海外の委託先工場の英文の監査報告書を読み取り、指摘事項・重要度・是正期限を是正管理台帳に転記して、前回からの再発と期限切れ間近を拾う

処理の起点を決める

起点は、受付フォルダ（Amazon S3）に報告書のPDFが保存されたことです。 監査会社からメールで届くものは共有受信箱のルールで、スキームのプラットフォームから担当者がダウンロードしたものは共有フォルダの同期で、それぞれS3へ入れます。保存の通知で AWS Lambda が動きます。

是正の報告や再監査の報告書も、同じ経路で入れます。 ファイル名と表紙の見出しで「初回の監査」「フォローアップ」を見分け、フォローアップなら新しい指摘ではなく、前回の指摘の是正の状況として台帳に書きます。

報告書と是正計画が別のファイルで届くこともあります。 是正計画のファイルは工場が書き込んだ是正の内容と予定日を含むので、同じ工場・同じ監査日の報告書に結びつけ、指摘の番号で是正の予定日を台帳に足します。 結びつく報告書がまだ無ければ、報告書が届くまで「待ち」にします。

毎週月曜の朝8時にも動かします。 台帳の全指摘について、是正期限まで14日を切ったものと過ぎたものを一覧にして担当者に送ります。月末にまとめて見ていた期限の確認を、週に1回に変えるのがこの起点の役目です。

入力データを集める

質を決めるのは、2つの表です。 対応表に無い表記の重要度は読み替えずに人に回し、分類の一覧が粗すぎると再発の候補が多すぎ、細かすぎると漏れます。 30前後の分類から始めます。

工場の一覧に別名を持たせるのは、報告書の工場名が登記の名称で書かれるからです。 自社が呼んでいる通称や、工場のある工業団地の名前とは違うことが多く、名称だけで引くと、前回の指摘が見つからず、再発の候補が1件も出ません。 工場コードは JobTag で受け渡し、表紙から読んだ名称は照合の確認にだけ使います。

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

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

表は TABLES で、行と列の位置と、列の見出し（COLUMN_HEADER）、表の題（TABLE_TITLE）、表の中の節の題（TABLE_SECTION_TITLE）が返ります。 複数の行や列にまたがるセルは MERGED_CELL として返るので、指摘の番号が結合セルになっている表でも、行の対応を崩さずに読めます。

ページをまたぐ表は、Python がつなぎます。 次のページの表の列の見出しが前のページと同じなら、同じ表の続きとして行を足します。結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。80ページの報告書では呼び直しが何十回にもなります。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは監査会社に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです。写真の多い報告書はサイズに注意します
4. 章の切り出し … LAYOUT_SECTION_HEADER の見出しの語（Non-Compliance、Findings、Corrective Action）で、指摘事項の章のページの範囲を決めます
5. 渡さないページの除外 … Worker Interview、Employee List、写真だけのページ（LAYOUT_FIGURE のみ）を外します
6. 言語の確認 … 6言語に入らない部分は読み取り結果から外し、英語の部分だけを渡します

5番目は、精度ではなく情報の扱いのための処理です。 社会監査の報告書には従業員への聞き取りの内容が載ることがあり、台帳の作成に要らない情報を生成AIに渡さないために外します。

AIに処理させる

させるのは、指摘ごとに原文を取り出し、自社の分類の一覧から1つを選ぶことです。 重要度の読み替えと期限の換算はさせません。

指摘の内容を「表の記載」と「本文の所見」に分けるのが、いちばん大事な区別です。 一覧の表は1行に短く書かれ、何が起きていたかは本文にしかないことが多いからです。台帳には表の記載を、確認の画面には本文の所見を出します。

4行目も見落とされがちです。 指摘を短く言い換えると読みやすくなりますが、工場に是正を求めるときに「報告書のどこにそう書いてあるか」を示せなくなります。

指示内容を固定する

あなたはメーカーの購買部で、委託先工場の英文の監査報告書から
指摘事項を記録する担当です。OCRの読み取り結果だけを使ってください。
推測で埋めないでください。

【取り出す項目（指摘ごと）】
finding_no、clause_raw、table_text、narrative_text、
severity_raw、due_raw、pages（配列）、category_code、
prior_status_raw（フォローアップの報告書のときだけ）

【category_code の選び方】
{category_list} の中から1つを選んでください。
当てはまるものが無ければ other にしてください。

