n8nのエラーハンドリング完全攻略：失敗ノードの自動リトライと通知設定

「ワークフローが夜中に止まっていたけど、朝まで気づかなかった」「APIの一時的な障害でデータが欠損してしまった」

n8nで業務自動化を進めていくと、こんなトラブルに直面することがあります。ワークフローは動いている間はとても頼もしい存在ですが、エラーが起きたときの対策をしていないと、気づかないうちに処理が止まってしまうという大きなリスクがあります。

そこで今回は、n8nのエラーハンドリング機能を徹底的に掘り下げます。失敗したノードの自動リトライ設定、エラー専用ワークフローの構築、さらにSlackやメールへの即時通知まで、本番運用に耐えられる堅牢なワークフロー設計の手順を実例付きで解説します。

初心者の方でも理解できるよう、基本的な概念から丁寧に説明していきますので、ぜひ最後まで読んでください。

n8nのエラーハンドリングとは？基本概念を理解する

まず、n8nがどのようにエラーを扱うかを理解しておきましょう。

ワークフロー実行のライフサイクル

n8nのワークフローは以下のような流れで実行されます。

トリガーの発火（Webhook、Cron、手動など）
ノードの順次実行（左から右へデータが流れる）
成功 or 失敗（各ノードの結果）
ワークフロー完了 or エラー停止

デフォルト設定では、どこかのノードがエラーを返すとそこでワークフローが停止します。後続のノードは実行されず、エラーログが残るだけです。これを防ぐのがエラーハンドリングです。

n8nが提供するエラーハンドリングの3つのアプローチ

アプローチ	概要	適用シーン
ノードレベルのリトライ	特定ノードが失敗したとき自動で再試行	一時的なAPIエラー対策
エラーワークフロー	失敗時に別ワークフローを起動	通知・ロールバック処理
エラーアウトプット	エラーを別ルートで処理	条件分岐による部分的な継続

これら3つを組み合わせることで、どんな状況でも止まらない堅牢な自動化が実現できます。

ノードレベルのリトライ設定：一時的な障害を自動で乗り越える

最もシンプルで効果的なエラーハンドリングが、ノードごとのリトライ設定です。外部APIへのリクエストが一時的にタイムアウトした場合や、レートリミットに引っかかった場合などに特に有効です。

リトライの設定手順

リトライを設定したいノードを右クリック（またはノード右上の「⋮」メニューをクリック）
「Settings」 を選択
「On Error」 セクションを展開
以下の項目を設定する

【設定項目と推奨値】

On Error: Retry
Retry On Fail: ON（トグルをオン）
Max Tries: 3〜5（試行回数の上限）
Wait Between Tries: 5000ms（5秒）

設定画面のUIはn8nのバージョンによって若干異なりますが、n8n公式ドキュメントに最新の操作手順が記載されています。

JSONによる設定の確認

n8nのワークフローはJSON形式でエクスポートできます。リトライ設定が正しく反映されているか確認するには、ワークフロー編集画面右上の「...」メニューから「Download」を選んでJSONを確認します。

{
  "nodes": [
    {
      "name": "HTTP Request",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "url": "https://api.example.com/data",
        "method": "GET"
      },
      "retryOnFail": true,
      "maxTries": 3,
      "waitBetweenTries": 5000,
      "continueOnFail": false
    }
  ]
}

retryOnFail: true でリトライが有効になり、maxTries で最大試行回数、waitBetweenTries でリトライ間隔（ミリ秒）を指定します。

リトライ設定のベストプラクティス

外部APIノードには必ずリトライを設定するのが鉄則です。特に以下のノードは優先的に設定してください。

HTTP Requestノード（外部API呼び出し）
Google Sheetsノード（Googleサービスは一時的な503が多い）
OpenAI / Anthropicノード（AI APIはレートリミットが発生しやすい）
データベース接続ノード（接続タイムアウト対策）

待機時間は指数バックオフ的に長くするのが理想です。n8nのUIでは固定値しか設定できませんが、3〜5秒程度が現実的なバランスです。レートリミット対策なら60秒以上設定することもあります。

continueOnFail：エラーを無視して次のノードへ進む

状況によっては「このノードが失敗してもワークフローは続けてほしい」というケースがあります。例えば、複数のデータソースから情報を取得するとき、1つが失敗しても残りを処理したい場合です。

そんなときに使うのが continueOnFail（失敗時も続行） オプションです。

設定方法

ノードのSettingsから 「Continue On Fail」 をオンにするだけです。

{
  "name": "HTTP Request - Optional Data",
  "type": "n8n-nodes-base.httpRequest",
  "parameters": {
    "url": "https://api.secondary.com/info",
    "method": "GET"
  },
  "continueOnFail": true
}

この設定を有効にすると、ノードがエラーを返してもエラー情報をデータとして次のノードに渡し、ワークフローを継続します。後続のIFノードなどで $json.error の有無をチェックすることで、エラー時の処理を分岐させることができます。

continueOnFail使用時の注意点

このオプションは便利ですが、エラーを見落とすリスクもあります。必ず後続のIFノードや通知ノードと組み合わせて使用し、エラーが発生したことを記録・通知する仕組みを作ってください。

