WO2019235252A1 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

本技術は、乗車率の向上に貢献する予測結果を提示することができるようにする情報処理装置、情報処理方法、およびプログラムに関する。 情報処理装置は、営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した複数のエリアのうち、注目するエリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる表示制御部を備える。本技術は、例えば、タクシーの乗車需要の予測結果を表示する情報処理装置等に適用できる。

Description

情報処理装置、情報処理方法、およびプログラム

　本技術は、情報処理装置、情報処理方法、およびプログラムに関し、特に、乗車率の向上に貢献する予測結果を提示することができるようにした情報処理装置、情報処理方法、およびプログラムに関する。

　タクシー業界において、タクシーの需要を予測し、より効果的な営業を実施する取り組みが活発化してきている（例えば、特許文献１参照）。

特開２０１７－１９４８６３号公報

　タクシーの需要を予測するシステムにおいて乗車率を上げるためには、どのような予測結果を提示するかが重要である。

　本技術は、このような状況に鑑みてなされたものであり、乗車率の向上に貢献する予測結果を提示することができるようにするものである。

　本技術の一側面の情報処理装置は、営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる表示制御部を備える。

　本技術の一側面の情報処理方法は、情報処理装置が、営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる。

　本技術の一側面のプログラムは、コンピュータに、営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる処理を実行させるためのものである。

　本技術の一側面においては、営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離が、予測結果として表示部に表示される。

　なお、プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。

　なお、本技術の一側面の情報処理装置は、コンピュータにプログラムを実行させることにより実現することができる。

　また、本技術の一側面の情報処理装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。

　情報処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

　本技術の一側面によれば、乗車率の向上に貢献する予測結果を提示することができる。

　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術を適用した予測システムの一実施の形態の構成例を示すブロック図である。 需要予測アプリによる需要予測画面の例を示す図である。 予測システムの構成例を示すブロック図である。 車両動態ログデータの例を示す図である。 実車データの生成例を説明する図である。 実車シーケンスデータの例を示す図である。 実車シーケンスデータ生成処理を説明するフローチャートである。 学習予測処理を説明するフローチャートである。 第１のクラスタリングの結果例を示す図である。 第１のクラスタリングの結果例を示す図である。 ２段階クラスタリングの結果例を示す図である。 未知エリアクラスタ分類処理を説明するフローチャートである。 需要予測画面の第１表示例を示す図である。 需要予測画面の第２表示例を示す図である。 需要予測画面の第３表示例を示す図である。 乗車位置の学習を説明する図である。 需要予測画面の第４表示例を示す図である。 需要予測画面の第５表示例を示す図である。 需要予測画面の第６表示例を示す図である。 乗車料金予測画面の例を示す図である。 乗車位置の学習を説明する図である。 降車位置の学習を説明する図である。 乗車位置の学習を説明する図である。 広域地図表示の場合の需要予測画面の例を示す図である。 詳細地図表示の場合の需要予測画面の例を示す図である。 詳細地図表示のその他の例を示す図である。 音声案内制御処理を説明するフローチャートである。 得意なエリアを抽出するヒートマップを説明する図である。 おすすめルート提示画面の表示例を示す図である。 ルート提示処理を説明するフローチャートである。 乗車点のスコアの付与について説明する図である。 乗車禁止地区を表示した需要予測画面の例を示す図である。 付け場所を表示した需要予測画面の例を示す図である。 終電の電車時刻を表示した需要予測画面の例を示す図である。 逆引き乗車点表示機能が実行された需要予測画面の例を示す図である。 逆引き乗車点表示機能が実行された需要予測画面の例を示す図である。 配車／流し／付けを区別した需要予測画面の例を示す図である。 平均乗車料金と信頼区間を表示した需要予測画面の例を示す図である。 リアルタイムの空車台数を表示する需要予測画面の例を示す図である。 リアルタイムの空車台数を表示する需要予測画面の例を示す図である。 １日の営業評価情報を出力する評価画面の例を示す図である。 運行履歴画面の例を示す図である。 距離や方角を考慮して付加情報を表示した需要予測画面の例を示す図である。 進行方向に応じた情報を表示した需要予測画面の例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。

　以下、本技術を実施するための形態（以下、実施の形態という）について説明する。なお、説明は以下の順序で行う。
１．予測システムの構成例
２．需要予測アプリの画面例
３．ブロック図
４．実車シーケンスデータ生成処理
５．学習予測処理
６．未知エリアクラスタ分類処理
７．エリアARの結合表示
８．需要方向と頻度の表示
９．ピンポイント予測の表示
１０．付け待ち時間予測の表示
１１．ロング度予測の表示
１２．乗車距離予測の表示
１３．乗車料金予測の表示
１４．乗車位置の学習
１５．降車位置の学習
１６．乗車位置の学習
１７．音による乗車需要ガイド
１８．おすすめルート提示処理
１９．乗車禁止地区案内表示
２０．付け場所表示
２１．電車時刻表示
２２．逆引き乗車点表示
２３．配車／流し／付け待ちの需要予測分類表示
２４．乗車料金予測の表示
２５．リアルタイム空車台数の表示
２６．１日の営業評価の表示
２７．距離および方角を考慮した付加情報の表示
２８．進行方向に応じた情報の表示
２９．コンピュータ構成例

＜１．予測システムの構成例＞
　図１は、本技術を適用した予測システムの一実施の形態の構成例を示している。

　図１の予測システム１は、複数のタクシー１１と、サーバ（情報処理装置）１２とで構成され、タクシー１１から取得されるデータに基づいて、タクシー１１の営業地域における乗車の需要を予測するシステムである。

　タクシー１１は、所定の営業地域を走行して、乗客を乗車させる営業車両である。タクシー１１には、料金メータ２１、車両管理装置２２、および、端末装置２３が、搭載されている。

　料金メータ２１は、ドライバによる「実車」および「空車」の操作を受け付ける。「実車」とは、乗客を乗車させて走行している状態を表し、「空車」とは、乗客を乗車させずに走行している状態を表す。料金メータ２１は、「実車」時には、走行した時間または距離の少なくとも一方に応じて料金（運賃）を計算し、所定の表示部に表示する。

　車両管理装置２２は、タクシー１１が走行した位置（経路）、「実車」または「空車」のステータスなどを所定の時間間隔で時系列に記録した車両動態ログデータを生成し、所定のネットワークを介して、サーバ１２に送信する。「実車」または「空車」のステータスは、料金メータ２１から取得される。

　端末装置２３は、例えば、スマートフォンやタブレット端末等の情報処理装置で構成される。端末装置２３には、サーバ１２から送信されてくる乗車需要予測データを用いて、乗車の需要予測をディスプレイに表示するアプリケーションプログラム（以下、単に、需要予測アプリとも称する）が格納されている。

　需要予測アプリは、ドライバの操作によって、端末装置２３上で起動され、実行される。需要予測アプリは、所定のネットワークを介して、サーバ１２から送信されてくる乗車需要予測データを受信し、受信した乗車需要予測データに基づいて、地図上に乗車需要を予測した予測結果をディスプレイに表示する。乗車需要を予測した予測結果の具体的な表示例は、図２等を参照して後述する。

　サーバ１２は、ネットワークを介して、複数のタクシー１１から、車両動態ログデータを取得する。そして、サーバ１２は、取得した多数の車両動態ログデータを用いて、乗車需要予測データを生成し、複数のタクシー１１それぞれへ、ネットワークを介して送信する。

　サーバ１２、車両管理装置２２、および、端末装置２３を接続するネットワークは、例えば、所謂3G回線や4G回線等の移動体通信網、インターネット、公衆電話回線網、衛星通信網などで構成される。

　タクシー１１のドライバは、需要予測アプリによって端末装置２３のディスプレイに表示された、乗車需要予測を参考にしながら、乗客獲得のため、タクシー１１を運転する。

＜２．需要予測アプリの画面例＞
　図２は、端末装置２３において需要予測アプリによって表示された需要予測画面の例を示している。

　図２の需要予測画面には、地図４１が表示されるとともに、現在地マーク６１、拡大縮小ボタン６２、需要予測メッシュ６３、設定ボタン６４などが、地図４１の上に重畳表示されている。

　また、需要予測画面には、地図４１の表示領域とは異なる領域に、予測時刻設定領域４２が設けられており、予測時刻設定領域４２には、予測時刻表示７１と、予測時刻変更ボタン７２Aおよび７２Bが含まれる。

　現在地マーク６１は、タクシー１１の現在地を表す。拡大縮小ボタン６２は、地図４１の縮尺を拡大したり、縮小したりする場合に操作される。

　需要予測メッシュ６３は、複数のエリアARを行列状に配置されて構成される。エリアARは、需要予測メッシュ６３を格子状に分割した１つの領域を表す。なお、図２の例では、地図４１上の一部の領域に、4ｘ7の２８個のエリアARが配置されているが、地図４１上の全ての領域にエリアARを重畳表示させてもよい。

　需要予測メッシュ６３の各エリアARは、サーバ１２から送信されてきた乗車需要予測データに基づいて、乗車需要の度合いに応じた色や濃度で表示されている。例えば、図２において、濃度が濃いエリアARは、乗車需要が高いエリアARを表し、濃度が薄いエリアARは、乗車需要が低いエリアARを表す。

　設定ボタン６４は、需要予測画面で表示可能な項目の選択や、表示の順番など、需要予測画面の表示に関する各種の設定を行う際に操作される。需要予測画面で表示可能な各項目の詳細は後述する。

　予測時刻設定領域４２の予測時刻表示７１は、需要予測メッシュ６３が表示している需要予測の該当時刻を表示する。すなわち、需要予測メッシュ６３には、予測時刻表示７１に表示されている時刻の需要予測が表示される。予測時刻表示７１をタップすると、現在の時刻にリセットされる。予測時刻変更ボタン７２Aおよび７２Bは、予測時刻表示７１の予測時刻を所定単位（例えば、１０分）で進めたり、戻したりする場合に操作される。

　以上のように、端末装置２３の需要予測アプリは、サーバ１２から送信されてくる乗車需要予測データを受信し、受信した乗車需要予測データに基づいて、地図４１上に乗車需要を予測した需要予測メッシュ６３を、予測結果としてディスプレイに表示する。

　なお、図２の例では、需要予測メッシュ６３の各エリアARが、乗車需要の度合いに応じて、色や濃度が異なる表示で表示されることとしたが、後述する図１３に示されるように、乗車数の予測結果を併せて表示することもできる。

＜３．ブロック図＞
　次に、タクシー１１に搭載された各装置、および、サーバ１２の詳細構成について説明する。

　図３は、サーバ１２、料金メータ２１、車両管理装置２２、および、端末装置２３の構成例を示すブロック図である。

　料金メータ２１は、ドライバによる「実車」または「空車」の操作を受け付け、「実車」または「空車」のステータスと、料金（運賃）を所定の表示部に表示する。料金メータ２１は、「実車」または「空車」のステータスを、車両管理装置２２に供給する。

　車両管理装置２２は、位置検出部１０１、速度検出部１０２、制御部１０３、記憶部１０４、および、通信部１０５を備える。

　位置検出部１０１は、例えば、GPS (Global Positioning System)受信機等で構成され、測位衛星が放送する測位信号を受信してタクシー１１の現在位置を検出する。また、位置検出部１０１は、ジャイロセンサ、地磁気センサ等を備え、タクシー１１の進行方向を検出する。

　速度検出部１０２は、速度センサや加速度センサ等で構成され、タクシー１１の移動速度を検出する。なお、速度検出部１０２は、タクシー１１のホイールの回転速度を検出する速度センサから測定値を取得することにより、タクシー１１の移動速度を検出してもよい。

　制御部１０３は、例えば、CPU（Central Processing Unit）、RAM（Random Access Memory）等で構成され、記憶部１０４に記憶されている動作制御プログラムを読み出し、動作制御プログラムにしたがって、車両管理装置２２全体の動作を制御する。具体的には、制御部１０３は、料金メータ２１、位置検出部１０１、および、速度検出部１０２のそれぞれから、一定時間間隔でデータを取得して、車両動態ログデータを生成し、記憶部１０４に記憶させる。また、制御部１０３は、記憶部１０４に記憶されている車両動態ログデータを、予め設定された所定のタイミングで、定期的または不定期に、通信部１０５を介して、サーバ１２に送信する。

　記憶部１０４は、例えば、ハードディスク、ROM（Read Only Memory）、RAM、およびNVRAM（Non Volatile RAM）などで構成され、車両動態ログデータを記憶する。通信部１０５は、制御部１０３の制御に従い、サーバ１２と所定の通信を行う。通信部１０５は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。

　サーバ１２は、制御部１２１、記憶部１２２、および、通信部１２３を備える。

　制御部１２１は、例えば、CPU、RAM等で構成され、記憶部１２２に記憶されている動作制御プログラムを読み出し、動作制御プログラムにしたがって、サーバ１２全体の動作を制御する。

　制御部１２１は、機能的には、データ生成部１３１、学習部１３２、および、予測部１３３を少なくとも備え、機械学習により、地図４１上のエリアARごとの乗車需要を予測する。機械学習の手法は、例えば、k-means法、自己組織化マップ（SOM）、ニューラルネットワーク、HMM（隠れマルコフモデル）など、任意の手法を選択することができる。

　データ生成部１３１は、通信部１２３を介して複数のタクシー１１の車両管理装置２２それぞれから取得した車両動態ログデータを記憶部１２２に記憶させる。

　図４は、タクシー１１の車両管理装置２２によって生成され、サーバ１２へ送信されてくる車両動態ログデータの例を示している。

　車両管理装置２２は、所定の時間間隔（例えば、１分間隔）で、車両動態ログデータを生成し、蓄積する。

　車両動態ログデータとして生成される項目には、図４に示されるように、タクシー１１が所属する会社を識別する会社ID、タクシー１１の車両を識別する無線ID、タクシー１１に乗務しているドライバを識別する乗務員ID、ステータスの生成時刻を表すステータス時刻、タクシー１１の位置情報である緯度および経度、タクシー１１の走行速度および進行方向を示す方向および速度、並びに、「実車」または「空車」のステータスが含まれる。

　データ生成部１３１は、記憶部１２２に記憶された車両動態ログデータから、実車に関するデータである実車データを生成する。

　図５は、実車データの生成例を示している。

　実車データは、車両動態ログデータから、タクシー１１の乗車に関する情報を抽出したデータであり、車両動態ログデータにおいて、ステータスが「空車」から「実車」となる乗車変化点と、「実車」から「空車」となる降車変化点の情報から生成される。

　実車データには、例えば、図５に示されるように、ID、乗車時刻、出発地点、到着地点、乗車時間、乗車距離、および、運賃の各項目が含まれる。

　IDは、車両動態ログデータの会社ID、無線ID、および乗務員IDを結合したデータである。

　乗車時刻には、乗車変化点の「空車」のステータス時刻と、「実車」のステータス時刻との間の時刻が算出され、記録される。

　出発地点には、乗車変化点の「空車」の緯度および経度と、「実車」の緯度および経度との間の緯度および経度が算出され、記録される。

　到着地点には、降車変化点の「空車」の緯度および経度と、「実車」の緯度および経度との間の緯度および経度が算出され、記録される。

　乗車時間には、乗車時刻から、降車変化点の「空車」のステータス時刻と、「実車」のステータス時刻との間の時刻までの時間（単位は例えば、分）が算出され、記録される。

　乗車距離には、出発地点から到着地点までの距離（単位は例えば、km）が算出され、記録される。

　運賃は、乗車時間と乗車距離から、タクシー運賃の規定に従って算出され、記録される。

　なお、実車データの各項目の算出方法は、上述した方法に限定されず、それ以外の方法でもよい。例えば、ステータスが「実車」となっている最初と最後の車両動態ログデータから上記の各項目を算出してもよい。また、運賃や乗車距離の情報は、乗車変化点と降車変化点の位置から計算するのではなく、車両動態ログデータの一部として車両管理装置２２から取得するようにしてもよい。

　データ生成部１３１は、多数のタクシー１１の車両管理装置２２の車両動態ログデータから生成された多数の実車データに基づいて、所定の時間単位（１０分間）の乗車数を表す時系列データである実車シーケンスデータを、エリアARごとに生成する。例えば、データ生成部１３１は、１０分ごとの乗車数をカウントした時系列データである実車シーケンスデータを、エリアARごとに生成する。

　図６は、タクシー１１の営業地域を分割して得られる複数のエリアARのうち、エリア１２２３、エリア１２２４、および、エリア１２２５の３つのエリアARの実車シーケンスデータの例を示している。

　実車シーケンスデータの横軸は日付および時刻であり、縦軸は、乗車数を表す。図６に示される実車シーケンスデータは８日間分のデータであるが、実車シーケンスデータの作成期間は、１週間、１か月、１年間等、任意の期間に設定することができる。例えば、実車シーケンスデータの作成期間を、１週間に設定すると曜日による変動を捉えることができ、数か月や１年間等の長期に設定すると、曜日による変動の他、年末年始やゴールデンウイーク、夏休み等の季節的な変動も捉えることができる。

　エリア１２２３の実車シーケンスデータ例で言えば、例えば、乗車時刻が２０１７年３月２１日の１０時から１０時１０分の間に含まれ、出発地点がエリア１２２３内に位置する実車データの数が、乗車数としてカウントされる。そのカウント結果が、２０１７年３月２１日の１０時から１０時１０分のエリア１２２３の実車シーケンスデータとなる。同様の処理が、取得された実車データの全期間で算出され、エリア１２２３の実車シーケンスデータが生成される。

