JP2022098823A - データ処理方法、データ処理システム - Google Patents

Abstract

【課題】通常時に加えてイベント開催時も対象とし、現在もしくは近い将来の駅構内の滞留人数を精度良く推定、予測できるデータ処理方法及び処理システムを提供する。【解決手段】入力装置、出力装置、処理装置及び記憶装置を備えた情報処理装置により改札口と列車の進入及び退出経路を備える駅構内の滞留人数を計算するデータ処理システムであって、列車に乗車して駅構内に進入する第１の乗員人数を反映した値ａ１と列車に乗車して駅構内を退出する第２の乗員人数を反映した値ｂ１から前記値ａ１の統計値及び前記ｂ１の統計値との差分を求め、路線方面別の配分比率および乗換者数を更新するモジュールと駅構内に改札口から入場する入場者数を反映した値ＩＮ及び駅構内を改札口から出場する出場者数を反映した値ＯＵＴと路線方面別の配分比率と乗換者数から滞留人数を計算する滞留人数計算モジュールと、を備える。【選択図】図１

Description

新規性喪失の例外適用申請有り

本発明はデータを処理する方法および当該方法を実行するデータ処理システムを対象とし、特に列車の荷重データおよび駅の改札通過データを用いて、通常時に加えてイベント開催時における駅構内の滞留人数を予測する技術に関する。

鉄道事業者にとって駅の混雑状況を把握することは、安全な輸送サービスを実現する上で非常に重要である。また、利用者にとっても利用予定の駅や列車の混雑を事前に知ることができれば、混雑を避けて別の駅を使う、駅を利用する時間帯を変更する、などの代替策を検討することができるため、有意義である。特にイベント会場の最寄り駅などにおいては、イベント開催前後に局所的な混雑が発生することにより、利用者の安全性や運行の安定性に関してのリスクが高まる。

近年、都市部の一部の駅では、監視カメラなどが設置されており、鉄道事業者がプラットフォーム上の混雑などを遠隔地からでもリアルタイムに、把握することができるようになっている。監視カメラを設置することは、改札口付近やエスカレーターの乗降場所など特定のエリアの混雑を把握する際には有効な手段といえるが、駅全体の混雑度を正確に把握するためには、駅構内において監視カメラを死角なく全てに配置する必要があり、コスト面や、乗客へのプライバシー配慮の面で難しい課題がある。また監視カメラ映像の分析技術を用いて人物検知、人物追跡などを行い、混雑を推定する手法も考えられるが、この方法では設置したカメラ毎にパラメタ調整が必要になり、即時的に数百、数千の駅へ展開し、運用を継続することは困難である。

一方、列車の混雑については、車両の荷重センサから得られたデータを用いて求める方法が広く知られている。例えば、車両重量と、乗客一人当たりの平均重量を利用して、列車の乗車率を算出する技術が知られている。また、乗車位置・区間にあわせた停車駅の情報（乗換路線、ホーム案内図、駅構内図）や乗車中（走行中）の列車の各車両の混雑状況や車内温度を、乗客向けにリアルタイムに提供するサービスも実用化されている。

また駅に設置された自動改札機の通過記録を利用する技術も知られている。例えば、未来の乗客流動を予測するために、自動改札機の通過記録を集計しておき、予測当日の実測値と照らし合わせて、統計的に類似のパターンを抽出することで当日の流動予測に活用する技術が知られている。

また駅の改札口の通過人数と列車の乗員人数の差分から駅構内の滞留人数を推定、予測する技術も知られている。特許文献１にはリアルタイムに取得した列車の乗員人数データと対象駅の入出場者数の統計値を組み合わせることで、近似的に駅構内の滞留人数（列車の乗車人数と降車人数の合計）を求める技術が開示されている。

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

駅の混雑状況を示す重要な指標の一つに、駅構内に滞留している滞留人数が挙げられる。ある時刻前後の滞留人数は、列車に乗車する人と列車から降車する人の合計値で考えることができる。そして、上述したように、車両の荷重データを用いると、各駅間において、おおよそ何人の乗客が列車に乗車中であるかを把握することができる。

しかし、ある駅で何人乗車し、何人降車したかという内訳は分からない。例えば、ある列車から５００人が降車し、さらに５００人が乗車したとすると、列車の乗員人数はプラスマイナスゼロになるため、車両の荷重データ上は変化がないままであるが、その時刻前後における駅の滞留人数は、乗車する人と降車する人の合計値として考えるので、合計１０００人である。従って、車両の荷重データだけから駅の滞留人数を推定することは困難である。

ここで、一つの路線しか乗り入れのない単純な駅においては、改札から入場した乗客は数分以内には、ほぼ必ず、列車に乗るであろうということが想像できる。同様に、列車から降車した乗客についても、大多数は数分以内に改札を出場すると考えられる。従って、改札の入場者数≒列車の乗車人数、改札の出場者数≒列車の降車人数の関係が成り立つ。そこで、リアルタイムに取得した列車の荷重データに加えて、対象駅の改札入場者数や改札出場者数の値を用いることで、駅構内の滞留人数（列車の乗車人数と降車人数の合計）を求めることができる。

また、上述したように、過去データから求めた統計的な入場者数および出場者数のパターンと、当日の改札通過記録により、予測値（すなわち、未来の乗客流動）を算出することができるが、これは改札機の通過記録が、ほぼリアルタイムに取得可能な場合においてのみ有効な手段であり、そのようなリアルタイムデータ取得に対応している改札機は、日本では、まだほとんど例がない。

そして、特許文献１に記載されている手法では、駅の滞留人数を列車の乗車人数と降車人数の和と定義し、列車の乗車人数と改札入場者数、列車の降車人数と改札出場者数が、それぞれ近似的に等しいとみなすことで、過去データから求めた統計的な改札入出場者数の値により、駅構内の滞留人数を計算することができる。しかし、この手法ではイベント開催時など、改札入出場者数の値が統計値と大きく外れるような場合に、精度の良い推計・予測ができないという問題がある。

本発明はかかる点に鑑みてなされたものであって、通常時に加えてイベント開催時なども対象として、現在もしくは近い将来の駅構内の滞留人数を、精度良く推定、予測することができるデータ処理方法、および、データ処理システムを提供することを目的とする。

本発明の一側面は、入力装置、出力装置、処理装置、および、記憶装置を備えた情報処理装置により、所定領域の混雑度を計算するデータ処理方法である。この方法では、滞留人数を移動体への乗車人数と移動体からの降車人数の和と定義し、乗車人数は、所定領域に入場する入場者数を反映した値ＩＮと路線方面別の配分比率の積と、乗換先の移動体に乗って所定領域内で移動体を乗り換える乗換者数の和と等しいものとし、降車人数は、所定領域を出場する出場者数を反映した値ＯＵＴと路線方面別の配分比率の積と、乗換元の移動体を降りて所定領域内で移動体を乗り換える乗換者数の和と等しいものとし、移動体に乗車して所定領域に進入する第１の乗員人数を反映した値ａ１を取得する第１ステップ、移動体に乗車して所定領域を退出する第２の乗員人数を反映した値ｂ１を取得する第２ステップ、前記値ＩＮ、および、前記値ＯＵＴを取得する第３ステップ、前記値ａ１と前記値ｂ１、および、前記値ａ１の統計値と前記値ｂ１の統計値の差分から、路線方面別の配分比率および所定領域内で移動体を乗り換える乗換者数を更新する第４ステップ、前記値ＩＮおよび前記値ＯＵＴと、更新された路線方面別の配分比率および更新された乗換者数から、滞留人数を計算する第５ステップ、を備える。

本発明の他の一側面は、入力装置、出力装置、処理装置、および、記憶装置を備えた情報処理装置により、改札口と列車の進入および退出経路を備える駅構内の滞留人数を計算する、データ処理システムである。このシステムは、列車に乗車して駅構内に進入する第１の乗員人数を反映した値ａ１と、列車に乗車して駅構内を退出する第２の乗員人数を反映した値ｂ１から、前記値ａ１の統計値および前記値ｂ１の統計値との差分を求め、路線方面別の配分比率および乗換者数を更新する計算モジュールと、駅構内に改札口から入場する入場者数を反映した値ＩＮ、および、駅構内を改札口から出場する出場者数を反映した値ＯＵＴと、前記路線方面別の配分比率から、滞留人数を計算する滞留人数計算モジュールと、を備える。

さらにこのシステムは、イベント開催時の動員人数情報から単位時間あたりの改札入場者数および改札出場者数の変化を予測する改札入出場者数予測モジュールを備えてもよい。

計算の典型的な具体例としては、駅構内の滞留人数を移動体への乗車人数と移動体からの降車人数の和と定義し、乗車人数と降車人数のそれぞれについて計算を行う。さらに乗車人数は改札から入場して列車に乗る人と、改札から入場せず、他の路線から駅に到着して乗換目的で列車に乗る人の２種類で構成されると考えてそれぞれ計算を行う。同様に、降車人数は列車から降りて改札を出場する人と、改札を出場せず、ある路線から他の路線に乗り換える乗換目的で降車する人で構成されると考えてそれぞれ計算を行う。

典型的な他の具体例としては、値ａ１およびｂ１は、移動体の荷重センサから得られたデータに基づいて取得することができる。

他の例としては、値ａ１、ｂ１、ＩＮ、ＯＵＴは、過去のデータを用いて、過去の混雑度や滞留人数を計算してもよい。また他の例としては、値ａ１、ｂ１、ＩＮ、ＯＵＴは、最新のデータを用いて、現在の混雑度や滞留人数を計算してもよい。さらに、他の例ではＩＮ、ＯＵＴとして、過去のデータから推定した値にイベント時の需要を加算して計算してもよい。また、他の例として、これらの値を予測モデルに入力し、他の時点の混雑度や滞留人数を計算してもよい。

以上の構成は、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。

本発明によれば、通常時に加えてイベント開催時なども対象として、現在もしくは近い将来の駅構内の滞留人数を、精度良く推定、予測することができるデータ処理方法、および、データ処理システムを提供することができる。

