海外の取引先・外注先から届く英文の米国税務フォーム（W-8BEN／W-8BEN-E／W-9）を読み取り、記入漏れ・署名日・条約適用欄の不備を支払の前に確かめる

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 新しい支払先は不定期に増えるため、1日1回の定時実行にはしません。 IRS の記入要領では、フォームは支払が行われる前に源泉徴収義務者（支払う側）に渡すものとされています。支払の予定日より前に不備を返せることが、この構成の価値です。

入る経路は、支払先の担当部署が相手から受け取って転送するPDFです。ファイル名の先頭に支払先コードを付けるところまでを人が行い、コードの無いファイルは処理の前に止めます。 どの支払先の書類か分からないと、相手の区分と照らせないからです。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken に支払先コードとファイルのハッシュから作った値を入れると、同じファイルを二度入れても同じ JobId が返り、二重に読みません。 完了は Amazon SNS に届き、SUCCEEDED を確かめてから結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。

期限の通知は、これとは別に毎朝、台帳の有効期限の列を見て動かします。

入力データを集める

質を決めるのは、下の3つです。 相手の区分が台帳に無ければ書式が合っているかを言えず、規則の表が無ければ、何を不備とするかが担当者ごとに戻ります。

相手の区分は、台帳の登録のときに担当部署が入れます。 IRS の記入要領では、米国の市民などの米国人は W-8BEN ではなく W-9 を使い、海外の事業体は W-8BEN-E を使うとされています。区分と書式が合わないことが、最初に見つける不備です。

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

読み取りは StartDocumentAnalysis に FeatureTypes として FORMS、QUERIES、SIGNATURES を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。 結果は GetDocumentAnalysis で取り、NextToken が返る限り続けて取ります。

チェックボックスはキーと値で取ります。 公式の説明では、FeatureTypes で表だけを指定すると、キーと値の中で検出された選択の要素は結果に含まれません。 フォームの選択肢はキーと値の側にあるので、FORMS を必ず入れます。

質問は QueriesConfig に別名（Alias）を付けて並べ、**Pages に ["*"] を入れて全ページを対象にします。** 署名の日付は、ページの指定が無いと1ページ目しか見ないため、W-8BEN-E のように署名が最後のページにある書式で取りこぼします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、入力欄つきのPDFは印刷し直してPDFにします
2. パスワードの確認 … パスワードで保護されたPDFは読めません。電子署名のサービスから出したPDFに多いので、保護の無い控えを頼みます
3. 書式と版の見分け … 全文の行から「Form W-8BEN」「Form W-8BEN-E」「Form W-9」と版の表記を探し、書式の版の一覧と照らします
4. ページの確認 … W-8BEN-E は数ページあります。署名のある最後のページがそろっているかを確かめます
5. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。手書きのものは300 DPIでスキャンしてもらいます
6. 重複の確認 … 同じ支払先・同じ書式・同じ署名日のものが既にあれば止めます

3番目を省かないでください。 古い版の書式が届くことがあります。版が違えば欄の番号も違い、規則の表がずれて当たります。

AIに処理させる

させるのは、書式と版を見分け、欄ごとの記入とチェックボックスの状態を所定の形にそろえ、根拠の文字列を添えることだけです。

区分の選択では、「どれに付いているか」と「いくつ付いているか」を分けて返させます。 1つだけ選ぶ欄で2つ付いていれば、どちらが正しいかをAIに選ばせず、2つという事実を返させます。

2行目がいちばん起きやすい失敗です。 台帳の情報を渡すと、AIは空欄の居住国を台帳の国で埋めます。埋めた瞬間、相手が書いていないという不備が消えます。 台帳は区分の照合にだけ使い、AIには渡しません。

指示内容を固定する

あなたは経理部で、米国子会社の支払先から届いた米国の税務フォーム
（W-8BEN、W-8BEN-E、W-9）を、支払の前に点検する担当です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 書式の名前と版の表記
2. 本人の情報（氏名・名称、国、住所、米国の納税者番号、外国の納税者番号）
3. 区分の選択（W-8BEN-E の 4 と 5 で SELECTED になっている選択肢）
4. 条約の適用欄（居住国、条項、率、所得の種類）
5. 署名の有無、署名者の氏名、日付、権限のチェック

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

【厳守事項】
- 空欄を埋めないでください。国名や住所を他の欄から補わないでください。
- 欄の見出しがあることを、値があることとして扱わないでください。
- 区分の選択は、SELECTED になっている選択肢の文字をそのまま写し、
  その数を selected_count に入れてください。
  0個や2個以上でも、どれが正しいかを選ばないでください。
