通販のオムニチャネル在庫統合とは｜統合の手順と落とし穴

◆監修・編集責任者　小園 将隆　2026年8月27日

B2B EC-COLUMN

オムニチャネルにおける「在庫統合」とは — 数ではなく意味を揃える

通販のオムニチャネル在庫統合とは、EC・実店舗・モール・電話注文が同一の商品識別子・在庫状態区分・配分ルールに基づいて在庫を参照できる状態にすることです。IPA「DX動向2026」によれば、企業がデータの標準化を課題に挙げる割合は36.8%に上ります^*1。

言い換えれば、在庫統合とは在庫数を一箇所にまとめることではなく、複数のチャネルが同じ意味で在庫を扱えるようにする取り組みです。数量だけを単純に共有すると、かえって二重販売や欠品を招くことがあります。

統合すべき対象は、次の4つの層に分解できます。第一に商品を指す識別子、第二に在庫の状態区分（実在庫・引当済・入荷予定・保留など）、第三にチャネルへの配分ルール、第四に更新のタイミングとタイムラグです。この4層を順に揃えることが、本記事全体の骨格になります。

本記事が扱うのは、チャネルをまたぐ在庫データの統合設計です。注文の受付経路をどう一元化するかという論点や、店舗受け取りを含む顧客体験の設計は対象に含みません。

結論 — 統合するのは在庫数ではなく在庫の「意味」

在庫統合が目指すのは、どのチャネルから見ても「在庫あり」の意味が同じである状態です。実在庫の数量だけを共有システムに流し込んでも、引当済かどうかの区分が揃っていなければ、同じ商品を複数チャネルが同時に販売してしまいます。

統合すべき4つの層 — 識別子・状態区分・配分ルール・更新タイミング

識別子の統一は、商品を一意に指せることが在庫統合の前提になるという意味です。状態区分の統一は、実在庫・引当済・入荷予定・保留といった区分の呼び方と定義を全チャネルで揃えることを指します。

配分ルールの統一は、限られた在庫をどのチャネル・どの取引先に優先して割り当てるかという判断基準を決めることです。更新タイミングの統一は、在庫数をどの頻度で反映し、どこまでのタイムラグを許容するかを決めることを指します。

一元管理・在庫連携・在庫統合の使い分け

在庫の一元管理とは、複数のシステムに散らばる在庫データを1か所に集約して見られるようにすることです。在庫連携とは、システム間で在庫データを受け渡す仕組みそのものを指します。これに対して在庫統合は、識別子・状態区分・配分ルールの意味を揃えたうえで、各チャネルが同じ前提で在庫を参照できる状態を指します。一元管理や連携の仕組みが整っていても、意味が揃っていなければ統合とは呼べません。

なぜ在庫は統合できていないのか — 公的調査が示す3つの壁

在庫統合が進まない理由は、システムの機能不足だけではありません。IPAの調査は、データ全般の整備・管理・流通に関する課題を数値で示しています^*1。

壁① データの標準化が難しい — 36.8%

IPA「DX動向2026」のデータ整備・管理・流通に関する課題の設問では、「データの標準化が難しい」と回答した企業が36.8%でした^*1。この設問は企業のデータ全般を対象としており、在庫データに限定した数値ではありません。ただし、チャネルをまたぐ在庫統合も同じ標準化の課題に直面すると考えられます。

壁② 管理システムが未整備 — 32.6%、規模で差

「管理システムが整備されていない」との回答は32.6%でした^*1。従業員規模別のデータ利活用状況を見ると、1,001人以上の企業は「全社で利活用している」27.2%と「事業部門・部署ごとに利活用している」48.1%を合わせて75.3%（n=378）、100人以下は同じく17.6%と21.0%を合わせて38.6%（n=580）です^*1。なお75.3%・38.6%は本記事が両区分を合算した値で、IPAが単一の項目として公表している数値ではありません。企業規模の差は取り組みやすさの違いであり、意欲の差として語れる数値ではありません。

壁③ 社外との連携が止まる — 直接連携でも実施は35.6%

