(57)【要約】【課題】相乗りにおける好ましさを考慮した移動体システムを提供する。【解決手段】複数のユーザが同一の移動体に同乗して移動するライドシェアシステムを管理する情報処理装置であって、同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出することと、所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定することと、を実行する。【選択図】図１
2020107215.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザが同一の移動体に同乗して移動するライドシェアシステムを管理する情報処理装置であって、
同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出することと、
所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定することと、
を実行する制御部を有する、情報処理装置。
【請求項２】
前記制御部は、前記所定の移動体について、それぞれユーザグループの構成が異なる複数の応答方針の候補を決定し、各応答方針を取った場合に得られる前記第二の評価値に基づいて、採用する応答方針を決定する、
請求項１に記載の情報処理装置。
【請求項３】
前記複数の応答方針は、
（１）前記所定の移動体に既に乗車している複数のユーザからなる第一のユーザグループを維持した場合、
（２）前記所定の移動体に既に乗車している複数のユーザに前記候補ユーザを加えてなる第二のユーザグループを形成した場合
のいずれかである、
請求項２に記載の情報処理装置。
【請求項４】
前記属性は、複数の種類の属性値の集合であり、
前記制御部は、前記属性値のそれぞれに対して所定の方法で演算を行った結果を合算したものを前記第一の評価値とする、
請求項１から３のいずれかに記載の情報処理装置。
【請求項５】
前記属性は、前記ユーザの性別情報を含み、
前記第一の評価値は、前記移動体に乗車する複数のユーザの性別比が１対１に近いほど高くなる、
請求項１から４のいずれかに記載の情報処理装置。
【請求項６】
複数のユーザが同乗して移動可能な移動体と、前記移動体を管理する情報処理装置と、を含む移動体システムであって、
前記情報処理装置は、
同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出することと、
所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定することと、
前記応答方針に基づいて、前記移動体に対して運行指令を送信することと、
を実行する第一の制御部を有し、
前記移動体は、
前記運行指令に基づいた走行経路によって走行およびユーザの乗降を行わせる第二の制
御部を有する、
移動体システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、同一の車両に複数のユーザが同乗して移動するための技術に関する。
【背景技術】
【０００２】
交通渋滞の緩和や、燃料代の節約、環境対策などの目的で、一台の車両に複数のユーザが相乗りして移動を行う形態（ライドシェア）が、諸外国を中心に広がっている。また、このような移動形態において、複数のユーザをマッチングするための技術が開発されている。これに関連する技術として、特許文献１には、車両に相乗りして移動する複数のユーザに対して、公平な料金算出を行うシステムが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−２１４１６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
不特定多数のユーザが同一の車両に相乗りして移動する場合、複数のユーザの属性を考慮したうえで同乗者を決定することが好ましい。
【０００５】
本発明は上記の課題を考慮してなされたものであり、相乗りにおける好ましさを考慮した移動体システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の第一の様態に係る情報処理装置は、
複数のユーザが同一の移動体に同乗して移動するライドシェアシステムを管理する情報処理装置であって、同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出することと、所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定することと、を実行する制御部を有することを特徴とする。
【０００７】
また、本発明の第二の様態に係る移動体システムは、
前記情報処理装置は、同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出することと、所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定することと、前記応答方針に基づいて、前記移動体に対して運行指令を送信することと、を実行する第一の制御部を有し、前記移動体は、前記運行指令に基づいた走行経路によって走行およびユーザの乗降を行わせる第二の制御部を有することを特徴とする。
【０００８】
また、本発明の第三の態様は、上記の情報処理装置および移動体システムが実行する情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。
【発明の効果】
【０００９】
本発明によれば、相乗りにおける好ましさを考慮した移動体システムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】第一の実施形態に係る移動体システムの概要図である。
【図２】システムが有する構成要素の一例を概略的に示したブロック図である。
【図３】自律走行車両１００の外観を示した図である。
【図４】第一の実施形態における乗車データを説明する図である。
【図５】第一の実施形態におけるユーザ属性データを説明する図である。
【図６】複数のユーザがそれぞれ車両に乗車する時間を示したタイムチャートである。
【図７】第一の実施形態においてサーバ装置が実行する処理のフローチャートである。
【図８】システムの構成要素間におけるデータの流れを示したフロー図である。
【図９】第二の実施形態においてサーバ装置が実行する処理のフローチャートである。
【発明を実施するための形態】
【００１１】
実施形態に係る移動体システムは、複数のユーザが同一の車両に同乗して移動する形態（ライドシェア）を実現するためのシステムである。システムに含まれる車両（自律走行車両）は、ユーザの意向に基づいて、複数のユーザを乗降させながら走行する。
【００１２】
このような、複数のユーザが同一の車両に同乗する形態においては、同一の車両に乗車させるユーザの組を、ユーザの属性を考慮したうえで生成することが好ましい。例えば、相乗りを募集する人が女性である場合、相乗りの相手は男性よりも女性であることが好ましい。反対に、男女の親睦を深めることが目的のイベントを車内で開催する場合、男女比が偏らないように乗車メンバを決定することが好ましい。
しかし、通勤ライドシェアなどの形態と異なり、経路途中でユーザが頻繁に入れ替わるオンデマンド型のライドシェア形態においては、従来技術では適切な判断ができないという問題があった。
【００１３】
これに対応するため、本実施形態では、移動体（ライドシェア車両）の運行計画を生成する装置が、同一の移動体に乗車して移動するユーザグループについて、ユーザの属性に基づいた第一の評価値と、前記ユーザグループが維持される時間と、に基づいて第二の評価値を算出し、所定の移動体に新規に乗車するユーザの候補である候補ユーザが存在する場合に、前記所定の移動体において所定のユーザグループを形成した場合における前記第二の評価値を算出し、前記第二の評価値が所定のポリシーを満たすか否かに基づいて、前記候補ユーザに対する応答方針を決定する。
【００１４】
第一の評価値は、ユーザ属性の観点から見た好ましさを表す評価値である。好ましさの判定基準には様々なものがあるが、例えば、複数のユーザの属性が類似しているほど好ましいと判断してもよいし、複数のユーザの属性が分散しているほど好ましいと判断してもよい。
本発明にかかる情報処理装置は、第一の評価値に、ユーザグループが維持される時間を加味することで、第二の評価値（総合的な評価値）を算出する。かかる構成によると、メンバが頻繁に入れ替わるライドシェア形態において、ユーザグループに対する好ましさを精度よく算出することができる。
【００１５】
また、前記制御部は、前記所定の移動体について、それぞれユーザグループの構成が異なる複数の応答方針の候補を決定し、各応答方針を取った場合に得られる前記第二の評価値に基づいて、採用する応答方針を決定することを特徴としてもよい。
【００１６】
複数の応答方針とは、例えば、「最短ルートで候補ユーザを乗車させる」「所定の乗降を行ったのちに候補ユーザを乗車させる」「所定の地点を経由したのちに候補ユーザを乗車させる」「候補ユーザを乗車させない」等である。これらは、それぞれユーザグループの構成が異なる。制御部は、それぞれについて第二の評価値を算出し、値が最も高くなるような応答方針を採用してもよい。
【００１７】
また、前記複数の応答方針は、（１）前記所定の移動体に既に乗車している複数のユーザからなる第一のユーザグループを維持した場合、（２）前記所定の移動体に既に乗車している複数のユーザに前記候補ユーザを加えてなる第二のユーザグループを形成した場合のいずれかであることを特徴としてもよい。
すなわち、対象の移動体に候補ユーザを乗車させた場合と、乗車させなかった場合とで比較を行うようにしてもよい。
【００１８】
また、前記属性は、複数の種類の属性値の集合であり、前記制御部は、前記属性値のそれぞれに対して所定の方法で演算を行った結果を合算したものを前記第一の評価値とすることを特徴としてもよい。
【００１９】
ユーザに関連する属性には様々なものがあるため、好ましさの算出方法は一様ではない。例えば、「母国語は同一であることが好ましいが、性別は別であることが好ましい」等である。そこで、属性ごとに異なる演算方法によって結果を算出し、合算するようにしてもよい。
【００２０】
また、前記属性は、前記ユーザの性別情報を含み、前記第一の評価値は、前記移動体に乗車する複数のユーザの性別比が１対１に近いほど高くなることを特徴としてもよい。
例えば、男女の親睦を深めることが目的である場合など、複数のユーザの性別比が１対１に近いほど好ましい場合がある。
【００２１】
（第一の実施形態）
第一の実施形態に係る情報収集システムの概要について、図１を参照しながら説明する。本実施形態に係る情報収集システムは、与えられた指令に基づいて自律走行を行う複数の自律走行車両１００Ａ…１００ｎと、当該指令を発行するサーバ装置２００と、を含んで構成される。自律走行車両１００は、所定のサービスを提供する自動運転車両であり、サーバ装置２００は、複数の自律走行車両１００を管理する装置である。以下、複数の自律走行車両を個々に区別しないで総称する場合には、単に自律走行車両１００という。
【００２２】
自律走行車両１００は、個体ごとに異なる機能を持つことができる多目的移動体であり、道路上を自動運転および無人運転可能な車両である。自律走行車両１００は、例えば、所定のルートを走行する送迎車、利用者の要請に応じて運行されるオンデマンドタクシー、任意の移動先で営業を行うことができる移動店舗などとすることができるが、本実施形態では、複数のユーザを乗車させて移動することができる乗り合い車両（以下、ライドシェア車両とも称する）であるものとする。自律走行車両１００は、Electric Vehicle（ＥＶ）パレットとも呼ばれる。
なお、自律走行車両１００は、必ずしも無人車両である必要はない。例えば、営業要員や保安要員などが乗車していてもよい。また、自律走行車両１００は、必ずしも完全なる自律走行が可能な車両でなくてもよい。例えば、状況に応じて人が運転ないし運転の補助を行う車両であってもよい。
【００２３】
サーバ装置２００は、自律走行車両１００に対して運行を指令する装置である。本実施形態では、移動を希望するユーザが、サーバ装置２００に乗車リクエストを送信すると、サーバ装置２００は、当該乗車リクエストに含まれる乗車地点および降車地点（あるいは乗車希望時刻）に基づいて、当該ユーザをピックアップ可能な自律走行車両１００を選択し、その走行経路を生成したうえで、走行中の自律走行車両１００に対して、「乗車地点から降車地点まで人を輸送する」旨の運行指令を送信する。これにより、自律走行車両１００に対して、所定の経路に沿った走行をさせることができる。なお、運行指令は、走行以外に関する指令を含んでもよい。例えば、「乗車中のユーザに案内を行う」、「経路の途中でユーザを乗車／降車させる」、「ユーザが所持する端末に案内を送信する」といったものを含んでもよい。このように、運行指令には、走行以外に自律走行車両１００が行うべき動作を含ませてもよい。
【００２４】
本実施形態では、サーバ装置２００は、自律走行車両１００の走行位置や走行経路を管理し、リアルタイムで寄せられる乗車リクエストを処理する。サーバ装置２００は、ユーザから乗車リクエストを受信すると、当該乗車リクエストに対する応答方針を決定し、当該応答方針に沿った運行指令を自律走行車両１００に送信する。さらに、本実施形態では、サーバ装置２００は、ユーザに関連付いた属性に関する情報であるユーザ属性データを考慮して、前述した応答方針を決定する。応答方針の具体的な決定方法については後述する。
【００２５】
次に、システムの構成要素について、詳しく説明する。
図２は、図１に示した自律走行車両１００およびサーバ装置２００の構成の一例を概略的に示したブロック図である。なお、自律走行車両１００は複数であってもよい。
【００２６】
自律走行車両１００は、サーバ装置２００から取得した運行指令に基づいて走行する車両である。具体的には、無線通信を介して取得した運行指令に基づいて走行経路を生成し、車両の周辺をセンシングしながら適切な方法で道路上を走行する。
【００２７】
自律走行車両１００は、センサ１０１、位置情報取得部１０２、制御部１０３、駆動部１０４、通信部１０５、画像出力部１０６を含んで構成される。自律走行車両１００は、不図示のバッテリから供給される電力で動作する。
【００２８】
センサ１０１は、車両周辺のセンシングを行う手段であり、典型的にはレーザスキャナ、ＬＩＤＡＲ、レーダなどを含んで構成される。センサ１０１が取得した情報は、制御部１０３に送信される。
また、センサ１０１は、自律走行車両１００の車体に設けられたカメラを含んでもよい。例えば、Charged-Coupled Devices（ＣＣＤ）、Metal-oxide-semiconductor（ＭＯＳ）あるいはComplementary Metal-Oxide-Semiconductor（ＣＭＯＳ）等のイメージセンサを
用いることができる。
図３に示したように、本実施形態では、自律走行車両１００は、車載されたカメラを有しており、画像（静止画または動画）を取得することができる。なお、図３にはカメラを一つ示しているが、車体の複数の箇所に複数のカメラが設けられていてもよい。例えば、前方、後方、左右側方にそれぞれカメラが設置されていてもよい。
【００２９】
位置情報取得部１０２は、車両の現在位置を取得する手段であり、典型的にはＧＰＳ受信器などを含んで構成される。位置情報取得部１０２が取得した情報は、制御部１０３に送信される。
【００３０】
制御部１０３は、センサ１０１から取得した情報に基づいて、自律走行車両１００の制
御を行うコンピュータである。制御部１０３は、例えば、マイクロコンピュータによって構成される。
【００３１】
制御部１０３は、機能モジュールとして、運行計画生成部１０３１、環境検出部１０３２、走行制御部１０３３を有している。各機能モジュールは、ＲＯＭ（Read Only Memory）等の記憶手段に記憶されたプログラムをＣＰＵ（Central Processing Unit）（いずれ
も不図示）によって実行することで実現してもよい。
【００３２】
運行計画生成部１０３１は、サーバ装置２００から運行指令を取得し、自車両の運行計画を生成する。本実施形態において、運行計画とは、自律走行車両１００が走行する経路と、経路の一部または全部において自律走行車両１００が行うべき処理を規定したデータである。運行計画に含まれるデータの例として、例えば、以下のようなものが挙げられる。
【００３３】
（１）自車両が走行する経路を道路リンクの集合によって表したデータ
自車両が走行する経路は、例えば、不図示の記憶手段に記憶された地図データを参照し、与えられた出発地と目的地に基づいて自動的に生成してもよい。また、外部のサービスを利用して生成してもよい。
【００３４】
（２）経路上の地点において自車両が行うべき処理を表したデータ
自車両が行うべき処理には、例えば、「人を乗降させる」「乗車中のユーザに案内を行う」「データの収集を行う」といったものがあるが、これらに限られない。
運行計画生成部１０３１が生成した運行計画は、後述する走行制御部１０３３へ送信される。
【００３５】
環境検出部１０３２は、センサ１０１が取得したデータに基づいて、車両周辺の環境を検出する。検出の対象は、例えば、車線の数や位置、自車両の周辺に存在する車両の数や位置、自車両の周辺に存在する障害物（例えば歩行者、自転車、構造物、建築物など）の数や位置、道路の構造、道路標識などであるが、これらに限られない。自律的な走行を行うために必要なものであれば、検出の対象はどのようなものであってもよい。
また、環境検出部１０３２は、検出した物体をトラッキングしてもよい。例えば、１ステップ前に検出した物体の座標と、現在の物体の座標との差分から、当該物体の相対速度を求めてもよい。
環境検出部１０３２が検出した、環境に関するデータ（以下、環境データ）は、後述する走行制御部１０３３へ送信される。
【００３６】
走行制御部１０３３は、運行計画生成部１０３１が生成した運行計画と、環境検出部１０３２が生成した環境データ、ならびに、位置情報取得部１０２が取得した自車両の位置情報に基づいて、自車両の走行を制御する。例えば、所定の経路に沿って走行し、かつ、自車両を中心とする所定の安全領域内に障害物が進入しないように自車両を走行させる。車両を自律走行させる方法については、公知の方法を採用することができる。
【００３７】
駆動部１０４は、走行制御部１０３３が生成した指令に基づいて、自律走行車両１００を走行させる手段である。駆動部１０４は、例えば、車輪を駆動するためのモータやインバータ、ブレーキ、ステアリング機構、二次電池等を含んで構成される。
通信部１０５は、自律走行車両１００をネットワークに接続するための通信手段である。本実施形態では、３ＧやＬＴＥ等の移動体通信サービスを利用して、ネットワーク経由で他の装置（例えばサーバ装置２００）と通信を行うことができる。
なお、通信部１０５は、他の自律走行車両１００と車々間通信を行うための通信手段をさらに有していてもよい。
【００３８】
画像出力部１０６は、車体に設けられた車外ディスプレイに画像を出力する手段である。本実施形態では、自律走行車両１００は、車体の外側にディスプレイを有しており、任意の画像を出力することができる。車外ディスプレイは、液晶ディスプレイであってもよいし、ＬＥＤマトリクス等によって構成されていてもよい。画像出力部１０６は、運行指令や運行計画に含まれるデータに基づいて、画像を生成し、車外ディスプレイに出力することができる。これにより、例えば、乗車予定のユーザに対して車両番号などの目印を示すことができる。
【００３９】
次に、サーバ装置２００について説明する。
サーバ装置２００は、複数の自律走行車両１００の走行位置および走行経路を管理し、自律走行車両１００に対する運行指令を生成し送信する装置である。サーバ装置２００は、例えば、ユーザから乗車リクエストを受信した場合に、乗車地点および降車地点を特定したうえで、付近を走行中の（ライドシェア車両としてとして機能可能な）自律走行車両１００を選択し、当該車両に対して運行指令を送信する。
【００４０】
サーバ装置２００は、通信部２０１、制御部２０２、記憶部２０３を有して構成される。
通信部２０１は、通信部１０５と同様の、ネットワーク経由で自律走行車両１００と通信を行うための通信インタフェースである。
【００４１】
制御部２０２は、サーバ装置２００の制御を司る手段である。制御部２０２は、例えば、ＣＰＵによって構成される。
制御部２０２は、機能モジュールとして車両情報管理部２０２１、ライドシェア管理部２０２２、運行指令生成部２０２３を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵ（いずれも不図示）によって実行することで実現してもよい。
【００４２】
車両情報管理部２０２１は、管理下にある複数の自律走行車両１００を管理する。具体的には、所定の周期ごとに複数の自律走行車両１００から、位置情報、経路情報、イベント情報を受信し、日時と関連付けて後述の記憶部２０３に記憶させる。
位置情報は、自律走行車両１００の現在位置を表す情報であり、経路情報は、自律走行車両１００が走行を予定している経路に関する情報である。また、イベント情報は、運行中の自律走行車両１００において発生したイベント（例えば、ユーザの乗降）に関する情報である。
【００４３】
また、車両情報管理部２０２１は、必要に応じて、自律走行車両１００の特性に関するデータ（以下、車両情報）を保持および更新する。車両情報は、例えば、自律走行車両１００の識別子、用途・種別、扉タイプ、車体サイズ、積載量、搭乗可能人数、満充電時における走行可能距離、現時点における走行可能距離、現在のステータス（待機中、空車、実車、走行中、営業中等）などであるが、これ以外であってもよい。
【００４４】
ライドシェア管理部２０２２は、複数の自律走行車両１００に乗車している（あるいは、乗車予定の）ユーザに関する情報を管理する。
具体的には、ライドシェア管理部２０２２は、図４に示したような、各ユーザが自律走行車両１００に乗車する地点および降車する地点についての情報（乗車データ）を管理する。本実施形態では、乗車データとは、自律走行車両１００に乗車するユーザと、各ユーザが乗車する区間および時間を表したデータである。図４の例において、矢印の始点はユーザが乗車する地点を表し、矢印の終点はユーザが降車する地点を表す。なお、図４では、時間に関する情報を省略して乗車データを図示しているが、乗車データは、時間につい
ての情報を含んでいることが好ましい。乗車データは、ユーザや自律走行車両１００から送信された情報（例えば、乗車リクエストや、ユーザの乗降が完了したことを示すデータ等）に基づいて、ライドシェア管理部２０２２によって随時更新される。
【００４５】
また、ライドシェア管理部２０２２は、図５に示したような、システムを利用するユーザの属性に関する情報（ユーザ属性データ）を記憶している。当該データは、ユーザをシステムに登録する際に生成（更新）されたものであってもよい。
【００４６】
また、ライドシェア管理部２０２２は、新たなユーザから乗車リクエストを受信した場合に、記憶された乗車データとユーザ属性データに基づいて、当該乗車リクエストに対する応答方針（乗車リクエストを受諾するか否か、受諾する場合、どの自律走行車両１００がどのタイミングで迎えに行くか）を決定する。具体的な方法については後述する。
【００４７】
本実施形態では、乗車リクエストとは、乗車希望地点、降車希望地点、乗車希望時刻を含んだ情報である。乗車リクエストは、例えば、ネットワーク等を介して利用者から取得する。なお、乗車リクエストの送信元は、必ずしも一般の利用者である必要はなく、例えば、自律走行車両１００を運行する事業者などであってもよい。
【００４８】
運行指令生成部２０２３は、ライドシェア車両に対する乗車リクエストを外部から受信した場合に、ライドシェア管理部２０２２が決定した応答方針に基づき、自律走行車両１００に送信するための運行指令を生成する。
【００４９】
記憶部２０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。
【００５０】
次に、サーバ装置２００が乗車リクエストを受信した場合に、ライドシェア管理部２０２２が応答方針を決定する処理について説明する。以降の説明において、乗車リクエストを送信したユーザを乗車希望ユーザと称する。
【００５１】
ここではまず、ユーザ属性に基づく評価値の算出について説明する。本実施形態では、事前に設定されたルールに従って、複数のユーザが一台の車両に同乗した場合における好ましさを、各ユーザの属性に基づいて算出する。ここでは、ユーザの属性として、「性別」「年齢」「言語」「出身」の４つを例に説明する。
【００５２】
ライドシェア車両を運行する場合、乗車中のユーザの性別が、全員同一であるか、半々程度となることが好ましい。
ここで、第一の評価関数ｆ1を考える。当該関数は、性別のリストを引数に与えた場合
の好ましさを返す関数である。当該関数は、性別に偏りが無いほど高い値を返す（すなわち、性別が１：１に近いほど高い値を返す。ただし、どちらかの性別が０人である場合に最も高い値を返す）関数である。
【００５３】
また、ライドシェア車両を運行する場合、乗車中のユーザの年齢，言語，出身等が類似していることが好ましい。
ここで、第二の評価関数ｆ2を考える。当該関数は、年齢，言語，出身地のリストを引
数に与えた場合の好ましさを返す関数である。当該関数は、値に偏りがあるほど高い値を返す関数である。
【００５４】
ここで、性別を評価関数ｆ1によって評価した結果と、年齢，言語，出身地をそれぞれ
評価関数ｆ2によって評価した結果を合計することで、複数のユーザが同乗した車両に対
する好ましさを算出することができる。
【００５５】
このようにして算出した値（以下、属性評価値）は、ある一時点における好ましさを表すものであるが、オンデマンド型のライドシェア形態では、各ユーザが乗車する時間がまちまちであるため、一時点における属性評価値で全体的な好ましさを評価することは適切ではない。
【００５６】
そこで、本実施形態では、算出した属性評価値に、「複数のユーザが同乗する時間」を加味して総合的な評価値（以下、総合評価値）を算出し、当該総合評価値に基づいて、乗車リクエストを送信したユーザに対する応答方針を決定する。すなわち、ユーザの属性に基づく「好ましい状態」がより長く継続するほど、より好ましいものと評価する。
【００５７】
図６は、複数のユーザがそれぞれライドシェア車両に乗車する時間を示したタイムチャートである。ここで、時刻１〜２間における総合評価値は、ユーザＡおよびＢの属性によって算出された属性評価値に、期間７０１の長さを加味することで算出できる。また、時刻２〜３間における総合評価値は、ユーザＡ，Ｂ，Ｃの属性によって算出された属性評価値に、期間７０２の長さを加味することで算出できる。時刻３〜４，４〜５，５〜６についても同様である。なお、連続したタイムステップに対して総合評価値を算出したい場合、各期間について算出した値を積算してもよい。
また、乗車希望ユーザを新たに乗車させる場合、既に乗車している複数のユーザに、乗車希望ユーザを加えたユーザグループを対象に評価を行えばよい。
【００５８】
ライドシェア管理部２０２２は、乗車希望ユーザから乗車リクエストを受信した場合に、複数の応答方針を生成し、前述した総合評価値の算出を、全ての応答方針について実行したうえで、最も評価値が高い応答方針を採用する。
例えば、ある応答方針に沿って乗車希望ユーザを乗車させた場合における、当該乗車希望ユーザの乗車時間帯（図６における破線）を判定し、前述した方法によって、所定の範囲（例えば、時刻１〜６まで）における総合評価値を算出する。なお、総合評価値を算出する範囲は、任意に設定してよい。例えば、「現在時刻から乗車希望ユーザが降車する時刻まで」としてもよいし、「現在時刻からｎ分後まで」としてもよい。
【００５９】
具体的なフローについて説明する。
乗車希望ユーザが乗車リクエストを送信すると、サーバ装置２００（ライドシェア管理部２０２２）がこれを取得し、乗車希望地点、降車希望地点、乗車希望時刻を取得する。図７は、ライドシェア管理部２０２２が乗車リクエストを取得した場合に実行される処理のフローチャートである。
【００６０】
まず、ステップＳ１１で、車両情報管理部２０２１によって管理されている、ライドシェア車両の位置情報や経路情報を参照し、乗車リクエストに対応可能なライドシェア車両があるか否かを判定する。本ステップでは、例えば、以下のような判断基準によって、乗車リクエストに対応可能なライドシェア車両があるか否かを判定する。
【００６１】
（１）乗車希望時刻を含む所定の時間範囲内に迎車が可能か
移動のスケジュールが乗車希望ユーザと適合しない場合、ライドシェア車両として不適格であるためである。
（２）乗車希望地点および降車希望地点にどれだけ接近できるか
例えば、既に他のユーザがライドシェア車両に乗車しており、対象車両の走行経路が既に決まっている場合、乗車希望ユーザを迎えに行くために経路を大きく逸脱すると他のメンバに影響するためである。
【００６２】
ステップＳ１１で肯定判定となった場合、対応可能なライドシェア車両のうちの一台を
（例えば、距離が近い順に）選択し、選択した車両について、応答方針の候補を複数個生成する。応答方針は、例えば、以下のような方法によって決定することができる（ステップＳ１２）。
【００６３】
（１）運行コストを最小化する方法によって乗車リクエストに応答する
例えば、対象ライドシェア車両の走行経路が既に決まっている場合、当該経路からの逸脱が最小になるような経路で、ユーザを迎えに行くといった方法である。
（２）ユーザの乗降タイミングを前後させる方法によって乗車リクエストに応答する
例えば、同乗者の降車地点が近い場合、当該同乗者を降車させることを優先し、その後、乗車希望ユーザを迎えに行くといった方法である。このように、同乗者のスケジュールを優先させてもよい。この他にも、乗車希望ユーザが二人以上いる場合、それぞれの乗車タイミングを入れ替えてもよい。例えば、より早く予約を行った乗車希望ユーザを（距離に関係なく）先にピックアップしてもよい。
（３）乗車リクエストに応答しない
リクエストを辞退するという応答方針も生成されうる。
なお、同時に複数の乗車希望ユーザから複数の乗車リクエストを受信した場合、考えられる全てのパターンを生成してもよい。
【００６４】
次に、ステップＳ１３で、複数の応答方針のそれぞれについて、図６を参照して説明した方法によって、総合評価値を算出する。
そして、ステップＳ１４で、乗車リクエストを受諾可能な（すなわち、乗車希望ユーザを乗車させられる）応答方針があるか否かを判定する。具体的には、各応答方針について算出された総合評価値を所定の閾値と比較し、評価値が当該閾値を上回る応答方針を選択する。もし、評価値が当該閾値を上回る応答方針が存在しない場合、ステップＳ１４は否定判定となる。また、乗車リクエストに応答しないという応答方針のみが残った場合も、ステップＳ１４は否定判定となる。
【００６５】
ステップＳ１４で否定判定となった場合、処理はステップＳ１１へ戻り、他のライドシェア車両について検討を行う。この結果、対応可能なライドシェア車両が存在しない場合、処理はステップＳ１６へ遷移し、乗車リクエストを受諾しないことを決定する。
ステップＳ１４で肯定判定となった場合、処理はステップＳ１５へ遷移し、乗車リクエストを受諾することを決定する。この場合、決定された応答方針がライドシェア管理部２０２２から運行指令生成部２０２３へ送信され、乗車希望ユーザを乗車させるための運行指令が生成される。
【００６６】
次に、システムを構成する各要素が行う処理について説明する。図８は、ユーザから送信された乗車リクエストに基づいてサーバ装置２００が運行指令を生成し、自律走行車両１００が運行を開始するまでのデータフローを説明する図である。
【００６７】
自律走行車両１００は、サーバ装置２００に対して周期的に位置情報、経路情報、イベント情報を送信する。なお、位置情報および経路情報は、時間の経過に伴って都度送信される。また、イベント情報は、イベントの発生（例えば、ユーザの乗降等）をトリガとして送信される。
これらの情報を受信した車両情報管理部２０２１は、受信した情報を、自律走行車両１００の識別子と関連付けて記憶部２０３に記憶させる。なお、位置情報は、必ずしもノード自体の位置情報でなくてもよい。例えば、ノードやリンクを特定するための情報であってもよい。また、リンクを複数の区間に分割してもよい。また、道路ネットワークは必ずしもノードとリンクによって表されたものでなくてもよい。
【００６８】
利用者が、サーバ装置２００に対して乗車リクエストを送信すると（ステップＳ２１）
、サーバ装置２００（ライドシェア管理部２０２２）が、乗車リクエストと、記憶されている乗車データおよびユーザ属性データに基づいて、前述した方法によって応答方針を生成する（ステップＳ２２）。そして、運行指令生成部２０２３が、応答方針に基づいて運行指令を生成する（ステップＳ２３）。運行指令は、例えば、乗車希望ユーザに関する情報、当該ユーザが自律走行車両１００に乗車する地点、および、降車する地点などを含む。
ステップＳ２４では、運行指令生成部２０２３が、対象の自律走行車両１００へ運行指令を送信する。また、ライドシェア管理部２０２２が、乗車希望ユーザに対して、乗車の可否、乗車地点、降車地点、到着予定時刻などを含む応答を送信する。
【００６９】
ステップＳ２５では、自律走行車両１００（運行計画生成部１０３１）が、受信した運行指令に基づいて運行計画を生成する。例えば、当該自律走行車両１００が運行中でない場合、乗車希望ユーザを所定の乗車地点で乗車させ、所定の降車地点で降車させる旨の運行計画を生成する。また、当該自律走行車両１００が運行中である場合、乗車希望ユーザを乗車および降車させるよう、既に決定された運行計画を修正する。生成ないし修正された運行計画は走行制御部１０３３へ送信される。
【００７０】
以上に説明したように、本実施形態に係る移動体システムは、ユーザの属性に加え、ユーザグループが維持される時間によって、当該ユーザグループに対する好ましさを算出する。これにより、メンバが頻繁に入れ替わるライドシェア形態においても、全体的な好ましさを評価することができる。
【００７１】
（第二の実施形態）
第一の実施形態では、乗車希望ユーザがサーバ装置２００に乗車リクエストを送信し、これに対応してサーバ装置２００が応答方針を決定した。これに対し、第二の実施形態は、潜在的なユーザを予めサーバ装置２００に登録しておき、あるライドシェア車両について評価値が閾値を下回った場合に、当該潜在ユーザに対して乗車を打診する実施形態である。
第二の実施形態は、ライドシェア車両を用いてユーザ間の交流を促進するイベント形態に好適に適用できる。
【００７２】
図９は、第二の実施形態において、サーバ装置２００（ライドシェア管理部２０２２）が実行する処理のフローチャートである。当該処理は、あるライドシェア車両についてイベント（典型的にはユーザの降車）が発生したタイミングで実行される。
【００７３】
まず、ステップＳ３１で、対象のライドシェア車両について、イベント発生後（例えば、ユーザの降車後）における総合評価値を再計算する。
ここで、算出した総合評価値が所定の閾値を下回った場合（ステップＳ３２−Ｙｅｓ）、処理はステップＳ３３へ遷移し、潜在ユーザが存在するか否かを判定する。
【００７４】
潜在ユーザとは、ライドシェア車両を利用してもよい旨の意思表示を事前に行っているユーザである。潜在ユーザに関する情報（ユーザＩＤ，乗降可能な地点またはエリア，乗車可能な時間帯等）は、ライドシェア管理部２０２２に予め登録される。
ステップＳ３３では、例えば、対象のライドシェア車両の近傍（所定の範囲内）に存在し、所定の時間内に乗車が可能な潜在ユーザを抽出する。
ここで、潜在ユーザが存在する場合、ステップＳ３４へ遷移し、当該潜在ユーザを乗車させた場合における総合評価値を算出する。
この結果、総合評価値が所定の閾値を上回った場合（ステップＳ３５−Ｙｅｓ）、当該潜在ユーザに対して乗車を打診する（ステップＳ３６）。例えば、潜在ユーザに関連付いた端末へメッセージを送信し、回答を要求する。
【００７５】
ここで、乗車が受諾されると（ステップＳ３７−Ｙｅｓ）、運行指令生成部２０２３が、当該潜在ユーザを乗車させるための運行指令を生成し、生成した運行指令を、対応する自律走行車両１００に送信する。乗車が受諾されなかった場合（ステップＳ３７−Ｎｏ）や、潜在ユーザを乗車させても総合評価値が閾値を上回らない場合（ステップＳ３５−Ｎｏ）、処理はステップＳ３３へ戻り、他の潜在ユーザを検索する。
【００７６】
以上説明したように、第二の実施形態によると、ユーザの乗降に伴って、ライドシェア車両における総合評価値が低下した場合に、当該評価値を上昇させるための策を講ずることができる。例えば、男女の親睦を深めるイベント形態において、男女比が偏った場合などにおいて、これを補完することができる。
【００７７】
（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【００７８】
また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。
【００７９】
本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。
【符号の説明】
【００８０】
１００・・・自律走行車両
１０１・・・センサ
１０２・・・位置情報取得部
１０３・・・制御部
１０４・・・駆動部
１０５，２０１・・・通信部
１０６・・・画像出力部
２００・・・サーバ装置
２０２・・・制御部
２０３・・・記憶部
【図１】
2020107215.tif 000003
【図２】
2020107215.tif 000004
【図３】
2020107215.tif 000005
【図４】
2020107215.tif 000006
【図５】
2020107215.tif 000007
【図６】
2020107215.tif 000008
【図７】
2020107215.tif 000009
【図８】
2020107215.tif 000010
【図９】
2020107215.tif 000011