AI保険アンダーライティング2026 — Lemonade・Root・Hippo・Ladder・Bestow・Ethos・Policygenius 深掘りガイド

プロローグ — Lemonade IPO から5年、そして K-ICS 時代

2020年7月に Lemonade が NYSE に上場した時、ウォール街の反応は二つあった。「保険会社が SaaS の PER をもらうのは妥当か」と「これからの保険はソフトウェアだ」だ。あれから6年後の2026年、その問いは答えに近づいた。引受（underwriting）と保険金支払い（claims）のコアロジックがアルゴリズムに移った。

米国では Lemonade・Root・Hippo・Ladder・Bestow・Ethos が自分のカテゴリーを作り、Policygenius・The Zebra・Insurify・Gabi は比較マーケットプレイスとして定着した。レガシー各社も手を抜いていない。AIG・Allstate・State Farm・Geico は自社の ML プライシングエンジンを構築し、MetLife・Prudential は ML で医療引受を高速化している。

韓国では2023年に K-ICS（新支払余力制度）が本格施行され、保険会社が資産・負債を時価評価することになった。資本効率を高めるには引受の精度と速度が要となり、三星生命・教保生命・韓和生命が AI 引受を導入した。損保では KB 損害保険・現代海上が不正検知 AI を、キャロット損害保険はテレマティクスベースのパーマイル（per-mile）自動車保険を運営している。

日本はソルベンシー2との整合性を経て、日本版 ICS（Insurance Capital Standard）の導入を2025-2027年にかけて段階的に進めている。第一生命の himawari AI、日本生命の AI 引受、ライフネット生命のインターネット専用終身、SBI 損害保険の自動車保険不正検知が代表例だ。

本稿はこの地図を描く。引受（underwriting）とは何か、なぜ AI に変わったのか、どのアルゴリズムが使われ、どう検証し、どう規制されているのか。

第1章 · 伝統的アンダーライティング vs AI アンダーライティング

伝統的な引受プロセスは長かった。終身保険1件が申込から発行まで通常4-6週間かかった。引受担当者が申込書・健康診断書・所得証明・信用報告書・MIB（Medical Information Bureau）記録・処方データベース（Milliman IntelliScript）を手作業で見たからだ。

AI 引受はこの流れを二つの軸で変えた。

要はデータの広がりと鮮度だ。伝統的引受は申込時点の静的データに依存するが、AI はテレマティクス・IoT・ウェアラブルが生み出す時系列シグナルを取り込む。価格は単に精密になるだけでなく、「安全運転をすれば保険料が下がる」という行動インセンティブが価格モデルに直接組み込まれる。

第2章 · Lemonade — Maya・Jim・<3초 の保険金支払い

Lemonade は2015年にニューヨークでスタートした。柱は二つ — チャットボット引受と固定手数料 P2P モデルだ。

• Maya: 申込チャットボット。30秒で加入を終わらせるのが目標。居住地・資産価値・以前の保険歴を訊いて即時見積。
• Jim: クレームチャットボット。事故通知を受け、AI で写真・書類・陳述を検証して自動支払。最速の記録は <3초 （3秒未満）。

P2P モデルは保険料の25%を固定手数料として取り、残りでクレームを支払い、残りを慈善団体に回す（Giveback）。この構造でクレーム拒否（claim denial）のインセンティブが弱まる。

主力モデルは不正検知に集中している。AI Jim はクレーム通報動画から18個の反不正シグナルを抽出し、閾値より上なら即時支払、下なら人間の査定担当へルーティングする。

# Lemonade スタイル: クレームトリアージ意思決定モデル（概念コード）
import numpy as np
from xgboost import XGBClassifier

# 入力特徴: ユーザーシグナル + クレームテキスト/メタ + デバイス指紋
FEATURES = [
    "policy_age_days",       # 契約後日数
    "claim_amount_usd",      # 請求金額
    "prior_claims_12m",      # 過去12ヶ月の請求回数
    "device_risk_score",     # デバイス指紋のリスク度
    "geo_risk_score",        # 地域の事故発生率
    "voice_stress_score",    # 音声陳述のストレスシグナル
    "photo_metadata_anom",   # 写真 EXIF 改ざん疑い度
    "text_inconsistency",    # 陳述テキスト一貫性
]

model = XGBClassifier(
    n_estimators=600,
    max_depth=5,
    learning_rate=0.05,
    subsample=0.8,
    colsample_bytree=0.8,
    eval_metric="auc",
)

