Amazonの仕分け拠点向けに作ったデータレイクの共通窓口です。データセットごとのコードを減らし、JSONの定義と権限制御を集約します。 表の意味と権限を一緒に更新する運用が必要になります。サーバーレスでも認証、SQL確認、カタログの鮮度を保つ責任が残ります。 データ接続の重複を共通の窓口へ集める AWSは11月6日、Amazon ECS Fargate上にMCPサーバーを配置する技術解説を公開しました。Amazonの北米仕分け拠点を支えるチームが、計画業務のデータへ会話でアクセスするために作った構成です。エージェントごとにSQL生成や接続処理を持つと、表が変わるたびに複数の実装を直す必要があります。共通のMCP窓口を置き、データセットの追加をJSONのメタデータで扱う設計にしました。同期処理が新しい定義を見つけ、次の更新で取り込みます。新サービスの一般提供ではなく、社内での実装を基にした構成例です。 認証から表の意味までを層に分ける 構成は利用者側の画面、MCPサーバー、道具、知識の更新という層に分かれます。Cognitoによる認証とDynamoDBのセッション管理を経て、非公開ネットワークのサーバーへ進みます。FastMCPで道具を実装し、Amazon Bedrockで処理を調整します。データ側はAthena、Redshift、Knowledge Basesなどへつながります。カタログには表の形だけでなく、列の意味や表同士の関係を持たせます。利用する文脈に合わせて参照する表を絞る構成です。対象は複数の部門やエージェントから同じデータを扱う基盤チームと見られます。定義を追加する仕組みは、自由にすべての表を読ませることとは異なります。認証済みの利用者にどの範囲を許すかを、共通窓口で保つことが中心になります。 コードを減らした分だけ定義の品質を守る 実務上の論点は、メタデータと実際の表が一致しているかです。列の意味や更新の条件が古いと、正しい構文のSQLでも業務上の答えを誤る可能性があります。新しいデータセットの追加では、所有者、許す利用者、参照条件を一緒に確認する進め方が考えられます。原文の試験では文脈を絞って待ち時間を抑えていますが、応答時間は自社の表と負荷で確かめる対象です。Fargateで基盤管理を減らしても、モデル、検索、照会、通信の費用は残ります。Guardrailsだけで業務上の正しさが決まるわけでもありません。導入時には、生成SQLの検査と、権限が変わった後の拒否を確認する必要があると見られます。カタログの更新失敗を見つけ、旧定義を使い続けない体制が次の判断点です。 新しい表を追加した後の確認を自動化する 定義だけで接続先を増やせても、その表の利用目的と許可範囲は確認する必要があると見られます。次の判断点は、カタログが変わった後に、代表的な質問へ正しく答え、禁止した照会を拒否できるかです。同期の成功表示だけでなく、実際に使った定義の版を追えるようにする方法が考えられます。複数のエージェントが共通の窓口を使うほど、変更が及ぶ範囲も広がります。更新前後の比較と戻し方を備えることが焦点になります。定義の所有者も明確にします。