　図３に戻り、学習部１３２は、多数のタクシー１１の車両管理装置２２から取得した実車データに基づいて生成された、多数かつ長期間の実車シーケンスデータを用いて、乗車需要を予測する予測器を学習により生成する。

　予測部１３３は、学習部１３２により生成された予測器を用いて、所定の時刻または時間帯の乗車需要を予測する。予測部１３３の予測結果は、乗車需要予測データとして、端末装置２３に送信される。

　記憶部１２２は、車両管理装置２２それぞれから取得した車両動態ログデータ、および、車両動態ログデータから生成された実車シーケンスデータを記憶する。車両動態ログデータから実車シーケンスデータを生成するための中間データである実車データも、記憶部１２２に記憶してもよい。

　通信部１２３は、制御部１２１の制御に従い、車両管理装置２２および端末装置２３と所定の通信を行う。通信部１２３は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。

　端末装置２３は、制御部１４１、操作部１４２、表示部１４３、通信部１４４、スピーカ１４５、および、マイクロホン１４６を備える。

　制御部１４１は、例えば、CPU、RAM等で構成され、図示せぬ記憶部に記憶されている動作制御プログラムにしたがって、端末装置２３全体の動作を制御する。例えば、制御部１４１は、ユーザであるドライバの操作に基づいて、需要予測アプリを実行する。そして、制御部１４１は、表示部１４３を制御する表示制御部としても機能し、需要予測アプリの実行結果、例えば、図２の需要予測画面などを、表示部１４３に表示させる。

　操作部１４２は、端末装置２３に設けられた複数の操作ボタン、表示部１４３に重畳されたタッチパネル等で構成され、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部１４１に供給する。

　表示部１４３は、例えば、LCD(Liquid Crystal Display)等で構成され、図２の需要予測画面など、所定の情報を表示する。

　通信部１４４は、制御部１４１の制御に従い、サーバ１２と所定の通信を行う。通信部１４４は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。

　スピーカ１４５は、電子音、効果音、メッセージの音声などの音を出力する。マイクロホン１４６は、ユーザが発する音声を検出したり、周囲音を収集する。

　サーバ１２、料金メータ２１、車両管理装置２２、および、端末装置２３は、以上のように構成されている。

　以下では、サーバ１２、車両管理装置２２、および、端末装置２３のそれぞれが実行する処理の詳細について説明する。

＜４．実車シーケンスデータ生成処理＞
　初めに、図７のフローチャートを参照して、サーバ１２による実車シーケンスデータ生成処理について説明する。この処理は、例えば、定期的または不定期等の所定のタイミングで実行することができる。

　初めに、ステップＳ１において、サーバ１２のデータ生成部１３１は、複数のタクシー１１の車両管理装置２２それぞれから、ネットワークを介して送信されてくる車両動態ログデータを取得（受信）する。なお、各車両管理装置２２は、車両動態ログデータを任意のタイミングで個別にサーバ１２へ送信することができ、同時である必要はない。

　ステップＳ２において、データ生成部１３１は、取得した車両動態ログデータから、実車データを生成する。実車データは、例えば、乗車時刻や出発地点などのように、車両動態ログデータの項目から算出されるデータと、運賃などのように、サーバ１２側で追加される外部データとを含む。外部データとしては、その他、例えば、曜日や平日または休日などの日付に関連する日付関連情報、該当するエリアARでデータ取得日に行われたイベント等に関するイベント情報、天候の情報などを設けることができる。実車データとして外部データを付加することにより、例えば、曜日ごとや、イベントの有無、天候などに応じた状況毎の乗車需要を学習および予測することができる。

　ステップＳ３において、データ生成部１３１は、多数のタクシー１１の車両管理装置２２から生成された多数の実車データに基づいて、エリアARごとの実車シーケンスデータを生成し、記憶部１２２に記憶して、実車シーケンスデータ生成処理を終了する。

＜５．学習予測処理＞
　次に、図８のフローチャートを参照して、生成されたエリアARごとの実車シーケンスデータを用いて乗車需要を学習および予測する学習予測処理について説明する。この処理も、例えば、定期的または不定期等の所定のタイミングで実行することができる。

　初めに、ステップＳ２１において、サーバ１２の学習部１３２は、タクシー１１の営業地域を分割して得られる複数のエリアARのなかから、代表エリアを抽出する。学習部１３２は、複数のエリアARのなかから、予め決定した所定数だけ、エリアARを選択して、代表エリアとする。代表エリアは、ランダムに決定してもよいし、例えば、都心部のエリアARと郊外のエリアAR、駅に近いエリアARと駅が遠いエリアAR、または、駅が多いエリアARと駅が少ないエリアARなど、知見を持つユーザが、所定の基準で選択してもよい。

　ステップＳ２２において、学習部１３２は、代表エリアとして抽出された各エリアARの実車シーケンスデータを用いて、２段階クラスタリングを実施する。より具体的には、学習部１３２は、第１のパラメータを用いて、抽出された複数の各エリアARをクラスタリングする第１のクラスタリングを実行し、第２のパラメータを用いて、抽出された複数の各エリアARをクラスタリングする第２のクラスタリングを実行する。

　例えば、学習部１３２は、第１のパラメータとして、エリアAR内における単位時間当たり（例えば、１日）の乗車数の平均と分散を用いて、第１のクラスタリングを実行し、第２のパラメータとして、エリアAR内における単位時間当たり（例えば、１日）の平均乗車数の波形を用いて、第２のクラスタリングを実行する。なお、クラスタリングの手法は、例えば、k-means法などを用いることができる。

　図９および図１０は、乗車数の平均と分散をパラメータとして、代表エリアである複数のエリアARをクラスタリングした第１のクラスタリングの結果例を示している。

　図９は、横軸を平均、縦軸を分散として、代表エリアとして抽出された複数のエリアARの分布を示している。

　図１０は、代表エリアである複数のエリアARの実車シーケンスデータを、クラスタごとに示した図である。図１０の横軸は時刻（０時から２４時）、縦軸は乗車数を表す。

　実車シーケンスデータは、基本的には、１日の各時間帯（朝、昼、夜など）ごとに同様の特徴が現れるため、クラスタリングは、実車シーケンスデータを基本単位（１日）毎に分割したデータを用いて行われている。

　図９および図１０では、代表エリアとして抽出された複数のエリアAR（の実車シーケンスデータ）が、６個のクラスタに分類されている。

　図１１は、第１のクラスタリングのクラスタリング結果と、第２のクラスタリングのクラスタリング結果をまとめた、２段階クラスタリング結果の例を示している。

　図１１において、横方向（列単位）が１段階目のクラスタリング結果を表し、縦方向（行単位）が２段階目のクラスタリング結果を表す。行列状に配置された各グラフの横軸および縦軸は図１０と同様である。

　図１１において、列番号１、列番号２、列番号３、・・・・が、第１のクラスタリングによるクラスタリング結果であり、縦方向に並ぶ複数のエリアARが乗車数の平均と分散が類似するエリアARの集合（エリアAR群）となっている。一方、行番号A、行番号B、行番号C、・・・が、第２のクラスタリングによるクラスタリング結果であり、第１のクラスタリングのクラスタリング結果である各エリアAR群を、平均乗車数の波形が類似するエリアARでさらにクラスタリングした結果となっている。行列状の各グラフ内の数字は、そのクラスタに分類されたエリアARの数を表す。例えば、行番号Dおよび列番号２のクラスタD-2のグラフ内の数字「４６８」は、代表エリアのうち、４６８個のエリアARがクラスタD-2に分類されたことを表している。第１のパラメータとして用いた単位時間当たりの乗車数の平均と分散は、単位時間当たりの乗車数の大小と単位時間内の乗車数の変化の大きさを表し、第２のパラメータとして用いた単位時間当たりの平均乗車数の波形は、単位時間内の乗車数の時間による変化の傾向を表す。

　なお、２段階目のクラスタリングは、１段階目のクラスタリング結果毎に、個別に実行してもよいし、１段階目のクラスタリング結果とは別に、代表エリアとして抽出された複数のエリアAR全体で実行してもよい。

　本実施の形態では、例えば、タクシー１１の営業地域が、４４００個のエリアARに分割され、さらに４４００個のうち、半分の２２００個のエリアARを代表メッシュとして抽出し、２２００個のエリアARに対して、２段階クラスタリングを実施することにより、４４個のクラスタに分類されたこととする。

　次に、図８のステップＳ２３において、学習部１３２は、クラスタ毎に、クラスタに属する実車シーケンスデータを用いて、学習率などに代表される予測器の学習パラメータを調整して、ステップＳ２４に進む。

　ステップＳ２４において、学習部１３２は、調整された学習パラメータと、クラスタに属する１以上のエリアARの実車シーケンスデータを用いて、クラスタ毎に、乗車需要を予測する予測器を学習して、ステップＳ２５に進む。

　ステップＳ２５において、予測部１３３は、学習部１３２により生成された予測器を用いて、所定のエリアARにおける所定の時刻の乗車需要を予測する。例えば、クラスタC-4に属するエリアARの乗車需要を予測する場合、クラスタC-4の予測器を用いて、所定の時刻の乗車需要が予測される。

　ステップＳ２１乃至Ｓ２４の学習処理とステップＳ２５の予測処理は、連続する処理として実行してもよいし、ステップＳ２５の予測処理を、ステップＳ２１乃至Ｓ２４の処理とは異なるタイミングで実行してもよい。

　例えば、ステップＳ２５の処理は、ステップＳ２４の処理に続けて実行され、タクシー１１の営業地域を構成する各エリアARの所定の時刻の乗車需要が算出され、記憶部１２２に記憶される。そして、端末装置２３からの要求に応じて、記憶部１２２に記憶された需要の予測データが、乗車需要予測データとして、端末装置２３に送信される。

　あるいはまた、端末装置２３から、１以上のエリアARの所定の時刻の乗車需要の予測データが要求されたタイミングにおいて、ステップＳ２５の処理が実行され、ステップＳ２５の処理結果が、乗車需要予測データとして、端末装置２３に送信される。

　乗車需要予測データを受信した端末装置２３の需要予測アプリは、図２に示したように、予測結果である各エリアARの乗車数に応じて、色や濃度を変えた需要予測メッシュ６３を表示する。

　以上の学習予測処理によれば、営業地域を構成する４４００個のエリアARのうち、代表エリアとして抽出された２２００個のエリアARそれぞれが、所定のクラスタに分類され、分類結果に応じて、乗車需要を予測することができる。

　一方で、代表エリアとして抽出されなかった残りの２２００個のエリアAR（以下、未知エリアARとも称する。）については、この段階では、どのクラスタに分類されるかが不明であり、乗車需要を予測することができない。

＜６．未知エリアクラスタ分類処理＞
　そこで次に、未知エリアARの乗車需要を予測するための処理について説明する。

　図１２のフローチャートを参照して、未知エリアARが属するクラスタを判別する未知エリアクラスタ分類処理について説明する。この処理は、例えば、定期的または不定期等の所定のタイミングで実行することができる。

　初めに、ステップＳ４１において、サーバ１２の学習部１３２は、学習予測処理で分類された各クラスタの実車シーケンスデータの特徴（平均、分散、形状）を学習する。換言すれば、代表エリアとして抽出された２２００個のエリアARの実車シーケンスデータと、クラスタとの関係が、学習器で学習される。

　ステップＳ４２において、サーバ１２の予測部１３３は、ステップＳ４１の学習で得られたパラメータを用いた分類器に、未知エリアARの実車シーケンスデータを入力し、未知エリアARのクラスタを判別する。

　以上のように、未知エリアクラスタ分類処理によれば、代表エリアのクラスタリング結果と実車シーケンスデータとの関係を学習して生成した分類器を用いて、代表エリア以外の未知エリアARのクラスタリングを実行することができる。

　未知エリアARのクラスタが判別できると、判別されたクラスタの予測器を用いて、上述したステップＳ２５の予測処理を実行することで、未知エリアARの乗車需要を予測することができる。

　したがって、図８の学習予測処理および図１２の未知エリアクラスタ分類処理の両方を実行することで、タクシー１１の営業地域を構成する４４００個の全てのエリアARの乗車需要の予測が可能である。

　図８の学習予測処理では、ステップＳ２１の処理である代表エリアの抽出を行うことで、学習するエリアARの数、換言すれば、実車シーケンスデータのデータ量を減らすことができるので、演算負荷を軽減し、乗車需要予測にかかるコストよび時間を削減することができる。

　また、ステップＳ２２により、代表エリアとして抽出された各エリアARの実車シーケンスデータを用いて、２段階クラスタリングを実施することで、学習器の数を減らすことができ、乗車需要予測にかかるコストよび時間を削減することができる。具体的には、２段階クラスタリングを実施しない場合には、代表エリアとして抽出されたエリアAR数（２２００個）の学習器が必要となるが、２段階クラスタリングを実施し、所定数のクラスタに分類できたことにより、学習に必要な学習器の数をクラスタ数（４４個）とすることができる。

　各クラスタの学習器には、そのクラスタに分類された全てのエリアARの実車シーケンスデータを用いることができる。すなわち、例えば、エリア１２２３の乗車需要予測を学習する場合に、一般的には、そのエリア１２２３で取得された実車シーケンスデータのみを用いて学習が行われる。これに対して、本技術では、エリア１２２３が、例えば、クラスタD-2に分類され、クラスタD-2に属するエリアARが４６８個存在する場合に、エリア１２２３以外のエリアARを含めた４６８個のエリアARの実車シーケンスデータを用いて学習を行うことができる。したがって、１つの学習器に対して、１エリアARで取得できるデータ量よりも多いデータ量で学習を行うことができるので、予測精度を向上させることができる。

　そして、学習予測処理において代表エリアとして抽出されない未知エリアARについても、未知エリアクラスタ分類処理により、未知エリアARのクラスタを判別して、判別されたクラスタの予測器を用いて、未知エリアARの乗車需要を予測することができる。

　なお、上述したステップＳ２３およびＳ２４では、代表エリアとして抽出された各エリアARの実車シーケンスデータのみを用いて、学習パラメータの調整および予測器の学習を行ったが、営業地域に含まれる全ての未知エリアARについてクラスタが判別された後に、未知エリアARの実車シーケンスデータも加えて、学習パラメータの調整および予測器の学習を行ってもよい。

　したがって、図１の予測システム１によれば、より効率的に学習し、予測することができる。また、少ないデータ量で、予測精度を向上させることができる。

　上述した学習予測処理および未知エリアクラスタ分類処理では、曜日、平日、または、休日などに関係なく、複数のタクシー１１の車両管理装置２２から取得される全ての車両動態ログデータから生成した実車シーケンスデータを用いて、クラスタ分類や学習を行った。

　しかしながら、実車シーケンスデータを、曜日、平日、休日、または、天候、などのカテゴリに分けて、カテゴリごとに、クラスタ分類や学習を行うようにしてもよい。これにより、曜日、平日、休日、天候、イベントの有無など、所定の条件ごとに乗車需要を予測し、予測結果をディスプレイに表示することができる。

＜７．エリアARの結合表示＞
　以下では、端末装置２３の需要予測アプリが乗車需要の予測結果をディスプレイに表示する各種の表示例について説明する。

　図１３は、需要予測アプリが表示する需要予測画面の第１表示例を示している。

　図２に示した需要予測画面では、需要予測メッシュ６３は、同一の矩形サイズのエリアARを行列状に配置して構成されていた。また、予測結果である各エリアARの乗車数は、画面上に表示されていなかった。

　これに対して、図１３の需要予測メッシュ６３では、予測結果である各エリアARの乗車数が、エリアAR内に表示されている。

　また、需要予測アプリは、隣接する複数のエリアARの乗車数が所定の閾値以下となる複数のエリアARについては、１つのエリアARに結合して、乗車数を表示している。図１３の第１表示例では、隣接する複数のエリアARの乗車数が１０人以下となる複数のエリアARが、１つのエリアARとして結合して表示されている。具体的には、同一の矩形サイズで表示した場合の乗車数が、「４」、「２」、「２」、および、「１」となるような２×２のエリアARが、１つのエリアARに結合され、「９」として表示されている。なお、勿論、隣接の乗車数によっては、１０以下であっても結合されない場合もある。

　予測される乗車数が、例えば、０、１、２など小さい場合に、需要を当てることは難しいため、需要予測アプリは、乗車数が一定以上の値となるようなエリアAR単位で、需要予測を表示することができる。これにより、予測の精度を向上させることができ、より有用な情報をドライバに提供することができる。

　なお、予測結果として表示する乗車数は、例えば、「１０－１３」のように、ある程度の幅を持たせた値でもよい。

＜８．需要方向と頻度の表示＞
　図１４は、需要予測アプリが表示する需要予測画面の第２表示例を示している。

　図１４では、各エリアARの乗車需要の度合いに応じた色や濃度の表示は省略されている。

　図１４は、地図４１に重畳表示された需要予測メッシュ６３の各エリアARのうち、ドライバが注目するエリアAR(以下、注目エリアARと称する。)について、さらに詳細な予測結果を表示する表示例を示している。

　ドライバが、地図４１に重畳表示された需要予測メッシュ６３の各エリアARのなかから、所定のエリアARをタップ（タッチ）するなど、注目エリアARを指定する操作を行うと、需要予測アプリは、指定された注目エリアARに対して、図１４に示されるような表示を行う。

　図１４では、ドライバにより指定された注目エリアARに対して、他のエリアARよりも太い幅の枠である注目エリア枠２１１が表示されている。そして、注目エリア枠２１１から外側に向かう矢印２１２－１乃至２１２－８が表示されている。矢印２１２－１乃至２１２－８それぞれを特に区別しない場合には、単に矢印２１２と称する。