実施形態を実施するシステムにおいて取得するデータ群の関係を説明する説明図である。 実施形態を実施するシステム全体の基本構成図である。 駅・路線情報を格納するレコードの構造を説明する表図である。 車両位置および列車乗員人数を格納するレコードの構造を説明する表図である。 改札入出場者数データを格納するレコードの構造を説明する表図である。 統計値を格納するレコードの構造を説明する表図である。 統計値を格納するレコードの構造を説明する表図である。 イベント見込み人数データを格納するレコードの構造を説明する表図である。 駅滞留人数計算結果データを格納するレコードの構造を説明する表図である。 列車の乗員人数を集計する処理手順を示す流れ図である。 改札入出場者数を各路線・方面の乗降者数に配分する処理手順を示す流れ図である。 乗換人数を更新する処理手順を示す流れ図である。 改札入出場者数を予測する処理手順を示す流れ図である。 駅の滞留人数を予測する処理手順を示す流れ図である。 混雑状況表示ツールの条件設定画面の例を示す平面図である。 操作端末に情報配信を行う処理手順を示す流れ図である。 情報配信画面を作成する処理手順を示す流れ図である。 乗客や鉄道事業者、システム運用者向けに配信される混雑状況可視化画面の例を示す平面図である。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。以下、図１から図１７を用いて本発明の実施形態を説明する。

図１は、駅の滞留人数を推定するために必要な改札入出場者数データ、駅間を走行中の列車の乗員人数、駅で列車から乗り降りする乗員人数データとの関係性を示す図である。近年、走行中の列車（車上）から、現在の列車の位置情報などを一定周期で地上のセンターサーバに伝送する列車無線システムの導入が進んでいる。また、ほとんどの列車には、車両毎の重量に応じて加減速の度合を制御する目的で、応荷重装置が取り付けられている。各駅間を通過する度に、応荷重装置で取得した重量データから、その時点で列車に乗車している人数（「乗員人数」という）のおおよその数を計算することができる。例えば、乗員人数は、一人あたりの体重が６０ｋｇであると仮定して、応荷重装置で取得した重量を前記の体重で割って得られる商より計算することができる。そして、図１に示すように、列車から数秒おきに伝送された列車位置、駅間における乗員人数などの情報が、地上側サーバで収集、蓄積される。

列車の位置情報および乗員人数情報により、どの駅と駅の間（「駅間」という）を列車が走行中か、もしくはどの駅に列車が停車中かといった列車の状態と、それぞれの状態において何人の乗客が乗車しているかを検知することが可能になる。これにより、例えば、Ａ路線上り方面の列車Ｔｒ１が駅ＳＴ１と駅ＳＴ２の間を走行している時の列車乗員人数をａ１、駅ＳＴ２と駅ＳＴ３の間を走行している時の列車乗員人数をｂ１、Ａ路線下り方面の列車Ｔｒ２が駅ＳＴ３と駅ＳＴ２の間を走行している時の列車乗員人数をａ２、駅ＳＴ２と駅ＳＴ１の間を走行している時の列車乗員人数をｂ２というように、各列車の一連の動きと乗員人数の変化を追跡することができる。なお、列車位置情報は例えば起点からの距離（ｍ）や、緯度・経度で示すことができる。

ここで列車Ｔｒ１と列車Ｔｒ２が、ほぼ同時刻に駅ＳＴ２に停車すると仮定した時、その停車時間帯において、駅ＳＴ２と各列車の間で乗客の乗り降りが発生する。ある時刻（または時間帯）における駅の混雑度を評価する場合、その時刻（または時間帯）において、駅構内に存在する人の数（「滞留人数」という）を指標とすることができる。ここで駅ＳＴ２の総滞留人数Ｐｓｔａｙは、駅ＳＴ２から列車に乗る人数（「乗車人数」という）Ｐｇｅｔ_ｏｎと列車から降りる人数（「降車人数」という）Ｐｇｅｔ_ｏｆｆの和と考えられ、数１の関係式が成り立つ。

ここで複数の路線方面の列車が停車する駅においては、乗車人数Ｐｇｅｔ_ｏｎは、各路線方面の列車の乗車人数の和になる。すなわち、図１の例においては、列車Ｔｒ１に係るＰＢ１と、列車Ｔｒ２に係るＰＢ２と、の和となる。その一方で、降車人数Ｐｇｅｔ_ｏｆｆも、各路線方面の列車の降車人数（例えばＰＡ１とＰＡ２）の和になると考えられる。すなわち、図１の例においては、列車Ｔｒ１に係るＰＡ１と、列車Ｔｒ２に係るＰＡ２と、の和となる。

図１においては、駅ＳＴ２には、２つの路線方面の列車（すなわち、Ａ路線上り方面の列車Ｔｒ１、および、Ａ路線下り方面の列車Ｔｒ２）が停車する。ここで、Ａ路線上り方面の列車Ｔｒ１と下り方面の列車Ｔｒ２の間で乗り換える乗客はいないと見なしたとき、駅ＳＴ２に改札から入場する人数（「改札入場者数」という）をＩＮ（Ｐｅｎｔｅｒ）とすると、ＩＮ（Ｐｅｎｔｅｒ）は、Ａ路線上りホームの列車Ｔｒ１に乗る人（ＰＢ１）と、Ａ路線下りホームの列車Ｔｒ２に乗る人（ＰＢ２）の和で構成される。同様に、改札から出場する人数（「改札出場者数」という）をＯＵＴ（Ｐｅｘｉｔ）とすると、ＯＵＴ（Ｐｅｘｉｔ）は、Ａ路線の上りホームの列車Ｔｒ１から降りる人（ＰＡ１）とＡ路線の下りホームの列車Ｔｒ２から降りる人（ＰＡ２）の和で構成される。

そして、ＰｅｎｔｅｒやＰｅｘｉｔを配分することで、複数の路線方面の列車が停車する駅における、それぞれの路線方面の列車に乗る人および降りる人を計算することができる。図１の例においては、Ｐｅｎｔｅｒ（すなわち、改札入場人数）を配分することで、Ａ路線上りホームで列車Ｔｒ１に乗車する人数と、Ａ路線下りホームで列車Ｔｒ２に乗車する人数と、をそれぞれ計算することができる。また、Ｐｅｘｉｔ（すなわち、改札出場人数）を配分することで、Ａ路線上りホームで列車Ｔｒ１から降車する人数と、Ａ路線下りホームで列車Ｔｒ２から降車する人数と、をそれぞれ計算することができる。ここで、ＰｅｎｔｅｒやＰｅｘｉｔを配分するための比率（配分比率）については、改札入出場者の入場駅および出場駅の組み合わせに対して、あらかじめ、経路検索エンジン等で代表的な利用経路を割り当てることで、平均的な配分比率を集計することができる。

また、駅構内に複数の路線が停車し、かつ、乗換客が存在する駅（つまり、同一の駅において列車の乗り換えが発生すると考えられる駅）については、上記の改札入場者数の配分および改札出場者数の配分に加えて、乗換者数も考慮しなければならない。乗換者数についても改札入出場者の入場駅および出場駅の組み合わせに対して、あらかじめ、経路検索エンジン等で代表的な利用経路を割り当て、乗換駅に着目して通過人数を集計することで、平均的な乗換者数を求めることができる。

ここで近年、改札入出場者数のデータを短い時間周期で地上のセンターサーバに伝送し、現在時刻に対して十数分前の改札入出場者数のデータを取得できるオンラインシステムの導入が進んでいる。そして、このような、ほぼリアルタイムに取得できる改札入出場者数のデータを用いて、上記の路線方面への配分を行うことができ、これにより、各ホームの乗車人数や降車人数を、更に高精度に計算することができる。

ただし、例えば列車が運行乱れなどにより、予定どおりに駅ＳＴ２に到着しないなどの事象が発生した場合、上記の統計的な路線方面の配分比率を用いた手法では、実際には降りる人がいないホームでも降車人数が計算されてしまうという課題がある。

そこで駅間を走行中の列車の乗員人数ａ１、ａ２、ｂ１、ｂ２と、列車乗員人数の統計値（すなわち、前記のａ１、ａ２、ｂ１、ｂ２の統計値）との差分を利用して（つまり、現在の列車の乗員人数の値と、統計上の列車の乗員人数の値と、の数値と数値の間のひらきを利用して）、列車を乗り降りする人数を調整する。すなわち、通常時より駅間の列車の乗員人数が多い場合（つまり、統計値の列車の乗員人数の方が少なくなる場合）は、その路線方面の列車に乗り降りする人数を多くし、その逆に通常より列車の乗員人数が少ない場合（つまり、統計値の列車の乗員人数の方が大きくなる場合）は、その路線方面の列車に乗り降りする人数を少なくするなどの調整を行うことで、上記の課題を解決することができる。

このような観点から、駅ＳＴ２の乗車人数Ｐｇｅｔ_ｏｎと降車人数Ｐｇｅｔ_ｏｆｆのそれぞれに関して、下記の数式２のように考えることができる。すなわち、リアルタイムに取得した改札入出場者数を示すＰｅｎｔｅｒ_ｒｔ、Ｐｅｘｉｔ_ｒｔ、路線方面の配分比率の統計値を示すＲｅｎｔｅｒ_ｓｔａ、Ｒｅｘｉｔ_ｓｔａ、乗換目的で駅ＳＴ２を利用する乗換客のうちで乗換先の列車の乗車人数を示すＰｔｒａ_ｇｅｔｏｎ_ｓｔａ、乗換元の列車の降車人数を示すＰｔｒａ_ｇｅｔｏｆｆ_ｓｔａ、列車の乗員人数と、列車の乗員人数の統計値との差分を示すＴＬｄｉｆｆ_ｒｔとすると、下記の数２の関係式が成り立つ。ここで、ＴＬｄｉｆｆ_ｒｔは、実際の列車の乗員人数と、統計値の列車の乗員人数と、の差分（すなわち、実際の列車の乗員人数と、統計値の列車の乗員人数と、のひらき）が適切に評価されれば特に限定されないが、例えば、「当日における列車の乗員人数の平均値÷列車の乗員人数の統計値」で求められる値とされる。図１の例（すなわち、２つの路線を走行する列車に対して乗り降りが発生する場合）では、ＴＬｄｉｆｆ_ｒｔの値は、一例として、列車乗員人数ａ１と該ａ１の統計値の商、および、列車乗員人数ｂ１と該ｂ１の商を用いて、決定することができる。この場合、決定したＴＬｄｉｆｆ_ｒｔの値を用いて、列車Ｔｒ１に運行乱れなどが発生した場合であっても、より確からしい計算を行うことができる。

