在庫があるのに欠品するのはなぜ？受注と在庫を正しく同期する仕組み

「在庫表には12個あるのに、お客様へ欠品の連絡をしなければならない」。こんな状況が続くと、担当者は在庫表を信用できなくなります。ECサイト、電話注文、店頭販売など、受注経路が増えるほど問題は表面化しやすくなります。

原因を「入力ミス」と決めつける前に確認したいのが、受注のタイミングで在庫がどのように引き当てられているかです。この記事では、在庫管理と受注管理の数字が食い違う仕組みを整理し、自社に合った同期方法を選ぶための判断材料を紹介します。

「倉庫にある数」と「今、売ってよい数」は違う

例えば、倉庫に商品Aが12個あるとします。しかし、すでに注文を受けて出荷待ちの商品が7個、不良品や予備として販売できない商品が2個あれば、新しい注文を受けられるのは3個だけです。

・ 手持ち在庫：12個

・ 引当済み：7個

・ 販売不可：2個

・ 販売可能在庫：12 − 7 − 2 ＝ 3個

図1：手持ち在庫と販売可能在庫の違い（架空の数値例）

「在庫があるはずなのに欠品した」と感じるとき、実は倉庫の数と販売可能な数を混同していることがあります。このような在庫状態の区分は、Shopifyの公式ヘルプでも採用されています。ただし、区分の実装や名称は利用中のシステムで異なります。

欠品を生むのは、受注と在庫の間にある時間差

もう一つの典型例は、複数の販売経路で同じ商品を扱う場合です。販売可能在庫が残り3個のとき、ECサイトAで3個、ECサイトBで2個の注文がほぼ同時に入り、両方が「まだ3個ある」という古い数字を見ていたらどうなるでしょうか。

合計5個の注文に対して、販売できる在庫は3個です。 受注データを後からExcelに集計しても、受注時点の重複した販売判断は取り消せません。こうした事象は、担当者の注意だけでは防ぎにくい問題です。

原因はほかにもあります。商品コードが販路によって異なる、入荷と返品を同じルールで加算している、キャンセル時に引当が戻らない、倉庫をまたいだ在庫が販売先に割り当てられていない、といったケースです。

したがって、在庫を同期する設計では「何分おきに更新するか」だけでなく、どの時点で注文が確定し、どの時点で在庫を確保するかを先に決める必要があります。

最初に決めるのは「正しい在庫」を持つ場所

受注管理ソフト、販売管理ソフト、倉庫のExcel、ECモールが、それぞれ独自に在庫数を書き換える運用は、差異の原因を追いかけにくくします。まず、商品コード（SKU）と倉庫・拠点の単位ごとに、どの台帳を基準にするか決めます。

この基準となる台帳を、ここでは「在庫の正本」と呼びます。正本は新しいシステムである必要はありません。すでに運用している販売管理システムでも構いません。ただし、更新権限と受注・入出庫・返品・キャンセルの反映ルールを統一します。

例えば、受注を取り込んだら「受注済み」だけを記録するのではなく、対象SKU・拠点・数量を指定して販売可能数から引当を確保します。出荷時には手持ち在庫を減らす一方、対応する引当を解消します。受注時と出荷時に同じ数量を二重に減らさないことも重要です。

同時受注でも二重に売らないための処理順序

受注を処理する順番の一例は、次のとおりです。

1. 販路から受注情報を取り込み、注文IDを記録する。

2. 同じ注文を過去に処理していないか確認する。

3. 商品コードと出荷元倉庫を確定する。

4. 販売可能在庫が必要数量以上ある場合に限り、一つの不可分な処理として在庫を引き当てる。

5. 結果を記録し、各販路へ反映する。

6. 同期に失敗したものは再試行し、定期的に正本と販路を照合する。

図2：受注から引当、エラー復旧までの概念図

特に4番が要点です。「在庫を読む→残数を確認する→数を減らす」を別々に実行すると、二つの処理が同じ残数を読み、両方を成功させてしまう可能性があります。データベースの条件付き更新やトランザクションなどを使い、残数確認と引当の確定を競合しない形に設計します。

ただし、各ECモールが独立して注文を確定する場合、中央システムの引当だけで全モールの売り越しを完全に防ぐことはできません。 モール側の販売制御、販路別の配分、安全在庫、反映遅延を考慮した運用を組み合わせます。

APIでつないだだけでは、同期は完成しない

APIや通知機能を使えば更新を素早く伝えられますが、通信失敗や再送は想定しておく必要があります。例えば同じ注文通知が2回届いたとき、在庫を2回減らす処理では数字が合わなくなります。

対策は、注文IDなどを使った重複処理の防止です。また、更新通知は順番どおり届くとは限らないため、古い更新で新しい在庫数を上書きしない仕組みも必要です。Shopifyの開発者向け資料でも、通知の重複・順序の不確実性に加え、定期的なデータ照合が推奨されています。

実務では、同期エラーを「失敗したまま放置しない」設計が大切です。未処理件数、最終成功時刻、更新に失敗した商品、再試行結果を一覧で確認できるだけでも、異常に気づく速度が変わります。

Excel・CSV連携とAPI連携、どこまで必要？

Excel・CSVで十分なケースは、注文数が少なく、販売先も限定され、更新タイミングを業務上調整できる場合です。商品コードの統一や、受注ファイルと在庫台帳の差分チェックから始められます。ただし、CSVを1日1回読み込む方式では、次の読み込みまでの同時売り越しを防げません。

定期自動連携が向くケースは、手動転記が多い一方で、数分単位の更新遅れを許容できる業務です。CSV/APIの定期取得、変換、差分反映、エラーログをまとめて自動化する方法が考えられます。

リアルタイムに近いAPI連携が必要なケースは、複数販路で注文が集中する、在庫が少ない商品が多い、欠品による影響が大きい場合です。引当の競合制御、通知の再送対策、障害時の復旧まで含めた設計が必要です。外部サービスの仕様や契約によっては実現できない制御もあります。

ツールを依頼する前に、ここだけ整理する

仕様書を一から作る必要はありません。次の情報が分かれば、何を自動化でき、何を運用で補うべきか判断しやすくなります。

・ 受注経路：ECサイト、モール、電話、店頭など

・ 在庫の管理先：Excel、販売管理システム、倉庫システムなど

・ 商品を識別する情報：SKU、商品コード、倉庫・拠点

・ 現在の更新方法と頻度：手入力、CSV取込、APIなど

・ どんな不一致が起きるか：欠品、二重減算、キャンセル戻し漏れなど

・ 許容できる反映遅延と、エラー時に誰が確認するか

実データをそのまま送る必要はなく、商品名や取引先名を置き換えたサンプルで整理できます。単一ファイルの差分チェックで済むのか、複数システムのAPI開発が必要なのかによって、作業範囲と見積りは大きく変わります。

小規模な単機能のデータ整理であれば比較的着手しやすい一方、複数販路の常時同期や同時受注を制御する仕組みは個別設計が前提です。ココナラ内で相談する場合は、現在の受注・在庫管理の流れと、欠品が発生するタイミングを簡単に説明いただければ、実現方法の切り分けから検討できます。

在庫管理で最初に見直すべきなのは、画面に表示された数字そのものより、その数字が何を表し、いつ確定した数字なのかです。ここが整理できると、Excelで直すべき部分と、システムとしてつなぐべき部分が見えてきます。