　矢印２１２の方向は、注目エリアARで乗車する乗客の移動方向を表し、矢印２１２の長さは、注目エリアARで乗車し、矢印２１２の方向へ移動する乗客の平均的な移動距離を表す。また、矢印２１２の幅（矢の方向に垂直な方向の太さ）は、全方向に対する、その矢印２１２が示す方向の乗車の割合を表す。

　したがって、図１４の例では、注目エリアARで乗車する乗客は、乗車の割合としては、矢印２１２－３の方向へ移動する乗客が多く、矢印２１２－４の方向へ移動する乗客は、移動距離が長いことを示している。また例えば、注目エリアARで乗車する乗客のうち、矢印２１２－２や矢印２１２－６へ移動する乗客は少なく、移動距離も短いことを示している。

　ドライバは、例えば、いわゆる「流し」（タクシー１１を走らせながら、乗客を探すこと）を行うエリアARを決定する際、需要予測メッシュ６３の所定のエリアARを注目エリアARに設定し、矢印２１２を表示させることで、ドライバが帰る方向と同じ方向の乗客が多いエリアARを探す、などを行うことができる。

　各エリアARの乗客の移動方向は、車両動態ログデータの方向（進行方向）の情報も含めて学習することで予測することができる。

　なお、矢印２１２を表示する数、換言すれば、乗客の移動方向の予測数は、図１４に示した８以外の数であってもよい。また、全方向における矢印２１２の方向へ移動する乗客の割合は、矢印の幅で表す以外の方法、例えば、色の違いや数字の表記などで表してもよい。

＜９．ピンポイント予測の表示＞
　図１５は、需要予測アプリが表示する需要予測画面の第３表示例を示している。

　図１５も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。

　営業地域を所定の単位で分割したエリアARのなかには、例えば、駅前やホテル前のタクシー乗り場など、乗車位置が決まっており、他と比較して乗車数が多い場所が存在することがある。

　そのような乗車数が多い乗車位置が注目エリアAR内に存在する場合、需要予測アプリは、注目エリアAR全体の乗車数とは別に、乗車数が多い乗車位置と、その乗車位置での乗車数をピンポイントで予測して表示することができる。以下では、注目エリアAR内で特定された、乗車数が多い乗車位置をピンポイント乗車位置と称する。

　図１５では、注目エリアAR内の所定の位置に、ピンポイント乗車位置を表すピンポイント乗車位置マーク２２１が表示され、そのピンポイント乗車位置マーク２２１において予測される乗車数を表示する乗車数表示２２２が表示されている。図１５において、注目エリア枠２１１内に表示された「４３」は、注目エリアAR全体としての乗車数であり、そのうち、乗車数表示２２２の「２９」は、ピンポイント乗車位置マーク２２１のピンポイント乗車位置「品川駅高輪口タクシー乗り場」における乗車数を示している。このように、注目エリアARの乗車数に加えて、ピンポイント乗車位置と、そこで予測される乗車数を表示することにより、実車率を上げることができる。

　ピンポイント乗車位置は、エリアAR内において乗車位置が決まっている場所を一つ一つ調査するのではなく、実車データを用いて学習することで推定することができる。

　具体的には、図１６の左側の黒丸で示されるように、乗客の過去の乗車位置は、実車データの出発地点の情報から把握できる。乗客の過去の乗車位置を学習することにより、図１６の右側に示されるように、黒丸で示される乗車位置の推定値と、その乗車位置の確率（尤度）が算出される。乗車位置の確率は、０乃至１の範囲の数字で表され、図１６では、乗車位置の近傍に表示されている。需要予測アプリは、例えば、乗車位置の確率が所定の閾値（例えば、０．８）以上の乗車位置の推定値を、注目エリアAR内における、ピンポイント乗車位置として表示することができる。

＜１０．付け待ち時間予測の表示＞
　図１７は、需要予測アプリが表示する需要予測画面の第４表示例を示している。

　図１７も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。

　駅前やホテル前のタクシー乗り場など、乗車位置が決まっていて、乗車数が多い場所では、いわゆる「付け待ち」と呼ばれる、乗車位置で乗客を乗せるタクシー１１の列に並んでタクシー１１を待機させた状態で乗客を獲得する方法がある。付け待ちの不利な点は、例えば、タクシー乗り場でタクシー１１の長い列ができている場合に、タクシー１１の長い列の最後に並んでから、乗客を乗せるまでの時間がかかるということである。

　そこで、需要予測アプリは、乗車数が多い乗車位置（ピンポイント乗車位置）で、付け待ちが行われている場合に、付け待ちにかかる時間、換言すれば、乗車位置で待って乗客を乗せるまでに要する時間を表示することができる。

　具体的には、図１７に示されるように、注目エリアAR内のピンポイント乗車位置マーク２２１が付け待ちの場所である場合に、需要予測アプリは、ピンポイント乗車位置マーク２２１での乗車数表示２２２内に、付け待ち開始ボタン２２３を表示させる。需要予測アプリは、付け待ち開始ボタン２２３がタップ（タッチ）された場合、付け待ちを行った場合の付け待ちに要する時間（付け待ち時間）を示す付け待ち表示２２４を表示する。図１７の例では、付け待ち時間として「２０分」が表示されている。

　例えば、ドライバは、ピンポイント乗車位置において、付け待ち表示２２４を表示させることにより、付け待ち時間を確認し、付け待ちする場所を選択することができる。付け待ち表示２２４に表示される付け待ち時間は、「１５分－２０分」のように、一定の幅を持った値でもよい。

　車両動態ログデータでは、ステータスが「空車」から「実車」となる乗車変化点と、その乗車変化点より少し前において、タクシー１１がゆっくりと移動している状態を検出することができるので、タクシー１１の付け待ち動作を検出することができる。例えば、乗車変化点の時刻より前の所定期間内または所定距離内における所定速度以下(時速5km/ｈ以下)での走行を付け待ち動作として検出することができる。したがって、付け待ち動作を学習することにより、所定の乗車位置における付け待ち時間を予測することができる。

＜１１．ロング度予測の表示＞
　図１８は、需要予測アプリが表示する需要予測画面の第５表示例を示している。

　図１８も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。

　営業地域を所定の単位で分割したエリアARのなかには、例えば、羽田空港や成田空港を目的地とする場合など、乗車距離が長距離（所定の距離以上）となる乗車の割合が多いエリアARや乗車位置がある。ドライバが、長距離の乗客の可能性を判断できることが好ましい。

　そこで、需要予測アプリは、図１８に示されるように、注目エリアAR全体の乗車数とは別に、注目エリアARの長距離の乗客の割合を表示するロング表示２４１を行うことができる。

　ロング表示２４１では、注目エリアARの全乗車数のうち、乗車距離が長距離となる乗車の割合（比率）が、ロング度として表示される。また、ロング表示２４１では、乗車距離を複数の区分に分割し、分割した区分ごとの乗車の割合が、ロング区分として、棒グラフで表示される。図１８に示される「All」の棒グラフは、営業地域全体における区分ごとの乗車の割合を示し、「This」の棒グラフは、注目エリアARの区分ごとの乗車の割合を示している。

　ロング表示２４１は、図１８に示したように、注目エリアARについてのロング度およびロング区分を表示してもよいし、ピンポイント乗車位置マーク２２１に付随して表示させ、ピンポイント乗車位置についてのロング度およびロング区分を表示してもよい。

　図１８のロング表示２４１の棒グラフは、ロング区分として、乗車距離を複数の区分に分割して、分割した区分（乗車距離）ごとの乗車の割合を示したが、乗車料金を複数の区分に分割して、分割した区分（乗車料金）ごとの乗車の割合を示してもよい。

　また、ロング表示２４１は、時間帯や天候ごとに乗車需要を予測して、所定の時間帯や天候に特化したロング度やロング区分を表示してもよい。

　ロング度やロング区分は、実車データの乗車距離と運賃の項目を含めて学習することで、予測することができる。

＜１２．乗車距離予測の表示＞
　図１９は、需要予測アプリが表示する需要予測画面の第６表示例を示している。

　図１９も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。

　需要予測アプリは、図１９に示されるように、所定のエリアARが注目エリアARとして選択された場合、注目エリアARで乗車する乗客の平均乗車距離とその信頼区間を表示する乗車距離表示２５１を行うことができる。信頼区間は、母集団の平均値（母平均）が所定の信頼度で含まれる範囲を表す。

　乗車距離表示２５１では、注目エリアARにおける乗車の平均乗車距離が、「2.4km」であり、例えば９５％の信頼度における平均乗車距離の信頼区間が、「1.1kmから3.7km」であることが表示されている。信頼区間の信頼度は９５％に限定されず、９９％など任意に設定することができる。

　このように、注目エリアARの平均乗車距離およびその信頼区間を表示することにより、ドライバが、例えば、残りの勤務時間に適した乗車距離のエリアARを探したり、「流し」の経路として、乗車距離の長いエリアARを探したりすることができる。

　乗車距離表示２５１は、図１９に示したように、注目エリアARについて表示してもよいし、ピンポイント乗車位置マーク２２１に付随して表示させ、ピンポイント乗車位置についての平均乗車距離および信頼区間を表示してもよい。

　あるいはまた、平均乗車距離および信頼区間の代わりに、平均乗車料金（運賃）と信頼区間を示してもよい。

　あるいはまた、平均乗車距離および信頼区間の代わりに、平均乗車時間と信頼区間を示してもよい。

　また、乗車距離表示２５１は、時間帯や天候ごとに乗車需要を予測して、所定の時間帯や天候に特化した、平均乗車距離と信頼区間、平均乗車料金と信頼区間、または、平均乗車時間と信頼区間を表示してもよい。

＜１３．乗車料金予測の表示＞
　タクシー１１は、乗ってみないと乗車料金が確定しないため、利用を控える利用者も存在する。需要予測アプリは、現在地と目的地とから、乗車料金を予想して表示する機能を備える。

　図２０は、需要予測アプリが表示する乗車料金予測画面の例を示している。

　需要予測アプリは、目的地までの移動に要する時間および料金を予測結果としてディスプレイに表示させるとともに、目的地までの移動経路を所定の単位に分割した分割単位ごとの、移動に要する時間および料金を、予測結果としてディスプレイに表示させる。

　図２０の乗車料金予測画面において、個別表示２６１は、分割単位ごとの移動に要する時間および料金を示している。目的地表示２６２は、目的地までの移動に要する時間および料金を示している。

　乗車料金と移動時間の学習は、図５に示した実車データをそのまま用いる場合には、出発地点と到着地点の両方が同じデータが必要となるため、学習が難しい。そこで、制御部１２１は、車両動態ログデータから、分割単位ごとの移動に要する時間および料金を学習する。そして、制御部１２１は、出発地点から到着地点までに含まれる各分割単位の時間および料金の総和を求めることにより、目的地までの移動に要する時間および料金を算出する。分割単位は、例えば、所定の距離、所定の時間、または、道路の区画（ブロック）などで区切られた単位、信号や交差点で区切られた単位、などの少なくとも１つまたは複数を用いて分割した単位とすることができる。

　分割単位ごとの移動時間および料金、並びに、目的地までの移動時間および料金は、例えば、「５分－１０分」、「３００円－５００円」のように所定の幅を持たせた表示としてもよい。

　図１３ないし図２０を参照して説明した各種の表示により、タクシー１１のドライバは、より効率的な営業を行うことができる。すなわち、需要予測アプリは、乗車率の向上に貢献する予測結果を提示することができる。

　図１３ないし図２０を参照して説明した各種の表示は、ドライバが、需要予測アプリの設定ボタン６４を操作してディスプレイに表示させた設定画面において、表示のオンオフや、表示の順番などを適宜設定することができる。

＜１４．乗車位置の学習＞
　次に、サーバ１２が行う、乗車需要以外の学習および予測について説明する。

　図２１は、ビル（建物）に対する乗車位置の学習を説明する図である。

　例えば、タクシー１１の利用者（客）は、ビル２７１内の所定の位置から、スマートフォン等の端末で実行させた配車アプリ２７２を使ってタクシー１１を手配し、ビル２７１の車寄せなど所定の位置２７３でタクシー１１に乗車する。この場合、配車アプリ２７２は、タクシー１１を手配したタイミングにおける利用者の位置情報を、端末内のGPS受信機から取得し、配車依頼時位置情報としてサーバ１２に送信する。また、利用者がタクシー１１に乗車したタイミングにおける利用者の位置情報である乗車時位置情報が、タクシー１１の車両管理装置２２から送信される車両動態ログデータから取得できる。

　サーバ１２は、配車依頼時位置情報と乗車時位置情報との関係を学習する。これにより、利用者がビル２７１内の所定の位置からタクシー１１を手配した場合に、ドライバがタクシー１１をビル２７１のどこに着ければよいか、ビル２７１の乗車位置を学習することができる。サーバ１２は、学習結果を乗車位置リストとして記憶部１２２に記憶する。需要予測アプリは、学習されたビル２７１の乗車位置を、地図４１上に表示することができる。また、利用者がビル２７１を目的地として指定した場合に、ドライバは、学習されたビル２７１の乗車位置を、降車位置とすることができる。

　また、サーバ１２は、タクシー１１の手配が実際に行われたビル２７１以外のビルについても、学習された配車依頼時位置情報と乗車時位置情報との関係から、ビルの乗車位置を類推して地図４１上に表示することができる。

＜１５．降車位置の学習＞
　図２１は、ビル（建物）に対する降車位置の学習を説明する図である。

　例えば、利用者は、所定の位置２７４でタクシー１１を降車し、目的地である所定のビル２７１に移動する。利用者がタクシー１１を降車したタイミングにおける利用者の位置情報である降車時位置情報が、タクシー１１の車両管理装置２２から送信される車両動態ログデータから取得できる。また、配車アプリ２７２は、利用者がタクシー１１を降車後に移動したビル２７１の位置情報を、端末内のGPS受信機から取得し、移動後位置情報としてサーバ１２に送信する。

　サーバ１２は、降車時位置情報と移動後位置情報との関係を学習する。これにより、利用者がビル２７１を目的地として指定した場合に、ドライバは、利用者をどこで降ろせばよいか、ビル２７１の降車位置を学習することができる。サーバ１２は、学習結果を降車位置リストとして記憶部１２２に記憶する。需要予測アプリは、学習されたビル２７１の降車位置を、地図４１上に表示することができる。また、利用者がビル２７１内の所定の位置から、配車アプリ２７２を使ってタクシー１１を手配した場合に、ドライバは、学習されたビル２７１の降車位置を、乗車位置としても活用することができる。

＜１６．乗車位置の学習＞
　図２１および図２２を参照して説明した例では、学習した乗車位置を降車位置としても表示したり、学習した降車位置を乗車位置としても表示することを説明したが、一般に、ビル（建物）に対する乗車位置と降車位置は、タクシープールや車寄せ、玄関口などの場所であることが多く、一致するか、近くであることが多い。

　そこで、サーバ１２は、図２３に示されるように、乗車時位置情報と降車時位置情報を学習し、ビル２７１に最適な乗車位置を学習し、乗車位置リストとして記憶部１２２に記憶する。需要予測アプリは、学習されたビル２７１の乗車位置を、地図４１上に表示することができる。

＜１７．音による乗車需要ガイド＞
　次に、需要予測アプリが実行する、乗車需要の予測結果の音による案内について説明する。

　タクシー１１のドライバは、運転中は、安全のため、需要予測アプリによって表示される需要予測画面を見ることはできない。そこで、需要予測アプリは、地図上に乗車需要を予測した予測結果をディスプレイに表示する他に、音によっても乗車需要の予測結果をドライバに通知する機能を備える。

　需要予測アプリは、需要予測画面に表示されている全ての予測結果を音で通知することはできないので、タクシー１１の現在地（以下、自車位置とも称する）と、タクシー１１の進行方向に対応した予測結果を音で通知する。

　また、需要予測アプリは、需要予測を表示する地図４１の縮尺に応じて、需要予測の表示方法と、音の通知方法を切り替える。

　以下では、需要予測を表示する地図４１の縮尺が高倍率、換言すれば、広域地図表示である場合の需要予測表示および音出力と、地図４１の縮尺が低倍率、換言すれば、詳細地図表示である場合の需要予測表示および音出力とを、順に、説明する。

　なお、需要予測アプリの音による通知には、「ピ、ピ、ピ」、「ポーン」、「ピンポン」のように、言語ではない音（効果音や電子音などとも呼ばれる）による通知と、単語や文章による音声（メッセージ）による通知の両方を含むが、以下では、簡単のため、効果音を単純に音と表現し、言葉による音出力を音声と表現して説明する。

＜広域地図表示における音通知例＞
　図２４は、需要予測を表示する地図４１の縮尺が高倍率、換言すれば、広域地図表示の場合の需要予測画面の例を示している。

　図２４の需要予測画面において、地図４１に重畳表示された需要予測メッシュ６３の各エリアARのうち、エリア４１１が、乗車需要が高い場所として予測されたエリアARであるとする。図２４においては、エリア４１１以外の各エリアARの乗車需要の度合いに応じた色や濃度の表示は省略されている。

　タクシー１１は、自車位置マーク４２１の場所を走行中であり、国道１号線の進行方向に、乗車需要が高い場所と予測されたエリア４１１が存在する。

　需要予測アプリは、進行方向に乗車需要が高いエリア４１１が存在していることを検出し、進行方向に乗車需要が高いエリア４１１が存在することを音または音声でドライバに通知する。例えば、需要予測アプリは、音声で「進行方向、近くに需要の高いところがあります。」と出力し、「ピピピ」と３連続の音を出力する。

