輸配送管理のIoTシステム：配送実績を自動で取る構成と荷待ち記録・配車への接続

輸配送管理のIoTシステムは、車載端末や貨物センサーで「いつ着いたか」「いつ荷役を始めたか」「荷物は何度だったか」を自動で記録し、配送管理システム（TMS）や配車、法令上の業務記録へ渡す仕組みです。この記事では、車両・貨物・拠点の三つの取得点を整理したうえで、センサーの生データを業務の時刻に変換するときにずれが出る箇所と、その補正方法を説明します。2025年4月に業務記録の荷待ち・荷役の記載が全車両へ広がり、特定荷主には施設ごとの荷待ち時間の報告も課されました。導入の要否は、記録を誰に、どの様式で出す必要があるかで決まります。

まとめ：輸配送管理のIoTは時刻の自動記録と後工程への受け渡しで価値が決まる

輸配送管理にIoTを入れる目的は、位置を地図に出すことではありません。到着・荷役開始・荷役終了・出発の時刻と、貨物の温度などの状態を、人の手書きに頼らず残し、その記録をTMS・配車・業務記録・荷主への報告へ同じ値で渡すことにあります。

設計で押さえる点は次の順です。まず、センサーで自動に取れる時刻と、荷主確認や待機理由のように運転者の操作が残る項目を分けること。次に、構内走行や受付待ちのように、自動取得の値が法令上の定義とずれる箇所を補正規則として決めること。最後に、生データとは別に「運行ID・停車地・イベント種別・時刻・取得元」をそろえた業務イベントの表を持ち、各システムはそこから読むようにすることです。

車両台数が少なく、荷主から時刻の提出を求められていない段階では、既製の動態管理サービスと運転者アプリで足ります。複数の荷主へ異なる様式で報告する、既存の基幹システムや配車計画へ実績を戻す、といった連携が二つ以上重なったときに個別開発の検討に入るのが妥当です。

輸配送管理のIoTシステムが扱う範囲｜車両・貨物・拠点の三つの取得点と変換層

車両側の位置と走行状態、貨物側の温度と開閉、拠点側の入退場という取得点

輸配送の実績は、取得する場所で三つに分かれます。車両側は車載端末やデジタルタコグラフが取る位置・速度・エンジンのオンオフで、走行と停車の区別はここから出ます。貨物側は荷室や荷物に付けるセンサーが受け持ち、温度・扉の開閉・衝撃・容器の所在が対象です。拠点側は倉庫や納品先の入退場ゲート、受付端末、バース予約の記録で、到着と荷役開始の時刻はここが正確です。

車両側の仕組みとデジタコとの連携は車両運行管理IoTのテレマティクスとデジタコ連携の解説で扱っています。本記事が扱うのは、三つの取得点の値を突き合わせて輸配送の業務時刻にまとめる部分です。

動態管理やTMS単体との違いは業務イベントへ変換して渡す層を持つかどうか

動態管理システムは車両の現在地と走行履歴を見せる仕組みで、位置の把握と日報作成までが守備範囲です。TMSは配送計画・運賃・配送実績を管理しますが、実績の入力元は運転者の報告や伝票であることが多く、センサーの値を直接は読みません。

輸配送管理のIoTシステムと呼べるのは、この間に「変換層」を持つ構成です。緯度経度の連続値や扉センサーのオンオフを、「A倉庫に到着」「荷役開始」のような意味のある出来事に変換し、TMSや配車へ渡します。車載機の方式ごとの違いは動態管理システムの車載機4方式と選び方にまとめているので、端末選びはそちらを参照してください。変換層が無いまま端末だけを入れると、地図は見えても業務記録は手書きのまま残ります。

輸配送の実績が法令上の記録になった背景｜業務記録の全車両化と荷主の定期報告

2025年4月から全車両が対象になった業務記録の荷待ち30分と荷役1時間の記載

