Amazon Bedrock AgentCore ランタイムターゲット
Amazon Bedrock AgentCore ランタイムエージェントをゲートウェイターゲットとして追加できます。ゲートウェイは、集約やプロトコル変換を行うことなく、トラフィックをランタイムエージェントに直接送信します。ツール機能を統合仮想 MCP サーバーに結合する MCP ターゲットとは異なり、AgentCore ランタイムターゲットは、クライアントとランタイムエージェントの間でリクエストとレスポンスを変更せずに転送します。
AgentCore ランタイムターゲットをゲートウェイに追加すると、次の場合に便利です。
-
単一のゲートウェイエンドポイントを通じて、ランタイムエージェントの一元的なアクセス管理を提供します。
-
ランタイムエージェントには、ゲートウェイの組み込み認証とオブザーバビリティを使用します。
-
複数のターゲットがゲートウェイにアタッチされている場合、パスベースのルーティングを使用して特定のランタイムエージェントにリクエストをルーティングします。
-
Amazon Bedrock AgentCore 最適化を使用して、エージェントトレースからのレコメンデーションを生成し、ゲートウェイを介したライブトラフィックによる A/B テストの変更を生成して、エージェントのパフォーマンスを最適化し、成功した設定をデプロイします。詳細については、AgentCore 最適化」を参照してください。
主な考慮事項と制限事項
AgentCore ランタイムターゲットを使用する場合は、次の考慮事項に注意してください。
-
ゲートウェイは、機能を集約せずに AgentCore ランタイムターゲットに直接トラフィックを送信します。
-
AgentCore ランタイムターゲットは、プロトコルタイプが設定されていないゲートウェイに追加できます。MCP プロトコルタイプゲートウェイに追加することはできません。
-
AgentCore ランタイムターゲットでは、機能同期やセマンティックツール検索は使用できません。クライアントは、パスベースのルーティングを通じて各ターゲットに個別に対応する必要があります。
-
サーバー送信イベント (SSE) ストリーミングは、AgentCore ランタイムターゲットでサポートされています。
-
リクエストとレスポンスのインターセプター Lambda 関数は、バッファモードでサポートされています。インターセプターはストリーミングモードではまだサポートされていません。
ターゲット設定
AgentCore ランタイムターゲットを作成するときは、ランタイム ARN とオプションの修飾子を指定します。ゲートウェイはランタイムエンドポイントを内部で解決するため、ランタイム URL を自分で構築する必要はありません。
AgentCore ランタイムターゲットのターゲット設定では、次の構造を使用します。
{ "http": { "agentcoreRuntime": { "arn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID", "qualifier": "DEFAULT", "schema": { "source": { "s3": { "uri": "s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml" } } } } } }
-
arn (必須) – Amazon Bedrock AgentCore ランタイムエージェントの ARN。
-
修飾子 (オプション) – ランタイム修飾子。デフォルトは
DEFAULTです。 -
スキーマ (オプション) – ランタイムターゲットのリクエストとレスポンスの構造を記述する API スキーマ。ゲートウェイはこのスキーマを使用して、ガードレールなどのポリシーエンジン機能を有効にします。スキーマ形式は OpenAPI または Smithy として自動検出されます。
MCP または A2A プロトコルを使用するランタイムエージェントの場合、デフォルトのスキーマが自動的に適用されるため、スキーマを指定する必要はありません。HTTP プロトコルを使用するランタイムエージェントの場合、ガードレールを使用するためのスキーマを指定する必要があります。
schemaオブジェクトには、スキーマコンテンツの場所sourceを指定する が含まれています。-
s3 – スキーマファイルを指す S3 URI (例:
s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml)。 -
inlinePayload – 文字列として直接提供されるスキーマコンテンツ。
-
注記
ランタイムエージェントが HTTP プロトコルを使用していて、ゲートウェイのポリシーエンジンを介してガードレールを適用する場合は、スキーマを指定する必要があります。MCP または A2A プロトコルを使用するランタイムエージェントの場合、デフォルトのスキーマが自動的に適用されます。
AgentCore ランタイムターゲットの呼び出し
ゲートウェイを介して AgentCore ランタイムターゲットを呼び出すには、ターゲットの呼び出し URL に POST リクエストを送信します。URL 形式は次のとおりです。
https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/invocations
{gatewayId} をゲートウェイ ID、 {region} を AWS リージョン、 をターゲットの名前{targetName}に置き換えます。
次の例では、curl を使用して AgentCore ランタイムターゲットを呼び出します。
curl -X POST https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target/invocations \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"input": {"prompt": "Hello"}}'
エンドポイント URL オーバーライドで Amazon Bedrock AgentCore SDK を使用することもできます。
aws bedrock-agentcore invoke-agent-runtime \ --endpoint-url https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target \ --runtimeArn arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID
アウトバウンド認可
AgentCore ランタイムターゲットは、次のアウトバウンド認可タイプをサポートしています。
-
IAM (SigV4) – ゲートウェイはゲートウェイサービスロールを引き受けて、ランタイムターゲットへのリクエストに署名するための認証情報を取得します。IAM 認可を設定するときは、IAM ポリシーを使用してゲートウェイロールのみへのアクセスを制限し、すべてのランタイムリクエストがゲートウェイを流れるようにすることができます。
-
発信者 IAM 認証情報 – ゲートウェイは、発信者の IAM 認証情報を使用してランタイムターゲットへのリクエストに署名します。ゲートウェイは発信者に代わってロールを引き受け、発信者の ID を使用してアウトバウンドリクエストに署名します。
-
OAuth (JWT) – ゲートウェイは、Amazon Bedrock AgentCore ID サービスを介してターゲットで設定された認証情報プロバイダーから OAuth トークンを取得します。
-
トークンパススルー – ゲートウェイはインバウンドトークンを検証し、変更せずにランタイムターゲットに渡します。これは、ランタイムが独自の認可を処理する場合に便利です。
ゲートウェイを介したトラフィックの強制
AgentCore ランタイムを AgentCore Gateway でフロントして、ゲートウェイがランタイムへの単一の管理エントリポイントになるようにできます。これにより、ポリシーベースの認可、Amazon Bedrock ガードレール、リクエストとレスポンスのインターセプター、統合オブザーバビリティが提供され、すべてエージェント独自の環境外で適用されます。完全な理論的根拠については、「Front your runtime with an AgentCore Gateway」を参照してください。ただし、ゲートウェイをバイパスしてランタイムに直接アクセスできない場合にのみ便利です。ランタイムが IAM (SigV4) または OAuth (JWT) のインバウンド認可を使用しているかどうかに関係なく、これを実現できるようになりました。
この制限はランタイムに設定できます。ゲートウェイは転送するすべてのリクエストのソースをスタンプし、ランタイムはそのソースを途中で検証します。特定のメカニズムは、ランタイムのインバウンド認可タイプによって異なります。
-
IAM (SigV4) ランタイム – ゲートウェイの実行ロールへの呼び出しを制限するリソースベースのポリシーをアタッチします。ポリシーとそれに必要な信頼ポリシーの強化については、「ゲートウェイへの IAM (SigV4) インバウンド呼び出しの制限」を参照してください。
-
OAuth (JWT) ランタイム – ゲートウェイのワークロードのみを許可する
customJWTAuthorizerようにランタイムのallowedWorkloadConfigurationで を設定します。設定とフィールドリファレンスについては、「ゲートウェイへの呼び出しの制限」を参照してください。
MCP ターゲットとの機能の比較
MCP サーバーを Amazon Bedrock AgentCore ゲートウェイと統合するには、集約モードで MCP ターゲットタイプを使用するか、AgentCore ランタイムターゲットタイプを使用します。次の表は、各アプローチの機能を比較したものです。
| 機能 | MCP ターゲットを持つ MCP ゲートウェイ | AgentCore ランタイムターゲット |
|---|---|---|
|
ツール/機能集約 |
すべての MCP ターゲットの機能を 1 つの統合仮想 MCP サーバーに集約します。クライアントには 1 つの統合 |
単独で動作します。ゲートウェイは、機能をマージせずにトラフィックをターゲットに直接送信します。クライアントは、パスベースのルーティングを通じて各ターゲットに個別に対応する必要があります。 |
|
セマンティックツール検索 |
ツールの説明をインデックス化し、自然言語クエリによる検出を可能にします。 |
利用できません。ゲートウェイは機能を取り込んだりインデックスを作成したりしません。クライアントは正確なツール名を知っているか、サーバー独自の を使用する必要があります |
|
レスポンスインターセプター Lambda |
非ストリーミング MCP オペレーションのリクエストインターセプターとレスポンスインターセプターの両方をサポートします。 |
バッファモードでリクエストインターセプター Lambda 関数とレスポンスインターセプター Lambda 関数の両方をサポートします。インターセプターはストリーミングモードではまだサポートされていません。 |