テレマティクスとは？GPSの位置データが走行距離になるまで

テレマティクスとは、車両が自分の居場所と状態を、離れた場所にあるコンピューターへ報告する仕組みです。ダッシュボードの裏にある小さな端末が衛星測位の位置と車両データを読み取り、携帯電話網で送信します。バックエンドはそのデータの流れを、トリップ、停車、走行距離、到着時刻に変換します。「配送状況の追跡」画面の裏にある配送バン、レンタカー、トラックは、どれもこの仕組みの何らかの形で動いています。

ほとんどの人が目にしないのは、バックエンドがどれだけのデータを修復しなければならないかという点です。GPSの位置は数メートルずれ、駐車中にも少しずつ動き、2回の送信（ping）の間の車両は見えません。私たちは、それが車両管理で最も重視される2つの数字、つまり走行距離と停車にどう影響するかを測定しました。10の配送・訪問ルートを再現したシミュレーションで、GPSの送信点を直線で結んで合計すると、1秒に1回の送信では走行距離が16%多く、2分に1回の送信では18%少なく出ました。同じ送信点を当社のMap Matching APIで道路ネットワークに合わせると、誤差はそれぞれ1.9%と2.7%まで下がりました。

この記事では、テレマティクスのシステムの構成、動態管理が生の位置データをルート、停車、走行距離、到着予定時刻（ETA）に変える仕組み、適用されるEUの規則、そしてシステムを開発または導入する人にとって実験結果が何を意味するかを説明します。

テレマティクスとは

テレマティクス（telematics）という言葉は、テレコミュニケーションとインフォマティクスを組み合わせたものです。車両の分野では、次の4つの要素が連携する仕組みを指します。

• 追跡端末。 衛星測位の受信機、携帯通信モデム、多くの場合は加速度センサーを備え、車両に接続された機器です。テレマティクス制御ユニット（TCU）とも呼ばれます。自動車メーカーが搭載するものと、後付けするものがあります。
• 車両データ。 現在の車両は、エンジン、トランスミッション、ブレーキ、ダッシュボードをつなぐ共有ネットワークであるCANバスで電子システムを動かしています。追跡端末は診断ポートや直接接続を通じてこのデータを読み取ります。大型トラックには共通のインターフェースがあります。欧州のトラックメーカーがACEAのもとで合意したFMS-Standardは、他社製のテレマティクス端末に車両データへのアクセスと、デジタルタコグラフのリモートダウンロードを可能にします。
• 通信。 端末は携帯電話網でデータを送ります。電力と通信量を節約するため、通常は小さなまとまりで送信します。電波が途切れたときは位置を保存し、後でまとめて送ります。
• バックエンド。 データの流れを受信し、整え、保存し、配車担当者、ドライバー、経理担当者が使える形に変えるサーバーです。

衛星測位の位置は、それだけでは数メートルの精度です。米国政府のGPSプログラムによると、GPS対応のスマートフォンは、開けた空の下で通常は半径4.9 m以内の精度で、建物、橋、樹木の近くでは精度が落ちます。良いアンテナを備えた専用の追跡端末はこれより正確で、ドアポケットに入れたスマートフォンはこれより不正確です。いずれにしても、バックエンドに届くのは点の集まりです。車両が走った道路は、そこから復元する必要があります。

動態管理が位置データをルート、停車、走行距離、ETAに変える仕組み

車両管理プラットフォームが表示するものは、すべてこの点の集まりから計算されています。

1. トリップ。 車両から読み取るか動きから推定したエンジンのオンとオフで、データの流れをトリップに区切ります。
2. 走行したルート。 マップマッチングは、ノイズを含む位置を道路ネットワークに合わせ、点と点の間を最も可能性の高い経路で埋めます。点の集まりを道路上の線に変えるのがこのステップです。
3. 走行距離。 マッチングしたルートの長さを、トリップごと、日ごと、車両ごとに集計します。燃料カード、税務用の走行記録、整備計画、請求書の元になります。
4. 停車。 小さな半径内に十分な時間とどまる一連の位置が停車です。停車は配達の証明であり、訪問サービスの請求時間であり、次のルートを計画するための入力でもあります。
5. ジオフェンスイベント。 車庫、顧客の拠点、市内の区域への出入りを、各位置を保存済みのポリゴンと照合して計算します。この判定の仕組みはジオフェンスのガイドで解説しています。
6. ETA。 現在のマッチング済み位置から次の停車地までの残りルートと所要時間を、車両の移動に合わせて再計算します。ドライバーのリアルタイム追跡チュートリアルでは、これを最初から最後まで実装しています。

