保険会社のコールセンターで、通話の文字起こしを応対品質の評価シートに照らして採点し、オペレーターごとの指導の要点を根拠の発言と一緒に出す

処理の起点を決める

評価者が、評価する通話を一覧に登録したことを起点にします。 一覧には通話の番号、社員番号、受付の種類、評価者を1行ずつ入れます。選ぶ作業は人に残します。 前月に指摘した項目が出やすい種類を選ぶといった、評価者の意図があるからです。

登録は毎日少しずつ行い、文字起こしの依頼は1日1回、夕方にまとめて出します。 バッチ文字起こしは1つの依頼に複数の録音を入れられ、公式の説明では短い録音と長い録音は別の依頼に分けることが勧められています。通話は長くても数十分なので、20分を境に2つの依頼に分けて出します。

完了は Webhook の通知で受け取ります。 ただし、受ける側のファイアウォールがサービスタグ CognitiveServicesManagement からの受信を許していないと、登録は成功するのに通知だけが届きません。 翌朝に状態を問い合わせる処理も置きます。

入力データを集める

質を決めるのは、評価シートの4列目です。 「用件を復唱している」という項目だけを渡すと、AI は「確認させていただきます」と言っただけの通話を「できている」にします。段階ごとに「何を言っていればできているのか」を書いた基準が要ります。 例えば「お客さまが述べた用件を、手続きの名前に置き換えて言い直し、合っているかを尋ねている」と書きます。

受付の種類ごとの手順は、本人確認の項目のために渡します。 住所変更と給付金の請求では聞く順序が違い、渡さないと正しく聞いたオペレーターを「順序が違う」と採点します。

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

録音は、通話録音システムの書き出しの機能で、選んだ通話の分だけ取り出します。取り出した録音は Azure Blob Storage の評価用のコンテナに置き、バッチ文字起こしにはその場所を渡します。 通話録音システムのほうから直接文字起こしへ送る経路は作りません。

文字起こしの依頼では、結果の保存先と保持の期間を決めて指定します。 保存先のコンテナ（destinationContainerUrl）を指定しないと、結果は Microsoft が管理するコンテナに置かれ、文字起こしの依頼を消すと結果も消えます。 また、保持の時間（timeToLiveHours）は必須の項目で、6時間から31日の間で指定します。この構成では48時間とします。destinationContainerUrl は properties の中に書きます。 一番上の階層に書くと黙って無視されるとされているので、最初の依頼で保存先を確かめます。

AIへ渡す前に整形する

1. チャネルで話者を決める … チャネル0をオペレーター、チャネル1を顧客とし、発話の一覧の speaker を op ／ cu にします。録音システムのチャネルの割り当てが逆でないかを、導入の最初に10件で確かめます
2. 時刻を「分:秒」にする … offsetInTicks（1ティックは100ナノ秒）を、評価者が録音の再生で探せる「03:12」の形にそろえます
3. 発話に番号を振る … 発話ごとに u001 からの番号を付けます。AI には番号と本文を一緒に返させ、照合を番号で行います
4. 信頼度の低い発話に印を付ける … 信頼度が低い発話は、本文の前に [聞き取り注意] を付けます。採点の根拠にしたときに、評価者が録音で確かめる目安になります
5. 保留中と転送の後を区切る … 保留音の区間と、転送で別の担当に替わった後の発話を一覧から外します。評価するのは、評価対象のオペレーターの発話だけです
6. 口座番号やカード番号を伏せる … 数字の並びの規則で、口座番号・カード番号に当たる桁を伏せ字にします。採点に数字そのものは要りません
7. 項目を2つに分ける … 評価シートの12項目のうち、発話で確かめられる9項目だけを採点の対象にし、受け取り方で決まる3項目は評価者に残します

7番目が、この構成の前提です。 残りの3項目を AI の採点に含める設定を、そもそも作りません。

AIに処理させる

させるのは、9項目それぞれについて、基準に照らした段階を選び、根拠にした発話の番号と本文をそのまま写すことです。 段階を選べないときは「判断できない」にし、その理由を書かせます。

4行目が、「共感を示している」を書き直した項目です。 共感が伝わったかは受け取り方の問題ですが、顧客の言葉を受けて言い換えたかは発話で確かめられます。

指示内容を固定する

あなたは保険会社のコールセンターで、応対品質の評価を手伝う立場です。
渡された発話の一覧だけを見て、評価シートの9項目を採点してください。

【採点する9項目と基準】{rubric}
（項目ごとに、good / partial / poor の基準と、該当する言い回しの例が書かれています）

【この通話の受付の種類と、本人確認の手順】{procedure}

【発話の一覧】{utterances}
（u番号、話者 op=オペレーター / cu=お客さま、時刻、本文。
  [聞き取り注意] が付いた発話は、文字起こしの信頼度が低いものです）

【段階の選び方】
- good ........... 基準の good に書かれた発話がある
- partial ........ 基準の一部だけを満たす発話がある
- poor ........... 基準を満たす発話が無く、満たすべき場面があった
- not_applicable . その項目が求められる場面が通話に無かった
- unknown ........ 発話の一覧からは判断できない
迷ったときに good を選ばないでください。迷ったら unknown です。

【厳守事項】
- 根拠には、発話の一覧から u番号と本文をそのまま写してください。
  言い換えたり、要約したり、つなぎ合わせたりしないでください。
