JP2024027227A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】適切な車両を供給する。【解決手段】所定のサービスを提供する複数の車両を監視し、前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定し、前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定し、配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示する。【選択図】図１

Description

本開示は、車両によるサービスの提供に関する。

利用者の需要に応じて車両（例えば、旅客輸送を行う車両）の配車を行うシステムが知られている。これに関し、例えば、特許文献１には、輸送サービスが提供されるエリア内において車両の不足が発生した場合に、他のエリアから車両を回送させ、補充するシステムが開示されている。

特開２０２０－０８６９４５号公報

本開示は、適切な車両を供給することを目的とする。

本開示の実施形態の一態様は、
所定のサービスを提供する複数の車両を監視することと、前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定することと、前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定することと、配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示することと、を実行する制御部を有する、情報処理装置である。

本開示の実施形態の一態様は、
所定のサービスを提供する複数の車両を監視するステップと、前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定するステップと、前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定するステップと、配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示するステップと、を含む、情報処理方法である。

また、他の態様として、上記の方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本開示によれば、適切な車両を供給することができる。

第一の実施形態に係る車両システムの概要図。 ユーザ装置の構成要素を示した図。 ユーザ装置から送信されるサービスリクエストの一例。 管制サーバの構成要素を示した図。 車両の運行スケジュールを説明するための図。 需要データおよび拠点データを説明するための図。 管制サーバが収集する車両データの一例。 車両１０に運行を指令する処理の流れを示した図。 管制サーバが生成する運行指令の一例。 車両の再配置を説明するための図。 再配置の対象車両に対して運行を指示する処理の流れを示した図。 車載装置の構成要素を示した図。 車両データを送受信する処理のシーケンス図。 サービスリクエストに基づいて車両の運行を指示する処理のシーケンス図。 管制サーバが行う再配置処理のフローチャート。 第二の実施形態における管制サーバの構成要素を示した図。 再配置部が実行する処理のフローチャート。

利用者からのリクエストに基づいて車両を運行するオンデマンド車両システムが知られている。斯様なシステムでは、複数の車両の運行スケジュールを管理するサーバ装置が、利用者からのリクエストに基づいて、車両の割り当てや運行の指令を行う。

通常、サービスに供される車両は、所定の車両拠点において待機しており、リクエストに応じて運行される。しかし、エリアや時間帯などによっては、車両に対する需要が一時的に高まる場合があり、かかる場合、サービスを提供できる車両が車両拠点に存在しなくなる場合がある。
これに対応するため、拠点間における車両の偏りを解消するための試みが行われている。例えば、あるエリアにおいて、ある時間帯に需要が高まることが予測される場合、予め、当該エリア内の車両拠点に車両を多く集めておくといった対応を取ることができる。

しかし、車両によって提供されるサービスが複数ある場合、単に車両を集めるだけでは、利用者が所望するサービスを提供できないケースが発生しうる。
例えば、自動運転車両によって、移動店舗サービス、旅客輸送サービス、または荷物輸送サービスといった複数のサービスを選択的に提供する形態が考えられる。かかる形態において、ある時期に旅客輸送に対する需要が高まることが推定される場合、移動店舗車両が利用可能であっても、「旅客輸送」というサービスを提供することはできない。
この問題を解決するためには、車両が持っている属性を考慮して、拠点間における車両の配置を調整する必要がある。

本開示の第一の態様に係る情報処理装置は、所定のサービスを提供する複数の車両を監視することと、前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定することと、前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定することと、配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示することと、を実行する制御部を有する。

所定のサービスとは、例えば、旅客輸送サービス、荷物輸送サービス、荷物保管サービス、および移動店舗サービスなど、複数のサービスを含むことができる。
制御部は、複数の車両を監視し、その待機状況に基づいて、車両の再配置を行うための計画を生成する。所定の属性とは、ある車両拠点に配置されることが好ましい車両の属性である。

車両の監視は、例えば、車両から送信されたデータに基づいて行ってもよいし、当該車両に対して発行された指令に基づいて行ってもよい。また、車両拠点に設けられたセンサ等によって行ってもよい。
制御部は、例えば、「複数の車両拠点における車両の台数が増減したこと」等を判定することで車両の待機状況の変化を検知し、これをトリガとして、再配置計画を生成する処理を実行する。
なお、上記のトリガは一例であり、これ以外のイベントをトリガとすることもできる。これにより、所定の属性を有する車両が、所定の車両拠点に配置されるように車両を回送させることができる。

車両拠点と所定の属性との関係は、利用者（消費者）による需要に基づいて決定されてもよい。例えば、あるエリアにおいて、旅客輸送の需要が増大すると見込まれる場合、当該エリアの近傍にある車両拠点に、旅客輸送に関する属性を持つ車両を多く配置することを決定してもよい。制御部は、複数の車両拠点のそれぞれについて、一つ以上の所定の属性を決定してもよい。

車両拠点ごとの所定の属性は、消費者の需要に少なくとも基づいて決定されてもよい。例えば、制御部は、車両が有する属性ごとの需要を、複数のエリアのそれぞれについて表した需要データを取得してもよい。需要データは、外部装置から取得されてもよいし、車両によるサービスの利用実績に基づいて生成されてもよい。

