海外の仕入先から届く英文の船荷証券・パッキングリスト・インボイスを読み取り、品名・数量・重量・船名を輸入案件の台帳へ転記する

処理の起点を決める

共有のメールボックスに届いたメールの添付を、保管先の受付の場所へ保存したことを起点にします。 保存は、メールの振り分けの規則か、メールボックスを見張る仕組みで行います。1日1回の定時実行にはしません。 書類は入港の数日前に集中して届き、まとめて処理すると、台帳に載るのが通関の依頼の締め切りに間に合わなくなります。

書類は3種類がそろって届くとは限りません。 インボイスが先に届き、B/L が数日後に届くことはよくあります。そのため、処理の単位は案件ではなく書類1通にします。 届いた書類から順に読み取り、台帳の同じ案件の行へ項目を足していきます。

同じメールが二度届いたときに、読み取りを二重に動かさない工夫をします。 Textract の非同期の処理には、同じ依頼を二度出しても同じ処理番号（JobId）を返す ClientRequestToken があります。ファイルの中身から作った値をこれに入れ、再送されたメールで同じ書類を二度読まないようにします。

入力データを集める

質を決めるのは、いちばん下の表です。 たとえば総重量はパッキングリスト、船名と B/L の番号は B/L、品名と数量はインボイスを正とする、といった取り決めを表にします。この表が無いと、同じ値が2つの書類から取れたときに、プログラムがどちらを採るかを決められません。

仕入先の情報の「数字の書き方」も効きます。 「1.234,50」と書く仕入先だと分かっていれば、読み取った文字列を数値にするときの規則を仕入先ごとに切り替えられます。 分かっていない仕入先は、両方の読み方を試して、合計と明細の和が合う方を採ります。

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

読み取りは非同期の処理（StartDocumentAnalysis）で行います。 同期の処理（AnalyzeDocument）は、PDF と TIFF が1ページまでです。B/L は裏面の約款まで含めて複数ページのPDFで届くことが多いため、全部の書類を非同期で扱います。 非同期なら、PDF と TIFF は500MB・3,000ページまで扱えます。

完了は通知で受け取ります。 非同期の処理は、完了の状態を Amazon SNS のトピックに送ります。公式のドキュメントは、結果の取得の操作（Get）を繰り返し呼んで完了を待つことを勧めておらず、呼びすぎると絞られるとしています。通知を受けて Lambda を動かし、そこで結果を取りに行きます。

結果は自社の保管先に出させます。 非同期の結果は、既定では Textract の側で暗号化して7日間保存され、取得できるのは処理の開始から7日までです。 OutputConfig で自社の保管先を指定し、読み取り結果を残します。

問いは、書類の種類ごとに決めます。 問いには本文と別名（Alias）を付けられ、答えの側にはその問いが繰り返されて返ります。別名を台帳の項目名にしておけば、答えを項目へ対応付ける手間がなくなります。 1ページあたりの問いは、非同期で30までです。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA 形式の PDF には対応していません
2. パスワードの確認 … パスワードで保護された PDF は読めません。 仕入先に保護を外して送り直してもらいます
3. 大きさの確認 … 非同期の PDF は500MB・3,000ページまで。画像は各辺10,000ピクセル以下です
4. 文字の大きさの確認 … 読み取れる文字の高さの下限は15ピクセルで、150DPIで8ポイントの文字に当たります
5. 1ファイルに複数の書類がないかの確認 … インボイスとパッキングリストが1つのPDFにまとまっているものは、ページで分けます
6. 重複の確認 … ファイルの中身から作った値で、同じ書類が既に読まれていないかを見ます

4番目を軽く見ないでください。 仕入先が紙の書類をスキャンして送ってくると、B/L の細かい字がこの下限に近くなります。小さな字の船名や航海番号が、読めずに空の答えになります。 空の答えが続く仕入先には、PDF を元のデータから書き出して送ってもらうよう頼みます。

5番目は、案件の引き当てに効きます。 1つのPDFに3種類の書類がまとまっていると、どのページがどの書類かが分からず、問いの答えが混ざります。ページごとに書類の種類を見分けてから、問いを当てるページを決めます。

AIに処理させる

AIがするのは2つです。 OCR が値と信頼度を読み取り、生成AIがそれを台帳の項目の形に並べ直します。 換算と選択と引き当ては、プログラムが行います。

真ん中の行の「並べ直す」が、生成AIの仕事のすべてです。 パッキングリストの表は、仕入先によって列の順も列の名前も違います。「G.W.」「Gross Wt」「Gross Weight (KGS)」を同じ総重量の列だと見分け、明細の行を台帳の品目の行の形にそろえるところだけを任せます。

3行目がいちばん起きやすい失敗です。 B/L で総重量の答えが空だったときに、パッキングリストの値で埋めたくなります。埋めると台帳の値は正しく見えますが、どちらの書類から採ったかという記録が消えます。 補うかどうかは、正とする書類の表に従ってプログラムが決めます。

指示内容を固定する

あなたは輸入の案件を管理する部署で、英文の船積書類の読み取り結果を
輸入案件の台帳の形に並べ直す立場です。
OCRが返した読み取り結果だけを使ってください。推測で埋めないでください。

【まずすること】
読み取り結果がどの書類かを、次から1つ選んで document_type に入れてください。
bill_of_lading / packing_list / commercial_invoice / other

【並べ直す項目】
- 輸送：B/L番号、船名、航海番号、積地、揚地、船積日
- 取引：インボイス番号、インボイス日付、注文番号、通貨、合計金額
- 梱包：梱包の数と種類、正味重量、総重量、容積
- 品目の行：品名、品番、数量、数量の単位、単価、金額

