2026.10.10 Google Cloud

Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】

Q: Cloud Run instancesは一般提供されていますか？

2026年10月10日時点ではプレビューです。 Cloud Runのリリースノート では2026年8月25日にプレビューとして公開され、10月7日更新のドキュメントでもPre-GAの表記が残っています。コマンドは gcloud beta run instances で、YAMLにも run.googleapis.com/launch-stage: BETA の注記を付けます。一般提供の時期は公表されていません。

Q: Cloud Run instancesは東京リージョンで使えますか？

作成と管理のドキュメントでは、Cloud Runの対応リージョンのうち除外されているのは europe-west1 ・ us-central1 ・ us-east1 の3つだけで、東京（ asia-northeast1 ）は除外に含まれていません。サンプルの多くは us-central1 を指定しているため、コピーして使う際はリージョンを書き換えてください。

Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】

Cloud Run instancesは、オートスケールをせず1台のコンテナだけを動かし続けるCloud Runの新しいリソースです。2026年8月25日にプレビューとして公開されました。トラフィックが止まるとゼロまで縮む通常のCloud Runのサービスと違い、インスタンスごとに更新や再起動をまたいで変わらないHTTPS URLが付き、作成・停止・再開・削除を人が操作します。この記事では、公式ドキュメントと発表ブログをもとに、仕組み・gcloudでの作成手順・共有vCPUの挙動・AIエージェントや踏み台での構成例を整理し、Compute Engineやほかの実行リソースとどう使い分けるかの判断基準を示します。

まとめ：Cloud Run instancesの要点とサービス・VMとの使い分けの結論

Cloud Run instancesは「VMを立てずに、1台だけを常駐させたい」用途のための形です。対象は常時起動の個人用AIエージェント、社内向けの踏み台、小さな管理画面など、利用者が少なく負荷の大半が待ち時間の処理です。1vCPU・1GiBで30日動かし続けた場合の費用は、公式ブログの試算で5.70ドルとされています。

ただし、CPUは共有型です。保証されるのは設定したvCPUの6.25%だけで、それを超える処理は貯めたバースト残高を使い切ると絞られます。計算を回し続ける処理、複数台で負荷を分けたいAPI、永続ディスクが要る処理には向きません。

2026年10月10日時点でプレビュー段階にあり、コマンドは gcloud beta 配下です。検証環境や社内の小さなツールから試し、顧客向けの本番システムは一般提供を待つ、というのが現時点の結論です。

Cloud Run instancesの仕組みとサービス・ジョブ・ワーカープールとの違い

Cloud Runには、サービス・ジョブ・ワーカープールに続く4つ目の実行リソースとしてインスタンスが加わりました。まずは単体の設計を押さえ、次にほかの3つと並べます。

オートスケールしない単一インスタンスと固定HTTPS URLという設計

発表ブログ（2026年8月28日）が挙げる特徴は4つです。1台だけを動かしてオートスケールしないこと。既定の自動再起動ポリシーのもとで最大7日間連続して動くこと。インスタンスごとに付くHTTPS URLが更新や再起動をまたいで変わらないこと。使わないときは停止し、必要なときに再開できること。

URLの形式は https://INSTANCE_NAME-PROJECT_NUMBER.REGION.run.app です。作成と管理のドキュメントによると、インスタンス名はプロジェクトとリージョンの中で一意でなければならず、既存のサービスと同じ名前も使えません。サービスを api という名前で動かしているリージョンでは、インスタンスに同名は付けられないということです。

稼働期間の書き方には揺れがあります。ブログは「最大7日の連続稼働」と書き、リソースモデルのページは「数日から数週間動き、無期限に自動で再起動する」と書いています。7日に達した時点の挙動を説明したページは、10月10日時点で見当たりません。週単位で止められない処理を載せる場合は、再起動が起きる前提で設計してください。

4つの実行リソースを起動契機・スケール・課金の違いで比べた比較表

リソースモデルのページにある比較表から、設計に効く行を抜き出しました。

項目	サービス	ジョブ	ワーカープール	インスタンス
主な用途	Webサイト・API	スクリプト・データ処理	Kafka・Pub/Subの購読	エージェント・単一の常駐処理
起動の契機	HTTP・gRPC・Eventarc	手動・Scheduler・Workflows	常駐またはキュー連動	なし（人が作成・再開）
スケール	リクエスト数で増減・ゼロまで縮む	タスク数で並列化	手動またはCPU・滞留数で増減	なし（1台固定）
寿命	アイドルで縮む	完了まで・最大7日	常駐または増減	数日〜数週間・自動再起動
到達先	サービスURL（負荷分散）	公開エンドポイントなし	Direct VPCのIP	インスタンスごとのURL
課金	リクエスト単位またはインスタンス単位	実行時間	インスタンスの稼働時間	インスタンスの稼働時間

