9月12日、AWSが「Mirroring Your Organization with Multi-Agent AI for FSI Risk Assessment」と題した記事を公開した。金融機関のリスク評価プロセスをマルチエージェントAIで組織構造に対応させ、アーキテクチャ設計段階から自動化する手法を解説している。
「リスク評価が常に後手」という構造問題
金融機関では、アーキテクチャチームがシステムを設計し、セキュリティチームが後からNIST CSFやPCI-DSSに照らしてレビューし、リスクチームはデプロイ判断が下りてから初めてアセスメントを行う——という順番が一般的だ。問題は、リスク報告書が経営層の目に届く頃には、アーキテクチャはすでに確定しており、規制上の露出は定量化されておらず、是正コストは跳ね上がっている点にある。
規制当局はこの状況に対して動き始めている。EUの**DORA（デジタル運用レジリエンス法）**は新システムのデプロイ前にICTリスクを特定・評価することを義務付け、バーゼル委員会のCRI（サイバーレジリエンスイニシアチブ）もサイバー脅威への運用レジリエンスに関するグローバル基準を定めている。OCC（通貨監督庁）の高水準基準も、重要な技術変更に対する事前リスク評価を要求する。しかし大半の機関は、アナリストが設計書を読み、要件を一つずつコントロールにマッピングするという手動の逐次プロセスに依存し続けている。
核心：組織の「三線防衛モデル」をエージェントで再現する
AWSが提案するのは、組織構造そのものをAIエージェントの構成に写し取る設計だ。金融機関で広く採用されている「三線防衛（Three Lines of Defense）」モデル——第一線（業務・テクノロジー）、第二線（リスク・コンプライアンス）、第三線（内部監査）——に対応する形で、専門化されたエージェントを配置する。
| エージェント | 対応する防衛線 | 最適化対象 | 話す言語 |
|---|---|---|---|
| Architect Agent | 第一線（テクノロジー） | アーキテクチャ品質 | Head of Technology |
| Security Architect Agent | 第一線（情報セキュリティ） | セキュリティ態勢 | CISO |
| Risk Assessment Agent | 第一・二線（テクニカルリスク） | リスク定量化 | CRO |
| Auditor Agent | 第三線（内部監査） | 出力品質の検証 | Head of Audit |
| Organization Profile Agent | サポートエージェント（任意） | 組織コンテキストの付与 | 汎用 |
実装には**Strands Agents（AWSがオープンソースとして公開しているPython向けエージェントフレームワーク）、Amazon Bedrock、およびA2A（Agent-to-Agent）プロトコル**を使用している。なお、ここでいうA2AはAWSのエージェント間通信仕様であり、Google DeepMindが提唱する同名のA2Aプロトコルとは別物である点に注意が必要だ。
4段階の逐次パイプライン
重要なのは、これらが並列ではなく逐次（sequential）で動作する点だ。各エージェントは生のアーキテクチャ図ではなく、前段エージェントが解釈・構造化した出力を受け取る。この設計には明確な意図がある——上流エージェントがドメイン固有の判断を完結させてから次工程に渡すことで、下流エージェントは自分の専門領域に集中でき、上流の改善が下流に自動で波及する。逆に言えば、並列実行では「生のアーキテクチャ図をリスクエージェントが直接読む」ことになり、セキュリティ分析とリスク定量化の前提が噛み合わなくなる。
Step 1 – Architect Agent：プロジェクトチームがアーキテクチャ図をアップロードすると、コンポーネント、データフロー、アーキテクチャパターンを抽出した構造化レビューを生成する。セキュリティやリスクの判断は一切行わない。後続エージェントが迷わないよう、技術的事実だけを整理して渡すことがこのステップの役割だ。
Step 2 – Security Architect Agent：A2Aプロトコル経由でアーキテクチャ分析を受け取り、NIST 800-53などの規制フレームワークを特定されたAWSサービスにマッピングする。コントロールマッピングの方法論はシステムプロンプトに埋め込まれており、新しいフレームワークバージョンや管轄の追加はプロンプト更新だけで対応できる。コードデプロイは不要だ。ここで規制マッピングを専門的に完結させておくことで、次のリスク定量化が「どのコントロールが欠けているか」という明確な入力の上に立てる。
Step 3 – Risk Assessment Agent：前2エージェントの出力を統合し、CROレベルの言語（可能性、影響度、規制上の露出、リスクマトリクス、戦略的推奨事項）で報告書を生成する。テンプレートは部門ごとに調整可能で、リテールバンキング向けはPCI-DSS、グローバルマーケット向けはトランザクション完全性と市場リスクを重点化する。コード変更なしに部門別の適切なアセスメントを出力できる。 技術的事実（Step 1）とコントロール分析（Step 2）の両方が揃って初めて、ビジネス影響度の定量化が意味を持つ。
Step 4 – Auditor Agent：すべての出力を完全性・一貫性・トレーサビリティの観点で検証し、「REJECTED」または「CONDITIONAL」の判定と具体的な指摘を返す。現時点ではLLMベースのルールチェックのため完全に決定論的ではなく、判定結果はユーザーへの提示にとどまりワークフローをゲートしない。構造的なチェックの強化と自動再実行は今後の課題として挙げられている。
単一モノリシックエージェントを試してみたら
記事の中で特に実践的な知見として語られているのが、「一つのエージェントに全部やらせようとして失敗した」という経験だ。
「アーキテクチャ分析、セキュリティ評価、リスクスコアリングを単一エージェントに担わせると、リスク評価の品質が顕著に低下した。エージェントが自分がどのドメインで動いているかを見失うためだ。専門エージェントへの分割でこの問題は即座に解消された」
巨大なモノリシックエージェントはツールの混乱、実行の遅延、コスト増加を招く——AWSはこれを「large singleton anti-pattern」と呼び、ドメイン特化によって回避できると説明している。
実運用上の数字と制約
- エンドツーエンドの評価時間：10分未満（モデルレイテンシと入力ドキュメントサイズに依存）
- 使用モデル：Claude Sonnet 4（最大200Kトークンの入力コンテキストをサポート）
- RAG（Retrieval Augmented Generation）によりBedrock Knowledge Baseに対してフレームワーク文書を索引化し、コントロール引用の捏造を大幅に低減
- ただしAuditor Agentはすべてのコントロール引用を再検証しない。資格を持つセキュリティ・リスク専門家による人間レビューは引き続き必要
各エージェントは独立したAmazon ECSタスクとして動作し、それぞれ独立したデプロイライフサイクルを持つ。セキュリティチームは他チームと調整せずにSecurity Architect Agentのシステムプロンプトを更新できる。
詳細はMirroring Your Organization with Multi-Agent AI for FSI Risk Assessmentを参照していただきたい。
