JP7406463B2 - 交通運行計画システム及び交通運行計画方法 - Google Patents

Description

本発明は、交通の運行を調停する計画技術に関する。

公共交通の運行計画を立案する技術として、例えば特開２０１９－０８２７６６号公報（特許文献１）に記載の技術がある。特許文献１には、「公共交通機関に係る運用計画を行うための公共交通運用計画装置であって、公共交通機関の走行方式、公共交通機関の便数、および道路の車線の情報を含んで構成される運用計画パターンを作成する作成部と、構成要素を切替可能な道路インフラの利用形態に係る情報を含む道路利用形態情報と、公共交通機関の運行に係る公共交通運行情報とに基づいて、道路の渋滞度、利便性、および収益性を評価指標として作成部が作成した運用計画パターンを評価する評価部と、を設ける」と記載されている。

また、目的地までの交通手段を利用した経路を探索する技術として、例えば国際公開第０６／０６１８８５号（特許文献２）に記載の技術がある。特許文献２には、「空席経路探索システムは、各交通手段の運行データを記憶した運行データＤＢと、探索用の運行データを記憶する探索用運行データＤＢと、各交通手段の予約情報を収集する予約情報収集手段と、座席条件を含む経路探索条件を入力する条件入力手段と、予約情報収集手段で収集した予約情報と経路探索条件に基づいて前記探索用運行データＤＢを参照して経路となる交通手段を探索する経路探索手段と、経路探索の結果を出力する出力手段と、を備え、経路探索手段は、経路探索に先立ち、運行データＤＢから経路探索条件に合致する予約情報を持つ交通手段を抽出して探索用運行データＤＢを形成して経路探索を行う」と記載されている。

特開２０１９－０８２７６６号公報 国際公開第０６／０６１８８５号

上記の特許文献１では、複数交通モードに対して、渋滞度、利便性、および収益性などの同一ＫＰＩを評価して運行計画を立案する方法及び装置が提案されている。しかし、ＫＰＩは各交通モードによって異なるため、特許文献１の方法を採用しても交通モードや事象者にとって必ずしも好ましい運行にならない。

特許文献２では、交通利用者の嗜好に合ったルート及び座れるルートなどをレコメンドする方法及び装置が提案されている。しかし、特許文献２の方法ではそもそも目的地及び立寄地を見つけ出すことができないため移動需要そのものは増加しない。また、ユーザの状況や要求レベル（座っていきたいのか、早くいきたいのか）はユーザによって異なるため、これらを考慮する必要がある。

さらに、レコメンドした結果及び運行調停した結果を相互に反映する発明はなされていないが、これらは相互に影響するため、互いに結果を反映して結果を導出しなければ、高精度な結果が得られない。

上記課題の少なくとも一つを解決するために、本願において開示される発明の代表的な一例は、演算部と、記憶部と、を有する交通運行計画システムであって、前記記憶部は、複数の交通機関の各々について指定された評価指標と、前記複数の交通機関の運行計画の作成条件と、前記複数の交通機関の運行のシミュレーション条件と、を保持し、前記演算部は、前記運行計画の作成条件に基づいて、前記複数の交通機関の運行計画を作成し、前記運行計画及び前記シミュレーション条件に基づいて、前記複数の交通機関の運行のシミュレーションを実行し、前記シミュレーションの結果に基づいて、前記複数の交通機関について指定された前記評価指標を計算し、すべての前記評価指標が所定の基準を充足した場合、前記運行計画を出力し、少なくともいずれかの前記評価指標が前記基準を充足しない場合、前記運行計画を変更することを特徴とする。

本発明の一態様によれば、例えば既存の複数の交通モードに関しても、あるいはそこに新規交通モードが加わる場合であっても、全交通モードのＫＰＩが低下しない運行を実現できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

本発明のコンセプトを示す説明図である。 本発明の実施例のシステム構成の一例を示すブロック図である。 本発明の実施例の移動レコメンドシステムの構成例を示すブロック図である。 本発明の実施例の運行調停システムの構成例を示すブロック図である。 本発明の実施例のシミュレーションシステムの構成例を示すブロック図である。 本発明の実施例のシステム間の連係動作例を示すシーケンス図である。 本発明の実施例の移動レコメンドシステムのレコメンド計画プログラムによる処理の一例を示すフローチャートである。 本発明の実施例の運行調停システムの運行計画立案プログラムによる処理の一例を示すフローチャートである。 本発明の実施例の運行調停システムが保持する交通データのデータ構造の一例を示す説明図である。 本発明の実施例の移動レコメンドシステムが生成するレコメンド計画のデータ構造の一例を示す説明図である。 本発明の実施例の交通利用者端末の表示画面の一例を示す説明図である。 本発明の実施例におけるある交通事業者の交通事業者運行計画システムの表示画面の一例を示す説明図である。 本発明の実施例における別の交通事業者の交通事業者運行計画システムの表示画面の一例を示す説明図である。 本発明の実施例の合意形成システムの表示画面の一例を示す説明図である。

以下、本発明の実施例を図面に基づいて説明する。

＜コンセプト＞
図１は、本発明のコンセプトを示す説明図である。

本発明の一実施例のシステムは、移動レコメンドシステム１０１、運行調停システム１０２及びシミュレーションシステム１０３を含む。運行計画に基づいて移動レコメンドシステム１０１は、利用者の移動需要を増減するレコメンド計画を立案する。運行調停システム１０２は、レコメンド計画に基づいて、運行計画を立案することで１つ以上の交通モードの運行調停を行う。

なお、移動レコメンドシステム１０１は、利用者の要求に応じてレコメンド計画を立案してもよい。また、レコメンドの結果を利用者が実施したかのフィードバックを得る仕組みを設けてもよい。運行調停システム１０２は、レコメンドの結果を利用者が実施したかを勘案して運行計画を立案してもよい。

そしてそれらの計画の立案は、シミュレーションシステム１０３が相互の効果をシミュレーションすることで実現される。

本発明によって、特に利用者は、混雑回避などスムースな移動を実現でき、移動／購買／観光の促進につながり、ＱｏＬ（Quality of Life）向上を実現できる。

一方で、交通事業者は、各事業者のＫＰＩ（Key Performance Indicator）を充足し、損をしないオペレーションを実現できる。

また、例えば新規交通モードが参入する等、ＭａａＳ（Mobility as a Service）への参入への合意が可能となる。従来は新規交通モードが参入しようとすると、既存事業者のＫＰＩへの影響が不明であることから、参入が困難な傾向にあったのに対して、本発明によれば、上記のように各事業者が損をしないオペレーションを実現できるためである。

特に、これは各事業者のＫＰＩが指定値を下回らないように運行計画を立案するだけでなく、利用者の移動がしかるべき経路及び時間で増減されることで実現できる。

これらによって、利用者は、目的地／立寄り地／ルート／出発タイミング／イベントなどのレコメンド／インセンティブが得られ、自然にＱｏＬ向上につながる移動をするようになることが期待できる。

また、交通事業者は、シミュレーション結果とＫＰＩ評価結果に基づくオペレーション情報／運行計画の提供によって、自然に他交通事業者と調停し持続的な運行をするようになることが期待できる。

＜システム構成＞
図２は、本発明の実施例のシステム構成の一例を示すブロック図である。

本発明を実現するシステムは、少なくとも移動レコメンドシステム１０１、運行調停システム１０２及びシミュレーションシステム１０３からなるが、これらは夫々個別のシステムとしても良いし、それらの任意の２つ又は全部が１つのシステムとして構成されても良い。

移動レコメンドシステム１０１、運行調停システム１０２及びシミュレーションシステム１０３は、ネットワーク２０１に接続され、ネットワーク２０１を介して相互にデータを送受信することが可能である。

システムには更に、ネットワーク２０１に接続された１つ以上の交通利用者端末２０２、１つ以上の交通事業者運行計画システム２０３及び合意形成システム２０４を含む。

運行調停システム１０２は、複数交通事業者及び交通モードに対して最適な運行計画を立案し、交通事業者運行計画システム２０３及び合意形成システム２０４に提供する。

移動レコメンドシステム１０１は、移動需要を増加するためのレコメンド／インセンティブ情報（以下、これらを単にレコメンドと記載する）を交通利用者端末２０２に提供する。

シミュレーションシステム１０３は、運行調停システム１０２から得られる運行計画と、移動レコメンドシステム１０１から得られるレコメンド結果に基づいて、各交通事業者及び交通モードにおける運行区間の利用者及び遅延時間等をシミュレーションし、上記運行調停システム１０２及び移動レコメンドシステム１０１に提供する。

交通利用者端末２０２は、交通利用者が利用する端末装置であり、移動レコメンドシステム１０１によってレコメンドされた情報を表示したり、交通利用者がレコメンド情報を選択した結果を入力したりすることができる。

交通事業者運行計画システム２０３及び合意形成システム２０４は、それぞれ交通事業者及び1社以上の交通事業者や自治体などが利用するシステムであり、運行調停システム１０２によって立案された運行計画による運行状況及びＫＰＩを表示したり、運行計画の立案条件を指定したりすることができる。特に、個々の交通事業者運行計画システム２０３は、個々の交通事業者又は交通モードの運営会社が、自社又は自社の交通モードに対する運行計画を立案するために用いる。合意形成システム２０４は、複数の交通事業者又は複数の交通モードの運営会社が、全体及び自社又は自社の交通モードに対する運行状況及びＫＰＩを確認及び修正するために用いる。また、合意形成システム２０４は、地域における複数交通モードの運行状況及びＫＰＩ値を確認及び修正するために自治体などが用いても良い。

＜移動レコメンドシステム構成＞
図３は、本発明の実施例の移動レコメンドシステム１０１の構成例を示すブロック図である。

移動レコメンドシステム１０１は、少なくとも記憶部３１０及び演算部３００からなる。

記憶部３１０には、交通利用者の利用者ＩＤ３１１、利用者属性情報３１２、利用者位置情報３１３、場所訪問履歴３１４、経路選択履歴３１５及び購買履歴３１６などの利用者に付随した情報の他、施設等の場所情報３１８及び施設等におけるイベント／広告情報３１７（クーポン情報などを含む）などが格納される。また、記憶部３１０には、運行調停システム１０２によって生成される運行計画３１９及びシミュレーションシステム１０３によって生成されるシミュレーション結果３２０も格納される。

利用者ＩＤ３１１は、利用者に一意の識別子であり、どの利用者にどのようなレコメンドを行ったかを管理するためのＩＤである。

利用者属性情報３１２は、例えば利用者の年齢及び性別等の属性情報である。

利用者位置情報３１３は、利用者の自宅及び勤務地がどこにあるか、あるいは利用者が現在どこにいるか、等を示す位置情報であり、地域名又は緯度／経度の情報であっても良い。

場所訪問履歴３１４は、利用者がいつ、どこを訪問したかを示す情報であり、地名、施設名又は緯度／経度の情報であっても良い。

