JP7392725B2 - 交渉システム、交渉方法および交渉プログラム - Google Patents

Description

本発明は、発注側と受注側との条件調整交渉を自動で行う交渉システム、交渉方法および交渉プログラムに関する。

近年、国際自動交渉エージェント競技会（ＡＮＡＣ：Automated Negotiating Agents Competition）という国際コンペティションが権威のある国際学会で開催されており、自動交渉エージェント技術の期待が、より高まっている。自動交渉エージェントは、人間が行う交渉を自動化し、合意条件案の生成や受諾または拒否の判断をＡＩ（Artificial Intelligence ）によって行う技術であり、これを実現する各種方法が提案されている。

特許文献１には、他のシステムと自動交渉を行う自動交渉システムが記載されている。特許文献１に記載された自動交渉システムは、基準からの需要者の需要量の変化に対する供給事業者の損益の変化を表す需要効用関数と、基準からの総需要量の変化に対する供給事業者の損益の変化を表す供給効用関数との合算結果から、需要家との自動交渉において、目標とする候補を定める。

また、特許文献２には、インターネット等を介して見積要求を受け付け、自動応答する見積回答方法が記載されている。特許文献２に記載された方法では、価格見積の基礎となる見積用ＤＢ（データベース）と、見積要求された製品開発の時期に応じて設定内容を変更できる補正用ＤＢを保持し、ユーザにより商談概要や要求仕様が送信されると、見積が作成され、作成された見積もりに対して価格および納期が補正される。

国際公開第２０１８／０７０４１９号 特開２００８－０１５８９２号公報

一方、発注側と受注側との間で、納期や数量、価格などの条件を調整する交渉を行う際、受注側は、自身の生産能力や生産計画などの情報をもとに、発注側の提示する条件が受け入れ可能か判断する必要がある。

交渉を行う際、受注側は、より価値の高い注文を受注できることを期待する。すなわち、受注側は、既存の注文の価値と新規の注文の価値とを比較し、より価値の高い注文が受注されるように発注側と交渉できる自動交渉エージェントを求めている。特許文献１～特許文献２には、より価値の高い注文を受注できる機会を受注側に提供する技術が記載されていない。

そこで、本発明は、より価値の高い注文を受注できる機会を受注側に提供できる交渉システム、交渉方法および交渉プログラムを提供することを目的とする。

本発明による交渉システムは、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定部と、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する計画立案部と、受注計画に基づく効用を算出する効用算出部とを備え、計画立案部は、変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成し、生成した各実行条件に対する複数の受注計画を立案することを特徴とする。

本発明による交渉方法は、交渉システムで実行される交渉方法であって、交渉システムが、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定し、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案し、受注計画に基づく効用を算出し、変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成し、生成した各実行条件に対する複数の受注計画を立案することを特徴とする。

本発明による交渉プログラムは、コンピュータに、任意の商品または役務を提供する受注側に任意の商品または役務の提供の依頼を表す発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定処理、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する立案処理、および受注計画に基づく効用を算出する算出処理を実行させるための交渉プログラムであって、立案処理で、変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成させ、生成した各実行条件に対する複数の受注計画を立案させることを特徴とする。

本発明によれば、より価値の高い注文を受注できる機会を受注側に提供できる。

本発明による交渉システムの一実施形態の構成例を示すブロック図である。 パラメータファイルの例を示す説明図である。 BOM/BOP の例を示す説明図である。 段取替時間の例を示す説明図である。 交渉候補の表示例を示す説明図である。 交渉条件を入力する画面の例を示す説明図である。 自動交渉システムの動作例を示すフローチャートである。 本発明による交渉システムの概要を示すブロック図である。

以下、本発明の実施形態を図面を参照して説明する。

図１は、本発明による交渉システムの一実施形態の構成例を示すブロック図である。図１に例示する自動交渉システム１０は、発注側交渉システム１００と、受注側交渉システム２００とを備えている。

発注側交渉システム１００は、任意の商品または役務の提供の依頼を表す注文を提示する主体側（以下、単に発注側と記す。）が任意の商品または役務を提供する主体側（以下、単に受注側と記す）に対して、発注を行う条件を交渉するためのシステムである。一方、受注側交渉システム２００は、発注側から提示される交渉条件に基づいて、受注するための条件等を考慮して交渉候補を提示するシステムである。本実施形態の受注側交渉システム２００は、受注側で交渉候補（交渉解候補）をバッチ処理で作成し、交渉時には作成された交渉候補をもとに発注側との交渉を行う。

