JP7130201B2 - 装置及びプログラム等 - Google Patents

Description

本発明は、例えばコミュニケーション等を行う機能を備えた装置及びプログラム等に関するものである。

特許文献１には、対話式のコミュニケーションロボットに関する技術が開示されている。

特開２０１１－０００６８１号公報

しかし、従来のコミュニケーションロボットは十分な能力を備えていないという課題があった。そこで従来よりも優れた能力を有する装置及びプログラム等を提供することを目的とする。
本願の発明の目的はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果を得ることを目的とする構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「～できる」と記載した箇所を「～が課題である」と読み替えた課題が本明細書には開示されている。課題はそれぞれ独立したものとして記載しているものであり、この課題を解決するための構成についても単独で分割出願・補正等により権利取得する意思を有する。課題が明細書の記載から黙字的に把握されるものであっても、本出願人は本明細書に記載の構成の一部を補正または分割出願にて特許請求の範囲とする意思を有する。またこれら独立の課題を組み合わせた課題も開示されている。

（１）ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能とを備える装置であって、前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備えるとよい。
このようにすれば、ユーザーまたは他の機器の少なくともいずれか一方は、生成が制御された出力情報又はタイミングが制御された出力情報の少なくともいずれか一方を得ることができる。従来よりも優れた装置を提供できる。
装置はコミュニケーションのための前記出力情報の生成を制御として例えばコミュニケーションに応じた出力情報を生成するとよい。このようにすれば特にユーザー又は他の機器において装置とのコミュニケーションを図る際の利便性が高まる。コミュニケーションはどのような出力情報を出力して行うようにしてもよいが、特に過去のコミュニケーションの履歴情報を記憶しておき当該履歴情報にも基いて行うとよい。また異なる複数のユーザーまたは他の機器とのコミュニケーションの履歴情報に基いて行うとよい。特に出力情報の出力は１の出力手段から行うようにしてもよいが、異なる複数の出力手段から可能な構成とし、これらのうちいずれかの出力手段を選択して出力を行うようにするとよい。出力手段としては例えば音声出力手段、表示手段、通信手段等とするとよい。コミュニケーションは、音声や目視あるいはそれら以外の五感、例えば触感にうったえコミュニケーションを図る構成としてもよい。

「装置」は特に出力情報を音声出力をする機能を備えるとよい。このようにすれば、例えば音声を入力して動作するデバイスを制御できる。装置は、特にコミュニケーションするためのインターフェースを備え、コミュニケーションを実行するための判断手段を備えるとよい。
なお「装置」の構成の含まれる部分は複数の筺体で構成してもよいが、特に１つの筺体で構成するとよい。
また装置は、例えば、有線や無線を通じてネットワークにアクセスする機能を備えるシステムとするとよい。特に、例えば、スマートフォン、タブレット端末、スマートスピーカ、スマートカメラ等とするとよい。また、外観も限定されるものではないが、特に、いかにも他者とコミュニケーションをとるような装置とするとよい。特にロボットとするとよい。例えば人や動物を模したような、あるいは例えばそれら以外の擬人化した形態のロボットとすると特によい。

装置は、コミュニケーションするための入力側のインターフェースを備えるとよく、例えばキーボードのような入力装置、例えば文字を読み込んでデータ化する光学文字認識（ＯＣＲ：Optical character recognition）とのインターフェースでもよいが、入力側のインターフェースとして音声によるものを備えるとよい。音声によるものとしては、例えばマイクロフォンで電気信号に変換した音声信号に基づく音声データの取得する機能を備えるとよい。
出力側のインターフェースとして音声によるものを備えるとよく、例えばスピーカ装置、イヤフォン等がよい。出力側のインターフェースとして目視によるものを備えるとよく、例えば表示内容を変更可能なディスプレイを備えるとよく、例えば液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ（ＰＤＰ）、有機ELディスプレイ、ブラウン管等の表示装置を備えるとよい。また、例えば印刷物による出力を備えるとよい。また特に出力側のインターフェースとして実際に動きを発生するものを備えるとよい。実際に動きを発生するものとしてアクチュエータを備えるとよい。例えばモータ等を備えるとよい。特に装置は実際に動きを発生する部材を備えるロボットとするとよい。装置は特に出力情報の出力を、実際に動きを発生する部材の動きとして行なうとよい。特に、出力側のインターフェースとしては音声によるものと目視によるものと実際に動きを発生するものをいずれも備えるとよい。
「ユーザー」は例えば装置を扱える人であって、一人でもよいが、複数人とするとよい。
「他の装置」は上記の装置の具体的な１つと例えば外観、機能等が同じであっても異なるものであってもよい。他の装置は音声出力をする機能を備えてなくともよい。音声出力機能を備えるとよい。また他の装置は音声入力をする機能を備えてなくともよいが音声入力機能を備えるとよい。
他の機器は、ネットワークにアクセスできない機器としてもよいが、ネットワークにアクセスできる機器とするとよい。特にインターネットにアクセスできる機器とするとよい。
出力情報は出力手段からある出力をさせる構成とするとよい。「ある出力」は、例えば外部に対する報知である。明らかな「報知」という形態でなくともそれによって結果的に何かの変化があったことだけでも「報知」と解釈できる。「ある出力」は必ずしも報知することを目的としたものでなくともよい。例えばなんらかの情報を有する、あるいはなんらの情報も有さない音や光の出力がよく、例えば何か物理的な量の変化、物の移動等がよい。

（２）前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備えているとよい。

音声によってコミュニケーションを取る際に表示部に音声によるコミュニケーションとの関係で表示態様が変化させられるため、音声を目で見る表示に変更してコミュニケーションできることとなり、コミュニケーションを図る際の利便性が高まる。
「表示部」は、音声による前記コミュニケーションによって前記表示部での表示態様を変化させるように表示させるデバイスとするとよく、例えば液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ（ＰＤＰ）、有機ELディスプレイ、ブラウン管等のような表示装置がよい。特に表示部は装置に備えるとよい。
「音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる」は、ユーザー又は他の機器の音声を表示部に表示させてその態様を変化させる場合と、装置自身の音声も表示部に表示させてその態様を変化させる場合のいずれか一方のみとしてもよいが、特に両方を備えるとよく、このときどちらか片方だけ表示させても両方とも表示させてもよいが、片方だけ表示させる状態と両方を表示させる状態との双方を備え、切り替え可能な構成とするとよい。例えば、片方だけ表示させる例としては下記実施の形態１のロボット１で顔画面Ｓ１が表示されている場合の態様であり、両方とも表示させる例としては下記実施の形態１のロボット１でチャット画面Ｓ２が表示されている場合の態様である。
表示態様としては、例えば音声との関係で画面を様々に変化させることとするとよく、例えば、音声によって表示画面に表示されたオブジェクトが動くようなアニメーションを実行させるとよい。例えば、音声の出力に伴って画像を変動させたり、音声の変化によって画像に他の画像を重ねたりするとよい。また、例えば、音声データを文字データに変換して表示させたりするとよい。その文字データの表示は音声の変化に応じて刻々と変化させるとよい。
音声による前記コミュニケーションは、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。
また、表示部での表示態様を変化させる機能は、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。
以下（３）以降も同様に、装置からの出力を行なう構成については、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。

（３）前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話のみに基づく構成とするとことがよい。

ユーザーや他の機器からの発話に基づいて装置が表示部での表示態様を変化させることでユーザーや他の機器側では自身の発話が装置に認識されているかが目視でわかることとなり、コミュニケーションを図る際の利便性が高まる。また、異種のヒューマンインターフェースによる特殊なコミュニケーションとなって、新鮮でおもしろさを感じる。
発話は直接的にユーザー又は他の機器から行われてもよく、間接的に発話を例えば文字データ化したものを使用してもよい。また、発話をなんらかの対応する情報、例えば他の音や視覚化した模様等に変換し、それに基づいて表示部で表示態様を変化させるようにしてもよい。
（３）では「ユーザー又は他の機器の少なくともいずれか一方の発話に基づく」ものであるため、例えば装置自身は音声のコミュニケーション機能とするとよい。
前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく構成としては、例えば、音声認識機能により音声を文字列に変換して前記ユーザー又は前記他の機器の少なくともいずれか一方の発話内容を特定する構成を備えるとよい。

（４）前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行われるようにした。
コミュニケーションが一方的にならず、安定して意思疎通しながらコミュニケーションを図ることができる。「交互」とは、例えば基本的に装置側とユーザー又は他の機器側とのコミュニケーションが対話形式で進行するように構成とするとよく、片方だけが一方的に発話する構成でない構成とするとよい。

（５）前記表示態様は前記ユーザー又は前記他の機器の少なくともいずれか一方の発話が変換された文字情報でを備えるとよい。

このようにすれば、ユーザーや他の機器側では自身の発話がどのように装置に認識されているかが表示された文字情報から具体的にわかることとなり、正しくコミュニケーションができているかを表示された文字情報の内容から判断できる。また、発話した内容の目視での確認ができる。また、認識が誤っているならもう一度言ったり、他の表現で言い直したりして正しいコミュニケーションに導くことができる。
「文字情報」は、例えば日本語であれば、例えば通常の漢字、ひらがな、かたかな等のユーザー又は他の機器の発話に基づく文字であり、発話が文を構成している場合には、漢字、ひらがな、かたかな、外国語表記等の混じった文節を有する文であることがよい。外国語、例えば英語や中国語等で発話される場合には、それらの文字で表示されることがよい。
例えば、音声認識機能と音声出力機能とを備え、音声認識機能によって音声認識し文字情報に変換された前記ユーザー又は前記他の機器の少なくともいずれか一方の発話の内容を表示部に表示させ、その内容に基づく返答文字情報を生成し、当該返答文字情報を音声合成機能により音声情報に変換して、音声として出力させる機能を備えると特によい。

（６）前記発話が変換された文字は発話の開始から終了までの全内容が同時に前記表示部に表示されるようにするとよい。
ユーザーや他の機器からのある長さを持った発話全体が装置側に受け止められるため、その発話に対する装置からの正しいコミュニケーションが期待できる。また、自らが発話した内容の目視での確認が瞬時にできることとなり、以後のコミュニケーションの修正や方向性に寄与する。
発話の開始から終了は、人が一息で発話できる時間を加味して設定するとよい。発話の終了は、例えば、所定の時間、音声の発話がないとみなされる音の大きさが続いた時点とするとよい。発話の開始は例えば音の大きさが所定のレベルを越えたことを条件に開始するとよい。発話の開始は例えば音の大きさが所定のレベル以上のレベルの急激な変化が検出されたことを条件に開始するとよい。

（７）前記装置は、前記装置と前記ユーザー又は前記他の機器の少なくともいずれか一方の音声によるコミュニケーションの対話履歴を文字情報として前記表示部に表示させる機能を備えるとよい。

装置とユーザー又は他の機器との間でどのように対話がされたかが容易にわかり、音声によるコミュニケーションにおける利便性が高まる。
対話履歴の表示は、例えばどちらが対話したものかがわかるように表示させることがよい。そのためには、例えば吹き出しを設けていずれの発話に基づく文字情報かを区別することがよい。過去の対話については画面上でスクロールして確認できることがよい。対話形式であることを示すために装置側とユーザー又は他の機器側とで異なるアバターキャラクターを表示させるとよい。いつ発話したのかその日時が同時に表示されるとユーザーが対話履歴から過去を思い出す契機となるのでよい

（８）前記装置は、前記対話履歴を文字情報として表示させる際に、前記ユーザー又は前記他の機器の交替があり、前記装置の対話対象が代わった場合には前記表示部にその旨が表示させる機能を備えるとよい。

装置の対話対象が代われば対話内容にも変化がある。対話対象が代わった旨を表示させることで、例えば過去の対話履歴を見た際にその表示があることでその前後で対話内容が代わることが読み手にわかるため、対話内容の切れ目がわかることとなる。
装置は前記ユーザー又は前記他の機器の交代を検出する機能を備えるとよい。交代の検出は、音声の特徴の変化から検出する機能を備えるとよいが、カメラを用いて周囲の人または機器の状態を取得して検出する機能を備える構成が望ましく、特に両者に基づいて検出する構成とするとよい。

（９）前記装置は音声認識機能によって前記ユーザー又は前記他の機器の少なくともいずれか一方の音声の認識状況を前記装置の表示部に表示させる機能を備えるようにするとよい。

例えば、ユーザーや他の機器が発話している場合に、それを間違いなく聞いていることをユーザー等に理解させることで円滑に対話が行われていることをユーザー等に理解させることができる。
例えば、視覚を通じた機能として、表示部に音声認識の度合いに応じて、例えば表示画面や表示画面に表示されるオブジェクトの色を変えたり、例えば音声の認識状況応じて異なるオブジェクトを表示をさせたり、音声認識の度合いに応じて量的な表示、例えばよく認識していれば高い数値を示したりすることがよい。聴覚を通じた機能として、例えば音声認識の度合いに応じて音を大きくしたり小さくしたりすることがよく、例えば音色を変えたりすることがよい。
特に擬人化された態様での表示を表示部に行なうようにし、その表情を変化させる構成とするとよい。

（１０）音声を認識して文字列に変換した結果を用いて前記音声出力を行うことで前記コミュニケーションを行うための機能を備え、音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分がある場合に当該文字列に対応する出力内容を音声出力する機能を備えるようにするとよい。

音声を認識して変換した文字列が音声記憶手段に記憶された文字列と一致する部分がある場合に、装置内のみで必要な音声出力ができれば、ユーザーや他の機器からの発話に迅速に応じることができる。また、外部サーバーに接続しないため、接続のためのコストが削減できる。
例えば、記憶手段に記憶された文字列として多数のビルトインシナリオを用意することがよい。ビルトインシナリオは予定された対話であって例えば、ユーザーからの「おはよう」に対して装置側から「お元気ですか」と返答するような簡単な挨拶や、一定の処理を実行するための、例えば「設定画面を開いて」（ユーザー）、「本当にいいですか」（装置）、「はい」（ユーザー）、「じゃあ、設定画面を開くね」（装置）のようなシナリオ等がよい。記憶手段としては、例えばコンピュータ内部のＲＯＭやＳＳＤや外付けのＳＤカードmicroＳＤカード、ＣＤ－ＲＯＭ等がよい。

ここで「文字列と一致する部分がある場合」とは、完全に記憶された文字列と一致する場合と、ある部分が異なっていてもよい正規表現である場合である。正規表現とは文字列の集合を一つの文字列で表現する言語処理方法の一つであり、例えば「×××音量大きく××」という場合に「ユピ坊音量大きくしてよ」とか「おい音量大きくして」「音量大きくしてください」等のように異なる部分があっても要部が一致すれば解釈として「音量を大きく」する表現として認識するような場合である。そして、「当該文字列に対応する出力内容を音声出力する」とは、例えば、このような「音量を大きく」するという当該文字列に応じて「はい、音量を大きくします」というような音声出力がよい。また、このような音声出力に続いて装置はある処理をするようにしてもよい。例えば、「はい、音量を大きくします」という発話の後で装置は実際に以後の対話における自身の発話の音量を大きくすることがよい。
音声を認識して文字列に変換する処理は、装置で行なうようにしてもよいが、ネットワークに接続された音声認識サーバーに対して音声データを送信し、音声認識サーバーで変換された文字列を受信するようにして行なうようにしてもよい。望ましくは両者を備えるとよく、コミュニケーションの状況等に応じていずれの結果を用いるかを決定する機能を備えるとよい。

（１１）音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分がない場合に、対話エンジンを備えるサーバーに接続して音声データを出力する機能を備えるとよい。

音声を認識して変換した文字列が音声記憶手段に記憶された文字列と一致する部分がない場合に、対話エンジンを備えるサーバーに接続するため、接続のためのコストが削減できる。
サーバーは、例えばインターネット回線を使用して接続する記憶部、制御部としてのコンピュータの機能を有する装置とするとよい。本発明では対話エンジンを備えていることがよい。外部サーバーの場合には例えばＩＤやパスワードや電子認証によって接続可能となる。外部サーバーはクラウドサーバーがよい。サーバーは音声認識エンジンを備え、音声認識エンジンによって音声を文字列データに変換ことができることがよい。変換された文字列データはインターネット回線を使用して装置に送信されることがよい。
対話エンジンを備えるサーバーに接続して音声データを出力する機能は、例えば、音声認識した文字列を対話エンジンに送信し、対話エンジンからその文字列に対応する対話内容を含む文字列を受信して、当該対話内容の文字列を音声合成機能で音声データに変換するとよい。
文字列の音声データへの変換は、装置に備えた音声合成エンジンで行ってもよいが、文字列を音声データに変換する音声認識サーバーに文字列を送信し、当該音声認識サーバーから変身された当該文字列に対応する音声データを受信して行うとよい。

（１２）音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分があっても、ある条件を満たすことで音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるようにするとよい。

音声を認識して変換した文字列が記憶手段に記憶された文字列と一致する部分がある場合に、ユーザーが予測できるような決まった音声出力をすることは対話の意欲を削ぐことにもなるため、敢えてこのよう外部サーバーに接続することが、より人間的な対話ができることとなりよい。
例えば、ユーザーから「こんにちは」と発話がされ、それを装置側が認識した場合に、本来のシナリオでは「こんにちは、ご機嫌はいかがですか」というように対話をさせるビルトインシナリオであった場合に、そのシナリオを使用せずに外部サーバーに「こんにちは」という音声データをリクエストし、外部サーバーの対話エンジンを使用してその「こんにちは」に対する返答データの作成をリクエストするようにすることがよい。ある条件は例えば何回かに一回の回数や、ランダムなタイミングとするとよい。

（１３）音声認識後に音声が途切れて無音状態となったことを検知する機能と、音声認識から無音状態となるまでの音声データを記憶する記憶手段と、前記記憶手段に記憶された音声データを無音状態となったタイミングで音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるとよい。

対話においてはしばしば無音状態となることがある。しかし、無音状態となっても外部の音声認識エンジンを備えるサーバーに接続したままでは無用なコストがかかってしまう。そのためこのような前もって音声認識から無音状態となるまでの音声データを記憶手段に記憶させ、リアルタイムではなくその音声データを無音状態となったタイミングで送ることで無音部分の時間分をカットできるため、コストが削減できる。

（１４）前記装置は録音機能を備え、所定の音圧レベルの音声の検出によって音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるようにするとよい。
常に外部の音声認識エンジンを備えるサーバーに接続したままでは無用なコストがかかってしまう。これによって無音や無音に近いような対話になっていない場合には接続せずに必要な対話が開始される場合にのみ外部サーバーに接続するため、接続のためのコストが削減できる。
音声認識エンジンを備えるサーバーは、装置ですでに録音済みの過去の所定期間の録音データを受信して、当該録音データに対する文字列を返信するものとしてもよいが、特に、例えばストリーミングデータとしてリアルタイムに音声データを受信して、文字列を返信するタイプのものとするとよい。音声データの受信時間当たり何円という形で従量課金等されるケースが多いが、大幅にコストを削減することが可能となる。

（１５）音声認識エンジンを備えるサーバーに接続して音声データを出力した際に、前記サーバーがビジー状態である場合に、前記ユーザーに対して記憶手段に記憶された対話データから選択された対話例を音声出力する機能を備えるようにするとよい。

ビジー状態である場合にはその旨の報知をすることが普通であるが、例えば対話途中でそのような報知は唐突でいかにも対話とは関係ない発話であり、対話がしらけてしまう可能性もある。そのため、ビジー状態である旨の報知の代わりに例えば「もう一度いってくれる？」という呼びかけや「ほう、そうですか」などのつなぎの発話をして対話をつなぐようにすれば、その間に音声認識エンジンに接続して適切な対話を続けることが可能となるし、対話が不自然にならない。

（１６）認識した前記ユーザーの発話が長すぎると判断した場合に、音声認識エンジンを備えるサーバーに接続することなく記憶手段に記憶された音声データから選択された対話例を音声出力する機能を備えるようにするとよい。

ユーザー側の発話が長すぎると、音声認識エンジンが誤認識をする可能性がある。そして、その結果的外れな返答が返ってくることがある。そのため、一定以上のセンテンスになってしまった場合には、あえてそのような可能性を排除して対話を仕切り直しするために「うん」とか「マジ？」とか「本当ですか？」などという対話においてどのようにも取れる相づちのような対話例を選択して音声出力することがよく、それによって適切な対話を続けることが可能となる。

（１７）対話による前記コミュニケーションにおいて、前記装置の音声を聞き逃した際に、前記ユーザーのある発話に基づいて前記装置は直前の音声を再度出力するとよい。
例えば「もう一度言って」とか「もう一回しゃべって」のような直前に装置が話した言葉が聞き取れなかったり、うっかり聞き忘れた場合にこのような呼びかけをすることで、直前に装置が話した言葉を発話させることができる。これによって、直前まで行っていた対話を途切れさせることなくそのまま続けることが可能となる。

（１８）音声を認識できなかった場合に、前記ユーザーに対して再度の発話を促すように前記装置から音声が出力されるとよい。
これによって、直前まで行っていた対話を途切れさせることなくそのまま続けることが可能となる。

（１９）認識した音声内容がある条件を満たす場合に、表示部にある表示をさせるようにするとよい。
例えば、所定の言葉が含まれた発話がされ、それを音声認識した場合に、表示部にその言葉に対応する「ある表示」をさせるようにする。「所定の言葉」とは、例えば、ユーザーの誕生日、ユーザーの子供の名前、装置の愛称、会社の名称、特定の宣伝用のキャッチフレーズ等とするとよい。所定の言葉とある表示との対応関係を予め設定しておく機能を備えるとよい。これによって、単なる対話に留まらず目視を含めたコミュニケーションをすることができ、装置との間でコミュニケーションの態様が増すこととなってコミュニケーションを図る際の利便性が高まる。

（２０）前記装置は筐体又は筐体に接続される部分を動かす機能を備え、認識した音声内容がある条件を満たす場合に、筐体又は筐体に接続される部分がある動きをするとよい。
例えば、所定の言葉が含まれた発話がされ、それを音声認識した場合に、筐体又は筐体に接続される部分にその言葉に対応するある動き、例えばジェスチャーをさせるようにする。これによって、単なる対話に留まらず装置の動きを含めたコミュニケーションをすることができ、装置との間でコミュニケーションの態様が増すこととなってコミュニケーションを図る際の利便性が高まる。上記の「ある表示」と組み合わせると特によい。

（２１）前記装置は前記ユーザーが目として認識できる部分である目部と、前記ユーザーの位置を認識するユーザー位置認識機能と、前記目部を動かす機能とを備え、 前記コミュニケーションとして前記位置認識機能で認識した前記ユーザーの位置方向を向くよう前記目部を動かす機能を備えるとよい。

目として認識できる目部がユーザーの位置方向を向くことで、実際に人と話しているような疑似感覚を得られることとなり、装置とコミュニケーションを取りたいという欲求もますこととなり、装置の利用価値が向上する。
「ユーザーが目として認識できる部分である目部」は表示画面に表示されるオブジェクトとしての目でもよく、そのようなバーチャルな映像ではない実際に機械的に動作する目でもよい。目部と同期して装置自体もユーザーの位置方向を向くよう制御してもよい。目部をユーザーの方向に向けるための装置だけをユーザーの位置方向を向くよう制御してもよい。

（２２）前記装置はユーザーの顔を認識する顔認識機能を備えるとよい。
個々の人物の顔を識別できるため、個々の個性に応じたコミュニケーションをとることが可能となる。例えば個々の人物の認証された顔と名前を関連付けすることで、対話の際に顔認識した人物をその名前で呼ぶことができる。また、過去の対話履歴に基づいて顔認識した人物に特化した対話を行う構成とすると特によい。

（２３）前記装置は表示部を備え、前記顔認識機能によってユーザーの顔の認識状況を表示部に表示させる機能を備えるとよい。
このようにすればユーザーは自身の顔の装置での認識状況を表示部を見ることで把握できる。特に認識状況として顔認識が完了しているか、それとも未だ人物の顔として認識されていないかを表示させるとよく、このようにすれば、ユーザーは未だ認識が完了していなければなるべく装置が認識しやすいように顔を動かさないようにして協力することができる。

（２４）前記位置認識機能は、三角形の頂点に配置された３つのマイクロフォンと、音源から前記３つのマイクロフォンの各々までの音の到達時間の差に基づき、前記音源の位置を、前記三角形を含む平面に垂直な方向に沿って前記三角形を含む平面に投影した位置から前記平面の前記三角形で囲まれた領域の内側にある基準位置へ向かう音源方向を特定する特定部と、を備える音源方向特定機能であるとよい。
これによって３つのマイクロフォンで音源方向を特定することができる。そして、音源方向を特定することができれば、ユーザーが発話すればその方向に装置を向けさせることができるため、対話によるコミュニケーションをしているようにユーザーは感じることができる。

（２５）前記装置は赤外線リモコン信号出力部を備え、前記コニュニケーションは赤外線リモコン受信機能を備える前記他の機器との間のコミュニケーションであるとよい。
これによって装置の赤外線リモコン信号出力部を介して簡単に機器との間のコミュニケーションを取ることができる。
例えば、赤外線リモコン信号受信部を備えた受信側装置、例えば、赤外線リモコン信号受信部を備えた受信側装置、例えばテレビ、オーディオ装置、エアコン装置等に対して装置から赤外線リモコン信号を出力して例えばＯＮ・０ＦＦ等の制御を実行させることが可能となる。特に装置に音声対話機能を備え、例えば「テレビつけて」とか「テレビ消して」という命令語句の発話に対し、装置はその命令に基づいて赤外線リモコン信号出力部を制御する構成とよい。

（２６）前記装置は前記他の機器からのインターネットを介して遠隔操作されるようにするとよい。
他の機器から装置を遠隔操作できるため、装置の利便性が高まる。例えば、他の機器としてのスマートフォン等とするとよい。装置にはカメラを備えるとよい。装置にはカメラの向きを変える機構を備えるとよい。他の機器からアクセスして、例えば、装置側のカメラ動画を見たり、カメラの向きを代えたりすることがよい。これによって装置の近くにいなくとも装置の制御が可能となる。また、例えばスマートフォンからアクセスして、例えば装置の見守り機能をＯＮとして、人（物）が動いたことをスマートフォンにｅメールで通報するようにするとよい。また、例えば病人や被介護者の見守りとして、常に動いていることを前提とし、例えば一定時間以上その人が動いていない場合に通報するようにするとよい。他の機器とは、例えばタブレット端末やパソコン等でもよい。

（２７）装置は前記他の機器からインターネットを介して送信された文字情報を用いて前記音声出力を行うようにするとよい。
例えば受信した電子メールの文字列を読み上げる機能を備えるとよい。誰かからのｅメールが届く設定にしておくことで、そのメール内容が装置から音声出力されるため、自身の端末を目視で確認する必要がなくなる。他の機器とは、例えばスマートフォンやタブレット端末やパソコン等とするとよいが、他の「装置」としてもよい。

（２８）前記音声出力は前記文字情報の内容によって前記音声出力を行う時間、時刻又は回数を変更できるとよい。
例えば「薬飲んだ」とういうメールは決まった時刻にしゃべらせたい。例えば件名の記載が合致することで、所定の時刻に装置が発話したり、例えば重要な内容を時間を空けて２回発話させるようにすれば、装置側の近くにいるユーザーにメール内容を間違いなく実行させることができる。

（２９）前記装置は音声認識した文字情報を前記他の機器へインターネットを介して送信する機能を有するとよい。
装置の音声コミュニケーション機能を使用して音声を文字化して他の機器に文字データとして送れば、例えばｅメールを送りたい場合に自身の端末に手入力しなくとも、送ることができる。

（３０）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、最も長い前記出力文字列を選択して対話させる機能を有するとよい。
最も長い返答であると、いかにも対話しているように感じ、対話の単調さがなくなり、聞き手（ユーザー）は対話を楽しむことができる。

（３１）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、語尾に疑問符がついた前記出力文字列を選択して対話させる機能を有するとよい。
語尾に疑問符がつくと、その疑問に更に答えるような話の流れになるため、会話が続きやすくなり聞き手（ユーザー）は対話を楽しむことができる。

（３２）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、肯定文を組み合わせた後に疑問文を組み合わせて対話させる機能を有するとよい。
このようにアレンジすることでいかにも考えて文章を練ったような応答になるため、ユーザーは真剣に自身の発話を聞いてもらっているような感覚となり、続けて会話をしたいと思うようになるため、会話が続きやすくなり聞き手（ユーザー）は対話を楽しむことができる。また、出力尺をかせぐことができるとともに聞き手（ユーザー）への返答を求めることができる。

（３３）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、話題転換した文字列を最後に配置するように組み合わせて対話させる機能を有するとよい。
このようにアレンジすることで話題転換したことで次の発話を誘うような対話となり、対話が続きやすくなる。

（３４）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、フレンドリーな前記出力文字列を初めに配置するように組み合わせて対話させる機能を有するとよい。
このようにアレンジすることで聞き手（ユーザー）が対話に引き込まれやすくなり、対話が続きやすくなる。

（３５）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、それらをランダムな順で組み合わせて対話させる機能を有するとよい。
対話のバリエーションが増えることとなるため、聞き手（ユーザー）が同じ発話をした場合でもまったく同じ応答が帰ってきてしまうことがなくなり、対話に飽きることがなく対話が続きやすくなる。

（３６）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、それらの内に顔文字を含む前記出力文字列がある場合には、対話対象とせず、表示部には対話対象とされた前記出力文字列と一緒に表示させる機能を有するとよい。
顔文字は音声出力できないが、表示部に敢えて顔文字を表示させることで、音声と併せて対話の一部とすることで通常にはない対話のおもしろさを創出することができる。

（３７）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、同じ文字列が含まれる前記出力文字列同士についてはいずれか１つのみを選択して他の前記出力文字列と組み合わせて対話させる機能を有するとよい。
同じ文字列が繰り返されると対話がくどくなってしまうし、聞き手に違和感を覚えさせてしまうためである。

（３８）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、前記出力文字列の語尾を語尾変換エンジンによって変換してから組み合わせて対話させる機能を有するとよい。
普通の対話エンジンの文章に比べて、より親しみやすい表現となるのでよい。

（３９）入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、すべての前記出力文字列を使用せずに一部の前記出力文字列を記憶手段に記憶させておき、以後の対話で前記記憶手段から取り出して対話に使用させる機能を有するとよい。
音声認識が失敗した場合や、外部サーバーからのレスポンスがなかなか来ない場合に使用することで、対話が途切れずにつなげることができ、自然な対話に寄与する。

（４０）音声認識エンジンを備えるサーバーを利用する際に料金が無料のサーバーと有料のサーバーをミックスして利用するとよい。
これによって例えば特に装置との対話のヘビーユーザーはサーバー接続料金を節約することができる。

（４１）前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカに音声出力を行って前記スマートスピーカとコミュニケーションを行うようにするとよい。
スマートスピーカは表示部がないため、装置と組み合わせて使用することで利便性が高まる。
スマートスピーカとは、例えば無線通信接続機能と音声操作のアシスタント機能を持つスピーカーとするとよい。例えばGoogleHome、AmazonEcho、LINE Clova等とするとよい。スマートスピーカは例えば様々な機能・能力（スキル）を実現する機能を備えるものとするとよい。て音声でのコミュニケーションをする装置からスマートスピーカに対して発話することでその機能を実行させることができる。装置から発話させる際には、例えばユーザーがスマートスピーカのスキルを起動させるフレーズを発話し、装置がその発話を音声認識して文字列データとして保存し、あるタイミングでその文字列データを音声合成してスマートスピーカに対して発話してスキルを実行させる構成とするとよい。

（４２）前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカに音声出力を行って前記スマートスピーカとコミュニケーションを行うようにするとよい。
スマートスピーカを起動させたり、スキルを起動させる。あるいは問い合わせを行う。自らスマートスピーカを起動させなくとも、ある決まったタイミングや、ある予定時刻にスマートスピーカのスキルを自動的に実行させることが可能となる。

（４３）前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカの音声出力を翻案する翻案機能を有するとよい。
質問に対するスマートスピーカの決まった長い回答を聞くのが面倒であったりする場合や、内容をざっと再確認したい場合に便利である。

（４４）前記装置の音声出力はＷｅｂ記事の読み上げる機能を有するとよい。
Ｗｅｂ記事を読まなくとも装置との対話のみで聞くことができる。

（４５）前記ある出力としてロボティクスプロセスオートメーションの所定の処理単位の実行が完了した時点でなされるようにするとよい。
ロボティクスプロセスオートメーションは処理単位の実行状況がわかりにくいが、装置に処理単位の実行に応じた「ある出力」をさせることで処理状況がわかりやすくなり利便性が高まる。

（４６）前記ある出力とは報知動作とするとよい。
報知動作によってある出力がされたことがわかることとなる。
（４７）ロボティクスプロセスオートメーションの実行中のコンピュータがユーザーからの入力待ち状態となった場合に、報知動作を行うようにした。
これによって入力待ち状態となったことをユーザーに報せ、次の処理を促すことが可能となる。

（４８）ロボティクスプロセスオートメーションを行うクライアントコンピュータと、前記クライアントコンピュータに対してロボティクスプロセスオートメーションの実行指示を与えるサーバーコンピュータとを備え、前記クライアントコンピュータに前記サーバーコンピュータからの指示があった場合、報知動作を行うようにするとよい。
これによってサーバーコンピュータからの指示があったことをユーザーに報せ、次の処理を促すことが可能となる

（４９）ロボティクスプロセスオートメーションを実行しているコンピュータの方向を指し示す動作を行なう前記出力情報を生成するとよい。
これによってどのコンピュータにおいて実行が行われたのかをユーザーがわかることとなり、ユーザーに次の処理を促すことが可能となる。
（５０）ロボティクスプロセスオートメーションの実行状態に応じて異なる前記出力情報を生成するものとするとよい。
これによってどのような実行が行われたかを区別することができる。

（５１）（１）～（５０）のいずれかに記載の装置の機能をコンピュータに実現させるためのプログラム。
「ある出力」など「ある」と記載した部分は例えば「所定の」とするとよい。
上述した（１）から（５０）に示した発明は、任意に組み合わせることができる。例えば、（１）に示した発明の全てまたは一部の構成に、（２）以降の少なくとも１つの発明の少なくとも一部の構成を加える構成としてもよい。特に、（１）に示した発明に、（２）以降の少なくとも１つの発明の少なくとも一部の構成を加えた発明とするとよい。また、（１）から（５０）に示した発明から任意の構成を抽出し、抽出された構成を組み合わせてもよい。本願の出願人は、これらの構成を含む発明について権利を取得する意思を有する。また「～の場合」「～のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。

ユーザーや他の機器とコミュニケーションを取る際に、装置はコミュニケーションに応じた出力情報を生成することができる。そのため、ユーザー又は他の機器において装置とのコミュニケーションを図る際の利便性が高まる。
本願の発明の効果はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果についても開示されており、当該効果を奏する構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「～できる」と記載した箇所などは奏する効果を明示する記載であり、また「～できる」と記載がなくとも効果を示す部分が存在する。またこのような記載がなくとも当該構成よって把握される効果が存在する。

本発明にかかる実施の形態１のロボットの正面図。 同じ実施の形態１のロボットの側面図。 同じ実施の形態１のロボットの背面図。 ロボットの電気的構成を説明するブロック図。 ロボットの顔面部に表示される顔画面のある表情の一例を捉えた説明図。 ロボットの顔面部に表示されるチャット画面のあるチャット状態の一例を捉えた説明図。 ロボットの顔面部に表示される顔画面を背景とする待ち受け画像を説明する説明図。 ロボットの顔面部に表示されるチャット画面を背景とする待ち受け画像を説明する説明図。 （ａ）～（ｄ）はロボットの顔面部に表示される目オブジェクトの変形パターンを説明する説明図。 （ａ）～（ｃ）はロボットの顔面部にユーザーの発話内容が文字列として徐々に表れてくる様子を説明する説明図。 ロボットの顔面部に表示される顔画面において目オブジェクトがユーザーの顔を追って移動している状態を説明する説明図。 スマートフォンの一例を説明する説明図。 ロボットの起動～ウェイクアップモード～対話モード～スリープモードの関係を説明する説明図。 実施の形態７においてロボットとスマートスピーカの関係を説明する説明図。 実施の形態９においてスマートフォンの一例を説明する説明図。

＜実施の形態１＞
図１～図３に示すように、人の声に反応して動作するコミュニケーションロボットであるロボット１は、下半身となる固定部２と、固定部２上に載置される上半身となる可動部３を筐体として備えている。可動部３は固定部２に隣接配置された胴部４と、胴部４に支持された頭部５とから構成されている。固定部２は上に開いた碗状の外観に形成され、胴部４は固定部２上縁と上下方向に連続的なカーブで構成された筒体形状に形成されている。ロボット１は固定部２と胴部４の接続部分がもっとも大径に構成されて、その接続部分を境界に上下方向に窄まった外形とされている。胴部４はその筒体形状の前方が半円形形状に大きく切り欠かれている。頭部５は胴部４の上部に埋め込まれるように嵌合されている。胴部４は固定部２に対して水平方向（図１の矢印方向）に回動し、頭部５は胴部４に対して縦方向（図２の矢印方向）と左右回転方向（図３の矢印方向）の２方向に回動する。

頭部５は全体として球体の一部（前面部分）が１つの平面でカットされた残余である球欠状の形状に構成されている。カット状に形成された前面部分は円形形状に現れロボット１の顔面部６を構成する。顔面部６の表面に形成された長方形部分はタッチパネル機能を備えた液晶ディスプレイ（ＬＣＤ）である表示部としてのタッチパネル部７とされている。タッチパネル部７に表示される内容については後述する。タッチパネル部７の周囲の顔面部６領域にはスモークパネルが配置され顔面部６全体が統一された濃色の背景となっている。頭部５の内部において顔面部６の上方左右の収容位置には照度センサ８と高輝度白色ＬＥＤ９がそれぞれ配設されている。顔面部６においてタッチパネル部７の上部中央位置には顔認識用カメラ１０のレンズ１１が配設されている。

胴部４内部において胴部４の前方左右寄り位置と後方中央位置の１２０度ずつずれた同じ高さの３箇所の位置にはマイクロフォン１２が配設されている。固定部２内部において固定部２上には左右一対のスピーカ装置１３が配設されている。スピーカ装置１３の側方にはスピーカ装置１３で発生した音を出力するための開口部１４が形成されている。スピーカー用開口部１４に隣接した位置には電源スイッチ１５とスピーカー装置１３の音量を調整するためのアップスイッチ１６とダウンスイッチ１７がそれぞれ配設されている。固定部２の後方位置にはＵＳＢのＯＴＧ（On-The-Go）用の端子１８、ＤＣ１２Ｖ用の電源用ジャック２０、マイクロＳＤカード用ソケット（リーダー）１９が配設されている。

ロボット１はインターネット回線を利用して所定の外部のクラウドサーバーに接続可能とされている。クラウドサーバーはロボット１が必要とするデータを記憶する記憶手段としての記憶領域、ロボット１が必要とする各種処理を行うための各種エンジン等を備えている。そのため、広義にはロボット１はこれらのクラウドサーバーのソフトウェア等の部分を含めた装置として解釈することができる。

次に、図４のブロック図に基づいて、実施の形態１のロボット１の電気的構成について説明する。
制御手段としてのコントローラＭＣには上記のタッチパネル部７、照度センサ８、高輝度白色ＬＥＤ９、顔認識用カメラ１０、マイクロフォン１２、スピーカ装置１３、端子１８、マイクロＳＤカード用ソケット１９が接続され、これらに加え、無線ＬＡＮ装置２１、ドップラーセンサ２２、第１～第３のモータ２３～２５等がそれぞれ接続されている。

タッチパネル部７はその表面に接触することで入力する入力操作機能を有する。タッチパネル部７は後述する自然対話モードにおいては図５又は図６のような異なった画面を表示させることができる。コントローラＭＣは第１の画面として図５のようなロボット１の表情、特に目の周辺の変化を司る顔画面Ｓ１を変位可能にタッチパネル部７に表示させる。顔画面Ｓ１はデフォルトで表示される画面であって、ロボット１の目オブジェクト２７とほっぺオブジェクト２８と楕円領域２９が表示される。目オブジェクト２７はアニメーション画像としていくつかの目オブジェクト２７の変形パターンを備えている（図９（ａ）～（ｄ））。また、アニメーション画像として瞳オブジェクト２７ａが左右に移動する動きをする。

また、コントローラＭＣは第２の画面として図６のようなチャット画面Ｓ２をタッチパネル部７に表示させる。チャット画面Ｓ２は顔画面Ｓ１の状態でタッチパネル部７をタッチしてスライドさせることで顔画面Ｓ１に代えてタッチパネル部７上にチャット画面Ｓ２を表示させることができる。スライド操作によって顔画面Ｓ１とチャット画面Ｓ２は相互に表示切り替えが可能となっている。チャット画面Ｓ２については後述する。
また、タッチパネル部７は待ち受けモード（ウェイクアップモード）ではタッチパネル部７上に図７又は図８の待ち受け画像を表示させることができる。待ち受け画像については後述する。
ロボット１にはこれら以外の異なる画像として設定画面が用意され、チャット画面Ｓ２からその設定画面に移動可能である。ロボット１が初めて起動された状態では設定画面からアクセスして、例えば、ＩＤ・パスワードのサーバーへの設定登録、Wi-Fiパスワードの設定登録、ユーザー登録（例えば名前、年齢、性別等）、顔認証、データを転送する先となるｅメールアドレスの設定等の必要な初期設定項目を入力する。

照度センサ８は、ロボット１の設置された環境の明るさを認識する。高輝度白色ＬＥＤ９は照度センサ８の検出した数値に基づいて顔認識用カメラ１０による撮影に光度が足りない場合に自動的に点灯される。
マイクロフォン１２は、ユーザーとの対話においてユーザーの発話を取得する音声入力手段であると同時に、三角形の頂点に配置される３つのマイクロフォン１２を同時に使用することで、これらの間での音の到達時間の差によって音源方向を特定することができる方向検知手段でもある。コントローラＭＣは各マイクロフォン１２の取得した電気信号の位相差から到達時間差を求める。コントローラＭＣはその到達時間差に基づいて基準方向に対する音源角度を算出する。ユーザーとの対話に特化したマイクロフォンを例えば顔面部６に設けるようにしてもよい。
スピーカ装置１３は、ユーザーとの対話においてロボット１が発話（音声出力）する音声出力手段である。
マイクロＳＤカード用ソケット１９は挿入されるmicroＳＤカードのデータの読み取り及び書き換えをする。
無線ＬＡＮ装置２１は、Wi-Fi対応機器であるロボット１をインターネットに無線接続させるための機器である。本実施の形態ではIEEE802.11bの国際標準規格とされている。
ドップラーセンサ２２は、マイクロ波を使用したセンサであって、マイクロ波を発射し、反射してきたマイクロ波の周波数と、発射した電波の周波数とを比較し、物体（人）が動いているかどうかを検出する。ドップラー効果により物体（人）が動いている場合の反射波の周波数が変化することを利用するものである。例えば、ユーザー不在時の不審者の有無等のように、ロボット１の周囲の異常を検知するために使用される装置である。
第１のモータ２３は胴部４を固定部２に対して水平方向（図１の矢印方向）に回動させるためのサーボモータである。第２のモータ２４は頭部５を胴部４に対して縦方向（図２の矢印方向）に回動させるためのサーボモータである。第３のモータ２５は頭部５を胴部４に対して左右回転方向（図３の矢印方向）に回動させるためのサーボモータである。マイクロフォン１２によってユーザーの発話する方向が決定された場合にはコントローラＭＣは顔面部６がユーザーの方向に正対するように第１のモータ２３を制御して固定部２に対して胴部４（可動部３）を回動させる。

コントローラＭＣは周知のＣＰＵやＲＯＭ及びＲＡＭ、ＳＳＤ等の記憶手段としてのメモリ、バス、リアルタイムクロック（ＲＴＣ）等から構成されている。コントローラＭＣのＲＯＭ内にはロボット１の各種機能を実行させるための各種プログラムが記憶されている。
各種プログラムとしては、例えばマイクロフォン１２とスピーカ装置１３を介したユーザーとの対話を制御するための対話プログラム、顔認識用カメラ１０を使用した顔認識に関する顔認識プログラム、タッチパネル部７や第１～第３のモータ２３～２５を制御してロボット１との対話中におけるロボット１の表情や動作を変化させるための表示変動・ジェスチャープログラム、ユーザーとの対話やタッチパネル部７の操作に基づいて異なる画面や画像をタッチパネル部７上に表示させる画面表示プログラム、他のコンピュータやスマートフォンとの間でロボット１側で取得した例えばカメラ画像やスマートフォン等からのｅメール等を処理するデータ送受信プログラム、ユーザーが不在の際の見守りのための留守設定時プログラム、ＧＵＩ機能・ネット接続機能、プロセス管理等の操作・運用・運転のためのＯＳ等が記憶されている。ＲＡＭ内には対話や顔認識における入出力データ等が一旦記憶される。各プログラムは他のプログラムと連携してあるいは独立してマルチタスクで対話、顔認識、ジェスチャー等の機能が実現される。

Ａ．対話時の動作内容について
上記のような構成において、コントローラＭＣは対話プログラムを実行することによってユーザーとの対話によるコミュニケーションを制御する。尚、対話の開始可能と同期して可能となる顔認識については下記「Ｂ．顔認識時の動作内容について」で後述する。
ここで、対話プログラムは、
１）マイクロフォン１２から取得したユーザーの発話データ（音声データ）をクラウドサーバーにリクエスト発行し、サーバー側の音声認識エンジンを使用してテキスト化したユーザーの発話データ（文字列データ）をレスポンスするためのサブプログラム
２）ユーザーの発話（文字列データ）に基づいてビルトインシナリオの対話を実行させるビルトインシナリオサブプログラム
３）ユーザーの発話がビルトインシナリオに対応しない場合に発話データ（文字列データ）を再びクラウドサーバーにリクエスト発行し、対話ＡＰＩ（アプリケーションプログラミングインタフェース）を利用して対話エンジンにロボット１の返答データ（文字列データ）を作成させる発話データ転送サブプログラム
４）レスポンスされた返答データ（文字列データ）を表示部としてのタッチパネル部７に表示させる文字列データ表示サブプログラム
５）レスポンスされた返答データ（文字列データ）を音声合成エンジンによって音声データに変換しスピーカ装置１３からロボット１側の発話として音声出力させるための音声データサブプログラム
６）ユーザー側文字列データやロボット１側文字列データに基づいてタッチパネル部７上の表示態様やロボット１の動作を変動させる表示態様・動作変動サブプログラム、
等を含む。
以下、主として対話プログラムに基づいたコントローラＭＣの制御内容の一例について、起動後の待ち受けモード（ウェイクアップモード）と自然対話モードとスリープモードの相互の関係と共に説明する。これらの相互の関係は図１２に示されるとおりである。
図５と図６は自然対話モードの画面であり、図７と図８は待ち受けモードの画面である。スリープモードではこれらの画面はタッチパネル部７のバックライトが消灯して暗くなった画面である。

１．起動
電源スイッチ１５の投入によってロボット１は起動される（図１３の処理Ｍ０）。コントローラＭＣではブート・プログラムが実行され、次いでＯＳが起動すると、ＯＳはユーザーからの「命令（コマンド）」待ち状態、つまりウェイクアップ状態となる。この初期の待ち受けモードでは図７の待ち受け画面が表示される。
尚、以下では初期設定が完了した後の状態、つまりロボット１のＩＤとパスワードがクラウドサーバーに登録され、ユーザー登録が完了し、複数のユーザーの顔認証がされ、スマートフォンのｅメールアドレスがロボット１に登録される等以後の起動とする。
『１．起動 における効果』
このように起動によって複数の待ち受け画面から選択された１つの画面（図７）がまず表示される。つまり、起動時には常に決まった画面が表示されることとなる。そしてロボット１の目が閉じている（対話ができないことを暗示している）ことから待ち受けモードにあることがユーザーに容易にわかるようになっている。

２．待ち受けモード（ウェイクアップモード）
待ち受けモードは自然対話モードの開始のトリガーがあるとロボット１と対話が可能となる状態である。また、自然対話モードにおいて対話が終了した場合に移行する状態でもある。また、一定時間自然対話モードが開始されないとスリープモードになってしまう状態でもある。スリープモードはロボット１と対話でコミュニケーションが取れない状態である。
ここに「自然対話」とはロボット１のビルトインシナリオやサーバ上の対話エンジン（対話ソフト）を使用してユーザーが音声合成された装置（ロボット１）側の音声と対話することをいう。自然対話モードは自然対話が可能な状態である。
待ち受けモードの画面は複数あり、本実施の形態では図７と図８の２種類が用意されている。
図７は図５の自然対話モードにおける画面から移行する待ち受け画面である（図１３の処理Ｍ２）。また、図１３の処理Ｍ０によって起動時に表示される待ち受け画面でもある。図７では、日時と曜日と、大きく現時間が表示がされた時計レイヤーの画面の背景にロボット１の目（目オブジェクト２７）が閉じた状態の顔画面Ｓ１のレイヤー画面が薄く表示されている。
図８は図６の自然対話モードにおける画面から移行する待ち受け画面である（図１３の処理Ｍ２）。図８では、日時と曜日と、大きく現時間が表示がされた時計レイヤーの背景にチャット画面Ｓ２のレイヤー画面が薄く表示されている。つまり、待ち受けモードではあるが自然対話モードではない。
『２．待ち受けモード（ウェイクアップモード） における効果』
このように、異なる待ち受け画面が用意されているので、ある待ち受け画面から自然対話モードが開始される場合にユーザーは直前にアクセスしていた画面での対話を行うことができるため利便性がよい。また、待ち受けモード特有の画面を表示させることで、ロボット１が待ち受けモードにあることがユーザーに容易にわかるようになっている。

３．自然対話モードの開始と停止
起動されて待ち受けモードやスリープモードにある状態から、コントローラＭＣは例えば次のような複数のタイミング、つまりモード移行のトリガーによって自然対話モードに移行させるよう処理する（図１３の処理Ｍ１、Ｍ５）。以下のトリガーは一例である。自然対話モードでは下記「Ｂ．顔認識時の動作内容について」で説明するような顔認識モードに切り替わる（顔認識ができるようになる）。

１－１）待ち受けモードにおいてコントローラＭＣは一定時間内に起動フレーズとして、例えば「ねえ、ユピ坊」というような発話（音声）をマイクロフォン１２から認識するとそれをトリガーとして自然対話モードとする（図１３の処理Ｍ１）。また、タッチパネル部７へのタッチ動作があったと判断した場合もそれをトリガーとして自然対話モードとする（図１３の処理Ｍ１）。
１－２）スリープモードにおいてコントローラＭＣは、所定のタイミングで待ち受け画面のタッチパネル部７へのタッチ動作があったかどうかを判断する。タッチパネル部７へのタッチ動作は顔面部６における表示態様によって異なり、顔画面Ｓ１の待ち受け画面ではタッチパネル部７全域へのタッチが、チャット画面Ｓ２の待ち受け画面では後述する対話開始ボタンオブジェクト３６へのタッチで開始される。つまり、異なる画面で異なる操作で開始されることとなる。
タッチパネル部７へのタッチ動作があったと判断した場合には、コントローラＭＣは一旦待ち受けモードとし（図１３の処理Ｍ３）、続いてもう一度タッチがあったと判断すると自然対話モードとする（図１３の処理Ｍ１）。
１－３）スリープモードにおいてコントローラＭＣは、１－２）と同様にタッチパネル部７へのタッチ動作があったかどうかを判断する。タッチ動作があったと判断した場合には、コントローラＭＣは一旦待ち受けモードとする（図１３の処理Ｍ３）。この状態で一定時間内に起動フレーズとして、例えば「ねえ、ユピ坊」というような発話（音声）をマイクロフォン１２から認識するとコントローラＭＣはそれをトリガーとして自然対話モードとする（図１３の処理Ｍ１）。
２）スリープモードにおいてコントローラＭＣはＲＴＣによってあらかじめ設定された所定の時刻になったかどうかを判断し、所定の時刻になったタイミングで自然対話モードとする（図１３の処理Ｍ５）。
３）スリープモードにおいてコントローラＭＣは、例えば所定のタイミングで生成した乱数によって、ランダムな時間間隔でランダムにある発話（音声データ）をスピーカ装置１３から出力する。つまり、一種の独り言として、例えば「ねえねえ何してる？」とか「暇だなあ」のような対話を誘うような音声をロボット１から出力させて自然対話モードとし（図１３の処理Ｍ５）、ユーザーに発話を促す。
４）スリープモードにおいてコントローラＭＣはドップラーセンサ２２によって物体（人）が動いているかどうかを判断し、物体（人）が動いていることを検出したタイミングで自然対話モードとする（図１３の処理Ｍ５）。

５）スリープモードにおいてコントローラＭＣは天候異常や地震等の気象の変化を察知した場合に、それをユーザーに報知してこれを契機として自然対話を開始する。外部のクラウドサーバーでは一定の基準で例えば天候異常（例えば、大雪、台風等）や地震、落雷等を含む異常気象の情報を異常気象検出エンジンを利用して一定時刻ごとに取得して記憶する。一定時刻とはすべて同じタイミングでもよく、気象の内容によって取得するタイミングを変えてもよい。異常気象の情報は本実施の形態１では、例えばサーバーからプッシュ型の配信システムを採用して装置（コントローラＭＣ）に配信される。コントローラＭＣは情報を取得すると自然対話モードとする（図１３の処理Ｍ５）。
６）コントローラＭＣは上記１）～５）においてそれぞ自然対話モードとなった状態で一定時間ユーザーからの発話を検出しなかった場合には、待ち受けモードとし（図１３の処理Ｍ２）、更に一定時間後にスリープモードとする（図１３の処理Ｍ４）。これらのモード変位時間の長さは、例えば端末装置よって、あるいはビルトインシナリオとして発話によって適宜設定変更可能である。

『３．自然対話モードの開始と停止 における効果』
このように多種類の自然対話モードの開始が用意されることで、様々なタイミングでロボット１と対話することとなりロボット１との対話する機会が多くなり、それによって自然と対話を楽しむ機会も増えることとなって、ユーザーがロボット１を所有するメリットを感じることとなる。また、対話モードが終了すると一旦待ち受けモードになってからスリープモードとなるため、電力コストが削減される。
また、スリープモードから待ち受けモードを飛び越して自然対話モードの画面になるので、直ちに対話を初めることができるため対話開始がスムーズである。また、対話が続く限り対話用の画面（図５や図７）が表示されるため、ユーザーに対話する意欲を惹起させることとなる。

４．自然対話モードにおけるビルトインシナリオの対話
自然対話モードにおいては、ビルトインシナリオの対話とサーバーの対話エンジンを使用した通常対話の複数の対話処理が用意されている。
コントローラＭＣは、ユーザーの発話に基づく発話データ（文字列データ）が、まずビルトインシナリオに合致するかどうかを判断し、そうではない場合にクラウドサーバー経由での対話エンジンを使用した対話（以下、通常対話とする）とするよう制御する。ユーザーからすると常にロボット１と対話しているようであるが、実際は自然対話モードの内部処理は複数あることとなる。
コントローラＭＣはクラウドサーバー側の音声認識エンジンによって作成されたユーザーの発話（文字列データ）をビルトインシナリオ（スクリプト）のテキストデータと比較する処理を実行する。本実施の形態ではビルトインシナリオのテキストデータはメモリに記憶されている。ビルトインシナリオをＳＤカードに追加させてもよい。ＳＤカードであれば書き換えによってビルトインシナリオを次々と増やすことが容易である。
コントローラＭＣはユーザーの発話を認識するとその文字列データが予定した正規表現又は非正規表現に合致するかどうか判断し、合致する場合にはその文字列データに対応するスクリプトを音声合成エンジンによって音声データに変換しスピーカ装置１３からロボと１の発話として音声出力させる。
ビルトインシナリオには、例えばユーザーの発話を促すための「こんにちは」「今日はいい天気ですね」のような挨拶のような簡単なシナリオや、ユーザーからの発話に基づく何かの処理を求めるためのシナリオのようなもの等、多くのビルトインシナリオが設定されている（用意されている）。表１～３にこのようなビルトインシナリオの一例を開示する。もちろん、実際にはこれらのビルトインシナリオ以外にも多くのビルトインシナリオが設定されている。

ビルトインシナリオ通りに対話がされない場合には、途中でビルトインシナリオでの対話は終了する。ビルトインシナリオ通りに対話がされない場合とは、例えば次のような場合である。
１）予定した正規表現又は非正規表現に合致しない場合
ビルトインシナリオに当初から、あるいは途中から正規表現又は非正規表現に合致しなくなる場合である。また、ユーザーの滑舌が悪くて発話を正しく取得できなかった場合も含む。この場合にはコントローラＭＣは通常対話であると判断して直ちに外部のクラウドサーバーに接続し、以後は外部のクラウドサーバーへ発話データをリクエスト発行し、外部のクラウドサーバー側の対話エンジンに文字列データ化された返答データを作成させる。そして、その返答データを音声合成エンジンによって音声データに変換しスピーカ装置１３から音声出力させるようにして対話を続ける。

２）予定通りにビルトインシナリオでの対話が終了した場合
例えば、ユーザーに対してシナリオに従った、例えば、「×××を行ってよいですか？」という発話をした際に、「はい」や「お願いします」等の肯定的な発話があって予定通りにビルトインシナリオでの対話が終了したため対話がなくなった場合、あるいはシナリオの途中で対話がなくなった場合等が考えられる。この場合には一定時間後に待ち受けモードとなる。
３）ある処理を進めてよいかどうかについてユーザーの発話が否定的であった場合
ユーザーに対してシナリオに従った、例えば、「×××を行ってよいですか？」という発話をした際に、「はい」や「お願いします」等の肯定的な発話ではなく、「いいえ」「間違いでした」のような否定的な発話があった場合もビルトインシナリオは終了し、以後の対話は１）又は２）と同様である。
この否定的発話の際にはコントローラＭＣは「本当にいいですか？」などと処理をやめてよいかどうかの確認を行う。これによってユーザーの言い間違いや心変わり等に対応することができる。例えば、電源オフ用シナリオにおいてユーザーに対してシナリオに従った「本当に電源オフしなくてもいいの？」という問いかけの発話をした際に、ユーザーから「はい」という発話があった場合には「本当に電源オフしなくてもいいの？」という問いかけを複数回（実施の形態では例えば３回）繰り返して「はい」があるとビルトインシナリオでの対話は終了する。

『ビルトインシナリオとする効果』
このようにビルトインシナリオが用意されていると、すべての対話を外部サーバーにリクエストする必要がなく、装置内部で処理できるため、サーバーに接続する通信コストが軽減され、また通信時間やサーバー側での計算時間が不要となるためユーザーの発話に対する返答が遅くなりすぎて会話が途切れてしまうような違和感を覚えることがなくなる。また、例えば、決まった処理を実行させる場合にこのようなビルトインシナリオを設けておくことでユーザーは処理実行のためにタッチパネル部７を操作したり、他の端末からロボット１にアクセスしたりする必要がなくなり対話で処理を実行させることができ、ユーザーフレンドリーである。

５．通常対話におけるリクエストとレスポンス
一方、発話データ（文字列データ）はビルトインシナリオではない場合に、コントローラＭＣはクラウドサーバーに接続させ、改めて発話データ（文字列データ）をサーバーに送信し対話エンジンによる返答データの作成をリクエストする。コントローラＭＣはユーザーが認証できている場合にはリクエストにおいてユーザー毎の認証情報（例えばＩＤとパスワード）に発話データの冒頭に送る。その場合には過去の対話情報が加味されて返答データが作成される。一方、ユーザーが認証できていない場合には過去に特定されていない人物として特に認証情報は送信しないので、過去の対話情報は加味されない。クラウドサーバーはリクエストがあると対話ＡＰＩ（Application Programming Interface）を利用して対話エンジンにその発話データ（文字列データ）に基づいて返答データ（文字列データ）を作成させ、ロボット１（コントローラＭＣ）にレスポンスする。過去のユーザーの対話履歴がある場合にはその内容を加味した返答データが作成される。コントローラＭＣはこの返答データを音声データに変換しスピーカ装置１３からロボット１側の発話として出力させる。
上記のビルトインシナリオと同様に一定以上時間のユーザーの無言があれば待ち受けモードとなる。
『５．通常対話におけるリクエストとレスポンス における効果』
ビルトインシナリオと異なり外部のクラウドサーバーに接続して通常対話をすることで、ビルトインシナリオに比べて格段なデータ量による高度な対話解析が迅速に実行できることとなり、実際に人と対話しているような高度な対話が実現できる。

６．対話時のロボット１の所作について
コントローラＭＣは、ビルトインシナリオ又は通常対話に関わらず自然対話モードで対話が行われている際に以下のイ．～ニ．のような所作の制御を実行する。
イ．起動～自然対話モード～待ち受けモードにおけるロボット１のジェスチャー
コントローラＭＣはロボット１の以下の様々なタイミングで第１～第３のモータ２３～２５を制御してロボット１の姿勢を変えるようにする。以下は一例である。
１）起動時：頭部５の顔面部６が正面を向いていない場合や頭部５が傾いている場合に正面のデフォルト位置に移動させる。
２）画面タッチ時：１）と同様（顔認証における顔認識用カメラ１０をユーザーと正対させるため）
３）「ねぇユピ坊」というトリガーの発話発生時：１）と同様（顔認証における顔認識用カメラ１０をユーザーと正対させるため）
４）音声方向検出時：頭部５の顔面部６をその方向に向ける。
５）特別な感情発話として、例えばうれしい場合：頭部５を顔面部６をユーザーに向けたまま左右方向（時計回りと反時計回り）に回動するように第３のモータ２５を制御する。
６）特別な発話として、例えば悲しい場合：頭部５をうなずいたまましばらく静止させ、その後デフォルト位置に戻すように第２のモータ２４を制御する。
７）感情は発話として、例えば「おはよう」「こんにちは」「こんばんわ」「ハロー」のような挨拶用の発話発生時：頭部５をお辞儀させるように第２のモータ２４を制御する。
８）特別ではない感情発話として、例えば「そうか」「わかった」「そうだね」「うん！」のような簡単な肯定的な意思疎通の用語の発話発生時：頭部５をうなずかせるように第２のモータ２４を制御する。６～８）では第２のモータ２４の速度や時間を変更して悲しさとお辞儀とうなづきが異なるようにするとよい。
９）特別ではない感情発話として、例えば「いいえ」「できない」「だめだよ」のような簡単な否定的な意思疎通の用語の発話発生時：可動部３を何度か左右に回動させるように第１のモータ２３を制御する。
１０）特別な感情発話や特別ではない感情発話と様々な対話に応じて、様々なジェスチャー、例えば頭部５をなんどか左右方向（時計回りと反時計回り）にや前後に回動させたり、それと可動部３全体を左右に回動させたり、大きく回動させたり小さくうなづくように回動させたりを組み合わせてもよい。
このロボット１のジェスチャーは以下のタッチパネル部７（顔面部６）における表示と組み合わせるとよい。
『６．対話時のロボット１の所作について における効果その１』
ロボット１にこれらのようなジェスチャーをさせることで、ユーザーはロボット１に親しみを覚えることとなり、ロボット１との対話を楽しむと同時にロボット１と積極的に触れ合う楽しみを覚えることになる。

ロ．顔画面Ｓ１の状態での表示態様の変化
１）ユーザーから発話がされている場合
コントローラＭＣはユーザーの発話をマイクロフォン１２から取得してこれを認識すると、タッチパネル部７の図５に示すような顔画面Ｓ１において楕円領域２９を青色表示としてユーザーの発話音量に応じてその領域の面積（つまり大きさ）を変化させるアニメーション表示をする。具体的にはコントローラＭＣは、ユーザーの発話の音量が大きくなると楕円領域２９は楕円形状を保ったまま拡大させ、音量が小さくなると楕円形状を保ったまま縮小させる。また、ほっぺオブジェクト２８を緑色で表示させる。

また、コントローラＭＣは、クラウドサーバーからレスポンスされたユーザーの発話データ（文字列データ）を所定の態様でタッチパネル部７に表示させる。
例えば、図５に示すように、タッチパネル部７が顔画面Ｓ１の場合に、ユーザーからの例えば「こんにちは」という発話を取得すると、コントローラＭＣは顔画面Ｓ１のレイヤー画面にこの発話に基づく「こんにちは」という文字列を表示させる。順序としてはユーザーの発話の返答となるロボット１の発話よりも先にこの表示が開始される。
表示態様としては、例えば顔画面Ｓ１を図１０（ａ）から図１０（ｂ）のように透明な状態から徐々に不透明になるように表示させ、最後に図１０（ｃ）のように背後の顔画面Ｓ１を完全に隠すようにする。つまり、徐々に文字列を表示させていくようにする。この文字列だけを暗い背景に対して文字部分だけを明るく表示させた図１０（ｃ）の状態をごくわずかな一定時間停止表示させた後に、今度は逆に文字列を表示したレイヤー画面を図１０（ｃ）→図１０（ｂ）→図１０（ａ）というように徐々に消していき、デフォルト状態である顔画面Ｓ１に戻すようにする。このとき、一回の発話での文字列はすべて同時に現れてきて同時に消失していくように表示される。この表示態様は一例であり、異なる態様で表示させるようにしてもよい。
『６．対話時のロボット１の所作について における効果その２』
これによってユーザーは自分の発した言葉をロボット１上で目で見ることができるため、ロボット１が正しく聞き取ったかどうかを確認でき、対話が間違いなく行われているかを判断でき、おかしな的外れな対話にならないように対話を導くことができる。また、的外れな会話はついイライラしてしまうが、確認することでその理由もわかるため、しゃべり方を変えて再度対話を試みることもできる。
また、ユーザーの発話データはビルトインシナリオの対象も通常対話の対象もすべてクラウドサーバーに一旦文字列データすることをリクエストするため、文字列データ化の前提処理に手間取らず、また、このような文字列データ後に初めて対話エンジンによる返答データの作成がリクエストされることとなるため、ユーザーの発話のタッチパネル部７の表示は少なくともロボット１の返答データによる発話より前に行うことができ、対話の順序を間違うおそれがない。

ユーザーからの発話を文字列とする場合、その長さは発話に応じて異なるため同じではない。また、単語ではなく文節がある「文」となっている場合にはかなり長くなる場合もある。コントローラＭＣはそのように長い文の発話である場合でも、一回の発話の内容がタッチパネル部７にすべて同時に表示されるように文字列のフォントの大きさを調整する。つまり、一回の発話が短ければ大きなフォントで、一回の発話が長くなるほど相対的に小さなフォントで表示させる。
『６．対話時のロボット１の所作について における効果その３』
これによって、ユーザーがどのような発話をしても、一回の目視で確認できるため、全文が現れるまで対話を中断しにくく、次のユーザーからの発話とかぶりにくくなる。また、一回の発話が一度に同時に現れるため、文全体を一挙に理解できることとなり、表示される時間が短くともユーザーは十分理解できることとなる。また、タッチパネル部７全体に文字列が展開されるため、字の１つ１つを大きく表示できユーザーにとって見やすくなっており、ごく短い表示時間であっても十分確認できるようになっている。

２）ロボット１から発話がされている場合
タッチパネル部７の図５に示すような顔画面Ｓ１において楕円領域２９を赤色表示としてロボットの発話音量に応じてその領域の面積（つまり大きさ）を変化させるアニメーション表示をする。具体的にはコントローラＭＣは、スピーカ装置１３からの出力レベルが大きくなると楕円領域２９は楕円形状を保ったまま拡大させ、音量が小さくなると楕円形状を保ったまま縮小させる。また、ほっぺオブジェクト２８を薄い赤色で表示させる。
『６．対話時のロボット１の所作について における効果その４』
このように、ユーザーとロボット１との交互の対話に応じて顔画面Ｓ１における表示態様が異なることとなり、実際の対話だけでなく画面においても交互に行われるというおもしろさがあり、会話がはずむことになる。

ハ．チャット画面Ｓ２の表示態様の変化
図６及び図８に基づいてタッチパネル部７のチャット画面Ｓ２の対話に伴う表示態様について説明する。上記のようにユーザーの操作によって顔画面Ｓ１からチャット画面Ｓ２へと表示が変わる。
まず、改めてチャット画面Ｓ２の構成について説明する。
図６に示すように、チャット画面Ｓ２の左寄り下側位置にはアバターキャラクターとしてユーザーオブジェクト３１が、右寄り下側位置には同じくロボットオブジェクト３２が対向するように配置されて表示されている。ユーザーオブジェクト３１は後述する顔認識モードで認識された認証されたユーザー毎あるいは認証のないユーザにおいて異なるオブジェクトが用意され、現在対話しているユーザーに応じてそれぞれ異なるオブジェクトが表示される。中央寄り領域にはユーザー側とロボット１側の対話内容を文字列化して配置した吹き出しオブジェクト３３が時間軸に沿って順に表示されている。チャット画面Ｓ２の左寄り上側位置には対話停止ボタンオブジェクト３４が表示されている。チャット画面Ｓ２の右寄り上側位置には設定ボタンオブジェクト３５が表示されている。

チャット画面Ｓ２ではユーザー側とロボット１側の対話に応じて刻々と吹き出しオブジェクト３３が追加されるように表示される。吹き出しオブジェクト３３には文字列データ化されたユーザーの発話内容と、同じく文字列データ化されたロボット１の発話内容が時間軸に沿って一列に表示されてチャット画面Ｓ２上に表示可能とされ、直近の発話内容は新たな吹き出しオブジェクト３３内にその発話と同期して過去の吹き出しオブジェクト３３列の最も下側に表示される。
吹き出しオブジェクト３３はユーザー側の発話内容かロボット１側の発話内容かわかるように発話方向が示されている。すべての対話履歴を一度に画面表示できないためチャット画面Ｓ２は上下方向にスクロール可能な画面構成とされ、過去に遡って吹き出しオブジェクト３１を表示させることができる。過去に遡らない場合には常に直近の対話の吹き出しオブジェクト３３が表示される。
本実施の形態１では一旦対話が終了して待ち受けモードとなった後に、対話が再開され、その際に後述する顔認識モードで改めて認識されたユーザーが変更された場合には、吹き出しオブジェクト３３列の途中に「ユーザー交替」の表示がされ、ユーザーオブジェクト３１が改めて認識されたユーザーに応じて違うユーザーオブジェクト３１が表示される。

また、チャット画面Ｓ２の対話停止ボタンオブジェクト３４をタッチすることで、対話はユーザーによって能動的に中断され、待ち受けモードとなる。この場合には図６に代わって図８のチャット画面Ｓ２の待ち受け画面が表示されることとなるが、対話停止ボタンオブジェクト３４に位置には対話開始ボタンオブジェクト３６が代わって表示される。再び自然対話モードにする場合には対話開始ボタンオブジェクト３６をタッチすることで図６のチャット画面Ｓ２に戻ることができる。
『６．対話時のロボット１の所作について における効果その５』
このように対話する関係にあるユーザーのユーザーオブジェクト３１とロボット１のロボットオブジェクト３２とが対向するように配置され、その間に対話した吹き出しオブジェクト３３が並ぶことでいかにも対話しているような感覚をチャット画面Ｓ２から受けることができる。
また、過去のチャット履歴を後から確認することもできるため日記代わりにチャット利用をすることができる。また、だれがどのような対話をしたかもわかるため、家族でだれがよく利用しているか等といったデータを確認することもできる。「ユーザー交替」という表示がされるので、そこで一旦対話が途切れていることがわかり、過去の履歴を読んだ際の混乱がない。

ニ．通常対話における特別な所作
通常対話においてクラウドサーバーはユーザーの発話データ内に特定の言葉が含まれていると判断した場合に特別な所作を実行させるようなコマンドを文字列データとともにレスポンスする。コントローラＭＣはそのコマンドによって上記の画面表示プログラムやジェスチャープログラムや対話プログラムに基づいて、例えば次のような具体的な所作を実行させる。以下の制御は一例であり、他の所作となるように制御をさせてもよく、ユーザーの発話中にコマンドが複数あれば連続又は同時に所作を行うように制御してもよい。以下の特別な所作はそれぞれ別個でもよく、組み合わせるように実行されてもよい。上記の「６．対話時のロボット１の所作について」のイ．におけるロボット１のジェスチャーに代わって下記の表示部での表示をしてもよく、下記の表示部での表示を適宜組み合わせるようにしてもよい。

１）通常の人同士の会話で否定的な表現がユーザーから発話された場合には、ロボット１側の発話と同時にタッチパネル部７の表示を図９（ａ）の通常の目から図９（ｂ）の怒った目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
２）通常の人同士の会話で楽しくなるような表現がユーザーから発話された場合には、ロボット１側の発話と同時にタッチパネル部７の表示を図９（ａ）の通常の目から図９（ｃ）の笑った目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
３）通常の人同士の会話で悲しくなるような表現がユーザーから発話された場合には、ロボット１側の発話と同時にタッチパネル部７の表示を図９（ａ）の通常の目から図９（ｄ）の悲しそうな目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
４）ユーザーの子供の名前がユーザーから発話された場合には、ロボット１の頭部５がうなずくようなジェスチャー動作をするように第２のモータ２４を制御する。本実施の形態では目ジェスチャー用のプログラムはメモリに記憶されている。
５）ロボット１を製造している会社名がユーザーから発話された場合には、ロボット１の頭部５が前後左右に動くと同時に胴部４が固定部２に対してなんども揺動を繰り返すようなジェスチャー動作をするように第１～第３のモータ２３～２５を制御する。同時にその会社名のテキストデータを音声合成して、音声としてスピーカ装置１３から会社名を連呼させる。本実施の形態ではジェスチャー用のプログラムはメモリに記憶されている。
『６．対話時のロボット１の所作について における効果その６』
これらのような特別な所作が行われることで、ユーザーは対話と同時にロボット１の思わぬ所作を期待することができ、ロボット１との対話を積極的に楽しむことができる。

Ｂ．顔認識時の動作内容について
１．顔認識モードの開始と停止
コントローラＭＣは顔認識プログラムを実行することによってユーザーの顔の認識及び認証をする。顔認識プログラムでは取得した画像を顔パターン認識することによって人の顔と認識し、かつ認識された顔の様々な位置を数値化して記憶することで過去に登録された顔の数値データとの一致度を判断して認証を行う。コントローラＭＣは自然対話モードと同期して顔認識モードとし、待ち受けモードから自然対話モードに移行する度に顔認証を実行する。

顔認識モードではコントローラＭＣは顔認識用カメラ１０を使用してユーザーの顔認識を行う。具体的には、
１）顔認識用カメラ１０を起動させる。顔認識用カメラ１０に写ったユーザーの顔画像をタッチパネル部７に表示させる（顔表示モード）。つまり、ユーザーにタッチパネル部７上の自分の顔を見るように促す。これによって顔認識処理が可能となり、このようにプレビューさせることで過去に認証された人かどうかを判断できる。
２）１）で顔認識用カメラ１０が顔を撮影できず、一定時間内に顔認識ができなかった場合には、第３のモータ２５を駆動させて頭部５を上下に揺動させる。つまり顔認識用カメラ１０に縦方向をスキャンさせる。そして、そのように顔認識用カメラ１０を縦方向にスキャンさせながら第１のモータ２３を駆動させて顔認識用カメラ１０を３６０度一周回転させながら顔認識動作をさせる。
３）１）又は２）で顔認識できた場合には認証を行う。既に登録されたユーザーであれば対話において特定の認証されたユーザーのデータを利用して上記自然対話モードとする。登録されていないユーザーであれば不特定の人物として認識して上記自然対話モードとする。タッチパネル部７は顔表示モードから直前の顔画面Ｓ１（図５）かチャット画面Ｓ２（図６）のいずれかに復帰する。
４）２）において顔認識ができなかった場合には人を認識できなかったとして顔認識モードとともに自然対話モード自体を終了させて待ち受けモードとする。タッチパネル部７は顔表示モードから直前の待ち受けモードである顔画面Ｓ１の待ち受け画面（図７）かチャット画面Ｓ２の待ち受け画面（図８）のいずれかに復帰する。
『１．顔認識モードの開始と停止 における効果』
対話は相手の顔を見ながら話すのが基本であるため、顔が認識できない場合には対話をさせないことで、積極的にユーザーに顔認識をさせるようにしたため、対話においてはロボット１と実際に面と向かわないと対話はできず、そのためユーザーは実際に対話をしているような感覚を得ることができる。

２．顔認識時のロボット１の所作について
１）顔認識後においてはコントローラＭＣは顔認識用カメラ１０に画像を取得させて一定のタイミングで常時顔パターン認識を実行する。そして、顔認識用カメラ１０の画角内でユーザーの顔を認識し、画角内の所定の位置、例えば画角中央の原点にユーザーの顔の２つの目の中央位置Ｃがある状態をデフォルト位置とする。コントローラＭＣはこのデフォルト位置から中央位置Ｃがずれた場合に、そのずれ量に応じて左右いずれかのずれ方向に瞳オブジェクト２７ａが移動するようなアニメーション表示をさせる。通常、瞳オブジェクト２７ａは、例えば図９（ａ）のように目オブジェクト２７の中で白目内に楕円形状として全体が現れているが、ユーザーの顔が移動しているある状態では図１１に示すように瞳オブジェクト２７ａはあたかもその方向を見ているように一部が隠れた目オブジェクト２７として表示されることとなる。
ユーザーが動いて顔認識用カメラ１０の画角から顔が出てしまい顔認識できなくなった場合には、コントローラＭＣは第１のモータ２３を駆動させ、中央位置Ｃがずれた方向に可動部３全体を回動させて顔認識用カメラ１０を向けるよう制御する。顔認識がされた段階で第１のモータ２３の駆動を停止させる。ある程度の回動、例えば可動部３全体を４５度回動させても顔認識がされない場合には、その段階でコントローラＭＣは第１のモータ２３の駆動を停止させ、その状態で常時顔パターン認識を継続する。
『２．顔認識時のロボット１の所作について における効果』
これによって、ユーザーはロボット１にいつも見られながら対話をしているような感覚になり、対話のおもしろさが増すこととなる。

２）コントローラＭＣは顔認識用カメラ１０で常時顔パターン認識を実行するが、ユーザが動いていたり顔認識用カメラ１０の画角内にいなかったりする場合には顔認識ができない。そのため、顔認識状態を画面上の変化としてユーザーに報知することがよい。実施の形態１では、瞳オブジェクト２７ａ内部の瞳上での反射を表現した鎌状の反射オブジェクト２７ｂの色の濃さの変化で顔認識状態を報知するようにしている。本実施の形態１では、コントローラＭＣは認識されていない場合にはごく薄い青色で表示させ、認識中である状態ではそれより濃く、通常の顔認識されている状態では濃い青色で表示させる。
『２．顔認識時のロボット１の所作について における効果その２』
これによって、ユーザーはロボット１に顔認識されているかいないかが容易にわかるため、積極的に顔認識するようにユーザーは協力するようになり、円滑な対話が進むこととなる。

Ｃ．留守設定時の動作について
実施の形態１では留守設定モード、つまり留守設定時に登録したｅメールに対して画像の転送が可能である。留守設定モードは本実施の形態１ではユーザーがロボット１のチャット画面Ｓ２の設定ボタンオブジェクト３５をタッチした後に表示される設定画面において設定とその解除がされる。以下では留守設定モードがされている場合のコントローラＭＣの留守設定時プログラムに基づく処理について説明する。
コントローラＭＣは、留守設定モードにおける上記の「２．自然対話モードの開始と停止」におけるＢ．の４）での待ち受けードにおいて、ドップラーセンサ２２によって物体（人）が動いていると判断すると以下のように制御する。

１）コントローラＭＣは、ロボット１の周囲になんらかの動く物体が存在することで、この状態をユーザーにｅメールによって報知をする。コントローラＭＣはインターネット回線を通じてｅメールアドレスが登録されているロボット１の近くにいないユーザー（以下、外部ユーザーとする）の端末装置、例えばスマートフォンに対してロボット１のクラウドサーバーのＵＲＬをｅメールに記載して送る。ｅメールの件名や送信文中にこの報知の意図のわかるような表現を表記をする。例えば「誰かが来ているようです」のような文章やそれを意味するようなアイコン等である。
『Ｃ．留守設定時の動作について における効果』
これによって、まずｅメールが送られて来たことによって外部ユーザーはなんらかのロボット１周囲に物体（人）が動いる状態が報知されて認識することができ、この状態に対して外部ユーザーに対策をとる機会が与えられることとなる。

２）コントローラＭＣは、外部ユーザーにｅメールを送信すると同時に顔認識用カメラ１０を起動させて画像を取得する。
３）コントローラＭＣは、外部ユーザーにｅメールを送信すると同時に、一定時間内にあるトリガーとなる発話があるかどうかを判断する。例えば「ただいまユピ坊」のような挨拶の発話である。この発話に基づいて自然対話モードにおけるビルトインシナリオが開始され、ユーザー（ここでは「ただいまユピ坊」を発話したロボット１の近くにいる者）に顔認証を促す。コントローラＭＣは顔認証の結果、登録されているユーザーの一人であると判断した場合に、外部ユーザーの端末装置に対して二回目となるｅメールを送信する。このｅメールはロボット１の周囲にいる者は不審者ではないという外部ユーザーに対する情報となる。つまり、二回目のｅメールは例えば家族のような関係者であることを報知するものとなる。ｅメールには登録情報に基づいて登録されているユーザーの名前を情報として件名や送信文中に表記する。尚、トリガーとして発話以外の、例えばタッチパネル部７にタッチして顔認識し、登録ユーザーであることを確認してもよい。
『Ｃ．留守設定時の動作について における効果その２』
これによって、留守中に例えば子供等の家族が帰ってきた場合には、この二回目のｅメールによってその旨がわかるため、わざわざスマートフォン経由で留守中の家の様子を確認する必要がない。

４）１）において、ｅメールを受信した外部ユーザーは、特に３）において二回目のｅメールの送信がなかった場合に、ロボット１のＩＤとパスワードを入力してクラウドサーバーに接続し、スマートフォンのブラウザ上でクラウドサーバーが提供する顔認識用カメラ１０のカメラ画像をリアルタイムで見ることができる。二回目のｅメールの送信があってもそれは可能である。
図１２はユーザーのスマートフォン４１の一例であり、クラウドサーバーに接続後においてはタッチパネルを兼ねたその表示画面４３上に顔認識用カメラ１０の所定のカメラ画像が表示される。カメラ画像内には顔認識用カメラ１０の向きを遠隔操作するための４つの操作アイコン４４ａ～４４ｄが表示される。外部ユーザーは操作アイコン４４ａ～４４ｄを操作することで制御コマンドがクラウドサーバーを介してコントローラＭＣに出力され、制御コマンドに基づいて第１のモータ２３又は第３のモータ２５が駆動制御されてロボット１の頭部５と胴部４が回動して顔認識用カメラ１０の向きを変えることができる。また、録画ボタンアイコン４５にタッチすることで、録画を開始し再度タッチすることで録画を停止することができる。
また、スマートフォン４１の図示しないマイクロフォンに発話した音声データはクラウドサーバーを介してロボット１のスピーカー装置１３から音声出力され、一方でロボット１のマイクロフォン１２から発話した音声データはクラウドサーバーを介してスマートフォン４１の図示しないスピーカー装置から音声出力される。そのため、外部ユーザーは顔認識用カメラ１０の画像を見ながらロボット１近傍のユーザーとスマートフォン４１とロボット１を使用した対話をすることができる。
『Ｃ．留守設定時の動作について における効果その３』
これによって、外部ユーザーは遠隔操作で顔認識用カメラ１０の向きを変えてロボット１の周囲の状況を確認することができ、例えば留守の際の自宅の安全状況をチェックすることができる。また、留守中に子供等の家族が帰ってきた場合でもこのようにスマートフォンを使用して積極的に外部から連絡することで家族を含めた他者との良好な関係に寄与する。

＜実施の形態１の変形例１＞
次に、実施の形態１の変形例１について説明する。
上記自然対話におけるビルトインシナリオの対話において、ユーザーの滑舌が悪かったり、他の音が混ざってしまいマイクロフォン１２から取得した音声データがビルトインシナリオの正規表現又は非正規表現に合致しない場合には、コントローラＭＣは直ちに通常対話であると判断することなくユーザーに再度の発言を促すための発話として、例えば「もう一度言って下さい」というような音声出力をさせるようにしてもよい。
コントローラＭＣは、このような促しの発話をスピーカ装置１３からさせ、これに対して一定の時間内にユーザーからビルトインシナリオに沿った正しい発話がされた場合には再びビルトインシナリオの対話として処理するようにする。一方、このような場合でもユーザーの発話がビルトインシナリオに正規表現又は非正規表現に合致しない場合に外部のクラウドサーバーに接続させるようにする。
このようにすれば、無駄に外部のクラウドサーバーに接続させるようなことがなく、ロボット１の内部のみで対話を行うことができる。

＜実施の形態１の変形例２＞
次に、実施の形態１の変形例２について説明する。
上記自然対話においてユーザーがロボット１の言葉（発話）を聞き逃した場合、一定の時間内であれば直前のロボット１の発話を繰り返すような依頼の発話をユーザーが発話することで再度ロボット１に発話（音声出力）させるようにしてもよい。この処理はビルトインシナリオの対話でも自然対話でもいずれでも可能である。
コントローラＭＣは対話モード中において聞き逃しのトリガーとなるような発話、例えば「もう一度言って」という発話があったかどうかを音声認識する。そして、ロボット１からの発話後にユーザーから発話を繰り返す依頼があったと判断すると、直前にロボット１が発話した内容を再度音声出力する。そして、先の発話をしたことはキャンセルして、二回目の発話をもって一回目の発話として処理する。
このようにすれば、ユーザーが対話途中で聞き逃したりした場合でも対話が途切れることなく再開されることとなる。

＜実施の形態１の変形例３＞
次に、実施の形態１の変形例３について説明する。
上記自然対話においてロボット１がタッチパネル部７に表示させたユーザーの発話をユーザーが確認して、間違って音声認識されたことがわかった場合には、一定の時間内であればそれを指摘して正しい対話に修正することができるようにしてもよい。この処理はビルトインシナリオの対話でも自然対話でもいずれでも可能である。
コントローラＭＣは対話モード中において、ユーザーからの音声認識が間違っている旨の指摘となるトリガーとなるような発話、例えば「間違えているよ」や「違うよ。もう一度いうよ」というような発話があったかどうかを音声認識する。そして、コントローラＭＣはその発話がユーザーの発話をタッチパネル部７に表示させた後の一定時間内にあったと判断すると再度のユーザーの発話を促す音声出力をする。例えば「ごめんね。もう一度言って」という発話内容を音声出力する。
そして、
（１）ビルトインシナリオの対話の場合には直前のユーザーの発話はキャンセルされ、再度ユーザーが発話する内容が正しい発話として音声認識処理される。
（２）通常対話では上記の「間違えているよ」や「もう一度いうよ」という対話内容も外部のクラウドサーバーに発話データ（音声データ）として送信され、そのような発話も含め再度ユーザーが発話した内容で返答データの作成をリクエストする。
このようにすれば、ロボット１が間違ってユーザーの発話を認識した場合でも正しい対話に修正することができる。

＜実施の形態１の変形例４＞
実施の形態１の構成とは異なる例えば次のような構成を採用するようにしてもよい。
（１）上記ではビルトインシナリオが実行されない場合にクラウドサーバーにリクエストして通常対話に移行するような設定であった。つまり、ビルトインシナリオが実行されるのであれば、すべてビルトインシナリオとするような設定であったが、敢えてビルトインシナリオに対応する場合でもある条件でローカルで対応をせずにクラウドサーバーにリクエストするようにしてもよい。ある条件とは例えば何回かに一回の回数や、ランダムなタイミングで実行することがよい。
これによって、ロボット１と予測されない対話をすることとなり、決まり切っていないより人間的な対話ができることができる。
（２）上記実施の形態１ではコントローラＭＣは音声認識エンジンを備えず、音声認識エンジンを備えた外部のサーバーに接続してユーザーの発話（音声データ）をテキスト化するようにしていた。それによってロボット１の負担が軽減されている。
しかし、コントローラＭＣは、メモリ内に音声認識エンジンを備えるようにし、音声認識エンジンを呼び出してマイクロフォン１２から取得したユーザーの発話データ（音声データ）を音声認識エンジンを使用して自身でテキスト化した文字列データを作成するようにしてもよい。つまり、ロボット１のコントローラＭＣは自らユーザーの音声データをテキストデータ化する能力を有していてもよい。これによって、音声認識エンジンを使用せずに文字列データを作成できることとなって、例えば内部の処理時間が短くなる。
（３）上記実施の形態１では設定画面から初期設定するようにしていたが、例えばスマートフォンのような端末装置を使用して外部からクラウドサーバー経由で登録するようにしてもよい。その方が特に端末装置を使い慣れた人には設定が容易で時間の短縮となる。
（４）第１～の第３モータ２３～２５はサーボモータ以外の他の駆動手段を使用するようにしてもよい。他の駆動手段とは、例えば他の形式のモータや油圧シリンダ等である。
（５）上記実施の形態１では文字列データをロボット１内部で音声合成するようにしていた。このように内部の音声合成エンジンを用いることはそのまま音声データをサーバーとやり取りするよりデータが重くなりすぎずによいが、クラウドサーバー側で対話エンジンを使用して取得した返答データ（文字列データ）を音声合成し、その音声データをロボット１にレスポンスするようにしてもよい。
（６）上記実施の形態１ではチャット画面Ｓ２の設定ボタンオブジェクト３５から設定画面に移行するような構成であったが、タッチパネル部７をスライド操作することで設定画面に移行ようにしってもよい。

（７）「ハ．通常対話における特別な所作」においてはビルトインシナリオにおいても同様にユーザーの発話データ内に特定の言葉が含まれていると判断した場合に特別な所作を実行させるようにしてもよい。例えばコントローラＭＣはユーザーの発話データ内に特定の言葉が含まれていると判断すると上記と同様に特別な所作をさせるように制御してもよい。
（８）「ハ．通常対話における特別な所作」においてロボット１の形状が異なれば更に異なるジェスチャーをさせるように制御してもよい。例えば、コントローラＭＣはロボット１に手や足があればそれらを駆動手段を制御して動かすようにしてもよい。
（９）顔画面Ｓ１の目オブジェクト２７のアニメーションとして、ときどき、瞬きさせるようなアニメーションを入れてもよい。例えば図９（ａ）の目オブジェクト２７の状態から図７の閉じた状態の目オブジェクト２７を挿入するような制御とすることで実行させる。そのようにすれば、ロボット１が実際に本当にこちらを見ているようなリアル感が創出されることとなりロボット１との対話をより楽しむことができる。
（１０）顔認識モードでは、登録されていないユーザーであれば不特定の人物として認識するようにしていたが、その状態から設定画面に移行して新たな別のユーザーとして認証登録するようにすると、便利である。
（１１）「Ｃ．留守設定時の動作について 」において、留守設定モードをスマートフォンから設定できるようにすると便利である。
（１２）「Ｃ．留守設定時の動作について 」において、コントローラＭＣは、ロボット１の周囲になんらかの動く物体が存在することで、この状態をユーザーにｅメールによって報知をするような処理をするが、逆に一定間隔で動いていることを認識し、一定時間内に動く物体がない場合にこの状態をユーザーにｅメールによって報知をするような処理を設けてもよい。
例えば、病人や介護対象者がある場合にその近くにロボット１を置くことで常に動きがあることを前提とした見守りをすることができる。

＜実施の形態２＞
次に、実施の形態２について説明する。
上記実施の形態１のロボット１の高輝度白色ＬＥＤ９に変えて、あるいはこれに併設した赤外線ＬＥＤを備えるようにしてもよい。この際に顔認識用カメラ１０のモジュールに赤外線フィルタが備えられていれば取り外す。赤外線ＬＥＤは人には見えないため、夜間の空き巣等の侵入者があった場合に、高輝度白色ＬＥＤ９が点灯することで驚いて侵入者に逃げられてしまう可能性がある。一方、赤外線ＬＥＤであると撮影されていることがわかりにくいので侵入者は逃げず、そのため侵入の画像を確認したり、保存したりすることが可能となる。

＜実施の形態２の変形例１＞
次に、実施の形態２の変形例１について説明する。
ロボット１が赤外線ＬＥＤを備えた場合に、この赤外線ＬＥＤを利用して赤外線リモコン信号受信部を備えた室内の各種装置の制御をするようにしてもよい。各種装置としては、例えばテレビ、オーディオ装置、エアコン装置等がよい。
ロボット１は赤外線リモコン信号受信部を備えた装置の赤外線リモコン信号受信部を直接見通せる場所に設置することがよい。実施の形態２の変形例１ではコントローラＭＣは顔認識用カメラ１０を使用した形状認識に関する形状認識プログラムを備えており、例えばテレビであればその形状の特徴（四角、大きい、黒い等）に基づいて認識することができる。ロボット１はユーザーの各種装置へ赤外線リモコン信号を出力するためのトリガーとしての例えば「テレビのスイッチ付けて」のような発話があると、その発話に基づいて第１のモータ２３又は第３のモータ２５を制御してロボット１を顔認識用カメラ１０を上下に顔５を首振りさせながら、３６０度回転させて周囲を撮影させ、形状認識プログラムによってテレビの形状を認識させるように動作させる。
コントローラＭＣがテレビがあると判断すると、その方向を記憶させると同時に赤外線ＬＥＤからその物体方向に赤外線リモコン信号を出力させて、テレビを動作させるＯＮ・０ＦＦ等の制御を実行させる。次のテレビについてのトリガーがあった際にはまず、その方向において形状認識を実行する。赤外線リモコン信号は単にＯＮ・０ＦＦのスイッチング制御だけではなく、例えばテレビであればチャンネルの変更、例えばエアコンであれば温度調整等にも対応するように赤外線周波数を変更して制御することが可能となる。このような細かな制御では複数種類の周波数の異なる赤外線リモコン信号が必要となるが、赤外線の周波数の設定は、例えば図１２はユーザーのスマートフォン４１を使用してサーバー経由で行うようにするとよい。
また、形状認識プログラムによって方向を探さなくとも、スマートフォン４１経由で顔認識用カメラ１０を操作してその向きを変えることで各種装置の方向を取得し、その方向を登録するようにしてもよい。

＜実施の形態３＞
次に、実施の形態３について説明する。
実施の形態３では音声認識エンジンを搭載したサーバーを使用する際の例えば対話ＡＰＩの利用等の接続に伴うランニングコストを削減することを主眼とした制御について説明する。
また、実施の形態３の対話プログラムはマイクロフォン１２から取得した音声の無音状態を検知できるサブプログラムを含んでいる。また、対話プログラムはユーザーの発話の音声データをマイクロフォン１２から取得して一旦録音し、サーバーに出力させるための録音・出力サブプログラムを含んでいる。
コントローラＭＣは発話があった場合には直ちにサーバーに接続させず、ユーザーの発話の音声データをまず一旦録音し、録音したユーザーの発話の音声データの無音状態を検出した段階で初めてサーバーに接続してその録音した音声データを出力し、対話エンジンでの返答データを作成させるようにする。このようにすれば常にサーバーに接続されているわけではなく、無音時間を含んだ長時間をサーバーに接続する必要がないため、無音の接続時間をカットすることができる。
音声認識エンジンはユーザーの発話中において１つのプロセスがそのユーザーに専有されることとなる。つまり、1つの処理に「何秒」というコンピュータとしては非常に長い時間が専有されることとなり、結果として音声認識エンジンを使用するユーザーのコストの負担が大きくなってしまうが、実施の形態３のようにすれば単位ユーザー当たりに必要なプロセスを減らすことができ、ユーザーのコスト削減に寄与する。

＜実施の形態３の変形例１＞
次に、実施の形態３の変形例１について説明する。
実施の形態３の変形例１でも音声認識エンジンを搭載したサーバーを使用する際の接続のランニングコストを削減することを主眼とした制御について説明する。ユーザーの発話が開始されるまでにタイムラグが発生することや、ユーザーの発話待ちの状態で結局ユーザーが発話せずタイムアウトでサーバーとの接続を終了する場合があると、音声認識サーバーはプロセスを消費してしまうのでユーザーのコストがかかってしまう。
実施の形態３の変形例１のロボット１の対話プログラムは発話の音声データをマイクロフォン１２から取得して一旦録音し、サーバーに出力させるための録音・出力サブプログラムを含んでいる。また、対話プログラムには録音された音声データの音圧レベルを検出し、出力するサブプログラムを含んでいる。
コントローラＭＣは自然対話の状態で常時録音されている音声データが一定音圧以上のである場合にサーバーに接続させ、録音中のデータを追っかけ再生するようにする。つまり、無音、あるいは音声認識ができないような小さな発話を無視し、対話可能な発話があった場合だけサーバーに接続して音声データを出力し、サーバー側に音声認識エンジンで返答データを作成させるようにする。
これによって、発話待ちの無駄な接続時間をなくすことが可能となる。

＜実施の形態４＞
次に、実施の形態４について説明する。
音声認識サーバーは高価であるため、あらかじめ十分なリソースを用意することができないことがあり、サーバーリソースに余裕がない場合、端末が音声認識サーバーに接続しようとした場合にサーバーがビジー状態であることがある。
上記通常対話においては、サーバーに発話データ（音声データ）を送信し返答データの作成をリクエストする。とサーバーは発話データに基づいて文字列データ化された返答データを作成してレスポンスする。ところが、ビジー状態であると返答データがされず、エラーになってしまうことがある。サーバーからエラーメッセージが返信されることとなる。
ロボット１のコントローラＭＣはサーバーからエラーメッセージの送信を受けた場合にサーバー接続エラーである旨の発話をユーザーにせずに、ビルトインシナリオから対話を続けられるような返信を音声出力するようにする。例えば「もう一度言って」とか「うんうん」とか「なんだっけ？」というような曖昧な返答したり、適当な相槌を返すなどしてサーバーが空くのを待つ処理をするとよい。

＜実施の形態４の変形例１＞
次に、実施の形態４の変形例１について説明する。
ユーザー側の発話が長すぎると、音声認識エンジンが誤認識をする可能性がある。そのため、認識したユーザーの発話が長すぎると判断した場合に、音声認識エンジンを備えるサーバーに接続することなく記憶手段に記憶された音声データから選択された対話例を音声出力する機能を備えることがよい。
ロボット１のコントローラＭＣは、ユーザーの発話データが一定以上の長さになったと判断した場合には、サーバーに接続させることなくビルトインシナリオから「うん」とか「マジ？」とか「本当ですか？」などという対話においてどのようにも取れる相づちのような発話を音声出力する。発話データは音声データのままでもよく、コントローラＭＣあるいはサーバーで文字列データに変換された後のものでもよい。
これによって的外れな言葉が返ってくることを防止し、対話を仕切り直しして改めてユーザーに対話を促すようにすることができる。

＜実施の形態５＞
次に、実施の形態５について説明する。
実施の形態５では複数の音声認識エンジンを組み合わせて利用する場合について説明する。
音声認識エンジンにはローカル（つまり、ネットサーバーに接続せずに装置内で処理する場合）の音声認識エンジンと、ネットサーバーに接続してリクエストによって作成した対話データをレスポンスするクラウドの音声認識エンジンがある。ローカルにもクラウドにもそれぞれ複数種類の音声認識エンジンがあり、無料のものも有料のものもある。そのため、これら異なる音声認識エンジンを備えるサーバーを利用する際に料金が無料のサーバーと有料のサーバーをミックスして利用するようにする。
ロボット１がインターネット回線を利用して接続されるクラウドサーバーでは、対話モードにおいて、ロボット１から発話データがリクエスト発行され音声認識エンジンに返答データを作成させる際に、例えばクラウドサーバーは次のように対応することがよい。
（１）月あたり設定したある時間Ａまでは有料の対話ＡＰＩにアクセスする。
（２）月あたり設定したある時間Ａからある時間Ｂまでは有料のＡＰＩと無料の音声認識エンジンを混ぜて使う。例えば最初の連続数回の認識は有料の音声認識エンジンのサーバーを使いその後の連続した認識には無料の音声認識エンジンのサーバーを使うなどミックスして使う。
（３）月あたり設定したある時間Ｂを超えた場合、無料の音声認識エンジンのみを使う。 これは一例であって、例えば月あたり設定したある時間Ａを越えた場合に直ちに無料の音声認識エンジンのみを使うような設定でもよい。
このようにすれば、有料の範囲を大きく越えずに対話をすることができる。ロボット１と接続されているクラウドサーバーがこのような処理を実行するプログラムに基づいて有料と無料とを月あたり設定した時間に基づいて計算してロボット１からのリクエスト発行を処理する。
ロボット１自体がこのような処理を実行して、リクエスト発行の際にクラウドサーバーに対して有料の対話ＡＰＩを使用するか、無料のサーバーの音声認識エンジンを使用するかの命令をするようにしてもよい。
＜実施の形態５－１＞
実施の形態５の複数の音声認識エンジンを組み合わせて利用する場合は複数の対話エンジンを組み合わせる場合についても同様である。

＜実施の形態６＞
次に、実施の形態６について説明する。
ある１つの決まった対話エンジンを使うだけでは、返答がきまったパターンになってしまいユーザーがロボット１との会話に飽きてしまう可能性がある。そのため、実施の形態６ではこれを解消するため複数の対話エンジンの出力の結果を用いて会話に飽きないようにその結果をアレンジするための処理を説明する。
対話エンジンはクラウドの対話エンジンだけではなく、ロボット１内のローカルな対話エンジンを使用してもよい。
この処理は複数の返答データを送信されたロボット１側で行ってもよく、対話エンジンを備えたいくつものサーバーからの返答データを取得した際にクラウドサーバー側で行ってもよい。
（１）雑談対話エンジンのうち文字列の文字数の最も長い返答をしてきたエンジンの結果を出力する。
最も長い返答とすると、いかにも対話しているように感じ、対話の単調さがなくなり、ユーザーは対話を楽しむことができる。
Ａ．例えば、「腹減った」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：よく間食をしますか?」「ｂエンジン：ご飯食べてないの？」「ｃエンジン：なんか食え」である場合に、ａエンジンを採用してその返答データを出力する。
Ｂ．例えば、「今日の天気は晴れ」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：今すぐお空に行って確認してきます」「ｂエンジン：快晴っぽい？」「ｃエンジン：晴れか雨かで、その日の気分が決まることがあるよね。」である場合に、ｃエンジンを採用してその返答データを出力する。

（２）雑談対話エンジンのうち、語尾に「？」がついているものを最後に持ってきて出力する。このとき「？」がついている回答が複数あればそれらを連続して出力する。
語尾に疑問符がつくと、その疑問に更に答えるような話の流れになるため、会話が続きやすくなりユーザーは対話を楽しむことができる。
例えば、上記（１）Ａ．の選択肢では「よく間食をしますか?ご飯食べてないの？」と出力する。また、上記（１）Ｂ．の選択肢であれば「快晴っぽい？」と出力する。
（３）肯定文を組み合わせた後、疑問文を組み合わせて出力する。
このようにアレンジすることでいかにも考えて文章を練ったような応答になるため、ユーザーは真剣に自身の発話を聞いてもらっているような感覚となり、続けて会話をしたいと思うようになるため、会話が続きやすくなりユーザーは対話を楽しむことができる。また、出力尺をかせぐことができるとともに人への返答を求めることができる。
例えば、上記（１）Ｂ．のような返答データが取得された場合「今すぐお空に行って確認してきます。晴れか雨かで、その日の気分が決まることがあるよね。快晴っぽい？」出力する。

（４）他よりも話題の転換をより頻繁にしてくるエンジンからの結果を、他のエンジンの結果よりも後に持ってきて出力する。
このようにアレンジすることで話題転換したことで次の発話を誘うような対話となり、対話が続きやすくなる。
Ａ．例えば、「どーもどーも」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：だょね～」「ｂエンジン：そうですね」「ｃエンジン：野球は見たりしますか？」である場合に、ｃエンジンのデータを最後にして「だょね～ そうですね 野球は見たりしますか？」と出力する。
Ｂ．例えば、「なかなか見つからないね」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：その通りですね」「ｂエンジン：あるあるー」「ｃエンジン：ご家族は何人ですか？」である場合に、ｃエンジンのデータを最後にして「その通りですね あるあるー ご家族は何人ですか？」と出力する。
（５）他よりもよりフレンドリーな返答をしてくるエンジンをまず真っ先に出力して、その後に他のエンジンからの返答をくっつけて出力する。
このようにアレンジすることでユーザーが対話に引き込まれやすくなり、対話が続きやすくなる。フレンドリーかどうかは言葉（単語）に相対的な序列化をすることでどの位置に配置するかを決定することができる。
Ａ．例えば、上記（４）Ｂ．の場合ではｂエンジンの結果を最初にして「あるあるー その通りですね ご家族は何人ですか？」と出力する。
Ｂ．例えば、「なるほどね」とユーザーが発話した場合に、ａ～ｂの２つのエンジンからの回答が「ａエンジン：あら適当な相槌ですね」「ｂエンジン：うむ」である場合に、ｂエンジンのデータを最後にして「ほほほー あら適当な相槌ですね うむ」と出力する。

（６）（１）～（５）の処理を任意に組み合わせる
これによって、対話のバリエーションが増えることとなるため、ユーザーが同じ発話をした場合でもまったく同じ応答が帰ってきてしまうことがなくなり、対話に飽きることがなく対話が続きやすくなる。
例えば「老後って何」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：ちょっと待ってくださいね」「ｂエンジン：サポートは嫌いじゃないよ」「ｃエンジン：今健康でいらっしゃいますか？」である場合に、最もフレンドリーなｂエンジンを最初にし、肯定文を組み合わせた後、疑問文を組み合わせ、「サポートは嫌いじゃないよ ちょっと待ってくださいね 今健康でいらっしゃいますか？」と出力する。

（７）テキスト出力用の場合のエンジンでは、カッコや顔文字が帰ってくることがあるため、これらが帰ってきた場合には音声出力を抑制して出力する。そして画面にはそれらは表示させる。
顔文字は音声出力できないが、表示部に敢えて顔文字を表示させることで、音声と併せて対話の一部とすることで通常にはない対話のおもしろさを創出することができる。
Ａ．例えば、「腹減った」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：(わざと無視)」「ｂエンジン：こんにちはお元気ですね」「ｃエンジン：こんにちは」である場合に、ａエンジンだけは音声出力させず、タッチパネル部７（表示画面）に表示させるようにする。
Ｂ．例えば、「元々入ってる」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：あなたはよくするんですか?「ｂエンジン：(´・ω・｀)」「ｃエンジン：夜型さんですか？」である場合に、ｂだけは音声出力させず、タッチパネル部７（表示画面）に表示させるようにする。
（８）同じ文字列が含まれる返答についてはいずれか１つを出力する。
同じ文字列が繰り返されると対話がくどくなってしまうし、聞き手に違和感を覚えさせてしまうためである。
例えば、「中華」とユーザーが発話した場合に、ａ～ｃの３つのエンジンからの回答が「ａエンジン：あらっいいですねぇ」「ｂエンジン：うん、中華です。」「ｃエンジン：中華を食べに行くんでしょうか？」である場合に、ｂエンジンとｃエンジンには「中華」の文字列があるためいずれか一方のみ出力する。例えば「あらっいいですねぇ 中華を食べに行くんでしょうか？」のように出力する。

（９）語尾変換手段、例えば語尾変換ＡＰＩを使って統一感を出すようにする。このときすべての返答について語尾変換を行ってもよいが、最後に出力する文か最初に出力する文のいずれか一方にのみ語尾変換を行うようにしてもよい。
普通の対話エンジンの文章に比べて、より親しみやすい表現となるのでよい。
例えば、あるエンジンから「ねむいな」と返答データがあった場合に語尾を語尾変換ＡＰＩによって変換させて「ねむいニャ」というように出力する。
（１０）認識失敗に備えて、複数のエンジンから得た返答のうち一部のみを音声出力に利用し、残りの返答は保持しておき、次の音声認識に失敗したときや対話システムからの返答がなかったときは、その保持しておいた返答を返すようにする。
音声認識が失敗した場合や、外部サーバーからのレスポンスがなかなか来ない場合に使用することで、対話が途切れずにつなげることができ、自然な対話に寄与する

＜実施の形態７＞
図１４に示すように、実施の形態７はロボット１の近傍にスマートスピーカ５１を配置し、ロボット１とスマートスピーカ５１を組み合わせた装置（システム）である。ロボット１とスマートスピーカ５１の間隔は互いのマイクロフォンで音が拾える程度の距離であって例えば１～２ｍ以内に隣接配置されることがよい。
スマートスピーカ５１は無線ＬＡＮ装置を内蔵し、インターネットを使用した無線通信機能、電話回線接続機能等を有しネットワークモジュールが搭載されたネットワーク端末であり、マイクロフォンとスピーカ装置を備えた一種のコンピュータでもある。スマートスピーカ５１はスマートフォンのような端末装置を利用してサーバーを介して各種初期登録（例えば、使用者の名前、住所、電話番号、メールアドレス登録、複数の音声登録、ブルトゥースによるネットワーク対応のＡＩ機器の設定等）を実行し、音声登録した使用者からの発話（命令）によってインターネットに接続してサーバーの検索エンジンを使用して所定の処理を実行し、その結果をスピーカ装置から音声情報として出力する。

ロボット１はスマートスピーカ５１と連携することで互いの機能を補うことができる。具体的にはロボット１とスマートスピーカ５１とを音声をインターフェースとして次のような機能を奏する。
（１）スマートスピーカ５１へのロボット１からの指示機能
イ．例えば、ユーザーがスマートスピーカのスキルを起動するフレーズを喋ったとき、ロボットはそのフレーズの音声認識結果の文字列を記憶しておき、ロボットは自らその文字列を音声合成で所定のタイミングで喋るようにする。
実施の形態７ではロボット１のコントローラＭＣは、ユーザーの発話を周波数成分を分析して個人の声を識別する声識別プログラム、ユーザーの発話を個人毎に区別して舞う頃フォン１２によって取得し、文字列データとして記憶させ、その文字列データに基づいて音声合成してスピーカ装置１３から再生させるフレーズを録音・再生プログラムを備えている。
ロボット１は、例えば発話を記憶するトリガーとなる発話、例えば「今からしゃべるから、録音して」という発話の後の言葉を記憶する機能を有している。そして、ユーザーはこの機能を利用して、スマートスピーカ５１を、起動させたりなんらかの処理をさせるような言葉を記憶させるようにする。例えば「ＯＫ、×××。照明をつけて。」のような言葉がよい。このとき、ロボット１に登録されるユーザー個人の音声は、スマートスピーカ５１に登録されるユーザー個人の声である。
そして、ロボット１に所定のタイミングで発話させるようにする。所定のタイミングで発話させる設定は、例えばスマートフォンのような端末を操作して設定登録できる。
ロ．ロボット１の「所定のタイミングでの発話」としては、例えばロボット１がなんらかの変化を検知すること、例えばタッチパネル部７へのタッチ動作や、ドップラーセンサ２２による物体（人）の検知等である。
例えばロボット１のコントローラＭＣはドップラーセンサ２２によって人を検知した場合に「ＯＫ、×××。照明をつけて。」というようにスピーカ装置１３から音声出力をさせる。それを受けてスマートスピーカ５１はネットワーク対応しているＡＩ機器である室内の照明を点灯させるように制御する。尚、制御される照明は前もってスマートスピーカ５１によって制御される対象であるように登録されている。照明以外に例えば、エアコン、テレビ、カーテンの開閉装置等をＡＩ機器とすることがよい。

（２）スマートスピーカ５１からの発話かユーザーの発話かを区別する機能
ユーザーの個人の声を識別してロボット１に設定登録することで、ロボット１がスマートスピーカ５１からの発話か、あるいはユーザーの直の発話かを区別する機能を備えることができる。これによって、ロボット１が登録されていない声であるスマートスピーカ５１からの音に反応しないように制御することができ、逆に（１）のようにスマートスピーカ５１とロボット１にそれぞれユーザーの個人の声を登録することで、スマートスピーカ５１に対してユーザーだけでなくロボット１からも指示をすることができる。このように個人の発話を区別できることでスマートスピーカ５１への音声操作を妨害しないという機能も有する。
（３）スマートスピーカ５１からの発話の表示機能
スマートスピーカ５１にユーザーが指示した発話内容をロボット１が取得して文字テキスト化し、タッチパネル部７に表示させるようにしてもよい。
ロボット１のコントローラＭＣは発話内容を取得して自身であるいはサーバーに接続して文字テキスト化するプログラムを有しているとよい。
例えば、ユーザーが「ＯＫ、×××。今日の天気を教えて。」と発話し、これに対してスマートスピーカ５１が「今日の愛知県岡崎市の天気は晴れ、最高気温１５度、降水確率は２０％です」と回答した場合に、これらのすべての対話を、例えば、ロボット１のタッチパネル部７には例えば、次のように聞き取った両者の対話が表示される。
「ユーザー：ＯＫ、×××。今日の天気を教えて。
スマートスピーカ：今日の愛知県岡崎市の天気は晴れ、最高気温１５度、降水確率は２０％です」
また、加えてロボット１のコントローラＭＣは文字テキスト化した内容を短く翻案したり要約するプログラムを有しているとよい。ロボット１は翻案したり要約した内容を音声出力又はタッチパネル部７への表示させるようにするとよい。
（４）人がいないときにロボット１がスマートスピーカ５１へ色々聞いて学習しておく機能
例えば、ロボット１がビルトインシナリオとして「明日の天気は？」とか「なにか事件はないですか」などという質問ワードを有しており、ユーザーが留守の時にロボット１のコントローラＭＣに所定のタイミングでスマートスピーカ５１を起動するフレーズと一緒に質問ワードを音声出力させるようにする（ロボット１の声はスマートスピーカ５１に登録済みとする）。このとき、コントローラＭＣはスマートスピーカ５１からの発話内容をロボット１はマイクロフォン１２によって取得して記憶しておき、所定のタイミングでその内容を音声出力させる。所定のタイミングとは、例えば所定の時間、ドップラーセンサ２２によって人を検知した際、ユーザーがロボット１に「何かニュースはないの？」というようなビルトインシナリオとしての発話を行った際等である。

＜実施の形態７の変形例１＞
スマートスピーカ等、他の音声認識機器の音声操作を妨害しない機能を設定するようにしてもよい。例えば、他のスマートスピーカの起動フレーズ（音声認識開始ワード）を、の音声をロボット１が認識した場合、自身の音声出力を停止するようにしてもよい。
例えば、他のスマートスピーカであるＡ社の起動フレーズである「ＯＫ、×××」のような起動用のフレーズの音声を認識した場合に、ロボット１のコントローラＭＣはそれをマイクロフォン１２から取得し、登録済みの起動フレーズであると判断すると、自身の音声出力を一旦停止させる。
これによって音声認識機器の音声操作を妨害せずに、機能を発揮させることができる。

＜実施の形態７の変形例２＞
ロボット１にスマートスピーカ５１のような他の音声認識機器の音声認識起動キーワードを認識し、その後のユーザーのスマートスピーカ５１への発音を認識してクラウドサーバ－にリクエストして、検索エンジン等に検索をさせて対応する回答を得ておく。
ロボット１は、スマートスピーカ５１が音声認識に失敗してしまった場合（例えば「エラーです」など）や音声認識結果に対する適切な回答を出力できない旨の音声出力（例えば「すみません」など）を認識した場合、ロボット１は自身が前もって得ておいた回答を出力する。あるいは、音声認識に失敗してしまった場合や音声認識結果に対する適切な回答を出力できない旨の音声出力を受けてから、ロボット１はクラウドサーバ－にリクエストして回答を得るようにしてもよい。

＜実施の形態８＞
ロボット１は、例えばユーザーの要求によってｗｅｂサイト上のニュース記事を音声で読み上げるようにしてもよい。ロボット１のコントローラＭＣはサーバー上での検索エンジンを利用したニュース記事のリクエストをし、クラウドサーバーはそのリクエストに対して、例えば登録サイトのニュースデータをテキストデータとしてレスポンスする。
ロボット１はニュースデータを音声合成して読み上げる（出力する）と同時に記事の情報源の名称も音声合成して読み上げる（出力する）。また、併せて表示画面としてのタッチパネル部７には記事の情報源のＵＲＬを表示をし、タッチパネル部７上でそのＵＲＬにタッチされたら、そのＵＲＬのページの内容をタッチパネル部７上に表示するようにする。
また、記事や記事の情報源を読み上げる場合には、それらが引用であることがわかるような表現で出力することがよい。
例えば、ＵＲＬ「https://＼＼＼＼.jp/archives/92###」の記事内容を読み上げる場合を説明する。
『「××ニュース」のサイトの記事を読み上げるよ。「・・・・・を本年１月１５日より販売する。」そうだよ。』
というように、例えば「のサイトの記事を読み上げるよ。」や「そうだよ」というような記事や記事の情報源以外を正規表現として引用であるように、聞き手にわかるように発話させ、この場合では画面表示に、例えば『https://＼＼＼＼.jp/archives/92###の情報だよ。』というようにＵＲＬを表示させる。そしてこのＵＲＬ部分にタッチすることでタッチパネル部７に読み上げた記事の内容を改めて表示させる。
「聞き手にわかるように発話」とは記事部分とそうでない部分で、例えば語調や声を変えるようにすることがよい。
このようにすれば、Ｗｅｂ記事を読まなくともロボット１の読み上げた内容を聞き取るだけでニュース内容を理解でき、場合によっては念のため目視でニュース内容を確認することもできる。

＜実施の形態９＞
実施の形態９ではコンピュータの見えない動きをロボットのアクチュエータの動作で見せる場合について説明する。
（１）ロボティクスプロセスオートメーションについて
ロボティクスプロセスオートメーション（以下、ＲＰＡとする）は、単純なパソコン作業を自動化するソフトウェアである。ソフトウェアはサーバーに設定することもでき、ユーザーのコンピュータに設定することもできる。図１５に基づいてソフトウェアをサーバーに設定した場合であって、上記各実施の形態のロボット１をＲＰＡのネットワークに組み込んだ場合の一例について説明する。
図１５に示すように、クラウドサーバー５５とユーザー側コンピュータ５６、５７とがインターネットを使用したネットワークで接続されている。また、クラウドサーバー５５とロボット１もネットワークで接続されている。ユーザー側コンピュータ５６はＲＰＡプログラムによってクラウドサーバー５５によって制御されている。また、ロボット１にはクラウドサーバー５５によって実行されるＲＰＡのためのプログラムにおける所定の処理においてその処理がまもなく実行される、実行されている、あるいは実行された等の処理情報が報知されるようになっている。
クラウドサーバー５５はユーザー側コンピュータ５６に処理１～処理４を順に処理させる。本実施の形態では処理1と処理２はコンピュータ５６、処理３と処理４はコンピュータ５７が実行する。もっと多くの処理を設定してもよく、処理に関わるユーザー側コンピュータ５６も１以上いくつでもよい。
処理１としては、例えばコンピュータ５６へのユーザーのアクセス・ログイン等、処理２としては、例えばコンピュータ５６内のデータに基づくリストの作成・仕分け等、処理３は、例えば処理２に続いて実行する顧客毎の請求内容の修正、処理４は、例えば処理３に続いて実行する請求書の発行である。本実施の形態９では例えば処理３ではユーザに修正のための入力を促し、その入力があって後に、次の処理４に移行するものとする。つまり、処理２の後は処理３での力が完了するまで一旦待ち受けードとなる。
クラウドサーバー５５はこれらの処理を実行する直前、処理中、処理後にそれぞれロボット１に異なる報知情報を出力し、ロボット１はその報知情報に基づいてロボット１の周囲に処理状況を報知するようにするとよい。あるいは各処理毎に一回の報知でもよい。

例えば、
ａ．ロボット１がどの処理がどのような状態かを音声や音の違い、あるいは音楽等で報知する。
ｂ．表示画面上で報知する。ａ．と同時に行ってもよい。
ｃ．処理３ではユーザーの入力が必要であるため、処理３だけを報知するようにしてもよく、処理３だけを他の報知とは異なる（識別できる）報知としてもよい。
ｄ．ロボット１から他の端末装置に処理の状態を転送して報知する。
ｅ．ロボット１が処理状況がわかるような動作をする。例えば、コンピュータ５６の処理が行われていればその方向を向くように制御する。そのため、前もってロボット１に対する各コンピュータ５６、５７の方向は何らかの方向特定手段、例えば上記の形状認識プログラムを使用して認識しておくことがよい。ロボット１に例えば矢印や腕部材のような方向指示部材を設け、その指し示す方向に報知対象としてのコンピュータ５６、５７があるように動作してもよい。

（２）ブロックチェーンについて
ブロックチェーンは多数のコンピュータが分散して記録する仕組みである。特にパブリック型のブロックチェーンでは記録対象のデータや記録されたデータが公開される。
そこでブロックチェーンのネットワーク中にロボット１を配置し、ブロックデータが送信される前にユーザーにロボット１がお知らせするようにする。ロボット１に「待て」という命令を出力させることで（つまりデータ送信させずに待機するリクエストをする）送信を停止させるようにするとよい。

＜実施の形態１０＞
各実施の形態では自然対話モードについて説明したが、自然対話モードに代えて、または、自然対話モードとともに、外国語学習モードを設けるとよい。自然対話モードに加えて外国語学習モードを設けるときは、例えば自然対話モードで「外国語学習モードへ切り替え」という音声を認識したときに自然対話モードから外国語学習モードへ切替えるとよい。また「外国語学習モード」で「自然対話モードへ切り替え」という音声を認識したときに外国語学習モードから自然対話モードへ切替えるとよい。
よく外国語を習得するには外国人の友人を作るとよいなどと言われるが、そのような機会に恵まれる人は多くない。そこで外国語学習のパートナーになり得る対話システムである外国語学習機能を備えるとよい。
任意の第一言語と第二言語との連携とすることができる。以下、日本語の対話システムと英語の対話システムを連携させる構成で説明する。
基本的には英語で会話するシステムとし、会話中に日本語で「もう一回言って」などの要求を出力するとよい。さらに、英文解析Webサービスなどと連携して、「説明して」などの要求にたいして会話中の英文を日本語で解説する機能を備える。会話中に言いたいことが英語でどう言えばいいかわからないときには、「翻訳して」と要求をすると英語でどういうのかを出力する。出力された英文を読めばそのまま会話を続けることができる。自分で調べたりする必要がないので、会話が途切れることもなく、円滑な英会話学習が期待できる。
外国語学習モードでの母国語（例えば、日本人なら日本語）の音声認識エンジンと外国語（例えば英語）の音声認識エンジンはどちらもクラウド上で動作している音声認識エンジンを利用するようにしてもよいが、母国語（例えば日本語）については要求内容が定型文であること、要求に対する回答のフォーマットが決まっていることから、ローカル（例えばロボット１内）に音声認識エンジンを設けこれを利用するとよい。対話エンジンも同様である。音声合成エンジンもいずれの場所に設けてもよいが、特にローカルに設けるとよい。
マイクロフォン１２からの信号に基づく音声データを両言語の音声認識エンジンに投げると、どちらの音声認識エンジンからもなんらかの結果が返ってくる。例えば、「もう一回言って」という日本語を両方のエンジンに投げると、日本語のエンジンは「もう一回言って」というテキストデータを返し、英語のエンジンは「もう一回言って」を英語として解釈したデタラメなテキスト データを返してくる。このような場合、日本語の要求は定型文であるため、日本語のエンジンが返してきたテキストデータと要求の定型文を比較して、一致すれば日本語の要求がされたと判断し、一致しなければ英語が話されたと判断することで、英語と日本語を切り分ける処理を行なうと良い。
要求は英語で受け付けるようにしてもよいが、特に、要求をしようにも英語がわからないというケースを想定して、日本語でも要求できるようにすることが望ましいことを発明者は見出した。
「説明して」などの要求に対して会話中の英文を日本語で解説する機能は、単に英文の訳を日本語にして出力するだけでもよいが、特に英文で用いられている語句や文法の解説を出力するとよい。特にその英文で用いられている構文についての解説を出力するとよい。構文についての解説は例えば各句を頂点（ノード）して例えば各句を囲む描画をし、関連する各句の関係を示す線分等の枝（エッジ）を描画するとよい。例えばグラフ構造（特にツリー構造とするとよい）の図でタッチパネル部７に表示するとよい。
また、表示した内容を音声でスピーカ装置１３から出力するとよい。例えば、https://gigazine.net/news/20160602-foxtype-review/で解説されるような構文解析サービスのAPIをコールし、その結果を受け取って、解析結果を日本語で出力する構成とするとよい。
例えば以下のような処理と出力を行なう。
『 処理 英語の対話エンジンからフレーズを取得
ロボット I'm a fantastic robot.
人 「もう一回言って」
ロボット I'm a fantastic robot.
人 「説明して」
処理 （「説明して」を認識）→構文解析APIコール→構文解析結果から日本語解説を生成
ロボット Iが主語で、amが動詞、robotが目的語になるよ。
fantasticは素晴らしいという意味の形容詞でrobotを修飾しているよ。
英文は「私は素晴らしいロボットです」という意味になるよ。
人 「I don't think so.」
ロボット Don't say it! 』
話したいことが英語でわからなければ、日本語で英語での言い方を教えてくれるように要求できるので会話が途切れないという優れた効果を発揮する。日本語での要求ができない場合は、英語での言い方がわからないとき、辞書で調べたりネットで翻訳したりする必要があり、勉強しているという感じになってしまいストレスを感じる。日本語で要求できれば、ただバイリンガルと会話しているという感覚でストレスなく学習できる。語学学習は継続することがとても大事であるから、なるべく学習の際にストレスが少ないということは継続する上で極めて重要なことである。本構成によれば、継続して語学学習を行なえるロボット１を実現できる。

＜実施の形態１１＞
各実施の形態で説明した機能に加え、ロボット１の設置された室内へ人が入ってきたことを検知したとき発話する機能を設けるとよい。またロボット１の設置された室内から人が出ていくことを検知したとき発話する機能を設けるとよい。
例えば、その室内とその室内以外の場所の通路にセンサを設けて、ロボット１の設置された室内へ人が入ってきたこと、ロボット１の設置された室内から人が出ていくことを検知するとよい。特にロボット１が設置された室内に出入りするための自動ドアがある場合、センサは特に自動ドアの開閉のために人がその自動ドアに接近していることを検知するセンサを用いると良い。特に自動ドアをはさんで室外にある第一の人検知センサと、自動ドアをはさんで室内にある第二の人検知センサと、自動ドアが開いているときに自動ドアの場所にいる人を検知する第三の人検知センサセンサ（人のドアへの挟み込みを防止するためのセンサ）の少なくともいずれか２つにロボット１のコントローラMCを接続して、室内への出入りを検知するとよい。このようにすれば、ロボット１が設置された室内への出入り等を新たなセンサを設置することなく検出できる。例えば各センサの人を検知した際に立ち上がる信号のエッジを捉えて検出するとよい。
例えば、第一の人検知センサで人が検知された後、第三の人検知センサで人が検知された場合、「いらっしゃいませ」などと入ってきた人を歓迎するフレーズの音声をスピーカ装置１３から出力するとよい。例えば、第二の人検知センサで人が検知された後、第三の人検知センサで人が検知された場合、「ありがとうございました」と出ていく人に感謝するフレーズの音声をスピーカ装置１３から出力するとよい。
これらのときに第１～第３のモータ２３～２５を動かし、ロボット１の設置位置から予め設定した自動ドアの方を向く動作を行なうようにするとよい。なお、第一の人検知センサと第二の人検知センサとが同じ時に人を検知した場合には、第一の人検知センサを優先するとよい。このようにすれば、入ってくる人によりロボット１の存在を気づいてもらいやすくなるとともに、入ってくる人が「ありがとうございます」とロボット１にいきなり言われる違和感を軽減できる。

＜その他の実施の形態＞
（１）各実施形態等においては、無線ＬＡＮ装置２１を備えることとしたが、これに代えてまたはこれとともに有線ＬＡＮ装置を備え、有線ＬＡＮネットワークに接続するようにしてもよい。有線ＬＡＮ装置はロボット１に内蔵しても、外付けとしてもよい。ＵＳＢのＯＴＧ（On-The-Go）用の端子１８に有線ＬＡＮ装置を接続する構成としてもよい。有線ＬＡＮネットワークはルーター等を介してインターネットに接続される構成とするとよい。無線ＬＡＮは環境によっては通信が安定しないまたは接続できないケースも想定されうる。例えばスマホ等、多数の無線ＬＡＮ装置が存在する場所にロボット１を設置する場合には有線ＬＡＮ装置を介してインターネットにアクセスする構成とすると望ましい。
（２）各実施形態等においては、半二重方式での人とロボット１との対話の例を示しているが、全二重方式で人とロボット１との対話を行なうようにしてもよい。例えば表１の対話の中で「・・・を開いて」と人が行った後、「本当にいいですか」の発話を行っている間も人の音声の認識を続け「取消」という音声が「本当にいいですか」の発話中に認識された場合には、発話中であれば発話を中断し、すぐに「中止しました」とロボットから発話するように構成してもよい。
（３）半二重方式での対話を行なう構成は、構成や処理を簡素化でき、コストを低減できるので特によい。しかし、ロボット１がマイクロフォン１２をオンにしたタイミングが分かりづらく、ユーザーが喋っても、ロボットが認識対象とするユーザーの音声の先頭部分、すなわち言葉の先頭部分が欠けてしまうことが多いという課題を発明者らは見出した。この課題を解決するため、コントローラＭＣがマイクをオンしたタイミングで特徴的な画面表示をおこなうとよい。これによりスムーズな会話をサポートする。コントローラＭＣがマイクをオンしたタイミングで特徴的な画面表示をおこなう態様としては、１）画面の四隅を光らせる、２）マイクのアイコンを表示させる、の少なくともいずれか一方を行なうとよく、特に１）、２）の両方とも行うと優れた効果を発揮する。
（４）第１～第３のモータ２３～２５を構成するモータとしては、ＤＣモータなど各種のモータとすることができるが、特にステッピングモータとするとよく、ロボット１はステッピングモータにより姿勢を制御する構成とするとよい。ステッピングモータはモータに流す電流に比例してトルクの大きさが変わる。電流をたくさん流せば大きなトルクを得られるが、発熱や電池寿命などが問題になる。そこでロボット１の静止時はその姿勢を維持するために必要な最小限の電流を流し、ロボット１が姿勢を変えるときのみ大きな電流を流すようにすると特によい。なお、サーボモータ２３～２５のすべてについてその静止時に姿勢を維持するために必要な最小限の電流を通電するようにしてもよいが、ディテントトルク(通電しない状態でのトルク)で支持できる胴体部の第１のモータ２３は通電しないようにする一方、頭部分はディテントトルクでは負けてしまうため第２のモータ２４，第３のモータ２５については静止時もこの通電をするようするとよい。
また、静止時のトルクのまま回転させるとトルク不足で脱調が起こり上手く回転しないため、回転させる時は静止時に比べ、電流をたくさん流すようにしてトルクを上げるとよい。一方、静止時は回転時のような大きなトルクは必要ないので回転時に比べ、電流を下げるとよい。
また、ある方向に向きを変える場合、加速しながら一定速度まで上げて目的の角度が近づいたら減速して止めるという制御を行なうとよい。
また、ロボットをモータによって駆動させると機械的、電気的なノイズを発生する。このノイズが音声認識の認識率を低下させるので音声認識中はモータを停止するように制御するとよい。
本発明の範囲は，明細書に明示的に説明された構成や限定されるものではなく，本明細書に開示される本発明の様々な側面の組み合わせをも，その範囲に含むものである。本発明のうち，特許を受けようとする構成を，添付の特許請求の範囲に特定したが，現在の処は特許請求の範囲に特定されていない構成であっても，本明細書に開示される構成を，将来的に特許請求の範囲とする意思を有する。
本願発明は上述した実施の形態に記載の構成に限定されない。上述した各実施の形態や変形例の構成要素は任意に選択して組み合わせて構成するとよい。また各実施の形態や変形例の任意の構成要素と，発明を解決するための手段に記載の任意の構成要素または発明を解決するための手段に記載の任意の構成要素を具体化した構成要素とは任意に組み合わせて構成するとよい。これらについても本願の補正または分割出願等において権利取得する意思を有する。また「～の場合」「～のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。
また，意匠出願への変更出願により，全体意匠または部分意匠について権利取得する意思を有する。図面は本装置の全体を実線で描画しているが，全体意匠のみならず当該装置の一部の部分に対して請求する部分意匠も包含した図面である。例えば当該装置の一部の部材を部分意匠とすることはもちろんのこと，部材と関係なく当該装置の一部の部分を部分意匠として包含した図面である。当該装置の一部の部分としては，装置の一部の部材としても良いし，その部材の部分としても良い。全体意匠はもちろんのこと，図面の実線部分のうち任意の部分を破線部分とした部分意匠を，権利化する意思を有する。

１…装置としてのロボット、４１…他の機器としてのスマートフォン、５１…他の機器としてのスマートスピーカ。

Claims (6)

1. ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能を備える装置であって、
   前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備え、
   前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備え、
   前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく機能を備え、
   前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行う機能を備え、
   前記装置は、前記装置と前記ユーザー又は前記他の機器の少なくともいずれか一方の音声によるコミュニケーションの対話履歴を文字情報として前記表示部に表示させる機能を備え、
   前記装置は、前記対話履歴を文字情報として表示させる際に、前記ユーザー又は前記他の機器の交替があり、前記装置の対話対象が代わった場合には前記表示部にその旨を表示させる機能を備えることを特徴とする装置。
2. ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能を備える装置であって、
   前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備え、
   前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備え、
   前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく機能を備え、
   前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行う機能を備え、
   音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分があっても、ある条件を満たすことで音声認識エンジンを備えるサーバに接続して音声データを出力する機能を備えるこ
   とを特徴とする装置。
3. ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能を備える装置であって、
   前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備え、
   前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備え、
   前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく機能を備え、
   前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行う機能を備え、
   認識した前記ユーザーの発話が長すぎると判断した場合に、音声認識エンジンを備えるサーバに接続することなく記憶手段に記憶された音声データから選択された対話例を音声出力する機能を備えることを特徴とする装置。
4. ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能を備える装置であって、
   前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備え、
   前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備え、
   前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく機能を備え、
   前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行う機能を備え、
   前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカの音声出力を翻案する翻案機能を有することを特徴とする装置。
5. ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能を備える装置であって、
   前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備え、
   前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備え、
   前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく機能を備え、
   前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行う機能を備え、
   ロボティクスプロセスオートメーションを実行しているコンピュータの方向を指し示す動作を行なう前記出力情報を生成する機能を備えることを特徴とする装置。
6. 請求項１～５のいずれかに記載の装置の機能をコンピュータに実現させるためのプログラム。

Images