Amazon Bedrock AgentCore Gateway の MCP サポート拡張
Amazon Bedrock AgentCore Gateway は、拡張されたツールスキーマサポート、動的リスティング、ストリーミング、セッション管理、OAuth 2.0 委任認証など、モデルコンテキストプロトコル(MCP)サーバーのエンタープライズ展開をサポートする新機能を追加し、集中管理、セキュリティ、可観測性を提供します。
エンタープライズでモデルコンテキストプロトコル(MCP)サーバーを展開する場合、サーバー間の細かいアクセス制御、どのチームがどのツールを使用しているかの可観測性、データ漏洩防止のセキュリティ保証、および集中管理された資格情報管理が大規模に必要となります。Amazon Bedrock AgentCore Gateway は、MCP サーバーとそれらを利用するクライアントの間に位置し、資格情報管理、可観測性、セキュアな接続を単一の信頼できるエントリポイントに集中化します。
本日、AgentCore Gateway に新機能を追加し、エンタープライズ MCP 展開のサポートをさらに強化します。この記事では、拡張された MCP ツールスキーマサポート、第一級プリミティブとしての MCP プロンプトとリソース、実行時の MCP サーバー発見のための動的リスティング、ステートフルなリアルタイム対話のためのストリーミングとセッション管理、実行中入力要求のためのエリシテーション、および委任認証のための OAuth 2.0 オンビハーフトークン交換について説明します。実践的な例については、GitHub サンプルリポジトリを参照してください。
AgentCore Gateway によるエンタープライズ向け MCP サーバーの統合
集中ゲートウェイがない場合、組織が構築するすべての MCP サーバーは、個別に資格情報、ポリシー執行、プライベート接続、ログ記録を処理する必要があります。つまり、法務チームの契約レビュー MCP サーバー、財務チームのデータ取得 MCP サーバー、運用チームのインシデント対応 MCP サーバーがそれぞれ同じインフラ負担を負います。セキュリティチームは各サーバーを個別にレビューし、開発者は承認を待ち、組織全体で MCP インフラがどのように使用されているかについて統合されたビューを持つ者は誰もいません。
AgentCore Gateway は、MCP トラフィックが通過する単一のエントリポイントを確立することで、この重複を回避します。次の図は、集中ガバナンスと制御を可能にする AgentCore Gateway の主な機能を示しています。
各チームは、MCP サーバーのビジネスロジックのみを構築します。AgentCore Gateway がその他すべてを処理します。MCP サーバー、REST API、AWS Lambda 関数など、さまざまなターゲットタイプの機能を集約します。リソースベースのポリシー(RBP)は誰が AgentCore Gateway を呼び出せるかを制御し、例えば Amazon VPC への呼び出しを制限できます。サービスコントロールポリシー(SCP)は、AWS 組織内で AgentCore Gateway がどのように維持されるかを管理します。
ネットワーク分離のために、AgentCore Gateway はコントロールプレーンとデータプレーンの両方で AWS PrivateLink をサポートし、トラフィックを VPC 境界内に維持します。また、マネージド VPC リソースモードを使用して、プライベート API エンドポイントや MCP サーバーに接続することもできます。集中管理されたアプリケーションおよびIDログは、監査とコンプライアンス要件の管理に役立ちます。
インターセプター機能により、AWS Lambda 関数がリクエストとレスポンスをカスタマイズし、細かいアクセス制御、サニタイゼーション、カスタム認可ロジックなどを可能にします。AgentCore Policy(プレビュー)との統合により、ツール中心のエージェントガードレールが提供され、集中プレーンでの確定的なポリシー執行が可能になります。AgentCore Gateway はまた、エージェントがツールを呼び出す前にユーザーに代わって認証する OAuth 2.0 認可コードフローを促進します。
ここからは、エンタープライズ MCP サポートをさらに強化するために AgentCore Gateway に追加された新機能について説明します。
単一ゲートウェイで MCP サーバープリミティブを公開
AgentCore Gateway は、組織内のすべての MCP サーバーの機能を集約する単一の MCP エンドポイントになります。クライアントは、20 個の個別接続を管理する代わりに、統一されたツールカタログ、プロンプトライブラリ、リソース名前空間を 1 つだけ見ます。内部的には、AgentCore Gateway はツール、プロンプト、リソースの 3 つの MCP プリミティブすべてをサポートしています。MCP のツール定義には、期待される出力構造を定義するオプションの outputSchema と、ツールが読み取り専用か破壊的かを説明するアノテーションが含まれ、標準の名前、アイコン、説明、inputSchema とともに提供されます。ゲートウェイは、プロンプトとリソースも、完全な MCP メソッドセット(tools/list、tools/call、prompts/list、prompts/get、resources/list、resources/read、resources/templates/list)を通じてサポートします。次のアーキテクチャ図は、AgentCore Gateway がリスト呼び出しと呼び出し操作をどのように促進するかを示しています。
デフォルトのリスティングモードでは、AgentCore Gateway は接続された MCP サーバーターゲットからのツール、プロンプト、リソースを発見してキャッシュします。このキャッシュは、CreateGatewayTarget または UpdateGatewayTarget を呼び出すたびに暗黙的にリフレッシュされ、SynchronizeGatewayTargets API を使用して明示的にリフレッシュできます。クライアントが tools/list、prompts/list、resources/list などのリスト呼び出しを行うと、AgentCore Gateway は MCP サーバーターゲットを呼び出さずに、このキャッシュから直接応答を返します。MCP サーバーターゲットとの実際の対話は、tools/call、prompts/get、resources/read などの呼び出し操作時にのみ発生します。その時点で、AgentCore Gateway はリクエストを正しいターゲットにルーティングします。
AgentCore Gateway によって返されるツールとプロンプトには、targetName___ 形式のターゲット名プレフィックスが付加されます。ツールやプロンプトとは異なり、リソース URI はターゲット名プレフィックスなしで返され、ダウンストリーム MCP サーバーからの元の URI がそのまま渡されます。リソースを公開する MCP サーバーターゲットを作成する際、複数のターゲットが同じリソース URI を公開する場合に AgentCore Gateway が競合を解決する方法を制御するために、resourcePriority 値(1~1000)をオプションで指定できます。優先度が定義されていない場合、デフォルト値 1000 が適用されます。競合が発生すると、AgentCore Gateway は最も低い resourcePriority 値を持つターゲットからのリソースを返します。2 つの競合するリソースが同じ優先度を持つ場合、最初に同期されたターゲットからのリソースが返されます。
リソース URI はダウンストリーム MCP サーバーターゲットによって提供され、AgentCore Gateway によって検証またはサニタイズされないため、信頼できないターゲットには注意してください。悪意のあるまたは侵害された MCP サーバーは、内部エンドポイントやローカルファイルシステムパスを指す URI を返す可能性があります。リソース URI をたどる前に検証およびサニタイズし、信頼できない MCP サーバーターゲットからの URI を自動的に取得またはレンダリングしないでください。
ランタイムの柔軟性のための動的リスティング
一部の MCP サーバーは、ユーザーごとに機能をパーソナライズします。権限認識サーバーは、approve_expense をマネージャーのみに公開するかもしれません。また、マルチテナントサーバーは、医療保険の相互運用性と説明責任に関する法律(HIPAA)準拠のツールを医療顧客のみに公開するかもしれません。動的リスティングを使用すると、AgentCore Gateway を経由しながらも、サーバー側のアクセス制御を維持できます。
ターゲットを作成する際、デフォルトと動的の 2 つのリスティングモードから選択できます。デフォルトリスティングモードでは、AgentCore Gateway は CreateGatewayTarget または UpdateGatewayTarget 操作中に MCP サーバーを呼び出して、ツール、プロンプト、リソースを発見してキャッシュします。このキャッシュは、SynchronizeGatewayTargets API を使用して明示的にリフレッシュできます。クライアントがリスト呼び出しを行うと、AgentCore Gateway はバックエンドサーバーに問い合わせることなく、このキャッシュから直接応答を提供します。動的リスティングモードでは、AgentCore Gateway は CreateGatewayTarget または UpdateGatewayTarget 操作中に MCP サーバーを呼び出しません。代わりに、リスト呼び出しはリクエスト時に呼び出し元ユーザーの ID を使用して、ライブで MCP サーバーに転送されます。両方のモードで、tools/call、prompts/get、resources/read などの呼び出し操作は、MCP サーバーターゲットに直接ルーティングされます。次のアーキテクチャ図は、両方のモードがどのように連携するかを示しています。
MCP サーバー 1 は動的リスティングモードで構成され、MCP サーバー 2 と 3 はデフォルトリスティングモードを使用します。AgentCore Gateway キャッシュには、デフォルトモードサーバーからの機能のみが含まれます。リスト呼び出し中、応答はページネーションされます。キャッシュされたプリミティブと MCP サーバー 1 のプリミティブは異なるページで返されます。動的リスティングターゲットのプリミティブは AgentCore Gateway でインデックス化されていないため、セマンティックツール検索機能は使用できません。
このデュアルモードアーキテクチャは、マルチテナンシーと細かいアクセス制御(FGAC)の柔軟性も提供します。両方のリスティングモードで、AgentCore Policy または AWS Lambda レスポンスインターセプターを使用してポリシーを集中施行し、テナント ID に基づいて機能をフィルタリングできます。例えば、テナントが読み取り専用ツールのみを表示するように制限できます。動的リスティングモードでは、リスト操作がエンドユーザーの ID で実行され、MCP サーバーターゲットがそのユーザーがアクセスを許可された機能のみを返すため、MCP サーバー自体で直接アクセス制御を管理できます。
ストリーミング、セッション管理、エリシテーション
多くのエンタープライズ MCP ワークフローは、単純なリクエスト-レスポンスのツール呼び出しを超えています。MCP サーバーは、レポート生成中に進行状況の更新をストリーミングしたり、機密アクションを実行する前にユーザーの承認を求めて一時停止したり、複数のツール呼び出しにわたるマルチステップ会話のコンテキストを維持したりする必要があるかもしれません。AgentCore Gateway は、Streamable HTTP トランスポート、MCP セッション管理、およびエリシテーションをサポートし、ステートフルでリアルタイムなヒューマンインザループ対話を可能にします。
Streamable HTTP
ストリーミングがない場合、45 秒かかるツール呼び出しは完了するまで何も返さず、ユーザーはスピナーを見つめるだけです。ストリーミングがあれば、進行状況イベントをリアルタイムで確認できます。クライアントが Accept: application/json, text/event-stream を含む tools/call リクエストを送信すると、AgentCore Gateway は SSE ストリームを開き、進行状況通知、ログメッセージ、最終的なツール結果を含むイベントを MCP サーバーターゲットからリアルタイムで転送します。Accept: application/json のみを送信するクライアントは、完全な後方互換性を維持しながら、単一の JSON 応答を受け取り続けます。
AgentCore Gateway で応答ストリーミングが有効になっている場合、レスポンスインターセプターの動作が変わり、gatewayResponse の isStreamingResponse フィールドをチェックして、ストリーミング応答と非ストリーミング応答を区別する必要があります。レスポンスインターセプターは、JSON-RPC id フィールドを含むイベントに対して呼び出されます。レスポンスインターセプターは、notifications/progress、notifications/message、pings に対しては呼び出されません。ストリーミングを有効にするには、CreateGateway または UpdateGateway API 呼び出しで enableResponseStreaming ブロックを設定します。
"protocolConfiguration": { "mcp": { "streamingConfiguration": { "enableResponseStreaming": true } } }
AgentCore Gateway でストリーミングユースケースを検討する際は、以下の点に留意してください。AgentCore Gateway は、ストリーム内の最初のイベントから HTTP ステータスコードを決定します。ストリームの途中でエラーが発生した場合、ステータスはすでに送信されているため、HTTP ステータスコードではなく、SSE フレーム内の JSON-RPC エラーオブジェクトとして配信されます。ストリーム前のエラー(認証失敗、スロットリング、検証エラーなど)は、標準の JSON-RPC エラー応答として返され、SSE フレーミングは行われません。
セッション管理
セッション管理は、AgentCore Gateway にステートフルなマルチターンワークフローを導入します。セッションを有効にすると、AgentCore Gateway は最初の initialize リクエスト時に Mcp-Session-Id を生成し、それを応答ヘッダーとして返します。クライアントは後続のリクエストにこのヘッダーを含めることで、AgentCore Gateway がクライアントの対話を追跡し、ダウンストリーム MCP サーバーセッションへのマッピングを維持し、ツール呼び出し間でエリシテーションリクエストを関連付けることができるようになります。
セッションを有効にするには、CreateGateway または UpdateGateway API 呼び出しで sessionConfiguration ブロックを追加します。セッションタイムアウトは、最小 15 分から最大 8 時間まで設定できます。デフォルトは 1 時間です。
"protocolConfiguration": { "mcp": { "sessionConfiguration": { "sessionTimeoutInSeconds": 3600 } } }
セッションは認証されたユーザーにスコープされます。AgentCore Gateway は、認可コンテキスト、OAuth イングレスの JWT ベアラートークン、または AWS_IAM イングレスの IAM 資格情報からユーザー ID を導出し、セッション内のすべてのリクエストが同じユーザーから発信されていることを検証します。これはセッションハイジャックの防止に役立ちます。