JP6726605B2 - 交通需給マッチングシステムおよび交通需給マッチング方法 - Google Patents

Description

本発明は、交通需給マッチングシステムおよび交通需給マッチング方法に関するものであり、具体的には、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断を容易なものとする技術に関する。

都市部など各地域には、公共交通機関である鉄道、バス、タクシー、また、個人交通機関であるマイカー、自転車など、様々な交通機関が存在する。また近年では、サイクルシェアやライドシェアなど、ユーザ間で自転車や自家用車を共通利用する新たなサービス等も登場してきている。

そのため、移動者が或る地域内を移動する場合、そうした複数の交通機関を乗り継いで移動するケースが多い。例えば、Ａ駅を出発地としてＢ展示場を目的地とした場合、Ａ駅からＣ鉄道に乗ってＤ駅まで向かい、Ｄ駅からＥ鉄道に乗り換えてＢ展示場の最寄り駅に至り、その駅から徒歩でＢ展示場に到着する、といった具合である。

こうした乗り継ぎ経路は、上述した様々な交通機関の存在により、複数経路を取り得ることも多い。例えば、上述したＡ駅からＢ展示場に向かう経路において、Ａ駅からＣ鉄道に乗ってＸ駅まで向かい、Ｘ駅からＥ鉄道に乗り換えてＢ展示場の最寄り駅に至り、その駅から徒歩でＢ展示場に到着する、といった別の経路である。この様に移動者が目的地に向かうには、多くの場合、複数の交通機関および複数の経路が存在することになる。

一方、各国で都市化が進展している現在、上述した複数経路の存在があっても都市部などでの渋滞、混雑は、世界共通の問題になりつつある。渋滞や混雑の原因の１つとしては、各移動者の移動需要と各交通機関の輸送供給力とが適切にマッチング出来ていないことが挙げられる。

例えば、Ａ駅からＢ展示場に向かうバスが足りず、Ａ駅付近のバス停に長蛇の列が発生するといった事態が起こりうる。そこで、各移動者の移動需要を予測した上で、適切な輸送供給力を提供していくことが必要となってくる。

こうした課題を解決する手段として、過去の輸送履歴（予約履歴）と運行履歴を用いる方法が存在する。例えば、オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、前記データベースに格納される前記運行実績から予め前記乗客の乗降に関する特性情報を抽出し、抽出した前記特性情報と抽出した前記特性情報に対応する前記運行実績に含まれる前記予約を示す情報とを対応付けて前記データベースに格納する手段と、運行スケジュールを決定する現在の状況が、前記特性情報が示す状況に整合するとき、整合した前記特性情報に対応する前記運行実績に含まれる前記予約情報に基づいて、前記オンデマンドバスの前記運行スケジュールを決定する手段とを設けることを特徴とするオンデマンドバスの運行スケジューリングシステム（特許文献１参照）などが提案されている。

特開２０１１−２２６４６号公報

しかしながら従来技術においては、特定事業者の交通機関に関する運行実績等のみを用いており、他事業者の交通機関における運行実績等もあわせて考慮することがない。例えば、上述したＡ駅からＢ展示場に至る例では、Ａ駅からバスに乗車する場合の移動需要を、或るＡ社のバスの運行履歴に基づき推測する一方で、Ｅ鉄道の運休に伴う移動需要の発生については考慮できない。

そうした状況下において、移動者らの移動需要に応えようと新たな（臨時の概念含む）運行経路を構想したとしても、その収益性が良好である根拠が無い限り、交通事業者が当該運行経路の開設を決断することは難しい。交通事業の公共性から、運行経路を一旦開設すると、移動需要が多少減少してもその運行を取りやめることが難しいという側面もある故である。

そこで本発明の目的は、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断を容易なものとする技術を提供することにある。

上記課題を解決する本発明の交通需給マッチングシステムは、所定地域における移動需要および輸送供給力の各情報を格納した記憶装置と、前記移動需要および前記輸送供給力の各情報に基づき、前記地域において混雑する混雑交通機関および混雑経路を推定し、前記混雑経路を回避する回避経路と、前記地域にて未運行ながら前記回避経路で運行されるべき仮の交通機関とを所定アルゴリズムで推定し、前記回避経路および前記仮の交通機関の各情報を所定装置に出力する演算装置と、を備えることを特徴とする。

また、本発明の交通需給マッチング方法は、所定地域における移動需要および輸送供給力の各情報を格納した記憶装置を備える情報処理システムが、前記移動需要および前記輸送供給力の各情報に基づき、前記地域において混雑する混雑交通機関および混雑経路を推定し、前記混雑経路を回避する回避経路と、前記地域にて未運行ながら前記回避経路で運行されるべき仮の交通機関とを所定アルゴリズムで推定し、前記回避経路および前記仮の交通機関の各情報を所定装置に出力する、ことを特徴とする。

本発明によれば、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が容易なものとなる。

本実施形態の交通需給マッチングシステムを含むネットワーク構成例を示す図である。 本実施形態の交通需給マッチングシステムのハードウェア構成例を示す図である。 本実施形態における移動需要案に関するデータ構造例を示す図である。 本実施形態における交通機関の輸送供給案に関するデータ構造例を示す図である。 本実施形態における移動需要のデータ構造例を示す図である。 本実施形態における輸送供給のデータ構造例を示す図である。 本実施形態における移動需要履歴に関するデータ構造例を示す図である。 本実施形態における移動者特性を示すデータ構造例を示す図である。 本実施形態における事業者特性を示すデータ構造例を示す図である。 本実施形態の交通需給マッチング方法のフロー例１を示す図である。 本実施形態の交通需給マッチング方法のフロー例２を示す図である。 本実施形態の交通需給マッチング方法のフロー例３を示す図である。 本実施形態における画面例１を示す図である。 本実施形態における画面例２を示す図である。 本実施形態における画面例３を示す図である。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の交通需給マッチングシステム１０を含むネットワーク構成図であり、図２は交通需給マッチングシステムのハードウェア構成例を示す図である。

