JP7619199B2 - 相乗りタクシーシステム - Google Patents

Description

本開示は、相乗りタクシーシステムに関する。

タクシーを利用する場合に、出発地或いは目的地が同じである場合、相乗りをして低額でタクシーを利用したいという要望が存在する。相乗りタクシーを提供するためには、出発地或いは目的地が同じタクシー利用者のデータを収集し、出発地或いは目的地と乗降時刻等でデータをマッチングし、得られたデータに対して、走行ルートを算出する必要がある。

特許文献１には、顧客とタクシー会社とを連携するコールセンターシステムによって、受け付けた予約情報から、出発地、目的地及び乗車予約時刻それぞれのマッチングをとるマッチング検索と、マッチングによって得られた結果をグループ化したデータを生成するグループ化データ生成を行うタクシー相乗り支援システムが開示されている。

特開２００３－２３３６５６号公報

タクシーの利用形態として、利用時間によって料金が決められている時間貸しの形態がある。料金計算が容易となる点を生かして、相乗りタクシーを仲介する場合に、タクシーの時間貸しを利用する場合がある。しかし、タクシー時間貸しの場合、相乗り走行ルートを作成しても一定時間を超えるとタクシーの貸出料金が上がるため、料金コストが高くなる場合がある。特許文献１のタクシー相乗り支援システムでは、タクシー時間貸しの時間条件に限らず、相乗り走行ルートを作成した後、所定の条件を満足するかどうかについては考慮されていない。

本開示の目的は、相乗り走行ルートを作成した後、タクシー時間貸しの時間条件等の所定の条件を満足しない場合に、クラスタリングを再度行い、相乗り走行ルートを再度作成する相乗りタクシーシステムを提供することにある。

本開示に係る相乗りタクシーシステムは、相乗りを希望する複数の利用者の乗降要望データを受信する受信部と、乗降要望データに基づいて、配車計画を生成する配車計画部と、配車計画をタクシー会社に送信する送信部とを有する。配車計画部は、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化し、配車するタクシーを１台ずつ割当て、タクシー１台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行うクラスタリング部と、クラスタに対して、相乗り走行ルートを作成し、走行ルートに基づいて、配車計画を生成する配車計画処理部を有する。配車計画処理部は、クラスタ毎の相乗り走行時間が一定時間以上の場合には、配車するタクシーの台数を増やして、再度クラスタリングを行うことを特徴とする。

本開示に係る相乗りタクシーシステムは、クラスタ毎の相乗り走行時間が一定時間以上の場合に、配車するタクシーの台数を増やして、再度クラスタリングを行うことで、所定の条件を満足する相乗り走行ルートを作成することができる。

本開示の相乗りタクシーシステムを利用した相乗りタクシーサービスを提供する全体構成図である。 本開示の相乗りタクシーシステムのハードウェア構成の一例である。 実施形態の相乗りタクシーシステムの機能ブロック図である。 実施形態の相乗りタクシーシステムがユーザー端末から受信する乗降要望データのデータ構造の一例を示す図である。 実施形態の相乗りタクシーシステムからユーザー端末へ送信する予約確認データのデータ構造の一例を示す図である。 図４の乗降要望データを複数まとめた状態を示す図である。 図６の乗降要望データをグループ化した状態を示す図である。 グループ化した複数の乗降要望データをクラスタリングする様子を説明する図であり、（ａ）は地図上に乗降要望データを配置した図であり、（ｂ）は出発地から各乗降要望データへのベクトルを表示した図であり、（ｃ）はクラスタリングが完了した状態を示す図である。 クラスタに対して走行ルートを付加した相乗り走行ルートのデータ構造の一例を示す図である。 図９の相乗り走行ルートに対して、利用者の情報を付加した配車計画のデータ構造の一例を示す図である。 料金算出データのデータ構造の一例を示す図である。 再度のクラスタリングを説明する図である。 実施形態の相乗りタクシーシステムの処理シーケンスの一例を示す図である。 実施形態のクラスタリング部の処理の一例を示すフローチャートである。 実施形態の配車計画処理部の処理の一例を示すフローチャートである。 実施形態の料金算出処理部の処理の一例を示すフローチャートである。 他の実施形態におけるクラスタリング処理を説明する図である。 他の実施形態における相乗条件による再度のクラスタリングを説明する図である。

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。以下の説明において、具体的な形状、材料、方向、数値等は、本開示の理解を容易にするための例示であって、用途、目的、仕様等に合わせて適宜変更することができる。また、以下で説明する実施形態および変形例の構成要素を選択的に組み合わせることは当初から想定されている。

［定義］
本開示において、「クラスタリング」とは、データ間の類似度にもとづいて、データをグループ分けする手法を言い、クラスタリングによってできた、似たもの同士が集まったグループのことを「クラスタ」と呼ぶ。

［システム構成］
図1は、本開示の相乗りタクシーシステム１０を使用して、相乗りタクシーサービスを提供する全体構成図である。相乗りタクシーシステム１０は、ネットワーク３００を介して、相乗りについての乗車地、乗車日時、降車地、降車日時等の要望である乗降要望データをユーザー端末１００から受信し、相乗りのためのタクシーのオーダー情報を兼ねる配車計画を外部のタクシー会社に設置されるコンピュータ２００に送信することで、相乗りタクシーサービスを実現している。

ユーザー端末１００は、相乗りタクシーの利用希望者が、相乗りの乗降要望データを、相乗りタクシーシステム１０に送信する端末である。ユーザー端末１００は、利用者毎に複数の端末が存在し、例えば携帯端末１００Ａは、移動体通信網を介して、ネットワーク３００と接続されている。或いは、ユーザー端末１００は、ネットワーク３００に接続されたコンピュータ１００Ｂの場合もある。