また、制御部は、複数の車両拠点のそれぞれを、複数のエリアのいずれかと対応付けてもよい。これにより、あるエリアで発生する需要に対応するために、どの車両拠点に車両を配置すべきかを決定することができる。

また、所定の車両拠点に対応する所定の属性は二つ以上であってもよい。この場合、制御部は、属性ごとの優先度に基づいて、移動を指示する車両を決定してもよい。

以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。

（第一の実施形態）
第一の実施形態に係る車両システムの概要について、図１を参照しながら説明する。本実施形態に係る車両システムは、車載装置３００が搭載された車両１０と、ユーザ装置１００と、管制サーバ２００とを含んで構成される。システムに含まれる車両１０（車載装置３００）は複数であってもよい。

車両１０は、消費者に対して所定のサービスを提供可能な自律走行車両である。所定のサービスとして、例えば、旅客輸送、荷物輸送、荷物保管、移動店舗の提供、ワーキングスペースの提供、および就寝スペースの提供などが例示できる。車両１０は、車載装置３００を介して、管制サーバ２００と無線通信可能に構成され、管制サーバ２００からの指示に基づいて自律的に運行される。

車両１０によるサービスの利用を希望する利用者は、ユーザ装置１００を介して、サービスリクエストを管制サーバ２００に送信する。サービスリクエストは、例えば、希望するサービスのタイプ（例えば「タクシー」）、車両１０の派遣を希望する地点および時刻、目的地（輸送サービスを希望する場合）、商品名（店舗サービスを希望する場合）などを含む。

これらの情報は、例えば、ユーザ装置１００にインストールされた、車両システムを利用するためのアプリケーションソフトウェアによって生成および送信されることができる。これらの情報は、携帯端末を利用して生成されてもよいし、ネットワークに接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、またはウェアラブルコンピュータ等）やパーソナルコンピュータを利用して生成されてもよい。

管制サーバ２００は、ユーザ装置１００から送信されたサービスリクエストに基づいて、車両１０の運行スケジュールを生成する。管制サーバ２００は、複数の車両１０の運行スケジュールを管理するためのデータベースを有しており、車両１０の運行スケジュールが更新された場合に、管制サーバ２００は、当該データベースを更新する。

さらに、管制サーバ２００は、更新後の運行スケジュールに基づいて、各車両に運行を指令するためのデータ（以下、運行指令）を、対象の車両１０（車載装置３００）に送信する。運行指令は、例えば、「所定の地点Ａまで走行し」、「利用者を乗車させ」、「所定の地点Ｂまで走行し」、「利用者を降車させ」、「車両拠点に帰還する」といったように、複数のタスクを車両１０に指示するデータである。

車載装置３００は、管制サーバ２００から運行指令を受信する。車両１０が自律走行車両である場合、当該運行指令は、車両１０に搭載された、自律走行を制御する装置に送信される。なお、車両１０は有人車両であってもよい。この場合、運行指令は、車載装置３００を介して乗務員に提供される。

本実施形態に係る車両システムにおいては、複数のユーザ装置１００、管制サーバ２００、および、車載装置３００が、ネットワークによって相互に接続される。ネットワークには、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークは、携帯電話等の電話通信網、Ｗｉ－Ｆｉ（登録商標）等の無線通信網を含んでもよい。

システムを構成する各要素について説明する。
図２は、ユーザ装置１００のシステム構成を示した図である。
ユーザ装置１００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、またはウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ装置１００は、制御部１０１、記憶部１０２、通信部１０３、入出力部１０４、および位置情報取得部１０５を含んで構成される。

制御部１０１は、ユーザ装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部１０１は、機能モジュールとして、リクエスト部１０１１を有して構成される。当該機能モジュールは、後述する記憶部１０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

リクエスト部１０１１は、装置の利用者から、車両によるサービスの提供をリクエストするために必要な情報を取得し、当該情報を含むサービスリクエストを管制サーバ２００に送信する。
サービスリクエストは、希望するサービスのタイプ、および、サービス内容等を含む。例えば、希望するサービスが旅客輸送サービスである場合、サービス内容として、乗車希望地点、乗車希望時刻、降車希望地点などが例示できる。また、希望するサービスが移動
販売サービスである場合、サービス内容として、購入を希望する商品の種別、識別子、および数量などが例示できる。サービス内容は、サービスのタイプによって異なりうる。
リクエスト部１０１１は、後述する入出力部１０４を介して、これらの情報を取得する。取得された情報は、サービスリクエストとして管制サーバ２００へ送信される。図３は、リクエスト部１０１１によって生成されたサービスリクエストの一例である。また、リクエスト部１０１１は、管制サーバ２００と対話することで、車両１０の予約を確定させる処理を行う。

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

通信部１０３は、ユーザ装置１００をネットワークに接続するための無線通信インタフェースである。通信部１０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ等の移動体通信サービスを介して、ネットワークへのアクセスを提供する。
入出力部１０４は、装置の利用者が行った入力操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

次に、管制サーバ２００の構成について説明する。
管制サーバ２００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。なお、管制サーバ２００は、単一のコンピュータで構成されてもよいし、互いに連携する複数台のコンピュータによって構成されてもよい。

