JP2012248161A - 対話型検索システム及びプログラム、並びに、対話シナリオ生成システム及びプログラム - Google Patents

Abstract

【課題】 ユーザが所望するＦＡＱデータが得られるまで対話を継続できるシナリオデータを生成する対話シナリオ生成システムを提供する。
【解決手段】 対話シナリオ生成システムは、各ＦＡＱデータに対して、そのデータの属性とその属性値を対応付けたデータ集合と、属性、属性値をクラスとして定義したクラスデータとを読込むデータ読込部と、各ＦＡＱデータのそれぞれに対して、属性値を有する全ての属性について、属性とその属性値との対の組み合わせを求め、組み合わせ毎に、当該組み合わせに係るＦＡＱデータの識別情報と、データ数とを得るデータ分類部とを有する。そして、データ数が１個の組み合わせと、データ数が２個以上ｘ個未満（但しｘは３以上の自然数）の組み合わせと、データ数がｘ個以上の組み合わせに対し、異なる観点から、シナリオデータを生成する。
【選択図】 図３

Description

本発明は対話型検索システム及びプログラムに関し、例えば、沢山の質問応答集の中から、対話によってユーザの質問に一番近い質問応答のペアを１つ選び出し、それを回答としてユーザに提供する場合に適用し得る。

また、本発明は、対話型質問応答システム及びプログラムが利用する対話シナリオのデータを生成する対話シナリオ形成システム及びプログラムに関する。

近年、多くの企業で、ＣＳＲ（企業の社会的責任）の向上のために、コンタクトセンタを設置し、お客様の問合せや要望を受け付けたり、ホームページ上での情報公開を積極的に行ったりしている。企業のホームページでは、ユーザが自分の質問の回答を簡単に見つけることができるように、製品やトラブルシューティング等のさまざまな情報を、ＦＡＱ集（頻度の高い質問応答集）としてユーザサポート等のサイトに集め、参照・検索可能な形式で提供している。しかしながら、大量の質問応答集の中から、ユーザの所望する質問応答（以下、ＱＡと呼ぶ）を単純なキーワード検索や文字列検索で見つけることは難しく、ユーザは複数のキーワードを入れたり、何度も検索したり、候補として出力された膨大な量のＱＡを１つ１つ確認したりして、ようやく回答に辿り着く。このような問題を解決するために、特許文献１では、対話形式でユーザが探している情報に絞り込んでいくシステムを提案している。

特許文献１に記載のシステムは、ユーザの質問文を事例文照合辞書に登録されている事例文と照合して、その事例文に対応する次のシステム発話を得る。例えば、ユーザが「印刷」と入力した場合、事例文照合辞書中の事例文「印刷」と照合し、事例文「印刷」に対応するＦＡＱテーマの「印刷」を得る。各ＦＡＱテーマには、ＦＡＱ・選択肢データベースにおいて、次のシステム発話文（以下、メッセージと呼ぶ）が対応付けられている。ＦＡＱテーマ「印刷」には、「印刷のどんなことについてお知りになりたいですか？以下の中から選んで下さい。（１）特別な用紙に印刷したい。（２）印刷時にトラブルが起こった。…（以下省略）」というメッセージが対応付けられており、この文がユーザに提示される。ユーザは、システムが提示した選択肢から適切な回答を一つ選択すると、その選択肢が新たなユーザの質問文となり、再度、事例文照合辞書との照合を繰り返す。事例文照合辞書には、「印刷」といった曖昧な意味の事例文もあれば、「印刷時にトラブルが起こった」、「印刷された文字がおかしい」といった、より具体的な事例文もある。具体的な事例文では、ＱＡが特定できるので、選択肢ではなく、その特定されたＱＡが次のシステム発話文として対応付けられている。従って、ユーザの質問文やユーザが選択した選択肢が、詳細な内容を含む場合は、具体的な事例文と照合し、特定されたＱＡを提示して、処理が終了する。

上記（１）から（３）の理由から、特許文献１に記載の従来システムでは、一般的な文字列検索では膨大な量のＦＡＱがヒットしてしまうような短い入力文が入力された場合でも、対話（選択肢からなる次の質問）を通じて詳細な情報をユーザから引き出し、最終的にユーザが求めているＱＡに絞り込むことができる。

特開２００３−２２８５７５

しかし、特許文献１に記載の従来システムでは、次のような３つの課題を有する。

（１）事例文照合辞書及びＦＡＱ・選択肢データベースの構築方法、並びに、構築コストの課題
上記従来システムでは、ユーザ入力文を照合させるための事例文を事例文照合辞書として用意しなければならない。さらに、事例文に合った次のシステム発話文（選択肢）をＦＡＱ・選択肢データベースとして用意しなければならない。これら事例文照合辞書、ＦＡＱ・選択肢データベースのデータ量や品質が、システムの検索精度を左右する。例えば、ユーザの入力文と照合させる事例文が少ないと、次のシステムの発話を決めることができず、対話は終了する。また、ＦＡＱ・選択肢データベースの作成の際、検索対象となるＦＡＱ全体を考慮にいれなければ、最終回答にたどりつかない選択肢を作ってしまったり、逆にＱＡがあるのに、選択肢がないためにたどりつけなくなったりする可能性がある。しかしながら、検索対象となるＦＡＱ全体を考慮に入れて選択肢を作成するのは非常に面倒な作業となる。さらに、ＦＡＱに追加や修正が起こる場合には、その度に選択肢の見直しが必要となる。このように、上記従来システムには、事例文やＦＡＱ・選択肢データベースの構築やデータの追加・削除が容易でないという課題がある。

（２）対話順番の効率性、事例文照合のコンフリクトの課題
例えば、ユーザが「印刷された文字がおかしいというトラブル」と入力した場合、照合に用いる文は、「印刷時にトラブルが起こった」、「印刷された文字がおかしい」の２文である。この場合、「印刷された文字がおかしい」の方がより詳細な記述なので、後者を優先して照合すべきだが、従来システムには、優先度を決める仕組みがない。

ユーザの入力文は極めて多様であり、このような複数文の事例文照合のコンフリクトは常に起こることが予想されるが、これらを想定して辞書やデータベースを調整することは難しい。入力文の照合精度を上げるためには、多数のＱＡに関連する事例文を追加しなければならない。しかし、事例文を追加すればするほど、照合のコンフリクトは発生し易くなる。

（３）質問（選択肢）の融通性の課題
ユーザ入力文が「印刷」の場合の例を先述したが、この例において、仮にシステムが提示する選択肢の中に、該当する選択肢がない場合、そこで対話が終了してしまう。

そのため、データベースの構築コストが低い、データベースの変更にも容易に対応できる、ユーザに対して優先度が高い候補から提示可能で、ユーザが所望する検索対象データが得られるまで対話を継続できる、シナリオデータを生成する対話シナリオ生成システム及びプログラムや、そのように生成されたシナリオデータを適用した対話型検索システム及びプログラムが望まれている。

第１の本発明は、ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムで利用される上記シナリオデータを生成する対話シナリオ生成システムにおいて、（１）検索対象の個々のデータに対して、そのデータの特徴を示す属性とその属性値を対応付けた属性データ集合と、属性、属性値をクラスとして定義したクラスデータとを少なくとも読込むデータ読込手段と、（２）検索対象の個々のデータのそれぞれに対して、属性値を有する全ての属性について、属性とその属性値との対の組み合わせを求め、属性とその属性値との対の組み合わせ毎に、当該組み合わせに係る検索対象のデータの識別情報と、当該組み合わせに係る検索対象のデータの数とを得るデータ分類手段と、（３）検索対象のデータの数が１個の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、１個だけの上記検索対象のデータをユーザに提示させるシナリオデータを生成する第１分類シナリオ生成手段と、（４）検索対象のデータの数が２個以上ｘ個未満（但しｘは３以上の自然数）の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該データ数の上記検索対象のデータをユーザに選択させるように提示させるシナリオデータを生成する第２分類シナリオ生成手段と、（５）検索対象のデータの数がｘ個以上の属性とその属性値との対の組み合わせについて、当該組み合わせに係る検索対象のデータを、当該組み合わせに含まれていない属性と属性値との対の観点から整理し、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該組み合わせに含まれていない属性の属性値を選択候補としてユーザに選択させるように提示させる、検索対象のデータを絞り込むためのシナリオデータを生成する第３分類シナリオ生成手段とを有することを特徴とする。

第２の本発明は、ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムで利用される上記シナリオデータを生成する対話シナリオ生成プログラムであって、コンピュータを、（１）検索対象の個々のデータに対して、そのデータの特徴を示す属性とその属性値を対応付けた属性データ集合と、属性、属性値をクラスとして定義したクラスデータとを少なくとも読込むデータ読込手段と、（２）検索対象の個々のデータのそれぞれに対して、属性値を有する全ての属性について、属性とその属性値との対の組み合わせを求め、属性とその属性値との対の組み合わせ毎に、当該組み合わせに係る検索対象のデータの識別情報と、当該組み合わせに係る検索対象のデータの数とを得るデータ分類手段と、（３）検索対象のデータの数が１個の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、１個だけの上記検索対象のデータをユーザに提示させるシナリオデータを生成する第１分類シナリオ生成手段と、（４）検索対象のデータの数が２個以上ｘ個未満（但しｘは３以上の自然数）の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該データ数の上記検索対象のデータをユーザに選択させるように提示させるシナリオデータを生成する第２分類シナリオ生成手段と、（５）検索対象のデータの数がｘ個以上の属性とその属性値との対の組み合わせについて、当該組み合わせに係る検索対象のデータを、当該組み合わせに含まれていない属性と属性値との対の観点から整理し、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該組み合わせに含まれていない属性の属性値を選択候補としてユーザに選択させるように提示させる、検索対象のデータを絞り込むためのシナリオデータを生成する第３分類シナリオ生成手段として機能させることを特徴とする。

第３の本発明は、ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムにおいて、（１）第１の本発明の対話シナリオ生成システムと、（２）ユーザからの入力を取り込みと共に、ユーザへの出力を行う入出力手段と、（３）ユーザの入力を解析することによって、属性と属性値との対の組み合わせを求める意図解析手段と、（４）上記意図解析手段により得られた属性と属性値との対の組み合わせと、各シナリオデータに関連する属性と属性値の対の組み合わせと照合する条件照合手段と、（５）上記条件照合手段の結果から、最適なシナリオデータを選択するシナリオ選択手段と、（６）選択されたシナリオデータに基づいて、次のシステム発話をユーザに提示させる対話制御手段とを有することを特徴とする。

