海外の鋼材メーカーから届く英文のミルシートを読み取り、発注仕様と照合して、受入の可否と要確認点を出す

処理の起点を決める

受付フォルダ（Amazon S3）にファイルが保存されたことを起点にします。 ミルシートは船積みの前後にまとまって届くので、1日1回の定時処理にすると、船積みの日の分が翌日にずれ込みます。入荷までの時間を問い合わせに使いたいので、届いたら動かします。

入る経路は、メールの添付を輸入担当が保存するものと、仕入先のポータルから取得したものの2つです。どちらも同じフォルダに入れ、そこから先は区別しません。

処理が終わったファイルは処理済みの場所へ移します。移すのは、判定の一覧への書き出しまで成功したときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の2つです。 発注仕様が表になっていなければ、比べる相手がありません。仕入先の書き方の一覧は、「0,025」を0.025と読むのか、0と025の2つの値と読むのかを決めるために持ちます。 証明書だけからこれを決めようとすると、千の位の区切りと取り違えます。

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

1ページのPDFは同期処理（AnalyzeDocument）、2ページ以上は非同期処理（StartDocumentAnalysis）で読みます。 同期処理はPDFとTIFFが1ページ・10MBまでで、複数ページのものはS3に置いて処理を始め、完了の通知（Amazon SNS）を受けてから結果（GetDocumentAnalysis）を取ります。非同期の結果は既定で7日間しか取り出せないので、受け取ったらすぐに自社の保管先へ書き出します。

問いの数には上限があります。 同期処理は1ページ15問まで、非同期処理は1ページ30問までです。識別情報の問いは8問程度に絞り、成分の値は問いではなく表から取ります。 成分を1つずつ問いにすると、上限にすぐ届きます。

発注書と発注仕様は、発注番号で引きます。 証明書の発注番号が読めなかったときは、仕入先とヒート番号から直近の発注を候補として出し、確定は人が行います。

AIへ渡す前に整形する

1. 形式の確認 … Textract が受け付けるのはJPEG、PNG、PDF、TIFFです。XFA形式のPDFには対応していません。 対応外の形式はPDFに変換します
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 仕入先に保護のないものを送り直してもらいます
3. ページ数とサイズの確認 … 同期処理は1ページ・10MBまで、非同期処理はPDFとTIFFで3,000ページ・500MBまで
4. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上で、150dpiで8ポイントの文字に当たります。成分表の小さな文字が、この下限に近いことがあります
5. ヒートごとの分割 … 1枚に複数のヒートが並ぶものは、生成AIの対応付けの段階で行ごとに分けます
6. 重複の検知 … 同じ仕入先・同じヒート番号の証明書が直近にあれば、再発行か重複かの印を付けます

4番目を軽く見ないでください。 成分表は小さな文字で数字が詰まっていることが多く、「0.08」と「0.03」の読み違いは、そのまま仕様の判定に効きます。 信頼度の低いセルは、値として使わずに人へ回します。

AIに処理させる

させるのは、表の列と行を「どの成分・どの試験の値か」「単位は何か」に対応付け、値を原文のまま書き出すことだけです。

いちばん下の行が、この構成で大事な区別です。 証明書には「Min」「Max」「Actual」のような列が並び、規格値の列を実測値として読むと、どの材料も「合格」になります。 規格値の列は照合には使わず、実測値の列を正しく選ぶためだけに見分けます。

規格値の欄を照合に使わない理由は、もう一つあります。 Textract が検出できる文字の一覧には、「≤」「≥」「±」が含まれていません。「≤0.030」のような規格値の書き方は、記号が落ちて「0.030」だけが読まれることがあります。 上限か下限かが分からなくなるので、仕様値は必ず自社の発注仕様から取ります。

4行目がいちばん起きやすい失敗です。 信頼度の低いセルや空のセルがあると、同じ証明書の別のヒートの値や、規格の中央の値で埋めたがります。埋まった瞬間、その値は仕様の判定を通ってしまいます。

指示内容を固定する

あなたは購買部で、海外の仕入先から届いた英文のミルシートを確認する立場です。
OCRが返した表とキーと値だけを見て、値を書き出してください。推測で埋めないでください。

【やること】
1. 成分の表について、列見出しから元素（C, Si, Mn, P, S, Cr, Ni, Mo など）を特定し、
   ヒートごとに実測値を書き出す
2. 機械的性質の表について、試験の種類（引張強さ、耐力、伸び、絞り、硬さ、衝撃値）と、
   書かれている単位を特定し、実測値を書き出す
3. 衝撃試験の温度と単位、試験片の数を書き出す
4. 発注番号、ヒート番号、材料規格、寸法、数量、証明書の種類の表記を書き出す
5. 表の中で、規格値（Min / Max / Spec など）の列と実測値（Actual / Result など）の
   列を区別し、どの列を実測値として使ったかを書く

【厳守事項】
- value には、証明書に書かれた文字列をそのまま入れてください。
  「0,025」を 0.025 に直さないでください。桁を足したり丸めたりしないでください。
- 単位を換算しないでください。unit には書かれている単位をそのまま入れ、
  書かれていなければ空にして status を unit_missing にしてください。
- 規格値の列の値を、実測値として書き出さないでください。
  区別がつかない場合は status を ambiguous にしてください。
