Webhookとは？APIとの違いと受け取る側が気をつけること
SaaS同士を連携させようとすると、必ず出てくる言葉があります。
「この機能はWebhookに対応しています」
「APIで連携できます」
どちらも「システム同士をつなぐ仕組み」ですが、役割はまったく違います。
ひとことで言えば、こうです。
APIは「こちらから聞きにいく」。Webhookは「あちらから知らせてくる」。
この違いを理解していないと、「なぜリアルタイムに反映されないのか」「なぜ同じ通知が2回届くのか」といった問題の原因が分からなくなります。
この記事では両者の違いと、Webhookを使う際の実務的な注意点を整理します。APIそのものについては APIとは？非エンジニアにもわかるビジネス活用のポイント をご覧ください。
方向がまったく逆
最も大きな違いは「どちらから声をかけるか」です。
| API（REST API） | Webhook | |
|---|---|---|
| 通信の起点 | こちら（利用する側） | 相手（サービス側） |
| 動作 | 必要なときに取りにいく | 変化があったら送られてくる |
| たとえると | 問い合わせの電話をかける | 相手からの着信を待つ |
| 必要なもの | APIキーなどの認証情報 | 受信用のURL（公開が必要） |
| リアルタイム性 | 聞きにいった時点の情報 | 発生した時点で届く |
ポーリングという非効率
Webhookがない場合、変化を知るにはAPIを繰り返し呼ぶしかありません。これをポーリングと呼びます。
たとえば「注文が入ったら通知したい」という要件を、5分ごとのポーリングで実現すると——
- 1日あたり288回のAPI呼び出しが発生する
- そのほとんどは「変化なし」という空振り
- それでも最大5分の遅れが生じる
- API側のレート制限に当たる可能性がある
Webhookなら、注文が入った瞬間に1回だけ通知が届きます。空振りがゼロになり、遅延もありません。
Webhookの仕組み
手順はシンプルです。
- 受信用のURL（エンドポイント）を用意する——外部からアクセスできる必要がある
- サービス側の管理画面に、そのURLを登録する
- どのイベントで通知するかを選ぶ（注文作成、支払い完了など）
- イベントが起きると、サービス側からそのURLへHTTP POSTが送られる
送られてくるデータは、多くの場合JSON形式です。
「URLを公開する」という前提
ここがAPIとの決定的な違いです。
APIを使うだけなら、こちらのシステムを外部に公開する必要はありません。しかしWebhookを受け取るには、インターネットから到達できるURLを用意する必要があります。
社内システムでこれを行う場合、ファイアウォールやプロキシの設定が関わってきます（プロキシサーバーとは？VPNとの違い）。「Webhookに対応しているから簡単」とは限らないのは、この点があるためです。
【重要】Webhookには統一仕様がない
意外に知られていないのが、これです。
APIにはRESTという広く共有された設計原則があります（REST APIとは？6つの原則・HTTPメソッド・設計の考え方）。しかしWebhookには、それに相当する統一された標準仕様がありません。
そのため、サービスごとに次の点が異なります。
- 署名の方式（送信元をどう確認するか）
- リトライの回数と間隔
- データの構造
- 成功と見なすHTTPステータスコード
「Webhookの実装経験がある」からといって、別のサービスでそのまま通用するとは限りません。連携先ごとに公式ドキュメントを読む必要があります。
標準化の試み：W3C WebSub
ただし、標準化の動きがなかったわけではありません。W3CはWebSubという仕様を勧告として公開しています。
「WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks.」
（WebSubは、あらゆる種類のWebコンテンツの発行者とその購読者の間の通信のための共通の仕組みを、HTTP web hooks に基づいて提供する）
——W3C「WebSub」
WebSubは3つの役割で構成されます。
| 役割 | 定義（W3C） |
|---|---|
| Publisher | 「An owner of a topic. Notifies the hub when the topic feed has been updated.」（トピックの所有者。更新をハブに通知する） |
| Subscriber | 「An entity (person or program) that wants to be notified of changes on a topic.」（変更の通知を受けたい主体） |
| Hub | 「The server (URL) which implements both sides of this protocol.」（このプロトコルの両側を実装するサーバー） |
通知の届き方も、一般的なWebhookと同じです。
「The request is an HTTP (or HTTPS) POST request from the hub to the subscriber’s callback URL.」
なおWebSubは旧称をPubSubHubbubといい、主にコンテンツ配信（フィードの購読）を想定した仕様です。SaaS連携で使われる一般的なWebhookが、この仕様に従っているわけではありません。
Webhookを受け取る側の実務
統一仕様がないぶん、受け取る側が気をつけるべき点があります。
① 署名検証は必須
公開されたURLには、誰でもPOSTできます。
「注文が確定した」という偽の通知を送られたら、システムはそれを本物として処理してしまいます。そのため多くのサービスは、リクエストに署名を付けています。
受信側は、あらかじめ共有された秘密鍵で署名を検証し、正当な送信元からのものか確認する必要があります。これを省略したWebhookエンドポイントは、事実上の穴になります。
② 同じ通知が複数回届く前提で作る
ネットワークの不調やタイムアウトで、サービス側が「届かなかった」と判断して再送することがあります。実際には1回目も届いていた、というケースです。
そのため受信側は「同じ通知を2回処理しても結果が変わらない」作りにしておく必要があります。
これはREST APIの記事で扱ったべき等性と同じ考え方です。通知に含まれる一意のIDを記録し、処理済みのIDなら無視するのが定石です。
③ 順序は保証されない
「作成」「更新」「削除」の通知が、その順番で届くとは限りません。通知に含まれるタイムスタンプで判断する設計が必要です。
④ すぐに応答を返す
受け取った処理に時間がかかると、送信側がタイムアウトと判断して再送します。
受信したらまず「受け取った」と応答を返し、重い処理は後回しにする——これが基本的な作りです。
どう使い分けるか
| やりたいこと | 適した仕組み |
|---|---|
| 変化があったらすぐ知りたい | Webhook |
| 過去のデータをまとめて取得したい | API |
| こちらからデータを登録・更新したい | API |
| 必要なときだけ最新の状態を確認したい | API |
| 受信用のURLを用意できない | API（ポーリング） |
実際には両方を組み合わせます。Webhookで「変化があった」ことを知り、APIで「詳しい内容」を取りにいく——という設計が一般的です。
通知には最小限の情報しか含まれないことも多く、その場合はAPIでの取得が前提になります。
ノーコードツールという選択肢
Webhookの受信URLを自前で用意するのが難しい場合、連携ツール（iPaaS）を間に挟む方法があります。
これらのツールは受信用URLを発行してくれるため、プログラムを書かずにWebhookを受け取れます。受け取った内容を別のサービスへ渡す、といった処理も画面上で組めます。
中小企業でシステム開発の体制がない場合、こちらのほうが現実的なことも多くなります（ノーコード・ローコードとは？中小企業向けツール比較）。
よくある質問
Q. Webhookは無料で使えますか？
サービスによります。プランによってWebhookが使えない、通知数に上限があるといった制限があることも珍しくありません。
連携を前提に導入を検討する場合は、契約プランで使えるかを事前に確認してください。
Q. 通知が届かないときは何を見ればよいですか？
多くのサービスは送信ログを管理画面で確認できます。まず「送信されているか」を確認してください。
送信されているのに届かない場合は、ファイアウォールやプロキシで外部からの通信がブロックされている可能性があります。
Q. HTTPSでなくても受け取れますか？
HTTPSを必須としているサービスがほとんどです。通知には業務データが含まれるため、暗号化されていない経路での受信は認められないのが一般的です。
Q. 社内システムで受け取れますか？
インターネットから到達できる必要があります。社内ネットワークの内側にあるシステムで直接受け取るのは難しく、公開できる場所に受信用の仕組みを置くか、前述の連携ツールを使うのが現実的です。
Q. APIとWebhook、どちらから検討すべきですか？
「リアルタイム性が本当に必要か」から考えてください。1日1回のデータ同期で足りるなら、APIで十分です。
Webhookは受信環境の準備・署名検証・重複対策が必要になるため、要件に見合うかを先に判断するほうが結果的に早く済みます。
参考にした主な調査・資料
- WebSub（W3C Recommendation）｜World Wide Web Consortium (W3C)
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format｜IETF
- 安全なウェブサイトの作り方｜独立行政法人 情報処理推進機構（IPA）
※W3C仕様の引用は原文（英語）からの抜粋で、和訳は本記事によるものです。Webhookの仕様はサービスごとに異なるため、実際の連携にあたっては各サービスの公式ドキュメントをご確認ください。
まとめ
- APIは「こちらから聞きにいく」、Webhookは「あちらから知らせてくる」
- Webhookがないとポーリングになり、空振りの通信と遅延が発生する
- Webhookにはインターネットから到達できる受信URLが必要
- Webhookには統一された標準仕様がない。署名方式・リトライ・データ構造がサービスごとに違う
- W3Cは WebSub（旧PubSubHubbub）を勧告として公開しているが、一般的なSaaS連携のWebhookがこれに従っているわけではない
- 受信側は署名検証が必須。公開URLには誰でもPOSTできる
- 同じ通知が複数回届く前提で作る（べき等性）。順序も保証されない
- 実際はWebhookで気づき、APIで取りにいく組み合わせが一般的
Webhookは「便利な通知機能」に見えますが、受け取る側に相応の設計を求める仕組みでもあります。
リアルタイム性が本当に必要かを見極めてから選べば、無用な複雑さを避けられます。
