海外旅行保険の請求に添付された英文の診断書・領収書を読み取り、査定に回す前に不足と記載漏れを洗い出す

処理の起点を決める

請求受付システムを15分おきに見に行き、新しい請求を取り込みます。 添付が後から足されることがあるので、フォームの送信から30分たったものだけを対象にします。

処理の単位は請求1件の書類一式です。 書類ごとに判定すると、「領収書が無い」と「領収書は別のファイルにある」を区別できません。点検の結果が出た請求だけを処理済みにし、途中で止まったものは次の回に拾い直します。

入力データを集める

質を決めるのは、必要書類の表です。 「治療費用の請求には診断書・請求明細・領収書が要る」「キャッシュレスで医療機関から直接請求が来ている場合は領収書を求めない」といった取り決めを、担当者の頭の中から表へ移します。

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

診断書は、AnalyzeDocument に問い合わせを付けて呼びます。 問い合わせは QueriesConfig に Text（問い）と Alias（呼び名）の組で並べます。

問い合わせは1ページあたり同期処理で15件、非同期処理で30件までです。 入院日・退院日などを足すときは数を数えます。

署名は SIGNATURES で位置を受け取ります。 返るのは署名らしきものの位置で、誰の署名か、本物かは分かりません。 確かめるのは「署名欄に署名がある」ことだけです。

請求明細と領収書は AnalyzeExpense に渡します。 医療機関名は VENDOR_NAME、宛名は RECEIVER_NAME、日付は INVOICE_RECEIPT_DATE、合計・支払額・未払額は TOTAL・AMOUNT_PAID・AMOUNT_DUE、明細は EXPENSE_ROW という標準の項目名で、信頼度付きで返ります。

複数ページの請求明細には注意が要ります。 非同期の分析は各ページを別々の請求書・領収書として扱い、ページをまたいだ文脈を保ちません。 合計は最後のページにだけ出るので、スクリプトでページを束ねて1つの書類として扱います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のいずれかであることを確かめます。iPhone の写真で多いHEICは、JPEGに変換してから送ります
2. パスワードの確認 … パスワードで保護されたPDFは受け付けられません。解除できないものは、請求者へ解除したものを頼みます
3. XFA形式の確認 … XFA形式のPDFには対応していません。印刷用のPDFに書き出し直します
4. ページ数とサイズの確認 … 同期処理はPDFとTIFFが1ページ・10MBまで、非同期処理はPDFとTIFFが3,000ページ・500MBまでです。複数ページのものは非同期処理に回します
5. 画像の寸法と文字の大きさの確認 … 画像はどの辺も10,000ピクセル以下で、検出できる文字の高さは最小15ピクセル（150DPIで約8ポイント）です。下回るものは撮り直しを頼む候補にします
6. 1ファイルに複数の書類がないかの確認 … 診断書と明細が1つのPDFに入っているものは、ページで分けて種類を判定します

5番目を軽く見ないでください。 スマートフォンで全体を1枚に収めた診断書は文字が小さく写り、「記載が無い」と見分けがつきません。

AIに処理させる

させるのは、書類の種類を決めることと、必要な記載事項ごとに「値が読み取れているか」を判定し、根拠にした文字列を書き出すことだけです。

missing と unreadable を分ける根拠は数値に置きます。 問い合わせの答えが空なら missing、答えはあるが信頼度が基準値より低ければ unreadable です。

日付の順は間違えやすい所です。 03/04/2026 は米国の書式なら3月4日、英国などなら4月3日です。同じ書類の中の他の日付で順が決まらなければ ambiguous にします。

4行目がいちばん起きやすい失敗です。 請求フォームの被保険者名を一緒に渡すと、読み違えた綴りをフォームに合わせて「直して」返します。 だから、AIには請求フォームの氏名を渡しません。

指示内容を固定する

あなたは損害保険会社の保険金請求の受付で、海外の医療機関が発行した
英文の書類がそろっているかを点検する立場です。
OCRが返した読み取り結果だけを見て判定してください。推測で埋めないでください。

【まず書類の種類を決める】
- medical_certificate … 医師が診断名・治療内容を記載した書類
- itemized_bill ....... 治療の明細と金額が並んだ請求書
- receipt ............. 支払ったことを示す領収書
- other ............... 上のどれでもない（紹介状、処方箋、航空券など）
複数に当てはまるときは、当てはまるものをすべて document_types に入れてください。

【点検する項目】
medical_certificate：patient_name, visit_date, diagnosis, treatment,
  physician_name, physician_signature, hospital_name, issue_date
