TMS刷新の進め方5ステップ｜パッケージか個社開発かの線引き

TMS刷新とは、古くなった輸配送管理システムを、法改正や運び方の変化に対応し続けられる仕組みに作り直すことです。刷新の必要性を感じていても、どこから着手すべきか、全面入れ替えに踏み切るべきか、判断に迷う企業は少なくありません。全面入れ替えには投資や期間への不安があり、完成時に業務と合わなくなる懸念もあります。

本記事では、株式会社Hacobu（ハコブ）が提供する、物流領域のシステムインテグレーション・AI導入支援サービス「Hacobu Solution Studio」が、パッケージと個社開発の線引きや、段階的に刷新を進める5ステップを解説します。物流を取り巻く4つの前提変化と、メーカー・物流事業者の事例を踏まえながら、自社に合う刷新方法と着手点を考えていきましょう。

自社での刷新に向けて支援サービスも検討したい方は、Hacobu Solution Studioのサービス資料もあわせてご覧ください。

TMS刷新とは？入れ替えではなく「変わり続けられる土台」に作り直すこと

TMS刷新のゴールは、新しいシステムへの置き換えではなく、変化に対応し続けられる状態をつくることです。導入後に業務や制度が変わっても、必要な部分だけを小さく更新できる構造と運用を整えます。

「最新化」と「変化対応力」は違う

最新化とは、導入時点でシステムの機能を新しくすることです。一方、変化対応力とは、導入後も業務や制度の変化に合わせて仕組みを更新できる力を指します。新しいシステムでも、変更のたびに大規模な改修が必要なら、業務とのずれは再び広がります。検討時は、導入直後の機能だけでなく、数年後に法改正や運び方の変化が起きた際、どの単位で変更できるかを確かめましょう。

新しいシステムに替えるだけでなく、業務や制度の変化に合わせて必要な部分を更新できる構造を整えることが重要です。

古いこと自体が問題なのではない

古いシステムでも、必要な改修を続けられる構造なら、年数だけを理由に刷新する必要はありません。問題は、事業環境が変わったのに過去の慣行や仕様だけが残り、担当者がExcelや個別メモで埋め合わせている状態です。例えば、中継輸送など新しい運び方をシステムで表現できず、別管理が増えると、情報の分断や二重入力につながります。システムの年齢ではなく、今の業務を表現できるか、変更の影響範囲を把握できるか、必要な記録を残せるかで刷新の必要性を判断しましょう。

なぜ今TMSの刷新が必要なのか：物流で変わった4つの前提

人手・価格・記録・システム費用を取り巻く前提が変わり、旧来の運用を続ける負担が増えています。一方、クラウドやAIを活用した開発も選択肢になり、刷新の進め方は広がっています。旧来の運用が今の事業環境に合っているか、4つの観点から確かめましょう。

人手：担当者の頑張りで回せる量を超えた

以前は、担当者の経験や残業で吸収していた仕事も、今は時間外労働の上限と人手不足を前提に組み直す必要があります。自動車運転業務には2024年4月から時間外労働の上限規制が適用され、臨時的な特別の事情がある場合でも上限は年960時間です。荷待ちや荷役が長引けば、運行計画を担当者の工夫だけで成立させることは難しくなります。属人的な判断や手作業を記録し、少ない人数でも続けられる運用へ変えることが、TMS刷新の出発点です。

価格：原価を語れる会社が値上げを通せる

以前は、運賃に含まれているものを分けて把握しにくい取引もありました。2024年3月の標準的な運賃の見直しでは、運賃水準が8％引き上げられ、荷役の対価などが新たに加算されました。また、2026年1月施行の取適法では、協議に適切に応じない一方的な代金決定の禁止が、改正ポイントの一つに挙げられています。原価を説明するには、区間別の輸送費、荷待ち・荷役にかかった時間、追加作業をデータで示すことが役立ちます。原価を語ることは、コスト上昇への備えにとどまりません。必要な価格改定を取引先と協議するための根拠にもなります。

記録：データが残る仕組みが取引の前提になった

以前は口頭やFAXで完結していた取引も、今は効率化の取り組みや実運送の体制を、後から確認できる記録に残す必要性が高まっています。物流効率化法では、2025年4月から荷主・物流事業者等に努力義務が課され、2026年4月から一定規模以上の特定事業者に中長期計画や定期報告等が義務付けられています。特定荷主にはCLOの選任も求められます。貨物自動車運送事業法の改正では、実運送体制管理簿の作成や運送契約の内容・対価を記載した書面の交付等も定められました。

