Stripeは年間約1.4兆ドルの決済を50カ国で処理しており、コンプライアンスチームは毎日数千件の取引をレビューする必要がある。この規模に対応するため、StripeはAmazon Bedrockを活用してAWS上にプロダクション品質のAIエージェントシステムを構築し、金融コンプライアンスレビューの効率と一貫性を高めた。
このシステムの主な目的は、人員を比例的に増やすことなくコンプライアンス業務を拡張しつつ、規制当局が求める高い品質基準を維持することにある。以前は、熟練したアナリストが最大80%の時間を断片化されたシステムでの文書収集に費やし、高価値のリスク評価に十分な時間を割けなかった。StripeのソリューションはAIエージェントと自動オーケストレーションを組み合わせ、コンプライアンスをリソース集約的なプロセスからスケーラブルなエンジンへと変革する。同社によれば、このシステムはレビュー処理時間を26%削減し、有用性評価は96%を超え、最終的な意思決定権は常に人間の専門家にある。
なぜエージェント型AIなのか
従来の自動化では、複雑で判断を伴うコンプライアンス業務に対応するのは困難だ。AIエージェントは、スケーラブルで一貫した品質と完全な監査可能性を備えた調査支援を可能にしつつ、人間の制御を維持する。Stripeのシステムは次の3つの柱に基づいている。
- 監督と説明責任：人間中心の検証、設定可能な承認ワークフロー、多層的な意思決定チェックポイント。人間が主導権を握り、エージェントが支援する。
- 透明性：すべてのアクション、決定、根拠を不変的に記録する完全な監査証跡。
- 効率性：事前調査と動的分析により、より迅速かつ深いレビューを実現。
技術アーキテクチャ
技術的な実装は、タスク分解とオーケストレーション、ReActエージェントフレームワーク、およびそれを支えるインフラストラクチャサービスの3つの主要コンポーネントで構成される。
タスク分解とレビューオーケストレーション
単一のエージェントに長く複雑なレビューを一度に処理させることは現実的ではない。制約のないエージェントは誤った点に集中し、本当に必要なことに十分に焦点を当てられない可能性がある。そこでStripeは、複雑なレビューを組み合わせ可能な小さなサブタスクに分解した。各サブタスクは他のサブタスクの結果に依存する可能性があり、有向非巡回グラフ（DAG）を形成する。この設計により、エージェントプロセスは品質テストで検証された問題でのみ実行され、調査が必要な基礎を網羅し、エージェントに十分なコンテキストと焦点を提供して高品質な結果を導く。
各サブタスクのエージェント応答は厳格な品質テストを受けているが、Stripeはエージェントの応答に全面的に依存しない。代わりに、応答は補足情報として人間のレビュアーに提供され、レビュアーが各サブタスクに最終回答する。これにより、監督と説明責任を確保しつつ、効率性の利点も得られる。レビュアーはレビューツールと対話し、このツールは現在の問題と、その回答をコンテキストとして必要とする後続の問題を認識している。ツールはオーケストレーターとして機能し、人間がレビューした回答を後続の問題のコンテキストとして渡す。
ReActエージェントフレームワークの実装
各サブ質問の調査資料を取得するため、StripeはReAct（推論と行動）フレームワークに基づくコンプライアンスエージェントを構築した。Amazon Bedrock上の大規模言語モデルを推論に使用するだけでなく、エージェントはツール呼び出しを通じて関連するシグナルを動的に収集する。Stripeがこのフレームワークを選んだのは、特定の対象に関連するかどうかわからない信号がほぼ無限に存在する問題を解決するためだ。エージェントはどのシグナルが関連するかを判断し、十分な自信が得られるまでフォローアップを提案して最終回答を導く。
ReActサイクルでは、思考ブロックでツールが要求されると、エージェントフレームワークはLLMの実行を停止し、代わりにプログラムでそのツールを実行する。そして、その出力を観察結果としてエージェントに強制的にフィードバックしてから、続行を許可する。この注入パターンは閉ループ制御メカニズムを実装している。
- エージェントの推論を実際のデータに基づかせる：すべてのツール出力を観察結果として処理することを義務付けることで、エージェントが幻覚を起こしたりツール結果を捏造したりするのを防ぐ。
- コンテキストの一貫性を維持する：エージェントが取得した各情報を明示的に認識し、推論してから進むことを強制する。
- 推論の漂流を防ぐ：観察ステップがチェックポイントとして機能し、エージェントの思考プロセスが推測的な推論ではなく事実に基づくツール出力に固定されるようにする。
- 監査可能性をサポートする：ツール呼び出し→観察→推論の明示的なトレースを作成し、コンプライアンスレビュー用に記録できる。
これは工学におけるフィードバック制御システムに類似している。エージェントは前のアクションからのフィードバック（観察）を処理する前に次のアクションに進むことができず、幻覚や軌道からの逸脱につながる開ループ動作を防ぐ。
このアプローチの課題は、タスクが非常に複雑で多くのターンと観察を必要とする場合、特に観察結果が冗長な場合、後半のターンでプロンプトが非常に長くなることだ。サブタスク分解により各質問の範囲を制限し、ターン数を少なく保つ。プロンプトキャッシングも、ここでの主要なコスト要因である入力トークンのコスト削減に役立つ。プロンプトキャッシングでは、各ターンで以前のメッセージに追加される新しい観察と思考に対してのみ支払う。Amazon Bedrockがこの機能を提供している。
完全なエージェントレビューアーキテクチャとインフラストラクチャ
Stripeは実際のエージェント実行をサポートするためにかなりのインフラストラクチャに依存している。完全なアーキテクチャは、前述のレビューインターフェースとオーケストレーター、およびエージェントロジックをホストし実行を促進するエージェントサービスで構成される。エージェントサービスはStripeのLLMプロキシサービスによってサポートされ、利用可能なエージェントツールを通じて内部シグナルに接続される。
専用エージェントサービスの構築
このプロジェクト以前は、Stripeのエージェントサービスは存在せず、このプロジェクトがその要求につながった。当初、Stripeはエージェントを従来のML推論エンジンに適合させようとしたが、以下の理由ですぐに却下された。
- コンピュートプロファイル：従来のMLはコンピュートバウンドであり、GPU、高速マルチスレッドCPU、大容量メモリなどの高価なハードウェアを必要とする。対照的に、エージェントアプリケーションは主にネットワークバウンドであり、基盤モデルの完了やツール呼び出しの実行を待つ。
- レイテンシ：前述のReActフローを参照すると、エージェントは必要なツール呼び出しのラウンド数に応じて不確定な時間がかかる可能性がある。長いエージェントクエリやデータベースツール呼び出しは、XGBoostモデルがミリ秒で完了するのに対し、スレッドを数分間アイドル状態にする可能性がある。
- 異なるAPI：従来のMLは基本型（浮動小数点数、ブール値など）を出力する傾向があるが、エージェントは結果に注釈を付けるためにより柔軟なスキーマを必要とする。一部のエージェントはステートフルな会話状態を維持する必要がある。
その結果、Stripeは独自のエージェントサービスを立ち上げた。当初はステートレスな同期推論エンドポイントに似ていたが、現在ではステートフルなマルチターン会話型エージェントも処理する。立ち上げ時の数個のエージェントから、1年足らずで100を超えるエージェントにまで成長した。
LLMプロキシアーキテクチャ
StripeのReActエージェントはAmazon Bedrockを直接呼び出さない。代わりに、LLMアクセスの標準方法としてLLMプロキシミクロサービスを使用する。StripeがLLMプロキシサービスを使用する理由は以下の通り。
- ノイジーネイバー：StripeにはさまざまなアプリケーションでLLMを使用するチームが多数ある。LLMプロキシは、他のチームが特定のモデルのLLM帯域幅を占有するのを防ぐ保護手段を提供し、リソースの競合を防ぐ。
- 1つのAPI、多数のモデル：単一のエンドポイントにより、Amazonや主要AI企業の基盤モデル間でプロンプトキャッシングやツール呼び出しなどの機能を指定するのが簡素化される。モデルの変更は、各ユースケースで多数の異なるクライアントを管理するのではなく、モデルタイプを引数として変更するだけで済む。
- モデルフォールバック：リソース制約や完全な障害が発生した場合に、デフォルトモデルを自動的に指定する機能を提供する。
- モニタリング：認証を要求することで、サービスはモデルの使用状況を追跡し、将来のリソース需要を予測し、アプリケーションのプライバシーに応じて適切なモデルが使用されていることを確認できる。
アーキテクチャコンポーネントの連携
人間のレビュアーがレビューを主導し、エージェントの応答を事前に取得した調査資料として使用する。レビュアーが回答すると、その応答は同じレビュー内のより深い質問のプロンプトに使用でき、レビュー質問を有向非巡回グラフとしてオーケストレーションする。このプロセス全体により、品質や監査可能性を犠牲にすることなく、コンプライアンス業務のスケーラビリティが確保される。