- 名称（LLC、Ltd. など）から区分を推測しないでください。
- 納税者番号は読み取った文字列をそのまま写し、桁を補わないでください。
- 署名については、署名らしきものがあるか、署名欄に名前が
  打ち込まれているだけかを分けて signature_kind に書いてください。
  本物かどうかは判断しないでください。
- 日付は書かれているとおりに写し、有効期限を計算しないでください。
- 条約の軽減を適用できるか、源泉徴収の率はいくつかは書かないでください。
- 書式が W-8BEN、W-8BEN-E、W-9 のどれでもなければ、form を other にしてください。

【読み取り結果】{textract_result}
【書式の版の一覧】{accepted_revisions}

「見出しがあることを、値があることとして扱わない」を明記しないと ok になります。 フォームには欄の見出しがすべて印刷されているので、何も言わなければ、印刷された見出しを根拠に「記入あり」と答えます。

「打ち込まれているだけかを分ける」も同じ理由です。 第3章の（b）のとおり、名前の打ち込みは電子署名になりません。署名の検出が「署名らしきもの」と答えた位置に、活字の名前しか無いこともあります。

出力形式を固定する

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

{
  "form": "W-8BEN | W-8BEN-E | W-9 | other",
  "revision": "",
  "fields": [
    { "line": "6a", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "evidence": "", "confidence": 0 }
  ],
  "selections": [
    { "line": "5", "selected": [""], "selected_count": 0 }
  ],
  "treaty": { "country": "", "article": "", "rate": "", "income_type": "",
              "status": "ok | missing | not_applicable" },
  "signature": { "kind": "handwritten_like | typed_name | missing",
                 "signer_name": "", "date": "", "capacity_checked": "yes | no | not_applicable" }
}

1つ目の理由は、規則をプログラムで当てられることです。 selected_count が1でなければ不備、signature.date が空なら不備、と規則の表をそのままコードにできます。 規則が変わっても、直すのは表だけです。

2つ目は、有効期限をプログラムで出せることです。 IRS の記入要領では、W-8BEN と W-8BEN-E は原則として署名日から3暦年後の最終日まで有効とされます（例：2015年9月30日の署名なら2018年12月31日まで）。signature.date からこの日付を計算し、台帳に入れます。

条約の適用欄に記入があるものを needs_human にしているのは、軽減の判断が人の仕事だからです。 欄が埋まっていることまではこの構成が確かめ、中身が条約に合うかは経理の責任者が見ます。

システムへ連携する

支払先台帳へは、人が確定したものだけを書き込みます。 判定の結果は別の一覧に出し、経理が確かめた行だけを台帳に移します。

会計システムの支払の止め・解除には触れません。 書類がそろうまで支払を保留するかは、経理の既存の手順で決めます。

人が確認する

人が開くのは needs_resend と needs_human のものだけです。 pass のものは一覧で書式と有効期限を流し見ます。

1. 支払の予定日が近いものを先に見る … 台帳の支払予定日の近い順に並べます
2. needs_resend の根拠を確かめる … evidence と画像で、本当に空欄か、本当に2つ付いているかを目で確かめます
3. 条約の適用欄を見る … 記入された条項・率・所得の種類が、支払の内容と合っているかを経理の責任者が見ます
4. 差し戻す … 下書きを直して送ります。送信は人が行います
5. 判定を覆したら記録する … どの欄を、どちらに変えたかを残します

2番目を省かないでください。 差し戻しは相手の手間を増やします。チェックボックスの印が薄いだけの書類を差し戻すと、海外の個人の外注先との関係がぎくしゃくします。

例外に対処する

7行目は、この構成の外から入ってくる例外です。 引っ越しや法人の再編で居住国や区分が変わったとき、記入要領は30日以内に支払う側へ知らせて新しいフォームを出すとしています。担当部署が連絡を受けたら、台帳の有効期限を待たずに取り直します。

記録を残す

• 元のPDFと、受け取った日時・支払先コード
• Textract が返したJSONの全文と、JobId・状態
• 生成AIの出力（fields、selections、treaty、signature）
• 判定の結果と、そのとき当てた規則の表と版の一覧の版
• 人が判定を覆した記録と、差し戻しのやり取り
• 台帳に登録した署名日と有効期限

4つ目で「規則の表の版」を残すのは、規則が後から変わるためです。 どこまでを不備とするかを専門家と見直したとき、過去の判定がどの規則によるものかが残っていないと、見直しの範囲が決まりません。