また、本実施形態の受注側交渉システム２００は、相対的に価値の低い注文に対する優先度を下げることによって、相対的に価値の高い注文を受注する機会を受注側に提供する。

受注側交渉システム２００は、交渉条件受信部２１０と、交渉候補作成部２２０と、交渉候補記憶部２３０と、交渉候補送信部２４０と、交渉候補管理部２５０とを含む。

交渉条件受信部２１０は、発注側交渉システム１００から、発注側の交渉条件を受信する。本実施形態では、発注側の交渉条件を受信することが、発注側から注文を受けることに相当する。交渉条件には、納期や費用など発注側の要望が含まれる。

交渉候補作成部２２０は、発注側からの注文に対する受注側の交渉候補を作成し、後述する交渉候補記憶部２３０に記憶させる。なお、発注側からの注文とは、発注側の要求を表わす条件の集合ということができる。交渉候補作成部２２０は、計画立案部２２１と、効用算出部２２２と、交渉候補登録部２２３と、判定部２２４とを有する。

計画立案部２２１は、発注側からの注文に応じた実行条件に対する受注計画を立案する。発注側からの注文は、受注側が要求される実行条件に対応する。

そして、計画立案部２２１は、注文に基づいて、以下の方法に基づき実行条件を複数生成し、生成された実行条件に対する受注計画をそれぞれ立案する。計画立案部２２１は、例えば、要求される条件ごとの区間をパラメータファイルに設定しておき、その区間内の値を予め定めた間隔で変動させて複数の実行条件を作成し、作成した各実行条件に対する受注計画を立案してもよい。設定される条件として、納期や数量、価格などが挙げられる。

例えば、納期条件を緩和（納期延長）した候補の数をＬ、数量条件を緩和した（数量削減）した候補の数をＭ、価格条件を緩和（価格増額）した候補の数をＮとした場合、計画立案部２２１は、Ｌ×Ｍ×Ｎ個の組み合わせによる実行条件を生成してもよい。

図２は、パラメータファイルの例を示す説明図である。図２に例示するパラメータファイルでは、変動（摂動）させるパラメータの初期値や間隔を定義していることを示す。例えば、数量の条件（PERTURB_DELTA_QUANTITY）の開始と終了が、それぞれ「－５０」、「５０」に設定され、変動させる間隔が５であることを示す。

実行条件を生成する第一の方法として、ビームサーチを利用する方法が挙げられる。ビームサーチでは、条件を意味する軸の値を、一度のサーチで一つのみ変動させる。変動させ得る軸や、変動させる値の最大幅、変動させる値の刻み幅は、軸（条件）の内容に応じて予め定めておけばよい。

実行条件を生成する第二の方法として、グリッドサーチを利用する方法が挙げられる。グリッドサーチは、想定し得るパラメータ（軸）のすべての組み合わせを試行し、最も評価の高いパラメータの組を探索する方法である。パラメータの変動方法は、上述するビームサーチと同様であってもよく、複数の軸の値を同時に変動させてもよい。

実行条件を生成する第三の方法として、ビームサーチとグリッドサーチを組み合わせる方法が挙げられる。この場合、まず、変動させる軸以外の軸の値を固定し、一軸のみ変動させて探索を行う（ビームサーチに相当）。その後、最大または最小の点を探索し、その後、刻み幅を徐々に小さくする。この方法を用いた場合、処理が途中で中断されたとしても、一定の精度の実行条件を生成することが可能になる。

実行条件を生成する第四の方法として、過去に生成された実行条件のうち、まだ試行が行われていない候補を確率的に探索する方法が挙げられる。この方法は、焼きなまし法（Simulated Annealing ）や、遺伝的アルゴリズム（genetic algorithm ）に類似する方法と言える。

実行条件を生成する第五の方法として、過去の実行条件の履歴から分布の偏りを推定し、その偏りに応じた詳細な候補を生成する方法が挙げられる。この方法は、ベイズ最適化における獲得関数に類似する方法と言える。

なお、計画立案部２２１が、実行条件に対する受注計画を立案する方法は任意である。計画立案部２２１は、例えば、混合整数計画問題（ＭＩＰ：Mixed Integer Programming ）により、最適な生産スケジュールを作成することにより受注計画を立案してもよい。

