JPWO2018190428A1 - 需要予測装置 - Google Patents

Abstract

需要予測装置（１）は、乗車日時を示す情報、及び、乗車場所を示す位置情報を含む、営業用車両に関する複数の乗車履歴情報を取得する乗車履歴取得部（１１）と、複数の乗車履歴情報を用いた空間クラスタリングにより、前記車両の需要予測を行う需要予測部（１４）と、需要予測部（１４）による需要予測結果を出力する出力部（１５）と、を有する。

Description

本発明は、需要予測装置に関する。

従来、タクシーの営業実績を示す営業実績データからタクシーの需要を推定するシステムがある。例えば、特許文献１には、タクシーの乗車が見込まれるロケーションを予測するシステムが開示されている。

特開２０１４−１３０５５２号公報

しかしながら、特許文献１等の方法を用いて予測された乗車が見込まれるロケーションにタクシー等の営業用車両が向かったとしても、営業用車両に客が乗車する位置は限られている場合等がある。また、ロケーションを予測したとしても、営業用車両の進行方向によっては、客の乗車が見込めないケースがある。

本発明は上記を鑑みてなされたものであり、営業用車両の需要をより精度よく予測可能な需要予測装置を提供することを目的とする。

上記目的を達成するため、本発明の一形態に係る需要予測装置は、乗車日時を示す情報、及び、乗車場所を示す位置情報を含む、営業用車両に関する複数の乗車履歴情報を取得する乗車履歴取得部と、前記複数の乗車履歴情報を用いた空間クラスタリングにより、前記車両の需要予測を行う需要予測部と、前記需要予測部による需要予測結果を出力する出力部と、を有する。

本発明によれば、営業用車両の需要をより精度よく予測可能な需要予測装置が提供される。

本発明の一実施形態に係る需要予測装置の概略構成図である。 需要予想方法について説明するフロー図である。 前処理部における前処理について説明する図である。 空間クラスタリングにおける半径ｄの設定について説明する図である。 半径ｄの設定の別の手法について説明する図である。 出力部における後処理について説明する図である。 需要予測結果の出力部からの出力例を示す図である。 本実施形態に係る需要予測装置のハードウェア構成の一例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態を詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１は、本発明の一実施形態に係る需要予測装置１の概略構成図である。図１に示す需要予測装置１は、営業用車両の需要予測を行う装置である。本実施形態では、営業用車両がタクシーである場合について説明する。ただし、乗降場所が限定されていない他の営業用車両にも適用可能である。需要予測装置１は、例えば装置の操作者等からの指示等を契機として、タクシーの乗車履歴に基づいて、予め定められたエリアにおけるタクシーの需要が高い場所の予測を行う装置である。

需要予測装置１では、需要を予測する対象エリアにおけるタクシーの乗車履歴情報を複数取得する。そして、乗車履歴情報に基づいて、空間クラスタリングを用いて需要が高くなる場所を予測する。そのため、需要予測装置１は、乗車履歴取得部１１、乗車履歴ＤＢ（データベース）１２、前処理部１３、需要予測部１４、及び、出力部１５を有する。

乗車履歴取得部１１は、タクシーに係る複数の乗車履歴情報を取得する機能を有する。乗車履歴情報には、乗車日時を示す情報、乗車場所を示す位置情報（ＧＰＳ情報等）、及び、車両の進行方向を示す情報が含まれる。車両の進行方向を示す情報は、客が乗車した車両が道路に沿ってどの方向に進むかを示すものである。したがって、南北方向に延びる道路においてタクシーに客が乗車した場合には、進行方向は「北」又は「南」となる。上記のように、進行方向は一方通行ではない道路においてタクシーがどの方向に進行した際に客が乗車したかを示す情報であるから、方向に関する細かい情報は不要であり、例えば、八方位程度に分類できる情報であればよい。なお、乗車履歴情報は、タクシーに搭載された装置等から送信された情報であってもよいし、例えばタクシーの運行管理を行う管理装置等で蓄積された情報であってもよい。

乗車履歴ＤＢ（データベース）１２は、乗車履歴取得部１１が取得した乗車履歴情報を保持する機能を有する。乗車履歴情報から需要予測を行う際には、乗車履歴ＤＢに保持された情報が用いられる。

前処理部１３は、需要予測を行う際の前処理として、乗車履歴情報に係る集計等を行う機能を有する。前処理については後述する。

需要予測部１４は、前処理部１３により前処理が行われた乗車履歴情報を用いて、空間クラスタリングを用いて需要予測を行う機能を有する。空間クラスタリングにより需要予測を行うと、需要予測結果として１以上の需要が高い場所を特定する情報が得られる。なお、需要予測部１４は、空間クラスタリングにより得られる需要予測結果の妥当性を検証する機能を有していてもよい。

