JP7438857B2 - 多主体連携計画システムおよび多主体連携計画方法 - Google Patents

Description

本発明は、複数の組織間で整合性のとれた計画の作成を容易にするための技術に関する。

交通サービス業や製造業など、サービス提供に複数のリソースを要する分野では、個々のリソースの運用計画を作成することで計画通りのサービス提供を実現している。各リソースの運用計画は、それぞれの管理組織で作成しており、各計画間で不整合が生じた場合は調整作業が必要となる。特に、突発事象により事前に合意した計画が実行できなくなった場合には、短期間のうちに組織間で整合性のとれた代替計画を合意して実行に移す必要がある。

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

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

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

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

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

発明者らは、他の計画主体が同意しやすい運用計画を立案可能とすることで、全体計画の調整が容易になる技術を提供できるのではないかと考え、日本国特許出願2020－012131号として提案した。この提案では、例えば、リソース群のうちひとつを管理する組織が、自組織が管理するリソース群について複数の計画案を他の関連リソース群の管理組織に提示し、各組織からの計画案受け入れ可否の返答を得ることで、全組織が合意できる計画を立案することができる。

しかし、特に突発事象により急な代替案の合意が必要になる場合には、あるリソース群Aについての複数の代替計画案の提示を受けた他の組織が、リソース群Aの全ての代替案に対し、自組織管理のリソース群を整合するよう計画できるかを短時間で検討して返答するのが困難である。一方で、リソース群Aの管理組織が他組織の状況を考慮することなくある代替計画案をひとつ選び複数組織に打診した場合、当該代替案の実行可能時間までにすべての組織からの合意を得ることができず、別の代替案の立案からやり直すことになる可能性がある。

そこで，本発明は，複数の組織間で計画案を合意するための時間を短縮することを目的とする。

本発明の好ましい一側面は、計画案を複数生成する計画案生成装置と、前記計画案に対し時刻に依存する評価値を演算する評価装置と、前記計画案に対し時刻に依存する調整成功確率を演算し、前記評価値と前記調整成功確率から、時刻に依存する値である推奨度を演算する推奨度演算装置と、を備える多主体連携計画システムである。

本発明の好ましい他の一側面は、CPUと記憶装置を備える情報処理装置で実行される多主体連携計画方法であって、前記CPUが、計画案を複数生成して、前記記憶装置に記憶する第１のステップ、前記CPUが、複数の前記計画案を評価して自己評価値を生成し、前記記憶装置に記憶する第２のステップ、前記CPUが、複数の前記計画案の調整時間を推定して調整時間推定値を得、前記記憶装置に記憶する第３のステップ、前記CPUが、前記自己評価値と前記調整時間推定値に基づいて、前記計画案の推奨値を演算し、前記記憶装置に記憶する第４のステップ、前記CPUが、前記推奨値に基づいて複数の前記計画案から少なくとも一つを選択し、連携先に提案する第５のステップ、を実行する、多主体連携計画方法である。

本発明によれば，複数の組織間で計画案を合意するための時間を短縮することができる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例におけるシステム構成を示したブロック図である。 システムを構成するPCの内部構成を示したブロック図である。 実施例における過去応答情報111のデータ構造を示した表図である。 実施例における代替計画案情報113のデータ構造を示した表図である。 実施例における計画の自己評価情報114を示したグラフ図である。 実施例における計画の他の自己評価情報114を示したグラフ図である。 実施例における計画の推定調整時間情報115のデータ構造を示した図である。 実施例における計画の推奨度情報116のデータ構造を示した図である。 実施例におけるシステムの処理フローの概略図である。 推奨度演算装置108が行う、ステップS812の詳細を示すフロー図である。 実施例における結果表示画面の概略を示した図である。 実施例において全体計画を作成するまでの流れを説明したフロー図である。

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

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

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

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

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

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

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

