海外の顧客から届く英文の注文書を読み取って受注データに転記し、見積書との単価・納期・インコタームズ・支払条件の食い違いを拾う

処理の起点を決める

受付フォルダ（Amazon S3）に注文書が保存されたことを起点にします。 注文は届いた順に処理し、照らした結果が出るまでの時間を短くします。 顧客は注文請書の返りを待っており、条件の違いを確かめる連絡は早いほど通りやすいからです。

注文の受け取り用のメールアドレスを顧客に案内し、添付を自動で受付フォルダへ保存します。 営業担当の個人のアドレスに届いた注文は、そのアドレスへ転送してもらいます。転送が抜けると、その注文は照らされないまま残ります。

処理が終わった注文書は処理済みの場所へ移し、移すのは確認の一覧への書き出しまで成功したときだけにします。

入力データを集める

質を決めるのは、見積のデータの取り出しやすさです。 見積が表計算のファイルに散らばっていると、照らす先がありません。見積番号・顧客・品番で1行を引ける形にそろえることが、最初の作業になります。

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

読み取りは、Lambda から StartDocumentAnalysis を呼んで始めます。 文書はS3の場所で指定し、完了の通知先にSNSのトピックを渡します。ClientRequestToken に受付のファイルごとの値を入れ、同じ注文書の処理が二重に始まらないようにします。 JobId は7日間しか有効でないので、完了を受けたらすぐに GetDocumentAnalysis で結果を取り、自社のバケットへ書き出します。

質問は QueriesConfig に並べ、Pages で当てるページを1ページ目と2ページ目に絞ります。 約款のページに質問を当てると、約款の中の一般的な支払条件の文を答えとして拾うことがあるためです。

答えは QUERY_RESULT の塊として返り、信頼度が付きます。答えが見つからないときは空のまま返ります。 見積番号が空なら、顧客と品番で見積を引く経路に切り替えます。空を「見積なし」と読まないことが大事です。

見積は Python で販売管理の仕組みから取り出します。 生成AIには、品番の候補を出すための品番の対応表の一部だけを渡します。

AIへ渡す前に整形する

1. 形式の確認 … 扱えるのはJPEG、PNG、PDF、TIFFです。XFA形式のPDFには対応していません
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 顧客に保護のないものを送り直してもらいます
3. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上（150dpiで8ポイント）です
4. 顧客の特定 … 送り元のアドレスのドメインから顧客マスタを引きます。引けなければ、注文書の会社名で引きます
5. 言語の切り替え … 顧客マスタの注文書の言語が英語なら QUERIES を入れ、それ以外は FORMS と TABLES だけにします
6. 数値と日付の正規化 … 顧客マスタの書き方で、「1.250,00」や「03/04/2026」を自社の形に直します。元の文字列は残します
7. 重複の検知 … 同じ顧客・同じ注文番号のものが既にあれば、再送か変更の注文かの印を付けます

6番目はAIに任せません。 欧州の顧客の「1.250,00」を千二百五十と読むか一・二五と読むかで、数量か単価が千倍ずれます。 書き方は顧客マスタで決め打ちします。

7番目で「変更の注文」を見分けるのは、同じ注文番号に「Revision 2」「Change Order」と書かれて届くものがあるからです。 新しい注文として登録すると二重に出荷します。

AIに処理させる

させるのは、読み取り結果を受注データの形にそろえ、品番の対応表で引けない行に候補を出し、取引条件を原文のまま切り出すことだけです。

インコタームズと支払条件を「原文のまま」切り出させるのは、言い換えで意味が変わるからです。 「Net 60 days from invoice date」と「60 days after B/L date」は、どちらも60日ですが起算日が違います。要約させると「60日」とまとめ、照合で違いが消えます。

4行目がいちばん起きやすい失敗です。 航空便の注文に「CIF」と書かれていると、AIは気を利かせて「航空便ならCIPのはず」と直して返すことがあります。直された値は見積と一致し、確かめるべき違いが消えます。

指示内容を固定する

あなたは輸出を行う商社の営業アシスタントで、海外の顧客から届いた
英文の注文書を、受注データの形にそろえる立場です。
渡すのは、OCRが返した読み取り結果と、その顧客の品番の対応表です。
そこに書かれたことだけを使ってください。

【書き出すこと】
1. 主要な項目: po_no, po_date, revision, quote_no, ship_to, currency
2. 明細の行: customer_part_no, description, qty, unit, unit_price,
   amount, requested_date
3. 品番の対応表で引けない行: 自社の品番の候補（最大3つ）と根拠
4. incoterms_text: インコタームズの記載を原文のまま
5. payment_terms_text: 支払条件の記載を原文のまま
6. 約款のページがあれば、そのページ番号

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 数量・単価・金額・日付は、読み取り結果の文字列のまま写してください。
  計算したり、書き方を直したりしないでください。
