JP6065768B2 - 情報処理装置、情報処理方法およびプログラム - Google Patents

Description

本開示は、情報処理装置、情報処理方法およびプログラムに関する。

ユーザに代わって各種の手順を実行してくれるコンピュータエージェント（コンピュータ上で動作するエージェントソフトウェア。以下では単にエージェントともいう）については、既にいろいろな技術が提案されている。例えば、特許文献１には、会議開催にあたり、出席予定者のスケジュール上の空き時間を各ユーザのエージェントに問い合わせ、その結果に基づいて最適な開催時間を決定するエージェントが記載されている。

特開平９−９１３４１号公報

しかしながら、例えば上記の特許文献１に記載された技術では、スケジュール上の空き時間に応じて自動的に開催時間が決定されるため、登録されたスケジュールからは得られない情報、例えばユーザが会議に出席するための移動時間や、全員が会議に出席することが困難な場合の出席予定者の優先順位などについては、考慮することが難しかった。

そこで、本開示では、エージェントがユーザからの情報を取り込むことによってより適切な手順を実行することを可能にする、新規かつ改良された情報処理装置、情報処理方法およびプログラムを提案する。

本開示によれば、リクエストを送信するリクエスト送信部と、上記リクエストに対応するレスポンスを受信するレスポンス受信部と、上記レスポンスを解析するレスポンス解析部と、上記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力するテキスト出力部と、上記レスポンスの解析結果、または上記ユーザによって入力されたテキストに基づいて上記リクエストを新たに生成するリクエスト生成部と、上記リクエストが新たに生成されるタイミングを、上記生成されたテキストが出力されるタイミングに基づいて制御するタイミング制御部とを含む情報処理装置が提供される。

また、本開示によれば、リクエストを送信することと、上記リクエストに対応するレスポンスを受信することと、上記レスポンスを解析することと、上記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力することと、上記レスポンスの解析結果、または上記ユーザによって入力されたテキストに基づいて上記リクエストを新たに生成することと、上記リクエストが新たに生成されるタイミングを、上記生成されたテキストが出力されるタイミングに基づいて制御することとを含む情報処理方法が提供される。

また、本開示によれば、リクエストを送信する機能と、上記リクエストに対応するレスポンスを受信する機能と、上記レスポンスを解析する機能と、上記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力する機能と、上記レスポンスの解析結果、または上記ユーザによって入力されたテキストに基づいて上記リクエストを新たに生成する機能と、上記リクエストが新たに生成されるタイミングを、上記生成されたテキストが出力されるタイミングに基づいて制御する機能とをコンピュータに実現させるためのプログラムが提供される。

以上説明したように本開示によれば、エージェントがユーザからの情報を取り込むことによってより適切な手順を実行することができる。

本開示の第１の実施形態に係る情報処理システムの概略的な構成を示す図である。 本開示の第１の実施形態に係るクライアント装置の概略的な構成を示すブロック図である。 本開示の第１の実施形態に係るサーバ装置の概略的な構成を示すブロック図である。 本開示の第１の実施形態に係るエージェントの概略的な機能構成を示すブロック図である。 本開示の第１の実施形態において最初にリクエストを送信する場合の処理の例を示すフローチャートである。 本開示の第１の実施形態において２回目以降にリクエストを送信する場合の処理の例を示すフローチャートである。 本開示の第１の実施形態の具体的な例について説明するための図である。 本開示の第２の実施形態において２回目以降にリクエストを送信する場合の処理の例を示すフローチャートである。 本開示の第２の実施形態の具体的な例について説明するための図である。 本開示の第２の実施形態の具体的な例について説明するための図である。 本開示の第２の実施形態の具体的な例について説明するための図である。 本開示の第２の実施形態の具体的な例について説明するための図である。 本開示の第２の実施形態の具体的な例について説明するための図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．第１の実施形態
１−１．システム構成
１−２．機能構成
１−３．処理フロー
１−４．具体的な例
２．第２の実施形態
２−１．処理フロー
２−２．具体的な例
３．補足

（１．第１の実施形態）
（１−１．システム構成）
図１は、本開示の第１の実施形態に係る情報処理システムの概略的な構成を示す図である。図１を参照すると、システム１０は、クライアント装置１００と、サーバ装置２００とを含む。単一のサーバ装置２００、または複数のサーバ装置２００の協働によって、サーバ２０が構成される。サーバ２０は、ネットワークを介してクライアント装置１００と通信し、クライアント装置１００にサービスを提供する。

クライアント装置１００では、エージェント３００が動作している。図示された例では、２つのクライアント装置１００ａ，１００ｂがあり、それぞれの装置でエージェント３００ａ，３００ｂが動作している。エージェント３００ａ，３００ｂは、それぞれのユーザ（ＵＳＥＲ＿ａ，ＵＳＥＲ＿ｂ）と対話し、対話によって得られた情報に基づいて、ユーザ（ＵＳＥＲ＿ａ，ＵＳＥＲ＿ｂ）に代わってさまざまな手順を実行する。

ここで、エージェント３００に関する処理は、主にクライアント装置１００で実行されてもよい。この場合、クライアント装置１００ａ，１００ｂのそれぞれがエージェント３００に関する処理を実行する。クライアント装置１００ａでエージェント３００ａが生成したリクエストは、サーバ２０を介してクライアント装置１００ｂに伝送され、クライアント装置１００ｂでエージェント３００ｂがこれを処理する。エージェント３００ｂがリクエストに対して生成したレスポンスは、再びサーバ２０を介してクライアント装置１００ａに伝送される。

あるいは、エージェント３００に関する処理は、クライアント装置１００とサーバ２０とに分散して、または主にサーバ２０で実行されてもよい。この場合、クライアント装置１００ａ，１００ｂがユーザとの対話によって取得した情報はサーバ２０に送信され、サーバ２０がそれに基づいて処理を実行する。また、サーバ２０が生成した情報がクライアント装置１００ａ，１００ｂに送信され、ユーザとの対話において出力される。従って、エージェント３００ａとエージェント３００ｂとの間でのリクエストおよびレスポンスは、サーバ２０において内部的に伝送される。

（クライアント装置の構成）
図２は、本開示の第１の実施形態に係るクライアント装置の概略的な構成を示すブロック図である。図２を参照すると、クライアント装置１００は、プロセッサ１０２、メモリ１０４、ストレージ１０６、通信モジュール１０８、ディスプレイ１１０およびタッチセンサ１１２によって構成されるタッチパネル１１４、スピーカ１１６、マイクロフォン１１８、センサモジュール１２０、カメラモジュール１２２、および接続ポート１２４を含みうる。