企業間のデータ連携についても、「特定企業間での直接的なデータ連携」を実施している企業は35.6%にとどまります（n=1,770）^*1。「サプライチェーン内でのデータ連携プラットフォームの利用」は22.5%、「地域・異業種間でのデータ連携基盤の利用」は4.6%です^*1。いずれの形態も、「実施・検討していない」との回答が過半を占めます^*1。

データ連携をすでに実施中・検討中の企業に目的を尋ねた設問（n=1,137・複数回答）では、最も多く挙がったのが「業務の効率化や自動化」で85.2%、次いで「既存事業の改善やサービス高度化」が50.8%、「新規事業やサービスの創出」は24.5%でした^*1。既存業務の改善に目的が集まる一方、新規事業の創出を挙げる企業は4社に1社にとどまります。参考までに、企業のクラウドサービス利用率は2024年時点で80.6%です^*2。ただしこれは総務省の別調査（通信利用動向調査）であり、IPAの数値と単純に比較はできません。

この停滞状況を自社の在庫統合計画に照らして確かめるには、無料相談で要件を整理するのが近道です。

統合の前提 — 商品を一意に指せるようにする

在庫統合の第一歩は、商品を一意に指せる状態を作ることです。チャネルごとに商品コードが異なると、同じ商品の在庫を1つの数値として扱えません。

チャネルごとに商品コードが違うと在庫は統合できない

自社ECの商品コード、モールが割り当てるSKU、基幹システムの品目コードが別々に存在すると、システム間で商品を突き合わせる対応表が必要になります。この対応表が抜け漏れると、在庫数が食い違ったまま統合作業が進んでしまいます。

流通標準という選択肢 — 流通BMS

流通BMS（流通ビジネスメッセージ標準。メーカー・卸売・小売の三層をつなぐEDIメッセージの標準規格）は、流通BMS協議会が策定・管理しています^*6。なお「流通ビジネスメッセージ標準」および「流通BMS」は、GS1 Japan（一般財団法人流通システム開発センター）の登録商標です^*6。発注・出荷・受領・返品・請求・支払の6業務・8種類の標準メッセージを定め、製・配・販の三層をシームレスに接続することを目的としています^*6。自社コードだけで対応表を組む前に、取引先が流通BMSに対応しているかを確認する価値があります。

自社コードと標準コードの対応表をどこに持つか

対応表を特定のチャネルのシステムだけに持たせると、そのシステムが停止したときに他のチャネルも商品を特定できなくなります。対応表は、在庫の正本（複数システムが在庫を持つとき、値が食い違った際に正しいと決めておく1つの保持先）と同じ場所で一元的に管理する設計が実務上のポイントです。

在庫の状態区分を揃える — 「在庫あり」が指すものを1つにする

識別子が揃っても、在庫の状態区分がチャネルごとに違えば、「在庫あり」の意味は揃いません。状態区分は最低限、次の5つに分けて管理します。

チャネルによって見せる区分を変える設計

表示してよいのは、実在庫そのものではなく販売可能在庫です。販売可能在庫は「実在庫−引当済−安全在庫（需要や入荷の変動を吸収するために、販売可能在庫からあらかじめ外しておく数量）」で求めます。実在庫の数値をそのまま表示すると、引当済分まで販売できるように見えてしまいます。

更新のタイムラグをどこまで許容するか

在庫の更新は、同期・準リアルタイム・バッチのいずれかを選びます（在庫連携のリアルタイム化で詳述）。同期に近づけるほど欠品確率は下がりますが、システム間の通信負荷は増えます。バッチ更新を選ぶ場合は、更新間隔のあいだに売り切れる可能性を見込んで、安全在庫や表示ルールで補う設計が必要です。

配分ルールを決める — BtoCとBtoB卸売を同じ在庫で回す難所

BtoC通販とBtoB（卸売）を同じ在庫から出す場合、消費者向けの即時販売と、卸売側の内示・取り置き・預託が競合します。この節はBtoBの商習慣特有の論点です。

共有プール型とチャネル別引当型の使い分け

