自動化が二重実行される原因と、重複処理を防ぐ設計の型

重複の発生パターン一覧

まず、自分の重複がどのパターンかを切り分けます。対処が違うためです。

• 1、パターン：同じ出来事の再送、典型的な様子：Webhookの送信元が、応答が遅いと同じ内容を再送する、主な対処：一意キーで2回目を弾く
• 2、パターン：タイムアウト後の再試行、典型的な様子：書き込みは成功したのに応答が返らず、再実行で二重に作られる、主な対処：書き込み前に「処理中」を記録
• 3、パターン：同じトリガーの複数ワークフロー、典型的な様子：2つの自動化が同じ出来事に反応する、主な対処：担当を1本に絞る
• 4、パターン：ループ、典型的な様子：自動化の書き込みが、自分自身のトリガーを再び起動する、主な対処：自動化が書いた印で除外
• 5、パターン：条件が広すぎる、典型的な様子：意図しない更新までトリガーになる、主な対処：トリガー側で条件を絞る
• 6、パターン：テスト値のまま、典型的な様子：固定文字を入れたまま本番稼働し、同じ内容が量産される、主な対処：動的な値に差し替え
• 7、パターン：手動の再実行、典型的な様子：失敗した実行を人が再実行し、成功済みの分まで再処理される、主な対処：処理済み記録で成功分を飛ばす

Zapierの公式ヘルプ「Zap is creating duplicate data」(2026年5月29日更新と表示)でも、原因として固定値のまま使っていること、トリガー設定が広すぎること、同じトリガーを使う複数のZap、Zapのループ、タイムアウトが挙げられています。上の表の3〜6はこれに対応し、2はタイムアウトした実行の再生による重複として説明されています。1と7は一般的な運用上の整理で、私の編集上の分類です。

このうち3〜6はトリガーやフローの設定を見直す対象です。1、2、7は同じ出来事が再び届いたり、成功したか判定できないまま再試行したりする場合があり、設計を見直しても起こりえます。ここに処理済み記録が役立ちます。

一意キーを決める

処理済み記録の精度は、キーの質で決まります。

• 良いキー:注文ID、イベントID、メッセージID、行に振った連番など、出来事ごとに固定で、再送されても変わらない値
• 悪いキー:受信時刻、実行ID、乱数。再送や再実行のたびに変わるため、重複を見逃します
• 複合キー:同じ注文でも「作成」と「更新」を別処理にしたいなら、注文ID + イベント種別 のように連結します

説明用の例です。

order_1042:created
order_1042:paid

「注文1042の作成」と「注文1042の入金」は別の出来事として扱え、同じ「入金」が2回届いたときだけ弾けます。

送信元が固有のIDを持たない場合は、メールアドレスと申込日時のように、変わらない項目を連結して作ります。ただし、同じ人が正当に2回申し込む場合まで弾いてしまわないか、人が確認してください。

処理済みチェック列を使った防止設計の手順

スプレッドシートやデータベースに、次の列を持つ管理表を1つ用意します。説明用の例です。

• order_1042:created、status：完了、first_seen_at：2026-10-27 10:00、completed_at：2026-10-27 10:00、note：
• order_1043:created、status：処理中、first_seen_at：2026-10-27 10:05、completed_at：、note：
• order_1044:created、status：失敗、first_seen_at：2026-10-27 10:07、completed_at：、note：宛先不明

手順

1. キーを作る:トリガー直後に、前節の方針でキーを1つの値にします。
2. 管理表を引く:キーが存在するか確認します。
3. 分岐する:

• 存在しない → 手順4へ
• 「完了」 → 何もせず終了(再送には成功応答を返す)
• 「処理中」 → 終了して重複を防ぐ。ただし一定時間を過ぎた「処理中」は人の確認対象にする
• 「失敗」 → 再試行してよいか、条件を決めておく

1. 先に「処理中」を書く:副作用の処理の前に記録します。後から書くと、処理が成功して記録前に落ちた場合に二重になります。
2. 本処理を実行する。
3. 結果を書き戻す:成功なら「完了」、失敗なら「失敗」と理由をnoteに残します。

ポイントは「処理済みを後で書く」のではなく、先に押さえて、終わったら確定する二段階にすることです。ただし、手順2の確認と手順4の書き込みの間に隙間があるため、ほぼ同時に2件届く場合は両方が通る可能性が残ります。同時到着が現実的に起こるなら、キー列に一意制約を持てるデータベースを使い、書き込みに失敗した側を終了させる方式が安全です。スプレッドシートは手軽ですが、その保証はありません。

