TMSのリアーキテクチャとは？｜考え方/特徴/仕組み/目的を解説

配車計画やルート最適化を担う配車最適化エンジンと、GPS/テレマティクスデータを取り込むストリーム処理基盤が同じモノリスの中に同居し、片方の改修が全体のリリースを止めてしまう——TMSの技術部門にはそんな悩みが増えています。TMSのリアーキテクチャとは、配車最適化エンジンとGPS/テレマティクスストリーム処理基盤を中心に、既存TMSの内部構造をモノリスからマイクロサービスへ設計し直す、アーキテクチャそのものの技術的な再設計を指します。

本記事では、TMSのモダナイゼーション・TMS刷新・TMS更改・TMSのリニューアルとの位置づけの違い、モノリスからマイクロサービスへ移行する仕組み、配車最適化エンジンの独立サービス化、GPS/テレマティクスストリーム処理基盤の設計、導入目的と期待できるメリット、他のアプローチとの違いを順に解説します。読者としてIT部門・アーキテクト・エンジニアを想定し、技術的な深掘りに重点を置いて整理します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド

TMSのリアーキテクチャとは何か？位置づけと2つの技術要素

TMSのリアーキテクチャは、新規にTMSを立ち上げる話でも、既存TMSを丸ごと入れ替える話でもありません。すでに稼働している配車計画・運賃計算の仕組みを前提に、その内部構造そのものをどう作り替えるかという技術部門の論点です。近い言葉として「TMSのモダナイゼーション」「TMS刷新」「TMS更改」「TMSのリニューアル」がありますが、扱う軸はそれぞれ異なります。

TMSのモダナイゼーションは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースという5手法を並列に扱い、どの手法を選ぶべきかを整理する総論です。本記事群はそのうちリファクタリング・リビルドの部分をさらに深掘りし、モノリスからマイクロサービスへの分解、ドメイン駆動設計、API-first設計、クラウドネイティブアーキテクチャパターンという「構造の設計」1テーマに絞って扱います。一方でTMS刷新は、輸送コスト増や積載効率低下の可視化から経営層の稟議承認や2024年問題対応を進めるPM視点の話であり、TMS更改は保守契約満了や車載器リース満了という外圧トリガー起点、TMSのリニューアルはドライバーアプリや荷主ポータルの使い勝手刷新が中心です。本記事群は、これらとは異なり画面の裏側の技術構造に特化した内容になります。

TMSのリアーキテクチャで実務上刺さりやすい技術要素は大きく2つです。ひとつは配車最適化エンジン、つまり配車計画・ルート最適化ロジックを独立したマイクロサービスとして切り出すこと。もうひとつは、車載GPSやテレマティクス端末から届くデータをリアルタイムに処理するストリーム処理基盤の構築です。以降の章では、この2つの技術要素を軸にアーキテクチャ設計の考え方を解説していきます。

モノリスからマイクロサービスへの移行の仕組み

全体の移行は、パイロット(PoC・技術検証)3〜6ヶ月、MVP(プロトタイプ並行稼働)6〜12ヶ月、本番移行12〜18ヶ月という3フェーズで進むのが一般的です。ビジネスドメインの再構築を伴うプラットフォーム全体の移行は、通常12〜18ヶ月を見込みます。

最初の3〜6ヶ月では、配車最適化ドメインのBounded Contextを設計し、最初のモジュールをAPI・独立サービスとして分離することに集中します。最初の四半期以内に「独立サービスとしての明確な分離」「自動化されたCI/CDパイプラインの構築」「他システムに悪影響なく独立稼働できること」の3点が確認できれば、正しい方向に進んでいる指標と見なせます。逆にこれらが未達であれば、ドメイン境界設計やDevOps体制を見直すサインです。

6〜18ヶ月をかけて、APIゲートウェイでレガシーモノリスの周囲に新サービスを稼働させ、既存システムを少しずつ置き換えていくのがストラングラーフィグパターンです。カナリアリリースやフィーチャートグルを使い、「まずはA営業所の5台のトラックのみ」といった小規模な範囲から適用し、旧システムと並行稼働(Parallel Runs)させながら安定性を検証し、適用範囲を拡大していきます。

移行における最大の遅延リスクは「分散型モノリス」化です。DDDによる境界定義が甘いままサービスを分割すると、見た目はマイクロサービスでもサービス間が密結合になり、一つの変更に複数サービスの同時リリースが必要になってリリース調整コストが激増します。境界設計に時間をかけることが、結果的に開発期間全体の短縮につながります。

配車最適化エンジンの独立マイクロサービス化

