TMSのリアーキテクチャは、進め方の種類を比べ、評価軸や依頼先で絞り込んで選びます。全面刷新を前提にせず、負債の所在を特定して、分離する対象と順番を決めます。
配車最適化エンジンとGPS・テレマティクス処理基盤の分離を検討するIT部門やアーキテクトに向けて、自社の条件に合う選択肢を絞る視点を示します。
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリアーキテクチャ着手前に整理すべき自社の課題
最初に、既存TMSのどこに技術的負債が集まっているかを洗い出します。負債の所在と業務への影響を説明できる状態にしておくと、そのあとの進め方や依頼先を比べやすくなります。
配車ロジックの密結合化
配車計画やルート最適化が、ユーザー管理・請求処理と同じモノリスに密結合していると、小さな変更でも全体のテストとリリース調整が必要になります。
発注側と開発会社は、デプロイ頻度、調整工数、変更待ちの長さを確認し、密結合が業務のボトルネックになっているかを見極めます。
GPS/テレマティクス処理基盤の逼迫
車両台数やセンサー項目の増加で、GPS・テレマティクス処理が遅れている場合は、基盤が逼迫していないかを確認します。
両者は、レイテンシ、帯域コスト、ルート逸脱検知などの応答性を数値で捉えたうえで、エッジコンピューティングが必要かどうかを判断します。
OMSやWMSとの連携でフォーマット不一致、APIエラー、手入力が続いている場合も、同じ洗い出しに含めます。
リアーキテクチャの3つの進め方
主な進め方は、ストラングラーフィグによる段階移行型、一括再構築型、コア・サテライト型です。進め方を比べるときは、業務を止められる時間、境界設計の確度、社内のリスク許容度をそろえて見ます。
ストラングラーフィグ段階移行型
APIゲートウェイの周囲に新サービスを置き、カナリアリリースやフィーチャートグルを使って、小さな範囲から移行します。
旧システムと並行稼働しながら6〜18ヶ月かけて拡大できるため、輸送業務を止めにくい企業に向いています。一方で、並行稼働中の運用負荷は、あらかじめ見積もっておく必要があります。
一括再構築型とコア・サテライト型
一括再構築型は、新アーキテクチャを一から作り込み、一定期間の並行稼働を経て一斉に切り替える方法です。境界設計さえ固まっていれば移行期間の複雑さを抑えられる半面、切り替え日の失敗が業務全体に波及するリスクは大きくなります。
コア・サテライト型は、配車最適化エンジンのような競争優位性に直結するコア業務ドメインだけをフルスクラッチで作り込みます。認証や通知といったコモディティ領域は、既存システムやSaaSを残してAPI連携する構成です。そのため、すべてを作り直す必要がない分、投資を絞り込みやすいアプローチといえます。
どの型を選ぶ場合でも、GPS/テレマティクスストリーム処理基盤と配車最適化エンジンという2つの技術要素のどちらを先に着手するかで、必要な体制やスケジュールの前提が変わります。この点は、どの型にも共通して押さえておく必要があります。
リアーキテクチャを判断する評価軸
進め方の候補を絞ったら、規模・コスト・要件の3方向から実行の可否を評価します。流行や印象よりも、自社の数値と運用条件を判断の基準にします。
規模閾値とTCOの50%ルール
マイクロサービス化が正当化されやすい目安は「1日100万リクエスト以上かつエンジニア50名以上」です。これを下回ると、運用オーバーヘッドがメリットを上回りがちです。
加えて、既存パッケージ・SaaSのカスタマイズ費用が本体価格の50%を超える場合は、フルスクラッチの方が長期的にコスト効率が良いと判断される「50%ルール」に当たります。このルールも、社内の見積もりと突き合わせて確認する価値があります。
初期コストはモノリス比で約40%高くなる前提があります。一方で、インフラコストは短期的に増加しつつも、長期では15〜35%削減され、保守費用は30〜50%低下、TCO全体では20〜45%削減されます。投資回収期間は12〜36ヶ月が標準とされ、社内稟議の説明材料として押さえておくと判断しやすくなります。
外部連携要件とスケーラビリティ要求
外部連携と負荷の条件は、次の項目がいくつ重なるかで見ます。重なるほど、標準パッケージだけで吸収できるかを慎重に見極める必要があります。
- 倉庫・営業所が3拠点以上
- ECや複数チャネル、基幹システムとの連携
- 重量物、温度帯、混載など独自の配車条件や繁忙期の負荷
該当数が少ない場合は、すべてを分離せず、負債の大きいコンポーネントから着手すると、投資対効果を保つ助けになります。
評価軸を数値にする際は、確認方法まで統一してから採点します。担当者ごとの主観に任せると、評価がそろいません。
「外部連携に対応できる」と回答されても、API連携なのかCSVの手動出力なのか、障害時にどちらが復旧を担うのかが見えません。
そこで、デモで確認したのか、仕様書で確認したのか、契約条項で確認したのかを記録に残します。未確認の項目は点数を付けずに保留にすると、営業説明の分かりやすさに評価が引っ張られるのを防げます。
開発会社・依頼先選定のポイント
進め方と評価軸が固まったら、構造刷新を任せる開発会社を選びます。機能一覧や実績数の多さよりも、自社の技術的負債にどう向き合ってくれるかを基準に絞り込みます。
段階拡張の実績とモダンな技術スタック
発注側は、要件定義から伴走し、アジャイル・MVPによる段階拡張を実際に進めた実績があるかを確認します。
あわせて、Node.js、TypeScript、React、Next.js、AWS、GCPといったモダンな技術スタックを採用しているかも見ておきたいところです。特に、将来の保守人材を確保しやすいかどうかは、長期運用のしやすさに直結します。
提案書に並ぶ実績社数や機能一覧は、判断材料の一部にすぎません。そこで、自社と近い規模・業種で、ストラングラーフィグ型の段階移行を実際に完遂した経験があるかを、具体的な工程やつまずいた点まで踏み込んでヒアリングすると有効です。
密なコミュニケーション体制と基幹連携の経験
既存の基幹システムやWMSとのAPI・EDI連携、地道なデータ移行・マスタ整備のノウハウを確認するとともに、週次定例などの密なコミュニケーション体制や、AI駆動開発による期間短縮の体制も、依頼先を比べる材料になります。
依頼先の体制と基幹連携の経験を比べるときは、見積もりに含まれる費用の内訳も並べて確認します。内訳を並べておくと、導入後の想定外の費用増を避けやすくなります。なお、開発費のうち中規模の金額は、TMSドメインのスクラッチ開発を前提としています。
- 開発費：中規模は初期費用1,000万円〜3,000万円・開発期間6〜12ヶ月、大規模は初期費用3,000万円〜1億円超・開発期間12ヶ月以上
- 保守費：フルスクラッチ開発の場合、中規模システムで月額10万円〜30万円、大規模システムで月額30万円〜100万円が目安
- 体制：SRE・インフラが月額80万〜130万円、PM・アーキテクトが月額80万〜140万円、配送最適化（配車）AI・データが月額150万〜250万円
- 地図API：独立した配車エンジンの背後で稼働し続けるライセンス費用で、ゼンリンAPIの場合は配車計画APIで月額55,000〜220,000円程度
- 通信端末：車両・ドライバーごとのランニングコストで、スマホアプリは月額1,500円程度、車載デバイスは月額2,200円程度
体制の費用は、大規模案件ではPM・アーキテクトの月額が最大220万円です。また、独自の配車計画テーブル構築だけで初回開発費1億円（納期1年）の見積もり事例もあります。デジタコやハンディターミナルとの独自連携インターフェースの開発費は、50万〜500万円程度です。
PoC・アーキテクチャスパイクの進め方
依頼先の候補を絞ったら、本開発の前にPoC・アーキテクチャスパイクで技術的不確実性を解消します。資料や提案書の確認に加えて、実際に動くものを見て評価します。
数日から数週間の使い捨てコードで実現可能性を検証するアーキテクチャスパイクを組み合わせると、本開発の前に、配車エンジン分離時のレスポンスタイムのような技術的な不安要素を潰しておけます。
垂直スライスによるPoCの対象
最初のモジュールには、「特定エリアの配車最適化処理」や「一部車両のGPS・テレマティクスデータ収集基盤」など、DB・API・インフラまでを一気通貫で切り出した最小単位を選びます。
PoC単体の期間は3ヶ月〜、費用感は100万円〜500万円程度が目安とされます。検証の中心は、配車エンジン分離時のレスポンスタイムや、数千台規模のGPSストリーム処理のスケーラビリティです。
最初の四半期のGo/No-Go判定
パイロットフェーズにあたる最初の四半期では、次の4点を確認します。配車最適化エンジンがAPI・サービスとして明確に分離できているか、CI/CDパイプラインが初期段階で確立できているか、最初のコンポーネントが他システムに悪影響なく独立稼働できているか、開発速度が向上し始めているかです。
いずれかが未達であればNo-Goと判断し、ドメイン境界設計やDevOps体制を依頼先と見直します。
リアーキテクチャの失敗を避ける方法
よくある失敗は、境界設計を急ぐことと、分散を目的化してしまうことです。どちらも、性急にマイクロサービス化を進めた結果として起こりやすい落とし穴です。
分散型モノリス化の回避
DDDによる境界定義が甘いままサービスを分割すると、サービス間が密結合になります。その結果、一つの変更に複数サービスの同時リリースが必要になる「分散型モノリス」化を招きます。
境界設計に時間をかけることが、最大の遅延リスクを避ける最も確実な方法です。
過剰な分散の目的化
マイクロサービスとサーバーレスで構築した監視システムがデータ転送コストの膨張を招き、モジュラーモノリスへ統合し直すことでインフラコストを90%削減した、という反面教師の事例もあります。また、規模閾値を下回るのに流行を理由に細かく分割すると、運用オーバーヘッドがメリットを上回りがちです。
具体的な技術要素の候補を確認したい場合は、TMSのリアーキテクチャのパッケージ・クラウド製品一覧を参照すると、比較の土台にしやすくなります。
TMSのリアーキテクチャ選定前に確認しておきたいポイント
候補となる進め方や依頼先を絞った後も、体制、予算、期間の観点から見落としがないかを確認しておくと、着手後の想定外を減らせます。
特に、地図APIや車載デバイス連携といったTMS特有の周辺コストは見落とされがちです。そのため、あわせて確認しておく必要があります。
少人数チームでの進め方
開発チームが10〜15名未満の場合、サービスメッシュなどの複雑なインフラを維持する運用オーバーヘッドが、メリットを上回りやすいのが実情です。
配車最適化エンジンなど負債が最も深刻な1コンポーネントに対象を絞り、外部の専門人材と組んで部分的に着手する方法が現実的です。
フルスクラッチの範囲
必要ありません。コア・サテライト型のように、競争優位性に直結する配車最適化エンジンだけをフルスクラッチで作り込み、それ以外は既存システムやSaaSを残す構成が現実的な選択肢です。
TCOの50%ルールや外部連携要件の該当数を基準に、どこまでを作り直すかを線引きします。
移行に見込む期間の目安
パイロット(PoC・技術検証)は3〜6ヶ月、MVPは6〜12ヶ月、本番移行は12〜18ヶ月が目安で、大規模なビジネスドメイン再構築を伴う全体移行は通常12〜18ヶ月かかります。
データクレンジングへの先行投資次第で、後続フェーズの期間が短縮される場合もあります。そのため、初期段階の準備工程を軽く見ないことが欠かせません。
まとめ
TMSのリアーキテクチャの選定では、まず配車ロジックの密結合化とGPS/テレマティクス処理基盤の逼迫という自社の技術的負債を特定します。そのうえで、ストラングラーフィグ型・一括再構築型・コア・サテライト型から進め方を選びます。
発注側は、規模閾値・TCOの50%ルール・外部連携要件・スケーラビリティ要求という評価軸で判断し、実在するモジュールを使ったPoCでGo/No-Go基準を確認します。
モダンな技術スタックと基幹連携の経験による依頼先の選定
依頼先は、要件定義からの伴走実績とモダンな技術スタックを軸に絞り込みます。基準には、既存基幹システム・WMSとの連携経験や密なコミュニケーション体制も含めます。機能数や知名度より、これらを重く見ます。
分散を目的化しないために、規模閾値とTCOの50%ルールに照らして必要な範囲だけを構造刷新することが、投資対効果を保つ鍵になります。
技術的負債の洗い出し
配車ロジックの密結合、GPS処理基盤の逼迫、監視オーバーヘッドの増加のうち、自社で最も深刻な項目を洗い出すことが選定の出発点です。
既製パッケージやSaaSのカスタマイズでは吸収しきれない独自の配車ロジックや多拠点管理の要件がある場合、フルスクラッチによる構造刷新が有力な選択肢になります。
riplaはフルスクラッチ開発の立場から、進め方の選定支援から配車最適化エンジンの分離設計、既存基幹システムとの連携までを一貫して支援しています。
▼全体ガイドの記事
・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を創業。