英文の居住者証明書を読み取り、名義・居住国・作成日を支払先台帳と照らして、租税条約の軽減が使えない支払を毎月の支払前に拾う

処理の起点を決める

起点は2つあります。証明書が届いたときと、支払予定表が固まったときです。

1つ目は、受付フォルダ（Amazon S3）に居住者証明書が保存されたことです。保存の通知で AWS Lambda が動き、読み取りと項目の取り出しまでを済ませて、支払先台帳とは別の「証明書の記録」に書き込みます。届いた時点で読んでおくので、支払の直前に読み取りが集中しません。

2つ目は、毎月の支払予定表が固まったことです。支払日の10営業日前に支払予定表を確定し、その確定の通知で照合が動きます。10営業日前にするのは、取り直しの依頼に相手国の当局の発行の時間を残すためです。 届出書等を支払を受ける日の前日までに出していなければ国内法の税率で源泉徴収することになるので、照合は支払日から逆算して早めに置きます。

さらに、月初に「作成日から10か月を過ぎた証明書」の一覧を出します。 支払が無い月でも、次の提示に備えて取り直しを早めに頼めるようにするためです。

入力データを集める

質を決めるのは、名義の別名の一覧です。 一覧が無いと、ABC Brands Inc. と ABC Brands, Incorporated を別人と判定するか、逆に ABC Holdings Inc. まで同じ者と寄せてしまいます。一覧にある書き方だけを同じ者とし、無いものは人に見せます。

台帳の「原本の添付か提示か」の列も欠かせません。 提示を受けた場合は、確認した旨・確認者・確認日・証明書の作成年月日を届出書に記載し、写しを5年間保存する必要があるとされています。どちらの扱いかで、後段の照合と保存の手順が変わります。

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

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

質問の答えが見つからなければ空のまま返ります。 作成日が空なら、全文から Date、Issued、Dated を含む行を探し、それでも無ければ missing にします。作成日の無い証明書を、受け取った日やPDFの作成日で埋めません。

同期の処理はPDF1ページまでです。 証明書の本体は1ページでも、送付状や翻訳が付いて数ページになるので、非同期で読みます。結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。

支払予定表は会計システムからCSVで出し、支払先台帳とあわせて Python が読みます。 生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。メール本文に貼られた画像は、PDFにして入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは支払先に解除を頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. スキャンの解像度の確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。郵送の原本をスキャンするときは、印影や透かしに重なった日付が下回りやすい箇所です
5. 言語の確認 … 6言語に入らない証明書は読み取りに回さず、担当者が目で見る一覧に入れます
6. 支払先の特定 … ファイル名の支払先コードを台帳で引き、条約と様式、特典条項の対象かを取り出します

5番目は、受付の時点で支払先台帳の所在国から先に分けておけます。 所在国が6言語の国でなくても英語の証明書が出ることはあるので、国で弾くのではなく、読み取って英字がほとんど出ないものを人に回します。

AIに処理させる

させるのは、証明書から6つの項目を取り出し、原文の文字列と、日付や国名の解釈を分けて書き出すことです。 照合はさせません。

作成日の原文を残すのは、日と月の順序が国で違うためです。 03/04/2026 は3月4日にも4月3日にも読めます。1年の判定は1か月の違いで結果が変わるので、順序が決まらない日付は解釈させず人に見せます。 発行機関の国の慣行から推測することもさせません。

対象の年と作成日を取り違えないことも大事です。 「2025年の課税年度について居住者であることを証明する」証明書が2026年に作成されることは普通にあります。1年の判定に使うのは作成日で、対象の年ではありません。

最後の行が、いちばん起きやすい失敗です。 作成日が書かれていない、または読めない証明書で、メールの受信日やPDFのプロパティの日付を作成日として埋めると、何年も前の証明書が「作成から1か月」に見えます。

指示内容を固定する

あなたは商社の経理部で、海外の支払先から届いた英文の居住者証明書の
記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
taxpayer_name_raw、taxpayer_address_raw、residence_country_raw、
residence_country_code、tax_period_raw、tax_period_start、tax_period_end、
issue_date_raw、issue_date、issuing_authority_raw、signature_or_seal、
各項目の status と source（ページと行）

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- not_stated ... 対象の年・期間が書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数ある、または日付の順序が決まらない

