JP2020004225A - 情報処理システム、情報処理プログラムおよび情報処理方法 - Google Patents

Abstract

【課題】タクシーの運行経路に関し、営業効率が高い経路を探索できる情報処理システムを提供する。【解決手段】情報処理システムは、タクシーの乗車実績情報を取得する乗車実績取得手段と、前記乗車実績情報に含まれる乗車位置の位置情報を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要情報を推定する需要情報推定手段と、前記道路毎のタクシー需要情報を探索コストに反映させ、タクシー需要が高い経路を優先的に探索する経路探索手段と、を備える。【選択図】 図１

Description

本発明は、情報処理システム、情報処理プログラムおよび情報処理方法に関する。

従来から、携帯端末の位置情報を利用してエリア毎のタクシー需要を予測する技術が知られている。特許文献１には、地図データにおいて矩形メッシュ状に分割されたメッシュ毎（エリア毎）に、携帯端末の位置情報を集計することで、エリア毎のタクシーの需要を予測する技術が開示されている。

国際公開第２０１０／１２３０７５号

特許文献１に記載の技術では、ユーザであるタクシードライバは、タクシーの需要が高いエリアは分かるものの、そのエリア内で実際にどの道路を走行すれば高い営業効率が得られるのかまでは分からない。また、エリア内の需要が把握できたとしてもそのエリアを通常の走行速度では短時間に通り過ぎてしまうことが想定される。

本発明は、以上のような点を考慮してなされたものである。本発明の目的は、タクシーの走行経路に関し、営業効率が高い経路を探索できる情報処理システム、情報処理プログラムおよび情報処理方法を提供することにある。

本発明に係る情報処理システムは、
タクシーの乗車実績情報を取得する乗車実績取得手段と、
前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する需要推定手段と、
前記道路毎のタクシー需要を探索コストに反映させ、タクシー需要が高い経路を優先的に探索する経路探索手段と、
を備える。

本発明によれば、タクシーの走行経路に関し、営業効率が高い経路を探索できる。

図１は、第１の実施形態に係る情報処理システムの概略的な構成を示す図である。 図２は、乗車実績情報データベースに含まれるデータの一例を示す図である。 図３は、道路単位当たりのタクシー需要が高い経路を説明するための図である。 図４は、第１の実施形態に係る情報処理システムの動作の第１の態様を示すフローチャートである。 図５は、第１の実施形態に係る情報処理システムの動作の第１の態様において表示される画面の一例を示す図ある。 図６は、第１の実施形態に係る情報処理システムの動作の第２の態様を示すフローチャートである。 図７は、第１の実施形態に係る情報処理システムの動作の第２の態様において表示される画面の一例を示す図である。 図８は、第１の実施形態に係る情報処理システムの動作の第３の態様を示すフローチャートである。 図９は、第１の実施形態に係る情報処理システムの動作の第３の態様において表示される画面の一例を示す図である。 図１０は、第１の実施形態に係る情報処理システムの動作の第４の態様を示すフローチャートである。 図１１は、第１の実施形態に係る情報処理システムの動作の第４の態様において表示される画面の一例を示す図である。 図１２は、第１の実施形態に係る情報処理システムの動作の第５の態様に示すフローチャートである。 図１３は、第１の実施形態に係る情報処理システムの動作の第５の態様において表示される画面の一例を示す図である。 図１４は、第２の実施形態に係る情報処理システムの概略的な構成を示す図である。 図１５は、経路検索ログデータベースに含まれるデータの一例を示す図である。 図１６は、第２の実施形態に係る情報処理システムの動作の第１の態様を示すフローチャートである。 図１７は、第２の実施形態に係る情報処理システムの動作の第１の態様において表示される画面の一例を示す図ある。 図１８は、第２の実施形態に係る情報処理システムの動作の第２の態様を示すフローチャートである。 図１９は、第２の実施形態に係る情報処理システムの動作の第２の態様において表示される画面の一例を示す図である。 図２０は、第２の実施形態に係る情報処理システムの動作の第３の態様を示すフローチャートである。 図２１は、第２の実施形態に係る情報処理システムの動作の第３の態様において表示される画面の一例を示す図である。 図２２は、第２の実施形態に係る情報処理システムの動作の第４の態様を示すフローチャートである。 図２３は、第２の実施形態に係る情報処理システムの動作の第４の態様において表示される画面の一例を示す図である。 図２４は、第２の実施形態に係る情報処理システムの動作の第５の態様を示すフローチャートである。 図２５は、第２の実施形態に係る情報処理システムの動作の第５の態様において表示される画面の一例を示す図である。

以下に、添付の図面を参照して、本発明の実施の形態を詳細に説明する。なお、各図において同等の機能を有する構成要素には同一の符号を付し、同一符号の構成要素の詳しい説明は繰り返さない。

＜第１の実施形態＞
第１の実施形態に係る情報処理システムについて説明する。図１は、第１の実施形態に係る情報処理システム１の概略的な構成を示す図である。なお、同図において、各機能を行う機能部は、それぞれ各機能を行う手段ということができる。

図１に示すように、情報処理システム１は、端末装置２と、サーバ３とを備えている。端末装置２とサーバ３とは、インターネット等のネットワーク４を介して互いに通信可能に接続されている。ネットワーク４は、無線回線を含むものであれば、回線の種類や形態は問わない。なお、端末装置２およびサーバ３の少なくとも一部は、コンピュータにより実現される。

端末装置２は、走行中のタクシーの車両内部、たとえばダッシュボードに設置されてタクシーとともに移動するものであり、たとえば、スマートフォンやタブレット端末などのモバイル端末、またはカーナビゲーション装置である。

図１に示すように、端末装置２は、端末通信部２１と、端末制御部２２と、端末記憶部２３と、端末入力部２４と、端末表示部２５とを有している。各部は、バスを介して互いに通信可能に接続されている。

端末通信部２１は、端末装置２とネットワーク４との間の通信インターフェースである。端末通信部２１は、ネットワーク４を介して端末装置２とサーバ３との間で情報を送受信する。

端末制御部２２は、端末装置２の各種処理を行う制御手段である。図１に示すように、端末制御部２２は、位置測位部２２ａを有している。位置測位部２２ａは、端末装置２内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。

位置測位部２２ａは、端末装置２の現在位置を測位する。位置測位部２２ａは、たとえば、ＧＰＳなどの電波航法手段による測位情報に基づいて現在位置を測位する。位置測位部２２ａは、加速度センサや地磁気センサなどの自律航法手段による測位情報を測位に用いてもよい。

本実施形態において、端末装置２は、走行中のタクシーの車両内部に設定されて当該タクシーとともに移動するものであるから、位置測位部２２ａにより測位された位置情報は、少なくともタクシーの走行中におけるタクシーの位置情報を示すものである。

端末制御部２２は、位置測位部２２ａにより測位された位置情報を、端末通信部２１を通じてサーバ３に送信する。端末装置２から送信された測位情報（すなわち、タクシーの位置情報）は、サーバ３に記憶される。サーバ３に複数の時点での位置情報が記憶されることで、タクシーの移動履歴情報が形成される。

端末記憶部２３は、たとえば内蔵メモリや外部メモリ（ＳＤメモリカード等）などのデータストレージである。端末記憶部２３には、端末制御部２２が取り扱う各種データが記憶される。端末記憶部２３は、必ずしも端末装置２内に設けられていなくてもよく、ネットワーク４を介して端末装置２と通信可能に接続された別の装置（たとえば、サーバ３）内に設けられていてもよい。

端末入力部２４は、ユーザ（すなわちタクシードライバ）が端末装置２に情報を入力するためのインターフェースであり、たとえばモバイル端末におけるタッチパネルやマイクロフォンなどである。

端末表示部２５は、端末装置２からユーザ（すなわちタクシードライバ）に対して各種情報を表示するインターフェースであり、たとえば液晶ディスプレイ等の映像表示手段である。具体的には、たとえば、端末表示部２５は、ユーザからの操作を受け付けるためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示してもよい。

次に、サーバ３について説明する。図１に示すように、サーバ３は、サーバ通信部３１と、サーバ制御部３２と、サーバ記憶部３３とを有している。各部は、バスを介して互いに通信可能に接続されている。

このうちサーバ通信部３１は、サーバ３とネットワーク４との間の通信インターフェースである。サーバ通信部３１は、ネットワーク４を介して端末装置２とサーバ３との間で情報を送受信する。

サーバ記憶部３３は、たとえばハードディスク等の固定型データストレージである。サーバ記憶部３３には、サーバ制御部３２が取り扱う各種データが記憶される。たとえば、サーバ記憶部３３は、交通ネットワーク情報を含む経路ネットワーク情報データベース３３ａと、地図情報を含む地図情報データベース３３ｂと、乗車実績情報データベース３３ｃとを含んでいる。

交通ネットワーク情報は、鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。なお、本明細書において「道路」とは、ノード間の道路区間であるリンクを意味するものとする。

地図情報は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。また、地図情報は公共交通機関の路線図に関する路線図情報を含んでいてもよい。また、地図情報は、地図上に表示される終電の終着駅や終バスの終着バス停における終着時刻情報を含んでいてもよく、地図上に表示される店舗の閉店時間情報を含んでいてもよい。

乗車実績情報データベース３３ｃには、タクシー事業者から取得された複数のタクシーの乗車実績情報がデータベース化されている。図２は、乗車実績情報データベース３３ｃに含まれるデータの一例を示している。

