公開2026.08.25更新2026.09.25 Webシステム

物流のデータ連携｜社内WMS・TMSと企業間EDIの二層設計と標準への寄せ方

倉庫では出荷が終わっているのに、基幹システムの在庫が翌朝まで動かない。運送会社から届く実績はPDFで、運賃の突き合わせは月末に人が電卓を叩く。物流のデータ連携で相談を受ける場面は、たいていこの二つが同時に起きています。原因は連携ツールを入れていないことではなく、社内のシステム間でつなぐ話と、荷主や運送会社との企業間でつなぐ話を、ひとつの要件定義に混ぜてしまう点にあります。本記事で扱うのは、二層の切り分け方、区間ごとに渡すデータと締め時刻の決め方、標準仕様へ寄せるかどうかの判断、そして法制度側から逆算して必要になる数字の取り出し先です。API連携そのものの仕組みはAPI連携の仕組みとデータ連携との違いを整理した解説に譲ります。

まとめ：物流のデータ連携で先に決める四項目と着手の順序

結論を先に書きます。物流のデータ連携で先に決めるのは、製品でも基盤でもありません。①社内連携と企業間連携のどちらを先に手当てするか、②在庫と出荷実績の正本をどのシステムに置くか、③締め時刻と再送のルール、④取引先ごとに指定される通信手順と伝票種別の一覧。この四つです。ここが埋まらないまま見積もりを取ると、金額が二倍三倍に振れます。

二層のうち、自社の裁量が効くのは社内側だけです。企業間側は取引先が手順も伝票種別も決めるため、自社で選べるのは「どこを境界にして、その内側をどう作るか」に限られます。境界の位置を先に固定しておくと、取引先が増えても社内の作り込みを触らずに済みます。

標準仕様への対応は義務ではなく判断です。国土交通省が示す物流情報標準ガイドラインは2025年2月にVer.3.00へ改訂され、ポータルは一般社団法人フィジカルインターネットセンターが管理しています。新しい取引先が年に何件も増える事業者は寄せる価値がありますが、取引先が固定されている事業者は独自仕様のままで足ります。

そして期限のある話がひとつあります。改正物流効率化法は2025年4月に第一段階が施行され、2026年4月からは特定事業者に中長期計画の提出・定期報告・物流統括管理者の選任が課されました。報告に使う荷待ち時間や積載率は、どのシステムにも自動では溜まりません。連携の設計に「報告用の数字をどこから取るか」を含めておくのが、いま着手する事業者の実務的な出発点になります。

物流のデータ連携を社内システム間と企業間の二層に切り分ける理由

物流のデータ連携という言葉には、性質のまったく違う二つの作業が同居しています。ひとつは自社が持つ基幹システム・倉庫管理システム・輸配送管理システムの間でデータを往復させる社内連携。もうひとつは荷主企業と元請の物流事業者、その先の実運送事業者の間でデータを受け渡す企業間連携です。この二つは決定権の所在が違うため、同じ土俵で要件を書くと必ず詰まります。決定権の所在で層を切り分ける手順は業種を問わず効き、医療のデータ連携を院内・地域・全国の3層で整理した解説でも同じ形を採っています。

社内の三点＝基幹とWMSとTMSの間で往復するデータの向きと範囲

社内側の登場人物は三つに整理できます。受注と在庫と請求を持つ基幹システム、庫内の入出荷とロケーションを持つ倉庫管理システム（WMS）の機能と在庫管理との違いを整理した解説、そして車両手配と運賃を持つ輸配送管理システムです。三点それぞれが在庫や出荷の情報を持っていますが、意味が同じとは限りません。基幹が持つのは伝票上の理論在庫で、WMSが持つのは棚にある実在庫です。二つがずれたとき、どちらの数字で確定させるかを決めていないと、連携した瞬間に「数が合わない」という報告だけが増えます。

企業間の三者＝荷主と元請と実運送で仕様の決定権が移る位置と条件

