「配車データを活用したいが、どこから手を付ければいいか分からない」。そんな相談を運送会社の運行管理者や情シスの方から月に何件かいただきます。
デジタコもGPSもTMSも動いているのに、車両側のテレマティクスと本社側の業務システムが別々に閉じていて、拠点や荷主を跨いだ瞬間に実車率も荷待ちの真因も追えなくなる。データの発生源と分析するレイヤーが物理的に離れているうえ、所管部門も運行管理・情シス・営業に分かれているため、稟議で「何をどこまで統合するのか」が言語化しづらいのが実情です。
そこで本記事では、車両データと業務データを1本のスキーマに揃えて実車率・積載率・荷主別採算を追えるようにするための考え方を、運行管理者・情シスのマネージャーがそのまま社内検討に使える形で整理しました。投資回収の考え方はすでにデータ基盤のROIをどう出す？費用対効果の考え方と投資判断のフレームで扱っているので、こちらはアプローチ選定とスモールスタートの手順に軸足を置いています。
運送業のデータ活用が他業種と比べて難しいのは、扱うデータが「秒単位・数百〜数千台の車両・数十〜数百の荷主」であり、しかもデータの発生源と分析するレイヤーが物理的に離れていることに起因します。まずこの構造から見ていきます。
図のように、運送業のデータは大きく2つの階層に分かれています。
車両側（テレマティクス）層は現場のトラックとドライバー側です。デジタコ（デジタルタコグラフ）、GPS、ドラレコ、車載端末、ハンディターミナル、フォークリフトのIoTなど、秒〜分単位で位置情報・速度・加速度・アイドリング・積載重量などを吐き続けます。データ形式はメーカー・機種ごとにバラバラで、矢崎・いすゞ・日野・ドコモ／KDDIのテレマティクスがそれぞれの流儀で蓄積され、同じ「稼働中」でも意味が微妙に違います。
本社側（業務システム）層は本社の基幹側です。TMS（輸配送管理システム）、WMS（倉庫管理システム）、EDIによる荷主からの受注、配車計画、請求、ドライバー給与、燃料原価。粒度は運行単位〜日次〜月次のトランザクションで、こちらは比較的整っています。
この2つの階層は、プロトコルも、粒度も、所管部門も違います。車両側は運行管理・整備が握り、本社側は営業と情シスと経理が握ります。「A荷主の集荷路線の実車率が落ちた日と、その日の配車ミックス・荷待ち時間・燃料コストを1画面で見たい」という当たり前の要望が、この所管の分断のせいで実現できない、というのが多くの運送会社で共通する状況です。
さらに厄介なのが、次の3点です。
車両とデジタコの世代が混在するのが運送業のリアルです。10年前のアナタコ後継の初期型デジタコと、最新の通信型テレマティクスが同じ拠点で動いています。古い車両はSDカード回収でしかデータが取れず、新しい車両は5G／LTEでリアルタイム送信、という混在環境で、共通のデータレイヤーを設計するのがそもそも骨が折れます。ゲートウェイの選定と、メーカークラウドAPIごとの取り込み設計に、想像以上の時間を取られます。
荷主ごとにEDI仕様と運賃体系が違うのも運送業の特徴です。同じ商品でも荷主A社は重量建て、B社は距離建て、C社はチャーター建てで運賃が決まり、EDIのフォーマットもCSV・XML・独自Webフォームと荷主ごとに異なります。実車率・積載率・採算を語るときに「荷主」「路線」「車型」「時間帯」「ドライバー」を必ずセットで持たないと、比較が意味を持ちません。
改善サイクルの主体が配車担当の職人技にあるのが最後のポイントです。ベテラン配車担当の勘と経験は運送業の強みですが、その判断が個人の頭の中に閉じたままだと、複数拠点・複数配車チームに横展開しにくくなります。データが整うと「別拠点では同じ荷主でどう組んでいるか」が横断で見え、配車の効き所そのものが変わっていきます。
こうした構造があるため、拠点数と荷主数が増えるほど、データ活用は「拠点ごとには配車が回るが、全社の実車率・積載率・荷主別採算の因果関係は追えない」という壁にぶつかります。データ基盤の全体像そのものを押さえたい方は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説を先に読んでいただくと、この記事の話がより具体的に感じ取れます。
「うちは配車担当が優秀だから、勘で回っている」と言う運行管理者は多いのですが、実は職人配車の限界サインが出ていることは珍しくありません。次の3つで判断できます。
拠点長・運行管理・配車担当が、日次の実車率・積載率・荷待ち時間を集計できず、月次で経理から締めのタイミングで初めて数字が出てくる状態は、データ基盤化の判断ラインです。3拠点の中規模運送業でも、月次集計に営業日換算で数十時間、5拠点に広げれば年間数百時間の集計工数が消えています。
しかも月末に数字が判明しても、翌月のシフトと荷主受注はすでに動いています。改善アクションが常に1か月遅れる構造では、2025年4月に施行された物流効率化法（荷待ち2時間以内、積載効率向上の努力義務）が求める改善サイクルに追いつけません。車両150台以上の貨物自動車運送事業者は2026年4月から「特定事業者」として中長期計画の作成と定期報告が義務化されており、日次で数字を出せる体制の重みはさらに増しています。単に「集計を楽にする」ためではなく、翌日の配車に前日の結果を反映できる状態を作るためにデータ化するのだ、と目的を切り分けると投資判断がぶれません。
前週火曜日にC路線で戻り便が空車だった、という事実は運行日報で残っています。しかし「あの空車の真因は何だったか」を、翌週の会議で誰も言い切れない。こういう状態は、運行実績と配車履歴と荷主別受注と時間帯別交通量が別々のシステムに閉じていて、真因分析が配車担当の記憶頼みになっている典型的な症状です。
原因が言い切れないと、再発防止策も打ちようがありません。結果として同じ路線・同じ時間帯の空車回送が翌月・翌々月に繰り返され、実車率が3ポイント落ちたまま定着してしまう、というのが運送業で頻繁に見る症状です。
「A荷主の運賃は魅力的だが、実質いくらの利益が出ているか」を、車両稼働・ドライバー拘束時間・燃料・高速代まで含めて、ドライバー単位・運行単位で割り戻せていない状態は、データ基盤化のもう1つの判断サインです。運賃と燃料と拘束時間が別システムにあるため、荷主別採算はどうしても部門全体の粗い数字でしか語れません。
原因は、TMSに運賃データが閉じ、デジタコに拘束時間が閉じ、燃料伝票が別のExcelに閉じ、ドライバー給与が給与システムに閉じている、というデータの分断です。3〜6か月分の全データを1基盤に集めて初めて、荷主別・路線別の真の採算が見えるようになります。
3つのうち2つ以上に当てはまれば、データ基盤化を検討するフェーズに入っています。逆に、1拠点・車両数十台・荷主数社で配車担当が固定されているうちは、Excel＋TMS純正ツールで当面戦えます。業種横断でのExcel限界サインは、Excel集計が限界になったら｜スプレッドシートからデータ基盤への移行にもまとめています。
物流データ基盤の実現手段は、大きく次の3つに分かれます。それぞれ費用感・将来性・自社の関与度がまったく違います。
矢崎、いすゞ、日野、ロジザードなど、既存で導入しているTMS／デジタコベンダーが提供する分析ダッシュボードのオプションを追加し、車両稼働・実車率・急ブレーキ・アイドリングを見える化する方法です。既存契約の延長で始まるため、社内稟議も通しやすく、短期で見える化が始まります。
弱点は、ベンダーごとのスキーマに閉じるため、他社の車両データやWMS・請求・EDIとの突き合わせは基本的にできないこと、そしてベンダーを乗り換えるとデータの引き継ぎが難しいことです。「実車率を見る」までは実現できても、「荷主別採算」「拠点横断の配車最適化」までは踏み込みにくい構造です。
対象を主力拠点1つに絞り、デジタコ／テレマティクスのメーカーAPI・TMS・WMSからのデータをクラウドに集約し、BigQueryやSnowflakeに書き込み、Looker StudioやPower BIで可視化する方法です。SaaSではなく自社のデータ基盤を持つため、後から荷主別採算や複数ベンダーの車両データと結合できる拡張性があります。
弱点は、1拠点で止まると「PoCで終わる」リスクがあること、横展開の際に他拠点で車型・ベンダー・EDI仕様が違うと接続テストで想定以上に工数が膨らむことです。「PoCの範囲」と「横展開の設計」を最初から線引きしておかないと、単発の実験で終わりがちです。データ基盤PoCの進め方と落とし穴はデータ基盤のPoCで失敗しないための進め方と評価基準にまとめています。
複数拠点・全車両のテレマティクスデータと、TMS・WMS・EDI・請求・給与・燃料原価のデータを、本社のクラウドDWH（BigQuery・Snowflake・Databricks）に自動集約し、dbtで統合モデルに変換し、BigQuery MLやSageMakerで動的配車・遅延予測を組み込む方法です。もっとも柔軟で、将来のマッチング型求貨求車・共同配送・海外拠点統合まで拡張できます。
初期費用は3アプローチで最も高く見えますが、複数拠点を持つ運送業では、実車率3〜5ポイント改善と積載率5〜10ポイント改善で1〜2年で投資回収するのが実務での目安です。BigQueryとSnowflakeの選び方はSnowflake vs BigQuery徹底比較｜料金・機能・向く業種の違いを解説、データ基盤の見積もりの内訳はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でくわしく整理しています。
3つのアプローチの選び方は、将来ダイナミック配車や複数拠点の統合運営、共同配送まで踏み込む予定があるかどうかで決めるのが後悔の少ない判断です。特定拠点の見える化だけならアプローチ1で十分。将来のデータ活用まで見据えるなら、最初からアプローチ2でPoCを回し、アプローチ3への段階的な拡張を設計しておくほうが総額を抑えられます。
「初期1,000万円超」と聞くと大きく感じますが、実車率と積載率の未活用で失っている売上・利益を数字にすると、判断はまるで変わります。
3拠点・車両200台の中規模運送業（年商50億円）を想定します。現状の実車率が45%だとすると、これを48%に引き上げると、追加投資なしで年間1〜2億円レンジの売上増につながります。実車率1ポイントで運送業の稼ぐ力が変わる、というのは配車現場ほど強く実感しています。データ基盤で「なぜ空車回送が発生するか」を拠点・荷主横断で追えるようにすることで、実車率3〜5ポイントの改善はよく見られる水準です。
積載率の改善も見逃せません。積載率が現状60%で、これを65〜70%に引き上げると、同じ運行本数で運べる貨物量が増え、車両稼働と燃料コストの効率が同時に改善します。1台1日あたり2〜3千円の燃料節減が全車両で効くと、200台規模で月100万〜200万円・年間1,200万〜2,400万円の削減効果になります。
これらを合計すると、3拠点・車両200台規模の中規模運送業で実車率・積載率・燃料効率の改善で年間数千万〜1億円レンジの見えないコストが発生している計算になります。1,000万〜3,000万円の初期投資は、この見えないコストに対して1〜2年で回収できるレンジです。
加えて、物流データ基盤には実車率・積載率以外の効果もあります。
これらは営業利益率で2〜4ポイントの改善につながり、初期投資の回収期間をさらに短縮します。配車業務そのものが「勘と経験」から「データを起点にした仮説検証」に変わっていく、というのが本当の意味での効果でもあります。
内製と外注のどちらで進めるかは、データ基盤は内製と外注どっち？判断基準とハイブリッドの進め方で判断軸を整理しています。運送業の場合、テレマティクスとクラウドDWHの両方に精通したエンジニアの採用が難しいため、外部パートナーと組んで立ち上げ、3〜5年で運用まで内製化するロードマップを描く企業がほとんどです。
物流データ基盤は、最初から全拠点・全車両・全荷主を対象にすると、要件が発散して頓挫します。最初の運用開始までを3〜6か月に区切ったスモールスタートで進めるのが、実務では失敗しにくい進め方です。
ここで欲張らないことが最大のコツです。最初は「主力拠点1つの実車率・積載率と荷待ち時間の見える化」1つに絞り、全拠点展開や荷主別採算・ダイナミック配車は次フェーズに回します。
この段階でデータ品質チェック（欠損・重複・タイムスタンプずれ）をパイプラインに組み込むと、後戻りが少なくなります。データパイプラインの考え方そのものはデータパイプラインとは？ETLとの違いと仕組みを図解で解説にまとめています。
このタイミングで、実際の日次点呼と配車会議で新旧併走で使います。現場が数字を見て動き始めるかどうかが最大の勝負どころで、「現場が使わないダッシュボード」を作らないための唯一の予防策が、この段階での週次フィードバックです。
ここまでで最初の運用が回り始めます。その後、複数拠点への横展開、ダイナミック配車の精度改善、荷主別採算・共同配送マッチングと、段階的にスコープを広げていくのが無理のない進め方です。全体スケジュールの目安はデータ基盤構築の期間はどのくらい？規模別・工程別スケジュールの目安でも工程別に解説しています。
物流・運送のデータ基盤について、要点を整理します。
物流データ基盤で本当に効いてくるのは、実車率が上がることそのものよりも、拠点長・配車担当・運行管理・情シスが同じ数字を同時に見て、空車回送や荷待ちの真因を、翌月ではなくその日のうちに議論できる状態を作れることではないでしょうか。日単位で改善のPDCAが回れば、営業利益率の改善はすぐに現れます。2024年問題以降の「1台1人あたりの生産性」で勝負する局面では、この差が3年後の会社の大きさを決めます。
まずは自社の拠点が実車率・積載率の集計にどれくらいの時間を使っていて、空車回送や荷待ちの真因分析にどれくらいの時間差が発生しているかを棚卸ししてみるところから、検討を始めてみてください。データ活用の全社設計や進め方の相談は、Evastのデータ基盤構築支援にお気軽にご相談ください。
データ基盤OT/ITが分断され、稼働率も不良真因もライン跨ぎで追えない——それが製造業データ活用の壁です。IoT SaaS/PoC/本部基盤の3アプローチと費用相場、稼働率5〜10ポイント改善・突発停止50〜70%削減の投資回収、3〜6か月で本番に乗せるスモールスタート手順を、工場長・情シス向けに整理しました。
データ基盤SUUMO・HOME'S・REINS・自社CRMに物件と顧客データが分散して、反響から成約までの実質歩留まりが見えない。不動産業に固有のデータ分断を、費用相場と3つの実現アプローチで整理しました。反響ロス3〜5割改善の投資回収シナリオと、3〜6か月で本番運用に乗せるスモールスタートを、賃貸・売買・管理の3業態向けに具体化しています。
データ基盤SaaS企業のデータ活用は「プロダクトのイベントログはAmplitude、課金はStripe、顧客管理はSalesforce、CSはIntercom」と、ユーザーの行動・お金・接点が別ツールに閉じ、チャーンとLTVを同じユーザーIDでつなげない構造で止まりがちです。この記事では、プロダクト×課金×CRM×CSの4層分断が起きる理由、Amplitude/Mixpanel止まりの限界サイン、プロダクトアナリティクスSaaS／GA4+BigQuery／モダンデータスタックの3アプローチと費用相場、チャーン0.5pt改善とLTV可視化による投資回収、3〜6か月のスモールスタート手順を、SaaS事業部長・データ責任者・PMのマネージャー向けに整理します。
