n8n 実践応用：Webhook トリガーと IF/Switch 条件分岐の設計

あのオレンジ色の「Test Workflow」ボタンを、17 回目に押したところです。

毎回、手動でクリックしないとトリガーできません。これって普通の API みたいに、誰かが呼び出したら自動で動いてくれないものか——。そう思って調べてみたら、n8n には Webhook というものがありました。要するにドアベルです。誰かがボタンを押すと、ワークフローが反応して動き出します。

この記事で扱うのは、このドアベルの取り付け方、そして取り付けたあとに訪問者ごとに別々の部屋へ振り分ける方法です。n8n の基本ノードはもう使えるけれど、ワークフローがいつも「受け身で待っている」状態に感じる——そんな人の助けになるはずです。

これから話す内容はこちらです。

• Webhook ノードの、見ているだけで目が回りそうなパラメータを、結局どう設定するのか
• IF と Switch というこの兄弟分を、どんなときにどちらを使うのか
• そのまま流用できる、注文処理の完全な事例
• 本番環境で踏みたくない落とし穴

一、Webhook ノードの詳細設定

まず一つはっきりさせておきます。Webhook と定期トリガーは、まったくの別物です。

定期トリガーは目覚まし時計です。外で何か起きているかどうかに関係なく、一定間隔で鳴ります。Webhook はドアベルで、誰かが押したときだけ鳴ります——これがいわゆるイベント駆動です。ドアベルの利点は、5 分おきに玄関へ荷物が届いていないか見に行かなくて済むこと。配達員が来てボタンを押せば、自然と気づけます。公式データによると、Webhooks はポーリングの負荷を 90-95% ポーリング負荷の削減 削減できるとのこと。要するに、リソースも時間も節約できるということです。

1.1 HTTP メソッドはどれを選ぶか

Webhook ノードを開いて、最初に入力するのが HTTP Method です。n8n は標準の DELETE、GET、HEAD、PATCH、POST、PUT をサポートしています。

どう選ぶか。やりたいこと次第です。

• POST：データを受け取る場合。たとえばフォーム送信や新規注文の通知。これがいちばん一般的な使い方です。
• GET：単純なトリガー。たとえば短縮リンクを生成し、ユーザーがクリックするとワークフローが動く、といった用途。
• PUT/PATCH：データ更新のシーン。たとえば注文ステータスの変更など。

私はほとんどの場合 POST を使います。body にデータを乗せて持ち込めるからです。

1.2 レスポンスモードは 4 種類

このパラメータは「Response Mode」と呼ばれ、n8n が呼び出し元へどう返答するかを決めます。

ここに落とし穴があります。「Immediately」を選ぶと、呼び出し元は 200 を受け取った時点で立ち去ります。でも、そのあとのノードでエラーが起きても呼び出し元には伝わりません。ですからバックグラウンドタスクには、エラー通知の仕組みを併せて用意しておくのが安全です。

1.3 ルートパラメータで RESTful に

Path パラメータには動的ルートを書けます。たとえば orders/:orderId。コロンの後ろが変数名で、URL 内の値を自動的に抽出します。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

例として /orders/12345 を呼び出すと、ワークフロー内では {{ $params.orderId }} で 12345 を取得できます。これは毎回 query string でパラメータを渡すよりもずっとすっきりしています。

1.4 Payload のサイズ制限

Webhook の最大 payload は 16MB 最大 payload です。これを超えるとエラーになります。

どうしても大きなファイルを送る必要があるなら、選択肢は 2 つ。

1. 環境変数 N8N_PAYLOAD_SIZE_MAX を変更する
2. ファイルをオブジェクトストレージへアップロードし、URL だけを Webhook に渡す

正直なところ、16MB はたいていのシーンで十分です。本当に大きなファイルを送るなら、2 つ目の方法のほうが確実です。

二、IF vs Switch：条件分岐ノードの選び方

この 2 つのノードは機能がよく似ていて、どちらもデータを振り分けられます。でも、使い分けを誤ると痛い目に遭います。IF を入れ子にしすぎてスパゲッティコードになるか、Switch を延々と設定したあげく結局 2 分岐で済んだことに気づくか、です。

2.1 IF ノード：二者択一

IF ノードには出口が 2 つしかありません。true と false です。

玄関で配達員に「生鮮ですか？」と尋ねるようなもの。そうなら冷蔵庫へ、違うなら玄関先へ。シンプルで分かりやすい。

IF が対応する条件タイプはけっこう多いです。String、Number、Date & Time、Boolean、Array、Object のどれも比較できます。たとえば——

• String：contains、starts with、ends with、matches regex
• Number：is greater than、is less than
• Boolean：is true、is false
• Array：contains、length greater than

