化粧品・日用品のメーカーが海外の香料会社から届く英文の IFRA 適合証明書とアレルゲンの一覧を読み取り、香料ごとの台帳と製品の配合量の上限との照合表を作る

処理の起点を決める

受付フォルダ（Amazon S3 のバケット）に証明書かアレルゲンの一覧のPDFが保存されたことを起点にします。 証明書は、香料の採用、処方の変更、IFRA の基準の改定のたびに届きます。届いたその週のうちに照合表を出せば、処方の見直しと表示の変更を、次の生産の前に決められます。

ファイル名の先頭に、香料会社の略号と香料のコードと書類の種類を付けます。 香料会社が分かれば、項目の対応表を最初から正しく選べます。証明書とアレルゲンの一覧は香料のコードで組にし、 片方だけ届いたときは、そろった方だけを照らします。

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

入力データを集める

質を決めるのは、製品の区分の表の「カテゴリ」と「洗い流すか塗ったままか」の列です。 IFRA のカテゴリは製品の種類で決まり、欧州の香料アレルゲンの表示の基準は、塗ったままの製品で0.001％、洗い流す製品で0.01％を超えるときとされています。同じ香料でも、製品の区分で答えが変わります。

カテゴリの表記は、証明書に書かれた文字列のまま持ちます。 数字だけに丸めると、細かく分かれたカテゴリを取り違えます。 製品の区分の表にも同じ文字列で書いておき、文字列どうしで照らします。

アレルゲンの一覧には、対象とした規則の版を1列持たせます。 欧州の表示の対象に56の成分が加わったため、加わる前の版の一覧では、加わった成分の濃度が分かりません。

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

1ページの証明書は、同期の AnalyzeDocument に S3 の場所を渡し、FeatureTypes に TABLES・FORMS・QUERIES・SIGNATURES を指定して読みます。 同期の処理は PDF 1ページまでなので、2ページ以上のアレルゲンの一覧は非同期の StartDocumentAnalysis で読み、 完了の知らせが Amazon SNS に届き、状態が SUCCEEDED であることを確かめてから GetDocumentAnalysis で結果を取ります。

問い（Queries）は英語の文書でだけ使えます。 証明書は英文なので使えます。問いは対象のページを指定しないと1ページ目にしか当たりません。 証明書の改定の版と発行日は1ページ目の上に書かれるので、1ページ目だけに当てます。

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

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF のいずれかであることを確かめます。XFA 形式の PDF は読めません
2. パスワードの確認 … パスワードで保護された PDF は読めません。電子署名で保護がかかっているときは、解除した版を頼みます
3. ページ数で読み方を分ける … 1ページなら同期、2ページ以上なら非同期で読みます
4. 文字の大きさ … 文字の高さは15ピクセル（150 DPI で8ポイント相当）が下限です。カテゴリの説明を細かい字で詰めた証明書は、下限に近くなります
5. 版の確認 … 同じ香料の証明書が台帳にあれば、発行日と改定の版を比べ、新しいものだけを照合に使い、古いものは履歴に残します
6. 使う製品の確認 … 処方の表で、その香料を使う製品を引きます。使う製品が無い香料は、台帳への転記の案だけを作ります

5番目を省かないでください。 同じ香料の新旧の証明書が混ざると、古い版の上限で照らした結果が、新しい版の上限で照らした結果を上書きすることがあります。

AIに処理させる

させるのは、証明書と一覧から決まった項目の値を読み取り、列の見出し・表の注記・信頼度を添えることだけです。 カテゴリと単位のそろえ、配合量と上限の照合、製品中の濃度の計算は、読み取りの後に Python の規則が行います。

1行目がいちばん起きやすい失敗です。 「Not approved」「Not permitted」の文字が読み取りでかすれたり、欄の外に書かれたりすると、値の欄は空に見えます。 空を「上限なし」と読むと、使えない香料を使える製品の一覧に並べます。

指示内容を固定する

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

【問い（Queries。証明書の1ページ目）】
1. Alias: PRODUCT_NAME  Text: What is the name of the fragrance?
2. Alias: PRODUCT_CODE  Text: What is the fragrance code?
3. Alias: AMENDMENT     Text: Which amendment of the IFRA Standards is this certificate based on?
4. Alias: ISSUE_DATE    Text: What is the date of issue?

【読み取った値の扱いの決まり】
1. 値が空の項目は missing とする。上限なしや 0 として扱わない。
2. 信頼度が決めた値を下回る値は unreadable とし、値は参考として残す。
3. カテゴリの表記は証明書の文字列のまま、その香料会社の対応表で
   自社のカテゴリの文字列に直す。直せない表記は unknown_category とする。