【厳守事項】
- 値は書類に書かれた文字列のまま raw に入れてください。
  数字の区切り、単位、日付の書き方を直さないでください。
- 単位は書かれているとおり unit に入れてください。換算しないでください。
- 日付を別の書き方に直さないでください。月と日を入れ替えないでください。
- 読み取り結果に無い項目は status を not_found にし、raw を空にしてください。
  他の書類や他の項目から補わないでください。
- 入港予定日（ETA）が書かれていなければ not_found です。
  船積日や航路から計算しないでください。
- 表の列の名前が違っても同じ意味なら同じ項目に並べてください。
  どの列を採ったかを source_label に写してください。
- 1つの項目に候補が2つ以上あるときは、両方を candidates に入れ、
  status を ambiguous にしてください。どちらかを選ばないでください。
- confidence は OCR が返した値をそのまま入れてください。
- 書類どうしで値が合っているかを判断しないでください。

【読み取り結果】{textract_result}
【この仕入先の情報】{supplier_profile}

「換算しない」「月と日を入れ替えない」を明記しないと、親切に直します。 「2,205 LBS」を渡すと、何も言わなければ「1,000 kg」と書いて返すことがあります。直した値が正しくても、元の書類に何と書かれていたかが台帳から消えます。 換算はプログラムで行い、元の値と並べて残します。

「候補が2つ以上なら選ばない」も同じ理由です。 B/L には、船積日と発行日という2つの日付が並んでいることがあります。どちらかを選ばせると、選んだ理由が残りません。

出力形式を固定する

Claude API の構造化出力を使い、次の形のJSONで受け取ります。 構造化出力は、応答を指定した JSON スキーマに従わせ、必須の項目と型がそろった、読み込める形を保証するとされています。

{
  "file_id": "",
  "document_type": "bill_of_lading | packing_list | commercial_invoice | other",
  "fields": [
    { "item": "vessel_name", "status": "ok | not_found | ambiguous",
      "raw": "", "unit": "", "candidates": [], "confidence": 0, "source_label": "" }
  ],
  "line_items": [
    { "description": "", "part_no": "", "qty_raw": "", "qty_unit": "",
      "unit_price_raw": "", "amount_raw": "", "confidence": 0 }
  ],
  "keys_for_matching": { "po_no": "", "invoice_no": "", "bl_no": "" }
}

1つ目の理由は、raw と台帳の値を別の層に置けることです。 AIが埋めるのは書かれたとおりの raw だけで、台帳に入る数値と日付はプログラムが作ります。 仕入先の数字の書き方が分かったら、直すのは規則だけです。

2つ目は、status で「無かった」と「迷った」を分けられることです。 not_found は書類に書かれていない、ambiguous は候補が複数あった、ということです。前者は他の書類を待てば埋まることが多く、後者は人が決めるものです。

3つ目は、keys_for_matching で案件を引き当てられることです。 注文番号、インボイスの番号、B/L の番号のどれかで台帳の行を探します。

台帳に入る値は、正とする書類の表で選びます。 正とする書類の値が ok ならそれを採り、not_found なら表に書いた次の書類の値を採って「代替」の印を付けます。 書類どうしで値が違うときは、採った値の横に「要確認」の印を付けます。

システムへ連携する

台帳への書き込みは、「仮登録」の行に限ります。 担当者が「書類受領」にした行は、この構成から書き換えません。後から届いた書類で値が変わりそうなときも、上書きせずに「後着の書類で値が違う」と印を付けます。

販売管理システムには書き込みません。 台帳の値を販売管理システムへ移すのは、これまでどおり人の仕事です。読み取りの誤りが仕入の計上まで一息に進む経路を作りません。

人が確認する

人が見るのは、仮登録の行の全部ですが、元の書類と見比べるのは印の付いた項目だけです。

1. 案件を特定できなかった書類を先に見る … どの案件の書類かを決め、引き当てます
2. 「要確認」の項目を見る … 書類どうしで値が違うものです。どちらを採るかを決め、必要なら仕入先に訂正を求めます
3. 信頼度の低い項目を見る … 元の書類の該当箇所を開いて、値を確かめます
4. 「代替」の印の項目を見る … 正とする書類に無かった値です。後から正とする書類が届く予定かを確かめます
5. 残りの項目を流し見て、状態を「書類受領」にする

2番目を省かないでください。 総重量が書類ごとに違うまま通関業者に渡すと、申告の段階で問い合わせが来ます。 食い違いを直すのは UC-0061 のような突合の仕組みか人の仕事で、この構成は印を付けて渡すところまでです。

目標は、240件をならして1件4分です。 印の付く項目が1件あたり数個という想定で、それより多い月は、仕入先の数字の書き方の情報が足りていないか、スキャンの書類が増えています。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、仕入先の書類の送り方の問題です。 仕入先ごとに傾向が出るので、まとめて頼むほうが、読み取りの精度を上げるより効きます。

記録を残す

• 元の書類のPDFと、受け取った日時・送信元
• Textract の読み取り結果の全文（問いへの答え、表、キーと値の組、信頼度）
• 生成AIが返したJSON（raw、status、candidates）
• 台帳へ書いた値と、その値を採った書類と規則（正とする書類か代替か）
• 人が値を直した記録と、「書類受領」にした人と日時
• 仕入先ごとの not_found と信頼度の低い項目の発生率

4つ目で「どの書類から採ったか」を残すのは、後から台帳の値を疑うときのためです。 通関業者から重量の問い合わせが来たとき、台帳の値が B/L から来たのかパッキングリストから来たのかが分からないと、答えられません。

最後の行は、仕入先への依頼の材料になります。 特定の仕入先だけ空の答えが続くなら、書類の送り方に理由があります。