--- title: "Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】" url: "https://www.issoh.co.jp/tech/details/18244/" published: 2026-10-10 updated: 2026-10-10 categories: ["Google Cloud"] publisher: "株式会社一創" --- # Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】 Cloud Run instancesは、オートスケールをせず1台のコンテナだけを動かし続けるCloud Runの新しいリソースです。2026年8月25日にプレビューとして公開されました。トラフィックが止まるとゼロまで縮む通常の[Cloud Runのサービス](https://www.issoh.co.jp/tech/details/15435/)と違い、インスタンスごとに更新や再起動をまたいで変わらない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日）](https://cloud.google.com/blog/products/serverless/introducing-cloud-run-instances)が挙げる特徴は4つです。1台だけを動かしてオートスケールしないこと。既定の自動再起動ポリシーのもとで最大7日間連続して動くこと。インスタンスごとに付くHTTPS URLが更新や再起動をまたいで変わらないこと。使わないときは停止し、必要なときに再開できること。 URLの形式は `https://INSTANCE_NAME-PROJECT_NUMBER.REGION.run.app` です。[作成と管理のドキュメント](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances)によると、インスタンス名はプロジェクトとリージョンの中で一意でなければならず、既存のサービスと同じ名前も使えません。サービスを `api` という名前で動かしているリージョンでは、インスタンスに同名は付けられないということです。 稼働期間の書き方には揺れがあります。ブログは「最大7日の連続稼働」と書き、[リソースモデルのページ](https://docs.cloud.google.com/run/docs/resource-model)は「数日から数週間動き、無期限に自動で再起動する」と書いています。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とはの解説記事](https://www.issoh.co.jp/tech/details/15435/)で扱っています。 ## gcloud beta run instancesで1台を作成・停止・再開する操作手順 [公式のクイックスタート](https://docs.cloud.google.com/run/docs/quickstarts/instances/create-instance)に沿って、サンプルイメージで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上限の設定ページ](https://docs.cloud.google.com/run/docs/configuring/instances/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回の再試行 [ライフサイクルのページ](https://docs.cloud.google.com/run/docs/instances/instance-lifecycle)では、選択できる再起動ポリシーは次の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](https://codelabs.developers.google.com/codelabs/cloud-run/deploy-openclaw-cloud-run-instances)では、[OpenClaw](https://www.issoh.co.jp/tech/details/10732/)の設定ファイルを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のリファレンス](https://docs.cloud.google.com/sdk/gcloud/reference/beta/run/instances/create)には `--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設定](https://docs.cloud.google.com/run/docs/securing/identity-aware-proxy-cloud-run)で接続を許可するGoogleアカウントを絞る設定が必要です。踏み台そのものの考え方と、SSH多段接続で組む従来の構成は[踏み台サーバーの解説記事](https://www.issoh.co.jp/tech/details/13320/)にまとめています。なお、ブログはインスタンスとサービスの両方への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の料金ページ](https://cloud.google.com/run/pricing)には、10月10日時点でインスタンス専用の単価表が見当たりません。課金の単位は「インスタンスの稼働時間」とされていますが、停止中の扱いも明記されていないため、見積はプレビュー中の参考値として扱ってください。 CPUを継続して使う処理、カーネルやディスクを触る処理、複数のプロセスを長く抱える処理は[Compute Engine](https://www.issoh.co.jp/tech/details/15665/)で組むほうが素直です。VMならCPUは専有でき、永続ディスクも付けられます。どちらで組むか、ネットワークと権限の設計を含めて決めたい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)で既存構成の棚卸しから相談できます。 ### 本番の業務システムでプレビュー機能の採用を見送るべき3つの場面 1つ目は、顧客向けにSLAを約束しているシステムです。プレビューの機能は「Pre-GA Offerings Terms」の対象で、現状有姿で提供され、サポートも限られるとドキュメント冒頭に書かれています。仕様が変わればコマンドの書き直しが要ります。 2つ目は、1台で受けきれない可能性のある処理です。インスタンスはオートスケールせず、同時実行も80で固定です。社内向けでも、月末に全員が同時に使う集計画面のような処理はサービスで組んでください。 3つ目は、ローカルに状態を書き込む既存アプリを、そのまま載せ替える場合です。停止・更新のたびにローカルの状態が消えます。保存先の改修工数を見込めないなら、VMに置いたままのほうが安全です。 ## よくある質問 Cloud Run instancesについて検索されることの多い質問に、公式ドキュメントで確認できる範囲で答えます。 ### Cloud Run instancesは一般提供されていますか？ 2026年10月10日時点ではプレビューです。[Cloud Runのリリースノート](https://docs.cloud.google.com/run/docs/release-notes)では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` の手順は流用できません。 ## 関連記事 - [Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15435/)：インスタンスの前提になるサービス・ジョブ・ワーカープールの仕組みと課金モデルを整理しています。 - [Compute Engineとは？GCPの仮想マシンの仕組み・料金とgcloudでのVM作成手順を実装者目線で解説](https://www.issoh.co.jp/tech/details/15665/)：CPUを専有したい常駐処理を載せる場合の比較先です。 - [Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15661/)：常駐処理が増えて複数台をまとめて管理したくなった段階の選択肢です。 - [踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】](https://www.issoh.co.jp/tech/details/13320/)：インスタンスを踏み台として使う前に、従来の構成と比べる材料になります。 - [Clawdbot（現OpenClaw）とは？できること・導入手順・危険性を解説](https://www.issoh.co.jp/tech/details/10732/)：公式ブログが常駐先の例に挙げたAIエージェント本体の機能と注意点です。 --- 出典: [Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】]()（株式会社一創）