複数倉庫・複数チャネルの在庫を一元管理するシステムの設計

複数の倉庫や店舗、ECサイトの在庫を一元管理するシステムを設計するときの要点は、「どこにある在庫を、どの販売先に、いつ時点の数字で見せるか」を決めることです。すべての拠点とチャネルの在庫を一つの画面に並べるだけでは一元管理になりません。注文が入ったときにどの拠点の在庫を引き当てるか、販売先ごとにどれだけの在庫を見せるか、在庫の数字をどのタイミングで同期するかを決めてはじめて、売り越しや欠品、過剰在庫を防げるようになります。

設計の柱は、①在庫の持ち主（正となるデータ）を一つに決める、②在庫を「実在庫」「引当済み」「販売可能数」に分けて管理する、③チャネルごとの同期のタイミングと方式を決める、④同期がずれたときに備えて安全在庫と補正の仕組みを持つ、の4つです。

この記事は、倉庫や店舗を複数持ち、実店舗・自社EC・モールなど複数のチャネルで販売している事業者の経営者、EC・物流・情報システムの担当者に向けて、在庫一元管理の設計の考え方と導入の手順、よくある失敗を具体的に解説します。

なぜ在庫の一元管理が必要になるのか

拠点やチャネルが一つずつしかない間は、在庫管理は比較的単純です。倉庫の在庫がそのまま販売できる数で、注文が入ればその在庫から出荷するだけです。ところが、倉庫が2つになり、店舗とECで同じ商品を売るようになると、次のような問題が起き始めます。

• 売り越し：ECで売れた商品を、在庫の反映が遅れている間に店舗やモールでも売ってしまい、出荷できない注文が発生する。
• 見かけの欠品：ある倉庫では在庫が切れているが、別の倉庫には余っている。それに気づかず、販売を止めたり追加で仕入れたりしてしまう。
• 過剰在庫：拠点ごとに発注を判断するため、全体では十分な在庫があるのに、各拠点が多めに仕入れる。
• 確認の手間：顧客や店舗スタッフから在庫の問い合わせがあるたびに、各拠点に電話やチャットで確認している。
• 集計の遅れ：全体の在庫を把握するために、各拠点の数字を手作業で集めて合算している。

これらは、在庫の情報が拠点やチャネルごとに分かれていることから生まれます。一元管理の目的は、在庫の情報を一つにまとめ、全体を見ながら引き当て・補充・販売の判断ができるようにすることです。

在庫の数字を3つに分けて考える

一元管理の設計で最初に整理すべきなのは、「在庫数」という言葉の中身です。一つの数字で管理しようとすると、売り越しや二重引当が起きます。次の3つに分けて考えます。

販売先に見せるのは、実在庫ではなく販売可能数です。注文が入った時点で引当済みを増やし、出荷した時点で実在庫と引当済みの両方を減らします。この区別があることで、出荷前の注文を考慮した正確な販売可能数を出せます。

さらに、入荷予定の在庫や、拠点間を移動中の在庫も区分して持っておくと、予約販売や補充の判断に使えます。最初から細かく分けすぎる必要はありませんが、少なくとも実在庫・引当済み・販売可能数の3つは分けて設計します。

在庫の「正」をどこに置くか

複数のシステムが在庫数を持っている場合、どのシステムの数字を正とするかを決めます。たとえば、ECのカートシステム、モールの管理画面、店舗のPOS、倉庫の管理システムがそれぞれ在庫数を持っていると、どれが正しいのか分からなくなります。

一般的には、在庫を一元管理する仕組み（在庫管理システムや受注管理システム）に正の在庫数を置き、各チャネルにはそこから販売可能数を配る形にします。各チャネルで売れた情報は一元管理の仕組みに集め、そこで引当と在庫の計算を行い、結果を各チャネルに返します。受注をまとめて管理する仕組みについては、OMS（受注管理システム）の用語ページも参考にしてください。

この「集めて計算して配る」流れを一方向に保つことが、一元管理の設計の要です。各チャネルの管理画面で在庫数を直接書き換える運用が残っていると、正の数字が崩れます。

在庫引当のルールと、チャネルごとの在庫の見せ方

注文が入ったとき、どの拠点の在庫を引き当てるかのルールを決めます。拠点が複数ある場合、このルール次第で配送の速さ、送料、拠点ごとの在庫の偏りが変わります。