　また、タクシー１１が、国道１号線を走行し、自車位置マーク４２２の場所にいる場合、需要予測アプリは、例えば、音声で「進行方向、高需要です。」と出力し、「ピピピピ」と４連続の音を出力する。

　このように、需要予測アプリは、進行方向に乗車需要が高い場所であるエリア４１１が存在する場合、そのことを所定のタイミングで音または音声によりドライバに通知する。通知するタイミングは、例えば、需要予測メッシュ６３のエリアAR単位に行うことができる。この場合、走行中のタクシー１１が位置するエリアARが変更されるごとに、音または音声による通知が出力される。あるいは、需要予測アプリは、予め設定された時間ごと（例えば、１分間隔）や、予め設定された距離ごと（例えば、１kmごと）に通知するようにしてもよい。通知するタイミングは、設定ボタン６４を操作して表示させる設定画面で変更することができる。

　需要予測アプリは、進行方向に検出された乗車需要が高いエリアARまでの距離（近さ）に応じて、音声メッセージの内容や、出力する音の種類を変更する。

　上述した例では、需要予測アプリは、自車位置が高需要エリアから遠い自車位置マーク４２１の場所では、需要予測アプリは、「進行方向、近くに需要の高いところがあります。」の音声を出力し、「ピピピ」と３連続の音を出力している。より近い場所では、需要予測アプリは、「進行方向、高需要です。」の音声を出力し、「ピピピピ」と４連続の音を出力している。すなわち、音声出力では、メッセージが「進行方向、近くに需要の高いところがあります。」から、「進行方向、高需要です。」に変更されている。音出力では、「ピピピ」の３連続の音から、「ピピピピ」と４連続の音となり、高需要エリアに近いほど、「ピ」という音の連続出力回数が増えていくように変更されている。効果音の連続回数を増やす他、例えば、「ピ」、「ピー」、「ピーー」のように、音の長さを変更したり、ボリュームが徐々に大きくなるようにしてもよい。また、音の回数、長さ、またはボリュームの少なくとも２つの組み合わせでもよい。

　また例えば、進行方向に交差点が存在し、高需要エリアが交差点を右折する方向である場合には、需要予測アプリは、「交差点右折方向、高需要です。」のように音声出力することができる。

　需要予測アプリが音または音声で高需要エリアを通知する乗車需要の度合いも、設定ボタン６４を操作して表示させた設定画面で変更することができる。例えば、図２に示したように、需要予測メッシュ６３の各エリアARは、乗車需要の度合いに応じた色や濃度で表示されるが、図２の需要予測画面で色や濃度で区別される乗車需要の度合いがレベル１乃至レベル５の５段階である場合に、乗車需要の度合いが最も高いレベル５のエリアARが進行方向に存在する場合に通知するように設定したり、レベル４以上のエリアARが進行方向に存在する場合に通知するように設定したりすることができる。

　高需要エリアの案内を音だけで行うか、音声だけで行うか、または、音と音声の両方で行うかについても、設定画面でドライバが設定することができる。需要予測アプリは、音または音声の少なくとも一方で、乗車需要の高い場所である所定のエリアARをドライバに通知する通知機能（通知部）を有する。

　なお、図１８では、乗車距離が長距離となる乗車の割合が多いエリアARや乗車位置がある場合に、乗車距離が長距離となる乗車の割合（比率）をロング度として表示するロング表示２４１について説明した。

　需要予測アプリは、広域地図表示の需要予測画面をディスプレイに表示している場合、ロング度が高いエリアARや乗車位置を音または音声でドライバに通知することもできる。

　例えば、需要予測アプリは、ロング度が所定の値以上であるエリアARが進行方向に存在する場合、音声で「近くにロングエリアがあります。」と出力するとともに、「ポーン」という、高需要エリアの通知とは異なる種類の音で出力する。

＜詳細地図表示における音通知例＞
　図２５は、需要予測を表示する地図４１の縮尺が低倍率、換言すれば、詳細地図表示の場合の需要予測画面の例を示している。

　図２５の詳細地図表示において、タクシー１１は、自車位置マーク４４１の場所を走行している。

　詳細地図表示では、実車シーケンスデータを用いた学習の結果、ディスプレイに表示されている表示領域内で、乗車需要が所定レベルを超えた乗車位置が、それぞれ、円状の需要点４５１として表示される。なお、図が煩雑になるのを防止するため、図２５では、需要点４５１の一部の符号は省略されている。

　例えば、ディスプレイに表示されている表示領域内で学習された乗車位置のうち、乗車需要が高い上位３０個の場所が、需要点４５１として表示される。ただし、所定の乗車位置が上位３０個に含まれる場合であっても、乗車位置の総数が少ないために選択されたものは除外される。したがって、需要点４５１として表示される乗車位置は、予測される乗車需要が少なくとも所定の第１レベルThA以上であり、かつ、上位３０個に含まれる乗車位置となる。

　図２５の例では、需要点４５１として、濃度の濃い円で表示された需要点４５１Aと、濃度の薄い円で表示された需要点４５１Bと、需要点４５１Aおよび４５１Ｂと異なる模様で表示された需要点４５１Cとがある。

　需要点４５１Aと需要点４５１Bの濃度の違いは、予測される乗車需要の度合いを表す。すなわち、予測される乗車需要が、高い乗車需要を示す第２レベルThB以上である場合には、濃い濃度の需要点４５１Aで表示され、第１レベルThA以上、第２レベルThB未満である場合には、薄い濃度の需要点４５１Bで表示される。このように、乗車需要の大きさに応じて、需要点４５１の濃度を変えることで、例えば、需要点４５１が、他の需要点４５１と重ならずに単独で表示されている場合には、濃度の違いによって、ドライバは乗車需要の違いを認識することができる。また、需要点４５１が、他の需要点４５１と重なって表示されている場合には、需要点４５１の濃度が濃く見えるので、乗車需要が集積した場所も、ドライバに乗車需要の高い場所として認識させることができる。なお、需要点４５１Aと需要点４５１Bの２種類の濃度で区別するのではなく、乗車需要の度合いに応じて無段階に濃度を変更してもよい。

　異なる模様で表示された需要点４５１Cは、乗車需要が高い上位３０個に選択された需要点４５１のうち、ロング度が所定の値以上の需要点４５１を表す。これにより、ドライバが、詳細地図表示において、ロング度が高い需要点４５１を認識することができる。

　図２５では、図面の制約上、ロング度が高い需要点４５１Cと、それ以外の需要点４５１Aおよび４５１Bとを、模様の違いで表示するようにしたが、カラー表示が可能なディスプレイでは、需要点４５１Cと、需要点４５１Aおよび４５１Bとで、色を変えることで識別できるようにすることができる。

　上述した例では、詳細地図表示の表示領域内で上位３０個までの乗車位置の場所を、需要点４５１として表示するようにしたが、需要点４５１を表示する個数は設定画面で変更することができる。例えば、設定画面で、上位３０個、上位２０個、上位１０個のなかから、選択可能とされる。

　また、上述した例では、詳細地図表示の表示領域内で上位３０個までの乗車位置を選択して表示したが、需要予測メッシュ６３のエリアAR単位で上位３０個を選択して表示してもよい。すなわち、需要点４５１を抽出する抽出単位は適宜設定することができる。

　次に、図２５のような詳細地図表示における音と音声による案内について説明する。

　タクシー１１は、自車位置マーク４４１の場所から、所定の方向（例えば、品川駅方向）に向かって走行している。需要予測アプリは、進行方向の所定の距離以内に、需要点４５１が存在する場合に、音声で「進行方向、高需要です。」と出力する。また、需要予測アプリは、タクシー１１が需要点４５１を通過するごとに、「ピ」と音を出力する。１個の需要点４５１に対して１回の音を出力する。

　詳細地図表示では、需要点４５１の通過に対して音が出力されるので、需要点４５１が多く表示されている道路では、「ピ」の音が連続的に発生する。これにより、ドライバは、現在通行している道路が、乗車需要が高い道路であることを認識することができ、乗車需要の多いエリアARや道路の認識向上に寄与し、ひいては、乗車率の向上に貢献する。各需要点４５１の乗車需要の度合いに応じて、「ピ」の音のボリュームの大きさを変更して出力するようにしてもよい。

　図２５の例とは異なるが、タクシー１１の進行方向に対して、需要点４５１が存在せず、進行方向と反対方向に需要点４５１が多く存在する場合には、需要予測アプリは、例えば、「反対方向に高需要ポイントがあります。」のような音声を出力する。また、進行方向に交差点が存在し、需要点４５１が多く存在する道路が交差点を右折する方向である場合には、需要予測アプリは、需要予測アプリは、「交差点右折方向、高需要です。」のように音声出力する。

　図２６は、詳細地図表示のその他の表示例を示している。

　図２６の詳細地図表示では、図２５の詳細地図表示に表示されていた需要点４５１の一部が、需要点４５１D乃至４５１Fに置き換えられている。

　車両動態ログデータには、図４に示したように、タクシー１１の進行方向も記録されているので、需要点４５１で乗車したタクシー１１の進行方向も学習されている。需要点４５１におけるタクシー１１の進行方向は、例えば、図１４の矢印２１２－１乃至２１２－８と同様に、８方向で学習されている。需要予測アプリは、各需要点４５１で乗車したタクシー１１の８方向の進行方向のうち、５０％以上の比率を占める進行方向が存在する場合に、その方向（以下、ドミナント方向と称する。）を表示することができる。

　需要点４５１Dは、ドミナント方向を示した需要点４５１を表す。需要点４５１Eは、同一のドミナント方向を有する需要点４５１Dが所定の範囲内に所定数以上存在する場合に表示される。すなわち、需要点４５１Eは、所定数以上の需要点４５１Dの集合を表す。

　需要点４５１Dは、例えば、図２６に示されるように、山型（V字型）の記号で表示され、角の指す方向がドミナント方向を表す。需要点４５１Eは、需要点４５１Dの記号をさらに拡大した記号で表される。なお、需要点４５１Dおよび需要点４５１Eは、例えば、矢印記号など、方向を示すことができるその他の記号で表示しもよい。

　需要点４５１Fは、ドミナント方向を有し、かつ、ロング度が高い需要点４５１を表す。換言すれば、ドミナント方向を有する需要点４５１Dが、図２５の需要点４５１Cのように、ロング度が高い需要点４５１である場合には、需要点４５１Fのように、模様または色を変えて表示することで、ロング度が高い需要点４５１であることも同時に表現されている。需要点４５１Eについてもロング度が高い場合には、同様に、模様または色を変えて表示される。

　詳細地図表示の各需要点４５１においてドミナント方向が存在する場合、そのドミナント方向を表示することで、ドライバが、例えば、いわゆる「流し」を行う際の走行方向の決定を手助けすることができ、乗車率の向上に貢献することができる。また、様々な方向があり得る交差点においても、交差点周辺のドミナント方向を参考にすることで、乗車需要の高い走行方向をドライバが決定することができる。

　図２６の詳細地図表示における音および音声による通知方法は、図２５と同様であるので、説明は省略する。

　詳細地図表示においても、需要点４５１の案内を音だけで行うか、音声だけで行うか、または、音と音声の両方で行うかは、設定画面の設定値に応じて変更される。需要予測アプリは、音または音声の少なくとも一方で、乗車需要の高い場所である所定の需要点４５１をドライバに通知する通知機能（通知部）を有する。

　以上のように、需要予測アプリは、タクシー１１の進行方向に対して、乗車需要の予測結果を、音や音声でドライバに通知することで、乗車率の向上に貢献することができる。

　需要予測画面が広域地図表示である場合（図２４）と、詳細地図表示である場合（図２５、図２６）とでは、乗車需要の表示方法も異なり、それに応じて、音および音声の通知方法も異なる。

　広域地図表示と詳細地図表示の切替えは、例えば、ドライバが、拡大縮小ボタン６２の操作で行ったり、設定画面の設定を変更して行うことができる。あるいはまた、タッチパネル操作の代わりに、需要予測アプリが、ドライバが発する「広域表示」や「詳細表示」の音声指示を認識（音声認識）して、切替えてもよい。さらには、需要予測アプリが自動で切替えてもよい。例えば、需要予測アプリは、タクシー１１の自車位置が、広域地図表示で案内した高需要エリアに進入したと判断された場合に詳細地図表示に変更し、高需要エリアから出たと判断された場合に広域地図表示に変更することができる。

＜音声案内制御処理＞
　上述した音および音声による乗車需要の予測の案内は、タクシー１１が乗客を乗せていない空車時に必要となり、乗客を乗せている乗車時には必要がない。また、音および音声による通知は、乗客にとってはノイズとなる。そこで、需要予測アプリは、料金メータ２１で検出される「実車」または「空車」のステータスを取得して、音および音声による案内のオンオフを、ステータスに連動して制御することができる。

　図２７は、音声案内を制御する音声案内制御処理のフローチャートである。

　初めに、ステップＳ５１において、需要予測アプリは、タクシー１１（車両）のステータスが「実車」に変更されたかを判定する。

　ステップＳ５１で、タクシー１１のステータスが「実車」に変更されたと判定された場合、処理はステップＳ５２に進み、需要予測アプリは、音声案内をオフに制御する。ステップＳ５２の後、処理はステップＳ５１に戻される。

　一方、ステップＳ５１で、タクシー１１のステータスが「実車」に変更されていないと判定された場合、処理はステップＳ５３に進み、需要予測アプリは、タクシー１１のステータスが「空車」に変更されたかを判定する。

　ステップＳ５３で、タクシー１１のステータスが「空車」に変更されたと判定された場合、処理はステップＳ５４に進み、需要予測アプリは、音声案内をオンに制御する。ステップＳ５４の後、処理はステップＳ５１に戻される。

　一方、ステップＳ５３で、タクシー１１のステータスが「空車」に変更されていないと判定された場合も、処理はステップＳ５１に戻される。

　図２７の音声案内制御処理は、需要予測アプリが起動されたときや、設定画面において音声案内がオンに設定されたときに開始され、需要予測アプリが終了されるまで繰り返される。

　以上のように、需要予測アプリは、料金メータ２１で検出される「実車」または「空車」のステータスに連動して、音声案内のオンオフを制御することができる。「実車」または「空車」のステータスに連動した制御により、ドライバが必要なときにのみ、自動で（ドライバの操作なしで）音声案内を実行することができる。

　なお、図２７の音声案内制御処理は、進行方向の乗車需要を音声メッセージで出力する音声案内の通知制御処理の例であるが、音による通知、および、音と音声の両方による通知も同様に制御される。「実車」または「空車」のステータスは、需要予測アプリが料金メータ２１から直接取得してもよいし、車両管理装置２２を介して間接的に取得してもよい。

＜その他の音声出力＞
　需要予測アプリは、上述した乗車需要を音および音声で通知する他、次のような情報も音声でドライバに通知することができる。

　例えば、需要予測アプリは、電車の運行停止情報や運行再開情報を、リアルタイムにサーバ１２から取得して、音声（メッセージ）として出力することができる。これにより、ドライバは、電車の運行情報に応じて乗車需要が高まるエリアに迅速に移動することができる。

　需要予測アプリは、例えば、タクシー１１の営業地域で開催されているイベントの終了タイミングや開始タイミングを、リアルタイムにサーバ１２から取得して、音声（メッセージ）として出力することができる。これにより、ドライバは、イベントの終了や開始に応じて乗車需要が高まるエリアに迅速に移動することができる。

　需要予測アプリは、例えば、タクシー１１の営業地域の天気情報、特に、突然の天気変化に関する情報を、リアルタイムにサーバ１２から取得して、音声（メッセージ）として出力することができる。これにより、ドライバは、天気変化に応じて乗車需要が高まるエリアに迅速に移動することができる。

　サーバ１２は、電車の運行情報や、イベント情報、天気情報などを、提携している情報提供会社のサーバから取得し、各端末装置２３の需要予測アプリに送信する。

＜１８．おすすめルート提示処理＞
　上述した実施の形態では、需要予測アプリが端末装置２３のディスプレイに表示した乗車需要予測の表示や音声出力に基づいて、ドライバ自身がタクシー１１の移動方向を決定し、タクシー１１を運転する例について説明した。

　以下では、需要予測アプリが、サーバ１２から送信されてきた乗車需要予測データに基づいて、乗車需要が高い経路を探索し、おすすめルートを提示するおすすめルート提示機能について説明する。

　需要予測アプリは、自車位置に基づいて、任意の方法で設定された目的地までの経路を探索するナビゲーション機能（ナビゲーション処理部）を有する。また、需要予測アプリは、車に搭載される一般的なナビゲーションシステム（以下、カーナビゲーションシステムと称する。）の機能に加え、乗車需要が高い場所として予測された場所を考慮して、目的地までの経路を探索する機能を有する。なお、目的地は、所定のピンポイントの場所であってもよいし、需要予測メッシュ６３で分割された１つ以上のエリアARのような目的エリアであってもよい。以下では、乗車需要が高い場所として予測された場所を、乗車点と称して説明する。乗車点は、上述した説明では乗車位置や需要点などと称した場所と同一である。

　需要予測アプリのおすすめルート提示機能は、タクシー１１が乗客を乗せていない状態である空車時、いわゆる「流し」の際に利用される。おすすめルート提示機能を利用することにより、乗客を短時間で捕まえることができ、空車時間や空車状態の運転距離を短くすることができる。また、タクシー業務を始めてからの期間が短い新人ドライバは、得意なエリア（地域）が決まっていなく、乗車需要が高い場所の知見がないため、特に有用である。タクシー業務を始めてからの期間が長いベテランドライバや、平均以上の売上を獲得するドライバにも、得意なエリアと不得意なエリアがあるので、不得意なエリアを運転している場合には、乗客を短時間で捕まえることができ、空車時間や空車状態の運転距離を短くすることができる。ルート探索時の目的地を、得意なエリアや場所とすることで、高需要の経路（乗車点）を通って、乗客を乗せつつ、所望のエリアまたは場所に戻ることも可能となる。おすすめルート提示機能を利用して高需要の経路（乗車点）を通る回数を重ねることにより、不得意なエリアを克服し、得意エリアを広げることができる。

