JPWO2017163515A1 - 情報処理システム、情報処理装置、情報処理方法、および記録媒体 - Google Patents

Abstract

【課題】エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることが可能な情報処理システム、情報処理装置、情報処理方法、および記録媒体を提供する。
【解決手段】夫々異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶される記憶部と、ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージをクライアント端末に返信する通信部と、ユーザからの指示に応じて複数のエージェントから特定のエージェントを選択し、特定のエージェントとユーザとの対話に応じて特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し、ユーザ用エージェントの属性と実在する複数の相手ユーザの属性とを比較することによりユーザ用エージェントの属性に最も類似する相手ユーザを特定し、所定のタイミングでユーザに相手ユーザの存在を通知する制御部を備える情報処理システム。
【選択図】図１

Description

本開示は、情報処理システム、情報処理装置、情報処理方法、および記録媒体に関する。

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

また、情報処理端末において、ユーザのメッセージに対して自動で応答を行うエージェントシステムが提案されている。このようなシステムに関し、例えば下記特許文献１では、閲覧者の端末に閲覧者個人のエージェントが駐在し、これが日々閲覧者と会話することで、閲覧者の好みの情報選択能力を獲得していくシステムが記載されている。

また、下記特許文献２では、ユーザとアシスタント（キャラクターのアニメーションによるユーザインタフェース）との過去の会話やその他やり取りの履歴や履歴に基づく性格・感情や学習データ等に基づいて、アシスタントのイメージ生成や行動パターンの生成が行われる対話型操作支援システムが記載されている。

また、下記特許文献３では、オンラインデートサーチのようなオンラインサーチ結果の初期印象属性を選択および表示するシステムが記載されている。また、デートサービス（恋人紹介所）において個人が求める好みを有する潜在的候補がサーチされるシステムが記載されている。

また、下記特許文献４では、男性会員と女性会員の写真データを格納し、各会員が異性会員の写真データを閲覧し、異性写真に対する脳波に基づいて理想像を紹介するマッチングシステムが記載されている。

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

ここで、従来のエージェントシステムでは、人間の代わりをするエージェントがユーザの会話相手になったり、ユーザのスケジュール管理や情報の整理の手伝いをする等、エンターテイメントまたはエンターテイメント性を持った実用ツールとして提案されてきた。また、エージェントを複数から選ぶことができたり、会話内容に応じてエージェントを学習、成長させることが可能であった。

しかしながら、従来のエージェントシステムは、人間を模倣した機械による自動応答に過ぎず、エージェントとコミュニケーションを行っても実在の人間と繋がることはなかった。

そこで、本開示では、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることが可能な情報処理システム、情報処理装置、情報処理方法、および記録媒体を提案する。

本開示によれば、それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶される記憶部と、ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に返信する通信部と、ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し、前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し、前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し、所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御する制御部と、を備える、情報処理システムを提案する。

本開示によれば、それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し、前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、を備える、情報処理装置を提案する。

本開示によれば、プロセッサが、それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報を記憶部に記憶することと、ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に通信部により返信することと、ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し、前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し、前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し、所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御することと、を含む、情報処理方法を提案する。

本開示によれば、コンピュータを、それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し、前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、として機能させるためのプログラムを提案する。

以上説明したように本開示によれば、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることが可能となる。

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

本開示の一実施形態による通信制御システムの概要について説明する図である。 本実施形態による通信制御システムの全体構成を示す図である。 本実施形態による音声エージェントサーバの構成の一例を示すブロック図である。 本実施形態による対話処理部の構成例を示す図である。 本実施形態による会話ＤＢの生成処理を示すフローチャートである。 本実施形態による音素ＤＢの生成処理を示すフローチャートである。 本実施形態による対話制御処理を示すフローチャートである。 本実施形態による会話ＤＢのデータ構成例について説明する図である。 本実施形態による会話ＤＢの更新処理を示すフローチャートである 本実施形態による個人化レイヤーから共通レイヤーへの会話データ移行処理を示すフローチャートである。 本実施形態による基本対話用会話ＤＢへの会話データの移行について説明する図である。 本実施形態による基本対話用ＤＢへの会話データ移行処理を示すフローチャートである。 本実施形態による広告ＤＢに登録されている広告情報の一例を示す図である。 本実施形態による広告内容の挿入処理を示すフローチャートである。 本実施形態による通信制御システムのシステム構成例を示す図である。 本実施形態による対話処理部の構成例を示す図である。 本実施形態によるマッチング部の構成例を示す図である。 本実施形態によるクライアント端末の構成の一例を示すブロック図である。 本実施形態による探索フェーズの動作処理を示すフローチャートである。 本実施形態による固定フェーズの動作処理を示すフローチャートである。 本実施形態による紹介フェーズの動作処理を示すフローチャートである。 本実施形態による支援フェーズの動作処理を示すフローチャートである。 本実施例による準備フェーズの動作処理を示すフローチャートである。 本実施例による基本情報の具体例を示す図である。 本実施例による基本条件情報の具体例を示す図である。 本実施例によるユーザの嗜好情報例を示す図である。 本実施例によるエージェントの基本情報例を示す図である。 本実施例によるエージェントの基本条件情報例を示す図である。 本実施例によるエージェントの嗜好情報例を示す図である。 本実施例によるエージェント選択画面例を示す図である。 本実施例による探索フェーズの動作処理を示すフローチャートである。 本実施例による探索フェーズの動作処理を示すフローチャートである。 本実施例によるユーザ行動履歴を利用したエージェントの発話例を説明する図である。 本実施例によるユーザの生体情報を利用したエージェントの発話例を説明する図である。 本実施例によるＳＮＳ情報を利用したエージェントの発話例を説明する図である。 本実施例によるエージェント対話処理のフローチャートである。 本実施例によるエージェント対話処理のフローチャートである。 本実施例によるエージェント学習の動作処理を示すフローチャートである。 本実施例によるネガポジ判定および言葉使い判定について説明するための図である。 本実施例によるマッチングの動作処理を示すフローチャートである。 本実施例によるエージェントの基本条件情報を用いた検索について説明する図である。 本実施例による嗜好情報の類似度算出について説明する図である。 本実施例による固定フェーズの動作処理を示すフローチャートである。 本実施例によるエージェントの嗜好が変化した場合における対話例を示す図である。 本実施例による紹介承認可否の通知画面の一例を示す図である。 本実施例による紹介フェーズの動作処理を示すフローチャートである。 本実施例によるユーザへの紹介通知の一例を示す図である。 本実施例による紹介相手の詳細情報表示画面の一例を示す図である。 本実施例による支援フェーズの動作処理を示すフローチャートである。 本実施例による出会いプラン選択画面の一例を示す図である。 本実施例による出会いプラン通知画面の一例を示す図である。 本実施例によるエージェントによる最後のお祝いメッセージ画面の一例を示す図である。

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

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による通信制御システムの概要
２．構成
２−１．システム構成
２−２．サーバの構成
３．システム動作処理
３−１．会話データ登録処理
３−２．音素ＤＢ生成処理
３−３．対話制御処理
３−４．会話ＤＢ更新処理
３−５．広告挿入処理
４．対話制御処理
４−１．構成
４−２．動作処理
４−３．実施例
（４−３−１．準備フェーズ）
（４−３−２．探索フェーズ）
（４−３−３．固定フェーズ）
（４−３−４．紹介フェーズ）
（４−３−５．支援フェーズ）
５．まとめ

＜＜１．本開示の一実施形態による通信制御システムの概要＞＞
本開示の一実施形態による通信制御システム（エージェントシステム）は、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることを可能とする。以下、図１を参照して本実施形態による通信制御システムの概要について説明する。

図１は、本開示の一実施形態による通信制御システムの概要について説明する図である。ユーザは、人格を持つエージェントとの対話を日常的に行い、状況に応じて実世界やインターネット上のコンテンツ等の推薦、ニュースや天気予報等の情報提供、ゲームの提供、道案内等々の様々なエージェントサービスを享受する。エージェントとの対話は、例えば表示部１０６を介して行われ、表示部１０６にエージェントの画像や会話が表示され得る。また、図示しないスピーカからエージェント音声が再生される。ユーザの発話は、図示しないマイクロホンにより収音され、エージェントシステム側で言語解析される。

また、本実施形態では、エージェントとして、それぞれ異なる人格を持った複数のエージェントキャラクターが用意され、ユーザは任意のエージェントキャラクターを選択、購入して、当該エージェントキャラクターによるエージェントサービスを利用する。

（背景）
ここで、従来のエージェントシステムでは、人間の代わりをするエージェントがユーザの会話相手になったり、ユーザのスケジュール管理や情報の整理の手伝いをする等、エンターテイメントまたはエンターテイメント性を持った実用ツールとして提案されてきた。また、エージェントを複数から選ぶことができたり、会話内容に応じてエージェントを学習、成長させることが可能であった。

しかしながら、従来のエージェントシステムは、人間を模倣した機械による自動応答に過ぎず、エージェントとコミュニケーションを行っても実在の人間と繋がることはなかった。

そこで、本開示では、ユーザとエージェントの対話に応じて、当該エージェントと同様の性格や嗜好を持つ実在の人物をマッチングし、シームレスに実在人物とのコミュニケーションや出会いに繋げる実世界指向のエージェントシステムを提案する。仮想的な人物（エージェント）だけでなく、実在の人物と繋がることで人間本来の充実した生活や心の満足感をユーザに与えることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、本実施形態による対話制御処理は、上述した例に限定されない。本実施形態による対話処理部３０は、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることも可能である。以下、図１５〜図４８を参照して具体的に説明する。

＜＜４．対話制御処理＞＞
＜４−１．構成＞
（４−１−１．システム構成）
図１５は、本実施形態による通信制御システムのシステム構成例を示す図である。本実施形態では、一例として、ユーザとエージェントとの対話に応じて、結婚相談所の会員情報を用いて、婚活会員とのマッチングを行う場合について説明する。