第４の本発明は、ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索プログラムであって、（１）第２の本発明の対話シナリオ生成プログラムを有すると共に、（２）コンピュータを、（２−１）ユーザからの入力を取り込みと共に、ユーザへの出力を行う入出力手段と、（２−２）ユーザの入力を解析することによって、属性と属性値との対の組み合わせを求める意図解析手段と、（２−３）上記意図解析手段により得られた属性と属性値との対の組み合わせと、各シナリオデータに関連する属性と属性値の対の組み合わせと照合する条件照合手段と、（２−４）上記条件照合手段の結果から、最適なシナリオデータを選択するシナリオ選択手段と、（２−５）選択されたシナリオデータに基づいて、次のシステム発話をユーザに提示させる対話制御手段として機能させることを特徴とする。

本発明によれば、データベースの構築コストが低い、データベースの変更にも容易に対応できる、ユーザに対して優先度が高い候補から提示可能で、ユーザが所望する検索対象データが得られるまで対話を継続できる、シナリオデータを生成する対話シナリオ生成システム及びプログラムを提供でき、また、そのように生成されたシナリオデータを適用した対話型検索システム及びプログラムを提供できる。

実施形態の対話型質問応答システム１０１のネットワーク上での位置を示す説明図である。 実施形態の対話型質問応答システム１０１の機能的な構成を示すブロック図である。 実施形態の対話シナリオ生成システム１１５の機能的な構成を示すブロック図である。 実施形態におけるクラス付ＦＡＱデータ１１６の一例を示す説明図である。 実施形態におけるクラスデータ１１７の一例を示す説明図である。 実施形態におけるシナリオデータ１１８の一例を示す説明図である。 実施形態の対話シナリオ生成システム１１５によるクラス辞書１１３及び条件付シナリオ辞書１１４の自動生成動作を示すフローチャートである。 図４に示したクラス付ＦＡＱデータ１１６における、属性＝属性値の全ての組み合わせの生成結果（データ構造）を示す説明図である。 図８に示した属性＝属性値の全ての組み合わせの生成結果を、属性＝属性値の組み合わせ毎に整理したｉｄリストおよびＱＡ数を示す説明図である。 ＱＡ数が１個の属性＝属性値の組み合わせについて生成された条件付シナリオのデータ構造を示す説明図である。 ＱＡ数が２以上ｘ未満の場合である属性＝属性値の組み合わせについて生成される条件付シナリオとクラスのデータ構造を示す説明図である。 ＱＡ数がｘ以上の場合である属性＝属性値の組み合わせについて、ｉｄリストの各ＱＡが持つ全ての属性＝属性値の組み合わせを取り出したデータ構造を示す説明図である。 ＱＡ数がｘ以上の場合である属性＝属性値の組み合わせについて、それ以外の属性からｘ個のＱＡを整理したリストのデータ構造を示す説明図である。 ＱＡ数がｘ以上の場合である属性＝属性値の組み合わせについて生成される条件付シナリオとクラスのデータ構造を示す説明図である。 実施形態の対話型質問応答システム１０１におけるユーザとの対話動作を示すフローチャートである。 実施形態の対話型質問応答システム１０１における対話の進行に伴って変化するユーザデータを示す説明図である。 実施形態の対話型質問応答システム１０１における各段階でのユーザ入力文とその意図解析結果とを示す説明図である。 実施形態の対話型質問応答システム１０１がユーザに提示する画面例を示す説明図である。 実施形態の対話型質問応答システム１０１が具体的な対話動作で利用する条件付シナリオとクラスのデータ構造を示す説明図である。

（Ａ）主たる実施形態
以下、本発明による対話型検索システム及びプログラム、並びに、対話シナリオ生成システム及びプログラムの一実施形態を、図面を参照しながら説明する。ここで、実施形態の対話型検索システムは、実施形態の対話シナリオ生成システムを包含しているものである。実施形態の対話型検索システムは、ユーザとシステムとの対話を通して、ユーザが所望するＦＡＱデータを探索できるようにした対話型質問応答システムである。

（Ａ−１）実施形態の構成
図１は、実施形態の対話型質問応答システム１０１のネットワーク上での位置を示す説明図である。

実施形態の対話型質問応答システム１０１は、Ｗｅｂサーバ３０３に接続されている。そのため、パーソナルコンピュータなどの通信機能を有する情報処理端末３０１は、インターネット３０２を介し、さらに、Ｗｅｂサーバ３０３経由で、対話型質問応答システム１０１と通信することができる。

例えば、ユーザは、情報処理端末３０１上のＷｅｂブラウザ等によって、入力情報を対話型質問応答システム１０１に与えることができる。ユーザの入力情報は、インターネット３０２を通り、Ｗｅｂサーバ３０３を経由して、対話型質問応答システム１０１の後述する入出力処理部１０２に渡される。逆に、対話型質問応答システム１０１からの出力情報は、後述する入出力処理部１０２からＷｅｂサーバ３０３、インターネット３０２を経由して、ユーザの端末３０１上のＷｅｂブラウザ等に出力される。

以下では、情報処理端末３０１及び対話型質問応答システム１０１間の通信において、インターネット３０２及びＷｅｂサーバ３０３を経由することの説明を省略する。

なお、対話型質問応答システム１０１及びＷｅｂサーバ３０３が融合されたシステムであっても良い。また、対話型質問応答システム１０１がインターネット３０２に直接接続したシステムであっても良い。

図２は、実施形態の対話型質問応答システム１０１の機能的な構成を示すブロック図である。対話型質問応答システム１０１は、専用装置として構成されても良く、また、パーソナルコンピュータなどのコンピュータに、対話型質問応答プログラムをインストールすることで構成されても良いものであるが、機能的には、図２で表すことができる。また、対話型質問応答システム１０１は、複数のコンピュータの分散処理で実現されるものであっても良い。さらには、対話シナリオ生成システム１１５として機能するコンピュータと、それ以外の部分として機能するコンピュータとが異なるものであっても良い。いずれにせよ、機能的には、図２で表すことができる。

対話型質問応答システム１０１は、入出力処理部１０２、対話制御部１０３、意図解析部１０４、ユーザデータ管理部１０５及びドメイン知識管理部１０７を有する。さらに、対話型質問応答システム１０１は、ユーザデータ（ユーザデータ格納部）１０６と、ドメイン知識データベース（ドメイン知識ＤＢ）１１１のデータを有する。ここで、ドメイン知識管理部１０７は、辞書引き部１０８、シナリオ選択部１０９及び条件照合部１１０を有する。また、ドメイン知識ＤＢ１１１は、形態素辞書１１２、クラス辞書１１３及び条件付シナリオ辞書１１４を有する。

各部の機能については、後述する動作説明の項で明らかにするが、その機能の概要を述べると以下の通りである。

入出力処理部１０２は、上述したように、ユーザが情報処理端末３０１へ入力した情報（以下、入力文と呼ぶ）を取り込むと共に、ユーザへの出力情報（以下、出力文と呼ぶ）を情報処理端末３０１へ出力するものである。なお、ユーザは、キーボードやマウスなどを使って、ユーザ入力文を入力しても良く、音声で入力文を入力しても良い。音声入力の場合、情報処理端末３０１が音声認識機能を備えていても良く、また、当該入出力処理部１０２が音声認識機能を備えていても良い。また、当該実施形態とは異なるが、検索対象の個々のデータのデータ量が少ないような場合であれば、ユーザへの出力にも音声を用いても良い。

また、ユーザが所望するＱＡを見つけ出すのにリアルタイム性が求められていない場合であれば、システムからユーザへの出力にも、ユーザからシステムへの入力にも、電子メールを適用しても良く、この場合、入出力処理部１０２は、電子メールの組立機能や電子メールの分解機能を持つことを要する。

対話制御部１０３は、システムとユーザとの対話を制御するものである。具体的には、対話制御部１０３は、入出力処理部１０２にシステム発話文を渡し、ユーザ入力文を受け取る。対話制御部１０３は、意図解析部１０４にユーザ入力文を渡し、解析結果を受け取る。対話制御部１０３は、ユーザデータ管理部１０５に解析結果を渡す。対話制御部１０３は、条件照合部１１０に命令を送り、シナリオ選択部１０９から、次のシステム発話用のシナリオを受け取る。

意図解析部１０４は、ユーザ入力文を対話制御部１０３から受け取り、ドメイン知識管理部１０７の辞書引き部１０８を通じて、形態素辞書１１２、クラス辞書１１３の情報を得て、ユーザ入力文を解析するものである。意図解析部１０４は、解析結果を対話制御部１０３に返す。

ユーザデータ管理部１０５は、対話制御部１０３から受け取った解析結果をユーザデータ１０６に格納する。

ドメイン知識管理部１０７における辞書引き部１０８は、意図解析部１０４からの命令により、ドメイン知識ＤＢ１１１の形態素辞書１１２とクラス辞書１１３を引くものである。

ドメイン知識管理部１０７における条件照合部１１０は、対話制御部１０３の命令によって、ユーザデータ１０６に格納されている情報と条件付シナリオ辞書１１４の情報を照合するものである。

ドメイン知識管理部１０７におけるシナリオ選択部１０９は、条件照合部１１０の結果を受け取り、次のシステム発話のためのシナリオを選択し、対話制御部１０３に渡すものである。

ユーザデータ１０６は、ユーザ入力文の解析結果によって得られる、ある属性についての属性値の情報が格納されている。

ドメイン知識ＤＢ１１１の形態素辞書１１２は、ユーザ入力文に対する形態素解析用の辞書である。

ドメイン知識ＤＢ１１１のクラス辞書１１３と条件付シナリオ辞書１１４は、対話シナリオ生成システム１１５によって自動生成されるユーザとの対話用の辞書である。なお、クラス辞書１１３は、ユーザ入力文を解析するためにも使用される。

対話シナリオ生成システム１１５は、クラス付ＦＡＱデータ１１６とクラスデータ１１７とシナリオデータ１１８を受け取り、条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３とを生成するものである。

ここで、クラス付ＦＡＱデータ１１６は、属性値（クラス）が付与されているＱＡ（質問応答）の集合からなるＦＡＱデータである（後述する図４参照）。クラスデータ１１７は、クラス間の関係、クラスの表記などを規定するデータである（後述する図５参照）。シナリオデータ１１８は、クラス付ＦＡＱデータ１１６やクラスデータ１１７から生成されるシナリオ以外で必要となるシナリオのデータである（後述する図６参照）。例えば、対話を開始した直後のシステム発話文や対話を終了させる際のシステム発話文などが、シナリオデータ１１８で規定されている。

図３は、対話シナリオ生成システム１１５における機能を整理して示す機能ブロック図である。対話シナリオ生成システム１１５は、コンピュータとそのコンピュータが実行するプログラムとして実現することができ、また、ＤＳＰや専用ＩＣチップとして実現することもできる。

対話シナリオ生成システム１１５は、データ読込み部１５０、ＦＡＱデータ分類部１５１、第１分類シナリオ生成部１５２、第２分類シナリオ生成部１５３、第３分類シナリオ生成部１５４及び生成シナリオ出力部１５５を有する。