プロセッサ１０２は、例えばＣＰＵ（Central Processing unit）、ＤＳＰ（Digital Signal Processor）、またはＡＳＩＣ（Application Specific Integrated Circuit）などによって実現され、メモリ１０４に格納されたプログラムに従って動作することによって各種の機能を実現する。プロセッサ１０２は、クライアント装置１００の各部を制御することによって、各種の入力を取得し、また各種の出力を提供する。なお、プロセッサ１０２によって実現される機能の詳細については後述する。

メモリ１０４は、例えばＲＡＭ（Random Access Memory）またはＲＯＭ（Read Only Memory）として用いられる半導体メモリによって実現される。メモリ１０４には、例えばプロセッサ１０２が動作するためのプログラムが格納される。このプログラムは、例えばストレージ１０６から読み出されてメモリ１０４に一時的に展開されてもよく、メモリ１０４に持続的に格納されていてもよい。あるいは、プログラムは、通信モジュール１０８によって受信されて、メモリ１０４に一時的に展開されてもよい。メモリ１０４は、さらに、プロセッサ１０２の処理によって生成された各種のデータを、一時的または持続的に格納する。

ストレージ１０６は、例えばＨＤＤ（Hard Disk Drive）などの磁気ディスク、光ディスク、もしくは光磁気ディスクなどを利用した記憶装置、またはフラッシュメモリなどによって実現される。ストレージ１０６には、例えばプロセッサ１０２が動作するためのプログラムや、プロセッサ１０２の処理によって生成された各種のデータが持続的に格納される。ストレージ１０６は、リムーバブルメディアを含んで構成されてもよいし、クライアント装置１００に内蔵されてもよい。

通信モジュール１０８は、プロセッサ１０２の制御に従って有線または無線のネットワーク通信を実行する各種の通信回路によって実現される。無線通信を実行する場合、通信モジュール１０８はアンテナを含んでもよい。通信モジュール１０８は、例えばインターネットやＬＡＮ（Local Area Network）、またはＢｌｕｅｔｏｏｔｈ（登録商標）などの通信規格に従ってネットワーク通信を実行する。通信モジュール１０８によって、クライアント装置１００で生成された情報がサーバ２０または他のクライアント装置１００などに送信されるとともに、サーバ２０または他のクライアント装置１００から各種の情報が受信されうる。

ディスプレイ１１０は、例えばＬＣＤ（Liquid Crystal Display）または有機ＥＬ（Electro-Luminescence）ディスプレイなどによって実現される。ディスプレイ１１０は、プロセッサ１０２の制御に従って各種の情報を画像として表示する。図示された例では、入力手段としてディスプレイ１１０とタッチセンサ１１２とによって構成されるタッチパネル１１４が用いられるため、ディスプレイ１１０はタッチセンサ１１２によって操作可能なＧＵＩ（Graphical User Interface）画像を表示する。

タッチセンサ１１２は、例えばディスプレイ１１０に対応する位置に配設される静電容量方式などのセンサによって実現される。タッチセンサ１１２は、ディスプレイ１１０に表示されたＧＵＩ画像に対するユーザのタッチ操作を取得する。なお、他の実施形態では、タッチセンサ１１２とともに、またはこれに代えて、マウスやタッチパッドなどのポインティングデバイスや、ボタンなどの他の入力装置が採用されてもよい。

スピーカ１１６は、プロセッサ１０２の制御に従って各種の情報を音声として出力する。マイクロフォン１１８は、例えばユーザによる発話音声など、クライアント装置１００の周辺で発生しているさまざまな種類の音声を取得し、音声データとしてプロセッサ１０２に提供する。

センサモジュール１２０は、例えば加速度センサ、ジャイロセンサ、地磁気センサ、光センサ、気圧センサ、または音センサなどの各種のセンサと、センサに付属する処理回路とによって実現される。センサモジュール１２０は、例えばクライアント装置１００の筐体に作用する加速度や筐体の向きなど、クライアント装置１００自体の状態に関する情報を取得するのに加え、クライアント装置１００の周辺の明るさや騒音など、クライアント装置１００の周辺環境に関する情報を取得してもよい。また、センサモジュール１２０には、ＧＰＳ（Global Positioning System）信号を受信してクライアント装置１００の緯度、経度および高度を測定するＧＰＳセンサが含まれてもよい。

カメラモジュール１２２は、例えばＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子と、撮像素子への被写体像の結像を制御するためのレンズなどの光学系と、撮像素子および光学系を駆動させる駆動回路とによって実現される。カメラモジュール１２２は、撮像素子が被写体像を撮像することによって生成された静止画または動画を、画像データとしてプロセッサ１０２に提供する。

接続ポート１２４は、クライアント装置１００に外部装置を直接的に接続するためのポートであり、例えばＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、またはＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）ポートなどによって実現される。接続ポート１２４に接続される外部装置は、例えば表示装置（外部ディスプレイなど）、入力装置（キーボードやマウスなど）、または記憶装置（外部ＨＤＤなど）でありうるが、これらの例には限られない。

以上で説明したような構成要素を含むクライアント装置１００は、例えばスマートフォン、タブレット端末、または各種のＰＣ（Personal Computer）などでありうる。また、クライアント装置１００は、メディアプレーヤ、ゲーム機、またはテレビなどであってもよい。本実施形態において、クライアント装置１００は、単独で、またはサーバ装置２００との協働によって、本開示に係る情報処理装置の機能を実現しうる。

（サーバ装置の構成）
図３は、本開示の第１の実施形態に係るサーバ装置の概略的な構成を示すブロック図である。図３を参照すると、サーバ装置２００は、プロセッサ２０２、メモリ２０４、ストレージ２０６、および通信モジュール２０８を含みうる。

なお、以下の説明では、サーバ装置２００を、ネットワーク上でクライアント装置１００にサービスを提供することを主な目的として設置され、それ自体が設定操作の場合などを除きユーザへの情報出力や操作入力の取得などを実施しない装置として説明するが、サーバ装置２００はこのような装置には限られず、例えばクライアント装置１００と同様の構成を有する装置であってもよい。つまり、例えば、ユーザが自宅に設置しているデスクトップＰＣがサーバ装置２００として機能し、ユーザが携帯しているスマートフォンがクライアント装置１００として機能するような例も可能である。

プロセッサ２０２は、例えばＣＰＵ、ＤＳＰ、またはＡＳＩＣなどによって実現され、メモリ２０４に格納されたプログラムに従って動作することによって各種の機能を実現する。プロセッサ２０２は、通信モジュール２０８を介してクライアント装置１００から送信された情報を取得し、この情報に基づいて各種の処理を実行する。プロセッサ２０２は、処理結果の情報を、通信モジュール２０８を介してクライアント装置１００に送信する。ここで、サーバ装置２００は、複数のクライアント装置１００にサービスを提供することが可能でありうる。従って、プロセッサ２０２は、複数のクライアント装置１００からそれぞれ送信された情報に基づいて処理を実行し、処理結果の情報を元の情報を送信したクライアント装置１００とは別のクライアント装置１００に送信してもよい。

