ロジックとエラーハンドリングが重要な理由

データをAからBへ単に移動させるだけのワークフローは脆弱です。実際のビジネスプロセスでは判断が必要です。商談の金額がしきい値を超えた場合にのみ営業チームに通知する、必須フィールドが存在する場合にのみレコードを保存する、そして最も重要なのは予期せぬエラーが発生しても稼働し続けることです。分岐とエラーハンドリングがなければ、たった一つの悪いAPIレスポンスがパイプライン全体を静かに壊してしまいます。

n8nでは、ロジックとエラーハンドリングは少数のノードをLEGOブロックのように組み合わせて構築します。IFノードがフローを分岐させ、Switchノードが複数経路のルーティングを処理し、Filterノードが下流ノードに到達する前に不要なアイテムを削除します。Stop and ErrorノードとError Triggerワークフローが、失敗を捕捉して対応する手段を提供します。

IFノードによる分岐

IFノードは各アイテムに対して条件を評価し、真の結果を一つの経路に、偽の結果を別の経路に送ります。これが二択の判断における主要なツールです。

{
  "conditions": {
    "number": [
      {
        "value1": "{{ $json.amount }}",
        "operation": "larger",
        "value2": 1000
      }
    ]
  }
}

上の例では、ノードは各入力アイテムの`amount`フィールドが1000より大きいかどうかをチェックします。条件を満たすアイテムはtrue分岐に進みます。満たさないアイテムはfalse分岐に落ち、Slackアラートや低優先度キューなど、別のアクションにルーティングできます。

三つ以上の可能性がある経路には、Switchノードを使用します。これはコードのswitch文のように動作します。ルールを定義し、最初にマッチしたルールがアイテムの出力先を決定します。

アイテムをクリーンにフィルタリングする

有时二分岐は必要なく、条件に一致しないアイテムを取り除いてそのまま進みたい場合もあります。Filterノードはまさにこれを行います。2つのノードの間で動作し、条件を満たさないアイテムを静かに破棄します。

{
  "conditions": {
    "string": [
      {
        "value1": "{{ $json.status }}",
        "operation": "equals",
        "value2": "active"
      }
    ]
  }
}

下流のアクションが有効なアイテムのみを受け取るべき場合はFilterを使用してください。両方の分岐に独自の後続ロジックが必要な場合はIFを使用してください。この違いが重要です。IFノードは、明示的に停止または再ルーティングしない限り、falseのアイテムも前方へ渡すため、Filterはそれらを完全に除去します。

エラーハンドリングのパターン

n8nは3層のエラーハンドリングを提供します。1つ目は、どのワークフローが失敗しても別のワークフローを起動する内蔵のError Triggerノードです。2つ目は個々のノードにあるContinue On Fail設定で、特定のノードがエラーになってもワークフローを継続するようn8nに指示します。3つ目はStop and Errorノードで、ロジックが不可能な状態を検出したときに意図的に起動します。

// Pseudocode for a retry pattern using Continue On Fail + Wait
try {
  // call external API
} catch {
  // log failure
  // wait, then retry up to 3 times
}

一般的なパターンは次のとおりです。HTTP RequestノードにContinue On Failを有効にしてラップします。呼び出しが失敗した場合、出力をWaitノード経由で再度HTTP Requestノードへ戻します。3回ループした後、エラーハンドラーへ分岐し、通知を送信して失敗したペイロードをデータベースのdead-letterテーブルに書き込み、手動レビュー用に保管します。

実践的なヒントとよくある間違い

繰り返し起こる間違いが2つあります。1つ目は、レジリエンスを求めてすべてのノードでContinue On Failを有効にしてしまうことです。しかし、これは実際のバグを隠してしまいます。401のunauthorizedレスポンスと本物のロジックバグは、エラーを無視した下流ノードから見ると同じに見えます。選択的に行いましょう。具体的なリカバリーパスを計画しているノードにのみContinue On Failを設定してください。

2つ目は、n8nはノード内でアイテムを1つずつ処理しますが、単一の実行で複数のアイテムがノードに入る可能性があることを忘れがちな点です。IF条件は最初のアイテムだけでなく、すべてのアイテムに対して正しく機能する必要があります。空文字列、ゼロ値、nullフィールドなどのエッジケースを含む、少なくとも3つの多様な入力でテストしてください。

まとめ

n8nのロジックは魔法ではありません。意図を持って適用される少数のノードツールキットです。明示的な分岐にはIFとSwitchを、サイレントなクリーンアップにはFilterを、Continue On Fail、専用エラーワークフロー、自動復旧できない失敗のためのdead-letterデスティネーションを組み合わせた多層エラー戦略を使用しましょう。実際のビジネスデータと遭遇しても生き残るワークフローは、問題が発生することを予期し、それを優雅に処理するワークフローです。