公開2026.08.26更新2026.10.11 業務システム

バース予約管理システムの比較｜7つの選定軸と自社倉庫への適合判断

バース予約管理システムの比較を始めると、製品名を並べたランキングや機能一覧にはすぐ行き当たります。ところが自社の物流センターに当てはめた途端、「大型が1日3便だけ集中する」「入荷と出荷で同じバースを兼用している」といった条件が引っかかり、一覧表では決められなくなる。難しさは製品の優劣ではなく、荷捌き運用のどこを機械に任せるかが決まっていない点にあります。

この記事では、ランキングではなく自社の倉庫要件と突き合わせるための比較軸を7つに整理しました。あわせて、2025年4月施行の判断基準と2026年4月からの報告義務が、選定条件をどう変えたのかを公表資料で確認しています。全体像は物流DXとは？2024年問題と改正物流効率化法を踏まえた課題と進め方で扱っているため、ここは荷捌き場の受付枠に絞ります。

まとめ｜バース予約管理システムは受付方式と記録の粒度で選ぶ

この仕組みは「予約枠の受付」「入退場の記録」「ドライバーへの通知」の3層。どの層まで自社で回すかを先に決めると候補が半分に絞れます。
製品タイプは、予約受付に特化した専用型・物流プラットフォーム型・WMS付帯モジュール型の3つ。既にWMSがある倉庫は付帯型から確認すると早い。
比較軸は、枠の作り方／ドライバー側の使いやすさ／入退場の実測／当日変更への追随／他システム連携／権限とマスタ／記録の粒度、の7つ。
費用は課金の単位で伸び方が変わります。拠点あたりの固定なら拠点数、端末数やアカウント数に連動するなら取引運送会社の広がりが総額を決めます。
2026年4月からの定期報告では荷待ち時間等の状況が問われるため、法令の定義に沿った起点で実測値を残せるかが実質的な選定条件になります。
標準機能のままで決着するのは、拠点が少なく・バース用途が固定で・取引運送会社の入れ替わりが緩やかで・記録の出力先が報告用だけ、という4条件がそろう場合。

バース予約管理システムが扱う3つの層と、隣接システムとの境界線

製品を横並びにする前に、この仕組みが担う機能を層に分けると、比較表の項目がどこに効くのかを判断しやすくなります。実務では3層が1つのサービスにまとまっているため、どこまでが運用改善で、どこからがシステムの仕事なのかが曖昧になりがち。

受付枠・入退場・ドライバー通知という3つの層が担う役割の違い

1層目は受付枠の設計と予約の受付です。バースごと・時間帯ごとに何台受け入れるかを枠として定義し、運送会社側が空き枠を取る。ここが混雑の平準化そのものを担います。2層目は入退場の記録で、受付端末やQRコード、ナンバー認識カメラで到着と退場を打刻する部分。3層目のドライバーへの通知は、順番が来たことをアプリやSMSで呼び出し、構内の滞留を防ぐ役割を持ちます。

効果がいちばん見えやすいのは2層目です。予約枠だけを入れても、実際の到着時刻が取れなければ枠設計が正しかったのかを検証できません。逆に、打刻だけを先に入れて1か月ほど実測し、混雑の山を見てから枠を設計する進め方もある。導入初期の混乱を避けたい現場では、この順番が現実的でしょう。

WMSやTMSと重複しやすい機能を、どこで線引きすればよいか

バース予約は入荷・出荷の直前直後に位置するため、隣のシステムと機能が重なります。庫内の在庫やロケーション、入荷検品の指示はWMS（倉庫管理システム）の領分で、バース予約側は「何時にどの車が来るか」までを持てば足りる。車両の運行計画や配送ルートは配送管理システム（TMS）の側にあり、バース予約は荷受け側の枠を提示する立場になります。

線引きの目安は、データの持ち主が誰かで決めること。入荷予定明細は発注側のシステムが原本を持ち、バース予約はその予定に紐づく到着時刻だけを扱います。この整理で、予定を手入力し直す二重管理を避けられる。受け渡し全体は物流のデータ連携｜社内WMS・TMSと企業間EDIの二層設計で扱っています。

