『失敗したから無料』とは限らない
WordPress側でタイムアウトと表示されても、AI事業者側では処理が始まり、使用量が計上されている場合があります。その直後に同じ処理を自動再試行すると、利用者には1回に見えても、裏側では複数回分の費用が発生します。
まず、画面のエラー件数ではなく、外部へ実際に送られた回数と処理結果を対応させます。
一つの操作をリクエストIDで追う
利用者の操作、WordPress内部処理、外部API呼び出しに共通の相関IDを付けると、二重送信を判別しやすくなります。本文や個人情報を保存しなくても、時刻、機能、結果コード、試行番号、推定トークン量は記録できます。
実際には、フォーム送信IDを親として、API送信ごとにattempt=1、2、3を付けます。利用者操作100件に対して外部送信が147件あり、そのうち38件が同じ親IDなら、アクセス増より再試行が疑わしいと分かります。相関IDは推測しにくい値とし、画面へ不用意に露出させない運用も必要です。
- 最初の送信と再試行の時刻
- HTTP状態やタイムアウトの種類
- 事業者側のリクエスト識別子
- 最終的に利用可能な回答が届いたか
- 各試行の推定費用
失敗を三つに分けて扱う
一時的な混雑など、待って再試行する価値がある失敗。認証エラーや入力不備など、同じ条件では成功しない失敗。医療・法務など、機械的に繰り返さず人の確認へ回すべき失敗です。すべてを同じ回数だけ再試行する設計は避けます。
たとえば明示的な一時エラーは30秒後に1回だけ再試行し、再度失敗したらキューへ退避します。認証エラーは即座に停止して管理者へ通知し、入力長超過は文章を勝手に切らず利用者へ修正を求めます。『最大3回』のような一律ルールではなく、同じ条件で成功する可能性と、二重処理の害から分岐させます。
- 再試行候補：短時間の混雑、明示された一時エラー
- 即時停止：認証失敗、権限不足、形式不備
- 人へ引き継ぐ：判断リスクが高い内容、原因不明の反復
- 同一処理を再送する場合は、二重実行を防ぐ仕組みを確認する
『失敗損失率』を週次で確認する
失敗・重複した試行の推定費用を、対象機能の総推定費用で割ります。金額が小さくても比率が継続して高いなら、上限を下げる前に再試行条件やタイムアウトを直す余地があります。実請求とのずれは月次で補正してください。
総推定費用が週200ドル、失敗・重複分が36ドルなら損失率は18％です。これを5％未満へ下げる、という改善目標は、単に月額上限を20％削るより原因に近い施策です。ただし途中で応答が失われても事業者側では成功扱いになることがあるため、WordPress側の結果と請求側のリクエストを照合して分類します。
次の障害で迷わない再試行表を作る
代表的なエラーごとに、再試行の可否、最大回数、待機時間、最終担当者を1枚にまとめます。次に確かめるべきは、1回の利用者操作が外部では何回の送信になっているかです。そこが分かれば、無駄な費用を狭い範囲で止められます。
成果物の各行には、エラー区分、初回処理の状態、再送条件、二重実行防止の有無、利用者への表示、担当者への通知を記載します。障害訓練ではテスト用の1件を意図的に失敗させ、表どおりに止まるか確認します。仕様書として保管するだけでなく、プラグイン更新後に再試行挙動が変わっていないかを確かめる回帰テストにも使えます。訓練時は、外部送信回数、最終画面、キュー残件、通知到達を一組の証拠として保存します。再試行を減らしても利用者が連打するなら、送信中表示や重複クリック防止も別の改善項目にします。
「失敗と再試行に消えたAI費用を見える化する」の「エラー区分別の再試行判断表」は、同じ指標を継続して集めることで判断材料になります。AI Cost Guardrails-CNXTを無料でダウンロードし、WordPress上のCalls・Token・推定USDを計測し始めましょう。