本実施形態では、需要予測に用いられる空間クラスタリングとして、クラスタリングの一手法であるＭｅａｎ ｓｈｉｆｔ法を用いる場合について説明する。Ｍｅａｎ ｓｈｉｆｔ法とは、分散している各データの密度の局所極大値を検出し、局所極大点をベースとしてクラスタを作る、という手法である。具体的には、あるデータに着目したときに、当該データ点から所定の半径ｄ内に存在するデータを特定し、それらのデータ点の平均座標を求める。その後、その平均へ円の中心を移動し、移動した後の点を基準として同じ処理を繰り返し、円の中心が移動しなくなるまで続ける。上記の処理を、全データに対して繰り返して行うことで、同じ円に収束するデータ同士を同一クラスタと判断する。この手法は、予めクラスタ数を特定する必要がないため、タクシーの需要予測のように需要が高い場所として特定される場所の数が予測前には不明である場合に好適に用いることができる。なお、需要予測に用いられる空間クラスタリングとして、ＤＢＳＣＡＮ（Density-Based Spatial Clustering）を用いてもよい。

出力部１５は、需要予測部１４による需要予測結果を出力する機能を有する。また、出力部１５は、需要予測結果を出力する際に、出力する需要予測結果を選択する等の後処理を行う後処理部としての機能を有していてもよい。出力部１５による出力方法は特に限定されないが、例えば、需要予測装置１に設けられた画面に表示する、タクシーに搭載されたナビゲーションシステム又はタクシー運行管理装置等の外部装置に出力する、等が挙げられる。

次に、図２を参照しながら、需要予測装置１による需要予測方法について説明する。図２は、需要予測方法を説明するフロー図である。

まず、需要予測装置１の乗車履歴取得部１１では、タクシーに搭載された装置等の外部装置からタクシーに係る乗車履歴情報を取得する（Ｓ０１）。取得する乗車履歴情報の数が少ない場合には偏った需要予測が行われる可能性があることから、需要予測の精度を高めるためにより多くの乗車履歴情報を取得する態様とすることができる。取得された乗車履歴情報は、乗車履歴ＤＢ１２において保持される。乗車履歴情報の取得のタイミングは特に制限されない。例えば、タクシーにおいて客の乗降がある度にタクシーに搭載された装置から需要予測装置１に対して乗車履歴情報を送信する構成とすることができる。また、需要予測装置１が所定のタイミング（例えば、毎日０時）毎に乗車履歴情報を取得する構成としてもよい。

次に、前処理部１３において、需要予測を行う際の前処理を行う（Ｓ０２）。前処理は、空間クラスタリングを用いた需要予測を行う前に、計算量が適当であり且つ予測精度が適切となるようにデータ数の調整を行うことを主な目的としている。前処理部１３による前処理は、需要予測処理の開始時に行われる。したがって、需要予測装置１がタクシーの需要予測に係る処理の開始の指示を受けた場合に、前処理が開始される。タクシーの需要予測に係る処理の開始の指示には、需要予測を行う対象のエリアを特定する情報が含まれる。また、何らかの条件を加えた需要予測を行いたい場合には、タクシーの需要予測に係る処理の開始の指示に、当該条件（例えば、需要予測の対象の時間帯）が含まれる。

本実施形態で用いられる空間クラスタリングは、需要が高いと思われる場所を精度よく特定することができる反面、各データ（乗車履歴情報）についての重心計算を繰り返し行うため、データ数が増大に対して計算量の増大がとても大きくなることがある。したがって、計算量を適当にするためには、一度の空間クラスタリングに使用するデータ数を調整することが求められる。そこで、前処理部１３では、予測精度の低下を防ぎつつ、データ数を適当に調整するための処理を行う。

前処理の手法は特に限定されず、種々の方法を用いることができるが、前処理では、主にデータ数の調整のための処理を行う。データ数調整の一例を図３に示す。図３は、前処理の一例を説明する図である。ここでは、図３に示すエリアＸが需要対象のエリアであるとする。図３では、この対象エリアに係る乗車履歴情報のうち、進行方向が北向きであるデータについて、乗車位置に対応させてエリアＸの地図上にデータ点Ｄとして表示している。すなわち、図３では、進行方向が北向きであるデータのみを抽出した結果を示している。本実施形態に係る需要予測装置１では、車両の進行方向に係る情報を乗車履歴情報として取得しているため、車両の進行方向毎に需要予測を行うことが可能となる。したがって、データ数の調整を行う場合には、まず、乗車履歴情報を車両の進行方向毎に個別に取り扱う処理を行う。すなわち、乗車履歴情報に含まれる車両の進行方向毎にデータを取り出した上で、車両の進行方向毎に空間クラスタリングを行い、需要予測を行う構成とする。

