G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された Cloud Run の新機能について、公式の投稿記事「What's new for Cloud Run at Next '26」の内容をもとに紹介します。
- はじめに
- Empowering the new era of developers
- Embracing the agentic era
- Automatic scaling for high-demand applications
- Running AI models

はじめに
以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Cloud Run の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス(GA / Preview / Private Preview / Coming Soon)は2026年4月23日現在の情報です。
他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。
Empowering the new era of developers
Google AI Studio によるフルスタックアプリのビルドとデプロイ(GA)
Google AI Studio から、Cloud Run、Firestore、ユーザー認証を組み合わせたフルスタックアプリケーションをワンクリックで構築・デプロイできるようになりました。
Google AI Studio を使用してバイブコーディングで作成したアプリをそのまま Cloud Run にデプロイでき、プロトタイプから本番環境までシームレスに繋がる点が特徴です。
Cloud Run MCP サーバー(GA)
Google Cloud では、Model Context Protocol(MCP)に対応したフルマネージドのリモート MCP サーバーが提供されており、Cloud Run MCP サーバーもその1つです。
これを利用することで、開発者や AI エージェントは MCP 経由で Cloud Run 上のアプリケーションをデプロイ・管理できるようになり、エージェントがツールとして Cloud Run を操作するユースケースを容易に実現できます。
Google Cloud が提供している MCP サーバーについては、以下の記事をご一読ください。
Billing Caps(Coming Soon)
Billing Caps は、月あたりの最大利用額を設定できる機能であり、設定した金額に請求額が達すると Cloud Run が非アクティブとなります。これにより、想定外のコスト発生を未然に防ぐことができます。
Cloud Run では、リクエスト数に応じた料金と、コンテナインスタンスが実行されている間の CPU、メモリの時間あたりの料金が発生します。この仕様により、DDoS 攻撃のような不測のトラフィック急増や、バグによるリトライのループなどによって利用料金が跳ね上がる恐れがあります。
従来の対策としては、Cloud Billing の予算アラートを使用して、利用料金が閾値を超過したときにアラートを飛ばす方法がありました。この方法は利用料金の増加に対して自動で対処できるようなものではなく、実際の対処は手動で行うか、Pub/Sub などを使用して自前で実装する必要がありました。
Billing Caps を用いることで、このような状況でサービスを強制停止できるようになります。サービス停止による損害とのトレードオフとなるため、本番運用のサービスでは慎重に設定する必要があるでしょう。
Embracing the agentic era
Gemini Enterprise Agent Platform との統合(Private Preview)
Gemini Enterprise Agent Platform は Vertex AI のリブランディングであり、AI エージェントの構築・拡張・ガバナンス・最適化のための新しいプラットフォームです。
Cloud Run との統合により、Agent Platform の実験環境で開発したエージェントを、アプリケーションを再構築することなく、そのまま Cloud Run に移行することができます。

Cloud Run Instances(Private Preview)
Cloud Run では、用途に応じて Cloud Run Services、Cloud Run Jobs、Cloud Run Worker Pools という3つの実行モデルが提供されています。
Cloud Run Instances は、コンテナインスタンスの基本機能のみを提供する新しい実行モデルであり、コンテナを常駐させておくためのフルマネージドのインスタンスを個別に作成することができます。
Cloud Storage バケットのボリュームマウントに対応しており、長時間稼働するバックグラウンドエージェント(例 : OpenClaw)のホスティングに適しています。
以下は、インスタンスを作成するコマンド例です(公式ブログより引用)。
$ gcloud run instances create \ --image alpine/openclaw:latest \ --port 18789 \ --memory 4Gi \ --default-url \ --add-volume mount-path=/home/node/.openclaw,type=cloud-storage,bucket=$BUCKET_NAME

Cloud Run Sandboxes(Coming Soon)
AI エージェントがコードやコマンドを自律的に生成・実行する場合、それらを隔離された環境で安全に実行することが求められます。
Cloud Run Sandboxes は、Cloud Run 上で実行されているエージェントが生成したコードを、隔離された使い捨てのサンドボックス環境で実行するための機能です。
以下は、アプリケーションからサンドボックスを起動してコードを実行する場合のイメージです(公式ブログより引用)。
app.post('/execute', (req, res) => { const escapedCode = req.body.code.replace(/"/g, '\\"'); exec(`sandbox do -- /usr/bin/python3 -c "${escapedCode}"`, (e, stdout, stderr) => { res.send({ stdout, stderr }); }); });

Automatic scaling for high-demand applications
コンテナへの SSH 接続のサポート(Private Preview)
Cloud Run はフルマネージド サービスのため、実行しているコンテナの中身を直接見ることができず、トラブルシューティングの際は Cloud Logging に出力したアプリケーションログ、Cloud Monitoring のメトリクスが頼りでした。
稼働中の Cloud Run コンテナに SSH でアクセスできる機能が追加されたことにより、コンテナ内からプロセスの状態やファイルシステムを直接調査したり、ネットワーク到達性の確認ができるようになることが期待されます。
Cloud Run 上のコンテナへの SSH 接続は、以下のコマンドで実施できるようになるようです。
$ gcloud run services ssh SERVICE

Cloud Run Service Bindings(Coming Soon)
Cloud Run Service Bindings は、Cloud Run におけるサービス間通信に関する機能のようです。公式ブログ上で機能の詳細は公開されていませんが、複数の Cloud Run サービスを安全かつ容易に接続できるようになることが期待されます。

以下の記事で解説しているように、従来の仕様では、Cloud Run から別の Cloud Run に安全にアクセスするためには、限定公開の Google アクセスを有効にした VPC を経由したり、Cloud Run の前段に内部アプリケーションロードバランサーを配置して Private Service Connect エンドポイントを構成したりする必要がありました。
Running AI models
NVIDIA RTX PRO 6000 Blackwell GPU のサポート(GA)
Cloud Run で NVIDIA RTX PRO 6000 Blackwell GPU が利用可能になりました。
従来以上に大きなモデル(最大700億パラメータ超)をサーバーレスで実行でき、リクエストに応じたスケーリング(アイドル時はゼロスケール)により、高額になりがちな GPU の利用料金を節約できます。
Cloud Run における GPU 利用は、特に低トラフィックのモデル推論において、アイドル時の GPU コストを抑制できる点が大きな利点となります。
Cloud Run における GPU の詳細については以下の記事で解説しています。

Ephemeral Disk(Preview)
Ephemeral Disk は、インスタンスごとに作成される一時的なディスクストレージであり、インスタンスの起動時に作成され、停止時に削除されます。
大きなファイルの処理やスクラッチ用途でメモリを消費していたワークロードを、メモリではなくディスクに逃がせるようになり、メモリ消費の増大によるパフォーマンス劣化や、割り当てるメモリ量を多く設定することによるコストの増加を抑制できます。
従来、このような問題はコンテナインスタンスに Cloud Storage をマウントすることによって回避する方法が一般的でした。Ephemeral Disk はインスタンスのローカルディスクとして扱われるため、ネットワーク経由で読み書きを行う Cloud Storage マウントよりも高パフォーマンスでの読み書きが可能です。

Ephemeral Disk は Cloud Run の各実行モデルで利用可能です。詳細は以下のドキュメントを参照してください。
- 参考 : Configure an ephemeral disk for Cloud Run services
- 参考 : Configure an ephemeral disk for Cloud Run jobs
- 参考 : Configure an ephemeral disk for Cloud Run worker pools
佐々木 駿太 (記事一覧)
G-gen 最北端、北海道在住のクラウドソリューション部エンジニア
2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。
趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。
Follow @sasashun0805