知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024171675
(43)【公開日】2024-12-12
(54)【発明の名称】ＡＩを用いた文書管理システム及び文書管理方法
(51)【国際特許分類】
G06F 16/34 20190101AFI20241205BHJP
【ＦＩ】
G06F16/34
【審査請求】未請求
【請求項の数】39
【出願形態】ＯＬ
(21)【出願番号】P 2023088817
(22)【出願日】2023-05-30
(71)【出願人】
【識別番号】519291331
【氏名又は名称】株式会社ＥＬＹＺＡ
(74)【代理人】
【識別番号】110003476
【氏名又は名称】弁理士法人瑛彩知的財産事務所
(72)【発明者】
【氏名】曽根岡 侑也
(72)【発明者】
【氏名】垣内 弘太
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175FB01
5B175HB03
(57)【要約】
【課題】 ＡＩによる要約生成を用いた業務効率化を行う仕組みを提供する。
【解決手段】 第１の文書情報を取得する文書情報取得手段と、文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、前記要約生成手段により取得された前記要約を出力する出力処理手段と、を有する文書管理システム。
【選択図】 図２４
【解決手段】 第１の文書情報を取得する文書情報取得手段と、文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、前記要約生成手段により取得された前記要約を出力する出力処理手段と、を有する文書管理システム。
【選択図】 図２４
【特許請求の範囲】
【請求項1】
第１の文書情報を取得する文書情報取得手段と、
文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、
前記要約生成手段により取得された前記要約を出力する出力処理手段と、
を有する文書管理システム。
文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、
前記要約生成手段により取得された前記要約を出力する出力処理手段と、
を有する文書管理システム。
【請求項2】
前記第１の文書情報が属するカテゴリを特定するカテゴリ特定手段を有する
請求項１に記載の文書管理システム。
請求項１に記載の文書管理システム。
【請求項3】
前記要約生成手段は、前記カテゴリに対応する第２の機械学習モデルを選択し、前記第２の機械学習モデルに前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記第２の機械学習モデルから取得する
請求項２に記載の文書管理システム。
請求項２に記載の文書管理システム。
【請求項4】
前記第２の機械学習モデルは、前記カテゴリに属する複数の文書情報を教師データとして用いて機械学習を行った学習済みの機械学習モデルである
請求項３に記載の文書管理システム。
請求項３に記載の文書管理システム。
【請求項5】
前記要約生成手段は、前記カテゴリを示す情報と、前記第１の文書情報と、を入力することで、前記第１の文書情報に対する前記カテゴリに関連する要約を前記機械学習モデルから取得する
請求項２に記載の文書管理システム。
請求項２に記載の文書管理システム。
【請求項6】
前記機械学習モデルは、文書情報の属するカテゴリを示す情報と前記カテゴリに属する複数の文書情報とを教師データとして用いて機械学習を行った学習済みの機械学習モデルである
請求項５に記載の文書管理システム。
請求項５に記載の文書管理システム。
【請求項7】
前記要約生成手段は、前記カテゴリに関連する要約のテンプレートを出力する
請求項２に記載の文書管理システム。
請求項２に記載の文書管理システム。
【請求項8】
前記要約に対する編集を受け付ける要約編集手段を有する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項9】
前記要約生成手段は、編集された要約の一部を入力し、要約の少なくとも一部を再生成する
請求項８に記載の文書管理システム。
請求項８に記載の文書管理システム。
【請求項10】
前記要約編集手段は、前記要約の変更のためのテンプレートを出力する
請求項８に記載の文書管理システム。
請求項８に記載の文書管理システム。
【請求項11】
前記要約に対する評価を受け付ける評価取得手段を有する請求項１～７のいずれか１項に記載の文書管理システム。
【請求項12】
受け付けた前記評価が高い要約が生成された文書情報を用いて、前記機械学習モデルを再学習する請求項１１に記載の文書管理システム。
【請求項13】
前記要約生成手段は、生成する要約に対する設定値の入力を受け付け、
前記設定値に応じて、生成される前記要約の出力内容を変化させる
請求項１～７のいずれか１項に記載の文書管理システム。
前記設定値に応じて、生成される前記要約の出力内容を変化させる
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項14】
前記要約生成手段は、第２情報取得手段により取得された第１の文書に関連する第２の文書情報と、前記第１の文書情報と、を入力し、要約を生成する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項15】
前記要約に含まれる１又は複数の特徴文字列のうち、所定の条件を満たす前記特徴文字列を強調表示する強調表示手段を有する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項16】
前記所定の条件は、日付、時間、名前、場所、電話番号、契約者番号、顧客番号、住所、数量、アドレスの少なくとも１つを含む属性に関する情報が存在すること、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項１５に記載の文書管理システム。
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項１５に記載の文書管理システム。
【請求項17】
前記所定の条件は、前記特徴文字列が前記要約に存在するが前記第１の文書情報に存在しないこと、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報に存在しない前記特徴文字列を強調表示する
請求項１５に記載の文書管理システム。
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報に存在しない前記特徴文字列を強調表示する
請求項１５に記載の文書管理システム。
【請求項18】
前記所定の条件は、前記要約と前記第１の文書情報の間で対応する前記特徴文字列が存在すること、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第１の文書情報の間で対応する前記特徴文字列を強調表示する
請求項１５に記載の文書管理システム。
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第１の文書情報の間で対応する前記特徴文字列を強調表示する
請求項１５に記載の文書管理システム。
【請求項19】
（要約の精度が高くないもの＝AIの自信のない箇所を強調表示）
前記所定の条件は、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列が存在すること、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項１５に記載の文書管理システム。
前記所定の条件は、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列が存在すること、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項１５に記載の文書管理システム。
【請求項20】
前記出力処理手段は、前記要約生成手段により取得された前記要約と、前記文書情報取得手段により取得された前記第１の文書情報と、を対応付けて出力する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項21】
前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の特徴文字列のうち、所定の条件を満たす前記特徴文字列を強調表示する強調表示手段を有する
請求項２０に記載の文書管理システム。
請求項２０に記載の文書管理システム。
【請求項22】
前記所定の条件は、日付、時間、名前、場所、住所、数量、アドレスの少なくとも１つを含む属性に関する情報が存在すること、であり、
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項２１に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項２１に記載の文書管理システム。
【請求項23】
前記所定の条件は、前記特徴文字列が前記要約に存在するが前記第１の文書情報に存在しないこと、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報に存在しない前記特徴文字列を強調表示する
請求項２１に記載の文書管理システム。
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報に存在しない前記特徴文字列を強調表示する
請求項２１に記載の文書管理システム。
【請求項24】
前記所定の条件は、前記要約と前記第１の文書情報の間で対応する前記特徴文字列が存在すること、であり、
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第１の文書情報の間で対応する前記特徴文字列を強調表示する
請求項２１に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第１の文書情報の間で対応する前記特徴文字列を強調表示する
請求項２１に記載の文書管理システム。
【請求項25】
前記所定の条件は、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列が存在すること、であり、
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項２１に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第１の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項２１に記載の文書管理システム。
【請求項26】
前記出力処理手段は、前記要約生成手段により取得された前記要約と、第２情報取得手段により取得された第２の文書情報と、を対応付けて出力する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項27】
前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の特徴文字列のうち、所定の条件を満たす前記特徴文字列を強調表示する強調表示手段を有する
請求項２６に記載の文書管理システム。
請求項２６に記載の文書管理システム。
【請求項28】
前記所定の条件は、日付、時間、名前、場所、住所、数量、アドレスの少なくとも１つを含む属性に関する情報が存在すること、であり、
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項２７に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記属性に関する情報を含む文字列を強調表示する
請求項２７に記載の文書管理システム。
【請求項29】
前記所定の条件は、前記特徴文字列が前記第２の文書情報に存在するが前記要約に存在しないこと、であり、
前記強調表示手段は、前記第２の文書情報に含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報に存在するが前記要約に存在しない前記特徴文字列を強調表示する
請求項２７に記載の文書管理システム。
前記強調表示手段は、前記第２の文書情報に含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報に存在するが前記要約に存在しない前記特徴文字列を強調表示する
請求項２７に記載の文書管理システム。
【請求項30】
前記所定の条件は、前記要約と前記第２の文書情報の間で対応する前記特徴文字列が存在すること、であり、
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第２の文書情報の間で対応する前記特徴文字列を強調表示する
請求項２７に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約と前記第２の文書情報の間で対応する前記特徴文字列を強調表示する
請求項２７に記載の文書管理システム。
【請求項31】
前記所定の条件は、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列が存在すること、であり、
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項２７に記載の文書管理システム。
前記強調表示手段は、前記要約または前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記要約生成手段が生成した前記要約の中で要約の精度が高くない可能性がある文字列を強調表示する
請求項２７に記載の文書管理システム。
【請求項32】
前記出力処理手段は、前記文書情報取得手段により取得された前記第１の文書情報と、前記要約生成手段により取得された前記要約と、第２情報取得手段により取得された第２の文書情報と、を対応付けて出力する
請求項１～７のいずれか１項に記載の文書管理システム。
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項33】
第２の文書情報を取得する第２情報取得手段を有し、
前記要約、第１の文書情報、前記第２の文書情報の少なくとも１つに含まれる１又は複数の特徴文字列のうち、所定の条件を満たす前記特徴文字列を強調表示する強調表示手段を有する
請求項３２に記載の文書管理システム。
前記要約、第１の文書情報、前記第２の文書情報の少なくとも１つに含まれる１又は複数の特徴文字列のうち、所定の条件を満たす前記特徴文字列を強調表示する強調表示手段を有する
請求項３２に記載の文書管理システム。
【請求項34】
前記所定の条件は、前記第２の文書情報と前記要約に対応する前記特徴文字列が存在すること、であり、
前記強調表示手段は、前記第１の文書情報、前記第２の文書情報、前記要約の少なくとも１つに含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報と前記要約に対応する前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
前記強調表示手段は、前記第１の文書情報、前記第２の文書情報、前記要約の少なくとも１つに含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報と前記要約に対応する前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
【請求項35】
前記所定の条件は、前記特徴文字列が前記第２の文書情報に存在するが前記要約に存在しないこと、であり、
前記強調表示手段は、前記第１の文書情報又は前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報に存在するが前記要約に存在しない前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
前記強調表示手段は、前記第１の文書情報又は前記第２の文書情報の少なくともいずれかに含まれる１又は複数の前記特徴文字列のうち、前記第２の文書情報に存在するが前記要約に存在しない前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
【請求項36】
前記所定の条件は、前記特徴文字列が前記要約に存在するが前記第１の文書情報又は前記第２の文書情報に存在しないこと、であり、
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報又は前記第２の文書情報に存在しない前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
前記強調表示手段は、前記要約に含まれる１又は複数の前記特徴文字列のうち、前記要約に存在するが前記第１の文書情報又は前記第２の文書情報に存在しない前記特徴文字列を強調表示する
請求項３３に記載の文書管理システム。
【請求項37】
前記文書情報取得手段は、音声情報の入力を受け付け、
前記音声情報を解析してテキスト化することで、前記第１の文書情報を取得する
請求項１～７のいずれか１項に記載の文書管理システム。
前記音声情報を解析してテキスト化することで、前記第１の文書情報を取得する
請求項１～７のいずれか１項に記載の文書管理システム。
【請求項38】
管理サーバを請求項１～３７のいずれか１項に記載の文書管理システムの各手段として機能させるためのプログラム。
【請求項39】
第１の文書情報を取得し、
文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得し、
前記要約を出力する
文書管理方法。
文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得し、
前記要約を出力する
文書管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ＡＩを用いた文書管理システム及び文書管理方法に関する。
【背景技術】
【0002】
本技術分野の背景技術として、特開２０１３－１９０９９１号公報（特許文献１）がある。この公報には、「コールセンターにおける応対モニタリング（音声を聞いて評価）を効率化する支援方式において、トークスクリプトの対話フローから外れた応対集合に対しても、モニタリング業務を効率化できるようにすること。音声対話要約装置は、対話テキストの集合から複数の発話を抽出し、抽出した複数の発話のうちの互いに含意関係で結ばれたものを発話クラスタとして抽出する」と記載されている（要約参照）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１３－１９０９９１号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
前記特許文献１には、コールセンターにおいて対話テキストの集合から複数の発話を抽出し、発話クラスタを抽出する音声対話要約装置の仕組みが記載されている。しかしながら、本特許文献においては、電話、チャット、メール等を用いた様々な種類の顧客応対業務について、ＡＩによる要約生成を用いた業務効率化の方法について検討がなされていない。
そこで、本発明は、ＡＩによる要約生成を用いた業務効率化を行う仕組みを提供する。
そこで、本発明は、ＡＩによる要約生成を用いた業務効率化を行う仕組みを提供する。
【課題を解決するための手段】
【0005】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、第１の文書情報を取得する文書情報取得手段と、文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、前記要約生成手段により取得された前記要約を出力する出力処理手段と、を有することを特徴とする。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、第１の文書情報を取得する文書情報取得手段と、文書情報を入力として要約を生成するための機械学習を行った学習済みの機械学習モデルに、前記文書情報取得手段により取得された前記第１の文書情報を入力することで、前記第１の文書情報に対する要約を前記機械学習モデルから取得する要約生成手段と、前記要約生成手段により取得された前記要約を出力する出力処理手段と、を有することを特徴とする。
【発明の効果】
【0006】
本発明によれば、ＡＩによる要約生成を用いた業務効率化を行う仕組みを提供することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0007】
【発明を実施するための形態】
【0008】
以下、実施例を図面を用いて説明する。
本実施例は、例えばコールセンターで働くオペレータ等のユーザが、顧客対応業務を容易に行いやすくするものである。
例えば、顧客応対が終わった後に、コールセンターのオペレータが、通話内容についての情報をシステムに入力し、ＣＲＭ（Customer Relationship Management）システムに反映させる一連の処理を容易に実行できるシステムを提供する。この様な顧客応対後の処理をＡＣＷ（アフターコールワーク）と呼ぶ。
システムで対応することができるＡＣＷとしては、例えば問合せ内容についての諸々のカテゴリ情報を記入・選択する処理、通話内容の要約を作成する処理、応対状況・応対方法について通話中に確定させた顧客情報と紐づく形でＣＲＭシステムに格納する処理等がある。
本実施例は、例えばコールセンターで働くオペレータ等のユーザが、顧客対応業務を容易に行いやすくするものである。
例えば、顧客応対が終わった後に、コールセンターのオペレータが、通話内容についての情報をシステムに入力し、ＣＲＭ（Customer Relationship Management）システムに反映させる一連の処理を容易に実行できるシステムを提供する。この様な顧客応対後の処理をＡＣＷ（アフターコールワーク）と呼ぶ。
システムで対応することができるＡＣＷとしては、例えば問合せ内容についての諸々のカテゴリ情報を記入・選択する処理、通話内容の要約を作成する処理、応対状況・応対方法について通話中に確定させた顧客情報と紐づく形でＣＲＭシステムに格納する処理等がある。
【0009】
本システムを使用すれば、顧客応対業務を一元化でき、またＡＣＷに係る時間を飛躍的に減少させることが可能であり、コールセンターの業務を効率化することができる。
なお、本システムは、コールセンターでの電話応対業務に限られず、チャットやメール等を用いた顧客応対業務に対しても適用可能であり、また何等か文書を管理する業務に対して適用することが可能である。
なお、本システムは、コールセンターでの電話応対業務に限られず、チャットやメール等を用いた顧客応対業務に対しても適用可能であり、また何等か文書を管理する業務に対して適用することが可能である。
【0010】
顧客応対管理システム１は、複数のユーザ端末１０２、複数の管理者端末１０３を備え、それぞれがネットワークを介して管理サーバ１０１に接続されている。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。
ユーザ端末１０２は、例えばコールセンターで顧客応対業務を行うオペレータ等のユーザが使用する端末である。
管理者端末１０３は、コールセンターで稼働している複数のユーザ端末１０２や多数のオペレータの作業等を管理する端末である。また、管理サーバ１０１の設定を変更する等、管理サーバ１０１を管理する機能を備えていてもよい。
ユーザ端末１０２は、例えばコールセンターで顧客応対業務を行うオペレータ等のユーザが使用する端末である。
管理者端末１０３は、コールセンターで稼働している複数のユーザ端末１０２や多数のオペレータの作業等を管理する端末である。また、管理サーバ１０１の設定を変更する等、管理サーバ１０１を管理する機能を備えていてもよい。
【0011】
顧客応対管理システム１のそれぞれの端末や管理サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末（モバイル端末）でもよいし、メガネ／ゴーグル型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。また、機能としてはＶＲ（仮想現実：Virtual Reality）端末、ＡＲ（拡張現実：Augmented Reality）端末、ＭＲ（複合現実：Mixed Reality）端末でもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。
【0012】
顧客応対管理システム１のそれぞれの端末や管理サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。
【0013】
主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
【0014】
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。
補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システム、ファイル管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬ、ＪＳＯＮなどのテキストファイルでもよい。
補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システム、ファイル管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬ、ＪＳＯＮなどのテキストファイルでもよい。
【0015】
図２は、管理サーバ１０１のハードウェア構成図の例である。
管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
但し、管理サーバ１０１は、ユーザ端末１０２及び／又は管理者端末１０３と同じ拠点内にオンプレミス型で構築されてもよい。また、ユーザ端末１０２及び／又は管理者端末１０３と一体として構成されてもよい。
主記憶装置２０１には、顧客応対処理モジュール２１１、カテゴリ選択モジュール２１２、文書情報取得モジュール２１３、要約生成モジュール２１４、メモ情報取得モジュール２１５、強調表示モジュール２１６、フィードバックモジュール２１７、データ検索モジュール２１８等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで管理サーバ１０１の各機能要素が実現される。
管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
但し、管理サーバ１０１は、ユーザ端末１０２及び／又は管理者端末１０３と同じ拠点内にオンプレミス型で構築されてもよい。また、ユーザ端末１０２及び／又は管理者端末１０３と一体として構成されてもよい。
主記憶装置２０１には、顧客応対処理モジュール２１１、カテゴリ選択モジュール２１２、文書情報取得モジュール２１３、要約生成モジュール２１４、メモ情報取得モジュール２１５、強調表示モジュール２１６、フィードバックモジュール２１７、データ検索モジュール２１８等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで管理サーバ１０１の各機能要素が実現される。
【0016】
顧客応対処理モジュール２１１は、ユーザ（オペレータ等）が行う顧客応対処理の全体を統括管理する機能を提供する。本実施例ではコールセンターにおける電話応対を例に説明するが、これに限られず、チャット、メール、問合せフォーム、メッセージ送受信サービス等により受信した顧客の要望に対しても適用可能である。
また、顧客応対処理モジュール２１１は、文書情報取得モジュール２１３により取得された文書情報と、要約生成モジュール２１４により生成された要約と、１つの画面上で対応付けて併せて表示することができる。なお、１つの画面上で２パネルを表示する構成だけでなく、例えば文書情報と要約をタブなどで切り替えて表示することもできる。この場合も、文書情報と要約を対応付けて表示していると言える。また、単に１つのパネルの内容のみを表示することとしてもよい。
また、顧客応対処理モジュール２１１は、文書情報取得モジュール２１３により取得された文書情報と、要約生成モジュール２１４により生成された要約と、１つの画面上で対応付けて併せて表示することができる。なお、１つの画面上で２パネルを表示する構成だけでなく、例えば文書情報と要約をタブなどで切り替えて表示することもできる。この場合も、文書情報と要約を対応付けて表示していると言える。また、単に１つのパネルの内容のみを表示することとしてもよい。
【0017】
カテゴリ選択モジュール２１２は、顧客の問合せがどのカテゴリに属しているのかを特定する。カテゴリとしては、例えば、以下のようなものが考えられる。
対象事業のカテゴリ：金融、保険、ＥＣ、公共エネルギー（電力、ガス、水道等）、観光、ブライダル等。
対象商品のカテゴリ：
・ブライダルのカテゴリに対して結婚式場、披露パーティー、新婚旅行等。
・保険のカテゴリに対して損害保険、生命保険、学資保険、自動車保険、火災保険等。
内容のカテゴリ：申込み／手続き、質問（問合せ）、相談、要望等。
カテゴリ情報を階層的に設計することで、様々な種類の顧客応対処理に対して柔軟に対応することが可能となる。
なお、カテゴリ情報はカテゴリ情報７００に記憶されているが、事前に登録される場合の他、ユーザ等が自由記述で記載して登録することもできる。また、カテゴリ選択モジュール２１２が、対話テキストの中に使用されている用語の中から抽出された文字列を、カテゴリ情報として新たに登録する構成であってもよい。
また、カテゴリ情報は、メタ情報であってもよい。文書等に対するメタ情報をカテゴリ情報として取り扱うことができる。
対象事業のカテゴリ：金融、保険、ＥＣ、公共エネルギー（電力、ガス、水道等）、観光、ブライダル等。
対象商品のカテゴリ：
・ブライダルのカテゴリに対して結婚式場、披露パーティー、新婚旅行等。
・保険のカテゴリに対して損害保険、生命保険、学資保険、自動車保険、火災保険等。
内容のカテゴリ：申込み／手続き、質問（問合せ）、相談、要望等。
カテゴリ情報を階層的に設計することで、様々な種類の顧客応対処理に対して柔軟に対応することが可能となる。
なお、カテゴリ情報はカテゴリ情報７００に記憶されているが、事前に登録される場合の他、ユーザ等が自由記述で記載して登録することもできる。また、カテゴリ選択モジュール２１２が、対話テキストの中に使用されている用語の中から抽出された文字列を、カテゴリ情報として新たに登録する構成であってもよい。
また、カテゴリ情報は、メタ情報であってもよい。文書等に対するメタ情報をカテゴリ情報として取り扱うことができる。
【0018】
文書情報取得モジュール２１３は、顧客との応対の会話内容をテキストデータとして取得し文書情報として記憶する。例えば顧客との電話応対の音声を音声解析しテキスト化することで、文書情報を生成する。
なお、チャット、メール、問合せフォーム、メッセージ送受信サービス等による顧客とのやり取りの場合には、送受信されるテキストの内容を、文書情報として記憶する。その他、顧客との応対内容に限られず、何等かの文書情報を取得できればよい。
なお、チャット、メール、問合せフォーム、メッセージ送受信サービス等による顧客とのやり取りの場合には、送受信されるテキストの内容を、文書情報として記憶する。その他、顧客との応対内容に限られず、何等かの文書情報を取得できればよい。
【0019】
要約生成モジュール２１４は、文書情報を入力し、その要約を生成する。ＡＩを用いる場合には、要約生成モジュール２１４は、文書情報を入力として要約を生成するための学習を行った学習済みの機械学習モデルに、文書情報を入力することで、入力された文書情報に対する要約を生成する。この際、文書情報と共にカテゴリ情報を入力することで、生成される要約の精度を高めたり、要約内容を調整したりすることができる。
メモ情報取得モジュール２１５は、顧客応対中にユーザにより記入されるメモを取得し記憶する。なお、メモは空白のテキストが入力される画面でもよいし、何らかのフォーマットが決められており、それに入力する構成であってもよい。何らかの文書情報が入力されるものであればよい。なお、メモは顧客応対前又は後に取得されるものであってもよい。
メモ情報取得モジュール２１５は、顧客応対中にユーザにより記入されるメモを取得し記憶する。なお、メモは空白のテキストが入力される画面でもよいし、何らかのフォーマットが決められており、それに入力する構成であってもよい。何らかの文書情報が入力されるものであればよい。なお、メモは顧客応対前又は後に取得されるものであってもよい。
【0020】
強調表示モジュール２１６は、文書情報、要約、メモ情報の中で条件を満たす部分を強調表示することにより、顧客応対業務を行いやすくする。
強調表示は、例えば、条件に合致する文書の部分を太字にする、下線を引く、色を変える、斜体にする、網掛けをする、フォントを変える、点滅させる、文字列の周りを線で囲う、背景色を変えたり文字列の上に色のレイヤーをかぶせたりしてハイライトする、等が考えられる。強調表示は、何等か他の文字列部分と比較して目立つ構成や区別しうる構成の文字列にすればよい。強調される文字列を別の画面やウィンドウで表示することにより、強調することとしてもよい。
強調表示は、例えば、条件に合致する文書の部分を太字にする、下線を引く、色を変える、斜体にする、網掛けをする、フォントを変える、点滅させる、文字列の周りを線で囲う、背景色を変えたり文字列の上に色のレイヤーをかぶせたりしてハイライトする、等が考えられる。強調表示は、何等か他の文字列部分と比較して目立つ構成や区別しうる構成の文字列にすればよい。強調される文字列を別の画面やウィンドウで表示することにより、強調することとしてもよい。
【0021】
フィードバックモジュール２１７は、生成した要約に対するユーザからの評価や修正を受け付ける。また、フィードバックモジュール２１７は、文書情報やメモ情報に対する修正を受け付けてもよい。本実施例では、これらの評価や修正をまとめてユーザからのフィードバックと呼ぶ。
データ検索モジュール２１８は、顧客応答業務に際して、顧客情報６００やＦＡＱ情報１２００、入力補助情報１３００等の検索を行う。
データ検索モジュール２１８は、顧客応答業務に際して、顧客情報６００やＦＡＱ情報１２００、入力補助情報１３００等の検索を行う。
【0022】
補助記憶装置２０２は、各種情報を記憶する各種データベースを備える。
それぞれのデータベースは、例えば、顧客情報６００、カテゴリ情報７００、文書情報８００、要約情報９００、メモ情報１０００、応対記録情報１１００等を記憶する。それぞれの情報の詳細は後述する。
それぞれのデータベースは、例えば、顧客情報６００、カテゴリ情報７００、文書情報８００、要約情報９００、メモ情報１０００、応対記録情報１１００等を記憶する。それぞれの情報の詳細は後述する。
【0023】
図３は、ユーザ端末１０２のハードウェア構成図の例である。
ユーザ端末１０２は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置３０１には、管理サーバ連携モジュール３１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することでユーザ端末１０２の各機能要素が実現される。
ユーザ端末１０２は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置３０１には、管理サーバ連携モジュール３１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することでユーザ端末１０２の各機能要素が実現される。
【0024】
管理サーバ連携モジュール３１０は、管理サーバ１０１の顧客応対処理モジュール２１１と連携して、管理サーバ１０１の提供する顧客応対処理を実行する。管理サーバ連携モジュール３１０は、出力装置２０５の１つであるディスプレイに管理サーバ１０１の提供する図２１～図３３等の各種画面を表示する。
【0025】
なお、管理サーバ１０１の顧客応対処理モジュール２１１は、例えば顧客応対機能をクラウド上から提供し、管理サーバ１０１から送信される画面情報を管理サーバ連携モジュール３１０がディスプレイに表示する。
但し、管理サーバ１０１の提供する全てのプログラムやアプリケーションの機能をユーザ端末１０２上に実装し、ユーザ端末１０２が単独で顧客応対機能を実現する構成でもよいし、一部のプログラムやアプリケーションの機能をユーザ端末１０２上に実装し、ユーザ端末１０２と管理サーバ１０１が連携して顧客応対機能を実現する構成でもよい。
但し、管理サーバ１０１の提供する全てのプログラムやアプリケーションの機能をユーザ端末１０２上に実装し、ユーザ端末１０２が単独で顧客応対機能を実現する構成でもよいし、一部のプログラムやアプリケーションの機能をユーザ端末１０２上に実装し、ユーザ端末１０２と管理サーバ１０１が連携して顧客応対機能を実現する構成でもよい。
【0026】
補助記憶装置３０２は、例えば、ユーザ端末管理情報３２０を記憶する。
ユーザ端末管理情報３２０は、例えばユーザ端末１０２を使用するユーザであるオペレータを特定する情報等が記憶されている。
また、管理サーバ１０１の機能の一部をユーザ端末１０２側で実施する構成の場合には、管理サーバ１０１に記憶されている各種情報と同様の情報をユーザ端末管理情報３２０に記憶してもよい。
ユーザ端末管理情報３２０は、例えばユーザ端末１０２を使用するユーザであるオペレータを特定する情報等が記憶されている。
また、管理サーバ１０１の機能の一部をユーザ端末１０２側で実施する構成の場合には、管理サーバ１０１に記憶されている各種情報と同様の情報をユーザ端末管理情報３２０に記憶してもよい。
【0027】
図４は、管理者端末１０３のハードウェア構成図の例である。
管理者端末１０３は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置４０１には、ユーザ端末管理モジュール４１０や管理サーバ管理モジュール４１１等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ４０３が実行することで管理者端末１０３の各機能要素が実現される。
管理者端末１０３は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置４０１には、ユーザ端末管理モジュール４１０や管理サーバ管理モジュール４１１等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ４０３が実行することで管理者端末１０３の各機能要素が実現される。
【0028】
ユーザ端末管理モジュール４１０は、コールセンターにおいて稼働している複数のユーザ端末１０２を取り纏めが管理する。
ユーザ端末管理モジュール４１０は、例えば図２９や図３０の様なＡＣＷ作業の効率を監視できる画面を表示する。各通話（やり取り）の一覧が確認・フィルタリングでき、各やり取りの入力を表示することができる。これらの画面に表示する情報は、ユーザ端末管理モジュール４１０が、管理サーバ１０１の顧客応対処理モジュール２１１と連携することで、取得する。
ユーザ端末管理モジュール４１０は、例えば図２９や図３０の様なＡＣＷ作業の効率を監視できる画面を表示する。各通話（やり取り）の一覧が確認・フィルタリングでき、各やり取りの入力を表示することができる。これらの画面に表示する情報は、ユーザ端末管理モジュール４１０が、管理サーバ１０１の顧客応対処理モジュール２１１と連携することで、取得する。
【0029】
また、ユーザ端末管理モジュール４１０は、時間（月・週など）ごと、ユーザごと、顧客応対の内容のカテゴリごと、等の各重要属性ごとに、ＡＣＷにかかった時間の分布・統計値等を算出し、表示する。
また、ユーザ端末管理モジュール４１０は、各ユーザのＡＣＷ作業のログを例えば図３０のように表示する。
また、ユーザ端末管理モジュール４１０は、各ユーザのＡＣＷ作業のログを例えば図３０のように表示する。
【0030】
管理サーバ管理モジュール４１１は、管理サーバ１０１の各種設定を行う。例えば、管理サーバ管理モジュール４１１は、図２６の要約設定画面２６００により、要約生成の設定を行うことができる。
なお、管理サーバ１０１の提供する全てのプログラムやアプリケーションの機能を管理者端末１０３上に実装し、管理者端末１０３が顧客応対機能を実現する構成にすることもできる。また、一部のプログラムやアプリケーションの機能を管理者端末１０３上に実装し、ユーザ端末１０２と管理者端末１０３が連携して顧客応対機能を実現する構成でもよい。
なお、管理サーバ１０１の提供する全てのプログラムやアプリケーションの機能を管理者端末１０３上に実装し、管理者端末１０３が顧客応対機能を実現する構成にすることもできる。また、一部のプログラムやアプリケーションの機能を管理者端末１０３上に実装し、ユーザ端末１０２と管理者端末１０３が連携して顧客応対機能を実現する構成でもよい。
【0031】
補助記憶装置４０２は、例えば、管理者端末情報４２０を記憶する。
管理者端末情報４２０は、例えば管理者端末１０３を使用する管理者を特定する情報や、管理しているユーザ端末１０２や各ユーザを特定する情報等が記憶されている。
また、管理サーバ１０１の機能の一部を管理者端末１０３側で実施する構成の場合には、管理サーバ１０１に記憶されている各種情報と同様の情報を管理者端末情報４２０に記憶してもよい。
管理者端末情報４２０は、例えば管理者端末１０３を使用する管理者を特定する情報や、管理しているユーザ端末１０２や各ユーザを特定する情報等が記憶されている。
また、管理サーバ１０１の機能の一部を管理者端末１０３側で実施する構成の場合には、管理サーバ１０１に記憶されている各種情報と同様の情報を管理者端末情報４２０に記憶してもよい。
【0032】
図５は、要約生成モジュール２１４のシステム構成図の例である。
要約生成モジュール２１４の実装の方法は色々考えられるが、図５は機械学習モジュールを用いた具体的な実装の一例である。
ＡＰＩ（Application Programming Interface）モジュール５０１は、ユーザ端末１０２からの要約生成のリクエストを受け取り、文書情報を取得して、要約生成処理を開始する。また、ＡＰＩモジュール５０１は、生成された要約を、Ｗｅｂサーバモジュール５０５を介してユーザ端末１０２に送信する。ＡＰＩモジュール５０１は独立したＡＰＩサーバで実装してもよい。
要約生成モジュール２１４の実装の方法は色々考えられるが、図５は機械学習モジュールを用いた具体的な実装の一例である。
ＡＰＩ（Application Programming Interface）モジュール５０１は、ユーザ端末１０２からの要約生成のリクエストを受け取り、文書情報を取得して、要約生成処理を開始する。また、ＡＰＩモジュール５０１は、生成された要約を、Ｗｅｂサーバモジュール５０５を介してユーザ端末１０２に送信する。ＡＰＩモジュール５０１は独立したＡＰＩサーバで実装してもよい。
【0033】
メッセージキューイングモジュール５０２は、文書情報をキューに一時的に格納し、順次ＭＬモジュール５０３に入力する。
ＭＬ（機械学習：Machine Learning）モジュールは、キューに溜まっている文書情報を取得し、要約を生成し、キューに渡す。ＭＬモジュール５０３は独立したＭＬサーバで実装してもよい。
ワーカーモジュール５０４は、メッセージキューイングモジュール５０２から受け取った要約を文書ＩＤと対応付けてＤＢ５１１に格納する。
Ｗｅｂサーバモジュール５０５は、要約結果等をＵＩ（User Interface）として表示する。
記憶装置５１２には機械学習の学習済みモデルが複数格納されており、ＭＬモジュール５０３に読み込まれることで、生成される要約の内容を変更することができる。
図５の要約生成モジュール２１４による詳細な要約生成処理フローは、図１７で後述する。
ＭＬ（機械学習：Machine Learning）モジュールは、キューに溜まっている文書情報を取得し、要約を生成し、キューに渡す。ＭＬモジュール５０３は独立したＭＬサーバで実装してもよい。
ワーカーモジュール５０４は、メッセージキューイングモジュール５０２から受け取った要約を文書ＩＤと対応付けてＤＢ５１１に格納する。
Ｗｅｂサーバモジュール５０５は、要約結果等をＵＩ（User Interface）として表示する。
記憶装置５１２には機械学習の学習済みモデルが複数格納されており、ＭＬモジュール５０３に読み込まれることで、生成される要約の内容を変更することができる。
図５の要約生成モジュール２１４による詳細な要約生成処理フローは、図１７で後述する。
【0034】
図６～図１３は、管理サーバ１０１に記憶されている各種情報である。
図６は、顧客情報６００の例である。
顧客情報６００は、コールセンターに電話をしてきた顧客に関する情報を記憶する。
顧客情報６００は、ユーザＩＤ６０１、ユーザ表示、名前、電話番号、メールアドレス、生年月日、性別、住所等の顧客を特定する情報を有しており、それぞれの項目６１０に対してサンプル値６２０で例示するような値が入力されている。
ユーザＩＤ６０１は、自動的に生成されるハッシュ値などのユニークなＩＤであり、他の情報から参照される主キーである。
ユーザ表示（ユーザタイトル、ユーザ表示名と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３等の画面に表示するユーザ名である。
図６は、顧客情報６００の例である。
顧客情報６００は、コールセンターに電話をしてきた顧客に関する情報を記憶する。
顧客情報６００は、ユーザＩＤ６０１、ユーザ表示、名前、電話番号、メールアドレス、生年月日、性別、住所等の顧客を特定する情報を有しており、それぞれの項目６１０に対してサンプル値６２０で例示するような値が入力されている。
ユーザＩＤ６０１は、自動的に生成されるハッシュ値などのユニークなＩＤであり、他の情報から参照される主キーである。
ユーザ表示（ユーザタイトル、ユーザ表示名と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３等の画面に表示するユーザ名である。
【0035】
図７は、カテゴリ情報７００の例である。
カテゴリ情報７００は、顧客応対の内容に従って選択される情報であり、顧客応対の内容を示す情報を記憶する。
カテゴリ情報７００は、カテゴリＩＤ７０１、サブカテゴリＩＤ７０２、サブカテゴリＩＤ２ ７０３、サブカテゴリ内容７０４、サブカテゴリ内容７０５、サブカテゴリ内容２ ７０６を有しており、それぞれの項目７１０に対してサンプル値７２０で例示するような値が入力されている。
カテゴリＩＤ７０１、サブカテゴリＩＤ７０２、サブカテゴリＩＤ２ ７０３は、これら単独で、若しくは組み合わせて顧客応答の内容を一意に特定するＩＤである。
カテゴリ情報７００は、顧客応対の内容に従って選択される情報であり、顧客応対の内容を示す情報を記憶する。
カテゴリ情報７００は、カテゴリＩＤ７０１、サブカテゴリＩＤ７０２、サブカテゴリＩＤ２ ７０３、サブカテゴリ内容７０４、サブカテゴリ内容７０５、サブカテゴリ内容２ ７０６を有しており、それぞれの項目７１０に対してサンプル値７２０で例示するような値が入力されている。
カテゴリＩＤ７０１、サブカテゴリＩＤ７０２、サブカテゴリＩＤ２ ７０３は、これら単独で、若しくは組み合わせて顧客応答の内容を一意に特定するＩＤである。
【0036】
図７の例では、カテゴリＩＤ７０１のBridal001はウェディング関連のカテゴリ内容７０４を示し、サブカテゴリＩＤ７０２のCeremony001は結婚式場関連のサブカテゴリ内容７０５を示し、サブカテゴリＩＤ２ ７０３のInquiry002は問合せに関するサブカテゴリ内容２ ７０６を示す。
この例では、例えばウェディングというカテゴリの下には、結婚式場関連のサブカテゴリの他に、披露パーティー、新婚旅行等のサブカテゴリが存在する。
また、結婚式場関連のサブカテゴリの下には問合せの他に、申込みというサブサブカテゴリが存在する。
この例では、例えばウェディングというカテゴリの下には、結婚式場関連のサブカテゴリの他に、披露パーティー、新婚旅行等のサブカテゴリが存在する。
また、結婚式場関連のサブカテゴリの下には問合せの他に、申込みというサブサブカテゴリが存在する。
【0037】
他の例では、例えば保険というカテゴリの下には、損害保険、生命保険、学資保険、自動車保険、火災保険等のサブカテゴリが存在する。
また、損害保険のサブカテゴリの下には、問合せ、申込み、保険請求等のサブサブカテゴリが存在する。
このように、カテゴリ情報を階層的に設計することで、様々な種類の顧客応対処理に対して柔軟に対応することが可能となる。
また、損害保険のサブカテゴリの下には、問合せ、申込み、保険請求等のサブサブカテゴリが存在する。
このように、カテゴリ情報を階層的に設計することで、様々な種類の顧客応対処理に対して柔軟に対応することが可能となる。
【0038】
なお、図７の例では、カテゴリが３階層の構造であったが、２階層にしてもよいし、４階層以上の構成にしてもよい。また階層を設けずに全てのカテゴリをカテゴリＩＤの１階層のみで管理する仕組みにしてもよい。
また、ウェディング、結婚式場関連、問合せの順で下の階層になる構成により説明したが、この順番は入れ替わってもよく、例えば問合せ、ウェディング、結構式場関連、の順で階層が下がって行く構成に入れ替えてもよい。
また、ウェディング、結婚式場関連、問合せの順で下の階層になる構成により説明したが、この順番は入れ替わってもよく、例えば問合せ、ウェディング、結構式場関連、の順で階層が下がって行く構成に入れ替えてもよい。
【0039】
図８は、文書情報８００の例である。
文書情報８００は、例えば、顧客応対により取得された文書に関する情報を記憶する。
文書情報８００は、文書ＩＤ８０１、文書表示８０２、記録日時８０３、文書情報格納ＵＲＬ８０４を有しており、それぞれの項目８１０に対してサンプル値８２０で例示するような値が入力されている。
文書情報８００は、例えば、顧客応対により取得された文書に関する情報を記憶する。
文書情報８００は、文書ＩＤ８０１、文書表示８０２、記録日時８０３、文書情報格納ＵＲＬ８０４を有しており、それぞれの項目８１０に対してサンプル値８２０で例示するような値が入力されている。
【0040】
文書ＩＤ８０１は、格納されている文書を一意に特定する識別情報である。
文書表示８０２（文書タイトル８０２、文書表示名８０２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示される文書のタイトル等の説明を記憶する。
記録日時８０３は、文書が記憶装置に記憶された日時を示す。図８の例の「20220401141201」は「2022年4月1日14時12分01秒」を示す。
また文書がアップデートされる場合には、文書の更新日時や最終更新日時を併せて記憶してもよい。
文書情報格納ＵＲＬ８０４は、実際の文書が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。
また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。
文書表示８０２（文書タイトル８０２、文書表示名８０２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示される文書のタイトル等の説明を記憶する。
記録日時８０３は、文書が記憶装置に記憶された日時を示す。図８の例の「20220401141201」は「2022年4月1日14時12分01秒」を示す。
また文書がアップデートされる場合には、文書の更新日時や最終更新日時を併せて記憶してもよい。
文書情報格納ＵＲＬ８０４は、実際の文書が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。
また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。
【0041】
なお、本実施例では、文書情報８００の文書情報格納ＵＲＬ８０４に記憶されている文書の情報自体を「文書情報」と呼ぶこともある。例えば、文書情報格納ＵＲＬ８０４に記憶されているテキストデータを「文書情報」と呼ぶこともある。
また、文書情報８００に格納される前のテキストデータを「文書情報」と呼ぶこともある。
また、文書情報８００に格納される前のテキストデータを「文書情報」と呼ぶこともある。
【0042】
なお、ここに格納されるテキストデータとしては、例えば顧客応対により顧客とオペレータとの間にかわされた会話内容をテキスト化したものである対話文（対話テキスト）を記憶する。その他、チャット、メール、問合せフォーム、メッセージ送受信サービス等による顧客とのやり取りの場合には、送受信されるテキストの内容を、文書情報として記憶する。その他、顧客との応対内容に関して何等かの文書情報を取得し記憶すればよい。
また、広くコールセンター以外の業務に本実施例を適用する場合には、何らかの文書情報を取得し記憶すればよい。顧客応対には様々な呼び方があるが、例えばサポート、問い合わせ、カスタマーサクセス、ＣＸ（Customer Experience）、コンタクトセンター等がある。
また、広くコールセンター以外の業務に本実施例を適用する場合には、何らかの文書情報を取得し記憶すればよい。顧客応対には様々な呼び方があるが、例えばサポート、問い合わせ、カスタマーサクセス、ＣＸ（Customer Experience）、コンタクトセンター等がある。
【0043】
図９は、要約情報９００の例である。
要約情報９００は、要約生成モジュール２１４が生成した要約を記憶する。
要約情報９００は、要約ＩＤ９０１、要約表示９０２、文書ＩＤ９０３、記録日時９０４、最終更新日時９０５、要約情報格納ＵＲＬ９０６を有しており、それぞれの項目９１０に対してサンプル値９２０で例示するような値が入力されている。
要約情報９００は、要約生成モジュール２１４が生成した要約を記憶する。
要約情報９００は、要約ＩＤ９０１、要約表示９０２、文書ＩＤ９０３、記録日時９０４、最終更新日時９０５、要約情報格納ＵＲＬ９０６を有しており、それぞれの項目９１０に対してサンプル値９２０で例示するような値が入力されている。
【0044】
要約ＩＤ９０１は、格納されている要約を一意に特定する識別情報である。
要約表示９０２（要約タイトル９０２、要約表示名９０２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示される要約のタイトル等の説明を記憶する。
文書ＩＤ９０３には、文書情報８００の文書ＩＤ８０１の値が記憶され、要約がどの文書情報８００に対応する要約なのかを特定する。
記録日時９０４は、要約が記憶装置に記憶された日時を示す。
要約表示９０２（要約タイトル９０２、要約表示名９０２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示される要約のタイトル等の説明を記憶する。
文書ＩＤ９０３には、文書情報８００の文書ＩＤ８０１の値が記憶され、要約がどの文書情報８００に対応する要約なのかを特定する。
記録日時９０４は、要約が記憶装置に記憶された日時を示す。
【0045】
最終更新日時９０５は、要約が修正された後の、最終的な更新日時を示す。なお、最終更新日時だけでなく、複数回更新される場合の要約の更新日時を併せて記憶してもよい。
要約情報格納ＵＲＬ９０６は、実際の要約が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。
なお本実施例では、１つの要約ＩＤ９０１で特定される要約に対して、複数回の更新を行った場合に、その要約の更新履歴若しくは全てのバージョンの要約を同じ要約ＩＤ９０１に対応付けて記憶することができる。一方、更新のたびに新しい要約ＩＤを振り直して要約の記憶をする構成でもよい。
要約情報格納ＵＲＬ９０６は、実際の要約が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。
なお本実施例では、１つの要約ＩＤ９０１で特定される要約に対して、複数回の更新を行った場合に、その要約の更新履歴若しくは全てのバージョンの要約を同じ要約ＩＤ９０１に対応付けて記憶することができる。一方、更新のたびに新しい要約ＩＤを振り直して要約の記憶をする構成でもよい。
【0046】
図１０は、メモ情報１０００の例である。
メモ情報１０００は、メモＩＤ１００１、メモ表示１００２、文書ＩＤ１００３、記録日時１００４、最終更新日時１００５、メモ情報格納ＵＲＬ１００６を有しており、それぞれの項目１０１０に対してサンプル値１０２０で例示するような値が入力されている。
メモＩＤ１００１は、格納されているメモ情報を一意に特定する識別情報である。
メモ表示１００２（メモタイトル１００２、メモ表示名１００２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示されるメモ情報のタイトル等の説明を記憶する。
文書ＩＤ１００３には、文書情報８００の文書ＩＤ８０２の値が記憶され、メモ情報がどの文書情報８００に対応するメモなのかを特定する。
記録日時１００４は、メモ情報が記憶装置に記憶された日時を示す。
メモ情報１０００は、メモＩＤ１００１、メモ表示１００２、文書ＩＤ１００３、記録日時１００４、最終更新日時１００５、メモ情報格納ＵＲＬ１００６を有しており、それぞれの項目１０１０に対してサンプル値１０２０で例示するような値が入力されている。
メモＩＤ１００１は、格納されているメモ情報を一意に特定する識別情報である。
メモ表示１００２（メモタイトル１００２、メモ表示名１００２と呼ぶこともある）は、ユーザ端末１０２や管理者端末１０３に表示されるメモ情報のタイトル等の説明を記憶する。
文書ＩＤ１００３には、文書情報８００の文書ＩＤ８０２の値が記憶され、メモ情報がどの文書情報８００に対応するメモなのかを特定する。
記録日時１００４は、メモ情報が記憶装置に記憶された日時を示す。
【0047】
最終更新日時１００５は、メモ情報が修正された後の、最終的な更新日時を示す。なお、最終更新日時だけでなく、複数回更新される場合のメモ情報の更新日時を併せて記憶してもよい。
メモ情報格納ＵＲＬ１００６は、実際のメモ情報が格納される場所を示す。
なお本実施例では、１つのメモＩＤ１００１で特定されるメモ情報に対して、複数回の更新を行った場合に、その更新履歴を同じメモＩＤ１００１に対応付けて記憶することが可能で、また、更新のたびに新しいメモＩＤを振り直す構成でもよい。
メモ情報格納ＵＲＬ１００６は、実際のメモ情報が格納される場所を示す。
なお本実施例では、１つのメモＩＤ１００１で特定されるメモ情報に対して、複数回の更新を行った場合に、その更新履歴を同じメモＩＤ１００１に対応付けて記憶することが可能で、また、更新のたびに新しいメモＩＤを振り直す構成でもよい。
【0048】
図１１は、応対記録情報１１００の例である。
ユーザが顧客応対を実施した際の応対内容を応対記録として記憶する。
応対記録情報１１００は、応対ＩＤ１１０１、応対開始日時１１０２，応対終了日時１１０３、担当者１１０４、顧客ＩＤ１１０５、カテゴリＩＤ１１０６、要約ＩＤ１１０７、評価点１１０８、顧客入力データ格納ＵＲＬ１１０９を有しており、それぞれの項目１１１０に対してサンプル値１１２０で例示するような値が入力されている。
ユーザが顧客応対を実施した際の応対内容を応対記録として記憶する。
応対記録情報１１００は、応対ＩＤ１１０１、応対開始日時１１０２，応対終了日時１１０３、担当者１１０４、顧客ＩＤ１１０５、カテゴリＩＤ１１０６、要約ＩＤ１１０７、評価点１１０８、顧客入力データ格納ＵＲＬ１１０９を有しており、それぞれの項目１１１０に対してサンプル値１１２０で例示するような値が入力されている。
【0049】
応対ＩＤ１１０１は、顧客応対を一意に特定する識別情報である。
応対開始日時１１０２及び応対終了日時１１０３は、顧客応対が始まった日時及び終了した日時を示す。
担当者１１０４は、顧客応対を行ったユーザ（オペレータ）を特定する情報を記憶する。
顧客ＩＤは、応対した顧客を特定する情報を記憶する。
応対開始日時１１０２及び応対終了日時１１０３は、顧客応対が始まった日時及び終了した日時を示す。
担当者１１０４は、顧客応対を行ったユーザ（オペレータ）を特定する情報を記憶する。
顧客ＩＤは、応対した顧客を特定する情報を記憶する。
【0050】
カテゴリＩＤ１１０６は、顧客応対の内容を示す情報であり、図７のカテゴリ情報７００のカテゴリＩＤ７０１が記憶される。なお、カテゴリＩＤ１１０６の下位にあるサブカテゴリＩＤやサブカテゴリＩＤ２にはそれぞれ図７のサブカテゴリＩＤ７０２やサブカテゴリＩＤ２ ７０３の情報が記憶される。
要約ＩＤ１１０７は、図９の要約ＩＤ９０１の情報が記憶され、顧客応答によりどのような要約が生成されたかを対応付けて記憶する。
要約ＩＤ１１０７は、図９の要約ＩＤ９０１の情報が記憶され、顧客応答によりどのような要約が生成されたかを対応付けて記憶する。
【0051】
評価点１１０８は、生成された要約に対するユーザや管理者からの評価点を記憶する。なお、評価点１１０８は、応対記録情報１１００ではなく、要約情報９００に記憶する構成としてもよい。
顧客入力データ格納ＵＲＬ１１０９は、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶する。例えば、顧客からの申し込みに対する応対の場合には、その結果である申し込みについての情報が顧客入力データ格納ＵＲＬ１１０９に記載されている。
顧客入力データ格納ＵＲＬ１１０９は、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶する。例えば、顧客からの申し込みに対する応対の場合には、その結果である申し込みについての情報が顧客入力データ格納ＵＲＬ１１０９に記載されている。
【0052】
図１２は、ＦＡＱ情報１２００の例である。
ＦＡＱ情報１２００には、よく聞かれる質問とその回答の一覧が記憶されている。
ＦＡＱ情報１２００は、ＦＡＱＩＤ１２０１、概要，カテゴリＩＤ１２０２、サブカテゴリＩＤ、ＦＡＱデータ格納ＵＲＬ１２０３を有しており、それぞれの項目１２１０に対してサンプル値１２２０で例示するような値が入力されている。
ＦＡＱ情報１２００には、よく聞かれる質問とその回答の一覧が記憶されている。
ＦＡＱ情報１２００は、ＦＡＱＩＤ１２０１、概要，カテゴリＩＤ１２０２、サブカテゴリＩＤ、ＦＡＱデータ格納ＵＲＬ１２０３を有しており、それぞれの項目１２１０に対してサンプル値１２２０で例示するような値が入力されている。
【0053】
ＦＡＱＩＤ１２０１は、ＦＡＱを一意に特定する識別情報である。
概要は、ＦＡＱのタイトルなど、内容を示す情報を記憶する。
ＦＡＱデータ格納ＵＲＬ１２０３は、実際のＦＡＱの内容が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。ＦＡＱのデータとしては例えば、質問と回答を別カラムとした文章情報を格納することができる。
概要は、ＦＡＱのタイトルなど、内容を示す情報を記憶する。
ＦＡＱデータ格納ＵＲＬ１２０３は、実際のＦＡＱの内容が格納される場所を示す。なお、ＵＲＬの形でデータまでのパスを指定する方法の他、サーバ内部のストレージ中のファイル等へのパスを指定する方法でもよい。また、データサイズが大きくない場合等には、直接情報を書き込んでもよい。ＦＡＱのデータとしては例えば、質問と回答を別カラムとした文章情報を格納することができる。
【0054】
カテゴリＩＤ１２０２は、顧客応対の内容を示す情報であり、図７のカテゴリ情報７００のカテゴリＩＤ７０１が記憶される。なお、カテゴリＩＤ１２０２の下位にあるサブカテゴリＩＤやサブカテゴリＩＤ２にはそれぞれ図７のサブカテゴリＩＤ７０２やサブカテゴリＩＤ２ ７０３の情報が記憶される。
このようにＦＡＱ情報１２００に対して、顧客応対のカテゴリを特定して記憶することで、顧客応対のカテゴリに関連するＦＡＱ情報を取得し、ユーザ端末１０２等に表示することができる。
このようにＦＡＱ情報１２００に対して、顧客応対のカテゴリを特定して記憶することで、顧客応対のカテゴリに関連するＦＡＱ情報を取得し、ユーザ端末１０２等に表示することができる。
【0055】
図１３は、入力補助情報１３００の例である。
入力補助情報１３００には、顧客応対の際に、顧客毎に入力する入力内容を呼び出すための入力補助情報を記憶する。
入力補助情報１３００は、入力補助情報ＩＤ１３０１、概要，カテゴリＩＤ１３０２、サブカテゴリＩＤ、入力内容格納ＵＲＬ１３０３を有しており、それぞれの項目１３１０に対してサンプル値１３２０で例示するような値が入力されている。
入力補助情報ＩＤ１３０１は、入力すべきフォームなどの入力補助情報を一意に特定する識別情報である。
概要は、入力補助情報のタイトルなど、内容を示す情報を記憶する。
入力補助情報１３００には、顧客応対の際に、顧客毎に入力する入力内容を呼び出すための入力補助情報を記憶する。
入力補助情報１３００は、入力補助情報ＩＤ１３０１、概要，カテゴリＩＤ１３０２、サブカテゴリＩＤ、入力内容格納ＵＲＬ１３０３を有しており、それぞれの項目１３１０に対してサンプル値１３２０で例示するような値が入力されている。
入力補助情報ＩＤ１３０１は、入力すべきフォームなどの入力補助情報を一意に特定する識別情報である。
概要は、入力補助情報のタイトルなど、内容を示す情報を記憶する。
【0056】
カテゴリＩＤ１３０２は、顧客応対の内容を示す情報であり、図７のカテゴリ情報７００のカテゴリＩＤ７０１が記憶される。なお、カテゴリＩＤ１３０２の下位にあるサブカテゴリＩＤやサブカテゴリＩＤ２にはそれぞれ図７のサブカテゴリＩＤ７０２やサブカテゴリＩＤ２ ７０３の情報が記憶される。
このように入力補助情報１３００に対して、顧客応対のカテゴリを特定して記憶することで、顧客応対のカテゴリに関連する入力補助情報を取得し、ユーザ端末１０２等に表示することができる。
このように入力補助情報１３００に対して、顧客応対のカテゴリを特定して記憶することで、顧客応対のカテゴリに関連する入力補助情報を取得し、ユーザ端末１０２等に表示することができる。
【0057】
図１４は、顧客応対処理フロー１４００の例である。
顧客応対処理モジュール２１１は、顧客応対を開始する（ステップ１４１０）。具体的にはオペレータ（ユーザ）が電話を受け顧客応対を開始した場合に、その旨が通知される構成でもよいし、オペレータが顧客応対を開始した旨を入力する構成でもよい。
文書情報取得モジュール２１３は、通話している間、通話内容をテキスト化し、文書情報を取得する（ステップ１４２０）。テキスト化された通話内容は、対話テキストと呼ぶこともある。文書情報取得処理については後述する。
顧客応対処理モジュール２１１は、顧客応対を開始する（ステップ１４１０）。具体的にはオペレータ（ユーザ）が電話を受け顧客応対を開始した場合に、その旨が通知される構成でもよいし、オペレータが顧客応対を開始した旨を入力する構成でもよい。
文書情報取得モジュール２１３は、通話している間、通話内容をテキスト化し、文書情報を取得する（ステップ１４２０）。テキスト化された通話内容は、対話テキストと呼ぶこともある。文書情報取得処理については後述する。
【0058】
次に、顧客応対処理モジュール２１１は、通話の相手方の顧客を特定する（ステップ１４３０）。
具体的には、顧客応対処理モジュール２１１が、データ検索モジュール２１８を呼び出し、データ検索モジュール２１８が、図２１の顧客情報検索画面２１００の顧客検索欄２１４０の内容を表示する。
オペレータは、通話の内容や対話テキストを見ながら顧客情報を検索し、該当する顧客が見つかった場合には、その顧客を通話相手として特定する。該当する顧客が見つからず、新規顧客登録する場合については後述する。
具体的には、顧客応対処理モジュール２１１が、データ検索モジュール２１８を呼び出し、データ検索モジュール２１８が、図２１の顧客情報検索画面２１００の顧客検索欄２１４０の内容を表示する。
オペレータは、通話の内容や対話テキストを見ながら顧客情報を検索し、該当する顧客が見つかった場合には、その顧客を通話相手として特定する。該当する顧客が見つからず、新規顧客登録する場合については後述する。
【0059】
図２１は、顧客情報検索画面２１００の例である。
対話テキスト欄２１１０には、文書情報取得処理１４２０でテキスト化された通話内容がほぼリアルタイムに表示される。
メモ欄２１２０は、顧客応答の際にオペレータがメモを入力する部分である。ここに記入されて取得されるメモ情報を第２の文書情報と呼ぶこともある。
対話テキスト欄２１１０には、文書情報取得処理１４２０でテキスト化された通話内容がほぼリアルタイムに表示される。
メモ欄２１２０は、顧客応答の際にオペレータがメモを入力する部分である。ここに記入されて取得されるメモ情報を第２の文書情報と呼ぶこともある。
【0060】
顧客検索欄２１４０は、オペレータが顧客を検索するためのキーワードを入力し、顧客情報６００に登録されている顧客情報を検索するための表示領域である。
顧客応対処理モジュール２１１は、応答している顧客の電話番号の情報を取得し、着信情報２１４１に表示する。なお、オペレータが電話機に表示されている電話番号を着信情報２１４１に入力する構成でもよい。
顧客応対処理モジュール２１１は、応答している顧客の電話番号の情報を取得し、着信情報２１４１に表示する。なお、オペレータが電話機に表示されている電話番号を着信情報２１４１に入力する構成でもよい。
【0061】
顧客情報の特定の方法としては、例えば、
・顧客応対処理モジュール２１１が、電話番号から自動で顧客情報を入力する。
・オペレータが検索して選択することで顧客情報を入力する。
・オペレータが手動で入力する。
ということが考えられる。
・顧客応対処理モジュール２１１が、電話番号から自動で顧客情報を入力する。
・オペレータが検索して選択することで顧客情報を入力する。
・オペレータが手動で入力する。
ということが考えられる。
【0062】
一方、対話テキストの内容から顧客応対処理モジュール２１１が入力を補助する構成とすることもできる。たとえば、顧客応対処理モジュール２１１は、対話テキスト欄２１１０に表示された対話文の中で人名に関する情報２１１１、２１１２のうち、顧客である可能性の高い名前の情報２１１１を検索条件２１４２の氏名欄に入力することができる。例えば顧客の発した言葉のうち、一番最初に登場する氏名情報２１１１を氏名欄に入力する。なお、オペレータが応対で聞いた顧客の氏名を検索条件２１４２の氏名欄に入力する構成でもよい。
なお、顧客応対処理モジュール２１１が、対話テキストから固有表現を抽出し、そこから推測して顧客情報を入力する事もできる。たとえば、対話テキストに表示された氏名や電話番号、内容などから、辞書等を用いたルールベース、又は機械学習ベースの技術により、顧客情報を推測し、入力することができる。
なお、顧客応対処理モジュール２１１が、対話テキストから固有表現を抽出し、そこから推測して顧客情報を入力する事もできる。たとえば、対話テキストに表示された氏名や電話番号、内容などから、辞書等を用いたルールベース、又は機械学習ベースの技術により、顧客情報を推測し、入力することができる。
【0063】
その他、検索条件２１４２として、氏名、生年月日、電話番号、郵便番号等、顧客に関する情報の入力を受け付けることもできる。
管理サーバ１０１の強調表示モジュール２１６は、対話テキスト欄２１１０に表示された対話テキストのうち、名前、日付、時間、電話番号、場所、契約番号等の顧客検索にとって重要そうな属性に関する箇所をハイライト表示する。また、強調表示モジュール２１６は、ハイライトされた内容のうち、検索条件２１４２に対応する項目がある場合には、該当箇所に対応する名前、電話番号等を入力し、補完を行う。
また、逆に、オペレータが電話により聞き取った氏名、電話番号等の情報を検索条件２１４２に記入した場合に、強調表示モジュール２１６が、これに対応する部分を対話テキストの中でハイライト表示することもできる。
管理サーバ１０１の強調表示モジュール２１６は、対話テキスト欄２１１０に表示された対話テキストのうち、名前、日付、時間、電話番号、場所、契約番号等の顧客検索にとって重要そうな属性に関する箇所をハイライト表示する。また、強調表示モジュール２１６は、ハイライトされた内容のうち、検索条件２１４２に対応する項目がある場合には、該当箇所に対応する名前、電話番号等を入力し、補完を行う。
また、逆に、オペレータが電話により聞き取った氏名、電話番号等の情報を検索条件２１４２に記入した場合に、強調表示モジュール２１６が、これに対応する部分を対話テキストの中でハイライト表示することもできる。
【0064】
データ検索モジュール２１８は、オペレータが検索ボタン２１４３を選択したことを検知すると、着信情報２１４１や検索条件２１４２に入力された情報で顧客情報６００を検索し、対応するレコードが存在するかを確認する。顧客情報６００に対応するレコードがあった場合には、データ検索モジュール２１８は、図２２の顧客情報照会画面２２００を表示する。
【0065】
なお、顧客情報表示欄２１５０には、顧客情報６００に登録されている顧客情報が表示されており、検索により顧客の情報が発見された場合には、顧客情報表示欄２１５０の中で発見された顧客情報を表示して、強調表示する構成としてもよい。
顧客情報６００の中に対応する顧客情報が見つからなかった場合には、顧客応対処理モジュール２１１は、新規顧客登録ボタン２１６０の選択を受け付け、着信情報２１４１や検索条件欄２１４２に記入された情報を引き継ぎ、新規の顧客情報の登録画面を表示する。新規顧客登録についても、対話テキストから補完する機能、および補完された部分を対話テキストの中でハイライトする機能を備えていてもよい。
なお、本実施例ではデータ検索モジュール２１８が、顧客情報６００から取得した情報を顧客検索欄２１４０に表示するが、この表示を全て顧客応対処理モジュール２１１が行うようにしてもよい。
顧客情報６００の中に対応する顧客情報が見つからなかった場合には、顧客応対処理モジュール２１１は、新規顧客登録ボタン２１６０の選択を受け付け、着信情報２１４１や検索条件欄２１４２に記入された情報を引き継ぎ、新規の顧客情報の登録画面を表示する。新規顧客登録についても、対話テキストから補完する機能、および補完された部分を対話テキストの中でハイライトする機能を備えていてもよい。
なお、本実施例ではデータ検索モジュール２１８が、顧客情報６００から取得した情報を顧客検索欄２１４０に表示するが、この表示を全て顧客応対処理モジュール２１１が行うようにしてもよい。
【0066】
図２２は、顧客情報照会画面２２００の例である。
データ検索モジュール２１８は、顧客紹介欄２２４０に検索により見つかった顧客情報２２４１を表示する。
強調表示モジュール２１６は、表示された顧客情報２２４１に表示された顧客情報に対応する情報を、対話テキスト欄２２１０の対話テキスト上でハイライトする。
このような構成とすることで、検索で見つかった顧客情報や、新規登録する顧客情報が、対話テキストの中でどこに記載されているかを容易に確認することができる。
データ検索モジュール２１８は、顧客紹介欄２２４０に検索により見つかった顧客情報２２４１を表示する。
強調表示モジュール２１６は、表示された顧客情報２２４１に表示された顧客情報に対応する情報を、対話テキスト欄２２１０の対話テキスト上でハイライトする。
このような構成とすることで、検索で見つかった顧客情報や、新規登録する顧客情報が、対話テキストの中でどこに記載されているかを容易に確認することができる。
【0067】
顧客応対処理モジュール２１１は、検索や新規登録によって特定された通話相手の顧客に対応する顧客ＩＤを記憶する。なお、ユーザによる検索を行わず、データ検索モジュール２１８が、着信した電話番号や、対話テキストから抽出された人名等に基づき、顧客情報６００を検索して、顧客を特定する構成とすることもできる。
またデータ検索モジュール２１８が、候補となる顧客名等を表示し、ユーザが確認の入力を行うことで、顧客が特定される構成とすることもできる。
またデータ検索モジュール２１８が、候補となる顧客名等を表示し、ユーザが確認の入力を行うことで、顧客が特定される構成とすることもできる。
【0068】
図３２は、要約生成指示画面３２００の例である。
顧客応対処理モジュール２１１は、要約スタートボタン３２３５が押されたことを検知すると、要約生成モジュール２１４に文書情報である対話テキストを送信し、要約生成モジュール２１４が要約生成処理を実行する（ステップ１４４０）。
具体的な要約生成処理は、図１６又は図１７で詳述する。
顧客応対処理モジュール２１１は、要約スタートボタン３２３５が押されたことを検知すると、要約生成モジュール２１４に文書情報である対話テキストを送信し、要約生成モジュール２１４が要約生成処理を実行する（ステップ１４４０）。
具体的な要約生成処理は、図１６又は図１７で詳述する。
【0069】
図３３は、要約表示画面３３００の例である。要約生成モジュール２１４により生成された要約が表示される。
表示された要約文３３３０の例では、お客様名３３３２や、応対者名３３３１が強調表示されており、また、生成された要約上重要な事項３３３３が強調表示されている。図３２及び図３３は、入力される文書情報と、それから生成された要約を１パネルでそれぞれ表示する例であるが、これらを１つのウィンドウ内に２パネルで表示する構成であってもよい。また、１つのウィンドウ内に１つのパネルのみ表示した図３２と図３３を横または上下に並べて表示する構成であってもよい。
表示された要約文３３３０の例では、お客様名３３３２や、応対者名３３３１が強調表示されており、また、生成された要約上重要な事項３３３３が強調表示されている。図３２及び図３３は、入力される文書情報と、それから生成された要約を１パネルでそれぞれ表示する例であるが、これらを１つのウィンドウ内に２パネルで表示する構成であってもよい。また、１つのウィンドウ内に１つのパネルのみ表示した図３２と図３３を横または上下に並べて表示する構成であってもよい。
【0070】
顧客応対処理モジュール２１１は、要約生成モジュール２１４により生成された要約と、顧客応対の内容とを対応付けて応対記録情報１１００に記憶する（ステップ１４５０）。
具体的には、顧客応対処理モジュール２１１は、顧客応答毎に、応対ＩＤ１１０１を生成し、応対した担当者の担当者ＩＤと、ステップ１４３０で特定された顧客を示す顧客ＩＤと、ステップ１４４０で生成された要約を示す要約ＩＤと、応対開始日時と応対終了日時と、を対応付けて応対記録情報１１００に記憶する。
具体的には、顧客応対処理モジュール２１１は、顧客応答毎に、応対ＩＤ１１０１を生成し、応対した担当者の担当者ＩＤと、ステップ１４３０で特定された顧客を示す顧客ＩＤと、ステップ１４４０で生成された要約を示す要約ＩＤと、応対開始日時と応対終了日時と、を対応付けて応対記録情報１１００に記憶する。
【0071】
フィードバックモジュール２１７が、要約に対する評価を受け付けた場合には、この評価の情報も併せて記憶することができる。
さらに、顧客応対により、申し込み等が発生した場合には、その申し込み等の手続に対する入力データをＣＲＭシステム等に反映することもできる。このような場合には、応対記録情報１１００の顧客入力データ格納ＵＲＬ１１０９に、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶することができる。
オペレータが要約に修正を加えた場合や、メモを更新した場合、等には、その変更履歴が応対記録情報１１００や、要約情報９００、メモ情報１０００等に記憶されてもよい。
さらに、顧客応対により、申し込み等が発生した場合には、その申し込み等の手続に対する入力データをＣＲＭシステム等に反映することもできる。このような場合には、応対記録情報１１００の顧客入力データ格納ＵＲＬ１１０９に、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶することができる。
オペレータが要約に修正を加えた場合や、メモを更新した場合、等には、その変更履歴が応対記録情報１１００や、要約情報９００、メモ情報１０００等に記憶されてもよい。
【0072】
図３４は、カテゴリ情報を用いた顧客応対処理フロー３４００の例である。
図１４の顧客応対処理フロー１４００に対して、カテゴリ情報の選択を受け付けるステップ３４４０の処理が追加されている。
顧客応対処理モジュール２１１によるステップ３４１０～ステップ３４３０の処理は、図１４のステップ１４１０～１４３０と同様であるため説明を省略する。
図１４の顧客応対処理フロー１４００に対して、カテゴリ情報の選択を受け付けるステップ３４４０の処理が追加されている。
顧客応対処理モジュール２１１によるステップ３４１０～ステップ３４３０の処理は、図１４のステップ１４１０～１４３０と同様であるため説明を省略する。
【0073】
次に、顧客応対処理モジュール２１１は、図２３に示すカテゴリ選択入力画面２３００を表示し、オペレータから応対内容についてのカテゴリの選択を受け付ける（ステップ３４４０）。
カテゴリは顧客応対の内容を分類分けしたものであり、図７に示すカテゴリ情報７００に記憶されている。選択されたカテゴリに応じて、顧客応対処理モジュール２１１は、対応するカテゴリＩＤ、サブカテゴリＩＤ、サブカテゴリＩＤ２等のカテゴリを識別する情報を取得し、記憶する。なお、カテゴリ情報は前述の通り、ユーザ等が自由記述で記載したり、メタ情報をカテゴリ情報として、登録・追加・使用すること等もできる。
カテゴリは顧客応対の内容を分類分けしたものであり、図７に示すカテゴリ情報７００に記憶されている。選択されたカテゴリに応じて、顧客応対処理モジュール２１１は、対応するカテゴリＩＤ、サブカテゴリＩＤ、サブカテゴリＩＤ２等のカテゴリを識別する情報を取得し、記憶する。なお、カテゴリ情報は前述の通り、ユーザ等が自由記述で記載したり、メタ情報をカテゴリ情報として、登録・追加・使用すること等もできる。
【0074】
図２３は、カテゴリ選択入力画面２３００の例である。
問合せ内容入力欄２３５０には、案件区分、内容、対応方法というカテゴリを入力若しくは選択する欄が表示されている。
通話者区分は、申込者、配偶者、父親、母親、契約者、被保険者、見込み客、事故相手、ディーラー、金融機関、等、顧客がどのような人であるのかを特定するための情報である。なお、通話者区分をカテゴリとして取り扱ってもよい。
具体的には、顧客応対処理モジュール２１１が、カテゴリ選択モジュール２１２を呼び出し、カテゴリ選択モジュール２１２が、図２３のカテゴリ選択入力画面２３００の問合せ内容入力２３５０の内容を表示する。
問合せ内容入力欄２３５０には、案件区分、内容、対応方法というカテゴリを入力若しくは選択する欄が表示されている。
通話者区分は、申込者、配偶者、父親、母親、契約者、被保険者、見込み客、事故相手、ディーラー、金融機関、等、顧客がどのような人であるのかを特定するための情報である。なお、通話者区分をカテゴリとして取り扱ってもよい。
具体的には、顧客応対処理モジュール２１１が、カテゴリ選択モジュール２１２を呼び出し、カテゴリ選択モジュール２１２が、図２３のカテゴリ選択入力画面２３００の問合せ内容入力２３５０の内容を表示する。
【0075】
図２３の例では、顧客応対の内容に従って、カテゴリとして「ブライダル」、サブカテゴリとして「式場」、サブサブカテゴリとして「問合せ」が選択されている。顧客応対処理モジュール２１１は、カテゴリ選択の後に設定ボタン２３５２が押された場合に、これらのカテゴリに対応するＩＤとして、図７の例に示すカテゴリＩＤ７０１、サブカテゴリＩＤ７０２、サブカテゴリＩＤ２ ７０３を取得し記憶する。
【0076】
図２３の問合せ内容入力２３５０の「内容」「対応方法種別」は、選択される「案件区分」に応じて表示が変わる様になっている。例えば、案件区分として「保険」が選択された場合には、例えばこの保険のサブカテゴリである自動車保険と火災保険を示す「自動車」「火災」が表示されるようになる。
【0077】
なお、強調表示モジュール２１６は、対話テキスト欄２３１０の対話テキストの中で、カテゴリに関連するキーワードや文章などの文字列をハイライト表示することができる。
例えば図２３の例では、ブライダル、ハワイでの式、新郎新婦、と言ったブライダルに関連するキーワードがハイライトされている。オペレータはこのハイライトされた文字列を確認することで、顧客応対の内容がどのカテゴリに属しているのかを判断しやすくなり、カテゴリ選択を容易にする効果がある。
例えば図２３の例では、ブライダル、ハワイでの式、新郎新婦、と言ったブライダルに関連するキーワードがハイライトされている。オペレータはこのハイライトされた文字列を確認することで、顧客応対の内容がどのカテゴリに属しているのかを判断しやすくなり、カテゴリ選択を容易にする効果がある。
【0078】
また、カテゴリ情報７００に登録されているカテゴリに関連するキーワードや文章はあらかじめ登録しておく、若しくは都度関連するキーワードや文章を取得することができる。
カテゴリ選択モジュール２１２が、対話テキストの中のキーワードや文章を解析して、あらかじめカテゴリ情報７００に登録されているどのカテゴリに関連するのかを判断し、問合せ内容入力欄２３５０の入力を、対話テキストに表示されるキーワードや文章に応じて、自動的に選択できる。
また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリに分類することも可能である。
カテゴリ選択モジュール２１２が、対話テキストの中のキーワードや文章を解析して、あらかじめカテゴリ情報７００に登録されているどのカテゴリに関連するのかを判断し、問合せ内容入力欄２３５０の入力を、対話テキストに表示されるキーワードや文章に応じて、自動的に選択できる。
また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリに分類することも可能である。
【0079】
また、カテゴリ選択モジュール２１２と強調表示モジュール２１６が連携することで、例えばオペレータが対応方法種別として「申込み」を選択している場合には、対話テキストの中で「申込み」に関連するキーワード等がハイライトされ、対話方法種別を「問合せ」に切り替えると、対話テキストの中で「問合せ」に関連するキーワードがハイライトされるようにすることもできる。
同様に、案件区分がブライダルから保険に変更された場合には、保険に関するキーワードがハイライトされるようになる。
同様に、案件区分がブライダルから保険に変更された場合には、保険に関するキーワードがハイライトされるようになる。
【0080】
カテゴリ選択モジュール２１２と強調表示モジュール２１６が連携することで様々な実装が可能となるが、例えば、以下のようなことができるようになる。
カテゴリ選択モジュール２１２が、対話テキストの中で顧客応対の内容の分類であるカテゴリに関連するキーワードや文章等の文字列を抽出し、これに基づいてカテゴリを自動的に選択することができる。また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリに分類することも可能である。
カテゴリ選択モジュール２１２が、対話テキストの中で顧客応対の内容の分類であるカテゴリに関連するキーワードや文章等の文字列を抽出し、これに基づいてカテゴリを自動的に選択することができる。また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリに分類することも可能である。
【0081】
また、強調表示モジュール２１６が、対話テキストの中から、カテゴリに関するキーワードや文章等の文字列を強調表示し、カテゴリ選択モジュール２１２が、強調表示された文字列に基づいて、関連するカテゴリを自動的に選択することができる。
また、強調表示モジュール２１６は、カテゴリ内容の選択に応じて、カテゴリ内容に関連する文字列を強調表示することができる。カテゴリ内容の選択が変更された場合に、強調表示モジュール２１６が、変更後のカテゴリ内容に関連する文字列を強調表示することができる。
また、対話テキストの情報を入力し、文章全体からカテゴリを選択することも可能である。また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリを選択することも可能である。
また、強調表示モジュール２１６は、カテゴリ内容の選択に応じて、カテゴリ内容に関連する文字列を強調表示することができる。カテゴリ内容の選択が変更された場合に、強調表示モジュール２１６が、変更後のカテゴリ内容に関連する文字列を強調表示することができる。
また、対話テキストの情報を入力し、文章全体からカテゴリを選択することも可能である。また、対話テキストの情報を入力し、文章全体から辞書情報等を用いてルールベースで、又は、機械学習モデルを用いて、カテゴリを選択することも可能である。
【0082】
なお、本実施例ではカテゴリ選択モジュール２１２が、カテゴリ情報７００に記憶されているカテゴリ情報を取得し、これに基づいて問合せ内容入力欄２３５０に内容を表示するが、この表示を全て顧客応対処理モジュール２１１が行うようにしてもよい。
【0083】
顧客応対処理モジュール２１１は、カテゴリの選択の後、要約スタートボタン２３３５が押されたことを検知すると、要約生成モジュール２１４に文書情報である対話テキストを送信し、要約生成モジュール２１４が要約生成処理を実行する（ステップ３４５０）。
具体的な要約生成処理は、図１６又は図１７で詳述する。
なお、カテゴリの選択は必須ではなく、何もカテゴリが選択されなくても要約生成処理を実行してもよい。また、図２３のようなカテゴリ選択入力画面２３００を表示することなく、バックグラウンドで、カテゴリ選択モジュール２１２により文書情報の内容に基づいてカテゴリが自動選択される構成としてもよい。
具体的な要約生成処理は、図１６又は図１７で詳述する。
なお、カテゴリの選択は必須ではなく、何もカテゴリが選択されなくても要約生成処理を実行してもよい。また、図２３のようなカテゴリ選択入力画面２３００を表示することなく、バックグラウンドで、カテゴリ選択モジュール２１２により文書情報の内容に基づいてカテゴリが自動選択される構成としてもよい。
【0084】
顧客応対処理モジュール２１１は、要約生成モジュール２１４により生成された要約と、顧客応対の内容とを対応付けて応対記録情報１１００に記憶する（ステップ３４６０）。
具体的には、顧客応対処理モジュール２１１は、顧客応答毎に、応対ＩＤ１１０１を生成し、応対した担当者の担当者ＩＤと、ステップ３４３０で特定された顧客を示す顧客ＩＤと、ステップ３４４０で選択されたカテゴリを示すカテゴリＩＤ等と、ステップ３４５０で生成された要約を示す要約ＩＤと、応対開始日時と応対終了日時と、を対応付けて応対記録情報１１００に記憶する。
具体的には、顧客応対処理モジュール２１１は、顧客応答毎に、応対ＩＤ１１０１を生成し、応対した担当者の担当者ＩＤと、ステップ３４３０で特定された顧客を示す顧客ＩＤと、ステップ３４４０で選択されたカテゴリを示すカテゴリＩＤ等と、ステップ３４５０で生成された要約を示す要約ＩＤと、応対開始日時と応対終了日時と、を対応付けて応対記録情報１１００に記憶する。
【0085】
フィードバックモジュール２１７が、要約に対する評価を受け付けた場合には、この評価の情報も併せて記憶することができる。
さらに、顧客応対により、申し込み等が発生した場合には、その申し込み等の手続に対する入力データをＣＲＭシステム等に反映することもできる。このような場合には、応対記録情報１１００の顧客入力データ格納ＵＲＬ１１０９に、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶することができる。
オペレータが要約に修正を加えた場合や、メモを更新した場合、等には、その変更履歴が応対記録情報１１００や、要約情報９００、メモ情報１０００等に記憶されてもよい。
さらに、顧客応対により、申し込み等が発生した場合には、その申し込み等の手続に対する入力データをＣＲＭシステム等に反映することもできる。このような場合には、応対記録情報１１００の顧客入力データ格納ＵＲＬ１１０９に、顧客応対の内容や、その結果入力された処理の内容を特定又は説明する情報を記憶することができる。
オペレータが要約に修正を加えた場合や、メモを更新した場合、等には、その変更履歴が応対記録情報１１００や、要約情報９００、メモ情報１０００等に記憶されてもよい。
【0086】
図１５は、文書情報取得処理フロー１５００の例である。
電話顧客応対を想定しているが、これに限られず、何らかの文書情報を取得できるものであれば文書情報取得処理を適用可能である。
文書情報取得モジュール２１３は、電話応対の際の電話音声の入力を受け付ける（ステップ１５１０）。
文書情報取得モジュール２１３は、音声情報を解析し、テキスト情報に変換する（ステップ１５２０）。なお、顧客との対話内容をテキスト化したものを対話テキストと呼ぶ。
文書情報取得モジュール２１３は、テキスト情報を対話テキストとして例えば図２１の対話テキスト欄２１１０に表示する（ステップ１５３０）。
電話顧客応対を想定しているが、これに限られず、何らかの文書情報を取得できるものであれば文書情報取得処理を適用可能である。
文書情報取得モジュール２１３は、電話応対の際の電話音声の入力を受け付ける（ステップ１５１０）。
文書情報取得モジュール２１３は、音声情報を解析し、テキスト情報に変換する（ステップ１５２０）。なお、顧客との対話内容をテキスト化したものを対話テキストと呼ぶ。
文書情報取得モジュール２１３は、テキスト情報を対話テキストとして例えば図２１の対話テキスト欄２１１０に表示する（ステップ１５３０）。
【0087】
テキスト情報を記憶する必要が無ければそのままテキスト情報は破棄され（ステップ１５４０のＮｏ）、記憶する必要があれば（ステップ１５４０のＹｅｓ）、文書情報取得モジュール２１３は、文書ＩＤを生成し、テキスト情報と対応付けて、文書情報８００に記憶する（ステップ１５５０）。
【0088】
なお、文書情報８００に記憶されるテキスト情報は、対話テキストに限られず、チャット、メール、問合せフォーム、メッセージ送受信サービス等による顧客とのやり取りに応じて、送受信されるテキストの内容をテキスト情報として記憶する。その他、顧客との応対内容に関して何等かの文書情報を取得し記憶すればよい。また、文書情報は、何等か別のサービスから連携する、通話後にコピーされて持ってくる、等により取得してもよい。また、文書情報は、何等か別のサービスから連携する、通話後にコピーされて持ってくる、等により取得してもよい。
また、広くコールセンター以外の業務に本実施例を適用する場合には、何らかの文書情報を取得し記憶すればよい。
また、広くコールセンター以外の業務に本実施例を適用する場合には、何らかの文書情報を取得し記憶すればよい。
【0089】
図１６は、要約生成処理フロー１６００の例である。
要約生成モジュール２１４は、文書情報を取得する（ステップ１６１０）。
具体的には、要約生成モジュール２１４は、文書情報８００の文書情報格納ＵＲＬ８０４により参照されている場所から、テキスト情報（文書情報と呼ぶ）を取得する。
その他、文書情報取得モジュール２１３が取得した対話テキストを取得する構成でもよく、またその他何等か文書情報を取得すればよい。
要約生成モジュール２１４は、文書情報を取得する（ステップ１６１０）。
具体的には、要約生成モジュール２１４は、文書情報８００の文書情報格納ＵＲＬ８０４により参照されている場所から、テキスト情報（文書情報と呼ぶ）を取得する。
その他、文書情報取得モジュール２１３が取得した対話テキストを取得する構成でもよく、またその他何等か文書情報を取得すればよい。
【0090】
要約生成モジュール２１４は、取得した文書情報（テキスト情報）を、学習済みの機械学習モデルに入力し、要約を生成する（ステップ１６２０）。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１６３０）。
なお、要約を生成するための入力としては、対話テキストやメモを想定するが、他にも、通話中に参照したＦＡＱやその他使用サービスのログを参照する構成としてもよい。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１６３０）。
なお、要約を生成するための入力としては、対話テキストやメモを想定するが、他にも、通話中に参照したＦＡＱやその他使用サービスのログを参照する構成としてもよい。
【0091】
図１７は、詳細な要約生成処理フロー１７００の例である。
要約生成モジュール２１４の実装の方法は色々考えられるが、図５は機械学習モジュールを用いた具体的な実装の一例であり、この構成による要約生成処理を説明する。
ＡＰＩモジュール５０１がテキスト情報を取得（ステップ１７０５）。
ＡＰＩモジュール５０１が文書ＩＤを生成し、文書ＩＤとテキスト情報を文書情報８００に記憶する（ステップ１７１０）。
ＡＰＩモジュールが文書ＩＤ及びテキスト情報を含むメッセージをメッセージキューイングモジュール５０２に送信する（ステップ１７１５）。
要約生成モジュール２１４の実装の方法は色々考えられるが、図５は機械学習モジュールを用いた具体的な実装の一例であり、この構成による要約生成処理を説明する。
ＡＰＩモジュール５０１がテキスト情報を取得（ステップ１７０５）。
ＡＰＩモジュール５０１が文書ＩＤを生成し、文書ＩＤとテキスト情報を文書情報８００に記憶する（ステップ１７１０）。
ＡＰＩモジュールが文書ＩＤ及びテキスト情報を含むメッセージをメッセージキューイングモジュール５０２に送信する（ステップ１７１５）。
【0092】
ＭＬモジュール５０３が、メッセージキューイングモジュール５０２から取得したメッセージを記憶装置５１２から取得した機械学習モデルに入力し、要約を生成する（ステップ１７２０）。
ＭＬモジュール５０３が、文書ＩＤと要約結果のペアをメッセージキューイングモジュール５０２に送信する（ステップ１７２５）。
ワーカーモジュール５０４が、文書ＩＤと要約結果を要約情報９００に記憶する（ステップ１７３５）。
ＭＬモジュール５０３が、文書ＩＤと要約結果のペアをメッセージキューイングモジュール５０２に送信する（ステップ１７２５）。
ワーカーモジュール５０４が、文書ＩＤと要約結果を要約情報９００に記憶する（ステップ１７３５）。
【0093】
ＡＰＩモジュール５０１が、要約情報９００に記憶されている要約結果（要約情報と呼ぶ）を取得する（ステップ１７４０）。
Ｗｅｂサーバモジュール５０５が、ＡＰＩモジュール５０１から要約情報を取得する（ステップ１７４５）。
Ｗｅｂサーバモジュール５０５が要約情報を出力する（ステップ１７５０）。
なお、機械学習モデルとしては、大規模言語モデルを使用することができ、高精度な生成型のモデルであるが、これに限られず、例えば文字列抽出型で要約を生成する機械学習モデルを用いてもよい。
Ｗｅｂサーバモジュール５０５が、ＡＰＩモジュール５０１から要約情報を取得する（ステップ１７４５）。
Ｗｅｂサーバモジュール５０５が要約情報を出力する（ステップ１７５０）。
なお、機械学習モデルとしては、大規模言語モデルを使用することができ、高精度な生成型のモデルであるが、これに限られず、例えば文字列抽出型で要約を生成する機械学習モデルを用いてもよい。
【0094】
図１８は、カテゴリ別要約生成処理フロー１８００の例である。
カテゴリ別要約生成処理フロー１８００では、要約を生成する際に、さらにカテゴリの情報を入力として加えることで、カテゴリに適した要約を生成することができる。
要約生成モジュール２１４は、文書情報を取得する（ステップ１８１０）。
要約生成モジュール２１４は、カテゴリ選択モジュール２１２により取得されたカテゴリ情報を取得する（ステップ１８２０）。
要約生成モジュール２１４は、取得した文書情報（テキスト情報）とカテゴリ情報を学習済みの機械学習モデルに入力することで、入力した文書情報に対するカテゴリ情報に関連する要約を生成する（ステップ１８３０）。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１８４０）。
カテゴリ別要約生成処理フロー１８００では、要約を生成する際に、さらにカテゴリの情報を入力として加えることで、カテゴリに適した要約を生成することができる。
要約生成モジュール２１４は、文書情報を取得する（ステップ１８１０）。
要約生成モジュール２１４は、カテゴリ選択モジュール２１２により取得されたカテゴリ情報を取得する（ステップ１８２０）。
要約生成モジュール２１４は、取得した文書情報（テキスト情報）とカテゴリ情報を学習済みの機械学習モデルに入力することで、入力した文書情報に対するカテゴリ情報に関連する要約を生成する（ステップ１８３０）。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１８４０）。
【0095】
学習済みの機械学習モデルは、文書情報の属するカテゴリを示すカテゴリ情報と、このカテゴリに属する複数の文書情報とを教師データとして用いて機械学習を行った学習済みの機械学習モデルとすることができる。
図３４のカテゴリ情報を用いた顧客応対処理フロー３４００のステップ３４４０のカテゴリ情報の選択の例では、既に対話テキストに関連するカテゴリが選択されている。従って、この機械学習モデルにカテゴリ情報と共に対話テキストの文書情報を入力することで、要約生成モジュール２１４は、この文書情報に最適化された要約を生成することができる。
本処理フローでは、カテゴリ情報と文書情報をセットにして機械学習させた機械学習モデルを用いており、１つの機械学習モデルで、入力されたカテゴリに対応した要約を出力することができる。
図３４のカテゴリ情報を用いた顧客応対処理フロー３４００のステップ３４４０のカテゴリ情報の選択の例では、既に対話テキストに関連するカテゴリが選択されている。従って、この機械学習モデルにカテゴリ情報と共に対話テキストの文書情報を入力することで、要約生成モジュール２１４は、この文書情報に最適化された要約を生成することができる。
本処理フローでは、カテゴリ情報と文書情報をセットにして機械学習させた機械学習モデルを用いており、１つの機械学習モデルで、入力されたカテゴリに対応した要約を出力することができる。
【0096】
なお、前述の通り、カテゴリの事前選択は必須ではなく、何もカテゴリが選択されなくても要約生成処理を実行してもよい。また、図２３のようなカテゴリ選択入力画面２３００を表示することなく、バックグラウンドで、カテゴリ選択モジュール２１２により文書情報の内容に基づいてカテゴリが自動選択される構成としてもよい。
また、カテゴリ情報自体を用いず、文書情報を機械学習モデルに入力することで、文書のカテゴリを判別した上で、そのカテゴリに対応する要約を生成する構成としてもよい。
また、カテゴリ情報自体を用いず、文書情報を機械学習モデルに入力することで、文書のカテゴリを判別した上で、そのカテゴリに対応する要約を生成する構成としてもよい。
【0097】
図１９は、別のカテゴリ別要約生成処理フロー１９００の例である。
別のカテゴリ別要約生成処理フロー１９００では、カテゴリ情報に応じて使用する機械学習モデルを切り替えることで、カテゴリに適した要約を生成することができる。
要約生成モジュール２１４は、文書情報を取得する（ステップ１９１０）。
要約生成モジュール２１４は、カテゴリ選択モジュール２１２により取得されたカテゴリ情報を取得する（ステップ１９２０）。
別のカテゴリ別要約生成処理フロー１９００では、カテゴリ情報に応じて使用する機械学習モデルを切り替えることで、カテゴリに適した要約を生成することができる。
要約生成モジュール２１４は、文書情報を取得する（ステップ１９１０）。
要約生成モジュール２１４は、カテゴリ選択モジュール２１２により取得されたカテゴリ情報を取得する（ステップ１９２０）。
【0098】
要約生成モジュール２１４は、カテゴリ情報に対応する機械学習モデルを選択する（ステップ１９３０）。例えば、機械学習モデル毎に別サーバを用意している場合には、カテゴリ情報に対応する機械学習サーバに対して文書情報を送信する。
【0099】
要約生成モジュール２１４は、取得した文書情報（テキスト情報）を、カテゴリ情報に対応して選択された機械学習モデルに入力することで、入力した文書情報に対する要約を生成する（ステップ１９４０）。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１９５０）。
要約生成モジュール２１４は、生成した要約の結果と、生成した文書ＩＤとを対応付けて要約情報９００に記憶する（ステップ１９５０）。
【0100】
学習済みの機械学習モデルは、特定のカテゴリに属する複数の文書情報を教師データとして用いて機械学習を行った学習済みの機械学習モデルとすることができ、カテゴリごとに学習済みの機械学習モデルを用意することができる。
これらの学習済み機械学習モデルは、図５の記憶装置５１２に格納されており、機械学習モデルの選択に応じて、選択された機械学習モデルが記憶装置５１２からＭＬモジュール５０３に読みだされる。
なお、カテゴリに最適化された機械学習モデル毎にＭＬモジュール５０３を用意しておき、このＭＬモジュール５０３を切り替える構成でも構わない。
これらの学習済み機械学習モデルは、図５の記憶装置５１２に格納されており、機械学習モデルの選択に応じて、選択された機械学習モデルが記憶装置５１２からＭＬモジュール５０３に読みだされる。
なお、カテゴリに最適化された機械学習モデル毎にＭＬモジュール５０３を用意しておき、このＭＬモジュール５０３を切り替える構成でも構わない。
【0101】
図３４の顧客応対処理フロー３４００のステップ３４４０のカテゴリ情報の選択で説明した通り、既に対話テキストに関連するカテゴリが選択されている。従って、カテゴリ情報に基づいて選択された、各カテゴリに最適化済みの機械学習モデルに対話テキストの文書情報を入力することで、要約生成モジュール２１４は、この文書情報に最適化された要約を生成することができる。
本処理フローでは、カテゴリ情報に基づいて、カテゴリごとに学習させた機械学習モデルを切り替えることで、入力されたカテゴリに対応した要約を出力することができる。
本処理フローでは、カテゴリ情報に基づいて、カテゴリごとに学習させた機械学習モデルを切り替えることで、入力されたカテゴリに対応した要約を出力することができる。
【0102】
なお、図３４の顧客応対処理フロー３４００のステップ３４４０のカテゴリの選択は必須ではなく、何もカテゴリが選択されなくても要約生成処理を実行してもよい。また、図２３のようなカテゴリ選択入力画面２３００を表示することなく、バックグラウンドで、カテゴリ選択モジュール２１２により文書情報の内容に基づいてカテゴリが自動選択される構成としてもよい。
すなわち、本実施例によれば、要約を通話内容のカテゴリ情報によって明示的に切り替える仕組みを提供することができる。
すなわち、本実施例によれば、要約を通話内容のカテゴリ情報によって明示的に切り替える仕組みを提供することができる。
【0103】
図２０は、強調表示処理フロー２０００の例である。
強調表示モジュール２１６は、文書情報８００からテキスト情報（文書情報と呼ぶ）を取得する（ステップ２０１０）。
強調表示モジュール２１６は、要約情報９００から要約（要約情報と呼ぶ）を取得する（ステップ２０２０）。
強調表示モジュール２１６は、メモ情報１０００から記入されたメモ情報を取得する（ステップ２０３０）。
強調表示モジュール２１６は、文書情報８００からテキスト情報（文書情報と呼ぶ）を取得する（ステップ２０１０）。
強調表示モジュール２１６は、要約情報９００から要約（要約情報と呼ぶ）を取得する（ステップ２０２０）。
強調表示モジュール２１６は、メモ情報１０００から記入されたメモ情報を取得する（ステップ２０３０）。
【0104】
強調表示モジュール２１６は、取得したそれぞれの情報に対して、例えば自然言語処理による解析等を実施し、１又は複数の特徴文字列を抽出する（ステップ２０４０）。
強調表示モジュール２１６は、後述する様々な条件を満たす特徴文字列、又はこの特徴文字列を含む文字列に対して強調表示を行う（ステップ２０５０）。
なお、特徴文字列とは、テキストデータの中の単語や単語を含む文字列のことであり、原則は単なる助詞のみの文字列等は含まれない。但しこれに限られず、助詞等を含む単語の連結や、助詞等を含む文字列、その他広く文字列や文章であってもかまわない。キーワードも特徴文字列の一つである。
但し、例えば、助詞の誤り等が有りそうな部分や、文法の誤りを強調したい部分等について助詞のみをハイライトすることもできる。
強調表示モジュール２１６は、後述する様々な条件を満たす特徴文字列、又はこの特徴文字列を含む文字列に対して強調表示を行う（ステップ２０５０）。
なお、特徴文字列とは、テキストデータの中の単語や単語を含む文字列のことであり、原則は単なる助詞のみの文字列等は含まれない。但しこれに限られず、助詞等を含む単語の連結や、助詞等を含む文字列、その他広く文字列や文章であってもかまわない。キーワードも特徴文字列の一つである。
但し、例えば、助詞の誤り等が有りそうな部分や、文法の誤りを強調したい部分等について助詞のみをハイライトすることもできる。
【0105】
なお、強調表示としては、強調表示は、例えば、条件に合致する文書の部分を太字にする、下線を引く、色を変える、斜体にする、網掛けをする、フォントを変える、点滅させる、文字列の周りを線で囲う、背景色を変えたり文字列の上に色のレイヤーをかぶせたりしてハイライトする、等が考えられる。強調表示は、何等か他の文字列部分と比較して目立つ構成や区別しうる構成の文字列にすればよい。
また、テキスト内の文字列を何らかの形で強調表示するだけではなく、別枠で表示することで強調することもできる。例えば、強調したい日付情報だけをまとめたスペースを別の画面や別ウィンドウ上に表示することもできる。
また、テキスト内の文字列を何らかの形で強調表示するだけではなく、別枠で表示することで強調することもできる。例えば、強調したい日付情報だけをまとめたスペースを別の画面や別ウィンドウ上に表示することもできる。
【0106】
なお、強調表示モジュール２１６が、記憶装置に記憶されている文書情報８００、要約情報９００、メモ情報１０００から情報を取得し、強調表示を行うこととして説明をしたが、これに限られない。例えば、文書情報取得モジュール２１３、要約生成モジュール２１４、メモ情報取得モジュール２１５が、それぞれ文書情報８００、要約情報９００、メモ情報１０００から情報を取得し、強調表示モジュールが強調表示処理を行うこととしてもよい。
また、顧客応対処理モジュール２１１が各種情報を取得し、強調表示モジュールが強調表示処理を行うこととしてもよい。
また、顧客応対処理モジュール２１１が各種情報を取得し、強調表示モジュールが強調表示処理を行うこととしてもよい。
【0107】
さらに、記憶装置に記憶済みの文書情報８００、要約情報９００、メモ情報１０００ではなく、文書情報取得モジュール２１３により取得されたテキスト情報（対話テキスト）、要約生成モジュール２１４により生成された要約情報、メモ情報取得モジュール２１５により取得されたメモ情報、に対して強調表示モジュール２１６が強調表示を行う構成でもよい。
また、顧客応対処理モジュール２１１が強調表示モジュール２１６と連携して、強調表示を行う構成でもよいし、顧客応対処理モジュール２１１自体が強調表示モジュール２１６の機能を有していてもよい。
また、顧客応対処理モジュール２１１が強調表示モジュール２１６と連携して、強調表示を行う構成でもよいし、顧客応対処理モジュール２１１自体が強調表示モジュール２１６の機能を有していてもよい。
【0108】
図２４は、要約表示画面２４００の例である。
図２３のカテゴリ選択の後に、要約スタートボタン２３３５を押した後に生成された要約が要約文欄２４３０に表示されている。
ここに表示されている要約は、対話テキスト欄２４１０に表示された文書情報が、カテゴリの選択に対応する要約を生成する機械学習モデルに入力されることによって生成されたものである。
図２３のカテゴリ選択の後に、要約スタートボタン２３３５を押した後に生成された要約が要約文欄２４３０に表示されている。
ここに表示されている要約は、対話テキスト欄２４１０に表示された文書情報が、カテゴリの選択に対応する要約を生成する機械学習モデルに入力されることによって生成されたものである。
【0109】
顧客応対処理モジュール２１１は、文書情報取得モジュール２１３により取得された第１の文書情報（対話テキスト）と、要約生成モジュール２１４により取得された要約と、メモ情報取得モジュール２１５により取得された第２の文書情報（メモ情報）の３種類の情報を、対話テキスト欄２４１０、要約文欄２４３０、メモ欄２４２０にそれぞれ表示し、３パネル表示によりそれぞれ対応付けて出力している。対話テキスト２４１０の中の記載は、電話の応対の音声情報をテキスト化しているため、ところどころ正確に文字おこしができていない部分がある。しかしながらこのような誤記のある対話テキストを入力として用いた場合であっても、要約生成モジュール２１４は、正しい要約２４３０を生成することができる。
【0110】
なお、３パネルの全てが必要ではなく、対話文を表示しない、要約文を表示しない、メモ欄を表示しない、というような構成とすることもでき、この場合、対話テキスト欄２４１０、要約文欄２４３０、メモ欄２４２０のうちの任意の２つを対応付けて表示する構成とすることができる。また、対話文、要約文、メモ欄、のそれぞれのみを単独で表示することもできる。
また、必ずしも３パネル表示や２パネル表示にする必要は無く、例えば３種類の情報又は任意の２種類の情報をタブ等により切り替えて表示する場合も、それぞれの情報を対応付けて表示する構成であると言える。
なお、第１の文書情報にメモ情報を用いてもよく、また、第２の文書情報として対話テキストやチャット、メール、問合せフォーム、メッセージ送受信サービス等を用いてもよい。
また、必ずしも３パネル表示や２パネル表示にする必要は無く、例えば３種類の情報又は任意の２種類の情報をタブ等により切り替えて表示する場合も、それぞれの情報を対応付けて表示する構成であると言える。
なお、第１の文書情報にメモ情報を用いてもよく、また、第２の文書情報として対話テキストやチャット、メール、問合せフォーム、メッセージ送受信サービス等を用いてもよい。
【0111】
強調表示モジュール２１６により、対話テキストと要約文のうち共通する人名の「特許次郎」が２４１１と２４３１において下線で強調表示されている。
また全く共通でなくとも、対応する人名である対話テキストの「イライザ花子さん」２４１２に対して、要約文の「イライザ花子」２４３２とメモ欄の「イライザ花子」２４２２が下線で強調表示されている。
また、対話テキストの中で「その他の方の飛行機代やホテル代等は含まれておりません」という記載２４１３と、それに対応する記載である「その他の方のホテル代等は含まれていない。」という記載２４３３が、共に色が付けられてハイライトされている。
また、２０２２年２月２日という日付が、対話テキストとメモの両方に共通して存在し、それぞれ下線で強調表示されている。
また全く共通でなくとも、対応する人名である対話テキストの「イライザ花子さん」２４１２に対して、要約文の「イライザ花子」２４３２とメモ欄の「イライザ花子」２４２２が下線で強調表示されている。
また、対話テキストの中で「その他の方の飛行機代やホテル代等は含まれておりません」という記載２４１３と、それに対応する記載である「その他の方のホテル代等は含まれていない。」という記載２４３３が、共に色が付けられてハイライトされている。
また、２０２２年２月２日という日付が、対話テキストとメモの両方に共通して存在し、それぞれ下線で強調表示されている。
【0112】
この例では、対話テキストの中で、要約と共通するキーワードをハイライトしている。つまり、強調表示モジュール２１６は、第１の文書情報（対話テキスト）と要約に対応する特徴文字列が存在することを条件として、この条件が満たされた場合に強調表示を行う。強調表示モジュール２１６は、第１の文書情報（対話テキスト）に含まれる１又は複数の特徴文字列のうち、要約に対応する特徴文字列を強調表示する。
その他、対話テキスト、要約文、メモのいずれかの中で共通に存在する特徴文字列を強調表示することもできる。
その他、対話テキスト、要約文、メモのいずれかの中で共通に存在する特徴文字列を強調表示することもできる。
【0113】
また、要約とメモで対応するキーワードをハイライトすることもできる。つまり、強調表示モジュール２１６は、第２の文書情報（メモ情報）と要約に対応する特徴文字列が存在することを条件として、この条件が満たされた場合に強調表示を行う。強調表示モジュール２１６は、第１の文書情報（対話テキスト）、第２の文書情報（メモ情報）、又は要約の少なくとも１つに含まれる１又は複数の特徴文字列のうち、第２の文書情報（メモ情報）と要約に対応している特徴文字列を強調表示する。
また、対話テキストと要約の表現が異なることもあるが、対応しているものを強調表示することができる。
また、対話テキストと要約の表現が異なることもあるが、対応しているものを強調表示することができる。
【0114】
なお、設定ボタン２４３６を押すことで、図２６の要約生成の設定画面に遷移する。ここでカテゴリ選択を変更する等、設定を変更し、再度要約スタートボタン２４３５を押すことで、変更後の設定に基づく要約が再度生成される。
要約生成の設定画面は、図２６の様な別画面が表示される構成でもよいし、図２３、図２４、図２５の様な要約出力の画面表示上に表示することとしてもよい。
要約生成の設定画面は、図２６の様な別画面が表示される構成でもよいし、図２３、図２４、図２５の様な要約出力の画面表示上に表示することとしてもよい。
【0115】
図２５は、別の要約表示画面２５００の例である。
図２４とは異なる部分がハイライト表示されている。
この例では、対話テキスト２３１０の中の「新郎新婦様の飛行機代は含まれておりますが、その他の方の飛行機代やホテル代等は含まれておりません。」という記載２５１１と、これに対応する記載である要約文２５３０の中の「新郎新婦の飛行機代は含まれているが、その他の方のホテル代等は含まれていない。」という記載２５３１が下線で強調表示されている。
図２４とは異なる部分がハイライト表示されている。
この例では、対話テキスト２３１０の中の「新郎新婦様の飛行機代は含まれておりますが、その他の方の飛行機代やホテル代等は含まれておりません。」という記載２５１１と、これに対応する記載である要約文２５３０の中の「新郎新婦の飛行機代は含まれているが、その他の方のホテル代等は含まれていない。」という記載２５３１が下線で強調表示されている。
【0116】
また、メモにあって要約に無いキーワードを、対話情報又はメモの中でハイライトすることもできる。
つまり、特徴文字列が第２の文書情報（メモ情報）に存在するが要約に存在しないこと、を条件として、この条件が満たされた場合に強調表示を行う。強調表示モジュール２１６は、第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）の少なくともいずれかに含まれる１又は複数の特徴文字列のうち、第２の文書情報（メモ情報）に存在するが要約に存在しない特徴文字列を強調表示する。
つまり、特徴文字列が第２の文書情報（メモ情報）に存在するが要約に存在しないこと、を条件として、この条件が満たされた場合に強調表示を行う。強調表示モジュール２１６は、第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）の少なくともいずれかに含まれる１又は複数の特徴文字列のうち、第２の文書情報（メモ情報）に存在するが要約に存在しない特徴文字列を強調表示する。
【0117】
図２５の例では、メモ欄２５２０に記載された「あと２名分追加したい」という記載２５２２が、メモには存在しているが、要約文２５３０の中には存在していない。そのため強調表示モジュール２１６は、この記載に対応する「あと２名分追加したい」という記載２５１２及び２５２２をメモ及び対話テキストの中で強調表示している。
【0118】
また、要約にあって対話情報やメモにないキーワードを、要約の中でハイライトすることもできる。
つまり、特徴文字列が要約に存在するが第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）に存在しないこと、を条件として、この条件が持たされた場合に強調表示を行う。強調表示モジュール２１６は、要約に含まれる１又は複数の特徴文字列のうち、要約に存在するが第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）に存在しない特徴文字列を強調表示する。
図２５の例では、「ブライダルのプランの変更を決定した」という記載２５３８は、要約には存在しているが、対話テキストやメモには存在していない。機械学習モデルによっては、入力された対話テキストに存在しない文章を生成してしまうことがあるが、この様な文字列を含む文章は事実と異なる可能性も存在するため、このような文字列を含む文章を強調表示することで、ユーザに修正の機会を与えることができる。
つまり、特徴文字列が要約に存在するが第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）に存在しないこと、を条件として、この条件が持たされた場合に強調表示を行う。強調表示モジュール２１６は、要約に含まれる１又は複数の特徴文字列のうち、要約に存在するが第１の文書情報（対話テキスト）又は第２の文書情報（メモ情報）に存在しない特徴文字列を強調表示する。
図２５の例では、「ブライダルのプランの変更を決定した」という記載２５３８は、要約には存在しているが、対話テキストやメモには存在していない。機械学習モデルによっては、入力された対話テキストに存在しない文章を生成してしまうことがあるが、この様な文字列を含む文章は事実と異なる可能性も存在するため、このような文字列を含む文章を強調表示することで、ユーザに修正の機会を与えることができる。
【0119】
図２５の例では、要約文欄２５３０に記載された「今後の方針方向性」という記載２５３３が、要約文には存在しているが、メモ欄２５２０の中には存在していない。そのため強調表示モジュール２１６は、この記載に対応する「今後の方針方向性」という記載２５１３を対話テキストの中で強調表示している。
また、要約とメモには存在しているが、対話テキストには存在しない文字列を強調表示することもできる。
また、要約とメモには存在しているが、対話テキストには存在しない文字列を強調表示することもできる。
また、その他、ＡＩの自信のない箇所をハイライトすることもできる。
また、要約とメモには存在しているが、対話テキストには存在しない文字列を強調表示することもできる。
また、要約とメモには存在しているが、対話テキストには存在しない文字列を強調表示することもできる。
また、その他、ＡＩの自信のない箇所をハイライトすることもできる。
【0120】
つまり、要約生成モジュール２１４が生成した要約の中で要約の精度が高くない可能性があるもの、を条件として、この条件が満たされた場合に強調表示を行う。たとえば、要約を出力するモデルの確率分布に従って判断することができる。たとえば確率分布が一定で語彙選択に優位な差がない場合等に強調表示を行う。また、判別するための学習モデルを別に作って判断することもできる。
強調表示モジュール２１６は、第１の文書情報（対話テキスト）、第２の文書情報（メモ情報）、又は要約に含まれる１又は複数の特徴文字列のうち、要約生成モジュール２１４が生成した要約の中で、要約の精度が高くない可能性があるものを強調表示する。
強調表示モジュール２１６は、第１の文書情報（対話テキスト）、第２の文書情報（メモ情報）、又は要約に含まれる１又は複数の特徴文字列のうち、要約生成モジュール２１４が生成した要約の中で、要約の精度が高くない可能性があるものを強調表示する。
【0121】
また、要約文選択タグ２５３７は、機械学習モデルによる複数の要約文の出力を比較して表示するためのタブである。表示方法は、少なくとも２２つ以上の要約文を並列に表示しても良いし、ボタン選択による切り替え、プルダウン形式での切り替えでも良い。表示方法は、少なくとも２つ以上の要約文を並列に表示しても良いし、ボタン選択による切り替え、プルダウン形式での切り替えでも良い。
なお、タブごとに複数の機械学習モデルによる要約文を出し分けてもよいし、異なるカテゴリにより生成された要約文を出し分けてもよい。
なお、タブごとに複数の機械学習モデルによる要約文を出し分けてもよいし、異なるカテゴリにより生成された要約文を出し分けてもよい。
【0122】
その他強調表示モジュール２１６は、強調によりInput（入力情報）、Output（出力情報）を参照して人がレビューしやすくする仕組みを提供する。
InputとOutputそれぞれ単体で、人がレビューしやすくする仕組みとしては、以下が挙げられる。
・重要箇所（日付・名前・契約番号など）をハイライトする。
・ＡＩが自信がない箇所をハイライトする。
・Input、Output間で、参照し合い、レビューしやすくする仕組みを提供する。
・要約にはあるが、Input（対話テキスト・メモなど）に近いものがない箇所をハイライトする。
なお、近いかどうかは以下のような手法により判定することができる。
- ルールによる判定
- 文字列・単語など何らかの単位での一致度・類似度による判定
- 辞書などによる判定
- 機械学習技術による判定
- 分散表現（ベクトル表現）の類似度
- 機械学習モデルによる判定
・要約において、Inputのどこを使ったかをハイライトする。
・メモにあって、要約にないものをハイライトする。
・対話テキストの中で、要約に入れた方が良さそうな部分を強調表示
なお、入れた方が良さそうかどうかは以下のような手法により判定することができる。
- 要約を複数生成し、それらの要約に入っている文字列を候補として判定する
- 別途重要度を判定する機械学習モデル・ルールを利用して判定する
InputとOutputそれぞれ単体で、人がレビューしやすくする仕組みとしては、以下が挙げられる。
・重要箇所（日付・名前・契約番号など）をハイライトする。
・ＡＩが自信がない箇所をハイライトする。
・Input、Output間で、参照し合い、レビューしやすくする仕組みを提供する。
・要約にはあるが、Input（対話テキスト・メモなど）に近いものがない箇所をハイライトする。
なお、近いかどうかは以下のような手法により判定することができる。
- ルールによる判定
- 文字列・単語など何らかの単位での一致度・類似度による判定
- 辞書などによる判定
- 機械学習技術による判定
- 分散表現（ベクトル表現）の類似度
- 機械学習モデルによる判定
・要約において、Inputのどこを使ったかをハイライトする。
・メモにあって、要約にないものをハイライトする。
・対話テキストの中で、要約に入れた方が良さそうな部分を強調表示
なお、入れた方が良さそうかどうかは以下のような手法により判定することができる。
- 要約を複数生成し、それらの要約に入っている文字列を候補として判定する
- 別途重要度を判定する機械学習モデル・ルールを利用して判定する
【0123】
レビュー後、修正の提案を行うための機能としては以下が挙げられる。
・単語やフレーズなどの単位で、類義語辞書や機械学習による単語・フレーズ間の類似度算出を用いて、修正を提案。例えば、要約文の中で「お打合せ」という語が強調表示されており、これに対する修正候補として「会議」「ミーティング」「ＭＴＧ」「打ち合せ」を選択可能な形で表示する。表示形式としては、修正候補をポップアップさせたり、別タブや別画面で表示したり、強調表示の上にマウス等のカーソルを移動すると修正候補が重畳表示させる、等の表示方法が考えられる。また、ＡＩの自信のない箇所に対して、修正提案を表示する構成としてもよい。また、任意の場所をユーザがクリック等により指定して修正候補を表示する構成でもよい。
・単語やフレーズなどの単位で、よく間違えられる表現に対して過去データから、もしくは手動で変換ルールを作成し、それを提案する。
・単語・フレーズ・文などの様々な単位で、ＡＩが出力し得た他の候補を提案する。例えば、次に生成確率が高かったものを提案。例えば、機械学習モデルの生成する候補だったものの中から、次に確率が高かったものなど、他のものを修正の提案として表示。修正箇所としては、例えばＡＩの自信がない箇所でもよいし、任意の場所をユーザがクリック等により指定する構成でもよい。
例えば、図２４の要約文例では、「ハワイでの見積もりを提示した。」という表現に対して、例えば、「先日ハワイでの見積もりを郵送した」を候補として提示する。この修正提案に対しては、提案が間違えていたり、あまり良くなかった場合にフィードバックを受け付けるための機能を有していてもよい。例えば修正候補の下に、提案を受け入れる事を示す「チェックマーク」と、受け入れない事を示す「バツマーク」を表示し、ユーザからの選択を受け付ける構成とすることができる。
その他、修正提案に対して、受け入れる又は受け入れないではなく、良いか悪いかの評価を受け付ける「良いねマーク」「悪いねマーク」を表示して、ユーザからの評価を受け付ける構成とすることができる。
・単語やフレーズなどの単位で、類義語辞書や機械学習による単語・フレーズ間の類似度算出を用いて、修正を提案。例えば、要約文の中で「お打合せ」という語が強調表示されており、これに対する修正候補として「会議」「ミーティング」「ＭＴＧ」「打ち合せ」を選択可能な形で表示する。表示形式としては、修正候補をポップアップさせたり、別タブや別画面で表示したり、強調表示の上にマウス等のカーソルを移動すると修正候補が重畳表示させる、等の表示方法が考えられる。また、ＡＩの自信のない箇所に対して、修正提案を表示する構成としてもよい。また、任意の場所をユーザがクリック等により指定して修正候補を表示する構成でもよい。
・単語やフレーズなどの単位で、よく間違えられる表現に対して過去データから、もしくは手動で変換ルールを作成し、それを提案する。
・単語・フレーズ・文などの様々な単位で、ＡＩが出力し得た他の候補を提案する。例えば、次に生成確率が高かったものを提案。例えば、機械学習モデルの生成する候補だったものの中から、次に確率が高かったものなど、他のものを修正の提案として表示。修正箇所としては、例えばＡＩの自信がない箇所でもよいし、任意の場所をユーザがクリック等により指定する構成でもよい。
例えば、図２４の要約文例では、「ハワイでの見積もりを提示した。」という表現に対して、例えば、「先日ハワイでの見積もりを郵送した」を候補として提示する。この修正提案に対しては、提案が間違えていたり、あまり良くなかった場合にフィードバックを受け付けるための機能を有していてもよい。例えば修正候補の下に、提案を受け入れる事を示す「チェックマーク」と、受け入れない事を示す「バツマーク」を表示し、ユーザからの選択を受け付ける構成とすることができる。
その他、修正提案に対して、受け入れる又は受け入れないではなく、良いか悪いかの評価を受け付ける「良いねマーク」「悪いねマーク」を表示して、ユーザからの評価を受け付ける構成とすることができる。
【0124】
レビュー後、修正の提案を行うための機能としては以下が挙げられる。
・単語やフレーズなどの単位で、類義語辞書や機械学習による単語・フレーズ間の類似度算出を用いて、修正を提案。例えば、要約文の中で「お打合せ」という語が強調表示されており、これに対する修正候補として「会議」「ミーティング」「ＭＴＧ」「打ち合せ」を選択可能な形で表示する。表示形式としては、修正候補をポップアップさせたり、別タブや別画面で表示したり、強調表示の上にマウス等のカーソルを移動すると修正候補が重畳表示させる、等の表示方法が考えられる。また、ＡＩの自信のない箇所に対して、修正提案を表示する構成としてもよい。また、任意の場所をユーザがクリック等により指定して修正候補を表示する構成でもよい。
・単語やフレーズなどの単位で、よく間違えられる表現に対して過去データから、もしくは手動で変換ルールを作成し、それを提案する。
・単語・フレーズ・文などの様々な単位で、ＡＩが出力し得た他の候補を提案する。例えば、次に生成確率が高かったものを提案。例えば、機械学習モデルの生成する候補だったものの中から、次に確率が高かったものなど、他のものを修正の提案として表示。修正箇所としては、例えばＡＩの自信がない箇所でもよいし、任意の場所をユーザがクリック等により指定する構成でもよい。
例えば、図２４の要約文例では、「ハワイでの見積もりを提示した。」という表現に対して、例えば、「先日ハワイでの見積もりを郵送した」を候補として提示する。この修正提案に対しては、提案が間違えていたり、あまり良くなかった場合にフィードバックを受け付けるための機能を有していてもよい。例えば修正候補の下に、提案を受け入れる事を示す「チェックマーク」と、受け入れない事を示す「バツマーク」を表示し、ユーザからの選択を受け付ける構成とすることができる。
その他、修正提案に対して、受け入れる又は受け入れないではなく、良いか悪いかの評価を受け付ける「良いねマーク」「悪いねマーク」を表示して、ユーザからの評価を受け付ける構成とすることができる。
単語等の文字列等が修正された場合に、修正された文字列等を機械学習モデルに再度入力し、要約全体や、修正された文字列等の以降の部分の要約を、再度機械学習モデルで生成し直してもよい。
・単語やフレーズなどの単位で、類義語辞書や機械学習による単語・フレーズ間の類似度算出を用いて、修正を提案。例えば、要約文の中で「お打合せ」という語が強調表示されており、これに対する修正候補として「会議」「ミーティング」「ＭＴＧ」「打ち合せ」を選択可能な形で表示する。表示形式としては、修正候補をポップアップさせたり、別タブや別画面で表示したり、強調表示の上にマウス等のカーソルを移動すると修正候補が重畳表示させる、等の表示方法が考えられる。また、ＡＩの自信のない箇所に対して、修正提案を表示する構成としてもよい。また、任意の場所をユーザがクリック等により指定して修正候補を表示する構成でもよい。
・単語やフレーズなどの単位で、よく間違えられる表現に対して過去データから、もしくは手動で変換ルールを作成し、それを提案する。
・単語・フレーズ・文などの様々な単位で、ＡＩが出力し得た他の候補を提案する。例えば、次に生成確率が高かったものを提案。例えば、機械学習モデルの生成する候補だったものの中から、次に確率が高かったものなど、他のものを修正の提案として表示。修正箇所としては、例えばＡＩの自信がない箇所でもよいし、任意の場所をユーザがクリック等により指定する構成でもよい。
例えば、図２４の要約文例では、「ハワイでの見積もりを提示した。」という表現に対して、例えば、「先日ハワイでの見積もりを郵送した」を候補として提示する。この修正提案に対しては、提案が間違えていたり、あまり良くなかった場合にフィードバックを受け付けるための機能を有していてもよい。例えば修正候補の下に、提案を受け入れる事を示す「チェックマーク」と、受け入れない事を示す「バツマーク」を表示し、ユーザからの選択を受け付ける構成とすることができる。
その他、修正提案に対して、受け入れる又は受け入れないではなく、良いか悪いかの評価を受け付ける「良いねマーク」「悪いねマーク」を表示して、ユーザからの評価を受け付ける構成とすることができる。
単語等の文字列等が修正された場合に、修正された文字列等を機械学習モデルに再度入力し、要約全体や、修正された文字列等の以降の部分の要約を、再度機械学習モデルで生成し直してもよい。
【0125】
要約単体において、人が修正しやすいＵＩ（User Interface）としては以下が挙げられる。
・ＡＩによる出力された要約と修正後の要約のテキストを見比べて編集できるＵＩを提供する。フィードバックモジュール２１７は、要約生成モジュール２１４により生成された要約に対する編集を受け付ける。修正前後の要約は対比可能な形で表示することができる。例えば、修正前後の要約をタブで切り替えて表示したり、横並びで表示したりすることができる。また、編集された箇所の色を変える等強調表示することもできる。
・要約生成モジュール２１４により生成された要約に対して、テンプレートを用いて修正をする機能を提供する。
・複数の要約の出力を比較して、選択できる機能を提供する。なお、複数の機械学習モデルの出力を比較して、選択できる構成でもよい。なお、複数の機械学習モデルの出力を比較して、選択できる構成でもよい。
・ＡＩによる出力された要約と修正後の要約のテキストを見比べて編集できるＵＩを提供する。フィードバックモジュール２１７は、要約生成モジュール２１４により生成された要約に対する編集を受け付ける。修正前後の要約は対比可能な形で表示することができる。例えば、修正前後の要約をタブで切り替えて表示したり、横並びで表示したりすることができる。また、編集された箇所の色を変える等強調表示することもできる。
・要約生成モジュール２１４により生成された要約に対して、テンプレートを用いて修正をする機能を提供する。
・複数の要約の出力を比較して、選択できる機能を提供する。なお、複数の機械学習モデルの出力を比較して、選択できる構成でもよい。なお、複数の機械学習モデルの出力を比較して、選択できる構成でもよい。
【0126】
図２６は、要約設定画面２６００の例である。
要約の出力設定を行う画面である。要約設定画面は図２４の要約設定ボタン２４３６や、図２５の要約設定ボタン２５３６が選択されることで表示される。要約設定画面２６００は、別画面で表示されてもよいし、他のＵＩと並列で表示されてもよいし、オーバーレイ（全体、一部）の形式で表示されてもよい。
図２６の例は、既に案件区分（カテゴリ）として「保険」が選択されている場合に表示される要約設定画面である。サブカテゴリとして保険種別２６０１が表示されており、自動車保険が選択されている。
サブサブカテゴリとして、対応方法種別２６０２が表示されており、手続きが選択されている。
要約の出力設定を行う画面である。要約設定画面は図２４の要約設定ボタン２４３６や、図２５の要約設定ボタン２５３６が選択されることで表示される。要約設定画面２６００は、別画面で表示されてもよいし、他のＵＩと並列で表示されてもよいし、オーバーレイ（全体、一部）の形式で表示されてもよい。
図２６の例は、既に案件区分（カテゴリ）として「保険」が選択されている場合に表示される要約設定画面である。サブカテゴリとして保険種別２６０１が表示されており、自動車保険が選択されている。
サブサブカテゴリとして、対応方法種別２６０２が表示されており、手続きが選択されている。
【0127】
キーワード指定２６０３は、要約を生成する際に使用する用語を指定する。要約生成モジュール２１４は、ここに指定された用語を含む要約を生成する。
長さ調整２６０４は、生成する要約文の長さを調整するものであり、この例では１８０文字までの要約が生成される。なお、この例では要約文の長さの上限を指定するものであるが、この他にも下限も指定するものや、目安の要約文の長さを指定するもの、としてもよい。
箇条書き２６０５を選択すると、長い文章ではなく箇条書きの要約が生成される。
長さ調整２６０４は、生成する要約文の長さを調整するものであり、この例では１８０文字までの要約が生成される。なお、この例では要約文の長さの上限を指定するものであるが、この他にも下限も指定するものや、目安の要約文の長さを指定するもの、としてもよい。
箇条書き２６０５を選択すると、長い文章ではなく箇条書きの要約が生成される。
【0128】
日時表現の表記ゆれ修正機能２６０６を選択すると、対話テキストに様々な形式の日時表現が用いられている場合であっても、要約の日時の表現を統一した形式で要約を生成する。
その他、表現の表記揺れを修正する機能を備えてもよい。例えば「今日」を全て「本日」に修正するような設定を行うことができる。
要約箇所指定２６０７は、要約対象となる対話テキストやメモなどの入力の場所を指定することができる。例えば、この要約箇所指定２６０７をクリックすると、対話テキストやメモの一部の領域の指定を受け付ける画面を表示し、指定された領域の部分を要約対象とすることができる。
これらの設定を行い、要約スタートボタン２４３５を押すことで、要約生成モジュール２１４は、対話テキストから設定された内容で要約を生成する。
その他、表現の表記揺れを修正する機能を備えてもよい。例えば「今日」を全て「本日」に修正するような設定を行うことができる。
要約箇所指定２６０７は、要約対象となる対話テキストやメモなどの入力の場所を指定することができる。例えば、この要約箇所指定２６０７をクリックすると、対話テキストやメモの一部の領域の指定を受け付ける画面を表示し、指定された領域の部分を要約対象とすることができる。
これらの設定を行い、要約スタートボタン２４３５を押すことで、要約生成モジュール２１４は、対話テキストから設定された内容で要約を生成する。
【0129】
上述のように、要約の出力を変化させるための以下に挙げるような様々な機能を提供する。
・問合せ内容のカテゴリ情報を指定して、要約の出力をコントロールする機能。
・キーワードを指定することで、出力にそれらのワードを反映させる機能。
・要約の長さを調整する機能。
・要約を箇条書き形式で出力する機能。
・表現の表記揺れを修正する機能。
・要約箇所を、対話テキストやメモなどのinputから指定する機能。
・問合せ内容のカテゴリ情報を指定して、要約の出力をコントロールする機能。
・キーワードを指定することで、出力にそれらのワードを反映させる機能。
・要約の長さを調整する機能。
・要約を箇条書き形式で出力する機能。
・表現の表記揺れを修正する機能。
・要約箇所を、対話テキストやメモなどのinputから指定する機能。
【0130】
図２７は、参照情報呼び出し設定画面２７００の例である。
顧客応対処理モジュール２１１は、画面左上の対話テキストボタン２７０１の選択を受け付けると、対話テキストの内容を表示する。
顧客応対処理モジュール２１１は、ＦＡＱボタン２７０２の選択を受け付けると、データ検索モジュール２１８を呼び出す。データ検索モジュール２１８は、既に選択されているカテゴリ情報を取得し、図１２のＦＡＱ情報１２００から、これに対応するカテゴリＩＤ等１２０２で指定されたＦＡＱデータを、ＦＡＱデータ格納ＵＲＬ１２０３で指定された場所から取得する。
その他、顧客応対中に使われたＦＡＱや、対話テキストに基づいて検索されたＦＡＱ等を表示することもできる。
顧客応対処理モジュール２１１は、画面左上の対話テキストボタン２７０１の選択を受け付けると、対話テキストの内容を表示する。
顧客応対処理モジュール２１１は、ＦＡＱボタン２７０２の選択を受け付けると、データ検索モジュール２１８を呼び出す。データ検索モジュール２１８は、既に選択されているカテゴリ情報を取得し、図１２のＦＡＱ情報１２００から、これに対応するカテゴリＩＤ等１２０２で指定されたＦＡＱデータを、ＦＡＱデータ格納ＵＲＬ１２０３で指定された場所から取得する。
その他、顧客応対中に使われたＦＡＱや、対話テキストに基づいて検索されたＦＡＱ等を表示することもできる。
【0131】
前述のように、カテゴリ情報は、オペレータが指定することも可能であるが、対話テキストの内容から自動的にカテゴリ情報を選択することができる。従って、オペレータがＦＡＱボタン２７０２を選択すると、カテゴリ情報を介してこれらの対話テキストに対応付けられた関連するＦＡＱデータが取得され、表示される。
【0132】
外部連携２７０３は、その他の外部システム呼び出すためのボタンである。
対話テキストの他、通話中に参照したＦＡＱや、Ｗｅｂシステム等のその他使用サービスのログ等を要約を生成するための入力として使用することもできる。
図２８は、フィードバック受付画面２８００の例である。
フィードバックモジュール２１７は、生成された要約に対する評価２８０１を受け付ける。フィードバックモジュール２１７は評価取得モジュールと呼ぶこともある。
また、フィードバックモジュール２１７は、要約文欄２８３０に表示されている要約に対して、ユーザからの編集や修正を受け付けることができる。なお、フィードバックモジュール２１７の代わりに、要約の編集の受付を行う別の要約編集モジュールを備える構成としてもよい。
対話テキストの他、通話中に参照したＦＡＱや、Ｗｅｂシステム等のその他使用サービスのログ等を要約を生成するための入力として使用することもできる。
図２８は、フィードバック受付画面２８００の例である。
フィードバックモジュール２１７は、生成された要約に対する評価２８０１を受け付ける。フィードバックモジュール２１７は評価取得モジュールと呼ぶこともある。
また、フィードバックモジュール２１７は、要約文欄２８３０に表示されている要約に対して、ユーザからの編集や修正を受け付けることができる。なお、フィードバックモジュール２１７の代わりに、要約の編集の受付を行う別の要約編集モジュールを備える構成としてもよい。
【0133】
フィードバックモジュール２１７は、高い評価をつけられた要約文や、高い評価をつけられた要約文の元になった文書情報（対話テキスト）や、ユーザにより修正された要約文、を蓄積し、これらを用いて機械学習モデルを再学習し、機械学習モデルを改善することができる。
他には、例えばＤＢ（Database）にＡＩが生成した要約と、ユーザが修正した要約、評価スコア、ユーザの要約とＡＩの要約の差分がどれくらいあったか、の指標等を記憶することもできる。
他には、例えばＤＢ（Database）にＡＩが生成した要約と、ユーザが修正した要約、評価スコア、ユーザの要約とＡＩの要約の差分がどれくらいあったか、の指標等を記憶することもできる。
【0134】
ユーザが修正したテキストの保存は、ＡＰＩでＣＲＭ等への反映を行う場合には、その操作の際に反映され、コピーアンドペースト等で別に貼り付ける際には、コピーボタンを押した時に反映されるようにすることができる。また、コピーボタンではなく、更新や反映というボタンであってもよい。また、更新は、明示的にボタン等を押さなくても、バックグラウンド等で自動的に実行される形式でもよい。
このように、生成された要約文に対してユーザが評価、修正を繰り返すHuman in the Loopの仕組みにより、モデルの精度を向上することができる。
また再学習には、ＡＩにより生成された要約と人により修正された要約の差分のスコアを用いたり、また修正でどれくらい変更されたか、等の情報を用いることもできる。
このように、生成された要約文に対してユーザが評価、修正を繰り返すHuman in the Loopの仕組みにより、モデルの精度を向上することができる。
また再学習には、ＡＩにより生成された要約と人により修正された要約の差分のスコアを用いたり、また修正でどれくらい変更されたか、等の情報を用いることもできる。
【0135】
モデルの再学習は、人が定期的に手動で再学習をする方法の他、定期的に再学習が走るパイプラインを構築することもできる。
また、学習対象のデータとしては、データベース内の全データで学習し直す方法の他、データベース内のうち、スコアがあまり良くなかったものを優先的に学習する方法も考えられる。
また、モデルの生成結果に対して、修正作業をＢＰＯ（Business Process Outsourcing）化し、改善した上で提供する仕組みを提供することもできる。
また、学習対象のデータとしては、データベース内の全データで学習し直す方法の他、データベース内のうち、スコアがあまり良くなかったものを優先的に学習する方法も考えられる。
また、モデルの生成結果に対して、修正作業をＢＰＯ（Business Process Outsourcing）化し、改善した上で提供する仕組みを提供することもできる。
【0136】
図３１は別のフィードバック受付画面３１００の例である。
ユーザは、テンプレートを出力して、そこから要約を新たに書き始める事ができる。例えば、フィードバックモジュール２１７は、要約文３１３０の横に表示された「テンプレート出力」のボタン３１３１の選択を受け付けた場合に、要約文に任意入力用のテンプレートを表示する。フィードバックモジュール２１７は、その前に入力されたカテゴリ（手続き型、自動車保険等）の内容に基づいて、出力するテンプレートの内容を変更することができる。
ユーザは、テンプレートを出力して、そこから要約を新たに書き始める事ができる。例えば、フィードバックモジュール２１７は、要約文３１３０の横に表示された「テンプレート出力」のボタン３１３１の選択を受け付けた場合に、要約文に任意入力用のテンプレートを表示する。フィードバックモジュール２１７は、その前に入力されたカテゴリ（手続き型、自動車保険等）の内容に基づいて、出力するテンプレートの内容を変更することができる。
【0137】
また、フィードバックモジュール２１７は、カテゴリの情報が事前に入力されていない場合等には、テンプレート出力の選択に従って、テンプレート選択パネル３１３２を表示し、このパネル内でテンプレートを選択の選択を受け付けるようにしてもよい。また、カテゴリを階層構造にしてもよく、対話文の内容に基づいてテンプレートを自動で選択したり、確率の高い候補を推薦したりすることもできる。
なお、要約生成モジュール２１４がテンプレートを出力する構成でもよい。
なお、要約生成モジュール２１４がテンプレートを出力する構成でもよい。
【0138】
図２９は、管理者端末１０３に表示される作業状況表示画面２９００の例である。
管理者端末１０３のユーザ端末管理モジュール４１０は、各ユーザ端末を使用する複数のユーザのＡＣＷ作業の効率を監視できる機能を提供する。
ユーザ端末管理モジュール４１０は、各重要属性毎に、ＡＣＷにかかった時間の分布・統計値を表示する。例えば属性としては、時間（月・週等）毎、ユーザ（オペレータ）毎、顧客応対の内容のカテゴリ毎、等でソートやフィルタリングしながら、各ユーザのＡＣＷ作業のログを表示することができる。
図２９の例では、各通話（やり取り）の一覧を確認・フィルタリングすることができる。また各項目が選択されると、ユーザ端末管理モジュール４１０は、図３０の作業状況詳細表示画面３０００を表示する。
管理者端末１０３のユーザ端末管理モジュール４１０は、各ユーザ端末を使用する複数のユーザのＡＣＷ作業の効率を監視できる機能を提供する。
ユーザ端末管理モジュール４１０は、各重要属性毎に、ＡＣＷにかかった時間の分布・統計値を表示する。例えば属性としては、時間（月・週等）毎、ユーザ（オペレータ）毎、顧客応対の内容のカテゴリ毎、等でソートやフィルタリングしながら、各ユーザのＡＣＷ作業のログを表示することができる。
図２９の例では、各通話（やり取り）の一覧を確認・フィルタリングすることができる。また各項目が選択されると、ユーザ端末管理モジュール４１０は、図３０の作業状況詳細表示画面３０００を表示する。
【0139】
図３０は、作業状況詳細表示画面３０００の例である。
作業状況詳細表示画面３０００では、対話テキスト欄３０１０に対話テキストの文書情報が表示され、メモ欄３０２０にユーザが記入したメモが表示される。
また、問合せ内容入力欄３０５０には選択されているカテゴリの情報が表示され、設定ボタン３０５１を押すことで選択されたカテゴリが決定される。
要約欄３０３０には、対話テキストから生成された要約が表示される。
カテゴリの選択を修正した場合等には、要約開始ボタン２０３１を再度押すことで、再度要約を生成することができる。
作業状況詳細表示画面３０００では、対話テキスト欄３０１０に対話テキストの文書情報が表示され、メモ欄３０２０にユーザが記入したメモが表示される。
また、問合せ内容入力欄３０５０には選択されているカテゴリの情報が表示され、設定ボタン３０５１を押すことで選択されたカテゴリが決定される。
要約欄３０３０には、対話テキストから生成された要約が表示される。
カテゴリの選択を修正した場合等には、要約開始ボタン２０３１を再度押すことで、再度要約を生成することができる。
【0140】
。
ＣＲＭに反映ボタン３０６０を押すと、最終的にここに表示された全体の内容をＣＲＭシステムに記憶する。
本実施例によれば、工数が大きいＡＣＷの作業を効率化することができる。また、高精度の要約が自動で生成され、それをＷｅｂ上で即座に表示できることができる。
また生成された要約は修正しやすいＵＩで表示し、ＡＣＷの業務全体をシンプルな１つの顧客応対管理システム１で実施できるようになる。
ＣＲＭに反映ボタン３０６０を押すと、最終的にここに表示された全体の内容をＣＲＭシステムに記憶する。
本実施例によれば、工数が大きいＡＣＷの作業を効率化することができる。また、高精度の要約が自動で生成され、それをＷｅｂ上で即座に表示できることができる。
また生成された要約は修正しやすいＵＩで表示し、ＡＣＷの業務全体をシンプルな１つの顧客応対管理システム１で実施できるようになる。
【0141】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【0142】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【0143】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。
【符号の説明】
【0144】
１…顧客応対管理システム、１０２…ユーザ端末、１０３…管理者端末、２１１…顧客応対処理モジュール、２１２…カテゴリ選択モジュール、２１３…文書情報取得モジュール、２１４…要約生成モジュール、２１５…メモ情報取得モジュール、２１６…強調表示モジュール、２１７…フィードバックモジュール、２１８…データ検索モジュール
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】