エージェントは生き残っているか？(前編)

作者 株式会社 豆蔵　皆川 誠 投稿日 2011年8月16日

セクション

エンタープライズ・アーキテクチャ,

デベロップメント

トピック

プラットフォーム ,

プログラミング ,

Architecture ,

分散プログラミング ,

Agents

共有 |

エージェント・プラットフォーム概略史

前世紀末から今世紀初頭にかけて、「エージェント指向」というコトバは「ポスト・オブジェクト指向」の有力候補として非常にもてはやされていた。当時、多くの研究者が各々の視点でさまざまな「エージェント指向」を提案し、Telescript, Bee-gent, TeaTray, Plangent, Aglets, …などなど、実際に動作する多種多様なエージェント・プラットフォーム(ソフトウェア・エージェントが動作するための土台となる環境)が開発されてきた。あたかも古生代のカンブリア大爆発のように、当時のエージェント・プラットフォームはそれぞれ非常にユニークな特徴を備えていたが、そのユニークさ故に、種類の異なるエージェント・プラットフォーム間の相互運用性(インターオペラビリティ)はほとんど皆無だった。
このような状況の中、FIPA ( Foundation for Intelligent Physical Agents )という非営利標準化団体が、西暦2000年～2002年頃、おもにエージェント・プラットフォーム間の相互運用性を確保するための各種仕様の標準化を行った(以降、本記事ではFIPAによって標準化された仕様群を指して「FIPA仕様」と記す)。FIPA仕様の内容が固まってくるに従って、FIPA-OS, Zeus, JACK, AAP(April Agent Platform), SPADE, JADE, など、FIPA仕様準拠を謳う(いわば第二世代の)エージェント・プラットフォーム群が登場してきた。
この頃までは、エージェント・プラットフォーム技術は順調に進化していっていたように見えたが、なぜかこれ以降、進化の速度が急速に鈍って(目立った変化が少なくなって)きてしまっているように思える。FIPAは2005年6月にIEEEの下部団体として併合されたが、FIPAによる標準仕様の追加/更新/新規公開は2003年以降ほとんど行われていない。実は、FIPA仕様をサポートする機能をJava言語/標準ライブラリに組み入れる事を目的として、JSR-87: Java Agent Services という仕様案がJCP ( Java Community Process ) にかけられていたが、2002年5月のパブリック・レビュー締切以降特に目立った変化がなく、ついに2011年1月に撤回されてしまった。
学術分野ではAAMAS ( International Conference on Autonomous Agents and Multiagent Systems ) というエージェント指向関連の国際会議が2002年から世界各国の都市で毎年開催されており、今年(2011年)で第10回開催を迎えている。研究者は地道ながら着実に進歩を続けている様子だ。エージェント・プラットフォームについてはどうだろう？ 第一世代のエージェント・プラットフォーム群のほとんどは消滅して(淘汰されて)しまっている。第二世代のエージェント・プラットフォーム群は生き残って進化を続けているのだろうか？

FIPA仕様の特徴

第二世代のエージェント・プラットフォームの動向を語る前に、本記事の前編では、一般の開発者にあまり知られていないFIPA仕様の概要と特徴を簡単に説明しておく。

FIPA仕様では、エージェント・プラットフォームの抽象アーキテクチャの概念が定義されている。

図1 FIPA抽象アーキテクチャの概観イメージ

FIPA仕様準拠のエージェント・プラットフォームには、少なくともAMS ( Agent Management System )、DF ( Directory Facilitator )、MTS ( Message Transport Service ) という3種類のコンポーネントが存在する(図 1 )。AMSによって、エージェントの生成/削除/停止/移動などのライフサイクル管理と名前による検索がサポートされる。DFによって、各エージェントが提供するサービスをキーにした登録/検索(イエロー・ページ・サービス)が可能となる。MTSによって、HTTP, IIOP, SMTP, など、下層の転送プロトコルを意識しないエージェント間通信を行うことができる(図 2 )。

図2 MTS ( Message Transport Service ) の仕組み

FIPA仕様では、ACL ( Agent Communication Language ) と呼ばれる、エージェント間でやり取りされるメッセージの形式も定義されている。FIPA仕様でのエージェント間のメッセージのやり取りは、電子メールの送信/受信/返信のイメージに近い。
エージェント間での処理の依頼/問い合わせ/協議/協調のためには、通常、何回かのメッセージのやり取りが必要になる。FIPA仕様では、対話論理研究に基づいて考えられた典型的な対話パターン(手順)を示す11種類のインタラクション・プロトコル ( IP: Interaction Protocol ) と、ある対話(インタラクション)を構成する各々の発話(メッセージ)のタイプを示す22種類の Communicative Act ( またはPerfomative ) が定義されている。

図 3 "Request" Interaction Protocol の概要

インタラクション・プロトコルと Communicative Act によってエージェント間対話の大枠の意味付けを行うことはできるが、具体的な指示/要求/問い合わせなどを行うためには、やはり各々のメッセージの中身の記述を送信側/受信側ともに正しく解釈できる形式で記述してやり取りする必要がある。FIPA-ACLでは、メッセージの中身(content)の記述言語やエンコーディングなどを置き換えられるようになっている。FIPA推奨のコンテンツ記述言語SL (Semantic Language ) では、対話内容に含まれる語彙(ある特定の対象領域における概念(Concept)/述語(Predicate)/行為(Action)など)の構造や語彙間の関係構造を規定するオントロジ(Ontology)との紐付けや、一階述語論理的な問い合わせ/マッチングを行うことができるようになっている。

以上のように、FIPA仕様では、異なる実装を持つエージェント・プラットフォーム群の相互運用性を確保するための基本的な仕組みに対するさまざまな仕様が定義されている。これらの仕様のいくつかは、後のWebサービス関連仕様の標準化などにも影響を与えていたと言われている。

<<<後編につづく>>>

関連情報：

1. FIPA：http://www.fipa.org/
2. AAMAS 2011：http://www.aamas2011.tw/
3. 【豆蔵】エージェント技術支援：
   http://www.mamezou.com/service/agent.html