DX開発事業部 フルスタックセクションの田村です。

Google Cloud Next 2026のセッション「Build AI Agents on Cloud Run」を聴講しました。

このセッションのメインは、Cloud Run Instances（Private Preview）という新しいリソースタイプの発表です。「エージェントを長時間動かし続けたい」というニーズに直接応える機能で、既存のService・Job・Worker Poolとは用途が異なります。

Cloud RunでAIエージェントをどう設計するか

エージェントアプリの設計における考え方が紹介されました。

考慮するポイントとして、Framework（どのフレームワークを使うか）・Sync and async（同期か非同期か）・Sub-agents and tools（役割を分担するか）・Autonomy（人間が介在するか）の4つが挙げられました。

「普通のWebサービスやマイクロサービスの設計と考え方はほぼ同じ」という説明があり、エージェントだから特別というわけではなく、分散システムの延長として捉えると整理しやすいですね。

またCloud RunがAIエージェントに向いている理由として、以下の3点が紹介されました。

  • Scale to zero：使っていないときは課金ゼロ。エージェントも同様にサーバーレスで動かせます
  • Simple to deploy：gcloud run deploy my-agent の1コマンドでデプロイ可能
  • Use any framework：ADKでもLangChainでも、コンテナが動けばどんなフレームワークでも対応

エージェントの4つのデプロイ形態

Cloud Runにはエージェント向けに4つの実行形態があります。

形態 概要
Service 複数ユーザーへの同時スケール。使わないときはゼロに落ちる
Job 必要なときだけ非同期で実行するエージェント
Worker Pool 常時稼働。キューを監視して継続的に処理
Instance 1つのエージェントを1インスタンスで長時間実行（新登場）

特に4つ目のInstanceは今回発表された新しいデプロイ形態のため後のパートで詳しく紹介されていました。
Worker Poolについても昨年のGoogle Cloud Nextで発表されて以降ようやくのGAですね。

Agent Platformとの連携

Cloud Runはエージェントプラットフォームとの統合フラグも用意されているようです。

  • --identity-type=agent_identity：エージェントIDを付与
  • --functional-type=agent|mcp_server：Agent Registryに登録
  • --ambient-networking=regional：Agent Gatewayを経由した通信を有効化

これにより、デプロイしたエージェントが組織内の他エージェントから発見・利用できるようになります。

VMO2の事例：Gemini・Cloud Run・AlloyDBで作ったコンタクトセンターAI

コンタクトセンターのオペレーターが1件の電話対応で5〜6ツールを行き来している課題を解決するために、Gemini・Cloud Run・AlloyDBでLumiというAIプラットフォームを構築した事例です。

「既存ツールへのAI後付けではなく、自社の製品・プロセス・顧客を理解したものをゼロから作った」という点が印象的でした。
Cloud Runを採用した理由として「オートスケーラーの調整に工数を使わずに済んだ分、プロダクト開発に集中できた」という言葉が紹介されており、インフラ運用の負荷軽減がいかに開発速度に直結するかを実感できる事例だったように思います。

Cloud Runは特に非エンジニアでも比較的扱いやすいサービスになるので、開発に専念できるという点は本当に大きなメリットですね。

Cloud Run Instances（Private Preview）

今回Cloud Runの4つ目の新しいリソースタイプとして「Instances」という設定が追加されました。

Cloud Run Instancesは「インタラクティブで長期稼働するエージェントのための新しいCloud Runリソース」と定義されています。現在Private Preview中です。

何が新しいのか

既存のCloud Run Serviceは「複数インスタンスがスケールする」設計で、使用するタイミングでインスタンスが立ち上がり利用可能になるという使い方が主だと思います。

しかしCloud Run Instancesでは異なり、常に1つのインスタンスが動いていてそれに直接アクセスすることができます。

4つの特徴が紹介されました。

  • Individually manageable（個別管理）：各インスタンスを独立して作成・更新・削除・停止・再起動できます
  • Long-lived（長期稼働）：時間・日単位で中断なく実行できます。タイムアウト後は自動再起動の設定も可能です
  • Directly Addressable（直接アドレス指定）：インスタンスごとに固有のURLを持ちます。特定のエージェントを直接指定してやり取りするのに向いています
  • On-demand（オンデマンド）：秒単位で起動できます

どんな用途に向いているか

4つのユースケースが挙げられました。

  • 長期稼働の個別AIエージェント（例：OpenClaw）：株取引エージェントがニュースを監視して1日中取引するような、数時間〜数日単位の非同期タスク
  • 長時間AIワークロードとオーケストレーター（例：n8n）：AIワークフローを長時間中断なく動かしたい場合
  • リモート開発環境（”Vibe coder boxes in the cloud”）：クラウド上の開発環境としても利用可能
  • AIエージェント向けサンドボックスPC：エージェントが専用の独立した実行環境として使う場合

インスタンスの作り方

以下はインスタンス作成のコマンドのサンプルです。