迷ったときは到達先の行から見ます。外からHTTPで呼ばれ、台数を増やしたいならサービス。呼ばれずに走り切るならジョブ、キューを読み続けるならワーカープールです。インスタンスは「呼び先が常に同じ1台でないと困る」処理だけが選ぶ形で、状態を持つ相手にURLで話しかける用途に絞られます。各リソースの全体像はCloud Runとはの解説記事で扱っています。

gcloud beta run instancesで1台を作成・停止・再開する操作手順

公式のクイックスタートに沿って、サンプルイメージで1台作るところから削除までを通します。

作成前に必要なAPI有効化とIAMロール・対応リージョンの確認手順

必要なのはCloud Run Admin API（run.googleapis.com）の有効化と、gcloudのbetaコンポーネントです。権限は、インスタンスに対する roles/run.developer（クイックスタートでは roles/run.admin）と、実行に使うサービスアカウントに対する roles/iam.serviceAccountUser の2つです。ログを見るなら roles/logging.viewer も付けます。

一部のリージョンは作成対象から除外される仕様です。ドキュメントは、Cloud Runの対応リージョンのうち europe-west1・us-central1・us-east1 の3つでは作成できないとしています。サンプルやTerraformの雛形は us-central1 を既定にしているものが多いため、そのまま流すと失敗します。東京（asia-northeast1）は除外の一覧に入っていません。

サンプルイメージでインスタンスを作成してURLへ接続する手順

以下は東京リージョンにサンプルイメージで1台作る例です。ブログの試算条件に合わせて1vCPU・1GiBを明示しています。指定しない場合の既定は2vCPU・2GiBで、試算より大きい構成で動きます。

# 1) 前提の準備（APIとbetaコンポーネント）
gcloud services enable run.googleapis.com logging.googleapis.com
gcloud components install beta
gcloud components update

# 2) インスタンスを作成する（1vCPU・1GiB・認証なしで公開する検証用の設定）
gcloud beta run instances create my-instance \
  --image us-docker.pkg.dev/cloudrun/container/hello \
  --region asia-northeast1 \
  --port 8080 \
  --cpu 1 \
  --memory 1Gi \
  --no-invoker-iam-check

# 3) 状態とURLを確認する
gcloud beta run instances list --region asia-northeast1
gcloud beta run instances describe my-instance --region asia-northeast1

作成が終わると URL: https://my-instance-PROJECT-NUMBER.asia-northeast1.run.app の形でURLが表示され、ブラウザで開けます。--no-invoker-iam-check はIAMによる呼び出し元の確認を外す指定で、URLを知っている人なら誰でも到達できる状態になります。検証が済んだら update に --invoker-iam-check を付けて戻してください。ログはLogs Explorerで resource.type="cloud_run_instance" と resource.labels.instance_name="my-instance" を条件にすると絞れます。

停止・再開・更新・削除のライフサイクル操作と実行時に消えるデータ

作成後の操作は、すべて gcloud beta run instances のサブコマンドで行います。

# 使わない間は止める（メモリ上のファイルと保存していない状態は消える）
gcloud beta run instances stop my-instance --region asia-northeast1

# 再開する（URLは作成時と同じ）
gcloud beta run instances start my-instance --region asia-northeast1

# イメージを差し替える（インスタンスは再起動する）
gcloud beta run instances update my-instance \
  --image us-docker.pkg.dev/cloudrun/container/hello:latest \
  --region asia-northeast1

# 削除する（元に戻せない）
gcloud beta run instances delete my-instance --region asia-northeast1

注意したいのはデータの扱いです。インスタンスには永続ディスクが無く、停止するとコンテナの実行環境ごと終了し、メモリ上のファイルや保存していない状態は失われます。update も再起動を伴うため、イメージを差し替えるたびに同じデータ消失が起きる仕組みです。「VMのように止めて再開すれば元の状態に戻る」という前提で使うと、ここで作業内容を失います。残したいデータは、次章のCloud Storageボリュームか外部のデータベースへ逃がしてください。

共有vCPUのバースト予算と再起動ポリシーで決まる常駐の挙動

