物流システム開発の事例｜配車・在庫・倉庫管理

01はじめに｜この記事でわかること

要点：物流システム開発を、業界が置かれている状況・4つの領域・領域ごとの事例・規模と期間の目安・法規制の順に整理します。費用の考え方はシステム開発の費用相場もあわせてご覧ください。

「配車表はいまもホワイトボードです」。物流のシステム相談で、この一言から始まる会社は多いです。ベテランの頭の中の段取りが、毎朝きれいに現場を回している。ただ、その人が休んだ日に何が起きるか。この不安を抱えたまま、法改正と人手不足が同時に来ているのが、いまの物流業界です。

この記事は、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、業務システム開発の立場からまとめました。国の統計と法令をもとに、どこから着手すると効果が出やすいかを見ていきます。デジタル化全般は小規模から始めるDXの記事でも扱っています。

まずは法改正の全体像を、国土交通省の説明会動画で押さえましょう。

022030年度には、輸送力が3割足りなくなります

要点：国の検討会は、対策をしなければ2030年度に輸送能力が34.1%不足すると試算しました。営業用トラックの輸送トン数で9.4億トン分です。積載効率と時間の使い方を上げる仕組みが要ります。

背景を数字で押さえておきます。国土交通省・経済産業省・農林水産省の3省が設置した検討会は、持続可能な物流の実現に向けた検討会 最終取りまとめで、対応行動がない場合に2030年度の輸送能力が34.1%（9.4億トン相当）不足する可能性を示しました。これを受けて動き出したのが物流効率化法です。国土交通省の理解促進ポータルに、法律が掲げる目標が数字で書かれています。

注目したいのは、目標がすべて「測れる数字」である点です。積載効率も荷待ち時間も、記録がなければ報告できません。法改正は「数えて残す仕組みを持ってください」という要請でもあります。

03物流システムは、4つの領域に分かれます

要点：物流システムは「配車・運行」「倉庫管理（WMS）」「在庫管理」「受発注・データ連携」の4領域に整理できます。一度に全部は作れません。Webシステム開発では、この順で優先度を決めていきます。

「物流システムを入れたい」というご相談は、そのままでは要件になりません。物流が指す範囲は広すぎます。まず、次の4つのどれを指すのかを分けてください。

• 配車・運行管理（TMS）。どの車がどの荷物をどの順で運ぶかを決め、進捗を追う領域です。属人化が最も進みやすい場所です。
• 倉庫管理（WMS）。入荷から出荷までの庫内作業を管理します。ロケーション管理、ピッキング指示、検品が中心。
• 在庫管理。どこに何がいくつあるかを把握します。拠点が複数になると、WMSとは別の課題になります。
• 受発注・データ連携（EDI）。荷主や協力会社とのやりとりです。FAX・電話・メールが残るのは、たいていこの領域です。

4つは独立していません。受発注のデータが在庫を動かし、在庫が出荷指示になり、出荷指示が配車につながります。1か所だけ自動化しても効果は薄まります。

順番の決め方はシンプルです。いま一番、人の時間を奪っている作業から手をつける。Excelの転記が中心なら、Excel業務をシステム化すべきサインの記事の基準が使えます。

041運行10時間13分のうち、2時間は荷待ちと荷役です

要点：国土交通省の2025年度調査では、1運行あたりの平均拘束時間は10時間13分、うち荷待ち・荷役等が2時間2分でした。前年度から1時間33分減り、その大半が荷待ち・荷役の削減分です。

時間がどこに消えているのか。国土交通省が2026年7月に公表した1運行当たりの平均拘束時間に関する調査結果に、その答えがあります。

運転時間は変わっていないのに拘束時間が1時間33分縮んだ。減ったのは、走っていない時間でした。

改善の余地は「走り方」ではなく「待ち方」にあります。到着時刻がバラつく、バース（荷降ろし場）の空きがわからない、検品に人が足りない。どれもシステムで先回りできます。