# モデル予測 → アクションルーティング
def triage(claim_features, model, auto_threshold=0.05, review_threshold=0.35):
    """auto_threshold 未満は即時支払、それ以上は人間レビュー。"""
    risk = float(model.predict_proba(np.array([claim_features]))[0][1])
    if risk < auto_threshold:
        return {"action": "auto_pay", "risk": risk}
    if risk < review_threshold:
        return {"action": "human_review", "risk": risk}
    return {"action": "siu_investigation", "risk": risk}

<3초 支払いの秘密はモデルが速いことではなく、モデルが確率分布の両端だけで意思決定を自動化することにある。グレーゾーンは常に人間に行く。

第3章 · Root — テレマティクスが価格を作る

Root Insurance（2015、オハイオ州）は最も攻めたテレマティクス事業者だ。契約前にユーザーがスマホアプリを起動し、通常2-3週間運転をすると、そのデータで価格が決まる。データが不十分か運転スコアが低ければ、引受そのものを断る。

収集されるシグナル:

• 加速・減速パターン
• コーナリング g-force
• ハンドリングのばらつき
• 夜間・深夜走行の比率
• 走行中の携帯操作（画面操作）
• 通勤距離・高速道路比率
• GPS ベースの累積走行距離

Root のモデルはこれらを driver_score（0-100）に圧縮し、地域・車種・年齢・信用といった伝統的シグナルと組み合わせて価格を作る。価格モデルは一般化加法モデル（GAM）とグラデーションブースティングのアンサンブルだ。

# Root スタイル: テレマティクス driver_score モデル（概念コード）
import lightgbm as lgb

TELEMATICS_FEATURES = [
    "hard_brake_per_100mi",
    "hard_accel_per_100mi",
    "cornering_g_p95",
    "night_driving_pct",
    "phone_usage_min_per_100mi",
    "highway_pct",
    "miles_per_week",
    "trip_count_per_week",
]

# ターゲットは6ヶ月内の損害率（loss ratio）
params = {
    "objective": "regression",
    "metric": "rmse",
    "learning_rate": 0.03,
    "num_leaves": 63,
    "feature_fraction": 0.9,
    "bagging_fraction": 0.8,
    "bagging_freq": 5,
}
booster = lgb.train(params, train_set, num_boost_round=2000)

規制面の論点は差別性だ。NAIC AI Bulletin は「Proxy discrimination」（郵便番号などの変数が人種の代理指標になること）を懸念する。Root は2024年にカリフォルニア州 DOI（Department of Insurance）と合意し、一部シグナルの重みを調整した。

第4章 · Hippo — 住宅 IoT で火災・水漏れを予防

Hippo Insurance（2015、カリフォルニア州）は住宅保険に IoT を組み合わせた。加入者に無料のスマート漏水センサー・煙感知器・ドアセンサーを送り、データを受け取って事故を事前に防ぐ。このモデルは損害を支払うより損害を予防する方が安いという直感から出発する。

主要なデータソース:

• 航空写真・衛星画像（屋根状態・樹木接近度） — Cape Analytics、ZestyAI API。
• 政府の火災・犯罪・洪水データ。
• スマートデバイスのテレメトリ（漏水検知で自動遮断バルブをトリガー）。
• 申込時の自撮りで住宅写真をアップロード → CV モデルが外観・室内状態を判断。

Hippo はこれらを HomeProtect Score に統合する。スコアが一定以下なら予防サービスがトリガーされる — 漏水センサー無料配送、屋根点検、定期点検通知。

規制面で面白いのは、gradient boosting モデルの価格決定への影響を NAIC ガイドラインに従って説明可能にしなければならないことだ。Hippo は SHAP 値を申込者に reason code として開示する。

第5章 · Ladder・Bestow・Ethos — 生命保険引受の自動化

生命保険引受の自動化は自動車・住宅より難しい。医療データの比重が大きく、補償期間が長いので、誤った引受の損失が累積する。

• Ladder（2017、カリフォルニア州）: 加入者が補償限度を自由に増減できる「はしご型」終身。引受は5分自動、一部は paramedic 面談へルーティング。
• Bestow（2016、テキサス州）: API ファーストのインフラ。他の保険会社が Bestow の引受 API を呼び出して自社ブランドで終身保険を販売できる（BaaS）。
• Ethos（2016、カリフォルニア州）: 「血液検査のない終身」を標榜。医療検査なしに医療データベース・処方薬・運転記録などで引受。

これらが共通して使うデータパイプライン:

• MIB（Medical Information Bureau）記録
• Milliman IntelliScript（処方データ）
• LexisNexis Risk Solutions（公的記録・信用）
• MVR（Motor Vehicle Records）
• 申込者の自己申告 + 識別子マッチング

