日本茶の輸出業者が海外の検査機関から届く英文の残留農薬の分析報告を読み取り、ロットごとの検査の台帳と輸出先の基準値との照合表を作る

処理の起点を決める

受付フォルダ（Amazon S3 のバケット）に分析報告のPDFが保存されたことを起点にします。 報告は、検査機関に試料を送ってから数日から2週間ほどで届きます。出荷の予定の前に判定を出せば、振り分けの変更と追加の分析の依頼が、船の予約に間に合います。

ファイル名の先頭に、検査機関の略号とロット番号を付けます。 検査機関が分かれば、項目の対応表を最初から正しく選べます。同じロットの再分析の報告は、版の番号を付けて区別します。

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

入力データを集める

質を決めるのは、基準値の表の「基準値の無い成分の扱い」の列です。 EU では、基準値の表に載っていない農薬と作物の組み合わせには、原則として一律の0.01 mg/kg が当てられるとされています。表に無い成分を「基準なし＝出せる」と読むと、いちばん厳しい値を見落とします。

基準値の表には、確かめた日を1列持たせます。 農林水産省の表は調査時点の値で、その後変わっていることがあると断られています。確かめた日が古い輸出先は、判定に印を付けます。

付表の定量下限は、検出されなかった成分の判定に欠かせません。 検出された成分の表だけを読むと、「検出されず」の確からしさが分かりません。

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

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

単位は、表の題や表の下の注記に書かれていることがあります。 「All results in mg/kg」のような注記は、表のセルではなく TABLE_TITLE や TABLE_FOOTER として返るため、表のセルだけを読むと単位が見つかりません。 対応表で、単位がどこに書かれるかを検査機関ごとに決めておきます。

ページをまたぐ表は、列の見出しで並べ直します。 付表は数ページにわたり、ページごとに見出しの行が繰り返されます。見出しの行を成分の行として数えないように、 見出しの印と対応表の文字で外します。

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

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF のいずれかであることを確かめます。XFA 形式の PDF は読めません
2. パスワードの確認 … パスワードで保護された PDF は読めません。電子署名つきの報告で保護がかかっているときは、解除した版を頼みます
3. 文字の大きさ … 文字の高さは15ピクセル（150 DPI で8ポイント相当）が下限です。数百成分を詰めた付表は、文字が小さくなりがちです
4. 版の確認 … 同じロットの報告が2通あれば、新しい版の番号のものを使い、古い版との差を一覧に残します
5. 出荷の予定の確認 … ロット番号で出荷の予定の表を引き、照らす輸出先を決めます。予定が無いロットは、すべての輸出先で照らします
6. 基準値の表の日付の確認 … 照らす輸出先の基準値の表を確かめた日を見て、決めた日数より古ければ stale_mrl の印を付けます

6番目を省かないでください。 基準値は変わり、変わる前の表で「出せる」と判定したロットが、着いた先で基準を超えることがあります。

AIに処理させる

させるのは、報告から決まった項目の値を読み取り、列の見出し・表の注記・信頼度を添えることだけです。 単位のそろえ、成分の名前の対応、基準値との照合、定量下限の確かめは、読み取りの後に Python の規則が行います。

4行目は、とくに気をつけます。 ジェトロの資料では、EU の当局は違反として処分する前に測定の不確かさを考え、通常は測定値の±50％を当てるのが慣行と紹介されています。それは当局の扱いで、出す側の基準ではありません。 この構成は値をそのまま基準値と比べます。

指示内容を固定する

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

【読み取った値の扱いの決まり】
1. 値が空の項目は missing とする。0 や前の行の値で埋めない。
2. 信頼度が決めた値を下回る値は unreadable とし、値は参考として残す。
3. 列の見出しは、その検査機関の項目の対応表だけで共通の項目
   （analyte, result, unit, loq, method）に直す。
4. 単位は、列の見出し、表の題、表の注記、対応表の順で探す。
   どれでも決まらなければ照らさず needs_review とする。
5. µg/kg は 1,000 で割って mg/kg にする。ppm は mg/kg、ppb は µg/kg とみなす。
   それ以外の単位は unit_unknown とする。
6. 「n.d.」「not detected」「<LOQ」「< 0.01」は not_detected とし、
   定量下限を付表から引いて残す。0 にしない。