引当ルールの例

• 優先拠点方式：メインの倉庫から優先して引き当て、足りない場合だけ別の拠点から引き当てる。単純で分かりやすい。
• 地域方式：配送先に近い拠点から引き当てる。配送の速さや送料を重視する場合に向く。
• 在庫量方式：在庫が多い拠点から引き当て、拠点ごとの在庫の偏りを減らす。
• チャネル専用方式：店舗の在庫は店頭販売用、倉庫の在庫はEC用、というように、拠点とチャネルを結び付ける。

一つの注文を分けて出荷するか

一つの注文の商品が複数の拠点に分かれているとき、分けて出荷するか、1つの拠点に集めてから出荷するかも決めておきます。分けて出荷すると早く届きますが送料がかさみ、集めて出荷すると送料は抑えられますが時間がかかります。どちらを優先するかは、商材や顧客との約束によって異なります。

チャネルごとの在庫の見せ方

すべてのチャネルに販売可能数をそのまま見せる方法と、チャネルごとに在庫を割り当てる方法があります。

同期が遅いチャネル（在庫の反映に時間がかかるモールなど）では、共有方式だと売り越しのリスクが高まります。その場合は、販売可能数から安全在庫を引いて見せる、売れ行きの速い商品だけ割当方式にする、といった調整をします。

同期のタイミングと方式

在庫の一元管理でもっとも技術的な判断が必要になるのが、同期の設計です。各チャネルとの間で、在庫と注文の情報をどのタイミングで、どの方式でやり取りするかを決めます。

同期の方式

• API連携：チャネルが在庫や注文のAPIを公開している場合、プログラムから直接やり取りする。反映が速く、自動化しやすい。
• 定期的なファイル連携：CSVファイルを一定時間ごとに出力・取り込みする。APIがない場合の選択肢。反映に時間がかかる。
• 連携サービスの利用：複数のモールやカートとの連携機能を持つ既製のサービスを使う。

同期のタイミング

• 注文が入ったとき：注文を受け取ったら、すぐに引当を行い、他のチャネルの販売可能数を更新する。売り越し防止に重要。
• 入荷・出荷のとき：倉庫での入出庫の記録を、在庫数に反映する。倉庫での記録の正確さが前提になる。バーコード読み取りによる記録の方法はバーコード・QR読み取りで在庫管理を効率化するシステム設計で解説しています。
• 定期的な突き合わせ：一定時間ごとに、各チャネルの在庫数と正の在庫数を比べ、ずれがあれば補正する。

同期が失敗したときの備え

チャネル側のシステムが一時的に応答しない、通信が途切れる、といった理由で同期が失敗することは避けられません。失敗したときに自動で再送する、一定回数失敗したら担当者に通知する、定期的な突き合わせでずれを見つけて補正する、といった仕組みを用意しておきます。連携の障害対策の考え方はAPI連携の障害対策で詳しく扱っています。

欠品と過剰在庫を防ぐ仕組み

一元管理によって全体の在庫が見えるようになると、欠品と過剰在庫を防ぐための判断がしやすくなります。

• 全体での発注点管理：拠点ごとではなく、全体の在庫と販売の状況から発注のタイミングを判断する。
• 拠点間の移動の提案：ある拠点で在庫が少なく、別の拠点で余っている場合に、移動を提案する。
• チャネル別の売れ行きの把握：どのチャネルで何がどれだけ売れているかを見て、割当や仕入れを調整する。
• 滞留在庫の抽出：一定期間動いていない在庫を拠点ごとに抽出し、売れているチャネルや拠点に回す、販促を行うなどの判断に使う。

返品・キャンセル・拠点間移動の扱いと運用ルール

一元管理の設計では、通常の販売と出荷だけでなく、在庫が戻ったり移動したりする処理も決めておく必要があります。ここが曖昧だと、仕組み自体は正しく動いていても、在庫の数字が少しずつずれていきます。

