JP7404190B2 - オペレーション連携装置およびオペレーション連携支援方法 - Google Patents

Description

本発明は、複数の交通事業者が提供する交通手段のオペレーションの連携を支援するオペレーション連携装置およびオペレーション連携支援方法に関する。

持続可能な交通社会の将来像としてＭａａＳ（Mobility as a Service）が注目を集めている。ＭａａＳでは交通手段をモノとして提供するのではなく、サービスとして提供する。現状、鉄道、バス、タクシーのような交通機関はそれぞれの交通事業者により運行されており、ユーザは目的地、あるいは交通状況に応じて、経路を選択し、必要に応じて交通機関を予約し、利用した交通機関の交通事業者に対して個別に支払いを行う。ＭａａＳは、これら複数の交通機関をシームレスに利用することを可能とする。ＭａａＳアプリを利用することにより、ユーザは一括して経路検索、予約、支払いを済ませることができ、自分の好みに合った交通手段、移動パターンを選択することができる。ＭａａＳは、上述した交通機関、レンタカー、さらには近年急速に拡大しているシェアリングサービスなどの新たな交通サービスをも統合し、１つのモビリティサービスとしてユーザの移動を支援することが期待されている。

特許文献１には、混雑度の低い乗換ルートを一度複数検索することで、ユーザの希望に近い結果を表示、選択できるナビゲーション装置が開示されている。

特許文献２には、車両の運行効率と顧客満足度との両方を向上させるため、顧客のニーズにあわせて車両運行計画を策定すること、顧客数に基づいて車種を選択したり、車両を増発したりすることが可能な交通機関の運行システムが開示されている。

特開２０１３－１９７７４号公報 特開２００２－２６９６７１号公報

一言でＭａａＳといっても、そのモビリティサービスの統合の程度や提供する機能は多様である。例えば、ＭａａＳを５段階にレベル分けした定義例が知られている。それによれば、レベル０が統合なし（非ＭａａＳ）、レベル１が情報の統合、レベル２が予約・支払いの統合、レベル３が提供するサービスの統合、レベル４が社会全体目標の統合とされている。レベル４では、社会政策的な目的が強調され、交通施策を超えて都市全体の最適化を目指すものとなっている。

ＭａａＳが実効を上げるためには、交通事業者同士が情報やビジネス活動のさまざまな局面で協調し、統合していくことが求められることになるが、そのためには多大な統合コスト、意識変革が必要になる。一方で、そのような困難を乗り越えて新しいサービスを根付かせるには、交通手段の統合によって移動の利便性が目に見えて向上することが、交通事業者、交通利用者に実感できることが重要である。

発明者らは、交通事業者同士の統合や密な連携を前提とすることなく、ビッグデータを用いることによって、早期に地域の交通サービスを高品質化することを検討した。すなわち、ＭａａＳ以前においては、交通事業者はそれぞれ自己のオペレーションポリシーやＫＰＩにしたがってその交通機関を運営している。このような状況下において、本発明のオペレーション連携システムでは、旅客需要や複数の交通手段の運行状況を把握し、推定されるオペレーションポリシーに沿って調整したオペレーションを交通事業者に対して提案する。これにより、ＭａａＳのレベル４に相当する、地域での交通サービスの品質向上を先駆けて実現することを目的とする。

特許文献１では、利用者に複数の選択肢を提供するのみであって、交通事業者に対してオペレーションの変更を要求するものではない。特許文献２では、１交通事業者に閉じてオペレーションを変更するものであって、複数の交通事業者に対するオペレーションの連携を図るものではない。

本発明の一実施態様であるオペレーション連携装置は、第１の交通事業者を含む複数の交通事業者がそれぞれ異なる交通手段を提供している地域において、複数の交通事業者による交通手段のオペレーション連携を支援するオペレーション連携装置であって、
複数の交通事業者ごとに、交通事業者による交通手段のオペレーション履歴情報に基づき、そのオペレーションポリシーを推定するオペレーションポリシー推定部と、
第１の交通事業者の交通手段を利用する第１の移動需要が、第１の交通事業者の交通手段の第１の輸送可能人数を超えると予測されるとき、第１の輸送可能人数を超過する第１の移動需要を吸収するよう、複数の交通事業者ごとに推定したオペレーションポリシーに基づき、複数の交通事業者の交通手段のオペレーションを調整し、調整した交通手段のオペレーションを交通事業者に提案する交通手段調整部とを有する。

