JP2007264198A - 対話装置、対話方法、対話システム、コンピュータプログラム及び対話シナリオ生成装置 - Google Patents

Abstract

【課題】対話シナリオの話題遷移に関する指定の開発・編集に関するコストを削減可能な対話装置、対話方法、対話システム、コンピュータプログラム及び対話シナリオ生成装置を提供する。
【解決手段】各話題を解決する話題シナリオを話題と対応付けて管理する対話シナリオ管理部１０４の話題シナリオを参照して対話進行部１０１でユーザとの対話を進行させるとともに、ユーザとの現在の話題情報を管理し且つ対話の進行段階での新規話題情報の導入の必要性を判断し、この判断で現在の話題情報に基づき遷移可能性のある一つ以上の次話題情報を遷移話題情報として次話題情報予測部１０３で予測し、この遷移話題情報を対話進行部１０１で管理される話題情報に反映し、この話題情報に基づき遷移話題情報選択部１０２により話題を継続させる。
【選択図】 図１

Description

本発明は、複数の話題についてユーザと対話を行う対話装置、対話方法、対話システム、コンピュータプログラム及び対話シナリオ生成装置に関するものである。

近年、音声や自然言語入力を可能とするインタフェースに関する研究が盛んである。また、そのようなインタフェースを用いるエキスパートシステムなどが多数開発され、入力された音声やテキストなどを受理する装置が一般向けにも利用可能となっている。自然言語による入力を行う場合にはユーザはシステムが必要とする全ての条件を一度に入力することは少なく、ユーザとシステムとの間でのやりとりが必要となる。例えばユーザの入力内容に不備がある場合には、システムは、その足りない条件をユーザに問い合わせ、その問い合わせに対するユーザの回答を統合するなどの処理が必要となる。このような処理を行うためにユーザとシステムとの対話処理技術が不可欠である。

このような自然言語入力は、人間にとって普段から慣れている入力方法であるため、特に操作が複雑で大規模なシステムのインタフェースでの利用が望まれている。こういった大規模なシステムでは、全体の目的を達成するために複数の副目的を達成するといった対話が必要となる。このため、対話処理技術ではそれぞれの目的に対応した複数の話題を取り扱う必要があり、同時にこれらの話題を連携させるべく対話進行状況に応じて適切に話題を遷移させる必要がある。同時にユーザの対話中の翻意などに対応した自由な対話を可能とするという観点では、システムが望む情報に関するユーザ入力のみを受理するのではなくユーザから自由に実行したい話題を指定でき、かつユーザによって対話に導入された様々な話題を統合して全体の目的を達成するような対話が可能であることが望ましい。

従来の対話技術においては、例えば、特許文献１に開示される話題をスタックで管理する方法が提案されている。この方法は、ユーザとの対話に現れた話題をスタックで管理し、目的を達成していないためにユーザとの対話が終了していない話題（未解決話題）をスタックに蓄積する。ユーザ或いはシステムによって新規話題を導入した場合には、その話題をスタックにプッシュし、ある話題についてユーザとの対話が終了した（以下『話題を解決した』と表記する）場合はスタックからポップするという操作を行う。そして、ある話題を解決した時にその話題の対話結果に基づき、対話を再開する未解決話題をスタックから探索した結果を次の話題として選択する。

特許文献１の方法においては、ある話題の対話中にシステムから新規話題を導入して話題遷移をする場合は、シナリオ設計者により予め作成されたシナリオに指定されている新規話題を導入している。また、特許文献１の方法においては、一つの話題が終了した時の話題遷移の決定はスタック内の未解決話題から対話を再開させるものを選択することで行っている。しかしながら、ユーザとの対話においては対話を中断された未解決話題を次の話題として選択するよりも新規話題を別途導入することが望ましい場合がある。

従来技術において、一つの話題が終了した後に新規話題を導入して話題を遷移させる対話技術としては、例えば、非特許文献１に開示されるように話題間の遷移を司るシナリオを各話題の対話を遂行するシナリオとは別に作成する方法がある。この方法では、システムが取り扱う機能（話題）をドメインとし、各ドメインの対話を進行させるためのシナリオ（発話プラン）と、ドメイン間の遷移を記述するためのシナリオ（ドメインプラン）とを対話の前に予め準備する。ユーザとの対話においては、システムは発話プランを参照して各ドメインに関する対話を実行し、各ドメインの対話が終了した時にはドメインプランを参照して新たなドメインへの遷移を決定している。
特開２００４−２１２６６４号公報 上野、河原：「ユーザと状況のモデルを用いたプランニングを行う音声対話システム」、人工知能学会研究会資料、SIG-SLUD-A303-11

ところが、従来の方法においては、ユーザとの対話中に対話システムから新規話題の導入を行うためには、対話シナリオ中に導入すべき話題を指定する必要があった。即ち、話題解決後に対話に導入する新規話題を決定するためには、シナリオ設計者は話題間の遷移を記述する対話シナリオ（話題間シナリオ）を各話題の対話を行うための対話シナリオ（話題シナリオ）とは別に作成しなければならない。また、ある話題の対話進行中に対話システムから新規話題を導入するためには、シナリオ設計者が話題シナリオ内に新規導入する話題の指定しなければならない。

特に話題間シナリオは対話シナリオの設計者が対話システムで取り扱う話題の組み合わせを考慮して記述するものである。対話システムが取り扱う話題の数が増加すると話題の組み合わせは大幅に増加するため、対話シナリオ設計者は大規模な話題間シナリオを設計する必要がある。従って対話システムが取り扱う話題の増加に伴い話題間シナリオ設計に関わるコストが大幅に増加するという問題がある。

また、対話システム運用開始後に対話システムが取り扱う機能の追加・削除が生じることもある。このような機能変更を対話シナリオに反映させるためには、機能追加に伴う話題シナリオの追加や、機能削除に伴う話題シナリオの削除をする必要がある。これに加えて各機能を有効に連携させて対話の目標を達成するためには、追加した機能を連携させる対話シナリオの追加・修正や、削除した機能を連携させていた対話シナリオの削除・修正といった対話シナリオの変更が必要となる。

話題シナリオの追加・削除の際にシナリオ設計者は話題間シナリオの編集を行う必要があり、同時に話題シナリオにおける新規話題を導入する指定についても編集を行う必要もある。従って、話題間シナリオの設計コストや話題シナリオの編集コストがかかってしまうという問題があった。このため、対話システム運用中にシステムが取り扱う機能構成を更新することも困難となってしまう。

本発明は上記事情に鑑みてなされたもので、対話シナリオにおける話題遷移に関する指定の開発・編集に関するコストを削減することが可能な対話装置、対話方法、対話システム、コンピュータプログラム及び対話シナリオ生成装置を提供することを目的とする。

本発明に係る対話装置は、
各話題を解決するための話題シナリオを話題と対応付けて管理する対話シナリオ管理手段と、
前記対話シナリオ管理手段で管理される前記話題シナリオを参照してユーザとの対話を進行させるとともに、前記ユーザとの現在の話題情報を管理し、且つ前記対話の進行段階での新規話題情報の導入の必要性を判断する対話進行手段と、
前記対話進行手段による新規話題情報の必要性の判断により現在の話題情報に基づいて遷移可能性を有する一つ以上の次話題情報を遷移話題情報として予測する次話題情報予測手段と、
前記次話題情報予測手段により予測された前記遷移話題情報を選択し前記対話進行手段で管理される話題情報に反映させ、該反映された話題情報に基づき話題を継続させる遷移話題情報選択手段と
を具備したことを特徴とする。

本発明によれば、対話シナリオ中の話題遷移指定なしに対話システムから新規話題導入を行う対話を実行可能とし、対話シナリオにおける話題遷移に関する指定の開発・編集に関するコストを削減することが可能で、さらに対話システム運用中にシステムが取り扱う機能構成変更に伴う対話シナリオ変更が容易となる。

以下、本発明の実施の形態に係る対話装置、対話方法及びプログラムについて図面を用いて説明する。

本発明による対話装置は何らかのアプリケーションのユーザインタフェースとなるものであり、アプリケーションにある機能を有効に動作させることを目的とするものである。特に本発明による対話装置はアプリケーションによる一つ以上の種類の機能を取り扱うために一つ以上の目的を取り扱うものであり、個々の目的を達成するためにそれぞれの目的と対応付けた話題についてユーザとの対話を行うものである。

（第１の実施の形態）
図１は、本発明の第１の実施の形態に係わる対話装置を示すブロック図である。

対話装置は、対話進行部１０１、遷移話題情報選択部１０２、次話題情報予測部１０３、対話シナリオ管理部１０４を備えている。

対話進行部１０１は、対話対象となっている話題の目的をユーザとの対話によって達成する（話題を解決する）。対話進行部１０１は、現在の対話状態として話題情報を管理する。話題情報は話題の種類と対話の進行状態を含む情報である。対話進行部１０１は管理している話題情報（現在の話題情報）についてユーザとの対話を行い、現在の話題情報の話題（現在の話題）を解決する。対話進行部１０１は、ユーザとの対話の際には、ユーザ入力を話題情報に対応付けるなどといった入力解釈や、送出プロンプトの決定などの対話進行処理を行う。送出プロンプトは音声信号やテキスト表示等によってユーザに提示される。ユーザ入力の解釈結果が現在の話題と異なる種類の話題情報であった場合は、対話進行部１０１は現在の話題情報とユーザ入力の話題情報を差し替える。対話進行部１０１は、現在の話題を解決した場合は解決時の話題情報の内容でアプリケーションの動作を実行させる。話題情報の詳細については後に図３を用いて詳述する。

対話進行部１０１は対話進行中に新規話題の導入が必要であると判定すると、遷移話題情報選択部１０２に次に対話を行うべき話題情報（遷移話題情報）の供給を依頼する。遷移話題情報選択部１０２から遷移話題情報が通知されると、通知された遷移話題情報を現在の話題情報に反映させる。新規話題導入の必要性判定や遷移話題情報を現在の話題情報に反映させる方法については後に詳述する。

対話進行部１０１における入力解釈では、ユーザから入力される自然言語を解釈し、ユーザ入力を何らかの話題情報か或いは値に変換する。例えば、ユーザが話題の名称を入力した場合には対話進行状況が初期状態の話題情報に変換したり、ユーザが動作条件としての値を指定した場合にはその値の種類の情報(例えば品詞情報など)を付与したりする。また、話題名称を省略した入力であっても話題を特定できる場合はある条件を指定された対話進行状況の話題情報に変換することもある。このような自然言語解釈方式は既存のものが使用できる。

対話進行部１０１は対話シナリオ管理部１０４に格納されている各話題に対応付けられた対話手順（話題シナリオに対応）と対話情報にある対話進行状況を参照して対話を行う。対話手順が終了した時に対話進行部１０１はその話題を解決したと判断する。このような一つの話題を解決する対話処理は、各話題に関連付けられた対話の状態遷移図などのシナリオを参照して対話を進め、シナリオの終了まで対話状態が遷移すると話題の解決とみなす手法や、話題解決のために不足している情報を検出してユーザに要求し、不足情報がなくなれば話題の解決とみなす手法など、既存の手法を利用することができる。また、対話の際にユーザに提示する応答文（送出プロンプト）はシナリオ付随の定型文や、応答文のテンプレートに情報を与えて自動生成するなど既存の手法を利用して生成することが可能である。

遷移話題情報選択部１０２は現在の対話状態に基づいて遷移話題情報を決定する。遷移話題情報選択部１０２は対話進行部１０１から話題情報を選択するように依頼を受ける。話題情報の選択処理としては先ず次話題情報予測部１０３に遷移可能性のある話題情報を予測させ、その中から一つ遷移話題情報を決定する。更に遷移話題情報選択部１０２は遷移話題情報を選択したことに基づいて遷移話題情報の対話進行状況を更新する編集処理を行う。遷移話題情報を得られなかった場合は失敗したことを対話進行部１０１に通知する。遷移話題情報選択部１０２の詳細については後述する。

次話題情報予測部１０３は現在の対話状態に基づいて遷移可能性のある話題情報を予測する。次話題情報予測部１０３は遷移話題情報選択部１０２から遷移可能性のある話題情報群を予測するように依頼を受け、０個以上の話題情報を予測結果として遷移話題情報選択部１０２に返す。次話題情報予測部の詳細については後に図４を用いて詳述する。

対話シナリオ管理部１０４は、各話題を解決するための話題シナリオを話題と対応付けて管理する。対話シナリオ管理部１０４は指定された話題に対応する話題シナリオを個別に参照できるようになっており、対話進行部１０１は各話題の対話を実行するために対話シナリオ管理部１０４から対象の話題シナリオを参照する。本対話装置において新たに対話可能とする話題を追加する際には対話シナリオ管理部１０４に話題・話題シナリオ情報を登録し、逆に対話装置で対話可能な話題を削除する際には対話シナリオ管理部１０４から話題・話題シナリオ情報を削除する。以上のような話題・話題シナリオの登録、削除処理を「話題の登録」、「話題の削除」と呼ぶ。

次に、本発明の第１の実施の形態に係わる対話装置の動作について図２を参照して説明する。なお、図２は、本発明の第１の実施の形態に係わる対話装置の動作を示すフローチャートである。

本対話装置は所定の話題についてユーザとの対話を行うものである。ユーザ或いは本対話装置によって対話を開始した段階が図２に示した「Ｓｔａｒｔ」に相当し、対話を継続する必要性がなくなったときに対話を終了する。すなわち、図２の「Ｅｎｄ」で対話を終了する。

本対話装置はユーザとの対話を開始すると、対話進行部１０１が、開始時の話題情報を現在の話題情報として設定し（ステップＳ２０１）、この話題情報に関する対話を継続する（ステップＳ２０２）。対話進行中にはシステム応答を出力してユーザ入力を待ち受ける場合も含まれるが、このような状態はステップＳ２０２でユーザ入力まで一時停止している状態であると言える。この場合はユーザ入力やタイマイベント等を受理することでステップＳ２０２の処理が継続される。対話進行中にユーザ入力によって現在の話題と異なる種類の話題情報が通知された場合は現在の話題情報をユーザ入力の話題情報と差し替える。さらに対話進行部１０１は、対話が進行する各段階で、新規話題情報の導入が必要であるかどうかを逐一確認する（ステップＳ２０３）。新規話題情報の導入が不要な場合は現在の話題を解決するための対話を継続する（ステップＳ２０２）。

ステップＳ２０３で新規話題情報の導入が必要であると判定されると（ステップＳ２０３Ｙｅｓ）、対話進行部１０１は遷移話題情報選択部１０２に遷移話題情報の選択を依頼する。

新規話題導入が必要であるかどうかの判定（ステップＳ２０３）について説明する。対話処理部１０１から新規話題導入を行うべき状況は２種類存在する。一つ目は（Ａ）現在の話題を解決した後に対話する話題を選択する時であり、二つ目は（Ｂ）現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する時である。対話進行部１０１は、これら（Ａ）（Ｂ）に該当する状況の時に新規話題導入が必要であると判定する。判定処理の詳細については後述する。

導入する新規話題情報を決定する方針は（Ａ）（Ｂ）の状況で異なる。即ち、（Ａ）の場合は対話の連続性を保つために、現在の話題の解決結果に基づいて次の話題を検討する必要がある。一方、（Ｂ）の場合は取得すべき情報を導出することが可能な話題を新規の話題とすべきである。従って、（Ａ）（Ｂ）それぞれについて異なる遷移話題情報の選択処理を行わねばならない。

ステップＳ２０４では新規話題導入が必要であると判定された状況は上記の（Ａ）、（Ｂ）のどちらであるかを判定する。（Ａ）現在の話題を解決した時であればステップＳ２０５へ（ステップＳ２０４ Ｙｅｓ）、（Ｂ）の場合であればステップＳ２０９へ進む（ステップＳ２０４ Ｎｏ）。

ステップＳ２０５からステップＳ２０８は状況（Ａ）に関する遷移話題情報の選択処理であり、ステップＳ２０９からステップＳ２１２は状況（Ｂ）に関する遷移話題情報の選択処理である。

ステップＳ２０５では次話題情報予測部１０３が遷移可能性のある話題を予測し、予測結果として遷移可能性のある話題情報を出力する。次話題情報予測部１０３は各話題情報に予測の信頼性を表す予測信頼度を付与する。予測信頼度は予測方法などに基づいて話題情報毎に算出する。次話題情報予測部１０３における詳細処理は後に詳述する。

遷移話題情報選択部１０２は、次話題情報予測部１０３から出力される予測結果から次に対話を実行する遷移話題情報を選択する（ステップＳ２０６）。次話題情報予測部１０３から通知される予測結果が空の場合は選択失敗とし、単独の場合は次話題情報予測部１０３から通知された話題情報の予測信頼度に基づき遷移話題情報として選択するかどうかを決定する。予測信頼度が低い場合はユーザに問い合わせて承認を得る。予測結果の話題情報が複数ある場合についての選択方法は様々な手法が利用できるが、ここではユーザに予測結果の話題情報を列挙して問い返し、ユーザによって選択された話題情報を遷移話題情報として選択することとする。ユーザが選択をキャンセルした場合は選択失敗とする。

