EC在庫連携のタイムラグで売り越す？CSV・在庫同期・外部連携の判断基準

ECと倉庫・店舗・在庫管理サービスの間で在庫数がずれ、欠品や売り越しの確認作業が発生している中小EC事業者向けの記事です。

在庫を複数の場所で更新していると、未出荷分が片方にだけ反映される、古いCSVで在庫を戻す、倉庫の更新がECへ届く前に注文を受ける、といったずれが起こります。

まず1商品だけ選び、「最終的に正しい在庫数を決める場所」「受注時に在庫を減らす時点」「未出荷・取消・返品の反映場所」「CSVや外部連携が更新する時点」を時系列で書いてください。

結論：同期を速くする前に、在庫の基準と更新時点を決める

在庫差異があるからといって、すぐにリアルタイム連携や新しい在庫システムが必要とは限りません。まず、どの画面・サービスの在庫数を基準にするのか、注文を受けた時点で何個を確保するのかを決めます。

標準機能やCSVで安全に更新できるなら、その方法を優先します。外部連携を増やすのは、正しい在庫の場所が決まっているのに、反映の遅れや二重更新が継続して売り越しにつながる場合です。

「正本」は、最終的に正しいとする在庫の場所

ここでいう正本は、在庫数が食い違ったときに最終的に正しいと判断する画面・サービスのことです。EC、倉庫、店舗、外部の在庫管理サービスのすべてを更新元にすると、どの数字へ戻すべきか分からなくなります。

未出荷注文をいつ在庫から差し引くか確認する

Shopifyの例では、Availableは販売可能な数量、Committedは未出荷注文などに確保された数量として別に扱われます。同じ「在庫」でも、販売可能数と未出荷分では意味が異なります。

これはShopifyの例です。別のECでは名称や計算方法が異なるため、利用中サービスで「販売できる数」と「受注済みで確保した数」がどこに表示されるか確認してください。

CSVは古い在庫で上書きしないか確認する

CSVを出力してから取り込むまでに注文が入ることがあります。その変化を無視して古い在庫数を上書きすると、売り越しの原因になります。

Shopifyの在庫CSVでは、All states形式で現在値と更新値を使った確認が用意され、出力後に在庫が変わった行は取り込まれません。一方、AvailableのみのCSVには同じ保護がありません。

この仕組みを他のECへ一般化せず、利用中サービスで「取込前に現在値を比較するか」「差分更新か全件更新か」「古いCSVを取り込んだ場合どうなるか」を確認します。

同期頻度は遅延時間だけで決めない

更新が数分遅れること自体より、その間に在庫切れ商品を受注する可能性と、欠品時の連絡・返金・キャンセル対応への影響が重要です。

定期的なCSV更新で十分なら、リアルタイム連携へ広げない方が運用は単純です。店舗販売や複数チャネルの受注が頻繁で、反映遅れが売り越しに直結する場合に連携方法を見直します。

4つの方法を順番に比較する

方法	向いている状態	確認すること
現在の運用を整理	在庫の基準が曖昧	正しい在庫の場所、担当者、更新時点
ECの標準在庫機能	未出荷分や利用可能数を標準で管理できる	受注時の確保、取消・返品の戻し方
CSV運用	定期更新で業務上間に合う	現在値確認、差分・全件、取込頻度
必要部分だけ外部連携	基準は決まっているが反映遅れが売り越しにつながる	更新元、反映先、失敗時の再処理

自社で5分で確認するなら1商品だけ

1. 最近、在庫差異が出た商品を1つ選ぶ
2. EC・倉庫・店舗のどこを正しい在庫とするか書く
3. 注文時に在庫がどこで減るか書く
4. 未出荷・取消・返品で数が戻る場所を書く
5. CSV・外部連携が更新する時点を書く

ここまで分かれば、設定やCSV運用の見直しで足りるのか、必要部分だけ連携すべきかを相談できます。

相談先を分ける

標準在庫機能やCSVの仕様で解消できる場合は、まず利用中のEC・在庫管理サービスの提供元へ確認します。

複数のシステム間で在庫の基準は決まっているのに、更新の遅れや二重入力が残る場合は、連携部分の見直し対象です。ENOLではCSVを含む業務運用、既存システムの必要箇所だけの改修、段階移行を相談範囲として案内しています。

EC制作・外部連携の費用範囲を見る

業務システムの部分改修を見る

EC在庫連携について相談する