実務では、両方式を組み合わせることが多くなります。卸売の内示・取り置き分をチャネル別引当型で先に確保し、残りを共有プールとして自社EC・モール・実店舗に配分する設計です。

卸売側の内示・取り置き・預託を先に確保する設計

卸売取引では、取引先ごとの内示（発注前に伝えられる購入見込み数量）に基づいて数量を仮押さえすることや、預託在庫として一定量を確保しておくことが一般的です。この確保分を消費者向けの販売可能在庫と同じ計算式に含めてしまうと、卸売側の約束が守れなくなります。

締め請求・取引先別単価との整合

在庫の統合設計は、締め請求や取引先別単価の運用を壊さないことも条件になります。配分ルールを変更する際は、価格・請求条件を管理する部門と、在庫を管理する部門の双方が同じ在庫区分の定義を参照できるようにしておく必要があります。

統合したあとに残るリスク — 在庫表示は販売の約束になる

在庫統合を終えても、表示の設計を誤ると新たなリスクが生まれます。チャネル横断で「在庫あり」を表示することは、取引の申出に近づくためです。

「在庫あり」の表示が取引の申出になる

おとり広告に関する表示（平成5年公正取引委員会告示第17号）は、不当表示となる4類型を定めています^*3。「取引を行うための準備がなされていない場合」「供給量が著しく限定されているにもかかわらず、その限定の内容が明りょうに記載されていない場合」「供給期間、供給の相手方又は顧客一人当たりの供給量が限定されているにもかかわらず、その限定の内容が明りょうに記載されていない場合」「合理的理由がないのに取引の成立を妨げる行為が行われる場合その他実際には取引する意思がない場合」の4つです^*3。ただし、この告示は一般消費者向けの表示を対象とする規定であり、事業者間取引（BtoB）にそのまま適用されるとは限りません。個別の表示が要件に当たるかどうかは、事実関係により判断が分かれます。

通信販売の広告には引渡時期の表示義務がある

特定商取引法第11条第3号は、通信販売の広告に「商品の引渡時期若しくは権利の移転時期又は役務の提供時期」を表示するよう義務づけています^*5。消費者庁の解説でも、商品の引渡時期については「期間又は期限を表示することが必要」とされています^*4。この規定は通信販売、つまりBtoC向けの規定です。BtoBの受発注では別の商習慣・契約条件で運用している場合が多く、同じ表示ルールをそのまま当てはめるのは適切ではありません。

供給量が限定されるときの書き方

供給量や供給期間が限定される場合、限定の内容を明りょうに記載することが求められます^*3。「売り切れ御免」とだけ表示するのでは足りず、何がどの程度限定されているかを具体的に示す必要があります。

タイムラグを前提にした表示設計

更新にタイムラグがある以上、在庫数そのものの直接表示は避け、在庫区分（在庫あり・残りわずか・取り寄せ等）と引渡時期の見込みをセットで示す設計が現実的です。この設計上の含意にとどめ、個別の表示が法令上の要件を満たすかどうかは、法務部門または所管官庁への確認を推奨します。

在庫統合の進め方 — 7ステップ

ここまでの内容を実装の順序に沿って整理します。

1. 現状のチャネルと在庫の持ち主を棚卸しします。誰のどのシステムが在庫を持っているかを洗い出す作業です。
2. 在庫の正本を1つ決めます（基幹システム連携の設計と合わせて検討します）。複数システムの値が食い違ったときに、正しいと扱う保持先を先に合意します。
3. 商品識別子を統一し、対応表の管理者を決めます。管理者が不在だと対応表が更新されず、統合が形骸化します。
4. 在庫の状態区分を定義し、全チャネルで同じ語を使います。H2-4の5区分を出発点にできます。
5. チャネルへの配分ルールと安全在庫を決めます。BtoB優先分を先に確保する設計にします。
6. 更新頻度と許容タイムラグを決め、表示ルール（引渡時期の表示）に落とし込みます。
7. 差異の検知と是正の運用を決めます（棚卸と在庫差異の是正を参照）。棚卸差異や引当残を定期的に点検し、監査ログとして残します。

