海外の仕入先から届く英文のISO認証書（品質・環境）を読み取り、認証範囲・登録番号・有効期限を仕入先台帳に転記して、期限切れ間近と範囲外の品目を拾う

処理の起点を決める

仕入先ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは iso/<仕入先コード>/<規格>/ の形にし、どの仕入先の認証書かを、保存した場所で決めます。 認証書の組織名から仕入先を探すと、グループ会社や旧社名で取り違えます。

読み取りを始めるとき、ClientRequestToken に「仕入先コード＋規格＋受領日」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。同じ認証書を2人が保存しても、読み取りは1回で済みます。

完了は Amazon SNS の通知で受け、JobTag に入れた仕入先コードでどの仕入先かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

期限の確認は、届いた認証書とは別に、毎週月曜に台帳の全件で行います。 届いたときだけ期限を見ると、届かない仕入先の期限切れに気づけません。 毎週、有効期限まで90日を切った仕入先を拾い、依頼の下書きを作ります。

入力データを集める

質を決めるのは、購入品目の一覧の「品目の区分」と「出荷元の事業所」です。 品目の区分が「部品」のように粗いと、範囲の文と見比べても疑いを拾えません。範囲の文に出てくる程度の粒度（成形・切削・板金・組立・設計の有無など）で区分を持たせます。

出荷元の事業所は、発注の記録の出荷元の住所から取ります。 仕入先台帳の住所は本社のことが多く、実際に品物を作って出荷している工場が認証の対象に入っているかは、出荷元で見ないと分かりません。

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

項目は、問い合わせで取ります。 公式のページでは、問い合わせの答えは QUERY_RESULT として信頼度付きで返り、答えが見つからなければ空のまま返るとされています。非同期では1ページあたり30件までです。

範囲の文は、問い合わせの答えだけに頼りません。 範囲の文は数行に及ぶことがあり、答えが途中で切れることがあります。答えの位置のページの LINE のブロックから、範囲の見出しの後の行をつなげて全文を取り、答えと照らします。 結果は NextToken が返る限り呼び続け、全ページ分をそろえてから組み立てます。

キーと値の組は、問い合わせの答えが空のときの予備に使います。 GetDocumentAnalysis は、「Certificate No.: 12345」のような組を KEY と VALUE の2つのブロックで返すとされています。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 仕入先に送り直してもらいます
3. 日付の読み方 … 認証機関ごとの設定で日付の順を決め、月の名前で書かれたものはそのまま読みます。設定の無い認証機関で数字だけの日付が来たら、日が12以下のものは人に回します
4. 3つの日付の取り違えの確かめ … 初回の発行日 ≦ 今回の発行日 ＜ 有効期限 の順になっているかを確かめます
5. 登録番号の整え … 前後の空白と記号をそろえ、認証機関ごとの番号の形に合うかを確かめます
6. 組織名の照らし … 「Co., Ltd.」「GmbH」「Inc.」などの会社の種類の表記を外して、台帳の正式名・旧社名と照らします

3番目と4番目を軽く見ないでください。 期限の日付を1か月取り違えると、依頼が1か月遅れます。日が12以下の数字だけの日付は、どちらの順でも日付として成り立つので、機械では決められません。

AIに処理させる

させるのは、言葉を扱う2つの仕事だけです。 項目の読み取りは Textract、日付と照合はプログラムが行います。

1行目の結果は、確定ではなく疑いの印です。 not_covered_suspected と unclear が付いたものだけを人が読み、covered のものは根拠の一文を台帳に残して流し見ます。

3行目がいちばん起きやすい失敗です。 範囲の文が「Manufacture of metal components」なら、AIは切削も板金も鋳造も「金属の部品」として covered にしがちです。指示で「範囲の文に書かれた工程や製品の言葉で判断し、読み広げない」と縛り、迷えば unclear にさせます。

指示内容を固定する

認証範囲の見比べの指示です。

あなたはメーカーの調達部で、海外の仕入先のISO認証書の認証範囲が、
自社が買っている品目に及んでいるかを見る担当者を手伝います。
渡された「認証範囲の文」「認証の対象の事業所」「購入品目の区分と出荷元の事業所」だけを見てください。

【やること】
- 品目の区分ごとに、範囲の文に当たる記述があるかを見て、次のどれかを付けてください。
  covered ................ 範囲の文に、その品目の工程や製品がはっきり書かれている
  not_covered_suspected .. 範囲の文に当たる記述が無い
  unclear ................ 当たるかどうかを範囲の文から決められない
- 出荷元の事業所が、認証の対象の事業所に入っているかも、同じ3つで付けてください。

