火災保険の保険金請求で届くり災証明書・修理見積書・被害写真の説明書きを読み取り、事故日・被害箇所・見積額を受付票にそろえて、足りない書類を案内する

処理の起点を決める

提出画面からのアップロードで書類が Cloud Storage に保存されたことを起点にします。 バケットの中は請求番号ごとのフォルダに分け、ファイルが1つ保存されるたびにイベントが届きます。

ただし、1ファイルごとに受付票を作るわけではありません。 契約者は書類を数回に分けて送ってくることがあり、最初の1枚で受付票を作ると、残りが届く前に「不足」と判定してしまいます。 そこで、ファイルごとの読み取りはイベントのたびに行い、受付票の案を作るのは「提出を完了する」ボタンが押されたときにします。提出画面にそのボタンが無い場合は、最後のファイルから30分たったところで受付票を作ります。

郵送で届いた書類は、受付でスキャンして同じ請求番号のフォルダに置きます。経路で処理を分けません。 分けると、郵送の請求だけ食い違いの確認が抜ける期間ができます。

入力データを集める

質を決めるのは、いちばん下の必要書類の一覧です。 これが担当者の記憶にしか無いと、不足の洗い出しを規則にできません。一覧は、自社の請求の案内に載っている必要書類をそのまま表にしたもので十分です。

契約の所在地は、被害の場所の照合に使います。 り災証明書の火災の場所と、契約の保険の対象の所在地が違えば、別の建物の書類が混ざっているかもしれません。ここもAIではなく規則で見ます。

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

読み取りは、関数から Document AI のプロセッサを呼ぶだけです。すべてのファイルを先に Enterprise Document OCR に通し、そのあと種類に応じて Form Parser にも通します。

画像の品質の点数は、既定では返りません。 リクエストの processOptions.ocrConfig.enableImageQualityScores を有効にします。公式の説明では、この機能はOCRの処理と同じくらいの時間を処理に足すとされています。全ファイルで有効にすると時間が倍になるので、写真（JPEG・PNG）だけで有効にし、PDFでは切る運用にします。

言語のヒントも付けます。 processOptions.ocrConfig.hints.languageHints に ja を入れると、データの性質に合わせて読み取りの精度を上げられるとされています。

AIへ渡す前に整形する

1. 形式の確認 … PDF、GIF、TIFF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます。HEIC の写真は JPEG に変換します
2. サイズとページ数の確認 … オンライン処理は1ファイル40MBまで、Form Parser は15ページまでです。超えるものはバッチ処理（Form Parser は100ページまで）に回します
3. 解像度の確認 … スキャンは200dpi以上が最低、300dpi以上が最適とされています。郵送の書類は300dpiでスキャンします
4. 画素数の確認 … 画像は1ページ4,000万画素までです。スマートフォンの写真で超えるものは縮小します
5. 写真の向きの補正 … 横向きに撮られた見積書は、読み順が崩れるので向きを直してから読ませます
6. 重複の検知 … 同じファイルが2回アップロードされたものは、内容の一致で見つけて1つにします

3番目と5番目を軽く見ないでください。 見積書の明細は表の構造で読むので、表の罫線が斜めに写っているだけで、行と列が崩れます。 崩れた表から合計を読むと、第7章の検算で食い違いが大量に出ます。

AIに処理させる

AIの仕事は3つです。書類の種類の見分け、受付票の項目へのそろえ、案内の下書きです。

2行目と5行目がいちばん起きやすい失敗です。 見積書の合計が読めないと、AIは明細を足し上げて合計を入れようとします。その値が見積書に書かれた金額として受付票に載ると、査定はそれを前提に進みます。 合計は「書かれている値」だけを取り、検算は関数が別に行います。

指示内容を固定する

あなたは損害保険会社の保険金請求の受付担当です。
火災保険の請求で届いた書類のOCR結果から、受付票の項目に値をそろえます。
OCR結果に書かれていることだけを根拠にしてください。推測で埋めないでください。

【書類の種類】
- fire_certificate：消防署長が交付するり災証明書
- repair_estimate：修理業者の見積書
- photo_note：被害写真の台紙や余白に書かれた説明書き
- other：上のどれでもないもの（請求書、委任状、本人確認書類など）

【取り出す項目】
1. 事故日の候補（書類ごとに別々に。発生日時、調査日、撮影日を混ぜない）
2. 被害の場所（階、部屋）と部位（天井、壁、床、設備など）
3. 見積の明細（工事の内容、数量、単価、金額）と、
   小計・消費税・税込合計（書かれているものだけ）
4. り災証明書の発行者と、り災の程度の記載

【厳守事項】
- 記載がなければ value を空にし、status を missing にしてください。
- 品質の点数が0.5未満の領域から取った値は、status を unreadable にしてください。
  読めた部分から前後を推測して埋めないでください。
- 見積の合計が書かれていなければ、明細を足して合計を作らないでください。
- 日付の前後が合わなくても、どちらが正しいかを書かないでください。
- 保険金の支払の可否、損害の額の妥当性、事故の原因については書かないでください。
- 各項目に、根拠にした書類のファイル名とページ、文字列をそのまま付けてください。
- 電子申請で交付されたり災証明書には押印がありません。
  押印が無いことを不備として扱わないでください。

