海外の部品メーカーの英文の技術データシートを読み取り、定格・寸法・使用温度範囲・認証を部品マスタに転記して、設計条件に合わない項目を拾う

処理の起点を決める

起点は2つあります。データシートが受付フォルダに入ったときと、改版のお知らせが届いたときです。

1つ目は、受付フォルダ（Amazon S3）にPDFが保存されたことです。設計者が型番と部品の種類を登録してPDFを上げると、保存の通知で AWS Lambda が動きます。部品の種類が無いものは動かしません。 照らす選定条件が決まらないためです。

2つ目は、改版のお知らせが届いたときです。新版を同じ型番で上げると、旧版と項目ごとに並べる処理が追加で動きます。

月に1回、版の日付が古い登録済みの部品の一覧を出し、購買の担当者が新版の有無を確かめます。

入力データを集める

質を決めるのは、下の3つです。 項目ごとに「どの表の値を入れるか」が決まっていないと、正しく取り出しても入れる場所が決まりません。

PDFの文字の層は、記号を確かめるために持ちます。 メーカーのサイトのデータシートはほとんどが電子的に作られたPDFで、OCRが µ を読めなかった値でも、文字の層には µA と残っています。

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

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

質問の答えが見つからなければ空のまま返ります。 質問は英語の文書だけで使え、非同期で1ページ30個までです。データシートは1ページ目と最後のほうに型番・版・認証がまとまっていることが多いので、Pages でそのページに絞って聞きます。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。同期の処理はPDF1ページまでなので非同期で読み、JobId は7日間しか有効でないため結果はその場でS3に保存します。

表は、表のタイトルと列の見出しから種類を決めます。 TABLE_TITLE か直前の LAYOUT_SECTION_HEADER が Absolute Maximum Ratings なら絶対最大定格、Recommended Operating Conditions なら推奨動作条件です。列の見出し（COLUMN_HEADER）の Min・Typ・Max・Unit・Conditions を、セルの ColumnIndex と結び付けます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは対応していないとされているので、別の形式で出し直してもらいます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものはメーカーか商社に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです。1冊にシリーズの全型番がまとまった大きな資料は、該当の型番のページだけを切り出します
4. 文字の層の取り出し … 電子的に作られたPDFなら、ページごとの文字を Python で取り出して保存します。記号の確認に使います
5. 型番の確認 … 登録された型番が1ページ目の文字に含まれるかを確かめます。違う型番のデータシートが上がる取り違えを、ここで止めます
6. 言語の確認 … 6言語に入らないデータシートは読み取りに回さず、担当者が目で見る一覧に入れます

AIに処理させる

させるのは、マスタの仕様項目ごとに、値・単位・条件・表の種類・ページを取り出し、原文の文字列と一緒に書き出すことです。 単位の換算と条件との照合はさせません。

4行目がいちばん起きやすい失敗です。 シリーズのデータシートでは、型番ごとの値が表の一部の行にしか無いことがあり、空いた欄を同じシリーズの別の型番の値で埋めると、その瞬間に違う部品の仕様がマスタに入ります。

指示内容を固定する

あなたは産業機器メーカーの部品管理の担当で、海外の部品メーカーの
英文の技術データシートから、部品マスタに入れる仕様を取り出します。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
{master_fields}（部品の種類ごとの項目名の一覧）
各項目について、value_raw、value_min、value_typ、value_max、unit_raw、
conditions_raw、table_kind、table_title_raw、page、status

【table_kind の選び方】
- absolute_max ...... 表の見出しが Absolute Maximum Ratings にあたる
- recommended ....... 表の見出しが Recommended Operating Conditions にあたる
- electrical ........ 表の見出しが Electrical Characteristics にあたる
- mechanical ........ 寸法の表または寸法図
- other ............. 上のどれでもない
- unclear ........... 見出しが無い、または判別できない

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数あり、1つに決められない

【厳守事項】
- 絶対最大定格の値を、推奨動作条件や使用温度範囲の値として
  使わないでください。表の見出しで決まらなければ table_kind を
  unclear にしてください。
- 保存温度（Storage Temperature）を使用温度範囲に入れないでください。
- 単位は書かれた文字のまま unit_raw に入れてください。換算しないでください。
  記号が読めない場合は、読めた文字のまま入れ、status を unreadable に
  してください。
