医療保険の給付金請求に添付された領収証・診療明細書の写真を読み取り、入院日数と手術の査定入力を下書きし、不足書類を洗い出す

処理の起点を決める

15分おきの定時実行にします。 請求は日中に集中して届き、夜間はほとんどありません。1件ずつ即時に動かすより、請求ごとに画像がそろってから束ねて処理するほうが、書類の突き合わせが正しくできます。

請求者は、写真を何回かに分けて送ってくることがあります。請求の登録から一定の時間がたち、追加の画像が届いていないものだけを対象にします。 処理の途中で画像が増えた請求は、次の回に回します。

処理済みの印は、下書きまで作れたときだけ付け、途中で止まったものは次の回にやり直します。

入力データを集める

いちばん下の取扱いの規則を、先に文字にしておく必要があります。 「どの請求なら診断書が要らないか」「日数の初日と退院日をどう数えるか」は自社の約款と事務の規程で決まることで、規則が決まっていないと、スクリプトは判定を出せません。

被保険者のカナの氏名も欠かせません。 領収証の患者名は、医療機関によって漢字だったりカナだったりします。漢字だけで照合すると、同じ人が別人になります。

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

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

品質の結果は pages[].imageQualityScores に、qualityScore と detectedDefects（quality/defect_glare などの種類と信頼度）で返ります。信頼度が0.5を超えるものが、検出されたとみなされます。

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

表のセルには rowSpan と colSpan が付きます。 単純な表では常に1です。表が1つも返らなかったページ、または行の数が明らかに少ないページは、表として取れなかったとみなし、OCRの全文を生成AIに渡します。

郵送のスキャンは、最低200dpi、できれば300dpi以上で取ります。 Document AI の案内では200dpiが最低で、300dpi以上が一般に最も良い結果になるとされています。写真については、請求者の側の撮り方の案内で補います（第12章）。

AIへ渡す前に整形する

1. 形式をそろえる … Document AI が受け付ける画像は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などで、HEIC は対応形式に含まれていません。 スマートフォンの HEIC の写真は JPEG に変えます
2. むやみに圧縮しない … JPEG のような非可逆の形式でファイルを小さくすると、画像の品質と読み取りの精度が落ちるとされています。変換は1回だけにし、容量を減らすための再圧縮をしません
3. 請求ごとに束ねる … 1件の請求の画像を1つにまとめ、ページに提出の順番を付けます
4. ページ数を確かめる … 同期の処理は1回に15ページまでです。超える請求は分けて送ります
5. 同じ写真の重複を落とす … 請求者が同じ書類を2回撮っていることがあります。画像の近さで重複を見つけ、1枚だけを残します
6. 品質の足りないページを分ける … qualityScore が0.5を下回ったページは、不具合の種類とともに撮り直しの候補にし、Form Parser に送りません

6番目で送らないのは、読めないページから取り出した値を後段で使わないためです。 反射で白く飛んだ明細書から手術の行が取れなかったとき、それを「手術の記載なし」と扱うと、請求者に診断書を頼むことになります。

AIに処理させる

生成AIにさせるのは、書類ごとの種類の判定と、決まった項目の取り出しだけです。

表の右端が、この構成で大事な区別です。 missing は読めたうえで書かれていないこと、unreadable は品質の足りないページにあったか、値として確定できないことです。前者は追加書類、後者は撮り直しに回ります。

いちばん起きやすい失敗は、表の4行目です。 明細書の項目名は略された書き方のことがあり、生成AIはそれを分かりやすい手術名に直したがります。直した名前で査定者が判断すると、書類に書かれていない手術を見たことになります。

指示内容を固定する

あなたは生命保険会社の給付金請求の受付で、添付書類を読む担当です。
渡された読み取り結果だけを見て、書類ごとに項目を取り出してください。
判断や計算はしないでください。

【書類の種類】
- receipt_inpatient : 入院の領収証
- receipt_outpatient: 外来の領収証
- statement         : 診療明細書
- other             : それ以外（診察券、お薬手帳、請求書の控えなど）
other の書類からは項目を取り出さないでください。

【取り出す項目】
患者名、医療機関名、期間（初日と終わりの日）、発行日、
保険診療の負担額、保険外の負担額、手術の項目（明細書のみ）

【status の選び方】
- ok ......... 値が読み取れている
- missing .... 読み取り結果の中に、その項目が無い
- unreadable . その項目があるはずのページが「品質不足」と印の付いたページ、
               または文字はあるが値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ status を missing にしてください。推測で埋めないでください。
- 入院日数を数えないでください。期間の初日と終わりの日を、書かれたとおりに
  取り出すだけにしてください。
- 手術の項目名は、書かれた文字列をそのまま写してください。
  略された名前を一般的な手術名に言い換えないでください。
- 手術の区分に行が無ければ、手術の一覧を空にしてください。
  手術が無いと判断したとは書かないでください。
