JP7485080B2 - 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム - Google Patents

Description

開示の技術は、渋滞判定方法、渋滞判定装置、及び渋滞判定プログラムに関する。

画像を用いて渋滞の推定を行う試みは古くからなされている。例えば、固定カメラで撮影された画像を用いて車両の挙動を推定する技術がある（例えば非特許文献１参照）。

車両の挙動を利用することで渋滞の発生個所を推定できる可能性がある。しかしながら広範な範囲を対象としようとする場合、多くのカメラを設置する必要があり、カメラから画像の処理を行うための演算装置まで画像若しくは符号化データを伝送する必要もある。

また、単に画像を処理するだけでは渋滞が発生していることや渋滞の発生要因を推定することができても、推定した事項を適切なユーザに適切な通知をすることは難しい。ここでいう適切なユーザとは、例えば慢性的に渋滞が発生するエリアが生活圏内であるユーザであり、適切な通知とは、突発的な渋滞の発生の通知である。すなわち、慢性的に渋滞が発生するエリアが生活圏内であるユーザに対しては慢性的な渋滞の発生を通知する必要はなく、突発的な渋滞の発生のみ通知することが好ましい。

"都市高速道路における画像解析手法を用いた渋滞発生メカニズムの詳細分析", http://www.ce.it-chiba.ac.jp/atrans/ronbun/akahane/2007/2007%20tosi%20kousokudouro.pdf

開示の技術は、上記の点に鑑みてなされたものであり、発生した渋滞が突発的か否かを判定することができる渋滞判定方法、渋滞判定装置、及び渋滞判定プログラムを提供することを目的とする。

上記目的を達成するために、本開示の一態様に係る渋滞判定方法は、取得部及び判定部を備えた渋滞判定装置における渋滞判定方法であって、前記取得部が、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、前記判定部が、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する。

更に、上記目的を達成するために、本開示の一態様に係る渋滞判定装置は、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する取得部と、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する判定部と、を備える。

更に、上記目的を達成するために、本開示の一態様に係る渋滞判定プログラムは、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定することをコンピュータに実行させる。

開示の技術によれば、発生した渋滞が突発的か否かを判定することができる。

場所毎の訪問確率の一例を示す図である。 第１実施形態に係る渋滞判定装置のハードウェア構成の一例を示すブロック図である。 第１実施形態に係る渋滞判定装置の機能構成の一例を示すブロック図である。 場所毎の集計台数の一例を示す図である。 第１実施形態に係る渋滞判定処理のフローチャートである。 第２実施形態に係る渋滞判定装置の機能構成の一例を示すブロック図である。 第２実施形態に係る渋滞判定処理のフローチャートである。 ＧＰＳログデータの時間帯の偏りを表すグラフである。 ＧＰＳログデータの曜日の偏りを表すグラフである。 メッシュ毎のログデータの数を表すログ数のグラフである。 タクシーのＧＰＳログデータに対してＲＢＭを適用した結果を示す図である。 慢性的に通行された場所を示す図である。 習慣度が高かった場所の曜日及び時間帯の偏りを表すグラフである。 ＳＩＣＭで算出した集計突発指標の分布を示す図である。 集計突発指標が最も高かった３か所について、集計突発指標及びログ数の変遷をプロットした図である。 集計突発指標が１．０以上であった１６０箇所について、算出された集計突発指標を８段階にレベル分けして地図上にプロットした図である。 動的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示す図である。 静的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示す図である。 後半３３日間のＧＰＳログデータを用いて算出した集計突発指標が閾値以上のメッシュについてＲＢＭを用いて渋滞習慣度を算出した結果を示す図である。 お台場において検知された１５個の渋滞に対して、渋滞を１回検出する毎にＳＲＢＭにより算出した重み付き習慣度と、１５個の渋滞全てを検知した後にＲＢＭにより算出した渋滞習慣度と、の相関係数を全メッシュについて算出した結果を示す図である。 重み付き渋滞習慣度を算出した際の重みの変化を示す図である。

以下、開示の技術の実施形態の一例を、図面を参照しつつ説明する。なお、各図面において、同一又は等価な構成要素及び部分には同一の参照符号を付与している。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。

＜渋滞検知の概要＞

車道で発生する渋滞の中には施設の入口や信号待ち等の理由により特定車線でのみ発生するものがある。このような渋滞が発生している際に、渋滞の末尾の位置からは先頭位置が見えず、その渋滞に自車が並ぶべきか、別車線から追い越してもよいかが分からないケースが発生する。このようなケースが増加すると、目的地までの所要時間が増加したり、無駄な混雑が発生したりするという問題がある。

このような問題を解決するため、車載カメラで撮影された撮影画像（例えば動画像）の撮影画像データ及びＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）による位置情報を用いて、道路上の特定車線における自動車の渋滞発生位置（先頭及び末尾）を推定し、運転者にその情報を通知することが考えられるが、以下のような問題がある。

（１）撮影画像データを使用するため、渋滞発生位置を推定する際の計算コストが高くなる。また、一般車から撮影画像データをサーバにアップロードする通信コストも高くなる。

（２）自動車を運転するユーザに渋滞が発生していることを通知する場合、慢性的に渋滞が発生するエリアが生活圏内とするユーザに対しても繰り返し通知してしまうため、不要な通知の回数が増加し、ユーザの満足度が低くなる可能性がある。

上記（１）の問題に対しては、撮影画像データを用いて渋滞発生位置を推定するエリアを、突発的な渋滞が発生しているエリアに限定することが考えられる。これにより、例えば施設の入口等のように繰り返し同じ原因で渋滞が発生するエリアに対しては渋滞発生位置を推定する処理を省略することで計算コストを抑えることができる。

上記（２）の問題に対しては、渋滞が発生しているエリアが生活圏内であるユーザに対しては、慢性的な渋滞の発生については通知せず、突発的な渋滞の発生についてのみ通知することにより、ユーザの満足度が向上すると考えられる。

レーン別渋滞には周期的に発生するレーン別渋滞と突発的に発生するレーン別渋滞がある。周期的に発生する渋滞には特定の曜日や時間帯に繰り返し発生する等の時間依存性があると考えられている。特定の曜日に発生することが多いが時間帯は必ずしも偏っていない渋滞、特定の時間帯に発生することが多いが曜日に偏りはなく毎日発生する渋滞、曜日や時間帯依存性がなく常に発生する渋滞等、発生する渋滞が、どの時間軸に強く依存するかは渋滞が発生する場所によって異なる。例えば、幹線道路の右左折レーンの渋滞は朝夕のラッシュ時に起きやすい、商業施設への入庫待ちは土日祝日に起きやすい、高速道路と一般道路の合流レーンの渋滞は常時、信号周期起因等で起きやすいなどの周期性があり、これらは周期性から予測可能であるといえる。一方、突発的に発生するレーン別渋滞には、事故や故障者等車線をふさぐ障害が発生しているもの、商業施設のバーゲンや新規開店などイベント起因のもの、コロナ禍によるドライブスルー特需など日常習慣の変化によるものなどがある。これらは予測不能かつ事故誘発可能性が高いため、複数の自動車から重点的に映像等の撮影画像データを収集して分析する必要があり、また、渋滞が発生しているエリアが生活圏内であるユーザに対しても渋滞の発生を通知する必要がある。従って、曜日や時間帯等の様々な時間軸を総合的に考慮した上で、発生した渋滞が突発的であるか慢性的であるかを指標化する必要がある。この時、指標は時間軸別に求めるのではなく、どの渋滞の撮影画像データを収集すべきかを判断できるように一元化する必要がある。加えて、渋滞情報はなるべくリアルタイムに通知する必要があるため、渋滞の慢性／突発性の判定も高速に実施する必要があり、Ａｕｔｏ Ｅｎｃｏｒｄｅｒなどの複雑なモデルを用いた異常値検出を適用することは難しい。