判断基準の施行と報告義務が、システムの選定条件をどう変えたか

比較記事の多くは待機時間削減の効果を軸にしていますが、2025年以降は制度側の要求が加わりました。制度を先に押さえると、機能表のどの項目が「あると便利」で、どれが「無いと後で困る」なのかを分けられます。

判断基準の中でトラック予約受付システムはどう位置づけられたか

経済産業省が2025年6月6日に公表した改正物流効率化法の説明資料によると、荷主・物流事業者等の判断基準は2025年4月1日に施行され、荷待ち時間の短縮の項に「トラックが一時に集中して到着することがないよう、トラック予約受付システムの導入や混雑時間を回避した日時指定等により、貨物の出荷・納品日時を分散させること」が挙げられています。同じ項には、導入で終わらせず現場の実態を踏まえて実際の短縮につながる使い方をするよう補足も添えられました。

荷役等時間の短縮の項では「バース等の荷捌き場を貨物の量に応じて適正に確保し、作業環境を整えること」も求められています。制度は導入そのものを目的とは見ておらず、荷捌き場の容量と受付枠の設計を一体で見る立場。同資料では令和10年度までの目標として、ドライバー1人当たり年間125時間の拘束時間の短縮と、1回の受渡しごとの荷待ち時間等を1時間以内とする水準が示されました。

特定事業者の指定基準と、定期報告で問われる荷待ち時間の記録範囲

一定規模以上の事業者への措置は、国土交通省の資料では令和8年4月1日施行と記載されています。指定基準値は、荷主および連鎖化事業者が取扱貨物9万トン以上、貨物自動車運送事業者等が保有車両150台以上、倉庫業者が保管量70万トン以上で、対象は上位790社程度の見込み。該当すれば中長期計画の作成、毎年度の実施状況の報告、物流統括管理者（CLO）の選任が課されます。

選定に直結するのは定期報告の中身です。記載内容は判断基準の遵守状況をチェックリスト形式で答える部分、関連する取組の状況を自由記述で書く部分、そして荷主等については荷待ち時間等の状況とされました。計測にはサンプリング等の手法が許容されます。全便の完全な実測までは求められないが、根拠として示せる記録は要るという水準感でしょう。自社が指定基準に届かなくても、取引先の特定荷主から提出を求められる可能性は残る。

製品タイプを3つに分ければ、比較すべき候補の範囲が先に決まる

市場にある製品は成り立ちで3つに分かれます。どれを見るかを先に決めると、10製品以上を並べる必要がなくなります。

予約受付だけに特化した専用型のサービスが向いている現場の条件

入荷・出荷の受付枠と入退場の打刻に機能を絞ったタイプです。ドライバー側のアプリや受付端末の使い勝手が磨かれており、取引運送会社が多い倉庫でも展開しやすいのが持ち味。国内で先行する製品には株式会社Hacobuの「MOVO Berth」があり、公式の料金ページでは初期費用が初回導入企業かつ初回拠点なら0円、月額は「月額3万円から」と明記されています（2026年8月時点）。

専用型が向くのは、まず待機の解消だけを単独で進めたい現場。既存システムに手を入れずに始められる代わり、入荷予定や実績を渡す部分は連携の設計が別途必要になります。

物流プラットフォーム型が持つ、車両の動態管理との連続性の利点

バース予約に加えて、車両の動態管理や配送案件の管理まで同じ基盤で提供するタイプです。到着予測を使って枠の割り当てを調整したり、遅延の見込みを受付側へ先に伝えたりできる点が専用型との差。輸送側も同時に見直す計画があるなら、配車管理システムの検討と並行して評価すると機能の重複を避けられます。

反面、荷受け側だけを改善したい倉庫には範囲が広すぎることもあります。使わないモジュールの分まで負担していないか、契約の単位を確認しておきたいところ。

WMSやTMSの付帯モジュール型で先に確認しておきたい制限事項

