公開更新 AIエージェント・MCP

AgentCore比較：Google Agent Runtime・Foundryと料金・上限・Runtime V2を並べて選ぶ

AgentCore比較：Google Agent Runtime・Foundryと料金・上限・Runtime V2を並べて選ぶ

Amazon Bedrock AgentCoreを検討するとき、比べる相手はGoogleのAgent Runtime（旧Vertex AI Agent Engine）とMicrosoftのFoundry hosted agentsです。3つとも「自分で書いたエージェントを、セッション専用の隔離環境で動かすマネージド基盤」で、機能表だけでは差が見えません。差が出るのは、LLMの応答を待つあいだの課金、アイドル中の扱い、1セッションの上限時間です。この記事では2026年9月時点の公式ドキュメントと料金APIの値をもとに、3基盤の仕様と東京リージョンの単価を並べ、CLIでデプロイする手順、月1万セッションの試算スクリプト、AgentCoreを選ぶ案件と見送る案件の線引きまでを整理します。10月に入ってからのAgentCore側の変更（GatewayのInvokeModel対応とモデルフォールバック、Memory短期メモリの課金方式の切り替え）は2026年10月31日時点の公式情報で、スナップショットから起動する新しいRuntime V2（platformVersion=V2）は2026年11月10日時点の公式情報と東京の単価で反映しました。

まとめ：AgentCoreを選ぶ条件と他社基盤へ回す条件の先出し整理

AWSに業務データとIAMがあり、1セッションが数分〜数時間で終わるエージェントなら、AgentCore Runtimeが第一候補です。LLM応答待ちのあいだCPUが課金されないため、同じ条件の試算では3基盤で最も安くなりました。

ただし会話の終わりにStopRuntimeSessionを呼ばないと、既定900秒のアイドル中もメモリ課金が続きます。試算では月額が約2.2倍に増え、Google側を上回りました。実装時に最初に潰すべき落とし穴はここです。

9月にGAとなり、11月9日のAWS Weekly Roundupで改めて紹介されたRuntime V2は、この前提を一部変えます。V2はスナップショットから環境を復元して起動し、使っていないメモリを返す課金になるため、200MB〜2GBのイメージでもコールドスタートがP75で約2秒にそろいます。代わりに東京の単価はvCPUで約1.4倍、メモリで約1.8倍という単価です。停止APIを確実に呼べるアプリならV1のままが安く、停止を呼べない画面や大きなイメージで起動待ちが目立つ案件ではV2へ切り替える、というのが今回の試算から出した線引きです。

10月の変更で、AgentCoreを推す材料は2つ増えました。1つはGatewayがBedrockのInvokeModel APIを受け付け、モデルの切り替え先を順番に試すフォールバックを持てるようになった点です。もう1つはMemoryの短期メモリが1,000イベント単位からGB単位の課金に変わり、会話履歴の保存費がかなり下がった点です。逆に、フォールバックは試行ごとにGatewayの呼び出しとして課金されるため、障害時の請求の増え方は設計で決まります。

配布先がTeamsやMicrosoft 365ならFoundry hosted agents、Gemini Enterpriseの社内アプリに載せるならGoogle Agent Runtimeを選びます。基盤の単価差より、利用者に届ける経路の作り込みのほうが工数を食うためです。

AgentCore・Google Agent Runtime・Foundryの仕様比較

最初に3基盤の立ち位置をそろえます。AgentCoreはAWS公式ドキュメントの概要ページで、Runtime・Memory・Gateway・Identity・Observabilityなど13の部品を「組み合わせても単体でも使える」と説明しています。この記事で比べるのは、そのうちエージェント本体を動かすRuntimeです。動かしたエージェントやMCPサーバーを組織内で探せるようにする台帳の側はAWS Agent Registryとは：MCPとエージェントの社内カタログを作る手順と料金で扱っています。AgentCore全体の構成やSDKの使い方、Gatewayの接続設定はAgentCore GatewayとAgentCore APIの使い方：InvokeModel対応・フォールバック設定とSDK・CLIでの本番デプロイで扱っています。

セッション専用VMの共通点と上限時間・アイドル時の扱いの相違点

3基盤とも、1セッションに専用の隔離環境を割り当てます。違うのは、その環境がどれだけ生き続け、止まったあと何が残るかです。セッションごとにマイクロVMを立てる隔離方式そのものの仕組みは、Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説で、コンテナとの違いから整理しています。

項目 AgentCore Runtime Google Agent Runtime Foundry hosted agents
隔離の単位 セッションごとのmicroVM reasoningEngineリソース セッションごとのVM隔離サンドボックス
1回の上限時間 最長8時間（Instancesは14日） クォータページで確認 記載なし（アイドルで停止）
アイドル既定値 900秒（60〜28,800秒） ターン間の待ちは課金外 15分（2〜60分）
アイドル中のメモリ V1は保持・V2は120秒で回収 ターン間は課金外 停止まで保持
起動のしかた V1は毎回初期化・V2は復元 公開値なし 公開値なし
停止後に残るもの 既定は消去（設定で保持） Sessions・Memory Bank $HOME・/filesを保持
デプロイ形式 CodeZipまたはコンテナ ADKアプリまたはコンテナ コード（ZIP）またはコンテナ

AgentCoreの上限とアイドル値はライフサイクル設定のページに、idleRuntimeSessionTimeoutとmaxLifetimeの範囲として載っています。Foundryの値はhosted agentsの概念ページの記載です。Google側の上限時間は本記事の執筆時点で数値を確認できていないため、表では空けています。停止後の保持について、AgentCoreはsession storage設定時に保持する仕様です。Googleは会話をSessions、長期記憶をMemory Bankに保存します。Foundryの$HOMEと/filesは、30日無操作で削除されます。AgentCoreの「アイドル中のメモリ」と「起動のしかた」の行は、後述するRuntime V2で変わった部分です。Foundry側の「停止まで保持」は、アイドル中のメモリを回収するという記載が概念ページに見当たらないことからの読み取りで、請求の明細で確かめる前提の値です。

国内案件で確認する東京リージョン対応と言語・フレームワークの差分

国内案件で先に確かめるのはリージョンです。AgentCoreは対応リージョン表で、東京がRuntime・Memory・Gateway・Identity・ハーネスなどに対応しています。paymentsだけは東京が対象外でした。Runtime V2も、2026年11月10日時点のmicroVMの説明ページ（Platform versions）に並ぶ10リージョンに東京（ap-northeast-1）が入っています。Googleはエージェント向けロケーション一覧でasia-northeast1がGA機能に対応し、FoundryはJapan EastとJapan Westの両方でhosted agentsを使えます。