- 読めないセル、空のセルは status を unreadable または missing にしてください。
  別のヒートの値や、規格の典型値で埋めないでください。
- confidence には OCR が返した値をそのまま入れてください。
- 合格・不合格、発注どおりかどうかは書かないでください。
- 1枚に複数のヒートがある場合は、ヒートごとに分けて書き出してください。
- ミルシート以外の書類（梱包明細、請求書など）と判断した場合は、
  書き出しをせず document_type に種類を書いてください。

【OCRの結果（表・キーと値・問いへの答え）】{textract_result}
【この仕入先の書き方（小数点、よく使う単位）】{supplier_profile}

「0,025 を 0.025 に直さない」を明記しないと、親切に直します。 直した値が正しいこともありますが、千の位の区切りとして使っている仕入先で同じことをされると、値が千倍ずれます。 解釈は仕入先の一覧を持つ Python 側で行います。

「単位を換算しない」も同じ理由です。 換算させると、ksi から MPa への係数を使った結果だけが返り、元の値と単位が消えます。 人が確かめるときに、証明書のどの数字から来たのかが追えなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（あらかじめ決めたJSONの形に沿った応答だけを返させる機能）を使い、status の選択肢を enum で固定します。

{
  "document_type": "mill_certificate",
  "identifiers": {
    "po_no": "", "heat_no": "", "material_spec": "", "size": "", "quantity": "",
    "certificate_type_text": ""
  },
  "heats": [
    {
      "heat_no": "",
      "chemical": [
        { "element": "C", "value": "", "unit": "%", "status": "ok | missing | unreadable | unmapped | ambiguous",
          "confidence": 0, "source_column": "" }
      ],
      "mechanical": [
        { "test": "tensile_strength", "value": "", "unit": "", "status": "ok | unit_missing | missing | unreadable",
          "confidence": 0 }
      ],
      "impact": { "temperature": "", "temperature_unit": "", "values": [], "status": "" }
    }
  ],
  "signature_found": false,
  "verdict": "conforming | needs_query | nonconforming_candidate | needs_human",
  "findings": [],
  "query_draft": ""
}

verdict と findings は、生成AIではなく Python の比較が埋めます。

1つ目の理由は、値と判定を別の層に置けることです。 heats はAIが原文のまま埋め、Python が単位と小数点をそろえてから発注仕様と比べます。

2つ目は、findings に「なぜそうなったか」を項目の単位で残せることです。 「Cr：実測 16.2%、発注仕様 下限 16.5%」のように、元の値と仕様値を並べて書きます。問い合わせの下書きは、この findings からだけ作ります。

3つ目は、source_column と confidence で確認が速くなることです。 どの列を実測値として使ったか、どれくらいの信頼度で読んだかが一覧で分かり、画像を開く前に怪しいセルの見当がつきます。

システムへ連携する

購買管理システムへは書き込みません。 受入の判定を記録するのは品質管理部で、この構成が出すのは照合の結果と候補までです。 自動で「受入済み」にすると、仕様外の材料がそのまま工程に出ていく経路ができます。

問い合わせも下書きまでにします。 送るのは輸入担当です。仕入先との取引の経緯によって、書き方も宛先も変わります。

人が確認する

人が開くのは、conforming 以外のものです。 conforming のものは、一覧で仕入先とヒート番号を流し見て、品質管理部へ回します。

1. needs_human を先に見る … 読めなかったセルと、識別情報が合わないものです。多くは画像を開けば数十秒で片付きます
2. nonconforming_candidate の根拠を確かめる … findings の値が証明書の実測値の列にあるかを、画像で確かめます。規格値の列を読んでいないかを必ず見ます
3. needs_query の下書きを直して送る … 足りない試験や証明書の種類について、発注仕様書の番号を添えて問い合わせます
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目を省かないでください。 nonconforming_candidate は、材料を止めるか、仕入先に特別採用（仕様外でも条件付きで受け入れること）を相談するかに直結します。 読み違いで止めた1件は、生産の予定に響きます。

目標は、360枚をならして1枚3分です。 conforming 以外が2〜3割という想定で、それより多い月は、読み取りの信頼度が落ちているか、仕入先の書き方の一覧が古くなっています。

例外に対処する

上から3行目は、アジアの仕入先で起きます。 成分表の見出しが英語で書かれていれば数値は読めますが、注記や試験条件が中国語だけで書かれていると、衝撃試験の温度のような大事な条件が落ちます。

記録を残す

• 元のミルシートのファイルと、受け取った日時・仕入先・経路
• Textract が返したJSONの全文（非同期の結果は7日で消えるので、自社の保管先へ書き出したもの）
• 生成AIが書き出した値（原文のまま）と、Python が正規化した値
• 判定に使った発注書と発注仕様の内容と、そのときの仕様の版
• 人が判定を覆した記録 … どの項目を、どちらに、なぜ変えたか
• 問い合わせと仕入先の回答、特別採用の記録
• 仕入先ごとの unreadable と needs_query の発生率

4つ目で「仕様の版」を残すのは、発注仕様が改訂されるためです。 上限を変えた後に過去の判定を見返すと、当時の基準で合っていたのか、今の基準で外れているのかが区別できなくなります。