JP6677264B2 - 需要予測装置、回送計画生成装置、ユーザモデル生成装置、および方法 - Google Patents

Description

本発明は、オンデマンド型のモビリティサービスにおける需要予測に関し、特に、ユーザの検索履歴に基づく需要予測に関連する。本発明は、また、需要予測に基づく回送計画生成、および需要予測に用いるユーザモデル生成にも関連する。

近年、オンデマンド型のモビリティサービスが普及している。オンデマンド型モビリティサービスは、ユーザからの要求に応じて運用を変更可能な移動手段を提供するサービスである。一例として、ワンウェイ型（乗り捨て型）のカーシェアシステムが挙げられる。このようなカーシェアシステムでは、ユーザの需要に応じてシェアカーの配置を変更することができ、それによりユーザの要求に最大限応えることが期待できる。

このようなオンデマンド型モビリティサービスにおいては、ユーザの移動需要を適切に予測することが求められる。特許文献１は、検索対象時が過去である移動に関連する検索実績と、当該移動に関連する過去の移動実績と、検索対象時が未来である移動に関連する検索実績とに基づいて、当該移動に関連する未来の移動実績を予測することを開示する。具体的には、地点Ａから地点Ｂまでの将来時点の移動に関する検索の数がどの程度行われたかによって、将来での地点Ａから地点Ｂまでに移動需要を予測する。すなわち、特許文献１は、検索と実際の移動の間に相関があることに着目して、将来についても検索に基づいて将来の需要を予測することを開示する。

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

特許文献１の手法は、検索件数に応じて需要を予測する手法であるので、それぞれの移動についての全体的な需要を予測するものといえる。しかしながら、オンデマンド型モビリティサービスによっては、需要総量が大きくなく、かつ利用のばらつきが大きいものも存在し、そのようなサービスに対しては特許文献１のような全体的な需要を予測する手法は精度が高くない。

上記の課題を考慮して、本発明は、オンデマンド型モビリティサービスにおける将来の需要を精度良く求めることを目的とする。また、本発明は、このような需要予測に基づいてモビリティサービスにおける移動資源を最適に配置すること、およびこのような需要予測のために用いられるユーザモデルを生成することも目的とする。

本発明の第１の態様は、モビリティサービスにおける移動の需要を予測する需要予測装置である。本態様に係る需要予測装置は、ユーザごとの検索履歴に基づいて、ユーザごとの移動需要を予測する。このようにユーザごとの需要を予測することで、全体としての利用傾向がばらつく場合であっても、予測精度を向上できる。

本態様に係る需要予測装置は、履歴取得手段と、第１推定手段と、第２推定手段と、需要予測手段とを備える。

履歴取得手段は、ユーザによって行われた検索の履歴を取得する。検索の履歴には、出発地と目的地とを含む検索条件と当該検索が行われた時刻が含まれる。

第１推定手段は、検索履歴から、前記ユーザが所望する移動の出発エリアまたは目的エリアの少なくとも一方を推定する。出発エリアは、出発地と同一の地理的範囲を指すものであってもよいし、出発地を含む出発地よりも広い地理的範囲を指すものであってもよい。目的エリアも同様に、目的地と同一の地理的範囲であってもよいし、目的地よりも広い地理的範囲であってもよい。たとえば、第１推定手段は、時間的に一連の検索において、指定された出発地および目的地の重み付け回数に基づいて、ユーザが所望する移動の出発エリアまたは目的エリアを推定してもよい。これは、一連の検索において先に行われた検索ほどユーザの要求に沿ったものであると考えられるためである。

第２推定手段は、検索履歴とユーザモデルとに基づいて、当該ユーザが所望する移動の開始時刻を推定する。ここで、ユーザモデルは、検索を行った時刻と、実際の移動の開始時刻との差を定義するものである。なお、ユーザモデルは、検索のどの程度後に利用を開始するかを明確に定義したものである必要はなく、検索後の経過時間ごとの利用開始確率を定義したものであってもよい。ユーザモデルは、ユーザごとに定義されていてもよいし、ユーザグループごとに定義されていてもよい。

たとえば、第２推定手段は、ユーザごとに定義されたユーザモデルを用いて上記推定を行ってもよい。この場合、本態様に係る需要予測装置は、複数のユーザモデルをユーザと関連付けて記憶する記憶手段と、ユーザに関連付けられたユーザモデルを選択するユーザモデル選択手段とをさらに備えてもよい。第２推定手段は、ユーザモデル選択手段が選択したユーザモデルを用いて、ユーザが所望する移動の開始時刻を推定する。

あるいは、第２推定手段は、ユーザグループごとに定義されたユーザモデルを用いて上記推定を行ってもよい。この場合、本態様に係る需要予測装置は、複数のユーザモデルをユーザグループと関連付けて記憶する記憶手段と、ユーザの属性と検索履歴と利用実績の少なくともいずれかに基づいて、ユーザに該当するユーザグループを決定し、当該ユーザグループに関連付けられたユーザモデルを選択するユーザモデル選択手段とをさらに備えてもよい。ユーザグループの決定は、あらかじめ定められた分類基準にしたがって行えばよい。第２推定手段は、ユーザモデル選択手段が選択したユーザモデルを用いて、ユーザが所望する移動の開始時刻を推定する。

さらに、第２推定手段は、ユーザの利用頻度が閾値未満であれば所定のユーザモデル（たとえば、デフォルトのユーザモデル）を選択してもよい。さらに、第２推定手段は、検索履歴と利用実績以外の情報、たとえば、検索時または利用時の気象条件、出発エリアと目的エリアの組み合わせ、検索実行の時間（時間帯、曜日など）なども考慮して、ユーザに該当するユーザモデルを選択してもよい。

需要予測手段は、第２推定手段が推定した移動開始時刻に、第１推定手段が推定した出発エリアまたは目的エリアによって規定される移動を、前記ユーザが行うと予測する。需要予測手段は、予測結果を他のモジュールに対して送信したり、予測結果を画面に出力したりする。

このように、本態様に係る需要予測装置は、ユーザによって行われた検索に基づいて、そのユーザの移動需要を予測する。このように、ユーザ単位で需要の予測が行えるので、精度の高い需要予測が可能となる。

本態様に係る需要予測装置は、複数の検索履歴と利用実績とを取得して、記憶手段に記
憶された複数のユーザモデルの少なくともいずれかを更新する更新手段を備えてもよい。このように新しい情報に基づいてユーザモデルを更新することで、より精度の高い需要予測が行えるようになる。

本発明の第２の態様は、上述の需要予測装置と、前記需要予測装置によって予測された需要とモビリティサービスにおける移動資源の配置および現在の回送計画に基づいて、前記移動資源の配置換えを行うための回送計画を作成する計画生成手段をさらに備える。回送計画は、移動資源を移動させる判断基準となるものであればどのようなものであっても構わない。たとえば、回送計画は、具体的にいつ・どこから・どこに移動資源を移動させることを示す指示であってもよいし、特定の条件を満たすときにどこからどこに移動資源を移動させるかというルールであってもよい。回送計画は、たとえば、線形計画法やシミュレーションなどによって最適化計算を行うことで実施できる。

