翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
MCP サーバーターゲット
MCP サーバーは、Bedrock AgentCore でモデルやエージェントとやり取りするためのローカルツール、データアクセス、またはカスタム関数を提供します。Bedrock AgentCore では、ゲートウェイの作成時に事前設定された MCP サーバーをターゲットとして定義できます。
MCP サーバーは、エージェントが検出して使用できるツール、プロンプト、リソースをホストします。Bedrock AgentCore では、ゲートウェイを使用してターゲットをこれらの機能に関連付け、エージェントランタイムに接続します。プロトコルハンドシェイクを実行し、使用可能な機能にインデックスを作成する SynchronizeGatewayTargets API を使用して、外部 MCP サーバーに接続します。MCP サーバーのインストールと使用の詳細については、「Amazon Bedrock AgentCore MCP Server: Vibe coding with your coding Assistant」を参照してください。
主な考慮事項と制限事項
一覧表示モード
ListingMode は、MCP サーバーターゲットの DYNAMIC または DEFAULT として設定できます。
-
DYNAMIC モードでは、ユーザーが MCP オペレーションを呼び出すと、クライアントは MCP サーバー機能を検出します。Gateway は、リクエストを MCP サーバーに転送することでサーバー機能を取得します。現在、DYNAMIC モードはセマンティック検索またはアウトバウンドの 3 レッグ OAuth (3LO) と相互運用できません。
-
変更されていない限り、リストモードは DEFAULT に設定されます。DEFAULT モードでは、クライアントは SynchronizeGatewayTargets API が提供する同期オペレーションを通じて MCP サーバー機能を検出します。
暗黙的な同期
DEFAULT モードのターゲットの場合、CreateGatewayTarget オペレーションと UpdateGatewayTarget オペレーションによって、機能検出とインデックス作成が自動的にトリガーされます。いずれかのオペレーションが呼び出されると、Gateway は MCP tools/listの機能を使用して使用可能なツールを取得し、 を使用してプロンプトを表示しprompts/list、 resources/listと を使用してリソースを取得しresources/templates/list、返された機能を統合カタログに追加します。
明示的な同期
DEFAULT モードのターゲットの 機能カタログは、 SynchronizeGatewayTargets API を呼び出して手動で更新できます。呼び出されると、ゲートウェイの使用可能な機能のリストが更新されます。MCP サーバーのツール、プロンプト、リソース定義が変更されるたびに API を呼び出す必要があります。
同期は、MCP サーバーを統合するときに正確な機能カタログを維持するための重要なメカニズムです。暗黙的な同期はターゲットの作成時と更新時に自動的に行われ、Gateway は MCP サーバーからツール、プロンプト、リソースを即座に検出してインデックスを作成し、セマンティック検索と統合出品に機能を利用できるようにします。明示的な同期は SynchronizeGatewayTargets API を介してオンデマンドで実行されるため、MCP サーバーが個別に機能を変更するときに MCP 機能カタログを検出できます。
SynchronizeGatewayTargets を呼び出すタイミング
MCP サーバーターゲットのリスト化モードが DEFAULT に設定されている場合は、ツール、プロンプト、またはリソースを追加、削除、または変更した後に SynchronizeGatewayTargets API を使用します。Gateway はセマンティック検索用のベクトル埋め込みを事前計算し、正規化された機能カタログを維持するため、ユーザーが利用可能な最新のツール、プロンプト、リソースを検出して呼び出すことができるように同期する必要があります。
API を呼び出す方法
/gateways/ { gatewayIdentifier}/synchronize に PUT リクエストを実行します。API はすぐに 202 レスポンスを返し、同期を非同期的に処理します。GetGatewayTarget を使用してターゲットステータスをモニタリングし、同期の進行状況を追跡します。大規模な機能セットではオペレーションに数分かかる可能性があるためです。
認可戦略
次のタイプの認可戦略がサポートされています。
-
認可なし – ゲートウェイは、事前設定された認可なしで MCP サーバーを呼び出します。このアプローチはお勧めしません。
-
OAuth – ゲートウェイは、2 本レッグの OAuth (
CLIENT_CREDENTIALSグラントタイプ)、3 本レッグの OAuth (AUTHORIZATION_CODEグラントタイプ)、およびトークン交換on-behalf-of (TOKEN_EXCHANGEグラントタイプ) をサポートしています。ゲートウェイが同じアカウントとリージョンの Amazon Bedrock AgentCore Identity で認可プロバイダーを設定して、MCP サーバーを呼び出します。トークン交換on-behalf-ofを使用する場合は、このターゲットタイプのトークン交換on-behalf-ofに関する考慮事項を確認してください。 -
IAM ( AWS 署名バージョン 4 (Sig V4) ) – ゲートウェイは、ゲートウェイサービスロールの認証情報を使用して SigV4 を使用して MCP サーバーへのリクエストに署名します。SigV4 署名に必要なサービス名とオプションのリージョン (デフォルトはゲートウェイリージョン)
IamCredentialProviderで を設定します。 -
API キー – ゲートウェイは API キー認証情報プロバイダーを使用して MCP サーバーで認証します。Amazon Bedrock AgentCore Identity の API キープロバイダーは、ゲートウェイと同じアカウントとリージョンで設定します。
重要
IAM (SigV4) アウトバウンド認可では、MCP サーバーが IAM 認証をネイティブにサポートする AWS サービスの背後でホストされている必要があります。ゲートウェイは SigV4 を使用してアウトバウンドリクエストに署名しますが、ターゲットの認証設定を変更しません。ターゲットサービスは SigV4 署名を検証できる必要があります。
以下の AWS サービスは IAM 認証をネイティブにサポートし、MCP サーバーターゲットの IAM アウトバウンド認可と互換性があります。
-
Amazon Bedrock AgentCore Gateway
-
Amazon Bedrock AgentCore ランタイム (AgentCore ランタイムに MCP サーバーをデプロイする」を参照)
-
Amazon API Gateway
-
Lambda 関数 URLs
Application Load Balancer や直接 Amazon EC2 エンドポイントなど、SigV4 署名をネイティブに検証しないサービスは、IAM アウトバウンド認可と互換性がありません。MCP サーバーがこれらのサービスのいずれかの背後でホストされている場合は、代わりに OAuth または API キー認可を使用します。
MCP サーバーターゲットの設定に関する考慮事項
以下を設定する必要があります。
-
MCP サーバーにはツール機能が必要です。プロンプトとリソース機能はオプションであり、サーバーがそれらをアドバタイズすると自動的に同期されます。
-
サポートされている MCP プロトコルバージョンは - 2026-07-28 、2025-11-25 、2025-06-18 および 2025-03-26 です。
-
サーバーの指定された URL/エンドポイントについては、URL をエンコードする必要があります。Gateway は同じ URL を使用してサーバーを呼び出します。
注記
MCP バージョンの更新が有効になっているアカウントでは、 UpdateGatewayオペレーションを使用してゲートウェイでサポートされているプロトコルバージョンを変更できます。それ以外の場合、ゲートウェイの作成時にサポートされているバージョンが修正されます。
ヒント
MCP サーバーが AgentCore ランタイムでホストされている場合、各リクエストで MCP サーバーによる反復初期化を回避できます。ゲートウェイで MCP セッションを有効にするか、ターゲットの で許可されたリクエストおよびレスポンスヘッダーMcp-Session-Idとして を追加しますmetadataConfiguration。これにより、後続のツール呼び出しのレイテンシーが低くなります。このガイダンスは、 バージョン 2025-11-25 以前に適用されます。バージョン2026-07-28はステートレスで、 Mcp-Session-Idヘッダーを使用しません。
トークン交換On-behalf-of考慮事項
MCP サーバーターゲットon-behalf-ofトークン交換 (TOKEN_EXCHANGEグラントタイプ) を使用する場合、次の制限が適用されます。
-
2LO をサポートする認可サーバー – 認可サーバーでmachine-to-machine認証 (2 レッグ OAuth とも呼ばれる
CLIENT_CREDENTIALS許可) が許可されている場合は、DEFAULT 出品モードを使用できます。DEFAULT 出品モードでは、ゲートウェイはCreateGatewayTarget、、および の間にバックグラウンド同期を実行して MCPSynchronizeGatewayTargetsサーバーのツール ( を使用tools/list)UpdateGatewayTarget、プロンプト、リソースを取得します。これらのコントロールプレーンオペレーション中にインバウンドユーザートークンが存在しないため、同期ではトークン交換on-behalf-ofmachine-to-machineトークンが使用されます。 -
2LO サポートのない認可サーバー – 認可サーバーがmachine-to-machine認証をサポートしていない場合は、代わりに DYNAMIC リストモードを使用します。DYNAMIC モードでは、ゲートウェイは呼び出し時に MCP サーバーの機能を検出します。インバウンドユーザートークンが存在し、その時点で交換できるため、ゲートウェイはコントロールプレーンのバックグラウンド同期を必要としません。
誘発とサンプリングのリクエスト状態を保護する (バージョン 2026-07-28 以降)
バージョン 2026-07-28以降では、誘発とサンプリングはマルチラウンドトリップリクエスト (MRTR) パターンを使用します。MCP サーバーターゲットはinput_required結果に requestState値を生成します。ゲートウェイはこの値を不透明として扱います。ゲートウェイは を保存しませんrequestState。この値は、クライアントと MCP サーバーターゲット間で変更せずに転送する間のみメモリに保持され、リクエストが完了すると破棄されます。
AgentCore Gateway と MCP サーバーターゲットは、リクエスト状態を保護する責任を共有します。
-
AgentCore Gateway は、 を実行する再試行など、ゲートウェイのインバウンド認可設定に対してすべてのリクエストを認証および認可します
requestState。ゲートウェイに対して認証できない発信者は、リクエスト状態をまったく提示できません。詳細については、「ゲートウェイのインバウンド認可を設定する」を参照してください。 -
MCP サーバーターゲットは、
requestState受信した を検証する責任があります。これは、値がクライアントを往復するためです。MCP 仕様では、サーバーはクライアントを信頼できない仲介者として扱い、常にリクエストの状態を検証する必要があります。状態が元のユーザーに固有のデータを含む場合、仕様ではサーバーがそのデータをユーザーに暗号化的にバインドする必要があります。再試行時に、サーバーは状態が現在認証されているユーザーに属していることを確認する必要があります。ゲートウェイは、 を提示する発信者requestStateがそれを受信した発信者と同じであることを検証しません。あるユーザーが別のユーザーのリクエスト状態を再生できないようにすることは、ユーザーの MCP サーバーの責任です。
リクエストの状態を保護するには、MCP 仕様のガイダンスに従ってください。状態 (AES-GCM や署名付き JWT など) を暗号化または署名して、機密性と整合性を確保します。ユーザー固有の状態を元のユーザーにバインドし、状態を期限切れにし、プレーンテキストの状態値を信頼できない入力として扱います。詳細については、Model Context Protocol ウェブサイトの「マルチ往復リクエスト
認可コードフローを使用した OAuth で保護された MCP サーバーへの接続
MCP サーバーターゲットで認可コード付与タイプ (3 レッグの OAuth) をサポートするために、Amazon Bedrock AgentCore Gateway にはターゲット作成のための 2 つの方法が用意されています。
MCP サーバーターゲットの作成中の暗黙的な同期
この方法では、管理者ユーザーは、レスポンスで返された認可 URL CreateGatewayTarget を使用して、、、または UpdateGatewayTarget SynchronizeGatewayTargetsオペレーション中に認可コードフローを完了します。これにより、Amazon Bedrock AgentCore Gateway は MCP サーバーのツールを事前に検出してキャッシュできます。
注記
承認保留中の状態 (、、または CREATE_PENDING_AUTH ) UPDATE_PENDING_AUTH のターゲットを削除、更新、または同期することはできませんSYNCHRONIZE_PENDING_AUTH。認可が完了または失敗するのを待ってから、ターゲットに対して追加のオペレーションを実行します。
MCP サーバーターゲットの作成時にスキーマを事前に指定する
この方法では、管理者ユーザーは Amazon Bedrock AgentCore Gateway が MCP サーバーから動的に取得するのではなく、 CreateGatewayTarget または UpdateGatewayTargetオペレーション中に mcpToolSchemaフィールドを使用してツールスキーマを直接提供します。Amazon Bedrock AgentCore Gateway は、提供されたスキーマを解析し、ツール定義をキャッシュします。
注記
静的ツールスキーマ (mcpToolSchema) が設定されたターゲットを同期することはできません。UpdateGatewayTarget 呼び出しを通じて静的スキーマを削除し、動的ツール同期を有効にします。
URL セッションのバインド
OAuth 2.0 認可 URL セッションバインディングは、OAuth 認可リクエストを開始したユーザーが、同意を付与したユーザーと同じであることを確認します。ユーザーが同意を完了すると、ブラウザは一意のセッション URI を使用してターゲットに設定された戻り URL にリダイレクトします。その後、アプリケーションは CompleteResourceTokenAuth API を呼び出し、ユーザーの ID とセッション URI の両方を提示します。Amazon Bedrock AgentCore Identity は、フローを開始したユーザーが、アクセストークンの認可コードを交換する前にフローを完了したのと同じユーザーであることを検証します。
これにより、ユーザーが誤って承認 URL を共有し、他のユーザーが同意を完了して、アクセストークンを間違った相手に付与するシナリオを防ぐことができます。認可 URL とセッション URI は 10 分間のみ有効で、誤用のウィンドウがさらに制限されます。セッションバインディングは、ターゲットの作成時 (暗黙的な同期) およびツールの呼び出し時に適用されます。
注記
AWS マネジメントコンソールを使用してターゲットオペレーション (作成、更新、または同期) と認可を実行すると、リソース所有者に代わって CompleteResourceTokenAuth 呼び出しが実行され、認可後にそれ以上のアクションは必要ありません。
許可を設定する
MCP サーバーターゲットの作成、更新、または同期に使用する IAM ロールには、次の例に示すアクセス許可が必要です。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateGateway", "bedrock-agentcore:GetGateway", "bedrock-agentcore:CreateGatewayTarget", "bedrock-agentcore:GetGatewayTarget", "bedrock-agentcore:SynchronizeGatewayTargets", "bedrock-agentcore:UpdateGatewayTarget" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" }, { "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateWorkloadIdentity", "bedrock-agentcore:GetWorkloadAccessToken", "bedrock-agentcore:GetWorkloadAccessTokenForUserId", "bedrock-agentcore:GetResourceOauth2Token", "bedrock-agentcore:GetResourceApiKey", "bedrock-agentcore:CompleteResourceTokenAuth", "secretsmanager:GetSecretValue" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:EnableKeyRotation", "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*", "kms:ReEncrypt*", "kms:CreateAlias", "kms:DisableKey", "kms:*" ], "Resource": "arn:aws:kms:*:123456789012:key/*" } ] }