言語とフレームワークは差がはっきり出ます。AgentCoreはStrands Agents・LangGraph・CrewAI・Google ADK・OpenAI Agents SDKを公式に挙げ、GoogleはAgent Runtimeの概要でADKを完全統合、LangGraphやLlamaIndexをSDK統合としています。Foundry hosted agentsはPythonとC#の2言語です。C#のSDKとデプロイ手順が公式にそろっているのは3基盤のうちFoundryだけです。

AgentCore CLIでエージェントを作りデプロイと呼び出しを通す手順

AgentCoreは2026年9月時点で、npm配布のCLIが公式の入口です。以前のpip版スターターツールキットとはコマンド体系が違うため、古い記事のagentcore configureやagentcore launchをそのまま打っても動きません。両方が入っていると旧版が先に呼ばれることがあるので、pip uninstall bedrock-agentcore-starter-toolkitで旧版を消してから新しい端末を開きます。

npm版agentcore CLI導入からagentcore deployまでの手順

公式のCLIクイックスタートに沿うと、雛形の作成からデプロイまでは次のコマンドで通ります。CLIのソースと不具合報告はGitHubのaws/agentcore-cliにあります。

# 前提: Node.js 20以上・Python 3.10以上・AWS認証情報の設定済み
npm install -g @aws/agentcore
agentcore --version   # エラーになる場合は旧pip版 bedrock-agentcore-starter-toolkit を削除する

# Strands Agents＋Bedrock・メモリなし・CodeZip（Docker不要）で雛形を作る
agentcore create \
  --project-name InvoiceProject \
  --name InvoiceAgent \
  --language Python \
  --framework Strands \
  --model-provider Bedrock \
  --memory none \
  --build CodeZip

cd InvoiceProject
agentcore dev               # ローカル実行（ホットリロードとエージェントインスペクタ）
agentcore deploy --dry-run  # 作成・変更されるリソースだけを確認
agentcore deploy            # CDKでAgentCore Runtimeのエンドポイントを作成
agentcore status            # 呼び出しに使うRuntimeのARNを確認
agentcore invoke --prompt "今月締めの請求書は何件ありますか"
agentcore logs --since 30m --level error

agentcore deployは裏でAWS CDKを使うため、初回はアカウントのブートストラップに数分かかります。Windowsでagentcore --versionがエラーになる場合、旧pip版のagentcoreコマンドがPATH上で先に見つかっている状態です。フレームワークにStrandsを選んだ場合の書き方はStrands Agentsとは？読み方・意味とPython SDKの使い方が参考になります。コードを書かずに設定ファイルだけで動かす経路もあり、そちらはBedrock AgentCoreハーネスGAの解説で解説している内容です。この手順で作ったランタイムは、何も指定しなければ従来のV1で動きます。V2への切り替えは後半の章で扱います。

boto3のInvokeAgentRuntimeで会話を続け最後に止める実装

アプリから呼ぶときはboto3のinvoke_agent_runtimeを使います。ポイントは2つ。同じ会話では同じruntimeSessionIdを渡すこと、会話が終わったらstop_runtime_sessionで止めることです。

import json
import uuid

import boto3

# agentcore status で表示されたARNに置き換える
AGENT_ARN = "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:runtime/InvoiceAgent-xxxxxxxxxx"
client = boto3.client("bedrock-agentcore", region_name="ap-northeast-1")

# 同じ会話は同じIDで呼ぶ。IDは33文字以上が条件で、uuid4の文字列（36文字）なら満たせる
session_id = str(uuid.uuid4())


def ask(prompt: str) -> dict:
    res = client.invoke_agent_runtime(
        agentRuntimeArn=AGENT_ARN,
        runtimeSessionId=session_id,
        payload=json.dumps({"prompt": prompt}).encode(),
        qualifier="DEFAULT",
    )
    body = "".join(chunk.decode("utf-8") for chunk in res.get("response", []))
    return json.loads(body)


try:
    print(ask("先月発行して未入金の請求書を一覧にして"))
    print(ask("そのうち支払期日を30日以上過ぎたものだけ"))  # 同じmicroVMで文脈を引き継ぐ
finally:
    # 会話が終わったら明示的に止める。止めないとアイドル既定900秒のあいだmicroVMが残る
    client.stop_runtime_session(
        agentRuntimeArn=AGENT_ARN,
        runtimeSessionId=session_id,
        qualifier="DEFAULT",
    )

セッションIDはセッションのページで定められた条件が「33文字以上」です。IDを毎回作り直すと、呼ぶたびに新しいmicroVMが立ち上がり、コールドスタートの待ちと会話の断絶が同時に起きます。停止APIの引数はStopRuntimeSessionのAPIリファレンスで確認できます。このコードはアプリ側（呼び出し元）で動くため、後述するV2のスナップショットの制約は受けません。

Google Agent RuntimeとFoundryで同じ構成を組むときの差分

同じ「請求書を答えるエージェント」を他の2基盤に載せる場合の手順を並べます。どちらもクイックスタートの構成をそのまま使っています。

ADKアプリのagent_engines.createによる登録手順

GoogleはVertex AIをGemini Enterprise Agent Platformへ改称し、Agent EngineもAgent Runtimeと呼ぶようになりました。APIのリソース名は互換性のためReasoningEngineのままです。ADKのクイックスタートでは、次のコードでデプロイします。

# pip install --upgrade --quiet "google-cloud-aiplatform[agent_engines,adk]>=1.112"
import vertexai
from google.adk.agents import Agent
from vertexai import agent_engines, types

# LOCATION は対応リージョン一覧で確認する（asia-northeast1 はGA機能に対応）
client = vertexai.Client(project="PROJECT_ID", location="LOCATION")

agent = Agent(model="gemini-3.5-flash", name="invoice_agent")
app = agent_engines.AdkApp(agent=agent)

# reasoningEngine リソースとしてAgent Runtimeへデプロイされる
remote_agent = client.agent_engines.create(
    agent=app,
    config={
        "requirements": ["google-cloud-aiplatform[agent_engines,adk]"],
        "staging_bucket": "STAGING_BUCKET",  # Cloud Storageのステージング用バケット
        "identity_type": types.IdentityType.AGENT_IDENTITY,
    },
)

