JP6322048B2 - 混雑予測装置及び混雑予測方法 - Google Patents

Description

本発明は、混雑予測装置及び混雑予測方法に関する。

特に都市部において、交通機関の混雑緩和を図ることが、乗客に対するサービス向上の観点及び安全確保の観点から強く要求されている。交通事業者は、将来における混雑状況を予測し、混雑緩和に役立てる。例えば、鉄道の場合、交通事業者は、あらかじめ混雑が予測される区間及び時刻帯において臨時便を増発する。特許文献１の車両混雑状況予測システムは、鉄道列車を構成する車両ごとに混雑率を予測する。すなわち、乗客は、降車駅の出口、階段等の近くに停車する車両に乗り込むことが多い。このことを利用して、特許文献１の車両混雑状況予測システムは、改札口を通過した乗客の行先（降車駅）ごとの人数を知ることによって、列車の車両ごとの混雑率を算出する。

特開２００７−２４９２７７号公報

例えば、多くの人員を集客するイベント（催物）が行われる会場近辺の鉄道駅を想定する。イベントが始まる数時間前から、イベントに参加するために当該駅で降車する乗客が徐々に増加し始める。そして、イベントが終了すると、当該駅で乗車する乗客が突発的に増加し、当該駅の混雑はピークに達する。そして、そのピークは、あたかも波動のように、当該駅を中心にして周辺の駅に伝わって行く。交通事業者は、イベント終了後の輸送力強化、安全確保に注力する必要がある。

特許文献１のシステムは、乗客が駅へ入場する際の情報を利用するにすぎない。よって、交通事業者が特許文献１のシステムを使用したとしても、イベント終了後の乗客の移動が始まる前にイベント終了後の混雑を予測することはできない。定期的に行われるイベントについての過去の経験則を使用して、当該イベント終了後の混雑を予測することができなくはない。しかし、定期的に行われるイベントであっても、参加する人員は常に変化している。さらに、過去に同種の例がない新規のイベントについては、経験則自体が存在しない。
そこで、本発明は、イベントが終了した後の乗客の流れを高精度で予測することを目的とする。

本発明の混雑予測装置は、乗客による交通機関の利用履歴が記憶される交通機関利用者情報を格納する記憶部と、イベントが開催される会場の近辺に通じる交通機関の停車場を示す情報を受け付け、交通機関利用者情報を参照し、イベントの開催日のイベント開始時刻前において停車場で降車した乗客の数が、当該イベントが開催されない日に比して増加した増加分を算出し、算出した増加分に基づいて、イベント終了時刻後の交通機関の混雑を予測する制御部と、を備えることを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、イベントが終了した後の乗客の流れを高精度で予測することが可能になる。

本実施形態の概要を説明する図である。 本実施形態に係る予測モデルを説明する図である。 本実施形態に係る予測モデルが行う教師付き学習について説明するを示す図である。 本実施形態に係る混雑予測装置の構成等を説明する図である。 （ａ）は、本実施形態に係る環境情報の一例を示す図であり、（ｂ）は、本実施形態に係る個人情報の一例を示す図であり、（ｃ）は、本実施形態に係るエリア情報の一例を示す図である。 （ａ）は、本実施形態に係るイベント情報の一例を示す図であり、（ｂ）は、本実施形態に係る交通機関利用者情報の一例を示す図である。 （ａ）は、本実施形態に係る移動パタン情報の一例を示す図であり、（ｂ）は、本実施形態に係る参加候補者情報の一例を示す図である。 本実施形態に係る属性付参加候補者情報の一例を示す図である。 本実施形態に係る混雑予測処理手順のフローチャートである。 本実施形態に係るイベント表示画面の一例を示す図である。 本実施形態に係るイベント参加者移動予測画面の一例を示す図である。 本実施形態に係るイベント参加者属性表示画面の一例を示す図である。 本実施形態に係る混雑予測詳細表示画面の一例を示す図である。 本実施形態に係る非定時イベント表示画面の一例を示す図である。 本実施形態に係る交通整備員配置画面の一例を示す図である。 本実施形態に係る運行管理支援画面の一例を示す図である。 本実施形態に係る運行計画変更画面の一例を示す図である。 本実施形態に係る混雑回避ルート提案画面の一例を示す図である。 本実施形態に係るイベント登録画面の一例を示す図である。

以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら説明する。本実施形態は、鉄道の駅の例を主として説明している。しかしながら、本発明の適用範囲は、鉄道の駅に限定されることなく、例えば、路線を通行するバス、タクシーを含む多くの交通機関が発着する停車場に対して適用可能である。本実施形態においては、停車場の一例として“駅”を採用する。

（本実施形態の概要）
図１に沿って、本実施形態の概要を説明する。都心の大規模イベント会場の例として、“Ｔ野球場”を挙げる。Ｔ野球場周辺には、多くの鉄道駅、バス停留所等が存在する。その一例として、ＪＲ線の“水道橋駅”を挙げる。いま、ある金曜日の夕刻から夜にかけて、Ｔ野球場においてプロ野球公式ゲームが開催されるとする。当該ゲームが終了した直後に水道橋駅から乗車する乗客の行先別の人数を知ることが、本実施形態の課題である。水道橋駅を利用する乗客は、交通ＩＣカード又は乗車券を改札装置に通す。よって、交通事業者（単に“駅”とも呼ぶ）は、水道橋駅で降車した乗客の乗車駅を知ることができる。当該ゲーム開始時刻以前に水道橋駅で降車した乗客のなかに、Ａさん、Ｂさん、Ｃさん及びＤさんがいたとする。このうちの誰が当該ゲームを観に来た乗客であるかを知ること、さらに、そのような乗客がどの駅まで帰るかを知ることが課題となる。

Ａさんは通学定期券（交通ＩＣカードに記憶されている）を使用する高校生であり、自宅近辺の中野駅で乗車し、通学する高校に近い水道橋駅で降車することを平日繰り返している。よって、駅は、Ａさんは当該ゲームを観に来た乗客ではないと推定する（Ａさんを追跡するわけではない）。このようにイベントを観に来た者ではないと推定される乗客を“定常利用者”と呼ぶ。そして、駅は、Ａさんがその日のうちに水道橋駅で再度乗車し中野駅で降車すると予測する。つまり、推定帰宅先は中野駅であると予測する。
Ｂさんは当日偶然、“○○商店街”に買い物に来た。Ｂさんは、自宅近辺の中野駅で切符を購入したうえで乗車し、水道橋駅で降車している。よって、駅は、Ｂさんが当該ゲームを観に来たと推定する（実際はそうではない）。このようにイベントを観に来たと推定される乗客を“イベント参加候補者”と呼ぶ。そして、駅は、Ｂさんの推定帰宅先も中野駅であると予測する。

Ｃさんは、当該ゲームを観るためにＴ野球場に来た。Ｃさんは、自宅近辺の三鷹駅で切符を購入したうえで乗車し、水道橋駅で降車している。よって、駅は、Ｃさんもイベント参加候補者であると推定する。そして、駅は、Ｃさんの推定帰宅先は三鷹駅であると予測する。
Ｄさんも、当該ゲームを観るためにＴ野球場に来た。Ｄさんは、平日、自宅近辺の国分寺駅と勤務先近辺の三鷹駅との間で通勤定期券（交通ＩＣカードに記憶されている）を使用している。Ｄさんは、当日、運賃がチャージされた交通ＩＣカードを利用して三鷹駅で乗車し、水道橋駅で降車した。よって、駅は、Ｄさんもイベント参加候補者であると推定する。そして、駅は、Ｄさんの推定帰宅先は国分寺駅であると予測する（三鷹駅であると予測してもよい）。

しかしながら、Ｄさんは、当該ゲームを観た後、水道橋駅で乗車して帰宅の途につきいつものように国分寺駅で降車するかといえばそうではない。Ｄさんは、水道橋駅で乗車し当日に限っては両国駅で降車し、仲間と夕食を取り、最終電車（又は翌日の始発電車）で両国駅から国分寺駅に戻る予定である。駅は、Ｄさんの推定帰宅先は国分寺駅（又は三鷹駅）であると予測することはできるが、当日に限ってＤさんがイベント直後に両国駅に向かうことは予測できない。既存の技術とは一線を画し、ここで駅が“Ｄさんがイベント直後に両国駅に向かう”と予測することが、本実施形態の混雑予測装置の特徴の一つである。

（予測モデル）
図２に沿って、予測モデルについて説明する。いま、非常に多数の“事実”が所与であるとする。“事実”とは、端的にいえば、いつ、どのような人物が、どこで、何をしたか、という現実の出来事の集積である。ここで、事実のうち、“いつ”等の、キーとなるような要素を“キー要素”と呼ぶ。キー要素は、１つの事実のなかに複数存在する。図２の例では、１１種類（下線箇所）存在する。そして、１つのキー要素は、他のすべてのキー要素に対して影響を与える。