図１に示す交通需給マッチングシステム１０は、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断を容易なものとするコンピュータシステムである。

本実施形態の交通需給マッチングシステム１０は、移動者の操作する移動者端末１１（例：スマートフォン、ＰＣ等）や、交通機関を運行する事業者（以下、交通事業者）の事業者システム１２と、ネットワーク１を介して通信可能に接続されている。

こうした交通需給マッチングシステム１０のハードウェア構成は以下の如くとなる。本実施形態の交通需給マッチングシステム１０は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３１、メモリ２０３１または記憶装置２０１１に保持されるプログラム２０２１を実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４１、ユーザからのキー入力や音声入力を受け付ける入力装置２０５１、処理データの表示を行うディスプレイ等の表示装置２０６１、ネットワーク１と接続し他装置との通信処理を担う通信装置２０７１、を備える。

なお、記憶装置２０１１内には、本実施形態の交通需給マッチングシステム１０として必要な機能を実装する為のプログラム２０２１に加えて、移動者特性６０、事業者特性７０、移動需要案２０、輸送供給案３０、移動需要４０、輸送供給４２、移動需要履歴５０の各データが少なくとも記憶されている。

交通需給マッチングシステム１０の演算装置２０４１は、例えば記憶装置２０１１のプログラム２０２１を実行することで、メモリ２０３１において、交通需給推定部１０１、臨時交通募集部１０２、仮交通通知部１０３、臨時交通確定部１０４、公共交通状況取得部１０５、道路交通状況取得部１０６、および、移動需要取得部１０７といった各機能部を実装する。

このうち公共交通状況取得部１０５は、鉄道、バス等の公共交通機関の運行計画、運行状況を取得する処理部である。こうした運行計画、運行状況はネットワーク１を経由して、各交通事業者の事業者システム１２ないし適宜な情報提供システム等から取得するものとする。

公共交通状況取得部１０５が得る運行計画は、交通事業者による計画時のダイヤを示しており、これにより各交通事業者事業者の路線網の繋がり、輸送時刻等を知ることが出来る。また、運行状況は、交通事業者による各ダイヤの実行状況を示しており、例えば遅延している場合は、計画より遅れたダイヤとして取得することが出来る。

また、道路交通状況取得部１０６は、道路交通の交通流の状況を取得する処理部である。この道路交通状況取得部１０６が得る情報は、道路と道路との繋がりと、道路の輸送量を示している。なお、道路交通状況取得部１０６は、ネットワーク１を経由して外部のシステムから各道路の輸送量を把握しても良い。

また、移動需要取得部１０７は、移動需要の状況を取得する処理部である。この移動需要取得部１０７が得る情報は、各移動者の移動者端末１１から得られる移動需要であり、これらの情報によれば、どの時間帯にどの経路にいくつの移動需要があるのかを把握することが出来る。なお、こうした移動需要取得部１０７における処理に代えて、ネットワーク１を経由して外部の所定システムから移動需要の情報を取得するとしても良い。

また、交通需給推定部１０１は、上述の公共交通状況取得部１０５、道路交通状況取得部１０６、および移動需要取得部１０７の各処理内容、および移動需要履歴５０に基づき、現時点での移動需要に対する輸送供給力の対応状況を算出し、移動需要に対して輸送供給力が不足している交通機関、経路を推定する処理部である。

また、臨時交通募集部１０２は、上述の交通需給推定部１０１の処理結果に基づき、混雑回避のため必要となる臨時の交通機関を交通事業者に募集する処理部である。また本処理部では、上述の募集に対する各交通事業者からの応諾内容を保持し、事業者特性情報に基づき好適な交通機関を決定し、仮の交通機関とする処理部である。

また、仮交通通知部は１０３は、上述の臨時交通募集部１０２によって決定された仮の交通機関について、各異動者および各交通事業者に通知する処理部である。本処理部ではさらに、仮の交通機関の運行実現時に利用する意思の有無情報を各移動者から集め、実利用者数の推定も実施する。

また、臨時交通確定部１０４は、上述の実利用者数の推定結果と、交通事業者の事業者特性とを照らし合わせ、仮の交通機関の実施を判定する。仮の交通機関の実施を確定させた場合、該当移動者および該当交通事業者に確定の旨を通知する。

また、移動者端末１１における移動者情報授受部１１１は、当該移動者端末１１の操作者たる移動者に対し、経路検索の結果や仮の交通機関の提示等を実施する端末である。また移動者端末１１は、交通需給マッチングシステム１０から提示された仮の交通機関に関して、実際に運行された場合の利用意思を回答するためのインタフェースを備えている。

また、移動案内部１１２は、上述の経路検索等で検索した経路について移動者への経路案内を行う機能部である。例えば乗換え時の移動方向を示し、または目標の交通機関に乗るためのタイムリミットなどを提示する。

また、事業者システム１２における状況提示部１２１は、交通需給マッチングシステム１０の臨時交通募集部１０２で算出した臨時交通の募集状況を示す機能部である。臨時交通は複数提示される場合もあり、交通事業者にて好適な臨時交通を１つ以上選択することが出来る。

また、事業者システム１２における臨時交通判断部１２２は、交通需給マッチングシステム１０からの臨時交通の提案に対し、交通事業者における提供可否を判定する機能部である。本処理部は輸送計画部１２３と接続されており、臨時交通の提案を実施可能か判断するために輸送計画の変更計算を実施する。臨時交通判断部１２２は、輸送計画物量から変更が可能（スケジュールとして可能）な情報が挙がってきた場合、交通事業者として運
行の応諾可能な条件を付与し、仮交通通知部１０３に返答を返す。