たとえば、本態様に係る回送計画生成装置は、前記需要予測装置によって予測された需要と、前記モビリティサービスにおける移動資源の配置および現在の回送計画に基づいて、１つまたは複数の回送リクエストを生成してもよい。そして、本態様に係る回送計画生成装置は、（１）前記１つまたは複数の回送リクエストのうち、他のリクエストと競合せずに実行可能な回送リクエストを、新しい回送計画に追加し、（２）前記１つまたは複数の回送リクエストのうち、他のリクエストと競合する回送リクエストについては、所定の基準に基づいて最適な回送リクエストを選択して、前記新しい回送計画に追加する、ことにより回送計画を生成してもよい。

本発明の第３の態様は、モビリティサービスの需要予測を行うためのユーザモデルを生成するユーザモデル生成装置である。本態様に係るユーザモデル生成装置は、履歴取得手段と、実績取得手段と、生成手段とを備える。

履歴取得手段は、ユーザによって行われたモビリティサービスにおける検索の履歴を取得する。検索の履歴には、検索が行われた時刻が含まれる。実績取得手段は、ユーザがモビリティサービスにおける利用実績を取得する。利用実績には、ユーザが移動資源の利用を開始した時刻が含まれる。履歴取得手段は、複数のユーザについての検索履歴および利用実績を取得してもよい。

ユーザモデル生成手段は、上述の検索履歴と利用実績に基づいて、ユーザが検索を行ってから利用を開始するまでの時間を定義したユーザモデルを生成する。このユーザモデルの生成は、たとえば、機械学習の手法により行える。また、ユーザモデルの生成には、検索履歴と利用実績以外の情報、たとえば、気象状況、出発エリアと目的エリアの組み合わせ、検索実行の時間帯なども用いてもよい。

ユーザモデル生成手段は、ユーザ単位でユーザモデルを生成してもよいし、複数のユーザからなるユーザグループ単位でユーザモデルを生成してもよい。また、ユーザモデル生成手段は、一人のユーザまたは一つのユーザグループに対して、複数のユーザモデルを生成してもよい。

ユーザ単位でユーザモデルを生成する場合には、本態様に係るユーザモデル生成手段は、ユーザごとのユーザモデルを、当該ユーザの検索履歴と利用実績に基づいて生成すればよい。一方、ユーザグループ単位でユーザモデルを生成する場合には、本態様に係るユーザモデル生成手段は次のようにしてユーザモデルを生成する。すなわち、ユーザモデル生成手段は、ユーザごとの暫定ユーザモデルを、当該ユーザの検索履歴と利用実績に基づいて生成し、暫定ユーザモデルが類似するユーザをユーザグループとして集約し、ユーザグループごとのユーザモデルを生成する。この際、ユーザモデル生成手段は、ユーザグルー
プの分類基準も合わせて生成する。

また、ユーザモデル生成手段は、利用頻度が閾値未満の複数のユーザの検索履歴と利用実績に基づいて１つのユーザモデルを生成してもよい。このようにして生成されるユーザモデルは、利用頻度が少ないユーザ向けのユーザモデルとして利用できる。また、ユーザモデル生成手段は、同じユーザであっても、検索時または利用時の気象条件、出発エリアと目的エリアの組み合わせ、検索実行の時間（時間帯、曜日など）などによって利用態様が異なる場合には、これらの条件ごとにユーザモデルを生成してもよい。

本態様に係るユーザモデル生成装置は、ユーザモデルを生成する際に用いられていない検索履歴と利用実績、すなわち新しい検索履歴と利用実績に基づいて、ユーザモデルを更新する更新手段をさらに備えてもよい。たとえば、ユーザモデル生成後に行われた検索と利用に基づいて、既存のユーザモデルを更新することができる。

なお、本発明は、上記手段の少なくとも一部を備える需要予測装置、回送計画生成装置、あるいはユーザモデル生成装置として捉えることができる。また、本発明は、上記需要予測装置が行う需要予測方法、回送計画生成装置が行う回送計画生成方法、あるいはユーザモデル生成装置が行うユーザモデル生成方法として捉えることもできる。また、本発明は、これらの方法をコンピュータに実行させるためのコンピュータプログラム、あるいはこのコンピュータプログラムを非一時的に記憶したコンピュータ可読記憶媒体として捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。

本発明によれば、オンデマンド型モビリティサービスにおける将来の需要を精度良く求めることができる。また、本発明によれば、このような需要予測に基づいてモビリティサービスにおける移動資源を最適に配置することができる。また、本発明によれば、需要予測のために用いられるユーザモデルを生成することができる。

図１は、実施形態に係る回送計画生成装置の構成を示す図である。 図２は、検索履歴データの例を示す図である。 図３は、利用実績データの例を示す図である。 図４は、ユーザモデル生成処理の流れを示すフローチャートである。 図５は、生成されるユーザモデルの例を示す図である。 図６は、需要予測処理の流れを示すフローチャートである。 図７（Ａ），７（Ｂ）は、検索履歴データの例と、それに基づく移動の出発地および目的地の予測を説明する図である。 図８は、回送計画生成処理の流れを示すフローチャートである。 図９は、回送計画生成処理のうちの回送計画修正処理の流れを示すフローチャートである。 図１０は、ユーザモデル生成処理の別の例を示すフローチャートである。 図１１（Ａ），１１（Ｂ）は、オンデマンド型モビリティサービスにおける問題点を説明する図である。

（第１の実施形態）
以下、本発明の第１の実施形態について説明する。第１の実施形態は、カーシェアリングシステムにおける回送計画生成サーバである。本サーバは、カーシェアリングシステムにおける需要予測機能、需要予測に基づく回送計画生成機能、および需要予測のためのユ
ーザモデルの生成・更新機能を備える。

［カーシェアリングシステム］
まず、本実施形態において想定するカーシェアリングシステムについて簡単に説明する。本実施形態におけるカーシェアリングシステムは、利用時に予約が必要なワンウェイ型（乗り捨て型）のカーシェアリングシステムである。ワンウェイ型であるので、車両（シェアカー）を借りるステーション（出発地ステーション）と、車両を返却するステーション（目的地ステーション）は異なっていてよい。

予約は、出発地ステーションに利用可能な車両が存在し、かつ、目的地ステーションに空きスポット（駐車枠）が存在する場合に可能とする。本実施形態においては、予約された車両やスポットは、その予約に係る利用が終了するまで他のユーザに貸し出さないものとする。

このような予約体系を想定しているため、本実施形態におけるカーシェアリングシステムでは、予約の受付開始が、利用時間の所定時間前以降（たとえば、３０分前以降、１時間前以降など）に限定される。予約に伴う他のユーザの利用機会損失を避けるためである。