既存のWMSやTMSがオプションとしてバース予約を持つ場合です。入荷予定と同じマスタを共有できるため二重入力が起きにくく、追加費用も抑えやすい。ただし社外のドライバーが使う画面の作り込みは専用型に見劣りすることがあり、取引運送会社が多いほど定着の壁になります。提案を求めるときは、ドライバー側の画面を実際に触らせてもらうのが確実。運送会社側の全体像は運送業のシステムとは？配車・運行・請求の一元管理と選び方を参照してください。

比較すべき7つの軸を、導入後に現場が詰まりやすい順で確認する

ここからが実際の比較です。機能表の項目順ではなく、導入後に現場が詰まりやすい順に並べました。各軸で「自社はどちらか」を1行ずつ埋めれば、そのまま要件の下書きになります。

軸	確認すること	詰まりやすい条件
1 予約枠の作り方	枠の単位と重み付け	大型と小型が混在
2 ドライバー体験	登録不要で使えるか	スポット委託が多い
3 入退場の記録	実測の打刻手段	構内が広く死角あり
4 当日変更	遅延時の枠の繰り上げ	遅延が日常的に発生
5 他システム連携	連携方式と頻度	入荷予定が別基幹
6 権限とマスタ	拠点別の管理範囲	複数拠点で横展開
7 記録の粒度	出力形式と保持期間	報告と分析で併用

軸1と軸2｜予約枠の設計と、ドライバー側の入口をどこまで広げるか

軸1の予約枠は、バース単位で切るのか作業員のチーム単位で切るのかで作りが変わります。大型車と小型車で荷役時間が倍以上違う倉庫では、1枠15分の等分割は破綻しやすい。車格や荷姿に応じて枠の長さを変えられるか、1枠に複数台を入れられるかを確認してください。パレットとバラ積みが混在するなら、荷姿の申告で枠長を自動調整する仕組みが要ります。

軸2は社外の人が毎日触る部分です。アプリ導入と会員登録を必須にすると、スポットで入る運送会社ほど脱落します。URLを開くだけで予約できる方式と、電話受付を管理者が代理入力する経路。この2つの逃げ道があるかが定着率を左右し、1アカウントで複数の荷主拠点を横断できるかも効いてきます。

軸3と軸4｜到着時刻の実測手段と、当日の変更への追随のしかた

軸3の入退場記録は、手段ごとに取れる精度が異なります。受付端末での手動打刻は導入が軽い一方、ドライバーが受付に来た時刻しか残りません。門前でのナンバー認識カメラや位置情報を使う方式なら、敷地に入った時刻を機械的に押さえられる。報告用の記録をどこまで求められるかで、必要な精度が決まります。

軸4は運用が続くかどうかの分かれ目になります。渋滞で1時間遅れた車を後ろの枠へ自動で回すのか、管理者が手で差し替えるのか。空いた枠を待機中の他社へ開放するなら、繰り上げのルールを設定として持てる製品を選びます。当日の枠変更を誰が承認するかまで決めておかないと、結局は電話へ戻ってしまう。

軸5と軸6｜連携の方式と、拠点をまたぐときの権限とマスタの設計

軸5の連携は、入荷予定を毎日どう渡すかが中心です。CSVを日次で取り込む方式は導入が早い代わり、当日の追加や取消が反映されません。APIで随時同期できるか、Webhookで実績を戻せるかを確認します。倉庫側の実績をWMSへ返す方向も忘れがちで、入荷実績を二度打ちする運用が残ると、削減した待機時間が事務作業に化けてしまう。

軸6は複数拠点への横展開で効きます。センター長は自拠点の枠だけを編集でき、本社は全拠点の実績を横断で見られる、という分け方ができるか。マスタを拠点ごとに独立させると本社の集計が崩れ、共通化すると現場の自由度が下がるため、運営体制に合わせて選ぶ部分になります。

軸7｜記録できる指標の粒度と、外部へ取り出せる形式があるかどうか

軸7は、ダッシュボードが立派かどうかではなく元データを取り出せるかどうかで見ます。到着・受付・接車・荷役開始・荷役終了・退場の時刻が別項目で残るか、CSVやAPIで期間指定して落とせるか、保持期間は何か月か。集計済みの平均値しか出せない製品は、報告の様式が変わったときに対応できません。この軸を最後に置いたのは、運用2年目に効いてくるためです。