-- 終身保険引受データマート — Ladder/Bestow/Ethos スタイルの結合クエリ
SELECT
  a.applicant_id,
  a.dob,
  a.gender,
  a.smoker_status,
  a.bmi,
  a.requested_coverage_usd,
  m.rx_burden_score,           -- IntelliScript 処方負担スコア
  l.public_record_flags,       -- LexisNexis 公的記録フラグ
  v.mvr_violations_24m,        -- 直近24ヶ月の運転違反
  mb.mib_alerts                -- MIB アラート
FROM applications a
LEFT JOIN intelliscript m   ON m.applicant_id = a.applicant_id
LEFT JOIN lexisnexis_pub l  ON l.applicant_id = a.applicant_id
LEFT JOIN mvr_records v     ON v.applicant_id = a.applicant_id
LEFT JOIN mib m_bureau mb   ON mb.applicant_id = a.applicant_id
WHERE a.created_at >= '2026-05-01'
  AND a.product_code = 'TERM_LIFE_20Y'

リスクモデルは一般に以下のステップで動く。

1. 申込者識別子（氏名・生年月日・SSN tail・住所）でデータソースをマッチング。
2. 欠損値処理・外れ値クリッピング。
3. 候補モデル: GBM（XGBoost/LightGBM/CatBoost）・ニューラルネット・ルールベースのガードレールのアンサンブル。
4. SHAP ベースの説明力算出。
5. 意思決定ルール: 自動承認 / 自動拒否 / paramedic 面談 / 引受人レビュー。

第6章 · Policygenius・The Zebra・Insurify — 比較マーケットプレイス

比較マーケットプレイスは自身では引受をしないが、引受意思決定の入口として重要だ。ユーザーがどの会社の見積を見るかを決める。

• Policygenius（2014、ニューヨーク州）: 終身・健康・住宅・自動車・ペット保険まで。2024年に Zinnia（Eldridge）が買収。終身マッチングが強い。
• The Zebra（2012、テキサス州）: 自動車保険比較。200社以上の保険会社の見積を統合。
• Insurify（2013、マサチューセッツ州）: AI チャットボット Evia。自動車・生命・住宅比較。
• Gabi（2017、カリフォルニア州）: 既存契約 PDF をアップロードして自動比較。2021年に Experian が買収。

マーケットプレイスは二つのアルゴリズムで動く。一つはユーザー-保険会社マッチングモデル（どの保険会社がこのユーザーに見積を出す可能性が高いか）、もう一つはランキングモデル（マッチした見積をどう並べるか）。後者はユーザーのクリック・コンバージョンデータで学習する。

規制面の核心は公正性だ。マーケットプレイスが特定保険会社を優遇して見せれば NAIC Unfair Trade Practices Act 違反となりうる。SHAP/LIME のような explainability ツールが内部監査にも使われる。

第7章 · アルゴリズムスタック — GBM、XGBoost、ニューラルネット

2026年の保険引受モデルの主力は依然としてグラデーションブースティングだ。ニューラルネットは医療画像・OCR・NLP で補助役を担う。

選択基準:

• 表形式 + 中規模データ（数十万-数億行）: GBM がほぼ常にニューラルネットより速く正確。
• 画像・テキスト・時系列の生データ: CNN・トランスフォーマーが強い。
• 説明力が重要: GLM・GAM が安全。GBM に SHAP を付けるのが次善。

第8章 · テレマティクスデータ処理

テレマティクスデータは100Hz 単位の時系列だ。1年の運転で1億行以上の生データが溜まる。保管・前処理・集計が肝心だ。

典型的なデータパイプライン:

1. 収集: スマートフォン SDK または OBD-II ドングル。Kafka へ積み込み。
2. セッション化: 始動-停止区間を trip に分割。
3. 品質フィルタ: GPS 欠損、加速度計ノイズの除去。
4. イベントラベリング: 急加速・急ブレーキ・コーナリング・停止などのラベル。
5. ウィンドウイング: 100マイル・7日・30日ウィンドウで集計。
6. 特徴ストア: Feast/Tecton に積む。学習・推論で同じ特徴。

# テレマティクス特徴パイプライン（概念的 Feast feature view）
- name: telematics_driving_features_7d
  entities: [driver_id]
  ttl: 30d
  source:
    type: kafka
    topic: telematics.events.v1
  features:
    - name: hard_brake_per_100mi
      dtype: float
    - name: hard_accel_per_100mi
      dtype: float
    - name: night_driving_pct
      dtype: float
    - name: phone_usage_min_per_100mi
      dtype: float
    - name: cornering_g_p95
      dtype: float
  online_store: redis
  offline_store: snowflake

