海外の委託先から届く英文の保険証明書を読み取って取引先台帳に転記し、契約で求める補償条件の不足と期限切れ間近を拾う

処理の起点を決める

処理の起点は2つです。 1つは、受付フォルダ（Amazon S3）に証明書が保存されたこと。もう1つは、毎月1日の定時実行で、台帳の期限を見直します。

証明書の受け取り用のメールアドレスを委託先と保険代理店に案内し、添付を自動で受付フォルダへ保存します。 保険代理店から直接届く証明書も多いので、契約のときに代理店にもこのアドレスを伝えてもらいます。

月1回の見直しは、証明書が届くかどうかに関係なく動かします。更新の証明書が届かない委託先は、受け取りの起点だけでは永久に拾えないからです。処理が終わった証明書は処理済みの場所へ移し、移すのは確認の一覧への書き出しまで成功したときだけにします。

入力データを集める

質を決めるのは、求める補償の条件の表です。 「一般賠償責任 100万ドル」とだけ書くと、1事故あたりか総額かが決まりません。比べる欄まで決めておくことが、第3章の（b）を解きます。

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

読み取りは、Lambda から StartDocumentAnalysis を呼んで始めます。 文書はS3の場所で指定し、完了の通知先にSNSのトピックを渡します。ClientRequestToken に受付のファイルごとの値を入れ、同じ証明書の処理が二重に始まらないようにします。 JobId は7日間しか有効でないので、完了を受けたらすぐに GetDocumentAnalysis で結果を取り、自社のバケットへ書き出します。

質問（Queries）は英語の文書だけで使えます。 「What is the certificate date?」「What is the certificate number?」のような、表の外の項目を取るのに使います。フランス語の証明書（カナダのケベック州など）では、質問を外します。

書式が決まった証明書が多い場合は、アダプターも選べます。 AdaptersConfig で、自社の証明書で学習させたアダプターを指定できます。学習には5件から2,500件の文書を使います。まず標準の機能で3か月回し、読み違いの多い欄が分かってから検討します。

AIへ渡す前に整形する

1. 形式の確認 … 扱えるのはJPEG、PNG、PDF、TIFFです。XFA形式のPDFには対応していません
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 送り直してもらいます
3. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上（150dpiで8ポイント）。証明書の表の小さな文字が、この下限に近いことがあります。 保険代理店が出したPDFをそのまま送ってもらい、印刷してスキャンしたものは避けます
4. 委託先の特定 … 送り元のアドレスと被保険者の名前から取引先台帳を引きます。引けなければ needs_human
5. 書式の判別 … 1ページ目の題と書式の番号（「ACORD 25」など）で、標準の書式か独自の書式かを分けます
6. 補償額と日付の正規化 … 「$1,000,000」「1M」「1,000,000」を数値に、「MM/DD/YYYY」を自社の形に直します。元の文字列は残します
7. 重複の検知 … 同じ委託先・同じ証明書の番号のものが既にあれば、再送か改訂かの印を付けます

6番目はAIに任せません。 日付の書き方は書式で決まっており、ACORD 25 では月・日・年の順です。オセアニアの証明書は日・月・年の順で書かれることが多く、生成AIに読ませると、期限が数か月ずれた値で照らすことになります。

AIに処理させる

させるのは、読み取り結果を保険の種類ごとの行にそろえ、備考欄の追加被保険者の記載を原文で切り出すことだけです。

補償額を「欄の名前と値の組」で出させるのは、比べる欄を規則の側で選ぶためです。 一般賠償責任には「EACH OCCURRENCE」「GENERAL AGGREGATE」など複数の欄があります。AIに1つの補償額にまとめさせると、どの欄の値かが分からなくなります。

2行目がいちばん大事です。 備考欄に「Certificate holder is included as additional insured」と書かれていると、AIは頼まなくても「追加被保険者として確認済み」とまとめます。証明書にはそれが権利を与えないと明記されています。 書かれていることと、保険でそうなっていることを分けます。

指示内容を固定する

あなたは物流会社の購買部で、委託先から届いた英文の保険証明書を、
取引先台帳の形にそろえる立場です。
渡すのは、OCRが返した読み取り結果（キーと値、表、チェック欄の状態）です。
そこに書かれたことだけを使ってください。

【書き出すこと】
1. insured, producer, certificate_holder, certificate_date, certificate_no
2. 保険の種類ごとの行: coverage_type, insurer_letter, policy_no,
   eff_date, exp_date, addl_insd, subr_wvd,
   limits（欄の名前と値の組をすべて）, checkboxes（選択の状態）