【請求の申告】{claim_declaration}
【契約の情報（保険の対象と所在地）】{policy}
【OCR結果（ファイルごと、品質の点数付き）】{ocr_results}

「押印が無いことを不備として扱わない」は、書いておかないと起きます。 名古屋市の案内では、電子申請で交付されるり災証明書の電子データには押印が無いとされています。AIは「公的な証明書には押印がある」と考えて、押印の欠落を指摘しがちです。

「発生日時、調査日、撮影日を混ぜない」も同じです。 書類ごとの日付を1つの「事故日」にまとめさせると、どの書類の日付だったかが消え、食い違いを見つける材料がなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude の構造化出力（output_config.format に json_schema を指定）を使い、項目の名前と型を固定します。

{
  "claim_id": "FC-2026-104233",
  "documents": [
    { "file": "IMG_0412.jpg", "pages": [1], "doc_type": "repair_estimate",
      "quality_score": 0.82, "handwritten": false }
  ],
  "dates": [
    { "source_doc": "fire_certificate", "kind": "occurred_at",
      "value": "2026-09-18", "status": "ok | missing | unreadable", "evidence": "" }
  ],
  "damage_locations": [
    { "floor": "2F", "room": "洋室（北）", "part": "天井",
      "source_doc": "photo_note", "status": "ok", "evidence": "" }
  ],
  "estimate": {
    "lines": [ { "item": "", "qty": "", "unit_price": "", "amount": "" } ],
    "subtotal": "", "tax": "", "total": "",
    "total_status": "ok | missing | unreadable"
  },
  "certificate": { "issuer": "", "damage_level_text": "" }
}

1つ目の理由は、dates を書類ごとに並べられることです。 申告の事故日、り災証明書の発生日、見積書の調査日、写真の撮影日を同じ配列に入れ、前後関係の確認を関数で行います。 たとえば調査日が発生日より前なら印を付けます。

2つ目は、status で「書かれていない」と「読めなかった」を分けられることです。 関数は missing の書類を「不足」、unreadable の書類を「撮り直し」に振り分けます。2つを混ぜないことが、案内の文面を正しくする前提です。

3つ目は、見積の合計を検算できることです。 lines の金額を関数が足し、subtotal と比べます。合わなければ、表の読み取りが崩れているか、見積書そのものの誤りです。 どちらかは担当が画像で確かめます。

構造化出力の制約にも注意します。公式の説明では、数値の範囲（minimum・maximum）や文字数の制約は使えないとされています。金額は文字列で受け、数値への変換と範囲の確認は関数の側で行います。

関数が規則で出す確認の結果は、次の形で受付票の案に添えます。

システムへ連携する

受付票は「案」として書き込み、確定のボタンは担当が押します。 確定された受付票だけが査定の担当の一覧に出ます。契約の台帳と査定の記録には、この構成から書き込みません。

案内のメールも自動では送りません。 下書きを受付票に添え、担当が直して送ります。不足の判定が誤っていた1件の案内は、契約者にとっては「出したのに出していないと言われた」連絡になります。

人が確認する

担当が見るのは、受付票の案と、印の付いた項目です。

1. 印の付いた項目を先に見る … date_mismatch、location_mismatch、estimate_sum の付いた項目は、根拠の画像を開いて確かめます
2. unreadable を確かめる … 品質の点数と欠陥の種類（反射、ぼやけなど）を見て、本当に撮り直しが要るか、担当が画像で読めるかを決めます
3. missing_doc を確かめる … 不足とされた書類が、別のファイルに混ざっていないかを見ます。種類の見分けの誤りで「不足」になっていることがあります
4. 受付票を確定し、案内を送る … 下書きを直して契約者に送り、確定した受付票を査定に回します

1件あたり5分を目安にします。 印の無い請求は受付票の案を流し読みして2〜3分、印のある請求は画像を開いて確かめるので数分かかります。ならして5分です。

3番目を省かないでください。 見積書の2ページ目が別のファイルで届き、そちらを「その他」と見分けると、見積書が無いという案内が出てしまいます。

例外に対処する

6行目は、題材の名前にもかかわる区別です。 名古屋市の案内では、消防のり災証明書は火災又は焼損事故があったことを消防署長が証明するもので、風水害・地震等の被災者支援に係る「罹災証明書」とは異なるとされています。同じ読み方の書類でも、証明している中身と発行者が違います。 種類を1つにまとめると、火災の請求に風水害の証明書が付いていても気づけません。

記録を残す

• 届いた書類の原本と、アップロードの日時・経路（提出画面／郵送のスキャン）
• Document AI が返した結果の全文（文字、手書きの情報、品質の点数、項目、表）
• Claude が返したJSONと、使った指示の版
• 関数が付けた印と、規則の版（必要書類の一覧の版を含む）
• 担当が受付票の案を直した記録 … どの項目を、何から何に変えたか
• 送った案内の文面と日時、契約者から追加の書類が届いた日時

最後の行は、案内の効き目を測る材料です。 撮り直しの案内から追加の書類が届くまでの日数を、「不足」と「撮り直し」に分けて数えます。