図２に示す例では、乗車実績情報データベース３３ｃには、乗車日時と、乗車位置（たとえば緯度経度）と、降車位置（たとえば緯度経度）と、最終目的地（ＰＯＩ；Ｐｏｉｎｔ ｏｆ ｉｎｔｅｒｅｓｔ）と、流し／待ち／迎車のいずれのタクシーであるのかを識別する識別情報と、対向車線がある道路での車両走行方向と、タクシーの車種（小型／中型／大型）とが互いに関連付けて記憶されている。タクシーの車種には、バリアフリー車両か否かの情報や乗車定員の情報が含まれていてもよい。また、本件明細書では、端末装置２にインストールされた配車アプリを介して予約されたタクシーが向かう場合は、迎車に該当するものとし、「迎車」の識別情報には、配車アプリを介した予約による迎車か、それ以外（たとえば電話予約）の迎車かを識別する情報が含まれていてもよい。

図示は省略するが、乗車実績情報データベース３３ｃには、さらに、乗車金額、乗車距離、乗客の属性（性別、年齢、観光客か否か、外国人か否か、車椅子など介助が必要な否か、乗車人数など）、天候（雨量、温度、湿度など）、曜日（祝日）、季節、曜日の並び（休日の前日か否か）、特定日（たとえば給料日である２５日）か否か、月末か否か、六曜（大安、仏滅など）といった情報が互いに関連付けて記憶されていてもよい。

上記の経路ネットワーク情報データベース３３ａ、地図情報データベース３３ｂおよび乗車実績情報データベース３３ｃは、それぞれ、所定のタイミングでアップデートされてもよい。

なお、サーバ記憶部３３の一部または全部は、必ずしもサーバ３内に設けられていなくてもよく、ネットワーク４を介してサーバ３と通信可能に接続された別の装置内に設けられていてもよい。

サーバ制御部３２は、サーバ３の各種処理を行う制御手段である。図１に示すように、サーバ制御部３２は、乗車実績取得部３２ａと、需要推定部３２ｂと、経路探索部３２ｃと、表示制御部３２ｄと、時間指定受付部３２ｅと、走行区域指定受付部３２ｆと、目的地指定受付部３２ｇと、スコア算出部３２ｈと、を有している。これらの各部は、サーバ３内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。

乗車実績取得部３２ａは、乗車実績情報データベース３３ｃを参照して、所定の地域（たとえば法令で定められた営業区域）内におけるタクシーの乗車実績情報を取得する。

需要推定部３２ｂは、地図情報データベース３３ｂを参照して、乗車実績取得部３２ａにより取得された乗車実績情報毎に、乗車実績情報に含まれる乗車位置情報（たとえば緯度経度情報）を、地図上の道路にマッチングさせる。そして、需要推定部３２ｂは、道路毎の乗車実績数を集計し、集計した道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する。たとえば、需要推定部３２ｂは、乗車実績数が比較的高い道路についてはタクシー需要として比較的高い数値を推定し、乗車実績数が比較的低い道路についてはタクシー需要として比較的低い数値を推定する。

需要推定部３２ｂは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。たとえば、長さ１００ｍのＡ道路の乗車実績数と長さ２００ｍのＢ道路の乗車実績数とが同一である場合、Ａ道路の単位距離当たりの乗車実績数はＢ道路の単位距離当たりの乗車実績数の２倍となるため、需要推定部３２ｂは、Ａ道路のタクシー需要がＢ道路のタクシー需要の２倍であると推定してもよい。

また、図２を参照し、乗車実績情報に、流し／待ち／迎車のいずれのタクシーであるのかを識別する識別情報が含まれる場合には、需要推定部３２ｂは、識別情報が「流し」の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定してもよい。「流し」の乗車実績情報のみを利用することで、タクシー需要の推定精度を高めることができる。

経路探索部３２ｃは、需要推定部３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。ここで、「道路単位当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路に含まれる道路の数で除算した値に相当する。また、「単位距離当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路の総距離で除算した値に相当する。

たとえば、図３を参照し、Ａ道路からＢ道路までの経路のうち、実線で示されたルートは、経路全体でのタクシー需要の合計が２１０であり、当該経路に含まれる道路の数が５であるから、道路単位当たりのタクシー需要は２１０／５＝４２である。一方、破線で示されたルートは、経路全体でのタクシー需要の合計が４３０であり、当該経路に含まれる道路の数が９であるから、道路単位当たりのタクシー需要は４３０／９≒４７である。したがって、破線で示されたルートは、実線で示されたルートよりも、道路単位当たりのタクシー需要が高い経路となる。この場合、経路探索部３２ｃは、破線で示されたルートを、実線で示されたルートよりも優先的に探索する。

ユーザ（すなわちタクシードライバ）が、端末装置２の端末入力部２４を介して、経路探索条件として、営業区域、走行希望道路、走行希望時間（〇時から〇時まで営業したい。今から〇時間走りたいなど）、走行希望距離、探索モード（ターゲットを長距離客あるいは短距離客（ちょい乗り客）にするなど）、乗客の属性（女性客に乗ってほしいなど）を設定した場合には、設定された経路探索条件が、端末装置２からサーバ３へと送信され、経路探索部３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、ユーザにより設定された経路探索条件に基づいて、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。

経路探索部３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、経路ネットワーク情報データベース３３ａを参照し、各道路（リンク）について、歩道の有無、車線の数、交差点分岐の有無、走りやすさ（道路交通状況、渋滞度、道幅、事故リスク）をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。また、本件発明者の知見によれば、鉄道駅やバス停から離れた地域はタクシー需要が比較的高いと推定できることから、経路探索部３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、各道路について、鉄道駅および／またはバス停からの距離をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。そのほか、周辺の鉄道駅やバス停における運行ダイヤやその行き先（目的地）を考慮してもよい。すなわち、ある地域について周辺の鉄道駅やバス停における次の便の発車時刻が現在時刻から所定時間以上先である場合は、現時点における当該地域のタクシー需要が比較的高いものと推定してもよい。

また、経路探索部３２ｃは、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路として、特定スポット（たとえば、駅やホテルなどの大規模施設のタクシープール）における「待機」を組み込んだ経路を探索してもよい。この場合、経路探索部３２ｃは、たとえば各タクシーの端末装置２から送信される位置情報に基づいて、特定スポットでのリアルタイムの客持ちタクシー台数を算出し、当該スポットでの客待ちタクシー台数が所定の閾値以下であれば、当該スポットでの「待機」を組み込んだ経路を探索し、当該スポットでの客待ちタクシー台数が所定の閾値を超えていれば、当該スポットでの「待機」を組み込むことなく「流し」の経路を探索するようになっていてもよい。

表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に出力させる。表示制御部３２ｄは、需要推定部３２ｂにより推定された道路毎のタクシー需要を地図上に重ねて端末表示部２５に表示させてもよい。具体的には、たとえば、表示制御部３２ｄは、道路毎のタクシー需要を、図３に示すように、地図上の道路の近傍に数値で表示させてもよいし、図５に示すように、地図上の道路を数値に応じて色分けすることにより表示させてもよい。

また、本件発明者の知見によれば、鉄道駅からもバス停からも離れた地域はタクシー需要が比較的高いと推定できることから、表示制御部３２ｄは、鉄道駅から所定距離（たとえば徒歩１５分）以内の範囲および／またはバス停から所定距離（たとえば徒歩５分）以内の範囲を、公共交通手段からのアクセス圏として設定し、当該アクセス圏を地図上に色分けして端末表示部２５に表示させてもよい。この場合、公共交通手段からのアクセス圏外である交通空白地域を可視化することができ、ユーザであるタクシードライバは、「流し」のルートを決める際の参考情報としてこれを利用することができる。

また、表示制御部３２ｄは、図５に示すように、経路探索部３２ｃにより抽出された複数の経路のうちの少なくとも１つを、地図上に重ねて端末表示部２５に表示させてもよい。この場合、表示制御部３２ｄは、各タクシーの端末装置２から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部２５に表示させる経路を割り振ってもよい。あるいは、タクシーの事業者が、各タクシーの端末装置２から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部２５に表示させる経路を割り振ってもよい。特定の経路に車両が集中することなく、複数の経路にまんべんなく車両が割り振られることにより、事業者単位での営業効率を最大化することができる。

時間指定受付部３２ｅは、ユーザが端末装置２の端末入力部２４を介して所定の時間（時間帯ないし時刻）を指定し、当該指定された時間の情報が端末装置２からサーバ３へと送信されると、当該時間の指定を受け付ける。ここで、ユーザは、たとえば端末表示部２５に表示されたスライドバー５１（図１３参照）を操作することにより、所定の時間を指定（ないし変更）してもよい。時間指定受付部３２ｅが時間の指定を受け付けると、需要推定部３２ｂは、指定された時間の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定する。ここで、「指定された時間の乗車実績情報」とは、「時間帯」が指定された場合は、当該指定された時間帯の乗車実績情報を意味し、「時刻」が指定された場合は、当該指定された時刻を含む所定長さ（たとえば２時間）の時間帯の乗車実績情報を意味する。

走行区域指定受付部３２ｆは、ユーザが端末装置２の端末入力部２４を介して所定の走行区域を指定し、指定された走行区域の情報が端末装置２からサーバ３へと送信されると、当該走行区域の指定を受け付ける。走行区域指定受付部３２ｆが走行区域の指定を受け付けると、経路探索部３２ｃは、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。

