契約ネットプロトコル

コントラクトネットプロトコル（CNP）は、1980年にReid G. Smithによって導入されたマルチエージェントシステムにおけるタスク共有プロトコルです。 ^{[1]これは、自律エージェント間でタスクを割り当てるために使用されます。これは}、密封オークションプロトコルに近いものです。これは主に下請け業者に依存しており、マネージャーが複数のエージェントにタスクを提案します。後者は提案を行い、マネージャーはその中からタスクを割り当てることを選択します。このタスクは分割され、下請け業者に委託することができます。

プロトコルの形式化は、言語行為理論を通じて実行できます。このプロトコルでは、各エージェントはマネージャーまたは請負業者のいずれかになります。

1. プロトコルは管理者によって初期化され、管理者は請負業者に提案募集を送信します。
2. 請負業者は、興味がある場合は提案書を、興味がない場合は拒否書を送信できます。この提案書には、管理者が選択を行うために必要なすべての要素が含まれています。
3. マネージャは、提案の中から最も適したものを選択し、該当する請負業者に承認を送信します。他の請負業者には、決定を通知するために拒否を送信します。
4. 契約が完了すると、請負業者は通知メッセージを使用して管理者に通知します。通知すべき結果がある場合、それも通知メッセージを通じて通知されます。請負業者が契約を履行できない場合は、キャンセルメッセージを通じて管理者に通知します。

コントラクト ネット プロトコルは、AUML 形式を使用して表現できます。

このプロトコルは階層型組織を実装するために使用できます。階層型組織では、管理者が請負業者にタスクを割り当て、請負業者はそれをさらに下位レベルのタスクに分解して下位レベルに割り当てます。この種の組織は、エージェントが協力的である場合、つまり目的が同一の場合に使用できます。この状況では、請負業者が提案を行う際に管理者に嘘をつかないようにすることができます。エージェントが競争的である場合、プロトコルはオークションに非常によく似た市場組織になります。^[2]

このプロトコルはFIPAによってACL（エージェント通信言語）に実装されている。 ^[3]

契約ネットプロトコルは、さまざまな問題や状況に対して実装されてきました。元の論文では、センサーネットワークのユースケースについて説明しました。その後の研究では、この状況での有用性が示されました。^[4]また、マルチロボットタスク割り当てにも使用されています。^{[5]また、電子商取引マーケットプレイス[6]}とサプライチェーンの両方の交渉プロトコルとしても使用されています。^[7]

Reid G Smith 氏は、そのプロトコルに関連するいくつかの問題を特定しました。特に、交換されるメッセージに関してネットワーク通信が過負荷にならないように、短いメッセージのみを作成し、提案されたタスクに関連する可能性のあるエージェントとのみ対話することを提案しています。対話の数を制限するために、マネージャーがどの請負業者と契約したいかわかっている場合は、請負業者に直接連絡して、請負業者が受け入れるかどうかのオファーを行うことができます。

2 つ目の問題は、タスクが多数ある場合の請負業者の占有率に関係します。実際、この場合、マネージャーが利用可能な請負業者を見つけるのは複雑になる可能性があります。この問題を解決するために、請負業者は、すでに別の契約で作業している場合でも、提案の呼びかけに応じることができます。このトリックを使用すると、請負業者全員が忙しいためにマネージャーが提案の呼びかけを行っても応答がないという状況を防ぐことができます。この場合、請負業者は、マネージャーからの提案で締結する準備ができた瞬間を提案に追加します。同様に、この状況では、利用可能なすべての請負業者のリストを保持して、マネージャーが最初に連絡できるようにすることができます。このトリックにより、マネージャーがすべてのエージェントに提案の呼びかけを何度も送信することによるネットワークの過負荷を回避しながら、提案されたタスクを契約する請負業者が最終的に見つかるようにすることができます。この情報は、請負業者によってマネージャーに直接送信されます。

著者が提案した拡張以外にも、コントラクト ネット プロトコルを拡張した研究はいくつかある。その研究で提起された問題の 1 つは、管理者が何を最も重視するかを明確にできないということである。管理者は、請負業者から受け取った提案の中から選択する必要がある。各請負業者がさまざまな提案を行える場合、最適ではないソリューションにつながる可能性がある。この問題に対処するために、FIPA は、管理者が、回答した請負業者の一部に対して新しい提案募集を行い、他の提案を拒否し、最終的にそのうちの 1 つを受け入れることができる、プロトコルの反復バージョンも提案している。結果として得られるプロトコルは、反復オークション プロトコルと比較できる。CNP と同様に、このプロトコルは AUML 図^{[8]として表すことができる。}

プロトコルのもう 1 つの問題は、実際にタスクを処理することです。元のプロトコルでは、提案を行う請負業者は、提案したタスクをどんな手段を使ってでも達成することを約束します。タスクの失敗は、タスクが対処されないことを管理者に通知するキャンセルメッセージを通じてのみ考慮され、請負業者に対する制裁はありません。エージェントが利己的である場合、エージェントは、できるだけ多くの提案を行い、最も利益のある提案のみを実行するインセンティブを持つ可能性があります。コラボレーションのコンテキストでは、エージェントは、別のタスクにコミットするためにタスクからオプトアウトすることがシステム全体にとって良いことかどうかを知る方法がありません。これらの要素を考慮に入れ、請負業者がタスクを達成できない場合に支払うコミットメント コストを事前に定義するために、プロトコルの拡張が 1995 年に Tuomas Sandholm とVictor Lesserによってリリースされました。^[9]

• マルチエージェントシステム
• インテリジェントエージェント
• エージェントベースモデル