- 測定の条件（温度、電源電圧、負荷など）が表の上や注記に書かれていれば、
  conditions_raw にそのまま写してください。注記の番号だけのときは、
  注記の本文も写してください。
- 型番 {part_number} 以外の行の値を使わないでください。
  シリーズの別の型番の値で空欄を埋めないでください。
- 認証や RoHS の記載は、書かれた文をそのまま写してください。
  適合しているかどうかを判断して書かないでください。
- 採用できるか、条件を満たすかを書かないでください。

【読み取り結果】{textract_layout_tables_queries}
【部品の種類】{part_category}

「保存温度を使用温度範囲に入れない」を明記しないと、入れます。 温度範囲を聞かれると、データシートの中でいちばん広い範囲を答えにしがちで、それはたいてい保存温度か絶対最大定格の値です。 禁じるのは、範囲の広さで選ぶ判断そのものです。

出力形式を固定する

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

{
  "file": "",
  "document_type": "datasheet",
  "part_number": "XQ-2215-T",
  "revision_raw": "Rev. D, 2026-06",
  "fields": [
    {
      "field": "operating_temp",
      "value_raw": "-40 to +105",
      "value_min": -40,
      "value_typ": null,
      "value_max": 105,
      "unit_raw": "°C",
      "conditions_raw": "",
      "table_kind": "recommended",
      "table_title_raw": "Recommended Operating Conditions",
      "page": 3,
      "status": "ok",
      "confidence": 0
    }
  ],
  "certifications_raw": ["UL Recognized, File No. ..."],
  "compliance_raw": ["RoHS compliant"]
}

1つ目の理由は、照合をプログラムの側に置けることです。 構造化出力のスキーマでは数値の最小・最大の制約（minimum、maximum）が使えないとされており、範囲の確かめはどのみちプログラムの仕事になります。 Python が単位をそろえ、選定条件と比べて印を付けます。

2つ目は、改版の差分を項目ごとに出せることです。 同じ field の値を旧版と新版で並べ、変わった項目だけを担当者に見せます。 版の文字列（revision_raw）は原文のまま残し、版の新旧は発行日で決めます。

システムへ連携する

部品マスタへの書き込みは、この構成からは行いません。 照合の一覧を担当者が確かめ、確定した値だけをマスタに登録します。マスタの値は図面と部品表に引き継がれ、誤った値が入ると設計の判断そのものを誤らせるためです。

設計者への通知は、out_of_condition の部品だけに、条件に合わない項目とページ番号を並べて送ります。

人が確認する

部品管理の担当者が開くのは、ok 以外の印が付いた項目です。 ok の項目は、値と出どころの一覧で流し見ます。

1. needs_human を先に見る … 型番がPDFに見つからないものは、取り違えの可能性があります。違う型番なら、それ以上の確認をせずに設計者に戻します
2. table_unclear の出どころを確かめる … 該当ページを開き、その値が絶対最大定格か推奨動作条件かを目で決めます
3. unit_unclear の単位を確かめる … µ、Ω、± を含む値は、PDFの該当箇所と見比べます
4. out_of_condition を設計者に送る … 値が正しく取れていることを確かめてから送ります。読み取りの誤りで条件外になったものを送らないためです
5. マスタへの登録を確定する … 確定した値と、確かめた担当者の名前を残します

4番目の順序を崩さないでください。 読み取りの誤りによる「条件外」を送ると、設計者は正しい部品を外して別の部品を探し始めます。

例外に対処する

上から3行目が、取り返しのつかない失敗を生みます。 違う型番で照合が通ると、誤った仕様が「確認済み」としてマスタに入るので、型番は前処理と人の確認の2か所で見ます。

記録を残す

• 元のデータシートと、受け取った日時、入手先（メーカーのサイト／商社）、版
• AWS Textract が返したJSONの全文と、使った質問の一覧
• PDFの文字の層（取り出せたもの）
• Claude API が返したJSON（原文と、数値に分けた値の両方）
• 照合の結果と、そのとき参照した選定条件とマスタの項目の決まりの版
• 担当者が値や表の種類を直した記録 … どの項目を、どう変えたか、誰が確かめたか

選定条件の版を残すのは、条件が後から変わるためです。 条件が広がると過去に ok だった部品が条件外になり、当時の条件が残っていれば照らし直す範囲がすぐに決まります。