企業間側は、力関係がそのまま仕様になります。受発注のデータ形式は荷主が指定し、輸送依頼の形式は元請の物流事業者が指定し、実際に走る運送事業者はその下で紙や電話に戻る、という段差がよく起きます。多階層の委託構造では、上流で電子化された情報が二次委託の手前で途切れ、そこから先は人が転記する形になりがちです。企業間の設計では、どの階層まで電子で届いていて、どこから人手に落ちているかを先に図に描くのが出発点になります。

二層を混ぜて一本の要件定義に入れると連携仕様が固まらない事情

二つを混ぜると何が起きるか。社内の在庫連携を検討している最中に「取引先A社のWeb EDIの画面入力もまとめて自動化したい」という話が入り、A社の画面仕様の調査待ちで在庫連携まで止まる、という進み方になります。社内側は自社で仕様を決められるため数週間で確定できますが、企業間側は取引先との調整が入るため数か月単位です。所要時間の桁が違うものを一本の工程に並べると、短いほうが長いほうに引きずられます。業種をまたいだ連携の型についてはデータ連携の6つの型と業種別の制約を整理した事例記事で扱っており、物流は「企業間EDIの型」と「基幹とSaaSをつなぐ型」が重なる位置にあります。

社内システム間で渡すデータの向きと締め時刻を区間ごとに確定させる

社内連携の設計は、区間を数えることから始めるのが基本です。基幹・WMS・TMSの三点をつなぐと区間は四本になり、それぞれ渡すデータも頻度も違います。ここを一枚の表にして関係者で合意しておくと、後の見積もりが安定します。入荷予定を庫外の受付側へ渡す区間を足すなら、バース予約管理システムの比較｜7つの選定軸と自社倉庫への適合判断で連携方式ごとの制約を確認しておくと設計が早く固まります。

区間	主に渡すデータ	発生の頻度	先に決めておく点
基幹→WMS	入荷予定・出荷依頼	日次と随時	締め時刻と取消の扱い
WMS→基幹	入出荷実績・在庫数	都度または日次	在庫の正本の置き場
WMS→TMS	出荷確定・重量と容積	出荷確定の直後	車建てのまとめ単位
TMS→基幹	運賃・配送実績	締め日の単位	請求との突合の方法

棚の実在庫と伝票の理論在庫のどちらを在庫数の正本に置くかの決め方

在庫の正本は、原則としてWMS側に置きます。棚卸しで数え直せるのは現物であって伝票ではないからです。ただし販売可能数を外部のECサイトへ出している場合は話が変わり、引当済みの数量を差し引いた値を基幹側で持たないと、二重に売れる事故が起きます。実務では「現物の数はWMS、引当と販売可能数は基幹」と役割を割り、両者の差分を日次で照合するレポートを一本作る形が扱いやすい構成です。差分がゼロにならないときは、連携の不具合ではなく庫内の作業手順に原因があることのほうが多くなります。

基幹からWMSへ渡す出荷依頼の粒度と締め後の取消を受け付ける期限

出荷依頼で決めるのは三つ。何時までに受け付けた依頼を当日出荷の対象にするか、締め後の追加をどう扱うか、そして取消と数量変更をいつまで受け付けるか。ここを決めずに連携だけ作ると、ピッキング開始後に届いた変更データがWMSに入り、現場が二度手間になります。締め時刻はシステムの都合ではなく、庫内の作業開始時刻から逆算して決めるものです。締め後の依頼は連携から外し、電話と手入力の例外運用として残したほうが、全体としては安く収まります。

WMSからTMSへ渡す出荷確定データと車建て単位の換算規則の置き場

庫内で梱包が終わると、出荷単位は伝票の行から物理的な個口へ変わります。輸配送側が必要とするのは、届け先ごとの個口数・重量・容積、そして時間指定です。ここでよく起きるのが単位の不一致で、WMSがケース単位で持っている重量を、TMSは個口単位で求めるという食い違いです。換算の規則をどちらのシステムに持たせるかを決めておかないと、運賃の計算が合いません。配車側の機能範囲は配車管理システムの機能と費用・導入判断を整理した解説で扱っています。

TMSから基幹へ戻す運賃と実績を月次の締め時刻に間に合わせる方法

