JPWO2019026617A1 - 情報処理装置、及び情報処理方法 - Google Patents

Abstract

本技術は、音声対話システムにおいて、ユーザに対し適切な情報量で応答を提示することができるようにする情報処理装置、及び情報処理方法に関する。ユーザの所望の情報に対して推定されるユーザ自身の確信度に応じて、当該所望の情報に対する応答の情報量を調整する処理部を備える情報処理装置が提供されることで、音声対話システムにおいて、ユーザに対し適切な情報量で応答を提示することができるようになる。本技術は、例えば、音声対話システムに適用することができる。

Description

本技術は、情報処理装置、及び情報処理方法に関し、特に、音声対話システムにおいて、ユーザに対し適切な情報量で応答を提示することができるようにした情報処理装置、及び情報処理方法に関する。

ユーザが音声対話システムを通じて、情報の取得や確認を行う場合、音声対話システムでは、ユーザの発話意図に応じたアプリケーションAPI(Application Programming Interface)を選択して実行し、それにより得られた結果を、応答文章としてユーザに提示することが多い。

例えば、音声対話システムとしては、システム側の確信度に応じて応答を切り替えるものが開示されている（例えば、特許文献１参照）。

特開２０１１−５４０８８号公報

ところで、一般的な音声対話システムにおいては、同一のAPIコールに対して、同一のルールでの応答生成が行われることが多いため、ユーザが欲しい情報に対して、どの程度確信しているかに関わらず、常に同じ情報量を含んだ応答が返ってくることになる。

そのため、ユーザは、自分が知っている情報が正しいかどうかを確認したいだけの場合でも、音声対話システムが、知っている情報をすべて含めて応答するなど、ユーザが求める情報量と、音声対話システムが出力する情報量と間に齟齬が生じてしまい、コミュニケーションのスムーズさを欠いてしまう恐れがある。

本技術はこのような状況に鑑みてなされたものであり、音声対話システムにおいて、ユーザに対し適切な情報量で応答を提示することができるようにするものである。

本技術の一側面の情報処理装置は、ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整する処理部を備える情報処理装置である。

本技術の一側面の情報処理置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。

本技術の一側面の情報処理方法は、情報処理装置の情報処理方法において、前記情報処理装置が、ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整するステップを含む情報処理方法である。

本技術の一側面の情報処理装置、及び情報処理方法においては、ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量が調整される。

本技術の一側面によれば、音声対話システムにおいて、ユーザに対し適切な情報量で応答を提示することができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

一般的な音声対話システムの構成を示すブロック図である。 本技術を適用した音声対話システムの一実施の形態の構成例を示すブロック図である。 音声対話システムの構成例を示すブロック図である。 音声処理装置の構成例を示すブロック図である。 サーバの構成例を示すブロック図である。 スケジュールDBの例を示す図である。 ユーザの確信度とシステム応答の情報量との関係の例を示す図である。 本技術を適用した音声対話システムの他の構成例を示すブロック図である。 スケジュールDBの例を示す図である。 ユーザの確信度とシステム応答の情報量との関係の例を示す図である。 本技術を適用した音声対話システムの他の構成例を示すブロック図である。 一般的なテキストチャットシステムの構成を示すブロック図である。 本技術を適用した音声対話システムの構成の第１の変形例を示すブロック図である。 本技術を適用した音声対話システムの構成の第２の変形例を示すブロック図である。 本技術を適用した音声対話システムの構成の第３の変形例を示すブロック図である。 ユーザの確信度とシステム応答の情報量との関係の第１の変形例を示す図である。 ユーザの確信度とシステム応答の情報量との関係の第２の変形例を示す図である。 ユーザの確信度とシステム応答の情報量との関係の第３の変形例を示す図である。 ユーザの確信度とシステム応答の情報量との関係の第４の変形例を示す図である。 音声対話処理を説明するフローチャートである。 コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

１．システム構成
２．本技術の実施の形態
（１）第１の実施の形態：基本形
（１−１）ユーザの確信度が高い場合
（１−２）ユーザの確信度が中程度の場合
（１−３）ユーザの確信度が低い場合
（１−４）ユーザの確信度は高いように見えるが、事実として間違っている場合
（１−５）事実として間違っている場合に、複数の選択肢があるとき
（２）第２の実施の形態：予定の対象者と話者が異なる場合
（２−１）他人の予定についてのユーザ自身の確信度が高い場合
（２−２）他人の予定についてのユーザ自身の確信度が中程度の場合
（２−３）他人の予定についてのユーザ自身の確信度が低い場合
（３）第３の実施の形態：センサ情報を利用する場合
３．変形例
４．音声対話処理の流れ
５．コンピュータの構成

＜１．システム構成＞

（一般的な音声対話システムの構成）
図１は、一般的な音声対話システムの構成を示すブロック図である。

図１において、一般的な音声対話システム１は、音声認識部１０１、ユーザ意図分析部１０２、対話制御部１０３、APIコール部１０４、及び出力生成部１０５を含んで構成される。

音声認識部１０１は、そこに入力されるユーザ発話データを、発話テキストデータに変換し、ユーザ意図分析部１０２に供給する。

ユーザ意図分析部１０２は、音声認識部１０１から供給されるテキストデータを処理して、ユーザの意図を分析し、その分析の結果得られるユーザの意図の候補を示すデータ（以下、ユーザ意図候補データという）を、対話制御部１０３に供給する。

対話制御部１０３は、ユーザ意図分析部１０２から供給されるユーザ意図候補データなどに基づき、現在の対話状態を推定し、コールすべきAPI及びその引数を決定する。対話制御部１０３は、コールすべきAPI及びその引数を示すデータ（以下、API及び引数データという）を、APIコール部１０４に供給する。

APIコール部１０４は、対話制御部１０３から供給されるAPI及び引数データに基づき、コールすべきAPIにその引数を渡して実行する。APIコール部１０４は、当該APIを実行することで得られる結果を、API出力として、出力生成部１０５に供給する。

出力生成部１０５は、APIコール部１０４から供給されるAPI出力に基づき、ユーザに対する応答文章（以下、システム応答という）を生成し、その音声データに応じた応答音声を出力する。

一般的な音声対話システム１は、以上のように構成される。

ここで、一般的な音声対話システム１（図１）においては、ユーザが確認したい予定に対し、その内容をどの程度確信しているのか（確信度）に関わらず、同一のAPIコールを行い、その結果を用いた応答生成も同一の手法で行われるため、結果として常に同じ情報量を含んだ応答が得られる。

そのため、シンプルな確認をしたい場合と、予定の詳細を確認したい場合とのどちらの場合においても、同じ応答が得られてしまうことになる。

よって、シンプルな確認をしたい場合でも、情報量の多い応答が得られるため、対話のテンポが落ち、コミュニケーションのスムーズさを欠いてしまう恐れがある。同様に、ユーザが多くの情報を得たい場合でも、音声対話システムの実装によっては、詳細な情報を返さないときもあり、より多くの情報を求めるための追加の対話が必要になって、コミュニケーションのスムーズさを欠いてしまう恐れがある。

そこで、本技術を適用した音声対話システムでは、ユーザが欲しい情報（所望の情報）に対してのユーザ自身の確信度を推定し、その結果に応じて応答生成に含める情報量を制御することにより、ユーザに対し適切な情報量で応答を提示するようにして、よりスムーズなコミュニケーションを実現することができるようにする。以下、本技術を適用した音声対話システムの構成について説明する。

（本技術の音声対話システムの構成）
図２は、本技術を適用した音声対話システムの一実施の形態の構成例を示すブロック図である。

図２において、音声対話システム２は、音声認識部２０１、ユーザ意図及び確信度分析部２０２、対話制御部２０３、APIコール部２０４、及び出力生成部２０５を含んで構成される。

音声認識部２０１は、音声テキスト変換用のデータベースを参照することで、そこに入力されるユーザ発話データを、発話テキストデータに変換する。音声認識部２０１は、ユーザ発話に応じた発話テキストデータを、ユーザ意図及び確信度分析部２０２に供給する。

ここで、ユーザ発話データは、ユーザにより発せられた音声を収音する音声処理装置（例えば、後述する図３の音声処理装置１０）から送られてくる。また、音声テキスト変換用のデータベースには、膨大な音声認識用データベースが蓄積されており、音声認識部２０１は、所定の認識アルゴリズムを用いることで、そこに入力されるユーザ発話データ（音声データ）を、発話テキストデータ（テキストデータ）に変換することができる。

ユーザ意図及び確信度分析部２０２は、音声認識部２０１から供給される発話テキストデータに対する解析処理を行う。ユーザ意図及び確信度分析部２０２は、ユーザ意図分析部２１１及びユーザ確信度推定部２１２を含んでいる。

ユーザ意図分析部２１１は、音声認識部２０１から供給される発話テキストデータに対し、解析処理を施すことで、ユーザの意図を分析する。ユーザ意図分析部２１１は、分析の結果得られるユーザ意図候補データを、対話制御部２０３に供給する。

ユーザ確信度推定部２１２は、音声認識部２０１から供給される発話テキストデータに対し、解析処理を施すことで、ユーザの確信度を推定する。ユーザ確信度推定部２１２は、推定の結果得られるユーザの確信度を示すデータ（以下、ユーザ確信度データという）を、対話制御部２０３に供給する。

対話制御部２０３は、ユーザ意図及び確信度分析部２０２から供給されるユーザ意図候補データ、及び対話履歴のデータベースなどに基づき、現在の対話状態を推定し、コールすべきAPI及びその引数を決定する。なお、対話履歴のデータベースには、過去の対話履歴の情報などが蓄積されている。

対話制御部２０３は、決定されたAPI及び引数データを、APIコール部２０４に供給する。また、対話制御部２０３は、ユーザ確信度データを、出力生成部２０５に供給する。