国土交通省は貨物自動車運送事業輸送安全規則を改正し（令和6年10月1日公布、令和7年4月1日施行）、業務記録へ荷待ち時間・荷役作業等を記載する義務の対象を、従来の「車両総重量8トン以上または最大積載量5トン以上」から全車両へ広げました。国土交通省のリーフレット（業務記録の全車両化と記載例）によると、荷主都合で30分以上待機したときの荷待ち時間、契約書に荷役作業等が明記されている場合は合計1時間以上になったときの荷役時間、記録内容を荷主が確認したかどうかが記載の対象で、最低1年間の保存が求められます。

同じ記載例には、デジタコなど別の方法で記録・保存している項目は記載不要という注記があります。端末で取った時刻を業務記録として保存できれば、手書きの記録票を減らせるということです。同資料が引く国の調査では、2024年度のトラック運転者の1運行あたり平均拘束時間は11時間46分で、うち荷待ち時間が1時間28分、荷役時間が1時間34分でした（n=1,259）。

特定荷主の定期報告で施設ごとの平均荷待ち時間が求められる点とIoTの関係

物流効率化法では、2025年度からすべての荷主・物流事業者に荷待ち時間等の短縮の努力義務がかかり、2026年度から取扱貨物重量9万トン以上の荷主などが特定事業者として中長期計画と定期報告を求められます。物流効率化法ポータルの定期報告ページでは、荷待ち時間等の平均を施設ごとに報告する形が示され、計測は取扱重量の大きい施設を選び、四半期ごとに任意の連続5営業日以上で行う方向性が書かれています（2026年10月時点の掲載内容）。

運送会社側から見ると、荷主が自社で時刻を把握できないときは運送会社へ確認が来ることになります。荷主の報告と運送会社の業務記録が同じ時刻を指すように、どちらが時刻の正本を持つかを契約の段階で決めておくと後の突き合わせが楽です。義務の範囲と提出期限の詳細は物流効率化法の特定荷主の義務と記録データの要件で扱っています。

自動で取れる時刻と人の操作が残る時刻の切り分け｜到着・荷役・出発の取得方法

到着・荷役開始・荷役終了・出発の4時刻を何で取るかと自動取得で起きるずれ

荷待ち時間の定義は「到着した時刻から荷役等の開始時刻まで」で、到着後すぐに受付をする場合は受付時刻を到着時刻とする、と物流効率化法ポータルの荷待ち時間・荷役等時間の算定方法に定められています。この定義に対して、各時刻をどの取得点から取ると誤差が小さいかを整理すると次の表になります。

実務では、到着と出発は位置情報、荷役の開始と終了は扉センサーか拠点側の記録、という組み合わせが扱いやすい構成です。拠点側にバース予約システムの受付・呼び出しの記録がある納品先では、その時刻を優先して取り込むと荷主側の記録と食い違いません。

ジオフェンスの半径と構内走行｜事業所全体を1施設とすると荷待ちが過大になる理由

ジオフェンスを広い敷地の外周に1つだけ置くと、門を入ってからバースに着くまでの構内走行がすべて荷待ちに入ります。定期報告ページでも、事業所内に複数の停留施設がある場合は施設ごとに計測するのが原則で、事業所全体を1施設として計測すると構内の走行時間が含まれて過大評価のおそれがある、と注意されています。

対策は、門と各バースに別のジオフェンスを置き、門の進入を「構内到着」、バース付近の停車を「施設到着」として二段で記録することです。半径は敷地の大きさで変わるため、導入直後の2〜4週間は運転者アプリの手入力と並行して取り、差が大きい拠点だけ範囲を調整します。最初から全拠点を同じ半径で一律に設定するのは失敗の典型です。

荷主確認の有無と待機の理由はセンサーで取れず運転者アプリの入力が残る