図１５に示すように、本実施形態による通信制御システムは、クライアント端末１、エージェントサーバ２、管理サーバ４を含む。管理サーバ４は、結婚相談所の会員情報（婚活会員情報４１）を管理する機能を有し、エージェントサーバ２からの要求に応じて会員情報の提供を行う。

（４−１−２．対話処理部３０ａの構成）
次に、本実施形態によるエージェントサーバ２に含まれる対話処理部３０ａの構成例について図１６を参照して説明する。本実施形態による対話処理部３０ａは、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げる実世界実働型のエージェントシステムを実現する。

図１６は、本実施形態による対話処理部３０ａの構成例を示す図である。図１６に示すように、対話処理部３０ａは、基本対話処理部３１、キャラクターＡ対話処理部３２、人物Ｂ対話処理部３３、人物Ｃ対話処理部３４、マッチング部３５、および通信部３６を有する。

基本対話処理部３１、キャラクターＡ対話処理部３２、人物Ｂ対話処理部３３、および人物Ｃ対話処理部３４は、図３を参照して上述した通りである。キャラクターＡ、人物Ｂ、人物Ｃは、いずれもエージェントキャラクターの一例である。

通信部３６は、ネットワークを介して外部装置とデータの送受信を行い得る。例えば通信部３６は、管理サーバ４から婚活会員情報を受信したり、マッチングした相手に承諾通知を送信したりする。

マッチング部３５は、ユーザとエージェントの対話に応じて、当該エージェントと同様の性格や嗜好を持つ実在の人物をマッチングする機能を有する。マッチング部３５の詳細な構成については、図１７を参照して次に説明する。

（４−１−３．マッチング部３５の構成）
図１７は、本実施形態によるマッチング部３５の構成例を示す図である。図１７に示すように、マッチング部３５は、ユーザ用エージェント対話処理部３５０、ユーザ／エージェント情報管理部３５１、ユーザ情報ＤＢ３５２、エージェント情報ＤＢ３６０、エージェント学習部３５３、ユーザ用エージェントＤＢ３５４、紹介ユーザ選出部３５５、親密度算出部３５６、紹介処理部３５７、シナリオ管理部３５８、およびシナリオＤＢ３５９を有する。

ユーザ／エージェント情報管理部３５１は、ユーザ情報ＤＢ３５２に対するユーザ情報、またはエージェント情報ＤＢ３６０に対するエージェント情報の登録、変更、更新、削除等を行う機能を有する。ユーザ情報は、例えばクライアント端末１でユーザにより入力され、エージェントサーバ２へ送信される。若しくは、ユーザ情報は、管理サーバ４の婚活会員情報４１から抽出される。ユーザ情報は、ユーザＩＤ、年齢、職業、家族構成、家族同居、年収、居住地、血液型等の基本情報を含む。各項目は、最終的な紹介相手（マッチング相手）への公開可否に関する公開属性を有する。また、ユーザ情報は、好みの相手を特定する基本条件情報を含む。基本条件情報は、年齢、職業、家族構成、家族同居、年収、居住地、血液型といった、結婚相談所でマッチング相手を探す際の項目に成り得るような情報におけるユーザの希望条件を示すものである。各項目には優先度が設定でき、優先度の高い項目を重視して当該属性を持ったエージェントを最初に選択することも可能となる。また、ユーザ情報は、ユーザの嗜好情報を含む。嗜好情報は、例えば項目毎に-1.0（嫌い）〜1.0（好き）の範囲で数値が設定されていてもよいし、「大好き、好き、どちらでもない、嫌い、大嫌い」等のアンケート形式で入力された情報が登録されていてもよい。また、ユーザの嗜好情報は、予めユーザが入力してもよいし、ユーザとエージェントとの対話に応じて、嗜好情報が生成されたり編集されたりしてもよい。例えばエージェントとの対話の中で「僕はラーメンには目がなくて」というユーザの発言があった場合、自動的に「ラーメン」の項目を生成し、「1.0」を設定してもよい。

エージェントに関しても同様の情報がエージェント情報ＤＢ３６０に格納される。エージェントの基本情報、基本条件情報、および嗜好情報は、デフォルト値が設定される。

なおユーザやエージェントの基本情報等の具体例は、図２４〜図２７に示す。

エージェント学習部３５３は、ユーザ用エージェント対話処理部３５０におけるユーザ用エージェントの人格（属性）を、ユーザとの対話を学習することでユーザ好みに変化させる機能を有する。ユーザ用エージェント対話処理部３５０の初期値は、例えば予め用意した複数のエージェントキャラクターからユーザが選択したエージェントであって、対話を行っていくうちに徐々にエージェント学習部３５３によりユーザ好みのエージェントに変化する。ユーザ用エージェントＤＢ３５４には、エージェント学習部３５３によりユーザ好みに変化したユーザ用エージェントの属性（例えば基本情報、基本条件情報、および嗜好情報の各項目）が格納され、適宜更新される。また、ユーザ用エージェントの属性には、エージェントの外観（顔のタイプ、髪型、服装のタイプ等）も含まれ得る。

ユーザ用エージェント対話処理部３５０は、エージェント学習部３５３により適宜変化するユーザ用エージェントによるユーザとの自動対話を実現する機能を有する。具体的には、ユーザ用エージェント対話処理部３５０は、クライアント端末１から送信された発話音声またはテキストを解析し、対応する応答文を出力する。

紹介ユーザ選出部３５５は、ユーザ好みに変化したエージェント（ユーザ用エージェント）の属性と同様の属性を持つ実在の人物を検索し、紹介ユーザとしてユーザにマッチングする機能を有する。ユーザ好みに変化したエージェントの属性は、ユーザ用エージェントＤＢ３５４を参照して把握される。具体的には、紹介ユーザ選出部３５５は、婚活会員情報４１から、ユーザ好みに変化したエージェントの属性と同様の属性を持つ実在の人物を検索し、紹介ユーザとして抽出する。また、紹介ユーザ選出部３５５により抽出された紹介ユーザの属性にユーザ用エージェントをより近付けるよう、エージェント学習部３５３に当該紹介ユーザの属性を出力してもよい。

親密度算出部３５６は、紹介ユーザの属性を反映させたユーザ用エージェントとユーザとの親密度を算出する。例えば親密度算出部３５６は、当該ユーザ用エージェントとユーザとの対話内容に応じて親密度を算出する。

紹介処理部３５７は、親密度算出部３５６により算出された親密度が閾値を超えた場合、紹介ユーザ（実在人物）をユーザに紹介するための各種処理を行う。例えば紹介処理部３５７は、紹介ユーザに対して紹介可否を問う承認通知を送信したり、両者のクライアント端末１に紹介画面を表示したりする。

シナリオ管理部３５８は、シナリオＤＢ３５９に登録されているシナリオに従って、ユーザと紹介ユーザの出会いを支援する各種処理を行う。例えばシナリオ管理部３５８は、シナリオＤＢ３５９からユーザが任意に選択したシナリオに従って、日時と場所を両者に通知し、プラン内容を所定の業者へ通知するよう制御する。

以上、本実施形態によるマッチング部３５の構成について説明した。

（４−１−４．クライアント端末１の構成）
続いて、本実施形態によるクライアント端末１の構成について図１８を参照して説明する。図１８は、本実施形態によるクライアント端末１の構成の一例を示すブロック図である。

図１８に示すように、クライアント端末１は、制御部１００、通信部１０１、操作入力部１０２、センサ１０３、カメラ１０４、マイク（マイクロホンの略称）１０５、表示部１０６、スピーカ１０７、および記憶部１０８を有する。

（制御部１００）
制御部１００は、例えばクライアント端末１が有するＣＰＵ（Central Processing Unit）のようなプロセッサによって実現される。本実施形態による制御部１００は、例えば通信部１０１を介してエージェントサーバ２から送信されたエージェントの応答音声をスピーカ１０７から再生するよう制御したり、エージェントの画像を表示部１０６に表示するよう制御したりする。

また、制御部１００は、操作入力部１０２から入力されたユーザによる選択情報（例えばエージェントの選択等）を、通信部１０１を介してエージェントサーバ２へ送信する。

また、制御部１００は、エージェントサーバ２の制御に従って、ユーザが選択したエージェントによる自動対話等のエージェントサービスを提供するよう制御する。

（通信部１０１）
通信部１０１は、例えば、ネットワーク３に接続するための通信デバイスなどで構成された通信インターフェースである。通信部１０１は、例えば、ＬＡＮ（Local Area Network）、Bluetooth（登録商標）、Wi-Fi、またはWUSB（Wireless USB）用の通信カードなどでありうる。また、通信部１０１は、光通信用のルータ、ADSL（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信部１０１は、例えばインターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信部１０１に接続されるネットワーク３は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などを含みうる。

（操作入力部１０２）
操作入力部１０２は、ユーザ操作の入力を受け付け、制御部１００に出力する機能を有する。操作入力部１０２は、例えばマウス、キーボード、タッチパネル、ボタン、スイッチ、またはレバーなどにより実現される。

（センサ１０３）
センサ１０３は、ユーザまたは周辺状況を検知する機能を有する。例えばセンサ１０３は、生体センサ（脈拍計、心拍計、発汗センサ、体温センサ、血圧センサ、脳波計等）、環境センサ（温度センサ、照度センサ、圧力計等）、加速度センサ、ジャイロセンサ、方位センサ、振動センサ、または位置測位センサなどにより実現される。

（カメラ１０４）
カメラ１０４は、撮像レンズ、絞り、ズームレンズ、及びフォーカスレンズ等により構成されるレンズ系、レンズ系に対してフォーカス動作やズーム動作を行わせる駆動系、レンズ系で得られる撮像光を光電変換して撮像信号を生成する固体撮像素子アレイ等を各々有する。固体撮像素子アレイは、例えばＣＣＤ（Ｃｈａｒｇｅ Ｃｏｕｐｌｅｄ Ｄｅｖｉｃｅ）センサアレイや、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）センサアレイにより実現されてもよい。

（マイク１０５）
マイク１０５は、ユーザの音声や周囲の環境音を収音し、音声データとして制御部１００に出力する。