実施例で説明される構成の一例を挙げるならば、多主体連携計画システムであって、代替計画に対し時刻に依存する評価値を演算する手段と，代替計画の組織間調整にかかる時間を推定する手段と，代替計画の評価値と推定調整時間から、時刻に依存する推奨度を演算する手段と，を含むものである。このシステムは、現在時刻において推奨度が最も高い計画を連携先に提案する多主体連携計画システムであって、提案計画の推奨度が最高である時刻までにすべての連携先から受諾の応答が得られない場合に、当該時刻からの推奨度を再計算し、当該時刻で推奨度の最も高い計画を連携先に提案する。

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

図１は実施例におけるシステム構成を示したシステム構成図である。この図において、符号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で生成される計画案に対し、自部門（本例では車両運用計画管理部門）から見た評価値を演算し、結果を計画の自己評価情報114として保存する装置である。評価値の定義は任意であり、例えば、車両運用にかかわるリソースの運用計画の評価では、元計画からの総遅延時間や車両による運送量の変動を評価基準とする等である。評価のためのアルゴリズムや評価関数は、予め定義して自己評価装置103に記憶しておくものとする。なお、本実施例では、短期間のうちに組織間で整合性のとれた代替計画を合意して実行に移すことを目的として構成しているが、代替計画でない計画一般に対して適用してもよいのは言うまでもない。

データ読込装置104は計画連携先応答提供装置101が提供しているデータを入力として受け取り、DB装置109上に過去応答情報111として保存する装置である。

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

代替計画案生成装置106は、リソース群Aの運用計画代替案を１つ以上生成し、結果を代替計画案情報113として保存する装置である。

計画の調整時間推定装置107は、代替計画案生成装置106で生成される代替計画案に対し、連携先（リソース群B、リソース群Cなどの管理組織。本例ではオペレータ要員管理部門および整備部門）が受諾・拒否の応答を返答するまでにかかる時間（調整時間推定値という）を推定し、結果を計画の推定調整時間情報115として保存する装置である。

計画の推奨度演算装置108は、代替計画案生成装置106で生成される代替計画案に対し、計画の自己評価情報114と計画の推定調整時間情報115とから、連携先との調整に選ぶべき度合いを表す推奨度を演算し、結果を推奨度情報116に保存する装置である。

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

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

過去応答情報111は、多主体連携計画システム100が提案した、リソース群Aの運用代替計画案に対する、リソース群B、リソース群Cなどの管理組織からの受諾・拒否等の決定と、これらの決定を、多主体連携計画システム100が代替計画を提案してから、計画連携先応答提供装置101あるいは多主体連携計画システム100が、リソース群B、リソース群Cなどの管理組織から受け取るまでに要した時間などの応答情報である。

連携先業務情報112は、計画連携先であるリソース群B、リソース群Cなどの管理組織がリソース群Aの運用計画の代替案を受けて受諾・拒否を決定し、決定を計画連携先応答提供装置101に伝送するまでの業務についての情報である。例えば、ある条件下で代替案の連絡があった場合に定時間以内に返答することを規定している場合に、このような業務マニュアルの情報を含む。

代替計画案情報113は、代替計画案生成装置106が生成したリソース群Aの運用計画代替案の情報である。これは例えば、車両運用であれば車両を割り当てる便名や時刻などの決定変数と、その値の組み合わせであるなど、運用計画が一意に理解される形式であればよい。

計画の自己評価情報114は、代替計画案生成装置106で生成されるリソース群Aの代替運用計画に対して、計画の自己評価装置103が評価づけた値情報である。この評価は、代替計画案が関連他組織に受諾されて実行される場合の、自部門から見た価値を演算する。例えば、車両運用にかかわるリソースの運用計画の評価では、元計画からの総遅延時間や車両による運送量の変動を評価基準とする等である。評価のためのアルゴリズムは、予めユーザが定義して自己評価情報114が記憶しておくものとする。

この評価値は、代替案が実行に移される時間に依存する。例えば、組織間で合意して実行に移される時刻によって、計画を全体として後ろ倒しにせざるをえない場合には、総遅延時間が増えることになり、組織間合意と計画実行時刻が遅延する程計画の評価は下がる。また、特定の時刻を超えると実行が不可能になる計画案の場合には、組織間合意と計画実行時刻がある閾値を超えた時点で評価値がゼロになることもある。

