本稿は、物流DXを構造的に捉え直す全3回のシリーズの第3回である。 物流DXがうまくいかない理由の一つは、フェーズが引き継がれるたびに前提がこぼれ落ちていくことにある。コンサル、SI、パッケージベンダー、3PL（サードパーティ・ロジスティクス、荷主に代わって物流業務を専門に受託する事業者）——各フェーズで必要な能力は別物であり、得意とする担い手も違う。分業そのものは当然の前提として、フェーズごとに最適な担い手を選び、その繋ぎ目を設計すること。物流DXの成否は、この設計の質にかかっている。

本稿の結論を先に置く。物流DXの成否を分けるのは、システムの優劣以上に、座組設計の質である。

記事1「物流DXを止める二重の分断 ― 需要側と供給側、それぞれの内側で」では、物流DXが停滞する構造を「1つの根本課題（つなぐ役の不在）と3つの主な問題（データ・KPI・投資判断の分断）」として整理した。記事2では、その構造に対する処方箋として、物流の役割、設計の起点、推進主体を問い直す3つの視座転換を示した。

本記事の問いは、その先にある。では、誰が、どのフェーズを、どう担うのか。

分業そのものは、避けられない。構想から運用までを一つの担い手が通しで背負うことは現実的ではないし、そもそも各フェーズで問われる能力が違う。論点はその先にある。分業すれば、担い手と担い手の間には必ず繋ぎ目が生まれる。この繋ぎ目を誰が持つのかが決まっていないと、フェーズが進むたびに、前のフェーズの前提が引き継がれないまま次が走り出す。

「構想で終わらせない」の本当の意味は、フェーズごとに最適な担い手を選び、それらを連結する設計をすることである。本記事では、これを「座組設計」と呼ぶ。

物流・SCMを捉える2つの3層

クオンティアが荷主企業の物流DXを支援する際には、2つの3層で物流・SCMを整理している。両者は補完関係にあり、両方の軸で捉えて初めて、実装に落とし込むことができる。

1つ目は、業務機能軸の3層——「何を最適化するか」である。ネットワーク設計（第①層、事業横断）は、拠点配置、輸送網、アセット戦略といった、年単位（3〜5年）の構造的な意思決定を扱う。計画系業務（第②層、事業別）は、需給計画、在庫計画、アロケーションといった、月次〜週次のパラメータ調整を扱う。実行系業務（第③層、事業横断）は、輸配送、倉庫、構内物流といった、日次のオペレーションを扱う。

なぜ①と③が事業横断で、②が事業別なのか。ネットワーク（①）と実行（③）は、物量を束ねるほど効果が出る領域である。規模の経済が働くためだ。倉庫の集約、共同配送、輸送モードの最適化は、いずれもこの規模の経済によって成り立っている。一方、計画（②）は、事業ごとに需要特性——変動パターン、顧客要求、製品ライフサイクル——が異なるため、目的関数を事業別に設定する必要がある。

2つ目は、技術スタック軸の3層——「どう実装するか」である。第1層は基幹システム統合層で、ERP（統合基幹業務システム）、SCP（需給計画システム）、WMS（倉庫管理システム）、TMS（輸配送管理システム）、LMS（労務管理システム）といったシステムの機能配置、業務設計、統制設計を扱う。

第2層はデータ統合層で、MDM（マスタデータ管理）、データレイク／ウェアハウス、ETL/ELT（データの抽出・変換・格納処理）、API連携基盤を扱う。第3層はAI活用層である。ここには性質の異なる2種類が同居している。1つは需要予測、配車最適化、画像検品のように、因果は自明ではないが分析すれば最適解に近づける領域を担うAIである。もう1つはエージェント型AIのように、因果が事前には確定できず、やってみて初めて筋が見える領域を担うAIである。

技術スタック軸は、業務機能軸の各レイヤーを「どう技術で支えるか」を設計するものである。ここで順序が肝心になる。第1層（業務・統制設計）が定まらないまま第2層に進むと、データ統合は形式的なものにとどまる。第3層のAIのうち、需要予測や配車最適化のような分析型は、学習データの質がそのまま精度を決めるため、下の層の整備が前提になる。ただし、エージェント型のAIはこの限りではない。むしろ先に動かすことで、下の層のどこが不足しているかが具体的に見えてくる。

業務機能軸が「What（何を最適化するか）」であるのに対し、技術スタック軸は「How（どう実装するか）」である。実装現場では、業務機能軸の①②③それぞれを、技術スタック軸の第1〜3層で実装していく。この二軸で捉えることで、初めて「何を、どこまで、どう作るか」が定まる。

この二つの3層を図に整理すると、次のようになる。

図表6　物流DXの設計マトリクスと推奨着手順序