CLOが物流に関する経営判断を担う企業では、委託先にも荷待ちや実運送の状況を確認する場面が想定されます。荷待ち時間や実運送の体制を記録し、根拠を示して説明できることは、委託先との協議や選定の判断材料になり得ます。

システム費用：クラウドとAIで作り直すコストが下がった

以前は、システムを一から作ると大規模な開発になりがちでした。今は、標準機能やクラウドの部品を組み合わせ、必要な部分に絞って個社開発する方法があります。

システムインテグレーション・AI導入支援のHacobu Solution Studioは、システム連携や個社開発から、データ統合、AIによる分析・可視化までを支援しています。Hacobuの経験では、条件によって構築コストを従来の1桁程度に抑えられたケースもあります。ただし、これは一般的な開発費の相場や、すべての案件に当てはまる削減率ではありません。開発範囲、データの状態、既存システムとの連携要件を整理してから、個別に見積もる必要があります。個社開発やシステム連携を外部に依頼する際の検討材料として、Hacobu Solution Studioのサービス資料で支援内容をご確認いただけます。

今のシステムに見直しのサインが出ているかは、「いまのシステムを見直すべき4つのサイン」で確認できます。

TMS刷新の3つの選択肢

選択肢は、パッケージ・SaaSへの全面入れ替え、個社開発（スクラッチ）での作り直し、標準機能と個社開発の組み合わせの3つです。自社の独自性、標準機能で満たせる範囲、変更を続ける体制を合わせて比較します。

パッケージ・SaaSへの全面入れ替え

パッケージ・SaaSへの全面入れ替えは、標準機能で業務要件を満たせる企業に向いています。既に用意された機能を利用するため、個別開発を抑え、比較的早く運用を始めやすい点が利点です。一方で、業務の進め方をシステムの標準に合わせる必要があります。自社独自の判断や取引先ごとのルールが競争力の源泉になっている場合、標準化の範囲を決めないと現場に合わない可能性があります。移行できるデータ、既存の基幹システムとの接続、将来の設定変更の範囲を契約前に確かめます。

個社開発（スクラッチ）での作り直し

個社開発は、既存の標準機能では表現しにくい業務や、自社の判断ロジックをシステム化したい企業に向いています。業務に合わせて設計できる一方、最初から全機能を一括で作ると投資が大きく、開発期間も長くなりやすい点に注意が必要です。完成までの間に業務や法制度が変われば、出来上がった仕様が現状とずれることもあります。一括開発では、初期に決める範囲が広いほど、投資や期間が膨らみやすくなります。優先する業務と後から追加する機能を分け、保守・改修を誰が担うかも決めておきます。

標準機能と個社開発を組み合わせる

共通業務を既存機能で賄い、自社の強みにつながる部分だけを作り込みたい企業には、標準機能と個社開発の組み合わせが向いています。輸配送管理を全体の一機能として切り出し、基幹システム、倉庫管理システム（WMS）、請求システムと連携させることで、各システムのデータを横断的に活用できます。最初にすべてを完成させず、可視化や必要な実務機能から始め、連携、自動化、AI分析へ広げられます。本記事では、共通業務は標準機能に任せ、自社の強みとなる部分に個社開発を組み合わせる方法を、TMS刷新の有力な選択肢として提案します。連携部分の責任範囲やデータの管理者を曖昧にしないことが、後から育てるための条件です。

パッケージか個社開発かの線引き

業務が自社の競争力につながるか、標準機能で満たせるかの2軸で判断します。すべてを標準化するか、すべてを独自開発するかの二択ではなく、業務ごとに4つの領域へ分けて考えます。

業務が競争力につながるか、標準機能で満たせるかを基準に、標準化する範囲と個社開発する範囲を見極めます。

競争力につながらない業務は標準機能に任せる

競争力に直結しない一般的な業務は、標準機能で満たせるなら独自ルールを増やさないことが基本です。マスタ管理、基本的な案件管理、進捗管理などは、多くの業務で共通するため、標準機能を活用しやすい領域です。標準機能で満たせる業務に独自ルールを増やさなければ、開発や保守の範囲を抑えやすくなります。標準機能を使う場合も、必須の記録や社内統制を損なわないかを確認し、現場の作業を変える場合は関係者と手順を合わせます。