図３では、データ点Ｄの１つのポイントが、１つの乗車履歴情報に対応する。ここで、図３に示すエリアＸ全体のデータを用いて空間クラスタリングを行った場合、エリアＸに含まれるデータ数が多いため、計算量が増大することが想定されるとする。その場合、例えば、エリアＸを一辺数十ｍ程度のメッシュ単位に区切ることで、一度の空間クラスタリングに用いられるデータ数を減らす処理が考えられる。図３に示す例では、破線で示すように、エリアＸを南北方向に３つに区切り、東西方向に９つに区切ることで、２７個の単位メッシュＭを作成している。このように、前処理部１３では、単位メッシュＭを作成し、単位メッシュＭ毎に乗車履歴情報を区画する処理を行うことで、需要予測の際の計算量を抑制する方法を用いることができる。なお、単位メッシュＭの大きさは、データ数等に応じて適宜変更することができる。

次に、上記と同様に、一度の空間クラスタリングに用いられるデータ数を減らす処理として、空間クラスタリングを行う対象のエリアＸの大きさではなく、エリアＸに係る全ての乗車履歴情報から特定の乗車履歴情報のみを抽出することが挙げられる。エリアＸに係る全ての乗車履歴情報には、乗車日時が互いに異なる乗車履歴情報が含まれる。したがって、例えば、エリアＸにおける特定の時間帯（例えば、１９時〜２１時）の需要予測を行う場合には、エリアＸに係る全ての乗車履歴情報から、需要予測の対象の時間帯の乗車履歴情報のみを抽出して空間クラスタリングに使用することで、データ数を減らすことができる。また、需要予測を行う対象の時間のように、需要予測を行う対象のエリア以外に何らかの条件が提示されている場合には、その条件に対応した乗車履歴情報のみを抽出して空間クラスタリングに使用するようにデータ数を減らす処理を行うことができる。

さらに、上記の前処理を行った後でもデータ数が十分に大きく計算量の増大が想定される場合には、乗車履歴情報の中からサンプリング（ランダム抽出）を行って、データ数を行ってもよい。このように、前処理部１３では、空間クラスタリングを行う際の計算量を考慮してデータ数を調整する。

次に、前処理部１３で前処理が施された乗車履歴情報を用いて、需要予測部１４において空間クラスタリングを実施する（Ｓ０３）。空間クラスタリングでは、上述のように半径ｄの円を用いた処理を繰り返し、同一の円に収束するデータを同一クラスタとして集約する。そして、同一クラスタのデータ群が収束した円の中心を、需要が高い地点として特定する。

なお、複数の条件での需要予測を行う場合には、前処理（特定の条件を満たす乗車履歴情報の抽出：Ｓ０２）と空間クラスタリング（Ｓ０３）とを繰り返す。これにより、条件毎の需要予測結果を得ることができる。

空間クラスタリングでは、半径ｄの円を用いてクラスタリングを行う。したがって、半径ｄの設定によって、同一クラスタとして集約されるデータ数が大きく変化する。例えば、半径ｄを大きくすると、同一クラスタとして集約されるデータ数が大きくなる。しかしながら、例えば隣接する他の道路での乗車履歴情報を、同一クラスタとして取り扱ってしまうことが考えられ、その場合、実際に需要が高い道路を特定することができなくなる可能性が考えられる。したがって、図４に示すように、２つの道路Ａ，Ｂがある場合には、道路Ａ，Ｂが含まれないような半径ｄを設定して空間クラスタリングを行う態様とすることができる。このように半径ｄを道路状況等に基づいて適切に設定することで、空間クラスタリングによる需要予測の精度が向上する。

需要予測部１４では、空間クラスタリングを用いて需要の高い地点を特定した後に、需要予測結果の妥当性を検証する工程を入れてもよい（Ｓ０４）。需要予測結果が妥当ではない場合とは、例えば、収束するデータ数が少ない円（クラスタ）ばかりになってしまう、又は、収束する円（クラスタ）の数が少なすぎる、という場合が挙げられる。このような場合、前処理によりデータ数を制限しすぎている、又は、空間クラスタリングに用いた半径ｄが適切ではない、という可能性が考えられる。そこで、需要予測部１４では、需要予測結果に基づいて、上記のように、需要予測結果が想定していたものであるかどうか（結果が妥当であるか）を確認する処理を行ってもよい。そして、需要予測結果が妥当ではない（Ｓ０４−ＮＯ）場合には、前処理（Ｓ０２）に戻り、再度需要予測を行う構成とすることができる。

