Webhookのセキュリティ対策は何ですか？

①シグネチャ検証：送信元が正規サービスであることを確認（HMAC-SHA256等）②秘密鍵のヘッダー検証③HTTPSによる通信暗号化④IPアドレスホワイトリスト（可能であれば）⑤タイムスタンプ検証（リプレイ攻撃防止）が主要な対策です。GitHubのwebhookシークレットは必ず設定してください。

Webhook | 用語集 | IT/AIエンジニア　野口真一

Q: Webhookとは何ですか？

Webhookはイベントが発生した時に自動的に指定のURLにHTTP POSTリクエストを送信する仕組みです。GitHubへのプッシュ時にCIを起動、Stripeでの決済完了時にシステムを更新、Slackへの通知送信などが代表例です。プル型API（ポーリング）と異なり、変化があった時だけデータが届くプッシュ型の通知です。

Q: WebhookとAPIはどう違いますか？

API（REST API等）はクライアントが能動的にリクエストする「プル型」です。Webhookは外部サービスが変化を能動的に通知してくれる「プッシュ型」です。APIは必要な時にデータを取得でき、Webhookはリアルタイム通知に向いています。状態変化をリアルタイムに把握したい場合はWebhookが効率的です。

Webhookとは

Webhookは、特定のイベントが発生した際に自動的にHTTPリクエストを送信する仕組みです。「逆向きのAPI」や「HTTPコールバック」とも呼ばれ、リアルタイムでの情報共有、システム間連携、自動化処理に活用されます。

従来のポーリング方式とは異なり、イベント発生時に即座に通知を送信するため、効率的でリアルタイムな連携が可能です。現代のWebサービス統合において不可欠な技術となっています。

「Webhook」という名称は、Web（Webサービス）とHook（プログラムの特定の処理に割り込んで別の処理を実行させる「フック」の仕組み）を組み合わせた造語です。2007年前後にJeff Lindsay氏が提唱したとされ、以降GitHub、Stripe、Shopify、Slack、Twilioなど、SaaS型サービスの標準的な外部連携手段として広く定着しました。

一般的なREST APIが「クライアントがサーバーに問い合わせる」プル型のやり取りであるのに対し、Webhookは「イベントの発生元となるサーバー側が、あらかじめ登録されたクライアント側のURLへ能動的にデータを送りつける」プッシュ型の仕組みである点が最大の特徴です。

Webhookの仕組み

基本的な流れ

1. サービスA（送信側）でイベントが発生
2. 事前に登録されたWebhook URLに対してHTTP POSTリクエストを送信
3. サービスB（受信側）がリクエストを受信し、適切な処理を実行
4. 処理結果に応じてHTTPレスポンスを返却

ペイロード

WebhookのHTTP POSTリクエストには、イベントの詳細情報がJSON形式で含まれます。イベントの種類、発生時刻、関連するデータなどが送信されます。

認証・セキュリティ

多くのWebhookサービスでは、HMAC署名、IPアドレス制限、HTTPSの使用など、セキュリティ機能を提供しています。これにより、正当なWebhookリクエストであることを検証できます。

配信の順序性・再送・タイムアウト

Webhookは「少なくとも1回は届く（at-least-once）」設計が一般的で、ネットワーク不調や受信側の一時的な障害に備え、送信元サービスが再送（リトライ）を行うことが多くあります。例えばStripeは指数バックオフ方式で一定期間にわたり再送を試みる仕様になっており、GitHubは管理画面の「Recent Deliveries」から失敗した配信を手動で再送（Redeliver）できます。多くのサービスは受信側のレスポンスが数秒〜30秒程度返らない場合にタイムアウトと判断するため、重い処理は非同期化し、まず200 OKを即座に返してから裏側でバッチ処理する設計が定石です。

また複数のイベントが連続して発生した場合、到達順序は保証されないケースが多いため、イベントに含まれるタイムスタンプやシーケンス番号を確認し、アプリケーション側で順序を整えるロジックが必要になる場面もあります。

署名検証の実装例

受信したWebhookが正規の送信元から届いたものかを検証するには、送信元が付与する署名ヘッダーとペイロードから自分でHMACを計算し、値が一致するかを比較します。以下はHMAC-SHA256を用いた検証処理の擬似コードです。

