JP2022167420A - 乗継ルート提案装置及び乗継ルート提案方法 - Google Patents

Abstract

【課題】乗り継ぎにおける接触人数を低減させることが可能な乗継ルート提案装置及び乗継ルート提案方法を提供する。
【解決手段】管理サーバ２０は、移動手段の乗り継ぎが必要である場合、乗継可能な乗継ルート候補を複数抽出し、抽出された複数の乗継ルート候補ごとに、乗り継ぎ地点におけるユーザの所定範囲内で単位時間接触する他のユーザ数を示す接触人数を所定の情報に基づいて予測し、複数の乗継ルート候補のうち、接触人数が少ない乗継ルート候補を接触人数が多い乗継ルート候補よりも優先してユーザに提案する。
【選択図】図１

Description

本発明は、乗継ルート提案装置及び乗継ルート提案方法に関する。

従来より、交通機関の乗り継ぎにおいて、混雑する駅の利用を回避する代替経路をユーザに提供する発明が知られている（特許文献１）。

特許第６４７００１０号

しかしながら、感染症が流行している期間においては、他者と接触する時間の長さを考慮する必要があるが、特許文献１に記載された発明では考慮されていない。混雑度が低い場所でも、滞在時間が長くなると、接触する人数が増えてしまうおそれがある。

本発明は、上記問題に鑑みて成されたものであり、その目的は、乗り継ぎにおける接触人数を低減させることが可能な乗継ルート提案装置及び乗継ルート提案方法を提供することである。

本発明の一態様に係る乗継ルート提案装置は、移動手段の乗り継ぎが必要である場合、乗継可能な乗継ルート候補を複数抽出し、抽出された複数の乗継ルート候補ごとに、乗り継ぎ地点におけるユーザの所定範囲内で単位時間接触する他のユーザ数を示す接触人数を所定の情報に基づいて予測し、複数の乗継ルート候補のうち、接触人数が少ない乗継ルート候補を接触人数が多い乗継ルート候補よりも優先してユーザに提案する。

本発明によれば、乗り継ぎにおける接触人数を低減させることが可能となる。

図１は、本発明の実施形態に係る乗継ルート提案システム１０の概略図である。 図２は、本発明の実施形態に係る管理サーバ２０、通信装置６０、及びタクシー４０の機能ブロック図である。 図３は、複数の乗継ルート候補を説明する図である。 図４は、接触人数を説明する図である。 図５は、ルート提案方法の一例を説明する図である。 図６は、本発明の実施形態に係る乗継ルート提案装置の一動作例を説明するフローチャートである。 図７は、本発明の変形例に係る乗継ルート提案装置の一動作例を説明するフローチャートである。

以下、本発明の実施形態について、図面を参照して説明する。図面の記載において同一部分には同一符号を付して説明を省略する。

図１～２を参照して、本実施形態に係る乗継ルート提案システム１０の構成例を説明する。図１に示すように、乗継ルート提案システム１０は、管理サーバ２０と、通信ネットワーク３０と、タクシー４０～４２と、ユーザ７０と、ユーザ７０が所持する通信装置６０と、を含む。なお、図１において、タクシーは３台存在するが、これに限定されない。乗継ルート提案システム１０は、４台以上のタクシーを含んでもよい。

管理サーバ２０は、通信ネットワーク３０を介してタクシー４０～４２及び通信装置６０と通信する。管理サーバ２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１と、メモリ２２と、通信Ｉ／Ｆ２３と、記憶装置２４とを備える汎用のコンピュータであり、これらの構成要素が図示しないバスなどを介して電気的に接続されている。管理サーバ２０は、タクシー４０～４２の配車サービスに用いられる。管理サーバ２０の設置場所は特に限定されないが、例えば管理サーバ２０はタクシー４０～４２を運用する事業者の管理センタに設置される。

ＣＰＵ２１は、記憶装置２４などに記憶されている様々なプログラムをメモリ２２に読み込んで、プログラムに含まれる各種の命令を実行する。メモリ２２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの記憶媒体である。記憶装置２４は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶媒体である。なお、以下で説明する管理サーバ２０の機能を含む乗継ルート提案システム１０の一部（または全部）は、通信ネットワーク３０上に配置されたアプリケーション（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）など）によって提供されてもよい。