このようなカーシェアリングシステムにおいては、ユーザは予約可能時間より前に検索を行って、出発地ステーションに利用可能車両が存在するか、および目的地ステーションに空きスポットが存在するかを、確認することが考えられる。その時点では予約可能でなくても予約ができそうであればシェアカーを使った移動が可能であると判断できるためである。

このようなカーシェアリングシステムにおいては、次のような問題が存在する。たとえば、ユーザが、ステーションＡからステーションＢに移動したいと考えており、予約開始前に検索を行ったところ図１１（Ａ）に示すように、ステーションＡの空き車両およびステーションＢの空きスポットが十分にあったとする。そうすると、ユーザは、シェアカーを使って移動ができるものと期待する。しかしながら、予約可能な時点あるいは移動したい時点においては図１１（Ｂ）に示すように、ステーションＡに空き車両がなかったり、ステーションＢに空きスポットがなかったりすることが原因で、ユーザはステーションＡからステーションＢへの移動を行えないという事情が発生しうる。これは、ユーザにとって不便であり、また、カーシェアリングシステムの運用者にとっては機会損失を招く。

上述のような問題を回避するためには、ステーションＡからステーションＢへ移動したいという上記ユーザの需要を把握し、ステーションＡにシェアカーを補充したり、ステーションＢからシェアカーを除いて空きスポットを増やしたりといった回送を適切に行う必要がある。

一般に、需要予測は過去の傾向にしたがって行われることが多い（特許文献１）。需要総量が大きいサービスでは、需要の変動・ばらつきが少なく、比較的精度のよい予測が行えるが、需要総量が少なく変動が大きい、すなわちランダム性の高いオンデマンドサービスでは、過去傾向からはそれほど高い精度の予測は行えない。

本発明者は、上述したカーシェアリングシステムでは予約可能前からユーザが検索を行っていることに着目し、ユーザの検索行動に基づいて将来の需要予測が行えることを見出した。たとえば、上述の図１１（Ａ）、図１１（Ｂ）の例では、ユーザがステーションＡからステーションＢへの移動に関する検索を最初に（予約可能時間よりも前に）行った時点で、この移動が行われる可能性が高いと管理サーバで判断し、適切な回送計画を立てる
ことで機会損失が生じる可能性を防げる。

［システム構成］
以下、図面を参照しながら本実施形態におけるカーシェアリングシステムの回送計画生成サーバ１００について説明する。なお、本実施形態におけるカーシェアリングシステムでは、利用開始の３０分前から予約が可能であるものとして説明する。また、カーシェアリングシステムの運用に当たっては、回送計画生成サーバ１００以外に予約管理サーバが必要となる。予約管理サーバは、ユーザからの検索に応じて空き状況の検索結果を提示したり、ユーザからの予約要求を処理したりするサーバであり、公知であるため本開示での詳細な説明は省略する。

図１は、サーバ１００の機能ブロック図である。サーバ１００は、ＣＰＵなどのプロセッサと、アプリケーションやＯＳのプログラムを格納したメモリとを有し、プロセッサがプログラムを実行することで、以下で説明するような機能を提供する。すなわち、サーバ１００は、ユーザモデル生成部１０２、ユーザモデル記憶部１０４、需要予測部１０６、回送リクエスト生成部１０８、回送計画生成部１１０、回送計画実行部１１２の各機能を提供する。

なお、サーバ１００は、複数のプロセッサを有してもよい。また、サーバ１００の機能は、複数台のコンピュータが連携することで提供されてもよい。また、上述した機能の一部または全部は、ＡＳＩＣやＦＰＧＡなどのハードウェア回路によって提供されても構わない。

以下、サーバ１００が備える各機能について説明する。なお、サーバ１００の機能は、ユーザモデル生成、需要予測、回送計画生成の３つに大別できるので、それぞれについて説明する。

［ユーザモデル生成機能］
ユーザモデル生成部１０２は、検索履歴データ１２０および利用実績データ１２２に基づいて、ユーザモデルを生成する。ここで、ユーザモデルは、ユーザが検索を行ったタイミングと、実際に移動を開始したいタイミングとの差を関連付けたモデルである。たとえば、あるユーザは、予約可能開始タイミングよりもかなり前の時点（たとえば、２時間前）から、空き状況を確認するための検索を断続的に行い、予約可能となった時点で予約を行うという傾向があるとする。そうすると、このユーザに関しては、最初の検索から２時間後に移動の需要があると判断できる。実際の検索傾向はユーザによって種々様々であるが、利用頻度がある程度以上あれば、ユーザがどのような検索を行うかを判断でき、したがって、検索行動から移動開始時刻を推定するためのユーザモデルを生成可能である。

ユーザモデル生成部１０２は、予約管理サーバ（不図示）から検索履歴データ１２０と利用実績データ１２２を取得して、これに基づいてユーザモデルを生成する。

検索履歴データ１２０は、ユーザが予約管理サーバに対して過去に行った検索に関する、検索時刻、出発地、目的地、その結果（空きの有無）、予約実行／未実行を含む。上述のように、予約管理サーバに対する検索における検索条件として出発地と目的地が含まれ予約管理サーバで把握可能である。検索が行われた時刻や検索結果および予約の実行／未実行も同様に予約管理サーバで把握可能である。

図２は、ある一人のユーザについて検索履歴データの一部を例示したものである。レコード２０１は、１月１日１５時００分に、ステーションＡを出発地としステーションＢを目的地として検索が行われ、空きありを示す検索結果が得られたことを意味する。最後の
「予約」の欄は、「○」は予約可能でありかつ予約が実行されたことを意味し、「×」は予約が可能であるが実行されなかったことを意味し、「−」は予約が不可能（空きなし）であることを意味する。一行目の例では、予約可能であったが予約が実行されておらず、予約可能時間前の検索であることが推定できる。

レコード２０２は、１月１日１５時３０分に、ステーションＡを出発地としステーションＢを目的地とした検索が再び行われたことを示す。ここでは、空きありを示す検索結果が得られ、実際に予約が行われている意味する。

レコード２０３は、ステーションＢからステーションＡへの移動に関する検索が行われ、空きなしの検索結果が得られたことを示す。レコード２０４は、その直後に、ステーションＢからステーションＤへの移動に関する検索が行われ、空きありの検索結果が得られたが予約は行われなかったことを示す。レコード２０５および２０６は、レコード２０３および２０４と同様の検索が３０分後に行われたことを示し、得られた検索結果および予約実行の有無も同様である。レコード２０７および２０８は、さらに１５分後に同様の検索が行われたことを示し、検索結果はこれまでと同様であるが、ユーザはステーションＢからステーションＤへの移動の予約を行っている。レコード２０３〜２０８から、このユーザはステーションＢからステーションＡへの移動が第一希望であったが、その代替としてステーションＤへの移動を行ったことが読み取れる。

レコード２０９およびレコード２１０は、レコード２０１および２０２と同様である。

