Webhook の送信を外部サービスに任せるメリット｜自前で作る場合との比較

SaaS や業務システムで「注文が確定した」「支払いが完了した」といった出来事を取引先のシステムに知らせるとき、多くは Webhook を使います。HTTP の POST を 1 回送るだけなら数行で書けますが、顧客に提供する機能として運用するには、届かなかったときの再送、なりすましを防ぐ署名、配信の記録、顧客が自分で送信先を登録する画面まで必要になります。この送信の部分を、専用の外部サービスに任せる企業が増えています。ここでは自前で作る場合の作業範囲と、外部サービスに任せる場合の利点、任せる前に確認する点を整理します。

Webhook の送信を自前で作る場合の作業範囲

顧客向けの機能として Webhook を提供するときに作るものを挙げます。見積りを取るときの項目としても使えます。

• キューと再送：イベントの発生と送信を分け、キューに積んでから送ります。送信先が止まっているときは、間隔を広げながら（指数バックオフ）数時間から数日にわたって再送します。Stripe は本番環境で最長 3 日間、指数バックオフで再送すると公開しています。同じイベントが 2 回届くこともあるため、受信側が重複を判定できるイベント ID も付けます
• 署名と鍵の入れ替え：受信側が送信元を確かめられるよう、本文に HMAC などで署名します。鍵の漏洩や定期的な入れ替えに備え、新旧 2 つの鍵で同時に署名する期間を設けます
• 顧客ごとの送信先の管理：顧客ごとに URL、受け取るイベントの種類、鍵を持ちます。登録・変更・削除の API と、操作できる人の権限も必要です
• 配信記録と手動の再送：いつ、どの送信先に、何を送り、何が返ってきたかを残します。「届いていない」という問い合わせに、記録を確認して再送できる画面が必要です
• 失敗の通知と自動停止：失敗が続く送信先を担当者に知らせ、長期間届かない送信先は止めます。止めたことは顧客にもメールなどで知らせます
• SSRF 対策：送信先の URL は顧客が入力します。社内ネットワークやクラウドのメタデータのアドレスを指定されると、送信サーバーから内部のシステムに通信が届きます。内部のアドレスを拒否する中継を通す、送信の処理を内部に届かないネットワークに置くといった対策が必要です
• 固定の送信元 IP：金融機関や大企業の取引先は、受信を IP アドレスで制限していることがあります。送信元の IP を固定し、変えるときは事前に知らせる運用が必要です
• 顧客向けの設定画面：顧客が自分で送信先を登録し、鍵を確認し、届いた記録を見て再送できる画面です。この画面がないと、送信先の登録や調査の依頼がすべてサポート窓口に届きます
• 応答の遅い送信先への対応：応答に数十秒かかる送信先が 1 つあると、同じキューを使うほかの顧客への送信まで遅れます。送信先ごとに同時に送る数を区切り、失敗が続く送信先への送信をしばらく止める仕組みが必要です

送信側が守る点は、公開仕様 Standard Webhooks にもまとめられています。再送の間隔、新旧の鍵による署名、SSRF 対策、失敗が続く送信先の停止、固定の送信元 IP まで、上の項目の多くが仕様の中で取り上げられています。署名とヘッダーの形式は「Standard Webhooks とは」で説明しています。

送信を専用サービスに任せる企業の事例

Webhook の送信を専門に提供するサービスには、Svix や Hookdeck Outpost などがあります。各社が公開している事例と発表から挙げます。

• Clerk（認証サービス）：Svix で Webhook を提供しています。事例では、自前で作ると最初の版だけで 1 か月以上、必要な機能をそろえた信頼できる実装には熟練したチームで 6 か月以上かかると見積もったうえで、Svix との最初の連携は 2 週間かからずに済んだとしています
• Resend（メール送信 API）：共同創業者が前職の WorkOS で Webhook の基盤を自前で作った経験から、Resend では最初から自前で作らない方針をとりました。Svix で年間 2 億件以上の Webhook を送っています。最初は Svix の顧客向け画面をそのまま使い、のちに Svix の React ライブラリで自社の見た目に合わせた画面を作っています
• Hookdeck Outpost：Hookdeck は 2026 年 4 月 23 日に Outpost の一般提供を発表しました。顧客の送信先に Webhook やイベントを送るための基盤で、Apache 2.0 のオープンソースとして公開されており、マネージド版と自社で動かす版は同じコードで動きます。送信先には Webhook のほか、Kafka、AWS SQS、GCP Pub/Sub なども選べます

