予算上限は、利用予測より先に損失許容度を決める
過去の平均費用に20％を足すだけでは、障害時の損失を説明できません。まず経営・事業側で、「原因不明のAI処理に、発見から停止まで最大いくら使われても事業継続に影響しないか」を決めます。これは通常月の利用予算ではなく、異常時に受け入れられる財務上の境界です。
たとえば粗利30万円の機能に、月20万円のAI上限を置くのは不釣り合いかもしれません。逆に、1件10万円の商談を生む機能を数千円で止めれば、請求は守れても売上を失います。上限は費用だけでなく、止まった場合の機会損失とセットで考えます。
一つの金額を、通常利用・余裕・事故枠に分ける
月間許容額が12万円なら、すべてを通常利用に割り当てません。平常時7万円、季節変動2万円、復旧や再処理1万円、予期しない増加2万円のように用途を分けます。どの枠を使い切ったら誰が判断するかまで決めると、現場がその場で上限を動かさずに済みます。
この配分は会計上の勘定科目ではなく、運用判断のための内訳です。たとえば通常枠が残っていても、事故枠2万円を30分で使い切る速度なら停止対象です。一方、繁忙期枠を計画どおり使い、注文も比例して増えているなら、総額が大きく見えても異常とは限りません。枠ごとに責任者と確認期限を決め、未使用分を別用途へ移す場合も承認履歴を残します。
- 通常利用：過去の中央値または保守的な予測
- 需要変動：セール、公開日、月末処理の余裕
- 復旧作業：障害後の再生成や確認テスト
- 事故枠：検知から停止までに許容する最大増分
月額だけでなく、1時間で失える額も計算する
月12万円なら安全とは限りません。ループが起きれば数時間で全額を使い切れます。最大リクエスト速度×1回あたりの高い方の推定費用から、1時間の最大露出を出し、営業時間外に何時間放置され得るかを掛けます。月間上限より小さい日次・時間帯のガードレールが必要か判断できます。
たとえば1回0.08ドル、最大毎分20回なら、1時間の露出は96ドルです。担当者が8時間不在なら768ドルまで進み得ます。この数字が許容損失を超えるなら、月間上限を微調整する前に、時間あたりの制御、再試行回数、夜間バッチの実行権限を見直すべきです。
稟議には、上限を上げる条件も書く
決裁資料には金額だけでなく、基準期間、対象機能、想定モデル、通常日の成功件数、停止時の代替導線を記載します。上限引き上げは、売上・問い合わせ・成功処理が増えた場合に限るなど、必要な証拠を先に合意します。
一時増額には必ず終了日時を付けます。期限のない例外は、翌月から通常ルールになってしまいます。
完成した予算シートは、月初の承認だけでしまわず、異常を確認したときの判断表として使います。現場が確認するのは残額、増加速度、守る顧客導線、承認なしで実行できる操作です。月末には予測と実績の差を記入し、差が30％を超えた項目だけ翌月の配分根拠を作り直します。更新後の配分、承認日、変更理由を版管理し、前月の判断根拠を上書きしないようにします。
最初は推定値でも、判断できる形にしておく
WordPress標準のAI Clientを通るリクエストについて、AI Cost Guardrails-CNXTの無料版で推定費用の傾向と基本のハードストップ保護を確認できます。推定値はプロバイダーの最終請求と一致する保証はないため、月末には実請求と照合し、差が大きければモデル単価や通信経路を見直してください。推定と請求の差は翌月の余裕率へ反映し、差分を理由なく毎月積み増さないようにします。照合日と確認者も予算シートへ必ず残します。
AI Cost Guardrails-CNXTをダウンロードし、「許容できる損失額から、月間AI予算を逆算する」のうち製品が対応する境界をWordPress上で動かします。Freeはサイト全体・呼び出し元別の月間USD・リクエスト試行数・トークン、Proは対応する短時間・失敗パターンを制御できます。