図４は、管制サーバ２００のシステム構成を示した図である。管制サーバ２００は、制御部２０１、記憶部２０２、および通信部２０３を含んで構成される。

制御部２０１は、管制サーバ２００が行う制御を司る演算装置である。制御部２０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部２０１は、車両管理部２０１１、計画生成部２０１２、および、再配置部２０１３の三種類の機能モジュールを有して構成される。各機能モジュールは、補助記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

車両管理部２０１１は、車両１０（車載装置３００）から受信したデータに基づいて、複数の車両１０を管理するためのデータを更新する。本実施形態では、複数の車両１０を管理するためのデータとして、車両データを例示する。車両データとは、車両１０から受信した、車両１０の現在の状況を表すデータである（記憶部２０２の説明において後述）。

計画生成部２０１２は、ユーザ装置１００から受信したサービスリクエストに基づいて、車両１０の運行スケジュールを管理するためのデータを更新する。本実施形態では、車両１０の運行スケジュールを管理するためのデータとして、運行データを例示する。運行データとは、複数の車両１０の運行スケジュールの集合である（記憶部２０２の説明において後述）。
具体的には、計画生成部２０１２は、サービスリクエストが送信された場合に、車両ごとの運行スケジュールを参照して、サービスを提供する車両１０を決定し、当該車両の運行スケジュールを更新する。運行スケジュールが決定すると、計画生成部２０１２は、運行スケジュールに沿って車両１０を運行させるための運行指令を生成し、対象の車両１０に送信する。
なお、計画生成部２０１２は、既定の運行スケジュールと、車両１０から受信したデータに基づいて、特定の車両１０の運行に遅延等が生じていることを判定し、運行スケジュールの再生成等を行うこともできる。

一方、サービスリクエストに応答して複数の車両１０を運行させ続けると、複数の車両１０の配置が偏ってしまう場合がある。例えば、帰宅時間帯においては、鉄道駅の周辺において、旅客輸送を行う車両の需要が高まることが考えられるが、駅を出発地とする輸送が多く行われた結果、駅の周辺から、旅客輸送が可能な車両１０が無くなってしまう場合がある。かかる場合、駅の周辺に、その他の機能を有する車両１０（例えば、移動店舗車両）が存在する場合であっても、所望のサービスを提供することができなくなってしまう。
再配置部２０１３は、これに対応するため、エリアごとの需要、および、車両１０の属性に基づいて、車両１０の再配置を行う。再配置とは、所定の属性を有する車両を、所定の車両拠点に回送させることを指す。再配置部２０１３は、いずれかの車両拠点に車両１０が出入りするタイミングで、車両１０の回送計画を生成し、対象の車両１０に対して、車両拠点間の移動を指示する。

記憶部２０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部２０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部２０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。
記憶部２０２には、運行データ２０２Ａ、需要データ２０２Ｂ、拠点データ２０２Ｃ、および、車両データ２０２Ｄが記憶される。

運行データ２０２Ａは、複数の車両１０の運行スケジュールを記録するデータである。図５は、運行データ２０２Ａによって表される、ある車両１０の運行スケジュールを表した図である。
図５（Ａ）は、車両１０について、運行スケジュールが入っていない状態を示した図である。この場合、車両１０は、所定の車両拠点において待機状態となる。
図５（Ｂ）は、輸送サービスをリクエストするサービスリクエストに基づいて更新された運行スケジュールの一例である。本例において、車両１０は、時刻Ｔ１に車両拠点から出庫し、指定された地点へ向かう。また、時刻Ｔ２において利用者をピックアップし、輸送サービスを提供する。サービスの提供が終了すると、車両１０は、車両拠点へ戻り、時刻Ｔ３から充電を開始する。時刻Ｔ４において充電が終了すると、再び待機状態となり、
別のリクエストに応答可能な状態になる。

なお、車両１０が出発する車両拠点と、当該車両１０が帰還する車両拠点は異なってもよい。車両１０が帰還する車両拠点は、例えば、サービスの提供を終了した地点からの距離や、当該車両拠点における満空情報に基づいて動的に決定されてもよい。

なお、運行データ２０２Ａは、将来における、予定された運行スケジュールを表すものであってもよいし、過去の運行の実績を表すものであってもよい。例えば、図５（Ｃ）におけるハッチングは、既に完了したタスクを表している。
どのタスクが完了したかは、車両１０（車載装置３００）から受信した車両データに基づいて判別することができる。

需要データ２０２Ｂは、サービスを提供しているエリア内において、どのような需要が発生するかを定義したデータである。
拠点データ２０２Ｃは、エリアと車両拠点との関係を定義したデータである。拠点データ２０２Ｃには、エリアがどのように分割されており、その中のどこに車両拠点が存在するかを示すデータが含まれる。拠点データ２０２Ｃは、エリアと車両拠点との位置関係を定義したデータと言い換えることもできる。

図６は、需要データ２０２Ｂおよび拠点データ２０２Ｃを説明するための図である。本例では、エリアを９つに分割している。図示したように、拠点データ２０２Ｃには、複数のエリアおよび複数の車両拠点の位置が定義されている。なお、拠点データ２０２Ｃに定義された複数の車両拠点は、エリアごとにグルーピングされていてもよい。

