第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

1

エージェント基盤のための通信プロトコル：
Agent Platform Protocol
高橋 健一

鍾 国強

雨宮 聡史

峯 恒憲 雨宮 真人

近年，ネットワークで接続された複数の機器が協調

エージェントシステムでは，エージェントの活動や交渉を行い仕事を達成するシステムを作る枠組みとを促進するための環境（Agent Platform，以降 APして様々なエージェントが提案されている．これらのと記す）（例えば，KODAMA の ACZ [1] [2] や FRM

エージェントシステムでは，エージェントの活動を促の Field [3]，Hive の cell [4] など）が準備されている．

進する環境（AP）が個々に準備されているが，それエージェントは，AP 上で，仕事の達成に必要な情報ら異なる AP 上のエージェントシステムを相互運用すを得るためのコミュニケーションや仕事の達成に必る手段については提供されていなかった．そこで，本要な資源を得るための AP 間の移動を行う．これら

稿では，AP 間のプロトコルとして Agent Platformの AP は，元々各エージェントシステム固有のものProtocol(APP) を提案する．APP を用いることで，として開発されているため，そのような異なる AP

１）サーバを介さない P2P な AP 間通信と２）物理を持つエージェントシステムを相互運用することは的環境を意識する必要しないエージェントコミュニ難しい．エージェントの標準化促進団体 FIPA [5] でケーションを実現できる．

は，Agent Communication Language（以降，FIPAACL）や，Agent Platform などの仕様が定められて1 はじめにいるが，その FIPA ACL では，メッセージの送信側インターネットの普及とともに，ネットワークで接と受信側エージェントの物理的なアドレスを指定す続された複数の機器によって実現された多くの情報シる，受信側エージェントの物理的位置を明確に意識しステムやサービスが提供されてきた．これらのシステた仕様となっている．しかし，これは，次のような弊

ムでは，分散された機器が互いの情報を交換するこ害を引き起こす．

• モバイルエージェントとのコミュニケーションとで協調や交渉を行い問題を解決する必要が出てきており，このようなシステムを作る枠組みとして様々が困難．

なエージェントが提案されている．

エージェントが移動すれば，エージェントが存在するアドレスも変わる．すなわち，受信側エー

Communication Protocol for Agent Platform : AgentPlatform Protocol.
Kenichi TAKAHASHI, Zhong GUOQIANG, Satoshi
AMAMIYA, 九州大学 大学院 システム情報科学府,
Graduate School of Information Science and Electrical Kyushu University.
Tsunenori MINE, Makoto AMAMIYA, 九州大学 大学
院 システム情報科学研究院, Graduate School of Information Science and Electrical Engineering, Kyushu
University.

ジェントの物理アドレスを特定することは難しい．

• エージェントに，予め決定された連携を行わせることが難しい．
例えば，２種類のエージェント，Ping と Pong が存在し，Ping は，適当なタイミングで Pong にメッセージを送り，Pong の存在を確認する仕事を持つとする．このとき，２種類のエージェント30

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17が別々にインストールされ，予めそれぞれのアド2いに利用できるようになる．

レスを特定できない場合，Ping は，Pong の物

以下，２節では APP について述べ，３節で APP理的なアドレスを知ることができないため，送を適用した AP の例として ACZ を紹介する．そして，信先としては，”Pong”とだけしか指定できない．

４節で APP を適用した ACZ を用いて，APP の機能

しかし，これでは，Pong が存在するアドレスがについての検証実験を行った結果について報告する．

指定されていないため，Ping から Pong にメッセージを伝達するには，Pong の物理的位置を検2 Agent Platform Protocol（APP）索する機構が必要となる．

APP は，エージェントの活動をサポートする AP

これらの問題を解決するためには，まず AP 間に間の通信プロトコルであり，図 1 のように位置づけ共通のインタフェースを提供するためのプロトコルをられる．APP は，低レベルの通信プロトコルとして定義しなければならない．そして，そのプロトコルでTCP [8] を持つ．TCP では，信頼性のあるコネクショは，次のことを想定しなければならない．

ン指向型の通信を提供しており，データの欠損や重• AP にエージェントの物理的アドレスを管理さ複，届けられる順序の違いなどを発生しない．

せ，エージェントに物理的な情報を意識させないようにする．

• 複数の種類の AP が存在しても，各 AP が一意にエージェントを識別できなければならない．

• AP によって，エージェントの管理方式が異なる．
• 要求した機能が，要求先 AP では実現されていない可能性がある．

• 一般に公開されていなければならない．
そこで我々は，AP 間でエージェントのコミュニ

図1

ケーションをサポートするためのプロトコルとしてAPP の位置づけ