運用上の課題はデータの鮮度だ。見積時点でユーザーの driver_score を即時反映するには、オンラインストアの latency が <100ms 以内である必要がある。韓国のキャロット損保や日本の SBI 損保も同様のアーキテクチャを運用している。

第9章 · IoT 住宅データ — Hippo、Cape Analytics

住宅 IoT データはテレマティクスより量は少ないが種類が多い。

• 漏水センサー: 1分単位の湿度・温度・圧力。
• 煙・一酸化炭素感知器: アラームイベント + 状態 ping。
• ドア・窓センサー: 開閉イベント。
• スマートロック: 施錠状態・アクセス試行。
• 航空/衛星画像: 四半期ごと。屋根・樹木・プール・構造物。

これらを全部組み合わせると、住宅リスクに対する2026年型 risk score が出る。損害率予測だけでなく、事前介入のトリガーにも使われる。Hippo はユーザーに通知を送る — 「屋根に苔が生えています。専門家点検をお勧めします」。

{
  "policy_id": "HPO-2026-998877",
  "home_risk_features": {
    "roof_age_years": 12,
    "roof_condition_score": 0.62,
    "tree_overhang_score": 0.78,
    "pool_present": true,
    "fire_zone_risk": "moderate",
    "neighborhood_burglary_index": 41,
    "leak_sensors_installed": 4,
    "smoke_detectors_active": 6
  },
  "predicted_loss_ratio_24m": 0.43,
  "premium_discount_applied_pct": 12
}

第10章 · 医療データ AI 分析 — 生命保険引受のコア

生命保険引受では医療データがモデルの精度を決める。米国では以下のデータソースが標準だ。

• MIB: 保険申請時に報告された医療情報の業界共有 DB。
• Milliman IntelliScript: 処方データ。5-7年の薬歴。
• ExamOne・LabCorp: paramedic 面談結果（血液・尿・体組成）。
• Human API・Health Gorilla: ユーザー同意のもとで EHR（電子カルテ）を取得。
• Apple Health・Google Fit: ウェアラブルデータ（任意）。

ML 観点ではEHR テキストの NLP が最も難しい。医師のノートは略語・誤字・短縮が多い。だから保険会社は BERT/clinical BERT 系を fine-tune して使う。

興味深いのは Munich Re・SCOR のような再保険会社がclinical NLP API を自社運営することだ。彼らのモデルは多くの保険会社のデータで学習されるので、単一保険会社のモデルより一般化が良い。

第11章 · 自動保険金支払い — Lemonade の <3초 の秘密

Lemonade の AI Jim が <3초 以内に支払えるのはモデルが速いからではなく、自動支払いの範囲が狭いからだ。

自動支払い条件の例:

• 請求金額が <$500/mo 水準。
• 加入後90日経過（churn-and-claim 不正対策）。
• クレーム種別が単純（破損・盗難）。
• 陳述・証拠の一貫性スコアが閾値以上。
• デバイス・地理・行動の指紋が正常分布。
• 単一証券の12ヶ月内クレーム回数 <3회 （3回未満）。

上記条件のどれかが欠ければ人間査定担当へルーティング。自動支払いの肝は速い判断ではなく、速やかに自動支払い可否を判別することだ。

# 自動クレーム支払い決定ロジック（概念コード）
from dataclasses import dataclass

@dataclass
class ClaimContext:
    amount_usd: float
    policy_age_days: int
    claim_type: str
    statement_consistency: float
    device_score: float
    geo_score: float
    behavior_score: float
    prior_claims_12m: int

def can_auto_pay(c: ClaimContext) -> bool:
    if c.amount_usd >= 500:
        return False
    if c.policy_age_days < 90:
        return False
    if c.claim_type not in ("damage_simple", "theft_simple"):
        return False
    if c.statement_consistency < 0.85:
        return False
    if c.device_score < 0.7 or c.geo_score < 0.7 or c.behavior_score < 0.7:
        return False
    if c.prior_claims_12m >= 3:
        return False
    return True

第12章 · クレーム不正検知 — KB 損保・SBI 損保のアプローチ

クレーム不正は世界の損保損害率の5-15%を占めると推定される。だから不正検知（claim fraud detection）は引受と並んで重要な ML 領域だ。

典型的な不正パターン:

• 同一車両・運転者の繰り返しクレーム（soft fraud）。
• 加入直後のクレーム（churn-and-claim）。
• 事故直後の同時多発クレーム（staged accident）。
• 医療過剰診療（provider fraud）。
• 水増しクレーム（inflated claim）。

