住宅の火災保険の破損・水濡れ・盗難の請求で届く書類と事故の経緯を Azure OpenAI で読み合わせ、書類どうしの食い違いを確認点に並べて、特別調査に回すかの判断材料を査定担当に出す

処理の起点を決める

支払システムで、請求の書類がそろって査定に入ったことを起点にします。 査定の状態が「書類完備」「査定中」に変わった事故を、Azure Functions から15分ごとに拾います。支払システムに状態の変化を外へ知らせる仕組みがあれば、それを使います。

事故の連絡を受けた時点では動かしません。 書類がそろわないうちに食い違いを探すと、まだ届いていない書類が「食い違い」に見えます。ただし、書類が後から追加で届いたときは、もう一度動かし、前回の確認点との差を出します。

処理の結果は、査定担当が事故を開く前にそろっているようにします。 査定に入ってから15分以内に一覧が添えられていれば、担当者は書類を読み始める前に確認点を見られます。処理が遅れているときは、一覧が無いことを画面に出し、手作業で読み合わせます。

種目は破損汚損・水濡れ・盗難に限ります。 風災・水災などの自然災害の請求は、同じ地域で同じ日に多数届くので、書類どうしの食い違いの意味が違います。対象を絞ることで、確認点の種類を決めやすくします。

入力データを集める

入力から外すもの： 契約者の年齢、国籍、職業、住所の地域、過去の苦情の有無。これらは確認点の材料にしません。 書類の住所は「所在地」として、損害の場所が契約の所在地と一致するかを見るためだけに使います。

過去の請求は、AIに渡さずプログラムで照合します。 同じ契約で同じ物の請求があるかは、日付と品目で機械的に引けます。AIには、照合の結果（「同じ契約で14か月前に同じ型番のテレビの請求あり」）だけを渡します。

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

1. 受付の記録と査定の状態 … 支払システムから、事故の番号で受付の記録と書類の一覧を取ります
2. 書類の文字のデータ … 請求書類の取込が保存している文字のデータを、書類の種類ごとに取ります。読み取りの信頼度が低い書類は、その旨を印にして持ちます
3. 契約の情報 … 契約の管理システムから、始期日・保険金額・変更の履歴を取ります
4. 過去の請求 … 契約番号と所在地で、自社の支払システムの過去の請求を引きます

2番目で、取込が読めなかった書類を「書かれていない」と扱わないことが大事です。 手書きの報告が読めずに空になっていると、AIは「報告に損害の物の記載が無い」と確認点にします。読めなかったことと書かれていないことは、査定担当にとって意味がまったく違います。

写真そのものは渡しません。 渡すのは、請求者や修理業者が書いた写真の説明と、取込のときに付いた撮影日などの文字のデータだけです。写真を画像として読ませると、写っている物の推し量りが確認点に混ざり、書類に書かれた事実どうしを比べるという線がぼやけます。 写真と説明が合っているかは、査定担当が原本で見ます。

集めた情報は、事故の番号ごとに1つの入力にまとめます。 書類の種類ごとに見出しを付け、どの文がどの書類のものかが分かる形にします。見出しが無いと、AIは根拠の書類を取り違えます。

AIへ渡す前に整形する

1. 属性の除外 … 年齢・国籍・職業・住所の地域など、確認点の材料にしない項目を入力から取り除きます
2. 記号化 … 契約者・被保険者・修理業者の氏名と連絡先を「契約者」「修理業者A」に置き換えます。対応表は Azure Functions の側に持ちます
3. 書類の種類の付け直し … 取込のときに付いた種類が違っていれば直し、種類ごとに区切りを入れます
4. 日付の正規化 … 和暦・西暦・「先週の金曜」のような書き方を残したまま、プログラムで読める日付は併記します
5. 期間の計算 … 始期日・補償の変更日と事故日との日数を、プログラムで計算しておきます
6. 読み取りの信頼度の印 … 信頼度が低い書類には「読み取り不確か」の印を付けて渡します

5番目をAIにさせないのは、計算の誤りを避けるためです。 日数の計算はプログラムのほうが確実で、AIには計算の結果を渡し、それを経緯と照らすところだけをさせます。

1番目は、外したことを記録に残します。 どの項目を外して渡したかが残っていないと、後から「属性で振り分けていないか」と問われたときに答えられません。外す項目の一覧に版を付け、処理ごとにその版の番号を保存します。 一覧を変えるときは、不正請求対策の担当とコンプライアンスの担当の両方が承認します。

AIに処理させる

表の3行目「損害と修理の対応」がいちばん効きます。 監督指針も、過大な修理費の見積りに基づく請求を問題として挙げています。ただし、AIが見るのは「その項目が報告された損害と対応するか」だけで、金額が高いか安いかは見ません。

たとえば、報告に「洗面所の給水管から漏れ、洗面所の床が濡れた」とあり、写真の説明も洗面所の床だけなのに、見積書に「洗面所 床張替」「廊下 床張替」「洋室 クロス張替」が並んでいる場合です。AIは「廊下」「洋室」の2項目が報告と写真の説明に出てこないことを挙げ、根拠として3つの書類の該当行を写します。 水が廊下まで回った可能性はあり、それを確かめるのは査定担当と、必要なら鑑定人です。AIの役目は、確かめるべき2項目を見落とさずに示すところまでです。

指示内容を固定する

あなたは損害保険会社の査定担当を補助し、保険金請求の書類どうしが
合っているかを確かめます。不正かどうかは判断しません。

【渡すもの】
- 受付の記録と、請求書類（種類ごとに区切り）の文字のデータ
- 契約の始期日・変更日と事故日の日数（計算済み）
- 過去の請求の照合結果（計算済み）
「読み取り不確か」の印がある書類は、文字が正しく読めていない可能性があります。