注意点がひとつあります。Agent Runtimeの概要ページには、Agent Platform SDKの2.0.1でagent_enginesモジュールがruntimes・sessionsなどに分割され、別パッケージのgoogle-cloud-agentplatformへ移ったという記載です。上のコードは2026年9月24日更新のクイックスタートどおりですが、新規案件では新パッケージ側の書き方も確認してから採用を決めます。2026年9月のSDK分離後の書き方（client.runtimes.create）はVertex AI Agent Engine（現Agent Runtime）の使い方：ADKデプロイと料金が手順の参照先です。Google側の名称や料金の全体像はVertex AI Agent Builderとは？現在の名称・料金・作り方で整理しています。

Foundry hosted agentsはazdでZIPを上げてリモートビルド

Foundryはhosted agentのクイックスタートで、Azure Developer CLI（azd）を使う流れを最初に案内しています。

# 前提: Foundry Dev Pack（azd 1.27.1以上）を導入済み
azd auth login

# Agent FrameworkのBasicサンプルから、コード（ZIP）デプロイ方式で初期化する
azd ai agent init -m "https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/responses/01-basic/azure.yaml" --deploy-mode code
cd agent-framework-agent-basic-responses

azd provision        # Foundryプロジェクト・モデルデプロイなどを作成
azd ai agent run     # ローカル実行（エージェントインスペクタが開く）
azd deploy           # ソースをZIPで上げ、Foundry側でリモートビルドしてデプロイ
azd ai agent invoke "今月締めの請求書は何件ありますか"
azd ai agent monitor --follow   # コンテナログの追跡

デプロイすると、エージェントごとに専用のMicrosoft Entra IDとエンドポイントが自動で作られます。呼び出しはOpenAI互換のResponsesプロトコルが基本で、Teamsへ公開するとActivityプロトコルへの橋渡しも自動です。サンドボックスの大きさは0.5vCPU/1GiB・1vCPU/2GiB・2vCPU/4GiBの3段階しか選べません。Foundry Agent Service全体の料金とプロンプト型エージェントの作り方はFoundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行・料金とブラウザ自動化の実装手順にあります。

月1万セッションのPrice List API・Retail Prices API料金試算

単価の見出しだけを比べると、判断を誤ります。3基盤で「何秒ぶんが課金されるか」の定義が違うためです。ここでは各社の料金APIから東京（Azureは東日本）の単価を取り、同じワークロードで月額を出します。この章の試算はAgentCoreを既定のV1で動かす前提です。V2の単価で計算し直した結果は、次の章で並べます。

東京とJapan Eastの単価を取得して3基盤の月額を出すスクリプト

AWSは認証不要のPrice List API、AzureはRetail Prices APIから単価を取得します。Googleは機械可読の価格APIに認証が要るため、Agent Platformの料金ページの公表値を手入力しました。標準ライブラリだけで動きます。

"""AgentCore Runtime・Google Agent Runtime・Foundry hosted agents の月額概算（実行基盤部分のみ）"""
import json
import urllib.parse
import urllib.request

# 想定ワークロード（自社の値に置き換える）
SESSIONS = 10_000        # 月間セッション数
SESSION_SEC = 300        # 1セッションの実行時間（秒）
CPU_ACTIVE = 0.3         # うちCPUが実際に動いている割合（残りはLLM応答待ち）
VCPU, MEM_GB = 1, 2      # 1セッションあたりの割り当て（AgentCoreはピーク消費量とみなす）
IDLE_SEC = 900           # AgentCoreでStopRuntimeSessionを呼ばない場合のアイドル時間（既定値）


def get_json(url):
    with urllib.request.urlopen(url, timeout=60) as r:
        return json.load(r)


# AWS: Price List API（東京 ap-northeast-1）から AgentCore Runtime の単価を取る
aws = get_json("https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/"
               "AmazonBedrockAgentCore/current/ap-northeast-1/index.json")
aws_price = {}
for sku, prod in aws["products"].items():
    ut = prod["attributes"].get("usagetype", "")
    if ut in ("APN1-Runtime:Consumption-based:vCPU", "APN1-Runtime:Consumption-based:Memory"):
        term = next(iter(aws["terms"]["OnDemand"][sku].values()))
        dim = next(iter(term["priceDimensions"].values()))
        aws_price[ut.rsplit(":", 1)[1]] = float(dim["pricePerUnit"]["USD"])

# Azure: Retail Prices API（東日本 japaneast）から hosted agents の単価を取る
flt = "productName eq 'Foundry Agents' and armRegionName eq 'japaneast'"
az = get_json("https://prices.azure.com/api/retail/prices?$filter=" + urllib.parse.quote(flt))
az_price = {i["meterName"]: i["retailPrice"] for i in az["Items"]}

# Google: 料金ページの公表値（機械可読APIは要認証のため手入力）
G_VCPU, G_GIB = 0.085, 0.009
G_FREE_VCPU_H, G_FREE_GIB_H = 50, 100

hours = SESSIONS * SESSION_SEC / 3600
agentcore = (hours * VCPU * CPU_ACTIVE * aws_price["vCPU"]
             + hours * MEM_GB * aws_price["Memory"])
google = (max(hours * VCPU - G_FREE_VCPU_H, 0) * G_VCPU
          + max(hours * MEM_GB - G_FREE_GIB_H, 0) * G_GIB)
foundry = (hours * VCPU * az_price["Hosted vCPU Usage"]
           + hours * MEM_GB * az_price["Hosted Memory Usage"])

print(f"AWS単価 {aws['publicationDate'][:10]}: {aws_price}")
print(f"Azure単価: vCPU {az_price['Hosted vCPU Usage']} / GiB {az_price['Hosted Memory Usage']}")
print(f"稼働 {hours:,.1f} セッション時間/月")
# microVM v1はアイドル中もピークメモリが課金対象になる（CPUはI/O待ちと同じく0）
agentcore_idle = agentcore + SESSIONS * IDLE_SEC / 3600 * MEM_GB * aws_price["Memory"]

for name, usd in (("AgentCore Runtime", agentcore), ("AgentCore（停止しない）", agentcore_idle),
                  ("Google Agent Runtime", google), ("Foundry hosted agents", foundry)):
    print(f"{name}: ${usd:,.2f}")

2026年9月25日に実行した結果は次のとおりです。AWSの単価はpublicationDateが2026-09-15のデータでした。2026年11月10日に同じPrice List APIを取り直したところ、publicationDateは2026-11-05に更新されていましたが、V1の東京単価（vCPU 0.0895ドル/時、メモリ0.00945ドル/GB時）は変わっていません。AgentCoreの料金ページの表も同じ値です。