具体的には、第1層（基幹システム統合）では、ネットワーク設計（①）なら拠点・輸送網の意思決定をどのシステムのどの機能に担わせるかを定義し、計画系業務（②）ならSCPで需給・在庫計画のプロセスと権限を設計し、実行系業務（③）ならWMS/TMSの機能範囲と拠点間の役割分担を定める。

第2層（データ統合）では、①は拠点・アセットのマスタを複数システム間で一意化し、②は需給計画と在庫実績のデータを日次で同期させ、③は出荷・配送実績のデータをリアルタイムに近い形で連携させる。第3層（AI活用）では、①はネットワーク最適化AIで拠点・輸送網のシナリオを比較し、②は需要予測・アロケーションAIで計画精度を上げ、③は配車最適化AIや画像検品AIで日々のオペレーションを支える。

ここで、我々の独自の論点も示しておきたい。AIの本当の使い所についてである。第3層のAI活用は、業界紙等で報じられる事例——人員配置、梱包、需要予測——の延長線上、すなわち「今ある倉庫・輸送をうまく回す」というオペレーション最適化だけに閉じるものではない。半歩先のAIの使い所は、「どこで作り、どこに置き、どれだけ運ぶか」という構造そのものをAIによって描くこと、すなわち意思決定そのものの生成にある。

AIは、記事1「物流DXを止める二重の分断 ― 需要側と供給側、それぞれの内側で」で述べた「どれだけ運ぶかを問う」という論点を具体化し、在庫と輸送のトレードオフを定量的に解くエンジンとして位置付けたい。ただし、この位置付けは現時点では仮説の域を出ない。。日本企業で生成AIを業務で活用している割合は34.5%にとどまり、14.2%は活用を検討中というデータもある（出典：帝国データバンク「生成AIに関する企業の動向調査」2026年3月）。新技術の普及は理論的な優位性ではなくROIと運用負荷で決まる。意思決定生成エンジンとしてのAIも、実装の前にその検証を避けられない。

よくある4つの失敗パターン

3層モデルを理解していても、入り方を誤ると失敗する。典型的な失敗パターンは4つある。

1つ目は、AIの性質を取り違えることである。需要予測や配車最適化のように、分析すれば最適解に近づける領域では、学習データの質がそのまま精度を決める。ここから入って成果が出ないのは、AIの限界ではなく下の層が整っていないことの結果にすぎない。一方、正解が事前には定まらない領域では、話が逆になる。

この領域では、最初から正解の計画を設計するより、小さく試して学び、判断を更新していく方が現実的である。エージェント型AIを使った試行はまさにここに効く。データが整っていなくても人が介在する形で動かせるうえ、手を動かすことで初めて、自社のどのデータが使い物にならないか、どの業務なら効果が見込めるかが具体的に見えてくる。試すこと自体は、むしろ積極的に勧めたい。避けたいのは、試行で得た知見をユースケースとして整理せず、ROIが見込める領域に投資を寄せる段階へ進めないまま、PoCだけが個別に積み上がっていく状態である。これは、記事2「物流をコストセンターから動かす視座転換 ― 役割、設計の起点、推進主体を問い直す」で示した「視座転換①」「物流の役割」を欠いた状態に対応する。

2つ目は、WMS先行で進むケースだ。第1層のWMSから刷新を始めると、データ統合が後回しになり、全体最適に届かない。記事2の「視座転換②」「設計の起点」を欠いた状態に対応する。

3つ目は、データ基盤を先に作るパターンだ。第2層のデータ基盤から構築を始めると、業務に紐づかず、「ただのデータレイク」になってしまう。記事1で示した組織の分断——つなぐ役の不在——の現れである。

最後の4つ目は、個別最適の積み上げである。各部署・各拠点で個別の改善を積み上げても、局所では効いていても、全社の数字には響かない。記事1の根本課題と主な問題、記事2の「視座転換③」の欠如に対応する。

これらに共通するのは、記事1、2で示した構造への対応を欠いていることだ。

どの順序で着手するか——Phase 0からStep 4まで

では、実際にどの順序で着手すればよいのか。推奨する着手順序は、Phase 0からStep 4までの合計5段階で構成される——Phase 0（ファクト整備）、Step 1（経営アジェンダの明確化とCLO権限設計）、Step 2（全体統合構想策定）、Step 3（データ統合実装）、Step 4（領域別実行）である。以下に示す所要期間は目安であり、企業規模や対象範囲によって増減する。

まず着手すべきは、Phase 0——ファクト整備、すなわち可視化と物流費ベースラインの整備である（目安、〜3ヶ月）。すべての議論の前に、物流費と在庫のベースラインを整えておく必要がある。具体的には、連結子会社から最終顧客までを含めた物流費の網羅的な把握（物流費が「売上比5%」だと思われていても、実際には7%かもしれない。それが事業・地域・費目のどこに偏っているのか）、そして在庫データの棚卸しと統合方針（工場、地域拠点、海外販社の在庫を一気通貫で見られるか）である。