経路選択履歴３１５は、利用者がいつ、どこを訪問するために、どういう経路を選択したか、どういう条件（空いている／座っていける、早く行ける、楽に行ける、安く行ける等）の経路を選択したか、を示すリストである。例えば、経路選択履歴３１５は、前述の場所訪問履歴３１４の各履歴に対応して、後述する交通データにおけるリンク情報と条件のセットをリスト化したものであってもよい。

購買履歴３１６は、利用者がいつ、どこで、何を購入したかを示す情報であり、例えばＰＯＳ（Point of Sales）であってもよい。

上記の情報は、それぞれ別データとして保持し、利用者ＩＤに対応づけて参照できるようにしても良いし、１つのデータテーブルに含めても良い。

場所情報３１８は、施設等の位置及び属性などの情報であり、例えば、ＰＯＩ（Point of interest）情報であってもよい。

イベント／広告情報３１７は、施設等におけるイベントの有無及びその内容又は広告情報である。例えば、イベント／広告情報３１７は、いつ、どこで、だれのコンサートがあるといった情報、いつ、どこで、何が安いといった広告の情報、又はクーポンの情報等であってもよい。

運行計画３１９は、運行調停システム１０２によって生成される運行計画であり、詳細は後述する。

シミュレーション結果３２０は、シミュレーションシステム１０３によって生成されるシミュレーション結果であり、詳細は後述する。

演算部３００では、レコメンド計画プログラム３０１及びレコメンド計画修正／実施プログラム３０２が動作する。レコメンド計画プログラム３０１及びレコメンド計画修正／実施プログラム３０２は、例えば記憶部３１０に格納され、必要に応じて演算部３００によって読み出されて実行されてもよい。

レコメンド計画プログラム３０１は、利用者に対して、どのようなレコメンドを実施するかを計画する処理を演算部３００に実行させるためのプログラムである。この処理は、特に、利用者のＩＤ、位置、訪問履歴、購買履歴、イベント／広告情報、場所情報及び後述するシミュレーションシステム１０３によるシミュレーションの結果に基づいて、行先、立ち寄り先、ルート、出発タイミング及びポイント等を計画する（詳細は後述）。

レコメンド計画修正／実施プログラム３０２は、レコメンド計画プログラム３０１に基づく処理によって計画されたレコメンド内容を修正する処理を演算部３００に実行させるためのプログラムである。この処理は、特に、利用者のＩＤ、位置、訪問履歴、購買履歴、イベント／広告情報、場所情報及び後述するシミュレーションシステムの結果に基づいて、行先、立ち寄り先、ルート、出発タイミング及びポイント等を交通利用者端末２０２に提供する処理を含む（詳細は後述）。

＜運行調停システム構成＞
図４は、本発明の実施例の運行調停システム１０２の構成例を示すブロック図である。

運行調停システム１０２は、少なくとも記憶部４１０及び演算部４００からなる。

記憶部４１０には、交通データ４１１、運行計画４１２、シミュレーション結果４１３及びＫＰＩ４１４が格納される。

交通データ４１１は、交通事業者又は交通モードの運営会社によって運行される交通機関の運行実績及び利用実績であり、詳細は後述する。

運行計画４１２は、運行調停システム１０２によって生成される運行計画であり、詳細は後述する。

シミュレーション結果４１３は、シミュレーションシステム１０３によって生成されるシミュレーション結果であり、詳細は後述する。

ＫＰＩ４１４は、例えば各交通事業者等によって指定されたＫＰＩであり、詳細は後述する。

演算部４００では、現状評価プログラム４０１及び運行計画立案プログラム４０２が動作する。

現状評価プログラム４０１は、各交通事業者あるいは各交通モードごとに、交通事業者運行計画システム２０３及び／又は合意形成システム２０４によって指定されるＫＰＩを算出し、これらが指定値を下回っているか否かを評価する処理を演算部４００に実行させるためのプログラムである。ここで、ＫＰＩの指定値は、各交通事業者又は各交通モードの運営会社が指定したＫＰＩについて、満たすことを希望する値として指定したものであってもよい。

ＫＰＩは、例えば、交通事業者、交通モード、便、区間における利用者数、需給バランス（供給量と需要量の差であり、例えば、容量とその占有量の差）、遅延時間、及び乗車密度（走行距離当たりの利用人数）などの他、収益、コスト及び利益などの少なくともいずれかであっても良い。

演算部４００は、現状評価プログラム４０１に従って、これら交通事業者あるいは交通モードの運営会社から指定されたＫＰＩ値を算出して、交通事業者運行計画システム２０３及び／又は合意形成システム２０４に表示する処理を実行する。また、このとき、遅延時間のような運行状態、並びに、乗車人数及び乗車率のような利用状態をアニメーションなどで表示できるようにしても良い。これらの表示例については後述する。

運行計画立案プログラム４０２は、移動レコメンドシステム１０１及びシミュレーションシステム１０３と連携して、各交通事業者あるいは各交通モードごとに、交通事業者運行計画システム２０３及び／又は合意形成システム２０４によって指定されるＫＰＩ値を算出し、これらが指定値を下回らない運行計画（ルート、ダイヤ及び使用車両などの計画）を立案する処理を演算部４００に実行させるためのプログラムである。この処理は、特に、各交通事業者及び交通モードに対して後述するシミュレーションシステム１０３によるシミュレーションの結果を用いてＫＰＩ値を評価し、それぞれのＫＰＩ値が指定値を下回らない運行計画を立案して、当該運行計画の予測ＫＰＩ値と共に運行計画を交通事業者運行計画システム２０３及び／又は合意形成システム２０４に提供する処理を含む（詳細は後述する）。

＜シミュレーションシステム構成＞
図５は、本発明の実施例のシミュレーションシステム１０３の構成例を示すブロック図である。

シミュレーションシステム１０３は、少なくとも記憶部５１０及び演算部５００からなる。

記憶部５１０には、運行調停システム１０２によって生成される運行計画５１１（後述）及び移動レコメンドシステム１０１によって生成されるレコメンド計画５１２（後述）が格納される他、先に説明した施設等の場所情報５１４及び施設等におけるイベント／広告情報５１３（クーポン情報などを含む）などが格納されても良い。また、記憶部５１０には、晴れ又は雨など天気の情報、気温、風速、湿度などを含む気象情報５１５、人口統計情報などの人口情報５１６及び人が何時に何処から何処へ移動したかなどを含む移動情報５１７などが格納されても良い。

演算部５００では、シミュレーションプログラム５０１が動作し、上記記憶部５１０に格納されている運行計画５１１で交通モードを運行した場合の、交通事業者、交通モード、便及び区間ごとの利用人数及び遅延時間をシミュレーションする。このとき、演算部５００は、例えば上記記憶部５１０にオプションで格納されるイベント／広告情報５１３、場所情報５１４、気象情報５１５、人口情報５１６、及び移動情報５１７などをシミュレーション条件として用いてシミュレーションしても良い。これは、公知のシミュレーション技術などで実現できる。

ただし、本発明では特に、これらの情報に加えて、移動レコメンドシステム１０１によって生成されるレコメンド計画５１２を加味してシミュレーションする。これは例えば、レコメンド計画５１２によってレコメンドされた交通事業者、交通モード、便、区間の利用確率、及び、後述するレコメンド選択確率を乗算することによって、利用人数及び遅延時間を補正することで実現できる。

＜システム間の連係動作＞
図６は、本発明の実施例のシステム間の連係動作例を示すシーケンス図である。

図６に示す処理では、まず、合意形成システム２０４又は交通事業者運行計画システム２０３がＫＰＩを指定し、運行調停システム１０２に通知する（ステップ６０１）。このとき、特に、改善対象とする交通事業者、交通モード、便及び区間等のいずれか又はそれらの任意の組み合わせを条件として指定しても良い。

運行調停システム１０２は、交通データを取得する（ステップ６０２）。前述の現状評価プログラム４０１は、取得された交通データに基づいて現状を評価する（ステップ６０３）。具体的には、運行調停システム１０２は、運行状態及びＫＰＩ値を算出する。このとき、運行調停システム１０２は、特に、ステップ６０１で改善対象とする交通事業者、交通モード、便及び区間等が条件として指定されている場合には、条件に合った交通データを取得しても良い。

運行調停システム１０２は、ステップ６０３で評価した現状評価結果を合意形成システム２０４又は交通事業者運行計画システム２０３に提供する（ステップ６０４）。

合意形成システム２０４又は交通事業者運行計画システム２０３は、ステップ６０４で運行調停システム１０２によって提供された現状評価結果に基づいて、運行状態及びＫＰＩ値などを表示する（ステップ６０５）。このときの表示例については後述する。

交通事業者又は自治体関係者等が、ステップ６０５で表示された運行状態及びＫＰＩ値などを確認し、合意形成システム２０４又は交通事業者運行計画システム２０３が、運行調停システム１０２に改善要求を発行する（ステップ６０６）。このとき、特に、改善対象とする交通事業者、交通モード、便及び区間等のいずれか又はそれらの任意の組み合わせを指定しても良い。

運行調停システム１０２は、ステップ６０６で発行された改善要求に基づいて、運行計画立案プログラム４０２を動作する（ステップ６０７）。運行計画立案プログラム４０２の処理内容詳細については後述する。以下では概要を述べる。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６０６で発行された改善要求及び条件に基づいて、運行計画を立案し（ステップ６０７）、当該立案した運行計画をシミュレーションシステム１０３に通知し、シミュレーションシステム１０３に対してシミュレーション要求を発行する（ステップ６０８）。

シミュレーションシステム１０３は、ステップ６０８で通知された運行計画とステップ６０８で発行されたシミュレーション要求とに基づいて、前述のシミュレーションプログラム５０１を動作し、ステップ６０８で通知された運行計画を実施した場合の利用人数及び遅延時間をシミュレーションする（ステップ６０９）。なお、このとき、シミュレーションシステム１０３は、ステップ６０６の条件を取得して、当該条件下でシミュレーションを実行しても良い。

また、このとき、シミュレーションシステム１０３は、イベント／広告情報５１３、場所情報５１４、気象情報５１５、人口情報５１６及び移動情報５１７の少なくともいずれか、又はそれらから抽出された情報をシミュレーション条件として使用したシミュレーションを実行してもよい。

シミュレーションシステム１０３は、ステップ６０９で実施したシミュレーションの結果を運行調停システム１０２（運行計画立案プログラム４０２）に通知する（ステップ６１０）。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６１０で通知されたシミュレーション結果に基づいて、改めてＫＰＩ値を算出／評価する（ステップ６０７）。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６０７でＫＰＩ値を評価した結果、ＫＰＩを充足していない場合に、移動レコメンドシステム１０１に運行計画、シミュレーション結果、及び、改善対象とする交通事業者、交通モード、便及び区間等の条件を通知し、レコメンド要求を発行する（ステップ６１１）。なお、ここではＫＰＩを充足していない場合にレコメンド要求を発行するとしているが、その限りではなく、ＫＰＩを充足していてもレコメンド要求を発行しても良い。