（表示部１０６）
表示部１０６は、文字、図、画像、映像等を表示する機能を有する。表示部１０６は、例えば液晶ディスプレイ（LCD）装置、ＯＬＥＤ（Organic Light Emitting Diode）装置等により実現される。

（スピーカ１０７）
スピーカ１０７は、音声信号を再生する機能を有する。

（記憶部１０８）
記憶部１０８は、制御部１００が各機能を実行するためのプログラムやパラメータを格納する。例えば記憶部１０８は、ユーザID、氏名、年齢、性別、職業、家族構成、家族同居、年収、居住地、嗜好情報等のユーザ情報を記憶していてもよい。

続いて、本実施形態による動作処理について図１９〜図２７を参照して具体的に説明する。

＜４−２．動作処理＞
本実施形態による動作処理は、探索、固定、紹介、支援の大きく４つのフェーズから成る。

・探索フェーズ
図１９は、本実施形態による探索フェーズの動作処理を示すフローチャートである。図１９に示すように、まず、ユーザにより一人のエージェントが選択されると（ステップＳ２７０）、ユーザ用エージェント対話処理部３５０は、選択されたエージェントによるユーザとの対話を開始する（ステップＳ２７３）。

次に、エージェント学習部３５３は、ユーザ用エージェント対話処理部３５０によるエージェントとユーザの対話を学習し、エージェントの嗜好や性格の属性をユーザの好みに近付くよう変更する（ステップＳ２７６）。

次いで、紹介ユーザ選出部３５５は、ユーザの好みに寄せたエージェントと各実在人物（紹介対象となる相手）の属性とをマッチングし、紹介ユーザの選出を行う（ステップＳ２７９）。このように、探索フェーズでは、エージェントの属性を変化させ、ユーザに知られることなく裏でエージェントと実在の人物とのマッチングが行われる。

同一人物が選出された回数が所定回数を超えるまで上記処理が繰り返される（ステップＳ２８２）。

そして、同一人物が選出された回数が所定回数を超えた場合（ステップＳ２８２／Ｙｅｓ）、図２０で説明する固定フェーズの処理が開始される。なお、ここでは同一人物の選出回数を基準としたが、本実施形態はこれに限定されず、一定期間同一人物が選出され続けた場合を固定フェーズを開始する基準としてもよい。

・固定フェーズ
図２０は、本実施形態による固定フェーズの動作処理を示すフローチャートである。固定フェーズでは、マッチングした人物（選出した紹介人物、以下「実在人物」とも称す）を固定し、本当に当該人物とユーザの相性（ここでは「親密度」により判断される）が良いかを確認するためのフェーズである。したがって、ここでは、実在人物の属性が変化した場合には対応するエージェントの属性が実在の人物に合わせて変化される。

具体的には、図２０に示すように、まず、ユーザ用エージェント対話処理部３５０は、実在人物をマッチングしたユーザ用エージェントとユーザの対話を継続する（ステップＳ３０３）。

次に、エージェント学習部３５３は、ユーザ情報ＤＢ３５２に保存される実在人物の情報を継続的に確認し、マッチングした実在人物の属性が変化した場合はこれをユーザ用エージェントの属性に反映する（ステップＳ３０６）。具体的には、ユーザ用エージェントＤＢ３５４に格納されるエージェントの属性が実在人物の属性に近付くよう更新される。

次いで、親密度算出部３５６は、エージェントとユーザの親密度を算出する（ステップＳ３０９）。上述したように、固定フェーズでは、エージェントの属性をマッチングした実在人物に寄せていくため、対話を進めるうちに、ユーザとエージェントの性格や嗜好がずれていく可能性がある。したがって、実在人物に似たエージェントとユーザとの親密度を算出し、マッチングした実在人物が本当にユーザに適切か否かを判断する。親密度の算出は、例えばエージェントの属性項目とユーザの属性項目の一致度合いや、ユーザとの会話量、会話時のユーザの笑顔量等に基づいて算出され得る。また、親密度は、ユーザの対話における言葉遣いや単語のポジティブ／ネガティブ等から算出されてもよい。

続いて、親密度が所定の閾値を超えた場合（ステップＳ３１２／Ｙｅｓ）、紹介処理部３５７は、紹介承認可否を当該マッチングした実在人物へ通知する（ステップＳ３１５）。

そして、実在人物により紹介承認が認められた場合（ステップＳ３１８／Ｙｅｓ）、図２１で説明する紹介フェーズの処理が開始される。

一方、実在人物により紹介承認が認められなかった（紹介を拒否された）場合（ステップＳ３１８／Ｎｏ）、図１９に示す探索フェーズに戻る。なお探索フェーズのステップＳ２７９のマッチング処理では、既に紹介承認を拒否した人物を除外する。

・紹介フェーズ
図２１は、本実施形態による紹介フェーズの動作処理を示すフローチャートである。紹介フェーズでは、ユーザ側に紹介できる実在の人物がいることが初めて通知される。

図２１に示すように、まず、紹介処理部３５７は、ユーザに紹介可能な実在人物がいることをユーザに通知する（ステップＳ３２３）。

次に、紹介処理部３５７は、ユーザのクライアント端末１の表示部１０６に、紹介する実在人物のプロフィールを（相手が公開している範囲で）表示し（ステップＳ３２６）、さらに、かかる実在人物（以下、「紹介相手」とも称す）に実際に会いたいか会いたくないかを選択する「会いたい／会いたくないボタン」を表示する（ステップＳ３２９）。これにより、ユーザは紹介相手のプロフィールを確認することができる。

次いで、エージェントを通したユーザと実在人物の音声またはテキストによる対話が続けられる（ステップＳ３３２）。ここでは、エージェントを通した会話であるため、例えばエージェントの音声で紹介相手の発話が再生されたり、エージェントの顔画像が表示された状態でチャットが行われる。ユーザは、エージェントを通した紹介相手との対話を続けた上で、実際に紹介相手に会いたいか会いたくないかを判断し、「会いたい／会いたくないボタン」をタップする。かかるボタンは、相手側の画面にも表示され得る。

次に、ユーザと紹介相手の双方が双方が会う意思を表明した（「会いたいボタン」を選択した）場合（ステップＳ３３５／Ｙｅｓ）、図２２に示す支援フェーズが開始される。

一方、片方が会う意思が無いことを表明した（「会いたくないボタン」を選択した）場合（ステップＳ３３８／Ｙｅｓ）、当該実在人物とのマッチングは解除され、図１９に示す探索フェーズに戻る。この際、ユーザはエージェントを再選択するか否かを選択できる（ステップＳ３４１）。本実施形態では、複数のエージェントが用意され、各エージェントはそれぞれ異なる人格、すなわち初期値の属性が異なるため、違うタイプのエージェントから改めて始めたい場合、ユーザはエージェントを再選択する。一方、エージェントを再選択しない場合、ユーザとの対話に応じて、現在のエージェントの属性が再度ユーザ好みの属性に変化していく。また、探索フェーズでは、一度マッチングして解消された人物とは一定期間マッチングしないようにする。

・支援フェーズ
図２２は、本実施形態による支援フェーズの動作処理を示すフローチャートである。紹介フェーズにおいて実在人物との繋がりは達成しているため、支援フェーズは必ずしも実行する必要はないが、ユーザの要求に応じて実施され得る。ここでは、二人が出会う時のシチュエーションや演出を「シナリオ」という形で選択することが可能である。

図２２に示すように、まず、シナリオＤＢ３５９に格納されている複数の出会いプラン（シナリオ）からユーザにより出会いプランが選択される（ステップＳ３５３）。なおシナリオ管理部３５８が、これまでのユーザと紹介相手との対話内容から自動的に出会いプランを推薦してもよい。出会いプランには、場所（レストラン、公園、遊園地、水族館等）、内容（サプライズ演出、プレゼント付き、優待、割引）、日時（平日／休日、朝／昼／夕）、費用等が含まれる。具体的には、例えば出会いプランには「落ち着いたレストランで彼女にサプライズプレゼントが…」といった内容が設定されている。出会いプランは、内容によってはユーザ側でしか閲覧できない。

次いで、シナリオ管理部３５８は、発動した出会いプランに従って、ユーザと実在人物に出会いの日時および場所を通知する（ステップＳ３５６）。

次に、シナリオ管理部３５８は、互いの予定が合ってＯＫされたか否かを確認する（ステップＳ３５９）。なお出会いプランを選択する際に予定が空いている日時をユーザに指定させるようにしてもよい。

次いで、双方ＯＫした場合（ステップＳ３５９／Ｙｅｓ）、当該出会いプランを実行する演出業者に通知する（ステップＳ３６２）。演出業者は、例えばレストランや遊園地などの施設でもよい。出会いプランにより二人に利用してもらえるため、施設側としては広告になるというメリットがある。

そして、二人が当日出会ったことが確認されると（ステップＳ３６５／Ｙｅｓ）、業者による演出が実行される（ステップＳ３６８）。例えば、紹介相手のための特別メニューが用意されていたり、景色の良い場所では最高の眺めの席が用意されている等である。また、演出内容によっては周囲に演者が配置され、次のデートに繋がるような観光地の話題や、結婚がどれだけ素晴らしいかといった話をユーザ達に聞こえるように話してもよい。

＜４−３．実施例＞
続いて、本実施形態について実施例を用いて詳細に説明する。ここでは、結婚相談所（管理サーバ４）と連携した例について説明する。本実施例では、システムを利用しているユーザを仮に成人男性のユーザとし、結婚相談所の会員情報に基づいて紹介相手の女性をマッチングする。また、本実施例では、上述した４つのフェーズの前に、準備を行うための準備フェーズについて説明する。

（４−３−１．準備フェーズ）
ユーザは、本システムを利用する準備としてプロフィール（ユーザ情報）を入力する。以下、図２３を参照して具体的に説明する。

