相談事例 /
ec-rescue
年商18億のEC事業者、繁忙期前夜に決済が止まった ─ Shopify Plus 移行直後の障害を48時間で復旧
課題
Shopify Plus への移行直後、決済プロセッサとの連携が断続的に失敗。母の日繁忙期を3日後に控え、決済失敗率が28%まで悪化していた。
解決策
Webhook 経路の冗長化、決済リトライ機構、Shopify Flow による異常検知の3本立てで対応。並行して既存プロセッサとのフォールバック経路を48時間以内に整備。
成果
母の日商戦の3日前に決済失敗率を0.4%まで改善。当日は注文数 過去最高 8,400件を処理しダウンタイムゼロ。繁忙期売上は前年同月比 +34%。
5月10日（金）の17:42。年商18億の食品EC企業から、緊急相談フォームに長文の依頼が入った。「Shopify Plus への移管を1週間前にやったばかり。決済が3日前から不安定で、本日12時時点の決済失敗率28%。母の日商戦は5月13日（月）。このままでは数千万円規模の機会損失」。
受注ピークまでの猶予は約60時間。電話で5分話して、その日のうちに作業に入ることを決めた。
## ヒアリングで判明した状況
移行プロジェクトは EC-CUBE 4 から Shopify Plus への乗り換え。移行作業自体は Shopify Plus パートナーの A社が担当していた。商品データ12,000SKU、過去注文データ86万件、会員データ23万件を移行済み。サイトデザインも移植済み。
問題は決済プロセッサだった。EC-CUBE では SBペイメントサービス（SBPS）を使っていたが、Shopify Plus に SBPS の公式コネクタが存在しない。A社の判断で、Shopify Payments（Stripe ベース）に切り替えていた。
Shopify Payments への切替自体は妥当な判断だが、Shopify Payments と SBPS では、決済処理の挙動が違う。特にカード会社からの 3D Secure 認証の戻り経路が違う。さらにこの会社では、注文確定後に自社のWMS（倉庫管理システム）にWebhookで注文情報を流す仕組みがあり、Webhook が間欠的に失敗していた。
決済失敗の真因は3つあった。
1つ目は 3D Secure 認証画面でユーザーが離脱するケース。Shopify Payments のデフォルトでは、3D Secure 失敗時に再試行を促す UI が出ない。ユーザーは「失敗した」と思って離脱する。
2つ目は Webhook 失敗の連鎖。Shopify から WMS への Webhook が失敗すると、Shopify は5回まで自動リトライするが、その間に在庫情報がズレる。結果として「在庫ありで決済通った」が「実は在庫なし」となり、注文がエラーキャンセルされる。
3つ目は不正検知の閾値。Shopify の Fraud Filter が、新規ドメインからの大量決済を異常と判定して保留にしていた。移行直後でドメインのレピュテーションが蓄積されていないことが原因。
## 48時間の作業
5月10日（金）夜：問題分解とアプリ選定。Webhook の信頼性問題には Shopify Flow と自社の Pub/Sub 経由の二重化で対応する設計を確定。3D Secure 離脱には Bold Subscriptions の決済再試行 UI を流用する案を採用。Fraud Filter は管理画面で閾値を一時調整。
5月11日（土）：実装。Cloudflare Workers で Webhook 中継レイヤを構築し、Shopify からの注文 webhook を受け取った時点で①WMSに送る②失敗時は Cloudflare D1 にキューイング③1分後にリトライ④5分後にもう1度⑤それでも失敗なら Slack に緊急通知、という多段リトライを実装。WMS側のレスポンスタイムを計測すると、平均420ms だが p99 で4.2秒。これが Shopify の Webhook タイムアウト（10秒）を逼迫していた。WMS側のキャッシュ層も挟んで応答を 150ms 平均まで改善。
5月12日（日）午前：本番投入とテスト。10件のテスト注文を実施し、全件成功を確認。決済失敗率を15分単位で監視するダッシュボードを Looker Studio で構築。社内オペレーターに緊急時の対応フローを5ページのマニュアルで共有。
5月12日（日）午後：負荷試験。母の日と同等の注文集中を仮想試験。同時60注文を5分間流して全件正常完了を確認。
5月13日（月）：本番。朝9時から監視開始。10時から注文ペースが加速し、ピーク時間（19:00-22:00）に毎分120件のペースで注文が入った。決済失敗率は終日 0.4% 以下。Webhook 失敗は3件発生したがすべてリトライ機構で正常処理。
## 結果
母の日当日の注文数 8,400件は、この企業の過去最高だった。前年同月比 +34%。ダウンタイムなし。決済失敗起因のキャンセルゼロ。
移行プロジェクトの責任者は「正直、ローンチ延期を覚悟していた。3日前の電話で『48時間で間に合わせる』と言われた時、半信半疑だった」と後日語った。
## このプロジェクトから得た示唆
Shopify Plus への移行は、技術的に難しい話ではない。難しいのは、既存業務との接続点の数だ。決済、WMS、会計、CRM、メール配信、レコメンドエンジン、それぞれが独自の作法を持っており、それらを Shopify の Webhook 設計に乗せ替える作業に隠れた工数がある。
もう1つ。移行直後はドメインレピュテーションが蓄積されておらず、Fraud Filter のような自動防御機構が過剰反応しやすい。これは数週間で自然に解消するが、繁忙期と重なると致命傷になる。移行のスケジュールは、繁忙期の最低6週間前には完了させるべきだ。
そして3つ目。Shopify 上で動く Webhook は、必ず中継層を挟むべきだ。Shopify から直接 WMS / ERP に流すと、相手側のダウンや遅延でデータロスが起きる。Cloudflare Workers / AWS Lambda / Google Cloud Functions あたりで中継し、リトライとキューイングを実装する。今回の現場ではこれが命綱になった。
受注ピークまでの猶予は約60時間。電話で5分話して、その日のうちに作業に入ることを決めた。
## ヒアリングで判明した状況
移行プロジェクトは EC-CUBE 4 から Shopify Plus への乗り換え。移行作業自体は Shopify Plus パートナーの A社が担当していた。商品データ12,000SKU、過去注文データ86万件、会員データ23万件を移行済み。サイトデザインも移植済み。
問題は決済プロセッサだった。EC-CUBE では SBペイメントサービス（SBPS）を使っていたが、Shopify Plus に SBPS の公式コネクタが存在しない。A社の判断で、Shopify Payments（Stripe ベース）に切り替えていた。
Shopify Payments への切替自体は妥当な判断だが、Shopify Payments と SBPS では、決済処理の挙動が違う。特にカード会社からの 3D Secure 認証の戻り経路が違う。さらにこの会社では、注文確定後に自社のWMS（倉庫管理システム）にWebhookで注文情報を流す仕組みがあり、Webhook が間欠的に失敗していた。
決済失敗の真因は3つあった。
1つ目は 3D Secure 認証画面でユーザーが離脱するケース。Shopify Payments のデフォルトでは、3D Secure 失敗時に再試行を促す UI が出ない。ユーザーは「失敗した」と思って離脱する。
2つ目は Webhook 失敗の連鎖。Shopify から WMS への Webhook が失敗すると、Shopify は5回まで自動リトライするが、その間に在庫情報がズレる。結果として「在庫ありで決済通った」が「実は在庫なし」となり、注文がエラーキャンセルされる。
3つ目は不正検知の閾値。Shopify の Fraud Filter が、新規ドメインからの大量決済を異常と判定して保留にしていた。移行直後でドメインのレピュテーションが蓄積されていないことが原因。
## 48時間の作業
5月10日（金）夜：問題分解とアプリ選定。Webhook の信頼性問題には Shopify Flow と自社の Pub/Sub 経由の二重化で対応する設計を確定。3D Secure 離脱には Bold Subscriptions の決済再試行 UI を流用する案を採用。Fraud Filter は管理画面で閾値を一時調整。
5月11日（土）：実装。Cloudflare Workers で Webhook 中継レイヤを構築し、Shopify からの注文 webhook を受け取った時点で①WMSに送る②失敗時は Cloudflare D1 にキューイング③1分後にリトライ④5分後にもう1度⑤それでも失敗なら Slack に緊急通知、という多段リトライを実装。WMS側のレスポンスタイムを計測すると、平均420ms だが p99 で4.2秒。これが Shopify の Webhook タイムアウト（10秒）を逼迫していた。WMS側のキャッシュ層も挟んで応答を 150ms 平均まで改善。
5月12日（日）午前：本番投入とテスト。10件のテスト注文を実施し、全件成功を確認。決済失敗率を15分単位で監視するダッシュボードを Looker Studio で構築。社内オペレーターに緊急時の対応フローを5ページのマニュアルで共有。
5月12日（日）午後：負荷試験。母の日と同等の注文集中を仮想試験。同時60注文を5分間流して全件正常完了を確認。
5月13日（月）：本番。朝9時から監視開始。10時から注文ペースが加速し、ピーク時間（19:00-22:00）に毎分120件のペースで注文が入った。決済失敗率は終日 0.4% 以下。Webhook 失敗は3件発生したがすべてリトライ機構で正常処理。
## 結果
母の日当日の注文数 8,400件は、この企業の過去最高だった。前年同月比 +34%。ダウンタイムなし。決済失敗起因のキャンセルゼロ。
移行プロジェクトの責任者は「正直、ローンチ延期を覚悟していた。3日前の電話で『48時間で間に合わせる』と言われた時、半信半疑だった」と後日語った。
## このプロジェクトから得た示唆
Shopify Plus への移行は、技術的に難しい話ではない。難しいのは、既存業務との接続点の数だ。決済、WMS、会計、CRM、メール配信、レコメンドエンジン、それぞれが独自の作法を持っており、それらを Shopify の Webhook 設計に乗せ替える作業に隠れた工数がある。
もう1つ。移行直後はドメインレピュテーションが蓄積されておらず、Fraud Filter のような自動防御機構が過剰反応しやすい。これは数週間で自然に解消するが、繁忙期と重なると致命傷になる。移行のスケジュールは、繁忙期の最低6週間前には完了させるべきだ。
そして3つ目。Shopify 上で動く Webhook は、必ず中継層を挟むべきだ。Shopify から直接 WMS / ERP に流すと、相手側のダウンや遅延でデータロスが起きる。Cloudflare Workers / AWS Lambda / Google Cloud Functions あたりで中継し、リトライとキューイングを実装する。今回の現場ではこれが命綱になった。