生命保険の払込状況・住所変更・問い合わせ・経過年数から失効と解約のおそれを毎月見込み、募集人がフォローする順番と理由を出す

処理の起点を決める

毎月1日の朝6時に動かします。 前月末の口座振替の結果が収納のシステムに入り、分析用データベースへの書き出しが終わった後です。月初の朝の打合せで、営業管理の担当が一覧を開ける時刻にします。

見込む先は「今後3か月以内に、失効または解約に至るか」です。 月払の払込猶予期間は払込期月の翌月の末日までなので、1か月先だけを見込むと、一覧に載った時点で猶予期間に入っている契約が大半になります。3か月先まで見込めば、払込が止まる前に話せる契約が一覧の上に来ます。

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

月の半ばにもう一度、軽い版を動かします。 15日に、前半の口座振替不能と照会だけを足して確率を出し直し、上位に新しく入った契約だけを支社長に知らせます。 月初の1回だけでは、月の前半に出た照会が翌月の一覧まで載りません。

入力データを集める

質を決めるのは、照会の記録です。 応対記録の自由記述をそのまま使うのではなく、コールセンターが応対のたびに付けている「照会の種類」のコードを使います。 解約返戻金の照会、契約者貸付の照会、解約書類の請求。この3つのコードが付いた日付があるだけで、払込の記録に出ない解約の兆しが見えるようになります。

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

1行目を外すのが、いちばん大事な判断です。 入院の給付金を請求した後に解約が増える、という傾向はあるかもしれません。しかし、金融分野のガイドラインでは機微（センシティブ）情報の取得・利用・第三者提供を、定められた場合を除いて行わないこととしています。解約の見込みのために使うことは、その場合に当たると言える根拠がありません。

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

各システムから分析用データベースへの書き出しは、多くの保険会社ですでに月次で動いています。 この構成はそれを読むだけで、各システムに新しい接続は作りません。

口座振替の不能は、理由のコードまで取ります。 残高不足と、口座の解約・名義の相違では意味がまったく違います。後者は口座を変えたのに届けていないだけのことが多く、 連絡すれば払込方法の変更で終わります。理由のコードが無いと、モデルは両方を同じ重さで数えます。

学習用の正解には、満期・死亡による消滅を入れません。 契約が消えた理由のうち、失効と解約だけを1にします。満期を1に混ぜると、経過年数の長い契約ほど確率が上がるだけのモデルになります。

AIへ渡す前に整形する

1. 契約番号でつなぐ … 4つの書き出しを契約番号でつなぎます。つながらない記録の件数を毎月残します。 急に増えたら、どこかの書き出しの形が変わっています
2. 見込む対象を絞る … 払込が終わっている契約（払込済）、団体の契約、払済保険に変えた契約は除きます。払込の止まりようが無い契約を混ぜると、一覧の下が埋まるだけです
3. 時点をそろえる … 特徴はすべて「前月末の時点」で作ります。月末より後の記録を混ぜると、学習のときに答えを見てしまいます
4. 特徴を作る … 直近3か月・6か月の口座振替不能の回数、最後の不能からの日数、自動振替貸付の適用中か、照会の種類ごとの最後の日からの日数、住所変更からの日数、担当の交代からの日数、最後の面談からの日数、経過月数、払込期間の残りの月数
5. カテゴリの型にする … 保険の種類、払込方法、払込の経路、口座振替不能の理由のコードをカテゴリの型にします
6. 入れない列を落とす … 第7章の入力データの表で決めた4つの列を、読み込みの段階で読まないようにします。 読んでから落とすのではなく、そもそも取りません

3番目を軽く見ないでください。 学習のときに「前月末より後に解約書類を請求した」という記録が入ると、モデルは解約を正しく当てているように見えて、運用では何も当てられません。 解約の手続きの途中で付く記録は、解約の結果そのものだからです。

AIに処理させる

させるのは、契約ごとに「今後3か月以内に失効または解約に至る確率」を出すことだけです。 学習には、過去3年分の毎月末の時点の特徴と、その後3か月の結果を使います。

較正をするのは、確率を件数の見積もりに使うからです。 支社長が「今月、この支社の上位100件のうち何件が実際に失効・解約に向かうか」を知るには、0.3という確率が本当に3割前後を意味している必要があります。公式の説明では、isotonic はおよそ1,000件を超える量があれば sigmoid と同等以上とされ、少ない量では過学習しやすいとされています。12万件の契約を毎月学ぶので、量は足ります。 ただし isotonic は同じ確率の契約を生むことがあり、順番を厳密に保ちたいなら sigmoid を選びます。

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

モデルの重要度から理由を作らないのは、説明が月ごとに変わるからです。 重要度の高い特徴をそのまま理由にすると、同じ契約でも月によって理由が入れ替わり、募集人が「先月と言っていることが違う」と感じます。 事実の条件は固定なので、同じ記録には同じ文が出ます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、学習・判定・一覧の作成を決める設定を、ひとつのファイルにまとめます。モデルに「何を見て、何を見ないか」を伝えるのは、この設定です。

