損害保険の支払査定で、新しい事故案件に似た過去の事案を査定記録と査定基準から探し、判断の分かれ目と根拠を引く

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、査定システムで事案の決裁が終わったことを起点にします。 決裁前の事案を取り込まないのは、差し戻された判断や、途中の見立てを検索結果に出さないためです。 決裁の完了を通知できない仕組みなら、毎晩、決裁日で絞った一覧を取りに行きます。

過去の約3万件は、別に一括で取り込みます。 このときは担当の査定者の確認が取れないので、論点に「未確認」の印を付けます。検索結果では未確認の論点を区別して表示し、査定メモに参照として書くときに、その場で元の記録と照らしてもらいます。

検索は、査定者が検索画面で「探す」を押したときに動きます。 論点を洗い出した段階で、論点ごとに何度でも探せるようにします。1件の事案に論点が3つあれば、3回探します。

入力データを集める

質を決めるのは、論点の区分です。 区分が査定者ごとに違うと、「経年劣化」「老朽化」「自然消耗」が別の論点になり、絞り込みが効きません。 最初に損害サービス部で区分を決めます。自動車保険なら、過失割合、修理費の相当性、全損の判定、免責の該当、告知・通知義務、因果関係、の6つ程度から始めます。

査定基準には改定日を持たせます。 過去の事案の判断は、当時の査定基準に従って行われたものです。 基準が改定されていれば、同じ判断がいまも正しいとは限りません。

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

査定記録は、査定システムから文字で取り出します。事故の報告書や診断書の画像は、この構成では取り込みません。 判断の理由として査定者が書いた文だけを対象にします。

検索は2段に分けます。 1段目は、事故状況の文で似た事案を集めます。言葉の一致と、Cohere Embed v4 で search_query として埋め込んだ文の近さを組み合わせ、保険の種類と事故の種類を filter で絞ります。2段目は、1段目の50件の事案番号で絞ったうえで、nested クエリで迷っている論点と同じ区分の論点だけを探し、inner_hits で当たった論点を返します。

2段に分けるのは、事故状況の近さと論点の近さを別々に見るためです。 1つのクエリにまとめると、事故状況がよく似ていて論点が違う事案が上位に残ります。論点の区分は絞り込みの条件にし、近さの計算に混ぜません。

AIへ渡す前に整形する

1. 契約者の情報の除去 … 事故状況の文と判断の理由の文から、契約者・被保険者・相手方の名前、住所、電話番号、車両の登録番号を取り除き、[契約者] のような記号に置き換えます。埋め込みと Claude に渡すのは、置き換えたあとの文だけです
2. 文の長さの確認 … 事故状況の文が長い事案は、事故の経緯の部分だけを埋め込みます。やり取りの記録は対象にしません
3. 論点への分割 … 判断の理由の文を論点ごとに分け、記録の中の位置（何段落目か）を付けます
4. 区分の照合 … 取り出した論点の区分が、決めた区分のどれかに当たるかを確かめます。当たらないものは「その他」にし、確認の画面で目立たせます
5. 査定基準の版の付与 … 決裁日から、その時点で有効だった査定基準の版を付けます
6. 決裁で直された事案の印 … 決裁者が判断を直した事案には印を付け、直したあとの判断を正とします

1番目を軽く見ないでください。 項目として伏せても、事故状況の文の中には相手方の名前や住所がそのまま書かれていることがあります。 文の中から取り除かないと、伏せたはずの情報が検索結果とAIの入力に出てきます。

AIに処理させる

AIの仕事は2か所です。取り込み時の論点の取り出しと、検索結果のまとめです。

1行目がいちばん外せない線です。 過去の事案を並べると、AIは「以上から、本件も経年劣化と判断するのが妥当です」と添えたくなります。この一文が査定メモに写されると、査定者が判断していない結論が支払の根拠になります。

4行目も起きやすい失敗です。 10件のうち7件が不払なら、AIは「多くは不払」とまとめます。10件は検索で集めた偏った標本で、件数の多さは判断の正しさを示しません。

指示内容を固定する

取り込み時（論点の取り出し）：

あなたは損害保険会社で、決裁済みの査定記録を整理する担当です。
判断の理由の文だけを根拠にしてください。推測で埋めないでください。

【論点の区分】
過失割合 / 修理費の相当性 / 全損の判定 / 免責の該当 / 告知・通知義務 / 因果関係 / その他

【やること】
判断の理由の文を論点ごとに分け、それぞれについて次を取り出してください。
- 論点の区分（上の一覧から1つ）
- 判断：accepted / rejected / partially_accepted
- 理由：記録に書かれた文をそのまま写す
- 根拠の条項：記録に書かれた約款や査定基準の条項番号
- 記録の中の位置（段落の番号）

【厳守事項】
- 理由は、記録に書かれた文だけを写してください。
  書かれていなければ「記載なし」とし、理由を推測しないでください。
- 条項番号が書かれていなければ null にしてください。補わないでください。
- 判断は記録の結論の書き方に従ってください。読み替えないでください。
- 1つの段落に複数の論点があるときは、論点ごとに分けてください。
- [契約者] などの記号を、元の名前に戻そうとしないでください。
- 決裁で判断が直されているときは、直したあとの判断を使い、
  revised に true を入れてください。

検索時（結果のまとめ）：

