水産加工会社が海外の加工委託先から毎月届く英文の加工報告とパッキングリストを読み取り、ロットごとの歩留まりの台帳と契約の歩留まりとの差の一覧を作る

処理の起点を決める

受付フォルダ（Amazon S3 のバケット）に加工報告かパッキングリストのPDFが保存されたことを起点にします。 書類は加工が終わって船積みするときに、ロットごとに届きます。製品が日本に着く前に差を出しておけば、着いた製品の重量を量り直すロットを先に決められます。

ファイル名の先頭に、委託先の略号とロット番号と書類の種類を付けます。 委託先が分かれば、項目の対応表を最初から正しく選べます。加工報告とパッキングリストはロットで組にし、 両方がそろってから照合を始めます。

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

入力データを集める

質を決めるのは、項目の対応表の「グレーズの扱い」の列です。 パッキングリストの見出しに「Net Weight (excl. glaze)」のように書かれていればそれに従い、書かれていなければ対応表に従い、どちらでも決まらなければ決めません。

原料の重量の定義も、対応表に1列持たせます。 加工場が受け入れた重量を解凍の前に量るか後に量るかで、同じ原料でも重量が変わります。 契約の歩留まりをどちらで取り決めたかを、契約の表と合わせておきます。

副産物の重量は、照合の補助に使います。 製品と副産物の重量の合計が原料の重量から大きく離れていれば、どこかの欄の読み違いか、報告の書き違いの疑いがあります。

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

報告は1ページから数ページなので、ページ数によらず非同期の StartDocumentAnalysis に S3 の場所を渡し、FeatureTypes に TABLES・FORMS・QUERIES・SIGNATURES を指定して読みます。 返った JobId を控え、完了の知らせが Amazon SNS に届き、状態が SUCCEEDED であることを確かめてから GetDocumentAnalysis で結果を取ります。

問い（Queries）は英語の文書でだけ使えます。 委託先の報告は英文なので使えます。問いは対象のページを指定しないと1ページ目にしか当たらず、 原料の重量が2ページ目の集計に書かれる委託先もあるため、その委託先だけ Pages に * を指定します。どの委託先がそうかは、対応表に持たせます。

同じ ClientRequestToken で読み取りを始めれば、同じ JobId が返ります。 ファイル名から作った値を渡しておけば、再試行で同じファイルを二度読まずに済みます。JobId は7日間だけ有効なので、 結果は取った時点で S3 に残します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF のいずれかであることを確かめます。加工場で撮った報告の写真も、そのまま読めます
2. パスワードの確認 … パスワードで保護された PDF は読めません。解除した版を委託先に頼みます
3. 画像と文字の大きさ … 各辺10,000ピクセル以下、文字の高さは15ピクセル（150 DPI で8ポイント相当）が下限です。冷凍庫の前で撮った写真は、霜や手ぶれで文字がつぶれがちです
4. 組の確認 … 同じロットの加工報告とパッキングリストがそろっているかを見ます。片方だけなら照合を待ちます
5. 重複の確認 … 委託先とロット番号が同じものは重複として外します。訂正の版が届いたときは、両方を残して人が選びます
6. 単位の確認 … 対応表の単位と、表の見出しの「kg」「lbs」を照らします。両方が食い違えば、そのロットを unit_conflict として人に回します

6番目を省かないでください。 1ポンドはおよそ0.45キログラムで、単位を取り違えた歩留まりは、半分以下か倍以上になります。 大きすぎる差は目立ちますが、合計だけが lb で書かれた書類のように一部の欄だけが違うと、差が小さく出て見逃します。

AIに処理させる

させるのは、報告とパッキングリストから決まった項目の値を取り出し、欄の名前・単位・信頼度・印字か手書きかを添えることだけです。 単位とグレーズのそろえ、箱の照合、歩留まりの計算と契約の照合は、取り出した後に Python の規則が行います。

3行目がいちばん起きやすい失敗です。 報告に原料の重量が無いとき、手元の出荷した重量で割りたくなります。そうすると、加工場が受け入れた時点の差が消え、 輸送中に減ったのか、加工で減ったのかが分からなくなります。

指示内容を固定する

文書の解析そのものには指示を書く場所がありません。AWS Textract に渡すのは文書と問い（Queries）で、判定の指示にあたるものは読み取った後の規則として持ちます。 問いは次の4つです。

【問い（Queries。英文の報告）】
1. Alias: LOT_NO        Text: What is the lot number?
2. Alias: RAW_WEIGHT    Text: What is the total raw material weight received?
3. Alias: PROCESS_DATE  Text: What is the processing date?
4. Alias: GLAZE         Text: What is the glaze percentage?

【読み取った値の扱いの決まり】
1. 値が空の項目は missing とする。0 や支給の記録の値で埋めない。
2. 信頼度が決めた値を下回る値は unreadable とし、値は参考として残す。
3. 欄の名前は、その委託先の対応表だけで共通の項目
   （raw_weight, product_weight, byproduct_weight, cartons,
     weight_per_carton, glaze_pct）に直す。表に無い名前は unknown_item とする。
