n8nでエラー処理を設計するときの基本

n8nのワークフローを本番運用するなら、「成功する流れ」だけでなく「失敗したときにどう気づき、どこまで再実行するか」を先に決めておく必要があります。

n8nではfailed executionをExecutionsから確認でき、ワークフロー SettingsにError ワークフローを設定すると、失敗時に別ワークフローを起動できます。Error ワークフローはError Triggerから始めます。

先に結論：エラーは「原因・通知・再実行」を分ける

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

失敗パターン	まず確認	次の処理
認証切れ	Credential / Error message	修正して再実行
Rate limit	API側の制限	待機・Retry方針
入力不足	必須項目	Stop / 要確認
AI出力異常	空・形式不正	Validation / Human review
外部サービス停止	Downstream状態	通知・後で再処理

Error Workflowは「全部を自動復旧する仕組み」ではなく、まず失敗を見逃さず、二重処理せずに復旧へつなぐために使います。

まず原因を切り分ける

まず失敗パターンを分ける

認証切れ、API rate limit、必須項目不足、外部サービス停止、AI レスポンス異常など、想定できる失敗を整理します。

Executionsで原因を確認できる状態にする

n8nではfailed executionをExecutionsから確認できます。どのノードで何が起きたかを追えるように、重要データを無理に消さず運用します。

復旧ルートを作る

Error Workflowを作る

別ワークフローを作り、先頭へError Triggerを置きます。元ワークフローのSettingsでそのError ワークフローを指定すると、execution failure時に通知や記録処理へ回せます。

Slackやメールへ通知する

Error ワークフローからSlack、メールなどへ通知します。通知に含める項目を決めます。execution ID/URLや失敗ノード名は常に存在するとは限りません。テスト実行で利用可能な値を確かめ、元のworkflowと実行を確認できる情報だけを通知します。エラー概要・確認方法を含め、個人情報・token・本文全体は不用意に転記しません。

業務上の異常も明示的にfailさせる

API自体は成功していても「在庫が0」「AI分類結果が不正」など業務上失敗と扱いたい条件があります。Stop And Error ノードを使うと、指定条件でexecutionを意図的にfailさせ、Error ワークフローへ情報を渡せます。

再発を防ぐ

Continue On Errorを乱用しない

エラーを無視して後続処理へ進めると、壊れたデータを別SaaSへ書き込む可能性があります。失敗しても続けてよいノードと、そこで止めるノードを分けます。

再実行時の重複を考える

メール送信、決済、row追加などは再実行で二重処理になる可能性があります。ID、ステータス、処理済みflagなどを使い、同じeventを二重実行しない設計を考えます。

Error処理自体も簡潔にする

Error ワークフローが複雑すぎると、障害時にさらに失敗箇所が増えます。まず通知・記録・確認導線を優先し、復旧処理は影響範囲に応じて分けます。

AIものさしの判断

n8nのエラー handlingは、「失敗しないワークフロー」を目指すより、「失敗しても気づけて、原因を追えて、安全に再開できるワークフロー」を作る考え方が重要です。

detect→fail clearly→エラー ワークフロー→notify→inspect→safe retryという流れにすると、本番運用へ移しやすくなります。

AIものさしでは、エラー messageが表示されたことではなく、担当者が異常を把握し、重複や誤処理を避けながら復旧できる状態をこのワークフローの完了条件にします。

障害時に人が判断できるエラー経路を作る

エラー処理の目的は、失敗を隠してworkflowを緑色に見せることではありません。失敗を検知し、担当者が「入力を直す」「認証を直す」「安全に再実行する」「再実行せず手作業へ切り替える」を選べる情報をそろえることです。n8nではWorkflow SettingsでError Workflowを指定し、Error Triggerから開始する別workflowへ失敗を渡せます。通知が1通届くことだけでなく、通知を見た人が元のexecutionへ戻れるかを確認します。

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

原因	同じ入力の即時retry	確認先	復旧前の安全確認
Credential期限切れ・権限不足	しない	Credential、外部サービスの権限	認証修正後、影響の小さい入力で再実行
Rate limit・一時的な接続不安定	上限付きで検討	providerの応答、Execution	待機・回数上限・重複Action防止
必須入力欠落・形式違い	しない	Triggerのinput、validation分岐	元データを修正してから再投入
AI結果が空・許可外の値	自動Actionはしない	AIノード出力、判定条件	人が結果を確認し、分類・promptを見直す
下流の登録成功後に応答だけ失敗	すぐ再送しない	下流の登録記録とexecution	既に登録済みかを照合して重複を防ぐ