利用実績データ１２２は、シェアカーの利用に関する実績（履歴）を表すデータであり、利用開始時刻、出発地、目的地、予約時刻が含まれる。利用実績データ１２２は、予約管理サーバに対する予約の内容から生成してもよいし、実際の貸出および返却を管理する管理サーバから得られる情報を元に生成してもよい。なお、利用実績データ１２２は、上記以外の情報を含んでいてもよく、たとえば、車両の返却時刻の情報が含まれていてもよい。

図３は、ある一人のユーザについて利用実績データの一部を例示したものである。図３に示す利用実績データは、図２に示す検索履歴データに対応するデータである。この例では、ステーションＡからステーションＢへの移動（レコード３０１，３０３）に関しては、予約可能となった時刻（利用開始の３０分前）に予約が行われており、ステーションＢからステーションＤへの移動（レコード３０２）に関しては、予約可能時刻以降に予約が行われていることが読み取れる。

なお、図２および図３に示した検索履歴データ１２０および利用実績データ１２２のいずれも一人のユーザに関するものであり、しかもその一部であることに留意されたい。実際には、多数のユーザについての多数の検索履歴および利用実績が存在する。

図４を参照して、ユーザモデル生成部１０２におけるユーザモデル生成処理について説明する。

まず、ステップＳ４０２において、ユーザモデル生成部１０２は、検索履歴データ１２０および利用実績データ１２２を取得する。ここで取得する検索履歴データ１２０および利用実績データ１２２は、既に利用が確定している検索および予約に関する履歴データのみで構わない。すなわち、ユーザモデル生成処理においては、必ずしも最新の履歴データは必要ではない。

ループＬ１の処理は、それぞれのユーザについて実行される。ステップＳ４０４におい
て、ユーザモデル生成部１０２は、対象ユーザの利用頻度が閾値以上であるか否かを判定する。この閾値は、精度のよいユーザモデルを生成できると判断できる利用頻度としてあらかじめ設定された値（利用頻度）とすることが好適である。利用頻度が閾値以上である場合（Ｓ４０４−ＹＥＳ）は、処理はステップＳ４０６に進み、利用頻度が閾値未満の場合（Ｓ４０４−ＮＯ）は、処理はステップＳ４０８に進む。

ステップＳ４０６では、ユーザモデル生成部１０２は、検索履歴データ１２０と利用実績データ１２２に基づいてユーザモデルを生成する。ユーザモデルは、ユーザが検索を行ったタイミングと、実際の移動開始時刻とを対応づけたモデルである。たとえば、あるユーザモデルは、利用開始１時間前から検索を開始し、予約可能時刻に再度検索および予約をするユーザを表すモデルである。他のモデルは、利用開始２時間前から検索を開始し、予約可能時刻に再度検索および予約をするユーザを表すモデルである。別のモデルは、予約可能時刻以降に検索および予約するユーザを表すモデルである。さらに別のモデルは、利用開始の直前のみに検索および予約するユーザを表すモデルである。また、検索行動が必ずしも予約（利用）に結びつくわけではないことを想定して、ユーザモデルは、検索行動のうちのどの程度の割合が予約に結びつくかを表してもよい。

ユーザモデル生成部１０２、対象ユーザに関する検索履歴データ１２０および利用実績データ１２２に統計処理を施して、当該対象ユーザのユーザモデルを決定できる。あるいは、ユーザモデル生成部１０２は、対象ユーザに関する検索履歴データ１２０および利用実績データ１２２に基づく機械学習を行って、当該対象ユーザのユーザモデルを決定できる。

なお、ユーザモデル生成部１０２は、１ユーザに対して１つのユーザモデルを対応づける必要はなく、１ユーザに対して複数のユーザモデルを対応づけてもよい。たとえば、図５に示すように、ユーザごとに、複数のユーザモデルのそれぞれに当てはまる確率を決定してもよい。図５の例では、ユーザαは、９０％の確率でユーザモデル１にしたがって行動し、１０％の確率でユーザモデル２にしたがって行動するように決定されている（レコード５０１）。同様に、ユーザβは、それぞれ１０％、７０％、２０％の確率で、ユーザモデル１、２、３にしたがって行動し、ユーザγは必ずユーザモデル３にしたがって行動するように決定されている（レコード５０２，５０３）。

ステップＳ４０８は、ユーザの利用頻度が閾値未満の場合に行われる処理である。ステップＳ４０８において、ユーザモデル生成部１０２は、対象ユーザを「その他」ユーザに分類し、このユーザ単独の検索履歴および利用実績に基づくユーザモデルの生成は行わない。

ステップＳ４０４〜Ｓ４０８からなるループＬ１の処理は、全てのユーザを対象として行われる。ループＬ１の終了後、利用頻度が閾値以上のユーザについては、ユーザモデル（図５参照）が生成される。

ステップＳ４１０において、ユーザモデル生成部１０２は、利用頻度が閾値未満である「その他」ユーザの検索履歴データ１２０および利用実績データ１２２に基づいて、ユーザモデルを生成する。ユーザモデルの生成処理自体は、ステップＳ４０６と同様であるので繰り返しの説明は省略する。ここで生成されたユーザモデルは、十分なデータがないユーザにも適用可能なユーザモデル（デフォルトのユーザモデル）である。このような観点から、ユーザモデル生成部１０２は、ステップＳ４１０において、利用頻度が閾値以上のユーザの履歴情報の一部または全部も考慮して「その他」ユーザ向けのユーザモデルを生成しても構わない。

以上の処理により、ユーザモデル生成部１０２によるユーザモデル生成処理が終了する。ユーザモデル生成部１０２は、生成したユーザモデルをユーザと関連付けてユーザモデル記憶部１０４に格納する。

［需要予測機能］
需要予測部１０６は、カーシェアリングシステムにおける将来の需要を予測する。本実施形態での予測には、移動の出発地ステーションまたは目的地ステーションの少なくとも一方と、移動の開始時刻とが含まれる。

図６は、需要予測部１０６による需要予測処理の流れを示すフローチャートである。以下、図６のフローチャートにしたがって需要予測部１０６による需要予測処理を説明する。

まず、ステップＳ６０２において、需要予測部１０６は、検索履歴データ１２０を取得する。ここで取得する検索履歴データ１２０は、利用が確定していない検索に関する履歴データのみで構わない。すなわち、需要予測処理においては、直近所定時間以内の検索履歴データのみを利用すればよい。

ループＬ２の処理は、それぞれのユーザについて実行される。ステップＳ６０４において、需要予測部１０６は、対象ユーザの検索履歴データ１２０から、対象ユーザが所望する移動の出発地および目的地を推定する。ステップＳ６０４の処理を実行する需要予測部１０６が本発明の第１推定手段に相当する。

対象ユーザが、たとえば、図７（Ａ）に示すような検索を行っているものとする。具体的には、このユーザは、１５時００分の時点でステーションＡからステーションＢへの移動を検索し、空き状況があるという結果を得ているが予約をせず、また、直後にはそれ以上の検索を行っていない。少し時間が経過した１５時３０分の時点で、このユーザは、ステーションＡからステーションＢへの移動を再度検索し、空きがないという結果を受けて、直後にステーションＡからステーションＣへの検索をしている。この移動にも空きがないという結果を受けて、さらにステーションＡからステーションＤへの移動を検索し、空きがあるという検索結果を得ているものの予約をしていない。

