上限を決める前に、「1日」と「1か月」を混ぜない
最初に揃えるのは期間と単位です。月額費用だけを見て日次の異常を判断すると、月の予算が数時間で使われるリスクを見落とします。反対に、最も多かった1時間だけを基準に月間上限を作ると、通常利用まで過大評価します。
『7日間基準値・仮上限計算シート』には、日ごとの呼び出し数、入力・出力トークン、推定費用、成功件数、失敗・再試行を同じタイムゾーンで記録します。AI Cost Guardrails-CNXTで観測できるのはWordPress標準のAI Client経由の処理なので、直接APIの利用はプロバイダー側の記録から別行として加えます。
「普通の7日間」を選び、特殊日には印を付ける
7日間という長さには、平日と週末、定期バックグラウンド処理、編集担当者の作業を一巡させる意味があります。ただし、キャンペーン、障害、移行テスト、大量入稿が含まれた週を無条件に通常値へ混ぜてはいけません。特殊日は除外するのではなく、理由を付けて別に残します。
- 曜日ごとの顧客利用件数。平均だけでなく、正常に完了した日の最大値も残す
- WP-Cronなど定期処理の実行時刻。予定件数と実行件数の差を確認する
- 編集・開発担当者によるテスト時間。顧客利用と混ぜず内部作業として注記する
- セール、広告、メディア掲載などの流入要因。開始・終了時刻と成果件数を対応させる
- タイムアウトと再試行が発生した時間帯。同一処理の重複が費用へ与えた分を分ける
仮上限は「通常ピークの余裕」と「最大許容損失」の小さい方
まず、特殊日を除く各日の最大値を並べ、正常に完了した業務のピークを求めます。そこに曜日差や小さな需要増を吸収する余裕を加えた値が、運用上必要な上限の候補です。次に、異常が続いた場合でも会社が受け入れられる最大損失から、金額面の上限候補を求めます。
実際の仮上限には、二つの候補のうち小さい方を採用します。通常業務がその値を超えるなら、上限を上げる前に、重要機能と社内自動処理を分ける、出力長を抑える、再試行を直すといった設計変更を検討します。
例として、通常日は1日800円、正常な最大日が1,200円、需要増の余裕を25％とするなら運用候補は1,500円です。一方、異常を2時間見逃しても許せる追加損失が1,300円なら、仮の日次上限は小さい方の1,300円になります。ただし通常ピーク1,200円との差が100円しかないため、購入補助を残して夜間生成だけを別枠にできないか確認します。数字はそのまま設定へ写すのではなく、誤停止の影響を見つける材料として使います。
境界ケースを紙上で試してから、停止条件にする
仮上限を設定する前に、三つのケースを当てはめます。通常の最繁忙日、正当な流入が普段の2倍になった日、同一処理が再試行で増幅した日です。どのケースで何を止め、何を残すかを書けなければ、その数字だけでは運用判断になりません。試算表には各ケースの『上限到達時刻』『止まる機能』『残る代替導線』『想定損失』を並べ、経理と運用が同じ数字を見られるようにします。
特に購入、問い合わせ、会員サポートなど顧客価値に直結する処理は、社内生成や夜間バッチと分けて考えます。全体を一律に止める上限は管理が簡単ですが、正当な需要まで止める影響を必ず計算に含めます。
仮上限には、有効期限と見直し条件を付ける
7日間の数字は永久の正解ではありません。『まず14日間適用し、通常業務が80％を超える日が2回あれば再計算』『キャンペーン前に別途承認』のように、日付と再検討条件を設定します。変更者、根拠に使った期間、直接APIを含むかどうかも記録します。計算シートは毎月上書きせず、版を分けて残します。モデル単価、プロンプト長、利用機能の変更日を記録しておけば、上限が増えた理由が顧客需要なのか単価変更なのかを翌月も説明できます。実績と仮定のセルを色分けし、承認者が推定値を事実と取り違えないようにします。
次にサイトで確かめるのは、監視モードに7日分の曜日差と定期処理が現れているかです。観測されていない主要AI機能がある場合は、上限計算へ進む前に通信経路を分けてください。さらに、単価が20％上がる場合と利用件数が20％増える場合を計算シートで別々に試します。前者はモデルや出力長の見直し、後者は正当な需要か反復かの確認が主な対策となり、同じ費用増でも判断が変わるからです。試算後の仮上限と見直し日を承認者へ共有します。
「最初のAI利用上限は、7日間の通常利用データと許容損失から決める」の「7日間基準値・仮上限計算シート」を、最初の実環境導入に使ってください。AI Cost Guardrails-CNXTを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。