海外のメーカー・代理店から届く英文の見積書を読み取り、単価・インコタームズ・支払条件・納期・保証を見積比較表にそろえて、条件のそろっていない見積を拾う

処理の起点を決める

受付フォルダ（Amazon S3）に見積書が保存されたことを起点にします。 見積は届いた順に読み、1社分ずつ比較表の列が埋まっていく形にします。3社そろうまで待つと、確認の往復のぶんだけ発注が遅れます。

見積の受け取り用のメールアドレスを、見積依頼の英文に書いて仕入先に案内します。件名に見積依頼の番号を書いてもらい、その番号で受付フォルダを分けます。 購買担当の個人のアドレスに届いた見積は、そのアドレスへ転送してもらいます。

処理が終わった見積書は処理済みの場所へ移し、移すのは比較表への書き出しまで成功したときだけにします。

入力データを集める

質を決めるのは、見積依頼の条件の持ち方です。依頼の番号で、品番ごとの数量と取引条件を1行で引ける形にそろえることが、最初の作業になります。

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

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

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

答えは QUERY_RESULT の塊として返り、信頼度が付きます。答えが見つからないときは空のまま返ります。 空のときは約款と注記の全文から生成AIに探させ、無ければ not_stated にします。 質問の数は、同期で1ページに15まで、非同期で30までです。

見積依頼の条件は Python で購買管理の仕組みから取り出します。 生成AIには、見積書の読み取り結果と、その依頼の品番の一覧だけを渡し、依頼の条件そのものは渡しません。

AIへ渡す前に整形する

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

6番目はAIに任せません。 「1.250,00」の読み方で単価が千倍ずれます。

7番目は、価格交渉の後に同じ見積番号で出し直してくる仕入先がいるためです。 改訂前の単価が残ると、下がった単価が反映されないまま別の仕入先に決めてしまいます。

AIに処理させる

させるのは、読み取り結果を比較表の項目にそろえ、取引条件を原文のまま切り出し、別途の費用と除外事項を拾うことだけです。

条件を「原文のまま」切り出させるのは、言い換えで意味が変わるからです。 「8-10 weeks ARO」と「8-10 weeks after drawing approval」は起算点が違い、要約させると「8〜10週」にまとまって違いが消えます。

2行目がいちばん起きやすい失敗です。 EXWとCIPの見積を並べると、AIは「運賃を加えるとおよそこのくらい」と書いてきます。根拠のない数字が、比較表では本物の見積と同じ重みで読まれます。

指示内容を固定する

あなたは製造業の購買部で、海外の仕入先から届いた英文の見積書を、
見積比較表の項目にそろえる立場です。
渡すのは、OCRが返した読み取り結果と、見積依頼の品番の一覧です。
そこに書かれたことだけを使ってください。

【書き出すこと】
1. 主要な項目: quote_no, quote_date, rfq_ref, revision, currency
2. 明細の行: part_no, description, qty, unit, price_basis,
   unit_price, amount, moq
3. incoterms_text: インコタームズの記載を原文のまま
4. payment_terms_text: 支払条件の記載を原文のまま
5. lead_time_text: 納期の記載を原文のまま。あわせて週または日の数と
   起算点（ARO、図面承認後など）を書く。起算点が無ければ「不明」
6. validity_text, warranty_text: 有効期限と保証の記載を原文のまま
7. extra_charges: 梱包費・書類費・試験費・運賃などの別途の費用、
   価格改定の条項。原文とページ番号

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 数量・単価・金額・日付は、読み取り結果の文字列のまま写してください。
  計算・換算・書き方の修正をしないでください。
- price_basis は「per piece」「per 100」など、書かれている単位をそのまま
  写してください。書かれていなければ「不明」としてください。
- インコタームズ・支払条件・納期・有効期限・保証は、要約・言い換え・
  修正をせず原文のまま写してください。誤りに見えても直さないでください。