ここで、ステーションＡ〜Ｄの位置関係は図７（Ｂ）に示す通りであるとする。これら複数の検索条件における出発地がステーションＡとなっていることから、ユーザが所望する移動の出発地はステーションＡであると推定できる。また、ステーションＢへの移動に空きがある１５時００分の時点でそれ以上検索をしていないこと、および、ステーションＢへの移動に空きがない１５時３０分の時点で、ステーションＢに近いステーションＣ，Ｄを目的地として検索をしていることから、このユーザが所望する移動の目的地はステーションＢであると推定できる。したがって、この例では、ユーザはステーションＡからステーションＢへの移動を所望していると推定できる。

このような出発地および目的地の推定は、次のような手順により行うことができる。単純な手法は、検索履歴データ１２０において指定された出発地および目的地の回数に基づいて推定する手法である。図７（Ａ）の例では、出発地としてステーションＡが最も多い回数（４回）指定されていることからステーションＡが出発地として推定され、目的地としてステーションＢが最も多い回数（２回）指定されていることからステーションＢが目的地として推定できる。

別の手法は、検索履歴データ１２０において指定された出発地および目的地の重み付き回数に基づいて推定する手法であり、時間的に一連する検索において指定された出発地お
よび目的地において検索時間が前であるほど大きい重み付回数を与えるという手法である。需要予測部１０６は、まず、複数の検索を、時間的に一連する検索グループに分類する。この分類は、たとえば、検索の間隔が所定時間以内の複数の検索を１つのグループに分類することで行ってもよいし、クラスタリングの手法を用いて行ってもよい。そして、需要予測部１０６は、検索グループ内で検索時刻が先であるほど大きな重みを与えた重み付け回数を決定する。図７（Ａ）の例では、１５時００分の１回の検索と、１５時３０分から１５時３２分の３回の検索がそれぞれ１つの検索グループとして決定される。目的地をステーションＢとする検索は検索グループ内での最初の検索であることから、重み付き回数が、たとえば、１回とカウントされる。グループ内での２番目以降の検索に対しては、重み付回数が、たとえば、0.9回, 0.8回, 0.7回, ・・・とカウントされる。そして、需
要予測部１０６は、重み付回数の最も大きな出発地および目的地を、ユーザが所望する出発地および目的地として決定できる。

なお、出発地および目的地はステーション単位で決定する必要はなく、より広い領域として決定してもよい。たとえば、図７の例では、目的エリアは、ステーションＢおよびステーションＣを含むようなエリアとして決定しても構わない。また、ここでは出発地と目的地の両方を推定しているが、出発地と目的地のいずれか一方のみを推定するようにしても構わない。

ステップＳ６０６において、需要予測部１０６は、対象ユーザのカーシェアリングシステムの利用頻度が閾値以上であるか否かを判定する。この閾値は、ユーザモデル生成処理（図４のステップＳ４０４）における閾値と同じであってもよいし、異なっていてもよい。なお、ユーザの利用頻度を判断するためには、比較的長い期間の利用実績データ１２２が必要となる。もっとも、ステップＳ６０６の判定は、利用実績データ１２２に基づいて行う必要はなく、あらかじめ算出された利用頻度情報を含む会員情報を取得して、この会員情報に基づいて判定を行っても構わない。対象ユーザの利用頻度が閾値以上であれば（Ｓ６０６−ＹＥＳ）、処理はステップＳ６０８に進み、そうでなければ処理はステップＳ６１０に進む。

ステップＳ６０８では、需要予測部１０６は、対象ユーザに対応するユーザモデルをユーザモデル記憶部１０４から取得する。一方、ステップＳ６１０では、需要予測部１０６は、デフォルトユーザ用のユーザモデル（図４のステップＳ４１０で生成されたユーザモデル）をユーザモデル記憶部１０４から取得する。なお、ステップＳ６０６〜Ｓ６１０の処理は、ユーザに対応するユーザモデルがユーザモデル記憶部１０４に存在するか判定し、存在する場合には当該ユーザモデルを取得し、存在しなければデフォルト用のユーザモデルを取得する、という処理としても構わない。

ステップＳ６１２において、需要予測部１０６は、対象ユーザの検索履歴データ１２０と、取得したユーザモデルとに基づいて、対象ユーザが希望する移動の開始時刻を推定する。ステップＳ６１２の処理を実行する需要予測部１０６が本発明の第２推定手段に相当する。

ここで、対象ユーザとユーザモデルが１対１に対応する場合には、需要予測部１０６は、そのユーザモデルで定義される時間をユーザの移動開始時刻であると推定する。たとえば、対象ユーザが、検索の１時間後に移動を開始するユーザモデルのみを有する場合には、需要予測部１０６は、最先の検索から１時間後をユーザの移動開始時刻であると推定する。

対象ユーザに複数のユーザモデルが対応する場合、需要予測部１０６はこれら複数のユーザモデルを考慮したユーザの移動開始時刻を推定する。たとえば、検索の１時間後に移
動を開始するユーザモデル１に７０％の確率で当てはまり、検索の２時間後に移動を開始するユーザモデル２に３０％の確率で当てはまるユーザを想定する。この場合、需要予測部１０６は、たとえば、確率に応じて移動開始時刻を推定、より具体的には、７０％の確率で最先の検索の１時間後とし、３０％の確率で最先の検索の２時間後としてもよい。あるいは、需要予測部１０６は、最も確率の高いユーザモデル１にしたがって最先の検索の１時間後を移動開始時刻として推定してもよい。さらには、需要予測部１０６は、確率に応じた需要があると推定してもよく、より具体的には、最先の検索の１時間後に移動を開始する需要が0.7回（0.7人分）あり、最先の検索の２時間後に移動を開始する需要が0.3
回（0.3人分）あると推定してもよい。さらには、需要予測部１０６は、２次データやそ
の他の情報に基づく機械学習結果に基づいて、いずれかのユーザモデルを選択して利用してもよい。

以上の処理により、一人のユーザについて、所望する移動の出発地および目的地と、移動開始時刻とが推定できる。ステップＳ６１４において、需要予測部１０６は、対象ユーザの移動需要を決定して、メモリに格納する。

ループＬ２の処理を全てのユーザについて行うことで、需要予測部１０６は、全てのユーザの移動需要を決定することができる。ステップＳ６１８において、需要予測部１０６は、このようにして決定された全ユーザの移動需要を、回送リクエスト生成部１０８に出力する。

［回送計画生成処理］
図８のフローチャートを参照して、回送計画生成処理について説明する。回送計画とは、車両の配置を調整するための計画であり、典型的には作業員による手動での車両の配置変更を意味するが、インセンティブ付与によって行われるユーザによる車両の配置変更を含んでもよい。また、車両が自動運転可能車両であれば、自動運転によって車両の配置を変えてもよい。

