TMSのリアーキテクチャのパッケージ/クラウド製品一覧

TMSのリアーキテクチャを支える技術基盤は、ストリーム処理、実行、ワークフローの3つに分けて選ぶと、自社の課題に合う構成を検討しやすくなります。製品を比べる共通軸、主要6製品の特徴、課題別の絞り方を順に紹介します。

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

パッケージ型とクラウド型の技術基盤の違い

GPS・テレマティクスのストリーム処理基盤と配車最適化エンジンの実行基盤を、買い切りのパッケージソフトを自社サーバーに導入して作る方法は一般的ではありません。

この領域では、具体的な機能や料金を確認しやすいクラウド型を中心に紹介します。

パッケージ型の自社構築と継続保守

自社データセンター内にストリーミング基盤やコンテナ実行基盤を個別に構築し、すべて自社で保守する形も、理論上は可能です。

自社で保守する場合は、メッセージング基盤のバージョンアップ、セキュリティパッチの適用、可観測性の確保まで、自前で継続する体制が前提になります。

24時間絶え間なく流れ込むGPS・テレマティクスデータを扱う基盤ほど、運用の継続性が問われます。そのため、多くの企業はマネージドサービスとしてクラウド型を選んでいます。

クラウド型が中心になっている理由

クラウド型のストリーミング基盤やコンテナ実行基盤では、クラスター管理やパッチ適用をベンダーに任せられます。

車両台数や配送エリアが増えると、GPS・テレマティクスデータの量も段階的に増えます。このため、基盤の運用をマネージドサービスに委ねられるかが、リアーキテクチャ全体の負荷を左右します。

ポイント

基盤を自社で構築するか、クラウド型のマネージドサービスを使うかは、メッセージング基盤の保守やパッチ適用を自社で続けられるかで判断できます。24時間流れ込むデータを扱うほど、この継続性が問われます。

製品を比較するときの共通軸

製品選定の比較観点として、データ処理特性、既存クラウド基盤との統合性、監視やログ収集を並べた図。
データの扱いと既存環境へのなじみやすさを並べて確認できます。

自社のデータ量や配車最適化エンジンの分割方針に合うかは、製品ページの機能一覧を見ても分かりにくいものです。そこで、データ処理特性と既存クラウド基盤との統合性を比べます。

データ処理特性との適合性

GPS・テレマティクスデータは、車両台数やセンサー項目数の増加に応じてメッセージ量が変わります。また、一般的な業務データと異なり、順序保証やべき等性が求められます。

ストリーム処理基盤を比べるときは、取り込み速度に加えて、順序保証の方式、重複排除、遅延時のリトライ挙動を確かめます。

実行基盤では、CPU負荷の高い配車計算を独立してスケールできるかが比較点になります。

既存クラウド基盤との統合性

既存のクラウド基盤との統合では、AWSの利用状況、ベンダー依存の度合い、運用基盤への統合を並べて製品を比べます。

  • AWS中心の環境:既にAWSを主に利用している場合は、AWSにネイティブ統合された製品を優先すると、認証やネットワーク設定の重複を避けられます
  • ベンダー依存の回避:複数クラウドを併用する構成や、特定ベンダーへの依存を避けたい場合は、マルチクラウド対応製品のほうが柔軟性を保ちやすいこともあります
  • 運用基盤との統合:監視やログ収集を既存の運用基盤にどこまで統合できるかが、運用開始後の負荷に関わります

詳しい評価手順は、TMSのリアーキテクチャの選定ポイントで整理しています。

ポイント

製品は、データ処理特性と既存クラウド基盤との統合性を同じ軸で並べると比べやすくなります。順序保証やべき等性の扱いと、既存環境への統合の度合いを両方見ておくと、運用開始後の負荷も読みやすくなります。

TMSのリアーキテクチャを支える主要クラウド製品6選

2026年7月時点で、現行の公式ページと対応内容を確認できた6製品を紹介します。

なお、掲載順はランキングではありません。製品は、GPS・テレマティクスのストリーム処理基盤と、配車最適化エンジンの実行・オーケストレーション基盤に分けて並べます。

Amazon MSK(Managed Streaming for Apache Kafka)