移動レコメンドシステム１０１は、ステップ６１１で発行されたレコメンド要求に基づいて、レコメンド計画プログラム３０１を動作する（ステップ６１２）。レコメンド計画プログラム３０１の処理内容詳細については後述する。以下では概要を述べる。

移動レコメンドシステム１０１（レコメンド計画プログラム３０１）は、ステップ６１１で発行されたレコメンド要求、条件、運行計画及びシミュレーション結果に基づいて、どの利用者にどのようなレコメンド（例えば行先、立ち寄り先、ルート、出発タイミング及びポイント提供等のレコメンド）を行うかを計画する（ステップ６１２）。

移動レコメンドシステム１０１（レコメンド計画プログラム３０１）は、レコメンド計画結果を運行調停システム１０２（運行計画立案プログラム４０２）に通知する（ステップ６１３）。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６１３で通知されたレコメンド計画及び運行計画をシミュレーションシステム１０３に通知し、シミュレーションシステム１０３にシミュレーション要求を発行する（ステップ６１４）。なお、このとき、運行調停システム１０２は、改めて運行計画を修正しても良い。

シミュレーションシステム１０３は、前述のシミュレーションプログラム５０１を動作し、ステップ６１４で通知されたレコメンド計画及び運行計画に基づいて、改めて利用人数及び遅延時間をシミュレーションする（ステップ６１５）。

ステップ６１５のシミュレーションは、ステップ６０９と同様に実行することができる。ただし、ステップ６１５では、少なくとも一部の交通利用者がステップ６１４で通知されたレコメンド計画に従って移動をしたという条件がシミュレーション条件に追加される。交通利用者がレコメンド計画に従って移動をする確率は、例えば後述する選択予測（図１０参照）に対応する。

シミュレーションシステム１０３は、ステップ６１５で実施したシミュレーションの結果を運行調停システム１０２（運行計画立案プログラム４０２）に通知する（ステップ６１６）。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６１６で通知されたシミュレーション結果に基づいて、改めてＫＰＩ値を算出／評価する（ステップ６０７）。上記のようにステップ６１５のシミュレーションの条件にはレコメンド計画に基づく移動が含まれるため、これによってレコメンド計画に基づくレコメンドがＫＰＩに与える影響を評価することができる。

運行調停システム１０２（運行計画立案プログラム４０２）は、ステップ６１６で通知されたシミュレーション結果及びそれに基づいてステップ６０７で算出／評価したＫＰＩ値の算出／評価結果を合意形成システム２０４又は交通事業者運行計画システム２０３に通知する（ステップ６１７）。

合意形成システム２０４又は交通事業者運行計画システム２０３は、ステップ６１７で通知されたシミュレーション結果及びＫＰＩ値の算出／評価結果に基づいて運行状態及びＫＰＩ値を表示する（ステップ６１８）。このときの表示例については後述する。

合意形成システム２０４又は交通事業者運行計画システム２０３を使用する交通事業者又は自治体関係者等が計画を承認すると、合意形成システム２０４又は交通事業者運行計画システム２０３が運行調停システム１０２に計画決定通知を発行する（ステップ６１９）。

運行調停システム１０２は、ステップ６１９で発行された計画決定通知を受け取ると、運行計画とステップ６１６で通知されたシミュレーション結果とを移動レコメンドシステム１０１に通知し、移動レコメンドシステム１０１に対して、レコメンド要求を発行する（ステップ６２０）。

移動レコメンドシステム１０１は、ステップ６１１で発行されたレコメンド要求に基づいて、レコメンド計画修正／実施プログラム３０２を動作する（ステップ６２１）。レコメンド計画修正／実施プログラム３０２の処理内容詳細については後述する。以下では概要を述べる。

移動レコメンドシステム１０１（レコメンド計画修正／実施プログラム３０２）は、ステップ６２１で発行されたレコメンド要求、運行計画及びシミュレーション結果に基づいて、ステップ６１２で立案したレコメンド計画を修正する（ステップ６２１）。これは、例えば混雑状況及び運行計画がステップ６１４で修正されている可能性があり、それに合わせてレコメンド計画の修正が必要となる可能性があるためである。

移動レコメンドシステム１０１（レコメンド計画修正／実施プログラム３０２）は、ステップ６２１で修正したレコメンド計画結果を交通利用者端末２０２に通知する（ステップ６２２）。

交通利用者端末２０２は、ステップ６２２で通知されたレコメンド計画結果を表示する（ステップ６２３）。このときの表示例は後述する。

以上の処理によって、運行計画の立案と利用者へのレコメンドが可能となり、移動需要の増減と交通事業者のＫＰＩ充足が可能となる。

なお、本実施例では運行調停システム１０２の処理が移動レコメンドシステム１０１によるレコメンド計画の作成及び修正を誘発したが、交通利用者が交通利用者端末２０２によって、明示的にレコメンド要求を行っても良い（ステップ６２５）。これによって、交通利用者が行きたくなるような場所を自分の意志でレコメンドしてもらうことができ、レコメンド結果を運行計画に反映することができる。

また、交通利用者端末２０２内のタイマーによって、定期的にレコメンド要求がなされても良い（ステップ６２４）。これによって、定期的に交通利用者に対して、行きたくなるような場所をレコメンドでき、レコメンド結果を運行計画に反映することが可能となる。

＜レコメンド計画及びレコメンド計画修正／実施処理＞
図７は、本発明の実施例の移動レコメンドシステム１０１のレコメンド計画プログラム３０１による処理の一例を示すフローチャートである。

レコメンド計画プログラム３０１は、以下の処理を行う。なお、本実施例においてレコメンド計画プログラム３０１が実行するように記載される処理は、実際には、移動レコメンドシステム１０１の演算部３００がレコメンド計画プログラム３０１に従って実行する。他のプログラムについても同様である。例えば運行計画立案プログラム４０２が実行するように記載される処理は、実際には、運行調停システム１０２の演算部４００が運行計画立案プログラム４０２に従って実行する。

レコメンド計画プログラム３０１は、後述する運行計画立案プログラム４０２からレコメンド要求を受け取る（ステップ７０１）。

レコメンド計画プログラム３０１は、後述する運行計画立案プログラム４０２から条件、運行計画及びシミュレーション結果を取得する（ステップ７０２）。ここで、条件とは例えば改善対象とする交通事業者、交通モード、便、区間等の条件である。また、運行計画とは、運行しようとしている交通モードのダイヤ、ルート及び車両（容量）などの運行計画である。シミュレーション結果とは、交通事業者、交通モード、便及び区間ごとの利用人数、及び遅延時間等のシミュレーション結果である。

レコメンド計画プログラム３０１は、ステップ７０２で取得した条件と運行計画に基づいて、レコメンド対象とするエリアと当該エリア内のレコメンド対象者を選定する（ステップ７０３）。例えば、レコメンド計画プログラム３０１は、条件に基づく交通事業者、交通モード、便及び区間等が関係するエリアを１つ以上選定する。

このとき、レコメンド計画プログラム３０１は、例えば、これらの交通事業者の交通モード、便及び区間の走行域の近傍からあらかじめ定めた人数が居住又は存在するようにエリアの大きさを決定しても良い。また、選定した対象エリア内に居住又は存在する人を対象者としても良い。

あるいは、レコメンド計画プログラム３０１は、エリア内に居住又は存在する人数とシミュレーション結果から得られる利用人数との間に乖離があるエリアを対象エリアとし、そのエリアと、そのエリア内に居住又は存在する人を優先的なエリア及び対象者として選定しても良い。さらに、選定したエリア及び対象者は、エリアごとにリスト化して後で参照できるように構成しても良い。

なお、エリア及び対象者あるいは対象人数は、運行計画立案プログラム４０２側で選定して、条件としてレコメンド計画プログラム３０１に通知されるように構成しても良い。

レコメンド計画プログラム３０１は、選定した対象エリアごとに選定した全ての対象者に対して以下の処理を実施する。

レコメンド計画プログラム３０１は、対象エリアについて以下の処理を実施していない対象者がいるかを判定し（ステップ７０４）、対象者がいなければ、他の対象エリアの全ての対象者に対して以下の処理を実施する。

レコメンド計画プログラム３０１は、対象者情報を取得する（ステップ７０５）。対象者情報は、例えば、利用者ＩＤ、利用者の年齢及び性別などの利用者属性情報、利用者の現在位置及び居住位置といった利用者位置情報、場所訪問履歴、経路選択履歴、購買履歴等を含んでもよい。

レコメンド計画プログラム３０１は、外部対象情報を取得する（ステップ７０６）。外部対象情報は、例えば、開催予定のイベント情報、広告情報、施設又は観光地の属性及び位置情報を含む場所情報等を含んでもよい。

レコメンド計画プログラム３０１は、場所レコメンド対象を決定する（ステップ７０７）。決定する方法として、例えば、ステップ７０５で取得した対象者情報とステップ７０６で取得した外部対象情報等を基にして、対象者の場所訪問履歴から好みの場所の属性（例えば景色がきれい等）を特定し、当該属性を持つ対象者が最近訪問していない場所をレコメンド対象として決定するなどの方法がある。

あるいは、対象者と場所訪問履歴が類似している利用者が最近訪問していて、対象者が最近訪問していない場所をレコメンド対象として決定しても良い。あるいは、対象者の購買履歴から当該対象者の嗜好を分析し、当該対象者が好みそうな商品が広告されている場所をレコメンド対象として決定しても良いし、単に近くにイベントがある場合にその場所をレコメンド対象として決定しても良い。

レコメンド計画プログラム３０１は、経路レコメンド対象を決定する（ステップ７０８）。例えば、レコメンド計画プログラム３０１は、ステップ７０５で取得した対象者の位置情報（利用者位置情報）とステップ７０７で決定したレコメンド対象の場所の位置情報とステップ７０２で取得した運行計画とに基づいて、公知の経路探索などによって得られる経路をレコメンド対象として決定しても良い。

このとき、レコメンド計画プログラム３０１は、ステップ７０５で取得した対象者の経路選択履歴から当該対象者の好みを特定し、当該好みに合った経路をレコメンド対象として決定しても良い。例えば、レコメンド計画プログラム３０１は、空いている経路、安い経路、早く行ける経路、及び、乗継が少ないなどの楽な経路等の中から、対象者が良く選ぶ傾向にある経路をレコメンド対象として決定しても良い。

