海外子会社から届く英文の保険証券を読み取り、保険期間・てん補限度額・免責金額をグループの付保台帳に転記して、方針との不足と更新の近いものを拾う

処理の起点を決める

起点は2つあります。証券が受付フォルダに入ったときと、毎月1日の定時です。

1つ目は、受付フォルダ（Amazon S3）に証券のPDFが保存されたことです。子会社ごとに共有フォルダを分け、子会社名と保険の種類が分かるように置いてもらいます。保存の通知で AWS Lambda が動き、読み取りから台帳の下書きまでを済ませます。子会社の担当者が本社にメールで知らせる手順は残しますが、処理はメールを待たずに始まります。

2つ目は、毎月1日の定時です。付保台帳の全契約について、保険期間の終わりまで90日を切ったもの、60日を切っても更新の証券が届いていないもの、期間が過ぎたのに新しい証券が無いものを一覧にし、本社の担当者に送ります。更新の管理を、担当者の記憶ではなく台帳の側に置きます。

期中に届く変更の裏書も、同じ経路で入れます。 証券番号が同じものは、台帳の同じ行の履歴に足します。

入力データを集める

質を決めるのは、付保方針の表です。 今の方針の文書は「賠償責任は十分な限度額を付けること」のような書き方も混ざっており、1事故あたりか合計かが書かれていない項目があります。 照合の前に、限度額の種類ごとの金額に書き直します。

子会社の名称の揺れの一覧は、被保険者の確認に使います。 証券の被保険者が親会社の名前だけになっている、旧社名のままになっている、という契約があります。被保険者に子会社が含まれていなければ、限度額が足りていても意味がありません。

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

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

質問の答えが見つからなければ空のまま返ります。 空なら、明細のページの表とキーと値から探します。財物の保険のように限度額が建物・在庫・設備ごとに表で並ぶものは、質問より表のほうが確実です。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。同期の処理はPDF1ページまでで、証券は数十ページあるので非同期で読みます。 JobId は7日間しか有効でないため、取った結果はその場でS3に保存します。

裏書は、明細とは別に、ページごとの見出しで拾います。 Endorsement、Amendment、It is hereby agreed のような言い方で始まるページを裏書として集め、生成AIに渡します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは子会社に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 言語の確認 … 英語以外の証券は質問が使えないため、読み取りに回さず担当者の一覧に入れます
5. 明細のページの特定 … 1ページ目から順に、Declarations、Schedule のような見出しのあるページを探し、質問の Pages に入れます。パッケージの証券では、保険の種類ごとの明細の範囲を分けます
6. 重複の確認 … 同じ証券番号・同じ保険期間の証券が台帳にあれば、差し替えか重複かを確かめる印を付けます

AIに処理させる

させるのは、保険の種類ごとに明細の値を原文のまま写し、限度額の種類を区別し、裏書が変えている条件を拾うことです。 方針との照合と補償の評価はさせません。

限度額の種類を分けさせるのは、方針がそれぞれに金額を決めているためです。 1事故あたりと合計を取り違えると、同じ金額でも方針に届いているかの結論が逆になります。

5行目がいちばん起きやすい失敗です。 更新の証券に限度額が見つからないと、前の期の台帳の値や、よくある金額を答えにしがちで、その瞬間に「方針に届いている」という誤った結論が台帳に入ります。

指示内容を固定する

あなたは商社の本社財務部で、海外子会社から届いた英文の保険証券の
条件をグループの付保台帳に記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目（保険の種類ごと）】
coverage_line、insurer_raw、policy_no、named_insured_raw、
additional_insured_raw、period_start_raw、period_end_raw、
limits（kind：each_occurrence／aggregate／sublimit、amount_raw、currency_raw、
対象の説明）、deductible（amount_raw、currency_raw、basis）、
endorsements（変更の内容、ページ）、各項目の status とページ

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数ある、または限度額の種類が決まらない

【厳守事項】
- 限度額は、1事故あたり（each occurrence など）、期間中の合計
  （aggregate など）、特定の損害だけの限度額（sublimit）を分けて
  ください。どれか決まらなければ kind を空にし、status を ambiguous
  にしてください。
