Google Cloud

Vertex AI Agent Engine（現Agent Runtime）の使い方：ADKデプロイと料金

Vertex AI Agent Engine（現Agent Runtime）の使い方：ADKデプロイと料金

Vertex AI Agent Engineは、2026年4月22日付でAgent Runtimeへ改称されました。ADKやLangGraphで書いたエージェントをGoogle Cloudにデプロイし、会話履歴（Sessions）と長期記憶（Memory Bank）までまとめて預けられるマネージド実行基盤です。本記事では、2026年9月に分離された新SDK「google-cloud-agentplatform」でのデプロイ手順、インスタンス数とリソースの決め方、セッションの有効期限とMemory Bankの組み込み、vCPU時間とGiB時間から月額を試算する方法を、2026年10月時点の公式ドキュメントで整理します。

まとめ：Vertex AI Agent EngineでADKエージェントを本番に出す要点

先に結論です。コードは「エージェントを書く→AdkAppで包む→runtimes.createでデプロイ→streamQueryで呼ぶ」の4段で済みます。手間がかかるのは、既定値のまま出すと困る設定の見直しです。

  • Agent EngineはAgent Runtimeに改称済みです。REST APIのリソース名はreasoningEnginesのまま残っています。
  • 2026年9月18日のSDK 2.0.1で、エージェント機能はgoogle-cloud-agentplatformに分かれました。client.agent_engines.createはclient.runtimes.createに読み替えます。
  • リソース上限の既定値は1コンテナ4vCPU・4GiBです。軽いエージェントなら下げるだけで単価が下がります。
  • セッションは有効期限を指定しないと365日残ります。保存料がかかるため、用途に合わせてTTLを短くします。
  • 単価はvCPU時間0.085ドル、GiB時間0.009ドルで、毎月50vCPU時間と100GiB時間は無料です。月1万会話程度ならランタイム費は数十ドルに収まり、費用の大半はモデルのトークン料金です。

Vertex AI Agent EngineのAgent Runtimeへの改称と構成

検索で見つかる手順の多くは、改称とSDK分離の前に書かれています。

2026年4月の改称と9月のSDK分離で変わったAPI名の対応表

Gemini Enterprise Agent Platformのリリースノートには、2026年4月22日の項に「Agent Engine is now Agent Runtime」とあります。同じ日の名称対応表で、Vertex AI Agent Engine SessionsはAgent Platform Sessions、Vertex AI Agent Engine Memory BankはAgent Platform Memory Bankになりました。プラットフォーム全体の改称と4本柱の関係はVertex AI Agent Builder（Agent Platform）の全体像で解説しています。

コードに響くのは、9月18日のSDK 2.0.1です。Agent Platform SDK 2.0.1の移行ガイドは、エージェント用途にはgoogle-cloud-agentplatformを推奨インストールとし、属性パスの対応表を載せています。

  • デプロイ：client.agent_engines.create → client.runtimes.create
  • セッション：client.agent_engines.sessions → client.sessions
  • 記憶：client.agent_engines.memories → client.memory_banks.memories
  • リビジョン：client.agent_engines.runtimes.revisions → client.runtimes.revisions
  • フレームワークのテンプレート：agentplatform.agent_engines.templates → agentplatform.frameworks

移行ガイドによれば、新SDKはvertexai.init()のグローバル設定を読みません。プロジェクトとリージョンはagentplatform.Clientに毎回渡します。旧SDKで書かれた記事のコードを写すと、この差で動かないことがあります。

Runtime・Sessions・Memory Bankの3部品と東京リージョン対応

Agent Runtimeは、エージェントのコードを動かすRuntime、会話の履歴を持つSessions、ユーザーごとの長期記憶を持つMemory Bankの3部品を中心に組まれています。デプロイできるフレームワークは、ADK・A2A・LangChain・LangGraph・AG2・LlamaIndexとカスタムです。

国内案件で気になるのはリージョンです。エージェントのサポートロケーション一覧では、asia-northeast1（東京）はv1がGA、v1beta1がプレビュー機能の対象です。Memory Bank非対応を示す印も付いておらず、東京で3部品をそろえられます。モデル選びを含むVertex AI全体の構成はVertex AIの機能・料金とSageMaker・Azure MLとの違いにまとめています。