あるいは、レコメンド計画プログラム３０１は、ステップ７０５で取得した利用者属性が高齢者であると判断できる場合は、座っていける経路をレコメンド対象として決定しても良い。あるいは、レコメンド計画プログラム３０１は、対象者が良く利用する経路にできるだけ合った経路、又は、逆に対象者が良く利用する経路とは出来るだけ異なった経路をレコメンド対象として決定しても良い。あるいは、レコメンド計画プログラム３０１は、経路上の途中で混雑している場合には、混雑前に付近にある立ち寄り地を施設情報などからレコメンドしても良い。このとき、例えば経路が何時空くかを判断し経路をレコメンとしても良いし、いつ頃空くかを予測して新たに経路をレコメンドしても良い。なお、空いている経路及び座っていける経路については、ステップ７０２で取得したシミュレーション結果に基づいて判別することができる。

レコメンド計画プログラム３０１は、出発タイミングを計算する（ステップ７０９）。例えば、レコメンド計画プログラム３０１は、ステップ７０５で取得した対象者の位置情報（利用者位置情報）とステップ７０８で決定した経路の中で出発時間が決まっている起点までの距離を基にして、徒歩又は自転車などで行く一般的な時間を計算し、出発時間が決まっている起点に間に合うための出発時刻を算出してもよい。

特に、レコメンド計画プログラム３０１は、ステップ７０８で対象者が座っていける経路を経路レコメンド対象とした場合には、当該経路の中で出発時間が決まっている起点までの距離を基にして、徒歩又は自転車などで行く一般的な時間を計算し、出発時間が決まっている起点に間に合うための出発時刻を算出してもよい。これによって、例えば「今、歩いて出発すれば座っていける可能性がある」ことをレコメンドすることができる。

レコメンド計画プログラム３０１は、選択予測を行う（ステップ７１０）。これは、場所レコメンド対象及び経路レコメンド対象がこれまでに選択又は実際に利用された履歴などに基づいて、これらのレコメンド対象が利用される確率を計算することで実施できる。この予測結果を先に述べたレコメンド選択確率として、シミュレーションシステムが利用できるようにすることで、先に説明した通り、シミュレーションシステム１０３が、移動レコメンドシステム１０１によって生成されるレコメンド計画を加味してシミュレーションすることが可能となる。

レコメンド計画プログラム３０１は、全ての対象エリアの全ての対象者に対してレコメンド計画が立案できたら、レコメンド結果を運行調停システム１０２（運行計画立案プログラム４０２）に通知して（ステップ７１１）、処理を終了する。なお、レコメンド結果データの一例については後述する。

上記は、レコメンド計画プログラム３０１の処理について述べたが、レコメンド計画修正／実施プログラム３０２の処理についても同様である。ただし、レコメンド計画プログラム３０１は最終的にレコメンド結果を運行調停システム１０２に通知するのに対して、レコメンド計画修正／実施プログラム３０２は、最終的にレコメンド結果を交通利用者端末に通知する。

＜運行計画立案処理＞
図８は、本発明の実施例の運行調停システム１０２の運行計画立案プログラム４０２による処理の一例を示すフローチャートである。

運行計画立案プログラム４０２は、以下の処理を行う。

運行計画立案プログラム４０２は、交通事業者又は交通モード毎のＫＰＩを取得する（ステップ８０１）。例えば、合意形成システム２０４又は交通事業者運行計画システム２０３などを介して、交通事業者などから指定されたＫＰＩが運行計画立案プログラム４０２に通知されても良い。その場合、通知されたＫＰＩは記憶部４１０にＫＰＩ４１４として保持される。あるいは、あらかじめ、交通事業者又は交通モード毎のＫＰＩが運行計画立案プログラム４０２に設定されて（具体的には例えば記憶部４１０にＫＰＩ４１４として保持されて）いても良い。

また、あらかじめ、ファイルなどに交通事業者又は交通モード毎のＫＰＩが設定されていて、運行計画立案プログラム４０２が当該ファイルを読み込むことで設定されても良い。また、上記のいずれかの方法で交通事業者ごとに複数のＫＰＩがある場合には、それらの優先順位が設定されても良い。

なお、ここで取得される交通事業者又は交通モード毎のＫＰＩは、交通事業者又は交通モード毎に、例えば利用人数、需給バランス、遅延時間、乗車密度、コスト又は収益などといった評価指標のうちいずれのものを使用するかを指定する情報と、その評価指標が充足されたかどうかを判定するための基準値を指定する情報とを含んでもよい。

また、複数の交通事業者が同一のＫＰＩを指定してもよいし、それぞれ異なるＫＰＩを指定してもよい。また、一つの交通事業者が複数の交通モード（例えば複数の鉄道路線、又は、鉄道とバス等の複数の交通モード）を運営している場合、それらについて同一のＫＰＩを指定してもよいし、それぞれ異なるＫＰＩを指定してもよい。また、交通モードの路線や経路及び区間ごとにＫＰＩが指定されてもよい。

運行計画立案プログラム４０２は、合意形成システム２０４又は交通事業者運行計画システム２０３から、運行計画立案の対象となる交通モード、便、区間等の条件を取得する（ステップ８０２）。このとき、運行計画立案プログラム４０２は、これらの条件に影響を与える他社の交通モードのルート及びダイヤなどの情報、並びに、これらに変更があった場合の変更点を条件として取得しても良い。また、運行計画立案プログラム４０２は、利用可能な車両、その種別（容量）、運行可能な運転士及び運行に必要となるスタッフなどのアセット情報を条件として取得しても良い。

運行計画立案プログラム４０２は、ステップ８０１で取得したＫＰＩとステップ８０２で取得した条件とに基づいて、運行計画を立案する（ステップ８０３）。このとき、運行計画立案プログラム４０２は、運行計画としてはダイヤ、ルート及び利用車両などを変更する。例えば、ある区間の利用人数がＫＰＩとなっていて、当該ＫＰＩ値が指定値を下回っていた場合には、人口統計データなどの人口情報を参照して、住民が多い地域を通るように経路を変更してもよい。

あるいは、需給バランスがＫＰＩとなっている場合において、空車と満車が交互にある場合には一部の車両のサイズを小さくする等の変更を行ってもよい。また、ある時間帯に定常的に混雑している場合にはダイヤを変更して、当該時間帯の運行本数を増やすなどの変更を行ってもよい。

さらに、運行計画立案プログラム４０２は、近辺に他の交通モードが走行している場合には、これらのＫＰＩに影響を与えない変更を行う。これらはよく知られるＡＩ（Artificial Intelligence）及び機械学習等によって行うことができる。

なお、変更できることは、交通モードによって異なっていることがあり、交通事業者の方針にも依存することがある。このため、運行計画のうち、変更できる項目及びその優先順位などを指定できるようにシステムを構成しても良いし、あらかじめ設定できるようにシステムを構成しても良い。または、一般的に、鉄道はルートを変更することが困難である可能性もあるため、例えば、鉄道では利用車両、ダイヤ、始点終点、ルートの順で変更の順で変更し、オンデマンドバスではルート及び利用車両のみを変更する等をルール化して、運行計画立案プログラム４０２は当該ルールに基づいて運行計画を立案するようにシステムを構成しても良い。

また、運行計画の項目が変更できるか否かは、時間的な制約条件（例えばＫＰＩの改善の対象となる時期までの時間の長さ）にも依存することがある。例えば、鉄道の運行計画については、数日後のＫＰＩを改善しようとする場合であれば、車両の変更、停車駅の変更又は臨時便の増発等は可能であっても、新しい駅又は路線の追加は通常困難であるとも考えられる。しかし、数年後のＫＰＩを改善しようとする場合には、新しい駅又は路線を追加できる可能性がある。このため、運行調停システム１０２は、交通モードだけでなく時間的な制約条件にも応じた、変更できる運行計画の項目及びその優先順位の情報を保持し、運行計画立案プログラム４０２はその情報に基づいて運行計画を立案及び変更してもよい。

運行計画立案プログラム４０２は、シミュレーションシステム１０３に対してシミュレーション要求を発行する（ステップ８０４）。このとき、運行計画立案プログラム４０２は、ステップ８０２で取得した条件とステップ８０３で立案した運行計画もシミュレーションシステム１０３に通知する。ここで、シミュレーションシステム１０３は、当該通知された運行計画と当該発行されたシミュレーション要求とに基づいて、前述のシミュレーションプログラム５０１を動作し、当該通知された運行計画を実施した場合の利用人数及び遅延時間をシミュレーションする。

ステップ８０４のシミュレーション結果に基づいて、前述の現状評価プログラム４０１が改めてＫＰＩ値を算出し、運行状態を評価する（ステップ８０５）。

運行計画立案プログラム４０２は、各交通事業者及び交通モードのＫＰＩが充足されているか判断する（ステップ８０６）。ここでは、改善対象とした交通事業者及び交通モードのＫＰＩが充足したかだけでなく、関連するすべての交通事業者及び交通モードのＫＰＩが充足しているかを判断する。運行計画立案プログラム４０２は、ＫＰＩを充足していると判断した場合には運行計画立案結果を合意形成システム２０４又は交通事業者運行計画システム２０３に送信して、運行計画立案プログラム４０２の処理を終了する。

一方で、ステップ８０６における判断の結果、ＫＰＩが充足されていない各交通事業者及び交通モードがある場合には、運行計画立案プログラム４０２は、他に計画案があるかを判断する（ステップ８０７）。例えば、ステップ８０３で得られる別の計画があればそれを他の計画案としても良いし、改めてステップ８０３の処理を実施して先の計画とは異なる別の計画を選択しても良い。

なお、ステップ８０７において他案の有無を評価する際には、例えばあらかじめ決められた数の計画案を対象として判断しても良い。あるいは、ステップ８０３からステップ８０７の繰り返しにあらかじめ決められた所要時間（例えば３０分等）以上の時間を要した場合には、他案無しとして判断しても良い。あるいは、これらの対象とする計画案数又は所要時間を交通事業者及び交通モード毎に指定できるようにシステムを構成しても良い。

特に、例えば、鉄道やバス等においては比較的時間を要してもより良い計画を得たい場合もある。このため、これらの対象とする計画数又は所要時間をあらかじめ多めに設定したり、交通事業者又は交通モードの運行事業者がこれらの計画数又は所要時間を指定できると有効である。一方で、例えばオンデマンドバス又はタクシー等においては、適時運行するため、リアルタイム性が要求されることが考えられる。このため、これらの対象とする計画数又は所要時間をあらかじめ少なめに設定したり、交通事業者又は交通モードの運行事業者がこれらの計画数又は所要時間を指定できることが望ましい。

運行計画立案プログラム４０２は、ステップ８０６で各交通事業者及び交通モードのＫＰＩが充足すると判断されるか、又は、ステップ８０７で他案がなくなるまで上記ステップ８０４からステップ８０７まで繰り返す。なお、繰り返す際は、新しい計画でステップ８０４のシミュレーションとステップ８０５のＫＰＩ値の計算／評価が実施される。