各部の機能については、後述する動作説明の項で明らかにするが、その機能の概要を述べると以下の通りである。

データ読込み部１５０は、クラス付ＦＡＱデータ１１６、クラスデータ１１７、シナリオデータ１１８を読み込んで作業用エリアに格納するものである。データ読込み部１５０による読込みは、記録媒体からの読込みであっても良く、他の情報処理装置からのファイル転送などであっても良い。クラス付ＦＡＱデータ１１６、クラスデータ１１７、シナリオデータ１１８毎に、異なる記録媒体などから読み込むものであっても良い。

ＦＡＱデータ分類部１５１は、ＦＡＱデータに付与されている属性値（クラス）の全組み合わせを求め、組み合わせ毎に、候補となるＱＡとそのＱＡ数とを求めるものである。

第１分類シナリオ生成部１５２は、ＱＡ数が１個の属性値の組み合わせについて、条件（属性値の組み合わせ）付シナリオ辞書１１４に格納する内容を生成するものである。ユーザ入力文から得た、ユーザが所望しているＱＡに係る属性値の組み合わせが、ＱＡ数が１個の組み合わせであれば、そのＱＡをユーザに提示するほかなく、第１分類シナリオ生成部１５２は、このような観点から、条件付シナリオ辞書１１４に格納する内容を生成する。

第２分類シナリオ生成部１５３は、ＱＡ数が２以上ある数（ｘ；ｘは３以上の自然数）未満の属性値の組み合わせについて、条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３に格納する内容を生成するものである。ＱＡ数が２以上ある数（ｘ）未満の場合、全ＱＡの候補を選択肢とした１つの質問（システム発話文）をユーザに提示した場合、提示されたＱＡの中にユーザが所望するＱＡが含まれている可能性が高く、第２分類シナリオ生成部１５３は、このような観点から、条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３に格納する内容を生成する。

第３分類シナリオ生成部１５４は、ＱＡ数がｘ以上の属性値の組み合わせについて、条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３に格納する内容を生成するものである。ユーザ入力文から得た、ユーザが所望しているＱＡに係る属性値の組み合わせについて、ＱＡ数がｘ以上あるような場合は、ユーザ入力文が、ユーザの意図を読取り難い曖昧性が高い文になっている場合であり、このような場合に、全ＱＡの候補を選択肢とした１つの質問（システム発話文）をユーザに提示しても、ＱＡの候補にユーザが所望するものが入っていない可能性が高く、また、多くのＱＡの候補を一括提示すると、所望するＱＡが入っていたとしてもユーザが見落とす可能性が高い。そのため、ＱＡ数がｘ以上の属性値の組み合わせについては、ＱＡの候補を絞り込む手順が必要となる。第３分類シナリオ生成部１５４は、次にどの属性に関する質問をすればさらにＱＡが絞り込まれるかを予め捉え、最も絞り込まれる可能性が高い属性から順番に、その属性についての質問を定義した条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３の内容を生成する。

生成シナリオ出力部１５５は、第１分類シナリオ生成部１５２、第２分類シナリオ生成部１５３及び第３分類シナリオ生成部１５４によって生成された、条件付シナリオ辞書１１４とそれに連携するクラス辞書１１３の内容を出力するものである。生成シナリオ出力部１５５は、ドメイン知識ＤＢ１１１の条件付シナリオ辞書１１４及びクラス辞書１１３に直接書き込むものであっても良い。例えば、対話シナリオ生成システム１１５を構成している情報処理装置が、対話シナリオ生成システム１１５以外の対話型質問応答システム１０１の構成要素を搭載している情報処理装置と異なる場合であれば、生成シナリオ出力部１５５は、記録媒体に出力（記録）させたり、ファイル転送させたりするものとなる。

（Ａ−２）実施形態の動作
次に、実施形態の対話型質問応答システム１０１の動作を説明する。動作は、大きく２つに分かれる。１つは、対話シナリオ生成システム１１５の動作（クラス辞書１１３及び条件付シナリオ辞書１１４の自動生成に関する動作）であり、もう１つは、対話型質問応答システム１０１の対話時の動作（問い合わせ回答のためのシステム対話に関する動作）である。

（Ａ−２−１）対話シナリオ生成システム１１５の生成動作
以下では、対話シナリオ生成システム１１５が読み込むクラス付ＦＡＱデータ１１６、クラスデータ１１７、シナリオデータ１１８を順に説明した後、対話シナリオ生成システム１１５による生成動作を説明する。

図４は、クラス付ＦＡＱデータ１１６の一例を示す説明図である。なお、図４中（他の図面も同様）の「ＭａｉｌＰＩＡ」、「訳してねっと」、「ラダサーチ」はいずれも、本願出願人の登録商標である。

一般的なＦＡＱ集の各ＱＡ（質問文及び回答文）に対して、各ＱＡを分別するための属性を決め、かつ、各ＱＡに対して、属性値を付与したものがクラス付ＦＡＱデータ１１６である。

１つのＱＡデータは、質問文４０１、回答文４０２、複数の属性値４０３〜４１０からなると共に、他のＱＡデータと区別するための識別情報（ｉｄ）４１１が付与されている。図４の最上行に記載のように、各属性について、「属性（属性名）：その属性に関する質問シナリオ（システム発話文の一部となる）」が記述されている。図４の例では、属性は、「サービス名」、「問い合わせ目的」、「機能ＫＷ（ＫＷはキーワードを表している）」、「画面ＫＷ」、「データＫＷ」、「システム動作ＫＷ」、「ユーザ動作ＫＷ」、「しない・できないＫＷ」の８つである。属性「サービス名」についての「質問シナリオ」として、「どのサービスに関係するご質問でしょうか？以下からお選びください。」が記述されている。

例えば、ｉｄ＝１のクラス付ＱＡ（４１２）は、質問文「ＭＡＩＬＰＩＡとは何ですか？」、回答文「お気に入りのサイトやブログの更新情報をメールで受け取るサービスです。」というＱＡの本体に対し、属性「サービス名」について属性値「ＭａｉｌＰＩＡ」が付与され、属性「問い合わせ目的」について属性値「サービス名や用語について説明して欲しい」が付与されている。以下、「属性＝属性値」という形式で記述する。この場合であれば、サービス名＝ＭａｉｌＰＩＡ、問い合わせ目的＝サービス名や用語について説明して欲しい、と記述することとなる。なお、属性値は全ての属性について付与する必要はなく、そのＱＡに関係する属性に対してのみ属性値を付与する。

ＦＡＱデータに対する属性値の付与は、手動で行ったものであっても良く、また、質問文（若しくは回答文）を解析（形態素解析や構文解析など）して自動的に付与したものであっても良い。

図５は、クラスデータ１１７の一例を示す説明図である。図５における最上行はデータ項目を表している。

クラスは、クラス０、クラス１、クラス２、…のように、いくつでも階層的に（木構造で）定義できる。図５の例では、クラス０（５０１）、クラス１（５０２）の２つのレベルで定義している。例えば、「Ｒｏｏｔ」の下位ノードとして、「ユーザデータ」、「ＹＥＳＮＯ−ｏｋ」、「ＹＥＳＮＯ−ｍａｉｌ」がある。「ユーザデータ」の下位ノードとして、「問い合わせ目的」、「サービス名」、「機能ＫＷ（ＫＷはキーワードを表している）」、「画面ＫＷ」、「データＫＷ」、「システム動作ＫＷ」、「ユーザ動作ＫＷ」、「しない・できないＫＷ」がある。このように、クラス付ＦＡＱデータ１１６で定義された属性（例えば、サービス名）は、ユーザデータクラスの子クラスとして定義し、各属性の属性値（例えば、ＭａｉｌＰＩＡ）は、さらにその属性の子クラスとして定義している。それぞれのクラスは、標準形（ユーザに提示する際に使われる表現）５０３と、異表記（ユーザ入力文を認識する際に使われる表現）５０４、質問キュー（このクラスが回答であった場合の次のシナリオのシナリオｉｄ）５０５と、値セット（そのクラスがユーザから取得された場合にセットされるユーザデータの属性＝属性値）５０６を定義する。質問キュー５０５と値セット５０６には、対話時に、このクラスデータが取り出された際に、値がセットされることがある。また、図５における「＠」は、「ユーザ入力文の形態素解析時に使用されないこと」を表している。「＠」を付与するようにしたのは、上位クラスはユーザ入力文から認識する必要がないためである。

図６は、シナリオデータ１１８の一例を示す説明図である。図６における最上行もデータ項目を表している。

１つのシナリオデータは、条件６０１、シナリオｉｄ６０２、システム発話文６０３、回答タイプ６０４、ユーザ回答クラス６０５、質問キュー６０６から構成される。条件６０１は、そのシナリオが適用されるユーザデータの条件を記述する。シナリオｉｄ６０２は、シナリオを区別する識別情報である。シナリオ発話文６０３は、そのシナリオの適用時に、ユーザに提示される文である。回答タイプ６０４は、シナリオ提示時にユーザに求める回答のタイプである。回答タイプ６０４に「自由」がセットされている場合は、自由文での入力をユーザに促し、回答タイプ６０４に「選択肢」がセットされている場合は、選択肢をユーザに提示し、その中から最も適切な候補を選択させる。質問キュー６０６は、この次の質問文となる次のシナリオｉｄである。次の質問が固定的でなく、動的に決まる場合は、質問キューには何もセットされていない。

ユーザ回答クラス６０５は、ユーザ入力文を意図解析する際に用いるクラスである。セットされたクラスより下位のクラスが意図解析部１０４に利用されるが、回答タイプによってその利用方法が異なる。

回答タイプが「自由」の場合は、ユーザの入力は自由文である。この場合、ユーザ入力文の形態素解析時に下位のクラスが用いられ、入力文に含まれる下位のクラスの集合が意図解析結果となる。例えば、図６のｓｔａｒｔシナリオ６０９では、ユーザ回答クラスがユーザデータであるので、意図解析結果は、ユーザの入力文に含まれるユーザデータクラスより下位のクラスの集合となる。

一方、回答タイプが「選択肢」の場合は、下位のクラスがユーザに直接提示され、ユーザはその中から選択する。従って、意図解析部１０４は単にクラス辞書１１３から選択されたクラスを結果として出力する。例えば、図６のｓｏｒｒｙ−００１シナリオ６１０は回答タイプが「選択肢」であり、ユーザ回答クラスが「ＹＥＳＮＯ−ｍａｉｌ」である。この場合、図５の「ＹＥＳＮＯ−ｍａｉｌ」の子クラスの「ＹＥＳ−ｏｋ（標準形の「はい」が提示される）」と「ＹＥＳ−ｎｏ（標準形の「いいえ」が提示される）」が選択肢としてユーザに提示され、ユーザが選択したクラスが直接、意図解析結果となる。

