JP2021117851A5 - - Google Patents

Description

本発明は、多主体連携計画システムおよび多主体連携計画方法に関する。

交通サービス業や製造業など、サービス提供に複数のリソースを要する分野では、個々のリソースの運用計画を作成することで計画通りのサービス提供を実現している。各リソースの運用計画は、それぞれの管理組織で作成しており、各計画間で不整合が生じた場合は調整作業が必要となる。このため計画間の整合性を確保し、全体として実行可能な計画を作成する取組みが行われている。

例えば、そうした技術として、以下の技術が提案されている。すなわち、部品などの供給元の割付、複数工場の生産スケジュール、配送資源の割付を含むサプライチェーンのスケジューリングを、スケジューリングに必要な情報および各スケジューリングの結果の共有を図ることで、供給元の割付から順次作成する技術（特許文献１参照）などが提案されている。

また、「互いに連携する計画をそれぞれ管理する各組織間で、計画に関する情報の秘匿性を適宜に維持しつつ、計画間の整合処理を効率的で迅速に実行可能とする技術」（特許文献２参照）が提案されている。

特開２０１１－９６１４１号公報 ＷＯ２０１５／０６８２３１Ａ１

特許文献１では、複数工場がそれぞれに割り付けられた計画案を受け入れ，これに従い生産することが想定されている。しかし、交通サービス業や製造業などの分野においては、サービス提供に必要なリソースを管理・計画する主体が、複数企業や、同一企業の複数部門にわたることがあり、その結果として、各計画主体にとって好ましい計画案が計画主体ごとに異なることがある。このような場合に、各計画間の調整を行い、全体として実行可能な計画案を立案する方法は与えられていない。

また、特許文献２では，各計画間の整合処理を迅速に行う方法が開示されているが、不整合がある場合にそれを調整して全体として実行可能な計画案を立案する方法は与えられていない。

そこで本発明は、他の計画主体が同意しやすい運用計画を立案可能とすることで、全体計画の調整が容易になる技術を提供することを目的とする。

本発明の好ましい一側面は、与えられた制約条件を満たす計画案を複数生成する計画案生成装置と、計画案を第１のアルゴリズムで評価して自己評価値を生成する評価装置と、計画案を第１のアルゴリズムと異なる第２のアルゴリズムで評価して連携先推定評価値を生成する評価推定装置と、連携先推定評価値の重みを表すレートを演算する連携先レート演算装置と、を備えるシステムである。このシステムは、複数の計画案を、自己評価値、連携先推定評価値、およびレートから計算される目的関数に基づいて評価する。

本発明の他の好ましい一側面は、CPUと記憶装置を備える情報処理装置で実行される多主体連携計画方法である。この方法では、記憶装置から、制約条件を読み込む第１のステップ、CPUが、制約条件を満たす計画案を複数生成する第２のステップ、CPUが、複数の計画案を、第１のアルゴリズムで評価して自己評価値を生成する第３のステップ、CPUが、複数の計画案を第１のアルゴリズムと異なる第２のアルゴリズムで評価して連携先推定評価値を生成する第４のステップ、記憶装置から、連携先推定評価値の重みを表す連携先レート情報を読み込む第５のステップ、CPUが、複数の計画案に対して、自己評価値、連携先推定評価値、および連携先レート情報から目的関数を計算する第６のステップ、CPUが、計画案から選ばれた少なくともひとつを連携先に提示して応答を得る第７のステップ、CPUが、応答の内容を記憶装置に過去応答情報として記録する第８のステップ、CPUが、過去応答情報に基づいて連携先レート情報を更新する第９のステップ、を実行する。

本発明によれば，他の計画主体が同意しやすい運用計画を立案することができる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例におけるシステム構成を示したブロック図である。 PCの内部構成を示したハードウェアブロック図である。 実施例における過去応答情報111のデータ構造を示した表図である。 実施例における制約条件情報112のうち、変数情報のデータ構造を示した表図である。 実施例における制約条件情報112のうち、変数を用いて表される制約条件のデータ構造を示した表図である。 実施例における追加制約条件情報113のデータ構造を示した表図である。 実施例における計画案情報114のデータ構造を示した表図である。 実施例における連携先からの推定評価指標情報115のデータ構造を示した表図である。 実施例における連携先レート情報116のデータ構造を示した表図である。 実施例におけるシステムの処理フローの概略図である。 実施例における結果表示画面の概略を示したイメージ図である。 実施例における結果表示画面のうち連携先レート情報の表示形式を切り替えたイメージ図である。 実施例における全体計画の作成手順を示すフロー図である。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。

本明細書において単数形で表される構成要素は、特段文脈で明らかに示されない限り、複数形を含むものとする。