−−−データ構成例−−−
図３は、本実施形態における移動需要案２０のデータ構造例を示す図である。本実施形態の移動需要案２０は、各移動者のそれぞれの移動需要案を示している。この場合、移動者は複数の移動需要を持っており、各移動需要について複数の経路案を持ち、それぞれの経路案は、１つ以上の交通機関によって実現されている。

移動者２０１、移動需要２０２、経路２０３の各カラムは、それぞれの識別子のカラムを示しており、本例ではこれら３つのカラムからなる複合キーとなっている。交通機関のカラム２０４は、経路２０３を移動する際の交通機関、発着２０５のカラムは出発地点と到着地点、すなわちどこからどこまでを移動するかを示し、時間帯２０６のカラムはその発着を実施したい時間帯を示している。

また、運賃幅のカラム２２１は、移動需要２０２に対応する経路２０３の交通機関２０４に関して、当該移動者２０１が払っても良い運賃幅を示している。また確定のカラム２２２は、移動者端末１１の移動者情報授受部１１１において選択対象となった経路（後述する図１２の画面でＹｅｓと回答した経路）を示すものである。また候補のカラム２２３は、仮の交通機関の運行が決定した場合に所定の通知を要求する移動者（後述する図１３で「実現出来たら通知」にチェックが入っている移動者）を示す。

図４は、本実施形態における各交通機関の輸送供給案３０のデータ構造例を示す図である。この輸送供給案３０において、交通機関およびリソースの各カラムは、各交通機関で、供給可能なリソースを特定するためのカラムであり、交通機関、リソースで特定する複合キーとなっている。

ここでリソースとは、例えばバス事業者におけるバス車両と乗務員を合わせたものであって、これにより臨時交通を実現する最小単位を表している。

また、時間帯のカラムは、リソース提供可能時間帯を示している。また、経路のカラムは、上述のリソースを提供する経路を指す。また、「確定」のカラムはリソース提供が確定したことを示し、「仮」のカラムは仮の交通機関としてリソースを仮確保していることを示している。

図５Ａは、本実施形態における移動需要のデータ構造例を示す図であり、また、図５Ｂは、本実施形態における輸送供給のデータ構造例を示す図である。図３の移動需要案２０と同様に、移動需要４０は、各移動者のそれぞれの移動需要を示している。ここで、当該移動需要４０における移動需要案２０との違いは、１つの移動需要に関して１つの経路が確定している点にある。また、確定した経路に対応する交通機関（対応交通機関）と対応するリソース（対応リソース）の割当が示されている点にある。また、輸送供給４２は、図４の輸送供給案３０と同様に、交通機関の輸送供給に関するデータ構造を示したものである。

図６は、本実施形態における移動需要履歴５０のデータ構造例を示す図である。本実施形態の移動需要履歴５０は、基本的には図５で示した移動需要４０と同様のデータ構成であるが、「年月日」のカラムが追加され、過去の移動需要であることが分かるようになっている。

図７は、本実施形態における移動者特性６０のデータ構造例を示す図である。本実施形態の移動者特性６０は、各移動者が移動に関して重視する各項目の優先度を示すテーブル
であり、移動者を特定する移動者カラムと、上述の各項目である、時間効用、混雑効用、運賃効用、乗換効用、買物効用、および支払意思の各カラムから構成されている。本実施形態の移動者特性６０では、効用を上述の５つとしているが、この他の効用を追加するとしてもよい。

なお、本実施形態の移動者特性６０では、上述の各効用の優先度は移動需要や経路によって左右されないとした場合の例を示しているが、移動需要や経路によって異なるケースを想定するとしてもよい。その場合、例えば図３の移動需要案２０にて移動者特性のカラムを追加し、１レコードごとに移動者特性を設定する構成を採用すればよい。

上述の項目たる時間効用、混雑効用、運賃効用、乗換効用、および買物効用の値は、各効用間での優先度、すなわち効用全体における割合を示している。例えば、時間効用が「０．６」の場合、全効用中で時間の重要性は６割を占めていることを表している。この割合をもって、移動者の効用は以下の式１で求める。

効用のうち支払意思は、移動者が交通機関に支払ってもよいと考える金額を示している。本例ではｋｍと時間あたりで正規化し、長距離や長い時間乗る場合にはより多くの金額を支払っても良い、という前提で設定しており、仮の交通機関に乗る場合に、その仮の交通機関の延長、および所要時間に応じた額を払うことを想定している。なお、本例では時間と道のりで正規化しているが、時間が短い程高く払う、という支払意思にしても良い。

図８は、本実施形態における事業者特性７０のデータ構造例を示す図である。本実施形態の事業者特性７０は、交通事業者を示す交通機関、当該交通事業者が交通機関の運行に必要な最低乗車率および最低運賃、当該交通事業者が交通機関の運行に希望する希望乗車率、希望運賃、および運行の希望時間帯の各カラムで構成されている。

−−−フロー例１−−−
以下、本実施形態における交通需給マッチング方法の実際手順について図に基づき説明する。以下で説明する交通需給マッチング方法に対応する各種動作は、交通需給マッチングシステム１０が実行するプログラム２０２１によって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図９は、本実施形態における交通需給マッチング方法のフロー例１を示す図である。ここではまず、交通需給マッチングシステム１０が、公共交通状況取得部１０５、道路交通状況取得部１０６、移動需要取得部１０７を実行して、それぞれ公共交通状況の取得（８０１）、道路交通状況の取得（８０２）、移動需要取得（８０３）を実施する。

続いて、交通需給マッチングシステム１０は、上述のステップ８０１〜８０３で得た、公共交通状況、道路交通状況、および移動需要を参照し、所定都市内における各経路の移
動需給の推定（８０４）を実施する。

