海外旅行保険の請求で届く英文の病院の明細書（itemized bill）を読み取り、診療項目・日付・金額を支払査定の表に起こす

処理の起点を決める

請求の管理システムに明細書が登録されたことを起点にします。 受付の担当者が書類の種類を「明細書」として登録すると、画像が Amazon S3 に保存され、その保存を AWS Lambda が受けます。1日1回の定時実行にはしません。 請求が重なる時期ほど、登録した順に下書きができていくほうが、打ち込みの順番待ちがなくなります。

種類の振り分けを人の受付に残しているのは、明細書と領収書と診断書が1つのPDFにまとめて出されることが多いからです。 振り分けを誤ると、診断書を明細として読もうとします。

Lambda は StartExpenseAnalysis を呼びます。ClientRequestToken に請求番号とファイルのハッシュから作った値を入れると、同じ画像を二度登録しても同じ JobId が返り、二重に読みません。 完了は Amazon SNS に届き、SUCCEEDED を確かめてから GetExpenseAnalysis で結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。

入力データを集める

質を決めるのは、渡航期間と過去の明細です。 渡航期間が無ければ日付の確認ができず、過去の明細が無ければ、同じ明細の二重の請求を見つけられません。

行の種類の語の一覧は、運用しながら育てます。 病院ごとに書き方が違うので、担当者が新しい語を見つけたら足します。

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

明細書は StartExpenseAnalysis で非同期に読みます。扱える形式は JPEG、PNG、PDF です。 結果は GetExpenseAnalysis で取ります。1回に返る件数は既定で最大20件なので、NextToken が返る限り続けて取ります。状態が PARTIAL_SUCCESS のときは、警告の出たページを記録して人に回します。

診療日は標準の名前にありません。 公式の説明では、標準の分類に当たらない欄は OTHER になります。診療日の列は行全体（EXPENSE_ROW）の文字から生成AIに切り出させます。

明細の表が複数あるときは、LineItemGroupIndex で分かれて返ります。 入院の明細では、室料、薬剤、検査が別々の表になっていることがあります。どの表の行かを group として残し、表ごとの小計と照らせるようにします。 表をまたいで行を並べ直すと、表の小計との照合ができなくなります。

元の見出し（LabelDetection）を必ず残します。 TOTAL に当たった欄が、明細書では「Total Charges」なのか「Balance Due」なのかで意味が違います。前者は治療の合計、後者は支払・調整を引いた残りです。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF であることを確かめます。TIFF などはPDFに変換します
2. パスワードの確認 … パスワードで保護されたPDFは読めません。契約者に保護の無いものを頼みます
3. ページの確認 … 「Page 1 of 3」のような表示があれば、ページがそろっているかを見ます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。スマートフォンで撮った明細は、文字が小さく写りやすいので、受付の段階で撮り直しを頼みます
5. 書類の数の確認 … ExpenseIndex で複数の明細書が入っていれば、明細書ごとに分けて扱います
6. 重複の確認 … 同じ請求番号・同じファイルのものが既にあれば止めます
7. 患者の確認 … 要約の欄の患者名・受取人名を、請求の被保険者の氏名と照らします。家族の明細が混ざって出されることがあるので、違えばその明細書を止めて受付に戻します

4番目を軽く見ないでください。 明細の金額の列は細かい文字で並んでいます。読めないだけの行が、明細に無い行と同じに見えると、合計が合わない理由が分からなくなります。

AIに処理させる

させるのは、行ごとの値を査定の表の形にそろえ、行の種類を分け、根拠の文字列を添えることだけです。

行の種類の仕分けが、いちばん手間を減らすところです。 「Ins Pmt」「Contractual Adj」のような略語の行を、payment や adjustment に分けます。根拠にした文字を必ず添えさせ、行の種類の語の一覧と照らせるようにします。

5行目がいちばん起きやすい失敗です。 入院の明細では、日付が日の最初の行にだけ書かれることがあります。AIは前の行の日付で埋めたくなりますが、埋めると、日付の書かれていない行と書かれた行の区別が消えます。 埋めるかどうかは規則の側で決めます。

指示内容を固定する

あなたは保険金の請求の受付で、海外の病院の英文の明細書を
支払査定の表に起こす担当です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【行ごとに取り出す項目】
1. 診療日（行全体の文字に書かれている日付。書かれている形のまま）
2. 項目名と、行に書かれたコード
3. 数量、単価、金額、通貨（マイナスやかっこ書きもそのまま）
4. 行の種類（charge／payment／adjustment／balance）
5. 項目の大まかな区分（consultation／lab／imaging／drug／procedure／room／other）