ステップＳ２０６においては遷移話題情報選択部１０２からユーザに対して話題の選択に関する問い合わせを行う場合があるが、このような場合はステップＳ２０６で一時停止していると言える。ユーザ入力やタイマイベントにより話題の選択がなされるとステップＳ２０６の処理を継続する。この時遷移話題情報選択部１０２はユーザによる話題指定の入力を解釈し、遷移話題情報を決定する。

ステップＳ２０６においては、ユーザが明示的に話題情報を選択することで遷移話題情報の対話進行状況に変化が見られる場合もある。話題解決時に対応する機能を実行するかどうかを最終的にユーザに問い合わせる対話進行方針で、且つ遷移話題情報の必須属性の属性値が全て代入されている場合は、ユーザが明示的に話題情報を選択することで最終的な問い合わせが省略可能となる。従って、遷移話題情報の必須属性の属性値が全て代入されている場合は、ユーザによる承認を得られた状態になるように遷移話題情報の対話進行状況を編集する。

ステップＳ２０７では、対話進行部１０１が遷移話題情報選択部１０２から遷移話題情報を取得できたかどうかを確認する。遷移話題情報を取得できた場合は遷移話題情報を対話進行部１０１の管理する話題情報に反映させ（ステップＳ２０８）、更新された話題情報に基づき対話を継続する（ステップＳ２０２）。遷移話題情報を取得できなかった場合は、次に対話を実行する話題情報がないので対話を終了する（Ｅｎｄ）。尚、ステップＳ２０８の詳細処理は後述する。

ステップＳ２０９では次話題情報予測部１０３が遷移可能性のある話題を予測し、予測結果として遷移可能性のある話題情報を出力する。次話題情報予測部１０３は各話題情報に予測の信頼性を表す予測信頼度を付与する。予測信頼度は予測方法などに基づいて話題情報毎に算出する。次話題情報予測部１０３における詳細処理は後に詳述する。

ステップＳ２１０では次話題情報予測部１０３の予測結果を受けて遷移話題情報選択部１０２が予測結果からの遷移話題情報選択を実行する。ここでの遷移話題情報選択部１０２の処理はステップＳ２０６のものと同様であるので詳細な説明は省略する。

ステップＳ２１１では、対話進行部１０１が遷移話題情報選択部１０２から遷移話題情報を取得できたかどうかを確認する。遷移話題情報を取得できた場合は遷移話題情報を対話進行部１０１の管理する話題情報に反映させ（ステップＳ２１２）、更新された話題情報に基づき対話を継続する（ステップＳ２０２）。状況（Ｂ）は現在の話題を解決するための新規話題導入であるので、遷移話題情報を取得できなかった場合は現在の話題の解決も不可能となる。従ってユーザに対して現在の話題の解決が不可能となることを提示し、対話を終了するか、エラーリカバリのための対話を実行する（Ｅｎｄ）。尚、ステップＳ２１２の詳細処理については後述する。

次に本対話装置で参照する話題情報の具体例について図３を参照して説明する。図３では、話題情報の例として、話題「目的地設定」、「ジャンル検索」、「住所検索」の話題情報を示している。

話題情報は少なくとも話題の種類と各話題の対話進行状況に関する情報を含む情報である。対話進行状況に関する情報は各話題に関する対話手順の指定方法に依存する。例えば状態遷移図によるシナリオ指定の場合は対話によって遷移したノードに相当し、或いは話題を解決するために必要な情報を要求する対話処理の場合は、解決に必要な情報のリストなどが挙げられる。

ここで本発明の説明に使用する話題情報及びその表記について図３を用いて説明する。話題情報は名称と引数に分割できる。名称は話題の種類を表す情報であり、“（”の左側に表記する。『目的地設定』や『住所検索』などがこれに相当する。引数は本対話装置が対話によってユーザから情報を取得すべき属性であり、“（）”の内部に相当する。引数の数は話題によって異なり、表記上では各引数を“、”によって区切る。各引数は属性の呼び名である属性名と実際に対話によって指定された値である属性値の組み合わせで定義されており、これを（属性名）：（属性値）と表記する。属性値を取得していない場合は“φ”を（属性値）に格納する。例えば図３における話題情報３０３は『話題「住所」において都道府県名として「〇〇県」という値をユーザから取得した』状態であることを意味する。話題情報３０１、３０２は、属性値を取得していないことを示している。また話題情報の属性値を取得するために別の話題情報を利用する場合には、利用する話題情報を取得対象の属性値に入れ子状に格納する。例えば図３における話題情報３０４は『話題「目的地設定」において目的地を話題「ジャンル検索」を用いて決定している』状態であることを意味する。尚、詳細な属性情報の表記が必要ではない場合は、話題情報の表記を単純に話題の名称のみで表記する。

ここで図３に示す話題情報を用いた対話進行部１０１の対話処理方法の例について説明する。話題情報の属性には話題解決のために取得が必須である必須属性と必須ではない属性がある。対話進行部１０１は属性値が指定されていない必須属性が現在の話題情報の中にあれば、対話処理としてその必須属性に代入する属性値を取得するように動作する。例えば必須属性の値を入力するようにユーザに要求し、ユーザ入力を各属性に対応付けたり、ユーザに問い合わす必要がない情報であれば(現在時刻など)ユーザに要求せずに暗黙的に取得したりする。また、ユーザに情報を要求する過程において別の話題を使用する必要があるならば、その話題の話題情報を呼び出して対話を行い、呼び出した話題情報に関する対話の結果を属性値として使用する。一方、単純なコマンドの場合などには話題情報の属性数が０個の場合もあるが、そのような話題の場合は全必須属性が指定されているものとみなせる。そして、話題情報において不足している必須属性が無くなるとその話題は解決したと判定する。尚、以下では表記を簡単にするために各話題情報における属性は全て必須属性とし、全必須属性が指定されればその話題を解決したものとして説明する。

次に、本発明において重要な役割を持つ次話題情報予測部１０３の動作について図４、５を参照して説明する。図４は本実施の形態における次話題情報予測部１０３のブロック図である。図５は次話題情報予測部１０３で参照する話題構造テーブル４０２の内容を示す。

本実施の形態の次話題情報予測部１０３は、予測処理部４０１、話題構造テーブル４０２を備えている。

予測処理部４０１は現在の対話進行状況に基づいて次に遷移しうる話題を予測し、予測結果に対応する話題情報を作成する。話題情報作成処理としては予測結果の各話題に関して対話進行状況が初期状態の話題情報を作成し、作成した話題情報に利用できる値を現在の対話進行状況から取得して対話進行状況を更新する。例えば、現在の対話状態にある属性が予測後の話題と共通の属性であれば、その属性の属性値を予測後の話題に移植するなどの処理が考えられる。予測処理部４０１は前述の新規話題導入が必要な状況の違い（ステップＳ２０３の説明における（Ａ）、（Ｂ））によってその動作が異なるため、予測処理部４０１の詳細動作は各状況における動作説明として詳述する。

話題構造テーブル４０２は、予測処理部４０１から参照される話題の構造情報を管理するテーブルである。話題の構造情報として、各話題の属性定義情報と出力定義情報を管理する。図５は話題構造テーブル４０２の例である。属性定義情報には話題の各属性が対象とする値の型（種類）を定義する。図５の書式では属性定義情報として各属性につき（型）−（属性名）という書式で記述している。例えば５０１の属性定義情報では「目的地として場所型の情報が利用可能」であることを表している。出力定義情報には各話題を解決した時に得られる情報の種類を定義する。例えば話題「ジャンル検索」（５０２）、「住所検索」（５０３）は両方とも場所を検索するための話題であるので、出力定義情報として「場所」を指定している。

ここで、新規話題情報の導入が必要とされる（Ａ）現在の話題を解決した時、（Ｂ）現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する時について、（Ａ）（Ｂ）の判定処理、及び遷移話題情報を選択する詳細処理を図２、図５、図６を用いて説明する。図２において（Ａ）（Ｂ）の判定処理はステップＳ２０３に相当し、（Ａ）場合の遷移話題情報選択の処理経路はステップＳ２０５からステップＳ２０８に相当し、（Ｂ）の場合の処理経路はステップＳ２０９からステップＳ２１２に相当する。

ステップＳ２０３の詳細処理について説明する。対話進行部１０１は現在の話題を解決した時に次に対話を実行する話題として新規話題情報の導入が必要である場合を（Ａ）であると判定する。現在の話題を解決した時全てにおいて新規話題情報の導入が必要というわけではなく、例えば、対話進行部１０１が話題を解決することによって得られる対話結果を対話途中で中断されている話題（未解決話題）の解決に利用でき、その未解決な話題の対話を実行すると判定した場合は、新規話題の導入は不要となる。

本実施の形態の場合（Ａ）に該当する判定条件を『現在の話題を解決し、その対話結果を他の未解決な話題の解決に利用しないと対話進行部１０１が決定した時』とする。対話進行部１０１における対話結果を未解決話題の解決に利用するかどうかの決定方法は既存の手法が利用可能である。本実施の形態では、例えば現在の話題情報に入れ子状に格納された話題情報を解決した場合には（Ａ）に該当しないと判定できる。即ち、入れ子状に格納された話題情報の対話結果はその話題情報が格納されている属性に利用できる（格納している側の話題情報が未解決話題）ので、対話進行部１０１は対話結果を未解決な話題の解決に利用できると判定できる。（Ａ）に該当する場合はステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｙｅｓと判定し、ステップＳ２０５に進む。

次にステップＳ２０３において（Ｂ）と判定する処理について説明する。対話進行部１０１はその対話進行処理において、現在の話題を解決するために属性値を取得する属性を決定する。その属性値を取得するために新規話題情報の導入が必要であれば、対話進行部１０１は場合（Ｂ）であると判定する。本実施の形態では対話進行部１０１において属性値を取得する属性を決定した時に、その属性の型が話題構造テーブル４０２における出力定義情報に指定されている型であるかどうかを確認する。この条件に該当する場合に対話進行部１０１は（Ｂ）に該当すると判定する。対話進行部１０１は次話題情報予測部１０３を介して話題構造テーブル４０２を参照する。（Ｂ）に該当する場合はステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏと判定し、ステップＳ２０９に進む。

（Ａ）現在の話題を解決した時の遷移話題情報の選択処理（ステップＳ２０５からステップＳ２０８）について説明する。ステップＳ２０３で対話進行部１０１が話題情報を解決し、その対話結果を未解決話題の解決に利用しないことを確認すると、対話進行部１０１は場合（Ａ）であると判定し（ステップＳ２０３Ｙｅｓ、ステップＳ２０４ Ｙｅｓ）、遷移話題情報選択部１０２に遷移話題情報の選択を依頼する。

遷移話題情報選択部１０２は次話題情報予測部１０３に遷移可能性のある話題情報の予測を依頼し、次話題情報予測部１０３はこの依頼を受けて遷移可能性のある話題情報の予測処理を実行する（ステップＳ２０５）。

ステップＳ２０５では予測処理部４０１によって遷移可能性のある話題情報の予測処理が実行される。この処理は遷移可能性のある話題の予測処理と、話題情報の作成処理の２段階からなる。以下図６を参照してそれぞれについて説明する。

ステップＳ２０５における遷移可能性のある話題の予測処理において、予測処理部４０１は、『解決した話題によって得る対話結果を利用できる話題が遷移可能性のある話題である』という判断に基づいて遷移可能性のある話題を予測する。対話結果を利用できる話題であるかどうかは話題構造テーブル４０２を参照することで決定することが可能である。即ち、話題構造テーブル４０２における属性定義情報の中に対話結果として取得できる値を利用できる属性が定義されている話題が遷移可能性のある話題であると判断する（図６（１））。図６では話題「ジャンル検索」の対話の結果として場所検索結果である“ビストロ〇〇”を取得し、場所型の情報である“ビストロ〇〇”を代入することが可能な話題として属性定義情報に場所型を利用することが定義されている「目的地設定」を選択している。この例では選択可能な話題は一つだけであるが、他にも該当する話題があれば全てを列挙する。尚、解決した話題から対話結果を取得できない場合（出力定義情報が「なし」になっている話題を解決した場合や、検索失敗等の情報取得に失敗した場合など）には予測に失敗したものとする。

予測処理部４０１は予測処理に続けて話題情報の作成処理を行う。話題情報の作成処理では、まず予測結果の全話題について対話進行状況が初期状態の新規話題情報を作成する（図６（２））。次に解決した話題の対話内容を各新規話題情報に入力して対話進行状況を更新する。具体的には対話結果として得られる情報を新規話題情報の属性値として代入する(図６（３）)。話題構造テーブル４０２を参照すれば代入する属性を決定することが可能である。図６（３）では対話結果として取得した“ビストロ〇〇”を新規作成した話題情報「目的地設定」の属性「目的地」に代入している。このように新規話題情報に対して対話結果が入力されたかのように対話進行状況を更新させるなどをすれば、対話結果を利用した連続性のある対話を続けることが可能となる。また、新規話題情報と解決した話題の話題情報（解決した話題情報）で共通の属性の属性値を新規話題情報に代入するなどの処理も併用することが可能である。

次話題情報予測部１０３は、この手法による予測信頼度は高くないものと判定して、個々の話題情報に予測信頼度情報が低いという情報を付与し（図６（４））、作成された新規話題情報群を遷移可能性のある話題情報の予測結果として出力する。

遷移話題情報選択部１０２は、次話題情報予測部１０３から出力される予測結果から次に対話を実行する遷移話題情報を選択し（ステップＳ２０６）、選択結果に基づいて対話を継続するか否かを決定する（ステップＳ２０７）。これらの処理は前述のステップＳ２０６、ステップＳ２０７の説明と同様であるので詳細な説明は省略する。

遷移話題情報の選択が終了した後に対話進行部１０１は遷移話題情報を現在の話題情報に反映させる（ステップＳ２０８）。ステップＳ２０８は現在の話題を解決した時に呼ばれる処理なので、対話進行部１０１は管理している話題情報と遷移話題情報を差し替える。その後更新された話題情報に基づく対話を継続する（ステップＳ２０２）。

続いて（Ｂ）現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する時の遷移話題情報の選択処理について説明する。

ステップＳ２０３で対話進行部１０１が現在の話題を解決するために別の話題情報を必要としていることを検出すると、対話進行部１０１は場合（Ｂ）であると判定し（ステップＳ２０３Ｙｅｓ、ステップＳ２０４ Ｎｏ）、遷移話題情報選択部１０２に遷移話題情報の選択を依頼する。

遷移話題情報選択部１０２は次話題情報予測部１０３に遷移可能性のある話題情報の予測を依頼し、次話題情報予測部１０３はこの依頼を受けて遷移可能性のある話題情報の予測処理を実行する（ステップＳ２０９）。

ステップＳ２０９では予測処理部４０１によって遷移可能性のある話題情報の予測処理が実行される。この処理は遷移可能性のある話題の予測処理と、話題情報の作成処理の２段階からなる。以下それぞれについて説明する。

ステップＳ２０９における遷移可能性のある話題の予測処理において、予測処理部４０１は、『取得したい属性値の型の値を出力する話題が遷移可能性のある話題である』という判断に基づいて遷移可能性のある話題を予測する。所望の型の値を出力する話題であるかどうかは話題構造テーブル４０２を基づいて決定することが可能である。即ち、話題構造テーブル４０２における出力定義情報が所望の型と定義されている話題が遷移可能性のある話題であると判断する。例えば、図５の話題構造テーブル４０２の例では、話題「目的地設定」の属性「目的地」を解決するために遷移する可能性がある話題は、「目的地」属性の型である場所型の情報を出力する話題「ジャンル検索」「住所検索」の２種類である。

予測処理部４０１は予測処理に続けて話題情報の作成処理を行う。ステップＳ２０９における話題情報の作成処理は、予測結果の全話題について対話進行状況が初期状態の新規話題情報を作成すれば完了する。尚、新規話題情報と解決した話題情報で共通の属性の属性値を新規話題情報に代入するなどの処理も実行可能である。

次話題情報予測部１０３は、この予測方法では手順として必要な話題を取得するものであるので予測信頼度は高いと判断し、個々の話題情報に予測信頼度が高いという情報を付与し、作成された新規話題情報群を遷移可能性のある話題情報の予測結果として出力する。

遷移話題情報選択部１０２は、次話題情報予測部１０３から出力される予測結果から次に対話を実行する遷移話題情報を選択し（ステップＳ２１０）、選択結果に基づいて対話を継続するか否かを決定する（ステップＳ２１１）。これらの処理は前述のステップＳ２１０、ステップＳ２１１の説明と同様であるので詳細な説明は省略する。

遷移話題情報の選択が終了した後に対話進行部１０１は遷移話題情報を現在の話題情報に反映させる（ステップＳ２１２）。ステップＳ２１２は現在の話題を解決するために別の話題情報を導入する処理なので、対話進行部１０１は管理している話題情報における現在解決対象となっている属性に遷移話題情報を入れ子状に代入する。その後更新された話題情報に基づく対話を継続する（ステップＳ２０２）。この場合、対話進行部１０１は代入した遷移話題情報を解決するための対話を実行する。