そこで、キー要素である“ノード”と、ノード間を矢印で接続する“リンク”とを有するネットワークを想定することが可能である。矢印の起点のノードは因果関係の“原因”となるキー要素を示し、矢印の終点のノードは因果関係の“結果”となるキー要素を示す。いま、単純化のために、キー要素のうち“降車駅”が不明であり、他のすべてのキー要素がわかっているとする。つまり、１０個の既知のキー要素に基づいて、１個の未知のキー要素を推定する。すると、本来メッシュ形状のネットワークを、“降車駅”のノードを中心とするスター形状のネットワークに単純化することができる。

個々のノードは、複数の成分を有するベクトルＶ_１、Ｖ_２、Ｖ_３、・・・である。例えば、ノード“季節”のベクトルＶ_１は、四季に対応する４つの成分を有し、いずれか１つの成分が“１”であり、他のすべての成分が“０”である。ベクトルＶ_１に対し、重みＷ_１が乗算される。Ｗ_１もまた４つの成分を有するベクトルである。よって、Ｗ_１とＶ_１との内積（同じ位置の成分同士の積の和）が定義できる。重みは、“降車駅”以外のあるノードが、“降車駅”のノードに対して与える影響の大きさを示している。たとえば、季節が“春”であることが、ある駅で降車することの大きな要因となっているような場合（飯田橋駅は桜の名所である）、Ｖ_１の１番目の成分に対応するＷ_１の１番目の成分“α_１”は大きな正値となる。

以上では、ノード“季節”について説明したが、他のノードについても同じことがあてはまる。ただし、Ｖ_１、Ｖ_２、Ｖ_３、・・・のそれそれぞれの成分の数は異なる。例えば、Ｖ_２は７つの要素を有し、Ｖ_３は駅の数だけの成分を有する。したがって、Ｗ_２は７つの成分を有し、Ｗ_３は駅の数だけの成分を有することになる。

（学習）
図３に沿って、予測モデルが行う教師付き学習について説明する。
ステップＳ１：混雑予測装置は、Ｗ_１、Ｗ_２、Ｗ_３、・・・の各成分の初期値を無作為に設定する。そして、ａ駅で降車したすべての事実を使用してＱ（ａ駅）を算出する。
なお、Ｑ（ａ駅）＝Σ（Ｗ_ｉ*Ｖ_ｉ）である。そして、右辺の“ｉ”は、各ノードを示し、ｉ＝１，２，・・・，１０である。“＊”はベクトルの内積を求める演算を示す。
同様に、混雑予測装置は、Ｑ（ｂ駅）、Ｑ（ｃ駅）、・・・を算出する。最後に、Ｑ（ａ駅）、Ｑ（ｂ駅）、Ｑ（ｃ駅）、・・・のそれぞれを、Ｑ（ａ駅）、Ｑ（ｂ駅）、Ｑ（ｃ駅）、・・・の合計値で除算することによって、各駅で降車する確率を算出する。

ステップＳ２：混雑予測装置は、すべての事実を使用して、実際にａ駅で降車した比率Ｐ（ａ駅）を算出する。
Ｐ（ａ駅）＝ａ駅で降車した事実の数／事実の総数、である。
同様に、混雑予測装置は、Ｐ（ｂ駅）、Ｐ（ｃ駅）、・・・を算出する。

ステップＳ３：混雑予測装置は、スコア＝（Ｑ（ａ駅）−Ｐ（ａ駅））^２＋（Ｑ（ｂ駅）−Ｐ（ｂ駅））^２＋（Ｑ（ｃ駅）−Ｐ（ｃ駅））^２＋・・・を算出する。

ステップＳ４：混雑予測装置は、Ｗ_１、Ｗ_２、Ｗ_３、・・・の各成分の値を無作為に変化させて、ステップＳ１〜Ｓ３を繰り返す。繰り返しの回数は任意であるが、多ければ多いほど望ましい。この繰り返し処理を終了した段階で、混雑予測装置は、繰り返しの回数に等しいスコアを保持している。

ステップＳ５：混雑予測装置は、スコアのうち値が最小であるものを特定する。そして、その最小のスコアが算出されたときの、Ｗ_１、Ｗ_２、Ｗ_３、・・・の各成分の値を、“学習済重み”として決定する。ここまでの処理が学習処理である。

ステップＳ６：混雑予測装置は、学習処理によって決定した学習済重みを使用して、任意の事実について、各駅で降車する確率を算出する。つまり、キー要素として降車駅だけが不明であり、他のキー要素がわかっている事実について、Ｑ（ａ駅）、Ｑ（ｂ駅）、Ｑ（ｃ駅）、・・・を算出する。このうち、値が最も大きいものがＱ（ｂ駅）である場合、混雑予測装置は、当該事実の降車駅は、ｂ駅であると予測することになる。

以上で明らかなように、本実施形態の混雑予測装置は、交通ＩＣカードに記憶されている乗車駅のデータを使用しなくても、乗客の推定帰宅先を予測できる。具体的には、図１の例において、Ｄさんがイベント終了後両国駅に向かうことを予測できる。なお、予測モデルを使用して予測した推定帰宅先を“モデル移動先”と呼ぶことがある。

（混雑予測装置）
図４に沿って、混雑予測装置１の構成等を説明する。混雑予測装置１は、一般的なコンピュータである。混雑予測装置１は、中央制御装置１１、キーボード、マウス等の入力装置１２、ディスプレイ等の出力装置１３、主記憶装置１４、補助記憶装置１５及び通信装置１６を有する。これらはバスによって相互に接続されている。主記憶装置１４における、イベント参加者推定部２１及び混雑予測部２２は、プログラムである。以降、“○○部は”と主体を記した場合は、中央制御装置１１が、補助記憶装置１５から各プログラムを読み出し、主記憶装置１４にロードしたうえで、各プログラムの機能（詳細後記）を実現するものとする。補助記憶装置１５は、環境情報３１、個人情報３２、エリア情報３３、イベント情報３４、交通機関利用者情報３５、移動パタン情報３６、参加候補者情報３７、属性付参加候補者情報３８を記憶する。混雑予測装置１は、ネットワーク４を介して、携帯端末装置２及び外部サーバ３と通信可能である。

（環境情報）
図５（ａ）に沿って、環境情報３１を説明する。環境情報３１は、日付欄１０１に記憶された日付に関連付けて、曜日欄１０２には曜日が、平日／休日欄１０３には平日／休日の区別が、天候欄１０４には天候が、季節欄１０５に季節が記憶されている。
日付欄１０１の日付は、過去の日付である。
曜日欄１０２の曜日は、七曜（日、月、火、水、木、金、土）のいずれかである。
平日／休日欄１０３の平日／休日の区別は、土曜、日曜及び祝日を示す“休日”、又は、それ以外を示す“平日”のいずれかである。

天候欄１０４の天候は、その日付における天候である。天候には、快晴、晴れ、曇り、雨、雪、・・・等が含まれる。１日のうちで天候が変化した場合は、最も時間の長かったものが記憶される。
季節欄１０５の季節は、四季（春、夏、秋、冬）のうちのいずれかである。
環境情報３１のレコードは、例えば現在から遡って直近の１年分存在する。イベント参加者推定部２１は、外部サーバ３にアクセスして環境情報３１を取得する。

（個人情報）
図５（ｂ）に沿って、個人情報３２を説明する。個人情報３２においては、個人ＩＤ欄１１１に記憶された個人ＩＤに関連付けて、性別欄１１２には性別が、年齢欄１１３には年齢が、職業欄１１４には職業が、住所欄１１５には住所が記憶されている。
個人ＩＤ欄１１１の個人ＩＤは、交通機関の乗客となり得る個人を一意に特定する識別子である。ここでの個人とは、典型的には、交通ＩＣカードのユーザである。しかしながら、他にも例えば、ＧＰＳ（Global Positioning System）技術が使用できる携帯端末装置２のユーザであってもよい。

性別欄１１２の性別は、個人の性別（男又は女）である。
年齢欄１１３の年齢は、個人の年齢である。
職業欄１１４の職業は、個人の職業である。
住所欄１１５の住所は、個人の住所である。
イベント参加者推定部２１は、自社又は他社の外部サーバ３にアクセスして個人情報３２を取得する。他社から取得する場合は、氏名を除いて取得してもよい。

（エリア情報）
図５（ｃ）に沿って、エリア情報３３を説明する。エリア情報３３においては、エリアＩＤ欄１２１に記憶されたエリアＩＤに関連付けて、食事欄１２２には食事適合度が、買い物欄１２３には買い物適合度が、娯楽欄１２４には娯楽適合度が、観光欄１２５には観光適合度が記憶されている。