図２３に示すように、まず、ユーザは、クライアント端末１からユーザ基本情報を入力する（ステップＳ３９３）。クライアント端末１で入力された情報は、エージェントサーバ２へ送信され、ユーザ／エージェント情報管理部３５１によりユーザ情報ＤＢ３５２に格納される。図２４Ａに、ユーザ基本情報の一例を示す。図２４Ａに示すように、例えばユーザ基本情報は、年齢、職業、家族構成、家族同居、年収、居住地、血液型の情報を含む。また、ユーザ基本情報の各項目は、他の人物に閲覧されてもよいかどうかの公開属性を持つ。

次に、ユーザは、クライアント端末１からユーザ基本条件情報を入力する（ステップＳ３９６）。ユーザ基本条件情報は、理想の紹介相手の属性に関する情報である。図２４Ｂに、ユーザ基本条件情報の一例を示す。図２４Ｂに示すように、例えばユーザ基本条件情報は、年齢、職業、家族構成、家族同居、年収、居住地、血液型の情報を含む。また、ユーザは、各項目に優先度を設定することが可能であって、優先度の高い項目を重視して最初のエージェントを選択することが可能となる。なおユーザ基本条件情報の項目は図２４Ｂに示す例に限定されず、例えば容姿、性格、話し方、声のトーン等の項目を含むことも可能である。

次いで、ユーザは、クライアント端末１からユーザ嗜好情報を入力する（ステップＳ３９９）。ユーザ嗜好情報は、ユーザの嗜好に関する情報である。図２５に、ユーザ嗜好情報の一例を示す。ユーザ嗜好情報は、例えば各項目を-1.0（嫌い）〜1.0（好き）の範囲で設定される。また、数値入力に限定されず、ユーザ嗜好情報の入力の際に「大好き、好き、どちらでもない、嫌い、大嫌い」等を項目毎にアンケート形式で入力できるようにしてもよい。

続いて、ユーザ／エージェント情報管理部３５１は、ユーザの性格診断を行う（ステップＳ４０２）。ユーザの性格診断は、例えばアンケート形式でユーザに提示した設問の答えに基づいて何パターンかの性格に分類したり、性格の要素となる複数の軸について軸ごとの点数を算出してレーダーチャートや折れ線グラフで診断する方法が挙げられる。エゴグラムテストとして知られる性格診断の場合には、例えば「断ることが苦手ですか？」や「時間を守ることに厳しいですか？」などの質問をユーザに与えることで、最終的に５軸の要素（CP（Controlling Parent）、NP（Nurturing Parent）、A（Adult ego state）、FC（Free Child）、AC（adapted child）と称される）毎に得点を集計し、最終的にエゴグラムという折れ線グラフで性格診断結果を表現することができる。ユーザに提示する際は折れ線グラフやレーダーチャートを用いて表現するが、ユーザ情報ＤＢ３５２内では各要素の得点をユーザ性格情報として保存し、各ユーザの要素の得点を比較することで、性格の類似度やユーザ好みの性格かどうかが判断され得る。

次に、ユーザ／エージェント情報管理部３５１は、ユーザの理想人物の性格診断を行う（ステップＳ４０５）。ユーザの理想人物の性格は、例えばユーザがエゴグラムテストを理想の相手になりきって入力することで設定することが可能である。ユーザの理想人物の性格診断結果も同様に、各要素の得点が理想性格情報としてユーザ情報ＤＢ３５２に格納される。

以上説明した基本情報、基本条件情報、嗜好情報、性格情報、理想性格情報は、エージェントも同様に有し、エージェント情報ＤＢ３６０に格納される。エージェントの基本情報の一例を図２６Ａに示し、基本条件情報の一例を図２６Ｂに示し、嗜好情報の一例を図２７に示す。基本情報、基本条件情報、嗜好情報、性格情報、および理想性格情報は、エージェントの性格を定義するための初期値として設定され得る。

以上、準備フェーズについて具体的に説明した。準備フェーズで用意した基本情報、基本条件情報、嗜好情報、性格情報、および理想性格情報は、管理サーバ４で管理される結婚相談所側の実在の人物（婚活会員）においても同様の値が婚活会員情報４１に格納されている。

（４−３−２．探索フェーズ）
続いて、探索フェーズの実施例について図２８〜図３８を参照して具体的に説明する。

基本情報等の入力を行う準備フェーズが終了すると、次にエージェントを選択する画面に誘導される。図２８は、本実施例によるエージェント選択画面の一例を示す図である。図示された画面２００には、エージェントの画像（手書きの絵、ＣＧ、写真等）、エージェントの基本プロフィール、エージェントの性格や嗜好が表示される。エージェントの性格は、図２８に示すように性格チャートで表示されてもよいし、上述したエゴグラムによる折れ線グラフで表示されてもよい。また、エージェントの選択候補は、ユーザの嗜好を反映して生成したものであってもよい。また、エージェントの選択候補は、エージェント情報ＤＢ３６０にプロフィール設定されているエージェントのうち、ユーザの嗜好とマッチングして選出したものや、ユーザの嗜好とは無関係に例えば人気順や評価順などの指標に基づいて選出したものであってもよい。

以下、図２９Ａ、図２９Ｂを参照して具体的な動作処理について説明する。

図２９Ａ、図２９Ｂは、本実施例による探索フェーズの動作処理を示すフローチャートである。図２９Ａに示すように、まず、ユーザによりエージェントの選択が行われる（ステップＳ４１３〜ステップＳ４３７）。エージェントの選択方法は例えば３つ用意する。ユーザは好きな選択方法でエージェントを選択することが可能である。

第１の選択方法では（ステップＳ４１３／Ｙｅｓ）、エージェント情報ＤＢ３６０に登録されている複数の女性エージェントの画像が表示され、ユーザは容姿的に好みの女性エージェントを選択する（ステップＳ４１６）。

次いで、エージェント学習部３５３は、準備フェーズで入力されたユーザの理想の基本条件と理想の性格をユーザ情報ＤＢ３５２から抽出し、選択された女性エージェントにそのままセット（ユーザ用エージェントＤＢ３５４に登録）する（ステップＳ４１９、ステップＳ４２２）。

第２の選択方法では（ステップＳ４２５／Ｙｅｓ）、エージェント学習部３５３は、準備フェーズで入力されたユーザの基本条件情報、および理想の性格情報に基づいて、エージェント情報ＤＢ３６０から近い属性を持つ女性エージェントを検索し（ステップＳ４２８、ステップＳ４３１）、検索結果をユーザに提示してエージェント選択を受け付ける（ステップＳ４３４）。エージェント検索の際、さらにユーザの嗜好情報を考慮し、ユーザと似た嗜好情報を持つ女性エージェントを検索するようにしてもよい。また、基本条件情報の各項目のうち、優先度の高い項目を優先して最も多くの属性が一致する女性エージェントに候補に絞ってもよい。

第３の選択方法では（ステップＳ４２５／Ｎｏ）、エージェントの容姿やプロフィールを確認しながら、全てのエージェントからユーザが任意に選択する（ステップＳ４３７）。

次いで、図２９Ｂに示すように、ユーザ用エージェント対話処理部３５０は、ユーザの行動履歴や、生体情報を取得する（ステップＳ４４０、ステップＳ４４３）。ユーザの行動履歴とは、活動した場所の履歴、活動内容履歴、購買履歴、ＳＮＳの投稿履歴等であって、クライアント端末１や所定のサーバから取得される。ユーザの行動は、位置情報、インターネット履歴、加速度センサデータやジャイロセンサデータ等に基づく行動認識等により詳細に把握され得る。また、ユーザの生体情報はクライアント端末１からリアルタイムに取得され、現在のユーザの状態（緊張している、眠そうにしている、笑っている等）が把握される。

次に、ユーザ用エージェント対話処理部３５０は、エージェントによるユーザとの対話処理を行う（ステップＳ４４６）。この際、ユーザ用エージェント対話処理部３５０は、取得したユーザ行動履歴や生体情報を参考にした応答文を生成し、エージェントの発話として出力してもよい。図３０〜図３２に、ユーザ行動履歴や生体情報を利用したエージェントによる対話の一例を示す。ここでは、表示部１０６のチャット画面を介してエージェントとユーザの対話が行われている。

図３０は、本実施例によるユーザ行動履歴を利用したエージェントの発話例を説明する図である。図示された画面２０２には、ユーザＭとエージェント「サキ」の対話がチャット形式で表示されている。画面２０２の下方には、テキスト入力欄と送信ボタンが表示され、ユーザがテキスト入力欄にメッセージを入力し、送信ボタンをタップすることで入力されたメッセージがエージェントサーバ２に発話テキストとして送信される。

ユーザ用エージェント対話処理部３５０は、エージェント「サキ」の応答を、例えば予め設定された質問文と応答文のデータセットに基づいて生成する。具体的には、例えば「○○に釘付けになりました」「○○に夢中で」「○○に目が無いんですよ」といった質問文に対しては『○○がお好きなんですか？』と応答する。また、ユーザ用エージェント対話処理部３５０は、例えばユーザＭが今日Ｙ駅で降りたという行動履歴を参照して、図３０に示すように、『Ｍさんが今日降りたＹ駅の周りには、ラーメン屋さんが多いですよね！』という発話を出力することも可能である。これにより、ユーザＭは、エージェントに対して親近感が湧いたり、自分だけのパートナーという意識が芽生えることが期待できる。

図３１は、本実施例によるユーザの生体情報を利用したエージェントの発話例を説明する図である。生体情報は、ユーザが装着するウェアラブルデバイスに設けられた生体センサや、ユーザの顔画像を撮像するカメラから得られ、クライアント端末１からリアルタイムにエージェントサーバ２へ送信される。ユーザ用エージェント対話処理部３５０は、生体情報に基づいてユーザの状態（心理状態、感情）を推測し、推測結果を反映した発話をエージェントの発言として生成する。例えばユーザＭの心拍数が通常より速くなっていた場合、図３１の画面２０３に表示されているように、『あれ？なんかいつもと違うような？』『なんかこちらもドキドキしてきました』といった、相手の心理状態に同調する発話が出力される。これにより、ユーザＭは、エージェントとの心理的な距離が近くなり、より親しく感じることが期待できる。