また、計画立案部２２１は、シミュレータ上の生産モデル（例えば、工場モデル）を外部のスクリプトを用いて操作することにより、最適な受注計画を立案してもよい。例えば、遺伝的アルゴリズムによる最適化を行う場合、計画立案部２２１は、目的関数の係数および制約条件を設定したうえで、最適化モジュールを呼び出してもよい。また、例えば、ベイズ最適化を行う場合、計画立案部２２１は、同様に、目的関数の係数および制約条件を設定したうえで、評価値取得のためのシミュレーション実行処理を呼び出してもよい。

受注計画を立案する際、計画立案部２２１は、現時点で受注可能なリソースの範囲で受注計画を立案してもよく、後述するように既に受注した注文（既存の注文）の変更を含めた受注計画を立案してもよい。

また、計画立案部２２１は、１つの注文を複数に分割して受注計画を立案してもよい。
例えば、計画立案部２２１は、１つの注文を数量の観点で分割して受注計画を立案してもよい。

また、計画立案部２２１は、製品を製造するための部品構成情報（BOM(Bill of Materials)/BOP(Bill of Process) とも呼ばれる。）を有し、部品構成情報を用いて部品構成に関する計画を受注計画と同時に立案してもよい。部品構成に関する計画は、例えば部品の製造計画、または部品の購入計画である。

図３は、BOM/BOP の例を示す説明図である。図３は、製品Ａの製造がSMT 工程とTester工程とPacking 工程とで構成されていることを示す。また、図３は、SMT 工程がmacSMT1 マシン、macSMT2 マシン、またはmacSMT3 マシンのいずれかで実行可能であることを示す。

また、図３では、macSMT1 マシンでのSMT 工程の実行に掛かる時間が147 秒、macSMT2 マシンでのSMT 工程の実行に掛かる時間が200 秒、macSMT3 マシンでのSMT 工程の実行に掛かる時間が221 秒であることが定義されている。

また、計画立案部２２１は、同一ライン上で作業対象の製品の切り替えに掛かる時間である段取替時間を考慮し、段取替時間の合計時間が最小になるように受注計画を立案してもよい。段取替時間は、例えば関数ｆを用いてｆ（同一ラインの前の作業，同一ラインの次の作業）のように定義される。

図４は、段取替時間の例を示す説明図である。図４は、例えばmacSMT1 マシンでの作業対象の製品が製品Ｂから製品Ａに切り替えられる際、すなわち製品Ｂから製品Ａへの段取替に2100秒掛かることを示す。

なお、段取替の実行には、人員等のリソースが求められる。また、段取替を同時に実行可能な製造装置はＮ台（Ｎは２以上の自然数）までのような制約が存在する場合もある。

よって、計画立案部２２１は、段取替に使用されるリソースが上限値を超えないように段取替時間を計算してもよい。例えば、段取替を同時に実行する製造装置がＮ台を超える場合、計画立案部２２１は、Ｎ台を超える分の製造装置が他の製造装置による段取替が完了してから段取替を実行するとして、段取替時間を計算してもよい。

また、各人員が実行可能な段取替は、各人員が有するスキルに応じて限定される。例えば、作業員Ｐ１は、製品Ｂから製品Ａへの段取替を実行できるが、製品Ｂから製品Ｘへの段取替を実行できない。また、作業員Ｐ２は、製品Ｂから製品Ｘへの段取替を実行できるが、製品Ｂから製品Ａへの段取替を実行できない。

よって、計画立案部２２１は、各人員が有するスキルの定義に基づいて、段取替時間を計算してもよい。

効用算出部２２２は、受注計画に基づく効用を算出する。具体的には、効用算出部２２２は、受注計画に対する受注側の好ましさの程度を算出する効用関数を用いて効用を算出する。効用関数は、例えば、以下に例示する式１で表される。

式１において、ｐ_ｉは、案件ｉの価格（売価）であり、価格が高いほど効用は増加する。また、λ∈Ｒ^＋は、ハイパーパラメータであり、ｘ_ｉは、案件ｉの罰金、ｌ_ｉは、案件ｉの生産完了時刻、ｄ_ｉは、案件ｉの納期を示す。すなわち、ｌ_ｉ－ｄ_ｉは、納期違反時間を示す。これは、納期を過ぎるほど、効用が低下することを示す。また、ｃ_ｉは、案件ｉの商品１個あたりの直接材料費、ｖ_ｉは、案件ｉの数量を示し、この値が増加するほど生産コストがかかるため、効用は低下する。

また、ｍ_ｊは、マシンｊの１秒あたりの稼働コスト、ｔ_ｊは、マシンｊの総稼働時間（秒）を示し、この値が増加するほど、稼働に要するコストが増加することから、効用は低下する。κは、ユーザによって指定される重みであり、φは、バッファの１秒あたり商品１個あたり滞留コスト、ｂ_ｋは、バッファｋの１秒あたりの平均商品滞留数を示す。これは、滞留させる商品が多いほどコストがかかるため、この値が大きいほど、効用は低下する。