運行計画立案プログラム４０２は、ステップ８０７で他に計画案がないと判断した場合、すなわちすべての計画案に対してシミュレーション及びＫＰＩ値の算出／評価が実施された場合には、移動レコメンドシステム１０１（レコメンド計画プログラム３０１）にステップ８０６で最もＫＰＩを充足していた運行計画、その運行計画に対するシミュレーション結果、及び、ＫＰＩを充足していない交通事業者、交通モード、便、区間等の条件を通知し、レコメンド要求を発行する（ステップ８０８）。

ここで、移動レコメンドシステム１０１におけるレコメンド計画プログラム３０１が、先に説明した通りレコメンド計画を立案する（図７参照）。なお、このとき、ステップ８０２で得られた改善対象とする交通事業者、交通モード、便、区間等の条件、又はレコメンドの対象とするエリア、対象者数を指定することで、前述した通り、レコメンド計画においてレコメンド対象エリア及びレコメンド対象者を特定できるようになる。

運行計画立案プログラム４０２は、レコメンド計画に更新があったか否かを判断し（ステップ８０９）、更新があった場合には、ＫＰＩを充足するか、レコメンド計画を更新できる限りステップ８０４からステップ８０８を繰り返す。このとき、既にあらかじめ決められた数のレコメンド計画を更新した場合には、レコメンド結果に更新無しと判断しても良い。また、この繰り返しにおいて、ステップ８０４のシミュレーションを行う前に、改めて運行計画を立案しても良い。ただし、できるだけ計画立案の繰り返しを収束させるため、及び、レコメンド結果を収束させるために、車両（容量）を変更するなど、ダイヤ及びルートの計画変更を行わないことが望ましい。

運行計画立案プログラム４０２は、ステップ８０６で各交通事業者及び交通モードのＫＰＩが充足されていると判断できた場合、又は、ステップ８１０でレコメンド結果の更新がなくなった場合には、最終的にステップ８０６で最もＫＰＩを充足していた運行計画を運行計画立案結果として、合意形成システム２０４又は交通事業者運行計画システム２０３に送信して（ステップ８１０）、運行計画立案プログラム４０２の処理を終了する。

なお、上記の例では、考えうる運行計画変更案に対してＫＰＩ値を評価した後に、レコメンド計画を立案する例を示した。しかし、本実施例のレコメンド計画の立案及び運行計画の変更の手順はこの例に限定されない。例えば、移動レコメンドシステム１０１がレコメンド計画を立案してから運行調停システム１０２が運行計画を変更しても良い。あるいは、運行調停システム１０２が運行計画を１つ変更してそれに対して移動レコメンドシステム１０１がレコメンド計画を立案するというように運行計画とレコメンド計画を１つずつセットにして行っても良い。また、逆に、移動レコメンドシステム１０１がレコメンド計画を１つ立案してそれに対して運行調停システムが運行計画を立案するというようにレコメンド計画と運行計画を１つずつセットにして行っても良い。これらの順序及びセットにする計画案の数等のバリエーションは制限されない。

＜交通データ構造＞
図９は、本発明の実施例の運行調停システム１０２が保持する交通データ４１１のデータ構造の一例を示す説明図である。

交通データ４１１は、複数の交通事業者及び交通モードの運行計画、運行実績及び利用実績を含む。

具体的には、図９に示す交通データ４１１は、国９０１、地域９０２、起点９０３、終点９０４、リンク９０５、道路種別９０６、事業者９０７、交通モード９０８、車両種別９０９、乗務員数９１０、容量９１１、個体識別子９１２、日９１３、曜日９１４、予定時刻９１５、実時刻９１６、遅れ時間９１７、乗車人数９１８、降車人数９１９、輸送人数９２０、乗車率９２１及び全収入９２２等のデータを持つ。

国９０１は、交通モードが走行する、後述する起点から終点までの区間が位置する国を示す。例えば、国９０１は、国コード又は国名など、国を一意に識別できる値又は文字列とすればよい。

地域９０２は、交通モードが走行する、後述する起点から終点までの区間が位置する地域を示す。例えば、地域９０２は、地域コード又は地域名等、前述の国名と合わせて一意に識別できる値又は文字列とすればよい。

起点９０３及び終点９０４は、それぞれ、後述する事業者の交通モードが走行する最小区間の始点及び終点を示す。例えば、起点９０３及び終点９０４は、地域名、住所、バス停名、駅名、バス停コード、駅コード、又は緯度と経度等の文字列又は数値とすればよい。なお、当該起点及び終点は、例えば隣り合うバス停や駅であり、終点は、起点の次に止まる駅又はバス停などであってもよい。

リンク９０５は、前述の起点と終点のセットであり、区間を示す。例えば、リンク９０５は、起点と終点をハイフン等で接続した文字列などとすればよい。

道路種別９０６は、上記リンクの道路種別を示す。例えば、道路種別９０６は、鉄道、高速道、都市高速、一般道、その他などであってもよい。また、道路種別９０６は、一般道のうち国道、県道、市道など、及び、高速道のうち東名高速などの種別を含んでも良く、それぞれを識別できる数値又は文字列とすればよい。

事業者９０７は、後述する交通モード及び前述のリンクを運行する交通事業者を示す。例えば、事業者９０７は、事業者コード又は事業者名など、事業者を一意に示す数値又は文字列とすればよい。

交通モード９０８は、鉄道、路線バス、オンデマンドバス、タクシーなどの乗物を示し、これらを一意に示す文字列又は数値とすればよい。

車両種別９０９は、使用する車両の種別であって、例えば、車両の大きさ（例えば特大、大型、中型、普通、軽自など）を示す文字列又は数値とすればよい。また、編成車両数を組み合わせても良い。

乗務員数９１０は、上記リンクで上記交通モードを運行する乗務員数を格納すればよい。

容量９１１は、車両種別で示された使用する車両の容量であって、乗車容量すなわち定員を示す数値とすればよい。

個体識別子９１２は、車両種別で示された使用する車両の識別子であって、車両を一意に示すものであればいかなるものでも良い。例えば、個体識別子９１２は、車両の登録番号、車載器のＩＤ、又は、系統番号もしくは系統コードと便番号との組み合わせなどの、数値又は文字列であってもよい。

日９１３は、運行する日を示す。例えば、日９１３は、ＹＹＹＹ／ＭＭ／ＤＤ（Ｙは年、Ｍは月、Ｄは日を示す）形式の文字列、又は、ＹＹＹＹＭＭＤＤと固定の桁数の数値など、運行する年、月、日を識別できる形式であれば何でもよい。

曜日９１４は、上記日で示される車両を運行する日の曜日を示す。例えば、曜日９１４は、曜日を示す文字列であってもよいし、月曜日を１、火曜日を２とするなど、曜日と対応した数値であってもよい。

予定時刻９１５は、前述した起点を出発する予定時刻であり、例えばダイヤなどで示される、駅又はバス停の出発予定時刻である。これは、例えば「：」で時と分が区切られた形式の文字列、又は、ＨＨＭＭ（Ｈは時、Ｍは分を示す）形式などの固定の桁数の数値など、対応する起点の出発予定時刻を識別できる形式であれば何でもよい。なお、予定時刻が決まっていない場合には、予定時刻９１５をＮＡなどの文字列又は０などの特別な数値とすればよい。

実時刻９１６は、前述した起点を実際に出発した実績の時刻であり、前述の予定時刻９１５と同様の形式とすればよい。

遅れ時間９１７は、前述した予定時刻と前述した実時刻との差である。これは、予定していた出発時刻に対して、実際に出発した時刻がどれだけ遅れたかを示す時間であり、その時間を示す分数又は秒数などの数値とすればよい。なお、予定時刻が決まっていないなどの理由で遅れ時間が定義できない場合にはＮＡなどの文字列又は０などの特別な数値とすればよい。

乗車人数９１８は、前述した起点で前述した個体識別子の車両に乗車した人数であり、乗車した人数を示す数値とすればよい。

降車人数９１９は、前述した起点で前述した個体識別子の車両から降車した人数であり、降車した人数を示す数値とすればよい。

輸送人数９２０は、前述の起点から前述の終点まで前述した個体識別子の車両が輸送した人数であり、輸送した人数を示す数値とすればよい。

乗車率９２１は、前述の起点から前述の終点までの、前述した個体識別子の車両の乗車率であり、例えば車両の空間占有率などである。これは、例えば、前述の輸送人数を、前述の容量で割った数値又はそれを示す文字列とすればよい。

全収入９２２は、前述の個体識別子の車両によって得られた収入である。例えば、全収入９２２は、当該車両に乗車した人が運賃として支払った金額の合計値とすればよく、また、当該車両が運行した全区間で得た収入の金額の合計値としても良い。

上記の交通データ４１１によって、ある地域を運行する複数の交通事業者及び交通モードの運行計画、運行実績及び利用実績を示すことができる。

＜運行計画データ構造＞
運行調停システム１０２が計画した運行計画データ（例えば運行計画３１９、運行計画４１２及び運行計画５１１）は、上述した交通データ４１１の国９０１、地域９０２、起点９０３、終点９０４、リンク９０５、道路種別９０６、事業者９０７、交通モード９０８、車両種別９０９、乗務員数９１０、容量９１１、個体識別子９１２、日９１３、曜日９１４及び予定時刻９１５を持つデータ構造とすればよい。

これによって、ある地域を運行する複数の交通事業者及び交通モードの運行計画を示すことができる。

＜シミュレーション結果データ構造＞
シミュレーションシステムでシミュレーションした結果（例えばシミュレーション結果３２０及びシミュレーション結果４１３）のデータ構造は、前述した交通データ４１１と同等とすることができる。

ただし、シミュレーション結果における実時刻９１６、遅れ時間９１７、乗車人数９１８、降車人数９１９、輸送人数９２０、乗車率９２１及び全収入９２２、等のデータについては、交通データ４１１で示したような実績ではなく、シミュレーション結果として得られた数値又は文字列とすればよい。

すなわち、シミュレーションシステム１０３は、前述の運行計画のデータを受け取り、実時刻９１６、遅れ時間９１７、乗車人数９１８、降車人数９１９、輸送人数９２０、乗車率９２１及び全収入９２２等を計算するためのシミュレーションを実行し、その結果をシミュレーション結果４１３等に格納するように構成すればよい。

＜レコメンド計画データ構造＞
図１０は、本発明の実施例の移動レコメンドシステム１０１が生成するレコメンド計画５１２のデータ構造の一例を示す説明図である。

図５に示したように、シミュレーションシステム１０３がレコメンド計画５１２を保持しているが、これは、移動レコメンドシステム１０１のレコメンド計画プログラム３０１によって立案されたものである。したがって、実際には、レコメンド計画は、移動レコメンドシステム１０１のレコメンド計画プログラム３０１によって立案され、記憶部３１０に保持され（図６のステップ６１２）、その後、運行調停システム１０２を介してシミュレーションシステム１０３に送信され（ステップ６１３、６１４）、シミュレーションシステム１０３の記憶部５１０にレコメンド計画５１２として保持される。

