JP7432960B2 - 対話システムおよびプログラム - Google Patents

Description

この発明は、対話システムおよびプログラムに関し、特にたとえば、対話場所において少なくとも１体のエージェントが少なくとも１人の人と対話する、対話システムおよびプログラムに関する。

ロボット分野の広がりとともに、ロボット研究は日常的な場面で働くロボットの研究に焦点を移しつつあり、人間が生活する環境の中で、人と対話することができるロボットの開発が注目されている。

近年の音声認識の技術の発展により、これまでにも人間と音声言語でやりとりをする機能を持つロボットが開発されてきているが、音声認識技術をいくら優れたものにしても、ロボットと人との対話において、人が人との対話に参加しているときに抱く「対話感（対話に参加しているという感覚）」と同等の感覚を、ロボットと対話する人に与え続けることは容易ではなかった。つまり、人が明らかに対話感を喪失することがあった。

背景技術の一例である特許文献１には、ロボットと人との対話において、ロボットが人の感情を推測して応答文の発話とその発話に伴う動作を決定することが開示されている。

特許文献２には、人とロボットとの対話システムにおいて、両者の同調を図ることで、持続的で自然なインタラクションを実現しようとするものである。

特開2004-90109号公報[B25J 13/00…] 特開2012-181697号公報[G06F 3/16…]

特許文献１の技術においても、特許文献２の技術においても、音声認識に基づく処理に限界があり、上述の「対話感」を人が持続することは容易ではない。つまり、対話の破綻を招来し易い。

それゆえに、この発明の主たる目的は、新規な、対話システムおよびプログラムを提供することである。

この発明の他の目的は、人との対話の破綻を可及的回避できる、対話システムおよびプログラムを提供することである。

この発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、この発明の理解を助けるために記述する実施形態との対応関係を示したものであって、この発明を何ら限定するものではない。

第１の実施例は、対話場所にある少なくとも１体のエージェントを備え、対話場所においてエージェントが、ダイアログに従って、人と対話する対話システムであって、エージェントに質問文を発話させる質問文発話部、質問文に対する人からの応答文の発話の有無を判断する第１判断部、第１判断部が、応答文が発話されたことを判断しなかったとき、エージェントに、質問文に対して人にかわって応答するための代理応答文を発話させる、代理応答文発話部、および代理応答文発話部による代理応答文の発話に続いて、代理応答文に関し対話の脈絡を作る認識応答文を発話させる認識応答文発話部を備える、対話システムである。

第１の実施例では、対話システム（１０：実施例において相当する部分を例示する、限定を意図しない参照符号。以下、同様。）は、対話場所（１２）にある少なくとも１体のエージェント（Ｒ１、Ｒ２）を備え、対話場所においてエージェントがダイアログに従って人（Ｈ）と対話する。質問発話部（２０ａ、Ｓ７）は、エージェントに質問文を発話させる。人（Ｈ）はその質問文に対して応答文を発話するが、第１判断部（２０ａ、Ｓ９）が、その質問文に対する人からの応答文の発話の有無を判断する。第１判断部（２０ａ、Ｓ９）が、応答文が発話されたことを判断しなかったとき、代理応答文発話部（２０ａ、Ｓ２７）によって、エージェントに、質問文に対して人にかわって応答するための代理応答文を発話させ、さらに認識応答文発話部（２０ａ、Ｓ２９）が、代理応答文発話部による代理応答文の発話に続いて、代理応答文に関し対話の脈絡を作る認識応答文を発話させる。

第１の実施例によれば、応答文が発話されなくても、代理応答発話や認識応答発話を行わせることによって、対話の破綻を可及的回避できる。

第２の実施例は、対話場所にある少なくとも１体のエージェントを備え、対話場所においてエージェントが、ダイアログに従って、人と対話する対話システムのコンピュータを、エージェントに質問文を発話させる質問文発話部、質問文に対する人からの応答文の発話の有無を判断する第１判断部、第１判断部が、応答文が発話されたことを判断しなかったとき、エージェントに、質問文に対して人にかわって応答するための代理応答文を発話させる、代理応答文発話部、および代理応答文発話部による代理応答文の発話に続いて、代理応答文に関し対話の脈絡を作る認識応答文を発話させる認識応答文発話部として機能させる、対話システムのプログラムである。

第２の実施例によれば、第１の実施例と同様の効果が期待できる。

この発明によれば、エージェントと人の対話の破綻を可及的回避することができる。

この発明の上述の目的、その他の目的、特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。

図１はこの発明の一実施例の対話システムの概要を示す概略図である。 図２は図１実施例におけるセンサマネージャの構成の一例を示すブロック図である。 図３は図１実施例におけるグループマネージャの構成の一例を示すブロック図である。 図４は図１実施例におけるロボットの一例を示す概略図である。 図５は図４のロボットを制御するロボットコントローラの構成の一例を示すブロック図である。 図６は図１に示すグループマネージャの動作の一例を示すフロー図である。