【厳守事項】
- 根拠として、範囲の文の該当する部分をそのまま evidence に写してください。
  covered のときは evidence を必ず埋めてください。
- 範囲の文に書かれた工程や製品の言葉で判断してください。
  「metal components」を切削・板金・鋳造のすべてに読み広げないでください。
- 「design」の語が範囲に無いときは、設計を含む品目を covered にしないでください。
- 迷ったときに covered を選ばないでください。
- 認証が有効かどうか、仕入先の良し悪しを書かないでください。

「design の語が無いときは設計を含む品目を covered にしない」を入れるのは、ISO 9001 の範囲で設計の有無がよく分かれるからです。 仕入先に設計を任せている品目（仕様だけを渡して設計から頼む部品）なのに、範囲が「Manufacture of ...」だけなら、設計の工程は認証の外かもしれません。 ここは品質保証部が最も気にする点です。

依頼の下書きの指示は短くします。「理由（expiring／scope_check／data_mismatch）ごとに、仕入先名・規格・登録番号・有効期限を渡された値のまま書き、更新した認証書の送付か範囲の確認をお願いする形にする。取引への影響に触れない」とします。

出力形式を固定する

転記の案は、プログラムがJSONで出します。 範囲の見比べも、Claude API の構造化出力で形を決めて受けます。公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。

{
  "supplier_code": "S-3021",
  "certificate": {
    "standard": "ISO 9001:2015", "cert_no": "", "cert_body": "",
    "org_name": "", "org_name_match": "matched | former_name | mismatch",
    "original_date": "2015-06-12", "issue_date": "2024-06-10", "expiry_date": "2027-06-09",
    "date_order_check": "ok | failed", "days_to_expiry": 238
  },
  "scope_text": "",
  "scope_check": [
    { "item_class": "injection_molded_parts", "result": "covered", "evidence": "Manufacture of injection molded plastic parts" },
    { "item_class": "machined_aluminum_parts", "result": "not_covered_suspected", "evidence": "" }
  ],
  "site_check": { "ship_from": "Plant 2", "result": "unclear", "evidence": "" },
  "ledger_diff": [ { "field": "cert_no", "ledger": "", "certificate": "" } ],
  "actions": [ "scope_check" ],
  "min_confidence": 95.2
}

1つ目の理由は、範囲の確認を品目の区分ごとに持てることです。 同じ仕入先でも、成形品は covered、切削品は not_covered_suspected のように分かれます。台帳に品目の区分ごとの結果を残せば、範囲外の品目だけを品質保証部に回せます。

2つ目は、evidence を台帳に残せることです。 covered と判断した根拠の一文が残っていれば、監査のときに「なぜ範囲内と判断したか」を説明できます。

システムへ連携する

仕入先マスタには書き込みません。 転記の案を確かめて登録するのは担当者です。読み取りの誤りで有効期限が延びたまま登録されると、期限切れに誰も気づかなくなります。

IAF CertSearch は、まず担当者が画面で使います。 ISO の公式のページでは、認証は1件ずつ、まとめて、または API で確かめられるとされています。件数が増えたら、まとめての確認を検討します。

人が確認する

担当者が全件の転記の案を確かめます。 見る順を決めておきます。

1. date_order_check が failed のもの、日付を人に回したものを先に見る … 原本で3つの日付を確かめます
2. data_mismatch を確かめる … 組織名の違いが旧社名か、別の会社の認証書かを見ます
3. verify の付いたものを IAF CertSearch で確かめる … 登録番号と認証機関、有効かを確かめます
4. scope_check の根拠を読む … not_covered_suspected と unclear の品目を、範囲の文の原文で確かめ、疑いが残るものを品質保証部に回します
5. 依頼を直して送る … 送信は担当者が行います

3番目で見つからなかったものは、すぐに偽物と決めつけません。 CertSearch に載るのは認定された認証だけで、認定されていない認証機関の認証書は載りません。 取引の条件が認定された認証を求めているかを確かめ、認証機関に直接問い合わせます。

例外に対処する

最後の行が、この構成で最も防ぎたいことです。 期限の確認を届いたときだけでなく毎週全件で行うのは、届かないことに気づくためです。

記録を残す

• 認証書の原本と、保存した場所（仕入先・規格・受領日）
• Textract が返した結果の全文と、組み立てた範囲の文
• 転記の案（certificate、scope_check、site_check）と、範囲の判断の根拠の一文
• 担当者が直した箇所 … どの項目を、どう直したか
• IAF CertSearch で確かめた日と結果
• 仕入先への依頼と催促、届いた認証書

3つ目の根拠の一文は、仕入先の監査と顧客の監査の両方で使います。 範囲内と判断した理由を後から説明できるようにしておきます。