n8nのIF・Switch・Filterの違いと条件分岐の作り方

対象は、n8nでノード間にデータを渡せるようになった方です。CloudまたはSelf-hostedのテスト用ワークフローを編集・手動実行できる環境を想定しています。

説明は2026年10月31日に確認したn8n公式の公開仕様に基づくもので、以下のデータと出力表は未実行の説明用作例です。利用中の本体版・ノード版による名称差は、ご自身の環境で照合してください。

IF・Switch・Filterは、残したい行き先で選ぶ

三つの違いは、条件の書き方だけでなく、判定した後のデータの扱いにあります。まず「通すデータ」と「通さないデータ」の両方に仕事が残るかを考えましょう。

両方を処理するIF、振り分けるSwitch、絞るFilter

たとえば「承認済みなら次へ、未承認なら確認待ちへ」はIF向きです。「下書き・レビュー待ち・処理可能で担当を変える」ならSwitchが合います。

一方、「承認済みだけを後続へ渡し、ほかは処理対象にしない」ならFilterで足りる設計です。後で不採用理由を記録したいのにFilterで先に除外すると、その出力から対象外のデータは拾えません。

IFの条件は、itemごとに評価されます。複数itemsのうち一致するものと一致しないものが混じれば、同じ実行でtrueとfalseの両出力にデータがあるのは自然な結果です。

SwitchをIFの上位互換、Filterを常に最短の正解と考える必要もありません。必要な行き先と、残したい記録に合うものを選びましょう。

itemの条件分岐と、配列の分割は別に考える

条件ノードへ渡す前に、判定したい単位が一つのitemになっているかを確認します。itemはノード間を流れる一件分のデータで、そのJSONの中に配列を持つことも可能です。

たとえば一つのitemにordersという配列が入り、その中に注文が10件あっても、そのままで10件のitemになったわけではありません。各注文を個別に振り分けるなら、Split Outで配列要素をitemへ展開してから条件を適用します。

すでに複数itemsがある場合、通常の処理ではn8nが各itemを扱うため、条件判定のためだけにLoop Over Itemsを追加する必要はありません。バッチ数や待機、戻り先、終了条件が必要な反復は、別の設計として扱いましょう。

IFの条件は、型と境界を決めてから設定する

IFは「何を」「どの型として」「何と比較するか」を一組にすると設定しやすくなります。今回は、数値のamountが100以上、かつBooleanのapprovedがtrueなら通す例で考えましょう。

数値・文字列・Booleanを混ぜない

JSONの100は数値、"100"は文字列です。見た目が似ていても型は異なり、trueと"true"も同じ扱いにはできません。

金額の大小はNumber、承認の真偽はBooleanとして比較します。文字列の比較で数値の大小を代用すると、意図した金額条件から外れる原因になるためです。

1. 入力側でフィールドと型を確認する

   IFの入力JSONを開き、amountが数値、approvedがBooleanとして届くかを見ます。文字列で届く契約なら、受け入れて数値化するのか、入力要確認へ回すのかを先に決めてください。

2. 金額の条件を作る

   Conditionsで対象値を{{ $json.amount }}とし、Numberのis greater than or equal toを選び、比較値を数値の100に設定します。これは「100を含む」条件です。

3. 承認条件を加えてANDでつなぐ

   Add conditionで{{ $json.approved }}を対象にし、Booleanのis trueを選びます。二つとも満たす必要があるので、条件間はANDを指定しましょう。

4. trueとfalseに役割を付ける

   true側は採用、false側は条件不成立として読み分けます。false側を確認待ちへ送る設計なら、その経路にもIDと不成立時の扱いを残してください。

ここでis greater thanを選ぶと、「100より大きい」に変わり、ちょうど100は通りません。閾値の直前・同値・直後を用意すると、選んだ演算子の違いがはっきりします。

ANDとOR、空・欠損の条件を分ける

ANDの成立にはすべての条件、ORの成立にはいずれかの条件が必要です。型がそろった次の四件で、両者を比べてみましょう。