- インコタームズと支払条件は、要約・言い換え・修正をせず原文のまま
  写してください。誤りに見えても直さないでください。
- 見積と合っているか、条件が妥当かを書かないでください。
- 自社の品番の候補は、渡した対応表に出てくる品番からだけ選んでください。
  品名が似ているというだけで候補にしないでください。
  候補が無い行は unmatched としてください。
- 約款の内容を要約したり、受け入れてよいかを書いたりしないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- 注文書でない書類（見積依頼、納期の問い合わせなど）と判断した場合は、
  そろえる作業をせず document_type に種類を書いてください。

【読み取り結果】{textract_result}
【この顧客の品番の対応表】{part_xref}

「誤りに見えても直さない」を書かないと、インコタームズを直します。 第7章の「させないこと」の4行目の失敗は、この1文で防ぎます。

「品名が似ているというだけで候補にしない」は、型番の末尾だけが違う品番が並ぶ商材で効きます。 「Bearing 6204」と「Bearing 6204-2RS」は別の品番で、単価も違います。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とJSONスキーマを渡す）を使うと、スキーマどおりの形で返り、必須の項目が欠けません。

{
  "document_type": "purchase_order",
  "po_no": "",
  "po_date": "",
  "revision": "",
  "quote_no": "",
  "ship_to": "",
  "currency": "",
  "lines": [
    { "customer_part_no": "", "description": "", "qty": "", "unit": "",
      "unit_price": "", "amount": "", "requested_date": "",
      "own_part_candidates": [ { "part_no": "", "evidence": "" } ] }
  ],
  "incoterms_text": "",
  "payment_terms_text": "",
  "terms_pages": []
}

この後に、Python が照合を足します。

1つ目の理由は、インコタームズを規則のコードと場所に分けて照らせることです。 Python が原文からコードと場所と版の年を取り出し、コードが一覧に無いもの（2020年版で名前が変わった旧来のDATなど）は terms_diff にします。ICCは、2020年版で旧来のDAT（Delivered at Terminal）をDPU（Delivered at Place Unloaded）に改めたとしています。

2つ目は、支払条件の照合を「一致」か「違う」かに限れることです。 支払条件の書き方は顧客ごとにばらばらなので、顧客マスタに過去に一致と確かめた書き方を積み、それと文字列で照らします。 積んでいない書き方は terms_diff で人に回し、確かめたら積みます。

システムへ連携する

受注の確定は自動にしません。 この構成が作るのは受注データの下書きまでで、確定と注文請書の送付は人が行います。 確定すると出荷の手配と仕入先への発注が動き出すため、誤りが一息に広がります。

人が確認する

営業アシスタントは全件の下書きを見ますが、見方を判定で分けます。

1. match は下書きと原本を並べて確定する … 照らす作業は済んでいるので、品番と数量を目で追うだけです
2. terms_diff を最優先で営業担当に回す … インコタームズと支払条件の違いは、運賃・保険料・支払の時期に直結します
3. price_diff と quote_expired を営業担当に回す … 差額と期限を添えて、顧客に確かめるかを決めてもらいます
4. below_moq と lead_time_short は、仕入先のメーカーの回答を待つ … 受けられるかを確かめてから顧客に返します
5. 品番の候補を確定したら対応表に積む … 翌月から同じ品番は機械で引けます

5番目が、この構成を月ごとに速くします。 最初の月は needs_human が多く出ますが、対応表が育つと、継続の注文は確定のボタンを押すだけになります。

目標は、360件をならして1件7分です。 match は数分、terms_diff のある注文は営業担当とのやり取りを含めて15分以上かかる想定です。

例外に対処する

4行目を軽く見ないでください。 改訂版の注文書は、変わった行だけでなく全体が送り直されてきます。新しい注文として取り込むと、同じ品物を二重に手配します。

5行目で版の記載なしを terms_diff にしないのは、書かない顧客が多いからです。 ICCは契約で使う版を明記するよう案内しています。全件を止めると確認が回らないので、添え書きにとどめ、顧客との基本契約で版を決めておきます。

記録を残す

• 元の注文書のPDFと、受け取った日時・送り元
• OCRが返したJSONの全文
• AIが返したJSONと、そのとき渡した品番の対応表の範囲
• 照合に使った見積の版と、照合の結果
• 人が受注を確定した記録と、確定までに変えた項目
• 顧客への確認の内容と回答、注文請書を送った日時

「見積の版」を残すのは、見積が改訂されるためです。 顧客と単価を合わせ直して見積を出し直すと、古い見積で照らした結果と新しい見積で照らした結果が違ってきます。 どちらで受けたかを、後から確かめられるようにします。