　得意なエリアは、設定画面等において、ドライバに予め登録（設定）させてもよいし、ドライバの車両動態ログデータや実車データを用いて需要予測アプリが決定（自動登録）してもよい。得意な場所は、例えば、ドライバの営業所や、ドライバが頻繁に利用するピンポイント乗車位置、例えば、ドライバが頻繁に利用するタクシー乗り場などの「付け待ち」が行われる場所とすることができる。

　需要予測アプリがデータを用いて得意なエリアを決定する場合、需要予測アプリは、例えば、図２８に示されるように、XY平面に分布した営業地域に対して、Z軸方向を累積時間とするヒートマップを作成し、所定の閾値、例えば、総時間の７０％に相当する時間値以上の領域を、ドライバの得意エリアとして抽出することができる。得意エリアは、閾値以上として抽出された１以上のエリア全てでもよいし、累積時間が最大の１個、または、累積時間が上位の複数個でもよい。得意エリアの表示単位は、抽出された領域そのままでもよいし、ドライバが認識し易くするため、抽出された領域のなかで面積最大の市区町村としたり、累積時間が最大の地点が存在する市区町村を表示単位としてもよい。

　Z軸方向の累積時間を計算する元のデータを、車両動態ログデータとした場合には、そのドライバが移動した時間の多いエリアを得意エリアとすることができる。また、Z軸方向の累積時間を計算する元のデータを、ステータスが「実車」である車両動態ログデータのみを用いた場合には、そのドライバが乗客を乗せた時間の多いエリアを得意エリアとすることができる。Z軸方向の累積時間を計算する元のデータを、実車データとした場合には、そのドライバが乗客を乗せた場所の多いエリアを得意エリアとすることができる。

　図２９は、需要予測アプリにおいておすすめルート提示機能が実行された状態である、おすすめルート提示画面の表示例を示している。

　図２９のおすすめルート提示画面は、例えば、ドライバが、図２等の需要予測画面の画面上に表示されたおすすめルート探索ボタン等をタップすることにより、おすすめルートが探索された後に表示される。

　図２９のおすすめルート提示画面には、需要予測メッシュ６３が重畳された地図４１が表示されている。需要予測メッシュ６３の各エリアARは、図２を参照して説明したように、乗車需要の度合いに応じて、色や濃度で分類されて表示されているが、図２９の例では、図を見やすくするため、色または濃度による表示が省略されている。乗車需要の度合いに応じた色または濃度による表示が省略されている点は、後述する図３２乃至図４４についても同様である。

　地図４１上には、おすすめルートのルート探索結果５０１が表示されている。また、地図４１上には、地図４１の縮尺を低倍率にする際に操作される詳細ボタン５１１、地図４１の縮尺を高倍率にする際に操作される広域ボタン５１２、全画面表示に切り替える際に操作される全画面表示ボタン５１３なども表示されている。

　地図４１の下方には、予測時刻表示部５０２が配置されている。予測時刻表示部５０２には、おすすめルートの探索を行った際の需要予測の予測時刻が表示されるとともに、図２の予測時刻設定領域４２と同様に、需要予測の予測時刻の変更が可能である。

　地図４１および予測時刻表示部５０２の右側には、おすすめルート情報提示部５０３が配置されている。おすすめルート情報提示部５０３には、おすすめルート提示画面であることを示す「おすすめルート」の文字が最上段に表示されている。

　おすすめルート情報提示部５０３には、「<行き先モード>」が表示されており、地図４１上に表示されたルート探索結果５０１が、複数の探索モードのうち、“行き先モード”で探索されたことを表している。需要予測アプリは、需要点を考慮したルート探索のモードとして、“行き先モード”、“すぐ乗せるモード”、および、“近くの乗車点モード”の、３つの探索モードを有している。

　“行き先モード”は、目的地を設定して、目的地までの複数のルートのなかから、需要点を通過するルートを探索するモードである。目的地は、ドライバが設定してもよいし、ドライバの得意エリアを目的地（目的エリア）としてもよい。例えば、“行き先モード”は、タクシー１１の現在地が得意エリア以外の場所であり、得意エリアに戻りながら、乗客を捕まえたいような場合に好適である。

　“すぐ乗せるモード”は、特定の目的地はなく、現在地から、需要点を通過するルートを探索するモードである。“すぐ乗せるモード”は、タクシー１１の現在地が得意エリア内にいる場合に利用することができる。

　“近くの乗車点モード”は、特定の目的地はなく、現在地の周辺で、評価値が高い需要点を通過するルートを探索するモードである。“近くの乗車点モード”は、タクシー１１の現在地が得意エリア内にいる場合、得意エリア外にいる場合のどちらにも利用することができる。

　おすすめルート情報提示部５０３の「<行き先モード>」の下方には、“行き先モード”のルート探索の目的地が世田谷区であることを表す「エリア「世田谷区」に戻ります」が表示されている。

　さらに、おすすめルート情報提示部５０３には、「おすすめ度　98点」、「乗車点数108か所」、「需要予測レベル計6レベル」の情報が表示されている。「おすすめ度　98点」は、地図４１上に表示されたルート探索結果５０１のおすすめ度が98点であることを表す。おすすめ度は、100点満点とした場合の点数でもよいし、数値が大きいほどおすすめ度合いが大きいことを表す点数表示でもよい。「乗車点数108か所」は、地図４１上に表示されたルート探索結果５０１のルートが、108か所の乗車点を通過するルートであることを表す。図２の需要予測画面では、色や濃度で区別される各エリアARの乗車需要の度合いがレベル１乃至レベル５の５段階で表示される例を説明したが、「需要予測レベル計6レベル」は、地図４１上に表示されたルート探索結果５０１が通過する１以上のエリアARの乗車需要のレベルを合計すると、６レベルになることを表す。

　図３０のフローチャートを参照して、需要点を考慮したおすすめルートを探索してドライバに提示するおすすめルート提示処理を説明する。

　この処理は、例えば、図２等の需要予測画面の画面上に表示されたおすすめルート探索ボタン等をタップすることにより、開始される。なお、おすすめルート提示処理に用いられる乗車需要予測データは、サーバ１２から定期的に送信されてくるデータを用いることができる他、必要に応じてサーバ１２に要求することで取得することができる。

　初めに、ステップＳ７１において、需要予測アプリは、探索モードが指定されたかを判定する。探索モードは、例えば、ルート探索ボタン押下後に表示されるモード選択画面において、“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれかの探索モードボタンを選択することで、指定することができる。あるいはまた、自車位置が得意エリア以外にある場合には、“行き先モード”が選択され、自車位置が得意エリア内にある場合には、“すぐ乗せるモード”または“近くの乗車点モード”が選択されるように予め設定してもよい。

　探索モードが指定されたと判定されるまでステップＳ７１の処理が繰り返され、探索モードが指定されたと判定された場合、処理がステップＳ７２に進められる。

　そして、ステップＳ７２において、需要予測アプリは、指定された探索モードが“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれであるかを判定する。

　ステップＳ７２で、指定された探索モードが“行き先モード”であると判定された場合、処理はステップＳ７３に進み、ステップＳ７３乃至Ｓ７５の処理が実行される。指定された探索モードが“すぐ乗せるモード”であると判定された場合、処理はステップＳ７６に進み、ステップＳ７６およびＳ７７の処理が実行される。指定された探索モードが“近くの乗車点モード”であると判定された場合、処理はステップＳ７８に進み、ステップＳ７８乃至Ｓ８０の処理が実行される。

　指定された探索モードが“行き先モード”であると判定された場合のステップＳ７３では、需要予測アプリは、行き先（目的地）を得意エリアに設定する。行き先は、デフォルトで、予め登録されている得意エリアに設定されるが、ドライバの操作によって変更することも可能である。

　ステップＳ７４において、需要予測アプリは、ダイクストラ法やＡ＊アルゴリズム等の探索経路アルゴリズムを用いて、自車位置と行き先とに基づいて、複数（所定数）のルートを検索する。この処理は、一般的なカーナビの機能と同様の処理である。

　ステップＳ７５において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。

　ルートの合計スコアSUMscoreは、例えば、スコアSc＝エリアARの乗車需要レベル[1-5]×乗車点[0,1]×方向一致度[cosθ]を、探索されたルートが通過するエリアAR毎に算出し、自車位置から行き先までの各エリアARのスコアScを合計することで算出することができる。エリアARの乗車需要レベル[1-5]は、そのエリアARの乗車需要の度合いを表し、レベル１乃至５のいずれかの値となる。乗車点[0,1]は、そのエリアARに乗車点が存在する場合には、“１”、存在しない場合には“０”となる。方向一致度[cosθ]は、自車位置から行き先までの方向に対する自車位置からエリアARの方向の角度（cosθ）であり、方向が一致するほど、１に近い値となる。上述したスコアScの計算式に用いる需要予測については、自車位置からの距離、例えば、エリアARの通過数などに応じて、エリアARの予測時刻が順次更新される。例えば、１つのエリアARを５００ｍ×５００ｍとし、３０km/hで１０分運行すると仮定すると、１０分で５km進むので、１０エリアの移動ごとにエリアARの予測時刻を１０分進め、ルートの需要予測が更新される。なお、上述したスコアScの計算式の乗車点[0,1]を、そのエリアARに存在する乗車点の個数などとしてもよい。

　ルートの合計スコアSUMscoreは、上述したエリアAR単位ではなく、ルート上に存在する乗車点ごとにスコアScを算出してもよい。また、探索されたルートの一部の経路において、方向が行き先に対して逆方向となるような場合には、スコアScの加算を行わないようにしたり、スコアScの減算を行うようにしてもよい。

　ルートの合計スコアSUMscoreは、上述した例に限らず、需要予測のレベルが高く、乗車点が多いルートの合計スコアSUMscoreが大きくなるような任意の計算方法を採用することができる。

　また、ルートの合計スコアSUMscoreには、その他の観点を付加してスコアScまたは合計スコアSUMscoreを計算してもよい。例えば、乗車点のロング度に応じた係数またはスコアScを付加して、ロング度が高いほど、合計スコアSUMscoreまたはスコアScが大きくなるようにしてもよい。あるいはまた、探索されたルートにおいて通過する経路が大通りであるか、または、狭い道路であるかなどに応じて、係数またはスコアScを付加してもよい。過去の乗車履歴（実車データ）の出発地点と到着地点から、各乗車点で乗車されたときの乗客の移動方向を識別することができる。ドライバの行き先と乗車点の移動方向とが近いほど、合計スコアSUMscoreまたはスコアScが大きくなるようにしてもよい。

　ステップＳ７５の各ルートの合計スコアSUMscoreの計算後、処理は、後述するステップＳ８１に進む。

　一方、指定された探索モードが“すぐ乗せるモード”であると判定された場合のステップＳ７６では、需要予測アプリは、所定のルート探索領域に対して、グラフ理論である深さ制限探索により複数のルートを決定する。より具体的には、グラフ理論におけるノードを交差点、エッジを交差点間の道路（経路）として、ルート探索領域内で、深さ制限探索により、複数のルートが決定される。ルート探索領域は、自車位置が得意エリア内にいる場合には、得意エリアとしてもよいし、自車位置から半径何km以内としてもよいし、自車位置を中心に、所定数のエリアARとしてもよい。

　ステップＳ７７において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。需要予測アプリは、例えば、検索されたルート上に存在する乗車点ごとのスコアScを、例えば、スコアSc＝乗車点を含むエリアARの乗車需要レベル[1-5]として算出して合算することで、合計スコアSUMscoreを計算する。

　ルートの合計スコアSUMscoreは、上述した例に限らず、需要予測のレベルが高く、乗車点が多いルートの合計スコアSUMscoreが大きくなるような任意の計算方法を採用することができる。逆方向のスコアScの加算または減算や、需要予測の予測時刻の更新などは、“行き先モード”時の計算と同様に行うことができる。

　ステップＳ７７の各ルートの合計スコアSUMscoreの計算後、処理は、後述するステップＳ８１に進む。

　一方、指定された探索モードが“近くの乗車点モード”であると判定された場合のステップＳ７８では、需要予測アプリは、自車位置からの距離が一定値以内に存在する乗車点を抽出し、抽出された各乗車点にスコアScを付与する。

　“近くの乗車点モード”における各乗車点のスコアScは、例えば、以下のように付与することができる。

　例えば、需要予測アプリは、各乗車点において、乗車があった日時が現在の日時に近いほど、大きなスコアScを付与する。需要予測アプリは、各乗車点において、乗車があった回数（乗車数）が多いほど、大きなスコアScを付与する。需要予測アプリは、各乗車点において、総乗車時間（各乗車回の乗車時間の合計）や、平均乗車時間が大きいほど、大きなスコアScを付与する。

　需要予測アプリは、各乗車点において、自車位置から、直進または左折で到達できる場所を高く、右折で到達できる場所は低くなるスコアScを付与する。

　例えば、図３１に示されるように、タクシー１１が、自車位置マーク５０５の場所を走行中であり、乗車点として、直進で到達できる乗車点HS1と、左折で到達できる乗車点HS2と、右折で到達できる乗車点HS3があるとする。左側通行の日本では、直進の乗車点HS1と左折の乗車点HS2は、比較的移動しやすいが、対向車線を横断する必要がある右折の乗車点HS3は、信号機のタイミングや、対向車線を走行する車両のタイミングに依存する部分が多く、到達するまでに時間がかかることが多い。そのため、需要予測アプリは、乗車点HS1と乗車点HS2のスコアScを、乗車点HS3のスコアScよりも高く付与することができる。

　なお、右側通行が採用されている外国の道路においては、直進または右折で到達できる場所を高く、左折で到達できる場所は低くなるように、スコアScが付与される。すなわち、直進と、対向車線を横断する必要が無い方向に曲がる乗車点は高く、対向車線を横断する必要がある方向に曲がる乗車点は低く、スコアScが付与される。

　需要予測アプリは、各乗車点において、自車位置から近い場所であるほど高くなるスコアScを付与する。

　需要予測アプリは、各乗車点において、その乗車点が存在するエリアAR内で、乗車点が占める割合（例えば、その乗車点の乗車回数／エリアAR内全ての乗車回数）が大きいほど高くなるスコアScを付与する。

　需要予測アプリは、行き先が設定されている場合には、各乗車点において、行き先の方向との一致度が大きいほど高くなるスコアScを付与する。

　以上のようにして各乗車点に付与されたスコアScの合計が、最終的な各乗車点のスコアScとなる。なお、以上は、各乗車点に付与するスコアScの付与例の一例であり、その他の付与基準で、スコアScを付与してもよい。

　ステップＳ７９において、需要予測アプリは、各乗車点に付与されたスコアScを参照し、スコアScの高い所定数の乗車点を経由点として、複数のルートを検索する。より具体的には、最初に、各乗車点に付与されたスコアScを参照し、スコアScの高い所定数の乗車点が抽出される。そして、抽出された乗車点を経由するように、複数（所定数）のルートが探索経路アルゴリズムを用いて探索される。

　ステップＳ８０において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。需要予測アプリは、例えば、検索されたルート上に存在する各乗車点のスコアScを合算することで、合計スコアSUMscoreを計算する。あるいはまた、ルート上に存在する乗車点の数を、合計スコアSUMscoreとしてもよい。

　ステップＳ８０の各ルートの合計スコアSUMscoreの計算後、処理は、ステップＳ８１に進む。

　ステップＳ８１において、“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれかの探索モードで計算された複数のルートのうち、合計スコアSUMscoreが最も高いルートを、おすすめルートとしてディスプレイに表示する。図２９に示したおすすめルート提示画面は、探索モードが“行き先モード”で表示された例である。

　図３０のおすすめルート提示処理は、以上のように実行される。おすすめルートが提示された後、一般的なカーナビゲーションシステムと同様に、ルートの案内が開始される。すなわち、ディスプレイによるルート表示の他、「次の交差点を右です」のように音声ガイドによりルートがドライバに指示される。ディスプレイによるルート表示では、図２６に示した需要点４５１のように、ルート上に表示される乗車点の記号や色、模様などを、乗車点のスコアScの値（大きさ）に応じて変えて表示してもよい。

　ドライバがおすすめルートの案内を停止する操作をタッチパネル操作等により行った場合、おすすめルートの案内が終了される。なお、端末装置２３の需要予測アプリが、「実車」、「空車」、または「迎車」のステータスを、料金メータ２１または車両管理装置２２から取得して、「空車」以外のステータス、即ち、「実車」または「迎車」のステータスとなった場合に、ドライバの操作なしで終了（自動終了）するようにしてもよい。

＜１９．乗車禁止地区案内表示＞
　タクシー１１のドライバは、タクシー乗り場以外の場所でお客を乗せることが禁止されている乗車禁止地区に注意する必要がある。仮に、新人ドライバなど、乗車禁止地区に慣熟していないドライバが注乗車禁止地区でお客を乗せてしまった場合には、厳しい罰則がある。例えば、関東地方では、銀座や新橋に乗車禁止地区が設定されている。関西地方では、北新地や南地に乗車禁止地区が設定されている。

　需要予測アプリは、需要予測画面において、乗車禁止地区を表示することができる。