【させること】
1. 書類ごとに、事故の日時、場所、原因、損害の物、修理の内容と金額を
   取り出してください。書かれていなければ "記載なし" としてください。
2. 同じ事実について書類どうしで記載が違うものを findings に挙げてください。
3. 修理見積書の各項目が、報告や写真の説明に出てくる損害と対応するかを見て、
   対応しない項目を findings に挙げてください。
4. 各 finding には、根拠にした原文を書類ごとに quote に一字一句写してください。
5. 各 finding について、請求者または修理業者に確かめる問いを1つ書いてください。

【厳守事項】
- 不正、虚偽、詐欺、疑わしい、といった評価の言葉を使わないでください。
- 支払うべきか、調査に回すべきかを書かないでください。
- 請求者の人柄や書きぶりについて書かないでください。
- 書かれていない事実を、経験則や一般的な事故の様子から補わないでください。
- 修理費の金額が高い・安いを評価しないでください。
- 「読み取り不確か」の書類だけに基づく食い違いは、basis を ocr_uncertain に
  してください。
- 日付の表記の違い（和暦と西暦など）だけで、同じ日を指すものは
  食い違いにしないでください。

【種類】date / location / damaged_item / amount / cause / missing_document
【事故の番号】{claim_ref}
【受付の記録】{intake_record}
【請求書類】{documents}
【計算済みの情報】{computed_facts}

「評価の言葉を使わない」を最初に書くのは、確認点が査定担当の先入観になるからです。 一覧に「疑わしい」と書かれていれば、それを読んだ担当者は疑う目で書類を読みます。一覧に書くのは「AとBの記載が違う」という事実だけにします。

最後の項目の「同じ日を指すもの」も入れておきます。 入れないと、令和と西暦の書き分けや「10/3」と「10月3日」の違いを食い違いとして挙げ、確認点の大半が意味のないものになります。

出力形式を固定する

{
  "claim_ref": "",
  "facts_by_document": [
    { "document": "事故状況の報告", "event_datetime": "", "location": "",
      "cause": "", "damaged_items": [""], "repair_items": [""], "amounts": [""] }
  ],
  "findings": [
    { "id": "F1", "type": "date | location | damaged_item | amount | cause | missing_document",
      "description": "",
      "quotes": [ { "document": "", "text": "" } ],
      "basis": "text | ocr_uncertain",
      "question_to_confirm": "" }
  ]
}

1つ目の理由は、findings と振り分けを別の層に置けることです。 findings はAIが埋め、振り分けは Azure Functions が規則で決めます。

2つ目は、quotes をプログラムで照合できることです。 各 text が、指定した書類の文字のデータにそのまま含まれているかを確かめ、含まれていない確認点は「原文と一致せず」と表示して振り分けの数から外します。

3つ目は、question_to_confirm がそのまま請求者への確認に使えることです。 確認点の多くは、請求者に聞けば誤記と分かって解消します。問いを先に用意しておくと、確認の連絡が速くなります。

システムへ連携する

支払システムへの書き込みは、確認点の一覧を添えることだけです。 査定の状態を変えたり、支払を止めたりする操作は、この構成からは行いません。調査に回すと決めるのも、状態を変えるのも、人です。

人が確認する

1. 確認点を書類の原本で確かめる（査定担当） … quotes の箇所を原本の画像で見て、食い違いが本当にあるかを確かめます
2. 請求者・修理業者に確かめる（査定担当） … question_to_confirm を使って問い合わせ、誤記・記憶違いと分かったものは、その旨を記録して解消します
3. 調査に回すかを決める（査定担当と不正請求対策の担当） … 「調査の検討」に振り分けられたもので、2番目で解消しなかったものについて協議します
4. 回さない理由を記録する … 確認点ごとに、何を確かめて解消したかを残します

2番目を3番目より先に置くのが、この運用の要です。 確認点の多くは請求者に一度聞けば片づきます。いきなり調査に回すと、誠実な請求者の支払いを理由なく遅らせることになります。

確認点の一覧は、支払システムの事故の画面から1回で開けるようにします。 一覧の各確認点から、根拠の書類の該当ページへ飛べると、原本で確かめる時間が大きく減ります。一覧だけを見て原本を開かない運用にならないよう、確かめた印を付けないと次の操作に進めない作りにしておくと確実です。

目標は、600件をならして1件8分です。 findings が0件の請求は数十秒で一覧を確かめて終わり、確認点のあるものは原本で確かめて数分から十数分かかります。

例外に対処する

最後の行は、AIの判断に入れません。 同じ修理業者の見積りに食い違いが続くかどうかは、件数を集計して不正請求対策の担当が見るものです。1件の確認点の一覧に「この業者は前にも」と書かせると、個々の請求の判断がゆがみます。

記録を残す

• AIに渡した入力の全文（属性を外し、記号化した後のもの）と記号の対応表
• AIの出力のJSONと、quotes の照合結果
• 振り分けの結果と、そのとき使った振り分けの規則の版
• 査定担当が確かめた結果（確認点ごとに、解消・未解消と理由）
• 調査に回すかの協議の結果と決めた人
• 調査の結果（回したものの結論）と、それが確認点のどの種類に当たっていたか

最後の行が、規則を直す材料になります。 どの種類の確認点が調査で事実と分かり、どの種類が誤記ばかりだったかが分かれば、振り分けの規則を書類の事実に基づいて直せます。 監督指針も、不正請求事案の調査結果などを通じて把握した課題を踏まえ、支払の手続きを見直すことを求めています。