英文の航空貨物運送状（AWB）とインボイスを読み取り、輸入台帳に転記して、個数・重量の食い違いを通関の前に拾う

処理の起点を決める

起点は、受付フォルダ（Amazon S3）にPDFが保存されたことです。 共有受信箱のルールで、登録したフォワーダーと航空会社のアドレスから届いたメールの添付をS3へ転送します。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。

AWBとインボイスは別々のメールで、別々の時刻に届くことがあります。 先に届いた書類だけで台帳の行を作り、相手の書類が来るまで照合を「待ち」にします。 相手が届いた時点で照合をやり直します。

毎朝8時にも1回動かします。 到着便が翌日までなのに書類の片方が届いていない件と、needs_human のまま残っている件を一覧にして、担当者に送ります。

入力データを集める

質を決めるのは、照合の規則の表です。 許容差を決めずに比べると、包装材の重さの違いで毎回印が付きます。

AWBには発注番号が書かれていないことが多いので、インボイスの発注番号で台帳の行を決め、AWBはハウスAWB番号で結びます。

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

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

質問は英語の文書でしか使えず、1ページあたり非同期で30個までです。 答えが見つからなければ空のまま返るので、空のときは全文から Pieces、Gross Weight、Chargeable を含む行を探し、それでも無ければ missing にします。

インボイスは StartExpenseAnalysis で読みます。 請求書・領収書から、仕入先や品目、合計などを取り出す非同期の処理で、結果は GetExpenseAnalysis で取ります。入力はJPEG、PNG、PDFです。

梱包の数と重量は、請求書の標準項目にありません。 標準に当たらない項目は OTHER として返り、書類に書かれていた項目名が LabelDetection に入ります。Total Cartons、Gross Weight、Net Weight といった項目名から、どの値が何かを生成AIに決めさせます。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。輸入台帳と照合の規則の表は Python が読み、生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。インボイスを請求書の分析に回すのはJPEG、PNG、PDFだけで、TIFFはPDFに変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは送り元に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 書類の振り分け … ファイル名、メールの件名、1ページ目の見出しの語（Air Waybill、Commercial Invoice、Packing List）で、AWB・インボイス・その他に分けます
5. 言語の確認 … 6言語に入らない書類は読み取りに回さず、担当者が目で見る一覧に入れます
6. 1つのPDFに複数の書類が入っているものの分割 … AWBとインボイスが1つのPDFにまとまって届くことがあります。ページごとの見出しで分け、それぞれの読み方に回します

6番目を省くと、AWBの運賃の欄が請求書の合計として返ります。

AIに処理させる

させるのは、AWBとインボイスから値を読み取り、その値が「何の数で、どの単位か」を書き出すことです。 照合と許容差の判定はさせません。

重量の「総重量か正味重量か、運賃計算重量か」を分けるのが、いちばん大事な区別です。 AWBの総重量とインボイスの正味重量を比べると、包装材の分だけいつも食い違います。種類が分からない重量は、比べずに not_comparable にします。

3行目がいちばん起きやすい失敗です。 明細の数量の合計を個数として返すと、100個の商品を3箱で送った貨物が、AWBの3個と食い違って見えます。

指示内容を固定する

あなたは物流会社の航空輸入課で、英文のAWBとインボイスの記載を
記録する担当です。OCRの読み取り結果だけを使ってください。
推測で埋めないでください。

【AWBから取り出す項目】
mawb_no、hawb_no、flight_raw、origin_raw、destination_raw、
pieces_raw、pieces、pieces_level（master / house / unknown）、
gross_weight_raw、gross_weight、gross_weight_unit（kg / lb / unknown）、
chargeable_weight_raw、goods_raw

【インボイスから取り出す項目】
invoice_no、invoice_date、po_no、
lines（配列：item_raw、quantity、quantity_unit）、
packages_raw、packages、
weights（配列：label_raw、kind（gross / net / unknown）、value、unit）

【status の選び方】
- ok ............. 値が読み取れており、その項目として解釈できる
- missing ........ 書かれていない
- not_stated ..... インボイスに梱包の数が書かれていない
- unreadable ..... 文字は検出されているが値として確定できない
- ambiguous ...... 候補が複数ある、または種類が決まらない
- unit_unknown ... 重量の単位が決まらない