通信Ｉ／Ｆ２３は、ネットワークアダプタなどのハードウェア、各種の通信用ソフトウェア、及びこれらの組み合わせとして実装され、通信ネットワーク３０などを介した有線または無線の通信を実現できるように構成されている。また、通信Ｉ／Ｆ２３はデータを送受信するための入力部及び出力部としての機能を有する。

通信ネットワーク３０は、無線または有線の何れかの方式、あるいは両方の方式によって構成されてもよく、通信ネットワーク３０には、インターネットが含まれてもよい。本実施形態では、管理サーバ２０、タクシー４０～４２、及び通信装置６０は、無線通信方式によって通信ネットワーク３０と接続する。

タクシー４０～４２は、運転者が存在する通常の車両でもよいし、運転者が存在しない自動運転車両でもよい。運転者が存在しない自動運転車両は、ロボットタクシーまたは無人タクシーと表現されてもよい。本実施形態ではタクシー４０～４２は運転者が存在しない自動運転車両として説明する。

ユーザ７０は、通信装置６０を用いてタクシーをリクエスト（予約）する。通信装置６０には、タクシーの予約に用いられる乗継配車アプリケーション（以下単に乗継配車アプリと称する）がインストールされており、ユーザ７０は、乗継配車アプリを使ってタクシーをリクエストする。

次に、図２を参照して、管理サーバ２０、タクシー４０、通信装置６０の詳細な構成について説明する。なお、図２において、タクシー４１～４２は省略するが、タクシー４１～４２はタクシー４０と同様の構成を有する。

通信装置６０は、通信Ｉ／Ｆ６０１と、乗継配車アプリ６０２と、ＧＰＳ受信機６０３と、ディスプレイ６０４を備える。通信Ｉ／Ｆ６０１は、通信Ｉ／Ｆ２３（図１参照）と同様の構成を備えており、通信ネットワーク３０を介して管理サーバ２０と通信する。通信装置６０は、例えば、スマートフォン、タブレットなどの携帯型の装置である。また、通信装置６０は、ウェアラブル型の装置であってもよい。なお、図示は省略するが、通信装置６０も管理サーバ２０と同様に、ＣＰＵ（コントローラ）、メモリ、記憶装置などを備える。

乗継配車アプリ６０２は、上述したようにタクシーのリクエストに用いられる。乗継配車アプリ６０２は、ユーザ７０がタクシーをリクエストする際のユーザインタフェースとして機能する。乗継配車アプリ６０２は、通信装置６０に設けられたＣＰＵが、通信装置６０に設けられた記憶装置から、専用のアプリケーションプログラムを読み出して実行することで実現する。ユーザ７０がタクシーをリクエストする際、ユーザ７０は、希望する乗車場所、希望する乗車時間、希望する降車場所などを乗継配車アプリ６０２に入力し、タクシーをリクエストする。本実施形態において、「乗り継ぎが必要」とは、ユーザ７０がリクエスト時に電車に乗車中であり、電車から降りる駅でタクシーに乗り継いで目的地に向かう必要がある、ということを意味する。ユーザ７０は、希望する乗車場所、希望する乗車時間を必ずしも入力する必要はない。これについては後述する。

乗継配車アプリ６０２は、ユーザ７０の入力に従って、管理サーバ２０に配車リクエストを送信する。また、通信装置６０は、配車リクエストに対して管理サーバ２０から返信される信号に含まれる各種情報（配車リクエスト受領、到着予定時刻、走行予定経路、接触人数など）を、ディスプレイ６０４に表示する。ただし、乗継配車アプリ６０２の実現方法は、これに限定されない。例えば、通信装置６０が、乗継配車アプリ６０２の機能を提供するサーバにアクセスして機能提供を受け、サーバから送信される機能の実行結果をブラウザに表示するようにしてもよい。接触人数については後述する。

ＧＰＳ受信機６０３によって取得された通信装置６０の位置情報は、任意のタイミングで管理サーバ２０に送信される。