ステップＳ８０２において、回送リクエスト生成部１０８は、現在の車両配置情報１３０と回送計画１３２を取得する。現在の車両配置情報１３０および回送計画１３２は、カーシェアリングシステムを管理している管理サーバから取得可能である。

ステップＳ８０４において、回送リクエスト生成部１０８は、需要予測部１０６によって予測された移動需要を取得する。上述したように、この移動需要には、ユーザが所望する移動の出発地・目的地・移動開始時刻が含まれる。

ステップＳ８０６において、回送リクエスト生成部１０８は移動需要を集約して回送リクエストを生成する。ここでは、回送リクエスト生成部１０８は、現在の車両配置および回送計画のままでは実現できない移動需要を特定し、この移動需要を満たすためのリクエストを回送リクエストとして決定する。回送リクエストには、たとえば、時刻ＴまでにステーションＡの車両台数を１台増やすといったものや、時刻ＴまでにステーションＢの空きスポットを１つ増やすといったものが含まれる。生成された回送リクエストは、回送計画生成部１１０に出力される。

回送計画生成部１１０は、回送リクエストと、現在の車両配置情報１３０・回送計画１３２、および回送リソース情報１３４に基づいて、現在の回送計画を修正して新たな回送計画を生成する。具体的には、回送計画生成部１１０は、図９のフローチャートに示す回送計画修正処理を行って回送計画を生成する。

まず、ステップＳ９０２において、回送計画生成部１１０は、対応不可能なリクエスト
を除外する。具体的には、回送計画生成部１１０は、検討開始時刻（現在時刻）から所定時間以内の回送に関するリクエストを除外する。所定時間は、回送計画の実行の準備に必要な時間であり、典型的には、回送計画の計算（算出）に要する時間と回送スタッフの準備に要する時間とを合計した時間である。

ループＬ３の処理は、ステップＳ９０２における除外処理後のリクエストのそれぞれについて実行される。

ステップＳ９０４において、回送計画生成部１１０は、現在の回送計画１３２と照らし合わせて、リクエストに対してスタッフが対応可能であるか否かを確認する。具体的には、回送計画生成部１１０は、リクエストで要求されている時間帯が、スタッフが稼働可能な時間帯であるか否かを確認する。これは、回送に要する時間帯だけでなくその前後の予定も考慮して対応可能であるか否かを判断することが望ましい。

リクエストが対応可能であれば（Ｓ９０４−ＹＥＳ）、処理はステップＳ９０６に進む。ステップＳ９０６では、回送計画生成部１１０は、リクエストを回送計画に追加する。

リクエストが対応可能であれば（Ｓ９０４−ＮＯ），処理はステップＳ９０８に進む。ステップＳ９０８では、回送計画生成部１１０は、競合するリクエストの中から最適なリクエストを決定する。ここで、「最適」の基準は、システム要求に応じて適宜決定すればよく、たとえば、利益やサービス率などを用いればよい。最適なリクエストを決定するための手法には、たとえば、線形計画法や整数計画法などの最適化計算による決定や、シミュレーションに基づく決定や、ルールベースでの決定などがある。ステップＳ９１０において、回送計画生成部１１０は、最適なリクエストを回送計画に追加し、このリクエストと競合するリクエストを回送計画から除外する。

以上の処理を全てのリクエストに対して行うことで、新しい回送計画の生成が完成する。

なお、ここで説明した処理は、計算速度を重視した簡易的な手法であり、必ずしも最適な回送計画が得られるわけではない。より精度を重視するのであれば、現在の状況と予測された移動需要とを全て考慮に入れた最適化計算を行えばよい。しかしながら、一般に最適化計算は変数が多くなると計算量が膨大になることから、本実施形態では、上述のような簡易的で高速な手法を採用している。

図８の説明に戻る。新しい回送計画が生成されると、ステップＳ８１０において、回送計画実行部１１２が、回送スタッフが行動を変更するための適切なタイミングでスタッフに対して回送の実行指示を出力する。

［本実施形態の有利な効果］
本実施形態によれば、ユーザの検索履歴に基づいてユーザの移動需要を予測し、予測した移動需要に対応するための回送計画を作成・実行することができる。

本実施形態は、これから行う移動に関する検索行動に基づいて需要予測をしているので、精度の高い予測が可能である。これは、個々のユーザの行動を予測していること、および、現在の検索行動がそのまま将来の移動需要につながる可能性が高いことに基づいている。従来の手法は、ユーザを集合として捉えてそのうちの何割が地点Ａから地点Ｂに移動するというような予測をしているが、このような予測は、必然的にばらつきが生じ、需要変動が大きなサービスでは精度のよい予測は行えない。すなわち、本実施形態の手法によって、従来よりも精度の高い需要予測が行える。また、このような需要予測に基づいて回
送計画を生成することで、よりユーザの需要を満足可能な回送計画が生成できる。

（第２の実施形態）
第１の実施形態では、移動の出発地および目的地や移動開始時刻の予測に、検索履歴に含まれる検索条件（出発地および目的地）および検索時刻と利用実績に含まれる利用開始時刻のみが利用されている。しかしながら、これら以外の情報を用いて、移動の出発地および目的地や移動開始時刻を予測してもよい。

需要予測部１０６は、たとえば、検索時または利用時の気象条件や、出発地と目的地の組み合わせ、検索実行の時間（時間帯・曜日）などの２次データを予測に利用してもよい。たとえば、天気の悪い日と天気の良い日とで行動傾向が異なるユーザについては、天気を考慮することでより適切な予測が行える。同様に検索の時間帯や曜日によって行動傾向が異なるユーザについては、検索の日時を考慮することで適切な予測を行える。また、検索における出発地と目的地を考慮して予測しても良い。たとえば、普段からよく利用している移動区間については利用直前のみに検索をし、普段はあまり利用しない移動区間については利用開始のかなり前から検索をするようなユーザも存在する。このようなユーザについては、検索条件に含まれる出発地や目的地に応じて異なるユーザモデルを利用することで、より精度の良い予測が可能となる。

本実施形態では、ユーザモデル生成部１０２は、ユーザごとに、検索時または利用時の気象条件、出発地と目的地の組み合わせ、検索実行の時間の少なくともいずれかごとにユーザモデルを生成する。ステップＳ６０８において、需要予測部１０６は、これらの要素も考慮して、需要予測に用いるユーザモデルを選択する。

本実施形態によれば、２次データを考慮したユーザモデルを利用して需要予測が行えるので、第１の実施形態よりもさらに精度の高い予測が行える。

（第３の実施形態）
上記の実施形態では、基本的にユーザごとにユーザモデルを決定している。本実施形態では、複数のユーザ（ユーザグループ）に対してユーザモデルを決定する。図１０は、本実施形態におけるユーザモデル生成処理を示すフローチャートである。

