保険会社で、高齢の顧客への募集の面談記録と意向確認の記録を、家族の同席・複数回の面談・理解度の確認の社内ルールに照らして点検し、記録の不足を営業店へ返す

処理の起点を決める

起点は、高齢者に当たる顧客の申込が受け付けられ、ルールが求める確認電話の記録がそろったことです。 確認電話が要らない区分の申込は、受付の時点で動かします。契約の成立の前に点検の結果が出ていることが、この構成の前提です。

確認電話の記録が一定の日数そろわない申込は、別の一覧に載せます。 電話がつながらない、顧客が不在といった事情で止まっているもので、点検の対象ではなく、コールセンターと営業店の連絡の対象です。

月末に申込が集まっても、1件ずつ動かします。 夜間にまとめて点検すると、成立の手続までの日数が月末ほど短くなり、営業店が再面談を組む時間が残りません。 受付の順に点検し、一覧は成立の予定日の近い順に並べます。

営業店が記録を補ったときも、同じ起点で動かし直します。 そのときは前回の判定と連絡の内容も渡し、前回の不足が埋まったかを項目ごとに示します。 補記の日時が申込の日より後であることも、そのまま表示します。

入力データを集める

質を決めるのは、ルールの表の「記載とみなす条件」です。 例えば理解度の確認なら、「顧客が商品の仕組みや解約時の扱いを自分の言葉で説明した、または募集人の質問に答えた旨の記載がある」のように、本文に何が書かれていれば記載ありとするかを、項目ごとに文で決めます。 条件が「理解度を確認したこと」だけだと、「ご理解いただけた」の一文で記載ありになります。

続柄の対応表は、同席者の判定に効きます。 社内規則が同席を求める「親族等」の範囲を表にし、書き方の違う続柄を同じ区分にそろえます。 表に無い書き方は判断不能として人に回します。

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

営業支援の仕組みと電子申込の仕組みからの取り出しは、各社の仕組みに応じた個別の実装になります。 APIが無い場合は、夜間に出力するファイルを中継プログラムが読む形にします。

面談の間隔は、訪問の日時の項目から中継プログラムが数えます。 ルールが「申込の前に、日を改めて2回以上の面談」と定めていれば、申込日より前の面談のうち、日付が異なるものを数えます。 同じ日に2回訪問した記録は1回として数え、モデルには数えさせません。

確認電話の実施者は、所属で判定します。 募集人以外による確認が求められている区分では、実施者の所属が募集を行った営業店であれば、記録があっても不足とします。

AIの呼び出しでは、構造化出力のスキーマを要求に付けます。 Chat Completions API なら response_format、Responses API なら text.format に JSON Schema を渡します。スキーマではすべての項目を required にし、オブジェクトごとに additionalProperties: false を付けます。 status は Enum で4つの値に限り、モデルが「おおむね満たす」のような5つ目の値を作れないようにします。出力の項目はスキーマの順に並ぶので、item を先、evidence を後に置き、判定より先に根拠の文を書かせたいときは順を入れ替えます。 項目は合わせて100まで、入れ子は5段までという上限があるため、面談ごとの判定は checks の配列の要素として持たせ、入れ子を深くしません。

AIへ渡す前に整形する

1. ルールの区分を決める … 申込日の時点の契約者の年齢と商品の種類から、ルールの表の行を選びます
2. 面談記録を申込日より前に絞る … 申込の後の訪問は、複数回の面談の数に入れません
3. 同席者の欄をそろえる … 続柄の対応表で区分にし、表に無い書き方に印を付けます
4. 個人を特定する情報を置き換える … 顧客の氏名・住所・電話番号を記号に置き換えてからAIに渡します
5. 本文を面談ごとに区切る … 面談の日時を見出しにして、どの面談の記載かが分かる形にします
6. 補記を分ける … 申込の後に書き足された部分は、補記として別に渡します

6番目を軽く見ないでください。 補記の部分を元の記録と区別せずに渡すと、申込の後に書き足した「長男様同席」が、申込の前の面談の事実として判定されます。 補記を受け付けること自体は構いませんが、点検の結果には「補記による記載」と分けて残します。

4番目は、判定の精度に影響しません。 点検に要るのは続柄と発言の中身で、顧客の氏名は要りません。 置き換えた記号と元の値の対応は中継プログラムの中だけに持ちます。

AIに処理させる

させるのは、面談記録の本文から、ルールの項目ごとに「記載とみなす条件」に当たる文があるかを判定し、根拠の文をそのまま書き出すことだけです。 回数・間隔・人数・実施者は中継プログラムが計算します。

右端の列が、この構成でいちばん大事な区別です。 not_found は記録に無いということ、conflict は記録どうしが食い違っているということで、前者は営業店に記録の確認を頼むもの、後者は担当者が先に読むべきものです。

4行目がいちばん起きやすい失敗です。 本文に「ご家族とも相談済みとのこと」とあると、モデルは同席者の発言の項目を記載ありにしがちです。伝聞は同席の記録ではありません。 指示で明記し、根拠の文が伝聞なら ambiguous にさせます。

指示内容を固定する

あなたは保険会社の募集管理部で、高齢の顧客への募集の記録を点検する立場です。
渡された面談記録と確認電話の記録だけを見て判定してください。推測で補わないでください。