実施例で説明される構成の一例は多主体連携計画システムであって，計画連携先から計画案に対する受諾可否の応答を読み込むデータ読込装置と，与えられた制約条件を満たす計画案を複数案生成する計画案生成装置と，計画案に対する連携先からの評価を推定する評価推定装置と，与えられた時間における連携先の優先度を表すレートを演算するレート演算装置と，複数の計画案の中から、自組織の評価値と、連携先のレートと、連携先からの評価推定値とから計算される目的関数の値がよいものを複数選択して連携先に提案する手段と、全ての連携先から受諾された計画案の詳細を表示する手段を含む。さらに表示には，自組織の評価と連携先からの評価推定値と連携先レートを含む情報が表示される。

以下、発明を実施するための形態について、図面を用いて説明する。まず、システム構成から述べる。

図１は実施例におけるシステム構成を示したシステム構成図である。この図において、符号100は多主体連携計画システム、符号101は計画連携先応答提供装置、符号102はネットワーク、符号103は自己の計画の評価装置、符号104はデータ読込装置、符号105は制御装置、符号106は計画案生成装置、符号107は連携先からの評価推定装置、符号108は連携先のレート演算装置、符号109はDB装置、符号110は端末装置、符号111は過去応答情報、符号112は制約条件情報、符号113は追加制約条件情報、符号114は計画案情報、符号115は連携先からの推定評価指標情報、符号116は連携先レート情報、符号117は計画連携先システムである。

多主体連携計画システム100、計画連携先システム117、計画連携先応答提供装置101は、互いにネットワーク102によって通信可能である。図１では、計画連携先応答提供装置101を介して２つのネットワーク102が接続されているが、これは一例であり、ネットワークの構成に制限はない。また、本実施例では、計画連携先応答提供装置101が、多主体連携計画システム100と計画連携先システム117の通信を中継しているが、計画連携先応答提供装置101を省略し、多主体連携計画システム100と計画連携先システム117が直接通信するように構成してもよい。

多主体連携計画システム100と計画連携先システム117-1,117-2は、それぞれが事業あるいはサービス等のために提供されるリソースを管理するためのシステムである。いま、一例として多主体連携計画システム100はリソース群Aを管理し、計画連携先システム117-1はリソース群Bを管理し、計画連携先システム117-2はリソース群Cを管理するものとする。これらの多主体連携計画システム100と計画連携先システム117-1,117-2は、それぞれが異なる事業主体（例えば法人）により運用されてもよいし、一つの事業主体の異なる部門により運営されてもよい。

本実施例では、多主体連携計画システム100は、リソース群Aを使用したサービスの計画を行うものとする。本例では、主体はA～Cの３つとしたが、もちろん主体が４以上であっても同様に本実施例を適用することができる。

計画連携先応答提供装置101は、多主体連携計画システム100を用いて運用計画を作成するリソース群Aの管理組織と連携してサービス提供を行うために必要な、１種類以上の他リソース群（リソース群B、リソース群Cなど）の管理組織の計画情報を提供する。これらの計画情報は、計画連携先システム117-1,117-2から計画連携先応答提供装置101に送信されるものとする。さらに、計画連携先応答提供装置101は、リソース群Aの計画情報の提供を受け、提供されたリソース群Aの計画情報に対する他リソース群管理組織からの承認もしくは修正依頼などの応答を計画連携先システム117-1,117-2から受信し、多主体連携計画システム100に提供する。

なお、計画連携先システム117-1,117-2は、多主体連携計画システム100と同様の構成でもよいが、本実施例では、上記の計画情報や承認もしくは修正依頼などの応答の入力を受付け、計画連携先応答提供装置101に送信する機能、および計画連携先応答提供装置101からの送信を受信する機能を少なくとも備えればよい。計画情報や承認もしくは修正依頼は、各リソース群管理組織の担当者が入力することを想定する。

例えば、鉄道における交通サービスの提供に対し、リソースA群が車両運用にかかわるリソース、リソース群Bが運転手などのオペレーションに関する人的資源、リソース群Cが整備に必要なリソース（機材・設備および整備員などの人的資源など）であるとする。この場合には、計画連携先応答提供装置101は、車両運用計画管理部門で策定されたリソースA群に係る計画に対する、オペレータ要員管理部門および整備部門の承認応答もしくは改定要求を多主体連携計画システム100に伝送する。さらにリソースA群に係る計画が、オペレータ要員管理部門および整備部門で承認の場合には、各部門が作成したオペレータ要員計画および整備計画方法を多主体連携計画システム100に提供する。改定要求は、改定計画が満たすべき制約条件を提供するという形式の情報を含む。一般的には提供はHTTP(Hyper Text Transfer Protocol)によってインターネットを介して行われる。

ネットワーク102はインターネット、もしくは、専用ネットワーク等、計画連携先応答提供装置101と多主体連携計画システム100とを接続する媒体である。ネットワーク102は、有線もしくは無線の形態があり、また複数のネットワークから成っていても良い。