APIコール部２０４は、対話制御部２０３から供給されるAPI及び引数データに基づき、コールすべきAPIにその引数を渡して実行する。APIコール部２０４は、当該APIを実行することで得られる結果を、API出力として、出力生成部２０５に供給する。

ここで、コールすべきAPIは、ユーザの意図に応じたAPIであって、例えば、ユーザの意図がスケジュールのチェックに関するものである場合には、スケジュールチェックを行うAPI（以下、スケジュールAPIともいう）が呼び出されて実行される。

出力生成部２０５には、対話制御部２０３からのユーザ確信度データと、APIコール部２０４からのAPI出力のデータが入力される。

出力生成部２０５は、ユーザ確信度データ及びAPI出力のデータに基づき、ユーザに対する応答文章（システム応答）を生成し、その音声データに応じた応答音声を出力する。ただし、ここでは、システム応答を生成するに際して、ユーザの確信度に応じて、応答文章に含める情報量が制御（調整）される。

例えば、ユーザの確信度を示す値が、所定の閾値を超える場合に、ユーザの確信度が高いと判断し、より簡潔なシステム応答を生成する。これにより、ユーザが欲しい情報だけを提示することができる。一方で、例えば、ユーザの確信度を示す値が、所定の閾値以下となる場合に、ユーザの確信度が低いと判断し、より詳細な情報を含むシステム応答を生成する。これにより、ユーザに対し、１回の対話で欲しい情報を適切に提示することができる。

音声対話システム２は、以上のように構成される。

ところで、音声対話システム２により提供される音声対話サービスは、例えば、音声認識処理や自然言語処理などの処理を組み合わせて、話し言葉による問いかけや要求に対し、適切に回答したり、動作したりするサービスが含まれる。

このような音声対話サービスを実現するために、音声対話システム２は、例えば、図３に示すような構成とすることができる。すなわち、音声対話システム２は、クライアント側に設置され、音声対話サービスのユーザインターフェースとして機能する音声処理装置１０と、データセンタ等のサーバ側に設置され、音声対話機能を実現するための処理を行うサーバ２０とから構成されるようにすることができる。

音声対話システム２において、音声処理装置１０とサーバ２０とは、インターネット３０を介して相互に接続されている。

音声処理装置１０は、例えば、家庭内LAN(Local Area Network)等のネットワークに接続可能なスピーカであって、いわゆるスマートスピーカなどとも称される。この種のスピーカは、音楽の再生のほか、例えば、照明器具や空調設備などの機器に対する音声操作などを行うことができる。

なお、音声処理装置１０は、スピーカに限らず、例えば、スマートフォンや携帯電話機等のモバイル機器や、タブレット型のコンピュータなどとして構成されるようにしてもよい。

音声処理装置１０は、インターネット３０を介してサーバ２０と連携することで、ユーザに対し、音声対話サービス（のユーザインターフェース）を提供することができる。

すなわち、音声処理装置１０は、ユーザから発せられた音声（ユーザ発話）を収音し、その音声データを、インターネット３０を介して、サーバ２０に送信する。また、音声処理装置１０は、インターネットを介してサーバ２０から送信されてくる処理データを受信し、その処理データに応じた音声を出力する。

サーバ２０は、クラウドベースの音声対話サービスを提供するサーバである。サーバ２０は、インターネット３０を介して音声処理装置１０から送信されてくる音声データを、テキストデータに変換するための音声認識処理を行う。また、サーバ２０は、テキストデータに対し、ユーザの意図に応じた対話処理などの処理を行い、その処理の結果得られる処理データを、インターネット３０を介して音声処理装置１０に送信する。

（音声処理装置の構成）
図４は、図３の音声処理装置１０の構成例を示すブロック図である。

図４において、音声処理装置１０は、処理部５１、マイクロフォン５２、スピーカ５３、センサ５４、及び通信I/F５５を含んで構成される。

処理部５１は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部５１は、各種の演算処理や、各部の動作制御など、音声処理装置１０における中心的な処理装置として動作する。

マイクロフォン５２は、外部からの音を、電気信号に変換する機器（収音器）である。マイクロフォン５２は、変換で得られる音声信号を、処理部５１に供給する。

スピーカ５３は、電気信号を物理振動に変えて音を出す機器である。スピーカ５３は、処理部５１から供給される音声信号に応じた音を出力する。

センサ５４は、各種のセンサから構成される。センサ５４は、センシングを行い、センシング結果に応じたセンサ情報（センサデータ）を、処理部５１に供給する。

例えば、センサ５４としては、被写体を撮像するイメージセンサ、磁場（磁界）の大きさや方向を検出する磁気センサ、加速度を検出する加速度センサ、角度（姿勢）や角速度、角加速度を検出するジャイロセンサ、近接するものを検出する近接センサ、あるいは、指紋や虹彩、脈拍などの生体情報を検出する生体センサなど、各種のセンサを含めることができる。

また、センサ５４には、温度を検出する温度センサや、湿度を検出する湿度センサ、周囲の明るさを検出する環境光センサなどの周囲の環境を測定するためのセンサを含めることができる。なお、センサデータには、GPS(Global Positioning System)信号などから算出される位置情報（位置データ）や、計時手段により計時された時刻情報などの情報を含めるようにしてもよい。

通信I/F５５は、例えば、通信インターフェース回路等から構成される。通信I/F５５は、処理部５１からの制御に従い、インターネット３０に接続されたサーバ２０にアクセスして、各種のデータをやりとりする。

ここで、例えば、処理部５１は、音声対話システム２（図２）を構成する音声認識部２０１乃至出力生成部２０５により提供される機能のうち、音声認識部２０１に対し、ユーザ発話データを入力するための機能と、システム応答（の音声データ）に応じた応答音声を出力するための機能を有している。

すなわち、処理部５１は、マイクロフォン５２から供給される音声信号を処理し、その結果得られる音声データを、通信I/F５５に供給する。これにより、ユーザ発話データ（音声データ）が、インターネット３０を介してサーバ２０に送信され、音声認識部２０１に入力される。また、処理部５１は、センサデータを、通信I/F５５に供給して、インターネット３０を介してサーバ２０に送信することができる。

また、処理部５１は、通信I/F５５から供給される音声データを処理し、その結果得られる音声信号を、スピーカ５３に供給する。これにより、スピーカ５３からは、システム応答（の音声データ）に応じた応答音声が出力される。

なお、図４には図示していないが、音声処理装置１０には、各種の情報（例えば文字や画像等）を表示するための表示部、ユーザからの操作を受け付ける入力部、又は各種のデータ（例えば音声データやテキストデータ等）を記憶する記憶部などをさらに設けるようにしてもよい。

ここで、表示部は、例えば、液晶ディスプレイや有機ELディスプレイ等から構成される。入力部は、例えば、ボタンやキーボード等から構成される。また、入力部は、タッチセンサと表示部とが一体化されたタッチパネルとして構成され、ユーザの指やタッチペン（スタイラスペン）による操作に応じた操作信号が得られるようにしてもよい。記憶部は、例えば、不揮発性メモリの一種であるフラッシュメモリ（Flash Memory）や、揮発性メモリの一種であるDRAM(Dynamic Random Access Memory)などから構成される。

（サーバの構成）
図５は、図３のサーバ２０の構成例を示すブロック図である。

図５において、サーバ２０は、処理部７１、通信I/F７２、及びデータベース７３を含んで構成される。

処理部７１は、例えば、CPUやマイクロプロセッサ等から構成される。処理部７１は、各種の演算処理や、各部の動作制御など、サーバ２０における中心的な処理装置として動作する。

通信I/F７２は、例えば、通信インターフェース回路等から構成される。通信I/F７２は、処理部７１からの制御に従い、インターネット３０を介して接続される音声処理装置１０との間で、各種のデータをやりとりする。

データベース７３は、例えば、ハードディスク(HDD：Hard Disk Drive)や半導体メモリ、光ディスク等の大容量の記録装置として構成される。

例えば、データベース７３には、音声認識処理を行うための音声認識用データベースや、対話処理を行うための対話履歴データベースなどが含まれる。なお、音声認識用データベースや対話履歴データベースは、データベースの一例であって、音声対話サービスを実現するために必要となるデータベース（例えば、知識データベースや発話データベース等）を含めることができる。

ここで、例えば、処理部７１は、音声対話システム２（図２）を構成する音声認識部２０１乃至出力生成部２０５により提供される機能のうち、音声認識部２０１、ユーザ意図及び確信度分析部２０２、対話制御部２０３、APIコール部２０４、及び出力生成部２０５の一部の機能を有している。

すなわち、処理部７１は、データベース７３に含まれる音声認識用データベースを参照して、インターネット３０を介して音声処理装置１０から送信されてくるユーザ発話データ（音声データ）を、発話テキスト（テキストデータ）に変換するための音声認識処理を行う。

また、処理部７１は、音声認識処理で得られる発話テキストを用い、ユーザの意図に応じた対話処理を行う際に、ユーザが欲しい情報に対してのユーザ自身の確信度を推定し、その結果に応じて応答生成に含める情報量を制御（調整）する処理を行う。これにより、ユーザに対する応答文章として、適切な情報量からなるシステム応答が生成され、処理データとして、インターネット３０を介して、音声処理装置１０に送信される。

なお、説明の都合上、図３の音声対話システム２においては、１台の音声処理装置１０が設けられる場合を図示しているが、例えば、ユーザごとに、複数の音声処理装置１０を設けることができる。

また、図３の音声対話システム２では、１台のサーバ２０が設けられる場合を図示しているが、例えば、機能（モジュール）ごとに、複数のサーバ２０を設けることができる。より具体的には、例えば、音声認識部２０１に対応した音声認識モジュールを有するサーバ２０や、対話制御部２０３に対応した対話制御モジュールを有するサーバ２０などを、個別のサーバ２０として設けることができる。