メモリ２０４は、例えばＲＡＭまたはＲＯＭとして用いられる半導体メモリによって実現される。メモリ２０４には、例えばプロセッサ２０２が動作するためのプログラムが格納される。このプログラムは、例えばストレージ２０６から読み出されてメモリ２０４に一時的に展開されてもよく、メモリ２０４に持続的に格納されていてもよい。あるいは、プログラムは、通信モジュール２０８によって受信されて、メモリ２０４に一時的に展開されてもよい。メモリ２０４は、さらに、プロセッサ２０２の処理によって生成された各種のデータを、一時的または持続的に格納する。

ストレージ２０６は、例えばＨＤＤなどの磁気ディスク、光ディスク、もしくは光磁気ディスクなどを利用した記憶装置、またはフラッシュメモリなどによって実現される。ストレージ２０６には、例えばプロセッサ２０２が動作するためのプログラムや、プロセッサ２０２の処理によって生成された各種のデータが持続的に格納される。ストレージ２０６は、リムーバブルメディアを含んで構成されてもよいし、サーバ装置２００に内蔵されてもよい。

通信モジュール２０８は、プロセッサ２０２の制御に従って有線または無線のネットワーク通信を実行する各種の通信回路によって実現される。無線通信を実行する場合、通信モジュール２０８はアンテナを含んでもよい。通信モジュール２０８は、例えばインターネットやＬＡＮ、またはＢｌｕｅｔｏｏｔｈ（登録商標）などの通信規格に従ってネットワーク通信を実行する。通信モジュール２０８によって、サーバ装置２００で生成された情報がクライアント装置１００または他のサーバ装置２００に送信されるとともに、クライアント装置１００または他のサーバ装置２００から各種の情報が受信されうる。サーバ２０が複数のサーバ装置２００の協働によって構成される場合、それぞれのサーバ装置２００のプロセッサ２０２が、通信モジュール２０８を介して処理に関する情報をやりとりする。

（１−２．機能構成）
図４は、本開示の第１の実施形態に係るエージェントの概略的な機能構成を示すブロック図である。図４を参照すると、本実施形態では、エージェント３００の機能として、音声取得機能３５１、音声認識機能３５３、リクエスト生成機能３５５、リクエスト送信機能３５７、レスポンス受信機能３５９、レスポンス解析機能３６１、タイミング制御機能３６３、テキスト生成機能３６７、およびテキスト出力機能３６９の各機能が実現される。

これらの機能は、例えばすべてがクライアント装置１００のプロセッサ１０２、またはサーバ装置２００のプロセッサ２０２によって実現されてもよい。例えば、音声取得機能３５１がサーバ装置２００のプロセッサ２０２によって実現される場合、プロセッサ２０２は、クライアント装置１００のマイクロフォン１１８によって取得された音声データを、通信モジュール２０８によるクライアント装置１００との間のネットワーク通信を介して取得する。また、例えば、テキスト出力機能３６９がサーバ装置２００のプロセッサ２０２によって実現される場合、プロセッサ２０２は、生成された音声データを通信モジュール２０８によるネットワーク通信を介してクライアント装置１００に提供し、クライアント装置１００のスピーカ１１６から音声を出力させる。

また、上記の機能は、その一部がクライアント装置１００のプロセッサ１０２によって実現され、残りがサーバ装置２００のプロセッサ２０２によって実現されてもよい。この場合、プロセッサ１０２とプロセッサ２０２は、通信モジュール１０８，２０８の間のネットワーク通信を介して協働する。サーバ２０が複数のサーバ装置２００によって構成される場合、上記の機能のうちの少なくとも一部が、複数のサーバ装置２００に分散して実現されうる。この場合、１つの機能が複数のサーバ装置２００に分散して実現されてもよいし、１つのサーバ装置２００が複数の機能を実現してもよい。

音声取得機能３５１は、クライアント装置１００のマイクロフォン１１８を介して、ユーザの発話音声を表す音声データを取得する。音声認識機能３５３は、音声取得機能３５１によって取得された音声データに基づいて音声認識を実行し、音声データをテキスト（文字データ）に変換する。なお、音声認識については、既に知られている各種の技術を適宜利用することが可能であるため、ここでは詳細な説明を省略する。

リクエスト生成機能３５５は、音声認識機能３５３において認識されたテキスト（ユーザによって音声入力されたテキスト）に基づいてリクエストを生成する。リクエスト生成機能３５５は、例えばテキストに対して必要に応じて形態素解析や構文解析などの自然言語処理を実行し、テキストの意味内容を把握する。なお、自然言語処理についても、既に知られている各種の技術を適宜利用することが可能であるため、ここでは詳細な説明を省略する。なお、リクエスト生成機能３５５は、レスポンス解析機能３６１によるレスポンスの解析結果に基づいてリクエストを生成することも可能であるが、これについては後述する。

ここで、リクエスト生成機能３５５によって生成されるリクエストは、例えばシステム１０内で規定された所定のプロトコルに従って生成されるコードでありうる。この場合、他のエージェント３００は、送信されたリクエスト（受信される側ではレスポンスとして扱われる）を容易に解析することが可能である。あるいは、リクエスト生成機能３５５によって生成されるリクエストには、上記のコードに加えて、またはこれに代えて、ユーザによって音声入力されたテキストが含まれてもよい。この場合、例えば後述するテキスト生成機能３６７は、レスポンス（他のエージェント３００によって送信されたリクエスト）に対応するテキストを容易に生成することが可能である。

なお、リクエスト生成機能３５５は、ユーザによって音声入力されたテキストの意味内容に応じて様々なリクエストを生成することが可能である。例えば、「明日の天気が知りたい」や、「今日の夜のテレビで何か見るものはある？」といった入力に対しては、サーバ２０またはその他のサービスを提供するサーバに対して「明日の天気予報」や「今夜のおすすめ番組」などの情報のリクエストが生成されうる。以下の説明では、他のエージェント３００との間でスケジュール調整を実行する機能について特に説明し、その他の機能については説明を省略するが、これらの機能も既に知られている技術を利用して実現することが可能であるため、エージェント３００がスケジュール調整以外の機能をも実現しうることは当業者には自明である。

