3. 研究開発の新しい展開と内外の動向

3.2 　エージェントの研究動向

3.2.1 　エージェントとは

　現状、「エージェント」という言葉はさまざまな定義で用いられている。ここでは、プログラミング言語としてのエージェントをオブジェクト指向言語の次の技術と位置づけて考える[1][2]。
　これまで、プログラミングパラダイムは主にアセンブラ言語、手続き型言語、オブジェクト指向言語という流れで変遷してきた。アセンブラは計算機のアーキテクチャを強く意識して計算機の挙動を記述するものであったが、手続き型言語では処理を主体にプログラムが書けるようになり、オブジェクト指向言語では計算対象（object）を主体とする記述が可能となった。これは、手続き型言語においては計算機のアーキテクチャを隠蔽し、オブジェクト指向言語においてはデータ抽象の考え方によってデータ実装の詳細を隠蔽した抽象化の歴史とみることができる。この抽象化は、計算の世界と現実の世界を近づける方向で続けられてきた。オブジェクトの次に位置づけられるエージェントもこの抽象化の延長上にあると考えられる。さらなる抽象化によって、計算の世界と現実の世界をより近づけるのがエージェント指向パラダイムのねらいである（図 3.2-1）。
　ここでは、オブジェクト指向にどのような特性が加えられ、それによって何が抽象化されたかという観点でエージェントを分類し、分類ごとの研究動向や事例を概観する。

図 3.2-1　プログラミングパラダイムの変遷

3.2.2 　エージェントの移動性

　オブジェクトに加えられた特性として、最初にエージェントの移動性を挙げる。ここでは、移動性を持つエージェントをモバイルエージェントと呼ぶ。モバイルエージェントにおいては、分散処理における通信の概念が抽象化されたとみることができる。モバイルエージェントとして多数のシステムが実装されており、Stuttgart大学教授のHohlが作成したThe Mobile Agent List[3]にも70以上のシステムが登録されている。代表的なモバイルエージェントシステムを表 3.2-1に挙げる。
　モバイルエージェントの実装には、独自のスクリプト言語を定義してインタプリタと共に動作させるもの、ライブラリを拡張して既存の言語（多くはJava）に移動性を持たせたもの、言語処理系（Javaの場合はJVM）に手を加えて移動性を持たせたものなどがある。

図 3.2-2　モバイルエージェントの移動の仕組み

　モバイルエージェントの利点には、ネットワークバンド幅の有効活用が挙げられる。モバイルエージェントは移動した先の資源にローカルにアクセスできるので、大量のデータに対して高速にローカルアクセスを行ったあと、得られた結果のみを移動して持ち帰るといった動作が可能である。必要に応じて移動先のマシン環境の情報を活用したり、負荷の小さいマシンに移動して負荷分散を行ったりもできる。無線アクセスのように通信が切れやすい環境において、通信切断後も処理を継続できる点では特にモバイルエージェントが有効と言える。
　モバイルエージェントの移動の仕組みを図 3.2-2に示す。この図は、モバイルエージェントがホストAからホストBに移動する流れを示している。まず、ホストAで移動前のエージェントの実行が中断される。そして、エージェントのプログラムコードや内部状態が符号化（シリアライズ）される。符号化の結果は通常のデータと同じようにしてホストAからホストBに送信される。ホストBでは、受信したデータに対してホストAと対称の操作を行う。つまり、復号化（デシリアライズ）によってプログラムコードと内部状態を復元し、エージェントの実行を再開させる。この一連の流れが完了すると、ホストAにいたモバイルエージェントがホストBに移動し、処理を続けることになる。

図 3.2-3　Telescript

　モバイルエージェントの実行の中断/再開、プログラムコードや内部状態の符号化/復号化、送信/受信などは、モバイルエージェントのプラットフォームと呼ばれるミドルウェアによって行われる。内部状態の符号化/複合化において、プログラムコードとインスタンス変数のみを対象とする場合を、「弱い移動」と言う。これに対して、プログラムコード、インスタンス変数に加えてプログラムカウンタまで対象とするものを「強い移動」という。ここで強調すべき点は、モバイルエージェントのコーディングの簡単さである。例えば、ホストAで処理1、2を行って、次にホストBに移動して処理3、4を行うとする。このときのコーディングは以下のような簡単な記述で済む。

