Cloud Run か Agent Engine か ── Google Cloud で AI エージェントをデプロイする際の設計選択

本記事では、Google Cloud で AI エージェントをデプロイする際の Agent Engine と Cloud Run の使い分け基準を整理します。Agent Engine を構成する Sessions・Memory Bank・Agent Runtime の役割、Cloud Run が依然として優位なユースケース、コンポーネント別の料金構造、VPC 統合の違いを順に整理します。両者を組み合わせるハイブリッド構成の可能性についても取り上げます。設計制約と料金の全体像を把握して、次のエージェント設計の技術選定に役立ててください。

ランタイム選択の全体像 ── マネージド・サーバーレス・オーケストレーテッドの三択

Google Cloud が示す AI エージェントのランタイム選択肢は、大きく三つに整理されます。フルマネージドの Agent Engine、サーバーレスコンテナの Cloud Run、そしてコンテナオーケストレーションの GKE です。

Architecture Center の公式ガイドは、この三択を「Python + 運用オーバーヘッド最小化」「コンテナ化 + 言語柔軟性 + サーバーレス」「コンテナ化 + 複雑なステートフル + きめ細かいインフラ制御」に対応させています。エージェントの設計条件によって適切なランタイムが変わる、という整理です。

ADK (Agent Development Kit) はこの三択すべてに対応します。Agent Engine 専用のフレームワークではなく、Cloud Run や GKE へのデプロイも公式にサポートされています。同様に LangChain / LangGraph / LlamaIndex / CrewAI / AG2 も三択いずれのランタイムでも動作します。

本記事は Agent Engine と Cloud Run の比較を中心に扱います。GKE はコンテナオーケストレーションに精通したチームが前提となる選択肢であり、「カスタムオーケストレーションが必要な複雑なステートフルシステム」や「きめ細かいインフラ制御」を要件とするケース向けです。

なお、2026 年 4 月 22 日付けで Vertex AI の Agent Builder ファミリーは Gemini Enterprise Agent Platform へ統合されました。このとき Agent Engine は Agent Runtime に改称されています。API リソース名 reasoningEngine は後方互換が維持されているため、既存のコードへの影響はありません。本記事では従来の呼称「Agent Engine」を引き続き使います。

Agent Engine が管理するもの ── Runtime・Sessions・Memory Bank の実態

Agent Engine は単一のサービスではなく、複数のコンポーネントの集合体です。それぞれ独立した課金単位と機能境界を持ちます。

Agent Runtime はフルマネージドのコンピューティング実行環境です。vCPU とメモリを確保し、Python エージェントコードをデプロイ可能な状態で管理します。コールドスタートは 1 秒未満をサポートし、min_instances 設定によるウォームアップも可能です。数日単位のステートフルな実行継続も対応します。GA ステータスで、asia-northeast1 リージョンでも利用できます。

Sessions は会話ターン間の状態と履歴を管理する短期記憶コンポーネントです。TTL はデフォルトで 365 日です (expire_time・ttl いずれも未指定の場合)。SDK 数行で組み込めるため、会話コンテキストの維持を自前実装する手間を省けます。

Sessions は Cloud Run から単体で呼び出し可能です。事前に Agent Runtime インスタンスの作成が必要ですが、エージェントコードをデプロイする必要はありません。このポイントはハイブリッド構成を検討する際に重要になります。

Memory Bank は複数セッションをまたいでパーソナライズ情報を保持する長期記憶コンポーネントです。セッションをまたいだ継続的なユーザー理解が必要なシナリオ、たとえば医療相談や継続的なカスタマーサポートで効果が出ます。GA ステータスで asia-northeast1 対応済みです。

Code Execution は Python コードを安全なサンドボックス環境で実行する機能です。ただし 2026 年 5 月時点では Preview ステータスであり、us-central1 のみ対応です。asia-northeast1 での利用は現時点では非対応となっています。

公式が示す分岐点 ── 設計条件ごとのランタイム選択

Architecture Center の公式ドキュメントは、以下の決定テーブルを示しています。

Agent Engine が公式に「不向き」と明示する条件は四つです。

1. Python 以外の言語 (Go / Java / TypeScript など)
2. コンピューティング環境の広範なカスタマイズ が必要なケース
3. カスタム MCP サーバーのホスティング
4. プライベート依存管理に厳しいセキュリティ要件

これらの条件に一つでも当てはまれば、Agent Engine ではなく Cloud Run を検討する根拠になります。

一方、Cloud Run 固有の優位はフレームワークと言語の自由度にあります。n8n / Dify などの OSS エージェントフレームワークは Cloud Run で動かす構成が現実的です。カスタム MCP サーバーもサイドカー的に Cloud Run へデプロイする設計が取れます。既存の CI/CD パイプラインやコンテナレジストリとの統合もそのまま活用できます。

Cloud Run には設計上の制約もあります。リクエストタイムアウトは最大 60 分 (Cloud Run ジョブは 7 日)、インスタンスあたりのリソース上限は 8 vCPU / 32 GiB です。インスタンスはステートレスで動作するため、インスタンスが再起動するとメモリに保持した状態は消失します。会話状態を維持するには外部ストレージ (Firestore / Memorystore など) との組み合わせが必要です。または後述する Agent Engine Sessions を呼び出すハイブリッド構成も選択肢になります。

