知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023006347
(43)【公開日】2023-01-18
(54)【発明の名称】計算機システム
(51)【国際特許分類】
G06Q 50/30 20120101AFI20230111BHJP
G06Q 10/04 20230101ALI20230111BHJP
【ＦＩ】
G06Q50/30
G06Q10/04
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2021108900
(22)【出願日】2021-06-30
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】小林 雄一
(72)【発明者】
【氏名】高橋 由泰
(72)【発明者】
【氏名】但馬 慶行
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049AA04
5L049CC42
(57)【要約】
【解決課題】複数主体夫々の計画に基づいて最適化された計画を実現する際、複数主体互いの効用関数が不確かな状況であっても、複数主体の合意が得られる計画候補を複数主体に提示することによって、複数主体が最適化計画に合意し易くし、以って複数主体の業務の連携が円滑に進めるようにする計算機システムを提供する。
【課題解決手段】サーバは、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々の端末装置に提供する。サーバのコントローラは、複数の端末夫々から送信された計画を評価し、評価の結果に基づいて、複数ユーザ夫々の効用関数を推定し、効用関数に基づいて複数のユーザに推奨する計画を設定し、推奨する計画を複数のユーザ夫々の端末装置に送信し、複数のユーザが推奨する計画に合意するまで、評価と推奨する計画の設定を繰り替えし、複数のユーザが合意した推奨する計画を最適化された計画として決定する。
【選択図】図１０
【課題解決手段】サーバは、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々の端末装置に提供する。サーバのコントローラは、複数の端末夫々から送信された計画を評価し、評価の結果に基づいて、複数ユーザ夫々の効用関数を推定し、効用関数に基づいて複数のユーザに推奨する計画を設定し、推奨する計画を複数のユーザ夫々の端末装置に送信し、複数のユーザが推奨する計画に合意するまで、評価と推奨する計画の設定を繰り替えし、複数のユーザが合意した推奨する計画を最適化された計画として決定する。
【選択図】図１０
【特許請求の範囲】
【請求項1】
複数のユーザ夫々の端末装置とサーバとがネットワークによって接続し、
前記サーバは、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々の前記端末装置に提供する、
計算機システムであって、
前記サーバはメモリに記載されたプログラムを実行するコントローラを備え、
当該コントローラは、
前記複数の端末夫々から送信された計画を評価し、
当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、
当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、
前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、
当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、
計算機システム。
前記サーバは、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々の前記端末装置に提供する、
計算機システムであって、
前記サーバはメモリに記載されたプログラムを実行するコントローラを備え、
当該コントローラは、
前記複数の端末夫々から送信された計画を評価し、
当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、
当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、
前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、
当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、
計算機システム。
【請求項2】
前記複数のユーザ夫々の前記効用関数について許容範囲が存在し、
当該複数のユーザ夫々は、当該許容範囲に属する前記推奨する計画に合意でき、
当該許容範囲は前記推奨する計画が繰り返される過程で拡張され、
前記コントローラは、
前記評価結果に基づいて前記許容範囲を推定し、
当該推定された許容範囲に基づいて前記複数のユーザが合意し得る計画を設定して、当該計画を前記推奨する計画として前記端末装置に送信する、
請求項１記載の計算機システム。
当該複数のユーザ夫々は、当該許容範囲に属する前記推奨する計画に合意でき、
当該許容範囲は前記推奨する計画が繰り返される過程で拡張され、
前記コントローラは、
前記評価結果に基づいて前記許容範囲を推定し、
当該推定された許容範囲に基づいて前記複数のユーザが合意し得る計画を設定して、当該計画を前記推奨する計画として前記端末装置に送信する、
請求項１記載の計算機システム。
【請求項3】
前記コントローラは、
前記評価と前記推奨する計画の設定を繰り替えす過程で、前記評価の結果が変化する速度を計算し、
当該速度に基づいて前記許容範囲の拡がりを推定する、
請求項２記載の計算機システム。
前記評価と前記推奨する計画の設定を繰り替えす過程で、前記評価の結果が変化する速度を計算し、
当該速度に基づいて前記許容範囲の拡がりを推定する、
請求項２記載の計算機システム。
【請求項4】
前記コントローラは、
前記効用関数に基づいて前記複数のユーザに推奨する計画を設定する際、前記評価の結果に基づいて、当該推奨する計画に前記複数のユーザが合意する確率を計算し、当該推奨する計画を当該合意する確率と共に前記複数のユーザ夫々の端末装置に通知する、
請求項１記載の計算機システム。
前記効用関数に基づいて前記複数のユーザに推奨する計画を設定する際、前記評価の結果に基づいて、当該推奨する計画に前記複数のユーザが合意する確率を計算し、当該推奨する計画を当該合意する確率と共に前記複数のユーザ夫々の端末装置に通知する、
請求項１記載の計算機システム。
【請求項5】
前記コントローラは、
前記効用関数に基づいて、前記最適化する計画の候補となる複数の計画を発生させ、
当該複数の計画夫々の評価結果に基づいて前記合意する確率を計算し、
当該合意する確率が最も高い計画を前記推奨する計画として設定する、
請求項４記載の計算機システム。
前記効用関数に基づいて、前記最適化する計画の候補となる複数の計画を発生させ、
当該複数の計画夫々の評価結果に基づいて前記合意する確率を計算し、
当該合意する確率が最も高い計画を前記推奨する計画として設定する、
請求項４記載の計算機システム。
【請求項6】
前記複数のユーザ夫々の効用関数がお互いにトレードオフの関係にある、
請求項１記載のシステム。
請求項１記載のシステム。
【請求項7】
前記コントローラは、
前記複数のユーザのうち、前記推奨する計画に同意しないユーザの端末装置から、当該推奨する計画を変更する計画を受信し、
当該変更する計画の前記評価の結果に基づいて、前記推奨する計画に同意しないユーザの効用関数を推定する、
請求項１記載のシステム。
前記複数のユーザのうち、前記推奨する計画に同意しないユーザの端末装置から、当該推奨する計画を変更する計画を受信し、
当該変更する計画の前記評価の結果に基づいて、前記推奨する計画に同意しないユーザの効用関数を推定する、
請求項１記載のシステム。
【請求項8】
前記コントローラは、
前記評価の結果を効用関数から得られる効用値として、当該効用値の変化率を計算する、
請求項３記載の計算機システム。
前記評価の結果を効用関数から得られる効用値として、当該効用値の変化率を計算する、
請求項３記載の計算機システム。
【請求項9】
複数のユーザ夫々の端末装置とネットワークによって接続するサーバが、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々に提供する、最適化された計画の作成を支援する方法であって、
メモリに記載されたプログラムを実行する、前記サーバのコントローラは、
前記複数の端末夫々から送信された計画を評価し、
当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、
当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、
前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、
当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、
前記方法。
メモリに記載されたプログラムを実行する、前記サーバのコントローラは、
前記複数の端末夫々から送信された計画を評価し、
当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、
当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、
前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、
当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、
前記方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、計算機システムと計算方法に係り、詳しくは、複数主体に於ける計画の最適化を達成するための計算機システムとその方法に関するものである。
【背景技術】
【0002】
異なる業種や部門間で連携して計画を立案することが頻繁に行われている。それに伴い、営業部門と生産部門との間で商品の需給計画を合意させなければならない、そして、複数交通機関夫々の運行計画を調整しなければならない等、複数の主体がお互いに計画を合意させなければならないこと等が多々ある。部門間や企業間では、企業全体、又は、社会や地域全体の利益を向上させようとする目的をお互いに共有しつつも、複数の主体夫々は自身の利益を向上したいという意向があるため、複数の主体夫々の計画をお互いに合意させることはそもそも容易ではない。
【0003】
そこで、夫々異なる効用関数を持つ複数主体が互いに協調して、計画の最適化を図らねばならない、という課題を解く手法が提案されている（非特許文献１）。この手法は、複数主体夫々の利益を公平に満たしながら全体目的も同時に達成するという共生型のリソースオペレーションの実現を目指している。この手法は、夫々の主体が協調場に対して自己の希望するリソース要求を行うことが可能であること、そして、リソース要求に対して、協調場は、複数主体の全体最適化という観点から、主体と複数回の交渉、即ち、調停を行うことができる、という特徴を有する。
【0004】
調停によって不利益な取り扱いをされた主体には、優先ポイントが付与され、次回以後の調停においてその優先権を行使できることとして、その主体は不利益分を取り戻すことができ、その結果、長期的観点で公平性が担保される。この種の従来例として、WO2017/130367号公報（特許文献１）が存在する。なお、特開2009-30476号公報（特許文献２）にも関連技術が開示されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】WO2017/130367号公報
【特許文献2】特開2009-30476号公報
【非特許文献】
【0006】
【非特許文献1】T. Ebata, T.Sato et al. “Symbiotic Autonomous Decentralized System on CooperativeDistributed Scheduling”, IEEE 6th International Conference on Advanced AppliedInformatics, 2017
【発明の概要】
【発明が解決しようとする課題】
【0007】
複数主体夫々の計画を合意させることがそもそも難しいのは、複数主体夫々の効用関数が異なり、多くの場合、お互いの効用関数がトレードオフ関係にあること、そして、お互いに相手の効用関数を知ることが容易ではないからである。ところで、複数の当事者がお互いの計画を合意させるために、時期を見計らって相手の要求に従うという戦略も存在する。
【0008】
しかしながら、多主体における計画立案業務に於ける各主体の要求は、例えば、製造する順番と出荷する順番であったり、列車が到着する時刻とバスが出発する時刻とであったりというように、主体の種類が一様でないことに基づいて、多種多様である。
【0009】
そのために相手に合わせる要求がどうであるべきかということを、夫々の主体が理解することは容易でない。したがって、多主体夫々の要求を合意させて、最適な計画を早期に設定できるシステムは、現在までのところ実現されていないのが実情である。そこで、本発明は、複数主体夫々の計画に基づいて最適化された計画を実現する際、複数主体互いの効用関数が不確かな状況であっても、複数主体の合意が得られる計画候補を複数主体に提示することによって、複数主体が最適化計画に合意し易くし、以って複数主体の業務の連携が円滑に進めるようにする計算機システムとその方法の提供を目的とする。
【課題を解決するための手段】
【0010】
前記目的を達成するために、本発明は、複数のユーザ夫々の端末装置とサーバとがネットワークによって接続し、前記サーバは、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々の前記端末装置に提供する、計算機システムであって、前記サーバはメモリに記載されたプログラムを実行するコントローラを備え、当該コントローラは、前記複数の端末夫々から送信された計画を評価し、当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、計算機システムである。
【0011】
さらに、本発明は、複数のユーザ夫々の端末装置とネットワークによって接続するサーバが、複数の端末装置夫々から送信された計画を最適化し、最適化された計画を前記複数のユーザ夫々に提供する、最適化された計画の作成を支援する方法であって、メモリに記載されたプログラムを実行する、前記サーバのコントローラは、前記複数の端末夫々から送信された計画を評価し、当該評価の結果に基づいて、前記複数ユーザ夫々の効用関数を推定し、当該効用関数に基づいて前記複数のユーザに推奨する計画を設定し、当該推奨する計画を前記複数のユーザ夫々の端末装置に送信し、前記複数のユーザが当該推奨する計画に合意するまで、前記評価と前記推奨する計画の設定を繰り替えし、当該複数のユーザが合意した前記推奨する計画を前記最適化された計画として決定する、前記方法である。
【発明の効果】
【0012】
本発明によれば、複数主体夫々の計画に基づいて最適化された計画を実現する際、複数主体互いの効用関数が不確かな状況であっても、複数主体の合意が得られる計画候補を複数主体に提示することによって、複数主体が最適化計画に合意し易くし、以って複数主体の業務の連携が円滑に進めるようにできる。
【図面の簡単な説明】
【0013】
【図1A】計算機システムが、複数ユーザの計画を最適化させる際での動作を端的に説明する特性図である。
【図1B】計算機システムが推奨計画の再計算を所定回数経た後での特性図である。
【図2】計算機システムのブロック図の一例である。
【図3】バス会社のバス路線と鉄道会社の鉄道路線が駅において接続されている系統図である。
【図5】バスと鉄道の運行計画の一例に係る管理テーブルである。
【図6】サーバからユーザ端末装置に提供される推奨計画（運行計画）の一例である。
【図7】ユーザ端末からの応答を管理する管理テーブルの一例である。
【図8】推奨計画を管理するテーブルの一例である。
【図9】ユーザ端末からの応答を管理する管理テーブルの一例である。
【図11】サーバがユーザＡの計画データを評価した結果を記録したテーブルである。
【図12】サーバが作成した想定計画の分布を示す特性図である。
【図13】ユーザの応答に対する、サーバによる評価結果を記録したテーブルである。
【図14】サーバが作成した想定計画の分布を示す特性図である。
【発明を実施するための形態】
【0014】
次に、本発明の実施の形態を説明する。計算機システムは、複数ユーザ間での計画の合意を支援することにより、最適化された計画を早期に確立することが可能なサービスを複数のユーザに提供する。計算機システムは、複数のユーザ夫々から要求された計画に基づいて、複数の主体が合意し得る計画を計算してこれを複数のユーザに推奨計画として提供する。複数のユーザは推奨計画への受諾又は拒否を判断し、拒否の場合には、修正した計画を計算機システムに送信する。計算機システムは全てのユーザが受諾するまで推奨計画の再計算を繰り返す。計算機システムは、全てのユーザが同意した推奨計画を最適計画として決定する。
【0015】
図１Ａは、計算機システムが、複数ユーザの計画を最適化させる際での動作を端的に説明する特性図である。横軸がユーザＡの効用関数を示し、縦軸がユーザＢの効用関数を示している。両軸共に大きいほど効用値が高く、ユーザが好む計画であることを示している。両ユーザの効用関数はトレードオフの関係、即ち、ユーザＡとＢの一方の効用値が高い計画は、他方にとって効用値が低い計画になるという関係にある。
【0016】
図１Ａにおいて符号１００で示される領域はユーザＡ，Ｂが同意する計画が存在する解空間であり、符号１０２は解空間の境界線である。１０２Ａ，１０２Ｂ，１０２Ｃ，１０２Ｄという四つのパレート最適な計画が解空間１００に存在することを想定すると、これらは、解空間の境界１０２に位置している。
【0017】
図１Ａにおいて、１０４ＡはユーザＡの許容範囲を示し、１０４ＢはユーザＢの許容範囲を示している。ユーザＡは許容範囲１０４Ａ内にある計画に合意でき、一方、ユーザＢは許容範囲１０４Ｂ内にある候補計画に合意できる。
【0018】
１０２ＡはユーザＢにとって効用値は大きいがユーザＡには低いため、計算機システムは両者が合意する確率を５％であると推定する。一方、１０２ＤはユーザＡにとって効用値は大きいがユーザＢには小さいため、計算機システムは合意確率を５％と見積もる。そして、１０２Ｂ，１０２Ｃは、ユーザＡ，Ｂにとって中間の値であるため、計算機システムは合意確率が１０％と計算する。
【0019】
夫々のユーザともに、計算機システムが計算した計画に同意できる許容範囲を有しているが、当初の段階では許容範囲は狭いため、両ユーザの共用範囲が交差する領域に存在する計画は存在していない。即ち、ユーザＡ，Ｂが合意できる確率が高い計画は存在しない。
【0020】
図１Ｂは、計算機システムが推奨計画の再計算を所定回数経た後での特性図を示す。ユーザＡ，Ｂによる計算機システムへの同意／不同意の通知、それを受けて計算機システムによる推奨計画の再計算というラウンドを経過することによって、ユーザＡ，Ｂが計算機システムとの対話が進む結果、ユーザＡ，Ｂは推奨計画の合意に向けて妥協が促される。その結果、許容範囲１０４Ａ，１０４Ｂは共に拡大し、ユーザＡの許容範囲とユーザＢの許容範囲の両方に跨る計画（１０２Ｂ）が出現し、計算機システムはその合意確率を８０％と推定する。
【0021】
計算機システムは、ユーザＡ，Ｂからの同意又は拒否の応答に基づいて共用範囲の拡大を推定し、それに基づいて合意確率を計算する。計算機システムは、複数の候補計画のうち候補計画１０２Ｂを推奨計画として、その合意確率（８０％）と共にユーザＡ，Ｂに提示する。その結果、ユーザＡ，Ｂは推奨計画１０２Ｂを最適計画として認め易くなる。
【0022】
図２に、計算機システムのブロック図の一例を示す。計算システムは、複数主体夫々の端末装置１０と、サーバ２００と、を備え、両者がネットワーク３００を介して接続されている。端末装置１０は、コントローラ１１０と、入力装置１７０と、出力装置１８０と、通信装置１９０を備える。コントローラ１１０は、メモリに記録されたプログラムを実行することにより、計画要求モジュール１１１と、計画判断モジュール１１２とを実現する。ユーザ端末は、パソコン、スマートフォン、ＰＤＡ等、どのような形態のもであってもよい。
【0023】
サーバ２００は、コントローラ２１０と、入力装置１７１と、出力装置１８１と、通信装置１９１と、ストレージ１２０と、を備える。コントローラ２１０は、メモリのプログラムを実行することによって、効用関数推定モジュール２１１と、許容範囲推定モジュール２１２と、パレート最適探索モジュール２１３とを実現する。ストレージ１２０は、ユーザ管理領域１２１と、計画履歴領域１２２とを備える。
【0024】
入力装置１７０，１７１、出力装置１８０，１８１、そして、通信装置１９０,１９１はいずれもコンピュータには周知慣用なものであるので以後説明では言及しない。“モジュール”とは、コントローラがプログラムを実行することによって実現する機能であり、手段、部、ユニット、又は、機能等と言い換えられてもよい。また、モジュールは、プログラムとは別に、あるいはプログラムと協働したハードウェアに実現されてもよい。モジュールの働きは、後述のフローチャートの説明の際に言及する。
【0025】
ユーザが計画を新規に作成する場合、又は、計画を修正する場合、サーバ２００に対して、利害関係先である他ユーザとの調整の要求を計画のデータと共にサーバ２００に送信する。利害関係先はサーバ２００にアクセスしたユーザによって指定されてもよいし、サーバが決定したものでもよい。サーバ２００は、計画を互いに調整すべきユーザグループを定めると、ユーザグループと計画の最適化のための対話を開始する。
【0026】
次に、計算機システムの動作を、バスを運行する交通機関（バス会社ユーザ）と鉄道を運行する交通機関（鉄道会社ユーザ）といった異種交通機関をユーザとし、これらユーザが互いの運行計画を最適化することを、例として、説明する。図３に示すように、バス会社のバス路線Ｂと鉄道会社の鉄道路線Ａとが駅Ｘにおいて接続されている。各交通機関はそれぞれが保有する車両を運用し、旅客を駅Ｘまで円滑に運び、また駅Ｘから旅客を運ぶ。
【0027】
各交通機関は、それぞれ異なる経路を担当しているため、お互いに異なる制約条件や効用関数を持っている。旅客が駅Ｘに滞留しすぎないように、各交通機関は各自の制約条件や効用関数を考慮しながら、両者はお互いの運行計画を調整しなければならない。調整の形態には、一つの最適化された計画（運行計画）を作成すること、又は、鉄道会社の計画とバス会社の計画との最適な組み合わせにすること等複数のパターンがある。以後コントローラ、一つの最適化された運行計画を作成することについて説明する。
【0028】
図４はコントローラ２１０の動作の一例に係るフローチャートである。このフローチャートを図３と関連させて説明する。コントローラ２１０は、バス会社Ｂと鉄道会社Ａとの少なとも一方の端末装置から計画の新規設定、又は、計画修正のリクエストを受け付けるとフローチャートを開始する。端末装置１０の計画要求モジュール１１１は運行計画のためのデータを作成する。コントローラ２１０は、ステップＳ００１において、鉄道会社Ａ（ユーザＡ）とバス会社Ｂ（ユーザＢ）の夫々とから、運行計画に関するデータを受信する。
【0029】
コントローラ２１０は、運行計画データを管理テーブルの形態（図５）にして、ストレージ１２０のユーザ管理領域１２１に蓄積する（ステップＳ００２）。この運行計画データは、時間帯毎の旅客の輸送量から構成されている。図５に基づくと、鉄道会社Ａ及びバス会社Ｂの運行計画は、“０６：００－”の時間帯の旅客輸送量は同じであるものの、これ以降の時間帯では旅客輸送量が異なるため、コントローラ２１０はこの相違を埋めて両者夫々に統一した運行計画を作成することを目的として、後述のとおり、両者が合意するまで運行計画の再作成、提案を繰り返す。
【0030】
コントローラ２１０は、ステップＳ００３に移行し、ユーザＡ，Ｂに提案した運行計画に、全ユーザ（ユーザＡ，Ｂ）が合意したか否かをチェックする。コントローラは、ユーザＡ，Ｂから計画データの要求があっただけで、未だ、これらユーザから同意の通知は受信していないために、ステップＳ００３を否定判定してステップＳ００４に移行する。
【0031】
ステップＳ００４では、コントローラ２１０は、ストレージのユーザ管理領域１２１を参照して、ユーザＡ，Ｂから送信された計画データを評価し、評価結果に基づいて、ユーザＡ，Ｂにとっての最適計画の候補計画を複数算出する。次いで、コントローラはステップＳ００５に移行し、複数の候補計画をランク付けして最もランクが高い候補計画を一回目（ラウンド１）の推奨計画として決定する。コントローラは、推奨計画を計画履歴領域に１２２に蓄積すると共に、ユーザＡ，Ｂの端末装置１０に送信する（ステップＳ００６）。図６に推奨計画の一例を示す。
【0032】
コントローラ２１０はステップＳ００６を終了すると、ユーザＡ，Ｂから推奨計画に対する応答を受信する（ステップＳ００１）。端末装置１０の計画判断モジュール１１２は、コントローラから送信された推奨計画に対して、受諾（Accept）、または、拒否（Reject）を判断して応答する。後者の場合、計画要求モジュール１１１は、推奨計画を変更して、推奨計画の再作成をサーバ２００に送信する。
【0033】
コントローラ２１０はステップＳ００２に進み、ユーザからの応答内容をユーザ管理領域１２１の管理テーブルに更新記録する。図７はそのユーザ管理テーブルを示したものであり、ユーザＡによって推奨計画が拒否され、推奨計画が変更、即ち、推奨計画の「１８：００－」の輸送量が「２０」から「１０」に変更されている。一方、ユーザＢによって推奨計画が受諾され、推奨計画そのものがユーザＢの管理テーブルに記録されている。
【0034】
コントローラ２１０はステップＳ００３において、ユーザ管理テーブルを参照し、ユーザＡの応答が拒否であることからステップＳ００４に移行し、ユーザ管理テーブルの応答内容、即ち、ユーザＡ，Ｂ夫々のＲｏｕｎｄ１の内容（図７）に基づいて、ユーザ推奨計画（第２ラウンド目）を決定し（ステップＳ００５）、この推奨計画をストレージの計画履歴領域１２２に更新記録する。図８は計画履歴領域１２２の推奨計画管理テーブルを示す。推奨計画（第２ラウンド目）は推奨計画（第１ラウンド目）「１８：００－」の輸送量が「２０」から「１０」に変わっている。
【0035】
コントローラ２１０は推奨計画（第２ラウンド目）をユーザＡ，Ｂに送信する（ステップＳ００６）。ユーザＡ，Ｂは共に推奨計画（第２ラウンド目）を受け入れるので、ステップＳ００１を経て、ユーザ管理テーブルは図９のように更新される（ステップＳ００２）。次いで、コントローラはユーザ管理テーブル（図９）を参照して、ステップＳ００３を肯定判定して図４のフローチャートを終了する。
【0036】
次に、図４に示すフローチャートのステップＳ００４の詳細について説明する。図１０はその詳細を示すフローチャートである。既述のとおり、コントローラ２１０は、複数のユーザが夫々作成する計画が互いにトレードオフの関係にあっても、ユーザ間の効用関数を推定し、そして、複数のユーザ装置との対話を通して、複数のユーザが計画を合意させることへの許容範囲の拡大を推定することによりユーザが合意可能な計画を複数のユーザに迅速に提供することができる。
【0037】
対話とは、ユーザＡ，Ｂがコントローラ２１０から送信された推奨計画に対して応答し、サーバがこの応答に基づいて推奨計画を変更してユーザＡ，Ｂに提供することを繰り返すことである。応答とは、ユーザＡ，Ｂが推奨計画に同意するか、又は、同意しないかを含み、後者の場合には、推奨計画に同意しないユーザは推奨計画に対する変更を明らかにして、推奨計画の再作成の要求をコントローラに送信する。対話は、推奨計画に全てのユーザが合意するまで継続される。全てのユーザが合意した計画が、全てのユーザにとっての最適化された計画になる。
【0038】
コントローラ２１０は、ユーザＡ，Ｂ夫々について、効用関数と許容範囲とを推定して推奨計画を作成する。コントローラは、ユーザから応答された計画データを評価し、評価結果に基づいて、効用関数と許容範囲とを設定する。コントローラ２１０は鉄道の運行計画とバスの運行計画とを公平に評価するため、両者に共通する評価指標を設定した。評価指標（Eval）として、例えば、一日に輸送する全旅客数（EvalA），時間帯毎の旅客数の平準化（EvalB）と、直前の計画データとの差分（EvalC）がある。
【0039】
これらの評価指標に基づいて、図５に示すユーザＡ，Ｂの計画データを、コントローラ２１０が評価すると図１１のテーブル（評価テーブル）のようになる（ステップＳ４０１）。EvalAについて、バス（Ｂ）の一日の旅客輸送量が８０なのに対して、トレイン（Ａ）のそれは４０なので、バス（Ｂ）のEvalAは１．００、トレイン（Ａ）のEvalAは０．５０である。EvalBについて、バス（Ｂ）の時間帯ごとの輸送量は同じであるのでEvalBは１．０であり、トレイン（Ａ）では時間帯ごとの輸送量は全て同じではないのでEvaBは０．３０になる。コントローラ２１０は評価テーブルをユーザ管理領域１２１に格納する。
【0040】
EvalCについて、コントローラ２１０はストレージのユーザ管理領域１２１を参照し、ユーザから送信された計画データを直近の計画データと比較する。トレイン（Ａ）については、両方が同じためEvalCは１．００である。一方、バス（Ｂ）では、トレインと異なり運行計画は柔軟に変更される傾向があり、実際に両者が異なっているため、EvalCは０．５０である。
【0041】
図１１の重み（Weight）は評価指標の重要度である。WeightAはEvalAの重みであり、WeightBはEvalBの重みでありWeightCはEvalCの重みである。サーバがユーザＡ，Ｂから最初に、夫々希望する計画を受け付けた段階では、これらの重みは、トレイン、バスの夫々について直近の運行計画について設定された値でよい。Errorはラウンド毎の評価指標の誤差であり、効用値（Util Value）は効用関数によって得られた満足度である。Errorは重み（Weight）の推定に利用される。コントローラ２１０はEvalの値をError値で割った値を比較して重みを推定する。つまり、例えば、EvalAの値がEvalBの値より大きくてもErrorAの値が非常に大きいとWeightAはWeightBより小さくなる。
【0042】
コントローラ２１０の効用関数推定モジュール２１１は、効用関数を、複数の評価指標夫々の値に、評価指標に対応する重みを掛け、全ての評価指標について合算したものとして、下記数式１のように定義した（ステップＳ４０２）。ｒを要求データ、ｎを評価指標の数、ＷＡｉをｉ番目の指標値に対する重みとすると、ユーザＡの効用関数ＵAは数式１を用いて表される。ユーザＡの効用値UtilValueは数式１によって計算される。Eval（rｉ）はユーザＡのｉ番目の指標値であり、ＷＡｉはユーザＡのｉ番目の指標値に対する重みである。
コントローラは、同じようにして、ユーザＢの効用関数を設定し、そして、その効用値UtilValueを計算することができる。効用関数の予測には、簡易的な統計手法を用いてもよいし、深層学習などの機械学習を用いてもよい。
【数1】
【0043】
次に、コントローラ２１０のパレート最適探索モジュール２１３は、ユーザＡの効用関数とユーザＢの効用関数に基づいて、解空間内にある、ユーザＡの想定計画とユーザＢの想定計画との組み合わせを疑似的に複数発生させる。想定計画とは、パレート最適探索モジュール２１３が演算によって求めた仮想的な計画であり、計画は時間帯毎の旅客輸送量からなる。パレート最適探索モジュール２１３は、想定計画を、遺伝的アルゴリズム（例えば、渡邉真也・廣安知之・三木光範，「近傍培養型遺伝的アルゴリズムによる多目的最適化」，情報処理学会論文誌「数理モデル化と応用」，Vol. 43 No. SIG 10（TOM 7），2002.）といったメタヒューリスティックな解法によって求めることができる。複数の想定計画の分布図を図１２に示す。図１２の横軸がユーザＡの効用関数であり、縦軸がユーザＢの効用関数である。一つの点が一つの想定計画である。パレート最適探索モジュール２１３は多数の想定計画の中からパレート最適なものの集合を、ユーザＡとユーザＢとが合意する可能性がある候補計画として選択する（ステップＳ４０３）。図１２において、１２００－１２０６の夫々がパレート最適なものとしての候補計画である。
【0044】
次に、コントローラ２１０は、複数のパレート最適な計画候補の夫々について、ユーザＡ，Ｂが推奨計画に合意する確率について計算する。図１Ｂに示すように、許容範囲が広がるほど合意確率が上がるので、許容範囲推定モジュール２１２は、ユーザの応答から許容範囲の拡縮を推定し、その結果に基づいて合意確率を計算する。許容範囲推定モジュール２１２は、この推定のために、ユーザ毎にラウンド毎の効用値の変化量を算出し、全てのラウンドについて変化量の平均値を算出する（ステップＳ４０４）。
【0045】
この平均値が大きいほど、効用値の変化量が大きいことになる。互いに計画の合意を目指そうとしている当事者間で、効用値の変化量が大きいということは、ユーザが、サーバが算出した計画に合わせて計画データを変更することに柔軟性があることの証左であって、即ち、ユーザの許容範囲が拡大していると見做すことができる。全てのラウンドについての変化量の平均値を妥協平均速度と言い換えてもよく、妥協平均速度が大きいほど、合意確率が大きくなるということである。妥協平均速度は、ｋをラウンド数とすると、次の数式２で表される。
ユーザＢの妥協平均速度も同様にして求められる。
【数2】
【0046】
コントローラ２１０は、各ユーザの効用関数と妥協平均速度とに基づいて、パレート最適な計画候補（図１２、１２００－１２０６）ごとに、全てのユーザが、推奨計画に合意する確率を算出する（ステップＳ４０５）。Ｕp,ｊをパレート最適な計画候補ｐに対するユーザｊの効用値とすると、計画候補ｐの合意確率Ｃｐは次の数式３を用いて表される。
任意の計画候補ｐの合意確率は、各ユーザの効用値との距離ｄｊの和で計算される。距離ｄｊの和がゼロのとき合意確率は1.0であり、距離ｄｊの和が大きければ大きいほど合意確率は小さくなり、距離ｄｊの和が無限大のとき合意確率はゼロになる。ユーザｊの効用値との距離ｄｊは、効用値Ｕｊと妥協平均速度と計画候補ｐの効用値ｕp,ｊで計算される。Ｕｊはユーザｊが最も望む効用値であり、この効用値から妥協平均速度を引いた値が妥協可能な効用値になる。任意の計画候補ｐについてユーザｊにとっての効用値ｕp,ｊが妥協可能な効用値以上であれば、ユーザｊは合意する確率が高いので距離ｄｊはゼロになる。任意の計画候補ｐについてユーザｊにとっての効用値ｕp,ｊが妥協可能な効用値より小さければ小さいほど、ユーザｊは合意する確率が低くなるので距離ｄｊは大きくなる。効用値から妥協平均速度を引いた値は常に正であるという想定である。
【数3】
【0047】
パレート最適な計画候補毎に合意確率が付けられてランク付けされると、最も高ランク、即ち、最も高い合意確率の候補計画が推奨計画として決定され、サーバ２００は推奨計画（図８のＲｏｕｎｄ１）を合意確率と共に、ユーザＡ，Ｂの端末に送信する（ステップＳ００６）。
【0048】
図９に示すように、Ｒｏｕｎｄ１の推奨計画はユーザＡによって拒否されたため、コントローラ２１０はステップＳ００３を否定判定する。コントローラは、Ｒｏｕｎｄ１の推奨計画に対するユーザＡ，Ｂの応答（図９のＲｏｕｎｄ１）に基づいて、ステップＳ００４（ステップＳ４０１－Ｓ４０５）を実行する。ユーザＡ，Ｂの応答に対する、サーバによる評価結果をＲｏｕｎｄ２として図１３に示す。
【0049】
図１４は、Ｒｏｕｎｄ２の評価結果に基づいて推定された効用関数に対して、ユーザＡの想定計画とユーザＢの想定計画との組み合わせの分布図であって、一つの点計画候補であり、１４００－１４１２は、パレート最適な候補計画である。サーバは、夫々の候補計画について合意確率を計算して、最も高ランクな候補計画（合意確率が最も高い候補計画、図８のＲｏｕｎｄ２）を推奨計画としてユーザＡ，Ｂに合意確率と共に送信する。Ｒｏｕｎｄ２の推奨計画はユーザＡ，Ｂによって受け入れられたので、サーバは、ステップＳ００３を肯定判定して図４のフローチャートを終了する。この結果、図８のＲｏｕｎｄ２に示される計画が最適計画として決定される。
【0050】
図１３において、コントローラ２１０は、推奨計画に対するユーザからの応答に応じて、重みを変更してもよい。ユーザＡは、Ｒｏｕｎｄ１の推奨計画（図８）を拒否し、「１８：００－」の旅客輸送量を「２０」から「１０」に変更したため、効用関数評価モジュール２１２は、ユーザＡは旅客輸送量のバラつきを無くそうとする傾向が強くなったと判定して、WeightBを「０」から「１」に増加させた。一方、ユーザＡは、Ｒｏｕｎｄ１の推奨計画（図８）を受諾したため、効用関数評価モジュール２１２は、ユーザＢは旅客輸送量のバラつきを許容して、Ｒｏｕｎｄ１との差分が大きくなることも許容する傾向が強くなったと判定して、WeightBを「１０」から「１」にする反面、WeightCを「１」から「１０」に増加させた。このようにすることによって、計算機システムはユーザの現状の傾向に合致させて効用関数、そして、合意確率を設定することができる。なお、パレート最適な計画（図１２，１４）の各点の合意確率は次の表１（図１２），表２（図１４）に示す通りである。
また、図８の夫々の計画（Round１，２）の合意確率は表３に示す通りである。
【表1】
【表2】
【表3】
【0051】
既述の実施形態によれば、多主体による計画最適化を実現する際、多主体にとって、お互いの効用関数が不確かな状況下であっても、サーバは各主体の応答から効用関数を推定し、そして、妥協平均速度に基づき許容範囲を推定することができるため、多主体お互いに合意できる計画候補を迅速に設定することができる。これにより、多主体間の業務の効率化や円滑な業務連携の構築が達成される。
【0052】
複数ユーザ夫々が互いにトレードオフの関係にあることは、既述の複数の評価指標の少なくとも１つにおいて、トレードオフの関係にあることを含む。既述の実施形態は本発明の実施形態の一例であって、既述の実施形態に本発明が限定されるものではない。即ち、電車とバスといった異種交通機関の間での計画最適化を例としたが、これに限らず、電車同士、バス同士であってもよい。また、２ユーザ間での計画最適化について説明したが、３ユーザ以上での計画最適化についても本発明を適用できる。交通機関の計画最適化に限られず、生産と流通とが、商品の販売促進のために連携する目的で、夫々の計画を最適化する業務形態にも本発明を適用することができる。ユーザは法人の他、法人の部門、国や地方公共団体の機関、組合、集団、複数個人のグループなど、特に限定されるものではない。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】