また、θは、バッファの最大滞留量１個あたり滞留コスト、ｈ_ｋは、バッファｋの最大滞留量を示し、この値が増加するほど、バッファにおけるコストがかかることから、効用は低下する。また、ρは、マシン空き時間１秒あたりコスト、ｇ_ｊは、マシンｊの空き時間（秒）を示し、この値が増加するほどマシンが稼働していないことによるロスが発生するため、効用は低下する。また、η_ｊは、マシンｊの１日あたり立ち上げコスト、ｓ_ｊは、マシンｊの利用日数を示し、この値が増加するほど、マシンの利用に必要なコストが増加することから、効用は低下する。

なお、上述する式１は、効用関数の一例であり、受注計画に対する受注側の好ましさを評価可能な関数であれば、その内容は任意である。例えば、上述する式１に含まれる各項のうち、考慮すべき項のみを選択した効用関数が用いられてもよい。

交渉候補登録部２２３は、発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する。また、交渉候補登録部２２３は、作成された交渉候補を、その受注計画に基づき算出された効用に対応付けて交渉候補記憶部２３０に登録する。この実行条件は、発注側との交渉で提示する候補であるため、交渉候補ということができる。これにより、実行条件と効用とが対応付けられるため、実行条件間の効用の比較が容易になる。

判定部２２４は、既存の注文の再計画が可能か否かを判定する機能を有する。具体的には、判定部２２４は、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する。

例えば、判定部２２４は、新規の注文を受けた時に、既存の注文に応じた実行条件が示す納期を延長可能であるか否かを判定する。具体例として、判定部２２４は、既存の注文に応じた実行条件が示す納期が、発注側が指定した納期よりも前に設定されているか否かを判定する。

受注側が自主的に早めに設定した等の理由により、既存の注文に応じた実行条件が示す納期が、発注側が指定した納期よりも前に設定されている場合、判定部２２４は、実行条件が示す納期を延長可能であると判定する。

また、判定部２２４は、新規の注文を受けた時に、既存の注文に応じた実行条件が示す注文数量を削減可能であるか否かを判定する。具体例として、判定部２２４は、既存の注文に応じた実行条件が示す注文数量が、発注側が指定した注文数量よりも多く設定されているか否かを判定する。

受注側が自主的に多めに設定した等の理由により、既存の注文に応じた実行条件が示す注文数量が、発注側が指定した注文数量よりも多く設定されている場合、判定部２２４は、実行条件が示す注文数量を削減可能であると判定する。

また、受注側が、既存の注文に応じた実行条件が変更された場合にペナルティを負う契約を発注側としている場合、判定部２２４は、より多くの実行条件が変更可能であると判定する。ペナルティの設定例として、商品の納入が発注側が指定した納期から１日遅れた場合、価格の１％を受注側が発注側に支払うという設定が考えられる。

受注側がペナルティを負う契約を発注側としている場合、判定部２２４は、既存の注文に応じた実行条件が示す納期が、発注側が指定した納期通りに設定されている場合であっても、実行条件が示す納期を延長可能であると判定する。

また、既存の注文に応じた実行条件が示す注文数量が、発注側が指定した注文数量通りに設定されている場合であっても、判定部２２４は、実行条件が示す注文数量を削減可能であると判定する。

また、判定部２２４は、既存の注文自体のキャンセルも選択肢に含める。すなわち、判定部２２４は、既存の注文に応じた実行条件を削除可能であるか否かも判定する。

以下、新規の注文である製品Ｘの注文を受け、判定部２２４が既存の注文のうち製品Ａ、Ｂ、Ｃの注文の各実行条件が変更可能であると判定した場合を例に考える。

製品Ａ、Ｂ、Ｃの注文の各実行条件が変更可能であると判定された場合、計画立案部２２１は、製品Ａ、Ｂ、Ｃの注文を操作変数として扱い、製品Ａ、Ｂ、Ｃの注文において予定されていたリソースも含めて、製品Ｘの注文を受けた場合の受注計画を再度立案する。

計画立案部２２１は、製品Ａ、Ｂ、Ｃの注文の各実行条件を変化させた場合の受注計画をそれぞれ立案する。すなわち、計画立案部２２１は、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する。

