JP2021108142A - 情報処理システム、情報処理方法、および情報処理プログラム - Google Patents

Abstract

【課題】エージェントの発話文データの監査をより柔軟に行うことが可能な情報処理システム、および情報処理方法を提供する。【解決手段】エージェントの発話文データを記憶する記憶部と、クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を受信する通信部と、前記通信部を介して前記要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて前記記憶部に記録する制御部と、を備える、情報処理システム。【選択図】図１

Description

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

近年、通信技術の発達により、ネットワークを介したメッセージのやり取りが頻繁に行われている。ユーザは、スマートフォンや携帯電話端末、タブレット端末等の情報処理端末を用いて、他端末から送信されたメッセージを確認したり、メッセージを送信したりすることができる。

また、情報処理端末において、ユーザのメッセージに対して自動で応答を行うエージェントシステムが提案されている。このようなシステムでは、エージェントの発話文データが担当者や専門家によりある程度まとめて制作され、別の専門家による監修が行われた上で登録されている。

このようなジェスチャーの発話文データ等の監修に関し、例えば下記特許文献１では、アバターが表示するジェスチャーを認識して禁止ジェスチャーを判断し、禁止ジェスチャーを他の画像データに変更したり、禁止ジェスチャーを行いつつユーザによって生成された音声データを切除したりすることが記載されている。また、下記特許文献２は、カスタマイズできるアバターのジェスチャーに関し、侮辱的な、無礼な、その他不適切なジェスチャーの使用は制限することが記載されている。

また、下記特許文献３では、オンラインユーザの不適切な振る舞いを検知すると、調停エンティティに通知することが記載されている。また、下記特許文献４では、サービス画面用のアバターにおいて重畳される入力文字に禁止語が含まれてないかチェックすることが記載されている。また、下記特許文献５では、育成型キャラクタプログラムにおいて不快な行為であると判断された場合、このジェスチャーの表示用画像データが変更される。さらに、下記特許文献６では、車両運転者の好みにより容姿や音声が選択され、学習成長する擬人化エージェントについて記載されている。

特表２０１３−５３３５３７号公報 特表２０１０−５３３００６号公報 特表２０１１−５０２３０７号公報 特開２００９−２５８９１８号公報 特開２００９−２０１７６５号公報 特開２００５−３１３８８６号公報

しかしながら、エージェントの発話文データを監修する際、上述したような技術では、禁止語を含む発話文データを削除するか否かの２択しかなく、エージェントのキャラクターを考慮して柔軟に対応することができなかった。また、専門家による監修を行う場合、作業効率やスケジュール調整の観点からある程度まとまった単位でしか処理できず、発話文データを充実させるまでには多大な手間がかかってしまう。

そこで、本開示では、エージェントの発話文データの監査をより柔軟に行うことが可能な情報処理システム、情報処理方法、および情報処理プログラムを提案する。

本開示によれば、エージェントの発話文データを記憶する記憶部と、クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を受信する通信部と、前記通信部を介して前記要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて前記記憶部に記録する制御部と、を備える、情報処理システムを提案する。

本開示によれば、プロセッサが、エージェントの発話文データを記憶部に記憶することと、クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を通信部により受信することと、前記通信部を介して前記要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて前記記憶部に記録するよう制御することと、を含む、情報処理方法を提案する。

以上説明したように本開示によれば、エージェントの発話文データの監査をより柔軟に行うことが可能となる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態による通信制御システムの概要について説明する図である。 本実施形態による通信制御システムの全体構成を示す図である。 本実施形態による音声エージェントサーバの構成の一例を示すブロック図である。 本実施形態による対話処理部の構成例を示す図である。 本実施形態による会話ＤＢの生成処理を示すフローチャートである。 本実施形態による音素ＤＢの生成処理を示すフローチャートである。 本実施形態による対話制御処理を示すフローチャートである。 本実施形態による会話ＤＢのデータ構成例について説明する図である。 本実施形態による会話ＤＢの更新処理を示すフローチャートである。 本実施形態による個人化レイヤーから共通レイヤーへの会話データ移行処理を示すフローチャートである。 本実施形態による基本対話用会話ＤＢへの会話データの移行について説明する図である。 本実施形態による基本対話用ＤＢへの会話データ移行処理を示すフローチャートである。 本実施形態による広告ＤＢに登録されている広告情報の一例を示す図である。 本実施形態による広告内容の挿入処理を示すフローチャートである。 本実施形態による会話ＤＢ生成部の構成例を示す図である。 本実施形態によるユーザ情報ＤＢに格納されているユーザ情報の一例を示す図である。 本実施形態によるエージェント情報ＤＢに格納されているエージェント情報の一例を示す図である。 本実施形態による特権者情報ＤＢに格納されている特権者情報の一例を示す。 本実施形態による特権者情報ＤＢに格納されている特権者情報の一例を示す。 本実施形態による対話処理部の構成例を示す図である。 本実施形態による発話文データの収集処理を示すフローチャートである。 本実施形態による発話文登録画面の一例を示す図である。 本実施形態によるエージェント選択画面の一例を示す図である。 本実施形態による一般ユーザ用の監査処理を示すフローチャートである。 本実施形態による一般ユーザの監査処理を示すフローチャートである。 本実施形態による一般ユーザ用監査画面の一例を示す図である。 本実施形態による一般ユーザ用監査画面の一例を示す図である。 本実施形態による特権者の監査処理を示すフローチャートである。 本実施形態による特権者用監査画面の一例を示す図である。 本実施形態による発話制御処理を示すフローチャートである。

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

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による通信制御システムの概要
２．構成
２−１．システム構成
２−２．サーバの構成
３．システム動作処理
３−１．会話データ登録処理
３−２．音素ＤＢ生成処理
３−３．対話制御処理
３−４．会話ＤＢ更新処理
３−５．広告挿入処理
４．発話文データの管理
４−１．構成
４−１−１．会話ＤＢ生成部の構成
４−１−２．対話処理部の構成
４−２．動作処理
４−２−１．収集処理
４−２−２．監査処理
４−２−３．発話制御処理
５．まとめ

＜＜１．本開示の一実施形態による通信制御システムの概要＞＞
図１を参照して本開示の一実施形態による通信制御システム（エージェントシステム）について説明する。

図１は、本開示の一実施形態による通信制御システムの概要について説明する図である。本システムでは、ユーザと日常的に対話を行う、人格を持つエージェントの発話文データの監査を行うことで、エージェントの人格にそぐわない発話や禁止ワードを含む発話を発しないようにすることができる。エージェントは、上述したようにユーザと日常的に対話を行い、状況に応じて、実世界やインターネット上のコンテンツ等の推薦、ニュースや天気予報等の情報提供、ゲームの提供、道案内等々の様々なサービスを提供する。エージェントとの対話は、例えばユーザが所持するスマートフォン等のクライアント端末１の表示部、マイクロホン、およびスピーカを介して行われる。例えば表示部にエージェントの画像や会話テキストが表示され、スピーカからエージェントの発話音声が再生される。また、ユーザの発話音声はマイクロホンにより収音され、システム側で音声認識、および意味解析される。ユーザと対話を行うエージェントは、システム側で予め用意された、それぞれ異なる人格（キャラクター）を持つ複数のエージェントから、ユーザが任意に選択、購入したものである。

（背景）
エージェントの発話文データは、予め登録しておく必要がある。ここで、発話文データを一般ユーザから収集することによって、より早く発話文ＤＢ（データベース）を充実させることが可能であるが、エージェントのイメージに合わない発話文や、公序良俗に反するワードを含む発話文等も登録されてしまう恐れがあり、専門家により監修が必要であった。専門家による監修を行う場合、作業効率やスケジュール調整の観点からある程度まとまった単位でしか処理できず、発話文データを充実させるまでには多大な手間がかかってしまう。

また、エージェントの発話文データを監修する際、禁止語を含む発話文データを削除するか否かの二択しかなく、エージェントのキャラクターを考慮して柔軟に対応することが出来なかった。

そこで、本開示では、収集した発話文データに対して、エージェントが言いそうな度合いを示す発話可能性レベルを設定し、エージェントの発話文データの監査をより柔軟に行うことを可能にする。これにより、一般ユーザから発話文データを収集して発話文ＤＢを充実させるとともに、エージェントのキャラクターのイメージに合わない発話データは利用されないようにすることが可能となる。

なお、本実施形態による通信制御システムは、音声により応答を行う音声エージェントに限定されず、スマートフォン等のクライアント端末においてテキストベースで応答を行うテキスト対応のエージェントであってもよい。

また、本実施形態による通信制御システムは、スマートフォンやタブレット端末、ＰＣ等の情報処理装置に搭載されてもよいし、ホームシステム、車載システム、クライアント端末とサーバから成るクライアントサーバシステムに組み込まれてもよい。また、本実施形態による通信制御システムは、ロボットのような擬人化されたデバイスに搭載されていてもよい。ロボットの場合、音声対話に加えて、表情の制御やアクションの制御も行われ得る。

＜＜２．構成＞＞
＜２−１．システム構成＞
続いて、上述した本実施形態による通信制御システムの全体構成について図２を参照して説明する。図２は、本実施形態による通信制御システムの全体構成を示す図である。