4. 単位は表の見出しの印、無ければ対応表で決める。
   両方あって食い違えば unit_conflict とし、計算に使わない。
5. パッキングリストの重量がグレーズ込みか正味かは、見出しの語、
   無ければ対応表で決める。どちらでも決まらなければ needs_review とし、
   歩留まりを出さない。
6. グレーズ込みの重量は、契約の表のグレーズの率で正味に直す。
   報告のグレーズの率が契約と違えば glaze_diff とする。
7. 箱の数 × 1箱の正味重量 と、報告の製品の正味重量の差が
   決めた幅を超えたら carton_mismatch とする。どちらの値も直さない。
8. 歩留まりは、規格ごとの製品の正味重量 ÷ 受け入れた原料の重量
   × 100 とし、小数1桁で残す。
9. 受け入れた原料の重量と、支給の記録の出荷した重量の差が
   決めた幅を超えたら weight_gap とする。
10. 英語でない手書きの書き込みは照合に使わず、欄の文字を一覧に写す。

4番目と5番目が、この構成の罠です。 どちらも「たぶんこうだろう」で埋めたくなる箇所で、埋めた瞬間に、誤った歩留まりが精算まで通ります。 決まらない委託先は、対応表に書き方を足せば次のロットから決まります。

6番目で、報告のグレーズの率をそのまま使わないのも理由があります。 グレーズの率は契約で決めた値で、報告の値が違えば、それ自体が問い合わせの候補です。

出力形式を固定する

次の形の JSON で一覧に書き出します。

{
  "processor_code": "PR-VN-01",
  "lot_no": "",
  "process_date": "2026-09-18",
  "raw_weight_kg": 0,
  "raw_weight_basis": "before_thaw | after_thaw",
  "products": [
    { "spec": "fillet_skinless_boneless", "weight_raw": "", "unit": "kg | lb",
      "glaze_basis": "net | with_glaze", "net_kg": 0, "yield_pct": 0,
      "contract_yield_pct": 0, "diff_pt": 0,
      "status": "ok | below_contract | missing | unreadable | needs_review",
      "text_type": "PRINTED", "confidence": 0 }
  ],
  "checks": {
    "carton": "ok | carton_mismatch | not_checked",
    "glaze": "ok | glaze_diff | not_checked",
    "supply_weight": "ok | weight_gap | not_checked",
    "unit": "ok | unit_conflict"
  },
  "signature_found": true,
  "verdict": "ok | query_processor | needs_review"
}

1つ目の理由は、元の文字と直した重量を並べて残せることです。 weight_raw と unit と glaze_basis と net_kg が並んでいれば、どの基準でどう直したかを、画像を開く前に読めます。

2つ目は、差を「どこで減ったか」に分けて持てることです。 supply_weight は輸送と受け入れの差、yield_pct は加工の差です。精算の問い合わせでは、どちらの差かで相手に聞くことが変わります。

below_contract は請求の決定ではありません。 契約の許す幅を外れたことの記録で、問い合わせるかどうかは人が決めます。

システムへ連携する

歩留まりの台帳には自動で書き込みません。 グレーズの扱いを取り違えた値が台帳に入ると、委託先ごとの歩留まりの傾向を誤って読み、 次の契約の歩留まりの取り決めまで狂います。経理の精算の仕組みにもつなぎません。

人が確認する

人が開くのは ok 以外のロットだけです。 ok のロットは一覧で流し見て台帳に取り込みます。全件を開く設計にすると、第10章の4.0時間には収まりません。

1. needs_review を先に見る … 単位、グレーズの扱い、手書きの重量を、画像で確かめます。決めた書き方は対応表に足します
2. weight_gap を確かめる … 出荷した重量と受け入れた重量の差を、解凍の前後の定義と輸送の記録で確かめます
3. below_contract を経理と見る … 契約の許す幅と、同じ委託先の前後のロットの歩留まりを見て、問い合わせるかを決めます
4. 製品が着いたら量り直すロットを決める … glaze_diff と carton_mismatch のロットは、着いた箱の正味重量を量り直す候補にします

3番目は、仕組みでは置き換えられません。 原料の魚の大きさや季節で歩留まりは動き、委託先との長い取引の中で、どこまでを精算の対象にするかを決めることです。

目標は、40件をならして1件6分です。 それを超える月は、項目の対応表の単位とグレーズの列が足りていません。

例外に対処する

大半は AI の精度ではなく、書類の書き方の揺れと、対応表の整い方の問題です。

記録を残す

• 元の加工報告とパッキングリスト、受け取った日時・委託先・ロット
• AWS Textract が返した JSON の全文と JobId
• ロットごとの判定と、そのとき参照した対応表・契約の表の版
• 人が値や判定を直した記録 … どの欄を、どう読み直したか
• 委託先への問い合わせの内容と返事、精算の結果
• 製品が着いた後に量り直した正味重量（品質管理の担当者が後から足す）
• 委託先ごと・規格ごとの歩留まりの推移

6つ目を足していくと、委託先の報告と自社で量り直した重量の差が見えてきます。 差の大きい委託先のロットは、量り直す候補を広げる材料になります。