また、需要データ２０２Ｂには、エリアごとの需要が定義されている。
例えば、エリアＡ３が、自動運転車両による旅客輸送が法的に許可されたエリアである場合、エリアＡ３内に位置する車両拠点ＤおよびＥには、自動運転車両を配置することが好ましい。また、エリアＡ３において、高齢者が多く居住している場合、エリアＡ３内に位置する車両拠点ＤおよびＥには、バリアフリー車両を多く配置することが好ましい。
このように、需要データ２０２Ｂは、「複数のエリアのそれぞれにおいて、どのような特徴（属性）を持つ車両１０に対して需要があるか」を表したデータである。
なお、需要データ２０２Ｂは、時間帯、曜日、日付ごとに定義されていてもよい。また、同じエリアにおいて、複数タイプの車両に需要がある場合、属性ごとに優先度を付与してもよい。

車両データ２０２Ｄは、車両１０（車載装置３００）から受信した、車両データの集合である。前述したように、車両データは、車両１０の現在の状況を表すデータである。
図７は、車両データの一例である。車両データは、車両１０の識別子、日時情報、車両１０の位置情報、および、タスクの処理状態を表すデータ（例えば、与えられた複数のタスクのうち、どれが完了したか、または、現在どれを実行中であるか）を含む。タスクの処理状態を表すデータは、予定されたスケジュールからの遅延時間を含んでいてもよい。

通信部２０３は、管制サーバ２００をネットワークに接続するための通信インタフェースである。通信部２０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

ここで、前述した、車両管理部２０１１、計画生成部２０１２、および、再配置部２０１３が実行する処理の流れについて、より詳しく説明する。

図８は、サービスリクエストに基づいて、車両１０の運行スケジュールを決定し、当該
車両１０に運行を指令する処理の流れを示した図である。
計画生成部２０１２は、ユーザ装置１００から受信したサービスリクエストに基づいて、サービスを提供する車両１０を決定する。サービスを提供する車両１０は、運行データ２０２Ａに基づいて決定することができる。例えば、リクエストされたサービスが輸送サービスである場合、計画生成部２０１２は、「車両拠点から指定された地点へ向かい、輸送サービスを提供し、再び車両拠点に戻り、充電を行う」といった一連のタスクを割り当てることが可能な車両１０を決定する。
一連のタスクを割り当てることができる場合、図５（Ａ）に示したスケジュールが、図５（Ｂ）のように更新される。スケジュールが決定すると、計画生成部２０１２は、対応する運行指令を生成し、当該運行指令を、対象である車両１０に搭載された車載装置３００へ送信する。

図９は、運行指令の一例である。運行指令は、図示したように、車両１０が実行すべき複数のタスクを含む。各タスクには、予定時刻や、デッドライン時刻が関連付いていてもよい。

図８に戻り、説明を続ける。
計画生成部２０１２は、車両１０（車載装置３００）から車両データを周期的に受信し、これに基づいて、運行データ２０２Ａを更新する。
具体的には、計画生成部２０１２は、既に完了したタスクを運行データ２０２Ａに反映する処理を実行する。これにより、図５（Ｂ）に示したスケジュールが、図５（Ｃ）のように更新される。

また、計画生成部２０１２は、車両１０のスケジュールが遅延していることを検出し、当該車両１０の運行をリスケジュールする処理を実行する。
例えば、図５（Ｃ）のケースにおいて、サービス提供（すなわち、旅客輸送）が予定より１０分遅延しているものとする。スケジュールが遅延していることは、例えば、車両データに含まれる、タスクの処理状態に基づいて判定することができる。この場合、車両拠点に帰還し、待機状態となるタイミングが１０分遅くなる。よって、計画生成部２０１２は、図５（Ｄ）に示したように、運行スケジュールを再生成することができる。
なお、後続するスケジュールが存在しており、リスケジュールが不可能な場合、計画生成部２０１２は、その旨の通知をシステムの管理者に送信してもよい。

次に、再配置部２０１３が、車両１０の属性に基づいて、複数の車両１０の再配置を行う処理について、より詳しく説明する。図１０は、複数の車両拠点間における車両１０の再配置を説明する図である。
本実施形態では、ある車両拠点に対して車両１０が入庫したタイミング、および、当該車両拠点から車両１０が出庫したタイミングで、車両１０の再配置を実行する。ここでは、車両拠点Ｄから、車両１０が、サービス提供のために１台出発したものとする。

再配置部２０１３は、車両拠点Ｄから、車両１０が出庫したことを検出すると、当該車両拠点の空いた駐車スペースに、どのような属性の車両を（他の車両拠点から）移動させるかを決定し、対象の車両１０に対して移動を指令する。
なお、車両１０が出庫または入庫したことは、車両１０から送信される車両データに基づいて判定してもよいし、車両１０に対して発行された運行指令に基づいて推定してもよい。また、車両１０が出庫または入庫したことは、各車両拠点に設けられたセンサから送信されたセンサデータに基づいて判定することもできる。

本例では、車両拠点Ｄがあるエリアにおいて、「バリアフリー車両」「旅客輸送車両」「自動運転車両」の順で需要が高いものとする。
この場合、再配置部２０１３は、「バリアフリー車両」「旅客輸送車両」「自動運転車両」の優先度で、他の車両拠点から移動可能な車両１０が無いか判定し、移動可能な車両１０がある場合に、当該車両に対して、車両拠点Ｄへの移動を指示する。これにより、周辺エリアにおいて需要が高い属性を持つ車両１０を車両拠点Ｄに配置することが可能になる。