多主体連携計画システム100は、１つ以上の他組織管理下のリソース群（本例ではリソース群BおよびC）と連携してサービスを提供するために、自組織管理下のリソース群（本例ではリソース群A）の割り当て計画を作成するものである。多主体連携計画システム100は、自己の計画の評価装置103、データ読込装置104、制御装置105、計画案生成装置106、連携先からの評価推定装置107、連携先のレート演算装置108、DB装置109、端末装置110を含んで構成されている。

自己の計画の評価装置103は、計画案生成装置106で生成される計画案に対し、自部門（本例では車両運用計画管理部門）から見た評価値を演算する装置である。例えば、車両運用にかかわるリソースの運用計画の評価では、車両による運送量を評価基準とする等である。

データ読込装置104は計画連携先応答提供装置101が提供しているデータを入力として受け取り、DB装置109上に過去応答情報111があり、かつ、制約条件の形式で改定要求がある場合に、制約条件を追加制約条件情報113として保存する装置である。

制御装置105は多主体連携計画システム100を構成する各装置を統括し，システムとして多主体連携計画を立案するよう制御する装置である。制御装置105は、ネットワーク102を介したデータの送受信等、一般のPCが実行する公知の処理についても制御するものとする。

計画案生成装置106は、制約条件情報112および追加制約条件情報113に保存される制約条件群を読み込み、制約条件群を満足するリソース群Aの運用計画案を１つ以上生成する装置である。

連携先からの評価推定装置107は、計画案生成装置106で生成される計画案に対し、連携先（リソース群B、リソース群Cなどの管理組織。本例ではオペレータ要員管理部門および整備部門）から見た評価推定値を演算する装置である。自己の計画の評価装置103とは、異なる立場から計画を評価するため、評価アルゴリズムは自己の計画の評価装置103とは異なるものを用いる。例えば、整備に必要なリソースの運用計画では、機器の稼働率を評価基準とする等である。

連携先レート演算装置108は、多主体連携計画システム100を用いてリソース群Aを管理する組織にとっての、リソース群B,リソース群Cなどを管理する各組織の重要性を示すレートを演算する装置である。

DB装置109は各装置によって作成されたデータを保持するデータベース（ＤＢ）であり、過去応答情報111、制約条件情報112、追加制約条件情報113、計画案情報114、連携先からの推定評価指標情報115、連携先レート情報116といったデータを含んで構成されている。なお、DBはデータを登録したり、検索したり、関連するデータを抽出したり、削除したりする機能を持っている。本実施例ではDB装置109は一般のPCで実現すると仮定しており、その場合、DB装置は一般のPC上と、その上で動作する一般のDBソフトを用いて実現できる。

端末装置110は多主体連携計画システム100のオペレータが操作する端末である。端末装置110は、立案されたリソース群Aの運用計画を表示したり、オペレータの承認を受け付けて処理フローを進める装置である。使われるデータは、以下説明するデータを含んでいる。

過去応答情報111は、多主体連携計画システム100が提案した、リソース群Aの運用計画に対する、リソース群B、リソース群Cなどの管理組織からの承認、選択、追加制約条件を伴う拒否などの応答情報である。

制約条件情報112は、リソース群Aの運用計画を立てるにあたってリソース群Aが認識している制約条件である。これは、例えば、リソース群Aが車両運用にかかわるリソースである場合には、車両の有無や、線路の有無、また、移動時間の十分性などの車両の物理的な連続移動を可能にする条件を含む。また、例えば、リソース群Aが整備にかかわるリソースである場合には、整備設備の有無や、整備人員の有無、十分な整備時間の有無を含む。

追加制約条件情報113は、リソース群B、リソース群Cの管理組織など、リソース群Aと連携してサービスを提供する組織が、リソース群Aの運用計画を立てるにあたって追加で課す制約条件である。例えば、リソース群Aが車両運用にかかわるリソース、リソース群Cが整備にかかわるリソースである場合に、リソース群Cを管理する組織が、「特定の車両が整備のために特定の時刻までに特定の場所に移動する」という追加制約条件を課す。

連携先からの推定評価指標情報115は、リソース群Aの運用計画案に対する、リソース群B、リソース群Cなどの管理組織からみた評価の推定値情報である。各計画案に対する評価推定値の組、または、運用計画案から評価推定値を計算する関数であってもよい。

連携先レート情報116は、リソース群Aの管理組織から見た、リソース群B、リソース群Cなどの管理組織の重要度情報である。なお、これらデータの詳細については後述する。

図１の各装置やシステム101、103～110、117は、本実施例では一般のPCを用いて実現されると仮定する。ただし、一般のPCでなく専用の機械を用いて実現することも可能である。また、図１の各装置は、互いにネットワークで接続されていると仮定する。また、図１の各装置やシステムは単一のPCを用いて構成してもよいし、任意の複数のPCで機能を分担してもよい。以下、各装置の構成として、一般のPCの内部構成につき、図２のPC200の構成を示す図で説明する。

