自動車保険の保険金請求のデータから不正請求の疑いの度合いを見込み、調査に回す順番と疑いの理由を損害調査の担当に出す

処理の起点を決める

毎朝7時に、前日までに受け付けた請求を対象に動かします。 受付のたびに1件ずつ動かす形にはしません。請求どうしのつながりは、その日に受け付けた他の請求も含めて数えないと拾えないためです。同じ日に同じ口座の請求が2件入ってきた、という型は、1件ずつでは見えません。

朝に一覧を出すのは、主任がその日の調査の割り振りを決める前に間に合わせるためです。 特別調査の担当が1日に動ける件数は限られているので、どの請求から手を付けるかを朝のうちに決められることが大事です。

学び直しは別に動かします。月に1回、調査の結果が確定した請求を足して作り直します。 調査は数週間から数か月かかるため、結果がまだ出ていない請求を正解にも不正解にも入れないことが、学び直しの条件です。

入力データを集める

質を決めるのは、いちばん下の行です。 どの請求が調査で不正と判明したかの記録が無いと、モデルは何を学べばよいかが分かりません。スプレッドシートの調査の記録を、請求番号でつなげられる形に直すのが最初の作業です。

入れない項目も決めておきます。 契約者の国籍、性別、年齢は特徴量に入れません。これらで度合いが上がると、属性で人を疑う仕組みになります。 事故の事実と請求のしかたに関わる値だけを使います。

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

各システムから、前日までに受け付けた請求と、つながりを数えるための過去3年分の請求を書き出します。過去分は毎日全件を引き直さず、前日までの数え上げの結果に新しい請求を足す形にします。

電話番号と口座の番号は、そのままの形で比べません。 ハイフンや全角・半角の違いをそろえたうえで、照合用の値に置き換えてから数えます。 数え上げの処理と一覧には、元の番号を出しません。

AIへ渡す前に整形する

1. 表記をそろえる … 電話番号・口座番号・住所・修理工場の名前の書き方を統一します。修理工場は名前の表記ゆれが多いため、工場の登録番号で引きます
2. 照合用の値に置き換える … 電話番号・口座・住所を、元に戻せない照合用の値にします
3. つながりを数える … 照合用の値ごとに、過去3年の他の請求に出てくる数を数えます。同じ契約者の請求どうしは数えません
4. 特徴量を作る … 契約の始期から事故までの日数、事故から届出までの日数、補償の変更から事故までの日数、深夜の事故か、車両保険の金額と時価の差、過去3年の請求の回数、見積額、修理工場、事故の型
5. 欠けた値を残す … 相手の無い事故では相手方の車両番号は欠けたまま渡します
6. 学習の正解を決める … 調査で不正と判明したものを1、調査して問題が無かったものと、調査せずに支払って1年たったものを0とし、結果が確定していないものは学習から外します

3番目の「同じ契約者の請求どうしは数えない」を忘れないでください。 同じ人が同じ電話番号で2回請求するのは当たり前で、それを数えると、事故の多い普通の契約者が上位に並びます。 見たいのは、別々の契約者のはずの請求に、同じ連絡先や口座が出てくることです。

6番目の「調査せずに支払ったものを0とする」は、割り切りです。 その中に見逃した不正が混ざっていることは避けられません。第5章の抽出確認で、その混ざり方を少しずつ確かめます。

AIに処理させる

させるのは、請求ごとの疑いの度合いと、要因ごとの寄与を出すことだけです。 調査に回すか、何を調べるかは、主任と特別調査の担当が決めます。

理由を上位3つまでにしているのは、主任が1行で読める数だからです。 要因を10個並べると、どれが効いているのかを主任が読み解く時間がかかり、理由を付けた意味が薄れます。 4つ目以降の寄与は記録には残し、一覧には出しません。

度合いは、確率としては読みません。 正解の0には見逃した不正が混ざっており、1は調査に回った請求の中からしか出てこないためです。「上から何番目か」として使い、一覧の上位何件を主任が見るかで運用します。

理由文は、要因ごとに言い回しを決めておきます。

指示内容を固定する

この構成でAIに与える指示は、文章のプロンプトではなく学習と予測の設定です。

import lightgbm as lgb

FEATURES = [
    "days_policy_start_to_loss",      # 契約の始期から事故まで
    "days_coverage_change_to_loss",   # 補償の変更から事故まで（変更が無ければ欠けたまま）
    "days_loss_to_report",            # 事故から届出まで
    "is_night", "loss_type", "repair_shop_id",   # 区分の値は category 型にしておく
    "vehicle_sum_insured_minus_value",
    "claims_3y_same_policyholder",
    "shared_phone_other_holders", "shared_account_other_holders",
    "shared_address_other_holders", "shared_counterparty_other_holders",
    "estimate_amount",
]
# 入れないもの：国籍、性別、年齢

model = lgb.LGBMClassifier(
    n_estimators=400,
    learning_rate=0.03,
    num_leaves=31,
    is_unbalance=True,       # 不正と判明した請求はごく一部
    random_state=0,
)

# 学習から外すもの：調査の結果が確定していない請求
train = claims[claims["label_status"] == "settled"]
model.fit(train[FEATURES], train["label"], categorical_feature="auto")

score = model.predict_proba(today[FEATURES])[:, 1]
contrib = model.predict(today[FEATURES], pred_contrib=True)   # 最後の列は期待値
reasons = top_positive(contrib[:, :-1], FEATURES, k=3)        # 押し上げた要因の上位3つ

