海外の試験・認証機関から届く英文の試験報告書を読み取り、試験項目・適用規格・判定を認証台帳に転記して、不合格と条件付き合格の項目を拾う

処理の起点を決める

受付用の S3 の場所に PDF が保存されたことを起点にします。 担当者はメールから PDF を保存するだけで、そこから先は自動で動きます。報告書は1通ずつ届くので、届いたその日に下書きが出る形にし、1日1回のまとめ処理にはしません。申請の締切が近い製品では、報告書が届いた当日に Fail を知りたいからです。

処理は2段に分かれます。1段目は保存を起点に Textract の解析を始めるところまで、2段目は Textract の完了通知を起点に結果を取り出すところからです。解析には数十秒から数分かかるため、1つの処理の中で待ち続けません。

解析を始めるときは ClientRequestToken に報告書ファイルのハッシュ値を入れます。同じトークンで呼べば同じ JobId が返るため、保存の通知が二度届いても解析は1回で済みます。 JobTag には製品コードを入れ、完了の通知から製品を引けるようにします。

入力データを集める

質を決めるのは、下の2つです。 必要な規格と版が台帳に無ければ、第3章の（c）の版の違いは拾えません。機関ごとの判定の書き方の一覧が無ければ、「P」を Pass と読んでよいのか、「Complies」を Pass と同じに扱ってよいのかが決まりません。

機関の一覧は、最初は過去の報告書3通ずつから作ります。 6社なら18通です。判定欄の語と、条件付きの書き方（「Pass*」「Pass, see remark」など）を書き出しておくと、第7章の「AIに何をさせるのか」の指示に使えます。

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

結果は1回では取り切れません。 GetDocumentAnalysis は1回の呼び出しで最大1,000個のブロックを返し、残りがあれば NextToken が付きます。200ページの報告書ではブロックが数万個になるので、NextToken が無くなるまで繰り返し呼びます。 途中で止めると、末尾の付録にある試験結果の一覧が丸ごと抜けます。

JobId は7日間しか有効ではありません。 取り出した結果はすぐに S3 に保存し、後から読み直すときは S3 の写しを使います。OutputConfig で結果を自社のバケットに出させる方法もあります。

問い合わせ（QUERIES）は表紙の決まった項目にだけ使います。問い合わせは英語の書類でだけ使え、非同期では1ページあたり30個までです。報告書番号・発行日・試験機関・型式・適用規格の5つを表紙のページに投げれば足ります。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・TIFF・PDF 以外は止めます。XFA を使った PDF は読めません
2. パスワードの確認 … パスワード付きの PDF は読めません。 試験機関から保護付きで届いたものは、解除したものを送ってもらいます
3. ページ数とサイズの確認 … 非同期で PDF・TIFF は 500MB・3,000ページまで。超えるものは分けます
4. 表の組み直し … CELL の行番号・列番号から表を2次元に組み、結合セルは元のセルに値を広げます
5. 表の選別 … 題名や列見出しに「Result」「Verdict」「Clause」「Requirement」などを含む表を、試験結果の一覧の候補にします
6. ページをまたぐ表の連結 … 列見出しが同じで、続くページの先頭にある表を1つにつなぎます
7. 言語の確認 … 本文の行に英字以外の文字が多いページは、英文でない可能性があるので印を付けます

4番目と6番目を軽く見ないでください。 試験結果の一覧は、ほぼ必ず複数ページにまたがり、項目名のセルが結合されています。組み直さずに AI に渡すと、2ページ目以降の行がどの試験項目に属するのかが分からなくなります。

7番目は、Textract が日本語を読めないことへの備えです。 英文の報告書に日本語の添え状が付いてくることがあり、そのページは文字として取れません。取れなかったことに気づけるように、印を残します。

AIに処理させる

させるのは、組み直した表の行を、台帳の形にそろえることだけです。 判定の良し悪しは決めさせません。

2行目がいちばん起きやすい失敗です。 一覧の途中に判定欄が空の行があると、生成AIは前後が Pass なので Pass だろうと埋めがちです。それは試験されていない項目かもしれません。 空は空のまま返させ、後段のプログラムが「判定なし」として拾います。

指示内容を固定する

あなたは品質保証部で、海外の試験機関が発行した英文の試験報告書を
認証台帳に写す担当です。
渡すのは、OCRが読み取った表を行と列に組み直したものと、その脚注・注記です。
推測で埋めないでください。

【やること】
1. 表の各行を、台帳の1行にそろえてください。
   列は test_item / standard / edition / amendment / clause /
   verdict_raw / remarks / source にそろえます。
2. 規格の表記（例：EN 55032:2015+A1:2020）は、
   standard（EN 55032）、edition（2015）、amendment（A1:2020）に分けてください。
3. verdict_raw には、判定欄に書かれた語をそのまま写してください。
   P、Pass、Complies、N/A、Fail、F、Pass*、See remark などを、
   別の語に言い換えないでください。
4. 行の備考欄、表の脚注、本文の注記で、その行を参照しているものがあれば、
   remarks に原文のまま写してください。要約しないでください。
