Google Cloudの支出上限が正式提供、予約済みスループットのリクエストは停止されない

Google Cloudは2026年10月30日、Google Cloud Budgetsの支出上限が一般提供になったと発表した。対象サービス向けのAPI、推定費用を示すライブレポート、月ごとの自動リセットを追加し、リソースを削除せずに過剰な利用を抑える仕組みである。上限に達すると従量課金と確約利用割引の対象リクエストは停止するが、Provisioned Throughputの予約済み容量を使うリクエストは停止しない。本サイトの11月2日号では、元の発表日とこの例外を区別して記録する。

新しい支出上限APIは既存のCloud Billing Budgets APIから利用できる。管理者はプロジェクト内の対象サービスについて、上限の作成、更新、解除、削除をプログラムから実行できる。開発用サンドボックスや短期間の実験プロジェクトを作る際に小さな上限を同時に設定すれば、後日請求書を確認するまで無制限に使われる事態を減らせる。ただし、すべてのGoogle Cloudサービスで強制停止が可能になるわけではない。導入前にサービスの対象範囲、プロジェクト、請求権限、設定値を確認し、組織全体の費用を確実に封じられると誤認しないことが重要である。

AIサービスについて、Googleは推定されたライブ費用を用いるため利用後数分以内に上限が発動し得るとしている。Cost Reportsには、その発動判断に用いた比較的速い推定値が表示される。通常の請求処理による確定後の純費用を待たずに原因を調査できる一方、速報値と最終的な請求額には時間差や差額があり得る。運用記録には設定、発動時刻、ライブ費用の画面、拒否されたリクエストの応答、後日の確定請求を残すべきだ。「数分」は対象AIサービスについての説明であり、すべての費用が境界額で厳密に止まる保証ではない。

APIガイドでは、全ての上限が次の予算期間の開始時にCONFIGUREDへ自動リセットされ、遮断されたサービスが再開する。当期中の手動解除は早期の再開を意味する。AWAITING_NEXT_PERIODに設定すると、上限額を増やしてinputStateをCONFIGUREDに戻さない限り、その期間は再発動しない。主ブログはmanual overrideの継続を述べるが、ガイドには翌期の自動復旧を無効にして内蔵の承認待ちにする選択肢は示されない。期間をまたぐ承認は別途外部の制御を設計する提案であり、製品の標準機能ではない。月初前に異常作業を調査する。

既定の通知は上限の50%、80%、100%で請求管理者とプロジェクト所有者に送られる。自動作成したプロジェクトでも実際に担当者へ届くかを確認し、必要ならカスタムロールに管理権限を追加する。ただし、上限を解除できる権限は限定し、操作履歴を残す方がよい。まず非本番の小さなサンドボックスに低い上限を設定し、制御された利用で通知、ライブレポート、リクエストの拒否、リセットを観察する。正当な作業が止まった場合の復旧方法と、対象外の費用が続く場合の連絡先も事前に決めておく。

もっとも重要な境界はProvisioned Throughputである。Googleの原文は、予約済み容量によるリクエストは支出上限で決して停止せず、しきい値に達しても通常どおり処理されると明記している。一方、従量課金および確約利用割引でカバーされるリクエストは停止する。両方の課金モデルを使うチームは、従量リクエストが一つ拒否されたことから総費用も止まったと推論してはいけない。予約容量や固定契約は別に棚卸しし、請求レポートや契約管理で監視する。支出上限は対象サービスへのリクエストを抑える仕組みとして説明すべきである。

検証では対象プロジェクト、サービス、API権限と通知先を列挙する。翌予算期間の自動リセットと、当期中の手動早期解除、AWAITING_NEXT_PERIODによる当期の再発動停止条件を区別する。破棄可能な環境で制御された利用により発動させ、時刻、推定費用、応答コードと後日の請求を保存し、対象の従量リクエストと実際に使うProvisioned Throughputを別々に試す。跨期の承認を追加するなら外部制御として別途検証し、内蔵スイッチとは扱わない。

一般提供によって上限を自動設定し、発動理由を調べやすくなった。月次リセットは運用上の再開判断も変える。実際の保護はサービスと課金方式に依存するため、API設定とリクエストの観測で対象範囲を確かめ、Provisioned Throughputなど継続する契約費用には別の管理策を用いる必要がある。