荷待ち時間と荷役等時間の数え方には決まりがあります。国土交通省の算定方法を先に読むと、何を記録させるべきかが決まります。

05配車システムの事例｜段取りを頭の中から出す

要点：配車システム開発でまず取り組むのは、自動割り当てではなく「制約条件の見える化」です。車種・免許・時間指定・積載制限といった判断材料を画面に出すだけで、担当が変わっても回ります。

配車の相談で最初に出る希望は、たいてい「ボタンひとつで最適な配車を組みたい」です。ただ、そこから作ると失敗します。何をもって最適と判断しているかを、誰も説明できないからです。

関東で中型トラックを20台ほど運用する運送会社の例です。配車はベテラン2名がホワイトボードで組んでいました。着手したのは自動配車ではなく、次の3つです。

1. 制約条件のデータ化。車両ごとの最大積載量、対応できる荷姿、ドライバーの免許、納品先の時間指定を1つの台帳にまとめました。
2. 当日進捗の共有。ドライバーがスマホから「到着」「荷降ろし開始」「完了」を押すだけの画面を用意し、事務所で一覧できるようにしました。
3. 実績の自動蓄積。押されたボタンの時刻が、そのまま荷待ち・荷役の記録として残る設計にしました。

配車を組む作業自体は、いまも人が担当しています。それでも当日の問い合わせ電話は減り、荷主との時間交渉に実データを出せるようになりました。自動化より先に、記録が効きました。割り当ての考え方は予約システム導入の比較記事も参考になります。

06倉庫管理システム（WMS）の事例｜棚と帳簿を合わせる

要点：WMS開発の効果が最も出やすいのは、ロケーション管理とハンディ端末による検品です。棚の位置を番地で管理し、出荷前にバーコードで照合するだけで、誤出荷と探す時間の両方が減ります。

WMS（倉庫管理システム）は、入荷から出荷までの庫内の流れを管理する仕組みです。

製造業の自社倉庫では、こんな状況が典型です。ベテランは「あの棚の奥」で通じるけれど、新人は30分探す。出荷ミスが月に数件あり、そのたびに謝罪と再配送のコストがかかる。棚卸は日曜出勤で丸1日。入れるべき機能は、実はそれほど多くありません。

• ロケーション管理。棚に番地を振り、どの商品がどこにあるかをシステムが持ちます。探す時間がなくなります。
• ハンディ端末での入出庫。バーコードを読むだけで在庫が動きます。転記が消え、入力ミスも消えます。
• 出荷前の照合。指示された商品と実際に取った商品を機械が照合します。誤出荷の多くはここで止まります。
• ロット・賞味期限管理。食品や医薬品では必須で、先入れ先出しをシステムが指示します。

事例の見せ方は製造業のホームページ制作にまとめました。

07在庫管理システムの事例｜拠点ごとの数字を1つにする

要点：拠点が2か所を超えると、在庫管理は倉庫管理とは別の課題になります。拠点間の移動と引当ルールを決め、全社で1つの在庫数を見る状態をつくることが出発点です。

倉庫が1か所なら、在庫管理はWMSの一機能で足ります。問題は拠点が増えたときです。各拠点がExcelで管理していると、「本社の数字」と「現場の数字」が必ずずれます。原因は次の3つです。

• 更新タイミングの違い。A拠点は当日入力、B拠点は翌朝まとめて。この差だけで数字が合いません。
• 引当ルールの不在。受注時にどの拠点の在庫を先に押さえるかが決まっておらず、二重引当が起きます。
• 拠点間移動の記録漏れ。「とりあえず送った」が記録されず、送り元にも送り先にも在庫がない状態になります。

機能を並べる前に、この3つのルールを社内で決めてください。決まらないまま作ると仕様が何度も変わり、費用も期間も膨らみます。進め方は要件定義の記事で扱っています。

08受発注・データ連携の事例｜FAXと電話を減らす

要点：荷主ごとに帳票の形式が違うため、受発注は最も手作業が残る領域です。Web受注画面とCSV取込を組み合わせ、取引先の対応度合いに応じて段階的に移行するのが現実的です。