• 注文のキャンセル：出荷前のキャンセルなら、引当済みを戻して販売可能数を増やす。どのチャネルのキャンセルも、一元管理の仕組みに確実に届くようにする。
• 返品：返品された商品をすぐに販売可能数に戻すか、検品して良品と判断してから戻すかを決める。不良品は別の区分で管理し、販売可能数に含めない。
• 拠点間の移動：送り出した拠点の実在庫から減らし、受け取った拠点で入庫を記録するまでは「移動中」として扱う。移動中の在庫を販売可能数に含めるかどうかも決めておく。
• 店舗での取り置き：店頭で顧客のために取り置いた商品は、引当済みとして扱い、他のチャネルで売れないようにする。

これらの処理を誰がどの画面で記録するかまで決めておくと、運用が始まってからの混乱を防げます。

運用の体制とルールを決める

一元管理の仕組みは、作って終わりではありません。販売計画や拠点の状況は日々変わるため、安全在庫や割当の設定を見直し続ける必要があります。運用を始める前に、次の役割を決めておきます。

大型の販促やセールの前には、チャネルの担当者と在庫の責任者が事前に相談し、割当を一時的に変える、同期の頻度を上げるといった準備をします。新商品を追加するときには、品目コードの対応表の更新を忘れないよう、商品登録の手順に組み込んでおきます。

一元管理を導入する手順

1. 現状のデータの流れを図にする：どのチャネル・拠点が、どのシステムで在庫と注文を管理し、どうやって情報をやり取りしているかを書き出す。
2. 困っていることの優先順位を決める：売り越し、見かけの欠品、過剰在庫、確認の手間など、もっとも影響の大きいものを決める。
3. 正の在庫を置く場所を決める：既存のシステムを使うか、新たに一元管理の仕組みを用意するかを決める。
4. 在庫の区分と引当ルールを決める：実在庫・引当済み・販売可能数の区分と、拠点の引当ルールを決める。
5. チャネルごとの同期方式とタイミングを決める：API、ファイル連携、連携サービスのどれを使うか、どの頻度で同期するかを決める。
6. 品目コードをそろえる：チャネルや拠点ごとに異なる品目コードを、共通のコードに対応付ける。
7. 一部の商品やチャネルで試す：売れ行きの速い商品や、売り越しの多いチャネルから試す。
8. 全体の棚卸しを行って切り替える：切り替え時に実在庫を数え直し、正確な数字から始める。
9. 同期の状況を監視し、ルールを調整する：売り越しや同期の失敗の状況を見ながら、安全在庫や割当を調整する。

手順7で試す商品は、売り越しが多く発生している商品や、複数のチャネルで売れ行きの速い商品を選ぶと、効果と問題点が早く見えます。試験期間中は、各チャネルの販売可能数と正の在庫を毎日見比べ、ずれが出たらその原因（同期の失敗、記録の遅れ、コードの対応漏れなど）を記録しておきます。

手順6は見落とされがちですが、非常に重要です。同じ商品がECでは「A-001」、モールでは「SHOP-A001」、倉庫では「1001」と、別のコードで管理されていることはよくあります。対応表を作らないまま連携を始めると、在庫が正しく反映されません。

具体的な場面で考える

架空の例として、アパレル商品を自社倉庫と委託倉庫の2拠点で保管し、実店舗3店、自社ECサイト、2つのモールで販売している会社を考えます。

この会社では、各モールと自社ECの在庫を、担当者が毎朝倉庫の在庫表を見て手作業で更新していました。日中に複数のチャネルで同じ商品が売れると売り越しが起き、顧客への謝罪とキャンセル対応に追われていました。また、店舗で品切れの商品が倉庫には残っていることに気づかず、追加で仕入れてしまうこともありました。

そこで、受注と在庫を一元管理する仕組みを中心に置き、自社ECとモールの注文をAPIで取り込み、引当を行って各チャネルの販売可能数を自動で更新する形にしました。同期の遅いモールについては、販売可能数から安全在庫を引いて見せる設定にしました。拠点の引当は、自社倉庫を優先し、足りない場合に委託倉庫から引き当てるルールにしました。

品目コードは、チャネルごとに異なっていたものを共通の品番に対応付ける表を作り、切り替えの前日に両拠点で棚卸しを行いました。導入後は、店舗の在庫も一元管理の仕組みで見られるようにし、店舗で品切れの商品を倉庫から補充する判断ができるようになりました。

よくある失敗と避け方