図２において、符号201はCPU、符号202はメモリ、符号203はインターフェース、符号204はネットワークインタフェース、符号205はキーボード、符号206は画面、符号207はマウス、符号208はハードディスクである。

CPU201は中央処理装置(Central Processing Unit)であり、メモリ202に記録されている、またはあらかじめハードディスク208からメモリ202に転送されたプログラムを実行することができる装置である。なお、プログラムは、必要に応じて、PCが利用可能であり、着脱可能な記憶媒体によって導入されてもよい。この場合、前記記憶媒体を読み取るための装置をインターフェース203に接続する。なお、このような前記記憶媒体及びそれを読み取るための装置としては、光ディスク（ＣＤ，ＤＶＤ，ブルーレイディスク等）を用いるものや、フラッシュメモリを用いるものが一般に知られており、これを用いることができる。また、プログラムは、必要に応じて、ネットワークインタフェース204によって、通信媒体（通信回線又は通信回線上の搬送波）を介して、PCに導入されてもよい。

メモリ202はプログラムやデータを一時的に記録しておくものである。インターフェース203はPCシステム内の装置を接続するためのものである。ネットワークインタフェース204はPCシステム外のPC等と通信をするための装置である。キーボード205はPCシステムへの指令やデータ入力を行うために、PCシステムの操作者が操作する装置である。画面206は処理結果等を表示するための装置である。マウス207は画面上に表示されるポインタを動かし、また任意の場所でオペレータにボタンを押し下げさせることで、画面上の位置を指定し、何らかのアクションをCPU201に伝える装置である。なお、マウス207はタッチパネル等、他のポインティングデバイスによって代替することもできる。タッチパネルでマウス207を代替する場合、通常ポインタは不要となる。ハードディスク208はプログラム及びデータを格納する装置であり、例えば、磁気ディスクや不揮発性メモリ等によって構成することができる。この場合、ハードディスク208に格納されたプログラム及びデータは、ハードディスク208の電源がＯＦＦとなった後にＯＮになった場合でも、通常保持される。なお、ハードディスク208には、予めオペレーティングシステム（OS）が導入されていても良い。このようにすることで、ファイル名を用いてプログラムを指定することなどができるようになる。ここで、OSとは、計算機の基本ソフトウェアのことであり、一般に広く知られたOSを用いることができる。

以上、図２に示すPC200を参照して、本システムのハードウェア構成について説明した。図１の各装置やシステム101、103～110、117の機能は、ハードディスク208あるいはメモリ202に格納されたプログラムがCPU201によって実行されることで、定められた計算や処理を他のハードウェアと協働して行うことにより実現される。すでに述べたように、各装置毎に１つのPCで構成してもよいし、全ての装置を１つのPCで構成してもよい。あるいは、１つの装置をネットワークで接続された複数のPCで構成してもよい。実施例中、プログラムで実現した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウェアでも実現できる。次に、データ構造について述べる。

図３を用いて、まず、実施例における過去応答情報111について説明する。過去応答情報111は、制御装置105により生成される。図３は、実施例における過去応答情報111のデータ構造を示した図である。

提案ID301は他組織への計画提案処理を一意に特定する番号である。計画案生成装置106で生成した運用計画案を特定の計画連携先システム117に送信することを契機に提案IDが生成される。計画ID302は提案するリソース群Aの運用計画案を一意に特定する番号である。計画案生成装置106で運用計画案を生成することを契機に計画IDが生成される。例えば、同一の計画案が複数の異なる組織に提案される場合には、同一の計画IDと異なる提案IDとを用いて記録される。

提案先303には、前記提案処理における提案先組織名が記載される。提案日時304、応答日時305は、それぞれ、提案処理において、リソース群Aの管理組織が提案先に計画案を送信した日時と、前記計画案に対する提案先組織からの応答を計画連携先応答提供装置101から受信した日時が記載される。

レート変動306には、提案先が計画案を承認した場合および拒否した場合のレート変動値が記載される。図３の例では記号「/」の前の数字は提案先が承認した場合のレート変動値、後の数字は提案先が拒否した場合のレート変動値を示す。
本実施例では、レート変動306は時間とともに変化することを想定しており、その値は後述する連携先からの評価推定装置107により計算される。

応答307は、提案に対する提案先の応答である。追加制約308には、提案先からの応答が拒否かつ追加制約を要求する場合に、その追加制約を記載する。提案先の応答や追加制約は、提案先のオペレータが計画連携先システム117の例えばキーボードを用いて入力するものとする。次に、実施例における制約条件情報112および追加制約条件情報113のデータ構造を説明する。

