Webhook
Webhook
Webhookとは、イベントが発生したときに、登録されたURLへHTTPリクエストを送り、他のシステムに知らせる仕組みです。通知の速さ、再送、順序の保証は提供サービスによって異なります。
🐾 猫で例えると？
何かを見つけた猫が、その都度飼い主へ知らせに来るイメージです。飼い主が何度も様子を見に行くのがポーリング、猫から知らせるのがWebhook。ただし留守なら知らせが届かないこともあり、通知の失敗への備えが必要です。
💻 IT現場における「Webhook」とは？
例えばGitHubへコードの変更を送るPushをきっかけに、外部のシステムへ通知して検証処理を始める用途があります。通知を受けた後に何をするかは受信側が実装します。自動デプロイやチャット通知が、すべて必ずWebhookだけで実現されるわけではありません。
変更の有無を繰り返し問い合わせるポーリングに比べ、不要な確認を減らせます。一方、配送の遅延や失敗、重複が起こる場合があり、即時・一度だけ・順番どおりの配信を無条件には期待できません。
⚠️ Webhookの仕組みと注意点
Webhookは非常に軽量で強力な仕組みですが、誰からでもアクセスできる公開URL（エンドポイント）を用意して待つという性質上、セキュリティ面の防御策が極めて重要になります。
セキュリティ検証用のHTTPヘッダー情報の例
以下はGitHubの通知で使われるヘッダー名を基にした、説明用の断片です。省略された値なので、このまま検証を通すことはできません。
POST /webhooks/github HTTP/1.1
Content-Type: application/json
X-GitHub-Event: push
X-GitHub-Delivery: 配送ごとの識別子
X-Hub-Signature-256: sha256=省略
（イベントに応じたJSON本文）GitHubの場合、共有シークレットと受信した本文の元のバイト列からHMACを計算し、署名と比較します。JSONを解析して再出力するとバイト列が変わる場合があります。HMACは本文の暗号化ではなく改ざん検知・認証のためで、重複配送の対策は配送IDなどを使って別途行います。
🛠️ Webhookを賢く使うためのポイント
実務でWebhookの受信システムを設計・構築する際は、インターネット通信の不確実性を考慮した堅牢な実装が求められます。
- リトライ（再送処理）への考慮： 受信サーバーが一時的にダウンしていると通知を取りこぼすため、送信側の再送ポリシーを確認する必要があります。
- 冪等性（べきとうせい）の確保： ネットワークの遅延などにより同じ通知が2回届くことがあるため、複数回受信してもシステムが二重処理を起こさない設計にします。
- 受理を確実にしてから応答する：署名などを確認し、必要なイベントを永続的なキューや保存先へ受理してから、提供者の制限時間内に成功応答を返します。保存前に200だけ返すと、その後の障害で通知を失うおそれがあります。
ひょっこり顔を出す茶トラのように、Webhookは出来事を相手へ知らせます。ただし、通知が遅れたり重複したりする場合もあります。署名の確認、再送への対応、重複して処理しない仕組みをそろえ、受理した通知を失わない手順で応答しましょう。