具体的には、たとえば、図７を参照し、経路探索部３２ｃは、地図情報データベース３３ｂを参照して、指定された走行区域に含まれる１または２以上のノードまたは道路（リンク）を仮想経由地Ｖ１、Ｖ２として設定するとともに、タクシーの現在位置を目的地Ｇとして設定したうえで、道路毎のタクシー需要を探索コストに反映させて、経路探索を行う。この場合、経路探索部３２ｃは、仮想経由地Ｖ１、Ｖ２を走行区域内でランダムに設定してもよい。これにより、特定の巡回経路だけに車両が集中することを防ぐことができる。

目的地指定受付部３２ｇは、ユーザが端末装置２の端末入力部２４を介して所定の目的地を指定し、指定された目的地の情報が端末装置２からサーバ３へと送信されると、当該目的地の指定を受け付ける。目的地指定受付部３２ｇが目的地の指定を受け付けると、経路探索部３２ｃは、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。この場合、経路探索部３２ｃは、指定された目的地まで走行中のタクシーが当該目的地またはその近くに到達したときに、タクシー需要が予め定められた第１閾値より高い高需要スポットが、当該タクシーの近くにあるか否かを判定し、高需要スポットが近くにある場合には、指定された目的地を当該高需要スポットに変更し、当該高需要スポットまでの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索してもよい。

スコア算出部３２ｈは、経路探索部３２ｃにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する。スコア算出部３２ｈは、経路のバリエーションが出るよう（複数の経路同士の走行ルートや方面が異なるよう）、複数の経路同士の走行ルートや方面が類似する場合には、当該複数の経路のスコアを類似の割合に応じて下げてもよい。スコア算出部３２ｈにより経路毎のスコアが算出されると、表示制御部３２ｄは、経路探索部３２ｃにより抽出された複数の経路を、スコア算出部３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させる（たとえば図１１参照）。図示は省略するが、表示制御部３２ｄは、走行ルートの選択をしやすくするため、経路探索部３２ｃにより抽出された複数の経路を地図上に表示の上、経路の概要を示す名称とともにスコアを表示（たとえば、「湾岸回りコース：９０点」など）してもよい。そのほか、走りなれたルートなど、ユーザにとって走行したいルートが具体的に決まっている場合には、ユーザが端末表示部２５に表示されている地図上の道路をなぞる等といった操作により走行ルートを指定し、指定された走行ルートの情報が端末装置２からサーバ３へと送信されると、スコア算出部３２ｈが、当該走行ルートの指定を受け付け、当該ルートについてのスコア値を算出するようにしてもよい。

一例として、スコア算出部３２ｈは、経路探索部３２ｃにより抽出された複数の経路の各々について、たとえば走行中のタクシーの位置情報をマッチングさせることにより、当該経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第２閾値を超えた場合には、当該経路のスコアを下げてもよい。別の一例として、スコア算出部３２ｈは、各タクシーの端末装置２からサーバ３へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第２閾値を超えた場合には、当該経路のスコアを下げてもよい。更に別の一例として、スコア算出部３２ｈは、経路の提示実績数に応じてスコアを下げてもよい。すなわち、スコア算出部３２ｈは、経路の提示実績数が予め定められた第３閾値を超えた場合には（第３閾値を超える回数、当該経路が提示されたら）、当該経路のスコアを下げてもよい。これらにより、特定の経路だけに車両が集中することを防ぐことができる。

需要推定部３２ｂは、乗車実績情報に含まれる天候（雨量、温度、湿度など）、曜日（祝日）、季節、曜日の並び（休日の前日か否か）、特定日（たとえば給料日である２５日）か否か、月末か否か、六曜（大安、仏滅など）のうち少なくとも一つの情報（特徴量）と、乗車実績情報毎に地図上の道路とマッチングさせて道路毎に集計された乗車実績数に基づいて推定された道路毎のタクシー需要とを教師データとして機械学習を実行し、上記特徴量を入力として道路毎のタクシー需要を推定する学習モデルを生成してもよい。

そして、ユーザ（すなわちタクシードライバ）が、端末装置２の端末入力部２４を介して、天候（雨量、温度、湿度など）、曜日（祝日）、季節、曜日の並び（休日の前日か否か）、特定日（たとえば給料日である２５日）か否か、月末か否か、六曜（大安、仏滅など）のうち少なくとも一つの情報（特徴量）を入力した場合には、入力された情報（特徴量）が端末装置２からサーバ３へと送信され、需要推定部３２ｂは、生成された学習モデルを利用し、ユーザにより入力された情報（特徴量）に基づいて、道路毎のタクシー需要を推定してもよい。この場合、タクシーの乗車実績情報をタクシー事業者から取得できない状況でも、需要推定部３２ｂは、天候や曜日などの情報（特徴量）を入力として学習モデルを利用することで、道路毎のタクシー需要を推定することが可能となる。

（動作の第１の態様）
次に、図４および図５を参照して、第１の実施形態に係る情報処理システム１の動作の第１の態様について説明する。図４は、情報処理システム１の動作の第１の態様を示すフローチャートである。図５は、情報処理システム１の動作の第１の態様において表示される画面の一例を示す図である。

図４に示すように、まず、乗車実績取得部３２ａは、乗車実績情報データベース３３ｃを参照して、所定の地域（たとえば法令で定められた営業区域）内におけるタクシーの乗車実績情報を取得する（ステップＳ１０）。

次に、需要推定部３２ｂは、地図情報データベース３３ｂを参照して、乗車実績取得部３２ａにより取得された乗車実績情報に含まれる乗車位置情報（たとえば緯度経度情報）を、地図上の道路にマッチングさせる（ステップＳ１１）。需要推定部３２ｂは、乗車実績取得部３２ａにより取得された乗車実績情報のうち、識別情報が「流し」の乗車実績情報の乗車位置情報のみを、地図上の道路にマッチングさせてもよい。

次に、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所定の時間を指定すると、指定された時間の情報は端末装置２からサーバ３へと送信され、時間選択受付部３２ｅは、当該時間の指定を受け付ける（ステップＳ１２）。

そして、需要推定部３２ｂは、ステップＳ１１におけるマッチング結果を参照して、指定された時間の道路毎の乗車実績数のみを集計し、集計した道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する（ステップＳ１３）。需要推定部３２ｂは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。また、ステップＳ１１において、識別情報が「流し」の乗車実績情報の乗車位置情報のみを、地図上の道路にマッチングさせる場合には、需要推定部３２ｂは、識別情報が「流し」の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定してもよい。

ステップＳ１３において、需要推定部３２ｂは、乗車実績情報に含まれる乗車金額、乗車距離、乗客の属性（性別、年齢、観光客か否か、外国人か否か、車椅子など介助が必要な否か、乗車人数など）、天候（雨量、温度、湿度など）、曜日（祝日）、季節、曜日の並び（休日の前日か否か）、特定日（たとえば給料日である２５日）か否か、月末か否か、六曜（大安、仏滅など）のうち少なくとも一つの情報を考慮して、道路毎のタクシー需要を推定してもよい。一例として、ユーザ（すなわちタクシードライバ）が、端末装置２の端末入力部２４を介して対象日の日付と時間を指定すると、指定された対象日の日付と時間の情報が端末装置２からサーバ３へと送信され、需要推定部３２ｂは、対象日の指定時間に対応する天候の予報情報を外部サーバから取得し、取得した天候の予報情報を考慮して、道路毎のタクシー需要を推定してもよい。別例として、ユーザ（すなわちタクシードライバ）が、端末装置２の端末入力部２４を介して時間帯とともに希望する乗客属性（性別、特定の国籍の外国人など）を指定すると、指定された時間帯および乗客属性の情報が端末装置２からサーバ３へと送信され、需要推定部３２ｂは、指定された時間帯および乗客属性の情報を考慮して、道路毎のタクシー需要を推定してもよい。

次に、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所定の目的地を指定すると、指定された目的地の情報は端末装置２からサーバ３へと送信され、目的地指定受付部３２ｇは、当該目的地の指定を受け付ける（ステップＳ１４）。

そして、経路探索部３２ｃは、需要推定部３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ１５）。なお、「道路毎のタクシー需要を探索コストに反映させ」るとは、従来の経路探索では、たとえば時間、金銭および走りやすさをコスト係数として道路毎のコストを計算していたのに対し、時間、金銭および走りやすさに加えて、タクシー需要もコスト係数に含めて道路毎のコストを計算することを意味する。

次に、表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１６）。図５に示すように、表示制御部３２ｄは、経路探索部３２ｃにより抽出された経路Ｒを、地図上に矢印で表示させてもよい。また、表示制御部３２ｄは、端末装置２から取得される測位情報（タクシーの現在の位置情報）Ａを、地図上に重ねて表示させてもよい。

また、表示制御部３２ｄは、需要推定部３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１７）。図５に示すように、表示制御部３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザ（すなわちタクシードライバ）は、タクシー需要が高い道路を一目で直感的に把握できるようになる。

ところで、発明が解決しようとする課題の欄でも言及したように、従来のタクシーの需要予測技術では、携帯端末の位置情報を利用してエリア毎のタクシー需要を予測するため、ユーザであるタクシードライバは、タクシー需要が高いエリアは分かるものの、そのエリア内で実際にどの道路を走行すれば高い営業効率が得られるのかまでは分からなかった。

これに対し、本実施の形態によれば、乗車実績取得部３２ａが、タクシーの乗車実績情報を取得し、需要推定部３２ｂが、乗車実績情報に含まれる乗車位置情報を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定し、経路探索部３２ｃが、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索するため、タクシーの走行経路に関し、営業効率が高い経路を探索することが可能となる。これにより、ユーザであるタクシードライバは、実際にどの道路を走行すれば高い営業効率が得られるのかが分かるようになり、営業効率を高めることができる。

