本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

Google Cloudの支出上限が正式提供 止まる範囲と導入順

目次 · 7項目

検証用のGoogle CloudのプロジェクトでGemini APIを呼ぶ処理がループし、翌朝に請求額を見て気づく。費用の管理の仕組みは、これまで金額に近づいたことを知らせるのが中心で、利用そのものは止めませんでした。Google Cloudの告知も、止めるために支払い方法の紐付けを外すといった、影響が大きく元に戻しにくい仕組みを自前で組む企業があったと書いています。

この「金額に達したら利用を止める」機能が、支出の上限(spend caps)です。Cloud Billingのリリースノートでは2026年10月13日の項に一般提供(GA)が載り、10月30日のGoogle Cloud公式ブログで告知されました。この記事では、GAで加わった点、上限に達したときに止まるものと止まらないもの、業務システムで使うときの注意を、ブログとドキュメントから整理します。

GAで加わった3つの機能

10月30日のブログは、プレビュー以降の要望を受けた変更として、次の3つを挙げています。

  1. APIでの設定: 既存のCloud Billing Budgets APIから使える「spend caps API」で、プロジェクトごとの対象サービスの上限を設定・変更・削除できる。開発者が新しい検証用のプロジェクトを作ったときに、上限を自動で付けることもできる。ドキュメントでは、予算の spendCap の項目として扱う
  2. 概算費用の表示: AIサービスの上限は、利用から数分以内に、概算のリアルタイムの費用で発動する。発動したときの概算の費用を、Cost Reports(費用のレポート)の画面で見られるようになった。ドキュメントでは、用意されたレポート「Live costs by SKU」で開く
  3. 月初の自動解除: これまでは、上限が発動すると、画面から手動で解除するまで利用が止まったままだった。GAでは、発動した上限が翌月の初めに自動で解除され、止まっていたサービスが再開する

ブログは3つ目について、再開の前に厳しい手動の確認が必要な組織向けに、手動の操作が従来どおり残るとも書いています。ただしドキュメントとAPIの定義で確かめられる手動の解除は、止まったサービスを月の途中で再開する操作です。すべての上限は翌月の初めに自動で解除されると書かれていて、それを止める設定は載っていません。手動の確認を前提にする場合は、この違いをGoogle Cloudに確かめてください。

上限の単位は、1つのプロジェクトと1つのサービスです。期間は月単位で、毎月1日に始まります。フォルダ、組織、ラベルを単位にした予算や、複数のプロジェクトやサービスをまとめた予算には設定できません。リセラー経由の請求先アカウントも対象外です。上限に達すると、そのプロジェクトのそのサービスだけ、新しい利用が止まります。データやリソースは削除されず、範囲外のサービスには影響しません。

止まる請求と、止まらない請求

上限は請求のすべてを止めるわけではありません。GAのブログは「固定の費用」と「利用に応じた費用」の違いを理解するよう求めていて、ドキュメントにも同じ趣旨の説明があります。

Google Cloudの支出の上限の1か月の流れを示す図。上限の50%・80%・100%で請求先アカウントの管理者とプロジェクトのオーナーに通知が届き、100%で上限が発動すると、従量課金の利用と確約利用割引で賄われる利用は止まり、プロビジョンドスループットの利用と固定のリソースやデータは止まらない。翌月の初めに自動で解除され、月の途中で再開するには手動で解除する。手動で解除すると、その月は上限が再び発動しない

区分上限に達したとき
従量課金(pay-as-you-go)の新しい利用止まる
確約利用割引(CUD)で賄われる新しい利用止まる
処理中のリクエスト最後まで処理され、費用も発生する
プロビジョンドスループット(予約した処理能力)の利用止まらず、通常どおり処理される
動き続けるリソースの固定の利用(コンピューティングやストレージなど)止まらず、費用も発生し続ける
サブスクリプションの費用(Gemini Enterpriseなど)上限の対象外
データ・リソース削除されない

2026年7月28日のプレビューの告知は、CUDやプロビジョンドスループットのような固定の契約料金は、上限が発動しても契約どおりに請求が続く、と書いています。つまり上限で抑えられるのは、利用に応じて増える部分です。予約した容量の契約がある場合、その料金は上限の対象外として予算を組みます。

金額の判定にも注意点があります。ドキュメントによると、上限は割引やクレジットを除いた概算の総額で判定します。そのため、割引やクレジットのある契約では、請求額が上限に届く前に発動する可能性があります。また、発動は即時ではなく、超えた分は通常どおり請求されます。ドキュメントは、絶対に超えたくない金額より少し低く設定するよう勧めています。

