JP2008123447A - オペレータ業務支援システム - Google Patents

Abstract

【課題】コールセンター業務において、オペレータが顧客に伝達すべき内容が、実際に伝達されたかどうかのチェックを行うことができるオペレータ業務支援システムを提供する。
【解決手段】オペレータ業務支援システム１において、オペレータが伝達すべき内容に関するキーワードと、そのキーワードを含む項目ルール５２とを含むセクション定義５０が、ＰＣ１２の記憶手段に格納される。また、音声認識部３０がオペレータの音声を文字列に変換してテキストデータを得、さらにこのテキストデータからキーワードを抽出する。さらに、キーワード処理部３２が、項目ルール５２と、抽出されたキーワードとの照合を行ってその結果を出力する。
【選択図】図２

Description

本発明は、オペレータ業務支援システムに関する。

コールセンター業務において、運用コスト削減のために、１件あたりの処理時間をいかに短くするかが大きな命題となっている。受発注系の業務（たとえば通販などにおけるもの）の定型化された業務では、応対マニュアルや顧客情報を、着信と同時に画面ヘポップアップするシステムなど、様々な支援ツールが開発・適用されている。
技術サポート系のコールセンターでは、応対内容が定型化できず、内容が多岐に渡り、また一件あたりの通話時間が長くなる。このような技術系サポートにおいては、音声認識技術によってオペレータの音声をテキストログ化し、また録音された音声とテキストログとを関連付けて保存することにより、業務ログ作成に要求されるオペレータの負荷を軽減し、また作業時間を短縮している。このようなオペレータ業務支援システムの例は、特許文献１に記載される。

特開２００６−１２６９６６号公報

一方、商品相談などにおいては、応対内容として特定の伝達項目が必須となるケースがある。また、最初の説明、中間の必須伝達項目、最後の説明というように、各事項を適切な順序で、抜けがなく伝達することが要求される。さらに、オペレータにとって望ましくない発言内容をＮＧワードとして定義しておくことが望ましい。オペレータ業務においては、このような事項が、遵守されるべきコンプライアンスとして存在する。

オペレータ業務支援システムには、画面に表示されるインタフェースによってオペレータに制御されるものがある。たとえば、それぞれ特定の商品や会話状況に対応した複数のボタンが表示され、オペレータがボタンをクリックすることにより、状況に応じた内容の応対ガイドが表示されるものや、オペレータが通話の状況を複数の項目によって入力することにより、次に伝達すべき内容がトークスクリプトとして表示されるものがある。

テキストログ化されたオペレータの発話内容から、特定のキーワードを検出し、検出されたキーワードに応じた処理を行うものもある。ここで、キーワードに応じた処理とは、そのキーワードが本来使用してはいけないＮＧワードであることをオペレータに警告する処理や、そのキーワードを重要単語としてテキストログ中で強調表示する処理が含まれる。

このような支援システムの動作を、図１２ａ〜図１２ｅに示す画面例を用いて説明する。
図１２ａは、オペレータによる操作の中心となるメイン画面８００の例である。メイン画面８００は、通話開始ボタン８０１を含む。オペレータは、このボタンをクリックすることにより、図１２ｂに示すような応対ログ内容表示画面８１０を表示させることができる。この画面には、一つの通話におけるオペレータの発話内容が音声認識エンジンによってテキストログ化されたデータが表示される。また、この画面には、テキストログから抽出されたキーワードの一覧が表示される。
これらの表示は、通話の進行に伴ってリアルタイム方式で更新される。

メイン画面８００は、応対ログ一覧表示ボタン８０２を含む。オペレータは、このボタンをクリックすることにより、図１２ｃに示すような応対ログ一覧表示画面８２０を表示させることができる。この画面には、過去に記録された複数の通話に対応する応対ログの一覧が表示される。この画面において一つの応対ログを選択すると、図１２ｄに示すように、その応対ログに含まれるキーワードの一覧を含むキーワード一覧画面８３０が表示される。

また、図１２ｃの応対ログ一覧表示画面８２０において、オペレータが一つの応対ログを指定して聞き起こしボタン８２１をクリックすると、図１２ｅに示す聞き起こし画面８４０が表示される。オペレータは、聞き起こし画面８４０を使用して、過去に録音された通話の音声を聞きながら、それに合わせてテキストデータを修正する作業を行う。

このような構成によって、従来の支援システムは、オペレータが顧客に伝達すべき内容のガイドを行い、また、ＮＧワード、すなわちオペレータが使用するべきでないキーワードのチェックを行う。

しかしながら、上述のような従来のオペレータ業務支援システムにおいては、オペレータが顧客に伝達すべき内容が、実際に伝達されたかどうかのチェックを行うことができないという問題があった。

伝達すべき内容のガイドを行う従来技術では、ガイドされた内容が実際に伝達されたかどうかのチェックまで行うものはない。この理由の一つは、状況によって、オペレータは必ずしもガイドの内容を一言一句そのまま伝達するわけではないため、実質的に内容の伝達がなされたかどうかを判定するのが困難だからである。
とくに、オペレータの発話内容から特定のキーワードを抽出する処理を含む従来技術では、オペレータが使用するべきでないキーワードのチェックを行うものはあるが、オペレータが使用すべきキーワードが正しく使用されたかどうかのチェックや、そのようなキーワードが使用された順序やキーワード抜けのチェックを行うものはない。

このような問題があるため、コールセンター業務におけるオペレータのコンプライアンスチェック等は自動的に行うことができない。したがって、オペレータ本人による報告作業や、本人による通話ログの作成が必要となり、オペレータの作業効率やチェックの客観性に改善の余地がある。

この発明は、このような問題点を解決するためになされたものであり、オペレータが顧客に伝達すべき内容が、実際に伝達されたかどうかのチェックを行うことができるオペレータ業務支援システムを提供することを目的とする。

上述の問題点を解決するため、この発明に係るオペレータ業務支援システムは、電話を介した通話に伴うオペレータの業務を支援する、オペレータ業務支援システムであって、オペレータが伝達すべき内容に関するキーワードと、キーワードに関するルールとを格納する記憶装置と、オペレータの音声を文字列に変換することによって得られるテキストデータから抽出されたキーワードと、ルールとの照合を行い、照合の結果を出力する、キーワード処理部とを備える。

ルールは、キーワードが伝達されるべきであるということを表すものを含んでもよい。
ルールは、キーワードが伝達される順序を表すものを含んでもよい。
記憶装置は、通話のパターンを表す複数のシナリオと、複数のシナリオにおける発話のまとまりを表す複数のセクションとを格納し、セクションの少なくとも一つは、少なくとも一つのルールを含み、キーワード処理部は、キーワードとの照合に用いるルールを、セクションを単位として選択してもよい。
シナリオの編集作業のためのグラフィカルユーザインタフェースをさらに備えてもよい。
キーワード処理部は、キーワードとの照合に用いるルールを、通話の状況に応じて追加してもよい。
結果の出力は、画面表示によって行われてもよい。
また結果の出力は、記憶装置に、通話単位で照合結果を記憶することによって行われてもよい。
キーワード処理部は、通話が終了する前にキーワードとルールとの照合を開始してもよい。

この発明によれば、オペレータ業務支援システムにおいて、キーワード処理部が、オペレータの発話から抽出されたキーワードと、キーワードに関する項目ルールとの照合を行い、その結果を出力する。このため、オペレータが顧客に伝達すべき内容が、実際に伝達されたかどうかのチェックを行うことができる。

以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１は、本発明の実施の形態１に係る音声認識エンジンおよびオペレータ業務支援ツールを含む、オペレータ業務支援システム１を含む構成を示す図である。
公衆交換電話網（Public Switched Telephone Network, PSTN)２に、コールセンター用の構内交換機(Private Branch eXchange, PBX)４が接続されている。この構内交換機４は、たとえばＡＶＡＹＡ社のＤｅｆｉｎｉｔｙである。

構内交換機４には、オペレータ２０宛の通話を受けるオペレータ用電話機である電話機６が接続される。さらに電話機６は、オペレータ２０が業務に使用するオペレータ用ＰＣであるＰＣ１２およびヘッドセット１４に、プラグアダプタ８と切り替え部であるスイッチボックス１０を介して接続される。
この電話機６は、構内交換機４からの信号を受信して、プラグアダプタ８を介してスイッチボックス１０に送信するスピーカ出力端子６ａと、スイッチボックス１０からの信号を受信して構内交換機４に送信するマイク出力端子６ｂとを備えており、たとえばＡＶＡＹＡ社のＣａｌｌｍａｓｔｅｒ ＩＶが使用される。なお、電話機の種類によってはプラグアダプタの機能を包含している場合や、通常のモジュラジャックの場合もある。

ヘッドセット１４は、スイッチボックス１０からの信号を音声に変換してオペレータ２０に伝えるスピーカ１４ａと、オペレータ２０が発する音声を信号に変換してスイッチボックス１０に送るマイク１４ｂとを備えており、たとえばＶＸＩ社のＴｕｆｆＳｅｔシリーズ、Ｐａｓｓｐｏｒｔシリーズが使用される。

ＰＣ１２は、演算装置および記憶装置を有する、周知の構成を持つコンピュータであり、出力装置としての画面を有するディスプレイおよびスピーカ出力端子と、入力装置としてのキーボード、マウス、およびライン入力端子とを備える。たとえば、演算装置としてクロック周波数３ＧＨｚで作動するＰｅｎｔｉｕｍ（登録商標）４プロセッサ等のＣＰＵを備え、記憶装置として１ＧＢの容量を持つメモリおよび１６０ＧＢの容量を持つハードディスクドライブを備えるものである。また、ＰＣ１２は、ネットワークを介して入出力を行うためのネットワークインタフェースを備える。
なお、ＰＣ１２は、ライン入力端子を通して、２つの音声入力、たとえばステレオ音声のＬチャネルとＲチャネルのような独立した音声データである信号を同時に受け付け、単一のファイルとして記憶装置に格納することが可能である。ただし、このファイル中において、ＬチャネルおよびＲチャネルはそれぞれ独立に記録され、後に独立してスピーカ出力端子を通して再生できる形式となっている。

図２は、ＰＣ１２の論理的な構成の概略を示す。ＰＣ１２は、入力された音声を文字列に変換する音声認識エンジンを含むログ化装置である音声認識部３０と、音声認識の結果であるテキストデータに基づいて通話に含まれるキーワードの処理を行うキーワード処理部３２とを備える。すなわち、ＰＣ１２のＣＰＵは、記憶装置に格納されるプログラム（図示せず）を実行することにより、音声認識部３０およびキーワード処理部３２として機能する。