交通事業者同士の統合を前提とすることなく、地域全体での交通サービスの品質向上を実現する。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

オペレーション連携システムのブロック図である。 オペレーション連携装置の機能ブロック図である。 実施例１における交通状況を示す図である。 各交通手段のキャパシティを示す図である。 運行履歴データ１３１のデータ構造を示す図である。 増便傾向情報テーブル１３２のデータ構造を示す図である。 オペレーション連携調整フローのフローチャートである。 需要情報データ１１１のデータ構造を示す図である。 運行計画データ１２１ａのデータ構造を示す図である。 位置情報データ１２２のデータ構造を示す図である。 供給情報データ１２３のデータ構造を示す図である。 調整後供給情報データ１４１ａのデータ構造を示す図である。 調整後供給情報データ１４１ｂのデータ構造を示す図である。 調整後供給情報データ１４１ｃのデータ構造を示す図である。 交通事業者に配信されるレコメンド例である。 実施例２における交通状況を示す図である。 運行計画データ１２１ｂのデータ構造を示す図である。 運行実績データ１５１のデータ構造を示す図である。 回復ポリシー情報テーブル１５２のデータ構造である。

図１はオペレーション連携システムの全体像を示すブロック図である。以下では、交通事業者として、鉄道事業者Ａが鉄道路線を有し、バス事業者Ｂがバス路線を有し、タクシー事業者Ｃ，Ｄが営業している地域に対して、オペレーション連携支援を行う例を用いて本発明を説明する。オペレーション連携システムに参加する交通事業者に特に制約はないが、交通サービスを高品質化するターゲットの地域における交通事業者ができるだけ多数参加することが望ましい。

これらの交通事業者が保有する交通機関のオペレーションの連携を支援し、地域の交通サービスの品質を向上させるため、連携支援者はオペレーション連携装置１を設置する。ここでは、連携支援者は参加しているどの交通事業者とも利害関係をもつことなく、公開された情報を用いて連携支援を行うことを想定する。オペレーション連携装置１は、鉄道事業者Ａの鉄道計画装置２、バス事業者Ｂのバス計画装置３、タクシー事業者Ｃのタクシー配車装置４、タクシー事業者Ｄのタクシー配車装置５とネットワーク７ａを介して接続されている。詳細は後述するが、これら交通事業者の計画装置あるいは配車装置は、それぞれの交通事業者が保有する交通機関のオペレーション情報（計画と実績）を蓄積しており、これをオペレーション連携装置１に提供する。オペレーション連携装置１は、後述するように、これらの情報を用いて、交通機関のオペレーションの連携支援、具体的には地域の交通サービスを向上させるための、電車やバスの増発やタクシーの配車などの提案を行う。

また、オペレーション連携装置１はネットワーク７ｂを介して交通利用者の携帯装置６に接続される。携帯装置６は例えば、スマートフォンやタブレットである。オペレーション連携装置１は交通事業者に対してオペレーションの調整を提案し、提案が受け入れられたことを受けて交通利用者に対してオペレーションが調整されたことを通知する。交通利用者はこれを受けて経路を再検索するなどして、調整されたオペレーションに応じて移動行動を切り換える。この例ではオペレーション連携装置１が交通利用者に対して直接通知する形態を例示しているが、オペレーション連携装置１がナビケーションシステムの運用者に対して通知し、交通利用者が当該ナビゲーションシステムからオペレーションの調整を通知される形態であってもよい。直接的であれ、間接的であれ、最終的に交通利用者にオペレーションが調整された情報が伝達されればよい。

図２にオペレーション連携装置１の機能ブロック図を示す。オペレーション連携装置１のハードウェアは、ＨＤＤ（Hard disk drive）、ＳＳＤ（Solid State Drive）のような記憶装置を備える情報処理装置である。図２では、オペレーション連携装置１の実行する機能とその機能に対する入出力データを機能ブロック図で表現しており、その各機能は、ソフトウェアのプログラムコードをメインメモリに読み込み、プロセッサが読み込んだプログラムコードを実行することで実現される。情報処理装置がプログラムによって実現する機能を本実施例では「部」と称することがある。また、入出力データが大規模データである場合には、入出力データそのものをオペレーション連携装置１の記憶装置に保存する必要はなく、例えば、クラウド上のオブジェクトストレージに保存し、対象データにアクセスするためのデータパスを保存するのであってもよい。オペレーション連携装置１は１台のサーバにより実現されても、分散処理サーバにより実現されてもよく、ハードウェアの物理構成には限定されない。オペレーション連携装置１の備える各機能の詳細については後述する。