この時、必ずしも全ての移動需要を把握出来ているとは限らず、移動需給の推定が難しくなる場合がある。こうした場合には、移動需要履歴５０と過去のそれぞれの交通機関の交通量を用いて、現時点で取得できている移動需要と類似の移動需要履歴５０の日、時間帯を特定し、それをもとに全体の移動需要を予測しても良い。例えば、「１１月の第二週の平日」という期間の朝７時〜８時に関して、今年は移動需要の情報を得られていないが、昨年の同期間、同時間帯に関して「１０００」という移動需要履歴を保持している場合、今年の移動需要を同じ「１０００」などと予測する。

交通需給マッチングシステム１０は、上述のステップ８０４における移動需要の推定結果と、各交通機関の輸送供給力とに基づき、移動需要と輸送供給力との間に関する需給比率を算出する。

例えば、ある鉄道の駅間に関する需給比率は、
（駅間の移動需要（人／時間））／（（運行頻度×当該列車の輸送人数（人））／駅間の所要時間（時間））
の式で算定できる。

例えば、ある交通事業者が運行するＡ鉄道のＸ駅からＹ駅の間の、１１月１０日の午前７時〜８時の時間帯に関して推定した移動需要が、「４０００人／時間」で、該当日の該当時間帯における該当区間の列車運行頻度が「１５」、また、当該列車の輸送人数が「５００人」、該当駅間の所要時間が「１時間」であったとする。この場合の需給比率は、（駅間の移動需要（人／時間））／（（運行頻度×当該列車の輸送人数（人））／駅間の所要時間（時間））＝４０００／（（１０×５００）／１）＝０．９、と算定出来る。

また同様に、上述のＡ鉄道のＹ駅からＺ駅の間の、該当日の該当時間帯に関して推定した移動需要が、「１００００人／時間」で、該当日の該当時間帯における該当区間の列車運行頻度が「１５」、また、当該列車の輸送人数が「５００人」、該当駅間の所要時間が「１時間」であったとする。この場合の需給比率は、（駅間の移動需要（人／時間））／（（運行頻度×当該列車の輸送人数（人））／駅間の所要時間（時間））＝１００００／（（１０×５００）／１）＝２．０、と算定出来る。つまり、このＹ駅からＺ駅の区間については、需要過多と特定出来る。

また、道路交通の場合の需給比率は、
（２点間の移動需要（人／時間））／（（運行頻度×提案リソースの輸送人数（人））／当該リソースの所要時間（時間））
で算定できる。

こうして算定した需給比率により、移動需給と輸送供給力とに関して需給の偏りがある交通機関や経路を特定することが出来る。

次に、交通需給マッチングシステム１０は、上述で算定した需給比率の中から、移動需要過多となっているものを特定する（８０５）。最後にこの過多分に対し、どの移動需要が該当するか、すなわち目的地を特定する（８０６）。上述の例であれば、Ｚ駅は移動需要過多の目的地と特定出来る。

−−−フロー例２−−−
図１０は、臨時交通の募集と仮の交通機関の決定・通知の処理フローを示した図である。この場合、交通需給マッチングシステム１０は、上述のステップ（８０６）にて取得し
た移動需要過多分のそれぞれの移動需要から、移動需要過多分の目的地を取得する（９０１）。 次に、交通需給マッチングシステム１０は、上述の移動需要過多分のＯＤ設定を行う（９０２）。ＯＤとは、人や物などの流れにおける起点 (Origin) と終点 (Destination) であり、ＯＤ設定とは、移動需要過多の目的地を終点とし当該移動需要の出発地と
した経路探索の設定を行うことを意味する。

続いて、交通需給マッチングシステム１０は、上述のＯＤ設定を満足する、交通機関および経路の探索を、各種交通機関の乗り換えやルート検索を行う所定の経路探索アルゴリズム等（プログラム２０２１として予め保持するか、或いは外部装置に問い合わせて利用するとしてもよい）を用いて行う（９０３）。

交通需給マッチングシステム１０は、上述の９０３における探索の際、現状存在する鉄道などの交通機関でなく、道路を自動車で移動するという結果になった経路を、現状では対応する交通機関が存在しない経路と特定する（９０４）。例えば、上述のＸ駅を起点としＺ駅を終点とした場合に、Ｙ駅からＺ駅の間を結ぶ所定道路Ｋをバスで移動する経路を特定したとする。

次に、交通需給マッチングシステム１０は、上述の９０４で特定した経路に関して、各交通事業者の事業者システム１２に向け、臨時交通の募集通知を送信する（９０５）。この募集通知は、少なくとも該当経路に関する情報と当該経路に関して仮の交通機関の運行を応諾する可否、および応諾する場合の条件（応諾条件）に関して回答を受けるインタフェースとを含む。上述の例であれば、Ｙ駅からＺ駅の間を結ぶ所定道路Ｋについて、現在運行が無いバスの運行を募集する通知内容と、その運行の応諾可否を受け付けるラジオボタン等の適宜なインターフェイス、および、応諾する場合の条件（例：図８に例示した、最低乗車率、最低運賃等の項目に対応したもの）を入力する入力インターフェイスを含むことになる。

一方、交通事業者の事業者システム１２では、上述の募集通知を受信し、状況提示部１２１によって適宜な表示装置に表示させる。当該交通事業者の所定担当者は、この募集通知を閲覧し、募集通知が示す臨時交通の運行を応諾する場合の条件、すなわち応諾条件を検討する。事業者システム１２は、その検討の結果を入力装置で受け付けて、上述の募集通知に対する回答として交通需給マッチングシステム１０に返信することとなる。