7. 成分の名前は、成分の名前の対応表だけで基準値の表の名前に直す。
   表に無い名前は unknown_analyte とし、似た名前に寄せない。
8. 検出された成分は、輸出先ごとに基準値と比べる。
   値が基準値を超えれば exceeds、基準値の決めた割合以上なら near_limit。
9. 基準値の表に載っていない成分は、その輸出先の
   「基準値の無い成分の扱い」の値で比べる。扱いが空なら needs_review。
10. not_detected の成分で、定量下限が輸出先の基準値より高ければ
    cannot_confirm とする。
11. 測定の不確かさを差し引いて判定しない。

4番目と6番目が、この構成の罠です。 どちらも「たぶんこうだろう」で埋めたくなる箇所で、埋めた瞬間に、誤った値が輸出の判断まで通ります。 決まらない検査機関は、対応表に書き方を足せば次の報告から決まります。

9番目の「基準値の無い成分の扱い」を輸出先ごとに持つのは、 国・地域によって扱いが違うためです。一律の値を当てる輸出先と、別の考え方をとる輸出先があり、 自社の表に書いておかないと、規則が判定できません。

出力形式を固定する

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

{
  "lab_code": "LAB-DE-01",
  "report_no": "",
  "report_version": 1,
  "lot_no": "",
  "product": "matcha",
  "analysis_date": "2026-10-14",
  "results": [
    { "analyte_raw": "", "analyte": "", "result_raw": "0.02", "unit_raw": "mg/kg",
      "result_mgkg": 0.02, "detected": true, "loq_mgkg": 0.01,
      "confidence": 0, "page": 1 }
  ],
  "by_destination": [
    { "destination": "EU", "mrl_checked_on": "2026-10-01",
      "findings": [ { "analyte": "", "mrl_mgkg": 0.05, "status": "ok | near_limit | exceeds | cannot_confirm" } ],
      "result": "ok | near_limit | exceeds | cannot_confirm | needs_review" }
  ],
  "flags": ["stale_mrl", "unknown_analyte", "unit_unknown"]
}

1つ目の理由は、元の文字と直した値を並べて残せることです。 result_raw と unit_raw と result_mgkg が並んでいれば、どの単位をどう直したかを、画像を開く前に読めます。

2つ目は、輸出先ごとの判定を並べて持てることです。 by_destination を見れば、このロットをどの輸出先に回せて、どこに回せないかを一覧で決められます。

near_limit を置いているのは、基準値すれすれのロットを出さないためです。 茶葉の分析の値は、同じロットでも試料の取り方で動きます。割合は品質管理部が決め、 最初は基準値の半分などの保守的な値から始めます。

システムへ連携する

検査の台帳には自動で書き込みません。 単位を取り違えた値が台帳に入ると、茶園ごと・季節ごとの傾向を誤って読み、 次の年の農薬の使い方の相談まで狂います。基準値の表も読むだけで、変えるのは品質管理部です。

人が確認する

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

1. needs_review を先に見る … 単位、成分の名前、基準値の表の日付を確かめます。決めた書き方は対応表に足します
2. exceeds を確かめる … 値と単位を画像で確かめ、輸出先の関係法規で基準値を確かめ直します
3. cannot_confirm を検査機関に相談する … 定量下限の低い分析を頼むか、その輸出先に回さないかを決めます
4. near_limit を営業部と見る … 別の輸出先に回すか、再分析をするかを決めます

2番目は、仕組みでは置き換えられません。 基準値の表は自社で整えた写しで、輸出の判断の前に、輸出先の原典で確かめることが欠かせません。

目標は、45件をならして1件8分です。 それを超える月は、成分の名前の対応表か、基準値の表の日付が追いついていません。

例外に対処する

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

記録を残す

• 元の分析報告と、受け取った日時・検査機関・ロット・版
• AWS Textract が返した JSON の全文と JobId
• ロット×輸出先ごとの判定と、そのとき参照した基準値の表と対応表の版
• 人が値や判定を直した記録 … どの成分の、どの値を、どう読み直したか
• 振り分けの変更と、追加の分析の依頼と結果
• 検査機関ごとの needs_review の件数と、成分ごとの検出の推移

3つ目で「そのときの基準値の表」を残すのは、基準値が後から変わるためです。 出荷した後に基準値が改められても、出荷の時点で何に照らして出したかを示せます。