「システム化したいのはどこですか」と聞くと、現場から最も多く挙がるのが受発注です。FAXで届いた注文を目で読み、基幹システムに手で打ち直す。毎朝1〜2時間を占めている会社は珍しくありません。ただ、一気にEDIへ切り替えるのは難しい。取引先にも都合があります。現実的なのは段階的な移行です。

1. Web受注画面を用意する。対応できる取引先から、専用画面で発注してもらいます。入った時点でデータです。
2. CSV・Excel取込に対応する。自社システムを持つ取引先には、決まった形式で送ってもらいます。
3. FAX分だけを手入力に残す。残った件数が見えれば、次の交渉材料になります。
4. 基幹システムと自動連携する。受注データが在庫の引当と出荷指示につながる状態を、最後に整えます。

掛け率や承認フローを含む設計は、BtoB向けECサイト構築の記事が参考になります。

09領域別に見た、開発規模と期間の目安

要点：物流システム開発の規模は、対象領域と拠点数でほぼ決まります。単一拠点の小さな範囲なら数か月、複数拠点の基幹連携まで含めると年単位です。範囲を切ることが、費用を抑える最短路になります。

以下は公開情報をもとにZenWeb Japanが整理したモデルケースで、特定の会社の価格ではありません。実際の見積りは要件で変わります。

どの領域も「最小構成なら数か月」で収まります。年単位に膨らむのは、右端の列に手を出したときです。最初のリリースで右端を狙わない。それだけで、止まる確率はかなり下がります。

見積書の読み方はシステム開発の見積もりの記事に、体制コストを抑える選択肢はオフショア開発の基本にまとめています。

102026年4月から、報告が義務になる会社があります

要点：物流効率化法では、2025年度からすべての荷主・物流事業者に努力義務が課され、2026年度からは一定規模以上の特定事業者に中長期計画の作成・CLOの選任・定期報告が義務づけられます。

投資時期を判断するうえで、法令のスケジュールは外せません。国土交通省のポータルサイトの内容を時系列で整理します。

指定基準に届かない中小事業者にも影響は及びます。取引先の大手荷主が特定事業者になれば、荷待ち時間や積載効率のデータ提出を求められるからです。報告できる状態かどうかが、取引条件の一部になっていきます。制度対応を含む要件の考え方は医療・介護のシステム開発の記事もご覧ください。

11パッケージ・SaaS・スクラッチの選び分け

要点：標準的な業務ならSaaS、業界特有の運用が多いならパッケージ、他社にない仕組みが競争力になっているならスクラッチ開発が向きます。判断の軸は「その業務が自社の強みかどうか」です。

「うちは特殊だから既製品では無理です」。物流の現場でよく聞く言葉です。半分は当たっていて、半分は思い込み。切り分けの基準は、その業務が競争力の源泉かどうかです。

• SaaSが向くケース。入出庫や在庫照会など、どの会社でもやり方が似ている業務。月額で始められ、法改正の対応もベンダー側が行います。
• 業界特化パッケージが向くケース。3PLや特定の荷姿など、業界固有の運用が多い場合。ゼロから作るより早く、標準機能でかなり埋まります。
• スクラッチ開発が向くケース。その運用こそが受注理由になっている場合。既製品に業務を合わせると、強みそのものを失います。

現実には3つを組み合わせる会社が増えています。倉庫はSaaS、配車は自社開発、その間をデータ連携でつなぐ。1つにまとめる必要はありません。内製か外注かは外注と内製を比べた記事の基準が使えます。

12物流システム開発でつまずく4つのパターン

要点：うまくいかない案件には共通点があります。範囲を広げすぎる、現場が要件検討に入っていない、例外処理を後回しにする、公開後の運用担当を決めていない。この4つです。

失敗の原因は、技術より進め方にあることがほとんどです。

