n8nのIF・Switch・Merge・Loopを理解する｜分岐・合流・反復の基本

n8nでは、データの内容によって処理先を変える、分かれたデータをまとめる、件数を区切って繰り返すといったflow logicを構成できます。

入力
→ 条件で分岐
→ branchごとに処理
→ 必要なら合流
→ 次の処理

IF、Switch、Merge、Loop Over Itemsを、分岐・合流・反復という制御構造として整理します。

今日の到達点

• IFとSwitchの使い分け
• 条件に一致したitemがどのoutputへ進むか
• MergeのAppendとCombineの違い
• n8nが複数itemsを通常どのように処理するか
• Loop Over Itemsが必要な場面と不要な場面

IFは2方向の条件分岐

IF nodeは、比較条件を評価し、各itemをtrueまたはfalseのoutputへ送ります。

たとえば、入力に次の3 itemsがあるとします。

[
  {
    "name": "Pump A",
    "pressure_mpa": 10
  },
  {
    "name": "Valve B",
    "pressure_mpa": 14
  },
  {
    "name": "Cylinder C",
    "pressure_mpa": 7
  }
]

条件を次のように設定します。

pressure_mpa is greater than or equal to 10

結果は2つのbranchへ分かれます。

true  → Pump A、Valve B
false → Cylinder C

IF nodeは、入力された各itemを条件で振り分けます。

IFでは、複数条件をすべて満たすAND、いずれかを満たすORも設定できます。値だけでなく比較する型を確認し、文字列の"10"と数値の10を混同しないことが重要です。

Switchは3方向以上の分岐に向く

Switch nodeはIFに似ていますが、複数のoutput routeを持てます。

たとえば圧力を3段階へ分類する場合、IFを重ねるよりSwitchの方が構造を読みやすくできます。

低圧 → pressure_mpa < 8
標準 → pressure_mpa >= 8 かつ < 12
高圧 → pressure_mpa >= 12

Switchには、条件を画面上で作るRulesモードと、出力indexを式で返すExpressionモードがあります。Rulesモードではruleごとの比較条件を設定でき、output名も変更できます。

IFとSwitchの使い分け

単純な真偽判定はIFの方が意図を読み取りやすくなります。

Rulesモードでは、一致した最初のoutputだけへ送るか、すべての一致outputへ送るかを設定できます。どのruleにも一致しないitemを扱うFallback Outputもあります。

条件範囲が重なると1 itemが複数branchへ進む場合があるため、outputごとの件数を確認します。

IFやSwitchで分かれた経路がbranchです。true側でroute = review、false側でroute = normalのようにfieldを追加すれば、合流後も通過した経路を追跡できます。

Mergeは複数streamのデータをまとめる

Merge nodeは、複数の入力streamから届くデータをまとめるnodeです。

線を見た目上1本に戻すだけではなく、どのようにデータを結合するかをModeで決めます。

Append

Appendは、各inputのitemsを順番に並べて出力します。

Input 1: A、B
Input 2: C
Output : A、B、C

IFで2branchへ振り分け、branchごとに処理したitemsを1本のstreamへ戻す練習にはAppendが分かりやすいでしょう。

ただし、分岐前の並び順へ完全に戻るとは限りません。後続処理が順序へ依存する場合は、IDや連番fieldを持たせ、必要に応じて明示的に並べ替えます。

Combine

Combineは、複数inputにあるfieldを一つのitemへ組み合わせるために使います。

結合基準には、共通IDなどを照合するMatching Fields、同じ位置を結ぶPosition、全組み合わせを作るAll Possible Combinationsがあります。

Appendはitemsを縦に並べ、Combineは対応するitemsのfieldを横に結ぶ操作と考えると区別しやすくなります。

Mergeで注意すること

Mergeは、接続された複数streamのデータが利用可能になってから結合します。どのbranchから何items到達したかを確認してください。

3つ以上のinputやSQL Query modeはn8n 1.49.0以降の機能であり、古い環境では表示が異なります。

branchの実行順へ依存せず、executionのINPUTとOUTPUTから結果を確認します。

n8nは通常、自動的に複数itemsを処理する

多くのn8n nodeでは、明示的なloopを作らなくても複数itemsを処理できます。

3 input items
→ nodeが各itemを処理
→ 3 output items

たとえば3 itemsをEdit Fieldsへ渡すと、通常は各itemへ同じ設定が適用されます。通知nodeへ渡せば、操作やnodeの仕様に応じてitemごとの処理が発生します。

したがって、「複数itemsがあるからLoop Over Itemsを置く」という判断は早すぎます。まず対象nodeが通常の複数item処理へ対応しているか確認します。

Loop Over Itemsが必要な場面

Loop Over Itemsは、入力itemsを指定したBatch Sizeに分け、loop outputから順次送り出します。