3. remarks_text: 備考欄のうち、追加被保険者・代位求償の放棄・
   証明書の保有者に触れた文を原文のまま

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 補償額・日付・証券番号は、読み取り結果の文字列のまま写してください。
  単位を直したり、合算したりしないでください。
- 補償額は、欄の名前（EACH OCCURRENCE など）と値の組で書いてください。
  1つの補償額にまとめないでください。
- addl_insd と subr_wvd は、表に書かれた文字をそのまま写し、
  空欄なら空欄のままにしてください。備考欄の記載から埋めないでください。
- チェック欄の状態は、読み取り結果の SELECTED / NOT_SELECTED に従い、
  状態が無いものは unknown としてください。
- 補償が足りるか、契約の条件を満たすか、追加被保険者として
  認められるかを書かないでください。
- 保険証明書でない書類（保険証券の写し、裏書、請求書など）と判断した
  場合は、そろえる作業をせず document_type に種類を書いてください。

【読み取り結果】{textract_result}

「備考欄の記載から埋めない」を書かないと、表の空欄が埋まります。 表の追加被保険者の列が空欄でも、備考欄に「additional insured」とあれば、AIは列に「Y」を入れて返します。表と備考欄の食い違いこそ、人が確かめるべきところです。

「保険証明書でない書類」を分けさせるのは、裏書の写しが同じアドレスに届くからです。 裏書を証明書として読むと、種類ごとの行が空のまま coverage_missing になります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とJSONスキーマを渡す）を使うと、スキーマどおりの形で返り、必須の項目が欠けません。

{
  "document_type": "certificate_of_insurance",
  "insured": "",
  "producer": "",
  "certificate_holder": "",
  "certificate_date": "",
  "certificate_no": "",
  "coverages": [
    { "coverage_type": "general_liability", "insurer_letter": "",
      "policy_no": "", "eff_date": "", "exp_date": "",
      "addl_insd": "", "subr_wvd": "",
      "limits": [ { "label": "", "value": "" } ],
      "checkboxes": [ { "label": "", "status": "" } ] }
  ],
  "remarks_text": ""
}

この後に、Python が照合を足します。

1つ目の理由は、比べる欄を条件の表で決められることです。 求める条件の表に「一般賠償責任は EACH OCCURRENCE で比べる」と書いておけば、担当者ごとに比べる欄が違うということが無くなります。

2つ目は、endorsement_needed を列の記載と裏書の写しの両方で決めることです。 列に「Y」があっても、裏書の写しが台帳に無ければ確かめを求めます。 証明書が権利を与えないという前提を、規則の側で守ります。

システムへ連携する

委託の停止や配車の仕組みへは、何も書き込みません。 期限が切れた委託先に仕事を出さないかは、購買と現場の判断です。この構成が出すのは、期限と不足の事実までです。

人が確認する

人が開くのは ok 以外の証明書です。

1. 期限切れの coverage_missing を最優先で見る … その委託先に今月仕事を出しているかを現場に確かめます
2. limit_short を見る … 不足額を添えて、委託先に補償の引き上げを求めるかを決めます
3. endorsement_needed を見る … 裏書の写しを委託先に求めます。表現が契約の条件に合うかは法務に相談します
4. name_mismatch を見る … 屋号か親会社の名前か、別の会社か。別名なら台帳に積みます
5. expiring は更新の依頼の下書きを確かめて送る

3番目で法務に回すのは、裏書の文言の読み方が保険の法的な解釈になるからです。 購買の担当者が決めてよいのは、写しが届いているかどうかまでです。

目標は、90件をならして1件8分です。 ok は数分、endorsement_needed で法務に相談するものは20分以上かかる想定です。

例外に対処する

下から2行目を軽く見ないでください。 委託先が別の荷主向けに取った証明書をそのまま送ってくることがあります。証明書の保有者が自社でなければ、補償の条件を満たしていても受け付けません。

記録を残す

• 元の証明書のPDFと、受け取った日時・送り元
• OCRが返したJSONの全文
• AIが返したJSONと、照合の結果
• 照合に使った求める補償の条件の表の版
• 人が確定・変更した記録と、法務への相談の結果
• 委託先への依頼と回答、裏書の写しの受け取り
• 月1回の期限の見直しの結果と、依頼を送った日時

「求める補償の条件の表の版」を残すのは、契約の条件が改定されるためです。 補償額の引き上げを契約で求めた後で過去の判定を見ると、当時は ok だったものが不足に見えます。いつの条件で照らしたかが残っていないと、どこまで依頼し直すかが決まりません。