3.2　次世代Webとエージェント

3.2　次世代Webとエージェント

3.2.1　はじめに

　WebサービスやセマンティックWebなど、機械がWebコンテンツの意味を理解した上で処理することを可能にする、新しいWebの世界を目指した研究が進められている。次世代Webと呼ばれるこの新しいWebの世界では、人間の代理人となってWeb上のさまざまな仕事を処理するソフトウェアエージェントが重要な役割を果たす。そこで、本章では、エージェント技術研究の最新動向をサーベイした後で、WebサービスやセマンティックWebなどの次世代Web技術とエージェント技術との関わりについて触れる。次に、エージェント技術をWebサービス分野に応用した具体事例として、Webサービス向けマッチメーカーを紹介する。Webサービスにおける現状のUDDIでは、検索の際にサービスの意味までは考慮しないため、今後、多数のWebサービスが登録された際に、その中から適切なサービスを探し出すのが難しくなる。Webサービス向けマッチメーカーは、この問題を解決するために開発された、Webサービスのための検索エンジンである。Webサービスの提供者がWSDLやOWLなどの言語を併用してサービスを定義すると、Webサービス向けマッチメーカーはオントロジーや制約条件などの意味情報を活用し、利用者の要求に合った適切なサービスを探し出す。

3.2.2　エージェント技術に関わる最近の動向

(1) エージェント技術の標準化
　FIPA (Foundation for Intelligent Physical Agents)[1]は、エージェント技術の標準化を進める非営利団体である。1996年にスイスのジュネーブで登録され、50前後の企業・大学が参加して活動を続けている。活動の主な目的は、異種エージェントシステム間の相互運用性を確保する標準仕様の策定である。2002年12月に、それまでにまとめられたエージェント通信言語(ACL; Agent Communication Language) やインタラクションプロトコル、エージェント管理などに関する23の仕様がFIPA全メンバーの投票を経て標準仕様(Standard)として承認された[2]。これを受けて、今後、産業・学術分野においてFIPA仕様の活用が盛んになっていくものと予想される。