各ステップは前のステップに依存しています。マッチングを誤ると走行距離が狂い、停車を1か所見逃すと、それ以降のすべての停車地のETAが狂います。そのすべてを左右する設定が、追跡端末の送信頻度です。

実験：送信間隔と走行距離、停車の関係

2026年10月2日に、MapAtlas Directions APIで現実的なルートを10本作成しました。アムステルダム、ベルリン、パリ、マドリード、ミラノ、ワルシャワ、ウィーンでそれぞれ12か所に停車する荷物配送ルートが7本と、リヨン、ミュンヘン地域、ユトレヒト地域で5か所または6か所を長めに訪問するサービスルートが3本です。各ルートは区域の端にある車庫から出発し、車庫に戻ります。合計で534 km、停車は100か所です。

各ルートについて、GPS追跡端末を次の条件でシミュレーションしました。

• 位置誤差 は実際の受信機と同じようにゆっくりと変化します。各軸平均3 m、相関時間60秒で、さらに建物間の信号反射を想定して、1%の測位値を30 mずれた外れ値にしました。
• 各停車地での滞在時間 は、荷物配送ルートで1.5分から6分、サービスルートで15分から60分です。駐車中も追跡端末は送信を続けます。
• 6種類の送信間隔 は1秒、5秒、15秒、30秒、60秒、120秒です。すべて同じシミュレーション走行から抽出しているため、違いは観測の頻度だけです。

そのうえで、走行距離を3つの方法で測りました。送信点を直線で結ぶ方法、駐車中の送信点を除いてから直線で結ぶ方法、そしてMap Matching APIが返すルートを使う方法です。さらに、送信点に標準的な停車検出を適用しました。

誤差は全ルート合計534 kmに対する値です。範囲の列は、1つのルート単位で最も良い値と最も悪い値を示しています。1秒から60秒で見逃した1か所の停車は、13 m離れたミラノの2か所の停車地で、検出器はこれを1か所の停車として扱いました。

頻繁な送信は走っていない距離まで数えます

1秒に1回の送信では、送信点を直線で結ぶと走行距離が15.7%増えました。そのほとんどは停車中に生じています。今回のモデルでも実際の受信機と同じく、駐車中のバンの報告位置は毎秒1 m近く揺れ、その揺れのたびに距離が加算されます。最も影響が大きかったのは、大半の時間を駐車して過ごすサービスルートで、リヨンのルートは35%長く出ました。

前の位置から15 m以内にとどまる送信点を除外すると、誤差は半分の8.2%になります。マップマッチングを使うと誤差の大部分が消え、1.9%になります。車両が縁石に沿って行ったり来たりすることはできないからです。

送信がまばらだと曲がり角を省略します

2分に1回の送信では、配送バンは2回の報告の間に市街地で約1 km、環状道路では数kmを走ります。その点を直線で結ぶと、すべての曲がり角と迂回路を省略することになり、走行距離は17.9%短く出ました。

マップマッチングは送信点の間を実際の道路に沿ってルーティングするため、誤差の大部分を取り戻し、全ルート合計で2.7%短い程度に収まりました。ただし、ルート単位で見ると結果は厳しくなります。送信間隔が2分あると、マッチング処理は経路を推測するしかなく、その推測はウィーンの23.8%短いものからパリの19.2%長いものまで幅がありました。60秒間隔ではすべてのルートが3.7%以内、15秒から30秒間隔では1.7%以内でした。

2分間隔では停車が消えます