リクエスト送信機能３５７は、リクエスト生成機能３５５によって生成されたリクエストを送信する。リクエストの送信先は、他のエージェント３００でありうる。上記のように、エージェント３００の機能は、各ユーザが使用するクライアント装置１００において実現される場合もあれば、サーバ２０において実現される場合もある。従って、リクエスト送信機能３５７によるリクエストの送信は、クライアント装置１００同士の間でのネットワーク通信を介した送信でもありうるし、サーバ２０内での内部的な送信でもありうる。

レスポンス受信機能３５９は、リクエスト送信機能３５７によって送信されたリクエストに対応するレスポンスを受信する。なお、本明細書で説明されているエージェント３００にとってのリクエストおよびレスポンスは相対的なものである。つまり、エージェント３００ａによって送信されるリクエストは、送信先（受信側）のエージェント３００ｂではレスポンスとして扱われる。逆に、エージェント３００ｂによって送信されるリクエストは、エージェント３００ａではレスポンスとして扱われる。それゆえ、あるエージェント３００についてみれば、リクエストを送信する前にレスポンスが受信されることもありうる。

レスポンス解析機能３６１は、レスポンス受信機能３５９によって受信されたレスポンスを解析する。ここで、レスポンスは、他のエージェント３００が送信したリクエストである。従って、リクエストについて説明したように、レスポンスは、例えばシステム１０内で規定された所定のプロトコルに従って生成されたコードでもありうるし、送信側のエージェント３００においてユーザによって音声入力されたテキストでもありうる。レスポンス解析機能３６１は、このようなレスポンスの内容に対応して、例えばプロトコルに従って単純にレスポンスを解析してもよく、自然言語処理を実行してレスポンスに含まれるテキストの意味内容を把握してもよい。

ここで、レスポンス解析機能３６１によるレスポンスの解析結果は、タイミング制御機能３６３を経てリクエスト生成機能３５５に提供されるとともに、テキスト生成機能３６７にも提供される。以下ではまず、テキスト生成機能３６７について説明する。

テキスト生成機能３６７は、レスポンス解析機能３６１におけるレスポンスの解析結果に基づいてテキストを生成する。生成されるテキストは、受信されたレスポンスの意味内容をユーザに通知するためのものであり、例えば会話文を構成しうる。ここで、レスポンスに、送信側のエージェント３００においてユーザによって音声入力されたテキストが含まれる場合、テキスト生成機能３６７は、そのテキストをそのまま利用してもよい。さらに、テキスト生成機能３６７は、後述するようにリクエスト生成機能３５５によって自動的に新たなリクエストが生成された場合、生成されたリクエストに基づくテキストを生成してもよい。テキスト出力機能３６９は、テキスト生成機能３６７によって生成されたテキストを、クライアント装置１００のスピーカ１１６を介して、ユーザに向けて音声出力する。

一方、タイミング制御機能３６３を経てリクエスト生成機能３５５に提供されたレスポンスの解析結果は、リクエスト生成機能３５５による新たなリクエストの生成に利用される。リクエスト生成機能３５５は、レスポンスの解析結果に基づいて、必要に応じてスケジュールＤＢ３６５を参照して、新たなリクエストを生成する。スケジュールＤＢ３６５は、クライアント装置１００のストレージ１０６、またはサーバ装置２００のストレージ２０６によって実現され、エージェント３００のユーザのスケジュール情報を格納する。リクエスト生成機能３５５は、例えばレスポンスが他のユーザのスケジュール情報に基づいて生成されたスケジュール調整の依頼であるような場合、スケジュールＤＢ３６５に格納されたユーザのスケジュール情報を参照して、このレスポンスに対する新たなリクエストを生成する。

ここで、タイミング制御機能３６３は、リクエスト生成機能３５５が新たなリクエストを生成するタイミングを、テキスト出力機能３６９によってテキストが音声出力されるタイミングに基づいて制御する。より具体的には、タイミング制御機能３６３は、テキスト出力機能３６９によってテキストが音声出力されてから、リクエスト生成機能３５５によってリクエストが新たに生成されるまでの間に待機時間を設定する。これによって、例えば、レスポンス解析機能３６１によるレスポンスの解析結果に基づいてリクエスト生成機能３５５がすぐに新たなリクエストを生成することが可能であったとしても、タイミング制御機能３６３によって、待機時間の間はリクエスト生成機能３５５が新たなリクエストを生成しないように制御される。

この待機時間は、音声出力されたテキストに対するユーザの返答を待ち受けるために設けられうる。従って、待機時間の間に、音声取得機能３５１によってユーザの発話音声の音声データが取得された場合、リクエスト生成機能３５５は、ユーザによって音声入力された新たなテキストに基づいて新たなリクエストを生成し、リクエスト送信機能３５７が生成されたリクエストを送信する。この場合、待機時間は途中で終了されてもよい。

一方、待機時間の終了までに音声取得機能３５１がユーザの発話音声の音声データを取得しなかった場合、つまり待機時間にユーザによってテキストが音声入力されなかった場合、リクエスト生成機能３５５は、レスポンス解析機能３６１によるレスポンスの解析結果に基づいて自動的に新たなリクエストを生成し、リクエスト送信機能３５７が生成されたリクエストを送信する。

つまり、本実施形態では、テキスト出力機能３６９によって、受信されたレスポンスの意味内容がユーザに向けて音声出力されるとともに、それからしばらくの間、タイミング制御機能３６３によって、リクエスト生成機能３５５によるリクエストの自動生成が抑制されることによって、受信されたレスポンスに対するユーザの発話による介入が可能になる。また、ユーザの介入がなかった場合には、レスポンスに対して自動的に新たなリクエストが生成されるため、ユーザが介入の必要を感じない場合や、介入する余裕がない場合などには、ユーザの手間をとらせることなくスケジュール調整を進めることが可能である。

（１−３．処理フロー）
（最初のリクエスト送信時の処理）
図５は、本開示の第１の実施形態において最初にリクエストを送信する場合の処理の例を示すフローチャートである。

この場合、まず、音声取得機能３５１がユーザの発話音声の音声データを取得する（ステップＳ１０１）。次に、音声認識機能３５３が、取得された音声データに対する音声認識を実行する（ステップＳ１０３）。さらに、リクエスト生成機能３５５が音声認識の結果として得られたテキストに基づいてリクエストを生成し（ステップＳ１０５）、リクエスト送信機能３５７が生成されたリクエストを送信する（ステップＳ１０７）。

以上のような処理は、例えば、エージェント３００が、ユーザの発話を取得することによって、他のエージェント３００とのやりとりを開始するときに実行される。

（２回目以降のリクエスト送信時の処理）
図６は、本開示の第１の実施形態において２回目以降にリクエストを送信する場合の処理の例を示すフローチャートである。なお、上記の図５に示す最初のリクエストを受信するエージェント３００、つまりリクエストよりも先にレスポンスを受信するエージェント３００での処理も同様である。