図３Ａ，Ｂにより実施例１におけるオペレーション連携を行う交通状況の例を説明する。実施例１では、図３Ａに示すように、鉄道路線の一部区間の利用希望者が急増し、オペレーション連携装置１は混雑が発生するであろう区間（混雑見込み区間、ここでは駅Ｓ２～駅Ｓ４）、の混雑を緩和するため、各交通事業者のオペレーションを調整する。図３Ｂに、交通手段ごとの１便（１台）あたりのキャパシティ（輸送可能人数）を示す。

オペレーション連携装置１は、混雑発生に対する過去の運行履歴より、各交通事業者の増便傾向をあらかじめ把握しておく。図４に運行履歴データ１３１のデータ構造を示す。運行履歴データ１３１は、あるエリア（本実施例では鉄道路線の区間によりエリアを定義する）において需要が輸送能力を超えた時間帯が生じたときに、実際に当該時間帯、当該区間において周辺交通手段を含めた運行状況（運行された便数、配車された台数）を記録したデータである。カラム４１は混雑が生じた区間を示す。ここでは駅Ｓ２～駅Ｓ４区間の例だけを示しているが、実際には運行履歴データ１３１の収集期間に生じた、すべての混雑区間が登録されている。カラム４２は当該混雑区間において混雑が生じた日付と時間帯を示す。カラム４３は当該混雑区間の当該日時に生じた需要人数、カラム４４～カラム４７はそれぞれ当該混雑区間の当該日時に実際に運行された便数、または実際に駅Ｓ２に配車された台数を示す。

オペレーション連携装置１の増便予測部２３は、この運行履歴データ１３１を用いて、各交通事業者の混雑へのオペレーションポリシーを示す情報として、混雑に対応した増便傾向を把握する。例えば、図４に示す運行履歴データ１３１からは、鉄道では少なくとも需要人数１０２０～１２００の範囲では増便しておらず、バスは需要人数１０２０～１０５０の範囲では増便していないが、需要人数１２００では１台増便されていることが分かる。このように、増便のしやすさは交通事業者によって違いがある。そこで、増便予測部２３は、運行履歴データ１３１から、混雑の生じた区間に対して増便する便数とその確率（増便傾向情報という）を算出した増便傾向情報テーブル１３２を作成する。なお、増便傾向情報テーブル１３２は同じ区間であっても、日付および／または時間帯を区別してテーブルを作成することが望ましい。増便傾向は、日付（例えば、平日であるか、休日であるか、等）や時間帯（例えば、通勤時間帯であるか、夜間であるか、等）によって異なると考えられるためである。また、需要人数を適宜区分してテーブルを作成してもよい。

図５に増便予測部２３が作成する増便傾向情報テーブル１３２のデータ構造を示す。カラム５１は交通事業者を示し、カラム５２は増便数を示し、カラム５３は増便による増強される輸送可能人数を示す。輸送可能人数５３は、増便数と図３Ｂに示した各交通手段のキャパシティとの積である。カラム５４は当該増便数が交通事業者によって実行される確率を示す。確率は、運行履歴データ１３１に記録された過去の運行履歴、配車履歴に基づいて算出される。

以上により、オペレーション連携装置１は、鉄道路線の一部に混雑が生じた場合への地域の交通事業者の増便対応傾向を把握することができる。なお、ここでは交通事業者の対応傾向を増便傾向情報テーブル１３２として保持する例を説明したが、これには限られない。増便傾向情報を機械学習によって求めてもよい。この場合、増便傾向情報を、増便傾向情報テーブル１３２に代えて、各交通事業者の増便パターンをクラスとする学習モデルとして保持することになる。

図６にオペレーション連携装置１が実行するオペレーション連携調整フローを示す。開始に先立ち、各交通事業者の運行ポリシーを把握する（Ｓ０１）。実施例１の場合、上述した、鉄道路線の一部に混雑が生じた場合への地域の交通事業者の増便対応傾向を把握することがステップＳ０１にあたる。すなわち、オペレーション連携装置１は、各交通事業者の増便傾向情報をテーブルあるいは学習モデルとして保持している。