次いで、効用算出部２２２は、再度立案された受注計画に基づく効用を算出する。次いで、交渉候補登録部２２３は、再度立案された受注計画の前提とする実行条件を交渉候補として、その受注計画に基づき算出された効用に対応付けて交渉候補記憶部２３０に登録する。

なお、上述した受注側がペナルティを負う契約を発注側としている場合において、効用算出部２２２は、再度立案された受注計画に基づく効用と実行条件の変更に伴うペナルティに対応する効用とを統合することによって、受注計画全体の効用を算出する。

既存の注文の実行条件よりも新規の注文の実行条件の方が受注側にとって好条件である場合、計画立案部２２１は、効用がより高い受注計画を立案できる。すなわち、受注側交渉システム２００は、受注側にとってより好ましい注文を受注側に失注させずに済む。

また、立案された受注計画に既存注文を含む各注文が変更可能か否かを意味する変更フラグが記録可能である場合、判定部２２４は、変更フラグが設定されている既存の注文に応じた実行条件が変更可能であると判定してもよい。また、判定部２２４は、変更の承諾を発注側から得られた既存の注文に応じた実行条件が変更可能であると判定してもよい。

交渉候補記憶部２３０は、複数の交渉候補（すなわち、実行条件と効用との組み合わせ）を記憶する。交渉候補記憶部２３０は、例えば、磁気ディスクにより実現される。

交渉候補送信部２４０は、受信した交渉条件（注文）に対し、交渉候補記憶部２３０に記憶された対応する交渉候補を発注側に送信する。例えば、交渉条件に一致する実行条件に基づく交渉候補が交渉候補記憶部２３０に記憶されている場合、交渉候補送信部２４０は、その交渉候補のうち、効用の最も大きい交渉候補を発注側に送信してもよい。また、例えば、交渉条件に一致する実行条件に基づく交渉候補が交渉候補記憶部２３０に記憶されていない場合、交渉候補送信部２４０は、一致する交渉条件が多い実行条件に基づく交渉候補のうち、効用の大きい受注計画の交渉候補から優先して発注側に送信してもよい。

交渉候補管理部２５０は、交渉候補記憶部２３０に記憶された交渉候補を管理する。交渉候補管理部２５０は、交渉候補表示部２５１と、交渉候補更新部２５２とを有する。

交渉候補表示部２５１は、交渉候補記憶部２３０に記憶された交渉候補を表示する。交渉候補表示部２５１は、例えば、指定された条件に該当する交渉候補に限定して表示してもよい。図５は、交渉候補の表示例を示す説明図である。図５に示す例では、交渉候補表示部２５１が、製品名が「Ｘ」である製品についての交渉候補として、納期、数量、売価（円）、効用値および利益（円）を対応付けた一覧を表示していることを示す。

さらに、交渉候補表示部２５１は、交渉候補を実現するための対応する受注計画の詳細を表示してもよい。交渉候補表示部２５１は、例えば、図５に例示するように、交渉候補ごとに受注計画を示すグラフ（例えば、製造ライン稼働計画ガントチャートなど）を表示する画面への遷移指示を行うボタンＢ１を設け、より詳細な情報を表示してもよい。

交渉候補更新部２５２は、交渉候補記憶部２３０に記憶された交渉候補の内容を更新する。交渉候補更新部２５２は、例えば、ユーザの指示に基づいて、不適切と判断される交渉候補を削除してもよい。

交渉条件受信部２１０と、交渉候補作成部２２０（より詳しくは、計画立案部２２１と、効用算出部２２２と、交渉候補登録部２２３と、判定部２２４）と、交渉候補送信部２４０と、交渉候補管理部２５０（より詳しくは、交渉候補表示部２５１と、交渉候補更新部２５２）は、プログラム（交渉プログラム）に従って動作するコンピュータのプロセッサ（例えば、ＣＰＵ（Central Processing Unit ）、ＧＰＵ（Graphics Processing Unit））によって実現される。

例えば、プログラムは、受注側交渉システム２００が備える記憶部（図示せず）に記憶され、プロセッサは、そのプログラムを読み込み、プログラムに従って、交渉条件受信部２１０、交渉候補作成部２２０（より詳しくは、計画立案部２２１と、効用算出部２２２と、交渉候補登録部２２３と、判定部２２４）、交渉候補送信部２４０および交渉候補管理部２５０（より詳しくは、交渉候補表示部２５１と、交渉候補更新部２５２）として動作してもよい。また、受注側交渉システム２００の機能がＳａａＳ（Software as a Service ）形式で提供されてもよい。