タクシー４０は、通信Ｉ／Ｆ４０１と、車両ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）４０２と、ＧＰＳ受信機４０３とを備える。通信Ｉ／Ｆ４０１は、通信Ｉ／Ｆ２３及び通信Ｉ／Ｆ６０１と同様の構成を備えており、通信ネットワーク３０を介して管理サーバ２０と通信する。車両ＥＣＵ４０２は、タクシー４０を制御するためのコンピュータである。車両ＥＣＵ４０２は、管理サーバ２０から受信した指令に基づいて各種のアクチュエータ（ブレーキアクチュエータ、アクセルアクチュエータ、ステアリングアクチュエータなど）を制御する。ＧＰＳ受信機４０３によって取得されたタクシー４０の位置情報は、任意のタイミングで管理サーバ２０に送信される。

管理サーバ２０のＣＰＵ２１（コントローラ）は、図２のブロック図に示すように、複数の機能の一例として、配車受付部２１１と、割当部２１２と、ルート抽出部２１３と、位置情報取得部２１４と、所要時間算出部２１５と、人口密度予測部２１６と、接触人数予測部２１７と、ルート提案部２１８とを備える。管理サーバ２０の記憶装置２４には、図２に示すように、地図データベース２４１と、顧客データベース２４２と、イベント情報データベース２４３と、交通機関混雑情報データベース２４４とが格納されている。

地図データベース２４１には、道路情報、施設情報など経路案内に必要となる地図情報が記憶されている。地図情報には、道路の車線数、道幅情報、道路の起伏情報が含まれる。また地図情報には、速度制限、一方通行などを示す道路標識、横断歩道、区画線などを示す道路標示も含まれる。

顧客データベース２４２には、ユーザ７０のＩＤなどのアカウント情報、タクシーの利用履歴などが格納されている。タクシーの利用履歴とは本実施形態に係る乗継ルート提案システム１０を利用した際の履歴である。

配車受付部２１１は、通信装置６０に入力されたユーザ７０の配車リクエストを受け付ける。配車受付部２１１は、ユーザ７０の配車リクエストを受け付けた旨、乗車場所への到着予定時刻、乗車場所への走行予定経路などを通信装置６０に通知する機能を有する。

割当部２１２は、受け付けた配車リクエストに基づいて、複数のタクシー４０～４２（図１参照）の中から適切なタクシーを割り当てる。例えば、配車受付部２１１は、効率化のために、複数のタクシー４０～４２の中から、ユーザ７０が希望する乗車場所に最も近い空車のタクシーを割り当てることができる。

また、割当部２１２は、地図データベース２４１を参照して割り当てたタクシーの現在地からユーザ７０が希望する乗車場所までの走行ルートを設定し、設定した走行ルートに沿ってユーザ７０が希望する乗車場所まで走行するようにタクシー４０に対して指令を送る。割当部２１２が算出する走行ルートは、例えば、タクシー４０の現在地からユーザ７０が希望する乗車場所までもっとも短い時間で到着できるルートである。なお、ルート抽出部２１３によって移動手段の乗り継ぎが必要であると判断された場合、別の方法でルートが設定されてもよい。

ルート抽出部２１３は、移動手段の乗り継ぎが必要であると判断した場合、乗継可能な乗継ルート候補を複数抽出する。ここで図３を参照して乗継可能な乗継ルート候補について説明する。図３に示すシーンは、ユーザ７０が電車８０に乗ってＡ駅８１に向かっているシーンである。符号８３はユーザ７０の目的地である。電車８０に乗っているユーザ７０は乗継配車アプリ６０２を操作して、タクシーをリクエストする。図３のシーンにおいて、ユーザ７０は、目的地８３を入力し、目的地８３に到着する希望到着時間を入力し、乗り継ぎが必要であることを入力したとする。ここでは希望する乗車場所、すなわち、タクシーに乗る駅についてはユーザ７０は入力しないものとする。