Amazon MSKは、AWSが提供するフルマネージドのApache Kafkaサービスです。導入を検討するうえで押さえたいのは、提供形態、課金の仕組み、料金の目安、TMSでの候補になる場面です。

  • 提供形態:Provisioned、Serverless、Connect、Replicatorの各形態。2026年7月時点で現行提供を公式に確認
  • Provisionedの課金:ブローカーインスタンスの時間単価と、ストレージ(GB-month単位)の二つを基準
  • 料金例:2026年7月時点の公式サイトでは、kafka.m7g.largeを3台構成にすると月$606.94程度
  • TMSでの候補:車両台数に応じてGPS・テレマティクスの取込量が段階的に増える場合に候補になり、プロビジョニングや保守をAWSに任せられます

Amazon Kinesis Data Streams

Amazon Kinesis Data Streamsは、サーバー管理が不要なAWSのリアルタイムストリーミングサービスです。GPS位置情報のような連続的なイベントデータの取り込みに利用できます。判断材料になるのは、運用の負担を抑えるオンデマンドの仕組み、利用対象、料金の単位、プロビジョニング方式の料金です。

  • オンデマンド:サーバー管理が不要で、自動スケーリングに対応
  • 利用対象:GPS位置情報など、連続するイベントデータの取り込み
  • 料金(2026年7月時点):公式サイトでは、オンデマンドアドバンテージモードの取込が1GBあたり$0.032、取得が1GBあたり$0.016
  • プロビジョニング:シャード時間あたり$0.015

実際の適用条件や最新の価格は、見積もりの段階で確認してください。

Confluent Cloud

Confluent CloudはKafkaの開発チームが提供するフルマネージドのクラウドサービスです。候補として、利用環境や契約条件に照らして比べるときは、提供形態、利用環境、料金、新規登録時の特典が判断材料になります。

  • サービス形態:Kafka開発チームのマネージドサービスで、4種類のクラスターを提供
  • 利用環境:複数クラウドやオンプレミスを横断し、特定ベンダーに依存しない構成の候補
  • 料金:従量課金で、年間コミットメント割引も選択可能
  • 新規登録:30日間$400分のクレジットを提供

クラスタータイプはBasic、Standard、Enterprise、Freightです。

2026年7月時点で現行サービスとして提供されていることも、公式に確認しています。

Amazon EKS(Elastic Kubernetes Service)

Amazon EKSはAWSが提供するマネージドKubernetesサービスです。TMSに当てはめると、クラスター管理の手間、配車最適化エンジンのスケール、AWS基盤との連携、料金と提供状況が判断材料になります。

  • クラスター管理:「Amazon EKS Auto Mode」は単一クリックで管理を自動化し、容量計画やスケーリングにも自動的に対応
  • 利用用途:CPU負荷の高い配車最適化エンジンを、繁忙期に合わせて独立してスケール
  • AWS基盤との連携:GPS・テレマティクスのストリーム処理基盤もAWS上にあれば、認証やネットワークを共通化しやすい
  • 料金・提供状況:料金は別途Pricingページで確認し、2026年7月時点の現行提供は公式ページで確かめています

Temporal

Temporalは、マイクロサービス間のワークフローをコードで記述・実行できるオーケストレーション製品で、公式に「Compensating Patterns(Saga)」を掲げています。

TMSで使うなら、補償処理の範囲、ワークフロー管理の機能、向いている案件、料金の区分を確かめます。

  • 補償処理:配車確定、ドライバー通知、荷主の追跡画面更新など、複数サービスにまたがる処理が途中で失敗しても、複雑な自前実装なしに対応できる
  • ワークフロー管理:自動リトライやタイマーを備え、状態の永続化や長時間処理の追跡にも対応
  • 利用候補:配車最適化エンジンの分離など、分散トランザクションの整合性確保が課題になる案件
  • Temporal Cloud料金:2026年7月時点で、Essentialsは月額$100〜、Businessは月額$500〜
  • Enterprise料金:カスタム価格

新規ユーザー向けには$1,000分のクレジットも案内されています。最新の適用条件は、見積時に確認してください。

AWS Step Functions

AWS Step Functionsは、複数のAWS Lambda関数などを組み合わせてサーバーレスなワークフローを構築するオーケストレーションサービスです。