// 受信したペイロード（生のリクエストボディ）と
// ヘッダーの署名値を比較して検証する例
const crypto = require('crypto');

function verifySignature(payload, secret, receivedSignature) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload, 'utf8')
    .digest('hex');

  // タイミング攻撃を防ぐため定数時間比較を使用する
  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(receivedSignature)
  );
}

GitHubは「X-Hub-Signature-256」ヘッダー、Stripeは「Stripe-Signature」ヘッダー（タイムスタンプとハッシュ値を含む形式）、Shopifyは「X-Shopify-Hmac-SHA256」ヘッダーというように、サービスごとにヘッダー名や検証手順が微妙に異なります。実装時は各サービスの公式ドキュメントで具体的な検証方法を必ず確認してください。

主な活用事例

決済システム

オンライン決済の完了、失敗、キャンセルなどのイベントを受信し、注文状況の更新、在庫管理、顧客への通知などを自動化できます。

CI/CD パイプライン

GitHubなどのソースコード管理システムから、コミット、プルリクエスト、マージなどのイベントを受信し、自動的にビルドやデプロイを実行できます。

コミュニケーションツール

Slack、Teams、Discordなどのチャットツールにリアルタイムで通知を送信し、チームメンバーに重要な情報を共有できます。

顧客管理

CRMシステムとの連携により、顧客情報の更新、営業活動の記録、マーケティングの自動化を実現できます。

IoT・監視システム

IoTデバイスやサーバー監視ツールで閾値超過・異常検知が発生した際に、Webhook経由でオペレーターへ即座にアラートを送信したり、自動復旧スクリプトを起動したりする用途にも使われます。監視ツールとチャットツール、インシデント管理ツールをWebhookで繋ぐことで、障害検知から一次対応までの時間を短縮できます。

Webhookのメリットとデメリット

メリット

最大の利点はリアルタイム性と効率性です。ポーリング（定期的な問い合わせ）と異なり、イベントが実際に発生した瞬間にだけ通信が発生するため、無駄なリクエストを送り続ける必要がなく、APIのレート制限にも抵触しにくくなります。また実装自体は「決められたURLでHTTP POSTを受け取るエンドポイントを用意するだけ」とシンプルで、WebSocketのような常時接続や専用プロトコルを必要としません。

デメリット・制約

一方で、受信側は常時稼働してリクエストを受け付けられるパブリックなエンドポイントを用意する必要があり、社内ネットワークやローカル開発環境からは直接受信できません（この制約を回避するためngrokなどのトンネリングツールが使われます）。また前述の通り再送により同じイベントが重複して届く可能性があるため、受信側で冪等性を担保する設計がほぼ必須になります。加えて、送信側のサービス障害や一時的なネットワーク分断が起きた場合、通知が欠落・遅延するリスクもゼロではありません。金融取引のような厳密な整合性が求められる処理では、Webhook通知をあくまで「トリガー」として扱い、必ずAPIへの問い合わせで最新状態を再確認する設計にするのが実務での定石です。

Webhookを提供するサービス

GitHub

プッシュ、プルリクエスト、イシュー、リリースなど、様々なイベントに対してWebhookを設定できます。

Stripe

支払い処理、返金、チャージバック、サブスクリプションの変更など、決済関連のイベントを通知できます。

Slack

メッセージの投稿、チャンネルの作成、ファイルの共有など、Slack内のイベントを外部システムに通知できます。

Mailchimp

メール配信、購読者の登録・解除、キャンペーンの結果など、メールマーケティング関連のイベントを通知できます。

混同されやすい用語・類似技術との違い

Webhookは「サーバー間でイベントをプッシュ通知する」仕組みですが、似た目的を持つ技術がいくつかあり、実務でも混同されがちです。それぞれの違いを整理します。

