死亡保険金の請求で届く死亡診断書の写し・戸籍・請求書を読み取り、死亡日・死因の種類・受取人を査定の入力項目にそろえ、不足書類と食い違いを拾う

処理の起点を決める

書類が Cloud Storage の請求番号のフォルダに保存されたことを起点にします。 Cloud Run には、バケットでオブジェクトが作られたとき（google.cloud.storage.object.v1.finalized）に関数を呼び出す仕組みがあり、関数とバケットは同じプロジェクトに置く必要があります。

ただし、1ファイルごとに入力項目の案を作るわけではありません。 遺族は書類を何回かに分けて送ってきます。戸籍だけが先に届いた時点で「死亡診断書が不足」と案内すると、翌日届く書類と行き違います。 ファイルごとの読み取りは保存のたびに行い、入力項目の案と不足の判定は、Webの提出で「提出を完了する」が押されたとき、または郵送の書類をスキャンし終えて受付の担当が「受付完了」を押したときに行います。

経路で処理を分けません。 郵送とWebで別の流れにすると、どちらか一方だけ照合が抜ける期間ができます。受付の順番も経路によらず届いた日で並べます。

入力データを集める

質を決めるのは、必要書類の一覧です。 これが担当者の経験にしか無いと、不足の判定を規則にできません。自社の請求の案内に載っている必要書類を、請求の型ごとに表にしたもので十分です。

受取人が亡くなっている場合は、法定相続情報一覧図の写しが届くことがあります。 法務局の説明では、一覧図の写しは戸除籍謄本等の束の代わりに相続手続に使え、被相続人の死亡に起因する様々な手続に利用できるとされています。必要書類の一覧では、戸籍の束と一覧図の写しのどちらでも可とするように作ります。受け付けるかどうかは、自社の規程で決めます。

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

すべてのファイルを先に Enterprise Document OCR に通し、そのあと種類に応じて Form Parser にも通します。

欄の切り出しは、印刷された見出しの位置から行います。 OCRが返した「死因の種類」という文字の位置を起点に、様式の上で欄が占める範囲を切り出します。切り出した画像が200ピクセルを下回るときは、元の解像度から拡大して取り直します。 小さな画像では誤ることがあるとされているためです。

画像の品質の点数は既定では返りません。 enableImageQualityScores を有効にすると、OCRと同程度の処理時間が足されるとされています。死亡診断書と戸籍では有効にし、本人確認書類の写しでは切ります。

AIへ渡す前に整形する

1. 形式の確認 … PDF、GIF、TIFF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます。HEIC の写真は JPEG に変換します
2. サイズとページ数の確認 … オンライン処理は1ファイル40MBまで、Form Parser は15ページまでです。戸籍の束で超えるものはバッチ処理（Form Parser は100ページ、Enterprise Document OCR は500ページまで）に回します
3. 解像度の確認 … スキャンは200dpi以上が最低、300dpi以上が最適とされています。郵送の書類は300dpiでスキャンします
4. 画素数の確認 … 画像は1ページ4,000万画素までです。スマートフォンの写真で超えるものは縮小します
5. 向きの補正 … 縦書きの戸籍を横向きにスキャンしたものは、向きを直してから読ませます
6. ページの束ね … 複数ページで1つの戸籍のものは、ページの続き番号で束ねます

3番目と5番目を軽く見ないでください。 死亡診断書の写しは、遺族が役所でもらったものをさらにコピーしたものが多く、文字が薄くなっています。

AIに処理させる

「させないこと」の3行目がいちばん起きやすい失敗です。 ○がかすれて読めないと、AIは「死亡の原因」の欄に書かれた病名から「1 病死及び自然死」を選びがちです。その推測が当たっていても、欄に○が無かったという事実が消えます。 死亡診断書の記入マニュアルでは、病死か外因死か判断できない場合は「12 不詳の死」として扱うとされており、医師がどの番号を選んだかは、病名からは決められません。

指示内容を固定する

あなたは生命保険会社の保険金の請求の受付担当です。
死亡保険金の請求で届いた書類のOCR結果と、死亡診断書の「死因の種類」の欄の画像から、
査定の入力項目に値をそろえます。
書類に書かれていることだけを根拠にしてください。推測で埋めないでください。

【死因の種類の読み方】
- 画像の中で○で囲まれている番号を1つ答えてください（1〜12）。
- ○が2つ以上ある、○がどの番号にかかるか決められない、○が見えない場合は、
  番号を答えず status を ambiguous または unreadable にしてください。
- 「死亡の原因」の欄の病名から番号を推し量らないでください。

【死亡したとき】
- 年月日と時分を別々に取ってください。
- 「（推定）」「（確認）」と書き添えられていれば time_note に写してください。

