9月5日、AWSが「From silos to insights: Federated data access patterns for AI agents」と題した記事を公開した。この記事では、MCP（Model Context Protocol）とAmazon Bedrock AgentCoreを使い、サイロ化した企業データにAIエージェントが直接アクセスするフェデレーテッドアーキテクチャのパターンについて詳しく紹介されている。
問題の本質：データはあるのに、答えが出ない
企業データは今も各システムに分散したままだ。S3上のバッチデータにはAthena、リアルタイムストリームにはKinesisの知識、SaaSアプリにはそれぞれの独自APIが必要になる。この「使い分け」ができるのは一握りのデータエンジニアだけで、ビジネス側はダッシュボードを眺めるか、チケットを切って待つかしかない。
記事ではストリーミングメディア企業を例に挙げる。「先四半期に最も加入者を増やしたコンテンツはどれか？」「マーケティング支出と視聴完了率の相関は？」——こうした問いに答えるには、S3上のバッチデータ、Kinesisのリアルタイムストリーム、Aurora MySQLのCRMデータを横断する必要がある。単一のクエリエンジンでは到達できない構造だ。
従来の解決策（データレイクやデータメッシュ）はどちらも多大なデータエンジニアリング投資を要する。記事が提案するのは別のアプローチだ。「データを1か所に集める」のではなく、AIエージェントがデータの所在地に直接話しかける。
MCPとAgentCoreによるフェデレーテッドアーキテクチャ
MCP（Model Context Protocol）は、AIアプリケーションが外部データソースやツールに接続する方法を標準化するオープンプロトコルだ。MCPサーバーが各システムをラップし、ツール検出・呼び出し・レスポンス処理を統一インターフェースで提供する。これにより、LLMはSQLやAPIの詳細を意識することなく、複数の異種データソースを横断してクエリを発行できる。
記事のリファレンスアーキテクチャでは、Amazon Bedrock AgentCoreを中核に、3つのMCPサーバーをAgentCore Gatewayの背後に集約する。ユーザーが自然言語で質問すると、Strandsエージェント（AWS Strands Agents：AWSが公開するオープンソースのAIエージェントフレームワーク）が適切なMCPサーバーへルーティングし、結果を自然言語で返す。ユーザーはSQLもAPIも意識しない。
アーキテクチャの全体像：
- フロントエンド：CloudFront + S3（React）、Cognitoで認証
- エージェント層：Strands Agent + Claude Haiku 4.5（Amazon Bedrock経由、元記事に記載）
- ゲートウェイ：AgentCore Gatewayが3つのMCPサーバーを単一エンドポイントに集約
- データソース：S3（バッチ）、Kinesis（ストリーム）、Aurora MySQL（CRM）
実装コードはGitHubリポジトリで公開されており、自分でデプロイして試せる。
3つのアクセスパターン
記事の核心は、データソースの性質に応じて使い分ける3つのアクセスパターンだ。以下でそれぞれを詳しく見ていく。
パターン1：カタログ経由アクセス（Catalog-first）
最も統制が効く構成。AWS Glue Data CatalogがS3上のすべてのソースをメタデータ層に登録し、Data Processing MCPサーバーがGlueカタログとAthenaのクエリ機能を標準MCPツールとしてラップする。
エージェントの動作は「スキーマを発見してからクエリする」という2ステップだ。
manage_aws_glue_tablesでテーブルスキーマ（カラム名・型・パーティションキー）を取得- パーティションフィルター付きのPresto/Trino SQLを生成してAthenaで実行
システムプロンプトは全カラムを列挙するのではなく、意図ベースのルーティングルールと必須のスキーマ発見ワークフローを記述する形をとる。記事から一部を引用する：
TOOL DISCOVERY & ROUTING:
Routing by intent:
- Telemetry/streaming/viewing data → Glue catalog tools, then Athena query tools
- CRM/support tickets/ratings → MySQL tools
- AWS service questions → documentation search tools
SCHEMA DISCOVERY (MANDATORY before writing SQL):
Before writing any Athena query, retrieve the table schema:
→ Use manage_aws_glue_tables with operation='get-table'
なお、このパターンはAWS固有ではない。DatabricksもUnity Catalog向けのマネージドMCPサーバーを提供しており、同様のモデルを採用している。共通のトレードオフは「データをカタログ登録しないとエージェントがアクセスできない」点で、変化の速い環境ではボトルネックになりえる。
パターン2：ダイレクトアクセス
カタログ層を介さず、MCPサーバーがソースシステムに直接アクセスする構成。Aurora MCPサーバーがRDS Data API経由でAurora MySQLに直接クエリを投げる。
エージェントはDBの接続管理も認証も行わない。認証はMCPサーバーがAWS Secrets Managerで処理し、エージェントに公開されるツールはrun_queryとget_table_schemaの2つだけだ。
スキーマ変更がAurora側で起きると即座に反映される点がカタログ方式との最大の違いであり、スキーマが安定した運用系DBに適している。
パターン3：ハイブリッドアクセス
パターン1（カタログ経由）とパターン2（ダイレクト）を組み合わせる構成だ。記事では、Kinesisのリアルタイムストリームデータにはダイレクトアクセスで低レイテンシを確保しつつ、S3の履歴バッチデータにはGlue/Athenaを経由するカタログ経由アクセスを用いるといった組み合わせが想定されている。データソースごとに最適なパターンを選択できるため、単一パターンに縛られない柔軟な設計が可能になる。
3パターンを踏まえてエンジニアが注目すべきポイント
上記3パターンに共通する基盤として、AgentCore GatewayによるMCPサーバーの動的発見はスケーラビリティの面で重要だ。新しいMCPサーバーを追加しても、エージェント側のルーティングロジックを更新する必要がない。キーワードベースのセマンティック検索でツールを発見できるため、パターン3のようにデータソースが増えても柔軟に対応できる。
また、AWS MCP Serverは今年一般提供（GA）となり、boto3経由でAurora（RDS Data API）やKinesis Data Streamsにアクセスするコーディングエージェント向けツールキットとして提供されている。IAMポリシーによる認可とSigV4認証をそのまま使えるため、新たな権限管理の仕組みを構築する必要がない点は実用的だ。
詳細はFrom silos to insights: Federated data access patterns for AI agentsを参照していただきたい。