60秒間隔までは、停車検出器は100か所のうち99か所を見つけました。見逃した1か所は13 m離れたミラノの2か所の停車地で、どの間隔でも区別できません。隣り合う2軒への荷物は、バックエンドからは1か所の停車に見えます。

2分間隔では、84か所の荷物配送の停車のうち24か所が消えました。玄関先での3分間の配達では、送信点は多くても1つか2つしか残らず、その両方がバンの到着中や出発後に記録されることもよくあります。15分以上の訪問16件は、すべての間隔で検出されました。

動態管理を開発・導入するチームにとっての意味

• マップマッチングはサーバー側で行ってください。 同じ送信点のままで、16%の過大計上と18%の過小計上が、2.7%以下の誤差になりました。生のGPS点から計算した走行距離は、今回試したどの間隔でも、請求や税務用の走行記録には使えません。
• 走行中は5秒から30秒ごとに送信してください。 今回のテストでは、この範囲でマッチング後のすべてのルートが2.7%以内に収まり、停車検出器は100か所のうち99か所を見つけました。送信数は1時間あたり120回から720回です。地図上のリアルタイム追跡や顧客向けのETAにはより短い間隔が必要になることがありますが、走行距離と停車にはこの範囲で足ります。
• 駐車中に毎秒送信するのはやめてください。 エンジン停止中は低頻度の死活通知に切り替えるか、距離を合計する前に駐車中の送信点を除外してください。駐車中の揺れは、テスト全体で最大の誤差要因でした。
• 玄関先への配達には2分間隔はまばらすぎます。 長時間の訪問サービスや、車両全体のおおよその走行距離には今も使えますが、短い停車を見逃し、個々のトリップの信頼性が下がります。
• 生の送信データは保存しておいてください。 来年より良いマッチング処理や停車ルールが出ても、適用できるのは保存してあるデータだけです。

テレマティクスに適用されるEUの規則

ドライバーの位置にはGDPR。 社用車の位置は、それを運転している人の個人データです。GDPR（EU一般データ保護規則）に関して、EUのデータ保護当局による職場でのデータ処理に関する意見書2/2017（WP249）は、安全確保や車両の所在確認といった正当な目的での車両追跡を認めています。一方で、雇用主はこれをドライバーの行動や居場所の追跡に使うべきではないこと、合意した勤務時間外の追跡には法的根拠がある可能性は低いこと、私用を認められたドライバーは原則として位置追跡を一時的にオフにできるべきことも示しています。実務では、目的の明示、プライバシースイッチ、製品内での保存期間の制限が必要になります。

プロのドライバーにはスマートタコグラフ。 規則（EU）No 165/2014は、EUの運転時間規則の対象となる3.5 tを超えるトラックに、運転時間と休憩時間を記録するタコグラフを義務付けています。規則（EU）2020/1054で改正された第2世代のスマートタコグラフは、勤務日の開始時と終了時、累積運転時間3時間ごと、国境を越えるたび、そして荷積みと荷下ろしのたびに車両の位置を記録します。2026年7月1日からは、国際貨物輸送に使う2.5 tを超えるバンにも搭載が必要です。テレマティクス端末はタコグラフをリモートでダウンロードすることが多く、上で触れたFMSインターフェースはそのためのものです。

すべての新型乗用車にeCall。 規則（EU）2015/758は、2018年3月31日以降に型式認証を受けた新型の乗用車と小型バンに、自動緊急通報システムを義務付けています。これは1つの役割に絞ったテレマティクスで、規則はその範囲を狭く保っています。システムは追跡可能であってはならず、常時追跡の対象にもならず、保持できるのは直近3つの位置だけで、衝突で起動したときに最小限のデータだけを送信します。委任規則（EU）2024/1180は、2Gと3Gのネットワークが停波するのに合わせてeCallを4Gと5Gのネットワークに移行させるもので、新しい基準は2026年1月1日から適用されています。

データの利用権にはデータ法。 2025年9月12日から、EUデータ法（Data Act）は車両を含むコネクテッド製品の利用者に、利用によって生じたデータへの権利を与えています。車両の位置にとっての意味は、位置データに関するデータ法の解説で説明しています。

企業がテレマティクスを使う目的