コンピュータ２００は、外部のタクシー会社に設置され、相乗りタクシーシステム１０から、配車計画を送信する外部システムである。コンピュータ２００の構成については、本開示では限定しない。

［システムのハードウェア構成］
図２に、相乗りタクシーシステム１０のハードウェア構成図の一例を示す。相乗りタクシーシステム１０は、ＣＰＵ（中央処理装置）１１，入力装置１２，出力装置１３，記憶装置１４，通信装置１５を有している。ＣＰＵ１１は、種々の演算と各装置の制御を行う。入力装置１２は、外部からデータの入力を行う。出力装置１３は、外部へのデータの出力を行う。記憶装置１４は、プログラム及びデータの記憶、外部から入力されたデータの記憶等を行う。通信装置１５は、ネットワーク３００を介して、外部システムとのデータの送受信を行う。これら各装置はバス１６で互いに接続され、データのやり取りを行う。図２で示した各装置が協働して動作することで、相乗りタクシーシステム１０として動作する。

＜第１の実施形態＞
図３に、第１の実施形態の相乗りタクシーシステム１０の機能ブロック図を示す。相乗りタクシーシステム１０は、配車計画部２０と受信部２４と送信部２５を有する。受信部２４はネットワーク３００と接続されており、相乗りを希望する利用者のユーザー端末１００から乗降要望データを受信する。送信部２５はネットワーク３００と接続されており、相乗りの配車計画を外部のタクシー会社のコンピュータ２００に送信する。相乗りタクシーシステム１０は、更に配車計画部２０が生成する種々のデータや受信部２４が受信したデータを記憶するための記憶部２３、料金算出処理部３１、情報通知処理部３２、オーダー処理部３３等、他の機能ブロックを備えていてもよい。

配車計画部２０は、乗降要望データに基づいて、配車計画を生成する。配車計画部２０は、クラスタリング部２１と配車計画処理部２２を有しており、配車計画部２０は、これらによって、具体的な処理を行う。

クラスタリング部２１は、受信部２４から乗降要望データを受けとる。クラスタリング部２１は、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化する。更に、クラスタリング部２１は、タクシー１台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行う。クラスタリング部２１は、グループ化された各グループに対してクラスタリングを行う。

配車計画処理部２２は、クラスタリング部２１が生成したクラスタ毎に配車計画を生成する。配車計画処理部２２は、クラスタに含まれる乗降要望データに基づいて、相乗りの経路を表す相乗り走行ルートを作成する。作成した相乗り走行ルートに基づいて算出した値に、所定の条件を満足しないデータがある場合には、相乗りに不適なクラスタであると判断して、配車するタクシーの台数を増やして、即ち、グループ内のクラスタの総数を増やして、再度クラスタリングを行う。

受信部２４は、ネットワーク３００と接続されて、外部からのデータを受信する。本実施形態における受信部２４は、ユーザー端末１００からの乗降要望データを受信する。また受信部２４は、タクシー会社のコンピュータ２００からの配車オーダーに対する返信を受信する。受信部２４は、外部からデータを受信すると、記憶部２３へデータを保存する。

送信部２５は、配車計画をタクシー会社のコンピュータ２００へ送信する。また、ユーザー端末から受信した乗降要望データに対して、予約確認データを送信する。

料金算出処理部３１は、配車計画に基づいて、相乗り利用者毎の料金を算出する。本実施形態の料金算出処理部３１は、相乗りの乗降要望データに対する変更、キャンセルの処理も行うように構成されている。

情報通知処理部３２は、ユーザー端末１００へ、相乗りの予約受付時及び変更の受付時の予約確認データの送信及び乗降要望データがキャンセルされた場合の応答とキャンセル料金の送信を送信部２５を介して行う。

オーダー処理部３３は、配車計画を送信部２５を介して、タクシー会社のコンピュータ２００へ送信する。

［データ構造について］
図４～図１１を参照して、相乗りタクシーシステム１０が相乗りの配車計画を生成する過程で生成するデータの構造を示しながら、乗降要望データをグループ化し、クラスタリングして、相乗り走行ルート及び配車計画を生成する一連の処理について説明する。本開示においてデータの構造は、縦に項目、横にデータ内容を表記した表によって示すこととする。縦一列が１つのまとまったデータであり、異なる複数のデータが存在する場合は、横に連続して表示する。

［乗降要望データ］
図４は、ユーザー端末１００から受信した乗降要望データ１２１の構造を示している。乗降要望データ１２１の項目は、縦に予約受付Ｎｏ、（予約の）種類、乗車地、乗車日時、降車地、降車日時、希望時間、希望料金、相乗条件１、２等から構成されている。予約受付Ｎｏは、相乗りタクシーシステム１０が、乗降要望データ１２１を受付けたときに割付ける番号であり、他のデータと区別する識別番号の意味を持つ。乗降要望データ１２１には、図４（ａ）、（ｂ）に示す新規のデータ１２１ａ、１２１ｂと、図４（ｃ）に示す変更のデータ１２１ｃと、図４（ｄ）に示すキャンセルのデータ１２１ｄがある。変更のデータ１２１ｃとキャンセルのデータ１２１ｄには、種類の項目にそれぞれ、変更、キャンセルの文字データが入力されている。変更のデータ１２１ｃ、キャンセルのデータ１２１ｄの種類の項目には、前回の予約受付Ｎｏが入力されている。

