『二重送信』を利用者の連打と決めつけない
フロントのボタンを一度押しても、JavaScriptのイベント登録が重複している、REST APIとadmin-ajax.phpの両方が動く、保存フックを複数プラグインが監視するなど、サーバーまでの途中でリクエストが増えることがあります。まず同じ入力に対して、ブラウザ送信、WordPress受信、AI Client呼び出し、プロバイダー受信がそれぞれ何回かを数えます。
再現時は、二重クリック防止をいったん疑うだけで終わらせません。マウス操作1回、Enter送信1回、モバイルタップ1回を別々に試し、ブラウザ開発者ツールのネットワーク欄、WordPress受信、AI送信の件数を並べます。入口が一つでも途中から二つになるなら、画面側のボタン制御は根本対策になりません。
一つの相関IDで、画面からプロバイダーまで追う
操作開始時に相関IDを発行し、各フックと送信ログへ引き継ぐと、増えた場所が分かります。個人情報やプロンプト本文を記録する必要はありません。処理種別、相関ID、時刻、発火元、結果コードだけでも経路は追えます。
相関IDはログの各行に同じ値を載せ、個々のリクエストIDとは分けます。一つの利用者操作から意図的に二つのAI処理を行う機能もあるため、外部IDが二つだけで重複とは断定できません。設計上期待する処理名と件数を経路マップに書き、実測との差を見ます。
- ブラウザのネットワーク送信回数
- REST・Ajaxエンドポイントへの到達回数
- 実行されたWordPressフック名と優先度
- AI Client呼び出しとプロバイダーのリクエストID
重複防止は、処理の責任者に近い場所へ置く
画面のボタンを連打不可にするだけでは、Webhookや直接リクエストを防げません。逆にプロバイダー直前ですべて弾くと、意図したフォールバックまで止める恐れがあります。どのコンポーネントが処理の成立を決めるのかを一つに定め、そこで相関IDまたは処理対象IDを使って一度だけ実行します。
第一送信が失敗した場合の扱いも決めます。「応答がない」と「処理されていない」は同じではないため、状態を照会できるなら確認してから再送します。
重複防止キーの有効期限が短すぎると、遅い処理の途中で同じ操作を受け付けます。長すぎると、利用者が修正して正当に再送した操作まで拒みます。対象ID、入力内容のハッシュ、操作種別を組み合わせ、平均処理時間と再編集の頻度から期限を決めます。
修正説明は、原因と影響範囲を分けて伝える
顧客には「ボタンの故障でした」ではなく、「1操作が特定フックで2回実行され、対象期間に最大○件の重複が生じた」と確認済みの事実を説明します。費用影響、データの二重保存、顧客への二重表示をそれぞれ調べ、未確認事項には期限を付けます。
通信経路マップの完成条件は、ブラウザからプロバイダーまでの各段階について、担当コンポーネント、入力、出力、再試行主体、重複を止める場所が一行で説明できることです。修正後のテスト結果も同じ図へ紐づけ、将来別プラグインを追加した際の受け入れ確認に使います。
修正後は、1操作あたりの基準値を監視する
主要操作ごとに「AI送信は1回」「失敗時のみ状態確認後に1回再試行」といった正常値を決めます。標準のAI Clientを経由する処理なら、AI Cost Guardrails-CNXTで推定費用と上限を確認できますが、重複の根本原因を自動修復するものではありません。まず経路の修正を完了させ、その後の再発検知に使ってください。経路マップへ修正後の試験証拠を紐づけ、将来別のフォームやプラグインを追加したときの受け入れ確認に使います。新しい経路を図へ説明できない変更は、二重実行の所有者が未定として公開を止めます。
「1回の操作でAIが二重送信される原因を見つける」で整理した判断を「二重送信の通信経路マップ」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。