この場合、まず、レスポンス受信機能３５９が他のエージェント３００からのレスポンスを受信する（ステップＳ１２１）。次に、レスポンス解析機能３６１がレスポンスを解析する（ステップＳ１２３）。さらに、レスポンスの解析結果に基づいてテキスト生成機能３６７がテキストを生成し（ステップＳ１２５）、テキスト出力機能３６９が生成されたテキストをユーザに向けて音声出力する（ステップＳ１２７）。ここで、タイミング制御機能３６３は、リクエスト生成機能３５５による新たなリクエストの生成を所定の時間だけ待機させる(ステップＳ１２９)。

ステップＳ１２９の待機の間、音声取得機能３５１は、ユーザの発話音声の音声データを待ち受けている（ステップＳ１３１）。ここで、発話音声の音声データが取得された場合（ＹＥＳ）、音声認識機能３５３が取得された音声データに対する音声認識を実行する（ステップＳ１３３）。この場合、リクエスト生成機能３５５は、音声認識によって得られたテキストに基づいて新たなリクエストを生成する（ステップＳ１３７）。

一方、ステップＳ１３１でユーザの発話音声の音声データを待ち受けた音声取得機能３５１が音声データを取得しなかった場合（ＮＯ）、リクエスト生成機能３５５は、レスポンスの解析結果に基づいて、必要に応じてスケジュールＤＢ３６５を参照して（ステップＳ１３５）、自動的に新たなリクエストを生成する（ステップＳ１３７）。

ステップＳ１３７でリクエスト生成機能３５５によって生成されたリクエストは、リクエスト送信機能３５７によって送信される（ステップＳ１３９）。なお、例えば３人以上のユーザのエージェント３００の間でスケジュール調整をしているような場合、ステップＳ１３９におけるリクエストの送信先は、必ずしもステップＳ１２１におけるレスポンスの送信元とは一致しない。

本実施形態では、以上のような処理が各エージェント３００において繰り返し実行されることによって、ユーザ間でのスケジュール調整が実現される。その具体的な例について、続いて説明する。

（１−４．具体的な例）
図７は、本開示の第１の実施形態の具体的な例について説明するための図である。図示された例では、花子（ＨＡＮＡＫＯ）のエージェント３００ａと太郎（ＴＡＲＯ）のエージェント３００ｂとの間で、スケジュール調整のためのやりとりが実行されている。

なお、上述の通り、本実施形態におけるリクエストおよびレスポンスは各エージェント３００において定義される相対的なものであり、例えばエージェント３００ａにおいて定義されるリクエストは、エージェント３００ｂではレスポンスになる。そこで、以下の例では、説明を簡単にするために、リクエストおよびレスポンスをメッセージとして総称する。

図示された例では、まず、花子の発話によってやりとりが開始される。彼女は、「１２／２４に太郎とデートがしたい」と発話する。この発話音声を取得したエージェント３００ａは、「太郎の予定を聞いてみます」という返答を音声出力した上で（上記の機能構成やフローチャートには示されていないが、ユーザの発話に対する音声での応答は、エージェントの一般的な機能として既に知られている）、花子からの誘いを伝えるメッセージを太郎のエージェント３００ｂに送信する。ここで、実際に送信されるメッセージは、例えばシステム１０内で規定されたプロトコルに従って生成されたコードでありうる。

太郎のエージェント３００ｂは、上記のメッセージを受信すると、テキスト生成機能３６７によって「花子から１２／２４にデートのお誘いがあります」というテキスト（ＴＥＸＴ１）を生成し、これを太郎に向けて音声出力する。ここで、タイミング制御機能３６３によって、テキスト（ＴＥＸＴ１）の出力後、太郎のエージェント３００ｂは、所定の時間だけ太郎の返答を待機する。

図示された例では、待機中に太郎の返答が取得されなかったため、エージェント３００ｂは、スケジュールＤＢ３６５に格納された太郎のスケジュール情報を参照し（花子には太郎のスケジュール情報へのアクセス権限が与えられているものとする）、指定された日（１２／２４）の中で適当な時間を返答するメッセージを生成する。図示された例では、１２／２４は１８：００以降の太郎のスケジュールに空き時間があったため、１８時以降であればＯＫである旨のメッセージが太郎のエージェント３００ｂから花子のエージェント３００ａに送信される。

ここで、太郎のエージェント３００ｂと同様に、花子のエージェント３００ａは、メッセージを受信すると、テキスト生成機能３６７によって「１２／２４は１８：００以降ＯＫです」というテキスト（ＴＥＸＴ２）を生成し、これを花子に向けて音声出力する。ここでも、タイミング制御機能３６３によって、テキスト（ＴＥＸＴ２）の出力後、花子のエージェント３００ａは、所定の時間だけ花子の返答を待機する。

待機中に花子の返答が取得されなかったため、エージェント３００ａは、スケジュールＤＢ３６５に格納された花子のスケジュールを参照し、１２／２４の１８：００以降の花子のスケジュールにも空き時間があることを確認する。さらに、エージェント３００ａは、スケジュール情報から花子が１２／２４の１８：００以前に東京駅周辺にいることを特定したため、場所を提案するメッセージを自動的に生成し、太郎のエージェント３００ｂに送信する。

これまでのやりとりと同様に、メッセージを受信した太郎のエージェント３００ｂは、「１２／２４ １８：００に東京駅ではどうですか？」というテキスト（ＴＥＸＴ３）を音声出力し、所定の時間だけ太郎の返答を待機する。ここで、待機中に太郎の返答が取得されないと、エージェント３００ｂは再びスケジュールＤＢ３６５に格納された太郎のスケジュール情報を参照し、太郎が１２／２４の１８：００に東京駅に行けるかどうかを判定する。太郎は１２／２４の１８：００まで横浜駅で別の予定があるため、１８：００に東京駅に行くことは難しいと判定される。従って、太郎のエージェント３００ｂが自動的にレスポンスを生成した場合、「１２／２４ １８：００は難しいです」というテキスト（ＴＥＸＴ４）のようなメッセージが生成されることになる。

しかし、図示された例では、待機中に太郎が「１８：３０に品川駅はどうかな？」という返答をエージェント３００ｂに対して発話している。この発話を取得したエージェント３００ｂは、太郎の返答を伝えるメッセージを花子のエージェント３００ａに送信する。これを受けて、花子のエージェント３００ａは、「１８：３０に品川駅はどうですか？」というテキスト（ＴＥＸＴ５）を音声出力する。