図４（ａ）、（ｂ）に示すように、新規のデータ１２１ａ、１２１ｂの場合は、予約受付Ｎｏは未定である。乗車地から降車日時までの項目は、相乗り走行ルートを作成する際に使用される項目である。希望時間、希望料金、相乗条件１、２は、必須の条件ではない。例えば、相乗条件の例としては、相乗りする同乗者の性別や人数の条件などがある。他には、相乗りによる走行時間の制限、料金などの条件がある。これらは必ずしもすべての項目が必要ではなく、提供する相乗りタクシーサービス内容に応じて調整することができる。相乗条件の利用については、後述する。

図４（ａ）のデータ１２１ａのデータ内容と、図４（ｂ）のデータ１２１ｂのデータ内容を比較すると、乗車地と降車地が入れ替わっていることが分かる。乗車日時と降車日時は異なっている。データ１２１ａは、利用者が住所Ａから住所Ｘへ行くときの乗降要望データ１２１であり、データ１２１ｂは、住所Ｘから住所Ａへ帰るときの乗降要望データ１２１となっているためである。

相乗りタクシーシステム１０は、予約の受付状況（乗降要望データの受付状況）を確認のために、ユーザー端末１００へ向けて予約確認データを送信する。図５は、ユーザー端末１００へ送信する予約確認データ１２２のデータ構造の一例である。利用者は、ユーザー端末１００で、予約確認データを確認して、相乗り予約の状況を確認することができる。

予約確認データ１２２の項目は、縦に予約受付Ｎｏ、乗車地、乗車日時、降車地、降車日時、相乗り人数、料金、タクシー情報、経路情報となっている。予約受付Ｎｏから降車日時までは、乗降要望データ１２１の項目と共通している。相乗り人数は、相乗りするときの本人を含む同乗者の人数である。料金は、相乗りにかかる利用料金、タクシー情報は、配車されるタクシー会社名が入力されている。経路情報は、相乗りの経路を示す情報であり、ユーザー端末１００上では、地図画面へのリンクとなっている。経路情報のリンクから地図アプリが開き、実際に走行する相乗り走行ルートが地図上で表示されるように構成されている。尚、経路情報の形式は一例であり、他の形式であってもよい。

図６は、相乗りタクシーシステム１０において、複数の乗降要望データ１２１が蓄積された状態を示している。基本的に単独の乗降要望データ１２１と変わらないが、乗降要望データ１２１に、利用者情報が追加されている。利用者情報は、利用者の氏名、年齢、性別、当該システムへの登録ＩＤ番号等の複数の項目に分かれていてもよい。利用者情報を付加する理由は、相乗り走行ルートを作成した場合に、乗降者の情報が必要な為である。後述するように、配車計画には、乗車地においての乗車者、又は降車地においての降車者の情報が付加されるが、乗車者、降車者の情報として、利用者情報が使われる。相乗りタクシーの運転手は、乗降地において乗降する利用者を利用者情報によって確認することができる。

乗車地、降車地には住所情報が入力されている。住所情報は、住所を表す文字情報でもよいし、緯度経度の数値データでもよい。更に乗降地における建物情報などが追加されていてもよい。相乗りタクシーの走行において、乗降地の確認を助ける情報などが付加されるようにしてもよい。

図６に示す複数の乗降要望データ１２１に入力されているデータについて見てみる。予約受付Ｎｏの００１～００３のデータは、何れも降車地と降車日時が同じである。このデータは、利用者Ａ、Ｂ、Ｃがそれぞれ別の乗車地から同一の降車地へ行きたい要望を示している。具体的な状況としては、学習塾へ行く場合が考えられる。例えば、同一の学習塾で同じ時間帯の授業を受ける利用者が想定される。よって、予約受付Ｎｏの００１～００３の利用者は相乗りタクシーを利用できる可能性が高いと言える。

次に、予約受付Ｎｏの０１１～０１３は、予約受付Ｎｏの００１～００３と同じ利用者Ａ、Ｂ、Ｃが、同じ乗車地と乗車日時を要望しているデータとなっている。降車地について見ると、予約受付Ｎｏが０１１の降車地は、予約受付Ｎｏが００１の乗車地と同じ住所Ａである。予約受付Ｎｏが０１２の降車地は、予約受付Ｎｏが００２の乗車地と同じ住所Ｂ、予約受付Ｎｏが０１３の降車地は、予約受付Ｎｏが００３と同じ住所Ｃである。先ほどの例でいえば、学習塾の授業が終わって、一斉に帰宅する場合が考えられる。以上に示した状況はあくまで例示であって、他の状況が当然に考えうる。降車地が同じ場合には、人が多く集まる施設などへ行くときの利用が考えられる。乗車地が同じ場合は、その施設から自宅へ帰る場合の利用が考えられる。

［乗降要望データのグループ化］
次に複数の乗降要望データ１２１をグループ化する処理について説明する。図７は、図６と同じデータを基にグループ化する方法を説明する図である。本実施形態のグループ化の手法としては、乗車地と乗車日時が同じ乗降要望データ１２１を一つのグループにまとめる。また、降車地と降車日時が同じ乗降要望データ１２１を一つのグループにまとめる。そして、グループ毎にデータの先頭にGroupNoを付加している。このようにして、同じグループには、同じGroupNoを付して生成されたのが図７のデータである。図７の例では、予約受付Ｎｏが００１～００３のデータが、GroupNoが００１としてグループ化され、また、予約受付Ｎｏが０１１～０１３のデータが、GroupNoが００２としてグループ化された様子を示している。即ち、図７に示すデータにおいては、GourpNoが００１のデータは、降車地が住所Ｘで、降車日時が日時Ｘ１と何れも同じデータである。GroupNoが００２のデータは、乗車地が住所Ｘで、乗車日時が日時Ｘ３と同じデータである。

