実務ガイド
「海外倉庫の在庫が合わない＝現地3PLの入力ミス」だけで片付けると、同じ事故が翌週も起きます。越境ECでは、本社のカート／OMSと、現地WMS・3PLポータルが別系統で動くことが多く、同期の遅れがオーバーセル（売り越し）を生みます。Shopify開発者向け文書でも、注文が入ると販売可能在庫が減り、アプリや3PLが拠点ごとの数量を照会・調整する、という役割分担が前提です。本記事では誤解を正し、最低限の点検表を先に置きます。
障害票を書く前に、社内で先に作るのは次の表です。「拠点（国・3PL名）／在庫の正本（WMS／3PL／EC）／同期方式（イベント／バッチ）／最終成功時刻／確認日」。例：「米国西岸3PL／WMS正本／Webhook＋日次突合／2026-08-25 14:00 UTC／2026-08-25」。
空欄の正本は未確認と書き、ベンダー定例の前に埋めます。「在庫が合わない」一語のチケットは、エンジニアにも倉庫にも届きません。表ができたら、EC運用と物流で同じファイルを共有します。
この1点を先に決める理由は、拠点ごとに正本が違うからです。自社倉庫ならWMS、3PLなら3PL側、店舗POSなら店舗側、という切り分けが一般的です。正本が空のままAPIを増やすと、古い数が戻ってきます。
表の更新ルールは簡単です。同期ジョブの成功ログが変わったら最終成功時刻だけ差し替えます。正本列は契約変更のときだけ更新します。繁忙期の前週には、全拠点の最終成功時刻が24時間以内であることをゲートにします。ゲートを通らない拠点は、広告の増枠対象から外します。例外運用は禁止です。
手入力ミスは起きます。ただし、典型パターンはそれだけではありません。バッチ同期が1時間に1回なら、その間の受注・入出庫はEC側に遅れます。Webhookが落ちても気づけない設計なら、欠落が溜まります。
Shopifyの在庫管理アプリ向け文書では、注文が入ると販売可能数量が減り、コミット済み数量が増える、といった状態遷移が説明されます。アプリや3PLは、拠点の数量を照会し、状態間の移動や調整を自動化できます。ここで「誰がいつ、どの状態を正として書くか」が曖昧だと、ズレは構造問題になります。
現場では、「3PLポータルの画面」と「ECの販売可能数」を同じ瞬間に見比べて怒ることが多いです。見る瞬間が違うと、どちらも正しくても一致しません。比較するときは、時刻をUTCで揃えてスクショを残します。時刻が無いスクショは、後から原因を切れません。
取り違えを減らす質問は1つです。「いま比較している数字は、同じ拠点・同じ状態・同じ時刻か」。答えがNoなら、チケットの件名を「入力ミス」にしない方がよいです。件名を「同期遅延疑い」に変えるだけで、初動が変わります。
イベント連携は有効です。ただし、Webhookは取りこぼしや遅延があり得ます。Shopifyの文書でも、在庫関連Webhookのトピックが列挙される一方で、コミット済みや予約など一部の状態変更はWebhookを発火しない、という注記があります。イベントだけで完結させない方が安全です。
実務の型は二段です。一段目は、入出庫・調整のイベントをできるだけ早くECへ返す。二段目は、定期の突合（リコンシリエーション）でドリフトを拾う。一段目だけだと欠落が残り、二段目だけだと売れ筋ピークで遅れが残ります。二段の担当者が別チームでも、同じダッシュボードを見ます。
「リアルタイム」の定義も社内で揃えます。秒単位なのか、5分なのか、1時間なのか。定義が空のままベンダーに依頼すると、成果物のSLAが決まりません。SLAの文面には、欠落時の再送期限も書きます。
GraphQL Admin APIには、差分で増減する調整と、数量を明示的にセットする操作があります。古い数値を上書きする経路が残っていると、イベント連携の成果が消えます。上書き経路の一覧を先に作り、誰が実行できるかを権限表に落とします。
越境でよくあるのは、本社がECの在庫を正本だと信じ、現地はWMSを正本だと信じている状態です。両方から同じSKUに書き込むと、後勝ちで数が戻ります。特に、EC側で手動調整したあと、夜間バッチがWMSの古いスナップショットを戻すパターンが強いです。
拠点が複数ある場合、ある拠点の出荷が他拠点の数量を自動では減らしません。これは仕様として正しいことが多いです。問題は、外部システムが「どの拠点で減ったか」を知らないまま全拠点へ同じ数を戻すことです。
3PL契約書に「在庫APIの更新頻度」と「障害時の連絡窓口」が無い場合、運用は口頭になります。口頭の同期は、繁忙期に一番壊れます。契約の改定前でも、運用合意書に頻度と窓口を書いてください。窓口の返信SLAも、同じ合意書に1行足します。
二重正本を防ぐ実務は、書き込み権限の一本化です。在庫を更新できるシステムを1つに絞り、他のシステムは参照のみに制限します。参照側でどうしても書き込みが必要になった時点で、正本の設計そのものを見直します。
オーバーセルは、販売可能と表示した数量を超えて受注することです。結果として、キャンセル、遅延連絡、返金、レビュー低下が続きます。キャンセル率や星評価の「平均悪化幅」は業種・国で差が大きく、単一の％を一般法則のように書くのは避けます（個別計測が必要）。自社の直近90日で、オーバーセル起因のキャンセル件数だけでも十分です。
痛みの本質は、カスタマーサポートの工数が増えることと、広告のCVRが下がることです。在庫が合わない週は、広告を止めずに在庫を盛ると、事故が広告費で増幅します。先に販売可能数を安全側へ寄せ、広告は後です。
海外では、配送遅延の許容度や返品ルールが市場ごとに違います。同じキャンセルでも、レビュー文言の刺さり方が変わります。国別のCSテンプレを用意していないと、現場が毎回作文します。
計測の最低セットは、「オーバーセル件数／原因拠点／同期遅延分／キャンセル理由コード」です。理由コードが「その他」ばかりなら、まだ原因が切れていません。週次で「その他」比率を下げると、改善が見えます。
1つ目は、拠点ごとの正本を1つに決めること。2つ目は、イベント連携と定期突合の二段を持つこと。3つ目は、Webhook欠落を想定した再送と監視。4つ目は、手動上書き経路の棚卸し。5つ目は、SKUマッピング（拠点SKUとECバリアント）の一意性。6つ目は、最終成功時刻のダッシュボード。7つ目は、繁忙期の一時バッファ（安全在庫状態の活用）。7つを全部一度に完璧にしなくて構いません。正本と最終成功時刻の2つだけでも、初週の事故は減ります。
Shopifyの在庫状態には、販売可能・コミット済み・予約・破損・安全在庫・品質検査などがあります。安全在庫は、売り越しを抑えるために手元数量を販売不可側へ寄せる用途として説明されます。バッファの置き場を「なんとなく非表示」にしない方がよいです。状態名を運用用語として統一します。
API面では、GraphQLの数量操作を前提に設計する事例が増えています。REST在庫エンドポイントを前提にした古い連携は、移行計画を別に持つ方が安全です（Shopifyの開発者向け説明に従い、最新ドキュメントを確認）。
チェックリストは、ベンダー定例のアジェンダ先頭に固定します。定例で「天気の話」から入ると、最終成功時刻が更新されません。
取り違え1は、画面の見た目が一致すれば同期が健全だと判断することです。取り違え2は、1拠点の修正を全拠点にコピーすることです。取り違え3は、キャンセル率の悪化を広告の問題だけに帰することです。
取り違え4は、「リアルタイム」という言葉で、突合ジョブを廃止することです。イベントと突合は補完関係です。どちらか一方に寄せた瞬間に、欠落か遅延のどちらかが残ります。
切り分けの質問は3つです。「正本は誰か」「最後に成功した同期はいつか」「上書きしたのは誰か」。3つが埋まったら、初めて3PLへエスカレーションします。
社内の障害レビューでは、人名より経路名を残します。経路が残ると、次の繁忙期に同じ穴を塞げます。
1行表のうち、正本が空の拠点を週次の先頭に置きます。空の拠点があるうちは、新規SKUの海外展開を増やさない方がよいです。正本が決まるまで、販売可能数は安全側に寄せます。
次のアクションは、主要3拠点まで仮置きし、各拠点の最終成功時刻を同じダッシュボードに並べることです。時刻が取れない拠点は、監視が無いのと同じです。ダッシュボードのURLを運用チャットの固定メッセージに貼ります。
海外倉庫の在庫ズレは、3PL批判で終わらせるほど再発します。正本と同期方式に切った瞬間に、会話が具体になります。
空欄の行が残る週は、勉強会を「在庫理論」だけで終わらせると効果が出にくいです。拠点担当を分け、同じ表を更新します。表が更新されない勉強会は、コストだけが残ります。更新された表が、次の繁忙期の初動マニュアルになります。
A. バッチ遅延、Webhook欠落、二重正本の上書きなど、システム設計側の原因が多いからです。比較時刻が違うだけ、というケースもあります。
A. 不十分です。イベントは取りこぼしがあり得るため、定期突合を併用する二段が安全です。一部の在庫状態変更はWebhookを発火しない、という注記もあります。
A. 拠点×正本×同期方式×最終成功時刻の1行表です。正本が空のままAPIを増やさない方がよいです。