レコメンド計画５１２のデータ構造は、移動レコメンドシステム１０１で生成する複数の人に対する出発地、目的地、経路、出発時刻などのデータを格納する。

レコメンド計画５１２のデータは、利用者ＩＤ１００１、計画ＩＤ１００２、出発地１００３、目的地１００４、区間起点１００５、区間終点１００６、交通モード１００７、リンク１００８、道路種別１００９、事業者１０１０、車両種別１０１１、容量１０１２、個体識別子１０１３、出発日１０１４、出発曜日１０１５、出発時刻１０１６、経路特徴１０１７及び選択予測１０１８等のデータを含む。

利用者ＩＤ１００１は、レコメンド対象となる利用者のＩＤであり、利用者を一意に判別できる識別子の文字列又は数値とすればよい。なお、同一利用者に複数のリンクからなる経路をレコメンドする場合には、一人の利用者に関するデータとして、同一の利用者ＩＤを持つ複数のデータが存在しても良い。

計画ＩＤ１００２は、移動レコメンドシステム１０１が立案した計画を識別するＩＤであり、計画毎に一意に判別できる識別子の文字列又は数値とすればよい。なお、同一利用者に複数のリンクからなる経路をレコメンドする場合には、一つの計画に関するデータとして、同一の計画ＩＤを持つ複数のデータがリンクごとに存在しても良い。

出発地１００３は、利用者ＩＤで示されるレコメンド対象の利用者の出発地であり、移動レコメンドシステム１０１が利用者にレコメンドする出発地である。これは、出発地又は出発エリアを一意に判別できる文字列又は数値とすればよい。例えば、出発地１００３は、出発地となるバス停名、駅名又はこれらのコードであってもよいし、地名又は住所を示す数値又は文字列などであってもよい。

目的地１００４は、利用者ＩＤで示されるレコメンド対象の利用者の目的地であり、移動レコメンドシステム１０１が利用者にレコメンドする目的地（すなわち移動レコメンドシステム１０１が決定した場所レコメンド対象）である。これは、目的地又は目的エリアを一意に判別できる文字列又は数値とすればよい。例えば、目的地１００４は、目的地となるバス停名、駅名又はこれらのコードであってもよいし、地名又は住所を示す数値又は文字列などであってもよい。

区間起点１００５は、前述した出発地から前述した目的地に向かうまでの経路における区間ごとの起点であり、例えば一つの交通モードで乗り換えなしに行ける区間の起点とすればよい。これは、区間の起点又は起点エリアを一意に判別できる文字列又は数値とすればよい。例えば、区間起点１００５は、バス停名、駅名又はこれらのコードであってもよいし、地名又は住所を示す数値又は文字列などであってもよい。

区間終点１００６は、前述した出発地から前述した目的地に向かうまでの経路（すなわち移動レコメンドシステム１０１が決定した経路レコメンド対象）における区間ごとの起点に対応した終点であり、例えば一つの交通モードで乗り換えなしに行ける区間の起点に対応した終点とすればよい。または区間起点の隣の駅やバス停としても良い。これは、区間の終点や終点エリアを一意に判別できる文字列や数値とすればよい。例えば、区間終点１００６は、バス停名、駅名又はこれらのコードであってもよいし、地名又は住所を示す数値又は文字列などであってもよい。

交通モード１００７は、前述した起点から前述した終点までに利用者が利用する交通モードであり、例えば、鉄道、路線バス、オンデマンドバス又はタクシーなどの乗物を示す。交通モード１００７は、これらを一意に示す文字列又は数値とすればよいが、交通データ４１１における交通モード９０８と対応可能なように構成する。

リンク１００８は、前述の区間起点と区間終点のセットであり、区間を示す。例えば、リンク１００８は、区間起点と区間終点をハイフン等で接続した文字列などとすればよい。

道路種別１００９は、上記リンクの道路種別を示す。例えば、道路種別１００９は、鉄道、高速道、都市高速、一般道、その他などであってもよい。また、道路種別１００９は、一般道のうち国道、県道、市道など、及び、高速道のうち東名高速などの種別を含んでも良い。道路種別１００９は、上記の種別のそれぞれを識別できる数値又は文字列とすればよいが、交通データ４１１における道路種別９０６と対応可能なように構成する。

事業者１０１０は、前述のリンクで前述の交通モードを運行する交通事業者を示し、特に利用者が当該リンクで利用する交通モードの運行事業者を示す。これは、事業者コード又は事業者名など、事業者を一意に示す数値又は文字列とすればよいが、交通データ４１１における事業者９０７と対応可能なように構成する。

車両種別１０１１は、前述した利用者が利用する交通モードの車両の種別であって、例えば、車両の大きさ（特大、大型、中型、普通、軽自など）を示す文字列又は数値とすればよい。また、編成車両数を組み合わせても良い。これは、交通データ４１１における車両種別９０９と対応可能なように構成する。

容量１０１２は、前述の車両種別で示された使用する車両の容量であって、乗車容量すなわち定員を示す数値とすればよい。これは、交通データ４１１における容量９１１と対応可能なように構成する。

個体識別子１０１３は、前述の車両種別で示された使用する車両の識別子であって、車両を一意に示すものであればいかなるものでも良い。例えば、個体識別子１０１３は、車両の登録番号、車載器のＩＤ、又は、系統番号もしくは系統コードと便番号との組み合わせなどの、数値又は文字列であってもよい。なお、個体識別子１０１３は、交通データ４１１における個体識別子９１２と対応可能なように構成する。

出発日１０１４は、利用者が前述の出発地から前述の目的地に出発する出発日を示す。例えば、出発日１０１４は、ＹＹＹＹ／ＭＭ／ＤＤ（Ｙは年、Ｍは月、Ｄは日を示す）形式の文字列、又は、ＹＹＹＹＭＭＤＤと固定の桁数の数値など、運行する年、月、日を識別できる形式であれば何でもよいが、前述の交通データ４１１における日９１３の形式と同じにすることが望ましい。

出発曜日１０１５は、上記日で示される出発日の曜日を示す。例えば、出発曜日１０１５は、曜日を示す文字列であってもよいし、月曜日を１、火曜日を２とするなど、曜日と対応した数値であってもよいが、前述の交通データ４１１における曜日９１４と対応可能なように構成する。

出発時刻１０１６は、前述した利用者ＩＤの利用者が、前述した起点を出発地を出発する予定時刻であり、特に、前述した移動レコメンドシステム１０１が計算した出発タイミングの時刻である。これは、例えば「：」で時と分が区切られた形式の文字列、又は、ＨＨＭＭ（Ｈは時、Ｍは分を示す）形式などの固定の桁数の数値など、対応する起点の出発予定時刻を識別できる形式であれば何でもよいが、交通データ４１１における時刻の形式と合わせることが望ましい。

経路特徴１０１７は、前述した区間起点及び前述した区間終点において前述した交通モードで移動する際の特徴であり、移動レコメンドシステム１０１が決定した経路の特徴である。これは、例えば、空いている経路、安い経路、早く行ける経路、乗継が少ないなどの楽な経路等の中から、対象者が良く選ぶ傾向にある経路を前述した移動レコメンドシステム１０１が決定した特徴であり、特徴を一意に判別できる数値又は文字列とすればよい。

選択予測１０１８は、前述した移動レコメンドシステム１０１が選択予測（ステップ７１０）にて予測した、レコメンド対象の利用者がこの目的地や経路を選択する確率などである。

なお、移動レコメンドシステム１０１が生成するレコメンド計画修正／実施結果についても図１０に示したものと同様のデータ構造とすることができる。

また、図１０の例では前述した区間起点１００５、区間終点１００６、交通モード１００７、リンク１００８、道路種別１００９、事業者１０１０、車両種別１０１１、容量１０１２、個体識別子１０１３、出発日１０１４、出発曜日１０１５を、運行計画のそれぞれの対応項目とは別に保有できるように構成したが、対応する運行計画データを参照できるように、当該運行計画データにおける対応行のインデックス及びＩＤなどで置き換えても良い。

上記のレコメンド計画データによって、運行調停システム１０２による運行計画の立案及びシミュレーションシステム１０３によるシミュレーションが可能となる。あるいは、シミュレーションシステム１０３において、レコメンド計画を反映したシミュレーションが可能となり、運行調停システム１０２において、シミュレーション結果を介して、レコメンド計画を反映した運行計画の立案が可能になる。また、逆に、シミュレーション及び運行計画に基づいて、移動レコメンドシステム１０１がレコメンド計画を立案することが可能となる。

＜交通利用者端末表示画面＞
図１１は、本発明の実施例の交通利用者端末２０２の表示画面の一例を示す説明図である。

交通利用者端末２０２の表示画面１１００は、レコメンドされた目的地１１０１、レコメンドされた経路、交通手段及びそれらがレコメンドされた理由（以下、単にレコメンドされた経路、交通手段及び理由とも記載する）１１０２、出発タイミング１１０３、レコメンドされた目的地のスクロールバー１１０４、レコメンドされた経路、交通手段及び理由のスクロールバー１１０５、採用ボタン１１０６、並びにキャンセルボタン１１０７を表示する。

レコメンドされた目的地１１０１の表示エリアには、移動レコメンドシステム１０１によるレコメンド計画修正／実施結果のうち、場所レコメンド対象が表示される。これはレコメンド計画データにおける目的地１００４を、利用者にわかりやすい形で地名又は画像などを取得して、それらを含むリスト形式などで表示しても良い。

このとき、先に示したレコメンド計画データ（図１０参照）にはレコメンド理由は格納されていないが、当該項目を格納するようにレコメンド計画データのデータ構造を拡張し、レコメンド理由が表示されるように構成しても良い。例えば、よく知られる協調フィルタ方式であれば、「〇〇に行った人はここにも行っています」といった理由を生成できる。あるいは、よく知られるコンテンツベースのレコメンドでは、「〇〇が好きな人はここがおすすめです」といった理由を生成できる。このため、「Ａスーパー： ○○が安いです」といった表示、又は、「Ｂ公園：○○に行った人はここも行っています」などの表示が可能となる。

また、個々のレコメンドされた目的地に対して、移動レコメンドシステム１０１が予測して、レコメンド計画データに格納されている選択予測結果（すなわち選択予測１０１８）を表示してもよいし、その選択予測結果が高い順に（すなわち、予測された選択されやすさの順に）レコメンドされた目的地を表示しても良い。

レコメンドされた目的地のスクロールバー１１０４は、上記レコメンドされた目的地が複数あり、表示エリアにすべてが表示しきれなかった場合に表示される。利用者がこのスクロールバー１１０４を操作することによって、レコメンドされた目的地すべてが表示される。あるいは、最近のスマートフォンのように指でスワイプするなどの方法でスクロールできる場合にはこのスクロールバー１１０４は省略してもよい。