図４は、実施例における制約条件情報112のうち、制約変数のデータ構造を示した図である。変数名401は、運用計画を記述するために決定すべき変数、すなわち決定変数を表す。タイプ402は変数のタイプを表す。変数タイプの取り得る型は、例えば、整数、実数、文字変数、ブーリアン型変数を含む。説明403では変数の意味を説明する。例えば、「変数」X(1,1)は整数値を取り得て、機材1が１番目に使用される便名を表す。制約変数のデータ構造は、オペレータ（例えばリソース群Aの管理者）が定義して端末装置110から入力し、システム運用前にDB装置109に格納しておくものとする。

図５は、実施例における制約条件情報112のうち、前記決定変数が満たすべき制約条件のデータ構造を示した図である。制約ID501は制約を一意に定めるIDである。制約内容502には制約の内容が記載される。例えば、「制約ID」が「1」であるものの「制約内容」は「LT(1,1)≧40」である。すなわち、機材1の１番目の便が次の停留地に到着するまでにかかる時間が40分以上であることを表している。制約条件の制約内容は、オペレータ（例えばリソース群Aの管理者）が定義して端末装置110から入力し、システム運用前にDB装置109に格納しておくものとする。

以上述べた図４、図５のデータと、DB装置の機能を用いることにより、計画案生成装置106は、リソースAの運用計画案を立案する際に満たすべき制約条件を参照することができる。

図６は、実施例における追加制約条件情報113の、前記決定変数が満たすべき追加制約条件のデータ構造を示した図である。

追加制約ID601は、追加制約を一意に定めるIDである。追加制約内容602には追加制約の内容が記載される。例えば、「追加制約ID」が「1001」であるものの「追加制約内容」は「Stay(1)=BaseA」である。すなわち、機材1の最終停泊地はBaseAであることを示している。追加制約内容602は、運用計画案が提案された提案先のオペレータが、単純承認しない場合に計画連携先システム117に入力したものである。図６に示すように、追加制約内容602は図４に示した制約変数のデータの変数名401を引用している。追加制約内容602は、計画連携先応答提供装置101から送信された内容を、データ読込装置104により、DB装置109に記録される。

以上述べた図４、図６のデータと、DB装置の機能を用いることにより、計画案生成装置106は、リソースAの運用計画案を立案する際に満たすべき追加制約条件を参照することができる。次に、実施例における計画案情報114のデータ構造を説明する。

図７は、実施例における計画案情報114のデータ構造を示した図である。計画案情報114は、計画案生成装置106が生成する。計画ID701は、リソース群Aの運用計画案を一意に特定する番号である。変数名702は、計画案で決定すべき決定変数であり、値703には、当該計画案での決定変数の値が記載される。特定の計画IDの計画案は、全ての決定変数の値が与えられることで説明される。すなわち、「計画ID」が「１」の計画案は、「X(1,1)」の値が「5」、「X(1,2)」の値が「3」、のように、全ての決定変数の値が与えられることで表現される。次に、実施例における連携先からの推定評価指標情報115のデータ構造を説明する。

図８は、実施例における連携先からの推定評価指標情報115のデータ構造を示した図である。推定評価指標情報115は、連携先からの評価推定装置107が生成する。提案ID801は他組織への計画提案処理を一意に特定する番号である。また、計画ID802は、本実施例ではリソース群Aの運用計画案を一意に特定する番号である。提案予定日時803には、前記計画IDで示される計画が、前記提案IDであらわされる提案処理によって前記計画連携先応答提供装置101に伝達される予定日時が記載される。

この他の列には、前記計画ID802で特定される計画案が、前記提案予定日時803であらわされる時刻に計画連携先応答提供装置101に伝達されるとき、この計画案に対する他組織からの推定評価値804,807と、前記計画案が他組織から受け入れ、もしくは拒否された時の他組織のレート変動値805,806,808,809がこの他の列に記載される。

他組織からの推定評価値804,807は、他組織（本実施例ではリソースBおよびCの管理主体）の立場から評価した計画案の評価値を示す。評価のためのアルゴリズムは、システム運用前に端末装置110から設定しておくものとする。評価のためのアルゴリズムは他組織自身に作成してもらい提供を受けたものでもよい。

評価のためのアルゴリズムは時間的に不変としてもよいし、時間に依存して変化するものでもよい。本実施例では、時間に依存するアルゴリズムとした。すなわち、同じ計画案でも、提案予定日時803に依存して推定評価値が変化する。同じ組織であっても、時期によっては自組織の都合を優先させなければならない場合があるためである。なお、時間に依存するアルゴリズムとしてよいのは、自己の計画の評価装置103の評価アルゴリズムも同様である。