- 金額と通貨は書かれたとおりに入れてください。換算しないでください。
- 書かれていない限度額や免責金額を、前の期の値や一般的な水準で
  埋めないでください。
- 裏書が限度額・免責金額・被保険者・補償の範囲を変えている場合は、
  変更の内容を原文のまま短く写し、ページを書いてください。
- 約款の本文に出てくる例示の金額を、この契約の値として使わないで
  ください。値は明細のページと裏書からだけ取ってください。
- 補償が十分か、方針を満たすかを書かないでください。
- 保険証券でない書類（請求書、見積書、証明書など）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_tables_queries}
【明細のページの範囲】{declaration_pages}
【裏書のページ】{endorsement_pages}

「前の期の値で埋めない」を明記しないと、埋めます。 台帳の情報を渡していなくても、よくある限度額を「一般的な」値として書き添えることがあります。台帳の前の期の値は、そもそも生成AIに渡しません。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "file": "",
  "document_type": "insurance_policy",
  "subsidiary_code": "US02",
  "coverages": [
    {
      "coverage_line": "general_liability",
      "insurer_raw": "",
      "policy_no": "GL-2026-55821",
      "named_insured_raw": "",
      "period_start_raw": "10/01/2026",
      "period_end_raw": "10/01/2027",
      "limits": [
        { "kind": "each_occurrence", "amount_raw": "1,000,000", "currency_raw": "USD" },
        { "kind": "aggregate", "amount_raw": "2,000,000", "currency_raw": "USD" }
      ],
      "deductible": { "amount_raw": "25,000", "currency_raw": "USD", "basis": "each occurrence" },
      "endorsements": [ { "change_raw": "", "page": 34 } ],
      "items": [ { "item": "limits", "status": "ok", "confidence": 0, "page": 2 } ]
    }
  ]
}

1つ目の理由は、照合をプログラムの側に置けることです。 Python が金額を数値に直し、社内レートで換算して、付保方針の表と比べて印を付けます。

2つ目は、通貨の換算を記録として残せることです。 原文の金額と通貨、使った社内レート、換算後の金額を並べて台帳に残すので、為替が動いて方針の境目を越えたときに、どの契約から見直すかがすぐに分かります。

システムへ連携する

付保台帳の確定は、担当者が行います。 この構成が書くのは下書きの行までです。台帳は保険の仲介者や監査に出す資料の元になるため、確定した値と確かめた人を分けて残します。

人が確認する

本社の担当者が開くのは、ok 以外の印が付いた契約です。 ok の契約は、取り出した値と出どころの一覧で流し見ます。

1. needs_human を先に見る … 被保険者に子会社が見つからないものは、限度額の確認より先に子会社に確かめます
2. endorsement_change の裏書を読む … 該当ページを開き、変わった条件を台帳に反映します
3. below_minimum と deductible_over を確かめる … 証券の該当ページで値と限度額の種類を確かめてから、子会社と相談します
4. expiring_soon の更新の予定を子会社に聞く … 更新の手配が進んでいるか、条件を変える予定があるかを確かめます

3番目の順序を崩さないでください。 読み取りの誤りによる不足を子会社に伝えると、子会社は仲介者に追加の見積を頼み始めます。 確かめてから相談します。

例外に対処する

上から3行目が、運用の初めに多く出ます。 保険証券ではなく保険証明書や仲介者の見積書が入れられていることがあり、どれを入れてほしいかを子会社に伝えると減ります。

記録を残す

• 元の証券と、受け取った日時、子会社、保険の種類
• AWS Textract が返したJSONの全文と、使った質問とページの指定
• Claude API が返したJSON
• 照合の結果と、そのとき参照した付保方針の表と社内レート
• 担当者が値や限度額の種類を直した記録 … どの項目を、どう変えたか、誰が確かめたか
• 子会社との相談の記録と、追加・変更の結果

付保方針の表の版を残すのは、方針が見直されるためです。 最低の金額を引き上げると、過去に ok だった契約が不足になります。 当時の方針が残っていれば、どの契約から見直すかがすぐに決まります。