最後の区間は運賃です。実績運賃が基幹へ戻らないと、荷主への請求も運送会社への支払も人手の突き合わせになります。ここは日次で流す必要がなく、締め日の単位でまとめて渡す設計で足ります。むしろ決めるべきは、実績と契約運賃が食い違ったときにどちらを正とするか、差額の調整をどの伝票で立てるか、という業務側のルールです。連携の作り込みより先に、経理と現場の合意を取っておく箇所になります。

企業間連携で相手が決める通信手順と自社が決められる境界の位置

企業間側は、自社の設計思想が通りません。取引先が指定した手順と伝票種別に合わせるのが前提で、複数の取引先がいれば複数の方式が並走します。それでも打つ手はあります。境界を一点に集約し、その内側だけを自社の都合で作ることです。

受発注と輸送依頼で使われる連携方式が別系統になる業務上の事情

物流の企業間データは、大きく二系統に分かれます。荷主と受注側の間で流れる受発注・出荷案内・受領のデータと、荷主や元請と運送会社の間で流れる輸送依頼・配車回答・輸送実績のデータです。前者は伝統的にEDIの領域で、取引先ごとに通信手順と伝票種別が指定されます。後者は求貨求車のサービスや元請が用意した専用の画面を経由することが多く、標準化の度合いが下がる傾向です。二系統は接続先も担当部署も違うため、同じ仕組みでまとめようとすると設計が破綻します。導入の工程そのものはEDI導入の六工程と基幹システム連携の進め方をまとめた解説に整理しています。

画面入力しか用意されない取引先を人手のまま残すかの判断の分かれ目

取引先がWeb画面しか提供していない場合、自動化の手段は限られます。判断の基準は件数と例外の多さです。月間の伝票が数十件で、内容の確認を人が見て行っている取引先は、画面入力のまま残したほうが安全です。逆に日々数百件が流れ、担当者が二画面を見比べて転記しているなら、自動化の対象になります。ここで画面操作の自動化に踏み切る場合、取引先の画面変更のたびに生じる保守負担も設計条件です。iPaaSでどこまで巻き取れるかはiPaaSでEDI連携を組む場合の役割分担と移行設計の判断で詳しく扱っています。

多階層の委託構造でデータが人手に落ちる箇所を先に特定する方法

元請から二次・三次へ委託が流れる構造では、電子データは一段目までしか届かないのが通例です。二段目から先は電話とメールで、運行の結果は紙で戻ってきます。この段差を一気に電子化しようとすると、取引先である運送会社に端末と手順を強いることになり、実運用が続きません。現実的なのは、戻りのデータだけを軽い形式で受け取る方法です。到着の報告をスマートフォンの画面から数項目だけ入力してもらう、といった粒度に落とすと定着します。

物流情報標準ガイドラインへ自社の項目を寄せるかどうかの判断基準

企業間の項目名やコード体系を、業界標準に合わせるかどうか。物流のデータ連携で必ず出てくる論点です。結論から言えば、これは義務ではなく費用対効果の判断であり、判断軸は新しい取引先が増える頻度に置きます。

ガイドラインの版と管理主体・扱うデータ範囲を先に押さえておく

国土交通省は物流情報の項目名やデータ形式をそろえるための指針として、物流情報標準ガイドラインを公開しています。2026年8月時点で示されている版は3.0系で、Ver.3.00への改訂は2025年2月に公表されました。改訂の要点として挙げられたのは、標準貨物自動車運送約款の改正への対応、新しいトラックの標準的な運賃への対応、物流サービス提供者が参画する標準プロセスの追加、運送事業者から荷主企業へのCO2排出量報告への対応、そして利用のしやすさの向上です。ポータルの管理は一般社団法人フィジカルインターネットセンターが担っており、利用手引も別途公開されています。版が変わる前提の資料なので、参照時点を社内資料に必ず書き添えてください。

標準へ寄せる価値が出る条件は新規取引先の追加頻度と件数で決まる

