米国子会社の輸入で通関業者から届く英文の CBP Form 7501 を読み取り、HTSコード・関税額・原産国をインボイスと品目マスタに突き合わせる

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 申告は便ごとに出るため、1日1回の定時実行にはしません。 控えが届いたその日に食い違いが分かれば、通関業者が案件を覚えているうちに確認を頼めます。

通関業者のメールは専用のアドレスで受け、添付を受付フォルダに自動で保存します。 ファイル名には件名から取った申告番号を付けます。申告番号が取れないメールは、処理を始める前に止めて担当者に知らせます。

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

入力データを集める

質を決めるのは、品目マスタと照合の許容幅です。 マスタに承認済みのHTS番号が無い品目は照合できず、許容幅を決めていないと、為替や運賃の配分で生じる小さな差が全部 mismatch になります。

便の情報は、申告とインボイスを結ぶために使います。 7501 の「12. B/L or AWB Number」と基幹システムの入荷予定の番号が一致すれば、どのインボイスの申告かが決まります。

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

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

質問は QueriesConfig に別名（Alias）を付けて並べます。公式の手引きは、決まった欄の値を取るときは欄の名前をそのまま質問にしてよいとしています。例えば ENTRY_NO に「Filer Code/Entry Number」、TOTAL_EV に「Total Entered Value」です。質問は既定で1ページ目しか見ません。 合計は本紙にありますが、継続シートの行も取るため、表は全ページから取ります。

行の表はそのまま使えないことがあります。 7501 の1行は、HTS番号の下に関連する番号や手数料が何段も重なる書き方をします。記入要領では、1行に複数のHTS番号が並ぶもの（例えば第98類の品目）や、HTS番号の直下に裁定の番号（「RLNG」で始まる）や手数料を書くものがあります。セルの中で段が混ざるので、行への組み立ては生成AIに任せます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えません
2. パスワードの確認 … パスワードで保護されたPDFは読めません。通関業者に保護の無いものを頼みます
3. ページの確認 … 本紙と継続シートがそろっているかを、行番号の連続で確かめます。記入要領では、行番号は001から順に振るとされています
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。ファクスを経由した控えは、これを下回りやすいので、PDFの原本を頼みます
5. 重複の確認 … 同じ申告番号の控えが既にあれば、差し替え版かどうかを日付で見分けます
6. インボイスの呼び出し … 「12. B/L or AWB Number」で入荷予定を引き、その便のインボイスの明細を取り出します

3番目を省かないでください。 継続シートが1枚抜けていても、本紙の合計と行の合計が合わないことでしか気づけません。 ページの抜けは、照合の前に止めます。

AIに処理させる

させるのは、7501 の行を所定の形にそろえ、インボイスの明細との対応の候補を根拠つきで出すことだけです。

明細との対応が、いちばん手間を減らすところです。 7501 の品名「Ball bearings」と、インボイスの「DGBB 6204ZZ」「DGBB 6205ZZ」を、品目マスタのHTS番号と金額の合計を手がかりに結びます。対応の根拠（どの品番を、なぜ選んだか）を必ず添えさせます。

3行目がいちばん起きやすい失敗です。 「8482.10.50」のように末尾の2桁が読めないとき、AIは品目マスタの番号で埋めたくなります。埋めた瞬間、照合は必ず match になります。

指示内容を固定する

あなたは米国子会社の物流管理の担当として、通関業者から届いた
CBP Form 7501（Entry Summary）の控えを読み、行ごとの値をそろえて、
仕入インボイスの明細との対応の候補を出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 申告の見出し（Entry Number、Entry Date、Importer of Record、
   Country of Origin、B/L or AWB Number）
2. 行ごとの値（行番号、品名、HTS番号のすべて、行ごとの原産国、
   Entered Value、Charges、Relationship、HTS Rate、Duty、手数料）
3. 行ごとの、インボイス明細との対応の候補と根拠

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

【厳守事項】
- HTS番号は、読み取った文字列をそのまま写してください。
  桁を補う、品目マスタの番号に直すことをしないでください。
- 1行に複数のHTS番号があるときは、すべてを順に写してください。
- 「RLNG」で始まる裁定の番号、「O」で始まる行ごとの原産国、
  手数料の記載は、それぞれの欄に分けてください。