配車最適化エンジンをあえて独立サービス化するのは、AI・アルゴリズムのCPU計算処理という特性が、ユーザー管理や請求処理といった一般的な業務ロジックとパフォーマンス特性・リソース要件・トラフィックパターンの面で劇的に異なるためです。コンポーネント単位で独立してスケールさせたい場合、この分離は正当化されやすくなります。

切り出し方の基本は垂直スライスです。「特定エリアの配車最適化処理」のように、DB・API・インフラまでを一気通貫で扱う最小単位を最初のモジュールとして定義し、そこから配車最適化エンジンをAPIとして独立させていきます。数日から数週間の使い捨てコードによるアーキテクチャスパイクで、分離時のレスポンスタイムなど技術的不確実性を先に解消しておくと、後続の本開発がスムーズに進みます。

ある実例では、住所やGPSデータの品質修正(クレンジング・自動ジオコーディング)にプロジェクトを意図的に4ヶ月遅らせたところ、当初9ヶ月と見込まれていた配車最適化エンジンの開発フェーズが、わずか3ヶ月で完了したという結果が得られています。フルスクラッチ開発では、プロジェクトリソースの40〜60%をデータ準備・基盤整備に割り当てるのがセオリーとされており、データ品質を後回しにしないことが、結果的に開発全体のスピードを高めます。

GPS/テレマティクスリアルタイムストリーム処理基盤の仕組み

車載GPSやテレマティクス端末、貨物センサーからのデータをすべてクラウドに集中させて処理しようとすると、レイテンシと帯域コストが膨大になります。そこでエッジコンピューティングを活用し、リアルタイムなルート逸脱検知など即時応答性が求められる処理をエッジ側で完結させ、コストとレイテンシの両方を抑える設計が基本方針になります。

Push型(Kafka等のイベント駆動)は、現在地の即時反映のようにミリ秒単位での即時確定が求められる業務に適しますが、イベントが紛失した際の補償トランザクションの実装難易度が高くなります。一方、Pull型(定期バッチ照合)は、配送実績の定期集計や運賃精算データの照合など5〜10分程度の遅延が許容される業務に向いており、シンプルなスケジューラで実装でき、障害時にも自己修復しやすいという利点があります。どちらを採用するかは、業務ごとの許容遅延をもとにPoCで検証します。

アーキテクチャPoCで検証すべき中心的な論点は、配車エンジンを分離した際のレスポンスタイムと、数千台規模のGPSストリーム処理がクラウド上でスケーラブルに捌けるかという2点です。車両台数の増加やセンサー項目数の拡大に応じてメッセージ量が変動する前提で、順序保証や重複排除、遅延時のリトライ挙動まで含めて検証しておくと、本番移行後のトラブルを避けやすくなります。

導入目的と期待できるメリット

リアーキテクチャの目的は、単に開発速度を上げることだけではありません。配車最適化エンジンとストリーム処理基盤をそれぞれ独立してスケールさせられる状態を作り、長期的なTCOを最適化することにあります。ただし、監視・運用コストが構造的に増加する点は、投資判断の段階であらかじめ織り込んでおく必要があります。

マイクロサービス化により、モニタリング要件・運用オーバーヘッドはモノリス比で40〜50%増加するとされています。サービスメッシュのインフラ費用も無視できず、Istio(サイドカー型)はプロキシあたりメモリ50〜100MB・CPU100〜200mを消費し、500サービス規模ではクラスター全体で軽量メッシュ比25〜50GB以上の追加メモリ消費が発生します。一方Cilium(eBPF型)はプロキシあたりメモリ10〜15MB・CPU20〜50mと軽量で、レイテンシもIstioの3〜5msに対し0.5〜1msと低く抑えられます。こうしたインフラが投資に見合うのは「1日リクエスト数100万回超かつ開発者50名以上」の場合とされ、開発チームが10〜15名未満だとインフラ維持に時間を取られ、メリットよりコストが上回りやすい点に注意が必要です。

インフラコストは短期的に増加するものの、長期的には15〜35%削減、保守費用は30〜50%低下、TCO全体では20〜45%削減という報告があり、投資回収期間は12〜36ヶ月が標準とされます。お中元や年末商戦のように平時の3〜5倍の配送量が発生する企業では、配車計算の処理能力を自社タイミングでスケールアウトできる独立サービス化が強みを発揮します。ただし反面教師の事例として、マイクロサービスとサーバーレスで構築した監視システムがデータ転送コストの膨張を招き、モジュラーモノリスへ統合し直すことでインフラコストを90%削減したケースもあり、過剰な分散はかえって非効率になり得ます。

TMS刷新に関する他のアプローチとの違い