図１を参照して、この実施例の対話システム１０の対話場所１２には、第１ロボットＲ１および第２ロボットＲ２と１人の人Ｈが存在する。ただし、ロボットの数は１体でもよく、３体以上でもよい。また、人の数は２人以上でもよい。なお、以下において、第１ロボットＲ１および第２ロボットＲ２を特に区別する必要がないとき、単にロボットＲと呼ぶことがある。

この実施例の対話システム１０は、図１の矢印Ａで示すように、ロボットＲ１またはＲ２が予め準備したダイアログ（台本）に従って人Ｈに対して質問文を発話させ、その質問文に対して人Ｈからの応答発話が適切な場合や、その質問文に対して人Ｈからの応答発話がない場合など、矢印Ｂで示すようにロボットＲ１またはＲ２が質問文を発話したロボットＲ１またはＲ２に対してダイアログに従って事前フレーズ発話や代理応答発話などを行わせる。

人Ｈに対してロボットＲ１またはＲ２が質問文を発話しても、人Ｈから応答発話がなかったり、あるいは応答発話があったとしても、たとえば「わからない」、「知らない」、「忘れた」、「覚えていない」または「答えたくない」などのネガティブな発話であったりした場合、人ＨとロボットＲ１またはＲ２が対話を続けていくこと自体が困難になりやすい。つまり、ロボットＲ１またはＲ２に応じる形で人Ｈの発話が生成されなければ、対話は破綻しやすい。そこで、この実施例では、人Ｈから適切な応答発話がない場合には、人Ｈに対して質問文を発話したロボットＲ１またはＲ２に対して、ロボットＲ１またはＲ２（質問発話をしたロボットと同じであってもよいし、別のロボットであってもよい）に発話をさせることによって、対話の継続を可及的可能にする。

他方で、人Ｈから適切な応答発話がある場合には、人Ｈに対して質問文を発話したロボットＲ１またはＲ２に対して、ロボットＲ１またはＲ２（質問発話をしたロボットと同じであってもよいし、別のロボットであってもよい）に事前フレーズを発話させることによって、そのメイントピックでの対話の継続を助長する。つまり、人Ｈに対して質問を続けることによって、ロボットＲ側からするとロボットＲの、人Ｈと経験を共有したいという欲求を表現して、人Ｈに対話感を提供する。

この実施例のような対話システムは、たとえば、高齢者の発話を引き出すツールなどとして、利用可能である。

対話システム１０の対話場所１２には、この実施例では、聴覚センサとしてのマイク１４および視覚センサとしてのカメラ１６が設けられる。マイク１４は、ロボットＲや人Ｈの発話による音声を聴取し、あるいは環境音を取得するためのもので、必要ならマイクアレイであってよい。カメラ１６は、同じく対話場所１２の状況、特に人Ｈの表情や動作を撮影するカメラであり、動画または静止画を撮影する。カメラ１６も必要なら２台以上設置してもよい。

さらに、上述のマイク１４やカメラ１６の他に、センサとして、図示はしないが、装着型の姿勢センサ、加速度センサ、心拍の状態、呼吸の状態、体動（体の動き）の状態などの生体信号を検知する生体センサ、モーションキャプチャシステムなどを設けてもよい。

マイク１４が取得した音声信号およびカメラ１６が撮影した画像信号などのセンサ信号は、センサマネージャ１８に入力される。センサマネージャ１８は、これらのセンサ信号を取得して、対話場所１２の状況を判定して、判定結果をセンシングデータとして、グループマネージャ２０に出力する。

図２を参照して、センサマネージャ１８は、ＣＰＵ（中央演算処理装置）１８aを含み、ＣＰＵ１８ａには、内部バス１８ｂを介して通信装置１８ｃが接続される。通信装置１８ｃは、たとえばネットワークインターフェースコントローラ（ＮＩＣ）などを含み、ＣＰＵ１８ａはこの通信装置１８ｃを介してグループマネージャ２０などと通信でき、それらの間でデータの授受を行うことができる。

ＣＰＵ１８ａにはさらに、内部バス１８ｂを介して、メモリ１８ｄが接続される。メモリ１８ｄはＲＯＭやＲＡＭを含む。たとえばＤＳＰ（Digital Signal Processor）で構成されるセンサＩ／Ｆ（インタフェース）１８ｅを通して、マイク１４（図１）からの音声信号やカメラ１６（図１）からの画像信号を含むセンサ信号が入力される。そして、メモリ１８ｄは、センサ信号を一時的に記憶する。

センサマネージャ１８は一種の判定器であり、ＣＰＵ１８ａは、メモリ１８ｄに記憶したセンサデータに基づいて、対話場所１２の状態を判定する。そして、センサマネージャ１８は、判定した状態を示すデータをグループマネージャ２０に送る。

また、センサマネージャ１８に必要なプログラム（ＯＳやセンサ信号取得プログラムなど）は、メモリ１８ｄに記憶される。センサマネージャ１８はメモリ１８ｄに記憶されたプログラムに従って動作する。

なお、ＣＰＵ１８ａにはさらに、図示しないが、キーボードやディスプレイが付属されてもよい。

