在庫・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見積もりで改修工数を試算

他のトラブル解決記事を見る