在庫・Webhook緊急度:高
Shopify Webhook 500エラーによる自動配信停止と再試行設計(Dead Letter Queue)
症状・エラーコード
Webhook delivery failed / 注文データが外部システム(POSや倉庫)に連携されない
注文発生時のWebhookが自社サーバーや外部ツールのタイムアウト等で500/504を返し、Shopify側からWebhookの自動購読が解除されてしまう障害。
なぜこのエラーが発生するのか?(根本原因)
ShopifyはWebhookエンドポイントが一定回数以上連続で失敗(4xx/5xx)すると、自動的にそのWebhookサブスクリプションを無効化します。また、5秒以内の200 OK応答がないとタイムアウト扱いになります。
解決のための具体的な手順
1
即時 200 OK 応答+非同期キューイングの導入
Webhookを受信した瞬間にステータス200を返し、重い処理(外部API連携等)はバックグラウンドキュー(Redis / SQS / Cloudflare Workers)へ委譲。
// FastAPI / Python 非同期受信用エンドポイント例
@app.post("/webhooks/orders/create")
async def handle_order_webhook(request: Request, background_tasks: BackgroundTasks):
raw_body = await request.body()
# 署名検証 (HMAC SHA256)
verify_shopify_hmac(request.headers, raw_body)
# 重い処理をバックグラウンドに逃がして即時200を返す
background_tasks.add_task(process_order_to_pos, json.loads(raw_body))
return JSONResponse(content={"status": "received"}, status_code=200)2
HMAC SHA256 署名検証の厳格化
改ざんされた不正リクエストを弾きつつ、正規のリクエストのみをキューへ流す。
3
Dead Letter Queue (DLQ) と障害アラートの実装
連携先システムがダウンしていても、失敗データを保持して復旧後にワンクリック再送できる管理画面を構築。
再発防止のためのアーキテクチャ設計指針
Webhook受信サーバーで重いSQLや外部API通信を同期実行しないこと。必ずキューイングアーキテクチャを採用してください。
トラブルシューティング FAQ
Q. Webhookが止まってしまった間の過去注文はどう復元しますか?
A. Shopify Admin API(GraphQL)から注文ID範囲を指定して差分バッチ取得し、抜け落ちた注文を一括同期します。
緊急改修・レスキュー代行
20万〜40万円
自社での改修リソースが不足している場合や、原因特定が難航している場合は、Shop-Wizのレスキューチームが即日調査に入ります。
緊急レスキューを依頼する AI見積もりで改修工数を試算