グループマネージャ２０は、たとえば後述の図６のフロー図に従って、２体のロボットＲ１およびＲ２のそれぞれの発話動作（言語動作：Verbal operation）および振舞い（非言語動作：Nonverbal operation）を制御する。

グループマネージャ２０は、ＣＰＵ２０aを含み、ＣＰＵ２０ａには、内部バス２０ｂを介して通信装置２０ｃが接続される。通信装置２０ｃは、たとえばネットワークインターフェースコントローラ（ＮＩＣ）などを含み、ＣＰＵ２０ａはこの通信装置２０ｃを介してセンサマネージャ１８やロボットＲなどと通信でき、それらの間でデータの授受を行うことができる。

ＣＰＵ２０ａにはさらに、内部バス２０ｂを介して、メモリ２０ｄが接続される。メモリ２０ｄはＲＯＭやＲＡＭを含む。メモリＩ／Ｆ２０ｅを通してダイアログ（Dialog：対話）データベース２２から、スクリプトデータを読み込み、それをメモリ２０ｄに一時的に記憶する。

また、グループマネージャ２０に必要なプログラム（ＯＳやセンサ信号取得プログラムなど）は、メモリ２０ｄに記憶される。グループマネージャ２０はメモリ２０ｄに記憶されたプログラムに従って動作する。

なお、このグループマネージャ２０のＣＰＵ２０ａは、上述のように、各ロボットの動作つまり振舞いを制御するが、その振舞いの履歴は、上述のメモリ２０ｄに蓄積され、必要に応じて、センサマネージャ１８に提供する。

ＣＰＵ２０ａにはさらに、内部バス２０ｂを介して、メモリ２０ｄおよび入力装置２０ｅが接続される。メモリ２０ｄはＲＯＭやＲＡＭを含む。メモリＩ／Ｆ２０ｆを通してダイアログデータベース２２から、スクリプト（ダイアログ）を読み込み、それをメモリ２０ｄに一時的に記憶する。

ただし、「ダイアログ」は、対話中に行うべき発話や非言語動作の指令の系列を意味し、ダイアログデータベース２２は、ダイアログの集合（たとえば、子供のころの話、旅行の話、健康の話など、各メイントピックの対話のための指令の系列が含まれる）である。そして、「スクリプト」は、その指令の系列を表す文字列のことであり、スクリプトデータは、その指令を表す文字列である。したがって、スクリプトデータの系列がスクリプトになる。このようなスクリプトは、グループマネージャ２０によって、ダイアログキュー２３ｃからロボットＲ１およびＲ２に送信される。

ただし、スクリプトデータは、言語データだけでなく、非言語データも含む。言語データは、ロボットＲ１およびＲ２の発話を指示するスクリプトデータであり、非言語データは、たとえばロボットＲ１およびＲ２の動作、人Ｈを見る、頷く、首を横に振る、首をかしげるなどの、非言語動作を指示するスクリプトデータである。

また、グループマネージャ２０に必要なプログラム（ＯＳやセンサ信号取得プログラムなど）は、メモリ２０ｄに記憶される。グループマネージャ２０はメモリ２０ｄに記憶されたプログラムに従って動作する。

なお、このグループマネージャ２０のＣＰＵ２０ａは、上述のように、各ロボットの動作つまり振舞いを制御するが、その振舞いの履歴は、上述のメモリ２０ｄに蓄積され、必要に応じて、センサマネージャ１８に提供する。

さらに、図１に示す対話システム１０は、次ダイアログ候補プール２３ａを備える。次ダイアログ候補プール２３ａは、ダイアログキュー２３ｃに記憶されている現在進行中のスクリプトに対する人Ｈの応答に応じて動的に選択される候補となる次に発話すべき一群のスクリプトを記憶しておくための記憶領域であって、特に、人Ｈからの応答文の発話の有無、応答文に含まれるキーワードが予め設定している特定のキーワードに対してヒットしたかどうか、などに応じて、個別に準備しておく。

不応答ダイアログプール２３ｂは、たとえばロボットＲ１が発話した質問文に対して人Ｈからの応答文の発話がないとき（マイク１４への応答文の音声入力がないときだけでなく、音声入力がマイク１４にあった場合でも、その応答文が認識できなかった場合、認識できたとしてもその応答文がネガティブな発話のものである場合なども含む。）にロボットＲ１および／またはＲ２が発話すべきダイアログがプールしている。すなわち、不応答ダイアログプール２３ｂは、次ダイアログ候補プール２３ａにロードした将来の一群のダイアログやダイアログキュー２３ｃにロードされ、進行中であるダイアログでは予定していなかった例外的な場合に対処するために発話しまたは非言語動作を実行すべき一群のスクリプトを記憶しておくための記憶領域である。

ダイアログキュー２３ｃもたとえばメモリ２０ｄの中の一領域であるが、このダイアログキュー２３ｃには、次ダイアログ候補プール２３ａにロードされているスクリプトデータや、不応答ダイアログプール２３ｂにロードされているスクリプトデータを、次にロボットＲ１および／またはＲ２が即座に実行できるように，待ち行列の形でロードすることができる。