gcloud run instances create helloworld \
  --image gcr.io/cloudrun/hello \
  --region us-west4 \
  --default-url \
  --timeout 600

デモでは、GitHubのissueを監視してPRを自動作成するコーディングエージェントを8時間タイムアウトでデプロイしていました。起動はわずか数秒で完了していました。

インスタンスへのアクセス方法

アクセス方法は2つ紹介されました。

1. SSH（Private Preview）

gcloud run instances ssh my-instance

Cloud RunへのSSHアクセスです。「記録されたデモでは初公開」とRyanが話していました。SSH接続してファイルを確認したり、Gemini CLIを起動したり、ファイルシステムを直接操作できます。トラブルシューティングにも活用できますね。

2. Dev-mode sync（Coming soon）

gcloud run instances dev sync --source .

ローカルのソースファイルを「リアルタイム」でCloud Runインスタンスに同期する機能です。
開発の内部ループを加速するために設計されています。

料金

スペック 30日間の料金（Tier 1リージョン）
1 CPU（共有）/ 1 GiB $5.70
2 CPU（共有）/ 2 GiB $11.40
2 CPU（共有）/ 4 GiB $21.41

「コーヒー1〜2杯の値段でOpenClawエージェントやn8nワークフローを1ヶ月動かし続けられる」という説明がありました。共有CPUを採用しているため、アイドル時間が多いエージェントのコストを抑えられる設計になっています。

個人開発者やちょっとした検証でエージェントを試すには十分な価格帯だと思います。

Instant Sandboxes（Coming soon）

LLMが生成した信頼できないコードを実行するための隔離サンドボックスです。これはCloud Runのインスタンス内に複数のサンドボックスを動的に作成できます。

ポイントは「インスタンス内にサンドボックスを作る」という仕組みにあります。
インスタンスごとにサンドボックスを立ち上げると時間がかかりますが、既存インスタンス内で作成することで高速化しています。デモでは平均400ミリ秒未満での起動が示されていました。

セキュリティ検証もデモで実施されました。ホストのファイルシステムへの書き込み試行・ホストの環境変数の読み取り試行のいずれも失敗しており、サンドボックスが正しく隔離されていることが確認されていました。

# インスタンスにSSHしてサンドボックスを使う
gcloud run instances ssh my-agent-instance
sandbox do -- /bin/bash -c "echo 'hello'"

マルチエージェントアプリのアーキテクチャ例

最後のデモはブロックを積むゲームで、複数のエージェントが協調するマルチエージェント構成でした。

  • Block Game Web App：Cloud Run Service（スケールできるWebアプリ）
  • Builder Agent：Cloud Run Instance（ゲームに参加する単一エージェント）
  • Physics Agent：Cloud Run Service（物理計算を担当、スケール可能）
  • MCP Server：Cloud Run Service（ツールを提供する）

ServiceとInstanceを用途によって使い分けているのがわかります。
WebアプリやスケールさせたいエージェントはService、1体のエージェントとして長時間インタラクションするものはInstance、という判断軸ですね。

デプロイコマンドも紹介されました。

# MCP Serverのデプロイ
gcloud run deploy blocks-mcp-server \
  --image ${IMAGE_REGISTRY}/mcp_server \
  --functional-type mcp_server \
  --identity-type agent_identity

# Physics Agent（Service）のデプロイ
gcloud run deploy blocks-physics-agent \
  --image ${IMAGE_REGISTRY}/physics_agent \
  --set-env-vars MCP_SERVER_URL=$MCP_SERVER_URL \
  --set-secrets GEMINI_API_KEY=GEMINI_API_KEY:latest \
  --functional-type agent \
  --identity-type agent_identity

# Builder Agent（Instance）のデプロイ
gcloud run instances create blocks-builder-agent \
  --image ${IMAGE_REGISTRY}/builder_agent \
  --set-env-vars PHYSICS_AGENT_URL=$PHYSICS_AGENT_URL \
  --set-secrets GEMINI_API_KEY=GEMINI_API_KEY:latest \
  --default-url \
  --functional-type agent \
  --identity-type agent_identity

--functional-type と --identity-type のフラグは現在Coming soonです。これが入れば、デプロイと同時にAgent Registryへの登録が自動で行われるようになります。

セッション全体を振り返って

Cloud Run Instancesは、エージェント向けにちょうどほしかった機能だと感じました。OpenClawやn8nのような長時間エージェントをCloud Runで動かそうとすると、Serviceのタイムアウト制限やスケールアウトの仕組みが課題になることがあります。
専用の1インスタンス・長時間稼働・固有URL・SSH対応という組み合わせは、エージェントのユースケースに対して整合性が高い設計です。

Instant Sandboxesと合わせることで、LLMが生成したコードを安全に実行する環境まで一体で提供されるのは、エージェント開発の実用性を大きく高めてくれると思いました。

エージェント開発が主軸になってきている中、このようなエージェント最適なCloud Runのインスタンスタイプはぜひ使っていきたいですね。