対話シナリオ生成システム１１５に入力するシナリオデータ１１８は、上述したように、対話を開始した直後のシステム発話文や対話を終了させる際のシステム発話文やＦＱＡデータに依存しないで対話を展開させるシステム発話文などを規定しており、シナリオ辞書１１４に格納させる他のシナリオデータを、対話シナリオ生成システム１１５が生成する。

次に、対話シナリオ生成システム１１５が、クラス付ＦＡＱデータ１１６、クラスデータ１１７、シナリオデータ１１８を用いて、クラス辞書１１３及び条件付シナリオ辞書１１４を自動生成する動作を説明する。図７は、かかる生成動作を示すフローチャートである。

対話シナリオ生成システム１１５は起動されると、図７に示す処理を開始し、まず、クラス付ＦＡＱデータ１１６、クラスデータ１１７及びシナリオデータ１１８を読み込む（ステップ７０１）。次に、対話シナリオ生成システム１１５は、各ＱＡに、クラス付ＦＡＱデータ１１６に付与されている属性＝属性値の全組み合わせを生成する（ステップ７０２；後述する図８参照）。

さらに、対話シナリオ生成システム１１５は、属性＝属性値の組み合わせ毎のＱＡのｉｄリストと関連するＱＡ数のデータを得る（ステップ７０３；後述する図９参照）。

その後、対話シナリオ生成システム１１５は、全ての属性＝属性値の組み合わせについて生成処理が終了していないことを確認して（ステップ７０４）、１つの未生成の属性＝属性値の組み合わせを処理対象とする（ステップ７０５）。そして、対話シナリオ生成システム１１５は、その組み合わせが関連するＱＡ数を確認する（ステップ７０６）。

処理対象の属性＝属性値の組み合わせに関連するＱＡ数が１個の場合には、対話シナリオ生成システム１１５は、そのＱＡの質問文と回答文を直接提示するデータ（シナリオ）を生成する（ステップ７０７）。

処理対象の属性＝属性値の組み合わせに関連するＱＡ数が２以上ｘ未満の場合には、対話シナリオ生成システム１１５は、関連するＱＡの質問文を選択肢とするシナリオと各ＱＡの質問文に対応するシナリオと、これらシナリオと連携するクラスとを生成する（ステップ７０８）。

処理対象の属性＝属性値の組み合わせに関連するＱＡ数がｘ以上の場合には、２以上ｘ未満の場合のように候補となるＱＡの質問文を選択肢として提示するのではなく、候補を絞り込むための特別な質問を行うようにする。

対話シナリオ生成システム１１５は、まず、関連するＱＡのｉｄリストを取得し（ステップ７０９）、各ｉｄのＱＡがもつ全ての属性＝属性値の組み合わせから、現在対象としている属性＝属性値を除外した属性＝属性値を求める（ステップ７１０）。その属性の中で、２以上の関連するＱＡ数が最も高い属性から順に選択し、その属性がもつ属性値を選択肢としてシナリオや連携するクラスを生成し（ステップ７１１、７１２）、このような処理を、条件を満たす属性がなくなるまで繰り返す。

対話シナリオ生成システム１１５は、条件を満たす属性がなくなれば、直前に生成したシナリオの質問キューにｓｏｒｒｙ−００１（図６の符号６１０参照）をセットし（ステップ７１３）、次の属性＝属性値の組み合わせの処理（ステップ７０４）に移行する。

ステップ７０４〜７１３の処理ループを繰り返すことにより、全ての属性＝属性値の組み合わせについて生成処理が終了すると、対話シナリオ生成システム１１５は、上述した生成処理（ステップ７０７、７０８、７１２）で生成されたクラスのデータ構造や入力された図５に示すクラスデータをクラス辞書１１３に書き出すと共に（ステップ７１４）、生成されたシナリオのデータ構造や入力された図６に示すシナリオデータを、条件付シナリオ辞書１１４に書き出し（ステップ７１５）、図７に示す処理を終了する。

以下、対話シナリオ生成システム１１５による自動生成動作を、具体例を用いて説明する。

図８は、図４に示したクラス付ＦＡＱデータに対して、ステップ７０２を実行した場合における、属性＝属性値の全ての組み合わせの生成結果（データ構造）を示す説明図である。

各ＱＡ（のｉｄ）８０１毎に、質問文８０２、回答文８０３、属性＝属性値の全ての組み合わせ８０４がセットされる。

例えば、図４のｉｄ＝１のＱＡには、サービス名＝ＭａｉｌＰＩＡ、問い合わせ目的＝サービス名や用語を説明して欲しい、の２つの属性に関する属性値がセットされているので、図８のｉｄ＝１の行に記載のように、属性＝属性値の３（＝２^２−１）個の組み合わせ、すなわち、（１）サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい、（２）サービス名＝ＭａｉｌＰＩＡ、（３）問い合わせ目的＝サービス名や用語を説明して欲しい、がセットされる。ここで、「＆＆」は「且つ」を表している。

例えば、図４のｉｄ＝２のＱＡのように、３つの属性に関する属性値がセットされているＱＡであれば、属性＝属性値の組み合わせ数は７（＝２^３−１）個となり、７個の組み合わせがリストアップされることとなる。

以上のようにして、クラス付ＦＡＱデータに含まれている全てのＱＡに対してそれぞれ、属性＝属性値の全ての組み合わせを得ると、ステップ７０３の処理により、属性＝属性値の組み合わせからデータを整理し、ＱＡのｉｄリストとＱＡ数のデータを得る。図９は、属性＝属性値の組み合わせ毎のＱＡのｉｄリストの一例を示す説明図であり、図８に一部対応している。各属性＝属性値の組み合わせ９０１に対して、その組み合わせを持つｉｄリスト９０２と関連するＱＡ数（ｉｄの個数）９０３が得られる。

例えば、図８のｉｄ＝１のＱＡやｉｄ＝２のＱＡは、サービス名＝ＭａｉｌＰＩＡという属性＝属性値の組み合わせを有するので、サービス名＝ＭａｉｌＰＩＡという属性＝属性値の組み合わせのｉｄリストには、図９に示すように、ｉｄ＝１や２が含まれる。また例えば、図８のｉｄ＝１のＱＡは、サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい、という属性＝属性値の組み合わせを有するので、サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい、という属性＝属性値の組み合わせのｉｄリストには、図９に示すように、ｉｄ＝１が含まれる。

ここで、サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい、という属性＝属性値の組み合わせを有するＱＡが他になければ、サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい、という属性＝属性値の組み合わせに関連するＱＡ数は、図９に示すように、「１」となる。

このように、ＱＡ数が１個の場合は、ステップ７０７の処理により、唯一のＱＡの質問文と回答文をユーザに直接提示するデータを生成する。図９の例の場合、「サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」が処理対象となった場合、関連するＱＡ数が１個であり、関連する唯一のＱＡのｉｄが「１」であるので、このｉｄ＝１の質問文と回答文を、図８の質問文８０３、回答文８０４から取り出し、システム発話文（条件付シナリオ）とする。

図１０は、このようにして生成された条件付シナリオ（のデータ構造）を示す説明図である。条件付シナリオのデータ構造は、図６で示した読み込むシナリオデータのデータ構造と同じである。生成した条件付シナリオの条件１００１には、属性＝属性値の組み合わせそのものが記述され、図９の符号９０４の例であれば、「サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」が記述され、システム発話文１００３には、唯一のＱＡの質問文８０３及び回答文８０４を引用した文をセットする。システム発話文１００３における最初の文「お客様の回答が見つかりました。」と最後の文「お客様の問題は解消しましたか？」は、ＱＡ数のシステム発話文１００３として予め定まっている文であり、これら文に挟まれて、唯一のＱＡの質問文８０３及び回答文８０４が記述される。シナリオｉｄ１００２は、自動的かつ機械的に割り振られるものである。最後の文が「お客様の問題は解消しましたか？」という、「ＹＥＳ」、「ＮＯ」で回答させるものであるので、回答タイプ１００４には「選択肢」が記述され、ユーザ回答クラス１００５には「ＹＥＳＮＯ−ｏｋ」が記述される。

次に、ＱＡ数が２以上ｘ未満の場合について、ＱＡ数が２である図９の「ユーザ動作ＫＷ＝解除したい」９０７を例に説明する。仮に、ｘ＝３とすると、「ユーザ動作ＫＷ＝解除したい」は、関連するＱＡ数が２個であるので（符号９０９参照）、今回の場合分けを満たす。この場合には、関連する各ＱＡの質問文を選択肢とするシナリオと、各ＱＡの質問文に対応するシナリオが生成される。

図１１は、ＱＡ数が２以上ｘ未満の場合である属性＝属性値の組み合わせ「ユーザ動作ＫＷ＝解除したい」について生成される条件付シナリオとクラス（のデータ構造）を示す説明図であり、図１１（ａ）が条件付シナリオを示し、図１１（ｂ）がクラスを示している。

属性＝属性値の組み合わせ「ユーザ動作ＫＷ＝解除したい」に関連するＱＡのｉｄはｉｄ＝２と、ｉｄ＝５３とである。ｉｄ＝２のＱＡは図４に記載の通りである。図４では省略しているが、ｉｄ＝５３のＱＡにおける質問文は「訳してねっとの辞書登録を解除する方法は？」であり、回答文は「はい。ユーザ設定画面により、利用登録を解除することができます。」である。

ＱＡ数が２個の場合、２個のＱＡの質問文を選択肢としたシナリオと、各ＱＡにそれぞれ対応したシナリオとの、計３個のシナリオが生成される。

１つめのシナリオとして、条件には、属性＝属性値の組み合わせである「ユーザ動作ＫＷ＝解除したい」をセットし、システム発話文には、「お客様の回答が以下のように絞られました。該当する質問がありましたら以下からお選び下さい。」という文をセットし、回答タイプは、「選択肢」をセットし、ユーザ回答クラスには、自動的に付与したクラス名「ｆｏｃｕｓＣｌ−００１」をセットする。システム発話文の「お客様の回答が以下のように絞られました。該当する質問がありましたら以下からお選び下さい。」における「以下からお選び下さい。」の選択肢を、システム発話文に盛り込むことができるように、この場合にはクラスも生成する。

