1つのWMS、複数の倉庫：在庫・権限・請求における3つの落とし穴

現象：WMSの問題は「1つの倉庫」の問題ではなくなった

過去3年間、マルチ倉庫WMSプロジェクトは「新しいシステムを買う」話ではなくなった。企業は既存のWMSを、1つの建物を管理するものからネットワーク全体を管理するものへと、無理やり引き伸ばすことを強いられている。ブランドが2拠点目を開設し、3PLが新顧客向けに施設を追加し、国境を越えたセラーが海外倉庫を代理店から取り戻す。拠点数は増えるのに、システムのロジックは単一拠点時代のまま凍結されている。

市場調査会社によると、世界のWMSソフトウェア市場は2025年に約45億ドル規模で、年間約16％の成長率。その成長のかなりの部分は、新規購入者ではなく既存顧客の新拠点への拡張から来ている。この拡張パターンこそが、マルチ倉庫管理を厄介なものにしている。表向きは技術の問題だが、その下では組織構造、業務プロセス、商取引ルールがネットワークによって一気に増幅されている。

落とし穴その1：在庫の次元——マルチ倉庫管理の最初の分かれ道：分離か共有か

1つの倉庫では、在庫の問いは単純だ。「このSKUはここにいくつあるのか」。2拠点以上になると、最初の問いは構造的になる。在庫は一体どの次元に沿って分離されているのか、と。組織、倉庫、クライアント（マーチャント）の3つの階層は、単一拠点WMSではよく混ぜこぜになっている。マルチサイトに踏み出した瞬間、その混ぜこぜは破綻する。

2024年に1倉庫から4倉庫へ拡大した長江デルタのホームファニシング輸出業者を考えてみよう。東部に2つ、南部に1つ、米国西海岸に1つ——それでも単一拠点時代のWMSをそのまま使っていた。ピークシーズン、拠点Aのスーパーバイザーが拠点Bの売れ筋商品の「利用可能在庫」を見つけ、自分の出荷ピークをカバーするために拠点間転送を発行した。その在庫は別の事業部門向けに引き当てられていたものだった。次元による分離がなければ、すべてが「会社の在庫」に見え、転送を止めるものは何もなかった。拠点Bは3日間欠品し、数百件の注文を失い、2つの事業部門はその件で1か月も言い争った。

トラックが並ぶマルチ倉庫物流パークの空撮

原因の所在ははっきりしている。単一拠点WMSは、物理的な建物1つが論理台帳1つに対応すると想定している。在庫、ロケーション、伝票はすべてその中で回る。マルチサイト化は選択を迫る。完全分離（拠点ごとに台帳）、完全共有（ネットワーク全体で1つの台帳）、ハイブリッド（クライアントや事業部門ごとに分離）の3択だ。私の観察では、完全共有を選んだ企業の多くは、3〜6か月以内に次元と権限の作り直しという追加工事を強いられている。共有自体が間違っているからではなく、選定時に「これは誰の在庫なのか」に答えていなかったからだ。

比較的安全なルールは、クライアント構造から始めること。拠点間で同じクライアント、SKU体系が統一されているなら、細粒度の権限付き共有台帳が最も安いルートだ。クライアントがほとんど重ならない、典型的な3PLなら、クライアント単位の分離が、将来破綻しないほぼ唯一の選択肢になる。2拠点目の開設前に決めること。台帳が稼働し始めたら、履歴データの移行コストは跳ね上がる。

落とし穴その2：権限の境界——拠点Aのスタッフは拠点Bの在庫を見られるのか

2つ目の落とし穴は権限だ。在庫の次元より厄介なのは、システムエラーとして現れないことだ。人の問題として現れる。拠点間転送を承認するのは誰か。拠点Aのピッカーは拠点Bの在庫を照会できるか。リージョナルマネージャーは4拠点の統合レポートを見られるか。

単一拠点の権限は「役割×機能」の2次元マトリクスだ。マルチサイトでは3つ目の次元が加わる。データスコープである。同じ「倉庫マネージャー」でも、拠点Aでは承認権限、拠点Bでは閲覧のみ、拠点Cではアクセスなし、ということが起こる。

2023年、中国東部のある中堅3PLが身をもって学んだ。2拠点目を開設する際、「効率化」のために1拠点目の権限テンプレートをそのままコピーした。新拠点のスタッフは本社とまったく同じ権利を継承した。全拠点、全クライアント、全受注が見える。善意の担当者が「顧客のため」と受注を拠点Aから拠点Bに振り替えた。拠点Bは配送先から遠く、運賃は跳ね上がり、顧客は正式にクレームを出した。その後、同社は2か月かけて権限を設計し直し、「拠点間オペレーション」を第2レベルの承認を要する別枠の権限に変えた。