業務記録には、荷主が記録内容を確認したか、確認が得られなかったかを残す欄があります。待機が荷主都合か運送会社都合か、到着の遅れによる順番待ちか、という区分も時刻からは判別できません。算定方法のページでは、到着の遅れで後ろ倒しになった待機や、天候・交通事情など荷主の責任によらない待機は一定の場合を除いて除外できるとされています。

こうした区分は、運転者アプリで「待機理由」と「荷主確認」をボタン一つで選ぶ形にするのが現実的です。自動取得した時刻を初期値として画面に出し、運転者は理由を選ぶだけにすると、入力の負担は増えません。

貨物側のIoTで管理するもの｜温度・衝撃・輸送容器の所在を実績と結びつける

冷蔵冷凍輸送の温度ロガーは記録間隔と逸脱時の通知先を運行単位で決める

冷蔵・冷凍の輸配送では、荷室の温度を一定間隔で記録し、設定範囲を外れたら通知する仕組みが基本になります。ここで決めるのは、記録間隔、逸脱とみなす温度と継続時間、通知を運転者・配車担当・荷主のどこへ送るかの三点です。扉の開閉と温度の記録を同じ運行IDで持つと、納品時の開扉で一時的に上がった温度と、冷凍機の不調による上昇を見分けられます。

食品の場合、記録の頻度や保存の考え方はHACCPの衛生管理計画と合わせる必要があります。基準値と記録頻度の決め方はHACCPの温度管理と記録頻度の決め方で整理しています。

カゴ車やパレットなど輸送容器の所在管理を返却遅れと紛失の検知に使う場面

カゴ車・パレット・通い箱などの輸送容器は、納品先に置かれたまま戻らないことが多く、所在を追う仕組みが求められる領域です。容器に小型の位置タグを付けると、拠点ごとの滞留日数が分かり、返却を依頼する相手と時期を絞れます。

ただし、容器1台あたりの単価が安い場合、タグの費用と電池交換の手間が回収できないこともあります。全数に付けるより、滞留が多い納品先向けの容器だけに付け、出荷と返却の記録はバーコードの読み取りで補う、という部分適用から始めるほうが費用対効果を見極めやすくなります。

センサーの生データを業務イベントへ変換するデータ設計｜運行ID・停車地・時刻の正本

業務イベント表に持たせる項目と、生データの表と分けて保存する理由

変換層の中心は、業務の出来事を1行ずつ持つイベント表です。生の位置情報やセンサー値は件数が多く、補正規則を変えたときに再計算できるよう、別の表にそのまま残します。業務イベント表には少なくとも次の項目を持たせます。

「取得元」と「確定区分」を持たせておくと、荷主から時刻の根拠を問われたときに、どのセンサーの値を誰が確認したかを示せます。

通信圏外と端末時刻のずれに備えるバッファ送信と時刻の正本の置き場所

山間部や地下の荷さばき場では通信が途切れるため、端末側で記録をためて圏内に戻ってから送る方式が前提になります。このとき、サーバーが受け取った時刻ではなく、端末が記録した時刻を発生時刻として扱うのが原則です。受信時刻を使うと、圏外の間に起きた到着や荷役開始が、すべて通信が戻った時刻に寄ってしまいます。

端末の時計がずれていると、別の取得元の時刻と前後が逆転します。端末の時刻は衛星測位の時刻で合わせ、受付端末など拠点側の機器と差が一定以上ある記録には確認フラグを立てる、という規則を最初に決めておくと、後から集計を作り直す手戻りを防げます。

物流情報標準ガイドラインver.3.00の着荷予定情報とコード標準へ寄せる範囲

国土交通省は2025年2月7日に物流情報標準ガイドラインのver.3.00への改訂を発表しました。ガイドラインは業務プロセス標準（共同運送・共同保管・検品レス・バース予約など）、メッセージレイアウト、共有マスタで構成され、メッセージを送受するときの「時間・場所・物事・主体」には標準のコードを使うよう定めています。運送事業者が荷受人へ到着を知らせる場面では「着荷予定情報」というメッセージが定義されています。