GroupNoが００１の予約受付Ｎｏが異なる３つのデータの乗車地は異なっている。これは利用者が異なるためで、それぞれ異なる乗車地から、同じ降車地である住所Ｘへ行くのに相乗りタクシーを利用したい利用者を１つのグループにまとめていることになる。GroupNoが００２の予約受付Ｎｏが異なる３つのデータは乗車地と乗車日時が同じであり、降車地が異なっている。これは同じ乗車地からそれぞれ異なる降車地へ行くのに相乗りタクシーを利用したい利用者を１つのグループにまとめていることになる。尚、グループ化された各グループのデータの数は、本例の３つに限らない。同じ乗車地と乗車日時、又は同じ降車地と降車日時を有する乗降要望データは全て１つのグループにまとめることになる。

上述の例では、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化する一例として、乗車地と乗車日時が同じ乗降要望データ、或いは降車地と降車日時が同じ乗降要望データをグループ化したが、完全に同じでなくてもよい。乗車地と乗車日時が近似する乗降要望データ、或いは降車地と降車日時が近似する乗降要望データをグループ化するようにしてもよい。グループ化する乗降要望データの近似の度合いについては、提供する相乗りサービスに応じて適宜設定する。

本実施形態の相乗りタクシーシステム１０は、複数の乗降要望データをグループ化した後、グループ内のデータをクラスタリングして、少数のデータから成るクラスタに分け、クラスタ毎にタクシーを１台割当てた配車計画を作成する。以下に順を追って説明する。

［クラスタリング処理］
図８（ａ）は、１つのグループに含まれる全ての乗降要望データについて、降車地を地図上に配置したときの図を示している。当該グループに含まれる乗降要望データは、同じ乗車地から利用者それぞれの降車地で降りる場合のデータとなっている。地図の略中央で他とは形の異なる図形を配置した地点Ｏは、乗車地（出発地）を示している。即ち、図８（ａ）に示すマップは、同じ日時に乗車地を示す地点Ｏから、相乗りタクシーを利用して行きたい降車地の分布を示している。よって、これらの降車地をクラスタリングして、クラスタ毎に走行ルートを作成することで、相乗り走行ルートが作成されることになる。以下に示すのは、１つの手法であって、他の手法で走行ルートを作成することを除外するものではない。

まず始めに図８（ｂ）に示すように、乗降要望データに含まれる住所情報から、出発地（地点Ｏ）から各乗降要望データの降車地へのベクトルを計算する。図８（ｂ）に、矢印で示すのが当該ベクトルである。

例えば、矢印の向きが近いデータは、出発地からの行き先の方向が近いことを意味し、相乗りのクラスタにすることに適する傾向がある。矢印の長さは出発地からの距離を意味し、矢印の向きが概ね近く、長さが段階的に異なるデータを選ぶようにすると、相乗り走行に適するクラスタとなる。このようにして、図８（ａ）の乗降要望データをクラスタリングしたものが、図８（ｃ）の実線で囲んだデータである。図８（ｃ）の破線は、出発地からの距離を段階的に示している。図８（ｃ）は、ＣＬ１～ＣＬ６で示すクラスタが生成されたことを示している。尚、図８（ａ）～（ｃ）で示した地図上の描画は、クラスタリングの過程を理解しやすいように図に示したものであって、実際に地図上にデータを描画して、クラスタを生成する必要はない。尚、本実施形態では、クラスタリングを行う際に、各クラスタに含まれる乗降要望データの数は、４以下となるように行う。これは相乗りする同乗者の最大人数であり、４人より多い場合には同乗が困難になるためである。クラスタに含まれる最大数は、相乗りタクシーを提供する車両の大きさにも関係するので、４人に限定されるものではない。

クラスタリング手法は、上述のクラスタリング手法に限らない。複数の乗降要望データからクラスタを生成する手法は、ＡＩによる機械学習を適用することによって可能であるが、詳細は省略する。

［相乗り走行ルート］
次に、相乗りタクシーシステム１０は、クラスタリングされた各クラスタに対して、相乗り走行ルートを作成する。図９（ａ）、（ｂ）に作成した相乗り走行ルート１２４の一例を示す。図９（ａ）は、複数の乗車地で利用者を乗車させ、共通の到着地に相乗りする場合の相乗り走行ルート１２４ａを示している。図９（ｂ）は、共通の出発地から複数の利用者を載せて、それぞれ別の降車地で利用者を降ろす場合の相乗り走行ルート１２４ｂを示している。

相乗り走行ルート１２４ａは、縦の先頭に配車Ｎｏが付加されている。続いて乗車地、乗車日時の項目が４つ続いて、到着地、到着日時、経路情報が付加されている。配車Ｎｏは、相乗りに配車されるタクシーの番号を意味している。配車Ｎｏが００１のデータにおいては、４人の利用者がそれぞれの乗車地１～４で乗車して、到着地（住所Ｘ）で降車することを意味している。経路情報は相乗りの経路を示す情報である。経路情報の経路Ｒ１は、図５の経路情報と同じ構造のデータである。経路情報は、後にユーザー端末１００とタクシー会社のコンピュータ２００へ送信するために使用される。

配車Ｎｏが００２のデータは、乗車地３から乗車日時４までの項目が空欄である。これは利用者が二人のためである。このように、利用者が４名未満の場合は、空欄となる項目が生じる。到着地以降のデータ項目については、配車Ｎｏが００１の場合と同様である。配車Ｎｏが００３以降のデータ項目についても、配車Ｎｏが００１、００２のデータと同様である。