技術	通信方向	接続の持続性	主な用途
Webhook	サーバー→サーバー（一方向・都度接続）	イベント発生時のみ短時間接続	外部サービス間のイベント通知
REST API（ポーリング）	クライアント→サーバー（都度問い合わせ）	リクエストごとに接続・切断	必要な時にデータを取得する汎用連携
WebSocket	双方向	常時接続を維持	チャット、リアルタイムゲーム、価格更新など高頻度な双方向通信
SSE（Server-Sent Events）	サーバー→ブラウザ（一方向）	常時接続を維持	ブラウザへの通知配信、進捗表示のストリーミング
メッセージキュー（Kafka、Amazon SQSなど）	非同期・仲介経由	キューが永続化して仲介	社内システム間の大量・高信頼なイベント連携

特にWebSocketとの違いは実務でも質問されやすいポイントです。WebSocketはクライアントとサーバーの間で常時接続を維持し双方向にデータをやり取りできるのに対し、Webhookはイベントが発生するたびに都度HTTPリクエストを送るだけで、接続を維持し続ける必要がありません。チャットアプリのようにミリ秒単位で双方向にやり取りしたい場合はWebSocket、決済完了やデプロイ完了のように「発生頻度が低く、通知さえ届けばよい」イベントはWebhookが適しています。

また社内マイクロサービス間の連携では、Webhookのような外部公開エンドポイント経由ではなく、KafkaやAmazon SQS、RabbitMQといったメッセージキュー・ブローカーを使うのが一般的です。メッセージキューはブローカーがメッセージを永続化するため、受信側が一時停止していても後から確実に処理でき、配信保証や順序制御の面でWebhookより堅牢に設計しやすいという特徴があります。一方でセットアップの手軽さでは、URLを1つ登録するだけで連携できるWebhookに軍配が上がります。

実装時の注意点

冪等性の確保

同じWebhookイベントが複数回送信される可能性があるため、処理の冪等性を確保する必要があります。重複処理を防ぐメカニズムを実装することが重要です。

エラーハンドリング

Webhookリクエストの受信に失敗した場合のリトライ機構、エラーログの記録、アラート機能を実装する必要があります。

重複排除とデッドレターの扱い

冪等性を実装する具体的な方法としては、各Webhookイベントに含まれる一意のイベントID（例：Stripeのidフィールドや、GitHubのX-GitHub-Deliveryヘッダー）を受信側のデータベースやキャッシュに一定期間保存しておき、同じIDのイベントを再受信した場合は処理をスキップする方式が一般的です。また、何度リトライしても処理に失敗し続けるイベントについては、デッドレターキュー（処理不能イベント専用の保管領域）に退避させ、後から人手で原因調査・再処理できるようにしておくと運用が安定します。

レスポンス時間

Webhookリクエストに対して迅速にレスポンスを返す必要があります。時間のかかる処理は非同期で実行し、すぐに200 OKを返却することが推奨されます。

セキュリティ

HMAC署名の検証、IPアドレスの制限、HTTPSの使用など、適切なセキュリティ対策を実装する必要があります。

開発とテスト

開発環境

ngrok、localtunnelなどのツールを使用して、ローカル開発環境でWebhookをテストできます。

テスト用サービス

Webhook.site、RequestBin、Postmanなどのツールを使用して、Webhookリクエストの内容を確認できます。

監視・ログ

Webhookの送受信状況を監視し、エラーやタイムアウトの発生を追跡できるログ機能を実装することが重要です。

2025〜2026年の最新動向

Webhook仕様の標準化の動き

従来Webhookはサービスごとにペイロード形式や署名検証方式がバラバラで、開発者は連携先ごとに個別対応を強いられてきました。この課題を解決するため、Webhook配信基盤を手がけるSvix社などが中心となって提唱する「Standard Webhooks」という共通仕様の採用が広がりつつあります。HMAC-SHA256署名、リプレイ攻撃対策のタイムスタンプ検証、標準的なヘッダー名などを定めたオープン仕様で、複数のSaaS事業者が対応を検討・採用する段階にあります。

AIエージェント連携での活用拡大

LLM（大規模言語モデル）を用いたAIエージェントが普及する中で、時間のかかる非同期処理（大量データの解析、画像・動画生成、バッチ処理など）の完了通知としてWebhookを使うパターンが一般的になってきています。エージェントが処理を依頼した後、都度ポーリングでステータスを確認する代わりに、処理完了時にWebhookで結果URLやステータスを受け取る設計は、APIコール数を抑えつつ応答性を保てるため、AI系API（画像生成、音声認識、動画解析など）を提供するサービスで採用が進んでいます。

