1. はじめに
Answers Anywhereは自然言語で入力されたユーザーの指示から意図を汲み取り、対話をしながら機器操作やデータを検索するシステムを構築するためのミドルウェアです。エージェント・ネットワークという独自の技術により高速、小容量、言語依存度が低いエンジンとなっていることが特徴です。前回は、SDKのインストールとAnswers Anywhereが自然文の入力に対してどのような反応を返すのかを電子メール検索のサンプルを使って説明しました。今回は同じサンプルを使いAnswers Anywhereがどのように動くのかについて解説をしたいと思います。
2. エージェント・ネットワークの構造
エージェント・ネットワークは、対象となるアプリケーションの機能やデータ構造を記述した概念モデルです。このモデルは「エージェント・ネットワーク」という言葉が示すようにエージェントを組み合わせてネットワーク状の構造としたものです。エージェント・ネットワークは以下の順で構築されます。
- 対象とするアプリケーションの範囲を特定する（アプリケーションドメインの設定）
- 範囲を機能またはデータ要素に分割しそれを処理の単位とする。処理の単位は１つずつエージェントに割り当てる
- 分割された処理単位の関係に基づきエージェントの親子関係を構築
- 上記処理単位を起動させるための語彙や文法ルールを各エージェントに設定する
具体的な例として、前回サンプルとして動かした電子メール検索を行うアプリケーションを考えて見ましょう。このアプリケーションの範囲を考えると（「電子メール検索」となっていますが操作全般について考えました）メール全体の中から条件に合致したものを参照する、削除するという操作が考えられます。操作の対象はメールやアドレス帳といったものになるでしょう。このように想定したアプリケーション範囲をリスト1に示します。
・条件に合致したメールを検索する ・条件に合致したメールを削除する ・条件に合致したアドレス帳を検索する ・条件に合致したアドレス帳を削除する
範囲が決まったらそれらを処理の最小単位に分割します。このときは操作の内容（Command）、操作の対象（Object）、対象の持つ属性（Field）という区分で考えるとやりやすいと思います。この区分で考えた分割結果をリスト2に示します。
操作の内容（Command） ・検索する ・削除する 操作する対象（Object） ・メール ・アドレス帳 対象の持つ属性（FieldまたはRelation） ・メールのもつ属性：重要度、作成日、サブジェクト、 送信者（アドレス帳）、受信者（アドレス帳） ・アドレス帳の中の人のもつ属性：姓、名、性別 ...etc
分割できたらそれを処理の単位としてエージェントに割り当てます。そして関係のあるもの同士を接続することでエージェント・ネットワークが構築できます。リスト2の例では「検索」の対象は「メール」と「アドレス帳」のため、EmailエージェントをEmailとContactエージェントに接続します。割り当ての一覧を表1に、構築されたネットワークを図1に示します。
| 区分 | 分割された処理 | エージェントへの割当 |
| 操作の内容(Command) | 検索する | Find |
| 削除する | Delete | |
| 操作する対象(Object) | メール | |
| アドレス帳 | Contact | |
| 対象の持つ属性(Field) | 重要度 | Priority |
| 受信日 | CreationDate | |
| サブジェクト | Subject | |
| 対象の持つ属性 他の対象にひもづくもの(Relation) |
送信者 | Sender |
| 受信者 | Receiver |
最後に、各エージェントに語彙を割り当てます。Answers AnywhereのSDKでサンプルを読み込み、Emailエージェントをダブルクリックするとエージェントの設定画面が開きます。設定画面のTemplate PropertiesタブのKeywordの部分にはそのエージェントの処理単位を起動させるための語彙「Email」が設定されています。またSynonym Tableタブには語彙Emailの同義語が「メール」を含め10個ほど記述されています。この設定によりユーザーが「メール」と入力するとEmailエージェントが緑色になりメールに関連する操作が起動されるというわけです。エージェントには他にも振る舞いを設定するパラメータがたくさんありますがそれらについては連載の中で徐々に解説していきたいと思います。
エージェント・ネットワークのアーキテクチャ上の特徴ですが、処理単位を分割することで各エージェントの処理が単純化され、文章を解析するという複雑な処理でも大量の計算をしなくてすむようになります。このため組み込み機器にものせて動作させることができるくらいエンジンの処理が軽くなります（現に組み込み版ランタイムも販売されています）。また、モデルの拡張をしたいときは新たな部分のみをエージェントとしてネットワークに追加するという方法で実現できるため、拡張性も高いという特徴を持っています。
3. エージェント・ネットワークの仕組み
このようにして構築されたエージェント・ネットワークは、入力に対して図3のような流れで解析が行われ処理が実行されます。
それでは処理の流れを、順を追って説明しましょう
1）文章解析
入力文の意味を解析する処理です。エージェント・ネットワークは、ユーザーから受け取った文章入力を親から子へ全エージェントに流し、解析を依頼します（図4矢印）。各エージェントの持つ語彙や文法ルールに対して入力の一部分がマッチすると、エージェントはその部分にクレーム（理解できたというマーク）を付け、親エージェントに報告します。親エージェントは、自身と子エージェントのクレームを結合して意味を強め、さらに親に通知します。
図4の例では、入力文のうち「池田」はアドレス帳の人名なのでContactエージェント、「重要」は重要度を示すPriorityエージェントがそれぞれクレームをつけます。ContactからのクレームはSender、Receiver両方に報告されますが、Senderでは送信者を示す「からの」にクレームと「池田」が結合され、結果的に「池田からの」がSenderのクレームとなります。一方ReceiverではContactから通知された「池田」のみがさらに親に通知されます。すべてのクレームが同様に処理され、最終的に理解できた部分を示すクレーム「池田からの重要メール」がInterpretationエージェントに届きます。
次に、1番強いクレームを出したエージェントに結果出力の依頼をします。依頼を受けたエージェントはXML出力を出します（図5）。子から順番に収集された出力を結合し最終的に解析結果XMLとします。図5の例ではクレームを出したSystem、Find、Email、Sender、Contact、Priorityにから出力がされています。Receiverも「池田」に対してクレームをしましたがSenderのクレーム「池田からの」と重なっており、かつ小さかったので負けてしまい出力依頼がされませんでした。これがエージェント・ネットワークの特徴的な動きである競合解決の仕組みです。
それでは、クレームが重なっていて先の例のように意味の強さが決められない場合はどうなるでしょうか？ 例えば図6のように「山田のメール」と入力されたときSender、Receiver両エージェントからともに「山田」に対するクレームがEmailエージェントに届きます。この場合は「山田からのメール」「山田宛のメール」のどちらの意味にも取れる解釈が一意に決められない曖昧な状態（Ambiguityと言います）とみなされ、不確定な部分が候補として出力されます。この出力は後述の出力整形処理でメッセージに変換されユーザーに意味を確定するように促します。
2）文脈追跡
文章解析結果に前回の処理結果を考慮し対話的な動きを与えるのが文脈追跡です。以下の2つの内容が実施されます。
引継ぎ処理
前回の入力に対するXML出力を今回の出力に結合します。クレームしたエージェントの子の中で、前回はクレームしたが、今回クレームしていないエージェントの出力が結合の対象となります。図7の例では前回の入力「池田からのメール」でSenderエージェント、今回の入力「重要なものでは」Priorityエージェントがクレームしました。ここで、Sender、PriorityともにEmailエージェントの子のため、Senderエージェントの前回のXML出力が引継ぎ対象となり出力に付加されています。結果的にこの2つの入力は「池田からのメール（のうち）重要なもの」という意味に解釈されたわけです。人と人とが会話しながら頭の中で情報を組み立てていくような動きと考えると分かりやすいかと思います。
話題での優先度づけ（Recency）
解析結果に競合が発生し曖昧状態となった場合に前回クレームしたほうを優先します。例えば、「山田」とだけ入力された場合、文脈がなければ「山田からの」「山田宛の」の2つの意味のどちらかが確定できませんが、前回「池田からのメール」と入力されでいるのであれば、Senderエージェントの方に話題があるとみなされ、そちらを優先して「山田からの」を自動で選択するように動作します。
3）推論ヒント
入力の解析結果をもとに、次のユーザー入力を支援するヒントを出すための処理になります。以下2つの内容が実施されます。
関連性の高い操作の提示
今回の入力内容に関連性の高い次の操作を提示するための処理です。エージェント同士のつながりは処理単位の関連性を示しているため、クレームしたエージェントにつながっているエージェントは今回の入力に関連が高いと言えます。このつながりをユーザーに提示することでユーザーの操作支援ができます。図8の例では「池田」という入力に対してクレームしたエージェント配下の未クレームのエージェントを調べています。Findの子であるEmail、そのまた子のSender、Receiverを通じてクレームしているContactにつながっているので図の赤線部分は関連が高いと判断され、そこを通る「池田からのメール（Contact-Sender-Email）」「池田宛のメール（Contact-Receiver-Email）」は関連性が高い処理であるとしてユーザーにヒントとして提示されます。
必須値のチェック
必須の値であるがまだ未入力であるものをチェックします。チェックの結果は後述の出力整形処理でメッセージに変換されユーザーに必須値を入力するように促します。電子メール検索のサンプルではこの機能は使っていないため具体的な例は次回以降の連載にしたいと思いますが、この処理をすることでAnswers Anywhereがより対話的にみえる動きとなります。
4）処理実行
解析結果XMLをもとにデータの抽出やアプリのAPIを呼び出す部分です。この部分は処理にあわせてモジュールの入れ替えができる構造となっています。このモジュールのことをサービスプロバイダと呼びます。Answers Anywhere標準では以下のサービスプロバイダを提供しています。
データベース・サービスプロバイダ
データベース検索をするためのサービスプロバイダです。解析結果XMLから検索SQLを自動生成し、JDBC経由で取得した検索結果を実行結果XMLに変換します。電子メール検索のサンプルではこのサービスプロバイダを使用しています。
WebXMLサービスプロバイダ
RESTインターフェースを備えたWebサービスに接続するためのサービスプロバイダです。解析結果XMLの指定された要素を抜き出してURLをつくりWebアクセスし、得られた結果を実行結果XMLとします。
RSSサービスプロバイダ
WebXMLサービスプロバイダと働きは似ていますが、RSSサイト向けに特化したものです。
また、サービスプロバイダAPIを使用して新規のサービスプロバイダを開発することで、標準でサポートされていないものに対しても連携できます。
5）出力整形
文章解析処理で発生した曖昧状態や推論ヒント処理でのヒント情報はXML形式の情報として実行結果XMLに含まれていますが、それを人が読める文章に変換します。また同時にHTMLやプレーンテキスト等、表示可能な形式の文字列に変換します。この変換を行うモジュールのことをフォーマッタと呼びます。どのフォーマッタを使用するかは入力のたびに選択ができるので、同じユーザーが複数種類の入出力デバイスを使用するマルチモーダルなアプリケーションが実現しやすいと言えます。
以上の流れで、電子メール検索のサンプルで見たようなユーザーの文章による質問からデータベースを検索し結果を表形式で表示するというAnswers Anywhereの基本動作が実施されています。
4. エージェントとは何か？
Answers Anywhereの説明をするとき、「エージェントとは何ですか？」という質問をお客様よりよく受けます。「エージェント」という言葉は聴いたことがあるが具体的に何かよくわからないという方が多いようです。大リーグに移籍する選手のために移籍先のチームと交渉する人のことをエージェントと呼びますが、コンピュータの世界では、代理性（依頼人の代わりに処理を実行する）、知性（状況に応じ知的に振舞う）、移動性（要求されたものを探索し取りに行く）などの特性を持つ自律動作するプログラムを指します。さらにマルチエージェントといった場合は協調性（機能や能力の異なる複数のエージェントで目的実現のため補い合っては働く）という特性も加味されます。コンピュータの世界での具体的な例としては次のものがあるかと思います。
インターフェース・エージェント
画面の中でユーザーの入力を受けつけたり話しかけてくるキャラクター。エージェントというとこれを思い浮かべる人も多いのではないでしょうか。知性や代理性があると言えます。
監視エージェント
サーバや機器の遠隔監視のために常駐動作し、問題を検出したときに通知するプログラム。人の代わりに監視するという点で代理性があると言えます。
移動検索エージェント
ネットワーク上の別のマシンにあるエージェント実行環境を次々と移動しながら、条件に合致した情報を収集し、結果を持って戻ってくるプログラム。文字どおり移動性ですが、ユーザーの代わりに情報をとってくるという点では移動性であり、収集の際は知的に振舞うこともあります。
これに対してAnswers Anywhereでのエージェントは「入力に対して自分の持つ知識や状態に応じ応答をする（クレームする）もの」です。上記に挙げたものよりは動作の粒度が小さく、神経細胞に近い動きをするものです。エージェントというよりはセルまたはシナプスといった方がよいかもしれません。ただ、これらが複数組み合わさって協調して動作することで、知性（ユーザーの命令を解釈し）、代理性（処理を実行する）という性質が発揮されていると言えます。
5. おわりに
Answers Anywhereは普通のプログラミング言語とは異なるので、その動作を理解していただくために前回から引き続き解説が主となりました。次回はいよいよエージェント・ネットワークの開発を予定しています。おたのしみに。
