予算を知らせるだけでなく、サービスを止めるところまで作る
クラウドでサービスを作る際、費用の上限を決めても、通知を受け取るだけでは利用は止まりません。今回、自社サービスのために用意したのは、予算に達した通知を受けて、対象プロジェクトの課金を自動で切り離す仕組みです。確認したかったのは、設定が存在することではなく、通知から停止までが実際につながっていることでした。
構成の前提として、無料枠を先に使い、サーバーレスや、使わないときに0台まで縮むものを既定にしました。常時課金される仮想マシンや、常時起動のデータベースは避け、サービスごとに専用のプロジェクトを用意します。そのうえで、各プロジェクトに予算と課金の自動停止を付けました。
仕組みは、Google Cloud の公式の型「Disable billing to stop usage」に沿っています。月の予算を設定し、50 / 90 / 100% のしきい値で通知を出します。通知は、メッセージの受け口である Pub/Sub に流し、Cloud Functions の小さな関数で受け取ります。関数が予算の条件を判定し、対象プロジェクトの課金を切り離します。関数自体も、同時に動くのは1つまで、使わないときは0台としました。
実際に課金を外し、付け直せることを確認した
2026年7月18日の検証では、テストの通知を流して、関数が課金を切り離すところまで動かしました。記録では、関数が通知を受け取り、1秒で課金を切り離しています。その後、課金を付け直して復旧できることも確認しました。
ここで確かめたのは、通知を受ける処理だけではありません。関数には、課金を外すための「請求のプロジェクト管理者」の権限を付けてあります。その権限を使って実際に停止操作を実行できることと、停止した後に復旧できることを、一続きで確認しました。
ただし、この1秒は、テストの通知を受けて課金を切り離した際の実測です。利用額が予算に達してから1秒で止まることを示す数字ではありません。請求額の反映には数時間の遅れがあるため、関数が動く速さと、費用が通知に反映されるまでの時間は、分けて捉える必要があります。
別のプロジェクトでは、対象と判定を止めずに確かめる
2026年10月10日には、AI の API を使う別のプロジェクトにも同じ仕組みを置きました。このときは、すでにある構成をそのまま共用するのではなく、どのプロジェクトの費用を見て、どのプロジェクトを止めるのかを確認しました。
まず、予算の範囲を、そのプロジェクトだけに限定しました。請求アカウント全体を対象にすると、同じ請求アカウントにある別サービスも予算の対象になります。止めたいサービスと、費用を集計する範囲を合わせる必要がありました。
さらに、既存の関数は、切り離す対象のプロジェクトをコードに直接書く構成でした。共用の受け口を使い回すと、別のプロジェクトを止めてしまいます。そこで、手本の形を維持しながら、別のコピーを置きました。
試運転では、本当に課金を切り離さない設定で、疑似の通知を2回流しました。判定の記録は次のとおりです。
cost=750 budget=1500 → 予算未満なので何もしない
cost=1500 budget=1500 → DRY RUN: ここで課金を切り離すところ（実際には切らない）
予算未満では何もせず、予算と同じ値では切り離しの判定に進むことを確認できました。実行後も課金が付いたままであることを確かめてから、本番の設定に戻しました。
翌日の2026年10月11日には、本物の通知も届きました。cost=194.25 budget=1500 に対して、結果は「予算未満なので何もしない」でした。これは通知の経路が動いている証拠になります。一方、この通知で実際の停止を確認したわけではありません。実際の停止・復旧、疑似通知による判定、本物の通知の到達で、それぞれ確かめた内容が異なります。
自動停止を付ける前に、止まる範囲を決める
課金を切り離すと、そのプロジェクトのサービスは止まります。そのため、自動停止を設ける際には、停止対象の関数だけでなく、同じプロジェクトに何が入っているかも確認しました。
1つのプロジェクトに複数のサービスを入れていると、1つのサービスの暴走で、同居するサービスまで止まります。今回、サービスごとに専用のプロジェクトを用意したのは、停止の影響範囲を分けるためでもあります。
停止後の状態は、毎朝の Slack の1行で、課金が付いているかどうかを確認する運用にしました。課金が外れていれば、自動停止が働いたことを知る手掛かりになります。止める処理を作ることに加えて、止まった状態をどう把握するかまで決めています。
請求の反映を待たずに止める制限も置く
予算による自動停止は、最後の砦として扱いました。請求額の反映には数時間の遅れがあるため、設定した予算を、その金額を超えない厳密な上限として扱うことはできません。
その手前で利用回数を止めるために、関数の同時実行数の上限や、AI 呼び出しの1日上限を置く考え方を採っています。金額が通知に現れるのを待つ前に、処理の量を制限するためです。
アクセスの急増に対しては、毎秒のリクエスト数を見て、公開の入口を自動で閉じる「回路遮断」も別に置きました。条件の例は、5分間、毎秒10件を超えた場合です。予算通知とは異なる指標を使い、請求の反映を待たずに止める構成です。
今回の記録から示せるのは、課金の切り離しと復旧が動いたこと、追加したプロジェクトで判定と通知経路を確認できたことです。費用を止める判断では、これらの確認結果と、請求の反映に遅れがあるという条件を、合わせて扱っています。
業務に置き換えると
業務で同様の仕組みを用意するなら、設定項目を埋めたかどうかに加えて、次の点を点検できます。
- 実際に停止と復旧を確かめたか。 費用の上限を決めたうえで、一度は実際に止め、課金を付け直して復旧できるところまで確認します。
- 止まるサービスを書き出したか。 同じプロジェクトに含まれるサービスを確認し、まとめて止めたくないものは、サービスごとにプロジェクトを分けます。
- 予算の範囲と停止先が一致しているか。 費用を集計する対象と、関数が課金を切り離す対象を、それぞれ確認します。
- 本番を止めない試運転の後、設定を戻したか。 実際には停止しない設定で判定を確かめ、課金が付いたままであることと、本番の設定に戻したことを確認します。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。