--- title: "AgentCore Gatewayと AgentCore APIの使い方：InvokeModel対応・フォールバック設定とSDK・CLIでの本番デプロイ" url: "https://www.issoh.co.jp/tech/details/8230/" published: 2025-08-15 updated: 2026-10-24 categories: ["AWS"] publisher: "株式会社一創" --- # AgentCore Gatewayと AgentCore APIの使い方：InvokeModel対応・フォールバック設定とSDK・CLIでの本番デプロイ Amazon Bedrock AgentCoreは、任意のフレームワークとモデルで作ったAIエージェントを、サーバー管理なしで本番運用するためのAWSのマネージド基盤です。2025年7月のプレビュー公開を経て、**2025年10月13日に一般提供（GA）**となり、VPC・AWS PrivateLink・CloudFormation・リソースタグに対応しました。この記事は「AgentCore API」で調べる開発者に向けて、エージェントを操作する3つの入口（SDK・CLI・InvokeAgentRuntime API）の実コードを中心にまとめます。あわせて、**2026年10月22日に追加されたAgentCore GatewayのInvokeModel対応とモデルフォールバック**の設定例、Runtime・Gateway・Memoryなど主要コンポーネントの使いどころ、従量課金の料金、Bedrock Agentsとの違いまで、公式ドキュメントの一次情報で確認できます。 ## まとめ：AgentCore APIとGatewayを触る前に押さえる5つの要点 - **AgentCoreは「コードは自分で書く、インフラはAWSが持つ」基盤**。フルマネージドで設定中心のBedrock Agentsとは役割が違う。 - エージェントの入口は3つ。**①ランタイム化する`bedrock-agentcore` SDK（Python）**、**②雛形生成〜デプロイを担う`@aws/agentcore` CLI（npm）**、**③外部から呼び出す`InvokeAgentRuntime` API（boto3等のAWS SDK）**。 - **AgentCore Gatewayは2026年10月22日から推論の入口も兼ねる**。boto3の`bedrock-runtime`クライアントの`endpoint_url`をGatewayへ向けるだけで、既存の`InvokeModel`呼び出しを通せる。 - Gatewayのルールに最大2つの代替先を並べると、429・5XX・初回バイトタイムアウトなどでモデルやプロバイダーを自動で切り替える。ただし試行1回ごとにGateway呼び出しとして課金される。 - 料金はコンポーネント単位の従量課金。Runtimeはv1が1 vCPU時0.0895ドル、v2の消費型が1 vCPU時0.1276ドル（2026年10月24日時点）。旧`bedrock-agentcore-starter-toolkit`はレガシー扱いで、新規は`@aws/agentcore` CLIを使う。 ## AgentCoreとは：GAした本番エージェント基盤の構成と役割分担 AgentCoreは、エージェントの実行環境・セッション隔離・メモリ・ツール接続・認証・可観測性といった「本番で必要になる周辺機能」を個別のマネージドサービスとして提供します。特定のエージェントフレームワークやモデルに縛られず、開発者は**エージェント本体のコードだけを書けばよい**のが設計思想です。GAに伴い、すべてのサービスがVPC・PrivateLink・CloudFormation・タグに対応し、本番のガバナンス要件に載せやすくなりました。 ### AgentCoreを構成する7つのマネージドサービスと各サービスの役割 | コンポーネント | 役割 | | ----------------------- | ------------------------- | | AgentCore Runtime | サーバーレス実行基盤。隔離・長時間実行に対応 | | AgentCore Memory | 会話の短期メモリと、事実・嗜好を抽出する長期メモリ | | AgentCore Gateway | API・LambdaのMCP化と推論窓口 | | AgentCore Identity | 受信認証と外部サービスへの送信認証を仲介する | | AgentCore Observability | 実行状況の追跡・監視 | | Code Interpreter | 隔離サンドボックスでコードを実行する組み込みツール | | Browser Tool | エージェントにWeb操作をさせる組み込みツール | Runtimeはエージェントを動かす基盤で、セッションを隔離して長時間実行に対応します。Gatewayは既存APIやLambdaをMCPツールとして公開し、推論の入口も担う構成です。ObservabilityではCloudWatchとOpenTelemetryを使い、エージェントの実行状況を追跡します。 GA後は上記に加え、品質評価のEvaluations、x402マイクロ決済のPayments、認可制御のPolicy、エージェントの社内カタログであるAWS Agent Registryなども料金表に並び、[公式の料金ページ](https://aws.amazon.com/bedrock/agentcore/pricing/)では2026年10月24日時点で13の機能が掲載されています。各コンポーネントは単体でも組み合わせても使え、Runtimeを使わず既存のエージェントからMemoryやGatewayだけを呼ぶ構成も可能です。RuntimeやGatewayで公開したエージェントとMCPサーバーを社内カタログに登録し、承認済みのものだけを検索させる仕組みは[AWS Agent Registryとは：MCPとエージェントの社内カタログを作る手順と料金](https://www.issoh.co.jp/tech/details/18240/)で解説しています。 ### Bedrock AgentsとAgentCoreの違い：設定中心かコード中心かの選び方 「bedrock agents agentcore 違い」で検索する人が最初に迷うのがこの2つの棲み分けです。結論から言うと、**コードを書かずに設定で完結させたいならBedrock Agents、任意のフレームワークで書いたエージェントを本番に載せたいならAgentCore**です。両者は競合する製品としてではなく、抽象度の違う選択肢として比較してください。 | 観点 | Bedrock Agents | AgentCore | | --------- | -------------- | ------------------------- | | 作り方 | コンソールやAPIで設定 | フレームワークでコードを記述 | | エージェントループ | AWSが実行 | 自分のコードが実行 | | フレームワーク | Bedrock独自 | Strands・LangGraph・CrewAI等 | | 向く用途 | ナレッジベース連携の定型処理 | 独自ロジック・既存資産の本番化 | すでにLangGraphやStrandsでエージェントを組んでいるなら、作り直さずAgentCore Runtimeに載せられるため移行コストは小さくなります。逆に、要件が「社内ドキュメントに答えるQ&Aボット」程度で内製工数を割きたくないなら、Bedrock Agentsのほうが早い。コードを書かずに業務担当者がエージェントを使う前提なら、[Amazon Quick（旧Quick Suite）の料金を全プラン比較](https://www.issoh.co.jp/tech/details/9643/)で扱ったSaaS型の選択肢もあります。フレームワークにこだわりがない小規模PoCでAgentCoreをフル装備すると、コンポーネント単位の課金が積み上がりがちなので注意してください。なお2026年7月30日以降、Bedrock Agentsは「Amazon Bedrock Agents Classic」としてメンテナンスモードに入り、過去12か月に利用実績のないAWSアカウントでは新規エージェントを作成できなくなりました。ループ制御を自前で持つ構成の扱いを含め、前提条件は[Bedrock Agentsのカスタムオーケストレーションとメンテナンスモードの影響](https://www.issoh.co.jp/tech/details/4482/)で整理しています。 ## AgentCore APIとSDKの全体像：開発フェーズ別に使う3つの入口 「AgentCore API」と一口に言っても、開発フェーズごとに触る対象が変わります。役割を混同するとドキュメントを探しても目的の手順にたどり着けないため、まず3つの入口を分けて理解します。 | 入口 | パッケージ | 用途 | | -------- | ------------------------- | ------------------- | | ランタイムSDK | bedrock-agentcore（PyPI） | 自作エージェントを本番用サーバーに包む | | 開発CLI | @aws/agentcore（npm） | 雛形生成・ローカル実行・デプロイ | | 実行API | bedrock-agentcore（boto3等） | デプロイ済みエージェントを呼び出す | ざっくり言えば、**SDKで「エージェントを載せる形」を作り、CLIで「AWSに配る」、APIで「アプリから叩く」**という流れです。管理系の操作（RuntimeやGatewayの作成・更新）は別クライアントの`bedrock-agentcore-control`が受け持ち、後述するGatewayのルール作成もこちらのAPIで行います。以下で順に実コードを示します。 ## bedrock-agentcore SDKでエージェントを本番用HTTPサーバー化する手順 PythonのランタイムSDK`bedrock-agentcore`は、自作のエージェント関数を、ヘルスチェックとストリーミングに対応した本番用HTTPサーバーに変換します。[PyPIの配布ページ](https://pypi.org/project/bedrock-agentcore/)で確認した2026年10月24日時点の最新は**1.25系（1.25.0、2026年10月23日公開）**で、Python 3.10以上が必要です。7月の1.18.0から3か月で7回のマイナー更新が入っているため、本番では版を固定し、更新時に動作確認を挟む運用をおすすめします。中核は`BedrockAgentCoreApp`クラスと`@app.entrypoint`デコレータの2つだけです。 ``` pip install "bedrock-agentcore==1.25.0" ``` ``` from bedrock_agentcore import BedrockAgentCoreApp from strands import Agent app = BedrockAgentCoreApp() agent = Agent() @app.entrypoint def invoke(payload): result = agent(payload.get("prompt")) return {"result": str(result)} if __name__ == "__main__": app.run() ``` `@app.entrypoint`を付けた関数が、リクエストを受け取る呼び出し口になります。`app.run()`はローカルでは既定でポート8080のサーバーを起動し、AgentCore Runtimeと同じHTTPプロトコルで動作を確認できる仕組みです。ストリーミング応答が必要なら、関数内で`return`ではなく`yield`でイベントを逐次返します。Runtimeの実行環境は**ARM64（AWS Graviton）**のため、コンテナビルドする場合はARM64向けにビルドする必要があります。 ## @aws/agentcore CLIでの雛形生成からデプロイと削除までの作業手順 デプロイと開発を担うのが`@aws/agentcore` CLIです。npmで配布され、2026年10月22日に1.0.0へ到達しました。Node.js 20.12以上とAWS CDKを前提に、内部でCloudFormationスタックを組み立ててRuntimeやIAMロールを作成します。旧`bedrock-agentcore-starter-toolkit`（`agentcore configure`／`agentcore launch`）はレガシーになったため、新規プロジェクトはこちらを使います。 ``` npm install -g @aws/agentcore agentcore create --name MyAgent --framework Strands --model-provider Bedrock --memory none cd MyAgent agentcore dev # ローカルで動作確認（http://localhost:8080） agentcore deploy # CDKでAWSにデプロイ agentcore invoke "Tell me a joke" # デプロイ済みエージェントを呼ぶ ``` `agentcore create`は対話ウィザードでも、フラグ指定でも雛形を生成できます。`--framework`は`Strands`／`LangChain_LangGraph`／`GoogleADK`／`OpenAIAgents`、`--protocol`は`HTTP`／`MCP`／`A2A`、`--memory`は`none`／`shortTerm`／`longAndShortTerm`から選ぶ方式です。デプロイ前に`agentcore deploy --dry-run`で差分を確認でき、片付けは`agentcore remove all`のあと再度`agentcore deploy`でリソースを削除します。1.0.0より前の版で作った雛形を流用する場合は、CLIを更新したあと`--dry-run`の差分を先に読み、意図しないリソースの作り直しが無いことを確かめてください。使うフレームワークの詳細は[Strands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説](https://www.issoh.co.jp/tech/details/7199/)や[LangChainとLangGraphの違いと使い分け](https://www.issoh.co.jp/tech/details/4059/)が参考になります。 ## InvokeAgentRuntime APIでデプロイ済みエージェントを呼び出す実装 デプロイ後、アプリケーションからエージェントを呼ぶのが`InvokeAgentRuntime` APIです。boto3では`bedrock-agentcore`クライアントの`invoke_agent_runtime`を使い、エージェントのARN・セッションID・ペイロードを渡します。応答はストリーミングで返り、ペイロードは最大100MBまで扱えます。 ``` import json, uuid, boto3 agent_arn = "<あなたのエージェントのARN>" # agentcore status で取得 client = boto3.client("bedrock-agentcore") payload = json.dumps({"prompt": "こんにちは"}).encode() response = client.invoke_agent_runtime( agentRuntimeArn=agent_arn, runtimeSessionId=str(uuid.uuid4()), payload=payload, qualifier="DEFAULT", ) content = [] for chunk in response.get("response", []): content.append(chunk.decode("utf-8")) print(json.loads("".join(content))) ``` `runtimeSessionId`に同じ値を渡し続けると会話コンテキストが維持されます。衝突を避けるため、セッションIDにはUUIDなど一意な値を使うのが推奨の方法です。呼び出しには`bedrock-agentcore:InvokeAgentRuntime`権限が必要で、権限不足は`AccessDeniedException`、ARN誤りは`ResourceNotFoundException`、レート超過は`ThrottlingException`で返ります。**OAuthでユーザー認証を統合する場合はAWS SDK経由では呼べず、HTTPSで直接`InvokeAgentRuntime`を叩く必要がある**点に注意してください。エージェント本体の作成・更新など管理系の操作は、別クライアントの`bedrock-agentcore-control`（`CreateAgentRuntime`等）で行います。 ## AgentCore GatewayのInvokeModel対応とモデルフォールバック設定 AgentCore Gatewayは、エージェントにツールを渡す「MCPの入口」に加えて、モデル推論の通り道（推論エンドポイント）も備えています。その推論エンドポイントについて、[2026年10月22日のAWS What’s New](https://aws.amazon.com/about-aws/whats-new/2026/10/agentcore-gateway-invokemodel-fallback/)で、Bedrock純正の`InvokeModel`系APIへの対応と、モデルフォールバックのルーティングが発表されました。提供範囲は、Gatewayが使えるすべてのAWSリージョン（中国リージョンを除く）です。複数のLLMを1つの窓口で束ねる「AIゲートウェイ」という製品カテゴリの考え方は[AIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断](https://www.issoh.co.jp/column/details/13818/)で整理しており、今回の追加によってGatewayはこのカテゴリにAWSマネージドで入ってきた形です。 ### 2026年10月22日発表の変更点：推論エンドポイントで既存SDKを流用 Gatewayの推論エンドポイントは`https://.gateway.bedrock-agentcore..amazonaws.com/inference`という形式で、これまではOpenAI形式（`/v1/chat/completions`・`/v1/responses`）とAnthropic形式（`/v1/messages`）を受け付けていました。今回、[公式ガイドのInvokeModel対応ページ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-inference-invokemodel.html)に記載のとおり、`/model/{model}/invoke`と`/model/{model}/invoke-with-response-stream`の2つのパスが加わりました。 接続先（ターゲット）は組み込みコネクタで作るのが早道です。[推論コネクタの公式ページ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-inference-connector.html)では、`connectorId`に`bedrock-mantle`・`bedrock-runtime`・`openai`・`anthropic`の4種が挙がっています。InvokeModelを受けるのは`bedrock-runtime`コネクタで、次のコマンドでターゲットを作成します。 ``` aws bedrock-agentcore-control create-gateway-target --cli-input-json '{ "gatewayIdentifier": "GATEWAY_ID", "name": "bedrock", "targetConfiguration": { "inference": { "connector": { "source": {"connectorId": "bedrock-runtime"} } } }, "credentialProviderConfigurations": [ {"credentialProviderType": "GATEWAY_IAM_ROLE"} ] }' ``` Gatewayの実行ロールには`bedrock:InvokeModel`と`bedrock:InvokeModelWithResponseStream`に加え、モデル一覧の取得に使う`bedrock:ListFoundationModels`・`bedrock:ListInferenceProfiles`など7つのList系権限が要ります。1つでも欠けるとモデル検出に失敗し、ターゲットが`Ready`になりません。公式ガイドも`bedrock:List*`の付与を代替案として挙げています。 ### endpoint\_urlの差し替えだけで済むboto3からのInvokeModel実装 呼び出し側の変更は、`bedrock-runtime`クライアントの`endpoint_url`をGatewayの`/inference`へ向ける1か所だけです。環境変数`AWS_ENDPOINT_URL_BEDROCK_RUNTIME`に同じURLを入れれば、コードを1行も触らずに切り替えられます。Gatewayは標準クライアントが使う署名名`bedrock`のSigV4をそのまま受け付けるため、署名の上書き設定も不要です。 ``` import boto3, json client = boto3.client( "bedrock-runtime", region_name="us-west-2", endpoint_url="https://.gateway.bedrock-agentcore.us-west-2.amazonaws.com/inference", ) body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user", "content": "AgentCore Gatewayを一文で説明して"}], }) response = client.invoke_model( modelId="us.anthropic.claude-sonnet-5-5", body=body, contentType="application/json", # 翻訳経路では必須 ) print(json.loads(response["body"].read())) ``` 呼び出し元に必要な権限は、Bedrockではなく`bedrock-agentcore:InvokeGateway`です。モデルへのアクセス権はGatewayの実行ロールが持つため、アプリ側のIAMロールからBedrockの権限を外せる構成です。ストリーミングは`invoke_model_with_response_stream`で、OpenAIやAnthropicのSSEで返った応答もGatewayがBedrockのイベントストリーム形式に組み直して返すので、既存の`for event in response["body"]`のループがそのまま動きます。InvokeModelのリクエスト本文の書き方そのものは[Bedrock Claudeの使い方：Messages API・InvokeModel・Claude Codeの設定](https://www.issoh.co.jp/tech/details/17865/)で扱っています。 ### 翻訳経路の制約：ペイロード形式の不一致とガードレールで400になる条件 Gatewayは「同じペイロード形式どうし」でしか翻訳しません。たとえばAnthropic Messages形式の本文を持つInvokeModelはAnthropicのAPIへ、OpenAI Chat Completions形式の本文はOpenAIへ翻訳できますが、形式をまたぐ変換（Chat Completionsの本文をAnthropicへ送るなど）は`400`の`ValidationException`で拒否されます。OpenAIのResponses APIは素通しのみで、InvokeModelとの相互翻訳はありません。 見落としやすいのが2点あります。1つは`contentType="application/json"`で、Bedrock単体では省略できても、翻訳経路では省くと`Expected request with Content-Type: application/json`で失敗します。もう1つはBedrock Guardrailsです。`guardrailIdentifier`を付けたリクエストは素通し経路では効きますが、他社プロバイダーへ翻訳される経路では黙って外されず、400で拒否されます。プロバイダーをまたいでガードレールを効かせたいなら、Gateway側で評価されるAgentCore Policyに寄せるのが公式の推奨です。なお、2026年10月24日時点の対応表に`Converse`は載っていません。[Converse APIで実装したコード](https://www.issoh.co.jp/tech/details/2391/)をそのままGatewayへ向けることはできない前提で設計してください。 ### フォールバックチェーンの設定：429・5XX・初回バイト超過で切り替え フォールバックはGatewayのルール（`create-gateway-rule`）で定義します。[公式ガイドのルーティングとフォールバックのページ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rules-fallback.html)に沿うと、`matchModels`で対象モデルを選び、`routeToTarget`の`staticRoute`に主系を、`targetFallback`に1〜2件の代替先を順番に並べます。次の例は、Bedrock上のClaudeを主系にし、失敗したらAnthropic直結へ、それも駄目ならBedrock上の別モデルへ落とす設定です（ターゲット名とモデルIDは自分のGatewayで`/inference/v1/models`を叩いて確かめた値に置き換えます）。 ``` aws bedrock-agentcore-control create-gateway-rule \ --gateway-identifier GATEWAY_ID \ --priority 100 \ --description "Claude: Bedrock primary, Anthropic direct, then degrade" \ --conditions '[{"matchModels": {"anyOf": [{"value": "claude-sonnet-5-5"}]}}]' \ --actions '[{ "routeToTarget": { "staticRoute": { "targetName": "bedrock", "model": "us.anthropic.claude-sonnet-5-5", "fallback": { "circuitBreaker": {"mode": "ENABLED"}, "triggerOn": { "statusCodes": ["5XX", "429"], "errors": ["CONNECTION_ERROR", "FIRST_BYTE_TIMEOUT", "UNROUTABLE"] }, "firstByteTimeoutMilliseconds": 5000, "targetFallback": [ {"targetName": "anthropic"}, {"targetName": "bedrock", "model": "us.anthropic.claude-haiku-5-5"} ] } } } }]' ``` `statusCodes`には4xx・5xxの個別コードか`5XX`のようなクラス指定を1〜10個、`errors`には`CONNECTION_ERROR`（接続できない）・`FIRST_BYTE_TIMEOUT`（最初の1バイトが期限内に来ない）・`UNROUTABLE`（ターゲット不在など）から1〜3個を指定します。`firstByteTimeoutMilliseconds`は、プロバイダーがエラーを返さず固まるケースでも次へ進むための待ち時間です。呼び出し元から見ると1リクエスト1レスポンスのままで、どの接続先が応答したかを示すヘッダーは付きません。実際の振り分け先はGatewayのルーティングログで確認します。 制約も3つ押さえておきます。まず**ストリーミングが始まった後はフォールバックできません**。途中で切れた場合、クライアントには部分応答とエラーが届き、再試行は呼び出し側の責任です。次に、主系と代替先は「ターゲット×モデル」の組み合わせがすべて異なる必要があり、重複するとルール作成が拒否されます。最後に、`weightedRoute`で重み付け配分している場合は、配分先ごとに`fallback`を書く設定が必要です。同じ発想をOSSで組む場合の設定は[LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定](https://www.issoh.co.jp/tech/details/18663/)と比べると、マネージドに任せる範囲の違いがつかめます。 ### サーキットブレーカーの3状態とフォールバック時に増える呼び出し課金 フォールバックには、障害中の接続先を飛ばすサーキットブレーカーが既定で有効になっています。状態は「Closed（正常：主系へ送り、失敗したら次へ）」「Open（障害中：主系を飛ばして次へ直行）」「Half-open（回復確認：一部だけ主系へ試しに送る）」の3つで、自動で遷移します。仕組みの一般論は[サーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組み](https://www.issoh.co.jp/tech/details/13216/)で解説しているものと同じです。 課金面では、**Gatewayが外へ送った試行1回ごとに、Gatewayの呼び出し1回として課金**されます。Closed状態で主系が500を返して代替先が応答した場合、失敗した主系の試行も課金対象です。Open状態で飛ばした主系は課金されません。モデルの推論料金は試行ごとにBedrockや各プロバイダー側で別途かかります。安い主系を優先し続けたい場合は`circuitBreaker.mode`を`DISABLED`にできますが、障害時は毎回失敗試行の遅延と課金を払うことになります。 ## Gateway・Memory・Identity・Observabilityの使いどころ ### Gateway：既存APIやLambdaをMCPツールとして一元管理する仕組み 推論の入口とは別に、Gatewayの本来の役割はOpenAPI仕様やLambda関数を**MCP（Model Context Protocol）のツール**としてエージェントに公開することです。MCPそのものの仕組みは[MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組み](https://www.issoh.co.jp/tech/details/5736/)を参照してください。エージェントごとにツール連携コードを書かず、Gateway側でツールを一元管理できるのが利点です。2026年6月にはAWSが運営するWeb検索もGatewayの組み込みコネクタとして加わりました。推論APIからGPTモデルに検索させる別系統のWeb Searchとの違いは[Bedrock Web Searchとは：GPT-5.6で引用付き回答を返す設定とIAM・料金](https://www.issoh.co.jp/tech/details/18242/)で整理しています。MCPサーバー自体の作り込みは[FastMCPとは？PythonでMCPサーバーを作る手順](https://www.issoh.co.jp/tech/details/6507/)が理解の助けになります。 ### Memory：会話内の短期STMとセッションをまたぐ長期LTMの使い分け 短期メモリ（STM）は1つの会話セッション内の文脈を保持し、長期メモリ（LTM）はセッションをまたいで事実・嗜好・要約を自動抽出して蓄積します。CLIの`--memory longAndShortTerm`やコンソールでLTMを有効化すると、抽出戦略（SEMANTIC等）に沿って記憶が構築される仕組みです。1回きりの問い合わせ対応ならSTMだけで足り、利用者ごとの好みや過去の判断を次回に持ち越したい業務でだけLTMを足すと、抽出処理の課金を抑えられます。 ### Identity：受信認証と送信認証を仲介しRuntime経由は追加課金なし Identityはエージェントへの受信認証と、外部サービスへの送信認証の両方を仲介します。Gatewayの推論ターゲットでOpenAIやAnthropicのAPIキーを使う場合も、キーはIdentityのトークン保管庫に置き、Gatewayが送信時に差し込みます。費用面で押さえたいのは、**RuntimeまたはGateway経由でIdentityを使う場合、Identity分の追加課金は発生しない**点です。 ### Observability：OpenTelemetry準拠のトレースと監視費の見積もり ObservabilityはOpenTelemetry準拠でトレース・ログ・メトリクスをCloudWatchに送ります。CLIなら`agentcore logs`でログを、`agentcore traces list`でトレースを確認できる構成です。ただしCloudWatch側の課金には上限がないため、監視コストは別枠で見積もる必要があります。 ## AgentCoreの料金体系：Runtime v1・v2単価とGateway課金の勘所 AgentCoreは、コンポーネントごとに個別の従量課金です。**基盤そのものは無料で、各コンポーネントが実際にリソースを消費したときだけ課金**されます。代表的な単価は以下のとおりで（2026年10月24日時点）、変動しうるため契約前に[公式の料金ページ](https://aws.amazon.com/bedrock/agentcore/pricing/)で確認してください。 | 項目 | 課金の基準 | | ----------------- | ------------------------ | | Runtime v1 | vCPU時$0.0895＋GB時$0.00945 | | Runtime v2（消費型） | vCPU時$0.1276＋GB時$0.0169 | | Gateway（ツール呼び出し等） | 1,000回あたり0.005ドル | | Gateway（検索API） | 1,000回あたり0.025ドル | | Identity（基盤経由） | 追加課金なし | 表中の$はドルを表し、RuntimeのCPU単価は1 vCPU時、メモリ単価は1 GB時あたりです。Identityの「基盤経由」はRuntimeまたはGateway経由での利用を指します。 Runtimeの料金表はv1とv2に分かれ、v2は単価が高い代わりに、アイドル状態が120秒続くとメモリを自動で回収する仕様です。2026年10月中に、v2をさらに安くするコミット型のベースライン料金（1 vCPU時0.0997ドル）も始まる予定と記載されています。Gatewayの推論トラフィックには料金表に専用の行がなく、前述のとおりフォールバックの試行ごとにGatewayの呼び出しとして数えられる点に注意が必要です。 見落としやすいコストはほかに2つあります。1つは**アイドル状態のセッションメモリ**で、v1では既定15分のタイムアウトまでメモリが確保され続けるため、放置セッションが積み上がると、そのメモリも課金対象です。もう1つは**Observability（CloudWatch）に上限がない**点で、テレメトリ量が多いエージェントでは監視費が本体費用を上回ることもあります。小規模から始め、実測してからコンポーネントを増やすのが安全です。Google・Azureの同等基盤と並べた月額の試算は[AgentCore比較：Google Agent Runtime・Foundryと料金と上限を並べて選ぶ](https://www.issoh.co.jp/tech/details/17828/)にまとめています。 ## AgentCore Gatewayを推論の入口に採用する条件と見送る場面の判断基準 InvokeModel対応で、Gatewayは「エージェントのツール窓口」から「社内のLLM呼び出しを1か所に集める窓口」にもなりました。ただし、すべての呼び出しをGateway経由にするのが正解ではありません。当社の判断基準は次のとおりです。 **採用する条件**は3つのうち2つ以上に当てはまる場合です。①Bedrockに加えてOpenAIやAnthropicの直接契約も併用しており、プロバイダー障害やスロットリングで業務が止まった経験がある。②アプリごとに散らばったBedrockの権限を整理し、モデルアクセスをGatewayの実行ロールに集約したい。③AgentCore PolicyやトークンベースのレートリミットをInvokeModelの呼び出しにも一律で効かせたい。既存のboto3コードが多いほど、`endpoint_url`の差し替えだけで済む今回の対応は効いてきます。 **見送る場面**もはっきりしています。Bedrockの単一モデルしか使わず、呼び出し元も1つのアプリだけなら、Gatewayを挟んでも試行課金と経路が1段増えるだけです。この場合はboto3の標準リトライで足ります。また、長文のストリーミング応答が主体のチャットUIでは、応答開始後のフォールバックが効かないため、可用性の改善幅は限られます。Converse APIで書いた既存コードを抱えている場合も、2026年10月24日時点では書き換えが前提になるため、移行コストと天秤にかけてください。 Gatewayのルール設計、既存エージェントのRuntime移行、権限とコスト上限の設計まで含めて検討する場合は、一創の[AIエージェント開発](https://www.issoh.co.jp/service/ai/agent/)で要件整理から本番運用まで支援しています。 ## よくある質問 AgentCore APIとAgentCore Gatewayについて、検索でよく寄せられる疑問に回答します。 ### AgentCoreは無料で使えますか？ 基盤の仕組み自体は無料ですが、Runtimeの実行時間やGateway・Memoryなどの利用量に応じて従量課金されます。呼び出さなければ料金は発生しません。ただしアイドルセッションのメモリ確保やCloudWatchの監視費は発生しうるため、実質的に「完全無料」ではありません。Gatewayでフォールバックを使う場合は、失敗した試行もGatewayの呼び出しとして数えられます。アイドル中のメモリ課金を止める実装と、他社基盤との月額比較は[AgentCore比較](https://www.issoh.co.jp/tech/details/17828/)の記事で試算しています。 ### AgentCore Gatewayで既存のInvokeModelのコードはそのまま動きますか？ 2026年10月22日の機能追加以降、boto3の`bedrock-runtime`クライアントの`endpoint_url`をGatewayの`/inference`に向ければ、`invoke_model`と`invoke_model_with_response_stream`はそのまま通ります。呼び出し元には`bedrock-agentcore:InvokeGateway`権限が必要です。他社プロバイダーへ翻訳される経路では`contentType="application/json"`の指定が必須で、Bedrock Guardrailsを付けたリクエストは400で拒否されます。Converse APIは対応表に載っていません。 ### Bedrock AgentsとAgentCoreの違いは何ですか？ Bedrock Agentsは設定中心のフルマネージドで、AWSがエージェントループを実行します。AgentCoreは自分でフレームワークを選んでコードを書き、その実行基盤・メモリ・認証・監視を受け持つのはAWSです。使えるフレームワークはStrands Agents・LangChain/LangGraph・CrewAI・LlamaIndex・Google ADK・OpenAI Agents・独自コードと幅広く、既存のLangGraphやStrandsのエージェントを本番化したいならAgentCoreが適しています。 ### agentcore configureやagentcore launchが動かない理由 それらは旧`bedrock-agentcore-starter-toolkit`のコマンドで、現在はレガシー扱いです。新しい`@aws/agentcore` CLI（2026年10月22日に1.0.0）では`agentcore create`／`agentcore dev`／`agentcore deploy`／`agentcore invoke`に置き換わっています。Runtimeの実行環境はARM64（AWS Graviton）で、既定のデプロイリージョンはus-west-2のため、コンテナを自前でビルドする場合はARM64向けにしてください。 ### AgentCore GatewayのフォールバックとLiteLLMは何が違いますか？ どちらも複数のモデルやプロバイダーを1つの窓口にまとめ、失敗時に別の接続先へ切り替えます。AgentCore Gatewayはサーバー運用が不要で、IAM・AgentCore Policy・Identityと一体で管理できる一方、代替先は1ルールあたり最大2件で、ストリーミング開始後は切り替えられません。LiteLLMは自前でProxyを運用する代わりに、予算管理や細かなリトライ設定を自由に組めます。AWSに閉じた構成ならGateway、マルチクラウドで細かく制御したいならLiteLLMが目安です。 ## 関連記事 - [AgentCore比較：Google Agent Runtime・Foundryと料金と上限を並べて選ぶ](https://www.issoh.co.jp/tech/details/17828/)（3基盤の料金と上限の比較） - [Strands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説](https://www.issoh.co.jp/tech/details/7199/)（Runtimeに載せる代表的なフレームワーク） - [LangChainとLangGraphの違いと使い分け](https://www.issoh.co.jp/tech/details/4059/)（既存エージェントを移す前の整理） - [FastMCPとは？PythonでMCPサーバーを作る手順](https://www.issoh.co.jp/tech/details/6507/)（Gatewayにつなぐツール側の実装） - [LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順](https://www.issoh.co.jp/tech/details/18663/)（Gatewayのフォールバックと比べるOSSの選択肢） --- 出典: [AgentCore Gatewayと AgentCore APIの使い方：InvokeModel対応・フォールバック設定とSDK・CLIでの本番デプロイ]()（株式会社一創）