Zapierで「Zapが止まった」「エラーになった」時の履歴の見方と再実行

最初に見る場所:実行履歴から失敗したステップまで

1. Zapierにログインし、Zap history(zapier.com/app/history)を開きます。
2. 絞り込みで、ステータス・日付・Zap名・アプリなどを指定します。検索ボックスでバージョン番号や名前から探すこともできます。(View and manage your Zap history)
3. 問題の実行をクリックして詳細ページを開きます。各ステップのData In(連携先へ送ったデータ)とData Out(連携先から受け取ったデータ)、実行時刻、使われたバージョンが確認できます。(View specific Zap run details)
4. 失敗したステップを開きます。Errored(エラー)の実行では、このステップで Troubleshoot タブからAIによる原因の説明と対処手順が表示されると公式ヘルプにあります。(How to troubleshoot errors in Zap workflows)

注意点が2つあります。履歴で確実に残るのは最大60日分で、表示は最大10,000件までです。古い失敗を調べたい場合は、早めに履歴をエクスポートしておく必要があります。また、エラーになったステップに依存する後続のステップも Errored と表示されるので、一番上(最初)の失敗ステップが原因の起点だと考えて読みます。

ステータス別:何が起きていて、どこを見るか

「止まった」と感じる状況は、実際にはステータスが違います。次の表で見る場所を決めてください。(ステータスの定義はReview run statuses in Zap workflowsに基づきます。「最初に見る場所」「次の一手」は編集上の整理です。)

• Errored、意味：ステップが失敗して実行が終了、最初に見る場所：詳細ページの最初の失敗ステップのエラー文、Troubleshootタブ、次の一手：原因を直す → 再実行の判断へ
• On hold、意味：問題が解消されるのを待っている状態(アプリ連携の切断、タスク上限、アカウント上の問題など)、最初に見る場所：保留理由の表示、Apps(連携アカウント)の接続状態、タスク使用量、次の一手：接続し直す/上限を解消してから再実行
• Safely halted、意味：検索ステップで結果なしなど、意図した形で停止、最初に見る場所：検索ステップの入力値(検索キー)と出力、次の一手：故障ではない場合が多い。検索キーが空・誤りでないか確認
• Filtered、意味：Filterの条件を満たさず停止、最初に見る場所：Filterステップに渡った値と条件、次の一手：条件が意図どおりか確認。意図どおりなら対応不要
• Handled error、意味：失敗したが、設定したエラー処理の別ルートが動いた、最初に見る場所：エラー処理側のステップの結果、次の一手：代替ルートの処理が完了しているか確認
• Scheduled、意味：Autoreplay有効で、自動再試行待ち、最初に見る場所：次の再試行を待つ(手動で重ねて実行しない)、次の一手：最終的に失敗した場合にだけ調査
• Delayed / Needs review、意味：Delayステップ待ち/人の確認・承認待ち、最初に見る場所：待機中のステップ、再開予定や確認依頼、次の一手：Delayedは予定を確認。Needs reviewは担当者が確認・承認する
• Skipped(ステップ単位)、意味：前段が止まった、または必要なマッピング値がなくて実行されなかった、最初に見る場所：直前のステップの出力、次の一手：上流の停止理由を読む

「Zapがオフになっていた」という場合は別の話です。公式ヘルプでは、直近7日間で実行の95%がエラーになるとZapが自動でオフになるとされています。TeamとEnterpriseではメール通知があり、猶予はTeamが24時間、Enterpriseが72時間という記載です。(前掲のトラブルシューティング記事)。さらに、Zapがオフのままだと再実行できないとも書かれているため、順番は「原因を直す → Zapをオンに戻す → 再実行」です。

エラーの原因を、履歴のデータから読み取る

エラー文だけで判断が難しい時は、失敗ステップの入力データを見ます。次のような観点で切り分けると速いです。これは編集上の整理で、Zapierが定めた分類ではありません。

• 入力が空・形式が違う:前のステップの出力が空だった、日付やメールアドレスの形式が想定と違う。この場合、同じデータでの再実行は同じ理由で失敗します。元データ側かマッピングを直す必要があります。ただし、元データを直しても履歴に保存されたトリガーデータは更新されません。保存済みデータに誤りがある場合は、有料プランの全体再実行でトリガーデータを編集する方法などを検討します。
• 連携アカウントや権限の問題:接続切れ、権限不足。アカウントを再接続すれば、同じデータで再実行できることが多いでしょう。
• 相手サービスの一時的な不調:タイムアウトなど。待って再実行、またはAutoreplayの対象になります。
• 宛先側の仕様の問題:シート・フォルダ・項目が削除・名称変更されていた。宛先側を戻すか、Zapを編集して公開し直します。

AIにエラー文の読み解きを任せる場合

Troubleshootタブのほかに、一般的なAIチャットに読み解きを頼む方法もあります。渡す情報と人が確認する点は次のとおりです。

渡す情報:Zapの目的を1行、ステップの並び、失敗ステップのエラー文。顧客名・メールアドレス・APIキー・本文などは、ダミーに置き換えます。

依頼文の例(説明用の例です。実際に実行した結果ではありません)