Agent Platform Protocol（以下，APP）を提案する．
APP では，１３の method と header が定義されたリAPP の主な特徴として次の点が上げられる．

クエスト／リスポンス指向のプロトコルであり，AP• サーバを介さない P2P な AP 間ネットワークのはそれらに従ったメッセージを用いて他の AP と協構築．

調を行う．APP は，次の機能を提供する．

• サーバを介さない Peer to Peer（以降，P2P）なAP 間ネットワーク．

P2P なネットワークでは，各ネットワークの構成要素が置き換え可能なため，耐故障性が高く，一つのAP の故障が AP のネットワーク（以降，AP で構成• エージェントメッセージの送受信機能．

されるネットワークを AP ネットワークと呼ぶ）に与• エージェントメッセージの伝達先の検索機能．

える影響は少ない．また，サーバ／クライアントモデ• エージェントの移動．

ルで構成された AP ネットワークのように，サーバのAP は，APP に従ってメッセージの送信先エージェ役割を担う AP に負荷が集中するという問題はなく，ントを検索し，メッセージの伝達を行うため，エー更に，サーバの役割を担うような特定の AP への接ジェントは，互いの物理的なアドレスを意識せず，コ続は不要で，AP ネットワークの任意な一つの AP へミュニケーションを行うことができる．エージェントの接続で AP ネットワークに加わることができる．

開発者は，AP に APP を実装することで，他で開発• エージェントメッセージの送受信機能の提供．

された異種の AP との通信が行えるようになり，様々エージェントはコミュニケーション手段として，メッな場所で開発された様々な種類のエージェントを，互セージ（以降，APP によって用いられるメッセージ31

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17
表1

APP で準備された method 一覧

分類

method説明

Connect

LINK

AP 間の認証及び通信経路の作成

DeLINKAP 間の通信経路切断

Deliver

MobileReply

GET LINK

要求先の AP が持つ通信経路情報の要求

ALIVE

要求先が活動状態であるか否かの確認

DELIVER3

エージェントメッセージの伝達

LOCATE AGENT

エージェントの検索依頼

GET AGENT LIST

要求先の AP が持つエージェント情報の要求

PUT AGENT LIST

保持しているエージェントの情報を他の AP に通知GET AGENT

エージェントを要求先の AP からローカルな AP に移動させる

PUT AGENT

ローカル AP 上のエージェントを要求先の AP に移動させる

ACCEPT

返答．要求を受理したときに用いる

SUCCESS

返答．要求が成功したときに用いる

FAILURE

返答．要求が失敗したときに用いると区別するために，エージェントメッセージと呼ぶ）

2.1.1 methodを用いた情報交換を行う．

AP は，エージェントのコミュニケーションや移動• エージェントメッセージの伝達先の検索機能の提供．

をサポートする環境を提供する．このため，APP では，１３の method を準備している（表 1）．

AP は，エージェントメッセージの送信先エージェ

Connect，Deliver，Mobile に分類される method

ントのアドレスが分からない場合，エージェントメッは，AP に対して要求を出し，その応答として，APセージの伝達先を探さなければならない．エージェン

は Reply に分類される method を用いる．

Connect サーバを介さないで P2P な AP ネッ

トメッセージの伝達先検索のため，APP では，（１）他の AP に検索を任せる方法と（２）他の AP から情トワークを構成するための method 群．LINK報を集め自分自身で検索を進める方法とを提供する．

によって，AP 間での認証を行い，お互いの存• モバイルエージェントの移動をサポート．

在を知り，相互に信頼性のある通信を可能とすエージェントに，仕事の達成に必要な資源を求める．GET LINK は，要求先の AP が接続している AP の情報を要求する．AP は起動時に，まずAP 間を移動する手段を提供する．

LINK method を使って任意の AP に接続し，AP2.1 AP メッセージネットワークに加わる．次に GET LINK で AP

APP で用いられるメッセージを AP メッセージとネットワークの情報を求める．新たに得た AP呼ぶ．AP メッセージは，method，header，body かネットワークの情報を利用して，複数の LINKら構成され，この順に記述される．ここで，methodを行うことで，特定の AP への依存度を下げる

は，AP メッセージが表す要求，または，応答を表す．

ことができる．DeLINK は，要求元の AP が通header は，method を解釈，処理するのに必要な情信を保証できなくなることを伝える．DeLINK報である．body は，各 method が対象とする任意のを受け取った AP は，接続可能な他の AP とのデータである．

接続が分断されないように GET LINK や LINK

method を使って，ネットワークが分断されない

AP メッセージ = {method, header, body}ように対処した後，DeLINK への応答を行わな

