カーナビは渋滞をどうやって知るのか？ Google マップ・リアルタイム渋滞情報の仕組み
仕事帰りの運転中に、カーナビが突然ルートの変更を提案してきます。ラジオの交通情報にはまだ事故のニュースが流れていないのに、ナビはすでに数キロ先の道路が混み始めたことを知っています。全国の道路にカメラが隙間なく設置されているわけでもなく、誰かが一件ずつ電話で知らせてくれるわけでもないのに、どうやって知るのでしょうか。この記事では、Google マップや Yahoo!カーナビのようなナビアプリがリアルタイムの渋滞情報を作り出す仕組みを、コードなしで整理します。
地図がどうやって画面に表示され、自分の位置が青い点でどう示されるのかは 地図と現在地の仕組みを扱った記事 で説明しました。今回はその次の段階です。自分の位置を知ることと、道路全体の状況を知ることは、まったく別の問題だからです。
ナビを起動した車たちが、そのまま速度センサーです #
答えから言うと、渋滞情報の最大の出どころは道路の上を走る車たち自身です。ナビアプリを起動して走る車は、数秒ごとに自分の位置と速度をサーバーへ送っています。ルート案内を受けるにはどのみち自分の位置を伝え続ける必要があり、そのデータが同時に道路状況を測る材料としても使われているわけです。こうして集まるデータを プローブデータ と呼びます。プローブ(探針)という名前のとおり、車の一台一台が道路のあちこちに挿さった匿名の温度計の役割を果たしているわけです。
車一台のデータだけでは判断できません。その車が遅いのは渋滞のせいなのか、運転者がもともとゆっくり走る人なのか、区別がつかないからです。けれども、同じ道路を走る数百台、数万台のデータが集まると話が変わります。ある区間を通る車たちの速度が一斉に時速 20km まで落ちたなら、それは運転の癖ではなく道路の状態です。
赤い線の正体は区間平均です #
サーバーは道路を短い区間単位に切って管理しています。交差点から次の交差点まで、インターチェンジから次のインターチェンジまでが一区間です。各区間について、直近数分の間に通過した車たちの速度を平均すると、それがその区間の現在の速度になります。地図の上の緑・オレンジ・赤の線は、この区間速度を色に置き換えたものです。制限速度に近い流れなら緑、半分ほどならオレンジ、ほぼ止まっていれば赤、という具合です。
個々の車ではなく区間が単位だという点が重要です。誰が通ったのかは色を決めるのに必要なく、何台がどんな速度で通ったのかだけが必要です。限界も同じ構造から生まれます。車がほとんど通らない深夜の閑散とした道は標本が足りず、情報が空白になるか過去の統計で埋められます。ナビが大通りの渋滞はよく当てるのに、路地の状況には鈍い理由です。
到着予想時刻は「距離÷速度」ではありません #
残りの距離を今の速度で割れば到着時刻が出そうですが、そう計算すると頻繁に外れます。自分が 30 分後に通る道路の状況は、今とは違うからです。今は空いていても帰宅ラッシュが重なれば混む道があり、今は赤くても 30 分後には解消している道があります。
そこで、到着予想時刻には予測が入ります。材料は二つです。一つは過去のパターンです。この道路の火曜日午後 6 時の速度がこの数か月どうだったかは、すでに統計として蓄積されています。もう一つはリアルタイムの変化です。今日がいつもと違う流れになっているなら、過去のパターンをその分だけ補正します。運転中に到着予想時刻が数分ずつ伸びたり縮んだりするのは、計算が雑だからではなく、この予測が新しく入ってくるリアルタイムデータで絶えず修正されているからです。
ルート検索は電車の乗り換え案内と同じ問題です #
いよいよルートを選ぶ番です。ルート検索は、電車の乗り換え案内を思い浮かべると理解しやすくなります。駅と駅の間ごとにかかる時間が決まっていて、出発駅から到着駅までその時間の合計が最も小さい組み合わせを選ぶ問題です。乗り換えの回数が多くても、合計が小さければそのルートが勝ちます。
道路も同じです。交差点が駅で、交差点の間の道路が路線です。違う点は一つだけです。区間ごとに書かれた数字が固定された距離ではなく、先ほど見た区間速度から計算した「今そこを通過するのにかかる時間」だという点です。だからナビが選ぶ道は最短距離ではなく最短時間で、混んでいる直線の大通りより空いている迂回路が勝つことがあります。どこかの区間が赤く変わって数字が大きくなり、合計がより小さい別の組み合わせが生まれた瞬間、ナビはルートを乗り換えます。運転中に案内が突然変わるのが、まさにこの瞬間です。
全員に同じ迂回路を案内すると、その道が混みます #
ここには面白い逆説が一つあります。数十万人が同じアプリを使っているのに、事故が起きた道路のすべての運転者に同じ迂回路を案内すると、今度はその迂回路が渋滞します。渋滞が消えるのではなく、隣の道へ移るだけです。
そこで各サービスは、迂回する車を一本の道に集中させず複数のルートに分けて案内したり、迂回路へ抜けた車たちが送ってくるプローブデータを改めて見ながら、その道が混み始めたら案内を減らしたりします。渋滞情報は一方向の放送ではなく循環です。案内が道路状況を変え、変わった状況がまた案内に反映されます。
事故や通行止めは二つの経路で入ってきます #
普段のパターンでは説明できない突発的な事故や通行止めは、二つの方法で捉えます。一つは利用者からの報告です。ナビアプリの事故報告ボタンを押したり、警察や道路管理者が規制情報を送ってくれたりする経路です。もう一つは、データ自身が発する信号です。普段は時速 80km で流れていた区間が数分のうちに 10km まで落ちたなら、報告が一件もなくても何かが起きたという意味です。
二つは互いを補い合います。報告は速いものの、いたずらや勘違いが混ざる可能性があり、速度急落の検知は確実なものの、車が実際に遅くなった後でしか捉えられません。そこで、報告が入るとその区間の速度データで事実かどうかを確認し、速度が急落すれば報告がなくても渋滞として表示する、という形で二つを組み合わせて使います。
個々の車を追跡しているわけではありません #
自分の位置と速度がサーバーへ送られ続けるという説明に、不安を覚えたかもしれません。そのため交通情報システムは、データを二段階で加工します。収集の段階では誰が送ったデータか分からないように識別情報を取り除き、活用の段階では区間平均という集計値だけを残します。地図の赤い線には、どの車がそこにいたのかという情報は残っていません。
もちろん、位置の記録そのものが取り扱いに注意の要る個人情報だという事実は変わりません。アプリが位置情報の許可を求める理由、そして収集と活用の原則が重要である理由は、地図と位置情報を扱った記事で説明したとおりです。
まとめ #
整理するとこうなります。ナビを起動した車たちが送る位置と速度がプローブデータになり、道路の区間単位で平均すると緑と赤の色つきの線になります。そこに過去のパターンを合わせると到着予想時刻になり、区間ごとにかかる時間を重みにした探索がルートになります。案内そのものが道路状況を変えるため迂回は分散され、事故は報告と速度急落の検知が一緒に捉えます。次にナビが静かな路地へ案内してきたとき、その案内の裏には、同じ道を少し先に通った数万台の車が残したデータがあることを思い出してみてください。