AWS、データレイク向けサーバーレスMCPゲートウェイを構築

AWSによると、同社チームはAmazonの北米仕分けセンター網の計画チームが企業データレイクを会話形式で検索できるよう、Amazon ECS Fargate上にサーバーレスのModel Context Protocol（AIエージェントが外部ツールと連携するための規約）サーバーを構築しました。ゲートウェイを通じて複数のAIエージェントが共通のデータツールとアクセス制御を利用できます。データセットを追加するにはメタデータJSONファイルを用意し、次回のパイプライン同期後にシステムが検出します。

数千のデータセットを含むデータレイクでは、従来、チームがエージェントごとに個別の連携機能を作り、SQL生成、スキーマ情報、接続処理を重複して実装していました。スキーマが変わると各エージェントの修正が必要になる場合もありました。データセットの導入には通常、テーブルごとに数日かかり、専用ツールコードの作成、クエリ検証、再デプロイが必要でした。AWSは、設定だけでのデータ追加、MCP対応クライアントで使えるツール、権限の一元管理、需要の急増に応じて拡張する基盤を目標に掲げました。

システムは、クライアント、MCPサーバー、ツール、ナレッジベースの更新という独立して拡張できる4層で構成されます。メタデータカタログにはスキーマの説明、列の意味、テーブル間の関係を保存し、エージェントがSQLを生成する際に利用します。テーブル構造をコードに固定する必要はなく、新しいメタデータは到着すると索引化されます。クライアントのリクエストはRoute 53、HTTPSとAWS WAFを備えたパブリックなApplication Load Balancer、Amazon Cognitoによる認証を経て、プライベートサブネット内のECS Fargateサービスに届きます。セッション履歴はDynamoDBに保存され、内部ロードバランサーが別のMCPサーバーへリクエストを振り分けます。Amazon Bedrockがエージェントのツール連携を担い、Bedrock Guardrailsはすべてのモデルとのやり取りに適用されます。

ツールには、Amazon AthenaとRedshiftによるSQL検索、文書とメタデータの検索、Amazon Bedrock Knowledge Basesによるポリシー検索があります。Athenaへのクエリでは、エージェントがメタデータカタログを確認し、BedrockでSQLを生成してAthena向けに検証・自動修正した後、結果を自然言語で返します。ツールはSELECT専用で、書き込み操作はデータレイクに届く前に拒否します。AWSによると、関連するテーブルにカタログ検索を絞り込むコンテキストマッピングを利用でき、テストでは一連の処理に15～20秒かかりました。

データセットの導入時には、テーブル、業務上の背景、列の意味を記したJSONメタデータファイルを作成し、任意でコンテキストマッピングを追加します。各項目にはクエリのヒント、説明、サンプル値を設定でき、AWSはWHERE句の作成に役立つ値の例として倉庫コード「FC-EAST-07」を挙げています。パイプラインはAmazon Titan Text Embeddingsでベクトル埋め込み（検索に使う数値表現）を作り、Bedrock Knowledge Basesにメタデータを索引化します。索引化後は、手動での再索引化やサーバーの再起動なしに、接続済みエージェントがテーブルを検索できます。

AWSが示した例では、「先月の金額が最も高い注文10件」という依頼を受け、コンテキストで検索範囲を絞り、エージェントが該当するスキーマを見つけてSQLを生成し、Athenaが検証済みのクエリを実行します。テストでは処理が15～20秒以内に完了しました。同じサーバーはAthenaの結果と文書検索を一つの応答にまとめられます。たとえば返品率の数値に、製品チームの分析を添えられます。AWSによると、サーバーはプライベートサブネットで稼働し、Cognitoで利用者を認証します。ツール呼び出しは構造化JSONとしてCloudWatchに記録されます。ECS FargateサービスはCPU使用率に応じて拡張し、クライアント層では50%をしきい値とします。サーバー層はCPUとメモリを基準にします。AWSは、AthenaとBedrockも各サービス内で拡張するため、設定変更なしで単一のクエリから同時に数百件のクエリまで処理できると説明しています。このエンドポイントは、BedrockとBedrock Knowledge Basesを利用できるAWSリージョンで提供されます。