スクリプトには、たとえばヘッダとして、それに含まれるスクリプトデータの実行時間（tnext）が書き込まれていて、ダイアログキュー２３ｃでは、その実行時間（tnext）によって常にスクリプトデータがソーティングされ、グループマネージャ２０は、実行時間が同じスクリプトデータが同時に実行されるように、各ロボットコントローラ２４にスクリプトデータを送る。したがって、たとえば、ロボットＲ１およびＲ２が同時に同じ動作、たとえば人Ｈを見るなどの動作ができるし、同じロボットＲ１またはＲ２が、たとえば、発話と同時に他方のロボットまたは人Ｈを見ることもできる。

ここで、この実施例におけるダイアログは、メイントピックないしメインカテゴリと、各メイントピックないしメインカテゴリの中のいくつかのサブトピックないしサブカテゴリで構成される。この実施例では、人Ｈとの対話の深度を深くすることができるように、たとえば子供のころの話、旅行の話、健康の話など、比較的少ないメイントピック（ないしカテゴリ）のダイアログを準備する。

子供のころの話、というメイントピック（大トピック）の中には、たとえば、遊び、食事、生活・住まい、などのサブトピック（中トピック）を設定する。サブトピック「遊び」には、たとえば、場所、公園、おもちゃ、かくれんぼ、ままごと、鬼ごっこ、かけっこ、だるまさんがころんだ、などのサブトピック（小トピック）を設定する。サブトピック「食事」には、たとえば、給食、おやつ、おかず、玄米、好きなもの、嫌いなもの、牛乳、ケーキ、魚と肉、ごはんとパン、カレーと寿司、などのサブトピックを設定する。サブトピック「生活・住まい」には、たとえば、住んでいたところ、家、井戸、お父さんとお母さん、兄弟姉妹、仕事、鶏、牛、馬、犬と猫、楽しかったこと、辛かったこと、などを設定する。

旅行の話、というメイントピックの中には、たとえば、温泉、富士山、移動手段（飛行機、新幹線）などのサブトピックを設定し、それぞれのサブトピックにはさらに細かいサブトピックを準備しておく。

健康の話、というメイントピックの中には、たとえば、運動、ゴルフ、などのサブトピックを設定し、それぞれのサブトピックにはさらに細かいサブトピックを準備しておく。

図４を参照して、この図４は実施例のロボットＲの外観を示し、ロボットＲは台３０上に、台３０に対して、前後左右に回転できるように、設けられる。つまり、胴体３２には２自由度が設定されている。

胴体３２の人の肩に相当する左右位置からは、それぞれに、肩関節（図示せず）によって、右腕３４Ｒおよび左腕３４Ｌが、前後左右に回転可能に設けられる。つまり、右腕３４Ｒおよび左腕３４Ｌには、それぞれ、２自由度が設定されている。

胴体３２の上端中央部には首３６が設けられ、さらにその上には頭部３８が設けられる。首３６すなわち頭部３８は、胴体３２に対して、前後左右に回転できるように、取り付けられている。つまり、首３６すなわち頭部３８には、ロール角（左右の傾げ）、ピッチ角（前後の傾げ）、ヨー（左右の回転）３自由度が設定されている。

頭部３８の前面すなわち人間の顔に相当する面には、右目４０Ｒおよび左目４０Ｌが設けられ、右目４０Ｒおよび左目４０Ｌには眼球４２Ｒおよび４２Ｌが設けられる。右目４０Ｒおよび左目４０Ｌは、まぶたを閉じたり開いたりでき、眼球４２Ｒおよび４２Ｌはそれぞれ上下左右に回転可能である。つまり、右目４０Ｒおよび左目４０Ｌすなわちまぶたには１自由度が、眼球４２Ｒおよび４２Ｌには２自由度が設定されている。

顔にはさらに、口４４が設けられていて、口４４は、閉じたり開いたりできる。つまり、口４４には１自由度が設定されている。

胴体３２の、人間の胸の位置には、対話システム１０において人Ｈに聞かせるための発話を行うスピーカ４６および環境特に人Ｈの発話音声を聞き取るマイク４８が設けられる。

なお、頭部３８の顔の額に相当する部分には動画または静止画を撮影できるカメラ５０が内蔵される。このカメラ５０は、対面する人Ｈを撮影でき、このカメラ５０からのカメラ信号（映像信号）は、環境カメラ１６（図１）と同様に、センサマネージャ１８のセンサＩ／Ｆを介してＣＰＵ２２ａに、入力されてもよい。

図５はロボットＲに内蔵されてロボットＲの動作（発話やジェスチャなど）を制御するロボットコントローラ２４を示すブロック図である。この図５を参照して、ロボットコントローラ２４は、ＣＰＵ２０ａを含み、ＣＰＵ２０ａには、内部バス２４ｂを介して通信装置２４ｃが接続される。通信装置２４ｃは、たとえばネットワークインターフェースコントローラ（ＮＩＣ）などを含み、ＣＰＵ２０ａはこの通信装置２４ｃを介してセンサマネージャ１８、グループマネージャ２０、さらには外部のコンピュータや他のロボット（ともに図示せず）などと通信でき、それらの間でデータの授受を行うことができる。