【点検する項目】
{rule_items}
（項目ごとに「記載とみなす条件」が書いてあります）

【status の選び方】
- found ....... 条件に当たる文が記録にある
- not_found ... 条件に当たる文が無い。項目名や定型の一文だけの場合も not_found
- conflict .... 記録どうし（同席者の欄と本文、面談記録と確認電話）が食い違う
- ambiguous ... 当たりそうな文はあるが、伝聞や言い回しのため決められない
迷ったときに found を選ばないでください。

【厳守事項】
- 記載がなければ「不明」とし、status を not_found にしてください。
- 「ご理解いただけた」「十分に説明した」のような募集人の評価だけの文を、
  理解度の確認の記載として扱わないでください。
- 「家族と相談済み」「家族も賛成」のような伝聞を、同席の記載として扱わないでください。
  その場合は ambiguous にしてください。
- 面談の回数・間隔・日付を数えないでください。別に計算します。
- 「補記」として渡した部分を根拠にしたときは、from_addendum を true にしてください。
- evidence には、判定の根拠にした文を記録からそのまま写してください。
- 顧客が理解していたか、契約が適しているか、申込を通すべきかを書かないでください。

【適用するルールの区分】{rule_set}
【面談記録（面談ごと）】{interview_notes}
【補記】{addendum}
【確認電話の要旨】{call_summary}
【同席者の欄（続柄の区分）】{attendees}

「募集人の評価だけの文を、理解度の確認として扱わない」を明記しないと found になります。 面談記録の多くは「ご理解いただけました」で締めくくられ、何も言わなければモデルはその一文を根拠に選びます。禁じるのは、評価の文を事実の記載として扱う判断そのものです。

伝聞の扱いを書くのも同じ理由です。 同席を求めるルールの趣旨は、親族等が説明をその場で聞くことにあり、「相談済み」はその代わりになりません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "application_id": "",
  "rule_set": "",
  "checks": [
    { "item": "", "status": "found | not_found | conflict | ambiguous",
      "interview_date": "", "evidence": "", "from_addendum": false }
  ]
}

中継プログラムが、計算の結果と合わせて次の形にまとめ、点検の一覧に載せます。

{
  "application_id": "",
  "branch": "",
  "rule_set": "",
  "computed": { "interviews_before_application": 0, "interval_days": 0, "attendee_category": "", "call_by_non_seller": true },
  "checks": [],
  "verdict": "ok | record_missing | needs_review",
  "missing_items": [],
  "branch_notice_draft": ""
}

1つ目の理由は、checks と verdict を別の層に置けることです。 checks はAIが埋め、verdict は規則の表で決めます。ルールの項目や区分が変わっても、直すのは表だけです。

2つ目は、computed を AI の判定と並べられることです。 同席者の欄が「長男」で attendee_category が親族等なのに、本文の同席者の発言が not_found なら、欄だけ埋めた記録かもしれないと担当者に分かります。

3つ目は、from_addendum で補記による記載を分けられることです。 補記で埋まった項目は自動で ok にせず、担当者が補記の中身と日時を読んでから閉じます。

システムへ連携する

面談記録にも申込の状態にも書き込みません。 営業店が補記するのは営業支援の仕組みの画面からで、点検の構成が記録を書き換える経路を作りません。

人が確認する

募集管理部の担当者は、record_missing と needs_review の申込だけを開きます。 ok の申込は一覧で件数と営業店を流し見ます。

1. needs_review を先に見る … conflict は記録どうしの食い違いで、同席の有無そのものが疑わしいことがあります
2. record_missing の根拠を確かめる … 該当する面談の本文を開き、本当に記載が無いかを目で確かめます
3. 営業店への連絡を直して送る … 下書きの不足の項目と、補記か再面談・確認電話のやり直しかの判断を求める文を確かめます
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

3番目の連絡では、「書き足してください」と書かないでください。 書き足しを求めると、同席が無かった面談にも同席の記録が書かれます。求めるのは「事実を確かめ、あった事実だけを補記するか、ルールの手続をやり直すか」の判断です。

営業店の対応は、点検の一覧の上で追います。 連絡を送った申込には返答の期限を付け、成立の予定日の前日までに返答が無いものを毎朝並べます。 返答が「再面談」なら、再面談の記録がそろった時点で起点が動き、前回の不足と並べて点検し直します。

目標は、480件をならして1件5分です。 開くのは3割前後という想定です。

例外に対処する

最後の行は、成立の前の点検が抜けないための約束です。 呼び出しが失敗した申込を点検済みとして扱うと、月末の申込の山の中で不足が成立まで残ります。

記録を残す

• 点検に使った面談記録・意向確認書・確認電話の記録の写しと、取り出した日時
• 適用したルールの区分と、そのときのルールの表の版
• 計算の結果（面談の回数・間隔、同席者の区分、確認電話の実施者）
• AIの判定の全文（checks）と、規則で決めた verdict
• 営業店への連絡の文と、営業店の対応（補記／再面談／確認電話のやり直し）
• 担当者が判定を覆した記録と、営業店・募集人ごとの不足の件数

ルールの表の版を残すのは、社内規則が見直されるためです。 監督指針は取組みの適切性の検証を求めており、検証のときに「当時のルールでは何を求めていたか」と「点検で何を見たか」を並べられるようにしておきます。