　図３２は、乗車禁止地区を表示した需要予測画面の例を示している。

　図３２において、図２９等と対応する部分については同一の符号を付してあり、その部分の説明は適宜省略する。

　図３２の需要予測画面には、需要予測メッシュ６３が重畳された地図４１上に、詳細ボタン５１１、広域ボタン５１２、および、全画面表示ボタン５１３が表示されている。また、地図４１上には、地図４１の表示を、自車位置を基準にした表示に切り替える現在地ボタン５１４も表示されている。

　さらに、地図４１の乗車禁止地区に該当する領域には、乗車禁止地区表示５２１が表示されている。また、乗車禁止地区表示５２１の近傍に、乗車禁止地区に関する詳細情報を表示する詳細表示５２２も表示されている。詳細表示５２２には、乗車禁止地区が適用される時間を示す「乗車禁止地区　22時から1時まで」の文字と、乗車禁止地区表示５２１を消去するための[OFF]ボタンが含まれる。乗車禁止地区表示５２１は、地図４１上に重畳されるため、需要予測の乗車点を示す表示が見えにくい場合や、乗車禁止地区の表示が不要なドライバは、[OFF]ボタンを操作することにより、乗車禁止地区表示５２１を消すことができる。需要予測アプリは、乗車禁止地区が適用される時間外となると、乗車禁止地区表示５２１と詳細表示５２２を消去する。

　また、図３２の需要予測画面には、地図４１の表示領域とは異なる領域に、予測時刻表示部５０２と、付加情報表示部５３１が設けられている。付加情報表示部５３１には、例えば、電車の運行情報や、イベント情報、天気情報などが表示される。

　乗車禁止地区に関する情報は、需要予測アプリ（端末装置２３）内に予め記憶されてもよいし、サーバ１２や、その他の情報提供会社のサーバ等から取得してもよい。

＜２０．付け場所表示＞
　図１７に示した付け待ち時間予測の表示では、「付け待ち」と呼ばれる、タクシー乗り場でタクシー１１の列に並び、タクシー１１を待機させた状態で乗客を獲得する方法があることについて説明した。「付け待ち」が行われる場所（以下、付け場所と称する。）は、駅前やホテル前のタクシー乗り場や、所定のオフィスビルの玄関前などである。このような付け場所には、付け場所を使用できるタクシー会社が限定された場所がある。所定のタクシー会社に限定された付け場所を、他のタクシー会社のタクシー１１は使うことはできない。需要予測アプリは、所定のタクシー会社専用の付け場所であることを表示する機能を有する。

　図３３は、タクシー会社ごとの付け場所を表示した需要予測画面の例を示している。

　図３３の需要予測画面には、需要予測メッシュ６３が重畳された地図４１上に、詳細ボタン５１１、広域ボタン５１２、全画面表示ボタン５１３、および、現在地ボタン５１４が表示されている。

　また、地図４１上の所定の乗車点５４１Aおよび５４１Bのそれぞれに、それらの乗車点が付け場所であることを示す付け場所表示５５１Aおよび５５１Bが表示されている。付け場所表示５５１Aは実線の円状図形で表され、付け場所表示５５１Bは破線の円状図形で表されており、付け場所表示５５１Aと付け場所表示５５１Bとで表示方法が異なっている。この表示方法の違いは、付け場所を使用可能なタクシー会社が異なることを表す。付け場所表示５５１Aと付け場所表示５５１Bとを特に区別しない場合には、単に付け場所表示５５１と称する。

　ドライバは、所定の付け場所表示５５１を選択（タップ）することにより、その付け場所の詳細情報５５３を表示することができる。図３３の例では、乗車点５４１Aの付け場所表示５５１Aに関する詳細情報５５３が表示されている。

　詳細情報５５３には、乗り場名称、そのタクシー１１が付け場所を使用可能か否か、お客を乗せることが可能な時間帯、付け場所を使用可能なタクシー会社の名前、需要予測画面の地図４１上に表示された他の使用可能な付け場所、などの情報が表示される。

　図３３の付け場所表示５５１Aの詳細情報５５３には、乗り場名称として「ホテル品川」が、タクシー１１が使用可能か否かについて、使用できない付け場所であることを表す「×（使用不可）」、お客を乗せることが可能な時間帯として「終日」が、付け場所を使用可能なタクシー会社の名前として「Kmタクシー専用」が、需要予測画面の地図４１上に表示された他の使用可能な付け場所、すなわち付け場所表示５５１Bの乗車点５４１Bの乗り場名称として「大崎Thinkビル」が表示されている。

　ドライバのタクシー会社については、需要予測アプリを起動時のログイン画面や、設定画面において、会社を識別する会社IDや、タクシー１１に乗務しているドライバを識別する乗務員IDなどを登録（入力）することで、需要予測アプリが識別することができる。

　図３３の画面例では、付け場所表示５５１Aおよび５５１Bが、乗車点を囲む円状図形で表されているが、付け場所を示す表示方法は、これに限られない。付け場所表示５５１は、そのタクシー１１が使用可能か否かで表示（色や記号）を変えてもよいし、そのタクシー１１が使用可能な付け場所に限定して、付け場所表示５５１を表示するようにしてもよい。

　付け場所についての情報は、需要予測アプリ内に予め記憶されてもよいし、サーバ１２や、その他の情報提供会社のサーバ等から取得してもよい。車両動態ログデータには、タクシー１１が所属する会社を識別する会社IDが含まれているので、サーバ１２は、既知の付け場所情報を取得する他、車両動態ログデータの履歴から乗車点の推定とともに、その乗車点が付け場所であるか否か、付け場所である場合に、どのタクシー会社が使用可能であるかを特定することができる。乗車点が付け場所であるかの特定は、上述したようにタクシー１１の付け待ち動作を検出することができるので、その付け待ち動作後に、ステータスが「空車」から「実車」となる乗車変化点を付け場所の乗車点とすることができる。

　需要予測アプリの付け場所表示５５１により、ドライバが不要な付け場所に行くことを防止し、効率的な営業を行うことができる。

＜２１．電車時刻表示＞
　ある鉄道路線の営業時間帯において、最後に運転される電車（いわゆる、終電）が出発した駅では、その電車を逃した人によるタクシー１１の需要が増加する。また、終電が到着した駅においても、時間的に他の乗り換え線やバスも終了していることが多く、タクシー１１の需要が増加する。あるいはまた、電車の運行本数が少ない（運行間隔が長い）鉄道路線では、ある駅で電車を降りた人が、タクシー１１を利用することも多い。したがって、電車の終電時刻や到着時刻など電車時刻情報をドライバに案内できれば、ドライバは、その電車時刻情報を基に、駅前のタクシー乗り場に向かうことで、乗客を獲得することができる。

　需要予測アプリは、需要予測画面において、地図４１に表示された鉄道路線の駅の終電時刻等の所定の電車時刻を表示する機能を有する。

　図３４は、終電の電車時刻を表示した需要予測画面の例を示している。

　図３４の需要予測画面の地図４１には、京浜急行電鉄株式会社の品川駅と、東日本旅客鉄道株式会社（JR東日本）の品川駅と、都営浅草線の高輪台駅が存在しており、それぞれの終電の電車時刻が表示されている。

　具体的には、時刻表示５７１は、「品川駅　0：23　金沢文庫行」を表示し、京浜急行電鉄株式会社の品川駅の金沢文庫行きの最終電車の発車時刻が0：23であることを示している。

　時刻表示５７２は、「品川駅　0：46　大崎行」を表示し、東日本旅客鉄道株式会社（JR東日本）の品川駅の大崎行きの最終電車の発車時刻が0：46であることを示している。

　時刻表示５７３は、「高輪台駅　0：31　西馬込行」を表示し、都営浅草線の高輪台駅の西馬込行きの最終電車の発車時刻が0：31であることを示している。

　需要予測画面の地図４１の右側には、地図４１上に表示された電車時刻情報をリストで表示するリスト表示部５８１が表示されている。

　リスト表示部５８１には、時刻表示５７１乃至５７３と同じ情報が、電車時刻の早い順または遅い順、自車位置から駅までの距離が近い順または遠い順、などの所定の順番で一覧表示される。ソートボタン５８２は、電車時刻の早い順から遅い順へ、自車位置からの距離が近い順から遠い順へ、電車時刻順から自車位置からの距離順へなど、リスト表示部５８１に表示される順番を変更する際に操作される。電車時刻は、到着時刻または発車時刻のいずれでもよい。

　需要予測アプリが、終電時刻等の所定の電車時刻を表示する機能を有することにより、終電を逃した人や、終電から下りた人などを、乗客として獲得する機会が増加する。電車時刻表示機能は、設定により表示をオンオフさせることができる。需要予測画面の地図４１に表示された全ての駅の電車時刻を表示するのではなく、利用者数が多い（利用者数が一定値以上の）駅や、複数の路線が乗り入れているターミナル駅、始発や終点となる駅などに限定してもよい。地図４１に表示されている駅ではなく、自車位置から一定距離以内（例えば、半径2.5km以内）の駅を表示するようにしてもよい。あるいはまた、自車の進行方向に存在する駅のみ表示してもよい。どのような条件の駅の電車時刻を表示するかは、設定画面で設定することができるようにしてもよい。

　上述したように、電車の運行本数が少ない（運行間隔が長い）鉄道路線では、終電や始発に限らず、全ての電車時刻を表示するようにしてもよい。

　需要予測アプリは、乗車需要予測データとともに、または、乗車需要予測データの一部として、電車時刻表示のデータをサーバ１２から取得して、需要予測画面に表示させることができる。需要予測アプリは、タクシー１１の現在地と現在時刻に連動して、例えば、電車時刻の所定時間前となったら表示してもよいし、需要予測画面に電車時刻表示ボタンを設け、ドライバの操作に基づいて表示してもよい。

＜２２．逆引き乗車点表示＞
　乗客が羽田空港や成田空港を行き先としてタクシー１１を利用する場合などでは、乗車距離が長距離となることが期待できる。そのため、ドライバが、特定の行き先に向かう乗客を希望することがある。実車データには、出発地点と到着地点が記録されているので、到着地点が特定の場所である実車データを集めることにより、行き先が特定の場所である乗車点（出発地点）を解析することができる。

　そこで、需要予測アプリは、ドライバが行き先として特定の場所を指定し、過去の実車データにおいて、その指定された場所を、乗客が実際に行き先として乗車した乗車点のみを表示する逆引き乗車点表示機能を備える。逆引き乗車点とは、行き先が特定の場所に限定された乗車点を表す。行き先として指定可能な場所には、例えば、羽田空港や成田空港、東京ディスニーリゾート（登録商標）（以下、TDRと称する。）などが挙げられる。

　図３５は、逆引き乗車点表示機能が実行された需要予測画面の例を示している。

　図３５の需要予測画面は、例えば、ドライバが、需要予測画面上に表示された逆引き乗車点表示ボタン等を操作することにより表示される。

　図３５の需要予測画面では、需要予測メッシュ６３が重畳された地図４１の隣り（右側）に、逆引き乗車点表示部６０１が配置されている。地図４１の下方には、予測時刻表示部６０２が配置されている。

　逆引き乗車点表示部６０１には、需要予測を表示する乗客の行き先のリストと、需要予測表示を実行する実行ボタン６１１が表示される。図３５の例では、行き先として、羽田空港、成田空港、および、TDRの３つが表示されており、羽田空港に向かう乗客の需要予測を表示させる場合には実行ボタン６１１A、成田空港に向かう乗客の需要予測を表示させる場合には実行ボタン６１１B、TDRに向かう乗客の需要予測を表示させる場合には実行ボタン６１１Cがタッチ（選択）される。

　予測時刻表示部６０２には、需要予測の予測時刻が表示されるとともに、図２の予測時刻設定領域４２と同様に、需要予測の予測時刻の変更が可能である。

　図３６は、実行ボタン６１１Aがタッチされた場合の、羽田空港に向かう乗客の需要予測画面の例を示している。詳細ボタン５１１または広域ボタン５１２を操作することにより、需要予測画面の地図４１の倍率を変更することができる。図３６の例は、実行ボタン６１１Aにより最初に表示される需要予測の地図４１の縮尺が、高倍率（広域地図）とした例であるが、実行ボタン６１１Aにより最初に表示される需要予測の地図４１の縮尺は、実行時の図３５の需要予測画面の地図４１と同倍率の表示とすることもできる。図３６の需要予測画面では、乗車点や行き先ごとに、その行き先に行く乗客に該当する確率を表示してもよい。

　所定の場所を行き先とする乗客の需要予測は、時間帯の他、天気や曜日（平日、休前日、休日）などの条件ごとに分類し、需要予測実行時の条件に合致する逆引き乗車点を表示することができる。

　逆引き乗車点表示部６０１に表示される１以上の行き先は、図３５に示した、羽田空港、成田空港、および、TDRのように、予め設定された場所としてもよいし、タクシー１１の現在地に応じて、現在地から向かうことが多い場所としてもよい。行き先には、上述した例の他、例えば、その他のテーマパーク、コンサート会場、イベント会場、球場などを設定しておくことができる。

＜２３．配車／流し／付け待ちの需要予測分類表示＞
　利用者がタクシー１１に乗る場合、「配車（trip request）」、「流し（cruising vehicle）」、「付け待ち（customer waiting at stand）」の３通りのタクシー１１の獲得方法がある。「配車」は、タクシー会社のコールセンターやアプリ等でタクシー１１を手配し、所定の場所へタクシー１１に来てもらう方法である。「流し」は、空車で移動しているタクシー１１を捕まえる方法である。「付け待ち」は、付け場所に移動して、付け待ちをしているタクシー１１に乗る方法である。需要予測アプリが、需要予測画面において需要予測を表示する場合、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示することができる。すなわち、需要予測アプリは、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示する機能を備える。

　図３７は、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示する需要予測画面の例を示している。

　図３７の需要予測画面には、需要予測メッシュ６３が重畳された地図４１と、需要予測の予測時刻の指定が可能な予測時刻表示部５０２と、付加情報表示部５３１とが設けられている。

　需要予測画面の地図４１上には、詳細ボタン５１１、広域ボタン５１２、全画面表示ボタン５１３、および、現在地ボタン５１４に加えて、付け表示ボタン６４１、流し表示ボタン６４２、および、配車表示ボタン６４３が設けられている。また、「配車」、「流し」、および「付け待ち」の乗車方法の違いを識別可能に、色、模様、マーク形状等の表示方法を異ならせた乗車点６４５が、地図４１上に表示されている。

　付け表示ボタン６４１は、「付け待ち」の乗車方法による乗車点６４５を地図４１上に表示する場合に操作される。流し表示ボタン６４２は、「流し」の乗車方法による乗車点６４５を地図４１上に表示する場合に操作される。配車表示ボタン６４３は、「配車」の乗車方法による乗車点６４５を地図４１上に表示する場合に操作される。付け表示ボタン６４１、流し表示ボタン６４２、および、配車表示ボタン６４３は、トグルボタンとなっており、操作する度に、指定の乗車方法単位で乗車点６４５の表示をオンオフすることができる。また、「配車」、「流し」、および「付け待ち」の任意の組合せも可能であり、例えば、「配車」と「流し」の両方がオンされている場合には、地図４１上には、「配車」の乗車方法と「流し」の乗車方法の両方の乗車点６４５が表示される。

　「配車」、「流し」、または「付け待ち」の乗車方法の違いによる乗車点の需要予測は、「配車」、「流し」、または「付け待ち」の乗車方法の違いごとに乗車需要を予測することで求めることができる。「配車」による実車データは、タクシー１１のステータスが「迎車」となった直後の「実車」の実車データを集めればよい。「付け待ち」による実車データは、付け待ち動作後の「実車」の実車データを集めればよい。「流し」による実車データは、「配車」と「付け待ち」以外の実車データとすることができる。

　乗車需要（乗車点）を、「配車」、「流し」、または「付け待ち」の乗車方法の違いを区別して表示することで、ドライバの営業スタイルに合わせた乗車需要をドライバに提示することができる。

＜２４．乗車料金予測の表示＞
　図１８では、所定のエリアARが注目エリアARとして選択された場合に、注目エリアARの長距離の乗客の割合を表示するロング表示２４１を行う例について説明した。

　また、図１９では、所定のエリアARが注目エリアARとして選択された場合に、注目エリアARで乗車する乗客の平均乗車距離とその信頼区間を表示する乗車距離表示２５１を行う例について説明した。

　また、図１９の説明では、需要予測アプリが、平均乗車距離および信頼区間の代わりに、平均乗車料金（運賃）と信頼区間を示してもよいことや、時間帯や天候ごとに乗車需要を予測することができることを説明した。

　図３８は、注目エリアARで乗車する乗客の平均乗車料金（運賃）と信頼区間を表示した場合の表示例を示している。

　需要予測アプリは、図３８に示されるように、注目エリアAR全体の乗車数とは別に、注目エリアARで乗車する乗客の平均乗車料金とその信頼区間を表示する乗車料金表示７１１を行うことができる。

　乗車料金表示７１１では、注目エリアARにおける乗車の平均料金が、「2,400円」であり、例えば７０％の信頼度における平均乗車料金の信頼区間が、「1,110円から3,700円」であることが表示されている。信頼区間の信頼度は７０％に限定されず、８０％など任意に設定することができる。

　また、乗車料金表示７１１では、表示された乗車料金の予測値が、「18：00-18：30の時間帯、平日、雨、10月」に特化した実車データに基づく値であることを示している。

　このように、注目エリアARの平均乗車料金およびその信頼区間を表示することにより、ドライバが、例えば、高い乗車料金が期待できるエリアARを探したりすることができる。

