powered by TechFeed
表示モード
Deep Dive

MorningstarがAIエージェントを金融規制下で本番運用できた理由 — microVM分離・JWT認可・ガードレール調整の三層設計

9月28日、AWSが「How Morningstar built a financial advisor AI assistant powered by Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、Morningstarが金融アドバイザー向けプラットフォーム「Direct Advisory Suite」にAmazon Bedrock AgentCoreを用いたAIアシスタントを本番構築した経緯と実装詳細について詳しく紹介されている。金融業界でAIエージェントを本番運用する場合、単なる精度の問題だけでなく、規制対応・マルチテナント分離・監査証跡・ガードレールの整合性という複数の制約を同時に満たす必要がある。Morningstarがどのようにこの問題を解いたか、アーキテクチャの核心部分を掘り下げる。解決したかった問題:毎朝数時間の準備作業金融アドバイザーは1日のクライアント対応を始める前に、ポートフォリオレビュー・リスク評価・リサーチ更新・コンプライアンス確認を手作業で揃える。これが毎朝数時間を消費し、本来の助言業務を圧迫していた。Morning...

9月28日、AWSが「How Morningstar built a financial advisor AI assistant powered by Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、Morningstarが金融アドバイザー向けプラットフォーム「Direct Advisory Suite」にAmazon Bedrock AgentCoreを用いたAIアシスタントを本番構築した経緯と実装詳細について詳しく紹介されている。金融業界でAIエージェントを本番運用する場合、単なる精度の問題だけでなく、規制対応・マルチテナント分離・監査証跡・ガードレールの整合性という複数の制約を同時に満たす必要がある。Morningstarがどのようにこの問題を解いたか、アーキテクチャの核心部分を掘り下げる。

解決したかった問題:毎朝数時間の準備作業

金融アドバイザーは1日のクライアント対応を始める前に、ポートフォリオレビュー・リスク評価・リサーチ更新・コンプライアンス確認を手作業で揃える。これが毎朝数時間を消費し、本来の助言業務を圧迫していた。

Morningstarが構築したAIアシスタントは、この準備作業を自動化する。ファンドの格下げがあれば、どのクライアントのポートフォリオに影響し、AUM(運用資産残高)がどれだけ動くかをオーバーナイトで計算済みにしておく。クライアントのリスクスコアがずれていれば、ずれの大きさと方向を顧客ごとにランク付けして提示する。アドバイザーは「質問から始める」のではなく「準備済みの分析に対して行動する」という形に変わった。

アーキテクチャの核心:microVM分離とJWT認可

Direct Advisory Suiteは複数の金融機関が利用するマルチテナントプラットフォームであり、あるアドバイザーが別のアドバイザーのクライアントデータにアクセスできてはならない。この分離をどう実現するかが設計上の最重要課題だった。

Morningstarが選んだ答えはAmazon Bedrock AgentCore Runtimeだ。各アドバイザーセッションは独立したmicroVM上で動作し、VPCネットワーキングもエージェント単位で設定される。共有リソースで複数エージェントが競合するモデルではなく、セッションごとに専用リソースが割り当てられる。スケールアウト・スケールインの管理はAgentCore Runtimeが担うため、エンジニアリングチームはインフラ管理ではなくエージェントロジックの構築に集中できる。

認可にはAgentCore IdentityのカスタムJWTオーソライザーを使い、MorningstarのOIDCディスカバリーエンドポイントに対してリクエストを検証する。トークンが無効または期限切れの場合、エージェントロジックの実行前にリクエストを拒否する設計だ。

オーケストレーションフレームワークとしてLangGraphを採用しており、AgentCoreのメモリ機能がLangGraphのチェックポイント機能を裏支えする。アドバイザーとのやり取りが複数セッションにまたがる場合(例:数日かけてミーティング準備をする)、セッションをまたいだ状態をテナント間で漏洩させずに永続化するために使われる。

ガードレールの「チューニングループ」が肝だった

金融アドバイザー向けサービスは規制上の要件が厳しく、AIの応答内容にも一定のコンプライアンス制約が課される。元記事はその文脈でAmazon Bedrock Guardrailsの調整が最も難しい部分だったと述べている。

実装上の工夫点として、ガードレールをモデル呼び出しに直接アタッチするのではなく、ApplyGuardrail APIを独立したステップとして呼び出す方式を採用した。入力ガードレールはエージェント処理の前に走り、ブロック判定が出た場合はモデル呼び出し自体をスキップする。マスク判定の場合はテキストを安全なバージョンに置き換えてから処理を続行する。出力ガードレールはアシスタントの応答後に走り、問題のある出力を安全な応答に差し替える。

テスト段階では、過剰にブロードなルール設定が正当な業務クエリを遮断するという問題が繰り返し発生した。「特定の証券やクライアントシナリオに関する正当な質問がブロックされた」ケースがあり、複数回のイテレーションを経てポリシーを調整した。環境ごとに別々のガードレールIDを用意し、ドラフトバージョンで調整しながら本番に適用するワークフローを構築している。

なお、Bedrock Guardrailsはインスペクション対象のテキストを生のまま保存せず、SHA-256ハッシュで暗号的に表現する設計になっている。

オブザーバビリティ:LangSmithとAgentCoreの二層構造

マルチステップのエージェントワークフローでは、「なぜそのツールを選んだか」「どこでエラーが発生したか」をトレースするのが難しい。

Morningstarはプラットフォームヘルスの監視にAgentCore Observabilityを使い、呼び出し回数・レイテンシ・エラー率・セッションアクティビティを取得する。エージェントレベルのデバッグにはLangSmithを主要トレースレイヤーとして使用し、スーパーバイザー・サブエージェント・ツール間の呼び出しをネストされたトレースとして記録する。この二層構造により、ワークフロー全体の俯瞰とステップ単位のデバッグを使い分けている。

MCPによる外部連携(ロードマップ)

現時点でロードマップ段階だが、MorningstarはAIアシスタント自体をMCPサーバーとして公開する計画を持つ。MCP(Model Context Protocol)とは、AIモデルが外部ツールやデータソースと標準化されたインターフェースで通信するためのオープンプロトコルであり、Anthropicが仕様を主導している。MCPに対応したクライアントであれば、Amazon Q・ChatGPT・Claude・Microsoft CopilotからDASの機能に直接アクセスできるようになる。ツールやサービスの追加に伴う認証・監査・レート制限の管理にはAgentCore Gatewayを使う予定だ。


Morningstarの事例が示すのは、「規制環境でのエージェント運用は、精度と同じくらいガバナンスの設計が重要だ」という現実だ。microVM分離・JWT認可・ガードレールのチューニングループ・クロスセッションメモリの組み合わせは、金融以外の規制産業でも参照できる構成だろう。

詳細はHow Morningstar built a financial advisor AI assistant powered by Amazon Bedrock AgentCoreを参照していただきたい。