電力・ガス会社のコールセンターで、通話の文字起こしを要約し、問い合わせの種類・対応・次の対応を応対記録の下書きにする

処理の起点を決める

通話が終わり、通話録音システムが録音を保存したことを起点にします。 応対記録は後処理の時間に書くものなので、夜間にまとめて処理しても意味がありません。 オペレーターが後処理の画面を開いたときに、下書きが入っている状態を目指します。

録音の保存を知る方法は、通話録音システムによって違います。保存先のフォルダにファイルが置かれたことを検知する方法、録音システムが通知を送る方法、PBX の通話終了の記録を見る方法のいずれかです。この部分は、利用している録音システムに応じた個別の実装になります。

文字起こしには、バッチではなく高速文字起こしを使います。 公式の説明では、高速文字起こしは結果を同期で返し、実時間より速く処理するとされ、字幕や会議のメモ、留守番電話のように予測できる待ち時間が要る場面に向くとされています。下書きが間に合わなかった通話は、待たずにオペレーターが手で書きます。 後処理を延ばすと、待っているお客さまが増えるからです。

入力データを集める

質を決めるのは、コード表の注記です。 「引越しの電話で料金の話も出たときは、引越しのコードを選ぶ」のような、オペレーターが頭の中で使っている選び方の決まりを、コード表に書いておきます。 書いていない決まりは、AIも守りません。第3章の（d）のぶれも、ここで減ります。

契約の情報は、「ガスのほうも」のような言葉の意味を決めるために渡します。 渡すのは料金メニューや支払方法の区分までで、口座番号やカード番号は渡しません。

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

高速文字起こしの入力には上限があります。 公式の説明では、5時間未満、500MB未満の音声が対象とされています。保留のまま切り忘れた通話のような極端に長い録音は、前処理で外します。

チャネルの扱いが、この構成の前提です。 公式の説明では、channels に [0,1] を指定でき、ステレオの音声で話者分離を有効にしたときは channels に [0,1] を指定できないとされ、話者分離は単一チャネルの音声を前提としています。オペレーターと顧客を別のチャネルで録音していれば、話者分離に頼らずに「誰が言ったか」が分かります。 次の対応の約束は、オペレーターのチャネルの発話から抜き出します。

電気・ガスの言葉は、フレーズリストで補います。 公式の説明では、phraseList で語句を渡すことができ、API のバージョン 2025-10-15 で使えるとされています。料金メニューの名前、「開栓」「閉栓」「スマートメーター」「検針票」「口座振替」など、取り違えると要約の意味が変わる言葉を登録します。

AIへ渡す前に整形する

1. 長さの確認 … 極端に短い通話（無言の切断、転送だけのもの）と、極端に長い録音は下書きの対象から外します
2. 発話の並べ替え … 応答の phrases には offsetMilliseconds と channel が付きます。時刻順に1本にし、「OP」「客」の印を付けます
3. 伏せ字 … Azure AI Language のテキストの PII 検出で、カード番号・口座番号・マイナンバーを検出して伏せます。桁の並びの規則でも二重に伏せます
4. 契約の情報の付加 … 契約の番号から、電気・ガスの別と料金メニューを読み、文字起こしの前に付けます
5. コード表の版の記録 … どの版のコード表で下書きを作ったかを、通話ごとに記録します

3番目で、会話向けの PII 検出を使わないのは理由があります。 公式の言語の一覧では、会話向けの PII 検出が対応する言語は英語・フランス語・ドイツ語・スペイン語で、日本語は含まれていません。一方、テキストの PII 検出は日本語に対応しています。文字起こしを1本の文字列にしてから、テキストの PII 検出にかけます。

規則の伏せ字を重ねるのは、数字が漢字や読みで起こされると検出から漏れうるからです。

AIに処理させる

させるのは、要件と対応した内容の要約、問い合わせの種類のコードの候補、次の対応の抜き出し、苦情と保安の候補の印付けです。

4行目がいちばん大事な項目です。 抜き出すのはオペレーターが自分でする、または社内の誰かにさせると約束したことだけです。「書類は郵送でお届けします」は約束、「書類はお客さまのほうで郵送してください」は案内です。取り違えると、作業一覧に要らない作業が載るか、要る作業が載りません。

3行目がいちばん起きやすい失敗です。 聞き取りの誤りで金額が違っていても、応対記録に書かれた数字は正しく見えます。 要約には「請求額についての問い合わせ」とだけ書かせます。

指示内容を固定する

あなたは電気・ガスの小売事業者のお客さまセンターで、通話の応対記録の下書きを作る担当です。
渡された文字起こしと契約の情報だけを見て書いてください。推測で補わないでください。

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

【書くこと】
1. request: お客さまが何を頼んだか。2文以内。
2. actions_taken: OP がその場で行った手続きと、案内した内容。手続きと案内を分けて書く。
3. category_main / category_sub: コード表から選ぶ。選び方の注記に従う。
4. follow_ups: OP が約束した次の対応。1つの約束を1要素にする。
5. complaint_flags / safety_flags: 当てはまる発話があれば引用する。

【厳守事項】
- follow_ups には、OP が「自分がする」「社内の誰かがする」と約束したことだけを入れてください。
  お客さまにしてもらうことの案内は follow_ups に入れず、actions_taken に書いてください。
