Webhookとは？仕組みと実装方法・セキュリティ対策を解説

Webhookとは

Webhook（ウェブフック）とは、特定のイベントが発生した際に、あらかじめ登録したURLへHTTPリクエストを自動送信する仕組みです。「逆引きAPI」や「HTTPコールバック」とも呼ばれます。例えば決済が完了したとき、GitHubにコードがプッシュされたとき、ストレージにファイルがアップロードされたときなど、イベントの発生を別のサービスにリアルタイムで通知する際に活用されます。

ポーリングとWebhookの違い

データの変更を検知する方法として、従来は「ポーリング」が広く使われていました。ポーリングとは、クライアントが一定間隔でサーバーに「変更がありましたか？」と問い合わせ続ける方式です。

ポーリングの問題点は、変更がない場合でもリクエストを繰り返すためサーバー・クライアント双方にとって無駄なリソース消費が生じることです。1秒ごとにポーリングしても、実際に変更が起きるのは1時間後かもしれません。

Webhookはこの問題を解決します。サーバーはイベントが発生した瞬間だけ通知を送るため、不要なリクエストが発生しません。リアルタイム性が高く、システム全体の負荷を大幅に削減できます。

Webhookの仕組み

Webhookの基本的な流れは以下の通りです。

1. 受信側（自分のサービス）がWebhookを受け取るためのHTTPエンドポイントを用意する
2. 送信側（外部サービス）にそのURLを登録する
3. 外部サービスでイベントが発生すると、登録されたURLにHTTP POSTリクエストを送る
4. 受信側はリクエストを処理し、200 OKを速やかに返す

重要なポイントは「速やかにレスポンスを返す」ことです。Webhookを受け取ったら即座に200 OKを返し、重い処理は非同期のキュー（RabbitMQ・SQS等）に委ねるのがベストプラクティスです。レスポンスが遅いと送信側がタイムアウトと判断して再送し、重複処理の原因になります。

Webhookのセキュリティ対策

1. 署名検証（Signature Validation）

最重要のセキュリティ対策です。多くのWebhookプロバイダー（Stripe・GitHub・Shopify等）は、ペイロードをシークレットキーでHMAC-SHA256署名し、リクエストヘッダーに署名値を含めます。受信側はシークレットキーで同じ計算を行い、ヘッダーの値と一致するか検証します。これにより、なりすましリクエストを排除できます。

2. タイムスタンプ検証によるリプレイ攻撃対策

同じリクエストを後から再送するリプレイ攻撃を防ぐため、タイムスタンプを検証します。受け取ったリクエストのタイムスタンプが現在時刻から5分以上前であれば拒否するという処理を実装することで対策できます。

3. HTTPSの使用

Webhookエンドポイントには必ずHTTPS（TLS）を使用してください。平文のHTTPでは通信内容が盗聴される可能性があります。

4. IPアドレス制限

Webhookを送信するサービスが送信元IPアドレスを公開している場合は、そのIPからのみ受け付けるよう制限できます。

冪等性（べきとうせい）の確保

Webhookは通信障害などで同じイベントが複数回送信される可能性があります。同じWebhookを2回処理しても結果が変わらない「冪等性」を確保することが重要です。一般的な対策はWebhookのイベントIDをデータベースに記録し、処理済みのIDが再度来た場合はスキップする方法です。

実装時のよくある失敗

• レスポンスが遅い：重い処理をWebhookハンドラー内で同期的に行うと、タイムアウトが発生して再送ループに陥る
• 署名検証をしていない：なりすましリクエストを処理してしまうリスク
• 冪等性未対応：重複処理による二重決済や二重登録が発生
• エラーを200で返す：処理に失敗しても200を返すと、送信側が成功と判断して再送されない

主要サービスのWebhook活用例

• Stripe：決済完了・返金・サブスクリプション更新などのイベント通知
• GitHub：プッシュ・PR作成・マージなどのリポジトリイベント（CI/CDのトリガーに活用）
• Slack：メッセージ投稿・ボタンクリックなどのインタラクション
• LINE：メッセージ受信・友だち追加などのチャネルイベント

まとめ

Webhookはポーリングの非効率を解消し、イベント駆動アーキテクチャを実現する重要な仕組みです。実装の際は署名検証・冪等性・非同期処理の3点を必ず押さえてください。正しく実装することでシステムの応答性と信頼性が大幅に向上します。