Phase 0を最優先に置く理由は、単に「データがないと困るから」ではない。第一に、議論を空中戦から地上戦に変えられる。ファクトがあれば、以降のネットワーク設計は仮説検証型で進められる。第二に、効果測定の物差しができる。各施策の効果を、金額で語れるようになる。第三に、事業部を巻き込む武器になる。CLO（物流統括管理者）が荷主として事業部と対話する際、最も説得力のある材料になる。Phase 0の成果物である「物流費・在庫のベースライン」は、以降すべてのフェーズにおける効果測定の物差しとなる。

老朽化した基幹システムでは、設計書が現存しないか実態と乖離しており、現状把握のためにソースコードから仕様を読み解く必要に迫られるケースもある。COBOLやAS400で組まれた基幹システムはその典型で、解読できる技術者自体が社内にほとんど残っていないことも珍しくない。調査コストとスケジュールへの影響は、Phase 0の段階であらかじめ織り込んでおくべきである。

続くStep 1は、経営アジェンダの明確化とCLO権限設計である（目安、1〜2ヶ月）。経営課題を物流DXの論点に翻訳し、投資ROIを全社の目的関数（利益率、CO2、サービス水準）で設計する。ここで必ず決めるべきなのが、CLO（あるいはそれに準ずる機能）の権限範囲である。業務機能軸の3層（前章参照）に対応して、次のように分けることを推奨する。

ネットワーク設計（①、事業横断）：拠点配置・輸送網・アセット戦略の意思決定権限を含めてCLOがオーナーとなる。

計画系業務（②、事業別）：事業部がオーナーとなり、CLOはガバナンス機能を担う。計画プロセスの標準、サービスレベル目標、在庫水準をモニタリングする立場である。

実行系業務（③、事業横断）：輸配送・倉庫の運営方針を含めてCLOがオーナーとなる。

データ・KPI基盤：全社共通の物流KPI体系としてCLOがオーナーを担う。

この権限分担が曖昧なままStep 2以降に進むと、事業部との合意形成でつまずくことになる。「事業部にとってのメリットを財務KPIで示す」ことがCLOの役割となり、記事2で示したROIC（投下資本利益率）分解ツリーが、その際の共通言語となる。

Step 2は、全体統合構想策定である（目安、3〜6ヶ月）。SCM・物流の機能配置設計、マスタとデータのオーナーシップ設計、ロードマップの確定を行う。

Step 3は、データ統合実装である（目安、6〜12ヶ月）。MDM・データ基盤の構築、既存システムとの接続を進める。

Step 4は、領域別実行である（並行・継続）。WMS・TMS・LMSの刷新、AI活用の個別テーマ、現場業務改革を進める。

Phase 0からStep 4までの流れを図に整理すると、次のようになる。

図表7　物流DXの推奨着手順序ロードマップ

最後に留意すべきは、物流システムの長期サイクルとオーナーの分散である。物流システムは刷新サイクルが長く、TMSやWMSでは10〜20年に及ぶ。オーナーシップも分散している——荷主はERP/SCPおよび設備投資としてのWCS（倉庫制御システム）・マテハン（マテリアルハンドリング機器）を、物流子会社や3PLはTMS/WMSを、それぞれ担っている。着手順序は、「誰の予算で、誰の責任範囲を動かすか」という組織設計とセットで描く必要がある。

誰が、どのフェーズを担うのか

ここからが本記事の核心である。物流DXの実装には、複数種類のプレイヤーが関わる。構想策定は戦略コンサルと業務コンサルが、要件定義はコンサルとSI上流が、開発・構築は大手SIが、パッケージ導入は製品知見のある専門ベンダーが、運用・改善は3PLや自社運用部門が、それぞれ担う。この分業構造とフローを図示すると、次のようになる。

図表8　構想・要件・実装の分業と座組設計

各プレイヤーの強みは、コンサルティング能力とは別種の専門性であり、互いに代替が利かない。大手SIerには、金融や製造の大規模基幹システムを完遂してきた実装力と組織力がある。パッケージベンダーには、何百社もの導入で磨かれた業務テンプレートとカスタマイズノウハウがある。3PLには、日々の現場オペレーションを回し続けてきた実装知がある。

担い手が替わるたびに、繋ぎ目が生まれる。構想フェーズで前提としていた業務設計が要件定義にどこまで反映されたか、要件定義で決めた機能範囲が開発でどう解釈されたか、その解釈が現場の運用と噛み合うか。この引き継ぎがどの担い手の責任範囲にも入っていないと、小さなずれが静かに積み上がっていく。

