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の基本動作が実施されています。