ANDのIFなら、trueにB、falseにA・C・Dが入るのが仕様から導く期待値です。ORに変えるとtrueはA・B・Cとなり、承認されていないCも金額条件だけで通ります。

「承認済みであることが必須」なら、ここをORにしないでください。接続する処理が同じでも、条件の結び方で通る対象は変わります。

また、null、キー自体がない状態、空文字、空白だけの文字列、数値の0、Booleanのfalseは別々の入力です。「空ではない」という一条件だけで、業務上有効な数値や承認状態まで保証できるわけではありません。

数値0は有効な値として残し、100以上の条件ではfalseと判定する設計です。承認falseも未入力に置き換えず、入力された否定値として扱います。

欠損や型違いがあり得るなら、存在・型の判定を前段に分け、正常な型のデータだけを金額条件へ進めましょう。ANDの左側で存在を調べれば右側の比較も必ず安全になる、という短絡評価の保証には頼りません。

数値とBooleanだけを受け付ける今回の契約なら、前段のIFで次の式を対象値にし、Booleanのis trueで入力の妥当性を判定できます。

{{  Number.isFinite($json.amount) &&  typeof $json.approved === 'boolean'}}

これは有限の数値とBooleanかを確認するための未実行の作例です。true側だけを金額・承認の業務条件へ進め、false側は入力要確認へ分けましょう。

この式では数値0とBooleanのfalseは入力として有効になり、文字列の"100"や"true"、null、空、欠損は受け付けません。入力の妥当性と、業務条件に合うかを二段階にする点が狙いです。

Switchは、一致・複数一致・未一致の行き先を決める

Switchでは、通常の振り分けルールに加え、複数のルールに合うitemと、どれにも合わないitemの扱いを決めます。ここまで設定して初めて、入力の行き先を説明できる状態です。

Rulesで複数の処理先を設定する

状態ごとに経路を分けるなら、ModeをRulesにし、Routing Rulesへ条件を追加します。今回は文字列のstatusがdraft、review、readyのいずれかに等しい例で進めましょう。

1. 状態別のルールを三つ並べる

   対象値は{{ $json.status }}、型はString、比較はis equal toです。比較値を順にdraft、review、readyとし、Add Routing Ruleで必要な経路を増やします。

2. 出力名とルール順を記録する

   Rename Outputを有効にし、Output NameをDraft・Review・Readyとしてください。名前だけでなく、どの値をどの出力へ送るかも対応表へ残しておくことが大切です。

3. 比較オプションと未一致先を固定する

   この例ではIgnore Caseをオフ、Less Strict Type Validationをオフ、Send data to all matching outputsをオフに設定します。Fallback OutputはExtra Outputとし、未知の状態を通常経路へ混ぜずに確認できるようにしてください。

追加でREADYを入れれば、大小文字の設定も試せます。Ignore Caseがオフなら未一致、オンならreadyのルールに一致するのが期待値です。

大小文字を無視してよいかは、入力仕様で決めましょう。状態コードが大小文字を区別する仕組みなら、見た目の揺れとして一律に吸収できません。

もう一つのModeであるExpressionは、Number of Outputsで出力数を定め、Output Indexの式が数値の出力インデックスを返す方式です。単純な状態別ルールから始めるならRulesで条件と行き先を見える形にし、値の加工が必要な式は前段のデータ整形として分けると確認しやすくなります。

複数一致を最初だけにするか、すべてに送るか

Switchのルールは、必ず互いに重ならないとは限りません。例Aのデータに対し、ルール0を「amountが100以上」、ルール1を「approvedがtrue」にすると、Bは両方に一致します。

ここで判断の分かれ目になるのが、Send data to all matching outputsの設定です。FallbackはExtra Output、ルール0が先という条件で比べましょう。

オンのとき、入力は4件でも出力の延べ件数は5件になるのが仕様に沿った期待値です。Bが二つの経路へ送られるためで、一意のIDは4個のまま残ります。

オフなら最初に一致したルールだけへ送られるため、順序も処理仕様の一部です。承認ルールを先に置くと、両方に一致するBは承認側へ進むことになります。