「入れないもの」をコードの中に書いておくのは、後から足されないためです。 学び直しの担当が替わったときに、「年齢を入れたら精度が上がった」という理由で足されることがあります。精度が上がっても、属性で人を疑う仕組みになるなら入れません。

top_positive は、寄与が正のものだけを取り出す関数です。 寄与が負の要因は度合いを下げたもので、理由としては出しません。理由が3つ未満しか無い請求は、そのまま少ない数で出します。 無理に3つにそろえると、ほとんど効いていない要因が理由として並びます。

評価は、時期で分けて行います。直近の数か月を検証用に取っておき、学習に使いません。 不正の手口は時期で変わるので、ばらばらに分けた評価は実際より良く見えます。見る値は、上位何件に、調査で不正と判明した請求がいくつ入ったかです。

出力形式を固定する

請求1件ごとに、次の形で一覧に書き出します。

{
  "claim_no": "",
  "received_date": "2026-10-06",
  "score": 0.0,
  "rank": 1,
  "reasons": [
    { "feature": "shared_account_other_holders", "value": 2, "text": "同じ振込先の口座が、別の契約者の請求 2 件に出てくる" },
    { "feature": "days_policy_start_to_loss", "value": 9, "text": "契約の始期から事故まで 9 日" }
  ],
  "random_audit": false,
  "linked_claims": ["", ""],
  "model_version": "2026-09"
}

1つ目の理由は、reasons に要因の名前と値と文を分けて持つことです。 主任は text を読み、学び直しの担当は feature で集計します。どの要因で調査に回った請求が多く、そのうちどれだけが不正だったかを後から数えられます。

2つ目は、linked_claims で、つながった請求の番号を並べることです。 口座が重なっている別の請求がどれかが分かれば、調査の担当はその請求の記録から見始められます。 番号だけを出し、相手の契約者の氏名は一覧に出しません。

3つ目は、random_audit を度合いと別に持つことです。 抽出確認の請求は度合いが低くても一覧に載り、主任は「なぜこれが載っているのか」を印で区別できます。

システムへ連携する

度合いを、事故受付・調査システムの画面に表示しません。 受付の担当者が請求者と話す前に度合いを見ると、質問の仕方や声の調子に表れます。 一覧を見るのは主任と特別調査の担当だけにします。

主任への通知のメールには、請求の中身を書きません。 書くのは「今朝の一覧ができた」ことと件数、一覧の置き場所だけです。メールは転送や誤送信で広がりやすく、度合いと理由を本文に載せると、見せる範囲を絞った意味がなくなります。 一覧そのものは、主任と特別調査の担当だけが開ける場所に置きます。

人が確認する

主任が見るのは、一覧の上位と抽出確認の請求です。 2,400件をすべて開く必要はなく、上位を理由と一緒に読み、調査に回すかを決めます。

1. 理由を読む … どの要因で度合いが上がっているかを見ます
2. 事実で確かめる … 理由に挙がった値が、請求の記録と合っているかを画面で確かめます
3. 調査に回すかを決める … 回すものは依頼書を書き、回さないものには短い理由を選択肢から選びます
4. 抽出確認の請求を回す … 度合いが低くても、決めた割合だけは調査します

目標は2,400件をならして1件1分です。 主任が詳しく見るのは毎朝の上位の十数件と抽出確認の数件で、残りは度合いと理由の1行を流し見て、支払の手続きに任せます。 上位を何件まで見るかは、特別調査の担当がその週に受けられる件数から逆算して決めます。

2番目を省かないでください。 電話番号の重なりが、代理店の代表番号や修理工場の番号だったということがあります。重なりの数は事実でも、疑う理由にはならない重なりです。 気づいたものは、次から数えない番号の一覧に足します。

支払の手続きは止めません。 保険法では、保険給付の期限について、保険事故や損害額などの確認をするための相当の期間という考え方が置かれています。調査が要ると判断したときに、その期間の中で事実を確かめます。 度合いが高いことだけを理由に、支払を寝かせる運用にしません。

例外に対処する

上の2行が最も多く起きます。 どちらもモデルの問題ではなく、数え上げの材料の問題です。 運用の最初の数か月で、数えない番号の一覧が育ちます。

下から2行目も見落としやすい型です。 1つの事故で車両と対物の請求が別の番号で入ると、同じ契約者・同じ口座の請求が2件あるように見えます。前処理の「同じ契約者を数えない」に加えて、同じ事故番号どうしも数えないようにしておきます。

記録を残す

• 毎朝の書き出しの件数と、請求ごとの度合い・寄与・理由
• 主任が調査に回したか、回さなかった理由
• 抽出確認に選ばれた請求と、その調査の結果
• 特別調査の結果と確定日
• モデルの版（学習の期間、特徴量、入れなかった項目、重みの設定）と、検証期間での上位の当たり方
• 数えない番号の一覧の変更の履歴

2つ目の「回さなかった理由」が、学び直しで最も効く記録です。 上位にあっても回さなかった請求の理由がたまると、モデルが的外れに上げている要因が見えてきます。

度合いと理由は、調査が終わった後も消しません。 請求者から苦情や照会があったときに、その朝の一覧で何位だったか、どの理由が並んでいたか、主任が何を見て調査に回したかを示せるようにしておきます。度合いを残しておくことは、度合いだけで判断していないことの裏付けにもなります。