生命保険の新契約で、告知書の内容と診査・健康診断の結果を照らし、食い違いと追加で確かめる事項を引受査定の担当へ論点として出す

処理の起点を決める

診査結果か健診結果のイメージが、新契約システムに登録されたことを起点にします。 告知の回答は申込みの時点でそろっていますが、診査は後日、健診の結果通知書は後から送られてくることが多く、照合できるのは書類がそろってからだからです。

診査と健診の両方が提出される申込みでは、2つ目の書類が登録されたときにもう一度照合します。 1回目の論点は残したまま、2回目の結果を並べます。後から届いた書類で前の論点が解消することも、新しい論点が出ることもあります。

照合は1件ずつ動かします。 夜間にまとめると、翌朝の担当者に論点が届くまでの時間が空き、申込みから成立までの日数が延びます。

入力データを集める

募集人の面談のメモは、入力に入れません。 生命保険会社が指定した医師以外の、営業職員や保険代理店の担当者に健康状態を口頭で伝えても、告知したことにはならないとされています。照合の元を告知書と診査医の記載に限っておかないと、「募集人には伝えた」という記載が告知のように扱われます。

質を決めるのは、2つの対応表です。 「過去5年以内に健康診断で異常を指摘されたか」という質問に対して、健診のどの項目と判定を見るのかが決まっていなければ、AIは見る範囲を毎回自分で決めます。 対応表は、査定の手引きと、経験のある担当者が実際に見ている項目から作ります。質問の期間や内容は自社の告知書に合わせます。

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

レイアウトモデルは、本文を Markdown 形式で返せます。 表はHTMLの表として出るので、結合されたセルや複数行の見出しを持つ健診の表も、構造を保ったまま生成AIに渡せます。 数値の表だけでなく、総合判定や医師のコメントの文章も同じ流れで取れるのが、この構成でレイアウトモデルを使う理由です。

紙の告知書のチェック欄は、信頼度を見て扱いを分けます。 「はい」と「いいえ」の両方に印があるように読めるもの、どちらにも印が無いように読めるものは、照合に進めず、担当者がイメージで確かめる側に回します。

AIへ渡す前に整形する

1. 書類の種類の確認 … 告知書、診査結果、健診の結果通知書、それ以外を分けます。それ以外の書類は照合に使いません
2. 告知の回答をそろえる … 電子告知と紙の告知書の回答を、質問の番号ごとの同じ形にします
3. 健診の項目をそろえる … 項目名と判定の記号を、対応表で自社の項目と判定に置き換えます。対応表に無い項目名は、置き換えずに原文のまま残します
4. 受診日の確認 … 健診の受診日と申込日の間隔を計算し、告知書の質問の期間に入るかを付けます
5. 個人の情報を外す … 氏名、住所、勤務先、健診機関の名前を置き換えます。性別と年齢は残します
6. 読み取りが怪しい箇所の印 … 信頼度の低い文字とチェック欄に印を付け、AIに「読み取りが不確か」と伝えます

3番目で、置き換えられない項目を捨てないのが大事です。 対応表に無い項目は、まさに担当者が見落としやすい項目です。原文のまま残して、AIに読ませます。

4番目は、AIより先に機械で済ませます。 日付の計算は答えが決まっていて、AIに任せると期間の内か外かを取り違える余地が生まれます。結果を「確認済みの事実」として渡します。

AIに処理させる

させるのは、告知書の質問ごとに、診査・健診の記載と照らして論点を書き出すことだけです。 論点は3つの種類に分けます。

種類を分けるのは、査定者の次の行動が違うためです。 conflict は書類どうしを読み比べて扱いを決めるもの、missing_detail は告知の補足を求めるもの、needs_confirmation は追加の書類や確認を検討するものです。どれを依頼するかは査定者が決めますが、一覧の上で分かれていれば、読む順番が決まります。

3つ目の例は、食い違いとは書かせません。 「服薬中」の薬が、告知書の質問の対象になる病気のものかどうかは書類からは分かりません。分からないことを、分からないまま確認の論点として出すのが、この種類の役目です。

3行目がいちばん起きやすい失敗です。 血糖の数値が高い通知書を渡すと、AIはそれらしい病名を添えて論点を書きます。病名が一覧に載ると、査定者はそれを前提に書類を読み始めます。 書かせるのは「通知書の血糖の項目に、要精密検査の判定がある」までです。

指示内容を固定する

あなたは生命保険会社の新契約部で、告知書と医的な書類の照合を手伝う立場です。
引受の判断や、告知義務違反かどうかの判断はしないでください。
書類どうしを突き合わせて、査定者が確かめるべき論点を書き出すことだけをしてください。

【やること】
告知書の質問ごとに、【質問と項目の対応表】で示した診査・健診の項目と記載を見て、
次のいずれかに当たるものを論点として書き出してください。
- conflict ............. 告知の回答と、書類の記載が食い違う
- missing_detail ....... 「はい」の回答の詳細が、傷病名・時期・治療の内容のいずれかを欠く
- needs_confirmation ... 食い違いとは言えないが、査定者が確かめる価値がある
対応表に無い項目でも、告知書の質問に関係しうる記載があれば needs_confirmation で書いてください。

【厳守事項】
- 病名、病気の重さ、将来の見込みを推測して書かないでください。
  書類に書かれている項目名、数値、判定、医師のコメントだけを書いてください。
