TMSのリアーキテクチャにおけるフルスクラッチ・オーダーメイド開発は、配車最適化エンジンやGPS・テレマティクスストリーム処理基盤を、独立したマイクロサービスとしてゼロから設計・構築することです。
リアーキテクチャの対象は、配車計画の立案、走行ルートの最適化、運賃計算、車両とドライバーの動静管理を担ってきた既存のTMS（輸配送管理システム）です。5つの技術的アプローチ（5R：リホスト、リプラットフォーム、リファクタリング、リビルド、リプレース）のうち、特にリファクタリングとリビルドを深掘りします。
その中心は、モノリスからマイクロサービスへの分解、ドメイン駆動設計（DDD）、API-first設計、クラウドネイティブのアーキテクチャパターンという構造そのものの設計です。IT部門やアーキテクト、エンジニアなど技術者が投資判断の材料を得られるよう、実務に踏み込んで解説します。
- 対象：技術要件と業務条件
- 工程：検証から実装まで
- 確認：品質と運用条件
このテーマの全体像は、以下の記事をご覧ください。
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリアーキテクチャの位置づけ（フルスクラッチ投資を検討する論点）
TMSのリアーキテクチャにおけるフルスクラッチ開発の位置づけを正しくつかむには、近接する4つの記事群との違いを先に切り分けておく必要があります。同じ「TMS」というキーワードでも、フルスクラッチという言葉が指す対象は記事ごとにまったく異なるためです。
モダナイゼーション・刷新・更改・リニューアルとの違い
「TMSのモダナイゼーション」が扱うリビルド（フルスクラッチ）は、既存のTMSを丸ごとゼロから作り直すという、規模軸の話です。「TMS刷新」が扱うのは、輸送コスト増・積載効率低下・傭車比率上昇の改善を根拠にした予算確保で、経営層の投資判断という文脈です。
「TMS更改」は、契約満了までの残存期間内でパッケージ・SaaSを選ぶかフルスクラッチにするかを決める、期限起点の判断を扱います。「TMSのリニューアル」は、ドライバーアプリや配車ダッシュボードのUI/UXデザインをフルスクラッチで作り込むかという、顧客体験を起点にした判断です。
これに対し本記事群が扱うフルスクラッチ・オーダーメイド開発は、配車最適化エンジンとGPS・テレマティクスストリーム処理基盤という特定のコンポーネントを対象にします。それらを独立したマイクロサービスとしてゼロから設計・構築すべきかは、アーキテクチャ構造そのものに根差した技術的な判断になります。
マイクロサービス化でフルスクラッチが検討される理由
既存のSaaSやパッケージ製品には、標準機能の枠内でしかカスタマイズできないという限界があります。そのため、荷主ごとの運賃体系や高度な配車最適化アルゴリズムのように競争優位に直結する領域では、この制約がボトルネックになりやすいものです。
特に配車最適化エンジンやGPS・テレマティクスストリーム処理基盤は、車両特性や道路の幅員制限のほか、荷主ごとの積み合わせルールや地域特有の交通事情といった自社固有の要件を抱えることが多いです。汎用パッケージでは対応しきれないため、ベンダーロックインを避けたいという判断とあわせて、フルスクラッチによるマイクロサービス構築が検討の対象になります。
TMSのすべてをマイクロサービスとしてフルスクラッチ構築することは推奨されておらず、対象を絞った投資判断が求められます。
フルスクラッチを選ぶべきかの判断基準
TMSをフルスクラッチでマイクロサービス化すべきかは、感覚ではなく、客観的な数値の閾値と業務要件で判断します。
規模閾値（1日100万リクエスト以上・エンジニア50名以上）とTCOの50%ルール
業界の共通認識として、マイクロサービスが確実に価値を出すのは、1日100万回以上のリクエストを処理する規模で、かつ開発組織が50名以上のエンジニアを抱える場合とされています。この閾値を下回るTMSでフルスクラッチのマイクロサービス化を進めると、「マイクロサービス税（運用オーバーヘッド）」が、独立したスケーラビリティという本来の利点を上回ってしまいます。
その負担は、ネットワークレイテンシの管理、分散データの一貫性維持、Jaeger等の複雑な監視ツールの運用にかかるものです。TMSドメインでは、「TCOの50%ルール」も判断材料になります。既存パッケージやクラウドSaaSのカスタマイズ費用が本体価格の「50%」を超える場合、長期的にはフルスクラッチ開発のほうがコスト効率が良くなるとされています。
自社の配車件数やリクエスト規模、開発体制がこれらの閾値に届かない場合は、まずモジュラーモノリス（内部的にはドメインごとに整理しつつ、デプロイ単位は1つにまとめる設計）として構築します。そのうえで、将来の規模拡大に応じて段階的にマイクロサービスへ分離していくほうが、現実的な投資判断になります。
TMS特有の判断基準（特殊な配車ロジック・多拠点・繁忙期スケーラビリティ）
TMSのフルスクラッチによる独立サービス化は、極めて特殊な配車ロジックと多拠点管理を要する場合に正当化されやすくなります。たとえば、建材の重量物制約、医薬品の厳密なトレーサビリティ・温度帯管理、複数キャリアとの混載といった独自要件を要する大手物流企業や荷主企業が該当します。
また、5つの要件のうち複数に当てはまる場合も、標準パッケージでは対応が困難なため、スクラッチ開発が視野に入ります。拠点とシステム連携については、倉庫・営業所が3拠点以上ある、EC・複数チャネルとのデータ連携が必要、古い基幹システムとAPI連携が必要の3つです。
残る2つは、自動倉庫等の物流機器と連携したいこと、取引先ごとに異なるEDIフォーマットがあることです。さらに、お中元や年末商戦のように平時の3〜5倍の配送量が発生する企業では、配車計算の処理能力を自社のタイミングでスケールアウト（負荷分散）させる設計が必要になります。独立サービス化が強みを発揮する典型的な条件です。
GPS・テレマティクスストリーム処理基盤のオーダーメイド開発
GPS・テレマティクスストリーム処理基盤をオーダーメイドで構築する場合は、汎用的な監視ツールを導入するのとは違い、インフラそのものの設計と相応の初期投資を覚悟しておく必要があります。
フルスクラッチで構築するインフラ要素と車載デバイス連携費用
オーダーメイドで構築する際は、KafkaやKinesisといったメッセージブローカー本体だけでなく、それを動かすKubernetesクラスターも設計対象になります。さらに、サービス間通信を制御するサービスメッシュ、そして分散トレーシング（Jaeger・OpenTelemetry）や監視スタック（Prometheus・Grafana）までを、一式で設計・構築する必要があります。
これらは、位置情報という自社固有のデータ特性（更新頻度、データ形式、トンネル・山間部での欠損時の扱い）に合わせて、パイプライン全体をカスタムメイドで組み上げる作業です。そのため、単体の製品をそのまま導入する形にはなりにくい部分です。
あわせて、デジタルタコグラフやハンディターミナルといった車載デバイスとの独自の連携インターフェースを開発・実装する場合は、別途50万円〜500万円程度の追加開発費用を見込む必要があります。この連携部分は、汎用テンプレートでは対応しきれず、必ず残ります。
初期コスト（モノリス比40%高）とその根拠
フルスクラッチによるマイクロサービス構築は、モノリス（またはモジュラーモノリス）と比べて、初期開発コストが約40%高くなるとされています。これは、Kubernetesクラスターやサービスメッシュ、分散トレーシングといったインフラと自動化ツールの初期設定に、相応の工数がかかるためです。
GPS・テレマティクスストリーム処理基盤のように常時大量のデータを扱うコンポーネントでは、この初期投資の割合がさらに大きくなる傾向があります。この初期コストの上振れを許容できるか、そして中長期的なTCO（総所有コスト）の削減や独立したスケーラビリティを優先できるかが、実質的な判断基準になります。
配車最適化エンジンのオーダーメイド開発
配車最適化エンジンは、自社の競争優位に直結しやすい領域です。そのため、このコンポーネントは、フルスクラッチ投資の是非を最も慎重に検討すべき対象です。
コア業務ドメインとしての投資判断
ドメイン駆動設計では、業務ドメインを次の2つに分けて、フルスクラッチへの投資を判断することが推奨されます。
- コア業務ドメイン：独自の配車ロジックや荷主ごとの運賃計算のように、競争優位に直結し要件変更が頻繁に起きる領域。
- コモディティ領域：標準的な決済処理、一般的な通知配信、認証基盤など。
配車最適化エンジンのようなコア業務ドメインには、トップクラスのエンジニアを配置して、独立したマイクロサービスとしてフルスクラッチで作り込む価値があります。一方で、コモディティ領域まで自社でフルスクラッチ構築するのは「車輪の再発明」になります。
API-first設計によって、外部SaaSや既存システムをAPIとしてカプセル化・再利用するほうが合理的です。この切り分けを誤ると、本来投資すべき配車最適化エンジンへのリソースが分散し、開発期間・費用の両面で非効率が生じます。
開発会社を選定する際は、Node.js、TypeScript、Reactといったモダンな技術スタックを採用しているかを見ます。Next.js、AWS、GCPまで含めて採用状況を確認し、将来的な保守人材を確保しやすいかどうかも見ておくべき点です。
データ準備投資（プロジェクト費用の40〜60%）と1億円規模の事例
フルスクラッチで配車最適化エンジンを成功させる前提条件は、プロジェクト全体費用の40〜60%を、データの準備・整備に予算化できるかどうかです。住所データの不均一なフォーマット、ジオコードの欠落、重複登録といった品質の低いデータをそのままアルゴリズムに投入すると、期待した最適化効果が得られないばかりか、現場からの信頼を失うリスクもあります。
一方で、データ準備を軽視せず適切に投資した組織は、本番環境でのROI達成を6〜12ヶ月早く実現できるという知見もあります。中規模（複数拠点・API連携あり）の場合は、初期費用1,000万円〜3,000万円、開発期間6〜12ヶ月が目安です。大規模（複数倉庫・高度自動化・多拠点）の場合は、初期費用3,000万円〜1億円超、開発期間12ヶ月以上が見込まれます。
大手企業では、独自の「配車計画テーブル」構築のみで初回開発費1億円（納期1年）という提示を受けた事例もあります。フルスクラッチという大きな投資判断をする以上、アルゴリズム開発と同等かそれ以上にデータ基盤への投資を織り込んでおく必要があります。
フルスクラッチ開発を成功させる体制・依頼先選定
ここまでの判断基準を踏まえると、TMSのリアーキテクチャをフルスクラッチで成功させるには、専門人材の体制づくりと依頼先の選定を、どちらも固めておく必要があります。
アーキテクト・SRE・配車AIエンジニアの体制構築
フルスクラッチのマイクロサービス構築には、専門人材が欠かせません。ドメインエキスパートはドメイン駆動設計による境界分離を担い、プラットフォームエンジニアはKubernetes・サービスメッシュ・CI/CDの運用を、SREは分散トレーシングによる障害の局所化を担います。
さらに、配車最適化エンジンの場合は、配車アルゴリズムや機械学習モデルを扱う配車最適化（AI・データ）エンジニアも必要になります。これらの人材は市場全体で「極めて希少で高価」とされています。開発組織の規模が10〜15人未満の場合、高価な専門エンジニアがインフラ維持に忙殺され、ビジネス価値を生み出す前にコストだけが先行するリスクがあります。
独立した小規模チームが各マイクロサービスを自律的に運用できる体制（いわゆるコンウェイの法則に沿った組織設計）が整うまでは、フルスクラッチによる本格的なマイクロサービス化は見送るべきという指摘もあります。そのため、自社の体制成熟度を客観的に評価しておく必要があります。
依頼先選定のポイント
依頼先を選ぶ際は、次の点を見極めます。
- 技術力と設計：フルスクラッチで開発できる技術力、ドメイン駆動設計による業務領域の切り分け、ストラングラーフィグパターンによる段階的な移行設計。
- 高難度の構築実績：配車最適化エンジンやGPS・テレマティクスストリーム処理基盤といった高難度コンポーネントの構築経験。
- 提案と伴走：要件定義からの伴走と、段階拡張（アジャイル・MVP）の提案力。
- 連携とデータ移行：既存基幹システム・WMSとのAPI/EDI連携、泥臭いデータ移行・マスタ整備のノウハウ。
- コミュニケーション体制：週次定例等の密な進め方。
契約前の提案段階で、規模閾値（1日のリクエスト量・開発組織規模）を踏まえたうえで、フルスクラッチが本当に妥当かを客観的に助言してくれるかどうかも、信頼できるパートナーを見極める材料になります。
プロジェクト開始後は、コア業務ドメインへの投資配分とコモディティ領域のAPI活用方針を定例会議で継続的に確認します。限られた予算と希少な専門人材を、最も価値の高い領域に集中投下できているかを常にモニタリングすることが、フルスクラッチ開発を成功に導く鍵です。
まとめ
ここまで、論点の位置づけや判断基準、2つのコンポーネントのオーダーメイド開発、体制と依頼先選定を見てきました。判断材料は、規模閾値（1日100万リクエスト・エンジニア50名以上）、TCOの50%ルール、モノリス比約40%高い初期コストです。加えて、多拠点、特殊な配車ロジック、繁忙期のスケーラビリティといったTMS特有の判断基準もあります。
フルスクラッチによるマイクロサービス化は、アジリティやスケーラビリティと引き換えに、高度な運用基盤コストと希少人材の確保を伴う投資判断です。そのうえで、配車最適化エンジンとGPS・テレマティクスストリーム処理基盤というコア業務ドメインに投資を集中させ、体制の成熟度を見極めることが大切です。
Bounded Context単位の切り分けと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を創業。