前処理（Ｓ０２）を再度行う場合には、以下の処理を行うことが考えられる。例えば、空間クラスタリングを行った結果、同一円に収束する（すなわち同一クラスタである）データ数が少なく、円の中心が本当に需要の高い場所であるかどうかが不明であるという場合がある。この場合、空間クラスタリングを行う対象のデータ数が少ないことが想定される。このような場合、初回の前処理として、図３に示すように単位メッシュＭ毎に区画する前処理を行った場合には、再度前処理を行う場合に、メッシュの大きさを変更する、又は、隣接するメッシュと結合することで、新たなメッシュを定義することが考えられる。そして、新たに定義されたメッシュを利用して、空間クラスタリング（Ｓ０３）を行うことで、初回とは異なる需要予測結果が得られる可能性がある。メッシュに区切って空間クラスタリングを行う場合、隣接するメッシュとの境界部分に乗車履歴情報が集中している可能性がある。したがって、隣接するメッシュと結合した上で再度空間クラスタリング（Ｓ０３）を行うと、初回の空間クラスタリングでは集約できなかったクラスタを見つけることができる可能性があると思われる。

また、例えば、特定の時間帯の乗車履歴情報のみを抽出する前処理を行ったためにデータ数が少なくなっていることが考えられる場合には、再度前処理を行う際には、抽出する対象の時間帯を広げる等抽出の条件を緩和することが考えられる。なお、乗車履歴情報の抽出条件を緩和する場合には、需要予測結果に与える影響が小さいと予想される条件を優先して緩和することができる。例えば、乗車履歴情報に関して、「曜日」、「時間帯」、及び、「車両の進行方向」を抽出条件としていたとする。この場合、互いに異なる「曜日」間での需要の変化は、「時間帯」及び「進行方向」と比べると小さいと考えられる。したがって、抽出条件を緩和する場合には、「曜日」、「時間帯」、「車両の進行方向」の順で条件を緩和することが適切であると考えられる。

また、空間クラスタリング（Ｓ０３）の条件を変更する場合には、半径ｄの設定を変更することが想定される。上述したように、半径ｄは、クラスタの大きさ、すなわち、同一円に含まれるデータ数に大きく影響する。したがって、需要予測結果が妥当でないと考えられる場合には、半径ｄを変更して再度計算を行うことが一案として考えられる。

なお、図２では、需要予測結果が妥当ではない（Ｓ０４−ＮＯ）場合には、前処理（Ｓ０２）に戻り再度需要予測を行う、すなわち、前処理（Ｓ０２）と空間クラスタリング（Ｓ０３）とを再度行う場合について示しているが、空間クラスタリング（Ｓ０３）のみを再度行う構成としてもよい。需要予測結果が妥当ではない（Ｓ０４−ＮＯ）場合に、前処理（Ｓ０２）から再度需要予測を行うか、空間クラスタリング（Ｓ０３）から再度需要予測を行うか、を決定する方法は特に限定されないが、例えば、空間クラスタリング（Ｓ０３）に用いた半径ｄの妥当性を検証し、その結果に基づくことが挙げられる。

図５は、半径ｄを求める手法の一つについて説明する図である。図５では、空間クラスタリングを行う対象の領域として単位メッシュＭを設定した場合に、単位メッシュＭ内に含まれる道路の総延長距離と、単位メッシュＭの面積を求めて、これらから、複数の道路と重ならない半径ｄを算出する方法を説明する図である。図５に示すように、単位メッシュＭの各辺方向に沿って道路Ｃが設けられているとする。この場合、隣接する道路が同時に含まれないような半径ｄの円を設定すると、道路Ｃの総延長距離ｄｉｓｔ＿ａｌｌは、各辺方向に沿って伸びる道路Ｃの長さｓｑｒｔ（Ｍ）（ただしＭは単位メッシュＭの面積）を用いて以下の数式（１）のように記載できる。
ｄｉｓｔ＿ａｌｌ＝ｓｑｒｔ（Ｍ）×｛（ｓｑｒｔ（Ｍ）／２ｄ）×２｝＝Ｍ／ｄ …（１）

上記の数式（１）に基づくと、半径ｄと、単位メッシュＭの面積と、道路Ｃの総延長距離ｄｉｓｔ＿ａｌｌとは、以下の数式（２）の関係を満たすことができる。
ｄ＝Ｍ／ｄｉｓｔ＿ａｌｌ…（２）
したがって、半径ｄを、単位メッシュＭの面積と、道路Ｃの総延長距離ｄｉｓｔ＿ａｌｌとから求めることができる。

