保険金の支払・一部支払・不支払の査定結果を、約款の該当箇所と査定の記録から契約者に分かる言葉で説明する通知文の下書きにし、査定担当の確認に回す

処理の起点を決める

支払査定システムで、査定担当が請求を「通知文作成」の状態にしたことを起点にします。 1時間ごとに状態を見て、該当する請求を順に処理します。夜にまとめて処理することはしません。 不支払の通知は、迅速性にも留意して行う必要があるとされていて、確定した査定が翌日まで寝ていることを避けます。

全額を支払う請求のうち、定型の明細書で済むものは対象にしません。 対象は、一部支払、不支払、そして査定担当が「説明を添える」に印を付けた支払の3つです。印を付ける判断は査定担当に残します。 支払でも、契約者が想定していた日数より少ない、といった請求には説明が要ります。

処理が終わった請求は「下書き確認待ち」に変え、照合で不一致が出た請求は「作り直し」のまま残します。 状態ごとの件数が、そのまま滞留の数になります。

入力データを集める

質を決めるのは、査定の記録の「認定した事実関係」の欄です。 ここが「告知と相違あり」の一言だと、通知文の理由も一言になります。「◯年◯月に◯◯の治療を受けていたことが、◯◯病院の診断書で確認された」の粒度で書かれていれば、通知文はそれを並べ直すだけで済みます。 この構成を入れる前に、記録の書き方をそろえることが最初の仕事です。

一部支払の請求なら、渡す記録は次のような形になります。

判定と条項が給付の種類ごとに分かれていることが前提です。 1つの欄に「一部支払」とだけあると、どの給付のどの日数なのかを ChatGPT が組み立てることになります。

用語の言い換えの一覧は、支払部門で作ります。 「責任開始期」「所定の手術」「継続した入院」などの約款の言葉ごとに、契約者向けの言い方を1つに決めておきます。一覧が無ければ、ChatGPT は毎回違う言い換えをします。

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

約款の版は、契約日と商品から機械的に決めます。 査定担当の手入力にはしません。版の取り違えは、通知文の誤りの中で最も見つけにくいものです。 条項番号が同じでも、版によって文言が違うことがあるからです。

条項の原文は、適用した条項と、その条項が参照している定義の条項までを渡します。 「所定の手術」は別表を参照していることが多く、本文だけを渡すと、別表の範囲を推測して説明します。

AIへ渡す前に整形する

1. 対象の判定 … 判定が一部支払か不支払か、または「説明を添える」の印があるかを見ます
2. 記録の欠けの確認 … 適用条項の番号と認定した事実関係が空なら、処理せず査定担当に戻します
3. 約款の版の特定 … 契約日と商品から版を決め、条項番号でその版の原文が引けるかを確かめます
4. 個人を特定できる情報の置き換え … 氏名・住所・証券番号・医療機関の担当医名を記号に置き換えます。医療機関名と診断名は理由の説明に要るので残します
5. 金額と日数の書式の統一 … 査定の記録の数字を、通知文で使う書式（3桁区切り、日付の書き方）にそろえて渡します
6. 対象外の事案の除外 … 告知義務違反による解除、重大事由による解除、詐欺による取消しの事案は、この構成で下書きを作らず担当者が書きます

2番目を軽く見ないでください。 記録が空のまま下書きを作らせると、ChatGPT は判定と条項番号から、ありそうな事実を組み立てます。 事実の欄が空の請求は、通知文を作れる状態ではありません。

6番目は、法的な判断を経る事案だからです。 生命保険協会のガイドラインでも、偶発性が無いと判断するような事案は必要に応じて法務部門・弁護士等の法的判断を踏まえて慎重に行うとされています。こうした事案の通知文を生成に任せる理由はありません。

AIに処理させる

させるのは、査定の記録と条項の原文を、決めた3部構成で契約者向けの文章に直すことです。 3部は、生命保険協会のガイドラインが不支払の場合に説明すべき事項として挙げる、①支払えないこと、②支払えない理由（該当する約款条項・事実関係）、③決定に不服がある場合の対応方法 に合わせています。

3行目の「原文のまま残し、印を付ける」が大事です。 一覧に無い用語を ChatGPT が自分で言い換えると、言い換えの範囲が約款より広くなったり狭くなったりします。 狭く言い換えれば、契約者は対象外だと思い込み、広く言い換えれば、次の請求で食い違います。

2行目がいちばん起きやすい失敗です。 「責任開始前の発病」と判定と条項があれば、ChatGPT は「加入前から通院されていたため」と経緯を補います。 記録にその通院の事実があれば正しく、無ければ通知に書いてはいけない事実です。

指示内容を固定する

あなたは生命保険会社の給付金の支払部門で、契約者にお送りする
査定結果の通知文の下書きを作る担当です。
支払うかどうかの判断はすでに済んでいます。判断を変えないでください。
下の【査定の記録】と【約款の条項】に書かれていることだけを材料にしてください。

【構成】次の3部で書いてください。
1. 結論 … 給付の種類ごとに、お支払いする・お支払いできないこと、
   日数・回数・金額。
2. 理由 … 適用した条項の原文をそのまま引用し、その下に
   【用語の言い換え】の言葉で意味を説明し、続けて記録の
   「認定した事実関係」を日付と書類の名称とともに書く。
3. 決定にご不服がある場合 … 【申出先の定型文】をそのまま入れる。

