店舗在庫を「売れる在庫」と誤認しない｜EC・店舗・倉庫の引当・移動中・取り寄せ可否を分ける在庫約束台帳

ECと実店舗、倉庫の在庫を連携していても、「在庫がある」と「今この注文に約束できる」は同じ意味ではありません。

たとえば、店舗に3点あっても、1点は来店客向けの取り置き、1点は別店舗への移動中、残る1点も棚卸差異の確認中であれば、EC注文へ即時に引き当てられるとは限りません。ここで合計在庫だけを商品ページ、受注処理、CS案内に使うと、欠品、分割出荷、店舗業務への影響、到着予定の案内ぶれが起きやすくなります。

必要なのは、在庫同期の有無とは別に、「どのSKUを、どの拠点から、どのチャネルの注文へ、いつまでに約束してよいか」を記録・判断するルールです。本記事ではこれを在庫約束台帳と呼びます。

なお、アパレル業界関係者を対象とした調査を紹介した報道では、OMO未着手企業が挙げた課題として、店頭・EC在庫管理や、店舗欠品時の取り寄せ工数、EC・モール間の在庫一元管理不足が示されています。これは個社の運用課題を診断する材料にはなりますが、自社の優先順位は受注データ、欠品理由、移動リードタイムで確認してください。

以下のShopify・futureshopの仕様は、各公式マニュアルを2026年9月15日時点で確認する前提で記載します。機能の利用可否、契約プラン、連携アプリ・基幹システム側の処理は、実装前に最新の公式情報と自社環境で再確認してください。

合計在庫ではなく「約束できる状態」を分ける

在庫の物理的な所在と、販売・出荷・受取の約束に使える数量は分けて管理します。最低限、SKU×拠点ごとに次の状態を区別します。

ここで重要なのは、取り寄せ可能数を販売可能数へ混ぜないことです。取り寄せ可能でも、出荷元店舗の営業状況、店頭取り置き、移動便、検品、受取店舗の受領作業によって、顧客へ渡せる日は変わります。

販売可能数は、単純な物理在庫ではなく、チャネル別の販売許可を反映した値として扱います。概念上は次のように置けます。

販売可能数 = 帳簿在庫
  - 受注引当済み
  - 店舗取り置き
  - 出荷・移動の処理中数量
  - 安全在庫
  - 確認保留数量

ただし、この式をそのまま各システムの在庫計算式として実装できるとは限りません。基幹、WMS、POS、カート、在庫連携ツールのどれを正とするか、どの状態を連携できるかを先に決める必要があります。

在庫約束台帳をSKU×拠点×チャネルで作る

台帳は、在庫数の集計表ではなく、受注時の判断を同じ基準に寄せるための定義表です。全SKUを手作業で管理する必要はありません。まずは欠品や取り寄せ判断が多いSKU群、主要拠点、主要チャネルから始めます。

台帳に持たせる項目

次のような列を用意すると、販売、物流、店舗、CSで確認する情報を揃えやすくなります。

拠点コードは、POS、WMS、カート、連携ツールで同じ意味になるよう対応表を維持します。名称だけで運用すると、「新宿店」と「新宿店バックヤード」のような近い名称を別拠点として扱う事故を発見しにくくなります。

販売ルールを数値だけで決めない

同じ販売可能数が1でも、販売可否はSKUの特性で変わります。たとえば限定品、予約品、セット商品、冷蔵・大型商品、店舗限定品では、物流制約や販売方針を別途持つ必要があります。

台帳では少なくとも、以下を明文化します。

• 店舗在庫をEC出荷へ使ってよいSKU・店舗
• EC販売より店頭販売を優先する条件
• 店舗間移動を開始できる最小残数
• 取り寄せ注文を受ける締め時刻と、移動を依頼する期限
• 移動元が出荷不可と判明した場合の代替拠点、キャンセル、顧客連絡の担当
• 1注文を分割出荷してよい条件と追加送料の扱い

受注から出荷・受取までの判断をキュー化する

担当者の経験だけで拠点を選ぶ運用では、繁忙時や不在時に判断が変わります。受注後に必要な判断を、状態別の例外キューとして分けます。

基本の判定順序

EC受注時の引当順序は、次のように設計できます。

