JP7654991B2 - 情報処理装置 - Google Patents

Description

本発明は、デマンド交通における利用状況を導出するための技術に関する。

特許文献１は、利用者の要求に対応して車両を運行するデマンド交通を運用するデマンド交通運用システムが開示されている。このデマンド交通運用システムは、希望出発時刻および希望到着時刻と、出発地および目的地とを含む乗客の旅客要求を受信し、集約した旅客要求をもとにデマンド交通車両の配車計画を作成する。

国際公開第２０１９／１０６７４５号

デマンド交通において交通リソースを適切に提供するため、デマンド交通の利用状況を精度良く算出できると好ましい。

本発明の目的は、デマンド交通の利用状況を精度良く算出する技術を提供することにある。

上記課題を解決するために、本発明のある態様の情報処理装置は、ユーザのリクエストに応じて運行するデマンド交通の利用情報を取得する取得部と、取得された利用情報にもとづいてデマンド交通の利用分布を導出する導出部と、導出部により導出された利用分布から運行の偏りを抽出する抽出部と、利用情報と運行の偏りとから、運行の偏りを低減する複数の手段を優先順位が高い順に出力する出力部と、を備える。取得された利用情報には、ユーザがデマンド交通の利用を申し込んだリクエスト情報と、リクエスト情報の成立および不成立を示す情報とが含まれる。複数の手段は、所定の時間帯および所定の場所で運行する車両の台数の変更、所定の時間帯および所定の場所でスポット的に定期運行する車両の追加、所定の経路を回遊する車両の追加、停留所の場所変更および停留所の増減のうちいずれか複数を含む。

本発明によれば、デマンド交通の利用状況を精度良く算出する技術を提供できる。

デマンド交通での配車を要求するユーザのリクエストと、そのリクエストに応じた運行ルートについて説明するための図である。 実施例の情報処理システムの機能構成を示す図である。 情報処理装置によるデマンド交通の利用状況を分析する処理のフローチャートである。

図１は、デマンド交通での運行を要求するユーザのリクエストと、そのリクエストに応じた運行ルートについて説明するための図である。デマンド交通では、ユーザからのリクエストに応じて車両を配車してユーザやユーザの荷物を搬送する。配車された車両には、バスのようにユーザ同士が乗り合うことも可能である。

ユーザのリクエストは、運行日の前日や運行時間の所定時間前などの所定の受付期限まで受け付けられる。デマンド交通では、ユーザのリクエストに全て応えて運行することが望ましいが、配車可能な車両には限りがあるため、ユーザのリクエストの内容によっては、リクエストを不成立にすることがある。ユーザのリクエストは、運行決定装置によって所定の受付期限まで集められ、成立させるか不成立にするか決定される。運行決定装置は、予め設定されたルールに沿ってユーザのリクエストを成立させ、成立させたリクエストに対応する運行計画を作成する。

ユーザのリクエストには、出発地、目的地、日時が定められる。図１には、ユーザのリクエストが示されており、第１リクエストは、出発地Ａ、目的地ａｂｃであり、第２リクエストは、出発地Ｂ、目的地ａｂｃであり、第３リクエストは、出発地Ｃ、目的地ａｂｃであり、第４リクエストは、出発地Ｄ、目的地ｄであり、第５リクエストは、出発地Ｅ、目的地ｅであり、第６リクエストは、出発地Ｆ、目的地ｆである。これらのリクエストは同じ時間帯の出発を希望しているものとする。出発地Ａから出発地Ｄは同じである。また、出発地Ａから出発地Ｃのリクエストは同じ目的地ａｂｃである。

運行決定装置がユーザのリクエストを多く成立しようと判定するため、出発地や目的地が重複しているリクエストを成立させやすい。また、リクエストに示す出発地および目的地が、他のユーザのリクエストと比べて、離れているほどリクエストが不成立になりやすい。そのため、第１リクエストから第３リクエストは、出発地および目的地が同じであるため、成立される。また、第５リクエストの出発地Ｅは、第１リクエストから第３リクエストに示す目的地ａｂｃに近いため、成立される。第１リクエストから第３リクエストおよび第５リクエストに対して、運行経路４０が設定される。