最初に需要予測を行う（Ｓ０２）。需要予測はオペレーション連携装置１の需要予測部２１が実行する。オペレーション連携装置１は、地域に発生する移動需要を収集し、需要関連履歴データ１１０として蓄積している。需要予測部２１は需要関連履歴データ１１０を用いて、地域に発生する移動需要を予測し、需要情報データ１１１として格納する。需要予測部２１による移動需要の予測は、任意の公知の手法を用いて行うことができる。例えば、需要関連履歴データ１１０として、過去、地域に発生した移動履歴や交通利用者によるナビゲーションシステムによるルート検索履歴を蓄積しているとすれば、同じ曜日の同じ時間帯の過去の移動履歴から当時の移動需要の発生を予測し、当日のルート検索履歴からその予測を補正して需要情報データ１１１を得ることができる。

図７に需要情報データ１１１のデータ構造を示す。カラム６１は交通事業者を示し、カラム６２は時間帯を示し、カラム６３，６４は対象エリアを示し、カラム６５は需要予測部２１が予測した当該時間帯、当該対象エリアにおける移動需要（人数）、カラム６６は移動需要のうち、タクシーを使ってでも移動したい人の割合を示す。タクシーと鉄道のような公共交通機関とでは料金差が大きいため、混雑によって鉄道需要がすべてタクシー需要に移行するわけでないと考えられる。このため、緊急度６６を鉄道からタクシーに移行し得る需要の割合を示す指標として設けている。また、図７の例では、需要情報データ１１１の対象エリア６３，６４は鉄道区間を基準に、鉄道路線における乗車駅から降車駅によって定義されている。

続いて、供給予測を行う（Ｓ０３）。供給予測はオペレーション連携装置１の供給予測部２２が実行する。供給予測部２２は運行計画データ１２１ａまたは位置情報データ１２２を用いて、時間帯ごとの列車、バスの便数（供給量）、タクシーの台数（供給量）を予測し、供給情報データ１２３として格納する。運行計画データ１２１ａは鉄道計画装置２またはバス計画装置３から提供され、位置情報データ１２２はタクシー配車装置４，５から提供される。図８Ａは、運行計画データ１２１ａのデータ構造を示し、鉄道の運行スケジュールを示すものである。カラム７１が列車名、カラム７２が列車の種別、カラム７３は各駅への到着予定時刻を示す。図８Ｂは、位置情報データ１２２のデータ構造を示し、タクシーの配車計画を示すものである。カラム７５がタクシー事業者名、カラム７６は待機位置ごとの配車台数を示す。

供給予測部２２が作成する供給情報データ１２３のデータ構造を図９に示す。カラム８１は交通事業者を示し、カラム８２は時間帯を示し、カラム８３，８４は対象エリアを示し、カラム８５は供給予測部２２が予測した当該時間帯、当該対象エリアにおける供給量（便数または台数）を示し、カラム８６は当該時間帯、当該対象エリアにおいて各交通手段が輸送可能な人数を示す。輸送可能人数８６は、供給量８５と図３Ｂに示した各交通手段のキャパシティとの積である。

需要と供給それぞれの予測が終了すると、交通手段調整部２４は、両者を比較する（Ｓ０４）。図７に示される需要情報と図９に示される供給情報とを比較すると、バスとタクシーについては供給が需要を上回っているのに対し、鉄道については移動需要６５（1100人）が、輸送可能人数８６（1000人）を上回っているので、超過する需要を吸収するよう、供給量の調整を実施する（Ｓ０４でYES）。

交通手段調整部２４は、増便傾向情報テーブル１３２を用いて、確率５４の高い順に、増便する交通手段を割り当て、調整後供給情報データ１４１を作成する（Ｓ０５）。交通手段調整部２４が作成する調整後供給情報データ１４１ａのデータ構造を図１０Ａに示す。カラム９１は交通事業者を示し、カラム９２は調整前の供給量を示し、カラム９３は調整前の輸送人数を示し、カラム９４は増便数を示し、カラム９５は増便による輸送人数を示し、カラム９６は増便を含めたトータルの輸送人数合計、カラム９７は当該増便が実行される確率を示す。カラム９２～９３の情報は供給情報データ１２３から、カラム９７の情報は増便傾向情報テーブル１３２から得ることができる。図１０Ａの供給調整により、輸送人数合計は1120人となり、図７の需要情報を満たすため、各交通事業者に増便のリコメンドを配信する（Ｓ０８）。