エラーワークフロー：失敗を検知して別ワークフローを起動する

n8nの最も強力なエラーハンドリング機能が 「Error Workflow（エラーワークフロー）」 です。メインのワークフローが失敗したとき、自動的に別のワークフローを起動してエラー処理を行うという仕組みです。

エラーワークフローの仕組み

メインワークフローがどこかでエラーになる
n8nが自動的にエラーワークフローをトリガー
エラーワークフローがエラー情報を受け取り処理する（Slack通知、ログ記録など）

これにより、メインのワークフロー自体はシンプルに保ちながら、エラー処理を独立したワークフローで管理できます。

STEP 1: エラーワークフローを作成する

まず、エラーを受け取る専用ワークフローを作成します。

1. 新規ワークフローを作成し、名前を「Error Handler」などわかりやすい名前にします。

2. トリガーノードとして「Error Trigger」を追加します。

Error Triggerノードは特殊なトリガーで、このノードから始まるワークフローが「エラーワークフロー」として機能します。このノードは以下のエラー情報を自動的に提供します。

{
  "execution": {
    "id": "実行ID",
    "url": "https://your-n8n-instance/execution/123",
    "retryOf": null,
    "error": {
      "message": "エラーメッセージ",
      "stack": "スタックトレース"
    },
    "lastNodeExecuted": "失敗したノード名",
    "mode": "実行モード"
  },
  "workflow": {
    "id": "ワークフローID",
    "name": "失敗したワークフロー名"
  }
}

3. Error TriggerノードにSlack（またはメール）通知ノードを繋げます。

STEP 2: Slackへのエラー通知を設定する

Slackノードを追加して、エラー内容を通知するメッセージを設定します。

【Slackノードの設定例】

Resource: Message
Operation: Send
Channel: #alerts（通知先チャンネル）
Text:
🚨 *ワークフローでエラーが発生しました*

*ワークフロー名:* {{ $json.workflow.name }}
*エラーノード:* {{ $json.execution.lastNodeExecuted }}
*エラー内容:* {{ $json.execution.error.message }}
*実行URL:* {{ $json.execution.url }}
*発生時刻:* {{ $now.toISO() }}

このメッセージテンプレートにより、Slackには以下のような通知が届きます。

🚨 ワークフローでエラーが発生しました

ワークフロー名: 顧客データ同期
エラーノード: HTTP Request
エラー内容: Request failed with status code 503
実行URL: https://n8n.example.com/execution/456
発生時刻: 2026-04-13T03:42:00.000Z

STEP 3: メインワークフローにエラーワークフローを紐づける

メインワークフローを開く
画面右上の 「⋮」メニュー → 「Settings」 を開く
「Error Workflow」 ドロップダウンから、先ほど作成した「Error Handler」を選択
「Save」をクリック

これだけで設定完了です。以降はメインワークフローがどこで失敗しても、自動的にエラーワークフローが起動してSlack通知が届きます。

エラーログをGoogle Sheetsに記録する

Slack通知だけでなく、エラーの履歴をGoogle Sheetsに蓄積することで、後からトレンド分析やパターン把握ができるようになります。エラーワークフローに以下のGoogle Sheetsノードを追加します。

Google Sheetsノードの設定

エラーワークフローのSlackノードの後（または並列）にGoogle Sheetsノードを追加します。

【Google Sheetsノードの設定】

Resource: Sheet Within Document
Operation: Append Row
Document ID: （対象スプレッドシートのID）
Sheet Name: ErrorLog

【追記するカラムの設定（Fieldsセクション）】

Column: timestamp
Value: {{ $now.toISO() }}

Column: workflow_name
Value: {{ $json.workflow.name }}

Column: workflow_id
Value: {{ $json.workflow.id }}

Column: error_node
Value: {{ $json.execution.lastNodeExecuted }}

Column: error_message
Value: {{ $json.execution.error.message }}

Column: execution_url
Value: {{ $json.execution.url }}

Column: status
Value: failed

Google Sheetsのヘッダー行には timestamp, workflow_name, workflow_id, error_node, error_message, execution_url, status の列を事前に作成しておいてください。

このシートを定期的に確認することで、**「毎週火曜の深夜に同じワークフローが落ちている」「特定のAPIノードでエラーが集中している」**といったパターンを発見できます。

実践例：本番運用向けエラーハンドリング設計の全体像

ここまでの内容を組み合わせた、本番運用に耐える設計を整理します。

全体構成図（テキスト表現）

【メインワークフロー】
Cron Trigger
  ↓
HTTP Request（retryOnFail: true, maxTries: 3）
  ↓（成功時）
Google Sheets - データ書き込み（retryOnFail: true, maxTries: 2）
  ↓（成功時）
Slack - 完了通知

  ↓（メインワークフローが失敗した場合）

【エラーワークフロー（Error Trigger）】
Error Trigger
  ↓
並列分岐:
  ├─ Slack - アラート通知（#alerts チャンネル）
  └─ Google Sheets - エラーログ記録

設計のポイントまとめ