計画の推定調整時間情報115は、代替計画案生成装置106で生成されるリソース群Aの代替運用計画に対して、リソース群B、リソース群Cなどの管理組織から受諾・拒否の返答を受け取るまでに要する時間の推定値を、計画の調整時間推定装置107が演算した結果の情報である。

計画の推奨度情報116は、計画の自己評価情報114と計画の推定調整時間情報115を含む情報から、計画の推奨度演算装置108が演算した、１つ以上のリソース群Aの代替運用計画に対する推奨度の情報である。この推奨度の高い代替計画がリソース群B、リソース群Cなどの管理組織との調整にかけられる。なお、これらデータの詳細については後述する。

図１の各装置やシステム101、103～110、117は、本実施例では一般のPCを用い、PCの中央処理装置が、記憶装置に格納されたプログラムを実行することによって各装置の機能が実現されると仮定する。ただし、一般のPCでなく専用の機械を用いて実現することも可能である。また、図１の各装置は、互いにネットワークで接続されていると仮定する。また、図１の各装置やシステムは単一のPCを用いて構成してもよいし、任意の複数のPCで機能を分担してもよい。

本実施例では、多主体連携計画システム100はリソース群Aを管理する管理システムの機能を兼ねるものとして記載している。すなわち、多主体連携計画システム100は、リソース群Aを管理する計画連携先システム117の機能を含む。ただし、多主体連携計画システム100から計画連携先システム117の機能を省略し、複数の計画連携先システム117で共有する構成とすることも可能である。この場合には、多主体連携計画システム100は、例えば計画連携先システム117-1からの指示をトリガにし、計画連携先システム117-2等の他の計画連携先システムに提案するべき計画案を選択する。

また、別の形態としては、計画連携先システム117-1、117-2がそれぞれ、多主体連携計画システム100の構成を備えていてもよい。

＜２.システムのハードウェア構成＞
以下、各装置やシステム101、103～110、117の構成として、一般の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は応答日時305と提案日時304との差分であり、提案先が代替計画の提案を受けてから受諾可否の決定を計画連携先応答提供装置101に送るまでに要した時間である。応答307は、提案に対する提案先の応答である。

次に、実施例における代替計画案情報113のデータ構造を説明する。

図４は、実施例における代替計画案情報113のデータ構造を示した図である。代替計画案情報113は、代替計画案生成装置106が生成する。計画ID401は、リソース群Aの運用計画案を一意に特定する番号である。変数名402は、計画案で決定すべき決定変数であり、値403には、当該計画案での決定変数の値が記載される。特定の計画IDの計画案は、全ての決定変数の値が与えられることで説明される。すなわち、「計画ID」が「１」の計画案は、「X(1,1)」の値が「5」、「X(1,2)」の値が「3」、のように、全ての決定変数の値が与えられることで表現される。

次に、実施例における計画の自己評価情報114のデータ構造を説明する。

図５Ａは、実施例における計画の自己評価情報114を示した図である。各計画に対する自己評価情報は、時間に依存する関数として表現される。すなわち、自己評価情報114は、時間tと評価値Eの関係を示すデータである。

評価値Eを計算するための評価関数E(t)は、ユーザが定義可能である。例えば、計画の遅延時間を評価対象とし、遅延時間に対して評価値が線形に減少するという評価関数を用いた場合、例えば、計画ID1に対する評価値501は、現在時刻から7分後まで一定であり、7分を超えると計画を後ろ倒しに修正して実行する必要が生じるため、評価値が下がる。計画ID2に対する評価値502も同様である。また、計画ID3に対する評価値503は、現在時刻から＋15分まで一定であるが、15分を超えると実行不可能になるため、評価値がゼロになる。

図５Ｂは、また、車両による運送量を評価対象とする自己評価情報114の例である。ある時間を過ぎると運送のための車両の運行が不可能になるような場合には、評価関数は2値をとる。例えば、計画ID1に対する評価値601は、現在時刻から7分後までは運行可能で輸送量が変らないため一定であるが、7分を超えると運行できなくなるため運送量がゼロになり、評価値がゼロとなる。計画ID2に対する評価値602、計画ID3に対する評価値603も同様である。