【厳守事項】
- 金額・日数・回数・日付は【査定の記録】の値をそのまま写してください。
  計算したり、丸めたり、合計を作ったりしないでください。
- 【査定の記録】に無い事実、経緯、医学的な説明を書き足さないでください。
  記録が足りないと感じたら、missing_in_record に書いてください。
- 条項の引用は一字一句変えないでください。
- 【用語の言い換え】に無い約款の用語は、自分で言い換えず原文のまま残し、
  unexplained_terms に入れてください。
- 契約者の落ち度や責任を示す言い回し、評価の言葉を使わないでください。
  事実だけを書いてください。
- 今後の請求の扱いについては書かないでください。
- 1文ごとに、根拠にした記録の項目名か条項番号を sources に入れてください。
- 敬体で、1文を60字程度までにしてください。

【査定の記録】{assessment_record}
【約款の条項（契約時の版）】{clauses}
【用語の言い換え】{glossary}
【申出先の定型文】{appeal_text}
【説明の手引】{style_guide}

「判断を変えないでください」を冒頭に置くのは、条項と事実を読ませると、ChatGPT が判断を検討し始めるからです。 「この事実なら支払の対象になる可能性もあります」と書き添えることがあります。通知文の下書きに、査定への意見は要りません。

「記録が足りないと感じたら書く」場所を用意しているのも同じ理由です。 書く場所が無いと、足りない部分を文章で埋めます。埋めずに申告させれば、査定の記録の書き方を直す材料になります。

出力形式を固定する

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

{
  "claim_id": "",
  "decision_type": "full | partial | denied | paid_with_note",
  "sections": [
    { "part": "conclusion | reason | appeal",
      "sentences": [ { "text": "", "sources": ["査定記録:支払日数", "第◯条"] } ] }
  ],
  "quoted_clauses": [ { "clause_no": "", "edition": "", "text": "" } ],
  "unexplained_terms": [],
  "missing_in_record": []
}

1つ目の理由は、1文ごとの sources で照合ができることです。 照合のスクリプトは、文の中の数字と日付を拾い、sources に書かれた記録の項目の値と突き合わせます。根拠の項目が書かれていない数字、記録と食い違う数字は、その場で不一致です。

2つ目は、quoted_clauses を原文と機械的に比べられることです。 引用の文字列を、約款の管理データベースの同じ版・同じ条項番号の原文と比べ、1文字でも違えば不一致にします。

3つ目は、unexplained_terms と missing_in_record が査定担当への申し送りになることです。 下書きを開く前に、どこを自分で書き足す必要があるかが分かります。

照合の規則は次のとおりです。

decision_type は記録から決め、AIには決めさせません。 スキーマの値は記録の判定をそのまま入れて渡し、返ってきた値が渡した値と違えば不一致にします。

システムへ連携する

支払査定システムには、状態の変更以外は書き込みません。 通知文の下書きが査定の記録を上書きする経路を作らないためです。通知文と記録が食い違ったとき、正しいのは常に記録の側です。

人が確認する

査定担当は、すべての下書きを読みます。 通知文は契約者に直接届き、支払の判断を伝える文書です。低信頼のものだけを見る設計にはしません。

1. 照合の結果を先に見る … 不一致が0件か、印の付いた文があるかを確かめます
2. missing_in_record と unexplained_terms を見る … 記録の書き足しか、言い換えの一覧への追加が要るかを決めます
3. 理由の言い換えを読む … 引用した条項より広く・狭く言っていないかを、引用と並べて読みます
4. 事実の並びを読む … 認定した事実が、契約者に誤解のない順で並んでいるかを見ます
5. 不支払の通知は上席に回す … 上席がもう一度読みます

3番目を省かないでください。 数字と引用は機械で照合できますが、言い換えが条項の意味から外れていないかは、人が読まないと分かりません。 時間をかけるのはここです。

直したら、直した理由を1つ選んで記録します。 選択肢は「言い換えの修正」「事実の並びの修正」「記録の不足」「表現の修正」の4つです。理由の集計が、言い換えの一覧と記録の書き方のどちらを直すべきかを教えてくれます。

目標は1件12分です。 下書きを一から書く時間が無くなり、読む・直す時間が残ります。12分を大きく超える請求が続くなら、記録の書き方か言い換えの一覧に足りないものがあります。

例外に対処する

3行目で作り直しを打ち切るのは、同じ材料で何度作らせても同じところで誤るからです。 2回続くなら、記録の値の書き方が通知文の書式と合っていない、といった材料の側の問題を疑います。

記録を残す

• 査定の記録の取り出し時点の値と、使った約款の版・条項番号
• 記号に置き換えた後の入力と、返ってきたJSONの全文
• 照合の結果（項目ごとの一致・不一致）
• 査定担当が直した後の通知文と、直した箇所
• 上席の確認の記録（不支払のもの）
• 発送した日付と、発送した通知文の確定版

1つ目で「使った約款の版」を残すのは、再照会と苦情に答えるためです。 ガイドラインでは、不支払に関する苦情の内容は処理結果を含めて記録・保存するとされています。通知文がどの版の条項を根拠にしたかが残っていないと、苦情の対応で当時の説明を再現できません。

4つ目の「直した箇所」は、言い換えの一覧を育てる材料です。 毎月同じ言い換えを直しているなら、それは一覧に載せるべき言い方です。