【見込む先】
target: 3か月以内に失効または解約（満期・死亡による消滅は 0）
as_of: 前月末
horizon_months: 3

【対象から外す契約】
- 払込済、団体の契約、払済保険・延長保険に変えた契約
- 契約日から3か月未満（記録が足りない）

【読まない列（読み込みの段階で除く）】
- 給付金・保険金の請求の履歴
- 告知の内容、査定の結果
- 性別、国籍
- 応対記録の自由記述

【モデル】
estimator: HistGradientBoostingClassifier
categorical_features: from_dtype
calibration: CalibratedClassifierCV(method="sigmoid", cv=時間順の分割)
学習期間: 直近36か月の月末時点  検証: 直近6か月の月末時点

【一覧に載せる契約】
- 確率の上位から、募集人1名あたり最大15件
- 担当がいない契約は、確率にかかわらず支社長の一覧に載せる
- 学習に無い保険の種類の契約は、確率を出さず「要確認」で載せる

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

「当てはまる条件が無い」と正直に書くのが大事です。 確率は高いのに、5つの条件のどれにも当たらない契約が出ます。そこに理由らしい文を作って埋めると、募集人は根拠の無い話を契約者にすることになります。 条件が無いと書かれていれば、募集人は「最近お変わりありませんか」から入ればよいと分かります。

募集人1名あたり最大15件で止めるのは、連絡できる数に合わせるためです。 上位を全部載せると、1人に40件届く月があり、結局いつもの順番で手を付けることになります。

出力形式を固定する

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

{
  "as_of": "2026-09-30",
  "model_version": "lapse-2026-09",
  "branch": "第3支社",
  "agent_id": "A-0215",
  "contracts": [
    {
      "policy_no": "",
      "product_type": "終身保険",
      "elapsed_months": 38,
      "probability": 0.41,
      "rank_in_agent": 1,
      "reasons": [
        "残高不足で口座振替が直近3か月に2回不能",
        "9月12日、解約返戻金の照会あり"
      ],
      "suggested_contact": "払込の相談",
      "flags": ["no_owner | unseen_product | none"]
    }
  ]
}

勧める連絡の種類も、規則で付けます。

JSON に残す理由は2つあります。 1つ目は、どの版のモデルが、どの時点の記録で、何を出したかを後から追えることです。翌月の結果と突き合わせると、上位に載せた契約のうち実際に失効・解約したのが何件か、モデルの版ごとに数えられます。2つ目は、flags で人が見るべき契約を機械的に拾えることです。

システムへ連携する

活動記録へは書き込みません。 一覧の確率を活動記録に入れると、次の月にその確率がまた特徴として読み込まれ、 モデルが自分の出した数字を学ぶことになります。結果だけを読み、確率は一覧と JSON にだけ置きます。

募集人が見られるのは、自分の担当の契約だけにします。 支社長は支社の分、営業管理の担当は営業本部の分です。一覧のシートを分けて置くのは、権限の範囲をそのまま形にするためです。

人が確認する

営業管理の担当が見るのは、次の3つだけです。

1. 担当がいない契約 … 確率にかかわらず全件。新しい担当を誰にするか、支社長と決めます
2. 学習に無い保険の種類の契約 … 新しい商品はモデルが知りません。確率を出さずに載せているので、記録を見て順番を付けます
3. 確率の上位50件 … 理由の事実が記録と合っているか、照会の日付や不能の理由を元の画面で確かめます

支社長は、一覧を配る前に順番を入れ替えてかまいません。 「この契約者は先週、募集人と会っている」と分かっていれば下げます。入れ替えたときは、理由を一覧の欄に書きます。 この欄が、モデルが知らない事情の記録になります。

目標は、1,200件をならして1件2分です。 全件を開くのではなく、上の3つに入る契約だけを開き、残りは一覧で確率と理由を流し見ます。開く件数が毎月300件を超えるなら、担当のいない契約が溜まっているか、新しい商品が増えています。

例外に対処する

5行目は、制度や景気の変化を拾うための行です。 口座振替の不能が急に増えた月は、契約者の事情ではなく、引落しの日の変更や金融機関側の事情のことがあります。分布が動いた月は、確率の高さをそのまま信じずに、上位の理由を人が読みます。

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

記録を残す

• 毎月の入力の書き出しの件数と、つながらなかった記録の件数
• モデルの版、学習に使った期間、検証の結果（上位に載せた契約のうち、実際に失効・解約した割合）
• 一覧の JSON の全文と、配った日時
• 支社長・営業管理の担当が順番を入れ替えた記録と、その理由
• 募集人の連絡の結果（翌月に活動記録から読む）
• 一覧を見た人と日時（共有の場所のアクセスの記録）

4つ目の入れ替えの記録が、モデルを直す材料になります。 同じ理由で何度も下げられる契約があれば、その事情を特徴に足せるかを考えます。ただし、機微情報に当たる事情なら足しません。

最後の行は、一覧そのものが個人データだからです。 誰がいつ見たかを残しておかないと、漏えいの疑いが出たときに範囲を確かめられません。