交渉条件受信部２１０と、交渉候補作成部２２０（より詳しくは、計画立案部２２１と、効用算出部２２２と、交渉候補登録部２２３と、判定部２２４）と、交渉候補送信部２４０と、交渉候補管理部２５０（より詳しくは、交渉候補表示部２５１と、交渉候補更新部２５２）とは、それぞれが専用のハードウェアで実現されていてもよい。また、各装置の各構成要素の一部又は全部は、汎用または専用の回路（circuitry ）、プロセッサ等やこれらの組合せによって実現されもよい。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組合せによって実現されてもよい。

また、受注側交渉システム２００の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

発注側交渉システム１００は、交渉条件入力部１１０と、交渉条件送信部１２０と、交渉候補受信部１３０と、結果表示部１４０とを含む。

交渉条件入力部１１０は、発注側の各種交渉条件の入力を受け付ける。図６は、交渉条件を入力する画面の例を示す説明図である。図６に示す例では、相手（受注側）に開示する交渉条件と、相手に開示しない交渉条件とを入力する画面を示す。相手に開示しない交渉条件は、例えば、受注側から提示された交渉候補に対して、合意するか否かの判断を自動で行う場合などに利用される。

交渉条件送信部１２０は、入力された交渉条件を受注側交渉システム２００に送信する。交渉条件送信部１２０は、例えば、図６に例示する交渉条件のうち、相手側に開示する交渉条件に限定して送信してもよい。

交渉候補受信部１３０は、受注側交渉システム２００から、送信した交渉条件に対する交渉候補を受信する。交渉候補受信部１３０は、交渉候補が予め定めた基準を満たしているか否か判断し、その基準を満たしている場合に、自動的に合意の旨を受注側交渉システム２００に送信してもよい。例えば、図６に例示する交渉条件の即決価格を交渉候補として受信した場合、交渉候補受信部１３０は、合意である旨を受注側交渉システム２００に送信してもよい。

なお、合意か否かを判断する条件は、図６に例示する価格に限定されない。例えば、発注側でも発注側の好ましさの程度を算出する効用関数を予め定めておき、交渉候補受信部１３０は、その効用関数に基づいて算出した効用が予め定めた閾値を上回っている場合に、合意であると判断してもよい。

結果表示部１４０は、受信した交渉候補の内容を表示する。また、自動で交渉を行っている場合、結果表示部１４０は、成立した交渉の内容を表示してもよい。

次に、本実施形態の交渉システムの動作を説明する。図７は、本実施形態の自動交渉システム１０（受注側交渉システム２００）の動作例を示すフローチャートである。

まず、受注側交渉システム２００の計画立案部２２１は、発注側からの注文に応じた実行条件に対する受注計画を立案する（ステップＳ１１）。効用算出部２２２は、立案した受注計画に基づく効用を算出する（ステップＳ１２）。交渉候補登録部２２３は、受注計画の前提とする実行条件を交渉候補として、その受注計画に基づき算出された効用に対応付けて交渉候補記憶部２３０に登録する（ステップＳ１３）。

その後、発注側交渉システム１００の交渉条件入力部１１０に入力された交渉条件が交渉条件送信部１２０により送信され、交渉条件受信部２１０が、発注側（発注側交渉システム１００）からの新規の交渉条件を受信する（ステップＳ１４）。

次いで、判定部２２４は、既存の注文の再計画が可能か否かを判定する（ステップＳ１５）。次いで、計画立案部２２１は、再計画可能であると判定された注文の各実行条件を変更させた上で、発注側からの注文に応じた実行条件に対する受注計画を再度立案する（ステップＳ１６）。次いで、効用算出部２２２は、再度立案した受注計画に基づく効用を算出する（ステップＳ１７）。

交渉候補登録部２２３は、再度立案した受注計画の前提とする実行条件を交渉候補として、その受注計画に基づき算出された効用に対応付けて交渉候補記憶部２３０に登録する（ステップＳ１８）。

交渉候補送信部２４０は、受信した交渉条件に対し、交渉候補記憶部２３０に記憶された交渉候補のうち、効用の大きい交渉候補から優先して発注側に送信する（ステップＳ１９）。そして、発注側交渉システム１００の交渉候補受信部１３０が、送信された交渉候補を受信する。

以上のように、本実施形態では、計画立案部２２１が、発注側からの注文に応じた実行条件に対する受注計画を立案し、効用算出部２２２が、受注計画に基づく効用を算出し、交渉候補登録部２２３が、受注計画の前提とする実行条件を交渉候補として、その受注計画に基づき算出された効用に対応付けて交渉候補記憶部２３０に登録する。そして、交渉候補送信部２４０は、受信した交渉条件に対し、交渉候補記憶部２３０に記憶された交渉候補のうち、効用の大きい交渉候補から優先して発注側に送信する。