$ python agent_runtime_cost.py
AWS単価 2026-09-15: {'Memory': 0.00945, 'vCPU': 0.0895}
Azure単価: vCPU 0.10934 / GiB 0.01298
稼働 833.3 セッション時間/月
AgentCore Runtime: $38.12
AgentCore（停止しない）: $85.38
Google Agent Runtime: $80.68
Foundry hosted agents: $112.75

月1万セッションの試算結果の読み方と待ち時間の課金差が月額を分ける理由

AgentCoreが最安になった理由は、LLM応答やツール呼び出しを待つI/O待ちのあいだCPUが0になる点です。AgentCoreの料金ページは、エージェントの処理時間の30〜70%がI/O待ちだと説明しています。CPU稼働率を0.3にした今回の条件では、CPU分が約22ドル、メモリ分が約16ドルでした。

Googleは毎月50vCPU時間と100GiB時間の無料枠があり、ターン間でプロンプトを待つ時間は課金されません。公表されている除外はターン間の待ちだけで、1ターン内のLLM応答待ちを除くという記載はありません。今回の試算でも、1ターン内の時間はCPUとメモリの両方を課金する前提で計算しています。Foundryは単価が3基盤で最も高く、vCPUが1時間0.10934ドル、メモリが1GiB時間0.01298ドルでした。

この試算はRuntime部分だけです。LLMのトークン料金、AgentCore MemoryやGatewayの従量課金、ログの保存料は別に積み上がります。トークン料金は会話の長さと選ぶモデルで大きく変わるため、Runtime単価の差だけで基盤を決めないでください。Bedrock側のトークン課金の方式と月額の見積もり方はAWS Bedrockの料金はいくら？課金方式4種と月額試算・費用を下げる順番にまとめています。

10月6日からのMemory短期メモリGB課金で会話履歴の保存費を見積もる

Runtimeの外で積み上がる費用のうち、10月に計算方法が変わったのがAgentCore Memoryの短期メモリ（会話のイベントを保存する部分）です。AWSは2026年10月12日の発表で、1イベントあたりの定額から、取り込み・取得・保存のデータ量に応じた課金へ切り替えたと案内しました。料金ページの表では、2026年10月5日までの取り込みが1,000イベントあたり0.25ドル、10月6日以降は取り込み1GBあたり1.00ドル、取得1GBあたり0.20ドル、保存1GB月あたり0.10ドルです（2026年10月31日時点）。長期メモリの単価は変わっていません。

注意したいのは課金対象のサイズです。取り込みと取得は、1イベントを最小12KB、最大64KBとして数えます。2KBの短い発話でも12KBぶんが課金され、保存だけは実サイズで按分される仕組みです。月1万セッション・1セッション10往復の条件で計算すると次のようになります。

"""AgentCore Memory 短期メモリ（STM）の月額概算（2026年10月6日以降のGB単位課金）"""
SESSIONS = 10_000      # 月間セッション数
TURNS = 10             # 1セッションの往復数
EVENTS_PER_TURN = 2    # 利用者の発話とエージェントの応答で2イベント
READ_EVENTS = 5        # 1往復ごとに直近5イベントを取得する想定
ACTUAL_KB = 2          # 1イベントの実サイズ（保存はこの値で課金）
KB_PER_GB = 1_000_000  # GBの換算（AWS側の定義を確認して置き換える）


def billable_kb(kb):
    # 取り込みと取得は、1イベントを12KB〜64KBの範囲に丸めて課金する
    return min(max(kb, 12), 64)


events = SESSIONS * TURNS * EVENTS_PER_TURN
ingest_gb = events * billable_kb(ACTUAL_KB) / KB_PER_GB
retrieve_gb = SESSIONS * TURNS * READ_EVENTS * billable_kb(ACTUAL_KB) / KB_PER_GB
# TTLを30日にした定常状態では、およそ1か月分のイベントが常に保存されている
storage_gb_month = events * ACTUAL_KB / KB_PER_GB

new = ingest_gb * 1.00 + retrieve_gb * 0.20 + storage_gb_month * 0.10
old_ingest = events / 1000 * 0.25  # 10月5日までの取り込み単価（1,000イベントあたり0.25ドル）
print(f"イベント {events:,}件 / 取り込み {ingest_gb:.2f}GB / 取得 {retrieve_gb:.2f}GB / 保存 {storage_gb_month:.2f}GB-月")
print(f"新方式の月額: ${new:,.2f}")
print(f"旧方式の取り込みだけの額: ${old_ingest:,.2f}")
$ python stm_cost.py
イベント 200,000件 / 取り込み 2.40GB / 取得 6.00GB / 保存 0.40GB-月
新方式の月額: $3.64
旧方式の取り込みだけの額: $50.00

取り込みだけで比べても、20万イベントで50ドルだったものが2.4ドルに下がります。上限が64KBなので、新方式の取り込みは1イベントあたり最大0.000064ドルで、旧単価の0.00025ドルを超えることはありません。GBの換算を1,000,000KBで置いた概算のため、請求と突き合わせるときはCost Explorerの使用量で確認してください。保存費はTTLの長さに比例するので、発表文が勧めるとおり、短期メモリのリソースには業務に必要な日数だけのTTLを付けておきます。

Runtime V2のplatformVersion指定とスナップショット起動の手順

2026年9月18日、AWSは新しいAgentCore Runtimeの一般提供を発表しました。11月9日のAWS Weekly Roundupでも「AgentCore Runtime V2」として改めて取り上げられ、対応は10リージョンに広がっています。既存のランタイムは自動では切り替わりません。作成時か更新時にplatformVersionをV2にしたものだけが新しい方式で動く、オプトイン型の変更です。ここまでの比較表と試算はV1（既定）の前提なので、V2で何が変わるかを順に並べます。

V1とV2の違いはスナップショット復元と使った分だけのメモリ課金

V2は、ランタイムを作成・更新したときに環境を一度だけ準備してスナップショットを取り、新しいセッションのたびにそのスナップショットから復元して起動します。毎回イメージを読み込んで初期化するV1と比べ、イメージが大きくても起動時間がそろうのが利点です。メモリは小さく始めて必要なときに足し、使わなくなった分は返す動きになり、ピーク時の量を持ち続けるV1の課金とは考え方が変わります。

項目 V1（既定） V2（オプトイン）
起動のしかた セッションごとに初期化 スナップショットから復元
コールドスタートP75 約5.4〜30秒 約1.9〜2.0秒
メモリの課金 ピーク時の量を保持 使った分・アイドル120秒で回収
東京のvCPU単価 0.0895ドル/時 0.1276ドル/時
東京のメモリ単価 0.00945ドル/GB時 0.0169ドル/GB時
作成・更新の所要 数秒でREADY 数分（スナップショット準備）
起動時の条件 特記なし 120秒以内に/pingで正常応答