ＣＰＵ２０ａにはさらに、内部バス２４ｂを介して、メモリ２４ｄが接続される。メモリ２４ｄはＲＯＭやＲＡＭを含む。グループマネージャ２０から送られる制御データやスクリプトデータがメモリ２４ｄに一時的に記憶される。

また、ロボット制御に必要なプログラム（ＯＳやセンサ信号取得プログラムなど）は、メモリ２４ｄに記憶される。ロボットコントローラ２４はメモリ２４ｄに記憶されたプログラムに従ってロボットＲの動作を制御する。

つまり、ロボットコントローラ２４のＣＰＵ２０ａにはさらに、たとえばＤＳＰで構成されたアクチュエータ制御ボード２４ｅが接続され、このアクチュエータ制御ボード２４ｅは、以下に説明するように、ロボットＲの上述の各部に設けられたアクチュエータの動作を制御する。

胴体３２の２自由度の動き、すなわち前後左右の回転は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａが胴体アクチュエータ５２を制御するとこによって制御される。

右腕３４Ｒおよび左腕３４Ｌの２自由度の動き、すなわち前後左右の回転は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａが腕アクチュエータ５４を制御することによって制御される。

首３６すなわち頭部３８の３自由度の動き、すなわち前後左右の回転は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａが頭部アクチュエータ５６によって制御される。

右目４０Ｒおよび左目４０Ｌすなわちまぶたの開閉動作は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａがまぶたアクチュエータ５８を制御することによって制御される。眼球４２Ｒおよび眼球４２Ｌの２自由度の動きすなわち前後左右の回転は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａが眼球アクチュエータ６０を制御することによって制御される。口４４の開閉動作は、アクチュエータ制御ボード２４ｅを通してＣＰＵ２０ａが口アクチュエータ６２を制御することによって制御される。

なお、図４に示すロボットＲのスピーカ４６がロボットコントローラ２４のＣＰＵ２４ａに接続される。ＣＰＵ２４ａは、グループマネージャ２０から与えられ、必要に応じてメモリ２４ｄに記憶されたスクリプトデータに従って、スピーカ４６から発声（発話）させる。

このようなロボットコントローラ２４によって、ロボットＲの頭や腕は、対話システム１０において必要なとき、たとえばスクリプトで非言語動作が要求されているとき、必要な動きをするが、以下の説明では、各アクチュエータなどの具体的な制御は、上述の説明から容易に推測できるので、必ずしも説明しない。

図１に示すように、それぞれのロボットＲ１およびＲ２には、ロボットコントローラ２４と同様に内蔵したロボットセンサ２６が設けられる。ロボットセンサ２６は、ロボットＲ１およびＲ２のそれぞれの可動コンポーネントの状態を検知するための姿勢センサや加速度センサなどを含み、それらのセンサからのセンサ信号は、センサマネージャ１８に入力される。したがって、センサマネージャ１８は、ロボットセンサ２６からのセンサ信号に基づいて、ロボットＲ１およびＲ２の状態をセンシングすることができる。

なお、図４に示すロボットＲのマイク４８やカメラ５０がロボットセンサ２６を介してセンサマネージャ１８に入力される。センサマネージャ１８は、マイク４８から取り込んだ音声データをメモリ１８ｄ（図２）に記憶し、必要に応じて、音声認識処理を実行する。センサマネージャ１８はまた、カメラ５０からのカメラ信号を処理して、対話場所１２の状況をセンシングする。

なお、センサマネージャ１８は、図１の実施例では１つだけが図示されているが、２つ以上の任意数のセンサマネージャが設けられてもよく、その場合には、各センサマネージャはセンシング項目を分担することができる。

同様に、必要なら、２以上のグループマネージャ２０を用いるようにしてもよいし、逆にセンサマネージャ１８およびグループマネージャ２０を１台のコンピュータで実現するようにしてもよい。

また、図１実施例の対話システム１０に用いられるロボットＲは図４を参照して上で説明したロボットに限定されるものではなく、少なくともスクリプトに従って発話できる機能があればよい。

図６を参照して、図１の対話システム１０のグループマネージャ２０のＣＰＵ２０ａは、ダイアログデータベース２６（図１）からたとえば先に説明したようなダイアログデータ（スクリプトデータ）を読み込むなど、初期化を実行する。この図６の動作は、たとえばフレームレート程度の速度で繰り返し実行される。

次のステップＳ３でＣＰＵ２０ａは、ダイアログのメイントピック（大トピック）を変更するかどうか判断する。メイントピックを変更するかどうかは、タイムスケジュールに従って変更する場合、所定時間経過したかどうか、などを判断することによって、このステップＳ３で決定される。なお、以下の実施例の具体的な説明では、メイントピック「旅行の話」のダイアログに従う場合を例に挙げて説明する。