この際に生成されるクラスのデータ構造は、入力された図５に示すクラスデータのデータ構造と同じである。Ｒｏｏｔの子クラスとしてｆｏｃｕｓＣｌ−００１をセットし、ｆｏｃｕｓＣｌ−００１の子クラスとして、上記システム発話文の選択肢にそれぞれ対応するｆｏｃｕｓＣｌ−００１−ｉｄ２、ｆｏｃｕｓＣｌ−００１−ｉｄ５３、ｆｏｃｕｓＣｌ−００１−ｅｌｓｅをセットする。それぞれのクラスの標準形として、ｉｄ＝２のＱＡの質問文である「Ｑ：ＭＡＩＬＰＩＡの利用登録の解除はいつでも可能ですか？」と、ｉｄ＝５３のＱＡの質問文である「Ｑ：訳してねっとの辞書登録を解除する方法は？」と、「その他」をセットし、それぞれのクラスには、選択された選択肢に応じた次のシステム発話文に移行できるように、質問キューに、移行先のシナリオｉｄを表すｆｏｃｕｓＣｌ−００１＿ｉｄ２、ｆｏｃｕｓＣｌ−００１＿ｉｄ５３、ｅｌｓｅ−０１をセットする。ここで、シナリオｉｄのｆｏｃｕｓＣｌ−００１＿ｉｄ２、ｆｏｃｕｓＣｌ−００１＿ｉｄ５３は自動的に割り振るものである。

また、質問キューｆｏｃｕｓＣｌ−００１＿ｉｄ２、ｆｏｃｕｓＣｌ−００１＿ｉｄ５３にセットされたシナリオｉｄのシナリオを生成する。

ｉｄ＝２とｉｄ＝５３のＱＡの各質問文に対応するシナリオとして、条件はなく（但し、条件として上位クラスのシナリオと同じ「ユーザ動作ＫＷ＝解除したい」をセットするようにしても良い）、シナリオｉｄを、ｆｏｃｕｓＣｌ−００１＿ｉｄ２、ｆｏｃｕｓＣｌ−００１＿ｉｄ１０とする。システム発話文は、ＱＡの質問文及び回答文を引用した文をセットし、回答タイプには「選択肢」を、ユーザ回答クラスには「ＹＥＳＮＯ−ｏｋ」をセットする。なお、シナリオｉｄがｅｌｓｅ−０１に対応するシナリオは、図６に示す入力されたシナリオデータ１１８に含まれている（符号６１２参照）。

最後に、関連するＱＡ数がｘ以上の場合（ｘ＝３のときは３以上の場合）について、具体例を説明する。図９の属性＝属性値の組み合わせ「問合せ目的＝サービス名や用語を説明して欲しい」（９１０）の例を用いて、具体的に説明する。

まず、属性＝属性値の組み合わせ「問合せ目的＝サービス名や用語を説明して欲しい」のｉｄリスト（ｉｄ＝１、ｉｄ＝２０、ｉｄ＝５０）の各ＱＡが持つ全ての属性＝属性値の組み合わせを、ｉｄ毎の属性＝属性値の組み合わせのリスト（図８）から得る（ステップ７０９）。図８の場合、かかる処理を考慮し、全ての属性＝属性値の組み合わせを、それぞれのリストの先頭行（８０５、８０６、８０７）に記載している。これらの先頭行のみを取り出したデータ構造を図１２に示している。

次に、現在対象となっている属性＝属性値の組み合わせ「問合せ目的＝サービス名や用語を説明して欲しい」以外の属性を、ｉｄ毎の全ての属性＝属性値の組み合わせリスト（図１２）から取り出し、その属性がもつ属性値をリスト化する（ステップ７１０）。図１３は、その結果を示している。各属性に対して、その属性に関するＱＡ数とその属性値がセットされる。

ｉｄ＝１、ｉｄ＝２０、ｉｄ＝５０の各ＱＡは、現在対象となっている属性＝属性値の組み合わせ「問合せ目的＝サービス名や用語を説明して欲しい」以外の属性として、「サービス名」を有するので、この属性「サービス名」が取り出され、ＱＡ数として３がセットされると共に、ｉｄ＝１のＱＡにおけるサービス名の属性値「ＭａｉｌＰＩＡ」と、ｉｄ＝２０のＱＡにおけるサービス名の属性値「訳してねっと」と、ｉｄ＝５０のＱＡにおけるサービス名の属性値「ラダサーチ」とがセットされる。

また、ｉｄ＝２０、ｉｄ＝５０の各ＱＡは、現在対象となっている属性＝属性値の組み合わせ「問合せ目的＝サービス名や用語を説明して欲しい」以外の属性として、「機能ＫＷ」を有するので、この属性「機能ＫＷ」が取り出され、ＱＡ数として２がセットされると共に、ｉｄ＝２０のＱＡにおける機能ＫＷの属性値「辞書登録」と、ｉｄ＝５０のＱＡにおける機能ＫＷの属性値「対話制御」とがセットされる。

なお、処理対象以外の属性をリスト化する際に、ＱＡ数が１の属性は、リストから排除するようにしても良い。後述するステップ７１１の処理で、ＱＡ数が１の属性は除外されるからである。これは、ＱＡ数が１の属性はユーザの意図の絞り込みにほとんど機能しないためである。

処理対象以外の属性をリスト化すると、次に、関連するＱＡ数が最も多い他の属性を選択し（ステップ７１１）、その属性がもつ属性値を選択肢として質問する条件付シナリオとそれに連携するクラスデータを生成する（ステップ７１２）。

属性「サービス名」と「機能ＫＷ」とではＱＡ数がそれぞれ、３個と２個であるので、まず、ＱＡ数が３個である属性「サービス名」が選択され、属性値として、「ＭａｉｌＰＩＡ」、「訳してねっと」、「ラダサーチ」の３つを選択肢として含むシナリオを生成する。このとき、生成される条件付シナリオのデータ構造を図１４（ａ）の上の行１４０１ａに、クラスデータのデータ構造を図１４（ｂ）の上の行１４０１ｂに示している。

条件付シナリオ１４０１ａは、条件には、処理対象の属性＝属性値の組み合わせ「問い合わせ目的＝サービス名や用語を説明して欲しい」がセットされ、システム発話文には、ステップ７１２の処理で生成されるシナリオの第１行目に含まれることが決まっている定形文「お客様のご質問の候補がｙ（ここには、絞込み用の属性「サービス名」のＱＡ数、今の例では３が挿入される）件あります。」と、今回の絞込み用の属性「サービス名」について定まっている質問文（質問シナリオ）との合成文が用いられる。図４について説明したように、各属性についての質問シナリオは、図４の最上段の後半に記載されている。属性「サービス名」の質問シナリオは、「どのサービスに関係するご質問でしょうか？以下からお選びください。」である（符号４０３参照）。条件付シナリオ１４０１ａの回答タイプには「選択肢」がセットされ、ユーザ回答クラスには、自動的に付与されたクラス名「ｃｈｏｉｃｅＣｌ−００８」がセットされる。

クラスデータ１４０１ｂは、Ｒｏｏｔの子クラスとしてｃｈｏｉｃｅＣｌ−００８をセットし、ｃｈｏｉｃｅＣｌ−００８の子クラスとして、選択肢用のｃｈｏｉｃｅＣｌ−００８＿００１、ｃｈｏｉｃｅＣｌ−００８＿００２、ｃｈｏｉｃｅＣｌ−００８＿００３、ｃｈｏｉｃｅＣｌ−００８＿００４をセットする。それぞれの標準形には、３つの属性値「ＭａｉｌＰＩＡ」、「訳してねっと」、「ラダサーチ」と、これら属性値がユーザの選択対象とならない場合を考慮した「この質問をスキップ」をセットし、３つの属性値「ＭａｉｌＰＩＡ」、「訳してねっと」、「ラダサーチ」に係る子クラスｃｈｏｉｃｅＣｌ−００８＿００１、ｃｈｏｉｃｅＣｌ−００８＿００２、ｃｈｏｉｃｅＣｌ−００８＿００３に対応する値セットには、対話時において、ユーザデータ１０６にセットするクラスを、属性＝属性値の形式でセットする。これは、例えば、仮に、ユーザが選択肢「ＭａｉｌＰＩＡ」を選択した場合に、「ユーザデータのサービス名にＭａｉｌＰＩＡをセットせよ」という命令を意味する。

このような条件付シナリオとそれに連携するクラスデータを生成する処理（（ステップ７１１、７１２）を、対象以外の属性の属性値リストの取得処理（ステップ７１０）で取得した他の属性に対して繰り返し行う。

図１３の例では、属性「機能ＫＷ」もステップ７１１の生成条件を満たすので、属性「サービス名」と同様にシナリオ及びクラスデータを生成する。生成処理の詳細は省略するが、生成される条件付シナリオは図１４（ａ）の下の行１４０２ａとなり、クラスデータは図１４（ｂ）の下の行１４０２ｂとなる。

属性「機能ＫＷ」についての生成が終了すると、対象以外の属性の属性値リストに未処理の属性が残っていない。そのため、繰り返し処理を終了する。このように生成条件を満たす属性がなくなれば、直前に生成したシナリオの質問キューに「ｓｏｒｒｙ−００１」をセットし（ステップ７１３）、次の属性＝属性値の組み合わせの処理に移行する（ステップ７０４）。

上記の生成処理で生成されたシナリオにおける選択肢「この質問をスキップ」は、絞込み用の次のシナリオにスキップさせることを表しており、スキップして到達する最後のシナリオは、ステップ７１１及び７１２の繰返しループで最後に生成されたシナリオである。最後に生成されたシナリオでも、選択肢「この質問をスキップ」が選択された場合を考慮した何の手立ても行っていなければ、対話は中断されてしまう。そのため、図６に示した入力されたシナリオデータ１１８の中に、シナリオｉｄが「ｓｏｒｒｙ−００１」であってシステム発話文が「申し訳ございません。お客様のご質問に関する回答をみつけることはできません。メールでの回答を希望しますか？」を用意しておいている。

（Ａ−２−２）対話型質問応答システム１０１の対話動作
次に、実施形態の対話型質問応答システム１０１におけるユーザとの対話動作を、図１５のフローチャートを参照しながら説明する。

ユーザが情報処理端末３０１に対して対話開始ボタンを押す等により、開始命令が入出力処理部１０２から対話制御部１０３に渡される。対話制御部１０３は、ドメイン知識管理部１０７のシナリオ選択部１０９を通じて、条件付シナリオ辞書１１４から、シナリオｉｄが「ｓｔａｒｔ」の開始シナリオを取り出し（ステップ１５０１）、そのシステム発話文「お客様のご質問を入力してください。」が入出力処理部１０２を通じて情報処理端末３０１に提示される（ステップ１５０２）。

その一方、ｓｔａｒｔシナリオのユーザ回答クラスが「ユーザデータ」クラスであるので、クラス辞書１１３からユーザデータの下位クラス（問い合わせ目的、サービス名、機能ＫＷ、データＫＷ、システム動作ＫＷ、ユーザ動作ＫＷ、しない・できないＫＷ）を取り出して、ユーザデータ管理部１０５に渡し、ユーザデータ管理部１０５は、各クラスをユーザデータの属性としてセットする（ステップ１５０３）。

