JSONファイル1枚でデータセットを追加できる — AWSがAIエージェント向けデータレーク統合ゲートウェイの構築方法を公開

11月7日、AWSが「Serverless MCP server for AI agent data lake access on Amazon ECS Fargate」と題した記事を公開した。新しいデータセットの追加にコードは一切不要で、JSONファイル1枚を置くだけで全AIエージェントからそのテーブルが使えるようになる——この設計を中心に、Amazon ECS Fargateを使ったサーバーレスMCP（Model Context Protocol：Anthropicが策定したAIエージェント向けツール呼び出し標準プロトコル）サーバーの構築方法が詳しく紹介されている。

解決したかった問題：「エージェントが増えるたびにデータ接続を書き直す」地獄

AIエージェントが増えると、必然的に発生する問題がある。各エージェントが独自にSQL生成ロジックやスキーマ知識、接続処理を持ち、データセットが変わるたびに全エージェントを個別に修正しなければならない。権限管理も分散し、監査ポイントも存在しない。新しいデータソースを追加するたびに「数日がかりのエンジニアリング作業」が発生する——これが記事の出発点だ。

記事を書いたのはAmazonの北米ソートセンター（NASC）ネットワークを支援するチームで、物流の計画チームが運用データへ会話形式でアクセスできる仕組みを求めていた実案件だ。

核心：JSONファイル1枚でデータセットを追加できる設計

このアーキテクチャの最も面白い点は「メタデータ駆動」のデータレークアクセスだ。新しいデータセットを追加するのに、コードを一切書かない。必要なのはJSONファイル1枚だけである。

{
  "database_service_name": "athena",
  "database_name": "analytics_db",
  "table_name": "regional_order_summary",
  "business_description_for_the_table": "Regional order history with shipping status and delivery performance. Contains completed orders with delivery data. Refreshes daily. In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.",
  "column_details": {
    "order_id [varchar]": {
      "description": "Unique order identifier assigned at checkout.",
      "sample_values": ["ORD-20250115-001234", "ORD-20250116-005678"]
    },
    "order_date [timestamp(3)]": {
      "description": "Date and time the order was placed. Use this column for time-range filtering.",
      "sample_values": ["2025-01-15 08:00:00.000", "2025-01-16 12:30:00.000"]
    },
    "warehouse_id [varchar]": {
      "description": "Fulfillment center that processed the order.",
      "sample_values": ["FC-EAST-07", "FC-WEST-03", "FC-SOUTH-12"]
    }
  },
  "load_type": "Incremental (refreshes last 7 days)",
  "refresh_frequency": "Daily at 6:00 AM UTC",
  "table_size": "~2.1B rows"
}

特に細かく作り込まれているのがsample_valuesフィールドだ。エージェントが WHERE 句を生成する際、warehouse_idに「FC-EAST-07」のようなコードが入ることを事前に学習できる。「East region facility」のような誤ったリテラルを生成しなくなる。

business_description_for_the_tableにはエンジン固有のクエリヒントも埋め込める。「timestamp列との比較では必ずdate()でラップすること」といった注意書きをここに書いておくことで、SQL検証の失敗を減らす仕組みだ。

このJSONを配置すると、パイプラインがメタデータを拾い上げ、Amazon Titan Text Embeddingsでベクトル埋め込みを生成し、Amazon Bedrock Knowledge Basesにインデックスする。サーバーの再起動も手動の再インデックスも不要で、次のパイプライン同期後には全エージェントからそのテーブルが使えるようになる。

4層アーキテクチャの全体像

構成は以下の4層に分離されており、それぞれ独立してスケールできる。

クライアント層：Amazon Route 53 → Application Load Balancer（HTTPS + AWS WAF）→ Amazon ECS Fargate。Amazon CognitoでJWT認証を行い、セッション状態をAmazon DynamoDBに保持する
MCPサーバー層：プライベートサブネット内のECS Fargateクラスタで動作。PythonのFastMCP（PyPI）フレームワークでJSON-RPCエンドポイントを構築し、Amazon Bedrockがエージェントのオーケストレーションを担う。タスク自体はステートレスで、会話状態はDynamoDBに永続化される
ツール層：Amazon AthenaとAmazon RedshiftへのSQLクエリ、Bedrock Knowledge BasesによるRAG（セマンティック検索）を提供
ナレッジベース更新層：上述のJSONメタデータを取り込み、自動でインデックスを更新するAWS Lambdaベースのパイプライン

また、スコープを絞るための「コンテキストマッピング」設定も用意されている。

{
  "labor_planning": {
    "description": "Workforce management and capacity planning",
    "tables": ["workforce.capacity_details"],
    "sources": {"wiki": [], "quip": []}
  }
}

このマッピングでクエリ対象テーブルを限定することで、エンドツーエンドの応答レイテンシを15〜20秒に抑えることに成功している。コンテキストを指定しない場合は全インデックス対象テーブルを横断検索する。

実際のクエリ実行フロー

ユーザーが「先月の上位10件の高額注文は？」と問い合わせると、以下の流れが走る。

クライアントがビジネスコンテキストを付加してスコープを絞る
エージェントが質問をベクトル化し、メタデータカタログから関連スキーマを検索
スキーマ情報・列説明・クエリヒントを元にSQLを生成

SELECT order_id, customer_id, total_amount, order_date
FROM analytics_db.regional_order_summary
WHERE order_date >= date_add('month', -1, current_date)
ORDER BY total_amount DESC
LIMIT 10

SQLをAthena互換に検証・自動修正してから実行
結果を自然言語でストリーミング返答

さらに「Q4の返品率は？それについてプロダクトチームの分析は何と言っている？」のような質問にも一度のターンで対応できる。AthenaでSQLクエリを走らせながら、同時にKnowledge Basesでドキュメント検索を行い、両方の結果を統合して返答するためだ。

セキュリティ設計：AIエージェント文脈での意味

MCPサーバーはプライベートサブネットに置かれており、インターネットから直接到達できない。クライアント層のみがルーティングできる構成だ。AthenaのクエリツールはSELECTクエリのみを許可し、書き込み操作はデータレークに到達する前にツール層で拒否される。全ツール呼び出しはAmazon CloudWatchに構造化JSONで記録され、全エージェント・全アプリケーションのデータアクセスを単一の監査ポイントで確認できる。

AIエージェントの文脈でこの設計が特に重要なのは、エージェントが自律的にツールを呼び出す性質上、人間のオペレーターが介在しないクエリが大量に発行されうるからだ。各エージェントが独自の接続を持つ分散構成では、どのエージェントが何のデータにいつアクセスしたかを事後に追跡することが難しくなる。ゲートウェイを単一にすることで、監査・インシデント対応・権限変更のいずれも一箇所で完結する。

またAmazon Bedrock Guardrailsが全LLMインタラクションに適用され、有害コンテンツのフィルタリングやプロンプトインジェクション対策が行われる。

詳細はServerless MCP server for AI agent data lake access on Amazon ECS Fargateを参照していただきたい。