5. source には、ページ番号・表の番号・表の中の行番号を入れてください。

【厳守事項】
- 判定欄が空の行は、verdict_raw を空文字にしてください。
  前後の行から判定を補わないでください。
- 版が書かれていない規格は edition を空文字にしてください。
  最新版だと仮定しないでください。
- 認証の申請に使えるかどうか、合格と言えるかどうかは書かないでください。
- 表の行でないもの（見出し、ページ番号、繰り返しの列見出し）は行にしないでください。
- 英文でない文字列が混ざっていて読めない場合は、
  その行の remarks に「読み取り不可」とだけ書いてください。

【この試験機関の判定の書き方】{lab_profile}
【表と脚注】{tables_with_footers}
【本文の注記】{notes}

「言い換えないでください」を判定と備考の両方に書くのが要点です。 生成AIは、P と Pass と Complies を同じ意味として扱うのが得意で、何も言わなければ揃えてしまいます。揃えること自体は後段でやりたい作業ですが、揃える規則を自社が持つことに意味があります。 機関によっては「Complies」を条件付きの意味で使うことがあり、その判断は機関の一覧に置きます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す）を使い、列の抜けや型の崩れを防ぎます。

{
  "report": {
    "report_no": "",
    "issue_date": "",
    "lab_name": "",
    "model": "",
    "unreadable_pages": []
  },
  "rows": [
    {
      "test_item": "",
      "standard": "",
      "edition": "",
      "amendment": "",
      "clause": "",
      "verdict_raw": "",
      "remarks": "",
      "source": { "page": 0, "table": 0, "row": 0 }
    }
  ]
}

1つ目の理由は、AI の出力と判定の正規化を別の層に置けることです。 verdict_raw は AI が写し、Pass／Fail／N/A／条件付き／判定なし への振り分けは、後段の Python が機関の一覧を見て行います。

2つ目は、source で確認が速くなることです。 担当者は印の付いた行のページと表の行番号から、報告書の該当箇所を直接開けます。200ページを頭から探す必要がありません。

3つ目は、構造化出力の制約を知ったうえで使えることです。 Claude API の構造化出力では、オブジェクトに additionalProperties: false が必要で、minimum などの数値の制約や minLength などの文字列の制約は使えません。ページ番号の範囲や文字数の検査は、受け取った後に Python で行います。

システムへ連携する

認証台帳の確定済みの行は書き換えません。 この構成が書き出すのは「下書き」の行で、担当者が確認した行だけが確定になります。同じ製品の過去の報告書の行を上書きしないように、報告書番号ごとに行を分けます。

Fail を開発部門に知らせるのは、担当者が確認した後です。 読み取りの誤りで Fail と出た行をそのまま流すと、開発部門が存在しない不具合を調べ始めます。

人が確認する

担当者が開くのは、fail／conditional／no_verdict の行と、版の違いが出た規格だけです。 pass の行は件数を表紙の試験結果の要約と見比べ、合っていれば流します。

1. 件数を合わせる … 報告書の要約に「Total: 64 items, 62 Pass, 2 Fail」のような数があれば、読み取った行の数と比べます。合わなければ、行の取りこぼしを先に疑います
2. fail と no_verdict を見る … source のページを開き、判定欄と読み取り結果が同じかを確かめます
3. conditional の条件を読む … remarks の原文を読み、条件が製品の仕様や表示に関わるかを判断します
4. 版の違いを判断する … 旧版で試験された項目を、そのまま使えるか、差分試験が要るかを決めます
5. 判定を覆したら記録する … どの行の正規化を、どれに変えたかを残します

1番目を省かないでください。 読み取りの失敗で一番困るのは、誤った値ではなく行が丸ごと抜けることです。抜けた行は印も付かず、誰の目にも入りません。件数の照合は、抜けに気づける唯一の手がかりです。

目標は、60通をならして1通15分です。 印の付く行が1通あたり数行という想定で、版の違いが多い月や、新しい試験機関の報告書が届いた月は15分を超えます。

例外に対処する

上から4行目までは、AI ではなく書類の受け取り方の問題です。 試験機関に「保護なし・印刷用の PDF で送ってほしい」と一度頼んでおくと、大半が解消します。

7行目は、新しい試験機関と取引を始めたときに必ず起きます。 機関の一覧に書式を足すまでは、その機関の報告書は人が写す前提で運用します。

記録を残す

• 元の報告書 PDF と、受け取った日時・送ってきた試験機関
• Textract の JobId と、取り出した結果の全文（S3 に保存）
• 組み直した表と、選んだ表・つないだ表の記録
• 生成AIに渡した入力と、返ってきた JSON
• 正規化の結果と、そのとき使った機関の一覧の版
• 担当者が判定を覆した記録と、確定させた日時・確定させた人

機関の一覧の版を残すのは、正規化の規則が後から変わるためです。 ある機関の「Complies」を条件付きとして扱うように変えたとき、過去のどの報告書を見直せばよいかが、この記録から決まります。