（動作の第２の態様）
第１の実施形態に係る情報処理システム１の動作の第２の態様について、図６および図７を参照して説明する。図６は、情報処理システム１の動作の第２の態様を示すフローチャートである。図７は、情報処理システム１の動作の第２の態様において表示される画面の一例を示す図である。第２の態様において、需要推定部３２ｂが道路毎のタクシー需要を推定する工程まで（ステップＳ１０〜Ｓ１３）は、上述した第１の態様と同様であり、説明を省略する。

図６に示すように、第２の態様では、需要推定部３２ｂが道路毎のタクシー需要を推定した後（ステップＳ１３の後）、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所望の走行区域（たとえば、得意とするエリア）を指定すると、指定された走行区域の情報は端末装置２からサーバ３へと送信され、走行区域指定受付部３２ｆは、当該走行区域の指定を受け付ける（ステップＳ２４）。

そして、経路探索部３２ｃは、需要推定部３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ２５）。図７に示す例では、経路探索部３２ｃは、経路探索条件として、地図情報データベース３３ｂを参照して、指定された走行区域に含まれる複数（図示された例では２つ）のノードを仮想経由地Ｖ１、Ｖ２として設定するとともに、タクシーの現在位置を目的地Ｇとして設定したうえで、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索する。

次に、表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ２６）。図７に示すように、表示制御部３２ｄは、経路探索部３２ｃにより抽出された経路Ｒを、地図上に矢印で表示させてもよい。また、表示制御部３２ｄは、端末装置２から取得される測位情報（タクシーの現在の位置情報）Ａを、地図上に重ねて表示させてもよい。

また、表示制御部３２ｄは、需要推定部３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ２７）。図７に示すように、表示制御部３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。

以上のような第２の態様によれば、上述した第１の態様と同様の作用効果が得られることに加えて、ユーザであるタクシードライバは、ある目的地までの経路（一方向の経路）の代わりに、指定された走行区域内で周遊（巡回）する経路を探索することができ、空車での走行時間の短縮を図ることができる。

（動作の第３の態様）
第１の実施形態に係る情報処理システム１の動作の第３の態様について、図８および図９を参照して説明する。第３の態様は、指定された目的地まで走行中のタクシーが、当該目的地またはその近くに到達したときに情報処理システム１により行われる処理（オートリルート処理）に関する。図８は、情報処理システム１の動作の第３の態様を示すフローチャートである。図９は、情報処理システム１の動作の第３の態様において表示される画面の一例を示す図である。

まず、図９の上図を参照し、サーバ制御部３２は、端末装置２から送信される測位情報に基づいて、指定された目的地Ｇまで走行中のタクシーの現在位置Ａが、当該目的地Ｇまたはその近くに到達したか否かを判定する。そして、走行中のタクシーの現在位置Ａが目的地Ｇまたはその近くに到達したと判定されると、サーバ制御部３２は、予め定められた第１閾値より高いタクシー需要を有する高需要スポットＰが、当該タクシーの現在位置Ａの近くにあるか否かを判定する（ステップＳ３１）。

そして、高需要スポットＰがタクシーの現在位置Ａの近くにあると判定された場合には（ステップＳ３１：ＹＥＳ）、図９の下図を参照し、指定された目的地Ｇを当該高需要スポットＰへと変更する（ステップＳ３２）。

そして、経路探索部３２ｃは、上述したステップＳ１５と同様にして、需要推定部３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地Ｇ（すなわち高需要スポットＰ）までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ３３）。

次に、表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ３４）。図９の下図に示すように、表示制御部３２ｄは、経路探索部３２ｃにより抽出された経路Ｒ２を、地図上に矢印で表示させてもよい。

また、表示制御部３２ｄは、需要推定部３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ３５）。図９に示すように、表示制御部３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。

上述したステップＳ３１〜Ｓ３５は、走行中のタクシーの現在位置Ａが指定された目的地Ｇまたはその近くに到達するたびに繰り返されてもよい。

以上のような第３の態様によれば、目的地Ｇまたはその近くに到達するたびに新たな走行経路が提示されるため、ユーザであるタクシードライバは、端末入力部２４を操作して目的地を指定するためにタクシーをいちいち停車させる必要がなくなり、営業効率をさらに高めることができる。

（動作の第４の態様）
第１の実施形態に係る情報処理システム１の動作の第４の態様について、図１０および図１１を参照して説明する。図１０は、情報処理システム１の動作の第４の態様を示すフローチャートである。図１１は、情報処理システム１の動作の第４の態様において表示される画面の一例を示す図である。第４の態様において、経路探索部３２ｃが道路単位当たりのタクシー需要が高い経路を優先的に探索する工程まで（ステップＳ１０〜Ｓ１５）は、上述した第１の態様と同様であり、説明を省略する。

図１０に示すように、第４の態様では、経路探索部３２ｃが道路単位当たりのタクシー需要が高い経路を優先的に探索した後（ステップＳ１５の後）、スコア算出部３２ｈが、経路探索部３２ｃにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する（ステップＳ３３）。

次に、表示制御部３２ｄは、図１１の上図に示すように、経路探索部３２ｃにより抽出された複数の経路を、スコア算出部３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させる（ステップＳ３４）。

次に、ユーザであるタクシードライバが、端末表示部２５に表示された各経路のスコアを参照しながら、端末入力部２４を介して１つの経路を選択すると、選択された経路の情報が端末装置２からサーバ３へと送信され、サーバ制御部３２は、経路の選択を受け付ける（ステップＳ３５）。

そして、表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、ユーザにより選択された経路の情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ３６）。

次いで、スコア算出部３２ｈは、経路探索部３２ｃにより抽出された複数の経路の各々について、当該経路を走行するタクシーの数を推定する。具体的には、たとえば、スコア算出部３２ｈは、各タクシーの端末装置２からサーバ３へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定する。あるいは、スコア算出部３２ｈは、各タクシーの端末装置２からサーバ３へと送信される各タクシーの位置情報に基づいて、各経路を走行するタクシーの数を推定してもよい。図１１の中央図に示すように、スコア算出部３２ｈ、推定された各経路を走行するタクシーの数を、スコア算出部３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させてもよい。そして、スコア算出部３２ｈは、各経路を走行するタクシーの数が、予め定められた第２閾値（たとえば、１０台）を超えたか否かを判定する（ステップＳ３７）。

各経路を走行するタクシーの数が第２閾値を超えた場合には（ステップＳ３７：ＹＥＳ）、スコア算出部３２ｈは、当該の経路のスコアを下げる（ステップＳ３８）。図１１に示す例では、ルート１を走行するタクシーの数（＝１２台）が第２閾値（＝１０台）を超えたことから、スコア算出部３２ｈは、ルート１のスコアを「９５」から「６５」へと下げている。これにより、ルート１の魅力が下がり、ルート１に車両がこれ以上集中することを防ぐことができる。

以上のような第４の態様によれば、ユーザであるタクシードライバが、端末表示部２５に表示された各経路のスコアを参照しながら、端末入力部２４を介して１つの経路を選択する際に、スコア算出部３２ｈが、走行するタクシーの数が第２閾値を超えている経路についてはそのスコアを下げることで、当該経路の魅力を下げるため、ユーザであるタクシードライバは、走行するタクシーの数が第２閾値を超えている経路の選択を避けるようになる。これにより、各経路を走行するタクシーの数を自動的に分散させることが可能となり、事業者単位での営業効率を最大化することができる。

（動作の第５の態様）
第１の実施形態に係る情報処理システム１の動作の第５の態様について、図１２および図１３を参照して説明する。図１２は、情報処理システム１の動作の第５の態様を示すフローチャートである。図１３は、情報処理システム１の動作の第５の態様において表示される画面の一例を示す図である。第５の態様において、需要推定部３２ｂが道路毎のタクシー需要を推定する工程まで（ステップＳ１０〜Ｓ１３）は、上述した第１の態様と同様であり、説明を省略する。

図１２に示すように、第５の態様では、需要推定部３２ｂが道路毎のタクシー需要を推定した後（ステップＳ１３の後）、表示制御部３２ｄは、地図情報データベース３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、需要推定部３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１７）。図１３に示すように、表示制御部３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。

図１３に示すように、表示制御部３２ｄは、所定の地域の地図に隣接して、時間帯を選択（ないし変更）するためのスライドバー５１を、端末表示部２５に表示させてもよい。

次に、ユーザであるタクシードライバが、端末入力部２４を介してスライドバー５１を操作して新たな時間を指定すると、指定された時間の情報は端末装置２からサーバ３へと送信される。時間指定受付部３２ｅは、新たに指定された時間の情報が端末装置２からサーバ３へと送信されたか否かに応じて、時間の変更があるか否かを判定する（ステップＳ１８）。

そして、時間の変更があると判定された場合には（ステップＳ１８：ＹＥＳ）、時間指定受付部３２ｅは、新たに指定された時間の指定を受け付け（ステップＳ１２）、新たに指定された時間についてステップＳ１３〜Ｓ１７の処理を繰り返す。

以上のような第５の態様によれば、ユーザであるタクシードライバは、端末表示部２５に表示される道路毎のタクシー需要情報を、時間別に容易に切り替えて比較したり、道路毎のタクシー需要の時間変化を把握したりすることが可能となり、営業効率の高い経路の分析にこれを役立てることができる。

＜第２の実施形態＞
次に、第２の実施形態に係る情報処理システムについて説明する。図１４は、第２の実施形態に係る情報処理システム１０１の概略的な構成を示す図である。なお、同図において、各機能を行う機能部は、それぞれ各機能を行う手段ということができる。