ユーザ７０のリクエストを受信した割当部２１２は、ユーザ７０の現在の位置情報（正確にはユーザ７０が所持する通信装置６０の現在の位置情報）に基づいて、目的地８３に到着するためにユーザ７０が降りる可能性のある駅を抽出する。これはユーザ７０の現在の位置情報と、地図データベース２４１を参照して目的地８３に近い順から駅を抽出すれば実現する。なおユーザ７０の現在の位置情報は位置情報取得部２１４によって取得される。図３のシーンにおいて、目的地８３に到着するためにユーザ７０が降りる可能性のある駅として、Ａ駅８１とＢ駅８２の２つの駅が抽出されたとする。割当部２１２は、Ａ駅８１及びＢ駅８２の近くに存在するタクシーをユーザ７０を迎えに行くタクシーとして割り当てる。図３のシーンにおいて、割り当てられたタクシーは、タクシー４０とする。このように、目的地８３に到着するために移動手段の乗り継ぎが必要である場合、ルート抽出部２１３は、移動手段の乗り継ぎが必要であると判断する。この判断は、主にユーザ７０の現在の位置情報及びユーザ７０の目的地８３に基づいて自動的に行われる。ただしこれに限定されない。ユーザ７０は、タクシーをリクエストする際、乗り継ぎが必要と乗継配車アプリ６０２上で入力してもよい。そしてルート抽出部２１３は、ユーザ７０から乗り継ぎが必要であることを示す信号を受信した場合、乗継可能な乗継ルート候補を複数抽出してもよい。

ルート抽出部２１３は、タクシー４０の走行ルートを抽出する。具体的には、ルート抽出部２１３は、走行ルートＲ１と走行ルートＲ２の２つの走行ルートを抽出する。走行ルートＲ１は、Ａ駅８１でユーザ７０を乗車させ、その後目的地８３に向かうルートである。走行ルートＲ１はユーザ７０から見れば、符号８４で示されるルートに沿って目的地８３に向かうルートである。走行ルートＲ２は、Ｂ駅８２でユーザ７０を乗車させ、その後目的地８３に向かうルートである。走行ルートＲ２はユーザ７０から見れば、符号８５で示されるルートに沿って目的地８３に向かうルートである。走行ルートＲ１及び走行ルートＲ２は、駅での乗り継ぎ時間を含めても、ユーザ７０の希望到着時間までに目的地８３に到着できるルートとする。このようにルート抽出部２１３は、移動手段の乗り継ぎが必要であると判断した場合、乗継可能な乗継ルート候補を複数抽出する。ここでいう複数の乗継ルート候補は、走行ルートＲ１及び走行ルートＲ２を指す。ルート抽出部２１３によって抽出される複数の乗継ルート候補はあくまで候補であって、どの走行ルートを選択するか、最終的な決定権はユーザ７０が持っている。なお上述においてユーザ７０は希望する乗車場所、希望する乗車時間を必ずしも入力する必要はない、と説明した。これは、ユーザ７０の目的地が符号８３であるならば、ユーザ７０が降りる可能性がある駅はＡ駅８１またはＢ駅８２であるとシステム側で自動的に決定されるからである。またＡ駅８１またはＢ駅８２に到着する時間もシステム側で自動的に把握されるため、駅での乗り継ぎ時間が判明すれば駅での乗車時間もシステム側で自動的に決定されるからである。

図２に戻る。位置情報取得部２１４は、通信装置６０からユーザ７０の位置情報を取得し、タクシー４０からタクシー４０の位置情報を取得する。ユーザ７０の位置情報とは、ユーザ７０が所持する通信装置６０の位置情報を意味する。位置情報取得部２１４は、取得した位置情報を所要時間算出部２１５に出力する。

所要時間算出部２１５は、位置情報取得部２１４から取得したタクシー４０の位置情報を用いて、タクシー４０の現在地からＡ駅８１またはＢ駅８２を経由して（乗り継ぎ時間も含めて）ユーザ７０が希望する目的地８３に到着するまでの所要時間を算出する。所要時間算出部２１５によって算出された所要時間が、ユーザ７０の希望到着時間を超える場合、すなわちユーザ７０の希望到着時間に間に合わない場合、ルート抽出部２１３は希望到着時間に間に合わない候補を除外する。例えば、図３のシーンにおいて、Ｂ駅８２の次の駅がＣ駅だったとする。ルート抽出部２１３はＣ駅を経由して目的地８３に向かうルートを抽出することが可能であるが、Ｃ駅を経由した場合ユーザ７０の希望到着時間に間に合わないのであれば、Ｃ駅を経由するルートは除外されることになる。