この表は一般的な切り分け順です。各サービスのエラーコードや再試行保証を前提にせず、n8n executionと下流サービスの処理結果を合わせて判断してください。特に「応答が返らなかった」ことは「Actionが実行されなかった」証拠ではありません。

Error Workflowの作り方

1. 通知・記録用の別Workflowを作り、先頭にError Triggerを置きます。

2. 元WorkflowのSettingsからそのError Workflowを指定します。どのWorkflowにも設定できるわけではなく、Error Workflow側はError Triggerで開始する必要があります。

3. 通知に含める項目を決めます。少なくとも元Workflow名、失敗ノードやエラー概要、確認方法、実行を調べる入口が分かるようにし、個人情報・token・本文全体を不用意にメールやチャットへ転記しません。

4. 通知先への送信自体が失敗した場合の代替を決めます。通知workflowの障害を同じ通知workflowで無限に通知しようとせず、Executionsを確認する手段や監視先を用意します。

5. 意図的な失敗で経路を試します。n8nのStop And Errorノードは、指定条件でexecutionをfailさせ、error handlingへ渡す用途に使えます。試験用データでError Workflow起動、通知、元executionへの参照を順に確認します。

失敗時に実行データがどこまで閲覧できるかは、保存設定・権限・エラーの場所で異なります。n8n公式Docsは、error workflowへ渡る情報の内容が失敗箇所により異なること、保存済み実行データが必要な情報があることを案内しています。通知テンプレートに特定フィールドが必ず存在すると決めつけず、実際のテストexecutionで値の有無を確認してください。

Retryと二重処理を分離する

「失敗したら全部retry」は危険です。通知・請求・メール送信・CRM登録などのActionは、リクエストが成功した後で応答だけ失われることがあります。このとき元execution全体を再実行すると、処理が二重になる可能性があります。再実行する前に、対象レコードのID、処理済み状態、外部側の結果を照合します。可能なら送信元event IDを業務データと一緒に保存し、同じIDが再到着しても同じActionを重ねないようにします。

Continue On Errorは「失敗をなかったことにする」設定ではありません。後続が独立しており、失敗したノードの出力を使わずに続けられる場合に限定し、影響のある処理ではvalidation branchで停止する方が明確です。未処理データを後続ノードへ流すと、不完全な値のまま別サービスを更新することがあります。

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

状況	推奨する経路
入力が不正	停止して入力元と理由を記録。自動retryしない
一時障害で再試行可能	上限付き待機・retry。超過後はError Workflowへ
取り消せないActionの直前	承認または重複確認を挟む
業務条件を満たさない	Stop And Errorなどで明示的に失敗として扱う
Error Workflowの通知失敗	元executionを別の監視方法で確認できるようにする

復旧手順を短いRunbookにする

障害対応者が初めに行うことを固定します。①通知のexecution IDと時刻を確認、②n8n Executionsで失敗ノード・入力・出力を確認、③下流サービスにActionが反映済みかを照合、④認証・データ・一時障害を分類、⑤二重処理の危険がないと確かめてから部分または全体を再実行、⑥結果を記録して通知を閉じる、の順です。保存済み実行データがない場合は、ログに機密情報を増やして解決しようとせず、必要な診断情報だけを安全に記録する設計を見直します。

公開前には、Error Triggerを使う別Workflowが正しく割り当てられているか、Error Workflow自身が失敗した時の監視先は何か、通知に秘密情報が含まれないか、retryしても下流Actionが重複しないかを確認します。エラー処理の完了条件は、障害が起きないことではなく、担当者が原因を追い、データを壊さずに復旧できることです。

更新確認日：2026-10-10

追加確認：n8n公式「Handle errors gracefully」https://docs.n8n.io/build/flow-logic/handle-errors-gracefully（新しいタブで開く）

追加確認：n8n公式「Executions」https://docs.n8n.io/build/understand-workflows/understand-executions/view-all-executions（新しいタブで開く）