32

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-174

ければならない．ALIVE は，AP が実際に APは，保持しているエージェントの情報を他の APメッセージを受け付けることが可能であるかの確に通知する場合に利用する．

Mobile エージェントの移動を行うための method

認を行う．

Deliver エージェントメッセージを送受信する群．POST AGENT は，要求先の AP にエージェ

ための method 群．DELIVER は，エージェンントを移動させ，GET AGENT は，要求先の AP

トメッセージを伝達する method では，bodyからエージェントを移動させる．

部にエージェントメッセージを指定し，aimAt

Reply Connect，Deliver，Mobile の各 methodheader(表 2 参照) でエージェントメッセージのの 応 答 と し て 用 い ら れ る ．ACCEPT は ，各受信側エージェントを指定する．DELIVER を受method を受理したことを表し，FAILURE は，信した AP は，aimAt header が示すエージェン

要求が失敗したことを，SUCCESS は，要求がトに body 部のエージェントメッセージを伝達す成功したことを表す．

る．受信側エージェントが存在する AP が分から2.1.2 header

ない場合の検索手段として，LOCATE AGENTAPP に お け る header は ，そ の 役 割 に よっと GET AGENT LIST を準備している．LO-て，general-header，body-header，authentication-

CATE AGENT は，他の AP に検索を任せる方header に分けられる（表 2）．general-header は，す法であり（図 2(a)），LOCATE AGENT を受信

べての AP メッセージで必須であり，body-header

した AP は，aimAt で指定されたエージェントがは，body 部を持つ AP メッセージに必要とされる．

存在する AP を探し出し，見つかれば，body 部authentication-header は，AP 間の認証が必要なとをそのアドレス（IP アドレス/Port 番号）としきに用いられる．header は，た SUCCESS を返す．GET AGENT LIST は，header = header-name ”:” value

要求先の AP に，それが持つエージェントの情の形で表される．

報を要求する．これは，様々な AP からエージェ

2.1.3 body

ントの情報を集め，その情報を用いて目的のエー

body は，method で必要とされる任意のデータでジェントが存在する AP を自分で見つける場合にある．例えば，DELIVER の場合，body は，エージェ利用する（図 2(b)）．また，PUT AGENT LISTントメッセージとなる．

3 APP の適用例
我々の研究室で研究・開発しているマルチエージェン
トシステム KODAMA（Kyushu university Open &Distributed Autonomous Multi-Agent）では，APとして ACZ （Agent Communication Zone）を利用する．本節では，まず，ACZ について述べ，次にACZ への APP 適用例を示す．
3.1 ACZACZ は，論理的なエージェント空間を物理的な構造にマッピングする機構であり，エージェント間のコミュニケーションを実現するために必要となる物理的
図2

エージェントの検索方法通信機能を提供する．通常，一つの計算機上に一つの33

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17
表2

general-header

5

header 一覧

header-namevaluemessage-id

stringfromAP-Address

説明
メッセージつけられた固有の ID
メッセージを送信した AP のアドレス(IP-Address/port)
via*AP-Address

メッセージの経路

refer*message-id

メッセージの動機となった message-id

AP-TypestringAP のタイプ

authentication

authentication-typestring

認証方法-headerauthentication-value

string認証キー

authentication-expire

numberauthentication-value の有効期限

body-header

absolute

0 or 1

リンクの重要性

body-size

numberbody 部のサイズ

body-typestringbody 部のデータ形式

aimAt

stringbody 部のデータの対象* は，0 回以上の繰り返しを表す．

ACZ が存在し，分散環境上では複数の ACZ が存在

リモート層は，他の ACZ 上で活動するエージェンする．これらの ACZ は，ネットワークを構成し，分トのアドレスを記したテーブル RAT（Remote Agent

散した計算機の間での通信を制御する．この管理のたaddress Table）と，他の ACZ の認可情報を記した

めに ACZ は，ローカル層とリモート層より構成されテーブル LT （Link Table）を持ち，他の ACZ 上でる（図 3）．

活動するエージェントへエージェントメッセージを伝達する際に利用される．

3.2 ACZ への APP の適用
ACZ のライフサイクルは，図 4 のように示される．

図3

ACZ の構造
図4

ACZ のライフサイクル

ローカル層は，ローカル ACZ 上のエージェントを管理するテーブル LAT（Local Agent address Table）

ACZ は生成されると直ぐに起動・初期化され，非活を持ち，ローカル ACZ 上のエージェントへのエー動状態から活動状態になる．活動状態中は，エージェジェントメッセージの伝達を行う．ローカル ACZ 上ントの生成や消滅，エージェントメッセージの伝達がのエージェントの生成または消滅時には，その名前が行われる．そして，最後に停止され，活動状態からLAT に追加／削除される．

