Shopify は、失敗し続ける Webhook を 9 回配信します。内訳は最初の試行と 8 回のリトライで、最後のリトライはイベントの 4 時間後です。そこで止まります。AnyHook のテストでは、サーバーが復旧した後も、それらの注文について何も送られてきませんでした。注文は Shopify には存在しますが、お使いのシステムに Webhook で伝わることはありません。
Shopify のドキュメントには、4 時間で 8 回のリトライという合計は書かれていますが、各試行のタイミングは書かれていません。そこで実測しました。Shopify の開発ストアでテスト注文を 4 件入れ、受信サーバーに 6 時間弱 503 を返させて、すべてのリクエストを記録しました。
TL;DR
- 試行は約 2 秒、3 秒、1 分、3 分、8 分、30 分、1 時間、2 時間、4 時間の時点で届きました。4 件の注文はすべて、1.4 秒以内の差でこのスケジュールに従いました
- 9 回目の試行の後は、何も届きませんでした。それから 2 時間足らずで受信サーバーは復旧しましたが、4 件の注文はどれも Webhook では届きませんでした
- 多くのガイドに今も書かれている「48 時間で 19 回のリトライ」は、古い情報です
- Shopify の管理画面で追加した Webhook は、36 回連続で配信に失敗しても削除されませんでした。管理画面に失敗は表示されず、ストアオーナーにメールも届きませんでした
- 4 時間を超える障害を乗り切るには、2 つ必要です。サーバーがダウンしている間にイベントを保存して Shopify に応答するものと、Admin API に対する照合ジョブです。管理画面で追加した Webhook や小規模なアプリなら、最小の変更は AnyHook のような Webhook 中継サービスです。変えるのは URL 1 つだけです
実測したスケジュール
| 試行 | 注文からの経過時間 | 前回の試行からの間隔 |
|---|---|---|
| 1 | 2 秒 | |
| 2 | 3 秒 | 1 秒 |
| 3 | 1 分 | 1 分 |
| 4 | 3 分 | 2 分 |
| 5 | 8 分 | 5 分 |
| 6 | 30 分 | 22 分 |
| 7 | 1 時間 | 30 分 |
| 8 | 2 時間 | 1 時間 |
| 9 | 4 時間 | 2 時間 |
| それ以降 | 何もなし |
時間は、Shopify が Webhook に付けるタイムスタンプ X-Shopify-Triggered-At から数えています。
9 回の試行のうち 5 回は、最初の 8 分で使われます。瞬断には効きますが、壊れたデプロイにはほとんど役に立ちません。誰かがアラートを見る頃には、残りの試行は 4 回です。
スケジュールは固定に見えます。どの段階でも 4 件の注文は互いに 1.4 秒以内に届いたので、目に見えるジッターはありません。まとめて失敗した注文は、同じまとまりのままリトライされるはずです。タイムセールのスパイクは 1 分後に戻ってきて、次は 3 分後、その次は 8 分後に戻ってきます。
同じイベントのリトライには、同じ ID が付きます。比較した注文では、X-Shopify-Webhook-Id は 9 回の試行すべてで同一でした。そのため、重複排除のキーとして安全に使えます。
重要な境目は 4 時間です。エンドポイントが復旧した時点で、直近 4 時間の注文はまだ配信の途中にあり、次に予定された試行で届きます。それより古い注文は、どれも届きません。
「48 時間で 19 回のリトライ」は古い情報
この数字は今も見かけます。Webhook ベンダーが今年公開したガイドにも載っています。出どころは Shopify の以前のポリシーです。Shopify は 2024年9月10日に仕組みを変更し、4 時間で 8 回のリトライにしました。現在のドキュメントにも同じことが書かれています。AnyHook のログも同じです。最後の試行は 4 時間の時点で、翌日になってもそれ以上は何も届いていませんでした。
ランブックや復旧計画が 2 日を前提にしているなら、12 倍ずれています。
注文はどうなったか
直接の Webhook では、36 件の配信（注文 4 件、各 9 回の試行）すべてに 503 が返りました。受信サーバーは、そのうち最後の試行の 1 時間 37 分後に再び 200 を返し始めましたが、Shopify はもう試行しませんでした。4 件の注文はどれも受信サーバーに届きませんでした。
この障害に特別なところは何もありません。金曜の夕方に壊れたデプロイを出し、日付が変わる前に直した場合も、同じように見えます。どの注文を失うかは、ダウンしていた時間で決まります。6 時間の障害なら、最初の 2 時間の注文は Webhook の経路から失われます。最後の 4 時間の注文は次に予定された試行で届き、それは復旧から最大 2 時間後です。これは、障害の間も Webhook が残っている場合の話です。Admin API で作成したサブスクリプションは途中で削除されることがあり、その場合は再作成するまで新しいものは何も送られません。
サーバーの負荷が最も高く、時間あたりの注文数も最も多いブラックフライデーのセール中にこれが起きれば、最初の数時間分は Admin API から補完しなければなりません。ほかに取り戻す方法はありません。手順は「Shopify に Webhook を削除された」にあります。
Webhook は残り、誰にも知らされなかった
Shopify のドキュメントによると、8 回連続の失敗でサブスクリプションが削除されるのは、Admin API で設定した場合だけです。警告も、アプリの緊急連絡用の開発者メールアドレスに届くとされています。Shopify の管理画面の Settings → Notifications → Webhooks で手動で追加した Webhook には、触れていません。こうした Webhook の背後にアプリはありません。ストアと ERP や倉庫をつないでいるのがこの Webhook であることも、よくあります。
そこで確認しました。36 回連続で配信に失敗した翌日の状態は、次のとおりです。
- Webhook は変わらず一覧に残っていました
- 管理画面には配信履歴も失敗の兆候も表示されていませんでした。各行の操作は、編集、テスト送信、削除です
- ストアオーナーのアドレスに警告メールは届いていませんでした
すべての配信に 1 日失敗し続けている Webhook も、正常な Webhook と同じに見えます。唯一の症状は、下流で注文が欠けることです。Admin API で作成したサブスクリプションの失敗は、違う形になります。Shopify に削除されます。
4 時間を超える障害を乗り切る方法
必要なのは、サーバーがダウンしている間にイベントを保存して Shopify に応答するものと、それでも漏れたものを拾う照合ジョブです。Shopify 自身のドキュメントも、このジョブを作ることを推奨しています。以下の選択肢の 1 つは AnyHook 自身の製品なので、その点を踏まえて判断してください。
| 選択肢 | 管理画面の Webhook | 向いているケース | 注意点 |
|---|---|---|---|
| Admin API の照合ジョブ | 対応 | 注文の欠落が金銭的な損失になるすべてのストア | 事後に、自分で決めたスケジュールで動く。構築も運用も自前 |
| Amazon EventBridge または Google Pub/Sub | 非対応。管理画面のフォームで指定できるのは URL だけ | すでにそのクラウドで動いているアプリ | アプリのサブスクリプション専用。コンシューマー、保存期間、アラートは自前で構築 |
| 小さなエンドポイントの後ろに置く自前のキュー | 対応 | すべてを内製したいチーム | そのエンドポイントにも同じ 5 秒の応答期限があり、ほかのシステムがダウンしても動き続ける必要がある |
| Hookdeck | 対応 | 変換処理、チームのワークフロー、大きな処理量が必要なプラットフォームチーム | リトライと再送だけの用途には機能が多すぎる |
| AnyHook | 対応 | 小規模なチームと管理画面の Webhook。変えるのは URL 1 つだけ、コード不要、無料で始められる | 配信は少なくとも 1 回（at-least-once）なので、重複排除は引き続き必要。Free プランのリトライは 35 分の時点で終わり、1 日 1,000 件を超えるイベントは受け付けない |
選び方は次のとおりです。
- Webhook を手動で追加した、または小規模なアプリを運用していて、障害の夜でも注文を失いたくない場合：エンドポイントの前に中継サービスを置きます。AnyHook はこのケースのために作られています。変えるのは URL 1 つだけで、ハンドラーはそのままです
- 大きな処理量を扱うプラットフォームチームの場合：Hookdeck のほうが充実した製品です。両者の比較はこちらです
- アプリがすでに AWS または Google Cloud で動いている場合：今の環境には EventBridge か Pub/Sub が合います
- どの場合でも：注文の照合ジョブは残してください。中継サービスを使うと、境目は 4 時間からそのサービスのリトライ期間と保存期間に移りますが、境目そのものはなくなりません
同じテストを AnyHook 経由で
AnyHook は Webhook 中継サービスです。Webhook を AnyHook に向けると、イベントを保存して送信元に応答し、サーバーに転送します。サーバーが失敗したときはリトライします。このテストでは、各注文は AnyHook に向けた 2 つ目の Webhook にも送られ、AnyHook が同じ受信サーバーに転送しました。
| 試行 | AnyHook 経由 |
|---|---|
| 1 | 2 秒 |
| 2 | 5 分 |
| 3 | 35 分 |
| 4 | 3 時間 35 分 |
| 5 | 21 時間 35 分、配信済み |
AnyHook は Shopify に約 1 秒で 200 を返すので、Shopify にはリトライするものがありません。このスケジュールは、同じ失敗中の受信サーバーに対する AnyHook 自身のものです。直接の Webhook への Shopify の試行が終わってからずっと後に、5 回目の試行は正常に戻った受信サーバーに届き、待っていた 3 件の注文を配信しました。最初の注文の分は、35 分の時点ですでに届いていました。原因はこちらのミスで、「テストの方法」で説明しています。
中継によって、最初の試行には 0.5〜0.9 秒が加わりました。Shopify の署名も転送を経て残りました。受信サーバーは転送されたリクエストで元の X-Shopify-Hmac-SHA256 を検証し、すべて通ったので、今ある検証コードはそのまま使えます。AnyHook は最初の配信失敗の時点と、5 回連続で失敗した時点でメールを送りました。Shopify からは何も届きませんでした。
このテストは AnyHook 自身の Enterprise アカウントで実行しました。リトライのタイミングはどのプランでも同じです。変わるのは試行回数と再送可能期間です。
| プラン | 料金 | 試行回数 | 最後の自動試行 | 再送可能期間 |
|---|---|---|---|---|
| Free | $0、クレジットカード登録不要 | 3 回 | 35 分 | 3 日 |
| Pro | $20/月 | 5 回 | 21 時間 35 分 | 30 日 |
| Scale | $90/月 | 10 回 | 5 日 21 時間 | 90 日 |
Free プランなら、このテストの結果は違っていました。リトライは受信サーバーが復旧する前の 35 分の時点で止まります。注文はログに残っているので、3 日以内に手動で再送することになります。Free プランは 1 日 1,000 件を超えるイベントも受け付けないので、セールには向きません。Pro プランには 1 日の上限がなく、5 回目の試行はここと同じように実行されます。
中継サービスは、注文の経路に加わるもう 1 つの当事者です。AnyHook は応答する前に各イベントを保存し、保存時に暗号化します。イベントを保存できないときは 200 ではなく 503 を返し、Shopify 自身のリトライに引き継がれます。
設定手順
-
AnyHook で App（Webhook の送信元ごとに作る受信設定）を作成し、現在の Webhook の URL を転送先に設定します。アカウントなしで先に試すなら、次のコマンドで稼働中の
inbound_url、API キー、claim_urlが返ります。紐付け用の URL を開いてログインしない限り、エンドポイントとそのイベントは 7 日後に削除されます。curl -X POST https://anyhook.net/api/v1/quickstart -
Shopify の管理画面で Settings → Notifications → Webhooks → Create webhook を開きます。イベントを選び、フォーマットを JSON に設定して、受信 URL を貼り付けます。
-
そのページに表示される署名シークレットを App の送信元の署名シークレットにコピーし、Webhook のメニューからテストを送信します。テストは App のログに表示されるはずで、偽造されたリクエストには 401 が返ります。アプリが作成するサブスクリプションは、代わりにアプリのクライアントシークレットで署名します。
AI コーディングエージェントなら、npx -y anyhook-mcp で最初のステップを実行できます。
よくある質問
Shopify は失敗した Webhook を何回リトライする？
Shopify は最初の試行の後に 8 回リトライします。つまり 4 時間で合計 9 回の配信試行です。実測では、試行はイベントから約 2 秒、3 秒、1 分、3 分、8 分、30 分、1 時間、2 時間、4 時間後でした。
Shopify の Webhook リトライは今も 48 時間？
いいえ。古いガイドにある「48 時間で 19 回のリトライ」は、Shopify が 2024年9月に行った変更より前の情報です。2026年11月の AnyHook のテストでは、最後の試行は 4 時間の時点でした。
サーバーが復旧したら、Shopify は Webhook を送り直してくれる？
そのイベントの試行がまだ続いている間だけです。復旧時点で発生から 4 時間たっていないイベントは、次に予定された試行で届きます。それより古いイベントは再び送られないので、Admin API から取得します。
Shopify では何が配信失敗として扱われる？
Shopify のドキュメントによると、3xx リダイレクトを含む 200 番台以外のレスポンスと、5 秒以内に応答がない場合（接続に使える時間は 1 秒）です。AnyHook のテストで使ったのは 503 のレスポンスだけです。
失敗し続ける Webhook は Shopify に削除される？
Shopify のドキュメントによると、Admin API で作成したサブスクリプションは 8 回連続で失敗すると削除されます。AnyHook のテストでは、Shopify の管理画面で追加した Webhook は、36 回連続で失敗した翌日も一覧に残っていました。
Webhook が失敗したとき、Shopify から警告は届く？
アプリのサブスクリプションの場合、警告メールはアプリの緊急連絡用の開発者メールアドレスに届きます。テストで管理画面から追加した Webhook では、ストアオーナーにメールは届かず、管理画面にも失敗は表示されませんでした。
Shopify がリトライをやめた注文を取り戻すには？
障害の期間を Admin API に照会し、その結果を通常のハンドラーに通します。重複排除は有効にしておきます。手順は「Shopify に Webhook を削除された」にあります。
サーバーのダウン中も Shopify の Webhook を失わない最善の方法は？
エンドポイントの前に Webhook 中継サービスかキューを置きます。それが Shopify に応答し、イベントを保存し、より長いスケジュールでサーバーへの配信をリトライします。管理画面で追加した Webhook や小規模なアプリなら、最小の変更は AnyHook です。変えるのは URL 1 つだけで、Free プランがあり、有料プランならより長くリトライし、1 日の上限もありません。変換処理やチームのワークフローが必要なプラットフォームチームには、Hookdeck が合います。AWS や Google Cloud 上のアプリは、代わりにサブスクリプションを EventBridge や Pub/Sub に送れます。どの場合でも、Admin API に対する照合ジョブは残してください。
テストの方法
テストは 2026年11月2日に、Shopify の開発ストアで実施しました。API バージョンは 2026-10、トピックは orders/create です。Webhook はどちらも管理画面で追加しました。受信サーバーは Cloudflare Worker で、すべてのリクエストを記録し、17:43 UTC までは 503、その後は 200 を返しました。4 件の注文は 11:46〜12:06 UTC の間に入れました。
直接の Webhook での正確な到着時刻です。単位は X-Shopify-Triggered-At からの秒数です。
| 試行 | 4 件の注文全体 |
|---|---|
| 1 | 1.4〜1.9 |
| 2 | 2.3〜2.9 |
| 3 | 63.3〜64.2 |
| 4 | 183.6〜185.0 |
| 5 | 484.4〜485.8 |
| 6 | 1805.4〜1806.5 |
| 7 | 3606.2〜3607.4 |
| 8 | 7207.0〜7208.2 |
| 9 | 14407.7〜14409.0 |
うまくいかなかった点が 2 つあります。こちらのミスで、12:20 UTC ごろに受信サーバーが数分だけ復旧しました。直接の試行はその間に入りませんでしたが、最初の注文の AnyHook 経由の分は入ったので、その注文は AnyHook の結果から除いています。また、受信サーバーが署名の検証を始めたのは途中からなので、どちらの経路でも最初のほうの試行は未検証です。
タイムアウトや接続拒否はテストしていません。テストしたのは、すぐに返る 503 だけです。Admin API で作成したサブスクリプションもテストしていないので、上の削除のルールは Shopify のドキュメントに基づいています。本番のストアや大量のトラフィックもテストしていません。注文 4 件はサンプルとしては少数ですが、これほど規則的なスケジュールがノイズである可能性は低いです。これらはどれも Shopify が変更する可能性があるので、上の日付を確認してください。