ＰＣ１２の記憶装置は、データであるセクショングループ定義４０と、セクション定義５０と、ＮＧルール定義６０と、処置ルール定義７０とを格納する。
ここで、これらの定義は、コールセンターでの通話において、オペレータの説明等によって伝達されるべき内容に関する定義を含む。本明細書において、コールセンターにおける通話を以下のようにモデル化し、これに沿ってそれぞれのデータを定義する。なお、本明細書において「伝達」とは、オペレータの発話が実際に顧客に伝達されたかどうかに関わらず、オペレータの発声が音声認識部３０によってテキスト化された内容に含まれているかどうかによって判断されるものとする。

オペレータの業務種別毎に、いくつかの標準的な業務遂行のパターンが定義される。このパターンを「シナリオ」と呼ぶ。シナリオの例としては、商品ごとに定義される問い合わせに対応するシナリオ（Ａ商品に関する問合せのシナリオ、Ｂ商品に関する問い合わせのシナリオ、等）や、クレームの種別ごとに定義されるシナリオがある。

各シナリオは、より細かい会話の単位として、発話のまとまりを表す「セクション」を含む。このセクションの例としては、着信直後の一般的な挨拶、商品説明の前の注意事項、商品ごとの概要説明、費用の発生に関する説明、質問事項の有無の確認、資料送付希望の確認、通話終了時の挨拶、等がある。シナリオはセクションに分割され、逆にセクションを接続することでシナリオが構成される。
セクションは、特定の商品の説明のように特定のシナリオにのみ含まれるものと、挨拶のように複数のシナリオに共通して含まれるものとがある。なお、この「セクション」は、「ブロック」等と呼ばれるものであってもよい。

会話の単位として、シナリオおよびセクションの中間となる「セクショングループ」が定義されてもよい。すなわち、セクションの集合がセクショングループであり、セクショングループの集合がシナリオとなる。セクショングループは任意であり、定義されなくともよく、また数段階に渡って階層的に定義されてもよい。また、セクショングループ内に、セクショングループを定義するといった、セクショングループを多重化することも可能である。
各シナリオ内において、セクショングループおよびセクションには、他のセクショングループおよびセクションとの間に順序関係（すなわち連続性）を有するものと、有しないものとがある。このような関係を有しないものは、所定の範囲内でどの順序で伝達されてもよいことになる。

図２に示すセクショングループ定義４０は、各シナリオについて、そのシナリオに含まれるセクションおよびセクショングループ間の関係を定義するデータである。
図３に、セクショングループ定義４０の構成の例を示す。図３の例では、セクショングループ定義４０に、２つのシナリオ、すなわちシナリオ（１）およびシナリオ（２）についての定義が含まれている。なお、図３においてシナリオの例は参照符号４１で示される。

各シナリオは、セクショングループ、セクション、フリーセクション、処置ルール、およびこれらの間の接続関係を示すシーケンスを含み、各セクションおよびフリーセクションが実行される条件を定義する。
なお、本明細書においてセクション等が「実行される」とは、ある通話において、そのセクション等に定義される会話に関するルールが有効なものとして適用されるということを意味する。

セクションは、オペレータからユーザすなわち顧客への伝達が必要な内容をキーワードによって定義し、そのルール範囲を定義したものであるが、詳細は図６ａを用いて後述する。なお、セクションの例は、図３および図６ａにおいて参照符号５１で示される。
セクションは、その定義を空（未定義）とすることができ、これは適用ルールがないことを示す。
フリーセクションは、他のセクションとの間に順序関係が定義されないセクションであり、特定の範囲内であればどの時点で実行されてもよい。

図３のシナリオ（１）は、その内部構造として、セクショングループ（１）〜（３）を含む。セクショングループ（１）〜（３）はこの順序で実行される。セクショングループ（１）は、セクションとしてオープニングセクションＳ−１を含む。セクショングループ（１）からセクショングループ（２）へは、特定の「商品選択」されたときに移行する。
セクショングループ（２）は商品セクションＡ−１〜Ａ−３、商品セクションＢ−２、フリーセクションＸ−２およびＸ−３を含む。セクショングループ（２）内の「商品セクションＡ−１」から「商品セクションＡ−２」または、「商品セクションＢ−２」への移行は、それぞれのセクションに対応する商品が選択されたときに、移行する。また「商品セクションＡ−２」からは、通常「商品セクションＡ−３」に移行するが、特定の条件（図３では、「＊接続条件３＊」と記載）が発生したとき、それが前提条件付き参照シーケンスとなり、「フリーセクションＸ−３」に移行する。
さらに、「フリーセクションＸ−２」から特定の条件（図３では、「＊接続条件１＊」と記載）が発生したとき、それが前提条件付き参照シーケンスとなり、「処置ルール１」に移行する。また「商品セクションＢ−２」から特定の条件（図３では、「＊接続条件２＊」と記載）が発生したとき、それが前提条件付き参照シーケンスとなり、「処置ルール２」に移行する。
また、シナリオ（１）は、セクショングループに属さないフリーセクションＸ−１を含む。フリーセクションＸ−１は、シナリオ（１）内においていかなる順序で実行されてもよい。

なお、各セクションの間には単なる順序だけでなく、セクション間の遷移に関するその他の条件も定義可能である。
フリーセクションＸ−２は、セクショングループ（２）が実行中であればいつ実行されてもよい。

処置ルールは、通話における「不正」に関連する、特定の状況が発生した場合の対応を定義するものである。この特定の状況を表す条件は、不正の総数、不正が発生したセクションの総数、不正の内容を含む。なお、この「不正」の内容詳細については後述するが、たとえばセクション内でキーワードが伝達されるべき順序が入れ替わってしまった場合や、伝達されるべきキーワードが伝達されなかった場合を含む。
処置ルールの適用範囲は自由に定義でき、シナリオ内全体で共通に適用されるルール、特定のセクショングループ内でのみ共通に適用されるルール、および、特定のセクション内でのみ適用されるルールが定義できる。

図３では、セクショングループ（２）には処置ルール１が接続されている。すなわち、処置ルール１はセクショングループ（２）の実行中で特定の条件（図３では、「＊接続条件１＊」と記載）が発生したとき、有効に適用される。また、同様に商品セクションＢ−２には、前提条件付き参照シーケンスとして処置ルール２が接続されている。
セクショングループ（３）はクロージングセクションＥ−１およびＥ−２を含む。クロージングセクションＥ−１およびＥ−２はいずれが先に実行されてもよい。

矢印で表されるシーケンスは、セクション等が実行される際の順序等の、互いの間のルールを示す。シーケンスによって接続されないセクションは、順序関係が定義されていない。フリーセクションの場合は、セクション順序が定義されないことを意味し、また、フリーセクションでない通常のセクションである場合は、そのセクションが特定の条件で自動的に実行されることはなく、オペレータの選択操作によって一時的に実行されることを意味する。この選択操作は、たとえば特別の処理が必要なキーワードが検出され、その処理がまだ済んでおらずキーワードが保留中になっている状態で、そのキーワードの処理に関するセクションをオペレータが実行したい際に行うものである。

シーケンスは、セクション等が実行される順序関係を定義する「順序シーケンス」と、セクション等が実行される特定の状況を定義する「前提条件付き参照シーケンス」を含む。「順序シーケンス」は、図３に例示したように、セクショングループ（１）からセクショングループ（２）のように、１対１で流れるように定義することもできるが、商品セクションＡ−１から、商品セクションＡ−２または、商品セクションＢ−２のどちらかに移行するように、検出されたキーワードにより、１つのセクションから複数のセクションに移行するように定義することもできる。
前提条件付き参照シーケンスは、セクション間の接続のルールとしてキーワードを含む条件を設定するものである。これによって、会話の進行状況すなわちキーワードチェックの結果に対応した、動的なシーケンスの変更が可能となる。たとえば、ＮＧワードとして定義される特定のキーワードをオペレータが発した場合は、そのフォローを行うために定義されたセクションを追加して実行するということが可能になる。
また前提条件付き参照シーケンスは、前のセクションの状態により移行するように定義することもできる。例えば図３のフリーセクションＸ−３の条件に記載しているように、前のセクションが完了している（該当キーワードが全て充足している）、または前のセクションが進行中であるときに、移行するなどと規定できる。

シナリオ、セクショングループ、セクション等は、それぞれ複数定義でき、各々を示す識別番号で一意に管理される。セクションは、全シナリオを通じて一意の定義である識別番号と、各シナリオ内で割り当てられる、そのシナリオ内でのみ有効な相対番号とを有してもよい。また、同一のセクションが複数のシナリオに共通して含まれてもよい。すなわち、シナリオを新規に作成する際に、既存のセクションと、新規に作成するセクションとを組み合わせてもよい。これにより、共通のセクションは再利用可能となり、また、一つの共通セクションの内容に修正が発生した場合でも、一括メンテナンス管理ができる。

以上はシナリオ（１）の定義であるが、シナリオ（２）についても同様にして定義がなされる。なお、図３の例ではシナリオ（２）が商品セクションＡ−３を含むが、これはシナリオ（１）に含まれる商品セクションＡ−３と同一のものを示す。すなわち、単一のセクションが複数のシナリオに共通して含まれている。

シナリオ定義は、図３に示すようなモジュール図を表示および編集する機能を持つ管理アプリケーションで管理されるものであり、シナリオ毎に、先頭から順序関係に従って一連の内容を接続して出力することができる。
図３に例示したシナリオでは、順序を持つセクションの先頭に黒塗りの四角（■マーク）、フリーセクションの先頭に黒塗りの菱形（◆マーク）、処理ルールの先頭にビックリマーク（！マーク）を付している。これらは、説明のために付したマークであるが、セクショングループ定義４０にはこれらと同等に、セクションが順序を持つものか、フリーセクションか、処理ルールか、またはＮＧルールかが判別できるフラグが記憶されているものとする。
図４は、図３に定義されるシナリオ（１）を異なる形式で表したものである。丸付き十字記号は図３のシーケンスと同様の条件を表す。管理アプリケーションは、シナリオ内におけるセクション等の構造を、図３のようなネットワーク構造として表すこともでき、図４のようなツリー構造として表すこともできる。
図５は、図３に定義されるシナリオ（１）において、セクションおよび処置ルールのみを表示し、それぞれの間の相互関係の表示を省略したものである。また、図５において、破線で表されるセクションは他のシナリオと共有されていることを示し、実線で表されるセクションおよび処置ルールはシナリオ（１）内でのみ使用されていることを示す。管理アプリケーションは、このように、セクションや処置ルール等が他のシナリオと共有されているかどうかのみを簡略化して示すことができる。また、システム管理者が管理アプリケーションにより、シナリオを作成するとき、まずはシナリオの大枠を例えば、Ａ商品に関する問合せのシナリオを決め、その次に、シナリオ内のセクショングループを、オープニングセクション、Ａ商品説明セクション、クロージングセクションと決め、その後、それぞれのグループセクション内のセクションを、シーケンスとともに定義する。そのシナリオ作成時に、既に作成済みのシナリオで定義したセクションを流用することが可能である。すなわち、セクションは複数のセクショングループ、複数のシナリオで流用することができる。

