はじめに
本連載では、アイエニウェア・ソリューションズ(株)の「Answers Anywhere」という自然言語解析＋対話エンジンを使って、推論・対話を元にユーザ・インタフェースをどう向上させることができるのかを紹介します。とりわけ、Answers Anywhereの特徴でもあるエージェント・ネットワークを使った開発手法に焦点を当てて説明していこうかと思います。
1.Answers Anywhereとは
自然言語の意味解釈、ならびに対話生成を行うためのミドルウェア。あるいは自然言語検索を実現するためのミドルウェアという言い方もできるでしょう。もともとはDejima, Inc.（日本法人はデジマ・ジャパン株式会社）からDejima Directという名前で製品化されていましたが、同社がサイベース社に2004年に買収され、サイベース社のモバイル子会社であるアイエニウェア社の製品ラインナップに加えられたため、製品名がAnswers Anywhereに変更されました。
エージェント技術を使用して、シナリオなしでも対話が自動生成されるのが特徴。ターゲットとするアプリケーションや機器の機能を細分化し、エージェントと呼ばれる単位に割り付けます。その後、エージェント同士を意味や機能のつながりごとに連結し、エージェント・ネットワークと呼ばれるものにします。
ユーザからの要求が与えられると、エージェントが協調動作して意味の解釈を行い、その意味内容や生成された対話内容がXML形式で出力されます。ユーザの意図が認識できない場合も、できる限りの認識を行おうとし、不明点のみをユーザに尋ねるような対話をシナリオによらず自動生成します。
たとえば、音声認識と組み合わせて使用する場合、音声認識の認識精度は技術的要因や外的、環境的要因（ノイズ等）により100％を期待することは当然できませんが、Answers Anywhereにより、認識部分をそのまま活かしつつ、認識できなかった部分（あるいは誤認識部分）を容易に補完するようなインタフェースの構築が可能です。
その他、音声認識に限らず、SMSやメールへの自動返信や、Webサイトのユーザビリティ向上といったところにも適用できます。
『WEB+DB PRESS Vol.30』（技術評論社）に「Answers Anywhereを使ってみよう！－自然言語対話エンジンで実現する使いやすいインタフェース」という筆者の記事があるので、こちらも参照してください。
1.1 機能・データ量の増加とユーザビリティの低下
少し昔の話から始めましょう。以前はラップトップPCというPCがありました（今でも欧米ではlaptop PCという呼び方をします）。文字通り解釈すれば、ひざ（lap）の上に置いて使うPCということになりますが、本当にひざの上に置こうものなら、ひざが壊れてしまうのではないか、というような代物でした。そんなラップトップPCが、さらに小さくなってノートPCと呼ばれるようになり、今ではPDAやスマートフォン、普通の携帯電話でも以前のラップトップPCよりもよほど性能の良いものとなっています。
さて、ラップトップPCからノートPC、PDAや携帯電話という流れにおいて、数値的に言って何が増え、何が減ったのでしょうか。増えたものとして、CPUのクロック数であったり、RAM容量や外部記憶容量、画面の解像度などが考えられます。一方で減ったものとしては、機器の大きさであったり、キーボードの大きさ、画面の大きさ、消費電力といったところでしょうか。消費電力を別にすれば、見た目で分かる物理的なサイズが小さくなった、これによって携帯性が向上したということができます。
機能という観点からすれば、プログラムを格納する領域も大きくなり、CPUも速くなり、使える電子部品の種類も増えたりで、新機能の盛り込みは容易になってきています。コピー機も青焼きから白黒、カラーコピーへと、また、手動での１枚ずつの原稿取りかえから自動での両面複数ページコピー機能へと進化してきました。一方、データという意味では、以前よりも大量のデータを一度に処理することが可能になりました。一度に編集可能な文書データ容量の関係から、卒業論文を複数ファイル構成で作成したのも今は昔の話です。
さて、多機能・大量データへの流れは、システムを使用するユーザを幸せにしたのでしょうか？ 先ほどのコピー機の例の続きを挙げると、高機能なコピー機が登場する一方で、10枚コピーする際にコピーボタンを10回押している人がいるのも事実です。機械の前でボタンを押し続けるというのも、時間のムダという気がしなくもありませんが、「1,0,0,Enter」でコピーが確実に100枚取れるかというと、後で取りに行ったら用紙切れだったりすることもあるので、必ずしも件の10回ボタンを押している人を笑えるかどうかは疑問です。
一方、データ容量という観点から見ると、どんなに検索対象データの数が増えても、最終的に欲しいデータの件数は、昔も今も変わることなく、たかだか数件ですし（レストランの検索の際に、沢山候補を出されても、最終的に行くことになるのは一カ所ですよね）、1,000件のデータがヒットしようと、見る気がなければ0件のデータと同じ情報量ということになりかねません。実際には見る気の問題というよりは、表示画面サイズの縮小化により、大量データを一覧性の高い形で画面に表示することができなくなっています。
上の図は、高機能化に伴うユーザビリティの低下を図示したものですが、前述したように、高機能化だけでなく、データの大容量化もユーザビリティ低下の一因となってしまいます。ゴールの数が変わらないのであれば、元々のデータ容量の増加（レストランの数であったり、テレビのチャンネル数、番組数の増加、携帯音楽プレイヤー内のMP3ファイル数の増加）は、ゴール到達への手数や手間を間違いなく増加させているわけです。ユーザビリティを損なうことなく、様々な機能やデータを使いこなすことができたら、その一つの解がAnswers Anywhereです。
1.2 対話型ユーザ・インタフェースの必要性
さて、機能やデータ量の増加に伴うユーザビリティの低下には、どのような対処法が考えられるでしょうか？ 一つの有効な方法としては、機能、データ量という縦軸と、ユーザビリティという横軸との間でほどほどの妥協点を探すという方法も考えられます。ユーザを徐々に慣らしていき、違和感を感じさせないというのもこの方法に含まれるでしょう。一方、さらなる機能、データ量を備えつつも、（異論があるかも知れませんが）優れたユーザビリティを提供するインタフェースとしての「人間」に学ぶというアプローチも考えられます。
はっきりゴールが決まっている場合、例えば、ハードディスクレコーダで特定の番組の録画を予約するといった作業は、機器の操作方法が分かっていればできる、分からなければできないという点ではっきりしています。また、やりたいことが明確なので、操作方法が分かっている人にお願いすれば、自分で頑張らなくとも所与の目的を達成することが可能です。有能な秘書を持った上司、番頭さんに恵まれた社長さんであれば、指示する際に、みなまで言わずとも、やりたいことを察してくれると言うことも期待できるでしょう。
一方、おおよそのゴールは分かっていても、はっきり決まっているわけではない場合もあります。例えば、次の連休に友達とどこに行こうかを考えているような場面を考えてみましょう。お互いに具体的な目的地を描いていなくても、温泉に行きたい、ゴルフに行きたい、海に行きたいといった漠然とした○○がやりたいという考えから、移動時間や費用、宿の予約の可否などを勘案し、アイデアを出し合いながら、最終的な旅行プランが決まってきます。時には提案に対してノーということがあっても、最終的にはゴールに至るわけです。
さて、これら全てを実現する基盤となる要素が「対話」であると言えます。きっかけとなる言葉（第1発話）が目的ややろうとしていることなどを明示的にすべて言い表していなくても、第2発話以降において、不足している情報を尋ねたり、いくつかの選択肢を提示して選ばせたりするなかで、または日頃の付き合いから非明示的な条件を推測することにより（さらに推測内容が誤っていた場合は補正することにより）、最終的に何がやりたいのかという意図を掴み、何らかのアクションにつなげることができるのです。
ところで「対話」の実装といった場合、一般的にはユーザが何でも指示をしていい「ユーザ主導型」の対話ではなく、システムから選択肢や入力内容を提示する、つまり会話の流れがあらかじめ決められた「システム主導型」の対話や、会話の流れに沿いつつも、条件等の提示を任意の順に行うことが可能な「混合主導型」の対話の2つがあります。宅配便の不在通知に対する電話での応答もこの「システム主導型」対話の一例です。配達日、伝票番号、希望配達日、希望配達時間の順に質問を行うという対話フローに基づいて、1ステップずつの発話ができるだけです。
一方、Answers Anywhereを使ったインタフェースでは、音声での指示にせよ、Webフォームからの入力や、メールのような文字での指示にせよ、特定の対話フロー（発話順序、指示順序）に依存しない自由な対話を通じて、家電などの機器操作や、レストランの検索、音楽プレイヤーでの楽曲選択などを行うことが可能です。別の言い方をすれば、ユーザの自由発話を許し、正しく推論、解釈には対話フローとは違った技術や道具立てが必要になってきます。どのような開発作業が必要になってくるのでしょうか。その解がエージェント指向開発です。