例えば、この回答は、上述の例であれば、Ｙ駅からＺ駅の間を結ぶ所定道路Ｋについて、現在運行が無いバスの運行を応諾する旨の回答と、その場合の応諾条件たる「最低乗車率が達成されること」といった情報を含むことになる。

続いて、交通需給マッチングシステム１０は、上述の回答を受信し（９０６）、この回答を送信してきた各交通事業者に関して事業者特性７０を参照し、上述の回答が示す各交通事業者の応諾条件に適合している交通事業者（図８では交通機関）を特定し、当該交通事業者によって運行される可能性のある臨時交通を、仮の交通機関と決定する（９０７）。例えば、所定の日時にＤバス会社によって道路Ｋの経路で運行される可能性のあるバス、を仮の交通機関、などと決定する。

この処理に際し、交通需給マッチングシステム１０は、図５の輸送供給４２のテーブルにおいて、仮の交通機関に該当する交通機関（鉄道事業者やバス会社）およびリソース（バスや鉄道など）のレコードの「仮」欄に、仮登録されたことを示す所定フラグを設定する。

−−−フロー例３−−−
図１１は、仮の交通機関の通知と確定の処理フローを示した図である。この場合、交通需給マッチングシステム１０は、上述のステップ（９０７）で決定した仮の交通機関における経路をキーに移動需要４０を参照し、各移動者のうち移動需要における経路が仮の交通機関の経路と一致する（或いは仮の交通機関の経路に含まれる）者を特定し、当該移動者の移動者端末１１に対し、移動需要を満たす仮の交通機関の存在に関する通知を送信する（１００１）。

一方、上述の通知を受けた移動者端末１１は、移動者情報授受部１１１により、仮の交通機関の情報と、該当経路に関して所定の経路探索アルゴリズムで得ている既存の交通機関の情報とを表示装置にて表示する。

図１２にて、上述の移動者端末１１で表示される画面１３００の例を示している。この画面１３００では、仮の交通機関等の情報を提示すると共に、仮の交通機関の利用意思を移動者から受け付ける。この図１２の例では、移動需要として当該移動者から既に得ている経路、すなわち既存の交通機関を組み合わせた実ルート検索結果１２０１と、仮の交通機関による経路である仮ルート検索結果１２０２をあわせて表示している。

また、この画面１３００では、それぞれの仮ルート検索結果、すなわち仮の交通機関について利用意思を受け付ける、「実現できたら通知」ボタン１２０３を備えている。画面１３００を閲覧した移動者は、好みの仮ルート検索結果１２０２について「実現できたら通知」ボタン１２０３をクリックすることで、該当する仮の交通機関が実現された場合に利用する意思がある旨をセンター側に伝えられる。移動者端末１１は、当該画面１３００の「実現できたら通知」ボタン１２０３がクリックされた場合、当該仮の交通機関の利用意思の登録要求として、通知登録要求を交通需給マッチングシステム１０に通知する。

他方、交通需給マッチングシステム１０は、各移動者端末１１から上述の登録要求を受信し（１００２）、当該仮の交通機関に関する登録要求の数を集計する（１００３）。

ここで交通需給マッチングシステム１０は、例えば、上述のステップ（１００１）からの経過時間が、予め定めた規定時間に到達しているか判定する（１００５）。

上述の判定の結果、上述のステップ（１００１）からの経過時間が、予め定めた規定時間に到達していた場合（１００５：Ｙｅｓ）、交通需給マッチングシステム１０は、上述のフロー例２のステップ（９０７）と同様の処理を実行して、他の交通事業者を探索する（１００８）。

この探索の結果、他の交通事業者を特定出来た場合（１００８：Ｙｅｓ）、交通需給マッチングシステム１０は、当該他の交通事業者に関する処理を行うべく、処理を上述のステップ（１００１）に戻す。他方、この探索で他の交通事業者を特定出来なかった場合（１００８：Ｎｏ）、交通需給マッチングシステム１０は、仮の交通機関は不実施と確定し（１００９）、その旨を移動者端末１１および該当交通事業者の事業者システム１２に通知する（１０１０）。

他方、上述のステップ（１００５）の結果、上述のステップ（１００１）からの経過時間が、予め定めた規定時間に到達していなかった場合（１００５：Ｎｏ）、交通需給マッチングシステム１０は、ステップ（１００３）で集計した通知登録数が、所定の希望基準に到達したか判定する（１００６）。つまり、当該仮の交通機関の運行に関して、数多くの移動者から支持を得られたか判定するのである。

上述の判定の結果、集計した通知登録数が、所定の希望基準に到達しなかった場合（１
００６：Ｎｏ）、交通需給マッチングシステム１０は、処理を上述のステップ（１００８）に遷移させる。

他方、上述の判定の結果、集計した通知登録数が、所定の希望基準に到達した場合（１００６：Ｙｅｓ）、交通需給マッチングシステム１０は、当該仮の交通機関の実運行が確定したと判定し（１００７）、その旨を移動者端末１１、事業者システム１２に通知する（１０１０）。

上述のステップ（１０１０）の結果、移動者端末１１の移動者情報授受部１１１が該当通知を受信し、仮の交通機関に関して集計された通知登録数の状態を表示する画面１２００について、図１３にて示す。なお、交通需給マッチングシステム１０が、上述のステップ（１００３）を定期的に行い、その処理結果として、当該画面１２００を移動者端末１１および該当交通事業者の事業者システム１２に通知するとしても好適である。

本例では、移動者が、出発地のＡ地点から、仮の交通機関と既存の公共交通とを乗り継いで目的地のＥ地点に向かう例を示している。この場合、Ａ地点１１０１からＣ地点１１０２の間の交通機関は仮の交通機関たるバスである旨と、その発時刻１１０４と着時刻１１０５、および、当該バスを運行予定の交通事業者における希望料金１１１１の各情報を示している。さらに、この仮の交通機関に対する移動者から得ている支持の状態を示すテキスト表示１１１０および円グラフ１１０９も含んでいる。この円グラフ１１０９は、例えば事業者特性情報を使い例えば以下の式で円グラフの割合を表すことが出来る。

