AWSがAIエージェント向けMCPサーバーをECS Fargateで構築する構成を公開

何が公開されたのか

AWSの機械学習ブログで、Amazonの北米ソートセンター（NASC）ネットワークを支援するチームが、Amazon ECS Fargate上で動かすサーバーレスなMCPサーバーの構成を説明しました。これはAWSの新製品発表ではなく、AIエージェントから企業データレイクへのアクセスを共通化する実装例の共有です。複数の計画チームが運用データを会話形式で扱えるようにする目的があったとされています。

背景には、エージェントごとにデータベースやAPIへの接続を実装し、データセット追加のたびに個別コードと権限管理が必要になる問題がありました。MCPサーバーを中央のゲートウェイとして置くことで、接続ロジックとアクセス制御を1カ所に寄せる狙いです。NASCのデータレイクには数千のデータセットがあると説明されています。

4層のアーキテクチャ

構成はクライアント、MCPサーバー、ツール、ナレッジベース更新の4層に分かれます。クライアント層はRoute 53、HTTPSとAWS WAF付きのApplication Load Balancer、Cognito、DynamoDBを使い、認証とセッション状態を担当します。MCPサーバー層は別のECS Fargateクラスタで動き、BedrockのエージェントがFastMCPで構築したツールを呼び出します。

ツール層ではAthenaとRedshiftがデータレイクにSQLを実行し、Bedrock Knowledge Basesがセマンティック検索を担います。S3へのデータ取り込みとナレッジベースの更新はLambdaが処理します。MCPサーバーのタスクはステートレスで、会話状態はDynamoDBに保存するため、タスクを交換・拡張しても状態を失わない設計です。

JSONでデータ追加

新規データセットの追加は、スキーマ説明、列の意味、テーブル関係などを記したJSONメタデータファイルで行います。サーバーは次回のパイプライン同期でファイルを自動検出し、Amazon Titan Text Embeddingsでベクトル化してBedrock Knowledge Basesに登録します。データセットごとのツールコードや再デプロイは不要と説明されています。

業務コンテキストを指定する任意のマッピングを追加すると、エージェントが検索するテーブルを絞り込めます。原文では、この絞り込みによりエンドツーエンドの対話遅延が15〜20秒程度に収まったとされています。外部のMCP対応クライアントは、FastMCPによるJSON-RPCインターフェースの/mcpエンドポイントを通じ、同じツールを直接検出・呼び出せます。

従来手法との違い

従来は各エージェントがSQL生成、スキーマ知識、接続処理を個別に持ち、スキーマ変更のたびに修正が必要でした。アクセス制御もエージェントごとに分散し、監査点が一本化されない問題がありました。MCPサーバーに集約すると、SELECTのみを許可する制御やBedrock Guardrailsを全クライアントに共通適用できます。

一方、原文は特定の製品や料金、導入までの期間を比較したものではありません。示されているのはNASC向けの実装と設計意図であり、他の企業が同じ効果を得られるかは、データの種類やメタデータの品質、利用するAWSサービスに左右されるとみられます。

現時点の注意点

原文では、導入・運用コストや各サービスの利用料金、SLA、対応リージョンは示されていません。また、既存のデータカタログやBI環境からメタデータを移行する手順にも触れていません。MCPサーバーはSELECTのみを許可し、書き込み操作はツール層で拒否する設計です。

Bedrock Guardrailsは有害コンテンツのフィルタやグラウンディング確認、プロンプトインジェクションの抑制を目的とすると説明されていますが、具体的な検知率や誤検知率は公表されていません。多テナント環境での分離方式や監査ログの詳細も、原文だけでは判断できません。