コールドスタートの数値は、GAの発表にあるAWS社内テストの値で、200MB〜2GBのコンテナイメージを対象にしています。V1はイメージが大きくなるほど約5.4秒からほぼ30秒まで延び、V2は同じ範囲で約2秒を保ったという内容です。仕組みと設計の背景はAWS Machine Learning Blogの解説記事が詳しく書いています。東京の単価は2026年11月10日にPrice List APIで取得した値で、使用タイプ名はAPN1-Runtime:Consumption-based:vCPU-v2とMemory-v2です。メモリが120秒のアイドルで回収される点は料金ページの記載によります。

起動の速さを「スナップショットで初期化済みの状態から始める」ことで稼ぐ発想は、関数型サーバーレスのコールドスタート対策と同じ系統です。コールドスタートが何に左右されるかという基本はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説で整理しています。

platformVersion=V2で作成後READYまで待つCLIとboto3の例

Platform versionsの説明に沿うと、AWS CLIではcreate-agent-runtimeに--platform-version V2を足します。npm版agentcore CLIからV2を指定する方法は今回の確認範囲では見つけられなかったため、ここではAWS CLIとboto3の例を載せます。アカウントID・ロール名・イメージURIは自分の環境の値への置き換えが必要です。

# 東京リージョンにV2のランタイムを作る（コンテナ版。CodeZip版も同じくplatformVersionで指定する）
aws bedrock-agentcore-control create-agent-runtime \
  --region ap-northeast-1 \
  --agent-runtime-name "invoice_agent_v2" \
  --role-arn "arn:aws:iam::123456789012:role/AgentExecutionRole" \
  --agent-runtime-artifact '{
    "containerConfiguration": {
      "containerUri": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/invoice-agent:latest"
    }
  }' \
  --network-configuration '{"networkMode": "PUBLIC"}' \
  --platform-version V2

# どちらの方式で動いているかを確かめる
aws bedrock-agentcore-control get-agent-runtime \
  --region ap-northeast-1 \
  --agent-runtime-id invoice_agent_v2-ABCDE12345 \
  --query platformVersion

V2の作成と更新は、スナップショットの準備のために数分かかります。作成APIはCREATINGのまま戻ってくるので、その状態で更新や削除を呼ぶと、返されるのはConflictExceptionです。デプロイのスクリプトには、終端の状態になるまで待つ処理を入れておきます。

import time

import boto3

client = boto3.client("bedrock-agentcore-control", region_name="ap-northeast-1")


def wait_until_ready(agent_runtime_id: str, timeout_sec: int = 900) -> str:
    """V2は作成・更新に数分かかるため、READYかFAILEDになるまで待つ"""
    deadline = time.monotonic() + timeout_sec
    while time.monotonic() < deadline:
        status = client.get_agent_runtime(agentRuntimeId=agent_runtime_id)["status"]
        if status == "READY" or status.endswith("FAILED"):
            return status
        time.sleep(5)
    raise TimeoutError(f"{agent_runtime_id} が {timeout_sec} 秒以内にREADYになりませんでした")


print(wait_until_ready("invoice_agent_v2-ABCDE12345"))

既存のランタイムを移すときは、更新のときにplatformVersionをV2にします。更新で値を省くと、それまでの方式がそのまま引き継がれます。V1へ戻すのも同じ更新操作です。ドキュメントによると、古いバージョンのスナップショットは既存のセッションが終わってから消され、消えるまで最長8時間かかります。

スナップショット前提で初期化処理と要求ごとの処理を分ける書き方

V2で一番手を入れる必要があるのは、エージェントのコードです。V2向けにエージェントのコードを調整する公式ガイドは、起動時に動いた処理の結果がスナップショットに焼き込まれ、復元されたすべてのインスタンスで共有されると説明しています。起動時に作った乱数・ID・時刻・認証情報は、全インスタンスで同じ値になるということです。

AgentCoreは最初に/pingが正常を返した時点でスナップショットを取ります。起動から120秒以内に正常を返せないと、ランタイムの作成はヘルスチェックのエラーによる失敗です。重いモデルの読み込みを起動時に寄せるのは正しい方向ですが、120秒に収まるかは先に測っておきます。分け方の目安は次のコードのとおりです。

import json
import os
import pathlib
import time

import boto3
from bedrock_agentcore.runtime import BedrockAgentCoreApp

# ── 起動時（スナップショットに入る）: 毎回同じで、期限切れにならないものだけ ──
SETTINGS = json.loads((pathlib.Path(__file__).parent / "agent.json").read_text())
s3 = boto3.client("s3", region_name="ap-northeast-1")  # クライアントの組み立ては起動時でよい

app = BedrockAgentCoreApp()


@app.entrypoint
def invoke(payload):
    # ── 要求ごと: インスタンス間で同じ値になってはいけないもの ──
    request_id = os.urandom(16).hex()   # OSから毎回取る。起動時に作ったIDは全インスタンスで重複する
    started = time.time()               # 現在時刻は要求の中で取る（起動時の時刻は固定される）
    # ツール一覧など、再デプロイせずに変わる情報はここで取得する
    # （起動時にキャッシュすると、スナップショット時点の一覧で固定される）
    answer = {"request_id": request_id, "prompt": payload.get("prompt", "")}
    answer["elapsed_ms"] = int((time.time() - started) * 1000)
    return answer


app.run()  # 8080番で待ち受けを始める。スナップショットはこの後に取られる

ガイドに記載されているのは、ほかにも見落としやすい次の注意事項です。復元したインスタンスはどれもホスト名がlocalhost、プロセスIDが1になるため、ログやロックの所有者の識別に使うと全インスタンスが同じものとして扱われます。time.monotonic()は復元をまたいで進まないので、経過時間の基準も要求の中で取る必要があるということです。Node.jsではcrypto.randomUUID()などOpenSSL由来の乱数が要求の中で呼んでもインスタンス間で重複しうるため、/dev/urandomから読むよう求めています。セッションIDやトークンをエージェント側で発行している実装は、V2へ移す前にこの点を必ず見直します。

Gatewayと組み合わせる場合の注意も1つあります。Gatewayから取ったツール一覧を起動時にキャッシュすると、スナップショットの時点の一覧で固定され、Gateway側でツールを足しても反映されません。前の章で扱ったフォールバックのルールのように運用中に変える設定は、要求の中で読むか、変更のたびにランタイムを更新して新しいスナップショットを作る運用にします。