そして、空間クラスタリング（Ｓ０３）において用いた半径ｄと、上記の数式（２）から得られる半径ｄと、が類似しているかに基づいて、空間クラスタリング（Ｓ０３）で用いた半径ｄが適切であるかを評価することができる。なお、類似しているか否かの判断は、例えば、差分が所定値以内であるか等の基準を用いることができる。空間クラスタリング（Ｓ０３）で用いた半径ｄが、数式（２）から得られる半径ｄと類似していない（例えば、差分が所定値よりも大きい）場合には、前処理（Ｓ０２）を再度行わずに、半径ｄを数式（２）から得られる値に変更して、空間クラスタリング（Ｓ０３）のみを再度行う構成としてもよい。

このように、需要予測結果が妥当ではない（Ｓ０４−ＮＯ）場合に、空間クラスタリング（Ｓ０３）で使用した半径ｄが適切であるか否かに基づいて、前処理（Ｓ０２）から再度需要予測を行うか、空間クラスタリング（Ｓ０３）から再度需要予測を行うか、を決定することができる。なお、上記の基準とは異なる基準を用いて、前処理（Ｓ０２）から再度需要予測を行うか、空間クラスタリング（Ｓ０３）から再度需要予測を行うか、を決定してもよい。

また、上記の数式（２）を利用した半径ｄの算出方法を最初から用いて、初回の空間クラスタリング（Ｓ０３）を行う構成としてもよい。数式（２）を利用して算出された半径ｄを用いて空間クラスタリング（Ｓ０３）を行った結果、需要予測結果が妥当ではない（Ｓ０４−ＮＯ）場合には、半径ｄは適切であると考えられるため、前処理（Ｓ０２）から再度需要予測を行うことができる。ただし、上記の手法とは異なる手法に用いて半径ｄの妥当性検証する等のプロセスを組み合わせてもよい。

以上のように、前処理（Ｓ０２）及び空間クラスタリング（Ｓ０３）を再度行う場合には、初回の前処理及び空間クラスタリングの条件と、初回の需要予測結果とに基づいて、適宜処理内容を変更する態様とすることができる。

一方、妥当性の検証の結果、需要予測結果が妥当であると判断できる（Ｓ０４−ＹＥＳ）場合には、出力部１５において、出力用の情報を作成するための後処理を行った上で需要予測結果を出力する（Ｓ０５）。

出力用の情報を作成するための後処理とは、例えば、クラスタを構成するデータ数が所定数より少ないクラスタについては、出力用の需要予測結果には含めないようにする、等の処理である。

後処理では、以下のような処理を行うことも考えられる。例えば、抽出条件を緩和して、より多くの乗車履歴情報を用いて空間クラスタリングを行った場合には、同一利用者が、同じ時間帯に同じ場所から繰り返しタクシーを利用している場合があったとしても、その情報は単なる複数の乗車履歴情報として同一のクラスタとして集約される場合がある。乗車履歴情報の抽出条件を緩和した場合、特定の細かい条件を満たす乗車履歴情報が偏っていても、それを見つけることができない場合がある。そのような場合には、後処理として、同一クラスタとして集約された乗車履歴情報に含まれる乗車日時の条件（曜日・時間帯等：緩和した条件がある場合には、特にその条件）に偏りがあるかを確認する処理を行うことができる。

図６は、同一クラスタとして集約された複数の乗車履歴情報の乗車日時の条件のうち曜日に偏りがある例を示している。図６では、複数の乗車履歴情報における乗車日時の曜日をカウントした結果、月曜日のみが突出して大きくなっていることを示している。このように、同一クラスタに特定の条件の乗車履歴情報のみが偏って含まれている場合には、例えば、予め設定した閾値よりも乗車履歴情報が少ない条件の場合（図６は、月曜日以外の曜日）には、当該クラスタの円の中心を需要が高い地点として出力しないように、曜日後の需要予測結果を修正する処理を行うことができる。このように、出力部１５では、需要予測結果を出力する前の後処理として、同一クラスタとして集約された複数の乗車履歴情報に係る統計的処理を行ってもよい。

後処理を行った後に、出力部１５から需要予測結果が出力される。需要予測結果の出力方法は特に限定されないが、例えば、需要が高いと予測された場所、すなわち、空間クラスタリングの結果、同一円に収束したクラスタ毎の円の中心の位置を地図上に表示する方法を用いることができる。需要が高いと予測された場所を表示する際に、個別の乗車履歴情報を併せて表示することもできる。

