複数モールの在庫連携｜同期のずれ・売り越しを防ぐ確認手順

倉庫の棚にある現物は最後の1個なのに、自社ECとモールAの両方で同時に注文が入ってしまい、手元にない商品をどう届けるべきか困り果てる――複数の売り場を運営していると、こうした在庫の食い違いに直面することがあります。

ここでは、帆布ポーチ24SKUを1箇所の倉庫から自社ECとモールAの2販路へ出品している架空の店舗を例に考えます。担当者は1名で、日々の在庫確認には20分、異常時の原因調査枠には60分をあて、追加の運用予算は月額5,000円（税込）という仮の作業枠を想定します。

複数店舗の間で在庫数がずれたとき、ツールの不具合と即断して設定を慌てて変更すると、かえって原因の切り分けが難しくなります。まずは各販売先で表示されている数字の意味を整理し、注文が入ってから画面へ反映されるまでの経路を1商品ずつ落ち着いて確認していきましょう。

各店の在庫を足せば、持っている数になる？

自社ECに「残り10個」、モールAにも「残り10個」と表示されていても、手元の現物が合計20個あるわけではありません。同じ倉庫の現物を複数の店舗で同時に販売する「共有」の運用では、1つの在庫に対してそれぞれの販売先から注文窓口を開いている状態だからです。

SKU（色や型で分けた管理単位）で考えると、倉庫にある共通の現物10個を共有して出品している架空例の条件において、各画面に見えている「10」という数値は、その10個をどちらの店からも注文できる設定上の状態を示しているに過ぎません。画面の表示値は通信や処理の途中で未反映の場合もあるため、画面上の「10」という表示だけから手元に現物が10個あると推定することはできず、各店の表示数値を単純に合算して実在庫と見なすこともできません。

店舗ごとに販売枠を切り離したい場合は、販路別に確保した数量を管理する「専用在庫」の運用をとります。これは必ずしも物理的な棚を別々に分けることだけを指すのではなく、特定の売り場向けに出荷枠を確保して管理する形も含みます。共有販売なのか、販路別に確保した専用在庫なのかを区別し、倉庫にある現物合計そのものが曖昧になっているなら、連携設定を触る前に現地の棚卸を行って正確な数を確定させることが先決です。

どの在庫と商品コードを基準にする？

複数の売り場へ在庫数を正しく届けるには、どのシステムの数値を通常の更新元とし、どの計算値を送るかという基準を定めます。あわせて、各販路の出品と管理側の基準商品を正しく結びつける設定が欠かせません。

ここで重要になるのが「商品対応表」と「引当」です。商品対応表とは、販売先の商品と基準側の商品を結びつける表のことです。引当とは、受けた注文に対して在庫枠を確保し、他の注文へ回らないようにする処理を指します。

クラウド型在庫管理システムのLOGILESSを例に取ると、在庫連携はシステム側から各販売先へと一方向に数量を送信する仕組みです（LOGILESS 在庫連携の概要、2026年10月9日確認）。自社ECとモールAで同一の商品コードを使っていても、店舗ごとの商品対応表を個別に作成する必要があり、コードが同じでも省略できません。さらに、対象商品の自動在庫連携設定と、店舗ごとの受注自動取込設定の双方が有効になっていることが前提条件です。

基準となる数量の計算では、同一SKUにおいて倉庫の現物総数が10個あっても、検品待ちなどの「保留」が2個、他店で注文を受けて出荷待ちの「確保（引当）」が3個ある場合、新しく販売に回せる基準側の数量は「10個 − 保留2個 − 確保3個 ＝ 新規用5個」となります。各販売先への実際の送信量は、この基準側の新規用5個を算出した後に、後述する予備在庫や割当率などの設定を適用して決定されます。

なお、手元に未確認の数量があるときに勝手にゼロとして計算すると、保留や現物の把握が狂う恐れがあるため、未確認数量は別枠で記録して確かめます。また、緊急時に店舗側で直接数値を変更した際は、変更者と日時を記録に残すルールを決めておきます。

注文から、他店の在庫が減るまで何が起きる？

ある店舗で注文が入ったあと、別の店舗の画面上の在庫数が減るまでには複数の工程があります。受注取込から販売先反映までは一瞬で同時に完了する処理ではありません。

データの流れは、次の順序で進みます。

1. 注文受付：顧客が自社ECで注文を確定する
2. 受注取込：在庫管理システムがAPI（システム間でデータを受け渡す仕組み）などを経由して注文情報を取り込む
3. 引当：注文情報に基づいて在庫枠が確保され、システム内の出荷可能数（フリー在庫）が減少する
4. 在庫送信：変動した最新の在庫数が各販売先へ向けて送信される
5. 販売先反映：モールA側で購入ページや在庫データが更新される

LOGILESSでは、フリー在庫に変動があった商品を対象として、一定間隔で販売先へ一方向送信されます。すべての経路が瞬時に同期するわけではなく、注文が入ってから他店の画面が切り替わるまでには時間差が生じます。

したがって、「受注取込」や「送信済み」の記録と、「販売先での画面反映」は同一ではありません。遅延時間を固定的に推測するのではなく、送信ログの状態と販売先の実画面をそれぞれ確かめる必要があります。