ADKエージェントをAgent Runtimeへデプロイする手順とPythonコード

ADKを使うAgent Runtimeのクイックスタート（2026年10月15日更新）に沿いつつ、新SDKの書き方に置き換えて示します。

API有効化とIAMロール2つ・ステージング用バケットの事前準備

有効にするAPIはaiplatform.googleapis.comとstorage.googleapis.comの2つです。デプロイする人には、Agent Platformユーザー（roles/aiplatform.user）とストレージ管理者（roles/storage.admin）のロールを付けます。ステージング用バケットは、デプロイ時にコードと依存関係の成果物を置く場所です。

# APIを有効化し、ステージング用バケットを東京に作る
gcloud config set project your-project-id
gcloud services enable aiplatform.googleapis.com storage.googleapis.com
gcloud storage buckets create gs://your-agent-staging --location=asia-northeast1

# ローカルの認証情報と、エージェント用SDK・ADKを用意する
gcloud auth application-default login
pip install --upgrade "google-cloud-agentplatform[adk]"

google-cloud-agentplatformの最新版は2026年10月14日公開の2.5.0です。PyPIのメタデータを見ると、extrasはadk・a2a・agent-engines・langchainなど10種類で、adkを指定するとagent-enginesとgoogle-adk（最新は2.12.0）も入ります。

AdkAppでエージェントを包みasync_stream_queryで試すローカル検証

エージェントの中身は通常のADKのコードです。AdkAppで包むと、デプロイ後と同じ呼び出し方でローカル実行できます。ローカルではセッションがメモリ上に作られ、プロセスを終えると消えます。

import asyncio
import agentplatform
from agentplatform.frameworks import AdkApp
from google.adk.agents import Agent

client = agentplatform.Client(project="your-project-id", location="asia-northeast1")

def get_leave_balance(employee_id: str) -> dict:
    """社員番号から有給休暇の残日数を返す（実装は社内APIに置き換える）"""
    return {"employee_id": employee_id, "remaining_days": 12}

agent = Agent(
    model="gemini-3.5-flash",
    name="hr_helpdesk",
    instruction="社内規程に沿って日本語で簡潔に答える。分からないときは分からないと答える。",
    tools=[get_leave_balance],
)
app = AdkApp(agent=agent)

async def main():
    async for event in app.async_stream_query(user_id="emp-0042", message="有給はあと何日ありますか"):
        print(event)

asyncio.run(main())

user_idはアプリ側で決める利用者IDで、クイックスタートの記載では128文字以内です。社員番号やメールアドレスをそのまま入れず、仮名化したIDを渡す設計にしておくと、後でMemory Bankを足すときにも困りません。エージェント定義の書き方そのものはADKの仕組みと始め方で詳しく扱っています。

runtimes.createでデプロイしcurlのstreamQueryから呼ぶ手順

ローカルで動いたら、同じappをclient.runtimes.createに渡します。デプロイには数分かかり、終わるとREST APIではreasoningEnginesのリソースとして見えます。

remote = client.runtimes.create(
    agent=app,
    config={
        "display_name": "hr-helpdesk",
        "staging_bucket": "gs://your-agent-staging",
        "requirements": ["google-cloud-agentplatform[adk]==2.5.0"],
        "env_vars": {"HR_API_BASE": "https://hr.example.internal"},
    },
)
print(remote.api_resource.name)  # projects/.../locations/asia-northeast1/reasoningEngines/数字のID

アプリケーションやバッチから呼ぶときは、ADKエージェントを使用する公式ページにあるstreamQueryのエンドポイントを使います。alt=sseを付けると、イベントがサーバー送信イベントで1件ずつ届きます。

LOCATION=asia-northeast1
RESOURCE_ID=1234567890123456789

curl -N \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://${LOCATION}-aiplatform.googleapis.com/v1/projects/your-project-id/locations/${LOCATION}/reasoningEngines/${RESOURCE_ID}:streamQuery?alt=sse" \
  -d '{"class_method": "async_stream_query", "input": {"user_id": "emp-0042", "message": "有給はあと何日ありますか"}}'

検証が終わったらremote.delete(force=True)で消します。force=Trueを付けると、デプロイ時に自動で作られたセッションのリソースも一緒に削除されます。

requirementsとインスタンス数を決めるデプロイ設定の既定値