【厳守事項】
- 記載がなければ value を空にし、status を missing にしてください。
- 品質の点数が0.5未満の領域から取った値は status を unreadable にしてください。
- 書類ごとの死亡日を1つにまとめないでください。書類ごとに別々に返してください。
- 標題で二重線が引かれている側を確かめ、死亡診断書か死体検案書かを返してください。
- 保険金の支払の可否、災害死亡保険金の対象かどうか、受取人を誰とするかは書かないでください。
- 各項目に、根拠にした書類のファイル名とページ、文字列をそのまま付けてください。

【契約の情報（被保険者・受取人）】{policy}
【請求の申告】{claim_declaration}
【OCR結果（ファイルごと、品質の点数付き）】{ocr_results}
【死因の種類の欄の画像】{cause_type_image}

「病名から番号を推し量らない」を名指しで書くのは、そこが最も推測の起きる欄だからです。 病名が書いてあれば病死だろう、と考えるのは自然ですが、マニュアルでは病死であっても損傷名を書いた場合は外因死の追加事項も書くとされるなど、病名と区分は一対一ではありません。

「書類ごとの死亡日を1つにまとめない」は、照合の材料を残すためです。 まとめさせると、どの書類の日付だったかが消えます。

出力形式を固定する

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

{
  "claim_id": "DC-2026-031877",
  "documents": [
    { "file": "scan_0003.pdf", "pages": [1], "doc_type": "death_certificate",
      "title_selected": "死亡診断書 | 死体検案書", "handwritten": true, "quality_score": 0.74 }
  ],
  "death_dates": [
    { "source_doc": "death_certificate", "date": "2026-09-12", "time": "04:30",
      "time_note": "（推定）", "status": "ok | missing | unreadable", "evidence": "" }
  ],
  "cause_type": { "number": "1", "status": "ok | ambiguous | unreadable", "evidence": "" },
  "insured": { "name": "", "birth_date": "", "source_docs": [] },
  "beneficiary": { "name": "", "relation": "", "source_doc": "claim_form", "evidence": "" }
}

1つ目の理由は、death_dates を書類ごとに並べられることです。 死亡診断書の死亡したとき、戸籍の死亡日、請求書の申告を同じ配列に入れ、照合は関数で行います。

2つ目は、cause_type を他の項目と分けて持てることです。 担当の確認の画面で、この項目だけは欄の画像を横に並べて表示します。

3つ目は、title_selected で死亡診断書と死体検案書を分けられることです。 記入マニュアルでは、標題は交付する書類の種別によってもう一方を二重の横線で消すとされています。どちらを求めるかは自社の規程で決め、ここでは読んだ事実だけを返します。

構造化出力では数値の範囲や文字数の制約は使えないとされているため、番号は文字列で受け、1〜12に入っているかは関数で確かめます。

関数が規則で付ける印は、次のとおりです。

システムへ連携する

入力項目は「案」として書き込み、確定は担当が行います。 確定された請求だけが査定の担当の一覧に出ます。案内も自動では送りません。 遺族への連絡は、言葉の選び方ひとつで受け取られ方が変わります。

人が確認する

1. 死因の種類を画像で確かめる … cause_review の有無にかかわらず、欄の画像と読み取った番号を並べて見ます
2. 印の付いた項目を見る … date_mismatch、insured_mismatch、beneficiary_check は根拠の画像を開いて確かめます
3. unreadable を確かめる … 担当が画像で読めるか、取り直しの案内が要るかを決めます
4. missing_doc を確かめる … 不足とされた書類が別のファイルに混ざっていないかを見ます
5. 確定し、案内を送る … 下書きを直して遺族に送り、請求を査定に回します

1件あたり9分を目安にします。 印の無い請求は死因の種類の確認と流し読みで数分、印のある請求は画像を開いて確かめるので10分を超えます。ならして9分です。

1番目を省かないでください。 外因死の区分が付いていれば、査定では特約の扱いを確かめることになります。読み違えた1件は、遺族への支払の額に直接かかわります。

例外に対処する

1行目は、この構成でいちばん大事な例外です。 ○が2つある死亡診断書は、医師が訂正した跡のこともあります。どちらが有効かを決めるのは、受付でもAIでもありません。

記録を残す

• 届いた書類の原本と、受付の日時・経路（郵送／Web）
• Document AI が返した結果の全文と、切り出した死因の種類の欄の画像
• Claude が返したJSONと、使った指示の版
• 関数が付けた印と、必要書類の一覧の版
• 担当が案を直した記録 … どの項目を、何から何に変えたか。死因の種類は特に別に記録する
• 送った案内の文面と日時、遺族から追加の書類が届いた日時

5つ目で死因の種類の直しを別に数えるのは、読み取りの精度をこの欄だけで測るためです。 直しが多いなら、切り出しの範囲か解像度を見直します。