次に、具体例として、カーナビゲーションシステム（以下カーナビ）に本発明を適用した場合を例に、本実施の形態の動作について図２、図５、図６、図７を参照してより詳細に説明する。カーナビで対話を行うことが可能な話題は、指定された位置へのルート計算を行う「目的地設定」と、場所を検索する場合に使用する、住所を都道府県名から順に指定することで位置を特定する「住所検索」と、施設の種類を指定することで周辺の施設を検索する「ジャンル検索」とである。「目的地設定」の機能を実行させる際には、ユーザに実行してよいかどうかの確認を行い、ユーザの承認を得る。このようなカーナビを用いて図７のような対話を行う場合の動作を詳細に説明する。

ユーザ入力ＵＳＲ１によって対話が開始される。ＵＳＲ１を解釈すると“ジャンル検索（ジャンル名：φ）”という入力となる。対話進行部１０１が「ジャンル検索」を現在の話題情報として設定し（ステップＳ２０１）、対話を開始する（ステップＳ２０２）。話題「ジャンル検索」で必要な情報であるジャンル名称を取得するために、対話進行部１０１はＳＹＳ１をユーザに対して出力する。

次に、ユーザ入力ＵＳＲ２が入力された。ＵＳＲ２を解釈すると“「レストラン」（ジャンル）”となる。対話進行部１０１は、この情報は話題情報「ジャンル検索」の「ジャンル名」として利用可能であるので、この値を「ジャンル名」に代入することによって現在の話題情報を“ジャンル検索（ジャンル名：レストラン）”に更新する。その結果、対話進行部１０１は、話題「ジャンル検索」の解決に必要な情報が全て取得できたので、これを解決したと判定する。対話進行部１０１は対話によって取得した情報を元に周辺のレストラン情報の検索をカーナビに実行させ、“ビストロ〇〇”（場所）という情報を得たとする。実行結果に関してユーザに応答を出力する（ＳＹＳ２）。対話進行部１０１は現在の話題情報を解決し、未解決話題も存在しないので新規話題の導入が必要であると判定する（ステップＳ２０３ Ｙｅｓ，ステップＳ２０４ Ｙｅｓ）。

対話進行部１０１は遷移話題情報選択部１０２に遷移話題情報の供給を依頼し、遷移話題情報選択部１０２は次話題情報予測部１０３に遷移可能性のある話題情報の予測を依頼する（ステップＳ２０５）。

次話題情報予測部１０３では図６のようにして動作する。解決した話題の対話結果として得られる検索結果“ビストロ〇〇”（場所）を属性に代入することが可能な話題を話題構造テーブル４０２から決定する。図５の構造話題構造テーブル４０２の登録内容においては属性定義情報に場所型の情報を代入可能な属性が定義されている話題は「目的地設定」のみである（図６（１））。従って「目的地設定」の初期状態の話題情報を作成し（図６（２））、対話結果である“ビストロ〇〇”（場所）を話題情報「目的地設定」に代入する（図６（３））。また、次話題情報予測部１０３で実行された属性定義情報に基づく予測処理の予測信頼度は低いものと判定し、作成した話題情報「目的地設定」に予測信頼度が低いことを登録する（図６（４））。次話題情報予測部１０３は作成された話題情報「目的地設定」を遷移可能性のある話題情報の予測結果として通知する。

遷移話題情報選択部１０２は次話題情報予測部１０３から通知された予測結果から遷移話題情報を選択する（ステップＳ２０６）。予測結果の話題情報は一つだけであるので、予測信頼度の大きさに基づいてユーザに対して選択可能かどうかの問い合わせを行うかどうかを決定する。通知された話題情報「目的地設定」は予測信頼度が低いという情報が付与されているので、「目的地設定」に遷移してよいかどうかをユーザに問い合わせるためにＳＹＳ３を返す。対話装置の処理状態はステップＳ２０６で一時停止状態となっている。

続いてユーザ入力ＵＳＲ３が通知された。これをうけてステップＳ２０６の処理を継続する。ＵＳＲ３は遷移話題情報選択部１０２が問い合わせた内容に対する肯定表現であると解釈される。通知された話題情報「目的地設定（目的地：ビストロ〇〇）」には目的地情報として“ビストロ〇〇”が代入されており、全必須情報に値が代入されているので、遷移話題情報選択部１０２は話題情報「目的地設定」の対話状況としてユーザによる承認済みであることを登録する。例えば、全話題情報に共通のパラメータ（話題の属性とは別のデータ構造）として「ユーザによる承認済み情報フラグ」が利用可能であれば、そのパラメータを編集する。或いは話題の属性としてユーザによる承認状況を追加した話題情報を作成しても良い。

ユーザによる承認を得たので、遷移話題情報選択部１０２は遷移話題情報として話題情報「目的地設定（目的地：ビストロ〇〇）」を対話進行部１０１に通知する。対話進行部１０１には有効な遷移話題情報が通知されたので（ステップＳ２０７ Ｙｅｓ）、遷移話題情報を現在の話題情報として登録する（ステップＳ２０８）。その結果、現在の話題情報は「目的地設定（目的地：ビストロ〇〇）」となる。

対話進行部１０１は現在の話題情報に基づいて対話を継続する（ステップＳ２０２）。現在の話題情報として登録されている「目的地設定」はユーザによる承認済みであることが登録されているので、「目的地設定」実行に関するユーザへの問い合わせをスキップする。その結果、対話進行部１０１は、話題「目的地設定」を解決したと判定する。対話進行部１０１は対話によって取得した情報を元に“ビストロ〇〇”を目的地に設定し、ルート設定を行う。実行結果としてユーザに応答を出力する（ＳＹＳ４）。対話進行部１０１は現在の話題情報を解決し、未解決話題も存在しないので、新規話題の導入が必要であると判定する（ステップＳ２０３ Ｙｅｓ，ステップＳ２０４ Ｙｅｓ）。

対話進行部１０１は遷移話題情報選択部１０２に遷移話題情報の供給を依頼し、遷移話題情報選択部１０２は次話題情報予測部１０３に遷移可能性のある話題情報の予測を依頼する（ステップＳ２０５）。しかし、話題「目的地設定」の対話結果から出力される情報はないので（図５の「目的地設定」における出力定義情報が「なし」になっている）、新たに属性値として利用できる情報が存在しない。従って次話題情報予測部１０３では遷移可能性のある話題の予測に失敗し、最終的に空の予測結果を出力する。

遷移話題情報選択部１０２は予測結果が空であることをうけ、選択に失敗したことを対話進行部１０１に通知する（ステップＳ２０６）。対話進行部１０１は有効な遷移話題情報が得られなかったので（ステップＳ２０７ Ｎｏ）、対話を終了する（Ｅｎｄ）。

このように本実施の形態は、解決した話題の対話結果を利用する話題を導入する。従ってシナリオ設計者が話題間シナリオを作成しなくとも、場所検索を行った結果を利用した継続性のある話題である「目的地設定」へとスムーズに遷移することが可能となる。話題「ジャンル検索」解決時に新たな話題を導入できなければ、「ジャンル検索」の結果を提示する（ＳＹＳ２）のみで対話が終了してしまうため、ユーザは別途「目的地設定」を示唆する入力を行わなければならない。

尚、本実施の形態では「ユーザ入力が現在の話題情報の解決に利用できない値の場合」についても動作する。例えば、図８の対話例について説明する。ＵＳＲ５、ＳＹＳ５では話題「住所検索」を解決するための対話である。ここでユーザが特定の場所を指定する発話であるＵＳＲ６「ビストロ〇〇」が入力された場合の動作について説明する。

“ビストロ〇〇”は場所型の情報であるが、現在の話題情報「住所検索」では都道府県名等を受理対象としているので場所型の情報を利用することが出来ない。このような現在の話題情報の解決に利用不可能な値入力を、「解決した形式の新規話題の導入且つ対話結果の値の指定」であると対話進行部１０１で取り扱う。即ち「ビストロ〇〇」という入力によって、対話進行部１０１は話題の解決を検出し、同時に対話結果として「ビストロ〇〇」を得る。従ってユーザ入力「ビストロ〇〇」によって対話進行部１０１の処理においてはステップＳ２０３、ステップＳ２０４共にＹｅｓと判定する。以下は図７の対話例において「ジャンル検索」を解決した場合と同様に動作する。ステップＳ２０５において次話題情報予測部１０３は図６のように動作する。ステップＳ２０６では次話題情報予測部１０３の予測結果である「目的地設定（目的地：ビストロ〇〇）」への遷移可否を問い合わせるためにＳＹＳ６を出力する。ユーザによる許諾（ＵＳＲ７）を受理すると、対話進行部１０１は遷移話題情報である「目的地設定（目的地：ビストロ〇〇）」を現在の話題情報として登録する（ステップＳ２０７ Ｙｅｓ、ステップＳ２０８）。その後話題情報「目的地設定」のための対話を継続する（ステップＳ２０２）。

本実施の形態では現在の話題とは無関係な値が入力されても、その値を利用した話題への遷移を可能とする。従って本実施の形態では意図が不明なユーザ入力に追従した対話が可能であると言える。もし対話装置が現在の話題と無関係の値の入力（ＵＳＲ６）を無視すると、対話進行状況は更新されずに再度同じプロンプト（ＳＹＳ５）を出力することになる。ユーザが“ビストロ〇〇”の情報を指定するためには少なくとも「住所検索」をキャンセルし、場所型の情報が利用可能な話題情報（例えば「目的地設定」）を指示しなければならない。

図７、図８の対話例は（Ａ）「現在の話題を解決した時」の遷移話題情報選択の手順を説明する対話例である。次に（Ｂ）「現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する時」の遷移話題選択の手順について図９の対話例を用いて説明する。

ユーザ入力ＵＳＲ８によって対話が開始される。ＵＳＲ８を解釈すると“目的地設定（目的地：φ）”という入力となる。対話進行部１０１が「目的地設定」を現在の話題情報として設定し（ステップＳ２０１）、対話を開始する（ステップＳ２０２）。対話進行部１０１は、話題「目的地設定」の解決に必要な情報である属性「目的地」を取得することを決定する。

話題構造テーブル４０２を参照すると、属性定義情報から属性「目的地」は場所型の情報を属性値とするものであることがわかり、出力定義情報に場所型が指定されている話題が存在することもわかる。従って、対話進行部１０１は、『属性「目的地」の属性値を取得するためには手順として出力定義情報に場所型が指定されている話題を利用する』必要があると判定する（ステップＳ２０３ Ｙｅｓ，ステップＳ２０４ Ｎｏ）。

対話進行部１０１は遷移話題情報選択部１０２に遷移話題情報の供給を依頼し、遷移話題情報選択部１０２は次話題情報予測部１０３に遷移可能性のある話題情報の予測を依頼する（ステップＳ２０９）。

予測処理部４０１では『取得したい属性値の型の値を出力する話題が遷移可能性のある話題である』という判断に基づいて遷移可能性のある話題情報を予測する（ステップＳ２０９）。属性値を獲得したい属性「目的地」の型である場所型を話題構造テーブル４０２（図５）における出力定義情報に持つ話題を抽出する。図５から出力定義情報に場所型を持つ話題として「ジャンル検索」「住所検索」の２種類が該当するので、予測処理部４０１はこれら２つの話題を遷移可能性のある話題として選択する。

予測処理部４０１は続けて話題情報の作成を行う。ステップＳ２０９では対話進行状況が初期状態の話題情報を作成すれば良いので、「ジャンル検索（ジャンル名：φ）」、「住所検索（都道府県名：φ、市区町村名：φ）」の話題情報を作成する。更にこの手順による予測信頼度は高いという情報を付与する。次話題情報予測部１０３による予測結果として話題情報「ジャンル検索」「住所検索」を遷移話題情報選択部１０２に通知する。

遷移話題情報選択部１０２は次話題情報予測部１０３から通知された予測結果から遷移話題情報を選択する（ステップＳ２１０）。予測結果に話題情報は二つあるので、何れか一方を選択するようにユーザに問い合わせるためにＳＹＳ８を出力する。対話装置の処理状態はステップＳ２１０で一時停止状態となる。

続いてユーザ入力ＵＳＲ９が通知された。これをうけてステップＳ２１０の処理を継続する。ＵＳＲ９は遷移話題情報選択部１０２が問い合わせた選択肢の中から「住所検索」を選択する表現であると解釈される。従って遷移話題情報として「住所検索（都道府県名：φ、市区町村名：φ）」を選択する。遷移話題情報「住所検索」には属性値が代入されていない属性があるので、ユーザによる承認済み情報は登録しない。

ユーザにより遷移話題情報が選択されたので、遷移話題情報選択部１０２は遷移話題情報として話題情報「住所検索（都道府県名：φ、市区町村名：φ）」を対話進行部１０１に通知する。対話進行部１０１には有効な遷移話題情報が通知されたので（ステップＳ２１１ Ｙｅｓ）、遷移話題情報を現在の話題情報において属性値取得対象となっている属性「目的地」に代入する（ステップＳ２１２）。その結果、現在の話題情報は「目的地設定（目的地：住所検索（都道府県名：φ、市区町村名：φ））」となる。

対話進行部１０１は現在の話題情報に基づいて対話を継続する（ステップＳ２０２）。現在の話題情報が入れ子になっている場合は入れ子として代入した話題情報を対象として対話を進行する。対話進行部１０１は話題「住所検索」の解決に必要な情報である「都道府県名」をユーザに問い合わせる（ＳＹＳ９）。

以後、対話進行部１０１は話題「住所検索」を解決するために対話を進行させる。「住所検索」を解決した時に対話結果として得られる場所情報は、話題情報「目的地設定」の属性「目的地」の値として登録する。

以上の例ではステップＳ２０９において次話題情報予測部１０３から提示された予測結果にある話題情報が複数の場合であったが、唯一であった場合について説明する。属性「目的地」を解決するために利用できる話題が「住所検索」のみであったと仮定する。この場合はステップＳ２０９の結果として話題情報「住所検索」を遷移話題情報選択部１０２に通知する。遷移話題情報選択部１０２における遷移話題情報の選択処理（ステップＳ２１０）においては、候補が唯一「住所検索」であり、予測信頼度が高いという情報が付与されているのでユーザに問い合わせることなく遷移話題情報は「住所検索」であることが決定される。

「目的地」属性の属性値を話題「住所検索」でしか決定できない場合は、属性値を取得する手順として「住所検索」を使用するのは明らかである。従って「住所検索」を利用するか否かをユーザに問い合わせる必要は無いものと考えられる。本手法では対話手順として利用するための話題の予測に関しては、現在の話題を解決するために予測した話題への遷移が必須であるので予測信頼度を高いものと設定している。予測信頼度を高めることにより、「住所検索」を利用するか否かをユーザに問い合わせる手順をスキップすることが可能となっている。

また、図９の対話例ではＵＳＲ９によって話題情報「住所検索」を選択するように入力しているが、ステップＳ２１０における入力ＵＳＲ９の時点で「キャンセル」等の選択拒否を示唆する入力が成された時について説明する。選択拒否の入力を受理すると、遷移話題情報選択部１０２は選択失敗を対話進行部１０１に返す。この場合、対話進行のために必要な手順が取得できなかったため、現在の話題の解決も不可能となってしまう。従ってステップＳ２１１において遷移話題情報が取得できなかったことを検出した場合には、「目的地設定を実行できませんでした」のようなエラー発生のメッセージを提示する。

このように第１の実施の形態では、属性値を取得する手順として他の話題が必要であることを検出し、他の話題が必要な場合は手順として利用可能な話題情報を選択し、対話手順として導入する。従って、シナリオ設計者が対話シナリオに別話題を呼び出す指定をしなくとも、属性値を取得するための話題へとスムーズに遷移することが可能となる。手順として利用可能な話題を選択することがなければ、ＵＳＲ８に対してシステムは単に「目的地を指定して下さい」という応答しか返せなくなり、ユーザがどのような話題があるかを把握していない場合には対話が困難になる。

対話進行部１０１における対話処理において現在の話題から他の新規話題に遷移する可能性は、（Ａ）現在の話題の対話が終了した時と（Ｂ）現在の話題を解決するために別の話題を呼び出す時にある。（Ａ）（Ｂ）以外の場合は現在の話題の対話を継続すれば良いので、シナリオ設計者が対話シナリオに話題間遷移のための指定をする必要は無い。また、ユーザによる別話題の入力については対話進行部１０１でユーザが指定した話題への遷移を行っており、シナリオ設計者による話題間遷移のための指定は不要である。従って上記（Ａ）（Ｂ）の場合はシナリオ設計者が話題間遷移をするための指定（話題間シナリオや別話題の呼び出し指定）を対話シナリオに指定しなければならない。しかしながら、本実施の形態では上記（Ａ）（Ｂ）の場合の新規話題への遷移を話題構造テーブル４０２に基づく決定のみで実現している。よって本実施の形態による対話装置では、シナリオ設計者は独立した個別の話題シナリオを設計するだけでよい。

以上のように第１の実施の形態では、シナリオ設計者が話題間シナリオや手順として他の話題を呼び出す手続きといった話題間遷移を対話シナリオに指定することなく、ユーザとの対話実行中に、話題構造テーブル４０２に基づき新規話題情報への遷移を適切に決定することが可能となる。