AWS中心の構成で検討する場合は、ワークフローの組みやすさ、AWSの各サービスとの統合、エラー処理と状態管理、整合性の保証範囲を照らし合わせます。

  • ワークフロー:Lambdaなどを組み合わせ、サーバーレスで構築
  • 設計・統合:ドラッグ&ドロップの画面で設計でき、220以上のAWSサービスと統合
  • 管理機能:自動エラーハンドリングと状態管理に対応
  • 留意点:Temporalのような明示的な分散トランザクション保証の記載はない

既にAWS上でサーバーレス中心の構成を検討していて、配車最適化エンジンの一部処理をLambda関数群として組み立てたい場合に候補になります。必要な整合性レベルに応じて、ほかの製品との使い分けを検討します。

具体的な料金はページ上に記載がないため、別途Pricingページで確認する必要があります。

自社の課題別に候補を絞る方法

6製品をすべて詳しく比べるより、今つまずいている技術要素を一つ決めて、その要素に必要な製品から絞るほうが効率的です。

GPS/テレマティクスストリーム処理基盤の逼迫を解消したい場合

車両やセンサーが増えてメッセージ処理が追いつかなくなっている場合は、データ量と既存のクラウド環境に合わせて、次の候補を比べます。

  • AWS中心:Amazon MSKまたはAmazon Kinesis Data Streams
  • 複数クラウド・オンプレミス横断:Confluent Cloud

いずれの製品でも、順序保証とべき等性の実装方法をデモで確認してください。

配車最適化エンジンの分離と整合性確保を進めたい場合

配車最適化エンジンを独立したマイクロサービスとして切り出す場合は、実行基盤と補償処理の要否を分けて検討します。

  • 実行基盤:Amazon EKS
  • 複数サービスの補償処理:Temporal
  • AWS中心のサーバーレス構成:AWS Step Functions

配車確定からドライバー通知、荷主の追跡画面の更新まで、実際の配車シナリオで試します。そのうえで、分散トランザクションの保証レベルが業務要件に合うかを確かめます。

ポイント

候補は、いまつまずいている技術要素を一つ決めてから絞ります。ストリーム処理、配車最適化エンジンの分離、整合性確保のどれが最優先かで、比べる製品が変わります。

料金・契約前の確認項目

見積もりに含めるデータ転送量、稼働時間、将来の配送量やサービス数、地図APIライセンスを示す図。
基盤の利用料に加えて、将来規模と周辺費用も見積もりに並びます。

今回の6製品のうち一部は、公式ページに具体的な価格がなく、従量課金か個別見積もりです。そこで、GPS・テレマティクスデータの想定流量と配車最適化エンジンの処理規模を伝え、総保有コストを確かめます。

課金の対象

料金を比べるときは、次の項目を見積もりに含めます。

  • ストリーミング基盤:データ転送量、パーティション数、クラスターのインスタンスサイズなど、複数の指標で課金されることがあります
  • 実行・オーケストレーション基盤:稼働時間やリクエスト実行回数に応じた従量課金が中心です
  • 将来の規模:現在の車両台数に加え、1年後・3年後の配送量やサービス数を示して見積もりを取ります
  • TMS特有の周辺費用:ゼンリンAPIなどの地図APIライセンスや車載デバイス連携費用は、6製品の従量課金とは別に継続して発生するため、総保有コストに含めます

サポート体制と契約形態

Confluent CloudやTemporalのように、オープンソース起源の技術を基にしたマネージドサービスがあります。さらに、セルフホスト版と商用クラウド版が併存するものもあります。

GPS・テレマティクスデータの取り込みが止まると、配車業務全体に影響します。そこで、自社で解決しきれない障害を想定して、商用サポートの対応時間、窓口、契約範囲を確かめます。

ポイント

料金は、従量課金の単位と将来の規模、地図APIなどの周辺費用を含めた総保有コストで比べます。サポートの対応時間と契約範囲も、見積もりの段階で確かめておきます。

デモとPoCで最終候補へ絞る進め方

一部車両のGPSデータを配車最適化エンジンで処理して追跡画面へ反映し、障害時の追跡も確認するPoCの流れ。
通常時のデータ経路に、障害時の追跡確認を加えた構成です。

