n8n Switchノードの使い方：3つ以上の分岐と、黙ってデータが消える設定

処理の分かれ道が3つ以上あるときに使うのが Switchノードです。 IFノードが true / false の2つにしか分けられないのに対し、 Switch は好きな数の出口を作れます。

この記事は前半がn8n を触ったことがない人向けで、3つに振り分けるところまでを通します。 後半は基本操作ができる人向けに、既定のままだとデータが黙って消えるという 重要な挙動を扱います。

内容は n8n 2.36.8 / Switch ノード v3.4 で実際に動かして確認しています。

Switchノードは何をするものか

ルールを複数書いて、条件に合った出口にデータを振り分けるノードです。

IFノードとの違いは出口の数だけではありません。一致しなかったデータの扱いが根本的に違います。 ここが後述する最大の注意点です。

	IF	Switch
出口の数	2つ（true / false）固定	ルールの数だけ作れる
一致しなかったデータ	必ず false 側に流れる	既定では消える

実際のワークフローではこう見えます。Switchノードの右側に、 ルールの数だけ出口が縦に並びます。

実際に振り分けてみる

前回の記事で、気象庁のデータを「1地域＝1件」に展開しました。 そのデータを、天気によって 雨 / くもり / 晴れ / その他 の4つに振り分けます。

手順

1. Reshape Forecast（Code）の後ろに Switch ノードを追加する
2. Mode は Rules（既定）のまま
3. 1つ目のルールを設定する
   • 左辺に {{ $json.weather }}
   • 演算子は contains
   • 右辺に 雨
4. Add Routing Rule で「くもり」「晴れ」のルールを足す
5. Execute step を押す

条件の書き方は IFノードと同じです。左辺は式なので、 fx が付いて緑色になっているかを確認してください。

1つのデータが複数の条件に当てはまる場合

東京地方の天気は 晴れ　夜　くもり　所により　雨 のように、 3つのルールすべてに当てはまることがあります。

このときどこに振り分けられるかというと、最初に一致したルールの出口だけです。 このワークフローではルールの順が「雨 → くもり → 晴れ」なので、雨の出口に入ります。

ルールの順番が結果を変えます。 優先したい条件を上に置いてください。

実行した結果

実際に動かすと、各出口に流れた件数がキャンバス上に表示されます。

出口	件数	内訳
雨	1件	東京地方（晴れ　夜　くもり　所により　雨）
くもり	2件	伊豆諸島北部、伊豆諸島南部
晴れ	1件	小笠原諸島
その他	0件	該当なし

注目してほしいのは東京地方です。天気は 晴れ　夜　くもり　所により　雨 なので、 3つのルールすべてに当てはまります。それでも入ったのは雨の出口だけでした。

そして「その他」につないだノードは、灰色のまま実行されませんでした。 IFノードの記事で書いたのと同じで、 0件の出口の先は「0件で実行される」のではなく、実行そのものが起きません。

出口に名前を付ける

各ルールには Rename Output という設定があり、既定はオフです。 オンにすると出口に名前を付けられます。

出口が3つ以上になると、番号だけでは「どれが何だったか」が分からなくなります。 ルールを足したら名前も付けるのを習慣にすると、後でワークフローを読み返すときに楽です。

一致しなかったデータは既定で消える

Switchノードで最も事故につながる挙動です。

どのルールにも一致しなかった項目は、既定ではどの出口にも出力されません。 エラーにもならず、警告も出ません。ただ静かに減ります。

実際に確認した結果

4件のテストデータを用意して、2つのルールで振り分けてみました。

データ	想定
tag: 'a'	ルール1だけに一致
tag: 'b'	ルール2だけに一致
tag: 'ab'	ルール1とルール2の両方に一致
tag: 'z'	どのルールにも一致しない

実行結果がこうなりました。

出力0（ルール1）: tag='a', tag='ab'
出力1（ルール2）: tag='b'

入力4件に対して、出力は合計3件です。 tag: 'z' はどこにも出てきませんでした。

さらに、両方のルールに一致する tag: 'ab' も、出力0にしか入っていません。 これも既定の挙動です。

2つの設定を知っておく

上の2つの挙動は、どちらも Options から変えられます。

Fallback Output（一致しなかったときの受け皿）

既定は none（出力しない）です。extra にすると、 一致しなかった項目専用の出口が最後に追加されます。

Rename Fallback Output で名前も付けられますが、これは名前を付けるだけで、 受け皿そのものは作りません。Fallback Output を extra にするのが先です。

Send data to all matching outputs（複数一致の扱い）

既定はオフで、最初に一致したルールの出口にだけ送られます。 オンにすると、一致したすべての出口に送られます。

設定を変えて再実行した結果

先ほどと同じデータで、Fallback Output を extra、複数出力をオンにして実行しました。

出力0（ルール1）: tag='a', tag='ab'
出力1（ルール2）: tag='b', tag='ab'   ← ab が両方に出るようになった
出力2（その他）:  tag='z'             ← 受け皿に流れるようになった

消えるデータが無くなりました。

どう使い分けるか

「一致しないデータは無視してよい」と確信が持てる場合以外は、 Fallback Output を設定してください。

理由は、消えたことに気づけないからです。エラーが出れば調べますが、 静かに減る場合は「なぜか件数が合わない」という形でしか表面化しません。 しかも原因がSwitchだと気づくまでに時間がかかります。

最低限、受け皿を作って、そこに何か流れてきたら分かるようにしておくのが安全です。

もう1つのモード：Expression

Mode には Rules のほかに Expression があります。

ルールを1つずつ書くのではなく、式で出口の番号を計算して返す方式です。 出口の数は Number of Outputs（既定4）で指定し、番号は0から始まります。

振り分け先が計算で決まる場合――たとえば数値を範囲で分けるような場合――は こちらの方が短く書けます。ただし式を見ないと振り分けが分からないので、 読みやすさは Rules の方が上です。

うまくいかないときの切り分け

1. 件数が合わない — Fallback Output が none のまま、一致しない項目が消えていないか
2. 1つの出口にしか行かない — 複数一致の設定がオフのままではないか
3. どの出口にも行かない — 左辺が式になっているか（fx と緑色）
4. 大文字・小文字 — Ignore Case は既定で有効
5. 出口をつないでいるか — つないでいない出口の項目は、そこで止まる

次に読む

• n8n IFノードの使い方 — 分岐が2つならこちら
• n8n Mergeノードの使い方 — 分けたデータを合流させる
• n8n Codeノードの使い方 — 条件では書けない振り分けをコードで
• コアノードの一覧 — ほかのよく使うノード