すべての処理が終わると、処理済みデータがdone outputから出力されます。

Batch Sizeを1にすれば、1 itemずつ処理できます。

複数items
→ Loop Over Items
→ 1件または一定件数ずつ処理
→ Loop Over Itemsへ戻る
→ 全件終了後にdoneへ進む

必要になる代表例は次のとおりです。

• 外部APIのrate limitを避けるため、件数を区切りたい
• 1件処理するたびにWaitを挟みたい
• 入力itemsを自動反復しないnodeやoperationを使う
• APIのpaginationで次のpageを繰り返し取得する
• 全件処理後にだけ実行したい後続処理がある

Edit Fieldsや通常の条件分岐など、node自身が複数itemsを処理できるだけならLoop Over Itemsは不要です。

小さな分岐・合流Workflow

実習では、次の構成が理解しやすいでしょう。

Manual Trigger
→ Code（3 itemsを作る）
→ IF（10MPa以上か判定）
   ├→ true  → Edit Fields「route = review」─┐
   └→ false → Edit Fields「route = normal」─┤
                                               → Merge（Append）

Code nodeでは練習用の3 itemsを作ります。

return [
  { json: { id: 1, name: 'Pump A', pressure_mpa: 10 } },
  { json: { id: 2, name: 'Valve B', pressure_mpa: 14 } },
  { json: { id: 3, name: 'Cylinder C', pressure_mpa: 7 } },
];

IFの条件には、数値型として次を設定します。

{{ $json.pressure_mpa }} is greater than or equal to 10

期待する件数は次のとおりです。

true branch : 2 items
false branch: 1 item
Merge後     : 3 items

次にIFをSwitchへ置き換え、低圧・標準・高圧の3branchを試します。条件の境界値が重複または欠落していないかも確認してください。

Loop Over Itemsは別のコピーでCode nodeの直後へ置き、Batch Sizeを1にします。Edit Fieldsなどを1つ通してLoop Over Itemsへ戻し、全件終了後のデータをdone outputで確認します。

よくある失敗

fieldの型が違う

数値比較のつもりで文字列を比較すると、期待と異なる結果になることがあります。INPUTのJSON表示で引用符の有無を確認します。

条件の境界が抜ける

10より大きいと10より小さいだけでは、ちょうど10のitemがどちらにも一致しません。以上、以下を含めて境界値を決めます。

MergeのModeを確認していない

Append、Matching Fields、Positionでは出力の意味が異なります。「合流させたい」だけでModeを決めず、期待する出力JSONから逆算します。

不要なLoopを作る

自動的に複数itemsを処理できるnodeの周囲にLoop Over Itemsを置くと、Workflowが複雑になります。

Loopの理由を「1件ずつに制限する」「待機する」「paginationする」のように説明できる状態にします。

実務での考え方

flow logicを増やすほど、Workflowはプログラムに近い構造になります。

分岐を設計するときは、条件式だけでなく次を決めておきます。

• 一致しないitemを破棄するのか、別routeへ送るのか
• 各branchでitemの形を変えるのか
• 合流後に必要な共通fieldは何か
• 期待するitem数は何件か
• 同じitemが複数branchへ進んでもよいか
• 順序へ依存していないか

branchごとに異なるデータ構造を作ると、Merge後の処理が不安定になります。routeやstatusなどの共通fieldを用意すると、どの経路を通ったitemか追跡しやすくなります。

巨大な条件分岐になった場合は、責務単位でSub-workflowへ分割することも検討します。

今日の実習で確認すること

• 3件以上のitemsをIFでtrue／falseへ分ける
• 各branchのitem数とOUTPUTを確認する
• IFをSwitchへ置き換えて3方向へ分類する
• SwitchのFallbackと複数一致設定を確認する
• MergeのAppendでbranchを再合流する
• Merge前後の合計item数を比較する
• Loop Over Itemsが必要な例と不要な例を1つずつ説明する

実習後は、入力件数、各branchの件数、Merge後の件数、Batch Size、Loopが必要だった理由、実際のUI差分を記録します。

まとめ

IFとSwitchはデータを条件で分け、Mergeは複数のデータstreamを目的に応じた方法でまとめます。

Loop Over Itemsは、通常の複数item処理では足りず、batch化、待機、paginationなど明示的な反復制御が必要な場合に使います。

IF／Switchで分ける
→ branchごとに処理する
→ Mergeでまとめる
→ 必要な場合だけLoopを制御する

大切なのは線の形ではなく、各nodeへ何itemsが入り、どの条件で進み、最終的に何itemsが出たかを確認することです。

参考資料

• n8n公式：Flow logic
• n8n公式：If node
• n8n公式：Switch node
• n8n公式：Merge node
• n8n公式：Loop
• n8n公式：Loop Over Items