これに対して、同じ例で鉄道についての移動需要６５が例えば1130人であったとすれば、図１０Ａの供給調整では輸送人数が不足している。輸送人数を上げるよう、確率を下げつつ、増便数を増加させて各交通手段に割り当てた例を図１０Ｂに示す。図１０Ｂの供給調整では、輸送人数合計は1165人となり、必要な輸送人数である1150人を超過する（なお、バスとタクシーの移動需要は図７の移動需要の通りとする）。すなわち、図１０Ｂの供給調整（Ｓ０５）では供給過多である（Ｓ０６でYES）であるので、割り当てた交通手段の増便数を調整する（Ｓ０７）。交通手段調整部２４が調整した例を図１０Ｃに示す。タクシーの増便数を減らすことによって、輸送人数合計は1150人となり、必要な輸送人数に調整されている。そこで、図１０Ｃの調整後供給情報に基づき、各交通事業者に増便のリコメンドを配信する（Ｓ０８）。

なお、交通手段調整部２４が求める調整後供給情報データ１４１は過不足なく需要情報データ１１１を満たす必要はない。調整前の供給情報データ１２３の示す輸送可能人数よりも供給量が改善されている限り、増便のレコメンドを配信する。

図１１にステップＳ０８でオペレーション連携装置１がオペレーションの調整を提案する交通事業者に配信するレコメンド例を示す。このレコメンドは、増便を要請するすべての交通事業者に発行され、図１１はバス事業者Ｂに対する表示画面例である。レコメンド画面１００には、レコメンドの内容とその理由がバス事業者Ｂに対して表示されている。交通事業者は、このレコメンドを受け入れてオペレーションを調整するか、レコメンドを受け入れられないかの選択をレコメンド画面１００の増便可否ボタン１０１により、オペレーション連携装置１に回答する。車両が手配できない等の理由で交通事業者がレコメンドを受け入れられない場合（Ｓ０９でYES）には、増便拒否の回答が交通手段調整部２４に伝達され、再度ステップＳ０５に戻って増便する交通手段の再割り当てを行う。一方、レコメンドが受け入れられた場合には、配信部２７は、交通利用者に対して受け入れられた増便情報を配信する（Ｓ１０）。交通事業者側も、駅やバス停のサイネージ等に増便情報を表示し、交通利用者に増便情報を周知することが望ましい。

図１２により実施例２におけるオペレーション連携を行う交通状況の例を説明する。実施例２では、図１２に示すように、駅Ｓ２～駅Ｓ３間に不通区間が生じて運行を停止した後、復旧し、鉄道の運行を再開するものとする。そこで、混雑を緩和するよう、オペレーション連携装置１は列車の運行の再開に応じて、各交通事業者のオペレーションを調整する。また、実施例２では、鉄道区間には急行列車も運行されており、駅Ｓ１，Ｓ５が急行停車駅とする。

実施例２では、オペレーション連携装置１は、鉄道事業者Ａの復旧時の列車運行再開に対するオペレーションポリシーを示す情報として、その鉄道路線における列車運行の回復ポリシーを過去の運行実績よりあらかじめ把握しておく。図１４に運行実績データ１５１のデータ構造を示す。運行実績データ１５１は、実際に列車が運行されたスケジュールおよび乗車率等を蓄積したデータである。カラム１４１が列車名、カラム１４２が列車の種別、カラム１４３が運休、カラム１４４は各駅への実際の到着時刻と前停車駅から当該駅までの乗車率（括弧内の数字）とを示す。

図１４の運行実績データ１５１に対応する期間の運行計画データ１２１ｂを図１３に示す。回復ポリシー推定部２５は、運行実績データ１５１と運行計画データ１２１ｂとを比較することにより、鉄道事業者Ａの復旧時における列車運行回復ポリシーを推定する。例えば、払い戻しが必要となる優等列車の回復を優先する、あるいは不通により生じた混雑の解消を優先する、といったさまざまな回復ポリシーが考えられる。そこで、回復ポリシー推定部２５は、過去の復旧からの回復時における運行実績データ１５１に基づき、回復ポリシー情報テーブル１５２を作成する。