図２に示すように、本実施形態による通信制御システムは、クライアント端末１およびエージェントサーバ２を含む。

エージェントサーバ２は、ネットワーク３を介してクライアント端末１と接続し、データの送受信を行う。具体的には、エージェントサーバ２は、クライアント端末１で収音され、送信された発話音声に対する応答音声を生成し、クライアント端末１に送信する。エージェントサーバ２は、１以上のエージェントに対応する音素ＤＢ（データベース）を有し、特定のエージェントの音声で応答音声を生成することが可能である。ここで、エージェントとは、漫画、アニメ、ゲーム、ドラマ、映画等のキャラクターや、芸能人、著名人、歴史上の人物等であってもよいし、また、個人に特定せず、例えば世代別の平均的な人物であってもよい。また、エージェントは、動物や擬人化されたキャラクターであってもよい。また、エージェントは、ユーザ本人の性格を反映した人物や、ユーザの友人、家族、知人等の性格を反映した人物であってもよい。

また、エージェントサーバ２は、各エージェントの性格を反映した応答内容を生成することが可能である。エージェントサーバ２は、エージェントを介して、ユーザのスケジュール管理、メッセージの送受信、情報提供等、様々なサービスをユーザとの対話を通じて提供し得る。

なおクライアント端末１は、図２に示すようなスマートフォンに限定されず、例えば携帯電話端末、タブレット端末、ＰＣ（パーソナルコンピュータ）、ゲーム機、ウェアラブル端末（スマートアイグラス、スマートバンド、スマートウォッチ、スマートネック等）等であってもよい。また、クライアント端末１は、ロボットであってもよい。

以上、本実施形態による通信制御システムの概要について説明した。続いて、本実施形態による通信制御システムのエージェントサーバ２の構成について図３を参照して具体的に説明する。

＜２−２．エージェントサーバ２＞
図３は、本実施形態によるエージェントサーバ２の構成の一例を示すブロック図である。図３に示すように、エージェントサーバ２は、音声エージェントＩ／Ｆ（インタフェース）２０、対話処理部３０、音素記憶部４０、会話ＤＢ生成部５０、音素ＤＢ生成部６０、広告挿入処理部７０、広告ＤＢ７２、およびフィードバック取得処理部８０を有する。

音声エージェントＩ／Ｆ２０は、音声データの入出力部、音声認識部、および音声生成部として機能する。入出力部としては、ネットワーク３を介してクライアント端末１と送受信を行う通信部が想定される。音声エージェントＩ／Ｆ２０は、クライアント端末１からユーザの発話音声を受信し、音声認識によりテキスト化することが可能である。また、音声エージェントＩ／Ｆ２０は、対話処理部３０から出力されたエージェントの回答文データ（テキスト）を、当該エージェントに対応する音素データを用いて音声化し、生成したエージェントの応答音声をクライアント端末１に送信する。

対話処理部３０は、演算処理装置および制御装置として機能し、各種プログラムに従ってエージェントサーバ２内の動作全般を制御する。対話処理部３０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、本実施形態による対話処理部３０は、基本対話処理部３１、キャラクターＡ対話処理部３２、人物Ｂ対話処理部３３、人物Ｃ対話処理部３４として機能する。

キャラクターＡ対話処理部３２、人物Ｂ対話処理部３３、人物Ｃ対話処理部３４は、エージェント毎に特化された対話を実現する。ここでは、エージェントの一例として「キャラクターＡ」「人物Ｂ」「人物Ｃ」を挙げているが、本実施形態は当然これに限定されず、さらに多数のエージェントに特化した対話を実現する各対話処理部を有していてもよい。基本対話処理部３１は、エージェント毎に特化されていない、汎用の対話を実現する。

ここで、基本対話処理部３１、キャラクターＡ対話処理部３２、人物Ｂ対話処理部３３、および人物Ｃ対話処理部３４に共通する基本構成について図４を参照して説明する。

図４は、本実施形態による対話処理部３００の構成例を示す図である。図４に示すように、対話処理部３００は、質問文検索部３１０、回答文生成部３２０、音素データ取得部３４０、および会話ＤＢ３３０を有する。会話ＤＢ３３０は、質問文データと回答文データが組になった会話データが保存されている。エージェントに特化した対話処理部では、かかる会話ＤＢ３３０にエージェントに特化した会話データが保存され、汎用の対話処理部では、かかる会話ＤＢ３３０にエージェントに特化しない汎用の会話データ（すなわち、基本会話データ）が保存されている。

質問文検索部３１０は、音声エージェントＩ／Ｆ２０から出力された、ユーザの質問音声（発話音声の一例）を認識してテキスト化した質問文と一致する質問文データを会話ＤＢ３３０から検索する。回答文生成部３２０は、質問文検索部３１０により検索した質問文データに対応付けて保存されている回答文データを会話ＤＢ３３０から抽出し、回答文データを生成する。音素データ取得部３４０は、回答文生成部３２０により生成された回答文を音声化するための音素データを、対応するエージェントの音素記憶部４０から取得する。例えば、キャラクターＡ対話処理部３２の場合、キャラクターＡ音素ＤＢ４２から、回答文データをキャラクターＡの音声で再生するための音素データを取得する。そして、対話処理部３００は、生成した回答文データおよび取得した音素データを音声エージェントＩ／Ｆ２０に出力する。

音素記憶部４０は、エージェント毎の音声を生成するための音素データベースを格納する。音素記憶部４０は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）により実現され得る。図３に示す例では、基本音素ＤＢ４１、キャラクターＡ音素ＤＢ４２、人物Ｂ音素ＤＢ４３、人物Ｃ音素ＤＢ４４を格納する。各音素ＤＢには、音素データとして、例えば音素片とその制御情報である韻律モデルが記憶されている。

会話ＤＢ生成部５０は、対話処理部３００の会話ＤＢ３３０を生成する機能を有する。例えば会話ＤＢ生成部５０は、想定される質問文データを収集し、各質問に対応する回答文データを収集した後に、質問文データと回答文データとを組にして保存する。そして、会話ＤＢ生成部５０は、所定数の会話データ（質問文データと回答文データとの組、例えば１００組）が集まったら、エージェントの会話データセットとして会話ＤＢ３３０に登録する。

音素ＤＢ生成部６０は、音素記憶部４０に格納されている音素ＤＢを生成する機能を有する。例えば音素ＤＢ生成部６０は、所定のテキストを読み上げた音声情報を解析して、音素片とその制御情報である韻律モデルに分解し、所定数以上の音声情報が収集できたら音素データとして音素ＤＢに登録する処理を行う。

広告挿入処理部７０は、エージェントの対話に広告情報を挿入する機能を有する。挿入する広告情報は、広告ＤＢ７２から抽出し得る。広告ＤＢ７２には、企業等の提供側（ベンダー、サプライヤー）から依頼された広告情報（例えばテキスト、画像、音声等の広告内容、広告主、広告期間、広告対象者等の情報）が登録されている。

フィードバック取得処理部８０は、エージェントの対話に、フィードバックを取得するための質問を挿入し、ユーザからフィードバックを得るための機能を有する。

以上、本実施形態によるエージェントサーバ２の構成について具体的に説明した。なお、本実施形態によるエージェントサーバ２の構成は、図３に示す例に限定されない。例えば、エージェントサーバ２が有する各構成は、各々ネットワーク上の他サーバで構成されていてもよい。

続いて、本実施形態による通信制御システムの基本的な動作処理について図５〜図１４を参照して説明する。

＜＜３．システム動作処理＞＞
＜３−１．会話データ登録処理＞
図５は、本実施形態による会話ＤＢ３３０の生成処理を示すフローチャートである。図５に示すように、まず、会話ＤＢ生成部５０は、想定される質問文を保存する（ステップＳ１０３）。

次に、会話ＤＢ生成部５０は、質問文に対応する（対の）回答文を保存する（ステップＳ１０６）。

次いで、会話ＤＢ生成部５０は、質問文と回答文のペア（会話データとも称す）が所定数集まったか否かを判断する（ステップＳ１０９）。

そして、質問文と会話文のペアが所定数集まった場合（ステップＳ１０９／Ｙｅｓ）、会話ＤＢ生成部５０は、質問文および回答文の多数のペアから成るデータセットを会話ＤＢ３３０に登録する（ステップＳ１１２）。質問文および回答文のペアの一例としては、例えば下記のようなものが想定される。

質問文および回答文のペア例
ペア１
質問文：おはよう。
回答文：今日の調子はどうですか？
ペア２
質問文：今日の天気は？
回答文：今日の天気は○○です。

このようなペアが、会話データとして会話ＤＢ３３０に登録され得る。

＜３−２．音素ＤＢ生成処理＞
図６は、本実施形態による音素ＤＢの生成処理を示すフローチャートである。図６に示すように、まず、音素ＤＢ生成部６０は、例文の表示を行う（ステップＳ１１３）。例文の表示は、例えば図示しない情報処理端末のディスプレイに、音素データ生成のために必要な例文を表示する。

次に、音素ＤＢ生成部６０は、例文を読み上げた音声を録音し（ステップＳ１１６）、録音音声を分析する（ステップＳ１１９）。例えば、エージェントの音声を担当する人物により読み上げられた音声情報が情報処理端末のマイクロホンにより収集され、音素ＤＢ生成部６０がこれを受信し、記憶し、さらに音声分析を行う。