- 数値が基準を外れているかを、あなたが判断しないでください。
  通知書に書かれた判定か、【確認済みの事実】の判定だけを使ってください。
- 告知書・診査結果・健診結果の、どの書類のどの記載を根拠にしたかを、
  doc_type と quote で示してください。quote は書類の文字を一字も変えずに写してください。
- 読み取りが不確かと印の付いた箇所を根拠にする場合は、uncertain を true にしてください。
- 募集人の記載や、告知書・診査結果・健診結果以外の書類は根拠にしないでください。
- 受診日が告知書の質問の期間に入るかは【確認済みの事実】に従ってください。
- 論点が無い質問は、checked_questions に番号だけを入れてください。

【申込内容】{application}
【告知の回答】{disclosure}
【診査結果】{exam}
【健康診断の結果】{checkup}
【質問と項目の対応表】{question_map}
【確認済みの事実】{facts}

「数値の基準を判断しない」を書いておかないと、AIは自分の知っている基準で判定します。 健診機関によって基準値は違い、通知書の判定とAIの判定が食い違うと、どちらを信じるかという新しい論点が生まれます。 判定は通知書のものを使うと決めておけば、この迷いは起きません。

checked_questions を返させるのは、見たことを記録するためです。 論点が無い質問について何も返さないと、見て問題が無かったのか、見ていないのかが区別できません。 後段の Python で、告知書の全質問がどちらかに入っているかを照合します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "application_id": "",
  "issues": [
    {
      "question_no": "",
      "type": "conflict | missing_detail | needs_confirmation",
      "disclosure_answer": "",
      "evidence": [
        { "doc_type": "disclosure | exam | checkup", "page": 0, "quote": "" }
      ],
      "uncertain": false,
      "note": ""
    }
  ],
  "checked_questions": [""],
  "unread_items": [""]
}

unread_items には、対応表に無く、告知書の質問との関係も判断できなかった記載を入れさせます。捨てずに一覧に残し、担当者が見るかどうかを決めます。

1つ目の理由は、根拠をイメージにさかのぼれることです。 doc_type と page と quote があれば、担当者は書類のイメージの該当ページを開き、その文字を探すだけで確かめられます。quote が読み取りの結果の中に一字一句そのまま存在するかは、Python で照合します。 見つからない論点は uncertain に落とします。

2つ目は、AIの論点と、論点の重さの決め方を分けられることです。 Python が issues の種類と数から、規則で一覧の扱いを決めます。

3つ目は、規則を変えても論点の書き出しを触らずに済むことです。 たとえば「保険金額が一定以上の申込みは needs_confirmation でも priority」という規則を足すときも、プロンプトは変えずに済みます。

システムへ連携する

新契約システムと査定の記録へは書き込みません。 論点の一覧は査定の画面に表示するだけで、引受の判断、条件、追加の確認の依頼は査定者が記録します。 AIの論点を査定の記録に自動で写す経路を作ると、論点が判断の結論のように残ります。

人が確認する

担当者と査定者が見る順番を、一覧の扱いで決めておきます。

1. priority を先に見る … conflict の論点は、evidence の両方の書類を開き、本当に食い違っているかを目で確かめます
2. uncertain の論点はイメージで読み直す … 読み取りの誤りで生まれた論点が混ざっています
3. review の論点を見る … 告知の補足や追加の書類が要るかを、査定者が決めます
4. no_issue は抜き取りで見る … 毎日一定の件数を選び、書類を最初から読んで、論点の見落としが無いかを確かめます
5. 論点を覆したら記録する … どの論点を、なぜ取り下げたか、または足したかを残します

1番目を省かないでください。 conflict は、告知が事実と違うかもしれないという論点です。読み取りの誤りや、別の年の健診を照らしただけということもあります。 書類の上で確かめないまま申込者に補足を求めると、申込者に不要な負担をかけます。

4番目の抜き取りが、この構成の精度を支えます。 論点の一覧だけを見ていると、AIが見落とした側の誤りに気づけません。

例外に対処する

5行目は、AIに選ばせません。 診査の血圧と健診の血圧が違うのは、測った日も状況も違うからです。どちらを引受の判断に使うかは、査定の基準で決まります。

最初の2行は、紙の告知書の様式で減らせます。 チェック欄が小さすぎる、記入欄がチェック欄に近すぎるといった様式は、読み取りの迷いを生みます。

記録を残す

• 照合の対象にした申込みの番号と、使った書類のイメージの番号
• 読み取りの結果のJSONの全文（文字、表、チェック欄、信頼度）
• AIに渡した内容（個人の情報を置き換えた後のもの）と、対応表の版
• AIが返したJSONの全文と、使ったモデルのデプロイ名
• 規則で決めた扱い（no_issue ／ review ／ priority）と、その条件
• 担当者と査定者が論点を取り下げた・足した記録と理由
• 抜き取りで見つかった見落としの記録

3つ目で対応表の版を残すのは、照合の範囲が後から変わるためです。 告知書の質問を改定すると、同じ書類でも見る項目が変わります。当時の対応表が残っていないと、支払の段階で引受のときに何を見たかを説明できません。

6つ目と7つ目は、対応表を育てる材料になります。 取り下げが多い論点の種類は対応表の定めが広すぎ、抜き取りで見つかる見落としは対応表に足りない項目を示しています。