特開 2025-163820 合意判定装置、合意判定方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025163820

(43)【公開日】2025-10-30

(54)【発明の名称】合意判定装置、合意判定方法及びプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20251023BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2024067362

(22)【出願日】2024-04-18

(71)【出願人】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100107331

【弁理士】

【氏名又は名称】中村 聡延

(74)【代理人】

【識別番号】100104765

【弁理士】

【氏名又は名称】江上 達夫

(74)【代理人】

【識別番号】100131015

【弁理士】

【氏名又は名称】三輪 浩誉

(72)【発明者】

【氏名】安藤 友人

【テーマコード（参考）】

5L050

【Ｆターム（参考）】

5L050CC11

(57)【要約】

【課題】次回の交渉の負担を好適に低減することが可能な合意判定装置、合意判定方法及びプログラムを提供する。
【解決手段】合意判定装置１Ｘは、主に、候補案取得手段３０Ｘと、候補案通知手段３１Ｘと、合意判定手段３３Ｘと、を有する。候補案取得手段３０Ｘは、交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得する。候補案通知手段３１Ｘは、第１交渉主体の交渉相手となる第２交渉主体に合意候補案を通知する。合意判定手段３３Ｘは、第２交渉主体による合意候補案の部分ごとの合意の有無を判定する。
【選択図】図１１

【特許請求の範囲】

【請求項1】

交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得する候補案取得手段と、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知する候補案通知手段と、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する合意判定手段と、
を有する合意判定装置。

【請求項2】

前記候補案通知手段は、前記第２交渉主体が前記交渉に使用する端末装置に前記合意候補案を表示させる場合に、前記合意候補案の部分ごとの合意を指定する入力を受け付ける、請求項１に記載の合意判定装置。

【請求項3】

前記候補案通知手段は、前記第２交渉主体が前記交渉に使用する端末装置に前記合意候補案を表示させる場合に、前記合意候補案のうち合意があった部分の当該合意の取り消しを受け付ける、請求項１に記載の合意判定装置。

【請求項4】

前記候補案通知手段は、前記第２交渉主体が前記交渉に使用する端末装置に前記合意候補案を表示させる場合に、前記合意候補案のうち合意があった部分の詳細を非表示にする、請求項１に記載の合意判定装置。

【請求項5】

前記候補案通知手段は、前記第２交渉主体が前記交渉に使用する端末装置に前記合意候補案を表示させる場合に、前記合意候補案のうち合意があった部分の詳細を非表示にするか否かの指定を受け付ける、請求項３に記載の合意判定装置。

【請求項6】

前記合意候補案のうち前記合意があった部分以外の非合意部分に関する前記合意候補案の代替案を取得する代替案取得手段をさらに有する、請求項１に記載の合意判定装置。

【請求項7】

前記非合意部分に関する前記代替案を前記第１交渉主体に通知する代替案通知手段をさらに有する、請求項６に記載の合意判定装置。

【請求項8】

前記交渉を中断する場合に、前記合意があった部分と前記合意があった部分以外の非合意部分とを、前記第１交渉主体が前記交渉に使用する端末装置と、前記第２交渉主体が前記交渉に使用する端末装置との少なくともいずれか一方に表示させる交渉結果表示手段をさらに有する、請求項１に記載の合意判定装置。

【請求項9】

コンピュータが、
交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得し、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知し、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する、
合意判定方法。

【請求項10】

交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得し、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知し、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する処理をコンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、合意判定装置、合意判定方法及びプログラムの技術分野に関する。

【背景技術】

【0002】

発注側と受注側との条件調整に関する交渉を自動で行うシステムが知られている。例えば、特許文献１には、想定される発注側からの注文に応じた交渉候補を予め記憶しておき、発注側から受信した交渉条件に対して効用の大きい交渉候補から優先して発注側に送信する自動交渉システムが開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】国際公開ＷＯ２０２１／０２４４１４

【発明の概要】

【発明が解決しようとする課題】

【0004】

一般に、お互いに相手のオファーに一部でも受諾できない点があれば合意されない。そして、交渉で合意されないときには、実質的に交渉前の状態と同じ状態から次の交渉を開始することになる。

【0005】

本開示の目的の一つは、上述した課題を鑑み、次回の交渉の負担を好適に低減することが可能な合意判定装置、合意判定方法及びプログラムを提供することである。

【課題を解決するための手段】

【0006】

合意判定装置の一の態様は、
交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得する候補案取得手段と、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知する候補案通知手段と、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する合意判定手段と、
を有する合意判定装置である。

【0007】

合意判定方法の一の態様は、
コンピュータが、
交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得し、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知し、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する、
合意判定方法である。

【0008】

