生命保険の乗合代理店が保険会社ごとの払込の書き出しと自店の接触の記録をそろえ、翌月に未入金・失効・解約に向かいそうな契約を Python で見込み、世帯ごとの連絡の予定にする

処理の起点を決める

月初の1営業日目、8社分の書き出しが決まったフォルダにそろった時点で動かします。 業務管理の担当が書き出しを置き終えたら、フォルダに「そろった」の印のファイルを置き、ジョブ管理の仕組みが15分ごとにその印を見に行きます。印が無いまま動かすと、置きかけの書き出しで一覧ができます。

見込む先は「翌月末までに、未入金・失効・解約の請求のいずれかが起きるか」です。 予定表が配られるのは今月の初めで、募集人が連絡するのは今月中です。翌月に止まりそうな契約に今月話せれば、払込が止まる前に間に合います。 未入金を的に入れるのは、乗合代理店に届く記録で最も早く分かる「止まった」印だからです。

3つの出来事は1つの的にまとめます。 分けて見込むと、失効と解約はそれぞれ件数が少なく、モデルが学べる例が減ります。理由の事実の側で「払込が止まりそう」か「解約に向かっている」かが分かれば、募集人の話し方は変えられます。

入力データを集める

質を決めるのは、会社ごとの対応表と接触の記録の種類のコードです。 対応表が無ければ8社の記録を1つにできず、接触の記録に種類のコードが無ければ、自由記述を読むことになります。 自由記述には、契約者の健康や家族の事情が書かれていることがあり、読ませたくありません。

入れない列を、表で決めておきます。

1行目を外すのが、いちばん大事な判断です。 金融分野のガイドラインは、要配慮個人情報や保健医療に関する情報などを機微（センシティブ）情報とし、定められた場合を除いて取得・利用・第三者提供を行わないこととしています。解約の見込みのために使うことが、その場合に当たると言える根拠はありません。

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

保険会社の画面から自動で取ってくる仕組みは作りません。書き出しは、業務管理の担当がこれまでどおり画面から行います。 保険会社の代理店向けの画面の使い方は各社の決まりに従うもので、この構成が勝手に自動化してよいものではないからです。

読み替えのたびに、対応表に無い値を数えます。 書き出しに対応表に無い列の名前や、知らないコードが出てきたら、その会社の分は読み替えの警告として止め、業務管理の担当に知らせます。保険会社が書き出しの形を変えた月に、黙って間違った読み替えをしないためです。

学習用の正解から、代理店の中の乗換えを外します。 同じ世帯が当店を通してA社の契約を解約し、B社の契約に入り直した場合、A社の記録では「解約」です。これを1にすると、見直しの相談に乗った世帯ほど確率が上がるモデルになります。 解約の前後3か月に、同じ世帯で当店経由の新しい契約がある解約は、正解から外して別に数えます。

AIへ渡す前に整形する

1. 読み替える … 会社ごとの対応表で列の名前とコードを共通の項目に直します。対応表に無い値が出た会社は止め、警告を出します
2. つなぐ … 証券番号で顧客管理の契約とつなぎ、世帯番号と担当の募集人を引きます。つながらない証券番号の件数を会社ごとに残します
3. 対象を絞る … 払込が終わっている契約、払済に変えた契約、団体の扱いの契約は除きます
4. 時点をそろえる … 特徴はすべて「前月末の時点」で作ります。月末より後の記録を混ぜると、学習のときに答えを見てしまいます
5. 特徴を作る … 直近3か月・6か月の不能・未入金の回数、最後の不能からの日数、自動振替貸付の適用中か、口座・払込方法の変更からの日数、最後の接触からの日数、最後のアフターフォローからの日数、経過月数、保険会社、保険の種類、払込方法
6. 世帯の特徴を足す … 同じ世帯の他の契約で、直近3か月に未入金・解約の請求・減額があったか。世帯の中の契約の数と、保険会社の数
7. 入れない列を落とす … 入力データの表で決めた4つの列を、読み込みの段階で読まないようにします

6番目の世帯の特徴が、乗合代理店で効く特徴です。 1社の記録しか見られない保険会社には作れない特徴で、「B社の契約で解約の請求が出た世帯の、A社の契約」が、払込の記録だけでは見えない兆しになります。ただし、世帯の中の他の契約の結果を特徴に入れるときは、4番目の時点のそろえ方を同じように守ります。

AIに処理させる

させるのは、契約ごとに「翌月末までに未入金・失効・解約の請求のいずれかが起きる確率」を出すことだけです。 学習には、過去3年分の毎月末の時点の特徴と、その翌月末までの結果を使います。

3行目は、既定のままにしないでください。 公式の説明では、early_stopping の既定は 'auto' で、学習の件数が1万件を超えると早めに止める見張りが有効になります。 検証用の記録を渡さないと、学習の記録の一部が取り分けられて見張りに使われ、月の新旧が混ざった記録で止めどきを決めることになります。 検証用の X_val・y_val を fit に渡し、直近の月を使います。

較正をするのは、確率を件数の見積もりに使うからです。 店長が「今月、この店舗の上位50世帯のうち何世帯が実際に止まるか」を知るには、0.3という確率が3割前後を意味している必要があります。公式は、学習済みの分類器を FrozenEstimator で包んで較正でき、較正に使う記録は学習に使った記録と重ならないようにするとしています。isotonic はおよそ1,000件を超えれば sigmoid と同等以上ですが同じ確率の契約を生むことがあり、順番を厳密に保つため sigmoid を選びます。

