n8n Filterノードの使い方：IFとの違いと、通らなかったデータの行方

Filterは条件に合うアイテムだけを通すノードです。IFとの使い分け、型が合わないとエラーで止まること、1件も通らないと後続が動かないことを実際に動かして確かめました。JSONで生成すると型変換のトグルが効かなくなる現象も実測しています。

Filter は、条件に合うアイテムだけを通すノードです。 10件流し込んで、条件に合う3件だけを次へ送る、という使い方をします。

似たノードに IF があります。どちらも条件で判定しますが、 合わなかったアイテムの扱いが違います。 そこが選び方の決め手になります。

5件のデータを流して、実際の挙動を確かめました。

IF との違い

	Filter	IF
画面上の出力	1本（`Kept`）	2本（`true` / `false`）
条件に合わなかったアイテム	先へ進まない	false 側へ流せる
向いている場面	いらないデータを落とす	両方に別の処理をする

「落とすだけ」なら Filter、「分けて両方使う」なら IF です。

条件の書き方は IF と同じです。左に値、真ん中に演算子、右に比較する値を置きます。

n8nのFilterノード設定画面。Conditionsに {{ $json.name }} is equal to tokyo という条件が1つ設定され、その下にConvert types where requiredのトグル、Optionsの+ Add optionを押すとIgnore Caseだけが表示されている — 設定項目は少ないです。Options に入っているのは Ignore Case だけ

通らなかったアイテムはどこへ行くのか

ここが一番調べたかったところです。

Switch ノードは、どのルールにも一致しなかったアイテムを 黙って捨てます。Filter も同じなのかを確かめました。

結論から言うと、画面上は捨てられますが、データとしては残っています。

5件のうち1件だけが条件に合う設定で実行したところ、実行データはこうなっていました。

"data": { "main": [
  [ { "name": "tokyo" } ],                                    // 1本目: 通った1件
  [ { "name": "Tokyo" }, { "name": "OSAKA" },
    { "name": "kyoto" }, { "name": "Tokyo" } ]                // 2本目: 通らなかった4件
]}

2本目の配列に、通らなかった4件が入っています。

実際にこの2本目へノードを繋いだところ、4件を受け取れました。

n8nのキャンバス。開始、5件つくる、絞り込む、通った分が横に並び、絞り込むの出力には Kept というラベルが1つだけ付いている。そこから下へ線が伸びて通らなかった分に繋がっているが、2本目の出力コネクタは表示されていない — 出力のコネクタは Kept の1つだけ。下へ伸びる線は JSON で直接繋いだもの

なぜこうなっているのか、n8n のコードを見たら理由が分かりました。

outputs: [NodeConnectionTypes.Main],   // 出力は1本と宣言している
...
return [keptItems, discardedItems];    // 実際は2つ返している

宣言と実装が食い違っています。 画面にコネクタが出ないのは宣言が1本だからで、それでもJSONで繋げば届くのは、実装が2つ返しているからです。

1件も通らないと、後続は動かない

条件に合うアイテムが0件のとき、何が起きるかも確かめました。

Filter の1本目の出力は 空の配列
後続ノードには実行記録が1つも残らない
ワークフロー全体は success で終わる

「0件で実行された」のではなく「実行されなかった」が正しい状態です。これは IF ノードで条件に合わなかった側と同じ挙動でした。

型が違うとエラーで止まる

数値の 3 を、文字列の '3' と比べたらどうなるか。試したところ、 ワークフローが止まりました。

Wrong type: '3' is a number but was expecting a string [condition 0, item 0]

エラーメッセージには対処法まで書かれています。

Try either:

Enabling ‘Convert types where required’

Converting the first field to a string by adding .toString()

Convert types where required は、条件の下にあるトグルです。オンにして同じ条件で実行したところ、数値の 3 が文字列の '3' と一致しました（2件通過）。

JSONで作ると、このトグルが効かないことがある

ここは Claude Code や API でワークフローを生成している人に向けた話です。

検証中、Convert types where required をオンにしてもまったく効かない時間がありました。原因は n8n ではなく、私のワークフローの作り方でした。

conditions.options.typeValidation に固定値を書くと、トグルが無視されます

conditions.options.typeValidation には、本来この式が入っています。

={{ ($nodeVersion < 2.1 ? $parameter.options.looseTypeValidation : $parameter.looseTypeValidation)
    ? "loose" : "strict" }}

画面のトグルを読むための式です。ところがJSONやSDKでワークフローを作るとき、ここに "strict" のような固定値を書いてしまうと、式が上書きされます。その結果、画面でトグルを切り替えても何も起きません。

式に戻したところ、トグルが正しく効くようになりました。

生成したワークフローで「設定が効かない」ときは、画面ではなくJSONを見てください。 式であるべき場所に固定値が入っていないかを確認します。

Options にあるのは Ignore Case だけ

+ Add option を押すと、出てくるのは Ignore Case の1つだけです。大文字小文字を無視するかどうかの設定で、既定はオンです。

なお、ノードの定義には looseTypeValidation という項目が Options の中にもあります。ただしこれはノードのバージョンが 2.1 未満のときだけ表示されるもので、いまのバージョン（2.3）では出てきません。上のトグルの方を使います。

検証していないこと

条件を複数組み合わせた場合は試していません。 and / or の挙動は条件1つでしか確認していません
使った演算子は 文字列の is equal to だけです。日付や配列の演算子は見ていません
2本目の出力に依存した作りが、将来のバージョンでどうなるかは分かりません。 n8n 2.36.8 の時点で、宣言と実装がずれていることを確認しただけです
Ignore Case を明示的にオフにした場合は試していません。既定（オン）の状態と、条件側の caseSensitive: true を指定した状態だけ確認しています

まとめると、落とすだけなら Filter、拾いたいなら IF です。 Filter の2本目の出力は存在しますが、画面から繋げない以上、設計の前提にはできません。

条件で2つに分けるなら IFノードの使い方
3つ以上に分けるなら Switchノードの使い方
アイテムの考え方は n8n 用語集に