（（現時点での移動需要の候補数／当該車両の定員×１００−最低乗車率））／（（希望乗車率−最低乗車率））
こうして、仮の交通機関の運行が実現されうる状況について各移動者に通知することが出来るため、より多くの移動者を仮の交通機関に関して獲得することが期待できる。また、仮の交通機関に関して、実現する前段階にて、移動者からの支持が十分でなく十分な採算が確保出来ないであろう状況を交通事業者に提示することも可能となり、無用な事業リスクを的確に回避する機会を交通事業者に与えることが出来る。

図１４は、上述のステップ（１０１０）の結果、移動者端末１１の移動者情報授受部１１１にて表示される、仮の交通機関の確定お知らせ画面１４００の一例である。この画面１４００では、仮の交通機関たる仮ルートとして実際に成立したルートと、その所要時間と料金の各情報（１３０１）を含む。また、確定した仮の交通機関にルート変更を行うか問い合わせる表示も含んでいる。その際の比較・参考のための、現在採用している実ルート１３０２（すなわち既存の交通機関によるルート）の表示も含む。また、ルート変更可否のＹＥＳ，Ｎｏボタン１３０３も備えている。このボタン１３０３のクリック結果は、交通需給マッチングシステム１０に送られ、移動需要履歴５０として蓄えられ、将来の移動需要推定に用いられることとなる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、所定の地域における複数の移動需要と複数の交通機関とを踏まえた移動需給のマッチングを行い、その需給関係の齟齬に対処する仮の交通機関（運行経路）を移動者および交通事業者に提案することが可能である。またこの場合、当該仮の交通機関の利用意思に関する移動者の反応を確認し、そうした仮の交通機関を提供する交通事業者に対し、当該交通機関の収益性見込や事業リスク回避の判断材料を提供することも出来る。

すなわち、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が容易なものとなる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の交通需給マッチングシステムにおいて、前記演算装置は、前記混雑経路の各移動者の端末に対し、前記回避経路および前記仮の交通機関に関する利用欲求有無の確認要求を通知し、該当移動者において利用欲求が有る旨の回答を前記端末から得るごとに、各移動者からの利用欲求の多さに応じた、前記回避経路および前記仮の交通機関の実現可能性を示す所定値をインクリメントし、当該所定値に関する情報を、前記移動者の端末および前記仮の交通機関を運行予定の事業者の端末の少なくともいずれかに通知する処理を更に実行するものである、としてもよい。

これによれば、仮の交通機関の利用を望む者の数を明確にし、この状況を移動者や交通機関の事業者に認識させることが可能である。仮の交通機関の利用を望む者の数は、該当交通機関を運行した場合の売上見込に直接的に影響する情報であり、ひいては、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチングシステムにおいて、前記演算装置は、前記混雑経路の各移動者の端末に対し、前記回避経路および前記仮の交通機関に関する利用欲求有無の確認要求を通知するに際し、前記各移動者による経路検索要求に応じて特定した前記混雑交通機関および前記混雑経路を少なくとも含む既存の交通機関および経路の情報と、前記回避経路および前記仮の交通機関の情報と、前記利用欲求有無の入力インターフェイスとを送信するものである、としてもよい。

これによれば、各移動者において、その移動経路の混雑状況を踏まえると共に、その混雑を回避出来る仮の交通機関についても認識出来ることとなり、当該仮の交通機関の利用意義をより明確かつ簡便に確認することが可能である。ひいては、仮の交通機関の利用を望む移動者の意思を、より迅速かつ精度良く特定し、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチングシステムにおいて、前記演算装置は、前記実現可能性を示す所定値と所定基準とを比較し、前記所定基準の達成度に応じた情報を、前記移動者の端末および前記仮の交通機関の事業者の端末の少なくともいずれかに通知する処理を更に実行するものである、としてもよい。

これによれば、仮の交通機関の利用を望む者の規模をより明確にし、この状況を移動者や交通機関の事業者に認識させることが可能である。ひいては、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチングシステムにおいて、前記演算装置は、前記実現可能性を示す所定値が前記所定基準を達成した場合、前記回避経路および前記仮の交通機関が前記事業者によって実現されると判定し、前記回避経路および前記仮の交通機関の実現について、前記移動者の端末および前記仮の交通機関の運行予定者の端末の少なくともいずれかに通知する処理を更に実行するものである、としてもよい。

これによれば、仮の交通機関の運行開始を事業者に確実に指示し、その利用を望む移動者に対して当該仮の交通機関の運行が開始される旨を迅速、簡便に通知することが可能と
なる。ひいては、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチングシステムにおいて、前記記憶装置は、各移動者が移動に関して重視する項目を示す移動者特性の情報と、各交通機関の事業者が当該交通機関の運行に関して重視する項目を示す事業者特性の情報と、を更に保持するものであり、前記演算装置は、前記回避経路と前記仮の交通機関とを推定するに際し、前記混雑経路の各移動者に関する前記移動者特性の情報と、前記混雑経路を回避する回避経路で運行されるべき前記仮の交通機関の事業者に関する前記事業者特性の情報とに基づき、前記移動者特性と前記事業者特性とが整合する仮の交通機関を特定するものである、としてもよい。