- follow_ups の said_due には、OP が言った期日の言葉をそのまま写してください。
  「明日の午前中」を日付に直さないでください。期日を言っていなければ空にしてください。
- follow_ups の quote には、約束した OP の発話を、文字起こしのとおりに一字一句写してください。
  要約、言い換え、聞き取りの誤りの修正をしないでください。
- 約束か案内か決められないときは、type を needs_check にしてください。
- 料金、使用量、口座、カードなどの数字を request と actions_taken に書かないでください。
  「請求額についての問い合わせ」のように、何についての話かだけを書いてください。
- 文字起こしに無い手続きや案内を、あったこととして書かないでください。
- お客さまの感情、話し方、人柄について書かないでください。
- 苦情として扱うべきか、保安上の対応が要るかを判断しないでください。
  当てはまりそうな発話を引用するだけにしてください。

【通話の日付】{call_date}
【契約の情報】{contract}
【問い合わせの種類のコード表（版：{code_version}）】{codes}
【文字起こし】{transcript}

「期日を日付に直さない」を書いているのは、AIが親切に直すからです。 通話の日付を渡していると、「明日」を翌日の日付にします。金曜の夕方の「明日」が翌営業日の月曜を指していても、AIは土曜にします。 日付にするのは、営業日のカレンダーを持つ顧客管理システムの側です。

「約束と案内を分ける」を2か所に書いているのも同じ理由です。 1か所だけだと、「お送りしますので、ご記入のうえご返送ください」の後半まで約束として拾います。

出力形式を固定する

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

{
  "call_id": "",
  "code_version": "",
  "request": "",
  "actions_taken": { "procedures": [""], "guidance": [""] },
  "category_main": "move_in_out | billing | payment_method | plan_change | cancellation | meter_usage | outage_equipment | gas_open_close | other",
  "category_sub": [""],
  "follow_ups": [
    { "type": "callback | send_document | gas_visit_arrange | internal_request | needs_check",
      "what": "", "said_due": "", "quote": "", "timestamp": "" }
  ],
  "complaint_flags": [ { "quote": "", "timestamp": "" } ],
  "safety_flags": [ { "quote": "", "timestamp": "" } ]
}

公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があり、最大100個のオブジェクトのプロパティと最大5段の入れ子が持てるとされています。また、文字列の minLength や pattern、配列の minItems や maxItems は使えないキーワードとされています。「従のコードは最大2つ」はスキーマでは縛れないので、受け取ったあとに Azure Functions で3つ目以降を落とします。

1つ目の理由は、コードを表の値に縛れることです。 category_main は enum でコード表の大分類だけを受けます。コード表を改定したら、スキーマの enum も同じ版に合わせて作り直します。

2つ目は、次の対応の引用をプログラムで照合できることです。 Azure Functions が quote を文字起こしの該当の時刻の行と突き合わせ、一致しないものは下書きの画面で赤く示し、作業一覧への登録の候補から外します。

システムへ連携する

Responses API ではなく Chat Completions API を使います。 公式の説明では、Responses API は会話の履歴などを保存する機能とされています。1通話ごとに完結する処理なので、履歴を残す必要がありません。 お客さまの情報を含む入力が、意図しない場所に残ることを避けます。

顧客管理システムへ書き込むのは、下書きの欄だけです。 保存済みの応対記録や契約の情報は書き換えません。次の対応も、下書きのまま作業一覧に載せないようにし、オペレーターの確定を待ちます。

人が確認する

1. 要件と対応した内容を読む … 自分の電話なので、記憶と違うところだけ直します。清書から始めないので、ここは短く済みます
2. 問い合わせの種類のコードを確かめる … 主のコードが違えば選び直します
3. 次の対応を1つずつ確定する … 引用を見て、約束したことかを確かめ、期日を日付にし、担当を選びます。約束したのに下書きに無いものは、ここで足します
4. 保存する … 保存した時点で、次の対応が担当の作業一覧に載ります
5. supervisor の通話はスーパーバイザーが見る … 苦情として社内で管理するか、保安の窓口へ連絡済みかを確かめます

3番目を省かないでください。 次の対応は、この構成でいちばん外せない欄です。下書きに無い約束をオペレーターが足すたびに、その記録を残し、指示の書き方を見直す材料にします。

目標は、9,000件をならして1件1.5分です。 ready の下書きは読んで保存するだけで1分足らず、check_follow_up は引用を確かめて期日を入れるので2〜3分かかります。

例外に対処する

3行目は、この構成の外の手順が前提です。 ガス漏れや停電の通報は、下書きを待たずに通話中に保安の窓口へつなぐもので、この構成はその記録があるかを後から確かめる材料を出すだけです。

記録を残す

• 録音のファイル名と、文字起こしの結果（時刻・チャネル付き、伏せ字の後）
• 使ったコード表の版と、スキーマの版
• Azure OpenAI に渡した入力と、返ってきたJSONの全文
• 引用の照合の結果と、下書きの状態（ready など）
• オペレーターが直した記録 … どの欄を、何から何に変えたか。足した次の対応
• 下書きができるまでの時間と、manual になった件数

5つ目が、指示とコード表を直す材料になります。 特定のコードで選び直しが多ければ、コード表の注記が足りていません。次の対応を足した件数が多ければ、約束の言い方のパターンを指示に足します。