原因の所在。企業は「組織図の変更」と「権限の変更」を別々の仕事として扱う。新拠点には必ず人事異動と新たな報告ラインが伴うのに、権限は古い形のまま凍結されている。成熟した小売・3PLの実務から借りるべき原則は「デフォルトで分離、必要に応じて開放」だ。go-live時点では拠点間の可視性とオペレーションはデフォルトで閉じ、真に必要なもの——リージョナルマネージャーの統合レポート、ネットワーク全体の在庫引当照会——を承認の記録付きで1つずつ開けていく。実装は安く、善意による損害の大部分を防げる。

落とし穴その3：請求ルール——マルチ倉庫ネットワークで拠点間転送のコストは誰の帳簿に載るのか

3つ目の落とし穴は、3PLと複数部門の精算シナリオでのみ現れる。しかし現れたときの被害は最大だ。請求である。単一拠点の請求は単純だ。入庫はパレット単位、出庫は受注単位、保管はパレット・日または面積単位。複数拠点になると3つの新しい問いが一気に来る。料率表は拠点間で統一されるのか。拠点間転送の幹線輸送（linehaul）コストと両端の荷役料金は誰の帳簿に載るのか。3拠点に在庫を持つ1つの顧客には請求書が1通か3通か。

同じ中国東部の3PLがここでつまずいた。2拠点目の開設時、営業が受注のために1拠点目の料率表で見積もりを出したのに、新拠点の賃料と人件費は実際には高かった。拠点間転送ではlinehaulコストが拠点Aのコストセンターに残り、保管収益は拠点Bが計上した。四半期末、経理が見つけたのは、拠点Aで顧客がマージンマイナス、拠点Bで人為的にマージンが膨らんだ状態。3か月分の誤った記帳、泥沼の消し込み、料率の全面再交渉である。

次元	分離（拠点ごと台帳）	共有（ネットワーク全体で1台帳）	ハイブリッド（クライアント/部門ごとに分離）
在庫台帳	拠点ごとに1台帳	ネットワーク全体で1台帳	クライアントまたは事業部門ごとに台帳
最適なケース	クライアントが重ならない3PL	自社拠点、SKU体系が統一	ネットワークを共有する複数事業部門のグループ
権限の複雑さ	低い	高い（3次元の権限が必要）	中程度
請求の難しさ	低い（各拠点が個別に精算）	高い（按分ルールが必要）	中程度（クライアントごとに請求を統合）
主なリスク	拠点間連携がオフラインになる	次元の混乱で在庫の取り違えが起きる	マスタデータはネットワーク全体で統一が必須
マスタデータの要件	各拠点が独自にコード付け可	SKUコードはネットワーク全体で統一が必須	統一コード＋クライアント単位の属性

この表の1行は、それだけで1段落の価値がある。マスタデータだ。SKUコードは、あらゆるマルチサイトシナリオでネットワーク全体で統一されなければならないのに、多くの企業は事後になって初めて気づく。拠点Aは「SKU-001」、拠点Bは「SKU-001-A」と呼び、拠点間転送とネットワーク全体の在庫引当照会は即座に破綻する。2拠点目の稼働前に統一すること。後から履歴データを洗い直すのは、チームが辞めたくなる種類の仕事だ。

トレンド判断：マルチサイト対応は「売り文句」から「当たり前」へ

根拠は3つある。第1に、年間約16％の成長の中で、既存顧客の拡張は主要な収益源であり、ベンダーにはマルチサイト対応を標準化するインセンティブが十分にある。第2に、主要クラウドWMSベンダーの過去2年間のリリースノートは一貫してマルチサイト・マルチテナント、拠点間の可視性、請求の統合を強調してきた。第3に、3PLの業界再編により、買収のたびにWMSインスタンスと台帳の統合が続く。

私の判断はこうだ。2027年より前に、「ネイティブにマルチサイト」はベンダーの差別化要素から選定の当たり前要件に移る。10年前に「バーコード対応」がそうなったように。もはや誰も広告しないが、それがなければショートリストに入らない。権限と請求の標準化はもっとゆっくり進む。各社の組織構造と財務ポリシーに絡みついており、ベンダーは道具は提供できても答えは提供できないからだ。

注目すべき変数が1つある。AIによる転送推奨だ。WMSがネットワーク全体の在庫と予測に基づいて「拠点Aではなく拠点Bから出せ」と自動提案するようになると、古い次元と権限の問題は増幅される。機械は、人間が取り違えに気づくよりはるかに速く判断するからだ。次のマルチ倉庫の落とし穴はそこに隠れているかもしれない。