自動車保険の事故で修理工場から届く修理見積書を読み取り、部品・工賃・塗装の明細を損害調査の入力項目にそろえ、事故の内容と合わない明細を調査担当へ挙げる

処理の起点を決める

15分おきの定時実行にします。 整備工場は見積書と写真を何回かに分けてアップロードし、見積書が後から差し替えられることもあります。 受付番号ごとに最後のアップロードから15分以上たったものを対象にし、処理の後に見積書が差し替えられたら、前の下書きを「差し替え前」として残したうえで、もう一度処理します。

差し替えの検知は、ファイルの内容の要約値で行います。 ファイル名が同じでも中身が違えば、別の見積書として扱います。処理済みの印は、入力の下書きまで作れたときだけ付けます。

入力データを集める

質を決めるのは、受付記録の損傷の部位が決まった値になっているかです。 事故の状況が自由文だけで記録されていると、スクリプトは部位を照らせません。受付の段階で、損傷の部位を選択式で記録する運用が前提です。

部品名称と部位の対応表は、略し方の一覧を育てるものです。 最初は主な外装の部品と、Fr・Rr・LH・RH の付け方だけで始め、生成AIが unknown を返した名称を毎週足していきます。

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

Enterprise Document OCR には、次の2つを指定して送ります。

Form Parser からは、次の2つを取ります。

表がページをまたぐときは、ページの順に行をつなぎます。 2ページ目以降に見出しの行が繰り返されている様式では、headerRows の中身が1ページ目と同じことを確かめてからつなぎます。見出しが違うページは、別の表として扱い、人に回します。

セルの rowSpan と colSpan が1でないセルがあるページ、または表が返らないページは、表として取れなかったとみなし、OCRの全文を生成AIに渡します。

AIへ渡す前に整形する

1. 形式をそろえる … Document AI が受け付ける画像は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などで、HEIC は対応形式に含まれていません。 スマートフォンの写真は JPEG に変えます
2. むやみに圧縮しない … 非可逆の形式で小さくすると、読み取りの精度が落ちるとされています。明細の小さな数字が読めなくなるため、変換は1回だけにします
3. ページ数で分ける … 同期の処理は1回に15ページまでです。超える見積書は分けて送ります
4. 見積書と写真を分ける … 同じアップロードに損傷の写真が混ざっています。OCRの文字の量で見積書のページを選び、写真は後段に送りません
5. 品質の足りないページを分ける … qualityScore が0.5を下回ったページは、不具合の種類とともに needs_retake の候補にします
6. 個人の情報を覆う … 見積書の宛名欄の氏名と住所は、生成AIに渡す全文と画像からは塗りつぶします。 照合は登録番号と受付番号で行います

4番目で写真を送らないのは、この構成が損傷の画像を判断しないためです。 写真は担当者が見るもので、生成AIに写真を見せると、損傷の程度について書き始めます。

AIに処理させる

生成AIにさせるのは、明細の取り出しと、部位の選択だけです。

5行目だけが、選ぶ作業です。 選べる値は対応表の一覧に限り、一覧に無い名称は unknown にさせます。 名称から推測して近い部位を選ぶと、照らし合わせの結果が信用できなくなります。

いちばん起きやすい失敗は、表の1行目です。 「RrコンビランプLH」を生成AIは「左リアコンビネーションランプ」と直し、さらに「テールランプ」と言い換えることがあります。直した名前は、見積書と損害調査システムの照合を壊します。

指示内容を固定する

あなたは損害保険会社の損害サービスで、整備工場から届いた修理見積書を
読む担当です。渡された読み取り結果だけを見て、明細を取り出してください。
判断や計算はしないでください。

【取り出す項目】
車両 ……… 車名、型式、登録番号、初度登録年月
明細 ……… 行ごとに、コード、修理項目・部品名称、部品番号、修理の方法、
            指数、部品価格、工賃、そのページの番号
合計 ……… 見積書の合計金額

【修理の方法の選び方】
replace（取替）／ remove_install（脱着）／ sheet_metal（板金）／
paint（塗装）／ other（それ以外）
書かれた言葉に当たるものを選び、書かれた言葉は method_text に残してください。

【部位の選び方】
次の一覧から1つ選んでください。一覧に無い名称は unknown にしてください。
{part_location_table}
左右と前後は、名称の Fr・Rr・LH・RH などの書き方だけから決めてください。

【厳守事項】
- 部品の名称と部品番号は、書かれた文字列をそのまま写してください。
  略された名前を、分かりやすい名前や一般的な呼び方に直さないでください。
- 金額を足したり、指数から工賃を計算したりしないでください。
  空欄の金額は空のままにしてください。