＜２．本技術の実施の形態＞

（１）第１の実施の形態

次に、音声対話システム２により提供される音声対話サービスの具体例について説明する。ここでは、スケジュールチェックを実行するための音声対話を一例として述べる。その前提として、図６に示した予定が、ユーザによって既に登録されているものとする。

図６においては、タイトル、日時、場所、及び対象者により特定される予定として、２つの予定が登録されている。すなわち、１つ目のレコードには、父親（パパ）の予定として、2017年3月23日 10時に、大会議室での会議が登録されている。また、２つ目のレコードには、パパの予定として、2017年3月23日 17時に、渋谷での買い物の予定が登録されている。

なお、これらの予定の情報は、スケジュールデータベース（以下、スケジュールDBと記述する）に格納された情報として、サーバ２０のデータベース７３（図５）に登録されているものとする。

ここで、音声対話システム２に対し、ユーザが発話をしているのは、2017年3月22日であるものとする。したがって、図６に示した予定は、ユーザ及び音声対話システム２にとって、明日の予定として登録されている。

また、音声対話システム２において、スケジュールチェックを実行するためのAPI(Application Programming Interface)は、例えば、次に示す４つの引数を持つものとする。

スケジュールAPI(pram1, pram2, pram3, pram4)
第１引数：タイトル
第２引数：日時
第３引数：場所
第４引数：対象者

以下の具体例では、このようなスケジュールDBとスケジュールAPIを有する音声対話システム２に対し、ユーザは、既に登録されている予定の確認を行う意図で、対話を行うものとする。ただし、以下の具体例では、比較のために、一般的な音声対話システム１（図１）についても適宜説明するものとする。

（１−１）ユーザの確信度が高い場合

ここでは、ユーザは、自分自身の予定として明日の10時に会議があることを知っているが、それが正しいかどうかだけを確認したい場合を想定する。この場合において、ユーザは、例えば、「明日の10時は会議の予定だよね。」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は、「スケジュールチェック」であり、その引数は、「タイトル = "会議"」、及び「日時 = "2017年3月23日 10時"」であると推定し、スケジュールチェックを行うスケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "会議"」、「日時 = "2017年3月23日 10時"」、及び「場所 = "大会議室"」を含むレコードが１件存在することが得られる。

そして、システム応答としては、例えば、「明日の10時から会議の予定が１件あります。場所は大会議室です。」が得られる。

しかしながら、このとき、ユーザ自身は、明日の10時に会議の予定があることは知っており、それが正しいかどうかの確認をしたかっただけであるが、ここで得られたシステム応答は、ユーザが既に知っている情報をオウム返ししたものになっており、ユーザにとっては不要な情報が多くを占めている。

そのため、本来、簡潔な応答さえあれば済むコミュニケーションが、情報量の多い応答を聞くことになってしまい、対話のテンポ、すなわち、コミュニケーションのスムーズさが失われてしまっている。

それに対し、本技術を適用した音声対話システム２（図２）では、ユーザの発話から得られる情報に基づき、ユーザ自身が欲しい情報（所望の情報）に対してどの程度確信しているか（確信度）を推定し、その結果に応じて応答の情報量を制御（調整）するようにする。

上述した例では、「明日の10時は会議の予定だよね。」の発話において、「タイトル = "会議"」及び「日時 = "2017年3月23日 10時"」が明確に示されていること、またそれらの情報に対して「多分」や「確か」などのような曖昧さを示す言葉も含まれていないことから、その予定のタイトル及び日時に対する確信度は高いものと推定することができる。

よって、既にユーザが知っている情報（確信度の高い情報）を省いて、例えば「はい、そうです。」のような簡潔なシステム応答にすることで、ユーザが欲しい情報だけを提供することができるため、テンポの良い対話を続けることが可能となる。

なお、上述した例では、発話中に場所を示す内容が含まれていないが、タイトル及び日時についての確信度が高いことや、自分自身の予定であり、場所については既に把握しているものと推定することができることなどから、システム応答中に、場所の情報を含めなくても構わない。

このようなユーザの確信度が高い場合に、図２の音声対話システム２で実行される処理の内容は、例えば、次のようになる。

すなわち、「明日の10時は会議の予定だよね。」であるユーザ発話データが、音声処理装置１０（図３）により収音され、音声認識部２０１に入力される。音声認識部２０１では、音声認識処理が行われ、ユーザ発話データが、発話テキストデータに変換される。

このようにして得られる発話テキストデータに対し、ユーザ意図分析部２１１により解析処理が行われることで、ユーザの意図の候補が得られる。また、発話テキストデータに対し、ユーザ確信度推定部２１２により解析処理が行われることで、ユーザの確信度が得られる。ここでは、予定のタイトルや日時が正確に示されていること、またそれらの情報に対して曖昧さを示す言葉も含まれていないことから、予定のタイトルや日時に対する確信度は高いものと推定される。

対話制御部２０３では、ユーザ意図候補データや対話履歴データベースなどに基づき、現在の対話の状態が推定され、コールすべきAPI及びその引数が決定される。ここでは、ユーザ発話データに応じて、スケジュールチェックを行うスケジュールAPIと、その引数として、「タイトル = "会議"」、及び「日時 = "2017年3月23日 10時"」が決定されるので、APIコール部２０４では、コールすべきスケジュールAPIにその引数（タイトル、日時）を渡して実行する。

出力生成部２０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当するレコードが１件存在することが得られるが、ユーザの確信度として、予定のタイトルや日時に対する確信度が高いと推定されているため、より簡潔なシステム応答が生成される。

ここで、ユーザの確信度とシステム応答の情報量との間には、例えば、図７に示すような関係を有している。図７においては、横軸をユーザの確信度とし、縦軸をシステム応答の情報量（応答情報量）としたときのユーザの確信度と応答情報量との関係を、関数f1により表している。

図７において、関数f1は、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、負の比例の関係を有している。ここでは、例えば、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となるように、閾値（Th1，Th2）が設定されているものとする。

このとき、例えば、85である確信度のスコアが算出されたとき、予定のタイトルや日時の確信度が高いと推定され、簡潔なシステム応答として、確信度の高い情報が省かれた、「はい、そうです。」のような応答が出力されることになる。

（１−２）ユーザの確信度が中程度の場合

ここでは、ユーザは、明日に何かの予定があることは把握しているが、その日時については曖昧な場合を想定する。この場合において、ユーザは、例えば、「確か明日だったと思うけど、会議の予定があったっけ？」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は、「スケジュールチェック」であり、その引数は、「タイトル = "会議"」、及び「日時 = "2017年3月23日」であると推定し、スケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "会議"」、「日時 = "2017年3月23日 10時"」、及び「場所 = "大会議室"」を含むレコードが１件存在することが得られる。

そして、システム応答としては、例えば、「明日の10時から会議の予定が１件あります。場所は大会議室です。」が得られる。なお、一般的な音声対話システム１（図１）において、このシステム応答は、先の別の例で述べた「明日の10時は会議の予定だよね。」である発話に対する応答と同様の内容になっている。

しかしながら、このとき、ユーザ自身は会議が行われるのが、明日だったかどうかの確認ができればよいのであって、すべての細かい情報を求めているわけではない。よって、一般的な音声対話システム１（図１）で得られるシステム応答では、応答が情報過多であり、コミュニケーションのテンポが落ちてしまう。

それに対し、本技術を適用した音声対話システム２（図２）では、「確か明日だったと思う」であるユーザ発話データから、日時は「明日」であるが、時刻情報が含まれていないことや、「確か」という文言で修飾されていることなどによって、日時に対する確信度が、中程度であると推定することができる。また、タイトルについては、「会議」と明確に発話していることにより、確信度は高いものと推定することができる。

よって、確信度の高いタイトルについては省き、確信度が中程度の日時については、より詳細まで含めた「はい。明日の10時になります。」のようなシンプルなシステム応答を生成することができる。

このようなユーザの確信度が中程度の場合に、図２の音声対話システム２で実行される処理の内容は、例えば、次のようになる。

すなわち、ユーザ確信度推定部２１２によって、「確か明日だったと思うけど、会議の予定があったっけ？」である発話テキストデータに対し、解析処理が行われることで、ユーザの確信度が得られる。ここでは、予定の日時については、時刻情報が含まれていないことや、曖昧さを示す言葉で修飾されていることなどから、確信度は、中程度であると推定される。また、予定のタイトルについては、正確に示されていることから、確信度は高いものと推定される。

そして、出力生成部２０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当するレコードが１件存在することが得られるが、ユーザの確信度として、予定のタイトルに対する確信度は高いが、予定の日時に対する確信度は中程度であると推定されているため、確信度が中程度の日時については、詳細な情報を含めたシンプルなシステム応答が生成される。

ここでは、例えば、ユーザの確信度とシステム応答の情報量との間に、図７に示した関数f1のような関係がある場合に、例えば70である確信度のスコアが算出されたとき、予定の日時に対する確信度は中程度であると推定され、シンプルなシステム応答として、確信度が中程度の予定の日時に関する詳細な情報を含めた、「はい。明日の10時になります。」のような応答が出力されることになる。

（１−３）ユーザの確信度が低い場合

ここでは、ユーザは、明日に予定があるかどうかを把握していない場合を想定する。この場合において、ユーザは、例えば、「明日、何か予定がある？」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は、「スケジュールチェック」であり、その引数は、「日時 = "2017年3月23日"」であると推定し、スケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "会議"」、「日時 = "2017年3月23日 10時"」、及び「場所 = "大会議室"」を含むレコードと、「タイトル = "買い物"」、「日時 = "2017年3月23日 17時"」、及び「場所 = "渋谷"」を含むレコードとの２件のレコードが存在することが得られる。