図３２は、本実施例によるＳＮＳ情報を利用したエージェントの発話例を説明する図である。ユーザ用エージェント対話処理部３５０は、ユーザの嗜好情報に合致する話題をＳＮＳやＷｅｂサイトから検索し、エージェントの発話に利用する。例えば図３２の画面２０４に表示されているように、『私はよく分からないけど、さっきＡＡチームのドラフトの話題でＳＮＳが盛り上がってたみたいですよ』といった発話が出力される。このようにユーザＭの嗜好に合った話題を提供することで話が盛り上がり、ユーザＭはエージェントとの会話をより楽しいと感じることが期待できる。

以上説明したユーザ用エージェント対話処理部３５０による対話処理の詳細を、図３３Ａ、図３３Ｂに示す。

図３３Ａ、図３３Ｂは、本実施例によるエージェント対話処理のフローチャートである。図３３Ａに示すように、まず、ユーザ用エージェント対話処理部３５０は、前回のユーザとの会話から一定時間経過していた場合（ステップＳ４７３／Ｙｅｓ）、挨拶を行う（ステップＳ４７６）。

次に、紹介ユーザが選出されない状態が所定期間続いている場合（ステップＳ４７９／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、ユーザに対する性格改善（若しくは理想の改善）メッセージを生成し、発話する（ステップＳ４８２）。紹介ユーザの選出については、追って詳述する。

次いで、ユーザからの新規入力（発話）があった場合（ステップＳ４８５／Ｙｅｓ）、エージェントサーバ２は、発話音声に対して音声認識を行い（ステップＳ４８８）、発話テキストに対してテキスト解析を行う（ステップＳ４９１）。

次に、エージェントサーバ２のユーザ用エージェント対話処理部３５０は、ユーザの属性（基本情報、基本条件情報、および嗜好情報の各項目）に応じた発話候補を生成する（ステップＳ４９４）。

次いで、ユーザの行動履歴が利用できる場合（ステップＳ４９７／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、行動履歴に応じて発話候補を改変する（ステップＳ４９８）。

また、ユーザの生体情報が利用できる場合（ステップＳ５００／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、生体情報に応じて発話候補を改変する（ステップＳ５０３）。なお、ユーザ用エージェント対話処理部３５０は、行動履歴と生体情報の両方を用いて発話候補を改変してもよい。

次いで、発話候補がある場合（ステップＳ５０６／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、エージェントの発言として当該発話候補を出力する（ステップＳ５０９）。なお発話候補が無かった場合（ステップＳ５０６／Ｎｏ）、エージェントの発言は行われない。

以上説明したエージェント対話は、ユーザからの新規入力（発話）があった場合の返答について説明したが、本実施例による対話はこれに限定されず、エージェント側から発言を行ってもよい。

具体的には、上記ステップＳ４８５において、ユーザからの新規入力（発話）が無い場合（ステップＳ４８５／Ｙｅｓ）、図３３Ｂに示すように、ユーザ用エージェント対話処理部３５０は、ユーザの行動履歴にトピックがあるか否かを判断する（ステップＳ５１２）。例えば、ユーザ用エージェント対話処理部３５０は、観光スポットに出掛けた、いつもと違う駅で降りた、高価な買い物をした等の注目すべき行動があったか否かを行動履歴から判断する。

次に、トピックがあった場合（ステップＳ５１２／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、行動履歴を用いて発話候補を生成する（ステップＳ５１５）。

次いで、ユーザの生体情報にトピックがあるか否かを判断する（ステップＳ５１８）。例えば、ユーザ用エージェント対話処理部３５０は、笑顔、楽しい、眠い、疲れている、興奮している、怒っている、といった普段と異なる注目すべき状態や感情を生体情報に基づいて判断する。

次に、トピックがあった場合（ステップＳ５１８／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、生体情報を用いて発話候補を生成する（ステップＳ５２１）。

次いで、直近のＳＮＳやＷｅｂサイト等からユーザが好む話題を検索し、ユーザが好む話題が有った場合（ステップＳ５２４／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、当該ＳＮＳ等の話題を用いて発話候補を生成する（ステップＳ５２７）。

なお、図３３Ｂでは、行動履歴、生体情報、およびＳＮＳ情報等のうちいずれか一つを利用して発話候補を生成するフローを示したが、本実施例はこれに限定されず、行動履歴、生体情報、およびＳＮＳ情報等のうちいずれか１以上の情報を組み合わせて発話候補を生成することも可能である。

次に、図２９Ｂに戻り、エージェント学習部３５３は、エージェントとユーザの対話に応じて、エージェントの学習を適宜行う（ステップＳ４４９）。具体的には、エージェント学習部３５３は、エージェントの属性がユーザ好みになるよう更新する。以下、図３４〜図３５を参照して具体的に説明する。

図３４は、本実施例によるエージェント学習の動作処理を示すフローチャートである。図３４に示すように、まず、エージェント学習部３５３は、ユーザの入力文（発話テキスト）をテキスト解析する（ステップＳ５３０）。

次いで、エージェント学習部３５３は、目的語（嗜好対象となる事象）に対してのユーザのポジティブ／ネガティブ判定を行う（ステップＳ５３３）。

次に、エージェント学習部３５３は、上記目的語がエージェントの嗜好情報に含まれている項目であるか否かを確認し（ステップＳ５３６）、含まれていない場合はエージェントの嗜好情報に当該目的語の項目を追加する（ステップＳ５３９）。

次いで、エージェント学習部３５３は、エージェントの嗜好情報の対応する項目の嗜好度（嗜好の数値）を調整する（ステップＳ５４１）。すなわち、エージェント学習部３５３は、対話内容に基づいて、ある事象に対するユーザのポジティブ／ネガティブを判別し、判別結果をエージェントの嗜好情報に反映させることで、エージェントの嗜好をユーザの嗜好に近付けることができる。なお、エージェントの嗜好情報のみならず、エージェントの基本情報や基本条件情報にも、ユーザの好みを反映させてもよい。

この際、エージェント学習部３５３は、エージェントの嗜好や性格が急激に変化すると不自然になるため、数値の更新は一定の範囲内の加減に留めるようにしてもよい。例えば、図３５に示すように、ユーザが「今日テレビでラーメンランキングに釘付けになってしまいまして、とんこつラーメンを食べたくなってしまいました。太るっすかね？あっさり系の醤油ラーメンは興味なかったのですが。」と入力した場合、テキスト解析により、目的語（嗜好対象単語）として「テレビ」「ラーメンランキング」「とんこつラーメン」「醤油ラーメン」が抽出される。エージェント学習部３５３は、当該目的語に対するユーザの心証を示す各対応語に応じて、図３５の右上の表に示すように、各目的語に対するポジティブ／ネガティブ判定を行う。図３５に示す例では、ユーザが「ラーメン」にポジティブな感情を持っていることが判明するため、エージェントの嗜好情報に「ラーメン」を加え、嗜好度（嗜好の数値）を高くしてユーザの嗜好に寄せていく。この際、嗜好の強さを表す言葉（「とても」、「少し」など）に応じて加算する点数を変えてもよいし、１回の発言で例えば0.1ずつ変化するようにしていってもよい。また、エージェント学習部３５３は、1.0が最大、-1.0が最小になるよう嗜好度を正規化して設定してもよい。

次に、エージェント学習部３５３は、ユーザの言葉使いカテゴリの判定を行う（ステップＳ５４４）。ここでは、ユーザの言葉使いに合わせてエージェントの言葉使いも変化させることで、ユーザと雰囲気が合うエージェントにすることができる。言葉使いカテゴリは、例えば丁寧、ぶっきらぼう（無愛想）、優しい、乱暴、早口、ゆっくり等に分けられる。

次いで、エージェント学習部３５３は、エージェントの言葉使いカテゴリパラメータを調整する（ステップＳ５４７）。エージェントの言葉使いカテゴリパラメータは、ユーザ用エージェントＤＢ３５４に格納され得る。言葉使いのカテゴリ判定は、一定期間におけるユーザの対話から収集した言葉使いカテゴリのうち一番多いカテゴリをユーザを代表する言葉使いカテゴリとしてもよい。例えば図３５に示す例では、図３５の右下に示すように、「丁寧」のカテゴリが３回、「ぶっきらぼう」のカテゴリが１回抽出されているので、、ユーザを代表する言葉使いカテゴは「丁寧」と判定してもよい。または、エージェント学習部３５３は、ユーザの対話から抽出される各言葉使いカテゴリの出現確率を判定結果としてもよい。そして、エージェント学習部３５３は、ユーザを代表する言葉使いカテゴリ、または各言葉使いカテゴリの出現確率を、エージェントの言葉使いカテゴリパラメータに反映させる。

次に、エージェント学習部３５３は、上述した嗜好情報や言葉使いパラメータの変更がエージェントの性格に影響するか否かを確認し（ステップＳ５５０）、影響する場合はエージェントの性格情報のパラメータを調整する（ステップＳ５５３）。嗜好や言葉使いには性格が表れるため、変更された嗜好や言葉使いに応じた性格パラメータに調整される。

以上説明したように、エージェントはユーザと対話を行っているうちに徐々にユーザ好みのエージェントに成長する。

続いて、図２９Ｂに戻り、紹介ユーザ選出部３５５は、次に説明するマッチングの更新間隔が閾値を超えたか否かを判断する（ステップＳ４５２）。マッチングの更新間隔は、例えば１日、１週間等、適宜設定される。

次に、紹介ユーザ選出部３５５は、実在人物とエージェントとのマッチングを行う（ステップＳ４５５）。本実施例では、エージェントとユーザの対話が進む裏で、定期的に実在の人物とエージェントとのマッチングが行われる。具体的には、例えば紹介ユーザ選出部３５５は、婚活会員情報４１を参照してエージェントと似ている実在人物を検索する。上述したように、ユーザ用エージェントはユーザ好みに変化しているため、当該エージェントと似ている実在人物をマッチングすることで、ユーザと相性のよい相手をより効果的に検索することができる。以下、図３６〜図３８を参照して具体的に説明する。