4. 最大の使用濃度の文字の値は、対応表で次のどれかに直す。
   not_limited（上限なし） / not_permitted（使えない）
   直せない文字は needs_review とする。
5. アレルゲンの濃度の単位は、列の見出し、表の注記、対応表の順で決める。
   ppm は 10,000 で割って % にする。決まらなければ照らさない。
6. 改定の版が、自社で決めた現行の版より古ければ outdated_amendment とし、
   照合の結果に印を付ける。
7. 配合量が最大の使用濃度を超えれば over_limit、決めた割合以上なら near_limit、
   not_permitted のカテゴリで使っていれば not_permitted とする。
8. 欧州向けの製品では、香料中の濃度（%）× 配合量（%）÷ 100 で
   製品中の濃度（%）を出し、塗ったままなら 0.001%、洗い流すなら 0.01%
   を超える成分を label_required とする。
9. アレルゲンの一覧の対象の規則の版が、加わった成分を含まない版なら
   allergen_list_outdated とする。

3番目と4番目が、この構成の罠です。 どちらも「たぶんこうだろう」で埋めたくなる箇所で、埋めた瞬間に、誤った上限が製品の照合まで通ります。 決まらない香料会社は、対応表に書き方を足せば次の証明書から決まります。

8番目の計算は、表示の要否の候補を出すだけです。 製品に同じ成分を含む別の原料があれば、合計が変わります。香料以外の原料からの分は、この構成では足しません。

出力形式を固定する

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

{
  "supplier_code": "FR-02",
  "fragrance_code": "",
  "fragrance_name": "",
  "issue_date": "2026-10-06",
  "amendment": "51",
  "amendment_status": "current | outdated_amendment | needs_review",
  "limits": [
    { "category_raw": "", "category": "", "max_raw": "0.85", "max_pct": 0.85,
      "type": "value | not_limited | not_permitted", "confidence": 0 }
  ],
  "allergens": [
    { "name": "", "cas": "", "conc_raw": "1200", "unit_raw": "ppm", "conc_pct": 0.12 }
  ],
  "allergen_list_status": "current | allergen_list_outdated",
  "by_product": [
    { "product_code": "", "category": "", "dosage_pct": 0.5, "eu": true, "rinse_off": false,
      "limit_check": "ok | over_limit | near_limit | not_permitted | needs_review",
      "label_required": [ { "name": "", "conc_in_product_pct": 0.0006 } ] }
  ],
  "verdict": "ok | action | needs_review"
}

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

2つ目は、香料1つから製品の数だけの結果を並べて持てることです。 by_product を見れば、この証明書でどの製品の処方と表示を見直すかを一覧で決められます。

label_required は表示の決定ではありません。 製品中の濃度が基準を超える候補の記録で、表示を決めるのは表示の担当です。

システムへ連携する

香料の台帳には自動で書き込みません。 単位を取り違えた濃度が台帳に入ると、その香料を使う製品すべての表示の判定が狂います。 処方の表と製品の区分の表も読むだけで、変えるのは研究開発部と品質保証部です。

人が確認する

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

1. needs_review を先に見る … 改定の版、カテゴリの表記、文字の値を画像で確かめます。決めた書き方は対応表に足します
2. not_permitted と over_limit を確かめる … 値とカテゴリを画像で確かめ、研究開発部と処方の見直しを決めます
3. label_required を表示の担当に渡す … 香料以外の原料からの分を足して、表示を決めます
4. outdated_amendment と allergen_list_outdated を香料会社に頼む … 新しい版の証明書と一覧を依頼します

2番目は、仕組みでは置き換えられません。 上限を超えた製品をどう直すかは、香りの設計と製品の発売の予定を見て決めることです。

目標は、36件をならして1件10分です。 それを超える月は、項目の対応表のカテゴリと単位の列が足りていません。

例外に対処する

大半は AI の精度ではなく、証明書の書き方の揺れと、対応表と製品の区分の表の整い方の問題です。

記録を残す

• 元の証明書とアレルゲンの一覧、受け取った日時・香料会社・香料のコード
• AWS Textract が返した JSON の全文と、非同期のときの JobId
• 香料×製品ごとの判定と、そのとき参照した処方の表・製品の区分の表・対応表の版
• 人が値や判定を直した記録 … どの欄を、どう読み直したか
• 処方と表示の見直しの決定、香料会社への依頼と返事
• 香料ごとの証明書の版の履歴

3つ目で「そのときの処方の表」を残すのは、処方が後から変わるためです。 配合量を変えた後でも、どの配合量で照らして「上限の内」としたかを示せます。