1. 注文の配送方法、店頭受取希望、配送先、SKU、数量を確認する
2. 同一拠点で注文全量を販売可能数から満たせる候補を探す
3. 候補が複数ある場合は、配送リードタイム、物流費、店舗販売優先、拠点負荷の優先順位で決める
4. 1拠点で満たせない場合、分割出荷可否を確認する
5. 分割不可なら、取り寄せ条件を満たす拠点があるかを確認する
6. 取り寄せても案内期限を守れない場合、代替商品、入荷待ち、キャンセルを含めてCS対応へ回す
7. 引当確定後、台帳と連携元の状態を更新し、二重引当を防ぐ

この順番では、他拠点の帳簿在庫が残っていても、無条件で取り寄せに進みません。店舗取り置き、最低残数、棚卸保留、移動締め切りを判定に含められるためです。

例外キューを先に決める

通常フローより、判断保留を放置しない仕組みが重要です。少なくとも次のキューと担当・期限を定めます。

• 在庫差異キュー：帳簿数と実在庫が一致しない。新規引当を止め、実査または責任者確認へ回す。
• 移動未受領キュー：移動予定日を過ぎても受領されない。移動元、配送状況、移動先の受領作業を確認する。
• 店舗回答待ちキュー：取り寄せ元店舗が出荷可否を確認中。回答期限を過ぎたらCSへ通知する。
• 分割出荷判断キュー：一部SKUのみ確保できた。購入時の約束と送料ルールに照らして出荷可否を判断する。
• 表示鮮度超過キュー：商品ページや店舗在庫一覧の更新時刻が基準を超えた。表示停止、文言変更、再連携のいずれかを選ぶ。

「確認中」を在庫ゼロとして扱うのか、販売停止として扱うのかも決めます。重要なのは、確認中のまま販売可能数に残さないことです。

Shopifyでは在庫状態、ロケーション、order routingを別々に確認する

Shopifyでは複数ロケーションを使う場合、オンライン注文は利用可能在庫と設定したorder routingに基づいてロケーションへ割り当てられます。1拠点で注文全体を満たせないときは、複数ロケーションへの分割、または優先ロケーションでのオーバーセルが起こり得ると公式ヘルプは説明しています。

したがって、「最寄り店舗に在庫があるからその店舗から出るはず」とは限りません。受注の割当結果と自社の約束ルールが一致するかを確認してください。

Shopifyの状態を台帳に読み替える際の注意

Shopifyは、Available、Committed、Unavailable、Incomingなどの在庫状態を区別します。公式ヘルプでは、Incomingは受領されてAvailableになるまで販売可能在庫ではなく、Committedには未発送注文や出荷準備済みの在庫移動で確保された数量が含まれるとされています。

台帳と対応づける際の確認観点は次の通りです。

• Available：自社ルール上の安全在庫、店舗優先分、確認保留を差し引く必要があるか確認する
• Committed：受注引当済みとして扱える範囲を、注文管理・出荷処理と照合する
• Incoming：到着予定を案内する根拠にはなり得ても、原則として即納販売可能数には含めない
• Unavailable：連携アプリ、予約、保留など、自社環境で数量が拘束される理由を切り分ける

また、Shopifyの在庫移動では、移動中、出荷準備、受領済みの処理が区別されます。移動先が販売・フルフィルメントに使える状態になったと判断するのは、少なくとも移動先で受領処理を行い、対象商品の在庫設定も確認してからにします。移動を作成した時点で移動先在庫を販売可能として扱う設計は避けます。

店頭受取で他ロケーションから受取店舗へ在庫を移すstore transfersは、Shopify公式ヘルプ上、Shopify Plus向けの機能です。店頭取り寄せの運用をこの機能に依存する前に、契約プラン、設定可否、移動処理時間、受取可能と表示する条件を確認してください。

futureshopの実店舗在庫表示は「表示」と「出荷可否」をつなげて確認する

futureshopでは、実店舗の在庫管理システムとAPI連携し、商品ごとの取扱店舗一覧や店舗在庫を表示できます。利用には実店舗在庫表示機能の申し込みと、在庫管理システム側からの在庫連携が必要です。表示対象となるのは在庫店舗コードを登録した店舗です。

ここで確認したいのは、店舗在庫の表示ができることと、その店舗在庫をEC注文の出荷または取り寄せに使えることは別、という点です。futureshopの画面表示を在庫約束台帳へつなぐ場合は、次を確認します。

