自動化の失敗はやり直していい?再試行してよいエラーと止めるエラー

判断の軸は「待てば変わるか」と「二重実行しても安全か」

見るポイントは2つだけです。

1. 待てば結果が変わるか。 一時的な通信エラーや混雑なら、変わる可能性があります。入力値の誤りや権限不足は、原因の修正が必要です。
2. 同じ処理をもう一度やっても安全か。 読み取りは再試行の候補です。「同じ値で上書き」は、通知などの副作用や更新競合がないことも確認します。「新規作成」「メール送信」「課金」は、重複防止の仕組みがないと危険です。

この2軸が、以下の判断表の土台です。

エラー別の判断表

次の表は編集上の整理です。ZapierのHTTPステータス解説とAPIエラーの対処説明を参考にしており、各ツールの自動動作そのものではありません。実際の文言や例外は、お使いのアプリごとに違います。

• タイムアウト、接続エラー、原因の見立て：通信の一時的な不調の可能性、判断：再試行(回数制限つき)、補足：書き込みは重複確認が条件
• 429(リクエスト過多)、原因の見立て：レート制限、判断：間隔を空けて再試行、補足：件数を絞る対策も併用
• 500・502・503、原因の見立て：相手側の障害(一時的とは限らない)、判断：再試行(回数制限つき)、補足：長引くなら人に回す
• 400・422(入力が不正)、原因の見立て：データの形式・必須項目の欠け、判断：停止→人に回す、補足：入力不備ならデータの修正が必要
• 401・403、原因の見立て：認証切れ・権限不足、判断：停止→人に回す、補足：再接続や権限の見直しが必要
• 404(対象が見つからない)、原因の見立て：ID違い、削除済み、判断：停止→人に回す、補足：設定の誤りを疑う
• 「項目が空」「想定外の形式」、原因の見立て：前工程のデータ不備、判断：停止→人に回す、補足：該当データだけ別枠へ隔離できると理想
• 再試行しても繰り返し失敗、原因の見立て：障害の継続、データや設定の問題など、判断：停止→人に回す、補足：上限到達の通知を必ず出す

迷ったときの原則は「再試行は例外的に許可するもの」と考えることです。再試行する種類を限定し、それ以外は止める。この向きで設計すると、静かに壊れ続ける事故を防げます。

3つのツールの再試行の仕組み(確認できた範囲)

以下は2026年10月30日の自動校閲で、公式ヘルプとドキュメントの本文を確認した内容です。画面や上限値は更新されることがあるため、設定時に最新の表示を確認してください。

n8n

n8nではノードの設定でRetry On Failを有効にでき、待ち時間はWait Between Tries (ms)で指定します。レート制限への対処として、1秒に1リクエストなら1000(ミリ秒)にする例が公式のレート制限の説明に載っています。同ページには、Loop Over ItemsとWaitを組み合わせて処理を小分けにする方法や、HTTP Requestノードのバッチ設定(Items per Batch、Batch Interval)も紹介されています。最大試行回数(Max Tries)の設定可能な範囲は今回確認できていません。

人に回す側は、エラー処理のドキュメントにあるError Workflowが使えます。ワークフロー失敗時に、Error Triggerで始まる別のワークフローが動き、エラーメッセージや失敗したノード名などを受け取ってメールやSlackで通知できます。また、Stop And Errorノードで条件に合うデータを意図的に失敗させ、このエラー処理へ流すことも可能です。

Zapier

Zapierには失敗した実行を自動でやり直す自動リプレイ(autoreplay)があります。公式のリプレイの説明によると、確認時点では最大5回で、間隔は5分、30分、1時間、3時間、6時間と段階的に延びます。合計すると約10時間35分です。エラー通知は最後の試行が失敗したときだけ届きます。対象は「エラー」状態の実行で、保留(on hold)の実行は自動では再実行されません。Freeプランでは自動リプレイを使えません(Professional以上)。

注意したいのは手動リプレイです。Zap全体をリプレイすると新しい実行として扱われ、成功済みのステップも含めてタスク使用量に数えられます。

Make

Makeはエラー処理の概要で、RateLimitErrorとConnectionErrorは、未完了の実行(incomplete executions)を有効にしていれば自動で扱われると説明しています。一方、認証切れ(InvalidAccessTokenError)やInconsistencyErrorは個別の対応が必要です。

明示的に再試行を設計するなら、Retryエラーハンドラを使います。使う前にシナリオ設定の「Store incomplete executions」をYesにします。「Automatically complete execution」をYesにすると、指定した回数と間隔で自動再試行されます。公式の例は「3回、15分間隔」です。回数や間隔の上限値は、確認したページには記載がありませんでした。

上限回数の考え方

回数は「何回が正解」と決まるものではありません。次の順で決めます。

1. 業務の許容遅延を決める。 たとえば「問い合わせ通知は1時間以内に届けばよい」なら、再試行の合計待ち時間は1時間未満にします。
2. 待ち時間を段階的に延ばす。 短い間隔で連打すると、レート制限を悪化させかねません。Zapierの5分→30分→1時間という伸ばし方は、一つの参考になります。
3. 回数は3〜5回程度から始める。 これは編集上の目安です。回数だけでは一時的な不調かどうかは判定できません。
4. 上限に達したら必ず人に通知する。 通知なしの上限到達は、失敗を隠すのと同じです。

書き込み処理には追加の条件があります。再試行の前に、「相手側にすでにデータがあるか」を検索で確認するステップを入れます。あるいは、注文番号などの一意の値で「あれば更新、なければ作成」にします。検索や更新の仕組みがあっても、同時実行を含めて重複しないことを確認できない処理は、再試行を0回にして人に回すほうが安全です。

AIにエラー文を分類してもらう依頼文

エラーの文面を見ても分類に迷う場合は、AIに下書きを作らせられます。機密情報は必ず伏せてください。以下は説明用の例で、実行結果ではありません。

次のエラーメッセージを、「再試行してよい」「停止して人が直す」「判断できない」の
3つに分類してください。分類の理由と、再試行する場合の推奨待ち時間の考え方も添えてください。
- 処理の種類:顧客リストへの新規登録(書き込み)
- 業務で許容できる遅延:1時間
- エラー文:「422 Unprocessable Entity: email is invalid」(説明用の例)

この例なら、メールアドレスの形式不正なので「停止して人が直す」に分類されるのが自然です。ただし、AIの分類は仮説です。次の点は人が確認します。

• 分類結果を、そのツールの公式ドキュメントで裏づけたか
• 書き込み処理に重複防止があるか
• 上限回数と通知先が、実際の運用に合っているか

エラー文に氏名やメールアドレス、APIキー、社内IDが含まれる場合は、ダミーに置き換えてから貼り付けます。

設定前のチェックリスト

• [ ] 再試行を許可する種類を、一時的な通信エラー・500/502/503・429などから決めた
• [ ] 入力・認証・権限・対象の誤りは、停止して通知する設定にした
• [ ] 書き込み処理に重複防止を入れた、または再試行しない設定にした
• [ ] 再試行の合計待ち時間が、業務の許容遅延に収まる
• [ ] 上限到達時と停止時の通知先を決めた
• [ ] 手動リプレイが使用量やデータの重複に影響しないか確認した