一方で、第４リクエストの目的地ｄは、第１リクエスト等の目的地ａｂｃから離れているため、第４リクエストには運行経路４２が設定される。第１リクエスト等に運行する車両とは別の車両が運行できなければ、第４リクエストは不成立となる。また、第６リクエストは、第１リクエストから第５リクエストと比べて、出発地も目的地も離れているため、第４リクエストよりも不成立になりやすい。このように、ユーザのリクエストは、他のリクエストとの関係で不成立になることがある。

出発地Ａから出発地Ｄや目的地ｅには駅があり、多くのリクエストが集まっている。リクエストが集中する場所から外れたリクエストや、リクエストが集中した後の時間帯はデマンド交通を利用しづらい結果になる。一部のユーザが利用しづらい状況は解消することが望ましい。そこで実施例の情報処理システムは、一部のユーザが利用しづらい状況を解消するための方法を見出すため、利用分布の偏りを導出し、偏りを低減する交通リソースの提供を見出す。例えば、デマンド交通の利用分布の偏りに示すリクエストが集中しているところには、多くの車両を投入するなどの対策ができる。また、利用分布の偏りは中長期的に変化し得るため、変化に合わせて車両の投入台数などを調整することが好ましい。

なお、デマンド交通における出発地および目的地は、予め設定された停留所の位置情報であってよく、緯度または経度で示す位置情報であってよい。つまり、デマンド交通の車両は、予め設定された停留所間の移動をするものであってよく、ユーザが希望する任意の位置に移動するものであってよい。リクエストに示す日時は、出発の日にちおよび時間帯を指定するものであってよい。

図２は、実施例の情報処理システム１の機能構成を示す。図２において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

情報処理システム１は、情報処理装置１０、運行決定装置１２およびユーザ端末装置１４を備える。ユーザ端末装置１４は、ユーザ毎に保持される携帯端末装置であってよく、車両の運行を申し込むためのアプリケーションプログラムを保持している。ユーザ端末装置１４は、アプリケーションプログラムを実行して、運行のリクエストをすることができ、運行決定装置１２にリクエスト情報を送信し、運行決定装置１２からリクエストの成立または不成立を示す応答情報を受け取る。また、ユーザ端末装置１４は、リクエスト情報を送信する際に、ユーザＩＤを付して送信する。

リクエスト情報には、出発地情報、目的地情報および日時情報が含まれる。出発地情報および目的地情報は、例えば、緯度および経度で示す位置情報であってよく、予め設定された停留所の位置情報であってよい。日時情報は、希望の出発時間を示すもので、日にちと時間帯であってよい。

運行決定装置１２は、通信部３２、運行決定部３４および車両情報保持部３６を有する。通信部３２は、運行決定装置１２およびユーザ端末装置１４と通信可能である。通信部３２は、ユーザ端末装置１４からリクエスト情報を受信し、リクエスト情報に対する応答情報をユーザ端末装置１４に送信する。

車両情報保持部３６は、ユーザのリクエストに応えて運行する車両の運行車両情報を保持する。運行車両情報は、車両ＩＤ、車両の乗員数、車両の位置情報などを含む。

運行決定部３４は、複数のユーザからリクエスト情報を受け付けて、運行車両情報をもとに、リクエスト情報を成立するか不成立にするか決定する。運行決定部３４は、リクエストを成立または不成立と判定するための判定プログラムを有する。判定プログラムは、例えば、リクエスト情報から優先順位を導出するロジックを有しており、導出した優先順位をもとに成立または不成立の判定結果を導出する。多くのリクエストを成立するため、判定プログラムは、出発地および目的地の近いリクエストを成立しやすい。判定プログラムは、ニューラルネットワークの手法を用いたものであってよく、運行車両情報および複数のリクエスト情報を入力すれば、各リクエストの成立または不成立を導出可能であってよい。

運行決定部３４は、リクエスト情報と、そのリクエスト情報に対する成立および不成立を示す応答情報と、を関連付けて利用情報として運行決定装置１２に記憶させる。このデマンド交通の利用情報は、通信部３２を介して情報処理装置１０に送信される。

運行決定部３４の運行の決定によって、車両の運行計画が作成される。運行計画には、車両の移動経路と、出発地および目的地に到着する目標時刻とが含まれる。運行計画は、例えば、車両の運転事業者のサーバ装置に送信され、運行計画に従って車両が走行される。なお、運行決定装置１２は、ユーザＩＤおよびそのユーザのプロファイル情報を保持してよい。