なお、オペレータ業務支援システム１は、このようなシナリオ定義の編集作業のためのグラフィカルユーザインタフェース（ＧＵＩ）を備えてもよい。このグラフィカルユーザインタフェースは、キーワード処理部３２によって提供されるものであってもよく、他の手段によって提供されるものであってもよい。ＧＵＩを用いて入力されたシナリオは、管理アプリケーションで、管理/編集され、記憶装置に記憶されたセクショングループ定義４０、セクション定義５０、ＮＧルール定義６０、処置ルール定義７０の各定義内容に追加、更新される。
ここで、グラフィカルユーザインタフェースとは、編集者に対してデータを出力する際に画像を含む画面表示によって行う機能と、その画面表示に対するマウス等のポインティングデバイスによる操作を入力として受け付ける機能とを有するインタフェースを意味する。

図２に示すセクション定義５０は、シナリオに含まれる各セクションについて、そのセクションに含まれる項目ルールを定義するデータである。
図６ａに、セクション定義５０の構成の例を６つ示す。なお、説明の明確化および簡略化のため、図６ａに示されるセクション定義は、図３に示されるセクションのすべてを網羅するものではなく、また図３に示されないセクションを一部含む。

各セクションは、そのセクションを他のセクションと区別するための定義名称および定義番号を含む。これはたとえばセクション定義内で先頭の行に記述される。
図６ａの「商品セクションＡ−２」の例では、「商品セクションＡ−２」が定義名称であり、「Ａ００２」が定義番号である。

また、各セクションは、『』記号によって囲まれる代表行を含む。代表行は、<>記号によって囲まれる、オペレータがそのセクションを認識しやすくするためのタイトルを含む。このタイトルは、たとえばオペレータ用の画面表示に使用される。さらに、代表行は、タイトルの後に定義される、そのセクションが開始される条件を含む。
セクションが開始される条件は、特定のキーワードを含んで定義される場合がある。キーワードに関する条件は次のいずれかを含み得る。
・あるキーワードが顧客に伝達された場合
・複数のキーワードのいずれか一つが伝達された場合（すなわち論理和）
・複数のキーワードのすべてが、一定時間内で伝達された場合（すなわち論理積）
・複数のキーワードのすべてが、一定時間内で、特定の順序に従って伝達された場合
また、上記の条件の組合せが定義されてもよい。なお、ここで「一定時間内」とは、本システムによって、予め決まっている時間であるが、システム管理者によって適宜指定することが可能な時間である。例えば５分と指定した一定時間の発話で、前記のキーワードに関する条件が確認される。
また一定時間ではなく、発話数（例えば２０発話）で前記のキーワードに関する条件が確認してもよい。なお１つの「発話」とは、外部からキーワード処理部３２（図２参照）に対して提供される、テキスト化された一まとまりの発話を意味する。これはどのように提供されるものであってもよいが、たとえば音声認識部３０（図２参照）が、３００ｍｓ以上の時間にわたってオペレータ音声の音量が一定未満である部分を区切りとして検出し、この区切りと区切りの間に相当するテキストを１つの発話としてキーワード処理部３２に提供するものである。

キーワードは、単語であってもよく、複数の単語を含んでもよく、文の一部または全部であってもよい。例としては、「担当」、「電話番号」、「商品Ａ」「Ａ投資信託」「Ａ投資信託メニュー」等の特定の商品名、「リスク」、「このメニュー」、「信託報酬」、「確約」、「確約ができない」、「確約はできない」、「分かりません」、「お申込みの詳細」等がある。

図６ａの「商品セクションＡ−２」の例では、「リスクの説明」がタイトルである。このセクションは、オペレータが「リスクのご説明」というキーワードを伝達した場合、あるいは「リスク」というキーワードと「ご説明」というキーワードを一定時間内で伝達した場合に実行が開始される。

各セクションは、代表行に続いて、一行あるいは複数行の項目ルール行を含む場合がある。図６ａにおいて、項目ルールの例は参照符号５２で示される。各項目ルール行は墨付きカッコによって囲まれ、そのセクション内で適用される、キーワードに関するルールが定義される。また、項目ルール行は、該当セクション内でルールが充足されるべき順序を示す数字と、<>記号によって囲まれる、オペレータがその項目ルールを認識しやすくするための表題とを含む。この表題は、たとえばオペレータ用の画面表示に使用される。
キーワードに関するルールは、上述のセクションが開始される条件と同様に、次のものを含む。
・あるキーワードが顧客に伝達されるべきであることを示すルール
・複数のキーワードのいずれか一つが伝達されるべきであることを示すルール（すなわち論理和）
・複数のキーワードのすべてが、一定時間内で伝達されるべきであることを示すルール（すなわち論理積）
・複数のキーワードのすべてが、一定時間内で、特定の順序に従って伝達されるべきであることを示すルール
また、上記のルールの組合せを含んでもよい。

図６ａの「商品セクションＡ−２」の例では、２つの項目ルールが定義されている。
第一の項目ルールの表題は「変動割合リスクの説明」である。この項目ルールによれば、オペレータは、「リスクについて」または「リスクは」というキーワードのいずれかと、「割合で運用」というキーワードとを一定時間内で顧客に伝達するべきであることが示される。
第二の項目ルールの表題は「信託報酬請求の説明」である。この項目ルールによれば、オペレータは、まず「Ａ投資信託」または「このメニュー」というキーワードのいずれかを顧客に伝達し、その後、一定時間内で、「信託報酬」および「請求」というキーワードの両方を顧客に伝達すべきであることが示される。

また、第一の項目ルールには順序が「１」として定義され、第二の項目ルールには順序が「２」として定義されている。これは、まず第一の項目ルールの条件が充足され、次に第二の項目ルールの条件が充足されるべきであることを意味する。
なお、項目ルールは充足されるべき順序を持たないものであってもよい。たとえば図６ａの「オープニングセクションＳ−１」において、「希望担当の確認」という表題を有する項目ルールには順序として「０」が定義されているが、これはこの項目ルールが当該セクション内でいつ充足されてもよく、また充足されなくともよいことを意味する。さらに、図６ａの「オープニングセクションＳ−２」において、すべての項目ルールに順序として「１」が定義されているが、これは項目ルール間の順序関係が存在しないことを意味する。
また「商品セクションＡ−１」の例では、タイトルの次に、（）記号が定義されているが、これはそのセクションへの導入キーワードが定義されていないことを示している。この場合は、「商品セクションＡ−１」の第一の項目ルール（表題「商品説明」）が充足されたときに、「商品セクションＡ−１」に移行したとみなす。
なお、図示しないが、各セクションは、そのセクションの実行が終了する条件を表す項目ルールを含んでもよい。

また、セクション定義５０は、定義される各セクションについて、項目ルールおよびオペレータの模範的対応を示すスクリプトを含む。このスクリプトは、そのまま音読すればそのセクションの項目ルールが充足されるように、あらかじめ作成されるものである。また、スクリプト中で項目ルールに対応するキーワードは、カッコ、下線、太字、反転表示等によって強調表示されるよう指定されてもよい。
たとえば、商品セクションＡ−２のスクリプトは、「<リスクの説明>［リスクについて］ですが、本製品は株式８０％の組み入れ［割合で運用］するため、変動割合がほかの製品に比して大きくなっています。［Ａ投資信託］メニューですが、［信託報酬］を毎年１％ご［請求］申しあげます。」というものである。これらのセクション定義５０に記憶されている、スクリプトデータは、セクションまたは項目ルールに対応付けられている。

図２に示すＮＧルール定義６０は、特定のキーワード、とくにコールセンター業務において望ましくないキーワードが伝達された場合のルールを定義するデータである。
図６ｂに、ＮＧルール定義６０の構成の例を示す。
各ＮＧルール定義６０は、ＮＧ検出ルール６１と、ＮＧルール６２とによって構成される。ＮＧ検出ルール６１は、ＮＧワードを検出し、検出したＮＧワードにより適切なルールに分岐するための検出および分岐ルールを定義したものである。墨付きカッコにより、条件分岐ルールが定義される。図６ｂに記した、ＮＧ検出ルール６１の例では、条件分岐ルールが４つ定義されている。例えば、第一の条件分岐ルールは、タイトルが「窓口の別途案内」であるが、その指摘のキーワードに関する条件を充足したとき、ルール１に分岐することが定義されている。なお、それぞれの条件分岐ルールの先頭に記した＊は順番を持たないルールであることを示している。またＮＧ検出ルール６１の２行目、＃で始まる行は、コメント行であることを示している。

ＮＧルール６２は、図６ａに示されるセクションと同様の『』記号によって囲まれる代表行と、墨付きカッコによって囲まれる項目ルールとを含む。ＮＧ検出ルール６１の条件分岐ルールで、ルール１と、ルール２に分岐することが定義されていたため、ＮＧルール６２にはルール１と、ルール２とが定義されている。なお、各ＮＧルールは、定義名称の直後に、そのＮＧルールが適用される範囲を表す記述、たとえば「全セクション」等を含んでもよい。図６ｂの例では、「窓口ＮＧ検出」が定義名称である。
また、ＮＧ検出ルール６１の条件分岐ルールおよび、ＮＧルール６２の項目ルールの中に、（窓口名ＴＢＬ：＊）という記載があるが、これはオペレータが自分で対応することができず、自分の所属以外の窓口名を伝達したとき、適用することを示している。窓口名が１つに定まるときは、窓口名を項目ルールに記載すればよいが、窓口名の候補が複数あるとき、別の定義ファイル（この場合は、「窓口名ＴＢＬ」）に複数の窓口名を定義しておき、別の定義ファイルに指定された、いずれかの窓口名が伝達されたときは、項目ルールが実行されるように構成することができる。
またＮＧルール６２は、ＮＧルール固有の定義（図６ｂには、ルール１、ルール２と記載）により、フリーセクションとして定義される、シナリオの最後に定義される、またはＮＧルールが実行する前に実行されていたセクションの次に定義される等の設計ができる。
なお、図６ａ、６ｂに表示した、『』、墨付きカッコ、<>、＊、＃等の編集記号は、一例であり、適宜任意の編集希望を用いて設計することが可能である。