# 不正検知: XGBoost + グラフ埋め込みの結合（概念コード）
import xgboost as xgb
import shap

FRAUD_FEATURES = [
    "policy_age_days",
    "claim_amount_usd",
    "prior_claims_12m_count",
    "claim_to_premium_ratio",
    "provider_risk_score",       # 同一医療機関/整備工場のクレーム集中度
    "ring_score",                # 加入者-整備士-診断のネットワーク埋め込み
    "device_anomaly_score",
    "geo_anomaly_score",
    "text_consistency_score",
]

dtrain = xgb.DMatrix(X_train, label=y_train, feature_names=FRAUD_FEATURES)
params = {
    "objective": "binary:logistic",
    "max_depth": 6,
    "eta": 0.05,
    "subsample": 0.8,
    "colsample_bytree": 0.8,
    "eval_metric": "auc",
    "scale_pos_weight": 30,      # ラベル不均衡
}
booster = xgb.train(params, dtrain, num_boost_round=1500)

# SHAP で reason code を算出 — NAIC AI Bulletin 対応
explainer = shap.TreeExplainer(booster)
shap_values = explainer.shap_values(X_inference)

韓国の KB 損害保険は2023年から AI 不正検知システムを運用している。損害査定・SIU（Special Investigation Unit）ワークフローに ML スコアが組み込まれ、調査官は優先度の高いケースから取り組む。日本の SBI 損保・東京海上日動・三井住友海上も同じパターンだ。

第13章 · グラフベースのリング不正検知

自動車・医療不正の相当部分は**リング（ring）**形態で起きる。同じ整備工場・医師・弁護士・運転者のネットワークが繰り返し登場する。これは表形式 ML では捕まえにくい。グラフが必要だ。

典型的なグラフスキーマ:

• ノード: 申込者、クレーム、車両、整備工場、医師、弁護士、保険外交員。
• エッジ: 「申込者—クレーム」、「車両—事故」、「整備工場—修理」、「医師—診断」、「弁護士—代理」。

ここにノード埋め込み（Node2Vec、GraphSAGE、GAT）を適用し、各申込者・整備工場のリスク埋め込みを作る。埋め込みが他のシグナルと結合して不正スコアに入る。

# Node2Vec ベースの ring score（概念コード）
from node2vec import Node2Vec
import networkx as nx

# G: 申込者-クレーム-整備工場-医師-弁護士など多重エッジグラフ
n2v = Node2Vec(G, dimensions=64, walk_length=30, num_walks=200, p=1.0, q=0.5)
model = n2v.fit(window=10, min_count=1, batch_words=4)

# 申込者ごとの埋め込み → 他モデルの特徴として使用
def get_ring_embedding(node_id):
    return model.wv[str(node_id)]

NAIC AI Bulletin の観点では、このモデルの使用にも explainability 義務が課される — 埋め込み次元だけでは reason code にならない。だからグラフベースのスコアを使う時は「この申込者は整備工場 X と12件のクレームを共有」のような自然言語 reason を併せて出力する。

第14章 · NAIC AI Bulletin — 米国保険規制の標準

NAIC（National Association of Insurance Commissioners）は2023年12月に Model Bulletin on the Use of Artificial Intelligence Systems by Insurers を発表した。2026年現在、ほぼ全ての州が採用または採用中だ。

主な義務:

1. AI システムガバナンスプログラム（AISGP）: 取締役会・経営層レベルのガバナンス明文化。
2. データ・モデルリスク評価: データ出所、バイアス、精度、安定性。
3. ベンダーガバナンス: 外部ベンダー AI 使用時も保険会社の責任。
4. テスト・検証・モニタリング: ローンチ前検証と運用中モニタリング。
5. 消費者保護: reason code 提供、人間レビュー経路。
6. 記録保管: モデル決定履歴を追跡可能に。

# NAIC AI Bulletin 要件マッピング（概念 yaml）
ai_system: claim_triage_v3
deployment_state: production
governance:
  owner: chief_risk_officer
  review_cycle_days: 90
  board_review_required: true
risk_assessment:
  data_sources:
    - claim_intake_form
    - device_telemetry
    - third_party_geo_risk
  bias_metrics:
    - demographic_parity
    - equal_opportunity
  fairness_threshold: 0.05
testing:
  backtest_window_months: 12
  shadow_test_required: true
  champion_challenger_required: true
monitoring:
  drift_alert_psi_threshold: 0.2
  performance_alert_auc_drop: 0.03