情報処理装置１０は、通信部２０、取得部２２、導出部２４、抽出部２６、推定部２８および出力部３０を備える。通信部２０は、運行決定装置１２からデマンド交通の利用情報を受信し、取得部２２は、デマンド交通の利用情報を取得する。利用情報には、デマンド交通の利用を申し込んだリクエスト情報と、そのリクエスト情報に対する成立および不成立を示す応答情報とが含まれる。また、利用情報には、リクエスト情報を出したユーザのプロファイル情報が含まれてもよい。

導出部２４は、取得された利用情報にもとづいてデマンド交通の利用分布を導出する。出発地および目的地が緯度および経度で示す位置情報である場合、所定範囲毎に区分したエリア毎の利用分布が導出され、出発地および目的地が停留所である場合、停留所毎に利用分布が導出される。

導出部２４は、時間帯毎に、出発地のリクエスト受付数、目的地のリクエスト受付数、目的地のリクエスト成立数、目的地のリクエスト成立数、出発地のリクエスト不成立数、目的地のリクエスト不成立数を利用分布として導出する。また、導出部２４は、時間帯および場所毎のリクエストの受付頻度、リクエストの不成立頻度を導出してもよく、停留所毎の時間当たりの利用頻度を導出してよい。また、導出部２４は、リクエストに対する車両の運行距離を導出してよく、各リクエストの運行距離を合計した総運行距離を導出してよい。このように、導出部２４は、デマンド交通の利用分布として、時間帯毎、停留所または所定のエリア毎にリクエストの受付数、成立数、不成立数、リクエストの不成立頻度、総運行距離などを導出する。導出部２４によって導出される利用分布には、リクエスト不成立の情報が含まれるため、ユーザの需要が精度良く表されている。

抽出部２６は、導出部２４により導出された利用分布から運行の偏りを抽出する。抽出部２６は、運行の偏りとして、所定数以上にリクエスト受付数が集中している時間帯および場所や、リクエスト不成立の頻度が所定頻度以上に高い時間帯および場所を抽出する。例えば、ある時間帯の停留所の利用頻度が所定頻度以上であれば、その時間帯の停留所に偏りが発生していると抽出される。抽出部２６は、運行の偏りとして、リクエストが集中する時間帯および場所や、リクエストの拒否が集中する時間帯および場所を抽出する。また、抽出部２６は、運行の偏りとして、車両の走行距離を基準にして、車両の走行距離の偏り、つまり長距離需要を導出してもよい。抽出部２６は、ニューラルネットワークの手法を用いたプログラムであってよく、利用分布を入力して、運行の偏りがある時間帯および場所を抽出してもよい。

ユーザのリクエストが不成立となった情報を用いることで、不利益を被るユーザを見出すことができ、利用状況の偏りを精度良く導出できる。運行の偏りを見た事業者は、その偏りに応じた適切な対処法を実行することが可能となる。

推定部２８は、抽出部２６により抽出された運行の偏りと、デマンド交通の利用情報とをもとに、シミュレーションを実行し、運行サービスを変更したときの利用状況を推定する。推定部２８は、リクエストが集中する時間帯および場所で運行する車両の台数を変更した場合に、リクエストの成立数やユーザの総乗車距離を推定する。

また、推定部２８は、リクエストが集中する時間帯および経路にスポット的に定期運行する車両を追加してユーザを運んだ場合に、リクエストの不成立数やユーザの総乗車距離を推定する。また、推定部２８は、リクエストが集中する経路を回遊する車両を追加してユーザを運んだ場合に、リクエストの不成立数やユーザの総乗車距離を推定する。また、出発地および目的地が予め設定された停留所である場合に、推定部２８は、停留所の場所変更、停留所の追加、停留所の削減したときのリクエストの不成立数やユーザの総乗車距離を推定する。つまり、推定部２８は、抽出部２６により抽出された運行の偏りと、デマンド交通の利用情報とをもとに、車両の運行サービスを変更した場合における利用状況の変化を推定できる。

このように、推定部２８は、運行の偏りを解消させるサービス変更をした場合の効果を推定することができる。この推定によって、リクエスト不成立数を減らしたり、ユーザの総乗車距離を増やしたりするサービス変更の内容を把握できる。

