(57)【要約】【課題】ソーシャルメディア情報を用いて、駅の混雑を正確に予測する。【解決手段】  混雑予測サーバ１０８は、ソーシャルメディアデータ蓄積サーバ１０３から一定時間内に書き込まれたソーシャルメディアデータを取得し、入出場数集計サーバ１０７から一定時間ごとの駅構内の人数を取得する。混雑予測サーバは、取得した駅構内の人数とソーシャルメディアデータを用いて現在時刻以降の駅構内に存在する人数を予測する。【選択図】  図１
2014206829.tif 000002
【特許請求の範囲】
【請求項１】
サーバを用いて駅構内の人の混雑を予測する混雑予測システムであって、
駅の自動改札機から取得される該自動改札機を通過する利用者の人数のデータ、及び又は駅構内に設置された監視カメラによって撮影された映像から求められる列車の乗降者数のデータを用いて駅構内に居る人数を算出する駅構内人数算出部と、
ソーシャルメディア蓄積サーバからネットワークを介して該駅に関連するソーシャルメディアデータを取得し、該ソーシャルメディアデータを用いて該駅周辺にいる人数を予測する駅周辺人数算出部と、
該駅構内人数算出部によって算出された該駅構内に存在する人数と、該駅周辺人数算出部によって算出された該駅周辺にいる人数に基づいて、現在時刻移行の該駅構内に存在する人数を予測する駅構内人数予測部と、
を有する混雑予測システム。
【請求項２】
前記駅構内人数予測部が、該ソーシャルメディアデータ中に含まれるキーワードを用いて、該ソーシャルメディアの利用者が参加するイベントが終了したことを判定し、該駅への移動を予測する、請求項１記載の混雑予測システム。
【請求項３】
前記駅構内人数予測部が、該ソーシャルメディアデータの書き込み頻度を用いて、該ソーシャルメディアの利用者が参加するイベントが終了したことを判定し、該駅への移動を予測する、請求項１記載の混雑予測システム。
【請求項４】
前記駅構内人数予測部が、該ソーシャルメディアデータに関連付けられた写真または動画データを用いて、該ソーシャルメディアの利用者が参加するイベントの参加人数を算出する、請求項１記載の混雑予測システム。
【請求項５】
前記駅構内人数予測部が、該ソーシャルメディアデータ中の位置情報と、該駅の位置情報とを用いて、該ソーシャルメディアの利用者が参加するイベントが終了した後に、何時に該駅へ到着するかを予測する、請求項１記載の混雑予測システム。
【請求項６】
前記駅構内人数予測部が、該駅構内に存在する人数が該駅の許容人数よりも大きくなると予測した時に、利用者が該自動改札機を通過するときに使用する交通ＩＣカードの利用履歴データを用いて、該駅を利用しない移動経路を案内する対象者を抽出する誘導対象者抽出部を有する、請求項１記載の混雑予測システム。
【請求項７】
前記駅構内人数予測部が、該駅構内に存在する人数が該駅の許容人数よりも大きくなると予測した時に、ソーシャルメディア履歴データを用いて、該駅を利用しない移動経路を案内する対象者を抽出する誘導対象者抽出部を有する、請求項１記載の混雑予測システム。
【請求項８】
前記誘導対象者抽出部が、一定期間の履歴データを用いて該対象者ごとの自宅駅を推定し、該対象者が目的地から自宅への移動を行うと判定した場合に、該駅を利用しない移動経路を案内する対象者として抽出する、請求項６又は７記載の混雑予測システム。
【請求項９】
前記誘導対象者抽出部が、一定期間の履歴データを用いて該対象者の利用経路ごとの駅の入場時間または出場時間の標準偏差を算出し、該標準偏差が特定の閾値以上である利用経路の移動を行うと判定した場合に、該駅を利用しない移動経路を案内する対象者として抽出する、請求項６又は７記載の混雑予測システム。
【請求項１０】
前記誘導対象者抽出部が、該対象者の直前の駅利用時に同行者が存在したと判定した場合に、該駅を利用しない移動経路を案内する対象者として抽出する、請求項６又は７記載の混雑予測システム。
【請求項１１】
サーバを用いて駅構内の人の混雑を予測する混雑予測方法であって、
駅の自動改札機から取得される該自動改札機を通過する利用者の人数のデータ、及び又は駅構内に設置された監視カメラによって撮影された映像から求められる列車の乗降者数のデータを用いて駅構内に居る人数を算出する駅構内人数算出ステップと、
ソーシャルメディア蓄積サーバからネットワークを介して該駅に関連するソーシャルメディアデータを取得し、該ソーシャルメディアデータを用いて該駅周辺にいる人数を予測する駅周辺人数算出ステップと、
該駅構内人数算出ステップによって算出された該駅構内に存在する人数と、該駅周辺人数算出部によって算出された該駅周辺にいる人数に基づいて、現在時刻移行の該駅構内に存在する人数を予測する駅構内人数予測ステップと、
を有する混雑予測方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、混雑予測システムおよび方法に係り、特に、ソーシャルメディア情報を用いて駅構内の混雑予測及び案内を行う混雑予測システムおよび方法に関するものである。
【背景技術】
【０００２】
都市における公共交通機関の輸送障害時や災害時などの対策が重視されている。駅などの公共施設で大混雑が発生すると、ホームからの利用客の転落やエスカレータでの将棋倒しなどの事故が発生する可能性が高く、大変危険である。これらの事故を防ぐためには、今後発生する混雑を高精度に予測して、駅係員による利用客の誘導や利用客への情報の提供など適切な対策をとることが重要である。
【０００３】
駅における旅客の混雑を予測する技術の一つとして、過去の改札入出場データを用いて、ある１日の現在時点以降の旅客流動を予測する旅客流動予測装置が知られている（特許文献１、例えば１５頁、１９図参照）。この技術によれば、ある１日の現在時点までの時間帯についての改札入出場人数ベクトルと、過去日付の改札入出場人数ベクトルとの距離を算出し、最も近似した過去日付の改札入出場人数データを用いて、ある１日の残りの時間帯の駅待機人数を算出することができる。
【０００４】
ところで、人の行動を分析する技術の一つとして、ソーシャルメディア情報を用いて、「いつ」「どこで」起きた「どんな」出来事に関する書き込みかを解析し、地図上に表示する社会俯瞰マップがある（例えば非特許文献１）。この技術では、機械学習を用いた自然言語処理技術を用いて、個別の書き込みから必要な情報を抽出することによって、地図上に表示することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−１９６９８７号公報
【非特許文献】
【０００６】
【非特許文献１】湯上伸弘、井形伸之、穴井宏和、稲越宏弥、インテリジェントソサエティを支える分析技術、雑誌ＦＵＪＩＴＳＵ、２０１１年９月号（ＶＯＬ．６２，ＮＯ．５）ｐ．４７５−４８１（第４７７頁、第２図）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
然るに、特許文献１に記載の技術は、通常と大きくパターンが異なる日（例えばイベント開催時や震災時など）の場合、駅構内の人数を正確に予測することが出来ないという課題がある。また、特許文献１にはソーシャルメディアデータを用いて旅客の流動予測を行う旨の示唆は記載されていない。
【０００８】
非特許文献１に記載の技術は、その時・その場所で発生した出来事については可視化して人数を算出することができるが、その時より後の出来事については予測できないという課題がある。さらにソーシャルメディアに書きこんでいる人以外の出来事については、人数を算出できないという課題がある。
【０００９】
本発明の目的は、ソーシャルメディア情報を用いて、駅の混雑を正確に予測することが可能な、混雑予測装置および方法を提供することである。
【課題を解決するための手段】
【００１０】
本発明に係る混雑予測システムは、好ましくは、サーバを用いて駅構内の人の混雑を予測する混雑予測システムであって、駅の自動改札機から取得される該自動改札機を通過する利用者の人数のデータ、及び又は駅構内に設置された監視カメラによって撮影された映像から求められる列車の乗降者数のデータを用いて駅構内に居る人数を算出する駅構内人数算出部と、
ソーシャルメディア蓄積サーバからネットワークを介して該駅に関連するソーシャルメディアデータを取得し、該ソーシャルメディアデータを用いて該駅周辺にいる人数を予測する駅周辺人数算出部と、
該駅構内人数算出部によって算出された該駅構内に存在する人数と、該駅周辺人数算出部によって算出された該駅周辺にいる人数に基づいて、現在時刻移行の該駅構内に存在する人数を予測する駅構内人数予測部と、を有する混雑予測システムとして構成される。
【００１１】
また、本発明に係る混雑予測方法は、上記システムにおいて実行される混雑予測方法として把握される。
【発明の効果】
【００１２】
本発明によれば、ソーシャルメディア情報を用いて駅の混雑を正確に予測することができる。
【図面の簡単な説明】
【００１３】
【図１】一実施例による駅の混雑予測システムの構成例を示す図である。
【図２】一実施例における混雑予測システムの機能構成を示すブロック図である。
【図３】一実施例における混雑予測サーバのハードウェア構成例を示す図である。
【図４】一実施例における案内サーバのハードウェア構成例を示す図である。
【図５】一実施例における駅構内人数算出部２０１、駅周辺人数算出部２０２、駅構内人数予測部２０３による処理動作を示すフローチャートである。
【図６】一実施例における駅構内人数テーブルの構成例を示す図である。
【図７】一実施例におけるソーシャルメディアデータの構成例を示す図である。
【図８】一実施例における行動予測判定条件テーブルの構成例を示す図である。
【図９】一実施例におけるイベント・団体情報テーブルの構成例を示す図である。
【図１０】一実施例における駅座標テーブルの構成例を示す図である。
【図１１】一実施例における誘導対象者抽出部２０４及び誘導案内部２０５０による処理動作を示すフローチャートである。
【図１２】一実施例における許容人数テーブルの構成例を示す図である。
【図１３】一実施例における移動履歴データの構成例を示す図である。
【図１４】一実施例における履歴分析結果テーブルの構成例を示す図である。
【図１５】一実施例における誘導対象者抽出テーブルの構成例を示す図である。
【図１６】一実施例におけるアクセス先アドレステーブルの構成例を示す図である。
【図１７】一実施例におけるメール受信画面の表示例を示す図である。
【図１８】一実施例における表示器１０４１の画面の表示例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明における実施例について、図面を参照しながら詳細に説明する。
図１は、駅の混雑予測システムの構成例を示す。
駅の混雑予測システムは主に、ソーシャルメディアデータ蓄積サーバ１０３、表示サーバ１０４、入出場者数集計サーバ１０７、混雑予測サーバ１０８、案内サーバ１０９、入出場履歴蓄積サーバ１１０がネットワーク１０２を介して接続して構成される。通常は、表示サーバ１０４、入出場者数集計サーバ１０７、混雑予測サーバ１０８、案内サーバ１０９及び入出場履歴蓄積サーバ１１０は鉄道会社によって所有又は管理され、ソーシャルメディアデータ蓄積サーバ１０３は外部の業者が運営するサーバである。
【００１５】
ソーシャルメディアデータ蓄積サーバ１０３は、携帯電話機や携帯端末のような複数の情報端末１０１からネットワーク１０２を経由して、書き込み内容（テキストデータ）、書き込み時刻、現在位置座標、写真、動画などのデータを蓄積する。また、蓄積したそれらのデータをネットワーク１０２を介して情報端末１０１へ提供して、情報端末で閲覧することができる。
【００１６】
自動改札機１０５はＩＣカードリーダ付きの改札ゲートを備え、利用者が所持する乗車用のＩＣカード（以下、交通ＩＣカードという）に記録されたデータ（利用者固有のカードＩＤ，入出場駅名、ゲート通過日時、入出場の区別、利用料金等のデータ）を読取り又は記録する。入出場者数集計サーバ１０７は、複数の自動改札機１０５で取得された改札通過データを、ネットワーク１０２を経由して受信して管理する。
【００１７】
駅のプラットホームには複数の監視カメラ１０６が設置されており、到着列車及び出発列車のドア付近の映像を撮影する。監視カメラによる撮影映像データは、ネットワーク１０２を経由して入出場者数集計サーバ１０７へ送信され、そこで管理される。入出場者数集計サーバ１０７は、利用者の改札通過データと撮影映像データを基に駅ごとの構内人数を一定時間ごとに集計する。即ち、自動改札機１０５が取得した改札通過データから各利用者の固有情報（利用者ＩＤ）を計数することで人数を算出でき、また監視カメラ１０６の撮影映像データから乗降者の画像を切り出し処理して、乗車人数、降車人数を算出する。
【００１８】
入出場履歴蓄積サーバ１１０は、利用者の交通ＩＣカードから取得（又は交通ＩＣカードに記録）したデータを移動履歴データとして記録する（詳細は図１３参照）。混雑予測サーバ１０８は、ネットワーク１０２を経由して、ソーシャルメディアデータ蓄積サーバ１０３からソーシャルメディアデータを取得し、入出場者数集計サーバ１０７から入出場者数を取得して、現在時点以降の駅構内人数を予測する。案内サーバ１０９は、ネットワーク１０２を経由して、混雑予測サーバから現在時点以降の駅構内人数を、入出場履歴蓄積サーバから複数の交通ＩＣカード利用者の移動履歴データをそれぞれ取得して、対象者を抽出して誘導案内を行う。表示サーバ１０４は駅構内に設置された複数の表示器１０４１のサイネージ画面に誘導案内の表示を行う。
【００１９】
このシステムの実現する構成例に関して、ソーシャルメディアデータ蓄積サーバ１０３、表示サーバ１０４、入出場者数集計サーバ１０７、混雑予測サーバ１０８、案内サーバ１０９、及び入出場履歴蓄積サーバ１１０は、パーソナルコンピュータやワークステーション等の計算機で構成され、ネットワーク１０２はＥｔｈｅｒｎｅｔ（登録商標）（Ｘｅｒｏｘ社とＤＥＣ社(現在Hewlett-Packard社の一部門)が考案したＬＡＮ規格。802.3, IＥＥＥ 802.3）で構成される。
なお、上記の混雑予測サーバ１０８と案内サーバ１０９は１台のサーバで構成してもよい。また自動改札機や監視カメラのデータを駅や路線毎に集計する中間サーバを用意してもよい。
【００２０】
図２は、駅構内の混雑予測システムの機能構成を示すブロック図である。
混雑予測システムは主に、駅構内人数算出部２０１、駅周辺人数算出部２０２、駅構内人数予測部２０３、誘導対象者抽出部２０４、誘導案内部２０５により構成される。これらの機能は、入出場者数集計サーバ１０７、混雑予測サーバ１０８及び案内サーバ１０９で、混雑予測プログラム３０７や案内プログラム４０７を実行することで実現される。
【００２１】
駅構内人数算出部２０１は、入場者数集計サーバ１０７が利用者の改札通過データと撮影映像データを用いて駅ごとの構内人数を一定時間ごとに算出する。駅周辺人数算出部２０２は、混雑予測サーバ１０８がソーシャルメディアデータを用いて駅の周辺に存在する人数を算出する。駅構内人数予測部２０３は、混雑予測サーバ１０８が、駅構内人数算出部２０１によって算出した一定時間ごとの駅構内人数と、駅周辺人数算出部２０２によって算出した駅の周辺に存在する人数と、ソーシャルメディアデータから推定した現在時刻以降に駅へ移動する人数を基に、現在時点以降の駅構内人数を予測する。誘導対象者抽出部２０４は、案内サーバ１０９が現在時点以降の駅構内人数が一定の閾値を超えた場合に、利用者が所持する交通ＩＣカードの移動履歴データから、前記駅以外を利用するように誘導する対象者を抽出する。誘導案内部２０５は、案内サーバ１０９が、抽出された誘導対象者に対して電子メール等の通信手段を用いて誘導案内を行う。
【００２２】
図３は、混雑予測サーバ１０８のハードウェア構成例を示す図である。
主制御部３０１は、ハードウェアの制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ）である。入力部３０２は、システム管理者がプログラム実行開始指示や中止指示等の入力を行うキーボードやマウスのような入力器である。出力部３０３は、プログラムの実行状態等の出力を行う液晶ディスプレイのような表示器である。通信処理部３０４は、他の計算機とのデータ交換を行うＥｔｈｅｒｎｅｔや無線通信部である。記憶管理部３０５は、プログラムやデータの読み出し、記録を行うハードディスクやフラッシュメモリのような記憶ユニットである。通信部３０６は上記各部間のデータ通信を行うバスである。記憶管理部３０５は、混雑予測プログラム３０７、駅構内人数テーブル３０８、行動予測判定条件テーブル３０９、イベント・団体情報テーブル３１０、駅座標テーブル３１１を格納する。なお、これらの各テーブル構成、及びプログラムによる処理動作については後述する。
【００２３】
図４は、案内サーバ１０９のハードウェア構成例を示す図である。
主制御部４０１は、ハードウェアの制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ）である。入力部４０２は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行うキーボードやマウスのような入力器である。出力部４０３は、プログラムの実行状態等の出力を行う液晶ディスプレイのような表示器である。通信処理部４０４は、他の計算機とのデータ交換を行うＥｔｈｅｒｎｅｔや無線通信部である。記憶管理部４０５は、プログラムやデータの読み出し、記録を行うハードディスクやフラッシュメモリのような記憶ユニットである。通信部４０６は上記各部間のデータ通信を行うバスである。記憶管理部４０５は、案内プログラム４０７、許容人数テーブル４０８、履歴分析結果テーブル４０９、誘導対象者抽出テーブル４１０、アクセス先アドレステーブル４１１を格納する。なお、これらの各テーブル構成、及びプログラムによる処理動作については後述する。なお、上記入力部や出力部はタッチパネルを備えて構成してもよい。
【００２４】
次に、図５を参照して、駅構内人数算出部２０１、駅周辺人数算出部２０２、駅構内人数予測部２０３による処理動作について説明する。このフローチャートによる動作は、例えば一定時間ごとに実行するものとする。
【００２５】
最初に、駅構内人数算出部２０１が、駅構内の人数を算出し、駅構内人数テーブル３０８に格納する（Ｓ５０１）。駅構内人数テーブル３０８は、図６に示すように、駅名６０１、日時６０２、構内人数６０３から構成される。駅構内の人数の算出方法について、例えば２０１２年４月１日１０：０５から１０：１０までのＡ駅の構内人数を求める場合には、２０１２年４月１日１０：００から１０：０５までのＡ駅の構内人数から、改札通過データにおける時間内の出場者数と、列車乗降車映像データから人の映像を認識することによって算出される時間内の列車乗車人数を減算し、さらに改札通過データにおける時間内の入場者数と、列車乗降車映像データから人の映像を認識することによって算出される当該時間内の列車降車人数を加算することで求める。
【００２６】
次に、駅周辺人数算出部２０２がソーシャルメディアデータ蓄積サーバ１０３から、現在時点より前の一定時間（例えば１時間）内に書き込まれたソーシャルメディアデータを取得する（Ｓ５０２）。ソーシャルメディアデータは、図７に示すように、ソーシャルメディアのユーザＩＤ７０１、書き込み日時７０２、書き込み時の位置座標７０３、書き込み内容を分類するタグ名７０４、書き込み内容テキスト７０５、書き込みに添付する写真や動画データへのリンク情報７０６から構成される。
【００２７】
次に、駅周辺人数算出部２０２が、取得したソーシャルメディアデータをエリア毎に配分して、エリア毎に存在する人数を算出する（Ｓ５０３）。ここで、エリアとは駅及びその周辺を指すものとする。また、ソーシャルメディアデータをエリア毎に配分する方法としては、ソーシャルメディアデータ中に含まれる位置座標７０３を用いて分類することができる。例えば、駅座標テーブル３１１を読み込み、ある駅の位置座標とソーシャルメディアデータ中に含まれる位置座標から、一定の距離以下であればその駅エリアに配分する。
【００２８】
駅座標テーブル３１１は、図１０に示すように、駅名１００１、駅が存在する位置座標・エリア１００２から構成されるリストである。駅が存在する位置座標・エリア１００２がある範囲を表す場合は、例えば当該範囲の矩形の頂点を表す複数の位置座標を格納する。矩形の場合は、矩形の重心座標とソーシャルメディアデータ中に含まれる位置座標から、一定の距離以下であればその駅エリアに配分してもよい。またはソーシャルメディアデータ中に含まれる位置座標が、矩形内に位置すればその駅エリアに配分してもよい。あるいは、ソーシャルメディアデータ中に含まれる分類７０４やテキストデータ７０５中に、その駅名がキーワードとして含まれていればその駅エリアに配分してもよい。
【００２９】
次に、駅構内人数予測部２０３が、取得したソーシャルメディアデータ中に、行動予測判定条件テーブル３０９に登録された判定条件に該当する書き込みが存在するか否かを調べる（Ｓ５０４）。行動予測判定条件テーブル３０９は、図８に示すように、イベント・団体情報名８０１、判定条件８０２から構成される。判定条件には、例えばイベントの場合は、イベントが終了して、イベント参加者がイベント会場から駅に向かっていると予測する判断条件を格納する。例えば、ソーシャルメディアの書き込みに、「終了」や「最高」と言ったキーワードが含まれている場合、イベントが終了して、イベント参加者がそのイベントの感想を書き込んでいると推測する。また、書き込み頻度から、それまで一定時間以上書き込みが無かった人が、その時点から複数の書き込みを行うようになったら、その頻度の変化を基に、イベント参加者がそのイベントが終了して書き込みできる状態になったと推測する。また、会社や学校などの団体の場合は、団体の所属者が退社或いは下校して駅に向かっていると予測する判断条件を格納する。例えば、ソーシャルメディアの書き込みに、「帰宅指示」と言ったキーワードが含まれている場合、地震などによって団体で帰宅指示が出され、その周辺の駅が混雑する可能性が高い。
【００３０】
Ｓ５０４の判定において該当するイベントまたは団体が存在する場合、駅構内人数予測部２０３が、イベント・団体情報テーブル３１０と、駅座標テーブル３１１０をそれぞれ読み込み、各駅に移動する人数の配分を決定する（Ｓ５０５）。イベント・団体情報テーブル３１０は、図９に示すように、イベント・団体名９０１、イベント会場または団体建物が存在する位置座標・エリア９０２、イベントの参加者人数または団体の所属者数を表す人数規模９０３から構成されるリストである。イベント会場または団体建物が存在する位置座標・エリア９０２がある範囲を表す場合は、例えばその範囲の矩形の頂点を表す複数の位置座標を格納する。
【００３１】
ここで、人数を決定する方法としては、Ｓ５０４のイベントまたは団体名に該当するレコードをイベント・団体情報テーブル３１０から検索し、人数規模９０３をその人数とする。または、該当するイベントまたは団体名がイベント・団体情報テーブル３１０になければ、書き込み件数や書き込み人数に係数を掛けて全体の人数を推定しても良い。あるいは、ソーシャルメディアデータ中に含まれる写真や動画データへのリンク情報７０６から、写真や動画がイベント会場風景を撮影したものであれば、写真や動画データを解析してイベント参加者の人数を推定しても良い。配分を決定する方法としては、例えばイベント会場の位置座標から半径５ｋｍ以内に位置する駅を抽出して配分する。該当する駅が複数存在する場合には、各駅の位置座標からイベント会場から各駅までの距離を求めて、距離が近い駅ほど多くの人が移動するように計算しても良い。または、駅の規模や利用可能路線数などの指標から、人を配分するように計算しても良い。
【００３２】
次に、駅構内人数予測部２０３が、各駅への到着予想時刻を算出する（Ｓ５０６）。例えばイベント会場と駅の位置座標から距離を算出し、距離に応じて到着予想時刻を算出する。また、イベント種類に応じて、移動速度に係数を掛けるようにしても良い。例えばイベントが家族向けの場合や団体が小学校の場合は、子供の歩行速度が遅いことを考慮するようにしても良い。
【００３３】
Ｓ５０６が終了するか、Ｓ５０４で行動予測判定条件テーブル３０９に登録された判定条件に該当する書き込みが存在しない場合は、駅毎の混雑率予測を算出する（Ｓ５０７）。例えば、駅ｐ１の時刻ｔ１における構内人数の予測人数Ａ（ｐ１，ｔ１）を式１により算出する。
【００３４】
Ａ（ｐ１，ｔ１)＝Ｂ(ｐ１，ｔ１)＋α×Ｃ(ｐ１)＋β×Ｄ(ｐ１，ｔ１)    （式１）
ここでＢ（ｐ１，ｔ１）は改札通過データや監視カメラの撮影映像データから算出した駅ｐ１の時刻ｔ１における予測人数である。例えば、特許文献１に記載されるように、ある１日の現在時点までの時間帯についての駅構内人数ベクトルと、過去日付の駅構内人数ベクトルとの距離を算出し、最も近似した過去日付の駅構内人数データを用いて、ある１日の残りの任意の時間帯の駅構内人数を算出することができる。
【００３５】
Ｃ（ｐ１）はＳ５０３で算出した駅ｐ１の周辺人数である。Ｄ（ｐ１，ｔ１）はＳ５０５、５０６で算出した駅ｐ１の時刻ｔ１における来訪予測人数である。例えば、Ｓ５０５で駅ｐ１に１００人移動すると配分し、Ｓ５０６で駅ｐ１への到着予測時刻が１２：００であれば、その前後の時間ごとの一定の配分係数に従って、１１：５５は１０人、１２：００は６０人、１２：０５は２５人、１２：１０は５人といったように算出する。α、βは係数であり、例えばソーシャルメディアを利用している人は全体の一部なので、人数を割増しするような係数としても良い。また、αは現在時刻と予測時刻との差に反比例する係数としても良い（即ち、遠い将来に対する予測であるほど、過去に駅周辺にいたという情報は有効性が低いため、係数を低くする）。さらに、この処理ステップで各駅の混雑率を算出しても良い。ここで、混雑率は、例えば駅構内人数における駅の許容人数に対する割合として算出する。即ち、例えば駅構内人数が１００人、その駅の許容人数が２００人であれば、混雑率は５０％とする。
【００３６】
最後に、駅構内人数予測部２０３が、算出した駅構内人数予測や駅混雑率予測の数値を用いて、表示サーバ１０４に対して駅サイネージなどの表示画面の更新を指示して処理を終了する（Ｓ５０８）。図１８に、駅の混雑率予測に関する情報を表示する、表示器１０４１の駅サイネージの表示画面例を示す。現在時点から一定時間後の駅や路線毎の混雑率を、例えば路線図上にアイコン表示やグラフ表示することによって、利用者はいつ頃にどの駅や路線がどの程度混雑する見込みかを容易に把握できる。
【００３７】
次に、図１１を参照して、誘導対象者抽出部２０４、誘導案内部２０５の処理動作について説明する。この処理は、例えば図５に示す処理動作が終了するごと（即ち一定時間ごと）に実行されるものとする。
【００３８】
まず、誘導対象者抽出部２０４が、許容人数テーブル４０８を読み込み、図５の処理によって算出した駅毎の駅構内人数が、駅の許容人数を超えた駅が存在するか否かを調べる（Ｓ１１０１）。その結果、人数超過の駅が存在しなければ処理を終了する。許容人数テーブル４０８は、図１２に示すように、駅名１２０１、収容人数１２０２から構成される。
【００３９】
Ｓ１１０１による判断の結果、該当駅が存在する場合は、次に前回の迂回依頼から一定時間以上経過しているか否かを調べる（Ｓ１１０２）。その結果一定時間以上経過していなければ、処理を終了する。このステップの処理を実行することにより、利用者に対して短時間内に何度も迂回依頼が送信されることを防ぐことができる。
【００４０】
一方、Ｓ１１０２の処理で一定時間以上経過している駅があれば、誘導対象者抽出部２０４は、駅や路線毎に何人が迂回をすれば、混雑を避ける適正人数になるかを算出する（Ｓ１１０３）。例えば上記許容人数を適正人数としても良いし、例えば許容人数の８０％を適正人数としても良い。駅構内人数から適正人数を減算した人数を、誘導対象者の人数とする。
【００４１】
次に、誘導対象者抽出部２０４が、入出場履歴蓄積サーバ１１０から一定期間の移動履歴データを取得する（Ｓ１１０４）。移動履歴データは、図１３に示すように、利用者が自動改札機を通過するときに使用する交通ＩＣカードのカードＩＤ１３０１、利用日時１３０２、処理名１３０３、端末名１３０４、利用金額１３０５から構成される。
【００４２】
次に、誘導対象者抽出部２０４が、カードＩＤ毎に行動パターンを集計し、履歴分析結果テーブル４０９に格納する（Ｓ１１０５）。履歴分析結果テーブル４０９は、図１４に示すように、カードＩＤ１４０１０、自宅駅１４０２、通勤・通学駅１４０３、最終利用駅１４０４、最終利用時の同行者有無１４０５、利用日・時間帯１４０６、利用経路１４０７、頻度１４０８、入出場時間の標準偏差１４０９から構成される。ここで、自宅駅は、例えば一日の最初の入場駅や一日の最後の出場駅として出現頻度の高い駅を移動履歴データから抽出して格納する。通勤・通学駅は、例えば平日朝の目的駅や平日夜の出発駅として出現頻度の高い駅を移動履歴データから抽出して格納する。最終利用駅は、移動履歴データ中で最も新しい日時のレコードを抽出し、そのレコードの駅を格納する。同行者有無は、移動履歴データ中で最も新しい日時のレコードを抽出し、レコードの移動時に同行者が存在した場合には同行者のカードＩＤを格納する。
【００４３】
ここで、交通ＩＣカード利用履歴データから同行者が存在したか否かを判定する方法については、同一駅の同一または近接（例えば、両隣１台まで）の改札機の端末名１３０４で、日時１３０２が同一時間帯（例えば、日時の差が３秒以内）で、かつ処理名１３０３が同一（入場または出場）である行データの組合せを抽出し、その行データのカードＩＤ１３０１を取得し、行データのカードＩＤの組が、一定以上の移動（例えば入場から乗り換えを除く出場まで）において出現するならば同行者が存在したと判定する。利用日・時間帯および利用経路は、平日・休日や何時台などの分類毎の利用経路を格納する。頻度は、例えば利用日・時間帯および利用経路毎に一週間の期間中の移動頻度をカウントして格納する。入出場時間の標準偏差は、例えば利用日・時間帯および利用経路毎に一週間の期間中の入出場時間の標準偏差を算出して格納する。即ち、いつも決まった利用日・時間帯に利用する経路であるほど、標準偏差は小さくなる。
【００４４】
次に、誘導対象者抽出部２０４が、駅や路線毎に迂回を依頼する人を選別し、誘導対象者抽出テーブル４１０に格納する（Ｓ１１０６）。誘導対象者抽出テーブルは、図１５に示すように、カードＩＤ１５０１、案内内容１５０２から構成される。迂回対象となる誘導対象者の選別方法としては、混雑が予測される時間帯にその駅を利用する移動を行う（例えばその駅を出発・到着・乗り換え・乗り継ぎ駅として利用する移動を行う）可能性が高く、かつ迂回をしてくれる可能性が高い人を選別する。例えば平日１９時にＢ駅が混雑すると予測される場合に、ある利用者の移動履歴データの分析結果から、最終利用駅がＢ駅、自宅駅がＡ駅であり、平日１９時台のＢ駅⇒Ａ駅への移動頻度が高ければ、Ｂ駅の混雑に巻き込まれる可能性が高い。一般に学校や会社への登校・出勤時は始業時間に間に合う必要があるので迂回してくれる可能性が低いが、帰宅時であれば多少時間がかかっても迂回してくれる可能性が高いため、誘導対象者として抽出し、案内内容として混雑の少ない駅への迂回経路を提案するように設定する。または、例えばカードＩＤの利用者が、頻度の低い移動を行っている場合や、標準偏差が大きい経路を利用している場合は（通勤や通学ではなくレジャー目的で移動している可能性が高いため）、誘導対象者として抽出し、案内内容として目的駅の変更を提案するように設定する。あるいは、例えばカードＩＤの利用者が、同行者を伴って移動していると判断され、同行者が子供や女性である場合には、誘導対象者として抽出し、案内内容として混雑の少ない駅への迂回経路を提案するように設定する。
【００４５】
次に、誘導案内部２０５が、誘導対象者抽出テーブルのレコードを順番に参照し（Ｓ１１０７）、次レコードがあれば迂回依頼メッセージを作成し、アクセス先アドレステーブル１６のアクセス方法およびアクセス先アドレスに従ってメッセージを送信する（Ｓ１１０８）。アクセス先アドレステーブルは、図１６に示すように、カードＩＤ１６０１、アクセス方法１６０２、アクセス先アドレス１６０３から構成される。アクセス方法１６０２、アクセス先アドレス１６０３などのデータは、利用者が交通ＩＣカードを購入するときに登録された情報である。案内メールの受信画面例を図１７に示す。
その後、Ｓ１１０７で誘導対象者抽出テーブルに次レコードがなくなれば、処理を終了する。
【００４６】
以上、交通ＩＣカード利用履歴データを用いて誘導対象者を抽出する例について説明した。なお、本発明は上記実施例に限定されるものではなく、種々変形して実施し得る。
【００４７】
例えば、ソーシャルメディア履歴データを用いて誘導対象者を抽出するようにしても良い。あるいは、交通ＩＣカード利用履歴データとソーシャルメディア履歴データをＩＤで紐付けして、その両方の履歴データを組み合わせた分析結果から誘導対象者を抽出するようにしても良い。ソーシャルメディア履歴データを用いる場合は、例えば最終利用駅の代わりに最新の書き込み時の位置情報を用いることができる。また交通ＩＣカード利用履歴データとソーシャルメディア履歴データを組み合わせる場合は、例えば交通ＩＣカード利用履歴から自宅駅・最終利用駅を抽出し、ソーシャルメディア履歴データから何時頃に駅に到着予定かを抽出できるため、該利用者が駅の混雑に巻き込まれる可能性があるか否かを、より正確に判定し、適切な誘導案内を行うことができる。
【００４８】
また他の例によれば、上述の表示サーバ１０４、入出場者数集計サーバ１０７、混雑予測サーバ１０８、案内サーバ１０９及び入出場履歴蓄積サーバ１１０等は個別のサーバで構成せず、１またはより少ない複数のサーバで構成するこが可能である。１台のサーバで構成する場合には、上記各サーバが有する機能を実現するアプリケーションプログラムを１台のサーバに有することで実現できる。
【００４９】
さらに上記実施例では、図２に示す駅構内人数算出部２０１は、入場者数集計サーバ１０７が、自動改札機１０５が取得した利用者の改札通過データと、監視カメラ１０６から取得した撮影映像データの両方を用いて駅の構内人数を算出するとした。しかし他の例によれば、駅構内人数算出部２０１は改札通過データ又は撮影映像データのいずれか一方を使用して、構内人数を算出することが可能である。改札通過データのみを使用する場合には利用者が駅のホームに居ることは不確実であるが、少なくても駅構内に居る人数は把握でき、これによって構内人数の予測が可能である。また、ホームだけではなく駅構内の随所に監視カメラを設置しておき、これらの撮影映像データを用いて構内人数を算出することは可能である。
【００５０】
本実施例によれば、従来技術による駅の混雑予測に比べて精度の高い混雑予測を実現することが可能となり、旅客の安全確保のために、鉄道会社が駅係員の配置を最適化したり、旅客案内を改善することが可能となる。また、従来の誘導案内（駅の案内板やサイネージ、遅延情報の一斉メール配信などを用いた画一的な呼びかけ）に比べて効果的な迂回誘導を実現することが可能となり、混雑の平準化、改善を図ることができる。
【符号の説明】
【００５１】
１０１：情報端末  １０２：ネットワーク  １０３：ソーシャルメディアデータ蓄積サーバ  １０４：表示サーバ  １０４１：表示器  １０５：自動改札機  １０６：監視カメラ  １０７：入出場者数集計サーバ  １０８：混雑予測サーバ  １０９：案内サーバ  １１０：入出場履歴蓄積サーバ  
２０１：駅構内人数算出部  ２０２：駅周辺人数算出部  ２０３：駅構内人数予測部  ２０４：誘導対象者抽出部  ２０５：誘導案内部  
３０１、４０１：主制御部  ３０２、４０２：入力部  ３０３、４０３：出力部  ３０４、４０４：通信処理部  ３０５、４０５：記憶管理部  ３０６、４０６：通信部  ３０７：混雑予測プログラム  ３０８：駅構内人数テーブル  ３０９：行動予測判定条件テーブル  ３１０：イベント・団体情報テーブル  ３１１：駅座標テーブル  ４０７：案内プログラム  ４０８：許容人数テーブル  ４０９：履歴分析結果テーブル  ４１０：誘導対象者抽出テーブル  ４１１：アクセス先アドレステーブル  １７０１：メール受信画面  １８０１：駅サイネージ画面
【図１】
2014206829.tif 000003
【図２】
2014206829.tif 000004
【図３】
2014206829.tif 000005
【図４】
2014206829.tif 000006
【図５】
2014206829.tif 000007
【図６】
2014206829.tif 000008
【図７】
2014206829.tif 000009
【図８】
2014206829.tif 000010
【図９】
2014206829.tif 000011
【図１０】
2014206829.tif 000012
【図１１】
2014206829.tif 000013
【図１２】
2014206829.tif 000014
【図１３】
2014206829.tif 000015
【図１４】
2014206829.tif 000016
【図１５】
2014206829.tif 000017
【図１６】
2014206829.tif 000018
【図１７】
2014206829.tif 000019
【図１８】
2014206829.tif 000020