consumer:
  reason_code_required: true
  adverse_action_letter_template: AAL-2026-V2
  human_review_path: /claims/escalate
records_retention_years: 7

NAIC Bulletin は EU AI Act より軽いが、実効性は強い — 州の保険庁が即時に検査・課徴金が可能だ。2025年にカリフォルニア・コネチカット・ニューヨークが最初の検査ラウンドを実施した。

第15章 · EU AI Act — 保険引受は high-risk

EU AI Act は2024年に発効、2026年に本格適用中だ。保険引受への直接的意味は二つのカテゴリーにある。

• High-risk AI: 生命・健康保険引受、価格設定。Annex III に明記。
• Limited risk: チャットボット・カスタマーサポート。透明性義務のみ。

High-risk AI の義務:

• Risk management system（Article 9）
• Data governance（Article 10）: 学習・検証データの品質、バイアス検討。
• Technical documentation（Article 11）
• Record-keeping（Article 12）: ログ保存。
• Transparency（Article 13）: ユーザーへの AI 使用告知。
• Human oversight（Article 14）: 最終決定権限。
• Accuracy, robustness, cybersecurity（Article 15）
• Quality management system（Article 17）
• CE marking & registration（Article 49, 60）

罰金は売上の7% または €35M のうち大きい方。保険会社にとってこれはクラスアクション規模のリスクだ。

EIOPA（European Insurance and Occupational Pensions Authority）は2025年に保険特化ガイドラインを発表した。韓国の金融監督院と日本の金融庁はこれを参照して自国ガイドラインを運用する。

第16章 · explainability — SHAP・LIME・カウンターファクチュアル

NAIC と EU AI Act が共通して要求するのが説明力だ。2026年の保険 ML スタックは SHAP がデフォルトで、LIME とカウンターファクチュアルが補助だ。

• SHAP（SHapley Additive exPlanations）: モデル出力を特徴別寄与度に分解。グローバル・ローカル両方可能。TreeSHAP は GBM で正確。
• LIME（Local Interpretable Model-agnostic Explanations）: 任意のモデル周辺にローカル線形モデルを当てはめる。モデル非依存。
• カウンターファクチュアル: 「どの特徴がどう変われば決定が変わるか」を提示。DiCE・Wachter など。

実務では SHAP 値を reason code に変換するマッピングテーブルを運用する。

# SHAP → 自然言語 reason code マッピング（概念コード）
REASON_CODES = {
    "claim_amount_usd": "請求金額が平均比で上位分位に該当します。",
    "policy_age_days": "保険加入後の経過期間が短いです。",
    "prior_claims_12m_count": "直近12ヶ月の請求回数が多いです。",
    "provider_risk_score": "関連する医療機関/整備工場の請求頻度が高いです。",
    "ring_score": "ネットワーク分析上、多数の請求が結びついています。",
}

def shap_to_reason_codes(shap_values, feature_names, top_k=3):
    pairs = sorted(zip(feature_names, shap_values), key=lambda p: -abs(p[1]))
    codes = []
    for name, val in pairs[:top_k]:
        reason = REASON_CODES.get(name, name)
        codes.append({"feature": name, "shap": float(val), "reason": reason})
    return codes

消費者には SHAP 値そのものではなく自然言語 reason 3-5個を見せる。これは米国 Fair Credit Reporting Act（FCRA）の adverse action notice 要求とも整合する。

第17章 · モデルモニタリングと drift

モデルがリリースされたらモニタリングが必要だ。データ分布が変われば精度が落ち、それが損害率悪化や差別シグナルにつながる。

2026年の標準運用指標:

• PSI（Population Stability Index）: 学習時点と運用時点の特徴分布差。
• CSI（Characteristic Stability Index）: モデル出力分布の変化。
• Performance metrics: AUC、KS、calibration。
• Fairness metrics: demographic parity、equal opportunity、group calibration。
• Volume: クレーム/見積件数、拒否率。

これを Evidently AI・Arize・Fiddler・WhyLabs のような ML observability ツールで見る。韓国では三星 SDS の BrightICS、日本では自社構築が多い。

アラームルールの例:

第18章 · 再保険会社と AI risk-sharing — Munich Re・Swiss Re・SCOR

再保険会社は保険会社の保険会社だ。大きな損害を分担し、資本負担を分散させる。2026年の新しい流れは再保険会社が AI モデル自体を分担することだ。

• Munich Re: aiSure — モデルの損失に対して再保険カバレッジを提供。AI モデルが予測失敗で損失を出した時その損失をカバー。
• Swiss Re: Magnum — デジタル引受プラットフォーム。保険会社が呼び出して終身引受の意思決定を得る。
• SCOR: Velogica・SCOR Velogica — Magnum と類似の引受自動化。