この構造的なリスクは、実際の訴訟にも表れている。ある大手物流事業者は、国際航空貨物の基幹システム開発を大手SIerに一括で委託したが、テスト段階で品質不良が繰り返し発覚し、約124億円の損害賠償を求めて提訴したと報じられている［1］。

あるメーカーでも、基幹システム刷新の一環で物流管理システムの要件定義から実装までを1社に一括発注した結果、機能間連携の不整合や業務フローと乖離したテスト設計が原因で、システムテスト段階で問題が発覚し、約39億円の損害賠償請求に発展したと報じられている［2］。いずれも訴訟であり最終的な責任の所在は係争の対象である。ただし、どちらも問題が表面化したのがテスト段階だった点は共通している。繋ぎ目で生じたずれは、その場では見えない。最も手戻りが大きい段階まで進んで、初めて姿を現す。

成功している企業を見ると、フェーズに応じて適切なパートナーを切り替えながら、全体の整合は荷主側（あるいは構想策定を担った当事者）が取り続けるという座組を組んでいる。クオンティアが目指したいのも、この立ち位置である。荷主企業の側に立ち、各フェーズで最適な担い手を組み合わせる役割を担いたい。

構想と実装をつなぐ役は、誰が担うのか

コンサルティングの伝統的な関わり方は、構想策定と提言で完結していた。しかし物流DXのような全体最適変革では、構想と実装の間に深い谷があり、誰かがその谷を渡らせる必要がある。

AIが分析・提言の領域を急速に浸食している今、構想策定だけで価値を出し続けることは、さらに難しくなっていくだろう。ここで改めて強調しておきたいのは、「実装まで責任を持つ」とは、全フェーズを自ら手を動かして担うことではないということだ。各フェーズの最適な担い手を組み合わせ、その繋ぎ目に責任を持ち続けることである。

記事2「物流をコストセンターから動かす視座転換 ― 役割、設計の起点、推進主体を問い直す」で示した通り、CLOの選任自体は着実に進んでいるが、役員級として実働している比率はごく一部にとどまり、人材基盤の整備が追いついていない企業は少なくない。既存のコンサルやSIerの多くも、法令対応という「義務」の範囲にとどまっている。

CLOに「経営の打ち手」——運ぶ量と在庫のバランス設計、全社標準の整備、コストの可視化——を渡し、構想から定着までを伴走する機能は、業界全体としてまだ手薄である。構想と実装の間の谷を渡らせる役割を、誰が担うのか。この問いへの答えが、次の物流DX変革の質を分けることになる。

自社を診断する5つの質問

最後に、自社の現在地を確認できる5つのチェックを示しておきたい。物流DX変革を始める、あるいは見直そうとしている経営層・推進責任者向けの診断観点である。

①経営アジェンダ起点になっているか（記事2・「視座転換③」）

②データ統合の青写真があるか（記事1・データの問題／記事2・「視座転換②」）

③CLO的役割が機能しているか（記事1・つなぐ役の不在／記事2・「視座転換③」）

④構想と実装が分業設計されているか

⑤継続改善の仕組みがあるか

チェックが3つ以下だった場合、本シリーズで示した分断の影響を強く受けている可能性が高い。

まとめ

物流DXを実際に動かすには、業務機能軸（ネットワーク・計画・実行）と技術スタック軸（SCM統合・データ・AI）の二軸を貫く座組設計が必要である。Phase 0のファクト整備とCLO権限の3層マッピングを起点に、構想・要件・実装の各フェーズを、コンサル・SI・パッケージベンダー・3PLといった専門性の異なる担い手に分業させ、その繋ぎ目に責任を持ち続けること。

分業そのものではなく繋ぎ目の設計が、物流DXの成否を分ける。構想と実装の間の谷を渡らせ、CLOの実働を支える機能は、業界全体としてまだ手薄なままである。自社の現在地は、本シリーズで示した5つのチェックで確認できる。

→PSX 物流／SCMチームへの個別相談

【出典】

［1］日経クロステック「日本通運が基幹システムの開発失敗を巡ってアクセンチュアを提訴、124億円の賠償請求」2024年9月26日、https://xtech.nikkei.com/atcl/nxt/column/18/00001/09779/

［2］日経クロステック「動かないコンピュータ」2018年10月1日、https://xtech.nikkei.com/atcl/nxt/cpbook/18/00002/00008/

シリーズ完結のお知らせ

本記事は、物流DXを構造的に捉え直す3記事シリーズの最終回である。

・記事1「物流DXを止める二重の分断」

・記事2「物流をコストセンターから動かす視座転換」

・記事3（本記事）「構想・要件・実装の分業 ― 物流DXの座組設計」