海外メーカーの試薬に付く英文のSDSを読み取り、化学物質台帳へ転記して、版の更新と保管場所の見直しが要るものを拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 試薬は毎日届くので、1日1回の定時処理にはしません。改訂で区分が変わったものを、研究員が使い始める前に見つけたいからです。

研究員が入れるファイルには、購買システムの発注番号をファイル名に付けてもらいます。発注番号があれば、どの研究室が・いつ・どれだけ買ったかを購買システムから引けます。 付いていないファイルは、処理を止めずに needs_human で受け、担当者が発注番号を足します。

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

入力データを集める

質を決めるのは、下の3つです。 台帳に改訂日が無ければ版を比べられず、保管庫の決まりが表になっていなければ見直しを拾えません。メーカーの一覧の「日付の書き方」が無いと、「03/04/2026」を3月4日と4月3日のどちらで読むかが決まりません。

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

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

問い合わせ（Queries）は、場所の決まらない値を拾うために使います。 「What is the revision date?」「What is the product number?」「What is the signal word?」のように英語の質問を渡し、Alias に REVISION_DATE のような名前を付けます。答えには信頼度が付き、見つからなければ空で返ります。 非同期の処理では1ページあたり30件まで問い合わせを渡せます。

改訂日は、問い合わせとSection 16の両方から取ります。 2つが一致しなければ needs_human にします。印刷日（Print Date）を改訂日として拾っていないかは、ここで分かります。

AIへ渡す前に整形する

1. 形式の確認 … 扱えるのはJPEG、PNG、PDF、TIFFです。XFA形式のPDFには対応していません。 対応外のものはPDFに変換します
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 メーカーのサイトから取り直します
3. ページ数とサイズの確認 … 非同期の処理はPDFで500MB・3,000ページまで。SDSなら収まります
4. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上で、150dpiで8ポイントの文字に当たります。成分の表や脚注の小さな文字が、この下限に近いことがあります
5. 言語の確認 … 英語以外の版が入っていないかを見ます。英語以外なら英語の版を取り直します
6. Sectionの切り分け … LAYOUT_SECTION_HEADER の文字列に「SECTION」と番号があるものを境にします。番号が見つからない見出しは、項目名（Hazards identification など）で当てます
7. ヘッダーとフッターの除去 … 各ページに繰り返し出る品名や印刷日を、本文から外します。ただし改訂日の候補として別に残します

6番目はAIに任せません。 見出しの切り分けを生成AIに頼むと、ページをまたいだ表を2つのSectionに割ったり、逆に2つを1つにしたりします。境界はレイアウトの要素で機械的に決め、AIにはSectionの中身だけを渡します。

AIに処理させる

させるのは、Sectionごとの文と表から台帳の項目を埋め、根拠にした文字列をそのまま写すことだけです。

Section 3の含有率は範囲のまま写させます。 「10 - 20 %」を「15%」にしません。丸めた値を台帳に入れると、次の版と比べたときに変わっていないものまで差分に出ます。

1行目がいちばん起きやすい失敗です。 「7647-01-?」のように桁がつぶれたCAS番号を渡すと、それらしい番号に直して埋めます。CAS番号の右端の1桁は、番号全体が正しいかを確かめるための検査用の数字です。 検算は後段の Python で行うので、AIには読めたとおりに写させます。

指示内容を固定する

あなたは研究所の安全管理グループで、英文のSDSから化学物質台帳の項目を写す立場です。
渡すのは、OCRがSectionごとに切り分けた文と表です。そこに書かれたことだけを使ってください。

【写す項目】
- section1: product_name, product_number, manufacturer
- section2: hazard_classes（区分の名称と区分の番号の組）, signal_word, h_statements
- section3: components（成分ごとに name, cas_no, concentration）
- section7: storage（温度, 遮光, 不活性ガス, 避ける物質）
- section14: un_number, transport_class
- dates: revision_date_candidates, version, print_date

【status の付け方】
- ok ......... 値が書かれており、そのまま写せた
- missing .... そのSectionに記載が無い。値は「不明」とする
- unreadable . 文字は検出されているが、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない

【厳守事項】
- 記載がなければ「不明」とし、status を missing にしてください。
  他のSectionから推測して埋めないでください。
- CAS番号は読めたとおりの文字列で写してください。
  桁を補う、ハイフンを足す、それらしい番号に直すことをしないでください。
- 含有率は書かれた範囲のまま写してください。中央の値に丸めないでください。
- 区分は書かれた名称と番号のまま写してください。
  成分や物性から区分を推定しないでください。