未一致を捨てずに確認したい場合のFallback

Fallback Outputは、どのルールにも一致しないitemの行き先です。既定のNoneをそのまま使うと、未一致itemは出力されません。

今回Extra Outputを選ぶ理由は、unknownを下書き扱いにする根拠がなく、確認すべき入力として残したいためです。すべてのワークフローでこの設定だけが正解、という意味ではありません。

「入力数と全出力の延べ件数が同じなら正常」という見方にも条件があります。全一致送出オフ、Extra Outputあり、条件評価が正常終了し、Execute Onceなどで入力を制限していない場合に、一件を一つの出力へ割り当てる期待で比べてください。

Filterは、条件を満たしたitemだけを後へ通す

Filterは一致したitemだけを次のノードへ渡し、一致しないitemを出力から省きます。IFと同じ条件を設定しても、不一致をfalse側へ残す動きにはなりません。

除外したデータが必要なら、先に分岐を残す

例Aと同じ「amountが100以上 AND approvedがtrue」をFilterに設定すると、通過するのはBだけという期待値です。A・C・Dは通常出力に含まれません。

この後へ「除外した三件の理由を保存する」処理を置いても、その処理が受け取るのはBだけです。採用と不採用の両方に作業が残るなら、Filterの前でIFなどにより経路を分けます。

逆に、対象外を後続で使わないことが決まっていれば、通過側だけを持つFilterは用途に合う選択です。元データが別の場所にあることと、Filterの出力から不一致を取得できることは区別しましょう。

AND/ORと型変換の設定を確認する

Filterでも複数条件をANDまたはORでまとめられます。ただし、公式文書で一つの条件群へのANDとORの混在は不可とされている点に注意してください。

「承認済み、かつ（金額100以上または優先フラグtrue）」なら、最初のFilterで承認済みに絞り、次のFilterで金額と優先フラグをORにする段階化が一案です。承認の必須条件と、その後の選択条件が分かれるので、通る理由も追いやすくなります。

単純に「金額100以上」のFilterと「優先フラグtrue」のFilterを直列にすると、両方を通る必要があり、ORの代わりにはなりません。先に条件式を日本語で書き、少なくとも「金額だけ成立」「優先だけ成立」「どちらも不成立」で期待値を比べましょう。

Less Strict Type Validationは、選んだ演算子に合わせた型変換をn8nが試みる設定です。「wrong type」の表示を消すためだけにオンにせず、入力契約として何を受け入れるかから判断してください。

たとえば文字列の"100"を数値として受け付けるなら、元値と変換後の値を並べて確かめましょう。空文字を0に変えた結果が業務上も正しいとは限らないため、空と数値の正規化を分けて扱うことが必要です。

境界値・空・未一致を試して、分岐結果を照合する

分岐の確認では、通る例を一件試すだけでなく、通らない例と想定外の入力も用意します。件数に加えてIDを追うことが、重複と欠落が同時に起きたケースを見つける手掛かりです。

最小のテストデータで出力を確認する

まず外部への送信・投稿・DB更新をつながないテスト用フローを用意しましょう。本体版、IF・Switch・Filterのノード版、Cloud/Self-hostedの別、実行順設定を記録すると、後で差が出たときに同じ条件へ戻せます。

入力は開発用のモックを使い、実顧客の情報やAPIキーを持ち込まない構成にしてください。少数の例ならEdit FieldsでID・amount・approvedを作り、値を変えてA～Dを一件ずつ試す方法も使えます。

複数itemsが同時に来る状態も別に確認してください。入力側の単一出力ノードでJSONを編集して四件のテストデータをピン留めすると、同じ入力で条件だけを比べられます。

公式手順に沿って、入力用ノードを実行したらOUTPUTをJSON表示に切り替え、Editから編集してSaveで保存・ピン留めしましょう。画面に示されるitemの形式を保ち、A～Dが配列フィールド一つの中ではなく、四つのitemsとして出力されているかを確認します。

