海外の部品メーカーから届く英文の適合宣言書を読み取り、型番・適用規格と版・発行日・署名者を部品の適合台帳に転記して、規格の版が古いものと型番の食い違いを拾う

処理の起点を決める

受領用の保管先（Amazon S3 のバケット）に宣言書が保存されたことを起点にします。 宣言書は月末にまとまって届くわけではないので、1日1回の定時処理にはしません。 届いた日のうちに食い違いが分かれば、仕入先とのやり取りが1往復早く始まります。

保存のたびに1通ずつ動かし、StartDocumentAnalysis に ClientRequestToken を付けます。 同じトークンで呼ぶと同じ JobId が返るとされており、ファイルのハッシュ値を使えば同じ宣言書を二重に分析しません。

分析が終わると、NotificationChannel に指定した Amazon SNS のトピックに完了の状態が届き、2つ目の Lambda が結果を取りに行きます。 JobTag には仕入先のコードを入れます。JobId は7日間だけ有効なので、結果はすぐに取り出して保管します。

入力データを集める

質を決めるのは部品マスタの「仕入先の型番」と「旧型番」の列です。 宣言書に書かれるのは仕入先の型番で、この列が空だと照合は全件 not_found になります。 規格マスタの基準は品質保証部が決めた値で、この構成は読むだけです。

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

分析の結果は GetDocumentAnalysis で取り出します。 JobStatus が SUCCEEDED か PARTIAL_SUCCESS かを確かめ、1回に最大1,000ブロックずつ NextToken で続きを取ります。結果は Block の配列で、種類（BlockType）で中身を見分けます。

質問は、宣言書に共通して書かれる項目に絞って投げます。

公式の説明では、答えが見つからないときは答えの要素が空のまま返ります。 ここが「書かれていない」を判定する根拠です。型番と規格は質問にしません。 1通に何十行も並び、1つの答えでは取り切れないので、表と全文の行から取ります。複数の行や列にまたがる見出しのセルは MERGED_CELL として返るので、関係（Relationships）で元のセルにたどります。

AIへ渡す前に整形する

1. 形式の確認 … 対応形式は JPEG、PNG、PDF、TIFF で、XFA の PDF は扱えません。Word で届いたものは PDF にします
2. パスワードの確認 … PDF はパスワードで保護されていてはならないとされています。保護されたものは仕入先に保護のない版を頼みます
3. サイズとページ数 … 非同期の処理では、PDF と TIFF が500MB・3,000ページまでです
4. 文字の大きさ … 検出できる文字の高さの下限は15ピクセル（150 DPI で8ポイント）です。ファクスの画像や写真は下限に近いことがあります
5. 宣言書以外のページを外す … 添え状、試験成績書、RoHS の分析データが同じ PDF に入っていることがあります。1ページ目のタイトルの行で切り分けます
6. 重複の検知 … 同じ仕入先・発行日・型番の並びの宣言書が台帳にあれば、二重に取り込まない印を付けます

5番目を省かないでください。 試験成績書にも規格の番号と版が並んでいて、宣言していない規格を宣言したものとして台帳に載ります。

AIに処理させる

させるのは、OCRの結果を台帳の項目にそろえ、規格の文字列を番号と版に分けることだけです。

いちばん大事なのは、規格の版を補わないことです。 年が無い規格は、そのまま年を空にします。生成AIは規格の番号を見ると、よく知られた年を付け足しがちで、 付け足した瞬間に「版が書かれていない」という取り直しの理由が消えます。

指示内容を固定する

あなたは製造業の品質管理部門で、海外の部品メーカーから届いた英文の
適合宣言書（Declaration of Conformity）を部品適合台帳の項目にそろえる担当です。
渡すのは AWS Textract の読み取り結果（キーと値の組、表、質問への答え、
署名の位置、全文の行）だけです。書かれていないことを推測で埋めないでください。

【そろえる項目】
1. manufacturer: 製造者の名称と住所
2. models: 宣言の対象の型番。1つずつ配列にする
3. legislation: 適用法令（指令・規則の番号と名称）
4. standards: 規格。1行ごとに number（番号）、year（年）、amendments（追補の記号）に分ける
5. date_of_issue と place_of_issue
6. signatory: 氏名と役職、署名のブロックがあるか

【厳守事項】
- 規格に年や追補が書かれていなければ、year と amendments は空にしてください。
  よく知られた年を補ったり、最新の版を推定したりしないでください。
- 型番は書かれた文字列をそのまま写してください。「*」「x」「…」などの
  ワイルドカードの記号を消したり、展開したりしないでください。
