まず「高い」ではなく、異常の範囲を一文にする
朝、プロバイダーの管理画面を開くと、前夜までの1日平均が20ドルだったのに、午前6時の時点ですでに60ドルを超えている。WordPressの表示や問い合わせフォームには目立った障害がない——この状況で最初に必要なのは、原因の推測ではなく「いつから・どのアカウントで・どれだけ増えたか」を固定することです。
プロバイダー画面の期間、タイムゾーン、対象プロジェクトを揃え、金額・トークン・リクエスト数のスクリーンショットまたはCSVを保存します。画面を更新する前に記録を残すのは、後から集計単位が変わっても当時の状態を再現できるようにするためです。
最初の5分で、請求事故と表示上の揺れを分ける
利用額だけを見て機能を停止する前に、実際の送信量も同じ方向へ動いているか確認します。金額だけが増えたなら、モデル変更、価格改定、長文化した入力、為替換算などの可能性があります。送信回数も増えていれば、Bot、Cron、Webhook、再試行を疑う余地が大きくなります。
たとえば、呼び出し回数が前日と同じ500件でも、1件あたりの入力が2,000トークンから8,000トークンへ増えていれば、アクセス遮断は的外れです。反対に、トークン量は同じまま深夜2時から5分ごとに件数が倍増しているなら、単価より実行経路を優先して調べます。この二つを分けるだけで、不要な全停止を避けやすくなります。
- 前日同時間帯と比べたリクエスト数・入力トークン・出力トークン
- モデル名、単価、APIキー、プロジェクトの切り替え履歴
- WordPressのCron実行、フォーム送信、Webhook受信の時刻
- 同時間帯の注文・会員登録・問い合わせ件数
全停止ではなく、増幅している経路を最小単位で止める
増加が続いている場合は、「もっとも費用を生んでいると確認できた経路」だけを一時停止します。たとえば夜間の要約バッチが同じ投稿を繰り返しているなら、そのCronだけを止め、顧客向けチャットまで落とす必要はありません。原因がまだ絞れない場合も、売上や問い合わせにつながる導線を明記したうえで、それ以外の自動処理から順に止めます。
APIキーの削除やログの消去は、最後の手段です。資格情報の漏えいが疑われる場合を除き、先に実行元、リクエストID、時刻、応答コードを保存しておくと、復旧後に同じ事故を再現せずに済みます。
30分シートには、次の確認時刻まで書く
初動記録には、発見時刻、当番者、保存した証拠、停止した処理、残した顧客導線、現在の増加速度を1枚にまとめます。そして「15分後に利用額の傾きを再確認する」のように、次の判断時刻を予約します。対応した事実と、まだ仮説にすぎないことは別欄にしてください。
30分後の合格条件は、「原因を完全に説明できた」ではなく、「費用の増加速度が通常の範囲へ戻り、残した顧客導線が動き、調査証拠が保存されている」です。未解明の仮説は担当者と期限を付けて次の調査へ渡します。初動で結論を急ぐより、損失拡大を止めた状態を再現可能にする方が重要です。
このシートは根本原因分析とは分けて保存し、未解明の項目だけを担当者と確認期限付きで次の調査チケットへ引き継ぎます。初動記録を後から書き換えないことで、判断時点で何が分かっていたかを再現できます。
- 確認済み：午前1時12分から特定ジョブの呼び出しが増加
- 未確認：外部Botが起点か、ジョブ自身の再試行か
- 実施済み：対象ジョブのみ停止、顧客向け検索は継続
- 次回判断：15分後に利用増加が止まったか確認
次の急増に備え、平常時の基準を先に置く
今回の対応が終わったら、通常日の推定費用と、ここを超えたら確認するという境界をWordPress側でも見える状態にします。AI Cost Guardrails-CNXTが対象にできるのは、WordPress標準のAI Clientを経由するリクエストです。直接プロバイダーへ送る独自実装は別途監視が必要なので、まず自サイトの通信経路を棚卸ししてください。
「AI費用が一晩で3倍に。最初の30分で確認すべきこと」で整理した判断を「AI費用急増・初動30分チェックシート」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。