エージェントをデプロイする公式ページには、configに渡せる項目と既定値が並んでいます。既定値のまま本番に出してよいものと、見直すべきものを分けます。

公式サンプルのruntimes extraと依存バージョンを固定する理由

Memory BankのADKクイックスタートは、requirementsの例にgoogle-cloud-agentplatform[runtimes,adk]を載せています。ところが2026年10月17日時点のPyPIのメタデータには、runtimesというextraがありません。pipは存在しないextraを警告付きで無視するため、実害は出にくいものの、依存の指定としては[adk]だけで足ります。

デプロイの公式ページは、再現できるビルドのためにバージョンを固定するよう勧めています。デプロイ先ではrequirementsから依存を入れ直すため、手元とデプロイ先で版がずれると、ローカルで通ったエージェントが起動時に落ちることがあります。手元のpip freezeからADKとSDKの版を拾い、==で書いてください。自作モジュールはextra_packagesにディレクトリを指定して同梱し、APIキーなどの秘密情報はenv_varsからSecret Managerのシークレットを参照させます。

min_instances既定1・resource_limits既定4vCPUの調整基準

項目 範囲 既定値
min_instances 0〜10 1
max_instances 1〜1000 100
resource_limitsのcpu 1・2・4・6・8 4
resource_limitsのmemory 1Gi〜32Gi 4Gi
container_concurrency 推奨は2×cpu＋1 9

最初に見直すのはresource_limitsです。モデル呼び出しと軽いAPI呼び出しを待つだけのエージェントなら、4vCPUは持て余します。課金は割り当てたvCPUとメモリに比例するので、負荷試験で足りる値まで下げます。cpuを下げたら、container_concurrencyも推奨式に合わせて変えてください。

min_instancesの既定値1については、公式ページに「プレビューの間はアイドル時間を請求しないが、今後変わる可能性がある」という注記があります。いまは1のままでも請求は増えませんが、課金方式が変わった日に固定費が生まれます。既定値に任せず、値を明示して書いておくと変更に気づきやすいです。社外向けで急な流入がありうるなら、max_instancesを上限として明示し、想定外の同時実行による請求の跳ね上がりも抑えます。

Sessionsで会話履歴を持たせMemory Bankで長期記憶を足す実装

ADKのエージェントをAgent Runtimeに出すと、セッション管理は自動で引き受けられます。手を入れるのは、保存期間と、会話をまたいで覚えさせる情報の範囲です。

user_idごとのセッション作成と既定365日のTTLを短くする設定

セッションをAPIで管理する公式ページによると、すべてのセッションに有効期限があり、指定しなければ既定で365日です。期限が来ると、セッションと配下のイベントは自動で消えます。問い合わせ窓口のように1回で完結する会話なら、7日程度で十分です。

import asyncio
import agentplatform

client = agentplatform.Client(project="your-project-id", location="asia-northeast1")

# 作成から7日で自動削除されるセッションを作る
session = client.sessions.create(
    name=remote.api_resource.name,
    user_id="emp-0042",
    config={"ttl": f"{7 * 24 * 60 * 60}s"},
)

# 同じ利用者の会話一覧を取り、続きから再開するセッションを選ぶ
async def list_my_sessions():
    response = await remote.async_list_sessions(user_id="emp-0042")
    for s in response.sessions:
        print(s)

asyncio.run(list_my_sessions())

TTLは作成時か更新時に決まり、更新した場合は更新時刻から数え直します。問い合わせ内容に個人情報が混ざるなら、保存期間を決める基準は社内の保管規程です。長い会話でコンテキストがふくらむ問題は、ADKのコンテキスト圧縮と停止・再開の設定で抑えられます。

PreloadMemoryToolとコールバックでMemory Bankに記憶を書き込む

Memory Bankの概要ページによれば、Memory Bankは会話からLLMで要点を抜き出し、ユーザーなどのスコープごとに分けて保存します。ADKのクイックスタートでは、runtimes.createでデプロイすると空のMemory Bankも一緒に作られます。エージェント側は、取り出すツールと書き込むコールバックを足すだけです。

from google.adk.agents import Agent
from google.adk.agents.callback_context import CallbackContext
from google.adk.tools.preload_memory_tool import PreloadMemoryTool