上の例では、評価関数E(t)により評価値を線形あるいは2値で変化させたが、非線形に変化させてもよい。あるいは、時間を変数の一つとした、他の任意の評価関数を用いてもよい。あるいは、評価関数E(t)ではなく時間tと評価値Eの対応表の形式でもよい。すなわち、評価関数E(t)の設定はユーザが任意に定めることができる。評価関数E(t)は、単調減少関数であることが多い。

次に、実施例における計画の推定調整時間情報115のデータ構造を説明する。

図６は、実施例における計画の推定調整時間情報115のデータ構造を示した図である。計画の推定調整時間情報は、各代替計画と計画提案先に対し、各提案先から当該時間tに受諾の応答が来る確率として表現され、例えば時間依存関数である受諾応答確率P(t)で表現される。

次に、実施例における計画の推奨度情報116のデータ構造を説明する。

図７は、実施例における計画の推奨度情報116のデータ構造を示した図である。計画の推奨度情報は、各代替計画案に対し、計画を組織間調整にかけるべき推奨度Rとして時間依存関数R(t)で表現される。以上、データ構造について説明した。

＜４.処理の説明＞
次に、処理について述べる。まず、システムの概略の処理から説明する。

図８は、実施例における多主体連携計画システム100の処理フローの概略図である。

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

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

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

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

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

以上の処理は、多主体連携計画システム100がリソース群Aの管理組織下にあるものとして説明している。ただし、先に述べたように、以下で説明する機能を、各リソース群の管理組織で共有することも可能である。その場合には、各計画連携先システム117からの代替運用計画立案作成要求を端末装置110経由で受付けることをトリガに、ステップS805以下の処理を開始すればよい。

ステップS806は、代替計画案生成装置106が，リソース群Aの運用計画案を複数種類作成し、代替計画案情報113としてDBに保存する処理である。ここで運用計画案の作成は、CPソルバやMIPソルバなどをはじめとする汎用数理最適化ツールを用いて行うことができる。

ステップS807は、制御装置105が，計画の自己評価装置103に、自己評価値の演算を指示する処理である。

ステップS808は、計画の自己評価装置103が、データ読込装置104に指示してDBから代替計画案情報113を読み込み、自己評価値Eを演算し、計画の自己評価情報114としてDBに保存する処理である。運用計画案は複数種類あるため、それぞれについて自己評価値Eが保存される。

ステップS809は、制御装置105が，計画の調整時間推定装置107に、調整時間推定値の演算を指示する処理である。

ステップS810は、計画の調整時間推定装置107が、各連携先の調整時間を推定し、推定調整時間情報115としてDBに保存する処理である。調整時間の推定方法は、種々ある。簡単な例では、ユーザが経験的に各連携先から受諾回答が得られる推定時間を予想して図６に示したような推定調整時間データとして記憶しておき、計画の調整時間推定装置107が、提案先の推定調整時間データを参照して調整時間を推定する。

他の例では、機械学習技術を応用してもよい。例えば、DBから過去応答情報111を読み込み、提案先303を問題とし、所要時間306を正解とした教師データでＤＮＮ（Deep Neural Network）等の関数近似器を学習し、計画の調整時間推定装置107とする。

提案先に加え、計画ID302に対応した代替計画案情報113を問題に加えて学習することで、提案する計画案の内容による影響を考慮することができ、推定精度を高めることができる。

また、提案先に加え、連携先業務情報112を問題に加えて学習することで、提案先の特性による影響を考慮することができ、推定精度を高めることができる。例えば、先に述べたように、連携先業務情報112に代替案の連絡があった場合に所定時間以内に返答することを規定している業務マニュアルの情報が含まれる場合、所定時間内が調整時間となる期待値が高まると考えられる。

以上のように、ステップS810は、DBから過去応答情報111や連携先業務情報112を読み込み、各連携先から受諾応答が得られる調整時間を推定し、推定調整時間情報115としてDBに保存する処理である。本実施例では、調整時間の推定は、過去応答情報111と連携先業務情報112から機械学習などの公知技術を用いて行うことにする。