- 記載がなければ status を missing にしてください。推測で埋めないでください。
- 名称から部位を推測しないでください。一覧に無ければ unknown です。
- 事故と関係があるか、修理費が妥当か、不正の疑いがあるかを書かないでください。
- 宛名の欄は塗りつぶされています。補わないでください。
- evidence には、その行の根拠にした文字列をそのまま写してください。

【読み取り結果（ページごと、品質不足のページには印）】{pages}

部位の一覧をプロンプトに入れるのは、選べる値を表の側で決めるためです。 一覧を渡さずに「部位を答えて」とすると、生成AIは「フロントフェンダー付近」のような自由な言葉で返し、スクリプトが受付記録と照らせません。

「不正の疑いを書かない」も外せません。 部位が合わない明細を見せると、生成AIは理由を推し量って書き足します。担当者がその文を先に読むと、写真を見る前に印象が決まります。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONを受け取ります。 要求の response_format に、mime_type を application/json、schema にJSONスキーマを指定します。

{
  "claim_no": "",
  "vehicle": { "name": "", "model_code": "", "reg_no": "", "first_reg": "",
               "status": "ok | missing | unreadable" },
  "lines": [
    { "page": 1, "code": "", "name": "", "part_no": "",
      "method": "replace | remove_install | sheet_metal | paint | other",
      "method_text": "", "index": "", "part_price": 0, "labor": 0,
      "location": "front | rear | left | right | roof | under | interior | unknown",
      "status": "ok | unreadable", "evidence": "" }
  ],
  "total_written": 0
}

スキーマでは method と location と status を enum で固定し、金額は integer にします。 location の一覧は、対応表の部位と同じ値にします。ただし、構文として正しいJSONが返っても、値はアプリケーションの側で確かめるよう案内されています。 スクリプトは、金額が負でないか、page が実在するか、部品番号の書式が崩れていないかを確かめます。

受け取ったあと、スクリプトが照合の結果を足します。

{
  "claim_no": "",
  "vehicle_match": "matched | reg_only | mismatch",
  "total_calc": 0,
  "total_gap": 0,
  "reported_locations": ["front"],
  "flags": [
    { "line": 0, "type": "location_mismatch | overlap_replace_repair | unknown_part | unreadable" }
  ],
  "verdict": "ready | flagged | needs_retake | needs_human"
}

flagged は「調べる必要がある」という意味ではありません。 受付記録の部位と明細の部位が違う、という照合の結果だけです。前部の事故で室内の部品を取り替えることも、事故の状況によっては起こりえます。

システムへ連携する

損害調査システムには、下書きとして書き出します。 明細の行、作業の区分、部位、金額、印を入れた状態にし、担当者が確かめて確定するまで、調査の入力として扱いません。

整備工場への問い合わせは、この構成からは送りません。 印の付いた明細を工場に確かめるか、技術アジャスターに相談するかは担当者が決め、連絡は今までどおり担当者が行います。

人が確認する

1. needs_human を先に見る … 車両が受付記録と合わないもの、合計が合わないもの。整備工場に見積書の確認を頼みます
2. flagged の明細を写真で見る … 印の付いた行の部品が、写真の損傷の範囲に写っているかを確かめます
3. unknown_part の名称を見る … 部位を選び直し、対応表に足すかを週に1回まとめて決めます
4. 下書きを確定する … 直した行は記録します
5. 調査の判断に進む … 修理費と損傷の関係の判断は、今までどおり担当者と技術アジャスターが行います

2番目を省かないでください。 印は受付記録との照合の結果で、受付記録の部位そのものが聞き取りの段階で不十分なこともあります。 写真で損傷の範囲を見て初めて、印の意味が分かります。

ready の見積書も、明細の行数と合計だけは目で見ます。 1行ずつ読み直す運用にすると、第10章の5分には収まりません。

例外に対処する

運用の最初に多いのは、6行目です。 部品の略し方は工場ごとに癖があり、最初の1〜2か月は unknown が多く出ます。 対応表に足すほど減り、照合の結果が使えるものになっていきます。

記録を残す

• 見積書の原本と、受付番号、整備工場、アップロードの日時、差し替えの履歴
• Document AI が返した結果の全文と、Gemini API に渡した全文（宛名を覆ったもの）と返ったJSON
• スクリプトが足した照合の結果と、そのとき使った部品名称と部位の対応表、重なりの規則の版
• 担当者が直した行と、直す前と後の値
• flagged の明細について、担当者が写真で確かめた結果（損傷の範囲にあった／なかった）
• 整備工場ごとの撮り直しと unknown の件数

5つ目の記録は、受付の聞き取りを直す材料になります。 印が付いたのに写真では損傷の範囲にあった、という結果が続く事故の型は、受付の段階で部位の聞き取りが足りていません。