次いで、音素ＤＢ生成部６０は、音声情報に基づいて、韻律モデルを生成する（ステップＳ１２２）。韻律モデルとは、音声の韻律的特徴（例えば音の高低、音の強弱、発話速度等）を示す韻律パラメータを抽出するものであって、個人毎に異なる。

次に、音素ＤＢ生成部６０は、音声情報に基づいて、音素片（音素データ）を生成する（ステップＳ１２５）。

次いで、音素ＤＢ生成部６０は、韻律モデルおよび音素片を保存する（ステップＳ１２８）。

続いて、音素ＤＢ生成部６０は、韻律モデルおよび音素片が所定数集まったか否かを判断する（ステップＳ１３１）。

そして、韻律モデルおよび音素片が所定数集まった場合（ステップＳ１３１／Ｙｅｓ）、音素ＤＢ生成部６０は、韻律モデルおよび音素片を、所定のエージェント用の音素データベースとして音素記憶部４０に登録する（ステップＳ１３４）。

＜３−３．対話制御処理＞
図７は、本実施形態による対話制御処理を示すフローチャートである。図７に示すように、まず、音声エージェントＩ／Ｆ２０は、ユーザの質問音声およびエージェントIDを取得したか否かを確認する（ステップＳ１４３）。エージェントIDは、キャラクターＡ、人物Ｂ、人物Ｃといった特定のエージェントを示す識別情報である。ユーザは、エージェント毎の音素データを購入することができ、例えば購入処理時に購入したエージェントのIDがクライアント端末１に保存される。

次に、ユーザの質問音声およびエージェントIDを取得すると（ステップＳ１４６／Ｙｅｓ）、音声エージェントＩ／Ｆ２０は、質問音声を音声認識し、テキスト化する（ステップＳ１４９）。音声エージェントＩ／Ｆ２０は、テキスト化した質問文を、エージェントIDで指定された特定エージェントの対話処理部に出力する。例えば「エージェントID：キャラクターＡ」の場合、音声エージェントＩ／Ｆ２０は、テキスト化した質問文をキャラクターＡ対話処理部３２に出力する。

次いで、対話処理部３０は、エージェントIDで指定された特定エージェントの会話ＤＢから、テキスト化した質問文と一致する質問文を検索する（ステップＳ１５２）。

次に、一致する質問があった場合（ステップＳ１５５／Ｙｅｓ）、キャラクターＡ対話処理部３２は、質問に対応する（対になって保存されている）回答文データを特定エージェントの会話ＤＢから取得する（ステップＳ１５８）。

一方、一致する質問がなかった場合（ステップＳ１５５／Ｎｏ）、基本対話処理部３１の会話ＤＢから、テキスト化した質問文と一致する質問文が検索される（ステップＳ１６１）。

一致する質問文があった場合（ステップＳ１６１／Ｙｅｓ）、基本対話処理部３１は、質問に対応する（対になって保存されている）回答文データを基本対話処理部３１の会話ＤＢから取得する（ステップＳ１６７）。

一方、一致する質問文がなかった場合（ステップＳ１６４／Ｎｏ）、基本対話処理部３１は、一致する質問文が無い場合の回答文データ（例えば、「質問が解りません」といった回答文）を取得する（ステップＳ１７０）。

次いで、キャラクターＡ対話処理部３２により、エージェントIDで指定された特定エージェントの音素ＤＢ（ここでは、キャラクターＡ音素ＤＢ４２）を参照し、回答文データの音声を生成するためのキャラクターＡの音素データが取得される（ステップＳ１７３）。

次に、取得された音素データと回答文データが音声エージェントＩ／Ｆ２０に出力される（ステップＳ１７６）。

そして、音声エージェントＩ／Ｆ２０は、回答文データ（テキスト）を音素データを用いて音声化（音声合成）し、クライアント端末１に送信する（ステップＳ１７９）。クライアント端末１では、キャラクターＡの音声で回答文が再生される。

＜３−４．会話ＤＢ更新処理＞
次に、各対話処理部３００の会話ＤＢ３３０の更新処理について説明する。本実施形態では、ユーザとの会話によって会話ＤＢ３３０を成長させることが可能である。

まず、会話ＤＢ３３０のデータ構成例について図８を参照して補足説明を行う。図８は、本実施形態による会話ＤＢ３３０のデータ構成例について説明する図である。図８に示すように、各会話ＤＢ３３０は、個人化レイヤー３３１と共通レイヤー３３２という２つのレイヤーを有する。例えばキャラクターＡ用会話ＤＢ３３０Ａの場合、共通レイヤー３３２Ａには、キャラクターＡの性格や特徴が反映された会話データが保持される。一方、個人化レイヤー３３１Ａには、ユーザとの会話により当該ユーザ向けにカスタマイズされた会話データが保持される。すなわち、キャラクターＡ音素ＤＢ４２およびキャラクターＡ対話処理部３２がセットでユーザに提供（販売）されると、あるユーザＸと、ユーザＹは、最初は同じキャラクターＡと対話を行う（共通レイヤー３３２Ａに保持されている会話データが使用される）が、対話を続けるにつれて、各ユーザ向けにカスタマイズされた会話データが、ユーザ毎の個人化レイヤー３３１Ａに蓄積される。これにより、ユーザＸ、ユーザＹそれぞれの好みに応じたキャラクターＡとの対話を提供できるようになる。

またエージェント「人物Ｂ」が、キャラクターＡのような特定の性格を有さない平均的な世代別の人物の場合も、会話データがユーザ向けにカスタマイズされ得る。すなわち、例えば「人物Ｂ」が『２０代の人物』の場合、共通レイヤー３３２Ｂには２０代の平均的な会話データが保持され、ユーザとの対話を続けることでカスタマイズされた会話データがユーザ毎の個人化レイヤー３３１Ｂに保持される。また、ユーザは、人物Ｂの音声として「男性」、「女性」、「高い声」、「低い声」といった好きな音素データを人物Ｂ音素ＤＢ４３から選択し、購入することも可能である。

このような会話ＤＢ３３０のカスタマイズを行う際の具体的な処理について、図９を参照して説明する。図９は、本実施形態による会話ＤＢ３３０の更新処理を示すフローチャートである。

図９に示すように、まず、音声エージェントＩ／Ｆ２０は、クライアント端末１からユーザの質問音声を取得（受信）し、これを音声認識によりテキスト化する（ステップＳ１８３）。テキスト化されたデータ（質問文データ）は、エージェントIDにより指定されている特定エージェントの対話処理部（ここでは、例えばキャラクターＡ対話処理部３２）に出力される。

次に、キャラクターＡ対話処理部３２は、質問文データが所定のコマンドであるか否かを判断する（ステップＳ１８６）。

次いで、所定のコマンドである場合（ステップＳ１８６／Ｙｅｓ）、キャラクターＡ対話処理部３２は、ユーザ指定の回答文データを、会話ＤＢ３３０Ａの個人化レイヤー３３１Ａに質問文データと対で登録する（ステップＳ１８９）。所定のコマンドとは、例えば「ＮＧ」、「設定」といった言葉であってもよい。例えば以下のような会話の流れにより、キャラクターＡの会話ＤＢをカスタマイズすることができる。

ユーザ：「おはよう」
キャラクターＡ：「おはよう」
ユーザ：「ＮＧ。元気で頑張ってと答えて」
キャラクターＡ：「元気で頑張って」

上記の会話の流れでは、『ＮＧ』が所定のコマンドであって、キャラクターＡ対話処理部３２は、ユーザから『ＮＧ』と発せられた後、ユーザ指定の回答文データ『元気で頑張って』を、質問文データ『おはよう』と対にして会話ＤＢ３３０Ａの個人化レイヤー３３１Ａに登録する。

一方、所定のコマンドでない場合（ステップＳ１８６／Ｎｏ）、キャラクターＡ対話処理部３２は、質問文データと対になって保持されている回答文データをキャラクターＡ用会話ＤＢ３３０Ａから検索する。問文データと対になって保持されている回答文データがキャラクターＡ用会話ＤＢ３３０Ａに保持されていない場合、すなわち、ユーザの質問が回答文の無い質問であった場合（ステップＳ１９２／Ｙｅｓ）、キャラクターＡ対話処理部３２は、ユーザ指定の回答文データを、質問文と対にして個人化レイヤー３３１Ａに登録する（ステップＳ１９５）。例えば以下のような会話の流れにより、キャラクターＡの会話ＤＢをカスタマイズすることができる。

ユーザ：「元気？」
キャラクターＡ：「質問がわかりません」（該当する回答が無い場合の回答データ例）
ユーザ：「『元気？』と聞いたら、『今日も元気だよ』と答えて」
キャラクターＡ：「今日も元気だよ」

上記会話の流れでは、『元気？』と対になって保持される回答文データが無いため、該当する回答が無い場合の回答データ例である『質問がわかりません』がキャラクターＡ対話処理部３２により取得され、対応するキャラクターＡの音素データと共に音声エージェントＩ／Ｆ２０に出力され、クライアント端末１で再生される。次いで、ユーザ指定の回答文『今日も元気だよ』が入力されると、キャラクターＡ対話処理部３２は、質問文データ『元気？』と対にして個人化レイヤー３３１Ａに登録する。