「TMSを刷新したい」と考えたとき、モダナイゼーション・刷新・更改・リニューアルという言葉が併用されがちですが、視点も進め方も異なります。自社の課題がどのアプローチに該当するかを見極めておくと、以降の選定作業を無駄にせずに進められます。具体的な進め方や評価軸を整理したい場合は、TMSのリアーキテクチャの選定ポイントもあわせてご覧ください。

TMSのモダナイゼーションは、5手法を並列に検討する総論であり、どの手法を選ぶかというHOWの整理が主眼です。本記事群はそのうちリファクタリング・リビルドをさらに深掘りし、モノリスからマイクロサービスへの分解という「構造の設計」1テーマに絞っています。一方TMS刷新は、輸送コスト増や積載効率低下、傭車比率上昇の可視化から経営層の稟議承認や2024年問題対応を進めるPM視点のWHY/WHENの整理であり、技術部門・アーキテクト向けの本記事群とは読者層も論点も異なります。

TMS更改は、保守契約満了や車載器リース満了、通信規格変更という外圧トリガー起点で入れ替えを検討する取り組みであり、本記事群のようなアーキテクチャ上の技術的負債(配車ロジックの密結合化、GPS処理基盤の逼迫)起点とは出発点が異なります。TMSのリニューアルは、ドライバーアプリや配車ダッシュボード、荷主ポータルという顧客接点の使い勝手刷新が主眼で、画面の裏側の構造にまでは踏み込みません。本記事群は逆に、ストリーム処理基盤やマイクロサービス分離という画面の裏側の構造に特化し、UIそのものには言及しない立場を取ります。

TMSのリアーキテクチャ導入前に確認しておきたいポイント

リアーキテクチャを検討するかどうかは、事業規模だけで決まるものではありません。既存のTMSでどの技術的負債が顕在化しているか、どこまでを自社で担う体制があるかまで含めて整理することで、着手後の手戻りを防げます。

規模閾値(1日100万リクエスト以上・エンジニア50名以上)を下回る場合は、マイクロサービス化の運用オーバーヘッドがメリットを上回りやすいのが実情です。ただし、配車ロジックの密結合化やGPS処理基盤の逼迫が明確な技術的負債として顕在化している場合は、配車最適化エンジンなど特定コンポーネントだけを先行して切り出す部分適用が現実的な選択肢になります。

必ずしもそうではありません。Bounded Contextごとに投資判断を分け、配車最適化エンジンのような競争優位性に直結するコア業務ドメインはフルスクラッチで作り込み、認証や通知のようなコモディティ領域はSaaSや既存システムを活用してAPIカプセル化する、という切り分けが可能です。初期コストがモノリス比で約40%高くなる点も踏まえたうえで、どこにフルスクラッチの投資を集中させるかを判断します。

配車アルゴリズムの精度を検証するPoC段階では、渋滞状況やドライバー拘束時間の年間960時間上限規制、積載率といった複数条件、ベテラン配車担当者の暗黙知のパラメータ化が技術的リスクとして挙がります。あわせて、既存の受注管理システム(OMS)やWMSとのデータ連携障害リスク、現場の入力負荷と定着リスクについても、PoC段階で検証しておく必要があります。

まとめ

TMSのリアーキテクチャは、配車最適化エンジンの独立マイクロサービス化とGPS/テレマティクスストリーム処理基盤の再設計を軸に、DDD・Bounded Context・ストラングラーフィグパターンを用いて既存TMSの内部構造を作り替える取り組みです。TMSのモダナイゼーション・刷新・更改・リニューアルとは論点も進め方も異なり、技術部門・アーキテクト・エンジニアが中心的な読者になります。

配車最適化エンジンとGPS/テレマティクスストリーム処理基盤という2つの技術要素を軸に、監視コストの増加やTCOの推移まで織り込んで投資判断を行うことが、リアーキテクチャを成功させる前提になります。規模閾値やTCOの50%ルールといった判断基準を踏まえながら、どこまでを独立サービス化するかを段階的に見極めていきます。

配車ロジックの密結合、GPS処理基盤の逼迫、監視オーバーヘッドの増加といった技術的負債をまず可視化し、Bounded Contextごとの投資判断を整理することが最初の一歩です。既製パッケージやSaaSのカスタマイズでは吸収しきれない独自の配車ロジックや多拠点管理の要件がある場合、フルスクラッチ開発による構造刷新が有力な選択肢になります。riplaはフルスクラッチ開発の立場から、配車最適化エンジンの分離設計やGPS/テレマティクスストリーム処理基盤の構築、既存基幹システムとの連携を含むTMSのリアーキテクチャを支援しています。

▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。