自社の判断ロジックが強みになる業務は作り込む

顧客や荷物の条件を読み、自社の収益やサービス品質を左右する判断は、競争力の源泉であれば個社開発の候補になります。例えば、運送会社の選定ロジック、顧客ごとの納品制約、採算を踏まえた受注判断、積み付けシミュレーションなどです。業務名だけで独自開発を決めず、どの情報を使い、誰がどの基準で判断し、その結果が何を変えるかを明らかにします。判断の再現性や改善効果を確かめるデータがなければ、まず記録と要件整理から始める方法もあります。個社開発の対象は「現場が長く続けてきた独自ルール」ではなく、事業上の成果につながる判断です。

AIで「作り込んでもよい範囲」が広がった

AIによる開発支援で個社開発のコストが下がれば、従来は費用に見合わず諦めていたルールも、実装を検討できる可能性があります。例えば、配車ロジック、運送会社の選定基準、顧客対応ルールのように、自社の判断が業務成果を左右する領域は個社開発の候補になります。ただし、作りやすくなったことだけを理由に機能を増やすのではなく、判断の価値、データの整備状況、導入後の保守方法を合わせて評価します。AIが要件整理や業務判断の代わりになるわけではありません。現場と管理部門がルールを確認し、試作した機能を実務で検証する段階を設けます。

TMS刷新の進め方5ステップ

全体を一度に作り込まず、業務への影響が大きい情報や機能から着手し、データを蓄積しながら連携・自動化へ段階的に広げます。最初に全社の完成形を実装するのではなく、判断や業務が最も変わる範囲を定めます。

現状の棚卸しから始め、最初に取り組む対象を絞り、標準機能と個社開発を使い分けながら連携・自動化へ広げます。

ステップ1：今の業務とデータを棚卸しする

最初に、現行業務の流れ、判断者、データの所在、システム外の作業を洗い出します。担当部門や物流会社と、次の6点を確認しましょう。

• 輸配送コストの構造を自社で説明できるか
• 荷待ち・荷役時間をデータで把握できているか
• 法令対応に必要な記録を後から確認できるか
• 配車や運送会社の選定基準が属人化していないか
• 拠点ごとのExcelや個別ツールにデータが分散していないか
• 法改正や運び方の変化に、どのシステムをどの程度変更すれば対応できるか

このステップで決めること：現状を把握する対象業務と、確認するデータの範囲です。

ステップ2：「あるかないかで一番変わるもの」を決める

次に、情報や機能の有無によって意思決定や作業への影響が最も大きく変わるものを一つ選びます。刷新の初手は、必要台数を説明するためのデータ、区間別の輸送コスト、荷待ちの実績など、現状の判断を変える情報から考えます。利用者、判断の場面、現在の代替作業を確認し、最初に着手する対象を決めましょう。全体を一度に解決しようとせず、効果を確かめられる範囲に絞ることが重要です。

このステップで決めること：最初に可視化・実装するデータまたは業務機能です。

ステップ3：標準機能と個社開発の線を引く

棚卸しした業務を「競争力につながるか」「標準機能で満たせるか」の2軸に当てはめ、標準で行う業務と個社開発する判断ロジックを分けます。線引きの理由を、業務ごとに担当者と確認します。

このステップで決めること：標準機能を使う範囲、個社開発の対象、追加開発を再評価する条件です。

ステップ4：可視化と最小限の実務機能から始める

最初の開発では、輸送実績、コスト、荷待ち・荷役時間、必要台数などを記録し、現状を説明できる状態を目指します。これは、完成形を一度に実装する前に、可視化や最小限の実務機能から始める段階です。記録項目、更新責任者、見る頻度を決め、計画値と実績値を比べます。データが記録されても、判断や改善に使われなければ、次の投資を決める根拠にはなりません。現場担当者や運送会社と結果を確認し、必要な機能を見直します。

このステップで決めること：記録する項目、担当者、実績を振り返る場と頻度です。

ステップ5：連携し、自動化・AIへ広げる