ここで、話題構造テーブル４０２の構築コストについて説明する。話題構造テーブルにおける「出力定義情報」は「その話題によってどのような情報を得るか」を定義するものであり、「属性定義情報」は「その話題を解決するためにどのような情報を取得する必要があるか」を定義するものである。これらの情報は各話題に関する話題シナリオを検討する際に検討すべき内容である。話題構造テーブル４０２は出力定義情報・属性定義情報をテーブルにまとめたものであり、各話題につき個別にこれらの情報を登録するだけで話題の組み合わせも検討する必要が無い。従って話題構造テーブル４０２の構築コストは、話題間シナリオと言った話題間遷移のための指定を対話シナリオに追加するよりも大幅に削減することが可能となる。

また、本実施の形態の構成は対話装置運用中であっても話題の追加・削除といった話題構成の変更が容易である。従ってアプリケーションの機能構成の変更による対話シナリオの変更が容易になる。新たな話題を導入する際には、シナリオ設計者は追加する話題に関する話題シナリオを話題構造テーブル４０２に登録するための話題の構造情報（出力定義情報・属性定義情報）のみを作成する。話題シナリオの作成作業は従来方式においても必要なコストである。これらの話題、話題シナリオ、話題導入の予測に使用する情報（話題構造テーブル４０２に登録する情報）の組み合わせを話題登録情報と呼ぶ。

話題登録情報を登録する作業として、対話シナリオ管理部１０４への話題の登録と話題導入の予測に使用する情報の登録を行えば良い。話題導入予測に使用する情報に関しては本実施の形態では話題構造テーブル４０２に作成した話題の名称、話題の構造情報（出力定義情報、属性定義情報）を登録するだけである。本実施の形態では話題シナリオを独立に定義することが可能であるので話題追加に伴う既存の対話シナリオに対する編集手続きは不要である。話題構造テーブル４０２も各話題の情報を個別に登録する形式であるので他の話題への影響を考慮する必要は無い。

例えば、上述のカーナビの例において新たに話題「登録名称検索」が追加されたとする。「登録名称検索」はランドマーク等の名称から場所を特定するための話題である。この時「登録名称検索」の話題を登録すると共に「登録名称検索」に関する出力定義情報と属性定義情報を図５の話題構造テーブル４０２に追加する。その結果話題構造テーブル４０２は図１０のようになる。図１０の話題構造テーブル４０２を対象とすると、「登録名称検索」解決後には検索結果の場所を利用する話題として「目的地設定」への遷移が可能である。一方、「目的地設定」の「目的地」属性を解決するために利用可能な話題として、出力定義情報が場所型である「ジャンル検索」、「住所検索」、「登録名称検索」が利用可能であることをユーザに提示することが可能となっている。

また、話題を削除する際には話題登録情報を削除するだけで良い。対象の話題と話題シナリオを対話シナリオ管理部１０４から個別に削除し、話題構造テーブル４０２から削除する話題に関する話題の構造情報を取り除くだけである。この場合も話題削除に伴う他の対話シナリオに対する編集手続きは不要である。

例えば、上述の「登録名称検索」追加後に、話題「ジャンル検索」を削除した場合には話題構造テーブル４０２は図１１のようになり、「ジャンル検索」への遷移可能性がなくなることがわかる。図１０、図１１を見てわかるように話題の登録・削除に伴う変更により、話題構造テーブル４０２に登録されている他の話題に関する情報の変更は必要ではない。

このように本実施の形態では個別に話題シナリオを管理できるので、シナリオ設計者によりアプリケーションの機能に対する話題登録情報が提供されていれば、エンドユーザによりアプリケーションの機能構成を変更 (アプリケーションの機能を追加・削除するなど)しても、それと連動して対話シナリオの変更を行うことが可能である。或いはサーバ管理者がサーバ上で利用可能なアプリケーションの機能構成を変更することも可能である。新規機能を追加する際にはその機能と関連付けられた話題に関する作成済みの話題登録情報を自動或いは手動で取得し、取得した話題登録情報を登録すればよい。或いは部分的に対話が可能なように話題登録情報を登録・削除することも可能である。

以上のように第１の実施の形態に係わる対話装置によれば、対話シナリオ設計における話題間遷移を指定するコストを削減することが可能であり、同時に対話システム運用中における話題構成の変更や、アプリケーションの機能構成の変更も容易に実行することが可能となる。

なお、上述の例では対話シナリオ管理部１０４や、話題構造テーブル４０２が本対話装置内に格納するかのように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば、図１２のように対話進行部１０１、遷移話題情報選択部１０２及び次話題情報予測部１０３を有する対話装置に対し対話シナリオ管理部１０４及び話題構造テーブル４０２を独立して配置し、これらの間をネットワークや無線回線などの通信媒体２００を介して接続するようにしても良い。この場合は話題の追加・削除処理に伴い通信媒体２００を介して対話シナリオ管理部１０４、話題構造テーブル４０２を編集するようになる。勿論、対話進行部１０１、遷移話題情報選択部１０２及び次話題情報予測部１０３の各構成要素も独立して配置し、それぞれの間を通信媒体２００により接続し、情報の送受信を行なうようにしても良い。

また、上述の例では対話シナリオ管理部１０４や、話題構造テーブル４０２の編集の際には、それぞれに登録されている話題シナリオや話題の構造情報の追加・削除を行っているが、本実施の形態はそのような構成に限定されるものではない。例えば、情報自体の追加・削除をせずに、対話進行部１０１や次話題情報予測部１０３からのアクセス可否を設定するだけでも良い。対話シナリオ管理部１０４では話題毎に話題シナリオへのアクセス可否を設定し、アクセス不可となった話題シナリオの情報の参照要求を拒否する。話題構造テーブル４０２でも話題毎に話題の構造情報へのアクセス拒否を設定し、アクセス不可となった話題の構造情報の参照要求を拒否する。以上のように動作すれば、話題登録情報の追加・削除がなされたものと同等になる。

なお、上述の例では遷移話題情報選択部１０２における遷移話題情報を選択する処理（ステップＳ２０６、ステップＳ２１０）において、遷移話題情報選択部１０２がユーザに遷移話題情報に関する問い合わせを行っているが、本実施の形態はそのような対話進行方法に限定されるものではない。例えば、遷移話題情報選択部１０２から問い合わせの内容を対話進行部１０１に通知し、対話進行部１０１の現在の対話状態を遷移話題情報選択のための問い合わせ状態であるように一時的に設定し、対話進行部１０１からユーザに問い合わせを行っても良い。この場合、ユーザからの応答の解釈結果を対話進行部１０１から遷移話題情報選択部１０２に通知するなどして、遷移話題情報選択部１０２がユーザによる選択内容を受理し、受理した情報に基づいて遷移話題情報の選択処理を継続する。

また、ステップＳ２０３における新規話題情報の導入の必要性判定において、（Ｂ）現在の話題を解決するために別の話題を利用することを判定するタイミングについても上述の例に限定されない。上述の例では対話進行部１０１が特定の属性の属性値を取得することを決定した時にステップＳ２０３でＹｅｓと判定し、遷移話題情報の選択処理（ステップＳ２０９〜）に移行している。しかし、例えば対話進行部１０１が特定の属性の属性値を取得すると決定し、一旦ユーザに対して「目的地の場所を入力して下さい」のように出力し、この出力に対してユーザからのヘルプ要求や入力のタイムアウトが生じ、より詳細な手続きの提示が必要とされた時に、ステップＳ２０３でＹｅｓと判定することも可能である。また、このような構成の場合には、対話進行部１０１が特定の属性の属性値を取得することを決定した時にステップＳ２０９の処理を実行して遷移可能性のある話題情報を予め予測しておき、ユーザからのヘルプ要求などのタイミングで予測済みの遷移可能性のある話題情報を利用してステップＳ２１０以降を実行することも可能である。

また、ユーザから「場所を検索したい」という検索すべき情報の種別を指定する入力が行われた場合であっても、上述（Ｂ）の枠組みで対処することが可能である。上述（Ｂ）の枠組みは取得すべき情報の型から話題の遷移を予測するものなので、ユーザから直接型を指定されても同様に処理が可能である。

また、ステップＳ２１１で失敗を検出した際に対話進行が不可能になったことをユーザに提示して対話を終了しているが、遷移話題情報選択部１０２から対話進行部１０１にエラーリカバリのための対話を依頼することも可能である。

また、本実施の形態では場合（Ａ）のような対話結果の値に基づく予測処理（ステップＳ２０５）を現在の話題を解決した時に実行しているが、例えば現在の話題を更新した時や、現在の話題の対話中にステップＳ２０５の処理を開始しても良い。このような場合は対話結果の値を取得できていないので、現在の話題に関する出力定義情報を代入可能な話題を遷移可能性のある話題と判定する。遷移可能性のある話題の収集が完了するとステップＳ２０５の途中で予測処理は一時停止しておき、現在の話題を解決して対話結果の値を取得した時に以後の処理を再開することが可能である。

また、本実施の形態では話題登録情報として話題、話題シナリオ、話題構造テーブル４０２に登録した情報としているが、本実施の形態はそのような構成に限定されない。例えば、入力された自然言語文がどの話題に該当するかを判断する話題への対応付けルールも話題登録情報として追加することが可能である。このような場合、話題Ａに対する対応付けルールは入力が話題Ａに該当するか否かを判断するという形式のルールであれば、話題別に個別のルールが適用できる。また、音声対話システムの場合は各話題の追加・削除に関して音声認識が対象とする音声認識文法を編集する必要がある。本実施の形態では各話題についてその話題に関する発話を表現する音声認識文法を定義しておき、各話題の音声認識文法も話題登録情報の一部として取り扱うことが可能である。

また、本実施の形態では遷移話題予測のために利用する話題の構造情報を話題構造テーブル４０２のような形式でまとめているが、対話装置で参照する話題と関連付けて個別に話題の構造情報を管理しても良い。この場合は次話題情報予測部１０３が参照可能な話題から話題の構造情報を収集して予測処理を進める。

また、本実施の形態では対話進行部１０１では対話状態を単一の話題情報である現在の話題情報としているが、特許文献１のように話題の遷移状況を表すスタック等のような構成を対話状態として利用しても良い。このような場合は対話進行部１０１が遷移話題情報を取得した時には遷移話題情報をスタックに追加させれば良い。また、このような構成の場合は、対話結果を未解決話題の解決に利用するかどうかを、話題情報の入れ子構造だけではなく、対話結果を利用するスタック要素（未解決話題）を探索した結果に基づいて決定することが可能である。

また、本実施の形態では、現在の話題の対話結果を未解決話題の解決に利用できる場合は現在の話題を解決した時に新規話題導入を実行しないと判定していたが、対話進行部１０１が未解決話題の解決に対話結果を利用すると同時に新規話題の導入も実行すると判定するならば、ステップＳ２０３でＹｅｓと判定しても良い。

また、本実施の形態では、新規話題情報の導入判定や、遷移可能性のある話題情報の予測の際に話題構造テーブル４０２における型情報の一致に基づいて判定を行っていたが、型の意味的な包含関係に基づいて判定しても良い。

以上のように、話題の構造情報に基づいて新規話題導入が必要な状況か否かを判定し、話題間シナリオと言った話題間遷移の指定を参照することなく遷移話題情報の選択を行うものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第２の実施の形態）
第１の実施の形態では話題構造テーブル４０２という話題の構造情報を利用して比較的簡単なルールに基づいて遷移可能性のある話題情報の予測を行っている。しかしながら、対話において話題を超えて対話手順が指定されていることもある。このような場合は話題構造テーブル４０２のような接続関係が明確ではない情報に基づいて予測することは困難となる。第２の実施の形態では、複数の話題にわたる対話手順（話題遷移手順）を考慮した遷移話題情報の予測を行うものである。

例えばユーザから承認済みの目的地と承認済みの経由地を取得し、ルート計算を行う「ルート設定」と、ユーザから目的地の場所の情報を取得し、目的地として利用することの承認を得る「目的地設定」と、ユーザから経由地の場所の情報を取得し、経由地として利用することの承認を得る「経由地設定」という３つの話題を例にあげる。「ルート設定」を実行するためには「目的地設定」「経由地設定」という話題から承認済みの目的地・経由地の情報を取得しなければならない。即ち対話手順『「ルート設定」を行うために「目的地設定」と「経由地設定」を解決する必要がある』は３つの話題にわたる話題遷移手順であるといえる。本実施の形態はこのような話題遷移手順を考慮した遷移話題情報の選択を行う。

本実施の形態と第１の実施の形態との変更点は次話題情報予測部１０３の構成と詳細動作、ならびに対話進行部１０１における新規話題情報導入が必要か否かの判定に関する詳細動作である。従って、本実施の形態のブロック図は図１、動作のフローチャートは図２となる。ただし、次話題情報予測部１０３は図１２のようになり、図２における新規話題情報導入判定（ステップＳ２０３）と、次話題情報予測処理（ステップＳ２０５、ステップＳ２０９）の詳細動作が第１の実施の形態とは異なる。以下、本実施の形態における次話題情報予測部１０３について説明する。

本実施の形態における次話題情報予測部１０３について図１３、１４を用いて説明する。図１４は話題手順データベースの内容を示す。

本実施の形態の次話題情報予測部１０３は予測処理部１２０１と、話題手順データベース１２０２、話題構造テーブル４０２を備えている。話題構造テーブル４０２は第１の実施の形態のものと同様であるので詳細な説明は割愛する。

予測処理部１２０１は話題手順データベース１２０２、話題構造テーブル４０２を参照して上述の新規話題の導入が必要な状況である（Ａ）現在の話題を解決した時、（Ｂ）現在の話題を解決する手順として別の話題情報を利用する時に、遷移可能性のある話題情報群を予測する（ステップＳ２０５、ステップＳ２０９）。予測処理部１２０１の詳細は後述する。

話題手順データベース１２０２は話題遷移手順を格納するデータベースである。図１４では話題遷移手順として話題の利用関係を採用し、話題の利用関係をグラフで表現している。即ち、グラフの各ノードが各話題を表現している。各話題における属性値を取得するために別の話題を利用することをアークで表現しており、属性値を取得する対象の属性をアーク内の文字で表している。例えばアーク１３０１は『「ルート設定」の属性「目的地」の属性値を取得するために話題「目的地設定」を呼び出す』ことを表現している。本実施の形態ではこのような利用・被利用関係において、別の話題を利用する側を「親話題」と呼び、利用される側を「子話題」と呼ぶ。

「目的地設定」の属性「目的地」などを決定するために場所を検索する話題も必要であるが、図１４の例ではシナリオ設計者は話題遷移手順として確定している「ルート設定」、「目的地設定」、「経由地設定」に関するグラフのみを登録している。このように話題手順データベース１２０２には全話題に関する全体の話題遷移手順ではなく、シナリオ設計者が意図する部分のみに対応する断片的な話題遷移手順を登録する。断片的な話題遷移手順が複数ある場合は個別に登録することが可能である。

話題遷移手順として確定している状態は、特定の属性の属性値を取得するための特定の手順が存在する場合としてシナリオ設計者が指定できる。例えば「ルート設定」の「目的地」を決定するための手順は話題「目的地設定」に組み込まれている場合は確定しているといえる。逆に「目的地設定」の属性「目的地」のための場所検索方法として「ジャンル検索」、「住所検索」があるが、「ジャンル検索」、「住所検索」は共に目的地設定のための手順ではなく経由地設定でも利用可能であり、どちらを利用するかはシナリオ設計者が予め指定できない（対話中に決定される）。このような場合は話題遷移手順として確定していないため、図１４のグラフでは場所検索の話題へのリンクが定義されていない。

一方、「目的地設定」の属性「目的地」の決定方法として有効な場所検索方法が「住所検索」のみであるとシナリオ設計者が指定する場合は、話題手順データベース１２０２は図１４の話題遷移手順に「住所検索」を「目的地設定」の子話題として追加する。或いは「目的地」の決定方法として有効な手順が「住所検索」、「ジャンル検索」に特定されるならばこの両者を「目的地設定」の子話題として追加する。また、「目的地設定」からだけでなく「経由地設定」の「経由地」の決定方法としても「住所検索」、「ジャンル検索」を使用するとシナリオ設計者が指定する場合は、「経由地設定」からも「住所検索」、「ジャンル検索」を子話題として登録する。この場合は「住所検索」、「ジャンル検索」の親話題は複数になる（図１５）。

対話進行部１０１における新規話題情報の導入判定（ステップＳ２０３）は、基本的に話題手順データベース１２０２に基づく導入判定を行い、その結果が新規話題情報の導入を実行しないという判定結果であれば、話題構造テーブル４０２に基づく新規話題情報導入判定を行うという処理となる。

まず（Ａ）現在の話題を解決した時の判定処理について説明する。対話進行部１０１において現在の話題を解決したことを検出すると、現在の話題の対話結果を利用する手順があるかどうかを話題手順データベース１２０２に基づき確認する。確認の結果、話題手順データベース１２０２にそのような手順が登録されていれば場合（Ａ）に該当する（ステップＳ２０３Ｙｅｓ、ステップＳ２０４Ｙｅｓ）と判定し、登録されていなければ第１の実施の形態で説明した場合（Ａ）の判定処理を行う。