なお、回答文の有る質問であった場合（ステップＳ１９２／Ｎｏ）、キャラクターＡ対話処理部３２は、当該回答文データを取得し、対応するキャラクターＡの音素データと共に音声エージェントＩ／Ｆ２０に出力し、クライアント端末１で回答文がキャラクターＡの音声で再生される（ステップＳ１９８）。

次いで、個人化レイヤーから共通レイヤーへの会話データ移行について、図１０を参照して説明する。図１０は、本実施形態による個人化レイヤーから共通レイヤーへの会話データ移行処理を示すフローチャートである。ここでは、一例としてキャラクターＡ対話処理部３２の個人化レイヤー３３１Ａから共通レイヤー３３２Ａへの会話データ移行処理について説明する。

図１０に示すように、まず、キャラクターＡ対話処理部３２は、ユーザ毎の個人化レイヤー３３１Ａを定期的にサーチし（ステップＳ２０３）、実質的に同じ内容の会話ペア（質問文データと回答文データのペア）を抽出する（ステップＳ２０６）。実質的に同じ内容の会話ペアとは、例えば質問文「元気？」と回答文「今日も元気だよ！」のペアと、質問文「元気ですか？」と回答文「今日も元気だよ！」のペアは、質問文が丁寧語か否かの違いのみであって、実質的に同じ内容の会話ペアと判断され得る。

次に、キャラクターＡ対話処理部３２は、ユーザ毎の個人化レイヤー３３１Ａから会話ペアが所定数以上抽出された場合（ステップＳ２０９／Ｙｅｓ）、当該会話ペアを（ユーザ毎の）共通レイヤー３３２Ａに登録する（ステップＳ２１２）。

このように、ユーザ毎の個人化レイヤー３３１において実質的に内容が同じ会話ペアを共通レイヤー３３２に移行することで、共通レイヤー３３２を成長（会話ペアを拡充）させることが可能となる。

また、本実施形態では、特定エージェントの会話ＤＢ（具体的には共通レイヤー）から基本対話用の会話ＤＢへ会話データを移行して基本対話用の会話ＤＢを成長させることも可能である。図１１は、本実施形態による基本対話用会話ＤＢ３３０Ｆへの会話データの移行について説明する図である。例えば、ユーザＸおよびユーザＹが各々エージェント「キャラクターＡ」を選択（購入）し、ユーザＺがエージェント「人物Ｂ」を選択（購入）している場合、図１１に示すように、ユーザＸのキャラクターＡ用会話ＤＢ３３０Ａ−Ｘ、ユーザＹのキャラクターＡ用会話ＤＢ３３０Ａ−Ｙ、およびユーザＺの人物Ｂ用会話ＤＢ３３０Ｂ−Ｚが対話処理部３０に存在し得る。この場合、各個人化レイヤー３３１ＡＸ、３３１Ａ−Ｙ、３３１Ｂ−Ｚには、各ユーザＸ、ユーザＹ、ユーザＺとの対話に応じ
て独自の（カスタマイズされた）会話ペアが登録されていく（図９参照）。次いで、同じエージェントの個人化レイヤー３３１Ａ−Ｘ、３３１Ａ−Ｙにおいて実質同じ会話ペアが所定数あると、ユーザ毎の共通レイヤー３３２Ａ−Ｘ、３３２Ａ−Ｙに各々登録される（図１０参照）。

そして、対話処理部３０は、複数のエージェント（異なるエージェントを含んでもよい）の共通レイヤー３３２Ａ−Ｘ、３３２Ａ−Ｙ、３３２Ｂ−Ｚから実質同じ会話ペアが所定数以上抽出された場合、上位の基本対話用会話ＤＢ３３０Ｆに会話ペアを移行する。基本対話用会話ＤＢ３３０Ｆは、基本対話処理部３１が有する会話ＤＢである。これにより、基本対話用会話ＤＢ３３０Ｆを成長（会話ペアを拡充）させることが可能となる。かかるデータ移行処理について、図１２を参照して具体的に説明する。図１２は、本実施形態による基本対話用ＤＢ３３０Ｆへの会話データ移行処理を示すフローチャートである。

図１２に示すように、まず、対話処理部３０は、定期的に会話ＤＢ３３０の複数の共通レイヤー３３２をサーチし（ステップＳ２２３）、実質同じ会話ペアを抽出する（ステップＳ２２６）。

次に、対話処理部３０は、複数の共通レイヤー３３２から実質同じ会話ペアが所定数以上抽出された場合（ステップＳ２２９／Ｙｅｓ）、当該会話ペアを基本対話用会話ＤＢ３３０Ｆに登録する（ステップＳ２３２）。

このように、複数のエージェントにおける会話ＤＢ３３０の共通レイヤー３３２において実質的に内容が同じ会話ペアを、基本対話用会話ＤＢ３３０Ｆに移行することで、基本対話用会話ＤＢ３３０Ｆを成長（会話ペアを拡充）させることが可能となる。

＜３−５．広告出力処理＞
続いて、広告挿入処理部７０による広告情報の挿入処理について図１３〜図１４を参照して説明する。本実施形態では、広告挿入処理部７０により、エージェントの発言に広告ＤＢ７２に格納されている広告情報の挿入を行うことが可能である。広告ＤＢ７２には、予め広告情報が登録され得る。図１３は、本実施形態による広告ＤＢ７２に登録されている広告情報の一例を示す図である。

図１３に示すように、広告情報６２１は、例えばエージェントID、質問文、広告内容、条件、および確率を含む。エージェントIDは広告内容を発言するエージェントを指定し、質問文は広告内容を挿入するトリガとなるユーザの質問文を指定し、広告内容はエージェントの対話に挿入する広告文章である。また、条件は、広告内容を挿入する条件であって、確率は広告内容を挿入する確率を示す。例えば図１３の１段目に示す例では、エージェント「キャラクターＡ」との対話において、３０歳以下のユーザからの質問文に「チョコレート」という単語が含まれている場合に、「ＢＢ社の新しく発売されたチョコはミルクがたくさん入っていて美味しいよ」といった広告内容が回答文に挿入される。また、トリガとなる質問文が発せられた際に毎回広告内容を挿入するとユーザが煩わしく思ってしまうこともあるため、本実施形態では、広告を挿入する確率を設定するようにしてもよい。かかる確率は広告料に応じて決定されてもよい。例えば広告料が高いほど確率が高く設定される。

このような広告内容の挿入処理について図１４を参照して具体的に説明する。図１４は、本実施形態による広告内容の挿入処理を示すフローチャートである。

図１４に示すように、まず、広告挿入処理部７０は、ユーザとエージェントとの対話（具体的には、対話処理部３０による対話処理）を監視する（ステップＳ２４３）。

次に、広告挿入処理部７０は、ユーザとエージェントとの対話に、広告ＤＢ７２に登録されている質問文と同一の内容の質問文が登場したか否かを判断する（ステップＳ２４６）。

次いで、同一の内容の質問文が登場した場合（ステップＳ２４６／Ｙｅｓ）、広告挿入処理部７０は、該当する質問文と対応付けられている広告挿入の条件および確率を確認する（ステップＳ２４９）。

続いて、広告挿入処理部７０は、条件および確率に基づいて、現在、広告が出せる状態であるか否かを判断する（ステップＳ２５２）。

次に、広告が出せる状態である場合（ステップＳ２５２／Ｙｅｓ）、広告挿入処理部７０は、対話処理部３０による対話処理を一時停止させ（ステップＳ２５５）、広告内容を対話に挿入する（ステップＳ２５８）。具体的には、例えばユーザの質問文に対するエージェントの回答文に、広告内容を挿入させる。

そして、広告内容を含む対話（会話文データ）が対話処理部３０から音声エージェントＩ／Ｆ２０に出力され、音声エージェントＩ／Ｆ２０からクライアント端末１に送信され、エージェントの音声で再生される（ステップＳ２６１）。具体的には、例えば以下のような会話により、キャラクターＡの発言としてユーザに広告内容を提示することができる。

ユーザ：「おはよう」
キャラクターＡ：「おはよう！今日の調子はどうですか？」
ユーザ：「元気だよ。何か美味しい物食べたいな」
キャラクターＡ：「ＣＣ店の焼肉が美味しいらしいよ」

上記会話では、まず、ユーザの質問文「おはよう」に対して、キャラクターＡの会話ＤＢから検索された対応する回答文「おはよう！今日の調子はどうですか？」が音声出力される。次いで、ユーザの質問文「元気だよ。何か美味しい物食べたいな」に、広告挿入のトリガとなる質問文「何か美味しい物食べたいな」が含まれているため（図１３の２段目参照）、広告挿入処理部７０は広告挿入処理を行い、キャラクターＡの音声で広告内容「ＣＣ店の焼肉が美味しいらしいよ」といった回答文が出力される。

以上、本実施形態による通信制御システムの基本的な動作処理として、会話データ登録処理、音素ＤＢ生成処理、対話制御処理、会話ＤＢ更新処理、および広告挿入処理について説明した。