人口密度予測部２１６は、乗り継ぎ地点における、平均人口密度（人／ｍ^２）を予測する。乗り継ぎ地点とは、ユーザ７０が目的地８３に向かうために交通機関を乗り継ぐ場所を意味し、図３を例にすればＡ駅８１及びＢ駅８２である。人口密度予測部２１６はイベント情報データベース２４３または交通機関混雑情報データベース２４４を参照して乗り継ぎ地点における平均人口密度を予測する。イベント情報データベース２４３には、Ａ駅８１またはＢ駅８２の近くでどのようなイベントが開催されているかといったイベント情報が格納されている。一例として、Ａ駅８１またはＢ駅８２の近くでスポーツ大会、ライブなどが開催されていれば、開催されている時間帯において平均人口密度は上昇する。このように人口密度予測部２１６はイベント情報データベース２４３を参照することにより、乗り継ぎ地点における平均人口密度を予測することが可能となる。なおイベント情報データベース２４３には、過去のイベント時における平均人口密度が格納されていてもよい。この場合、過去のイベントと類似するイベントが行われていれば、過去のデータを参照することにより現在の平均人口密度を予測することが可能となる。

交通機関混雑情報データベース２４４には、交通機関（例えば鉄道会社）から取得した駅の混雑に関する情報が格納されている。人口密度予測部２１６は交通機関混雑情報データベース２４４を参照することにより、乗り継ぎ地点における平均人口密度を予測することが可能となる。

接触人数予測部２１７は、乗り継ぎ地点における接触人数を予測する。本実施形態において「接触人数」の定義は、国立感染症研究所の定義を用いる。国立感染症研究所の定義によれば、「濃厚接触者」とは手で触れることの出来る距離（目安として１メートル）で、必要な感染予防策なしで、「患者（確定例）」と１５分以上の接触があった者（周辺の環境や接触の状況等個々の状況から患者の感染性を総合的に判断する）と定義される。なおこの定義は、「濃厚接触者」の定義の一例となっているが、本実施形態ではこの定義を用いる。この定義について必要があれば以下のリンクを参照されたい。https://www.niid.go.jp/niid/images/epi/corona/COVID19-02-210108.pdf

本実施形態では、「濃厚接触者」の定義を用いて、「接触人数」を１ｍ以内で１５分以上接触した状態の人数と定義する。「接触人数」の詳細について図４を参照して説明する。図４に示す符号９０は、ユーザ７０を中心とした半径１ｍの円を示す。この円９０以内に１５分以上滞在したユーザ７１がいればユーザ７１は「接触人数」としてカウントされる。つまりここでいう接触とは直接触れることを意味するものではなく、半径１ｍ以内において１５分以上滞在したユーザ７１がいればそのユーザ７１とは接触したとみなすことを意味する。次に接触人数の予測方法の一例について説明する。接触人数は、式１によって求められる。

［数１］
接触人数＝（単位時間当たりの接触人数）×（乗継時間）・・・（１）

式１における「単位時間当たりの接触人数」とは、人口密度予測部２１６によって予測された平均人口密度を１５分で割った単位時間当たりの接触人数(人／分)である。よって式１は式２で表現されてもよい。

［数２］
接触人数＝（平均人口密度÷１５）×（乗継時間）・・・（２）

式１及び式２における「乗継時間」とは、乗り継ぎ地点において乗り継ぎに要する時間である。一例として「乗継時間」には電車を降りてから改札口までの時間、改札口からタクシー乗り場までの時間などが含まれる。ここで図３のＡ駅８１における「乗継時間」が６分であり、図３のＢ駅８２における「乗継時間」が２分であったとする。また、Ａ駅８１における平均人口密度が０．２４人／半径１ｍ円であり、Ｂ駅８２における平均人口密度が０．４８人／半径１ｍ円であったとする。この場合、Ａ駅８１における「接触人数」は０．２４÷１５×６≒０．１人となる。Ｂ駅８２における「接触人数」は０．４８÷１５×２≒０．０６人となる。このように接触人数予測部２１７の予測によれば、Ｂ駅８２における「接触人数」はＡ駅８１における「接触人数」より少ないことが判明する。