V2の東京単価で月1万セッションの停止条件別に試算をやり直した結果

Weekly Roundupは「単価は上がるが、GB時間の消費が大きく減るので、多くのエージェントで請求は下がる見込み」と書いていますが、保証はしていません。前の章と同じ条件（月1万セッション・1セッション300秒・CPU稼働率0.3・1vCPU）で、V2の平均メモリ使用量を変えながら計算し直しました。

"""AgentCore Runtime V1とV2の月額概算（東京・実行基盤部分のみ）"""
import json
import urllib.request

SESSIONS = 10_000      # 月間セッション数
SESSION_SEC = 300      # 1セッションの実行時間（秒）
CPU_ACTIVE = 0.3       # CPUが実際に動いている割合
VCPU = 1
PEAK_MEM_GB = 2        # V1はピーク時のメモリを持ち続ける前提
IDLE_V1_SEC = 900      # V1で停止しない場合のアイドル（既定値）
IDLE_V2_SEC = 120      # V2はアイドル120秒でメモリを回収

URL = ("https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/"
       "AmazonBedrockAgentCore/current/ap-northeast-1/index.json")
with urllib.request.urlopen(URL, timeout=60) as r:
    offer = json.load(r)

price = {}
for sku, prod in offer["products"].items():
    ut = prod["attributes"].get("usagetype", "")
    if ut.startswith("APN1-Runtime:Consumption-based:"):
        term = next(iter(offer["terms"]["OnDemand"][sku].values()))
        dim = next(iter(term["priceDimensions"].values()))
        price[ut.rsplit(":", 1)[1]] = float(dim["pricePerUnit"]["USD"])

hours = SESSIONS * SESSION_SEC / 3600
cpu_h = hours * VCPU * CPU_ACTIVE
print(f"AWS単価 {offer['publicationDate'][:10]}: {price}")

v1 = cpu_h * price["vCPU"] + hours * PEAK_MEM_GB * price["Memory"]
v1_idle = v1 + SESSIONS * IDLE_V1_SEC / 3600 * PEAK_MEM_GB * price["Memory"]
print(f"V1 停止する: ${v1:,.2f} / 停止しない: ${v1_idle:,.2f}")

# V2は実際に使っているメモリだけが課金される。平均使用量を変えて比べる
for avg_mem in (2.0, 1.0, 0.5):
    v2 = cpu_h * price["vCPU-v2"] + hours * avg_mem * price["Memory-v2"]
    v2_idle = v2 + SESSIONS * IDLE_V2_SEC / 3600 * avg_mem * price["Memory-v2"]
    print(f"V2 平均{avg_mem}GB 停止する: ${v2:,.2f} / 停止しない: ${v2_idle:,.2f}")

# 停止する運用でV1と同額になるV2の平均メモリ
breakeven = (v1 - cpu_h * price["vCPU-v2"]) / (hours * price["Memory-v2"])
print(f"損益分岐の平均メモリ: {breakeven:.2f}GB")
$ python agentcore_v1_v2_cost.py
AWS単価 2026-11-05: {'Memory': 0.00945, 'vCPU-v2': 0.1276, 'Memory-v2': 0.0169, 'vCPU': 0.0895}
V1 停止する: $38.12 / 停止しない: $85.38
V2 平均2.0GB 停止する: $60.07 / 停止しない: $71.33
V2 平均1.0GB 停止する: $45.98 / 停止しない: $51.62
V2 平均0.5GB 停止する: $38.94 / 停止しない: $41.76
損益分岐の平均メモリ: 0.44GB

読み方は2通りに分かれます。StopRuntimeSessionを確実に呼べるアプリでは、V2の平均メモリが約0.44GB以下まで下がらない限り、V1のほうが安い結果でした。ピーク2GBのエージェントが平均でも2GB近く使い続けるなら、V2は約1.6倍になります。一方、停止を呼べない場合は様子が逆で、V1の85.38ドルに対し、V2は平均2GBのままでも71.33ドルに収まります。V2はアイドルのメモリを120秒で回収するため、900秒の待ちがまるごと請求に乗るV1より傷が浅いのです。この試算では回収までの120秒を平均メモリのまま数えており、実際の請求はこれより小さくなる側に振れます。

確約型のベースライン単価（vCPU 0.0997ドル、メモリ0.0132ドル）は、料金ページでは2026年10月までに提供予定と書かれています。ところが11月9日のWeekly Roundupでは「近日提供」の扱いで、11月10日時点のPrice List APIの東京データにもこの単価の使用タイプは見当たりませんでした。常に一定量が動く案件の見積もりにこの単価を入れるのは、提供が始まってからにします。

アイドル課金とセッション上限で請求が膨らむ条件・落とし穴と対処

比較表では見えにくい2つの落とし穴を、発生条件と対処の組で書きます。

StopRuntimeSessionを呼ばないと既定900秒のメモリ課金が続く

AgentCoreの料金ページは、課金対象の期間を「microVMの準備完了から、初期化、処理、アイドル期間を経てセッション終了まで」と定めています。V1ではアイドル中のメモリも解放されません。試算スクリプトで停止しない場合を足すと、月額は38.12ドルから85.38ドルへ増えました。

対処の手順は次の3段階です。第一に、会話の終わりが分かるアプリではstop_runtime_sessionを必ず呼びます。第二に、終わりが分からないチャットではidleRuntimeSessionTimeoutを見直します。公式の推奨表は対話型チャットで10〜15分、開発環境で5分としており、まず開発環境を既定の900秒から5分へ縮めるだけでも、検証中の請求は減る計算です。第三に、アイドル120秒でメモリを回収するRuntime V2へ切り替えます。前の章の試算どおり、V2は東京でvCPUが0.1276ドル、メモリが0.0169ドルと単価が上がるため、停止を呼べる画面ではかえって高くつきます。V2に寄せる対象は、停止を呼べない入口が多い場合と、イメージが大きくコールドスタートの待ちが利用者に見えている場合に限る方針です。どちらの方式でも、まずCloudWatchでセッションごとのアイドルの長さとメモリ使用量を測ってから決める流れです。

8時間を超えるバッチはInstancesか処理分割へ逃がす判断

microVMのセッションは最長8時間で、maxLifetimeに到達すると延長できません。V2でもこの上限は変わりません。夜間に数千件の書類を読むようなバッチを1セッションで回す設計は、ここで止まります。