• 在庫数を一つの数字で管理する：引当済みを分けないと、出荷前の注文を考慮できず売り越しが起きる。実在庫・引当済み・販売可能数を分ける。
• 各チャネルの管理画面で在庫を直接いじる：正の在庫が崩れ、どれが正しいか分からなくなる。在庫の変更は一元管理の仕組みからだけ行う。
• 品目コードの対応付けを後回しにする：連携を始めてから在庫が反映されない品目が続出する。切り替え前に対応表を作る。
• 同期の失敗を想定しない：一時的な失敗でずれた在庫がそのまま残る。再送、通知、定期的な突き合わせを用意する。
• 全チャネルを一度に切り替える：問題が起きたときの影響が大きい。売り越しの多いチャネルや商品から試す。
• 倉庫での記録が不正確なまま：一元管理しても、入出庫の記録が遅れたり漏れたりすれば数字はずれる。倉庫の記録方法を先に整える。

設計前のチェックリスト

• 各チャネル・拠点の在庫と注文のデータの流れを図にしたか
• 正の在庫を置く場所を一つに決めたか
• 実在庫・引当済み・販売可能数を分けて管理する設計になっているか
• 拠点の引当ルールと、分割出荷の扱いを決めたか
• チャネルごとの在庫の見せ方（共有・割当・安全在庫）を決めたか
• チャネルごとの同期方式とタイミングを決めたか
• 同期が失敗したときの再送・通知・突き合わせの仕組みがあるか
• 品目コードの対応表を作ったか
• 切り替え時の棚卸しの日程を確保したか

よくある質問

Q. 既製の一元管理サービスと自社開発、どちらがよいですか？

連携したいチャネルが既製のサービスで対応しており、引当や在庫の見せ方のルールが一般的なものであれば、既製のサービスを使うのが早くて確実です。独自の引当ルールがある、製造や卸の業務と在庫が絡む、既存の基幹システムと細かく連携する必要がある、といった場合は、自社開発や既製のサービスとの組み合わせを検討します。費用の比べ方は在庫管理システムの費用で整理しています。

Q. 同期はどのくらいの頻度で行えばよいですか？

売れ行きの速さと、売り越しが起きたときの影響で決めます。売れ行きの速い商品や在庫の少ない商品を扱うチャネルでは、注文のたびに同期するのが理想です。チャネル側の仕組みで頻繁な同期ができない場合は、安全在庫を多めにとって売り越しを防ぎます。

Q. 安全在庫はどうやって決めればよいですか？

同期の遅れの間に売れる可能性のある数を目安にします。売れ行きの速い商品ほど、同期が遅いチャネルほど多く必要になります。最初は控えめに設定し、売り越しの発生状況を見ながら調整していくのが現実的です。安全在庫を多くとりすぎると販売機会を逃すため、売り越しと機会損失のバランスを見ながら決めます。

Q. 店舗の在庫もECで売るべきですか？

店舗の在庫をECの販売可能数に含めると、販売機会は広がりますが、店頭で売れた情報の反映が遅れると売り越しにつながります。店舗のPOSとの同期の速さや、店舗からの出荷の体制を確認したうえで判断します。最初は倉庫の在庫だけをECに見せ、仕組みが安定してから店舗の在庫を加えるという段階的な進め方もあります。

Otsumuに相談できること

連携したいチャネルが既製の一元管理サービスに対応しており、拠点が少なく引当のルールも一般的であれば、既製のサービスを導入して自社で運用を整えるのが合理的です。データの流れの図にまとめる作業や品目コードの対応表づくりは、業務をよく知る社内の担当者が主導するのがもっとも確実です。

一方で、独自の引当ルールや拠点間の移動の判断を組み込みたい、APIのないチャネルや既存の基幹システムとつなぐ必要がある、同期の失敗やずれを自動で補正する仕組みを作り込みたい、といった場合は、連携と在庫の計算の部分を設計・開発する必要があります。

Otsumuでは、現状のデータの流れと困りごとを整理したうえで、正の在庫の置き場所、在庫の区分、引当ルール、同期の方式を一緒に設計し、必要な連携と画面を開発します。売り越しの多いチャネルや商品から小さく始め、運用しながらルールを調整していく進め方を大切にしています。詳しくは在庫管理システム開発のページをご覧ください。

どこから整理すればよいか分からない段階でも構いません。30分の無料相談で、現在の拠点とチャネルの状況を伺いながら、設計の進め方を整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01