上記の数１および数２の関係式は、現在の駅構内における滞留人数を推計するだけでなく、未来の時刻での駅構内における滞留人数の予測にも拡張することができる。

未来の時刻での駅ＳＴ２における総滞留人数をＰｐｒｅｄ_ｓｔａｙとする場合、Ｐｐｒｅｄ_ｓｔａｙは、予測したい時刻での駅ＳＴ２における乗車人数であるＰｐｒｅｄ_ｇｅｔ_ｏｎと、予測したい同時刻での駅ＳＴ２における降車人数であるＰｐｒｅｄ_ｇｅｔ_ｏｆｆの和になると考えられる。従って、下記の数３の関係式が成り立つ。

同様にして、未来の時刻での駅ＳＴ２における乗車人数の予測値であるＰｐｒｅｄ_ｇｅｔ_ｏｎと、未来の同時刻での降車人数の予測値であるＰｐｒｅｄ_ｇｅｔ_ｏｆｆは、未来の時刻に対して予測した改札入出場者数を示すＰｐｒｅｄ_ｅｎｔｅｒ、Ｐｐｒｅｄ_ｅｘｉｔ、路線方面の配分比率の統計値を示すＲｅｎｔｅｒ_ｓｔａ、Ｒｅｘｉｔ_ｓｔａ、乗換目的で駅ＳＴ２を利用する乗換客のうちで、乗換先の列車の乗車人数を示すＰｔｒａ_ｇｅｔｏｎ_ｓｔａ、乗換元の列車の降車人数を示すＰｔｒａ_ｇｅｔｏｆｆ_ｓｔａ、列車の乗員人数と、列車の乗員人数の統計値との差分を示すＴＬｄｉｆｆ_ｒｔとすると、数４の関係式によって求められる。

ここで、未来の時刻に対する改札入出場者数であるＰｐｒｅｄ_ｅｎｔｅｒ、Ｐｐｒｅｄ_ｅｘｉｔは、下記の数５の関係式から求められる。すなわち、Ｐｐｒｅｄ_ｅｎｔｅｒ、Ｐｐｒｅｄ_ｅｘｉｔは、改札入出場者数データの過去分から求めた統計値であるＰｅｎｔｅｒ_ｓｔａ、Ｐｅｘｉｔ_ｓｔａにイベント開催時に増加が見込まれる改札入出場者数であるＰｅｖｅｎｔを加算した値を基準値とする。そして、リアルタイムに取得した改札入出場者数であるＰｅｎｔｅｒ_ｒｔ、Ｐｅｘｉｔ_ｒｔとの差分であるＰｅｎｔｅｒ_ｄｉｆｆ_ｒｔ、Ｐｅｘｉｔ_ｄｉｆｆ_ｒｔで調整することによって求められる。

ここで、Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔは、例えば、リアルタイムに取得したＰｅｎｔｅｒ_ｒｔと現在時刻の（Ｐｅｎｔｅｒ_ｓｔａ＋Ｐｅｖｅｎｔ）との商で求めることができる。すなわち、統計値とイベント需要から求めた入場者数の予測値に対して、現在の改札入場者数との比率を求め、比率が高ければ（予測していた値より、現実の数値の方が多ければ）、この先もその傾向がしばらく続くものとして、入場者数の予測値が多くなるように調整する。Ｐｅｘｉｔ_ｄｉｆｆ_ｒｔについても、リアルタイムに取得したＰｅｘｉｔ_ｒｔを用いて、Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔの場合と同様にして求めることができる。

上記の説明より、数３～数５の式を、未来の時刻での滞留人数を予測するための予測モデルとして利用することができる。

図２は、駅の滞留人数を推定するシステムの全体構成図である。近年、多くの鉄道の駅において、自動改札機（１０２）が設置されるようになり、鉄道を利用する乗客（利用者１０１）は、非接触型ＩＣカードや、あるいは同等の機能を持つ携帯端末、磁気乗車券を、自動改札機（１０２）に読み取らせることにより、駅への入場、駅からの出場を行っている。自動改札機（１０２）で読み取った情報は、ネットワーク（１０７）を介して、鉄道事業者（１１６）が管理する履歴管理サーバ（１０８）へ送信される。また、列車（１０３）からは、前記の列車無線システムを介して、車両位置データや乗員人数データ（列車の乗員人数）などが履歴管理サーバ（１０８）に送信される。

次に、本実施形態での駅滞留人数推定システム（１０５）について詳しく説明する。なお、本実施形態を説明する際に直接関係しない車両、自動改札機（１０２）などの機能や構成、データ処理技術については説明を省略する。

駅滞留人数推定システム（１０５）は、データサーバ（１１１）、計算サーバ（１１２）、情報配信サーバ（１１３）からなる。これらのサーバ群（１１１、１１２、１１３）からなる駅滞留人数推定システム（１０５）は、ネットワーク（１０７、１１４）を介して、鉄道事業者（１１６）や情報利用者（１１５）と通信することができる。ここで、情報利用者（１１５）は、駅の滞留人数について、駅滞留人数推定システム（１０５）に照会する者である。従って、情報利用者（１１５）は、一例として、駅の利用者（１０１）であってもよい。また、駅滞留人数推定システム（１０５）は、改札通過履歴やリアルタイムの車両情報を収集、蓄積し、分析処理を行うことができる。

車両位置データや列車乗員人数データ、改札通過データは、データの蓄積と同時、もしくは一時間おきや一日おきなど適当なタイミングで、ネットワーク（１０７）を介して、必要な部分に関してデータサーバ（１１１）へ送信される。そして、データサーバ（１１１）は、ネットワーク（１０７）を介して車両位置・列車乗員人数（１２３）、改札入出場者数（１２４）をそれぞれの更新間隔に従って受信し、サーバ内のデータ格納部（１２１）に記録する。

また、受信したデータは集計され、列車乗員人数や改札入出場者数の統計値（１２５）として、データ格納部（１２１）に記録される。データサーバ（１１１）には、駅および路線のネットワーク情報を表す駅・路線情報（１２２）や、イベント開催時の見込みの動員人数であるイベント見込み人数（１２６）、駅の滞留人数の計算結果である滞留人数計算結果（１２７）などのデータも記録される。なお、駅・路線情報（１２２）やイベント見込み人数（１２６）に変更があった場合、適宜にシステムの外部から入力され、データサーバ（１１１）は、データの更新と記録を行う。

計算サーバ（１１２）は、データサーバ（１１１）に蓄積されたデータ群を用いて、駅の滞留人数を算出する処理と、その結果を格納する処理を行う。計算サーバ（１１２）は、主にネットワークインタフェース（Ｉ／Ｆ（Ａ））（１３０）、ＣＰＵ（１３１）、メモリ（１３２）、記憶部（１３３）からなる。

ネットワークインタフェース（Ｉ／Ｆ（Ａ））（１３０）は、ネットワークに接続するためのインタフェースである。

記憶部（１３３）は、例えばハードディスクドライブやＣＤ－ＲＯＭドライブ、フラッシュメモリなどの記憶装置である。記憶部（１３３）には、列車乗員人数集計プログラム（１３４）、乗降人数配分比率更新プログラム（１３５）、乗換人数更新プログラム（１３６）、改札入出場者数予測プログラム（１３７）、駅の滞留人数計算プログラム（１３８）などのプログラム群と、計算処理の過程で得られた結果を格納するデータ格納部（１３９）が含まれている。なお、記憶部（１３３）は、複数の記録装置から構成されてもよく、複数の記録装置に各種プログラム、各種データを分割して記録するようにしてもよい。

各プログラム群（１３４～１３８）が実行される際には、計算サーバ（１１２）は、分析対象となるデータをデータサーバ（１１１）から読み出してメモリ（１３２）へ一時的に格納し、ＣＰＵ（１３１）で各プログラム（１３４～１３８）をメモリに読み出して実行する。これにより、各種機能を実現する。これらのプログラム（１３４～１３８）は、車両位置データや乗員人数データを新たに取得し、データサーバ（１１１）に格納されたタイミングで実行してもよいし、数秒おき、数分おきなどあらかじめ、決められた時間間隔に従って（つまり、決められた時間間隔でのタイミングで）、自動的に処理を実行してもよい。

本実施形態では計算や制御等の機能は、記憶装置に格納されたプログラムがプロセッサによって実行されることで、定められた処理を他のハードウエアと協働して行う。なお、計算機などが実行するプログラムまたはその機能を実現する構成を、本明細書では「機能」、「手段」、「部」、「モジュール」等と呼ぶ場合がある。

情報配信サーバ（１１３）は、ネットワークインタフェース（Ｉ／Ｆ（Ｂ））（１４５）、ＣＰＵ（１４６）、メモリ（１４７）、記録装置（１４８）を備える。

ネットワークインタフェース（Ｉ／Ｆ（Ｂ））（１４５）は、ネットワークに接続するためのインタフェースである。

記録装置（１４８）は、各種プログラム、各種データを記録することができ、例えば、ハードディスクドライブやＣＤ－ＲＯＭドライブ、フラッシュメモリなどの記録媒体である。なお、複数の記録媒体に各種プログラムが記録されてもよい。また、各種データを分割し、分割されたデータが複数の記録媒体に記録されてもよい。

情報配信サーバ（１１３）は、利用者の照合、画面表示に関する条件設定、駅の滞留人数推定結果の参照を行うためのサーバである。システム運用者（１１９）、鉄道事業者（１１６）、情報利用者（１１５）は、情報端末（１１７、１１８、１２０）を用いて、ネットワーク（１１４、１５１）を介して情報配信サーバ（１１３）にアクセスすることができる。