2.2 Switch ノード：多者選択

Switch ノードは出口を複数持てます。「あなたはどの部署ですか？」のようなシーン向きです——経理はこちら、技術はあちら、運営はまた別の方へ。

Switch には 2 つのモードがあります。

• Rules：表に記入する感覚で、1 つの条件が 1 つの出口に対応します。直感的で、初心者向き。
• Expression：JavaScript 式を書いて出口番号を返します。柔軟で、複雑なロジック向き。

2.3 どちらを選ぶ？この表を見てください

コツが 1 つ。IF の後ろにまた IF を足し、さらに IF を足し……と気づいたら、目を覚ましましょう。それは Switch の出番です。

2.4 データ型はどれも比較できる

IF も Switch も、次の型の比較に対応しています。

• String：exists、is empty、contains、matches regex……
• Number：より大きい、より小さい、等しい……
• Date & Time：時刻の前後を比べる
• Boolean：真偽
• Array：長さ、ある要素を含むか
• Object：存在する、空、空でない

Date & Time はなかなか便利です。たとえば注文がタイムアウトしているかどうかは、日付を比べるだけで判定できます。

三、実践事例：注文ステータスの自動処理

実際のシーンを話します。友人が小さな EC を始めたのですが、毎日の注文処理はすべて手作業で、管理画面を見て、通知を送り、電話をかける、という具合でした。これは n8n で片付くよ、と言ったら、半信半疑でした。

2 週間後、彼の倉庫担当が言ったそうです。「なんで急に注文を取りこぼさなくなったんだ？」

3.1 何をやりたいか

要件はとてもシンプルです。

• 新規注文（pending）→ 倉庫へ入荷準備を通知
• 支払い済み（paid）→ 顧客へ確認メールを送信
• 発送済み（shipped）→ 配送情報を更新
• キャンセル（cancelled）→ 返金処理

4 つのステータス。ちょうど Switch ノードで振り分けるのにぴったりです。

3.2 Webhook の設定

まずは Webhook ノードから。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

• HTTP Method：POST
• Path：orders/:orderId
• Response Mode：When Last Node Finishes（処理結果を返したいので）
• Authentication：Header Auth

セキュリティには Header Auth を使い、X-Shop-Secret というカスタムヘッダーを用意して、値はランダムな文字列にしました。この secret を知っているシステムだけが呼び出せます。

3.3 Switch ノードの振り分けロジック

Switch を Rules モードに設定し、4 つのルールを 4 つのステータスに対応させます。

ルール1: {{ $json.status }} equals "pending" → 出力: pending
ルール2: {{ $json.status }} equals "paid" → 出力: paid
ルール3: {{ $json.status }} equals "shipped" → 出力: shipped
ルール4: {{ $json.status }} equals "cancelled" → 出力: cancelled

Fallback Output は Extra Output に設定します。万一おかしなステータス（たとえば “unknown”）が来ても、詰まらないようにするためです。

3.4 完全なワークフロー JSON

これはそのまま n8n にインポートして使えます。

{
  "name": "Order Processing",
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "position": [250, 300],
      "parameters": {
        "httpMethod": "POST",
        "path": "orders/:orderId",
        "responseMode": "responseNode",
        "authentication": "headerAuth"
      }
    },
    {
      "name": "Switch",
      "type": "n8n-nodes-base.switch",
      "position": [500, 300],
      "parameters": {
        "mode": "rules",
        "rules": [
          { "output": "pending", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "pending" } },
          { "output": "paid", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "paid" } },
          { "output": "shipped", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "shipped" } },
          { "output": "cancelled", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "cancelled" } }
        ],
        "fallbackOutput": "extra"
      }
    },
    {
      "name": "Notify Warehouse",
      "type": "n8n-nodes-base.slack",
      "position": [750, 200]
    },
    {
      "name": "Send Confirmation",
      "type": "n8n-nodes-base.emailSend",
      "position": [750, 300]
    },
    {
      "name": "Update Tracking",
      "type": "n8n-nodes-base.httpRequest",
      "position": [750, 400]
    },
    {
      "name": "Process Refund",
      "type": "n8n-nodes-base.stripe",
      "position": [750, 500]
    }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "Switch", "type": "main", "index": 0 }]] },
    "Switch": {
      "main": [
        [{ "node": "Notify Warehouse", "type": "main", "index": 0 }],
        [{ "node": "Send Confirmation", "type": "main", "index": 0 }],
        [{ "node": "Update Tracking", "type": "main", "index": 0 }],
        [{ "node": "Process Refund", "type": "main", "index": 0 }]
      ]
    }
  }
}