非活動状態に変化する．このように，ACZ の動作は，

34

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

6

起動・初期化，エージェントの生成・消滅，エージェ

ら DeLINK を受け取った ACZ2 は（図 6 °1 ），ACZントメッセージの伝達，停止の４つに分けられる．こネットワークの分断をさけるため，GET LINK で停のうち，エージェントの生成・消滅はローカル層での止する ACZ1 から ACZ ネットワークの情報を受け取動作であり，APP は関係しない．そこで，エージェり（図 6 °
2 ，°3 ），ACZ3 との間にリンクを構成するントの生成・消滅以外の３つの ACZ の動作について（図 6 °5 ）．

APP がどのように適用されているかを示す．
3.2.1 ACZ の起動・初期化
KODAMA は，Java で開発されており，ACZ は次のコマンドで起動・初期化される．

java acz.ACZ (使用 port) (接続 IP:port)
図 5 のような状態において，

java acz.ACZ 2000 192.168.0.1:2020

図6

ACZ の停止動作

3.2.3 メッセージの伝達
エージェントメッセージの受信側エージェントがLAT のエージェントであれば，ローカル層でエージェントメッセージの伝達を行う．RAT に登録されてい図5

ACZ の初期動作

るエージェントであれば，RAT からアドレスを求め，DELIVER を用い，エージェントメッセージを伝達
で ACZ1 を起動すれば，ACZ1 は，まず，LINK をする．LAT，RAT 双方に登録されていないエージェ使って，ACZ2 ( 192.168.0.1 /2020) との間で，相互ントであれば，そのエージェントの検索が行われる．

通信のためのリンクを作る．これは，ACZ1 と ACZ2ACZ でのエージェントの検索は，KODAMA エーが各自の LT に相互登録する（図 5 °1 ，°2 ）ことにジェントの論理的構造を参照し，LOCATE AGENTよって実現する．次に，ACZ2 の持つ ACZ ネットワーを用いて行う．
（図 7）．KODAMA では，エージェンクの情報を集め（図 5 °3 ，°4 ），集めた ACZ 中の任トは階層的に配置され，エージェントの名前が階層意の ACZ との間で相互の通信経路を作成する（図 5の場所を示す．例えば，”root・A”の名前を持つエー°
5 ，°6 ）．図 5 では，ACZ3 とだけ通信経路を作成しているが，ACZ の設定†1 によって，任意の数の通信ジェントは，”root”の名前を持つエージェントを上経路を作成することができる．このことで，ACZ1 はジェントを下位階層に持つ．ACZ は，検索依頼を表特定の ACZ への依存度を減らすことができる．

す LOCATE AGENT を用いて，次の方針でエージェ

3.2.2 ACZ の停止位階層に持ち，”root・A・child”の名前を持つエーントの検索を行う．

図 6 のような状態において，ACZ1 が停止すれば，(a) 検索は RAT，LAT から refer header に含ま

ACZ2 と ACZ3 の間での通信経路が無くなり，ネッれない ACZ で活動するエージェントで階層的にトワークが２つに分断される．このため，ACZ1 か最も近いエージェントを見つけ，見つけたエー†1 ユーザによって，ACZ 初期化時に作成される通信経路の枠組みが指定される．

ジェントが目的のエージェントであれば，始めに LOCATE AGENT を出した ACZ に SUC-35

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

図77

ACZ でのエージェント検索方法

CESS で応答し（図 7 °2 ），目的のエージェンダムに選び，停止時には LAT，RAT，LT のテーブル

トでなければ，見つけたエージェントが活動すを初期化した．また，各 ACZ には，１０のエージェ

る ACZ に LOCATE AGENT で検索を依頼す

ントを準備し，それぞれに適当なエージェントとコる（図 7 °1 ）．LAT，RAT が共に要素を持たミュニケーションを行わせることとした．この条件でない場合は，最初に LT に登録された ACZ に

1 時間経過したあとにすべての ACZ を停止させた．

LOCATE AGENT で検索依頼を出す．

このときの実験結果を表 3 に示す．

(b) LOCATE AGENT を受け取った AP は，via

表3

header を 見 て ，す で に 受 け 取って い る LO-

実験結果

総 AP メッセージ数

CATE AGENT 要 求 で あ れ ば ，始 め に LO-

2831

CATE AGENT を 出 し た ACZ に FAILURE

総起動・停止回数44で応答する．まだ，受け取っていない LOCATE