① すべての外部APIノードにリトライを設定する 一時的な障害の大半はリトライで解決します。最低でも3回、待機時間は5秒以上が目安です。

② エラーワークフローを全メインワークフローに紐づける n8nでは複数のメインワークフローに同じエラーワークフローを紐づけることができます。エラーハンドラーを1つ作っておけば、すべてのワークフローで再利用できます。

③ エラー通知には「実行URL」を必ず含める Slack通知にn8nの実行URLを含めておくと、通知を受けたときにすぐに失敗した実行の詳細を確認しに行けます。問題解決までの時間が大幅に短縮されます。

④ エラーログは長期保存する Google Sheetsへの記録は最低3ヶ月分は残すようにしましょう。月次でエラー傾向を分析し、繰り返し発生するエラーは根本的に対処することが重要です。

⑤ Criticalなワークフローには二重通知を設定する 売上データや顧客情報に関わる重要なワークフローは、SlackとメールW通知にしておくと安心です。n8nのGmailノードやSendGridノードを組み合わせることで実現できます。

よくある落とし穴と対処法

落とし穴1：エラーワークフロー自体がエラーになる

エラーワークフローのSlackノードが、Slack APIの障害で失敗する…という二重エラーは意外とあります。エラーワークフロー内のノードにも continueOnFail: true を設定し、Slackが落ちていてもメール通知には届くよう、複数チャネルでの通知を設定しておきましょう。

落とし穴2：リトライ中にデータが重複する

例えば「データベースに書き込む」ノードをリトライ設定にした場合、最初の書き込みが成功したにもかかわらずn8nが失敗とみなしてリトライした結果、データが2件書き込まれてしまうケースがあります。

対策としては、書き込み前に 「既存データの存在チェック」 を行うIF分岐を入れるか、ノードのリトライを無効にしてエラーワークフローで手動対応するフローにすることを検討してください。

落とし穴3：エラー通知が多すぎてアラート疲れになる

一時的なAPIエラーでリトライ後に成功していても、すべてのエラーをSlack通知してしまうと通知が多すぎて重要なアラートを見落とすリスクがあります。

リトライで回復した場合は通知しないという設計が理想です。具体的には、エラーワークフローへの通知は「最終的に失敗した場合のみ」に限定し、途中のリトライは通知しないようにします。n8nではリトライ中の状態ではエラーワークフローは起動しないため、この問題は基本的に起きませんが、continueOnFailを多用する場合は注意が必要です。

まとめ：次のアクションは「既存ワークフローへのエラーハンドリング追加」から

今回解説した内容を振り返りましょう。

機能	用途	優先度
ノードリトライ	一時的なAPI障害への対処	★★★ 最優先
continueOnFail	部分的なエラーを無視して続行	★★ 状況に応じて
エラーワークフロー	失敗時の自動通知・ログ記録	★★★ 最優先
エラーログ（Sheets）	長期的なエラー傾向の把握	★★ 推奨

今日すぐできるアクション：

まず「Error Handler」ワークフローをSlack通知付きで1つ作成する
既存の本番ワークフローすべてにそのエラーワークフローを紐づける
重要な外部APIノードにリトライ（3回、5秒間隔）を設定する

この3ステップだけで、n8nワークフローの信頼性は大幅に向上します。エラーハンドリングは「後で設定しよう」と後回しにされがちですが、本番運用で痛い目を見る前に、ぜひ今日中に対応してください。

安定した自動化の構築が、真の業務効率化につながります。ぜひ試してみてください！

n8nのエラーハンドリング完全攻略：失敗ノードの自動リトライと通知設定

n8nのエラーハンドリング完全攻略：失敗ノードの自動リトライと通知設定

n8nのエラーハンドリングとは？基本概念を理解する

ワークフロー実行のライフサイクル

n8nが提供するエラーハンドリングの3つのアプローチ

ノードレベルのリトライ設定：一時的な障害を自動で乗り越える

リトライの設定手順

JSONによる設定の確認

リトライ設定のベストプラクティス

continueOnFail：エラーを無視して次のノードへ進む

設定方法

continueOnFail使用時の注意点

エラーワークフロー：失敗を検知して別ワークフローを起動する

エラーワークフローの仕組み

STEP 1: エラーワークフローを作成する

STEP 2: Slackへのエラー通知を設定する

STEP 3: メインワークフローにエラーワークフローを紐づける

エラーログをGoogle Sheetsに記録する

Google Sheetsノードの設定

実践例：本番運用向けエラーハンドリング設計の全体像

全体構成図（テキスト表現）

設計のポイントまとめ

よくある落とし穴と対処法

落とし穴1：エラーワークフロー自体がエラーになる

落とし穴2：リトライ中にデータが重複する

落とし穴3：エラー通知が多すぎてアラート疲れになる

まとめ：次のアクションは「既存ワークフローへのエラーハンドリング追加」から

参考資料

この記事をシェア

関連記事

n8n×LINE APIで問い合わせを自動分類・担当通知する

Make×NotionでAI週次タスクレポートを自動生成する

N8N × Claude APIで記事自動生成ワークフローを構築する