また、判定部２２４は、新規の注文を受けた時に、既存の注文の再計画が可能か否かを判定する。計画立案部２２１は、再計画可能であると判定された注文の各実行条件を変更させた上で受注計画を再度立案する。受注計画を再度立案することによって、計画立案部２２１は、相対的に価値の低い注文に対して割り当てられていたリソースを価値の高い注文に割り当て直すことができる。すなわち、本実施形態の受注側交渉システム２００は、使用可能なリソースが限られている場合であっても、より価値の高い注文を受注できる機会を受注側に提供できる。

次に、本発明の概要を説明する。図８は、本発明による交渉システムの概要を示すブロック図である。本発明による交渉システム２０（例えば、受注側交渉システム２００）は、任意の商品または役務を提供する受注側に任意の商品または役務の提供の依頼を表す注文を提示する発注側と交渉する交渉システムであって、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定部２１（例えば、判定部２２４）と、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する計画立案部２２（例えば、計画立案部２２１）と、受注計画に基づく効用を算出する効用算出部２３（例えば、効用算出部２２２）とを備える。

そのような構成により、交渉システムは、より価値の高い注文を受注できる機会を受注側に提供できる。

また、交渉システム２０は、発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する交渉候補作成部（例えば、交渉候補作成部２２０）と、注文に対して、効用の大きい受注計画の交渉候補から優先して発注側に送信する交渉候補送信部（例えば、交渉候補送信部２４０）とを備えてもよい。

そのような構成により、交渉システムは、より価値の高い注文を受注できる機会を受注側に提供できる。

また、判定部２１は、既存の注文に応じた実行条件が示す納期を延長可能であるか否かを判定してもよい。また、判定部２１は、既存の注文に応じた実行条件が示す注文数量を削減可能であるか否かを判定してもよい。実行条件には、納期、数量および価格を含んでいてもよい。また、判定部２１は、既存の注文に応じた実行条件を削除可能であるか否かを判定してもよい。

また、判定部２１は、変更フラグが設定されている既存の注文に応じた実行条件を変更可能であると判定してもよい。また、判定部２１は、変更の承諾を発注側から得られた既存の注文に応じた実行条件を変更可能であると判定してもよい。

そのような構成により、交渉システムは、変更可能な既存の注文を変更できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）任意の商品または役務を提供する受注側に任意の商品または役務の提供の依頼を表す注文を提示する発注側と交渉する交渉システムであって、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定部と、発注側からの新規の注文に応じた実行条件および既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する計画立案部と、受注計画に基づく効用を算出する効用算出部とを備えることを特徴とする交渉システム。

（付記２）発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する交渉候補作成部と、前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する交渉候補送信部とを備える付記１記載の交渉システム。

（付記３）判定部は、既存の注文に応じた実行条件が示す納期を延長可能であるか否かを判定する付記１または付記２記載の交渉システム。

（付記４）判定部は、既存の注文に応じた実行条件が示す注文数量を削減可能であるか否かを判定する付記１から付記３のうちのいずれか１つに記載の交渉システム。

（付記５）判定部は、既存の注文に応じた実行条件を削除可能であるか否かを判定する付記１から付記４のうちのいずれか１つに記載の交渉システム。

（付記６）判定部は、変更フラグが設定されている既存の注文に応じた実行条件を変更可能であると判定する付記１から付記５のうちのいずれか１つに記載の交渉システム。

（付記７）判定部は、変更の承諾を発注側から得られた既存の注文に応じた実行条件を変更可能であると判定する付記１から付記５のうちのいずれか１つに記載の交渉システム。

（付記８）計画立案部は、注文に基づいて実行条件を複数生成し、生成された実行条件に対する受注計画をそれぞれ立案する付記１から付記７のうちのいずれか１つに記載の交渉システム。

（付記９）計画立案部は、要求される条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成し、生成した各実行条件に対する受注計画を立案する付記１から付記８のうちのいずれか１つに記載の交渉システム。

（付記１０）効用算出部は、受注計画に対する受注側の好ましさの程度を算出する効用関数を用いて効用を算出する付記１から付記９のうちのいずれか１つに記載の交渉システム。

（付記１１）計画立案部は、最適化エンジンによるシミュレータを用いた処理により最適な受注計画を立案する付記１から付記１０のうちのいずれか１つに記載の交渉システム。