これに対して、花子は異論がないため返答せず、またエージェント３００ａが花子のスケジュール情報を参照した結果、１８：３０に品川駅に行くことは可能であった。そこで、エージェント３００ａは、承諾する旨のメッセージを自動的に生成して、太郎のエージェント３００ｂに送信する。これを受けて、太郎のエージェント３００ｂは、「１２／２４ １８：３０ 品川駅でＯＫです」というテキスト（ＴＥＸＴ６）を音声出力する。

これに対して太郎も異論がなく返答しなかったため、太郎のエージェント３００ｂも、承諾する旨のメッセージを自動的に生成して、花子のエージェント３００ａに送信する。これを受けて、花子のエージェント３００ａは、「わかりました。では１２／２４ １８：３０に品川駅にしましょう」というテキスト（ＴＥＸＴ７）を音声出力する。

以上のようなエージェント３００同士の間でのやりとりによって、太郎と花子とのスケジュールの調整が完了する。エージェント３００ａ，３００ｂは、それぞれ、１２／２４の１８：３０に品川駅でのデートの予定をスケジュール情報に登録するとともに、「１２／２４ １８：３０に太郎（花子）と品川駅でデートの約束をしました」というようなテキストを音声出力し、スケジュール調整の完了を花子と太郎に通知する。

上記の例のやりとりでは、最初に提案された条件（１８：００に東京駅）でスケジュールの調整が成立しなかったときに、太郎がエージェント３００同士のやりとりに介入し、新たな時間と場所を提案することによって円滑にスケジュール調整が実施された。このように、本実施形態によれば、エージェント３００がスケジュール情報の参照などのユーザの手間を代行するとともに、ユーザの知見（例えば、東京駅と横浜駅との間に品川駅があり、品川駅の周辺に太郎と花子がデートする場所があること）をスケジュール調整に活用し、より適切なスケジュールを生成することができる。

（２．第２の実施形態）
続いて、本開示の第２の実施形態について説明する。本実施形態は、システム構成および機能構成については、以下で説明するタイミング制御機能３６３を除いて上記の第１の実施形態と同様であるため、詳細な説明は省略する。また、最初のリクエスト送信時の処理フローについても上記の第１の実施形態と同様であるため、詳細な説明は省略する。

（２−１．処理フロー）
（２回目以降のリクエスト送信時の処理）
図８は、本開示の第２の実施形態において２回目以降にリクエストを送信する場合の処理の例を示すフローチャートである。なお、以下で説明するフローチャートのステップは、ステップＳ２０１を除いては、上記で図６を参照して説明したフローチャートと同様であるため、これらについては詳細な説明を省略する。

図示された例では、テキスト出力機能３６９がテキストを音声出力した後、タイミング制御機能３６３が、レスポンスの解析結果に基づいて、スケジュール調整において競合が発生しているか否かを判定する（ステップＳ２０１）。ここで、スケジュール調整では、各エージェント３００が、各ユーザのスケジュール情報に基づいてリクエストを生成している。従って、ステップＳ２０１で判定される競合は、エージェント３００において送信されるリクエスト（ユーザのスケジュール情報に基づく）と、受信されるレスポンス（他のユーザのスケジュール情報に基づく）との間での競合といえる。

ステップＳ２０１において、競合が発生していない場合（ＮＯ）、タイミング制御機能３６３によって所定時間の待機（ステップＳ１２９）が実行されることなく、リクエスト生成機能３５５がスケジュールＤＢ３６５を参照して（ステップＳ１３５）、自動的に新たなリクエストを生成する（ステップＳ１３７）。

一方、ステップＳ２０１において、競合が発生している場合（ＹＥＳ）、タイミング制御機能３６３がリクエスト生成機能３５５による新たなリクエストの生成を所定の時間だけ待機させ（ステップＳ１２９）、以下上記の図６の例と同様のステップが実行される。

なお、上記の例ではステップＳ２０１をステップＳ１２７の後に記載したが、ステップＳ２０１は、テキスト出力機能３６９によるテキストの出力を待たず、ステップＳ１２３以降の任意のタイミングで実行されてもよい。

このように、本実施形態では、エージェント３００のタイミング制御機能３６３が、レスポンスの解析結果に基づいて、リクエスト生成機能３５５による新たなリクエスト生成までの間に待機時間を設定するか否かを決定する。例えば、上記のように、スケジュール調整において競合が発生している場合、ユーザが介入することによって最適な解決策が得られる可能性が高いため、待機時間を設定してユーザの返答を待ち受けることが合理的でありうる。それ以外の場合には、待機時間を設定しないことによって、エージェント３００の間でのスケジュールの調整を迅速に進めることができる。また、待機時間を設定しない場合も、テキスト出力機能３６９によるテキストの出力を実行することで、ユーザの介入が必要になった場合に、ユーザが容易に状況を把握することができる。

上記のようなタイミング制御機能３６３の機能として、以下のような変形例も可能である。例えば、タイミング制御機能３６３は、レスポンスの解析結果に基づいて新たに生成されるリクエストが、レスポンスに対して否定的な内容である場合に待機時間を設定してもよい。これは、例えば、第１の実施形態で図７を参照して説明した例におけるＴＥＸＴ４（実際は送信されなかったリクエストに対応する）のように、受信されたレスポンスによって提案されている時間や場所に対して否定的なリクエストを生成しなければならない場合である。この場合、タイミング制御機能３６３は、レスポンスの解析結果に基づいて新たに生成されるリクエストを予想して、待機時間を設定するか否かを決定しうる。

また、例えば、タイミング制御機能３６３は、受信されたレスポンスが以前に送信されたリクエストに対して否定的な内容である場合に、待機時間を設定してもよい。これは、例えば、同じく図７を参照して説明した例において、ＴＥＸＴ３に対応するリクエストが実際に送信されたような場合である。この場合、「１２／２４ １８：００は難しいです」という、以前に送信したリクエスト（ＴＥＸＴ３に対応）に対して否定的な内容のレスポンス（ＴＥＸＴ４に対応）を受信したエージェント３００ａは、これに対する花子の返答を待ち受けるために、（それまでは設定されていなかった）待機時間を設定しうる。

（２−２．具体的な例）
図９〜１４は、本開示の第２の実施形態の具体的な例について説明するための図である。図示された例では、花子（ＨＡＮＡＫＯ）のエージェント３００ａとチームメンバーのエージェント３００ｂ〜３００ｄとの間で、スケジュール調整のためのやりとりが実行されている。なお、この例でも、説明を簡単にするために、リクエストおよびレスポンスをメッセージとして総称している。