図１４に示すように、情報処理システム１０１は、端末装置２と、サーバ１０３とを備えている。端末装置２とサーバ１０３とは、インターネット等のネットワーク４を介して互いに通信可能に接続されている。端末装置２およびネットワーク４の構成は、上述した第１の実施形態と同様であり、説明を省略する。なお、端末装置２およびサーバ１０３の少なくとも一部は、コンピュータにより実現される。

図１４に示すように、サーバ１０３は、サーバ通信部１３１と、サーバ制御部１３２と、サーバ記憶部１３３とを有している。各部は、バスを介して互いに通信可能に接続されている。

このうちサーバ通信部１３１は、サーバ１０３とネットワーク４との間の通信インターフェースである。サーバ通信部１３１は、ネットワーク４を介して端末装置２とサーバ１０３との間で情報を送受信する。

サーバ記憶部１３３は、たとえばハードディスク等の固定型データストレージである。サーバ記憶部１３３には、サーバ制御部１３２が取り扱う各種データが記憶される。たとえば、サーバ記憶部１３３は、交通ネットワーク情報を含む経路ネットワーク情報データベース１３３ａと、地図情報を含む地図情報データベース１３３ｂと、経路検索ログデータベース１３３ｃとを含んでいる。

交通ネットワーク情報は、鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。なお、本明細書において「道路」とは、ノード間の道路区間であるリンクを意味するものとする。

地図情報は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。また、地図情報は公共交通機関の路線図に関する路線図情報を含んでいてもよい。また、地図情報は、地図上に表示される終電の終着駅や終バスの終着バス停における終着時刻情報を含んでいてもよく、地図上に表示される店舗の閉店時間情報を含んでいてもよい。

経路検索ログデータベース１３３ｃには、乗換検索や地図上のルート検索などの経路検索Ｗｅｂサービス（またはアプリ）を利用した複数のユーザの経路検索ログがデータベース化されている。図１５は、経路検索ログデータベース１３３ｃに含まれるデータの一例を示している。

図１５に示す例では、経路検索ログデータベース１３３ｃには、検索条件と検索結果とが互いに関連付けて記憶されている。検索条件には、出発地と、目的地と、出発時刻または到着時刻と、タクシー利用の有無とが含まれる。また、探索結果には、出発地から目的地までの経路の内容と、タクシーの利用の有無とが含まれる。

経路検索ログデータベース１３３ｃは、乗換検索や地図上のルート検索から得られる経路検索ログに加えて、スポット検索から得られるスポット検索ログを含んでいてもよい。また、経路検索ログデータベース１３３ｃは、検索ログとして、タクシー配車サービスで入力された配車希望位置情報やタクシー経路検索サービス、タクシー料金検索サービスで入力された出発地の位置情報を含んでいてもよい。

上記の経路ネットワーク情報データベース１３３ａ、地図情報データベース１３３ｂおよび乗車実績情報データベース１３３ｃは、それぞれ、所定のタイミングでアップデートされてもよい。

なお、サーバ記憶部１３３の一部または全部は、必ずしもサーバ１０３内に設けられていなくてもよく、ネットワーク４を介してサーバ１０３と通信可能に接続された別の装置内に設けられていてもよい。

サーバ制御部１３２は、サーバ１０３の各種処理を行う制御手段である。図１４に示すように、サーバ制御部１３２は、経路検索ログ取得部１３２ａと、需要推定部１３２ｂと、経路探索部１３２ｃと、表示制御部１３２ｄと、時間指定受付部１３２ｅと、走行区域指定受付部１３２ｆと、目的地指定受付部１３２ｇと、スコア算出部１３２ｈと、を有している。これらの各部は、サーバ１０３内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。

経路検索ログ取得部１３２ａは、経路検索ログ情報データベース１３３ｃを参照して、所定の地域（たとえば法令で定められた営業区域）内に出発地または目的地が含まれる経路検索ログを取得する。経路検索ログ取得部１３２ａは、経路検索ログ情報データベース１３３ｃを参照し、所定の地域（たとえば法令で定められた営業区域）内に出発地または目的地が含まれる経路検索ログに加えて、当該地域内に検索対象のスポットが含まれるスポット検索ログを取得してもよい。

需要推定部１３２ｂは、地図情報データベース１３３ｂを参照して、経路検索ログ取得部１３２ａにより取得された経路検索ログ毎に、経路検索ログに含まれる出発地または目的地の位置情報を、地図上のスポットにマッチングさせる。経路検索ログ取得部１３２ａによりスポット検索ログが取得されている場合には、需要推定部１３２ｂは、スポット検索ログに含まれる検索対象のスポットの位置情報を、地図上のスポットにマッチングさせてもよい。そして、需要推定部１３２ｂは、スポット毎の検索回数（経路検索における出発地または目的地として指定された回数）を集計し、集計したスポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定する。たとえば、検索回数が多いスポット周辺は混雑が予測されるから、需要推定部１３２ｂは、検索回数が比較的多いスポット周辺の道路についてはタクシー需要として比較的高い数値を推定し、検索回数が比較的低いスポット周辺の道路についてはタクシー需要として比較的低い数値を推定する。また、需要推定部１３２ｂは、混雑が予測されるスポットからの距離に応じて各道路のタクシー需要を推定してもよいし、混雑が予測されるスポットの出入口からの距離に応じて各道路のタクシー需要を推定してもよい。

また、図１５を参照し、経路検索ログの検索条件または検索結果に、タクシーの利用の有無を示す情報が含まれる場合には、需要推定部１３２ｂは、タクシーの利用ありの経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。タクシーの利用ありの経路検索ログのみを利用することで、タクシー需要の推定精度を高めることができる。

需要推定部１３２ｂは、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ（いわゆる事前経路検索ログ）のみに基づいて、道路毎のタクシー需要を推定してもよい。本件発明者らの知見によれば、未来の日時を指定して経路検索を行うユーザは、当該指定された日時において検索結果どおりの経路で移動する可能性が比較的高いから、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ（事前経路検索ログ）のみを利用することで、タクシー需要の推定精度を高めることができる。

また、需要推定部１３２ｂは、終電検索（準終電検索を含む）または始発検索の経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。なお、本明細書において「準終電検索」とは、目的地までの終電後の経路であって、目的地の手前の途中駅までの終電の経路と当該途中駅から目的地までのタクシーの経路との組み合わせを検索することをいう。本件発明者らの知見によれば、終電検索（準終電検索を含む）または始発検索を行うユーザは、検索結果どおりの経路で移動する可能性が比較的高いから、終電検索（準終電検索を含む）または始発検索の経路検索ログのみを利用することで、タクシー需要の推定精度を高めることができる。

経路探索部１３２ｃは、需要推定部１３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。ここで、「道路単位当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路に含まれる道路の数で除算した値に相当する。また、「単位距離当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路の総距離で除算した値に相当する。

たとえば、図３を参照し、Ａ道路からＢ道路までの経路のうち、実線で示されたルートは、経路全体でのタクシー需要の合計が２１０であり、当該経路に含まれる道路の数が５であるから、道路単位当たりのタクシー需要は２１０／５＝４２である。一方、破線で示されたルートは、経路全体でのタクシー需要の合計が４３０であり、当該経路に含まれる道路の数が９であるから、道路単位当たりのタクシー需要は４３０／９≒４７である。したがって、破線で示されたルートは、実線で示されたルートよりも、道路単位当たりのタクシー需要が高い経路となる。この場合、経路探索部１３２ｃは、破線で示されたルートを、実線で示されたルートよりも優先的に探索する。

ユーザ（すなわちタクシードライバ）が、端末装置２の端末入力部２４を介して、経路探索条件として、営業区域、走行希望道路、走行希望時間（〇時から〇時まで営業したい。今から〇時間走りたいなど）、走行希望距離、探索モード（ターゲットを長距離客あるいは短距離客（ちょい乗り客）にするなど）、乗客の属性（女性客に乗ってほしいなど）を設定した場合には、設定された経路探索条件が、端末装置２からサーバ１０３へと送信され、経路探索部１３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、ユーザにより設定された経路探索条件に基づいて、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。

経路探索部１３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、経路ネットワーク情報データベース１３３ａを参照し、各道路（リンク）について、歩道の有無、車線の数、交差点分岐の有無、走りやすさ（道路交通状況、渋滞度、道幅、事故リスク）をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。また、本件発明者の知見によれば、鉄道駅やバス停から離れた地域はタクシー需要が比較的高いと推定できることから、経路探索部１３２ｃは、道路毎のタクシー需要を探索コストに反映させたうえで、各道路について、鉄道駅および／またはバス停からの距離をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。そのほか、周辺の鉄道駅やバス停における運行ダイヤやその行き先（目的地）を考慮してもよい。すなわち、ある地域について周辺の鉄道駅やバス停における次の便の発車時刻が現在時刻から所定時間以上先である場合は、現時点における当該地域のタクシー需要が比較的高いものと推定してもよい。

また、経路探索部１３２ｃは、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路として、特定スポット（たとえば、駅やホテルなどの大規模施設のタクシープール）における「待機」を組み込んだ経路を探索してもよい。この場合、経路探索部１３２ｃは、たとえば各タクシーの端末装置２から送信される位置情報に基づいて、特定スポットでのリアルタイムの客持ちタクシー台数を算出し、当該スポットでの客待ちタクシー台数が所定の閾値以下であれば、当該スポットでの「待機」を組み込んだ経路を探索し、当該スポットでの客待ちタクシー台数が所定の閾値を超えていれば、当該スポットでの「待機」を組み込むことなく「流し」の経路を探索するようになっていてもよい。