エリアＩＤ欄１２１のエリアＩＤは、エリアを一意に特定する識別子である。エリアとは、乗客がある交通機関に乗車又は降車することができる施設（典型的には、鉄道の駅、路線バスの停留所）を含む地理上の範囲である。そして、本実施形態においては、エリアと交通機関の駅等は、１対１に対応している。したがって、エリアＩＤは、交通機関の駅を一意に特定する識別子でもある。ここでの地理上の範囲の形状及び面積は、任意に設定され得る。例えば、“駅を含む半径２００ｍの円の内部”等であってもよい。

食事適合度、買い物適合度、娯楽適合度、及び、観光適合度は、そのエリアの特性を示す指標値（１〜１０の整数値のいずれか）である。例えば、食事適合度は、そのエリアに含まれる飲食店数に基づき決定される。買い物適合度は、そのエリアに含まれる商店数に基づき決定される。娯楽適合度は、そのエリアに含まれる娯楽施設（映画館等）数に基づき決定される。観光適合度は、そのエリアに含まれる観光スポット（免税土産店等）数に基づき決定される。イベント参加者推定部２１は、自社又は他社の外部サーバ３にアクセスして、エリア情報３３を取得する。

（イベント情報）
図６（ａ）に沿って、イベント情報３４を説明する。イベント情報３４においては、場所欄１３１に記憶された位置情報に関連付けて、開始時刻欄１３２には開始時刻が、終了時刻欄１３３には終了時刻が、影響交通機関欄１３４には影響交通機関が、イベント規模欄１３５にはイベント規模が、イベント種類欄１３６にはイベント種類が、会場名欄１３７には会場名が、年代欄１３８には年齢層別構成比が、性別欄１３９には性別構成比が記憶されている。

場所欄１３１の位置情報は、イベントが開催される会場の位置情報（緯度及び経度）である。
開始時刻欄１３２の開始時刻は、イベントが開始する時点の年月日時分である。
終了時刻欄１３３の終了時刻は、イベントが終了する時点の年月日時分である。
影響交通機関欄１３４の影響交通機関を説明する前提として、まず“交通機関”を定義する。“交通機関”とは、駅等の名称と、“鉄道”、“バス”等の交通手段との組み合わせである。鉄道の路線が複数存在する場合、“鉄道”又は“バス”等を“◎◎電鉄○○線”、“◎◎電鉄△△線”のようにより細かく表現してもよい。ある駅等に通じている交通手段が１つしかない場合、駅等の名称のみを以て交通機関とする。交通機関のうち、イベントによって影響を受ける交通機関を“影響交通機関”と呼ぶ。影響交通機関は、多くの場合、イベントが開催される会場の近辺の駅、停留所等である。

イベント規模欄１３５のイベント規模は、イベントに集まることが予測される人数である。
イベント種類欄１３６のイベント種類は、イベントのカテゴリであり、例えば、コンサート、野球公式ゲーム、美術展覧会等である。
会場名欄１３７の会場名は、イベントが開催される会場の名称である。
年代欄１３８の年齢層別構成比は、イベントに集まることが予測される人員の年齢構成を、年代ごとの比率で示したものである（和が１００％になる）。
性別欄１３９の性別構成比は、イベントに集まることが予測される人員の男女構成比率である（和が１００％になる）。

イベント参加者推定部２１は、混雑予測装置１のユーザが入力装置１２を介して入力したデータをイベント情報３４として記憶する。イベント参加者推定部２１は、例えば図１９のイベント登録画面７０を出力装置１３に表示し、ユーザの入力を受け付けてもよい。
なお、ユーザが影響交通機関欄５０１において駅名を選択する前に“自動選択”ボタン５０２を押下すると、イベント参加者推定部２１は、会場を中心に所定の距離の範囲内にある影響交通機関の全部又は一部を別ウインドウに表示する。ユーザは、必要に応じてそのなかの一つを選択する。ユーザが“手動選択”ボタン５０３を押下すると、イベント参加者推定部２１は、例えば路線ごとの駅名一覧等を表示する。ユーザは、そのなかの一つを選択する。ユーザが“履歴から選択”ボタン５０４を押下すると、イベント参加者推定部２１は、ユーザが同じ会場について過去に選択した影響交通機関を表示する（必ずしも最寄駅等ではない）。ユーザは、そのなかの一部を選択する。

（交通機関利用者情報）
図６（ｂ）に沿って、交通機関利用者情報３５を説明する。交通機関利用者情報３５においては、個人ＩＤ欄１４１に記憶された個人ＩＤに関連付けて、エリアＩＤ欄１４２にはエリアＩＤが、利用時刻欄１４３には利用時刻が、利用種別欄１４４には利用種別が、交通機関欄１４５には交通機関が記憶されている。

個人ＩＤ欄１４１の個人ＩＤは、図５（ｂ）の個人ＩＤと同じである。
エリアＩＤ欄１４２のエリアＩＤは、図５（ｃ）のエリアＩＤと同じである。
利用時刻欄１４３の利用時刻は、交通機関の利用者（＝乗客）が、交通機関を利用した時点の年月日時分である。
利用種別欄１４４の利用種別は、乗客が交通機関に乗車したことを示す“出発”、又は、乗客が交通機関から降車したことを示す“到着”のいずれかである。なお、“出発”した駅等が判明していなければ乗客がイベント終了後に向かう行き先が決定できないわけではないことは、前記した通りである。
交通機関欄１４５の交通機関は、前記した交通機関である。但し、ここでは駅等の名称は省略されてもよい（エリアＩＤが駅等を特定する）。交通機関は、“○○電鉄◎◎線”のようにより詳細な情報を有するものであってもよい。

因みに、交通機関利用者情報３５の１行目及び２行目のレコードを参照すると、以下のことがわかる。
・２０１４年１月１日１２時００分、個人ＩＤが“Ａ０００１”である乗客は、エリアＩＤが“１０００１”であるエリアに位置する鉄道の駅で乗車した。
・２０１４年１月１日１２時１５分、当該乗客は、エリアＩＤが“１０００２”であるエリアに位置する鉄道の駅で降車した。

（交通機関利用者情報の作成方法）
イベント参加者推定部２１は、外部サーバ３から素材となる様々なデータを取得し、それらを加工して交通機関利用者情報３５を作成する。素材となるデータの例としては、以下が挙げられる。
・交通ＩＣカードデータ：乗客が交通ＩＣカードを使用（商品の購入、交通機関の利用）した履歴からなる。
・改札乗降データ：交通ＩＣカードデータと一部重複するが、乗客が、交通ＩＣカードを駅等の改札装置に通した履歴からなる。

・ＧＰＳデータ：乗客が、駅等の近辺で携帯端末装置２を使用して通信した履歴、及び、駅等の近辺の店舗で携帯端末装置２を使用して商品を購入した履歴からなる。携帯端末装置２は、ＧＰＳ衛星から受信した電波を解析して、自身の位置情報を取得できるものとする。さらに、位置情報の時系列変化から取得した移動速度に基づいて、乗客が利用している交通機関の種類を特定することもできる。
・タクシー乗降データ：タクシーの乗客が、任意のカード又は携帯端末装置２を支払手段として使用した履歴からなる。

・バス乗降データ：バスの乗客が、任意のカード又は携帯端末装置２を支払手段として使用した履歴からなる。
・プローブカーデータ：乗客が自身または他人の自家用車に乗りこみ、カーナビゲーション装置等の機器を操作した履歴からなる。

これらの素材となるデータは、異なるデータ構成を有する。そこで、混雑予測装置１のイベント参加者推定部２１は、これらの素材を加工し、例えば図６（ｂ）の交通機関利用者情報３５のような型式に整える。具体的には、まず、“鉄道”、“バス”、“タクシー”、“その他”というように、交通手段ごとに素材となるデータを分類する。その後、“出発”及び“到着”のレコードの組み合わせ（図６（ｂ）の１行目及び２行目の組み合わせ、又は、３行目及び４行目の組み合わせ）の型式に素材となるデータを加工する。なお、ＧＰＳデータ及びプローブカーデータにおいては、“到着”の判定が困難である場合もある。この場合、混雑予測装置１のイベント参加者推定部２１は、一定時間のエリア内滞在を以て“到着”したと判断してもよい。

（移動パタン情報）
図７（ａ）に沿って、移動パタン情報３６を説明する。移動パタン情報３６においては、出発エリアＩＤ欄１５１に記憶された出発エリアＩＤに関連付けて、到着エリアＩＤ欄１５２には到着エリアＩＤが、交通機関欄１５３には交通機関が、移動ルート欄１５４には移動ルートが記憶されている。

