(57)【要約】【課題】イベント予定の事前登録が無くても、高精度に将来の需要を予測する。【解決手段】需要予測システムは、過去の時系列の需要実績値を示す需要実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値に対応した１以上の時刻に従う１以上の期間を１以上のイベント発生期間したイベントデータを作成することを、複数の対象の各々について行う。システムは、複数の対象のうちのいずれかの対象と将来の時期との指定を受け付け、当該指定された対象について、当該指定された対象に対応したイベントデータを基に、将来の時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行う。システムは、当該イベント予測の結果を基に将来の時期での需要の予測である需要予測を行う。【選択図】図１
2019168868.tif 000002
【特許請求の範囲】
【請求項１】
過去の時系列の需要実績値を示す需要実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値がイベントの影響を受けた需要実績値としたイベントデータを作成することを、複数の対象の各々について行うイベントデータ作成部と、
前記複数の対象のうちのいずれかの対象と将来の時期との指定を受け付け、当該指定された対象について、当該指定された対象に対応したイベントデータを基に、前記将来の時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行い、当該イベント予測の結果を基に前記将来の時期での需要の予測である需要予測を行い、当該需要予測の結果として予測された需要を表す需要結果情報を出力する需要予測部と
を備える需要予測システム。
【請求項２】
前記需要実績データを基に１以上のモデルを作成することを前記複数の対象の各々について行うモデル作成部、
を更に備え、
前記複数の対象の各々について、前記基準値は、当該対象についての前記１以上のモデルを用いて作成され、
前記複数の対象の各々について、前記イベントデータは、前記見つかった１以上の需要実績値と、当該１以上の需要実績値に対応した１以上の時刻と、前記１以上のモデルとに基づくイベント効果の１以上の予測モデルである１以上のイベント効果予測モデルを含んだデータであり、
前記需要予測部は、前記指定された対象について作成された１以上のモデルと、前記指定された対象に対応したイベントデータ中の１以上のイベント効果予測モデルとを基に、前記イベント予測および前記需要予測を行う、
請求項１に記載の需要予測システム。
【請求項３】
前記複数の対象の各々について、前記１以上のモデルは、
第１の期間での需要変動の傾向を示すモデルであるトレンドモデルと、
前記第１の期間における第２の期間毎に繰り返される需要変動を示すモデルである周期性モデルと
を含み、
前記複数の対象の各々について、前記基準値は、前記トレンドモデルと前記周期性モデルとに基づいて作成された点である、
請求項２に記載の需要予測システム。
【請求項４】
前記複数の対象の各々について、前記イベントデータは、当該対象についてのイベント毎に対応したイベントデータセットを含み、
各イベントについて、前記イベントデータセットは、当該イベントのイベント名、発生頻度、発生パタン、発生時期、発生期間、および、前記１以上のモデルの少なくとも１つを基に得られたイベント効果予測モデル、のうちの少なくともイベント効果予測モデルを含む、
請求項２に記載の需要予測システム。
【請求項５】
前記需要結果情報は、前記指定された対象について前記イベント予測において発生が予測されたイベントに関する情報であって、当該イベントに対応したイベントデータセットにおける要素を含む、
請求項４に記載の需要予測システム。
【請求項６】
前記需要予測部は、前記予測されたイベントに対応したイベントデータセットにおける要素の追加、削除および編集のうちの少なくとも１つを受け付ける、
請求項５に記載の需要予測システム。
【請求項７】
運行最適化システムに接続されており、
前記指定された対象は、第１の駅と第２の駅を含み、
前記需要予測において予測された需要は、前記第１の駅と前記第２の駅間での利用者数であり、
前記運行最適化システムは、前記将来の時期について、列車本数と、列車運賃と、予測された利用者数とを基に、列車本数および列車運賃の少なくとも１つを最適化するシステムである、
請求項１に記載の需要予測システム。
【請求項８】
前記需要予測部は、前記将来の時期におけるいずれかの期間が発生期間であるイベント予定に関するイベント予定データセットが事前登録されていれば、前記イベント予測の結果に加えて、事前登録されている当該イベント予定データセットに基づいて、前記需要予測を行う、
請求項４に記載の需要予測システム。
【請求項９】
前記イベント予定データセットは、需要と同じ単位で表現されたイベント規模を含み、
前記予測されたイベントが、事前登録されているイベント予定と一致しており、且つ、前記予測されたイベント効果と前記イベント規模との乖離が一定乖離を超えている場合に、当該イベント効果が補正される、
請求項８に記載の需要予測システム。
【請求項１０】
過去の時系列の需要実績値を示す需要実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値がイベントの影響を受けた需要実績値としたイベントデータを作成することを、複数の対象の各々について行い、
前記複数の対象のうちのいずれかの対象と将来の時期との指定を受け付け、
前記指定された対象について、
当該指定された対象に対応したイベントデータを基に、前記将来の時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行い、
前記イベント予測の結果を基に前記将来の時期での需要の予測である需要予測を行い、
当該需要予測の結果として予測された需要を表す需要結果情報を出力する、
需要予測方法。
【請求項１１】
過去の時系列の需要実績値を示す需要実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値がイベントの影響を受けた需要実績値としたイベントデータを作成することを、複数の対象の各々について行い、
前記複数の対象のうちのいずれかの対象と将来の時期との指定を受け付け、
前記指定された対象について、
当該指定された対象に対応したイベントデータを基に、前記将来の時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行い、
前記イベント予測の結果を基に前記将来の時期での需要の予測である需要予測を行い、
当該需要予測の結果として予測された需要を表す需要結果情報を出力する、
ことをコンピュータに実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、将来の需要を予測する技術に関する。
【背景技術】
【０００２】
コンサート、フェスティバルに代表されるイベントは主に数時間〜数日の期間で交通機関の利用者数（需要）に大きな影響を与えることが知られている。仮に将来発生するイベントが既知の場合、イベント効果を加味し、需要予測を行うことで予測精度を向上させることができる。例えば、需要予測システムとして次のような方法が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2006-268529号公報
【特許文献２】特開2010-231605号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では、過去に発生したイベント効果（特徴モデル）と将来発生するイベント予定を登録し、それらを元にイベント時における需要予測を行っている。しかしながら、大規模な都市で開催されるイベントは大小含めると無数にあるため、全てのイベントを１つ１つ登録することは登録作業コスト（登録作業の負担）が大きい。
【０００５】
一方、特許文献２では、イベント予定の登録がない場合においても、イベントが発生しているかどうかを当日の時系列のパタンから判断している。発生イベントを特定し、精度良く需要予測を行うためには、イベント時の時系列パタンを起こり得るイベントの数だけ定義する必要がある。そのため、特許文献１と同様に登録作業コストが大きい。また、特許文献２では、当日の時系列データを用いる必要があるため、将来（例えば、数週間〜数ヶ月先）の需要の予測を行うことはできない。
【０００６】
そこで、本発明は、イベント予定の事前登録が無くても、将来（例えば、数週間〜数ヶ月先）の需要予測を高精度に行うことを目的とする。
【課題を解決するための手段】
【０００７】
イベントデータ作成部および需要予測部を備えた需要予測システムが構築される。イベントデータ作成部は、過去の時系列の需要実績値を示す需要実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値に対応した１以上の時刻に従う１以上の期間を１以上のイベント発生期間したイベントデータを作成することを、複数の対象の各々について行う。需要予測部は、複数の対象のうちのいずれかの対象と将来の時期との指定を受け付け、当該指定された対象について、当該指定された対象に対応したイベントデータを基に、将来の時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行う。需要予測部は、当該イベント予測の結果を基に将来の時期での需要の予測である需要予測を行い、当該需要予測の結果として予測された需要を表す需要結果情報を出力する。
【発明の効果】
【０００８】
イベント予定の事前登録が無くても、将来の需要予測を高精度に行うことができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態１に係る需要予測装置の構成等を説明する図である。
【図２】実施形態１に係る需要実績データの一例を示す図である。
【図３】実施形態１に係るトレンドモデル作成手順のフローチャートである。
【図４】実施形態１に係る周期性モデル作成手順のフローチャートである。
【図５（Ａ）】実施形態１に係るトレンドモデルのイメージを示す図である。
【図５（Ｂ）】実施形態１に係る周期性モデルのイメージを示す図である。
【図６】実施形態１に係るイベントデータ作成手順のフローチャートである。
【図７（Ａ）】実施形態１に係るイベントテーブルの一例を示す図である。
【図７（Ｂ）】実施形態１に係る需要予測モデルの一例を示す図である。
【図８】実施形態１に係る入力データとモデル化のイメージ図である。
【図９】実施形態１に係る需要予測手順のフローチャートである。
【図１０】実施形態１に係る需要予測結果の一例を示す図である。
【図１１】実施形態１に係る需要予測画面の第一の例を示す図である。
【図１２】実施形態１に係る需要予測画面の第二の例を示す図である。
【図１３（Ａ）】実施形態２に係る運行計画システムの一例を示す図である。
【図１３（Ｂ）】運行最適化システムを用いた運行計画の一例を示す図である。
【図１４（Ａ）】実施形態３に係る需要予測システムとイベント事前登録ＤＢと接続させた例を示す図である。
【図１４（Ｂ）】イベント事前登録ＤＢの一例を示す図である。
【発明を実施するための形態】
【００１０】
以降、本発明の幾つかの実施形態を、図を参照しながら説明する。以降の実施形態では、駅利用者の需要予測を例として採用している。しかしながら、本発明の適用範囲は、駅に限定されることなく、例えば、物流分野の需給予測（在庫管理）や機器レンタルの需給予測などにも適用可能である。
［実施形態１］
【００１１】
（需要予測システム）
【００１２】
図１に沿って、実施形態１に係る需要予測システム１の構成等を説明する。
【００１３】
需要予測システム１は、例えば、一般的なコンピュータを用いて実現可能である。需要予測システム１は、中央制御装置１１、入力装置（例えば、キーボードおよびマウス）１２、出力装置（例えば、ディスプレイ）１３、通信装置１４、主記憶装置１５、および、補助記憶装置１６を有する。これらの装置１１〜１６は、バスによって相互に接続されている。なお、通信装置１４は、１以上の通信インターフェースデバイスでよい。１以上の通信インターフェースデバイスは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。主記憶装置１５は、１以上のメモリでよい。１以上のメモリの少なくとも１つは、不揮発性のメモリでもよい。補助記憶装置１６は、１以上の不揮発性記憶デバイスでよい。各不揮発記憶デバイスは、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）でよい。中央制御装置１１は、１以上のプロセッサ（例えば、ＣＰＵ（Central Processing Unit）でよい。
【００１４】
主記憶装置１５における１以上のコンピュータプログラムが中央制御装置１１によって実行されることで、トレンドモデル作成部２１、周期性モデル作成部２２、イベントデータ作成部２３、および、需要予測部２４といった機能が実現される。以降、「○○部」は、中央制御装置１１が、補助記憶装置１６から１以上のプログラムを読み出し、当該１以上のプログラムを主記憶装置１５にロードし、当該１以上のプログラムを実行することで、実現されるものとする。
【００１５】
補助記憶装置１６は、需要実績テーブル３１、イベントテーブル３２、モデル管理テーブル３３、需要予測結果テーブル３４を記憶する。なお、以降の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。また、テーブル以外のデータ構造が採用されてもよい。
【００１６】
需要予測システム１は、ネットワーク４を介して、外部システム２及び外部サーバ３と通信可能である。ここで、外部システム２とは、例えば、実施形態２における運行最適化システム９１０（図１３（Ａ）参照）である。需要予測結果に合わせた運行最適化が可能となる。外部サーバ３とは、例えば、人流集計サーバであり、人流集計サーバに格納された人流集計履歴を、ネットワークを介して需要実績テーブル３１として活用することも可能である。また、必要に応じてカレンダー情報を外部サーバ３から取得してもよい。
【００１７】
（需要実績テーブル）
【００１８】
需要実績テーブル３１は、需要予測システム１の入力データとしての需要実績データの集合である。図２に沿って、需要実績テーブル３１を説明する。
【００１９】
需要実績テーブル３１は、複数の駅（複数の対象の一例）の各々について過去の時系列の人数（需要実績値の一例）を示す需要実績データの集合である。例えば、需要実績テーブル３１を構成する各レコードには、例えば、日付欄１０１、駅名欄１０２および人数欄１０３がある。日付欄１０１には日付が、駅名欄１０２には駅名が、人数欄１０３には日付および駅に紐付いた人数（駅利用者数）が記憶されている。
【００２０】
なお、図２では、１日単位で集計した例を記載しているが、需要実績データは１日単位の集計に限定されるものではない。例えば、需要実績テーブル３１における需要実績データは、１時間単位など１日未満で集計した需要実績データや、１週間単位などの複数日で集計した需要実績データでもよい。
【００２１】
本実施形態では、入力データである需要実績データの集計単位の粒度に合わせて需要予測を行うことが可能である。需要実績テーブル３１の入力は、例えば、ネットワーク４を介して、外部システム２に接続することで行うことが出来る。需要実績テーブル３１の具体的な例としては、レーザーセンサによって得られた駅内の通路を通過する人数を集計した結果などである。需要実績テーブル３１はセンサによる人数集計結果に限らず、改札履歴情報などを用いてもよいし、図２の例に限定されず、商品の販売実績、電力消費履歴、サイトへのアクセス履歴など様々な入力を対象としてもよい。
【００２２】
（トレンドモデル作成部）
【００２３】
図３に沿って、トレンドモデル作成の手順を説明する。なお、図３に示すトレンドモデル作成は、駅の需要実績データ毎に行われる。
【００２４】
本実施形態における「トレンド」とは、長期的な視点でみたときの需要変動の傾向である。例えば、１日単位で集計されていた需要実績データに対し、長期的視点として１年単位での集計を行い、年毎の需要変動をトレンドとして扱うことが出来る。
【００２５】
ステップＳ２０１において、トレンドモデル作成部２１は、需要実績テーブル３１を取得する。ステップＳ２０２において、トレンドモデル作成部２１は、月、年などの長期的な単位期間で需要実績テーブル３１を集計する。
【００２６】
そして、ステップＳ２０３において、トレンドモデル作成部２１は、変化点を抽出し、データを期間ごとに分割する。ステップＳ２０３における「変化点」とは、トレンドが大きく変化した時期（集計点）である。例えば、年単位で集計した結果において、年々１０％の需要増加が５年続いた後、その後５年間は年々１０％需要減少が続いて現在に至る場合、変化点は５年前の年となる。この場合、１０年前〜５年前の期間と５年前〜現在の期間でデータが分割される。
【００２７】
ステップＳ２０４において、トレンドモデル作成部２１は、分割した期間ごとに近似直線モデルあるいは近似曲線モデルを作成する。そして、ステップＳ２０５において、トレンドモデル作成部２１は、作成したモデルをトレンドモデルとして、モデルＩＤを割当て、モデル管理テーブル３３に記憶する。トレンドモデルの具体的イメージは後述する。
【００２８】
（周期性モデル作成部）
【００２９】
図４に沿って、周期性モデル作成の手順を説明する。なお、図４に示す周期性モデル作成は、駅の需要実績データ毎に行われる。
【００３０】
本実施形態における「周期性」とは、例えば季節毎の需要変動であり、夏に需要が増え、冬には需要が下がるといった毎年のように繰り返される需要変動である。
【００３１】
ステップＳ３０１において、周期性モデル作成部２２は、需要実績データを取得する。ステップＳ３０２において、周期性モデル作成部２２は、需要実績データからトレンド成分を除算する。ステップＳ３０２における「トレンド成分」とは、トレンドモデル作成部２１で作成したトレンドモデルによって算出される値である。例えば、年率１０％で需要増加していくトレンドモデルであった場合、その増加率を需要実績データから除算することで、トレンドを除去した定常性をもったデータを作成することができる。
【００３２】
そして、ステップＳ３０３において、周期性モデル作成部２２は、任意の周期Ｔで需要実績データからトレンド成分を除算したデータを分割する。例えば、周期性モデル作成部２２は、季節性の周期性モデルを作成する場合は１年を１周期としてデータを分割する。
【００３３】
ステップＳ３０４において、周期性モデル作成部２２は、周期Ｔのデータをフーリエ展開し、フーリエ級数モデルを作成する。そして、ステップＳ３０５において、周期性モデル作成部２２は、作成したフーリエ級数モデルを周期性モデルとして、モデルＩＤを割当て、モデル管理テーブル３３に記憶する。
【００３４】
本実施形態では周期性モデルの作成にフーリエ展開を用いることを例として記載したが、周期性モデルの作成はフーリエ展開に限定されるものではなく、例えば自己回帰モデルや移動平均モデルなどを用いてもよい。周期性モデルの具体的イメージは後述する。
【００３５】
（トレンドモデルのイメージ）
【００３６】
図５（Ａ）に沿って、トレンドモデルの具体的なイメージを説明する。
【００３７】
図５（Ａ）において、画面上の各ドットが前述したステップＳ２０２で集計した需要実績データであり、実線がトレンドモデル作成部２１で作成したモデルの値である。データは期間１（２０１）と期間２（２０２）に分割され、２つのトレンドモデルy1（２０３）とy2（２０４）が作成されている。データが２分割されているのは変化点（２０５）でトレンドが大きく変化しているからであり、例えば１つ前の集計値との差分が前回差分と大きく乖離した点を変化点として抽出する。なお、期間１と期間２の組合せが、第１の期間の一例である。
【００３８】
（周期性モデルのイメージ）
【００３９】
図５（Ｂ）に沿って、周期性モデルの具体的なイメージを説明する。
【００４０】
図５（Ｂ）において、画面上の各ドットが、前述したステップＳ３０３で需要実績テーブル３１からトレンド成分を除算したデータであり、実線が、周期性モデル作成部２２で作成したモデルの値である。データは１周期（２１１）毎に分割され、周期性モデルy(t)（２１２）が作成されている。ここで、１周期とは、例えば、１年単位などである。なお、１周期が、第２の期間の一例である。
【００４１】
（イベントデータ作成部）
【００４２】
図６に沿って、イベントデータ作成の手順を説明する。なお、図６に示すイベントデータ作成は、駅の需要実績データ毎に行われる。
【００４３】
本実施形態における「イベント」とは、コンサート、学会、悪天候、連休など、普段とは異なる需要を引き起こす様々な事象であり、ある特定の事象を指すものではない。以後、需要変動の一要因をイベントと記載して説明する。
【００４４】
ステップＳ４０１において、イベントデータ作成部２３は、トレンドモデルと周期性モデルを用いて基準値を作成する。本実施形態における“基準値”とは、イベントが発生しない場合に推定される需要の値である。具体的な数値を用いて基準値の一例を説明する。例えば、トレンドモデルによって年の需要平均値を算出した結果を仮に１００とする。次に周期性モデルを用いて各季節の需要変動を推定し、仮に夏は年平均に対し３割増、冬は年平均に対し３割減であったとする。これにより、例えば８月の基準値はトレンド：１００に周期性：３割増（＋３０）を加算した１３０となる。基準値は需要予測の粒度に合わせて（例えば１日単位で）作成する。
【００４５】
ステップＳ４０２において、イベントデータ作成部２３は、需要実績テーブル３１と基準値を比較する。ステップＳ４０３において、イベントデータ作成部２３は、需要実績データを構成する時系列の需要実績値（本実施形態では人数）のうち、ステップＳ４０１において作成された基準値との差分がしきい値を超えた需要実績値を特定し、特定した需要実績値毎にイベントデータセットを作成する。各イベントデータセットについて、需要実績値から基準値を引いた値が、イベント効果とされる。例えば、需要実績データと基準値を１日単位で比較し、その差分が基準値の±３０％以上の各需要実績値について、イベントデータセットが生成される。±３０％はしきい値の一例であり、プラス値のみがしきい値とされてもよいし、しきい値は、パーセントのような相対値ではなく、１０００人などの固定値でもよい。また、季節や年によってしきい値が変更されてもよい。なお、「データセット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペア及びタプルのうちのいずれでもよい。
【００４６】
ステップＳ４０４において、イベントデータ作成部２３は、特定の年月日、曜日、時期などで周期的に発生しているイベントについて、発生頻度、発生パタン、発生時期と合わせてイベント効果をモデル化し、イベントテーブル３２にイベントデータセットを記憶し、ならびに、モデル管理テーブル３３にイベント効果予測モデルを記憶する。また、ステップＳ４０５において、イベントデータ作成部２３は、特定の条件下で発生しているイベントについて、発生条件と合わせてイベント効果をモデル化し、イベントテーブル３２にイベントデータセットを記憶し、ならびに、モデル管理テーブル３３にイベント効果予測モデルを記憶する。本実施形態ではＳ４０４とＳ４０５をシリアルな処理としているが、それぞれ独立して処理を行うことも可能であり、Ｓ４０４、Ｓ４０５を並行して処理するあるいはＳ４０４、Ｓ４０５のどちらか片方のみを処理してもよい。イベントテーブルおよびモデル管理テーブルの詳細については、後述する。
【００４７】
（イベントテーブル）
【００４８】
図７（Ａ）に沿って、イベントテーブル３２を説明する。
【００４９】
イベントテーブル３２を構成する各レコードは、イベントデータセットに相当する。複数の駅の各々について、１以上のイベントデータセットを含んだイベントデータが存在する。なお、ここで言う「駅」は、１つの駅に限らず、例えば“全駅”のように２以上の駅が１つの「駅」とされることもある。
【００５０】
イベントテーブル３２を構成する各レコードには、例えば、抽出イベント名欄３０１、発生頻度欄３０２、発生パタン欄３０３、発生時期欄３０４、発生期間欄３０５、発生場所欄３０６、および、イベント効果予測モデルＩＤ欄３０７がある。イベントテーブル３２においては、抽出イベント名欄３０１には、イベント名が、発生頻度欄３０２には、推定されたイベント発生頻度が、発生パタン欄３０３には、イベントの発生パタンが、発生時期欄３０４には、イベントの発生時期が、発生期間欄３０５には、イベントの継続日数が、発生場所欄３０６には、イベントの発生場所が、イベント効果予測モデルＩＤ欄３０７には、モデルＩＤが記憶されている。なお、「発生パタン」は、特定曜日のように周期的に発生するイベントを意味するパタンもあれば、“条件”のように特定条件が満たされた場合にのみ発生するイベントを意味するパタンもある。また、「時期」は、時間の長さに加えて開始時刻と終了時刻の少なくとも１つが定まっていることを意味し、それに対して、「期間」は、時間の長さが定まっているが開始時刻と終了時刻のいずれも定まっていないことを意味する。「発生場所」は、駅のような対象の一例である。「イベント効果予測モデル」は、イベント効果を予測するためのモデルである。“モデルＩＤ”は、後述するモデル管理テーブル３３において、モデル（例えば予測式）を識別するために用いられる。
【００５１】
以下、１つの具体的な事例を用いてイベントテーブルの詳細を説明する。
【００５２】
イベント１（イベント名“イベント１”のイベント）は、毎年の頻度である特定日に発生するイベントである。より具体的には、イベント１は、１２月２５日の１日の期間で全駅に対して需要変動が発生するイベントであり、イベント１のイベント効果予測モデルのＩＤは“Ｃ１”である。イベント１は、ステップＳ４０４によって、毎年の１２月２５日の全駅において、平常時と比較して需要実績値がしきい値を超えていたため抽出されたイベントである。イベントは自動で抽出されるため、抽出イベント名欄３０１にはイベント１、イベント２などの通し番号が記憶されている。本実施形態では、イベント名は自動割り当てを想定して記載しているが、管理画面などを設けてユーザーが任意にイベント名を変更してもよい。例えば、イベント１であれば、毎年１２月２５日に発生する事象であるため、イベント名を“クリスマス”に変更することでユーザーはより分かり易くイベントを管理可能である。イベントの発生パタンは、イベント１のような毎年の特定日といった周期的に発生するものの他に、イベント５のような不定期な頻度で発生する休日並び（例えば３連休）といった条件であってもよい。イベント５は、ステップＳ４０５によって、不定期で発生する３連休の全駅において、平常時と比較して需要がしきい値を超えていたため抽出されたイベントである。休日並びを条件とする場合、イベント抽出にはカレンダー情報（祝日情報）が必要となる。その際、カレンダー情報を外部サーバ３から取得する、あるいは補助記憶装置１６に記憶させて読み込んでもよい。
【００５３】
（モデル管理テーブル）
【００５４】
図７（Ｂ）に沿って、モデル管理テーブル３３について説明する。
【００５５】
モデル管理テーブル３３には、トレンドモデル、周期性モデルおよびイベント効果予測モデルといった種々のモデルが記憶される。具体的には、例えば、モデル管理テーブル３３を構成する各レコードには、モデルＩＤ欄３１１および予測式欄３１２がある。モデルＩＤ欄３１１にはモデルを識別するＩＤが、予測式欄３１２にはＩＤに対応したモデルとしての式が記憶されている。予測式欄３１２には、トレンドモデル、周期性モデル、イベント効果予測モデルなど、本実施形態で作成されたモデルが定数あるいは数式として記憶される。モデル管理テーブル３３における「定数」とは、あるイベント時に必ず同じ需要となるというイベント効果予測モデルである。例えば、１月１日の駅利用者数が毎年しきい値を超えておおよそ基準値＋３万人であることが分かった場合、１月１日のイベント効果予測モデルを定数：30000としてもよい。「数式」とは、単回帰モデルや重回帰モデルなどの予測モデルである。例えば、トレンドモデルの予測値をX1、周期性モデルの予測値をX2、イベント発生からの経過日数をX3（複数日継続するイベント）として、予測式を需要予測値Y = 0.4 * (X1 + X2) - 100 * X3などとしてもよい。この予測式では、イベント初日は基準値に対し、４０％増のイベント効果があり、初日を基準として１日経過する毎に１００人の需要低下があることをモデル化している。予測式の説明変数には外部サーバ３から取得した外部データを活用してもよい。具体的には需要に影響を与える外部要因として予想降水確率や予想気温などを予測式の説明変数に取り込んでもよい。また、天候および気候データ以外でも経済指標、ＳＮＳ（Social Networking Service）情報、メディア情報、観光統計調査結果など、様々なデータを説明変数に取り込んでもよい。イベント効果予測モデルは入力データである需要実績データを基に作成され、そのタイミングは任意である。そのため、需要実績データが増える度にイベント効果予測モデルを更新する、年数回決まったタイミングでイベント効果予測モデルを更新する、イベント効果予測モデルを更新せずに使い続けるなどの運用方法が考えられる。また、イベント効果予測モデルは作成された後、ユーザーが手動で補正を加えてもよい。その際、修正前のモデルを別途記憶する、人手による修正モデルに修正フラグや修正者情報を付けて管理するなどを行ってもよい。
【００５６】
（入力データとモデル化のイメージ）
【００５７】
図８に沿って、入力データとモデル化の具体的なイメージを説明する。
【００５８】
図８において、上部グラフ４０１は、入力された時系列の需要実績値であり、下部グラフ４０２〜４０４が、モデル化のイメージ図である。入力データは、２０１５年１月から２０１７年１月までの２年分の需要実績データである。仮に１年単位で集計したデータからトレンドモデルを作成した場合、グラフ４０２に示したような線形増加の回帰直線モデルが作成される。また、仮に１年周期で周期性モデルを作成した場合、グラフ４０３に示したような曲線モデルが作成される。イベントのモデル化は需要実績データが基準値から大きく外れ、かつ規則性を持って発生しているかどうかで判定され、例えば、グラフ４０４に示したように条件に合致した特定の需要実績データが抽出される。
【００５９】
（需要予測部）
【００６０】
図９に沿って、需要予測の手順を説明する。
【００６１】
ステップＳ５０１において、需要予測部２４は、需要予測の対象駅と将来時期との指定（入力）を受け付ける。以下、指定された駅を「指定駅」と言い、指定された将来の時期を「指定時期」と言う。ここで指定時期とは、例えば、数ヶ月先のある１日、あるいは翌日以降のある日からある日までの時期などである。予測は、例えば、指定時期を構成する時間単位（例えば１日）毎に行われてよい。また、指定時期は、“Ｘ年○月△日の１０時〜１１時”といった詳細な時期でもよい。この場合は入力された時間粒度毎の需要予測が行われる。
【００６２】
ステップＳ５０２において、需要予測部２４は、トレンドモデルと周期性モデルから基準値を予測する。基準値の計算方法についてはステップＳ４０１と同様の処理で行い、説明は省略する。なお、本実施形態では、駅毎に、過去の時期について、トレンドモデル作成部２１によって作成されたトレンドモデルと、周期性モデル作成部２２によって作成された周期性モデルとがモデル管理テーブル３３に記憶されていてよい。需要予測部２４は、指定駅について、当該指定駅に対応したトレンドモデルおよび周期性モデルを基に、基準値を予測してよい。
【００６３】
ステップＳ５０３において、需要予測部２４は、指定時期にイベントが発生する可能性があるかを判定する。具体的には、例えば、需要予測部２４は、指定時期に属する日、曜日、月、休日などが、指定駅に対応したイベントデータが示す各イベントの発生パタンや発生時期と合致するかをチェックし、該当しているイベントがあった場合、対象日はイベント発生日であると判断する。このとき、カレンダー情報は外部サーバ３から取得する、あるいは補助記憶装置１６に記憶させておいてもよい。
【００６４】
対象日がイベント発生日である場合（ステップＳ５０３：Ｙｅｓ）、ステップＳ５０４において、需要予測部２４は、イベント効果予測モデルから対象日のイベント需要を予測する。「イベント需要」とは、イベントの影響を受けた結果としての需要である。具体的には、例えば、需要予測部２４は、対応するイベントに対応したイベント効果予測モデルＩＤに対応した予測式（モデル管理テーブル３３の予測式を）参照し、イベント効果を予測する。より具体的には、例えば、予測式が３万の定数であった場合、イベント効果は３万となる。Ｓ５０５において、需要予測部２４は、各予測値を合算したものを需要予測結果として記憶する。例えば、需要予測部２４は、トレンド予測値（予測されたトレンドモデルを基に予測された需要）：５万、周期性予測値（予測された周期性モデルを基に予測された需要）：−２万、イベント効果予測値：３万とした場合、需要予測結果はそれらを合算した６万となる。なお、予測値としてイベント効果には、該当しているとされたイベントに対応した発生期間が考慮されてよい。
【００６５】
なお、対象日がイベント発生日でない場合（ステップＳ５０３：Ｎｏ）、需要予測部２４は、ステップＳ５０２で予測した基準日を出力する。ステップＳ５０５において、算出される合計は、トレンド予測値と周期性予測値と基準値との合計になる。
【００６６】
（需要予測結果テーブル）
【００６７】
図１０に沿って、需要予測結果テーブル３４を説明する。
【００６８】
需要予測結果テーブル３４を構成する各レコードには、対象日欄５０１、駅名欄５０２および予測値欄５０３がある。対象日欄５０１には指定時期における予測の対象日（時間単位の粒度であれば時間情報も）が、駅名欄５０２には、駅名が、予測値欄５０３には、トレンド、周期性およびイベント効果といった３種類のモデルについて得られた３つの予測値とそれら合計といった需要予測結果が記憶されている。図１０では、駅利用者数の予測が需要予測の一例であるため、需要予測結果テーブル３４には駅名欄が設けられているが、例えば、改札履歴情報が用いられる場合、入場駅欄および出場駅欄が設けられてもよい。また、小売の需要予測であれば、駅名欄の代わりに対象とする店舗名欄を設けて需要予測を行ってもよいし、レンタル品の需要予測であれば、対象とする商品名欄を設けて需要予測を行ってもよい。需要予測結果テーブル３４の構成は、入力データである需要実績データの構成に合わせた構成とすることができる。
【００６９】
予測値について、需要予測結果テーブル３４における１番目のレコード（駅名“駅Ａ”のレコード）を一例に説明する。当該レコードは、２０１７年１２月２５日の需要予測結果を示し、予測値の「合計」は、駅Ａの利用者数を予測している。具体的には、予測値：トレンド“１０００”は、例えば、年平均の駅利用者の予測値（例えば、“駅Ａ”に対応しトレンドモデルから得られた値）として１０００人であることを意味している。予測値：周期性“６００”は、例えば、年平均に対する１２月の駅利用者の需要増分（例えば、“駅Ａ”に対応した周期性モデルから得られた値）が６００人であることを意味している。予測値：イベント効果“−５００”は、対象日にイベントが発生し、駅利用者が５００人低下すると予測されていることを意味する。結果として、２０１７年１２月２５日に駅Ａの利用者数は１１００人（＝１０００＋６００＋（−５００））であると予測される。
【００７０】
（システム画面）
【００７１】
需要予測システム１は、ユーザー、例えば鉄道事業者が需要予測結果を確認する画面等を提供する。以下に具体的な画面の一例を説明する。
【００７２】
（システム画面１：需要予測画面１）
【００７３】
図１１に沿って需要予測画面７０を説明する。なお、以降の説明では、「ＵＩ」は、ユーザーインターフェースの略であり、典型的には、ＧＵＩ（Graphical User Interface）部品である。
【００７４】
需要予測画面７０は、需要予測の対象（駅）を選択するＵＩ（例えばボタン）７０１および需要予測の対象時期（例えば対象日）を選択するＵＩ（例えばボタン）７０２を有する。ユーザーは、画面７０を用いて、需要予測対象とする駅と将来の時期を指定（選択）することができる。図１１の例によれば、需要予測画面７０では、２０１８年１月１日９時〜１０時に駅Ａの利用者が需要予測の対象として選択されている。
【００７５】
需要予測結果エリア７０４は、需要予測結果表示を要求するためのＵＩ（例えばボタン）７０３が操作された場合に需要予測結果情報（需要予測結果を示す情報）が表示されるエリアである。具体的には、例えば、ＵＩ７０３が操作された場合に需要予測部２４が呼び出され、呼び出された需要予測部２４により需要予測が行われ、需要予測結果テーブル３４に記憶された対象日の需要予測値が需要予測結果エリア７０４に表示される。需要予測結果エリア７０４では、予測値としての合計（“１２０００人”）がＵＩ７０５に表示される。ＵＩ７０５に表示された合計（予測値）をより理解し易いように前年度比情報などの補足情報を７０６が、需要予想結果エリア７０４に表示されてもよい。
【００７６】
（システム画面２：需要予測画面２）
【００７７】
図１２に沿って需要予測画面７１を説明する。
【００７８】
需要予測画面７１は、需要予測画面７０の一変形例である。需要予測画面７１は、需要実績値と需要予測値の確認を行うための時系列グラフ８０１を有する。時系列グラフ８０１において、実績値はドットで、基準値は実線で、自動抽出したイベントはイベント名（テキスト）と合わせて表示されている。また、予測値は破線で表示され、合わせて将来のイベント発生（イベント１の発生予測）を確認することができる。時系列グラフ８０１は、画面左下部（または他の部分）に設けられたＵＩ８０２〜８０５が操作されたことに応答して表示されてよい。ＵＩ８０２は、対象とする入出場駅を指定するためのＵＩである。ＵＩ８０３は、需要実績データの入力範囲としての入力時期を指定するためのＵＩである。ＵＩ８０４は、需要予測結果の出力範囲としての出力時期を指定するためのＵＩである。ＵＩ８０５は、需要予測結果の表示を要求するためのＵＩ（例えばボタン）である。需要予測画面７１では、駅Ａに入場し、駅Ｂで出場する鉄道利用者について、２０１５年１月〜２０１６年１２月までの需要実績データを用いて、２０１７年１月〜２０１７年１２月までの需要予測を行うことが選択されており、その結果が時系列グラフ８０１である。自動抽出されたイベントは１件であり、イベント１として画面上に表示され、その詳細情報はイベント発生予測エリア８０６に表示されている。イベント１は毎年１２月２５日に全駅で発生するイベントであり、基準値に対して需要が−５０％となることが示されている。また、ＵＩ（例えばボタン）８０７を操作することで、イベント発生予測エリア８０６に表示されたイベント情報の編集、追加および削除のうちの少なくとも１つを行うことも出来る。イベント名や予測モデルは需要予測システム１によって自動的に作成されるものであるが、より適切なものにユーザーが変更してもよい。また、自動抽出されなかったイベントをユーザーが追加してもよい（イベント編集・追加画面の説明は省略する）。
［実施形態２］
【００７９】
実施形態２を説明する。その際、実施形態１との相違点を主に説明し、実施形態１との共通点については説明を省略または簡略する。
【００８０】
実施形態１では、需要実績データを入力とし、省コストな運用で高精度な需要予測を行うことが可能である。需要予測結果の活用の一例として、図１３（Ａ）に運行管理システム９１の例を示す。運行管理システム９１は、需要予測システム１と、需要予測システム１の外部システムの一例である運行最適化システム９１０とを含む。運行最適化システム９１０で、相互に接続された運行計画システム９０１およびイールド管理システム９０２を含む。
【００８１】
運行計画システム９０１は、需要予測システム１によって予測された駅利用者（需要予測結果）を確認し、例えば、列車の定員と予測乗車人数に基づき、運転本数の最適化を行うことができる。より具体的には、例えば、運行計画システム９０１は、乗車率を１００％前後にするような運行本数を計画することができる。また、運行計画システム９０１は、運行計画情報を需要予測システム１に入力することで、需要予測システム１が、例えば、列車の運転本数および定員と予測乗車人数に基づき、列車に乗車できず駅に滞留する駅利用者数を計算することも可能である。
【００８２】
イールド管理システム９０２は、例えば、列車の運転本数および定員と予測乗車人数に基づき、列車の運賃を変更することができる。より具体的には、例えば、イールド管理システム９０２は、新幹線の指定席の価格を季節や時間帯の需要に合わせて任意に変更させるなどの機能を有する。
【００８３】
図１３（Ｂ）に需要予測結果を用いた列車運行計画の具体的なイメージを示す。
【００８４】
図１３（Ｂ）には３種類の棒グラフ（９１１〜９１３）が６つのケース（９１４〜９１９）の各々について記載されている。３種類の棒グラフは、左から運賃９１１、輸送力９１２、需要予測９１３である。運賃９１１とは、例えば、駅Ａから駅Ｂまでの列車移動に必要な料金である。輸送力とは、例えば、駅Ａから駅Ｂの１日の列車運行本数に列車の定員を乗算したものである。需要予測９１３とは、例えば、需要予測システム１によって予測された駅Ａから駅Ｂに移動する１日の駅利用者である。ケース１〜３（９１４〜９１６）は運賃や輸送力の初期値であり、ケース１’〜３’（９１７〜９１９）は図１３（Ａ）で示した運行計画システム９０１およびイールド管理システム９０２によって運賃や輸送力を変更した例である。ケース１（９１４）では、輸送力に対して、需要予測が小さいため、ケース１’（９１７）では運賃を下げて需要喚起を行っている（運賃を上下させて需要が上下するというモデルは別途用意しておく）。ケース２（９１５）では、輸送力に対して需要が大きいため、ケース２’（９１８）では需要予測に合わせて輸送力を上げている（運転本数を増やしている）。ケース３（９１６）では、輸送力に対して需要がかなり大きいため、ケース３’（９１９）では輸送力と運賃を合わせて上げている。これら運行計画の変更により、鉄道事業者と鉄道利用者双方にとって有益な輸送計画を立案することが可能となる。鉄道事業者と鉄道利用者双方にとって有益な運行計画とは、例えば、需要（鉄道を利用したい顧客）と供給（輸送力）が一致していること、収益（運賃×需要−運転コスト（輸送力））が最大となる輸送計画であること、などを満たす運行計画である。
［実施形態３］
【００８５】
実施形態３を説明する。その際、実施形態１および２との相違点を主に説明し、実施形態１および２との共通点については説明を省略または簡略する。
【００８６】
実施形態１および２では、イベント予定の事前登録がない場合においてもイベントの発生を加味した需要予測が可能である。しかし、イベントの中には不定期に発生するイベント、しきい値を超えないレベルでしか影響を与えない小規模イベント、数年に１回しか発生しない大イベントなど、自動抽出が難しいイベントも存在することが考えられる。仮にそれらのイベント発生日時、場所などが既知である場合、イベント予定を事前登録することにより、より高精度にイベントを加味した需要予測を行うことが可能となる。
【００８７】
図１４（Ａ）に、外部システムの一例としてのイベント事前登録ＤＢ（例えばＤＢシステム）９２１が需要予測システム１に接続されたシステムの一例を示す（「ＤＢ」は、データベースの略である）。図１４（Ｂ）に、イベント事前登録ＤＢ９２１の構成を示す。
【００８８】
イベント事前登録ＤＢ９２１を構成する各レコードには、例えば、イベント種９３１、開催日９３２、開催期間９３３、周辺駅９３４、規模９３５などが登録されている。それらのデータを需要予測システム１に入力することで、需要予測システム１で抽出できなかったイベントを、イベントデータＤＢの情報を用いることで補完を行い、より多くのイベント発生予測を行う。具体的には、例えば、８月１０日に開催を予定している展示即売会が需要予測システム１で予測できていなかった場合（あるいは、実施形態１および２での需要予測の処理において）、需要予測部２４が、イベント事前登録ＤＢ９２１における開催期間９３３、周辺駅９３４、規模９３５を参照し、当該イベント“展示即売会”による影響を受けた需要を予測する。より具体的には、例えば、８月１０日から３日間の期間で３０万人のイベント客が駅Ｄを利用して来場すると登録されているため、１日あたり１０万人規模と考え、８月１０日、１１日、１２日の駅Ｄの需要予測結果に対し、１０万人を加算することで需要予測の精度を向上させることができる。
【００８９】
また、イベント事前登録ＤＢ９２１に登録されたイベント予定が既に需要予測システム１で自動抽出されている場合、イベント予測の補正やイベント後にその結果を、需要予測システム１（例えば、需要予測部２４）がイベント事前登録ＤＢ９２１にフィードバックすることも可能である。具体的には、例えば、９月１日に開催を予定しているイベント“コンサート”が需要予測システム１で予測できている場合、需要予測部２４が、予測されたイベント効果と、イベント事前登録ＤＢ９２１に登録されている規模９３５とを比較し、予測結果が妥当であるかどうかを確認することが出来る。仮に、予測されたイベント効果（予測値としてのイベント効果）とイベント規模との乖離（差分）が大きかった場合、予測されたイベント効果が、需要予測部２４により自動補正されてもよいし、あるいは、ユーザーにより手動で補正されてもよい。イベント終了後は、需要予測部２４が、予測値（例えば、イベント効果や合計）ならびにイベント規模と、需要実績とを比較することで、誤差を評価すること（および、当該誤差を基にイベントデータを補正すること）も可能であり、その結果をユーザーに提示してもよい。また、新たに蓄積された需要実績データを用いて予測モデルが更新されてもよい。
【００９０】
以上の説明を、例えば下記のように総括することができる。なお、下記の総括は、上述の説明に無い事項を含んでもよい。
【００９１】
需要予測システム１が、イベントデータ作成部２３と、需要予測部２４とを備える。イベントデータ作成部２３が、需要実績データ（過去の時系列の需要実績値を示すデータ）を基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の需要実績値を探し、見つかった１以上の需要実績値がイベントの影響を受けた需要実績値としたイベントデータを作成することを、複数の対象（例えば駅）の各々について行う。需要予測部２４は、いずれかの対象と将来の時期との指定を受け付け、指定対象（当該指定された対象）について、当該指定対象に対応したイベントデータを基に、指定時期（指定された将来の時期）でのイベントの発生有無と、イベントが発生するのであれば当該イベントが需要実績値に与える影響であるイベント効果との予測であるイベント予測を行う。需要予測部２４は、当該イベント予測の結果を基に、指定時期での需要の予測である需要予測を行い、当該需要予測の結果として予測された需要を表す需要結果情報を出力（表示）する。このように、過去の時系列の需要実績値を示す需要実績データを基にイベントの影響を受けた需要実績値が自動抽出される。これにより、イベント登録作業の省コスト化が実現される。そして、イベントの影響を受けた需要実績値は、需要実績データを基に作成された基準値との差分がしきい値を超えている需要実績値である。将来のイベント発生を予測することによる需要予測の高精度化が期待できる。
【００９２】
なお、需要予測システム１（および、上述した外部システム２（例えば、運行最適化システム９１０）、および、外部サーバ３）は、１以上の物理コンピュータで構成されてもよいし、１以上の物理コンピュータの各々にインストールされた所定のソフトウエアが実行されることで実現されるソフトウエアディファインドのシステムでもよい。また、システム１が「情報を表示する」ことは、システム１が有するディスプレイに当該情報を表示することであってもよいし、システム１が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。
【００９３】
また、「時刻」の単位は、年月日のうちの少なくとも１つのように粗い単位でもよいし、さらに時分が追加された細かい単位でもよい。
【００９４】
需要予測システム１は、需要実績データを基に１以上のモデル（例えば、トレンドモデルおよび周期性モデルの少なくとも１つ）を作成することを複数の対象の各々について行うモデル作成部（例えば、トレンドモデル作成部２１および周期性モデル作成部２２の少なくとも１つ）を更に備える。複数の対象の各々について、基準値は、当該対象についての１以上のモデルを用いて作成される。複数の対象の各々について、イベントデータは、見つかった１以上の需要実績値と、当該１以上の需要実績値に対応した１以上の時刻と、前記１以上のモデルとに基づくイベント効果の１以上の予測モデルである１以上のイベント効果予測モデルを含んだデータである。需要予測部２４は、指定対象について作成された１以上のモデルと、指定対象に対応したイベントデータ中の１以上のイベント効果予測モデルとを基に、イベント予測および需要予測を行う。基準値は、需要実績データをモデル化することにより得られた１以上のモデルを基に作成されるので、精度の高い基準値を効率的に作成することが期待できる。
【００９５】
複数の対象の各々について、前記１以上のモデルは、第１の期間（例えば比較的長期の期間）での需要変動の傾向を示すモデルであるトレンドモデルと、第１の期間における第２の期間毎に繰り返される需要変動を示すモデルである周期性モデルとを含む。複数の対象の各々について、基準値は、トレンドモデルと周期性モデルとに基づいて作成された点である。トレンドモデルを基に長期の視点での需要変動の傾向がわかり、当該長期において周期的な需要変動がわかることが期待でき、故に、精度の高い基準値を効率的に作成することが期待できる。
【００９６】
複数の対象の各々について、イベントデータは、当該対象についてのイベント毎に対応したイベントデータセットを含む。各イベントについて、イベントデータセットは、当該イベントのイベント名、発生頻度、発生パタン、発生時期、発生期間、および、１以上のモデルの少なくとも１つを基に得られたイベント効果予測モデル、のうちの少なくともイベント効果予測モデルを含む。発生すると予測されたイベントに対応したイベントデータセット中のイベント効果予測モデル等に基づいて需要予測ができるため、需要予測を高精度に行うことが期待できる。
【００９７】
なお、需要結果情報は、指定対象についてのイベント予測において発生が予測されたイベントに関する情報であって、当該イベントに対応したイベントデータセットにおける要素を含む。これにより、発生が予測されたイベントと予測された需要との関係性をユーザーが把握できることが期待できる。
【００９８】
また、需要予測部２４は、予測されたイベントに対応したイベントデータセットにおける要素の追加、削除および編集のうちの少なくとも１つを受け付ける。これにより、イベント名やイベント予測効果モデルといった要素がユーザーにとって正確にまたは分かり易くなることが期待できる。
【００９９】
需要予測部２４は、指定時期におけるいずれかの期間が発生期間であるイベント予定に関するイベント予定データセット（例えば、イベント事前登録ＤＢ９２１におけるレコード）が事前登録されていれば、イベント予測の結果に加えて、事前登録されている当該イベント予定データセットに基づいて、需要予測を行う。これにより、需要予測の一層の高精度化が期待できる。
【０１００】
イベント予定データセットは、需要と同じ単位で表現されたイベント規模を含む。例えば、需要の単位が人数であれば、イベント規模も人数で表現されている。予測されたイベントが、事前登録されているイベント予定と一致しており、且つ、予測されたイベント効果とイベント規模との乖離が一定乖離を超えている場合に、当該イベント効果が、例えば需要予測部２４により補正される。これにより、需要予測の一層の高精度化が期待できる。
【０１０１】
需要予測システム１が、運行最適化システム９１０に接続されている。指定対象は、第１の駅と第２の駅を含む。需要予測において予測された需要は、第１の駅と第２の駅間での利用者数（例えば乗客数）である。運行最適化システム９１０は、指定時期について、列車本数と、列車運賃と、予測された利用者数とを基に、列車本数および列車運賃の少なくとも１つを最適化する。これにより、需要予測に基づく最適な運行計画の立案が期待できる。
【０１０２】
なお、本発明は前記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０１０３】
また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１０４】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。
【０１０５】
また、上述のイベント予測は、需要予測以外の用途にも利用可能であることが期待できる。例えば、次のようなイベント予測システムが構築されてもよい。すなわち、イベント予測システムは、イベントデータ作成部と、イベント予測部とを備えてよい。イベントデータ作成部は、過去の時系列の実績値を示す実績データを基に基準値を作成し、当該基準値との差分がしきい値を超える１以上の実績値を探し、見つかった１以上の実績値がイベントの影響を受けた実績値としたイベントデータを作成することを、複数の対象の各々について行ってよい。イベント予測部は、いずれかの対象と将来の時期との指定を受け付け、指定対象について、当該指定対象に対応したイベントデータを基に、指定時期でのイベントの発生有無と、イベントが発生するのであれば当該イベントがいずれのイベントであるかとの予測であるイベント予測を行ってよい。
【符号の説明】
【０１０６】
１：需要予測装置、２１：トレンドモデル作成部、２２：周期性モデル作成部、２３：イベントデータ作成部、２４：需要予測部
【図１】
2019168868.tif 000003
【図２】
2019168868.tif 000004
【図３】
2019168868.tif 000005
【図４】
2019168868.tif 000006
【図５（Ａ）】
2019168868.tif 000007
【図５（Ｂ）】
2019168868.tif 000008
【図６】
2019168868.tif 000009
【図７（Ａ）】
2019168868.tif 000010
【図７（Ｂ）】
2019168868.tif 000011
【図８】
2019168868.tif 000012
【図９】
2019168868.tif 000013
【図１０】
2019168868.tif 000014
【図１１】
2019168868.tif 000015
【図１２】
2019168868.tif 000016
【図１３（Ａ）】
2019168868.tif 000017
【図１３（Ｂ）】
2019168868.tif 000018
【図１４（Ａ）】
2019168868.tif 000019
【図１４（Ｂ）】
2019168868.tif 000020