曜日や時間帯等の複数の時間軸を同時に考慮して、発生した事象が突発的であるか慢性的であるかを高速に一元化された形で指標化する方法として、下記特許文献１、２に開示の技術がある。

（特許文献１）特開２０１５－１５３０８８号公報
（特許文献２）特開２０１６－９１０４０号公報

特許文献１に開示された技術では、ユーザの位置情報を用いて、或る訪問場所への訪問がどの程度突発的であるか慢性的であるかを、複数の時間軸を総合的に考慮して指標化した「習慣度」を算出する。

特許文献１に開示された技術を、渋滞検知における上記（１）、（２）の問題点の対応のために適用すると、それぞれ以下のような問題がある。

まず、上記（１）に関する問題について説明する。

上記特許文献１に開示された技術は、元々人間の行動を対象としていることもあり、訪問に付随する指標ではなく、訪問があったという事象そのものに対する指標を習慣度として算出している。具体的には、特定のユーザに限定して場所別の訪問確率を算出し、その中で習慣度を算出したい訪問場所の訪問確率が他の場所の訪問確率に比べてどの程度突発的であるかを習慣度として算出している。

図１に、特許文献１に開示の技術で算出される場所毎の訪問確率の一例を示す。また、特許文献１に開示された習慣度Ｒ（ｌ，ｕ，ｔ）を算出する式は次式で表される。

・・・（１）

ここで、ｋは、曜日（ｋ＝１）、時間帯（ｋ＝２）、曜日及び時間帯（ｋ＝３）、時間考慮無し（ｋ＝４）の時間軸の種類を示すパラメータである。

ｔ_ｋは、習慣度の算出対象の時間帯を示す。例えば、ｋ＝２であり、習慣度の算出対象の時間帯が１３時台の場合には、ｔ_２＝１３と表される。

Ｐ（ｌ｜ｕ，ｔ_ｋ）は、時間帯ｔ_ｋにおけるユーザｕの場所ｌへの訪問確率である。場所ｌは、本実施形態では渋滞の判定対象領域を仮想的に分割したメッシュをいうので、以下ではメッシュｌと称する。メッシュは、例えば縦横が１００ｍの正方形の領域とすることができるが、メッシュのサイズ及び形状はこれに限られるものではない。

なお、Ｐ（ｌ｜ｕ，ｔ_ｋ）に関して次式が成り立つ。

ω（ｕ，ｔ_ｋ）は、ユーザｕについての時間帯ｔ_ｋの重みである。

μ（ｕ，ｔ_ｋ）は、時間軸ｋ、時間帯ｔ_ｋのユーザｕの全メッシュに対する訪問確率の平均である。

σ（ｕ，ｔ_ｋ）は、時間軸ｋ、時間帯ｔ_ｋのユーザｕの全メッシュに対する訪問確率の標準偏差である。

これに対し、渋滞検知の場合には、或る１台の自動車が特定のメッシュを訪問したという事象ではなく、特定のメッシュにおいて存在が検知された自動車の単位時間当たりの集計台数に対して突発的か否かを指標化する必要がある。

特許文献１では、訪問場所に対する「訪問確率」が他の場所に比べてどの程度突発的であるかを示す指標として習慣度を算出しているが、渋滞検知では、同じメッシュのこれまでの「集計台数」に比べて、指標を算出したい時間軸における集計台数がどの程度突発的に多くなっているかを表す指標を算出する必要がある。従って、特許文献１に開示の技術をそのまま適用することはできない。

特許文献１では、各時間軸において算出した習慣度を適切な比重で重み付けすることで総合的な習慣度を算出している。この重みω（ｕ，ｔ_ｋ）は、ユーザｕが同じ時間帯に他の場所を含めてどの程度の訪問数を記録しているかが考慮された次式により算出される。

・・・（２）

ここで、Ｎ（ｕ，ｔ_ｋ）は、時間帯ｔ_ｋにおけるユーザｕによる全場所の訪問回数の合計値である。

は、ユーザｕが時間軸ｋの全時間帯の中で最も多く訪問を記録した時間帯ｔ_ｋ’における全場所の訪問回数の合計値である。

渋滞検知においては、ユーザｕに関係無く、集計台数がどの程度突発的に多くなっているかを表す指標を算出したいことから、上記（２）式をそのまま用いることはできない。以下、渋滞検知において集計台数の突発度合いを示す指標を集計突発指標又はＳＩＣＭ（Ｓｕｄｄｅｎｎｅｓｓ Ｉｎｄｅｘ Ｃａｌｃｕｌａｔｉｏｎ Ｍｅｔｈｏｄ）と呼ぶ。また、広範囲の場所に対して集計突発指標を算出する場合、集計突発指標自体の計算コストを抑える必要がある中で、上記（２）式のように、全場所の訪問回数を算出することは、メッシュ毎に独立して集計突発指標を算出できなくなるため避ける必要がある。

上記特許文献２に開示の技術では、或る事象が存在した時に、その事象のこれまでの発生回数及び発生確率に基づいて複数の時間軸における習慣度を算出する。これについても、「集計台数」のような数の大小に基づく習慣性ではなく、事象発生そのものの確率をユーザ毎に算出しているため、集計突発指標のような集計値の突発度合いを算出するという目的で用いることはできない。

次に、上記（２）に関する問題について説明する。

ユーザへの渋滞発生の通知の有無を判定するために、発生した渋滞が突発的であるか慢性的であるかを判定する場合、渋滞が発生したという事象そのものに対する習慣度を算出すればよいため、特許文献１に開示された技術の適用が考えられる。

上記（１）においては、渋滞が発生したかどうかを検出する前に、集計台数から集計突発指標を算出する必要があるが、上記（２）においては、渋滞を公知の方法で検出した後で、その渋滞が突発的であるか慢性的であるかを判定すればよいためである。

しかしながら、実際は車線別の渋滞検知は計算コスト等が高コストであること、渋滞検知結果のサンプル数が少ない初期段階では、算出される習慣度の精度が問題となる。

以上より、第１実施形態では、上記（１）の問題を解決するため、各メッシュで集計した集計台数に基づいて集計突発指標をメッシュ毎に算出する。これにより、その後の処理である渋滞が発生しているエリアに存在する自動車によって撮影された撮影画像データの取得及び撮影画像データの解析による渋滞検知の処理を簡略化することができる。

また、第２実施形態では、上記（２）の問題を解決するため、発生した渋滞が突発的であるか慢性的であるかを習慣度として算出するが、渋滞検知のために取得したログデータの数が少ない初期の段階では、タクシー等の過去のＧＰＳログデータや、レーン別のデータは存在しないが道路及び区間別の過去の渋滞履歴なども考慮して習慣度を算出する。そして、慢性的な渋滞の発生については、渋滞が発生しているエリアを生活圏としているユーザに対しては通知せず、渋滞が発生しているエリアが生活圏外であるユーザに対してのみ通知する。このように、発生している渋滞が突発的であるか慢性的であるかに応じて、渋滞発生の通知対象を切り替えてもよい。

＜第１実施形態＞

図２は、本実施形態に係る渋滞判定装置１０のハードウェア構成の一例を示すブロック図である。

図２に示すように、渋滞判定装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ストレージ１４、入力部１５、表示部１６、及び通信インタフェース（Ｉ／Ｆ）１７を備えている。各構成は、バス１８を介して相互に通信可能に接続されている。

ＣＰＵ１１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４からプログラムを読み出し、ＲＡＭ１３を作業領域としてプログラムを実行する。ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４に記憶されているプログラムに従って、上記各構成の制御及び各種の演算処理を行う。本実施形態では、ＲＯＭ１２又はストレージ１４には、渋滞が突発的か否かを判定するための渋滞判定プログラムが格納されている。

ＲＯＭ１２は、各種プログラム及び各種データを格納する。ＲＡＭ１３は、作業領域として一時的にプログラム又はデータを記憶する。ストレージ１４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により構成され、オペレーティングシステムを含む各種プログラム、及び各種データを格納する。