図１１は、再配置部２０１３が、再配置の対象車両に対して運行を指示する処理の流れを示した図である。
再配置部２０１３は、需要データ２０２Ｂと、拠点データ２０２Ｃに基づいて、どの車両拠点に、どの属性を持つ車両１０を配置すべきかを判定する。例えば、あるエリアにおいて需要が高い車両属性があった場合、当該エリア内にある車両拠点（または、当該エリアから所定の距離以内にある車両拠点）に、当該属性を持つ車両１０を配置すべきであると判定する。
そして、再配置部２０１３は、運行データ２０２Ａを参照し、移動対象である車両１０を決定し、当該車両１０に対して運行指令を送信する。

次に、車載装置３００の構成について説明する。
車載装置３００は、車両１０に搭載されたコンピュータである。車載装置３００は、管制サーバ２００と通信することで、運行に関する情報のやり取りを行う。
車載装置３００は、車両１０の乗員または乗客に情報を提供する装置を兼ねていてもよい。また、車載装置３００は、車両プラットフォームが有する電子制御ユニット（ＥＣＵ）であってもよい。また、車載装置３００は、通信機能を有するデータコミュニケーションモジュール（ＤＣＭ）であってもよい。
車載装置３００は、外部ネットワークと無線通信を行う機能を有する。車載装置３００は、外部ネットワークと通信することで、交通情報や道路地図データなどをダウンロードする機能を有していてもよい。

車載装置３００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

図１２は、車載装置３００の構成要素を詳細に示した図である。
車載装置３００は、制御部３０１、記憶部３０２、通信部３０３、および、入出力部３０４を有して構成される。

制御部３０１は、所定のプログラムを実行することで、車載装置３００の各種機能を実現する演算ユニットである。制御部３０１は、例えば、ＣＰＵ等によって実現されてもよい。制御部３０１は、記憶されたプログラムをＣＰＵによって実行することでその機能を実現してもよい。

制御部３０１は、所定のタイミングで、車両１０の運行に関するデータ（車両データ）を取得ないし生成し、管制サーバ２００に送信する。車両データは、例えば、位置情報や、タスクの処理状態などを含む。また、制御部３０１は、ＧＰＳモジュール等を介して位置情報を取得する機能を有している。

記憶部３０２は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモ
リなどの記憶媒体により構成される。記憶部３０２には、制御部３０１にて実行される各種プログラム、当該プログラムが利用するデータ等が記憶される。

通信部３０３は、無線通信を行うためのアンテナと通信モジュールを含む。アンテナは、無線信号の入出力を行うアンテナ素子である。本実施形態では、アンテナは、移動体通信（例えば、３Ｇ、ＬＴＥ、５Ｇ等の移動体通信）に適合したものである。なお、アンテナは、複数の物理的なアンテナを含んで構成されてもよい。例えば、マイクロ波やミリ波などの高周波帯の電波を利用した移動体通信を行う場合、通信の安定化を図るため、複数のアンテナを分散して配置してもよい。通信モジュールは、移動体通信を行うためのモジュールである。

入出力部３０４は、入力された操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

なお、図２、図４、および図１２に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

次に、各装置が実行する処理について説明する。
図１３は、車載装置３００および管制サーバ２００が車両データを送受信する処理のシーケンス図である。図示した処理は、車両１０の走行中において、制御部３０１によって、所定の周期で繰り返し実行される。

まず、ステップＳ１１で、車載装置３００が、所定の送信周期が到来したか否かを判定する。所定の周期（例えば、１分ごと）が到来した場合、処理はステップＳ１２へ遷移する。所定の周期が到来していない場合、所定の時間だけ待機し、処理を繰り返す。
ステップＳ１２では、車載装置３００が、車両データを生成する。生成された車両データは、ステップＳ１３において管制サーバ２００に送信される。
ステップＳ１４では、管制サーバ２００（車両管理部２０１１）が、車載装置３００から送信された車両データを受信し、当該車両データに基づいて、車両１０の運行スケジュール（運行データ２０２Ａ）を更新する。

なお、本例では、所定の周期で車載装置３００が車両データを送信するものとしたが、車両データの送信は、所定のイベントが発生したタイミングでのみ行われてもよい。斯様なタイミングとして、例えば、車両１０が新たなタスクを開始するタイミング、車両１０によって実行中のタスクが完了したタイミング、車両１０が所定のスポットに到着したタイミングなどが例示できる。

図１４は、管制サーバ２００がサービスリクエストを受け付ける処理のシーケンス図である。図示した処理は、利用者の操作に基づいて開始される。

まず、ステップＳ２１で、ユーザ装置１００（リクエスト部１０１１）が、サービスリクエストを生成する。本ステップでは、所定のインタフェースを介して、リクエストするサービスと、その内容に関するデータを利用者に入力させる。
サービスリクエストは、希望するサービスのタイプ、および、サービスの内容等を含む。例えば、希望するサービスが旅客輸送サービスである場合、サービスの内容として、乗車希望地点、乗車希望時刻、降車希望地点などが例示できる。また、希望するサービスが移動販売サービスである場合、サービスの内容として、購入を希望する商品の種別、識別
子、および数量などが例示できる。
リクエスト部１０１１は、生成したサービスリクエストを、管制サーバ２００（計画生成部２０１２）に送信する。

