n8n 実践ガイド:Webhook トリガーと IF/Switch 条件分岐の設計
深夜2時、画面上のオレンジ色の “Test Workflow” ボタンを17回目押したときのことです。
そのたびに手動でクリックしないとトリガーされない。「これ、普通の API みたいに誰かが呼び出したら自動で動かないの?」と思っていました。後に知ったのですが、n8n には Webhook という機能があるのです。要するにインターホンのようなもので、誰かが押すとワークフローが動き出します。
この記事では、そのインターホンの取り付け方と、来客者の種類に応じて別々の部屋に案内する方法について解説します。n8n の基本ノードは使えるけれど、ワークフローが「待ち受け状態」のような感覚を持っている方は、この記事で視野が広がるはずです。
この記事で取り上げる内容:
- Webhook ノードのややこしいパラメータの設定方法
- IF と Switch の使い分け
- そのまま使える完全な注文処理ケーススタディ
- 本番環境で避けるべき落とし穴
一、Webhook ノードの詳細設定
まず理解しておくべきことがあります。Webhook とスケジュールトリガーは全く別物です。
スケジュールトリガーは目覚まし時計のようなもので、一定間隔で鳴ります。外で何が起きているかは関係ありません。一方、Webhook はインターホンです。誰かが押したときだけ鳴ります。これがイベント駆動です。インターホンの利点は、5分ごとに玄関に行って荷物があるか確認する必要がないことです。宅配員が来て押してくれれば、自然とわかります。公式データによると、Webhook は
を実現できます。つまり、リソースと時間の節約になるのです。1.1 HTTP メソッドの選択
Webhook ノードを開くと、最初に入力するのが HTTP Method です。n8n は標準的な DELETE、GET、HEAD、PATCH、POST、PUT をサポートしています。
どう選ぶか?目的によって異なります:
- POST:データを受信する場合。フォーム送信や新規注文通知など。最も一般的な使い方です。
- GET:シンプルなトリガー。短縮URLを生成して、ユーザーがクリックするとワークフローを実行するなど。
- PUT/PATCH:データ更新のシナリオ。注文ステータスの変更など。
私はほとんどの場合、POST を使います。body データを受け取れるからです。
1.2 レスポンスモードは4種類
このパラメータは “Response Mode” と呼ばれ、n8n が呼び出し元にどう応答するかを決定します:
| モード | 使用シーン |
|---|---|
| Immediately | すぐに 200 を返す。後続の実行結果は問わない。バックグラウンドタスクに適している。 |
| When Last Node Finishes | ワークフロー全体が完了するのを待ってから結果を返す。データを返す必要がある場合に使用。 |
| Using ‘Respond to Webhook’ Node | 中間のノードが何を返すか決定する。柔軟だが、ノードを追加する必要がある。 |
| Streaming response | AI Agent のストリーミング出力シナリオ。新機能。 |
注意点:“Immediately” を選択すると、呼び出し元は 200 を受信して終わりますが、後続ノードでエラーが起きても知りません。そのため、バックグラウンドタスクにはエラー通知メカニズムを設定するのが望ましいです。
1.3 ルーティングパラメータで RESTful
Path パラメータに動的ルーティングを設定できます。例えば orders/:orderId。コロンの後ろは変数名で、URL の値が自動的に抽出されます。
例えば、/orders/12345 を呼び出すと、ワークフロー内で {{ $params.orderId }} で 12345 を取得できます。クエリ文字列で毎回パラメータを渡すより、こちらの方がスッキリしています。
1.4 Payload サイズ制限
Webhook の最大ペイロードは
です。これを超えるとエラーになります。どうしても大きなファイルを送る必要がある場合、2つの選択肢があります:
- 環境変数
N8N_PAYLOAD_SIZE_MAXを変更する - ファイルをオブジェクトストレージにアップロードし、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:フォームに入力するように、条件ごとに出口を設定。直感的で、初心者に適している。
- Expression:JavaScript 式を書いて、出口番号を返す。柔軟で、複雑なロジックに適している。
2.3 どっちを選ぶ?この表を見て
| あなたのシナリオ | 推奨ノード | 理由 |
|---|---|---|
| 真偽だけ判定 | IF | 2つの出口で十分、複雑にしない |
| 3つ以上の分流 | Switch | 1つのノードで完結、ネスト不要 |
| 条件ロジックが複雑 | Switch + Expression | フォームよりコードの方が早い |
| 後でマージする必要がある | IF | Merge ノードとの相性が良い |
テクニック: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 ノード:
- HTTP Method:POST
- Path:
orders/:orderId - Response Mode:When Last Node Finishes(処理結果を返す必要がある)
- Authentication:Header Auth
セキュリティについては Header Auth を使用し、カスタムヘッダー X-Shop-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:アクティブにした後に有効。実際に外部サービスとして動作
フローはこうです:
- Test URL で呼び出し、ノードの実行順序とデータの流れを確認
- 問題なければ、右上の “Active” スイッチをクリック
- 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 しか受け取れません。でも、どこで問題が起きたか知る必要があります。
対策は、ワークフローに Error Trigger ノードを追加すること。エラー時に自動的に Slack 通知を送ります。設定はこんな感じ:
Error Trigger → Slack(エラー情報と実行IDを送信)
こうすれば、深夜に問題が起きても、スマホで確認できます。朝になってユーザーからのクレームで気づくということはありません。
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 に注意し、ルーティングパラメータを使えるなら使いましょう。クエリ文字列にたくさん書くよりスッキリします。
IF と Switch のどちらを選ぶか?2つの分岐なら IF、3つ以上なら Switch。IF をネストしないでください。読みにくいです。
あの注文処理ワークフローはそのまま使えます。Slack、Email、Stripe の設定を変更するのを忘れないでください。本番前に Test URL で何度かテストし、問題ないことを確認してからアクティブにしてください。
最後に、セキュリティをサボらないでください。Header Auth を設定し、可能なら IP Whitelist も追加しましょう。エラー通知メカニズムも必須です。そうしないと、問題が起きても気づきません。
質問があればコメントを残すか、n8n コミュニティで検索してください。そこには詳しい人がたくさんいます。
n8n Webhook ワークフローの設定
ゼロから Webhook トリガーの注文処理ワークフローを構築し、条件分岐とセキュリティ認証を含む
⏱️ 目安時間: 30 分
- 1
ステップ1: Webhook ノードの設定
基本パラメータの設定:
• HTTP Method:POST(データ受信シナリオ)
• Path:orders/:orderId(動的ルーティングパラメータ)
• Response Mode:When Last Node Finishes(処理結果を返す必要がある)
• Authentication:Header Auth(セキュリティ認証) - 2
ステップ2: Switch 条件分岐の設計
4つの分岐ルールの設定:
• pending → 倉庫に通知して出荷準備
• paid → 確認メールを送信
• shipped → 配送情報を更新
• cancelled → 返金処理
Fallback Output を Extra Output に設定し、未知のステータスでワークフローが止まらないようにする。 - 3
ステップ3: 分岐処理ノードの追加
各分岐に対応するノードを追加:
• Slack ノード:倉庫に通知
• Email ノード:確認メール送信
• HTTP Request ノード:配送情報更新
• Stripe ノード:返金処理
自分のサービス設定に置き換える。 - 4
ステップ4: セキュリティ認証の設定
本番環境のセキュリティ設定:
• Header Auth:カスタム X-Shop-Secret
• IP Whitelist:呼び出し元の IP を制限
• Error Trigger:エラー時に Slack 通知を送信 - 5
ステップ5: ワークフローのテストとアクティベート
検証フロー:
• Test URL と curl でテスト呼び出し
• Execution ログでデータの流れを確認
• 問題なければ Production URL をアクティベート
• URL をECプラットフォームに設定
FAQ
Webhook とスケジュールトリガーの違いは何ですか?
IF ノードと Switch ノードはどう使い分けるべきですか?
• 2つの分岐(true/false)→ IF ノード、シンプルで効率的
• 3つ以上の分岐 → Switch ノード、IF のネストを回避
• 複雑なロジック → Switch + Expression モード、JavaScript 式でより柔軟に
IF をネストしている自分に気づいたら、Switch を検討すべきです。
Webhook の Payload サイズ制限は?
Webhook のセキュリティ認証はどう設定しますか?
• Header Auth:カスタムヘッダーとシークレットキー
• IP Whitelist:許可する呼び出し元の IP アドレスを制限
• JWT Auth:より安全だが設定が複雑
開発テスト段階では Header Auth で十分、本番環境では IP Whitelist の追加を推奨します。
Immediately と When Last Node Finishes レスポンスモードの違いは?
Webhook ワークフローはどうデバッグしますか?
• 左側メニューの Executions で各呼び出しを確認
• 入力出力、ノード実行時間、エラー情報が見られます
• Test URL と Production URL のログは別々に確認
• デフォルトで直近 1000 件を保持、環境変数で調整可能
本番環境での注意事項は?
• セキュリティ認証の設定(Header Auth + IP Whitelist)
• エラー通知メカニズムの追加(Error Trigger + Slack)
• 大量トラフィックシナリオでは Immediately レスポンスモード + バックグラウンド処理を検討
• 実行ログの定期エクスポートまたはクリーンアップ
• テスト時は Test URL を使用、問題なければ Production URL をアクティベート
6 min read · 公開日: 2026年4月9日 · 更新日: 2026年4月9日
関連記事
Docker Compose マルチサービスオーケストレーション:ローカル開発環境を一発起動
Docker Compose マルチサービスオーケストレーション:ローカル開発環境を一発起動
Supabase Storage 実践ガイド:ファイルアップロード、権限制御とCDN活用
Supabase Storage 実践ガイド:ファイルアップロード、権限制御とCDN活用
GitHub Actions Matrix ビルド:マルチバージョン並列テストの実践

コメント
GitHubアカウントでログインしてコメントできます