図３６は、本実施例によるマッチングの動作処理を示すフローチャートである。図３６に示すように、まず、紹介ユーザ選出部３５５は、エージェントの基本条件情報と全て一致する人物を婚活会員情報から検索する（ステップＳ５６３）。図３７は、エージェントの基本条件情報を用いた検索について説明する図である。図３７に示すように、基本条件の項目が条件を満たしているか否かに基づいて婚活会員情報がスクリーニングされる。例えば紹介ユーザ選出部３５５は、基本条件情報を管理サーバ４に送り、婚活会員情報４１から条件を満たす１以上の会員ＩＤを取得する。

次いで、検索された候補数（婚活会員の数）が閾値（一定数）を超えているか否かを判断する（ステップＳ５６６）。これにより、例えば最低でも１０人など、マッチング相手を選ぶ候補人数を確保することができる。

次に、候補数が閾値を超えていない場合（ステップＳ５６６／Ｎｏ）、紹介ユーザ選出部３５５は、基本条件情報の優先度「高・中」の項目を満たす候補を検索する（ステップＳ５６９）。

次いで、候補数がまだ閾値を超えていない場合（ステップＳ５７２／Ｎｏ）、紹介ユーザ選出部３５５は、さらに基本条件情報の優先度「高」の項目を満たす候補を検索する（ステップＳ５７５）。

次に、候補数が閾値を超えている場合（ステップＳ５７８／Ｙｅｓ）、紹介ユーザ選出部３５５は、エージェントと各候補の性格診断結果の相関を求める（ステップＳ５８１）。ここでは、準備フェーズで説明した性格診断を各婚活会員も事前に行っているものとする。例えば紹介ユーザ選出部３５５は、エージェントと各候補のエゴグラムの各値における差分の自乗値を合算し、相互相関を求める。

次いで、紹介ユーザ選出部３５５は、相関値が所定の閾値より低い候補を除外する（ステップＳ５８４）。

次に、紹介ユーザ選出部３５５は、残った候補とエージェントの嗜好の類似度を算出し（ステップＳ５８７）、類似度の最も高い候補（人物Ｐ）を選出する（ステップＳ５９０）。嗜好の類似度の算出は、嗜好情報を用いて行われる。

具体的には、紹介ユーザ選出部３５５は、例えばエージェントとある候補の嗜好情報の各項目のうち一致する項目の数値を並べたn次元のベクトルをそれぞれ生成し、エージェントのn次元ベクトルと候補者のn次元ベクトルのcosθ内積を求める。数値が1.0であれば類似度は完全一致、0.0であれば完全不一致となる。

ただし、nが所定の閾値より小さい場合は当該候補者について類似度算出は行わずに候補から除外する。少ない項目で一致しても信頼性が低いためである。

例えば図３８に示す例では、エージェントの嗜好情報と、候補者である婚活会員の嗜好情報のうち、「ＡＡチーム」「ＦＦ食堂」「Ｄ町」「寿司」「ＥＥファッション」といった５つの項目が一致する。従って、紹介ユーザ選出部３５５は、これら５つの項目の数値を並べた5次元ベクトルをそれぞれ生成する。

一方、候補数が閾値を超えていない場合（ステップＳ５７８／Ｎｏ）、候補が少ないため、マッチングを解除し、図２９Ｂに示すステップＳ４４０に戻る。

以上、本実施形態によるエージェントと実在人物のマッチング（紹介ユーザ（人物Ｐ）の選出）について説明した。

次いで、図２９Ｂに戻り、紹介ユーザ選出部３５５は、選出した人物Ｐが前回選出した人物と同じか否かを確認する（ステップＳ４６１）。上述したように、実在人物のマッチングは、エージェントとユーザの対話が行われる一方で定期的に（例えば１日１回等）行われ得る。

次に、選出した人物Ｐが前回選出した人物と同じ場合（ステップＳ４６１／Ｙｅｓ）、紹介ユーザ選出部３５５は、同一人物カウントCsをインクリメントする（ステップＳ４６４）。

一方、選出した人物Ｐが前回選出した人物と異なる場合（ステップＳ４６１／Ｎｏ）、紹介ユーザ選出部３５５は、同一人物カウントCsをリセットする（ステップＳ４７０）。

次いで、紹介ユーザ選出部３５５は、同一人物カウントCsが閾値を超えるまで実在人物とのマッチングを定期的に行う（ステップＳ４６７）。同一人物カウントCsが閾値を超えた場合（ステップＳ４６７／Ｙｅｓ）、図３９に示す固定フェーズが開始される。

（４−３−３．固定フェーズ）
次に、固定フェーズの実施例について図３９〜図４１を参照して具体的に説明する。固定フェーズでは、ユーザとエージェントが探索フェーズの際と同様に対話を続けながら一方でエージェントの嗜好や性格の属性が探索フェーズでマッチングされた実在人物に徐々に近付けられ、ユーザが気付かないうちに実在人物との相性（親密度）が判断される。

図３９は、本実施例による固定フェーズの動作処理を示す図である。図３９に示すように、まず、承認待ちフラグがFalseにセットされる（ステップＳ６０３）。

次に、親密度算出部３５６は、親密度を0にセットする（ステップＳ６０６）。

次いで、ユーザ用エージェント対話処理部３５０により、上記ステップＳ４４０〜Ｓ４４６と同様に、ユーザの行動履歴や生体情報を利用したユーザとの対話処理が引き続き行われる（ステップＳ６０９〜ステップＳ６１５）。

次に、エージェント学習部３５３は、選出した人物Ｐの嗜好や基本情報、性格情報の属性に変化が起きたか否かを確認し（ステップＳ６１８）、変化が起きた場合には、エージェントの嗜好情報や基本情報、性格情報等の属性に反映させる（ステップＳ６２１）。この際、変化した値をそのままコピーしてもよいが、エージェントの嗜好が急激に変化するとユーザが不自然さを感じる場合もあるため、一度に変化させる量を限定してもよい。一定の時間をかけてエージェントの嗜好を人物Ｐの嗜好に一致させる。

ここで、図４０に、エージェントの嗜好が変化した場合における対話例を示す。図４０に示すエージェント「サキ」は、ユーザＭと対話していた探索フェーズの時点ではそれ程ＡＡチームのことが好きではない属性であったとする（探索フェーズではユーザの嗜好に徐々にエージェントを合わせていくため時間が経てばＡＡチームファンになっていたはずではある）。しかしながら、それ以外の嗜好や性格がマッチして実在人物が選出され、固定フェーズに移行した場合、今度はエージェント「サキ」の嗜好は当該実在人物の嗜好に近付いて行く。そして、当該実在人物が偶然にもＡＡチームファンだった場合、エージェント「サキ」の嗜好がＡＡチーム好きに調整され、例えば図４０の画面２０６に示すように、『私もＡＡチームが好きになってきちゃった。昨日の試合すごかったね！』というような、ＡＡチームの話題に対して以前よりもポジティブな発言が出力される。

次いで、承認待ちフラグがtrueになっていない場合（ステップＳ６２４／Ｙｅｓ）、親密度算出部３５６は、ユーザとエージェントとの親密度を算出する（ステップＳ６３６）。親密度の算出方法は、基本条件情報や嗜好情報等を用いて紹介ユーザ選出部３５５で行ったエージェントと実在人物とのマッチング方法と同様であってもよい。すなわち、基本条件情報や嗜好情報等の項目の一致度合いを親密度として算出する。また、さらにユーザとエージェントの会話量や会話時の笑顔量に基づく数値を親密度に加算してもよい。

次に、親密度が閾値を超えた場合（ステップＳ６３９／Ｙｅｓ）、紹介処理部３５７は、選出した人物Ｐ（エージェントにマッチングした婚活会員）に紹介承認可否を通知し（ステップＳ６４２）、承認待ちフラグをtrueにして承認待ち状態とする（ステップＳ６４５）。ここで、図４１に、紹介承認可否の通知画面の一例を示す。図示された例では、画面２０７に、ユーザＭのプロフィールが（公開している範囲で）表示され、さらに承認ボタン２０７ａと却下ボタン２０７ｂが表示される。紹介承認可否通知を受けた人物Ｐは、ユーザＭのプロフィールを確認し、自分を相手に紹介することを承認する場合は承認ボタン２０７ａをタップし、承認しない場合は却下ボタン２０７ｂをタップする。

次いで、承認応答があるまでユーザＭ側は承認待ち状態となり（ステップＳ６４８）、エージェントとの対話やエージェントの学習が継続される（ステップＳ６０９〜Ｓ６２４）。

次に、人物Ｐから一定期間応答がなくタイムアウトした場合（ステップＳ６２７／Ｙｅｓ）、紹介処理部３５７は、承認待ちフラグをfalseにして（ステップＳ６３０）、また、親密度算出部３５６は親密度を0にする（ステップＳ６３３）。この場合、人物Ｐとのマッチングは解除され、探索フェーズに戻る。

また、人物Ｐからの承認が認められなかった場合（ステップＳ６５１／Ｎｏ）も、親密度を0にリセットされ（ステップＳ６３３）、人物Ｐとのマッチングが解除され、探索フェーズに戻る。

一方、人物Ｐからの承認が認められた場合（ステップＳ６５１／Ｙｅｓ）、図４２に示す紹介フェーズが開始される。

（４−３−４．紹介フェーズ）
次に、本実施例の紹介フェーズについて図４２〜図４４を参照して説明する。紹介フェーズでは、実在の人物が承認を行ったことをトリガとして、ユーザ側に紹介できる人物がいる旨が通知される。ユーザはこの時点から実在の人物の存在を知り、プロフィールを見ることができるようになる。なおユーザ側に提示される実在人物のプロフィールは、基本情報の公開属性が「はい」になっているものだけである。