【厳守事項】
- 名義は書かれた文字列をそのまま入れてください。略記を補ったり、
  台帳の名称に書き換えたりしないでください。
- issue_date は、日と月の順序が文面から確定できるときだけ
  YYYY-MM-DD で入れてください。決まらなければ空にし、
  status を ambiguous にしてください。
- 作成日が書かれていない場合は missing にしてください。
  メールの日付、ファイルの日付、対象の年から補わないでください。
- 対象の年（tax year）と作成日（date of issue）を混同しないでください。
- 軽減を受けられるか、条約の要件を満たすかを書かないでください。
- 居住者証明書でない書類（送付状、翻訳、請求書など）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_and_queries}
【この支払先の台帳上の所在国】{ledger_country}

「台帳の名称に書き換えない」を明記しないと、書き換えます。 台帳の所在国や名称を一緒に渡すと、近い名義を台帳の表記にそろえて返し、その瞬間に名義の食い違いが見えなくなります。 台帳の名称そのものは渡さず、所在国だけを渡しているのもそのためです。

出力形式を固定する

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

{
  "file": "",
  "payee_code": "",
  "document_type": "residence_certificate",
  "taxpayer_name_raw": "ABC Brands, Incorporated",
  "residence_country_raw": "United States of America",
  "residence_country_code": "US",
  "tax_period_raw": "calendar year 2025",
  "issue_date_raw": "March 4, 2026",
  "issue_date": "2026-03-04",
  "issuing_authority_raw": "",
  "signature_or_seal": "present",
  "items": [
    { "item": "issue_date", "status": "ok", "confidence": 0, "source": "p1:L12" }
  ],
  "request_draft": ""
}

1つ目の理由は、照合をプログラムの側に置けることです。 Python が支払予定表の支払ごとに、台帳とこの記録を突き合わせて印を付けます。

2つ目は、原文と解釈を分けて持てることです。 issue_date_raw と issue_date を並べておけば、担当者は解釈が正しいかを原文で確かめられます。解釈が空なら、それだけで人が見る印になります。

3つ目は、source で根拠をたどれることです。 p1:L12 なら1ページ目の12行目で、担当者は画像のその行だけを見れば済みます。

システムへ連携する

会計システムへは書き込みません。 源泉徴収の税率を決めて送金の手続きに進むのは、責任者が一覧を確かめたあとです。支払先台帳にも書き込みません。 証明書の作成日や名義を台帳に写すのは、担当者が画像で確かめたあとに人が行います。

人が確認する

経理の担当者が開くのは、ok 以外の印が付いた支払です。 ok の支払は、名義と作成日を並べた一覧で流し見ます。

1. needs_human を先に片付ける … 日付の順序が決まらないもの、読めないものを画像で確かめ、作成日を確定させます
2. name_mismatch の理由を確かめる … 旧社名や表記の違いなら別名の一覧に足し、親会社名義なら証明書の取り直しを依頼します
3. cert_stale と no_form を責任者に上げる … 支払日までに取り直しが間に合うかを見て、源泉徴収の扱いを決めてもらいます
4. 取り直しの依頼を送る … 下書きを直して、担当者が送ります

2番目で別名の一覧に足すかを、担当者1人で決めないでください。 名義が同じ者かは、軽減の前提に関わります。足すときは責任者の確認を取り、足した理由を一覧に残します。

例外に対処する

上から4行目と5行目が、照合の誤りのほとんどを生みます。 どちらも「作成日」という1つの値の問題で、ここを人に回す設計を崩すと、1年の判定が当てにならなくなります。

記録を残す

• 元の居住者証明書と、受け取った日時、支払先コード、原本の添付か提示か
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と解釈の両方）
• 支払ごとの照合の結果と、そのとき参照した支払先台帳と別名の一覧の版
• 担当者が結果を覆した記録 … どの印を、どちらに変えたか、誰が確認したか
• 取り直しの依頼と、新しい証明書との対応

提示を受けた場合の写しの保存は、この記録とは別に扱います。 国税庁のページでは、提示を受けた日から5年間、国内にある事務所等に写しを保存しておく必要があるとされています。S3 に置くのは照合の記録で、法定の保存を兼ねるかは経理の責任者と顧問税理士で決めます。