async def remember_recent_turns(callback_context: CallbackContext):
    # 直近の数イベントだけを渡す（同じイベントを何度も処理させない）
    await callback_context.add_events_to_memory(events=callback_context.session.events[-5:-1])
    return None

agent = Agent(
    model="gemini-3.5-flash",
    name="hr_helpdesk",
    instruction="社内規程に沿って日本語で簡潔に答える。",
    tools=[get_leave_balance, PreloadMemoryTool()],  # 毎ターンの最初に記憶を読み込む
    after_agent_callback=remember_recent_turns,
)

クイックスタートは、セッション全体を送るadd_session_to_memoryより、差分のイベントを送るadd_events_to_memoryを推奨しています。記憶の生成は非同期で、エージェントの応答を待たせません。読み込みは毎ターン実行するPreloadMemoryToolと、モデルが必要と判断したときだけ呼ぶLoadMemoryToolから選べます。

注意点もあります。概要ページは、誤った情報や悪意のある情報が記憶に入り、後の会話で使われる「メモリポイズニング」のリスクを挙げています。権限の判定や金額の計算など、記憶の内容を信じて動くと事故になる処理は、記憶ではなく業務システムの正本を参照させてください。

Agent Runtimeの料金体系と月1万会話の費用を試算する計算例

料金はGemini Enterprise Agent Platformの料金ページにあります。Runtime・Sessions・Memory Bankはどれも、コンピューティング・メモリ・ストレージの共通の単価で課金されます。

vCPU時間0.085ドルとGiB時間0.009ドルの単価と毎月の無料枠

リソース 単価（米ドル） 毎月の無料枠
エージェントコンピューティング 0.085／vCPU時間 50vCPU時間
エージェントメモリ（RAM） 0.009／GiB時間 100GiB時間
エージェントストレージ 0.30／GiB月 1GiB月

使用量は秒単位に丸められ、会話のターンとターンの間で次の入力を待つアイドル時間は課金されません。SessionsとMemory Bankは2026年9月1日に課金が始まりました。読み取りは300万回ごと、書き込みは100万回ごとに1vCPU時間として数えます。Memory Bankが記憶の生成や埋め込みに使うモデルのトークンは、各モデルの料金で別に請求されます。

月1万会話・1会話5往復で試算したランタイム費とモデル費の比率

仮定を置いて試算します。月1万会話、1会話5往復、1往復の処理時間8秒、リソース上限は既定の4vCPU・4GiB、リクエストどうしが重ならない場合の上限見積もりです。

# Agent Runtimeのランタイム費を見積もる（単価は2026年10月時点の料金ページ）
conversations, turns, sec_per_turn = 10_000, 5, 8
vcpu, mem_gib = 4, 4

hours = conversations * turns * sec_per_turn / 3600   # 約111.1時間
vcpu_cost = max(hours * vcpu - 50, 0) * 0.085          # 無料50vCPU時間を引く
mem_cost = max(hours * mem_gib - 100, 0) * 0.009       # 無料100GiB時間を引く
print(round(vcpu_cost, 2), round(mem_cost, 2))         # 33.52 3.1

ランタイム費は月約37ドルです。リソース上限を1vCPU・2GiBに下げられれば、同じ計算で月10ドルを切ります。CPU数ごとに設定できるメモリ量は、デプロイの公式ページからたどれる表で確認してください。セッションの書き込みは1往復で数件のイベントなので、5万往復でも数十万回、vCPU時間に直して1時間未満です。

この規模で請求の大半を占めるのは、Geminiなどのモデルのトークン料金です。予算を組むときは、ランタイムより先にモデルの選択と1往復あたりのトークン数を詰めてください。モデルの窓口と料金の違いはVertex AIとGemini APIの違いで比べています。

Agent Runtimeを採用する条件とCloud Runや他社基盤を選ぶ場面

ここまでの仕様と料金を前提に、使う場面と使わない場面を言い切ります。

ADKで書いた社内エージェントを少人数で運用する場合の採用条件

採用してよいのは、次の条件がそろうときです。エージェントをPythonのADKかLangGraphで書いている、業務データがGoogle Cloudか社内APIにある、会話履歴と記憶の保存先を自前で作る人手がない。この場合、セッション用のデータベースとオートスケールの設定を自分で組むより、runtimes.create1回のほうが早く本番に出せます。2026年4月には最大7日の長時間処理と1分未満のプロビジョニングにも対応し、5月にはリビジョンとトラフィック分割がプレビューで加わったため、段階的な切り替えも基盤側で扱えます。

