人工知能（AI）を活用したアプリケーションを構築する組織は、共通の課題に直面しています。それは、大規模言語モデル（LLM）エージェントにエンタープライズデータレイクへのアクセスを提供する際に、すべてのエージェントとアプリケーションで統合ロジックを重複させないことです。ほとんどのチームは、Model Context Protocol（MCP）サーバーのような共有ゲートウェイを介さずに、エージェントをデータベースやAPIに直接接続することから始めます。新しいデータセットごとにカスタムコードが必要となり、各エージェントが独自のアクセス制御を再実装します。データセットやエージェントの数が増えるにつれて、権限の適用がずれ、新しいデータソースのオンボーディングは数日がかりのエンジニアリング作業になります。
私たちのチームは、Amazonの北米ソートセンター（NASC）ネットワークをサポートしており、計画チームは容量、労働力、荷物の流れを管理するために運用データに依存しています。これらのチームにデータへの会話型アクセスを提供するため、私たちはAmazon Elastic Container Service（Amazon ECS）とAWS Fargate上にサーバーレスMCPサーバーを構築しました。このサーバーは、AIエージェントとエンタープライズデータレイクの間の集中型でエージェント非依存のゲートウェイとして機能します。新しいデータセットを公開するにはJSONメタデータファイルが1つあれば十分で、サーバーは次回のパイプライン同期時に自動的に検出します。
問題の定義と設計目標
システム設計を形作った2つの相互に関連する課題があります。それは、データアクセスパターンの断片化と持続不可能なオンボーディングモデルです。
大規模な統合の課題
私たちのデータレイクには、運用指標、ビジネス分析、ドメイン固有のデータにわたる数千のデータセットが含まれています。複数のチームが会話型でデータをクエリできるAIアシスタントを望んでいましたが、それぞれがゼロから独自の統合を構築していました。各エージェントは独自のSQL生成ロジック、スキーマ知識、接続処理を埋め込んでいたため、スキーマの変更は各エージェントを個別に修正することを意味しました。アクセス制御は断片化され、データアクセス決定の単一の監査ポイントがありませんでした。新しいデータセットのオンボーディングには、カスタムツールコード、クエリ検証、再デプロイが必要で、通常はテーブルあたり数日かかりました。
設計目標
私たちは4つの要件を設定しました：
- 構成駆動型のデータレイクアクセス：データセットの追加にはメタデータファイルのみが必要で、コードは不要。
- エージェント非依存のツールインターフェース：任意のMCP互換クライアントが同じツールを呼び出せる。
- 集中型の権限適用：アクセス制御はMCPサーバー層で適用。
- 柔軟なインフラストラクチャ：システムは突発的なAIワークロードパターンに応じてスケール。
ソリューションの概要
アーキテクチャは、クライアント、MCPサーバー、ツール、ナレッジベース更新の4つの層に懸念事項を分離し、各層は独立してスケールおよびデプロイ可能です。メタデータカタログがツール層を支え、AIエージェントがSQL生成時に参照するスキーマ記述、列レベルのセマンティクス、テーブル関係を保存します。エージェントはクエリ時にカタログからスキーマ知識を取得するため、テーブル構造をハードコードしたり、スキーマ変更時に再デプロイする必要はありません。ナレッジベース更新層はカタログを最新の状態に保ち、新しいデータセットのメタデータが到着するたびにインデックスを作成します。
アーキテクチャの詳細
ユーザーはクライアントアプリケーション（Webチャット、Slack、IDEプラグイン、外部エージェント）からクエリを送信します。リクエストはAmazon Route 53でDNS解決され、HTTPSとAWS WAFが設定されたパブリックサブネットのApplication Load Balancerに到達します。ロードバランサーはリクエストをAmazon Cognitoにルーティングし、Cognitoがユーザーを認証してリクエストを強化します。認証されたトラフィックはプライベートサブネットに入り、クライアント層がAmazon ECS Fargate上で実行されます。この層はAmazon DynamoDBでセッション状態を処理し、内部Application Load Balancerを介してリクエストをMCPサーバー層（これもAmazon ECS Fargate上）に転送します。MCPサーバー層では、Amazon Bedrockを搭載したAIエージェントがFastMCP（MCPサーバー構築用Pythonフレームワーク）で構築されたツールをオーケストレーションします。すべてのモデルインタラクションにAmazon Bedrock Guardrailsが適用されます。データ層にはツールバックエンドが含まれます：Amazon AthenaとAmazon Redshiftがデータレイクに対してSQLクエリを実行し、Amazon Bedrock Knowledge Basesがセマンティック検索を処理します。Amazon S3とナレッジベースへのデータ取り込みはAWS Lambdaが処理します。
MCPクライアント層：認証とセッション管理
リクエストはクライアントアプリケーションからAmazon Route 53でDNS解決され、HTTPSとAWS WAFが設定されたApplication Load Balancerに到達します。ロードバランサーはトラフィックをAmazon ECS Fargateクライアントサービスに転送し、このサービスはAmazon Cognitoと統合してJSON Web Token（JWT）認証を行い、Amazon DynamoDBでセッションを保存します。コンテキストマッピング構成がこの強化を促進し、各クエリを関連するテーブルのみにスコープします。私たちのテストでは、このスコープ設定によりエンドツーエンドのインタラクション遅延が15〜20秒の範囲に保たれました。コンテキストがテーブルを指定すると、MCPサーバーはメタデータカタログの検索をそれらのテーブルに絞り込み、ノイズを減らしてSQL生成の精度を向上させます。新しいビジネスドメインの追加は、マッピングにエントリを追加するだけです。
MCPサーバー層：ステートレス実行と会話状態
MCPサーバーは独自のECS Fargateクラスターで実行され、クライアント層から分離されています。リクエストはAmazon Route 53とプライベートサブネット内の内部Application Load Balancerを介して到達します。サーバーはクエリ分析、ツール選択、実行、応答生成を含む完全なオーケストレーションを処理します。MCPプロトコルエンドポイント（/mcp）、FastMCPを搭載したJSON-RPCインターフェースを通じて、Amazon Q DeveloperやIDE拡張機能などの外部MCP互換クライアントがツールを直接検出して呼び出すことができます。Fargateタスクはステートレスで、会話状態はDynamoDBに永続化されるため、データ損失なしにタスクを置き換えたりスケールしたりできます。リクエストが到着すると、エージェントはセッション履歴を取得し、Amazon Bedrockを使用してユーザーの意図を分析し、適切なツールを検出して呼び出し、結果をユーザーにストリーミングで返します。
ツール層とメタデータ駆動型データレイクアクセス
各ツールはFastMCPに登録され、実行時に検出可能です：SQLクエリツール（バックエンド：Amazon AthenaとAmazon Redshift）は、データレイクおよびRedshift内の設定された任意のデータセットに対してSQLクエリを実行します。ドキュメントとメタデータ検索（バックエンド：Amazon Bedrock Knowledge Bases）は、内部ドキュメント、テーブルメタデータ、チームWikiに対してセマンティック検索を行います。ポリシー検索（バックエンド：Amazon Bedrock Knowledge Bases）は、運用ポリシーと標準手順を検索します。
Athenaクエリツールはデータレイクへの主要なインターフェースです。エージェントはまずメタデータカタログをクエリして利用可能なスキーマを理解し、Amazon Bedrockを介して最適化されたSQLクエリを生成し、Athena互換性のためにSQLを検証および自動修正してから実行します。結果はオーケストレーティングエージェントに返され、自然言語で合成されます。
責任あるAIの制御
Amazon Bedrock GuardrailsはすべてのLLMインタラクションに適用され、有害なコンテンツのフィルタリング、グラウンディングチェックの実施、プロンプトインジェクション試行のブロックを目的としています。これらのガードレールはMCPサーバー層で本番制御として機能するため、接続方法に関係なく、すべての接続エージェントが同じコンテンツ安全ポリシーの恩恵を受けます。AthenaクエリツールはSELECTのみのクエリを強制し、データレイクに到達する前にツールレベルで書き込み操作を拒否します。
ナレッジベース更新層：単一のJSONファイルによるデータセットオンボーディング
システム全体は構成駆動型の拡張性を中心に構築されています。新しいデータセットを追加するには、テーブルを記述するメタデータJSONファイルと、オプションのコンテキストマッピングエントリが必要です。このファイルはテーブルのスキーマ、ビジネスコンテキスト、列レベルのセマンティクスをキャプチャし、AIエージェントがデータセットを理解してクエリするための唯一の信頼できる情報源として機能します。business_description_for_the_tableフィールドには、エンジン固有のクエリヒント（例：「文字列リテラルをラップするには常にdate()を使用する」）が含まれ、SQL検証の失敗を減らします。column_detailsフィールドは、各column_name [type]を自然言語の説明とサンプル値とペアにし、エージェントにスキーマ認識とビジネスセマンティクスの両方を提供します。sample_valuesフィールドは正確なWHERE句の生成に重要です。なぜなら、エージェントは実際のデータパターンを学習するからです。例えば、warehouse_idには「East region facility」のような綴られた名前ではなく、FC-EAST-07のようなコードが含まれることを学びます。
パイプラインはメタデータファイルを取得し、Amazon Titan Text Embeddingsでベクトル埋め込みを生成し、Amazon Bedrock Knowledge Basesにインデックスします。インデックスされると、テーブルは手動での再インデックスやサーバーの再起動なしに、すべての接続エージェントから検出可能になります。特定のアプリケーションの精度を向上させるために、エンジニアはオプションでデータセットをビジネスコンテキストに関連付けることができます。これにより検索範囲が絞り込まれ、エージェントは適切なテーブルを優先します。コンテキストが指定されていない場合、エージェントはインデックスされたすべてのテーブルを検索します。コンテキストマッピングは検索スペースを制限することで遅延を減らし、SQL精度を向上させます。このスコープ設定はオプションであり、メタデータファイル自体を変更せずにいつでも追加できます。
まとめ：実際のクエリ
ユーザーが「先月の価値の高い注文トップ10は何でしたか？」と尋ねると、クライアントはビジネスコンテキストでリクエストを強化して範囲を絞ります。エージェントは質問をベクトル埋め込みに変換し、メタデータカタログを検索して一致するスキーマを見つけ、軽量なLLM呼び出しで最も関連性の高いテーブルを選択します。選択されたスキーマ、列の説明、エンジン固有のクエリヒントを使用して、エージェントはSQLを生成し、検証して実行し、結果を自然言語の応答に合成します。このプロセス全体は15〜20秒で完了し、メタデータ駆動型アプローチの効率性と拡張性を示しています。