入力部１５は、マウス等のポインティングデバイス、及びキーボードを含み、自装置に対して各種の入力を行うために使用される。

表示部１６は、例えば、液晶ディスプレイであり、各種の情報を表示する。表示部１６は、タッチパネル方式を採用して、入力部１５として機能しても良い。

通信インタフェース１７は、自装置が他の外部機器と通信するためのインタフェースである。当該通信には、例えば、イーサネット（登録商標）若しくはＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）等の有線通信の規格、又は、４Ｇ、５Ｇ、若しくはＷｉ－Ｆｉ（登録商標）等の無線通信の規格が用いられる。

本実施形態に係る渋滞判定装置１０には、例えば、サーバコンピュータ、パーソナルコンピュータ（ＰＣ：Personal Computer）等の汎用的なコンピュータ装置が適用される。

次に、図３を参照して、渋滞判定装置１０の機能構成について説明する。

図３は、本実施形態に係る渋滞判定装置１０の機能構成の一例を示すブロック図である。

図３に示すように、渋滞判定装置１０は、機能構成として、取得部２１、判定部２２、及び通知部２３を備えている。各機能構成は、ＣＰＵ１１がＲＯＭ１２又はストレージ１４に記憶された渋滞判定プログラムを読み出し、ＲＡＭ１３に展開して実行することにより実現される。

取得部２１は、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する。集計台数は、サーバ３０が備えるログデータベース３１から取得する。

ログデータベース３１は、メッシュを表す識別符号であるメッシュＩＤ、日時、曜日、メッシュ内で集計された自動車の集計台数の対応関係を表すデータベースである。

サーバ３０は、渋滞の判定対象領域を走行するコネクテッドカー等のＧＰＳ装置及びインターネットへの接続機能を備えた自動車から送信された自車位置情報（緯度経度）を収集し、ログデータベース３１を逐次更新する。なお、サーバ３０の機能を渋滞判定装置１０が備えても良い。また、サーバ３０は、衛星画像を取得して画像解析することにより、メッシュ毎に自動車の台数を集計し、ログデータベース３１を逐次更新してもよい。

サーバ３０は、コネクテッドカーから受信した自車位置情報が表す緯度経度をメッシュＩＤに変換して、メッシュＩＤ毎及び単位時間毎に自動車の集計台数を集計する。そして、メッシュＩＤ、集計台数、日時、曜日の情報をログデータベース３１に登録する。サーバ３０は、ログデータベース３１を逐次更新する。なお、単位時間は、例えば１０秒等に設定できるが、これに限られるものではない。

日時は、例えば「ＹＹＹＹ／ｍｍ／ｄｄ ＨＨ：ＭＭ：ＳＳ」のように表される。ここで、「ＹＹＹＹ」は年を表し、「ｍｍ」は月を表し、「ｄｄ」は日を表し、「ＨＨ」は時間を表し、「ＭＭ」は分を表し、「ＳＳ」は秒を表す。また、曜日は例えば月曜日から日曜日までを「０」～「６」で表す。

また、メッシュのサイズ及び形状は、例えば１００ｍ×１００ｍの正方形とすることができるが、これに限られるものではない。

なお、集計台数は、コネクテッドカーから収集した自車位置情報に基づいて集計するのではなく、道路上に設置されたビーコンで検出された自動車の数に基づいて集計してもよい。

判定部２２は、取得したメッシュ毎及び単位時間毎の集計台数に基づいて、渋滞の発生が突発的か否かをメッシュ毎に判定する。具体的には、判定部２２は、メッシュ毎及び単位時間毎の集計台数に基づいて集計突発指標を算出し、算出した集計突発指標に基づいて渋滞の発生が突発的か否かを判定する。

通知部２３は、渋滞の発生をユーザに通知する。

以下、集計突発指標について説明する。

渋滞検知においては、自動車の集計台数が通常に比べて突発的に多くなっているか否かを判定するために、訪問確率ではなく集計台数に基づく集計突発指標を定義する。集計突発指標Ｒ（ｌ，ｔ）は、次式により定義される。

・・・（３）

ここで、ｔ_ｋは、集計突発指標Ｒ（ｌ，ｔ）の算出対象の時間軸ｋで分類した時の時間帯や曜日などの時間情報を示す。例えば、ｋ＝２であり、集計突発指標Ｒ（ｌ，ｔ）の算出対象の時間帯が１３時台の場合には、ｔ_２＝１３と表される。

Ｃ（ｌ，ｔ）は、集計突発指標Ｒ（ｌ，ｔ）を算出したいメッシュｌの日時ｔにおける集計台数を表す。図４に、場所毎に算出した集計台数Ｃ（ｌ，ｔ）の一例を示す。

μ（ｔ_ｋ，ｌ）は、メッシュｌについての日時ｔが含まれる時間軸ｋにおける集計台数の平均を表す。例えば、日時ｔが１３時３分であり、ｋ＝２であった場合、ｔ_２＝１３である。従って、μ（ｔ_２，ｌ）は、メッシュｌの１３時台の集計台数の平均を表す。

同様に、σ（ｔ_ｋ，ｌ）は、日時ｔが含まれる時間軸ｋにおける集計台数の標準偏差を表す。

ω（ｔ_ｋ、ｌ）は、メッシュｌについての時間軸ｋの時間帯ｔ_ｋにおける重みであり、次式で表される。

・・・（４）

ここで、Ｔ（ｔ_ｋ，ｌ）は、時間帯ｔ_ｋにおけるメッシュｌの集計台数の集計回数を示す。

は、メッシュｌについて時間帯ｔ_ｋの全時間軸の中で最も多く集計された時間帯ｔ’_ｋにおける集計回数を表す。このように、集計回数が多い時間軸ほど重みが大きくなる。

また、ωは時間軸の信頼度を示す。なお、集計回数の時間帯や曜日によるばらつきが少なく、１日を通して常に１台以上は車両が存在するようなデータを用いる際には、集計回数をカウントする台数に閾値を設けることも考えられる。例えば、閾値を１０台以上とする場合、１０台以上の集計結果を得た回数をＴ（ｔ_ｋ，ｌ）に格納する。集計突発指標を算出したい時間帯ｔ_ｋにおいて、ある程度混雑発生時の学習回数が多い時間軸の信頼度を高くして、最終的な集計突発指標の算出時に強く考慮することが可能となる。単なる集計結果に比べて混雑発生時の集計結果はサンプル数が少ないため、周期的な混雑発生を学習できている時間軸の信頼度を強くすることで、様々な粒度の時間軸のうち、信頼できる時間軸で算出された突発指標の値を強く考慮できる。粒度の異なる複数の時間軸を用意して、それぞれから算出された集計突発指標の重み付き線形和を出力することにより、混雑発生時の学習が不十分でも一元化された指標を用いた突発度合いの判定が可能になる。特にコネクテッドカーの普及初期においては、混雑発生時にコネクテッドカーの割合が低いと正しく周期的混雑が判別できない場合があるため、本開示ではそのような場合においても、学習データが少なければより粗い時間軸を採用することで突発度合いを出力することができる。例えば曜日および時間帯を考慮した「月曜日１３時台」のような時間軸に比べ、曜日だけを考慮した時間軸は粗い時間軸と言える。

上記（１）式と異なり、集計突発指標Ｒ（ｌ，ｔ）の算出に用いる上記の値は全てのユーザｕを考慮しない値であり、ユーザに関係なく、単位時間当たりに同一場所で検知された自動車の台数に関する値となっている。

なお、上記（４）式に示すように、重みω（ｔ_ｋ，ｌ）は上記（２）式と異なり全メッシュｌを考慮しなくてよいため、集計突発指標Ｒ（ｌ，ｔ）の算出をメッシュｌ毎に独立して行うことができる。このため、渋滞検知のように多くの場所で集計突発指標を算出する必要がある場合、計算コストを削減することができる。

