企業保険の引受で、海外の保険会社が発行した英文の損害履歴（Loss Run）を読み取り、年度ごとの事故件数・支払額・未決額を引受審査の入力表にそろえる

処理の起点を決める

見積の依頼ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは lossrun/<見積の依頼番号>/<保険会社の記号>/<種目>/ の形にし、どの依頼のどの保険会社のどの種目かを、保存した場所で決めます。 保険会社と種目を報告書から読み取って決めると、同じ保険会社の別の種目と取り違えます。

読み取りを始めるとき、ClientRequestToken に「依頼番号＋保険会社の記号＋種目＋版」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。

完了は Amazon SNS の通知で受け、JobTag に入れた依頼番号でどの依頼かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。 集計は、担当者が「この依頼の損害履歴はそろった」と印を付けてから始めます。届いた分だけで集計すると、欠けた年度を「事故が無い年度」と取り違えます。

入力データを集める

質を決めるのは、保険会社ごとの設定の「金額の意味」の列です。 発生額に費用を含むか、免責の前か後か、回収を差し引くか。この3つが決まっていれば、意味の違う数字を同じ列に並べずに済みます。 新しい保険会社の損害履歴が来たら、最初の1通で担当者が注記を読んで設定に書きます。

日付の順も設定に入れます。 米国の保険会社は月・日・年の順、欧州の保険会社は日・月・年の順で書くことが多く、「03/04/2024」が3月4日か4月3日かで、事故の保険年度が変わることがあります。

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

表は、CELL のブロックの RowIndex と ColumnIndex で組み立てます。 公式のページでは、表は TABLE のブロックとして返り、各セルは CELL のブロックで表の中の位置の情報を持つとされています。結合されたセルは MERGED_CELL で示されます。証券ごとに見出しの行が入る報告書は、TABLE_SECTION_TITLE のセルで区切りを知ります。

結果は1回に最大1,000ブロックずつ返ります。 NextToken が返る限り呼び続け、全ページ分をそろえてから表を組み立てます。 途中で組み立てると、ページの境目で事故の行が落ちます。

評価日と証券番号は、問い合わせで取ります。 問い合わせは英語の文書でだけ使え、非同期では1ページあたり30件までです。答えが見つからなければ空のまま返るので、評価日の書かれていない報告書を見分けられます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 解除して保存し直します
3. 事故が無い旨の書面の判別 … 表が無く、問い合わせで保険期間が取れた書面は、事故の無い年度の証明として別に扱います
4. ページをまたぐ表の連結 … 見出しが同じなら1つの表として続け、ページごとに繰り返される見出しの行は落とします
5. 数と日付の整え … 括弧付きの金額（負の数）、通貨の記号、桁区切りを数値に直し、日付を設定の順で読みます
6. 保険年度の付与 … 事故の発生日と証券の保険期間から、各事故に保険年度を付けます
7. 小計の照合 … 年度ごとに足した額を、報告書の小計と比べます

5番目の括弧付きの金額を軽く見ないでください。 回収や備金の取崩しは「(12,500)」のように括弧で示されることが多く、括弧を落として正の数として足すと、支払額が実際より大きく見えます。

AIに処理させる

させるのは、言葉を扱う3つの仕事だけです。 数の読み取りは Textract、金額の意味の調整と集計はプログラムが行います。

2行目は、引受の担当者が事故の傾向を見るための補助です。 同じ原因の事故が年度をまたいで続いていれば、防災や安全の対策を顧客に聞くきっかけになります。 区分そのものを審査の数字には使いません。

3行目を外すのは、未決額の評価が損害保険の専門の判断だからです。 AIに「この未決額は少なすぎないか」と聞くと、もっともらしい意見を返します。入力表には読み取った数字だけを入れ、評価は人が行います。

指示内容を固定する

事故の原因の区分の指示です。

あなたは損害保険会社の企業営業部で、海外の保険会社が発行した損害履歴の
事故の説明を原因の区分に分ける担当者を手伝います。
渡された事故の説明の一覧だけを見てください。氏名は伏せてあります。

【区分】
fire（火災）／water（水濡れ）／theft（盗難）／natural_catastrophe（自然災害）／
product_liability（製品の賠償）／premises_liability（施設の賠償）／
auto_bi（自動車の対人）／auto_pd（自動車の対物）／workers_comp（労災）／other

【厳守事項】
- 説明の言葉だけで判断してください。金額の大きさから推し量らないでください。
- 説明の原文を raw にそのまま残してください。
- 「litigation」「suit」「subrogation」「reopened」の語があれば、その語を flags に写してください。
- 2つの区分に当たりうる説明は other とし、note に理由を書いてください。
- 事故の重さ、支払の見込み、引受への影響を書かないでください。

