---
title: "Cloud Run 予算上限の設定手順：spend capで止まる範囲・5xx対策・解除方法【2026年】"
url: "https://www.issoh.co.jp/tech/details/18341/"
published: 2026-10-14
updated: 2026-10-14
categories: ["Google Cloud"]
publisher: "株式会社一創"
---

# Cloud Run 予算上限の設定手順：spend capで止まる範囲・5xx対策・解除方法【2026年】

Cloud Runの予算上限（spend cap）は、Cloud Billingの予算で決めた月額を超えたときに、Cloud Runのワークロードを自動で止める仕組みです。2026年7月27日にプレビュー、10月12日にCloud Run側で一般提供（GA）となりました。上限に達すると、サービスはトラフィックを処理できずに5xxを返し、ジョブとワーカープールも停止する仕様です。この記事では、公式ドキュメントをもとに、止まる範囲と計測方法、コンソールとBudget APIでの設定手順、停止中の5xxを想定した設計、解除と月初の再開、本番で入れるかどうかの判断までを整理します。Cloud Run自体の仕組みと料金モデルは[Cloud Runとはの解説記事](https://www.issoh.co.jp/tech/details/15435/)で扱っています。

## まとめ：Cloud Runの予算上限で止まる範囲と本番プロジェクトで設定する際の結論

予算上限は「請求額が想定を超えたら、売上より先に止める」ための仕組みです。対象は1つのプロジェクトの1つのサービスで、期間は月単位に固定されます。判定は割引とクレジットを引く前の総額（推定値）で行われ、反映には遅れがあるため、目標額は払える上限より低めに置くのが前提です。

検証用のプロジェクト、個人開発、社内ツールには入れてください。止まっても困る人が少なく、設定ミスやループ呼び出しによる課金事故を月額で打ち切れます。

顧客向けの本番APIには、そのまま入れないのが結論です。上限に達した瞬間から月末まで5xxを返し続ける可能性があり、障害の損失が超過額を上回ります。本番は最大インスタンス数と予算アラートで膨張を抑え、予算上限は検証環境を分けたプロジェクト側に置きます。

## Cloud Runの予算上限（spend cap）が止める範囲と2026年10月GAの仕様

設定画面に進む前に、何が・どの単位で・何を基準に止まるのかを押さえます。ここを読み違えると、止めたくないものまで止まります。

### サービスは5xx・ジョブは起動失敗・ワーカープールは停止という止まり方の違い

[Cloud Runの課金設定ページ](https://docs.cloud.google.com/run/docs/configuring/billing-settings)（2026年10月12日更新）によると、予算上限はプロジェクト内のすべてのCloud Runのリソースに自動で適用されます。上限に達したときの動きはリソースごとに異なります。

| リソース    | 上限到達時の動き                 | 利用者から見える症状   |
| ------- | ------------------------ | ------------ |
| サービス    | 既存のサービスがトラフィックを処理できない    | HTTPの5xxが返る  |
| ジョブ     | 新しいタスクが始まらず実行中のタスクも完了しない | 定期バッチが途中で終わる |
| ワーカープール | 既存のインスタンスが処理を止める         | キューの滞留が増え続ける |

表に[Cloud Run instances](https://www.issoh.co.jp/tech/details/18244/)の行が無いのは、課金設定ページが10月14日時点でサービス・ジョブ・ワーカープールの3つしか挙げていないためです。「すべてのリソースに適用」とあるので、インスタンスも止まる前提で扱ってください。リソースやデータは削除されません。上限が解除されれば同じ構成のまま戻ります。

### 総額の推定コストで判定し割引とクレジットを含めない計測方法の注意

判定に使うのは請求書の額ではありません。[Cloud Billingの予算上限ページ](https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps)（10月13日更新）は、リスト価格ベースの「gross, estimated」コストで判定し、割引とクレジットを含めないと明記しています。無料トライアルのクレジットや確約利用割引で実際の請求が0円に近いプロジェクトでも、定価で計算した額が目標額を超えた時点で止まります。

コストデータの反映は通常1日以内ですが、24時間を超える場合もあるとされています。強制適用は即時ではなく、反映までに使った分はそのまま請求の対象です。ドキュメント自身が「絶対的な上限より少し低く設定する」ことを勧めており、超過分の責任は利用者にあると書いています。

対象外の費用もあります。VPCコネクタのVMはCompute Engineとして課金されるため、Cloud Runの予算上限では数えられません。下りのネットワーク費用まで上限の対象に含めたい場合は、課金設定ページがDirect VPC egressへの切り替えを勧めています。

### 1プロジェクト×1サービス単位という範囲とCloud Run functionsの別枠

予算上限の範囲は「1つのプロジェクト」と「1つの対象サービス」の組み合わせに限られます。フォルダ・組織・ラベル単位や、複数プロジェクトをまとめた予算には使えません。10月13日時点の対象サービスは次の4つです。

| サービス                    | サービスID           |
| ----------------------- | ---------------- |
| Cloud Run               | `152E-C115-5142` |
| Cloud Run functions     | `29E7-DA93-CA13` |
| Gemini API              | `AEFD-7695-64FA` |
| Agent Platform（旧Vertex） | `C7E2-9256-1C43` |

見落としやすいのは2行目です。[Cloud Run functions（旧Cloud Functions）](https://www.issoh.co.jp/tech/details/15538/)はCloud Runとは別のサービスIDで数えられるため、同じプロジェクトで両方を動かしているなら予算も2本要ります。Cloud Runの予算だけを作ると、関数側の暴走は止まりません。生成AIを呼ぶアプリなら、Gemini側の予算も合わせて検討してください。

## Cloud Billingコンソールとbudget APIで予算上限を設定する作業手順

設定はCloud Run側ではなく、Cloud Billingの「予算とアラート」で行います。数が少なければコンソール、プロジェクトが多いならBudget APIです。

### 必要なIAM権限とアラート専用予算から作り直す前提条件の確認

請求先アカウント全体を管理する場合は、請求先アカウントに対する `billing.budgets.configureSpendCap` 権限が必要です。事前定義ロールなら「請求先アカウント管理者」です。プロジェクト単位で管理する場合は、各プロジェクトに `billing.resourcebudgets.write` と `billing.resourcebudgets.configureSpendCap` を付けます。費用を画面で見るには `billing.resourceCosts.get` も足します。

前提条件は2つです。まず、使えるのはGoogle Cloudと直接契約している請求先アカウントだけで、販売代理店経由の請求先アカウントは対象外とされています。次に、通知だけを送る既存の予算は、編集して予算上限に変えられません。[従来の予算とアラート](https://docs.cloud.google.com/billing/docs/how-to/budgets)を作ってある場合は、削除して作り直す手順になります。同じ範囲の予算を重複して作れない仕様もあるため、古い予算を残したまま新しく作ろうとすると止まります。

### コンソールのSpend cap enforcementで目標額を入れる4画面の操作

コンソールでは、Cloud Billingの「予算とアラート」から次の順に進みます。

1. 「予算を作成」を押し、定義の画面で「Spend cap enforcement」を選んで名前を入れる
2. 範囲の画面で、対象のプロジェクトを1つと、サービスに「Cloud Run」を1つ選ぶ（期間は月次で固定）
3. 金額の画面で「Target amount」に月額の目標を入れる（予算タイプは指定額のみ）
4. アクションの画面は自動設定のまま「完了」で保存する

通知は50%・80%・100%の3段階で、宛先は請求先アカウントの管理者全員とプロジェクトのオーナーに固定されます。宛先も内容も変更できません。Slackへ流したい場合は、別途作った通知用の予算からPub/Subにつなぐ構成が要ります。設定後は、Cloud Runコンソールの概要ページで上限に対する消費の進み具合を確認できます。

### Budget APIのcurlでCloud Run用の予算上限を作成するリクエスト例

プロジェクトが多い組織では、[Budget APIの予算上限ページ](https://docs.cloud.google.com/billing/docs/how-to/budget-api-spend-cap)の手順でまとめて作れます。以下は、公式のリクエスト例のサービスIDをCloud Run（`152E-C115-5142`）に差し替えた例です。`my-app-dev` は対象のプロジェクト、`my-admin` はBudget APIを有効にしたプロジェクトに読み替えてください。

```
# 1) 対象プロジェクトの請求先アカウントIDを確認する
gcloud billing projects describe my-app-dev --format="value(billingAccountName)"
# 出力例: billingAccounts/012345-ABCDEF-678901

# 2) Budget APIを呼ぶ側のプロジェクトでAPIを有効にする
gcloud services enable billingbudgets.googleapis.com --project my-admin

# 3) 予算上限の定義を書く（金額は請求先アカウントの通貨で月3000単位）
cat > request.json <<'EOF'
{
  "displayName": "cloud-run-cap-my-app-dev",
  "budgetFilter": {
    "projects": ["projects/my-app-dev"],
    "services": ["services/152E-C115-5142"],
    "creditTypesTreatment": "EXCLUDE_ALL_CREDITS",
    "calendarPeriod": "MONTH"
  },
  "amount": { "specifiedAmount": { "units": "3000", "nanos": 0 } },
  "thresholdRules": [
    { "thresholdPercent": 0.5 },
    { "thresholdPercent": 0.8 },
    { "thresholdPercent": 1.0 }
  ],
  "notificationsRule": { "enableProjectLevelRecipients": true },
  "spendCap": { "inputState": "CONFIGURED" }
}
EOF

# 4) 作成する
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "x-goog-user-project: my-admin" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d @request.json \
  "https://billingbudgets.googleapis.com/v1/billingAccounts/012345-ABCDEF-678901/budgets"
```

固定値になっている項目が多い点に注意してください。`creditTypesTreatment` は `EXCLUDE_ALL_CREDITS`、`calendarPeriod` は `MONTH`、作成時の `spendCap.inputState` は `CONFIGURED` しか受け付けません。しきい値の基準に予測額（`FORECASTED_SPEND`）は使えず、通知の宛先も `enableProjectLevelRecipients` だけです。作成後のレスポンスで `"spendCap": {"outputState": "CONFIGURED"}` が返れば有効になっています。Cloud Run functionsも止めたい場合は、サービスIDを `29E7-DA93-CA13` にした定義をもう1本作ります。

## 上限到達で5xxを返すサービスを想定した停止時の設計と監視の組み方

予算上限を入れると、「月の途中でサービスが止まる」ことが仕様上の正常動作になります。止まる前提で、金額・クライアント・監視の3か所を設計します。

### 反映の遅れを見込んで絶対上限より低い目標額を置く金額の決め方

目標額は、払える上限そのものではなく、1日分の最大消費を差し引いた額に置きます。判定に使うコストデータの反映は通常1日以内で、それを超える日もあるためです。たとえば「月5万円までなら払える」プロジェクトで、暴走時の1日の消費が最大1万円と見込めるなら、目標額は4万円です。

1日の最大消費は、最大インスタンス数×1台あたりの単価×24時間で上限を見積もれます。[Cloud Runの料金ページ](https://cloud.google.com/run/pricing)の単価と、後述の最大インスタンス数の設定を組み合わせて計算してください。最大インスタンス数を絞らずに予算上限だけを入れると、この1日分が大きくなり、目標額を大きく下げる羽目になります。

### 停止中の5xxで再試行が膨らまないクライアントと監視側の設定

課金設定ページは返るステータスを「5xx」としか書いておらず、[Cloud Runのトラブルシューティングページ](https://docs.cloud.google.com/run/docs/troubleshooting)にも、請求先アカウントが上限に達すると5xxを返す可能性がある、という項目が置かれています。コードの番号で予算停止を見分けることはできません。クライアント側では、5xxを受けたときの再試行を指数バックオフにし、回数の上限を決めておきます。予算停止は月末まで続く可能性があり、即時の再試行を繰り返しても戻りません。

監視側は、外形監視の5xxアラートと、予算の100%通知が同時に来たら「予算停止」と判断する手順を運用に書いておきます。上限を超えた時点でCloud Runコンソールに強制適用のバナーが出るので、当番が最初に開く画面として決めておくと切り分けが早くなります。障害対応の手順書に「アプリのロールバック」より先に「予算状態の確認」を置いてください。止まった原因が予算なのに、コードを戻しても復旧しません。

### 最大インスタンス数で瞬間の膨張を抑え予算上限を最後の歯止めにする構成

予算上限は月額の歯止めで、1時間単位の暴走は止められません。瞬間の膨張を抑えるのは最大インスタンス数です。[最大インスタンス数のページ](https://docs.cloud.google.com/run/docs/configuring/max-instances)（10月9日更新）によると、既定はリビジョンごとに100台です。サービス単位の設定は即時に反映され、リビジョン単位の設定と両方がある場合は小さいほうが効きます。

```
# サービス単位で最大インスタンス数を20台に絞る（即時反映）
gcloud run services update my-api --max 20 --region asia-northeast1

# 設定を確認する（Scaling: Auto (Min: 0, Max: 20) の形で表示される）
gcloud run services describe my-api --region asia-northeast1
```

台数の上限に達したリクエストは「No available container instances」となり、トラブルシューティングページではHTTP 429の項目に載っています。429は「混んでいる」、予算停止の5xxは「月末まで止まっている」の意味になり、利用者への見せ方を分けられます。課金事故の大半はループ呼び出しや攻撃的なクローラーによる急増なので、まず最大インスタンス数で1日あたりの最大額を決め、予算上限は最後の歯止めとして重ねる順番が実務的です。

## 予算上限の解除・引き上げと月初の自動再開までを担当者が回す運用手順

止まった後の戻し方は2通りです。月をまたいで自動で戻るのを待つか、手動で解除するかを選びます。

### コンソールとAPIのAWAITING\_NEXT\_PERIODで行う予算上限の手動解除

コンソールでは、予算の編集画面で「Lift spend cap」を押して確定します。Cloud Runコンソールの概要ページからも、上限の調整や解除が可能です。APIでは、予算の `spendCap.inputState` を `AWAITING_NEXT_PERIOD` に変更します。

```
# 強制適用中の予算上限を解除する（BUDGET_IDは作成時のレスポンスのname末尾）
curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "x-goog-user-project: my-admin" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"spendCap": {"inputState": "AWAITING_NEXT_PERIOD"}}' \
  "https://billingbudgets.googleapis.com/v1/billingAccounts/012345-ABCDEF-678901/budgets/BUDGET_ID?updateMask=spendCap.inputState"
```

解除直後のレスポンスには `"outputState": "AWAITING_NEXT_PERIOD"` と `"reconciling": true` が入ります。強制適用中は、名前や目標額を含めて予算の編集も削除もできません。ほかの項目を変えようとすると `FAILED_PRECONDITION` で失敗するため、引き上げたい場合も先に解除します。

### 解除後に最大1時間かかる復旧と同月内に再発動しない仕様への備え

解除しても、サービスが完全に戻るまで最大1時間かかる場合があるとドキュメントは書いています。解除を押した直後に5xxが続いていても、すぐに再デプロイを重ねないでください。待つ時間を手順書に入れておくと、当番が二次対応で設定を壊すのを防げます。

もう1つの仕様は、同じ月の中で一度解除すると、目標額を引き上げない限り再発動しないことです。解除した瞬間から月末までは、上限の無い状態で課金されます。原因を潰さずに解除するのは避け、原因が分かるまでは最大インスタンス数を絞ってから解除する順番が安全です。何もしなければ、次の請求期間の初日（通常は翌月1日）に消費額が0に戻り、状態は「Configured」へ戻ってワークロードが再開します。リセットの時刻とタイムゾーンは、10月14日時点でドキュメントに記載がありません。

## Cloud Runの予算上限を採用する条件と本番サービスで見送る場面

判断を言い切ります。予算上限は「止まっても困らない環境の課金事故を打ち切る道具」で、本番の可用性と引き換えにする道具ではありません。

### 検証用・個人開発・社内ツールのプロジェクトで上限を必ず入れる条件

次のどれかに当てはまるプロジェクトには、予算上限を入れてください。

- 新人研修やハンズオンで作った検証用のプロジェクトで、消し忘れのサービスが残りやすい
- 生成AIのAPIを呼ぶ試作で、ループや再試行の不具合で呼び出しが膨らむ可能性がある
- 社内向けのツールで、半日止まっても手作業で代替できる
- 無料トライアルのクレジットで動かしており、クレジットが切れた後の請求に気付きにくい

特に効くのは最後の項目です。判定がクレジットを引く前の総額で行われるため、クレジットが残っている間でも定価換算で上限に達すれば止まります。請求が始まる前に、使いすぎに気付ける形になります。

### 顧客向け本番APIで停止より超過を選ぶべき場面と代わりの歯止め

顧客にSLAを約束しているAPI、決済や予約のように止まると売上が直接消える処理には、予算上限を入れません。1か月分の超過額より、月末まで5xxを返し続けた場合の損失と信用の毀損が大きいためです。範囲が1プロジェクト単位なので、本番と検証を同じプロジェクトに置いていると、検証環境の暴走で本番まで止まります。プロジェクトを分けることが先です。

本番側の歯止めは、最大インスタンス数と、通知だけの予算アラートを組み合わせます。AWSでの同じ設計は[AWS Budgetsの予算アクションをCLIで組む記事](https://www.issoh.co.jp/tech/details/18027/)で扱っており、通知から止めるまでを人の判断に残すという考え方は共通です。どのプロジェクトに上限を入れ、本番をどう分けるかを既存の構成から決めたい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)でプロジェクト構成の棚卸しから相談できます。

## よくある質問

Cloud Runの予算上限について検索されることの多い質問に、2026年10月14日時点の公式ドキュメントで確認できる範囲で答えます。

### Cloud Runの予算上限はいつ一般提供になりましたか？

[Cloud Runのリリースノート](https://docs.cloud.google.com/run/docs/release-notes)では、予算上限でワークロードを一時停止する機能が2026年7月27日にプレビュー、10月12日に一般提供（GA）となっています。[Cloud Billingのリリースノート](https://docs.cloud.google.com/billing/docs/release-notes)でも、10月13日に「限られたサービスで一般提供」と告知されました。対象サービスは今後のリリースで追加される予定とされています。

### 上限に達するとCloud Runのサービスやデータは削除されますか？

削除されません。予算上限ページの記載では、リソースやデータは削除されず、ほかのサービスやほかのプロジェクトにも影響しない扱いです。止まるのは対象プロジェクトの対象サービスの新しい利用だけで、処理中のリクエストは最後まで処理されて課金されます。解除するか翌月になれば、同じ構成のまま再開します。

### 既存の予算アラートを予算上限に切り替えられますか？

切り替えられません。通知だけの予算は編集で予算上限に変更できず、削除して「Spend cap enforcement」で作り直す必要があります。同じ範囲の予算を重複して作れない仕様もあるため、作り直す前に古い予算を消してください。通知をPub/Subへ流している場合は、その連携も作り直しの対象になります。

### 販売代理店経由の請求先アカウントでも予算上限を使えますか？

ドキュメント上は使えません。予算上限はGoogle Cloudと直接契約している顧客の請求先アカウントに限られ、販売代理店（リセラー）経由のアカウントは対象外と明記されています。請求先アカウントを移した場合も、元のアカウントで作った予算上限はすべて削除されるため、移行先で作り直します。

### Cloud Runの最大インスタンス数と予算上限はどちらを先に設定すべきですか？

最大インスタンス数が先です。最大インスタンス数はサービス単位の設定なら即時に効き、1時間あたりの最大消費を決める設定です。予算上限は月額で判定し、反映に1日程度の遅れがあります。最大インスタンス数で1日の上限額を決めてから、その額を差し引いて予算上限の目標額を置くと、遅れの間の超過も見積もれます。

## 関連記事

- [Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15435/)：予算上限の前提になるCloud Runの料金モデルとスケーリングを整理しています。
- [Cloud Run instancesとは？1台常駐の仕組み・作成手順・料金【2026年】](https://www.issoh.co.jp/tech/details/18244/)：常駐させる1台の構成と、共有vCPUで費用を抑える仕組みを扱っています。
- [Google Cloud Functionsとは？仕組み・料金とCloud Run functionsへの改称・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15538/)：別のサービスIDで予算を作る必要があるCloud Run functions側の解説です。
- [AWS Budgetsの設定手順：予算アラート・SNS通知・予算アクションをCLIで実装する](https://www.issoh.co.jp/tech/details/18027/)：AWSで同じ課金事故対策を組む場合の手順です。
- [FinOpsとは？クラウドコスト管理の仕組み・3フェーズと導入判断を解説](https://www.issoh.co.jp/tech/details/13408/)：予算上限を組織のコスト管理の中でどう位置付けるかの全体像です。

---

出典: [Cloud Run 予算上限の設定手順：spend capで止まる範囲・5xx対策・解除方法【2026年】](<https://www.issoh.co.jp/tech/details/18341/>)（株式会社一創）