話題手順データベース１２０２に基づき現在の話題の対話結果を利用する手順があるかどうかは、現在の話題の親話題が話題手順データベース１２０２に定義されていれるかどうかで判定することができる。親話題が定義されていれば現在の話題の対話結果を利用する手順があると判定する。

次に（Ｂ）現在の話題を解決する手段として別の話題を利用する時の処理について説明する。対話進行部１０１において現在の話題で属性値を取得する属性を決定した時に、その属性値を取得するために利用する手順があるかどうかを話題手順データベース１２０２に基づき確認する。確認の結果、話題手順データベース１２０２にそのような手順が登録されていれば場合（Ｂ）に該当する（ステップＳ２０３Ｙｅｓ、ステップＳ２０４Ｎｏ）と判定し、登録されていなければ、話題構造テーブル４０２に基づく判定を行う。話題構造テーブル４０２に基づく判定は、第１の実施の形態のものと同様であるので詳細は省略する。

話題手順データベース１２０２に基づき取得対象の属性値を取得するための手順があるかどうかは、属性値を取得すると決定した属性が子話題へのアークを有する属性であるかどうかで判定することができる。子話題へのアークが存在する場合であれば取得対象の属性値を取得するための手順があると判定する。

続いて次話題情報予測部１０３における予測処理部１２０１の詳細動作について説明する。予測処理部１２０１は（Ａ）「現在の話題を解決した時」の遷移可能性のある話題情報の予測（ステップＳ２０５）と、（Ｂ）「現在の話題を解決する手順として別の話題情報を利用する時」の遷移可能性のある話題情報の予測（ステップＳ２０９）とで処理が異なる。以下ステップＳ２０５、ステップＳ２０９のそれぞれについて説明する。

予測処理部１２０１のステップＳ２０５における処理について説明する。ステップＳ２０５における処理はまず話題手順データベース１２０２に基づき遷移可能性のある話題情報を取得し、その結果遷移可能性のある話題情報を取得できなかった場合は話題構造テーブル４０２に基づき遷移可能性のある話題情報を取得する。次話題情報予測部１０３は予測処理部１２０１によって取得された話題情報群を予測結果として遷移話題情報選択部１０２に通知する。尚、話題構造テーブル４０２に基づく遷移可能性のある話題情報の取得処理は第１の実施の形態における予測処理部４０１の動作（ステップＳ２０５）と同様であるので詳細説明は省略する。

話題手順データベース１２０２に基づくステップＳ２０５の処理について説明する。ステップＳ２０５では現在の話題を解決した時に実行するものであるので、現在の話題に関する対話結果を利用できる話題情報への遷移を行えば継続性のある対話が可能となる。従って、ステップＳ２０５の処理では話題手順データベース１２０２から解決した話題の親話題全てを遷移可能性のある話題として選択する。

続いて予測処理部１２０１は遷移可能性のある話題情報を作成する。作成手順は次のようになる。まず、対話進行状況が初期状態の話題情報を遷移可能性のある各話題について作成する。次に、解決した話題の対話結果を親話題に反映させる。少なくとも親話題と連結しているアークに指定されている属性は解決した話題の対話結果を用いて更新する。シナリオ設計者が指定した話題遷移手順に属性値の受け渡し方法があればそれに従う。また、新規話題情報と解決した話題情報で共通の属性の属性値を新規話題情報に代入するなどの処理も併用することが可能である。最後に予測信頼度を与える。予測信頼度は解決した話題の親話題が単独であるかどうかに基づいて決定する。親話題が単独であれば対話の手順として確定しているので予測信頼度が高いものとする。

予測処理部１２０１のステップＳ２０９における処理について説明する。ステップＳ２０９における処理はまず話題手順データベース１２０２に基づき遷移可能性のある話題情報を取得し、その結果遷移可能性のある話題情報を取得できなかった場合は話題構造テーブル４０２に基づき遷移可能性のある話題情報を取得する。次話題情報予測部１０３は予測処理部１２０１によって取得された話題情報群を予測結果として遷移話題情報選択部１０２に通知する。尚、話題構造テーブル４０２に基づく遷移可能性のある話題情報の取得処理は第１の実施の形態における予測処理部４０１の動作（ステップＳ２０９）と同様であるので詳細説明は省略する。

話題手順データベース１２０２に基づくステップＳ２０９の処理について説明する。ステップＳ２０９では現在の話題を解決するために別の話題を利用する時に実行されるので、現在の話題で解決しようとする属性を解決する手順の話題への遷移を行えば継続性のある対話が可能となる。従って、ステップＳ２０９では属性値を取得する属性を付与されたアークで辿れる子話題を遷移可能性のある話題として選択する。

続いて予測処理部１２０１は遷移可能性のある話題情報を作成する。作成手順は次のようになる。まず、対話進行状況が初期状態の話題情報を遷移可能性のある各話題について作成する。シナリオ設計者が指定した話題遷移手順に属性値の受け渡し方法があればそれに従う。この時に、新規話題情報と現在の話題情報で共通の属性の属性値を新規話題情報に代入するなどの処理も併用することが可能である。次に、予測信頼度を与える。予測信頼度は該当する子話題が単独であるかどうかについて決定する。子話題が単独であれば対話の手順として確定しているので予測信頼度が高いものとする。

次に、具体例として、カーナビに本発明を適用した場合を例に、本実施の形態における対話進行部１０１の判定処理及び予測処理部１２０１の動作について図２、図１４、図１６を参照してより詳細に説明する。なお、図１４は本説明例における話題手順データベース１２０２の内容であり、図１６は話題構造テーブル４０２の内容である。

「ジャンル検索」を解決し、対話結果として“ビストロ〇〇”を得た場合について説明する。対話処理部１０１は、話題手順データベース１２０２（図１４）に「ジャンル検索」話題が登録されていないため、親話題の取得に失敗する。従って第1の実施の形態の判定に基づき場合（Ａ）に該当すると判定する（ステップＳ２０３Ｙｅｓ、ステップＳ２０４ Ｙｅｓ）。

ステップＳ２０５において、話題手順データベース１２０２（図１４）に「ジャンル検索」話題が登録されていないため、次話題予測部１２０１は話題手順データベース１２０２から親話題を取得することに失敗する。次に話題構造テーブル４０２（図１６）に基づき遷移可能性のある話題を抽出し、結果として「目的地設定」、「経由地設定」を取得する。従って次話題情報予測部１０３は、遷移可能性のある話題情報の予測結果として「目的地設定（目的地：ビストロ〇〇）」、「経由地設定（経由地：ビストロ〇〇）」を出力する（ステップＳ２０５）。遷移可能性が２つあるので遷移話題情報選択部１０２によってどちらにするか問い合わせるように動作する（ステップＳ２０６）。

「目的地設定（目的地：ビストロ〇〇）」を解決した場合について説明する。対話処理部１０１は、話題手順データベース１２０２（図１４）から親話題として「ルート設定」があることを確認する。従って話題（Ａ）に該当すると判定する（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｙｅｓ）。

ステップＳ２０５において、話題手順データベース１２０２（図１４）から次話題予測部１２０１は親話題として「ルート設定」を取得する。従って次話題予測部１２０１は遷移可能性のある話題情報の予測結果として、解決した話題情報の内容と親話題を辿ったアークの属性情報を利用して「ルート設定（目的地：ビストロ〇〇、経由地：φ）」を作成する。親話題が単独なので予測信頼度は高いと判定されているので、遷移話題情報選択部１０２ではユーザに問い合わせずに「ルート設定」を選択する（ステップＳ２０６）。その後対話進行部１０１において、「ルート設定」を解決するための対話を実行する（ステップＳ２０２）。この場合は属性「経由地」に属性値が指定されていないため、経由地を決定するようにユーザとの対話を進行する。

「ルート設定（目的地：ビストロ〇〇、経由地：φ）」における属性「経由地」の属性値を取得すると対話進行部１０１が決定した場合について説明する。対話進行部１０１は、話題手順データベース１２０２（図１４）から属性「経由地」に子話題が指定されていることを確認する。従って場合（Ｂ）であると判定する（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏ）。

次話題予測部１２０１はステップＳ２０９で話題手順データベース１２０２（図１４）に基づき「ルート設定」の子話題として「経由地設定」を取得し、遷移可能性のある話題情報として「経由地設定（経由地：φ）」を作成する。子話題が単独なので予測信頼度は高いと判定されているので、遷移話題情報選択部１０２ではユーザに問い合わせずに「経由地設定」を選択する（ステップＳ２１０）。その後対話進行部１０１において「経由地設定」を解決するための対話を実行する（ステップＳ２０２）。この場合は属性「経由地」に属性値が指定されていないため、経由地を決定するようにユーザとの対話を進行する。

「経由地設定（経由地：φ）」における属性「経由地」を決定すると対話進行部１０１が決定した場合について説明する。対話進行部１０１は、話題手順データベース１２０２（図１４）から属性「経由地」に子話題が登録されていないことを確認する。従って第1の実施の形態の判定に基づき場合（Ｂ）に該当すると判定する（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏ）。

ステップＳ２０９では、話題手順データベース１２０２（図１４）に「経由地」の子話題が登録されていないため、次話題予測部１２０１は話題手順データベース１２０２から子話題を取得することに失敗する。次に話題構造テーブル４０２（図１６）に基づき遷移可能性のある話題を抽出し、結果として「ジャンル検索」、「住所検索」を取得する。次話題情報予測部１０３は遷移可能性のある話題情報の予測結果として「ジャンル検索（ジャンル名：φ）」、「住所検索（都道府県名：φ、市区町村名：φ）」を出力する。遷移話題情報選択部１０２では、候補が複数あるのでどちらにするかを問い合わせる（ステップＳ２１０）。

以上のように本実施の形態では、シナリオ設計者によって意図的に定められた断片的な話題遷移手順を話題手順データベース１２０２に格納し、これを優先的に適用することで、新規話題情報への遷移をより適切に決定することが可能となる。

また、本実施の形態においては、（Ａ）現在の話題を解決した際の話題手順データベース１２０２を使用した新規話題情報の導入処理を、現在の話題を更新した時に実行することも可能である。即ち、現在の話題を更新した時にその話題の親話題を話題手順データベース１２０２から取得し、取得結果の親話題が一つであれば予め新規話題情報として導入することを決定する。親話題を新規話題情報として導入する場合には、現在の話題を親話題に入れ子状に代入すれば良い。親話題が単独なのであれば話題遷移手順は確定しているので、現在の話題が解決した時に導入する新規話題として予め親話題を導入することが可能となる。また、このような親話題の話題情報を導入する処理を親話題の導入が出来なくなるまで遡及的に行っても良い。

ここで、話題手順データベース１２０２の構築コストについて説明する。話題手順データベースは「特定の属性の属性値を取得するために利用する話題」を定義するものである。これは特定の手順を必要とする話題の話題シナリオを設計するためには必須の情報であるので、話題間シナリオのような話題遷移を指定する従来手法と比較して設計のコストが増加するものではない。

また、本実施の形態においても対話装置運用中であっても話題の追加・削除といった話題構成の変更が容易である。従ってアプリケーションの機能構成の変更による対話シナリオの変更が容易となる。新たな話題を導入する際に話題登録情報が必要であるのは第1の実施の形態と同様であるが、話題登録情報における新規話題導入の予測に使用する情報として話題の構造情報に加えて必要に応じて断片的な話題遷移手順を追加する。

話題登録情報を登録する作業としては話題の登録、話題構造テーブル４０２の登録と共に、断片的な話題遷移手順を話題手順データベース１２０２に登録する。一方、話題を削除する時の作業としては、対象の話題の削除、話題構造テーブル４０２から対象の話題の構造情報を削除すると共に話題手順データベース１２０２から対象の話題を含む話題遷移手順を取り除く。以上の話題登録・削除においても、個別の話題シナリオに対する修正処理は必要ではなく容易に話題構成の変更が可能である。

以上のように第２の実施の形態に係わる対話装置によれば、断片的な話題遷移手順の指定を許可しながらも対話シナリオ設計における話題間遷移を指定するコストを第１の実施の形態と同等に削減することが可能である。同時に対話システム運用中における話題構成の変更や、アプリケーションの機能構成の変更も容易に実行することが可能となる。

なお、上述の例では話題手順データベース１２０２と話題構造テーブル４０２とを併用して次話題情報予測部１０３が遷移可能性のある話題情報を出力しているが、本実施の形態はそのような対話進行方法に限定されるものではない。例えば、話題手順データベース１２０２を断片的な話題遷移手順の集合ではなく、全話題の話題遷移手順を統合した情報としても良い。この場合は話題構造テーブル４０２が不要となる。

また、上述の例では断片的な話題遷移手順を全て話題手順データベース１２０２に格納するように記述しているが、各話題シナリオに付随させておいても良い。この場合は対話進行部１０１、次話題情報予測部１０３が必要に応じて話題シナリオにアクセスし、話題遷移手順を取得する。

また、本実施の形態においても第１の実施の形態と同様に話題手順データベース１２０２を対話装置外に配置しても良い。対話装置外に格納する場合はネットワークと介する等によって話題手順データベース１２０２を参照する。

以上のようにシナリオ設計者は話題構造テーブル４０２と、特定の手順が必要な部分に限り断片的な話題遷移手順を作成すれば、補完処理によって他の話題との接続関係を構成することができる。従って、話題手順データベース１２０２の構築コストを削減することが可能となる。

以上のように、断片的な話題遷移手順に基づいて新規話題導入が必要な状況か否かを判定し、シナリオ設計者が全話題における話題遷移手順を作成しなくとも遷移話題情報の選択を行うものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第３の実施の形態）
第１、第２の実施の形態では、新規話題情報を必要とする時に遷移話題情報を選択して対話を継続させることを目的とするものであった。この第３の実施の形態では遷移話題情報を選択する際のユーザの負担を軽減する対話装置を提案する。

上述の各実施の形態においては、遷移可能性のある話題情報を次話題情報予測部１０３によって予測し、その予測結果が複数存在する場合は遷移話題情報選択部１０２においてユーザに予測結果である話題情報を提示してどの話題に遷移するかを問い合わせて遷移話題情報を選択している。しかしながら、次話題情報予測部１０３において予測結果の話題情報が多数作成された場合は、多数の話題情報を列挙して問い合わせなければならない。

ユーザに遷移可能性のある話題情報を提示してどれに遷移させるかを問い合わせるための質問（遷移対象選択質問）の文章は、予測結果にある話題情報の数に応じて長くなる。特に多数の話題情報を列挙して問い合わせると、対話装置による問い合わせ発話は非常に長くなってしまう。このような長い質問文はユーザとって煩わしく、聞き取りにも負担がかかってしまう。本実施の形態は遷移話題情報選択部１０２における遷移対象選択質問の発話によって生じるユーザの負担を軽減するものである。

本実施の形態と第１の実施の形態との変更点は遷移話題情報選択部１０２の詳細動作のみである。従って、本実施の形態のブロック図は図１、動作のフローチャートは図２となる。ただし、遷移話題情報選択部１０２の動作である図２における遷移話題情報の選択処理（ステップＳ２０６、ステップＳ２１０）の詳細動作が第1の実施の形態とは異なる。以下、本実施の形態における遷移話題情報選択部１０２について説明する。

本実施の形態おける遷移話題情報選択部１０２の動作について説明する。本実施の形態における遷移話題情報選択部１０２は、遷移対象選択質問の質問文を簡略化するために、遷移対象選択質問でユーザに提示する話題情報の個数をしきい値以内の個数に絞り込む。絞り込む基準は予測信頼度が高いものから順に採用するものとする。以上の処理は図２におけるステップＳ２０６、ステップＳ２１０において共通である。

次に、具体例として、カーナビに本発明を適用した場合を例に、本実施の形態における予測処理部１２０１の動作について図２、図１７を参照してより詳細に説明する。なお、図１７本説明例における話題構造テーブル４０２の内容である。尚、図１７において「距離計算」は現在地から指定の場所までの距離計算を実行するための話題であり、「周辺ジャンル検索」は指定の場所の周辺にある施設をジャンルから検索するための話題である。また次話題情報予測部１０３は第1の実施の形態による動作を行う。

「ジャンル検索」を解決して“ビストロ〇〇”を場所検索結果として取得した場合（ステップＳ２０３Ｙｅｓ、ステップＳ２０４Ｙｅｓ）、次話題情報予測部１０３は第1の実施の形態と同様に遷移可能性のある話題情報を予測結果として出力する（ステップＳ２０５）。出力される予測結果は「目的地設定（目的地：ビストロ〇〇）」、「経由地設定（経由地：ビストロ〇〇）」、「距離計算（端点：ビストロ〇〇）」、「周辺ジャンル検索（基準点：ビストロ〇〇、ジャンル名：φ）」である。