レート変動値805,806,808,809は、推定評価値804,807に基づいて、連携先からの評価推定装置107が計算する。本実施例では、他組織の推定評価が低いものほど、承認時のレート上昇率を大きくし、拒否時のレート下降率を小さくするというポリシーでレート変動値を計算している。すなわち、レート変動値は他組織の推定評価と応答の両者に依存して決定される。例えば推定評価値が低いにも関わらず承認してくれた場合、報酬としてその組織のレートに反映すべきだからである。

例えば、リソース群Bの管理組織とリソース群Cの管理組織と連携する場合には、計画ID「１」、提案ID「１」で特定される計画提案に対するBの推定評価値804は「80」であり、前記提案をBが受け入れた場合のBのレート変動値805は「0」、拒否した場合のBのレート変動値806は「-20」である。さらに、前記提案に対するCの推定評価値807は「60」であり、前記提案をCが受けいれた場合のレート変動値808は「+20」、拒否した場合のレート変動値809は「0」である。次に、実施例における連携先レート情報116のデータ構造を説明する。

図９は、実施例における連携先レート情報116のデータ構造を示した図である。連携先レート情報116は、連携先からの承認あるいは拒否の応答の都度、連携先レート演算装置108が推定評価指標情報115を参照してレート値を計算し、内容を更新する。日付901および時刻帯902は、一定の幅を持った時間帯を一意に特定する日付と時刻帯である。その他の列には、前記日付901および前記時刻帯902における、連携先のレート値が記載される。すなわち、「2018/12/01」の「6:00-7:00」におけるBのレート値903は「50」であり、Cのレート値904は「60」である。以上、データ構造について説明した。次に、処理について述べる。まず、システムの概略の処理から説明する。

図１０は、実施例におけるシステムの処理フローS1000の概略図である。

ステップS1001は、制御装置105のCPU201が、端末装置110にオペレータコマンド待ちを指示する処理である。

ステップS1002は、端末装置110のCPU201が，端末装置110の画面206にコマンド待ち画面を表示する処理である。

ステップS1003は、多主体連携計画システム100のオペレータが，端末装置110に，リソース群Aの運用計画立案を指示する処理である。

ステップS1004は、端末装置110のCPU201が，オペレータコマンド受付を制御装置105に報告する処理である。

ステップS1005は、制御装置105のCPU201が，計画案生成装置106にリソース群Aの運用計画案を指示する処理である。

ステップS1006は、計画案生成装置106のCPU201が，データ読込装置104に、制約条件情報112および追加制約条件情報113の読み込みを指示し、データ読込装置104がデータを読み込む処理である。

ステップS1007は、計画案生成装置106のCPU201が，制約条件情報112および追加制約条件情報113を満足する計画案を複数種類作成し、計画案情報114としてDB装置109に保存する処理である。ここで、与えられた制約条件を満足する計画案の作成は、CPソルバやMIPソルバなどをはじめとする汎用数理最適化ツールを用いて行うことができる。

ステップS1008は、制御装置105のCPU201が、連携先からの評価推定装置107に、計画案情報114に保存される計画案に対する連携先評価推定値の演算を指示する処理である。

ステップS1009は、連携先からの評価推定装置107のCPUが、連携先からの評価の推定値を演算し、連携先からの推定評価指標情報115としてDB装置109に保存するステップである。ここで連携先からの評価推定値（図８の804,807）は、例えば、リソース群Aの運用計画に対する関数として設計してもよい。例えば、リソース群Aの運用計画が鉄道の本線運行計画であって、連携先Bが整備に関するリソースを運用する組織である場合、Bから見た評価は、各車両の停泊地と、整備のために停泊地に到着する時刻と、翌日本線運行のために停泊地を出発する時刻と、計画提案予定日時からなる関数として設計してもよい。また、関数の設計は、例えば、過去の計画案に対してBのオペレータがつけた評価値データを収集し、これに対するカーブフィッティングや、機械学習などの一般的なデータマイニング技術を用いて行ってもよい。計画提案予定日時は、例えば、計画立案時刻に一定数の時間を足して計算してもよい。これらの関数は、システム運用前に連携先からの評価推定装置107のハードディスク208等に格納しておくものとする。

さらに、ステップS1009では、連携先からの評価推定装置107のCPUが、評価推定値をもとに、提案計画が連携先組織に受諾された場合および拒否された場合の、連携先組織のレート変動を演算する。これは、例えば、受諾時と拒否時とに対し推定評価の基準値を設定し、基準値からの差分を用いて計算してもよい。例えば、計画案に対するBの推定評価値をEV、受諾時の基準値をSV_acceptとし、受諾時のレート変動ΔR_acceptを式（１）で計算してもよい。

また、例えば、計画案に対するBの推定評価値をEV、拒否時の基準値をSV_rejectとし、拒否時のレート変動を式（２）で計算してもよい。

また、レート変動値の算出に対し、その他の任意の関数を設計してもよい。特に、レート変動値が提案時刻に依存する関数として設計してもよい。