料金が安い理由と、向かない処理がある理由は同じところにあります。CPUの割り当て方式です。

1vCPUあたり6.25%のベースラインと最大500秒のバースト残高

CPU上限の設定ページによると、インスタンスは共有CPUの割り当てモデルで動きます。常に保証されるのは、設定したvCPU1つあたり6.25%（16分の1）です。この範囲に収まる処理なら、期限なく動かし続けられます。

ベースラインを下回っている間は、使わなかったCPU時間がバースト残高として最大500秒まで貯まります。重い処理が来ると残高を使って設定vCPUの100%まで使え、使い切った後も高い負荷が続くとベースラインまで絞られます。待ち受けが大半で、ときどき数十秒だけ計算するAIエージェントには合う方式です。数分間フルにCPUを使う処理を繰り返すと、2回目以降に急に遅くなる現象として表に出ます。

設定できるのは1インスタンス1〜8vCPUで、1を超える値は整数です。メモリは1vCPUで512MiB〜4GiB、8vCPUで4〜32GiBの範囲になります。同時実行数は80で固定され、変えられません。

on-failure・always・neverの再起動ポリシーと最大3回の再試行

ライフサイクルのページでは、選択できる再起動ポリシーは次の3種類です。既定の on-failure は、主プロセスが0以外の終了コードで終わったときと、基盤側の障害のときに再起動します。always は終了コード0でも再起動し、never は再起動せずに STOPPED か FAILED へ移ります。

再起動が有効な場合、Cloud Runは失敗したインスタンスを順に最大3回まで立ち上げ直し、それでも失敗が続くと FAILED にします。起動直後に設定ファイルの読み込みで落ちるようなアプリは、3回で止まって復帰しません。--startup-probe で起動判定を入れ、FAILED への遷移をCloud Monitoringのアラートで拾う設計を合わせて組んでください。

AIエージェント常駐と踏み台用途で組むボリュームと公開範囲の設計

公式ブログが挙げた用途は、個人向けAIエージェントの常駐と、L’Oréal Beauty Techによる踏み台です。どちらも「状態をどこに置くか」と「誰に開けるか」の2点で構成が決まります。

Cloud Storageボリュームで設定と状態を残すOpenClawの構成例

ブログと公式のCodelabでは、OpenClawの設定ファイルをCloud Storageのバケットに置き、FUSEでマウントして動かしています。停止や更新でコンテナが消えても、マウント先（/home/node/.openclaw）に書いた内容はバケット側に残る構成です。

# 設定ファイルを置いたバケットをマウントしてOpenClawを常駐させる（公式ブログの例）
gcloud beta run instances create openclaw-instance \
  --image ghcr.io/openclaw/openclaw:latest \
  --port 18789 \
  --public \
  --add-volume mount-path=/home/node/.openclaw,type=cloud-storage,mount-options="uid=1000;gid=1000;file-mode=0700;dir-mode=0700",bucket=${BUCKET} \
  --set-env-vars "OPENCLAW_GATEWAY_PASSWORD=${PASSWORD},GEMINI_API_KEY=${GEMINI_API_KEY}"

この例はAPIキーを環境変数に直接渡しています。gcloudのリファレンスには --set-secrets があり、Secret Managerの値を環境変数かファイルとして渡せます。組織で使う場合はこちらに置き換え、キーをコマンド履歴やインスタンス定義に残さないでください。ボリュームの種類は、Cloud Storage・一時ディスク・メモリ・NFSの4つです。一時ディスクとメモリはインスタンスの終了で消えるため、残す用途には使えません。

–publicを付けずにIAMとIAPで踏み台的な接続を絞る設定

上の例の --public は、--no-invoker-iam-check と --no-iap を同時に指定したのと同じ意味です。IAMによる呼び出し元の確認も、Identity-Aware Proxyによる認証も外れます。エージェントがパスワード認証を持っているとしても、URLが漏れれば総当たりの対象になります。

社内の踏み台として使うなら、既定のIAM確認を残し、--ingress internal でVPC内からの到達に限るのが基本です。--network と --subnet（/26以上）でVPCにつなぎ、--set-cloudsql-instances でCloud SQLへの接続を足せます。ブラウザから社員に使わせたい場合は、Cloud Run向けのIAP設定で接続を許可するGoogleアカウントを絞る設定が必要です。踏み台そのものの考え方と、SSH多段接続で組む従来の構成は踏み台サーバーの解説記事にまとめています。なお、ブログはインスタンスとサービスの両方へのSSH接続を「近日提供」としており、10月10日時点では使えません。