システム発話文の「お客様のご質問を入力してください。」に対して、ユーザが入力文を入力し、入出力処理部１０２がその入力文を受け取ると、対話制御部１０３を介して、意図解析部１０４に渡す（ステップ１５０４）。その際、シナリオ質問文のユーザ回答クラスである「ユーザデータ」も同時に意図解析部１０４に渡す。意図解析部１０４は、形態素辞書１１２とクラス辞書１１３を引くことによって、形態素解析を行い、「ユーザデータ」クラスより下位に定義されているクラスを、対話制御部１０３を介してユーザデータ管理部１０５に渡す（ステップ１５０５）。そのようなクラスが存在しないこともあり得る。ユーザデータ管理部１０５は、「ユーザデータ」クラスより下位に定義されているクラスがあるか否かを判別し（ステップ１５０６）、そのようなクラスがあれば、既にセットされている属性と同じクラス名を親クラスにもつクラスを属性値としてセットする（ステップ１５０７）。

さらに、対話制御部１０３は、現在利用中のシナリオの質問キューに値がセットされているか否かを判別し（ステップ１５０８）、値がセットされていれば、質問キューにセットされているシナリオｉｄのシナリオを次のシナリオとして選択する（ステップ１５１０）。これに対して、質問キューにシナリオｉｄがセットされていなければ、条件照合部１１０に命令を送り、条件照合部１１０は、ユーザデータを読み込み、ユーザデータと条件付シナリオ辞書１１４にセットされている条件を照合させ、照合結果をシナリオ選択部１０９に渡し（ステップ１５０９）、シナリオ選択部１０９は、最も数多くマッチするシナリオｉｄを、条件付シナリオ辞書１１４から選び、対話制御部１０３に渡す（ステップ１５１０）。

対話制御部１０３は、次のシナリオに係る応答文を、入出力処理部１０２を通じて情報処理端末３０１に提示する（ステップ１５１１）。対話制御部１０３は、シナリオｉｄが「ｅｎｄ」か否かを判別し（ステップ１５１２）、「ｅｎｄ」でなければ、ユーザ入力文の取込みステップ１５２４に戻り、「ｅｎｄ」であれば対話処理を終了する。

以下では、実施形態の対話型質問応答システム１０１におけるユーザとの対話動作を、２つの具体例を用いて説明する。第１の具体例は、ユーザの質問内容が明確な場合であり、第２の具体例は、ユーザの質問内容が不明瞭な場合である。

（Ａ−２−２−１）対話型質問応答システム１０１の対話動作の第１具体例
以下では、当初のシステム発話文「お客様のご質問を入力してください。」の提示に対して、ユーザが「メールピアとは何ですか？」と入力した場合を説明する。なお、ステップ１５０１〜１５０３の処理は上述した通りである。ステップ１５０２でセットされたユーザデータ１０６は、ｓｔａｒｔシナリオのユーザ回答クラスが「ユーザデータ」クラスであるので、クラス辞書１１３からユーザデータの下位クラス（問い合わせ目的、サービス名、機能ＫＷ、データＫＷ、システム動作ＫＷ、ユーザ動作ＫＷ、しない・できないＫＷ）を取り出したものとなり、図１６（ａ）に示すようになるが、この段階では、全ての属性について、属性値が空のものである。

入出力処理部１０２は、ユーザ入力文「メールピアは何ですか」を受け取り、対話制御部１０３を介して、意図解析部１０４に渡し、その際、シナリオ質問文のユーザ回答クラスである「ユーザデータ」も同時に意図解析部１０４に渡す（ステップ１５０４）。意図解析部１０４は、形態素辞書１１２とクラス辞書１１３を引くことによって、形態素解析を行い、「ユーザデータ」クラスより下位に定義されているクラスを、対話制御部１０３を介してユーザデータ管理部１０５に渡す。

図１７（ａ）に、ユーザ入力文「メールピアは何ですか」についての意図解析結果を示す。２つの出現形への分割は形態素解析による。意図解析結果の「メールピア」の部分については、図５のクラスデータにおけるクラス０が「サービス名」である中の１行目のクラスデータから、「標準形」、「親クラス」、「クラス名」のデータが得られ、ユーザ回答クラスの「ユーザデータ」は、このユーザ入力文が入力される前に提示された、シナリオｉｄが「ｓｔａｒｔ」のシステム発話文のユーザ回答クラスの内容である。意図解析結果の「何ですか」の部分については、図５のクラスデータにおけるクラス０が「問い合わせ目的」である中の１行目のクラスデータから、「標準形」、「親クラス」、「クラス名」のデータが得られ、ユーザ回答クラスの「ユーザデータ」は、このユーザ入力文が入力される前に提示された、シナリオｉｄが「ｓｔａｒｔ」のシステム発話文のユーザ回答クラスの内容である。

ユーザデータ管理部１０５は、既にユーザデータにセットされている属性と同じクラス名を、意図解析結果の親クラスにもつクラスを属性値としてセットする（ステップ１５０７）。

上記の例では、「ＭａｉｌＰＩＡ」をサービス名の属性値と、「サービス名や用語について説明して欲しい」を問い合わせ目的の属性値としてセットする。これにより、セット後のユーザデータは、図１６（ｂ）に示すようになる。

現在利用中のｓｔａｒｔシナリオの質問キューには値がセットされていないので、対話制御部１０３は、条件照合部１１０に命令を送り、条件照合部１１０は、その時点のユーザデータ１０６を読み込み、ユーザデータ１０６と条件付シナリオ辞書１１４にセットされている条件とを照合させ、照合結果をシナリオ選択部１０９に渡す（ステップ１５０９）。

シナリオ選択部１０９は、最も数多くマッチするシナリオｉｄを、条件付シナリオ辞書１１４から選び、対話制御部１０３に渡す（ステップ１５０９）。

上記の例の場合、条件付シナリオ辞書１１４に記憶された図１０に示した生成シナリオの条件「サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」が、ユーザデータ１０６に完全マッチするので（ステップ１５０９）、条件照合部１１０からこの照合結果が与えられたシナリオ選択部１０９は、その条件が有するシナリオｉｄが「ａｎｓｗｅｒ−００１」のシナリオを対話制御部１０３に渡し（ステップ１５１０）、対話制御部１０３は、システム発話文と選択肢を、入出力処理部１０２を介して、ユーザに提示する（ステップ１５１１）。

シナリオｉｄが「ａｎｓｗｅｒ−００１」のシナリオの回答タイプが「選択肢」でユーザ回答クラスが「ＹＥＳＮＯ−ｏｋ」であるので、回答クラスの子クラスの「ＹＥＳ−ｏｋ」、「ＮＯ−ｏｋ」の各標準形「はい」、「いいえ」（図５の符号５０７参照）が選択肢としてユーザに提示される。

シナリオｉｄが「ａｎｓｗｅｒ−００１」のシナリオをユーザに提示した画面例を図１８（ａ）に示す。図１８（ａ）〜（ｅ）は選択肢をラジオボタンで選択させるものを示しているが、選択肢の指示方法はこれに限定されず、反転表示などのカーソルで選択させるものであっても良い。

シナリオｉｄが「ａｎｓｗｅｒ−００１」のシナリオは、質問キューに「ｅｎｄ」がセットされていないので、対話制御部１０３は処理を終了せず（ステップ１５１２）、選択肢「はい」か「いいえ」のどちらをユーザが選択したかを取り込む（ステップ１５０４）。

ユーザが「はい」を選択した場合には、「はい」のクラス名「ＹＥＳ−ｏｋ」が、入出力処理部１０２、対話制御部１０３を通じて、意図解析部１０４に渡される（ステップ１５０４）。ユーザ回答タイプが「選択肢の選択」に係るタイプの場合、意図解析部１０４は、形態素辞書１１２に対する辞書引きを実行せず、「ＹＥＳ−ｏｋ」のクラスデータ（図５の下から５行目のデータ）を、意図解析結果として対話制御部１０３に直接渡す（ステップ１５０５）。図１７（ｂ）は、この場合の意図解析結果を示している。

この結果にはユーザデータはないので、ユーザデータは格納されない（ステップ１５０６）。但し、意図解析部１０４からの結果に質問キューがセットされているので（ステップ１５０８）、質問キューにセットされているシナリオｉｄが「ｅｎｄ」のシナリオ（図６符号６１１参照）が次のシナリオとして選択され（ステップ１５１）、シナリオ発話文の「ありがとうございました。」を入出力処理部１０２を通じて情報処理端末３０１に出力する（ステップ１５１１）。

このシナリオのシナリオｉｄは「ｅｎｄ」なので、対話型質問応答システム１０１は一連の処理が終了する（ステップ１５１２）。

（Ａ−２−２−１）対話型質問応答システム１０１の対話動作の第１具体例
次に、ユーザの最初の質問（ユーザ入力文）が不明瞭な場合について、対話型質問応答システム１０１の対話動作を具体例を挙げて説明する。以下では、当初のシステム発話文「お客様のご質問を入力してください。」の提示に対して、ユーザが「用語がわからない」と入力した場合を説明する。なお、ステップ１５０１〜１５０３の処理は上述した通りであるので、ステップ１５０４によるユーザ入力文の入力処理から説明する。

入出力処理部１０２は、ユーザ入力文「用語がわからない」を受け取り、対話制御部１０３を介して、意図解析部１０４に渡す（ステップ１５０４）。意図解析部１０４は、形態素辞書１１２とクラス辞書１１３を引くことによって、形態素解析を行い、「ユーザデータ」クラスより下位に定義されているクラスを、対話制御部１０３を介してユーザデータ管理部１０５に渡す（ステップ１５０５）。

図１７（ｃ）は、ユーザ入力文「用語がわからない」に対する意図解析結果を示している。形態素解析による「用語」が、図５のクラスデータにおけるクラス０が「問い合わせ目的」である中の１行目のクラスデータの異表記に定義されていることから、この１行目のクラスデータにおける「標準形」、「親クラス」、「クラス名」のデータが意図解析結果に含まれ、ユーザ回答クラスの「ユーザデータ」は、このユーザ入力文が入力される前に提示された、シナリオｉｄが「ｓｔａｒｔ」のシステム発話文のユーザ回答クラスの内容である。

ユーザデータ管理部１０５は、既にセットされている属性と同じクラス名を親クラスにもつクラスを属性値としてユーザデータ１１６にセットする（ステップ１５０７）。上記の例では、「サービス名や用語について説明して欲しい」を問い合わせ目的の属性値としてセットする（図１６（ｃ）参照）。