- 日付は、改訂日・版・印刷日の候補を、書かれていた文字列と場所ごとに
  すべて出してください。どれが改訂日かを1つに選ばないでください。
- 保管場所や、国内の法令に当たるかは書かないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- SDSでない書類（分析証明書など）と判断した場合は、写さずに
  document_type に種類を書いてください。

【Sectionごとの読み取り結果】{sections}
【問い合わせへの答え】{query_results}

「改訂日を1つに選ばない」と書かないと、最初に見つけた日付を選びます。 ヘッダーの印刷日が先に出てくるメーカーでは、毎回それが改訂日になり、全件が「改訂された」と判定されます。 選ぶのは規則の側（第7章の出力形式）です。

「区分を推定しない」も明記します。 何も言わないと、Section 2が空のSDSに対して成分から区分を考え、もっともらしい区分を埋めます。 それは台帳に載った瞬間に事実として扱われます。

出力形式を固定する

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

{
  "sds_id": "",
  "document_type": "sds",
  "product": { "name": "", "number": "", "manufacturer": "" },
  "dates": {
    "revision_candidates": [ { "text": "", "location": "header | section16 | query" } ],
    "version": "", "print_date": ""
  },
  "hazard_classes": [ { "class": "", "category": "", "status": "ok", "evidence": "" } ],
  "signal_word": "",
  "components": [
    { "name": "", "cas_no": "", "concentration": "", "status": "ok", "evidence": "" }
  ],
  "storage": { "temperature": "", "light": "", "inert_gas": "", "incompatible": "" },
  "un_number": "",
  "verdict": "new_entry | revised | unchanged | storage_review | needs_human"
}

verdict はAIに埋めさせません。 後段の Python が次の規則で決めます。

1つ目の理由は、版の比較を規則で行えることです。 改訂日だけでなく、区分と成分の差分も Python で取ります。改訂日が同じなのに区分が違う、というメーカー側の差し替えも拾えます。

2つ目は、CAS番号の検算を機械で行えることです。 検査用の1桁は、右から2桁目に1、3桁目に2…と重みを掛けて足し、10で割った余りと一致します。CASの説明では 107-07-3 が例に挙がっており、1×7＋2×0＋3×7＋4×0＋5×1＝33 で、余りの3が右端と一致します。 合わなければ読み違いです。

3つ目は、evidence で確認が速くなることです。 差分の行ごとに、SDSのどの文字列を根拠にしたかが並びます。

システムへ連携する

台帳への書き込みは、担当者の承認の後だけです。 自動で書き込むと、改訂日の読み違い1件で、正しい版が古い版で上書きされます。書き込むときは前の版の値を履歴に残し、上書きしません。

購買システムは読み取りだけです。発注番号が見つからなくても、購買システムの側を直しに行きません。

人が確認する

人が開くのは unchanged 以外のものです。 unchanged は件数と品名を一覧で流し見ます。

1. needs_human を先に見る … CAS番号の検算が合わないもの、改訂日の候補が食い違うもの。多くはSDSの画像を見れば数秒で決まります
2. revised の差分を確かめる … 区分・成分・保管条件のどこが変わったかを、evidence とSDSの該当箇所で見ます
3. new_entry を登録する … 品名・CAS番号・区分を確かめて承認します
4. storage_review を研究員へ依頼する … 移し替えの依頼の下書きを直して送り、完了の報告を受けて閉じます
5. 判定を覆したら記録する … どの項目を、どう直したかを残します

4番目の「閉じる」を省かないでください。 連絡しただけでは保管庫は変わりません（第3章の（d））。

目標は、160件をならして1件9分です。 同じ版の買い直しが半分ほどという想定で、それより開く件数が多い月は、メーカーの一覧の日付の書き方が足りていないことが多いです。

例外に対処する

7行目の「AIにもう一度読ませて直さない」が大事です。 読み直させると、検算が合う番号を作って返すことがあります。検算が合うことと、正しい物質の番号であることは別です。

記録を残す

• 元のSDSのPDFと、受け取った日時・発注番号
• OCRが返したJSONの全文（レイアウト・表・問い合わせへの答え）
• AIが返したJSONと、そのとき参照した台帳の行と保管庫の決まり
• 判定の結果と、版の差分
• 人が判定を覆した記録 … どの項目を、どう直したか
• 台帳へ登録した日時と承認者、上書きした前の版の値
• storage_review の依頼日と完了日

「上書きした前の版の値」を残すのは、改訂の経緯を後から追えるようにするためです。 ある試薬の区分がいつ変わり、そのとき保管庫を移したかを、事故やヒヤリハットの後に確かめることがあります。