ステップＳ２２では、管制サーバ２００（計画生成部２０１２）が、運行データ２０２Ａに基づいて、サービスを提供する車両１０を決定し、その運行スケジュールを生成する。サービスを提供する車両１０は、リクエストされたサービスを提供するのにかかる時間、および、車両１０の属性に基づいて決定することができる。運行スケジュールが決定すると、計画生成部２０１２は、対応する運行指令を生成し、当該運行指令を、対象である車両１０に搭載された車載装置３００に送信する。また、計画生成部２０１２は、予約結果をユーザ装置１００に送信し、リクエスト部１０１１がこれを出力する（ステップＳ２３）。これにより利用者は、車両１０の予約が成立したことを確認することができる。
また、車載装置３００は、運行指令を、自律走行を制御する装置に送信、または、乗務員に提供する。これにより、車両１０の運行が開始される。

次に、管制サーバ２００（再配置部２０１３）が、複数の車両拠点における複数の車両１０の配置を調整する方法について説明する。
前述したように、本実施形態に係る車両システムでは、サービスリクエストに基づいて車両１０が運行される。なお、サービスを終了した車両１０は、出発した車両拠点に帰還するとは限らない。すなわち、時間が経過すると、車両の配置に偏りが生じる可能性がある。再配置部２０１３は、これを解消するための処理を周期的に実行する。

図１５は、再配置部２０１３が実行する処理のフローチャートである。図示した処理は、複数の車両拠点のうちのいずれかに車両１０が入庫、または、複数の車両拠点のうちのいずれかから車両１０が出庫した場合に実行される。車両１０が車両拠点に入庫、または、車両拠点から出庫したことは、例えば、車載装置３００から受信した車両データに基づいて判定することができる。

まず、ステップＳ３１において、出庫または入庫のどちらが発生したかを判定する。発生したイベントが出庫であった場合、処理はステップＳ３２へ遷移し、発生したイベントが入庫であった場合、処理はステップＳ３５へ遷移する。

ステップＳ３２では、出庫した車両１０の代わりに補充する車両の属性を決定する。どのような属性を持つ車両を補充するかは、以下の処理によって決定することができる。
（１）対象の車両拠点に対応するエリアを特定する
例えば、予め規定された複数のエリアの中から、対象の車両拠点から最も近いエリア（以下、第一のエリア）を特定する。この処理は、エリアと車両拠点との位置関係を定義したデータ（拠点データ２０２Ｃ）に基づいて行うことができる。なお、エリアの特定は、必ずしも直線距離に基づいて行わなくてもよい。
（２）第一のエリアにおける需要に基づいて、車両属性を決定する
例えば、需要データ２０２Ｂを参照し、第一のエリアにおいて、どのような属性を持つ車両の需要が高いかを決定する。なお、ここで決定する需要は一種類でなくてもよい。例えば、バリアフリー車両に対する需要が最も高く、次いで、旅客輸送車両に対する需要が高く、次に、自動運転車両に対する需要が高い、といったことを判定してもよい。

次に、ステップＳ３３で、決定した属性を持つ車両１０を選択する。
本ステップでは、例えば、決定した属性を持つ車両１０が、他の車両拠点から回送できるか否かを判定する。他の車両拠点とは、第一のエリアに対して、処理対象である車両拠点よりも遠い場所にある車両拠点である。処理対象である車両拠点よりも第一のエリアに近い場所に対象車両がある場合、当該車両を回送する利益が無いためである。
ある属性を持つ車両１０を、車両拠点間で回送させることができるか否かは、運行データ２０２Ａに基づいて判定することができる。例えば、ある車両拠点間において移動に１５分かかる場合、決定した属性を持ち、かつ、１５分以上の空きスケジュールがある車両１０を選択する。
なお、ステップＳ３２で決定した属性が二種類以上ある場合、その優先度に基づいて、車両１０の選択を行ってもよい。例えば、最初に、バリアフリー車両の回送を試み、スケジュールが組めない場合、次に、旅客輸送車両の回送を試みてもよい。

ステップＳ３４では、選択した車両１０の運行スケジュールを更新したうえで、車両拠点間を回送させるための運行指令を生成し、当該車両１０に送信する。これにより、対象の車両拠点（すなわち、車両数が１台減った車両拠点）に、所定の属性（近傍のエリアにおいて需要の高い属性）を持つ車両１０を呼び寄せることができる。

ステップＳ３１で発生したイベントが入庫であった場合、処理はステップＳ３５へ遷移する。
ステップＳ３５では、他の車両拠点へ移動可能な車両が存在するか否かを判定する。すなわち、他の車両拠点において需要が高い属性を持つ車両１０を提供可能であるか否かを判定する。