IF・Switch・Filterの基本比較では、SettingsのExecute OnceとAlways Output Dataをオフにそろえてください。前者は最初のitemだけを使う設定、後者は出力がないときにも空itemを返す設定であり、条件そのものとは別に結果の見え方へ影響します。

表は実行結果の報告ではなく、照合用の期待値です。実行後の記録はこの期待と分け、差があれば条件・型・設定のどこが違ったかを残してください。

次に例Dとして、正常値とは別の入力を追加します。どの型でも同じように空判定されると決めつけず、入力要確認へ回すための検出条件を利用環境で確かめましょう。

空を含むデータの処理順は「入力の妥当性を分ける→必要なら正規化→業務条件を判定」とすると整理しやすくなります。日付条件を使う場合は、入力形式・タイムゾーン・当日を含むかも同じように決めてください。

• 99・100・101を試し、境界100を含む演算か確認
• Booleanのtrue/falseと、文字列の”true”を別の入力として検査
• 未一致の行き先と、同じIDが複数ルールに合う場合の出力を確認
• 各実行について入力ID・出力ID・設定・版を残し、期待との差を記録

結果が違うときは、入力・条件・設定の順に調べる

出力が違うときは、ノードを追加する前に、同じ実行の入力と設定を順番に見直します。古い実行の表示と今回まだ動いていない枝を混ぜると、条件式を直しても原因が追えません。

1. 今回の入力IDと型を確かめる

   値が想定したフィールドにあり、amount・approved・statusの型が合うかを確認します。ピン留めが残っている場合は、今回の検証に使う固定データかどうかも照合してください。

2. 演算子と条件の結び方を見る

   100以上と100より大きい、ANDとOR、文字列の大小文字を順に比べます。条件が正常に不成立だったfalseと、型違いなどで評価に失敗したエラーは別の状態です。

3. Switchの三つの設定を確認する

   ルール順、Send data to all matching outputs、Fallback Outputを見直します。件数が増えたら同じIDが複数ルールに一致したか、減ったらNoneで未一致を除いていないかを調べましょう。

4. 共通設定とエラー処理を分けて見る

   Execute Once、Always Output Data、On Errorの設定を確かめます。エラー後に続行する設定で後続が動いても、業務条件が正しくfalseになった証拠にはなりません。

5. 一つだけ直し、同じ入力で再確認する

   テストコピーで変更点を絞り、各IDの行き先を期待表と比べます。予定外の経路・意図しない二重送出・未一致の消失・意味不明な型変換が残る間は、本番の外部処理へ進めないでください。

完了の目安は、同じ実行について「入力ID→出力経路→出力ID」を説明でき、例外入力も決めた経路へ流れることです。件数が合うだけで終わらず、条件表・版・期待との差も残しましょう。

ノード自体が失敗し続ける場合は、条件の不成立とは分けて障害原因を調べます。分岐の正常確認は、外部送信の成功や本番稼働の確認までを意味しません。

古いIFとMergeの説明を現行全体へ広げない

分けた経路を再結合する場合は、Merge側の入力と結合方法も設計する必要があります。IFの条件が正しくても、照合キーや結合時の件数まで自動で正しくなるわけではありません。

古いフローを使う場合は、本体版だけでなくワークフローの実行順設定も確認します。再結合やループへ進む前に、まずここまでの条件分岐をテストフローで説明できる状態にしておきましょう。

まとめ｜IF・Switch・Filterを選び、行き先を確かめる

不一致も別処理へ残すならIF、複数の経路へ振り分けるならSwitch、対象だけを後へ通すならFilterが合います。Switchではルール順・全一致送出・Fallbackまで決め、Filterでは除外側を後で使う前提を置かないことが大切です。

次はID付きの四件を用意し、境界値100、承認true/false、未知の状態、空や型違いの順に試しましょう。外部更新をつなぐ前に、期待した経路と実測のID・件数が一致するかを確認します。

分岐設計で先に考えておきたいのは、正常ルートから外れたデータの受け皿です。行き先が決まっていれば「消えた」「増えた」を設定とIDで説明できるため、通常処理を増やす前に例外の扱いを固める進め方が妥当だと考えます。