逃がし方は2つです。1つは、EC2上で最長14日まで動かせるAgentCore Runtime Instancesへ移す方法です。東京も対象ですが、EC2のオンデマンド料金に12%の管理手数料が上乗せされます。もう1つは、キューで処理を小分けにし、1セッションを数十分で終える設計に変える方法です。単価が有利なのは後者で、失敗時にやり直す範囲も小さくなります。処理を小分けにするとセッションの起動回数が増えるため、起動待ちが積み上がる場合はV2のコールドスタートの短さが効いてきます。

Gateway経由のInvokeModel呼び出しとモデルフォールバックを比較に足す

2026年10月22日、AWSはAgentCore GatewayがBedrockのInvokeModel APIとモデルフォールバックに対応したと発表しました。これまでGatewayは、既存のLambdaやAPIをMCPツールとしてエージェントに渡す入口という位置づけでした。今回の対応で、モデル推論の呼び出しもGatewayの1つのエンドポイントにまとめられます。3基盤を比べる観点では「モデル障害への備えを基盤の設定で持てるか」が新たな比較軸になります。

InvokeModel対応で既存のBedrock SDK呼び出しをGatewayに寄せる

発表文によると、Gatewayの推論エンドポイントはInvokeModelとInvokeModelWithResponseStreamを受け付けます。既存のBedrock SDKの呼び出しは、接続先をGatewayへ向けるだけで済み、モデル提供元ごとにクライアントを書き直す必要はありません。対象は中国を除き、Gatewayが提供されているすべてのリージョンです。InvokeModel自体の書き方はBedrock Claudeの使い方：Messages API・InvokeModel・Claude Codeの設定で、Gatewayの推論ターゲットの作り方と接続設定は前出の8230の記事で扱っています。

この形は、複数のLLMを1つの入口で束ねる「LLMゲートウェイ」をAWSのマネージドサービスとして持つ構成です。役割の整理はAIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断に、同じことをOSSで自前運用する場合の構成はLiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定にあります。AWSの外のモデルも混ぜて使い、予算上限をキー単位で管理したいならLiteLLM、AWSのIAMとログの中で閉じたいならGatewayという分け方になります。

モデル障害時のフォールバック連鎖をGatewayルールで設定するCLI例

モデルのルーティングとフォールバックの公式ドキュメントでは、GatewayルールのrouteToTargetアクションにfallbackブロックを足して切り替え先の順番を決めます。次の例は、主ターゲットが429や5xxを返したとき、または最初の1バイトが5秒以内に返らないときに、別ターゲット、次に小さいモデルへ順に切り替える設定です。ターゲット名とモデルIDは、自分のGatewayに作った推論ターゲットの値に置き換えます。

aws bedrock-agentcore-control create-gateway-rule \
    --gateway-identifier GATEWAY_ID \
    --priority 100 \
    --description "primary model with 2-step fallback" \
    --conditions '[
        {"matchModels": {"anyOf": [{"value": "PRIMARY_MODEL_ID"}]}}
    ]' \
    --actions '[
        {
            "routeToTarget": {
                "staticRoute": {
                    "targetName": "primary-target",
                    "fallback": {
                        "circuitBreaker": {"mode": "ENABLED"},
                        "triggerOn": {
                            "statusCodes": ["5XX", "429"],
                            "errors": ["CONNECTION_ERROR", "FIRST_BYTE_TIMEOUT", "UNROUTABLE"]
                        },
                        "firstByteTimeoutMilliseconds": 5000,
                        "targetFallback": [
                            {"targetName": "secondary-target"},
                            {"targetName": "primary-target", "model": "SMALLER_MODEL_ID"}
                        ]
                    }
                }
            }
        }
    ]'

ドキュメントで決まっている制約は次のとおりです。targetFallbackに並べられる切り替え先は1〜2件です。statusCodesは4xxと5xxの範囲で1〜10個、errorsはCONNECTION_ERROR・FIRST_BYTE_TIMEOUT・UNROUTABLEの3種から選びます。主ターゲットと切り替え先は「ターゲットとモデルの組」がすべて異なる必要があり、同じ組を2回書いたルールは受け付けられません。

フォールバックの試行課金とストリーミング中は切り替わらない制約

比較で見落としやすいのは費用の数え方です。ドキュメントは、Gatewayが外へ出す1回の試行を1回のGateway呼び出しとして課金すると明記しています。主ターゲットで失敗して2番目で成功したリクエストは、Gateway呼び出し2回ぶんになり、各試行のモデル料金もBedrockやモデル提供元から別に請求されます。2026年10月31日時点の料金ページでは、Gatewayの推論呼び出しの単価は確認できませんでした。障害時の上振れを見積もるときは、試行回数とモデル料金の両方で数えます。

サーキットブレーカーは既定で有効です。障害中の主ターゲットを飛ばして次へ直行するので、失敗する試行の課金と待ち時間を減らせます。一方で、安い主ターゲットを使い続けたい場合はDISABLEDにして、高い切り替え先へ早々に流れないようにする選択肢も公式に挙がっています。もう1つの制約は、ストリーミングの応答が始まったあとは切り替わらない点です。利用者は途中までの応答とエラーを受け取り、アプリ側で再試行が必要になります。チャット画面で逐次表示するエージェントでは、この再試行の扱いを画面側で決めておきます。

呼び出し側から見ると、フォールバックは透過的です。1回のリクエストに1回の応答が返り、どの切り替え先が答えたかの印は応答に付きません。どこが応答したかはGatewayのルーティングログで確かめます。品質の差が出やすい「小さいモデルへの格下げ」を連鎖の最後に置く場合は、ログで格下げの発生率を監視する運用まで含めて設計します。

AgentCoreを採用する案件と他社基盤・自前実装を選ぶ案件の線引き

ここまでの仕様と料金を踏まえて、判断を言い切ります。

AgentCoreを選ぶ条件はAWSの業務データとIAMで閉じる案件

次の3つがそろえば、AgentCoreを選びます。業務データがS3・RDS・DynamoDBなどAWS側にあること。社内の認可をIAMとCognitoで組めること。1セッションが8時間以内に終わることです。Gatewayで既存のLambdaやAPIをMCPツールに変えられるので、社内システムとつなぐ作業の量が減ります。10月からは同じGatewayでモデル呼び出しのフォールバックも持てるようになり、「モデル側の障害時も止めたくない」という要件がある案件ほど、AgentCoreに寄せる理由が強くなった形です。エージェント同士をつなぐ設計が必要なら、Runtimeが対応するA2A（Agent2Agent）プロトコルも同時に検討します。

V1のまま使う案件とRuntime V2へ切り替える案件の分け方