本ステップでは、例えば、対象の車両拠点にて待機中である複数の車両１０のそれぞれについて、「他の車両拠点の近傍エリアで需要が高い属性を持つ車両であるか」、「当該他の車両拠点への回送が可能であるか」判定を行う。当該判定は、運行データ２０２Ａ、需要データ２０２Ｂ、および、拠点データ２０２Ｃに基づいて行うことができる。なお、他の車両拠点に駐車キャパシティがあるか否かは、当該他の車両拠点における満空情報に基づいて決定されてもよい。

ここで、移動可能な車両１０が複数ある場合、回送させる車両１０を優先度に基づいて決定してもよい。優先度は、需要の大きさや、車両拠点間の距離などに基づいて決定してもよい。例えば、より需要が大きい属性を有しており、より回送距離が短い車両１０を選択してもよい。
移動可能な車両１０がある場合、処理はステップＳ３６へ遷移する。移動可能な車両１０が無い場合、処理は終了する。

ステップＳ３６では、移動対象である車両１０の運行スケジュールを更新したうえで、車両拠点間を回送させるための運行指令を生成し、当該車両１０に送信する。これにより、対象の車両拠点に、所定の属性（近傍のエリアにおいて需要の高い属性）を持つ車両１０を送り込むことができる。

図１５に示した処理は、車両拠点に車両１０が入出庫したタイミングで繰り返し実行される。これにより、近傍エリアにおいて需要の高い属性を持つ車両１０を、所定の車両拠点に徐々に集めることが可能になる。

なお、本例では、車両１０の入出庫をトリガとして車両の再配置を行ったが、車両の再配置は、複数の車両拠点における車両１０の待機状況に基づくものであれば、他のタイミングで実行してもよい。
また、本例では、車両１０の移動を１台ずつ行ったが、車両拠点の駐車キャパシティが許せば、複数台をまとめて移動させてもよい。
また、所定のタイミング（例えば、一日に一回、一週間に一回など）において、全ての車両１０について再配置を実行してもよい。

以上説明したように、第一の実施形態に係る車両システムでは、車両１０の属性を考慮して、車両拠点間における車両１０の回送スケジュールを生成する。これにより、所定の車両拠点に、より需要の高い属性を持つ車両１０を集めることが可能になる。

なお、第一の実施形態では、需要データ２０２Ｂは予め定義されたデータであるものとしたが、需要データ２０２Ｂは、外部からの情報に基づいて随時更新されてもよい。この場合、需要データ２０２Ｂが更新されたタイミングで、管制サーバ２００が、複数の車両拠点における車両１０の配置を再決定してもよい。

（第二の実施形態）
第一の実施形態では、予め定義された需要データ２０２Ｂに基づいて、移動させる車両１０の属性を決定した。これに対し、第二の実施形態は、過去に利用者が車両１０によるサービスを受けた履歴に基づいて、需要データ２０２Ｂを生成および更新する実施形態である。

図１６は、第二の実施形態における管制サーバ２００のシステム構成図である。第二の実施形態では、管制サーバ２００は、更新部２０１４をさらに有して構成される。

更新部２０１４は、蓄積された運行データ２０２Ａに基づいて、システムの利用者が過去の所定の期間に受けたサービスに関する履歴を収集し、当該履歴に基づいて、エリアごとの需要データ２０２Ｂを生成する。

図１７は、第二の実施形態において更新部２０１４が実行する処理のフローチャートである。図示した処理は、所定の周期で実行される。
ステップＳ４１およびＳ４２の処理は、システムが対象とする複数のエリアのそれぞれについて実行される。
まず、ステップＳ４１において、過去の所定の期間（例えば１ヶ月）における運行データ２０２Ａを参照し、当該所定の期間において利用された車両１０の属性（サービスタイプ）およびその利用回数を取得する。これにより、対象のエリアにおいて利用された車両の属性についてのランキングを取得することができる。

次に、ステップＳ４２において、属性ごとの利用回数に基づいて、該当するエリアに対応する需要データを生成する。例えば、最も利用回数が多かった属性が「旅客輸送車両」であって、次いで、「バリアフリー車両」、「自動運転車両」であった場合、当該エリアにおいて最も需要が高い属性は旅客輸送車両であると判定することができる。需要データは、需要の高い車両属性をランキング形式で表したものであってもよいし、車両属性ごとに、需要の大きさを表すスコアを関連付けたものであってもよい。需要の大きさを表すスコアは、例えば、過去における車両１０の利用回数に基づいて算出してもよい。

なお、既に需要データ２０２Ｂが生成されている場合、更新部２０１４は、結果を上書きしてもよいし、過去に生成されたスコア等との相加平均等を取り、その結果を新たな需要データ２０２Ｂとしてもよい。

（第二の実施形態の変形例）
第二の実施形態では、更新部２０１４が、過去における車両１０の利用回数に基づいて需要の大きさを判定したが、車両属性ごとの需要の大きさを判定することができれば、他の方法を利用してもよい。例えば、車両１０の属性、エリアの特徴、時間帯、利用回数、利用時間、売上金額などの関係を機械学習モデルによって学習させ、当該機械学習モデルを利用して需要データ２０２Ｂを生成してもよい。
また、当該機械学習モデルに入力されるデータは、車両１０によるサービス提供実績に
関するものでなくてもよい。例えば、エリアごとの消費者に関する統計データ、ユーザ装置１００から発信されたユーザ情報、位置情報または購買情報などであってもよい。