社内のイベント表をすべて標準に合わせる必要はありません。荷主や納品先と到着予定・実績を交換する部分だけ標準のメッセージに変換し、社内の項目は使いやすい形のまま持つ、という分け方が保守しやすい構成です。社内システム間と企業間の二層の考え方は物流のデータ連携の二層設計と標準への寄せ方で詳しく扱っています。

取得した実績をTMS・配車・改善基準告示の判定へ渡すときの接続の順序

配送完了と到着予定時刻をTMSへ返し、荷受人への到着連絡に使う流れ

最初につなぐ先はTMSです。停車地ごとの到着・出発のイベントを運行IDで返すと、TMS側の配送実績が自動で埋まり、運賃計算や待機料の請求根拠に使えます。業務記録の資料でも、運送事業者が荷待ち・荷役の時刻を記録することは、待機時間料や積込料・取卸料を荷主から収受する根拠になると説明されています。

走行中の位置と残りの停車地から到着予定時刻を出し、遅れが一定時間を超えたら荷受人へ知らせる機能も、この段階で載せられます。TMSの機能範囲と選び方は配送管理システム（TMS）の主要機能と選び方を参照してください。

運転・休憩・荷待ちの区分を配車計画と改善基準告示の判定へ同じ時刻で渡す

次につなぐのは配車と労務の側です。荷待ちと荷役の実績が停車地ごとにたまると、配車計画で納品先ごとの所要時間を実績値で見積もれるようになります。配車管理システムの配車計画機能に実績の平均を返すと、計画と実際のずれが縮まります。

拘束時間・休息期間の判定にも同じイベントを使います。荷待ちを休憩として扱えるかどうかは業務上の指示の有無で変わるため、変換層で「荷待ち」と「休憩」を別のイベント種別にしておく必要があります。判定の数え方は改善基準告示の判定要件の解説を参照してください。TMS向けと労務向けで別々に時刻を加工すると、請求の待機時間と勤怠上の拘束時間が合わなくなるので、イベント表を1つにすることが接続設計の前提です。

既製の動態管理とTMSで足りる会社と、輸配送管理を個別に組むべき会社の分かれ目

既製サービスの組み合わせで足りる条件と、IoT投資を見送ってよい場面

次の条件に当てはまる会社は、既製の動態管理サービスと運転者アプリ、既存のTMSの組み合わせで足ります。

• 荷主から荷待ち時間の提出を求められておらず、業務記録を残すことが当面の目的
• 主要な納品先が数か所に限られ、ジオフェンスの調整を手作業で回せる
• 温度管理の対象貨物が無いか、荷主指定の温度ロガーを使う運用になっている
• 配車計画を表計算や既製の配車システムで組んでおり、実績を戻す先が1つ

見送ってよいのは、荷待ちが発生する納品先がほとんど無い場合です。測っても改善の交渉材料にならない段階で端末とセンサーをそろえても、費用だけが残ります。この場合は、まず運転者アプリで到着・出発を記録し、荷待ちが長い納品先を特定することから始めるのが妥当です。配送全体の課題の洗い出しは配送効率化の進め方と打ち手の優先順位が参考になります。

個別開発に寄せる条件｜複数荷主への報告様式と既存基幹との連携が重なる場合

個別開発を検討するのは、次の連携が二つ以上重なったときです。複数の荷主へそれぞれ異なる様式で荷待ち・荷役の実績を出す必要がある場合、自社の基幹システムや請求システムへ待機料を自動で反映したい場合、温度記録と運行記録を同じ運行IDで荷主へ提出する必要がある場合、構内に複数のバースがある大きな拠点を多く回る場合です。既製サービスはそれぞれの機能を持っていても、イベント表を1つにして各所へ同じ値を配る部分は利用者側に残ります。

