API・メッセージング

Webhook うぇぶふっく

イベント駆動コールバックHTTP POSTREST API通知リアルタイム連携

Webhookについて教えて

簡単に言うとこんな感じ！

「何かあったら自動で連絡してくる仕組み」だよ！自分でわざわざ確認しに行かなくても、相手のシステムが「さっき注文が入ったよ！」って向こうから知らせてくれるんだ。宅配の不在票じゃなくて、リアルタイムで電話してくれるイメージ！

Webhookとは

Webhookとは、あるシステムで特定のイベント（出来事）が発生したときに、あらかじめ指定したURLへ自動的にHTTP通知を送る仕組みのことです。「フック（hook＝引っかかり）をウェブ上に仕掛けておく」というイメージで、イベントが起きた瞬間に処理が走ります。イベント駆動型の連携手段として、現代のクラウドサービスやSaaSに広く採用されています。

従来のAPI連携では、「今どういう状態？」と自分から定期的に問い合わせるポーリングという方法が一般的でした。しかしWebhookは逆で、「何か起きたら向こうから教えてもらう」プッシュ型の通知です。これにより、無駄なリクエストを減らしながらリアルタイムに近い連携が実現できます。

実務では、ECサイトへの注文通知、GitHubへのコードプッシュをトリガーにしたCI/CDの自動実行、決済完了後の在庫システム更新など、システム間の自動連携に欠かせない技術です。ノーコードツールのZapierやMake（旧Integromat）でもWebhookは中心的な役割を担っています。

Webhookの仕組みと構造

Webhookの動作は「仕掛けておいて、来たら受け取る」という3ステップで理解できます。

ステップ	誰が動く	何をするか
① URL登録	受け取る側（あなたのシステム）	「このURLに通知して」と送信側に伝える
② イベント発生	送信側サービス	注文・決済・プッシュなど特定の出来事が起きる
③ HTTP POSTで通知	送信側サービス	登録URLへJSONデータを自動送信する

【ポーリング（従来型）】
あなたのシステム ──「今どう？」──→ 外部サービス
あなたのシステム ←──「変化なし」── 外部サービス
あなたのシステム ──「今どう？」──→ 外部サービス  ← 無駄なリクエスト
あなたのシステム ←──「注文あり！」── 外部サービス

【Webhook（プッシュ型）】
あなたのシステム ←──「注文入ったよ！」── 外部サービス ← イベント時だけ通知

Webhookのデータ例（JSON）

実際に送られてくるデータはこのような形式です。

{
  "event": "payment.completed",
  "timestamp": "2026-04-09T10:30:00Z",
  "data": {
    "order_id": "ORD-20260409-001",
    "amount": 12800,
    "currency": "JPY",
    "customer_email": "taro@example.com"
  }
}

受け取り側のシステムは、このJSONを解析して「決済完了したので在庫を減らす」「出荷指示を出す」などの後続処理を実行します。

覚え方

「Web上に仕掛けた釣り針（hook）」 — イベントという魚がかかったら自動で引き上げられる！

ポーリングは「毎分魚がいるか確認しに行く」、Webhookは「魚がかかったら竿が自動で動く」釣り自動化システム、と覚えるとイメージしやすいです。

歴史と背景

2007年 — Jeff Lindsayが「Webhook」という概念と用語を提唱。当時はまだ一般的ではなかった
2010年前後 — GitHub・PayPalなど主要サービスがWebhookを採用し、開発者コミュニティに普及し始める
2012年〜 — Stripeが決済通知にWebhookを全面採用。「決済→業務システム自動連携」の定番手段として定着
2015年〜 — SlackやTrelloなどSaaSの普及とともに、ビジネス現場での利用が急拡大。ノーコードツールとの組み合わせも増加
2020年〜 — Zapier・Make・n8nなどの自動化プラットフォームがWebhookをコア機能として標準搭載。エンジニア不要のシステム連携が一般化

Webhook vs ポーリング vs WebSocket

Webhookに似た「リアルタイム連携」の手段と比較してみましょう。

比較項目	Webhook	ポーリング	WebSocket
通信の向き	サーバー→クライアント（プッシュ）	クライアント→サーバー（プル）	双方向
リアルタイム性	高い	低〜中（間隔次第）	非常に高い
サーバー負荷	低い	高い（無駄リクエスト多）	接続維持コストあり
実装の簡単さ	比較的簡単	簡単	やや複雑
向いている用途	非同期イベント通知	状態監視・簡易連携	チャット・ゲームなどリアルタイム
典型的な使用例	決済通知・CI/CD	在庫確認・ステータス監視	チャット・株価表示

セキュリティの注意点

Webhookは「URLさえ知っていれば誰でも送れる」ため、受け取る側のセキュリティ対策が重要です。

リスク	対策
なりすまし（偽の送信元）	署名検証（HMAC-SHA256など）で送信元を確認する
URLの流出・悪用	Webhook URLをシークレットとして管理し、ログに残さない
大量送信による過負荷	レートリミット・冪等性（同じリクエストを複数回受けても安全）の確保
処理の失敗	送信側のリトライに対応できるよう、冪等なAPIとして実装する

多くのサービス（Stripe・GitHubなど）は、シークレットトークンを使った署名をリクエストヘッダーに付与します。受け取り側はこの署名を検証することで、正規の送信元からのリクエストかどうかを確認できます。

規格・RFC番号	内容
RFC 7230	HTTP/1.1メッセージ構文とルーティング（WebhookはHTTP POSTで送信される）
RFC 8259	JSONデータ形式（Webhookのペイロードはほぼ必ずJSON）
RFC 2104	HMAC（Webhookの署名検証に広く使われるアルゴリズム）