満期が近い保険契約を毎月洗い出し、更改されないおそれの高い順に連絡先を並べる

処理の起点を決める

毎月第1営業日の定時に、1回だけ動かします。 満期は1年前から決まっているため、日々の変化を追う必要はありません。月初にまとめて一覧を出すほうが、担当者がその月の連絡の段取りを組めます。

対象は2つの幅に分けます。新たに翌々月の満期に入った契約（月360件）と、翌月の満期で前月から持ち越した契約です。前者は初めての採点、後者は前月の連絡の結果を反映した採点のやり直しです。持ち越し分は、前月に連絡が取れなかった契約ほど点数が上がります。

実行の前に、代理店システムのCSVが当月の日付で出力されているかを確かめます。古いファイルのまま動くと、前月の一覧が当月の顔をして配られます。

入力データを集める

質を決めるのは、いちばん下の行です。 学習には「どの契約が更改されなかったか」が要ります。しかも理由の区分が要ります。 車を手放したので保険が不要になった契約と、他社へ移った契約を同じ「更改されず」にすると、車を手放しそうな顧客を探すモデルができてしまいます。

接触の記録は、つながらなかった電話も残します。 「3回かけて1回もつながらない」は、更改されないおそれの強い材料です。記録の粒度をそろえることが、最初の準備になります。

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

取得は、代理店システムから出力したCSVと、顧客管理の表を Python の pandas で読み込み、契約番号で結合するだけです。代理店システムのAPIには頼りません。API連携の有無や仕様は保険会社ごとに異なるため、この構成ではCSV出力を前提にし、API連携は利用環境に応じた個別実装とします。

特徴量は、担当者が口で説明できるものだけにします。 「考え方」の列は仮説で、実際にどちらへ効くかは学習の結果で確かめます。 仮説と逆の係数が出たら、データの取り方を疑います。

入れない特徴量も先に決めます。 契約者の年齢、性別、国籍、住んでいる地域は使いません。担当者の番号も使いません。 入れると、点数が担当者の成績を映すようになります。

AIへ渡す前に整形する

1. 対象外の別枠化 … 解約の申し出が受付済み、フリート契約、団体扱いの契約は点数を出さず、別のシートに並べます
2. 学習データの理由の仕分け … 過去の「更改されず」のうち、車両の売却・廃車、物件の売却、契約者の死亡など保険の対象が無くなったものは、学習から外します
3. 時点の固定 … 特徴量は、その契約の満期の2か月前の時点で分かっていた情報だけで作ります
4. 欠損の扱い … 接触の記録が1件も無い契約は、日数を空欄にせず「記録なし」の印を別の列に立てます
5. 尺度をそろえる … StandardScaler で標準化してから学習します。Pipeline で標準化とモデルを一つにまとめ、採点のときも同じ変換を通します
6. 学習と検証の分け方 … ランダムに分けず、時期で分けます。 過去3年のうち古い2年半で学習し、直近の半年で検証します
7. 重複の検知 … 同じ契約番号が一覧に2回入っていないかを確かめます

3番目を軽く見ないでください。 過去の契約で「満期後に解約の申し出があった」という情報を特徴量に混ぜると、検証では高い精度が出て、本番では何も当たらないモデルになります。採点の時点では、まだ起きていない出来事だからです。

5番目の標準化は、理由を書き出すためにも必要です。 尺度がそろっていないと、係数の大きさを比べられません。

AIに処理させる

AIの仕事は2つに分かれます。 点数を出すのはロジスティック回帰で、メモを書くのは生成AIです。点数は生成AIに出させません。 同じ契約に毎回同じ点数が付かないと、順番を比べられないからです。

理由の書き出しは、モデルの計算そのものから作ります。 ロジスティック回帰では、各特徴量の係数と標準化後の値を掛けた値の合計が、点数のもとになる値（対数オッズ）です。この掛け算の値が大きい順に3つ並べれば、その契約で点数を押し上げている項目になります。 生成AIに理由を考えさせると、それらしい別の理由を書きます。

pipe = Pipeline([("scale", StandardScaler()), ("lr", LogisticRegression())])
pipe.fit(X_train, y_train)                      # y=1 が「更改されず」
score = pipe.predict_proba(X_now)[:, 1]         # 2列目を点数にする
z = pipe["scale"].transform(X_now)
contrib = z * pipe["lr"].coef_[0]               # 契約×特徴量の寄与
top3 = np.argsort(-contrib, axis=1)[:, :3]      # 押し上げている上位3つ

寄与が負の特徴量は、理由に出しません。 点数を下げている項目は「更改されやすい材料」なので、上位3つに正の値が3つ無ければ、あるだけを出します。

生成AIに渡すのは、上位の契約の要約だけです。 例えば各担当者の上位10件、合わせて月40件前後にします。渡すのは、種目、前年からの変化、異動の要点、事故の有無と対応の状況、接触の要点、そして上の3つの理由です。氏名・住所・電話番号・証券番号は渡しません。

1行目がいちばん起きやすい逸脱です。 「確認事項」を頼んでも、何も言わなければ「〇〇様、いつもお世話になっております」から始まる文面を書きます。メモは募集人が自分で読むもので、顧客には渡しません。

指示内容を固定する

あなたは損害保険代理店で、満期更改の面談を控えた募集人のために、
面談前に確認しておきたい事項を整理する立場です。
渡された契約の要約だけを見て書いてください。推測で事実を足さないでください。

