n8nの二重実行を防ぐ｜再試行・同時送信・再起動を切り分ける

二重実行を防ぐには、同じ依頼のIDと、保存先が重複をどう扱うかを決めます。再試行を増やす設定だけでは、一回分の処理になるとは限りません。保存直後の通信断も試験に含めてください。

実行IDと、依頼のIDを分ける

同じ問い合わせを送り直すと、n8nでは別の実行が始まる場合があります。新しい実行IDだけで判断すると、同じ依頼を別件として作る可能性があります。重複を見分けるキーには、送り直しても変わらない受付IDや原稿IDを使います。

キーと一緒に内容のhashも保存すると、同じキーへ違う内容が届いた場合を区別できます。例えば原稿の版が違うのに同じキーなら、古い結果を無条件に返さず、更新か入力の衝突かを判断してください。

「保存先へ送る→保存される→成功を受け取る」の間で通信が切れると、送信側は失敗に見えても保存先には結果が残る場合があります。ここで新しい作成を送れば、同じ問い合わせが二件できる可能性があります。

状態は未処理、処理中、完了、要確認などに分けます。タイムアウトを未処理へ戻す前に、保存先が同じキーで結果を返せるか、受付IDから照会できるかを確認します。どちらもできなければ、確認待ちへ止める条件を決めます。

「まだないか検索→なければ作成」の二つの操作では、二つの実行がどちらも検索を通過できます。DBの一意制約などで同じキーを一件だけ保存し、すでに存在すれば既存の結果へ戻る設計を使います。

n8nのRemove Duplicatesは重複を見分ける用途に使えますが、その後の外部APIの保存まで一回だけになる保証とは別です。ノードの設定と、書き込み先の処理契約を分けて確認してください。

Devsでは2026年10月10日、SQLiteの一意キーと保存処理を使い、次の状況を実行しました。n8nのノードや外部SaaSを動かした試験ではなく、保存先の性質を確認するローカルのラボです。

一件を維持できたのは、同じSQLite DB内の一意制約と確定した保存記録を使えた条件です。異なる外部API、決済、メール送信などへ、この結果をそのまま保証として移せません。

最初は同じ合成入力を二回送って、応答だけでなく保存件数を見ます。その後、同時送信、保存直後の通信断、再起動を順に加えてください。保証できない条件が残るなら、その操作の自動再送を止めることも判断に含めます。

一時的な失敗の戻し方は通知・再試行・停止の分け方へ、WordPressの投稿IDとの照合は下書きの入稿手順へ分担します。