標準へ寄せる利点は、初回ではなく二社目以降に出ます。項目の意味を自社で定義し直す作業が要らなくなり、新しい取引先を追加するときの設計工数が下がるからです。目安として、年に三社以上の新規接続が発生する事業者、あるいは荷主側から標準準拠を求められる可能性がある事業者は、寄せておく価値があります。逆に接続先が数社で固定され、新規の追加が数年に一度という事業者は、いま寄せても回収できません。

独自仕様のまま進めてよい場面と後から標準へ寄せ替えるときの手順

独自仕様のまま進めてよいのは、接続先が固定されていて、既存の連携が業務として回っている場合です。その場合でも、後から寄せ替えられるように一つだけ手を打っておきます。社内のコード体系と取引先のコードを対応づける読み替え表を、プログラムの中ではなく外部の表として持つことです。読み替え表が外に出ていれば、標準へ寄せる作業は表の差し替えと変換部分の改修に収まります。プログラムへ埋め込んでしまうと、寄せ替えのたびに全面改修になります。

EDIとAPIを併存させる連携設計で変換をどこに置くかを決める

物流の現場では、取引先が指定する従来型のEDIと、クラウドサービスが提供するAPIが同時に存在します。どちらかへ統一するのは現実的ではないため、併存を前提に構成を組みます。

変換とコード読み替えを一箇所へ集約する構成が保守工程で効く理由

推奨する構成はひとつです。取引先ごとの手順の差は入口で吸収し、そこから先の社内側には単一の形式でデータを流します。入口を複数に分けて、それぞれが基幹システムを直接更新する構成にすると、取引先が増えるたびに基幹側へ手が入り、テストの範囲が毎回全体へ広がる構造です。集約点を一つ設けておけば、新しい取引先の追加は入口の追加だけで済みます。手段の選び分けはiPaaSとデータ連携基盤と受託開発を使い分けるツール選定の解説に整理しています。

再送と二重取り込みを防ぐために決めておく一意の識別子の組み立て方

企業間の連携では、通信の失敗と再送が日常的に起きます。設計で決めるのは、どの単位を一意の識別子にするかです。取引先の伝票番号だけでは、訂正伝票が同じ番号で再送されたときに区別できません。取引先コード・伝票番号・伝票種別・改訂の連番を組み合わせた鍵を作り、同じ鍵のデータが二度届いたら後着を無視するか上書きするかを、伝票種別ごとに決めておきます。ここを詰めずに稼働させると、出荷指示が二重に出て現場が二重に出荷する事故につながります。

ツールで巻き取る範囲と受託開発へ回す範囲を切り分ける判断観点

切り分けの基準は、基幹システム側に手が入るかどうかです。接続先にAPIがあり、渡す項目もそのまま流せる範囲であれば、既製のツールで足ります。一方、伝票の項目を業務ルールに沿って組み替える、在庫の引当を条件つきで走らせる、締め処理と競合しないように更新の順序を制御する、といった処理が入るなら、基幹側の作り込みが必要です。この領域は物流システム開発として、既存システムの改修とあわせて設計する形が扱いやすくなります。判断に迷う場合は、接続の本数ではなく「基幹のデータを書き換えるか、読むだけか」で線を引いてください。

改正物流効率化法の義務対応でデータ連携に加わる報告用データの要件

物流のデータ連携には、業務効率とは別の締め切りが加わりました。法制度が求める報告のために、これまで誰も集計していなかった数字が要るようになったためです。

特定事業者に課される計画と報告の枠組みと制度が施行される時期

改正物流効率化法は2024年に成立し、2025年4月に第一段階が施行されました。続く2026年4月からは、一定規模以上の荷主や物流事業者が特定事業者に指定され、中長期計画の作成と提出、定期報告、そして物流統括管理者の選任が課されています。自社が指定の対象かどうかは取扱貨物量などの基準で決まるため、まず該当の有無を確認するのが先です。制度の背景と物流業界全体の課題は物流DXの定義と2024年問題・改正物流効率化法を踏まえた進め方で扱っています。

荷待ち時間と積載率の数字をどの社内システムから取り出すかの判断