追加資料の依頼の下書きの指示です。

あなたは損害保険会社の企業営業部で、保険仲立人に損害履歴の追加を頼む
英文のメールを下書きする担当者を手伝います。渡された不足の一覧だけを見てください。

【書き方】
- 不足ごとに、保険会社、種目、証券番号、保険期間、不足の理由を並べてください。
- 不足の理由は、missing_year（年度が無い）／stale_valuation（評価日が古い）／
  no_valuation_date（評価日が無い）のどれかです。理由に合う依頼の一文を添えてください。
- stale_valuation には、渡された評価日をそのまま書いてください。
- 見積の可否や保険料に触れないでください。
- 回答の希望日は、渡された日付だけを書いてください。

「litigation」「subrogation」を写させるのは、引受の担当者がまず見る語だからです。 訴訟になっている事故は未決額が動きやすく、求償の事故は回収で支払額が減る見込みがあります。語を写させておけば、入力表の大きな事故の行に印を付けられます。

出力形式を固定する

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

{
  "quote_request": "Q-2026-1042",
  "line": "general_liability",
  "currency": "USD",
  "basis": { "incurred_includes_expense": true, "net_of_deductible": false, "net_of_recovery": true },
  "years": [
    { "policy_year": "2023-2024", "carrier": "", "valuation_date": "2026-06-30",
      "claim_count": 7, "open_count": 2,
      "paid": 182400.00, "expense": 21300.00, "outstanding": 95000.00, "incurred": 298700.00,
      "summary_check": "matched", "source": "loss_run | no_loss_letter" }
  ],
  "large_losses": [
    { "claim_no": "", "date_of_loss": "2024-02-11", "status": "open",
      "incurred": 150000.00, "cause": "product_liability", "flags": ["litigation"] }
  ],
  "issues": [ { "type": "missing_year | stale_valuation | summary_mismatch | low_confidence | no_mapping",
                "detail": "" } ]
}

1つ目の理由は、basis で数字の意味を入力表と一緒に渡せることです。 引受の担当者は、発生額に費用が入っているか、免責の前か後かを見てから数字を読みます。意味が違う保険会社の数字を同じ年度の表に並べないよう、basis が違う報告書は別の表に分けます。

2つ目は、source で事故が無い年度の根拠を示せることです。 件数0の年度が、損害履歴に0件と書かれていたのか、事故が無い旨の書面で示されたのかを区別します。

システムへ連携する

引受審査の仕組みには書き込みません。 入力表の案を確かめて登録するのは営業の担当者です。読み取りの誤りが審査の数字にそのまま入る経路を作らないためです。

Claude を Amazon Bedrock から使う場合は、構造化出力の対応を先に確かめます。 公式のページでは、Bedrock では構造化出力が旧来の連携でだけ使え、Claude in Amazon Bedrock では使えないとされています。

人が確認する

営業の担当者が全件の入力表の案を確かめます。 見る順を決めておきます。

1. summary_mismatch の年度を先に見る … 小計が合わない年度は入力表に入っていません。多くはページの境目の行落ちか、括弧付きの金額の符号です
2. basis を確かめる … 新しい保険会社なら、注記を原本で読んで設定を確かめます
3. missing_year と stale_valuation を確かめ、依頼を送る … 下書きを直して送ります。送信は担当者が行います
4. 大きな事故の行を原本で見る … 金額と状態、flags の語を原本で確かめます
5. 入力表を登録して引受に回す … 不足の資料を待っていることを、入力表の備考に書きます

3番目は、受け取ったその日に行います。 欠けた年度の依頼は、早いほど見積の期限に間に合います。

例外に対処する

下から2行目は、賠償の種目で起きます。 発生日ではなく請求の日で保険年度が決まる契約があり、発生日だけで年度を付けると年度がずれます。 契約の基準は保険会社ごとの設定に書きます。

記録を残す

• 損害履歴の原本と、保存した場所（依頼・保険会社・種目・版）
• Textract が返したブロックの全文と、組み立てた表
• 保険会社ごとの設定の、その時点の版
• 入力表の案（years、large_losses、issues）と、集計に使った事故の行
• 担当者が直した箇所 … どのセルの数を、どう直したか
• 仲立人への依頼と、追加で届いた資料
• 保険会社ごとの summary_mismatch と見出しの対応なしの件数

最後の行は、設定表の手入れに使います。 同じ保険会社で不一致が続くなら、その会社の書式が変わったか、設定に誤りがあります。