ルート提案部２１８は、接触人数予測部２１７によって接触人数が少ないと予測されたルートを優先的にユーザ７０に提案する。図３を例に取ればＡ駅８１を経由する走行ルートＲ１よりも、Ｂ駅８２を経由する走行ルートＲ２のほうが接触人数が少ないと予測されているため、ルート提案部２１８は走行ルートＲ２を優先的にユーザ７０に提案する。優先的に提案する方法は特に限定されないが、例えば図５に示すように、走行ルートＲ２をオススメのルートとして通信装置６０の画面上に表示してもよい。図５に示すように所要時間、接触人数を同時に表示してもよい。これにより、ユーザ７０は、希望到着時間までに目的地８３に到着できることを知ることができたり、乗り継ぎ地点においてどれくらいの人と接触するか、その目安を知ることができたりする。なお、図５の示す例では通信装置６０の画面下に走行ルートＲ１を表示しているが、走行ルートＲ１を表示しなくてもよい。他の優先的な提案方法として、走行ルートＲ２の表示を目立たせてもよい。

次に、図６のフローチャートを参照して、乗継ルート提案装置の一動作例を説明する。

ステップＳ１０１において、配車受付部２１１は、通信装置６０に入力されたユーザ７０の配車リクエストを受け付ける。処理はステップＳ１０３に進み、ルート抽出部２１３は、移動手段の乗り継ぎが必要であると判断した場合、乗継可能な乗継ルート候補を複数抽出する。処理はステップＳ１０５に進み、人口密度予測部２１６はイベント情報データベース２４３または交通機関混雑情報データベース２４４を参照して乗り継ぎ地点における平均人口密度を予測する。処理はステップＳ１０７に進み、接触人数予測部２１７はステップＳ１０５で予測された平均人口密度と乗り継ぎに要する時間を用いて乗り継ぎ地点における接触人数を予測する。処理はステップＳ１０９に進み、ルート提案部２１８は、ステップＳ１０７で予測された接触人数が少ないと予測されたルートを優先的にユーザ７０に提案する（図５参照）。

なお、接触人数を予測する方法の一例として、平均人口密度及び乗り継ぎに要する時間を用いる方法を説明したが、これに限定されない。接触人数予測部２１７は、他のユーザが過去に乗継ルート提案システム１０を利用した際の接触人数を用いて接触人数を予測してもよい。他のユーザが過去に乗継ルート提案システム１０を利用した際の接触人数は顧客データベース２４２に格納されているため、接触人数予測部２１７は顧客データベース２４２を参照して他のユーザが過去に乗継ルート提案システム１０を利用した際の接触人数を取得することにより接触人数を予測できる。例えば、過去の履歴と日付、曜日、時間帯が類似していれば、過去の接触人数をそのまま接触人数として利用してもよい。

（作用効果）
以上説明したように、本実施形態に係る乗継ルート提案装置（管理サーバ２０）によれば、以下の作用効果が得られる。

乗継ルート提案装置（管理サーバ２０）は、ユーザのリクエストに基づいてユーザの目的地８３までのルートを提案するコントローラ２１を備える。
コントローラ２１は移動手段の乗り継ぎが必要である場合、乗継可能な乗継ルート候補を複数抽出する。乗継可能な、複数の乗継ルート候補の一例は、図３に示す走行ルートＲ１及び走行ルートＲ２である。コントローラ２１は抽出された複数の乗継ルート候補ごとに、乗り継ぎ地点におけるユーザの所定範囲内で単位時間接触する他のユーザ数を示す接触人数を所定の情報に基づいて予測する。乗り継ぎ地点の一例は、図３に示すＡ駅８１及びＢ駅８２である。ユーザの所定範囲内の一例は、図４に示すユーザ７０を中心とした半径１ｍの円内である。単位時間の一例は１５分である。コントローラ２１は複数の乗継ルート候補のうち、接触人数が少ない乗継ルート候補を接触人数が多い乗継ルート候補よりも優先してユーザに提案する。優先して提案する方法の一例は図５に示すように、接触人数が少ない走行ルートＲ２を接触人数が多い走行ルートＲ１よりも画面上部に表示することである。このように接触人数が少ない乗継ルート候補を接触人数が多い乗継ルート候補よりも優先してユーザに提案することにより、乗り継ぎにおける接触人数を低減させることが可能となる。