- 金額を足したり、税や負担割合から割り戻したりしないでください。
- 保険診療と保険外の負担額を1つにまとめないでください。
- 約款上の手術に当たるか、給付の対象か、支払えるかを書かないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- 日付は西暦（YYYY-MM-DD）に直してください。元の表記は evidence に残してください。

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

「手術が無いと判断したとは書かない」を入れているのは、空の一覧の意味を1つにするためです。 何も言わないと、生成AIは「手術は行われていません」と文にして返します。査定者がそれを読むと、書類の事実ではなく判断に見えます。 空の一覧は「明細書の手術の区分に行が無かった」という事実だけを表します。

日付を西暦に直させるのは、スクリプトが期間をつなぐためです。 和暦のままだと比べられません。元の表記を evidence に残させるので、直し方の誤りは査定者が見て分かります。

出力形式を固定する

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

{
  "claim_id": "",
  "documents": [
    {
      "page_refs": [1, 2],
      "doc_type": "receipt_inpatient | receipt_outpatient | statement | other",
      "fields": [
        { "item": "patient_name", "status": "ok | missing | unreadable | ambiguous",
          "value": "", "evidence": "" }
      ],
      "surgeries": [
        { "name": "", "date": "", "points": "", "evidence": "" }
      ]
    }
  ]
}

fields の item は patient_name ／ facility ／ period_from ／ period_to ／ issue_date ／ insured_share ／ non_insured_share です。

スキーマには enum と required を使います。 doc_type と status は enum で値を固定し、fields の要素には item と status を required にします。ただし、構文として正しいJSONが返っても、値はアプリケーションの側で確かめるよう案内されています。 スクリプトは、日付として解釈できるか、金額が数字か、page_refs が実在するページかを確かめます。

JSONを受け取ったあと、スクリプトが請求ごとの判定を足します。

{
  "claim_id": "",
  "admission": {
    "periods": [ { "from": "", "to": "", "doc": 0 } ],
    "gaps": [ { "from": "", "to": "" } ],
    "days_by_rule": 0
  },
  "patient_match": "matched | kana_only | mismatch",
  "retake_pages": [ { "page": 0, "defects": [] } ],
  "missing_docs": [],
  "verdict": "ready | needs_retake | needs_docs | needs_human"
}

status と verdict を別の層に置いているのが要点です。 取り出しは生成AI、判定は規則です。取扱いの規則が変わっても、直すのはスクリプトの条件だけです。

システムへ連携する

査定システムへは、下書きとして渡すだけです。 期間、日数、手術の項目、負担額を、担当者が確認する画面に入れた状態にします。担当者が確認して登録するまで、査定の対象にはなりません。

Document AI の地域は、個人の医療情報を置いてよい場所を社内で決めてから選びます。 対応地域は asia-southeast1 や us、eu などで、どこで処理するかは、請求書類の取扱いの規程と合わせて決めます。

人が確認する

担当者は全件の下書きを見ますが、見る場所を絞ります。

1. verdict で順番を決める … needs_human を先に、ready を最後に見ます
2. retake_pages の写真を見る … 不具合の種類（反射、ぼけ、切れ）を確かめ、撮り直しの依頼を送ります
3. gaps の期間を確かめる … 抜けている期間の領収証が、別のページに写っていないかを画像で見ます
4. 手術の項目の evidence を読む … 項目名が書類のとおりに写されているかを、画像の該当箇所で確かめます
5. 下書きを登録する … 直したところがあれば記録します

4番目を省かないでください。 手術の項目名は、査定者が約款の手術に当たるかを判断する材料そのものです。写し間違いや言い換えは、そのまま査定の誤りになります。

ready の請求も、画像を1回は開きます。 見るのは、期間と手術の項目の根拠だけです。全件を最初から読み直す設計にすると、第10章の4分には収まりません。

例外に対処する

上から2行目が、件数としていちばん多くなります。 スマートフォンの写真の反射と端の切れは、AIの問題ではなく撮り方の問題です。 不具合の種類が分かるので、撮り直しの依頼に「照明が反射しています」「右端が切れています」と具体的に書けます。

記録を残す

• 請求番号と、受け取った画像の原本、変換後の画像
• Document AI が返した結果の全文（品質スコア、欄の名前と値、表）
• 生成AIに渡した読み取り結果と、返ったJSON
• スクリプトが足した判定（期間のつながり、日数、照合、verdict）と、そのとき使った取扱いの規則の版
• 担当者が直した項目と、直す前と後の値
• 撮り直しと追加書類の依頼を送った日時と、その後に届いた書類
• 不具合の種類ごとの撮り直しの件数

規則の版を残すのは、日数の数え方が後から変わりうるためです。 数え方を変えたあとに過去の請求を見直すとき、当時の規則が残っていないと、どの請求をやり直すかが決まりません。

最後の件数は、請求者への撮り方の案内を直す材料になります。 反射が多ければ照明の、端の切れが多ければ枠に収める案内を足します。