上記（３）式より、集計台数Ｃ（ｌ，ｔ）が、集計台数の平均μ（ｔ_ｋ，ｌ）より大きい場合は、集計突発指標Ｒ（ｌ，ｔ）は０より大きい値となり、平均μ（ｔ_ｋ，ｌ）との差が大きいほど集計突発指標Ｒ（ｌ，ｔ）の値も大きくなる。また、集計台数Ｃ（ｌ，ｔ）のばらつきを表す標準偏差σ（ｔ_ｋ，ｌ）が大きい場合は、集計台数Ｃ（ｌ，ｔ）が平均μ（ｔ_ｋ，ｌ）と比べて大きかったとしても、集計突発指標Ｃ（ｌ，ｔ）はそれほど大きくならないが、標準偏差σ（ｔ_ｋ，ｌ）が小さく、集計台数Ｃ（ｌ，ｔ）が集計台数の平均μ（ｔ_ｋ，ｌ）よりも大きい場合は、集計突発指標Ｒ（ｌ，ｔ）は大きくなる。

次に、図５を参照して、本実施形態に係る渋滞判定装置１０の作用について説明する。

図５は、本実施形態に係る渋滞判定プログラムによる渋滞判定処理の流れの一例を示すフローチャートである。渋滞判定プログラムによる渋滞判定の処理は、渋滞判定装置１０のＣＰＵ１１が、ＲＯＭ１２又はストレージ１４に記憶されている渋滞判定プログラムをＲＡＭ１３に書き込んで実行することにより、実現される。

ステップＳ１００では、ＣＰＵ１１が、ログデータベース３１からメッシュｌ毎及び単位時間毎の集計台数Ｃ（ｌ，ｔ）を取得する。

ステップＳ１０２では、ＣＰＵ１１が、集計台数の平均μ（ｔ_ｋ，ｌ）及び標準偏差σ（ｔ_ｋ，ｌ）をメッシュｌ毎及び時間帯ｔ_ｋ毎に算出する。

ステップＳ１０４では、ＣＰＵ１１が、メッシュｌ毎及び時間帯ｔ_ｋ毎に重みω（ｔ_ｋ，ｌ）を算出する。具体的には、時間帯ｔ_ｋにおけるメッシュｌの集計台数の集計回数Ｔ（ｔ_ｋ，ｌ）を算出する。また、メッシュｌ毎に、時間帯ｔ_ｋの全時間軸の中で最も多く集計された時間帯ｔ’_ｋにおける集計回数

を算出する。そして、上記（４）式により、メッシュｌ毎及び時間帯ｔ_ｋ毎に重みω（ｔ_ｋ，ｌ）を算出する。

なお、ステップＳ１０２、Ｓ１０４の処理は、毎回実行しなくてもよい。例えば、予め定めた時間毎又は集計台数の取得を予め定めた回数実行する毎にステップＳ１０２、Ｓ１０４の処理を実行するようにしてもよい。

ステップＳ１０６では、ＣＰＵ１１が、ステップＳ１００～Ｓ１０４の算出結果に基づいて、上記（３）式によりメッシュｌ毎に現在時刻ｔにおける集計突発指標を算出する。

ステップＳ１０８では、ＣＰＵ１１が、ステップＳ１０６で算出した全てのメッシュｌの集計突発指標Ｒ（ｌ，ｔ）のうち、閾値以上のメッシュｌが有るか否か、すなわち、突発的な渋滞が発生しているメッシュｌが有るか否かを判定する。そして、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌが有る場合はステップＳ１１０へ移行し、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌが無い場合はステップＳ１００へ移行する。なお、閾値は、集計突発指標Ｒ（ｌ，ｔ）が閾値以上であれば、突発的な渋滞が発生している可能性が高いと考えられる値に予め設定される。

ステップＳ１１０では、ＣＰＵ１１が、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌ、すなわち突発的な渋滞が発生しているメッシュｌに存在する自動車から撮影画像データを取得する。撮影画像データは、サーバ３０経由で取得してもよいし、直接自動車から取得してもよい。なお、撮影画像データは、動画像でもよく静止画像でもよい。

ステップ１１２では、ＣＰＵ１１が、ステップＳ１１２で取得した撮影画像データを公知の解析手法を用いて解析して渋滞範囲を特定し、渋滞の先頭位置を特定する。渋滞の先頭位置を特定するのは、渋滞の先頭位置の撮影画像には、渋滞が発生している原因が記録されている可能性があるためである。なお、渋滞の先頭位置を特定するのは一例であり、これに限られない。すなわち、渋滞が発生している原因が記録されている可能性がある撮影画像を特定できればよく、例えば渋滞が発生している原因として車両の密度が変化する境界等を特定してもよい。車両の密度が変化する境界としては、例えば事故車の位置や工事現場等が挙げられる。

ステップＳ１１４では、ＣＰＵ１１が、ステップＳ１１２で特定した渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報をユーザに送信することにより通知する。これにより、ユーザは渋滞範囲の位置と共に渋滞発生の原因を認識することができる。なお、通知するユーザは全てのユーザでもよいし、突発的な渋滞が発生しているメッシュを中心とした予め定めたエリア内のユーザのみでもよい。予め定めたエリアは、例えば突発的な渋滞が発生しているメッシュを中心として半径数百メートル以内又は数キロメートル以内のエリアとすることができるが、これに限られるものではない。

このように、本実施形態では、メッシュｌ毎に集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌの撮影画像データのみを取得し、渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報をユーザに送信することにより通知する。これにより、撮影画像データの解析のための計算コストを抑えることができる。

なお、本実施形態では、集計突発指標Ｒ（ｌ，ｔ）が閾値未満のメッシュｌの撮影画像データを取得しない場合について説明したが、これに限られない。例えば、集計突発指標Ｒ（ｌ，ｔ）が大きくなるほど優先順位が高くなるように優先順位を付与し、集計突発指標Ｒ（ｌ，ｔ）が小さく、撮影画像データの取得の優先順位が低い場合でも、撮影画像データの解析等の処理に余裕がある場合には、撮影画像データを取得し、ステップＳ１１０～Ｓ１１４の処理を実行するようにしてもよい。

また、ステップＳ１０８の閾値については、予め定めた値を用いる場合について説明したが、これに限られない。例えば、ＲＯＣ（Ｒｅｃｅｉｖｅｒ Ｏｐｅｒａｔｉｎｇ Ｃｈａｒａｃｔｅｒｉｓｔｉｃ）カーブ等の手法を用いて閾値を自動で決定してもよい。この場合、集計突発指標Ｒ（ｌ，ｔ）に上限及び下限はないので、最大値を１．０、最小値を－１．０等のように正規化してもよい。これにより、閾値の決定を一般化することができる。

なお、本実施形態では、集計突発指標が閾値以上のメッシュが有る場合にユーザに通知する場合について説明したが、算出した集計突発指標を他の処理に用いても良い。例えば自動車のルート探索処理において、目的地までのルートを決定する際のパラメータの１つとして集計突発指標を用いてもよい。

また、自動車の集計台数に基づいて算出した集計突発指標を都市計画のための評価として用いてもよい。突発的に渋滞が発生した場所は、事故など突発的な原因で一時的な混雑を引き起こしている場合もあるが、新規道路や新規施設の開店などで新しく渋滞が発生するようになった場合もある。特に集計突発指標が一度大きくなってからやがて減少していくような場所は、道路状況の変化により新たに慢性的な渋滞を引き起こすような場所であるため、車線を増やす、車両整理のための人員を割くなどの対応が必要であると考えられる。

