自動処理の再実行で二重登録しないための確認表

例は「注文 O-104 の受付通知を一度送る」処理です。再起動のたびに変わる実行番号とは別に、対象と操作を表すキーを決めます。注文変更の通知は別操作です。同じ注文だからと永久にまとめると、必要な通知まで消してしまいます。顧客名やメールアドレスをキーとして公開しないでください。

送信先APIが冪等性キーを受け付けるなら、その対象操作・保持期間・同じキーで内容を変えた場合の仕様を確認します。すべてのAPIが対応するわけではありません。対応しない送信先では、処理結果を照会してから再開するか、結果不明として止める選択が必要です。

「記録を検索し、なければ追加する」だけでは、同時に二つの処理が通過することがあります。一意制約などを使った不可分な予約が必要です。予約だけで完了扱いにすると、予約後の停止で未処理の仕事を失います。

1. 同じキー・同じ内容を二回入力し、送信先の結果が一つか確認する。
2. 二つの実行を同時に開始し、予約を取得できた側だけが書き込むか確認する。
3. 送信先で成功した直後に応答を失うケースを試し、結果不明から無条件再送しないか確認する。
4. 同じキーで内容だけを変え、誤って以前の結果を成功として返さないか確認する。
5. 保持期間を過ぎた古い入力を再投入し、想定外の二重操作を起こさない扱いを決める。

試験には外部送信を行わない模擬の送信先を使います。予約・成功結果の記録は再起動後も残る必要があります。VPSへ移すだけではこの設計は成立しません。

Stripeの冪等リクエスト仕様は同じキーの応答再利用と保持期間の注意点を説明しています。ここでは仕様の一例として参照しており、決済連携の導入は不要です。n8nの公式解説も手動再実行で実行IDが変わる点を区別しています。このページの状態表と試験項目はSelparoの設計案で、特定の構成での実装保証ではありません。

本文の受入条件を決めた仕事をClaude Codeで進める場合、次は入力に届く場所とPCの稼働時間から実行場所を選べます。

診断はClaude Codeの実行場所を選ぶためのものです。容量計算やn8n・Codexの設定は扱いません。VPS結果には広告 / PRがあり、不要なら契約しません。