この変換層とTMS・配車・基幹への接続を、既存の端末やサービスを生かしたまま組む進め方は、一創の物流システム開発で相談を受けています。相談の前に、主要な納品先の数、荷主ごとの報告様式、現在の配車と請求のシステム構成の三つをそろえておくと、どこまでを既製で賄い、どこからを組むかの線引きが早く決まります。

輸配送管理のIoTシステムについてよくある質問｜導入範囲と記録義務の扱い

輸配送管理にIoTを入れる検討で、運送会社と荷主の担当者からよく寄せられる質問をまとめました。

輸配送管理のIoTシステムと動態管理システムは何が違いますか？

動態管理システムは車両の現在地と走行履歴を見せることが主な役割で、位置情報の取得と日報作成までを扱います。輸配送管理のIoTシステムは、車両の位置に加えて荷室の扉や温度、拠点の受付記録などを組み合わせ、到着・荷役開始・荷役終了・出発といった業務の時刻に変換してTMSや配車、業務記録へ渡すところまでを含みます。動態管理はその取得点の一つとして組み込まれる、という関係です。

スマートフォンのアプリだけで荷待ち時間の記録はできますか？

記録は可能です。運転者がアプリで到着・荷役開始・荷役終了・出発をタップし、位置情報を添えて保存すれば、業務記録に必要な時刻はそろいます。ただし押し忘れや後からのまとめ入力が起きやすく、時刻の正確さが運転者の運用次第になる点は弱みです。ジオフェンスによる自動記録を初期値として表示し、運転者は確認と待機理由の選択だけを行う形にすると、入力の手間と記録の正確さを両立しやすくなります。

デジタコの記録があれば業務記録への手書きは不要になりますか？

国土交通省の業務記録の記載例には、デジタコなど他の方法で記録・保存している場合は、その項目の記載は不要と注記されています。ただし、荷主都合かどうかの区分や、荷主が記録内容を確認したかどうかはデジタコの走行データからは判別できません。こうした項目は運転者アプリや記録票で補い、デジタコの記録と合わせて最低1年間保存する運用にします。

輸配送管理のIoT導入はどこから始めればよいですか？

最初は、荷待ちが長い納品先と温度管理が必要な運行を特定し、その範囲だけで到着・出発の自動記録を始めるのが手堅い進め方です。2〜4週間ほど手入力と並行して記録し、ジオフェンスの範囲や扉センサーの判定規則を拠点ごとに合わせます。そのうえでTMSへの実績連携、配車への所要時間の反映、荷主への報告様式への出力と順に広げると、各段階で効果を確かめながら投資を判断できます。

特定事業者に当たらない中小の運送会社でも導入する意味はありますか？

あります。業務記録への荷待ち・荷役の記載は2025年4月から全車両が対象で、会社の規模にかかわらず記録と1年間の保存が必要です。荷主が特定荷主に当たる場合は、荷主から時刻の確認を求められることもあります。待機時間料や積込料を荷主へ請求する根拠にもなるため、まずは運転者アプリでの記録から始め、荷待ちの多い取引先との交渉材料をそろえる用途で検討する価値があります。

関連記事

• 車両運行管理IoTとは？テレマティクス・デジタコ連携の仕組みと導入判断を解説：車両側の取得点とデジタコ連携を詳しく扱います。
• バース予約システムとは：仕組みと荷待ち削減の効果、改善基準告示との関係：拠点側で到着と荷役開始の時刻を残す仕組みです。
• 物流効率化法とは？改正の要点と特定荷主の義務・提出期限、記録データの要件を解説：荷主の報告義務と提出期限の全体像です。
• 配車管理システムとは？配車計画・車両手配の機能と費用・導入判断を解説：実績の所要時間を戻す先になる配車側の機能です。
• IoTとは？仕組み・身近な例・AIとの組み合わせを簡単にわかりやすく解説：IoTの基本的な仕組みから確認したい場合の入口です。