加えて集計突発指標の活用先は渋滞の評価に限られない。例えば人流の統計情報に対して適用させることで突発的に人が密になっている場所を検知し、人員整理の警察官をあてがう先の決定や人流の他の場所への誘導に使用することができる。また、ネットワークの伝送量に集計突発指標を適用すると、複数の時間軸を考慮した時に突発的に伝送量が増えたり減ったりする現象を抽出することができ、ネットワーク装置の故障検知にも役立つと考えられる。同様に電力消費量などにも適用が可能であり、例えば老人独居家庭で急激に消費量が増えた時には機械の誤動作を疑ったり、急激に減った時には体調の異変を疑ったりという活用も考えられる。このように複数の時間軸における周期性が想定されて、「量」を記録する時系列のログデータ全般に集計突発指標を適用することが可能であり、特に異常値を取った学習データが不足している場合に、指標の計算を広範囲に対して高速に行いたい時に効果を大きく発揮すると期待される。

＜第２実施形態＞

第２実施形態について説明する。なお、第１実施形態と同一部分には同一符号を付し、詳細な説明は省略する。

図６に示すように、第２実施形態に係る渋滞判定装置１０の機能構成は、第１実施形態で説明した図３に示す渋滞判定装置１０と同一構成であるが、各部の処理が異なる。まず、取得部２１が、サーバ３０から取得するデータの内容及び処理内容が異なる。

サーバ３０は、ログデータベース３１Ａ及び軌跡情報データベース３２を備える。

ログデータベース３１Ａは、第１実施形態で説明したログデータベース３１の内容に加えて、自車位置情報をサーバ３０へ送信した自動車を表すユーザｕを識別するためのユーザＩＤを含む。

軌跡情報データベース３２には、例えばＧＰＳ装置を搭載したタクシー等の自動車によって記録された過去の走行軌跡を表す軌跡情報が、ログデータベース３１Ａと同じフォーマットで複数の自動車の台数分、すなわち複数のユーザ分記録されている。

取得部２１は、メッシュ毎及び単位時間毎に、自動車の集計台数を取得する。なお、検知済みの渋滞情報を取得してもよい。また、取得部２１は、自動車の軌跡情報を軌跡情報データベース３２から更に取得する。

判定部２２は、メッシュ毎及び単位時間毎に集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出する。例えば、メッシュ毎及び単位時間毎に集計台数が一定よりも多かった場合又は画像処理によりレーン別渋滞が検知された場合に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出する。そして、判定部２２は、軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、渋滞習慣度、軌跡習慣度、及び軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した重み付き渋滞習慣度に基づいて渋滞の発生が突発的か慢性的かを判定する。

判定部２２は、例えば渋滞習慣度が未算出のメッシュの数が多いほど、軌跡習慣度の重みを大きくする。特に渋滞発生確率の算出に集計台数が閾値以上となっているかどうかではなく、撮影画像データの画像処理によって検知された渋滞の先頭及び末尾の情報を使用した場合、渋滞の検出にはコストが大きくかかるため、渋滞習慣度が未算出のメッシュが多くなり、本開示の技術の効果が大きくなると考えられる。また、集計台数が閾値以上になっているかどうかで渋滞を判定したとしても、コネクテッドカーの普及初期から普及拡大中の時期の場合、必ずしも渋滞の発生を集計台数の情報から検知できるとは限らないので、渋滞習慣度が未算出のメッシュが出てくる可能性がある。

通知部２３は、渋滞の発生を、予め定めた基準を満たすユーザにのみ通知する。例えば予め定めた基準は、渋滞の発生が慢性的な場合は、慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏外のユーザである。

次に、図７を参照して、本実施形態に係る渋滞判定装置１０の作用について説明する。

図７は、本実施形態に係る渋滞判定プログラムによる渋滞判定処理の流れの一例を示すフローチャートである。渋滞判定プログラムによる渋滞判定の処理は、渋滞判定装置１０のＣＰＵ１１が、ＲＯＭ１２又はストレージ１４に記憶されている渋滞判定プログラムをＲＡＭ１３に書き込んで実行することにより、実現される。

ステップＳ２００では、ＣＰＵ１１が、軌跡情報をサーバ３０の軌跡情報データベース３２から取得する。

ステップＳ２０２では、ＣＰＵ１１が、ステップＳ２００で取得した軌跡情報に基づいて、軌跡習慣度を上記特許文献１に開示された手法を用いて算出する。すなわち、上記（１）式により軌跡習慣度Ｒ１（ｌ，ｔ）を算出する。ただし、ここではユーザｕを区別せず、全ユーザ共通で軌跡習慣度Ｒ１（ｌ，ｔ）を算出する。

具体的には、軌跡情報に基づいて、時間帯ｔ_ｋにおける全ユーザ横断のメッシュｌへの通過確率Ｐ（ｌ｜ｔ_ｋ）を、メッシュｌ毎及び時間帯ｔ_ｋ毎にそれぞれ算出する。

また、時間帯ｔ_ｋの全ユーザ横断の全メッシュｌに対する通過確率の平均μ（ｔ_ｋ）を、時間帯ｔ_ｋ毎に算出する。

また、時間帯ｔ_ｋの全ユーザ横断の全メッシュｌに対する通過確率の標準偏差σ（ｔ_ｋ）を、時間帯ｔ_ｋ毎に算出する。

また、時間帯ｔ_ｋにおける全ユーザ横断による全場所の通過回数の合計値Ｎ（ｕ，ｔ_ｋ）を、時間帯ｔ_ｋ毎に算出する。

また、全ユーザ横断で時間帯ｔ_ｋの全時間帯の中で最も多く通過を記録した時間帯ｔ_ｋ’における全場所の通過回数の合計値

を時間帯ｔ_ｋ毎に算出する。

そして、上記（１）式により軌跡習慣度Ｒ１（ｌ，ｔ）をメッシュｌに算出する。

ステップＳ２０４では、ＣＰＵ１１が、ログデータベース３１Ａからメッシュｌ毎及び単位時間毎の集計台数Ｃ（ｌ，ｔ）又は渋滞発生の有無を取得する。

ステップＳ２０６では、ＣＰＵ１１が、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌ有るか否かを判定する。閾値は、集計台数Ｃ（ｌ，ｔ）が閾値以上の場合は、そのメッシュｌで渋滞が発生している可能性が高いと判断できる値に設定される。そして、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌが有る場合はステップＳ２０８へ移行し、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌが無い場合はステップＳ２０４へ移行する。また、撮影画像データの画像処理による渋滞検知結果を入力とする場合には、渋滞検知結果が１件以上有る場合はステップＳ２０８へ移行し、１件もない場合はステップＳ２０４へ移行する。

ステップＳ２０８では、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌに存在していたユーザｕ、すなわち集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌからログデータをサーバ３０に送信した自動車のユーザｕから撮影画像データを取得する。

ステップＳ２１０では、ＣＰＵ１１が、図５のステップ１１２と同様に、ステップＳ２０８で取得した撮影画像データを解析して渋滞範囲を特定し、渋滞の先頭位置を特定する。

ステップＳ２１２では、ＣＰＵ１１が、ログデータベース３１Ａに登録されたログデータに基づいて、上記（１）式により渋滞習慣度Ｒ２（ｌ，ｔ）をメッシュｌ毎に算出する。ただし、ここではユーザｕを区別せず、全ユーザ共通で渋滞習慣度Ｒ２（ｌ，ｔ）を算出する。この場合、Ｐ（ｌ｜ｔ_ｋ）は、混雑発生確率を表す。渋滞習慣度Ｒ２（ｌ，ｔ）の算出は、ログデータベース３１Ａに登録されたログデータを用いる点を除いてステップＳ２０２の軌跡習慣度Ｒ１（ｌ，ｔ）の算出と同様であるので説明は省略する。

ステップＳ２１４では、ステップＳ２０２で算出した軌跡習慣度Ｒ１（ｌ，ｔ）及びステップＳ２１２で算出した渋滞習慣度Ｒ２（ｌ，ｔ）に基づいて重み付き習慣度Ｒ３（ｌ，ｔ）を次式により算出する。

Ｒ３（ｌ，ｔ）＝Ｒ２（ｌ，ｔ）＋Ｒ１（ｌ，ｔ）×α ・・・（５）