記録装置（１４８）には条件取得プログラム（１４１）と、情報配信プログラム（１４２）と、が含まれる。ＣＰＵ（１４６）は、記録装置（１４８）に記録されている各種プログラム（１４１、１４２）をメモリ（１４７）に読み出して実行することにより各種機能を実行する。情報配信サーバ（１１３）からの情報は、基本的に各情報利用者（１１５）等が能動的にアクセスしたタイミングで取得される。

また、駅滞留人数推定システム（１０５）を運用するシステム運用者（１１９）は、情報端末（１２０）を用いてネットワーク（１５１）を介し、各種の蓄積データの構成や状況、計算サーバ（１１２）の状況や計算結果、情報利用者（１１５）からの検索リクエスト状況などを確認することができる。

図３は、データサーバ（１１１）内に格納される駅・路線情報（１２２）のデータ構造について示した図である。駅・路線情報（１２２）は、駅ＩＤ（２０１）、路線・方面ＩＤ（２０２）、停車順序（２０３）、路線名（２０４）、ホーム名（２０５）、番線名（２０６）、緯度（２０７）、経度（２０８）などの情報を含み、各路線の停車駅や、路線、駅の地理的な位置情報などを表すデータである。

駅・路線情報（１２２）は、変更があった場合に、鉄道事業者（１１６）もしくはシステム運用者（１１９）がシステムの外部から入力することで、その内容が更新され記録される。また、例えば、駅・路線情報（１２２）が曜日によって異なるような場合には、複数のテーブルを保持しておき、保持された複数のテーブルが、データ処理の対象日の曜日に応じて切り替えられてもよい。

図４は、データサーバ（１１１）内に格納される車両位置・列車乗員人数（１２３）のデータ構造について示した図である。車両位置・列車乗員人数（１２３）は、路線・方面ＩＤ（２２１）、列車ＩＤ（２２２）、取得日時（２２３）、駅１（２２４）、駅２（２２５）、乗員人数（２２６）などの情報を含み、車両から新たなデータを受信したタイミングで更新される。なお、車両位置・列車乗員人数（１２３）は、履歴管理サーバ（１０８）からデータを受信したタイミングで更新されてもよい。

取得日時（２２３）は、列車から車両情報を受信した時刻を表す。また駅１（２２４）および駅２（２２５）は、列車がどの駅間に在線しているかを表す。駅１（２２４）と駅２（２２５）が同一である場合は、列車が駅１（２２４）に停車中であることを表す。乗員人数（２２６）は、駅１（２２４）から駅２（２２５）を走行している間に、その列車に乗っている乗客の数を表す。

乗員人数（２２６）は、例えば列車の荷重センサから総重量のデータをそのまま受信し、データサーバ（１１１）が格納時に人数の値に変換してもよい。すなわち、乗員人数（２２６）は、列車から新たなデータを受信するタイミングで更新されてもよい。また、例えば、履歴管理サーバ（１０８）が総重量のデータを人数の値に変換し、既に人数の値に変換されたデータが、データサーバ（１１１）に出力されてもよい。乗員人数（２２６）は、例えば、一人あたりの体重が６０ｋｇであると仮定して、総重量のデータが示す重量を前記の体重で割って得られる商より計算することができる。

車両位置・列車乗員人数（１２３）に関する情報は、例えば、３０秒おきなど一定周期で取得される。データ取得の間隔が非常に短い場合には、同じ駅間でのデータ（つまり、駅１（２２４）と駅２（２２５）に変化のないデータ）が何度も伝送されることになる。このとき、データサーバ（１１１）は、都度、異なるログＩＤを付与して、それぞれのデータを別々に格納してもよいし、直前に取得したデータと比較して完全に同一であれば、データを格納せずに捨ててもよい。

図５は、データサーバ（１１１）に格納される改札入出場者数（１２４）のデータ構造について示した図である。改札入出場者数（１２４）は、駅ＩＤ（２３１）、改札口ＩＤ（２３２）、日付（２３３）、時間帯（２３４）、種別（２３５）、通過人数（２３６）などの情報を含む。時間帯（２３４）の区分は、例えば１分毎、５分毎などのように、あらかじめ定義されているものとし、区分の単位については、システム運用者によってシステムの外部から入力される。種別（２３５）は、自動改札機（１０２）の通過の向きを表す情報であり、「入場」もしくは「出場」のうち、どちらかが格納される。

改札入出場者数（１２４）は、乗客が任意の自動改札機（１０２）を通過する度に、データサーバ（１１１）にリアルタイムに受信され、集計されて格納されてもよい。データサーバ（１１１）は、一例として、一定の更新タイミングに従って一括で受信したデータを処理してもよく、データサーバ（１１１）側では、その送信タイミングに合わせて格納処理が行われればよい。また、データサーバ（１１１）は、自動改札機（１０２）で読み取った情報を、ネットワーク（１０７）を介して履歴管理サーバ（１０８）から受信してもよい。

なお、改札入出場者数（１２４）のデータソースは、上記した自動改札機（１０２）の通過データに限定されない。例えば、ＩＣ乗車券の利用履歴がデータソースであってもよい。また、カメラやセンサから取得される改札の出入り人数がデータソースであってもよい。例えば自動改札機（１０２）が設置されていない駅や、ＩＣ乗車券が利用できない駅については、改札口付近に設置される監視カメラや人感センサなどから取得されるデータに、映像解析・信号解析技術を用いることによって、改札の出入り人数が求められる。また、改札通過人数やＩＣ乗車券の利用履歴の集計処理や、映像解析や信号解析により改札の出入り人数を計算する処理は、適宜のコンピュータで実行されればよく、例えば、データサーバ（１１１）が処理を実行してもよいし、システムの外部で処理が実行されてもよい。

上記の説明のようにして、改札入場者数は、入場する人数を計数したデータに基づいて取得され、改札出場者数は、出場する人数を計数したデータに基づいて取得される。

図６Ａおよび図６Ｂは、データサーバ（１１１）に格納される統計値（１２５）のデータ構造について示した図である。統計値（１２５）には路線・方面の利用者比率（２４０）、乗換者数統計値（２５０）、列車乗員人数統計値（２６０）、改札入出場者数統計値（２７０）などが含まれる。

路線・方面の利用者比率（２４０）は、駅ＩＤ（２４１）、期間（２４２）、平休（２４３）、時間帯（２４４）、改札通過種別（２４５）、路線・方面ＩＤ（２４６）、乗降種別（２４７）、比率（２４８）などの情報を含み、例えば駅ＳＴ１で入場した人のうちで、路線・方面ＩＤ００１の列車に乗車する人の割合を表す。

比率（２４８）（上記した数式２、４で用いた比率、すなわち、配分比率に対応する。詳細には、乗降種別（２４７）が乗車の場合には、数式２、４のＲｅｎｔｅｒ_ｓｔａに対応し、乗降種別（２４７）が降車の場合には、数式２、４のＲｅｘｉｔ_ｓｔａに対応する。）を求めるためには、まず、入場駅と出場駅の組み合わせに対して、どの路線方面の列車を利用者が利用するかという経路情報が必要になる。この経路情報は経路検索エンジンなどを活用し、任意の入場駅と出場駅の組み合わせに対して検索処理を実行することで取得できる。一般的に経路検索エンジンにより得られる経路情報には、入場駅から出場駅に至るまでの路線方面のリストと、乗換駅の情報が含まれている。そこで、入場駅と出場駅の組み合わせごとに利用人数の統計値を求めて、経路情報と突き合わせることで、改札を入場した後に、ある路線方面の列車に乗る人が、それぞれ何人いるか、それは改札入場者全体の中で、どの程度の比率であるかを集計することができる。比率を求める一例として、入場駅から出場駅に至るまでの経路情報の取得に併せて、入場駅から出場駅に至るまでの路線方面ごとに、過去データから求めた利用人数の統計値も取得することができる経路検索エンジンを用いることができる。

路線・方面の利用者比率（２４０）には、ある期間（２４２）の改札入出場者数（１２４）を用いて、平休（２４３）や時間帯（２４４）の区分ごとに、各駅における路線方面別の乗り降りに関する人数の比率（２４８）が計算された結果が格納される。しかしながら、入場駅と出場駅の組み合わせごとの経路情報や利用人数は、例えば、ダイヤ改正などの列車の運行状況変化や都市開発の影響などによって、多少変動することが考えられるため、この路線・方面の利用者比率（２４０）は、定期的に更新する必要がある。

路線・方面の利用者比率（２４０）において、改札通過種別（２４５）が入場であれば、乗降種別（２４７）は乗車になり、改札通過種別（２４５）が出場であれば、乗降種別（２４７）は降車になる。例えば、一路線しか停車しないシンプルな駅では、一般的には、上り方面と下り方面の２つの路線・方面ＩＤ（２４６）の列車が停車する。そのため、当該駅において、ある時間帯（２４４）に改札から入場した改札入場者数は、上り方面の列車に乗車する人数と、下り方面の列車に乗車する人数に分配され、路線方面別の比率（２４８）の和は１となる。すなわち、同時間帯（２４４）の乗車において、上り方面と、下り方面と、の相違する２種類の路線・方面ＩＤ（２４６）に係る比率（２４８）の和は１となる。また、当該駅において、ある時間帯（２４４）に改札から出場した改札出場者数は、上り方面の列車からの降車の人数と、下り方面の列車からの降車の人数に分配され、路線方面別の比率（２４８）の和は１となる。すなわち、同時間帯（２４４）の降車において、上り方面と、下り方面と、の相違する２種類の路線・方面ＩＤ（２４６）に係る比率（２４８）の和は１となる。図６Ａを用いて比率の例について具体的に説明する。例えば、平日の１２：００～１２：０５の時間帯（２４４）で、路線・方面ＩＤ００１を上り方面と仮定すると、上り方面に関する乗車の比率（２４８）は０、６である。そして、平日の同時間帯（２４４）において、路線・方面ＩＤ００１とは異なるＩＤ（図６Ａにおいて不図示）を下り方面と仮定すると、下り方面に関する乗車の比率（２４８）は０．４（すなわち、１－０．６）である。同様にして、降車についても説明する。図６Ａにおいて、例えば、平日の１２：００～１２：０５の時間帯（２４４）で、路線・方面ＩＤ００１を上り方面と仮定すると、上り方面に関する降車の比率（２４８）は０．８である。そして、平日の同時間帯（２４４）において、路線・方面ＩＤ００１とは異なるＩＤ（図６Ａにおいて不図示）を下り方面と仮定すると、下り方面に関する降車の比率（２４８）は０．２（すなわち、１－０．８）である。

