2026.09.25 プラットフォーム

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

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

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

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

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

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

配布先が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です。AgentCore全体の構成やSDKの使い方はAmazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイで扱っています。

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

3基盤とも、1セッションに専用の隔離環境を割り当てます。違うのは、その環境がどれだけ生き続け、止まったあと何が残るかです。

項目 AgentCore Runtime Google Agent Runtime Foundry hosted agents
隔離の単位 セッションごとのmicroVM reasoningEngineリソース セッションごとのVM隔離サンドボックス
1回の上限時間 最長8時間（Instancesは14日） クォータページで確認 記載なし（アイドルで停止）
アイドル既定値 900秒（60〜28,800秒） ターン間の待ちは課金外 15分（2〜60分）
停止後に残るもの 既定は消去（設定で保持） 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・Memory・Gateway・Identity・ハーネスなどに対応しています。paymentsだけは東京が対象外でした。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をそのまま打っても動きません。

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とは？AWS製OSSエージェントSDKの使い方が参考になります。コードを書かずに設定ファイルだけで動かす経路もあり、そちらはBedrock AgentCoreハーネスGAの解説にまとめています。

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リファレンスで確認できます。

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日更新のクイックスタートどおりですが、新規案件では新パッケージ側の書き方も確認してから採用を決めます。ADK自体の設計はVertex AI Agent Builderとは？Gemini Enterprise Agent Platform改称後の全体像で整理しています。

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は東日本）の単価を取り、同じワークロードで月額を出します。

東京と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のデータでした。

$ 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単価の差だけで基盤を決めないでください。

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

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

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

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

対処の手順は次の3段階です。第一に、会話の終わりが分かるアプリではstop_runtime_sessionを必ず呼びます。第二に、終わりが分からないチャットではidleRuntimeSessionTimeoutを見直します。公式の推奨表は対話型チャットで10〜15分、開発環境で5分としており、まず開発環境を既定の900秒から5分へ縮めるだけでも、検証中の請求は減る計算です。第三に、アイドル120秒でメモリを回収するmicroVM v2を検討します。v2は東京でvCPUが0.1276ドル、メモリが0.0169ドルと単価は上がるため、アイドルの長さを測ってから切り替えます。

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

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

逃がし方は2つです。1つは、EC2上で最長14日まで動かせるAgentCore Runtime Instancesへ移す方法です。東京も対象ですが、EC2のオンデマンド料金に12%の管理手数料が上乗せされます。もう1つは、キューで処理を小分けにし、1セッションを数十分で終える設計に変える方法です。単価が有利なのは後者で、失敗時にやり直す範囲も小さくなります。

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

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

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

次の3つがそろえば、AgentCoreを選びます。業務データがS3・RDS・DynamoDBなどAWS側にあること。社内の認可をIAMとCognitoで組めること。1セッションが8時間以内に終わることです。Gatewayで既存のLambdaやAPIをMCPツールに変えられるので、社内システムとつなぐ作業の量が減ります。エージェント同士をつなぐ設計が必要なら、Runtimeが対応するA2A（Agent2Agent）プロトコルも同時に検討します。

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などで常時起動するほうが費用を読みやすい）

最後のケースでは、マネージド基盤を使う利点だったセッション隔離と従量課金が逆に働きます。LangGraphなどで状態管理を自前で持つ場合は、LangGraphでAIエージェントを実装する手順の構成をコンテナで動かすほうが素直です。どの基盤に載せるか決めきれない段階なら、AIエージェント開発の相談窓口で業務データの置き場所と配布経路から一緒に整理できます。

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

AgentCoreを他社基盤と比べる段階で出やすい質問に、2026年9月時点の公式情報で答えます。

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

使えます。AWSの対応リージョン表では、東京（ap-northeast-1）がRuntimeのmicroVMとInstances、Memory、Gateway、Identity、組み込みツール、Observability、ハーネスに対応しています。東京で使えないのはAgentCore paymentsです。Price List APIで取得した東京のRuntime単価は、microVM v1でvCPUが1時間0.0895ドル、メモリが1GB時間0.00945ドルで、米国リージョンの公表値と同じでした。

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

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

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

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

agentcore configureやagentcore launchが動かないのはなぜですか？

これらは旧pip版のスターターツールキットのコマンドです。2026年9月時点の公式手順は、npmの@aws/agentcoreを入れてagentcore create・agentcore dev・agentcore deploy・agentcore invokeの順に使います。両方が入っていると旧版が先に呼ばれることがあるため、pip uninstall bedrock-agentcore-starter-toolkitで旧版を消してから新しい端末を開きます。

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

3基盤ともLangGraphを動かせるため、移しやすさはコードより周辺で決まります。AgentCoreはagentcore createでLangGraphを選べ、CodeZipならDockerも要りません。GoogleはLangGraphをSDK統合の対象に挙げています。Foundryはコンテナまたはコードで載せられますが、言語はPythonかC#です。会話履歴の保存先を基盤のメモリ機能に寄せるかどうかで、書き換えの量が変わります。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る