　　　　処理1;
　　　　処理2;
　　　　go(ホストB);
　　　　処理3;
　　　　処理4

　このため、さまざまな非同期分散処理が必要となる場面でもモバイルエージェントを活用すれば、簡明な記述の集合によって全体の処理を定義できる可能性がある。
　モバイルエージェントの例として、General Magicが開発したTelescriptを紹介する（図 3.2-3）。Telescriptにおいては、移動するプロセスをエージェント、移動しないプロセスをプレースと呼ぶ。エージェントがプレース間を渡り歩き、同じプレース内にいるエージェントと出会って（ミートして）相手のプロシージャを呼び出したり、他のプレースにいるエージェントと通信（コネクション）したりするモデルが、独自のスクリプト言語上に実装されている。エージェントの移動には、強い移動が採用されている。各エージェントは権限を持っており、これにより資源へのアクセス制御も可能である。今日のモバイルエージェントで用いられる概念の多くは、Telescriptにおいて実現されたものである[4]。

3.2.3 　エージェントの協調性

　オブジェクトに加えられた特性として、次にエージェントの協調性を挙げる。ここでは、協調性を持つエージェントを協調エージェントと呼ぶ。協調性の導入は、分散処理における異種性、位置、通信手順などの抽象化につながるものである。代表的な協調エージェントシステムを表 3.2-2に示す。
　協調エージェント技術の利点は、エージェント間のコミュニケーションの意味や意図のレベルまで踏み込んだサービスを提供して、エージェント同士の動的で緩やかな連携を可能にしたこと（疎結合モデル）や、あらかじめ連携することを意図して設計していなかった異種システムを連携動作させられるようにしたこと（相互運用性）などである。協調エージェントの研究は分散オブジェクトの研究と深くかかわっている。分散オブジェクトには、もともと分散している（非オブジェクト）システムのそれぞれをオブジェクト化する垂直分散アプローチと、非分散のオブジェクトを（分散化を意識させずに）分散させる水平分散のアプローチとがあるが、どちらにおいても透過性の概念が重要である。分散オブジェクトにかかわる透過性には、位置透過性、異種透過性、障害透過性、規模透過性、移動透過性などが挙げられる。透過性とはある種の抽象化であり、その実現には数々の協調エージェントの技術やコンセプトが応用されている。例えば、分散オブジェクトにおける位置透過性の追求には、ネーミングサービス、トレーディングサービス、メディエータなどの技術が使われるが、これにはファシリテータの考え方がかかわっている。UDDI（Universal Description, Discovery and Integration）[5]におけるWebサービスのためのディレクトリ機能は、次に述べるファシリテータによるリコメンドパターンの応用と見ることができる。

図 3.2-4　ファシリテータによるサービス利用パターン

　ファシリテータは、エージェント間の協調動作させるための仲介機能をもったエージェントである。ファシリテータによるサービス利用の代表的なパターンを図 3.2-4に示す。Fはファシリテータを、Pはサービスプロバイダを、Rはサービス利用者を表す。障害透過性の追求には、オブジェクトの多重化や冗長待機などの手法が用いられるが、共有データ空間、タプルスペース、黒板モデルなどを介してオブジェクト同士が間接的なコミュニケーションを行う場面にも、協調エージェントの技術が応用され、効果を発揮している[6]。

図 3.2-5　Bee-gent

図 3.2-6　プランニングエージェントの構造

　協調エージェントの例として、東芝のBee-gentを紹介する[7]。Bee-gentは、既存アプリケーションをエージェント化するエージェントラッパーと、アプリケーション間の連携手続きを管理するモバイル仲介エージェントから構成される。これらの仕組みにより、データベースやWebサービス、レガシーシステムなどの各種ソフトウェアを柔軟に接続して活用することを目指している。Bee-gentの概念図を図 3.2-5に示す。モバイル仲介エージェントは、接続対象のアプリケーションが存在する場所に移動し、エージェントラッパーと対話しながら要求を伝える。エージェントラッパーはアプリケーションの状態を管理し、必要に応じてアプリケーション処理を起動することによって、モバイル仲介エージェントからの要求にこたえる。エージェント間の対話には、FIPA準拠のACL[8]が用いられる。ACLは、会話の意図を表す通信行為（Communicative Act）を記述することが特徴であり、これにより受け手側は意図を解釈した上で自分なりの処理手順を決定できる。Bee-gentでは、FIPAが策定するACLをXML形式で表現したXML/ACLを採用している。XML形式の採用によってインターネットとの親和性が格段に向上し、企業間でのXML/ACL.の交換も可能となっている。モバイル仲介エージェントやエージェントラッパーの動作を定義するための専用のビジュアル開発環境も提供される[9][10][11]。