レコメンドされた経路、交通手段及び理由１１０２の表示エリアには、移動レコメンドシステム１０１によるレコメンド計画修正／実施結果のうち、目的地に対応する経路レコメンド対象を表示する。これはレコメンド計画データにおける、目的地１００４に対応した計画ＩＤ１００２ごとの区間起点１００５と区間終点１００６のセット又はリンク１００８と、交通モード１００７及び事業者１０１０とを、利用者にわかりやすい文字列又は画像などを取得して、それらのリスト形式などで表示すると良い。

このとき、先に示したレコメンド計画データに格納されている経路特徴１０１７がレコメンド理由として表示されるように構成しても良い。これによって、例えば「空いている」、「安く行ける」、「早く行ける」、「乗継が少ない」などの理由を表示できる。また、個々のレコメンドされた経路に対して、移動レコメンドシステム１０１が予測して、レコメンド計画データに格納されている選択予測結果（すなわち選択予測１０１８）を表示してもよいし、その予測結果が高い順に（すなわち、予測された選択されやすさの順に）レコメンドされた経路を表示しても良い。また、先に示したレコメンド計画データ（図１０参照）にはステップ７０８で記載した立ち寄り地のレコメンド結果は格納されていないが、当該項目を格納するようにレコメンド計画データのデータ構造を拡張し、経路上の立ち寄り地のレコメンド結果が表示されるように構成しても良い。さらに、このとき、経路上の途中で混雑していることを表示し、経路が何時空くか判断した結果を表示しても良い。

レコメンドされた経路、交通手段及び理由のスクロールバー１１０５は、上記レコメンドされた経路や立寄り地が複数あり、表示エリアにすべてが表示しきれなかった場合に表示される。利用者がこのスクロールバーを操作することによって、レコメンドされた経路や立寄り地すべてが表示される。あるいは、最近のスマートフォンのように指でスワイプするなどの方法でスクロールできる場合にはこのスクロールバー１１０５は省略してもよい。

出発タイミング１１０３の表示エリアには、移動レコメンドシステム１０１によるレコメンド計画修正／実施結果のうち、計算された出発タイミングを表示する。これはレコメンド計画データにおける出発時刻１０１６、経路特徴１０１７、及び経路上の空く時刻を利用者にわかりやすい形で表示するとよい。例えば、「〇時〇分に出発すれば空いている」などと表示してもよいし、あるいは出発時刻と現在時刻を照らして「今出発すれば座っていける可能性が高い」などと表示してもよい。

採用ボタン１１０６は、上記のレコメンドされた目的地及び経路を利用者が選択して、これを採用する場合に操作するボタンである。これによって、計画を予約したり、これに基づいて予定を作ることが可能となる。また、既に公知の方法で必要な決済が行われるように構成しても良い。採用ボタン１１０６を操作することで、図１１に示した表示画面を終了するように構成しても良い。

キャンセルボタン１１０７は、上記のレコメンドされた目的地及び経路を消去し、表示画面を終了するためのボタンである。

これらの画面構成によって、移動レコメンドシステム１０１によるレコメンド計画修正／実施結果を利用者に提示し、利用者が目的地及び経路などを選択可能となる。なお、ここで選択された目的地や経路などは、レコメンド結果の選択実績として、前述したレコメンド選択予測に使われるように構成しても良い。

＜交通事業者運行計画システム表示画面＞
図１２は、本発明の実施例におけるある交通事業者の交通事業者運行計画システム２０３の表示画面の一例を示す説明図である。

交通事業者運行計画システム２０３の表示画面１２００には、タイムバー１２０１、改善要求ボタン１２０２、承認ボタン１２０３、ＫＰＩ表示エリア１２０４があるほか、交通事業者が運行する交通モードの経路及び運行状態が地図１２０５上に表示される。

タイムバー１２０１は、運行日の日付及び時刻が表示される他、例えばスライダーを動かすことによって、運行状態を表示する時刻を指定することができる。また、例えば、日付を指定することもできる。

改善要求ボタン１２０２は、運行の改善要求を運行調停システム１０２に対して行うためのボタンである。例えば、ユーザ（図１２に関しては、交通事業者運行計画システム２０３を使用する交通事業者等）が、何も指定せずに改善要求ボタン１２０２を操作した場合、交通事業者運行計画システム２０３は、表示されている交通事業者の全ての交通モード、路線、便及び区間を対象として（すなわちこれを条件として）、運行調停システム１０２に改善要求を発行する。

図中の×は、交通モードの運行区間における起点又は終点、例えばバス停又は駅などであり、太線は、交通モードの運行経路を示す。

図中の●は、例えば、タイムバー１２０１で示された時刻に交通モードの車両が走行している位置であり、丸の大きさは、例えば、走行位置での輸送人数又は乗車率を示している。これは、交通データ又はシミュレーション結果のデータにおける輸送人数又は乗車率に応じて、ある決められた比率で円の大きさを規定すればよい。また、円の色は、例えば、予定時刻からの遅延時間を示し、例えば、遅延時間の大きさによって、色を変化させればよい。これは、交通データ又はシミュレーション結果のデータにおける遅延時間に応じて色を変化させればよい。

なお、上記のようなシンボル（例えば●）の色及び形とそれによって表現される情報（輸送人数、遅延時間等）との関係は一例であり、これ以外の種々の対応付けが許容される。例えば、丸の大きさが遅延時間を、色が輸送人数を示してもよい。あるいは、遅延時間又は輸送人数を示す数字を丸の中に表示してもよいし、丸以外の形のシンボルを使用してその形と何らかの情報とを対応付けてもよい。

ＫＰＩ表示エリア１２０４には、交通事業者によって決められたＫＰＩとその値を例えばグラフなどで表示する。ＫＰＩは前述の通り例えば利用人数又は遅延時間などが考えられ、交通事業者によって異なっていてもよい。図１２には一例として利用人数をＫＰＩとして設定した場合を示している。なお、何をＫＰＩとするかは、事業者ごとにあらかじめ設定ファイルなどで設定しても良いし、表示画面から指定できるようにしても良い。なお、ＫＰＩは複数あっても良いし、優先順位が指定できても良い。

ＫＰＩ表示エリア１２０４には、何も指定しなければ、表示されている交通事業者の全ての交通モード、路線、便及び区間を対象として（すなわちこれを条件として）、ＫＰＩ値を計算した結果がグラフなどで表示される。

ここで、表示画面１２００は、ＫＰＩとＫＰＩ値の表示対象とする期間、交通モード、路線、便及び区間などを指定できるように構成しても良いし、ＫＰＩが複数ある場合には、改善対象とするＫＰＩを選択できるように構成しても良い。

例えば、ユーザが地図１２０５に現在表示されている●をタップすることで便を、×の間の線をタップすることで区間を、線全体を囲うことで路線及び交通モードを指定すると、指定された条件に合致するＫＰＩとＫＰＩ値が表示されるように表示画面１２００を構成しても良い。

また、表示されているＫＰＩをタップすることで改善対象とするＫＰＩを指定可能となるように表示画面１２００を構成しても良い。

また、図中の点線は、変更点を示す。図１２の例では点線で示した区間にシャトル路線を増やすことを指定した場合を示している。例えば、既存の経路を変更することによってそのような変更を実現することなどが考えられるが、このような変更を指定できるように表示画面１２００を構成しても良い。

この場合、図１２に示す通り、ＫＰＩとＫＰＩ値としては、現状（変更前）と変更後の両方を表示できるように表示画面１２００を構成しても良い。あるいは、運行調停システムによる運行の変更点を点線などで表示し、同様に変更前と変更後のＫＰＩとＫＰＩ値を表示できるように表示画面１２００を構成しても良い。

承認ボタン１２０３は、運行計画変更後の承認ボタンであり、これを操作することによって、現在表示されている（すなわち、上記のように運行計画が変更された場合には、変更後の）運行計画の決定を運行調停システム１０２に通知することができる。

図１２に示した表示画面１２００によって、交通事業者ごと、交通モードごと、路線ごと、便ごと、及び区間ごとのＫＰＩとＫＰＩ値を確認して、改善対象を指定して、運行調停システムに改善要求を発行することができる。また、運行計画変更後のＫＰＩとＫＰＩ値を確認して、運行計画を決定することができる。

＜交通事業者運行計画システム表示画面（別事業者の例）＞
図１３は、本発明の実施例における別の交通事業者の交通事業者運行計画システム２０３の表示画面の一例を示す説明図である。

図１３には、図１２に示したものとは別の交通事業者が管理する交通事業者運行計画システム２０３の表示画面１３００の例を示している。この例は、地図１３０１に示すように、南北と東西に走る２つの交通モードがあることを示している。

ＫＰＩ表示エリア１３０２に示すように、ＫＰＩとして、定時性（例えば遅延時間）、需給バランス（例えば乗車人数が定員数と等しい場合を０、定員以上であればプラスの数値を加算し、定員以下であればマイナスの数値を加算した値）及び乗車密度（例えば運行距離当たりの乗車人数）を表示した例を示している。

その他、基本的な表示内容及び操作方法は図１２で示した内容と同じである。

図１３の例は特に、交通事業者によって、当該交通事業者が運行する交通モードのみを表示することを例示している。

＜合意形成システム表示画面＞
図１４は、本発明の実施例の合意形成システム２０４の表示画面の一例を示す説明図である。

合意形成システム２０４では、対象地域で運行されている複数の交通モードを合わせて表示する。

図１４では、特に、図１２で示した交通事業者の交通モードと図１３で示した交通事業者の交通モードに関して表示した例である。

図１４に示す通り、合意形成システム２０４の表示画面１４００には、その地域で運行されている交通モードに対応する交通事業者運行計画システム２０３の表示をマージしたものが表示される。図１４の例では、図１２に示した地図１２０５上の表示と図１３に示した地図１３０１上の表示とをマージしたものが地図１４０１上に表示される。

その他の基本的な表示内容及び操作方法は図１２及び図１３で示した内容と同じである。

上記の合意形成システム２０４によって、ある地域における複数の交通モードの運行をそれぞれのＫＰＩ値が指定値を充足するように運行計画を立案することができ、複数の交通モードの運行を調停することができる。

すなわち、以上の実施例によれば、例えば既存の複数の交通モードに関しても、あるいはそこに新規交通モードが加わる場合であっても、全交通モードのＫＰＩ値が悪化しない、“ＡＬＬ ＷＩＮ”運行を実現できる。特に、交通利用者にとっては混雑がないあるいはスムースな移動といった利便性が得られるだけでなく、移動促進がなされるため、健康促進といったＱｏＬ向上の効果もある。また、交通事業者にとっては、ＭａａＳにおけるマルチモード交通の合意形成を図ることができ、サステナブルな運営が可能となる。さらに、地域及び周辺施設にとっては、観光促進及び購買促進がなされるといった経済効果も期待できる。