プログラムの一の態様は、
交渉を行う第１交渉主体が提供する分割可能な合意候補案を取得し、
前記第１交渉主体の交渉相手となる第２交渉主体に前記合意候補案を通知し、
前記第２交渉主体による前記合意候補案の部分ごとの合意の有無を判定する処理をコンピュータに実行させるプログラムである。

【発明の効果】

【0009】

本開示による効果の一例では、次回の交渉の負担を好適に低減することが可能となる。

【図面の簡単な説明】

【0010】

【図1】交渉システムの構成を示す。

【図2】プラットフォーム提供装置のハードウェア構成を示す。

【図3】端末装置のハードウェア構成を示す。

【図4】交渉プラットフォームにおける機能ブロックの一例である。

【図5】交渉主体による入力前のオファー編集画面の一例である。

【図6】交渉主体による入力後のオファー編集画面の一例である。

【図7】折り畳みボタンが選択された後のオファー編集画面の一例である。

【図8】交渉中断ボタンが選択されたときに表示される交渉結果画面を示す。

【図9】プラットフォーム提供装置が実行するフローチャートの一例である。

【図10】交渉システムの構成を示す。

【図11】合意判定装置の機能ブロック図である。

【図12】合意判定装置の処理手順を示すフローチャートの一例である。

【発明を実施するための形態】

【0011】

以下、図面を参照しながら、合意判定装置、合意判定方法及びプログラムの実施形態について説明する。

【0012】

以下の説明において、「交渉」とは、発注と受注（即ち、注文の授受）を行う両者間において合意に至るまでの条件に関する調整を指し、本実施形態では、合意形成が図られるまで、発注と受注を行う両者士が交互に注文に関する条件の合意候補案（「オファー」とも呼ぶ。）を提供し合う行為を主に指す。この場合の交渉は、利害の対立する主体間の交渉であってもよいし、利害の対立しない主体間の交渉（所謂、調整）であってもよい。また、交渉は、注文書を発行する一般的な注文に関する交渉だけでなく、注文書を発行せずに納入予定数量等を調整するものも含む。また、交渉が行われる条件（所謂、ｉｓｓｕｅ）の例には、商品の価格、納期、数量、輸送手段、使用リソース（輸送手段がドローンの場合には空域）、機能、品質などが含まれる。また、「交渉主体」とは、発注及び受注を行う主体であり、例えば、他の交渉主体に提供する合意候補案を生成する能力、及び、他の交渉主体から取得したオファーに合意するか否かを判断する能力を有する主体のことを指す。交渉主体は、個人であってもよく、組織であってもよい。交渉主体は、これらの個人又は組織の意思を反映するＡＩ、ロボット、その他の装置（ドローン及び自動運転自動車などを含む）を用いて交渉してもよい。

【0013】

＜第１実施形態＞
（１）システム構成
図１は、交渉システム１００の構成を示す。交渉システム１００は、主に、条件を交渉する電子的な交渉プラットフォームを提供するプラットフォーム提供装置１と、プラットフォーム提供装置１が提供する交渉プラットフォーム上での交渉を行う交渉主体が使用する端末装置２Ａ及び端末装置２Ｂと、を備える。プラットフォーム提供装置１と、端末装置２Ａと、端末装置２Ｂとは、ネットワーク３を介してデータ通信を行う。図１では、一例として、交渉主体Ａが使用する端末装置２Ａと、交渉主体Ｂが使用する端末装置２Ｂとが図示されており、以後においては、端末装置２Ａと端末装置２Ｂとを特に区別しない場合には、これらを単に「端末装置２」とも呼ぶ。

【0014】

以後では、交渉主体Ａと交渉主体Ｂとの１対１での交渉を例として説明する。なお、以後に説明する１対１での交渉を複数組み合わせて、相見積交渉、総量交渉、入れ子交渉に発展させてもよい。

【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】

オファー送信部３１Ａは、オファー生成・更新部３０Aが生成又は更新したオファーを示す情報をオファー受信部３２Ｂへ供給する。この場合、例えば、プロセッサ１１は、オファー送信部３１Ａとして機能し、オファー生成・更新部３０Ａが生成又は更新したオファーを端末装置２Ｂ上において表示するための表示情報を生成し、インターフェース１３を介し、生成した表示情報を端末装置２Ｂへ送信する。なお、オファー送信部３１Ａは、更新したオファー（即ちカウンターオファー）を示す情報を送信する場合には、合意済みの部分オファーと合意されていない部分オファーとの両方を示す情報を送信してもよく、合意されていない部分オファーを示す情報のみを送信してもよい。合意済みの部分オファーは、「合意候補案のうち合意があった部分」の一例であり、合意されていない部分オファーは、合意候補案における「非合意部分」の一例である。

【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】

１ プラットフォーム提供装置
１Ｘ 合意判定装置
２（２Ａ、２Ｂ） 端末装置
３ ネットワーク
４ 記憶装置
１００、１００Ａ 交渉システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】