輸入の案件で海外の売り手から届く英文の貨物海上保険の保険証明書を読み取り、保険金額・担保条件・航路を案件台帳と照らして、条件の不足を拾う

処理の起点を決める

受付フォルダ（Amazon S3）に保険証明書のPDFが保存されたことを起点にします。 保存の通知で AWS Lambda が動き、照合までを済ませます。1日1回の定時実行にはしません。

保存するのは担当者で、ファイル名の先頭に契約番号を入れる決まりにします。 メールの件名から自動で取る方法もありますが、売り手ごとに書き方が違い、取り違えると別の案件の条件で照合するため、最初は人が付けます。

再発行された証明書は、契約番号の末尾に版を付けて保存します。

入力データを集める

質を決めるのは、下の3つです。 求める条件が決まった値で書かれていなければ照合の規則が書けず、約款の呼び方の一覧が無ければ、同じ (A) を別の条件として扱います。 一覧は読み慣れた担当者が過去の証明書から作り、一覧に無い書き方が出たら確かめてから足します。

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

読み取りは StartDocumentAnalysis に S3 の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

担保条件のように表面と裏面の両方に書かれうる項目は、質問の答えだけに頼らず、全文を生成AIに渡して探させます。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。JobId は7日間しか有効でないため、取った結果はその場で S3 に保存します。 状態が PARTIAL_SUCCESS のときは Warnings のページ番号を記録し、そのページを読めなかったものとして扱います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA で作られたPDFは扱えないとされているので、印刷してPDFにし直します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは、売り手に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです。船積書類一式が1つのPDFで届いたときは、証明書のページだけを切り出します
4. 言語の確認 … 英語以外の証明書は質問が使えないため、読み取りに回さず担当者の一覧に入れます
5. 文字の大きさの確認 … 検出できる文字の高さの下限は15ピクセルで、150DPIで8ポイント相当です。裏面の約款はこの下限に近いことが多いため、スキャンの写しは解像度を確かめます
6. 契約番号の確認 … ファイル名の契約番号で台帳が引けるかを確かめ、引けなければ処理を止めて担当者に戻します

5番目を軽く見ないでください。 写しをさらに写したPDFでは、裏面の小さな字の約款に読めない行が出ます。

AIに処理させる

させるのは、読み取り結果から7つの項目を取り出し、それぞれに根拠の文字列と状態を付けることだけです。 案件台帳との照合は Python が行い、AIには台帳を渡しません。

担保条件の欄が、この構成でいちばん大事です。 原文を evidence に写させ、一覧のどの呼び方に当たるかだけを選ばせます。

4行目がいちばん起きやすい失敗です。 指示で禁じたうえで、evidence が空の present が無いかを後段で機械的に確かめます。

指示内容を固定する

あなたは商社の輸入業務課で、売り手から届いた英文の貨物海上保険の
保険証明書を読み、記載を項目に分ける担当です。
AWS Textract の読み取り結果だけを見て答えてください。推測で埋めないでください。

【取り出す7項目】
1. 証明書番号と被保険者（Assured）
2. 保険金額（Amount Insured）と通貨
3. 担保条件（Conditions）
4. 追加の約款（戦争・ストライキ）
5. 船名、仕出地、積み替え地、仕向地
6. 貨物の記載（品名・数量）と荷印
7. 保険金の支払地（Claims payable at）と、仕向地での検査の連絡先

【status の選び方】
- present ........ 値が読み取れている
- missing ........ 該当する記載が無い。項目名だけがあって値が空の場合も missing
- unreadable ..... 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous ...... 値の候補が複数あり、1つに決められない
- unlisted ....... 担保条件の文言が、約款の呼び方の一覧のどれにも当たらない
- not_fixed ...... 「to be declared」「TBA」など、値が未確定と書かれている
- reference_only . 「as per invoice」など、別の書類を参照するとだけ書かれている
迷ったときに present を選ばないでください。

【厳守事項】
- 金額と通貨は書かれたとおりに写してください。換算・丸め・合算をしないでください。
- 担保条件は、evidence に原文をそのまま写したうえで、
  約款の呼び方の一覧のうち一致するものの記号（A／B／C）を選んでください。
  一覧に一致するものが無ければ unlisted とし、読み替えないでください。