AgentCoreを選んだあとは、V1とV2のどちらで動かすかを決めます。今回の試算と公式の説明から、次のように分けます。

  • 会話の終わりでStopRuntimeSessionを確実に呼べ、メモリ使用量がピークに近いまま推移する案件は、V1のまま使う
  • Webチャットのように利用者が黙って離れ、停止を呼べないセッションが多い案件は、V2へ切り替える
  • コンテナイメージが数百MB〜数GBあり、コールドスタートの待ちが利用者の体感に出ている案件は、V2へ切り替える
  • 起動時に乱数やIDを作る、ホスト名で個体を識別するなど、スナップショットと相性の悪いコードが多い案件は、直し終えるまでV1に留める

迷う場合は、開発用のランタイムを1つV2で作り、同じ負荷を流してCost Explorerで1週間分のGB時間を比べるのが確実です。V2の作成と更新には数分かかるため、CIのデプロイ待ち時間が延びる点も見積もりに入れます。

AgentCoreを見送るTeams配布・C#実装・Gemini配布・常駐型の4場面

AgentCoreを見送るのは次の場面です。

  • 利用者の入口がTeamsやMicrosoft 365で、Entra IDで権限を管理している案件（Foundry hosted agentsを選ぶ）
  • エージェント本体をC#で書く必要がある案件（C#の公式手順があるのはFoundryだけ）
  • Gemini Enterpriseの社内アプリに載せる案件（Google Agent Runtimeへの登録手順が公式に用意されている）
  • 24時間動き続ける常駐型で、I/O待ちが少ない案件（ECSなどで常時起動するほうが費用を読みやすい）

最後のケースでは、マネージド基盤を使う利点だったセッション隔離と従量課金が逆に働きます。V2で単価が上がった分、常駐型ではこの傾向がさらに強まります。LangGraphなどで状態管理を自前で持つ場合は、LangGraphでAIエージェントを実装する手順の構成をコンテナで動かすほうが素直です。モデルのフォールバックだけが目的で、エージェント基盤は別に持っている案件なら、AgentCore全体を採らずGatewayだけを使う構成も成り立ちます。どの基盤に載せるか決めきれない段階なら、AIエージェント開発の相談窓口で業務データの置き場所と配布経路から一緒に整理できます。

AgentCoreの料金・東京対応・他社基盤との比較検討でよくある質問

AgentCoreを他社基盤と比べる段階で出やすい質問に、2026年9月時点の公式情報で答えます。10月の変更点は10月31日時点、Runtime V2は11月10日時点の情報で追記しました。

AgentCoreは東京リージョンで使えますか？

使えます。AWSの対応リージョン表では、東京（ap-northeast-1）がRuntimeのmicroVMとInstances、Memory、Gateway、Identity、組み込みツール、Observability、ハーネスに対応しています。東京で使えないのはAgentCore paymentsです。Price List APIで取得した東京のRuntime単価は、V1でvCPUが1時間0.0895ドル、メモリが1GB時間0.00945ドル、V2でvCPUが0.1276ドル、メモリが0.0169ドルでした（2026年11月10日取得）。Runtime V2は9月18日のGA時点から東京が対象に入っています。10月22日に発表されたGatewayのInvokeModel対応とモデルフォールバックも、中国を除くGateway提供リージョンが対象なので、東京で使えます。

AgentCoreとVertex AI Agent Engineの違いは何ですか？

Vertex AI Agent Engineは、現在はGemini Enterprise Agent PlatformのAgent Runtimeという名前です。どちらもエージェントのマネージド実行基盤ですが、課金の考え方が違います。AgentCoreはI/O待ち中のCPUを課金せず、V2ではアイドルのメモリも120秒で回収します。Agent Runtimeは毎月50vCPU時間の無料枠があり、ターン間の待ちを課金しません。ADKで書くならGoogle、AWS上のデータとIAMで閉じるならAgentCoreが手戻りの少ない選択です。

AgentCoreの料金は無料で試せますか？

AgentCore単体の常設無料枠はありません。料金ページでは、新規のAWS顧客が最大200ドルの無料利用枠クレジットを使えると案内されています。検証だけなら、agentcore devでローカル実行し、デプロイ後はagentcore remove allとagentcore deployで片付けると課金期間を短くできます。Memoryの短期メモリは10月6日からGB単位の課金になり、小さな会話の検証なら数ドルに収まる規模です。Googleには毎月の無料枠があるため、無料で長く試したい場合はGoogle側が有利です。

Runtime V2に切り替えると料金は下がりますか？

使い方次第で、上がる場合もあります。V2は東京の単価がV1よりvCPUで約1.4倍、メモリで約1.8倍高く、その代わり使っていないメモリを返す課金です。本記事の月1万セッションの試算では、停止APIを呼ぶ運用だとV2の平均メモリが約0.44GB以下でないとV1より高くなりました。停止を呼べずアイドルが長く残る運用では、平均2GBのままでもV2のほうが安く収まります。切り替えはplatformVersionの更新だけで戻せるので、開発環境で1週間ほど両方を測ってから決めるのが確実です。

既存のLangGraphエージェントはどの基盤に移しやすいですか？

3基盤ともLangGraphを動かせるため、移しやすさはコードより周辺で決まります。AgentCoreはagentcore createでLangGraphを選べ、CodeZipならDockerも要りません。GoogleはLangGraphをSDK統合の対象に挙げています。Foundryはコンテナまたはコードで載せられますが、言語はPythonかC#です。会話履歴の保存先を基盤のメモリ機能に寄せるかどうかが、書き換えの量を左右する条件です。モデル呼び出しをBedrockのInvokeModelで書いているなら、AgentCoreに移す際に接続先をGatewayへ向けるだけでフォールバックを足せます。AgentCoreでV2を使う場合は、グラフの初期化で乱数やIDを作っていないかも確認します。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

ほか 2 件の記事からもリンクされています。

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.09　テックブログ エディオン不正アクセス第2報：カード番号の対象確認とログ・決済画面の改ざん対策
  2. 2026.11.10　テックブログ ニトリの情報漏洩：最大3,762万件の対象確認となりすまし連絡の見分け方
  3. 2026.11.10　テックブログ Claude Fable 5.2とは：料金・破壊的変更4点とFable 5.1からの移行手順【2026年11月】
  4. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  5. 2026.11.09　テックブログ LANSCOPE不正アクセス第2報：製品への影響と偽連絡の確認、停止中のライセンス認証の窓口

RELATED POSTS 関連記事

一覧へ戻る

目次