この JSON をコピーして、n8n に貼り付けてインポートするだけです。Slack、Email、HTTP Request、Stripe といったノードは、忘れずに自分の設定に置き換えてください。

3.5 テストと本番投入

n8n には 2 種類の URL があります。

• Test URL：開発・デバッグ時に使う。自分で手動テストしたときだけ実行される
• Production URL：アクティブ化してから有効になる。実際に外部へサービスを提供する

流れはこうです。

1. Test URL で呼び出し、ノードの実行順序とデータの流れを確認する
2. 問題ないと確認できたら、右上の「Active」スイッチをクリック
3. Production URL を EC プラットフォームへ伝える（または Zapier 経由で中継する）

テスト時は curl で呼び出しをシミュレートできます。

curl -X POST https://your-n8n-instance.com/webhook/orders/12345 \
  -H "Content-Type: application/json" \
  -H "X-Shop-Secret: your-secret-key" \
  -d '{"status": "paid", "customer_email": "test@example.com"}'

200 が返って実行ログが見えれば、開通したということです。

四、本番環境の落とし穴回避ガイド

ワークフローが動いたからといって、すぐに本番へ出せるわけではありません。私がいくつか踏んだ落とし穴を共有します。

4.1 認証で手を抜かない

Header Auth は最初の一歩にすぎません。呼び出し元の IP アドレスが固定だと分かっているなら、IP Whitelist も足したほうがより安全です。

Webhook ノードの詳細オプションに「IP Whitelist」というパラメータがあるので、呼び出しを許可する IP のリストを記入します。それ以外の IP からの呼び出しは即座に拒否され、ワークフローはトリガーすらされません。

JWT Auth もなかなか便利ですが、設定が少し複雑です。呼び出し元が自分で管理しているシステムなら、Header Auth + IP Whitelist で十分です。

4.2 エラーは誰かが気づけるように

Webhook ノードでエラーが起きると、呼び出し元には 500 が 1 つ届くだけかもしれませんが、具体的にどこで問題が起きたのかはあなたが把握する必要があります。

やり方は、ワークフローに Error Trigger ノードを 1 つ追加し、エラー時に自動で Slack 通知を送ること。設定はだいたいこんな感じです。

Error Trigger → Slack（エラー情報と実行 ID を送信）

こうしておけば、夜中に問題が起きてもスマホで気づけます。朝になってユーザーからクレームが来るまで気づかない、ということがなくなります。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

4.3 パフォーマンスのちょっとしたコツ

ワークフローの後ろで外部 API をたくさん呼ぶ場合（在庫照会、メール送信、決済 API の呼び出しなど）、レスポンスはとても遅くなります。呼び出し元が待ちきれずタイムアウトしてしまうかもしれません。

そんなときは Immediately レスポンスモードを使い、先に 200 を返して、バックグラウンドでゆっくり処理します。代償として、呼び出し元は最終結果を知れないので、別途照会する必要があります。

向いているシーン：定期バッチタスク、重要でない通知。向かないシーン：決済確認、リアルタイム照会。

4.4 デバッグは Execution ログを見る

n8n は実行ごとに記録を残します。左メニューの「Executions」をクリックすると、各呼び出しの入出力、どのノードにどれだけ時間がかかったか、どのステップでエラーが出たかが分かります。

細かい点が 1 つ。実行ログは最新の 1000 件だけ保持されます（デフォルト設定）。呼び出し量が多いなら、環境変数 EXECUTIONS_DATA_MAX_AGE を変更するか、定期的にログをエクスポートしたくなるでしょう。

それから、Test URL と Production URL の実行ログは別々に見るものなので、混同しないように。

まとめ

ひととおり話し終えました。

Webhook は n8n にドアベルを取り付けるようなもの——誰かが押せば、あなたのワークフローが動き出します。設定では HTTP Method と Response Mode に注意し、ルートパラメータは使えるなら使って、query string にあれこれ書かずに済ませましょう。

IF と Switch のどちらを選ぶか。分岐が 2 つなら IF、3 つ以上なら Switch です。IF を入れ子にしないこと。見ているだけで頭が痛くなります。

あの注文処理のワークフローはそのまま持っていって使えます。中の Slack、Email、Stripe の設定は忘れずに変更してください。本番投入の前に Test URL で何度かデバッグし、問題ないと確認してからアクティブ化しましょう。

最後に、セキュリティで手を抜かないこと。Header Auth を足し、条件が許すなら IP Whitelist も足す。エラーには通知の仕組みを。でないと、問題が起きても気づけません。

質問があればコメントするか、n8n コミュニティで直接検索してみてください。あそこには詳しい人がたくさんいます。