費用の構造｜課金の単位によって、3年後の総額の伸び方が変わる

費用は、金額そのものより何に対して課金されるかで総額が変わります。見積書を並べる前に課金の単位を聞き出すと、比較の土俵がそろう。

公開されている料金の実例と、見積り時に確認しておく課金の単位

金額を公開している例として、MOVO Berthの料金ページでは月額3万円からで1拠点あたりの費用と明記されています（2026年8月時点）。多くの製品は詳細を資料請求扱いにしているため、問い合わせ段階では3点を確認してください。課金の単位が拠点かバース数か端末台数か。運送会社やドライバーのアカウント数が費用に含まれるか。連携用のAPI利用が基本料金の範囲かどうか。

拠点課金であれば、5拠点へ広げた時点で単純に5倍になります。端末課金なら、バースが20本ある大型センターほど負担が増える。自社の形と課金単位の相性で、同じ提示額でも3年後の総額は大きく開きます。

3年の総額で比べるときに抜けやすい、運用側で発生する費用の項目

見落とされやすいのは、ソフト以外に発生する費用です。受付端末やタブレットの調達、構内のネットワーク敷設、ナンバー認識カメラの設置工事。さらに取引運送会社への説明会や案内書類の作成といった立ち上げの手間もかかります。導入後も、新しく取引を始めた運送会社への案内は継続的に発生する作業。

これらを含めて3年で比べると、月額が安い製品が必ずしも有利とは限りません。逆に既存のWMSに付帯モジュールがある場合は端末や連携の費用が浮くため、機能面で少し劣っても総額で逆転することがある。庫内システム全体で投資を見直すなら、WMSの機能と導入判断の整理とあわせて検討すると重複を避けられます。

定期報告に出せる数字になるか｜荷待ち時間の記録の起点をそろえる

ここが、比較サイトの機能表には載らないのに後から効いてくる部分です。システムが残す時刻は、そのままでは制度が求める荷待ち時間と一致しません。導入前に起点を合わせないと、報告のたびに手作業で補正する羽目になります。

法令上の荷待ち時間の定義と、到着時刻によって分かれる3つの起点

説明資料に載る法第三十条の定義では、荷待ち時間は運転者が集貨・配達を行うべき場所またはその周辺で、荷主や施設管理者等の都合により貨物の受渡しのために待機した時間とされています。荷役等時間は別に定義され、検品、荷造り・搬出・搬入・保管・仕分・陳列・ラベル貼り、代金の取立てや立替え、荷役への立会いなどが含まれる。切り分けられない場合は、まとめて計測することも可能とされました。

注意すべきは起点の扱いです。同資料では、到着時刻や時間帯の指示等がない場合は到着時刻から起算し、指示等がある場合は3つに分かれると整理されています。指示時刻より早く着いたときは指示時刻から、指示時刻ちょうどに着いたときと遅れて着いたときは到着時刻から。予約システムは早着の実到着を打刻しますが、その時刻をそのまま起点にすると、制度上は数えない早着分まで待機時間へ算入してしまう。

予約時刻と実測時刻を、それぞれ別の項目に残す設計としておく理由

この分岐を吸収するには、予約枠の指示時刻と実際の到着時刻を別項目で保持することが前提になります。どちらか一方しか残らない製品では、早着分を除いた集計を後から作れません。選定時のデモでは、CSV出力の項目名を見せてもらい、予約時刻・受付時刻・接車時刻・荷役完了時刻・出門時刻が独立した列で出るかを確認するのが確実。

計測の負荷については、サンプリング等の手法が許容され、一定時間以内なら報告を省略できるとされています。全便の完全計測をシステムに求める必要はありません。むしろ限られた期間の実測を正確に切り出せることのほうが、実務では効いてくるでしょう。

既製サービスで決着する4つの条件と、個別開発へ寄せる3つの場面

最後に、パッケージのままで運用できるのか、追加開発が要るのかの線引きを置きます。曖昧にしたまま製品を決めると、契約後に「その要件はカスタマイズです」と言われて予算が崩れる。