出発エリアＩＤ欄１５１の出発エリアＩＤは、出発点の駅等を含むエリアを特定するエリアＩＤである。
到着エリアＩＤ欄１５２の到着エリアＩＤは、到着点の駅等を含むエリアを特定するエリアＩＤである。
交通機関欄１５３の交通機関は、図６（ｂ）の交通機関と同じである。但し、ここでは、駅等の名称は省略されている。
移動ルート欄１５４の移動ルートは、その交通機関を使用して出発点から到着点へ行く場合の最短ルートである。
イベント参加者推定部２１は、混雑予測装置１のユーザが入力装置１２を介して入力したデータを移動パタン情報３６として記憶する。

（参加候補者情報）
図７（ｂ）に沿って、参加候補者情報３７を説明する。参加候補者情報３７においては、イベント参加候補者ＩＤ欄１６１に記憶されたイベント参加候補者ＩＤに関連付けて、交通機関欄１６２には交通機関が、出発エリアＩＤ欄１６３には出発エリアＩＤが、到着時刻帯欄１６４には到着時刻帯が、イベント参加確率欄１６５にはイベント参加確率が記憶されている。

イベント参加候補者ＩＤ欄１６１のイベント参加候補者ＩＤは、到着点の駅等で実際に降車した個人を特定する個人ＩＤである。ただし、ここでの個人は、イベントに参加することを目的として到着点の駅等で降車したと推定された者（イベント参加候補者）に限定されるものとする（詳細後記）。当該欄１６１には非常に多くの個人ＩＤが記憶される。
交通機関欄１６２の交通機関は、図６（ｂ）の交通機関と同じである。
出発エリアＩＤ欄１６３の出発エリアＩＤは、図７（ａ）の出発エリアＩＤと同じである。

到着時刻帯欄１６４の到着時刻帯は、到着点の駅等に乗客が到着した時点を含む時刻帯である。図の例では、時刻帯の長さは、１５分である。
イベント参加確率欄１６５のイベント参加確率は、イベント参加候補者ＩＤ欄１６１に記憶されている個人ＩＤが特定する個人が、実際にイベントに参加した者である確率である（詳細後記）。
イベント参加者推定部２１は、混雑予測処理手順において、参加候補者情報３７を作成する（詳細後記）。

（属性付参加候補者情報）
図８に沿って、属性付参加候補者情報３８を説明する。属性付参加候補者情報３８においては、イベント参加候補者ＩＤ欄１７１に記憶されたイベント参加候補者ＩＤに関連付けて、交通機関欄１７２には交通機関が、出発エリアＩＤ欄１７３には出発エリアＩＤが、到着時刻帯欄１７４には到着時刻帯が、イベント参加確率欄１７５にはイベント参加確率が、登録住所エリアＩＤ欄１７６には登録住所エリアＩＤが、乗客タイプ欄１７７には乗客タイプが、年代欄１７８には年代が、性別欄１７９には性別が、職業欄１８０には職業が記憶されている。

属性付参加候補者情報３８の欄１７１〜欄１７５は、参加候補者情報３７（図７（ｂ））の欄１６１〜欄１６５と同じである。ただし、図７（ｂ）のイベント参加候補者ＩＤ欄１６１には、複数の個人ＩＤが記憶されている一方、図８のイベント参加候補者ＩＤ欄１７１には、個人ＩＤが１つしか記憶されていない。つまり、属性付参加候補者情報３８のレコードは、個々の乗客ごとに作成されている。

登録住所エリアＩＤ欄１７６の登録住所エリアＩＤは、イベント参加候補者ＩＤが特定する乗客の登録住所（詳細後記）があるエリアのエリアＩＤである。
乗客タイプ欄１７７の乗客タイプは、“旅行者”又は“地域住民”のいずれかである（詳細後記）。
年代欄１７８の年代は、乗客の年齢が含まれる年齢層である。
性別欄１７９の性別は、乗客の性別である。
職業欄１８０の職業は、乗客の職業である。
イベント参加者推定部２１は、混雑予測処理手順において、属性付参加候補者情報３８を作成する（詳細後記）。

（混雑予測処理手順）
図９に沿って、混雑予測処理手順を説明する。
ステップＳ３０１において、イベント参加者推定部２１は、影響を受ける移動パタンを抽出する。具体的には、第１に、イベント参加者推定部２１は、ユーザが、入力装置１２を介して影響交通機関を入力するのを受け付ける。いま、“鉄道”及び“水道橋駅”が入力されたとする。
第２に、イベント参加者推定部２１は、“水道橋駅”が位置するエリアのエリアＩＤ、及び“鉄道”を検索キーとして、移動パタン情報３６（図７（ａ））の、それぞれ到着エリアＩＤ欄１５２及び交通機関欄１５３を検索する。そして、該当したレコードを取得する。

ステップＳ３０２において、イベント参加者推定部２１は、到着数を比較する。具体的には、第１に、イベント参加者推定部２１は、ステップＳ３０１の“第２”で検索キーとしたエリアＩＤ、“鉄道”及び“到着”を検索キーとして、交通機関利用者情報３５（図６（ｂ））を検索し、該当したレコードをすべて取得する。
第２に、イベント参加者推定部２１は、ステップＳ３０２の“第１”で取得したレコードを、現時点の日付を有する第１の群と、それ以前の日付を有する第２の群に分類する。第１の群のレコード数は、イベント当日の午前０時から現時点までに、鉄道を利用して水道橋駅で降車した乗客の数に等しい。いま、“午前０時００分から現時点まで”の時刻帯を“イベント前時刻帯”と呼び、第１の群のレコード数を“当日乗客数”と呼ぶ。

第３に、イベント参加者推定部２１は、イベント前時刻帯に属する利用時刻を有するレコードを第２の群から抽出し、抽出したレコードの数を日数で除算する。当該除算結果の数は、過去において、イベント前時刻帯に水道橋駅で降車した乗客の１日あたりの平均値である。当該平均値を“過去乗客数”と呼ぶ。なお、平均値を求める際、別件イベントが行われていない日を除くことが好ましい。
第４に、イベント参加者推定部２１は、当日乗客数から過去乗客数を減算し、減算結果を“到着者増加数”として保持する。

ステップＳ３０３において、イベント参加者推定部２１は、到着数が増加しているか否かを判断する。具体的には、イベント参加者推定部２１は、ステップＳ３０２の“第４”において保持した到着者増加数が所定の閾値以上である場合（ステップＳ３０３“ＹＥＳ”）、ステップＳ３０４に進む。それ以外の場合（ステップＳ３０３“ＮＯ”）、イベントによって交通機関が混雑する可能性はないと決定し、混雑予測処理手順を終了する。
イベント参加者推定部２１は、当日の例えば８時００分、８時１５分、８時３０分、・・・のようなタイミングで周期的にステップＳ３０２及びＳ３０３の処理を繰り返してもよい。この例でのイベント参加者推定部２１は、到着者増加数が有意な水準に達した時点で初めて以降のステップに進むことになる。

ステップＳ３０４において、イベント参加者推定部２１は、到着者を分類する。具体的には、第１に、イベント参加者推定部２１は、第１の群のレコードから個人ＩＤを取得する。
第２に、イベント参加者推定部２１は、ステップＳ３０４の“第１”で取得した個人ＩＤを有するレコードを、第２の群から抽出し、抽出したレコード数が、すべての週において所定の数（例えば“４”）以上である場合は、その個人ＩＤが特定する乗客は“定常利用者”であるとする。それ以外の場合は、その個人ＩＤが特定する乗客は“イベント参加候補者”であるとする。つまり、イベント参加者推定部２１は、定常的な利用履歴を有する“定常利用者”、又は、それ以外の“イベント参加候補者”のいずれかに乗客を分類する。

ステップＳ３０５において、イベント参加者推定部２１は、イベント参加確率を算出する。イベント参加確率は、到着時刻帯ごとに、到着者増加数をイベント参加候補者の数で除算した値である。

ステップＳ３０６において、イベント参加者推定部２１は、参加候補者情報３７（図７（ｂ））のレコードを作成する。具体的には、イベント参加者推定部２１は、交通機関、出発エリアＩＤ及び到着時刻帯の組み合わせごとに、イベント参加候補者を集計し、参加候補者情報３７のレコードを作成する。作成されたレコードのイベント参加確率欄１６５には、ステップＳ３０５において算出されたイベント参加確率が記憶されることになる（後記する“拡張機能３”も参照）。
イベント参加者推定部２１は、ステップＳ３０４〜Ｓ３０６の処理を、交通機関ごと、かつ、到着時刻帯ごとに繰り返す。繰り返し処理が終了した段階で、イベント参加者推定部２１は、水道橋駅について、図７（ｂ）のようなイベント参加候補者情報３７を完成していることになる。