この意図解析結果には質問キューがないので（ステップ１５０８）、対話制御部１０３は、条件照合部１１０に命令を送り、条件照合部１１０は、ユーザデータ１１６を読み込み、ユーザデータ１１６と条件付シナリオ辞書１１４にセットされているシナリオの条件を照合させ、照合結果をシナリオ選択部１０９に渡す（ステップ１５０９）。シナリオ選択部１０９は、最も数多くマッチするシナリオｉｄのシナリオを、条件付シナリオ辞書１１４から選び、対話制御部１０３に渡す（ステップ１５１０）。

上記の例の場合、ユーザデータ１１６の属性値に対し、図１４（ａ）の条件付シナリオの条件「問い合わせ目的＝サービス名や用語を説明して欲しい」が完全マッチする（ステップ１５０９）。この場合、条件がユーザデータ１１６にマッチするシナリオは、図１４（ａ）に示すように、シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオと、シナリオｉｄが「ｃｈｏｉｃｅ−００９」のシナリオとがある。

シナリオ選択部１０９は、ユーザデータ１１６に合致する条件を有する１つのシナリオを選択して対話制御部１０３に渡す（ステップ１５１０）。図１４（ａ）に示すように、シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオと、シナリオｉｄが「ｃｈｏｉｃｅ−００９」のシナリオとの２つのシナリオがマッチする場合、シナリオ選択部１０９は、シナリオｉｄにおける枝番が若い方のシナリオを選択する。この例であれば、シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオを選択する。

上述した対話シナリオ生成システム１１５の生成動作から明らかなように、シナリオｉｄにおける枝番が若い方のシナリオの方が、ユーザの意図を絞り込める可能性が高いシナリオ（選択肢が多いシナリオ）になっているためである。

シナリオ選択部１０９は、シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオを対話制御部１０３に渡し（ステップ１５１０）、対話制御部１０３は、システム発話文と選択肢を、入出力処理部１０２を介して、ユーザに提示する（ステップ１５１１）。

シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオの回答タイプが選択肢であるので、回答クラス「ｃｈｏｉｃｅ−００８」の子クラス「ｃｈｏｉｃｅ−００８＿００１」、「ｃｈｏｉｃｅ−００８＿００２」、「ｃｈｏｉｃｅ−００８＿００３」、「ｃｈｏｉｃｅ−００８＿００４」のそれぞれに係る各標準形「ＭａｉｌＰＩＡ」、「訳してねっと」、「ラダサーチ」、「この質問をスキップ」が選択肢として提示される（ステップ１５１１）。この際にユーザに提示された画面例を図１８（ｂ）に示している。

シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオは、質問キューに「ｅｎｄ」がセットされていないため（ステップ１５１２）、処理を終了しない。

次に、図１８（ｂ）の画面中の選択肢の中から、ユーザが「ＭａｉｌＰＩＡ」を選択した場合の動作は説明する。

選択肢「ＭａｉｌＰＩＡ」を選択すると、「ＭａｉｌＰＩＡ」のクラス名「ｃｈｏｉｃｅ−００８＿００１」が、入出力処理部１０２、対話制御部１０３を通じて、意図解析部１０４に渡される（ステップ１５０４）。意図解析部１０４は、回答タイプが「選択肢」であるため、クラス辞書１１３を引き、そのクラスデータを意図解析結果として対話制御部１０３に渡す（ステップ１５０５）。

このときの意図解析結果を図１７（ｄ）に示している。クラス名「ｃｈｏｉｃｅ−００８＿００１」のクラスデータにおける値セットには、図１４（ｂ）に示すように、「サービス名＝ＭａｉｌＰＩＡ」が記述されているので、意図解析結果の値セットにも、「サービス名＝ＭａｉｌＰＩＡ」が含まれる。「サービス名」は、ユーザデータクラスの下位であるため、対話制御部１０３は、「サービス名＝ＭａｉｌＰＩＡ」をユーザデータ管理部１０５に渡し、ユーザデータ管理部１０５は、ユーザデータの属性「サービス名」に「ＭａｉｌＰＩＡ」をセットする（ステップ１５０７）。この結果、ユーザデータ１１６は、ユーザ入力文「メールピアとは何ですか？」の処理後を示している上述した図１６（ｂ）と同じ結果、「サービス名＝ＭａｉｌＰＩＡ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」となる。

そのため、これ以降の動作は、ユーザ入力文「メールピアとは何ですか？」が入力された上述した第１具体例の場合と同様となり、以下の動作の説明は省略する。

詳述は避けるが、図１８（ｂ）の画面中の選択肢の中から、「訳してねっと」が選択されたときには、ユーザデータ１１６が「サービス名＝訳してねっと＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」となり、これに最も合致する条件を有する条件付シナリオが、次のシナリオとして選択されることになる。同様に、図１８（ｂ）の画面中の選択肢の中から、「ラダサーチ」、が選択されたときには、ユーザデータ１１６が「サービス名＝ラダサーチ＆＆問い合わせ目的＝サービス名や用語を説明して欲しい」となり、これに最も合致する条件を有する条件付シナリオが、次のシナリオとして選択されることになる。

次に、図１８（ｂ）の画面中の選択肢の中から、ユーザが「この質問をスキップ」を選択した場合の動作を説明する。

ユーザが「この質問をスキップ」を選択すると、「この質問をスキップ」のクラス名「ｃｈｏｉｃｅ−００８＿００４」が、入出力処理部１０２、対話制御部１０３を通じて、意図解析部１０４に渡される（ステップ１５０４）。意図解析部１０４は、回答タイプが「選択肢」であるため、クラス辞書１１３を引き、そのクラスデータを意図解析結果として対話制御部１０３に渡す（ステップ１５０５）。クラスデータが図１４（ｂ）の符号１４０１ｂに示すようなものであるので、この際の意図解析結果は図１７（ｅ）に示すようになる。

この場合、クラス名がユーザデータでなく、かつ、値セットにおいてもユーザデータへの値セットがないため、ユーザデータ１１６には何もセットされず、また、質問キューも空であるので、条件照合処理を行う（ステップ１５０９）。その条件照合時のユーザデータ１１６は、ユーザデータに対する変更が実行されていないため、前回と同じユーザデータである。すなわち、図１６（ｃ）に示すユーザデータである。そのため、条件照合部１１０による照合結果は、図１４（ａ）に示す条件付シナリオとなる。

但し、シナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオは既にユーザに提示しているため、このときには、シナリオｉｄが「ｃｈｏｉｃｅ−００９」のシナリオがシナリオ選択処理１０９で選択され（ステップ１５１０）、対話制御部１０３は、そのシステム発話文を、入出力処理部１０２を通じてユーザに出力する（ステップ１５１１）。図１９（ｃ）は、シナリオｉｄが「ｃｈｏｉｃｅ−００９」のシナリオが選択されてユーザに提示された画面例を示している。提示画面に、選択肢を含める処理は、上述したシナリオｉｄが「ｃｈｏｉｃｅ−００８」のシナリオが選択した場合と同様であるので、その説明は省略する。

図１９（ｃ）の提示画面の選択肢の中から、ユーザが「辞書登録」を選択したとする。このとき、「辞書登録」のクラス名「ｃｈｏｉｃｅ−００９＿００１」が、入出力処理部１０２、対話制御部１０３を通じて、意図解析部１０４に渡される（ステップ１５０４）。意図解析部１０４は、回答タイプが選択肢であるため、クラス辞書１１３を引き、そのクラスデータを意図解析結果として対話制御部１０３に渡す（ステップ１５０５）。

クラス名「ｃｈｏｉｃｅ−００９＿００１」を含むクラスデータにおける値セットには、図１４（ｂ）に示すように、「機能ＫＷ＝辞書登録」が記述されているので、意図解析結果の値セットにも「機能ＫＷ＝辞書登録」が記述され、属性「機能ＫＷ」は、ユーザデータクラスの下位であるため、対話制御部１０３は、「機能ＫＷ＝辞書登録」をユーザデータ管理部１０５に渡し、ユーザデータ管理部１０５は、ユーザデータ１１６の属性「機能ＫＷ」に「辞書登録」をセットする（ステップ１５０７）。この結果、ユーザデータ１１６は、図１６（ｄ）に示すようになる。すなわち、ユーザデータ１１６は「問い合わせ目的＝サービス名や用語を説明して欲しい＆＆機能ＫＷ＝辞書登録」となる。

この意図解析結果には質問キューが記述されていないので、対話制御部１０３は、条件照合部１１０に命令を送り、条件照合部１１０は、ユーザデータ１１６を読み込み、ユーザデータ１１６と条件付シナリオ辞書１１４にセットされている条件を照合し、照合結果をシナリオ選択部１０９に渡す（ステップ１５０９）。シナリオ選択部１０９は、最も数多くマッチするシナリオを、条件付シナリオ辞書１１４から選び、対話制御部１０３に渡す（ステップ１５１０）。

生成処理では言及しなかったが、図１９に示すような条件付シナリオ及びクラスデータが生成され、それぞれ、条件付シナリオ辞書１１４とクラス辞書１１５とに記憶されていたとする。

この場合、図１９の１９０１ａの条件付シナリオの条件「問い合わせ目的＝サービス名や用語を説明して欲しい＆＆機能ＫＷ＝辞書登録」がユーザデータ１１６に完全マッチする（ステップ１５０９）。シナリオ選択部１０９は、その条件をもつシナリオｉｄが「ｆｏｃｕｓＣｌ−０２０」のシナリオを対話制御部１０３に渡し（ステップ１５１０）、対話制御部１０３は、システム発話文と選択肢を、入出力処理部１０２を介して、ユーザに提示する（ステップ１５１１）。

この場合のユーザへの提示画面は、図１８（ｄ）に示すようなものとなる。ユーザが、選択肢「Ｑ：辞書登録では何かできますか？」を選択すると、その選択肢に係るクラス名「ｆｏｃｕｓＣｌ−００１＿ｉｄ３２」が、入出力処理部１０２、対話制御部１０３を通じて、意図解析部１０４に渡される（ステップ１５０４）。意図解析部１０４は、回答タイプが選択肢であるため、クラス辞書１１３を引き、そのクラスデータを意図解析結果として対話制御部１０３に渡す（ステップ１５０５）。このクラスデータにはユーザデータはないが（ステップ１５０６）、図１９（ｂ）に示すように質問キューが存在する。そのため、シナリオ選択部１０９は、質問キューにセットされているｆｏｃｕｓＣｌ−００１−ｉｄ３２のシナリオを条件付シナリオ辞書１１４から選択する（ステップ１５１０）。この場合、図１９（ａ）に符号１９０２ａを付与したシナリオが選択され、そのシステム発話文が、ユーザに提示される（ステップ１５１１）。このときに、ユーザに提示される画面例を図１８（ｅ）に示している。

これ以降も同様にして、ユーザとシステムとの対話が進行していくが、これ以降の動作の説明は省略する。

（Ａ−３）実施形態の効果
構成及び動作を上述した上記実施形態によれば、以下の効果を奏することができる。

