保険のコールセンターの通話の文字起こしを、説明すべき事項の漏れと不適切な言い回しで点検し、指導の材料にする

処理の起点を決める

毎晩の定時に、前日の通話をまとめて処理します。 点検は面談の材料なので、通話の直後に結果が出る必要はありません。夜間にまとめると、バッチ文字起こしの待ち時間も気になりません。 公式の説明では、バッチ文字起こしの完了には、音声の量やサービスの負荷によって数分から数時間かかることがあるとされています。

点検する通話は、いまの抜き取りの基準で選びます。 オペレーター1人あたり月4件前後、新人と苦情の入ったオペレーターは多めに、という基準を、応対履歴から機械的に選ぶ条件にします。選び方を変えずに始めれば、導入前と後の点検の結果を比べられます。

文字起こしが終わったら、バッチの完了を待って次の処理に進みます。公式の説明では、状態を問い合わせる代わりに、完了したときに通知を受ける Web フックを登録できるとされています。Web フックを使う場合は、受け口の側で検証の手順に正しく応える必要があります。

入力データを集める

質を決めるのは、点検の一覧の書き方です。 「重要事項を説明したか」という1項目では、AIもスーパーバイザーと同じだけ迷います。「解約日以降に起きた事故は補償されないことを伝えたか」のように、1項目に1つの内容を書きます。 言い換えとして認める表現の例を添えておくと、第3章の（b）のぶれが減ります。

禁止される言い回しの一覧は、保険業法の禁止行為を下敷きにします。 保険業法第300条は、保険募集に関して、重要な事項を告げない行為、重要な事実を告げないことを勧める行為、不利益となる事実を告げずに乗り換えさせる行為、誤解させるおそれのある比較、将来の金額が不確実な事項について断定的な判断を示す行為などを禁じています。社内の一覧は、これを通話の言葉の例に落としたものにします。

データの取得方法を決める

録音の書き出しの方式は、通話録音システムによって違います。 API で取れる製品もあれば、管理画面からの書き出ししかない製品もあります。この部分は利用している録音システムに応じた個別の実装になります。

バッチ文字起こしには、いくつかの設定が要ります。 公式の説明では、locale は必須で後から変えられず、timeToLiveHours も必須で、6時間から31日の範囲で、完了後にその時間が過ぎると自動で消されるとされています。結果を自社のコンテナーに残すには destinationContainerUrl を properties の中に置く必要があり、ルートに置くと無視されて、Microsoft が管理するコンテナーに書かれるとされています。

チャネルの扱いが、この構成の前提です。 公式の説明では、チャネル0と1が既定で文字起こしされ、話者分離（diarization）は単一チャネルの録音を前提とし、ステレオの録音では使えないとされています。オペレーターと顧客を別のチャネルで録音していれば、話者分離に頼らずに「誰が言ったか」が分かります。 単一チャネルの録音しか無いコールセンターでは、話者分離を使い、誤りを前提に点検します。

AIへ渡す前に整形する

1. 言い回しを伏せない設定 … 公式の説明では、profanityFilterMode の既定は Masked（アスタリスクに置き換える）です。不適切な言葉を点検したいので None にします
2. 時刻の付与 … wordLevelTimestampsEnabled を有効にし、発話ごとに開始の時刻を付けます。スーパーバイザーが聞き直す位置になります
3. 発話の並べ替え … 2チャネルの結果を時刻順に1本にし、「OP」「客」の印を付けます
4. 伏せ字 … クレジットカードの番号、口座番号、電話番号を、桁の並びで検出して伏せます
5. 通話の種類の確認 … 応対履歴の種類と、点検の一覧を対応させます。種類が空の通話は「種類不明」にします
6. 長さの確認 … 極端に短い通話（切断、転送）は点検から外します
7. 版の記録 … 使った点検の一覧の版の番号を、通話ごとに記録します

1番目を忘れないでください。 既定のままでは、点検したい言葉そのものがアスタリスクになって消えます。 一方で、伏せ字の対象（4番目）は自社で決めて確実に伏せます。伏せない設定と伏せる処理を、目的に合わせて使い分けます。

AIに処理させる

させるのは、点検の一覧の説明事項ごとに説明の有無を判定し、根拠の発話を引用すること、禁止される言い回しを引用付きで拾うことです。

一番上の行の右端が、この構成でいちばん大事な区別です。 not_explained は文字起こしを読んでも説明が見つからないということ、unclear は文字起こしが崩れていて判断できないということです。前者はオペレーターへの指導の材料、後者は録音を聞くべき箇所です。

3行目がいちばん起きやすい失敗です。 「解約日以降のジコは補償されません」のような聞き取りの誤りを、AIは気を利かせて直し、「説明あり」と判定します。今回は合っていても、直した文は文字起こしに存在しないので、引用の照合で落ちます。 誤りは誤りのまま引用させ、判定を unclear にさせます。

指示内容を固定する

あなたは損害保険会社のコールセンターで、通話の文字起こしを点検する担当です。
渡された文字起こしと点検の一覧だけを見て判定してください。推測で補わないでください。

【文字起こしの形式】
各行は「[開始時刻] 話者: 発話」です。話者は OP（オペレーター）か 客（お客さま）です。
文字起こしには聞き取りの誤りが含まれることがあります。

