IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-21
(45)【発行日】2022-10-31
(54)【発明の名称】需要予測システムおよび需要予測方法
(51)【国際特許分類】
   G06Q 50/30 20120101AFI20221024BHJP
【FI】
G06Q50/30
【請求項の数】 15
(21)【出願番号】P 2018158469
(22)【出願日】2018-08-27
(65)【公開番号】P2020035004
(43)【公開日】2020-03-05
【審査請求日】2020-12-14
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001689
【氏名又は名称】青稜弁理士法人
(72)【発明者】
【氏名】大塚 理恵子
(72)【発明者】
【氏名】大土橋 格
(72)【発明者】
【氏名】三輪 真生
(72)【発明者】
【氏名】山城 昌雄
【審査官】小原 正信
(56)【参考文献】
【文献】特開2009-230555(JP,A)
【文献】特開2014-215908(JP,A)
【文献】特開2016-091271(JP,A)
【文献】特開2004-164388(JP,A)
【文献】特開平02-299059(JP,A)
【文献】国際公開第2011/024379(WO,A1)
【文献】特開2005-038140(JP,A)
【文献】特開2010-061321(JP,A)
【文献】特開2015-219673(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
過去の時系列的な数値データである実績データを第1の時間的粒度で集計し、当該第1の時間的粒度を有し前記第1の時間的粒度の前記実績データの変動を示す第1の予測モデルを作成する第1のモデル作成部、
前記実績データを前記第1の時間的粒度より小さな第2の時間的粒度で集計し、集計した実績データを前記第1の予測モデルの前記実績データの変動成分で除算して補正することにより傾き成分を除去し、補正した実績データから当該第2の時間的粒度を有する第2の予測モデルを作成する第2のモデル作成部、
前記第1の予測モデルを用いて求めた第1の予測値と、前記第2の予測モデルを用いて求めた第2の予測値とに基づいて、将来の数値データを予測する予測部と、
を備える需要予測システム。
【請求項2】
さらに、前記実績データを所定の条件で絞り込み、絞り込んだ前記実績データを前記第2の時間的粒度より小さな第3の時間的粒度で集計し、当該第3の時間的粒度を有する第3の予測モデルを作成する第3のモデル作成部を備え、
前記予測部は、前記第1の予測値、前記第2の予測値、および前記第3の予測モデルを用いて求めた第3の予測値に基づいて、第3の時間的粒度を有する将来の数値データを予測する、
請求項1記載の需要予測システム。
【請求項3】
前記第1の時間的粒度は1年であり、前記第2の時間的粒度は1ヶ月であり、前記第3の時間的粒度は1時間である、
請求項2記載の需要予測システム。
【請求項4】
前記予測部は、
前記第1の予測値と前記第2の予測値を正規化する、
請求項1記載の需要予測システム。
【請求項5】
前記予測部は、
所定期間に対応する前記第1の予測値と、同じ所定期間に対応する複数の前記第2の予測値の合計値が、等しくなるように正規化する、
請求項4記載の需要予測システム。
【請求項6】
前記第1のモデル作成部は、
前記実績データを第1の時間的粒度で集計し、集計した実績データを複数の期間に分割し、分割した期間ごとに前記第1の予測モデルを生成する、
請求項1記載の需要予測システム。
【請求項7】
前記第1のモデル作成部は、
前記分割した期間ごとに、近似直線モデルあるいは近似曲線モデルを作成することで、前記第1の予測モデルを生成する、
請求項6記載の需要予測システム。
【請求項8】
前記第2のモデル作成部は、
前記補正した実績データからフーリエ級数モデルを用いて前記第2の予測モデルを生成し、前記傾き成分の除去では、前記フーリエ級数モデルの周波数と比較して十分低い周波数成分を除去する、
請求項1記載の需要予測システム。
【請求項9】
前記第2のモデル作成部は、
前記補正した実績データを、フーリエ級数モデル、自己回帰モデル、および移動平均モデルの少なくとも一つを用いて、前記第2の予測モデルを生成する、
請求項1記載の需要予測システム。
【請求項10】
前記第3のモデル作成部は、
前記実績データから所定条件での抽出を行い、抽出された実績データを第3の時間的粒度である一定時間単位で集計し、1日のうちの前記一定時間単位毎の比率を計算し、前記比率の配列を前記第3の予測モデルとして生成する、
請求項2記載の需要予測システム。
【請求項11】
前記実績データは、交通機関の利用実績データであって、出発地と到着地に対応付けられる利用人数、および、路線に対応する利用人数の少なくとも一つを含む、
請求項1記載の需要予測システム。
【請求項12】
前記予測部は、
前記第1の予測値および前記第2の予測値の少なくとも一つを表示装置に表示するとともに、外部情報を提示し、提示した外部情報に対応して入力された指示に基づいて、前記第1の予測値および前記第2の予測値の少なくとも一つを補正する、
請求項1記載の需要予測システム。
【請求項13】
前記予測部は、
前記外部情報の提示を、テキスト情報を前記表示装置に表示することにより行なう、
請求項12記載の需要予測システム。
【請求項14】
前記外部情報は時刻情報を含み、
前記予測部は、
前記表示装置に表示された、前記第1の予測値および前記第2の予測値の少なくとも一つが予測した予測対象時に関連する時刻情報を含む、前記外部情報を提示する、
請求項12記載の需要予測システム。
【請求項15】
収集したデータをコンピュータが処理して、需要予測を行なう需要予測方法であって、
過去の時系列的な数値データである実績データを第1の時間的粒度で集計し、当該第1の時間的粒度を有し前記第1の時間的粒度の前記実績データの変動を示す第1の予測モデルを作成する第1のステップ、
前記実績データを前記第1の時間的粒度より小さな第2の時間的粒度で集計し、集計した実績データを前記第1の予測モデルの前記実績データの変動成分で除算して補正することにより傾き成分を除去し、補正した実績データから当該第2の時間的粒度を有する第2の予測モデルを作成する第2のステップ、
前記第1の予測モデルを用いて求めた第1の予測値と、前記第2の予測モデルを用いて求めた第2の予測値とに基づいて、将来の数値データを予測する第3のステップ、
を備える需要予測方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、輸送機関を対象に交通事業者が保有しているデータや外部情報を組み合わせることにより、将来の移動需要を精度よく予測するためのシステム及び方法に関する。
【背景技術】
【0002】
鉄道事業者など輸送機関を運営する事業者にとって将来の乗客移動需要を予測することは、輸送サービスの品質向上と、高効率な運用を実現する上で重要である。特に列車の運行ダイヤや輸送設備の計画業務においては数ヵ月先から一年先、あるいは数年先のタイムスパンで乗客の移動需要を予測し、それに基づいて各路線の運行本数や、各時間帯の運転間隔などを決定していく。
【0003】
ダイヤ計画を具体化していく過程においては、車両や乗務員を管理する関係部署との調整、交渉が必要となるため、それらの関係部署にダイヤ変更の必要性や効果を説明し、納得してもらうことが重要である。また、運行本数を減らすなどの決断をする場合には、その路線の周辺地域の商業施設や自治体への説明を求められることもある。そのため、ダイヤ計画業務の担当者は、各路線や各駅の需要をできるだけ正確に、納得性の高い形で予測したいというニーズをもっている。
【0004】
現状は年一回(あるいは数年に一回)の観測調査結果を用いて乗客の移動需要に関する分析を行う手法が用いられているが、情報の更新頻度が低く、納得性の高い分析結果を得ることができていないという課題がある。
【0005】
一方、近年では鉄道事業者が所有するデータの蓄積、活用に関する取り組みが活発化しており、例えば特許文献1では過去数年分のデータを使うことにより、人の勘と経験によらず、短時間で高精度に電力需要を予測する技術が開示されている。また特許文献2には蓄積されたデータの中から入力された条件を満たすデータだけを抽出し、統計的手法により高速に予測値を出力する旅客需要予測技術が開示されている。
【先行技術文献】
【特許文献】
【0006】
【文献】特開2018-23227号公報
【文献】特開平9-230910号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
特許文献1や特許文献2の技術を用いて、鉄道路線のダイヤ計画に必要な各路線や各駅の移動需要を予測するためには路線ごと、駅ごとに過去数年分の移動履歴データが蓄積されていることが必要である。しかし現時点でそのようなデータを収集、十分に蓄積できている鉄道事業者は非常に少なく、適用可能な対象が限られる。
【0008】
新たな計測デバイスやシステムを設置し、収集する手段も考えられるが、開発コストがかかる上に、十分なデータが蓄積されるまでの期間が必要である。一方で特許文献1や特許文献2で開示されている技術は、基本的に蓄積されている過去データから典型的なパターンを作成しておき、予測値として出力するものであるため、まだデータに兆候が表れていない、遠い将来の需要予測には対応することはできない。
【0009】
本発明の目的は、かかる点を鑑みてなされたものであり、新たなシステムを追加することなく既存のデータを用いて予測した結果を用い、将来の乗客移動需要を予測することである。
【課題を解決するための手段】
【0010】
本発明の好ましい一側面は、過去の時系列的な数値データである実績データを第1の時間的粒度で集計し、当該第1の時間的粒度を有する第1の予測モデルを作成する第1のモデル作成部、実績データを第1の時間的粒度より小さな第2の時間的粒度で集計し、当該第2の時間的粒度を有する第2の予測モデルを作成する第2のモデル作成部、第1の予測モデルを用いて求めた第1の予測値と、第2の予測モデルを用いて求めた第2の予測値とに基づいて、将来の数値データを予測する予測部と、を備える需要予測システムである。
【0011】
本発明の好ましい他の一側面は、収集したデータをコンピュータが処理して、需要予測を行なう需要予測方法である。この方法では、過去の時系列的な数値データである実績データを第1の時間的粒度で集計し、当該第1の時間的粒度を有する第1の予測モデルを作成する第1のステップ、実績データを第1の時間的粒度より小さな第2の時間的粒度で集計し、当該第2の時間的粒度を有する第2の予測モデルを作成する第2のステップ、第1の予測モデルを用いて求めた第1の予測値と、第2の予測モデルを用いて求めた第2の予測値とに基づいて、将来の数値データを予測する第3のステップ、を備える。
【発明の効果】
【0012】
新たなシステムを追加することなく既存のデータを用いて予測した結果を用い、将来の乗客移動需要を予測することができる。
【図面の簡単な説明】
【0013】
図1】本実施例のシステムと輸送手段のダイヤ計画者の業務フローを示す図である。
図2】本実施例のシステム構成を示す図である。
図3】実績データ31のデータ構造を示す図である。
図4】駅・路線情報32のデータ構造を示す図である。
図5】外部情報33のデータ構造を示す図である。
図6】乗客需要データ34のデータ構造を示す図である。
図7】年単位トレンドモデル作成プログラム21のフローチャートである。
図8】季節性モデル作成プログラム22のフローチャートである。
図9A】年単位のモデルの一例を示す図である。
図9B】季節性のモデルの一例を示す図である。
図9C】時間帯別のモデルの一例を示す図である。
図10】時間帯別モデル作成プログラム23のフローチャートである。
図11A】モデルデータ35のデータ構造を示す図である。
図11B】モデルデータ35のデータ構造を示す図である。
図12】乗客需要予測の条件入力画面の一例を示す図である。
図13】乗客需要予測プログラム24のフローチャートである。
図14】シナリオデータ36のデータ構造を示す図である。
図15】乗客需要データの確認画面の一例を示す図である。
【発明を実施するための形態】
【0014】
実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【0015】
以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
【0016】
同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。
【0017】
本明細書等における「第1」、「第2」、「第3」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【0018】
図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
【0019】
本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。
【0020】
本明細書において単数形で表される構成要素は、特段文脈で明らかに示されない限り、複数形を含むものとする。
【0021】
以下詳細に説明される実施例のシステムの一例は、プログラムを実行するプロセッサと、プログラムを格納する記憶デバイスとを備える需要予測システムである。輸送手段を利用するための乗降施設および車両の一部に乗客数を検知するための計測手段が備えられており、記憶デバイスは、計測手段で部分的に計測された乗客数を格納する。プロセッサは年単位、季節性、時間帯別の傾向をあらかじめ、計算しておき、入力された補正値を組み合わせて乗客データの将来予測値を計算する。
【0022】
さらに、以上のように新たなシステムを追加することなく既存のデータを用いて予測した結果に対し、未来の都市開発計画情報を手動で入力することで納得性の高い、将来の乗客移動需要を予測する。
【0023】
実施例のシステムの一例によれば、乗降施設や車両から断片的に収集した乗客数の蓄積データを用いて、交通機関の乗客需要の傾向モデルを年単位、季節単位、時間帯別の3つの観点から作成し、さらに輸送計画作業者が補正を加えることで、より正確な将来の乗客需要を予測する。また需要予測のプロセスや結果を蓄積し、輸送計画作業者間で共有することで、関係者間の相互理解や作業の引き継ぎを円滑にする。これ以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【0024】
図1から図15を用いて、本発明の実施形態を説明する。なお、本発明の実施例は、鉄道輸送サービスを対象とするものであるが、本発明は多数人が利用する輸送手段(例えば航空機やバス)や物流分野(配送)に適用できる。
【0025】
図1は、本発明の実施例のシステムにおける、鉄道ダイヤ計画者の業務フローの概要を示した図である。
【0026】
本実施例の需要予測装置1は列車に取り付けられたセンサや、駅構内の既存設備から取得できる部分的な実績データ31を用いて、乗客需要の傾向変化を年単位・季節単位・時間帯別に分析しておき、さらに将来の都市開発計画などの外部情報33に基づき、ダイヤ計画担当者1000が入力した補正値を考慮して、計算対象とする鉄道ネットワーク上の乗客需要を予測する。
【0027】
出力された乗客需要データ34は例えば、運行ダイヤ計画システム10に入力され、ダイヤ計画担当者1000が策定した運行ダイヤ計画案のデータと組み合わせることで、各乗客の移動に関するシミュレーションを行い、計算対象とする鉄道ネットワーク上の全列車および全駅の混雑を予測することができる。
【0028】
上記のシミュレーション手法としては例えばエージェントシミュレーション技術の活用が考えられる。シミュレーションの結果、得られた混雑予測結果を比較・分析し、ダイヤ計画担当者は、より良い運行ダイヤ計画を策定する上での定量的な判断材料として活用する。
【0029】
図2は、本実施例の需要予測装置1のシステム構成を示す図である。需要予測装置1は、一般的なコンピュータ(サーバなど)である。本実施例では物理的に一つの計算機として説明するが、論理的あるいは物理的に構成された複数の計算機上で構成される計算機システムとして構成することもでき、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【0030】
需要予測装置1は、中央制御装置11、キーボード、マウス等の入力装置12、ディスプレイ等の出力装置13、通信装置14、主記憶装置15、補助記憶装置16を有する。これらはバスによって相互に接続されている。
【0031】
主記憶装置15における、年単位トレンドモデル作成部21、季節性モデル作成部22、時間帯別モデル作成部23、乗客需要予測部24は、プログラムである。以降、“○○部は”と主体を記した場合は、中央制御装置11が、補助記憶装置16から各プログラムを読み出し、主記憶装置15にロードしたうえで、各プログラムの機能(詳細後記)を実現するものとする。これらのプログラムは、予め定められた時間間隔(例えば1日おき、1週間おき、1ヶ月おきなど)に従って自動的に実行してもよいし、システム運用者が指示したタイミングで実行してもよい。これらのプログラムの詳細については後述する。
【0032】
補助記憶装置16は実績データ31、マスタデータ32、外部情報33、乗客需要データ34、モデルデータ35、シナリオデータ36を記憶する。需要予測装置1は、キーボードやマウスなどを備えており、計画者からの入力を受ける入力インタフェース及び、ディスプレイ装置やプリンタなどが接続され、プログラムの実行結果を計画者が視認可能な形式で出力する出力インタフェースを有している。
【0033】
需要予測装置1は、ネットワーク4を介して、外部システム2及び外部サーバ3と通信可能である。ここで、外部システム2とは、例えば運行ダイヤ計画システム10であり、需要予測装置1で出力した乗客需要の予測結果を送信し、より良いダイヤ計画の作成業務に活用される。また、運行ダイヤ計画システムで用いられている駅や路線の情報のマスタデータ32や、カレンダー情報を需要予測装置1で受信し、活用してもよい。
【0034】
外部サーバ3とは、例えば自動改札機が読み取った乗客の改札通過人数を集計・管理するサーバや、列車の乗車人員を収集・管理する列車情報管理サーバである。これらの外部サーバ3で収集した履歴データをネットワークを介して需要予測装置1で受信し、実績データ31として蓄積、活用する。
【0035】
需要予測装置1は、鉄道事業者が業務システムの一部として保有してもよいし、鉄道事業者とは異なるサービス事業者が保有して混雑予測結果の配信を鉄道事業者に対して行う事業形態であってもよい。
【0036】
図3は補助記憶装置16に格納される実績データ31のデータ構造を示す図である。実績データ31には鉄道事業者が保有している様々なデータが蓄積される。ここでは、その代表例として運賃収入データ311、乗車人員データ312、改札通過人数データ313を説明する。
【0037】
まず、一年単位に収集・蓄積が可能なデータの代表例として運賃収入データ311が挙げられる。運賃収入データ311は例えば年と金額の情報を含む。月別の集計結果が残っている場合は、月別の集計結果をそのまま活用してもよい。このような運賃収入の実績は、決算報告書などに開示されている情報であり、一般的には数年、あるいは十数年前まで過去にさかのぼって入手することも容易である。よって年単位のマクロな乗客需要の変化傾向をつかむには適したデータであると考えられる。
【0038】
次に乗車人員データ312について説明する。鉄道事業者は列車の位置情報や列車の車内状況のデータを運行管理システムや列車情報管理システムで管理しており、それらの外部サーバ3からネットワーク4を介して列車の情報を需要予測装置1に収集、蓄積することが可能である。例えば列車情報管理システムを活用すると、列車の位置や列車番号、列車の故障情報などが各列車から送信され、運行管理センタに集約することができる。一般的に列車にはブレーキング強弱の調整のために、列車の重量を測定できるセンサが取り付けられている。列車重量の計測値を収集し、乗客一人当たりの平均体重から列車の乗車人員情報を推定することができる。また推定した乗車人員を集計することで、乗車人員データ312として蓄積することができる。
【0039】
乗車人員データ312は例えば年、月、路線名、時間帯(1時間単位)、乗車人数の情報を含む。年別、月別に加えて日別の単位で保存してもよいし、路線名ではなく列車番号(編成)の単位で保存してもよい。その集計単位はデータソースに依存する。時間帯についても1時間単位ではなく、例えば1秒単位などデータ計測が可能な最小の粒度で保存しておき、後段の分析時に集計処理を実施してもよい。年別、月別の情報が含まれることで、少なくとも一年間を通しての季節変化を分析することが可能になる。季節変化の分析が可能なデータの他の例としては、例えば上述の運賃収入データや、定期券の発売件数などが挙げられる。いずれも月別に集計可能であることが条件になる。
【0040】
次に時間帯別の利用傾向を分析する際に活用可能な実績データの例として、改札通過人数データ313について説明する。近年、多くの鉄道の駅には自動改札機が設置されており、自動改札機が非接触型ICカード(または、同等の機能を持つモバイル端末)または磁気乗車券を読み取ることによって、乗客は駅へ入場、または出場することができる。自動改札機が読み取った情報は、ネットワークを介して、鉄道事業者が管理するデータ管理サーバ群(外部サーバ3)へ送信され、改札通過データとして蓄積される。改札通過データには、各乗客が列車を利用するために入場した駅と時刻、降車した駅と時刻等の情報が含まれるため、入場時刻の情報に基づき、例えば1時間単位で集計することで改札通過人数データ313に示すデータを蓄積することができる。集計単位は1時間単位に限定されるものではなく、元のデータの計測粒度に合わせて任意に設定することができる。
【0041】
実績データ31に含むことができる、その他のデータソースの例としては下記があげられる。
【0042】
(1)監視カメラ映像から推定した人数情報
近年、安全面から駅の改札付近やプラットホームに監視カメラが設置されるようになってきている。また監視カメラで撮影した映像から人物を検知し、ある空間に存在している人数を集計する技術も開発されている。そこで監視カメラの映像を解析して取得した乗客数のデータを収集・蓄積する。一台の監視カメラで撮影できる空間的な範囲は限られているため、一つの駅に改札付近、各プラットホーム、通路、階段など複数台の監視カメラを設置されることが一般的である。複数の監視カメラで収集したデータを加工・集計して使うことで収集範囲の拡大や、解析精度の向上につながると期待される。
【0043】
(2)公衆無線LANの接続履歴
駅や列車内で利用可能な公衆無線LANの普及に伴い、アクセスポイントが各所に設置されるようになってきている。なお、ここで公衆無線LANは鉄道事業者以外の事業者が提供するものであってもよい。公衆無線LANとは、無線LANによりインターネットへの接続を提供するサービスであり、乗客はノートPC、タブレットPC、スマートフォンなどのモバイル端末からアクセスポイントを介してインターネット接続する。一つのアクセスポイントから電波が到達可能な範囲は、一般的に数十メール程度であるため、駅などの広い空間では複数のアクセスポイントが設置される。モバイル端末が複数のアクセスポイントと交信可能な場合に混信が生じるのを防ぐため、ネットワークを識別するSSIDによって通信を行う。このため、アクセスポイント側では各モバイル端末の接続開始時刻及び接続終了時刻を取得することができる。この接続情報を用いると、ある場所における滞留人数の情報を収集、蓄積することができる。
【0044】
図4は補助記憶装置16に格納されるマスタデータ32のデータ構造を示す図である。マスタデータ32には、システムを適用する鉄道の駅・路線情報が含まれる。駅情報321は、駅ID、駅名、所有会社、所在地などの情報を含む。他に緯度経度情報や駅構内の設備情報(監視カメラの設置状況など)を含めてもよい。路線情報322は、路線ID、路線名、運営会社などの情報を含む。他に管轄区の情報などを含めてもよい。駅・路線関係情報323は路線ID、駅ID、走行順序などの情報を含む。路線を構成する駅は、基本的に実際の並び順に従って格納される。
【0045】
マスタデータ32は新しい駅や路線の追加や駅の廃止などに伴い、更新が必要となる。更新作業は実際の新駅・新線開業時にシステム運用者により実施される。また、数年先に予定されている新駅開発計画を見越した需要予測を行いたい場合には、新駅を追加した架空のマスタデータを整備する必要がある。この場合はシステム運用者もしくは需要予測装置1の利用者(ダイヤ計画作業者)が架空のマスタデータ作成作業を実施する。このように需要予測装置1では複数のマスタデータの管理が必要になる。ダイヤ計画作業者は分析の用途に応じて、マスタデータを指定し、利用することになる。
【0046】
図5は補助記憶装置16に格納される外部情報33のデータ構造を示す図である。外部情報33には、鉄道乗客需要に影響を及ぼすと考えられる、過去および将来のイベント情報や都市開発情報が格納される。具体的には例えば日付331、場所332、内容333、出典元334の情報が含まれる。
【0047】
日付331は、都市開発計画であれば、おおよその開発予定年や月、イベント情報であれば開催予定日の情報が格納される。場所332には乗客需要の変化が起こると考えられる、おおよそのエリアや駅、路線を格納する。内容333は、都市開発やイベントの具体的な情報を、出典元334にはデベロッパやイベント運営者がリリースした情報が含まれる。
【0048】
これらの外部情報はあらかじめ定義しておいたキーワードに従ってWeb情報から自動的に収集してもよいし、システム運用者やダイヤ計画作業が手動で収集または追加してもよい。また将来の開発計画やイベント情報などは時期が近付くにつれて、より詳細な情報が開示されるようになるため、定期的にメンテナンスされる仕組みがあるとよい。その際、外部情報の更新内容や更新日時も保存しておくと、開発計画やイベントの具体化の流れがわかり、需要予測作業のパラメタを決定する上で役に立つと考えられる。
【0049】
図6は補助記憶装置16に格納される乗客需要データ34のデータ構造を示す図である。乗客需要データ34には需要予測装置1がユーザ(ダイヤ計画作成者)によって入力された条件に従い、作成・出力した予測データを格納する。乗客需要データ34は例えば、ID340、年341、月342、平日と休日の別を示す平休343、出発駅ID344、到着駅ID345、出発時間帯346、人数347などの情報を含み、乗客がどこからどこへ何時頃に移動を開始するかという情報を表す。
【0050】
年341、月342、平休343、出発駅ID344、到着駅ID345の値は、月需要予測装置1のユーザ(ダイヤ計画作成者)の入力した条件から取得される。その入力画面の例は後述する。
【0051】
出発駅ID344、到着駅ID345の組み合わせは、一回のリクエストにおいて1つを対象としてもよいし、複数の組み合わせを対象としてもよい。複数の組み合わせを対象とする場合には、乗客需要データの作成単位でユニークIDを付与し、一つのまとまりとして管理できることが望ましい。例えば、図6のID2のデータは、2つの組み合わせのデータを含む。
また、出発時間帯346の時間の粒度は1時間帯毎の例で示したが、秒単位でもよいし、1分や10分など任意の単位で格納されてもよい。
【0052】
図7は年単位トレンドモデル作成プログラム21のフローチャートである。本実施形態における年単位トレンドとは、長期的な視点でみたときの1年ごとの需要の変動傾向である。例えば、月単位で集計されている実績データに対し、長期的視点として1年単位での集計を行い、年毎の需要変動をトレンドとして扱う。
【0053】
ステップS201において、年単位トレンドモデル作成部21は、マスタデータ32と実績データ31を取得する。ステップS202において、年単位トレンドモデル作成部21は年単位の期間で実績データ31を集計する。そしてステップS203において、変化点を抽出し、データを期間ごとに分割する。
【0054】
ステップS203における変化点とは、トレンドが大きく変化した時期(集計点)である。例えば、年単位で集計した結果において、年々10%の需要増加が5年続いた後、その後5年間は年々10%需要減少が続いて現在に至る場合、変化点は5年前の年となる。この場合、10年前~5年前の期間と5年前~現在の期間でデータが分割される。あるいは、曲線近似を行なって傾きが変化する点を変化点としてもよい。
【0055】
ステップS204において、分割した期間ごとに近似直線モデルあるいは近似曲線モデルを作成する。そして、ステップS205において作成したモデルをトレンドモデルとして、モデルIDを割当てモデルデータ35に記憶する。トレンドモデルの具体的イメージは後述する。
【0056】
図8は季節性モデル作成プログラム22のフローチャートである。本実施形態における季節性とは、例えば月毎の需要変動であり、7月に需要が増え、2月に需要が下がるといった毎年、定期的に繰り返される需要変動である。
【0057】
ステップS301において、季節性モデル作成部22は、マスタデータ32と実績データ31を取得する。ステップS302において季節性モデル作成部22は月単位の期間で実績データ31を集計する。ステップS303において、季節性モデル作成部22は実績データ31から年単位のトレンド成分を除算する。
【0058】
ステップS303におけるトレンド成分とは年単位トレンドモデル作成部21で作成したトレンドモデルによって算出される値である。例えば、年率10%で需要増加していくトレンドモデルであった場合、その増加率を実績データ31から除算することで、トレンドが除去され、定常性をもったデータを作成することができる。減少の場合も同様であり、すなわち、傾き成分を除去することでトレンド成分を除去する。傾き成分は、以下のフーリエ級数モデルの周波数と比較して、十分低い周波数成分ともいえる。
【0059】
そして、ステップS304において、実績データ31からトレンド成分を除算したデータを12ヶ月(1年)周期で分割する。ステップS305において、1年を一周期として分割したデータをフーリエ展開し、フーリエ級数モデルを作成する。そして、ステップS306において、作成したフーリエ級数モデルを季節性モデルとして、モデルIDを割当てモデルデータ35に記憶する。
【0060】
本実施形態では季節性モデルの作成にフーリエ展開を用いることを例として記載したが、季節性モデルの作成はフーリエ展開に限定されるものではなく、例えば自己回帰モデルや移動平均モデルなどを用いても良い。季節性モデルの具体的イメージは後述する。
【0061】
図9A図9Cは年単位トレンドモデルおよび季節性モデル、時間帯別モデルの具体的なイメージを示した図である。
【0062】
図9Aに沿って年単位トレンドモデルの具体的なイメージを説明する。図9Aにおいて、画面上の各ドットが前述したステップS202で集計した年単位の実績データであり、実線が年単位トレンドモデル作成部21で作成したモデルの値である。データは期間1(901)と期間2(902)に分割され、2つのトレンドモデルy1(903)とy2(904)が作成されている。データが2分割されているのは変化点(905)でトレンドが大きく変化しているからであり、例えば1つ前の集計値との差分が前回差分と大きく乖離した点を変化点として抽出する。年単位トレンドモデルは、例えば数年~数十年にわたる人口の増加や減少に伴う緩やかな変動を反映できる。
【0063】
図9Bに沿って季節性モデルの具体的なイメージを説明する。図9Bにおいて、画面上の各ドットが前述したステップS303で月単位の実績データ31からトレンド成分を除算したデータであり、実線が季節性モデル作成部22で作成したモデルの値である。データは1年(12ヶ月)を1周期(911)として分割され、季節性モデルy(t)(912)が作成されている。季節性モデルは、例えば夏季の休暇や期末の繁忙期など、社会的な要因による各月の変動を反映できる。
【0064】
図9Cに沿って時間帯別モデルの具体的なイメージを説明する。図9Cは、実績データ31を用いて、ある出発駅(SA駅)と到着駅(SB駅)の組み合わせについて1時間単位の乗客数の値を集計し、結果を棒グラフで示した図である。すなわちSA駅からSB駅へ向かう乗客の一日の中での傾向の変化を表している。各時間帯の乗車人員を、一日の合計乗客数(図9Cにおいて5時から23時までの合計値)で割ると各時間帯の配分率を計算できる。この配分率が時間帯別モデルの代表例の一つである。配分率は下記のような配列情報としてモデルデータ35に格納される。
1. 5時台:5.2%
2. 6時台:6.1%
・・・
19. 23時台:1.3%
時間帯別モデルは、例えば朝夕の通勤時間帯の混雑など、社会的な要因による1日の変動を反映できる。また、出発駅(SA駅)と到着駅(SB駅)の組み合わせで、どちらがオフィス街でどちらがベッドタウンかによって、異なるモデルとなることが多い。
【0065】
図10は、時間帯別モデル作成プログラム23のフローチャートである。本実施形態における時間帯別の傾向とは、上述のように一日の中での需要変動を出発駅-到着駅の組み合わせ毎に、一定の時間単位で区切って表現したものである。
【0066】
ステップS401において、時間帯別モデル作成部23は、マスタデータ32と実績データ31を取得する。ステップS402において時間帯別モデル作成部23は指定された条件(利用する実績データの種類と時期、出発駅と到着駅の組み合わせ)に従い、条件を満たすデータだけを抽出する。
【0067】
例えば、ユーザ(ダイヤ計画作成者)が「SA駅を出発し、SB駅へ到着する1時間単位の時間帯別モデルを2017年7月の実績データを用いて作成する」という条件を指定した場合に、ステップS402では実績データ31から、2017年7月の期間の実績データかつ、SA駅からSB駅までの移動を示したデータを抽出する。もしもデータがなかった場合には、エラーメッセージを表示し、プログラムを終了する。
【0068】
ステップS403において時間帯別モデル作成部23は、抽出したデータを用いて例えば一時間単位で集計し、ステップS404において、集計結果を用いて一時間単位の利用比率(配分率)を計算する。ステップS405では、求めた利用比率結果を時間帯別モデルとして、モデルIDを割当てモデルデータ35に記憶する。
【0069】
本実施形態では時間帯別モデルの作成に配分率を用いることを例として記載したが、これに限定されるものではなく、例えば回帰モデルやフーリエ展開などを用いても良い。
【0070】
図11A図11Bは、モデルデータ35のデータ構造を示す図である。モデルデータ35には年単位トレンドモデルの管理データ351、季節性モデルの管理データ352、時間帯別モデルの管理データ353、モデルデータ一覧354が格納される。
【0071】
図11A図11Bでは便宜上、それぞれテーブルを分けて記載したが、これらは全てを統合して一つのテーブルとして格納する形式でもよい。年単位トレンドモデル管理データ351にはユニークID、出発駅ID、到着駅ID、モデルID、モデルを作成するために用いたデータソースなどの情報が含まれる。他にもモデルを作成した日時や作成者、モデル作成に使われたデータソースの期間などを含めてもよい。
【0072】
出発駅IDおよび到着駅IDの値にそれぞれ、駅IDが記載されているようであれば、特定の出発駅および到着駅の組み合わせを表す。何も記載されていない場合は、全出発駅から全到着駅の組み合わせ(すなわち対象とするエリア全体)を表す。
【0073】
データソースとして運賃収入実績を用いる場合、一般的には特定の出発駅および到着駅の組み合わせでデータを収集していないため、全出発駅から全到着駅を対象としたトレンドモデルになる。データソースとして乗員データの実績を用いる場合も一般的には特定の出発駅および到着駅の組み合わせでデータを収集していないため、全出発駅から全到着駅を対象としたトレンドモデルになる。これらのモデルは、例えばある都市圏のマクロな需要動向を把握するのに有効である。
【0074】
一方で、データソースとして改札通過人数データや定期券発売枚数の実績などを用いる場合には、任意の出発駅および到着駅の組み合わせ単位で集計することができるため、出発駅ID、到着駅IDには特定の駅IDが格納される。季節性モデル管理データ352や時間帯別モデル管理データ353も年単位トレンドモデル管理データ351と同様である。
【0075】
時間帯別モデル管理データ353に格納されるモデルデータは、時間帯別の波動を表すデータであるため、時間的に最も細かい粒度の実績データを必要とする。その代表例は改札通過人数データであるが、改札通過人数データを用いる場合は日付情報や時刻情報が細かく記録されているため、それを用いることで例えば、同じ出発駅と到着駅の組み合わせであっても、月別や曜日別にデータを集計し、異なる時間帯別モデルを作成、格納することができる。
【0076】
また実績データの補足情報として、外部サーバ3から取得した外部データを活用してモデルを生成してもよい。具体的には需要に影響を与える外部要因として予想降水確率や予想気温などを予測式の説明変数に取り込んでも良い。また、天候・気候データ以外でも経済指標、SNS・メディア情報、観光統計調査結果など、様々なデータを説明変数に取り込んでも良い。
【0077】
図11Bにおいて、モデルデータ一覧354にはモデルを識別するIDと、予測式が格納されている。予測式の欄には、トレンドモデル、季節性モデル、時間帯別モデルなど、本実施形態で作成されたモデルが数式として記憶される。モデルデータ一覧354における数式とは、単回帰モデルや重回帰モデルなどの予測モデルである。例えば、年単位トレンドモデルM01の予測値をY、説明変数をXとして、Xに予測したい対象年の値を入力することで当該年の予測値を得る。季節性モデルM11では、予測値をY、説明変数をXとして、Xに予測したい対象月の値を入力することで当該月の予測値を得る。
【0078】
需要予測モデルは入力データである実績データ31を基に作成され、そのタイミングは任意である。どの実績データを用いて、なんのモデルを作るかが決まっている場合は、該当する実績データが追加されたタイミングや、年数回など定期的なタイミングで自動的にモデルを更新してもよい。または需要予測装置1のユーザや、システム運用者が個別に指定した条件でモデルデータを作成してもよい。
【0079】
上記の例では需要予測モデルは、1年を時間的粒度とする年単位トレンドモデル、1月を時間的粒度とする季節性モデル、1時間を時間的粒度とする時間帯別モデルの3階層とした。ただし、これらに代えて、あるいは加えて、他の時間的粒度(例えば1日や1週間、あるいは10年)のモデルを準備してもよい。モデルの階層は2、あるいは4以上でもよい。また、図11Aに示すように、各階層のトレンドモデルには、出発駅-到着駅の組み合わせなどにより、複数のモデルが含まれてよい。
【0080】
図12は需要予測装置1のユーザ(ダイヤ計画作成者)が乗客需要予測を行う際に条件を入力する画面の一例を示した図である。かかる画面は、乗客需要予測部24が作成し、出力装置13に表示する。画面1001内には、いくつかのテキスト入力欄や選択肢のボックスが配置されており、ユーザは各自の分析用途に応じて、入力装置12により自由にテキストを入力したり、決まった選択肢の中から、条件を選んでいく操作を行う。
【0081】
画面1001の例では例えば、上部に需要予測の目的を表すタイトル1201や、特記事項1202を入力できる欄を備えている。また、予測対象時期1203や予測対象エリア・駅(出発駅および到着駅の組み合わせ)1204を指定する欄を備えている。
【0082】
同じ分析用途で、以前にも同様の需要予測を実施している場合は、“作成済のシナリオを呼び出す”などのボタン1205から過去の作業結果(条件入力画面)を呼び出す機能があってもよい。その際、ユーザ毎に利用権限を管理している場合は、付与されているユーザID1206を用いて、自分が作業した分析結果だけを呼び出せるようにしてもよい。もしくは全ユーザの分析結果を参照できるようになっていてもよい。
【0083】
予測対象時期1203の指定は、年と月、平日/休日をそれぞれ分けて指定できてもよいし、図12の例のように年月日を一括で選択できるようになっていてもよい。予測対象エリア・駅1204についても同様に、特定の出発駅と到着駅“SA駅-SB駅”の選択肢以外に、例えば“全駅-全駅”)を指定する方法や、特定の路線全体(例えば“LA線全部”)という指定方法でもよい。また出発駅と到着駅の組み合わせが複数であってもよく、その場合は出発駅と到着駅の組み合わせリストをテキストファイルなどの形式で用意し、それをアップロードするインタフェースがあてもよい。駅や路線の他にも市町村の単位で指定する方法やユーザが自由に駅の組み合わせリストを定義する方法も考えられる。
【0084】
図12では、予測対象エリア・駅1204で“SA駅-SB駅”が選択され(SA駅のIDを10001、SB駅のIDを10002とする)、この場合、予測モデルは当該駅間を対象にするモデル(ここではトレンドモデルM03)がデフォルトで選択される。また、トレンドモデルで選択されたモデルと、条件が同じ季節性モデルと時間帯別モデル(ここでは季節性モデルM13と時間帯別モデルM22)が、デフォルトで選択される。条件とは、例えば、出発駅IDと到着駅IDの組み合わせや路線ID、データソースや数値の単位であり、これらが同じモデルを選択する。条件が同じモデルが複数ある場合には、ユーザが選択できるようにすればよい。条件が同じモデルが無い場合には、ユーザが近いものを選べるようにすればよい。
【0085】
また、デフォルトで選択されたモデルは、ユーザが変更してもよい。例えば、トレンドモデルとして、よりマクロな傾向を示す“全駅-全駅”を対象とするデータ(たとえばトレンドモデルM01)を選択し、季節性モデルと時間帯別モデルで特定駅間のモデルを選択しても良い。この場合、“全駅-全駅”の予測値を特定駅間の予測値に換算する換算テーブルを別途準備しておき、主記憶装置15に格納しておく。換算テーブルには、例えば、
「“SA駅-SB駅”の人数データ(人)=“全駅-全駅”の運賃収入データ(円)*“SA駅-SB駅”のシェア(%)/100/1人あたり平均運賃(円)」
のような変換式をあらかじめユーザが設定して格納しておく。
【0086】
画面1001の下部分は、年単位トレンドモデル・季節性モデル・時間帯別モデルを選択・編集する画面の一例である。図12の例では、モデルがグラフ表示されているが、表形式その他でもよい。画面1001ではタブ画面の構成で記載したが、ボタンなどを押すと、それぞれのモデルがポップアップ画面上に表示されるような構成であってもよい。各モデルの画面構成は共通の構成でよく、例えば年単位トレンドモデルの選択・編集画面は、下記の機能を有している。
1.モデルをリストから選択し、読み込む
2.外部情報の参照と追記、編集
3.選択したモデルの傾向と、予測値をグラフ形式などで表示
4.予測値を手動で編集し、保存
【0087】
モデルのリストは、モデルデータ35に格納されているデータにもとづいて、表示される。また外部情報は、外部情報33に格納されているデータにもとづいて、表示される。その際、“予測対象時期”の条件入力値を参照し、その前後の時期の外部情報だけを抽出して表示してもよいし、全外部情報データの一覧をユーザに提示し、ユーザが任意に選択した情報だけを画面1001上に表示してもよい。外部情報は、図12に示すようにテキストデータを表示してもよいし、テキストデータを音声として出力してもよい。あるいは、例えばニュース映像のような動画でもよい。
【0088】
画面1001では年単位トレンドモデルとしてM03が選択された場合の画面例を示している。グラフの表示方法に関しては様々なバリエーションが考えられるが、例えば、既に実績データが収集・蓄積されている期間と予測期間とを色分けして表示したり、モデル生成に用いた実績データをプロットしたり、“予測対象時期”の予測値vをハイライトしてプロットするなどが考えられる。
【0089】
この予測値vは年単位トレンドモデルM03に予測対象時期(画面1001の例では2020年)を入力して得られる値であるが、この値はあくまで過去の実績データのトレンドから導出した値である。このようなトレンドは例えば人口の自然増などに基づくが、将来の都市開発計画や大規模イベント時の乗客需要増などの要素は含んでいない。そこで予測対象時期を入力する画面1001では、この予測値vに対して、ユーザが外部情報を参照しながら、手動で調整できる機能を提供する。
【0090】
具体的にはモデルの傾向を表しているグラフや予測値vのプロット位置の付近に、編集ボタンなどを用意し、ユーザがそれをクリックすることで、新たな予測値v’を入力できる機能を備える。これにより、例えば予測対象時期において約50万人の動員数が見込まれる大規模なイベントが開催されるような状況の乗客需要を予測したい場合は、元の予測値vに対し、v+50万人の位置に新たな予測値v’を設定することができる。元の予測値vに対して新たな予測値v’を入力したという操作履歴は保存できることが望ましい。
【0091】
季節性モデルや時間帯別モデルに関しても同様に、ユーザがモデルを選択、予測値を確認し、手動で新たな予測値を入力できる機能を提供する。季節性モデルは月単位の変動を表したモデルであるため、例えば月毎の棒グラフや折れ線グラフなどが表示されている画面において、ユーザがある特定の月を選択し、外部情報を参照して、特定の月の需要予測値を増減することで新たな予測値を設定する。例えば、年末年始や夏季は休みのために例年需要が減少するとして、今年の夏は特に休みが長い場合、需要予測をさらに下方修正する。
【0092】
時間帯別モデルについても同様に、例えば1時間毎の変動を表したモデルであるならば、1時間単位の需要予測値が棒グラフや折れ線グラフで表示されている画面において、ユーザがある時間帯を選択し、手動で新たな予測値を入力することで、時間帯別モデルを調整する。例えば、朝夕は出退勤のために乗車人員が増加するが、ある年以降企業の在宅勤務の普及が想定される場合、朝夕の乗車人員を下方修正する。
【0093】
年単位トレンドモデル、季節性モデル、時間帯別モデルの編集は、特定の出発駅、到着駅の組み合わせ毎に行ってもよいし、全駅共通でもよい。例えば大規模なスポーツイベント開催時の乗客需要を予測するようなケースにおいては、開催場所や開始日時があらかじめ、決まっている場合が多いため、“出発駅を全駅”、“到着駅を開催場所の最寄駅”とし、イベント開始時刻前後の数時間の時間帯別モデルを手動で増やすことで、イベント開催日における会場最寄駅の混雑をシミュレーションするための乗客需要データを作ることができる。このようにして年単位トレンドモデル、季節性モデル、時間帯別モデルの選択と編集を終えた後、乗客需要データ作成ボタンを押すことで、需要データ生成の処理が実行される。
【0094】
図13は乗客需要予測プログラム24のフローチャートである。乗客需要予測プログラム24は、ユーザが乗客需要予測の条件入力画面で入力した条件に従って必要な予測対象エリアの乗客需要を予測し、乗客需要データ34に格納するものである。
【0095】
乗客需要予測プログラム24は、例えば乗客需要予測の条件入力を行なう画面1001において“乗客需要データ作成”ボタンが押されたタイミングで実行される。まず乗客需要予測の条件入力画面1001上で指定された条件一式を読み込む(ステップS501)。指定された条件とは予測作業のタイトル、予測対象時期、予測対象エリア・駅のことである。予測対象エリア・駅の値が、複数の出発駅および到着駅の組み合わせで構成される場合は、後段の処理を出発駅-到着駅の組み合わせ単位で繰り返す。例えば予測対象エリア・駅の値が“全駅-全駅”である場合にはマスタデータ32を参照し、駅情報321に含まれている全ての駅IDを抽出し、考えられる出発駅-到着駅の全ての組み合わせを列挙する。
【0096】
指定された年単位のトレンドモデルデータと、予測対象エリア・駅の値を参照し、モデルデータ35から該当するモデルを取得し、予測対象時期の値を代入して予測値を計算する。対象とする出発駅-到着駅の組み合わせに相当するモデルがない場合には、別の対象駅のモデル(例えば全駅-全駅)などを参照するようになっているとよい。乗客需要予測の条件入力を行なう画面1001の年単位トレンドモデル指定画面において、ユーザが手動で新たな予測値を入力している場合には、その入力値で置き換える(ステップS502)。
【0097】
同様に指定された季節性モデルデータと、予測対象エリア・駅の値を参照し、モデルデータ35から該当するモデルを取得し、予測対象時期の値を代入して予測値を計算する。乗客需要予測の条件入力を行なう画面1001の季節性モデル指定画面において、ユーザが手動で新たな予測値を入力している場合には、その入力値で置き換える(ステップS503)。
【0098】
時間帯別モデルについても指定された条件に従い、モデルデータ35から該当するモデルを取得する。乗客需要予測の条件入力を行なう画面1001の時間帯別モデル指定画面において、ユーザが手動で新たな予測値を入力している場合には、その入力値で置き換える(ステップS504)。
【0099】
年単位トレンドモデル、季節性モデル、時間帯別モデルの予測値を合成して乗客需要データを生成し(ステップS505)、1時間帯の人数予測結果を乗客需要データ34に格納する(ステップS506)。各モデルの条件が異なっている場合には、前述の換算テーブルを用いて予測値を変換して合成する。
【0100】
ステップS505では、処理S502で第1の予測モデル(年単位トレンドモデル)から導かれた第1の粒度(年単位)の予測値と、処理S503で第2の予測モデル(季節性モデル)から導かれた第2の粒度(月単位)の予測値から、特定の年の特定の月(例えば2020年7月)の予測値を求める。このとき、季節性モデルから導かれる月単位の予測値の1年分(12ヶ月分)が、年単位トレンドモデルから導かれる年単位の予測値の1年分と等しくなるように正規化する。具体的には、例えば予測したい月が2020年7月とすれば、年単位トレンドモデルで予測した2020年の予測値と、季節性モデルで予測した2020年1月から2020年12月までの予測値の合計が等しくなるようにすればよい。
【0101】
次に、ステップS505では、第2の粒度(月単位)の予測値を月の日数(例えば7月なら31)で除して日単位の予測値を求め、日単位の予測値と、処理S504で第3の予測モデル(時間帯別モデル)から導かれた第3の粒度(時間単位)の予測値から、特定の年の特定の月の特定の時間帯の予測値を求める。図9Cの予測値の例はパーセントで与えられているので、この場合には、(日単位の予測値/100)に時間当たりの予測値(%)を乗じて時間当たりの値(例えば人数や金額)を得ることができる。
【0102】
図14はシナリオデータ36のデータ構造を示す図である。シナリオデータ36には乗客需要予測の条件入力画面で指定された条件や作業内容の履歴が格納される。具体的には例えば作業毎に付与されたユニークID、作成者の情報、作業日時(乗客需要データの作成日時)、タイトル(作業の内容)、予測の条件、選択したモデル情報、予測値を編集した履歴や、作成した乗客需要データのIDなどの情報を含む。他にもシナリオ毎に他ユーザへの公開/非公開を設定できるアクセス権限情報などを含めても良い。ここで作業とは乗客需要予測の条件入力を行なう画面1001上で、様々な条件を入力し、最終的に乗客需要データ作成ボタンを押すまでの一連の流れを指しており、ボタン押し下げをトリガとして新しいIDが付与される。
【0103】
このような作業の履歴をシナリオデータ36として管理・蓄積することで、例えば同一の大規模イベントを想定した需要予測作業を複数のユーザ間で共有したり、過去の作業履歴を参照しながら少し条件を変更し、差分を分析したりすることが容易になる。また、外部情報の更新に合わせて段階的に詳細な需要予測分析を行っていく過程を記録しておくことも可能になる。例えば、図14中SC03のIDを持つシナリオデータは、SC01のシナリオデータの条件とモデルを再利用し、ただし編集はしなかったことを示している。
【0104】
図15は需要予測装置1のユーザ(ダイヤ計画作成者)が乗客需要予測を実施後に、作成した乗客需要データを確認する画面の一例を示した図である。画面1101内には、シナリオデータ36に格納された情報にもとづき、特定のシナリオを呼び出す機能(ボタンやリストボックスなど)が配置されており、ユーザは自分が作成したシナリオや、他のユーザの作業結果などを呼び出すことができる。各ユーザが、どのシナリオにアクセスできるかどうかもシナリオデータ36で管理されていることが望ましい。
【0105】
画面1101では、あるシナリオを呼び出した後、その最終出力物である乗客需要データ34を呼び出し、需要予測の作業によって、どのエリアの乗客需要がどのくらい変化したかを地図画面1102や簡易的なグラフ1103で確認できる例である。変化を見せる際には、基準値が必要となるが基準値の選び方としては、最新の実績データを参照する方法や別のシナリオで作成した需要予測結果を選ぶなどの方法が考えられ、その場合、基準値となる乗客需要データを選ぶ画面があることが望ましい。乗客需要の変化の見せ方についても場所別、時間帯別に確認できる機能があるとよい。
【0106】
以上に説明したように、本発明の実施例によると蓄積データから作成した、交通機関の乗客需要の傾向モデルに対して輸送計画作業者が外部情報を参照して、補正を加えることで、より正確な将来の乗客需要を予測し、保存、共有することができる。これにより、鉄道事業者は将来の乗客需要データを用いて、混雑緩和施策(例えばダイヤ改正)を立案する際の基礎データとして利用できる。また運賃収入データや改札通過データ、監視カメラの映像、公衆無線LAN接続情報など、入手可能なデータソースのいずれか、もしくは組み合わせにより乗客需要の傾向モデルを作成するため、多額の設備投資をすることなく、将来の乗客需要を知ることができる。
【0107】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【0108】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、SSD(Solid State Drive)等の記憶装置、又は、ICカード、SDカード、DVD等の記録媒体に格納することができる。
【0109】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
図1
図2
図3
図4
図5
図6
図7
図8
図9A
図9B
図9C
図10
図11A
図11B
図12
図13
図14
図15