外国人の入居希望者から届く英文の在職証明書・給与明細・残高証明書を読み取り、入居審査シートへ転記して申込書との食い違いを拾う

処理の起点を決める

受付フォルダ（Amazon S3）に書類が保存されたことを起点にします。 Webフォームの申込が送信されると、添付ファイルが申込番号の名前のフォルダに入り、その保存の通知で AWS Lambda が動きます。

1日1回の定時実行にはしません。 同じ部屋に別の申込が入る前に審査へ回せるかどうかが、そのまま成約に響くからです。

書類は後から足されることがあります。 申込番号のフォルダに書類が足されるたびに、その申込の判定をやり直し、前の判定は版として残します。

入力データを集める

質を決めるのは、いちばん下の行です。 基準が無いと、同じ書類が担当者によって食い違いになったり、ならなかったりします。

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

読み取りは、StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問は非同期で1ページ30件まで使えますが、在職証明書には次の9件で足ります。

答えが見つからないとき、その答えは空のまま返ります。 公式の説明でも、答えが見つからなければ応答の要素は空のまま残るとされています。空の答えを「書かれていない」と扱い、別の項目から埋めません。

結果は1回最大1,000ブロックで区切られます。 NextToken が返る限り呼び直し、後半のページが抜けないようにします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。HEIC の写真は JPEG に変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。銀行の残高証明書は保護されて届くことが多く、申込者に解除したものを出し直してもらいます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページ、JPEGとPNGは10MBまでです
4. 写真の向きと解像度の確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。机の上で斜めに撮った給与明細は、小さい数字から読めなくなります
5. 1ファイルに複数の書類がないかの確認 … 在職証明書と給与明細が1つのPDFにまとまっていれば、ページごとに種類を分けてから扱います
6. 個人の番号の伏せ字 … 口座番号、社会保障番号などの国民識別番号、従業員番号は、生成AIへ渡す前に下4桁以外を伏せます

2番目がいちばん多い差し戻しの理由になります。 受付画面で「パスワードの付いたPDFは読めません」と最初から案内しておくと、出し直しの往復が1回減ります。

AIに処理させる

させるのは、読み取り結果を書類の種類ごとに審査シートの項目へそろえ、日付と金額を「読んだ文字列」と「解釈した値」に分けて書き出すことです。 比較と判定はさせません。

日付は、読んだ文字列をそのまま残し、解釈は次の場合だけ行います。 月の名前が書かれている（4 March 2025）、年・月・日の順の数字（2025-03-04）、日か月のどちらかが13以上で順序が決まる（25/03/2025）。それ以外の 03/04/2025 は ambiguous とし、どちらの日付も入れません。 勤務先の国から順序を推し量ることもさせません。

金額も同じです。 85,000 に通貨記号も通貨の略称も無ければ通貨は unknown、per annum や monthly の記載が無ければ期間は unknown にします。年額か月額かを、金額の大きさから推し量らせません。

いちばん起きやすい失敗は最後の行です。 給与明細の月額を12倍して在職証明書の年収欄を埋めると、「年収が書かれていない」という確認点が消えます。

指示内容を固定する

あなたは賃貸の申込受付で、入居希望者が提出した英文の書類を
入居審査シートの項目にそろえる担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【書類の種類】
employment_letter / payslip / bank_statement / offer_letter / other
のどれか1つを document_type に入れてください。

【取り出す項目】
書類の種類ごとに、指定の項目を fields に入れてください。
各項目には raw（読んだ文字列そのまま）、value（解釈した値）、
status、source（読み取り結果のどこから取ったか）を入れます。

【status の選び方】
- ok ......... 値が読み取れ、その項目として解釈できる
- missing .... 書類に書かれていない。質問の答えが空の場合も missing
- ambiguous .. 読み方が複数あり、1つに決められない
- unreadable . 文字は検出されているが信頼度が低く、確定できない
迷ったときに ok を選ばないでください。

【日付の扱い】
- raw には書類の文字列をそのまま入れてください。
- 月の名前がある、年・月・日の順である、日または月の一方が13以上で
  順序が決まる、のどれかのときだけ value に YYYY-MM-DD を入れてください。
- それ以外（例：03/04/2025）は status を ambiguous とし、value は空にしてください。
  勤務先の国や書類の書式から順序を推し量らないでください。

【金額の扱い】
- 通貨記号または通貨の略称が書かれていなければ currency は unknown です。
- annual / per annum / monthly / per month などの記載が無ければ
  period は unknown です。金額の大きさから年額か月額かを決めないでください。