ステップS1010は、制御装置105のCPU201が、計画案情報114と連携先からの推定評価指標情報115と連携先レート情報116と自己の計画の評価装置103の評価結果を読み込み、１つ以上の計画案を選定し、計画連携先応答提供装置101に送信する処理である。ここで前記計画連携先応答提供装置101に送信する計画案は、例えば、式（３）の目的関数により評価されソートされる。

計画案の選定方法の一例としては、複数の計画案から目的関数を大きくする１または複数の計画案を優先して選定する。選定された計画案は、多主体連携計画システム100のオペレータに端末装置110で複数表示して選択させ、選択された計画案を計画連携先応答提供装置101に送信してもよい。あるいは、目的関数の一番大きなものを自動的に計画連携先応答提供装置101に送信してもよい。

ここで、V_Aは計画案に対する自組織のKPI（Key Performance Indicator, 重要経営指標）評価、EV_BおよびEV_Cは計画案に対するB、Cからの評価推定値、R_BおよびR_Cはそれぞれ、組織Bおよび組織Cの現在のレート値である。V_Aは第１のアルゴリズムにより自己の計画の評価装置103で算出される。EV_BおよびEV_Cは第２および第３のアルゴリズムにより連携先からの評価推定装置107で算出される。R_BおよびR_Cは連携先レート演算装置108で算出される。なお、式（３）のR_B、R_Cの代わりにR_BとR_Cからなる任意の関数を重みとして使用してもよい。

ステップS1011は、計画連携先応答提供装置101のCPU201が、連携先に前記選定済計画案の内容を提示し、各案について受諾可否の応答を取得し、結果を過去応答情報111に保存し、制御装置105に応答取得を報告する処理である。

ステップS1012は、連携先レート演算装置108が連携先レートを演算する処理である。例えば、各計画案に対する受諾可否の応答レート変動の総和をとり、元の連携先レートに加えてもよい。あるいは、連携先レート演算装置108は、図３に示す過去応答情報111を参照し、応答307の内容に応じて１エントリ毎にレートを更新してもよい。あるいは、所定数のエントリを纏めてバッチ処理してもよい。更新したレート値は、連携先レート情報116として記録される。

また、例えば、前記総和に連携先ごとに設定した適当な重み関数を適用してもよい。また、例えば、一日の運用時間における連携先レートの関数をあらかじめ連携先のリソース運用の柔軟性や重大性などに基づいて決めておき、この関数を前記総和に基づき平行移動、拡大縮小することによって連携先レートを演算してもよい。

ステップS1013は、制御装置105が過去応答情報111を読み込み、すべての連携先が受諾する計画案が存在するかどうかを判定する処理である。存在する場合はステップS1014へ、存在しない場合はステップS1015へ進む。

ステップS1014は、端末装置110のCPU201が，端末装置110の画面に計画案と、連携先のレート情報を表示する処理である。

ステップS1015は、データ読込装置104のCPU201が、過去応答情報111から追加制約を読み込み、追加制約条件情報113としてDBに保存する処理である。ステップS1015処理後は、更新された追加制約情報をもとにステップS1005に戻る。

なお、ステップS1013において、所定時間あるいは所定ステップ経過後においても、すべての連携先が受諾する計画案が存在しない場合には、ステップS1014では、端末装置110のCPU201が，端末装置110の画面に全ての連携先が受諾しなかった旨を表示して処理を終了することにしてもよい。

以上、実施例におけるシステムの処理フローの概略を説明した。次に、ステップS1104の結果表示について、結果表示画面を、図１１、図１２を用いて説明する。

図１１は、実施例における結果表示画面の概略を示した図である。この図において、符号1101は結果表示画面、符号1102は運用計画表示部、符号1103は計画案切り替えタブ、符号1104はKPI表示部、符号1105はレート比率表示部、符号1106はレート表示切替ボタンである。結果表示画面1101は、端末装置110の画面206に表示される。

運用計画表示部1102はすべての連携先が受諾したリソース群Aの運用計画を表示する部分である。複数案受諾されている場合には、計画案切り替えタブ1103が押されることにより、他の計画案を表示する。KPI表示部1104は、運用計画表示部1102で表示される計画案に対する自組織内KPIや連携先からの推定評価など、関連するKPIを表示する。レート比率表示部1105は、連携先レートの現在の比率を表示する。レート表示切替ボタン1106が押されることにより、現在の比率の代わりに連携先レートの時間変化を表示してもよい。レートの時間変化表示に切りかえた表示画面を図１２に示す。

図１２は実施例における結果表示画面のうち連携先レート情報の表示形式を切り替えた図である。この図において、符号1201はレート時間変化表示部である。レート時間変化表示部は、連携先レートの時間変化を横軸時刻、縦軸レートとして表示する。レート表示切替ボタン1106が押されると、連携先レートの現在の比率表示に戻る。