（付記１２）実行条件には、納期、数量および価格を含む付記１から付記１１のうちのいずれか１つに記載の交渉システム。

（付記１３）任意の商品または役務を提供する受注側に前記任意の商品または役務の提供の依頼を表す注文を提示する発注側と交渉する交渉システムにおいて実行される交渉方法であって、発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定し、発注側からの新規の注文に応じた実行条件および前記既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案し、前記受注計画に基づく効用を算出することを特徴とする交渉方法。

（付記１４）発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成し、前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する付記１３記載の交渉方法。

（付記１５）コンピュータに、任意の商品または役務を提供する受注側に前記任意の商品または役務の提供の依頼を表す発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定処理、発注側からの新規の注文に応じた実行条件および前記既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する立案処理、および前記受注計画に基づく効用を算出する算出処理を実行させるための交渉プログラム。

（付記１６）コンピュータに、発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する作成処理、および前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する送信処理を実行させる付記１５記載の交渉プログラム。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

産業上の利用の可能性

本発明は、発注側と受注側との間で行われる、納期、数量、または価格等に関する交渉の自動化や半自動化を効率的に行う受発注支援方法または交渉方式に好適に適用される。

１０ 自動交渉システム
２０ 交渉システム
２１、２２４ 判定部
２２、２２１ 計画立案部
２３、２２２ 効用算出部
１００ 発注側交渉システム
１１０ 交渉条件入力部
１２０ 交渉条件送信部
１３０ 交渉候補受信部
１４０ 結果表示部
２００ 受注側交渉システム
２１０ 交渉条件受信部
２２０ 交渉候補作成部
２２３ 交渉候補登録部
２３０ 交渉候補記憶部
２４０ 交渉候補送信部
２５０ 交渉候補管理部
２５１ 交渉候補表示部
２５２ 交渉候補更新部

Claims (10)

1. 発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定部と、
   発注側からの新規の注文に応じた実行条件および前記既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する計画立案部と、
   受注計画に基づく効用を算出する効用算出部とを備え、
   前記計画立案部は、
   変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成し、
   生成した各実行条件に対する複数の受注計画を立案する
   ことを特徴とする交渉システム。
2. 発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する交渉候補登録部と、
   前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する交渉候補送信部とを備える
   請求項１記載の交渉システム。
3. 判定部は、既存の注文に応じた実行条件が示す納期を延長可能であるか否かを判定する
   請求項１または請求項２記載の交渉システム。
4. 判定部は、既存の注文に応じた実行条件が示す注文数量を削減可能であるか否かを判定する
   請求項１から請求項３のうちのいずれか１項に記載の交渉システム。
5. 判定部は、既存の注文に応じた実行条件を削除可能であるか否かを判定する
   請求項１から請求項４のうちのいずれか１項に記載の交渉システム。
6. 判定部は、変更フラグが設定されている既存の注文に応じた実行条件を変更可能であると判定する
   請求項１から請求項５のうちのいずれか１項に記載の交渉システム。
7. 交渉システムで実行される交渉方法であって、
   前記交渉システムが、
   発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定し、
   発注側からの新規の注文に応じた実行条件および前記既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案し、
   受注計画に基づく効用を算出し、
   変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成し、
   生成した各実行条件に対する複数の受注計画を立案する
   ことを特徴とする交渉方法。
8. 交渉システムが、
   発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成し、
   前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する
   請求項７記載の交渉方法。
9. コンピュータに、
   任意の商品または役務を提供する受注側に前記任意の商品または役務の提供の依頼を表す発注側からの既存の注文に応じた実行条件が変更可能であるか否かを判定する判定処理、
   発注側からの新規の注文に応じた実行条件および前記既存の注文に応じた実行条件に対する受注計画を、変更可能であると判定された実行条件を変更させた上で立案する立案処理、および
   受注計画に基づく効用を算出する算出処理を実行させるための交渉プログラムであって、
   前記立案処理で、
   変更可能であると判定された実行条件ごとに区間内の値を予め定めた間隔で変動させて複数の実行条件を生成させ、
   生成した各実行条件に対する複数の受注計画を立案させる
   交渉プログラム。
10. コンピュータに、
    発注側からの注文に関する受注計画の前提とする実行条件を交渉候補として作成する作成処理、および
    前記注文に対して、効用の大きい前記受注計画の交渉候補から優先して発注側に送信する送信処理を実行させる
    請求項９記載の交渉プログラム。

Images