保険の募集の面談の録音から、意向把握と比較説明の記録を作る

処理の起点を決める

起点は、面談の文字起こしがそろったことです。 オンラインは Teams の会議が終わり、文字起こしが保存された時点、来店と訪問は募集人が録音のファイルを所定の場所に置いた時点です。面談の当日のうちに下書きが出ることを目標にします。 翌日に回すと、募集人が面談の中身を覚えているうちに確かめる、という前提が崩れます。

Teams の文字起こしには前提があります。 文字起こしは開催者ごと・ユーザーごとのポリシー設定で、会議に文字起こしを含めるには開催者がこの設定をオンにしている必要があります。レコーディングや文字起こしを開始するユーザーも同様です。レコーディングが有効でも文字起こしがオフなら、トランスクリプトのファイルは保存されません。 面談を始める前に、募集人のアカウントの設定を業務管理部で確かめておきます。

録音の了承が取れなかった面談は、この仕組みに入れず、従来どおり手で記録を書きます。

入力データを集める

質を決めるのは、下の2つです。 様式の定義が曖昧だと、AIは項目の意味を自分で解釈します。「優先する事項」の欄に何を書くのかを、様式の側で一文ずつ決めておきます。 商品名の一覧が無いと、文字起こしの誤変換がそのまま記録に残ります。

前回までの記録を渡すのは、意向の変化を見るためです。 監督指針では、最終的な顧客の意向が確定した段階で、その意向と当初把握した主な顧客の意向を比較し、相違している場合にはその相違点を確認する方法が例として示されています。AIには、当初の記録と今回の発言が食い違う項目を、並べて示すところまでさせます。

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

Teams の文字起こしを取り出す方法は、利用環境に応じた個別実装が必要です。 最初は、募集人が保存先から所定のフォルダに置く運用で足ります。

音声文字起こしのAPIに渡すファイルには条件があります。 形式は mp3、mp4、mpeg、mpga、m4a、wav、webm で、1ファイル25MBまでです。面談は1時間を超えることも多く、録音アプリの設定によってはこの上限を超えます。超える録音は、文の途中で切らないように分けて渡します。 途中で切ると、前後の文脈が失われて精度が落ちます。

話者の区別には、募集人の声を先に登録しておけます。 話者を区別する形式では、2〜10秒の既知の話者の音声を最大4つまで参照として渡し、区間を特定の話者に対応づけられます。6名の募集人の短い音声を用意しておけば、募集人の名前で区間が返ります。 顧客側は登録しません。

AIへ渡す前に整形する

1. 了承の確認 … 面談の基本情報で録音の了承が「あり」になっていることを確かめます。「なし」または未入力なら、処理を止めて募集人に戻します
2. 形式とサイズの確認 … 録音が対応形式であること、25MB以内であることを確かめます。超えるものは、無音の区間で分けます
3. 用語の指定 … 文字起こしの際に、取扱商品と特約の正式名称を指示として渡します。音声文字起こしのAPIでは、指示を与えることで固有名詞や略語、専門用語の認識を改善できるとされています
4. 話者の整理 … 募集人の発言と顧客の発言にラベルを付けます。顧客の同席者（配偶者など）がいれば、顧客側の話者として分けて残します
5. 面談と関係のない部分の除去 … 冒頭の雑談や、移動中に録音が回り続けた区間を、時刻で切り落とします
6. 健康に関する発言の印付け … 病歴や通院の話は、面談記録ではなく告知の手続きで扱います。該当する区間に印を付け、記録の下書きでは「健康状態の話題あり」とだけ書かせます
7. 前回の記録の添付 … 顧客番号から前回までの記録を引き、当初の意向の項目だけを渡します

6番目は、渡す範囲を決める作業です。 様式に欄が無い情報を、AIに要約させる理由はありません。

AIに処理させる

させるのは、様式の項目ごとに、顧客の発言から意向を要約し、根拠の発言と状態を付けることだけです。 項目は、募集管理規程の様式をそのまま並べます。

「意向」を書くのは顧客の発言からだけです。 意向の各項目には、根拠の発言がどちらの話者かを source に残します。顧客が自分から言ったものは customer_stated、募集人の言葉に顧客がうなずいただけのものは agent_led です。agent_led は意向として消さずに残し、そう書いたうえで募集人に判断を返します。

1行目がいちばん起きやすい失敗です。 監督指針には、性別や年齢などの顧客属性や生活環境から意向を推定する方法も例として挙げられていますが、その場合はどのような意向を推定して設計したかを説明することが考えられるとされています。推定するかどうかは募集人が決めることで、AIが黙って推定した値は、推定だったことが記録から分かりません。 そこでAIには推定をさせず、募集人が推定するときは自分で「推定」と明記して書き足します。

指示内容を固定する

あなたは保険代理店の業務管理部で、保険募集の面談記録の下書きを作る立場です。
面談の文字起こしだけを根拠にして、指定の様式の項目を埋めてください。

【入力】
- 文字起こし：{transcript}（話者ラベル付き。「募集人」または「顧客」「顧客の同席者」）
- 前回までの記録：{previous_intent}
- 取扱商品の一覧：{product_list}
- 様式の項目と書き方：{form_definition}

【status の選び方】
- recorded ... 顧客の発言から、その項目の内容が分かる
- not_asked .. その項目について、面談で話題に出ていない
- no_answer .. 募集人が聞いたが、顧客が答えなかった、または「考えておく」と保留した
- unclear .... 話題には出ているが、文字起こしが途切れているなどで内容を確定できない
迷ったときに recorded を選ばないでください。

