損害保険の引受審査で、新しい申込に職業・既往歴・物件の条件が近い過去の引受判断を探し、当時の判断と付けた条件を根拠付きで返す

処理の起点を決める

引受担当が審査の画面で「前例を探す」を押したことを起点にします。 引受基準の表で決まらなかった申込に、画面がボタンを出します。基準で決まる申込にまで前例を出すと、基準より前例を先に読む癖が付くので、出す場面を絞ります。

索引の更新は、判断の決裁のたびに行います。 決裁された判断の結論と判断メモを、その日のうちに索引に入れます。

改定の表の更新は、引受基準の改定のたびに人が行います。 改定の情報を、改定された商品・項目・施行の日として表に足します。 この表が古いと、第5章の4番目の印が付かなくなります。

入力データを集める

質を決めるのは、判断メモから項目を取り出せるかです。 年齢・築年数・保険金額が文章に埋もれたままでは、近さの点が付けられません。取り込みの段で項目に分け、取り出せなかった項目は空にして「不明」の印を付けます。 空の項目を推し量って埋めると、近さの点が根拠の無い値で付きます。

2つの読み替えの表は、絞り込みのためのものです。 判断メモの「調理師」「板前」「料理人」を同じ分類の番号にそろえ、分類の番号で絞れるようにします。

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

判断1件を、索引の1件にします。 項目は数値（年齢、築年数、保険金額、治療を終えてからの年数）、キーワード（商品、分類の番号、構造、判断、基準の版、見られる担当の区分）、文章（判断メモ、付けた条件）に分けて持たせます。

検索の要求は、おおよそ次の形です。

{
  "size": 10,
  "query": {
    "function_score": {
      "query": { "bool": {
        "filter": [
          { "term": { "product": "income_protection" } },
          { "term": { "occupation_class": "C-12" } }
        ],
        "should": [ { "terms": { "condition_class": ["M-208"] } } ]
      } },
      "functions": [
        { "filter": { "exists": { "field": "age" } },
          "gauss": { "age": { "origin": 52, "offset": 2, "scale": 5 } } },
        { "filter": { "exists": { "field": "sum_insured" } },
          "gauss": { "sum_insured": { "origin": 300000, "offset": 30000, "scale": 100000 } } },
        { "filter": { "bool": { "must_not": { "exists": { "field": "age" } } } },
          "weight": 0.3 },
        { "filter": { "bool": { "must_not": { "exists": { "field": "sum_insured" } } } },
          "weight": 0.3 }
      ],
      "score_mode": "multiply",
      "boost_mode": "multiply"
    }
  }
}

下の2つの weight が、値の無い記録の減点です。 公式のドキュメントでは、score_mode の既定は multiply で、関数の点を掛け合わせて最終の点にします。年齢が無い記録は年齢の点が1になる代わりに、0.3を掛けられて下がります。火災保険では、age の代わりに building_age と structure で同じ形を作ります。

治療を終えてからの年数も、同じ形で点を付けます。 今回の申込が治療を終えて3年なら、origin を3、offset を1にして、2〜4年の前例を同じ点で並べ、離れるほど点を下げます。 年数の違いが判断を分けることが多い項目なので、scale は年齢より小さくします。

絞り込みは filter に置き、点に混ぜません。 公式のドキュメントでは、function_score はどの文書を返すかではなく、並び順を変えるものとされ、トップの query を省くと全件が点1で対象になるとされています。商品と職業の分類は、必ず bool の filter で絞ってから近さの点を付けます。

見られる記録は、文書レベルのセキュリティで決めます。 役割（ロール）ごとに、見てよい文書の条件を検索の形で書きます。

PUT _plugins/_security/api/roles/uw_medical
{
  "index_permissions": [{
    "index_patterns": ["uw-precedents*"],
    "dls": "{\"terms\": {\"visible_to\": [\"general\", \"medical\"]}}",
    "allowed_actions": ["read"]
  }]
}

visible_to はキーワードの項目にします。 公式のドキュメントでは、文章の項目に記号を含む値があると、標準の分析器が値を分けて索引にするため、意図しない絞り込みになりうるとされ、キーワードの項目にする方法が示されています。

AIへ渡す前に整形する

1. 判断メモを項目に分ける … 取り込みの段で、判断メモから年齢・築年数・保険金額・付けた条件を取り出します。取り出せない項目は空にし、「不明」の印を付けます
2. 職業と既往歴を分類の番号にそろえる … 読み替えの表を当て、番号を項目に持たせます。表に無い名前は「未分類」にします
3. 当時の引受基準の版を割り当てる … 版が書かれていない判断は、決裁の日から版を割り当て、「推定」の印を付けます
4. 見られる担当の区分を付ける … 既往歴を含む判断には medical、含まないものには general を付けます
5. 個人を特定する項目を外す … 申込者の氏名・住所・連絡先・証券の番号は索引に入れません。判断の番号から審査の仕組みの記録をたどれるだけにします

5番目を軽く見ないでください。 前例の検索に要るのは条件と判断で、誰の申込だったかは要りません。 索引に氏名があると、前例を探すたびに他人の健康の情報を名前付きで読むことになります。

AIに処理させる

探すのと点を付けるのは検索基盤、改定の印は改定の表から規則で付けます。生成AIには、上位の判断の判断メモを読ませ、引受担当が読み比べられる形にまとめさせます。

させないことの1行目が、この構成でいちばん大事な線引きです。 上位の前例がすべて「保険料の割増で引受」なら、生成AIは「同様の条件で引受可能と考えられます」と書きたくなります。 それを読めば、引受基準に照らす手順を飛ばして前例の結論を写すことになります。