(2) FIPA仕様に基づくエージェントプラットフォーム
　FIPA仕様を先取りしたエージェントプラットフォームも次々と登場している。FIPA-OS(FIPA Open Source)[3]、JADE(Java Agent DEvelopment Framework)[4]、JADEを携帯機器向けに軽量化したLEAP(Lightweight Extensive Agent Platform)[5]が有名であるが、この他にも Zeus[6]、AAP(April Agent Platform）[7]、Bee-gent[8]、Grasshopper[9]、microFIPA-OS[10]などが知られている。多くのプラットフォームはWebページからダウンロード可能である。

(3) AgentCitiesプロジェクト
　FIPA仕様に準拠したプラットフォームを用いて、インターネット上でさまざまなエージェントサービスを提供する国際プロジェクトAgentCities[11]が盛り上がりを見せている。エージェントサービスとして各都市(city)の情報を提供することから、この名が付けられたものである。グローバルにプラットフォームを管理するPlatform Directory[12]を見ると、現時点で100前後のプラットフォームが登録されており、国内からもAgentCity TokyoとSendaiがこれに参加している。このプロジェクトでは、当面はエージェントサービスの相互運用技術の開発を進めるが、将来的にはセマンティックWebやWebサービス、グリッドコンピューティングなどとの連携を図り、ダイナミックで知的かつ自律的なエージェントの実現を目指していく。

(4) セマンティックWebとエージェント
　セマンティックWebとは、Web上のコンテンツの意味を取り扱う技術である。これによりWebコンテンツの意味を機械的に扱うことが可能となるため、エージェントが文字通り人間の代理人となって、Web上のさまざまな仕事を処理することが期待される[13,14,15]。このような知的エージェントがWebコンテンツの意味を理解する上で、オントロジーが重要となる。オントロジーを記述する言語として、W3C(World Wide Web Consortium)では当初DARPAで開発されたDAML (DARPA Agent Markup Language)[16] とEUで開発されたOIL (Ontology Inference Layer)[17] を統合したDAML+OIL[18] の採用が検討されたが、その後、これをベースとする新たな言語OWL(Web Ontology Language^[1] )[19] が提案され、今後はOWL中心に検討が進むものと思われる。

(5) Webサービスとエージェント
XMLやSOAPといった技術をベースに、Webサービスは急速に広がりを見せている。Webサービス技術に関しては、W3C[20]やWS-I (Web Services Interoperability Organization)[21]などで仕様の標準化が進められている。このようなWebサービス分野にセマンティックWebやエージェント技術を応用する試みがある。WebサービスのためのオントロジーDAML-S(DAML Services)[22]の活動などがその例である。現状のDAML-SはDAML+OILに基づいているが、OWL版の登場も遠くないと思われる。また、サービスの意味を扱うWebサービスのための検索エンジンも開発されている。次節では、Webサービス向けマッチメーカーと呼ばれるWebサービスのための検索エンジンを紹介する。

3.2.3 　Webサービス向けマッチメーカー

(1) Webサービスの課題
　人がブラウザを介してインターネット上のコンテンツを閲覧する際、コンテンツの検索にはYahoo!やGoogleなどの検索サイトが利用される。これらの検索サイトで使われている技術は、基本的には入力されたキーワードを含むWeb上のコンテンツを探し出すというものである。しかし、こうした技術はWebサービスの検索にそのまま使うことはできない。

図１　Webサービスにおける検索エンジンの位置づけ

　例えば、完成品メーカーが「ネジ」を1,000個発注しようと部品メーカーの電子商取引サイトを探すような場合を考える。必要なネジの個数に相手先が対応可能かどうか、納期や配送地などの条件はこちらの希望に合うかどうかなど、単純なキーワード列では指定できないことが多い。また、部品メーカーのサイトで「ネジ」ではなく「Screw」という言葉を使っていた場合は、キーワード検索ではこのサイトを見つけることすらできなくなる。そこで、 Webサービスには、従来の検索エンジンとは異なる専用の検索エンジンが必要となる（図１）。

(2) Webサービス向けマッチメーカーの概要
　Webサービスとは、簡単に言えば、インターネット上でSOAP (Simple Object Access Protocol)[20]と呼ばれるXML形式のメッセージを使って行なわれるリモートプログラム呼出しである。実際に呼び出されるのはJavaやC#で記述されたプログラムであり、そうしたプログラムの呼出しインターフェースを定義するのがWSDL (Web Services Description Language)[20]と呼ばれるサービスインターフェース記述言語である。また、このWSDLをサービス提供者名やサービス名、アクセスポイントに関する情報と一緒に登録するための専用のレジストリがUDDI (Universal Description, Discovery, and Integration)[23]である。SOAP、WSDL、UDDIの３つはWebサービスの基本的な枠組みと言うことができ、国際標準仕様の策定も進められている。

図２　CMUサイトのWebサービス向けマッチメーカー画面例

　しかし、この枠組みでは従来の検索エンジンと同様に、サービス提供者の名前やサービスの名前、サービスインターフェースの名前をキーワードで検索することしかできない。そこで、Webサービスの基本的な枠組みを変えることなく、サービスが提供するもの（「ネジ」や「Screw」など）の意味や、サービスを呼び出す際の条件（注文個数や納期、配送地など）を対象にサービスを検索する技術が開発された[24,25,26,27]。この技術は、東芝が米国カーネギ・メロン大学(Carnegie Mellon University; CMU)のエージェント技術をベースにWebサービス向けに拡張したものである。この技術に基づいて作られたシステムがWebサービス向けマッチメーカーであり、既に図２に示すような試用版がCMUのサイトから公開されている[28]。

(3) Webサービス向けマッチメーカーによる高度なサービス検索
　Webサービス向けマッチメーカーでは、サービスのインターフェースにオントロジーや制約条件といったメタ・データを新たに付加している。そして、それらに対し「意味検索」や「制約条件間の包摂関係を判定するアルゴリズム」をフィルターとして適用し、候補となるサービスを絞り込んでいく（図３）。

図３　Webサービス向けマッチメーカーの構成

　ここで、メタ・データとは情報の意味や内容を判断するために付加するデータのことである。オントロジーとは一般に語彙体系と呼ばれるもので、意味に基づいて言葉の関係を定義したグラフによって表現される。また、制約条件とはサービスを呼び出す際に満足すべき条件を論理的に記述したものである。以下、簡単な例を用いて説明する。
　例えば、従来のUDDIレジストリにおける検索では、「ネジ」を提供している部品メーカーを検索するには、キーワードとして「ネジ」を与え、サービス提供者の名前やサービスの名前に「ネジ」を含むサービスを探すしか方法はなかった。しかし、Webサービス向けマッチメーカーを使えば、図４にあるようなオントロジーを参照して「ネジ」と「Screw」が意味的に同一であることを発見し（意味検索）、単語として「ネジ」が使われていなくても対象となる部品メーカーを見つけ出すことができる。また、「部品」や「小ネジ」など「ネジ」から見て上位や下位の概念も探し出し、検索時に指定するオプションによって検索結果に含めることができる。オントロジーを検索する深さや検索の時間も指定できる。

　また、従来のUDDIレジストリでは、納期や配送地に関する制約条件を対象にサービスを検索することはできなったが、Webサービス向けマッチメーカーでは以下のような検索が可能である。利用者が次の制約条件を持つサービスを検索したいとする。

(1) 注文個数 ＞ 1,000個
(2) 配送地 ⊂ 東京
(3) 納期 ≦ ７日

　仮に次のような制約条件を持つ部品メーカーのサービスが登録されていたとする。

(a) 注文個数 ＞ 100個
(b) 配送地 ⊂ 関東
(c) 納期 ≦ ５日

　すると、Webサービス向けマッチメーカーは、要求された制約条件(1)〜(3)をサービスの制約条件(a)〜(c)が満たしているということを論理的に判断し（制約条件間の包摂関係を判定するアルゴリズム）、このサービスを検索結果として返す。
　その他にも、利用者がサービス呼出し時に与える情報の種別（品名、注文個数、配送地など）を指定し、その種の情報で呼び出すことができるサービスを検索することも可能である。同様に、利用者がサービス呼出しの結果として得たい情報の種別（納期など）を指定し、その種の情報を返すサービスを検索することもできる。
　つまり、WSDLでは引数のデータ型や個数は指定できても、引数の情報が持つ意味や出力結果が持つ意味までは定義できなかった。Webサービス向けマッチメーカーでは、サービスを呼び出す際に与える引数や、サービスの出力結果にオントロジーを付加することで、サービス自体が持つ意味を規定できる。また、WSDLでは記述することのできない制約条件を論理的に与えることで、提供されているサービスが自分の要求に合うかどうかを判断することができる。こうした技術を現在のWebサービスの枠組みを壊さずに、UDDIへのアドオンとして組み込んだものがWebサービス向けマッチメーカーである（図５）。

図５　UDDIとWebサービス向けマッチメーカーの比較

(4) エージェントによるダイナミックなWebサービス統合
　現在のUDDI利用では、人間がUDDIから返されたサービスのリストを見て、ひとつひとつのサービスインターフェースをチェックし、Webサイトを訪れて要求に合うサービスかどうかを判断することになる。Webサービス向けマッチメーカーを用いることで、このような手間を大きく軽減することが期待できる。また、Webサービス向けマッチメーカーから返されるサービスは、利用者が要求したサービスのインターフェースに整合するものであることが保証されるため、返されたサービスを利用者側のプログラムから直接呼び出すことも可能となる。このため、Bee-gent[8]のようなサービス連携エージェントフレームワークを適用することで、Webサービス向けマッチメーカーを使って探し出した複数のサービスを動的に連携させることも可能になる。
　今後、Webサービスはダイナミックにサービスを統合して活用するものに徐々に変わっていくと考えられるが、そこではこの種の技術が重要な役割を果たす。