理由の事実は、モデルではなく規則で並べます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、読み替え・学習・予定表の作り方を決める設定を、ひとつのファイルにまとめます。

【見込む先】
target: 翌月末までに 未入金 / 失効 / 解約の請求 のいずれか（満期・死亡・転換は 0）
exclude_from_target: 解約の前後3か月に同じ世帯で当店経由の新契約がある解約（乗換え）
as_of: 前月末

【読み替え】
mapping_table: 会社ごとの対応表（列の名前・払込の結果のコード・理由のコード）
on_unknown_value: その会社の分を止めて警告（推測で読み替えない）

【読まない列（読み込みの段階で除く）】
- 給付金・保険金の請求の履歴、告知の内容、引受の条件
- 接触の記録の自由記述
- 性別、国籍、年齢の区分

【モデル】
estimator: HistGradientBoostingClassifier(categorical_features="from_dtype")
validation: 直近3か月の月末時点を X_val / y_val として fit に渡す
calibration: CalibratedClassifierCV(FrozenEstimator(model), method="sigmoid")
             較正用は学習・検証と重ならない月
学習期間: 直近36か月の月末時点

【予定表】
- 世帯ごとにまとめ、世帯の中で最も高い確率で並べる
- 募集人1名あたり最大20世帯
- 担当のいない世帯は、確率にかかわらず店長の一覧に載せる
- 学習に無い保険の種類・新しく扱い始めた保険会社の契約は、確率を出さず「要確認」

【理由の文】
- 第7章の理由の表の5つの条件だけを使う
- 当てはまる条件が無い世帯は「記録上の目立った変化なし（モデルの確率のみ）」と書く

「推測で読み替えない」を設定に書くのは、対応表に無い値を近いコードに寄せたくなるからです。 知らないコードを「不能」と読めば確率が上がり、「済」と読めば一覧から落ちます。どちらに寄せても間違いなので、止めて人に聞きます。

出力形式を固定する

予定表は表で出し、同じ内容を JSON でも残します。 表は募集人が読むため、JSON は翌月の振り返りと監査のためです。

{
  "as_of": "2026-09-30",
  "model_version": "agency-lapse-2026-09",
  "store": "駅前店",
  "agent_id": "S-012",
  "mapping_warnings": [],
  "households": [
    {
      "household_no": "",
      "max_probability": 0.37,
      "rank_in_agent": 1,
      "policies": [
        { "policy_no": "", "insurer": "〇〇生命", "product_type": "医療保険", "probability": 0.37 },
        { "policy_no": "", "insurer": "△△生命", "product_type": "終身保険", "probability": 0.12 }
      ],
      "reasons": [
        "同じ世帯の△△生命の契約で減額の請求あり",
        "最後の接触から14か月"
      ],
      "flags": ["no_owner | unseen_product | none"]
    }
  ]
}

世帯の下に契約を並べる形にするのは、募集人が1回の連絡で世帯の契約をまとめて話せるようにするためです。 確率の低い契約も世帯の中に載せるので、「医療保険の払込が止まりそう」と聞いて電話をしたら、実は終身保険の見直しを考えていた、という場面でも、募集人の手元に世帯の契約がそろっています。

JSON に mapping_warnings を残すのは、どの月にどの会社の読み替えで警告が出たかを後から追うためです。 警告が出た月の予定表は、その会社の契約の確率が信用できません。

システムへ連携する

接触の記録へは書き込みません。 確率を顧客管理に入れると、次の月にその確率がまた特徴として読み込まれ、 モデルが自分の出した数字を学ぶことになります。

募集人が見られるのは、自分の担当の世帯だけにします。 店長は店舗の分、業務管理の担当は全店の分です。

人が確認する

1. 読み替えの警告 … 警告の出た会社の書き出しを開き、形の変更なら対応表を直して動かし直します。警告が残ったまま予定表を配りません
2. 担当のいない世帯 … 確率にかかわらず全件。店長と新しい担当を決めます
3. 学習に無い保険の種類・保険会社の契約 … 確率を出していないので、記録を見て順番を付けます
4. 確率の上位30世帯 … 理由の事実が書き出しと合っているかを元の書き出しで確かめます

店長は、予定表を配る前に順番を入れ替えてかまいません。 入れ替えたときは理由を予定表の欄に書きます。この欄が、モデルが知らない事情の記録になります。

目標は、600件をならして1件2分です。 全件を開くのではなく、上の4つに入る契約だけを開き、残りは予定表で確率と理由を流し見ます。

例外に対処する

1行目で、そろわない会社の分だけ外すのは、待つと月初が過ぎるからです。 7社分で予定表を作り、残りの1社の契約は「記録未着」として理由の事実だけを並べます。

6行目は必ず入れてください。 連絡を控えてほしいと申し出た契約者に、予定表に載ったからと連絡すると、それ自体が苦情になります。

記録を残す

• 月ごとの8社の書き出しの件数、読み替えの警告、つながらなかった証券番号の件数
• 会社ごとの対応表の版（いつ、どの列やコードを直したか）
• モデルの版、学習・検証・較正に使った期間、検証の結果（上位の世帯のうち実際に止まった割合）
• 予定表の JSON の全文と、配った日時
• 店長・業務管理の担当が順番を入れ替えた記録と、その理由
• 募集人の連絡の結果（翌月に接触の記録から読む）と、予定表を見た人と日時

2つ目の対応表の版が、乗合代理店ではとくに大事です。 保険会社が書き出しの形を変えたあとに、どの月の予定表がどの版の対応表で作られたかが分からないと、 検証の結果が下がった理由を追えません。