図２に示す処置ルール定義７０は、特定の状況において追加で行われるべき対応を定義するデータである。各処置ルールは、セクションおよびＮＧルールと同様に、定義名称と、代表行と、項目ルールとを含む。
項目ルールは、ある特定の状況と、追加して実行されるルールの定義を含む。これはたとえば図６ｂの「窓口の別途案内」と同様の構成をもって定義されるものであるので、詳細な説明を省略する。

このように、セクション定義５０、ＮＧルール定義６０、および処置ルール定義７０においては、キーワードであることを示す記号や、タイトル等を示すメタデータは、すべてカッコ等のテキストで示される。よってこれらはテキストファイルとして作成することができる。

以上のような構成を有するオペレータ業務支援システム１の動作を、以下に説明する。
まず、キーワード処理部３２の処理が開始される前に、音声認識部３０が、オペレータの発話である音声を入力とし、これをテキストログ化する、すなわち文字列に変換することによってテキストデータを得る。さらに、音声認識部３０は、このテキストデータからキーワードに相当する部分を抽出する。ここで、キーワードの抽出は、テキストデータのうち、図示されないキーワード辞書に定義された文字列と一致する部分を抽出することによって行われる。このような音声認識およびキーワードの抽出は、従来技術と同様にして行われるものであり、詳細な説明は省略する。

これに続くキーワード処理部３２の処理の流れを、図７および図８に示すフローチャートを用いて説明する。
全体の処理の流れを図７に示し、図７のステップＳ２１の処理の詳細を図８に示す。
まずキーワード処理部３２は、オペレータと顧客との通話が完了しているかどうか、すなわち電話が切られたかどうかを判定する（ステップＳ１）。通話が完了していない場合、キーワード処理部３２は、一定時間内にオペレータから顧客に伝達されたキーワードが音声認識部３０から送信されるのを待ち、これを受信する（ステップＳ３）。なお、このステップＳ３において、キーワード処理部３２は、それぞれのキーワードが伝達された順序と、キーワードを含む一定時間内の発話全体のテキストデータも受信する。

次にキーワード処理部３２は、受信したキーワードおよび発話全体のテキストデータを、ＰＣ１２の記憶装置（メモリ）に格納し保存する（ステップＳ４）。
次にキーワード処理部３２は、シナリオまたはセクショングループがすでに選択されているかどうかを判定する（ステップＳ５）。シナリオまたはセクショングループがまだ選択されていない場合、キーワード処理部３２は、シナリオまたはセクショングループの選択をオペレータに促し、その選択結果を受け取る（ステップＳ６）。
シナリオが新たに選択されると、対応するシナリオがセクショングループ定義４０から読み込まれる。または、通話の開始時点で所定のシナリオが読み込まれて実行されており、同一シナリオ内で新規のセクショングループが選択されたとき、セクショングループに対応する項目ルールがセクション定義５０から読み込まれる。

ステップＳ５においてシナリオまたはセクショングループがすでに選択されていた場合、またはステップＳ６が実行された後、キーワード処理部３２は、ステップＳ４で記憶された、未処理のキーワードを読み込み、セクションの開始および終了のチェックを行う（ステップＳ７）。
ステップＳ７において、セクションが開始されたかどうかは、各セクションの代表行に定義される、そのセクションが開始される条件が充足されたかどうかによって判定される。つまり、読み込んだキーワードが図６ａに記載した、いずれかのセクションのタイトル行に指定された、項目ルールを充足するとき、そのセクションが開始されたと見なす。また、オペレータは、画面上の操作により、そのセクションが開始されたことをキーワード処理部３２に指示することができ、この場合には指示されたセクションが開始されたものと判定される。
また、ステップＳ７において、セクションが終了したかどうかは、そのセクションの項目ルールの一つとして定義される、セクションの終了を表す条件が充足されたかどうかによって判定される。また、オペレータは、画面上の操作により、実行中のセクションが終了したことをキーワード処理部３２に指示することができ、この場合には指示されたセクションが終了したものと判定される。

次にキーワード処理部３２は、ステップＳ７の判定結果に応じて分岐を行う（ステップＳ８およびＳ９）。セクション開始が検出された場合はステップＳ１１に進み、セクション開始が検出されずセクション終了が検出された場合はステップＳ１７に進み、セクション開始もセクション終了も検出されなかった場合はステップＳ１０に進む。

セクション開始が検出された場合、キーワード処理部３２は、開始されるべきセクションがフリーセクションかどうかの判定を行う（ステップＳ１１）。フリーセクションである場合、キーワード処理部３２はそのフリーセクションの実行を開始する（ステップＳ１２）。ここで、このフリーセクションは割り込みによって新たにスタックされる。すなわち、それまで実行されていたセクションがある場合、そのセクションの実行は一時的に中断され、フリーセクションの実行が開始される。後にこのフリーセクションの実行が終了すると、一時的に中断されていたセクションの実行が再開されるが、これについてはステップＳ１９およびＳ２４に関して後述する。

ステップＳ１１において、開始されるべきセクションがフリーセクションでない通常のセクションである場合は、キーワード処理部３２は、まずキーワード単位の充足抜けチェックを行う（ステップＳ１３）。ここでは、それまで実行中であったセクション内に定義されたすべての項目ルールに含まれるすべてのキーワードについて、伝達がなされたかどうかがチェックされる。たとえば、ある項目ルールが複数のキーワードの組合せ条件を含み、そのうち一部のキーワードのみが伝達されているが項目ルール全体としては条件が充足されていない場合、伝達されたキーワードは充足されたものと判定され、伝達されなかったキーワードは充足されなかったものと判定される。この判定結果は、画面表示によってオペレータに通知される。この通知は、充足されなかったキーワードおよび関連する項目ルールの表示を含む。

ステップＳ１３の後、キーワード処理部３２は、文単位の充足抜けチェックを行う（ステップＳ１４）。ここでは、そのセクション内に定義されたすべての項目ルールについて、条件が充足されたかどうかがチェックされる。たとえば、ある項目ルールが複数のキーワードの組合せ条件を含み、そのうち一部のキーワードのみが伝達されているが項目ルール全体としては条件が充足されていない場合、その項目ルールは全体として充足されていないものと判定する。この判定結果は、画面表示によってオペレータに通知される。この通知は、充足されなかった項目ルールの表示を含む。
その後、キーワード処理部３２はそれまで実行されていたセクションを終了し（ステップＳ１５）、その後新たなセクションの実行を開始する（ステップＳ１６）。すなわち、順序関係を持たないフリーセクションを除き、複数のセクションが同時に実行中の状態となることはない。なお、異なる実施形態として、複数のセクションが同時に実行されてもよい。

ステップＳ９においてセクション終了が検出された場合、キーワード処理部３２は、まずキーワード単位の充足抜けチェックを行い（ステップＳ１７）、次に文単位の充足抜けチェックを行う（ステップＳ１８）。ステップＳ１７およびＳ１８のチェックは、上述のステップＳ１３およびＳ１４と同様にして行われる。

ステップＳ１８の後、キーワード処理部３２はそれまで実行されていたセクション（現在セクション）を終了する（ステップＳ１９）。ここで、終了したセクションがフリーセクションであり、かつそのフリーセクションの開始に伴って一時的に中断されていたセクションがある場合、キーワード処理部３２は中断されていたセクションの実行を再開する。
ステップＳ１９の後、処理は後述のステップＳ２２へと進む。

ステップＳ９においてセクション終了が検出されなかった場合、キーワード処理部３２は、セクションが設定済みかどうか、すなわちその時点において実行開始されておりかつ終了していないセクションが存在するかどうかを判定する（ステップＳ１０）。セクションが設定されていない場合、キーワード処理部３２は、該当シナリオに含まれる全セクションについてキーワード検索を行い、上記ステップＳ３で受信したキーワードがいずれかのセクションに含まれるかどうかを判定する（ステップＳ２０）。ステップＳ２０で、受信したキーワードがいずれのセクションにも含まれないと判定されたとき、セクションに含まれないＮＧワード検出処理を行うために、後述するステップＳ５５〜Ｓ５８の処理が行われる。
その後処理は図８のステップＳ６１（後述）に進む。

ステップＳ１０においてセクションが設定されている場合、ステップＳ１２が実行された後、および、ステップＳ１６が実行された後、キーワード処理部３２はキーワードチェックを行う（ステップＳ２１）。このステップＳ２１では、項目ルールとキーワード処理部３２が受信した一定時間内のキーワードとの照合が行われるが、この処理の詳細は、図８を用いて後述する。
ステップＳ２１の後、キーワード処理部３２は状況の更新を行う（ステップＳ２２）。ここでは、シナリオが選択されているかどうか、またどのシナリオが選択されているか、実行中のセクションおよび中断中のセクションがあるかどうか、またどのセクションが実行中または中断中か、各セクションにおける項目ルールのいずれが充足されているか、に関する状況を保存する。また、これらの状況に関する画面表示（図９ａ〜図９ｃ、図１０ａ〜図１０ｄ、図１１、図１３ａ〜図１３ｄを用いて後述）を更新する。具体的には、セクション表示部１０４に表示された、スクリプトの中で、充足したキーワードを赤色表示したり、ルールチェック結果１０８の件数を更新する。
さらに、ステップＳ２２の状態更新時に、記憶装置に各セクションにおける項目ルールの充足度を記憶する。ここで、記憶されるデータは、通話内容に対する項目ルールの照合度を示すものであり、通話ＩＤ、オペレータＩＤ、シナリオＩＤ、時間情報等を付して記憶していくことにより、通話内容に対する項目ルール照合度を照合結果ファイルに形成する。この照合結果ファイルは、オペレータ業務のおけるコンプライアンスチェックに用いることができるものであり、オペレータＩＤまたはシナリオＩＤ等により項目ルールの充足度が確認できる。また、シナリオ別に順序不正やワード抜けの頻度を確認することにより、より実務に則したシナリオを作成することも可能となる。

