Webhookって何？
Webhookとは、「特定のイベントが発生したときに、自動で通知を送ってくれる仕組み」です。
イメージしづらいかもしれませんが、WebhookたとえばTeamsやSlackで、GitHubのCIが成功した際に自動で通知を送る仕組みがこれにあたります。あらかじめ通知先となるURLを登録しておき、イベントが発生したタイミングでそのURLに対してHTTPリクエストを送信します。
Webhookを利用することで、人が操作しなくてもシステム同士が自動で連携できるようになります。APIが「取りに行く（Pull型）」仕組みだとすると、Webhookは「送られてくる（Push型）」仕組みと考えると理解しやすいです。
使われる場所
先ほどはTeamsやSlackとGitHubを用いた例を紹介しましたが、Webhookは決済の世界でも広く使われています。特に分かりやすいのが「決済完了通知」です。
例えば、アプリなどで商品を購入した際に、読み込み中の画面が表示された後、「決済が完了しました」と表示される流れを体験したことがあるかと思います。その裏側では、Webhookが重要な役割を果たしています。
流れは次のとおりです。
1, ユーザーが商品を購入
2, アプリが決済サービスに支払いを依頼
3, 決済サービス側で決済処理が実行される
4, 決済完了後、決済サービスがECサイトのサーバーにWebhookを送信
5, ECサイト側で注文ステータスを「支払い済み」に更新
6, 画面に「決済完了」と表示される
ここで重要なのは、ECサイト側が決済結果を“取りに行っている”わけではないという点です。決済サービス側から「決済が完了しました」という通知（Webhook）が送られてくることで、注文情報が更新されます。
この仕組みによって、たとえユーザーが途中で画面を閉じたとしても、決済が完了していれば正しく注文状態を反映させることができます。Webhookは単なる通知ではなく、システム間のデータ整合性を保つ重要な役割も担っています。
気をつけなければいけないこと
Webhookを利用する際には、セキュリティ面に十分注意が必要です。Webhookは外部からHTTPリクエストを受け取る仕組みであるため、なりすましや改ざんのリスクがあります。
そのため、多くのサービスでは署名付きリクエストが採用されており、受信側で署名を検証することが重要です。送信元が正規のサービスであることを確認せずに処理してしまうと、不正なデータを受け入れてしまう可能性があります。
また、同じ通知が複数回送信される場合もあるため、重複処理を防ぐための冪等性の確保も必要です。たとえば、すでに「支払い済み」となっている注文を再度更新しないようにする設計が求められます。
実装方法
実装の手順は比較的シンプルです。
まず、Webhookを受信するためのエンドポイント（URL）を自社サーバーに用意します。次に、利用するサービスの管理画面などでそのURLを登録します。イベントが発生すると、そのURLに対してPOSTリクエストが送信されます。
受信側ではリクエストボディをパースし、必要な処理を実行します。このとき、署名の検証やリクエスト内容のバリデーションを行い、安全性を確保します。処理が正常に完了したら、HTTPステータス200を返します。
例として、SlackとGitHub Actionsを連携させる場合の流れは次のとおりです。
1, SlackでIncoming Webhooksを設定し、Webhook URLを発行する
2, GitHubの「Secrets and variables」にSlackのWebhook URLを登録する
3, GitHub Actionsのworkflowファイルに、ビルド結果をSlackへ通知する処理を記述する
4, CIが実行されると、結果がSlackへ通知される
このように、WebhookはURLを介してシステム同士を連携させるシンプルな仕組みです。
最後に
Webhookは、イベントをきっかけにシステム同士を自動で連携させる仕組みです。主に通知連携やイベント駆動処理に利用され、リアルタイム性の高いアーキテクチャを実現できます。
一方で、署名検証や冪等性の確保など、セキュリティと安定性を意識した設計が不可欠です。特に決済のような重要な処理では、実装次第で重大な影響を及ぼす可能性もあります。そのため、利用するサービスの公式ドキュメントを十分に読み込み、運用まで見据えた設計を行うことが重要です。
Webhookはシンプルな仕組みでありながら、設計力が問われる技術要素の一つだ考えています。