本実施形態におけるユーザモデル生成部１０２は、検索履歴および利用実績を取得し（Ｓ１００２）、ユーザごとに暫定ユーザモデルを生成する（Ｓ１００４）。この処理は、基本的に第１の実施形態と同様の処理である。なお、本実施形態では、ユーザの利用頻度にかかわらず暫定ユーザモデルを生成するようにしているが、第１の実施形態と同様に利用頻度が閾値以上のユーザのみについて暫定ユーザモデルを生成するようにしてもよい。

次に、ユーザモデル生成部１０２は、検索の傾向が共通する複数のユーザをユーザグループとして決定する（Ｓ１００６）。すなわち、ユーザモデル生成部１０２は、暫定ユーザモデルが類似する複数のユーザを１つのグループに集約する。さらに、ユーザモデル生成部１０２は、ユーザグループに対応するユーザモデルを決定する（Ｓ１００８）。ユーザグループ内で暫定ユーザモデルの差異がある場合には、暫定ユーザモデルを平均化するなどしてユーザグループについて１つのユーザモデルを定義するようにしてもよい。このようにすれば、記憶するユーザモデルの数を削減することができる。

ユーザモデル生成部１０２は、ユーザグループ内のユーザに共通する特徴を抽出して、ユーザグループを求めるための分類基準を生成する（Ｓ１０１０）。ユーザグループの分類に用いる特徴は、ユーザの属性や、検索履歴や、利用実績の少なくともいずれかに基づく特徴であることが望ましい。このようにユーザグループごとのユーザ特徴を定義する分
類基準を求めることで、利用頻度が少ないユーザについても、そのユーザに特有のユーザモデルを適用した需要予測が可能となる。なお、ユーザ特徴は、さらに、検索時または利用時の気象状況、出発地と目的地の組み合わせ、検索実行の時間帯のいずれかを含んでもよい。

本実施形態においては、ユーザモデル生成部１０２は、ユーザグループに関連付けてユーザモデルをユーザモデル記憶部１０４に記憶する（Ｓ１０１２）。需要予測部１０６は、上記で決定したユーザの分類基準も記憶部に記憶する。

本実施形態における需要予測処理は基本的に第１の実施形態（図６）と同様である。ただし、ステップＳ６０８において、需要予測部１０６は、対象ユーザの属性・検索履歴・利用実績と、分類基準とに基づいて対象ユーザのユーザグループを特定し、特定されたユーザグループに関連付けられたユーザモデルを、ユーザモデル記憶部１０４から取得する。

また、本実施形態においては、ユーザの利用頻度に応じたユーザモデルの選択（Ｓ６０６〜Ｓ６１０）は行わなくてもよい。たとえば、需要予測部１０６は、対象ユーザが既存のいずれかのユーザグループに当てはまる確率が高ければ該当するユーザグループのユーザモデルを利用し、そうでない場合にデフォルトユーザ用のユーザモデルを利用してもよい。

（第４の実施形態）
本実施形態では、上記の実施形態の構成に加えて、ユーザモデルを更新する更新部を備える。更新部は、ユーザモデル生成部１０２がユーザモデルを生成した後の検索履歴と利用実績に基づいて、ユーザモデルを更新する。

ユーザモデルの更新には、次の２通りが考えられる。１つは、ユーザ（あるいはユーザグループ）ごとの各モデルの割当確率の変更である。たとえば、図５では、ユーザαはモデル１に対応する確率が９０％であり、モデル２に対応する確率が１０％である。これを、モデル１を９５％に、モデル２を５％に更新する処理が１つの目の更新手法に該当する。

２つ目は、モデルにおける行動傾向の変更である。たとえば、図５のモデル１は検索から１時間後に利用を開始するものであるが、これを検索から５０分後に利用を開始するものに更新する処理が２つ目の更新手法に該当する。

これら２つの更新手法はいずれか一方のみを採用してもよいし、両方を採用してもよい。

このように、検索履歴および利用実績が増加する度にユーザモデルの更新を行うことで、ユーザの利用傾向をより忠実に反映したユーザモデルの生成が可能となり、ユーザの需要をより精度良く予測できる。

（第５の実施形態）
第１の実施形態では、ユーザモデルの生成と、需要の予測と、需要予測に基づく回送計画の生成を１つのサーバで実現している。しかしながら、これらの機能は、それぞれ独立して実行してもよい。

たとえば、ユーザモデルの生成は他の装置（ユーザモデル生成装置）で行い、生成されたユーザモデルに基づく需要予測と回送計画生成は別の装置で行ってもよい。ユーザモデ
ル自体が利用価値の高い情報であるため、本発明はユーザモデル生成装置として捉えることもできる。

また、ユーザの移動需要予測自体も利用価値の高い情報であるため、本発明は需要予測装置として捉えることもできる。上述のように、ユーザモデル自体は需要予測装置で生成する必要はなく、別の装置によって生成されたユーザモデルを取得して利用してもよい。また、予測された移動需要は、回送以外に活用しても構わない。

（第６の実施形態）
上記の説明では、カーシェアリングシステムにおける回送計画生成サーバを説明したが、本発明の適用先はカーシェアリングシステムに限定されない。本発明は、オンデマンド型のモビリティサービス一般に適用可能である。オンデマンド型のモビリティサービスとは、ユーザからの要求に応じて、ユーザに対して移動手段を提供するサービスである。オンデマンド型モビリティサービスの例として、予約型乗合タクシーや、オンデマンドバス（エリア型バスだけでなく、迂回型バスも含む）などが挙げられる。いずれもユーザが予約を行って利用するサービスであり、かつ、十分な移動資源がなければユーザがサービスを受けられない点において共通する。このようなオンデマンド型モビリティサービスにおいて、ユーザの需要を予測し、それに応じて移動資源を適切に配置することで、ユーザの需要に適切に応えることが可能となる。

（その他の実施形態）
上記の実施形態はあくまでも一例であって、複数の実施形態を組み合わせて実施したり、本発明はその要旨を逸脱しない範囲内で適宜変更して実施したりしてもよい。

上記の実施形態における、需要予測装置、ユーザモデル生成装置、回送計画生成装置は、それぞれ独立した発明として捉えることができる。需要予測装置は、モビリティサービスにおける移動需要を予測するものであるが、予測結果はモビリティサービスの回送計画生成以外の目的に使われてもよい。たとえば、カーシェアリングシステムによる需要予測の結果を、他のモビリティサービス（たとえば，鉄道など）で利用してもよい。カーシェアリングシステムを使って、鉄道の駅に到着するユーザは、鉄道サービスにおける需要となり得るからである。また、ユーザモデル生成装置も、それ単独で有用である。本開示におけるユーザモデルによれば、ユーザの行動予測が行えるためである。

１００：回送計画生成装置
１０２：ユーザモデル生成部 １０４：ユーザモデル記憶部
１０６：需要予測部 １０８：回送リクエスト生成部
１１０：回送計画生成部 １１２：回送計画実行部
１２０：検索履歴データ １２２：利用実績データ
１３０：車両配置情報 １３２：回送計画 １３４：回送リソース情報

Claims (18)