乗換者数統計値（２５０）は、駅ＩＤ（２５１）、期間（２５２）、平休（２５３）、時間帯（２５４）、乗換前路線・方面ＩＤ（２５５）、乗換後路線・方面ＩＤ（２５６）、人数（２５７）などの情報を含み、複数の路線があって異なる路線方面の列車への乗り換えが発生し得る駅を対象に、乗換者だけに注目した統計値である。

例えば駅ＳＴ２に、路線・方面ＩＤ（２４６）が００１と００３である列車が停車する場合に、路線・方面ＩＤが００１から００３への列車の乗換と、その逆方向への列車の乗換が考えられる。乗換者数統計値（２５０）には、乗換を含む駅を対象に、全ての乗換パターン（乗換前路線・方面ＩＤ（２５５）と乗換後路線・方面ＩＤ（２５６）の組み合わせ）ごとに、それぞれの人数（２５７）が格納される。ここで、人数（２５７）は、乗換者の数である。すなわち、人数（２５７）は、乗換者数統計値（２５０）上の同一のレコードにおいて、乗換前路線・方面ＩＤ（２５５）の列車から降車する人数（数式２、４のＰｔｒａ_ｇｅｔｏｆｆ_ｓｔａに対応）と、乗換後路線・方面ＩＤ（２５６）の列車に乗車する人数（数式２、４のＰｔｒａ_ｇｅｔｏｎ_ｓｔａに対応）と、の両方の人数に対応する。

乗換者数の統計値は、路線・方面の利用者比率（２４０）の計算の場合と同様に、入場駅と出場駅の組み合わせごとに利用人数の統計値を求めて、経路情報と突き合わせることで、計算することができる。なお、入場駅と出場駅の組み合わせごとの利用人数や経路情報は、列車の運行状況や都市開発の影響などによって、多少変動することが考えられるため、この乗換者数統計値（２５０）も定期的に更新することが望ましい。

列車乗員人数統計値（２６０）は、駅ＩＤ（２６１）、期間（２６２）、平休（２６３）、時間帯（２６４）、路線・方面ＩＤ（２６５）、乗員人数（２６６）などの情報を含み、車両位置・列車乗員人数（１２３）に格納されているレコードのうちで、指定された期間（２６２）のレコードを対象に集計することで作成される。

改札入出場者数統計値（２７０）は、駅ＩＤ（２７１）、期間（２７２）、平休（２７３）、時間帯（２７４）、種別（２７５）、人数（２７６）などの情報を含み、改札入出場者数（１２４）に格納されているレコードのうちで、指定された期間（２７２）のレコードを対象に集計することで作成される。

なお、改札入出場者数統計値（２７０）は、過去の改札通過データのパターン分類結果や、平均値などの公知の推定手法を使って求めることもできる。推定手法については、特許文献（特開２０１０－０６１３２１号公報）にも例が示されている。他にも例えば、過去の同一または類似の条件（同一日時、天候、その他イベント等）のデータから推定したデータ、あるいは、予測モデルを用いて推定した値を用いることもできる。

図７は、データサーバ（１１１）に格納されるイベント見込み人数（１２６）のデータ構造について示した図である。イベント見込み人数（１２６）は、駅ＩＤ（２８１）、改札口ＩＤ（２８２）、日付（２８３）、開始・終了時刻（２８４）、持続時間（２８５）、種別（２８６）、利用人数（２８７）などの情報を含み、イベント開催時に最寄り駅を利用すると思われる入場者数または出場者数の増加分を表すデータである。

イベント会場の最寄り駅に改札口が複数あり、会場へのアクセスの良さなどの観点から、改札口の利用比率に明らかに偏りが出ると予想されるときには、駅ＩＤ（２８１）以外に改札口ＩＤ（２８２）も指定し、イベント開催による最寄り駅の利用人数（２８７）の需要増加を細かく表現してもよい。例えば、駅ＳＴ１において２つの改札口Ｇ１およびＧ２があり、改札口Ｇ１と改札口Ｇ２の利用比率に明らかに偏りが出ると予想されるときには、駅ＳＴ１の改札口Ｇ１の利用人数（２８７）および駅ＳＴ１の改札口Ｇ２の利用人数（２８７）が、それぞれ別々にイベント見込み人数（１２６）上で表現されてもよい。

開始・終了時刻（２８４）は、イベント開催やイベント終了により、最寄り駅の利用人数に初めて変化が表れる時刻もしくは変化が終わる時刻を表す。例えば、イベント自体の開始時刻が１６：３０かつ、イベント会場が最寄り駅のすぐそばに位置している場合、最寄り駅の出場者数は、イベント開始時刻である１６：３０直前まで多くなることが想像される。しかし、イベント参加者の全員が開始時刻間際に来場するわけではなく、もう少し早い時間に最寄り駅を出場し、イベント会場付近で待機する人もいると考えられる。その時間幅が持続時間（２８５）の値であり、例えば１２０分など分単位で格納される。イベント終了後の利用者の流れも同様に考えることができ、イベント終了時刻の直後に最寄り駅から入場し、帰路につく人もいれば、会場付近で少し時間をつぶしてから、最寄り駅に入場する人もいると考えられる。イベント見込み人数（１２６）は、変更があった場合に、鉄道事業者（１１６）もしくはシステム運用者（１１９）がシステムの外部から入力し、更新されて記録される。

図８は、データサーバ（１１１）に格納される滞留人数計算結果（１２７）のデータ構造について示した図である。滞留人数計算結果（１２７）は、駅ＩＤ（２９１）、日付（２９２）、時間帯（２９３）、ホーム名（２９４）、番線名（２９５）、乗降種別（２９６）、人数（２９７）などの情報を含み、各駅および各番線の乗車人数もしくは降車人数を表すデータである。時間帯（２９３）の区分は、適宜に設定してもよいが、計算処理の簡便性を考慮して、改札入出場者数（１２４）の時間帯区分および統計値（１２５）の時間帯区分と一致していることが望ましい。

図９は、車両位置・列車乗員人数（１２３）のデータと、列車乗員人数集計プログラム（１３４）と、を用いて、列車乗員人数統計値（２６０）を計算する手順を説明する図である。

計算サーバ（１１２）は、まず、データサーバ（１１１）内の駅・路線情報（１２２）を読み込み、駅ＩＤ（２０１）および路線・方面ＩＤ（２０２）の組み合わせを取得する（処理ステップＳ１０１）。

計算サーバ（１１２）は、集計対象の期間および時間帯の情報をプログラム（１３４）の外部から取得する（処理ステップＳ１０２）。

計算サーバ（１１２）は、データサーバ（１１１）の車両位置・列車乗員人数（１２３）のデータから取得日時（２２３）を参照し、処理ステップＳ１０２で取得した集計対象期間および時間帯に該当するデータ期間および時間帯に含まれるレコードを読み込んで抽出する（処理ステップＳ１０３）。

計算サーバ（１１２）は、路線・方面ＩＤ（２２１）、駅２（２２５）の組み合わせ、および、平休の区分ごとにレコードを分類し、分類したレコードを用いて乗員人数（２２６）の平均値を区分ごとに求める。そして、その計算結果が集計された列車乗員人数統計値（２６０）を、計算結果を記録するデータ格納部（１３９）に格納する（処理ステップＳ１０４）。なお、処理ステップＳ１０４では、乗員人数（２６６）の平均値が、取得日を考慮して求められてもよく、例えば、当日における列車の乗員人数（２２６）の平均値が求められてもよい。

図１０は、列車の乗員人数に関して当日と統計値との差分（当日と統計値のひらき）を考慮しながら、改札入場者数を各路線方面に配分して更新された乗車人数（入場して列車に乗車する人数）を求め、改札出場者数を各路線方面に配分して更新された降車人数（降車して出場する人数）を求める処理手順を説明する図である。図１０の処理においては、乗降人数配分比率プログラム（１３５）を用いた処理が実行される。

計算サーバ（１１２）は、まず、プログラム（１３５）の外部から、乗降人数の計算対象とする駅ＩＤの情報を取得し、データサーバ（１１１）内の駅・路線情報（１２２）を読み込み、駅ＩＤ（２０１）および路線・方面ＩＤ（２０２）の値から、計算対象の駅に停車する列車の路線・方面ＩＤ（２０２）のリスト（一覧）を取得する（処理ステップＳ２０１）。

計算サーバ（１１２）は、取得した全ての路線・方面ＩＤ（２０２）について以降の処理を繰り返す。計算対象の駅および計算対象の路線・方面ＩＤ（２０２、２２１）に一致する、当日における列車の乗員人数（２２６）の平均値を取得する。なお、上記した列車乗員人数集計プログラム（１３４）の処理（すなわち、処理ステップＳ１０４の処理）において、当日における列車の乗員人数（２２６）の平均値を求めた場合、処理ステップＳ１０４の結果から、当日における列車の乗員人数（２２６）の平均値を取得してもよい。これに加えて、列車乗員人数集計プログラム（１３４）により求めた、統計値（１２５）に含まれる列車乗員人数統計値（２６０）を読み込み、計算対象の駅および計算対象の路線・方面ＩＤ（２０２、２６５）に一致する乗員人数（２６６）の値を取得する（処理ステップＳ２０２）。

計算サーバ（１１２）は、上記の処理ステップＳ２０２により取得した２つの値（当日における列車の乗員人数（２２６）の平均値と列車の乗員人数（２６６）の統計値）を用いて、当日と統計値との差分を表す値であるＴＬｄｉｆｆ_ｒｔを計算する。ＴＬｄｉｆｆ_ｒｔは、例えば、「当日における列車の乗員人数（２２６）の平均値÷列車の乗員人数（２６６）の統計値」で求めることができる（処理ステップＳ２０３）。