- 関税額を計算しないでください。書かれている金額だけを写してください。
- 税率が「Free」、百分率、数量あたりの金額、その組み合わせのどれかを
  rate_type に書き、原文を rate_original に写してください。
- 原産国を品名や仕入先の国から推測しないでください。書かれているコードだけを写してください。
- インボイス明細との対応は候補として出し、根拠（品番、品名、金額）を
  reason に書いてください。決められなければ ambiguous にしてください。
- 分類が正しいか、訂正を求めるべきかは書かないでください。

【読み取り結果】{textract_result}
【この便のインボイス明細】{invoice_lines}
【明細の品番に対応する品目マスタの抜粋】{item_master}

「品目マスタの番号に直さない」を明記しないと、親切に直します。 マスタの抜粋を渡しているので、AIには「正しい番号」が見えています。見えているからこそ、写すだけにさせることを言葉で縛ります。

品目マスタを渡すのは、対応づけの手がかりにするためです。 照合の材料にさせるためではありません。照合はプログラムが行います。

出力形式を固定する

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

{
  "entry_no": "",
  "entry_date": "",
  "bl_awb_no": "",
  "origin_header": "",
  "lines": [
    {
      "line_no": "001",
      "description": "",
      "hts_numbers": [""],
      "ruling_no": "",
      "origin_line": "",
      "entered_value": "",
      "charges": "",
      "relationship": "Y | N | not_found",
      "rate_type": "free | ad_valorem | specific | compound | not_found",
      "rate_original": "",
      "duty": "",
      "status": "ok | not_found | unreadable | ambiguous",
      "invoice_lines": [ { "invoice_no": "", "item_code": "", "reason": "" } ]
    }
  ],
  "totals": { "entered_value": "", "duty": "", "other": "", "total": "" }
}

1つ目の理由は、照合をプログラムに渡せることです。 hts_numbers と invoice_lines の品番があれば、品目マスタの承認済みの番号と1対1で比べられます。照合の結果は AI の出力に入れず、プログラムが別に持ちます。

2つ目は、rate_type で検算の可否を分けられることです。 記入要領では、税率は無税・従価・従量・複合のいずれかで書かれます。従価なら税率×課税価格で検算し、従量と複合は数量の単位が要るので needs_human にします。

最後の行は、読み取りの誤りを拾う網です。 行の値を1つ読み違えれば、合計が合わなくなります。

システムへ連携する

基幹システムへは書き込みません。 品目マスタのHTS番号と申告が違っていても、マスタを申告に合わせて直すことはしません。 どちらが正しいかを決めるのは貿易管理の担当者です。

通関業者への依頼は、下書きまでです。 送信は担当者が行います。

人が確認する

人が開くのは、mismatch か needs_human の行がある申告だけです。 照合が通った申告は、件数と関税の合計を一覧で流し見ます。

1. 合計が合わない申告を先に見る … 読み取りの誤りか、ページの抜けかを、控えの画像で確かめます
2. HTS番号の食い違いを確かめる … 品目マスタの承認の根拠と、申告の番号を並べます。マスタが古いこともあります
3. 原産国の食い違いを確かめる … 第3章の（c）のように、仕入先の国と原産国が違う品目は、マスタの根拠を見ます
4. 通関業者に確認を頼むかを決める … 下書きを直して送ります
5. 判定を覆したら記録する … 照合の結果を、どちらに変えたかを残します

2番目でマスタを先に疑うのは、承認が古いまま残っていることがあるからです。 HTSは改正されます。申告のほうが新しい番号で、マスタが古い番号ということは珍しくありません。

例外に対処する

7行目が、運用を始めて最初に増えるものです。 6,000品目のうち承認済みの番号が入っているのは、よく動く品目だけということが多いからです。この一覧が、そのままマスタ整備の作業表になります。

記録を残す

• 元のPDFと、受け取った日時・通関業者・申告番号
• Textract が返したJSONの全文と、JobId・状態
• 生成AIの出力（lines、totals）
• 照合の結果と、そのとき参照した品目マスタの番号と承認日
• 人が判定を覆した記録と、通関業者とのやり取り
• 経理に回した関税額と、回した日

4つ目で「そのときのマスタ」を残すのは、マスタが後から直るためです。 承認済みの番号を直したあとで過去の照合を見返すと、当時は mismatch だった理由が分からなくなります。