AIものさし

Zapierの再実行でレコードが重複するとき、Run履歴とアクションの状態を切り分ける

ZapierのActionがタイムアウトしたあと、宛先にレコードが作られたか分からないまま同じRunを再実行すると、同じデータが二重に登録されることがあります。タイムアウトは「処理が行われなかった」という意味ではありません。

AIものさし編集部

目次

まず結論：再実行ボタンを押す前に宛先を照合する

ZapierのActionがタイムアウトしたあと、宛先にレコードが作られたか分からないまま同じRunを再実行すると、同じデータが二重に登録されることがあります。タイムアウトは「処理が行われなかった」という意味ではありません。Zapier側が応答を受け取れなかった一方で、接続先アプリでは書き込みが完了していた可能性があります。再実行前にZap Historyで実行Runと失敗Stepを特定し、宛先アプリのレコードを一意なIDや業務キーで検索してください。

調査では、①トリガーが同じ情報を複数回渡した、②同じトリガーを複数のZapが処理した、③一つのRunのActionが再試行された、④接続先が同じCreate要求を重複登録できる、を分けます。Polling triggerのIDによるdeduplicationは、そのZap内で既に見たトリガー項目を再度起動しないための仕組みです。後段Actionの作成を一意にする保証ではありません。Actionの重複時の挙動は接続先アプリによって異なるため、全アプリで自動的に重複排除されると考えないでください。

まず重複したレコードのキーを決める

調査の前に、同じものと見なすべきレコードを定義します。宛先アプリに固有IDがあるならそれを使い、まだIDがないデータでは、業務上変わらない識別情報の組み合わせを使います。たとえば注文番号、外部システムのrecord ID、顧客IDと申請番号などです。氏名や件名だけでは同じ値が正当に複数回現れるため、重複判定のキーとして弱い場合があります。

表は横にスクロールできます

確認する値何を特定するか注意点
宛先のrecord ID作成済みレコードの実体Createが成功したかを判別する有力な手掛かり
外部ID・注文番号元データとの対応宛先側で検索可能か確認する
Zap Run ID・開始時刻どの実行が書き込んだか同一データを処理した別Runも探す
Trigger item ID入力イベントの同一性Polling triggerのdedupとActionの重複は別問題
Action step・結果書き込みを試みた場所timeout、error、successを区別する

記録表は「候補キー」「元データID」「Zap名」「Run ID」「Step」「宛先レコードID」「宛先の現在状態」を並べます。個人情報は必要最小限にし、調査用シートに不要な本文や認証情報をコピーしないでください。

Zap Historyで同じRunの状態を追う

Zap Historyを開き、発生時刻、Zap名、Triggerの識別情報、または重複したrecord IDを手掛かりに該当Runを探します。Runの全体ステータスだけで判断せず、各Stepの詳細を確認します。Triggerが一度だけ取得され、同じRunの途中Actionだけが失敗したのか、同じTrigger itemから複数Runが始まったのかで原因と次の操作が異なるためです。

表は横にスクロールできます

観測されたパターン次に確認すること再実行前の判断
同じRunのCreate Actionがtimeout宛先を外部IDで検索し、レコードが既にあるか確認既に作成済みなら同じCreateを再実行しない
同じTrigger項目から別Runが複数ある別のZap、複数Trigger、loop、再処理履歴を確認入力重複の原因を止めるまで再実行を保留
TriggerのIDは異なるが業務キーが同じ元システムがイベントを重複発行していないか確認IDだけで同一性を判断しない
Actionが明示的なエラーで停止error message、対象field、宛先の制約を確認原因を直してから、失敗Stepの再実行を検討
Run全体は成功だが宛先が重複複数Zap、Create後の別Action、宛先側の連携を確認成功表示だけでは重複原因を決められない

Zapierの公式案内も、重複した値に含まれる一意識別子で該当Runを探し、複数のRun詳細からどの段階でデータを受け渡したか確認する方法を示しています。TimeoutのあとActionを再実行して重複する可能性にも注意を促しています。従って、まず「Runが失敗したか」ではなく「宛先への副作用が既に起きたか」を確かめます。

Triggerの重複とActionの重複を分ける

Polling triggerでは、Zapierは取得した項目のunique IDを以前受け取ったIDと比較して、既知の項目なら通常は同じZapを再起動しないと説明しています。これはTriggerのdeduplicationです。同じTriggerを使うZapが複数あれば、各Zapがそれぞれ起動することがあり、deduplicationはZap間の排他制御ではありません。Instant triggerはアプリから新しいデータを受信する方式で、公式説明上Polling triggerと同じdeduplicationを使いません。

Actionで同じレコードを作るかどうかは、Action先アプリの仕様に依存します。アプリが重複を許せば新規レコードを追加し、重複を許さなければエラーを返す場合があります。既存データを更新する、または重複を無視する接続先もあり得ます。Zapier全体に共通するCreateの一意制約があると想定せず、対象アプリのAction説明と実際のRun結果を確認してください。

同じトリガーを複数Zapで利用している場合、Zapごとの重複排除が行われても、複数のZapが同じ元データを処理する設計になっていないか確認します。一つのZapが宛先へ書き、その書き込み自体が同じZapまたは別ZapのTrigger条件を満たすloopもあります。データの流れを「元データ→Trigger→Filter/Path→Action→宛先の後続Trigger」まで図にすると、同じ値が再び入る経路を見つけやすくなります。

Timeoutでは「送信済みか不明」を扱う