上記（５）式においてαは重みであり、次式で表される。

α＝ｃ×Ｍ^１／ａ×ｂ ・・・（６）

ここで、ｃは、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との相関係数である。Ｍは、渋滞習慣度Ｒ２（ｌ，ｔ）が未算出のメッシュｌ、すなわち、閾値以上の台数が検知されていない、又は、画像による渋滞検知で渋滞が検出されておらず、渋滞習慣度Ｒ２（ｌ，ｔ）が算出されていないメッシュｌの数である。ａ、ｂは定数である。

上記（６）式より、相関係数ｃが大きいほど、すなわち軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との差が小さいほど重みαは大きな値となる。また、渋滞習慣度が未算出のメッシュｌの数Ｍが多いほど、重みαは大きな値となる。

従って、重み付き習慣度Ｒ３（ｌ，ｔ）は、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との差が小さいほど、渋滞習慣度Ｒ２（ｌ，ｔ）と比べて軌跡習慣度Ｒ１（ｌ，ｔ）の影響が大きくなる。また、未検知のメッシュｌの数Ｍが多いほど、渋滞習慣度Ｒ２（ｌ，ｔ）と比べて軌跡習慣度Ｒ１（ｌ，ｔ）の影響が大きくなる。

なお、ログデータの数が少ない場合は、重み付き習慣度Ｒ３（ｌ，ｔ）のばらつきが大きくなる傾向があるため、重み付き習慣度Ｒ３（ｌ，ｔ）を正規化してレベル１～１０等のようにレベル分けするようにしてもよい。

また、渋滞習慣度Ｒ２（ｌ，ｔ）を算出したメッシュｌがある程度増加してきた場合は、定数ａを大きな値に設定することにより、渋滞習慣度Ｒ２（ｌ，ｔ）が未算出のメッシュｌの数Ｍの影響を抑えるようにしてもよい。すなわち、軌跡習慣度Ｒ１（ｌ，ｔ）の影響が小さくなるようにしてもよい。

また、定数ｂについても、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との相関係数Ｃが小さい場合、ログデータの数が少なすぎる場合は、定数ｂを１未満の値に設定し、重みαが小さくなるようにしてもよい。すなわち、軌跡習慣度Ｒ１（ｌ，ｔ）の影響が小さくなるようにしてもよい。

ステップＳ２１６では、ＣＰＵ１１が、慢性的な渋滞が発生しているメッシュｌが有るか否かを判定する。具体的には、ステップＳ２１４で算出した重み付き習慣度Ｒ３（ｌ，ｔ）が予め定めた閾値以上であるか否かを判定する。閾値は、重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上の場合は、そのメッシュｌ及び時刻ｔで発生している渋滞が慢性的である可能性が高いと判断できる値に設定される。

そして、慢性的な渋滞が発生しているメッシュｌが有る場合、すなわち重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上のメッシュが有る場合は、ステップＳ２１７へ移行する。一方、慢性的な渋滞が発生しているメッシュｌが無い場合、すなわち、重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上のメッシュが無い場合は、ステップＳ２１８へ移行する。

ステップＳ２１７では、ＣＰＵ１１が、ステップＳ２１０で特定した渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報を、慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏外であるユーザｕに送信することにより通知する。すなわち、慢性的な渋滞が発生しているメッシュを含むエリアが生活圏内であるユーザｕに対しては慢性的な渋滞の発生は通知しない。なお、予め定めたエリアは、慢性的な渋滞が発生しているメッシュを中心として半径数百メートル以内又は半径数キロメートル以内のエリア等とすることができるが、これに限られるものではない。

ステップＳ２１８では、ＣＰＵ１１が、突発的な渋滞が発生していることを生活圏外のユーザ及び生活圏内の両方のユーザに通知する。

慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏内であるか否かは、例えば特許文献１記載の方法により算出した習慣度に基づいて判定してもよいし、位置情報の履歴に基づいて推定した自宅の位置から現在地までの距離に基づいて判定してもよい。

このように、重み付き渋滞習慣度Ｒ３（ｌ，ｔ）に基づいて、発生した渋滞が慢性的か突発的かを判定し、慢性的であった場合には、渋滞が発生しているメッシュを含む予め定めたエリアが生活圏内のユーザには渋滞の発生を通知しない。これにより、不要な渋滞発生の通知を抑制することができる。一方、発生した渋滞が突発的だった場合は、ユーザが生活圏内か生活圏外かによらず、全ユーザに通知する。突発的な渋滞は生活圏内のユーザも認識しておらず、事故を誘発する可能性が高いためである。

なお、本実施形態では、重み付き渋滞習慣度が閾値以上のメッシュが有る場合に、そのメッシュを含む予め定めたエリアを生活圏外とするユーザに慢性的な渋滞の発生を通知する場合について説明したが、算出した重み付き渋滞習慣度を他の処理に用いても良い。例えば自動車のルート探索処理において、目的地までのルートを決定する際のパラメータの１つとして重み付き渋滞習慣度を用いてもよい。

また、算出した重み付き渋滞習慣度と、算出した日時と、メッシュＩＤと、を記録しておき、日時及びメッシュＩＤを入力すると、そのメッシュＩＤのメッシュで発生した渋滞が慢性的か突発的かを出力する処理に重み付き渋滞習慣度を用いても良い。

なお、渋滞習慣度を算出する際に用いるログデータとしては、例えばレーン別でない片側全車線共通の渋滞情報を蓄積しているデータベースの情報を用いてもよい。また、渋滞のログデータだけでなく、新規に開始された位置情報記録サービスにおけるユーザの訪問傾向を調べたい時に、別の類似サービスにおける訪問傾向を外部情報として活用することも考えられる。

＜実施例＞

開示の技術の実施例について説明する。

なお、以下では、特許文献１に開示の習慣度の算出手法をＲＢＭ（Ｒｅｇｕｌａｒ Ｂｅｈａｖｉｏｒ Ｍｅａｓｕｒｅ）、第１実施形態における集計突発指標の算出手法を前述したようにＳＩＣＭ、第２実施形態における重み付き習慣度の算出手法をＳＲＢＭ（Ｓｍａｌｌ－ｓｔａｒｔ Ｒｅｇｕｌａｒ Ｂｅｈａｖｉｏｒ Ｍｅａｓｕｒｅ）と称する。

（軌跡情報の概要）

軌跡情報として、以下のタクシーのＧＰＳログデータを使用した。

期間：２０１７年１１月２７日から２０１８年１月３１日までの６６日間
台数：タクシー１０台分
総ログ数：２，７５７，００３
メッシュ数：４７，１４６

なお、ＧＰＳログデータの緯度経度については、小数点以下４桁以降を丸めて小数点以下３桁までを有効桁数とした。メッシュは、縦横が約１１０ｍの正方形のメッシュとした。

図８には、上記のＧＰＳログデータの時間帯の偏りを表すグラフを示した。横軸は時間を表し、縦軸はログ数を表している。また、図９には、上記のＧＰＳログデータの曜日の偏りを表すグラフを示した。横軸は曜日を表し、縦軸はログ数を表している。図８、９に示すように、時間帯及び曜日の何れにおいてもログ数の偏りは少なかった。

また、図１０には、メッシュ毎のログデータの数を表すログ数のグラフを示した。図１０は、ログ数が多い順に各メッシュのログ数をプロットしたものである。図１０に示すように、上位１０メッシュに全体の９０％のＧＰＳログデータが集まっていることが分かった。

（ＲＢＭの妥当性評価）