通知は、上限の50%・80%・100%で、請求先アカウントの管理者とプロジェクトのオーナーに自動で届きます。ドキュメントによると、この通知の割合と宛先は変更できません。GAのブログは、これらの役割に適切な担当者が入っているかを確かめるよう勧めています。カスタムロールで管理するときは、請求先アカウントの単位なら billing.budgets.configureSpendCap、プロジェクトの単位なら billing.resourcebudgets.configureSpendCap の権限を加えます。

対象は4つのサービス

GAのブログは、対象を「eligible services(対象のサービス)」と書くだけで、一覧は載せていません。ドキュメントの一覧にあるのは、Gemini API、Gemini Enterprise Agent Platform(旧Vertex AI)、Cloud Run、Cloud Run functionsの4つで、プレビューの告知の表と同じです。2026年4月のGoogle Cloud Nextの告知ではMapsの名前も挙がっていましたが、ドキュメントの一覧にはありません。

Compute EngineやBigQueryのように、この一覧にないサービスの費用を上限で止められると考えて設計しないでください。一覧は今後変わる可能性があるため、設定の前にドキュメントで確かめます。BigQueryのAI関数には、別にトークンの上限があります。BigQueryのAI関数に日次トークン上限 設定の要点で整理しました。

月初の自動解除は、本番では両刃になる

ここからは編集部の整理です。月初の自動解除は、検証用のプロジェクトでは便利です。毎月の解除の作業がなくなり、開発者は月が変わればまた使えます。

一方、業務システムの本番のプロジェクトに上限を掛ける場合は、2つの点を先に決めておく必要があります。

  • 上限に達したら、月末まで止まってよいか: 上限は「止める」ための仕組みです。顧客向けの機能がGemini APIやCloud Runに依存していると、上限の発動はそのまま障害になります。止まったときの画面の表示や、利用者への案内を用意しておきます
  • 月初に自動で再開してよいか: 費用が膨らんだ原因(処理のループ、想定外の呼び出し)が直っていないまま月が変わると、同じ処理が再開します。ドキュメントには自動の解除を止める設定が載っていないため、月末までに原因を直すか、呼び出す側の処理を止めておく前提で手順を決めます

月の途中で手動で解除するときも、注意が要ります。ドキュメントによると、解除した月は、金額を増やさない限り上限が再び発動しません。解除してからサービスが元に戻るまで最大1時間かかることがあり、発動中の予算は編集も削除もできません。

導入の順番の提案

GAのブログが勧めるのは、まず本番以外の環境に、少額の厳しい上限を掛けることです。具体的には、開発者の検証用のプロジェクト、テスト用のクラスター、AIエージェントを試す環境が挙がっています。編集部としては、次の順番を提案します。

  1. 検証用のプロジェクトに少額の上限を掛ける: 新しいプロジェクトの作成時に、APIで上限を自動で付ける仕組みにすると、付け忘れがなくなります
  2. 通知の受け取り手を確かめる: 宛先は変更できないため、請求先アカウントの管理者とプロジェクトのオーナーの役割に、実際に費用を見る担当者が入っているかを確認します
  3. 発動したら、概算の費用を見て原因を探す: Cost Reportsの「Live costs by SKU」で、どのSKU(課金の品目)やプロジェクトが費用を押し上げたかを確かめます。ブログは、費用の急増を日次の信号で先に知らせる「早期の異常検知(Early Anomalies)」との組み合わせを勧めています
  4. 本番に掛けるかは、止まったときの影響を業務側と合意してから決める: 本番では、止めずに通知だけにする選択もあります。通知だけの既存の予算は上限付きに変更できないので、上限を掛けるときは予算を作り直します

AI APIの費用を部署や用途ごとに管理する考え方は、Anthropicの月間クレジットとClaude API予算ガバナンスでも扱っています。

確認した範囲

2026年11月6日に、Google Cloud公式ブログの「Google Cloud spend caps now generally available」(2026年10月30日)、「Detect early and enforce firmly with Google Cloud’s enhanced cost controls for AI spend」(2026年7月28日、プレビューの告知)、Google Cloud Next ‘26のFinOpsの告知(2026年4月22日)、Cloud Billingのリリースノート、支出の上限のドキュメント、Cloud Billing Budget APIのガイドとAPIの定義、Live costsのドキュメントを直接開いて確認しました(資料調査)。Google Cloudのコンソールでの設定も、上限の発動の確認もしていません。ブログが書く「手動の操作」と、ドキュメントの自動の解除の違いは、実際に動かしていないため決着していません。本番の扱いと導入の順番は編集部の提案です。

クラウドとAI APIの費用の上限や通知を、業務システムの運用にどう組み込むかは、開発・AI・自動化のご相談からお問い合わせください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る