そして、システム応答としては、例えば、「明日は、10時に大会議室にて会議の予定が、17時に渋谷にて買い物の予定があります。」が得られる。

それに対し、本技術を適用した音声対話システム２（図２）では、予定のタイトルに関する情報が、ユーザの発話中に含まれず、「何か」と具体的な指定を含まずに聞いていることにより、タイトルに関する確信度は低いと推定することができる。また、日時については、「明日」との指定があるが、時刻の指定はないことから、確信度は中程度であると推定することができる。

よって、例えば、「明日は、10時に会議の予定が、17時に買い物の予定があります。」のように、タイトル及び日時についての詳細を含めたシステム応答を生成することができる。このように、確信度が低い場合については、情報を多めに出すことにより、ユーザは、１回の対話で、欲しい情報を適切に得ることが可能となり、余計な対話を追加する必要がないため、テンポの良い対話を行うことができる。

このようなユーザの確信度が低い場合に、図２の音声対話システム２で実行される処理の内容は、例えば、次のようになる。

すなわち、ユーザ確信度推定部２１２によって、「明日、何か予定がある？」である発話テキストデータに対し、解析処理が行われることで、ユーザの確信度が得られる。ここでは、予定のタイトルについては、具体的な指定が含まれていないため、確信度は低いと推定される。また、予定の日時については、時刻情報が含まれていないことから、確信度は、中程度であると推定される。

そして、出力生成部２０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当する２件のレコードが存在することが得られるが、ユーザの確信度として、予定のタイトルに対する確信度は低く、予定の日時に対する確信度は中程度であると推定されるため、確信度が低いタイトルについては、より詳細な情報を含めたシステム応答が生成される。

ここでは、例えば、ユーザの確信度とシステム応答の情報量との間に、図７に示した関数f1のような関係がある場合に、例えば17である確信度のスコアが算出されたとき、予定のタイトルに対する確信度は低いと推定され、詳細なシステム応答として、確信度が低い予定のタイトルに関するより詳細な情報を含めた、「明日は、10時に会議の予定が、17時に買い物の予定があります。」のような応答が出力されることになる。

（１−４）ユーザの確信度は高いように見えるが、事実として間違っている場合

ここでは、ユーザが確信している内容に間違いがある場合を想定する。この場合において、ユーザは、例えば、「明後日の10時に会議の予定だよね。」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は、「スケジュールチェック」であり、その引数は「タイトル = "会議"」、及び「日時 = "2017年3月24日 10時"」であると推定し、スケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、スケジュールDBに登録済みの予定の中には、そのような内容を含むレコードは存在しないため、そのAPI出力として、予定が0件であることが得られる。そして、システム応答としては、例えば、「そのような予定はありません。」が得られる。

それに対し、本技術を適用した音声対話システム２（図２）では、上述した（１−１）の「ユーザの確信度が高い場合」と同様に、「タイトル = "会議"」及び「日時 = "2017年3月24日 10時"」が明確に示されていること、またそれらの情報に対して「多分」や「確か」などのような曖昧さを示す言葉も含まれていないことから、その予定のタイトル及び日時に対する確信度は高いものと推定することができる。

また、ここでは、指定された予定のタイトル及び日時を引数としたスケジュールAPIを実行することで得られるAPI出力が、予定0件であることから、ユーザの日時に対する確信度が間違いであったことを推定することができる。

よって、「いいえ、明日の10時です。」のように、正しい情報を付加してシステム応答を生成することができる。これにより、ユーザから改めて、正しい情報を確認する発話をすることなく、一度の対話で欲しい情報を得ることができる。

（１−５）事実として間違っている場合に、複数の選択肢があるとき

上述した（１−４）では、「明後日の10時に会議の予定だよね。」である発話に対し、「いいえ、明日の10時です。」であるシステム応答が生成される例を示したが、ユーザによっては、スケジュールDBに、複数の会議の予定が登録されている可能性があり、正しい情報を付加することが困難な場合も想定される。

そのような場合には、例えば、ユーザ側の音声処理装置１０で、カレンダのアプリケーションを起動して、登録済みの複数の会議の予定を、月単位や週単位で提示されるようにすることができる。このとき、登録済みのすべての予定が提示されるようにするほか、例えば、発話に含まれる「明後日」の近傍の予定だけを提示してもよい。

これにより、ユーザは、カレンダの提示内容を確認して、自身の発話の内容が間違っていたことだけでなく、例えば、他の会議の予定と勘違いしていたことや、明後日の10時の会議の予定の登録自体を忘れていたことなどを認識することができる。このとき、ユーザの傾向（例えば、あるユーザは、予定の登録を忘れることが多いなど）を学習して、次のカレンダの提示内容に反映させるようにしてもよい。

なお、上述した（１−１）の確信度が高い場合や、（１−２）の確信度が中程度の場合に、より簡潔なシステム応答が出力される場合を示したが、テンポの良い対話が行われるのであれば、システム応答の情報量を増やすようにしてもよい。例えば、上述した（１−１）のシステム応答として、例えば、「はい、そうです。」だけでなく、「はい、そうです。明日の10時から会議があります。」のように、後段の応答を加えて、より詳細なシステム応答が出力されるようにしてもよい。

（２）第２の実施の形態

上述した第１の実施の形態では、予定の対象者と、対話を通じて予定を確認しているユーザとが、同一の人物である場合について述べたが、次に、第２の実施の形態として、それらの人物が異なる場合について述べる。

（本技術の音声対話システムの構成）
図８は、本技術を適用した音声対話システムの他の構成例を示すブロック図である。

図８において、音声対話システム３は、音声認識部３０１、ユーザ意図及び確信度分析部３０２、対話制御部３０３、APIコール部３０４、出力生成部３０５、及び話者認識部３０６を含んで構成される。

図８において、音声認識部３０１乃至出力生成部３０５は、図２に示した音声認識部２０１乃至出力生成部２０５と同様に構成される。すなわち、図８の音声対話システム３は、図２の音声対話システム２と比べて、ユーザ意図及び確信度分析部３０２の前段に、話者認識部３０６が追加されている点が異なっている。

話者認識部３０６は、話者認識用のデータベースを参照して、そこに入力されるユーザ発話データを解析することで、話者を認識する。話者認識部３０６は、認識された話者に割り当てられたユーザIDを特定し、ユーザ意図及び確信度分析部３０２に供給する。

なお、話者認識用のデータベースには、例えば、話者ごとに、発話データとユーザIDとを対応付けた情報が、あらかじめ登録されている。また、ここでは、話者認識部３０６が、ユーザ発話データに基づき、話者を識別する場合を例示したが、話者を識別するために用いられるデータは、ユーザ発話データに限らず、例えば、センサ５４により撮像された被写体の画像データなどが用いられるようにしてもよい。

対話制御部３０３には、ユーザ意図及び確信度分析部３０２から、ユーザID、ユーザ意図候補データ、及びユーザ確信度データが供給される。対話制御部３０３は、ユーザ意図候補データ、及び対話履歴のデータベースなどに基づき、現在の対話の状態を推定し、コールすべきAPI及びその引数を決定する。対話制御部３０３は、決定されたAPI及び引数データを、APIコール部３０４に供給する。

また、対話制御部３０３は、ユーザ確信度データを、出力生成部３０５に供給する。ここでは、例えば、ユーザIDを用いることで、発話したユーザと、予定の対象者が異なることが認識されるため、対話制御部３０３は、出力生成部３０５に対し、ユーザ確信度データとして、他人の予定の確信度データを渡すことになる。

出力生成部３０５は、ユーザ確信度データ及びAPI出力のデータに基づき、ユーザに対する応答文章（システム応答）を生成し、その音声データに応じた応答音声を出力する。ここでは、他人の予定の確信度に応じて、システム応答の情報量が制御（調整）されるが、対話を通じて予定を確認している人物が異なるため、自分の予定の場合と比べて、応答情報量を増やすことができる。

次に、音声対話システム３により提供される音声対話サービスの具体例について説明する。ここでは、ある家族が、１つのスケジューラを共有して使用するケースを想定し、スケジュールDBには、図９に示した予定が、ユーザによって既に登録されているものとする。また、父親（パパ）が、母親（ママ）の予定を確認する対話を想定する。

図９においては、タイトル、日時、場所、及び対象者により特定される予定として、５つの予定が登録されている。すなわち、１つ目のレコードには、パパの予定として、2017年3月23日 10時に、大会議室での会議が登録されている。また、２つ目のレコードには、ママの予定として、2017年3月23日 10時に、新宿での買い物が登録されている。

また、３つ目のレコードには、パパの予定として、2017年3月23日 15時に、代々木での歯医者が登録されている。さらに、４つ目のレコードには、パパの予定として、2017年3月23日 17時に、渋谷での買い物が登録されている。また、５つ目のレコードには、ママの予定として、2017年3月23日 17時に、原宿での同窓会が登録されている。

以下の具体例では、このようなスケジュールDBとスケジュールAPIを有する音声対話システム３に対し、ユーザは、既に登録されている予定の確認を行う意図で、対話を行うものとする。ただし、以下の具体例においても、比較のために、一般的な音声対話システム１（図１）についても適宜説明するものとする。

（２−１）他人の予定についてのユーザ自身の確信度が高い場合

ここでは、ユーザ（パパ）は、ママの同窓会の予定が、明日の17時にあることは知っているが、それが正しいかどうかを確認したい場合を想定する。この場合において、ユーザ（パパ）は、例えば、「ママは、明日の17時に同窓会があるよね。」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は「スケジュールチェック」であり、その引数は、「タイトル = "同窓会"」、「日時 = "2017年3月23日 17時"」、及び「対象者 = "ママ"」であると推定し、スケジュールチェックを行うスケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "同窓会"」、「日時 = "2017年3月23日 17時"」、「対象者 = "ママ"」、及び「場所 = "原宿"」を含むレコードが１件存在することが得られる。