最初のスコープの切り方 — 全チャネル同時にやらない

全チャネルを同時に統合しようとすると、識別子の対応表と配分ルールの検討範囲が広がりすぎ、着手が遅れがちです。影響範囲が小さいチャネルの組み合わせから始め、段階的に対象を広げる進め方が現実的です。

受発注システム側に必要な要件

受発注システムを検討・要件定義する際は、4点を仕様として明文化します。在庫の正本をどこに置くか、配分ロジックをどう表現するか、更新頻度をどう設定できるか、監査ログをどう残すかです。この4点が曖昧なまま導入すると、識別子や状態区分を揃えても運用でしか吸収できません。

この4点をシステム要件として書き切るには、日本の商習慣に固有の配分ルールを扱える設計力が必要です。内製で対応するには、識別子設計・状態区分の定義・配分ロジックの実装という複数領域の知識が要ります。自社の要件を整理するには、無料相談で受発注システムの要件を整理する進め方もあります。

まとめ：在庫統合を進める3つの判断軸

本稿では、通販のオムニチャネル在庫統合を、識別子・状態区分・配分ルール・更新タイミングという4つの層に分けて整理しました。要点を3つに集約すると次のとおりです。

第一に、統合が進まない背景には、公的調査が示すデータ標準化と管理システムの課題があります^*1。第二に、統合したあとも在庫表示は取引の申出に近づくため、引渡時期の表示とセットで設計する必要があります^{*3 *5}。第三に、BtoCとBtoBを同じ在庫で回す場合は、卸売側の確保分を先に押さえる配分ルールが欠かせません。

この3点を押さえてから7ステップに着手すれば、統合の途中で配分ルールを作り直す手戻りを避けやすくなります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

在庫の一元管理と在庫統合は何が違いますか。

対象が異なります。一元管理は在庫データを1か所に集約して見られるようにすることを指し、在庫統合は識別子・状態区分・配分ルールの意味をチャネル間で揃えることを指します。一元管理の仕組みが整っていても、意味が揃っていなければ統合とは呼べません。

在庫数をサイトに表示してもよいですか。

表示自体は禁止されていません。ただし表示は取引の申出とみなされる場合があり、供給量が限定されるときはその内容を明りょうに記載する必要があります^*3。個別の表示が要件を満たすかは事実関係により異なるため、法務部門や所管官庁への確認をおすすめします。

実店舗の在庫をECの販売可能在庫に含めてよいですか。

技術的には可能ですが、店頭の実在庫をそのまま含めると、店頭精算とオンライン受注が同時に同じ商品を確保しようとして競合します。安全在庫を設定し、更新のタイムラグを踏まえた配分ルールを別途決める必要があります。

BtoBの卸売取引とBtoCの通販で在庫を分けるべきですか。

完全に分けなくても運用は可能ですが、同じ在庫プールで回す場合は、卸売側の内示・取り置き分を先に確保する配分ルールが必要です。なお、おとり広告に関する表示は一般消費者向けの規制であり、事業者間取引にそのまま適用されるとは限りません^*3。

在庫連携はリアルタイムでないといけませんか。

必須ではありません。同期・準リアルタイム・バッチのいずれを選ぶかは、許容できる欠品確率と更新にかかるシステム負荷のバランスで判断する事項です。バッチを選ぶ場合は、更新間隔中の売り切れを見込んだ安全在庫や表示設計で補います。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「DX動向2026」（2026年7月30日公表）
2. *2　出典：総務省「令和7年版 情報通信白書 クラウドサービスの利用状況」（令和7年版）
3. *3　出典：消費者庁「おとり広告に関する表示」（平成5年公正取引委員会告示第17号）
4. *4　出典：消費者庁「特定商取引法ガイド 通信販売広告について」
5. *5　出典：e-Gov法令検索（デジタル庁）「特定商取引に関する法律 第11条」
6. *6　出典：GS1 Japan（一般財団法人流通システム開発センター）「流通BMS（流通ビジネスメッセージ標準）」