標準機能のままで運用しても差し支えのない、4つの倉庫側の条件

次の4つがそろう倉庫は、既製サービスの標準機能で決着します。第一に、対象拠点が1〜2拠点で、拠点ごとに運用ルールを変える必要がないこと。第二に、バースの用途が入荷専用・出荷専用のように固定され、時間帯で切り替える運用が無いこと。第三に、取引運送会社の顔ぶれが安定していること。第四に、記録の出力先が報告用と自社の振り返りだけで、他システムへ日次で流し込む必要が無いことです。

この4条件に当てはまるなら、比較は軸1から軸4までで十分に決められます。むしろ機能の多い製品を選ぶと、使わない設定項目が現場の迷いを生む。まずは1拠点で3か月ほど運用し、実測データが溜まってから枠設計を見直す進め方が向いています。

追加開発や個別開発の検討へ切り替えるべき、3つの兆候と見分け方

一方、次の兆候が出ている場合は既製サービスの設定範囲を越えます。1つ目は、予約枠の決まり方が自社固有のルールに依存しているとき。荷主ごとの優先順位、温度帯によるバース指定、共同配送の混載条件が絡むと、汎用の枠設定では表現できません。2つ目は、入荷予定の原本が独自の基幹システムにあり、当日の変更が頻繁に発生するとき。日次のCSV連携では追随できず、双方向のAPI連携が要ります。3つ目は、入退場の設備や庫内の作業指示と一体で動かしたいとき。ゲートの開閉、車番認識、WMSの入荷検品の起票までを連動させる要件は、パッケージの外側に接続層を作る前提になる。

いずれかに当てはまるなら、既製サービスを土台にして不足分を個別開発でつなぐ構成が現実的です。全部を一から作る必要はなく、ドライバー向けの受付は既製品に任せ、自社ルールで枠を決める部分と基幹連携だけを作るという分担がとれます。当社では流通システム開発で、既存の倉庫システムやWMSと外部サービスをつなぐ接続層の設計・構築を承っています。要件の切り分けからご相談ください。

1拠点での試行から横展開まで、導入を進める順番と撤退の見極め

製品が決まったら、いきなり全拠点へ広げず代表の1拠点で試すのが定石です。選ぶべきは、いちばん混雑している拠点ではなく混雑があり、かつ取引運送会社の数が中程度の拠点。難易度が高すぎる現場で始めると、製品の問題と運用の問題を切り分けられなくなります。

試行では、最初の1か月は予約を必須にせず打刻だけを全便に課します。実測から時間帯ごとの到着台数と荷役時間の分布を出し、枠の長さと本数を決める。2か月目から予約受付を開始し、3か月目に運送会社別の遵守率と待機時間の変化を見ます。撤退や製品変更を判断するなら、この3か月目が期限。遅れる便がどの運送会社に偏るかまで見ると、システムと運用のどちらの問題かを切り分けられます。

よくある質問

バース予約管理システムを入れれば待機時間は必ず減りますか？

予約枠を作っただけでは減りません。判断基準でも、導入するだけでなく実際の短縮につながる使い方をするよう補足されています。荷役の処理能力に対して枠を多く出せば構内で待つだけになり、逆に絞りすぎると予約が取れず飛び込みが増える。実測した分布に合わせて枠を調整する運用が前提です。

予約を守らない運送会社が出た場合はどう扱えばよいですか？

ペナルティを先に決めるより、まず遅延の理由を分けて記録することをおすすめします。前の荷主での荷待ちが原因なら自社では解けません。製品側では、遅延理由の選択入力と運送会社別の遵守率の集計ができるかを確認してください。数字が出せると、荷主や元請けとの交渉材料になります。

小規模な倉庫でも導入する意味はありますか？

1日の入荷が10便に満たず、待機がほとんど発生していない倉庫では費用に見合いにくいのが実情です。ただし取引先の荷主が特定事業者に指定されている場合、荷待ち時間の状況を尋ねられる場面が想定されます。まずは入退場の記録だけを残す運用から始め、必要になったときに予約受付を足す進め方が無理のない選択でしょう。