その後、キーワード処理部３２は、現在実行中のセクションにおける全項目ルールのチェックが完了したかどうか、すなわち全項目ルールが充足されたかどうかの判定を行う（ステップＳ２３）。全項目ルールのチェックが完了している場合は、キーワード処理部３２は現在実行中のセクションを終了する（ステップＳ２４）。ここで、終了するセクションがフリーセクションであり、かつそのフリーセクションの開始に伴って一時的に中断されていたセクションがある場合、キーワード処理部３２は中断されていたセクションの実行を再開する。
ステップＳ２３において充足されていない項目ルールが存在する場合、またはステップＳ２４が実行された後、キーワード処理部３２はステップＳ３で受信したキーワードのうち未処理のものがまだ存在するかどうかを判別する（ステップＳ２５）。未処理のキーワードが存在するときは、ステップＳ５に処理が戻り、未処理のキーワードが存在しないときは、上述のステップＳ１に戻る。

ステップＳ１において、オペレータと顧客との通話が完了している場合、キーワード処理部３２は全項目チェックを行う（ステップＳ２）。この全項目チェックは、ステップＳ１７と同様のキーワード単位充足抜けチェック、ステップＳ１８と同様の文単位充足抜けチェック、および、順序不正チェックを含む。順序不正チェックでは、各セクションにおける項目ルールのうち、充足されるべき順序の定義を持つものが、定義された通りの順で充足されたかどうかがチェックされ、定義と矛盾する順で充足されたものは順序不正と判定される。
また、チェックの結果として、伝達されなかったキーワードおよび関連する項目ルール、全体として充足されなかった項目ルール、および、セクション内で順序不正があった項目ルールの記録が、保存されるとともに画面に表示され、オペレータに通知される。

図８は、ステップＳ２１のキーワードチェックの詳細を示す。ステップＳ２１は、その内部処理として、以下のステップＳ５１〜Ｓ６３を含む。
ステップＳ２１において、まずキーワード処理部３２は、現在実行中のセクションの全項目ルールについて、ステップＳ３（図７）で受信した全キーワードを検索する（ステップＳ５１）。

次に、キーワード処理部３２は、項目ルールのいずれかに対応して含まれるキーワードを検出したかどうかを判定する（ステップＳ５２）。
含まれるものがある場合、キーワード処理部３２は、各項目ルールに定義された充足されるべき順序を参照し、順序不正またはワード抜けが検出されたかどうかを判定する（ステップＳ５３）。ここでは、より後に充足されるべき項目ルールがすでに充足されており、かつ、より先に充足されるべきであった項目ルールがまだ充足されていない状態で、ステップＳ３で受信したキーワードによって、より先に充足されるべきであった項目ルールが充足されたことが検出された場合に、順序不正を検出したと判定する。
また、一つの項目ルール中でキーワードが伝達されるべき順序が定義されているもの、たとえば図６ａの商品セクションＡ−２における「信託報酬請求の説明」という表題を有する項目ルールでは、より後に伝達されるべきキーワードが、より先に伝達されるべきキーワードよりも先に伝達された場合に、順序不正を検出したと判定する。
また、ワード抜けとは、その時点で充足されるべき項目ルールが充足されていない状態を表す。すなわち、より先に充足されるべき項目ルールがまだ充足されていない状態で、ステップＳ３で受信したキーワードによって、より後に充足されるべき項目ルールが充足されたことが検出された場合に、より先に充足されるべき項目ルールについてワード抜けを検出したと判定する。

順序不正またはワード抜けが検出された場合、キーワード処理部３２は、順序不正・ワード抜け検出時の処理を行う（ステップＳ５４）。この処理は、順序不正またはワード抜けが検出されたセクションおよび関連する項目ルールを記録し保存するとともに、画面に表示してオペレータに通知する処理を含む。また、図３に示す処置ルールとして、順序不正またはワード抜けに関する条件およびその条件が満たされた場合の対応が定義されているものがあれば、その処置ルールに従った処理が行われる。

ステップＳ５３において順序不正もワード抜けも検出されなかった場合、および、ステップＳ５４が実行された後、キーワード処理部３２は、その時点で適用されているＮＧルール定義６１を参照し、ステップＳ３（図７）で受信したキーワードを含む項目ルールがあるかどうか、すなわちＮＧワードが検出されたかどうかを判定する（ステップＳ５５）。
ＮＧワードが検出された場合、キーワード処理部３２は、ＮＧワード検出時の処理を行う（ステップＳ５６）。この処理は、ＮＧ検出ルール６１を参照することによりＮＧワードが検出されたら、条件分岐ルールとして定義されている該当のＮＧルール６２を適用する。その後、ＮＧワードが検出されたセクションおよび関連するＮＧルール６２を記録し保存するとともに、画面に表示してオペレータに通知する処理を含む。この通知は、たとえばポップアップ表示にて、発生時刻と、ＮＧワード等を通知してもよい。
また、図６ｂに例示するＮＧルール６２の定義として、新規セクション追加等の処理を含むものがあれば、その処理が行われる。さらに、図３に示す処置ルールとして、ＮＧワードに関する条件およびその条件が満たされた場合の対応が定義されているものがあれば、その処置ルールに従った処理が行われる。

ステップＳ５５においてＮＧワードが検出されなかった場合、および、ステップＳ５６が実行された後、キーワード処理部３２は、その時点で適用されている処置ルール定義を参照し、ステップＳ３（図７）で受信したキーワードに対応するものがあるかどうか、すなわち追加対応ルールが検出されたかどうかを判定する（ステップＳ５７）。

追加対応ルールが検出された場合、キーワード処理部３２は、シナリオ内にその追加対応ルールが示すセクションを追加する（ステップＳ５８）。追加されるセクションは、現在実行中のセクションの次に実行されるべきものとして、シナリオ内に新たに定義される。また、シナリオの最後や、シナリオ内にフリーセクションとして定義されることもでき、それらは追加対応ルールが有するルールに基づく。
この処理において、キーワード処理部３２は、当該追加対応ルールおよび追加されるセクションを記録し保存するとともに、画面に表示してオペレータに通知する処理を含む。
また、追加対応ルールが新たに定義されたことから、セクションが変更になった可能性がある。付加機能として、ステップＳ５８の処理の後に、シナリオ内の次のセクションのスクリプトガイダンスを、後述する図９ａの選択セクション表示部１０５に表示するように構成することができる。それにより、オペレータに次のオペレータ業務を促し、誘導することができる。
ステップＳ５７において追加対応ルールが検出されなかった場合、および、ステップＳ５８が実行された後、キーワード処理部３２は、図８に示す処理を終了する。すなわち、図７のステップＳ２１が終了し、処理はステップＳ２２へと進む。

上述のステップＳ５２において、キーワードが、現在実行中のセクションの項目ルールのいずれにも対応しない場合、キーワード処理部３２は、シナリオ内の他セクションすべてについて、ステップＳ５１と同様の検索を行う（ステップＳ６０）。
次に、キーワード処理部３２は、項目ルールのいずれかに対応して含まれるキーワードを他セクションにおいて検出したかどうかを判定する（ステップＳ６１）。なお、ステップＳ６１の前にステップＳ６０でなくステップＳ２０（図７）が実行されていた場合は、他セクションでなく全セクションのいずれかにおいて検出したかどうかが判定される。

ここで、他セクションにおいて対応キーワードが検出された場合は、その時点で実行中であるセクションと、その時点での実際の通話内容とが食い違っており、実行中のセクションを終了して該当する別セクションを開始すべきである可能性がある。これに対応して、キーワード処理部３２は、別セクションの実行開始を示唆する画面表示を行ってオペレータに通知する（ステップＳ６２）。対応キーワードが複数のセクションにて検出されるときがあるが、そのときは複数のセクションを「別セクションの可能性」として表示し、その中からオペレータが選択するように構成してもよい。ここで、この画面表示は、オペレータが別セクションの実行を開始するか、または現在のセクションの実行を継続するかをキーワード処理部３２に指示するための手段であるボタンを含んでもよく、またこのような手段を含まなくともよい。画面表示がこのような手段を含まない場合であっても、オペレータは、上述のステップＳ７（図７）において別セクションの開始をキーワード処理部３２に指示することができる。
次に、キーワード処理部３２は、ステップＳ６２で表示された通知へのオペレータの対応を入力として受け取り、別セクションが開始されたことが指示されたかどうかを判定する（ステップＳ６４）。別セクションの開始が指示された場合、その該当セクション（現在のセクション）に対して、ステップＳ５４で記した、順序不正、ワード抜け検出時の処理を実行し、その後処理は図７のステップＳ１７に進む。また、ステップＳ１９の処理後、新しく指定されたセクションが開始され、ステップＳ７に処理が移行する。

ステップＳ６１において、他セクションにおいて対応キーワードが検出されなかった場合、キーワード処理部３２はそのキーワードを未定義スタックに追加して格納し保存する（ステップＳ６３）。この未定義スタックは、通話終了後に、オペレータ業務支援システム１の管理者が各セクションの項目ルールの見直し等に使用することができる。
ステップＳ６４で別セクションの開始が指示されなかった場合、またはステップＳ６３の実行後は、キーワード処理部３２は、図８に示す処理を終了する。すなわち、図７のステップＳ２１が終了し、処理はステップＳ２２へと進む。

以上のような処理を行うキーワード処理部３２を含み、オペレータ業務支援システム１は、画面への表示によってオペレータに対する出力を行い、また画面上に表示されるインタフェースによってオペレータからの入力を受け付ける。
以下、画面上に表示されるインタフェースの例について説明する。

図９ａ〜図９ｃは、キーワード処理部３２によって画面上に表示され制御されるインタフェースの例である。
図９ａはメイン画面１００を示す。メイン画面１００はシナリオ選択部１０１を含む。オペレータは、シナリオ選択部１０１を操作することによって、その通話に適用されるシナリオを指定あるいは変更することができる。この選択は、図７のステップＳ６における選択に対応する。

メイン画面１００は、商品選択部１０２を含む。オペレータは、商品選択部１０２を操作することによって、その通話の対象となる商品を指定あるいは変更することができる。この指定は、処置ルールの条件となる場合がある。すなわち、指定された商品に応じたセクションがシナリオに追加される場合や、指定された商品に応じたＮＧワードが適用される場合がある。

メイン画面１００は、セクション図１０３を含む。セクション図１０３は、通話に対応するシナリオのタイトルとその内部構造を表示する。ここで、内部構造は、シナリオ内におけるセクション間の相互接続関係と、各セクションのタイトルとを含み、たとえば図示のようなツリー構造として表示される。表示はツリー構造でなくともよく、他の構造たとえばネットワーク構造であってもよい。
なお、このセクション図１０３の動作は、図１０ａ〜図１０ｃを用いて後述する。