計算サーバ（１１２）は、上記のＴＬｄｉｆｆ_ｒｔの値を用いて、比率（２４８）の更新を行う。計算サーバ（１１２）は、統計値（１２５）に含まれる路線・方面の利用者比率（２４０）を読み込み、更新する対象の駅ＩＤ（２４１）、対象の期間（２４２）および対象の時間帯（２４４）、対象の路線・方面ＩＤ（２４６）を含むレコードを抽出する。そして、乗車の比率（２４８）と降車の比率（２４８）それぞれに、ＴＬｄｉｆｆ_ｒｔを掛けることで、比率（２４８）を更新する。（処理ステップＳ２０４）。詳細には、乗車の比率（２４８）にＴＬｄｉｆｆ_ｒｔを掛けることで（上記の数式２、４で説明すると、Ｒｅｎｔｅｒ_ｓｔａにＴＬｄｉｆｆ_ｒｔを掛けることで）、乗車の比率（２４８）が更新される。また、降車の比率（２４８）にＴＬｄｉｆｆ_ｒｔを掛けることで（上記の数式２、４で説明すると、Ｒｅｘｉｔ_ｓｔａにＴＬｄｉｆｆ_ｒｔを掛けることで）、降車の比率（２４８）が更新される。ここで、更新する対象の期間および対象の時間帯は、プログラム（１３５）の外部から指定されるものとする。このようにして、配分比率が更新される。

計算サーバ（１１２）は、データサーバ（１１１）内に格納された改札入出場者数（１２４）から、乗車する人数の計算対象となる駅の改札入場者数（すなわち、乗車する人数の計算対象となる駅ＩＤ（２３１）において、種別（２３５）が「入場」である通過人数（２３６）の値）を取得する。そして、上記の処理ステップＳ２０４で更新した乗車の比率（２４８）を取得した計算対象駅の改札入場者数に掛け、更新された人数（すなわち、入場して列車に乗車する人数）を求める（処理ステップＳ２０５）。すなわち、上記の数式２、４で説明すると、Ｐｅｎｔｅｒ_ｒｔに、更新した乗車の比率（２４８）である（Ｒｅｎｔｅｒ_ｓｔａ×ＴＬｄｉｆｆ_ｒｔ）を掛ける処理を行う。計算サーバ（１１２）は、同様にして、データサーバ（１１１）内に格納された改札入出場者数（１２４）から、降車する人数の計算対象となる駅の改札出場者数を取得し、上記の処理ステップＳ２０４で更新した降車の比率（２４８）を取得した計算対象駅の改札出場者数に掛け、更新された人数（すなわち、列車から降車して出場する人数）を求める（処理ステップＳ２０６）。すなわち、上記の数式２、４で説明すると、Ｐｅｘｉｔ_ｒｔに、更新した降車の比率（２４８）である（Ｒｅｘｉｔ_ｓｔａ×ＴＬｄｉｆｆ_ｒｔ）を掛ける処理を行う。

図１１は、列車の乗員人数に関して当日と統計値との差分（当日と統計値のひらき）を考慮しながら、乗換人数を更新する処理手順を説明する図である。図１１の処理においては、乗換人数更新プログラム（１３６）を用いた処理が実行される。

計算サーバ（１１２）は、まず、プログラム（１３６）の外部から、乗換人数の計算対象とする駅ＩＤの情報を取得して、データサーバ（１１１）内の駅・路線情報（１２２）を読み込み、駅ＩＤ（２０１）および路線・方面ＩＤ（２０２）の値から、計算対象の駅に停車する路線・方面ＩＤ（２０２）のリスト（一覧）を取得する（処理ステップＳ３０１）。

計算対象となる駅に２つ以上の路線があり、当該駅が異なる路線方面の列車への乗り換えが発生し得る駅である場合（ただし、同じ路線の上り方面の列車と下り方面の列車の間では、乗り換えがないとして）、計算サーバ（１１２）は、乗り換えが発生し得る駅について、取得した路線・方面ＩＤ（２０２）のリストから乗換前路線・方面ＩＤ（２５５）と乗換後路線・方面ＩＤ（２５６）の組み合わせを作成する。なお、乗り換えが発生し得る駅かどうかについては、駅ＩＤ（２０１、２５１）を比較したり、路線名（２０４）を用いた処理を行うことで、適宜に判定することができる。そして、計算サーバ（１１２）は、以降の処理を繰り返す。計算サーバ（１１２）は、計算対象の駅、および、乗換前路線・方面ＩＤ（２５５）に一致する、当日における列車の乗員人数（２２６）の平均値を取得する。これに加えて、統計値（１２５）に含まれる列車乗員人数統計値（２６０）を読み込み、計算対象の駅および乗換前路線・方面ＩＤ（２５５）に一致する路線・方面ＩＤ（２６５）の乗員人数（２６６）の値を取得する（処理ステップＳ３０２）。

計算サーバ（１１２）は、上記の処理ステップＳ３０２により取得した２つの値（列車の乗員人数の平均値と統計値）を用いて、当日と統計値との差分を表す値であるＴＬｄｉｆｆ_ｒｔを計算する。ＴＬｄｉｆｆ_ｒｔは例えば、「当日における列車の乗員人数の平均値÷列車の乗員人数の統計値」で求めることができる（処理ステップＳ３０３）。

計算サーバ（１１２）は、次に統計値（１２５）に含まれる乗換者数統計値（２５０）を読み込み、計算する対象の駅ＩＤ（２５１）、計算する対象の期間（２５２）および対象の時間帯（２５４）、計算する対象の路線・方面ＩＤが乗換前路線・方面ＩＤ（２５５）と一致するレコードを抽出し、人数（２５７）の値を取得する。計算サーバ（１１２）は、取得した人数（２５７）の値にＴＬｄｉｆｆ_ｒｔを掛けることで、乗換時の降車人数を求める（処理ステップＳ３０４）。上記の数式２、４で説明すると、Ｐｔｒａ_ｇｅｔｏｆｆ_ｓｔａに、ＴＬｄｉｆｆ_ｒｔを掛けて更新する処理を行う。

計算サーバ（１１２）は、同様に、統計値（１２５）に含まれる乗換者数統計値（２５０）を読み込み、計算する対象の駅ＩＤ（２５１）、計算する対象の期間（２５２）および対象の時間帯（２５４）、計算する対象の路線・方面ＩＤが乗換後路線・方面ＩＤ（２５６）と一致するレコードを抽出し、人数（２５７）の値を取得する。計算サーバ（１１２）は、取得した人数の値にＴＬｄｉｆｆ_ｒｔを掛けることで、乗換時の乗車人数を求める（処理ステップＳ３０５）。上記の数式２、４で説明すると、Ｐｔｒａ_ｇｅｔｏｎ_ｓｔａに、ＴＬｄｉｆｆ_ｒｔを掛けて更新する処理を行う。なお、乗換者数を計算する対象の期間（２５２）および対象の時間帯（２５４）は、プログラム（１３６）の外部から指定されるものとする。このようにして、差分を考慮した乗換者数を計算することができ、乗換者数を更新することができる。

図１２は、イベント開催時に増加すると思われる利用者数の増加分を考慮して、未来の時刻の改札入場者数を予測する処理手順を説明する図である。改札入場者数の予測を例として説明するが、改札出場者数の予測についても処理手順は同様である。図１２の処理においては、改札入出場者数予測プログラム（１３７）を用いた処理が実行される。

計算サーバ（１１２）は、まず、プログラム（１３７）の外部から、未来の時刻の改札入場者数の計算対象とする駅ＩＤと、予測対象日時と、の情報を取得する（処理ステップＳ４０１）。

計算サーバ（１１２）は、次に統計値（１２５）に含まれる改札入出場者数統計値（２７０）を読み込み、上記の処理ステップＳ４０１で取得した、計算対象の駅と計算対象の日付の平休区分および時間帯に該当するレコードを検索し、改札入場者数の統計値である人数（２７６）を取得する（処理ステップＳ４０２）。

計算サーバ（１１２）は、次にイベント見込み人数（１２６）を読み込み、上記の処理ステップＳ４０１で取得した、計算対象の駅と予測対象日の日付において、入出の種別（２８６）が入場であるレコードを検索し、かつ、開始・終了時刻（２８４）から持続時間（２８５）が経過するまでの時刻に、予測の対象となる時刻（予測対象日時の時刻）が該当しているかどうかについて判定する。そして、該当レコードがある場合は、該当するレコードから、イベントの開始・終了時刻（２８４）と持続時間（２８５）と利用人数（２８７）の値を取得する（処理ステップＳ４０３）。

イベント開催時に増加が見込まれる改札入場者数や改札出場者数の変化は、イベント開始・終了時刻の前後に瞬間的に発生するわけではなく、ある時間幅を持って変化することが想像される。そのため、計算サーバ（１１２）は、イベントの開始・終了時刻（２８４）と持続時間（２８５）を参照し、イベントの開催時に増加することが見込まれる改札の利用人数（２８７）（図１２では、イベント動員人数と記載）の値を各時間帯に配分する（処理ステップＳ４０４）。ここで、配分方法の例としては、例えばベータ分布など、統計的な分布に従って、配分する方法を挙げることができる。また、過去に開催されたイベント日の改札入出場者数の値から求めた平均値を用いて配分する方法であってもよい。

計算サーバ（１１２）は、次に処理ステップＳ４０２で取得した改札入場者数の統計値である種別（２７５）が「入場」の人数（２７６）に、処理ステップＳ４０４で求めた、イベント開催時に増加することが見込まれる改札入場者数を加算し、和Ｓを求める（処理ステップＳ４０５）。なお、改札出場者数の予測を行う場合では、改札出場者数の統計値である種別（２７５）が「出場」の人数（２７６）に、処理ステップＳ４０４で求めた、イベント開催時に増加することが見込まれる改札出場者数を加算し、和Ｓを求める。

