Michael Johnsonクラウドコンピューティングの支出を制限しながら、稼働中のアプリケーションを停止させずに済むでしょうか。Cloudflareではどちらの設定も利用できますが、ハードリミットはアカウント内の製品全体に適用されるスイッチのようなものです。しきい値に達すると、対象となる新たな操作がブロックされます。一方で、このしきい値は請求額の上限を保証しません。
2026年11月13日、Cloudflareは従量課金制（Pay-as-you-go）のお客様向けにSpend Managementの提供開始を発表しました。開始時点では、WorkersとDurable Objectsで上限と通知を利用できます。これは予期せぬ利用増加を防ぐ自動的な安全装置ですが、どのサービスが同じ一括停止の対象になるのかをチームが理解していることが前提です。Cloudflareの説明を見てみましょう。
支出通知とは何が違うのか？
通知は、支出が設定した水準に達したことを知らせますが、製品の稼働は続きます。ハードリミットは、対象となる操作をブロックします。Spend Managementでは、製品ごとに上限額、通知のしきい値、設定した場合は通知先のメールアドレスを含むポリシーを指定します。WorkersとDurable Objectsの上限は相互に独立しており、それぞれアカウント内の該当製品全体に適用されます。Cloudflareのドキュメントによると、単一のWorker、Durable Objectsの個別ネームスペース、個々のメトリクスに対するしきい値は設定できません。
実際の選択はシンプルです。可用性を優先するなら通知を選び、さらなる利用を抑えるために製品の対象操作を止めてもよいとチームが判断するなら、ブロックする上限を選びます。
なぜ上限は設定額ちょうどで発動しないのか？
支出の計上とブロックの反映は瞬時には行われません。Cloudflareによると、ダッシュボードの支出表示はほぼリアルタイムで、反映まで10分未満です。一方、料金計算エンジンはリクエストごとの処理経路上にはありません。ポリシーはネットワーク上のノードへ非同期に配布され、実行環境はローカル状態を定期的に更新する際にポリシーを適用します。CloudflareはSpend Managementの仕組みをこのように説明しています。
そのため、設定したしきい値はブロックが始まるべきポイントであって、最終請求額の厳密な上限ではありません。支出の計上とルールの配布が進む間、操作が継続する可能性があります。また、上限の対象外となる請求もあります。たとえば、Workers Paidのサブスクリプション料金は除外され、Durable Objectsの保存データは一時停止後も支出を発生させる場合があります。最終的な金額は請求書で確認するよう、Cloudflareは注意を促しています。
Workersの上限でアプリケーションのどこが停止するのか？
Workersの上限は、無料枠を差し引いた後のアカウント内すべてのWorkersのリクエストとCPU時間に関する支出を合算します。ブロックが有効になると、Cloudflareはコストが発生するコードへの新しい呼び出しを拒否します。Workerのコードを実行せずに配信される静的アセットは引き続き動作します。適用範囲はWorkersのドキュメントで説明されています。
本番アプリケーションとテスト用Workerを同じアカウントで運用している場合を考えてみましょう。テスト負荷によってWorkers全体の支出がしきい値に達すると、同じアカウント内の本番コードもブロックされる可能性があります。アプリケーションごとに上限を分けることはできません。影響を分離するには、対象の負荷を別のアカウントに分けるか、Workersの停止が許容できない場合は通知を選びます。
Durable Objectsの個別上限では、リクエスト、実行時間、SQLite行の読み取りと書き込み、key-valueストレージの読み取り、書き込み、削除の各操作が計上されます。Workers、Workers AI、KV、R2、その他の製品は対象外です。アプリケーションが複数のサービスに依存している場合、1つの上限で保護できるのは該当する支出の一部だけです。また、1つの構成要素が停止するだけでもアプリケーションの動作に支障が出ることがあります。
ブロックを有効にする前に確認すること
まず、アカウント内の依存関係を整理しましょう。どのアプリケーションがWorkersを使うのか、どのバックグラウンドタスクがスケジュールやキューで実行されるのか、どのサービスがDurable Objectsを呼び出すのかを確認します。そのうえで、どの製品なら自動停止を許容できるかを決めます。停止のほうが超過支出より深刻なら、ブロックは設定せず通知のしきい値を設定します。ブロックを許容できる場合は、処理の遅れ、無料枠、上限対象外の支出を考慮して金額を選びます。
Cloudflareによると、設定はダッシュボード、cf CLI、REST APIから行えます。たとえばAPIでポリシーを作成する際は、セント単位の金額にthreshold_cents、製品にproduct_id、動作にaction、通知先にnotification_emailの各フィールドを使います。例は同社の発表記事にあります。設定を自動化しても適用範囲は変わらず、上限は引き続きアカウント内の製品全体に適用されます。
復旧手順もあらかじめ決めておきましょう。次の請求期間を待たずに停止を解除するには、累積支出を上回る金額まで上限を引き上げるか、上限を無効にするか、ポリシーを削除するようCloudflareは案内しています。変更が有効になるまで数分かかる場合があり、同じ上限を再び有効にしても、当該期間の支出はリセットされません。
この機能が役立つのはどんな場合か？
Spend Managementは、利用増加に対する自動的な対応を追加します。メール通知だけでなく、選択した製品の対象操作をシステムが停止できるようになります。テスト用タスクがあるアカウントでは、制御不能な負荷を防ぐ安全装置になり得ます。一方、複数の重要サービスを抱えるアカウントでは、共通の上限によって、アカウント内のすべてのWorkersまたはDurable Objectsの予算と可用性が結び付けられます。
判断の基準は、停止によって許容できる損失です。稼働の継続を優先するなら、まず通知を設定し、支出を監視しましょう。それ以上の利用を抑えることが優先なら、依存関係を確認して復旧手順を準備したうえでブロックを有効にします。しきい値は請求額を正確に保証する約束ではなく、製品を停止するためのポリシーとして計画する必要があります。
