Webhook2026年10月14日9 分
Webhook ハンドラーが LLM を呼ぶ。送信元は先に接続を切る。
Slack は 3 秒、Shopify は 5 秒、GitHub は 10 秒しか待ちません。LLM 呼び出しはそれより長く、送信元は接続を切ります。先に応答するか、中継サービスに預けます。
最新
14
2026.10
配信、リトライ、署名検証、デバッグ、再送についての本番運用ノートです。AnyHook の開発チームが書いています。
ngrok は再起動のたびに URL が変わり、Stripe や Shopify に貼り直すはめになります。プロバイダーには固定の URL を登録し、その日に動くトンネルに向けてください。
冪等性の議論は、たいていデータベースの重複行で終わります。予約の Webhook では、同じ 10:00 の枠に 2 人が現れるところで終わります。
GitHub は失敗した Webhook の配信を一度もリトライしません。配信記録は 3 日で消え、その後は、デプロイの失敗で失ったイベントは二度と戻りません。
HubSpot は順序を保証せず、eventId が一意である保証もないと明記しています。Stripe の event.id で培った直感は、ここでは全部外れます。
access.granted を取りこぼせば問い合わせが来ます。access.revoked を取りこぼしても、外からは正常に見えるので誰も気づきません。稼働率がアクセス制御になります。
MoR の決済は応答期限が短く、リトライが密です。個人開発の SaaS が Paddle や Lemon Squeezy に移ると何が変わるかを解説します。
Slack は 3 秒以内の 2xx を求め、1 時間で配信の 95% が失敗するとサブスクリプションを無効化します。ユーザーの目の前で起きる Webhook の失敗です。
Twilio は、接続・読み取りタイムアウト、合計時間、リトライ回数、リトライポリシーを設定できる唯一の主要な送信元です。その 5 つのダイヤルを、誰も回していません。
Node の crypto はなく、CPU 時間はミリ秒単位、waitUntil は永続的ではありません。受信側が Worker になると何が変わるのかを、AnyHook の受信 Worker から解説します。
WooCommerce の Webhook はキューに入り、サイトにアクセスがあったときに WP-Cron が送ります。5 回を超える連続失敗で無効化されます。
主要プロバイダーの多くは少なくとも 1 回の配信（at-least-once）で、重複は例外ではなく必ず起きます。冪等性の 4 パターンを、守りの弱い順に紹介します。
原因の 9 割は、画面を見ている間しか受信しないテスト URL です。残りは応答モード、パースで消えた生のボディ、失われたイベントのどれかです。
Shopify の応答期限は 5 秒です。4 時間で 8 回リトライした後、サブスクリプションを削除します。エラーは出ず、注文が届かなくなるだけです。
Stripe に Webhook エンドポイントを無効化されたら、30 日の復旧期間は思うほど長くありません。手順は再有効化、そして Events API からの補完です。
理由なく失敗する署名検証、消える waitUntil の処理、タイムアウトまでの猶予を食うコールドスタート。サーバーレスでつまずく点と、その対処法を説明します。
ポーリングはリクエストを無駄にしますが、穏やかに劣化します。Webhook は効率的でも、黙って失敗します。本格的な連携の多くが行き着くハイブリッド構成も紹介します。
確認コードも領収書も通知も、今もメールで届きます。キー不要の呼び出し 1 回で、エージェントは Webhook イベントとして読めるインボックスを持てます。
キャッチオールと Worker のメールハンドラー、約 60 行で、ドメイン宛ての全メールが既存の HTTP パイプラインへの JSON POST になります。
変更できるデータベースの Webhook ログは、証拠ではなく主張です。AnyHook はハッシュチェーン、毎日の封印、公開アンカーでログを検証可能にしました。
テストが検証コードと同じ式で署名を作っているなら、両方が間違っていてもテストは通ります。プロバイダーの SDK と突き合わせて確認してください。
エージェントは API を呼べても、受信手段がありません。Webhook の URL が要るときに壊れるものと、エージェントが扱えるサービスの形を説明します。
Webhook の配信をデバッグする手順です。連携が動かなくなったときに、ヘッダー、ステータスコード、所要時間、ペイロードで何を確認すべきかを説明します。
素朴な指数バックオフがサンダリングハード問題を招く理由、ジッターでそれを防ぐ方法、本番運用に耐えるリトライスケジュールの実際を説明します。
サーバーが 3 時間ダウンしても、Stripe、GitHub、Shopify は Webhook を送り続けます。取りこぼしたイベントの再送方法を、中継サービスの有無別に説明します。
ngrok はローカル開発には最適ですが、本番の戦略にはなりません。トンネルの先で必要になるものを、ステージング、本番、その間のグレーゾーンについて説明します。
Stripe は失敗した Webhook を最長 3 日間リトライします。スケジュールの仕組み、エンドポイントがダウンしたときに壊れるもの、それに備えた設計を解説します。
プロバイダーごとの Webhook 署名検証。よくある失敗、タイムスタンプの許容範囲の仕組み、素朴な実装がリトライで壊れる理由を説明します。