図７は、進行方向毎に需要予測結果を出力した例を示している。図７（Ａ）は、車両の進行方向が北向きの乗車履歴情報から需要予測結果を求めたものであり、図７（Ｂ）は、車両の進行方向が南向きの乗車履歴情報から需要予測結果を求めたものである。図７では、個別の乗車履歴情報を示すデータ点Ｄに加えて、空間クラスタリングにより特定された需要が高い場所Ｓを表示している。この際に、図７（Ａ），（Ｂ）は、同一クラスタを構成するデータ数が１である場合には、当該クラスタの中心は需要が高い場所Ｓとして表示しないという処理を行っている。

図７のように、需要が高いと予測された場所Ｓを表示することに加えて、個別の乗車履歴情報のデータ点Ｄを併せて表示した場合、例えば、特定の建造物に対応する特定の場所Ｒ１，Ｒ２において乗車履歴情報が集中していることが確認できる。また、特定の道路に沿った領域Ｒ３、Ｒ４では、車両の進行方向に関係なく乗車履歴情報が集中していることが確認できる。さらに、図７（Ｂ）では、地図と組み合わせることで、ロータリーとなっている領域Ｒ５において乗車履歴情報が集中していることも確認できる。このように、地図と、需要予測結果と、乗車履歴情報と、を組み合わせて出力する構成とすると、種々の傾向等を把握することも可能となる。

なお、例えば、図７（Ａ）に示す情報と、図７（Ｂ）に示す情報とを組み合わせて１つの地図上に表示する構成としてもよい。この場合、車両の進行方向が北向きである場合に需要が高いと予測された場所と、車両の進行方向が南向きである場合に需要が高いと予測された場所と、が区別して認識できるように、出力内容を考慮する（例えば印の形状又は色を変更する）態様とすることができる。

以上のように、本実施形態に係る需要予測装置１は、乗車日時を示す情報、乗車場所を示す位置情報、及び、車両の進行方向を示す情報を含む、営業用車両に関する複数の乗車履歴情報を取得する乗車履歴取得部１１と、複数の乗車履歴情報を用いた空間クラスタリングにより、車両の進行方向毎に需要予測を行う需要予測部１４と、需要予測部１４による需要予測結果を出力する出力部１５と、を有する。

上記の需要予測装置１によれば、営業用車両に関する複数の乗車履歴情報を取得し、空間クラスタリングに基づいて車両の進行方向毎に需要予測を行うことができる。したがって、実績に基づいて営業用車両の進行方向毎の需要予測をより精度よく行うことができる。また、営業用車両の進行方向毎の需要予測を精度良く行うことで、精度が低い需要予測を行う場合と比較して、需要予測の試行回数（再計算）が増大することが防がれる。また、車両の進行方向毎に空間クラスタリングを行うため、一度の空間クラスタリングで使用するデータ量を抑制することができる。このように、需要予測装置における営業用車両の需要予測に関して発生する処理量の増大を防ぐことができる。

従来から、過去の乗車実績に基づいて営業用車両の需要を予測することは検討されていた。しかしながら、車両の進行方向等を考慮した予測は行われていなかった。そのため、例えば、需要が高いと思われる場所を予測することは検討していても、特定の進行方向に関して需要が高い場所を予測することまでは十分に行われていなかった。したがって、需要予測の精度について改善の余地があった。これに対して、本実施形態に係る需要予測装置１では、進行方向毎の需要予測を行う構成としたため、より高い精度での需要予測を行うことが可能となった。

また、需要予測装置１では、需要予測に空間クラスタリングを用いていることを特徴とする。従来の需要予測の手法としては、例えば、予測対象のエリアを細かく区切った上で、区画毎の乗車実績を集計することがよく行われていた。ただし、この手法を用いてどの場所での需要が高いかを特定する場合には、区画する単位を非常に小さく（例えば、１０ｍ四方等）する必要がある。また、区画する単位を小さくすると、その区画における乗車実績数が少なくなり、需要が高い場所の予測精度が低下する可能性がある。また、隣接する区画の境界の設定が適切ではない場合、本来需要が高い場所を適切に抽出できないことが考えられる。

また、需要予測の他の手法として、本実施形態と同様にクラスタリング手法を用いることが考えられるが、空間クラスタリングと比較して以下の問題がある。例えば、クラスタリング手法の１つとしてｋ−ｍｅａｎｓ法を用いることが考えられる。しかしながら、ｋ−ｍｅａｎｓ法では、予め分類するクラスタの数を決めておく必要があるという点で、需要が高い場所の数を事前に特定できない営業用車両の需要予測には不適である。また、クラスタ数を事前に決めておかなくてもよいクラスタリング手法としては、階層型クラスタリング手法が挙げられる。しかしながら、階層型クラスタリングでは、クラスタの数等が適当であるかを人間等が評価する段階が含まれるが、評価を機械的に行うことが難しいため、装置の自動化の観点からは適切では無い場合がある。