Zapierで次のZapがエラーになりました。
目的:フォーム回答をスプレッドシートに追記し、担当者にメール通知する
ステップ:1) フォームの新規回答 2) シートに行を追加 3) メール送信
失敗したのはステップ2です。エラー文:「(ここにエラー文を貼る)」
ステップ2に渡った入力(個人情報はダミーに置換済み):
 名前=テスト太郎 / 日付=2026/13/01 / 金額=(空)
質問:
1. 原因として考えられるものを可能性の高い順に3つ
2. 履歴のどの項目を見れば切り分けられるか
3. 同じデータで再実行して成功しそうか、その根拠

AIの答えは仮説です。人が履歴の入力データと照らして確かめてください。「再実行して成功しそうか」という推測を、そのまま実行の根拠にはしないでください。

再実行してよいかを決める

再実行の仕組みを押さえておきます。(Replay Zap runs、What is replay?)

• 再実行は、元の実行のトリガーデータを使います。
• Zap全体の再実行は新しい実行として履歴に記録され、成功したステップはタスク使用量に再び数えられます。
• エラーの再実行(以下、ステップ単位の再実行)は、エラーで止まったステップと、その影響で止まった後続ステップを対象にします。成功済みのステップはやり直しません。FilterとPathsの条件は再評価されません。Zap全体の再実行はトリガーから全ステップをやり直すため、成功済みのメール送信なども重複する可能性があります。
• Free プランでは、手動再実行できるのはErroredのみです。On holdなどの状態の再実行と、Zap全体の再実行には有料プラン(Professional、Team、Enterprise)が必要です。
• トリガーのアプリやイベントを変更した後は、元の実行を再実行できません。ステップ単位の再実行では、ステップの追加・削除・並べ替え、アクションのアプリやイベント変更も制限になります。
• Zap historyでの再実行の一括選択は最大5,000件までです。Zap全体の再実行は同時に最大10件までです。

確認後、ステップ単位で再実行するには、Zap historyで対象の実行にチェックを入れ、Play X → Replayを選びます。全体を再実行する場合は、Zap editorのZap runsで対象を選び、Replay X runs → Entire Zapを選びます。どちらも実行後に対象ステップと宛先の結果を確認してください。(Replay Zap runs)

再実行前の確認項目

実行の前に、次の項目を順に確認してください。

1. 原因を直したか:エラー文と入力データから原因を特定し、直した(再接続、マッピング修正、宛先の復旧など)。直していなければ同じ失敗を繰り返すだけです。
2. Zapはオンか:オフでは再実行できません。
3. 編集した場合は公開したか:Zap全体の再実行は、編集を公開してから行います。
4. 失敗より前のステップの副作用:失敗ステップより前に、メール送信・Slack投稿・課金・行追加などをしていないか。していれば、Zap全体の再実行は重複の原因になります。その場合はステップ単位の再実行を選ぶか、手動で補います。
5. すでに人が手で処理していないか:担当者が手作業で対応済みの案件を再実行しない。
6. 宛先にすでに行・レコードが入っていないか:エラーが「書き込み後の応答待ち」で起きた場合、実際には書き込めている可能性があります。宛先を確認します。
7. データの鮮度:再実行は元のトリガーデータを使います。在庫・価格・期限のように、時間が経つと意味が変わる情報ではないか。
8. 件数と範囲:複数件を一括再実行する前に、1件だけ再実行して結果を確認します(編集上の進め方です)。
9. タスク使用量:再実行でもタスクが増えます。残量に余裕があるか。
10. Autoreplayの有無:Scheduledの実行は自動再試行待ちです。ProfessionalのプランからAutoreplayを使えます。手動で再実行する前に、自動の再試行が終わるのを待つほうが重複を避けられます。

判断の目安

• 一時的な不調が解消し、失敗ステップが最初の外部書き込みだった、再実行：宛先に書き込み済みでないことを確認してから再実行
• 原因を直した。失敗より前に副作用のある処理がない、再実行：失敗ステップの宛先も未処理と確認できれば再実行可(全体の再実行でも可)
• 原因を直した。失敗より前にメール送信などが成功している、再実行：ステップ単位の再実行を検討。全体の再実行は避ける
• 原因が入力データの不備で、直していない、再実行：しない。修正後、再実行に使われる保存済みデータにも不備が残っていないか確認
• 人が手作業で処理済み、再実行：しない
• Safely halted / Filtered、再実行：通常は故障ではないので、条件や検索キーを確認してから判断

再発させないための最小限の設定

再実行を繰り返さずに済むよう、Autoreplayは一時的な障害の対策として役立ちます。Professional以上で有効にでき、失敗したら間隔を空けて最大5回まで自動で再試行します。公式ヘルプの例では、最初はトリガー発生から5分後、その後は直前の試行から30分、1時間、3時間、6時間後に再試行します。最終試行が失敗するまで、エラー通知メールは送られず、関連するZapier ManagerのZapも起動しません。(What is replay?)通知を待つ運用にする場合、この点を知っておく必要があります。

再実行には、元のトリガー発生から60日以内という制限があります。重要なZapは、定期的に履歴のErroredとOn holdを絞り込んで確認する習慣をつけてください。