• 在庫店舗コードと、POS・在庫管理システム・台帳の拠点コードが対応しているか
• 連携するのは実在庫、販売可能数、または在庫文言のどれか
• 店頭取り置き、棚卸保留、移動中を連携値から除外できるか
• 表示在庫が更新される時刻と、CSが参照する時刻を確認できるか
• EC画面上の文言が「在庫あり」「取り寄せ可」「受取可」のどれを表すか

futureshopの実店舗在庫一覧では、在庫店舗コード・商品番号で連携済みの在庫を検索し、在庫数または在庫表示文言、データ日時を確認できます。一方、そのデータ日時はECサイトには表示されません。購入者に店舗在庫を見せる場合でも、運用側はデータ鮮度を監視し、基準を超えたときの表示・受注判断を決めておく必要があります。

日次照合とテスト注文で約束のずれを見つける

在庫約束台帳は一度作って終わりではありません。連携エラーよりも、設定変更、店舗作業の遅れ、例外受注でずれることがあります。日次で差分を見つけ、定期的に注文シナリオを通します。

日次の差分照合項目

SKU×拠点ごとに、少なくとも以下を照合対象にします。

• POSまたはWMSの帳簿在庫と、カート・在庫連携先の在庫
• 確定受注の引当数と、出荷待ち・未出荷注文数
• 移動元の出荷済み数、移動中数、移動先の受領数
• 店頭取り置き期限切れの数量
• 販売停止SKUなのに公開チャネルで販売可能になっている数量
• 表示用在庫データの最終更新時刻

差異を見つけたら、いきなり数値を上書きするのではなく、正とするシステム、差異理由、修正担当、再発防止の要否を記録します。帳簿修正とEC販売停止は、必要に応じて別の判断です。

テスト注文で確認するケース

設定変更時、繁忙期前、拠点追加時には、少なくとも次のケースをテスト注文で確認します。

1. 1拠点だけで注文全量を満たせる通常注文
2. 2拠点に在庫が分かれ、分割出荷が必要になる注文
3. 店舗在庫はあるが、安全在庫または取り置きによりECへ回せない注文
4. 他店取り寄せ後に店頭受取となる注文
5. 移動中在庫しかないSKUの注文
6. 在庫連携の更新が止まった店舗を含む注文
7. 店舗が出荷不可と回答した場合の代替・キャンセル・顧客連絡

テストでは、在庫数だけでなく、どのロケーションへ割り当てられたか、社内通知が誰へ届くか、商品ページ・注文確認・CS画面の案内が矛盾しないかを確認します。

導入は「全在庫の統合」より約束ルールの固定から始める

複数拠点の在庫を扱う際、最初から全SKU・全チャネルのリアルタイム連携を目指すと、状態定義や例外処理が未決定のまま実装が進むことがあります。まずは対象範囲を限定し、約束を守れる状態を作る方が、移行リスクを抑えやすくなります。

進め方の例は次の通りです。

1. 直近の欠品、分割出荷、取り寄せ遅延を、SKU・拠点・原因別に棚卸しする
2. 正とする在庫データと、各システムが更新する項目を決める
3. 販売可能、引当、移動中、取り置き、取り寄せ可の定義を台帳へ記載する
4. 主要SKU・主要拠点で販売優先順位と例外キューを運用する
5. 日次照合とテスト注文で、顧客約束と実際の処理の差を修正する
6. 条件が安定した範囲からSKU・拠点・チャネルを広げる

在庫を公開する範囲を広げることは、販売機会につながる可能性がある一方で、店舗作業、移動費、分割出荷、CS対応の負荷も増やします。「店舗にあるから売る」ではなく、「その在庫を使って約束した期限と体験を守れるか」を、SKU×拠点×チャネルで判断できる状態を目指してください。

参考情報

• 【アパレル関係者に聞いた課題とOMO導入】スタッフの6割が店頭・ECの在庫管理業務に課題、7割がコーディネート投稿は売上貢献の可視化があればモチベ向上
• Shopify Help Center: Setting up order fulfillment for locations
• Shopify Help Center: Understanding inventory states
• Shopify Help Center: Creating and processing inventory transfers
• Shopify Help Center: Setting up pickup in store for online orders
• futureshopオンラインマニュアル：実店舗在庫表示のはじめかた
• futureshopオンラインマニュアル：実店舗在庫一覧