ステップＳ３０７において、イベント参加者推定部２１は、乗客タイプ及び登録住所を取得する。具体的には、第１に、参加候補者情報３７（図７（ｂ））のレコードを個々のイベント参加候補者ごとに分解する。
第２に、イベント参加者推定部２１は、個々のイベント参加候補者の乗客タイプを決定する。交通機関利用者情報３５の第２の群（過去データ）のレコードのうち“出発”を有するレコードに、あるイベント参加候補者の個人ＩＤが記憶されているとする。そして、それらのレコードのうち、水道橋駅を中心として所定の距離の範囲内にあるエリアを示すエリアＩＤを有するレコードの数が所定の数以上あるとする。この場合、イベント参加者推定部２１は、当該イベント参加候補者の乗客タイプは、“地域住民”であると推定する。それ以外の場合、イベント参加者推定部２１は、当該イベント参加候補者の乗客タイプは、“旅行者”であると推定する。

第３に、イベント参加者推定部２１は、個々のイベント参加候補者の登録住所を決定する。すなわち、イベント参加候補者の乗客タイプが“地域住民”であると推定され、かつ、個人情報３２（図５（ｂ））において当該イベント参加候補者の住所がわかる場合、イベント参加者推定部２１は、当該住所のエリアＩＤを当該イベント参加候補者の登録住所エリアＩＤとする。イベント参加候補者の乗客タイプが“旅行者”であると推定された場合、又は、“地域住民”と推定されても個人情報３２において住所がわからない場合、イベント参加者推定部２１は、過去データの出発点のエリアＩＤを参加候補者の登録住所エリアＩＤとする。

ステップＳ３０８において、イベント参加者推定部２１は、乗客の属性を取得する。具体的には、イベント参加者推定部２１は、個々のイベント参加候補者の性別、年齢及び職業を個人情報３２（図５（ｂ））を参照することによって取得する。個人情報３２を参照することによって年齢及び／又は性別が取得できない場合、イベント参加者推定部２１は、イベント情報３４（図６（ａ））の当日開催されるイベントのレコードを参照し、最も構成比の高い年代及び性別を取得してもよい。

ステップＳ３０９において、イベント参加者推定部２１は、属性付参加候補者情報３８（図８）を完成する。具体的には、イベント参加者推定部２１は、ステップＳ３０７の“第１”で分解した、個々のイベント参加候補者のレコードに、登録住所エリアＩＤ、乗客タイプ、年代、性別及び職業を追加して記憶する。

ステップＳ３１０において、イベント参加者推定部２１は、イベント後の乗客の移動先を推定する。具体的には、第１に、イベント参加者推定部２１は、属性付参加候補者情報３８、環境情報３１及びエリア情報３３を参照して、あるイベント参加候補者の“キー要素”を取得する。そして取得したキー要素を前記した予測モデルに対して適用することによって、当該イベント参加候補者がイベント終了後に向かう先（＝モデル移動先）を予測する。モデル移動先は、例えば鉄道の駅（降車駅）である。
第２に、イベント参加者推定部２１は、属性付参加候補者情報３８に新たに“モデル移動先”欄を設け（図示せず）、当該欄に予測したモデル移動先を記憶する。
イベント参加者推定部２１は、ステップＳ３１０の処理をすべてのイベント参加候補者について繰り返す。

ステップＳ３１１において、イベント参加者推定部２１は、移動先ごとの移動人数を算出する。具体的には、イベント参加者推定部２１は、第１に、属性付参加候補者情報３８を、交通機関ごと、かつ、移動先ごとに集計し、集計したレコードのイベント参加確率を合計する。この合計数が、イベント終了時刻において一斉に会場から駅等に向かうと予測される人数となる。そして、イベント参加者推定部２１は、合計数を、当該交通機関ごと、かつ、当該モデル移動先ごとの“移動人数”とし、“交通機関別移動情報”を作成する。交通機関別移動情報は、（交通機関，モデル移動先，移動人数）＝（鉄道，両国駅，１０００人），（鉄道，千葉駅，１５００人），（鉄道，横浜駅，８００人），・・・というデータである。

第２に、イベント参加者推定部２１は、交通機関別移動情報の各“（交通機関，モデル移動先，移動人数）”の移動人数に対して、交通機関が同じであって、かつ移動先がモデル移動先と同じである乗客の過去乗客数を加算し、“交通機関別混雑情報”を作成する。交通機関別混雑情報は、[交通機関，モデル移動先，移動人数]＝[鉄道，両国駅，１９００人]，[鉄道，千葉駅，１８００人]，[鉄道，横浜駅，１２００人]，・・・というデータである。“[ ， ，]”の移動人数は、過去の平均値である過去乗客数に比して、イベント参加候補者の人数分だけ多くなっている。当該“交通機関別混雑情報”は、後記する画面表示の際の基礎データとして活用される。

ステップＳ３１２において、混雑予測部２２は、画面表示を行う。混雑予測部２２は、多くの画面を出力装置１３に表示する。それぞれの画面の内容は以下に詳しく示すこととし、混雑予測処理手順の説明はここで終了する。

（表示画面）
混雑予測部２２が表示する画面は、全部で２系統、９種類ある。第１の系統は、イベント終了後の混雑の様子を表示するためのものであり、イベント表示画面６１（図１０）、イベント参加者移動予測画面６２（図１１）、イベント参加者属性表示画面６３（図１２）、及び、混雑予測詳細表示画面６４（図１３）を含む。第２の系統は、５種類の画面を含むが、後記する“拡張機能”のなかで説明する。以降で説明する例は、イベントの会場が“Ｔ野球場”であり、イベント終了後直ちにイベント参加候補者が“Ｔ野球場”から一斉に退出する例である。なお、前記してきた “イベント参加候補者”を図面上は“イベント参加者”と表記している（ユーザに対するわかりやすさのため）が、いずれも同義である。

（イベント表示画面）
図１０に沿って、イベント表示画面６１を説明する。混雑予測部２２は、イベント表示欄４０１に、イベント会場近辺の地図、イベント会場の位置（○及び●）、会場名、終了時刻、イベント規模及び推定参加者数を表示する。推定参加者数は、前記した到着者増加数（平常日からの増分）である。ユーザが、それぞれ、ボタン４０２、４０３及び４０４を押下すると、混雑予測部２２は、それぞれ、イベント登録画面７０（図１９）、イベント参加者移動予測画面６２（図１１）及びイベント参加者属性表示画面６３（図１２）を表示する。ユーザが混雑予測欄４０５のイベント選択欄４０６においてあるイベント（例えば会場名）を選択する。すると、混雑予測部２２は、混雑予測処理手順において取得した交通機関別混雑情報に基づいて、混雑予測欄４０５の欄４０７にそのイベントが終了する時点での混雑予測を表示する。ユーザが、混雑予測欄４０５の“混雑予測詳細情報を表示”ボタン４０８を押下すると、混雑予測部２２は、混雑予測詳細表示画面６４（図１３）を表示する。

（イベント参加者移動予測画面）
図１１に沿って、イベント参加者移動予測画面６２を説明する。混雑予測部２２は、イベント参加者移動先予測欄４１１に、イベント参加者の移動経路を矢印で表示し、当該経路をイベント参加者群が移動して行く様子をアイコン（スマイルマーク）の移動で表示し、特に混雑が発生する位置を円状の網掛けで表示する（凡例は欄４１２）。なお、混雑予測部２２は、混雑の程度に応じて、アイコン及び円状の網掛けの色又は大きさを変化させてもよい。混雑予測部２２は、欄４１３、４１４において、イベントの現在の状況を表示する。

混雑予測部２２は、前記した交通機関別混雑情報を集計することによって、混雑率（混雑率＝当日の乗車人数（交流量）／車両定員（交通容量）×１００（％））を、路線単位、時刻帯単位、上下単位、かつ、区間単位で算出することができる。そこで、混雑予測部２２は、イベント影響による混雑情報欄４１５に、現在発生している混雑及び、将来発生することが予測される混雑を、路線単位、時刻帯単位、上下単位、かつ、区間単位で表示する。さらに、ユーザが特に注目したい路線の“混雑率確認”ボタン４１６を押下すると、混雑予測部２２は、欄４１７に、その路線の混雑マトリクスを表示する。混雑マトリクスは、縦軸に路線の駅名を有し、横軸に時刻（左から右に時間が経過する）を有するマトリクスであり、交点のセルに混雑率が表示される。そして、混雑予測部２２は、混雑率の大きさに応じて、セルの表示態様（色等）を変化させてもよい。