基幹システム、倉庫管理システム、請求システムと必要なデータを連携し、実績が蓄積した領域から自動化やAI分析へ広げます。例えば、労働時間の上限に触れる可能性がある運行計画を事前に確認する、積載率や区間別コストの改善余地を示す、といった使い方です。AIの分析結果をそのまま確定せず、担当者が条件と判断理由を確認できる運用を設けます。システムを追加するたびに、データの定義、連携の責任者、障害時の業務手順も明確にします。配車受発注・管理サービス「MOVO Vista」（Hacobu（ハコブ）提供）など既存サービスを組み合わせる場合も、既存システムとの役割分担を先に確認します。

このステップで決めること：次に連携・自動化する業務と、結果を人が確認する手順です。

TMS刷新でつまずきやすい3つのこと

つまずきの多くは、最初から作りすぎることから起きます。解決したいことを絞らず、全業務の自動化や拠点別機能を先に積み上げると、完成までの間に要件が変わり、使われない機能が増えるおそれがあります。

最初から全工程の自動化を目指す

「自動配車をしたい」と考えたとき、全工程を自動化する必要があるとは限りません。運行計画の作成から配車までを一括で自動化する前に、労働時間の上限に触れる可能性がある計画を事前に確認できる状態を優先する方法もあります。機能を増やすこと自体を目的にせず、現場のリスクや経営判断に直結する課題を特定し、そこから着手しましょう。

一括で作り込み、完成したときには古くなっている

長期の一括開発では、要件を決めてから稼働するまでに業務や制度が変わることがあります。変更をすべて初期要件に詰め込むと、検討や開発が長引き、完成時点で運用に合わない可能性が高まります。優先度の高いコアを先に実装し、実績を見て次の機能を選ぶ方が、作り直す範囲を抑えられます。将来変更する部分を切り分け、追加の判断時期と責任者も決めておきます。

拠点ごとの違いを残しすぎる、または消しすぎる

拠点固有の制約をすべて残すと、全社で同じデータや手順を使いにくくなります。反対に、業務上必要な違いまで一律に消すと、現場でシステム外の運用が再発します。共通の案件・進捗管理を土台にし、拠点ごとの条件は設定や限定した機能で扱うと、全社での共通化と現場への適合を両立しやすくなります。共通化する範囲と個別に残す条件を、現場の責任者と一緒に決めましょう。

TMS刷新の事例

TMS刷新では、最初に取り組む範囲や、標準化する業務の見極めが重要です。メーカーと物流事業者の事例を通じて、課題に応じた着手点と、標準機能・個社開発の使い分けを見ていきましょう。

メーカー：可視化から始めて物流の主導権を取り戻した例

あるメーカーでは、輸配送管理を運送会社に任せており、物流コストの構造や必要な配車台数を自社で説明しにくい状態でした。全面的に作り直す案も検討しましたが、一括開発では投資が大きく、期間も長くなりやすいため、業務への影響が大きい情報・機能に対象を絞りました。

最初の範囲は、配車台数の算出、区間別コスト、荷待ち実績の可視化です。記録を残すことで、必要台数や計画段階のコストを説明し、改善や投資をデータに基づいて検討できる状態を目指します。データを持つ目的は物流会社と対立することではありません。荷主と物流会社が同じ実績を見ながら、よりよい運び方を一緒に作るための共通材料にします。

物流事業者：全国の配車拠点を1つの土台に集めた例

ある物流事業者では、複数の配車拠点で業務の仕組みが分かれ、既存システムが古くなっているか、業務の一部しか扱えていない状態でした。全国の拠点を同じ土台に集め、共通業務を扱えるようにすることを目指しました。

基本的な案件管理や進捗管理には標準機能を使い、個社開発は運送会社の選定ロジックに絞りました。標準機能を活用しながら、各拠点に残す必要がある条件と、全社で共通化できるコアを分けます。結果として、固有の選定ロジックを生かしつつ、共通の土台で運用する構成を目指しました。

鴻池運輸：受注から請求・支払いまでをつなぎ、案件ごとの採算を可視化

鴻池運輸の国立流通センター営業所と北関東流通センター営業所では、配車と請求・支払いを別々に管理しており、案件ごとの収支を把握できるのは月次の締め作業後でした。紙の配車台帳やExcelなどに情報が分散し、照合や修正にも多くの工数がかかっていました。