なお、ステップＳ３で判断するメイントピックを変更する条件としては、他に、前回のメイントピックの変更から所定数Ｎ回（これは、同じメイントピックの話が続きすぎることによって、対話が退屈になるのを避けるために設定する、同一メイントピックの繰り返し回数の最大値である。）以上経過したとき、人Ｈからの応答発話が今対話中のメイントピックとは別のメイントピックのキーワードにヒットしたとき、人Ｈからの応答発話が所定回数認識できなかったとき、などが考えられる。

ステップＳ３で“ＮＯ”を判断したときはそのまま、“ＹＥＳ”を判断したときはステップＳ５でメイントピックを変更して、次ダイアログ候補プール２３ａから読み出したスクリプトに従って、たとえばロボットＲ１が、人Ｈに対して、たとえば「休みの日にはどこへ行きたいですか？」のような質問文を発話する。ここで、「どこへ行く」というのが、「旅行の話」というメイントピックのサブトピックと考えることができる。このステップＳ７を実行するＣＰＵ２０ａは、質問文発話部として機能する。

ステップＳ９において、ＣＰＵ２０ａは、ステップＳ７でたとえばロボットＲ１が発話した質問文に対して人Ｈからの応答発話があったかどうか、センサマネージャ１６で検出したマイク１４からの音声データに基づいて、判断する。このステップＳ９を実行するＣＰＵ２０ａは、人からの応答発話の有無を判断する第１判断部として機能する。

応答発話があったと判断したとき、ＣＰＵ２０ａは、次のステップＳ１１では、ステップＳ９で検出した人Ｈからの応答発話が認識できたかどうか、すなわち、その応答発話がたとえばダイアログデータベース２２に予め設定しているキーワードにヒットしたかどうか、判断する。つまり、人Ｈの応答文の中に予め設定しているキーワードが含まれているかどうか、判断する。これは、マイク１４からの音声データを任意の音声認識技術を利用して処理することによって、簡単に実行することができる。

ただし、キーワードがヒットした場合であっても、人Ｈの応答文が複数のキーワードに同時にヒットしている場合には、このステップＳ１１では“ＮＯ”と判断するようにしている。どのキーワードで対話を進めていくべきか判断しにくいためである。このステップＳ１１（次のステップＳ１３を含むことがある）を実行するＣＰＵ２０ａは、人からの応答文がキーワードにヒットしたかどうかを判断する第２判断部として機能する。

ステップＳ１３でＣＰＵ２０ａは、ステップＳ１１で検出したキーワードがネガティブな発言であるかどうか、判断する。ネガティブな発言とは、前述したとおり、質問文に対して回答を拒否しているかのような発言のことである。

ステップＳ１３で“ＮＯ”を判断したとき、次のステップＳ１５で、そのキーワードは現在対話中のメイントピックの中に定められているキーワードか、別のメイントピックの中に設定されているキーワードかを判断する。

もし、このステップＳ１５で“ＹＥＳ”を判断したら、ステップＳ３に関連して説明したように、人Ｈからの応答発話が今対話中のメイントピックとは別のメイントピックのキーワードに及んだとき、という条件を充足することになるので、ステップＳ５に戻って、メイントピックの変更処理を実行した後、再度ステップＳ７に進む。

ステップＳ１１でキーワードがヒットしたことを判断しかつステップＳ１５でそのキーワードが現在進行中のメイントピックのものであると判断したとき、続くステップＳ１７で、ＣＰＵ２０ａは、質問文を発話したロボット、この例ではロボットＲ１と別のロボット、ロボット２に、たとえば「やっぱり梅田かな」という事前フレーズを発話させる。ここで、事前フレーズとは、次のロボットＲ１（またはロボットＲ２）の発話を誘導する意味の発話文である。ただし、検出されたキーワードの発話を人Ｈが実際に意図していたら、そのときには、ロボットＲ２が発話した事前フレーズは単に傾聴感（ロボットＲが人Ｈの発話を傾聴しているという感覚）に貢献するに過ぎないが、人Ｈが意図していない事前フレーズであった場合、続くロボットＲ１からの返答の脈絡を作る効果がある。

つまり、事前フレーズは、いわば「話の振り」（対話や議論などが円滑に進行するように、話題を提供することを意味する語）の役目をする。この実施例では、ロボットＲ２がそのキーワード（この例では「梅田」）で話を振ったので、ロボットＲ１がそれを受け継いで、たとえば「梅田は便利だもんね」という発話をし、それによって人Ｈに、梅田の話になったことについて違和感を与えない効果がある。