- 換算や合計の計算をしないでください。
- 総支給（gross）と手取り（net）を取り違えないでください。
  区別が書かれていなければ ambiguous にしてください。

【厳守事項】
- 書かれていない項目を、別の書類の値や計算で埋めないでください。
- 入居の可否、収入が足りるかどうか、申込書と合っているかを書かないでください。
- 国籍、出身国、在留資格について、評価や推測を書かないでください。
- 伏せ字（****）になっている番号を復元しないでください。
- 英文の書類でないと判断した場合は document_type を other とし、
  項目を取り出さないでください。
- inquiry_draft には、missing と ambiguous の項目について
  申込者に確かめる英文の文案を、丁寧な表現で書いてください。
  審査の結果や見込みには触れないでください。

【読み取り結果】{textract_result}
【申込番号】{application_id}

「金額の大きさから年額か月額かを決めない」を明記しないと、もっともらしく決めます。 85,000 を見れば年額と書き、7,000 を見れば月額と書きます。多くの場合は当たりますが、当たらなかった1件が年収を12倍にします。 禁じるのは、推し量ること自体です。

「審査の結果や見込みに触れない」は、下書きがそのまま送られる場面への備えです。

出力形式を固定する

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

{
  "application_id": "",
  "documents": [
    {
      "file": "",
      "document_type": "employment_letter | payslip | bank_statement | offer_letter | other",
      "fields": [
        { "name": "start_date", "raw": "03/04/2021", "value": "",
          "status": "ok | missing | ambiguous | unreadable",
          "source": "QUERY:START_DATE", "confidence": 0 }
      ],
      "salary": { "raw": "", "amount": "", "currency": "", "period": "annual | monthly | hourly | unknown" }
    }
  ],
  "inquiry_draft": ""
}

1つ目の理由は、raw と value を分けて持てることです。 営業担当が確かめるとき、value が空で raw に 03/04/2021 とあれば、何が曖昧なのかが画像を開く前に分かります。 申込者への問い合わせも、その文字列を引用して書けます。

2つ目は、比較を Python の側に置けることです。 AIが返すのは項目の値までで、比較の結果はこのJSONに入れません。Python が換算表と申込書の値を使って、項目ごとに次の印を付けます。

勤務先名の比較は、表記ゆれの一覧を通してから行います。 Ltd. と Limited、K.K. と 株式会社、日本法人と本国の親会社。一覧に無い組み合わせは mismatch にして人に見せ、確かめたら一覧に足します。

3つ目は、source で根拠をたどれることです。 QUERY:START_DATE なら質問への答え、FORMS:Date of Joining ならキーと値から取った値です。

システムへ連携する

審査シートには「下書き」の列にだけ書き込みます。 確定の列は、営業担当が確認して写すか、確認済みの印を付けたときに埋まるようにします。読み取りの結果が、確認を経ずに保証会社へ流れる経路を作りません。

人が確認する

営業担当が開くのは、mismatch、ambiguous、missing_doc、stale_doc の付いた項目です。 match の項目は、根拠の文字列と並べた一覧で流し見ます。

1. ambiguous を先に片付ける … 日付の順序や通貨が決まらないものは、書類の他の箇所（レターヘッドの住所、別の日付の書き方）で決まることが多いです。決まらなければ申込者に確かめます
2. mismatch の根拠を確かめる … 画像の該当箇所を見て、読み取りの誤りか、申込書の書き間違いか、本当の食い違いかを分けます
3. 申込者へ問い合わせる … 下書きを直して送ります。送信は営業担当が行います
4. 判定を覆したら記録する … どの項目を、どちらに変えたか。勤務先の表記ゆれなら一覧に足します

目標は、160件をならして1件12分です。 印の付く項目が1件に2〜3個という想定で、それより多い月は、換算表か表記ゆれの一覧が足りていません。

例外に対処する

上から2行目は、申込を受けた時点で分かります。 申込時に選んでもらった書類の言語が6言語以外なら、最初から営業担当の手作業の列に入れます。

記録を残す

• 元の書類ファイルと、受け取った日時、申込番号
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（raw、value、status、source）
• Python の比較の結果と、そのとき使った換算表の版と書類の日付の基準
• 営業担当が判定を覆した記録 … どの項目を、どちらに変えたか
• 申込者への問い合わせと回答の記録

換算表の版を残すのは、率が月ごとに変わるためです。 当時の率が残っていないと、判定の理由を説明できません。