あるサービスはわずかなリクエストにしか応答していないのに、想定以上のコストがかかります。別のサービスは多数の短い呼び出しを安価に処理しています。したがって、リクエスト数だけを制限している人は、後でインフラの請求書に現れるものを自動的に測っているわけではありません。コスト管理と負荷管理は、異なる地点で作用するのです。
Google は2026年十月12日、 Cloud Run 向け Budget spend caps の一般提供を発表しました。いったん設定すると、支出上限によって対象のワークロードを一時停止できます。これはインフラにとって重要な変更です。しかし、予算アラート、支出上限、個々のリクエストに対する制限を区別して初めて、その意味が理解できるようになります。
三つの問い、三つの異なる制限
リクエスト制限が答えるのは、たとえば「特定のクライアントは一定の期間内に何回呼び出しを送ってよいか」といった問いです。同時実行の作業に対する制限が問うのは「どれだけ並行して実行してよいか」です。一方、コスト制限は、その対象範囲内で料金が発生するリソース消費を見ます。これらの量は互いに関連していますが、置き換えられるものではありません。
私たちの架空のサービスには二つのタスクがあります。一つは短いステータス応答を返します。もう一つは長い文書を処理します。どちらもちょうど一つのリクエストから始まりますが、必要な作業量は異なります。たとえ両方のユーザーに同じ回数の呼び出しが許可されていても、両者がインフラに同じ負荷をかけるということにはなりません。単一のカウンターは、その各エントリーが持つ意味の違いを覆い隠してしまいます。
予算アラートはまだ停止ではありません
公式の課金ドキュメントでは、アラートのみの予算と支出上限が区別されています。説明されている上限は推定総コストを用いており、割引やクレジットは含まれません。対象範囲は単一のプロジェクトとサポート対象のサービスで、期間は月単位です。運用者は、何かを設定する前に、これらの条件を必ず読んでおくべきです。
適用も即時ではありません。Google は、遅延によって生じた超過分も請求されると指摘しています。したがって、入力した金額は、最終的な請求額がちょうどそこで止まるという数学的な約束ではありません。この新機能は技術的な介入手段を提供するものであり、課金の仕組みを理解することの代わりにはなりません。
Cloud Run については、製品ドキュメントに具体的な影響が記載されています。サービスはリクエストを処理できなくなり、5xx 番台のエラーを返します。その他のリソースの種類には、それぞれ独自の影響があります。したがって、コストの停止は可用性に関する判断でもあります。この帰結は、インシデント報告の中だけでなく、計画段階で考慮すべきものです。
机上演習で、どのルールがいつ適用されるかがわかります
このモデルを理解するために、稼働中のサービスを停止する必要はありません。三つの独立したカウンターを描いてみてください。クライアントごとの呼び出し数、同時に実行されている作業、そして対象期間の推定コストです。それぞれに対応する反応を割り当てます。一つ目のルールはクライアントからのそれ以上の呼び出しを拒否し、二つ目のルールは並列度を制限し、三つ目のルールは定義されたサービス範囲全体を一時停止できます。
Client limit: Who may send requests, and how often?
Concurrency limit: How much work runs at the same time?
Spend cap: When is the service in question paused?次に、二つの架空のケースを試してみましょう。多数の短いリクエストと、少数の負荷の高いリクエストです。入力するのは質的な違いだけにして、でっち上げたユーロ金額は入れないでください。この演習によって、そもそもどのルールがそれぞれのケースを捉えるのかがわかります。これは思考モデルであり、実測による負荷テストやコストテストではありません。
運用者のインフラは顧客の利用枠ではありません
KENJTEC はプラットフォームサービスに Cloud Run を使用しています。これはプロジェクトのインフラおよびデプロイのソースから確認できます。だからといって、Google の新機能が自動的に有効化されているということにはなりません。また、すべての KENJTEC の顧客アカウントに個別に調整可能なインフラ上限が与えられるわけでもありません。運用者のプロジェクトと顧客のサブスクリプションは、異なる課金の境界なのです。
したがって、実務上重要な問いは次のとおりです。制限はどの利用を守るためのものなのか、そしてそれが発動したときに、どの作業まで一緒に停止されてしまうのか。妥当な計画では、警告、介入、再開をまとめて記述します。そうして初めて、支出上限がリクエスト制限や自社の可用性要件とどのように整合するかを判断できます。
出典と情報の時点
2026年十月25日時点の調査とドキュメントに基づきます。 Cloud Run リリースノート — 2026年十月12日 · サービスの課金設定 — Budget spend caps（予算の支出上限） · 支出上限予算を管理する。
