はじめに

本番環境のワークフローでは、必ず何かが失敗します。APIが500を返す、webhookのペイロードが不正な形式になる、データベース接続がタイムアウトする。問題なのは失敗が発生するかどうかではなく、ワークフローがそれを適切に処理できるか、それとも何も知らされずに見落とすかです。

n8nには2層のエラー処理があります。ノードレベルのローカルエラー処理と、失敗を捕捉して対応するための専用ワークフローを構築できるError Triggerノードです。このレッスンでは両方を解説し、実際にアラートを受け取れるようにすることに重点を置きます。

n8nのデフォルトのノード失敗処理

デフォルトでは、ノードがエラーをスローすると、n8nはそのパスの実行を停止し、実行を失敗としてマークします。実行履歴にエラーは表示されますが、プロアクティブな対応は何も起こりません。アラートもリトライもフォールバックもありません。

各ノードでは、ノードの設定パネルでこの動作を変更できます。最も useful な3つのオプションは以下のとおりです：

Stop workflow on error — デフォルトの動作。失敗したノードで実行が停止します。

Continue on error — ノードが失敗しても、n8nは実行を先に進めます。失敗したノードからの出力アイテムには、特別なフィールドにエラー情報が含まれ、それを下流で検査できます。

Retry on fail — n8nが設定可能な回数、ノードを自動的にリトライし、試行間に遅延を挟みます。レート制限の応答や不安定なネットワーク呼び出しのような一時的な失敗に有用です。

これらを設定するには、任意のノードを開き、Settingsに移動して「On Error」セクションを探してください。リトライの場合は、「Retry On Fail」をtrueに設定し、「Max Tries」と「Wait Between Tries」をミリ秒単位で指定します。

Continue on errorは、バッチのアイテムを処理する際に、1つの不良レコードで実行全体が止まることを避けたい場合に特に強力です。下流ノードは次のようなアイテムを受け取ります：

{
  "error": {
    "message": "Request failed with status code 404",
    "node": "HTTP Request",
    "stack": "..."
  }
}

その後、IFノードを使ってアイテムにエラーフィールドがあるかどうかを確認し、ロギングやアラート用の別のブランチにルーティングできます。

Error Triggerを使ったエラーワークフローの設定

ノードレベルの設定は個々のノードの失敗を処理しますが、ワークフロー全体のあらゆる失敗を捕捉するにはどうすればよいでしょうか。それがError Triggerノードの目的です。

Error Triggerはワークフローレベルで動作します。「Global Error Handler」のような名前の別のワークフローを作成し、そのトリガーをError Triggerに設定します。次に、他の任意のワークフローでSettingsを開き、「Error Workflow」フィールドにこのハンドラーワークフローを指定します。

親ワークフローが失敗すると、n8nは自動的にエラーハンドラーワークフローを起動し、何が問題だったかを示す詳細を含むペイロードを渡します。ペイロード構造は以下のとおりです：

{
  "execution": {
    "id": "1042",
    "url": "https://your-n8n.com/execution/1042",
    "retryOf": null,
    "error": {
      "message": "Could not connect to the database",
      "stack": "Error: Could not connect..."
    },
    "lastNodeExecuted": "Postgres",
    "mode": "trigger"
  },
  "workflow": {
    "id": "88",
    "name": "Daily Invoice Sync"
  }
}

これで必要な情報がすべて得られます。失敗したワークフロー、最後に実行されたノード、エラーメッセージ、実行ログへの直接リンクです。

Error Triggerワークフローを設定するには：

1. 新しいワークフローを作成し、Error Triggerノードを開始ノードとして追加します。2. 必要なアラートステップ（Slack、メール、PagerDuty、またはwebhookへのHTTP Request）を追加します。3. ワークフローを保存して公開します。4. 本番ワークフローでSettingsを開き、「Error Workflow」をこのハンドラーに設定します。

1つのグローバルエラーハンドラーを設定し、インスタンス内のすべてのワークフローで再利用することができます。

問題発生時のアラート送信

エラーワークフローで行う最も一般的なことは通知の送信です。以下は、Error Triggerのデータを使ってSlackチャンネルにメッセージを投稿する例です：

// Inside a Slack node's message field (using an expression)
`Workflow "{{ $json.workflow.name }}" failed.
Node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
View execution: {{ $json.execution.url }}`

Slack webhookを直接呼び出すHTTP Requestノードを使いたい場合は：

{
  "text": "=Workflow \"{{ $json.workflow.name }}\" failed at node {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}"
}

Send Emailノードを使ったメールアラートの場合も同様に、エラーフィールドを件名と本文にマッピングします。重要なのは、Error Triggerペイロードのすべてのフィールドが通常の式構文でアクセスできることです。

アラートステップの前にSetノードを追加してデータを再構成・拡張することもできます。例えば、ワークフロー名に基づいて重大度レベルを追加したり、タイムスタンプを追加したりできます。

よくある間違い

Error Workflowを自分自身に向ける — エラーハンドラーワークフロー自体がエラーになった場合、n8nは再帰的にそれを再度トリガーしませんが、可視性が失われます。エラーハンドラーワークフローはシンプルに、依存関係を軽く保ってください。

エラーハンドラーの公開を忘れる — Error Workflowとして設定されたワークフローはアクティブである必要があります。下書きとして保存されただけの場合、実行されません。

どこでもContinue on Errorを使う — これは本当のエラーを隠してしまう可能性があります。エラーアイテムを処理する明示的な下流ロジックがある場合に限って使用してください。対処したくないエラーを黙らせる手段として使わないでください。

エラーパスをテストしない — 故意に失敗を発生させるテストワークフロー（500を返すURLを指すHTTP Requestノード）を作成し、エラーハンドラーが実際に起動して期待したアラートを送信することを確認してください。

まとめ

ノードレベルの設定により、個々の失敗に対する動作を制御できます。stop、continue、retryのいずれかです。Error Triggerノードにより、リンクされたワークフローが失敗するたびに起動する一元的なハンドラーを構築でき、意味のあるアラートを送信するために必要な実行コンテキストが得られます。この2つを組み合わせることで、カスタムコードを必要とせずに、n8nにおける本番環境のエラー処理要件の大半をカバーできます。