そして、システム応答としては、例えば、「明日の17時に同窓会の予定が原宿であります。」が得られる。

それに対し、本技術を適用した音声対話システム３（図８）では、ユーザの発話から得られる情報に基づき、ユーザ自身が欲しい情報（所望の情報）に対してどの程度確信しているか（確信度）を推定し、その結果に応じて応答の情報量を制御（調整）する。

上述した例では、ユーザの発話により、予定のタイトルや日時、対象者が明確に示されていることや、それらを形容する言葉の中に、「多分」や「確か」などのような曖昧さを示すものも含まれていないため、それらの確信度は高いものと推定される。

よって、例えば、「はい。そうです。」などのような簡潔なシステム応答を生成して出力することで、テンポの良い対話をすることが可能となる。

ただし、予定の場所については、その発話がなかったため、場所についての確信度が高いと判断することはできない。この例では、特に、発話したユーザ（パパ）と、予定の対象者（ママ）とが異なるため、あらかじめ場所について知っていることを前提とするのは、難しいと考えられる。

よって、例えば、「はい、あります。場所は原宿です。」などのように、システム応答に、場所情報を追加することが望ましい。

このような、他人の予定についてのユーザ自身の確信度が高い場合に、図８の音声対話システム３で実行される処理の内容は、例えば、次のようになる。

すなわち、ユーザ確信度推定部３１２によって、「ママは、明日の17時に同窓会があるよね。」である発話テキストデータに対し、解析処理が行われることで、他人の予定についてのユーザの確信度が得られる。ここでは、予定のタイトルや日時、対象者が明確に示されていることや、曖昧さを示す言葉が含まれていないことなどから、それらの確信度は高いと推定される。

そして、出力生成部３０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当するレコードが１件存在することが得られるが、他人の予定についてのユーザの確信度として、予定のタイトルや日時、対象者に対する確信度は高いと推定されているため、より簡潔なシステム応答が生成される。

ここでは、例えば、ユーザの確信度とシステム応答の情報量との間には、例えば、図１０に示すような関係を有している。図１０においては、図７と同様に、横軸をユーザの確信度とし、縦軸をシステム応答の情報量としたときの関係を表しているが、自分の予定の場合の関係を関数f1により表すとともに、他人の予定の場合の関係を関数f2により表している。

すなわち、図１０において、関数f1と関数f2は、同一の傾きを有し、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、負の比例の関係を有している点で共通するが、切片が異なっており、同じ確信度であれば、関数f1よりも、関数f2のほうが、応答情報量が大きくなる。

換言すれば、自分の予定と比べて、他人の予定は、把握していないことが多いので、同じ確信度でも、自分の予定と他人の予定とで、応答情報量を変えているのである。

ここでは、例えば、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となるように、閾値（Th1，Th2）が設定されているものとする。

このとき、例えば、90である確信度のスコアが算出されたとき、予定のタイトルや日時、対象者に対する確信度は高いと推定され、簡潔なシステム応答として、「はい。そうです。」のような応答を出力することができるが、他人の予定であるから、場所情報などを追加して、例えば、「はい、あります。場所は原宿です。」のように、応答情報量を増やすことが望ましい。

（２−２）他人の予定についてのユーザ自身の確信度が中程度の場合

ここでは、ユーザ（パパ）は、明日、何かママの予定があることは把握しているが、その日時や内容については曖昧である場合を想定する。この場合において、ユーザ（パパ）は、例えば、「確か明日だったと思うけど、ママは買い物に行くんだっけ？」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は「スケジュールチェック」であり、その引数は、「タイトル = "買い物"」、「日時 = "2017年3月23日"」、及び「対象者 = "ママ"」であると推定し、スケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "買い物"」、「日時 = "2017年3月23日 10時"」、「場所 = "新宿"」、及び「対象者 = "ママ"」を含むレコードが１件存在することが得られる。

そして、システム応答としては、例えば、「明日の10時に新宿で買い物の予定が１件あります。」が得られる。

それに対し、本技術を適用した音声対話システム３（図８）では、ユーザの発話に、時刻情報がなく、さらに「明日」が、「確か」により修飾されているため、日時の確信度は低く、また、ユーザの発話に、「行くんだっけ？」の表現が含まれることから、タイトルに対する確信度は、中程度であると推定することができる。また、場所に対する発話もないため、その確信度も低いと推定することができる。

よって、例えば、「明日の10時に新宿に買い物に行く予定があります。」のように、確信度の低い情報を含めた応答を返すことができる。これにより、ユーザは、欲しい情報が一度に得られ、スムーズなコミュニケーションを実現することができる。

このような、他人の予定についてのユーザ自身の確信度が中程度の場合に、図８の音声対話システム３で実行される処理の内容は、例えば、次のようになる。

すなわち、ユーザ確信度推定部３１２によって、「確か明日だったと思うけど、ママは買い物に行くんだっけ？」である発話テキストデータに対し、解析処理が行われることで、他人の予定についてのユーザの確信度が得られる。ここでは、予定の日時については、時刻情報が含まれていないことや、曖昧さを示す言葉で修飾されていることなどから、日時に対する確信度は低く、さらに、ユーザの発話に含まれる表現から、タイトルに対する確信度は、中程度であると推定される。

そして、出力生成部３０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当するレコードが１件存在することが得られるが、他人の予定についてのユーザの確信度として、予定の日時に対する確信度は低く、予定のタイトルに対する確信度は、中程度であると推定されているため、確信度が中程度のタイトルと、確信度が低い日時については、詳細な情報を含めたシステム応答が生成される。

ここでは、他人の予定についてのユーザの確信度とシステム応答の情報量との間に、図１０に示した関数f2のような関係がある場合に、例えば60である確信度のスコアが算出されたとき、予定のタイトルに対する確信度は、中程度であると推定され、確信度が中程度の予定のタイトルに関する詳細な情報を含めた、「明日の10時に新宿に買い物に行く予定があります。」のような応答が出力されることになる。ただし、ここでは、他人の予定であるから、「新宿」である場所情報を追加して、応答情報量を増やしている。

（２−３）他人の予定についてのユーザ自身の確信度が低い場合

ここでは、ユーザ（パパ）が、ママの予定を把握していない場合を想定する。この場合において、ユーザは、例えば、「明日、ママは何か予定はあるかな？」と発話したものとする。

このとき、一般的な音声対話システム１（図１）では、ユーザの意図は、「スケジュールチェック」であり、その引数は、「日時 = "2017年3月23日"」、及び「対象者 = "ママ"」であると推定し、スケジュールAPIに対し、それらの引数を渡すことになる。

このスケジュールAPIが実行されると、そのAPI出力として、スケジュールDBに登録済みの予定の中に、「タイトル = "買い物"」、「日時 = "2017年3月23日 10時"」、「場所 = "新宿"」、及び「対象者 = "ママ"」を含むレコードと、「タイトル = "同窓会"」、「日時 = "2017年3月23日 17時"」、「場所 = "原宿"」、及び「対象者 = "ママ"」を含むレコードとの２件のレコードが存在することが得られる。

そして、システム応答としては、例えば、「明日の10時に新宿で買い物の予定が１件、17時に原宿で同窓会の予定が１件あります。」が得られる。

それに対し、本技術を適用した音声対話システム３（図８）では、予定のタイトル、日時、及び場所に対する確信度が低いものと推定することができる。

よって、例えば、「明日の10時に新宿で買い物の予定が１件、17時に原宿で同窓会の予定が１件ありますよ。」のように、ユーザの確信度が低い情報に対して、具体的な情報を提示することで、ユーザは欲しい情報を一度に得ることができるため、スムーズなコミュニケーションを実現することが可能となる。

このような他人の予定についてのユーザ自身の確信度が低い場合に、図８の音声対話システム３で実行される処理の内容は、例えば、次のようになる。

すなわち、ユーザ確信度推定部３１２によって、「明日、ママは何か予定はあるかな？」である発話テキストデータに対し、解析処理が行われることで、他人の予定についてのユーザの確信度が得られる。ここでは、予定のタイトル、日時、及び場所に対する確信度が低いものと推定される。

そして、出力生成部３０５では、API出力として、スケジュールDBに登録済みの予定の中に、該当する２件のレコードが存在することが得られるが、他人の予定についてのユーザの確信度として、予定のタイトル、日時、及び場所に対する確信度は低いと推定されているため、より詳細な情報を含めたシステム応答が生成される。

ここでは、他人の予定についてのユーザの確信度とシステム応答の情報量との間に、図１０に示した関数f2のような関係がある場合に、例えば21である確信度のスコアが算出されたとき、予定のタイトル、日時、及び場所に対する確信度は低いと推定され、より詳細な情報を含めた、「明日の10時に新宿で買い物の予定が１件、17時に原宿で同窓会の予定が１件ありますよ。」のような応答が出力されることになる。

なお、ここで挙げた２つの例（（２−２）と（２−３）の場合）では、一般的な音声対話システム１（図１）と、本技術を適用した音声対話システム３（図８）とで、システム応答に、大きな差異はない。これは、他人の予定であることによって、場所情報に対する暗黙の確信が得られないため、ユーザの確信度のランクが必然的に下がって、本来、情報を多めに出力する一般的な手法と、ユーザの確信度に応じて情報量を調整する本技術の手法とで、その出力情報量が同じになったためである。

なお、このような、自分の予定に比べて、他人の予定の場合には、ユーザの確信度のランクが下がるために、応答情報量を増やすことは、図１０に示した関数f1と関数f2との関係からも明らかである。

（３）第３の実施の形態