他に想定されている対話としては次の例１や例２などがある。
＜例１＞
ロボットＲ１：休みの日にはどこにいきたいですか？（ステップＳ７）
人Ｈ：一番は梅田かな（「梅田」と認識される）（ステップＳ１１）
ロボットＲ２：やっぱり梅田かな（ステップＳ１７）
ロボットＲ１：梅田は便利だもんね（ステップＳ１９）
＜例２＞
ロボットＲ１：休みの日にはどこにいきたいですか？（ステップＳ７）
人Ｈ：青梅だな（「お、梅田な」と認識される）（ステップＳ１１）
ロボットＲ２：やっぱり梅田かな（ステップＳ１７）
ロボットＲ１：梅田は便利だもんね（ステップＳ１９）
このように、ロボットＲ２による「やっぱり梅田かな」という事前フレーズの発話は、次のステップＳ１９において発話されるロボットＲ１の返答の脈絡になる。

ここで、ステップＳ１７では、ステップＳ７で質問文を発話したロボットＲ１とは違うロボットＲ２に事前フレーズを発話させるようにし、さらにステップＳ１９でそれに続く認識応答発話（ロボットＲ２による事前フレーズを認識した上での発話）を別のロボットＲ１に発話させるようにした。つまり、２体のロボットＲ１およびＲ２に交互に、質問文、事前フレーズ、認識応答発話を行わせたが、順番は逆でもよい。さらには、質問文、事前フレーズ、認識応答発話を全て同じロボットＲ１またはＲ２に発話させるようにしてもよい。あるいは、図示しいてない、さらに他のロボット（Ｒ３）にステップＳ１９の認識応答発話を行わせるようにしてもよい。

なお、ステップＳ１７でたとえば「エキスポランド」という事前フレーズをロボットＲ２に発話させたときには、ステップＳ１９でたとえば「エキスポは人気だね」という認識応答発話をロボットＲ１（またはＲ３）にさせるようなダイアログも考えられる。

また、ステップＳ１７でたとえば「そうだ、北海道があった」という事前フレーズをロボットＲ２に発話させたときには、ステップＳ１９でたとえば「北海道はカニがおすすめです」という認識応答発話をロボットＲ１（またはＲ３）にさせるようなダイアログも考えられる。

このような事前フレーズに含まれる「梅田」、「エキスポランド」または「北海道」などは、「旅行の話」というメイントピックの「どこへ行くか」というサブトピックのさらにサブトピックであると考えられる。

なお、ステップＳ１７を実行するＣＰＵ２０ａは、事前フレーズ発話部として機能する。

ステップＳ１９でロボットＲ２に認識応答発話をさせた後、ＣＰＵ２０ａは、次のステップＳ２１で、対話を終了するかどうか、判断する。ここでは、たとえば、対話の開始から一定時間（たとえば１５分）経過したこと、カメラ１６（図１）の映像によると人Ｈが不在になったこと、などの対話を終了する条件を判断する。

終了する場合は、ステップＳ２３で終了処理をした後、終了する。終了処理は、たとえば対話のログを保存するなどの処理を含む。

終了しない場合には、先のステップＳ３に戻る。

先のステップＳ９で“ＮＯ”の場合、すなわちマイク１４を通して人Ｈの返答発話を取得できなかった場合、ＣＰＵ２０ａは、不応答ダイアログプール２３ｂから、次のステップＳ２３で現在進行中のメイントピックの中でキーワードをランダムに選択する。そして、ステップＳ２５で、質問文を発話したロボットＲ１とは異なるロボットＲ２によって、その選択したキーワードに従った代理応答文（たとえば、「僕は、やっぱり梅田かな」）を発話させる。ここでは、先のステップＳ１７の事前フレーズとは異なり、たとえば「僕は」という発話主体を表す語を発話させることによって、ロボットＲ２の主体的な代理応答文であることをはっきりさせる。このステップＳ２５（ステップＳ２３を含むことがある。）を実行するＣＰＵ２０ａは、代理応答文発話部部として機能する。

その後、ステップＳ２９で、ＣＰＵ２０ａは、先のステップＳ１９と同じような認識応答発話をロボットＲ１に行わせる。ただし、ステップＳ７、Ｓ２７およびＳ２９がすべて同じロボットＲ１またはＲ２であってもよいことは、先に述べたとおりである。

ステップＳ２７においてロボットＲ２に代理応答文を発話させることによって、人Ｈからの応答発話が無くても、取り敢えず対話が破綻することはなく、ステップＳ２９での認識応答発話によって、人Ｈの対話意欲の回復を期待することができる。たとえば、ステップＳ７での質問文に対して人Ｈが急には返答できない場合であっても、ステップＳ２７の代理応答文によってトリガされ人Ｈが応答文を着想する可能性がある。この場合、人Ｈは、そのときのメイントピックたとえば「旅行の話」について対話を継続することができる。その意味では、ステップＳ２７の代理応答文はステップＳ１７での事前フレーズと同様の効果（対話の脈絡を作る）を奏することができる。

なお、ステップＳ１３で“ＹＥＳ”を判断しステップＳ２５でキーワードを変更した回数が一定回数以上になったときステップＳ３、Ｓ５でメイントピックを変更するようにしてもよい。

ステップＳ２９の後、先のステップＳ２１に進んで、終了かどうか判断する。

