入力と出力が同じ更新イベントを通ると循環が生まれる
たとえば投稿更新を契機にAI要約を作り、その要約をカスタムフィールドへ保存する構成を考えます。保存によって再び投稿更新フックが動けば、要約生成→保存→要約生成が続きます。外部サービスからWebhookで書き戻す場合も、WordPress側がその変更を新しい入力と判断すれば同じです。
具体例では、商品説明の変更がAI翻訳を呼び、翻訳文の保存が商品更新Webhookを送り、そのWebhookが再び翻訳を始めます。一周がすべて成功するためエラー率は0％のまま、5分ごとに費用だけが増えます。成功ログしかない事故があることを前提に、同じ対象IDの反復を見ます。
時系列にすると、循環の一周が見える
同じ投稿IDについて、更新元、変更フィールド、WebhookイベントID、AIリクエストIDを時刻順に並べます。一定間隔で同じ並びが繰り返されていれば循環です。Cronの再試行とは異なり、各処理自体は成功しているため、エラーログだけでは見つかりません。
時系列表は、イベントを受信した時刻ではなく、同じ対象が一周した順番を追えるようにします。商品ID42について、手動更新A、AI翻訳B、外部書き戻しC、再度AI翻訳Bという並びが2回以上続けば循環候補です。各行に発生元と親イベントIDを持たせると因果を追えます。
- 起点：人の保存、Cron、外部Webhookのどれか
- AI処理が書き換えたフィールド
- 書き戻しで再発火したフック
- 一周にかかる時間と1時間の実行回数
発生元マーカーと処理済みIDを組み合わせる
AIが書き戻す更新には「ai-summary-worker」のような発生元を付け、その発生元から来た更新では同じ生成処理を起動しないようにします。さらにWebhookイベントIDや対象内容のハッシュを保存し、同じイベントを再処理しないようにします。
最大実行深度は最後の安全網です。循環を3回で止めても、正当な理由で3回必要な処理を壊す可能性があります。発生元と処理済み判定を主にし、深度制限は予期しない経路への備えとして置きます。
発生元マーカーは利用者が変更できる入力値として信用せず、サーバー間で検証できる形にします。マーカーが欠落した古いWebhookにも備え、イベントIDの既処理判定を併用します。マーカーだけ、深度だけという単独対策では、別経路から戻った循環を見逃す可能性があります。
復旧では、止めた後に未完了処理を数える
循環の入口を止めたら、キュー、予約Cron、外部Webhookの再送待ちを確認します。コードを直しても、古いイベントが残っていれば再開時に再発します。処理済み・未処理・破棄の三つに分け、顧客データへの書き戻しが必要なものだけを手動で再開します。
復旧手順では、まず入口を閉じ、次にキューの増加が止まったことを確認し、その後に残件を分類します。入口を止める前にキューを削除しても、新しいイベントが補充され続けます。削除対象は再生成可能なものに限定し、顧客入力を含む未処理イベントは保全して再開順を決めます。
最後に、循環した場合の最大費用を限定する
修正後は、同じイベントを意図的に再送し、AI呼び出しが一度で止まるかを確認します。そのうえで、標準のAI Clientを通るリクエストには基本のハードストップ保護を置き、未知の循環が起きたときの推定費用を限定します。直接Webhook先からプロバイダーへ送る処理は別経路として管理してください。Webhook循環防止設計書には入口、発生元マーカー、既処理キー、最大深度、キュー退避先、再開責任者を一枚にまとめます。連携先を追加するときは、この図に新しい戻り経路がないことを確認してから公開します。
「Webhookの循環でAIリクエストが止まらなくなる条件」で整理した判断を「Webhook循環防止設計書」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。