海外の検品会社から届く英文の出荷前検査報告書を読み取り、AQLの判定と不良の内訳を検品台帳に転記して、出荷可否の判断が要るものを品質管理へ回す

処理の起点を決める

起点は2つあります。報告書が届いたときと、毎朝の定時です。

1つ目は、受付フォルダ（Amazon S3）に報告書のPDFが保存されたことです。共有受信箱のルールで、検品会社3社の送り元から届いたメールの添付をS3へ転送します。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。届いた時点で読むので、出荷予定日までの残りの日数を最大限に使えます。

2つ目は、毎朝9時の定時です。判断待ちの一覧のうち、出荷予定日まで3日を切ったもの、判断が付いていないもの、再検査の報告書が届いていないものを並べ、品質管理の判断者と購買の担当者に送ります。保留の報告書が放置されないように、期日の管理を一覧の側に置きます。

再検査の報告書も同じ経路で入れます。 発注番号が同じものは、台帳の同じ行の履歴に足します。

入力データを集める

質を決めるのは、発注データの取り決めたAQLの列です。 これが無いと、報告書のAQLが正しいかを照らす先がありません。今は取り決めが品質協定の文書の中にしか無く、発注ごとに引ける形になっていません。

発注番号の書き方の一覧は、台帳の行を探すために持ちます。 PO-26-0412、260412、PO#0412-A のように、同じ発注でも検品会社によって書き方が違います。ここで行が見つからないと、それ以降の照合がすべて止まります。

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

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

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

手書きの行を分けて記録するのは、そこに判断の材料があることが多いためです。 印字の判定のあとに、検品員が「工場が手直しを約束」のような書き込みをしていることがあります。

不良の表は、列の見出しで意味を決めます。 Found、Allowed、Ac、Re の見出しが検品会社ごとに違う言い方で並ぶので、列の見出しの言い方の一覧を検品会社ごとに持ち、セルの ColumnIndex と結び付けます。 見出しが一覧に無い表は、列の意味を決めずに ambiguous として人に回します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは検品会社に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです。写真の多い報告書は大きくなるので、サイズを先に確かめます
4. 報告書の種類の確認 … 1ページ目の題名から、出荷前検査か、生産中の検査か、再検査かを決めます。出荷前検査と再検査以外は、この流れに乗せず担当者の一覧に入れます
5. 発注番号の正規化 … 書き方の一覧で、報告書の発注番号を自社の書き方に直します

AIに処理させる

させるのは、報告書の項目を原文のまま写し、不良の内訳を種類ごとに並べ直すことです。 照合と、出荷できるかの判断はさせません。

判定を文字と印の両方で記録するのは、書式によって片方しか正しくないことがあるためです。 チェック欄の横に PASS と印字されていても、印は FAIL の欄に付いている、という報告書があります。

3行目を明記するのは、計算させると引き直すためです。 抜取数とAQLを見て、許容数を一般的な抜取表から求めようとし、報告書に書かれた値と違う数を返します。 正しいかどうかではなく、報告書に何が書かれていたかを残すのが目的です。

指示内容を固定する

あなたは生活雑貨の商社の品質管理部で、海外の検品会社から届いた
英文の出荷前検査報告書の記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
po_number_raw、item_number_raw、lot_quantity_raw、
verdict_text_raw、verdict_checkbox（どの欄に印があるか）、
aql_raw（critical／major／minor）、inspection_level_raw、sample_size_raw、
defects_found（critical／major／minor）、accept_raw（Ac）、reject_raw（Re）、
defect_lines（名称、区分、数）、photo_captions、handwritten_notes、
各項目の status とページ

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

【厳守事項】
- 判定は、印字された文字と、チェック欄の印の両方を別々に記録して
  ください。どちらかに合わせて書き換えないでください。
- 許容数（Ac）と不合格の数（Re）は、報告書に書かれた数だけを
  入れてください。抜取数や AQL から計算しないでください。
- 不良の区分（critical／major／minor）は、報告書に書かれたとおりに
  してください。重さを判断して付け直さないでください。