1. モビリティサービスにおける需要を予測する需要予測装置であって、
   ユーザによって行われた出発地と目的地とを含む検索の条件および当該検索が行われた時刻を含む検索履歴を取得する履歴取得手段と、
   前記検索履歴から、前記ユーザが所望する移動の出発エリアまたは目的エリアの少なくとも一方を推定する第１推定手段と、
   前記検索履歴と、検索を行った時刻と実際の移動の開始時刻との差を定義したユーザモデルと、に基づいて前記ユーザが所望する移動の開始時刻を推定する第２推定手段と、
   前記ユーザが、前記第２推定手段が推定した移動の開始時刻に、前記第１推定手段が推定した出発エリアまたは目的エリアによって規定される移動をすると予測する需要予測手段と、
   を備える需要予測装置。
2. 複数のユーザモデルをユーザと関連付けて記憶する記憶手段と、
   前記ユーザに関連付けられたユーザモデルを選択するユーザモデル選択手段と、
   をさらに備える、請求項１に記載の需要予測装置。
3. 複数のユーザモデルをユーザグループと関連付けて記憶する記憶手段と、
   前記ユーザの属性と検索履歴と利用実績との少なくともいずれかに基づいて、ユーザに該当するユーザグループを決定し、前記ユーザモデルに関連付けられたユーザモデルを選択するユーザモデル選択手段と、
   をさらに備え、
   前記第２推定手段は、前記ユーザモデル選択手段によって選択されたユーザモデルを用いて、前記ユーザが所望する移動の開始時刻を推定する、
   請求項１に記載の需要予測装置。
4. 前記ユーザモデル選択手段は、前記ユーザの利用頻度が閾値未満であれば、前記ユーザモデル選択手段は、前記複数のユーザモデルのうちの所定のユーザモデルを選択する、
   請求項２または３に記載の需要予測装置。
5. 前記ユーザモデル選択手段は、検索時または利用時の気象条件、出発エリアと目的エリアの組み合わせ、検索実行の時間の少なくともいずれかも考慮して、前記ユーザに該当するユーザモデルを選択する、
   請求項２から４のいずれか１項に記載の需要予測装置。
6. 複数の検索履歴と利用実績を取得して、前記記憶手段に記憶された前記複数のユーザモデルの少なくともいずれかを更新する更新手段をさらに備える、
   請求項２から５のいずれか１項に記載の需要予測装置。
7. 前記第１推定手段は、時間的に一連の検索において指定された出発地および目的地の重み付き回数に基づいて、前記ユーザが所望する移動の出発エリアまたは目的地エリアを推定し、
   前記重み付き回数における重みは、前記一連の検索における検索時刻が前であるほど大きい、
   請求項１から６のいずれか１項に記載の需要予測装置。
8. 請求項１から７のいずれか１項に記載の需要予測装置と、
   前記需要予測装置によって予測された需要と、前記モビリティサービスにおける移動資源の配置および現在の回送計画に基づいて、前記移動資源の配置換えを行う回送計画を生
   成する計画生成手段をさらに備える、
   回送計画生成装置。
9. 前記計画生成手段は、
   前記需要予測装置によって予測された需要と、前記モビリティサービスにおける移動資源の配置および現在の回送計画に基づいて、１つまたは複数の回送リクエストを生成し、
   前記１つまたは複数の回送リクエストのうち、他のリクエストと競合せずに実行可能な回送リクエストを、新しい回送計画に追加し、
   前記１つまたは複数の回送リクエストのうち、他のリクエストと競合する回送リクエストについては、所定の基準に基づいて最適な回送リクエストを選択して、前記新しい回送計画に追加する、
   ことにより回送計画を生成する、
   請求項８に記載の回送計画生成装置。
10. モビリティサービスにおける、ユーザが検索を行った時刻を含む検索履歴を、複数のユーザについて取得する履歴取得手段と、
    前記ユーザが前記モビリティサービスの利用を開始した時刻を含む利用実績を取得する実績取得手段と、
    前記検索履歴と前記利用実績に基づいて、前記ユーザが検索を行ってから利用を開始するまでの時間を定義したユーザモデルを生成する生成手段と、
    を備える、ユーザモデル生成装置。
11. 前記生成手段は、ユーザごとのユーザモデルを、当該ユーザの検索履歴と利用実績に基づいて生成する、
    請求項１０に記載のユーザモデル生成装置。
12. 前記生成手段は、
    ユーザごとの暫定ユーザモデルを、当該ユーザの検索履歴と利用実績に基づいて生成し、
    暫定ユーザモデルが類似するユーザをユーザグループとして集約し、
    ユーザグループごとのユーザモデルと、ユーザグループの分類基準とを生成する、
    請求項１０に記載のユーザモデル生成装置。
13. 前記生成手段は、利用頻度が閾値未満のユーザの検索履歴と利用実績に基づいて１つのユーザモデルを生成する、
    請求項１０から１２のいずれか１項に記載のユーザモデル生成装置。
14. 前記生成手段は、検索時または利用時の気象条件、出発エリアと目的エリアの組み合わせ、検索実行の時間の少なくともいずれかも考慮して、前記ユーザモデルを生成する、
    請求項１０から１３のいずれか１項に記載のユーザモデル生成装置。
15. 前記ユーザモデルを生成する際に用いられていない検索履歴と利用実績に基づいて、前記ユーザモデルを更新する更新手段をさらに備える、
    請求項１０から１４のいずれか１項に記載のユーザモデル生成装置。
16. モビリティサービスにおける需要を予測する需要予測方法であって、
    コンピュータが、
    ユーザによって行われた出発地と目的地とを含む検索の条件および当該検索が行われた時刻を含む検索履歴を取得する履歴取得ステップと、
    前記検索履歴から、前記ユーザが所望する移動の出発エリアまたは目的エリアの少なく
    とも一方を推定する第１推定ステップと、
    前記検索履歴と、検索を行った時刻と実際の移動の開始時刻との差を定義したユーザモデルと、に基づいて前記ユーザが所望する移動の開始時刻を推定する第２推定ステップと、
    前記ユーザが、前記第２推定ステップにおいて推定された移動の開始時刻に、前記第１推定ステップにおいて推定された出発エリアまたは目的エリアによって規定される移動をすると予測する需要予測ステップと、
    を実行する、需要予測方法。
17. モビリティサービスにおいて、ユーザが検索を行ってから利用を開始するまでの時間を定義したユーザモデルを生成するためのユーザモデル生成方法であって、
    コンピュータが、
    モビリティサービスにおける、ユーザが検索を行った時刻を含む検索履歴を、複数のユーザについて取得する履歴取得ステップと、
    前記ユーザが前記モビリティサービスの利用を開始した時刻を含む利用実績を取得する実績取得ステップと、
    前記検索履歴と前記利用実績に基づいて、前記ユーザが検索を行ってから利用を開始するまでの時間を定義したユーザモデルを生成する生成ステップと、
    を実行する、ユーザモデル生成方法。
18. 請求項１６または１７に記載の方法の各ステップをコンピュータに実行させるためのプログラム。

Images