そして、現在時刻において、改札入場者数の統計値と、イベント開催時に増加することが見込まれる改札入場者数と、の和Ｓが、リアルタイムに取得した改札入場者数の値と、ある程度の乖離がある場合がある。この場合には、差分Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔを計算し、上記の和Ｓの値を補正する（処理ステップＳ４０６）。ここで、差分Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔは、例えば、「リアルタイムに取得した改札入場者数の値÷（改札入場者数の統計値とイベント開催時に増加することが見込まれる改札入場者数増加分である、処理ステップＳ４０５で求められる和Ｓ）」で計算できる。改札出場者数の予測を行う場合では、差分Ｐｅｘｉｔ_ｄｉｆｆ_ｒｔは、例えば、「リアルタイムに取得した改札出場者数の値÷（改札出場者数の統計値とイベント開催時に増加することが見込まれる改札出場者数増加分である、処理ステップＳ４０５で求められる和Ｓ）」で計算できる。これにより、統計値とイベント需要から求めた改札入場者数の予測値に対して、現在の改札入場者数の比率が高ければ（予測していた改札入場者数より、現実の改札入場者数の方が多ければ）、この先もその傾向が、しばらく続くものとして、改札入場者数の予測値が多くなるように調整することができる。なお、この補正については、予測したい対象日時（予測対象日時）と、現在時刻との間の時間差を考慮し、必要に応じて増幅や減衰させることができる。例えば現在時刻＋１時間後までは、Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔの係数をそのまま用いて補正を行うが、現在時刻＋１時間先以降は、Ｐｅｎｔｅｒ_ｄｉｆｆ_ｒｔの係数に０．５を掛けて、重みを半分にして適用するなど、時間経過とともに補正の効果を薄めることができる。改札出場者数の予測を行う場合についても、同様にして、補正の効果を調整することができる。

図１３は、駅の滞留人数を計算する処理手順を示す流れ図である。駅の滞留人数計算プログラム（１３８）は、データサーバ（１１１）の改札入出場者数（１２４）が更新されたタイミングか、もしくはあらかじめ定められた間隔に合わせて、実行される。図１３の処理においては、駅の滞留人数計算プログラム（１３８）を用いた処理が実行される。

計算サーバ（１１２）は、まず、プログラム（１３８）の外部から計算対象とする駅ＩＤと路線方面の情報を取得する（処理ステップＳ５０１）。次に計算対象日時の情報を取得する（処理ステップＳ５０２）。処理ステップＳ５０２で取得した計算対象日時が未来の時刻である場合、改札入出場者数予測プログラム（１３７）により、改札入場者数と改札出場者数の予測値（改札入出場者数の予測値）を求める（処理ステップＳ５０３）。また、処理ステップＳ５０３では、改札入出場者数予測プログラム（１３７）の処理（改札入場者数の場合は処理ステップＳ４０２）で取得される、改札入出場者数の統計値である人数（２７６）も取得される。すなわち、処理ステップ５０３は、未来の所定時間帯における滞留人数の計算にあたり、イベント時に増加する改札入場者数（または改札出場者数）と、所定時間帯での改札入場者数（または改札出場者数）の統計値である人数（２７６）と、の和Ｓ（差分により補正された場合は、和Ｓの補正値）を求めるステップである。その一方で、処理ステップＳ５０２で取得した計算対象日時が現在時刻である場合は、リアルタイムに取得される改札入出場者数を取得する（処理ステップＳ５０４）。

計算サーバ（１１２）は、処理ステップＳ５０３および処理ステップＳ５０４のいずれかで求めた、改札入場者数および改札出場者数に基づき、乗降人数配分比率更新プログラム（１３５）を呼び出すことにより、配分比率である比率（２４８）を用いて更新された乗車する人数（入場して列車に乗車する人数）および降車する人数（列車から降車して出場する人数）を取得する。また、計算サーバ（１１２）は、乗換人数更新プログラム（１３６）を呼び出すことにより、計算対象の路線方面の列車から乗り降りする人数（更新された乗換人数）を取得する。そして、計算サーバ（１１２）は、取得した更新された乗車人数と、取得した更新された降車人数と、取得した更新された乗換人数と、を集計して、その結果を滞留人数計算結果（１２７）に格納する（処理ステップＳ５０５）。なお、処理ステップＳ５０３で改札入出場者数の予測値を取得した場合、処理ステップＳ５０５においては、予測モデル（上述した数３～数５）が取得されて、予測モデルに基づく滞留人数計算結果（１２７）が求められる。その一方で、計算対象日時が現在時刻である場合は、数式１、２に基づく滞留人数計算結果（１２７）が求められる。

図１４は、情報配信サーバ（１１３）によって、システム運用者（１１９）、鉄道事業者（１１６）、情報利用者（１１５）向けに生成および配信される、駅の滞留人数表示のための条件設定画面の一例を示した図である。これらの利用者は、情報配信サーバ（１１３）からの配信データを適宜のディスプレイに表示させて利用することができる。

条件設定画面（１０００）において、情報利用者（１１５）が、ユーザ名入力欄（１００１）にユーザ名、対象路線・駅選択欄（１００２）に検索対象の路線や駅、対象日選択欄（１００３）に検索対象の日付などを直接入力、またはプルダウンメニューなどで選択し、実行ボタン（１００４）を押すことによって、情報配信サーバ（１１３）にリクエストが伝達される。

なお、これらの表示条件（すなわち、条件設定画面（１０００）の表示の態様）は、特に限定されず、利用者によって適宜に設定・変更することが可能である。利用者は、例えば設定画面やマウス・キーボードなどの入力インタフェースを用いて、表示条件などを設定・変更することができる。例えば、ユーザ名入力欄（１００１）は、必要のない場合、表示自体を省略することができる。また、例えば、対象路線・駅選択欄（１００２）については、選択肢が多くなる場合には、まず路線を選択してから次に駅を選ぶなど、段階的な選択を行うことができるように、変更されてもよい。また、対象路線・駅選択欄（１００２）や対象日選択欄（１００３）については、この画面例では一つの選択肢を選択する場合を示したが、ウィンドウを大きくするなどして、複数の選択肢を同時に選ぶことができるように、変更されてもよい。

図１５は、駅の滞留人数を参照するために検索条件が入力され、リクエストされたタイミングで実行される情報配信処理の手順を説明する図である。

情報配信サーバ（１１３）は、条件取得プログラム（１４１）の実行において、まず条件設定画面（１０００）で入力された条件を取得する（処理ステップＳ６０１）。次にユーザ名入力欄（１００１）が入力されている場合には、正しくアクセス権限を有しているかの照合を行う（処理ステップＳ６０２）。ユーザ名の入力が必要でない場合は、この処理を省略する。アクセス権限を確認した後、情報配信プログラム（１４２）を呼び出す（処理ステップＳ６０３）。

図１６は、入力された検索条件に従って配信画面を生成し、配信する処理手順を説明する図である。

情報配信サーバ（１１３）は、情報配信プログラム（１４２）の実行において、まず、条件取得プログラム（１４１）で取得した条件を受け取り（処理ステップＳ７０１）、滞留人数計算結果（１２７）から集計対象の駅および日付に該当するレコードを抽出する（処理ステップＳ７０２）。次に抽出したレコードを時系列グラフや地図画面へのマッピングなど、わかりやすい形式に加工し、配信を行う（処理ステップＳ７０３）。これらのプログラム（つまり、加工処理に用いるプログラム）は、情報配信サーバ（１１３）内にあらかじめ用意され、情報配信サーバ（１１３）は、用途ごとにこれらのプログラムを組み合わせて加工処理することが望ましい。ただし、プログラムを組み合わせないで加工処理が行われてもよいし、クライアント側のコンピュータで加工処理が行われてもよい。

図１７は、情報配信サーバ（１１３）によって生成および配信される提示画面の一例であり、図１４で示した条件設定画面からリクエストされ、加工処理が終わったタイミングで配信される画面の例を示した図である。

提示画面（１１００）は、例えば日付、時刻が表示される日付・時刻表示領域（１１０１）、駅の滞留人数や、列車の乗員人数が地図上に表示された混雑状況全体図（１１０２）、ある特定の駅の滞留人数の予測結果を時系列グラフで表示した混雑予測図（１１０３）などで構成される。

地図上（ここでは、混雑状況全体図）では、駅や列車シンボルが表示されている。ここで、駅や列車シンボルは、あらかじめ定められた閾値によりレベル分けされた混雑度に応じて、大きさや色を異ならせて表示することができる。これにより、利用者に混雑状況をわかりやすく伝えることができる。

提示画面（１１００）には、混雑度に併せて列車の遅延情報などが表示されてもよい。

提示画面（１１００）には、ある時間帯もしくは一日を通して、混雑すると考えらえる順に駅がソートされている表が表示されてもよい。ここで、駅をソートする処理は、情報配信サーバ（１１３）側で行ってもよいし、クライアント側のコンピュータで行ってもよい。

画面（１１００）には、全体を俯瞰することができる画像を表示させることができるので、システム運用者（１１９）や鉄道事業者（１１６）にとって、運行計画の見直しや混雑している駅の支援策の立案などの業務改善につながることが考えられる。

情報利用者（１１５）は、マウスやキーボードなどの適宜の入力インタフェースを用いて操作することにより、提示画面（１１００）の表示を調節したり、提示画面（１１００）の表示を変更したりすることができる。例えば、ホイールボタンなどを利用者が操作することなどによって、地図画面のズームイン／ズームアウトが実行されてもよい。また、マウスで駅や列車のシンボルを選択してクリックすることによって、列車ＩＤや運行実績などの詳細な情報の表示が実行されてもよい。なお、画面の表示を調節／変更するためのプログラムは、利用者側のコンピュータに格納される。

また、タッチパネルに提示画面（１１００）が出力される場合、情報利用者（１１５）は、指や専用ペンで操作してもよい。

また、上記で説明した以外にも、提示画面（１１００）の表示態様は、適宜に変更することができる。例えば、混雑状況全体図（１１０２）の配置と混雑予測図（１１０３）の配置を変更してもよいし、不要であれば、日付・時刻表示領域（１１０１）を省略してもよい。また、例えば、「かなり混雑するでしょう。」などの混雑情報を示す文字情報が表示されてもよい。