なお、本実施形態による会話データの登録処理は、上述した例に限定されない。本実施形態による会話ＤＢ生成部５０は、多数の一般ユーザからエージェントキャラクター毎の発話文データを収集し、収集した発話文データを監査することが可能である。また、監査した発話文データが一定量蓄積すると、データセットとして対話処理部３０に出力され、対応するエージェントキャラクターの対話処理部３００の会話ＤＢ３３０に格納され得る。以下、このような発話文データの収集、監査を行う会話ＤＢ生成部５０について、図１５〜図３０を参照して具体的に説明する。

＜＜４．発話文データの管理＞＞
＜４−１．構成＞
（４−１−１．会話ＤＢ生成部の構成）
図１５は、本実施形態による会話ＤＢ生成部５０Ａの構成例を示す図である。図１５に示すように、会話ＤＢ生成部５０Ａは、制御部５００、通信部５１０、ユーザ情報ＤＢ５２０、エージェント情報ＤＢ５３０、発話文ＤＢ５４０、および特権者情報ＤＢ５５０を有する。

通信部５１０は、外部装置と有線または無線により接続し、データの送受信を行う機能を有する。例えば通信部５１０は、ネットワークを介して、一般ユーザや特権者（特別な権限を有するユーザ）のクライアント端末１と接続し、データの送受信を行う。

制御部５００は、演算処理装置および制御装置として機能し、各種プログラムに従って会話ＤＢ生成部５０Ａ内の動作全般を制御する。制御部５００は、例えばＣＰＵ、マイクロプロセッサ等の電子回路によって実現される。また、本実施形態による制御部５００は、画面生成部５０１、発話文データ管理部５０２、発話可能性レベル算出部５０３として機能する。

画面生成部５０１は、一般ユーザによる発話文データの登録画面や、発話文データの監査画面を生成する機能を有する。生成された登録画面や監査画面は、通信部５１０を介してユーザのクライアント端末１に送信され、表示される。本実施形態によるエージェントは、例えば特定の著作権者や所有者によって管理され、また、熱心なファンやファンクラブが結成されている所謂アイドルのような存在である。各ユーザは、好きなエージェントに喋らせたい言葉（発話文）を、所定の登録画面から入力して登録することが可能である。例えば熱心なファンであれば、エージェントのキャラクター性をよく理解しているため、著作権者や所有者が全てを制作しなくても、そのキャラクターが言いそうな言葉がファンにより多数登録され、発話文ＤＢ５４０が充実することが期待できる。なお、本実施形態による登録画面や監査画面の具体例については、図２２、図２６、図２７、図２９を参照して後述する。

発話文データ管理部５０２は、発話文ＤＢ５４０に格納されている発話文データの登録、変更、削除といった管理を行う。例えば発話文データ管理部５０２は、ユーザにより登録画面から入力された発話文データを発話文ＤＢ５４０に書き込み、また、監査画面から入力された発話文データの変更を発話文ＤＢ５４０に反映する。

発話可能性レベル算出部５０３は、発話文ＤＢ５４０に格納されている発話文データを、対応するエージェントキャラクターが発言しそうな（言いそうな）度合い（以下、「発話可能性レベル」と称す）を算出する。発話可能性レベルは、例えば0.0〜1.0の数値で算出される。算出方法の詳細については、後述する。

ユーザ情報ＤＢ５２０は、ユーザに関する各種情報を格納する。図１６に、本実施形態によるユーザ情報ＤＢ５２０に格納されているユーザ情報の一例を示す。図１６に示すように、ユーザ情報は、例えばログイン用のユーザＩＤ、パスワード、およびエージェントのファンクラブ会員であるか否かを示すフラグ情報を含む。

エージェント情報ＤＢ５３０は、エージェントに関する各種情報を格納する。図１７に、本実施形態によるエージェント情報ＤＢ５３０に格納されているエージェント情報の一例を示す。図１７に示すように、エージェント情報は、例えばエージェントＩＤや、エージェント画像を含む。また、ＰＶ（Promotion Video）やエージェント音声等の付加情報をさらに含んでいてもよい。

発話文ＤＢ５４０は、各エージェントの発話文データを格納する。図１８に、本実施形態による発話文ＤＢ５４０に格納されている発話文データの一例を示す。図１８に示すように、発話文データは、エージェントＩＤ、発話文、トリガ、発話可能性レベル、および発話可能フラグの情報を含む。エージェントＩＤは、どのエージェントの発話文データかを示すものであって、発話文ＤＢ５４０には、複数のエージェントにそれぞれ紐付けられた発話文データが格納されている。図１８では、一例として「キャラクターＡ」に紐付けられた発話文データが示されている。また、トリガは、当該発話文データをエージェントが発話するタイミングについて設定されているものである。例えば、図１８の発話文データの一行目に示す「おはよう」という発話文は、トリガが「ユーザ設定起床時刻」であるため、ユーザが設定した起床時刻になった際に、キャラクターＡの音声で出力される。また、例えばトリガが「感情：落胆」の発話文「げんきだして」は、ユーザの感情が「落胆」の状態になった際に、キャラクターＡの音声で出力される。ユーザの感情は、発話文を生成する対話処理部３０により、ユーザの行動、生体情報、発話内容、またはＳＮＳ（Social Networking Service）への投稿内容等に基づいて推定される。

発話文ＤＢ５４０に蓄積された発話文データが所定数集まると、制御部５００により対応するエージェントの発話文のデータセットとして対話処理部３００の会話ＤＢ３３０に登録される。

「発話可能性レベル」は、そのエージェントのキャラクターが言いそうな度合いであって、例えば一般ユーザまたは特権者により各々入力された発話可能性レベルに基づいて算出される。図１８に示す例では、0.0〜1.0の数値で発話可能性レベルが設定されている。対話処理部３０は、発話可能性レベルを考慮して発話文データの出力制御を行う。

「発話可能フラグ」は、発話可否の設定であって、特権者により入力される。発話可能フラグが「false」の場合、発話可能性レベルに関わらず、発話不可とされる。なお、本実施形態では発話を許可することを示す「発話可能フラグ」の入力について説明するが、本実施形態はこれに限定されず、発話を禁止することを示す「発話禁止フラグ」の入力を行うようにしてもよい。「発話可能フラグ」および「発話禁止フラグ」は、いずれも発話可否フラグの一例である。

特権者情報ＤＢ５５０は、特権を有するユーザに関する各種情報を格納する。特権を有するユーザ（特権者）は、上述した「発話可能フラグ」を設定できるユーザであって、例えばエージェントの著作権者、所有者、関係者等が想定される。図１９に、本実施形態による特権者情報ＤＢ５５０に格納されている特権者情報の一例を示す。図１９に示すように、特権者情報は、例えばエージェントＩＤ、ログイン用のパスワード、および特権者ＩＤの情報を含む。エージェントＩＤは、どのエージェントの特権者であるかを示すものであって、パスワードおよび特権者ＩＤは、特権者用の監査画面にログインする際に用いられる。

（４−１−２．対話処理部の構成）
図２０は、本実施形態による対話処理部３００Ａの構成例を示す図である。図２０に示すように、対話処理部３００Ａは、質問文検索部３１０、回答文生成部３２０、会話ＤＢ３３０、音素データ取得部３４０、発話文ＤＢ３５０、発話文生成部３６０を有する。

質問文検索部３１０、回答文生成部３２０、会話ＤＢ３３０、および音素データ取得部３４０は、図４を参照して説明した同符号の構成と同様であるので、ここでの説明は省略する。

発話文生成部３６０は、所定のトリガに応じて、発話文データを発話文ＤＢ３５０から検索する。発話文ＤＢ３５０には、会話ＤＢ生成部５０Ａの発話文ＤＢ５４０に蓄積された発話文のデータセットが保存されている。発話文ＤＢ３５０に保存されている発話文データは、会話ＤＢ生成部５０Ａにより定期的に更新されてもよい。

例えば、発話文生成部３６０は、ユーザが設定した起床時刻になった際、「ユーザ設定起床時刻」をトリガとする発話文を発話文ＤＢ３５０から検索し、発話文データとする。この際、発話文生成部３６０は、トリガに加えて、発話文データの発話可能性レベルを考慮して１つの発話文データを選択する。また、発話文生成部３６０は、発話文データの「発話可能フラグ」が「False」の場合、発話文データとして選択しないようにする。このような発話文データの選択については、図３０を参照して詳述する。

発話文生成部３６０により生成された発話文データは、音素データ取得部３４０に出力され、音素データ取得部３４０により特定エージェントの音素が取得され、発話文データおよび音素データが音声エージェントＩ／Ｆ２０に出力される。そして、音声エージェントＩ／Ｆ２０により発話文データが特定エージェントの音声で音声化され、ユーザのクライアント端末１から特定エージェントの発言として出力される。

以上、本実施形態による対話処理部３００Ａの構成について説明した。

＜４−２．動作処理＞
続いて、本実施形態の各動作処理について図２１〜図３０を参照して説明する。

（４−２−１．収集処理）
図２１は、本実施形態による発話文データの収集処理を示すフローチャートである。図２１に示すように、まず、エージェントサーバ２の会話ＤＢ生成部５０Ａは、画面生成部５０１により生成した発話文登録画面を、ユーザが所持するクライアント端末１に表示する（ステップＳ３００）。具体的には、会話ＤＢ生成部５０Ａは、発話文登録画面を通信部５１０からクライアント端末１に送信し、クライアント端末１の表示部に表示させる。

