<p>EC事業者からの夜間相談で、決済タイムアウトと並んで多いのが「注文が管理画面に出てこない」というものです。サンクスページは正常に表示され、ユーザにも完了メールが届いている。それなのに Shopify の管理画面、EC-CUBE の受注一覧、楽天 RMS の注文照会、どこを見ても該当注文が出てこない。出荷担当からは「在庫だけ減って受注が無い」と連絡が入る。販売機会の損失だけでなく、在庫差異が決算まで尾を引きます。</p>
<p>原因は実装の層によって全く違います。フロントエンドの JavaScript 側で送信が失敗しているのか、API 経路で書き込みが落ちているのか、Webhook の取りこぼしか、CMS 側のバッチ反映遅延か。最初の切り分けを間違えると、何時間も無駄な調査が続きます。</p>
<p><strong>Shopify で起きる典型: アプリ連携の Webhook 失敗</strong></p>
<p>Shopify 本体側はほぼ落ちません。問題は外部アプリとの連携です。受注を社内 ERP や出荷管理 SaaS（ロジレス、ネクストエンジン、CROSS MALL）に連携している構成では、Shopify の <code>orders/create</code> Webhook を受けて連携先 API へ転送する実装が一般的です。この Webhook が届かない、もしくは届いても連携先の API エラーで取りこぼされている、というのが頻発します。</p>
<p>確認は Shopify Admin の「設定 → 通知 → Webhook」セクションで配信履歴を見ます。直近の失敗率が 1% を超えていたら異常事態です。Shopify は失敗時に最大 19 回まで指数バックオフで再送し、48 時間で諦めます。連携先のメンテナンスや TLS 証明書切れがこの 48 時間にかかっていれば、そのままロストです。</p>
<p>もうひとつ Shopify 特有の罠が、Checkout UI Extensions と Shopify Functions の不整合です。チェックアウト拡張で住所バリデーションを入れていると、特定パターン（半角全角混在、機種依存文字、「丁目」「番地」の表記揺れ）で JavaScript が例外を投げ、サンクスページには進むのに注文オブジェクトが作成されないケースがあります。Shopify Plus のスクリプトエディタを併用している古い構成は要注意です。</p>
<p><strong>EC-CUBE で起きる典型: DB 行ロック競合と決済モジュールの闇</strong></p>
<p>EC-CUBE 4 系で注文が消える場合、まず疑うのは決済モジュールです。GMO ペイメント、ペイジェント、ソニーペイメント、いずれも公式モジュールが配布されていますが、決済プロセッサの Webhook 受信後に EC-CUBE の <code>dtb_order</code> テーブルへ書き込む処理が同期トランザクションになっており、ピーク時に行ロックで詰まります。<code>order_status_id</code> を更新するクエリがロック待ちで 90 秒待たされ、最後にデッドロックで巻き戻され、ユーザには「決済完了」だけが残ります。</p>
<p>EC-CUBE のログは <code>var/log/site/yyyymmdd.log</code> に出ますが、デフォルトでは INFO レベルしか出力されません。<code>config/packages/monolog.yaml</code> で <code>level: debug</code> に上げ、再現を待ちます。<code>Lock wait timeout exceeded</code> や <code>Deadlock found when trying to get lock</code> が出ていれば、MySQL 側の <code>innodb_lock_wait_timeout</code> と決済モジュールのトランザクション境界を見直します。</p>
<p>もう一点、EC-CUBE 4 の在庫引当ロジックは商品テーブルに <code>SELECT ... FOR UPDATE</code> を使います。同一商品に同時注文が 10 件以上集中すると、最後尾の処理が 30 秒以上待たされ、PHP の <code>max_execution_time</code> に引っかかって Fatal で落ちます。在庫だけ引かれて受注は無い、という最悪パターンが、ここから生まれます。</p>
<p><strong>楽天市場で起きる典型: RMS 反映遅延と店舗 ID 不一致</strong></p>
<p>楽天市場では、注文情報そのものは楽天側システムに即座に登録されますが、RMS（店舗管理ツール）の受注一覧画面への反映には 5 分から最大 30 分の遅延があります。「注文が入ってこない」と相談された場合、まずは 30 分待ってもらうのが正解です。</p>
<p>30 分経っても反映されない時に疑うのは、店舗側で運用している在庫連携ツールの設定ミスです。CROSS MALL や GoQSystem 経由で楽天と自社 EC、Amazon を同期している店舗で、楽天側の店舗 ID と社内マスタの店舗コードが一字違いになっていて、注文取得 API のレスポンスが空になっているケースが定期的に出ます。楽天ペイ注文 API の <code>orderProgressList</code> で取得結果を直接 cURL で確認し、API レスポンスには注文があるのに自社側に降りていなければ、連携ツール側の問題で確定です。</p>
<p>楽天ペイ注文 API には 1 分あたり 5 リクエストのレート制限があります。注文急増時にこのレート制限に引っかかると、連携ツール側がリトライを諦めて取りこぼします。<code>429 Too Many Requests</code> のレスポンスを連携ツールがログに残しているかを、まず確認します。</p>
<p><strong>調査の順番</strong></p>
<p>注文消失の調査は、ユーザ目線から逆順にたどります。サンクスページの表示確認、完了メールの送信ログ確認、決済プロセッサ側の課金履歴確認、ここまでが「決済は成立した」の証拠固めです。次に、EC プラットフォーム側のオーダー API を cURL で直接叩いて、注文が存在するかを確認します。プラットフォームには有るのに管理画面に無い場合、99% は連携ツールか Webhook の問題です。プラットフォームにも無い場合、決済成立後のオーダー作成 API が落ちています。</p>
<p>この切り分けを 30 分以内に終わらせないと、追加の注文が次々と消えていきます。出荷オペレーションは止めず、過去 24 時間の注文を別経路で取得して突合させるのを並行で進めます。決済プロセッサ側の CSV、Google Analytics 4 の e コマースイベント、注文完了メールの送信ログ、この 3 つを突合すれば消えた注文はほぼ全件捕まります。原因の特定と恒久対策は、その後でかまいません。止血を最優先するのが、EC 障害対応の鉄則です。</p>
<p>原因は実装の層によって全く違います。フロントエンドの JavaScript 側で送信が失敗しているのか、API 経路で書き込みが落ちているのか、Webhook の取りこぼしか、CMS 側のバッチ反映遅延か。最初の切り分けを間違えると、何時間も無駄な調査が続きます。</p>
<p><strong>Shopify で起きる典型: アプリ連携の Webhook 失敗</strong></p>
<p>Shopify 本体側はほぼ落ちません。問題は外部アプリとの連携です。受注を社内 ERP や出荷管理 SaaS（ロジレス、ネクストエンジン、CROSS MALL）に連携している構成では、Shopify の <code>orders/create</code> Webhook を受けて連携先 API へ転送する実装が一般的です。この Webhook が届かない、もしくは届いても連携先の API エラーで取りこぼされている、というのが頻発します。</p>
<p>確認は Shopify Admin の「設定 → 通知 → Webhook」セクションで配信履歴を見ます。直近の失敗率が 1% を超えていたら異常事態です。Shopify は失敗時に最大 19 回まで指数バックオフで再送し、48 時間で諦めます。連携先のメンテナンスや TLS 証明書切れがこの 48 時間にかかっていれば、そのままロストです。</p>
<p>もうひとつ Shopify 特有の罠が、Checkout UI Extensions と Shopify Functions の不整合です。チェックアウト拡張で住所バリデーションを入れていると、特定パターン（半角全角混在、機種依存文字、「丁目」「番地」の表記揺れ）で JavaScript が例外を投げ、サンクスページには進むのに注文オブジェクトが作成されないケースがあります。Shopify Plus のスクリプトエディタを併用している古い構成は要注意です。</p>
<p><strong>EC-CUBE で起きる典型: DB 行ロック競合と決済モジュールの闇</strong></p>
<p>EC-CUBE 4 系で注文が消える場合、まず疑うのは決済モジュールです。GMO ペイメント、ペイジェント、ソニーペイメント、いずれも公式モジュールが配布されていますが、決済プロセッサの Webhook 受信後に EC-CUBE の <code>dtb_order</code> テーブルへ書き込む処理が同期トランザクションになっており、ピーク時に行ロックで詰まります。<code>order_status_id</code> を更新するクエリがロック待ちで 90 秒待たされ、最後にデッドロックで巻き戻され、ユーザには「決済完了」だけが残ります。</p>
<p>EC-CUBE のログは <code>var/log/site/yyyymmdd.log</code> に出ますが、デフォルトでは INFO レベルしか出力されません。<code>config/packages/monolog.yaml</code> で <code>level: debug</code> に上げ、再現を待ちます。<code>Lock wait timeout exceeded</code> や <code>Deadlock found when trying to get lock</code> が出ていれば、MySQL 側の <code>innodb_lock_wait_timeout</code> と決済モジュールのトランザクション境界を見直します。</p>
<p>もう一点、EC-CUBE 4 の在庫引当ロジックは商品テーブルに <code>SELECT ... FOR UPDATE</code> を使います。同一商品に同時注文が 10 件以上集中すると、最後尾の処理が 30 秒以上待たされ、PHP の <code>max_execution_time</code> に引っかかって Fatal で落ちます。在庫だけ引かれて受注は無い、という最悪パターンが、ここから生まれます。</p>
<p><strong>楽天市場で起きる典型: RMS 反映遅延と店舗 ID 不一致</strong></p>
<p>楽天市場では、注文情報そのものは楽天側システムに即座に登録されますが、RMS（店舗管理ツール）の受注一覧画面への反映には 5 分から最大 30 分の遅延があります。「注文が入ってこない」と相談された場合、まずは 30 分待ってもらうのが正解です。</p>
<p>30 分経っても反映されない時に疑うのは、店舗側で運用している在庫連携ツールの設定ミスです。CROSS MALL や GoQSystem 経由で楽天と自社 EC、Amazon を同期している店舗で、楽天側の店舗 ID と社内マスタの店舗コードが一字違いになっていて、注文取得 API のレスポンスが空になっているケースが定期的に出ます。楽天ペイ注文 API の <code>orderProgressList</code> で取得結果を直接 cURL で確認し、API レスポンスには注文があるのに自社側に降りていなければ、連携ツール側の問題で確定です。</p>
<p>楽天ペイ注文 API には 1 分あたり 5 リクエストのレート制限があります。注文急増時にこのレート制限に引っかかると、連携ツール側がリトライを諦めて取りこぼします。<code>429 Too Many Requests</code> のレスポンスを連携ツールがログに残しているかを、まず確認します。</p>
<p><strong>調査の順番</strong></p>
<p>注文消失の調査は、ユーザ目線から逆順にたどります。サンクスページの表示確認、完了メールの送信ログ確認、決済プロセッサ側の課金履歴確認、ここまでが「決済は成立した」の証拠固めです。次に、EC プラットフォーム側のオーダー API を cURL で直接叩いて、注文が存在するかを確認します。プラットフォームには有るのに管理画面に無い場合、99% は連携ツールか Webhook の問題です。プラットフォームにも無い場合、決済成立後のオーダー作成 API が落ちています。</p>
<p>この切り分けを 30 分以内に終わらせないと、追加の注文が次々と消えていきます。出荷オペレーションは止めず、過去 24 時間の注文を別経路で取得して突合させるのを並行で進めます。決済プロセッサ側の CSV、Google Analytics 4 の e コマースイベント、注文完了メールの送信ログ、この 3 つを突合すれば消えた注文はほぼ全件捕まります。原因の特定と恒久対策は、その後でかまいません。止血を最優先するのが、EC 障害対応の鉄則です。</p>
この症状でお困りなら、まず無料相談
60分無料相談を予約