図９（ｂ）は、相乗り走行ルート１２４ｂの構造を示している。相乗り走行ルート１２４ｂは、相乗り走行ルート１２４ａと異なり、出発地で複数の利用者がタクシーに乗って、それぞれの降車地でタクシーを降りるときの相乗りデータである。従って、配車Ｎｏに続いて、出発地、出発日時が項目となっている。その後に、降車地、降車日時の項目が４つ続いて、経路情報となっている。相乗り走行ルート１２４ｂの配車Ｎｏが０１１のデータは、４人の利用者が、出発地（住所Ｘ）で一斉にタクシーに乗車し、利用者それぞれが一人ずつ降車していくデータを意味している。経路情報の経路Ｒ１１の内容は、相乗り経路を示す情報である。配車Ｎｏが０１２のデータは、乗車者が二人のため、降車地３から降車日時４までの項目は空欄である。

相乗り走行ルート１２４ａ、１２４ｂは、所定の条件を満足しないデータ（相乗りに適しないと判断するデータ）がある場合は、後述するように同一のグループ内の配車タクシーの台数を増やして（例えば１台増やして）、再度クラスタリングを行い、相乗り走行ルートを再度作成する。所定の条件を満足しないデータが無い場合には、配車計画に加工される。

［所定の条件に対する判断］
本実施形態の相乗りタクシーシステム１０においては、相乗り走行ルートを作成した後、当該データに相乗りに適しないデータの存否を判断する。時間貸しで相乗りタクシーを利用している場合を例にして説明する。時間貸しで利用する場合に問題となるのは、利用時間が一定の貸出時間を超える毎に料金が高くなることである。従って、相乗りにタクシーを利用する時間が一定の貸出時間を超えないようにする必要がある。この場合、利用時間が一定の貸出時間を超えないことが所定の条件となる。以降、図９（ａ）の相乗り走行ルート１２４ａの配車Ｎｏが００１のデータの例で説明する。

相乗りにタクシーを利用する時間は、相乗りの全ルートを走行するのに要する相乗り利用時間に相当し、乗車日時１である日時Ａ１から到着日時である日時Ｘ１までの時間である。日時Ａ１から日時Ｘ１までに要する時間をＴＡとし、時間貸しの料金が変わる時間をＴａとすると、ＴＡ＜Ｔａを所定の条件とする。この条件を満足しない場合、貸出時間をオーバーするので、タクシー貸出料金が高くなり、相乗りに適しないと判断する。所定の条件ＴＡ＜Ｔａを満足しない場合には、当該相乗り走行ルートが含まれるグループに対して、タクシーの台数を増やして、再度クラスタリングを行う。クラスタには配車するタクシーが１台ずつ割当てられるので、配車するタクシーの台数を増やすことは、クラスタの総数を増やすことになり、再度クラスタリングすることで、相乗り利用時間ＴＡを短くすることが可能となる。所定の条件を満足する場合には、配車計画を生成する。

所定の条件は、タクシーの時間貸しの貸出時間以外とすることも可能である。例えば、相乗りする場合と相乗りしない場合の時間の差（ロス時間と呼ぶ）が所定の時間を超えるか否かで判断してもよい。ロス時間とは、相乗りする場合に要する時間から単独でタクシーを利用した場合に要する時間との差である。このロス時間は、相乗りすることによって、余分にかかる時間であり、ロス時間が長い場合には、相乗りによるメリットを減少させることになる。

再び、図９（ａ）の相乗り走行ルート１２４ａの配車Ｎｏが００１のデータの例で説明する。配車Ｎｏが００１のデータは、乗車地１～４の項目にデータが埋まっているので、利用者が４人いることになる。利用者のそれぞれが相乗りで要する時間は、到着日時の日時Ｘ１から利用者の乗車日時を引いた時間である。二番目のデータである乗車日時２のデータに対しては、日時Ｘ１－日時Ｂ１（Ｔ１とする）である。単独でタクシーを利用した時間に対してロス時間が発生するのは、他の利用者を乗車させるために経路を迂回する可能性があるためである。今、乗車地２で乗車する利用者について、ロス時間を算出する場合に、単独でタクシーを利用した時間（ｔ１とする）を算出する必要があるが、この時間ｔ１は、乗車地２の住所Ｂと到着地の住所Ｘとから、既存の経路算出手法を使用して算出することができる。ロス時間は、Ｔ１－ｔ１となる。ロス時間の許容時間をＴｂとしたとき、（Ｔ１－ｔ１）＜Ｔｂを所定の条件とする。この条件を満足しない場合には、相乗りによって許容時間以上の時間がかかっていることになり、利用者によっては相乗りのメリットを感じられない場合が発生する。所定の条件を満足しない場合には、当該相乗り走行ルートが含まれるグループに対して、タクシーの台数を増やして（クラスタの総数を増やして）、再度クラスタリングを行う。所定の条件を満足する場合には、配車計画を生成する。

［配車計画］
相乗り走行ルートに所定の条件を満足しないデータが無ければ、配車計画１２５を生成する。配車計画１２５は、タクシー会社にタクシーの配車を依頼するためのデータである。配車計画１２５には、図９（ａ）、（ｂ）の相乗り走行ルート１２４ａ、１２４ｂに含まれる項目は全て含まれる。また、図９（ａ）、（ｂ）の２種類の相乗り走行ルート１２４に対応して、配車計画１２５も２種類の構造を有する。図１０（ａ）が、図９（ａ）に対応する配車計画１２５ａであり、図１０（ｂ）が、図９（ｂ）に対応する配車計画１２５ｂである。