次いで、発話文登録画面から入力されたユーザＩＤ等に基づいてユーザログイン処理が行われる（ステップＳ３０３）。ここで、図２２に、本実施形態による発話文登録画面の一例を示す。図２２に示すように、登録画面１００には、ユーザＩＤ入力欄１０１、パスワード入力欄１０２、ログインボタン１０３、エージェントＩＤ選択欄１０４、発話文入力欄１０５が表示されている。ユーザは、登録画面１００のユーザＩＤ入力欄１０１にユーザＩＤを入力し、さらにパスワード入力欄１０２にパスワードを入力し、ログインボタン１０３を選択する。これにより、入力されたユーザＩＤおよびパスワードがクライアント端末１からエージェントサーバ２の会話ＤＢ生成部５０Ａに送信され、制御部５００によりログイン処理が行われる。具体的には、ユーザ情報ＤＢ５２０に予め登録されたユーザＩＤおよびパスワードを参照し、認証処理を行う。

次に、ユーザによるエージェントの選択を受け付ける（ステップＳ３０６）。例えばユーザは、登録画面１００のエージェントＩＤ選択欄１０４を操作し、プルダウンリストに表示される「キャラクターＡ」、「人物Ｂ」、「人物Ｃ」、「キャラクターＤ」等の複数のエージェントの中から、発話文の登録を行いたいエージェントを選択する。選択したエージェントＩＤは、特定のエージェントの発話文データを要求する要求情報として、クライアント端末１からエージェントサーバ２へ送信される。

次いで、エージェントサーバ２の会話ＤＢ生成部５０Ａは、制御部５００により、ユーザが選択したエージェントの登録済み発話文を発話文ＤＢ５４０から抽出して登録画面１００の発話文入力欄１０５に表示する（ステップＳ３０９）。制御部５００は、発話文データに登録者情報（例えばユーザＩＤ）が紐付けられている場合、特定されたエージェントＩＤの発話文データのうち、ユーザが今までに登録した発話文データを抽出し、クライアント端末の登録画面１００に表示するようにしてもよい。また、ここでは要求情報の一例としてエージェントＩＤをクライアント端末１からエージェントサーバ２に送信しているが、本実施形態はこれに限定されない。例えば、ユーザがシチュエーション情報（トリガ）を特定し、要求情報としてエージェントサーバ２に送信されてもよい。シチュエーション情報（時刻、場所、ユーザ状況、ユーザ感情等）が特定された場合、制御部５００は、特定されたシチュエーションをトリガとする発話文データを発話文ＤＢ５４０から抽出し、クライアント端末１に返信する。また、エージェントＩＤ、ユーザＩＤ、シチュエーション情報の少なくともいずれか１以上がユーザにより特定され、要求情報としてエージェントサーバ２に送信され、制御部５００により該当する発話文データが返信されるようにしてもよい。

次いで、ユーザによる発話文の追加、編集が行われると（ステップＳ３１２）、発話文データ管理部５０２は、ユーザにより追加、編集された発話文データを発話文ＤＢ５４０へ書き込む（ステップＳ３１５）。具体的には、ユーザは、登録画面１００の発話文入力欄１０５に表示されている登録済み発話文の編集や、新規の発話文の入力を行う。発話文入力欄１０５では、発話テキストの編集、入力と、発話タイミングを示すトリガの編集、入力が行われ得る。編集、入力が終了すると、ユーザは登録画面１００に表示されている登録ボタン１０６を選択する。これにより、編集、入力内容がエージェントサーバ２の会話ＤＢ生成部５０Ａに送信され、制御部５００により発話文ＤＢ５４０に格納される。発話文ＤＢ５４０への書き込み処理については図２４を参照して後述する。

このようにして各ユーザから各エージェントの発話文の収集が行われる。なおエージェントの選択は、上述したようなプルダウンリストからの選択に限定されず、エージェントの画像を見ながら選択することも可能である。図２３に、本実施形態によるエージェント選択画面の一例を示す。図示された例では、画面１０８に、複数のエージェントキャラクター１０Ａ〜１０Ｄが表示されている。ユーザは、クライアント端末１に表示された各エージェントキャラクター１０Ａ〜１０Ｄのうち、発話文の編集、入力を行いたいエージェントキャラクターをタップする等して選択する。

続いて、上記ステップＳ３１５における発話文ＤＢ５４０への書き込み処理について図２４を参照して説明する。図２４は、本実施形態による発話文ＤＢ５４０への書き込み処理を示すフローチャートである。

図２４に示すように、まず、会話ＤＢ生成部５０Ａの発話文データ管理部５０２は、書き込まれる発話文データと発話文ＤＢ５４０を比較し（ステップＳ３１８）、重複があるか否かを判断する（ステップＳ３２１）。具体的には、発話文データ管理部５０２は、発話文ＤＢ５４０に格納されている対応するエージェントの登録済み発話文データを参照し、書き込まれる発話文データと重複するものがあるか否かを判断する。

次に、重複する発話文データが無い場合（ステップＳ３２１／Ｎｏ）、発話文データ管理部５０２は、発話文データを発話文ＤＢ５４０へ書き込む処理を行う（ステップＳ３２４）。一方、重複する発話文データが有る場合（ステップＳ３２１／Ｙｅｓ）、発話文ＤＢ５４０への書き込み処理は行われない。

以上、書き込み処理について具体的に説明した。なお、ここでは一例として、発話文データを発話文ＤＢ５４０に登録するときに重複チェックを行っているが、本実施形態はこれに限定されない。例えば発話文データをユーザ毎（登録者毎）に登録し（ユーザ発話文ＤＢ）、ユーザ発話文ＤＢにある程度蓄積された後に、発話文ＤＢ５４０と重複チェックを行ってマージしてもよい。

（４−２−２．監査処理）
次に、収集された発話文データの監査処理について図２５〜図２９を参照して説明する。発話文データの監査を行うユーザには、各種ランク付けを行ってもよい。例えば、対応するエージェントのファンクラブ会員等、熱心なファンであるか否か、また、対応するエージェントの著作権者や所有者等の特別な権限を持つユーザ（いわゆる特権者）であるか否か等のランク付けである。これにより、例えばファンクラブ会員により発話可能性レベルが変更され、更新する際は、非会員の場合よりも重みを付けて算出することが可能である。また、特権者であれば発話可能フラグを付与できるようにすることも可能である。以下、ファンクラブ会員を含む一般ユーザによる監査と、特権者による監査について、順次説明する。

（一般ユーザによる監査）
図２５は、本実施形態による一般ユーザの監査処理を示すフローチャートである。図２５に示すように、まず、エージェントサーバ２の会話ＤＢ生成部５０Ａは、画面生成部５０１により生成した一般ユーザ用監査画面を、クライアント端末１に表示する（ステップＳ４０３）。

次いで、ユーザにより一般ユーザ用監査画面からユーザＩＤおよびパスワードが入力され（ステップＳ４０６）、ログインボタンが押下されると（ステップＳ４０９）、会話ＤＢ生成部５０Ａは、入力された情報に基づいて制御部５００によりユーザログイン処理を行う（ステップＳ４１２〜Ｓ４１５）。

具体的には、制御部５００は、ユーザ情報ＤＢ５２０に登録されたＩＤとパスワードの組を探索し（ステップＳ４１２）、ユーザが入力したＩＤとパスワードの組と一致するか否かを判断することで、認証を行う（ステップＳ４１５）。ここで、図２６に、本実施形態による一般ユーザ用監査画面の一例を示す。図２６に示すように、監査画面１１０には、一般ユーザＩＤ入力欄１１１、パスワード入力欄１１２、およびログインボタン１１３が表示されている。ユーザは、監査画面１１０のユーザＩＤ入力欄１１１にユーザＩＤを入力し、さらにパスワード入力欄１１２にパスワードを入力し、ログインボタン１１３を選択する。これにより、入力されたユーザＩＤおよびパスワードがクライアント端末１からエージェントサーバ２の会話ＤＢ生成部５０Ａに送信される。

次に、入力されたＩＤおよびパスワードと一致する組があった場合（ステップＳ４１５／Ｙｅｓ）、認証が成功したため、制御部５００は、エージェント情報ＤＢ５３０からエージェントＩＤを抽出して一般ユーザ用監査画面に提示（リスティング）する（ステップＳ４１８）。具体的には、例えば図２７に示すように、監査画面１１０ａのエージェントＩＤ選択欄１１４において、複数のエージェントＩＤのリストがプルダウン形式で表示される。