ステップＳ２０６において遷移話題情報選択部１０２がこれら全てを利用した遷移対象選択質問は次のようになる。「“ビストロ〇〇”で何をしますか？目的地設定、経由地設定、距離計算、周辺施設の検索ができます。」
本実施の形態における遷移話題情報選択部１０２においてはユーザに提示する内容を絞り込む。第1の実施の形態によると通知された予測結果の予測信頼度は何れも「低」であるので、通知された順序（或いはランダム）に基づきしきい値までの個数の話題情報を選択する。ここでしきい値が２であったとすると、遷移対象選択質問の質問文で提示する話題情報として「目的地設定」「経由地設定」を使用すると決定できる。従ってステップＳ２０６でユーザに問い合わせる遷移対象選択質問の質問文は次のようになる。「“ビストロ〇〇”で何をしますか？目的地設定、経由地設定などができます。」
続いて「目的地設定」の属性「目的地」の属性値を取得すると対話進行部１０１が決定した場合（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏ）について説明する。この場合においても、次話題情報予測部１０３は第1の実施の形態と同様に遷移可能性のある話題情報を予測結果として出力する（ステップＳ２０９）。出力される予測結果は「周辺ジャンル検索（基準点：ビストロ〇〇、ジャンル名：φ）」、「住所検索（都道府県名：φ、市区町村名：φ）」、「登録名称検索（登録名称：φ）」である。

ステップＳ２０９において遷移話題情報選択部１０２がこれら全てを利用した遷移対象選択質問の質問文は次のようになる。「目的地の設定方法を指定して下さい。周辺施設の検索、住所検索、登録名称検索が利用できます。」
本実施の形態における遷移話題情報選択部１０２においてはユーザに提示する内容を絞り込む。ステップＳ２０６の時と同様に提示する話題情報を２つまで絞り込むと、ユーザに問い合わせる遷移対象選択質問の質問文は次のようになる。「目的地の設定方法を指定して下さい。周辺施設の検索、住所検索などが利用できます。」
以上のように第３の実施の形態に係わる対話装置によれば、新規話題の導入時に発生する遷移対象選択質問の質問文を簡略化し、ユーザの聞き取り負担を軽減することが可能である。

上述の例では次話題情報予測部１０３が第1の実施の形態のように動作するように記述しているが、本実施の形態はそのような対話方法に限定されるものではない。第２の実施の形態による予測動作であっても構わない。また、話題を解決した時、属性値を取得する時に導入すべき新規話題を予測する手法であればどのようなものでも適用が可能である。

また、遷移話題情報選択部１０２において、単純なしきい値処理のみで遷移対象選択質問に利用する話題情報を決定していたが、次話題情報予測部１０３から通知される予測結果に付与されている予測信頼度に基づいて遷移対象選択質問に利用する話題情報を決定しても良い。例えば、話題情報を予測信頼度順に並べて隣り合う話題情報の予測信頼度の差分が一定値より大きい場合は、その話題情報以下の話題情報は遷移対象選択質問に利用しないようにする、或いは最上位の予測信頼度からの差分が所定の値以下である話題情報だけ遷移対称選択質問に利用する、などの手法が考えられる。或いは上述のしきい値処理と組み合わせて決定しても良い。

また、対話進行部１０１において、ユーザ入力を受付ける際に音声認識エンジンを使用する場合に、音声認識率の向上のために問い合わせのために提示した内容のみに認識対象語彙を限定するなどの方策が考えられる。しかし、本実施の形態においては提示した話題情報以外の内容をユーザが指定する場合があることを考慮し、次話題情報予測部１０３が出力した話題情報全てに関する認識対象語彙を有効としても良い。或いは、音声認識エンジンの認識結果として実話題情報予測部１０３による予測結果が出現しやすいように音声認識エンジンを操作しても良い。

また、対話進行部１０１において、ユーザ入力を受理した時に入力解釈処理を行うが、この入力解釈処理においても、次話題情報予測部１０３から出力された話題情報に該当する解釈結果を優先するようにしても良い。

以上のように、新規話題の導入時に発生する遷移対象選択質問の質問文に利用する話題情報の個数を制限することで、遷移対象選択質問の質問文を簡略化するものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第４の実施の形態）
第３の実施の形態においては、遷移話題情報選択部１０２は遷移対象選択質問の質問文に利用する話題情報を単純な手法で絞り込んでいた。この第４の実施の形態では詳細なルールに基づいてより適応的に遷移対象選択質問に利用する話題情報を絞り込む対話装置を提案する。

本実施の形態と第１の実施の形態との変更点は遷移話題情報選択部１０２の構成と詳細動作のみである。従って、本実施の形態のブロック図は図１、動作のフローチャートは図２となる、また、次話題情報予測部１０３の詳細ブロック図は図４となる。ただし、遷移話題情報選択部１０２の構成は図１８になり、その動作である図２における遷移話題情報の選択処理（ステップＳ２０６、ステップＳ２１０）の詳細動作が第1の実施の形態とは異なる。以下、本実施の形態における遷移話題情報選択部１０２について説明する。

本実施の形態における遷移話題情報選択部１０２について図１８を参照して説明する。

本実施の形態における遷移話題情報選択部１０２は選択部１８０１と絞り込みルール記憶部１８０２を備えている。

選択部１８０１は次話題情報予測部１０３から通知される予測結果（遷移可能性のある話題情報）から、遷移話題情報を一つ選択して対話進行部１０１に出力する。予測結果にある話題情報が複数ある場合は遷移対象選択質問をユーザに提示し、ユーザが選択した話題情報を遷移話題情報とする。以上の処理は第1の実施の形態における遷移話題情報選択部１０２の動作（ステップＳ２０６、ステップＳ２１０）と同様であるので詳細は割愛する。

選択部１８０１は上記の遷移話題情報を選択する処理に加えて、遷移対象選択質問を行う際にユーザに提示する話題情報の個数を絞り込む。絞込みの際に絞り込みルール記憶部１８０２に記憶されているルールに基づき提示する話題情報を絞り込む。この絞り込み処理についての詳細は後述する。

絞り込みルール記憶部１８０２について図１９を参照して説明する。絞り込みルール記憶部１８０２は、遷移対象選択質問を行う際にユーザに提示する話題情報を絞り込むためのルールを管理する。絞り込みルール記憶部１８０２で管理するルールには、絞り込みルールとその強度の対で記憶されている。強度は絞り込みルールの優先度合いを示すパラメータである。絞り込みルールは話題解決時に適用するルールと、話題情報の属性の属性値を取得するための別話題を呼び出す際に適用するルールとが存在する。各絞り込みルールは解決した話題の種類に基づくもの（１９０１）や、現在の話題情報（対話状態）に基づくもの（１９０３）、アプリケーションやユーザの状態（１９０２）などを条件として使用する。

選択部１８０１における遷移対象選択質問時に利用する話題情報の絞り込み処理について説明する。選択部１８０１は絞り込みルールが適用可能である話題情報に適用可能な絞り込みルールの強度を与え、強度が大きい話題情報から順に遷移対象選択質問に利用する。複数のルールが適用可能な話題情報が存在する場合は、適用可能なルールの強度の総和をその話題情報の強度として採用する。選択部１８０１はしきい値以下の個数の話題情報を遷移対象選択質問に利用する。強度で差が出なかった場合はランダムに選択する。以上の処理はステップＳ２０６、ステップＳ２１０において共通であるが、適用する絞り込みルールが異なる（ステップＳ２０６の場合は「話題解決時のルール」、ステップＳ２１０の場合は「他話題利用時のルール」）。

次に、具体例として、カーナビに本発明を適用した場合を例に、本実施の形態における選択部１８０１の動作について図２、図１７、図１９、図２０を参照してより詳細に説明する。なお、図１７は本説明例における話題構造テーブル４０２の内容である。図２０は本説明例で使用する対話例である。

ＵＳＲ１０からＳＹＳ１１にかけてユーザから導入された話題「住所検索」を解決している（ステップＳ２０２）。ＳＹＳ１１を提示した時には対話進行部１０１は話題の解決を検出する（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｙｅｓ）。次話題情報予測部１０３は遷移可能性のある話題情報の予測を実行する（ステップＳ２０５）。ステップＳ２０５では、次話題情報予測部１０３が図１７の話題構造テーブルを参照して、遷移可能性のある話題情報を予測結果として出力する。予測結果は「目的地設定（目的地：〇〇県△△市）」、「経由地設定（経由地：〇〇県△△市）」、「距離計算（端点：〇〇県△△市）」、「周辺ジャンル検索（基準点：〇〇県△△市、ジャンル名：φ）」である。

遷移話題情報選択部１０２における選択部１８０１は、予測結果に話題情報が複数存在するので、遷移対象選択質問のための絞り込み処理を実行する。図１９における話題解決時のルールを対象として強度を算出する。ルール１９０１を適用すると、“〇〇県△△市”は住所検索結果であるので「周辺ジャンル検索」の強度として５が与えられる。次にルール１９０２を適用すると、現在カーナビのルートが未設定であるので「目的地設定」の強度として３が与えられる。従って、選択部１８０１は絞り込み結果として得られる「周辺ジャンル検索」（強度５）、「目的地設定」（強度３）の順に遷移対象選択質問への利用を優先すると判定する。ここで、絞り込み個数のしきい値を２とすると、遷移対象選択質問にはこれらの２つの話題情報を利用すると判定される。質問文における提示順序も強度の順に行うとすると、遷移対象選択質問としてユーザにＳＹＳ１２を提示する。

続いてＵＳＲ１２が入力された。ＵＳＲ１２は「周辺ジャンル検索」を採用する意図の入力であると判断されるので、選択部１８０１は遷移話題情報として「周辺ジャンル検索（基準点：〇〇県△△市、ジャンル名：φ）を選択し、対話進行部１０１に通知する（ステップＳ２０６終了）。

対話進行部１０１は通知された遷移話題情報を現在の話題として設定し（ステップＳ２０７Ｙｅｓ，ステップＳ２０８）、ユーザとの対話を継続する（ステップＳ２０２）。ＳＹＳ１３、ＵＳＲ１３によって現在の話題情報である「周辺ジャンル検索（基準点：〇〇県△△市、ジャンル名：レストラン）」を解決しＳＹＳ１４を出力する。対話進行部１０１は「周辺ジャンル検索」を解決したと判定する（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｙｅｓ）。そして、次話題情報予測部１０３は遷移可能性のある話題情報の予測を実行する（ステップＳ２０５）。ステップＳ２０５では、次話題情報予測部１０３が図１７の話題構造テーブルを参照して、遷移可能性のある話題情報を予測結果として出力する。予測結果は「目的地設定（目的地：ビストロ〇〇）」、「経由地設定（経由地：ビストロ〇〇）」、「距離計算（端点：ビストロ〇〇）」、「周辺ジャンル検索（基準点：ビストロ〇〇、ジャンル名：φ）」である。

遷移話題情報選択部１０２における選択部１８０１は、予測結果に話題情報が複数存在するので、遷移対象選択質問のための絞り込み処理を実行する。図１９における話題解決時のルールを対象として強度を算出する。ルール１９０１を適用できる話題情報が存在しないので、どの話題にも強度は与えられない。次にルール１９０２を適用すると、現在カーナビのルートが未設定であるので「目的地設定」の強度として３が与えられる。従って、選択部１８０１は絞り込み結果として得られる「目的地設定」（強度３）を遷移対象選択質問への利用に優先すると判定する。ここで、絞り込み個数のしきい値を２とすると、遷移対象選択質問には話題情報「目的地設定」を利用すると判定される。遷移対象選択質問としてユーザにＳＹＳ１４を提示する。

以上は話題解決時のルールを適用した際の対話例である。現在の話題情報の属性値を取得するために他の話題を使用する場合（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏ，ステップＳ２０９、ステップＳ２１０）についても同様に動作する。但し、ステップＳ２１０の処理において選択部１８０１は遷移対象選択質問のための絞り込み処理に「他話題利用時のルール」（図１９）を参照して話題情報の強度を算出する。従って、「目的地設定」の属性「目的地」の属性値を取得する状況においては、選択部１８０１は遷移対象選択質問のための絞り込み処理の結果として「住所検索」を提示するように動作する。それ以外の状況では次話題情報予測部１０３の予測結果からランダムに２個選択する。

以上のように絞り込みルールを適用することで、遷移対象選択質問時に対話状態にあった話題情報をユーザに提示することが可能となる。従ってよりユーザフレンドリーな遷移対象選択質問を提示できるようになり、ユーザにかかる負担は減少する。

本実施の形態における絞り込みルールの設計コストについて説明する。本実施の形態における絞り込みルールは話題シナリオと別に新規に設計すべき情報であるが、話題遷移を行うために必須の情報ではない。即ち絞り込みルールが無くとも対話自体は継続が可能であり、全話題・全対話状態を包括的にカバーする絞り込みルールを設計する必要はない。対話システム動作中に回避させたい質問文を生成する場合だけ付加的に絞り込みルールを追加することが可能である。従って、全話題について話題間シナリオを設計するよりも設計にかかるコストを削減することが可能である。

本実施の形態においては対話装置運用中に話題の削除を行うと、無効になる絞り込みルールが現れることがあるが、例えばステップＳ２０６、ステップＳ２１０において絞り込みルールの適用を検討する際に対象とする話題が存在しないことを検出した場合は、遷移話題情報選択部１０２がその絞り込みルールが無効であると判定し、無効なルールは絞り込みルール記憶部１８０２から削除すればよい。従って、本実施の形態による絞り込みルールの追加による対話装置運用中の話題構成変更のコストは増加しない。

以上のように第４の実施の形態に係わる対話装置によれば、新規話題の導入時に発生する遷移対象選択質問の質問文を簡略化する際に、絞り込みルールを適用してより適応的に質問文に利用する話題情報を選択する。従って対話状況に即した遷移対象選択質問をユーザに提示することが可能となり、ユーザの聞き取り負担を軽減することが可能である。

上述の例では絞り込みルール記憶部１８０２が記憶する絞り込みルールの強度に基づいて遷移対象選択質問への利用が望ましい話題情報を選択しているが、本実施の形態はそのような対話方法に限定されるものではない。例えば、絞り込みルールとして望ましくない条件の強度を指定し、遷移対象選択質問への利用が望ましくない話題情報を除外する形式でも良く、或いは、望ましい話題情報の選択との組み合わせでも良い。

また、上述の例では解決した話題の種類や、現在の話題情報（対話状態）、アプリケーションやユーザの状態に基づき絞り込みルールを定義しているが、対話の履歴情報に基づくルール、時節を利用したルールを定義しても良い。

また、上述の例では絞り込みルールを用いて遷移対象選択質問で列挙する話題情報を選択しているが、遷移対象選択質問として「対話装置からお奨めする話題情報に遷移しても良いか」という推奨形式の質問を出力させても良い。この場合は、絞り込みルールの強度として「お奨め」であることを付与しておき、絞り込みルール適用後に「お奨め」ルールに該当する話題情報について実行してよいか問い合わせる。例えば、時節を利用したルールとして「付近でお祭りがある場所を検索した場合は、周辺のイベント情報をお奨めする」（強度＝「お奨め」）を追加する。この絞り込みルールが適用された場合にはまずお奨めの遷移対象選択質問として「〇〇県△△市では現在お祭りが開催されています。周辺のイベント情報を検索しますか？」などという質問を行い、ユーザが許諾したら周辺のイベント情報検索を遷移話題情報として選択し、ユーザが拒否したら通常の遷移対象選択質問「〇〇県△△市で何をしますか？・・・」をユーザに質問し、遷移話題情報の選択を行う。

また、本実施の形態においても第１の実施の形態と同様に絞り込みルール記憶部１８０２を対話装置外に配置しても良い。対話装置外に格納する場合はネットワークと介する等によって絞り込みルール記憶部１８０２を参照する。

以上のように、新規話題の導入時に発生する遷移対象選択質問の質問文に利用する話題情報の個数を必要に応じて追加する絞り込みルールを用いて絞り込むことで、遷移対象選択質問の質問文を簡略化するものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第５の実施の形態）
第４の実施の形態においては、遷移話題情報選択部１０２は遷移対象選択質問の質問文に利用する話題情報をシナリオ設計者が別途設計する絞り込みルールで絞り込んでいた。この第５の実施の形態では話題選択の頻度情報に基づいてより適応的に遷移対象選択質問に利用する話題情報を絞り込む対話装置を提案する。

本実施の形態は第３の実施の形態を基本とする。第３の実施の形態との変更点は対話装置全体の構成図が図２１となり、頻度情報データベース２１０４が追加されたことと、対話進行部２１０１、遷移話題情報選択部２１０２、次話題情報予測部２１０３の各部に頻度情報を取り扱うための動作が追加されたことである。従って本実施の形態の動作のフローチャートは図２となるが、フローチャート内の各ステップにおいて頻度情報を取り扱う手続きが追加される。以下、本実施の形態における対話装置について説明する。

図２１は、本発明の第５の実施の形態に係わる対話装置を示すブロック図である。

本実施の形態に係わる対話装置は、図２１に示すように対話進行部２１０１、遷移話題情報選択部２１０２、次話題情報予測部２１０３、頻度情報データベース２１０４を備えている。

対話進行部２１０１は、現在の話題についてユーザと対話を行い、現在の話題を解決する。この詳細処理は第1の実施の形態における対話進行部１０１と同様である。本実施の形態における対話進行部２１０１は、上記の処理に加えてユーザとの対話の進行状況に応じて頻度情報データベース２１０４における頻度情報を編集する。この頻度情報編集処理については後に詳述する。