推定調整時間情報115は、代替計画案を提案する全ての連携先について取得する。機械学習において、計画内容も教師データに含めており、応答時間が計画内容に依存する場合には、運用計画案は複数種類あるため、それぞれの運用計画案について推定調整時間情報115が保存される。応答時間が計画内容に依存せず、提案先のみに依存するとした場合には、提案先毎に一つの推定調整時間情報115が得られる。応答時間が計画内容に依存しないとわかっている場合には、入力から計画内容を省略し、簡略化した構造を持つことが可能になる。

ステップS811は、制御装置105が，計画の推奨度演算装置108に、計画の推奨度の演算を指示する処理である。

ステップS812は、計画の推奨度演算装置108が，データ読込装置104に指示してDBから計画の自己評価情報114と推定調整時間情報115とを読み込み、推奨度を演算し、計画の推奨度情報116としてDBに保存する処理である。

図９は、推奨度演算装置108が行う、ステップS812の詳細を示すフロー図である。

ステップS8121で、計画の自己評価情報114（図５Ａ, 図５Ｂ）と推定調整時間情報115（図６）を読み込む。

いま、推定調整時間情報115の受諾応答確率P(t)は、連携先毎のデータとしているので、推奨度演算装置108は推奨度の演算を行う場合、受諾応答確率P(t)から統合受諾応答確率IP(t)を求める。統合受諾応答確率IP(t)は、当該時間帯に全ての提案先から受諾応答が得られる確率である。

ステップS8122で、各連携先の受諾応答確率P(t)から、各時間帯において全ての連携先から受諾応答を受領済みとなる統合受諾応答確率IP(t)を計算する。例えば、具体例としては連携先が２つのとき、
計画ID1について連携先Bから受諾応答を受ける確率P_B(t)
0－1時間：10％
1－2時間：30％
2－3時間：60％
計画ID1について連携先Cから受諾応答を受ける確率P_C(t)
0－1時間：20％
1－2時間：70％
2－3時間：10％
であった場合、計画ID1がすべての連携先から0-1時間の間に受諾応答を受領済みとなる統合受諾応答確率IP(0-1)は、「（計画ID1がBから0-1時間に受諾応答を受ける）かつ（計画ID1がCから0-1時間に受諾応答を受ける）」であるから、簡単のためそれぞれの分布が独立であると仮定すれば、0.1×0.2＝0.02 (2%)となる。

そして、計画ID1がすべての連携先から1-2時間の間に受諾応答を受領済みとなる統合受諾応答確率IP(1-2)は、「（計画ID1がBから1-2時間に受諾応答を受ける）かつ（計画ID1がCから1-2時間に受諾応答を受ける）」または、「（計画ID1がBから0-1時間に受諾応答を受ける）かつ（計画ID1がCから1-2時間に受諾応答を受ける）」または、「（計画ID1がBから1-2時間に受諾応答を受ける）かつ（計画ID1がCから0-1時間に受諾応答を受ける）」である。すなわち、0.1 × 0.7 ＋ 0.2 × 0.3 ＋ 0.3 × 0.7 = 0.34 (34%)となる。

ステップS8123では、統合受諾応答確率IP(t)から、調整成功確率S(t)を計算する。調整成功確率S(t)は、統合受諾応答確率IP(t)の積分値であり、単位時間の中では一定として扱う。例えば、上の例では0-1時間の間は2%で一定となる。瞬間ごとの確率を扱おうとすると、確率0になってしまうため、幅を持って単位時間ごとに表現する必要がある。単位時間の粒度は任意である。

上記の例では、未だすべての連携先から受諾応答を受けていない場合、0＜t≦1の間の調整成功確率S(t)は2%、1＜t≦2の間のS(t)は2＋34＝36%である。以上のように、調整成功確率S(t)は、複数連携先の受諾応答確率P(t)の積和演算で求めることができる。調整成功確率S(t)は、統合受諾応答確率IP(t)の積分値になるので、一般に単調増加関数となる。

ステップS8124で、調整成功確率S(t)と評価値E(t)から推奨度R(t)を計算する。