【書くもの】
1. changes ……… 前年の満期から変わったこと（保険料、補償、異動）
2. to_confirm …… 面談で顧客に確かめたいこと。質問の形で書く
3. open_items …… 前回の接触で約束したまま終わっていないこと
4. cautions …… 面談の前に社内で確かめておくこと（事故の対応状況など）

【厳守事項】
- これは募集人が読む社内のメモです。顧客への挨拶、案内、説明の文面を書かないでください。
- 商品や補償を勧めないでください。「〇〇特約を付けるべき」とも書かないでください。
- 保険料の金額や見込みを計算しないでください。要約にある数字だけを写してください。
- 他社の商品や保険料と比べないでください。
- 要約に記載がないことは「不明」と書き、埋めないでください。
- 更改されない理由を断定しないでください。「〇〇の可能性があるため確認」までにしてください。
- 事故の相手方や、けがの内容について書かないでください。
- 点数と理由は変えずにそのまま扱い、評価し直さないでください。
- to_confirm は5つまで、各項目は60字以内にしてください。

【契約の要約】{contract_summary}
【点数を押し上げている理由（上位3つ）】{top_reasons}
【直近の接触の要点】{contact_notes}

「顧客への文面を書かない」を最初に置かないと、案内状になります。 面談の準備という言葉から、生成AIは顧客に見せる資料を想像しがちです。メモの読み手が募集人であることを、指示の冒頭で固定します。

「理由を断定しない」も同じです。 点数の理由に「保険料の上昇」があると、「保険料に不満があるため他社を検討中」と書きます。それは予測の理由であって、顧客の事実ではありません。 断定したメモを読んだ募集人は、その前提で面談に入ってしまいます。

出力形式を固定する

生成AIからは、次の形のJSONで受け取ります。 Claude API の構造化出力を使い、output_config.format に type: "json_schema" とスキーマを指定します。スキーマに沿った応答を制約付きの生成で保証するとされ、JSONの解析で失敗しません。

{
  "contract_key": "",
  "changes": [""],
  "to_confirm": [""],
  "open_items": [""],
  "cautions": [""],
  "unknown_fields": [""]
}

スキーマで字数や件数の上限は縛れません。 構造化出力は minLength maxLength などの文字列の制約や、minimum maximum などの数値の制約に対応していないとされています。「5つまで」「60字以内」は、受け取ったあと Python の側で数えて確かめます。

モデルの採点の結果は、生成AIとは別の表に持ちます。

1つ目の理由は、点数とメモを別の層に置けることです。 点数はモデルが決め、メモは生成AIが書きます。メモがうまく書けない月も、一覧は出せます。

2つ目は、lane で期限の枠を分けられることです。 満期まで30日を切って一度も接触できていない契約は、点数にかかわらず deadline に入れて一覧の先頭に置きます。 点数が低くても、手続きが間に合わなければ満期を過ぎてしまいます。

3つ目は、model_version で後から振り返れることです。 学習し直したモデルで順番が変わったとき、どの版の点数で連絡したかが分かります。

システムへ連携する

代理店システムへは書き込みません。 契約の手続きは、これまでどおり保険会社の手順で募集人が行います。この構成が出すのは、連絡の順番の案とメモの下書きまでです。

一覧は担当者ごとのシートに分け、自分の担当分だけを開けるようにします。 他の担当者の顧客の事情まで全員に見せる必要はありません。

人が確認する

担当者が見るのは、自分の担当の一覧全体です。 上位だけを見るのではありません。1件ずつ詳しく見るのは上位と期限枠で、残りは点数と理由を流し見ます。

1. 期限枠を先に見る … deadline の契約は、点数にかかわらず今週中に連絡します
2. 上位の理由を読む … 3つの理由が、自分の知っている事情と合っているかを確かめます
3. 順番を入れ替える … 先週会ったばかり、すでに更改の意向を聞いている、といった事情があれば後ろに回します。入れ替えた理由を一言残します
4. メモの下書きを直す … 使う項目だけを残し、断定になっている箇所を直します
5. 連絡の結果を記録する … つながったか、次の約束、更改の意向の有無を顧客管理の表に書きます

3番目を省かないでください。 担当者が入れ替えた契約がのちにどうなったかは、モデルが見落としている事情を教えてくれる材料です。

目標は、360件をならして1件4分です。 上位と期限枠で全体の2割前後という想定で、それより多い月は、点数の閾値か期限枠の条件を見直します。

メモは募集人の手元の準備で、面談の記録ではありません。 面談で確かめた顧客の意向や、説明した事項の記録は、代理店が定めた手順と様式で別に残します。

例外に対処する

上から3行目までが大半を占めます。 どれもモデルの問題ではなく、データの側で「その契約が点数を出してよい状態か」を見分ける問題です。 ここを別枠に分けるほうが、モデルの精度を上げるより効きます。

記録を残す

• 採点に使った特徴量の全列と、その時点のCSVのファイル名と出力日
• 点数、順位、理由の上位3つ、lane、model_version
• 担当者が順番を入れ替えた記録と、その理由
• 生成AIに渡した要約と、返ってきたメモ、担当者が直したあとのメモ
• 連絡した日、方法、つながったか、結果
• 満期後の更改の結果と、更改されなかった理由の区分
• モデルを学習し直した日、学習に使った期間、検証の結果

3つ目と最後から2つ目がそろって、初めて学習データになります。 「点数が高く、連絡して、更改された」契約と、「点数が高く、連絡できず、更改されなかった」契約を分けられないと、連絡の効果とモデルの当たり外れが混ざります。

連絡したかどうかは、必ず残します。 これが無いと、第12章で述べる学習データの偏りを確かめられません。