これによれば、移動のための時間や運賃、乗り換えの容易さ、混雑度合い、などといった移動者が重視する項目とマッチした仮の交通機関を特定し、これを移動者や事業者に認識させることが可能である。こうした移動者のニーズにマッチする仮の交通機関の利用を望む者の数は、該当交通機関を運行した場合の売上見込に直接的に影響する情報であり、ひいては、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチングシステムにおいて、前記演算装置は、前記整合する仮の交通機関を特定するに際し、前記事業者特性の情報のうち仮の交通機関の運行時間帯および運賃に関する許容範囲の情報にも基づいて、前記移動者特性と前記事業者特性とが整合する仮の交通機関を特定するものである、としてもよい。

これによれば、事業者が、運行コストや運行管理の面で許容出来る仮の交通機関を特定することが可能であり、ひいては、複数の交通機関および移動経路が存在する地域に関して、移動需要に対応しうる新たな交通機関の運行開始可否の判断が更に容易なものとなる。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記混雑経路の各移動者の端末に対し、前記回避経路および前記仮の交通機関に関する利用欲求有無の確認要求を通知し、該当移動者において利用欲求が有る旨の回答を前記端末から得るごとに、各移動者からの利用欲求の多さに応じた、前記回避経路および前記仮の交通機関の実現可能性を示す所定値をインクリメントし、当該所定値に関する情報を、前記移動者の端末および前記仮の交通機関を運行予定の事業者の端末の少なくともいずれかに通知する処理を更に実行する、としてもよい。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記混雑経路の各移動者の端末に対し、前記回避経路および前記仮の交通機関に関する利用欲求有無の確認要求を通知するに際し、前記各移動者による経路検索要求に応じて特定した前記混雑交通機関および前記混雑経路を少なくとも含む既存の交通機関および経路の情報と、前記回避経路および前記仮の交通機関の情報と、前記利用欲求有無の入力インターフェイスとを送信する、としてもよい。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記実現可能性を示す所定値と所定基準とを比較し、前記所定基準の達成度に応じた情報を、前記移動者の端末および前記仮の交通機関の事業者の端末の少なくともいずれかに通知する処理を更に実行する、としてもよい。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記
実現可能性を示す所定値が前記所定基準を達成した場合、前記回避経路および前記仮の交通機関が前記事業者によって実現されると判定し、前記回避経路および前記仮の交通機関の実現について、前記移動者の端末および前記仮の交通機関の運行予定者の端末の少なくともいずれかに通知する処理を更に実行する、としてもよい。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記記憶装置において、各移動者が移動に関して重視する項目を示す移動者特性の情報と、各交通機関の事業者が当該交通機関の運行に関して重視する項目を示す事業者特性の情報と、を更に保持し、前記回避経路と前記仮の交通機関とを推定するに際し、前記混雑経路の各移動者に関する前記移動者特性の情報と、前記混雑経路を回避する回避経路で運行されるべき前記仮の交通機関の事業者に関する前記事業者特性の情報とに基づき、前記移動者特性と前記事業者特性とが整合する仮の交通機関を特定する、としてもよい。

また、本実施形態の交通需給マッチング方法において、前記情報処理システムが、前記整合する仮の交通機関を特定するに際し、前記事業者特性の情報のうち仮の交通機関の運行時間帯および運賃に関する許容範囲の情報にも基づいて、前記移動者特性と前記事業者特性とが整合する仮の交通機関を特定する、としてもよい。

１ ネットワーク
１０ 交通需給マッチングシステム
１１ 移動者端末
１２ 事業者システム
２０ 移動需要案
３０ 輸送供給案
４０ 移動需要
４２ 輸送供給
５０ 移動需要履歴
６０ 移動者特性
７０ 事業者特性
１０１ 交通需給推定部
１０２ 臨時交通募集部
１０３ 仮交通通知部
１０４ 臨時交通確定部
１０５ 公共交通状況取得部
１０６ 道路交通状況取得部
１０７ 移動需要取得部
１１１ 移動者情報授受部
１１２ 移動案内部
１２１ 状況提示部
１２２ 臨時交通判断部
１２３ 輸送計画部
１３００ 画面
１４００ 画面
２０１１ 記憶装置
２０２１ プログラム
２０３１ メモリ
２０４１ 演算装置
２０５１ 入力装置
２０６１ 表示装置
２０７１ 通信装置

Claims (12)

1. 所定地域における移動需要および輸送供給力の各情報を格納した記憶装置と、
   前記地域における混雑経路が混雑しているかを前記移動需要および前記輸送供給力の各情報に基づき推定し、混雑している前記混雑経路の交通機関車両である混雑経路交通機関車両を前記移動需要および前記輸送供給力の各情報に基づき特定し、
   前記混雑経路を回避する回避経路と、前記地域にて前記回避経路で運行可能な仮の交通機関車両とを所定アルゴリズムで推定し、前記回避経路および前記仮の交通機関車両の各情報を所定装置に出力する演算装置と、
   を備え、
   前記演算装置は、
   前記混雑経路の各移動者のうち前記移動需要における経路が前記仮の交通機関の回避経路と一致し又は前記仮の交通機関の回避経路に含まれる移動者の端末に対し、前記回避経路および前記仮の交通機関車両に関する利用欲求有無の確認要求を通知し、該当移動者において利用欲求が有る旨の回答を前記端末から得るごとに、各移動者からの利用欲求の多さに基づき、前記回避経路および前記仮の交通機関車両の実現可能性を示す所定値をインクリメントし、当該所定値に関する情報を、前記移動者の端末および前記仮の交通機関車両を運行予定の事業者の端末の少なくともいずれかに通知する処理を更に実行するものである、
   ことを特徴とする交通需給マッチングシステム。
2. 前記演算装置は、
   前記移動者の端末に対し、前記回避経路および前記仮の交通機関車両に関する利用欲求有無の確認要求を通知するに際し、前記各移動者による経路検索要求に応じて特定した前記混雑経路交通機関車両および前記混雑経路を少なくとも含む既存の交通機関車両および経路の情報と、前記回避経路および前記仮の交通機関車両の情報と、前記利用欲求有無の入力インターフェイスとを送信するものである、
   ことを特徴とする請求項１に記載の交通需給マッチングシステム。