（イベント参加者属性表示画面）
図１２に沿って、イベント参加者属性表示画面６３を説明する。ユーザが予測結果選択欄４２２で、例えば“移動先”を選択する。すると、混雑予測部２２は、イベント参加者属性欄４２１に、イベント参加者のモデル移動先が含まれる地域（例えば、新宿区、港区）ごとに移動人数の大きさをその半径で示す円を表示する。イベントが複数存在する場合、ユーザがイベント選択欄４２３で１つのイベントを選択できる。例えば、選択されたイベントに“１”が割り当てられている場合、混雑予測部２２は、イベント参加者属性欄４２１に、当該イベントの会場の位置を“１”で表示する。そして、“１”のイベントに関する円を同じ態様（色等）で表示し、“２”のイベントに関する円を別の同じ態様で表示することによって、イベントごとのモデル移動先を区別できる。

さらに、ユーザは、イベント参加属性選択欄４２４において属性を選択することもできる。例えばユーザが、年代“１０代”及び性別“女性”を選択した場合、混雑予測部２２は、１０代の女性についての円を、イベント参加者属性欄４２１に表示する。すると、例えば円が大きい地域において、警備を強化し、犯罪リスクを低減することができる。

（混雑予測詳細表示画面）
図１３に沿って、混雑予測詳細表示画面６４を説明する。混雑予測部２２は、イベント会場近辺エリアマップ欄４３１に会場の近辺の交通機関の地図を表示する。地図中の、“Ａ”、“Ｂ”、“１”、“２”等の符号は、イベント影響交通機関欄４３２の符号に対応している。

混雑予測部２２は、イベント参加者移動予測ネットワーク欄４３３に、交通機関別混雑情報に基づいて、イベント終了後にイベント参加者が利用する交通機関を示すスター形状を表示する。スター形状の周辺のノード内の符号は、欄４３１の符号に対応している。例えば、“鉄道Ａ”は“春日駅”である。スター形状の中心と周辺のノードを結ぶ直線の太さは、その駅等に向かう移動人数に比例している。直線の長さは、イベント会場からその交通機関の駅等までの距離に比例している。距離が確定できない場合は、直線は矢印になっている（タクシー及び自家用車）。

混雑予測部２２は、歩行者混雑度予測欄４３４に、イベント終了後に歩行者密度が高くなると予想されるエリアを、円形、楕円形等の図形で表示する。これらの図形は、混雑度に応じて色付けされる。イベント参加者移動予測ネットワーク欄４３３を参照すると、会場から“後楽園駅”に向かうイベント参加者が最も多いことがわかる。すると、混雑予測部２２は、会場から“後楽園駅”の間のエリア（道路、広場等）が最も混雑すると予測し、そのエリアの楕円形を目立つ色で表示する。

混雑予測部２２は、道路混雑度予測欄４３５に、イベント終了後に混雑すると予測される道路を、その混雑度に応じて色付けして表示する。ユーザは、イベント参加者移動予測ネットワーク欄４３３及び道路混雑度予測欄４３５を参照し、イベント参加者が利用する自家用車が混雑の原因になっていると判断した場合、イベント参加者に対して、次回のイベント開催時には公共交通機関を利用することを促すことができる。

混雑予測部２２は、鉄道混雑度予測欄４３６に、イベント終了後に混雑すると予測される鉄道の区間を、その混雑度に応じて色付けして表示する。すると、ユーザは、混雑が予測される駅のホームに駅員を多く配置することができる。

混雑予測部２２は、交通機関利用予測分布欄４３７に、イベント終了後にイベント参加者が利用する交通機関の割合を示す円グラフを表示する。ユーザは、特定の交通機関に利用が偏っているか否かを容易に視認することができる。

混雑予測部２２は、交通機関利用者数詳細予測欄４３８に、ある駅からの路線別かつ上下別の移動人数を表示する。例えば、ユーザが、表示選択欄４３９において、“鉄道Ｂ”（＝“後楽園駅”）を選択したとする。後楽園駅には、“丸ノ内線”及び“南北線”が乗り入れている。よって、混雑予測部２２は、これらの２つの路線の上下を示す計４本の矢印を表示する。矢印の太さは、移動人数に比例している。

（拡張機能について）
前記では、開始時刻及び終了時刻が決まっているイベントについて説明した。例えばサッカーＪリーグのある公式ゲームは、開始時刻が予め決まっている。そして、ゲーム時間（９０分＋ハーフタイム）も決まっているので、終了時刻も予め決まっている。このような場合、観客は、ゲーム時間中は会場に留まり、ゲーム終了時刻に一斉に交通機関に向かうことになる。一方、会場の開門時刻と閉門時刻が決まっているものの、その間、観客が自由に会場に出入りできるようなイベントも存在する。例えば、美術館における展覧会では、午前９時００分の開門時刻から午後４時００分の閉門時刻までに、観客は自由に会場に出入りできる。会場を出る観客が午後４時００分に集中することは通常考えられない。このような場合、どの時点で観客が交通機関に向かうかを予測するには、別途方策が必要になる。以下に説明する拡張機能のそれぞれは、このような課題に対応している。

（拡張機能１：イベント参加候補者の追跡及び滞在時間の算出）
イベント参加者推定部２１は、会場の開門時刻以降、ＩＤ管理情報の取得を継続する。ＩＤ管理情報とは、イベント参加候補者の行動が把握できる任意の情報である。イベント参加候補者が会場を出て交通機関に戻り改札を通過すると、当然その結果は、前記した交通機関利用者情報３５（図６（ｂ））に反映される。このような情報を“移動履歴”と呼ぶ。イベント参加候補者は、会場に滞在する間、店舗又は自動販売機で商品を購入することもある。また、会場に滞在する間、携帯端末装置２を使用して通信することも、インターネットにアクセスすることもある。イベント参加者推定部２１は、このような履歴もＩＤ管理情報として活用することができる。このような履歴を“会場内履歴”と呼ぶ。

イベント参加者推定部２１は、あるイベント参加候補者についての移動履歴が取得できた場合、当該イベント参加候補者の“滞在時間”を算出する。滞在時間とは、交通機関利用者情報３５において、“到着”があった後、次の“出発”があるまでに経過した時間である。さらに、イベント参加者推定部２１は、当該イベント参加候補者が“参加除外者”であると決定する。一方、イベント参加者推定部２１は、あるイベント参加候補者についての会場内履歴が取得できた場合、当該イベント参加候補者が“参加確定者”であると決定する。さらに、イベント参加者推定部２１は、すべてのイベント参加候補者についての滞在時間の平均値を算出して、“平均滞在時間”とする。“平均滞在時間”の活用方法については後記する。

（拡張機能２：会場退出能力）
会場の出口の数が少ない、又は、出口が小さいと、会場から一度に退出できる人数が制限される。ある会場が２箇所の出口を有し、それぞれの出口から同時に３人ずつ退出することが可能であり、退出者の歩行速度が１.０ｍ／秒であり、退出者同士の前後の間隔が０.５ｍであるとする。イベント参加者推定部２１は、会場退出能力を以下のように算出する。
会場退出能力＝２×３×１.０／０.５＝１２（人／秒）＝７２０（人／分）
“会場退出能力”の活用方法については後記する。

（拡張機能３：イベント参加確率の更新）
前記の図９のステップＳ３０６において、イベント参加者推定部２１は、イベント参加候補者を集計している。すなわち、当該処理後の、イベント参加候補者情報３７（図７（ｂ））のレコードは、“イベント参加候補者”についてのものとなっている。しかしながら、イベント参加者推定部２１は、イベント参加候補者情報３７レコードを、“イベント参加候補者”又は“定常利用者”についてのものとしてもよい。そして、そのうえで、以下のように、イベント参加確率を時々刻々と更新してもよい。

いま、属性付参加候補者情報３８（図８）において、ある到着時刻帯、ある交通機関及びある出発エリアＩＤを共有するレコードが５０件存在するとする。そして、イベント参加者推定部２１は、３人のイベント参加候補者が参加確定者であると決定したとする。この場合、イベント参加者推定部２１は、属性付参加候補者情報３８において、参加確定者についての３件のレコードのイベント参加確率を“１.０”に更新する。そして、ステップＳ３０５の処理と同様に、５０件のうち他の４７件のレコードのイベント参加確率を、（到着者増加数−３）／（イベント参加候補者数−３）の値で更新する。

さらに、時間が経過し、イベント参加者推定部２１は、別の４人のイベント参加候補者が参加除外者であると決定したとする。この場合、イベント参加者推定部２１は、属性付参加候補者情報３８において、参加除外者についての４件のレコードのイベント参加確率を“０.０”に更新する。そして、ステップＳ３０５の処理と同様に、４７件のうち他の４３件のレコードのイベント参加確率を、（到着者増加数−３−４）／（イベント参加候補者数−３−４）の値で更新する。
イベント参加者推定部２１は、ステップＳ３１１の“第１”において、このようにして、更新したイベント参加確率が“１”となるイベント参加候補者情報３７のレコードの数を、“合計数”としてもよい。