推定部２８は、ユーザのプロファイル情報をもとにシミュレーションを実行してよい。ユーザのプロファイル情報に、乗り合わせ条件が設定されており、設定された属性のプロファイル情報を有するユーザとの乗り合わせは拒否する。例えば、女性が男性との乗り合わせを拒否する条件を設定したり、ある会社の社員が競合他社との社員との乗り合わせを拒否する条件を設定することが可能である。推定部２８は、定期運行する車両や回遊する車両を追加した場合に、乗り合わせ条件を設定したユーザは定期運行する車両や回遊する車両に乗車しないと推定してよい。

また、推定部２８は、運行車両数の調整、スポット的に定期運行する車両の追加、回遊する車両の追加などのサービス変更をした場合に、いずれのサービス変更の効果が高いか、例えば、いずれのサービス変更がリクエストの不成立数を大きく減らせるか推定し、その推定結果をもとにサービス変更の種類毎の優先順位を導出してよい。

出力部３０は、推定部２８に推定されたサービス変更をした場合の効果を示す推定結果をディスプレイや外部のサーバ装置に出力する。出力部３０は、サービス変更の種類毎の優先順位をもとに、お勧めのサービス変更を出力してよい。

図３は、情報処理装置１０によるデマンド交通の利用状況を分析する処理のフローチャートである。情報処理装置１０の取得部２２は、運行決定装置１２からデマンド交通の利用情報を取得する（Ｓ１０）。この利用情報には、ユーザのリクエスト情報と、そのリクエスト情報の成立または不成立を示す応答情報とが含まれる。

導出部２４は、デマンド交通の利用情報から利用分布を導出する（Ｓ１２）。利用分布は、あるエリアや停留所における、時間帯毎の利用頻度、リクエスト受付数、リクエスト不成立数などを含む。

抽出部２６は、導出部２４によって導出された利用分布から運行の偏りを抽出する（Ｓ１４）。抽出された運行の偏りは、例えば、リクエストが所定値以上に集中する時間帯および場所や、リクエストの不成立となる頻度が高い時間帯および場所の情報を含む。

推定部２８は、抽出部２６によって抽出された運行の偏りを低減するシミュレーションを実行し、その効果を推定する（Ｓ１６）。例えば、推定部２８は、リクエストが集中する場所に、回遊する車両の追加、定期運行車両の追加等をした場合のリクエスト不成立数を推定する。推定部２８は、シミュレーション結果から、効果に応じてサービス変更の優先順位を導出する。出力部３０は、運行の偏りを低減する手段として、推定部２８によって推定された複数のサービス変更うち、優先順位が高い順に出力する（Ｓ３０）。

なお実施例はあくまでも例示であり、各構成要素の組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

１ 情報処理システム、 １０ 情報処理装置、 １２ 運行決定装置、 １４ ユーザ端末装置、 ２０ 通信部、 ２２ 取得部、 ２４ 導出部、 ２６ 抽出部、 ２８ 推定部、 ３０ 出力部、 ３２ 通信部、 ３４ 運行決定部、 ３６ 車両情報保持部。

Claims (3)

1. ユーザのリクエストに応じて運行するデマンド交通の利用情報を取得する取得部と、
   取得された利用情報にもとづいてデマンド交通の利用分布を導出する導出部と、
   前記導出部により導出された利用分布から運行の偏りを抽出する抽出部と、
   前記利用情報と前記運行の偏りとから、前記運行の偏りを低減する複数の手段を優先順位が高い順に出力する出力部と、を備え、
   取得された利用情報には、ユーザがデマンド交通の利用を申し込んだリクエスト情報と、リクエスト情報の成立および不成立を示す情報とが含まれ、
   前記複数の手段は、所定の時間帯および所定の場所で運行する車両の台数の変更、所定の時間帯および所定の場所でスポット的に定期運行する車両の追加、所定の経路を回遊する車両の追加、停留所の場所変更および停留所の増減のうちいずれか複数の運行サービスの変更を含むことを特徴とする情報処理装置。
2. 前記出力部は、前記運行の偏りを低減する複数の手段を実行することを推定することによって、前記手段の実施によるリクエストの不成立数の変化に関する推定結果にもとづいて導出した複数の前記手段の優先順位を出力することを特徴とする請求項１に記載の情報処理装置。
3. 前記出力部は、前記運行の偏りを低減する複数の手段を実行することを推定することによって、前記手段の実施によるユーザの総乗車距離の変化に関する推定結果にもとづいて導出した複数の前記手段の優先順位を出力することを特徴とする請求項１または２に記載の情報処理装置。

Images