Cronは一度だけ実行されるとは限らない
WP-Cronはアクセスを契機に動くため、処理の遅延や同時アクセスによって同じイベントが近い時刻に走ることがあります。さらに、AI側では処理が完了していてもWordPressが応答を受け取る前にタイムアウトすると、呼び出し元は「失敗」と判断して再送します。管理画面にエラーが1件しかなくても、プロバイダーには複数の有料リクエストが届いていることがあります。
例として、毎時00分に50記事を要約するジョブがあり、1記事の処理に70秒かかるのにHTTPタイムアウトが60秒なら、WordPressは失敗と判断します。AI側では70秒後に処理が完了していても、再試行がもう一度50記事を送れば請求は倍です。平均処理時間より短い待ち時間がないかを最初に調べます。
実行ログを、投稿IDとジョブIDでつなぐ
原因を確定するには、Cronの実行時刻だけでなく、処理対象を識別できるIDが必要です。同じ投稿ID・同じジョブIDに対して、開始ログが複数あり完了ログが一つしかないなら、同時実行が疑われます。開始は一つでもプロバイダーのリクエストIDが複数なら、HTTPクライアントや上位プラグインの再試行を追います。
切り分け表では、仮説ごとに肯定証拠と否定証拠を一つずつ置きます。同時起動説なら同一ジョブIDの開始が重なること、HTTP再試行説ならWordPressの開始は一つでプロバイダー側IDが複数になることが証拠です。ログがない箇所は『異常なし』ではなく『未観測』と書きます。
- WordPress側のイベント名、ジョブID、対象投稿ID
- 開始・送信・受信・保存・完了の各時刻
- HTTPステータス、タイムアウト秒数、再試行回数
- プロバイダー側のリクエストIDとトークン数
対策の中心は、回数制限より冪等性
単に再試行を0回にすると、一時的な通信障害で本来必要な処理まで失われます。先に「同じジョブIDは結果を一度だけ保存する」「実行中のロックがある間は次を始めない」「完了済みならAIへ送らず結果を再利用する」という冪等性を入れます。これなら安全な再試行を残しつつ、二重課金を防げます。
ロックには有効期限を設けます。無期限ロックは、プロセスが落ちたときに永久停止を生みます。平均処理時間の数倍を目安に期限を置き、期限切れ時は自動で再送せず、状態確認へ回す設計が扱いやすいでしょう。
処理結果を保存する直前にプロセスが落ちる場合もあります。外部の結果IDが分かるなら、再送前に状態を照会し、完了済みなら保存だけをやり直します。照会手段がない場合は入力のハッシュ、対象ID、送信時刻を残し、自動再送ではなく確認待ちへ回す方が二重課金を避けやすくなります。
修正は小さな対象で、タイムアウトも含めて試す
ステージングでは正常終了だけでなく、意図的に応答を遅らせたケース、途中で接続を切ったケース、同じイベントを二重起動したケースを試します。合格条件は「画面上で1回に見える」ことではなく、プロバイダー側の有料呼び出しも1回に収まることです。
検証結果は『条件・期待結果・実測・証拠・判定』の5列で残します。再試行を無効にして一度通っただけでは、通信障害時の欠損が未検証です。正常、タイムアウト、同時起動、途中終了の4ケースで、重複せず未完了分だけ再開できることを確認してから本番へ戻します。
- 正常時：1ジョブにつき送信・保存が各1回
- タイムアウト時：状態照会後にだけ再試行
- 同時起動時：後続はロックで待機または終了
- 失敗時：対象IDを保ったまま手動再開できる
まずCron経由のAI処理を一つ選び、見える化する
すべての定期処理を一度に直す必要はありません。費用の大きいジョブを一つ選び、1実行あたりのリクエスト数と推定費用が平常時にいくつかを確認してください。標準のAI Clientを経由する処理なら、無料版の基本停止を検証する候補になります。直接API呼び出しには別の制御が必要です。
「WordPress Cronの再試行でAI請求が膨らむ仕組みと止め方」で整理した判断を「Cron重複実行の切り分け表」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。