資料比較で2〜3製品に絞ったら、実際の車両データや配車エリアの一部を使って、動作を検証します。

アーキテクトに加えて、配車最適化エンジンを実装するエンジニアも参加すると、導入後の運用イメージのずれを減らせます。

1機能のフルパス検証

実データを使って、次の項目を確かめます。

  • 処理経路:一部車両のGPSデータをストリーミング基盤に取り込み、配車最適化エンジンで処理
  • 結果の反映:ドライバーアプリや荷主の追跡画面に反映されるところまで、一通り動かす
  • 障害時の追跡:正常系に加え、メッセージの重複や欠落、障害時に処理が止まった場所を追跡できるかを試す
  • 記録項目:通信レイテンシ、障害時の切り分けにかかった時間、監視画面での可視性を残し、本格展開の判断材料にする

移行効果の実測と稟議での活用

PoC前に、配車最適化ロジック変更の確認工数、リリース所要時間、GPS・テレマティクスデータの遅延件数を記録しておき、PoC後の数値と比べます。

一般的な効果をそのまま当てはめるより、自社の車両台数と開発チームの実績値で算出したほうが、経営層への説明に根拠を持たせられます。

ポイント

最終候補は、デモと自社の実データを使ったPoCで絞ります。障害時の追跡や記録した数値まで見ておくと、導入の判断根拠を残せます。

TMSのリアーキテクチャの製品比較で押さえておきたいポイント

候補を選ぶときは、買い切り型の有無やおすすめ順位だけでなく、自社のGPS・テレマティクスデータ量と配車最適化エンジンの分割方針に合うかを、同じ条件で比べます。

パッケージ型が必要な場合の個別構築

具体的な機能や料金を確認しやすいGPS・テレマティクスのストリーム処理基盤や配車最適化エンジンの製品は、現在、クラウド型が中心です。ただし、自社データセンター内での完全な自社構築が必須の場合は、オープンソース製品を組み合わせた個別構築や、外部ベンダーとのハイブリッド構成も比べます。

おすすめの製品と最優先課題

全企業に共通する1位の製品はありません。最優先課題(ストリーム処理基盤の逼迫解消、配車最適化エンジンの分離、分散トランザクションの整合性確保など)を決め、それに合う製品を候補にします。

対象範囲と課題を明確にしたうえで、必要な製品の組み合わせを2〜3案に絞り、PoCへ進みます。

複数年の総保有コストでの比較

同じデータ量、サービス数、サポート条件を各社に提示し、数年単位の総保有コストで比べます。

利用料に加えて、学習コスト、既存基盤との統合作業、商用サポート費用も含めます。地図APIや車載デバイス連携など、TMS特有の周辺コストも判断材料になります。

まとめ

TMSのリアーキテクチャでは、買い切り製品を探すより、役割ごとにクラウド製品を組み合わせるほうが現実的です。GPS・テレマティクスのストリーム処理基盤と、配車最適化エンジンの実行・オーケストレーション基盤を分けて考えます。

今回紹介した6製品には、マルチクラウド対応、AWS基盤との統合、Sagaパターン対応など、それぞれ異なる強みがあります。

課題診断から2〜3案への絞り込み

まず、GPS・テレマティクスのストリーム処理基盤の逼迫、配車最適化エンジンの密結合化、分散トランザクションの整合性確保のうち、最優先課題を決めます。次に、データ処理特性との適合性と既存クラウド基盤との統合性で候補を比べます。

話題性だけに左右されず絞り込むため、評価軸の詳細はTMSのリアーキテクチャの選定ポイントもご確認ください。

実データのPoCによる最終確認

資料上の機能一覧を見るだけでなく、自社の車両データや配車エリアを使ったPoCで、レイテンシや障害対応にかかる時間まで検証します。そのうえで、導入を判断します。PoCで既製製品の不足が見えた場合は、次の点も検討します。

  • 個別設計の要否:既製のクラウド製品で独自の分割方針や基幹システム連携を吸収しきれない場合は、個別の設計・実装支援が必要になることもある
  • riplaの支援:フルスクラッチ開発の立場から、不足部分の整理や業務に合わせたTMSのリアーキテクチャ実装を担います

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。