所定の情報には、乗り継ぎ地点の平均人口密度及び乗り継ぎに要する時間、または他のユーザが過去に乗り継ぎを利用した際の接触人数が含まれる。コントローラ２１は、平均人口密度及び乗り継ぎに要する時間を用いて接触人数を予測する、または他のユーザが過去に乗り継ぎを利用した際の接触人数を用いて接触人数を予測する。これにより乗り継ぎ地点における接触人数を精度よく予測することが可能となる。

複数の乗継ルート候補は、ユーザの到着希望時間内に目的地に到着するルートである。これによりユーザは希望する時間内に目的地に到着するルートの中から、乗り継ぎ地点における接触人数が少ないルートを選択することができる。

移動手段は、第１移動手段と、第１移動手段と異なる第２移動手段を含む。コントローラ２１は、ユーザの位置情報とユーザの目的地に基づいて、第１移動手段から第２移動手段への乗り継ぎが必要である場合に、移動手段の乗り継ぎが必要であると判断する。第２移動手段は車両である。また車両はタクシーでもよく、自家用車でもよい。第１移動手段は電車である。

（変形例）
次に図７を参照して本実施形態の変形例について説明する。変形例では乗り継ぎ地点における必要換気量も考慮する。図７に示すステップＳ２０１～２０５の処理は、図６に示すステップＳ１０１～１０５の処理と同様であるため、説明を省略する。

ステップＳ２０７において、ルート抽出部２１３は乗り継ぎ地点における必要換気量を算出する。本実施形態における「必要換気量」の定義は、厚生労働省の定義を用いる。本実施形態における「必要換気量」とは、「換気の悪い密閉空間」に当てはまらないための必要な換気量である。厚生労働省によれば、感染症のリスク要因の一つである「換気の悪い密閉空間」に当てはまらないためには、二酸化炭素の含有率が１００万分の１０００以下（＝１０００ｐｐｍ以下）であれば、つまり換気量が一人あたり毎時３０ｍ^３であれば足りるとされている。この定義について必要があれば以下のリンクを参照されたい。https://www.mhlw.go.jp/content/10900000/000618969.pdf

換気量は式３を用いて求められる。

呼気のＣＯ２濃度、室内濃度、及び外気濃度は、交通機関（例えば鉄道会社）から取得すればよい。ルート抽出部２１３は、算出した換気量が３０ｍ^３/(ｈ・人)以上である場合、その乗り継ぎ地点で滞在可能と判定する（ステップＳ２０９でＹＥＳ）。図３に示すＡ駅８１及びＢ駅８２の両方で滞在可能と判定された場合、ステップＳ２１１及びＳ２１３の処理は図６に示すステップＳ１０７及びＳ１０９と同じである。Ａ駅８１及びＢ駅８２のどちらか一方について滞在可能と判定された場合、ステップＳ２１１において接触人数は予測されるものの、ステップＳ２１３で提案されるルートは滞在可能と判定された乗り継ぎ地点を経由するルートとなる。

一方、ルート抽出部２１３は、算出した換気量が３０ｍ^３/(ｈ・人)より少ない場合、その乗り継ぎ地点で滞在不可と判定する（ステップＳ２０９でＮＯ）。なおステップＳ２０９でＮＯとは、すべての乗り継ぎ地点で滞在不可と判定された場合である。つまりＡ駅８１及びＢ駅８２の両方で滞在不可であるため、配車受付部２１１は、タクシーを配車することはできない旨をユーザ７０に通知する（ステップＳ２１５）。

このように変形例によれば、コントローラ２１は複数の乗継ルート候補ごとに、乗り継ぎ地点における換気量を算出する。コントローラ２１は算出された換気量が所定の基準以上である場合、接触人数を予測する。所定の基準の一例は３０ｍ^３/(ｈ・人)である。コントローラ２１は算出された換気量が所定の基準未満である場合、対象となる乗り継ぎ地点を経由する乗継ルート候補をユーザに提案するルートから除外する。このように変形例によれば乗り継ぎ地点における換気量も用いることにより、換気が悪い場所すなわち感染リスクが高いと考えられる場所を案内から除外できるため、ユーザの感染リスクを低減することが可能となる。

上述の実施形態に記載される各機能は、１または複数の処理回路により実装され得る。処理回路は、電気回路を含む処理装置等のプログラムされた処理装置を含む。処理回路は、また、記載された機能を実行するようにアレンジされた特定用途向け集積回路（ＡＳＩＣ）や回路部品等の装置を含む。

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