（１）ＱＡの特徴を示す属性値（クラス）を付与したＱＡを準備するだけで、ユーザが所望するＱＡを絞り込むための効果的な条件付シナリオを自動的に生成することができる。なお、この条件付シナリオは、全ＱＡに付与されている属性値に基づいて生成されているため、各選択肢には、必ずＱＡが紐づいている。従って、無駄な選択肢がユーザに提示されることはない。

（２）キーワード（属性値）を複数の属性に分類することによって、ユーザがある分類の切り口での選択肢による絞込みができなかった場合でも、別の分類の切り口での選択肢をユーザに提示することができる。従って、ユーザが理解できる分類での選択肢による絞込みが可能となる。

通常、ある用語に関するＱＡを選択肢で分類する切り口は、１つとは限らない。例えば、「印刷」に関するＱＡを（選択肢で）分類する切り口は、使用している「プリンタ名」で分類することもできるし、「印刷」の何について知りたいか（トラブル対処、設定方法、用語）で分類することもできる。何らかのアプリケーションからの印刷の場合ならば、「アプリケーション名」で分類することもできる。上記実施形態では、分類の切り口をいくつも用意し（属性＝属性値の組み合わせ）、ある選択肢で回答が得られない場合は、別の切り口の分類で選択肢を提示し、ユーザに選ばせることができるので、ユーザが所望するＱＡをシステムが回答する率を向上させることができる。

（３）従来例のような事例文による照合ではなく、かつ、検索対象となる全ＱＡに付与されているキーワード（属性値）を用いて、条件付シナリオと照合するため、照合する属性値が多い順にシナリオの優先度を設定したり、また、最終的に絞り込まれるＱＡの数が少ないものほど優先度を上げたりすることにより、シナリオの優先度を決定することができ、照合時のコンフリクトを抑えることができる。

（４）属性値は、全ＦＡＱデータに出現する用語から作成することができる。クラスファイルの作成は、類義語辞書や市販の辞書を利用することもでき、事例文による照合より、各種辞書の構築（生成）が容易である。

（Ｂ）他の実施形態
上記実施形態では、意図解析部１０４が単純な形態素解析を利用するものである場合を示したが、係り受けを解析する構文解析等を利用して意図解析するものであっても良い。例えば、このような高度な解析を用いることによって、文の５Ｗ１Ｈ（何、誰、どこ、いつ、なぜ、どのように）型を解析し、その解析結果から、属性「問い合わせ目的」の属性値を決定し、その属性値を条件として、次のシナリオを決定することもできる。

上記実施形態のクラスデータの上位下位関係を利用することによって、ユーザの入力文の解析精度を向上させることができる。例えば、仮に、「送受信する」、「送信する」、「受信する」が同じレベルで定義されていると、ユーザが、「送受信する」と入力した場合、「送受信する」という属性値が付与されているＱＡしか関連付かないことになる。しかし、クラスデータの上位クラスの「送受信する」の下位クラスに「送信する」と「受信する」を定義した場合、ユーザの「送受信する」は、その下位の「送信する」及び「受信する」の上位レベルの意味なので、ＱＡで「送受信する」、「送信する」、「受信する」の３つが関連付けられる。さらにこの場合、ユーザが「受信する」と入力した場合は、「送受信する」及び「受信する」は関連付けられるが、「送信する」は関連付けられない。このように、上位下位クラスを使って認識する語を定義することにより、精度の高い入力文とシナリオ（ＱＡ）の対応付けが可能となる。

なお、このようなクラスの上位下位関係を利用する方法として、特開２０１０−２６２３４３号公報に記載の方法を用いることができる。

上記実施形態においては、対話シナリオ生成システム１１５へ、図４に示したクラス付ＦＡＱデータ１１６を入力するものを示したが、図４の符号４０１及び４０２を付与したＱＡの第１の部分と、図４の符号４０３〜４１０を付与した属性＝属性値の第２の部分とを、ＦＡＱデータのｉｄでリンクできるようにした別のデータとして入力し、図７に示した処理を、第２の部分のデータだけを用いて行って、ＱＡの質問文や回答文を挿入すれば良いだけの未完シナリオや未完クラスデータを生成し、全ての未完シナリオや未完クラスデータを生成した後で、各未完シナリオや未完クラスデータに、第１の部分のデータから、必要なＱＡの質問文や回答文を挿入して、シナリオ及びクラスデータを完成させるようにしても良い。

また、未完シナリオや未完クラスデータの形式で、対話時に使用されるクラス１１３や条件付シナリオ辞書１１４に記憶させると共に、各ＱＡを記憶したＱＡ辞書を設け、ユーザにシステム発話文を提示する直前の段階で、必要なＱＡの質問文や回答文を挿入してユーザに提示するようにしても良い。

上記実施形態では、ＱＡに属性＝属性値を付与することで、ＱＡの検索を目的とした例について示したが、ＱＡに限定せず、複数の属性とその属性値を付与できる対象であれば、検索対象はどのようなものでも良い。例えば、画像に属性＝属性値が付与されているならば、画像検索にも応用することができる。

１０１…対話型質問応答システム、１０２…入出力処理部、１０３…対話制御部、１０４…意図解析部、１０５…ユーザデータ管理部、１０６…ユーザデータ、１０７…ドメイン知識管理部、１０８…辞書引き部、１０９…シナリオ選択部、１１０…条件照合部、１１１…ドメイン知識データベース（ドメイン知識ＤＢ）、１１２…形態素辞書、１１３…クラス辞書、１１４…条件付シナリオ辞書、１１５…対話シナリオ生成システム、１５０…データ読込み部、１５１…ＦＡＱデータ分類部、１５２…第１分類シナリオ生成部、１５３…第２分類シナリオ生成部、１５４…第３分類シナリオ生成部、１５５…生成シナリオ出力部。

Claims (6)

1. ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムで利用される上記シナリオデータを生成する対話シナリオ生成システムにおいて、
   検索対象の個々のデータに対して、そのデータの特徴を示す属性とその属性値を対応付けた属性データ集合と、属性、属性値をクラスとして定義したクラスデータとを少なくとも読込むデータ読込手段と、
   検索対象の個々のデータのそれぞれに対して、属性値を有する全ての属性について、属性とその属性値との対の組み合わせを求め、属性とその属性値との対の組み合わせ毎に、当該組み合わせに係る検索対象のデータの識別情報と、当該組み合わせに係る検索対象のデータの数とを得るデータ分類手段と、
   検索対象のデータの数が１個の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、１個だけの上記検索対象のデータをユーザに提示させるシナリオデータを生成する第１分類シナリオ生成手段と、
   検索対象のデータの数が２個以上ｘ個未満（但しｘは３以上の自然数）の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該データ数の上記検索対象のデータをユーザに選択させるように提示させるシナリオデータを生成する第２分類シナリオ生成手段と、
   検索対象のデータの数がｘ個以上の属性とその属性値との対の組み合わせについて、当該組み合わせに係る検索対象のデータを、当該組み合わせに含まれていない属性と属性値との対の観点から整理し、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該組み合わせに含まれていない属性の属性値を選択候補としてユーザに選択させるように提示させる、検索対象のデータを絞り込むためのシナリオデータを生成する第３分類シナリオ生成手段と
   を有することを特徴とする対話シナリオ生成システム。
2. 検索対象の個々のデータが、質問文と回答文のペアのデータであることを特徴とする請求項１に記載の対話シナリオ生成システム。
3. ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムで利用される上記シナリオデータを生成する対話シナリオ生成プログラムであって、
   コンピュータを、
   検索対象の個々のデータに対して、そのデータの特徴を示す属性とその属性値を対応付けた属性データ集合と、属性、属性値をクラスとして定義したクラスデータとを少なくとも読込むデータ読込手段と、
   検索対象の個々のデータのそれぞれに対して、属性値を有する全ての属性について、属性とその属性値との対の組み合わせを求め、属性とその属性値との対の組み合わせ毎に、当該組み合わせに係る検索対象のデータの識別情報と、当該組み合わせに係る検索対象のデータの数とを得るデータ分類手段と、
   検索対象のデータの数が１個の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、１個だけの上記検索対象のデータをユーザに提示させるシナリオデータを生成する第１分類シナリオ生成手段と、
   検索対象のデータの数が２個以上ｘ個未満（但しｘは３以上の自然数）の属性とその属性値との対の組み合わせについて、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該データ数の上記検索対象のデータをユーザに選択させるように提示させるシナリオデータを生成する第２分類シナリオ生成手段と、
   検索対象のデータの数がｘ個以上の属性とその属性値との対の組み合わせについて、当該組み合わせに係る検索対象のデータを、当該組み合わせに含まれていない属性と属性値との対の観点から整理し、ユーザとシステムとの対話を通して、ユーザの意図が、当該組み合わせに関連していると判別されるときに、当該組み合わせに含まれていない属性の属性値を選択候補としてユーザに選択させるように提示させる、検索対象のデータを絞り込むためのシナリオデータを生成する第３分類シナリオ生成手段と
   して機能させることを特徴とする対話シナリオ生成プログラム。
4. ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索システムにおいて、
   請求項１に記載の対話シナリオ生成システムと、
   ユーザからの入力を取り込みと共に、ユーザへの出力を行う入出力手段と、
   ユーザの入力を解析することによって、属性と属性値との対の組み合わせを求める意図解析手段と、
   上記意図解析手段により得られた属性と属性値との対の組み合わせと、各シナリオデータに関連する属性と属性値の対の組み合わせと照合する条件照合手段と、
   上記条件照合手段の結果から、最適なシナリオデータを選択するシナリオ選択手段と、
   選択されたシナリオデータに基づいて、次のシステム発話をユーザに提示させる対話制御手段と
   を有することを特徴とする対話型検索システム。
5. 検索対象の個々のデータが、質問文と回答文のペアのデータであることを特徴とする請求項４に記載の対話型検索システム。
6. ユーザとシステムとのシナリオデータに従った対話を通して、検索対象の多数のデータの中から、ユーザが所望するデータを見つけ出す対話型検索プログラムであって、
   請求項３に記載の対話シナリオ生成プログラムを有すると共に、
   コンピュータを、
   ユーザからの入力を取り込みと共に、ユーザへの出力を行う入出力手段と、
   ユーザの入力を解析することによって、属性と属性値との対の組み合わせを求める意図解析手段と、
   上記意図解析手段により得られた属性と属性値との対の組み合わせと、各シナリオデータに関連する属性と属性値の対の組み合わせと照合する条件照合手段と、
   上記条件照合手段の結果から、最適なシナリオデータを選択するシナリオ選択手段と、
   選択されたシナリオデータに基づいて、次のシステム発話をユーザに提示させる対話制御手段と
   して機能させることを特徴とする対話型検索プログラム。

Images