署名の形式も共通化が進んでいます。2023 年 12 月には、Svix が呼びかけ、Zapier、Twilio、Lob、Mux、ngrok、Supabase、Kong が技術委員会に加わった Standard Webhooks が発表されました。形式が共通になると、受信側は公式ライブラリで検証でき、送信側は送信の基盤を入れ替えても顧客に改修を頼まずに済みます。

外部サービスに任せる利点

• 公開までの期間：再送、署名、記録、顧客向けの画面を作らずに済みます。アプリ側の作業は、イベントの発生時に API を呼ぶ処理と送信先の登録になります
• 届く確かさ：再送の間隔、失敗が続く送信先の停止、応答の遅い送信先の切り分けが最初から入っています
• 調査のしやすさ：配信記録と送信先の応答が画面で見られるため、「届いていない」という問い合わせに記録を見て答えられます
• 顧客の自己解決：顧客が送信先の登録、鍵の確認、再送を自分で行えるため、サポート窓口への依頼が減ります
• IP 制限のある取引先への送信：固定の送信元 IP を提供するサービスであれば、取引先はその IP を許可するだけで受け取れます

任せる前に確認すること

1. 費用の決まり方：多くは送信の通数で月額が決まります。再送が通数に数えられるか、上限を超えたときに送信が止まるのか超過分が課金されるのかを確認し、見込みの通数で試算します
2. 本文の預け先：本文は外部サービスを通り、配信記録として一定期間保存されます。保存期間、保存先の地域、個人情報を本文に含める場合の委託先としての扱いを確認します。本文に個人情報を入れず ID だけを送り、受信側に API で詳細を取得してもらう形にすると、預ける情報を減らせます
3. 署名の形式：Standard Webhooks のような公開仕様に沿っていれば、あとで別のサービスや自前の送信に移しても、顧客の検証コードは変わりません
4. 障害時の影響：外部サービスが止まると送信も止まります。稼働率の保証、障害中に送信の依頼を受け付け続けるか、障害情報の公開方法を確認します
5. 契約と窓口：規約の言語、準拠法、請求の通貨、サポートの窓口が、社内の委託先の審査に合うかを確認します

自前で作る場合と外部サービスを使う場合の比較

自前で作るほうが合うのは、送信の通数が非常に多く通数に応じた料金が合わない場合、社内規程で本文を社外に出せない場合、送信の仕組みそのものが製品の強みになる場合です。本文を社外に出せない場合は、オープンソースの送信基盤を自社の環境で動かす方法もあります。

Webhook Admin のご案内

当社は、Webhook の送信を任せられるサービス「Webhook Admin」を提供しています。イベントが発生した箇所で API を 1 回呼ぶと、Standard Webhooks 形式で署名して送信し、届かなかった場合は、既定では 1 回目を含めて最大 8 回、約 28 時間にわたって再送します。回数と間隔は送信先ごとに選べます。5 日間失敗が続いた送信先は自動で止め、失敗は Slack・Teams・Chatwork・メールなどに通知します。固定の送信元 IP と顧客向けの設定画面は Starter プラン（月 3,000 円・税別）から使え、月 5 万通までは無料で始められます。本文を社外に出せない場合に向けて、Enterprise プランでは、お客さまの環境での運用（セルフホスト）もご相談いただけます。

出典

• Stripe: Webhook エンドポイントで Stripe イベントを受信する
• Standard Webhooks
• Standard Webhooks: Specification
• Svix: Announcing Standard Webhooks
• Svix: Clerk の事例
• Svix: Resend の事例
• Hookdeck: Hookdeck Outpost is GA
• Hookdeck: Changelog（2026 年 4 月 23 日）