• 最初から全領域を対象にする。配車も倉庫も在庫も、と広げると要件定義だけで半年が過ぎます。1領域に絞るほうが、社内の納得も早いです。
• 現場が要件検討に入っていない。本部だけで仕様を決めると、実際の作業と噛み合わない画面ができます。使われないシステムは、ないのと同じです。
• 例外処理を後回しにする。物流の現場は例外だらけです。急な追加、返品、破損、代替品。標準フローだけでは、公開後にExcelが復活します。
• 公開後の担当を決めていない。マスタ更新、取引先の登録、不具合の一次受け。誰がやるか決めずに公開すると、数か月で情報が古くなります。

4つとも依頼前の準備で防げます。書き方はRFPの書き方の記事にまとめました。

13依頼する前に、社内で決めておく5つのこと

要点：対象領域、最初のリリース範囲、既存システムとの連携先、社内の決裁者、公開後の運用担当。この5つが決まっていれば、見積りの精度が上がり、比較もしやすくなります。

相談前に決めておくと話が早い項目です。すべて埋まらなくても構いません。埋まらない項目こそ、最初の打ち合わせで詰める論点です。

1. 対象領域を1つ選ぶ。配車・倉庫・在庫・受発注のどれから始めるか。一番時間を取られている作業が基準です。
2. 最初のリリース範囲を決める。「半年後にこれだけ動けば成功」と言える線を引きます。あとから足せる設計なら、削っても損はありません。
3. 連携先を洗い出す。会計、販売管理、デジタコ、荷主のシステム。連携の有無が費用を大きく左右します。
4. 社内の決裁者を決める。仕様の判断が滞るとスケジュールが崩れます。誰が最終判断するかを最初に決めてください。
5. 公開後の運用担当を決める。マスタ更新と問い合わせ一次受けの担当者を、開発中から関わらせます。

人手不足を採用側から解決したいなら、採用サイト制作の記事もご覧ください。省力化と採用は、どちらか一方ではありません。

14まとめ｜まず1日分の作業を書き出す

要点：物流システム開発は、4領域のうち1つに絞って始めるのが定石です。最初の一歩は、現場の1日の作業を時間つきで書き出すこと。どこに時間が消えているかが見えれば、優先順位は自然に決まります。

ここまで、輸送力不足という背景から4つの領域、事例、規模の目安、法令のスケジュールまで見てきました。共通するのは、範囲を絞る大切さです。

何から始めるか迷っているなら、現場の1日を書き出してみてください。何時に何をして、どれくらいかかっているか。それだけで、システム化すべき作業は見えてきます。

ZenWeb JapanのWebシステム開発は、その書き出しをご一緒するところから対応しています。ベトナムのオフショア拠点と組み合わせ、日本品質のまま開発コストを抑える体制も選べます。

15よくある質問

要点：物流システム開発について、ご相談でよくいただく質問をまとめました。費用の考え方はシステム開発の費用相場もご覧ください。

1. 物流システム開発の費用はどれくらいかかりますか

対象領域と拠点数、外部連携の有無で大きく変わります。単一拠点の最小構成と、複数拠点の基幹連携込みでは規模が一桁違うこともあります。ZenWeb Japanは見積り制のため、要件をうかがったうえで金額をご提示しています。

2. 配車と倉庫、どちらから始めるべきですか

いま一番、人の時間を奪っている作業から始めてください。ベテラン1名に配車が集中しているなら配車から、探す時間や誤出荷が多いなら倉庫からが定石です。迷う場合は1日の作業を時間つきで書き出すとはっきりします。

3. 既存の基幹システムと連携できますか

多くの場合は可能です。API連携、ファイル連携、データベースの直接参照など、相手側の仕様に応じて方式を選びます。連携の有無は費用と期間を大きく左右するため、最初の打ち合わせで対象システムを洗い出しておくと見積りの精度が上がります。

4. 中小規模の運送会社でも導入する意味はありますか

あります。規模が小さいほど特定の担当者に業務が集中しやすく、記録が残る仕組みの効果は大きく出ます。荷主からデータ提出を求められる場面も増えているため、取引を守る意味でも有効です。