させることの4行目は、第3章の（b）への手当てです。 同じ職業で年齢の違う2件が、一方は引受、一方は謝絶なら、その分かれ目の理由が判断メモに書かれているはずです。 結論をそろえて見せるのではなく、分かれた理由を並べます。

指示内容を固定する

あなたは損害保険会社の引受審査の担当に、過去の引受判断を
示す立場です。渡した検索結果（過去の判断）だけを根拠にしてください。

【今回の申込】商品 {product}、職業の分類 {occupation_class}、
  年齢 {age}、既往歴の分類 {condition_class}、
  治療を終えてからの年数 {years_since}、物件 {property}、保険金額 {sum_insured}
【過去の判断】検索結果として渡します。各結果のタイトルには
  判断の番号、当時の基準の版、改定の印、近さの点の内訳が付いています。

【やること】
1. 判断ごとに、判断（引受・条件付き・謝絶）と付けた条件を書く
2. 判断ごとに、判断を分けた理由を判断メモから書く
3. 今回の申込と値が違う項目を書く
4. 似た条件で判断が分かれている前例があれば、どの項目の
   違いで分かれたと判断メモに書かれているかを書く

【厳守事項】
- 今回の申込を引き受けられるか、どの条件を付けるべきかを
  書かないでください。「同様に」「準じて」とも書かないでください。
- 前例の判断は、前例の判断としてだけ書いてください。
- 改定の印が付いた判断は、最初に「判断の後に基準の改定あり」と書いてください。
- 判断メモに無い値を推測で埋めないでください。
  無いものは「記載なし」と書いてください。
- 既往歴の病状や予後について説明しないでください。

「同様に」「準じて」を禁じないと、ほぼ必ず書きます。 上位の前例の結論がそろっていると、それを今回に当てはめる文章がいちばん自然だからです。結論を写す道を、言葉の段階で塞ぎます。

出力形式を固定する

過去の判断は、search_result のブロックとして渡します。 公式のドキュメントでは、search_result は source、title、content（テキストのブロックの配列）を持ち、引用を有効にすると、回答の文章に、どの検索結果のどのブロックを引いたかが search_result_location として付いて返るとされています。判断メモを「判断」「付けた条件」「理由」のブロックに分けて渡し、どの記述を根拠にしたかをブロックの番号で受け取ります。

Lambda は、返ってきた文章と引用を、次の形のJSONに組み直して画面に流し込みます。

{
  "application_id": "",
  "precedents": [
    {
      "decision_id": "UW-2023-04811",
      "rule_version": "2023-04",
      "version_estimated": false,
      "amended_after": true,
      "score_breakdown": { "age": 0.92, "sum_insured": 0.81, "missing_penalty": 1.0 },
      "decision": "条件付き",
      "conditions": ["保険料の割増"],
      "differences": [{ "item": "年齢", "this": "52", "precedent": "49" }],
      "citations": [{ "search_result_index": 0, "start_block_index": 2, "end_block_index": 2 }]
    }
  ],
  "split_decisions": [""]
}

1つ目の理由は、score_breakdown で近さの内訳を見せられることです。 公式のドキュメントでは、explain を有効にすると、点の計算の内訳を確かめられるとされています。どの項目が近くて上位に来たのか、値が無くて減点されたのかを、画面で読めるようにします。

2つ目は、amended_after を結論より前に出せることです。 改定の後の判断と前の判断を、見出しの段階で色を分けます。

3つ目は、citations で判断メモの該当の記述を開けることです。 生成AIのまとめだけで読まず、理由の原文を開いて確かめるためです。

システムへ連携する

審査の仕組みの判断には書き込みません。 今回の判断は、これまでどおり引受担当が審査の仕組みに入力し、決裁を受けます。前例の画面から判断を入力できる作りにすると、前例の結論をそのまま選ぶ判断が増えます。

営業店と代理店には、この画面を開きません。 前例の検索は引受担当の道具で、「前に通った事案があります」と募集の場で言える形にはしません。

人が確認する

引受担当が前例を読み、今回の判断は引受基準に照らして担当が行い、権限に応じて決裁を受けます。

1. 改定の印を見る … 改定の後の判断を先に読み、改定の前の判断はその項目が今の基準でどう扱われるかを確かめる前提で読みます
2. 近さの内訳を見る … 値が無くて減点された前例は、判断メモを開いて条件を確かめます
3. 判断の分かれ目を読む … split_decisions があれば、今回の申込がどちら側に近いかを確かめます
4. 既往歴の扱いを医務の担当に確かめる … 既往歴の解釈が判断を分けている場合は、医務の担当の意見を求めます
5. 判断を入力し、決裁を受ける … 審査の仕組みの判断メモに、参照した前例の判断の番号を書きます

5番目の「参照した前例の番号」を必ず残してください。 次にこの判断が前例として出てきたとき、どの前例を見て判断したかが分かれば、前例の連鎖をたどれます。

目標は、1件7分です。 前例を読み、改定の印と近さの内訳を確かめ、今回との違いを書き出すまでの時間です。

例外に対処する

6行目は、文書レベルのセキュリティの使い方です。 権限の無い担当には、見られない前例があること自体を中身で示さないようにします。前例の中身を見たいときは、権限のある担当に回します。

記録を残す

• 今回の申込の項目と、検索の条件（使った origin・offset・scale の値）
• 返した前例の判断の番号、近さの点の内訳、改定の印
• 生成AIに渡した検索結果と、返ってきた文章と引用の全文
• 引受担当が開いた判断メモと、判断に参照した前例の番号
• 検索した担当と、そのときの権限のロール

1行目で検索の設定の値を残すのは、近さの基準を後から直すためです。 年齢の scale を変えたときに、変える前と後で、どの前例が上位に来ていたかを比べられます。