Cloud Run instancesとは？ 常時動くAIエージェントをシンプルに実行する新しい選択肢


Cloud Runというと、WebサイトやAPIを動かす場所、というイメージが強いと思います。

アクセスが増えれば実行するコンテナを自動で増やし、使われなくなれば0まで減らす。サーバーを用意せずにアプリケーションを動かせるところが、分かりやすい特徴です。

では、「1つのプログラムをクラウドでずっと動かしておきたい」ときはどうでしょうか。アクセスの数に合わせて増やす必要はなく、ただ1つが動き続けていてほしい、という処理です。

2026年8月に登場したCloud Run instancesは、まさにその使い方を想定した新しい実行方法です。現在はプレビューです。

この記事では設定の手順ではなく、これまでのCloud Run serviceと何が違って、どんなときに使うのかを見ていきます。

著者：佐藤 浩
所属：ソリューション事業本部 インフラ事業部 インフラ イノベーション部
公開日：2026年9月19日

1. Cloud Run instancesとは

Cloud Run instancesは、1つのコンテナ実行環境を継続して動かしたいときに使う、Cloud Runの新しい選択肢です。

公式ドキュメントでは「1つだけ動く実行環境を必要とする、長く動き続けるワークロード向け」と説明されています。

分かっておきたいのは3つです。

まず、動くのは1つだけです。アクセス量に合わせて実行数を自動で増減するautoscalingはしません。

次に、1つずつ操作できます。作成、更新、開始、停止を個別に行えます。使わない間は止めておいて、必要になったら再開する、という扱い方ができます。

そして、URLが変わりません。instanceごとにHTTPSのURLが割り当てられ、更新や再起動をまたいでも同じURLのまま使えます。

起動は20秒ほどで、そこから長時間動き続けます。ただし、ずっと止まらないわけではありません。基盤側の更新に合わせて再起動が入ります。既定では自動的に再起動する設定になっていて、連続で動くのは最長7日程度です。

イメージとしては、軽量なサーバーレスの仮想マシンに近い、と公式では説明されています。1台を起動したり止めたりしながら使う感覚は仮想マシンに似ていて、OSやマシンそのものの管理はGoogle側に任せられる、という位置付けです。

左のCloud Run serviceは、アクセスが増えるとコンテナが0個から1個、3個へと増えていく。右のCloud Run instanceは、コンテナが1つだけあり、時計のアイコンとともに動き続けている。下部に仕事の種類が違う、と示した図。

図1　増やすのか、1つを動かし続けるのか

2. Cloud Run serviceとの違い

これまでのCloud Run serviceは、HTTPリクエストを受けて動きます。

アクセスが増えれば実行するコンテナを自動で増やし、減れば減らします。アクセスがない時間は0まで減らすこともできます。たくさんの利用者からのリクエストをさばくWeb APIには、この形が向いています。

たとえば社内の申請フォームのAPIなら、朝と夕方に人が集まって、深夜はほとんど誰も使いません。serviceならその波に合わせて実行数が変わり、使われていない時間は0にできます。

Cloud Run instancesは考え方が違います。1つの実行環境を作って、それを動かし続けます。数を増減させるのではなく、自分で開始や停止をして管理します。

反対に、日中ずっと様子を見ていて、必要になったら作業を進めるような処理は、アクセスの波とは関係なく動きます。この場合は増減の仕組みより、1つが動き続けていることの方が大事になります。

どちらが優れている、という話ではありません。アクセスに合わせて増減させたいのか、1つを動かし続けたいのか。仕事の種類が違う、と考えると分かりやすくなります。

3. AIエージェントと相性がよい理由

Googleは、Cloud Run instancesの代表的な使い道として、長時間動くAIエージェントを挙げています。個人が使う専用のエージェントのように、一人のために動き続けるタイプのものです。

質問が来たときだけ答えるWeb APIとは、動き方が違います。裏側で処理を続けたり、途中の状態を持ったまま長く動いたりします。こういう処理では、アクセスに合わせて実行数を増やす仕組みはあまり出番がありません。

利用者からCloud Run instanceの枠へ矢印が伸び、その中でAIエージェントが時計とともに動き続けている。枠の外にはメール、予定表、データのアイコンが点線でつながっている。下部につなぎ先は自分で用意する、と示した図。

図2　1人のために動き続けるAIエージェント

状態を持つ、というのは、途中まで進めた作業や覚えておきたい情報を抱えたまま動き続ける、ということです。リクエストごとに使い捨てられる実行環境だと、この持ち方に工夫がいります。

自分のPCで動かす手もありますが、PCを閉じれば止まります。Compute Engine（GCE）のVMなら動かし続けられますが、OSの管理が付いてきます。Google Kubernetes Engine（GKE）でクラスタを用意するのは、小さな常駐処理には大がかりです。

Cloud Run instancesは、その間を埋める選択肢です。コンテナを1つ、クラウドで動かし続ける。用途がそこに絞られています。

なお、AIエージェント専用の機能ではありません。1つを動かし続けたい処理であれば、AIに限らず使えます。

4. 何でもinstancesにすればよいわけではない

Cloud Runには、処理の種類に応じた実行方法が用意されています。

WebサイトやAPIならservice。処理が終われば止まるバッチならjob。キューから仕事を取り続けるバックグラウンド処理ならworker pool。そして、1つの実行環境を継続して動かしたいならinstance。

Web・API向けのService、終わったら停止するJob、バックグラウンド処理のWorker pool、1つを継続して動かすInstanceの4つを、アイコン付きのカードで並べた図。下部に置き換えではなく使い分け、と示している。

図3　動き方でCloud Runの実行方法を選ぶ

instancesは、Cloud Run serviceの後継でも、置き換えでもありません。そのプログラムがどう動くかで選ぶのが、一番分かりやすい考え方です。

5. まとめ

Cloud Run instancesが加わって、Cloud Runで扱える処理の幅が広がりました。

これまで得意だった、アクセスに合わせて増減するWeb/API型に加えて、1つの実行環境を継続して動かす使い方ができるようになりました。自分専用のAIエージェントや、小さな常駐処理では分かりやすい使い道です。

まだプレビューなので、本番で使う前には提供状況を確認してください。動かせる時間や再起動の扱いも、実際に使う前に一度見ておくと安心です。

選び方はシンプルです。アクセスに合わせて増減させたいならservice、1つを動かし続けたいならinstance。ここから考えると迷いにくくなります。

参考情報