【status の選び方】
- ok ......... 値が読み取れており、その欄の値として解釈できる
- not_found .. その行にその値が無い
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 金額を計算しないでください。合計や差額を書かないでください。
- 通貨を換算しないでください。書かれている通貨のまま写してください。
- 日付の無い行に、前後の行の日付を入れないでください。not_found にしてください。
- 項目名とコードは原文のまま写してください。略語を言い換えないでください。
  日本語の説明は note_ja にだけ書いてください。
- 支払・割引・調整・残高の行を charge にしないでください。
  見分けた根拠の語を type_evidence に写してください。
- 補償の対象か、治療が妥当かは書かないでください。
- 明細書でない書類（診断書、領収書だけのもの）と判断した場合は、
  行を作らず document_type に種類を書いてください。

【読み取り結果（明細の行と要約の欄）】{expense_result}
【支払・調整の行に使われる語の一覧】{type_terms}

「支払・調整の行を charge にしない」を明記しないと、マイナスの金額も治療の行に入ります。 AIは表の行をすべて「明細の行」と見るからです。根拠の語を写させると、担当者が一覧で誤りに気づけます。

「日付を入れない」も同じ理由です。 書かれていない日付を埋めると、渡航期間の確認が、埋めた日付で行われます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "claim_no": "",
  "document_type": "itemized_bill | other",
  "provider_name": "",
  "patient_name": "",
  "currency": "",
  "lines": [
    { "row": 1, "group": 0, "service_date": "", "description": "", "code": "",
      "quantity": "", "unit_price": "", "amount": "",
      "line_type": "charge | payment | adjustment | balance",
      "type_evidence": "", "category": "", "status": "ok | not_found | unreadable | ambiguous",
      "note_ja": "" }
  ],
  "summary": { "total_label": "", "total": "", "amount_paid": "", "amount_due": "" }
}

1つ目の理由は、合計の照合をプログラムで行えることです。 line_type が charge の行の amount を足し、summary の合計と比べます。total_label を見て、治療の合計と比べるのか、残りと比べるのかを分けます。

2つ目は、査定の表にそのまま流せることです。 行の列が査定の表の列と1対1なので、担当者は打ち込まずに、印の付いた行を直すだけで済みます。

1行目と2行目を分けているのは、合わない理由が違うからです。 1行目が合わなければ読み取りの誤り、2行目だけが合わなければ、明細書の外の事情（別の支払、前回の繰越）があるということです。

システムへ連携する

査定の表には、下書きとして書き出します。 確定は担当者が行い、確定した表だけが査定の担当者に回ります。 支払の処理には一切つなぎません。

人が確認する

担当者が見るのは、下書きの表と明細書の画像を並べた画面です。 印の無い行は流し見て、印の付いた行と合計の照合の結果だけを確かめます。

1. 合計が合わない請求を先に見る … 読み取りの誤りか、明細書の外の事情かを画像で確かめます
2. 行の種類を確かめる … payment・adjustment の行が本当にそうかを、type_evidence で見ます
3. 渡航期間外・重複の印を確かめる … 日付の読み違いでないかを画像で見ます
4. 表を確定する … 直した行には、直したことを残します

2番目を省かないでください。 支払の行を治療の行に入れたままにすると、現地の保険で支払済みの金額まで保険金として査定に回ります。

目標は、300件をならして1件6分です。 数行の明細は合計の照合を見るだけで終わり、入院の明細は印の付いた行を見ます。6分を超える月は、撮り方の悪い明細が増えているか、行の種類の語の一覧が追いついていません。

入院の明細のように行の多い請求は、合計が合っていれば、印の付いた行だけを見ます。 合計が合っているのに個々の行がずれていることは、行の値を読み違えたうえで合計が偶然合う場合だけで、まれです。

例外に対処する

最後の行は、この構成が止まっても業務が止まらないためのものです。 読み取りに失敗した請求は、従来の打ち込みの手順にそのまま戻します。

記録を残す

• 元の明細書の画像と、受け取った日時・請求番号
• Textract が返したJSONの全文と、JobId・状態・警告
• 生成AIの出力（lines、summary）
• 照合の結果と、そのとき参照した渡航期間・領収書の金額
• 担当者が直した行と、直す前の値
• 行の種類の語の一覧の版
• 合計の照合が合わなかった請求と、その理由（読み取りの誤り／明細書の外の事情）

5つ目は、読み取りの弱いところを見つけるために残します。 どの病院の、どの列で直しが多いかが分かれば、行の種類の語の一覧や受付での撮り直しの頼み方を直せます。