AWSによると、同社チームはAmazonの北米仕分けセンター網の計画チームが企業データレイクを会話形式で検索できるよう、Amazon ECS Fargate上にサーバーレスのModel Context Protocol（AIエージェントが外部ツールと連携するための規約）サーバーを構築しました。ゲートウェイを通じて複数のAIエージェントが共通のデータツールとアクセス制御を利用できます。データセットを追加するにはメタデータJSONファイルを用意し、次回のパイプライン同期後にシステムが検出します。

数千のデータセットを含むデータレイクでは、従来、チームがエージェントごとに個別の連携機能を作り、SQL生成、スキーマ情報、接続処理を重複して実装していました。スキーマが変わると各エージェントの修正が必要になる場合もありました。データセットの導入には通常、テーブルごとに数日かかり、専用ツールコードの作成、クエリ検証、再デプロイが必要でした。AWSは、設定だけでのデータ追加、MCP対応クライアントで使えるツール、権限の一元管理、需要の急増に応じて拡張する基盤を目標に掲げました。

システムは、クライアント、MCPサーバー、ツール、ナレッジベースの更新という独立して拡張できる4層で構成されます。メタデータカタログにはスキーマの説明、列の意味、テーブル間の関係を保存し、エージェントがSQLを生成する際に利用します。テーブル構造をコードに固定する必要はなく、新しいメタデータは到着すると索引化されます。クライアントのリクエストはRoute 53、HTTPSとAWS WAFを備えたパブリックなApplication Load Balancer、Amazon Cognitoによる認証を経て、プライベートサブネット内のECS Fargateサービスに届きます。セッション履歴はDynamoDBに保存され、内部ロードバランサーが別のMCPサーバーへリクエストを振り分けます。Amazon Bedrockがエージェントのツール連携を担い、Bedrock Guardrailsはすべてのモデルとのやり取りに適用されます。

ツールには、Amazon AthenaとRedshiftによるSQL検索、文書とメタデータの検索、Amazon Bedrock Knowledge Basesによるポリシー検索があります。Athenaへのクエリでは、エージェントがメタデータカタログを確認し、BedrockでSQLを生成してAthena向けに検証・自動修正した後、結果を自然言語で返します。ツールはSELECT専用で、書き込み操作はデータレイクに届く前に拒否します。AWSによると、関連するテーブルにカタログ検索を絞り込むコンテキストマッピングを利用でき、テストでは一連の処理に15～20秒かかりました。

データセットの導入時には、テーブル、業務上の背景、列の意味を記したJSONメタデータファイルを作成し、任意でコンテキストマッピングを追加します。各項目にはクエリのヒント、説明、サンプル値を設定でき、AWSはWHERE句の作成に役立つ値の例として倉庫コード「FC-EAST-07」を挙げています。パイプラインはAmazon Titan Text Embeddingsでベクトル埋め込み（検索に使う数値表現）を作り、Bedrock Knowledge Basesにメタデータを索引化します。索引化後は、手動での再索引化やサーバーの再起動なしに、接続済みエージェントがテーブルを検索できます。

AWSが示した例では、「先月の金額が最も高い注文10件」という依頼を受け、コンテキストで検索範囲を絞り、エージェントが該当するスキーマを見つけてSQLを生成し、Athenaが検証済みのクエリを実行します。テストでは処理が15～20秒以内に完了しました。同じサーバーはAthenaの結果と文書検索を一つの応答にまとめられます。たとえば返品率の数値に、製品チームの分析を添えられます。AWSによると、サーバーはプライベートサブネットで稼働し、Cognitoで利用者を認証します。ツール呼び出しは構造化JSONとしてCloudWatchに記録されます。ECS FargateサービスはCPU使用率に応じて拡張し、クライアント層では50%をしきい値とします。サーバー層はCPUとメモリを基準にします。AWSは、AthenaとBedrockも各サービス内で拡張するため、設定変更なしで単一のクエリから同時に数百件のクエリまで処理できると説明しています。このエンドポイントは、BedrockとBedrock Knowledge Basesを利用できるAWSリージョンで提供されます。