※本記事にはアフィリエイトリンクが含まれます。
n8n Webhook を使い始めて最初にハマったのが、「テスト用URLでは動いたのに、本番に切り替えたら404が返ってきた」という問題だった。僕も最初これで1時間溶かした。原因はワークフローをActivateするのを忘れていただけだったが、そのことは設定ガイドのどこにも目立って書いていなかった。
この記事では、 のWebhookノードの基本設定から、テスト用URLと本番URLの違い、セキュリティ設定まで、実際に詰まったポイントを踏まえながら説明する。
この記事でわかること：
- Webhookとは何か・他のトリガーとの違い
- テスト用URLと本番URLの使い分けと切り替え時の落とし穴
- POSTデータの取り出し方（$jsonでの参照）
- Header Authによるセキュリティ設定
Webhook とは何か、なぜ n8n で使うのか
Webhookは、外部サービスで何かイベントが発生したときに、そのサービスが自動的にn8nにHTTPリクエストを送る仕組みだ。「データが来たら動く」という形で、n8n側は受け身で待っている。
他のトリガーとの違い（Scheduleトリガー・Pollingとの比較）
n8nには複数のトリガー方式がある。
- Scheduleトリガー：一定間隔や指定時刻に自動起動。外部サービスを5分おきにAPIで叩いてデータを確認するような使い方
- Pollingトリガー：特定サービスのAPIを定期的に問い合わせて変化を検知する
- Webhookトリガー：外部サービスからのリクエストを受け取ったときだけ起動する
Scheduleでやっていたときは、5分おきにAPIを叩くので1日288回のリクエストが発生していた。Webhookに切り替えたら、イベントが発生したときだけ動くので1日数回になった。相手サービスのレートリミットを気にしなくて良くなったのは地味に大きかった。
n8n Webhookが向いているのは「外部サービスのイベント発生をリアルタイムで受け取りたい」ときだ。フォーム送信、GitHub push、決済通知、Zapierからの連携などがわかりやすい用途になる。
n8n Webhook ノードの基本設定：まず押さえるべき3点
テスト用 URL と本番 URL の違い、切り替え方
n8nのWebhookノードには2種類のURLがある。
- テスト用URL（Test URL）：「Test workflow」モード（リスニング状態）でのみ動作
- 本番URL（Production URL）：ワークフローがActive状態のときに動作
設定画面を開くと両方のURLが表示されている。テスト中は「Test URL」にリクエストを送り、本番運用時は「Production URL」を使う。
最も多いハマりポイント： テスト用URLで動作確認したあと、外部サービスのWebhook設定をProduction URLに変えたのにワークフローをActivateするのを忘れた、というケースだ。ActivateしないとProduction URLへのリクエストは無視される。
ワークフロー画面右上のトグルスイッチをONにしてActivateすることを必ず確認する。ダッシュボードでは「Active」バッジが表示されているかで確認できる。
POST データの受け取り方と $json での参照
外部サービスがWebhookでPOSTリクエストを送ってくると、n8n側でそのデータを受け取れる。
POSTのボディデータは以下の形式で参照できる：
{{ $json.body.フィールド名 }}
たとえばフォームから送られてきた name と email を受け取るなら：
{{ $json.body.name }}
{{ $json.body.email }}
GETリクエストのクエリパラメータは $json.query.パラメータ名 になる。
Webhookノードを実行してみると、受け取ったデータの全体構造が「output」に表示される。そこを見れば $json のどのパスにデータが入っているかがわかるので、まずテスト実行して確認するのが早い。
レスポンス設定（即時返却 vs ワークフロー完了後返却）
Webhookノードには「Respond」という設定項目がある。
- Immediately：Webhookを受け取った瞬間に200 OKを返す。ワークフローの処理が終わるのを待たない
- After Workflow Completes：ワークフロー全体の処理が完了してから返す。処理結果をレスポンスに含めたい場合
フォーム送信の受付など「受け取りさえすればいい」ケースはImmediately。外部サービスが処理結果のレスポンスを必要とするAPIコールバックはAfter Workflow Completesを選ぶ。
実践例：GitHub の push イベントを受け取って Slack に通知する
よくある使い方として、GitHubのリポジトリにpushがあったときSlackに通知するフローを説明する。
- n8nでWebhookノードを作成し、Production URLをコピー
- GitHubのリポジトリ設定 → Webhooks → Add webhook
- Payload URLにコピーしたProduction URLを貼る
- Content typeを「application/json」に設定
- 送信イベントで「Just the push event」を選択
- n8nでワークフローをActivate
- n8nのWebhookノードの後ろにSlackノードを繋いで、メッセージ内容を設定
$json.body.ref でブランチ名、$json.body.pusher.name でpushしたユーザー名を取得できる。
Webhook にセキュリティを追加する：Header Auth の設定
Webhook URLを知られていれば、誰でもリクエストを送れてしまう。外部からの不正リクエストを弾くために、Header Authを設定することを強く勧める。
僕はテスト中に認証をかけていなかった時期があって、数日後に不審なリクエストがログに残っていた。大したことはなかったが、認証は最初から設定すべきだったと反省している。
Webhookノードの「Authentication」→ 「Header Auth」を選択すると、ヘッダー名と値を設定できる。MDN Web Docs のHTTPヘッダー解説（日本語版）を読んでおくと、認証ヘッダーの仕組みが理解しやすい。たとえば：
- Name：X-Webhook-Secret
- Value：（ランダムな文字列）
外部サービス側で同じヘッダーを送るよう設定する。n8nは受け取ったリクエストのヘッダーを検証し、値が一致しない場合は401を返す。
GitHubのWebhookには標準でSecret設定があるので、そちらを使うのも良い。
つまずきポイント：本番 URL に切り替えたら動かなくなった理由
まとめとして、「本番URLで動かない」場合のチェックリスト：
- ワークフローがActivateされているか（最多原因）
- 外部サービスのWebhook設定がProduction URLになっているか（Test URLのままでは本番で動かない）
- セルフホスト版の場合、そのURLが外部から到達可能か（ローカルホストのままではngrokなどが必要）
- Header Authを設定した場合、外部サービス側でも同じヘッダーを送っているか
一個一個確認すれば大体どれかに当たる。
まとめ：Webhook を使うべき場面・使わない方がいい場面
Webhookを使うべきなのは：
- 外部サービスのイベントをリアルタイムで受け取りたいとき
- ScheduleトリガーのPolling頻度が高くなりすぎてAPIレートリミットにかかるとき
- 外部サービス側がWebhook通知に対応しているとき
逆に、Webhookが向いていないのは：
- 外部サービスがWebhookに対応していないとき（その場合はPollingやScheduleで対応する）
- セルフホスト環境で外部からのアクセスを受け付けられないとき
Webhookは設定できれば強力だが、「テスト用とProduction URLを使い分ける」という概念が最初わかりにくい。ここさえ理解できれば、あとは思ったより簡単に動く。
合わせて読みたい
GitHubのWebhook機能についての詳細はGitHub 公式ドキュメント（日本語版）も参考にしてほしい。
※本記事の情報は2026年4月時点のものです。n8nのUIはバージョンアップで変更されることがあります。
コメント