一方、空間クラスタリングは、需要が高い場所をクラスタの円の中心とすることができるため、ピンポイントで特定することができる。したがって、例えば需要が高い場所は近接する２つの道路のどちらかである、というような曖昧な特定を防ぐことができる。また、空間クラスタリングでは、クラスタリングを行う前に予め分類するクラスタを決めておく必要がないため、需要が高い場所が多い場合にはそれらを適切に特定することができる。さらに、例えば「クラスタに含まれるデータ数が２以上であれば当該クラスタは需要が高い場所である」という機械的な判断を用いて、需要予測の結果が適切であるかを検証することも可能である。したがって、本実施形態に係る需要予測装置１が行う空間クラスタリングを用いた営業用車両の需要予測は、他の手法を用いた場合よりも精度を向上させることができる。また、空間クラスタリングを用いた営業用車両の需要予測によれば、上述の通り需要予測の精度が高められるため、需要予測に係る試行回数の増大による処理量の増大を防ぐことができる。

また、複数の乗車履歴情報から、空間クラスタリングに用いる乗車履歴情報を抽出する前処理部１３を有し、需要予測部１４は、前処理部１３により抽出された乗車履歴情報に基づいて需要予測を行う態様とすることができる。上記のように、前処理部１３による前処理を行う構成とすることで、例えば、需要予測の対象ではない乗車履歴情報が含まれた状態で需要予測を行うことを防ぐことができる。また、空間クラスタリングに用いられるデータ数の調整が可能となり、適切な計算量で需要予測を精度良く行う構成を実現することができる。また、上記のようにデータ数の調整が可能となることで、必要量以上のデータ数を用いた計算が発生することを防ぐことができるため、想定外の計算量の増大を防ぐことができ、処理量の最適化を計ることができる。

また、前処理部１３は、乗車日時を示す情報が特定の条件を満たす乗車履歴情報を抽出する態様とすることができる。また、前処理部１３は、位置情報が特定の条件を満たす乗車履歴情報を抽出する態様とすることができる。上記のように、前処理部において乗車日時又は位置情報等を用いて乗車履歴情報を抽出する構成とすることで、需要予測の対象の条件に適合した乗車履歴情報を適切に抽出することができる。また、上記のように乗車履歴情報の抽出を適切に行うことで、不要な乗車履歴情報を用いた計算が発生することを防ぐことができることから、計算量の増大を防ぐことができ、処理量の最適化を計ることができる。

また、需要予測部１４は、需要予測結果の妥当性を検証し、需要予測結果が妥当でない場合には、条件を変更して空間クラスタリングを再度実施する態様とすることができる。上記のように、妥当性を検証するという構成を有することで、より適切な需要予測結果を出力可能な構成とすることができる。また、妥当性を検証する構成を有することで、適切な需要予測結果を出力可能とすることで、例えば装置の操作者が需要予測の再計算を繰り返すことなどを防ぐことができるため、需要予測に係る処理量の増大を防ぐことができる。

出力部１５は、需要予測結果において需要が高いと予測された位置に関する情報を、地図情報と重ね合わせて表示する態様とすることができる。上記のように、地図情報と重ね合わせて需要予測結果において需要が高いと予測された位置に関する情報を出力する構成とすることで、出力結果を直感的に把握しやすくなるため、需要予測結果の活用度が向上する。また、需要予測結果において需要が高いと予測された位置に関する情報を、地図情報と重ね合わせて表示することで、装置の操作者は需要予測結果を俯瞰的に確認することができるため、再計算等の機会を減らすことができ、処理量の増大を防ぐことができる。

なお、上記実施形態では、車両の進行方向毎に需要予測を行う方法として、車両の方向別に乗車履歴情報を取得して空間クラスタリングを行う場合について説明したが、車両の進行方向毎に収集した情報で空間クラスタリング（Ｓ０３）を行うことに代えて、進行方向関係なく収集した情報で空間クラスタリング（Ｓ０３）を行った後に、後処理（Ｓ０４）として方向のクラスタリングを行うことで、進行方向毎の需要予測を行う構成としてもよい。