メイン画面１００は、現在セクション表示部１０４を含む。現在セクション表示部１０４は、現在実行中のセクションに対応するスクリプトを、オペレータの支援のために、会話のガイドとして表示する。なお、このスクリプトは、上述のように、セクション定義５０（図２参照）に含まれるものである。
現在セクション表示部１０４は、スクロールバーおよびスクロールボタンを含むスクロール手段１０４ａを備える。スクリプトが長く、その全体が現在セクション表示部１０４に一度に表示しきれない場合、オペレータはスクロール手段１０４ａを操作することにより、所望の部分を表示させることができる。
なお、このセクション表示部１０４に表示されるスクリプトは、現在実行中のセクションが変更されると、これに応じて変更される。また、図７および図８で説明した、ルールチェック処理の中で、該当のキーワードが検出されると、現在セクション表示部１０４に表示されているスクリプトの該当キーワードを例えば赤色に表示し、表示部内の先頭に表示するように構成することもできる。

メイン画面１００は、選択セクション表示部１０５を含む。選択セクション表示部１０５は、オペレータによって選択されたセクションに対応するスクリプトを、現在セクション表示部１０４と同様にして表示する。オペレータが、セクション図１０３内で所望のセクションをクリックして指定すると、そのセクションのスクリプトが選択セクション表示部１０５に表示される。
選択セクション表示部１０５は、現在セクション表示部１０４のスクロール手段１０４ａと同様のスクロール手段１０５ａを備える。
この選択セクション表示部１０５によって、オペレータは、現在実行中のセクションにかかわらず、次に会話すべき内容等を自由に参照することができる。

メイン画面１００は、セクション変更ボタン１０６を含む。このセクション変更ボタン１０６は、セクション図１０３と組み合わせて、現在セクションを変更するために使用される。たとえば、オペレータは、まずセクション変更ボタン１０６をクリックし、次にセクション図１０３に表示されている所望のセクションをクリックすることにより、そのセクションを開始することができる。なお、この操作は図７のステップＳ７に対応する。
検出されたキーワードからキーワード処理部３２が自動的にセクションを設定できなかった場合や、顧客の対応により会話の内容が飛躍して他セクションに属する内容となった場合であっても、オペレータは、セクション変更ボタン１０６を使用することで、正しいセクションの実行を開始することができる。
また、セクション変更ボタン１０６は、業務が突然変更となった場合等に対応するため、現在のシナリオにセクションを追加するために使用されてもよい。

メイン画面１００は、結果表示ボタン１０７を含む。オペレータによって結果表示ボタン１０７がクリックされると、結果表示画面２００（図９ｂ参照、後述）が表示される。

メイン画面１００は、ルールチェック結果表示部１０８を含む。ルールチェック結果表示部１０８は、通話の進行中または完了後におけるチェックの結果をサマリーとして表示する。
ルールチェック結果表示部１０８のうち、「ワード抜け」と表記される行は、検出されたワード抜けの数（図７のステップＳ２およびＳ２１、図８のステップＳ５３参照）を示す。「未設定ワード」と表記される行は、未定義スタック（図８のステップＳ６３参照）に格納されたキーワードの数を示す。「セクション抜け」と表記される行は、実行が開始されたにもかかわらずすべての項目ルールが充足されていないセクションの数を示す。なお、この「セクション抜け」は、開始されるべきであったにもかかわらず開始されていないセクション（たとえば、順序関係として後に実行されるべきセクションが、先に実行されるべきセクションよりも早く実行開始された場合等に相当）の数を含むものであってもよく、その場合は、このようなセクションを検出する処理が図７のフローチャートに追加されてもよい。
「順序不正」と表記される行は、検出された順序不正の数（図７のステップＳ２およびＳ２１、図８のステップＳ５３参照）を示す。「ＮＧワード」と表記される行は、検出されたＮＧワードの数（図８のステップＳ５５参照）を示す。

ルールチェック結果表示部１０８はさらに他のチェック結果を表示してもよい。たとえば、図９ａに示すように、あらかじめ特定のキーワードを「要注意ワード」として定義しておき、これが検出された数を「要注意ワード」と表記される行に示してもよい。
なお、この要注意ワードに関する情報は、ＮＧワード定義７０と同様の構成をもってＰＣ１２の記憶装置に格納されていてもよい。また、要注意ワードが検出された際は、その旨をオペレータに通知するとともに、スーパーバイザに対してアラームを通知し、確認を促す処理が行われてもよい。

ルールチェック結果表示部１０８は、各行について、該当のキーワード一覧またはスクリプト一覧を表示させるための一覧表示ボタン１０８ａを備え、さらに、一覧表示ボタン１０８ａの操作に応じて、その行に対応するキーワード一覧またはスクリプト一覧を表示するためのワード一覧表示部１０９を含む。
ワード一覧表示部１０９は、現在セクション表示部１０４のスクロール手段１０４ａと同様のスクロール手段１０９ａを備える。

メイン画面１００は、音声認識部３０から受信した発話（図７のステップＳ３参照）のテキストデータを表示するための、認識結果表示部１１０を含む。図９ａの例では、「ＯＰ」はオペレータの発話であることを示し、「０００１」〜「０００５」は発話を識別する行番号を示し、墨付きカッコは音声認識部３０によって検出されたキーワードであることを示す。この他に、各発話について開始時刻を表示してもよい。
認識結果表示部１１０は、現在セクション表示部１０４のスクロール手段１０４ａと同様のスクロール手段１１０ａを備える。
なお、図９ａの例ではオペレータの発話のみが表示されているが、オペレータ業務支援システム１が顧客の音声認識を行う手段も備えている場合には、顧客の発話が同様に表示されてもよい。

メイン画面１００は、認識結果表示部１１０に表示される発話のうち、特定の行の発話に対応するキーワードを抽出して表示する通知キーワード表示部１１１を含む。図９ａの例では、行「０００３」に含まれるキーワードである「ご用件」が表示されている。
通知キーワード表示部１１１は、現在セクション表示部１０４のスクロール手段１０４ａと同様のスクロール手段１１１ａを備える。
なお、通知キーワード表示部１１１は、特定の行の発話のみでなく、その通話において認識されたすべてのキーワードを表示するものであってもよい。その場合、通知キーワード表示部１１１に表示された特定のキーワードがクリックされると、認識結果表示部１１０にはそのキーワードを含む行が表示されるものであってもよい。

また、上述のワード一覧表示部１０９は、表示された内容に対するオペレータの操作を受け付け、これに応じて、認識結果表示部１１０、通知キーワード表示部１１１、および結果表示画面２００（図９ｂ、後述）の表示を変更する。
たとえば、ワード一覧表示部１０９のキーワードまたは項目ルールがクリックされると、結果表示画面２００において関連するセクションが強調表示されてもよい。また、認識結果表示部１１０および通知キーワード表示部１１１には関連する発話およびキーワードが表示される。なお、「セクション抜け」または「ワード抜け」に対応する項目ルールがクリックされた場合は、関連する発話およびキーワードが検出されていないことになるので、認識結果表示部１１０および通知キーワード表示部１１１の表示は変更されない。

メイン画面１００は、通知キーワード分類表示ボタン１１２を含む。オペレータによって通知キーワード分類表示ボタン１１２がクリックされると、通知キーワード分類表示画面３００（図９ｃ参照、後述）が表示される。

図９ｂは結果表示画面２００の例を示す。結果表示画面２００には、シナリオに含まれる全セクショングループおよびセクションについて、タイトルと、そのセクションに含まれる項目ルールの表題とが表示される。また、各セクショングループ、各セクション、および各項目ルールには、それぞれが伝達されたかどうかを示すチェックボックスが表示される。
図９ｂの例は、図６ａのオープニングセクションＳ−１および商品セクションＡ−１〜Ａ−３に対応する表示を含む。なお、ここで商品セクションＡ−１〜Ａ−３は、「商品メニュー」というタイトルを有するセクショングループを構成する。また、図９ｂの例は、さらに、訂正処置を表すセクションと、クロージングセクションとに対応する表示を含む。チェックボックスは、各行の左端の□マークである。

図９ｃは通知キーワード分類表示画面３００の例を示す。通知キーワード分類表示画面３００は、音声認識部３０が認識したキーワードを、キーワード処理部３２が所定の基準に従って分類した結果を表示する。
図９ｃの例では、通知キーワード分類表示画面３００は、通常ワード表示部３０１およびＮＧワード表示部３０３を含む。キーワード処理部３２が受信したキーワード（図７のステップＳ３参照）のうち、ＮＧワードとして検出されたキーワード（図８のステップＳ５５参照）はＮＧワード表示部３０３に表示され、その他のキーワードは通常ワード表示部３０１に表示される。

なお、通知キーワード分類表示画面３０１は、図示されるような要注意ワード表示部３０２を含んでもよい。この場合、あらかじめ特定のキーワードが「要注意ワード」として定義され、要注意ワード表示部３０２はこのようなキーワードを表示する。また、この場合、通常ワード表示部３０１は、ＮＧワードでも要注意ワードでもないキーワードを表示する。
通常ワード表示部３０１、要注意ワード３０２、およびＮＧワード表示部３０３は、それぞれ、現在セクション表示部１０４のスクロール手段１０４ａと同様のスクロール手段３０１ａ〜３０３ａを備える。

図１０ａ〜図１０ｃは、図９ａに示すメイン画面１００のうち、セクション図１０３の動作状態を説明する図である。
図１０ａは、シナリオの変化に応じたセクション図１０３の変化を示す。左図はシナリオが選択されていない状態を示す。この状態ではシナリオは特定の商品に関連するセクションを含まず、オープニングセクション、訂正処置セクション、およびクロージングセクションのみからなる。
シナリオが選択される（図７のステップＳ６）と、シナリオが確定し、含まれるセクションも確定する。これに応じて、セクション図１０３は確定したシナリオにおけるセクショングループおよびセクションを表示するものとなり、右図のようになる。
なお、このようなセクション図１０３の変化は、通話の進行中にシナリオにセクションが追加された際にも、同様に行われる。

図１０ｂは、セクション図１０３の階層構造表示が展開される際の変化を示す。左図では、オープニングセクションの下部構造、すなわち項目ルールは表示されていない。また、オープニングセクションの左側には、そのセクションが下部構造を有することを示す「＋」マークが表示されている。
オープニングセクションの左側の「＋」マークがクリックされると、オープニングセクションが展開される。すなわち、その下部構造である項目ルールが表示され、右図のようになる。項目ルールの左側には、その項目ルールが下部構造を有しないことを示す「・」マークが表示される。
また、右図においてオープニングセクションの左側の「＋」マークがクリックされると、オープニングセクションが閉じられ、左図のようになる。