遷移話題情報選択部２１０２は、遷移話題情報を選択する。この詳細処理は第1の実施の形態における遷移話題情報選択部１０２と同様である。本実施の形態における遷移話題情報選択部２１０２は、上記の処理に加えて遷移話題情報の決定結果に基づき頻度情報データベース２１０４における頻度情報を編集する。この頻度情報編集処理については後に後述する。

次話題情報予測部２１０３は、新規話題導入が必要と判定された際に、遷移可能性のある話題情報を予測する。この詳細処理は第1の実施の形態における次話題情報予測部１０３と同様である。本実施の形態における次話題情報予測部２１０３は、上記の処理において予測結果の各話題情報に与える予測信頼度を頻度情報に基づいて編集する。この予測信頼度算出処理については後に後述する。

頻度情報データベース２１０４は、新規話題情報の導入を行う際に、遷移話題情報として選択された回数（頻度）を話題別に記憶するものである。頻度情報データベース２１０４の具体例を図２１に示す。本実施の形態における頻度情報データベース２１０４は、新規話題情報の導入が必要とされる状態別に頻度情報を管理する。即ち、現在の話題を解決した時に参照する頻度情報群（２２０１）、現在の話題の属性値を取得するために別話題を利用する時に参照する頻度情報群（２２０２）からなる。２２０１の中では更に解決した話題別の頻度情報（２２０３、２２０４）があり、２２０２の中には更に属性値を取得する属性別の頻度情報（２２０５）がある。

続いて、本実施の形態における対話装置における頻度情報を利用する処理について図２を用いて説明する。

対話進行部２１０１がユーザとの対話を行い（ステップＳ２０２）、現在の話題を解決した時（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｙｅｓ）に、次話題情報予測部２１０３は遷移可能性のある話題情報の予測を実行する（ステップＳ２０５）。

次話題情報予測部２１０３では、第1の実施の形態におけるステップＳ２０５の処理と同様にして遷移可能性のある話題情報を予測する（ステップＳ２０５）。但し、予測結果の話題情報に付与する予測信頼度を頻度情報に基づいて決定する。

次話題情報予測部２１０３は、頻度情報データベース２１０４における話題解決時に参照する頻度情報群（２２０１）の中から、解決した話題情報に対応する頻度情報を参照する頻度情報として選択する。そして、予測結果の各話題情報に該当する頻度情報を予測信頼度としてそれぞれに割り当てる。例えば「住所検索」を解決した時には頻度情報２２０３を参照する。予測結果の話題情報として「目的地設定」があれば、頻度情報２２０３を参照して予測信頼度を１０に設定する。また、予測方法に基づいて予測信頼度が高いと判定されている話題情報については頻度情報に一定のバイアス（例えば頻度情報の平均値）を与える。

次話題情報予測部２１０３による予測結果から、遷移話題情報選択部２１０２が遷移話題情報を選択する（ステップＳ２０６）。この処理は第３の実施の形態におけるステップＳ２０６の処理と同様であり、遷移対象選択質問を行う場合には頻度情報を付与された予測信頼度に基づき、ユーザに提示する話題情報を選択することになる。

本実施の形態における遷移話題情報選択部２１０２は遷移話題情報が選択されたときに、遷移話題情報の話題に対応する頻度を更新する。遷移話題情報選択部２１０２は、頻度情報データベース２１０４における話題解決時に参照する頻度情報群（２２０１）の中から、解決した話題情報に対応する頻度情報を参照する頻度情報として選択する。そして選択した頻度情報の中にある遷移話題情報の話題に対応する頻度に１を加える。遷移話題情報の選択に失敗した場合は頻度情報の編集は行わない。

一方、対話進行部２１０１がユーザとの対話を行い（ステップＳ２０２）、現在の話題の属性値を取得するために別の話題を利用する時（ステップＳ２０３Ｙｅｓ，ステップＳ２０４Ｎｏ）も、次話題情報予測部２１０３は遷移可能性のある話題情報の予測を実行する（ステップＳ２０９）。この場合の遷移話題情報を選択するための次話題情報予測部２１０３、遷移話題情報選択部２１０２（ステップＳ２０９、ステップＳ２１０）の処理は上述のステップＳ２０５、ステップＳ２０６の処理と同様である。但し、参照する頻度情報が異なる。即ちステップＳ２０９、ステップＳ２１０で参照する頻度情報群は２２０２であり、参照する頻度情報は属性値を取得しようとしている属性に基づいて決定する。

以上のようにして遷移話題情報を決定し、対話進行部２１０１は遷移話題情報を現在の話題に設定し、ユーザとの対話を継続する（ステップＳ２０２）。ここで、ユーザにより現在の話題の対話をキャンセルなどで打ち切られたとき、遷移話題情報選択部２１０２によって編集された頻度を元に戻す（１を減算する）。ユーザが誤って遷移話題情報を選択したい場合や、ユーザの翻意によって遷移話題情報から違う話題の対話に変更した場合には選択された遷移話題情報は無効となり、更新した頻度情報も無効になるため、現在の話題の対話を打ち切られた場合は頻度情報を元に戻す処理が必要となる。

次に、具体例として、カーナビに本発明を適用した場合を例に、本実施の形態における対話装置の動作について図２、図１７、図２１、図２２を参照してより詳細に説明する。なお、図１７は本説明例における話題構造テーブル４０２の内容である。

対話進行部２１０１がユーザとの対話により「住所検索」を解決し、“〇〇県△△市”を得た時（ステップＳ２０３Ｙｅｓ、ステップＳ２０４Ｙｅｓ）の次話題情報予測部２１０３は第1の実施の形態と同様にして遷移可能性のある話題情報を予測する（ステップＳ２０５）。その結果「目的地設定（目的地：〇〇県△△市）」、「経由地設定（経由地：〇〇県△△市）」、「距離計算（端点：〇〇県△△市）」、「周辺ジャンル検索（基準点：〇〇県△△市、ジャンル名：φ）」を遷移可能性のある話題情報の予測結果として得る。

次話題情報予測部２１０３は、以上の予測結果に予測信頼度を付与する。解決した話題が「住所検索」であるので頻度情報２２０３を参照し、各話題情報に該当する頻度を予測信頼度として与える。その結果「目的地設定」（予測信頼度＝１０）、「経由地設定」（予測信頼度＝５）、「距離計算」（予測信頼度＝３）、「周辺ジャンル検索」（予測信頼度＝１５）を与えることが可能である。予測方法による予測信頼度は第1の実施の形態と同様に「低」であるのでバイアスは与えない。

遷移話題情報選択部２１０２では予測結果に話題情報が複数あるので遷移対象選択質問を行うと決定する。ここで遷移対象選択質問に利用する話題情報の数のしきい値を２と設定してあるとすると、予測信頼度の高い順から「周辺ジャンル検索」、「目的地設定」を利用して質問すると決定できる。従って遷移対象選択質問の質問文は「〇〇県△△市でどうしますか？周辺の施設検索や、目的地設定が可能です」となる。これは第４の実施の形態におけるルールを適用した場合と同様の質問文である。

以上のように対話状態毎に遷移話題情報に選択された話題の回数に基づく頻度情報を用いることで、遷移対象選択質問時に対話状態にあった話題情報をユーザに提示することが可能となる。従ってよりユーザフレンドリーな遷移対象選択質問を提示できるようになり、ユーザにかかる負担は減少する。

本実施の形態における頻度情報はシナリオ設計者によるシナリオ作成とは関係なく、シナリオ構築のコスト増にはあたらない。話題の削除が発生した場合は、各頻度情報から該当する話題に関する頻度を削除すればよく、やはり登録済みの話題シナリオ等に影響を与えるものではない。

話題を単位として頻度情報を集計する利点について説明する。話題は属性値等と比較して圧倒的に種類が少なく多数の頻度情報を平滑的に得ることが可能である。また、話題の解決に基づいて頻度情報を集計する場合は、ユーザが誤って遷移話題情報を選択した場合や、途中で対話を打ち切ってしまった場合の誤った集計を是正することが可能となる。上述の例では対話進行部２１０１で実行中の対話がキャンセルされた場合などに頻度情報を元に戻す処理がこれに該当する。即ち、ユーザが意図して対話を完結させた話題に限り頻度情報を更新することが可能であるので、高品位な頻度の集計が可能となっている。

以上のように第５の実施の形態に係わる対話装置によれば、新規話題の導入時に発生する遷移対象選択質問の質問文を簡略化する際に、頻度情報を利用してより適応的に質問文に利用する話題情報を選択する。従ってシナリオ設計者によるシナリオの設計コストを削減すると同時に、対話状況に即した遷移対象選択質問をユーザに提示することが可能となり、ユーザの聞き取り負担を軽減することが可能である。

尚、上述の説明において、頻度情報の編集を遷移話題情報選択部２１０２の選択時に追加し、対話進行部２１０１で対話を打ち切られたときに削除するようにするとしているが、本実施の形態はそのような対話方法に限定されるものではない。

例えば、対話進行部２１０１で話題を解決した時に限り頻度情報を追加することが可能である。この構成では頻度集計対象の対話状態として、新規話題情報が必要となった時の対話状態を出現順に（例えばスタックで）記憶する（図２３）。頻度集計対象となっている対話状態は関連する話題の対話が打ち切られたときには連動して消去する。そして遷移話題情報選択部２１０２では頻度情報の編集を行わずに対話進行部２１０１でユーザとの対話を進行させる。そして対話進行部２１０１で現在の話題を解決した時に、頻度集計対象となっている対話状態の出現順の先頭にある対話状態に基づいて頻度情報データベース２１０４から頻度情報を探索し、解決した話題の頻度情報に１を加える。この構成では、各対話状態においてユーザが情報を取得（決定）した話題に着目した集計方法になる。例えば、「目的地設定」の「目的地」を決定するための場所検索の話題をユーザが複数回変更しても、場所検索結果が「目的地」に採用されるものであれば、「目的地」決定に利用する場所検索の話題の頻度情報に反映させることが可能である。

また、上述の説明において、頻度情報データベースを話題解決時等の対話状態により分類して集計していたが、全状態で平滑した頻度情報を集計しても良い。このようにして集計した頻度情報単体で決定したり、特定の対話状態による頻度が同じ場合に全体の頻度情報に基づいて予測信頼度を増減させたりすることが可能である。

また、上述の説明において、遷移話題情報選択部２１０２で遷移話題情報を選択しなかった場合は頻度情報データベース２１０４への更新を行わないとしていたが、「遷移なし」を集計しても良い。「遷移なし」が圧倒的に多い場合には遷移話題情報選択部２１０２における遷移話題情報の選択に失敗と動作させることが可能となる。

また、上述の説明において、頻度情報データベース２１０４は一つだけであったが、使用者別に頻度情報データベースを複数用意しても良い。この場合は利用者ごとの話題利用に関する特性に応じた遷移対象選択質問を行うことが可能となる。

また、本実施の形態においても第１の実施の形態と同様に頻度情報データベース２１０４を対話装置外に配置しても良い。対話装置外に格納する場合はネットワークを介する等によって頻度情報データベース２１０４を参照する。

以上のように、新規話題の導入時に発生する遷移対象選択質問の質問文を、頻度情報を利用して質問文に利用する話題情報を選択することで、シナリオ設計者によるシナリオの設計コストを削減すると同時に、遷移対象選択質問の質問文を簡略化するものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第６の実施の形態）
第1から第５の実施の形態においては、話題構造テーブル４０２と話題手順データベース１２０２を参照してユーザとの対話を行う対話装置に関する説明であった。この第６の実施の形態では、話題構造テーブル４０２と話題手順データベース１２０２を参照して対話シナリオにおける話題間遷移に関するルールを生成する対話シナリオ生成装置について説明する。作成された話題間遷移に関するルールは、各話題を解決するための話題シナリオと組み合わせて対話シナリオとして利用することが可能なものである。

本実施の形態における対話シナリオ生成装置の構成図を図２５に示す。本実施の形態における対話シナリオ生成装置は、編集部２５０１、補完部２５０２、出力部２５０３、話題構造テーブル４０２、話題手順データベース１２０２を備える。尚、ここで話題構造テーブル４０２と話題手順データベース１２０２はそれぞれ第1、第２の実施の形態のものと同様であるので説明は省略する。

編集部２５０１は、外部からのリクエストにより話題構造テーブル４０２と、話題手順データベース１２０２を編集する。編集の内容としては話題構造テーブル４０２に対して話題の構造情報の追加・削除と、話題手順データベース１２０２に対して話題遷移手順の追加・削除を行う。話題遷移手順を伴わない話題を追加する場合は話題手順データベース１２０２の編集は行わないが、追加された全話題の話題の構造情報は話題構造テーブル４０２に格納するように動作する。

補完部２５０２は、外部からのリクエストにより、話題構造テーブル４０２と、話題手順データベース１２０２を利用して、全話題を包括した話題遷移手順となるように話題手順データベース１２０２を補完する。この補完処理については後述する。

出力部２５０３は、補完部２５０２で作成された全話題を包括した話題遷移手順を出力する。出力の際には全話題を包括した話題遷移手順の形式で出力したり、外部での利用形式に応じて状態遷移モデルやルール等の形式に変換したりして出力する。例えば出力形式としてルールのような形式で提示する場合は、「親話題の属性の属性値を取得する時に導入する新規話題は、その属性でリンクされている子話題」、「話題解決後に導入する新規話題は、解決した話題の親話題」という内容のルールで出力することが可能であり、新規話題の候補が複数ある場合は「新規話題の候補を列挙して問い返す」というルールに変形して出力する。これらのルールは話題遷移手順に含まれる全リンクについて生成する。新規話題導入後に実行する対話手順は導入した話題に対応する話題シナリオを参照する。

次に補完部２５０２における詳細補完手順について説明する。補完部２５０２は、全話題を包括した話題遷移手順を作成する手順として、まず話題手順データベース１２０２にある話題遷移手順を話題構造テーブル４０２の形式に変形し、次に話題構造テーブル４０２に基づき手続きの補完作業を行う。

話題遷移手順から話題構造テーブル４０２の形式への変換について図２５を用いて説明する。この変換処理は、話題遷移手順で明記されている手続きを補完によって編集しないように話題遷移手順を一つの話題として取り扱える形式とすることを目的とする。話題構造テーブル４０２に登録するために出力定義情報と、属性定義情報が必要であるので、話題遷移手順からこれらの情報を取得する。まず出力定義情報については、話題遷移手順において親話題がない話題の出力定義情報を利用する（図２５（１））。親話題が無い話題が複数存在する話題遷移手順であれば、出力定義情報は複数持たせ、どの話題からの出力であるかを明らかにしておく。次に属性定義情報については、話題遷移手順において子話題がない話題の属性定義情報を利用する（図２５（２）（３））。子話題が無い話題が複数存在する場合は、それらの属性定義情報を全てマージし、どの話題からの出力であるかを明らかにしておく。図２５の書式では個々の属性定義情報の後に“（目的地設定）”と話題情報を付記してある。取得した出力定義情報、属性定義情報を一つの話題の構造情報として登録する（１４０２）。最後に話題遷移手順にある個々の話題を補完対象の話題から除外する（図２５（４））。

図２５の例では図１６の話題構造テーブル４０２と図１３の遷移手順データベース１２０２を用いて、「ルート設定」、「目的地設定」、「経由地設定」からなる話題遷移手順（１４０１）を一つの話題の構造情報に変換する手続きを示している。親話題のない「ルート設定」の出力定義情報を出力定義情報とし（図２５（１））、子話題の無い「目的地設定」、「経由地設定」の属性定義情報をマージして属性定義情報とする（図２５（２）、（３））。その結果話題の構造情報１４０２を構成する。そして、話題遷移手順に登録されていた話題である「ルート設定」、「目的地設定」、「経由地設定」を次ステップの補完作業から除外する。

続いて話題構造テーブル４０２による手順の補完について図２６を用いて説明する。この補完処理は、話題構造テーブル４０２における各話題の出力定義情報を属性定義情報に利用できる話題であれば、対話結果（出力定義情報の型の値）を利用した対話を継続することが可能であるので親話題とできるという方針に基づく。従って、話題構造テーブル４０２に存在する補完対象の各話題につき、その出力定義情報に対応する属性定義情報を持つ話題を収集し、収集された話題群を親話題としてリンクすることで補完を実行する。補完対象の全話題について補完処理を実行する。リンクの際は補完された手順であることを明らかにしておく。補完された手順はシナリオ設計者が意図した特定の手順とは異なるので、予測信頼度を下げるなどの問い返しを実行しやすいルールとして用いる。

図２６は図２５の変換処理が終了した後に、話題「ジャンル検索」を補完対象とした補完の例である。「ジャンル検索」の出力定義情報は場所であるので、場所を代入可能な属性定義情報を持つ話題を話題構造テーブル４０２から収集する。その結果、話題遷移手順から作成された話題１４０１の属性「目的地」、「経由地」を親話題の対象として取得する（図２６（１））。親話題の対象となった「目的地」属性に対して「ジャンル検索」を子話題としてリンクする。話題遷移手順から作成された話題の場合は、話題遷移手順内で該当する話題へのリンクを作成する。従って、話題遷移手順１４０１の中の「目的地設定」を親話題とし、「目的地」リンク２６０１を補完された手順として作成する（図２６（２））。属性「経由地」についても同様にして親話題へのリンク２６０２を補完された手順として作成する（図２６（３））。図２６の例では、話題「住所検索」も同様の補完が実行可能である。