Cloud Run instancesを採用する条件とプレビュー段階で見送る場面

判断を言い切ります。Cloud Run instancesは「小さく常駐させるための安い器」であって、VMやサービスの代わりではありません。

月5.70ドルの試算が当てはまる条件とCompute Engineとの線引き

次の条件がそろうなら、Cloud Run instancesで組む価値があります。

利用者が1人〜数人で、1台が落ちて数十秒止まっても業務が止まらない
CPUの平均使用率が設定vCPUの6.25%前後に収まり、重い処理は短く断続的
状態をCloud Storageや外部DBへ逃がせ、ローカルディスクに依存しない
OSの更新やHTTPS証明書の管理を自分で持ちたくない

5.70ドルという金額は、1vCPU・1GiBで30日動かした場合の数字です。既定の2vCPU・2GiBのまま作ると、この条件から外れます。Cloud Runの料金ページには、10月10日時点でインスタンス専用の単価表が見当たりません。課金の単位は「インスタンスの稼働時間」とされていますが、停止中の扱いも明記されていないため、見積はプレビュー中の参考値として扱ってください。

CPUを継続して使う処理、カーネルやディスクを触る処理、複数のプロセスを長く抱える処理はCompute Engineで組むほうが素直です。VMならCPUは専有でき、永続ディスクも付けられます。どちらで組むか、ネットワークと権限の設計を含めて決めたい場合は、AWS・Google Cloud・Azureのインフラ構築支援で既存構成の棚卸しから相談できます。

本番の業務システムでプレビュー機能の採用を見送るべき3つの場面

1つ目は、顧客向けにSLAを約束しているシステムです。プレビューの機能は「Pre-GA Offerings Terms」の対象で、現状有姿で提供され、サポートも限られるとドキュメント冒頭に書かれています。仕様が変わればコマンドの書き直しが要ります。

2つ目は、1台で受けきれない可能性のある処理です。インスタンスはオートスケールせず、同時実行も80で固定です。社内向けでも、月末に全員が同時に使う集計画面のような処理はサービスで組んでください。

3つ目は、ローカルに状態を書き込む既存アプリを、そのまま載せ替える場合です。停止・更新のたびにローカルの状態が消えます。保存先の改修工数を見込めないなら、VMに置いたままのほうが安全です。

よくある質問

Cloud Run instancesについて検索されることの多い質問に、公式ドキュメントで確認できる範囲で答えます。

Cloud Run instancesは一般提供されていますか？

2026年10月10日時点ではプレビューです。Cloud Runのリリースノートでは2026年8月25日にプレビューとして公開され、10月7日更新のドキュメントでもPre-GAの表記が残っています。コマンドは gcloud beta run instances で、YAMLにも run.googleapis.com/launch-stage: BETA の注記を付けます。一般提供の時期は公表されていません。

Cloud Run instancesは東京リージョンで使えますか？

作成と管理のドキュメントでは、Cloud Runの対応リージョンのうち除外されているのは europe-west1・us-central1・us-east1 の3つだけで、東京（asia-northeast1）は除外に含まれていません。サンプルの多くは us-central1 を指定しているため、コピーして使う際はリージョンを書き換えてください。

停止中のインスタンスにも料金はかかりますか？

公式ドキュメントでは課金の単位を「インスタンスの稼働時間」としていますが、停止中の扱いを明記したページは10月10日時点で見当たりません。発表ブログは「使わないときは停止し、必要なときに再開できる」と書いています。費用を抑えたい場合は停止を前提にしつつ、Cloud Billingのレポートで実際の請求を確かめてから運用を固めてください。

Cloud Runのサービスで最小インスタンス数を1にするのと何が違いますか？

最小インスタンス数を1にしたサービスは、負荷に応じて台数が増え、リクエストは負荷分散されます。どの台に届くかは選べず、URLもサービス単位です。インスタンスは1台固定で、そのインスタンス専用のURLを持ちます。CPUも、インスタンスは共有型でベースライン6.25%です。状態を持つ1台に確実に話しかけたいならインスタンス、台数を増やしたいならサービスです。

ソースコードから直接デプロイできますか？

できません。リソースモデルのページでは、インスタンスはコンテナイメージのデプロイのみに対応し、ソースからのデプロイは対象外とされています。Cloud BuildやGitHub ActionsでイメージをArtifact Registryへ登録し、--image で指定する流れになります。サービスで使っている gcloud run deploy --source の手順は流用できません。