上述の実施形態では、乗り継ぎについて、電車からタクシーへの乗り継ぎを取り上げて説明したが、乗り継ぎはこれに限定されない。本発明は乗り継ぎを行う場所が複数存在すれば適用可能であるから、バスからタクシーへの乗り継ぎ、タクシーからタクシーへの乗り継ぎにおいても適用可能である。

乗継ルート提案装置は管理サーバ２０として説明したが、これに限定されない。乗継ルート提案装置は通信装置６０であってもよい。乗継ルート提案装置が通信装置６０である場合、通信装置６０は必要な情報を管理サーバ２０から取得すれば足りる。

１０ 乗継ルート提案システム
２０ 管理サーバ
２１１ 配車受付部
２１２ 割当部
２１３ ルート抽出部
２１４ 位置情報取得部
２１５ 所要時間算出部
２１６ 人口密度予測部
２１７ 接触人数予測部
２１８ ルート提案部
２４１ 地図データベース
２４２ 顧客データベース
２４３ イベント情報データベース
２４４ 交通機関混雑情報データベース

Claims (6)

1. ユーザのリクエストに基づいて前記ユーザの目的地までのルートを提案するコントローラを備える乗継ルート提案装置であって、
   前記コントローラは、
   移動手段の乗り継ぎが必要である場合、乗継可能な乗継ルート候補を複数抽出し、
   抽出された複数の乗継ルート候補ごとに、乗り継ぎ地点における前記ユーザの所定範囲内で単位時間接触する他のユーザ数を示す接触人数を所定の情報に基づいて予測し、
   前記複数の乗継ルート候補のうち、前記接触人数が少ない乗継ルート候補を前記接触人数が多い乗継ルート候補よりも優先して前記ユーザに提案する
   ことを特徴とする乗継ルート提案装置。
2. 前記所定の情報には、前記乗り継ぎ地点の平均人口密度及び乗り継ぎに要する時間、または他のユーザが過去に乗り継ぎを利用した際の接触人数が含まれ、
   前記コントローラは、
   前記平均人口密度及び乗り継ぎに要する時間を用いて前記接触人数を予測する、または前記他のユーザが過去に乗り継ぎを利用した際の接触人数を用いて前記接触人数を予測する
   ことを特徴とする請求項１に記載の乗継ルート提案装置。
3. 前記複数の乗継ルート候補は、前記ユーザの到着希望時間内に前記目的地に到着するルートである
   ことを特徴とする請求項１または２に記載の乗継ルート提案装置。
4. 前記コントローラは、
   前記複数の乗継ルート候補ごとに、前記乗り継ぎ地点における換気量を算出し、
   算出された前記換気量が所定の基準以上である場合、前記接触人数を予測し、
   算出された前記換気量が所定の基準未満である場合、対象となる乗り継ぎ地点を経由する乗継ルート候補を前記ユーザに提案するルートから除外する
   ことを特徴とする請求項１～３のいずれか１項に記載の乗継ルート提案装置。
5. 前記移動手段は、第１移動手段と、前記第１移動手段と異なる第２移動手段を含み、
   前記コントローラは、前記ユーザの位置情報と前記ユーザの目的地に基づいて、前記第１移動手段から前記第２移動手段への乗り継ぎが必要である場合に、前記移動手段の乗り継ぎが必要であると判断し、
   前記第２移動手段は車両である
   ことを特徴とする請求項１～４のいずれか１項に記載の乗継ルート提案装置。
6. ユーザのリクエストに基づいて前記ユーザの目的地までのルートを提案するコントローラを備える乗継ルート提案装置の乗継ルート提案方法であって、
   前記コントローラは、
   移動手段の乗り継ぎが必要である場合、乗継可能な乗継ルート候補を複数抽出し、
   抽出された複数の乗継ルート候補ごとに、乗り継ぎ地点における前記ユーザの所定範囲内で単位時間接触する他のユーザ数を示す接触人数を所定の情報に基づいて予測し、
   前記複数の乗継ルート候補のうち、前記接触人数が少ない乗継ルート候補を前記接触人数が多い乗継ルート候補よりも優先して前記ユーザに提案する
   ことを特徴とする乗継ルート提案方法。

Images