図４２は、本実施例による紹介フェーズの動作処理を示すフローチャートである。図４１に示すように、まず、紹介ユーザ選出部３５５は、紹介可能な人物が居ることをユーザに通知する（ステップＳ６６３）。図４３に、紹介通知の一例を示す。図示された例では、画面２０８に、エージェント「サキ」とユーザＭのチャットが表示されている。エージェント「サキ」に紐付けられた人物Ｐから紹介承認が許可された場合、紹介ユーザ選出部３５５は、『突然ですが運営からユーザさんにお知らせです！サキさんに似た女性が見つかりました。画面下のハートボタンから連絡をとってみませんか？』といったメッセージを割り込ませる。メッセージは割込みお知らせのため、エージェント「サキ」との対話はそのまま継続される。ユーザＭが画面２０８に表示されたハートボタン２０８ａをタップすると、紹介相手の詳細情報が表示される（ステップＳ６６６）。図４４に、紹介相手の詳細情報表示画面の一例を示す。図示された例では、画面２０９に、紹介相手（人物Ｐ）のプロフィールと、会ってみたいボタン２０９ａ、および、やめておくボタン２０９ｂが表示される（ステップＳ６６９）。

次いで、エージェントを通してユーザと人物Ｐとの対話がチャットや音声によって行われる（ステップＳ６７２）。ここでの対話は、エージェントを通した対話であって、ユーザはまだ相手の声を直接聞くことなく、相手の発話がエージェントの音声で出力、若しくはエージェントの発言として表示される。ユーザは相手のプロフィールを紹介フェーズで初めて知ることとなるが、固定フェーズまでの処理で十分にユーザと相手のマッチングが行われているため、ユーザ側からすると、表示される人物Ｐのプロフィール情報はこれまで接してきたエージェントの嗜好と同様であり、また、性格も似ていることが期待され、好印象のまま人物Ｐとの会話に移行できる。また、人物Ｐ（女性）側から見ても、自分の分身となるエージェントによる会話が既に上手くいっている男性が紹介されているため、ユーザを気に入る確率が高い。このように、本実施例では、出会いの成功確率が高まる紹介を行うことが可能となる。

次に、ユーザと人物Ｐのうちどちらかが「やめておく」ボタンを押した場合（ステップＳ６７５／Ｙｅｓ）、人物Ｐとのマッチングは解消される。ユーザがエージェントを選び直す場合（ステップＳ６７８／Ｙｅｓ）、エージェント学習部３５３は、エージェントを消去し（ステップＳ６８１）、探索フェーズのエージェント選択（ステップＳ４１３〜Ｓ４３７）から再度開始する。

若しくは、ユーザがエージェントを選び直さない場合（ステップＳ６７８／Ｎｏ）、現在のエージェントのまま（人物Ｐとのマッチングは解消された状態）、探索フェーズの対話ループ（ステップＳ４４０〜Ｓ４４６）に戻り、再度マッチングが行われる（この際、マッチングを解消した人物Ｐは一定期間除外されるようにしてもよい）。

一方、双方が「会ってみたい」ボタンを押した場合（ステップＳ６８４／Ｙｅｓ）、ユーザが支援を希望している場合は（ステップＳ６８５）、図４５に示す支援フェーズが開始される。支援が不要の場合（ステップＳ６８５／Ｙｅｓ）、エージェント学習部３５３は、エージェントの消去処理（クライアント端末１で起動するエージェントプログラムの消去処理）を行う（ステップＳ６８８）。この際、ユーザ用エージェント対話処理部３５０は、最後に図４８を参照して後述するような挨拶を行ってエージェントがユーザの元から去っていくような対話制御を行ってもよい。また、支援フェーズが不要な場合、ユーザはエージェントを介した人物Ｐとの対話の中で、会う日時や場所を決めたり、連絡先の交換等を行う。

（４−３−５．支援フェーズ）
次に、支援フェーズの実施例について図４５〜図４８を参照して説明する。支援フェーズでは、シナリオＤＢ３５９に登録されている出会いを支援するシナリオリストからユーザが任意でシナリオ（以下、「出会いプラン」とも称す）を選択し、シナリオに従った出会い演出が関係業者によって実施される。シナリオは有料制にしてもよい。

図４５は、本実施例による支援フェーズの動作処理を示すフローチャートである。図４５に示すように、まず、ユーザは、シナリオ管理部３５８により提示された複数の出会いプランから任意のプランを選択する（ステップＳ６９３）。ここで、図４６に、出会いプラン選択画面の一例を示す。図示された例では、画面２１０に、出会いプランのタイトル、内容、および費用といった詳細情報と、選択ボタン２１０ａ、戻るボタン２１０ｂが表示されている。出会いプランは、例えば「素敵なイタリアンレストランで彼女に嬉しいサプライズが起こる」等のタイトルで、サプライズ内容として特別メニューの用意や特別席の用意、プレゼントの用意等の内容が記載されている。出会いプランに登場するレストランや施設は、例えば広告としてタイアップしており、無料の出会いプランであっても特定のレストランや施設にユーザを誘導することで集客効果が期待できる。また、有料の出会いプランを用意してスポンサーとは無関係の場所にユーザを誘導してもよい。

ユーザが出会いプランを選択すると、ユーザと人物Ｐに出会いプランの日時と場所が通知される（ステップＳ６９６）。ここで、図４７に、出会いプラン通知画面の一例を示す。図４７左側には、人物Ｐのクライアント端末１の表示部１０６Ａに表示される画面２１１を示す。画面２１１には、「ここを予約してみました。お会いできるのを楽しみにしています！」といったユーザＭのメッセージと、出会いプランの詳細情報と、承諾ボタン２１１ａおよび断るボタン２１１ｂが表示される。人物Ｐは、日時場所とプランの内容を確認し、問題無ければ承諾ボタン２１１ａをタップし、このお誘いを断る場合は断るボタン２１１ｂをタップする。

また、図４７右側には、ユーザＭのクライアント端末１の表示部１０６Ｂに表示される画面２１２を示す。画面２１２には、人物Ｐを誘った旨と、出会いプランの詳細情報と、ＯＫボタン２１２ａおよびやり直すボタン２１２ｂが表示される。ユーザＭは、日時場所とプラン内容を確認し、問題無ければＯＫボタン２１２ａをタップし、日時やプランを変更する場合はやり直すボタン２１２ｂをタップする。

次いで、双方が出会いプランを承諾すると、シナリオ管理部３５８は、出会いプランを関係業者（レストランや施設等）に通知する（ステップＳ６９９）。

次に、指定日時まで待ち（ステップＳ７０２）、シナリオ管理部３５８は、指定日時が来ると二人が指定の日時場所で出会ったかどうかを確認する（ステップＳ７０５）。二人が実際に出会ったか否かは、ＧＰＳ等により検知された二人の位置情報から自動的に判断してもよいし、ユーザＭから手動で出会ったことが通知されてもよい。

次いで、二人が指定の日時場所で出会った場合（ステップＳ７０５／Ｙｅｓ）、シナリオ管理部３５８は、二人が出会ったことを関係業者に通知する（ステップＳ７０８）。なおレストランであれば、予約の二人が到着したことは明示的に把握可能である。そして、関係業者は、出会いプランの内容を二人に提供する。

次に、シナリオ管理部３５８は、関係業者からの完了通知を待ち（ステップＳ７１１）、完了通知を受け取ると、二人が付き合うことになったか否かをエージェントからユーザＭに尋ねる（ステップＳ７１４）。尋ねるタイミングは、一定期間経過してからであってもよい。

次いで、付き合うことになった場合（ステップＳ７１４／Ｙｅｓ）、ユーザ用エージェント対話処理部３５０は、祝福のメッセージを伝えてエージェントが去って行くよう対話制御する（ステップＳ７１７）。ここで、図４８に、エージェントによる最後のお祝いメッセージ画面の一例を示す。図示された例では、画面２１３に、エージェント「サキ」からユーザＭに対して「彼女とは付き合うことになったの？」と尋ねるメッセージと、「付き合う」ボタン２１３ａ、および「ダメだった」ボタン２１３ｂが表示される。ユーザＭは、人物Ｐと付き合うことになった場合、「付き合う」ボタン２１３ａをタップする。すると、図４８右側に示すように、画面２１４に、エージェント「サキ」から「そう…それはおめでとう！私も嬉しいわ。だって私は彼女の分身だもの。私の役目は今日で終わりね。せっかくここまで来たのだから、幸せになってね。私はここでお別れ。さようなら。」といった最後のお祝いメッセージが表示される。

そして、エージェント学習部３５３は、エージェントの消去処理（クライアント端末１で起動するエージェントアプリケーションの消去処理）を行う（ステップＳ７２０）。

一方、指定日時に二人が出会えなかった場合（ステップＳ７２３／Ｎｏ）、ユーザ用エージェント対話処理部３５０は、残念であった旨のメッセージをエージェントからユーザＭへ提示する（ステップＳ２７３）。

また、付き合うことにならなかった場合（ステップＳ７１４／Ｎｏ）、ユーザ用エージェント対話処理部３５０は、慰めや励ましのメッセージをエージェントからユーザＭへ提示する（ステップＳ７２６）。

そして、ユーザがエージェントを選び直す場合（ステップＳ７２９／Ｙｅｓ）、エージェント学習部３５３は、エージェントを消去し、探索フェーズのエージェント選択（ステップＳ４１３〜Ｓ４３７）から再度開始する。

若しくは、ユーザがエージェントを選び直さない場合（ステップＳ７２９／Ｎｏ）、現在のエージェントのまま（人物Ｐとのマッチングは解消された状態）、探索フェーズの対話ループ（ステップＳ４４０〜Ｓ４４６）に戻り、再度マッチングが行われる（この際、マッチングを解消した人物Ｐは一定期間除外されるようにしてもよい）。

＜＜５．まとめ＞＞
上述したように、本開示の実施形態による通信制御システムでは、エージェントとの対話をシームレスに実世界の人物とのコミュニケーションに繋げることが可能である。

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

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

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

また、上述した実施例では、男性ユーザを想定して女性の婚活会員を紹介する場合について説明したが、当然に、女性ユーザを想定して男性の婚活会員を紹介する場合にも応用可能である。

