複数のサービスの Webhook の一元管理：勧める理由と進め方

複数のサービスから Webhook を送る会社では、送信の仕組みを会社で 1 つにまとめる方が、作る量・運用の手間・受け手の負担のどれも小さくなります。署名・再送・送信の記録・失敗の通知・SSRF の対策を 1 回作れば全サービスで使え、受け手の顧客には、どのサービスの Webhook も同じ形で届くからです。

この記事では、サービスごとに作ったときに起きること、一元管理を勧める理由と公開されている例、まとめる必要がない場合、まとめたときの弱点と手当て、社内の基盤とサービスの選び方、移行の手順の順に書きます。出典の日付はすべて 2026-09-30 に確認したものです。

サービスごとに作ったときに起きること

結論として、同じ部品が少しずつ違う形でサービスの数だけでき、受け手と運用の担当者がその違いを覚えることになります。

たとえば、請求のサービスは HMAC の署名を X-Signature に入れて 3 回再送し、会員のサービスは署名を付けずに固定のトークンを送り、予約のサービスは再送しない、という状態です。どれも単独では動いていますが、次のような違いが積み重なります。

一元管理を勧める理由

理由は 6 つあります。どれも「同じ仕組みを 1 回だけ作り、1 か所で見る」ことから来ています。

署名の形が 1 つになる

Webhook の署名の形は、送る会社ごとに違うのが現状です。Standard Webhooks を始めた Svix は、発表の記事で「エコシステムが分断され、Webhook を送る会社ごとに実装も品質も違う」ことを課題に挙げ、受け手は送り手ごとに検証の方法を覚え直し、送り手はすでに解かれた問題（セキュリティ、将来の互換性など）を作り直していると書いています（Announcing Standard Webhooks、2023-12-13）。

同じことは 1 社の中でも起きます。サービスごとに署名の形が違えば、同じ顧客が検証のコードを複数書くことになります。送信を 1 か所にまとめれば、署名の形は自然に 1 つになります。Standard Webhooks の運営委員会には Zapier・Twilio・Lob・Mux・ngrok・Supabase・Svix・Kong の担当者が入っており（Standard Webhooks）、形を決めるときの候補になります。仕様の中身は Standard Webhooks の仕様と実装で説明しています。

再送と重複の扱いがそろう

受け手が重複を除くには、再送しても変わらないイベントの ID が要ります。Standard Webhooks の仕様は、webhook-id を「失敗した Webhook を何回再送しても変わらない」ものと定め、再送は数日にわたる指数バックオフに揺らぎを加える形を勧めています（仕様）。

サービスごとに作ると、ID が無いサービスや、再送のたびに ID が変わるサービスが混ざりがちです。1 つの仕組みから送れば、どのイベントにも同じ規則の ID が付き、再送の間隔も同じになります。再送の間隔の決め方は 再送の設計に、受け手の重複の除き方は 重複と冪等性にあります。

記録と監視が 1 か所になる

顧客から「Webhook が届いていない」と問い合わせを受けたとき、まず見るのは送信の記録です。記録がサービスごとに別の場所にあると、どのサービスから送ったものかを確かめるところから始まります。1 か所にまとめれば、イベントの ID や顧客の ID で全サービスを横断して探せます。

失敗の通知も同じです。送信先ごとの失敗が続いている時間と、全体の再送待ちの数という同じ指標を、全サービスで同じ条件で見られます。当番の担当者が覚える画面と手順も 1 つで済みます。見る指標は 送信の監視で説明しています。

セキュリティの対策を 1 回で済ませられる

Webhook を送る側は、顧客が登録した任意の URL へ自社のサーバーから通信します。社内のアドレスや、クラウドのメタデータのアドレスを登録されると、SSRF の入口になります。Standard Webhooks の仕様は、社内の IP を弾くプロキシを通して送ることと、送信のワーカーを社内のサービスに届かないサブネットに置くことを勧めています（仕様）。

この対策は、登録時の検査と送る直前の検査の両方が要り、1 か所でも漏れると意味がありません。サービスの数だけ実装すると、漏れを点検する場所もサービスの数だけ増えます。鍵の暗号化した保管、鍵の切り替え、固定の送信元 IP も同じで、1 か所で作れば全サービスに効きます。詳しくは 送る側の SSRF 対策と 鍵の切り替えにあります。

受け手から見て 1 社の Webhook になる

顧客は、どのサービスの Webhook かではなく、「その会社の Webhook」として受けます。署名の形、再送の仕様、送信元 IP、受け手向けの説明、送信先を登録する画面が 1 つにそろっていれば、顧客の組み込みの手間と問い合わせが減ります。受け手向けに書く内容は 受け手向けのドキュメントで、顧客が自分で送信先を扱う画面は 顧客向けの画面で扱っています。

同じ部品を何度も作らずに済む

Webhook の送信で重いのは、POST を送る部分ではなく、再送・記録・自動停止・通知・鍵の切り替え・顧客向けの画面です（部品の一覧は 自作か配信サービスかに載せています）。これをサービスの数だけ作ると、作る量も直す量もその倍数になります。

CNCF の Platforms White Paper は、共通の基盤を置く理由として、製品のチームの負担（覚えること）を減らすことと、道具と知見を多くのチームで使い回して開発を速めることを挙げています（CNCF Platforms White Paper、「Why platforms?」の節）。Webhook の送信は、この考え方がそのまま当てはまる部品です。