- 戦争・ストライキの約款は、表面と裏面の両方を探してください。
  見つからなければ missing です。「通常は付いている」と補わないでください。
- 読み取りの警告が出ているページがあれば、そのページにありうる項目は
  missing ではなく unreadable としてください。
- evidence には根拠の文字列を原文のまま、ページ番号と一緒に写してください。
- 契約の条件に足りるか、追加で保険を手配すべきかは書かないでください。
- 保険証明書でない書類（インボイス、保険料の請求書など）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_result}
【読み取りの警告があったページ】{warning_pages}
【約款の呼び方の一覧】{clause_aliases}

「迷ったときに present を選ばない」を区分の直後に置くのは、意図してのことです。 担保条件の欄には何かしらの約款名が必ず書かれているので、何も言わないと内容を見ずに present で通ります。

警告のあったページを渡すのは、missing と unreadable を分けるためです。 裏面が読めていないことを知らなければ、戦争の約款が見つからないことを、書かれていないこととして答えます。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema）で、次の形のJSONを受け取ります。 数値の minimum・maximum の制約は使えないとされているため、値の範囲は Python の側で確かめます。

{
  "contract_no": "IMP-2026-0912",
  "document_type": "insurance_certificate",
  "items": [
    { "item": "sum_insured", "status": "present",
      "value": "USD 132,000.00", "amount": "132000.00", "currency": "USD",
      "page": 1, "confidence": 98.1, "evidence": "Amount Insured: USD 132,000.00" },
    { "item": "conditions", "status": "present",
      "value": "Institute Cargo Clauses (C) 1/1/09", "clause_code": "C",
      "page": 1, "confidence": 96.4, "evidence": "Conditions: Institute Cargo Clauses (C) 1/1/09" }
  ]
}

items には7項目を並べます。item は cert_and_assured ／ sum_insured ／ conditions ／ war_strikes ／ voyage ／ cargo ／ claims_payable です。

照合は Python が台帳の条件と突き合わせて行い、項目ごとに印を付けます。

判定は、印と状態の組み合わせで規則として決めます。

status はAIが付け、印は Python が台帳と照らして付け、verdict は規則で決まります。 層を分けておけば、契約の条件が変わっても直すのは台帳と規則だけです。

システムへ連携する

案件台帳への書き込みは、「保険の確認」の列だけに限ります。 照合の元になる列を、照合する側が書き換えられないようにします。基幹システムの輸入管理とはつなぎません。

人が確認する

担当者が開くのは needs_correction と needs_human の証明書だけです。 ok のものは一覧で契約番号と売り手を流し見て、確認の列を確定します。

1. needs_human を先に見る … 多くは裏面が読めていないか、一覧に無い約款の書き方です
2. needs_correction の印の根拠を確かめる … evidence とページで、証明書の該当箇所を目で見ます
3. clause_short と amount_short の対応を決める … 売り手に訂正を頼むか、自社で上乗せの保険を手配するかを、課長と決めます
4. 訂正依頼を送る … 下書きを直して送ります。送信は人が行います
5. 印を覆したら記録する … どの印を、なぜ外したかを残します

3番目は、この構成が決めない部分です。 船がすでに出ていれば、売り手の保険を直すより自社で手配するほうが早いこともあります。

目標は、240件をならして1件4分です。 開くのは2割前後という想定です。

例外に対処する

上から4行目までが、試す段階でいちばん多く出るはずです。 どれも受け取り方の問題で、船積書類の案内に「保険証明書は単独の文字の入ったPDFで」と一文足せば多くは減ります。

記録を残す

• 元の証明書ファイル（版を含む）と、受け取った日時・送り主
• AWS Textract が返したJSONの全文と、Warnings のページ
• 生成AIが返した7項目のJSON、Python が付けた印、verdict
• そのとき参照した案件台帳の条件（求める担保条件、割合、戦争・ストライキの要否）
• 人が印を覆した記録 … どの印を、なぜ外したか
• 売り手への訂正依頼の日時と、再発行された証明書との対応

4つ目で「そのときの台帳の条件」を残すのは、契約の条件が後から変わることがあるからです。 当時の条件が残っていないと、事故のあとに「当時は足りていたのか」を答えられません。