ここで、時刻に依存する計画ID1の推奨度R(t)は、例えば、各時刻に対し、
（当該時刻における計画ID１の調整成功確率S(t))×(当該時刻における計画ID1の自己評価値E1(t))＋(当該時刻における 計画ID１の調整失敗確率１－S(t))×(当該時刻における計画ID１の代替案の自己評価値E2(t))として算出できる。

ここで、計画ID１の調整失敗時の代替案は、当該時刻における自己評価値が計画ID1に次いで高いものとする。上記の計算は一例であり、時間関数（あるいは時間に依存した値）である調整成功確率と自己評価値を用いている限り、自己評価値や調整成功確率、調整失敗確率に適当な重みづけをしてもよいし、他の関数を用いてもよい。

ステップS813は、制御装置105が、データ読込装置104に指示してDBから計画の推奨度情報116を読み込み、現在時刻で推奨度R(t)の最も高い計画を連携先に提案する計画として、計画連携先応答提供装置101に送信する処理である。ここで、現在時刻で推奨度の最も高い計画を計画ID１の計画とすると、計画ID１の推奨度が最高でなくなる時刻を「推奨期限」として、計画連携先応答提供装置101に送信する。

ステップS814は、制御装置105が過去応答情報111を読み込み、すべての連携先が推奨期限までに提案計画を受諾したかどうかを判定する処理である。すべての連携先が受諾した場合はステップS815へ、しない場合はステップS816へ進む。

ステップS815は、端末装置110のCPU201が，端末装置110の画面に計画案と、計画の自己評価情報を表示する処理である。

ステップS816は、現在時刻を再設定する処理である。ステップS816終了後はステップS807に戻る。

なお、上記の例では、連携先の個別の応答確率を推定し、同時独立性を仮定して同時分布を導出している。別の方法としては連携先の個別の応答確率を想定せず、結果としてすべての連携先から受諾応答を得た時間を過去履歴等から直接モデル化して調整成功確率S(t)を推定してもよい。

また、受諾応答確率の合計は必ずしも100%にならない場合もある。例えば、全ての時間を積分しても受諾応答確率が60%にしかならない提案は、拒絶応答が全体として40%の確率で帰ってくるということを表す。履歴から学習するときには、時間分布だけでなく、この応答確率積分値も同時に学習させることも可能である。

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

＜５.表示画面例＞
図１０は、実施例における結果表示画面の概略を示した図である。

この図において、符号901は結果表示画面、符号902は推奨計画表示部、符号903は自己評価値表示部、符号904は推定調整時間表示部、符号905は推奨度表示部、符号906はスクロールバーである。

推奨計画表示部902は時間とともに変化する推奨度をグラフ化して示し、連携先に提案すべき推奨計画を表示する。例えば、本実施例では、現在時刻から5分後までは計画ID1を連携先に提案する。5分後までにすべての連携先が計画ID1を受諾しない場合には、計画ID1を取り下げ、5分後以降9分まで計画ID2を提案する。

スクロールバー906を動かすことで、スクロールバーの表す時刻における、各計画の自己評価値、推定調整時間、推奨度がそれぞれ自己評価値表示部903、推定調整時間表示部904、推奨度表示部905で表示される。

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

＜６．全体計画作成フロー＞
図１１は、実施例において全体計画を作成するまでの流れを説明したフロー図である。以下のフローでは図１のシステムを利用するものとして説明する。この場合、先に述べたように、多主体連携計画システム100は、１つ以上の他組織管理下のリソース群（本例ではリソース群BおよびC）と連携してサービスを提供するために、自組織管理下のリソース群Aの運用計画を作成する。

処理S1000において、多主体連携計画システム100はリソースAの運用計画を作成する。この処理は、図８において説明した処理である。処理S1000の結果、全ての連携先が受諾する計画案が1つ以上作成されている。この結果は、図８のステップS815のように、多主体連携計画システム100のオペレータに表示される。

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

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

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

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

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

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

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

100…多主体連携計画システム
101…計画連携先応答提供装置
102…ネットワーク
103…計画の自己評価装置
104…データ読込装置
105…制御装置
106…代替計画案生成装置
107…計画の調整時間推定装置
108…計画の推奨度演算装置