判断表:どこまで作り込むか

• 重複しても削除すれば済む(社内メモなど)、推奨：キー確認だけ。「処理中」は省略可
• 重複すると顧客に見える(メール送信、請求)、推奨：二段階記録+人が見る「処理中」放置の一覧
• 金額が動く(決済、返金)、推奨：一意制約のあるDB+外部サービス側の冪等性の仕組みも確認

ツール別:処理済み記録の置き場所

ここは、公式ページで確認できた範囲だけを書きます。

n8n:Remove Duplicatesノードに「現在の入力内の重複を除く」「過去の実行で処理済みの項目を除く」などのモードがあります。履歴は既定で10,000件まで保持され、ノード単位か、ワークフロー単位(複数ノードで共有)かを選べます。履歴を消す操作もあります(Remove Duplicates node)。件数が上限を超える規模の運用では、履歴の外側にもDBなどの記録を持つかを検討してください。また、このノードは「重複を除く」ための機能で、前述の「処理中→完了」の状態管理までは担いません。状態を持たせたいなら、別途表やDBを使う設計になります。

Make:Data storeにレコードを「追加または置換」「存在確認」「取得」「検索」するモジュールがあります(Data storeモジュール一覧)。たとえば、キーをレコードのキーにして存在確認し、存在しない場合だけ進める構成が考えられます。「追加/置換」は既存を置き換える動作です。存在確認と追加の間に同じキーの処理が並行して走る可能性もあるため、この構成だけで同時実行時の重複を防げるとは限りません。

Zapier:公式ヘルプでは、静的な値の見直し、トリガー側の絞り込み、フィルターやパス、対応アプリでの「検索して、なければ作成」型のアクションが対策として挙がっています(前掲ヘルプ)。管理表を自作する場合は、ZapierのTablesや外部のスプレッドシートに、キーを検索するステップとフィルターを組み合わせる形になります。具体的な上限やプランごとの違いは、使うアプリとプランで確認してください。

どのツールでも、「検索して、なければ作成」を使えるアクションはそちらを優先すると、自作の管理表より手数が減ります。

AIに任せる範囲と、人が確認すること

AIは、自分の自動化の流れから重複パターンを洗い出し、管理表の列やキー案を出す作業に向いています。一方で、キーが本当に不変か、同時到着が起こるかは、送信元の仕様を知る人でないと判断できません。

そのまま使える依頼文の例です(【】を自分の内容に置き換えます)。

自動化の二重実行を防ぐ設計を考えてください。

【流れ】トリガー:【例:フォーム送信】→ 処理:【例:顧客台帳に追加し、確認メールを送る】
【届くデータの項目】【例:申込ID、メールアドレス、申込日時(実データは入れず項目名のみ)】
【使うツール】【n8n / Zapier / Make】
【重複したときの影響】【例:確認メールが2通届く】

次を表で出してください。
1. 起こりうる重複パターンと、この流れでの可能性(高/中/低)
2. 一意キーの候補と、変わってしまうリスク
3. 処理済み管理表の列案(status は 処理中/完了/失敗)
4. 分岐の条件(存在しない/完了/処理中/失敗のとき)
5. 私が人として確認すべき点

渡す情報は項目名と流れの説明までにして、顧客の氏名やメールアドレスなどの実データ、APIキーは入れないでください。仮のIDに置き換えれば十分です。

AIの回答を受け取ったら、次の3点を人が確認します。

• キー候補が、再送や再実行でも同じ値になるか(送信元の仕様、または実際の再送ログで見る)
• 「処理中」のまま止まったレコードをどう扱うか(誰がいつ見るか)
• 本番の前に、同じテストデータを2回流し、2回目が弾かれることを確認したか

3つ目は、必ず自分の環境で試してください。この記事の例は実行して検証したものではありません。

起きたあとの確認手順

すでに重複が出ているなら、先に原因の切り分けです。実行履歴で、重複したレコードに共通のID(注文IDやメールアドレスなど)を検索し、同じ出来事で複数の実行が走っているのか(表の1・7)、同じ実行内で2回作られているのか(表の2)、別のワークフローが動いているのか(表の3・4)を見ます。Zapierのヘルプも、実行履歴で重複しているIDを検索する診断を勧めています。切り分けができたら、該当パターンの対処をして、管理表を後付けします。