具体的には、進行方向関係なく収集した乗車履歴情報を用いて空間クラスタリング（Ｓ０３）を行った後に、同一クラスタとして特定された各乗車履歴情報に含まれる車両毎の進行方向を数値化する。具体的には、車両の進行方向に関する情報を、特定の方角（例えば東）及び特定の回転方向（右回り）を基準として、ｓｉｎ（ｒａｄ）、ｃｏｓ（ｒａｄ）に変換する。各乗車履歴情報に含まれる進行方向に係る情報がそれぞれｓｉｎ（ｒａｄ）、ｃｏｓ（ｒａｄ）に変換されるので、これらの値を用いて空間クラスタリングを行う。この結果、進行方向が関係なく収集された乗車履歴情報において同一クラスタと判断された乗車履歴情報の中から、特定の方向に向かう車両の情報をクラスタとして取り出すことができる。このように、進行方向関係なく収集した乗車履歴情報を用いて空間クラスタリング（Ｓ０３）を行った後に、後処理（Ｓ０４）工程において、進行方向に係るクラスタリングを行う場合でも、進行方向毎の需要予測を行うことが可能である。

なお、上記実施形態では、進行方向毎の需要予測を行う構成を有する場合について説明したが、進行方向毎の需要予測を行わない構成としてもよい。すなわち、乗車履歴情報には、乗車日時を示す情報、及び、乗車場所を示す位置情報が含まれて、複数の乗車履歴情報を用いた空間クラスタリングにより、車両の需要予測を行う構成であってよい。このような構成であっても、空間クラスタリングを用いることで、需要が高い場所をクラスタの円の中心とすることができるため、ピンポイントで特定することができる。したがって、営業用車両の需要をより精度よく予測することができる。

なお、上記実施形態では、需要予測装置１が需要予測のみの機能を有している場合について説明した。しかしながら、需要予測装置としての機能を、例えば営業用車両を管理する運行管理装置等、他の機能を有する装置と組み合わせて実現してもよい。

（その他）
上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に(例えば、有線及び／又は無線)により接続し、これら複数の装置により実現されてもよい。

例えば、本発明の一実施の形態における需要予測装置１は、本実施形態の処理を行うコンピュータとして機能してもよい。図８は、本実施形態に係る需要予測装置１のハードウェア構成の一例を示す図である。上述の需要予測装置１は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。需要予測装置１のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

需要予測装置１における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、需要予測装置１における前処理部１３などは、プロセッサ１００１で実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、需要予測装置１の需要予測部１４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（ElectricallyErasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述の需要予測装置１の乗車履歴取得部１１などは、通信装置１００４で実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、ＬＥＤランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間において異なるバスで構成されてもよい。

また、需要予測装置１は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

以上、本実施形態について詳細に説明したが、当業者にとっては、本実施形態が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本実施形態は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本実施形態に対して何ら制限的な意味を有するものではない。

本明細書で説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。

また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。

上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。

ユーザ端末は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

「含む（include）」、「含んでいる（including）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える(comprising)」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

本明細書において、文脈または技術的に明らかに1つのみしか存在しない装置である場合以外は、複数の装置をも含むものとする。

本開示の全体において、文脈から明らかに単数を示したものではなければ、複数のものを含むものとする。

１…需要予測装置、１１…乗車履歴取得部、１２…乗車履歴ＤＢ、１３…前処理部、１４…需要予測部、１５…出力部。

Claims (7)

1. 乗車日時を示す情報、及び、乗車場所を示す位置情報を含む、営業用車両に関する複数の乗車履歴情報を取得する乗車履歴取得部と、
   前記複数の乗車履歴情報を用いた空間クラスタリングにより、前記車両の需要予測を行う需要予測部と、
   前記需要予測部による需要予測結果を出力する出力部と、
   を有する、需要予測装置。
2. 前記乗車履歴情報は、車両の進行方向を示す情報を含み、
   前記需要予測部は、前記車両の進行方向毎に需要予測を行う、請求項１に記載の需要予測装置。
3. 前記複数の乗車履歴情報から、前記空間クラスタリングに用いる前記乗車履歴情報を抽出する前処理部を有し、
   前記需要予測部は、前記前処理部により抽出された前記乗車履歴情報に基づいて需要予測を行う、請求項１又は２に記載の需要予測装置。
4. 前記前処理部は、前記乗車日時を示す情報が特定の条件を満たす前記乗車履歴情報を抽出する、請求項３に記載の需要予測装置。
5. 前記前処理部は、前記位置情報が特定の条件を満たす前記乗車履歴情報を抽出する、請求項３に記載の需要予測装置。
6. 前記需要予測部は、前記需要予測結果の妥当性を検証し、前記需要予測結果が妥当でない場合には、前記空間クラスタリングにおける条件を変更して前記空間クラスタリングを再度実施する、請求項１〜５のいずれか一項に記載の需要予測装置。
7. 前記出力部は、前記需要予測結果において需要が高いと予測された位置に関する情報を、地図情報と重ね合わせて表示する、請求項１〜６のいずれか一項に記載の需要予測装置。

Images