再保険会社はグローバルなデータを保有しているので学習データが大きい。単一保険会社のモデルより一般化がよく、特に新興保険会社は自社データが不足するので再保険会社の引受モデルをそのまま使うケースが多い。

規制面では Munich Re の aiSure は NAIC Bulletin・EU AI Act のベンダーガバナンス義務を多少緩和する効果がある。保険会社が自社検証 + 再保険会社カバレッジを組み合わせればリスクが分散する。

第19章 · K-ICS と韓国の AI 引受 — 三星生命・教保・韓和・KB 損保・現代海上

韓国の新支払余力制度 K-ICS は2023年1月に施行された。保険会社の資産・負債を時価評価して RBC（Risk-Based Capital）比率を算出する。

K-ICS RBC 比率の中心式（概念）:

RBC ratio = (資本 - 保有リスク) / (要求資本)

保有リスクは保険・市場・信用・運営・集中リスクをシミュレーションで結合する。AI 引受の精度が落ちれば保険リスクが大きくなり要求資本が大きくなる。

代表事例:

• 三星生命: AI 引受システム（社名は非公開）を導入。paramedic なしの自動引受比率を拡大。
• 教保生命: 医療データベースの引受自動化。
• 韓和生命: 申込チャネルのデジタル化 + 引受自動化。
• KB 損害保険: AI 不正検知（自社運用）+ 自動車保険損害査定自動化。
• 現代海上: 車両損害評価 AI（車両写真で損傷見積）。
• DB 損害保険: テレマティクス自動車保険運用。
• 三星火災: ダイレクトチャネルの AI 価格決定運用。
• キャロット損害保険: 韓和・SK が合弁。パーマイル（Per-Mile）自動車保険。テレマティクス標準。

金融監督院は2024年に「金融分野 AI ガイドライン」を発表した。保険会社は AI 引受システムについて影響評価・記録保管・消費者保護義務が課される。

# 韓国金融監督院 AI ガイドラインマッピング（概念）
financial_ai_system: life_underwriting_v2
target_business: 生命保険_自動審査
impact_assessment:
  consumer_impact: high
  fairness_check_required: true
governance:
  model_governance_committee: true
  review_cycle_days: 180
records:
  retention_years: 5
consumer:
  algorithm_explainability_required: true
  human_review_path_url: https://example.kr/underwriting/escalate
incident_reporting:
  to_fss_within_days: 5

第20章 · 日本の AI 引受 — 第一生命・日本生命・ライフネット・SBI

日本は保守的だが人口減少・高齢化で保険市場が変化している。AI 引受の導入は米国・韓国より一拍遅いが確実に進行中だ。

代表事例:

• 第一生命: himawari AI — 保険金請求の写真分析で自動支払いを一部導入。paramedic なしの終身引受拡大。
• 日本生命: 自社 AI 引受を運用。NTT データと協業。
• 明治安田生命: グループ終身・年金の ML 価格決定。
• 住友生命: 健康増進型保険 Vitality（南アフリカ Discovery と協業）— ウェアラブルデータを価格に反映。
• ライフネット生命: インターネット専用。申込5分、引受が速い。
• SBI 損害保険: 自動車保険の不正検知 AI。
• 東京海上日動: クレーム自動化・企業保険 AI。
• 三井住友海上（MS&AD）: 車両損害査定 AI。

日本の金融庁は2025年に「保険 AI ガバナンスガイドライン」を発表した。EIOPA と NAIC を参照して作られ、日本版 ICS 導入スケジュールと連動して段階導入中だ。

日本版 ICS は IAIS（国際保険監督者協議会）の ICS 2.0 を土台に、日本の市場構造に合わせた資本規制だ。2025-2027年に施行、2030年に本格適用予定。K-ICS と同様、保険会社の引受精度が資本負担に直接影響する。

第21章 · 差別・バイアス — proxy discrimination の罠

AI 引受の最大の規制論点は差別だ。NAIC、EU AI Act、韓国金融監督院、日本金融庁の全てが懸念する部分だ。

主要概念:

• Disparate treatment: 明示的に保護属性（人種・性別・宗教など）を使用。ほぼ常に違法。
• Disparate impact: 明示的には使っていないが、結果的に保護グループに不利な影響。米国では ECOA・Fair Housing Act などが適用。
• Proxy discrimination: 保護属性と強く相関する変数（郵便番号・苗字パターン・車種）を使って事実上の差別。NAIC AI Bulletin の中心的懸念。