また、結婚相談所の婚活会員情報を用いた男女のマッチングに限定されず、例えばＳＮＳに登録された情報を用いてＳＮＳ内での友達マッチング（異性、同性問わず）に応用することも可能である。若しくは、就活情報を用いて人事と就活生とのマッチングに応用することも可能である。

このように、本実施形態は、様々な場面における人物マッチングに広く適用される。

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

なお、本技術は以下のような構成も取ることができる。
（１）
それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶される記憶部と、
ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に返信する通信部と、
ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し；
前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し；
所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御する制御部と、
を備える、情報処理システム。
（２）
前記制御部は、
前記特定のエージェントの属性を前記ユーザの属性に近付けるよう更新したものを当該ユーザ用エージェントの属性として記録し；
一定期間毎に前記ユーザ用エージェントの属性に最も類似する相手ユーザを選出し、同一人物が所定回数選出された場合に相手ユーザとして特定する、前記（１）に記載の情報処理システム。
（３）
前記制御部は、前記ユーザ用エージェントの属性に最も類似する相手ユーザの属性に応じて、前記ユーザ用エージェントの属性を更新する、前記（１）または（２）に記載の情報処理システム。
（４）
前記ユーザ用エージェントの属性に最も類似する相手ユーザが一定期間同一であるとき、当該相手ユーザの属性に応じて、前記ユーザ用エージェントの属性を更新する、前記（２）〜（３）のいずれか１項に記載の情報処理システム。
（５）
前記実在する複数の相手ユーザの属性は、外部装置から取得される、前記（４）に記載の情報処理システム。
（６）
前記制御部は、前記ユーザと、前記ユーザ用エージェントとの親密度が閾値を超えると、前記ユーザに前記相手ユーザの存在を通知する、前記（４）または（５）に記載の情報処理システム。
（７）
前記制御部は、さらに、前記相手ユーザに前記ユーザの存在を通知する、前記（６）に記載の情報処理システム。
（８）
前記制御部は、前記ユーザと前記相手ユーザの双方から会いたい旨の要求信号を受信すると、出会いのシナリオを前記ユーザに提供可能となる、前記（７）に記載の情報処理システム。
（９）
前記制御部は、前記ユーザから、前記相手ユーザと交際を始める旨の通知を受け取ると、前記ユーザにお祝いのメッセージを送信すると共に、前記クライアント端末におけるエージェントアプリケーションが消去されるように制御する、前記（８）に記載の情報処理システム。
（１０）
前記属性は、プロフィール情報、嗜好情報、性格情報、理想のプロフィール条件情報、および理想の性格情報の少なくともいずれかである、前記（１）〜（９）のいずれか１項に記載の情報処理システム。
（１１）
それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、
ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、
を備える、情報処理装置。
（１２）
前記制御部は、前記サーバ装置から、前記ユーザと前記ユーザ用エージェントとの親密度が閾値を超えると判断されたタイミングで前記相手ユーザの存在の通知を受信する、前記（１１）に記載の情報処理装置。
（１３）
前記制御部は、前記サーバ装置により、前記相手ユーザとの出会いのシナリオを受信する、前記（１２）に記載の情報処理装置。
（１４）
前記制御部は、
前記ユーザの指示に応じて、前記相手ユーザと交際を始める旨の通知を前記サーバ装置に送信し；
当該交際を始める旨の通知に応じて、サーバ装置から、お祝いのメッセージおよび情報処理装置に実装されるエージェントアプリケーションの消去を指示する制御信号を受信し、当該制御信号に応じて前記エージェントアプリケーションを消去するように制御する、前記（１３）に記載の情報処理装置。
（１５）
前記属性は、プロフィール情報、嗜好情報、性格情報、理想のプロフィール条件情報、および理想の性格情報の少なくともいずれかである、前記（１１）〜（１４）のいずれか１項に記載の情報処理装置。
（１６）
プロセッサが、
それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報を記憶部に記憶することと、
ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に通信部により返信することと、
ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し；
前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し；
所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御することと、
を含む、情報処理方法。
（１７）
コンピュータを、
それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、
ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、
として機能させるためのプログラム。

１ クライアント端末
２ エージェントサーバ
３０ 対話処理部
３００ 対話処理部
３１０ 質問文検索部
３２０ 回答文生成部
３３０ 会話ＤＢ
３４０ 音素データ取得部
３０ａ 対話処理部
３１ 基本対話処理部
３２ キャラクターＡ対話処理部
３３ 人物Ｂ対話処理部
３４ 人物Ｃ対話処理部
３５ マッチング部
３５０ ユーザ用エージェント対話処理部
３５１ ユーザ／エージェント情報管理部３５１
３５２ ユーザ情報ＤＢ
３５３ エージェント学習部
３５４ ユーザ用エージェントＤＢ
３５５ 紹介ユーザ選出部
３５６ 親密度算出部
３５７ 紹介処理部
３５８ シナリオ管理部
３５９ シナリオＤＢ
３６０ エージェント情報ＤＢ
３６ 通信部
４０ 音素記憶部
４１ 基本用音素ＤＢ
４２ キャラクターＡ音素ＤＢ
４３ 人物Ｂ音素ＤＢ
４４ 人物Ｃ音素ＤＢ
５０ 会話ＤＢ生成部
６０ 音素ＤＢ生成部
７０ 広告挿入処理部
７２ 広告ＤＢ
８０ フィードバック取得処理部
３ ネットワーク
１０ エージェント

Claims (17)

1. それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶される記憶部と、
   ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に返信する通信部と、
   ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
   前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し；
   前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し；
   所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御する制御部と、
   を備える、情報処理システム。
2. 前記制御部は、
   前記特定のエージェントの属性を前記ユーザの属性に近付けるよう更新したものを当該ユーザ用エージェントの属性として記録し；
   一定期間毎に前記ユーザ用エージェントの属性に最も類似する相手ユーザを選出し、同一人物が所定回数選出された場合に相手ユーザとして特定する、請求項１に記載の情報処理システム。
3. 前記制御部は、前記ユーザ用エージェントの属性に最も類似する相手ユーザの属性に応じて、前記ユーザ用エージェントの属性を更新する、請求項１に記載の情報処理システム。
4. 前記ユーザ用エージェントの属性に最も類似する相手ユーザが一定期間同一であるとき、当該相手ユーザの属性に応じて、前記ユーザ用エージェントの属性を更新する、請求項２に記載の情報処理システム。
5. 前記実在する複数の相手ユーザの属性は、外部装置から取得される、請求項４に記載の情報処理システム。
6. 前記制御部は、前記ユーザと、前記ユーザ用エージェントとの親密度が閾値を超えると、前記ユーザに前記相手ユーザの存在を通知する、請求項４に記載の情報処理システム。
7. 前記制御部は、さらに、前記相手ユーザに前記ユーザの存在を通知する、請求項６に記載の情報処理システム。
8. 前記制御部は、前記ユーザと前記相手ユーザの双方から会いたい旨の要求信号を受信すると、出会いのシナリオを前記ユーザに提供可能となる、請求項７に記載の情報処理システム。
9. 前記制御部は、前記ユーザから、前記相手ユーザと交際を始める旨の通知を受け取ると、前記ユーザにお祝いのメッセージを送信すると共に、前記クライアント端末におけるエージェントアプリケーションが消去されるように制御する、請求項８に記載の情報処理システム。
10. 前記属性は、プロフィール情報、嗜好情報、性格情報、理想のプロフィール条件情報、および理想の性格情報の少なくともいずれかである、請求項１に記載の情報処理システム。
11. それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、
    ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
    前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、
    を備える、情報処理装置。
12. 前記制御部は、前記サーバ装置から、前記ユーザと前記ユーザ用エージェントとの親密度が閾値を超えると判断されたタイミングで前記相手ユーザの存在の通知を受信する、請求項１１に記載の情報処理装置。
13. 前記制御部は、前記サーバ装置により、前記相手ユーザとの出会いのシナリオを受信する、請求項１２に記載の情報処理装置。
14. 前記制御部は、
    前記ユーザの指示に応じて、前記相手ユーザと交際を始める旨の通知を前記サーバ装置に送信し；
    当該交際を始める旨の通知に応じて、サーバ装置から、お祝いのメッセージおよび情報処理装置に実装されるエージェントアプリケーションの消去を指示する制御信号を受信し、当該制御信号に応じて前記エージェントアプリケーションを消去するように制御する、請求項１３に記載の情報処理装置。
15. 前記属性は、プロフィール情報、嗜好情報、性格情報、理想のプロフィール条件情報、および理想の性格情報の少なくともいずれかである、請求項１１に記載の情報処理装置。
16. プロセッサが、
    それぞれ異なる属性を有し、ユーザと対話可能な複数のエージェントの情報を記憶部に記憶することと、
    ユーザからのメッセージをクライアント端末から受信すると共に、応答メッセージを当該クライアント端末に通信部により返信することと、
    ユーザからの指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
    前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性を更新したものをユーザ用エージェントの属性として記録し；
    前記ユーザ用エージェントの属性と、実在する複数の相手ユーザの属性とを比較することにより、当該ユーザ用エージェントの属性に最も類似する相手ユーザを特定し；
    所定のタイミングで前記ユーザに前記相手ユーザの存在を通知するように制御することと、
    を含む、情報処理方法。
17. コンピュータを、
    それぞれが異なる属性を有し、ユーザと対話可能な複数のエージェントの情報が記憶されるサーバ装置に対して、ユーザからのメッセージを送信すると共に、そのメッセージに対する応答メッセージを受信する通信部と、
    ユーザによる指示に応じて、前記複数のエージェントから特定のエージェントを選択し；
    前記特定のエージェントと前記ユーザとの対話に応じて、当該特定のエージェントの属性が更新されたユーザ用エージェントの属性に最も類似する実在する相手ユーザが存在することを示す通知を、前記サーバ装置から前記通信部を介して所定のタイミングで受信するように制御する、制御部と、
    として機能させるためのプログラム。

Images