【厳守事項】
- table_text と narrative_text には、報告書の文をそのまま写してください。
  要約したり言い換えたりしないでください。
- severity_raw には報告書に書かれた重要度の表記をそのまま入れてください。
  書かれていなければ空にしてください。重要度を自分で判断しないでください。
- due_raw には是正期限の表記をそのまま入れてください
  （例：「30 days」「2026-11-15」）。日付に換算しないでください。
- 一覧の表に無く、本文の所見にだけ書かれた指摘も取り出し、
  table_text を空にしてください。
- 良好な取り組み（good practice）として書かれたものは、
  指摘として取り出さないでください。
- 再発かどうか、是正が十分か、取引を続けるべきかを書かないでください。
- 個人の名前が出てきても写さず、「[氏名]」に置き換えてください。

【報告書の種類】{audit_type}
【読み取り結果（指摘事項の章）】{textract_layout_tables}

「良好な取り組みを指摘として取り出さない」を明記しないと、混ざります。 報告書には指摘と並んで良い取り組みが同じ形式で書かれることがあり、台帳に是正の要らない行が入ります。

出力形式を固定する

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

{
  "file": "",
  "site_name_raw": "",
  "audit_date_raw": "",
  "audit_type": "full | follow_up",
  "findings": [
    {
      "finding_no": "NC-03",
      "clause_raw": "",
      "table_text": "",
      "narrative_text": "",
      "severity_raw": "Major",
      "due_raw": "30 days",
      "pages": [41, 12],
      "category_code": "FIRE_EXIT",
      "status": "ok"
    }
  ]
}

1つ目の理由は、読み替えと照合をプログラムの側に置けることです。 Python が対応表で重要度を当て、監査日と due_raw から期限を計算し、前回の指摘と照らします。

2つ目は、再発の候補を広めに出せることです。 分類コードか条項のどちらかが一致すれば候補にし、確認の画面で前回と今回の本文の所見を並べて見せます。 再発かどうかの判断は担当者が行い、結果を台帳に残します。

3つ目は、根拠の頁を残せることです。 pages に表と本文のページ番号があれば、工場に是正を求めるときも、取引先に説明するときも、報告書のどこに書かれているかをすぐ示せます。 確認の画面では、この頁の画像を指摘の横に出します。

システムへ連携する

工場への催促と取引先への報告は、この構成からは送りません。 送るのは担当者で、催促の文面に添える根拠として、指摘の番号と報告書の頁を一覧から引けるようにします。

人が確認する

担当者は、すべての報告書の指摘の一覧を確かめてから台帳に確定させます。

1. 指摘の数を報告書と合わせる … 一覧の表の行数と、取り出された指摘の数が合うかを見ます。合わなければ、ページをまたぐ表のつなぎを疑います
2. needs_human を片付ける … 対応表に無い重要度の表記は、対応表に足してから当てます
3. possible_recurrence を判断する … 前回と今回の所見を読み、再発か別の問題かを決めて台帳に残します
4. 重い指摘と再発を報告する … 課長と取引先の窓口に、指摘の番号と頁を添えて伝えます

1番目を省かないでください。 取り出された指摘を1件ずつ読むより先に、数が合うかを見るほうが速く、漏れを確実に拾えます。 数が合えば、中身の確認は本文の所見と見比べて流し読みで済みます。

3番目の判断は、迷ったら「再発」に寄せます。 別の問題と判断して外した指摘が実は同じ問題だった場合、次の監査でまた新しい指摘として扱われ、工場に同じ説明を繰り返すことになります。

例外に対処する

上から2行目と3行目が、指摘の取りこぼしのほとんどを生みます。 表の読み取りが崩れると、指摘が丸ごと台帳から消えるため、指摘の数を報告書と合わせる確認を省かないでください。

記録を残す

• 元の報告書と、受け取った日時、経路、工場コード
• AWS Textract が返したJSONの全文と、切り出した章のページの範囲
• Claude API が返したJSONと、担当者が確定させた指摘の一覧
• 重要度の読み替えと期限の計算の結果と、そのとき参照した対応表の版
• 再発の候補と、担当者の判断（再発か別の問題か）
• 催促と報告の日時と相手

5つ目の判断の記録は、分類の一覧を直す材料になります。 候補にしたが別の問題だった組み合わせが多い分類は、分け方が粗すぎることが分かります。