検証方法:

# バイアス検証 — demographic parity / equal opportunity の点検
import pandas as pd

def fairness_report(df, score_col, label_col, group_col, threshold=0.5):
    df = df.copy()
    df["pred"] = (df[score_col] >= threshold).astype(int)
    out = []
    for g, sub in df.groupby(group_col):
        pos_rate = sub["pred"].mean()
        tpr = ((sub["pred"] == 1) & (sub[label_col] == 1)).sum() / max(
            (sub[label_col] == 1).sum(), 1
        )
        fpr = ((sub["pred"] == 1) & (sub[label_col] == 0)).sum() / max(
            (sub[label_col] == 0).sum(), 1
        )
        out.append({"group": g, "pos_rate": pos_rate, "tpr": tpr, "fpr": fpr})
    return pd.DataFrame(out)

実務では学習データから保護属性を直接外すのが目的ではなく、認識して検証することが先だ。その後、郵便番号のような強い proxy を除去するか重みを調整する。

第22章 · 価格差別 vs 価格個別化 — どこまでが合法か

保険価格はリスクに基づく差別が合法だ。その差別が保護属性と無関係である限りにおいて。だから次のような流れが標準になった。

EU の Test-Achats 判決は2012年に性別差別を保険価格に使えなくした。その結果、EU の自動車・生命・健康保険は性別無関係の価格が標準だ。米国は州ごとに異なる。

第23章 · 総合比較 — US/EU/KR/JP 規制マトリクス

第24章 · 運用チェックリスト — 新しい AI 引受モデルをローンチする前に

最後に実務チェックリスト。

1. データ出所文書化: 全ての学習・検証データの出所・ライセンス・同意記録。
2. バイアス検討: demographic parity、equal opportunity、group calibration。
3. proxy 点検: 郵便番号・車種・職業など強い proxy の SHAP 影響度測定。
4. 説明力: SHAP ベース reason code 5個以上。
5. 人間レビュー経路: 拒否・高リスクケースのエスカレーションワークフロー。
6. チャンピオン/チャレンジャー: 新モデルはトラフィックの5-10%から開始。
7. PSI/AUC モニタリング: データ・性能 drift アラート。
8. 再学習サイクル: 四半期・半年単位。
9. ベンダーガバナンス: 外部モデル使用時の SLA・テスト結果記録。
10. 事故対応: モデルが誤った決定をした時の還付・補償・再処理 SOP。
11. ログ保管: 決定の入力・出力・モデルバージョンを追跡可能に保存。
12. 消費者告知: AI 使用の事実・異議申立経路を明示。
13. 規制報告: NAIC/EIOPA/FSS/FSA 報告書式・周期。
14. 資本影響: K-ICS・日本版 ICS・Solvency II 資本負担シミュレーション。

この14項目が2026年の標準だ。何よりも重要なのは、AI 引受の効率性と責任性が同じ重みを持つことだ。速い見積と自動支払いが可能になった分、誤った決定の社会的コストも一緒に大きくなった。Lemonade の <3초 支払いはマーケティングコピーだが、その裏には14個のガードレールがある。

References

• Lemonade — https://www.lemonade.com/
• Root Insurance — https://www.root.com/
• Hippo — https://www.hippo.com/
• Ladder — https://www.ladderlife.com/
• Bestow — https://www.bestow.com/
• Ethos — https://www.ethoslife.com/
• Policygenius — https://www.policygenius.com/
• The Zebra — https://www.thezebra.com/
• Insurify — https://insurify.com/
• NAIC AI Model Bulletin — https://content.naic.org/sites/default/files/inline-files/2023-12-4%20Model%20Bulletin_Adopted_0.pdf
• NAIC Home — https://www.naic.org/
• EIOPA — https://www.eiopa.europa.eu/
• EU AI Act — https://artificialintelligenceact.eu/
• Munich Re aiSure — https://www.munichre.com/
• Swiss Re Magnum — https://www.swissre.com/
• SCOR Velogica — https://www.scor.com/
• 損害保険協会（KGIA） — https://www.kgia.or.kr/
• 韓国生命保険協会（KLIA） — https://www.klia.or.kr/
• 日本生命保険協会 — https://www.seiho.or.jp/
• 第一生命 — https://www.dai-ichi-life.co.jp/
• ライフネット生命 — https://www.lifenet-seimei.co.jp/
• SHAP（SHapley Additive exPlanations） — https://shap.readthedocs.io/
• LIME — https://github.com/marcotcr/lime
• Cape Analytics — https://capeanalytics.com/
• ZestyAI — https://zesty.ai/