図１５に回復ポリシー推定部２５が作成する回復ポリシー情報テーブル１５２のデータ構造を示す。カラム１５３は回復ポリシーを示し、カラム１５４は当該回復ポリシーが鉄道事業者Ａによって採用される確率を示す。確率は、運行実績データ１５１に記録された過去の復旧時における遅延時間、混雑状況（乗車率）、遅延収束に要した時間などを特徴量として抽出し、それらの特徴量と実際に採用された運行回復時の運行スケジュールとに基づいて算出される。

以上により、オペレーション連携装置１は、鉄道事業者Ａが鉄道路線を復旧する場合の列車運行の回復ポリシーを推定することができる。なお、ここでは交通事業者の対応傾向を回復ポリシー情報テーブル１５２として保持する例を説明したが、これには限られない。回復ポリシー情報を機械学習によって求めてもよい。この場合、回復ポリシー情報を、回復ポリシー情報テーブル１５２に代えて、鉄道事業者Ａの回復ポリシーをクラスとする学習モデルとして保持することになる。

オペレーション連携装置１が実行するオペレーション連携調整フローは図６の通りであり、実施例１と重複する内容については省略し、ここでは、実施例２固有の内容について説明するものとする。開始に先立ち、各交通事業者の運行ポリシーを把握する（Ｓ０１）。実施例２の場合、上述した、鉄道路線を復旧する場合の回復ポリシーの推定がステップＳ０１に追加される。すなわち、実施例２では、オペレーション連携装置１は、鉄道事業者Ａの回復ポリシー情報をテーブルあるいは学習モデルとして保持している。

ステップＳ０３の供給予測においては、供給予測部２２は、運行計画データ１２１ｂそのものではなく、推定した復旧時の運行スケジュールに基づき、供給量を予測する。すなわち、供給予測部２２は、運行計画データ１２１ｂ、需要情報データ１１１及び回復ポリシー情報テーブル１５２から、鉄道事業者Ａが採用するであろう回復ポリシーを推定し、回復ポリシーに基づく復旧時の運行スケジュールを推定する。復旧時の運行スケジュールに対して供給量を予測する処理は、実施例１の場合と同様である。

また、それ以降の処理についても、実施例１と同様であるので、重複する説明は省略する。

以上、本発明を２つの実施例に基づき説明した。本発明は、実施例の記載に限定されるものではなく、様々な変形が可能である。例えば、実施例では主に鉄道路線を例にとって説明したが、バスであっても同様であり、あらかじめ定められた路線を所定のスケジュールで運行する交通手段全般に対して適用可能である。

１：オペレーション連携装置、２：鉄道計画装置、３：バス計画装置、４，５：タクシー配車装置、６：携帯装置、７：ネットワーク、２１：需要予測部、２２：供給予測部、２３：増便予測部、２４：交通手段調整部、２５：回復ポリシー推定部、２７：配信部、１００：レコメンド画面、１０１：増便可否ボタン、１１０：需要関連履歴データ、１１１：需要情報データ、１２１：運行計画データ、１２２：位置情報データ、１２３：供給情報データ、１３１：運行履歴データ、１３２：増便傾向情報テーブル、１４１：調整後供給情報データ、１５１：運行実績データ、１５２：回復ポリシー情報テーブル。

Claims (14)

1. 第１の交通事業者を含む複数の交通事業者がそれぞれ異なる交通手段を提供している地域において、複数の前記交通事業者による交通手段のオペレーション連携を支援するオペレーション連携装置であって、
   複数の前記交通事業者ごとに、前記交通事業者による交通手段のオペレーション履歴情報に基づき、そのオペレーションポリシーを推定するオペレーションポリシー推定部と、
   前記第１の交通事業者の交通手段を利用する第１の移動需要が、前記第１の交通事業者の交通手段の第１の輸送可能人数を超えると予測されるとき、前記第１の輸送可能人数を超過する前記第１の移動需要を吸収するよう、複数の前記交通事業者ごとに推定したオペレーションポリシーに基づき、複数の前記交通事業者の交通手段のオペレーションを調整し、調整した交通手段のオペレーションを当該交通事業者に提案する交通手段調整部とを有するオペレーション連携装置。
2. 請求項１において、
   前記交通手段調整部は、提案した交通手段のオペレーションが当該交通事業者に受け入れられなかったときは、複数の前記交通事業者ごとに推定したオペレーションポリシーに基づき、複数の前記交通事業者の交通手段のオペレーションを再調整し、再調整した交通手段のオペレーションを当該交通事業者に提案するオペレーション連携装置。
