- はじめに
こんにちは！n8nでの自動化推進に情熱を注ぐシニアエンジニアです。
前回の第1回では、n8nの血液とも言える「JSONデータ」を読み解き、「式(Expressions)」を使ってデータを取り出す方法をマスターしました。これにより、IFノードを使ってデータの内容に応じた基本的な条件分岐が可能になりましたね。
しかし、実世界の業務は単純な「はい/いいえ」だけでは終わりません。
タスクのステータスが「未着手」「進行中」「完了」「保留」の4パターンある
問い合わせの種類が「製品A」「製品B」「その他」で分かれる
顧客のランクが「プラチナ」「ゴールド」「シルバー」で対応が違う
こんな時、IFノードを何重にもネストさせていくとどうなるでしょうか？
(画像はIFを繋げたカオスな状態をイメージ)
あっという間にワークフローは複雑怪奇な「スパゲッティ」と化し、解読もメンテナンスも困難な「IF文の地獄（IF Hell）」に陥ってしまいます。
今回の記事では、この**「IF Hell」からあなたを解放し、複雑なロジックを驚くほどクリーンに整理するための5つの必須ノード**を徹底的に解説します。主役となるSwitchノードを筆頭に、それを支える名脇役たちを使いこなして、ワンランク上のワークフロービルダーを目指しましょう！
- 主役の登場！多分岐を実現する Switch ノード
IFノードが「右か、左か」の二択を迫る分岐点だとすれば、Switchノードは**「行き先案内人」**です。受け取ったデータを見て、その内容に最も適したルート（出力）へと案内してくれます。
1-1. Switchノードの基本構造
Switchノードの設定画面は非常に直感的です。
Routing Rule (ルーティング方法): Data to Route を By Rules (ルールごと) に設定します。
Field to Route By (ルーティング対象フィールド): ここに行き先を判断するためのデータを式で指定します。例えば、タスクのステータスで分岐させたいなら {{ $json.status }} のように入力します。
Rules (ルール): ここに具体的な行き先案内のルールを複数追加していきます。
1-2. ルールの設定方法
各ルールは「どの出力に、どんな条件でデータを渡すか」を定義します。
例えば、statusの値が「未着手」「進行中」「完了」の3パターンある場合、以下のように設定します。
出力 (Output)
条件 (Operation)
比較値 (Value)
Output 0
Equals
未着手
Output 1
Equals
進行中
Output 2
Equals
完了
Google スプレッドシートにエクスポート
これで、statusが「未着手」のアイテムは0番目の出口から、「進行中」なら1番目の出口から...というように、データが自動的に振り分けられます。IFを3つ繋げるよりも、遥かに見通しが良いですよね。
1-3. 想定外を防ぐ「Default」出力
Switchノードの素晴らしい点の一つが、どのルールにも一致しなかったアイテムのための**「Default」出力**が用意されていることです。
例えば、何かの間違いでstatusが「ペンディング」という想定外の値で来た場合、このDefault出口からデータが出力されます。ここにエラー通知処理などを繋いでおけば、予期せぬデータにも迅速に対応でき、ワークフローの堅牢性が格段に向上します。
- ワークフローの名脇役たち
Switchノードは強力ですが、単体では真価を発揮しきれません。ここでは、Switchと組み合わせることでワークフローの質を爆上げする、3つの重要なノードを紹介します。
①【合流の達人】Merge ノード
Switchで分岐させた処理、最終的にまた一つにまとめたい場面は多いものです。「どのステータスであっても、最後にログを記録したい」といったケースですね。
この分岐した流れを再び合流させるのがMergeノードの役割です。
使い方: Switchから分岐した各処理の最後のノードを、すべて1つのMergeノードに繋ぐだけです。
挙動: Mergeノードは、いずれかのルートからデータが到着するたびに、そのデータを後続のノードへパスします。これにより、分岐前と同じように単一のフローとして処理を継続できます。
これを使わずに各分岐から直接最後のノードに線を繋ぐと、意図しない回数実行されるなど、混乱の元になります。**「分岐したら、最後はMerge」**を合言葉にしましょう。
②【変幻自在のデータ職人】Set ノード (再訪)
第1回でも登場したSetノードですが、Switchと組み合わせることでその真価を発揮します。
Switchの各分岐の中でSetノードを使うことで、そのルート専用のデータを作成・加工することができます。
「未着手」ルート: Setノードで、Slack通知用のメッセージとして"【至急】タスク〇〇が未着手です！"というテキストを作成する。
「進行中」ルート: 別のSetノードで、"【進捗確認】タスク〇〇は順調ですか？"という全く別のテキストを作成する。
このように、分岐先ごとにSetノードでデータを「仕込み」、その後の処理（Slack通知など）を共通化することで、ワークフロー全体が非常にスッキリします。
③【沈黙の仕事人】NoOp ノード
NoOp (No Operation)は、その名の通り**「何もしない」**ことを目的としたノードです。
「何もしないノードに何の意味が？」と思うかもしれませんが、これが驚くほど役に立ちます。
ユースケース1: 意図的に処理を終了させる
Switchで分岐した結果、「この場合は何もする必要がない」というルートも存在します。例えばタスクステータスが「完了」の場合です。このルートの末尾にNoOpノードを置いておくと、「ここは意図して何もしていない」ということが一目瞭然になります。 dangling（宙ぶらりん）な出力をなくすことで、ワークフローの可読性が格段に上がります。
ユースケース2: デバッグとプレースホルダー
ワークフローの途中にNoOpを挟み、一旦そこで実行を止めてデータの中身を確認したり、まだ実装していない処理の「仮置き」として設置したりと、開発中の様々な場面で活躍します。
- 実践！タスク管理ボットを賢くする
それでは、これらのノードを使って、前回よりも遥かに賢いタスク管理ボットを構築しましょう。
シナリオ設定
DB: Google Sheetsを使用。シートにはタスク名, 担当者, ステータスの3列が存在する。(ステータス列は未着手, 進行中, 完了のいずれか)
トリガー: Webhookでタスク名を受け取る。
処理:
受け取ったタスク名でGoogle Sheetsを検索し、該当行のデータを取得。
ステータスに応じて処理を分岐。
未着手: 担当者にメンション付きでSlack通知「タスクを開始してください」
進行中: 担当者にメンションなしでSlack通知「タスクの進捗はいかがですか？」
完了: 何もしない。
最後に、Webhookに「確認完了」と応答を返す。
ワークフロー構築手順
[Webhook] ノード: テスト実行用に{"task_name": "n8nブログ執筆"}のようなJSONを送れるように設定します。
[Google Sheets] ノード:
ResourceをRow、OperationをGet Manyに設定。
Sheet ID等、ご自身のシート情報を設定します。
Options > Add Option > Filters を追加。
Keyにタスク名（シートの列名）、Valueに{{ $json.body.task_name }}と式で設定します。これでWebhookで受け取ったタスク名に一致する行だけを取得できます。
[Switch] ノード: Google Sheetsノードの次に接続します。
Field to Route By に {{ $json.ステータス }} と設定します。
Rule 1: OperationをEquals、Valueを未着手とし、OutputをOutput 0に。
Rule 2: OperationをEquals、Valueを進行中とし、OutputをOutput 1に。
Rule 3: OperationをEquals、Valueを完了とし、OutputをOutput 2に。
分岐1: 「未着手」ルート (Output 0)
[Set] ノード: Nameをslack_message、Valueを@{{ $json.担当者 }} 【至急】タスク「{{ $json.タスク名 }}」が未着手です！対応をお願いします。と設定。
[Slack] ノード: Textに{{ $json.slack_message }}と設定し、メッセージを送信。
分岐2: 「進行中」ルート (Output 1)
[Set] ノード: Nameをslack_message、Valueを【進捗確認】タスク「{{ $json.タスク名 }}」は順調ですか？と設定。
[Slack] ノード: Textに{{ $json.slack_message }}と設定し、メッセージを送信。
分岐3: 「完了」ルート (Output 2)
[NoOp] ノード: 接続し、ノード名を「処理不要（完了済み）」などとしておきます。
[Merge] ノード:
上記３つのルートの最終ノード（Slackノード2つとNoOpノード1つ）を、すべてこのMergeノードに接続します。
[Respond to Webhook] ノード:
Mergeノードの次に接続します。
Response Bodyに 「{{ $json.タスク名 }}」のステータス確認が完了しました。 と設定します。
これで完成です！IFをネストするのに比べて、各ステータスの処理が独立し、どこで何をしているのかが非常に分かりやすいワークフローになりました。
- まとめ：ロジックを制する者が、自動化を制す
今回は、複雑な条件分岐をクリーンに実装するための必須ノード群を学びました。
Switchノード: 多分岐の主役。IF Hellを回避し、ロジックを見通し良くする。
Mergeノード: 分岐したフローを綺麗に合流させる、縁の下の力持ち。
Setノード: 分岐先ごとにデータを加工し、後続処理を共通化させるためのキーマン。
NoOpノード: 「何もしない」を明示し、ワークフローの可読性と堅牢性を高める仕事人。
これらのノードを自在に組み合わせることで、あなたはもう単に処理を繋げるだけでなく、ワークフローの「ロジック」そのものを設計することができるようになりました。これは、n8nを「おもちゃ」から「強力な開発ツール」へと昇華させるための、非常に大きな一歩です。
次回は、いよいよn8nの真価が発揮される**「外部サービス(API)との連携」に踏み込みます。n8nに専用ノードが用意されていないサービスとも自由に通信できる最強の武器、HTTP Requestノード**を使いこなし、あなたの自動化の世界を無限に広げていきましょう。
それでは、良き自動化ライフを！