3.2.4 　エージェントの自律性

　オブジェクトに加えられた特性として、次にエージェントの自律性を挙げる。ここでは、自律性を持つエージェントを自律エージェントと呼ぶ。自律性の導入は、処理の手順や手続きの抽象化にねらいがある。

図 3.2-7　Plangent

　一般にオブジェクトは受動的であり、エージェントは能動的と言われる。しかし、分散オブジェクトなどにおいては作りこみによってオブジェクトの自律性・能動性を実現している例が多く、外部から観察しただけでは両者の違いは明確ではない。自律エージェントのための言語においては、自律性が言語処理系において支援される。これを実現するために、多くの自律エージェントの処理系ではプランニング技術を採用している。一般的なプランニングエージェントの構造を図 3.2-6に示す。プランニングには熟考プランニング、反応プランニング、ハイブリッドプランニングなどがある[12]。
　自律エージェントの利点は、従来の手続き型言語やオブジェクト指向言語では書ききれないような処理、特に柔軟性を必要とする処理が書きやすい点にある。1対1ビジネスにおけるパーソナライズ処理や、状況に応じてダイナミックに処理内容を変更する状況依存処理などに対するニーズは高く、これらの問題に自律エージェントを応用することが期待されている。また、予期せぬ事態に対して柔軟に対処できる点も自律エージェントの利点である。例えばネットワーク上の処理が何らかの原因で中断された場合にも、自律エージェントは自分で代替手段をさがして処理を継続する。
　自律エージェントの例として、東芝のPlangentを紹介する[13]。Plangentは、プランニング機能を持つモバイルエージェントが、目標達成の手段を自分で考えながら、ネットワーク上を自律的に動き回って処理を行う点に特徴がある。ユーザからの要求を受けとったPlangentエージェントは以下のように行動する（図 3.2-7）。

　このようなPlangentには多くの利点がある。例えば、ユーザが細かい作業手順を指示する必要がないこと、予期せぬネットワーク環境の変化に対してエージェントが柔軟に対処すること、個人の好みや過去の事例を学習してエージェントが成長することなどは大きな利点である。また、エージェントの移動時以外は通信回線が切断されてもよいため、今後増加する携帯機器向けソフトウェアとしても適した特性を持つ[13][14][15]。

3.2.5 　その他の特性

　これまでに、移動性、協調性、自律性の3特性をオブジェクトがエージェントとなる際に加えられた主要なものとして挙げた。ここではその他の試みを簡単に紹介する（表 3.2-3）。エージェントに環境適応性や順応性を持たせる試みにFlage（情報処理振興事業協会）の提案がある。また、環境の変化を陽に扱う有機的プログラミング言語としてGaea（産業技術総合研究所）が提案されている。エージェントの成長をコンセプトとする言語には、FlageのほかにMusic、Morpheがあり、計算の場（フィールド）やセルを導入した言語には、Flage、GaeaのほかにCellua、Kamui、Kemariなどがある。ほかにはオブジェクトの通信方式を拡張したり、オブジェクトに永続性を持たせたり、リフレクションを導入してエージェント化をはかった言語の提案がある。

図 3.2-8　Flage

　ここではこれらの言語の中でFlageを紹介する。Flageは環境変化に対する適応、エージェントの成長、場の計算といったコンセプトの実現を目的としたエージェント言語である（図 3.2-8）。Flageのモバイルエージェントが場に入ると、そこに置かれている機能を使って計算を行うことが可能となる。これにより、エージェントは移動先の環境に合った計算方法を獲得し、その場で実行する。また、エージェントは場に置かれている計算方法を自分のものとして取り込み、場を去った以降も持ち歩くことができる。この機能をうまく活用すれば、エージェントが場を渡り歩きながら次々と新機能を獲得し、エージェントが成長するモデルを実現できる[1][17]。