そこで、Hacobu Solution Studioとともに、受注から配車、請求・支払いまでのデータを一気通貫でつなぐ輸配送システムを開発しました。重視したのは、すべてを自動化することではなく、現場が培ってきた判断や柔軟性を生かしながら、情報管理や事務作業をデジタル化することです。業務の進め方が異なる2拠点が要件定義から参加し、共通で使える仕組みを整えました。

導入により、案件ごとの収入と原価をタイムリーに把握できるようになり、請求・支払いも同じデータを基に並行して進められるようになりました。2026年9月の取材時点では、配車業務をチーム全体で月160時間以上削減し、月末の締め作業を3日短縮できる見込みです。現場の判断を残しながらデータの分断を解消した点は、TMS刷新で自動化と標準化の範囲を考えるうえで参考になります。

鴻池運輸では、分散していた情報を受注・配車・請求・支払いまでつなぎ、案件ごとの収入と原価をタイムリーに把握できるようにしました。

（出典：鴻池運輸の主要事業を支える輸配送システムを開発、更新日：2026年10月1日）

自社でも、現場の判断を生かしながら分散したデータをつなぎたいとお考えの方は、開発を支援したHacobu Solution Studioのサービス資料をご覧ください。

TMS刷新に関するよくある質問

TMS刷新では、相談先、既存システムとの並行運用、個社開発の費用、期間が気になるところです。いずれも一律に決めるのではなく、最初に作る範囲と既存環境を整理して判断します。

TMSを刷新したいときは、どこに相談すればよいですか？

業務の整理とシステムづくりを一体で進められる相手を選びます。物流の業務や取引条件を理解していること、既存のパッケージや社内システムと組み合わせられること、要件整理から運用まで相談できることを確認します。システムインテグレーション・AI導入支援「Hacobu Solution Studio」は、物流領域の業務に合わせた個社開発やシステム連携を支援します。相談先を比較・検討する際は、サービス紹介ページや、ダウンロードできるサービス資料で支援内容をご確認ください。

古いTMSを使いながら、段階的に入れ替えることはできますか？

できます。可視化など一部の機能から開発し、既存システムと並行して運用しながら範囲を広げる方法があります。最初に、現行と新しい仕組みのどちらが各データを更新するか、二重入力をどう防ぐか、障害時にどちらへ戻すかを決めます。試行する業務と拠点を限定し、運用とデータを確認してから、次の機能や範囲へ進みます。

個社開発（スクラッチ）は費用が高くつきませんか？

すべてを一括で作ると費用が大きくなりやすい一方、標準機能と組み合わせて自社の強みの部分だけを開発すれば、対象範囲を絞れます。個社開発の見積もりでは、初期開発だけでなく、データ移行、既存システムとの連携、テスト、運用・保守も確認します。金額の相場は要件によって変わるため、現状の業務と最初の実装範囲を整理してから比較します。

TMSの刷新にはどのくらいの期間がかかりますか？

期間は刷新の範囲によって大きく変わります。見通しを立てるには、まず実装する範囲を小さく定めることが大切です。機能の実装だけでなく、業務要件の整理、データの整備、既存システムとの連携、利用部門による確認も必要です。期限だけを先に置かず、最初の業務範囲と稼働条件を決め、試行後に次の段階を判断しましょう。対象業務や連携要件が決まっていない段階では、具体的な期間を一律に示せません。

まとめ：作り替えを繰り返すのではなく、育て続けられる土台を作る

TMS刷新の目的は、古いシステムを新しい製品に置き換えることだけではありません。人手、価格、記録、システム費用の前提が変わる中で、変化に合わせて機能を更新できる土台を作ることです。選択肢は全面入れ替え、個社開発、標準機能との組み合わせがあり、業務の競争力と標準機能で満たせる範囲を基準に選びます。

進め方は、現状を棚卸しし、最初に可視化する情報や機能を決め、標準機能と個社開発の役割を分けて着手します。その後、データを連携し、自動化やAI活用へ段階的に広げます。大切なのは、システムを一度作って終わりにせず、業務や制度の変化に合わせて必要な部分を更新できる土台を育てることです。

自社のTMS刷新をどこから始めるか検討している方は、まずHacobu Solution Studioのサービス資料をダウンロードし、支援内容をご確認ください。業務整理からシステムづくりまで具体的に相談したい方は、Hacobu Solution Studioへお問い合わせください。