配車計画１２５ａのデータ構造は、相乗り走行ルート１２４ａに比べて、乗車地１～４のそれぞれに乗車する乗車者の情報が付加されている点で異なる。更に降車地での降車者の情報も付加されている。配車計画１２５ｂのデータ構成は、相乗り走行ルート１２４ｂに比べて、出発地において、乗車する乗車者の情報と降車地１～４毎に降車する降車者の情報が付加されている。これらの情報は、タクシー会社のドライバーにとって、乗降者を確認するために必要な情報となる。

［料金算出データ］
図１１に、料金算出データ１２６のデータ構造を示す。料金算出データ１２６は、相乗りタクシーの各利用者毎に料金を算出したデータである。料金算出データ１２６は、縦先頭に配車Ｎｏ、続いて利用者、乗車地、乗車日時、降車地、降車日時、所要時間、単独時間、単独距離、単独料金、相乗人数、係数、料金、経路情報となっている。単独時間、単独距離、単独料金の項目は、必須の項目ではないが、相乗り利用の良し悪しを反映するデータであり、参考値として付加している。所要時間は、相乗りに乗車地から降車地までかかる予定時間である。単独時間は、相乗りをせず直接タクシーを利用したときの予測所要時間である。単独距離、単独料金は、直接タクシーを利用したときの距離と料金の予測である。相乗り人数は、相乗りで同乗する利用者の人数である。係数は、相乗りによる料金を算出するための係数であり、例えば、単独料金に係数を掛けることで相乗りの料金を決定するようにしている。経路情報は、配車計画１２５の経路情報と同じデータ構造である。図１１においては、配車Ｎｏが００１のデータが４つ示されているが、図１０（ａ）の配車計画１２５ａの配車Ｎｏが００１のデータに含まれる４人の利用者Ａ～Ｄのそれぞれに対して、料金を算出したデータに対応している。

相乗りタクシーシステム１０は、この料金算出データを基に、各利用者に対して、図５に示した予約確認データ１２２を、送信部２５からユーザー端末１００に送信する。

［再度のクラスタリング処理］
図１２を参照して、相乗り走行ルートに所定の条件を満足しないデータが存在し、相乗りに適しないと判断した場合の再度のクラスタリング処理について説明する。図１２（ａ）は、図８（ｃ）と同様のクラスタリングを完了した直後の様子を示している。クラスタＣＬ３に星印を付けたデータが、相乗りに不適のデータであるとする。この場合、クラスタＣＬ３を分解して、全体のクラスタ数を１増やして、クラスタ数を７として、再度クラスタリングを行う。

最も単純な再度のクラスタリングの方法は、相乗りに不適のデータがあるクラスタのデータを分割して、２つのクラスタに分けることである。クラスタの分割だけで、相乗りに不適のデータが無くならない場合には、隣接するクラスタを含めて、再度クラスタリングを試みる。或いは、図８（ｂ）、（ｃ）で説明した、出発地と降車地のベクトルの向きと大きさを基に、グループ全体のクラスタリングを行うようにしてもよい。この場合、クラスタの総数を増やしているため、クラスタに含まれるデータの数が少なくなるので、同様の手法で相乗りの不適なデータが無くなるようにクラスタリングすることが可能になる。図１２（ｂ）が再度のクラスタリングの結果の一例である。クラスタＣＬ３が分割されて、クラスタＣＬ７が新たに追加された状態となっている。

［相乗りタクシーシステムの処理シーケンス］
図１３に示すシーケンス図によって、本実施形態の相乗りタクシーシステム１０がユーザー端末１００とタクシー会社のコンピュータ２００との間で行う処理の一例について、データの授受と共に示す。図１３で示すのは、ユーザー端末１００で相乗り乗降要望を送信し、相乗りタクシーシステム１０で相乗りのデータ処理を行い、ユーザー端末１００に結果を送信し、タクシー会社のコンピュータ２００に配車オーダーを送信するまでの一連の処理である。尚、図１３の説明においては、相乗りタクシーシステム１０については、単にシステム１０と呼ぶ。

ステップＳ１において、ユーザー端末１００から乗降要望データが送信され、システム１０は、受信部２４で当該データを受信する。次に、ステップＳ２において、システム１０は、既に蓄積された乗降要望データとステップＳ１で受信したデータをマージした後、上述した、グループ化、クラスタリング、相乗り走行ルートの作成、配車計画の生成までを行う。

次に、ステップＳ３において、システム１０は、コンピュータ２００へ配車計画を送信する。配車計画は、図１０で説明したデータである。次に、ステップＳ４において、コンピュータ２００から送信される配車計画の受領返信を受信して、データ送信が正常に完了したことを確認する。その後、ステップＳ５において、システム１０は、ユーザー端末１００に向けて、予約受付Ｎｏ、経路情報、料金を含む予約確認データを送信する。予約確認データは、図４に示したデータである。

続いて、実際の相乗りタクシーの配車までに、予約の変更或いはキャンセルがあった場合のシーケンスについて説明する。

システム１０は、予約の変更またはキャンセルの要望を、ユーザー端末１００から乗降要望データとして受信する。ステップＳ６において、システム１０が予約の変更またはキャンセルの乗降要望データを受信したとする。システム１０は、次にステップＳ７において、予約変更、キャンセルの処理を行う。実際の処理は、乗降要望データの項目の種類に記入されているデータに基づいて行う。予約の変更である場合は、システム１０内に既にある乗降要望データの中の予約受付Ｎｏが一致するデータを更新して、グループ化以降の処理を行い、配車計画を生成する。予約のキャンセルである場合は、予約受付Ｎｏが一致するデータを消去して、グループ化以降の処理を行い、配車計画を生成する。次に、ステップＳ８において、システム１０は、コンピュータ２００へ更新した配車計画を送信する。ステップＳ９において、コンピュータ２００から送信される配車計画の受領返信を受信して、データ送信が正常に完了したことを確認する。その後、ステップＳ１０において、システム１０は、ユーザー端末１００に向けて、更新した予約受付Ｎｏ、経路情報、料金を含む予約確認データを送信する。