以上で述べたように、確信度の推定の手法については、ユーザの発話中に、対象情報が明確に含まれるか、曖昧さを示す言葉による修飾が行われているか、あるいは、発話したユーザ自身の情報か否か、といった指標を用いることができる。

一方で、ユーザの意図と確信度との関係を、その事例に基づき、学習して獲得することもできる。すなわち、発話テキストだけでなく、例えば、その他の音声情報やジェスチャ、視線、顔の表情などを利用することができる。

（本技術の音声対話システムの構成）
図１１は、本技術を適用した音声対話システムの他の構成例を示すブロック図である。

図１１において、音声対話システム４は、音声認識部４０１、ユーザ意図及び確信度分析部４０２、対話制御部４０３、APIコール部４０４、出力生成部４０５、話者認識部４０６、ジェスチャ認識部４０７、視線認識部４０８、顔向き認識部４０９、及びユーザ位置認識部４１０を含んで構成される。

図１１において、音声認識部４０１乃至出力生成部４０５は、図２に示した音声認識部２０１乃至出力生成部２０５と同様に構成される。また、話者認識部４０６は、図８に示した話者認識部３０６と同様に構成される。

すなわち、図１１の音声対話システム４は、図２の音声対話システム２及び図８の音声対話システム３と比べて、ユーザ意図及び確信度分析部４０２の前段に、ジェスチャ認識部４０７、視線認識部４０８、顔向き認識部４０９、及びユーザ位置認識部４１０が追加されている点が異なっている。

なお、ジェスチャ認識部４０７、視線認識部４０８、顔向き認識部４０９、及びユーザ位置認識部４１０には、例えば、音声処理装置１０（図４）に設けられたセンサ５４により検出されたセンサ情報（センサデータ）が入力される。

ジェスチャ認識部４０７は、そこに入力されるセンサデータを用いたジェスチャ認識処理を行うことで、ユーザのジェスチャを認識し、その認識結果を、ユーザ意図及び確信度分析部４０２に供給する。ここで用いられるセンサデータは、例えば、ユーザのジェスチャを検出するための専用のセンサや、ユーザを被写体に含む画像データを取得するイメージセンサ等の各種のセンサから得られる情報とされる。

視線認識部４０８は、そこに入力されるセンサデータを用いた視線認識処理を行うことで、ユーザの視線を認識し、その認識結果を、ユーザ意図及び確信度分析部４０２に供給する。ここで用いられるセンサデータは、例えば、ユーザの視線を検出するための専用のセンサや、ユーザを被写体に含む画像データを取得するイメージセンサ等の各種のセンサから得られる情報とされる。

顔向き認識部４０９は、そこに入力されるセンサデータを用いた顔向き認識処理を行うことで、ユーザの顔向きを認識し、その認識結果を、ユーザ意図及び確信度分析部４０２に供給する。ここで用いられるセンサデータは、例えば、ユーザの顔向きを検出するための専用のセンサや、ユーザを被写体に含む画像データを取得するイメージセンサ等の各種のセンサから得られる情報とされる。

ユーザ位置認識部４１０は、そこに入力されるセンサ位置情報を用いた位置認識処理を行うことで、ユーザの位置を認識し、その認識結果を、ユーザ意図及び確信度分析部４０２に供給する。ここで用いられるセンサデータは、例えば、ユーザの位置を検出するための専用のセンサ（例えば、GPSモジュールなど）や、ユーザの場所を特定可能な被写体を含む画像データを取得するイメージセンサ等の各種のセンサから得られる情報とされる。

ユーザ意図及び確信度分析部４０２には、音声認識部４０１からの発話テキストデータ、及び話者認識部４０６からのユーザIDとともに、ジェスチャ認識部４０７、視線認識部４０８、顔向き認識部４０９、及びユーザ位置認識部４１０からの認識結果が入力される。ユーザ意図及び確信度分析部４０２は、ユーザ意図分析部４１１及びユーザ確信度推定部４１２を含んで構成される。

ユーザ確信度推定部４１２は、発話テキストデータに対し解析処理を施して、ユーザの確信度を推定するに際し、センサデータから得られる認識結果に基づいたユーザの行動を考慮して、ユーザの確信度が得られるようにする。ここでは、ユーザの行動として、例えば、次のような傾向が見られた場合に、ユーザの確信度を下げるべきケースに該当するものとする。

（ａ）話し方がゆっくりになる。
（ｂ）話す声が高くなる。
（ｃ）視線が落ち着かない。
（ｄ）音声対話システム（音声処理装置１０）のすぐそばに来る。
（ｅ）音声対話システム（音声処理装置１０）の方向に顔を向ける。
（ｆ）両腕による身振り手振りの動作が大きくなる。
（ｇ）欠伸をしている。

このような、ユーザの行動として、例えば、上記の（ａ）乃至（ｇ）の傾向が見られる場合に、その確信度は低いものと推定するアルゴリズムを追加することで、ユーザの確信度の推定の精度を向上させることができる。また、これらのユーザの行動に関する行動データを逐次記録しておいて、この行動データ（の履歴）を用いた学習を行うことで得られる傾向に基づき、確信度が推定されるようにしてもよい。

なお、ユーザの行動は、センサ５４から得られるセンサデータに基づき認識されるものであればよく、例えば、温度センサや湿度センサにより検出される温度や湿度の情報のほか、計時手段により計時される時刻情報などを用いて認識されるようにしてもよい。例えば、時刻情報を用い、早朝に欠伸をしている場合には、確信度が低いなどとすることもできる。

以上、第１の実施の形態乃至第３の実施の形態について説明した。これらの実施の形態で述べた手法を用いることで、ユーザは欲しい情報を、適切な情報量で得ることができるため、テンポの良いスムーズなコミュニケーションを実現することが可能となる。

なお、上述した特許文献１には、音声対話システムとして、システム側の確信度に応じて応答を切り替えるものとして、システムが、ユーザの発話意図を分析した際の結果に対するシステム自身の確信度に応じて応答を切り替える手法が開示されている。しかしながら、この手法では、ユーザがどの程度確信しているかを推定する仕組みがないため、ユーザの確信度が低い場合でも、あるいは確信度が高い場合でも、システム自身の確信度が同じときには、同じ情報量の応答を生成してしまうため、上述した実施の形態で述べた手法のように、テンポの良いスムーズなコミュニケーションを実現することはできない。

＜３．変形例＞

上述した説明では、サーバ２０の処理部７１が、音声認識部２０１乃至出力生成部２０５により提供される機能のうち、音声認識部２０１、ユーザ意図及び確信度分析部２０２、対話制御部２０３、APIコール部２０４、及び出力生成部２０５の一部の機能を有しているとして説明したが、処理部７１は、音声認識部２０１乃至出力生成部２０５により提供される機能のうち、少なくとも一部の機能を有していればよい。

また、音声処理装置１０の処理部５１が、構成する音声認識部２０１乃至出力生成部２０５により提供される機能のうち、音声認識部２０１に対し、ユーザ発話データを入力するための機能と、システム応答（の音声データ）に応じた応答音声を出力するための機能を有しているとして説明したが、処理部５１は、音声認識部２０１乃至出力生成部２０５により提供される機能のうち、少なくとも一部の機能を有していればよい。

すなわち、音声認識部２０１乃至出力生成部２０５により提供される機能のうち、サーバ２０の処理部７１が有する機能を除いた機能が、音声処理装置１０の処理部５１が有する機能とされる。

ただし、音声処理装置１０の処理部５１が、音声認識部２０１乃至出力生成部２０５により提供される機能のすべての機能を有し、音声対話システムの機能が音声処理装置１０のみによって実現されるようにしてもよい。その際に、データベース７３は、音声処理装置１０に内蔵してもよいし、あるいは、インターネット３０上のサーバ２０により提供されるようにしてもよい。

また、上述した説明では、図２の出力生成部２０５（図８出力生成部３０５、図１１の出力生成部４０５）が、ユーザの確信度を用い、応答の情報量を制御（調整）する場合を説明したが、他のブロックが、ユーザの確信度を用いた応答の情報量の制御を行ってもよい。

そこで、次に、図１２乃至図１４を参照して、本技術を適用した音声対話システムの構成の変形例について説明する。なお、ここでは、比較のために、一般的なテキストチャットシステムの構成についても説明する。

（一般的なテキストチャットシステムの構成）
図１２は、一般的なテキストチャットシステムの構成を示すブロック図である。

図１２において、一般的なテキストチャットシステム６は、ユーザ意図分析部６０２、対話制御部６０３、APIコール部６０４、及び出力生成部６０５を含んで構成される。

ユーザ意図分析部６０２には、テキストチャットで、ユーザにより入力されたテキストデータが供給される。ユーザ意図分析部６０２は、テキストデータを処理して、ユーザの意図を分析し、その分析の結果得られるユーザ意図候補データを、対話制御部６０３に供給する。

対話制御部６０３は、ユーザ意図分析部６０２から供給されるユーザ意図候補データなどに基づき、現在の対話状態を推定し、コールすべきAPI及びその引数を決定する。対話制御部６０３は、API及び引数データを、APIコール部６０４に供給する。

APIコール部６０４は、対話制御部６０３から供給されるAPI及び引数データに基づき、コールすべきAPIにその引数を渡して実行し、その結果得られるAPI出力を、出力生成部６０５に供給する。

出力生成部６０５は、APIコール部６０４から供給されるAPI出力に基づき、システム応答として、テキストデータや画像データに応じた情報を出力する。

一般的なテキストチャットシステム６は、以上のように構成される。ここで、本技術の音声対話システム（例えば、図２の音声対話システム２）においても、ユーザ意図及び確信度分析部２０２に、発話テキストデータの代わりに、テキストチャットのテキストデータが入力され、発話テキストデータと同様の処理が行われるようにしてもよい。この場合、出力生成部２０５は、システム応答として、テキストデータや画像データに応じた情報を出力することになる。なお、このとき、図２の音声対話システム２において、音声認識部２０１は不要とされる。