最後の1個が、どうして2件売れる？

システムが正常に稼働していても、現物以上の注文が入ってしまう「売り越し」が発生することがあります。特に棚の在庫が残り1個になった場面では、注文から他店へ「0」が反映されるまでの隙間に別の注文が入ると、現物以上の注文が成立してしまいます。

ここで意識しておきたいのは、「受け付けた注文の数」と「手元にある商品の個数」は別であるという点です。架空店舗における処理の流れを見てみます。

• 14:00:00：自社ECで顧客がポーチ最後の1個を注文（注文受付：1件目）
• 14:00:30：在庫管理システムへ注文が取り込まれて引当が完了し、基準側のフリー在庫が「0個」に変動
• 14:00:35：モールAではまだ反映前で在庫「1個」と表示されており、別の顧客が注文を完了（注文受付：2件目）
• 14:01:00：モールAへ在庫「0個」のデータが届き、購入画面が「売り切れ」に更新

この結果、自社ECとモールAで合計2件・計2個の注文が成立し、現物1個に対して「不足1個」が発生します。

後からモールAの画面が「0個」に切り替わっても、すでに成立した既存の2件の注文が自動的に解消されるとは限りません。在庫データが「0」として送信・反映された事実だけでは既存注文の処理完了を確認できないため、販売先や決済の状態、対応担当を確認し、どちらの注文を出荷・取消・補充とするかを個別に判断して対処を進める必要があります。

数が違うとき、どこから調べる？

管理画面とモールの表示数が一致しないときは、まず設定による意図的な計算の違いがないかを確かめ、そのうえでデータの流れに沿って対象SKUの状況を調べます。

LOGILESSでは送信数量を調整する機能があり、計算の優先順位は次の通りです。

1. 予備在庫を差し引く
2. 在庫割当率を適用する
3. 上限値・下限値を適用する

たとえば、他の割当率や上限・下限が影響しない中立な条件において、予備在庫を「1」と設定している場合、フリー在庫が1個あっても「1 − 1 ＝ 0」と計算され、販売先には「0個」と送信されます。ただし、これは送信する計算値が0になる設定であり、実画面で実際に0個と反映されているかは目視での確認が必要です。

設定通りの差ではない場合は、対象SKUに絞って以下の項目を順番に確認します。

特に、販売先側で手動やCSVによって変更された値は、基準側のフリー在庫に新たな変動が起きなければ上書き送信されず残る場合があります。原因の切り分けを行う際は、いきなり全SKUを一括操作するのではなく、まずは問題の起きている対象SKUを特定してログと実画面を照合します。

少量の商品は、共有を続けていい？

在庫数が残り1個など極端に少なくなった商品や、短時間に注文が集中する商品では、共有連携を続けたまま売り切る運用に注意が必要です。更新間隔による時間差がある以上、自動連携だけで売り越しを完全に防ぐことはできません。

LOGILESSの公式案内でも、厳格な数量管理や販売制限が必要なSKU、非常に短時間で大量に販売されるSKUについては、在庫連携を行わないよう注意が促されています。このようなSKUに対しては、予備在庫の設定だけで連携を継続するのではなく、在庫連携そのものの対象から外す運用が基本です。

一方、通常商品で「残り1個になった」という自店の在庫状況に応じた判断としては、次のような運用の選択肢があります。

• 受付停止と1店専用販売：他販路での注文受付を停止し、未反映注文や確定状況を確認したうえで、残る1店舗に専用在庫として割り当てて売り切る。

なお、在庫割当率は計算上の送信割合を決める設定であり、現物を物理的に確保するものではありません。また、「在庫同期の無効化」と「販売先での注文受付停止」は別の操作です。同期を止めても販売先の受付が自動で止まるわけではないため、販売先の実画面で注文可否を必ず確認する必要があります。

何を確かめたら、販売を再開できる？

在庫のずれや売り越しが発生した際、数値を再送しただけで安全に再開できるわけではありません。再送は現在の数値を送り直す処理であり、販売先での処理完了や不足注文の解決を意味しないからです。

販売を再開する際は、対象SKUについて以下の全項目を点検し、状況を記録します。

再開判断の基準は、「現物数・送信数・表示数の3つの数字が完全に一致すること」ではありません。予備在庫などの設定に応じた整合性が取れているかが基準となります。確認テストを行う場合は、システム提供元が案内する方法を確認し、決済・通知・出荷への影響を考慮して進めます。

売り越しによって不足した既存注文の取消や返金は、販売先や決済手段によって自動で行われるか手動対応が必要かが異なります。そのため、再送操作だけで完了したとみなさず、自店の手順に従って対応担当を明確にします。

もし影響範囲が不明な項目があれば「調査中」として受付停止を維持し、正常性が確認できた商品から順に再開を判断します。日々の20分や異常時の60分という作業枠は復旧期限ではなく、事実を1つずつ確認するための目安です。焦らずに対象SKUの記録を揃えて対応を進めてください。

---

関連記事

• 実在庫と画面の差を棚卸で確認する
• ロット・期限による出荷対象を分ける
• ECのKPIを日次・週次・月次で確認する