図１０ｃは、セクション図１０３において通話の進行状況が表示される例を示す。左図では、セクション図１０３においてオープニングセクションが反転表示され、また自動的に展開され、このセクションが実行中であることを示している。右図は、オープニングセクションの下部構造が展開され、その項目ルールのうち現在伝達されているとみなされているものが反転表示され、オペレータがこの項目ルールに対応する説明を行うべきであることを示す。
なお、現在実行中のセクションに関する情報は、セクション図１０３以外にも、上述のように現在セクション表示部１０４にも表示される。
さらにオペレータは、上述のように、現在実行中のセクションに関わらず、セクション図１０３内で所望のセクションをクリックすることにより、そのセクションのスクリプトを選択セクション表示部１０５に表示させることができる。

図１０ｄは、図９ｂに示す結果表示画面２００の動作状態を説明する図である。
図１０ｄは、「利回りの説明」セクションが終了する時点まで通話が進んだ状態を示す。項目ルールのうち充足されたものは、対応するチェックボックス（□マーク）が塗りつぶされた状態（■マーク）となって示される。
この例では、「信託報酬の請求の説明」に対応する説明が行われておらず、従って該当する項目ルールが充足されないままの状態であり、この項目ルールのチェックボックスが空白のままとなっている。このため、この項目ルールを含む「リスクの説明」セクションと、このセクションを含む「商品メニュー」セクショングループのチェックボックスも空白のままとなる。
このように、オペレータは、順序不正等が検出された時点での通知（図８のステップＳ５４等）だけでなく、通話がさらに進行した後であっても、まだ伝達されていない事項を結果表示画面２００によって常に確認することができる。

図１１は、図９ａ〜図９ｃの画面に加え、キーワード処理部３２によって画面上に表示され制御されるインタフェースである、ルールチェック画面４００の例を示す。なお、例示のため、ルールチェック画面４００の表示内容は図９ａ〜図９ｃに示す画面の表示内容とは一致しない部分がある。
ルールチェック画面４００は、商品選択部４０１を含む。商品選択部４０１は、メイン画面１００（図９ａ）の商品選択部１０２と同様の機能を有する。

ルールチェック画面４００は、セクション表示部４０２を含む。セクション表示部４０２には、シナリオに含まれる各セクションの項目ルールが表示される。各項目ルールについて、その項目ルールが充足されたかどうかを示すチェックボックス４０２ａが設けられ、まだ充足されていない場合は空白（○マーク）、充足されている場合は塗りつぶされた状態（●マーク）で表示される。また、まだ充足されていない項目ルールのうち順序不正が検出されたものについては、チェックボックスに順序不正を示す表示、たとえば×マークが表示される。図１１の例では、「受付お電話番号」という項目ルールがまだ充足されておらず、順序不正が検出されている。
セクション表示部４０２に表示される項目ルールについて、支援ガイドボタン４０２ｂが表示される場合がある。この支援ガイドボタン４０２ｂは、特定の項目ルールについて別途作成される支援ガイドが存在していることを表す。支援ガイドボタンが操作されると、図示するように、たとえば「０７．３月迄、毎年１％」という表示が現れ、オペレータに対する支援ガイドとなる。

次に、図１３ａ〜１３ｄを用いて、キーワード処理部３２が図７、図８に示した処理を行うときの、ルールチェック結果表示部１０８と結果表示画面２００との偏移を例示する。図１３ａに示すように、シナリオの中に、セクショングループ１としてオープニングセクション、セクショングループ２として商品メニューセクション、セクショングループ３として訂正処置セクション、セクショングループ４としてクロージングセクションが定義されているとする。セクショングループ２の商品メニューセクションでは、Ａ投資信託メニューに分岐する条件が発生し、Ａ投資信託メニューが選択され、結果表示画面２００（図１３ａには記載していないが、セクション図１０３にも同様に）には、Ａ投資信託メニューに対応するセクションが動的に追加された状態を示す。

図１３ａは、シナリオの最初から項目チェックを行い、商品メニューセクショングループの「商品説明のはじめ」セクションの、「商品名の確認」の項目ルールが充足された状態を示す。前記したように、キーワード処理部３２が該当の項目ルールを充足したと判断したときは、対応するチェックボックス（□マーク）を、塗りつぶした状態（■マーク）に変更する。また、項目ルールを充足する順番がシナリオおよびセクションの定義と異なることにより、項目ルールが充足されなかった場合は、充足されなかった項目ルールに定義されているキーワード数をワード抜け数と判断し、ワード抜け数と記憶する。また、ワード抜けの状態から、シナリオの順番とは異なる順序で項目ルールを充足したと判断したときは、該当の項目ルールは、順序不正として判断され、順序は不正であったが、充足されたキーワード数が、順序不正数と判断され、記憶される。なお、ワード抜けや順序不正を発生させた、項目ルールのタイトルに色を付けたり、点滅したりと表記を変更することにより、オペレータに注意を喚起させることができる。図１３ａ〜１３ｄでは、ワード抜けは、赤色表示、順序不正は青色表示するように、表記しているが、適宜設計することができる。

図１３ａに示す、チェック結果表示部１０８は、図７のステップＳ２１（図８のＳ５１〜Ｓ６４）、Ｓ２２の処理によりチェック結果が随時更新され、照合結果ファイルに項目ルールとの照合結果が記憶される。
図１３ａに示す、キーワードチェック状態表示データ３３は、図７のステップＳ２１（図８のＳ５１〜Ｓ６４）の処理により、状態が更新される、メモリ上の記憶データである。シナリオの階層を、Ａ−１、Ａ−１１、Ａ−１１１等と表記しているが、数値が大きくなるにつれ、階層が下になることを示している。便宜的な表記のため、異なる方法で設計しても良い。続いて、セクションまたは項目ルールのタイトル、キーワード、「ＯＫフラグ」、「順序」が記憶、更新される。キーワードは、セクション定義５０に記憶されている項目ルールであり、図１３ａでは論理和のときは、並列にorで接続して表記し、論理積のときは、複数行に分けて表記している。「ＯＫフラグ」には、該当のキーワードが充足したときは、１を記憶するように構成している。また「順序」には、一連の受信データ内で、処理された順番（オペレータが発話した順番）を記憶する。

図１３ａは順次項目チェックを行い、「商品名の確認」の項目ルール（図１３ａ中に（１）として示す）が充足された状態であるが、途中の「希望担当の確認」項目ルールが充足されていないため、その項目ルールに記憶されたキーワード数がワード抜け数となる。図１３ａの例では、「希望担当の確認」項目ルールのキーワード数は１のため、ワード抜け数は、１件と算出され、表示される。また図１３ａでは、ワード抜けはあるが、シナリオの先頭から項目ルールが処理され、充足されているので、「順序」には上から下に数値が大きくなるように記憶している。

次に図１３ｂは、ステップＳ１の処理から始め、「購入意思の確認」と、「投資期間の意思」の項目ルール（図１３ｂ中にそれぞれ（２）および（３）として示す）が続けて充足された状態を示している。ここでは、「希望担当の確認」項目ルールは変わらず充足されず、また「商品知識の確認」と、「商品を知った理由」の項目ルールが充足されずに抜けたことは判断されるので、「商品知識の確認」のキーワード数１と、「商品を知った理由」のキーワード数１が加算されて、ワード抜け数３件と算出され、記憶される。また、結果表示画面２００には、「商品知識の確認」と、「商品を知った理由」とがワード抜けであることを示す表記をする。なお、「商品知識の確認」の項目ルールの中で、論理積で定義された２つのキーワードのうち１つは、充足していると判断している。

次に図１３ｃは、ステップＳ１の処理から始め、「投資期間の意思」の項目ルールが充足された後、「商品知識の確認」の項目ルールの中で、図１３ｂで充足されなかった、キーワードが充足され、それにより、「商品知識の確認」（図１３ｃ中に（４）として示す）が充足された状態を示している。キーワード処理部３２は、「商品知識の確認」の項目ルールは充足したと判断するが、充足された順番が、「商品知識の確認」のキーワード（（初めて）or（最初））の「１５３」が、現状最後のキーワードの「順番」の「１３０」より大きいため、順序不正を起こした上で充足したと判断し、順序不正数を１と算出する（ステップＳ５３）。またワード抜け数を、３から２に減算する。（ステップＳ５４）

次に図１３ｄは、再びステップＳ１の処理から始め、「商品知識の確認」の項目ルールが充足された後、「商品を知った理由」（図１３ｄ中に（５）として示す）が充足された状態を示している。「商品を知った理由」が充足された時点でワード抜け数は１つ減るので、ワード抜け数を２から１に減算する（ステップＳ５４）。また、１つ前に処理したキーワード（「商品知識の確認」で定義されたキーワード）がキーワードチェック状態表示データ３３で先に定義された（シナリオおよびセクションの中で前に定義された）キーワードであることから、現在の項目ルールと直近の項目ルールの間では、順序不正は起こしていないとみなし、順序不正数は変更しないように動作する（明示的に記載していないが、キーワードチェック状態表示データ３３には、直近に処理したキーワードが判別できる情報を記憶しているものとする）。なお、このときに、図１３ｃでの処理で説明したように、キーワードチェック状態表示データ３３の最後のキーワードの「順番」と比較して、順序不正か否かを判断するように、すなわち「商品を知った理由」についても順序不正と判定するように、構成することもできる。
なお、図１３ｄに示す時点では、ワード抜けは「希望担当の確認」に対して１件、順序不正は「商品知識の確認」に対して１件となる。
以上、図１３ａ〜１３ｄを用いて説明したように、キーワード処理部３２は処理するキーワードに応じてセクションを動的に追加し、セクションに定義された項目ルールを充足するかどうかを判別し、ワード抜け、順序不正を検出する。

ルールチェック画面４００は、ＮＧワード表示部４０３を含む。ＮＧワード表示部４０３は、図９ｃのＮＧワード表示部３０３と同様に、検出されたＮＧワードの一覧を表示する。
さらに、ルールチェック画面４００は、要注意ワード表示部４０４を含んでもよい。要注意ワード表示部４０４は、図９ｃの要注意ワード表示部３０２と同様に、検出された要注意ワードの一覧を表示する。

