業務自動化・iPaaS・RPA

Webhookとは｜出来事が起きた瞬間に他システムへ知らせる仕組み

ServiceDock 2026年8月13日 更新 約10分で読めます
Webhookとポーリング（定期確認）は何が違うのかWebhookは安全に受け取れるのか受信側のシステムはどう設計すればよいか

Webhookは、システム側で出来事が起きた瞬間に、指定したURLへHTTPリクエストを送って知らせる仕組みです。決済の完了やフォームの送信のように、リアルタイム性が求められる連携で広く使われています。

ただし送られてくるリクエストが本物かどうかは、受信側で検証しなければ確認できません。署名の検証を省くと、第三者からのなりすましリクエストをそのまま処理してしまう危険があります。

この記事の要点

  • Webhookは出来事が起きた瞬間に送信元からリクエストが届くプッシュ型の連携方式
  • 定期的に確認しにいくポーリングと比べて、リアルタイム性が高く通信回数も少ない
  • 受信したリクエストが本物かは署名検証をしないと確認できない
  • 同じ通知が複数回届くことがあるため、受信側は冪等性を持たせる設計が要る

Webhookで何ができるのか｜プッシュ型通知の仕組み

Webhook は、送信元のシステムで出来事が起きたときに、あらかじめ登録しておいたURLへHTTPリクエストを送る仕組みです。受信側は常に待ち構えているだけで、能動的に確認しにいく必要がありません。

Webhookは受信側が「ください」と聞きに行くのではなく、送信元が「来ました」と知らせに来る。この向きの違いが、ポーリングとの本質的な差になる。

送信元システム受信側エンドポイント出来事の発生を通知即時受信確認（200 OK）数百ms以内往復 1 回 / 2 段受信確認を素早く返さないと、送信元がタイムアウトと判断して再送してくることがある。
図1 ── 注：往復回数はWebhookの受信からACK応答までの目安。

ポーリングとの違い

Webhookは通知の即時性で勝るが、受信側が公開URLを持つ必要がある。ポーリングは実装が単純だが、確認間隔の分だけ遅延する。

観点Webhookポーリング
通知の即時性出来事の直後に届く確認間隔の分だけ遅延する
通信回数出来事があったときのみ変化が無くても定期的に発生する
受信側の要件外部から到達できるURLが要る送信元への到達性は不要
表1 ── 注：実装によって細部は異なる。実際の可否は連携先の仕様に依存する。

n8n・Zapierでの使われ方

n8n や Zapier のトリガーの多くは、内部的にWebhookとして実装されています。フォームの送信や決済の完了を合図に、登録したワークフローが自動で起動します。

この節は一次情報での裏取りが未了です。 一般的なWebhook実装の解説（一次情報での裏取りは未了）（2026-08-13 記載）

Webhookでよくある失敗｜重複通知と受信確認の遅延

Webhook の実装で多い失敗は、同じ通知が複数回届くことを想定せずに処理を書くことです。送信元がタイムアウトで再送すると、受信側の処理が二重に実行されます。

重複通知への対応が無い

決済完了の通知が2回届いた場合、何も対策していなければ二重に処理が実行され、二重請求のような事故につながります。通知に含まれる一意のIDを記録し、処理済みかどうかを確認する仕組みが要ります。

受信確認の応答が遅く再送を招く

受信したリクエストの中で重い処理をすべて完了させてから応答すると、送信元のタイムアウトに間に合わず、不要な再送を招きます。受信確認は即座に返し、重い処理は非同期のキューに回す設計が安全です。

エンドポイントのURLが漏れると誰でも送信できる署名検証をしていないエンドポイントは、URLさえ知っていれば誰でも偽の通知を送り込めます。URLを秘密にするだけでなく、署名検証を必ず実装してください。
この節は一次情報での裏取りが未了です。 実運用でのヒアリングと検証（一次情報での裏取りは未了）（2026-08-13 記載）

Webhookのセキュリティ｜署名検証となりすまし対策

Webhook の受信エンドポイントは、インターネットに公開されたURLである以上、誰からでもリクエストを送れる状態にあります。送信元が本物かどうかを検証する仕組みが無ければ、なりすましを見分けられません。

署名検証の仕組み

多くのサービスは、リクエストの本文と共有の秘密鍵からハッシュ値を計算し、ヘッダーに署名として付けて送ってきます。受信側で同じ計算をして署名が一致するか確認すれば、送信元が本物であることを検証できます。

通信経路の暗号化とIPの許可リスト

  • エンドポイントはHTTPSで公開し、平文での通信を避ける
  • 送信元のIPアドレスが公開されている場合は、許可リストで絞り込む
  • 署名検証とIP制限は片方だけでなく両方を組み合わせるとより堅牢になる
この節は一次情報での裏取りが未了です。 一般的なWebhookセキュリティ実装の解説（一次情報での裏取りは未了）（2026-08-13 記載）

よくある質問

Webhookとポーリングはどちらを使うべきですか？
即時性が求められる通知（決済完了など）にはWebhookが向いています。送信元がWebhookに対応していない場合や、定期的な差分確認で十分な場合はポーリングが選択肢になります。
Webhookのリクエストが本物かどうかはどう確認しますか？
多くのサービスは、リクエストのヘッダーに署名を付けて送ってきます。受信側で共有の秘密鍵を使って署名を検証することで、なりすましのリクエストを排除できます。
同じWebhook通知が2回届くことはありますか？
送信側がタイムアウトなどで再送する仕組みを持っている場合、同じ内容の通知が複数回届くことがあります。受信側は同じ処理を二重に実行しないよう、冪等性を持たせて設計する必要があります。
n8nやZapierでWebhookはどう使われますか？
n8nやZapierのトリガーの多くはWebhookで実装されています。外部サービスで出来事が起きると、n8nやZapierが用意したURLにリクエストが届き、それを合図にワークフローが起動します。

まとめ

  • Webhookの価値は出来事が起きた瞬間に即座に通知が届くことにある
  • ポーリングと比べてリアルタイム性が高く、無駄な通信も減らせる
  • 受信側での署名検証を省くと、なりすましリクエストを受け入れてしまう
  • 通知が重複する可能性があるため、受信側は冪等性を持たせて設計する

今日から始められること

  1. 連携先がWebhookに対応しているか、署名検証の方法を確認する
  2. 受信用のエンドポイントに署名検証を実装する
  3. 同じ通知が重複しても問題ない設計（冪等性）になっているか確認する
  4. Webhookが届かなかった場合の代替手段（ポーリングでの補完）を検討する

実務で組んだWebhookのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る