エージェントのコミュニケーション数906AGENT 要求であれば，(a) を行う．
(c) LOCATE AGENT の応答として SUCCESSを受け取った ACZ は（図 7 °3 ），検索結果を4.1 ネットワークに関する評価

RAT に登録する．応答として FAILURE を受け実験では， ACZ の起動・停止が共に 44 回行われ結果として，ACZ は，目的のエージェントを見つた．IP=192.168.35.76，port=2200 の ACZ 停止時に発生した AP メッセージを例 1 に示す．†2 ．

けた場合，DELIVER で（図 7 °4 ），エージェント

例 1 では，192.168.35.76 の停止によって AP ネッ取れば，検索失敗である．

メッセージを伝達する．

トワークが分断されることを防ぐため，GET LINKで AP ネットワークの情報を求め，192.168.35.64 と4 実験の間に新しくリンクを作成した．192.168.35.73 とのAPP の有効性を検証するために，APP を実装し間には，すでにリンクを持っていたため，新しくリンた ACZ で実験を行った．実験では，各計算機に一つクは構成しなかった．
結果，44 回の ACZ の起動・停止にも係わらず，APの ACZ を準備し，合計８台の計算機を利用した．各

ACZ は，ランダムに停止・起動を繰り返すこととし，†2 すべての ACZ で 2200 番ポートを使用しているため，ポート番号は省略した．

起動時には接続する ACZ を活動中の ACZ からラン36

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

8ことができる．
この検証のため，我々の研究室で開発している ACZに，APP を実装した結果，APP を実装した ACZ は，動的な経路変更機能を持つ P2P な ACZ ネットワークを構成することができた．
今後の課題は，ACZ 以外の AP に APP を実装し，ACZ と相互運用が可能であるかを検証することと，
例 1: ACZ 停止時の AP メッセージAPP で提供されるエージェント検索方法の効率を検証することである．

ネットワークから孤立した ACZ は，発生しなかった．
すなわち，本稿で提案する APP を使用することで，参考文献

サーバを介さない P2P な AP 間ネットワークを構成[1] G. Zhong, K. Takahashi, T. Helmy, K. Takaki, T.
Mine, S. Kusakabe and M. Amamiya, “KODAMA:
As a Distributed Multi-agent System”, Proceedingsof the 7th International Conference on Parallel andDistributed Systems: Workshops, IEEE Computer
Society Press, pp.435–440, Iwate, Japan, July.2000.
[2] 高橋 健一, 高木 幸一郎, 鍾 国強, 雨宮 聡史, 峯 恒憲, 雨宮 真人,“分散マルチエージェントシステム KODAMA”, 「ソフトウェアエージェントとその応用」特集ワークショップ,SAA2000, 157–164, 2000
[3] T. Iwao, M. Takada, M. Amamiya, “Flexible
Multi-Agent Collaboration using Pattern Directed
Message Collaboration of Field Reactor Model”,
Approaches to Intelligent Agents - Second Pacific Rim International Workshop on Multi-Agents,
LNAI, vol.1733, Springer, pp.1–15, 1999.
[4] N. Minar, M. Gray, O. Roup, R. Krikorian andP. Maes, “Hive: Distributed Agents for NetworkingThings”, IEEE Concurrency, vol.8, no.2, 2000.
[5] FIPA : http://www.fipa.org[6] T. Finin, Y. Labrou, and J. Mayfield, “KQML
as an agent communication language”, In Software
Agents, MIT Press, Cambridge, pp.291–316, 1997.
[7] E.D. Pietro, A.L. Corte, O. Tomarchio, A. Puliafito, “Extending the MASIF Location Service int
the MAP Agent System”, IEEE Symposium on
Computers and Communications, 2000.
[8] D. Comer, D. Stevens（村井 純, 楠本 博之（訳））,“TCP/IP によるネットワーク構築”, 共立出版, 2001.

でき，AP ネットワーク接続の頑健性が確認できた．

4.2 エージェントのコミュニケーションに関する評価
実験では，906 回のエージェントのコミュニケーションが試みられた．このうち，903 回のコミュニケーションが正常に行われた．残り 3 回については，相手のエージェントが存在しないため，コミュニケーションを行わないものであった．この実験で，エージェントは，相手の物理的位置を意識することなく，コミュニケーションが正常に行えた．このように APPを使用することで，ACZ はエージェントの位置透過性を与えることができた．

5 おわりに本稿では，エージェントの活動を促進する環境 APを相互運用するためのプロトコルとして APP を提案した．APP は，サーバを介さない P2P な AP 間ネッ
トワークで，エージェントが物理的環境を意識することなくコミュニケーションを行うための環境を与える

37