Claims (10)

1. １つ以上の他組織管理下のリソース群と連携してサービスを提供するために、自組織管理下のリソース群の割り当て計画を作成する多主体連携計画システムであって、
   前記自組織管理下のリソース群の割り当て計画案を複数生成する計画案生成装置と、
   予め定めて記憶した評価アルゴリズムを用いて前記計画案に対し時刻に依存する評価値を演算する評価装置と、
   前記計画案に対しある時刻において、前記計画案に対しすべての連携先からの受諾応答を受領済みとなる確率であって時刻に依存する調整成功確率を演算し、前記評価値と前記調整成功確率とを変数として用いる推奨度アルゴリズムを用いて、時刻に依存する値である推奨度を演算する推奨度演算装置と、
   を備え、
   前記計画案生成装置、前記評価装置、および前記推奨度演算装置のそれぞれの機能は、情報処理装置の中央処理装置が記憶装置に格納されたプログラムを実行することによって実現される多主体連携計画システム。
2. 前記推奨度に基づいて、連携先に提案する計画案を選択する制御装置を備える、
   請求項１記載の多主体連携計画システム。
3. 前記制御装置は、
   前記推奨度の最も高い計画案を連携先に提案し、提案した前記計画案の推奨度が最高でなくなる時刻を推奨期限として、当該推奨期限が到来した時点で計画案の調整が成功していない場合、前記連携先に提案する計画案を前記時点で前記推奨度の最も高い計画案に変更する、
   請求項２記載の多主体連携計画システム。
4. 前記調整成功確率は、
   前記計画案に対しすべての連携先から所定時間範囲において受諾応答を受領済みとなる統合受諾応答確率に基づいて演算される、
   請求項１記載の多主体連携計画システム。
5. 前記統合受諾応答確率は、連携先毎に所定時間範囲において受諾応答を受領済みとなる受諾応答確率に基づいて演算され、
   前記受諾応答確率は、過去応答情報に基づいて機械学習技術を用いて得たものであり、
   前記過去応答情報は、過去の計画案に対し各連携先から受け取った受諾または拒否の決定と、決定を受け取るまでの時間を含む情報である、
   請求項４記載の多主体連携計画システム。
6. 前記統合受諾応答確率は、さらに前記計画案に依存する、
   請求項５記載の多主体連携計画システム。
7. 前記評価値は時間に対して単調減少関数であり、前記調整成功確率は時間に対して単調増加関数である、
   請求項１記載の多主体連携計画システム。
8. CPUと記憶装置を備える情報処理装置で実行され、１つ以上の他組織管理下のリソース群と連携してサービスを提供するために、自組織管理下のリソース群の割り当て計画を作成する多主体連携計画方法であって、
   前記CPUが、前記自組織管理下のリソース群の割り当て計画案を複数生成して、前記記憶装置に記憶する第１のステップ、
   前記CPUが、予め定めた評価アルゴリズムを用いて複数の前記計画案を評価して時間の関数である自己評価値を生成し、前記記憶装置に記憶する第２のステップ、
   前記CPUが、ある時刻において、複数の前記計画案それぞれに対しすべての連携先から受諾応答を受領済みとなる調整成功確率を得、前記記憶装置に記憶する第３のステップ、
   前記CPUが、前記自己評価値と前記調整成功確率とを変数として用いる推奨度アルゴリズムに基づいて、前記計画案の推奨値を演算し、前記記憶装置に記憶する第４のステップ、
   前記CPUが、前記推奨値に基づいて複数の前記計画案から少なくとも一つを選択し、連携先に提案する第５のステップ、
   を実行する、
   多主体連携計画方法。
9. 前記第５のステップでは、
   複数の前記計画案の前記推奨値の大小関係に基づいて、複数の前記計画案から一つを選択する、
   請求項８記載の多主体連携計画方法。
10. 前記第５のステップでは、
    複数の前記計画案のうち前記推奨値が最大の計画案を選択し、選択した計画案の推奨値が最大でなくなったことを契機に、選択する計画案を変更する、
    請求項９記載の多主体連携計画方法。

Images