【厳守事項】
- 顧客の意向の項目は、顧客（または同席者）の発言だけを根拠にしてください。
- 記載がなければ「不明」とし、status を not_asked にしてください。
  年齢、家族構成、職業などから推測して埋めないでください。
- 募集人が言った保険料や保険金額を、顧客の希望として書かないでください。
  顧客が自分で金額を言っていなければ not_asked です。
- 募集人の問いかけに顧客が「はい」「そうですね」と答えただけの場合は、
  source を agent_led にしてください。customer_stated にしないでください。
- 推奨理由は、募集人が実際に口にした理由だけを要約してください。
  理由を補ったり、一般的な推奨理由を足したりしないでください。
- 商品名は取扱商品の一覧の正式名称に合わせてください。
  一覧に無い名前は、聞こえたとおりに書き、status を unclear にしてください。
- 商品が顧客の意向に合っているか、どの商品がよいかは書かないでください。
- 病歴、通院、服薬など健康状態に関する話は要約せず、
  health_topic_mentioned を true にするだけにしてください。
- 前回までの記録と今回の発言が食い違う項目は、intent_changes に両方を並べてください。
  どちらが正しいかは判断しないでください。
- evidence には、根拠にした発言の時刻と、発言をそのまま短く写してください。
- 次回の約束で期限が言われていなければ、due_date は null にしてください。
  「来週中」のような言い方は、そのまま due_text に写してください。

「提案額を希望として書かない」を独立させているのは、いちばん混ざりやすいからです。 面談で金額を口にするのはたいてい募集人で、何も言わなければその金額を「保険料の希望」に入れます。第3章の（b）の失敗の再現です。

出力形式を固定する

次の形のJSONで受け取ります。 Structured Outputs のスキーマで、全項目を必須、状態を列挙にしておきます。

{
  "interview_id": "",
  "customer_id": "",
  "recording_consent": true,
  "intent": [
    { "item": "coverage_area",
      "status": "recorded | not_asked | no_answer | unclear",
      "summary": "", "source": "customer_stated | agent_led | null",
      "evidence": [ { "time": "", "quote": "" } ] }
  ],
  "intent_changes": [
    { "item": "", "previous": "", "current": "", "evidence": "" }
  ],
  "products": {
    "presented": [ { "name": "", "insurer": "", "status": "" } ],
    "compared": [ { "name": "", "insurer": "", "status": "" } ],
    "reason": { "status": "", "summary": "", "evidence": [] }
  },
  "explained_items": [ { "item": "", "status": "" } ],
  "next_actions": [
    { "action": "", "owner": "agent | customer",
      "due_date": null, "due_text": "" }
  ],
  "health_topic_mentioned": false
}

intent には、様式の意向の欄と同じ数の要素を並べます。item は coverage_area ／ savings_need ／ period_premium_amount ／ priority です。

1つ目の理由は、not_asked が項目として残ることです。 項目が消えるのではなく、状態として残るので、次の面談で聞く事項の一覧が、この値から機械的に作れます。 業務管理部の点検でも、not_asked の数で記録を並べ替えられます。

2つ目は、due_date と due_text を分けたことです。 「来週中」を日付に直すのは、AIではなく募集人です。AIが勝手に日付を決めると、募集人が約束していない期限が台帳に載ります。

応答の拒否にも備えます。 Structured Outputs では、安全上の理由でモデルが応じなかった場合、応答に refusal という項目が付き、プログラムで検知できるとされています。検知したら下書きを作らず、募集人に手で書いてもらいます。

システムへ連携する

顧客管理システムへは、AIの出力を直接書き込みません。 募集人が確認を終えたときだけ、確認の画面から保存します。台帳への追加も確認済みの記録からだけ行います。

人が確認する

募集人は、全件の下書きを確かめます。 ただし、読むのは文字起こし全体ではなく、各項目の evidence です。

1. agent_led の項目を先に見る … 顧客の同意として扱ってよいかを決めます。扱わないなら not_asked に直し、次回に聞く事項に回します
2. not_asked と no_answer を確かめる … 本当に聞いていないのか、文字起こしが拾えていないだけかを見ます。聞いたのに拾えていなければ、録音の該当時刻を聞いて直します
3. 推奨理由を確かめる … 話したとおりの要約か、足りない理由を補っていないかを見ます
4. 次回の約束の期限を決める … due_text を日付にし、台帳に載せる約束を選びます
5. 推定して書き足すものがあれば明記する … 推定したことを本人が書きます

2番目を省かないでください。 聞いていないものを聞いたことにするのは、この仕組みが防ぎたかった失敗そのものです。

例外に対処する

上から4行目までは、AIではなく録音と文字起こしの準備の問題です。 面談の始めに了承を取り、録音が回っていることを確かめる手順を決めるほうが効きます。

記録を残す

• 録音の了承の記録（面談日時、了承の有無、伝えた内容）
• 文字起こしの全文と、話者の区別の結果
• AIに渡した様式の版と、指示の版
• AIが返したJSONの全文と、募集人が確認・修正した後の記録
• 募集人が直した項目の差分 … どの項目を、どの状態からどの状態に変えたか
• 次回の約束と、台帳に載せた日、完了した日

様式の版を残すのは、様式が変わるためです。 どの版で作った記録かが分からないと、not_asked が本当に聞いていないのか、当時は項目が無かったのかが区別できません。

差分の記録は、指示を直す材料になります。 recorded を not_asked に直す件数が多いなら、AIが推測で埋めています。 毎月数えます。