3. 前記演算装置は、
   前記実現可能性を示す所定値と所定基準とを比較し、前記所定基準の達成度に応じた情報を、前記移動者の端末および前記仮の交通機関車両の事業者の端末の少なくともいずれかに通知する処理を更に実行するものである、
   ことを特徴とする請求項１に記載の交通需給マッチングシステム。
4. 前記演算装置は、
   前記実現可能性を示す所定値が前記所定基準を達成した場合、前記回避経路および前記仮の交通機関車両が前記事業者によって実現されると判定し、前記回避経路および前記仮の交通機関車両の実現について、前記移動者の端末および前記仮の交通機関車両の運行予定者の端末の少なくともいずれかに通知する処理を更に実行するものである、
   ことを特徴とする請求項３に記載の交通需給マッチングシステム。
5. 前記記憶装置は、
   各移動者が移動に関して重視する項目を示す移動者特性の情報と、各交通機関車両の事業者が当該交通機関車両の運行に関して重視する項目を示す事業者特性の情報と、を更に保持するものであり、
   前記演算装置は、
   前記回避経路と前記仮の交通機関車両とを推定するに際し、前記混雑経路の各移動者に関する前記移動者特性の情報と、前記混雑経路を回避する回避経路で運行されるべき前記仮の交通機関車両の事業者に関する前記事業者特性の情報とに基づき、前記移動者特性と前記事業者特性とが整合する仮の交通機関車両を特定するものである、
   ことを特徴とする請求項１に記載の交通需給マッチングシステム。
6. 前記演算装置は、
   前記整合する仮の交通機関車両を特定するに際し、前記事業者特性の情報のうち仮の交通機関車両の運行時間帯および運賃に関する許容範囲の情報にも基づいて、前記移動者特性と前記事業者特性とが整合する仮の交通機関車両を特定するものである、
   ことを特徴とする請求項５に記載の交通需給マッチングシステム。
7. 所定地域における移動需要および輸送供給力の各情報を格納した記憶装置を備える情報処理システムが、
   前記地域における混雑経路が混雑しているかを推定し、混雑している前記混雑経路の交通機関車両である混雑経路交通機関車両を前記移動需要および前記輸送供給力の各情報に基づき特定し、
   前記混雑経路を回避する回避経路と、前記地域にて前記回避経路で運行可能な仮の交通機関車両とを所定アルゴリズムで推定し、前記回避経路および前記仮の交通機関車両の各情報を所定装置に出力し、
   前記混雑経路の各移動者のうち前記移動需要における経路が前記仮の交通機関の回避経路と一致し又は前記仮の交通機関の回避経路に含まれる移動者の端末に対し、前記回避経路および前記仮の交通機関車両に関する利用欲求有無の確認要求を通知し、該当移動者において利用欲求が有る旨の回答を前記端末から得るごとに、各移動者からの利用欲求の多さに基づき、前記回避経路および前記仮の交通機関車両の実現可能性を示す所定値をインクリメントし、当該所定値に関する情報を、前記移動者の端末および前記仮の交通機関車両を運行予定の事業者の端末の少なくともいずれかに通知する処理を更に実行する、
   ことを特徴とする交通需給マッチング方法。
8. 前記情報処理システムが、
   前記移動者の端末に対し、前記回避経路および前記仮の交通機関車両に関する利用欲求有無の確認要求を通知するに際し、前記各移動者による経路検索要求に応じて特定した前記混雑経路交通機関車両および前記混雑経路を少なくとも含む既存の交通機関車両および経路の情報と、前記回避経路および前記仮の交通機関車両の情報と、前記利用欲求有無の入力インターフェイスとを送信する、
   ことを特徴とする請求項７に記載の交通需給マッチング方法。
9. 前記情報処理システムが、
   前記実現可能性を示す所定値と所定基準とを比較し、前記所定基準の達成度に応じた情報を、前記移動者の端末および前記仮の交通機関車両の事業者の端末の少なくともいずれかに通知する処理を更に実行する、
   ことを特徴とする請求項７に記載の交通需給マッチング方法。
10. 前記情報処理システムが、
    前記実現可能性を示す所定値が前記所定基準を達成した場合、前記回避経路および前記仮の交通機関車両が前記事業者によって実現されると判定し、前記回避経路および前記仮の交通機関車両の実現について、前記移動者の端末および前記仮の交通機関車両の運行予定者の端末の少なくともいずれかに通知する処理を更に実行する、
    ことを特徴とする請求項９に記載の交通需給マッチング方法。
11. 前記情報処理システムが、
    前記記憶装置において、各移動者が移動に関して重視する項目を示す移動者特性の情報と、各交通機関車両の事業者が当該交通機関車両の運行に関して重視する項目を示す事業者特性の情報と、を更に保持し、
    前記回避経路と前記仮の交通機関車両とを推定するに際し、前記混雑経路の各移動者に関する前記移動者特性の情報と、前記混雑経路を回避する回避経路で運行されるべき前記仮の交通機関車両の事業者に関する前記事業者特性の情報とに基づき、前記移動者特性と前記事業者特性とが整合する仮の交通機関車両を特定する、
    ことを特徴とする請求項７に記載の交通需給マッチング方法。
12. 前記情報処理システムが、
    前記整合する仮の交通機関車両を特定するに際し、前記事業者特性の情報のうち仮の交通機関車両の運行時間帯および運賃に関する許容範囲の情報にも基づいて、前記移動者特性と前記事業者特性とが整合する仮の交通機関車両を特定する、
    ことを特徴とする請求項１１に記載の交通需給マッチング方法。