次いで、ユーザによりエージェントＩＤが選択されると（ステップＳ４２１）、制御部５００は、発話文ＤＢ５４０から、ユーザにより選択されたエージェントＩＤに紐付けられた発話文、トリガ、発話可能性レベルを抽出して一般ユーザ用監査画面に提示（リスティング）する（ステップＳ４２４）。具体的には、例えば図２７に示すように、一般ユーザ用監査画面１１０ａの発話情報調整欄１１５に、発話文（発話内容を示すテキスト）、トリガ、発話可能性レベルが表示される。発話可能性レベルは、数値表示（0.0〜1.0）であってもよいし、図２７に示すようなスライドバー表示であってもよい。ユーザは、登録済みの発話文がエージェントに相応しいものであるか否かを監査し、相応しくない発話文であれば「発話可能性レベル」のスライダーを調整して発話可能性レベルを低く設定する（ステップＳ４２７）。初期値ではスライダーが中央に表示されている（デフォルト値0.5）。また、発話文の新規追加を行いたい場合、発話情報調整欄１１５の下方にある「新規」の欄に発話文を新たに入力することも可能である。

なお、ここでは一例として、エージェントＩＤを発話文データを要求するための要求情報としてエージェントＩＤが用いられているが、本実施形態はこれに限定されず、例えばユーザＩＤやシチュエーション情報等が要求情報として用いられてもよい。例えばシチュエーション情報がユーザにより特定され、クライアント端末１から送信された場合、制御部５００は、特定されたシチュエーションをトリガとする発話文データを発話文ＤＢ５４０から抽出し、クライアント端末１に返信する。

次に、一般ユーザ用監査画面１１０ａの完了ボタン１１６がユーザにより押下されると（ステップＳ４３０）、発話情報調整欄１１５で変更された内容がエージェントサーバ２に送信される。会話ＤＢ生成部５０Ａは、クライアント端末１から送信された変更内容に基づいて、各発話文の発話可能性レベルが変更されたか否かを確認する（ステップＳ４３３）。

続いて、発話可能性レベルが変更されていた場合（ステップＳ４３３／Ｙｅｓ）、発話可能性レベル算出部５０３は、一般ユーザに入力された発話可能性レベルに基づいて、発話文ＤＢ５４０に登録された対応する発話文の発話可能性レベルを更新する（ステップＳ４３６）。発話可能性レベルの更新は、例えば下記式１により算出される。下記式１は、一例として、一般ユーザのうち、対応するエージェントキャラクターのファンクラブ会員による入力を重視して更新する場合の算出式を示す。ファンクラブ会員であればエージェントキャラクターの性格をより理解しているため、入力した発話可能性レベルの信頼度が高いと考えるためである。

下記式１において、Wは重み（例えば一般ユーザの場合0.05、ファンクラブ会員の場合0.5とする）、Ioは発話文ＤＢ５４０に登録されている過去の発話可能性レベル（0.0〜1.0）、Iuは、ユーザによって入力された発話可能性レベル（0.0〜1.0）、Inは更新された発話可能性レベルである。

そして、発話文データ管理部５０２は、発話可能性レベル算出部５０３により算出された発話可能性レベルを発話文ＤＢ５４０に書き込む（ステップＳ４３９）。なお変更内容が発話文の新規追加の場合、図２４に示す重複チェックを行った上で、重複が無ければ発話文ＤＢ５４０に書き込みが行われる。

（特権者による監査）
次に、特別な権限を有するユーザ（特権者）による監査処理について図２８を参照して説明する。図２８は、本実施形態による特権者の監査処理を示すフローチャートである。特権者は、例えばエージェントキャラクターの著作者や所有者等が想定される。

図２８に示すように、まず、エージェントサーバ２の会話ＤＢ生成部５０Ａは、画面生成部５０１により生成した特権者用監査画面を、クライアント端末１に表示する（ステップＳ５０３）。

次いで、ユーザにより特権者用監査画面から特権者ＩＤおよびパスワードが入力され（ステップＳ５０６）、ログインボタンが押下されると（ステップＳ５０９）、会話ＤＢ生成部５０Ａは、入力された情報に基づいて制御部５００によりユーザログイン処理を行う（ステップＳ５１２〜Ｓ５１５）。

具体的には、制御部５００は、特権者情報ＤＢ５５０に登録されたＩＤとパスワードの組を探索し（ステップＳ５１２）、ユーザが入力したＩＤとパスワードの組と一致するか否かを判断することで、認証を行う（ステップＳ５１５）。ここで、図２９に、本実施形態による特権者用監査画面の一例を示す。図２９に示すように、監査画面１２０には、特権者ＩＤ入力欄１２１、パスワード入力欄１２２、およびログインボタン１２３が表示されている。ユーザは、監査画面１２０の特権者ＩＤ入力欄１２１にユーザＩＤを入力し、さらにパスワード入力欄１２２にパスワードを入力し、ログインボタン１２３を選択する。これにより、入力された特権者ＩＤおよびパスワードがクライアント端末１からエージェントサーバ２の会話ＤＢ生成部５０Ａに送信される。

次に、入力されたＩＤおよびパスワードと一致する組があった場合（ステップＳ５１５／Ｙｅｓ）、認証が成功したため、制御部５００は、エージェント情報ＤＢ５３０から、特権対象のエージェントＩＤ（特権者情報ＤＢ５５０で一致した組に紐付けられたエージェントＩＤ）を抽出して特権者用監査画面に提示（リスティング）する（ステップＳ５１８）。具体的には、例えば図２９に示すように、監査画面１２０のエージェントＩＤ選択欄１２４において、特権対象のエージェントＩＤのリストがプルダウン形式で表示される。

次いで、ユーザによりエージェントＩＤが選択されると（ステップＳ５２１）、制御部５００は、発話文ＤＢ５４０から、選択されたエージェントＩＤに紐付けられた発話文、トリガ、発話可能フラグ情報を抽出して特権者用監査画面に提示（リスティング）する（ステップＳ５２４）。具体的には、例えば図２９に示すように、特権者用監査画面１２０の発話情報調整欄１２５に、発話文、トリガ、発話可能フラグが表示される。発話可能フラグは、例えばチェックボックス形式で表示され、発話可能フラグが「true」の場合にチェックが入るよう表示される。特権者は、登録済みの発話文がエージェントに相応しいものであるか否かを監査し、エージェントに相応しくなく、発話を許可しないと判断した場合、チェックボックスを選択し、「発話可能フラグ」のチェックを外す（ステップＳ５２７）。チェックが外された発話文は、発話可能性レベルの数値に関わらず、エージェントの発話として出力しないよう制御される。

次に、特権者用監査画面１２０の完了ボタン１２６がユーザにより押下されると（ステップＳ５３０）、発話情報調整欄１２５で変更された内容がエージェントサーバ２に送信される。会話ＤＢ生成部５０Ａは、クライアント端末１から送信された変更内容に基づいて、各発話文の発話可能フラグが変更されたか否かを確認する（ステップＳ５３３）。

続いて、発話可能フラグが変更されていた場合（ステップＳ５３３／Ｙｅｓ）、発話文データ管理部５０２は、特権者に変更された発話可能フラグを発話文ＤＢ５４０にセットする（ステップＳ５３６）。具体的には、例えば特権者用監査画面１２０の発話情報調整欄１２５において発話可能性フラグのチェックが外された場合は「False」、チェックが入れられた場合は「true」とセットされる。

（４−２−３．発話制御処理）
次いで、本実施形態による発話制御処理について図３０を参照して説明する。図３０は、本実施形態による発話制御処理を示すフローチャートである。

図３０に示すように、まず、エージェントサーバ２の対話処理部３００Ａは、トリガ情報を取得する（ステップＳ６０３）。トリガ情報は、時計、ＧＵＩ（Graphical User Interface）（例えば画面操作内容等）、ユーザ発話の音声認識結果、ユーザの行動、生体情報等から得られた情報から取得される。

次に、トリガ情報が時刻の場合（ステップＳ６０６／時刻）、発話文生成部３６０は、発話文ＤＢ３５０に格納されている発話文データのトリガ列から、取得したトリガの指定時刻に該当する行リストを取得する（ステップＳ６０９）。例えば、発話文ＤＢ３５０に、図１８に示す発話文ＤＢ５４０のデータ例がキャラクターＡの発話データセットとして格納され、トリガ情報が「１２時」の場合、トリガ列が「１２時」となっている行リスト（発話文「おひるだよ」、「おひる」、「おひるです」、「じゅうにじです」、「ひるめしだぞ」の行リスト）が取得される。

一方、トリガ情報が感情の場合（ステップＳ６０６／感情）、発話文ＤＢ３５０に格納されている発話文データのトリガ列から、取得したトリガの感情に該当する行リストを取得する（ステップＳ６１２）。例えば、発話文ＤＢ３５０に、図１８に示す発話文ＤＢ５４０のデータ例がキャラクターＡの発話データセットとして格納され、トリガ情報が「落胆」の場合、トリガ列が「感情：落胆」となっている行リスト（発話文「げんきだして」、「がんばって」、「きみならできる」、「がんばってください」の行リスト）が取得される。

次いで、発話文生成部３６０は、取得した行リストの各発話可能フラグ（true／false）を確認する（ステップＳ６１５）。

次に、発話文生成部３６０は、発話可能フラグが「true」の発話文から発話可能性レベルに基づいて１つの発話文を選択する（ステップＳ６１８）。なお発話可能フラグが「false」の発話文は選択されない。ここで、発話可能性レベルを用いた発話文の選択処理について、例えば３つの候補から１つを選択する場合の具体例について説明する。