ネットワーク応答が途切れた場合、呼び出し側は接続先の処理完了を判定できないことがあります。Zap Historyにtimeoutが記録されていても、接続先が要求を受け取らなかったとは限りません。最初のCreateが成功しているのに、再実行が2回目のCreateを送ると二重登録になります。反対に、失敗Stepの再実行を避ければ必要な処理が欠けることもあります。

安全に決めるには、宛先で一意キー検索を行い、①対象レコードがある、②ない、③検索できず分からない、の三つに分けます。ある場合は、内容が今回の元データと一致するかを確認し、追加操作が本当に必要か判断します。ない場合は、Runの入力とAction payloadを比較してから再実行します。検索できず分からない場合は、作成系Actionを繰り返さず、接続先の監査ログ、担当者確認、または一時的な照合手順で副作用を確かめます。

ZapierのReplayでは、Zap Historyから失敗したAction stepを再実行できるケースがあります。再実行は失敗したstepに対して行われ、前に成功したstepは再度実行しない挙動が公式説明されています。一方、Zap EditorからRun全体を再生する操作はTriggerから全stepを再度実行し、別の新規Runとして履歴に残ります。どのReplay操作を選ぶかで再処理範囲が違うため、ボタンを押す前に対象が「failed step replay」か「entire run replay」か確認してください。いずれも再実行による副作用が自動で取り消されるわけではありません。

再実行を安全にする設計

重複を完全に防ぐには、可能なら宛先側の業務キーに一意制約を設定し、同じキーのCreate要求を拒否または既存レコードへ結び付ける方法を検討します。Zapierの接続先にFind or Create / Find Record等のActionがあるなら、業務キーで検索し、見つかったときは更新・継続、見つからないときだけ作成する構成が候補です。ただし、FindとCreateの間に別処理が入ると競合が残る場合があり、Action名が同じでもアプリごとの挙動は同じとは限りません。テスト環境で同じ入力を二回処理し、二つ目で新しいレコードが増えないことを確認します。

宛先側に一意制約やFind-or-createがない場合は、重複を検知する代替手順を用意します。例として、Zapの前に元イベントを記録する台帳を置く、処理済みIDを保存する、または宛先の検索結果に基づき手動確認へ分岐する方法があります。どの方式でも、キーが欠落した場合、値の表記ゆれ、同じ申請の正当な更新をどう区別するかを決めてください。重複防止を追加した結果、正当な更新まで捨てないよう、同じIDの再送と同じ内容の別イベントを区別します。

一意キーを利用できない場合は、「絶対に一度だけ実行される」と保証する表現を避けます。代わりに、処理済み一覧との照合、候補の人手確認、再実行前の宛先確認を手順化します。冪等性（同じ操作を複数回行っても最終結果が重複しない性質）は、Zapierのボタンだけで自動的に得られるものではなく、接続先の制約やフロー設計で実現できるかを確認する必要があります。

原因別の修正判断

表は横にスクロールできます

原因修正の方向確認する副作用
Triggerの範囲が広いtrigger条件を絞る、Filterを追加必要な正規データを除外しないか
同じ元データを複数Zapが処理Zap間で役割を分ける、共有の処理済みキーを設ける片方だけ止めて必要な後続処理が欠けないか
LoopTriggerとActionが同じデータを相互に再発火させないよう条件を設計正当な更新が止まらないか
timeout後の重複再実行前の宛先照合、業務キー、Find-or-create等2回目の更新が初回結果を上書きしないか
Action先の重複許容接続先の一意制約または検索ステップを検討検索条件が一意か、同時実行で競合しないか
静的な値を送っているTriggerの動的フィールドへマッピングテスト値が本番項目へ残っていないか

修正後は一つのテスト用record IDで、初回、同一入力の再処理、timeout相当の失敗、処理成功の各ケースを確認します。テスト結果にはZap Run ID、Step、宛先ID、再処理後の件数を記録します。実データで再現する前に、接続先のsandboxや機密でないテストデータを使えるか確認してください。実行ログに個人情報や秘密値を残さないことも重要です。

再実行前チェックリスト

  • 重複した宛先レコードを一意な業務キーで特定した

  • 問題のZapとRun ID、失敗Stepを記録した

  • 同じTrigger項目が別Runにも現れるか確認した

  • 同じTriggerを利用する別Zapがないか確認した

  • Timeoutと明示的なAction errorを分けた

  • 宛先側でCreate済みか、更新済みかを確認した

  • Replay対象が失敗Stepのみか、Run全体か確認した

  • 同じ入力を再処理した場合のAction先の挙動を確認した

  • Find-or-createや一意制約が利用できるか確認した

  • 実データを使う前に安全なテスト方法を選んだ

  • Replay後に重複件数と宛先状態を再確認する担当を決めた

次に行うこと

まず宛先で重複したrecordの一意キーを決め、Zap Historyで同じキーを含むRunをすべて抽出します。次に各RunのTrigger、Actionの開始・終了状態、実行時刻を並べ、宛先側で作成済みのrecord IDと照合してください。ActionがtimeoutしたRunでは、作成済みか不明な間はCreateを再実行しないでください。Run全体を再生する必要があるのか、失敗ActionだけのReplayで足りるのかを選び、再処理後に宛先で一件だけ存在することを確認します。

個別Zapの設定や接続先アプリ、Run履歴はこのガイドでは確認していません。したがって、特定の重複原因を決めつけず、上の観測表に沿って分岐してください。公式Helpの説明と異なるアプリ固有の挙動が疑われるときは、対象アプリのAction仕様も確認してから変更します。

Sources