上記の本発明の実施例のシステムは、次のように構成されてもよい。

（１）演算部（例えば演算部３００、４００、５００の少なくともいずれか）と、記憶部（例えば記憶部３１０、４１０、５１０の少なくともいずれか）と、を有する交通運行計画システムであって、記憶部は、複数の交通機関の各々について指定された評価指標（例えばステップ６０１及び８０１におけるＫＰＩ）と、複数の交通機関の運行計画の作成条件（例えばステップ６０１、７０２及び８０２における条件）と、複数の交通機関の運行のシミュレーション条件（例えばイベント／広告情報５１３～移動情報５１７の少なくともいずれか又はそれらから抽出された情報）と、を保持し、演算部は、運行計画の作成条件に基づいて、複数の交通機関の運行計画を作成し（例えばステップ６０７及び８０３）、運行計画及びシミュレーション条件に基づいて、複数の交通機関の運行のシミュレーションを実行し（例えばステップ６０９及び８０４）、シミュレーションの結果に基づいて、複数の交通機関について指定された評価指標を計算し（例えばステップ８０５）、すべての評価指標が所定の基準を充足した場合、運行計画を出力し（例えばステップ８０６：Ｙｅｓ、ステップ８１０）、少なくともいずれかの評価指標が基準を充足しない場合、運行計画を変更する（例えばステップ８０６：Ｎｏ、ステップ８０３）。

これによって、例えば既存の複数の交通モードに関しても、あるいはそこに新規交通モードが加わる場合であっても、全交通モードの評価指標の値が悪化しない運行を実現できる。また、ＭａａＳにおけるマルチモード交通の合意形成を図ることができ、サステナブルな運営が可能となる。

（２）上記（１）において、演算部は、運行計画に基づいて、交通利用者に移動を推奨する推奨計画（例えばレコメンド計画）を作成し（例えばステップ８０６：Ｎｏ、ステップ８０８）、シミュレーション条件に、交通利用者の推奨計画に従う移動を追加した場合の、複数の交通機関の運行のシミュレーションを実行する（例えばステップ６１５、８０４）。

これによって、交通利用者にはスムースな移動といった利便性が得られ、移動促進によって健康促進といったＱｏＬ向上の効果もある。さらに、地域及び周辺施設にとっては、観光促進及び購買促進がなされるといった経済効果も期待できる。

（３）上記（２）において、演算部は、推奨計画に基づいて運行計画を変更し（例えばステップ６０７）、変更された運行計画に基づいて、複数の交通機関の運行のシミュレーションを実行する（例えばステップ６１５）、あるいは演算部は、推奨計画に基づいて複数の交通機関の運行のシミュレーションを実行し、運行計画を変更する。

これによって、推奨計画によるＫＰＩの向上を予測することができる。

（４）上記（３）において、演算部は、変更された運行計画に基づいて推奨計画を変更し（例えばステップ６２１）、変更された運行計画を出力する（例えばステップ６２２、７１１）。

これによって、運行計画が変更された場合にもそれが反映された適切な移動の推奨を行うことができる。

（５）上記（２）において、推奨計画は、交通利用者の移動の目的地、目的地までの経路、立ち寄り地及び出発時刻を含む（例えばステップ７０７～７０９）。

これによって、交通利用者の利便性が向上する。

（６）上記（２）において、演算部は、交通利用者の属性及び過去の行動の記録に基づいて推奨計画を作成する（例えばステップ６１２、７０７～７０９）。

これによって、交通利用者に採用されやすいレコメンドを生成して、ＫＰＩ及びＱｏＬの向上を図ることができる。

（７）上記（２）において、記憶部は、交通利用者が推奨計画に従って移動する確率（例えば選択予測１０１８）を保持し、演算部は、交通利用者の推奨計画に従う移動が確率に従って発生した場合の、複数の交通機関の運行のシミュレーションを実行する。

これによって、レコメンドによるＫＰＩの向上を適切に予測することができる。

（８）上記（７）において、交通利用者が推奨計画に従って移動する確率は、交通利用者が過去の推奨計画に従って移動したか否かの履歴に基づいて計算される。あるいは、交通利用者が提示された推奨計画を選択した履歴に基づいて計算される。

これによって、レコメンドによるＫＰＩの向上を適切に予測することができる。

（９）上記（１）において、記憶部は、複数の交通機関の各々について、変更する運行計画の項目の優先順位を示す情報を保持し、優先順位が高い項目から順に変更することによって、運行計画を変更する。

これによって、実行可能かつ適切な運行計画の変更を提案することができる。

（１０）上記（９）において、優先順位は、各交通機関の交通モードに応じて決定される。なお、当該優先順位は各交通機関の交通モード毎に指定されても良い。

これによって、交通モードの特性に応じて、実行可能かつ適切な運行計画の変更を提案することができる。

（１１）上記（１０）において、優先順位は、交通機関の交通モードに対して指定できる。

これによって、交通モードの特性に応じて、実行可能かつ適切な運行計画の変更を提案することができる。

（１２）上記（９）において、優先順位は、評価指標の改善対象の時期までの時間の長さに応じて決定される。

これによって、交通モードの特性及び時間的な制約に応じて、実行可能かつ適切な運行計画の変更を提案することができる。

（１３）上記（１）において、演算部は、複数の交通機関の各々について、変更する運行計画を交通モードの特性に応じた時間で終了させる。また、この終了時間を指定できる。これによって、リアルタイムに運行計画を立案すべき交通モードの運行計画を所定時間で立案できる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１０１ 移動レコメンドシステム
１０２ 運行調停システム
１０３ シミュレーションシステム
２０１ ネットワーク
２０２ 交通利用者端末
２０３ 交通事業者運行計画システム
２０４ 合意形成システム

Claims (15)

1. 演算部と、記憶部と、を有する交通運行計画システムであって、
   前記記憶部は、
   複数の交通機関の各々について指定された評価指標と、
   前記複数の交通機関の運行計画の作成条件と、
   前記複数の交通機関の運行のシミュレーション条件と、を保持し、
   前記演算部は、
   前記運行計画の作成条件に基づいて、前記複数の交通機関の運行計画を作成し、
   前記運行計画及び前記シミュレーション条件に基づいて、前記複数の交通機関の運行のシミュレーションを実行し、
   前記シミュレーションの結果に基づいて、前記複数の交通機関について指定された前記評価指標を計算し、
   すべての前記評価指標が所定の基準を充足した場合、前記運行計画を出力し、
   少なくともいずれかの前記評価指標が前記基準を充足しない場合、前記運行計画を変更することを特徴とする交通運行計画システム。
2. 請求項１に記載の交通運行計画システムであって、
   前記演算部は、
   前記運行計画に基づいて、交通利用者に移動を推奨する推奨計画を作成し、
   前記シミュレーション条件に、前記交通利用者の前記推奨計画に従う移動を追加した場合の、前記複数の交通機関の運行のシミュレーションを実行することを特徴とする交通運行計画システム。
3. 請求項２に記載の交通運行計画システムであって、
   前記演算部は、
   前記推奨計画に基づいて前記運行計画を変更し、
   前記変更された運行計画に基づいて、前記複数の交通機関の運行のシミュレーションを実行すること、あるいは、前記推奨計画に基づいて複数の交通機関の運行のシミュレーションを実行し、前記運行計画を変更することを特徴とする交通運行計画システム。
4. 請求項３に記載の交通運行計画システムであって、
   前記演算部は、
   前記変更された運行計画に基づいて前記推奨計画を変更し、
   前記変更された運行計画を出力することを特徴とする交通運行計画システム。
5. 請求項２に記載の交通運行計画システムであって、
   前記推奨計画は、前記交通利用者の移動の目的地、前記目的地までの経路、立ち寄り地及び出発時刻を含むことを特徴とする交通運行計画システム。
6. 請求項２に記載の交通運行計画システムであって、
   前記演算部は、前記交通利用者の属性及び過去の行動の記録に基づいて前記推奨計画を作成することを特徴とする交通運行計画システム。
7. 請求項２に記載の交通運行計画システムであって、
   前記記憶部は、前記交通利用者が前記推奨計画に従って移動する確率を保持し、
   前記演算部は、前記交通利用者の前記推奨計画に従う移動が前記確率に従って発生した場合の、前記複数の交通機関の運行のシミュレーションを実行することを特徴とする交通運行計画システム。
8. 請求項７に記載の交通運行計画システムであって、
   前記交通利用者が前記推奨計画に従って移動する確率は、前記交通利用者が過去の前記推奨計画に従って移動したか否かの履歴あるいは前記交通利用者が提示された前記推奨計画を選択した履歴に基づいて計算されることを特徴とする交通運行計画システム。
9. 請求項１に記載の交通運行計画システムであって、
   前記記憶部は、前記複数の交通機関の各々について、変更する前記運行計画の項目の優先順位を示す情報を保持し、
   前記優先順位が高い項目から順に変更することによって、前記運行計画を変更することを特徴とする交通運行計画システム。
10. 請求項９に記載の交通運行計画システムであって、
    前記優先順位は、前記各交通機関の交通モードに応じて決定されることを特徴とする交通運行計画システム。
11. 請求項１０に記載の交通運行計画システムであって、前記優先順位は、交通機関の交通モードに対して指定できることを特徴とする交通運行計画システム。
12. 請求項９に記載の交通運行計画システムであって、
    前記優先順位は、前記評価指標の改善対象の時期までの時間の長さに応じて決定されることを特徴とする交通運行計画システム。
13. 請求項１に記載の交通運行計画システムであって、
    前記演算部は、複数の交通機関の各々について、変更する運行計画を交通モードの特性に応じた時間で終了させることを特徴とする交通運行計画システム。
14. 請求項１３に記載の交通運行計画システムであって、
    前記交通モードの特性に応じた運行計画の変更終了時間を指定できることを特徴とする交通運行計画システム。
15. 演算部と、記憶部と、を有する計算機システムが実行する交通運行計画方法であって、
    前記記憶部は、
    複数の交通機関の各々について指定された評価指標と、
    前記複数の交通機関の運行計画の作成条件と、
    前記複数の交通機関の運行のシミュレーション条件と、を保持し、
    前記交通運行計画方法は、
    前記演算部が、前記運行計画の作成条件に基づいて、前記複数の交通機関の運行計画を作成する手順と、
    前記演算部が、前記運行計画及び前記シミュレーション条件に基づいて、前記複数の交通機関の運行のシミュレーションを実行する手順と、
    前記演算部が、前記シミュレーションの結果に基づいて、前記複数の交通機関について指定された前記評価指標を計算する手順と、
    前記演算部が、すべての前記評価指標が所定の基準を充足した場合、前記運行計画を出力する手順と、
    前記演算部が、少なくともいずれかの前記評価指標が前記基準を充足しない場合、前記運行計画を変更する手順と、を含むことを特徴とする交通運行計画方法。

Images