表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に出力させる。表示制御部１３２ｄは、需要推定部１３２ｂにより推定された道路毎のタクシー需要を地図上に重ねて端末表示部２５に表示させてもよい。具体的には、たとえば、表示制御部１３２ｄは、道路毎のタクシー需要を、図３に示すように、地図上の道路の近傍に数値で表示させてもよいし、図１７に示すように、地図上の道路を数値に応じて色分けすることにより表示させてもよい。

また、本件発明者の知見によれば、鉄道駅からもバス停からも離れた地域はタクシー需要が比較的高いと推定できることから、表示制御部１３２ｄは、鉄道駅から所定距離（たとえば徒歩１５分）以内の範囲および／またはバス停から所定距離（たとえば徒歩５分）以内の範囲を、公共交通手段からのアクセス圏として設定し、当該アクセス圏を地図上に色分けして端末表示部１２５に表示させてもよい。この場合、公共交通手段からのアクセス圏外である交通空白地域を可視化することができ、ユーザであるタクシードライバは、「流し」のルートを決める際の参考情報としてこれを利用することができる。

また、表示制御部１３２ｄは、図１７に示すように、経路探索部１３２ｃにより抽出された複数の経路のうちの少なくとも１つを、地図上に重ねて端末表示部２５に表示させてもよい。この場合、表示制御部１３２ｄは、各タクシーの端末装置２から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部２５に表示させる経路を割り振ってもよい。あるいは、タクシーの事業者が、各タクシーの端末装置２から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部２５に表示させる経路を割り振ってもよい。特定の経路に車両が集中することなく、複数の経路にまんべんなく車両が割り振られることにより、事業者単位での営業効率を最大化することができる。

また、表示制御部１３２ｄは、図１７に示すように、検索回数が比較的多く、高いタクシー需要が見込まれるスポットまたはエリア情報を、その検索回数および／または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部２５に表示させてもよい。図１７に示す例では、検索回数が比較的多いＡ駅について、その検索回数が、検索回数に応じた大きさのバブル（円）で表示されるとともに、平常時の検索回数との比較情報が文字で表示されている。また、検索回数が比較的多いＢ駅についても、その検索回数が、検索回数に応じた大きさのバブル（円）で表示されるとともに、平常時の検索回数との比較情報が文字で表示されている。

図示は省略するが、表示制御部１３２ｄは、地図情報データベース３３ｂを参照し、端末表示部２５に表示させる地図の範囲内に終電の終着駅（または終バスの終着バス停）が含まれている場合には、当該終着駅（または終着バス停）の位置情報や終着時刻に関する情報を、地図上に重ねて端末表示部２５に表示させてもよい。また、表示制御部１３２ｄは、端末表示部２５に表示させる地図の範囲内に準終電検索の途中駅（すなわち終電後にタクシーに乗り換える駅）が含まれている場合には、当該途中駅の位置情報や終着時刻に関する情報を、地図上に重ねて端末表示部２５に表示させてもよい。

また、表示制御部１３２ｄは、地図情報データベース３３ｂを参照し、終電（または終バス）後に閉店する店舗の閉店時間情報を、地図上に重ねて端末表示部２５に表示させてもよい。終電（または終バス）後に閉店する店舗の閉店時間情報を表示させる場合には、表示制御部１３２ｄは、所定のエリア毎に閉店時間が最も遅い店舗を特定し、エリア単位で店舗の閉店時間情報を端末表示部２５に表示させてもよい。

時間指定受付部１３２ｅは、ユーザが端末装置２の端末入力部２４を介して所定の時間を選択し、当該指定された時間の情報が端末装置２からサーバ１０３へと送信されると、当該時間の指定を受け付ける。ここで、ユーザは、たとえば端末表示部２５に表示されたスライドバー５１（図２５参照）を操作することにより、所定の時間を指定（ないし変更）してもよい。時間指定受付部１３２ｅが時間の指定を受け付けると、需要推定部１３２ｂは、出発時刻または到着時刻が指定された時間に対応する経路検索ログのみに基づいて、道路毎のタクシー需要を推定する。ここで、「指定された時間に対応する経路検索ログ」とは、「時間帯」が指定された場合は、出発時刻または到着時刻が当該指定された時間帯に入る経路探索ログを意味し、「時刻」が指定された場合は、出発時刻または到着時刻が当該指定された時刻を含む所定長さ（たとえば２時間）の時間帯に入る経路検索ログを意味する。

走行区域指定受付部１３２ｆは、ユーザが端末装置２の端末入力部２４を介して所定の走行区域を指定し、指定された走行区域の情報が端末装置２からサーバ１０３へと送信されると、当該走行区域の指定を受け付ける。走行区域指定受付部１３２ｆが走行区域の指定を受け付けると、経路探索部１３２ｃは、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。

具体的には、たとえば、図１９を参照し、経路探索部１３２ｃは、地図情報データベース１３３ｂを参照して、指定された走行区域に含まれる１または２以上のノードまたは道路（リンク）を仮想経由地Ｖ１、Ｖ２として設定するとともに、タクシーの現在位置を目的地Ｇとして設定したうえで、道路毎のタクシー需要を探索コストに反映させて、経路探索を行う。この場合、経路探索部１３２ｃは、仮想経由地Ｖ１、Ｖ２を走行区域内でランダムに設定してもよい。これにより、特定の巡回経路だけに車両が集中することを防ぐことができる。

目的地指定受付部１３２ｇは、ユーザが端末装置２の端末入力部２４を介して所定の目的地を指定し、指定された目的地の情報が端末装置２からサーバ３へと送信されると、当該目的地の指定を受け付ける。目的地指定受付部１３２ｇが目的地の指定を受け付けると、経路探索部１３２ｃは、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。この場合、経路探索部１３２ｃは、指定された目的地まで走行中のタクシーが当該目的地またはその近くに到達したときに、タクシー需要が予め定められた第１閾値より高い高需要スポットが、当該タクシーの近くにあるか否かを判定し、高需要スポットが近くにある場合には、指定された目的地を当該高需要スポットに変更し、当該高需要スポットまでの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索してもよい。

スコア算出部１３２ｈは、経路探索部１３２ｃにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する。スコア算出部１３２ｈは、経路のバリエーションが出るよう（複数の経路同士の走行ルートや方面が異なるよう）、複数の経路同士の走行ルートや方面が類似する場合には、当該複数の経路のスコアを類似の割合に応じて下げてもよい。スコア算出部１３２ｈにより経路毎のスコアが算出されると、表示制御部１３２ｄは、経路探索部１３２ｃにより抽出された複数の経路を、スコア算出部１３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させる（たとえば図２３参照）。図示は省略するが、表示制御部１３２ｄは、走行ルートの選択をしやすくするため、経路探索部１３２ｃにより抽出された複数の経路を地図上に表示の上、経路の概要を示す名称とともにスコアを表示（たとえば、「湾岸回りコース：９０点」など）してもよい。

一例として、スコア算出部１３２ｈは、経路探索部１３２ｃにより抽出された複数の経路の各々について、たとえば走行中のタクシーの位置情報をマッチングさせることにより、当該経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第２閾値を超えた場合には、当該経路のスコアを下げてもよい。別の一例として、スコア算出部１３２ｈは、各タクシーの端末装置２からサーバ１０３へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第２閾値を超えた場合には、当該経路のスコアを下げてもよい。更に別の一例として、スコア算出部１３２ｈは、経路の提示実績数に応じてスコアを下げてもよい。すなわち、スコア算出部１３２ｈは、経路の提示実績数が予め定められた第３閾値を超えた場合には（第３閾値を超える回数、当該経路が提示されたら）、当該経路のスコアを下げてもよい。これらにより、特定の経路だけに車両が集中することを防ぐことができる。

（動作の第１の態様）
次に、図１６および図１７を参照して、第２の実施形態に係る情報処理システム１０１の動作の第１の態様について説明する。図１６は、情報処理システム１０１の動作の第１の態様を示すフローチャートである。図１７は、情報処理システム１０１の動作の第１の態様において表示される画面の一例を示す図である。

図１６に示すように、まず、経路検索ログ取得部１３２ａは、経路検索ログデータベース１３３ｃを参照して、所定の地域（たとえば法令で定められた営業区域）内に出発地または目的地が含まれる経路検索ログを取得する（ステップＳ１１０）。

次に、需要推定部１３２ｂは、地図情報データベース１３３ｂを参照して、経路検索ログ取得部１３２ａにより取得された経路検索ログに含まれる出発地または目的地の位置情報を、地図上のスポットにマッチングさせる（ステップＳ１１１）。需要推定部３２ｂは、乗車実績取得部３２ａにより取得された乗車実績情報のうち、検索条件または検索結果にタクシーの利用を含む経路検索ログに含まれる出発地または目的地の位置情報のみを、地図上の道路にマッチングさせてもよい。

次に、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所定の時間を指定すると、指定された時間の情報は端末装置２からサーバ１０３へと送信され、時間指定受付部１３２ｅは、当該時間の指定を受け付ける（ステップＳ１１２）。

そして、需要推定部１３２ｂは、ステップＳ１１１におけるマッチング結果を参照して、出発時刻または到着時刻が指定された時間に対応するスポット毎の検索回数のみを集計し、集計したスポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定する（ステップＳ１１３）。需要推定部１３２ｂは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。また、ステップＳ１１１において、タクシーの利用ありの経路検索ログに含まれる出発地または目的地の位置情報のみを、地図上の道路にマッチングさせる場合には、需要推定部１３２ｂは、検索条件または検索結果にタクシーの利用を含む記経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。