図１３は、実施例において全体計画を作成するまでの流れを説明したフロー図である。

処理S1000において、多主体連携計画システム100はリソースAの運用計画を作成する。この処理は、図１０において説明した処理である。処理S1000の結果、全ての連携先が受諾する計画案が１つ以上作成されている（処理S1013）。この結果は、図１１あるいは図１２のように、多主体連携計画システム100のオペレータに表示される（処理S1014）。オペレータは、全ての連携先が受諾する運用計画が複数ある場合は、端末装置110を用いてそれらから連携先に提案するものを一つ選択する。

処理S2000では、多主体連携計画システム100の制御装置105は、ネットワーク102-1、計画連携先応答提供装置101、ネットワーク102-2を経由して、計画連携先システム117-1,117-2に選択されたリソースAの運用計画の内容を通知する。

処理S3000では、連携先は計画連携先システム117-1,117-2で受信したリソースAの運用計画に整合するように、自己リソースB,Cの運用計画を作成する。この処理は、連携先において手作業で作成してもよい。あるいは、計画連携先システム117-1,117-2が、計画案生成装置106相当の構成を備えることにより、自動的に作成してもよい。

処理S4000では、連携先は計画連携先システム117-1,117-2で自己リソースの運用計画B,Cを計画連携先応答提供装置101に送信する。

処理S5000では、計画連携先応答提供装置101は、リソースA,B,およびCの運用計画を統合して全体計画を生成する。各リソースの運用計画の内容やそれらの統合については、公知でもあるので詳細は省略する。

処理S6000では、計画連携先応答提供装置101は、全体計画を多主体連携計画システム100と計画連携先システム117-1,117-2に送信する。

上記の説明では、全体計画の生成処理S5000と通知処理S6000は計画連携先応答提供装置101が行っているが、計画連携先応答提供装置101を省略し、多主体連携計画システム100が処理S5000と処理S6000を行うように構成することも可能である。

以上のようにして、多主体連携計画システム100が連携先の承認が得られたリソースAの運用計画を作成する。この計画を連携先に送付し、連携先ではこの計画に適合させて、リソースBやCの運用計画を作成する。各リソースの運用計画を統合することにより、全体計画が完成する。本実施例では、個々のリソースの運用計画立案後、各計画間調整作業を行うことで全体計画を作成する従来のやり方に比べ、効率的に全体計画が作成できる。

以上説明した実施例によれば、多主体連携計画システム100の計画案生成装置106が生成した計画を評価する目的関数には、自己の評価要素に加え連携先の評価要素が含まれる。このため、連携先が同意しやすい計画が提案可能となる。また、連携先の評価要素には重みづけがなされるため、複数の連携先があった場合でも計画案生成装置106が生成する計画の内容を調整しやすい。

さらに、多主体連携計画システム100は連携先からの応答を収集し、応答に基づいて連携先レート演算装置108が連携先の重みを計算する。重みを連携先の過去の応答に基づいて調整することにより、連携先の行動特性を目的関数に反映することができる。例えば、計画に対する承認と拒否の応答内容に基づいて連携先の重みを調整することにより、協力的な連携先の重みが大きくなり、将来の計画で優遇されることが期待できるようになる。このため、各計画主体が他主体の都合を配慮して自発的により合意しやすい計画を策定し、計画間不整合があった場合には，譲ることのできる主体が自発的に譲るモチベーションを得ることができる。よって、計画間の調整を円滑化・迅速化することができる。

なお、実施例では鉄道における交通サービスの提供を例にして説明したが、航空、船舶その他の旅客や輸送の分野でも同様に適用が可能である。あるいは、製造や物流分野においても、複数のリソースの運用計画の調整を行う場合に、本実施例は適用が可能である。また、実施例では説明上リソースはA,B,Cの3つとしているが、2、あるいは4以上のリソースの場合も同様に適用が可能であることはいうまでもない。

以上、本実施例について説明したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

また、実施例の説明で鉄道運行計画と、整備計画、人的リソース運用計画の連携を述べたが、本発明の適用分野は鉄道事業に限らず、航空機運航、MaaS (Mobility as a Service)をはじめとする交通サービス業、生産業、他のサービス業におけるリソース割当にも適用可能である。

100…多主体連携計画システム
101…計画連携先応答提供装置
102…ネットワーク
103…自己の計画の評価装置
104…データ読込装置
105…制御装置
106…計画案生成装置
107…連携先からの評価推定装置
108…連携先レート演算装置
109…DB装置
110…端末装置
111…過去応答情報
112…制約条件情報
113…追加制約条件情報
114…計画案情報
115…連携先からの推定評価指標情報
116…連携先レート情報
1101…結果表示画面
1102…運用計画表示部
1103…計画案切り替えタブ
1104…KPI表示部
1105…レート比率表示部
1106…レート表示切替ボタン
1201…レート時間変化表示部