- poor を選ぶときは、満たすべき場面だった発話（お客さまの発話でもよい）を
  根拠に写してください。「無かった」ことだけを理由にしないでください。
- 声の調子、感情、態度、性格については何も書かないでください。
  「冷たい」「いらだっている」「自信がない」のような言葉を使わないでください。
- [聞き取り注意] の発話だけを根拠にする場合は、unknown にしてください。
- 合計点、総合評価、人事評価や処遇に関わることは書かないでください。
- 説明すべき事項が説明されたかどうかは、この採点の対象外です。
- 直し方の例（advice）は、根拠にした発話をどう言い換えるかを1文で書いてください。
  基準の言い回しの例を使ってかまいません。

「迷ったら unknown」を明記しないと、AI は good に寄ります。 名乗りらしい発話があれば、会社名が欠けていても good を選びがちです。good は誰も聞き直さない段階なので、迷いは unknown に倒します。

poor の根拠に「満たすべき場面」を写させるのは、指導のためです。 顧客が用件を言った発話が根拠にあれば、面談で「この直後に言い直しましょう」と示せます。

出力形式を固定する

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

{
  "call_id": "",
  "scores": [
    {
      "item": "opening | identity_check | restate_request | acknowledge | plain_terms | hold_manner | process_explain | document_notice | closing",
      "level": "good | partial | poor | not_applicable | unknown",
      "evidence": [
        { "utterance_id": "u012", "time": "01:48", "text": "" }
      ],
      "unknown_reason": "",
      "advice": ""
    }
  ]
}

scores には9項目を1つずつ並べ、item と level を enum で縛ります。根拠が要らない段階（not_applicable）でも evidence は空の配列で返させ、項目の欠けを形で見分けられるようにします。

1つ目の理由は、記録表の列と1対1で対応させられることです。 item が評価シートの項目、level が段階の列にそのまま入ります。評価シートに無い段階や項目名が入る経路が無くなります。

2つ目は、照合を番号で行えることです。 utterance_id で発話の一覧を引き、text が元の本文と一致するかをプログラムで比べます。一致しなければその項目の level を unknown に置き換え、unknown_reason に「根拠の照合ができない」と書きます。

ただし、スキーマで縛れないこともあります。 構造化出力では、すべてのフィールドを必須にし additionalProperties: false を設定します。配列の minItems・maxItems などは使えないため、「根拠を1つ以上」「9項目ちょうど」は受け取った後にプログラムで確かめます。

月末の要点づくりは別の呼び出しで、渡すのは評価者が確定させた4件分です。 poor と partial が2件以上で出た項目を最大3つ、根拠の発言を2つまでと、次に試す言い回しを1文で返させます。

システムへ連携する

評価の記録表には、下書きの欄と確定の欄を別に持たせます。 AI の段階は下書きの欄に入り、評価者が確定させた段階だけが確定の欄に入ります。 集計や面談に使うのは確定の欄だけです。同じ欄に書くと、評価者が見ていない下書きがそのまま点数として残ります。

Responses API ではなく Chat Completions API を使います。 Responses API は会話の履歴を保存する機能を持ちますが、1件ずつ採点して終わる処理なので、文字起こしを置く場所を増やす必要がありません。

人が確認する

AI の段階をそのまま確定させることはしません。全件を評価者が確かめます。 ただし、確かめ方は録音を頭から聞くことではありません。

1. unknown を先に見る … 根拠の照合ができなかったもの、聞き取りの怪しい発話だけが根拠だったものです。時刻の前後を聞いて段階を付けます
2. poor と partial の根拠を聞く … 根拠の時刻から前後30秒ほどを再生し、文字起こしの誤りで poor になっていないかを確かめます
3. good は一覧で流し見る … 根拠の本文を読み、違和感のあるものだけ録音を聞きます
4. 受け取り方で決まる3項目を付ける … 1〜3番目で聞いた箇所の印象を元に付け、足りなければ録音を追加で聞きます
5. 覆したら記録する … どの項目を、どの段階からどの段階へ変えたかを残します

2番目を省かないでください。 文字起こしが「保留させていただきます」を聞き落とすと、断ったオペレーターが poor になり、評価の仕組みそのものが信用されなくなります。

目標は1件10分です。 大きく超える月は、unknown が多すぎるか、基準の書き方が足りていません。

例外に対処する

最後の行は、採点の外で扱います。 採点の仕組みが苦情の受付を兼ねると、どちらも中途半端になります。

記録を残す

• 評価対象の一覧（通話の番号、オペレーター、受付の種類、選んだ評価者、選んだ日）
• 文字起こしの結果の JSON 全文と、整えた発話の一覧
• AI に渡した評価シートの版と、指示文の版
• AI の下書き（9項目の段階、根拠、直し方の例）と、照合で unknown に置き換えた記録
• 評価者が確定させた段階と、覆した項目の記録
• 月末の要点の下書きと、スーパーバイザーが直した後の文面
• 項目ごとの「AI の下書きを評価者が覆した率」

3つ目の版を残すのは、基準を直すと同じ通話でも段階が変わるためです。 版が無いと月ごとの比較ができません。

最後の行が、評価者どうしのぶれを見る材料になります。 ある評価者だけが同じ項目をよく覆しているなら、基準の読み方がずれているか、基準があいまいかです。 四半期の会議はこの率から始めます。