あなたは支払査定の担当者の調べものを助ける担当です。
渡された検索結果だけを根拠に、過去の判断を並べてください。

【新しい事案】{new_claim}
【迷っている論点】{issue}
【過去の事案の論点（上位10件）と査定基準の箇所】検索結果として渡します

【書くこと】
1. 各事案の論点について、判断と理由（記録の記載どおり）
2. 判断が分かれた事案どうしについて、記録に書かれた違い
3. 査定基準の該当箇所と、当時の基準と現在の基準が違う事案

【厳守事項】
- 新しい事案の支払の可否、金額、過失割合を書かないでください。
- 「本件も〜と判断するのが妥当」のような結論を書かないでください。
- 件数の多い判断を、一般的な傾向として書かないでください。
- 理由を言い換えたり、付け足したりしないでください。
- 「未確認」の印のある論点は、その旨を必ず書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の論点を1つの search_result にし、source に事案の番号と段落、title に論点の区分と判断、content に理由の文と根拠の条項を別々のテキストブロックで入れます。査定基準の箇所も同じ形で、source に文書名と版と条項を入れます。引用を有効にすると、まとめの文ごとにどの記録のどの段落を根拠にしたかが付きます。 ドキュメントでは、引用の有効・無効はリクエスト内のすべての検索結果でそろえる必要があるとされているので、査定基準の箇所も含めて全部有効にします。

「結論を書かない」と「件数を傾向として書かない」は別々に書きます。 片方だけを禁じると、もう片方の形で結論が入ってきます。

出力形式を固定する

取り込み時の論点のまとまりは、次の形のJSONで受け取ります。

{
  "claim_id": "CL-2022-018834",
  "line": "auto | fire | personal_accident",
  "issues": [
    {
      "category": "過失割合 | 修理費の相当性 | 全損の判定 | 免責の該当 | 告知・通知義務 | 因果関係 | その他",
      "decision": "accepted | rejected | partially_accepted",
      "reason": "",
      "clauses": [""],
      "paragraph": 0,
      "revised": false
    }
  ],
  "standard_version": "",
  "unconfirmed": false
}

1つ目の理由は、issues を nested の項目として索引に入れられることです。 category と decision と reason の組み合わせが1つのまとまりとして保たれるので、「免責の該当で、認めなかった論点」という条件が、同じ論点の中で成り立つかを見られます。 普通のオブジェクトの配列にすると、区分と判断の組み合わせが崩れ、別の論点の判断が当たってしまいます。

2つ目は、decision を決まった値に限れることです。 査定者によって「否認」「不担保」「対象外」と書き方が違っても、判断は3つにそろいます。判断が分かれた事案を並べる処理は、この値で行います。

3つ目は、standard_version と revised で読み方を変えられることです。 査定基準が改定されている事案と、決裁で直された事案を、検索結果で区別して見せます。

2段目の検索の要求は、次の考え方で組みます。

システムへ連携する

埋め込みは、文書側を search_document、問い合わせ側を search_query で作ります。 Cohere Embed v4 の出力の次元は256、512、1,024、1,536から選べ、指定しなければ1,536です。索引の次元と同じ値を output_dimension で明示します。

査定システムには書き込みません。 査定メモへの書き出しは、参照した事案と査定基準の箇所を下書きに写すところまでです。判断と理由を書き、決裁に回すのは査定者です。

人が確認する

確認は2か所です。取り込み時の担当査定者と、検索時の査定者です。

1. 担当査定者が論点を確定する … 決裁の直後に、論点の分け方と区分、判断を確かめます。「その他」に入った論点と、revised が付いた事案を優先して見ます
2. 査定者が根拠の記録を開く … 参照に書く事案は、引用の付いた記録の段落を必ず開いて確かめます
3. 査定基準の版を確かめる … 当時の基準と現在の基準が違う事案を参照に使うときは、現在の基準で読み直します
4. 判断は自分で書く … まとめの文を査定メモに写さず、自分の判断と理由を書きます。参照した事案は「参照事案」の欄にだけ書きます

1件の事案あたり12分を目安にします。 10件の論点を読み、うち数件の記録を開いて確かめ、査定基準の箇所を読む時間です。

4番目が、この構成の線引きです。 決裁者が見る査定メモに、AIのまとめの文が混ざらないようにします。

例外に対処する

5行目が、この構成でいちばん大事な例外です。 同じ論点の判断が見つからないとき、事故状況が似た事案を代わりに出すと、別の論点の判断が、迷っている論点の答えのように読まれます。 0件は0件として見せます。

記録を残す

• 取り込んだ事案の番号、決裁日、取り込んだ日時、当時の査定基準の版
• Claude が返した論点のJSONと、担当査定者が確定した時に直した項目
• 検索のたびの新しい事案の条件、1段目の50件、2段目で当たった論点
• Claude に渡した検索結果と、返ってきたまとめと引用
• 査定者が参照に選んだ事案と、選ばなかった事案
• 「同じ論点の過去の判断は見つかりませんでした」と出た論点の記録

5つ目の記録は、判断のぶれを見るための材料になります。 同じ論点で、参照した事案と逆の結論を書いた査定が続くなら、査定基準の書き方か、過去の判断のどちらかを見直す時期です。 品質の監査で、論点ごとに集計して使います。