ステップＳ１１で“ＮＯ”を判断したとき、ＣＰＵ２０ａは、ステップＳ３１において、不応答ダイアログプール２３ｂから選択した曖昧な応答文（たとえば、「とっか行きたいね」）をたとえばロボットＲ２に発話させる。この曖昧な応答は、ステップＳ２７で代理応答が「ロボットＲ２が人Ｈの代わりにロボットＲ１の質問に対して答える」という意味を持つのに対し、「ロボットＲ１やＲ２が人Ｈの発話に対して答える」という意味を持つ。つまり、ステップＳ９で人Ｈからの応答発話は検出したけれどもステップＳ１１でその応答発話文を認識することができなかったとき、そのままであれば対話が破綻することがあるが、曖昧な応答文をロボットに発話させることによって、人Ｈの次の発話を引き出すことができ、それによって対話の破綻を回避できる可能性が生まれる。

このステップＳ３１を実行するＣＰＵ２０ａは、曖昧応答文発話部として機能し、そして、ステップＳ３１の後、ステップＳ２１に進む。

なお、上述の説明ではメイントピックについては時間の経過や、人Ｈの発話や発話なしなどで変更できることを説明したが、サブトピックについては、次のような場合に変更することができる。

人Ｈの発話が、現在のサブトピックと同じサブトピック内に前の発話に関連度の高い未発話のダイアログ（シナリオ）がある場合、その関連度の高いサブトピックに移動する。たとえば、各シナリオに予め登録しておくキーワードと距離が近い語（言葉）が含まれているかどうか判定する。距離は、たとえばＷｏｒｄ２Ｖｅｃ等の手法を用いて評価する。ただし、そのような言葉が含まれていても、同様に他のキーワードと近い別の言葉が含まれていたら、それを割り引いて評価する。

ステップＳ１１でキーワードにヒットせず、ステップＳ３１へ進む回数が所定回数Ｎ以上になったときに、サブトピックを変更するようにしてもよい。

なお、上述の実施例では、各ロボットＲ１およびダイアログデータベース２２に予め蓄積しておくようにした。しかしながら、このデータベース２２に代えて、たとえばネットから、必要なダイアロク（スクリプトデータ）を逐次グループマネージャ２０に供給するようにしてもよい。

さらに、上述の実施例は、物理的なエージェントであるロボットを用いた対話システムであるが、この発明は、そのような物理的なエージェントだけでなく、たとえばディスプレイの画面上に表示されるアバタないしキャラクタのようなエージェントを用いることも可能である。この場合、図１のロボットコントローラ２４やロボットセンサ２６は、そのようなアバタやキャラクタを表示するためのディスプレイコントローラ（図示せず）に代えられ、対話場所はそのエージェントを表示しているディスプレイの近傍が想定できる。

さらに、上述のロボットによるエージェントやＣＧによるエージェントに代えて、音声だけのエージェントも人との対話のためのエージェントとして採用することができる。たとえば、カーナビのスピーカが車両の左右についているとして、その左側から聞こえてくる声の主をＲ１（実施例のロボットＲ１に相当する。）とし、右側の声の主をＲ２（実施例のロボットＲ２に相当する。）とすることが考えられる。この場合、対話場所は車の中ということになり、図１のロボットコントローラ２４は、そのような音声エージェントの発話を制御するオーディオコントローラ（図示せず）に代えられる。

つまり、この発明は、任意のエージェントを用いた人との対話システムである。

１０ …対話システム
１２ …対話場所
Ｒ１、Ｒ２ …ロボット
１８ …センサマネージャ
２０ …グループマネージャ
２２ …ダイアログデータベース
２４ …ロボットコントローラ

Claims (2)

1. 対話場所にある少なくとも１体のエージェントを備え、前記対話場所において前記エージェントが、ダイアログに従って、人と対話する対話システムであって、
   前記エージェントに質問文を発話させる質問文発話部、
   前記質問文に対する前記人からの応答文の発話の有無を判断する第１判断部、
   前記第１判断部が、前記応答文が発話されたことを判断しなかったとき、前記エージェントに、前記質問文に対して前記人にかわって応答するための代理応答文を発話させる、代理応答文発話部、および
   前記代理応答文発話部による代理応答文の発話に続いて、前記代理応答文に関し対話の脈絡を作る認識応答文を発話させる認識応答文発話部を備える、対話システム。
2. 対話場所にある少なくとも１体のエージェントを備え、前記対話場所において前記エージェントが、ダイアログに従って、人と対話する対話システムのコンピュータを、
   前記エージェントに質問文を発話させる質問文発話部、
   前記質問文に対する前記人からの応答文の発話の有無を判断する第１判断部、
   前記第１判断部が、前記応答文が発話されたことを判断しなかったとき、前記エージェントに、前記質問文に対して前記人にかわって応答するための代理応答文を発話させる、代理応答文発話部、および
   前記代理応答文発話部による代理応答文の発話に続いて、前記代理応答文に関し対話の脈絡を作る認識応答文を発話させる認識応答文発話部として機能させる、対話システムのプログラム。

Images