相乗りタクシーの配車当日になると、システム１０は、ステップＳ１１において、配車確定情報をコンピュータ２００に送信する。これ以降、システム１０は、予約の変更、キャンセルを受付けないようにする。ステップＳ１２において、システム１０は、ユーザー端末１００に向けて、当日の配車情報を送信する。この当日の配車情報は、既にユーザー端末１００に送信している予約確認データと同じものである。尚、当日の配車確定情報と配車情報の送信は必須ではない。

次に相乗りタクシーシステム１０において行われる処理のフローチャートを示す。ここで説明するフローチャートは、図３で示したクラスタリング部２１、配車計画処理部２２及び料金算出処理部３１において処理される内容である。

［クラスタリング処理］
図１４は、クラスタリング部２１が行う処理のフローチャートである。クラスタリング部２１は、複数の乗降要望データのグループ化とクラスタリング及び再度のクラスタリングの処理を行う。

クラスタリング部２１は、始めに乗降要望データを受信する（ステップＳ１１）。乗降要望データには、予約の変更、キャンセルの乗降要望データを含んでいる（図中Ｃ）。乗降要望データは、記憶部２３に記憶され蓄積される。次に蓄積された乗降要望データのグループ化を行う（ステップＳ１２）。グループ化の詳細は、既に図７で説明しているので省略する。次に、クラスタリング部２１は、グループデータについて、クラスタリングを行う（ステップＳ１３）。クラスタリングには、後述する配車計画処理において、乗降時間が不適の場合の再度のクラスタリングを含む（図中Ａからの処理）。図中Ａから来た処理は再クラスタリングに該当し、タクシーの台数（クラスタ数）を１増やして（ステップＳ１４）、クラスタリングの処理を行う（ステップＳ１３）。クラスタリングが終了すると、クラスタリング部２１の処理は終了する。尚、ステップＳ１３のクラスタリングの後に、相乗条件調整（ステップＳ１５）を行うようにしてもよい。相乗条件調整については、後述する。

［配車計画処理］
図１５は、配車計画処理部２２が行う処理のフローチャートである。配車計画処理部２２は、クラスタリング部２１が生成したクラスタに対して、相乗り走行ルートの作成、相乗りに適するか否かを判断するデータの算出、配車計画の生成、料金計算のためのマッチング係数の割当て等の処理を行う。

配車計画処理部２２は、まず初めにクラスタデータに対して、相乗り走行ルートの作成を行い、各所要時間の算出を行う（ステップＳ２１）。各所要時間とは、相乗りの全ルートを走行するのに要する相乗り利用時間ＴＡ、及び相乗り利用者毎のロス時間Ｔ１－ｔ１である。まず、相乗り利用時間ＴＡが所定の条件：ＴＡ＜Ｔａを満足するかどうかを判断する（ステップＳ２２）。満足しない場合は、乗降時間の所定の条件を満足しない場合として、再度クラスタリングを行う（図中Ａへ）。所定の条件を満足する場合は、次のステップＳ２３へ進む。次は、ロス時間が所定の条件：（Ｔ１－ｔ１）＜Ｔｂを満足するかどうかを判断する（ステップＳ２３）。満足しない場合は、同様に再度クラスタリングを行う（図中Ａへ）。満足する場合は、料金計算のためのマッチング係数を利用者毎に割り当てる処理を行う（ステップＳ２４）。ステップＳ２４の後は、料金算出処理へ処理を移行する（図中Ｂへ）。配車計画処理部２２は、ステップＳ２４と平行して、配車計画を生成する（ステップＳ２５）。生成された配車計画は、情報通知処理部３２及びオーダー処理部３３へ送られ、必要な加工をされて、送信部２５によってユーザー端末１００とコンピュータ２００へ送信される。

［料金算出処理］
図１６は、料金算出処理部３１が行う処理のフローチャートである。料金算出処理部３１は、配車計画が生成された後に、相乗り料金の算出、乗降要望データの予約変更、キャンセルの有無の確認、キャンセルが発生した場合のキャンセル料金の算出等の処理を行う。

料金算出処理部３１は、まず始めに配車計画に基づいて、乗降距離に基づく料金算出を行う（ステップＳ３１）。この料金算出は、図１０の料金算出データで説明した、単独料金の算出が該当する。次に、算出した料金に対して、配車計画処理部（図中Ｂ）から受け取ったマッチング係数を乗算することで、料金を算出する（ステップＳ３２）。以上で料金算出は完了であるが、本実施形態の料金算出処理部３１は、更に予約の変更の有無（ステップＳ３３）、キャンセルの有無（ステップＳ３４）を確認する処理を行う。予約の変更がある場合は、予約変更の処理へ移行する（図中Ｃ）。これと並行して、ユーザー端末への変更受付データを作成し（ステップＳ３５）、送信するために情報通知処理部３２へ処理を移行する。キャンセルがある場合には、キャンセルの処理へ移行する（図中Ｃ）。これと平行して、キャンセル料金を算出して（ステップＳ３６）、キャンセル料金をユーザー端末に送信するために情報通知処理部３２へ処理を移行する。予約変更もキャンセル変更もない場合には、予約確認データと料金情報を作成し（ステップＳ３７）、ユーザー端末１００へ送信するために情報通知処理部３２へ処理を移行する。