ＲＢＭは人間のチェックインログを想定した手法として考案されたものであるため、自動車が搭載するＧＰＳ装置によって取得された連続的なログデータへの適応が可能か、自動車の渋滞について、ＲＢＭが考慮する複数の時間軸に依存する習慣性があるか、について確認した。１０台分のＧＰＳログデータから、どの自動車のログデータであったかを区別せずに通過確率を算出した。本来、第２実施形態では集計台数が閾値以上となった場所を入力したり、撮影画像データの画像処理で検知された渋滞発生場所を入力したりするが、１０台分しかＧＰＳログデータがなかったこともあり、まずはＧＰＳログデータに基づきタクシーが各メッシュを通過したか否かによりＲＢＭによる習慣度を算出した。

図１１には、タクシーのＧＰＳログデータに対してＲＢＭを適用した結果を示す。各メッシュにおける習慣度の平均値で分類した。タクシー会社の本拠地である東京都武蔵野市付近と都内に習慣度の高い場所が点在していること、都内から離れていくほど突発的な訪問を示す習慣度の低い場所が存在していることが確認できた。

図１２には、習慣度が特に高かった場所、すなわち慢性的に通行された場所のみをプロットしたものを示す。駅や仮眠・待機場所と考えられる都内の公園等で慢性的な渋滞があったことが分かった。

図１３には、ログ数は少ないが、習慣度が特に高かった場所の曜日及び時間帯の偏りを表すグラフを示した。メッシュＩＤであるＬｉｄ＝３６７４の場所（千歳船橋駅）は、金曜日の深夜のログ数が多く、曜日及び時間帯に偏りが多いことが分かる。

Ｌｉｄ＝３８７３の場所（恵比寿公園）も金曜日の終電後及び月曜日の始発前の時間帯のログ数が多く、何れも電車が運行していない時間帯の顧客獲得を狙って走行するタクシー特有の傾向を表していると考えられる。

このように、単なるログ数を考慮するだけではなく、ＲＢＭにより複数の時間軸を考慮した習慣度を算出することにより、必ずしもログ数は多くないものの、曜日や時間帯の偏りが大きい場所を特定できることが確認できた。

また、ＧＰＳによる軌跡情報から渋滞が慢性的であるか突発的であるかを指標化するのにＲＢＭが有効であることが分かった。

（ＳＩＣＭの妥当性評価）

タクシーのＧＰＳログデータを用いて、ＳＩＣＭの妥当性を確認した。

本来は各メッシュの単位時間当たりの集計台数を入力として突発的な渋滞を判定するが、タクシー１０台分のＧＰＳログデータを用いてＳＩＣＭの妥当性を評価するにあたり、１０分毎のメッシュ内のＧＰＳログデータのログ数をＳＩＣＭの入力とした。

渋滞が発生しているメッシュでは、そのメッシュに自動車が留まる時間が長くなり、定期的に取得するＧＰＳログデータのログ数が増加するため、簡易的にＳＩＣＭの妥当性を評価するためにＧＰＳログデータのログ数を用いて評価した。

ＧＰＳログデータを１０分毎に集計した際の集計回数は９，２５８回であった。また、全メッシュでの延べ集計回数、すなわち集計突発指標の算出回数は１，０１６，０２４回であった。

図１４には、ＳＩＣＭで算出した集計突発指標の分布を示した。図１４は、集計突発指標が高い順に全メッシュの集計突発指標をプロットしたものである。初回の集計では全メッシュの集計突発指標は０であるため、集計突発指標が丁度０となっている集計が多い。また、集計突発指標がプラスの値の場合、すなわち通常より集計台数が突発的に多くなっている場合もあれば、集計突発指標がマイナスの値の場合、すなわち通常より集計台数が突発的に少なくなっている場合もある。通常より集計台数が突発的に少ない場合よりも、通常より集計台数が突発的に多い場合の方が多いことが分かり、慢性的に渋滞が発生している場所で突発的に集計台数が減ることは少ないことが分かる。

図１５には、集計突発指標が最も高かった３か所について、集計突発指標及びログ数の変遷をプロットした。Ｔｏｐ１（国際基督教大学（ＩＣＵ）付近１）は、ログ数が普段は多くない場所であり、急にログ数が５０以上となった時に集計突発指標が最大となったことが確認できた。また、その後もログ数が４０以上となったタイミングが２回あるが、ログ数が増大した３回目のタイミングでは、ログ数が増大した２回目のタイミングよりもログ数が多いにも関わらず、集計突発指標はそれほど大きくないことが分かる。突発的に集計突発指標が大きくなる結果が何回か出ると、集計突発指標が大きいことがそこまで珍しいことではなくなるため、ＳＩＣＭによる集計突発指標の算出結果は妥当と言える。

同様に、Ｔｏｐ２（国際基督教大学（ＩＣＵ）付近２）、Ｔｏｐ３（初台駅付近）の場所についても、通常よりも集計台数が突発的に増加した際に集計突発指標が大きくなっていて、意図通りの結果が出ていることが確認できた。

次に、静的な集計統計情報を用いて集計突発指標を算出した場合の計算コストの削減効果について説明する。なお、集計統計情報は、上記（３）式における集計台数の平均μ（ｔ_ｋ，ｌ）、集計台数の標準偏差σ（ｔ_ｋ，ｌ）、及び重みω（ｔ_ｋ、ｌ）を含む情報である。

６６日間のうち前半の３３日間のＧＰＳログデータを用いて集計統計情報を作成し、後半の３３日間については、作成した静的な集計統計情報を用いて集計突発指標を算出した場合の計算時間は１．９０秒であった。一方、６６日間全てにおいて毎回集計統計情報を更新した動的な集計統計情報を用いて集計突発指標を算出した場合の計算時間は６．３７秒であった。静的な集計統計情報を用いて集計突発指標を算出することにより、計算コストを抑えることができることを確認した。また、渋滞情報を高速にユーザに伝えるためには画像処理対象の撮影画像データを優先付けする処理自体も高速に実施する必要があるが、Ａｕｔｏ Ｅｎｃｏｒｄｅｒなどのモデルを用いて異常値検出を行う場合に比べても高速に優先付けが実現できることが確認できた。

図１６には、集計突発指標が１．０以上であった１６０箇所について、算出された集計突発指標を８段階にレベル分けして地図上にプロットしたものを示す。なお、同じメッシュで集計突発指標を複数回算出した場合はマークを重ねて表示している。図１６に示すように、車線数の多い道路の、特に交差点付近に集中していることが確認できた。これは渋滞が発生しやすい場所と合致している。

図１７には、動的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合において、集計突発指標が０より大きいメッシュを採用した場合と、集計突発指標が０以上のメッシュを採用した場合と、集計突発指標が－０．５より大きいメッシュを採用した場合と、の各々の場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示した。

なお、実際に渋滞が発生したメッシュの検出は、お台場付近のエリアにおいて人手で行い、実際に渋滞が発生している１２１個のメッシュを検出した。

集計突発指標が０より大きいメッシュを採用した場合、計算コストのお台場における削減率は８２．２％であり、突発的な渋滞があったメッシュについては１００％採用されていることが分かる。

また、集計突発指標が０以上のメッシュを採用した場合、集計突発指標が－０．５以上のメッシュを採用した場合の何れにおいても、計算コストの削減率は少し減るものの、突発的な渋滞があったメッシュの全てが採用されている。

一方、撮影画像データの取得及び解析の処理対象から外したい慢性的な渋滞のメッシュの採用率は低くなっており、突発的な渋滞のみを撮影画像データの取得及び解析の対象にするという目的に合致した結果が得られていることが確認できた。なお、人手で検知した渋滞の渋滞習慣度についてはＲＢＭを用いて算出し、渋滞習慣度の値が上位５０％を慢性的な渋滞、下位５０％を突発的な渋滞とした。

図１８には、６６日間のうち前半のＧＰＳログデータのみを用いて算出した静的な集計統計情報を用いた場合の結果を示した。図１８の結果は、静的な集計統計情報を用いたことだけが図１７の場合と異なる。

図１８に示すように、集計突発指標が０より大きいメッシュだけを採用すると、突発的な渋滞のメッシュの採用率は８５．７％に下がったが、集計突発指標が０以上のメッシュを採用すれば、突発的な渋滞のメッシュの１００％が採用され、計算コスト削減率はお台場で３７．７％、全地域で６５．２％であった。