この例では、まず、図９に示されるように、花子の発話によってやりとりが開始される。彼女は、「チームのみんなと忘年会がしたい」と発話する。この発話音声を取得したエージェント３００ａは、各チームメンバーのエージェント３００ｂ〜３００ｄに向けて、花子からの誘いを伝えるメッセージを送信する。ここで、実際に送信されるメッセージは、例えばシステム１０内で規定されたプロトコルに従って生成されたコードでありうる。

各チームメンバーのエージェント３００ｂ〜３００ｄは、リクエストを受信すると、テキスト生成機能３６７によって「花子から忘年会のお誘いが来ています」というテキスト（ＴＥＸＴ１）を生成して音声出力する。この時点では、まだスケジュール調整において競合は発生していないため、エージェント３００ｂ〜３００ｄは、各チームメンバーの返答を待つことなく、すぐに次のメッセージの生成を実行する。

その結果、図１０に示されるように、エージェント３００ｂからは「１２／２０か１２／２８またＯＫです」という内容のメッセージ（ＴＥＸＴ２として各ユーザに向けて音声出力される）が、エージェント３００ａ，３００ｃ，３００ｄに送信される。また、エージェント３００ｃは、エージェント３００ｂから受信されたメッセージの受信後に、「１２／２８は難しいです。１２／２０ならＯＫです」という内容のメッセージ（ＴＥＸＴ３として各ユーザに向けて音声出力される）を、エージェント３００ａ，３００ｂ，３００ｄに送信する。

さらに、花子のエージェント３００ａは、上記のエージェント３００ｂ，３００ｃからのメッセージの受信後に、花子自身のスケジュール情報を参照し、「１２／２０でＯＫです」という内容のメッセージ（ＴＥＸＴ４として各ユーザに向けて音声出力される）を、エージェント３００ｂ〜３００ｄに送信する。上記のように、これらのメッセージは各チームメンバーの返答を待つことなく送信されているが、メッセージに対応するテキストが音声出力されていることによって、各チームメンバーはエージェント３００間でのやりとりの状況を把握することができる。

続いて、図１１に示されるように、エージェント３００ｄからのメッセージが送信される。ここで、エージェント３００ｄは、現時点でチームメンバーの都合が合いそうな１２／２０のスケジュール情報を参照したが、空きがなかったため、「１２／２０は難しいです。１２／２８ならＯＫです」という内容のメッセージ（ＴＥＸＴ５として各ユーザに向けて音声出力される）をエージェント３００ａ〜３００ｃに向けて送信する。

この時点で、エージェント３００ａ〜３００ｄの間でのスケジュール調整に競合が発生している。エージェント３００ｄだけでなく、エージェント３００ａ〜３００ｃも、エージェント３００ｄからのメッセージを受信したことによって競合の発生を認識する。ここで、各エージェント３００のタイミング制御機能３６３によって各ユーザの返答を待機するための待機時間が設定される。

すると、図１２に示されるように、チームメンバーの１人（太郎）が、「スケジュール調整をしました。１２／２８でＯＫです」という返答をエージェント３００ｃに向けて発話した。これを受けて、エージェント３００ｃは、「太郎が１２／２８でもＯＫになりました」という内容のメッセージ（ＴＥＸＴ６として各ユーザに向けて音声出力される）をエージェント３００ａ，３００ｂ，３００ｄに向けて送信する。これを受けて、エージェント３００ａ，３００ｂ，３００ｄから、それぞれ「１２／２８でＯＫです」という内容のメッセージ（ＴＥＸＴ７〜ＴＥＸＴ９として各ユーザに向けて音声出力される）が送信される。

以上のようなエージェント３００同士の間でのやりとりによって、図１３に示すように、チームメンバーの間でのスケジュールの調整が完了する。エージェント３００ａ〜３００ｄは、各ユーザのスケジュールに１２／２８の忘年会を追加するとともに、「１２／２８にチームの忘年会をスケジュールしました。」というようなテキストを音声出力し、スケジュール調整の完了を各ユーザに通知する。

（３．補足）
上記で説明した実施形態では、エージェント３００が受信したレスポンスに対応するテキストがユーザに向けて音声出力されたが、テキストは例えば画像としてクライアント装置１００のディスプレイ１１０に表示されることによって出力されてもよい。同様に、エージェント３００が自動的に生成して送信するリクエストに対応するテキストも、画像としてディスプレイ１１０に表示されてもよい。この場合、ディスプレイ１１０には、各エージェント３００の間でやりとりされるメッセージが、例えばチャットのログのように交互に表示される。

また、上記で説明した実施形態では、ユーザが音声入力によってエージェント３００にテキストを入力するが、テキストは例えばキーボード（タッチパネル１１４を利用したいわゆるソフトウェアキーボードを含む）によって入力されてもよい。

本開示の実施形態は、例えば、上記で説明したような情報処理装置（クライアント装置またはサーバ装置）、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された一時的でない有形の媒体を含みうる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）リクエストを送信するリクエスト送信部と、
前記リクエストに対応するレスポンスを受信するレスポンス受信部と、
前記レスポンスを解析するレスポンス解析部と、
前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力するテキスト出力部と、
前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成するリクエスト生成部と、
前記リクエストが新たに生成されるタイミングを、前記生成されたテキストが出力されるタイミングに基づいて制御するタイミング制御部と
を備える情報処理装置。
（２）前記タイミング制御部は、前記生成されたテキストが出力されてから前記リクエストが新たに生成されるまでの間に待機時間を設定する、前記（１）に記載の情報処理装置。
（３）前記リクエスト生成部は、前記待機時間に前記ユーザによってテキストが入力された場合、該入力されたテキストに基づいて前記リクエストを新たに生成する、前記（２）に記載の情報処理装置。
（４）前記リクエスト生成部は、前記待機時間に前記ユーザによってテキストが入力されなかった場合、前記レスポンスの解析結果に基づいて前記リクエストを新たに生成する、前記（３）に記載の情報処理装置。
（５）前記タイミング制御部は、前記レスポンスの解析結果に基づいて前記待機時間を設定するか否かを決定する、前記（２）〜（４）のいずれか１項に記載の情報処理装置。
（６）前記タイミング制御部は、前記レスポンスの解析結果に基づいて新たに生成される前記リクエストが前記レスポンスに対して否定的な内容である場合に前記待機時間を設定する、前記（５）に記載の情報処理装置。
（７）前記タイミング制御部は、前記レスポンスが以前に送信された前記リクエストに対して否定的な内容である場合に前記待機時間を設定する、前記（５）に記載の情報処理装置。
（８）前記テキスト出力部は、さらに、前記リクエスト生成部が前記レスポンスの解析結果に基づいて生成した前記リクエストに基づいて生成されたテキストを前記ユーザに向けて出力する、前記（１）〜（７）のいずれか１項に記載の情報処理装置。
（９）前記テキスト出力部は、前記生成されたテキストを音声出力する、前記（１）〜（８）のいずれか１項に記載の情報処理装置。
（１０）前記リクエスト生成部は、前記ユーザによって音声入力されたテキストを取得する、前記（１）〜（９）のいずれか１項に記載の情報処理装置。
（１１）前記テキスト出力部は、前記生成されたテキストを画像として出力する、前記（１）〜（１０）のいずれか１項に記載の情報処理装置。
（１２）前記リクエスト生成部は、前記ユーザのスケジュール情報にさらに基づいて前記リクエストを生成し、
前記レスポンス受信部は、他のユーザのスケジュール情報に基づいて生成された前記レスポンスを受信する、前記（１）〜（１１）のいずれか１項に記載の情報処理装置。
（１３）前記タイミング制御部は、前記リクエストと前記レスポンスとの間に競合が発生した場合に、前記生成されたテキストが出力されてから前記リクエストが新たに生成されるまでの間に待機時間を設定する、前記（１２）に記載の情報処理装置。
（１４）リクエストを送信することと、
前記リクエストに対応するレスポンスを受信することと、
前記レスポンスを解析することと、
前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力することと、
前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成することと、
前記リクエストが新たに生成されるタイミングを、前記生成されたテキストが出力されるタイミングに基づいて制御することと
を含む情報処理方法。
（１５）リクエストを送信する機能と、
前記リクエストに対応するレスポンスを受信する機能と、
前記レスポンスを解析する機能と、
前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力する機能と、
前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成する機能と、
前記リクエストが新たに生成されるタイミングを、前記生成されたテキストが出力されるタイミングに基づいて制御する機能と
をコンピュータに実現させるためのプログラム。