（本技術の音声対話システムの構成の第１の変形例）
図１３は、本技術を適用した音声対話システムの構成の第１の変形例を示すブロック図である。

図１３において、音声対話システム７は、音声認識部７０１、ユーザ意図及び確信度分析部７０２、対話制御部７０３、APIコール部７０４、及び出力生成部７０５を含んで構成される。

図１３において、音声認識部７０１、ユーザ意図及び確信度分析部７０２、及びAPIコール部７０４は、図２に示した音声認識部２０１、ユーザ意図及び確信度分析部２０２、及びAPIコール部２０４と同様に構成される。

すなわち、図１３の音声対話システム７は、図２の音声対話システム２と比べて、対話制御部７０３と出力生成部７０５の機能が異なっている。

具体的には、対話制御部７０３は、ユーザ意図候補データ及び対話履歴データベースなどに基づき、現在の対話状態を推定してコールすべきAPI及びその引数を決定する際に、ユーザ確信度データを用いて最適なAPIが選択されるようにする。ただし、このとき、応答の情報量に応じて、選択可能なAPIが分かれているものとし、ユーザの確信度に応じた情報量の応答が得られるAPIが選択されることになる。

APIコール部７０４は、対話制御部７０３から供給されるAPI及び引数データに基づき、コールすべきAPIにその引数を渡して実行する。

出力生成部７０５は、APIコール部７０４から供給されるAPI出力のデータに基づき、システム応答を生成し、その音声データに応じた応答音声を出力する。ただし、対話制御部７０３において、ユーザ確信度データを用いて最適なAPIが選択され、応答文章に含める情報量は調整済みであるため、ここでは情報量を調整する必要はない。

音声対話システム７は、以上のように構成される。

（本技術の音声対話システムの構成の第２の変形例）
図１４は、本技術を適用した音声対話システムの構成の第２の変形例を示すブロック図である。

図１４において、音声対話システム８は、音声認識部８０１、ユーザ意図及び確信度分析部８０２、対話制御部８０３、APIコール部８０４、及び出力生成部８０５を含んで構成される。

図１４において、音声認識部８０１、及びユーザ意図及び確信度分析部８０２は、図２に示した音声認識部２０１、及びユーザ意図及び確信度分析部２０２と同様に構成される。

すなわち、図１４の音声対話システム８は、図２の音声対話システム２と比べて、対話制御部８０３と、APIコール部８０４と、出力生成部８０５の機能が異なっている。

具体的には、対話制御部８０３は、ユーザ意図候補データ、及び対話履歴のデータベースなどに基づき、現在の対話状態を推定し、コールすべきAPI及びその引数を決定する。対話制御部８０３は、API及び引数データを、APIコール部８０４に供給する。

APIコール部８０４は、対話制御部８０３から供給されるAPI及び引数データに基づき、コールすべきAPIにその引数を渡して実行し、その結果得られるAPI出力を、対話制御部８０３に返す。

対話制御部８０３は、ユーザ確信度データ及びAPI出力のデータに基づき、応答文章に含める情報量を調整した出力を生成し、出力生成部８０５に供給する。

ここでは、ユーザに対するシステム応答そのものを生成して出力してもよいし、あるいはシステム応答の生成に必要な情報のみを出力して、システム応答の生成は、後段の出力生成部８０５に任せるようにしてもよい。

出力生成部８０５は、対話制御部８０３からの出力に基づき、システム応答に応じた応答音声を出力する。ただし、システム応答が、出力生成部８０５側で生成されるようにしてもよいことは先に述べた通りである。

音声対話システム８は、以上のように構成される。

ところで、音声対話システム２（図２）においては、音声認識部２０１に対し、ユーザ発話データが直接入力される場合を説明したが、ユーザ発話データを処理してから、音声認識部２０１に入力されるようにしてもよい。そこで、次に、図１５を参照して、ユーザ発話データに対する前処理を行う構成について説明する。

（本技術の音声対話システムの構成の第３の変形例）
図１５は、本技術を適用した音声対話システムの構成の第３の変形例を示すブロック図である。

図１５において、音声対話システム２は、音声認識部２０１、ユーザ意図及び確信度分析部２０２、対話制御部２０３、APIコール部２０４、出力生成部２０５、及び前処理部２２１を含んで構成される。

図１５において、音声認識部２０１乃至出力生成部２０５は、図２に示した音声認識部２０１乃至出力生成部２０５と同様に構成される。すなわち、図１５の音声対話システム２は、図２の音声対話システム２と比べて、音声認識部２０１の前段に、前処理部２２１が追加されている点が異なっている。

前処理部２２１は、そこに入力される音声信号に対し、例えばエコーキャンセルやノイズ除去等の信号処理を行い、その結果得られるユーザ発話データを、音声認識部２０１に供給する。

ここで、例えば、音声処理装置１０は、マイクロフォン５２とスピーカ５３を有しているため、スピーカ５３からの音を、マイクロフォン５２が拾ってしまう可能性があるので、エコーキャンセル等の信号処理を行うことで、ユーザ発話データのみが得られるようにする。より具体的には、音声処理装置１０にて音楽を再生している場合には、スピーカ５３から出力される音楽を除いた音声信号であって、マイクロフォン５２により収音された音声信号が、ユーザ発話データとして得られるようにする。

なお、前処理部２２１は、基本的には、音声処理装置１０の処理部５１が有する機能とされるが、サーバ２０の処理部７１が有する機能としてもよい。その場合には、音声処理装置１０が、インターネット３０を介して音声信号をサーバ２０に送信することで、サーバ２０側で、音声信号に対する信号処理が行われる。

音声対話システム２は、以上のように構成される。

ところで、上述した説明では、図７及び図１０に示したように、ユーザの確信度とシステム応答の情報量との間には、負の比例関係があるとして説明したが、その関係は一例であって、例えば、反比例の関係など、線形又は非線形の関係を有していればよい。

そこで、次に、図１６乃至図１９を参照して、ユーザの確信度とシステム応答の情報量との関係の変形例について説明する。なお、これらの関係は、所定のアルゴリズムに従い算出されるようにしてもよいし、手動により定義されるようにしてもよい。また、ユーザごとに蓄積されたデータを用いた機械学習を適用してもよい。

（確信度と応答情報量の関係の第１の変形例）
図１６は、ユーザの確信度とシステム応答の情報量との関係の第１の変形例を示す図である。

なお、図１６においては、図７及び図１０と同様に、横軸をユーザの確信度とし、縦軸をシステム応答の情報量（応答情報量）としたときのユーザの確信度と応答情報量との関係を表している。後述する図１７乃至図１９についても同様である。

図１６において、関数f3は、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、反比例の関係を有している。

ここでは、例えば、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となるように、閾値（Th1，Th2）を設定することができる。

（確信度と応答情報量の関係の第２の変形例）
図１７は、ユーザの確信度とシステム応答の情報量との関係の第２の変形例を示す図である。

図１７において、関数f4は、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、階段状の関係を有している。

ここでは、閾値として、例えば、Th1 = 25, Th2 = 75を設定することで、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となる。ただし、関数f4は、階段状の関係を有しているため、高い確信度、中程度の確信度、及び低い確信度ごとに、応答情報量は、一定の情報量となっている。

（確信度と応答情報量の関係の第３の変形例）
図１８は、ユーザの確信度とシステム応答の情報量との関係の第３の変形例を示す図である。

図１８において、関数f5は、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、弧状の関係を有している。

ここでは、閾値として、例えば、Th1 = 25, Th2 = 75を設定することで、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となる。ただし、関数f5は、弧状の関係を有しているため、高い確信度、中程度の確信度、及び低い確信度ごとに、応答情報量は、緩やかに変化している。

（確信度と応答情報量の関係の第４の変形例）
図１９は、ユーザの確信度とシステム応答の情報量との関係の第４の変形例を示す図である。

図１９において、関数f6は、ユーザの確信度が低いほど、応答情報量が大きくなる一方で、ユーザの確信度が高いほど、応答情報量が小さくなる、Ｓ字状の関係を有している。

ここでは、閾値として、例えば、Th1 = 25, Th2 = 75を設定することで、75であるスコア以上が高い確信度となり、25であるスコア未満が低い確信度となり、25であるスコア以上で、かつ、75であるスコア未満が中程度の確信度となる。ただし、関数f6は、弧状の関係を有しているため、高い確信度、中程度の確信度、及び低い確信度ごとに、応答情報量は、やや緩やかに変化している。

なお、図１６乃至図１９には、明記していないが、図１０の関係と同様に、例えば、関数f3（関数f4, f5, f6）が、自分の予定の場合の関係を表しているとき、他人の予定の関係は、関数f3（関数f4, f5, f6）を右方向にずらしたような関係となって、同じ確信度であれば、自分の予定を表す関数f3（関数f4, f5, f6）よりも、他人の予定の関係を表す関数のほうが、応答情報量が大きくなるようにすればよい。

すなわち、自分の予定と比べて、他人の予定は把握していないことが多いので、同じ確信度でも、自分の予定と他人の予定とで、応答情報量を変えることができる。

（APIの他の例）
上述した説明では、ユーザの意図（インテンション）に応じたAPIとして、スケジュールチェックを行うスケジュールAPIを一例に説明したが、例えば、ニュースや天気のチェックを行うAPI、音楽の再生を行うAPIなど、他のAPIであっても同様に適用することができる。例えば、これらのAPIは、音声処理装置１０又はサーバ２０にて実行されるアプリケーションにより呼び出すことができる。また、上述した説明では、スケジュールAPIの引数（スロット）として、タイトル、日時、場所、及び対象者を一例に説明したが、それらの引数の一部を削除したり、あるいは他の引数（例えば、登録者など）を追加したりするようにしてもよい。