（拡張機能４：非定時イベント表示画面）
図１４に沿って、非定時イベント表示画面６５を説明する。非定時イベント表示画面６５は、イベント表示画面６１（図１０）に比して、時系列駅情報欄４４１を有している点が異なる。混雑予測部２２が非定時イベント表示画面６５を表示すると、ユーザは、イベント影響交通機関選択欄４４２に駅名を入力する。すると、混雑予測部２２は、交通機関利用者情報３５（図６（ｂ））を参照することによって、降車者数欄４４３に、当該駅で降車する乗客の数を時系列で示した棒グラフ（降車棒グラフ）を表示する。そして、乗車者数欄４４４及び乗車者数予測欄４４６に、当該駅で乗車する乗客の数を時系列で示した棒グラフ（乗車棒グラフ）を表示する。混雑予測部２２は、交通機関別混雑情報のうち、入力された駅名から他の駅等に向かうものを検索し、平均滞在時間も考慮することによって、これらのグラフを表示することができる。

例えば、前記した平均滞在時間（符号４４５）が４時間００分であり、１４時００分〜１４時１５分において降車した乗客の人数が１００人である場合、１８時００分〜１８時１５分において乗車することが予測される乗客の人数も１００人である。ただし、１５分間ごとの乗客の人数の予測値が、前記した会場退出能力を超える場合、混雑予測部２２は、超過分を次の１５分間に繰り越す。

（拡張機能５：交通整備員配置画面）
図１５に沿って、交通整備員配置画面６６（図１５）を説明する。交通整備員配置画面６６のイベント会場近辺エリアマップ欄４５１は、図１３のイベント会場近辺エリアマップ欄４３１と同じである。混雑予測部２２は、交通整備員配置状況欄４５２に、会場近辺の地図、現在配置されている交通整備員を示すマーク、及び駅員数（駅に付された吹き出し内の数）を表示する。交通整備員は、ＧＰＳ技術を使用できる携帯端末装置２を保持している。よって、混雑予測部２２は、交通整備員の位置をリアルタイムで表示することが可能である。

混雑予測部２２は、歩行者混雑度予測欄４３４（図１３）及び交通整備員配置状況欄４５２（図１５）に表示した情報を重ね合わせ、交通整備員配置計画欄４５３に表示する。ユーザは、駅に付された吹き出し内の数字を“５→８”のように変更入力することによって、駅に対して、駅員数の増加を指示することもできる。さらに、駅が自主的に駅員数を増加した結果を知ることもできる。

（拡張機能６：運行管理支援画面）
図１６に沿って、運行管理支援画面６７を説明する。混雑予測装置１は、各路線の列車ダイヤを補助記憶装置１５に格納している（図４では図示せず）。列車ダイヤとは、時刻を横軸とし、路線の起点からの距離を縦軸とした平面上に、列車の軌跡を線で表示したものである。上り方面の列車は右上がりの折れ線となって表現され、下り方面の列車は右下がりの折れ線となって表現されるので、線の交差がダイヤ形状になって出現する。

混雑予測部２２は、運行管理支援画面６７の、運行情報と運行計画欄４６１に、列車ダイヤを表示する。図１６の例では、××線△△方面の列車ダイヤが表示されている。混雑予測部２２は、列車ダイヤのうち、現在時点以前の部分を実線で表示し、現在時点より後の部分を破線で表示している。そして、駅間の混雑率に比例して線の太さを大きくしてもよいし、駅間の混雑率に応じて線の色を変えてもよい。

いま、ユーザが列車ダイヤの縦軸のある駅名（○○駅）を選択したとする。すると、混雑予測部２２は、当該駅を検索キーとしてイベント情報３４（図６（ａ））を検索し、該当するイベントについての情報を、イベント情報欄４６２に表示する。そして、輸送力と待機乗客予測欄４６３に、イベントの開始時刻を示す縦線及び終了時刻を示す縦線を表示する。次に、混雑予測部２２は、交通機関別混雑情報のうち、入力された駅名から他の駅等に向かうものを検索し、平均滞在時間も考慮することによって、乗車者数欄４６４及び乗車者数予測欄４６５に、当該駅で乗車する乗客の数を時系列で示した棒グラフ（乗車棒グラフ）を表示する。

混雑予測部２２は、次の式によって算出される輸送力の水準を示す輸送力線４６６を表示する。
輸送力＝列車の定員×単位時間あたりの列車の本数
輸送力線は、本来、時系列で水準が変化し得る曲線である。図１６の例では、輸送力線は、水平な直線となっている。このことは、定員が同じ列車が等間隔で運行していることを示している。

乗車者数予測欄４６５及び輸送力線４６６に注目すると、以下のことがわかる。
・現在時刻からイベントの終了時刻までの間は、○○駅における乗車者数は低水準で安定している。
・イベントの終了時刻において乗客者数は急に増加している（符号４６７）。
・その後、乗客数（符号４６８）のうち輸送力線を超過している部分は、列車に乗車できずに駅に取り残される。取り残された乗客を“待機乗客”（網掛け部分）という。

・待機乗客は、時刻帯４６９において、当該時刻帯の乗客に加算される。
・時刻帯４６９において待機乗客の数は増加する。
・増加した待機乗客は、時刻帯４７０において、当該時刻帯の乗客に加算される。
・時刻帯４７０において、ようやく待機乗客の一部が乗車できる。
・時刻帯４７１において、待機乗客は新たに発生しなくなる。
・待機乗客予測４７２（待機乗客の延べ人数）は、“ＸＸＸＸ”人である。

待機乗客の発生は、駅近辺の危険度を高めると同時に連鎖的な混雑を発生させる。そこで、ユーザ（交通事業者）は、列車の運行を変更することによって、待機乗客をできるだけ早く解消することが必要になる。ユーザが、“運行計画変更”ボタン４７３を押下すると、混雑予測部２２は、運行計画変更画面６８（図１７）を表示する。

（拡張機能７：運行計画変更画面）
図１７に沿って、運行計画変更画面６８を説明する。運行計画変更画面６８の構成は、運行管理支援画面６７（図１６）に準じる。但し、図１７においては、現在時刻以前の部分が非表示又は変更不能の状態（図ではこの状態を斜線で表す）になっている。
いま、ユーザが、列車ダイヤのうちある部分４８１、４８２、４８３、４８４をマウス等の入力装置１２で掴み、画面上を右側に移動する。つまり、ユーザは、イベント終了時刻の直前に○○駅を発車する１本の列車、及び、イベント終了時刻の直後に○○駅を発車する３本の列車について、○○駅での停車時間を延長しようとしている。

すると、混雑予測部２２は、変更されたダイヤに基づいて、輸送力線及び乗車棒グラフを再度表示する。再度表示された乗車者数予測４８５及び輸送力線４８６に注目すると、図１６との比較において以下のことがわかる。
・輸送力線４８６の水準は、イベント終了時刻の直前に一旦低下する。
・イベント終了時刻の直後に、輸送力線４８６の水準が元の水準以上に上昇し、やがて、元の水準に戻る。
・その結果、待機乗客予測４８７（待機乗客の延べ人数）は、“ＸＸＸＸ”人から“ＸＸＸ”人に減少する。

前記では、ユーザが列車ダイヤを単純に平行移動する例を説明した。しかしながら、臨時列車の列車ダイヤを追加すること、又は、速度（線の傾きとして表現される）を変更することも可能である。

（拡張機能８：混雑回避ルート提案画面）
図１８に沿って、混雑回避ルート提案画面６９を説明する。会場の近辺にいるイベント参加候補者が混雑を避けるルートを知ることができれば、イベント参加候補者及び交通事業者にとって便宜である。そこで、混雑予測部２２は、イベント参加候補者が操作する携帯端末装置２に混雑回避ルート提案画面６９を表示する。

混雑回避ルート提案画面６９の交通機関混雑予測欄４９１は、図１５のイベント会場近辺エリアマップ欄４５１と概ね同じである。但し、図１８においては、混雑予測部２２は、駅等に付した吹き出しのなかに、駅等の混雑度“○”、“△”又は“×”を表示する。“○”の混雑度が最も低く、平常時の平均水準以下である。“△”の混雑度は、平常時の平均水準を超えているが、待機乗客が発生する水準以下である。“×”の混雑度は、待機乗客が発生する水準を超えている。なお、混雑度とは、前記した混雑率を含む、より広い概念である。

混雑予測部２２は、混雑情報欄４９２に、混雑の具体的内容を説明する文章を表示する。携帯端末装置２のユーザ（イベント参加候補者）は、図１８の混雑回避ルート検索欄４９３の目的地欄４９４に自身が行きたい駅名を入力し、検索ボタン４９５を押下する。すると、混雑予測部２２は、駅名を検索キーとして交通機関別混雑情報を検索し、途中区間の混雑率が所定の閾値以下であるルートを、移動時間の短い順に、検索結果欄４９６に表示する。