１０ システム
２０ サーバ
１００ クライアント装置
１０２ プロセッサ
２００ サーバ装置
２０２ プロセッサ
３００ エージェント
３５１ 音声取得機能
３５３ 音声認識機能
３５５ リクエスト生成機能
３５７ リクエスト送信機能
３５９ レスポンス受信機能
３６１ レスポンス解析機能
３６３ タイミング制御機能
３６７ テキスト生成機能
３６９ テキスト出力機能

Claims (11)

1. リクエストを送信するリクエスト送信部と、
   前記リクエストに対応するレスポンスを受信するレスポンス受信部と、
   前記レスポンスを解析するレスポンス解析部と、
   前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力するテキスト出力部と、
   前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成するリクエスト生成部と、
   前記生成されたテキストが出力されてから前記リクエストが新たに生成されるまでの間に、前記ユーザによってテキストが入力されることを待機する待機時間を設定するタイミング制御部と
   を備え、
   前記テキスト出力部は、さらに、前記リクエスト生成部が前記レスポンスの解析結果に基づいて生成した前記リクエストに基づいて生成されたテキストを前記ユーザに向けて出力し、
   前記リクエスト生成部は、前記ユーザのスケジュール情報にさらに基づいて前記リクエストを生成し、
   前記レスポンス受信部は、他のユーザのスケジュール情報に基づいて生成された前記レスポンスを受信し、
   前記タイミング制御部は、前記レスポンスの解析結果に基づいて前記待機時間を設定するか否かを決定する、情報処理装置。
2. 前記リクエスト生成部は、前記待機時間に前記ユーザによってテキストが入力された場合、該入力されたテキストに基づいて前記リクエストを新たに生成する、請求項１に記載の情報処理装置。
3. 前記リクエスト生成部は、前記待機時間に前記ユーザによってテキストが入力されなかった場合、前記レスポンスの解析結果に基づいて前記リクエストを新たに生成する、請求項２に記載の情報処理装置。
4. 前記タイミング制御部は、前記レスポンスの解析結果に基づいて新たに生成される前記リクエストが前記レスポンスに対して否定的な内容である場合に前記待機時間を設定する、請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記タイミング制御部は、前記レスポンスが以前に送信された前記リクエストに対して否定的な内容である場合に前記待機時間を設定する、請求項１〜３のいずれか１項に記載の情報処理装置。
6. 前記タイミング制御部は、前記リクエストと前記レスポンスとの間に競合が発生した場合に、前記待機時間を設定する、請求項１〜３のいずれか１項に記載の情報処理装置。
7. 前記テキスト出力部は、前記生成されたテキストを音声出力する、請求項１〜６のいずれか１項に記載の情報処理装置。
8. 前記リクエスト生成部は、前記ユーザによって音声入力されたテキストを取得する、請求項１〜７のいずれか１項に記載の情報処理装置。
9. 前記テキスト出力部は、前記生成されたテキストを画像として出力する、請求項１〜８のいずれか１項に記載の情報処理装置。
10. プロセッサが、
    リクエストを送信することと、
    前記リクエストに対応するレスポンスを受信することと、
    前記レスポンスを解析することと、
    前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力することと、
    前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成することと、
    前記生成されたテキストが出力されてから前記リクエストが新たに生成されるまでの間に、前記ユーザによってテキストが入力されることを待機する待機時間を設定することと、
    前記レスポンスの解析結果に基づいて生成された前記リクエストに基づいて生成されたテキストを前記ユーザに向けて出力することと、
    を含み、
    前記リクエストは、前記ユーザのスケジュール情報にさらに基づいて生成され、
    受信される前記レスポンスは、他のユーザのスケジュール情報に基づいて生成された前記レスポンスであり、
    前記待機時間は、前記レスポンスの解析結果に基づいて設定されるか否かが決定される、情報処理方法。
11. リクエストを送信する機能と、
    前記リクエストに対応するレスポンスを受信する機能と、
    前記レスポンスを解析する機能と、
    前記レスポンスの解析結果に基づいて生成されたテキストをユーザに向けて出力する機能と、
    前記レスポンスの解析結果、または前記ユーザによって入力されたテキストに基づいて前記リクエストを新たに生成する機能と、
    前記生成されたテキストが出力されてから前記リクエストが新たに生成されるまでの間に、前記ユーザによってテキストが入力されることを待機する待機時間を設定する機能と
    をコンピュータに実現させるためのプログラムであって、
    前記出力する機能は、さらに、前記リクエストを新たに生成する機能が前記レスポンスの解析結果に基づいて生成した前記リクエストに基づいて生成されたテキストを前記ユーザに向けて出力し
    前記リクエストを新たに生成する機能は、前記ユーザのスケジュール情報にさらに基づいて前記リクエストを生成し、
    前記レスポンスを受信する機能は、他のユーザのスケジュール情報に基づいて生成された前記レスポンスを受信し、
    前記待機時間を設定する機能は、前記レスポンスの解析結果に基づいて前記待機時間を設定するか否かを決定する、プログラム。

Images