（確信度のスコアの例）
また、確信度のスコアは、例えば、ユーザの発話ごとに算出したり、あるいはユーザの発話に含まれる単語ごとに算出したりすることができる。例えば、ユーザの発話に含まれる単語として、タイトル、日時、場所、又は対象者などの引数に応じた単語ごとの確信度のスコアを算出することができる。また、例えば、タイトルや日時などの引数に応じた単語ごとの確信度のスコアを算出して、集計するようにしてもよい。ここでの集計としては、例えば、確信度のスコアの合計値や平均値、最大値などを求めることができる。

＜４．音声対話処理の流れ＞

次に、図２０のフローチャートを参照して、音声対話処理の一例として、音声対話システム２（図２）により実行される音声対話処理の流れについて説明する。

なお、図２０のフローチャートに示した処理ステップのうち、ステップＳ１１乃至Ｓ１３は、音声処理装置１０の処理部５１（図４）により実行され、ステップＳ２１乃至Ｓ２７の処理は、サーバ２０の処理部７１（図５）により実行される。

ステップＳ１１において、処理部５１は、ユーザにより発話がなされた場合、マイクロフォン５２を介して、当該ユーザの発話を受け付ける。ここでは、例えば、「明日の10時は会議の予定だよね。」や「確か明日だったと思うけど、会議の予定があったっけ？」などのユーザの発話が受け付けられる。

ステップＳ１２において、通信I/F５５は、ステップＳ１１の処理で受け付けられたユーザ発話データを、インターネット３０を介して、サーバ２０に送信する。

音声処理装置１０から送信されてくるユーザ発話データは、サーバ２０の通信I/F７２により受信され、サーバ２０では、ステップＳ２１乃至Ｓ２７の処理が実行される。

ステップＳ２１において、処理部７１の音声認識部２０１は、音声テキスト変換用のデータベースを参照することで、音声認識処理を行い、音声処理装置１０から受信したユーザ発話データを、発話テキストデータに変換する。

ステップＳ２２において、処理部７１のユーザ意図分析部２１１は、ステップＳ２１の処理で得られる発話テキストデータに基づき、ユーザ意図分析処理を行う。

ステップＳ２３において、処理部７１のユーザ確信度推定部２１２は、ステップＳ２１の処理で得られる発話テキストデータに基づき、ユーザ確信度推定処理を行う。

ステップＳ２４において、処理部７１の対話制御部２０３は、ステップＳ２２の処理で得られるユーザ意図候補データ、及び対話履歴のデータベースなどに基づき、現在の対話状態を推定し、コールすべきAPI及びその引数を決定する。

ステップＳ２５において、処理部７１のAPIコール部２０４は、ステップＳ２４の処理で得られるAPI及び引数データに基づき、コールすべきAPI（例えば、スケジュールAPI）にその引数を渡して実行する。

ステップＳ２６において、処理部７１の出力生成部２０５は、ステップＳ２３の処理で得られるユーザ確信度データ、及びステップＳ２５の処理で得られるAPI出力に基づき、ユーザの確信度に応じて応答文章に含める情報量が制御（調整）されたシステム応答を生成する。

ステップＳ２７において、通信I/F７２は、ステップＳ２６の処理で得られるシステム応答を、インターネット３０を介して、音声処理装置１０に送信する。

サーバ２０から送信されてくる処理データ（システム応答のデータ）は、音声処理装置１０の通信I/F５５により受信され、音声処理装置１０では、ステップＳ１３の処理が実行される。

ステップＳ１３において、処理部５１の出力生成部２０５は、サーバ２０から受信したシステム応答に応じた応答音声を、スピーカ５３から出力する。ここでは、例えば、「はい、そうです。」や「はい。明日の10時になります。」などのユーザの確信度に応じた情報量で、簡潔な応答音声が出力される。なお、ユーザの確信度に応じて応答文章に含める情報量を制御（調整）する処理は、クライアント側の処理部５１の出力生成部２０５（例えばアプリケーション）により実行されるようにしてもよい。

以上、音声対話処理の流れについて説明した。

＜５．コンピュータの構成＞

上述した一連の処理（例えば、図２０に示した音声対話処理）は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、各装置のコンピュータにインストールされる。図２１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

コンピュータ２０００において、CPU(Central Processing Unit)２００１、ROM(Read Only Memory)２００２、RAM(Random Access Memory)２００３は、バス２００４により相互に接続されている。バス２００４には、さらに、入出力インターフェース２００５が接続されている。入出力インターフェース２００５には、入力部２００６、出力部２００７、記録部２００８、通信部２００９、及び、ドライブ２０１０が接続されている。

入力部２００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２００７は、ディスプレイ、スピーカなどよりなる。記録部２００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２００９は、ネットワークインターフェースなどよりなる。ドライブ２０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体２０１１を駆動する。

以上のように構成されるコンピュータ２０００では、CPU２００１が、ROM２００２や記録部２００８に記録されているプログラムを、入出力インターフェース２００５及びバス２００４を介して、RAM２００３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ２０００（CPU２００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体２０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

コンピュータ２０００では、プログラムは、リムーバブル記録媒体２０１１をドライブ２０１０に装着することにより、入出力インターフェース２００５を介して、記録部２００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部２００９で受信し、記録部２００８にインストールすることができる。その他、プログラムは、ROM２００２や記録部２００８に、あらかじめインストールしておくことができる。

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

また、図２０に示したフローチャートで説明した音声対話処理の各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

なお、本技術は、以下のような構成をとることができる。

（１）
ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整する処理部を備える
情報処理装置。
（２）
前記確信度は、前記ユーザの発話から得られる情報に基づき推定され、
前記応答は、前記ユーザの発話に対する応答とされる
前記（１）に記載の情報処理装置。
（３）
前記確信度は、前記ユーザの行動から、あらかじめ学習することで得られる傾向に基づき推定される
前記（１）又は（２）に記載の情報処理装置。
（４）
前記確信度と前記応答に含まれる情報量との関係は、線形又は非線形の関係とされる
前記（１）乃至（３）のいずれかに記載の情報処理装置。
（５）
前記関係は、比例又は反比例の関係である
前記（４）に記載の情報処理装置。
（６）
前記確信度は、センサから得られるセンサ情報に基づき推定される
前記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
前記センサ情報は、前記ユーザのジェスチャ認識情報、視線認識情報、顔向き認識情報、及び位置情報のいずれかの情報を少なくとも含んでいる
前記（６）に記載の情報処理装置。
（８）
前記所望の情報は、他のユーザに関する情報であり、
前記確信度は、前記所望の情報の対象者に応じて変動する
前記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）
前記確信度は、前記対象者が前記他のユーザである場合に、前記対象者が前記ユーザである場合と比べて低くなる
前記（８）に記載の情報処理装置。
（１０）
前記応答は、前記ユーザの意図に応じたAPI(Application Programming Interface)に対し、その引数として、前記所望の情報から得られる値を渡して実行することで得られる
前記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）
情報処理装置の情報処理方法において、
前記情報処理装置が、
ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整する
ステップを含む情報処理方法。

２，３，４，７，８ 音声対話システム， １０ 音声処理装置， ２０ サーバ， ３０ インターネット， ５１ 処理部， ５２ マイクロフォン， ５３ スピーカ， ５４ センサ， ５５ 通信I/F， ７１ 処理部， ７２ 通信I/F， ７３ データベース， ２０１ 音声認識部， ２０２ ユーザ意図及び確信度分析部， ２０３ 対話制御部， ２０４ APIコール部， ２０５ 出力生成部， ２１１ ユーザ意図分析部， ２１２ ユーザ確信度推定部， ２２１ 前処理部， ３０６ 話者認識部， ４０７ ジェスチャ認識部， ４０８ 視線認識部， ４０９ 顔向き認識部， ４１０ ユーザ位置認識部， ７０３ 対話制御部， ８０３ 対話制御部， ２０００ コンピュータ， ２００１ CPU

Claims (11)

1. ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整する処理部を備える
   情報処理装置。
2. 前記確信度は、前記ユーザの発話から得られる情報に基づき推定され、
   前記応答は、前記ユーザの発話に対する応答とされる
   請求項１に記載の情報処理装置。
3. 前記確信度は、前記ユーザの行動から、あらかじめ学習することで得られる傾向に基づき推定される
   請求項１に記載の情報処理装置。
4. 前記確信度と前記応答に含まれる情報量との関係は、線形又は非線形の関係とされる
   請求項１に記載の情報処理装置。
5. 前記関係は、比例又は反比例の関係である
   請求項４に記載の情報処理装置。
6. 前記確信度は、センサから得られるセンサ情報に基づき推定される
   請求項１に記載の情報処理装置。
7. 前記センサ情報は、前記ユーザのジェスチャ認識情報、視線認識情報、顔向き認識情報、及び位置情報のいずれかの情報を少なくとも含んでいる
   請求項６に記載の情報処理装置。
8. 前記所望の情報は、他のユーザに関する情報であり、
   前記確信度は、前記所望の情報の対象者に応じて変動する
   請求項１に記載の情報処理装置。
9. 前記確信度は、前記対象者が前記他のユーザである場合に、前記対象者が前記ユーザである場合と比べて低くなる
   請求項８に記載の情報処理装置。
10. 前記応答は、前記ユーザの意図に応じたAPI(Application Programming Interface)に対し、その引数として、前記所望の情報から得られる値を渡して実行することで得られる
    請求項１に記載の情報処理装置。
11. 情報処理装置の情報処理方法において、
    前記情報処理装置が、
    ユーザの所望の情報に対して推定される前記ユーザ自身の確信度に応じて、前記所望の情報に対する応答の情報量を調整する
    ステップを含む情報処理方法。

Images