（他の変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、車両が持つ属性として、バリアフリー車両、自動運転車両、旅客輸送車両を例示したが、適切にサービスを提供することができれば、これ以外の属性を持つ車両を配置してもよい。例えば、自動運転に支障が発生しうるエリアが近くにある車両拠点には、手動運転可能な車両を優先的に配置するようにしてもよい。また、ある商品やサービスに対する需要が高いエリアが近くにある車両拠点には、当該商品やサービスを提供可能な移動店舗車両を優先的に配置するようにしてもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１０・・・車両
１００・・ユーザ装置
２００・・・管制サーバ
３００・・・車載装置
１０１，２０１，３０１・・・制御部
１０２，２０２，３０２・・・記憶部
１０３，２０３，３０３・・・通信部
１０４，３０４・・・入出力部
１０５・・・位置情報取得部

Claims (20)

1. 所定のサービスを提供する複数の車両を監視することと、
   前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定することと、
   前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定することと、
   配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示することと、
   を実行する制御部を有する、情報処理装置。
2. 前記待機状況を特定することは、前記監視の結果に基づいて、前記複数の車両のいずれかが、複数の車両拠点のいずれかから出庫したこと、または、前記複数の車両拠点のいずれかに入庫したことを検知することを含み、
   前記制御部は、前記出庫または入庫が検知された場合に、前記再配置計画を決定する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記複数の車両拠点のそれぞれについて、前記所定の属性を決定する、
   請求項２に記載の情報処理装置。
4. 前記制御部は、前記複数の車両拠点のそれぞれに対応する前記所定の属性を、消費者の需要に少なくとも基づいて決定する、
   請求項２に記載の情報処理装置。
5. 前記制御部は、前記消費者の需要を表す需要データを取得する、
   請求項４に記載の情報処理装置。
6. 前記需要データは、前記車両が有する属性ごとの需要を、複数のエリアのそれぞれについて表したデータである、
   請求項５に記載の情報処理装置。
7. 前記複数の車両拠点のそれぞれを、前記複数のエリアのうちのいずれかと対応付けるデータを記憶する記憶部をさらに有し、
   前記制御部は、第一のエリアにおける前記需要データに基づいて、前記第一のエリアに対応する車両拠点に対応する前記所定の属性を決定する、
   請求項６に記載の情報処理装置。
8. 前記需要データは、前記消費者による前記サービスの利用実績に基づいて生成される、
   請求項６に記載の情報処理装置。
9. 前記所定の車両拠点に対応する前記所定の属性が二つ以上である場合に、前記制御部は、属性ごとの優先度に基づいて、前記移動を指示する車両を決定する、
   請求項１から８のいずれか１項に記載の情報処理装置。
10. 前記属性ごとの優先度は、消費者による前記サービスの利用実績に基づいて生成される、
    請求項９に記載の情報処理装置。
11. 所定のサービスを提供する複数の車両を監視するステップと、
    前記監視の結果に基づいて、複数の車両拠点のそれぞれにおける前記複数の車両の待機状況を特定するステップと、
    前記特定された待機状況に基づいて、所定の属性を有する車両が所定の車両拠点に配置されるように、前記複数の車両拠点のいずれかにおいて待機中である一台以上の車両の再配置計画を決定するステップと、
    配置先の車両拠点が第一の車両拠点に変更された車両に対して、前記第一の車両拠点への移動を指示するステップと、
    を含む、情報処理方法。
12. 前記待機状況を特定するステップは、前記監視の結果に基づいて、前記複数の車両のいずれかが、複数の車両拠点のいずれかから出庫したこと、または、前記複数の車両拠点のいずれかに入庫したことを検知するステップを含み、
    前記出庫または入庫が検知された場合に、前記再配置計画を決定する、
    請求項１１に記載の情報処理方法。
13. 前記複数の車両拠点のそれぞれについて、前記所定の属性を決定するステップをさらに含む、
    請求項１２に記載の情報処理方法。
14. 前記複数の車両拠点のそれぞれに対応する前記所定の属性を、消費者の需要に少なくとも基づいて決定する、
    請求項１２に記載の情報処理方法。
15. 前記消費者の需要を表す需要データを取得するステップをさらに含む、
    請求項１４に記載の情報処理方法。
16. 前記需要データは、前記車両が有する属性ごとの需要を、複数のエリアのそれぞれについて表したデータである、
    請求項１５に記載の情報処理方法。
17. 前記複数の車両拠点のそれぞれを、前記複数のエリアのうちのいずれかと対応付けるデータを取得するステップをさらに含み、
    第一のエリアにおける前記需要データに基づいて、前記第一のエリアに対応する車両拠点に対応する前記所定の属性を決定する、
    請求項１６に記載の情報処理方法。
18. 前記需要データは、前記消費者による前記サービスの利用実績に基づいて生成される、
    請求項１６に記載の情報処理方法。
19. 前記所定の車両拠点に対応する前記所定の属性が二つ以上である場合に、属性ごとの優先度に基づいて、前記移動を指示する車両を決定する、
    請求項１１から１８のいずれか１項に記載の情報処理方法。
20. 前記属性ごとの優先度は、消費者による前記サービスの利用実績に基づいて生成される、
    請求項１９に記載の情報処理方法。

Images