• 配送と物流： 停車記録による配達証明、顧客向けのリアルタイムETA、ラストワンマイル配送のルートでの計画と実績の比較。
• フィールドサービス： 訪問ごとの現場滞在時間、作業間の移動時間、新しい作業に最も近い技術者の特定。
• 走行距離と税務記録： トリップごとの距離と私用・業務用の区別。多くの税務当局が追跡端末の記録を認めています。
• 整備： 実際の走行距離とエンジン稼働時間に基づく整備間隔、CANバスからの故障コード。
• コンプライアンス： 運転時間と休憩時間、制限速度に対する走行速度、低排出ガスゾーンへの進入。
• 保険： 走行距離、時間帯、運転スタイルで保険料を決める利用ベースの保険。
• 安全： 衝突検知、単独作業者向けのアラーム、盗難車両の回収。

車両は地図を読み取る機械のひとつのグループにすぎません。ロボタクシーからドローンまで、ほかの機械については機械のための地図の概要で取り上げています。

APIでトレースをマップマッチングする

この実験のマップマッチングのステップは、トレース1つにつきリクエスト1回です。送信点をタイムスタンプ付きで送ると、レスポンスにはエンコード済みポリラインとしてのマッチング済みルート、属性付きの道路区間、信頼度スコアが含まれます。

curl -X POST "https://gateway.mapmetrics-atlas.net/map-matching/?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "shape": [
      {"lat": 52.35472, "lon": 4.89402, "time": 0},
      {"lat": 52.35503, "lon": 4.89751, "time": 30},
      {"lat": 52.35801, "lon": 4.90098, "time": 60}
    ],
    "costing": "auto",
    "shape_match": "map_snap"
  }'

走行距離には、返されたshapeの長さを測ってください。離れた2つの送信点をマッチング処理がつなげない場合は、直線を引く代わりにDirections APIでその間をルーティングしてください。今回の実験でもそうしました。

手法と限界

• ルート： MapAtlas Directions API、costing auto、2026年10月2日。出発時刻を指定していないため、リアルタイムの交通状況は反映していません。停車地は各区域の中心周辺にシード付き乱数で配置した点で、ルーターが最寄りの走行可能な道路にスナップし、最近傍順に訪問しています。ルート上の距離を実際の走行距離としています。
• シミュレーションの追跡端末： 位置誤差は1次のガウス・マルコフ過程で、各軸3 m、相関時間60秒、さらに30 mの外れ値を1%加えています。実際の受信機はアンテナ、取り付け方、周囲の環境によって異なり、多くは独自のフィルタリングを行います。たとえば一定速度以下で位置を固定するものがあります。各道路区間内の速度は一定とし、信号や渋滞は含めていません。
• マップマッチング： MapAtlas Map Matching API、costing auto、shape_match map_snap。送信点はタイムスタンプ付きで、最大1,500点ずつに分けて送りました。マッチング結果のうち、マッチング処理が2つの送信点をつなげずに500 mを超えて直線で飛んでいる箇所は、両端の間のDirectionsルートに置き換えました。
• 停車： 50 m以内にとどまる連続した送信点が60秒以上続いたものを停車とし、間隔が2分未満かつ50 m未満の停車は統合しました。検出した停車が100 m以内にあり、時間的に重なっている場合に、実際の停車を検出したと数えています。
• この実験で測定していないもの： ETAの精度、リアルタイム追跡の遅延、車両1台あたりの通信コスト、携帯電話網の圏外エリア。

スクリプトは調査アーカイブの scripts/seo/blog-keyword-research/what-is-telematics.mjs にあり、生の結果は docs/blog-keyword-research/what-is-telematics-2026-10-02.json にあります。

関連記事

マッチングのステップを支えるアルゴリズムについては、マップマッチングとはをお読みください。稼働中の車両を地図に表示するには、ドライバーのリアルタイム追跡チュートリアルに沿って進めてください。ここで使ったMap Matching APIとDirections APIはEU域内でホストされたインフラで動作しているため、ドライバーの位置がマッチング処理に送られる途中でEUの外に出ることはありません。