ステップＳ１１１およびＳ１１３に関し、需要推定部１３２ｂは、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ（いわゆる事前経路検索ログ）のみに基づいて、道路毎のタクシー需要を推定してもよい。また、需要推定部１３２ｂは、終電検索（準終電検索を含む）または始発検索の経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。

次に、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所定の目的地を指定すると、指定された目的地の情報は端末装置２からサーバ１０３へと送信され、目的地指定受付部１３２ｇは、当該目的地の指定を受け付ける（ステップＳ１１４）。

そして、経路探索部１３２ｃは、需要推定部１３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ１１５）。なお、「道路毎のタクシー需要を探索コストに反映させ」るとは、従来の経路探索では、たとえば時間、金銭および走りやすさをコスト係数として道路毎のコストを計算していたのに対し、時間、金銭および走りやすさに加えて、タクシー需要もコスト係数に含めて道路毎のコストを計算することを意味する。

次に、表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部１３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１１６）。図１７に示すように、表示制御部１３２ｄは、経路探索部１３２ｃにより抽出された経路Ｒを、地図上に矢印で表示させてもよい。また、表示制御部１３２ｄは、端末装置２から取得される測位情報（タクシーの現在の位置情報）Ａを、地図上に重ねて表示させてもよい。

また、表示制御部１３２ｄは、需要推定部１３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部１２５に出力される地図上に重ねて表示させる（ステップＳ１１７）。図１７に示すように、表示制御部１３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザ（すなわちタクシードライバ）は、タクシー需要が高い道路を一目で直感的に把握できるようになる。

図１７に示すように、表示制御部１３２ｄは、検索回数が比較的多く、高いタクシー需要が見込まれるスポット（Ａ駅およびＢ駅）の情報を、その検索回数および／または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部２５に表示させてもよい。

ところで、発明が解決しようとする課題の欄でも言及したように、従来のタクシーの需要予測技術では、携帯端末の位置情報を利用してエリア毎のタクシー需要を予測するため、ユーザであるタクシードライバは、タクシー需要が高いエリアは分かるものの、そのエリア内で実際にどの道路を走行すれば高い営業効率が得られるのかまでは分からなかった。

これに対し、本実施の形態によれば、経路検索ログ取得部１３２ａが、経路検索アプリや経路検索Ｗｅｂサービスにより得られる経路検索ログを取得し、需要推定部１３２ｂが、経路検索ログに含まれる出発地または目的地の位置情報を地図上のスポットにマッチングさせ、スポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定し、経路探索部１３２ｃが、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索するため、タクシーの走行経路に関し、営業効率が高い経路を探索することが可能となる。これにより、ユーザであるタクシードライバは、実際にどの道路を走行すれば高い営業効率が得られるのかが分かるようになり、営業効率を高めることができる。

（動作の第２の態様）
第２の実施形態に係る情報処理システム１の動作の第２の態様について、図１８および図１９を参照して説明する。図１８は、第情報処理システム１０１の動作の第２の態様を示すフローチャートである。図１９は、情報処理システム１０１の動作の第２の態様において表示される画面の一例を示す図である。第２の態様において、需要推定部１３２ｂが道路毎のタクシー需要を推定する工程まで（ステップＳ１１０〜Ｓ１１３）は、上述した第１の態様と同様であり、説明を省略する。

図１８に示すように、第２の態様では、需要推定部１３２ｂが道路毎のタクシー需要を推定した後（ステップＳ１１３の後）、ユーザであるタクシードライバが、端末装置２の端末入力部２４を介して所望の走行区域（たとえば、得意とするエリア）を指定すると、指定された走行区域の情報は端末装置２からサーバ１０３へと送信され、走行区域指定受付部１３２ｆは、当該走行区域の指定を受け付ける（ステップＳ１２４）。

そして、経路探索部１３２ｃは、需要推定部１３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ１２５）。図１９に示す例では、経路探索部１３２ｃは、経路探索条件として、地図情報データベース３３ｂを参照して、指定された走行区域に含まれる複数（図示された例では２つ）のノードを仮想経由地Ｖ１、Ｖ２として設定するとともに、タクシーの現在位置を目的地Ｇとして設定したうえで、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索する。

次に、表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部１３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１２６）。図１９に示すように、表示制御部１３２ｄは、経路探索部１３２ｃにより抽出された経路Ｒを、地図上に矢印で表示させてもよい。また、表示制御部１３２ｄは、端末装置２から取得される測位情報（タクシーの現在の位置情報）Ａを、地図上に重ねて表示させてもよい。

また、表示制御部１３２ｄは、需要推定部１３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ２７）。図１９に示すように、表示制御部１３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。

図１９に示すように、表示制御部１３２ｄは、検索回数が比較的多く、高いタクシー需要が見込まれるスポット（Ａ駅およびＢ駅）の情報を、その検索回数および／または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部２５に表示させてもよい。

以上のような第２の態様によれば、上述した第１の態様と同様の作用効果が得られることに加えて、ユーザであるタクシードライバは、ある目的地までの経路（一方向の経路）の代わりに、指定された走行区域内で周遊（巡回）する経路を探索することができ、空車での走行時間の短縮を図ることができる。

（動作の第３の態様）
第２の実施形態に係る情報処理システム１０１の動作の第３の態様について、図２０および図２１を参照して説明する。第３の態様は、指定された目的地まで走行中のタクシーが、当該目的地またはその近くに到達したときに情報処理システム１０１により行われる処理（オートリルート処理）に関する。図２０は、情報処理システム１０１の動作の第３の態様を示すフローチャートである。図２１は、情報処理システム１０１の動作の第３の態様において表示される画面の一例を示す図である。

まず、図２０の上図を参照し、サーバ制御部１３２は、端末装置２から送信される測位情報に基づいて、指定された目的地Ｇまで走行中のタクシーの現在位置Ａが、当該目的地Ｇまたはその近くに到達したか否かを判定する。そして、走行中のタクシーの現在位置Ａが目的地Ｇまたはその近くに到達したと判定されると、サーバ制御部１３２は、予め定められた第１閾値より高いタクシー需要を有する高需要スポットＰが、当該タクシーの現在位置Ａの近くにあるか否かを判定する（ステップＳ１３１）。

そして、高需要スポットＰがタクシーの現在位置Ａの近くにあると判定された場合には（ステップＳ１３１：ＹＥＳ）、図２０の下図を参照し、指定された目的地Ｇを当該高需要スポットＰへと変更する（ステップＳ１３２）。

そして、経路探索部１３２ｃは、上述したステップＳ１１５と同様にして、需要推定部１３２ｂにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地Ｇ（すなわち高需要スポットＰ）までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する（ステップＳ１３３）。

次に、表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、経路探索部１３２ｃにより抽出された経路の少なくとも１つを、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１３４）。図２１の下図に示すように、表示制御部１３２ｄは、経路探索部１３２ｃにより抽出された経路Ｒ２を、地図上に矢印で表示させてもよい。

また、表示制御部１３２ｄは、需要推定部１３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１３５）。図２１に示すように、表示制御部１３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。

上述したステップＳ１３１〜Ｓ１３５は、走行中のタクシーの現在位置Ａが指定された目的地Ｇまたはその近くに到達するたびに繰り返されてもよい。

以上のような第３の態様によれば、目的地Ｇまたはその近くに到達するたびに新たな走行経路が提示されるため、ユーザであるタクシードライバは、端末入力部２４を操作して目的地を指定するためにタクシーをいちいち停車させる必要がなくなり、営業効率をさらに高めることができる。

（動作の第４の態様）
第２の実施形態に係る情報処理システム１０１の動作の第４の態様について、図２２および図２３を参照して説明する。図２２は、情報処理システム１０１の動作の第４の態様を示すフローチャートである。図２３は、情報処理システム１０１の動作の第４の態様において表示される画面の一例を示す図である。第４の態様において、経路探索部１３２ｃが道路単位当たりのタクシー需要が高い経路を優先的に探索する工程まで（ステップＳ１１０〜Ｓ１１５）は、上述した第１の態様と同様であり、説明を省略する。

図２２に示すように、第４の態様では、経路探索部１３２ｃが道路単位当たりのタクシー需要が高い経路を優先的に探索した後（ステップＳ１１５の後）、スコア算出部１３２ｈが、経路探索部１３２ｃにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する（ステップＳ１３３）。

次に、表示制御部１３２ｄは、図２３の上図に示すように、経路探索部１３２ｃにより抽出された複数の経路を、スコア算出部１３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させる（ステップＳ１３４）。

次に、ユーザであるタクシードライバが、端末表示部２５に表示された各経路のスコアを参照しながら、端末入力部２４を介して１つの経路を選択すると、選択された経路の情報が端末装置２からサーバ１０３へと送信され、サーバ制御部１３２は、経路の選択を受け付ける（ステップＳ１３５）。

そして、表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、ユーザにより選択された経路の情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１３６）。

次いで、スコア算出部１３２ｈは、経路探索部１３２ｃにより抽出された複数の経路の各々について、当該経路を走行するタクシーの数を推定する。具体的には、たとえば、スコア算出部１３２ｈは、各タクシーの端末装置２からサーバ１０３へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定する。あるいは、スコア算出部１３２ｈは、各タクシーの端末装置２からサーバ１０３へと送信される各タクシーの位置情報に基づいて、各経路を走行するタクシーの数を推定してもよい。図２３の中央図に示すように、スコア算出部１３２ｈ、推定された各経路を走行するタクシーの数を、スコア算出部１３２ｈにより算出された各経路のスコアとともに、端末装置２の端末表示部２５に表示させてもよい。そして、スコア算出部１３２ｈは、各経路を走行するタクシーの数が、予め定められた第２閾値（たとえば、１０台）を超えたか否かを判定する（ステップＳ１３７）。

