TMSのリアーキテクチャとは、配車最適化エンジンとGPS/テレマティクスのストリーム処理基盤を軸に、既存TMSの内部構造をモノリスからマイクロサービスへ設計し直す技術的な再設計のことです。
同じモノリスに両者が同居したままだと、片方の改修が全体のリリースを止めてしまいます。
- 分解：配車最適化エンジンとストリーム処理の境界の整理
- 連携：GPS/テレマティクスデータの流れ方
- 判断：導入目的と他のアプローチとの違いを比べて決める
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリアーキテクチャとは何か？位置づけと2つの技術要素
TMSのリアーキテクチャは、すでに稼働している配車計画・運賃計算の仕組みを前提に、その内部構造をどう作り替えるかを考える技術部門の論点です。新規にTMSを立ち上げる話や、既存TMSを丸ごと入れ替える話とは性質が異なります。
近い言葉として「TMSのモダナイゼーション」「TMS刷新」「TMS更改」「TMSのリニューアル」がありますが、扱う軸はそれぞれ異なります。
近い言葉との違いの整理
TMSのモダナイゼーションは、リホストやリファクタリングなど5つの手法を並列に扱う総論です。どの手法を選ぶべきかを整理するのが主眼になります。本記事群は、そのうちリファクタリングとリビルドを深掘りし、「構造の設計」という1テーマに絞っています。
その中身は、モノリスからマイクロサービスへの分解が中心で、ドメイン駆動設計やAPI-first設計などを含みます。TMS刷新は、輸送コストの増加や積載効率の低下、傭車比率の上昇を洗い出して、経営層の稟議承認や2024年問題への対応を進めるPMの視点です。
TMS更改は、保守契約の満了や車載器リースの満了、通信規格の変更といった外部の要因が起点になります。一方でTMSのリニューアルは、ドライバーアプリや荷主ポータルの使い勝手の刷新が中心です。本記事群は、これらと違って画面の裏側の技術構造に特化しています。
配車最適化エンジンとGPS/テレマティクス基盤という2つの技術要素
TMSのリアーキテクチャで実務上の検討対象になりやすい技術要素は、大きく2つです。ひとつは配車最適化エンジンで、配車計画とルート最適化のロジックを独立したマイクロサービスとして切り出します。
もうひとつは、車載GPSやテレマティクス端末から届くデータをリアルタイムに処理するストリーム処理基盤の構築です。この2つは、以降の設計の考え方を読むうえでの軸になります。
モノリスからマイクロサービスへの移行の仕組み
全体の移行は、3つのフェーズで進むのが一般的です。パイロット(PoC・技術検証)は3〜6ヶ月、MVP(プロトタイプの並行稼働)は6〜12ヶ月、本番移行は12〜18ヶ月が目安になります。
ビジネスドメインの再構築を伴う場合は、プラットフォーム全体の移行に通常12〜18ヶ月を見込みます。
DDDとBounded Contextによる境界設計
最初の3〜6ヶ月は、配車最適化ドメインのBounded Contextを設計し、最初のモジュールをAPI・独立サービスとして分離することに集中します。
最初の四半期以内に「独立サービスとしての明確な分離」「自動化されたCI/CDパイプラインの構築」「他システムに悪影響なく独立稼働できること」の3点が確認できれば、正しい方向に進んでいる目安になります。逆に、これらが未達であれば、ドメイン境界の設計やDevOps体制を見直すサインです。
ストラングラーフィグパターンによる段階的な移行
ストラングラーフィグパターンは、6〜18ヶ月かけて、APIゲートウェイでレガシーモノリスの周囲に新サービスを稼働させ、既存システムを少しずつ置き換えていく方法です。
たとえば、カナリアリリースやフィーチャートグルを使い、「まずはA営業所の5台のトラックのみ」といった小規模な範囲から適用します。旧システムと並行稼働(Parallel Runs)させて安定性を確かめながら、適用範囲を広げていきます。
分散型モノリス化という最大の遅延リスク
移行で最大の遅延リスクになるのは、「分散型モノリス」化です。
DDDによる境界定義が甘いままサービスを分割すると、見た目はマイクロサービスでも、サービス同士が密結合になります。その結果、一つの変更に複数サービスの同時リリースが必要になり、リリース調整のコストが大きく膨らみます。
境界設計に時間をかけることが、結果的に開発期間全体の短縮につながります。
配車最適化エンジンの独立マイクロサービス化
配車最適化エンジンをあえて独立サービスにするのは、AI・アルゴリズムのCPU計算処理という特性が、ユーザー管理や請求処理といった一般的な業務ロジックと大きく異なるためです。特に、パフォーマンス特性・リソース要件・トラフィックパターンの面で差が大きく出ます。
コンポーネント単位で独立してスケールさせたい場合は、この分離に合理性があります。
配車計画・ルート最適化ロジックのAPI化
切り出し方の基本は垂直スライスです。DB・API・インフラまでを一気通貫で扱う最小単位を、最初のモジュールとして定義します。たとえば「特定エリアの配車最適化処理」がこれに当たり、そこから配車最適化エンジンをAPIとして独立させていきます。
数日から数週間の使い捨てコードによるアーキテクチャスパイクで、分離時のレスポンスタイムなどの技術的な不確実性を先に解消しておけば、後続の本開発がスムーズに進みます。
データクレンジングへの先行投資と開発期間
ある実例では、プロジェクトを意図的に4ヶ月遅らせて、住所やGPSデータの品質修正(クレンジング・自動ジオコーディング)を行いました。その結果、当初9ヶ月と見込まれていた配車最適化エンジンの開発フェーズが、わずか3ヶ月で完了しています。
フルスクラッチ開発では、プロジェクトリソースの40〜60%をデータ準備・基盤整備に割り当てるのがセオリーとされています。このため、データ品質を後回しにしないことが、結果的に開発全体のスピードを高めます。
GPS/テレマティクスリアルタイムストリーム処理基盤の仕組み
車載GPSやテレマティクス端末、貨物センサーのデータを、すべてクラウドに集めて処理しようとすると、レイテンシと帯域コストが膨大になります。
そこで、エッジコンピューティングを活用し、リアルタイムなルート逸脱検知など即時応答が求められる処理は、エッジ側で完結させます。コストとレイテンシの両方を抑える設計が、基本方針になります。
Push型・Pull型ストリーミング設計の使い分け
Push型(Kafkaなどのイベント駆動)は、現在地の即時反映のように、ミリ秒単位での確定が求められる業務に向いています。ただし、イベントが失われた際の補償トランザクションは、実装の難易度が高くなります。
一方、Pull型(定期バッチ照合)は、配送実績の定期集計や運賃精算データの照合のように、5〜10分程度の遅延を許容できる業務に適しています。シンプルなスケジューラで実装でき、障害時にも自己修復しやすい点が利点です。
どちらを採用するかは、業務ごとの許容遅延をもとに、PoCで検証します。
数千台規模のスケーラビリティのPoC検証
アーキテクチャPoCで中心的に検証すべき論点は2つあります。ひとつは、配車エンジンを分離したときのレスポンスタイムです。もうひとつは、数千台規模のGPSストリーム処理がクラウド上でスケーラブルに捌けるかどうかです。
車両台数やセンサー項目が増えると、メッセージ量も変動します。そのため、順序保証や重複排除、遅延時のリトライの挙動まで含めて検証しておくと、本番移行後のトラブルを減らせます。
導入目的と期待できるメリット
リアーキテクチャの目的は、配車最適化エンジンとストリーム処理基盤をそれぞれ独立してスケールさせ、長期的なTCOを最適化することにあります。開発速度を上げることも狙いに含まれますが、それだけが目的ではありません。
監視・運用コストが構造的に増える点は、投資判断の段階で織り込んでおく必要があります。
監視コストの増加と投資判断
マイクロサービス化すると、モニタリング要件と運用オーバーヘッドは、モノリスと比べて40〜50%増えるとされています。サービスメッシュのインフラ費用も無視できません。
Istio(サイドカー型)は、プロキシ1つあたりメモリ50〜100MB・CPU100〜200mを消費し、500サービス規模では、クラスター全体で軽量メッシュ比25〜50GB以上の追加メモリが必要になります。一方、Cilium(eBPF型)は、プロキシ1つあたりメモリ10〜15MB・CPU20〜50mと軽量で、レイテンシもIstioの3〜5msに対して0.5〜1msと低く抑えられます。
こうしたインフラが投資に見合うのは、「1日リクエスト数100万回超かつ開発者50名以上」の場合とされています。逆に、開発チームが10〜15名未満だと、インフラの維持に時間を取られて、メリットよりコストが上回りやすい点に注意が必要です。
TCO最適化と繁忙期のスケーラビリティ
インフラコストは短期的には増えるものの、長期的には15〜35%削減されるという報告があります。保守費用は30〜50%低下し、TCO全体では20〜45%削減されるとされています。投資回収期間は12〜36ヶ月が標準とされます。
お中元や年末商戦のように、平時の3〜5倍の配送量が発生する企業では、独立サービス化が強みを発揮します。配車計算の処理能力を、自社のタイミングでスケールアウトできるためです。
ただし、反面教師となる事例もあります。マイクロサービスとサーバーレスで構築した監視システムがデータ転送コストの膨張を招き、モジュラーモノリスへ統合し直すことでインフラコストを90%削減したケースです。過剰な分散は、かえって非効率になり得ます。
TMS刷新に関する他のアプローチとの違い
「TMSを刷新したい」と考えたとき、モダナイゼーションや刷新といった言葉が、更改やリニューアルと併用されがちです。ただし、視点も進め方も異なるため、自社の課題がどのアプローチに当たるかを見極めておくと、以降の選定を無駄なく進められます。具体的な進め方や評価軸を知りたい場合は、TMSのリアーキテクチャの選定ポイントもあわせてご覧ください。
TMSのモダナイゼーション・TMS刷新との違い
TMSのモダナイゼーションは、5つの手法を並列に検討する総論です。どの手法を選ぶかという、いわばHOWの整理が主眼になります。
本記事群は、そのうちリファクタリングとリビルドを深掘りし、モノリスからマイクロサービスへの分解という「構造の設計」1テーマに絞っています。
また、TMS刷新は、輸送コストの増加や積載効率の低下、傭車比率の上昇を洗い出して、経営層の稟議承認や2024年問題への対応を進めるPMの視点です。WHYとWHENを整理する話であり、技術部門やアーキテクト向けの本記事群とは、読者層も論点も異なります。
TMS更改・TMSのリニューアルとの違い
TMS更改は、保守契約の満了や車載器リースの満了、通信規格の変更といった外部の要因をきっかけに、入れ替えを検討する取り組みです。本記事群が扱う、アーキテクチャ上の技術的負債(配車ロジックの密結合化、GPS処理基盤の逼迫)を起点とする話とは、出発点が異なります。
一方でTMSのリニューアルは、ドライバーアプリや配車ダッシュボード、荷主ポータルといった顧客接点の使い勝手を刷新することが主眼です。画面の裏側の構造にまでは踏み込みません。
本記事群は逆に、ストリーム処理基盤やマイクロサービス分離といった画面の裏側の構造に特化し、UIそのものには言及しない立場を取ります。
TMSのリアーキテクチャ導入前の確認ポイント
リアーキテクチャを検討するかどうかは、事業規模に加えて、既存TMSの状態や自社の体制を含めて考えます。
既存のTMSでどの技術的負債が表面化しているか、どこまでを自社で担う体制があるかまで含めて整理しておくと、着手後の手戻りを防げます。
小規模なTMSでのリアーキテクチャの効果
規模の目安(1日100万リクエスト以上・エンジニア50名以上)を下回る場合は、マイクロサービス化の運用負担がメリットを上回りやすいのが実情です。
配車ロジックの密結合化やGPS処理基盤の逼迫が明確な技術的負債として表れている場合は、配車最適化エンジンなど特定のコンポーネントだけを先に切り出す部分適用が現実的な選択肢になります。
フルスクラッチ以外での実現の可否
フルスクラッチに限らず、実現できる場合があります。
Bounded Contextごとに投資判断を分けられます。配車最適化エンジンのように競争優位に直結するコア業務ドメインはフルスクラッチで作り込み、認証や通知のようなコモディティ領域はSaaSや既存システムを活用して、APIでカプセル化します。
初期コストがモノリスより約40%高くなる点も踏まえて、どこにフルスクラッチの投資を集中させるかを判断します。
ドライバー拘束時間の規制がアーキテクチャに与える影響
配車アルゴリズムの精度を検証するPoC段階では、渋滞状況やドライバー拘束時間の年間960時間上限規制、積載率といった複数の条件を扱う点が技術的リスクになります。加えて、ベテラン配車担当者の暗黙知をパラメータ化することも、論点として挙がります。
既存の受注管理システム(OMS)やWMSとのデータ連携障害リスク、現場の入力負荷と定着リスクについても、PoC段階で検証しておく必要があります。
まとめ
TMSのリアーキテクチャは、配車最適化エンジンの独立マイクロサービス化とGPS/テレマティクスストリーム処理基盤の再設計を軸に、既存TMSの内部構造を作り替える取り組みです。DDDやBounded Context、ストラングラーフィグパターンを使って進めます。
モダナイゼーションなどの近い言葉とは、論点も進め方も異なります。中心的な読者は、技術部門やアーキテクト、エンジニアです。
配車エンジンとストリーム基盤の構造刷新
配車最適化エンジンとGPS/テレマティクスのストリーム処理基盤という2つの技術要素を軸にします。そのうえで、監視コストの増加やTCOの推移まで織り込んで投資判断を行うことが、リアーキテクチャの成功の前提になります。
規模の目安やTCOの50%ルールといった判断基準を踏まえながら、どこまでを独立サービス化するかを段階的に見極めていきます。
現状のアーキテクチャ課題の可視化
配車ロジックの密結合、GPS処理基盤の逼迫、監視オーバーヘッドの増加といった技術的負債を、まず一覧にします。そのうえで、Bounded Contextごとの投資判断を整理することが最初の一歩です。
既製パッケージやSaaSのカスタマイズでは吸収しきれない、独自の配車ロジックや多拠点管理の要件がある場合は、フルスクラッチ開発による構造刷新が有力な選択肢になります。
riplaは、フルスクラッチ開発の立場から、配車最適化エンジンの分離設計やGPS/テレマティクスのストリーム処理基盤の構築、既存基幹システムとの連携を含むTMSのリアーキテクチャを支援しています。
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。