電話応対の録音から、評価の下書きと本人へのフィードバックを作る

処理の起点を決める

評価対象として選ばれた通話がストレージに置かれたときを起点にします。全件を自動で処理しません。

理由は2つあります。第一に、全通話を評価すると監視になります。第二に、費用が通話時間に比例します。評価対象の選び方（新人は多め、他は無作為）を運用として決め、その分だけを処理します。

バッチ文字起こしは完了まで時間がかかるため、完了を待って次に進む作りにします。Azure AI Speech では、処理の状態を問い合わせる方法のほかに、完了時に通知を受け取る仕組み（Webhook）が用意されています。通知を受ける側の設定には注意点があり、登録時の確認要求に対して、受け取った文字列をそのまま平文で返す必要があります。

入力データを集める

3番目の定義が、この構成の品質を決めます。 「共感を示せているか」だけでは判定できません。「顧客が不便を述べた直後に、その内容を受け止める発言があるか」のように、文字起こしから確認できる形に言い換えます。

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

文字起こし： Azure AI Speech のバッチ文字起こしを使います。音声ファイルの場所（contentUrls または contentContainerUrl）、言語（locale）、名前（displayName）、保持期間（timeToLiveHours）を指定して登録します。保持期間は必須の指定で、最短6時間・最長31日、直接利用する場合は48時間が推奨されています。

話者の分離： 話者分離は既定では無効で、diarizationEnabled を true にすると有効になります。モノラルの音声が前提で、ステレオ録音では使えません。 2チャンネルのステレオであれば、もともと1チャンネルに1話者が入っているためです。3人以上が話す通話では diarization の指定も必要で、話者数の最小・最大を指定します。話者分離を使う場合、1ファイルの音声は240分までという制限があります。

電話の録音では、どちらのチャンネルに誰が入っているかを先に確認してください。 オペレーターと顧客が別チャンネルで録音されていれば、話者分離そのものが不要になり、精度の問題も起きません。

結果の保存先： 結果を自社のストレージに保存したい場合、その指定は要求の properties の中に入れます。上の階層に置くと無視され、結果はサービス側の管理する場所に保存されます。

AIへ渡す前に整形する

1. 音声の形式を揃える … 話者分離を使う場合、モノラルであることを確認します
2. 短すぎる通話の除外 … 30秒未満の通話（間違い電話、無言）は評価の対象外にします
3. 個人情報のマスク … 文字起こしのあと、氏名、電話番号、住所、注文番号、カード番号を伏せます。生成AIへ渡す前に必ず行います
4. 保留・転送の区切り … 保留中の無音や、転送後の別担当者の発言を分けます
5. 用件区分の付与 … 注文受付と苦情対応では評価の観点が違うため、区分を渡します

3番は、この構成でもっとも重要な前処理です。通話には氏名・住所・カード番号が必ず出てきます。

AIに処理させる

点数を付けさせないでください。 点数は評価者が付けます。AIが点数を出すと、管理者がそれを追認するだけになり、評価の責任の所在が曖昧になります。

指示内容を固定する

あなたは電話応対の品質評価を補佐する担当者です。
通話の文字起こしと、評価項目の定義を渡します。
項目ごとに該当する箇所を引用し、状態を記述してください。

【厳守事項】
- 点数や総合評価を付けないでください。
- 各項目について、該当する発言を文字起こしからそのまま引用してください。
  引用できない場合は「該当する発言は見つかりませんでした」と書いてください。
  引用のない指摘を書かないでください。
- 声の調子、話す速さ、間の取り方について書かないでください。
  文字起こしからは分かりません。
- オペレーターの性格や姿勢について書かないでください。
  「やる気が感じられない」のような記述は禁止です。
  発言と、その発言がどの項目に当たるかだけを書いてください。
- 顧客の発言を評価しないでください。
- 改善の余地がある点には、具体的な言い換えの案を1つ添えてください。
- 通話の中に個人情報が残っている場合は、引用の中でも伏せてください。

【評価項目の定義】
{rubric}

【用件区分】
{call_type}

【文字起こし（話者分離済み・マスク済み）】
{transcript}

「性格や姿勢について書かない」の1行を必ず入れてください。 これが無いと、生成AIは「対応が事務的で冷たい印象を与える」といった記述を書きます。本人に返すフィードバックとして、もっとも扱いが難しい種類の文章です。

出力形式を固定する

{
  "call_id": "",
  "operator_id": "",
  "call_type": "",
  "items": [
    {
      "item": "名乗り",
      "found": true,
      "quote": "",
      "observation": ""
    }
  ],
  "good_points": [
    { "quote": "", "why": "" }
  ],
  "improvements": [
    { "quote": "", "issue": "", "suggested_phrase": "" }
  ],
  "transcript_quality": "good | partial | poor",
  "masked_items": []
}

transcript_quality を持たせるのは、文字起こしがうまくいかなかった通話を評価に使わないためです。雑音や回線の状態で精度が落ちた通話を評価すると、オペレーターにとって不公平になります。

masked_items には、伏せた情報の種類を入れます。マスクが効いているかの確認に使います。

システムへ連携する

録音そのものを本人以外に広く共有しないでください。 教材として使う場合は、本人の同意を得たうえで、該当箇所のみを使います。

人が確認する

全件、管理者が確認して評価を確定します。

理由は、評価が人の処遇や育成に関わるためです。文字起こしからは分からない要素（声の調子、間、顧客の反応の速さ）があり、引用された箇所だけを聞き直して判断する運用にします。

確認を速くするための設計が要ります。

• 引用箇所に、録音の再生位置へのリンクを付ける
• 「該当する発言が見つからなかった」項目を先頭に出す
• 前回の評価で指摘した点を並べて表示する
• 文字起こしの品質が低い通話に印を付ける

録音の頭から聞き直す必要がなくなることが、時間短縮のほぼすべてです。

例外に対処する

記録を残す

• 録音（保存期間は自社の規程に従う）
• 文字起こしとマスク処理の結果
• AIの下書きと、管理者が確定した評価の差
• 本人へ返したフィードバック
• 異議とその対応

3番目を定期的に見てください。 管理者が毎回同じ項目を書き換えているなら、評価項目の定義が実務に合っていません。定義を直すほうが、プロンプトを直すより効きます。