各経路を走行するタクシーの数が第２閾値を超えた場合には（ステップＳ１３７：ＹＥＳ）、スコア算出部１３２ｈは、当該の経路のスコアを下げる（ステップＳ１３８）。図２３に示す例では、ルート１を走行するタクシーの数（＝１２台）が第２閾値（＝１０台）を超えたことから、スコア算出部１３２ｈは、ルート１のスコアを「９５」から「６５」へと下げている。これにより、ルート１の魅力が下がり、ルート１に車両がこれ以上集中することを防ぐことができる。

以上のような第４の態様によれば、ユーザであるタクシードライバが、端末表示部２５に表示された各経路のスコアを参照しながら、端末入力部２４を介して１つの経路を選択する際に、スコア算出部１３２ｈが、走行するタクシーの数が第２閾値を超えている経路についてはそのスコアを下げることで、当該経路の魅力を下げるため、ユーザであるタクシードライバは、走行するタクシーの数が第２閾値を超えている経路の選択を避けるようになる。これにより、各経路を走行するタクシーの数を自動的に分散させることが可能となり、事業者単位での営業効率を最大化することができる。

（動作の第５の態様）
第２の実施形態に係る情報処理システム１０１の動作の第５の態様について、図２４および図２５を参照して説明する。図２４は、情報処理システム１０１の動作の第５の態様を示すフローチャートである。図２５は、情報処理システム１０１の動作の第５の態様において表示される画面の一例を示す図である。第５の態様において、需要推定部１３２ｂが道路毎のタクシー需要を推定する工程まで（ステップＳ１１０〜Ｓ１１３）は、上述した第１の態様と同様であり、説明を省略する。

図２４に示すように、第５の態様では、需要推定部１３２ｂが道路毎のタクシー需要を推定した後（ステップＳ１１３の後）、表示制御部１３２ｄは、地図情報データベース１３３ｂを参照し、所定の地域（たとえば法令で定められた営業区域）の地図を、端末装置２の端末表示部２５に表示させるとともに、需要推定部１３２ｂにより推定された道路毎のタクシー需要情報を、端末表示部２５に出力される地図上に重ねて表示させる（ステップＳ１１７）。図２５に示すように、表示制御部１３２ｄは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。

また、表示制御部１３２ｄは、図２５に示すように、検索回数が比較的多く、高いタクシー需要が見込まれるスポット（Ａ駅およびＢ駅）の情報を、その検索回数および／または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部２５に表示させてもよい。

図２５に示すように、表示制御部１３２ｄは、所定の地域の地図に隣接して、時間帯を選択（ないし変更）するためのスライドバー５１を、端末表示部２５に表示させてもよい。

次に、ユーザであるタクシードライバが、端末入力部２４を介してスライドバー５１を操作して新たな時間を指定すると、指定された時間の情報は端末装置２からサーバ１０３へと送信される。時間指定受付部１３２ｅは、新たに指定された時間の情報が端末装置２からサーバ１０３へと送信されたか否かに応じて、時間の変更があるか否かを判定する（ステップＳ１１８）。

そして、時間の変更があると判定された場合には（ステップＳ１１８：ＹＥＳ）、時間指定受付部１３２ｅは、新たに指定された時間の指定を受け付け（ステップＳ１１２）、新たに指定された時間についてステップＳ１１３〜Ｓ１１７の処理を繰り返す。

以上のような第５の態様によれば、ユーザであるタクシードライバは、端末表示部２５に表示される道路毎のタクシー需要情報を、時間別に容易に切り替えて比較したり、道路毎のタクシー需要の時間変化を把握したりすることが可能となり、営業効率の高い経路の分析にこれを役立てることができる。

なお、上述した実施形態で説明した情報処理システム１の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ハードウェアで構成する場合には、情報処理システム１の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、情報処理システム１の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

さらに、一つまたは複数の情報処理装置によって情報処理システム１を機能させてもよい。複数の情報処理装置を用いる場合、情報処理装置のうちの１つをコンピュータとし、当該コンピュータが所定のプログラムを実行することにより情報処理システム１の少なくとも１つの手段として機能が実現されてもよい。

また、方法の発明においては、全ての工程（ステップ）をコンピュータによって自動制御で実現するようにしてもよい。また、各工程をコンピュータに実施させながら、工程間の進行制御を人の手によって実施するようにしてもよい。また、さらには、全工程のうちの少なくとも一部を人の手によって実施するようにしてもよい。

上記の記載に基づいて、当業者であれば、本発明の追加の効果や様々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１、１０１ 情報処理システム
２ 端末装置
２１ 端末通信部
２２ 端末制御部
２３ 端末記憶部
２４ 端末入力部
２５ 端末表示部
３、１０３ サーバ
３１、１３１ サーバ通信部
３２、１３２ サーバ制御部
３２ａ、１３２ａ 乗車実績取得部
３２ｂ、１３２ｂ 需要推定部
３２ｃ、１３２ｃ 経路探索部
３２ｄ、１３２ｄ 表示制御部
３２ｅ、１３２ｅ 時間帯選択受付部
３２ｆ、１３２ｆ 走行区域指定受付部
３２ｇ、１３２ｇ 目的地指定受付部
３２ｈ、１３２ｈ スコア算出部
３３、１３３ サーバ記憶部
３３ａ、１３３ａ 経路ネットワーク情報データベース
３３ｂ、１３２ｂ 地図情報データベース
３３ｃ 乗車実績情報データベース
１３３ｃ 経路検索ログデータベース
４ ネットワーク
５１ スライドバー

Claims (15)

1. タクシーの乗車実績情報を取得する乗車実績取得手段と、
   前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する需要推定手段と、
   前記道路毎のタクシー需要を探索コストに反映させ、タクシー需要が高い経路を優先的に探索する経路探索手段と、
   を備える情報処理システム。
2. 前記乗車実績情報は、流し／待ち／迎車のいずれのタクシーであるのかを識別する識別情報を含み、
   前記需要推定手段は、前記識別情報が「流し」の前記乗車実績情報のみに基づいて、道路毎のタクシー需要を推定する、請求項１に記載の情報処理システム。
3. 前記需要推定手段は、道路毎の単位距離当たりの乗車実績数に基づいて、前記道路毎のタクシー需要を推定する、請求項１または２に記載の情報処理システム。
4. 前記道路毎のタクシー需要を地図上に重ねて表示部に表示させる表示制御手段を更に備える、請求項１〜３のいずれかに記載の情報処理システム。
5. 時間の指定を受け付ける時間指定受付手段を更に備え、
   前記需要推定手段は、指定された時間の前記乗車実績情報のみに基づいて、前記道路毎のタクシー需要を推定する、請求項１〜４のいずれかに記載の情報処理システム。
6. 走行区域の指定を受け付ける営業区域指定受付手段を更に備え、
   前記経路探索手段は、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する、請求項１〜５のいずれかに記載の情報処理システム。
7. 目的地の指定を受け付ける目的地指定受付手段を更に備え、
   前記経路探索手段は、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する、請求項１〜５のいずれかに記載の情報処理システム。
8. 前記経路探索手段は、指定された目的地まで走行中のタクシーが当該目的地またはその近くに到達したときに、タクシー需要が第１閾値より高い高需要スポットが、当該タクシーの近くにあるか否かを判定し、高需要スポットが近くにある場合には、指定された目的地を当該高需要スポットに変更し、当該高需要スポットまでの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する、請求項７に記載の情報処理システム。
9. 前記経路探索手段により抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出するスコア算出手段をさらに備え、
   前記表示制御手段は、前記経路探索手段により抽出された複数の経路を、各経路のスコアとともに表示部に表示させる、請求項１〜８のいずれかに記載の情報処理システム。
10. 前記スコア算出手段は、前記経路探索手段により抽出された複数の経路の各々について、当該経路を走行するタクシーの数を推定し、推定したタクシーの数が第２閾値を超えた場合には、当該経路のスコアを下げる、請求項９に記載の情報処理システム。
11. タクシーの乗車実績情報を取得する乗車実績取得手段と、
    前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する需要推定手段と、
    前記道路毎のタクシー需要情報を地図上に重ねて表示部に表示させる表示制御手段と、
    を備える情報処理システム。
12. コンピュータを、
    タクシーの乗車実績情報を取得する乗車実績取得手段、
    前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する需要推定手段、
    前記道路毎のタクシー需要を探索コストに反映させ、タクシー需要が高い経路を優先的に探索する経路探索手段、
    として機能させる情報処理プログラム。
13. コンピュータを、
    タクシーの乗車実績情報を取得する乗車実績取得手段、
    前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する需要推定手段、
    前記道路毎のタクシー需要情報を地図上に重ねて表示部に表示させる表示制御手段、
    として機能させる情報処理プログラム。
14. タクシーの乗車実績情報を取得するステップと、
    前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定するステップと、
    前記道路毎のタクシー需要を探索コストに反映させ、タクシー需要が高い経路を優先的に探索するステップと、
    を備える情報処理方法。
15. タクシーの乗車実績情報を取得するステップと、
    前記乗車実績情報に含まれる乗車位置を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定するステップと、
    前記道路毎のタクシー需要情報を地図上に重ねて表示部に表示させるステップと、
    を備える情報処理方法。