以上、第１の実施形態について説明した。本実施形態によれば、乗降要望データをグループ化、クラスタリングしたクラスタに対して、相乗り走行ルートを作成し、相乗りの所定の条件を満足しないデータがある場合には、タクシーの台数（クラスタ数）を増やして、再度クラスタリングを行うようことにより、所定の条件を満足するように相乗り走行ルートを生成することが可能となる。

＜第２の実施形態＞
図１７に、第２の実施形態の相乗りタクシーシステム１０の他の処理例を示す。ユーザー端末１００からの乗降要望データの予約の受付期間が長く、相乗りタクシーの配車までに一定の期間があり、乗降要望データが時間と共に増えていく場合の相乗りタクシーシステム１０の動作について説明する。

図１７（ａ）は、例えば、相乗りタクシーの配車の１週間前のクラスタ形成の様子を示す。図１７（ｂ）は、相乗りタクシーの配車の３日前のクラスタ形成の様子を示す。図１７（ｃ）は、相乗りタクシーの配車の前日のクラスタ形成の様子を示す。図１７（ａ）～（ｃ）に示す通り、時間と共に、乗降要望データが増加して、クラスタ形成の様子も変化していく。第１の実施形態においては、予約の変更を受付ける毎に再度クラスタリングを行うようにしたが、第２の実施形態では、一定期間ごとにクラスタリングを行うようにする。予約期間が長い場合には、乗降要望データが増えていくことが想定され、予約変更の都度、再度クラスタリングを行うよりもシステムのリソースを消費しないので有利である。尚、再度クラスタリングを行う間隔については、具体的な相乗りを提供する状況に応じて、適宜調整することは言うまでもない。

＜第３の実施形態＞
図１８は、乗降要望データに設定した相乗条件を基に再度クラスタリングを行う例を示す。第１の実施形態では、配車計画処理部２２で各所要時間の算出結果に基づいて、所定の条件を満足するか否かを判断し、満足しない場合に再度クラスタリングを行った。第３の実施形態では、乗降要望データに項目がある相乗条件に基づいて、再度クラスタリングを行うものである。相乗条件は、図４の乗降要望データで説明したように、相乗りする同乗者の条件などである。具体的には、先に説明した学習塾への送迎に相乗りを利用する場合は、利用者は子供であり、同性の同乗者しか許容しない場合が想定される。この処理は、図１４のクラスタリング処理で説明を省略した相乗条件調整（ステップＳ１５）に相当する。

図１８（ａ）～（ｃ）を参照して説明する。図１８（ａ）はクラスタリングが完了して、クラスタＣＬ１～ＣＬ６が生成された場合を示している。図１８（ｂ）は、相乗条件の関係を示している。相乗条件Ａ、Ｂ、Ｃの利用者に対して、それぞれ相乗りの同乗を許容している利用者の相乗条件を示した表である。図１８（ａ）のクラスタＣＬ１～ＣＬ３のマップ上のデータには、条件Ａ～Ｃの何れであるかを示している。クラスタＣＬ１のデータは、Ａ、Ａ、Ｃであり、図１８（ｂ）から相乗条件に問題はない。クラスタＣＬ２のデータは、Ｂ、Ｃ、Ｃである。条件Ｂの利用者は、条件Ａ、Ｂの利用者しか同乗を許容しないから、相乗条件を満足していない。クラスタＣＬ３のデータは、Ａ、Ａ、Ａ、Ｂであり、相乗条件に問題はない。

この場合に、クラスタ数を増やし（クラスタ数を７にして）、再度クラスタリングを行う。結果として、クラスタＣＬ２、ＣＬ３を分割して、クラスタＣＬ７を図１８（ｃ）に示すようにクラスタが生成されて、相乗条件の問題は解消する。当該処理はクラスタリング部に組み込んだプログラムによって実行する。本実施形態で示したのは、一例であって、クラスタリングのアルゴリズムによって、図示した以外のクラスタが生成されることは当然にして有り得る。本開示は、クラスタリングの詳細まで特定するものではなく、クラスタ数を増やして、再度クラスタリングを行うことに特徴を有するものである。

なお、本発明は上述した実施形態およびその変形例に限定されるものではなく、本願の特許請求の範囲に記載された事項の範囲内において種々の変更や改良が可能であることは勿論である。

１０ 相乗りタクシーシステム、１１ ＣＰＵ、１２ 入力装置、１３ 出力装置、１４ 記憶装置、１５ 通信装置、１６ バス、２０ 配車計画部、２１ クラスタリング部、２２ 配車計画処理部、２３ 記憶部、２４ 受信部、２５ 送信部、３１ 料金算出処理部、３２ 情報通知処理部、３３ オーダー処理部、１００、１００Ａ、１００Ｂ ユーザー端末、２００ コンピュータ、３００ ネットワーク

Claims (1)

1. 相乗りを希望する複数の利用者の乗降要望データを受信する受信部と、
   前記乗降要望データに基づいて、配車計画を生成する配車計画部と、
   前記配車計画をタクシー会社に送信する送信部と、
   を有する相乗りタクシーシステムであって、
   前記配車計画部は、
   前記乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の前記乗降要望データをグループ化し、前記グループ内のデータをクラスタリングして、少数のデータから成るクラスタに分け、前記クラスタ毎に配車するタクシーを１台ずつ割当て、タクシー１台に乗る人数が所定数以下となるように前記クラスタを生成するクラスタリングを行うクラスタリング部と、
   前記クラスタに対して、相乗り走行ルートを作成し、前記走行ルートに基づいて、前記配車計画を生成する配車計画処理部と、
   を有し、
   前記配車計画処理部は、前記クラスタ毎の相乗り走行時間が一定時間以上の場合には、前記配車するタクシーの台数を増やして、再度クラスタリングを行う、
   相乗りタクシーシステム。

Images