料金の構造 ── コンポーネント別の単価と月次試算

Cloud Run の料金 (asia-northeast1)

Cloud Run はアクティブな処理時間に対して課金されます。

無料枠は月次で CPU 180,000 vCPU 秒、RAM 360,000 GiB 秒、リクエスト 200 万件です。小規模なプロトタイプであれば無料枠内で収まるケースが大半です。

Agent Engine の料金 (グローバル一律・asia-northeast1 対応済み)

Agent Engine はコンポーネントごとに独立した課金体系を持ちます。

月次コストの試算

公式が示す試算例は月 432,000 リクエスト・平均処理時間 3 秒のケースです (1 USD = 155 円換算、確認日 2026-05-06)。Sessions は 1 リクエストあたりユーザー発話・モデル応答・ツール呼び出しなど複数のイベントが保存されるため、リクエスト数に比例してコストが積み上がります。

LLM の呼び出しコストは別途かかります。

この試算が示すのは、Agent Runtime のコストが全体の 6% 以下にとどまり、料金の重心が Sessions と Memory Bank に移っている点です。会話履歴の保存粒度 (イベント数) とメモリの取得頻度を設計段階でコントロールしないと、実行コンピューティング費用より状態管理費用の方が大きくなります。

設計と運用の注意点 ── VPC 統合・名称変更・ハイブリッド構成

VPC 統合の違い

プライベートネットワーク内のリソースへのアクセス方法が、両者で異なります。

Agent Engine は PSC (Private Service Connect) インターフェース経由での VPC 統合に対応します。/28 サブネットを別途確保する必要があります。

Cloud Run は Direct VPC Egress (GA) または Serverless VPC Access Connector で VPC 接続を構成します。Direct VPC Egress はコネクタ不要で直接 VPC サブネットへのアウトバウンドを確保できます。

セキュリティ要件でプライベート依存関係への厳密なアクセス制御が必要な場合は、Agent Engine の PSC 設定手順と必要なサブネット設計を確認してから選定を進めるのが安全です。

名称変更の実務インパクト

Gemini Enterprise Agent Platform への改称後も、API リソース名 reasoningEngine は後方互換が維持されています。既存コードを書き直す必要はありません。ただしドキュメント上は旧称「Vertex AI Agent Engine」と新称「Gemini Enterprise Agent Platform」が混在して登場します。ページが古いかどうかを確認してから参照してください。

ハイブリッド構成

Python 以外の言語を使いたい、またはカスタム MCP サーバーが必要なケースでも、セッション管理は自前実装したくない場合があります。そのようなときは、Cloud Run でエージェントを実行しながら Agent Engine Sessions を単体で呼び出す構成が有効です。

前述のとおり Sessions は Agent Engine のコンテナ上でなくても呼び出せるため、Cloud Run コンテナから Sessions API を直接呼び出してセッション状態を取得・更新する設計が取れます。言語やフレームワークの制約を Cloud Run 側で解消しつつ、状態管理の実装コストを Sessions に委譲する、という分担です。

顧客事例 (参考)

2026 年 4 月 22 日の Gemini Enterprise Agent Platform 発表時には、複数の実導入事例が公表されています。Color Health は ADK と Agent Runtime を活用してがん診療エージェントを大規模化しました。Comcast の Xfinity Assistant はマルチエージェントアーキテクチャで顧客サポートのデジタル解決率を向上させています。いずれも Python エージェントを本番スケールで動かすユースケースであり、Agent Engine が想定するシナリオと一致しています。

まとめ ── 設計制約と運用責任が選択を決める

Agent Engine と Cloud Run の選択は、「優劣」ではなくエージェントの設計制約と運用責任の範囲で決まります。

判断の出発点として、以下の四つを確認してください。

• Python 以外の言語、または MCP サーバーが必要 → Cloud Run
• 既存コンテナの CI/CD にそのまま乗せたい → Cloud Run
• Python 確定 + セッション管理を自前実装したくない → Agent Engine
• 両方の要素がある (言語・MCP の自由度 + セッション管理の委譲) → Cloud Run + Agent Engine Sessions のハイブリッド

料金設計の観点では、Agent Engine の Runtime 本体より Sessions / Memory Bank のコストが重くなる点を事前に把握しておくことが重要です。会話履歴のイベント粒度とメモリ取得頻度を設計段階で見積もっておきましょう。

VPC 統合やセキュリティ要件についての詳細は、Architecture Center の公式ガイド「AI エージェントアーキテクチャコンポーネントの選択」で確認してください。

参考文献

• Choose agentic AI architecture components — Architecture Center
• Deploy AI agents to Cloud Run — Cloud Run documentation
• Gemini Enterprise Agent Platform overview
• Gemini Enterprise Agent Platform pricing
• Cloud Run pricing
• Introducing Gemini Enterprise Agent Platform — Google Cloud Blog
• From code to cloud: Three labs for deploying your AI agent — Google Cloud Blog

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile