JP2018161704A - 対話制御システム、及び、ロボット制御システム - Google Patents

Abstract

【課題】顧客との適切な対話を行うことが可能な対話制御装置およびロボット制御システムを提供する。【解決手段】対話制御装置は、滞在状態判断部と、情報取得部と、対話制御部と、を備える。滞在状態判断部は、飲食店に入店した顧客の前記飲食店内での滞在状態を判断する。情報取得部は、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を取得する。対話制御部は、前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う。【選択図】図１

Description

本発明は、対話制御システム、及び、ロボット制御システムに関する。

近年、レストランその他公共施設において、来場客の案内役としてヒューマノイド型ロボットを活用する事例が見られる。このようなロボットとのコミュニケーション（対話）を専用の操作端末を用いて行う技術が検討されており、この技術によれば、ユーザは、操作端末を介してロボットとの対話を楽しんだり、案内情報を入手したりすることができる。

具体的には、テーブル席に設置されたロボットと、直接的あるいはタブレット等を介して間接的に対話を行うサービスが考えられる。この場合、お薦めメニューを提示したり、雑談をしたりすることにより顧客の満足度を向上させることができる。

特開２０１５−６６６２３号公報

しかしながら、顧客の現在の状態、例えば、注文前、食事提供前、食事中などの状態に適した対話を行うものでないと、対話がちぐはぐになったり、顧客に不快感を与えたりして、却って顧客の満足度を下げることにもなり得る。

そこで、本発明が解決しようとする課題は、顧客との適切な対話を行うことが可能な対話制御装置およびロボット制御システムを提供することである。

一実施形態に係る対話制御装置は、飲食店に入店した顧客の前記飲食店内での滞在状態を判断する、滞在状態判断部と、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う、対話制御部と、を備える。

前記滞在状態判断部は、店舗システムからの情報に基づいて、前記顧客の前記飲食店内での滞在状態を判断してもよい。

対話制御装置は、前記顧客が飲食物の注文を行ったことを示す信号を前記店舗システムから受信する、受信部をさらに備えていてもよく、前記滞在状態判断部は、前記受信部にて前記信号が受信されると、注文した飲食物を前記顧客が待っている状態であることを判断するようにしてもよい。

前記滞在状態判断部が判断する前記顧客の滞在状態は、時間の経過により変化する状態であってもよい。

前記滞在状態判断部が判断する前記顧客の滞在状態は、前記顧客が前記飲食店に入店または着席してから飲食物を注文するまでの状態と、前記顧客が注文した飲食物が提供されるのを待っている状態と、前記顧客が飲食物の飲食を完了するまでの状態と、前記顧客が飲食物の飲食を完了してから退店するまでの状態と、のうち少なくとも１つの状態を含んでいてもよい。

対話制御装置は、前記顧客が飲食物の注文を行っていない場合に、前記顧客に飲食物の推奨メニューを提供する、推奨メニュー提供部を備えていてもよく、前記情報取得部は、飲食物のメニュー選択に関する前記顧客との対話において、前記顧客が前記推奨メニューを選択した場合と、前記推奨メニューを選択せずに別のメニューを選択した場合とで、それぞれ相違する対話シナリオ情報を取得してもよい。

対話制御装置は、それぞれ異なる複数の対話シナリオ情報を蓄積するシナリオ蓄積部を備えていてもよく、前記情報取得部は、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を、前記シナリオ蓄積部から取得するようにしてもよい。

前記情報取得部は、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を、通信ネットワークを介して取得してもよい。

一実施形態に係るロボット制御システムは、指示信号に応じた動作を行う、ロボットと、前記指示信号を生成して前記ロボットに送信する、操作端末と、を備え、前記操作端末は、店舗システムからの情報に基づいて、飲食店に入店した顧客の前記飲食店内での滞在状態を判断する、滞在状態判断部と、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う対話制御部と、を有する。

前記操作端末は、前記店舗システムから前記顧客の注文情報を受信する、受信部を有していてもよく、前記滞在状態判断部は、前記受信部にて前記注文情報が受信されると、注文した飲食物を前記顧客が待っている状態であることを判断するようにしてもよい。

前記店舗システムは、前記注文情報に加えて、前記顧客が入店したことを示す第１情報、前記顧客が着席したことを示す第２情報、注文した飲食物が前記顧客に提供されたことを示す第３情報、前記顧客が提供された飲食物の飲食を完了したことを示す第４情報の少なくとも１つを含む滞在情報を無線送信してもよく、前記操作端末の前記受信部は、前記店舗システムが送信した前記注文情報および前記滞在情報を受信し、前記滞在状態判断部は、前記受信部にて受信した前記注文情報および前記滞在情報に基づいて前記顧客の滞在状態を判断するようにしてもよい。

本発明によれば、顧客との適切な対話を行うことが可能な対話制御装置およびロボット制御システムを提供できる。

一実施形態に係るロボット制御システムの一例を示すブロック図。 一実施形態に係るシナリオ制御部の一例を示すブロック図。 一実施形態に係る対話制御におけるシナリオ制御の処理を示す図。 一実施形態に係る対話制御の処理の流れを示すフローチャート。 一実施形態に係る対話の一例を示す図。 一実施形態に係る推奨メニュー提供の対話の一例を示す図。 一実施形態に係る推奨メニュー選択時の対話の一例を示す図。 一実施形態に係る推奨メニュー非選択時の対話の一例を示す図。 一実施形態に係る注文後の対話の一例を示す図。 一実施形態に係るシナリオ制御部の別の例を示すブロック図。 変形例に係るロボット制御システムの一例を示すブロック図。 変形例に係る対話の一例を示す図。 変形例に係るロボット制御システムの一例を示すブロック図。

以下、本発明の実施形態に係る対話制御システム及びロボット制御システムの構成及び作用について、図面を参照しながら詳細に説明する。なお、以下に示す実施形態は、本発明の実施形態の一例であって、本発明はこれらの実施形態に限定して解釈されるものではない。また、本実施形態で参照する図面において、同一部分又は同様な機能を有する部分には同一の符号又は類似の符号を付し、その繰り返しの説明は省略する場合がある。また、図面の寸法比率は説明の都合上実際の比率とは異なる場合や、構成の一部が図面から省略される場合がある。

図１は、本発明の実施形態によるロボット制御システム１を示すブロック図である。図１に示すように、ロボット制御システム１は、ロボット２と、ロボット制御装置の一例である操作端末３と、ハンディ端末４と、ＰＯＳ（Point of Sales）システムなどの店舗システム５と、を備える。ロボット制御システム１は、例えば、飲食店の顧客（以下、ユーザと呼ぶ）が、ロボット２を操作する操作端末３を介してロボット２と対話をするためのシステムである。

図１におけるロボット２は、人間に似た外観及び対話機能を有する機械、すなわちヒューマノイドである。なお、ロボット２は、動物やキャラクタなどの人間と非類似の外観を有していてもよい。また、ロボット２は、表示部３５に表示された画像による仮想的なロボットであってもよい。

（ロボット２）
図１に示すように、ロボット２は、ロボット駆動部２１と、駆動制御部の一例であるロボット制御部２２とを有する。ロボット２は、商用電源から供給される電力によって駆動するものであってもよいし、電池等のバッテリにより駆動するものであってもよい。

ロボット駆動部２１は、ロボット２の発話音声を出力する音声出力装置を備える。ロボット駆動部２１を必要に応じて駆動させることにより、ユーザとの対話を行うためにロボット２に発話させることができる。ロボット駆動部２１には、ロボット制御部２２から、ロボット駆動部２１の駆動を制御する駆動制御信号が入力される。ロボット駆動部２１は、駆動制御信号に応じて駆動される。なお、ロボット駆動部２１は、他に、自由度を有するロボット２の部位を駆動するアクチュエータや、ロボット２の眼球部を点灯させる点灯装置等を有していてもよい。

ロボット制御部２２は、指令信号の一例であるロボット制御コマンドを操作端末３から受信する。ロボット制御部２２は、受信したロボット制御コマンドに基づいて上述の駆動制御信号を生成し、生成された駆動制御信号をロボット駆動部２１へと出力する。すなわち、ロボット２は、ロボット制御コマンドに応じて動作することができる。なお、ロボット２を発話させるためのコマンドには、発話内容を示すデータ（後述するシナリオデータ）が含まれる。

ロボット制御部２２は、例えば、アプリケーションプログラムやこれを動作させるオペレーティングシステムなどのソフトウェアが記憶された少なくとも１つのメモリと、メモリに記憶されたソフトウェアを実行するＣＰＵ（Central Processing Unit）とを有し、メモリに記憶されたソフトウェアをＣＰＵが実行することにより駆動制御信号を生成してもよい。

（操作端末３）
操作端末３は、ユーザが携帯するものであり、例えば、タッチ機能を備えたタブレット端末である。この他、操作端末３は、スマートフォンや卓上のディスプレイ型の端末などでもよい。図１に示すように、操作端末３は、センサの一例である方位センサ３１と、指令信号生成部及び送信部の一例である動作生成部３２とを有する。操作端末３は、内蔵電池から供給される電力によって駆動される。

方位センサ３１は、操作端末３の方位を示す方位検出信号を動作生成部３２へと出力する。方位センサ３１は、検出された操作端末３の方位を示す方位検出信号を動作生成部３２へと出力する。動作生成部３２は、例えば、方位センサ３１からの方位検出信号に基づいて、操作端末３が存在する方向を向くように、ロボット２の姿勢を制御するためのロボット制御コマンドを生成する。

動作生成部３２は、方位センサ３１の出力に基づいてロボット２の動作を制御するロボット制御コマンドを生成する。動作生成部３２は、生成されたロボット制御コマンドを、例えば、Ｗｉ−Ｆｉなどの無線通信を介してロボット制御部２２へと送信する。ロボット制御部２２は、動作生成部３２からのロボット制御コマンドを受信し、受信されたロボット制御コマンドに応じた駆動制御信号をロボット駆動部２１へと出力することにより、ロボット２の動作の制御を行う。

ロボット２の動作としては、音声を用いてユーザと会話を行う対話動作も含まれる。ユーザとロボット２との間での対話を行うための構成として、操作端末３は、上述の動作生成部３２に加え、さらに、シナリオＤＢ（データベース）３３と、シナリオ制御部３４と、表示部３５と、タッチパネル等の入力部３６と、音声出力部３７とを備える。

シナリオＤＢには、ユーザとロボット２との間での対話を行うための複数の対話シナリオ情報が蓄積されている。対話シナリオ情報は、複数の対話シナリオを含んでいる。対話シナリオとは、ユーザとロボット２との間でやり取りされる対話のストーリである。飲食店に入店した顧客は、入店してから退店するまでの間に複数の滞在状態を遷移する。そこで、シナリオＤＢには、遷移状態ごとに別個の対話シナリオが蓄積されている。また、ある滞在状態にて実行された対話シナリオの進行中に、顧客が操作端末３で複数の選択肢の中から特定の選択肢を選択した場合には、別の対話シナリオに切り替わる場合もありうる。各対話シナリオは、ロボット２が対話（すなわち、発話）に用いるロボット側シナリオデータと、ユーザが対話（すなわち、操作端末３での選択）に用いるユーザ側シナリオデータとで構成されている。ユーザ側シナリオデータは、各対話シナリオにおけるロボット２の発話に対するユーザ側の選択肢等を集めたデータである。ユーザ側シナリオデータは、対話シナリオの進行に合わせて、操作端末３の表示部３５に選択肢等を表示するために用いられる。ユーザは、表示された選択肢の中から特定の選択肢を入力部３６にて選択することができる。

そして、ユーザ側シナリオデータに示される対話シナリオの選択肢のそれぞれに、互いに異なる新たな（下位の）ロボット側シナリオデータが対応付けられている。すなわち、対話シナリオデータは、ロボット側シナリオデータとユーザ側シナリオデータが交互にノードとして結合されたツリー構造を有する。ツリー構造のうち、最上位から最下位にわたる所定の一連のノード群は、例えば典型的な対話に用いられる基本シナリオとして管理され、他のノード群は、基本シナリオを補正する補正シナリオとして管理されていてもよい。

例えば、飲食店向けの対話シナリオデータは、飲食店におけるユーザの滞在状態を示すステータスデータ（滞在情報）に応じて複数のシナリオ群に区分されていてもよい。図１の例におけるステータスデータは、着席、注文、飲食物提供、食事終了、及び、会計の各行為をしたことを示す情報である。対話シナリオデータはこれらのステータスデータにより区分されるシナリオ群の中から提供される。

シナリオ制御部３４は、店舗システム５から出力されたデータに基づいてシナリオを制御する。図２は、シナリオ制御部３４のブロック図を示す図である。この図２に示すように、シナリオ制御部３４は、受信部３４１と、滞在状態判断部３４２と、情報取得部３４３と、対話制御部３４５と、を備える。また、シナリオ制御部３４は、推奨メニュー提供部３４４を備えていてもよい。このように、推奨メニュー提供部３４４は、必須の構成部ではない。

受信部３４１は、店舗システム５から出力されたステータスデータを含む情報を受信する。ステータスデータは、例えば飲食店の店舗スタッフが携帯する注文用のハンディ端末４にて入力可能である。このステータスデータは、ハンディ端末４から店舗システム５に送信された上で、店舗システム５からシナリオ制御部３４の受信部３４１へと送信される。また、ステータスデータは、店舗システム５を経由せずに、ハンディ端末４から直接受信部３４１を介して操作端末３へと送信されるようにしてもよい。

ステータスデータの例としては、ユーザが飲食物の注文をしたことを示す注文情報の他、ユーザが入店したことを示す第１状態、ユーザが着席したことを示す第２状態、注文した飲食物がユーザに提供されたことを示す第３状態、ユーザが提供された飲食物の飲食を完了したことを示す第４状態などがある。これには限られず、ステータスデータは、ユーザが離席したことを示す離席状態、ユーザ同士が会話をしている会話状態、又は、ユーザが食後にデザートを注文した状態などを備えていてもよい。このように、ステータスデータは、時間の経過とともに変化するユーザの滞在状態を示す情報である。

滞在状態判断部３４２は、受信部３４１が受信した情報のうち、ステータスデータに基づいて、ユーザの滞在状態を判断する。滞在状態判断部３４２は、例えば受信部３４１を介してユーザが着席したことを示す第２状態の信号を受信すると、ユーザが着席後、注文前の滞在状態であると判断する。受信部３４１を介して注文情報を受信すると、滞在状態判断部３４２は、ユーザが注文後、飲食物の提供待ちの滞在状態であると判断する。上述のステータスデータと同様に、滞在状態も、時間の経過とともに変化するユーザの状態を示す情報である。

なお、ステータスデータと滞在状態の関連性は、上述したもの以外の構成であってもよい。例えば、店舗スタッフが、ステータスデータとして滞在状態そのものを入力するようにしてもよい。すなわち、ユーザの行為をトリガとして入力するのではなく、状態そのものを入力するものであってもよい。具体的には、店舗スタッフが、着席した、注文した、といった行為を入力するのではなく、着席している状態、注文して飲食物待機中の状態といった状態を直接入力するようにしてもよい。この場合、滞在状態判断部３４２は、受信したステータスデータそのものを滞在状態であると判断する。このような入力の違いは、基本的には設計事項の問題である。

情報取得部３４３は、シナリオＤＢ３３から、滞在状態判断部３４２が判断した滞在状態に応じた対話シナリオ情報を取得する。対話シナリオ情報とは、滞在状態により変化するシナリオ群の情報、又は、当該シナリオ群に含まれる個々のシナリオデータ等のことを言う。シナリオ群が存在せず、複数の対話シナリオのデータで対話シナリオ情報が構成されていてもよい。

シナリオ群とは、ユーザの滞在状態に適したシナリオデータの束であり、滞在状態に合わせた種々のシナリオデータを含む。例えば、ユーザの滞在状態が注文前の状態である場合、シナリオ群には、それぞれの時刻に合わせたメニューを提示するシナリオデータや、大人、小人の人数により対話の内容や、話し方が変化するシナリオデータ、その他様々なシチュエーションに応じたシナリオデータが含まれている。また、同一の滞在状態であっても、操作端末３の操作に応じて選択されうる複数の対話シナリオデータを設けてもよい。

情報取得部３４３は、ユーザの滞在状態に応じて対話するシナリオデータを取得するようにしてもよいし、情報取得部３４３がシナリオ群を取得した上で、当該シナリオ群から対話に用いるシナリオデータを選択して出力するようにしてもよい。シナリオ群から対話に用いるシナリオデータを選択するのは、情報取得部３４３であってもよいし、対話制御部３４５であってもよい。

推奨メニュー提供部３４４は、メニュー中にお薦めのメニューがある場合に、当該お薦めのメニューに関する推奨メニュー情報を情報取得部３４３に送信する。情報取得部３４３は、シナリオＤＢ３３から、当該推奨メニューに関する対話シナリオ情報を取得する。

例えば、ユーザが着席後、注文前の滞在状態である場合に、情報取得部３４３で取得した推奨メニューに関する対話シナリオ情報に基づいて、推奨メニュー提供部３４４が推奨メニューを出力するようにしてもよい。

別の方法としては、情報取得部３４３は、対話シナリオ情報を取得する際に、推奨メニュー提供部３４４に対して推奨メニューの有無を確認する。推奨メニューがある場合には、シナリオＤＢ３３から、推奨メニューを推奨するシナリオデータを取得する。そして、取得したシナリオデータは、対話制御部３４５へと出力される。複数の推奨メニューがある場合には、当該複数の推奨メニューを情報取得部３４３へと送信してもよいし、第１の推奨メニューに加え、その他の推奨メニューがあるという情報を情報取得部３４３へと送信してもよい。

対話制御部３４５は、ユーザの滞在状況に応じて取得した対話に用いるシナリオデータを含む情報を動作生成部３２へと出力する。さらに、対話制御部３４５は、必要であれば、操作端末３の表示部３５へと対話に用いるデータを出力してもよい。対話に用いるデータは、基本的には、ロボット側シナリオデータに応答するために使用するユーザ側シナリオデータの情報である。

対話に用いるシナリオデータを受信した動作生成部３２は、対話データを音声化した信号をロボット制御部２２へと送信することにより、ロボット２から音声を発生させる。この際、ロボット２の口の部分を開閉させたり、光らせたりする信号を併せてロボット制御部２２に送信し、ロボット２の口を開閉させたり、光らせたりさせることもできる。また、音声データは、上記のように操作端末３からロボット制御部２２に適宜送信する代わりに、ロボット２内に音声データを格納しておき、各音声データに紐付けられた識別信号を送信することにより、ロボット２に発声させるようにしてもよい。ロボット２から出力される音声は、意味のある言葉を含む発話でもよいし、言葉を含まない擬制音などでもよい。

なお、対話制御部３４５が出力するデータは、ユーザ側シナリオデータには限られず、ユーザがメニューを選択する際には、飲食物の画像や動画を表示部３５へと出力するようにしてもよい。すなわち、対話に用いる言葉、文字に関する情報だけではなく、適宜、画像、動画等、表示に用いることのできるデータを表示部３５へと出力するようにしてもよい。

また、これには限られず、必要に応じて操作端末３から音声を出力させたり、操作端末３を振動させたりしてもよく、この場合には、これらの音声データ、振動データ等を出力するようにしてもよい。また、ロボット２が音声を発する場合には、ロボット２が発する音声を文字として表示部３５へと併せて出力するようにしてもよい。一方、ユーザは、表示部３５に表示されているユーザ側シナリオデータに基づき、表示部３５に表示された選択肢の中から、入力部３６にて任意の選択を行う。

そして、対話制御部３４５は、ユーザに選択されたデータに応答するためのロボット側シナリオデータを表示部３５、及び、動作生成部３２へと出力する。この際、ユーザの選択を、音声出力部３７を介して操作端末３から音声情報として出力するようにしてもよい。

表示部３５に推奨メニューが表示された後であり、かつ、複数の推奨メニューがある場合、対話制御部３４５は、入力部３６からの別の推奨メニューを提示する旨のユーザの入力に基づいて、異なる推奨メニューの提示を行うように情報取得部３４３へと信号を出力してもよい。

この場合、点線で示されるように、推奨メニュー提供部３４４を介して情報取得部３４３へと新たな推奨メニューを通知するようにしてもよい。新たな推奨メニューの指示を受信すると、情報取得部３４３は、あらかじめシナリオＤＢ３３又は推奨メニュー提供部３４４から取得していた新たな推奨メニューに係る対話シナリオを対話制御部３４５へと送信してもよい。

別の例としては、情報取得部３４３は、新たな推奨メニューを出力する旨の通知が来たタイミングでシナリオＤＢ３３又は推奨メニュー提供部３４４から当該新たな推奨メニューに係る対話シナリオを取得するようにしてもよい。さらに、推奨メニューは、店舗側や、店舗のチェーン側で設定できるだけではなく、例えば、売り上げの高いメニューや、人気のあるメニューとするようにしてもよい。

なお、図２においては、入力部３６は、対話制御部３４５と接続されているが、これには限られず、併せて推奨メニュー提供部３４４へと接続されていてもよい。この場合、他の推奨メニューの提示をユーザが望んだ場合に、推奨メニュー提供部３４４は、対話制御部３４５を介さずに、当該入力に基づき情報取得部３４３へと他の推奨メニューについての信号を出力する。

このように、シナリオ制御部３４は、店舗スタッフがハンディ端末４へ入力したユーザの滞在状態に基づいて、シナリオＤＢ３３に格納されている各種のシナリオデータから適したものを取得し、動作生成部３２、表示部３５へと出力する。さらに、シナリオ制御部３４は、入力部３６から入力された対話シナリオ選択信号に応じて、対話シナリオ選択信号で選択された対話シナリオに応答する新たなロボット側シナリオデータをシナリオＤＢ３３から読み出す。

そして、シナリオ制御部３４は、読み出された新たなロボット側シナリオデータを、発話のために動作生成部３２へと出力する。この処理を繰り返すことにより、ユーザとロボット２との間の対話を行うことが可能となる。

以上の構成により、対話シナリオデータを用いてユーザとロボット２との間での対話を行うことができる。

（滞在状態）
図３は、店舗スタッフによるハンディ端末４の操作から、シナリオデータの選択までの処理の様子を時系列と併せて模式的に表した図である。この図３において、実線の矢印は、データ及び信号の入出力、破線の矢印は、時間の経過を表す。上述した説明、及び、この図３に示されているように、シナリオデータ選択までの処理は、店舗システム５と、シナリオＤＢ３３と、シナリオ制御部３４により実行される。

この図３を用いてステータスデータと、シナリオ群の推移について説明する。まず、店舗スタッフの操作によりハンディ端末４に、ユーザが入店したという第１情報、又は、ユーザが着席したという第２情報が滞在情報Ａ１として入力される。店舗システム５を介して当該滞在情報Ａ１がシナリオ制御部３４へと送信されると、滞在状態判断部３４２は、現在のユーザの滞在状態が、ユーザが飲食店に入店、又は、着席してから注文をするまでの状態である滞在状態Ｐ１であると判断する。そして、情報取得部３４３は、この滞在状態Ｐ１に応じたシナリオ群１に属するシナリオデータをシナリオＤＢ３３から取得し、ユーザとの対話を行う。店舗スタッフがステータスデータを打ち込む際に、ハンディ端末４は、例えばユーザの着席しているテーブル番号等をキーとして送信するようにしてもよい。このようにすることにより、ハンディ端末４から打ち込んだステータスデータと、ユーザとを紐付けることもできる。

次に、時間が経過し、店舗スタッフが、ハンディ端末４を介してユーザの注文を店舗システム５へと送信、すなわち注文したという注文情報を滞在情報Ａ２として送信する。すると、滞在状態判断部３４２は、ユーザの滞在状態が注文前の滞在状態Ｐ１から、ユーザが注文した飲食物が提供されるのを待っている状態、すなわち、注文をして飲食物の提供を待機している滞在状態Ｐ２へと移行したと判断する。そして、情報取得部３４３は、この滞在状態Ｐ２に応じたシナリオ群２に属するシナリオデータをシナリオＤＢ３３から取得し、ユーザとの対話を行う。

同様に、飲食物提供の滞在情報Ａ３が送信されると、ユーザが飲食物の飲食を完了するまでの状態、すなわち、飲食中である滞在状態Ｐ３へと移行し、シナリオ群３に属するシナリオデータで対話を行い、飲食終了の滞在情報Ａ４が送信されると、ユーザが飲食を完了してから退店するまでの状態である滞在状態Ｐ４へと移行し、シナリオ群４に属するシナリオデータで対話を行う。このように、時間の経過にしたがい、店舗スタッフがユーザのステータスデータを適宜入力することにより、滞在状態が変化し、それに応じたシナリオデータを用いた対話が行われる。

滞在状態に関しても、上述した滞在情報と同様に、上記したものには限られない。滞在状態として、例えば、デザートを注文した場合においては、デザートが提供されるのを待っている待機状態、注文したデザートが提供された後には、デザートを飲食中である状態であるといった滞在状態を含んでもいてもよい。シナリオ群も上記に限定されるものではなく、デザート待機状態に応じたシナリオ群、デザート飲食中状態に応じたシナリオ群等を含んでいてもよい。別の例として、追加の注文を受けた場合には、滞在状態Ｐ２へと戻るようにしてもよい。

なお、ステータスデータの入力は、ハンディ端末４を介して入力されるものには限られない。例えば、ユーザが会計をして退店をする場合、会計をする際のＰＯＳ端末（店舗システム５）から会計をした旨のステータスデータが、操作端末３へと送信されるようにしてもよい。また、会計をした旨のステータスデータを受信した操作端末３は、滞在状態を初期状態へと戻すようにしてもよい。

（動作例）
次に、図１のロボット制御システム１の主要な動作例について説明する。図４は、本実施形態に係る操作端末３における、シナリオデータの取得処理、及び、対話処理の流れを示すフローチャートである。この図４と図３を用いて動作例について説明する。初期の滞在状態としては、例えば、ヌル値を入れておき、状態が未入力としてもよいし、未入店又は未着席という滞在状態を設定しておいてもよい。以下の説明においては、初期状態として未入店又は未着席という滞在状態が設定されているものとする。

まず、滞在状態判断部３４２は、受信部３４１を介して店舗システム５からステータスデータ（滞在情報）を取得する（ステップＳ１０）。滞在状態判断部３４２は、例えば、図３における入店した、というステータスデータＡ１を、受信部３４１を介して受信する。

次に、滞在状態判断部３４２は、受信したステータスデータに基づいて、ユーザの滞在状態を判断する（ステップＳ１１）。例えば、ステータスデータＡ１を受信した場合、滞在状態判断部３４２は、滞在状態を、ユーザが注文をする前の状態である滞在状態Ｐ１であると判断する。滞在状態判断部３４２は、得られた滞在状態Ｐ１を、情報取得部３４３へと出力する。

次に、情報取得部３４３は、ユーザの滞在状態が変更されたか否かを判定する（ステップＳ１２）。例えば、未入店又は未着席の状態から滞在状態Ｐ１へと変更している場合、情報取得部３４３は、新たな滞在状態へと遷移したと判定し（ステップＳ１２：ＹＥＳ）、シナリオの取得ステップへと移行する。

滞在状態が変更されたと判定した情報取得部３４３は、シナリオ群の選択を行う（ステップＳ１３）。例えば、滞在状態Ｐ１であれば、情報取得部３４３は、シナリオを取得するグループとして、シナリオ群１を選択する。

次に、情報取得部３４３は、シナリオ群１に属するシナリオから、対話に用いるシナリオデータの選択を行う（ステップＳ１４）。例えば、未着席状態から滞在状態Ｐ１に遷移した場合、ユーザは、入店した直後、又は、席に案内された直後である可能性が高いので、時刻に合わせた「おはよう」、「こんにちは」等の挨拶をするシナリオ、及び、メニュー選択についてのシナリオを選択するようにしてもよい。

このシナリオの選択をするタイミングにおいて、推奨メニュー提供部３４４から推奨メニュー情報が提供されてもよい。この場合、情報取得部３４３は、推奨メニューがある場合のシナリオを選択し、推奨メニュー提供部３４４から提供された推奨メニューに基づいたシナリオを対話制御部３４５へと出力する。

次に、対話制御部３４５は、ロボット２を介してユーザとの対話の処理を実行する（ステップＳ１５）。滞在状態が遷移していない場合（ステップＳ１２：ＮＯ）には、上記のステップＳ１３、ステップＳ１４の処理を省いてこの処理を行う。

図５は、ロボット２とユーザとの対話の一例を示す図であり、推奨メニュー提供部３４４が推奨メニュー情報を提供した場合の例を示す図である。この図５に示すように、対話は、ロボット２と、操作端末３を用いて行われる。操作端末３は、例えば、表示部３５と、表示部３５に一体に組み込まれたタッチパネル式の入力部３６と、を備えるタブレット型の携帯端末である。ロボット２からは、情報取得部３４３により選択されたロボット側シナリオデータに基づいて、例えば「なにを注文する？」という発話が実行される。

そして、このロボット２の発話に返答するタイミングにおいて、操作端末３の表示部３５には、上記のロボット側シナリオデータに対する回答として、「メニューを見る」及び「おすすめメニューを教えて！」という選択肢を含むユーザ側シナリオデータが表示される。入力部３６を介して、選択肢からの選択を行うことにより、ユーザは、ロボット２との対話を実行する。入力部３６にて選択を行ったときに、選択内容を自動音声にて発話してもよい。これにより、ロボット２との対話感をより高めることができる。

対話制御部３４５は、ユーザからの回答により、以降の対話に用いるシナリオが変更されるか否かを判定する（ステップＳ１６）。例えば、図５において、シナリオデータは、推奨メニューをお薦めするシナリオが選択されているとする。ここで、「メニューを見る」という選択肢をユーザが選択すると、シナリオを変更する必要が出てくる。このような場合、対話制御部３４５は、シナリオの変更が必要であると判断し（ステップＳ１６：ＹＥＳ）、ステップＳ１４に戻り、シナリオ群１の中からメニューを見せるシナリオを選択するように、情報取得部３４３へ通知する。

一方、「おすすめメニューを教えて！」という選択肢をユーザが選択した場合、シナリオの変更は必要なく（ステップＳ１６：ＮＯ）、ユーザとロボット２との対話が継続される。

ユーザ側シナリオデータに基づいてユーザが対話を行うと、滞在状態判断部３４２は、ユーザの滞在情報を取得する（ステップＳ１７）。これは、対話中に、店舗スタッフがハンディ端末４を用いてユーザの滞在情報を入力する場合があるので、そのような状況に対応するための処理である。操作端末３は、このように滞在情報を対話中に取得できるようにしておいてもよい。

次に、対話制御部３４５は、ロボット２との対話を終了させるか否かを判定する（ステップＳ１７）。ユーザが選んだ選択肢により対話が終了する場合（ステップＳ１７：ＹＥＳ）、対話制御部３４５は、対話を終了させる。この際、ロボット２から、「またお話ししようね。」などと発話させるようにしてもよい。一方、ユーザが選んだ選択肢により対話が継続される場合（ステップＳ１７：ＮＯ）、ステップＳ１１へと戻り、上述した手順にしたがい、対話が継続される。

以下、ロボット２とユーザとのやりとりを通じて、上記の図５の説明に続く処理手順を詳しく説明する。

図６は、図５において、「おすすめメニューを教えて！」がユーザにより選択された場合の表示部３５の表示例を示す図である。この図６に示すように、本日のおすすめメニューとして、推奨メニュー提供部３４４が提供した、「イタリア産チーズのハンバーグ」の文字が、画像や動画とともに表示される。それとともに、その他のおすすめメニューを併せて表示してもよい。さらに、ロボット２からイタリア産チーズのハンバーグの説明について、メニューの内容、おすすめの理由等を発話するようにしてもよい。ここで、ユーザにより、イタリア産チーズのハンバーグを注文するメニューとして選択される、すなわち、「このメニューを選択する」が選択されると、シナリオの変更はせず（ステップＳ１６：ＮＯ）に対話が継続される。

図７は、おすすめメニューを選択した場合の対話例を示す図である。まず、ロボット２は、ユーザが選択したことに対して、「おすすめメニューを選んでくれたんだ。ありがとう！」等のメッセージを発話する。そして、表示部３５には、その発話に対する回答として、「もちろん！」、「やっぱり変える」と言った選択肢が表示される。ここで、「もちろん！」がユーザにより選択されると、ロボット２は、例えば、「おすすめメニューは、・・・、グッドチョイスだよ！」と発話し、続いて、「店舗スタッフさんを呼んで注文しよう！」と、注文を促す旨のメッセージを発話する。

一方、図６において、「他のメニューを見る」が選択されると、シナリオが変更される旨の通知が対話制御部３４５から情報取得部３４３へと為される（ステップＳ１６：ＹＥＳ）。通知を受信した情報取得部３４３は、ステップＳ１４に戻り、別のシナリオを選択する。図８は、別のシナリオが選択された場合の例を示す図である。この図８に示すように、ロボット２は、例えば、「違うメニューにしたんだ。」等発話する。表示部３５には、その発話に対する回答として、「ごめんね。」、「やっぱり変える」と言った選択肢が表示される。ここで、「ごめんね。」がユーザにより選択されると、ロボット２は、例えば、「別のおすすめメニューもみてみる？」等のメッセージを発話し、ユーザに別のおすすめメニューをリコメンドしてもよい。

このように、ユーザが選んだ選択肢により、対話制御部３４５は、シナリオを変更するか否かを判定し、情報取得部３４３は、その判定結果を基に、シナリオＤＢ３３から新たなシナリオデータを取得する。新たなシナリオデータを取得する際に、別のおすすめメニューがあり、それを表示させる場合には、情報取得部３４３は、推奨メニュー提供部３４４と情報をやりとりすることもできる。なお、図６において、その他のおすすめメニューである「黒毛和牛のすき焼き」等を選択した場合にも、情報取得部３４３は、推奨メニュー提供部３４４から新たな推奨メニュー情報を取得し、シナリオＤＢ３３から推奨メニューに別のシナリオを取得するようにしてもよい。

上記の図６乃至図８の間には、滞在情報が更新されないので、ユーザの回答後、ステップＳ１７において滞在情報を取得したとしても、滞在状態判断部３４２により、滞在状態が更新されることは無く、シナリオ群の選択をすることは無い。一方で、例えば、図７の状態の後、ユーザが飲食物の注文を行い、ハンディ端末４を介してユーザが注文を行った、という注文情報がシナリオ制御部３４の受信部３４１を介してされた場合について、以下に説明する。

この場合、ステップＳ１７において、ハンディ端末４から図３における注文したという滞在情報Ａ２が、店舗システム５及び受信部３４１を介して、滞在状態判断部３４２へと送信される。そして、対話終了と判断されない（ステップＳ１８：ＮＯ）と、次に、滞在状態判断部３４２は、滞在状態の検出を行う（ステップＳ１１）。滞在状態判断部３４２は、滞在情報Ａ２を受信したことに基づいて、現在の滞在状態が、ユーザが注文を完了し、注文した飲食物が提供されるのを待っている状態であるという滞在状態Ｐ２へと遷移したと判断する。

次に、滞在状態判断部３４２から滞在状態Ｐ２へ遷移したことを通知された情報取得部３４３は、シナリオデータを取得するシナリオ群として、滞在状態Ｐ２に対応するシナリオ群２を選択する（ステップＳ１３）。続いて、情報取得部３４３は、シナリオＤＢ３３から、シナリオ群２に属する対話シナリオ情報を選択し、取得する（ステップＳ１４）。そして、情報取得部３４３により取得された対話シナリオ情報に基づいて、対話制御部３４５は、ロボット２を介してユーザとの対話を実行する（ステップＳ１５）。なお、滞在状態判断部３４２は、単に現在の滞在状態が滞在状態Ｐ２であることを通知するだけでもよく、この場合、情報取得部３４３が滞在状態が遷移したと判定し、シナリオ群２を選択するようにしてもよい。

図９は、情報取得部３４３により、シナリオ群２に属するシナリオデータが選択された場合の対話例を示す図である。この図９に示すように、ロボット２は、「料理が来るまでお話ししよう！」等、注文が終了して、ユーザが飲食物の提供を待機している状態に適した対話を行う。

以上のように、本実施形態によれば、飲食店に来店した顧客が飲食店内に設置されたロボット２と、操作端末３を介して適切な対話を行うことができる。すなわち、本実施形態では、店舗スタッフがハンディ端末４を介して入力した情報に基づいて、顧客の滞在状態を把握できる。そして、比較的短時間の間に変化していく顧客の滞在状態に応じた対話シナリオ情報を取得することで、顧客の状態、例えば、注文前である状態や、飲食中である状態に適した対話を行うことができ、顧客の満足度を高めることが可能となる。

なお、上記の説明においては、滞在状態は、店舗スタッフがハンディ端末４から入力した際に遷移するものであるとしたが、これには限られない。例えば、ユーザの注文を確定した後に、ユーザの注文した飲食物の平均的な提供までの待ち時間が経過した後に、飲食中の滞在状態へと遷移するようにしてもよい。また、例えば、飲食物の提供が完了した後、３０分や４５分と言った所定の時間後に自動的にユーザの飲食が完了した滞在状態へと遷移するようにしてもよい。

特に、注文を受けた際には、店舗スタッフがハンディ端末４を操作するために滞在状態の更新を忘れることはないが、その他の滞在情報は、店舗スタッフが確認してハンディ端末４を操作しなくてはならないため、ハンディ端末４を介しての滞在情報の更新が為されない場合がある。このような場合に、予め決められた時間が経過すると自動的に滞在状態が遷移するようにしておくことは有効である。

（第１変形例）
図１０は、第１変形例に係るシナリオ制御部３４の機能を示すブロック図である。この図１０に示すように、シナリオ制御部３４は、受信部３４１と、滞在状態判断部３４２と、情報取得部３４３と、対話制御部３４５と、を備える一方、上述した実施形態とは異なり、推奨メニュー提供部３４４を有していない。すなわち、推奨メニュー提供部３４４は、シナリオ制御部３４の必須の構成要素ではない。

この場合、情報取得部３４３は、図４におけるステップＳ１４において、推奨メニュー情報を得ずに、シナリオデータを取得する。以下のステップを上述した実施形態と同様に行うことにより、シナリオ制御部３４を介して、ユーザは、ロボット２との間で、ユーザの滞在状態に適した対話を行うことが可能である。このような構成においてもお薦めメニューのリコメンドをしたい場合には、シナリオＤＢ３３に、お薦めメニューを含めたシナリオデータを格納するようにしてもよい。

本変形例によれば、シナリオ制御部の構造を、上述した実施形態と比べて簡易なものとすることが可能となる。店舗は、シナリオＤＢ３３やシナリオ制御部３４の状況に応じて図２に示した構造と、図１０に示した構造を適宜選択するようにしてもよい。

（第２変形例）
図１１は、第２変形例に係るロボット制御システム１の一例を示すブロック図である。上述した実施形態においては、シナリオＤＢ３３は、操作端末３内に設置されているものであったが、これには限られない。例えば、図１１に示すように、シナリオＤＢ３３は、操作端末３の外部にあるものでもよい。そして、シナリオ制御部３４は、ネットワーク６を介してシナリオＤＢ３３と接続される。

シナリオＤＢ３３は、操作端末３の外部の所定のサーバに備えられているものでもよいし、特定のサーバではなく、ネットワーク６により接続される所謂クラウド上に存在するデータベース（分散型データベースを含む）であってもよい。ネットワーク６と、操作端末３又はシナリオＤＢ３３は、有線又は無線の通信を介して接続される。

本変形例によれば、シナリオＤＢ３３を操作端末３内ではなく外部に有することにより、操作端末３の容量を確保することが可能となるとともに、シナリオデータの一元管理をすることも可能となる。さらに、シナリオＤＢ３３がクラウド上に存在し、特定多数の編集者がシナリオデータを編集、あるいは、追加することが可能であるように設定することにより、よりバリエーションに富んだ対話内容を選択することも可能となる。

（第３変形例）
図１２は、第３変形例に係る対話における表示部３５の様子を示す図である。上述した実施形態においては、ロボット２が必須の構成要素であったが、本変形例は、ロボット２が物理的には存在しない例である。

例えば、図１２に示すように、操作端末３の表示部３５にロボット２の代わりとなるロボットを描画するようにしてもよい。このようにすることにより、ユーザは、操作端末３内に表示された仮想的なロボットと対話をすることが可能となる。この場合、あらかじめ表示するロボットの候補を複数設定しておくことにより、ユーザが好みのロボットを対話する相手として選択できるようにしてもよい。

なお、このように、表示部３５に表示するものには限られない。例えば、ロボット自体を表示部３５に表示しない、すなわち、文字を用いてロボット側シナリオデータを表示することも可能である。より具体的な一例としては、吹き出し文字等を用いて、仮想的なロボットとの対話を行ってもよい。

他の例では、ＡＲ（Augmented Reality）技術を用い、操作端末３に搭載されているカメラでユーザが着席しているテーブル上を表示部３５へと映すことにより、表示部３５を介して、あたかもテーブル上にロボット２が存在するように投影してもよい。テーブル上又はテーブル周辺の所定の位置にＡＲマーカを設けてもよいし、マーカレスのＡＲを用いてもよい。この場合、上記の例と同様に、あらかじめＡＲとして表示するロボットの候補を複数設定しておくことにより、ユーザが好みのロボットを対話する相手として選択できるようにしてもよい。

本変形例によれば、ロボット２が必須ではなく、ユーザは、操作端末３を用いて滞在状態に応じた対話を楽しむこともできる。このようにすることにより、コストの削減となるとともに、ユーザが使用するテーブルを広く使用することも可能となる。なお、これらの場合、ロボットの音声を、操作端末３から発話させるようにしてもよい。ユーザにより表示するロボットが選択できるようにした場合、選択したロボットに応じた声の高さ、声質、声色等に変更してロボットの発話を行うようにしてもよい。

（第４変形例）
図１３は、第４変形例に係るロボット制御システム１の構成を示す図である。この図１３に示すように、動作生成部３２、シナリオ制御部３４、及び、シナリオＤＢ３３は、操作端末３ではなく、ロボット２内に備えられているものとしてもよい。すなわち、主要な制御機能を操作端末３ではなく、ロボット２に備えるようにしてもよい。動作生成部３２、及び、シナリオ制御部３４の動作は、上述した実施形態における動作と大きく異なることはなく、本変形例においても、図４に示すフローチャートにしたがって対話の処理が実行される。

本変形例によれば、操作端末３の構成を簡略化でき、また、操作端末３からロボット２へと送信する通信料を削減できるため、操作端末３とロボット２との間の通信回線の性能が低い場合でも、支障なくロボット２との対話を行うことができる。なお、動作生成部３２は、操作端末３及びロボット２の外部に設けられていてもよく、例えば、店舗システム５に内蔵されていてもよいし、店舗システム５とは別個の通信機器内に設けてもよい。

なお、上述した全ての実施形態及び変形例においては、対話は、ユーザ、又は、ロボット２が何かしらの情報を出力している状態として説明したが、これには限られない。例えば、食事中であれば、ロボット２との対話の必要性は低くなるので、このような場合においては、無言のシナリオをあらかじめ準備しておき、この無言のシナリオを出力するようにしてもよい。

上述した全ての実施形態及び変形例に係るロボット制御システム１は、既述したように飲食サービスに好適に適用することができるが、飲食サービス以外の種々のサービスに適用されてもよい。

本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１ ロボット制御システム、２ ロボット、３ 操作端末、３４ シナリオ制御部

Claims (11)

1. 飲食店に入店した顧客の前記飲食店内での滞在状態を判断する、滞在状態判断部と、
   前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、
   前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う、対話制御部と、
   を備える対話制御装置。
2. 前記滞在状態判断部は、店舗システムからの情報に基づいて、前記顧客の前記飲食店内での滞在状態を判断する、請求項１に記載の対話制御装置。
3. 前記顧客が飲食物の注文を行ったことを示す信号を前記店舗システムから受信する、受信部をさらに備え、
   前記滞在状態判断部は、前記受信部にて前記信号が受信されると、注文した飲食物を前記顧客が待っている状態であることを判断する、請求項２に記載の対話制御装置。
4. 前記滞在状態判断部にて判断される前記顧客の滞在状態は、時間の経過により変化する状態である、請求項１又は請求項２に記載の対話制御装置。
5. 前記滞在状態判断部にて判断される前記顧客の滞在状態は、
   前記顧客が前記飲食店に入店または着席してから飲食物を注文するまでの状態と、
   前記顧客が注文した飲食物が提供されるのを待っている状態と、
   前記顧客が飲食物の飲食を完了するまでの状態と、
   前記顧客が飲食物の飲食を完了してから退店するまでの状態と、のうち少なくとも１つの状態を含む請求項４に記載の対話制御装置。
6. 前記顧客が飲食物の注文を行っていない場合に、前記顧客に飲食物の推奨メニューを提供する、推奨メニュー提供部を備え、
   前記情報取得部は、飲食物のメニュー選択に関する前記顧客との対話において、前記顧客が前記推奨メニューを選択した場合と、前記推奨メニューを選択せずに別のメニューを選択した場合とで、それぞれ相違する対話シナリオ情報を取得する請求項１乃至５のいずれか１項に記載の対話制御装置。
7. それぞれ異なる複数の対話シナリオ情報を蓄積するシナリオ蓄積部を備え、
   前記情報取得部は、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を、前記シナリオ蓄積部から取得する、請求項１乃至６のいずれか１項に記載の対話制御装置。
8. 前記情報取得部は、前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を、通信ネットワークを介して取得する、請求項１乃至６のいずれか１項に記載の対話制御装置。
9. 指示信号に応じた動作を行う、ロボットと、
   前記指示信号を生成して前記ロボットに送信する、操作端末と、を備え、
   前記操作端末は、
   店舗システムからの情報に基づいて、飲食店に入店した顧客の前記飲食店内での滞在状態を判断する、滞在状態判断部と、
   前記滞在状態判断部で判断された前記顧客の滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、
   前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う対話制御部と、
   を有するロボット制御システム。
10. 前記操作端末は、前記店舗システムから前記顧客の注文情報を受信する、受信部を有し、
    前記滞在状態判断部は、前記受信部にて前記注文情報が受信されると、注文した飲食物を前記顧客が待っている状態であることを判断する、請求項９に記載のロボット制御システム。
11. 前記店舗システムは、前記注文情報に加えて、前記顧客が入店したことを示す第１情報、前記顧客が着席したことを示す第２情報、注文した飲食物が前記顧客に提供されたことを示す第３情報、前記顧客が提供された飲食物の飲食を完了したことを示す第４情報の少なくとも１つを含む滞在情報を無線送信し、
    前記操作端末の前記受信部は、前記店舗システムが送信した前記注文情報および前記滞在情報を受信し、
    前記滞在状態判断部は、前記受信部にて受信した前記注文情報および前記滞在情報に基づいて前記顧客の滞在状態を判断する、
    請求項１０に記載のロボット制御システム。

Images