　乗車料金表示７１１は、図３８に示したように、注目エリアARについて表示してもよいし、ピンポイント乗車位置マーク２２１（図１５）に付随して表示させ、ピンポイント乗車位置についての平均乗車料金および信頼区間を表示してもよい。

　また、上述した説明では、図２を参照して説明したように、需要予測メッシュ６３の各エリアARを、乗車需要の度合いに応じて、色や濃度で分けて表示するようにしたが、期待される乗車料金で、色や濃度を変えて表示してもよい。この場合、ドライバは、例えば、高い乗車料金が期待できるルートを選んで、「流し」の運転を行うことができる。

＜２５．リアルタイム空車台数の表示＞
　需要予測アプリは、所定の時刻（時間帯）における乗車需要を予測して表示するが、例えば、注目エリアARに１０台の乗車需要が予測されるが、そこに、お客を乗せたいタクシー１１が２０台存在するとしたら、１０台のタクシー１１は、乗客を獲得することができない。すなわち、乗客を獲得することができるか否かは、需要と供給の関係にも依存する。

　タクシー会社は、配車センターなどにおいて、営業中の各タクシー１１の現在地と、「実車」、「空車」または「迎車」等のステータスとをリアルタイムに管理している。リアルタイムに取得される、各タクシー１１の現在地とステータスとを含む運行データと、乗車需要予測とを組み合わせることで、ドライバは、上述した需要と供給の関係をも考慮した効率の良い営業を行うことができる。なお、リアルタイムには、営業中の各タクシー１１の現在地とステータス情報の収集、需要予測アプリへの運行データの配信等にかかる多少（例えば、数分程度）のタイムラグを含む。

　図３９は、運行データに基づいてリアルタイムの空車情報を表示する需要予測画面の例を示している。

　図３９の需要予測画面は、需要予測メッシュ６３が重畳された地図４１と、需要予測の予測時刻の指定が可能な予測時刻表示部５０２と、エリア情報表示部７４１とを備える。

　地図４１の需要予測メッシュ６３で区分された各エリアARには、そのエリアARに存在するタクシー１１の空車情報７４２がリアルタイムに表示されている。タクシー１１の空車情報７４２は、現在、そのエリアAR内を移動し、「空車」のステータスとなっているタクシー１１の台数を表す。

　需要予測メッシュ６３で区分されたエリアARのうち、ドライバにより指定された注目エリアARには、注目エリア枠２１１が表示されている。エリア情報表示部７４１には、注目エリア枠２１１の詳細情報が、エリア情報として表示されている。エリア情報表示部７４１は、例えば、そのエリアARの乗車需要の予測台数、そのエリアARの乗客のロング率などが表示されている。図３９の例では、注目エリア枠２１１が表示された注目エリアARに、乗車需要の予測台数が０台に対して、現在５台の「空車」のタクシー１１がいることを表している。

　図４０は、地図４１の縮尺が低倍率、換言すれば、詳細地図表示である場合のリアルタイムの空車情報を示した需要予測画面の表示例を示している。

　図３９は、地図４１の縮尺が高倍率、換言すれば、広域地図表示である場合のリアルタイムの空車情報を示した需要予測画面の表示例を示していた。広域地図表示の場合には、図３９に示したように、需要予測メッシュ６３のエリアAR単位で、「空車」のタクシー１１の台数が、空車情報として表示される。

　これに対して、詳細地図表示の場合には、図４０に示されるように、「空車」のタクシー１１が存在する位置に、「空車」のタクシー１１の存在を示すアイコン７５１が表示される。

　なお、付け待ち場所の乗車点などでは、その付け待ち場所の乗車点で付け待ちしている台数も表示することができる。

　需要予測アプリが、運行データに基づいてリアルタイムの空車情報を表示する機能を備えることにより、ドライバは、乗客を獲得する確率の高いエリアARを選んで運行することができ、乗客を獲得する確率を上げることができる。

　また、需要予測アプリが運行データを取得できる場合には、上述したおすすめルート提示処理において、運行データのリアルタイムの空車情報を含めて、おすすめルートを探索し、提示することができる。すなわち、おすすめルートの一部として所定の経路を選択する際、需要予測アプリが、乗車需要の予測台数が、「空車」のタクシー台数以上の経路をおすすめルートとして選択したり、大きなスコアScを付与する。また、需要予測アプリは、所定の経路で、現在から所定時間前までの一定期間、「空車」のタクシー１１が通っていない場合には、乗車需要があるかもしれないので、おすすめルートとして選択する処理を入れてもよい。

＜２６．１日の営業評価の表示＞
　需要予測アプリは、ドライバが１日の営業の終了後に、その日の営業を評価する営業評価情報を出力する機能を備えることができる。営業の評価は、優秀なドライバ、例えば、１日の売り上げ平均が高いドライバを基準に行うことができる。優秀なドライバを評価の基準ドライバとすることで、売り上げを上げるための情報をドライバに提供することができる。

　図４１は、１日の営業評価情報を出力する評価画面の例を示している。この評価画面は、例えば、需要予測アプリにおいて、１日の営業を終了する操作が行われたタイミング等で表示される。

　図４１の評価画面には、その上部に、タイトル表示８１１が表示されている。図４１の例では、「10/11　乗務スコア」と表示され、１０月１１日の営業日の評価情報であることが示されている。

　また、評価画面には、評価点数表示８１２と、レーダチャート８１３、営業収入グラフ８１４、および、ルート履歴表示ボタン８１５が設けられている。

　評価点数表示８１２は、ドライバの１日全体の総合評価を、基準ドライバを１００点とする値で示している。この総合評価値を参照することにより、ドライバが、どれくらい基準ドライバに近づいたかを確認することができる。

　レーダチャート８１３は、ドライバの１日全体の総合評価値を複数項目に分けて示した評価結果を示している。図４１の例では、営業収入、実車率、空車時間、営業回数、および、営業範囲の５項目に分類されている。営業収入は、実走行時間当たりの営業収入（売り上げ）の観点からの評価値を表す。実車率は、「実車」の走行時間／総走行時間の観点からの評価値を表す。空車時間は、「空車」の時間／総走行時間の観点からの評価値を表す。営業回数は、お客を乗せた回数の観点からの評価値を表す。営業範囲は、走行したエリアの大きさの観点からの評価値を表す。

　営業収入グラフ８１４は、１日の営業時間（営業時刻）を横軸、営業収入を縦軸として、その日１日の営業収入の推移を表示する。営業収入グラフ８１４内に表示された実線８２１は、ドライバの実際の売り上げを表す。一方、営業収入グラフ８１４内に表示された破線８２２は、ドライバの実際の運行経路と、他のタクシー１１の運行データ等を基に、理想的な仮想の売り上げを表す。例えば、ドライバの実際の運行経路と、他のタクシー１１の運行データがあれば、ある交差点で、実際にはドライバは直進したが、仮に左折していれば、乗客を獲得できたと予想される場合などを解析することができる。そのような想定を実際の運行経路について解析すると、運行経路の少しの違いで獲得できたであろう理想の営業収入を予測することができる。そのような理想の営業収入が、破線８２２として表示されている。また、破線８２２において、営業収入を上げる可能性があったポイント（場所）に対して、「東銀座７丁目を曲がっていた場合」、「新橋５丁目を曲がっていた場合」などのように、コメントが表示されている。

　ルート履歴表示ボタン８１５は、ドライバの１日の実際の運行履歴を地図上に表示する機能である。

　図４２は、ルート履歴表示ボタン８１５が操作されたときに表示される運行履歴画面の例を示している。

　運行履歴画面には、図４２に示されるように、１日の営業開始から営業終了までに、そのタクシー１１が移動した経路と、「実車」、「空車」、または「迎車」のステータス、乗客が乗った場所と降りた場所およびその時刻、などが表示される。なお、図４２の例では、地図４１が表示されていないが、実際には、地図４１上に重畳表示される。また、図４２の例では、１日の運行経路の一部のみが表示されているが、ドライバは、地図４１の表示倍率を変えることにより、１日の全部または一部の運行経路を確認することができる。

　図４２の運行履歴画面は、図４１の評価画面と合わせて、１つの画面に表示してもよい。図４２の運行履歴画面は、図４１の評価画面の営業収入グラフ８１４の営業収入を上げる可能性があったポイントと合わせて参照することで、次回の営業に参考にすることができる。

＜２７．距離および方角を考慮した付加情報の表示＞
　電車の運行情報や、イベント情報、天気情報などの付加情報を表示する場合、図３２の例で示したように、地図４１の表示領域とは異なる領域に付加情報表示部５３１を設け、表示してもよいが、距離や方角を考慮して、地図４１上に、付加情報を表示してもよい。

　図４３は、距離や方角を考慮して付加情報を表示した需要予測画面の例を示している。

　図４３の例では、付加情報８３１と、付加情報８３２が、地図４１上に表示されている。

　付加情報８３１は、山手線の田町駅で運転見合わせが発生したことを通知する情報である。付加情報８３１は、タクシー１１の現在地を示す自車位置マーク５０５を基準に、田町駅の方角に対応する位置に表示されている。図４３の例は、田町駅が、需要予測画面の地図４１の表示外の場所にあるため、田町駅の方角に対応する位置に付加情報８３１のみが表示されているが、仮に、田町駅が、需要予測画面の地図４１上にある場合には、地図４１上の田町駅の部分に、付加情報８３１とともに、運転見合わせが発生したことを示す、例えば、×、△などの記号が表示される。また、付加情報８３１として記号のみの表示し、その記号をタップ（選択）した場合に、詳細情報が表示されるようにしてもよい。

　付加情報８３２は、都営浅草線の戸越駅で電車の遅延が発生したことを通知する情報である。付加情報８３２は、タクシー１１の現在地を示す自車位置マーク５０５を基準に、戸越駅の方角に対応する位置に表示されている。

　自車位置マーク５０５を基準とする方角は、１度単位などの詳細な角度でもよいし、４方向、８方向などの所定の範囲に収束させた角度でもよい。

　また、距離についても同様に、付加情報に関する位置までの距離が現在地から遠い場合は、自車位置マーク５０５に対して遠く、近い場合は自車位置マーク５０５に対して近い位置に表示される。

　例えば、付加情報が、電車の遅延に関する情報である場合、影響があると計算された駅を、付加情報に関する位置として、自車位置マーク５０５からの方向および距離を計算することができる。

　例えば、付加情報が、イベントに関する情報である場合、イベントが開催される場所を、付加情報に関する位置として、自車位置マーク５０５からの方向および距離を計算することができる。

　例えば、付加情報が、ゲリラ豪雨などの天気に関する情報である場合、気象現象の発生場所を、付加情報に関する位置として、自車位置マーク５０５からの方向および距離を計算することができる。

　以上のように、付加情報の距離や方角に応じて、付加情報を地図４１上に表示して、ドライバに提示することにより、ドライバが付加情報を直観的に理解することができる。

　なお、図４３の需要予測画面において、地図４１上に表示される乗車点６４５（需要点４５１でも同様）の表示や、予測時刻表示部５０２の表示は省略されている。

＜２８．進行方向に応じた情報の表示＞
　需要予測の乗車点などの予測情報や、図４３等で示したイベント情報や電車遅延情報などの付加的な付加情報は、タクシー１１の進行方向にある情報は重要であるが、進行方向の逆方向にある情報は、さほど重要ではない。地図４１の経路の情報についても同様である。

　そのため、需要予測アプリは、需要予測画面の地図４１を表示する際、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように表示することができる。

　図４４のAは、タクシー１１の進行方向を画面の上方（上辺側）とするヘッドアップ（Head Up）モード時の表示例を示している。

　ヘッドアップモードでは、地図４１の全領域に対して、自車位置マーク５０５が、左右方向については、右側領域R１と左側領域L1とが同一または略同一となり、上下方向については、上側領域U1が下側領域D1よりも大きくなるように配置される。

　図４４のBは、タクシー１１の進行方向に関係なく、北の方角を画面の上方（上辺側）とするノースアップ（North Up）モード時の表示例を示している。

　ノースアップモードでは、右側領域R１と左側領域L1との配分、および、上側領域U1と下側領域D1との配分が、タクシー１１の進行方向によって異なるが、図４４のBは、タクシー１１の進行方向が、北東方向の場合の表示例を示している。この場合、左右方向については、右側領域R１が左側領域L1よりも大きくなり、上下方向については、上側領域U1が下側領域D1よりも大きくなるように配置される。

　その他の図示は省略するが、例えば、タクシー１１の進行方向が南西方向の場合には、左右方向については、左側領域L1が右側領域R１よりも大きくなり、上下方向については、下側領域D1が上側領域U1よりも大きくなるように配置される。

　以上のように、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように表示することで、ドライバにより有用な情報を表示することができる。

＜２９．コンピュータ構成例＞
　上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているマイクロコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

　図４５は、サーバ１２、車両管理装置２２、または、端末装置２３が実行する各処理をコンピュータがプログラムにより実行する場合の、コンピュータのハードウエアの構成例を示すブロック図である。

　コンピュータにおいて、CPU（Central Processing Unit）３０１，ROM（Read Only Memory）３０２，RAM（Random Access Memory）３０３は、バス３０４により相互に接続されている。

　バス３０４には、さらに、入出力インタフェース３０５が接続されている。入出力インタフェース３０５には、入力部３０６、出力部３０７、記憶部３０８、通信部３０９、及びドライブ３１０が接続されている。

　入力部３０６は、操作ボタン、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部３０７は、ディスプレイ、スピーカ、出力端子などよりなる。記憶部３０８は、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部３０９は、ネットワークインタフェースなどよりなる。ドライブ３１０は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブル記録媒体３１１を駆動する。

　以上のように構成されるコンピュータでは、CPU３０１が、例えば、記憶部３０８に記憶されているプログラムを、入出力インタフェース３０５及びバス３０４を介して、RAM３０３にロードして実行することにより、上述した一連の処理が行われる。RAM３０３にはまた、CPU３０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

　コンピュータ（CPU３０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体３１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

　コンピュータでは、プログラムは、リムーバブル記録媒体３１１をドライブ３１０に装着することにより、入出力インタフェース３０５を介して、記憶部３０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部３０９で受信し、記憶部３０８にインストールすることができる。その他、プログラムは、ROM３０２や記憶部３０８に、あらかじめインストールしておくことができる。

　本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

　また、本明細書において、フローチャートに記述されたステップは、記載された順序に沿って時系列的に行われる場合はもちろん、必ずしも時系列的に処理されなくとも、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで実行されてもよい。

　本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

　上述した実施の形態は、営業車両として、タクシーの乗車の需要を予測する予測システムの例について説明したが、客（人）を乗せるその他の営業車両、具体的には、バス、電車、飛行機、船、ヘリコプターなどや、物（荷物）を載せる営業車両、トラック、ダンプ等の需要を予測するシステムにも適用することができる。また、営業車両は、ドローン等の無人で動く輸送車両であってもよい。

　例えば、上述した実施の形態の全てまたは一部を適宜組み合わせた形態を採用することができる。

　例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、本明細書に記載されたもの以外の効果があってもよい。