- 日付は、月の名前で書かれていれば YYYY-MM-DD にしてください。
  数字だけで日と月の順が決められないときは、元の文字列を raw に写し、
  status を ambiguous にしてください。
- 試験成績書や添え状の中の規格を、宣言の対象の規格に含めないでください。
  宣言の対象かどうか決められない行は status を needs_check にしてください。
- 規格の版が新しいか古いか、部品が適合しているかは書かないでください。
- 読み取り結果に値が無い項目は status を missing にしてください。
  項目名（例: "Date of issue:"）があっても値が空なら missing です。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- confidence は OCR が返した値をそのまま入れてください。
- 適合宣言書ではない書類と判断した場合は、document_type に種類を書き、
  ほかの項目は空にしてください。

【読み取り結果】{textract_result}
【仕入先】{supplier_code} {supplier_name}

「よく知られた年を補わない」を書かないと、年の無い規格に年が入ります。 直された台帳は見た目がそろって読みやすく、それだけに取り直しの理由が見えなくなります。 「試験成績書の規格を含めない」は、1ページ目に宣言書と試験の要約が一緒に印刷された書式があるため、前処理のあとにも書いています。

出力形式を固定する

応答は、Claude API の構造化出力で次の形の JSON に固定します。 公式の説明では、output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに合う JSON が返るとされています。

{
  "doc_id": "DOC-2026-10-0412",
  "document_type": "declaration_of_conformity",
  "supplier_code": "S-0731",
  "manufacturer": { "name": "", "address": "", "status": "ok", "evidence": "" },
  "models": [
    { "raw": "PSU-120-24*", "status": "ok", "confidence": 98.1, "evidence": "Model: PSU-120-24*" }
  ],
  "legislation": [
    { "raw": "", "status": "ok", "evidence": "" }
  ],
  "standards": [
    { "raw": "EN 6XXXX-1:2014", "number": "EN 6XXXX-1", "year": "2014",
      "amendments": "", "status": "ok", "confidence": 96.4, "evidence": "" }
  ],
  "date_of_issue": { "value": "2026-09-18", "raw": "18 September 2026", "status": "ok" },
  "place_of_issue": { "value": "", "status": "missing" },
  "signatory": { "name": "", "title": "", "signature_block": true, "status": "ok" }
}

例の規格の番号は伏せ字です。この JSON には判定がなく、 照合の結果はプログラムが付け足します。

AIの層とプログラムの層を分けるのは、規格マスタが変わるからです。 基準の版が改まったとき、保存した JSON に新しい基準を当て直すだけで、古くなった宣言書の一覧が出ます。 pattern を人に回すのは、「*」が色の違いだけを表す仕入先もあれば、定格の違う製品をまとめる仕入先もあるからです。

システムへ連携する

部品マスタには書き込みません。 宣言書の型番に合わせてマスタを直すと、別の部品の宣言書で穴を埋めることになりかねません。部品適合台帳は、古い宣言書の行を消さずに履歴として残します。

人が確認する

品質管理の担当が開くのは request_update と needs_human だけです。 ok のものは一覧で件数と仕入先を流し見ます。

1. needs_human を先に見る … not_found が表記の違いなら、購買の担当に部品マスタの修正を頼みます
2. request_update の根拠を確かめる … evidence と原本を見比べ、年が本当に無いか、版が本当に古いかを確かめます
3. 古い版を受け入れるかを決める … 受け入れるなら、その理由を台帳に残します
4. 取り直しを頼む … 下書きを購買の担当が直して送ります。送信は人が行います

2番目を省かないでください。 OCRが年の末尾を読み落とすと、プログラムはそれを古い版と判定します。目標は、240通をならして1通4分です。 開くのは3割前後という想定です。

例外に対処する

いちばん多いのは、3行目と5行目です。 どちらも受け取り方の問題で、英語の版と単独のファイルを取引の条件として伝えると減ります。

記録を残す

• 宣言書の原本と、受け取った日時・仕入先・メールの件名
• Textract の結果の全文（Block の配列）と JobId
• 生成AIがそろえた JSON と、そのときのプロンプトの版
• 照合の結果（model_match、standard_check、verdict）と、そのとき参照した規格マスタの版
• 人が判定を覆した記録 … どの項目を、どちらに変えたか、古い版を受け入れた理由
• 取り直しを依頼した日、仕入先の回答、新しい宣言書との対応

4つ目で「そのときの規格マスタの版」を残すのは、基準が後から変わるためです。 当時の基準が残っていないと、当時は current だったものがどの時点で古くなったのかを説明できません。