itemized_bill：patient_name, hospital_name, service_date, line_items, total, currency
receipt：patient_name, hospital_name, payment_date, amount_paid, currency

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- missing .... 値が無い。項目名の欄だけがあって値が空の場合も missing
- unreadable . 文字は検出されているが、信頼度が基準値 {threshold} を下回る
- ambiguous .. 値の候補が複数ある、または日付の日と月の順が決まらない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ「不明」とし、status を missing にしてください。
  他の書類や他の項目から補って埋めないでください。
- 綴りを直さないでください。読み取った文字列をそのまま value に入れてください。
- 金額を計算しないでください。合計や支払額が無いときに、明細から足し上げないでください。
- 通貨を換算しないでください。書かれている記号や通貨コードをそのまま写してください。
- 日付は、同じ書類の中で日と月の順が確定できるときだけ YYYY-MM-DD に直してください。
  確定できなければ、書かれたとおりの文字列を value に入れ、ambiguous にしてください。
- physician_signature は、署名の検出結果がその書類のページにあるときだけ ok です。
  医師名が印字されていることを、署名があることとして扱わないでください。
- 補償の対象か、支払うべきか、治療が必要だったかは書かないでください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- confidence は OCR が返した値をそのまま入れてください。

【読み取り結果】{textract_result}
【信頼度の基準値】{threshold}

「綴りを直さない」を明記しないと、照合が意味を失います。 OCRが「TANAKA HIROSI」と読むと、AIは「HIROSHI」に直したくなります。直した瞬間に、読み違いか書き間違いかが分からなくなります。 医師名の印字を署名として扱わせないのも同じ理由で、署名の有無は Textract の署名の検出という別の事実で決めます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 output_config.format に type: "json_schema" とスキーマを渡し、オブジェクトには additionalProperties: false を付けます。

{
  "claim_id": "",
  "documents": [
    {
      "file": "",
      "pages": [1, 2],
      "document_types": ["medical_certificate"],
      "checks": [
        { "item": "patient_name", "status": "ok | missing | unreadable | ambiguous",
          "value": "", "confidence": 0, "evidence": "" }
      ]
    }
  ]
}

AIの出力とは別に、スクリプトが突合の結果と判定を持ちます。

1つ目の理由は、AIの判定と規則の判定を別の層に置けることです。 checks はAIが埋め、verdict はスクリプトが表で決めるので、取り決めが変わっても直すのは表だけです。

2つ目は、不足を一度に全部出せることです。 3種類の書類の missing をまとめて依頼文にするので、「診断書をください」の後に「署名がありません」を送る往復が減ります。

システムへ連携する

非同期処理の完了は、通知で受け取ります。 Textract は完了を Amazon SNS のトピックへ知らせ、それを Amazon SQS か AWS Lambda で受けます。Get の操作を繰り返し呼んで完了を待つことは推奨されていません。

査定システムへは書き込まず、依頼文も自動では送りません。 書き込みを足すと、unreadable を見落とした請求がそのまま査定に進む経路ができます。

人が確認する

人が開くのは needs_documents と needs_human のものだけです。 ready のものは一覧で件数と請求者を流し見て査定へ回します。全件を開く設計にすると、第10章の60.0時間には収まりません。

1. language_check が suspect のものを先に見る … 英語以外なら翻訳の手配へ。請求者に依頼を出してはいけない書類です
2. needs_human の根拠を見る … unreadable は画像で読み、ambiguous の日付は他の書類と見比べます。mismatch は読み違いか本当の食い違いかを見分けます
3. needs_documents の依頼文を確かめる … missing の項目が本当に空欄かを画像で確かめてから送ります
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

3番目を省かないでください。 請求者は海外の医療機関に書類を頼み直すことになり、空振りの依頼1件は長く印象に残ります。

Textract の人の確認の仕組み（Amazon Augmented AI）は新規の利用者を受け付けていないため、確認は既存の画面の側に作ります。

例外に対処する

上の2行は Textract が読める範囲の外で起きます。 判定の側で無理に扱いません。

記録を残す

• 元の添付ファイルと、受け取った日時
• Textract が返した結果の全文と、使った問い合わせの一覧
• AIに渡した内容と、返ってきたJSONの全文
• 突合の結果と verdict、そのとき使った必要書類の表の版
• 人が判定を覆した記録 … どの書類のどの項目を、どちらに変えたか
• 医療機関ごとの unreadable と suspect の発生率

「表の版」を残すのは、取り決めが後から変わるためです。 当時の表が無いと、過去の判定を説明できません。最後の行は、特定の国で読めない書類が続くとき、帰国前に英文の書類をもらうよう案内に書き足す材料になります。