【説明事項ごとの status】
- explained ...... OP の発話に、その内容が含まれている（言い換えの例に当たる表現を含む）
- not_explained .. 文字起こし全体を読んでも、その内容の発話が見つからない
- unclear ........ それらしい発話はあるが、聞き取りの誤りで内容を確定できない
- not_applicable . 通話の流れから、その説明事項の場面に至っていない（例：申込みに進まなかった）

【厳守事項】
- evidence には、根拠にした OP の発話を、文字起こしのとおりに一字一句写してください。
  要約、言い換え、聞き取りの誤りの修正をしないでください。
- evidence の発話の開始時刻を timestamp に入れてください。
- not_explained のときは evidence を空にしてください。
- 聞き取りの誤りがあると思われる箇所を、正しい言葉に直して判定しないでください。
  直さなければ判定できないときは unclear にしてください。
- 迷ったときに explained を選ばないでください。
- 禁止される言い回しは、一覧の区分のどれに当たるかを category に入れ、発話を写してください。
  区分に当てはまらないが気になる発話は category を other にしてください。
- 法令違反かどうか、オペレーターの評価、点数は書かないでください。
- お客さまの発言を評価しないでください。

【通話の種類】{call_type}
【点検の一覧（版：{checklist_version}）】{checklist}
【禁止される言い回しの一覧】{ng_list}
【文字起こし】{transcript}

「聞き取りの誤りを直さない」を2か所に書いているのは、直すのがAIの得意なことだからです。 1か所だけだと、明らかな誤りは直してよいと解釈します。直した瞬間に引用の照合が通らなくなり、判定の根拠が消えます。

「迷ったときに explained を選ばない」を入れているのは、見逃しのほうが重いからです。 説明していないのに説明したと判定すると、その通話は誰にも聞かれずに終わります。迷ったものは unclear にして、人が聞く側に倒します。

出力形式を固定する

次の形のJSONを、構造化出力のスキーマで受け取ります。

{
  "call_id": "",
  "call_type": "new_application | change | cancellation | unknown",
  "checklist_version": "",
  "items": [
    { "item_no": "", "status": "explained | not_explained | unclear | not_applicable",
      "evidence": "", "timestamp": "" }
  ],
  "phrases": [
    { "category": "assertive | misleading_comparison | discouraging_disclosure | rude | other",
      "quote": "", "timestamp": "", "note": "" }
  ]
}

公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があり、スキーマには最大100個のオブジェクトのプロパティと最大5段の入れ子が持てるとされています。新規の申込みの30項目は items の配列の要素として並べるので、この上限には当たりません。

1つ目の理由は、引用をプログラムで照合できることです。 Azure Functions が evidence と quote を文字起こしの該当の時刻の行と突き合わせ、一致しないものは unverified として点検の一覧に赤で出します。

2つ目は、AIの判定と点検の結果を別の層に置けることです。 AIは items を埋め、通話の結果は規則で決めます。

3つ目は、timestamp で聞き直す位置が分かることです。 スーパーバイザーの画面で時刻を押すと、その位置から録音が再生されるようにしておけば、通話を頭から聞く必要がなくなります。

システムへ連携する

通話録音システムと応対履歴のシステムには、書き込みません。 点検の結果を応対履歴に戻すと、確かめる前の判定がオペレーターの記録として残ります。 戻すのは、スーパーバイザーが確定させた結果だけにします。

面談の記録も、この構成の外に置きます。 指導の要点はスーパーバイザーが書き、いまの面談の記録の様式に残します。

人が確認する

1. escalate を最初に見る … 示された時刻の録音を聞き、事実を確かめてから法務部に相談します
2. review を聞く … unclear と unverified の箇所の録音を聞いて、explained か not_explained に決めます
3. coaching の根拠を確かめる … not_explained の項目は、その説明が入るはずの場面の前後を聞きます。言い換えで説明していれば、explained に直します
4. clear は一覧で流し見る … 根拠の引用を読み、違和感のあるものだけ聞きます
5. 判定を直したら記録する … どの項目を、何から何に変えたかを残します

3番目を省かないでください。 点検の一覧の言い換えの例に無い言い方で説明しているオペレーターは、いつも not_explained になります。確かめずに指導すると、正しく説明しているのに注意されることになります。 直した記録が増えた項目は、言い換えの例を一覧に足します。

目標は、450件をならして1件6分です。 clear は1件1分足らず、coaching と review は示された時刻の前後を数か所聞いて数分かかります。

例外に対処する

上の2行は、録音の仕方の問題です。 2チャネルで録音していれば、どちらもほとんど起きません。録音システムの設定を見直すほうが、点検の精度を上げるより効きます。

記録を残す

• 録音のファイル名と、文字起こしの結果（時刻付き）
• 使った点検の一覧と禁止される言い回しの一覧の版
• Azure OpenAI に渡した入力と、返ってきたJSONの全文
• 引用の照合の結果（unverified になったもの）
• スーパーバイザーが判定を直した記録 … どの項目を、何から何に変えたか
• 法務部への相談の記録と、その結論

5つ目は、点検の一覧を直すための材料になります。 特定の項目で not_explained を explained に直す件数が多ければ、その項目の言い換えの例が足りていません。

バッチ文字起こしの結果の消し方も決めておきます。 公式の説明では、timeToLiveHours の時間が過ぎると自動で消え、自社の保存先を指定しなければ結果は Microsoft が管理するコンテナーに置かれ、ジョブを消すと結果も消えるとされています。自社のコンテナーに書いた文字起こしは、社内の録音の保存期間に合わせて消します。