ルールチェック画面４００は、エスカレーションボタン４０５を含む。エスカレーションボタン４０５は、オペレータが自分の知識だけでは顧客に対応しきれなくなった場合に、オペレータがスーパーバイザに支援を求めるために使用するボタンである。エスカレーションボタン４０５が操作されると、キーワード処理部３２は、オペレータがスーパーバイザに支援を求めていることを、外部たとえばスーパーバイザ用システムに通知する。
ルールチェック画面４００は、スーパーバイザメッセージ表示部４０６を含む。スーパーバイザメッセージ表示部は、外部たとえばスーパーバイザ用システムから受信したメッセージを表示するものである。

なお、このエスカレーションは、エスカレーションボタン４０５が操作された場合に限らず、キーワード処理部３２が自動で行うものであってもよい。たとえば、処置ルール定義７０（図２）の一部として、ＮＧワードの検出数が一定限度以上となった場合には、キーワード処理部３２がその旨をスーパーバイザに通知するという処理が定義されてもよい。

以上のように説明される画面によるインタフェースとしては、図９ａ〜図９ｃのメイン画面１００、結果表示画面２００、および通知キーワード分類表示画面３００のみが使用されてもよく、また、図１１のルールチェック画面４００のみが使用されてもよく、これらのすべてが同時に使用されてもよい。

このように、本実施の形態に係るオペレータ業務支援システム１によれば、オペレータが伝達すべき内容に関するキーワードと、そのキーワードを含む項目ルールとを含むセクション定義５０が、その記憶手段に格納される。また、音声認識部３０がオペレータの音声を文字列に変換してテキストデータを得、さらにこのテキストデータからキーワードを抽出する。さらに、キーワード処理部３２が、項目ルールと、抽出されたキーワードとの照合を行ってその結果を出力する。
これによって、たとえば伝達すべきものとして項目ルールに定義されているキーワードが実際に伝達されたかどうかや、伝達すべき順序が項目ルールに定義されているキーワードの組合せが正しい順序で伝達されたかどうかを判定することができる。このように、本実施の形態に係るオペレータ業務支援システム１は、オペレータが顧客に伝達すべき内容が、実際に正しく伝達されたかどうかのチェックを行うことができる。

また、オペレータ業務支援システム１によれば、コールセンター業務におけるオペレータのコンプライアンスチェックを自動的に行うことができ、オペレータ本人による報告作業が不要となるので作業効率が向上する。また、複数のオペレータに対して共通のチェック基準を適用するので、チェックの客観性が向上する。

また、本実施の形態に係るオペレータ業務支援システム１によれば、項目ルールはセクション単位に定義され、キーワード処理部３２はこのセクションをキーワードチェックの単位として選択する。このため、複数の項目ルールの組合せが必要な場合、たとえばある内容を伝達するために順を追って会話を進めなければならない場合等であっても、シナリオに定義されたセクションの中から動的に次に実行されるべきセクションを選択して、チェックを行うことができる。

また、画面を介してキーワード処理部３２に指示を与えることにより、現在実行中のセクションを指定することができるので、実行すべきセクションをキーワード処理部３２が選択できない場合、または誤ったセクションが選択された場合であっても、適切なセクションを指定してチェックを行うことができる。
さらに、オペレータは、同様にして現在実行中のセクションを適宜切り替えることができるので、通話の進行状況に応じた適切なチェックを行うことができる。たとえば、顧客が会話の内容を次々に変え、会話が飛び飛びになるような場合には、本来ならばより後で実行すべきセクションを先に実行せざるを得ない可能性がある。オペレータは、このような場合であっても、状況に応じて実行されるセクションの順序を切り替え、適切なチェックを行うことができる。

また、本実施の形態に係るオペレータ業務支援システム１によれば、特定の状況において追加で行われるべき対応を定義する処置ルール定義７０が、その記憶装置に格納される。このため、通話の状況に応じてシナリオを自動的に変更することができ、状況に応じたきめ細かい対応をオペレータにガイドするとともに、オペレータの対応をチェックすることができる。
たとえば、オペレータが「窓口が違います」と発言した場合、窓口の転送に関するセクションがシナリオに追加され、適切な窓口の案内をオペレータに促すとともに、適切な案内がなされたかどうかをチェックすることができる。また、このため、オペレータの応対内容がより適切なものとなり、顧客とのトラブルを防止することができる。

なお、業務の内容によっては、伝達すべき文が決まっていても、それぞれの文を伝達すべき順序は自由であるような場合もある。このような場合は、それぞれの文に対応する項目ルールを作成し、この項目ルールを一つずつ含むフリーセクションを定義したうえで、これらのフリーセクションをすべて含むシナリオを定義することによって対応することができる。

上述の実施の形態に係るオペレータ業務支援システム１は、オペレータの応対中にリアルタイムでキーワードチェックを行うものである。すなわち、キーワード処理部３２による図７および図８に示すフローチャートの実行は、通話が開始された後、その通話が終了する前に開始される。通話の進行に伴って音声認識部がキーワードの抽出を行い、これに応じてステップＳ３の受信が行われ、これに続くキーワード処理部３２の処理が行われる。
変形例として、キーワード処理部３２は、過去の通話についてキーワードチェックを行うものであってもよい。すなわち、すでにテキストログ化された過去の通話について、そのテキストデータをステップＳ３における入力とし、最終的なチェック結果のみを表示するものであってもよい。
また上述の実施の形態に係るオペレータ業務支援システム１は、リアルタイムにキーワードチェックを行い、オペレータにキーワードとの照合度、具体的にはワード抜け、ＮＧワード検出、順序抜け等を通知するが、同時に記憶装置に通話内容に対する項目ルール照合度を記憶する。ここで、記憶される項目ルール照合度は、通話内容に対する項目ルールの照合度を示すものであり、通話ＩＤ、オペレータＩＤ、シナリオＩＤ、時間情報等を付して記憶していくことにより、通話内容に対する項目ルール照合度を照合結果ファイルに形成する。この照合結果ファイルは、オペレータ業務のおけるコンプライアンスチェックに用いることができるものであり、オペレータＩＤまたはシナリオＩＤ等により項目ルールの充足度が確認できる。また、シナリオ別に順序不正やワード抜けの頻度を確認することにより、より実務に則したシナリオを作成することも可能となる。

また、オペレータ業務支援システム１は、実施の形態１に説明される機能に加え、図１２ａ〜１２ｇを用いて説明される従来技術の機能、たとえばいわゆる「聞き起こし」作業を行う機能を、同時に提供するものであってもよい。すなわち、オペレータは、たとえば図１２ｅに示す聞き起こし画面８４０を使用し、任意に音声の再生を指示するとともに、音声に合わせてテキストデータを修正する作業を行うものであってもよい。

本発明の実施の形態１に係るオペレータ業務支援システムを含む構成を示す図である。 図１のＰＣの論理的な構成の概略を示す図である。 図２のシナリオ定義（セクショングループ定義）の構成の例を示す図である。 図３のシナリオ定義を異なる形式で表した図である。 図３のシナリオのセクションおよび処置ルールのみを表示した図である。 図２のセクション定義の構成の例を示す図である。 図２のＮＧルール定義の構成の例を示す図である。 キーワード処理部の処理の流れを説明するフローチャートである。 図７のステップＳ２１の処理の詳細を説明するフローチャートである。 キーワード処理部によって表示されるメイン画面を示す図である。 キーワード処理部によって表示される結果表示画面を示す図である。 キーワード処理部によって表示される通知キーワード分類表示画面を示す図である。 図９ａのセクション図のシナリオの変化に応じた変化を示す図である。 図９ａのセクション図の階層構造表示が展開される際の変化を示す図である。 図９ａのセクション図において通話の進行状況が表示される例を示す図である。 図９ｂの結果表示画面の動作状態を説明する図である。 キーワード処理部によって表示されるルールチェック画面を示す図である。 従来技術によるメイン画面を示す図である。 従来技術による応対ログ内容表示画面を示す図である。 従来技術による応対ログ一覧表示画面を示す図である。 従来技術によるキーワード一覧画面を示す図である。 従来技術による聞き起こし画面を示す図である。 図９ａのルールチェック結果表示部および図９ｂの結果表示画面の偏移を例示する図である。 図９ａのルールチェック結果表示部および図９ｂの結果表示画面の偏移を例示する図である。 図９ａのルールチェック結果表示部および図９ｂの結果表示画面の偏移を例示する図である。 図９ａのルールチェック結果表示部および図９ｂの結果表示画面の偏移を例示する図である。

符号の説明

１ オペレータ業務支援システム、３２ キーワード処理部、４１ シナリオ、５１ セクション、５２ 項目ルール（ルール）。

Claims (9)

1. 電話を介した通話に伴うオペレータの業務を支援する、オペレータ業務支援システムであって、
   前記オペレータが伝達すべき内容に関するキーワードと、前記キーワードに関するルールとを格納する記憶装置と、
   前記オペレータの音声を文字列に変換することによって得られるテキストデータから抽出されたキーワードと、前記ルールとの照合を行い、前記照合の結果を出力する、キーワード処理部と
   を備える、オペレータ業務支援システム。
2. 前記ルールは、前記キーワードが伝達されるべきであるということを表すものを含む、請求項１に記載のオペレータ業務支援システム。
3. 前記ルールは、前記キーワードが伝達される順序を表すものを含む、請求項１または２に記載のオペレータ業務支援システム。
4. 前記記憶装置は、前記通話のパターンを表す複数のシナリオと、前記複数のシナリオにおける発話のまとまりを表す複数のセクションとを格納し、
   前記セクションの少なくとも一つは、少なくとも一つの前記ルールを含み、
   前記キーワード処理部は、前記キーワードとの前記照合に用いる前記ルールを、前記セクションを単位として選択する
   請求項１〜３のいずれか一項に記載のオペレータ業務支援システム。
5. 前記シナリオの編集作業のためのグラフィカルユーザインタフェースをさらに備える、請求項４に記載のオペレータ業務支援システム。
6. 前記キーワード処理部は、前記キーワードとの前記照合に用いる前記ルールを、前記通話の状況に応じて追加する、請求項１〜５のいずれか一項に記載のオペレータ業務支援システム。
7. 前記結果の前記出力は、画面表示によって行われる、請求項１〜６のいずれか一項に記載のオペレータ業務支援システム。
8. 前記結果の前記出力は、前記記憶装置に、通話単位で照合結果を記憶することによって行われる、請求項１〜６のいずれか一項に記載のオペレータ業務支援システム。
9. 前記キーワード処理部は、前記通話が終了する前に前記キーワードと前記ルールとの前記照合を開始する、請求項１〜８のいずれか一項に記載のオペレータ業務支援システム。

Images