　なお、本技術は以下のような構成も取ることができる。
（１）
　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる表示制御部を備える
　情報処理装置。
（２）
　前記表示制御部は、前記移動方向および前記移動距離を前記注目エリアから外側に向かう矢印で前記表示部に表示させる
　前記（１）に記載の情報処理装置。
（３）
　前記矢印の方向は前記移動方向を表し、前記矢印の長さは前記移動距離を表し、前記矢印の太さは全方向における前記移動方向の乗車の割合を表す
　前記（２）に記載の情報処理装置。
（４）
　前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数を、予測結果として前記表示部に表示させる
　前記（１）乃至（３）のいずれかに記載の情報処理装置。
（５）
　前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数と、前記注目エリアの乗車数とを、予測結果として前記表示部に表示させる
　前記（１）乃至（４）のいずれかに記載の情報処理装置。
（６）
　前記表示制御部は、前記注目エリア内の、所定の乗車位置および前記乗車位置での乗車数と、前記乗車位置で待って乗客を乗せるまでに要する時間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
　前記表示制御部は、前記注目エリアにおける乗車距離が所定の距離以上となる乗車の割合を、予測結果として前記表示部に表示させる
　前記（１）乃至（６）のいずれかに記載の情報処理装置。
（８）
　前記表示制御部は、前記注目エリアにおける乗車距離を複数の区分に分割し、分割した区分ごとの乗車の割合を、予測結果として前記表示部に表示させる
　前記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）
　前記表示制御部は、前記複数のエリア全体の前記区分ごとの乗車の割合も、予測結果として前記表示部に表示させる
　前記（８）に記載の情報処理装置。
（１０）
　前記表示制御部は、目的地までの移動に要する時間および料金と、前記目的地までの移動経路を所定の単位に分割した分割単位ごとの移動に要する時間および料金とを、予測結果として前記表示部に表示させる
　前記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）
　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車距離とその信頼区間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）
　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１３）
　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車時間とその信頼区間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１４）
　前記表示制御部は、分割した前記複数のエリアのうち、隣接する複数エリアの乗車数が所定の閾値以下となる前記複数エリアについては、１つのエリアとして結合して、前記予測結果を前記表示部に表示させる
　前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１５）
　進行方向に存在する乗車需要の高い場所を音で通知する通知部をさらに備える
　前記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）
　前記通知部は、前記エリア単位に、前記乗車需要の高い場所を通知する
　前記（１５）に記載の情報処理装置。
（１７）
　前記通知部は、前記表示部に表示される前記予測結果の縮尺に応じて音の種類を変えて、乗車需要の高い場所を通知する
　前記（１５）または（１６）に記載の情報処理装置。
（１８）
　前記通知部は、前記乗車需要の高い場所までの距離に応じて音の種類を変えて、前記乗車需要の高い場所を通知する
　前記（１５）乃至（１７）のいずれかに記載の情報処理装置。
（１９）
　前記通知部は、前記乗車需要の大きさに応じて音の種類を変えて、前記乗車需要の高い場所を通知する
　前記（１５）乃至（１８）のいずれかに記載の情報処理装置。
（２０）
　前記通知部は、前記乗車需要の高い場所を通過する毎に音で通知する
　前記（１５）乃至（１９）のいずれかに記載の情報処理装置。
（２１）
　前記通知部は、「実車」または「空車」のステータスに連動して、通知をオンオフする
　前記（１５）乃至（２０）のいずれかに記載の情報処理装置。
（２２）
　前記音は、効果音または音声メッセージである
　前記（１５）乃至（２１）のいずれかに記載の情報処理装置。
（２３）
　前記通知部は、さらに、電車の運行情報、イベント情報、天気情報の少なくとも一つを、音声メッセージで通知する
　前記（１５）乃至（２２）のいずれかに記載の情報処理装置。
（２４）
　前記表示制御部は、乗車需要を予測した予測結果に基づくおすすめのルートを、前記表示部に表示させる
　前記（１）乃至（２３）のいずれかに記載の情報処理装置。
（２５）
　前記表示制御部は、設定された目的地に向かうルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
　前記（２４）に記載の情報処理装置。
（２６）
　前記目的地は、ドライバが得意とするエリアまたは場所である
　前記（２５）に記載の情報処理装置。
（２７）
　前記ドライバが得意とするエリアは、前記ドライバが移動した時間が所定値以上のエリアである
　前記（２６）に記載の情報処理装置。
（２８）
　前記ドライバが得意とするエリアは、前記ドライバが乗客を乗せた時間が所定値以上のエリアである
　前記（２６）または（２７）に記載の情報処理装置。
（２９）
　前記ドライバが得意とするエリアの表示単位は、市区町村であり、
　前記ドライバが得意とする場所の表示単位は、乗車数が多い乗車位置である
　前記（２６）乃至（２８）のいずれかに記載の情報処理装置。
（３０）
　前記表示制御部は、現在地の周辺で、乗車需要が予測される場所を通過するルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
　前記（２４）に記載の情報処理装置。
（３１）
　前記表示制御部は、通過するルートのスコアを合計した合計スコアが高いルートを、前記おすすめのルートとして、前記表示部に表示させる
　前記（２４）乃至（３０）のいずれかに記載の情報処理装置。
（３２）
　前記合計スコアは、乗車需要のレベルに基づく前記エリア毎の前記スコアを合計して算出される
　前記（３１）に記載の情報処理装置。
（３３）
　前記合計スコアは、乗車需要が予測される場所毎の前記スコアを合計して算出される
　前記（３１）に記載の情報処理装置。
（３４）
　対向車線を横断する必要がある場所の前記スコアは、対向車線を横断する必要がない場所の前記スコアよりも低く設定される
　前記（３１）乃至（３３）のいずれかに記載の情報処理装置。
（３５）
　乗客の移動方向の予測結果と、目的地の方向とが近いほど、前記スコアが大きい
　前記（３１）乃至（３４）のいずれかに記載の情報処理装置。
（３６）
　前記おすすめのルートを探索する際の所定のエリアの前記乗車需要を予測する予測時刻が、現在地からの距離に応じて変更される
　前記（２４）乃至（３５）のいずれかに記載の情報処理装置。
（３７）
　前記乗車需要の予測台数が、空車の営業車両の台数以上のルートを、前記おすすめのルートとして表示させる
　前記（２４）乃至（３６）のいずれかに記載の情報処理装置。
（３８）
　前記表示制御部は、乗車禁止地区をさらに前記表示部に表示させる
　前記（１）乃至（３７）のいずれかに記載の情報処理装置。
（３９）
　前記表示制御部は、「付け待ち」が行われる場所をさらに前記表示部に表示させる
　前記（１）乃至（３８）のいずれかに記載の情報処理装置。
（４０）
　前記表示制御部は、前記「付け待ち」が行われる場所を使用可能な会社の名前を、さらに前記表示部に表示させる
　前記（３９）に記載の情報処理装置。
（４１）
　前記表示制御部は、前記営業車両が使用可能な他の「付け待ち」が行われる場所を、さらに前記表示部に表示させる
　前記（３９）または（４０）に記載の情報処理装置。
（４２）
　前記表示制御部は、前記表示部に表示された地図上の駅の電車時刻を、さらに表示させる
　前記（１）乃至（４１）のいずれかに記載の情報処理装置。
（４３）
　前記表示制御部は、複数の前記駅の電車時刻を、到着時刻順、または、自車位置から前記駅までの距離順でリスト表示させる
　前記（４２）に記載の情報処理装置。
（４４）
　前記表示制御部は、指定された場所を乗客の行き先として、乗車した乗車点のみを表示させる
　前記（１）乃至（４３）のいずれかに記載の情報処理装置。
（４５）
　前記表示制御部は、複数の前記行き先を表示させ、選択された前記行き先の乗車点のみを表示させる
　前記（４４）に記載の情報処理装置。
（４６）
　前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法の違いを区別して、乗車の需要予測をさらに前記表示部に表示させる
　前記（１）乃至（４５）のいずれかに記載の情報処理装置。
（４７）
　前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法単位で、前記乗車の需要予測の表示をオンオフさせる
　前記（４６）に記載の情報処理装置。
（４８）
　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（４７）のいずれかに記載の情報処理装置。
（４９）
　前記表示制御部は、所定の乗車位置における前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
　前記（１）乃至（４７）のいずれかに記載の情報処理装置。
（５０）
　前記表示制御部は、リアルタイムの空車情報をさらに前記表示部に表示させる
　前記（１）乃至（４９）のいずれかに記載の情報処理装置。
（５１）
　前記表示制御部は、前記空車情報として、前記エリア毎の空車台数を表示させる
　前記（５０）に記載の情報処理装置。
（５２）
　前記表示制御部は、前記空車情報として、空車の前記営業車両のアイコンを表示させる
　前記（５０）または（５１）のいずれかに記載の情報処理装置。
（５３）
　前記表示制御部は、１日の営業の終了後に、その日の営業を評価する営業評価情報を、さらに前記表示部に表示させる
　前記（１）乃至（５２）のいずれかに記載の情報処理装置。
（５４）
　前記表示制御部は、前記営業評価情報の一部として、実際の売り上げと、仮想の売り上げとを表示させる
　前記（５３）に記載の情報処理装置。
（５５）
　前記表示制御部は、前記営業評価情報の一部として、実車と空車のステータスを含む運行経路を表示させる
　前記（５３）または（５４）に記載の情報処理装置。
（５６）
　前記表示制御部は、付加情報の距離または方角に応じて、前記付加情報を前記表示部の地図上にさらに表示させる
　前記（１）乃至（５５）のいずれかに記載の情報処理装置。
（５７）
　前記表示制御部は、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように前記表示部に表示させる
　前記（１）乃至（５６）のいずれかに記載の情報処理装置。
（５８）
　情報処理装置が、
　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
　情報処理方法。
（５９）
　コンピュータに、
　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
　処理を実行させるためのプログラム。

　１　予測システム，　１１　タクシー，　１２　サーバ，　２２　車両管理装置，　２３　端末装置，　６３　需要予測メッシュ，　１２１　制御部，　１３１　データ生成部，　１３２　学習部，　１３３　予測部，　１４１　制御部，　１４２　操作部，　１４３　表示部，　１４５　スピーカ，　１４６　マイクロホン，　２１１　注目エリア枠，　２１２　矢印，　２２１　ピンポイント乗車位置マーク，　２２２　乗車数表示，　２２３　付け待ち開始ボタン，　２２４　付け待ち表示，　２４１　ロング表示，　２５１　乗車距離表示，　２６１　個別表示，　２６２　目的地表示，　３０１　CPU，　３０２　ROM，　３０３　RAM，　３０６　入力部，　３０７　出力部，　３０８　記憶部，　３０９　通信部，　３１０　ドライブ，　５２１　乗車禁止地区表示，　５３１　付加情報表示部，　５５１　付け場所表示，　５５３　詳細情報，　５８１　リスト表示部，　５８２　ソートボタン，　６０１　逆引き乗車点表示部，　６４１　付け表示ボタン，　６４２　流し表示ボタン，　６４３　配車表示ボタン，　７１１　乗車料金表示，　７４１　エリア情報表示部，　７４２　空車情報，　７５１　アイコン，　８１２　評価点数表示，　８１３　レーダチャート，　８１４　営業収入グラフ，　８１５　ルート履歴表示ボタン，　８２１，８２２　実線，　８３１，８３２　付加情報

Claims (59)

1. 　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる表示制御部を備える
   　情報処理装置。
2. 　前記表示制御部は、前記移動方向および前記移動距離を前記注目エリアから外側に向かう矢印で前記表示部に表示させる
   　請求項１に記載の情報処理装置。
3. 　前記矢印の方向は前記移動方向を表し、前記矢印の長さは前記移動距離を表し、前記矢印の太さは全方向における前記移動方向の乗車の割合を表す
   　請求項２に記載の情報処理装置。
4. 　前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数を、予測結果として前記表示部に表示させる
   　請求項１に記載の情報処理装置。
5. 　前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数と、前記注目エリアの乗車数とを、予測結果として前記表示部に表示させる
   　請求項１に記載の情報処理装置。
6. 　前記表示制御部は、前記注目エリア内の、所定の乗車位置および前記乗車位置での乗車数と、前記乗車位置で待って乗客を乗せるまでに要する時間とを、予測結果として前記表示部に表示させる
   　請求項１に記載の情報処理装置。
7. 　前記表示制御部は、前記注目エリアにおける乗車距離が所定の距離以上となる乗車の割合を、予測結果として前記表示部に表示させる
   　請求項１に記載の情報処理装置。
8. 　前記表示制御部は、前記注目エリアにおける乗車距離を複数の区分に分割し、分割した区分ごとの乗車の割合を、予測結果として前記表示部に表示させる
   　請求項１に記載の情報処理装置。
9. 　前記表示制御部は、前記複数のエリア全体の前記区分ごとの乗車の割合も、予測結果として前記表示部に表示させる
   　請求項８に記載の情報処理装置。
10. 　前記表示制御部は、目的地までの移動に要する時間および料金と、前記目的地までの移動経路を所定の単位に分割した分割単位ごとの移動に要する時間および料金とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
11. 　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車距離とその信頼区間とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
12. 　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
13. 　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車時間とその信頼区間とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
14. 　前記表示制御部は、分割した前記複数のエリアのうち、隣接する複数エリアの乗車数が所定の閾値以下となる前記複数エリアについては、１つのエリアとして結合して、前記予測結果を前記表示部に表示させる
    　請求項１に記載の情報処理装置。
15. 　進行方向に存在する乗車需要の高い場所を音で通知する通知部をさらに備える
    　請求項１に記載の情報処理装置。
16. 　前記通知部は、前記エリア単位に、前記乗車需要の高い場所を通知する
    　請求項１に記載の情報処理装置。
17. 　前記通知部は、前記表示部に表示される前記予測結果の縮尺に応じて音の種類を変えて、乗車需要の高い場所を通知する
    　請求項１５に記載の情報処理装置。
18. 　前記通知部は、前記乗車需要の高い場所までの距離に応じて音の種類を変えて、前記乗車需要の高い場所を通知する
    　請求項１５に記載の情報処理装置。
19. 　前記通知部は、前記乗車需要の大きさに応じて音の種類を変えて、前記乗車需要の高い場所を通知する
    　請求項１５に記載の情報処理装置。
20. 　前記通知部は、前記乗車需要の高い場所を通過する毎に音で通知する
    　請求項１５に記載の情報処理装置。
21. 　前記通知部は、「実車」または「空車」のステータスに連動して、通知をオンオフする
    　請求項１５に記載の情報処理装置。
22. 　前記音は、効果音または音声メッセージである
    　請求項１５に記載の情報処理装置。
23. 　前記通知部は、さらに、電車の運行情報、イベント情報、天気情報の少なくとも一つを、音声メッセージで通知する
    　請求項１５に記載の情報処理装置。
24. 　前記表示制御部は、乗車需要を予測した予測結果に基づくおすすめのルートを、前記表示部に表示させる
    　請求項１に記載の情報処理装置。
25. 　前記表示制御部は、設定された目的地に向かうルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
    　請求項２４に記載の情報処理装置。
26. 　前記目的地は、ドライバが得意とするエリアまたは場所である
    　請求項２５に記載の情報処理装置。
27. 　前記ドライバが得意とするエリアは、前記ドライバが移動した時間が所定値以上のエリアである
    　請求項２６に記載の情報処理装置。
28. 　前記ドライバが得意とするエリアは、前記ドライバが乗客を乗せた時間が所定値以上のエリアである
    　請求項２６に記載の情報処理装置。
29. 　前記ドライバが得意とするエリアの表示単位は、市区町村であり、
    　前記ドライバが得意とする場所の表示単位は、乗車数が多い乗車位置である
    　請求項２６に記載の情報処理装置。
30. 　前記表示制御部は、現在地の周辺で、乗車需要が予測される場所を通過するルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
    　請求項２４に記載の情報処理装置。
31. 　前記表示制御部は、通過するルートのスコアを合計した合計スコアが高いルートを、前記おすすめのルートとして、前記表示部に表示させる
    　請求項２４に記載の情報処理装置。
32. 　前記合計スコアは、乗車需要のレベルに基づく前記エリア毎の前記スコアを合計して算出される
    　請求項３１に記載の情報処理装置。
33. 　前記合計スコアは、乗車需要が予測される場所毎の前記スコアを合計して算出される
    　請求項３１に記載の情報処理装置。
34. 　対向車線を横断する必要がある場所の前記スコアは、対向車線を横断する必要がない場所の前記スコアよりも低く設定される
    　請求項３１に記載の情報処理装置。
35. 　乗客の移動方向の予測結果と、目的地の方向とが近いほど、前記スコアが大きい
    　請求項３１に記載の情報処理装置。
36. 　前記おすすめのルートを探索する際の所定のエリアの前記乗車需要を予測する予測時刻が、現在地からの距離に応じて変更される
    　請求項２４に記載の情報処理装置。
37. 　前記乗車需要の予測台数が、空車の営業車両の台数以上のルートを、前記おすすめのルートとして表示させる
    　請求項２４に記載の情報処理装置。
38. 　前記表示制御部は、乗車禁止地区をさらに前記表示部に表示させる
    　請求項１に記載の情報処理装置。
39. 　前記表示制御部は、「付け待ち」が行われる場所をさらに前記表示部に表示させる
    　請求項１に記載の情報処理装置。
40. 　前記表示制御部は、前記「付け待ち」が行われる場所を使用可能な会社の名前を、さらに前記表示部に表示させる
    　請求項３９に記載の情報処理装置。
41. 　前記表示制御部は、前記営業車両が使用可能な他の「付け待ち」が行われる場所を、さらに前記表示部に表示させる
    　請求項３９に記載の情報処理装置。
42. 　前記表示制御部は、前記表示部に表示された地図上の駅の電車時刻を、さらに表示させる
    　請求項１に記載の情報処理装置。
43. 　前記表示制御部は、複数の前記駅の電車時刻を、到着時刻順、または、自車位置から前記駅までの距離順でリスト表示させる
    　請求項４２に記載の情報処理装置。
44. 　前記表示制御部は、指定された場所を乗客の行き先として、乗車した乗車点のみを表示させる
    　請求項１に記載の情報処理装置。
45. 　前記表示制御部は、複数の前記行き先を表示させ、選択された前記行き先の乗車点のみを表示させる
    　請求項４４に記載の情報処理装置。
46. 　前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法の違いを区別して、乗車の需要予測をさらに前記表示部に表示させる
    　請求項１に記載の情報処理装置。
47. 　前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法単位で、前記乗車の需要予測の表示をオンオフさせる
    　請求項４６に記載の情報処理装置。
48. 　前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
49. 　前記表示制御部は、所定の乗車位置における前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
    　請求項１に記載の情報処理装置。
50. 　前記表示制御部は、リアルタイムの空車情報をさらに前記表示部に表示させる
    　請求項１に記載の情報処理装置。
51. 　前記表示制御部は、前記空車情報として、前記エリア毎の空車台数を表示させる
    　請求項５０に記載の情報処理装置。
52. 　前記表示制御部は、前記空車情報として、空車の前記営業車両のアイコンを表示させる
    　請求項５０に記載の情報処理装置。
53. 　前記表示制御部は、１日の営業の終了後に、その日の営業を評価する営業評価情報を、さらに前記表示部に表示させる
    　請求項１に記載の情報処理装置。
54. 　前記表示制御部は、前記営業評価情報の一部として、実際の売り上げと、仮想の売り上げとを表示させる
    　請求項５３に記載の情報処理装置。
55. 　前記表示制御部は、前記営業評価情報の一部として、実車と空車のステータスを含む運行経路を表示させる
    　請求項５３に記載の情報処理装置。
56. 　前記表示制御部は、付加情報の距離または方角に応じて、前記付加情報を前記表示部の地図上にさらに表示させる
    　請求項１に記載の情報処理装置。
57. 　前記表示制御部は、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように前記表示部に表示させる
    　請求項１に記載の情報処理装置。
58. 　情報処理装置が、
    　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
    　情報処理方法。
59. 　コンピュータに、
    　営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
    　処理を実行させるためのプログラム。

Images