大企業の情報システム担当者なら、この光景に見覚えがあるはずだ。「営業部門のCRMデータと、経理部門の売掛データを突き合わせたい」という現場の要望が上がる。情報システムが調整に入り、セキュリティ部門が審査し、法務がデータ取り扱いルールを確認する。半年後、プロジェクトはようやく動き出すか、あるいは静かに消える。その間、現場はExcelで手作業の横断集計を続ける。
この問題の根は深い。データを部門ごとに分離して管理するのは、セキュリティ上の要請であり、ガバナンス上の正論でもある。だからこそ解決が難しかった。従来のアプローチは「データを一か所に集める」方向で進んできた。データウェアハウスへの統合、ETL処理の構築、そして再びセキュリティ審査。莫大なコストと時間をかけて壁を物理的に取り除こうとしてきた。
AWSが今回示したのは、その逆の発想だ。
データは動かさない。部門ごとのAWSアカウントにデータを置いたまま、AIエージェントが各部門のシステムに「質問しに行く」経路を整備する。エージェントが受け取るのはツールが返した特定の結果だけで、元のデータセットは所有アカウントの外に一切出ない。セキュリティ部門が守りたかったものはそのままに、現場が求めていた横断的な情報アクセスを実現する。矛盾しているように聞こえて、技術的には両立している。
この発想の転換が持つ意味は、クラウド新機能の文脈で語るには少し小さい。「誰がどのデータにアクセスできるか」という問いは、本来は企業ガバナンスの中核的な問いだ。それをインフラの再設計ではなく、AIエージェントのアーキテクチャレイヤーで解こうとしている点に、今回の発表の核心がある。
データ統合の歴史を振り返ると、企業は常に「集める」か「諦める」かの二択を迫られてきた。ERPが登場したとき、その答えは「全部ERPに集める」だった。データウェアハウスが登場したとき、答えは「分析用に別の場所に集める」だった。コストと時間をかけて壁を壊すことが、横断的な情報活用の前提条件だった。
今回AWSが示したアーキテクチャは、壁を壊さずに壁の向こうに問い合わせる経路を作る。データの所有権と管理責任は従来どおり各部門が持つ。認証と認可の仕組みで「誰が何を聞けるか」を細かく制御する。その設計がそのまま、大企業のガバナンス要件と整合する形になっている。
誰にとって使いやすい発表かは、読めば明確だ。データを一か所に集めるコストと時間がプロジェクトのボトルネックになってきた組織、複数事業部門が独立したAWSアカウントで運用を行っている企業、そして「横断分析はしたいが、データを外に出すなと言われている」現場担当者だ。
技術的な詳細は後段で整理するが、先に言えることがある。企業データのサイロ問題は、これまで「インフラをどう設計するか」の問題として扱われてきた。それが今、「AIエージェントをどう動かすか」の問題として再定義されつつある。
3行まとめ
- AWSはAmazon Bedrock AgentCore GatewayとMCPを組み合わせ、複数のAWSアカウントをまたいでAIエージェントがデータに問い合わせられるアーキテクチャを公開した
- 各部門のデータは専用AWSアカウントに置いたまま、中央のプラットフォームアカウント上のエージェントがMCP経由で横断的に問い合わせる仕組みで、データそのものは所有アカウントの外に出ない設計になっている
- クロスアカウントアクセスの認証はAgentCore IdentityとOktaが担い、認可の細かい制御にはCedarベースのPolicy in AgentCoreが使われる
※以下は詳細
データを動かさない設計の仕組み
従来のBI導入やデータ活用プロジェクトでは、まずデータを一か所に集めるところから始まる。データウェアハウスへの移行、ETL処理の構築、セキュリティ審査。この工程が多くのプロジェクトの遅延要因になってきた。
今回の設計はその手順を省く。各事業部門はMCPサーバーを自分たちのAWSアカウント内で立ち上げ、データを引き続き自部門で管理する。中央のAIエージェントはその窓口を通してのみ情報を引き出せる。ツールが返すのは当該リクエストが必要とした特定の結果だけで、元のデータセットは所有アカウントの外に出ない。
MCPとAgentCore Gatewayの役割分担
MCP（Model Context Protocol）は、AIモデルが外部のデータソースやツールと通信するための標準プロトコルだ。
Amazon Bedrock AgentCore Gatewayはプラットフォームアカウントに配置され、エージェントに対して単一のMCPエンドポイントとして機能する。各事業部門のMCPサーバーをターゲットとして登録し、そのエンドポイントからセマンティック検索による統合ツールディスカバリー、AgentCore Identityによる認証、Policy in AgentCore（Cedar）による認可制御、および可観測性を提供する。
エージェントがツールを呼び出すと、GatewayはAgentCore IdentityからOAuth 2.0のM2Mクレデンシャルを取得し、送信リクエストに付与した上で対象の事業部門MCPサーバーにルーティングする。MCPサーバー側はOktaのOIDCエンドポイントに対してトークンを認証してからリクエストを処理する。
具体的な構成例と公開リソース
元記事では、小売銀行チームが`get_balance`や`get_profile`といったツールを、融資チームが`get_credit_score`や`search_lending_policies`といったツールをそれぞれのMCPサーバーで公開する構成例が示されている。融資チームのツールはAmazon Bedrock Knowledge Basesを使ったRAGで銀行ポリシーのPDFを検索する。
新規実装ではAmazon Bedrock Managed Knowledge BaseをGatewayのネイティブコネクタとして直接接続することもでき、その場合は検索インフラを自前で運用する必要がない。AWSはサンプルコードをGitHubで公開しており、Amazon Bedrock上でエージェントを動かし、複数アカウントにまたがるMCPサーバーに問い合わせる一連の流れをステップごとに確認できる状態になっている。
全体まとめ
AWSは、AIエージェントが複数のAWSアカウントをまたいでデータに問い合わせられるアーキテクチャを公開した。各部門のデータは元のアカウントに置いたまま、中央のエージェントがMCP経由でアクセスする仕組みで、エージェントが受け取るのはツールが返した特定の結果のみ。元のデータセットは所有アカウントの外に出ない。AgentCore IdentityとOktaによる認証、CedarベースのPolicy in AgentCoreによる認可制御を組み合わせて運用でき、サンプルコードはGitHubで公開されている。