どの業務をエージェントに任せるかの切り分けから、ツール連携・権限設計・Agent Runtimeへの載せ方までをまとめて相談したい場合は、一創のAIエージェント開発で、既存の業務システムと接続する構成から検討できます。

AWS中心の業務データや独自の実行環境が要る場合の見送り判断

見送るのは、業務データとIAMがAWSに集まっている案件です。エージェントだけGoogle Cloudに置くと、データの持ち出しと認証の橋渡しが増えます。その場合はAmazon Bedrock AgentCoreが候補で、料金と上限の差はAgentCore・Google Agent Runtime・Foundryの比較で並べています。

OSのパッケージや常駐プロセスを自由に入れたい、既存のコンテナ運用にそろえたい、という場合もAgent Runtimeは過剰な抽象化です。カスタムコンテナは使えるようになったものの、ADKのエージェントは同じコードのままCloud RunやGKEにも載せられます。セッションをFirestoreなどに自分で置く手間を受け入れられるなら、既存の監視や配備の仕組みに合わせたほうが運用は単純です。

Vertex AI Agent Engine（Agent Runtime）のよくある質問

Agent Runtimeを使い始めるときに出やすい疑問に、公式ドキュメントの記載をもとに答えます。

Vertex AI Agent EngineとAgent Runtimeは別の製品ですか？

同じ製品です。2026年4月22日のリリースノートで、Agent EngineはAgent Runtimeへ改称されました。REST APIのリソース名はreasoningEnginesのままで、デプロイ済みのエージェントを作り直す必要はありません。変わったのはPython SDKのパッケージ名と属性パスで、2026年9月18日の2.0.1以降はgoogle-cloud-agentplatformのclient.runtimesを使います。

Agent Runtimeは無料で試せますか？

毎月50vCPU時間・100GiB時間・ストレージ1GiB月まではアカウントごとに無料です。既定の4vCPUなら約12時間分の処理に当たり、動作確認には十分な量です。ただし課金を有効にしたプロジェクトが前提で、エージェントが呼ぶGeminiのトークン料金は無料枠とは別に請求されます。

東京リージョンでAgent RuntimeとMemory Bankを使えますか？

使えます。サポートロケーション一覧では、asia-northeast1はv1がGAで、Memory Bank非対応を示す印もありません。一方、Memory BankやSessionsをグローバルエンドポイントで構成すると顧客管理の暗号鍵（CMEK）が使えないため、鍵の要件がある場合は東京のエンドポイントを使います。

ADK以外のフレームワークでもデプロイできますか？

できます。公式ドキュメントが挙げる対応先は、ADK・A2A・LangChain・LangGraph・AG2・LlamaIndexとカスタムです。デプロイ時のagent_frameworkは、エージェントのオブジェクトから出す場合は自動で判定されます。ソースファイルから出す場合の既定値はcustomです。ただしセッション管理とMemory Bankの自動連携が最も手厚いのはADKなので、新規に作るならADKを選ぶのが近道です。

Cloud RunにADKをデプロイする場合と何が違いますか？

Cloud Runは汎用のコンテナ基盤なので、会話履歴の保存先やスケールの設定を自分で用意します。Agent Runtimeは、SessionsとMemory Bankがはじめから付いており、新しくデプロイしたADKエージェントはOpenTelemetryのトレースも既定で有効です。課金もAgent Runtimeはターン間のアイドルを除いた処理時間が基準で、Cloud Runの課金設定を自分で選ぶ必要がありません。既存のコンテナ運用があるならCloud Run、エージェント専用の基盤を新しく持つならAgent Runtimeという分け方になります。

関連記事

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

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

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

資料請求

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

  1. 2026.10.16　テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩｜対象確認・案内メールの真偽と運営側のログ点検
  2. 2026.10.15　テックブログ 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更の手順
  3. 2026.10.16　テックブログ ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検
  4. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  5. 2025.12.02　テックブログ クーパン問題とは？3,755万人流出と過去最大6,246億ウォンの課徴金

RELATED POSTS 関連記事

一覧へ戻る

目次