このように、静的な集計統計情報を用いて計算コストを抑えた場合でも、突発的な渋滞の判定の精度はそれほど低下しないことが確認できた。

図１９には、後半３３日間のＧＰＳログデータを用いて算出した集計突発指標が閾値以上のメッシュについてＲＢＭを用いて渋滞習慣度を算出した結果を示す。渋滞習慣度は８段階にレベル分けした。なお、丸で囲まれた４か所のメッシュについては集計突発指標が閾値未満であるため渋滞習慣度を算出する際に除外されたが、これらはＲＢＭによる渋滞習慣度が高く慢性的な渋滞であったため、集計突発指標が閾値以上のメッシュについてのみ撮影画像データの取得及び解析を行うという目的に合致することが確認できた。

（ＳＲＢＭの妥当性評価）

図２０に、お台場において検知された１５個の渋滞に対して、渋滞を１回検出する毎にＳＲＢＭにより算出した重み付き習慣度と、１５個の渋滞全てを検知した後にＲＢＭにより算出した渋滞習慣度と、の相関係数を全メッシュについて算出した結果を示す。

なお、重み付き習慣度を算出する際の定数ａは、渋滞検知回数が少ないため１とした。また、定数ｂは、０～３の間で０．５刻みに変化させた。定数ｂが０の場合は、軌跡習慣度が考慮されないので、ＲＢＭにより渋滞習慣度を算出した場合と同じである。

図２０に示すように、定数ｂを０より大きい値の何れに設定した場合も、定数ｂを０とした場合、すなわち軌跡習慣度を考慮しなかった場合に比べて、最初の４個の渋滞が検知されるまでの間で高い相関があることが確認できた。定数ｂの値を大きくし過ぎると、後半でＲＢＭによる渋滞習慣度との相関が若干低くなるため、定数ｂは０．５が最も適切であると考えられる。

図２１には、重み付き渋滞習慣度を算出した際の重みαの変化を示す。図２１に示すように、渋滞検知回数が少ない初期の段階において軌跡習慣度の影響が大きくなるように重みが大きくなっていることが確認できた。

ＳＲＢＭを用いて重み付き渋滞習慣度を算出することにより、渋滞検知回数が少ない初期の段階においても、渋滞検知結果が十分に得られた後にＲＢＭで算出した渋滞習慣度に近い値が得られることが確認できた。

上記実施形態は、本開示の構成例を例示的に説明するものに過ぎない。本開示は上記の具体的な形態には限定されることはなく、その技術的思想の範囲内で種々の変形が可能である。

例えば、上記実施形態では、自動車及び渋滞を例に説明したが、これに限定されるものではない。例えば、自動車に代えて人間を、渋滞に代えて人の密度を用いてもよい。このように構成することで、例えば突発的に人の密度が高くなっている領域や人の密度が低くなっている領域を所定の条件を満たすユーザに通知することで、例えば人の密度が低いタイミングで外出をするといった意思決定の助けになることが想定される。

密度が高くなる画像は、例えばスマートフォンに代表されるモバイルデバイスで撮影された画像を使ってもいいし、該当する位置・時間にＳＮＳに投稿された画像を用いてもよい。人の密度を取得するために前述した手段以外にモバイル空間統計などの情報を用いてもよい。

なお、上記実施形態でＣＰＵがソフトウェア（プログラム）を読み込んで実行した渋滞判定処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の製造後に回路構成を変更可能なＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、及びＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、渋滞判定処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。

また、上記実施形態では、渋滞判定プログラムがストレージに予め記憶（インストール）されている態様を説明したが、これに限定されない。プログラムは、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ－ＲＯＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、及びＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ等の非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）記憶媒体に記憶された形態で提供されてもよい。また、プログラムは、ネットワークを介して外部装置からダウンロードされる形態としてもよい。

以上の実施形態に関し、更に以下の付記を開示する。

（付記項１）
メモリと、
前記メモリに接続された少なくとも１つのプロセッサと、
を含み、
前記プロセッサは、
渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
ように構成されている渋滞判定装置。

（付記項２）
渋滞判定処理を実行するようにコンピュータによって実行可能なプログラムを記憶した非一時的記憶媒体であって、
前記渋滞判定処理は、
渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
非一時的記憶媒体。

１０ 渋滞判定装置
２１ 取得部
２２ 判定部
２３ 通知部
３０ サーバ
３１、３１Ａ ログデータベース
３２ 軌跡情報データベース

Claims (9)

1. 取得部及び判定部を備えた渋滞判定装置における渋滞判定方法であって、
   前記取得部が、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
   前記判定部が、取得した前記メッシュ毎及び単位時間毎の前記集計台数と、前記メッシュ毎及び単位時間毎の前記集計台数の平均と、前記メッシュ毎及び単位時間毎の前記集計台数の標準偏差と、前記メッシュ毎及び単位時間毎に前記集計台数を集計した集計回数に基づく重みと、に基づいて集計突発指標を算出し、算出した前記集計突発指標に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
   渋滞判定方法。
2. 取得部及び判定部を備えた渋滞判定装置における渋滞判定方法であって、
   前記取得部が、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得すると共に、自動車の軌跡情報を取得し、
   前記判定部が、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出し、前記軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、前記渋滞習慣度、前記軌跡習慣度、及び前記軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した前記重み付き渋滞習慣度に基づいて、渋滞の発生が突発的か慢性的かを前記メッシュ毎に判定する、
   渋滞判定方法。
3. 前記判定部が、前記渋滞習慣度が未算出の前記メッシュの数が多いほど、前記軌跡習慣度の重みを大きくする、
   請求項２記載の渋滞判定方法。
4. 前記渋滞判定装置は通知部を備え、
   前記通知部が、前記渋滞の発生を、予め定めた基準を満たすユーザにのみ通知する、
   請求項２又は請求項３記載の渋滞判定方法。
5. 前記予め定めた基準を満たすユーザは、渋滞の発生が慢性的な場合は、前記慢性的な渋滞が発生している前記メッシュを含む予め定めたエリアが生活圏外のユーザである、
   請求項４記載の渋滞判定方法。
6. 渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する取得部と、
   取得した前記メッシュ毎及び単位時間毎の前記集計台数と、前記メッシュ毎及び単位時間毎の前記集計台数の平均と、前記メッシュ毎及び単位時間毎の前記集計台数の標準偏差と、前記メッシュ毎及び単位時間毎の前記集計台数を集計した集計回数に基づく重みと、に基づいて集計突発指標を算出し、算出した前記集計突発指標に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する判定部と、
   を備えた渋滞判定装置。
7. 渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
   取得した前記メッシュ毎及び単位時間毎の前記集計台数と、前記メッシュ毎及び単位時間毎の前記集計台数の平均と、前記メッシュ毎及び単位時間毎の前記集計台数の標準偏差と、前記メッシュ毎及び単位時間毎の前記集計台数を集計した集計回数に基づく重みと、に基づいて集計突発指標を算出し、算出した前記集計突発指標に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する
   ことをコンピュータに実行させるための渋滞判定プログラム。
8. 渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得すると共に、自動車の軌跡情報を取得する取得部と、
   取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出し、前記軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、前記渋滞習慣度、前記軌跡習慣度、及び前記軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した前記重み付き渋滞習慣度に基づいて、渋滞の発生が突発的か慢性的かを前記メッシュ毎に判定する判定部と、
   を備えた渋滞判定装置。
9. 渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得すると共に、自動車の軌跡情報を取得し、
   取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出し、前記軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、前記渋滞習慣度、前記軌跡習慣度、及び前記軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した前記重み付き渋滞習慣度に基づいて、渋滞の発生が突発的か慢性的かを前記メッシュ毎に判定する
   ことをコンピュータに実行させるための渋滞判定プログラム。