知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023091265
(43)【公開日】2023-06-30
(54)【発明の名称】需給マッチング装置及び方法
(51)【国際特許分類】
G06Q 50/14 20120101AFI20230623BHJP
【ＦＩ】
G06Q50/14
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2021205920
(22)【出願日】2021-12-20
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】弁理士法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】長谷川 陽平
(72)【発明者】
【氏名】米原 三揮
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049CC26
(57)【要約】
【課題】旅客の多種多様な移動需要を満たすことと輸送サービスの運用効率を維持することとを両立する。
【解決手段】移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含む。交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフである。同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在する。装置は、運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである問題リンクを特定し、問題リンクを含んだ部分交通ネットワークを抽出し、部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、生成された各クラスタを基に、移動需要を満たし運用効率を維持する解（部分交通ネットワークにおける区間毎のクラスタ割当て）を決定する。
【選択図】図１
【解決手段】移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含む。交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフである。同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在する。装置は、運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである問題リンクを特定し、問題リンクを含んだ部分交通ネットワークを抽出し、部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、生成された各クラスタを基に、移動需要を満たし運用効率を維持する解（部分交通ネットワークにおける区間毎のクラスタ割当て）を決定する。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数の旅客端末と通信するインターフェース装置と、
旅客毎の移動需要を表す情報である移動需要情報と、旅客毎の仮経路を表す情報である仮経路情報と、交通ネットワークを表す情報である交通ネットワーク情報とを記憶する記憶装置と、
前記インターフェース装置及び記憶装置に接続されたプロセッサと
を備え、
旅客端末は、旅客の情報処理端末であり、
移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含み、
仮経路は、出発地から目的地までの仮の経路であり、
前記交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフ構造のネットワークであり、
ノードは、旅客が乗車及び降車のうちの少なくとも一つを行い得る場所に対応し、
リンクは、輸送サービスに対応し、
同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在し、
前記交通ネットワーク情報は、輸送サービス毎に、輸送サービスの定員と輸送サービスのサービスレベルに関する情報とを含み、
前記プロセッサは、
（Ａ）対象旅客の対象旅客端末から移動需要を受け付け、当該移動需要を表す情報を前記移動需要情報に含め、
前記対象旅客は、いずれかの旅客であり、
前記対象旅客端末は、前記対象旅客の旅客端末であり、
（Ｂ）前記移動需要情報及び前記交通ネットワーク情報を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定し、
（Ｃ）当該一つ以上の問題リンクを含み前記交通ネットワークの一部分としてのグラフである部分交通ネットワークを抽出し、
（Ｄ）前記仮経路情報及び前記移動需要情報を基に、前記部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、
（Ｅ）生成された各クラスタと前記交通ネットワーク情報とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行い、
前記決定された解は、前記部分交通ネットワークにおける区間毎のクラスタ割当てであり、
前記部分交通ネットワークにおいて、区間は、ノード間が異なる一つ以上のリンクであり、
（Ｆ）前記決定された解が、前記対象旅客について仮経路に含まれない区間を含む場合、前記対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、
（Ｇ）前記対象旅客端末からの移動需要に対する応答として、前記対象旅客の確定経路に関する情報を前記対象旅客端末に送信する、
需給マッチング装置。
旅客毎の移動需要を表す情報である移動需要情報と、旅客毎の仮経路を表す情報である仮経路情報と、交通ネットワークを表す情報である交通ネットワーク情報とを記憶する記憶装置と、
前記インターフェース装置及び記憶装置に接続されたプロセッサと
を備え、
旅客端末は、旅客の情報処理端末であり、
移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含み、
仮経路は、出発地から目的地までの仮の経路であり、
前記交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフ構造のネットワークであり、
ノードは、旅客が乗車及び降車のうちの少なくとも一つを行い得る場所に対応し、
リンクは、輸送サービスに対応し、
同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在し、
前記交通ネットワーク情報は、輸送サービス毎に、輸送サービスの定員と輸送サービスのサービスレベルに関する情報とを含み、
前記プロセッサは、
（Ａ）対象旅客の対象旅客端末から移動需要を受け付け、当該移動需要を表す情報を前記移動需要情報に含め、
前記対象旅客は、いずれかの旅客であり、
前記対象旅客端末は、前記対象旅客の旅客端末であり、
（Ｂ）前記移動需要情報及び前記交通ネットワーク情報を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定し、
（Ｃ）当該一つ以上の問題リンクを含み前記交通ネットワークの一部分としてのグラフである部分交通ネットワークを抽出し、
（Ｄ）前記仮経路情報及び前記移動需要情報を基に、前記部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、
（Ｅ）生成された各クラスタと前記交通ネットワーク情報とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行い、
前記決定された解は、前記部分交通ネットワークにおける区間毎のクラスタ割当てであり、
前記部分交通ネットワークにおいて、区間は、ノード間が異なる一つ以上のリンクであり、
（Ｆ）前記決定された解が、前記対象旅客について仮経路に含まれない区間を含む場合、前記対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、
（Ｇ）前記対象旅客端末からの移動需要に対する応答として、前記対象旅客の確定経路に関する情報を前記対象旅客端末に送信する、
需給マッチング装置。
【請求項2】
前記抽出された部分交通ネットワークは、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であるネットワークである、
請求項１に記載の需給マッチング装置。
請求項１に記載の需給マッチング装置。
【請求項3】
（Ｃ）において、前記プロセッサは、
問題リンクに隣接するリンクを問題リンクにつなぐことを、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であることが満たされる範囲で行うことで、一つ以上の部分交通ネットワークを生成し、
互いに少なくとも一部が重複する二つ以上の部分交通ネットワークが生成された場合、当該二つ以上の部分交通ネットワークを一つの部分交通ネットワークとする、
請求項２に記載の需給マッチング装置。
問題リンクに隣接するリンクを問題リンクにつなぐことを、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であることが満たされる範囲で行うことで、一つ以上の部分交通ネットワークを生成し、
互いに少なくとも一部が重複する二つ以上の部分交通ネットワークが生成された場合、当該二つ以上の部分交通ネットワークを一つの部分交通ネットワークとする、
請求項２に記載の需給マッチング装置。
【請求項4】
前記抽出された部分交通ネットワークは、問題リンクを最も多く通る仮経路である該当仮経路の代替パス数が下限値以上であるネットワークであり、
前記代替パスは、前記該当仮経路における問題リンク毎に、当該問題リンクを迂回しそれぞれ問題リンクではない一つ以上のリンクである、
請求項２に記載の需給マッチング装置。
前記代替パスは、前記該当仮経路における問題リンク毎に、当該問題リンクを迂回しそれぞれ問題リンクではない一つ以上のリンクである、
請求項２に記載の需給マッチング装置。
【請求項5】
（Ｃ）において、前記プロセッサは、生成された部分交通ネットワークにおける問題リンクを最も多く通る仮経路の代替パス数が前記下限値未満の場合、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であることが満たされる範囲で当該部分交通ネットワークを拡大する、
請求項４に記載の需給マッチング装置。
請求項４に記載の需給マッチング装置。
【請求項6】
前記抽出された部分交通ネットワークは、問題リンクを最も多く通る仮経路である該当仮経路の代替パス数が上限値以下であるネットワークであり、
前記代替パスは、前記該当仮経路における問題リンク毎に、当該問題リンクを迂回しそれぞれ問題リンクではない一つ以上のリンクである、
請求項２に記載の需給マッチング装置。
前記代替パスは、前記該当仮経路における問題リンク毎に、当該問題リンクを迂回しそれぞれ問題リンクではない一つ以上のリンクである、
請求項２に記載の需給マッチング装置。
【請求項7】
（Ｃ）において、前記プロセッサは、
生成された部分交通ネットワークにおける問題リンクを最も多く通る仮経路の代替パス数が前記上限値を超えている場合、下記が満たされているか否かを判定し、
・当該部分交通ネットワークに、端点のノード以外のノードであって、折り返し可能とする輸送サービスの数又は割合が所定値以下であるノードである該当中間ノードがある、
・当該該当中間のノードを境に当該部分交通ネットワークを複数の部分交通ネットワークに分割したとしても当該複数の部分交通ネットワークがそれぞれ該当仮経路の代替パス数が下限値以上であることを満たす、
前記判定の結果が真の場合に、前記生成された部分交通ネットワークを、前記該当中間ノードを境に分割する、
請求項２に記載の需給マッチング装置。
生成された部分交通ネットワークにおける問題リンクを最も多く通る仮経路の代替パス数が前記上限値を超えている場合、下記が満たされているか否かを判定し、
・当該部分交通ネットワークに、端点のノード以外のノードであって、折り返し可能とする輸送サービスの数又は割合が所定値以下であるノードである該当中間ノードがある、
・当該該当中間のノードを境に当該部分交通ネットワークを複数の部分交通ネットワークに分割したとしても当該複数の部分交通ネットワークがそれぞれ該当仮経路の代替パス数が下限値以上であることを満たす、
前記判定の結果が真の場合に、前記生成された部分交通ネットワークを、前記該当中間ノードを境に分割する、
請求項２に記載の需給マッチング装置。
【請求項8】
（Ｅ）において、前記プロセッサは、
（ｅ１）旅客と、クラスタと、前記抽出された部分交通ネットワークにおける区間との組である第１種の組毎に、当該旅客が当該クラスタに所属する場合に当該区間を通る確率である所属確率を算出し、
（ｅ２）クラスタと、前記抽出された部分交通ネットワークにおける区間との組である第２種の組毎に、当該第２種の組について得られた全旅客の所属確率を基に、当該クラスタのうち当該区間を通る旅客の割合である期待値を算出し、
（ｅ３）第２種の組毎の期待値を基に、解を決定する、
請求項１に記載の需給マッチング装置。
（ｅ１）旅客と、クラスタと、前記抽出された部分交通ネットワークにおける区間との組である第１種の組毎に、当該旅客が当該クラスタに所属する場合に当該区間を通る確率である所属確率を算出し、
（ｅ２）クラスタと、前記抽出された部分交通ネットワークにおける区間との組である第２種の組毎に、当該第２種の組について得られた全旅客の所属確率を基に、当該クラスタのうち当該区間を通る旅客の割合である期待値を算出し、
（ｅ３）第２種の組毎の期待値を基に、解を決定する、
請求項１に記載の需給マッチング装置。
【請求項9】
前記記憶装置が、経路に関する情報と旅客による受け入れ可否との履歴を表す情報である旅客受け入れ履歴情報を記憶し、
前記プロセッサが、
前記対象旅客が属するクラスタに割り当てられ前記対象旅客の仮経路に含まれていない前記決定された解に従う区間を含んだ経路である新経路を、当該新経路を前記対象旅客端末に通知し、
当該新経路に関する情報を前記旅客受け入れ履歴情報に含め、
前記新経路の受け入れ可否の回答を前記対象旅客端末から受け、当該回答を、前記通知された新経路について前記旅客受け入れ履歴情報に含め、
（ｅ１）の算出は、前記旅客受け入れ履歴情報を基に学習された機械学習モデルを用いて行われる、
請求項８に記載の需給マッチング装置。
前記プロセッサが、
前記対象旅客が属するクラスタに割り当てられ前記対象旅客の仮経路に含まれていない前記決定された解に従う区間を含んだ経路である新経路を、当該新経路を前記対象旅客端末に通知し、
当該新経路に関する情報を前記旅客受け入れ履歴情報に含め、
前記新経路の受け入れ可否の回答を前記対象旅客端末から受け、当該回答を、前記通知された新経路について前記旅客受け入れ履歴情報に含め、
（ｅ１）の算出は、前記旅客受け入れ履歴情報を基に学習された機械学習モデルを用いて行われる、
請求項８に記載の需給マッチング装置。
【請求項10】
（ｅ３）において、前記プロセッサは、
（ｅ３ａ）第２種の組毎に予測された旅客数と、前記交通ネットワーク情報とを基に、一つ以上の解を算出し、
（ｅ３ｂ）当該一つ以上の解のうち未選択の一つの解を選択し、
（ｅ３ｃ）前記交通ネットワーク情報を基に、（ｅ３ｂ）で選択された解が、輸送サービスの追加の手配を必要とする解か否かを判定し、
（ｅ３ｄ）（ｅ３ｃ）の判定の結果が偽の場合、（ｅ３ｂ）で選択された解を、決定された解とする、
請求項８に記載の需給マッチング装置。
（ｅ３ａ）第２種の組毎に予測された旅客数と、前記交通ネットワーク情報とを基に、一つ以上の解を算出し、
（ｅ３ｂ）当該一つ以上の解のうち未選択の一つの解を選択し、
（ｅ３ｃ）前記交通ネットワーク情報を基に、（ｅ３ｂ）で選択された解が、輸送サービスの追加の手配を必要とする解か否かを判定し、
（ｅ３ｄ）（ｅ３ｃ）の判定の結果が偽の場合、（ｅ３ｂ）で選択された解を、決定された解とする、
請求項８に記載の需給マッチング装置。
【請求項11】
前記インターフェース装置は、複数の交通運行管理サーバと通信可能であり、
前記交通運行管理サーバは、交通事業者が提供する輸送サービスにおける交通手段の運行を管理するサーバであり、
（ｅ３）において、前記プロセッサは、
（ｅ３ａ）第２種の組毎に予測された旅客数と、前記交通ネットワーク情報とを基に、一つ以上の解を算出し、
（ｅ３ｂ）当該一つ以上の解のうち未選択の一つの解を選択し、
（ｅ３ｃ）前記交通ネットワーク情報を基に、当該選択された解が、輸送サービスの追加の手配を必要とする解か否かを判定し、
（ｅ３ｄ）（ｅ３ｃ）の判定の結果が真の場合、追加の手配が必要な輸送サービス毎に当該輸送サービスに対応した一つ以上の交通運行管理サーバに追加の手配を依頼し、
（ｅ３ｅ）（ｅ３ｄ）で依頼がされた全ての交通運行管理サーバから承認の回答を受けた場合、（ｅ３ｂ）で選択された解を、決定された解とし、
（ｅ３ｆ）（ｅ３ｄ）で依頼がされた少なくとも一つ交通運行管理サーバから承認の回答が無かったと判断した場合、（ｅ３ｂ）を行う、
請求項８に記載の需給マッチング装置。
前記交通運行管理サーバは、交通事業者が提供する輸送サービスにおける交通手段の運行を管理するサーバであり、
（ｅ３）において、前記プロセッサは、
（ｅ３ａ）第２種の組毎に予測された旅客数と、前記交通ネットワーク情報とを基に、一つ以上の解を算出し、
（ｅ３ｂ）当該一つ以上の解のうち未選択の一つの解を選択し、
（ｅ３ｃ）前記交通ネットワーク情報を基に、当該選択された解が、輸送サービスの追加の手配を必要とする解か否かを判定し、
（ｅ３ｄ）（ｅ３ｃ）の判定の結果が真の場合、追加の手配が必要な輸送サービス毎に当該輸送サービスに対応した一つ以上の交通運行管理サーバに追加の手配を依頼し、
（ｅ３ｅ）（ｅ３ｄ）で依頼がされた全ての交通運行管理サーバから承認の回答を受けた場合、（ｅ３ｂ）で選択された解を、決定された解とし、
（ｅ３ｆ）（ｅ３ｄ）で依頼がされた少なくとも一つ交通運行管理サーバから承認の回答が無かったと判断した場合、（ｅ３ｂ）を行う、
請求項８に記載の需給マッチング装置。
【請求項12】
（Ａ）コンピュータが、対象旅客の対象旅客端末から移動需要を受け付け、当該移動需要を表す情報を移動需要情報に含め、
前記移動需要情報は、旅客毎の移動需要を表す情報であり、
前記対象旅客は、いずれかの旅客であり、
前記対象旅客端末は、前記対象旅客の旅客端末であり、
旅客端末は、旅客の情報処理端末であり、
移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含み、
（Ｂ）コンピュータが、前記移動需要情報及び交通ネットワーク情報を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定し、
前記交通ネットワーク情報は、交通ネットワークを表す情報であり、
前記交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフ構造のネットワークであり、
ノードは、旅客が乗車及び降車のうちの少なくとも一つを行い得る場所に対応し、
リンクは、輸送サービスに対応し、
同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在し、
前記交通ネットワーク情報は、輸送サービス毎に、輸送サービスの定員と輸送サービスのサービスレベルに関する情報とを含み、
（Ｃ）コンピュータが、当該一つ以上の問題リンクを含み前記交通ネットワークの一部分としてのグラフである部分交通ネットワークを抽出し、
（Ｄ）コンピュータが、仮経路情報及び前記移動需要情報を基に、前記部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、
前記仮経路情報は、旅客毎の仮経路を表す情報であり、
仮経路は、出発地から目的地までの仮の経路であり、
（Ｅ）コンピュータが、生成された各クラスタと前記交通ネットワーク情報とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行い、
前記決定された解は、前記部分交通ネットワークにおける区間毎のクラスタ割当てであり、
前記部分交通ネットワークにおいて、区間は、ノード間が異なる一つ以上のリンクであり、
（Ｆ）コンピュータが、前記決定された解が、前記対象旅客について仮経路に含まれない区間を含む場合、前記対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、
（Ｇ）コンピュータが、前記対象旅客端末からの移動需要に対する応答として、前記対象旅客の確定経路に関する情報を前記対象旅客端末に送信する、
需給マッチング方法。
前記移動需要情報は、旅客毎の移動需要を表す情報であり、
前記対象旅客は、いずれかの旅客であり、
前記対象旅客端末は、前記対象旅客の旅客端末であり、
旅客端末は、旅客の情報処理端末であり、
移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含み、
（Ｂ）コンピュータが、前記移動需要情報及び交通ネットワーク情報を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定し、
前記交通ネットワーク情報は、交通ネットワークを表す情報であり、
前記交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフ構造のネットワークであり、
ノードは、旅客が乗車及び降車のうちの少なくとも一つを行い得る場所に対応し、
リンクは、輸送サービスに対応し、
同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在し、
前記交通ネットワーク情報は、輸送サービス毎に、輸送サービスの定員と輸送サービスのサービスレベルに関する情報とを含み、
（Ｃ）コンピュータが、当該一つ以上の問題リンクを含み前記交通ネットワークの一部分としてのグラフである部分交通ネットワークを抽出し、
（Ｄ）コンピュータが、仮経路情報及び前記移動需要情報を基に、前記部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成し、
前記仮経路情報は、旅客毎の仮経路を表す情報であり、
仮経路は、出発地から目的地までの仮の経路であり、
（Ｅ）コンピュータが、生成された各クラスタと前記交通ネットワーク情報とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行い、
前記決定された解は、前記部分交通ネットワークにおける区間毎のクラスタ割当てであり、
前記部分交通ネットワークにおいて、区間は、ノード間が異なる一つ以上のリンクであり、
（Ｆ）コンピュータが、前記決定された解が、前記対象旅客について仮経路に含まれない区間を含む場合、前記対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、
（Ｇ）コンピュータが、前記対象旅客端末からの移動需要に対する応答として、前記対象旅客の確定経路に関する情報を前記対象旅客端末に送信する、
需給マッチング方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、需給マッチングに関する。
【背景技術】
【0002】
交通手段（例えば、バス、電車及びタクシー）を用いた輸送サービスの供給と、交通手段を利用する旅客の需要との適切なマッチングが行われることが望ましい。特許文献１には、リソースの利用条件と提供条件との双方を満たしつつ、リソースの需要と供給を制御するための技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】ＷＯ２０１９／０９３２５５
【発明の概要】
【発明が解決しようとする課題】
【0004】
交通事業者にとって、輸送サービスの品質と運用効率（例えば採算性）を両立することは重要である。例えば、交通手段がバスの場合、バスの本数が不十分であると、サービスの品質が低下し（例えば、乗車までの待ち時間が長くなり、或いは、車内が混雑し）、バスの本数が過剰であると、運用効率が低下する。
【0005】
一方、旅客の移動需要は様々である。例えば、着席できさえすれば良いという旅客もいれば、目的地に着きさえすれば良いという旅客もいる。
【0006】
本発明は、旅客の多種多様な移動需要を満たすことと輸送サービスの運用効率を維持することとを両立した需給マッチングを実現することを目的とする。
【課題を解決するための手段】
【0007】
需給マッチング装置が構築される。需給マッチング装置は、旅客毎の移動需要を表す情報である移動需要情報と、旅客毎の仮経路（出発地から目的地までの仮の経路）を表す情報である仮経路情報と、交通ネットワークを表す情報である交通ネットワーク情報とを参照する。移動需要は、出発地と、目的地と、旅客の輸送に関する一つ又は複数の項目の各々について要求するレベルである要求サービスレベルとを含む。交通ネットワークは、複数のノードと複数のリンクとで構成されたグラフ構造のネットワークである。ノードは、旅客が乗車及び降車のうちの少なくとも一つを行い得る場所に対応する。リンクは、輸送サービスに対応する。同一のノード間に、一つ以上の輸送サービスに対応した一つ以上のリンクが存在する。交通ネットワーク情報は、輸送サービス毎に、輸送サービスの定員と輸送サービスのサービスレベルに関する情報とを含む。需給マッチング装置は、対象旅客（いずれかの旅客）の対象旅客端末（対象旅客の旅客端末）から移動需要を受け付け、当該移動需要を表す情報を移動需要情報に含める。需給マッチング装置は、移動需要情報及び交通ネットワーク情報を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定する。需給マッチング装置は、当該一つ以上の問題リンクを含み交通ネットワークの一部分としてのグラフである部分交通ネットワークを抽出する。需給マッチング装置は、仮経路情報及び移動需要情報を基に、部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成する。需給マッチング装置は、生成された各クラスタと交通ネットワーク情報とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行う。決定された解は、部分交通ネットワークにおける区間毎のクラスタ割当てである。部分交通ネットワークにおいて、区間は、ノード間が異なる一つ以上のリンクである。決定された解が、対象旅客について仮経路に含まれない区間を含む場合、需給マッチング装置は、対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、対象旅客端末からの移動需要に対する応答として、対象旅客の確定経路に関する情報を対象旅客端末に送信する。
【発明の効果】
【0008】
本発明によれば、旅客の多種多様な移動需要を満たすことと輸送サービスの運用効率を維持することとを両立した需給マッチングを実現することができる。
【図面の簡単な説明】
【0009】
【図1】本発明の一実施形態に係るシステム全体の構成例を示す。
【図2】需給マッチングサーバのハードウェア構成例を示す。
【図3】需給マッチングサーバの機能構成例を示す。
【図4】旅客アプリケーション部の処理の流れを示す。
【図5A】輸送サービス要求ＵＩ（User Interface）の例を示す。
【図5B】受入れ問合せＵＩの例を示す。
【図5C】チケットＵＩの例を示す。
【図6】需給マッチングバッチ処理の流れを示す。
【図7】部分交通ネットワークの抽出処理の流れを示す。
【図8】部分交通ネットワーク生成処理の流れを示す。
【図9】仮の部分交通ネットワークの生成の一例を模式的に示す。
【図10】部分交通ネットワーク再構成処理の流れを示す。
【図11】運用制約テーブルの構成例を示す。
【図12】需要クラスタ生成処理の流れを示す。
【図13】移動需要テーブルの構成例を示す。
【図14】需要クラスタリングテーブルの構成例を示す。
【図15】需給最適化処理の流れを示す。
【図16】クラスタ内旅客カウント処理の流れを示す。
【図17】旅客受け入れ履歴ＤＢの構成例を示す。
【図18A】期待値管理テーブルの構成例を示す。
【図18B】部分交通ネットワークの例を示す。
【図19】本実施形態に係る区間管理テーブルの構成例を示す。
【図20】一比較例に係る区間管理テーブルの構成例を示す。
【図21】所属確率管理テーブルの構成例を示す。
【図22】需給マッチングの一例を模式的に示す。
【発明を実施するための形態】
【0010】
以下の説明では、「インターフェース装置」は、一つ以上のインターフェースデバイスでよい。当該一つ以上のインターフェースデバイスは、下記のうちの少なくとも一つでよい。
・一つ以上のＩ／Ｏ（Input/Output）インターフェースデバイスであるＩ／Ｏインターフェース装置。Ｉ／Ｏ（Input/Output）インターフェースデバイスは、Ｉ／Ｏデバイスと遠隔の表示用計算機とのうちの少なくとも一つに対するインターフェースデバイスである。表示用計算機に対するＩ／Ｏインターフェースデバイスは、通信インターフェースデバイスでよい。少なくとも一つのＩ／Ｏデバイスは、ユーザインターフェースデバイス、例えば、キーボード及びポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・一つ以上の通信インターフェースデバイスである通信インターフェース装置。一つ以上の通信インターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
・一つ以上のＩ／Ｏ（Input/Output）インターフェースデバイスであるＩ／Ｏインターフェース装置。Ｉ／Ｏ（Input/Output）インターフェースデバイスは、Ｉ／Ｏデバイスと遠隔の表示用計算機とのうちの少なくとも一つに対するインターフェースデバイスである。表示用計算機に対するＩ／Ｏインターフェースデバイスは、通信インターフェースデバイスでよい。少なくとも一つのＩ／Ｏデバイスは、ユーザインターフェースデバイス、例えば、キーボード及びポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・一つ以上の通信インターフェースデバイスである通信インターフェース装置。一つ以上の通信インターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
【0011】
また、以下の説明では、「メモリ」は、一つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも一つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。
【0012】
また、以下の説明では、「永続記憶装置」は、一つ以上の永続記憶デバイスである。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）であり、具体的には、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。
【0013】
また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。
【0014】
また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサデバイスである。少なくとも一つのプロセッサデバイスは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサデバイスであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサデバイスでもよい。少なくとも一つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも一つのプロセッサデバイスは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサデバイスでもよい。
【0015】
また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。
【0016】
また、以下の説明では、「ｘｘｘＤＢ」や「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし（例えば、構造化データでもよいし非構造化データでもよいし）、入力に対する出力を発生するニューラルネットワーク、遺伝的アルゴリズムやランダムフォレストに代表されるような学習モデルでもよい。従って、「ｘｘｘＤＢ」や「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各ＤＢ（及び各テーブル）の構成は一例であり、一つのＤＢ（及び一つテーブル）は、二つ以上のＤＢ（二つ以上のテーブル）に分割されてもよいし、二つ以上のＤＢ（二つ以上のテーブル）の全部又は一部が一つのＤＢ（一つのテーブル）であってもよい。
【0017】
以下、図面を用いて本発明の一実施形態を説明する。
【0018】
図１は、本実施形態に係るシステム全体の構成例を示す。
【0019】
一般に、地域には、複数種類の交通手段を用いた複数種類の輸送サービスがあり、それら複数種類の輸送サービスは、異なる交通事業者によって提供される。
【0020】
本実施形態では、需給マッチングサーバ１０が設けられる。需給マッチングサーバ１０は、複数の交通事業者の各々の交通運行管理サーバ２０と、複数の旅客の各々の旅客端末３０と、通信ネットワーク４０（例えばインターフェース）を介して通信する。サーバ１０及び２０のいずれも、物理的な計算機システム（一つ以上の物理的な計算機）でもよいし、物理的な計算機システム（例えば、複数種類の物理的な計算リソースを有するクラウド基盤）に基づく論理的な計算機システム（例えば、クラウドコンピューティングサービス）でもよい。
【0021】
交通運行管理サーバ２０は、輸送サービスの手配や交通手段の管理を行う。「輸送サービス」は、車両に乗った旅客を輸送するサービスである。「交通手段」は、典型的には車両であり、例えば、定期運行型、デマンド交通型、シェア型又はＤＨ（ダイナミックヘッドウェイ）型の交通システムにおける車両（例えば、鉄道、バス、タクシー、乗用車又は自転車）である。本明細書において、旅客の「輸送」は、旅客自身が車両（例えば、シェア型の交通システムにおける乗用車又は自転車）を運転して移動することも含む広義の輸送である。
【0022】
旅客端末３０は、旅客の情報処理端末（典型的には、スマートフォンのようなモバイル型の情報処理端末）である。旅客端末３０は、例えば、輸送サービスの予約やチケッティングに用いられる。
【0023】
需給マッチングサーバ１０は、複数の交通運行管理サーバ２０と複数の旅客端末３０と通信し、移動需要と輸送サービスとのマッチングである需給マッチングを行う。
【0024】
図２は、需給マッチングサーバ１０のハードウェア構成例を示す。
【0025】
需給マッチングサーバ１０は、Ｉ／Ｏインターフェース装置１０７と、通信インターフェース装置１０５と、プログラムやデータを記憶する記憶装置（永続記憶装置１０４及びメモリ１０３）と、それらに接続されたプロセッサ１０１とを有する。Ｉ／Ｏインターフェース装置１０７は、キーボードやマウス等の入力デバイス１０８と、液晶ディスプレイや有機ＥＬディスプレイ等の表示デバイス１０９のインターフェースである。
【0026】
図３は、需給マッチングサーバ１０の機能構成例を示す。
【0027】
需給マッチングサーバ１０は、移動需要ＤＢ１２８と、仮経路ＤＢ１２９と、確定経路ＤＢ１３０と、旅客受け入れ履歴ＤＢ１３１と、交通ネットワークＤＢ１３２とを備える。これらのＤＢは、例えば永続記憶装置１０４に格納される。
【0028】
移動需要ＤＢ１２８は、旅客の移動需要を旅客毎に表す情報を格納するデータベースである。本実施形態において、「移動需要」は、顧客の移動に関する要素（例えば、目的地、出発地及び出発時刻など）と、顧客が要求するサービスレベルとで構成される。すなわち、移動需要ＤＢ１２８において、旅客毎に、旅客の移動需要のＩＤと、移動需要を表す情報は、当該旅客の移動情報（例えば、目的地、出発地及び出発時刻などを表す情報）と、当該旅客のサービスレベル情報（輸送サービスについて顧客が要求するサービスレベルを表す情報）とを含む。「サービスレベル」は、輸送サービスに関する複数のサービス項目の各々についてのレベルである。また、本実施形態では、移動需要のＩＤは、旅客のＩＤと同義でよい。すなわち、同一の移動需要が旅客Ａ及びＢから登録された場合、旅客Ａにより登録された移動需要のＩＤと旅客Ｂにより登録された移動需要のＩＤが異なっていてよい。
【0029】
仮経路ＤＢ１２９は、旅客の目的地から出発地までの仮の経路を旅客毎に表す情報を格納するデータベースである。例えば、仮経路ＤＢ１２９は、旅客の移動需要のＩＤ毎に、仮経路を表してよい。
【0030】
確定経路ＤＢ１３０は、旅客の目的地から出発地までの確定した経路を旅客毎に表す情報を格納するデータベースである。例えば、確定経路ＤＢ１３０は、旅客の移動需要のＩＤ毎に、確定経路を表してよい。
【0031】
旅客受け入れ履歴ＤＢ１３１は、新しい経路候補の受け入れ可否に関する履歴を格納するデータベースである。当該履歴は、例えば、旅客の移動需要のＩＤ毎に、一つ以上の新しい経路候補の各々について当該新しい経路候補を受け入れるか否かを表してよい。
【0032】
交通ネットワークＤＢ１３２は、交通ネットワークを表す情報を格納するデータベースである。「交通ネットワーク」は、複数のノードとそれぞれノード間を結ぶ複数のリンクとで構成されたグラフ構造のネットワークである。ノードは、旅客が乗り降り可能な予め決められた車両の停止場所である。リンクは、それらの停止場所を結ぶ物理的又は論理的な路（例えば、線路、道路又は空路）である。交通ネットワークは、複数のサブ交通ネットワークで構成される。一つのサブ交通ネットワークは、複数の輸送サービス（複数の交通手段）のうちの一つの輸送サービスに対応する。交通ネットワークは、複数のサブ交通ネットワークが論理的に同一レイヤとされた一つのネットワークである。鉄道、バス及びタクシーといった複数の交通手段のうちの任意の二つ以上の交通手段の利用が可能な場所に対応したノードは、当該二つ以上の交通手段に複数のサブ交通ネットワークにおいて共通である。すなわち、複数の輸送サービスでノードが共通していれば、異なるサブ交通ネットワーク間でノードだけが重ねられ（共通となり）、リンクは重ならない。例えば、交通ネットワークでは、ノードＡ（駅Ａ）とノードＢ（駅Ｂ）間に、鉄道用のリンクとバス用のリンクといった複数のリンクが存在し得る。一方、サブ交通ネットワークでは、サブ交通ネットワークは一つの輸送サービスに対応しているため、ノード間を結ぶリンクは一つである。輸送サービス別に、サブ交通ネットワークを表す情報が、交通ネットワークＤＢ１３２に含まれていてよい。また、交通ネットワークＤＢ１３２は、ノード毎に、当該ノードに対応した場所の詳細を表す情報（例えば、名称、位置情報、輸送サービス毎に折返し可能か否か、輸送サービス毎の時刻表、混雑状況、遅延状況等）を含んでよく、また、リンク毎に、当該リンクに対応した路の詳細を表す情報（例えば、対応する輸送サービス（交通手段）、混雑状況、遅延状況等）を含んでよい。
【0033】
以下の説明では、一つの輸送サービスについて一つのリンクを挟む二つのノードの各々を、便宜上、「隣接ノード」と呼ぶことがある。つまり、隣接ノード間に複数のリンクがある場合、隣接ノード間に異なる複数の輸送サービスがある（一方の隣接ノードに対応した一方の場所から他方の隣接ノードに対応した他方の場所への輸送のサービスとして複数の輸送サービスがある）。
【0034】
また、以下の説明では、出発地（ノード）から目的地（ノード）への連続した一つ以上のリンクの集合を、「経路」と呼ぶことができる。
【0035】
プログラムがプロセッサ１０１に実行されることで、旅客アプリケーション部１２１と、経路検索部１２２と、部分ネットワーク抽出部１２３と、需要クラスタリング部１２４と、旅客カウント部１２５と、需給最適化部１２６と、運行手配部１２７といった機能が実現される。これらの機能の少なくとも一つが、ＤＢ１２８～１３２の少なくとも一つを適宜に参照又は更新する。旅客アプリケーション部１２１が、旅客端末３０と通信する。運行手配部１２７が、交通運行管理サーバ２０と通信する。これらの機能１２１～１２７の詳細は後に説明する。
【0036】
図４は、旅客アプリケーション処理の流れを示す。
【0037】
旅客アプリケーション部１２１は、移動情報及びサービスレベル情報の入力を旅客端末３０から受け付け、当該情報を移動需要ＤＢ１２８に登録する（Ｓ１）。例えば、旅客アプリケーション部１２１は、図５Ａに例示する輸送サービス要求ＵＩ１４０（輸送サービスの要求を入力するための画面）を旅客端末３０に表示する。輸送サービス要求ＵＩ１４０を介して、移動情報（例えば、出発地、目的地、出発時刻及び／又は到着時刻）と、サービスレベル情報（複数のサービス項目の各々についてのレベル）とが入力される。サービスレベル情報の入力はオプションでよい。
【0038】
旅客アプリケーション部１２１は、旅客端末３０から入力された上述の移動情報（及びサービスレベル情報）を基に、経路検索部１２２に経路の検索指示を出し、当該指示に応答して経路検索部１２２により検索された経路である仮経路を表す情報を仮経路ＤＢ１２９に登録する（Ｓ２）。検索指示には、入力された上述の移動情報（及びサービスレベル情報）の少なくとも一部（例えば、出発地、目的地、出発時刻及び／又は到着時刻、及び、複数のサービス項目の各々についてのレベル）が検索条件として関連付けられる。経路検索部１２２は、検索指示に応答して、検索指示に関連付けられている検索条件を満たす経路を交通ネットワークＤＢ１３２から検索し、検索された経路を表す情報を返すようになっている。
【0039】
旅客アプリケーション部１２１は、経路確定の期限が過ぎたか否かを判定する（Ｓ３）。「経路確定」とは、一つ又は複数の経路候補のうちの一つの経路候補を確定経路とすることである。「一つ又は複数の経路候補」は、Ｓ２で登録された仮経路と、Ｓ５で受け入れ可とされた一つ以上の新しい経路候補とのうちの少なくとも仮経路である。「経路確定の期限」は、所定のポリシーで決められた期限でよい（例えば、Ｓ２で仮経路が登録されてから一定期間経った時点でもよいし、最後に新しい経路候補が受入れ可とされてから一定時間経った時点でもよいし、旅客に指定された期限でもよい）。
【0040】
Ｓ３の判定結果が偽の場合（Ｓ３：Ｎｏ）、旅客アプリケーション部１２１は、経路変更通知を受けたか否かを判定する（Ｓ４）。Ｓ４の判定結果が偽の場合（Ｓ４：Ｎｏ）、処理がＳ３に戻る。ここで、「経路変更通知」とは、仮経路（及び通知済の新しい経路候補）とは異なる新しい経路候補が見つかったことの通知である。この通知は、図６に示す需給マッチングバッチ処理において出される（具体的には、図１５のＳ６７で出る通知が、経路変更通知である）。
【0041】
Ｓ４の判定結果が真の場合（Ｓ４：Ｙｅｓ）、旅客アプリケーション部１２１は、経路変更通知に示される新しい経路の候補の受け入れ可否を旅客端末３０から受け付ける（Ｓ５）。例えば、旅客アプリケーション部１２１は、図５Ｂに例示する受入れ問合せＵＩ１５０（新しい経路候補を受け入れるか否かを入力するための画面）を旅客端末３０に表示する。図５Ｂが示す例によれば、二つの新しい経路候補があり、それぞれにチェックボックス５２が用意されている。旅客は、受け入れる新しい経路を選択できる（チェックボックスにチェックを入れることができる）。旅客アプリケーション部１２１は、選択の内容（各新しい経路候補について受け入れが可能か否かを示す情報）を旅客受け入れ履歴ＤＢ１３１に登録する（Ｓ６）。その後、処理がＳ３に戻る。
【0042】
Ｓ３の判定結果が真の場合（Ｓ３：Ｙｅｓ）、旅客アプリケーション部１２１は、確定経路を決定し、仮経路ＤＢ１２９から、Ｓ２で登録した仮経路の情報を削除し、確定経路を表す情報を確定経路ＤＢ１３０に登録する（Ｓ７）。「確定経路」は、上述したように、一つ又は複数の経路候補のうちの一つの経路候補であるが、具体的には、例えば、下記でよい。
・一つ以上の受入れ可の新しい経路候補を表す情報が旅客受け入れ履歴ＤＢ１３１に登録されている場合、当該一つ以上の受入れ可の新しい経路候補から得られた一つの新しい経路候補が、確定経路となる。この新しい経路候補は、最後に受入れ可とされた新しい経路候補でもよいし、ランダムに選択された新しい経路候補でもよいし、旅客から選択された経路候補でもよい。
・受入れ可の新しい経路候補が一つも無い場合、仮経路が、確定経路となる。
・一つ以上の受入れ可の新しい経路候補を表す情報が旅客受け入れ履歴ＤＢ１３１に登録されている場合、当該一つ以上の受入れ可の新しい経路候補から得られた一つの新しい経路候補が、確定経路となる。この新しい経路候補は、最後に受入れ可とされた新しい経路候補でもよいし、ランダムに選択された新しい経路候補でもよいし、旅客から選択された経路候補でもよい。
・受入れ可の新しい経路候補が一つも無い場合、仮経路が、確定経路となる。
【0043】
Ｓ７の後、旅客アプリケーション部１２１は、確定経路に従い移動するための輸送サービスのデジタルチケットを旅客端末３０に発行する（Ｓ８）。発行されたデジタルチケットを表示した画面であるチケットＵＩ１６０が、図５Ｃに例示の通り旅客端末３０に表示される。チケットＵＩ１６０には、確定経路「Ａ→Ｃ：鉄道、Ｃ→Ｅ：デマンドバス」（Ａ地点からＣ地点へは鉄道で移動し、Ｃ地点からＥ地点まではデマンドバスで移動する経路）を表す情報が表示される。また、チケットＵＩ１６０には、確定経路のデジタルチケットのオブジェクト１６３が表示される。オブジェクト１６３が指定されると、チケットの内容の詳細が表示される。
【0044】
図４に示した処理によれば、「経路確定の期限」になるまでの間（Ｓ３：Ｙｅｓとなるまでの間）、図６に示すバッチ処理において「新しい経路」が見つかった場合には、Ｓ４：ＹｅｓとなりＳ５が行われる。一方、「経路確定の期限」になるまでの間、図６に示すバッチ処理が行われない（例えば、「経路確定の期限」までの期間が短い（例えば、リアルタイムでの応答が求められている））又はバッチ処理が行われても「新しい経路」が見つからなかった場合には、Ｓ７で仮経路が確定経路となる。
【0045】
図６は、需給マッチングバッチ処理の流れを示す。この処理は、定期的に行われる。
【0046】
部分交通ネットワークの抽出処理が行われる（Ｓ１１）。次に、需要クラスタ生成処理が行われる（Ｓ１２）。最後に、需給最適化処理が行われる（Ｓ１３）。以下、これらＳ１１～Ｓ１３の処理を詳細に説明する。
【0047】
なお、部分交通ネットワークにおいて、連続した一つ以上のリンクの集合を、「区間」と呼ぶことができる。「区間」は、経路の一部であることもあり得る。区間を構成する「連続した一つ以上のリンク」では、同一の隣接ノード間に存在するリンクは一つであり、且つ、区間が二つ以上のリンクの場合、リンクとリンクがノードを介して繋がっている。本実施形態では、「区間」は、典型的には、一つのリンク、又は、連続した二つのリンク（同一ノードに繋がった二つのリンク）でよい。
【0048】
また、以下の説明では、部分交通ネットワークにおいて、連続した一つ以上の区間を「パス」と呼ぶことができる。「パス」は、経路の一部であることもあり得る。
【0049】
＜図６のＳ１１：部分交通ネットワークの抽出処理＞
【0050】
【0051】
部分ネットワーク抽出部１２３は、要求サービスレベルが満たされる旅客の数を輸送サービス（サブ交通ネットワーク）のリンク毎に計算する（Ｓ２１）。具体的には、例えば、下記が行われる。
・部分ネットワーク抽出部１２３が、移動需要ＤＢ１２８及び確定経路１３０を参照し、経路が確定していない移動需要を特定する。
・部分ネットワーク抽出部１２３が、経路が確定していない移動需要毎に、取り得る経路（仮経路や新経路（新しい経路候補））を、仮経路ＤＢ１２９及び旅客受け入れ履歴ＤＢ１３１から特定する。
・部分ネットワーク抽出部１２３が、特定された取り得る経路毎に、当該経路に対応した移動需要と、交通ネットワークＤＢ１３２（例えば、交通ネットワークの構成、及び、リンク毎の情報）とから、リンク毎に、要求サービスレベルが満たされる旅客の数を、輸送サービス（サブ交通ネットワーク）のリンク毎に計算する。
・部分ネットワーク抽出部１２３が、移動需要ＤＢ１２８及び確定経路１３０を参照し、経路が確定していない移動需要を特定する。
・部分ネットワーク抽出部１２３が、経路が確定していない移動需要毎に、取り得る経路（仮経路や新経路（新しい経路候補））を、仮経路ＤＢ１２９及び旅客受け入れ履歴ＤＢ１３１から特定する。
・部分ネットワーク抽出部１２３が、特定された取り得る経路毎に、当該経路に対応した移動需要と、交通ネットワークＤＢ１３２（例えば、交通ネットワークの構成、及び、リンク毎の情報）とから、リンク毎に、要求サービスレベルが満たされる旅客の数を、輸送サービス（サブ交通ネットワーク）のリンク毎に計算する。
【0052】
部分ネットワーク抽出部１２３は、輸送サービスの運用効率を輸送サービスのリンク毎に計算する（Ｓ２２）。例えば、運用効率は、コストに対する予測収入の割合でよい。具体的には、例えば、部分ネットワーク抽出部１２３は、交通ネットワークＤＢ１３２及び確定経路１３０を基に、輸送サービスのリンク毎に、時間帯における旅客数と車両運行数とを特定し、当該旅客数及び車両運行数とを基に、運用効率を計算してよい。なお、輸送サービスのリンク毎に、時間帯における旅客数の特定は、各交通運行管理サーバから入手可能な過去の運行管理情報を基に、時間帯における旅客数を予測することでもよい。
【0053】
部分ネットワーク抽出部１２３は、Ｓ２１で算出された旅客数（サービスレベルが満たされる旅客の数）が絶対的に又は相対的に少ないリンク、及び／又は、Ｓ２２で算出された運用効率が絶対的に又は相対的に低いリンクをリストアップする（Ｓ２３）。Ｓ２１で算出された旅客数が少ないリンクとは、具体的には、当該旅客数が閾値θｐａｓｓｅｎｇｅｒを下回ったリンクである。Ｓ２２で算出された運用効率が低いリンクとは、当該運用効率が閾値θｔｒａｎｓｐｏｒｔａｔｉｏｎを下回ったリンクである。θｔｒａｎｓｐｏｒｔａｔｉｏｎは、予測収入がコストより小さくなる輸送サービスの数の閾値とされてもよい。
【0054】
部分ネットワーク抽出部１２３は、Ｓ２３でリストアップされたリンクの情報を基に部分交通ネットワーク生成処理を行う（Ｓ２４）。以下、Ｓ２３でリストアップされた各リンクを、「問題リンク」と総称することがある。「問題リンク」は、サービスレベルが満たされる旅客の数が少ないリンク、又は、運用効率が低いリンクである。
【0055】
【0056】
部分ネットワーク抽出部１２３は、仮の部分交通ネットワークを構成する（Ｓ３１）。仮の部分交通ネットワークは、リストアップされた問題リンク毎にその近傍のリンクがつなげられたネットワークである。「近傍のリンク」は、問題リンクを挟む両端のノードのいずれかに繋がっているノードでよい。問題リンクの近傍のリンクは、別の問題リンクであることもあれば、問題リンクではないリンクであることもある。Ｓ３１では、例えば図９の上側に示すように、太線で表現された問題リンクに近傍リンクがつなげられることで、図９の下側に示すような部分交通ネットワークが構成される。なお、図９の下側に例示の部分交通ネットワークの端点のノードは、ノードＡ及びＥである。破線矢印は、部分交通ネットワークの外から部分交通ネットワークに入る旅客や、部分交通ネットワークからその外に出る旅客を意味する。
【0057】
部分ネットワーク抽出部１２３は、仮の部分交通ネットワークの端点のノードが運用制約を満たすように仮の部分交通ネットワークを広げる（Ｓ３２）。「端点のノードが運用制約を満たす」とは、端点のノードが、当該ノードに関わる全ての輸送サービスについて、図１１に例示の運用制約テーブル１７０が表す運用制約を満たすことである。運用制約テーブル１７０は、例えば交通ネットワークＤＢ１３２に含まれる。運用制約テーブル１７０は、ノードと輸送サービスの組毎に、ノードでの折り返し可否を表す。図１１が示す例によれば、鉄道や路線バスは、折り返し可能な場所が限られ、臨時便の区間の設定に制約があることが考慮されている。また、デマンド交通やタクシーなどの輸送サービスについては、全ての場所が折り返し可能として管理される。
【0058】
なお、運用制約は緩くされてもよい。例えば、「端点のノードで折り返しできない輸送サービスの数又は割合がα以下」が、運用制約であってもよい。すなわち、「α」は、端点のノードに繋がるリンクの数（輸送サービスの数）でもよいし、端点のノードに繋がるリンクの数に対する、折り返しできない輸送サービスの数の割合、でもよい。本実施形態では、通常、「α」の値は０である。すなわち、本実施形態では、原則として、各輸送サービスについて、部分交通ネットワークの端点ノードは、折り返し可能なノードである。
【0059】
部分ネットワーク抽出部１２３は、重複するリンクを持つ複数の部分交通ネットワークがある場合（つまり、一部が互いに重複した複数の部分交通ネットワークがある場合）、それらの部分交通ネットワークを結合させる（Ｓ３３）。これにより、それら複数の部分交通ネットワークは一つの部分交通ネットワークとされる。そのような複数の部分交通ネットワークが無い場合、Ｓ３３はスキップされる。
【0060】
その後、部分ネットワーク抽出部１２３は、部分交通ネットワーク毎に、部分交通ネットワーク再構成処理を行う（Ｓ３４）。この結果、再構成された部分交通ネットワークがあれば（Ｓ３５：Ｙｅｓ）、処理が、Ｓ３３に戻る。
【0061】
【0062】
部分ネットワーク抽出部１２３は、対象ネットワークにおける問題リンクを最も多く通る経路について代替パス数を計算する（Ｓ４１）。ここで、図９の例によれば、経路がノードＢ及びＤを経由し、問題リンクがリンクＴ５の場合、代替パス数は“３”、すなわち、代替パスは、リンクＴ４及びＴ７の組、リンクＴ４及びＴ８の組、及び、リンクＴ６である。
【0063】
部分ネットワーク抽出部１２３は、Ｓ４１で算出された代替パス数がβｍａｘ以下か否かを判定する（Ｓ４２）。βｍａｘは、部分交通ネットワーク内の代替パス数の上限である。この値を設定することで、部分交通ネットワークの大きさを制限し、以って、後述の需給最適化処理（図１５）において組合せ爆発を防ぐことができる。
【0064】
Ｓ４２の判定結果が真の場合（Ｓ４２：Ｙｅｓ）、部分ネットワーク抽出部１２３は、Ｓ４１で算出された代替パス数がβｍｉｎ以上であるか否かを判定する（Ｓ４３）。βｍｉｎは、部分交通ネットワーク内の代替パス数の下限である。この値を設定することで、問題最適化のための代替パスが設定できないことを防ぐことができる。Ｓ４３の判定結果が真の場合（Ｓ４３：Ｙｅｓ）、処理が終了する。Ｓ４３の判定結果が偽の場合（Ｓ４３：Ｎｏ）、部分ネットワーク抽出部１２３は、対象ネットワークの両端のノードから最も近傍の折り返し可能ノードまで対象ネットワークを拡大させる（Ｓ４４）。拡大後のネットワークについては、代替パス数がβｍｉｎ以上となることが期待される。
【0065】
Ｓ４２の判定結果が偽の場合（Ｓ４２：Ｎｏ）、部分ネットワーク抽出部１２３は、対象ネットワーク内に運用制約を満たすノードがあるか否かを判定する（Ｓ４５）。Ｓ４５の判定結果が偽の場合（Ｓ４５：Ｎｏ）、処理が終了する。なお、「運用制約を満たすノード」の有無は、図１１に示した運用制約テーブル１７０から特定される。
【0066】
Ｓ４５の判定結果が真の場合（Ｓ４５：Ｙｅｓ）、部分ネットワーク抽出部１２３は、運用制約を満たすノードを境に対象ネットワークを分割しても代替パス数がβｍｉｎ以上か否かを判定する（Ｓ４６）。Ｓ４６の判定結果が偽の場合（Ｓ４６：Ｎｏ）、処理が終了する。Ｓ４６の判定結果が真の場合（Ｓ４６：Ｙｅｓ）、部分ネットワーク抽出部１２３は、対象ネットワークを、運用制約を満たすノードを境に分割する（Ｓ４７）。
【0067】
以上が、部分交通ネットワークの抽出処理（図６のＳ１１）の説明である。この処理において抽出された部分交通ネットワークを表す情報は、交通ネットワークＤＢ１３２に格納される。また、ここで抽出された部分交通ネットワークは、上述したように、図７のＳ２３でリストアップされた問題リンクを基に構築されたネットワークである。複数の部分交通ネットワークが抽出された場合、各部分交通ネットワークの情報が交通ネットワークＤＢ１３２に格納される。
【0068】
部分交通ネットワークの抽出処理に関する総括として、例えば下記の通りである。
【0069】
部分交通ネットワークは、一つ以上の問題リンクの影響を受け得る範囲としてのネットワークであり交通ネットワークの一部としてのグラフである。このような部分交通ネットワークがない場合、交通ネットワークのいずれかのリンクが問題リンクとなる度に多くの経路を探索しなければならなくなる。これにより、経路数が莫大な数となり、この後の需給最適化において解が得られない（又は、解を得るのに非常に時間がかかってしまう）おそれがある。問題リンクが関係する部分としての部分交通ネットワークを抽出することで、最適化問題を小さくして解を得やすくする（解き易くする）ことができる。言い換えると、本実施形態では、部分交通ネットワーク以外の範囲は最適化問題の対象外であるため、問題リンクが無い範囲についての処理が避けられ、以って、計算に要する時間及びリソースを節約することができる。
【0070】
＜図６のＳ１２：需要クラスタ生成処理＞
【0071】
【0072】
需要クラスタリング部１２４は、移動需要ＤＢ１２８、交通ネットワークＤＢ１３２及び仮経路ＤＢ１２９を参照し、部分交通ネットワークを通る仮経路に対応した移動需要（旅客）を特定する（Ｓ５１）。一つの部分交通ネットワークについて、当該部分交通ネットワークを通る仮経路として、一つ以上の仮経路があり得る。
【0073】
需要クラスタリング部１２４は、交通ネットワークＤＢ１３２を基に、部分交通ネットワークのうち仮経路に含まれるノード毎に、時刻を特定する（Ｓ５２）。例えば、交通ネットワークＤＢ１３２が、輸送サービス毎に、各ノードでの到着時刻や出発時刻や、車両の平均速度等を表す情報である時刻管理情報を含む。この時刻管理情報を基に、Ｓ５２における時刻特定が行われてよい。
【0074】
需要クラスタリング部１２４は、移動需要ＤＢ１２８から、Ｓ５１で特定された移動需要（旅客）について、サービスレベルを特定する（Ｓ５３）。
【0075】
需要クラスタリング部１２４は、Ｓ５３で特定されたサービスレベルとＳ５２で特定されたノード毎の時刻から、Ｓ５１で特定された移動需要をクラスタリングする（Ｓ５４）。
【0076】
需要クラスタリング部１２４は、移動需要のクラスタ毎の代表値を算出する（Ｓ５５）。
【0077】
以上の通り、クラスタは、同一又は類似の移動需要の集合である。本実施形態では、旅客毎に移動需要が存在するため、クラスタは、移動需要が同一又は類似である旅客の集合と言うこともできる。抽出された部分交通ネットワークを経路（典型的には仮経路）が通る旅客のみについてクラスタが生成されるので、最適化問題を小さくすることができる。
【0078】
また、移動需要のクラスタリングでは、必ずしも出発地と目的地が使用されないでもよい。例えば、部分交通ネットワーク内に出発地か目的地（或いはその両方）が存在する移動需要は、出発地及び目的地の少なくとも一つがクラスタリングに使用されてもよい。一方、出発地と目的地の少なくとも一つが部分交通ネットワークの外にある場合、当該外にある出発地及び／又は目的地は、常にクラスタリングに使用されないでもよいし、或いは、当該外にある出発地及び／又は目的地と部分交通ネットワークの端点のノードとの間の距離を基に、当該外にある出発地及び／又は目的地がクラスタリングに使用されるか否かが決定されてよい。一つのクラスタは、例えば、部分交通ネットワーク内に出発地及び／又は目的地がある、部分交通ネットワーク外の出発地及び／又は目的地の遠さ、及び、要求サービスレベル（例えば、混雑度合、遅延度合、着席確実性といった移動嗜好）といった移動需要要素が同一又は類似の旅客の集合である。
【0079】
以下、図１２に示した需要クラスタ生成処理をより詳細に説明する。
【0080】
図１３は、移動需要テーブル１８０の構成例を示す。
【0081】
Ｓ５４の移動需要のクラスタリングでは、移動需要テーブル１８０が参照される。移動需要テーブル１８０は、移動需要ＤＢ１２８に格納される。移動需要テーブル１８０は、移動需要毎にレコードを有する。各レコードは、ＩＤ１８１と、出発地１８２と、出発時刻１８３と、目的地１８４と、到着時刻１８５と、要求サービスレベル１８６といった情報を有する。要求サービスレベル１８６は、要求されるサービスレベルに関し複数のサービス項目の各々についてのレベルを表す情報、例えば、許容混雑１８７と、許容遅延１８８と、着席保障１８９といった情報である。一つの移動需要を例に取る（図１３の説明において「対象移動需要」）。
【0082】
ＩＤ１８１は、対象移動需要のＩＤを表す。出発地１８２は、対象移動需要における出発地（例えばノードのＩＤ）を表す。出発時刻１８３は、対象移動需要における出発時刻（旅客が出発地を出発する時刻）を表す。目的地１８４は、対象移動需要における目的地（例えばノードのＩＤ）を表す。到着時刻１８５は、対象移動需要における到着時刻（旅客が目的地に到着する時刻）を表す。
【0083】
サービス項目として、例えば、許容混雑、許容遅延及び着席保証がある。許容混雑１８７は、旅客が鉄道等の混雑として許容できるレベル（例えば、１５０％までの混雑を許容できる場合、“１５０”）を表す。許容遅延１８８は、旅客が鉄道等の輸送サービスの遅延時間として許容できるレベル（例えば、１０分まで遅延が許容できる場合、“１０”）を表す。着席保障１８９は、旅客が鉄道等の輸送サービスに対して着席のなしを許容できるか否かを要求するレベル（例えば、旅客が輸送サービスに対して、着席なしを許容できる場合、“なし”）を表す。
【0084】
Ｓ５４では、例えば、需要クラスタリング部１２４は、Ｓ５３で特定されたサービスレベルとＳ５２で特定されたノード毎の時刻が類似する移動需要の集合をクラスタとする。具体的には、例えば、需要クラスタリング部１２４は、移動需要毎に、複数種類の情報１８２～１８９の各々の特徴量を算出し、各種情報の特徴量が類似する移動需要の集合をクラスタとする。Ｓ５４において、各クラスタを表す需要クラスタリングテーブルが構築される。
【0085】
【0086】
需要クラスタリングテーブル１９０は、クラスタ毎にレコードを有する。各レコードは、クラスタ番号１９１と、クラスタ所属数１９２、出発地１９３と、出発時刻１９４と、目的地１９５と、到着時刻１９６と、要求サービスレベル１９７といった情報を有する。要求サービスレベル１９７は、許容混雑１９８と、許容遅延１９９と、着席保障２００等を含む。一つのクラスタを例に取る（図１４の説明において「対象クラスタ」）。
【0087】
クラスタ番号１９１は、対象クラスタの識別番号を表す。クラスタ所属数１９２は、対象クラスタに所属する移動需要の数を表す。
【0088】
出発地１９３は、対象クラスタに属する移動需要における出発地（例えば、図１３の出発地１８２の統計値）を表す。出発時刻１９４は、対象クラスタに属する移動需要における出発時刻（例えば、図１３の出発地の統計値）を表す。目的地１９５は、対象クラスタに属する移動需要における目的地（例えば、図１３の目的地１８４の統計値）を表す。到着時刻１９６は、対象クラスタに属する移動需要における到着時刻（例えば、図１３の到着時刻１８５の統計値）を表す。要求サービスレベル１９７の許容混雑１９８は、対象クラスタに属する移動需要における許容混雑（例えば、図１３の許容混雑１８７の統計値）を表す。要求サービスレベル１９７の許容遅延１９９は、対象クラスタに属する移動需要における許容遅延（例えば、図１３の許容遅延１８８の統計値）を表す。要求サービスレベル１９７の着席保障２００は、対象クラスタに属する移動需要における着席保障（例えば、図１３の着席保障１８９の統計値）を表す。
【0089】
図１２のＳ５５では、例えば、需要クラスタリング部１２４は、クラスタ毎に、当該クラスタに対応した複数種類の情報１９２～２００を基に、代表値を算出する。
【0090】
以上が、需要クラスタ生成処理（図６のＳ１２）の説明である。この処理において、部分交通ネットワークを通る仮経路を基に、複数のクラスタ（移動需要（旅客）のクラスタ）が生成される。
【0091】
なお、各クラスタについて算出された代表値は、輸送サービス割り当て対象の移動需要の特徴として利用される。すなわち、後の需給最適化の中で、移動需要は群（クラスタ）としてみなされ、故に、代表値を用いて最適化問題が解かれる。例えば、クラストの代表値を基に、当該クラスタに輸送サービスとしてバス又は鉄道が適しているといった判断が可能である。
【0092】
＜図６のＳ１３：需給最適化処理＞
【0093】
【0094】
需給最適化部１２６は、交通ネットワークＤＢ１３２及び需要クラスタリングテーブル１９０を参照し、クラスタ毎に、当該クラスタに属する移動需要（情報１９３～２００）を満たす区間を探索し、見つかった区間について、利用する交通手段の組合せ候補を列挙する（Ｓ６１）。Ｓ６１では、需給最適化部１２６は、まだ手配されていない臨時交通を含む区間も候補として探索する。臨時交通の情報（例えば、臨時交通としての輸送サービスの種類と経由するノードとを表す情報）は、例えば交通ネットワークＤＢ１３２に格納されている。
【0095】
次に、需給最適化部１２６は、旅客カウント部１２５にクラスタ内旅客カウント処理を実施させる（Ｓ６２）。Ｓ６２では、旅客カウント部１２５は、区間ごとに受け入れてくれる旅客が異なるという仮定の元、クラスタ及び区間の組毎に、当該クラスタのうち当該区間を通る旅客の割合である期待値を計算する。
【0096】
次に、需給最適化部１２６は、各クラスタがどの区間を用いるか、区間を組み換えながら、移動需要（要求サービスレベル）と運用効率を満たすような多目的最適化問題を解き、算出された一つ以上の解候補（解）のうちの一つを選択する（Ｓ６３）。一つの解候補は、例えば、図１９に示す通りである。
【0097】
次に、需給最適化部１２６は、例えば交通ネットワークＤＢ１３２を基に、選択された解候補について輸送サービスの追加の手配が必要か否かを判定する（Ｓ６４）。例えば、解候補の区間経路に臨時便が含まれている場合は、追加手配が必要と判定される（つまり、Ｓ６４の判定結果が真となる）。すなわち、各クラスタの区間経路の候補には、定期便として提供される輸送サービスの他に、不定期運行の輸送サービスが存在することがあり、不定期運行の輸送サービスが存在する場合、追加手配が必要と判定される。
【0098】
Ｓ６４の判定結果が真の場合（Ｓ６４：Ｙｅｓ）、需給最適化部１２６は、選択された解候補について追加の手配が必要な輸送サービスを、当該輸送サービスを提供し得る全ての交通事業者の交通運行管理サーバ２０に提示することを、運行手配部１２７に実施させる（Ｓ６５）。運行手配部１２７が、全ての交通事業者の交通運行管理サーバ２０に、追加の手配を依頼する。具体的には、例えば、選択された解候補に含まれる或るクラスタの区間経路に、臨時バスや臨時列車が含まれていれば（Ｓ６４：Ｙｅｓ）、Ｓ６５において、その臨時バスや臨時列車を担当する交通事業者に追加手配が依頼される。
【0099】
次に、需給最適化部１２６は、Ｓ６４での提示がされた全ての交通事業者が当該提示の受け入れをしたか否かを判定する（Ｓ６６）。Ｓ６６の判定結果が偽の場合（Ｓ６６：Ｎｏ）、次の解候補を選出し（Ｓ６７）、処理がＳ６５に戻る。
【0100】
Ｓ６６の判定結果が真の場合（Ｓ６６：Ｙｅｓ）、需給最適化部１２６は、選択された解候補を、決定された解とし、当該解について、経路変更通知を旅客アプリケーション部１２１に送る（Ｓ６８）。典型的には、決定された解に従う少なくとも一部の区間を、部分交通ネットワークを通る仮経路（例えば、特に、部分交通ネットワークのうちの最も多くの問題リンクを通る仮経路）を含んでいることはない。Ｓ６８では、当該仮経路に対応する旅客について、決定された解に従う区画を含んだ経路である新経路を表す経路変更通知が出力される。経路変更通知の出力は、旅客受け入れ履歴ＤＢ１３１に、経路変更通知が表す新経路に関する情報を含んだレコードを追加することを含んでよい。需給最適化部１２６は、臨時交通を手配済みとして交通ネットワークＤＢ１３２に登録する（Ｓ６９）。
【0101】
Ｓ６４の判定結果が真の場合（Ｓ６４：Ｙｅｓ）、需給最適化部１２６は、選択された解候補を、決定された解とし、当該解について、経路変更通知を旅客アプリケーション部１２１に送る（Ｓ７０）。
【0102】
図１６は、クラスタ内旅客カウント処理（Ｓ６２）の流れを示す。
【0103】
旅客カウント部１２５は、移動需要ＤＢ１２８及び需要クラスタリングテーブル１９０を参照し、移動需要（旅客）毎に、移動需要が属するクラスタの近傍のクラスタを列挙する（Ｓ７１）。「移動需要が属するクラスタの近傍のクラスタ」とは、例えば、移動需要が属するクラスタの代表値と一定範囲内にある代表値を持つクラスタである。旅客カウント部１２５は、移動需要（旅客）毎に、旅客受け入れモデルの入力となる特徴量を算出する（Ｓ７２）。ここでの「特徴量」は、移動需要ＤＢ１２８及び及び需要クラスタリングテーブル１９０を基に特定された特徴量であって、旅客とクラスタと区間（Ｓ６１で見つかった区間）との組である第１種の組毎の特徴量である。「旅客受け入れモデル」とは、第１種の組毎の特徴量を入力とし第１種の組毎の所属確率（図２１参照）を出力とするモデルである。モデルは、典型的には、機械学習モデル（例えばニューラルネットワーク）である。
【0104】
次に、旅客カウント部１２５は、Ｓ７２で算出された第１種の組毎の特徴量を旅客受け入れモデルに入力することで、第１種の組毎に所属確率（図２１参照）を算出し、第１種の組毎の所属確率を基に、クラスタと区間との組である第２種の組毎に期待値（確率）（図１８Ａ参照）を算出する（Ｓ７３）。旅客カウント部１２５は、クラスタ毎に、期待値（確率）が最も高い区間を特定し、当該クラスタのクラスタ所属数１９２（図１４参照）と期待値（確率）とを基に、旅客数（予測）を算出する（Ｓ７４）。
【0105】
図１７は、旅客受け入れ履歴ＤＢ１３１の構成例を示す。
【0106】
旅客受け入れ履歴ＤＢ１３１は、旅客及び新経路の組毎にレコードを有する。各レコードは、レコード番号１３１ａと、クラスタ代表値との距離１３１ｂと、乗り換え回数１３１ｃと、部分交通ネットワーク外までの距離１３１ｄと、混雑率１３１ｅと、着席保障１３１ｆと、受け入れ可否１３１ｇといった情報を有する。一の旅客及び一の新経路新経路を例に取る（図１７の説明において「対象旅客」及び「対象新経路」）。
【0107】
レコード番号１３１ａは、対象旅客と対象新経路との組のレコードの識別番号を表す。クラスタ代表値との距離１３１ｂは、対象旅客のレコードを基に算出された特徴量と対象旅客が属するクラスタの代表値との距離を表す。乗り換え回数１３１ｃは、対象新経路における乗り換え回数を表す。部分交通ネットワーク外までの距離１３１ｄは、対象旅客の出発地又は目的地と部分交通ネットワークとの距離を表す。混雑率１３１ｅは、対象新経路における混雑率を表す。着席保障１３１ｆは、対象新経路における着席保障を表す。受け入れ可否１３１ｇは、対象新経路を対象旅客が受け入れ可としたか否かを表す（“１”が受入れ可を意味する）。
【0108】
旅客カウント部１２５は、旅客受け入れ履歴ＤＢ１３１に格納されたデータを基に、上述の旅客受け入れモデルを構築又は更新といった学習を行ってよい。例えば、旅客受け入れ履歴ＤＢ１３１の各レコードが、旅客、クラスタ及び区間を表す情報を含み、旅客受け入れモデルは、旅客と、クラスタと、区間と、要求サービスレベルと、受け入れ可否との組毎に、特徴量を算出し、それらの特徴量を入力とし、旅客とクラスタと区間との組である第１種の組毎の所属確率を出力としてよい。旅客カウント部１２５は、学習済の旅客受け入れモデルに対して、第１種の組毎の特徴量を入力することで、第１種の組毎の所属確率を求めることができる。
【0109】
【0110】
期待値管理テーブル２１０は、第２種の組（クラスタと区間との組）毎にレコードを有する。各レコードは、クラスタ番号２１１と、区間２１２と、期待値（確率）２１３といった情報を有する。
【0111】
クラスタ番号２１１は、クラスタの識別番号を表す。区間２１２は、区間を構成する一つの以上のリンクの並びを表す。期待値（確率）２１３は、当該クラスタについて区間を通る旅客の割合を表す。
【0112】
本実施形態では、期待値（確率）２１３が採用される。この場合、図１９に例示の区間管理テーブル２２０が構築され得る。区間管理テーブル２２０は、区間毎にレコードを有し、各レコードが、区間２２１と、割り当てクラスタ２２２と、コスト２２３と、運賃２２４と、定員２２５と、旅客数（予測）２２６といった情報を有する。旅客数（実測）２２７と、収益２２８と、混雑率２２９といった情報は、本実施形態の期待される効果の一例の説明に用意された情報であり、区間管理テーブル２２０に含まれている必要は無い。
【0113】
区間２２１は、区間を構成するリンクの並びを表す。割り当てクラスタ２２２は、区間に割り当てられたクラスタの識別番号を表す。コスト２２３は、区間に沿った運行にかかるコストを表す。運賃２２４は、区間の運賃を表す。定員２２５は、区間に対応した輸送サービスの定員を表す。旅客数（予測）２２６は、区間を通る旅客数の予測値を表す。旅客数（実測）２２７は、区間を通る旅客数の期待される実測値を表す。収益２２８は、区間についての期待される収益を表し、典型的には、旅客数（実測）２２７と運賃２２４との積からコスト２２３を減じた値である。混雑率２２９は、区間での期待される混雑率を表し、典型的には、旅客数（実測）２２７を定員２２５で除算することにより得られた値である。なお、コスト２２３と、運賃２２４と、定員２２５といった情報は、期待値管理テーブル２１０に代えて、区間毎に交通ネットワークＤＢ１３２に含まれていてもよい。また、定員２２５としての値は、実際の定員としての値でもよいし、移動需要ＤＢ１２８に登録された旅客の数に応じて実際の定員が調整された後の値でもよい。
【0114】
図１８Ａ及び図１９が示す例によれば、第１種の組（旅客とクラスタと区間との組）毎に所属確率２５４が算出される。つまり、旅客がいずれのクラスタにも属し得るとして旅客がいずれのクラスタに属した場合にいずれの区間をどのぐらいの確率的で通るかが算出される。第２種の組毎に期待値（確率）２１３が採用され、区間毎に期待値（確率）２１３に応じたクラスタが割り当てられる。区間毎に、旅客数（２２６）は、当該期待値（確率）２１３と、当該区間に割り当てられたクラスタに所属する旅客の数とから算出される。結果として、最適解とされた組合せが輸送サービスの運用効率や旅客の要求サービスレベルを満たさなくなる（現実と乖離した最適解が求められてしまう）可能性が低減される。具体的には、例えば、運用効率の一要素である収益２２８が負の値（不採算を意味する値）になったり、サービスレベルの一要素である混雑率２２９が“１００％”を超える値になったりする可能性が低減される。
【0115】
一比較例によれば、クラスタと旅客との関係は固定的である。この場合、本実施形態に比べて、最適解とされた組合せが輸送サービスの運用効率やサービスレベルを満たさなくなる可能性が高い。例えば、一比較例では、図２０が示す通り、運用効率の一要素である収益が“－５００”のように悪化したり、サービスレベルの一要素である混雑率が“１２０％”ように悪化したりし得る。
【0116】
図１８Ａの期待値（確率）２１３の計算方法は、例えば次の通りである。
【0117】
図２１に例示の所属確率管理テーブル２５０が構築される。所属確率管理テーブル２５０は、第１種の組（旅客とクラスタと区間の組）毎にレコードを有し、各レコードが、旅客番号２５１と、クラスタ番号２５２と、区間２５３と、所属確率２５４とから構成される。
【0118】
旅客番号２５１は、旅客の識別番号を表す。クラスタ番号２５２は、クラスタの識別番号を表す。区間２５３は、区間を構成するリンクの並びを表す。所属確率２５４は、旅客がクラスタに所属する場合に区間を受け入れる（通る）確率を表す。この確率は、旅客受け入れモデル（旅客受け入れ履歴ＤＢ１３１の学習により構築されたモデル）を基に得られた値である。
【0119】
この所属確率管理テーブル２５０を基に、図１８Ａに例示した期待値管理テーブル２１０が構築される。第２種の組（クラスタと区間との組）毎に、期待値（確率）２１３は、当該第２種の組に対応した全旅客の所属確率２５４の和である。例えば、クラスタＣ１の区間Ｔ１の期待値（確率）２１３は、図２１が示す例によれば、０．８１＋０．７５＋０．９３＋・・・であり、結果として、図１８Ａが示すように、期待値（確率）２１３は、“６０”となる。
【0120】
図２２は、需給マッチングの一例を模式的に示す。
【0121】
二次元直交座標系のグラフがある。縦軸（第１の軸の例）が、サービスレベル評価関数ｗ０ｆ（Ｒ，Ｓ）であり、横軸（第１の軸と直交する第２の軸の例）が、運用効率評価関数ｗ１ｇ（Ｒ，Ｓ）である。「Ｒ」は、各クラスタの区間（利用する交通手段の組み合わせを含み得る区間）である。「Ｓ」は、各クラスタの要求サービスレベルである。
【0122】
サービスレベル及び運用効率に最適な需給マッチング解を需給最適化部１２６が多目的最適化問題を解いて探索した場合、探索結果として最適解としてＲ＊
１が得られる。解Ｒ＊
１で需給マッチングが成立しない場合、次の候補として、２番目に最適な解Ｒ＊
２が選出される。この際、パレート最適な解の候補が複数存在する場合、サービスレベルが優先されてもよい。
【0123】
需給最適化部１２６が行う処理の具体例は、次の通りである。
【0124】
需要クラスタ生成処理において、Ｃ個のクラスタが生成されたとする。各クラスタｃのサービルレベルと移動需要を、数１とする。
【数1】
【0125】
この場合、全てのクラスタの需要Ｓを、数２のように表現できる。
【数2】
【0126】
区間検索にかけるクラスタｃの区間候補の一覧をｒｃとする。クラスタ毎に、Ｍｃ個の区間が得られるとする。各ｒｃ，ｊには、クラスタ毎の区間が含まれる。ｒｃを、数３のように表現できる。
【数3】
【0127】
需給最適化部１２６は、各クラスタが取るべき区間の組み合わせとして、各クラスタが選択するパスＲを生成する。Ｒを、数４のように表現することができる。
【数4】
【0128】
需給最適化部１２６は、パスＲ内の各クラスタの区間を変えることで、数５に従って最小化問題を解く。
【数5】
【0129】
ｆｉは、サービスレベルを満たしていない場合に増加するコスト関数である。例えば、人流に関するシミュレーションの結果からサービスレベルの基準を超えた混雑率の区間数を設定することに加えて、事業者の運行コストも設定する。なお、ｗｉｆｉで構成される最小化問題は線形である。ｗｉｆｉを状況に応じて追加、削除してもよいし、ｗｉｆｉを各々改良してもよい（シミュレーションの精度向上、重みの更新など）。また、Ｒ＊は、上位３つ程度の候補を出しておいてもよい。この際、Ｒ＊に新たな手配が必要な交通（臨時便やデマンド交通）を抽出し、抽出し交通の対象事業者に手配を通知することができる。また、対象事業者全ての承認が得られない場合は、次のＲ＊の候補の処理に移動することができる。
【0130】
運行手配部１２７は、各交通運行管理サーバ２０と情報の送受信を行い、各交通事業者が提供する輸送サービスに用いる各交通手段の運行を手配する処理を実行する。
【0131】
以上の実施形態の具体例として、下記が考えられる。
【0132】
第１の例として、通学需要とイベント需要とが重なる例が考えられる。この場合、遅刻できない学生のクラスタと、イベントに早く行きたい参加者（学生）のクラスタと、イベント会場まで座っていきたい参加者（学生）のクラスタが生成される。移動需要のサービスレベルに応じて、学校に向けにデマンドバスを追加手配したり、学校向けにスクールバスのイベント会場への延長運行を手配したり、イベント会場へのタクシーを手配したりすることができる。また、タクシー、一部のデマンドバス等ノードが一定でない場合、経路に属する近隣のバス停等、既存のノードを活用したり、一定距離ごとに仮想的な停留所をノードに設定したりすることができる。交通手段としてシェアサイクルを対象とする場合、自転車置き場をノードに設定することができる。
【0133】
第２の例として、都市の鉄道などで輸送障害が発生した例が考えられる。この場合、着席を優先する買い物客のクラスタと、時間に或る程度余裕がある観光客のクラスタと、時間厳守のビジネス客のクラスタとが生成される。移動需要のサービスレベルに応じて、臨時バスの運行を手配したり、新交通システムの増便を手配したりすることができる。
【0134】
以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
【0135】
例えば、上述の説明を、以下のように総括することができる。以下の総括は、上述の説明の補足説明及び変形例の説明を含んでもよい。
【0136】
旅客アプリケーション部１２１が、対象旅客（いずれかの旅客）の対象旅客端末３０（対象旅客の旅客端末）から移動需要を受け付け、当該移動需要を表す情報を移動需要ＤＢ１２８（移動需要情報の一例）に含める。部分ネットワーク抽出部１２２が、移動需要ＤＢ１２８及び交通ネットワークＤＢ１３２（交通ネットワーク情報の一例）を基に、それぞれが運用効率と要求サービスレベルの少なくとも一つが満たされないリンクである一つ以上の問題リンクを特定し、当該一つ以上の問題リンクを含む部分交通ネットワークを抽出する。需要クラスタリング部１２４が、仮経路ＤＢ１２９（旅客毎の仮経路を表す情報である仮経路情報の一例）及び移動需要ＤＢ１２８を基に、部分交通ネットワークを通る仮経路に対応した旅客の移動需要のクラスタを生成する。需給最適化部１２６が、生成された各クラスタと交通ネットワークＤＢ１３２とを基に、移動需要を満たし運用効率を維持する解を決定する需給最適化を行う。決定された解は、部分交通ネットワークにおける区間毎のクラスタ割当てである。決定された解が、対象旅客について仮経路に含まれない区間を含む場合、旅客アプリケーション部１２１が、対象旅客の仮経路と、当該仮経路に含まれない区間を含んだ新経路とのいずれかを確定経路とし、対象旅客端末３０からの移動需要に対する応答として、対象旅客の確定経路に関する情報を対象旅客端末３０に送信する。
【0137】
これにより、旅客の多種多様な移動需要を満たすことと輸送サービスの運用効率を維持することとを両立した需給マッチングを実現することができる。また、移動需要を個々に満たそうとすると情報処理としてタクシーや自転車など小さなモビリティ（交通手段）が割り当てられがちになるおそれがあるが、移動需要のクラスタを基に解を出すため、旅客数が比較的多い（効率の良い）バスや鉄道などの大規模な交通手段の割り当てが可能となる。これは、輸送サービス（交通手段）の割り当て特有の技術的効果の一つである。
【0138】
抽出された部分交通ネットワークは、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であるネットワークである。このため、部分交通ネットワークにおける区間（例えば問題リンクを含む区間）について単位時間当たりの運行数に変更があっても、折り返し可能な端点のノードでの車両の折り返しが可能である。結果として、部分交通ネットワークの外に問題リンクの影響を及ぼすことを無くす又は小さくすることができる。これは、輸送サービス（交通手段）の割り当て特有の技術的効果の一つである。
【0139】
部分ネットワーク抽出部１２２が、問題リンクに隣接するリンクを問題リンクにつなぐことを、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であることが満たされる範囲で行うことで、一つ以上の部分交通ネットワークを生成してよい。部分ネットワーク抽出部１２２が、互いに少なくとも一部が重複する二つ以上の部分交通ネットワークが生成された場合、当該二つ以上の部分交通ネットワークを一つの部分交通ネットワークとしてよい。これにより、互いに少なくとも一部が重複するにも関わらず二つ以上の部分交通ネットワークのそれぞれの最適化問題の解の整合性が取れないといったことが生じ得ることを避けることができる。
【0140】
抽出された部分交通ネットワークは、問題リンクを最も多く通る仮経路である該当仮経路の代替パス数が下限値以上であるネットワークでよい。代替パスは、該当仮経路における問題リンク毎に、当該問題リンクを迂回しそれぞれ問題リンクではない一つ以上のリンクでよい。部分ネットワーク抽出部１２２は、生成された部分交通ネットワークにおける問題リンクを最も多く通る仮経路の代替パス数が前記下限値未満の場合、端点のノードを折り返し可能とする輸送サービスの数又は割合が所定値以下であることが満たされる範囲で当該部分交通ネットワークを拡大してよい。これにより、問題最適化のための代替パスが設定できないことを防ぐことができる。
【0141】
抽出された部分交通ネットワークは、問題リンクを最も多く通る仮経路である該当仮経路の代替パス数が上限値以下であるネットワークでよい。部分ネットワーク抽出部１２２は、生成された部分交通ネットワークにおける問題リンクを最も多く通る仮経路の代替パス数が上限値を超えている場合、下記が満たされているか否かを判定し、当該判定の結果が真の場合に、生成された部分交通ネットワークを、該当中間ノードを境に分割してよい。これにより、部分交通ネットワークの大きさを制限し、以って、需給最適化において組合せ爆発を防ぐことができる。
・当該部分交通ネットワークに、端点のノード以外のノードであって、折り返し可能とする輸送サービスの数又は割合が所定値以下であるノードである該当中間ノードがある。
・当該該当中間のノードを境に当該部分交通ネットワークを複数の部分交通ネットワークに分割したとしても当該複数の部分交通ネットワークがそれぞれ該当仮経路の代替パス数が下限値以上であることを満たす。
・当該部分交通ネットワークに、端点のノード以外のノードであって、折り返し可能とする輸送サービスの数又は割合が所定値以下であるノードである該当中間ノードがある。
・当該該当中間のノードを境に当該部分交通ネットワークを複数の部分交通ネットワークに分割したとしても当該複数の部分交通ネットワークがそれぞれ該当仮経路の代替パス数が下限値以上であることを満たす。
【0142】
需給最適化処理において、旅客カウント部１２５は、第１種の組（旅客と、クラスタと、部分交通ネットワークにおける区間との組）毎に、旅客がクラスタに所属する場合に区間を通る確率である所属確率を算出してよい。クラスタと、前記抽出された部分交通ネットワークにおける区間との組である第２種の組毎に、当該第２種の組について得られた全旅客の所属確率を基に、当該クラスタのうち当該区間を通る旅客の割合である期待値を算出してよい。需要最適化部１２６は、第２種の組毎の期待値を基に、解を決定してよい。すなわち、旅客が生成されたクラスタに必ず所属するとは限らず別のクラスタに所属する可能性を基に、第１種の組毎の所属確率が算出され、第１種の組毎の所属確率を基に、第２種の組毎の期待値が算出される。これにより、最適化問題の解が適切である可能性の向上が期待される。
【0143】
旅客アプリケーション部１２１が、新経路（対象旅客が属するクラスタに割り当てられ対象旅客の仮経路に含まれていない上記決定された解に従う区間を含んだ経路）を対象旅客端末３０に通知し、当該新経路に関する情報を旅客受け入れ履歴ＤＢ１３１（旅客受け入れ履歴情報の一例）に含めてよい。旅客アプリケーション部１２１が、新経路の受け入れ可否の回答を対象旅客端末３０から受け、当該回答を、上記通知された新経路について旅客受け入れ履歴ＤＢ１３１に含めてよい。第１種の組毎の所属確率の算出は、旅客受け入れ履歴ＤＢ１３１を基に学習された機械学習モデルを用いて行われてよい。旅客受け入れ履歴ＤＢ１３１は、新経路に関する情報や新経路が受け入れられたか否かを表す情報を含む。すなわち、旅客が属するクラスタが割り当てられた区間を含んだ新経路が旅客に提示されてもその経路が旅客に拒否された場合には拒否がされたことを表す情報が旅客受け入れ履歴ＤＢ１３１に含まれる。言い換えれば、新経路を受け入れるか否かは旅客の裁量に委ねられており、その旅客の裁量の結果が旅客受け入れ履歴ＤＢ１３１に反映される。このような旅客受け入れ履歴ＤＢ１３１を基に学習された機械学習モデルを基に、第１種の組毎の所属確率が算出される。これにより、最適化問題の解が適切である可能性の向上が期待される。
【0144】
需要最適化部１２６は、第２種の組毎に予測された旅客数と、交通ネットワーク情報とを基に、一つ以上の解を算出し、当該一つ以上の解のうち未選択の一つの解を選択し、交通ネットワーク情報を基に、選択された解が、輸送サービスの追加の手配を必要とする解か否かを判定してよい。この判定の結果が偽の場合、需要最適化部１２６は、選択された解を、決定された解としてよい。一方、この判定の結果が真の場合、運行手配部１２７は、追加の手配が必要な輸送サービス毎に当該輸送サービスに対応した一つ以上の交通運行管理サーバに追加の手配を依頼し、依頼がされた全ての交通運行管理サーバから承認の回答を受けた場合、需要最適化部１２６は、選択された解を、決定された解としてよい。これにより、新経路の適切な通知（適切な経路変更通知）を出すことができる。
【符号の説明】
【0145】
１０：需給マッチングサーバ
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18A】
【図18B】
【図19】
【図20】
【図21】
【図22】