AWS、AgentCore GatewayとMCPで複数アカウント横断AI

AWS が機械学習ブログで、複数アカウントにまたがるデータを扱う AI エージェントの構築手順を公開した。各チームが自分のアカウントでデータを管理する形は、所有者の明確さや権限範囲の分離、独立したデプロイの点で理にかなっている。しかし 1 アカウント分のデータしか見えないエージェントでは価値が限られ、分散したデータにつなごうとすると、複製するか、アカウント間の IAM 設定を複雑に組むことになりがちだった。今回の構成は、データを各事業部門（LOB）のアカウントに置いたまま、問い合わせ時に必要な分だけを取り出すことを狙う。

構成は 3 層からなる。中央のプラットフォームアカウントでは、AgentCore Runtime 上でエージェントを動かし、Amazon Bedrock で推論を行う。Runtime はセッションごとに専用の microVM で分離される。推論を中央に集めることで、基盤モデルの管理やコストの把握を 1 か所で行える。

各部門は、S3 などのリソースを直接さらすのではなく、データとツールを MCP サーバとして包んで公開する。例として、リテールバンキング部門が、Amazon Bedrock Knowledge Bases を使って銀行の規程 PDF を検索するツールを提供する。MCP サーバも部門側のアカウントの AgentCore Runtime で動くため、何を公開し、裏でどんな処理を走らせるかは部門が決められ、ツールの呼び出し口さえ変えなければ実装を差し替えてもエージェント側に影響しない。

両者をつなぐのが AgentCore Gateway で、ハブ・アンド・スポーク型の構成をとる。Gateway は各部門の MCP サーバを登録し、エージェントからは 1 つの MCP サーバとして見える。ツール呼び出しの際、Gateway は AgentCore Identity から OAuth 2.0 のマシン間認証の資格情報を取り出してリクエストに付け、該当部門の MCP サーバへ送る。受け手は Okta の OpenID Connect のエンドポイントでトークンを検証してから処理する。Gateway 層では Amazon Bedrock Guardrails によるコンテンツの安全対策や、Policy による細かなアクセス制御もかけられ、いずれもエージェントのコードの外で効く。

この設計の意味は、データの所有と AI の活用を切り分けられる点にある。部門は自分のデータの管理権を手放さずに済み、プラットフォーム側は統制と課金を一元化できる。データの集約に伴う調整や、アカウント間の権限設定の複雑さが AI 活用の障壁になっていた大企業にとって、現実的な落としどころを示した構成といえる。