（拡張機能９：イベント登録の自動化）
前記では、ユーザ（交通事業者）が、イベント登録画面７０に対してイベント情報を入力する例を説明した。しかしながら、イベント参加者推定部２１が当該入力を自動的に実行することも可能である。イベント参加者推定部２１は、ユーザが入力装置１２を介してキーワードを予め入力するのを受け付け、受け付けたキーワードを補助記憶装置１５に格納しておく。キーワードは、“サッカー”、“Ｔ野球場”、“展覧会”等、それを検索キーとしてイベント参加者推定部２１がネットワーク経由で外部サーバ３（ＳＮＳサーバ又はウエブサーバ）にアクセスできるものであれば何でもよい。そして、イベント参加者推定部２１は、取得した情報を、イベント情報３４（図６（ａ））として補助記憶装置１５に格納する。
つまり、イベント参加者推定部２１は、ウエブサイト（例えば、事前登録した情報サイト）やＳＮＳ上の発言等から、自動的にイベントを登録する。

前記では、ユーザ（交通事業者）がイベントの開催を予め知っていた例を説明した。しかしながら、ユーザがイベントの開催を知ることなく何の対策も取れないまま混雑が発生してしまうこともあり得る。そこで、イベント参加者推定部２１は、移動パタン情報３６（図７（ａ））の各レコードの移動ルートの各区間に対応する、交通機関利用者情報３５（図６（ｂ））の当日分のレコードを監視しておく。そして、平常日に比して到着者数が所定の閾値以上増加した駅を検知すると、その到着駅及び到着時刻をキーとして、自動的にイベント情報３４を検索し、該当するイベントを抽出する。さらに、イベント参加者推定部２１は、“○○駅での◎◎イベントに留意してください”のような注意喚起メッセージを出力装置１３に表示したうえで、前記したステップＳ３０１以降の処理を開始することとしてもよい。
さらに、イベント参加者推定部２１は、乗客の増加からイベントの開催を検知した際に、時刻とエリア情報を用いて、ウエブサイトやＳＮＳ上の発言等からイベントの内容を特定し、特定した内容をイベント情報３４として登録してもよい。

（実施形態の効果）
（１）本実施形態の混雑予測装置は、イベント開始前の情報を使用してイベント開始後の交通機関の混雑を予測できる。よって、列車等の増便対策、安全対策等を早期に立てることができる。
（２）本実施形態の混雑予測装置は、当日増加した到着客のうち、定常的な乗者履歴を有さない者の数に占める、平常日からの増加分の比率を算出し、その比率に基づいてイベント参加候補者の数を算出する。よって、イベント参加候補者数の予測精度が向上する。
（３）本実施形態の混雑予測装置は、イベント参加候補者の属性を含む情報を入力とした予測モデルを使用する。よって、イベント参加候補者の乗車履歴からは予測できないイベント参加候補者の不規則な移動先を推定できる。よって、イベント参加候補者の属性の変化が発生しても、又は、イベントが新規のイベントであっても、高い精度で混雑を予測できる。

（４）本実施形態の混雑予測装置は、混雑の度合いを路線ごとに時系列で表示する。よって、混雑がイベント会場を中心に波及していく様子を容易に視認できる。
（５）本実施形態の混雑予測装置は、ダイヤ情報、任意の駅における乗車数及び待機乗客数を将来にわたって時系列で表示する。よって、列車の運行計画を変更する必要性を容易に視認できる。
（６）本実施形態の混雑予測装置は、ダイヤ情報に対する変更を反映した待機乗客数を将来にわたって時系列で表示する。よって、具体的な運行計画の変更の効果を容易に視認できる。

（７）本実施形態の混雑予測装置は、イベント開始時刻後に、前記比率を更新する。よって、イベント参加候補者数の予測精度がさらに向上する。
（８）本実施形態の混雑予測装置は、会場退出能力を算出する。よって、任意の駅における乗車数及び待機乗客数をより正確に時系列で表示できる。
（９）本実施形態の混雑予測装置は、乗客の増加を検知し、処理を自動的に開始する。よって、ユーザがイベントを予め知らない場合であっても処理を開始できる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１ 混雑予測装置
２ 携帯端末装置
３ 外部サーバ
４ ネットワーク
１１ 中央制御装置（制御部）
１２ 入力装置
１３ 出力装置
１４ 主記憶装置（記憶部）
１５ 補助記憶装置（記憶部）
１６ 通信装置
２１ イベント参加者推定部
２２ 混雑予測部
３１ 環境情報
３２ 個人情報
３３ エリア情報
３４ イベント情報
３５ 交通機関利用者情報
３６ 移動パタン情報
３７ 参加候補者情報
３８ 属性付参加候補者情報
６１ イベント表示画面
６２ イベント参加者移動予測画面
６３ イベント参加者属性表示画面
６４ 混雑予測詳細表示画面
６５ 非定時イベント表示画面
６６ 交通整備員配置画面
６７ 運行管理支援画面
６８ 運行計画変更画面
６９ 混雑回避ルート提案画面
７０ イベント登録画面

Claims (10)

1. 乗客による交通機関の利用履歴が記憶される交通機関利用者情報を格納する記憶部と、
   イベントが開催される会場の近辺に通じる前記交通機関の停車場を示す情報を受け付け、
   前記交通機関利用者情報を参照し、前記イベントの開催日のイベント開始時刻前において前記停車場で降車した乗客の数が、当該イベントが開催されない日に比して増加した増加分を算出し、
   前記算出した増加分に基づいて、イベント終了時刻後の前記交通機関の混雑を予測する制御部と、
   を備えることを特徴とする混雑予測装置。
2. 前記制御部は、
   前記交通機関利用者情報を参照し、前記開催日のイベント開始時刻前において前記停車場で降車した乗客のうち定常的な前記利用履歴を有さない乗客の数に占める、前記増加分の比率を算出し、
   前記開催日のイベント開始時刻前において前記停車場で降車した乗客の数と、前記算出した比率と、に基づき、前記イベントに参加した後、当該停車場で乗車する乗客の数を、前記交通機関の移動先ごとに予測すること、
   を特徴とする請求項１に記載の混雑予測装置。
3. 前記制御部は、
   前記乗客の属性を含む情報を入力とし前記乗客の移動先を出力とする予測モデルを使用して、前記当該停車場で乗車する乗客の移動先を予測すること、
   を特徴とする請求項２に記載の混雑予測装置。
4. 前記制御部は、
   前記予測した混雑の度合いを前記交通機関の路線ごとに将来にわたって時系列で表示すること、
   を特徴とする請求項３に記載の混雑予測装置。
5. 前記制御部は、
   前記路線のダイヤ情報を表示し、
   前記ダイヤ情報に含まれる任意の停車場で乗車する乗客の数と、当該停車場において待機する乗客の数と、を将来にわたって時系列で表示すること、
   を特徴とする請求項４に記載の混雑予測装置。
6. 前記制御部は、
   前記表示したダイヤ情報を変更する入力を受け付け、
   前記待機する乗客の数が前記受け付けた入力によって変化する様子を将来にわたって時系列で表示すること、
   を特徴とする請求項５に記載の混雑予測装置。
7. 前記制御部は、
   イベント開始時刻後かつイベント終了時刻前において前記乗客が、携帯端末装置を使用した履歴、又は、前記交通機関を利用した前記利用履歴に基づき、前記比率を更新すること、
   を特徴とする請求項２に記載の混雑予測装置。
8. 前記制御部は、
   前記会場の単位時間当たりの退出能力を算出し、
   前記算出した退出能力に基づいて、前記停車場で乗車する乗客の数を時系列で表示すること、
   を特徴とする請求項７に記載の混雑予測装置。
9. 前記制御部は、
   前記停車場を示す情報をユーザの入力によって受け付けない場合は、
   前記交通機関利用者情報を常時監視することにより前記増加分を検知し、
   前記検知した増加分に基づいて、イベント終了時刻後の前記交通機関の混雑を予想すること、
   を特徴とする請求項１に記載の混雑予測装置。
   
10. 混雑予測装置の記憶部は、
    乗客による交通機関の利用履歴が記憶される交通機関利用者情報を格納しており、
    前記混雑予測装置の制御部は、
    イベントが開催される会場の近辺に通じる前記交通機関の停車場を示す情報を受け付け、
    前記交通機関利用者情報を参照し、前記イベントの開催日のイベント開始時刻前において前記停車場で降車した乗客の数が、当該イベントが開催されない日に比して増加した増加分を算出し、
    前記算出した増加分に基づいて、イベント終了時刻後の前記交通機関の混雑を予測すること、
    を特徴とする前記混雑予測装置の混雑予測方法。