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つのマネージドサービスと各サービスの役割

Runtimeはエージェントを動かす基盤で、セッションを隔離して長時間実行に対応します。Gatewayは既存APIやLambdaをMCPツールとして公開し、推論の入口も担う構成です。ObservabilityではCloudWatchとOpenTelemetryを使い、エージェントの実行状況を追跡します。

GA後は上記に加え、品質評価のEvaluations、x402マイクロ決済のPayments、認可制御のPolicy、エージェントの社内カタログであるAWS Agent Registryなども料金表に並び、公式の料金ページでは2026年10月24日時点で13の機能が掲載されています。各コンポーネントは単体でも組み合わせても使え、Runtimeを使わず既存のエージェントからMemoryやGatewayだけを呼ぶ構成も可能です。RuntimeやGatewayで公開したエージェントとMCPサーバーを社内カタログに登録し、承認済みのものだけを検索させる仕組みはAWS Agent Registryとは：MCPとエージェントの社内カタログを作る手順と料金で解説しています。

Bedrock AgentsとAgentCoreの違い：設定中心かコード中心かの選び方

「bedrock agents agentcore 違い」で検索する人が最初に迷うのがこの2つの棲み分けです。結論から言うと、コードを書かずに設定で完結させたいならBedrock Agents、任意のフレームワークで書いたエージェントを本番に載せたいならAgentCoreです。両者は競合する製品としてではなく、抽象度の違う選択肢として比較してください。

すでにLangGraphやStrandsでエージェントを組んでいるなら、作り直さずAgentCore Runtimeに載せられるため移行コストは小さくなります。逆に、要件が「社内ドキュメントに答えるQ&Aボット」程度で内製工数を割きたくないなら、Bedrock Agentsのほうが早い。コードを書かずに業務担当者がエージェントを使う前提なら、Amazon Quick（旧Quick Suite）の料金を全プラン比較で扱ったSaaS型の選択肢もあります。フレームワークにこだわりがない小規模PoCでAgentCoreをフル装備すると、コンポーネント単位の課金が積み上がりがちなので注意してください。なお2026年7月30日以降、Bedrock Agentsは「Amazon Bedrock Agents Classic」としてメンテナンスモードに入り、過去12か月に利用実績のないAWSアカウントでは新規エージェントを作成できなくなりました。ループ制御を自前で持つ構成の扱いを含め、前提条件はBedrock Agentsのカスタムオーケストレーションとメンテナンスモードの影響で整理しています。

AgentCore APIとSDKの全体像：開発フェーズ別に使う3つの入口

「AgentCore API」と一口に言っても、開発フェーズごとに触る対象が変わります。役割を混同するとドキュメントを探しても目的の手順にたどり着けないため、まず3つの入口を分けて理解します。

ざっくり言えば、SDKで「エージェントを載せる形」を作り、CLIで「AWSに配る」、APIで「アプリから叩く」という流れです。管理系の操作（RuntimeやGatewayの作成・更新）は別クライアントのbedrock-agentcore-controlが受け持ち、後述するGatewayのルール作成もこちらのAPIで行います。以下で順に実コードを示します。

bedrock-agentcore SDKでエージェントを本番用HTTPサーバー化する手順

PythonのランタイムSDKbedrock-agentcoreは、自作のエージェント関数を、ヘルスチェックとストリーミングに対応した本番用HTTPサーバーに変換します。PyPIの配布ページで確認した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の使い方・特徴を解説やLangChainとLangGraphの違いと使い分けが参考になります。

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で、Bedrock純正のInvokeModel系APIへの対応と、モデルフォールバックのルーティングが発表されました。提供範囲は、Gatewayが使えるすべてのAWSリージョン（中国リージョンを除く）です。複数のLLMを1つの窓口で束ねる「AIゲートウェイ」という製品カテゴリの考え方はAIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断で整理しており、今回の追加によってGatewayはこのカテゴリにAWSマネージドで入ってきた形です。

2026年10月22日発表の変更点：推論エンドポイントで既存SDKを流用

Gatewayの推論エンドポイントはhttps://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/inferenceという形式で、これまではOpenAI形式（/v1/chat/completions・/v1/responses）とAnthropic形式（/v1/messages）を受け付けていました。今回、公式ガイドのInvokeModel対応ページに記載のとおり、/model/{model}/invokeと/model/{model}/invoke-with-response-streamの2つのパスが加わりました。

接続先（ターゲット）は組み込みコネクタで作るのが早道です。推論コネクタの公式ページでは、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-id>.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の設定で扱っています。

翻訳経路の制約：ペイロード形式の不一致とガードレールで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で実装したコードをそのままGatewayへ向けることはできない前提で設計してください。

フォールバックチェーンの設定：429・5XX・初回バイト超過で切り替え

フォールバックはGatewayのルール（create-gateway-rule）で定義します。公式ガイドのルーティングとフォールバックのページに沿うと、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の構築手順とフォールバック・予算設定と比べると、マネージドに任せる範囲の違いがつかめます。

サーキットブレーカーの3状態とフォールバック時に増える呼び出し課金

フォールバックには、障害中の接続先を飛ばすサーキットブレーカーが既定で有効になっています。状態は「Closed（正常：主系へ送り、失敗したら次へ）」「Open（障害中：主系を飛ばして次へ直行）」「Half-open（回復確認：一部だけ主系へ試しに送る）」の3つで、自動で遷移します。仕組みの一般論はサーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組みで解説しているものと同じです。

課金面では、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と外部ツールをつなぐ標準規格の仕組みを参照してください。エージェントごとにツール連携コードを書かず、Gateway側でツールを一元管理できるのが利点です。2026年6月にはAWSが運営するWeb検索もGatewayの組み込みコネクタとして加わりました。推論APIからGPTモデルに検索させる別系統のWeb Searchとの違いはBedrock Web Searchとは：GPT-5.6で引用付き回答を返す設定とIAM・料金で整理しています。MCPサーバー自体の作り込みはFastMCPとは？PythonでMCPサーバーを作る手順が理解の助けになります。

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日時点）、変動しうるため契約前に公式の料金ページで確認してください。

表中の$はドルを表し、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と料金と上限を並べて選ぶにまとめています。

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エージェント開発で要件整理から本番運用まで支援しています。

よくある質問

AgentCore APIとAgentCore Gatewayについて、検索でよく寄せられる疑問に回答します。

AgentCoreは無料で使えますか？

基盤の仕組み自体は無料ですが、Runtimeの実行時間やGateway・Memoryなどの利用量に応じて従量課金されます。呼び出さなければ料金は発生しません。ただしアイドルセッションのメモリ確保やCloudWatchの監視費は発生しうるため、実質的に「完全無料」ではありません。Gatewayでフォールバックを使う場合は、失敗した試行もGatewayの呼び出しとして数えられます。アイドル中のメモリ課金を止める実装と、他社基盤との月額比較はAgentCore比較の記事で試算しています。

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と料金と上限を並べて選ぶ（3基盤の料金と上限の比較）
• Strands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説（Runtimeに載せる代表的なフレームワーク）
• LangChainとLangGraphの違いと使い分け（既存エージェントを移す前の整理）
• FastMCPとは？PythonでMCPサーバーを作る手順（Gatewayにつなぐツール側の実装）
• LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順（Gatewayのフォールバックと比べるOSSの選択肢）