報告で求められる指標のうち、システムに素直に溜まっているものは多くありません。荷待ち時間はバース予約や動態管理の記録から、荷役の時間は庫内作業の実績から、積載率は輸配送の実績と車両の容積から組み立てます。ここで問題になるのが、記録の粒度です。到着と出発の時刻が分単位で残っていない、車両ごとの積載重量が伝票の合計としてしか残っていない、といった状態では、後から集計できません。連携の設計時に「報告で使う項目を実績データへ残す」という要件を一行入れておくだけで、翌年の集計作業が変わります。

物流のデータ連携に着手してよい三つの条件と、手作業のまま見送る場面

ここまでの整理を、着手の判断として言い切ります。物流のデータ連携に着手してよいのは、次の三つが揃ったときです。第一に、転記の作業が一日あたり一時間を超えて発生していること。第二に、在庫か出荷の数字の食い違いが月に数件以上起きており、その調査に人が時間を取られていること。第三に、つなぐ相手のシステムが今後二年は入れ替わらないと見込めること。この三つが揃えば、投資は回収の見通しが立ちます。

逆に、見送ってよい場面もはっきりしています。取引先が数社で、伝票が月に数十件しかない事業者は、連携を作るより担当者の入力手順を整えるほうが速く効きます。倉庫が一拠点で、WMSをこれから選ぶ段階の事業者も同様です。連携の設計は接続先が確定してからでないと手戻りになるため、システムの選定を先に終えてください。基幹システムの入れ替えが二年以内に予定されている場合も、いまの基幹に合わせた連携は捨てる前提の投資になります。

順序についても言い切っておきます。社内連携と企業間連携で迷ったら、社内から着手してください。理由は二つあります。社内側は自社だけで仕様を決められるため短期間で完了すること、そして企業間で受け取ったデータの受け皿が社内側に整っていないと、企業間をつないでも結局は人が転記することになるからです。受け皿のないところへ電子データを流し込んでも、印刷される紙が増えるだけになります。製造現場を含む連携の階層設計については製造業のデータ連携で設備・MES・基幹を階層別に設計する解説が参考になります。

よくある質問

物流のデータ連携はどこから着手するのが安全ですか？

社内の基幹システムとWMSの区間からです。自社だけで仕様を決められて、効果も在庫差異の減少という形で測りやすいためです。企業間のEDIは取引先との調整に数か月かかるため、社内側と並行して情報収集を進め、社内の受け皿ができてから接続する順序をおすすめします。

WMSとTMSは同じベンダーで揃えないと連携できませんか？

そのようなことはありません。異なるベンダーの組み合わせは一般的で、多くの製品がファイルやAPIによる受け渡しの口を持っています。確認すべきは口の有無ではなく、渡せる項目に必要なものが含まれているか、そして受け渡しの頻度が業務の締め時刻に間に合うかです。製品選定の段階で、連携仕様書を出してもらってください。

取引先ごとに違うEDIをひとつの仕組みにまとめられますか？

通信の部分は取引先の指定に従うため統一できませんが、その内側は一本化できます。取引先ごとの差を入口で吸収し、社内へは単一の形式で流す構成にすると、社内側の作り込みは一つで済みます。取引先が増えても入口の追加だけで対応でき、基幹システムには手が入りません。

物流情報標準ガイドラインへの対応は義務ですか？

義務ではありません。国土交通省が示す指針であり、採用するかどうかは各社の判断です。ただし取引先から準拠を求められる場面はあるため、新規の接続が増える見込みがある事業者は、項目の対応表だけでも作っておくと後の手戻りが減ります。参照する際は版番号と参照時点を記録してください。

データ連携基盤やiPaaSは物流の現場でも使えますか？

基幹より上、つまり基幹システムとクラウドサービスの接続には問題なく使えます。事情が異なるのは従来型のEDIで、取引先が指定する通信手順が既製のコネクタに載っていない場合があり、その部分は国内のEDIサービスを前段に置く構成になります。庫内の機器やハンディ端末との接続も、WMS側の仕組みで扱う領域です。