公開されている例

Webhook を送る大手は、製品や種類が違っても、1 つの仕組みで同じ形の Webhook を送っています。社内の構成までは公開されていませんが、受け手から見える仕様がそろっていることは公式の文書で確かめられます。

受け手の側から見ると、これらの会社では製品が増えても検証のコードと重複の除き方は 1 つのままです。複数のサービスを持つ会社が目指す形も同じです。

一元管理が向かない場合

次のどれかに当てはまるなら、無理にまとめる必要はありません。

• Webhook を送るサービスが 1 つで、今後も増える予定がない
• 送信先が社内の 1〜2 か所だけで、顧客に送っていない
• イベントの種類が数個で、送信の記録を顧客に見せる必要がない
• 送る側のサービスが別の会社に売却・分社される予定で、仕組みを共有すると切り離しの手間が増える

1 つ目と 2 つ目の場合は、既存のキューの再試行に送信を載せる形で足ります。その場合も、署名は最初から Standard Webhooks の形にしておくと、後でまとめるときに受け手を変えずに済みます。

まとめたときの弱点と手当て

弱点は、1 か所の障害や 1 社の遅い送信先が、全サービスの送信に影響し得ることです。次の分け方で防ぎます。

受け付けの失敗に備える形は outbox パターンに、送信先ごとの分け方は マルチテナントの Webhook の送信にあります。

社内の基盤か、配信サービスか

どちらでも一元管理はできます。違いは、作る量と運用を誰が持つかです。

配信サービスには Svix、Hookdeck Outpost、Convoy、Webhook Admin などがあります。料金・保存期間・固定 IP の比較は 配信サービスの比較に、自作との比べ方は 自作か配信サービスかにあります。

一元管理の進め方

1. 今の送信を棚卸しする: Webhook を送っているサービス、イベントの種類、署名の形、再送の仕様、送信先の数、受け手向けの文書を一覧にする
2. 共通の決めごとを文書にする: 署名の形（Standard Webhooks を勧めます）、イベントの種類の名前の付け方、再送の間隔、タイムアウト、成功の判定、自動停止の条件
3. 仕組みを決める: 社内の基盤を作るか、配信サービスを使うかを、上の表で決める。サービスごとに記録と権限を分けられることを条件に入れる
4. 失敗の通知の宛先を決める: サービスごとの担当と、全体を見る当番の両方に届くようにする
5. 1 サービスずつ移す: 新しいイベントの種類から、または送信先の少ないサービスから始める。移す間は新旧の両方の署名を付け、受け手が切り替えたことを確かめてから古い形をやめる
6. 受け手向けの文書と画面を 1 つにする: 署名の検証、再送の仕様、送信元 IP、送信先の登録の画面を 1 か所にまとめる

イベントの名前の付け方は イベントの種類の名前と粒度に、移行の手順は 配信サービスの乗り換えにあります。

Webhook Admin での一元管理

Webhook Admin では、会社（組織）の下にサービスごとのプロジェクトを作り、各プロジェクトに本番とテストの環境があります。API キーは環境ごとに発行するので、サービスごとに送信の権限を分けられます。

• 全プロジェクトの横断: 組織の画面で、全プロジェクトの直近 24 時間の送信数・成功率・対応が要る送信先をまとめて見られます。本番の送信の記録も、全プロジェクトを横断して探せます
• 同じ形の署名と再送: どのプロジェクトからの送信も Standard Webhooks の形で署名し、既定で最初の送信を含めて 8 回・約 28 時間かけて再送します。失敗が 5 日続いた送信先は自動で無効にします
• 失敗の通知: Slack・Teams・Chatwork・メール・Webhook に、プロジェクトごとにも、組織でまとめて 1 か所にも送れます
• SSRF の対策: 送信先の URL を登録時に検査し、送る直前にも名前解決の結果を検査します
• 顧客向けの画面: Starter から、顧客自身が送信先・受け取るイベント・鍵・記録・再送を扱える画面を自社の画面に埋め込めます
• 操作の記録と API・MCP: 組織の操作の記録を残します。公開 API と MCP から、送信先の登録や失敗した送信の再送を行えます

プロジェクトの数は Free が 1、Starter が 3、Pro が 10、Business が無制限です。Free は月 5 万通まで無料で試せます。https://app.webhookadmin.com/signup

よくある質問

サービスが 2 つしかなくても、まとめる意味はありますか。

受け手が同じ顧客で、両方のサービスの Webhook を受けているなら意味があります。署名の形と再送の仕様が 1 つになり、顧客は検証のコードを 1 つ書けば済みます。受け手がサービスごとに別で、今後もサービスが増えないなら、それぞれの作りのままでも困りません。

まとめると、1 か所の障害で全サービスの送信が止まりませんか。

止まらないように分けて作ります。送信の受け付けは保存してから返し、送る処理はキューを通して非同期にします。送信先ごとに同時に送る数の上限と一時停止を持たせ、API の回数制限はサービス（プロジェクト）ごとにします。サービスを使う場合は、公開している稼働率の保証（SLA）と障害の報告の履歴を確かめます。

すでに各サービスで別の形の署名を送っています。受け手を壊さずに移れますか。

移れます。しばらくは古い形と新しい形の両方の署名を付けて送り、受け手が新しい形の検証に切り替えたことを確かめてから古い形をやめます。手順は配信サービスの乗り換えの記事にまとめています。