まず、発話候補リスト（A）を下記のように定義する。
A=[{S1:R1},{S2:R2},{S3:R3}]
上記式において、
Sn：発話文
Rn：発話可能性レベル
[]：配列
{}：辞書
S：選択された発話
とする。

これにより、不確定な要素を含みつつも、発話可能性レベルの高い発話が選ばれる傾向が高くなる。発話可能性レベルの高さのみで選択することも可能であるが、その場合は毎回同じ発話文が選択されてしまうため、発話可能性レベルに重みを付け、乱数を用いて選ぶことで、発話可能性レベルを考慮しつつ毎回同じ発話文が選択されてしまうことを回避することができる。

そして、対話処理部３００Ａは、発話文生成部３６０により選択された発話文をクライアント端末１からエージェントの発言として出力するよう制御する（ステップＳ６２１）。具体的には、対話処理部３００Ａは、発話文生成部３６０により生成された発話文データを音素データ取得部３４０に出力し、音素データ取得部３４０により特定エージェントの音素を取得し、発話文データおよび音素データを音声エージェントＩ／Ｆ２０に出力する。そして、音声エージェントＩ／Ｆ２０により発話文データが特定エージェントの音声で音声化され（例えばＴＴＳ（Text-to-Speech）による音声出力）、ユーザのクライアント端末１から特定エージェントの発言として出力される。

＜＜５．まとめ＞＞
上述したように、本開示の実施形態による通信制御システムでは、エージェントの発話文データの監査をより柔軟に行うことが可能である。

具体的には、大衆からエージェントの発話データを収集して発話データベースの充実を図るとともに、大衆の嗜好に合った発話データの利用を容易とし、さらにエージェントのイメージに合わない発話データを容易に排除できるようにすることで、監査の柔軟性を実現する。

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

例えば、上述したクライアント端末１またはエージェントサーバ２に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、クライアント端末１またはエージェントサーバ２の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。

また、上述した実施形態では、インターネット上のエージェントサーバ２で各種機能が実現される構成を示したが、本実施形態はこれに限定されず、エージェントサーバ２の構成のうち少なくとも一部が、ユーザのクライアント端末１（スマートフォンやウェアラブル端末等）にあってもよい。また、エージェントサーバ２の構成全てがクライアント端末１に設けられ、クライアント端末１で全ての処理を行えるようにしてもよい。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、本技術は以下のような構成も取ることができる。
（１）
エージェントの発話文データを記憶する記憶部と、
クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を受信する通信部と、
前記通信部を介して前記要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて前記記憶部に記録する制御部と、
を備える、情報処理システム。
（２）
前記制御部は、前記ユーザに設定されたランクに応じて重み付けを行った上で、前記発話可能性レベルを更新する、前記（１）に記載の情報処理システム。
（３）
前記制御部は、特別な権利を有するランクのユーザの入力に応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話することの可否を示す発話可否フラグを当該発話文データに付与する、前記（１）または（２）に記載の情報処理システム。
（４）
前記要求情報は、エージェント識別情報、ユーザ識別情報、シチュエーション情報、またはキーワードを含む、前記（１）〜（３）のいずれか１項に記載の情報処理システム。
（５）
前記制御部は、
クライアント端末を介して送信される、ユーザにより入力された特定のエージェントに発話させたい発話文データを前記通信部を介して収集し、
前記記憶部に、前記特定のエージェントの識別情報と前記発話文データを対応付けて登録する、前記（１）〜（４）のいずれか１項に記載の情報処理システム。
（６）
前記発話可能性レベルは、特定のシチュエーション毎に設定される、前記（１）〜（５）のいずれか１項に記載の情報処理システム。
（７）
前記特定のシチュエーション情報は、対応する発話文データで示される発話内容をエージェントが発話するトリガとなる時刻、場所、ユーザ状況、またはユーザ感情である、前記（６）に記載の情報処理システム。
（８）
前記制御部は、
前記通信部を介して、クライアント端末から送信される、特定のエージェントの発話のトリガになる可能性があるトリガ情報を取得し、
前記トリガ情報に基づいて、前記特定のエージェントの発話文データから各発話可能性レベルを考慮して該当する発話文データを選択し、前記クライアント端末に返信する、前記（１）〜（７）のいずれか１項に記載の情報処理システム。
（９）
前記制御部は、
トリガ情報として、特定の時間帯になったことを取得し、
前記特定のエージェントの各発話文データに関連付けられる時間帯情報および発話可能性レベルを考慮して、前記時間帯情報に合致する発話文データを選択する、前記（８）に記載の情報処理システム。
（１０）
前記制御部は、前記特定のエージェントに関連付けられる発話文データのうち、特別な権利を有するランクのユーザにより入力された発話可否フラグに応じて、発話が許可されている発話文データを抽出し、抽出した発話文データにそれぞれ付与される発話可能性レベルに応じて、一の発話文データを選択し、前記クライアント端末に返信する、前記（８）または（９）に記載の情報処理システム。
（１１）
プロセッサが、
エージェントの発話文データを記憶部に記憶することと、
クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を通信部により受信することと、
前記通信部を介して前記要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて前記記憶部に記録するよう制御することと、
を含む、情報処理方法。

１ クライアント端末
２ エージェントサーバ
３０ 対話処理部
３００、３００Ａ 対話処理部
３１０ 質問文検索部
３２０ 回答文生成部
３３０ 会話ＤＢ
３４０ 音素データ取得部
３５０ 発話文ＤＢ
３６０ 発話文生成部
３１ 基本対話処理部
３２ キャラクターＡ対話処理部
３３ 人物Ｂ対話処理部
３４ 人物Ｃ対話処理部
３５ マッチング部
３６ 通信部
４０ 音素記憶部
４１ 基本用音素ＤＢ
４２ キャラクターＡ音素ＤＢ
４３ 人物Ｂ音素ＤＢ
４４ 人物Ｃ音素ＤＢ
５０、５０Ａ 会話ＤＢ生成部
５００ 制御部
５０１ 画面生成部
５０２ 発話文データ管理部
５０３ 発話可能性レベル算出部
５１０ 通信部
５２０ ユーザ情報ＤＢ
５３０ エージェント情報ＤＢ
５４０ 発話文ＤＢ
５５０ 特権者情報ＤＢ
６０ 音素ＤＢ生成部
７０ 広告挿入処理部
７２ 広告ＤＢ
８０ フィードバック取得処理部
３ ネットワーク
１０ エージェント

Claims (12)

1. クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて記憶部に記録する制御部を備える、情報処理システム。
2. 前記制御部は、前記ユーザに設定されたランクに応じて重み付けを行った上で、前記発話可能性レベルを更新する、請求項１に記載の情報処理システム。
3. 前記制御部は、特別な権利を有するランクのユーザの入力に応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話することの可否を示す発話可否フラグを当該発話文データに付与する、請求項１または２に記載の情報処理システム。
4. 前記要求情報は、エージェント識別情報、ユーザ識別情報、シチュエーション情報、またはキーワードを含む、請求項１〜３のいずれか１項に記載の情報処理システム。
5. 前記制御部は、
   クライアント端末を介して送信される、ユーザにより入力された特定のエージェントに発話させたい発話文データを収集し、
   前記記憶部に、前記特定のエージェントの識別情報と前記発話文データを対応付けて登録する、請求項１〜４のいずれか１項に記載の情報処理システム。
6. 前記発話可能性レベルは、特定のシチュエーション毎に設定される、請求項１〜５のいずれか１項に記載の情報処理システム。
7. 前記特定のシチュエーション情報は、対応する発話文データで示される発話内容をエージェントが発話するトリガとなる時刻、場所、ユーザ状況、またはユーザ感情である、請求項６に記載の情報処理システム。
8. 前記制御部は、
   クライアント端末から送信される、特定のエージェントの発話のトリガになる可能性があるトリガ情報に基づいて、前記特定のエージェントの発話文データから各発話可能性レベルを考慮して該当する発話文データを選択し、前記クライアント端末に返信する、請求項１〜７のいずれか１項に記載の情報処理システム。
9. 前記制御部は、
   トリガ情報として、特定の時間帯になったことを取得し、
   前記特定のエージェントの各発話文データに関連付けられる時間帯情報および発話可能性レベルを考慮して、前記時間帯情報に合致する発話文データを選択する、請求項８に記載の情報処理システム。
10. 前記制御部は、前記特定のエージェントに関連付けられる発話文データのうち、特別な権利を有するランクのユーザにより入力された発話可否フラグに応じて、発話が許可されている発話文データを抽出し、抽出した発話文データにそれぞれ付与される発話可能性レベルに応じて、一の発話文データを選択し、前記クライアント端末に返信する、請求項８または９に記載の情報処理システム。
11. プロセッサが、
    クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を通信部により受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて記憶部に記録するよう制御することと、
    を含む、情報処理方法。
12. コンピュータを、
    クライアント端末から送信される、ユーザからの特定のエージェントの発話文データを要求する要求情報を受信すると、対応する発話文データを前記クライアント端末に返信し、当該発話文データに対する前記ユーザからのフィードバックに応じて、前記特定のエージェントが当該発話文データで示される発話内容を発話する可能性を表す発話可能性レベルを更新し、前記特定のエージェントと前記発話内容に関連付けて記憶部に記録する制御部、
    として機能させるための情報処理プログラム。

Images