補完部２５０２により、図１６の話題構造テーブル４０２と図１４の話題手順データベース１２０２に基づいて補完可能な全話題を補完した結果は図２７のようになる。出力部２５０３において、それぞれのリンクについてルールを生成する場合は例えば、『「住所検索」を解決した後の新規話題は「目的地設定」、「経由地設定」のいずれかであり、どちらにするか問い合わせる』、『「目的地設定」を解決した後の新規話題は「ルート設定」である』、『「目的地設定」の属性「目的地」を決定する際の新規話題は「住所検索」、「ジャンル検索」のいずれかであり、どちらにするか問い合わせる』、『「ルート設定」の属性「目的地」を決定する際の新規話題は「目的地設定」である』といったルールが生成可能である。

以上のように、本実施の形態における対話シナリオ生成装置によると、個別の話題の構造情報（話題構造テーブル４０２）と断片的な話題遷移手順（話題手順データベース１２０２）を用いて、話題間を遷移するルールを自動生成することが可能である。従ってシナリオ設計者は各話題を解決するための話題シナリオを設計するのみで、話題間遷移のための指定を検討することなく複数の話題を連携して取り扱う対話シナリオを作成することがかのうとなり、シナリオ設計者による対話シナリオ設計コストを削減することが可能である。

なお、上述の例において話題手順データベース１２０２に基づいた話題遷移手順を作成するように記述しているが、本実施の形態はこのような対話シナリオ生成方法に限定されるものではない。例えば、話題手順データベース１２０２が無くとも話題構造テーブル４０２に基づく補完処理だけで最終的な話題遷移手順を生成することが可能である。従って話題手順データベース１２０２は必須の構成ではない。

また、本実施の形態の構成にある話題構造テーブル４０２や話題手順データベース１２０２とは別に話題遷移手順を作成するように記述しているが、本実施の形態はこのような対話シナリオ生成方法に限定されるものではない。例えば、話題構造テーブル４０２や話題手順データベース１２０２を編集結果で上書きしても良い。これに伴い出力部２５０３からの出力として話題構造テーブル４０２や話題手順データベース１２０２を参照させることも可能である。この場合は再度話題構造テーブル４０２や話題手順データベース１２０２を編集した時には、補完された手順や、話題遷移手順から変換された話題の構造情報をクリアしてから再度補完処理を実行するなど、多重に補完された手順を作成しないようにする。

また、本実施の形態では話題間遷移のルールを生成する際に全話題を包括した話題遷移手順を作成していたが、出力後に話題遷移手順を必要としない場合は話題遷移手順の生成を行わずに話題構造テーブル４０２から直接ルールを生成しても良い。例えば、「話題の解決後に遷移する話題は、その話題の出力定義情報を属性定義情報に持つ話題」、「属性の属性値を取得するために遷移する話題は、その属性の属性定義情報を出力定義情報に持つ話題」というルールが生成可能であり、遷移可能性がある話題が複数ある場合は「遷移可能性がある話題を列挙して問い返す」というルールに変形して出力する。

また、本実施の形態では、補完部２５０２による補完処理の際に話題構造テーブル４０２における型情報の一致に基づいて判定を行っていたが、型の意味的な包含関係に基づいて判定しても良い。

また、本実施の形態における対話シナリオ生成装置を対話装置内に組み込んでも良い。このような場合は、話題構成の変更に対応して話題間遷移のためのルールを本対話シナリオ生成装置で自動生成することが可能となる。

以上のように、少なくとも話題構造テーブル４０２を利用し、必要に応じて話題手順データベース１２０２を付加的に用いて、対話シナリオにおける話題間遷移のための指定のルールを自動生成し、シナリオ設計者による対話シナリオ設計コストを削減する対話シナリオ生成装置であれば、そのような実施の形態は本発明の主旨の範囲内である。

以上に示した実施の形態によれば、話題間の遷移に関する対話シナリオを設計することなく、対話装置から適切に話題の遷移を示唆することが可能となる。

なお、本発明の対話装置はアプリケーションと分離した構成であるかのように記述しているが、アプリケーションの機能を含有する対話装置であっても本発明の適用が可能である。例えばユーザに提示する情報を管理するデータベースを保持し、ユーザの要求する条件に基づいてそのデータベースを検索する機能を含有する対話装置の場合について考える。このような対話装置において、ユーザとの対話によってデータベース検索条件を取得し、取得した検索条件に基づいてそのデータベースを検索し、ユーザに対して回答を返す動作をする場合は、そのようなデータベース検索機能は本発明におけるアプリケーションの機能であり、データベース検索条件を取得することが本発明における話題に相当する。

また、データベース検索の他に種々の機能を保有する対話装置であっても、ユーザと対話をして各種機能の動作条件を決定しそれに基づいて各種機能を動作させる場合は、その機能は全て本発明におけるアプリケーションの機能と同一とみなせる。例えばユーザとの対話によって指定された条件で各種機能を動作させる構成や、対話装置から動作条件を提示してユーザからの承諾を得ることで各種機能を動作させる構成であっても、動作させる各種機能は本発明におけるアプリケーションの機能であると言える。

また、本発明の対象とするアプリケーションが単一であるかのように記述しているが、複数のアプリケーションの機能を利用することも可能である。本発明では複数のアプリケーションに含まれる個々の機能を実行させることを個別の目的として、それぞれを個別の話題として取り扱うことが可能である。

また、各実施の形態の説明においてはアプリケーションの機能を実行させることを話題解決時の一回だけ行うかのように記述しているが、本発明における話題は「アプリケーションにある機能を有効に動作させる」ことを目的とするものであり、その実行結果が有意なものでなければ（検索結果の件数が0件や多すぎる場合、コマンドの実行失敗など）話題を解決していないとみなし、再度その機能の実行条件の変更を行いアプリケーションの機能を複数回実行しても良い。実行条件はユーザから対話的に変更することも、対話装置から自動的に変更することも可能である。或いはある話題の対話中の途中経過において、ユーザとの対話進行のための手順として必要な機能を実行しても良い。また、各実施の形態の説明においてはカーナビを例にして説明しているが、本発明は家電の操作などカーナビ以外のアプリケーションにも適用することも可能である。

その他、本発明は、上記実施の形態に限定されるものでなく、実施段階では、その要旨を変更しない範囲で種々変形することが可能である。

さらに、上記実施の形態には、種々の段階の発明が含まれており、開示されている複数の構成要件における適宜な組み合わせにより種々の発明が抽出できる。例えば、実施の形態に示されている全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題を解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出できる。

本発明の第１の実施の形態に係わる対話装置の構成を示すブロック図。 第１の実施の形態の動作を説明するフローチャート。 第１の実施の形態における話題情報の説明図 第１の実施の形態に用いられる次話題情報予測部の詳細を示す構成図。 第１の実施の形態に用いられる話題構造テーブルを説明する図。 第１の実施の形態における現在の話題を解決した際の次話題情報予測処理の動作説明図。 第１の実施の形態における対話例を示す図。 第１の実施の形態における対話例を示す図。 第１の実施の形態における対話例を示す図。 第１の実施の形態に用いられる話題構造テーブルの編集例を示す図。 第１の実施の形態に用いられる話題構造テーブルの編集例を示す図。 第１の実施の形態の変形例の概略構成を示す図。 本発明の第２の実施の形態に用いられる次話題情報予測部の詳細を示す構成図。 第２の実施の形態に用いられる話題手順データベースを説明する図。 第２の実施の形態に用いられる場所検索の話題を追加した後の話題手順データベースを説明する図。 第２の実施の形態に用いられる話題構造テーブルを示す図。 本発明の第３の実施の形態に用いられる話題構造テーブルを示す図。 本発明の第４の実施の形態に用いられる遷移話題情報選択部の詳細を示す構成図。 第４の実施の形態に用いられる絞り込みルール記憶部を説明する図。 第４の実施の形態における対話例を示す図。 本発明の第５の実施の形態に係わる対話装置の構成を示すブロック図。 第５の実施の形態に用いられる頻度情報データベースを説明する図。 第５の実施の形態の新規話題導入を行った対話状態のリストの例を示す図。 本発明の第６の実施の形態に用いられる対話シナリオ生成装置の概略構成を示す図。 第６の実施の形態における話題遷移手順から話題の構造情報への変換手順の説明図 第６の実施の形態に用いられる話題構造テーブルに基づく補完の説明図。 第６の実施の形態における補完によって構成された話題遷移手順の例を示す図。

符号の説明

１０１、２１０１・・・対話進行部
１０２、２１０２・・・遷移話題情報選択部
１０３、２１０３・・・次話題情報予測部
１０４・・・対話シナリオ管理部
４０１、１２０１・・・予測処理部
４０２・・・話題構造テーブル
１２０２・・・話題手順データベース
５０１、５０２、５０３、１００４、１６０１、１６０２、１６０３、１６０４、１６０５、１７０１、１７０２、１７０３、１７０４、１７０５・・・話題の構造情報
１８０１・・・選択部
１８０２・・・絞り込みルール記憶部
１９０１、１９０２、１９０３・・・絞り込みルール
２１０４・・・頻度情報データベース
２２０１、２２０２・・・頻度情報群
２２０３、２２０４、２２０５・・・頻度情報
２５０１・・・編集部
２５０２・・・補完部
２５０３・・・出力部

Claims (17)

1. 各話題を解決するための話題シナリオを話題と対応付けて管理する対話シナリオ管理手段と、
   前記対話シナリオ管理手段で管理される前記話題シナリオを参照してユーザとの対話を進行させるとともに、前記ユーザとの現在の話題情報を管理し、且つ前記対話の進行段階での新規話題情報の導入の必要性を判断する対話進行手段と、
   前記対話進行手段による新規話題情報の必要性の判断により現在の話題情報に基づいて遷移可能性を有する一つ以上の次話題情報を遷移話題情報として予測する次話題情報予測手段と、
   前記次話題情報予測手段により予測された前記遷移話題情報を選択し前記対話進行手段で管理される話題情報に反映させ、該反映された話題情報に基づき話題を継続させる遷移話題情報選択手段と
   を具備したことを特徴とする対話装置。
2. 前記対話進行手段は、現在の話題を解決した後に対話する話題を選択する状況、又は現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する状況に応じて前記新規話題情報の導入の必要性を判断することを特徴とする請求項１記載の対話装置。
3. 前記前記次話題情報予測手段は、各話題の対話によって得られる情報の種類である出力定義情報と、各話題の対話を終了させるために必要な情報である属性定義情報からなる話題の構造情報を話題毎に管理する話題構造テーブルと、現在の対話進行状況と前記話題構造テーブルに基づいて次に遷移しうる話題を予測し、該予測結果に対応する話題情報を作成する予測処理手段を有することを特徴とする請求項１記載の対話装置。
4. 前記対話進行手段は、前記話題構造テーブルに基づいて、前記対話の遷移の実行を決定することを特徴とする請求項３に記載の対話装置。
5. 前記対話シナリオ管理手段又は前記話題構造テーブルは、前記対話シナリオ又は前記話題の構造情報を追加又は削除可能にしたことを特徴とする請求項１又は３記載の対話装置。
6. 前記対話進行手段は、現在の話題を解決した後に対話する話題を選択する状況により新規話題情報の導入の必要性を判断し、
   前記次話題情報予測手段は、前記対話進行手段の判断結果に基づいて遷移可能性のある話題情報を遷移話題情報として予測し、
   前記遷移話題情報選択手段は、前記次話題情報予測手段より出力される予測結果から次に対話を実行する遷移話題情報を選択し該遷移話題情報を現在の話題情報に反映させることを特徴とする請求項２記載の対話装置。
7. 前記前記対話進行手段は、現在の話題を解決するために必要な情報を取得するための手順として別の話題を利用する状況により新規話題情報の導入の必要性を判断し、
   前記次話題情報予測手段は、前記対話進行手段の判断結果に基づいて遷移可能性のある話題情報を遷移話題情報として予測し、
   前記遷移話題情報選択手段は、前記次話題情報予測手段から取得される遷移話題情報を前記対話進行手段の管理する話題情報に反映させることを特徴とする請求項２記載の対話装置。
8. 前記次話題情報予測手段は、
   話題遷移手順を予め格納する話題遷移手順手段と、前記話題遷移手順手段に格納された話題遷移手順を参照して現在の話題を解決した時の遷移可能性のある話題情報の予測又は現在の話題を解決する手順として別の話題情報を利用する時の遷移可能性のある話題情報の予測をそれぞれ行なう予測処理手段をさらに有することを特徴とする請求項１記載の対話装置。
9. 前記次話題情報予測手段は、予測結果として出力される遷移可能性のある話題情報に予測の信頼性を表す予測信頼度を付与し、
   遷移話題情報選択手段は、前記話題情報に付与された予測信頼度に基づき遷移話題情報として選択するか否かを決定することを特徴とする請求項１記載の対話装置。
10. 前記遷移話題情報選択手段は、前記次話題情報予測手段により遷移可能性のある話題情報が複数予測された場合、ユーザに対し遷移すべき話題を問い合わせするとともに、該問い合わせする話題情報の個数を予め設定したしきい値以内にすることを特徴とする請求項１記載の対話装置。
11. 前記遷移話題情報選択手段は、前記次話題情報予測手段により遷移可能性のある話題情報が複数予測された場合、ユーザに対し遷移すべき話題を問い合わせするとともに、該問い合わせする話題情報の絞り込み基準は予測信頼度が高いものから順に採用することを特徴とする請求項１記載の対話装置。
12. 前記前記遷移話題情報選択手段は、遷移話題情報として選択された頻度を話題別に記憶した頻度情報データベースを有し、
    前記頻度情報データベースの頻度情報に基づいて前記予測信頼度を決定することを特徴とする請求項１１記載の対話装置、
13. 前記遷移話題情報選択手段は、絞り込みルールと該絞り込みルールの優先度合いをパラメータで示す強度を対応させて記憶した絞り込みルール記憶手段を有し、
    前記次話題情報予測手段により遷移可能性のある話題情報が複数予測された場合、ユーザに対し遷移すべき話題を問い合わせするとともに、前記絞り込みルール記憶手段の絞り込みルールに基づいて前記問い合わせする話題情報の絞り込みを行なうことを特徴とする請求項１記載の対話装置。
14. 各話題を解決するための話題シナリオを話題と対応付けて管理する対話シナリオ管理手段の前記話題シナリオを参照してユーザとの対話を進行させるとともに、前記ユーザとの現在の話題情報を管理し、且つ前記対話の進行段階での新規話題情報の導入の必要性を判断する第１のステップと、
    前記第１のステップによる新規話題情報の必要性の判断により現在の話題情報に基づいて遷移可能性を有する一つ以上の次話題情報を遷移話題情報として予測する第２のステップと、
    前記第２のステップにより予測された前記遷移話題情報を前記第１のステップで管理される話題情報に反映させ、該反映された話題情報に基づき話題を継続させる第３のステップと
    を具備したことを特徴とする対話方法。
15. 各話題を解決するための話題シナリオを話題と対応付けて管理する対話シナリオ管理部と、
    前記対話シナリオ管理部で管理される前記話題シナリオを参照してユーザとの対話を進行させるとともに、前記ユーザとの現在の話題情報を管理し、且つ前記対話の進行段階での新規話題情報の導入の必要性を判断する対話進行部と、
    前記対話進行部による新規話題情報の必要性の判断により現在の話題情報に基づいて遷移可能性を有する一つ以上の次話題情報を遷移話題情報として予測する次話題情報予測部と、
    前記次話題情報予測部により予測された前記遷移話題情報を前記対話進行部で管理される話題情報に反映させ、該反映された話題情報に基づき話題を継続させる遷移話題情報選択部と
    前記対話シナリオ管理部、対話進行部、次話題情報予測部及び遷移話題情報選択部の少なくとも２つの間を接続し、情報の送受信を行なう通信媒体と
    を具備したことを特徴とする対話システム。
16. 複数の話題についてユーザと対話を行う対話装置を制御するコンピュータプログラムであって、
    各話題を解決するための話題シナリオを話題と対応付けて管理する対話シナリオ管理手段の前記話題シナリオを参照してユーザとの対話を進行させるとともに、前記ユーザとの現在の話題情報を管理し、且つ前記対話の進行段階での新規話題情報の導入の必要性を判断する第１のステップと、
    前記第１のステップによる新規話題情報の必要性の判断により現在の話題情報に基づいて遷移可能性を有する一つ以上の次話題情報を遷移話題情報として予測する第２のステップと、
    前記第２のステップにより予測された前記遷移話題情報を前記第１のステップで管理される話題情報に反映させ、該反映された話題情報に基づき話題を継続させる第３のステップと
    を有することを特徴とするコンピュータプログラム。
17. 各話題の対話によって得られる情報の種類である出力定義情報と各話題の対話を終了させるために必要な情報である属性定義情報からなる話題の構造情報を話題毎に管理する話題構造テーブルと、
    前記話題構造テーブルの編集を行なう編集手段と、
    前記話題構造テーブルに管理される全ての話題を包括した話題遷移手順を作成する話題遷移手順作成手段と
    を具備したことを特徴とする対話シナリオ生成装置。

Images