以上、本発明の実施形態について説明したが、本実施形態では、リアルタイムでのデータ入手が容易な車両の荷重データを活用し、さらに改札等から入退場した乗客のデータで補完することにより、駅の滞留人数を推定することができる。本発明は上記実施形態に限定されるものではなく、種々な変形が可能である。

本実施形態では、駅滞留人数推定システム（１０５）は、データサーバ（１１１）、計算サーバ（１１２）、情報配信サーバ（１１３）のサーバ群として説明されていたが、駅滞留人数推定システム（１０５）は、１つのサーバによってこれらのサーバ群の機能を実行できるように構成されていてもよい。また、複数のサーバによってこれらサーバ群の機能を実行できるように構成されていてもよい。

システム運用者（１１９）、鉄道事業者（１１６）、情報利用者（１１５）向け以外でもよく、これらの者以外にも、情報配信サーバ（１１３）は、データを提供してもよい。

１０１…利用者、１０２…自動改札機、１０３…列車、１０５…駅滞留人数推定システム、１０７…ネットワーク、１０８…履歴管理サーバ、１１１…データサーバ、１１２…計算サーバ、１１３…情報配信サーバ、１１４…ネットワーク、１１５…情報利用者、１１６…鉄道事業者、１１７…情報端末、１１８…携帯情報端末、１１９…システム運用者、１２０…操作端末、１２１…データ格納部、１２２…駅・路線情報、１２３…車両位置・列車乗員人数（列車乗員人数データ）、１２４…改札入出場者数（改札入出場者数データ）、１２５…統計値、１２６…イベント見込み人数、１２７…滞留人数計算結果、１３０…ネットワークインタフェース、１３１…ＣＰＵ、１３２…メモリ、１３３…記憶部、１３４…列車乗員人数集計プログラム、１３５…乗降人数配分比率更新プログラム、１３６…乗換人数更新プログラム、１３７…改札入出場者数予測プログラム、１３８…駅の滞留人数計算プログラム、１３９…データ格納部、１４１…条件取得プログラム、１４２…情報配信プログラム、１４５…ネットワークインタフェース、１４６…ＣＰＵ、１４７…メモリ、１４８…記憶部、１５１…ネットワーク、２０２、２２１、２４６，２６５…路線・方面ＩＤ、２０１、２３１、２４１、２５１、２６１、２７１、２８１、２９１…駅ＩＤ、２０３…停車順序、２０４…路線名、２０５、２９４…ホーム名、２０６、２９５…番線名、２０７…緯度、２０８…経度、２２２…列車ＩＤ、２２３…取得日時、２２４…駅１、２２５…駅２、２２６…乗員人数、２３２、２８２…改札口ＩＤ、２３３、２８３、２９２…日付、２３４、２４４、２５４、２６４、２７４、２９３…時間帯、２３５、２７５、２８６…種別、２３６…通過人数、２４０…路線・方面の利用者比率、２５０…乗換者数統計値、２４２、２５２、２６２、２７２…期間、２４３、２５３、２６３、２７３…平休区分、２４５…改札通過種別、２４７、２９６…乗降種別、２４８…比率（配分比率）、２５５…乗換前路線・方面ＩＤ、２５６…乗換後路線・方面ＩＤ、２５７、２７６、２９７…人数、２６６…乗員人数、２６０…列車乗員人数統計値、２７０…改札入出場者数統計値、２８４…開始・終了時刻、２８５…持続時間、２８７…利用人数、Ｓ１０１～Ｓ１０４、Ｓ２０１～Ｓ２０６、Ｓ３０１～Ｓ３０５、Ｓ４０１～Ｓ４０６、Ｓ５０１～Ｓ５０５、Ｓ６０１～Ｓ６０３、Ｓ７０１～Ｓ７０３…処理ステップ、１０００…条件設定画面、１００１…ユーザ名入力欄、１００２…対象路線・駅選択欄、１００３……対象日選択欄、１００４…実行ボタン、１１００…提示画面、１１０１…日付・時刻表示領域、１１０２…混雑状況全体図、１１０３…混雑予測図

Claims (10)

1. 入力装置、出力装置、処理装置、および、記憶装置を備えた情報処理装置により、所定領域の滞留人数を計算するデータ処理方法であって、
   前記滞留人数を移動体への乗車人数と移動体からの降車人数の和と定義し、
   前記乗車人数は、前記所定領域に入場する入場者数を反映した値ＩＮと路線方面別の配分比率の積と、乗換先の移動体に乗って前記所定領域内で前記移動体を乗り換える乗換者数の和と等しいものとし、
   前記降車人数は、前記所定領域を出場する出場者数を反映した値ＯＵＴと路線方面別の配分比率の積と、乗換元の移動体を降りて前記所定領域内で前記移動体を乗り換える乗換者数の和と等しいものとし、
   前記移動体に乗車して前記所定領域に進入する第１の乗員人数を反映した値ａ１を取得する第１ステップと、
   前記移動体に乗車して前記所定領域を退出する第２の乗員人数を反映した値ｂ１を取得する第２ステップと、
   前記値ＩＮ、および、前記値ＯＵＴを取得する第３ステップと、
   前記値ａ１と前記値ｂ１、および、前記値ａ１の統計値と前記値ｂ１の統計値の差分を用いて、前記路線方面別の配分比率および前記所定領域内で前記移動体を乗り換える乗換者数を更新する第４ステップと、
   前記値ＩＮおよび前記値ＯＵＴと、更新された前記路線方面別の配分比率および更新された前記乗換者数から、前記滞留人数を計算する第５ステップと、
   を備える、データ処理方法。
2. 前記値ａ１および前記値ｂ１は、
   前記移動体の荷重センサから得られたデータに基づいて取得される、
   請求項１に記載のデータ処理方法。
3. 前記値ａ１および前記値ｂ１は、
   前記移動体から新たなデータを受信するタイミングで更新される、
   請求項１に記載のデータ処理方法。
4. 前記値ＩＮは、前記所定領域に入場する人数を計数したデータに基づいて取得され、前記値ＯＵＴは、前記所定領域から出場する人数を計数したデータに基づいて取得される、
   請求項１に記載のデータ処理方法。
5. 前記所定領域は、鉄道の駅構内であり、
   前記所定領域への入出場は、改札口を介して行われ、
   前記路線方面別の配分比率は、
   入場駅と出場駅の組み合わせごとに求めた前記値ＩＮと前記値ＯＵＴの統計値と、前記入場駅から前記出場駅への経路情報と、を突き合わせることにより集計される、
   請求項１に記載のデータ処理方法。
6. 前記所定領域は、鉄道の駅構内であり、
   前記所定領域への入出場は、改札口を介して行われ、
   前記移動体は、鉄道の列車であり、
   所定時間帯における前記値ＩＮと前記値ＯＵＴを格納したデータである改札入出場者数データと、前記所定時間帯における前記値ａ１と前記値ｂ１を格納したデータである列車乗員人数データと、を用いて、
   前記滞留人数の計算を行う対象となる時間帯である対象時間帯を取得するステップを有し、
   前記対象時間帯に含まれる前記所定時間帯における、前記改札入出場者数データと前記列車乗員人数データと、を用いて、前記滞留人数を計算する、
   請求項１に記載のデータ処理方法。
7. 前記所定領域は、鉄道の駅構内であり、
   前記所定領域への入出場は、改札口を介して行われ、
   前記滞留人数の計算を行う対象となる将来の時間帯である予測対象時間帯を取得するステップと、
   前記滞留人数を予測するための予測モデルを取得するステップと、
   イベント時に増加する改札入出場者数を取得するステップと、
   前記予測対象時間帯以前の所定時間帯における、前記改札入出場者数の過去分の統計値を取得するステップと、
   を有し、
   前記イベント時に増加する前記改札入出場者数と、前記改札入出場者数の過去分の統計値と、を前記予測モデルに入力し、前記予測対象時間帯における前記滞留人数の計算を行う、
   請求項１に記載のデータ処理方法。
8. 入力装置、出力装置、処理装置、および、記憶装置を備えた情報処理装置により、改札口と、列車の進入および退出経路を備える駅構内の滞留人数を計算する、データ処理システムであって、
   前記列車に乗車して前記駅構内に進入する第１の乗員人数を反映した値ａ１と、前記列車に乗車して前記駅構内を退出する第２の乗員人数を反映した値ｂ１から、前記値ａ１の統計値および前記ｂ１の統計値との差分を求め、路線方面別の配分比率を更新する配分比率更新モジュールと、
   前記列車に乗車して前記駅構内に進入する第１の乗員人数を反映した前記値ａ１と、前記列車に乗車して前記駅構内を退出する第２の乗員人数を反映した前記値ｂ１から、前記値ａ１の統計値および前記ｂ１の統計値との差分を求め、乗換者数を更新する乗換者数更新モジュールと、
   前記駅構内に前記改札口から入場する入場者数を反映した値ＩＮ、および、前記駅構内を前記改札口から出場する出場者数を反映した値ＯＵＴと、更新された前記路線方面別の配分比率および更新された前記乗換者数から、前記滞留人数を計算する滞留人数計算モジュールと、
   を備える、データ処理システム。
9. 前記滞留人数を予測するための予測モデルを用いて、
   イベント時に増加する改札入出場者数と、所定時間帯における改札入出場者数のデータである改札入出場者数データの過去分から計算した統計値と、を、前記滞留人数を予測するための前記予測モデルに入力し、現在または将来の改札入出場者数を予測する、改札入出場者数予測モジュール、
   を備える請求項８に記載のデータ処理システム。
10. 前記滞留人数計算モジュールは、
    前記滞留人数を、前記列車への乗車人数と前記列車からの降車人数の和と定義し、
    前記乗車人数は、前記値ＩＮと前記路線方面別の配分比率の積と、乗換先の列車に乗って前記駅構内で列車を乗り換える乗換者数の和と等しいものとし、
    前記降車人数は、前記値ＯＵＴと前記路線方面別の配分比率の積と、乗換元の列車を降りて前記駅構内で列車を乗り換える乗換者数の和と等しいものとし、前記滞留人数を計算する、
    請求項８に記載のデータ処理システム。

Images