【厳守事項】
- マスターAWBとハウスAWBを区別してください。混載の書類では
  マスターの個数・重量を、ハウスの値として入れないでください。
- 重量は、総重量（gross）、正味重量（net）、運賃計算重量
  （chargeable）を分けてください。項目名から決まらなければ
  kind を unknown にしてください。
- 単位は書類に書かれたものだけを入れてください。kg と lb を
  換算しないでください。
- インボイスに梱包の数が書かれていない場合は not_stated に
  してください。明細の数量の合計で埋めないでください。
- AWB番号は読み取った文字列をそのまま入れてください。
  桁を補ったり、似た文字に直したりしないでください。
- 個数や重量が合っているか、食い違いの理由が何かを書かないでください。
- AWBでもインボイスでもない書類（パッキングリスト、運賃の請求書、
  原産地証明書など）と判断した場合は、項目を取り出さず
  document_type に種類を書いてください。

【書類の種類】{document_type_hint}
【読み取り結果】{textract_result}

「明細の数量の合計で埋めない」を明記しないと、埋めます。 梱包の数の欄が無いインボイスで、何か数を返そうとして明細の数量を足し合わせ、後段の照合でAWBの個数と大きく食い違って見えます。

出力形式を固定する

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

{
  "file": "",
  "document_type": "air_waybill",
  "mawb_no": "000-00000000",
  "hawb_no": "HKG26100123",
  "flight_raw": "XX123/10OCT",
  "pieces_raw": "5",
  "pieces": 5,
  "pieces_level": "house",
  "gross_weight_raw": "86.5 K",
  "gross_weight": 86.5,
  "gross_weight_unit": "kg",
  "chargeable_weight_raw": "120.0",
  "goods_raw": "ELECTRONIC PARTS",
  "items": [
    { "item": "pieces", "status": "ok", "confidence": 0, "source": "" }
  ]
}

インボイスは document_type を commercial_invoice とし、invoice_no、po_no、lines、packages、weights を同じ形の items とあわせて返させます。

1つ目の理由は、照合をプログラムの側に置けることです。 Python がハウスAWB番号とインボイス番号で組を作り、照合の規則の表を引いて、比べてよい値どうしだけを比べます。

2つ目は、「比べられなかった」を記録として残せることです。 not_comparable は食い違いではありませんが、照合が済んでいない印として担当者の一覧に出します。 同じ仕出人で毎回 not_comparable になるなら、インボイスに梱包の数と総重量を書いてもらうよう、荷主から頼む先が決まります。

システムへ連携する

通関業者への受け渡しと、税関への申告は、この構成からは行いません。 照合の済んだ件を通関業者のフォルダに移すのは担当者です。申告の内容をどうするかは、通関業者が書類を見て判断します。

人が確認する

担当者が開くのは、ok 以外の印が付いたものです。 印の無いものは台帳の値のまま扱います。human_check を「条件付き」としているのはこのためです。

1. pieces_mismatch と weight_mismatch を最初に片付ける … 分割の出荷か、書き誤りかをフォワーダーと仕出人に確かめます
2. needs_human の値を画像で確定させる … AWB番号、マスターとハウスの別、重量の単位を確かめます
3. not_comparable を流し見る … 比べられなかった理由を見て、急ぎの貨物だけはパッキングリストで個数を確かめます
4. 解決した件を通関業者に渡す … 訂正されたインボイスが届いたら、照合をやり直してから渡します

例外に対処する

上から4行目と5行目は、組み方を規則の表に書いておかないと、正しい書類がすべて食い違いに見えます。

記録を残す

• 元のAWBとインボイスと、受け取った日時、送り元、メールの件名
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と、数値・単位・種類の解釈の両方）
• 照合の結果と、そのとき参照した照合の規則の表の版
• 担当者が印を覆した記録と、フォワーダー・仕出人への問い合わせの回答
• 訂正されたインボイスと、元のインボイスとの対応

最後の行は、通関の後で問い合わせがあったときに、どの版のインボイスで照合したかを引く材料になります。