- 写真の説明文は書かれた文をそのまま短く写してください。
  写真に何が写っているかを推測して書き足さないでください。
- 手書きの書き込みは handwritten_notes に分けて入れてください。
- 出荷してよいか、再検査が要るかを書かないでください。
- 出荷前検査の報告書でない書類と判断した場合は、項目を取り出さず
  document_type に種類を書いてください。

【読み取り結果】{textract_layout_tables_forms}
【検品会社の区分】{inspector_company}

「どちらかに合わせて書き換えない」を明記しないと、合わせます。 文字と印が食い違うと、もっともらしいほうに寄せて1つの判定を返し、食い違いがあったという事実が消えます。

出力形式を固定する

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

{
  "file": "",
  "document_type": "pre_shipment_inspection",
  "po_number_raw": "PO#0412-A",
  "item_number_raw": "HW-2207",
  "lot_quantity_raw": "3,600 pcs",
  "verdict_text_raw": "PASS",
  "verdict_checkbox": "FAIL",
  "aql_raw": { "critical": "0", "major": "2.5", "minor": "4.0" },
  "sample_size_raw": "200",
  "defects_found": { "critical": 0, "major": 11, "minor": 6 },
  "accept_raw": { "critical": "0", "major": "10", "minor": "14" },
  "defect_lines": [
    { "name_raw": "Loose stitching", "class_raw": "major", "count": 7 }
  ],
  "photo_captions": ["Loose stitching at handle seam"],
  "handwritten_notes": [],
  "items": [
    { "item": "verdict", "status": "ambiguous", "confidence": 0, "page": 1 }
  ]
}

1つ目の理由は、照合と回付をプログラムの側に置けることです。 Python が発注データを引き、数字を比べて印を付けます。

inconsistent を needs_decision と分けるのは、確かめる相手が違うためです。 前者は検品会社に報告書の訂正を頼むもので、後者は自社が出荷を決めるものです。

2つ目は、不良の内訳を台帳で集計できることです。 defect_lines を工場と品番ごとに積み上げると、同じ工場で同じ不良が続いていることが見えます。

システムへ連携する

工場への連絡と出荷の許可は、この構成からは行いません。 判断待ちの一覧を見た品質管理の担当者が決め、購買が工場に伝えます。出荷を止めるか通すかの連絡を自動にすると、印の付け間違い1つで船積みが止まります。

人が確認する

品質管理の担当者が開くのは、判断待ちの一覧に入ったものです。 ok の報告書は台帳で件数と工場を流し見ます。

1. inconsistent を先に見る … 報告書の該当ページを開き、判定と数字のどちらが正しいかを確かめます。検品会社に訂正を頼む前に、読み取りの誤りでないことを確かめます
2. aql_mismatch を確かめる … 取り決めと違う基準で検査されたなら、検品会社に再検査か説明を求めます
3. needs_decision の写真と指摘を見る … 写真を開き、手直しで足りるか、再検査が要るか、条件付きで出荷するかを決めます
4. 判断を台帳に記録する … 決めた内容、決めた人、理由を残し、購買に回します

1番目を急がないでください。 inconsistent の多くは報告書の記入の誤りですが、判定の欄のほうが正しく、表の数字が誤っていることもあります。 どちらが正しいかは検品会社に確かめるまで分かりません。

例外に対処する

上から3行目が、運用の初めに最も多く出ます。 検品会社の書き方を一覧に足していくと減り、1か月ほどでほとんど出なくなる想定です。

記録を残す

• 元の報告書と、受け取った日時、検品会社、メールの件名
• AWS Textract が返したJSONの全文
• Claude API が返したJSON
• 照合の結果と、そのとき参照した発注データの取り決めたAQLと数量
• 品質管理の判断の記録 … 出荷・手直し・再検査・条件付き出荷のどれか、決めた人、理由
• 検品会社に訂正を頼んだ記録と、訂正された報告書との対応

判断の記録は、工場ごとの品質の傾向を見る材料になります。 再検査や手直しの多い工場と不良の種類を並べると、次の発注で検査の水準を上げるべき工場が見えてきます。