ノーコード・iPaaSでの定着

Zapier、Make（旧Integromat）、n8nといったiPaaS（Integration Platform as a Service）ツールでは、Webhookが「トリガー」の中核的な仕組みとして定着しており、非エンジニアでもGUI操作だけでWebhook受信URLを発行し、複数サービスを連携できる環境が一般的になっています。ノーコード開発の広がりとともに、Webhookは以前にも増して「エンジニア以外も扱う技術」になりつつあります。

セキュリティ要件の厳格化

Webhookエンドポイントを狙った偽装リクエストや再送を悪用した攻撃への警戒から、署名検証を必須とするサービスが増えており、加えてIPアドレス制限やmTLS（相互TLS認証）などの追加的な防御をオプションで提供するサービスも増加傾向にあります。実務では「署名検証をしていないWebhookエンドポイントは原則作らない」という考え方が定石になりつつあります。

よくある質問（FAQ）

Q1. Webhookとは何ですか？

A. Webhookはイベントが発生した時に自動的に指定のURLへHTTP POSTリクエストを送信する仕組みです。GitHubへのプッシュ時にCIを起動する、Stripeでの決済完了時にシステムを更新する、Slackへ通知を送るなどが代表例です。クライアントが問い合わせるプル型のAPIと異なり、変化があった時だけデータが届くプッシュ型の通知である点が特徴です。

Q2. Webhookのセキュリティ対策は何をすればよいですか？

A. ①シグネチャ検証（HMAC-SHA256などで送信元が正規サービスであることを確認）②秘密鍵・シークレットの安全な管理③HTTPSによる通信の暗号化④可能であれば送信元IPアドレスのホワイトリスト化⑤タイムスタンプ検証によるリプレイ攻撃対策、の5点が基本です。GitHubやStripeなどでWebhookシークレットを発行できる場合は、必ず設定して署名検証を行ってください。

Q3. WebhookとAPIはどう違いますか？

A. REST APIなどの一般的なAPIは、クライアントが必要な時に能動的にリクエストする「プル型」です。Webhookは外部サービス側が変化を検知して能動的に通知してくれる「プッシュ型」です。任意のタイミングでデータを取得したい場合はAPI、状態変化をリアルタイムに把握したい場合はWebhookが効率的、という使い分けが基本になります。

Q4. Webhookが届かない・失敗する時はどう対処すればよいですか？

A. まず送信元サービスの管理画面でWebhookの配信ログ・エラーコードを確認します（GitHubの「Recent Deliveries」やStripeの「Webhookログ」など）。よくある原因は、受信側エンドポイントのタイムアウト、TLS証明書の期限切れ、ファイアウォールによるアクセス拒否、レスポンスコードが200系以外を返しているなどです。開発中はngrokなどでローカル環境に一時的な公開URLを発行し、Webhook.siteなどで実際のペイロードを確認しながらデバッグすると原因を特定しやすくなります。

Q5. WebhookとWebSocketはどちらを使うべきですか？

A. 発生頻度が低く「イベントが起きたことだけ通知できればよい」用途（決済完了、デプロイ完了、フォーム送信など）にはWebhookが適しています。逆にチャットや価格のリアルタイム更新のように高頻度・低遅延で双方向にやり取りしたい用途にはWebSocketが向いています。両者は競合技術というより、目的に応じて使い分ける関係にあります。

外部リンク・参考資料

まとめ

Webhookは、リアルタイムでの情報共有とシステム間連携を実現する重要な技術です。ポーリング型のAPIに比べて効率的で柔軟な統合を可能にし、現代のWebサービス開発において不可欠な要素となっています。一方で、パブリックなエンドポイントの用意、冪等性の担保、署名検証といった実装上の注意点もあるため、適切な実装とセキュリティ対策を行うことで、信頼性の高いシステム連携を構築できます。WebSocketやメッセージキューなど類似技術との違いを理解した上で、要件に合った技術を選択することが重要です。

Webhook