スマートフォンに荷物の配達完了通知が届いたり、ネットショップで支払いが完了すると注文処理が始まったりしますよね。
このように、あるシステムで起きた出来事をきっかけに、別のシステムへすぐ知らせる仕組みとしてよく使われるのがWebhook（ウェブフック）です。
Webhookは「Web」と「Hook（引っかける仕組み）」を組み合わせた言葉です。少し難しそうな名前ですが、考え方は「何かが起きたら、登録された宛先へ自動で連絡する」というシンプルなものです。
今回は、Webhookの仕組みと使われる場面、そしてポーリングとの違いを分かり易く解説していきます！
Webhookとはイベントの発生を自動で知らせる仕組み
Webhookとは、あるシステムで特定のイベントが発生した時に、あらかじめ登録されたURLへデータを送信する仕組みです。
イベントの例
- 商品が購入された
- 決済が完了した
- ソースコードが更新された
- フォームに回答が送信された
こうした出来事を「イベント」と呼びます。イベントが発生すると、知らせる側のシステムが受け取る側のURLへHTTPリクエストを送ります。
たとえばインターホンを想像してみてください。家の人は、玄関に誰か来ていないかを何度も見に行かなくても、訪問者がボタンを押せば音で気付けます。Webhookも、何かが起きた時に相手から知らせてもらう仕組みです。
Webhookが動く流れ
Webhookの基本的な動作は、次の4段階です。
Webhookが動く4つのステップ
- 通知先URLを登録する
受け取る側が、Webhookを受信するためのURL（Webhookエンドポイント）を用意します。 - イベントが発生する
購入、決済、更新など、通知対象にした出来事が発生します。 - HTTPリクエストが送信される
知らせる側から通知先URLへ、イベントの種類や内容を含むデータが送られます。HTTPのPOSTメソッドとJSON形式がよく使われます。 - 受信側が処理する
データを確認し、通知の表示、データベースの更新、メール送信などの処理を実行します。
送信されるデータはサービスによって異なりますが、次のようなイメージです。
{
"event": "payment.completed",
"order_id": "A12345",
"amount": 5000
}この例では、「注文番号A12345の5,000円の支払いが完了した」という情報を受け取れます。受信側は、その内容をもとに在庫を減らしたり、購入者へメールを送ったりできます。
Webhookとポーリングの違い
Webhookと一緒に覚えておきたいのがポーリングです。どちらもシステム間で変化を知るために使いますが、確認する側が異なります。
| 比較項目 | Webhook | ポーリング |
|---|---|---|
| 連絡する側 | イベントが起きた側から知らせる | 情報が欲しい側から問い合わせる |
| タイミング | イベント発生時 | 一定の間隔 |
| 即時性 | 高い | 問い合わせ間隔に左右される |
| 不要な通信 | 比較的少ない | 変化がなくても問い合わせる |
| 受信側の条件 | 通知を受け取れるURLが必要 | 必要な時だけ問い合わせることも可能 |
| 障害時の考慮 | 再送や取りこぼし対策が必要 | 次の問い合わせで取得できる場合がある |
ポーリングは「荷物が届いた？」と何度も確認する
ポーリングでは、受け取る側が「新しい情報はありますか？」と一定間隔で問い合わせます。まだ荷物が届いていなくても、配送状況のページを何度も更新するイメージですね。
Webhookは「荷物が届いたら通知してもらう」
Webhookでは、イベントが発生した側から連絡が来ます。荷物が配達された瞬間に通知が届くイメージです。変化がない時には通信しないため、無駄な問い合わせを減らせます。
「それなら、全部Webhookにすれば良いのでは？」と思うかもしれません。しかし、通知先が一時的に停止しているとWebhookを受け取れないことがあります。また、そもそも相手のサービスがWebhookに対応していない場合もあります。
Webhookとポーリングは、どちらかが常に優れているわけではありません。システムの目的や制約に合わせた使い分けが大切です。
Webhookが使われる具体例
決済サービスとネットショップの連携
クレジットカードの決済が完了したら、決済サービスからネットショップへWebhookを送ります。ショップ側は通知を受けて、注文を「支払い済み」に変更できます。
チャットツールへの通知
問い合わせフォームに新しい回答が届いたら、Webhookを利用してチャットツールへ通知できます。担当者がフォームを何度も確認しなくても、新着情報に気付けます。
ソフトウェア開発の自動化
GitHubなどでソースコードが更新された時にWebhookを送り、自動テストやデプロイを開始できます。「コードの更新」というイベントをきっかけに、後続作業を自動化するわけですね。
Webhookのメリット
Webhookのメリット
- 変化をすばやく検知できる
イベント発生時に通知されるため、ほぼリアルタイムに後続処理を始められます。 - 無駄な通信を減らせる
変化がない時に何度も問い合わせる必要がありません。 - サービス間の処理を自動化しやすい
決済完了、フォーム回答、コード更新などを別の処理につなげられます。 - 監視対象が増えても効率化しやすい
多数の対象を定期的に問い合わせるより、発生したイベントだけを受け取るほうが負荷を抑えられる場合があります。
Webhookを使う時の注意点
送信元が正しいか確認する
WebhookのURLが外部に公開されていると、第三者から偽のデータが送られる可能性があります。サービスが提供する署名を検証し、本当に正しい送信元から届いたデータか確認することが重要です。
同じ通知が複数回来ても問題ないようにする
送信側は、応答を受け取れなかった時に同じWebhookを再送する場合があります。同じ決済完了通知を2回受け取っても、商品を2回発送しないようにしなければなりません。
そのため、イベントIDを記録して処理済みか確認するなど、同じ通知を複数回処理しても結果が変わらない冪等性（べきとうせい）を意識します。
すばやく正常応答を返す
受信後に重い処理をすべて終えてから応答すると、送信側がタイムアウトすることがあります。まず受信を確認して正常なHTTPステータスコードを返し、時間のかかる処理はキューなどを使って後から実行する設計がよく使われます。
通知の取りこぼしに備える
ネットワーク障害や受信側の停止によって、通知を受け取れない可能性があります。送信側の再送機能を確認するほか、重要なデータでは定期的な照合処理を組み合わせると安心です。
Webhookとポーリングはどう使い分ける？
最後に、向いている場面を整理しましょう。
| Webhookが向いている場面 | ポーリングが向いている場面 |
|---|---|
| 変化をすぐに知りたい | 一定間隔で確認できればよい |
| イベントが時々発生する | 定期的に最新状態をまとめて取得したい |
| 相手がWebhookに対応している | 相手がWebhookに対応していない |
| 外部からアクセス可能な受信先を用意できる | 受信先を外部公開したくない、または用意できない |
実際のシステムでは、Webhookを中心に使いながら、通知の取りこぼしを確認するためにポーリングも併用することがあります。お互いの弱点を補う組み合わせですね。
まとめ
Webhookのまとめ
- Webhookは、イベント発生時に登録済みURLへ自動でデータを送る仕組み
- ポーリングは受け取る側が定期的に問い合わせ、Webhookは発生した側から知らせる
- Webhookは即時性が高く、不要な通信を減らしやすい
- 署名検証、再送、冪等性、タイムアウトへの対策が必要
- 目的に応じてWebhookとポーリングを使い分け、併用することも大切
Webhookは、システム同士をつないで処理を自動化する時に、とても便利な仕組みです。
家族に「夕飯できた？」と5分おきに聞くのがポーリングなら、「できたら呼んで！」とお願いするのがWebhook、と考えると分かりやすいかもしれませんね（笑）
ポーリングの詳しい仕組みは、以下の記事でも解説しています。併せて読んでみてください！
以上です！