- 運賃・保険料・関税の金額を見積もったり、足したりしないでください。
- 見積依頼と合っているか、どの見積が有利かを書かないでください。
- 品番は、渡した見積依頼の品番の一覧と一致するものだけ part_no に入れ、
  一致しない品番（代替品の提案など）は alternative に入れてください。
- evidence には、根拠にした文字列とページ番号をそのまま写してください。
- 見積書でない書類（カタログ、辞退の連絡など）と判断した場合は、
  そろえる作業をせず document_type に種類を書いてください。

【読み取り結果】{textract_result}
【約款のページの全文】{terms_text}
【見積依頼の品番の一覧】{rfq_parts}

「誤りに見えても直さない」を書かないと、インコタームズを直します。 航空便の見積に「FOB Frankfurt Airport」と書かれていると、AIは「航空便ならFCAのはず」と直して返すことがあります。確かめるべき違いが消えます。

出力形式を固定する

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

{
  "document_type": "quotation",
  "quote_no": "",
  "quote_date": "",
  "rfq_ref": "",
  "revision": "",
  "currency": "",
  "lines": [
    { "part_no": "", "description": "", "qty": "", "unit": "",
      "price_basis": "", "unit_price": "", "amount": "", "moq": "",
      "evidence": "" }
  ],
  "alternative": [],
  "incoterms_text": "",
  "payment_terms_text": "",
  "lead_time": { "text": "", "weeks_min": "", "weeks_max": "", "basis": "" },
  "validity_text": "",
  "warranty_text": "",
  "extra_charges": [ { "text": "", "page": "" } ]
}

数値の最小値・最大値の制約はスキーマに書けないので、 weeks_min などは文字列で受け、原文に無い数字なら Python が unclear にします。

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

インコタームズは、原文から規則のコードと場所に分けて照らします。 ICCは2020年版で旧来のDAT（Delivered at Terminal）をDPU（Delivered at Place Unloaded）に改めたとしており、一覧に無いコードは terms_differ にします。 あわせて一覧で運賃と保険料を売り手が持つかを引き、負担の範囲が依頼と違う見積に「単価をそのまま比べない」と印を付けます。

システムへ連携する

購買管理の仕組みへは書き込みません。 作るのは比較表と確認メールの下書きまでで、見積の採用と発注は人が行います。 比較表は依頼ごとに1枚、仕入先を列にし、各セルに判定の色を付けて原文をコメントに入れます。

人が確認する

購買担当は、見積ごとに判定を見て、見方を分けます。

1. aligned は比較表の行を原本と並べて確かめる … 単価と数量の桁を目で追うだけです
2. terms_differ を最優先で見る … 払う額と納期に直結します。原文のセルを読み、確認メールの下書きを直して送ります
3. currency_differ と validity_short は受けるかを決める … 通貨や期限を合わせてもらうかを決めます
4. incomplete と needs_human は原本を開く … 品番の抜け、代替品の提案、読み取りの信頼度の低い行です
5. 確かめた支払条件の書き方を仕入先マスタに積む … 翌月から同じ書き方は機械で same になります

目標は、120件をならして1件10分です。

例外に対処する

6行目の「per 100」は、桁の誤りとして最も多い型です。 100個あたり85ユーロの見積を1個85ユーロと読むと、その仕入先は比較から外れ、いちばん安い仕入先を見逃します。

記録を残す

• 元の見積書のPDFと、受け取った日時・送り元・見積依頼の番号
• OCRが返したJSONの全文
• AIが返したJSONと、そのとき渡した見積依頼の品番の一覧
• 照合に使った見積依頼の条件の版と、照合の結果
• 比較表の版と、人が判定を覆した記録（どのセルを、どちらに変えたか）
• 仕入先への確認の内容と回答、改訂版との対応

「見積依頼の条件の版」を残すのは、数量や希望納期を変えて依頼を出し直すことがあるためです。 どの条件で比べて決めたかを、後から確かめられるようにします。