3. 請求項１において、
   前記提案した交通手段のオペレーションが当該交通事業者に受け入れられたとき、受け入れられた交通手段のオペレーションを交通利用者に配信する配信部をさらに有するオペレーション連携装置。
4. 請求項１において、
   前記オペレーションポリシー推定部が推定する前記交通事業者のオペレーションポリシーは、混雑発生に対する増便傾向であるオペレーション連携装置。
5. 請求項４において、
   前記オペレーションポリシー推定部は、前記地域における混雑の発生したエリア、前記混雑の発生した日時、前記混雑時における需要人数、当該エリア及び当該日時における複数の前記交通事業者の交通手段のオペレーション情報を含むオペレーション履歴データから、複数の前記交通事業者ごとの混雑に対応した増便傾向を示す増便傾向情報を生成するオペレーション連携装置。
6. 請求項５において、
   前記第１の交通事業者の交通手段は、あらかじめ定められた路線を所定のスケジュールで運行する交通手段であって、
   前記エリアは前記路線の区間により定義されているオペレーション連携装置。
7. 請求項５において、
   前記増便傾向情報を、複数の前記交通事業者ごとの増便数とその確率を示す増便傾向情報テーブルまたは複数の前記交通事業者の増便パターンをクラスとする学習モデルとして保持するオペレーション連携装置。
8. 請求項１において、
   前記第１の交通事業者の交通手段は、あらかじめ定められた路線を所定のスケジュールで運行する交通手段であって、
   前記オペレーションポリシー推定部が推定する前記交通事業者のオペレーションポリシーは、前記第１の交通事業者が運行を再開するときのオペレーションの回復ポリシーを含むオペレーション連携装置。
9. 請求項８において、
   前記オペレーションポリシー推定部は、前記第１の交通事業者による前記路線の復旧時における運行スケジュールと乗車率とを少なくとも含む運行実績データと前記運行実績データに対応する期間の運行計画データとに基づき、前記第１の交通事業者が運行を再開するときのオペレーションの回復ポリシー情報を生成するオペレーション連携装置。
10. 請求項９において、
    前記回復ポリシー情報を、前記第１の交通事業者が採用する回復ポリシーとその確率を示す回復ポリシー情報テーブルまたは前記第１の交通事業者の回復ポリシーをクラスとする学習モデルとして保持するオペレーション連携装置。
11. 請求項９において、
    複数の前記交通事業者の交通手段ごとの輸送可能人数を予測する供給予測部を有し、
    前記供給予測部は、前記路線の復旧時において、前記第１の交通事業者が運行を再開するときのオペレーションを前記回復ポリシー情報に基づき推定し、推定されたオペレーションに基づき、前記第１の交通事業者の交通手段の輸送可能人数を予測するオペレーション連携装置。
12. オペレーションポリシー推定部と交通手段調整部とを備えたオペレーション連携装置を用いて、第１の交通事業者を含む複数の交通事業者がそれぞれ異なる交通手段を提供している地域における複数の前記交通事業者による交通手段のオペレーション連携を支援するオペレーション連携支援方法であって、
    前記オペレーションポリシー推定部は、複数の前記交通事業者ごとに、前記交通事業者による交通手段のオペレーション履歴情報に基づき、そのオペレーションポリシーを推定し、
    前記交通手段調整部は、前記第１の交通事業者の交通手段を利用する第１の移動需要が、前記第１の交通事業者の交通手段の第１の輸送可能人数を超えると予測されるとき、前記第１の輸送可能人数を超過する前記第１の移動需要を吸収するよう、複数の前記交通事業者ごとに推定したオペレーションポリシーに基づき、複数の前記交通事業者の交通手段のオペレーションを調整し、調整した交通手段のオペレーションを当該交通事業者に提案するオペレーション連携支援方法。
13. 請求項１２において、
    前記オペレーションポリシー推定部が推定する前記交通事業者のオペレーションポリシーは、混雑発生に対する増便傾向であるオペレーション連携支援方法。
14. 請求項１２において、
    前記第１の交通事業者の交通手段は、あらかじめ定められた路線を所定のスケジュールで運行する交通手段であって、
    前記オペレーションポリシー推定部は、前記第１の交通事業者が運行を再開するときのオペレーションの回復ポリシーを推定するオペレーション連携支援方法。

Images