Media > AI活用ユースケース > カスタマーサポート > 損害保険の調査会社から届く事故調査報告書を要約し、事故状況・責任割合の根拠・支払判断の論点を、報告書のページを添えて査定担当向けの1枚にまとめる

損害保険の調査会社から届く事故調査報告書を要約し、事故状況・責任割合の根拠・支払判断の論点を、報告書のページを添えて査定担当向けの1枚にまとめる

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

調査会社から届いた事故調査報告書のPDFを読み、事故の概要、当事者の主張の食い違い、責任割合について調査会社が挙げた根拠、支払判断で確かめる論点を1枚の要約にします。要約の各行には、報告書のページと原文の引用を添えます。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Google Apps Script/Python
対象業界
保険
対象部門
カスタマーサポート
対象業務
内容確認・チェック/要約
主な課題
人手が足りない/判断に時間がかかる/属人化している
AIで行う処理
要約
主な効果
判断支援/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
180h/月
AI導入後
72h/月
想定削減
60%
年間削減
1,296h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 調査会社から報告書のPDFが事故の管理システムに添付される
  2. 査定担当が報告書を通読する。写真と図面、聴取記録を行き来しながら読む
  3. 事故の概要、当事者の主張、調査会社の所見を、経過の欄にメモとして書く
  4. 責任割合や支払の判断に関わる記載を探し、ページを控える
  5. 上席に事案を相談するとき、メモと報告書を見せる
導入後(After)
  1. 自動事故の管理システムに報告書のPDFが添付されたことを、要約のプログラムが拾う
  2. 自動プログラムがPDFのページ数とサイズ、文字が取り出せるかを確かめ、ページごとの文字を取り出す
  3. 自動Claude API に報告書のPDFを渡し、決めた項目ごとに要約と、ページ・原文の引用を返させる
  4. 自動プログラムが、引用がそのページの文字にあるかを照合し、無い行に「要確認」の印を付ける
  5. 自動1枚の要約を作り、事故の管理システムの事案に添付して、査定担当に知らせる
  6. 人査定担当が要約を読み、「要確認」の行と、論点の行の該当ページを報告書で確かめる
  7. 人査定担当が要約を直して確定させ、経過の欄に載せる
各工程の詳しい説明を読む
  1. 調査会社から報告書のPDFが事故の管理システムに添付される
  2. 査定担当が報告書を通読する。写真と図面、聴取記録を行き来しながら読む
  3. 事故の概要、当事者の主張、調査会社の所見を、経過の欄にメモとして書く
  4. 責任割合や支払の判断に関わる記載を探し、ページを控える
  5. 上席に事案を相談するとき、メモと報告書を見せる

(a)通読に時間がかかる。 20〜60ページの報告書を、写真や図面と照らしながら読むと、1件で30分近くかかります。 月240件では、それだけで課の時間の大きな部分を占めます。

(b)拾う論点が担当者ごとに違う。 調査会社が所見の最後に「被保険者の申告と現場の痕跡に一部食い違いがある」と書いていても、要約メモに載るかどうかは担当者次第です。 上席が見落としに気づくのは、相談の場で報告書を読み直したときです。

(c)根拠のページを探し直す。 メモに「調査会社は相手方の一時停止違反を指摘」と書いてあっても、どのページのどの記載が根拠かが無いと、上席や後任が報告書を探し直します。

(d)報告書の中の食い違いを見落とす。 聴取記録の時刻と映像の時刻、図面の距離と当事者の説明の距離のように、別々のページに書かれた値の食い違いは、通読しても気づきにくいものです。

  1. 【自動】 事故の管理システムに報告書のPDFが添付されたことを、要約のプログラムが拾う
  2. 【自動】 プログラムがPDFのページ数とサイズ、文字が取り出せるかを確かめ、ページごとの文字を取り出す
  3. 【自動】 Claude API に報告書のPDFを渡し、決めた項目ごとに要約と、ページ・原文の引用を返させる
  4. 【自動】 プログラムが、引用がそのページの文字にあるかを照合し、無い行に「要確認」の印を付ける
  5. 【自動】 1枚の要約を作り、事故の管理システムの事案に添付して、査定担当に知らせる
  6. 【人】 査定担当が要約を読み、「要確認」の行と、論点の行の該当ページを報告書で確かめる
  7. 【人】 査定担当が要約を直して確定させ、経過の欄に載せる

4番目が、この設計の分かれ目です。 AIの要約を信じるのではなく、引用が報告書にあるかを機械で確かめます。 引用が見つからない行は、AIが言い換えたか、報告書に無いことを書いたかのどちらかで、査定担当が必ず見ます。

6番目で論点の行の該当ページを開くのは、要約だけで判断しないためです。 責任割合や支払に関わる記載は、前後の文脈まで読まないと意味が変わることがあります。

02今回想定するシステム構成

構成図
調査会社の事故調査報告書(PDF)
   ▼【トリガー】事故の管理システムへの添付
要約のプログラム(Python)
   ├──▶ ページ数・サイズ・文字の取り出し
   ▼
Claude API ── 報告書の要約
   │   ① 事故の概要   ② 当事者の主張と食い違い
   │   ③ 責任割合について調査会社が挙げた根拠   ④ 支払判断で確かめる論点
   │   ⑤ 報告書の中の食い違いの候補   (各行にページと原文の引用)
   ▼
要約のプログラム ── 引用をページの文字と照合、無い行に「要確認」
   ▼
1枚の要約 → 事故の管理システムに添付
   ▼
【人】査定担当が該当ページを確かめ、要約を確定
役割想定する製品代替候補
処理Claude API(報告書のPDFの要約と、ページ・引用の抜き出し)OpenAI API、Gemini API
連携Python(添付の検知、PDFの文字の取り出し、引用の照合、要約の書き出し)Google Apps Script
事案の管理事故の管理システム共有フォルダと事案の一覧表

新しく作るのは、要約のプログラムと、要約の様式だけです。 事故の管理システムには、要約を添付して担当者に知らせるだけで、事案の記録の項目には書き込みません。

報告書は、Claude API に PDF のまま渡します。 公式の説明では、PDF は各ページを画像に変換し、ページごとに抽出したテキストと一緒に渡され、図や表、写真も読めるとされています。現場の図面や写真の説明を含む報告書を、文字だけでなく見た目ごと読ませられるのが、この製品を選ぶ理由です。 リクエストの上限は32MB、ページ数の上限は600(コンテキストが100万トークン未満のときは100)で、1ページあたり1,500〜3,000トークン程度を使います。パスワードや暗号化のかかったPDFは扱えません。

要約の受け取り方は、Claude API の構造化出力です。 リクエストの output_config.format に type: "json_schema" とスキーマを渡すと、返答がスキーマに沿ったJSONになります。要約の項目と行の形を固定できるので、引用の照合と1枚の様式への書き出しをプログラムで書けます。 enum の文字列は大文字・小文字が保証されないとされているため、値は小文字の英字にし、大文字・小文字を区別せずに比べます。

03どうやって実装するのか

Step1

処理の起点を決める

事故の管理システムの事案に、調査会社から報告書のPDFが添付されたことを起点にします。 要約のプログラムが10分ごとに新しい添付を確かめ、添付の種類が「調査報告書」のものを拾います。見積書や写真だけの添付では動かしません。

報告書の追補が届いたら、もう一度動かします。 調査会社が追加の聴取や現場の再確認の結果を追補として送ってくることがあります。追補は元の報告書と合わせて1つの要約を作り直し、前の要約は版を分けて残します。

動かすのは平日の日中だけにします。 夜間に要約ができても、査定担当が見るのは翌朝で、夜間に失敗したときに気づく人がいません。

Step2

入力データを集める

データ中身取得元
事故調査報告書調査の概要、事故の状況、当事者・目撃者の聴取、現場の状況、写真・図面、調査会社の所見事故の管理システムの添付(PDF)
事案の基本情報事故の種類(自動車・火災・賠償)、事故日、保険の種目事故の管理システム
調査の依頼事項査定担当が調査会社に何を調べるよう依頼したか事故の管理システムの依頼の記録
要約の様式項目の並びと、項目ごとの書き方課で決めた様式

質を決めるのは、調査の依頼事項です。 査定担当が「一時停止の有無と、相手車両の速度を調べてほしい」と依頼していれば、要約ではその2点に報告書が何と答えたかを最初に示します。 依頼事項に答えていない報告書は、それ自体が査定担当の知りたいことです。

事案の基本情報は、事故の種類に合わせて要約の項目を変えるために入れます。 自動車の事故なら当事者の動きと責任割合の根拠、火災なら出火の原因と損害の範囲が中心になります。種類ごとに項目を決めた様式を用意し、プログラムが選んで指示に入れます。

Step3

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

取るものどこから何に使うか
報告書のPDF事故の管理システムの添付要約の材料
ページごとの文字PDFからプログラムで取り出す引用の照合
事故の種類・事故日事故の管理システムの事案の項目様式の選択、食い違いの確認
調査の依頼事項依頼の記録要約の先頭の項目

PDFからのページごとの文字の取り出しは、AIとは別にプログラムで行います。 AIに引用を書かせ、その引用がプログラムの取り出した文字にあるかを比べるためです。同じAIに要約と照合の両方をさせると、照合になりません。

調査の依頼事項が記録に無い事案もあります。 電話で依頼して、依頼書を残していない場合です。その事案では「依頼事項への答え」の項目を作らず、要約の先頭に「依頼事項の記録なし」と出します。 依頼の記録を残す習慣を課に根づかせる材料にもなります。

報告書は、事案の担当者と調査の担当者だけが見られる場所から取ります。 要約のプログラムには、事故の管理システムで報告書を読む権限だけを与え、事案の他の記録には触れさせません。

Step4

AIへ渡す前に整形する

  1. 形式の確認 … PDFであること、パスワードや暗号化がかかっていないことを確かめます
  2. ページ数とサイズの確認 … 32MBとページ数の上限を超えるものは、写真の付録を分けます
  3. 文字の取り出し … ページごとに文字を取り出し、ページ番号と一緒に持ちます
  4. 文字の無いページの把握 … 文字が取り出せないページ(写真だけ、手書きの撮影)を一覧にします
  5. 文字の揃え … 全角・半角、改行、空白を揃えた照合用の文字を作ります
  6. 様式の選択 … 事故の種類から、要約の項目の様式を選びます
  7. 伏せ字の要否の確認 … 報告書の中の、要約に要らない個人の情報の扱いを決めます(第13章)

4番目が、照合の限界を先に知る仕掛けです。 文字が取り出せないページは、AIが画像から読んで要約に書いても、プログラムでは引用を照合できません。 そのページからの引用は、照合の結果を「照合不可」にして、査定担当が画像で確かめる行にします。

2番目で写真の付録を分けるのは、本文の読み取りを優先するためです。 写真が数十枚付いた報告書は、写真だけでサイズとページの上限に近づきます。本文と図面を先に渡し、写真の付録は要約の対象から外して、査定担当が直接見ます。

Step5

AIに処理させる

させるのは、決めた項目ごとに、報告書に書かれていることを短くまとめ、ページと原文の引用を付けることだけです。

項目書くこと報告書に記載が無いとき
調査の依頼事項への答え依頼事項ごとに、報告書が何と書いているか「記載なし」
事故の概要日時、場所、当事者、事故の態様項目ごとに「記載なし」
当事者の主張当事者ごとの主張と、主張どうしの食い違い「記載なし」
責任割合の根拠調査会社が挙げた事実と所見「記載なし」
支払判断で確かめる論点報告書が触れている、損害の範囲・原因・申告との食い違いなど「記載なし」
報告書の中の食い違い別々のページに書かれた値の食い違いの候補(両方の引用)空

右端の列で、無いものは無いと書かせます。 調査会社が所見を書いていない項目に、AIが聴取記録から推して「所見」を作ることを防ぎます。「記載なし」は、査定担当が調査会社に追加で聞く材料になります。

1行ごとに source を付けさせます。 report(調査会社が書いたこと)と inconsistency(AIが見つけた食い違いの候補)の2つで、要約の様式でも2つを分けて並べます。 査定担当が、どれが調査会社の見解で、どれがAIの指摘かを取り違えないためです。

させないこと理由
責任割合を何対何と書く責任割合の判断は査定担当が行う
支払う・支払わない、免責に当たると書く支払の判断は査定担当と上席が行う
報告書に無い事実を補う要約が報告書を超えると、根拠の無い判断の材料になる
当事者の主張の真偽を評価する評価は査定担当と調査会社の仕事
当事者の傷病の詳しい内容を要約に書く支払判断に要る範囲を超える。必要なら診断書で確かめる
写真から状況を推測して書く写真の説明文に書かれたことだけを使う

食い違いの候補として拾わせる型を3つ挙げます。 値は説明のための架空の例です。

食い違いの型拾い方要約での扱い
同じ出来事の時刻・日付が、聴取記録と記録媒体で違う両方のページの引用を並べる差の大きさは書かず、2つの値を並べる
距離・速度・位置が、当事者の説明と図面で違う説明の文と図面の注記を並べるどちらが正しいかは書かない
被保険者の申告と、調査会社が確認した損傷・痕跡が違う申告の記載と確認結果の記載を並べる支払判断の論点の枠にも載せる

どの型でも、AIに「どちらが正しいか」を書かせません。 食い違いがあるという事実と、2か所の原文を並べるところまでです。どちらの記載を採るかは、査定担当が調査会社に確かめて決めます。

させないことの表に戻ると、1行目が最も起きやすい失敗です。 調査会社が「相手方に一時停止違反が認められる」と書いていると、AIはそこから責任割合の目安まで書こうとします。要約に割合の数字が載ると、査定担当がその数字から判断を始めてしまいます。 指示で禁じ、出力に割合の数字が出たらプログラムが印を付けます。

Step6

指示内容を固定する

あなたは損害保険会社の査定担当の補助です。調査会社の事故調査報告書を読み、
決めた項目ごとに、報告書に書かれていることだけを短くまとめてください。

【項目】
1. requested:調査の依頼事項ごとに、報告書が何と書いているか
2. overview:事故の日時・場所・当事者・態様
3. claims:当事者ごとの主張と、主張どうしの食い違い
4. liability_basis:責任割合について調査会社が挙げた事実と所見
5. payment_issues:報告書が触れている、損害の範囲・原因・申告との食い違いなど
6. inconsistencies:別々のページに書かれた値の食い違いの候補

【各行に付けるもの】
- page:根拠にしたページ番号
- quote:根拠にした原文を、一字一句そのまま写す(40字以内の一続きの文字)
- source:report(調査会社が書いたこと)/inconsistency(あなたが見つけた食い違い)
- inconsistencies の行には、食い違う2か所の page と quote を両方付ける

【厳守事項】
- 報告書に書かれていないことを書かないでください。記載が無い項目は「記載なし」としてください。
- 責任割合を数字や比率で書かないでください。
- 支払う・支払わない・免責に当たる、と書かないでください。
- 当事者の主張が正しいかどうかを評価しないでください。
- quote は原文をそのまま写してください。要約や言い換えをしないでください。
- 写真から状況を推測しないでください。写真に付いた説明文は使ってよいです。
- 傷病の詳しい内容は書かないでください。「通院の記載あり(p.12)」のように、
  記載の有無とページだけを書いてください。

【事故の種類】{claim_type}
【調査の依頼事項】{requests}
【要約の様式】{template}
【報告書】(PDF)

「40字以内の一続きの文字」と決めるのは、照合を確実にするためです。 長い引用は、AIが途中を省いたり改行の位置を変えたりして、ページの文字と一致しなくなります。短く一続きにすると、照合の失敗が「AIが書き換えた」場合に絞られます。

「傷病は記載の有無とページだけ」を明記するのは、要約が事案の経過の欄に載るからです。 経過の欄は多くの担当者が見る場所で、傷病の詳しい内容をそこに広げないためです。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "claim_id": "",
  "report_pages": 0,
  "items": [
    {
      "section": "requested | overview | claims | liability_basis | payment_issues | inconsistencies",
      "text": "",
      "source": "report | inconsistency",
      "evidence": [ { "page": 0, "quote": "" } ]
    }
  ],
  "not_found": [ "" ]
}

1つ目の理由は、引用の照合をプログラムで書けることです。 evidence の page と quote を、前処理で取り出したそのページの文字と比べます。

照合の結果条件要約での扱い
照合済みquote がそのページの照合用の文字にあるそのまま載せる
ページ違い別のページにあるページを直して載せ、印を付ける
要確認どのページにも無い行を残し「要確認」の印を付ける
照合不可文字の無いページを指している「照合不可」の印を付け、画像で確かめる
割合の記載text に比率や割合の数字がある印を付け、査定担当が削る

2つ目は、1枚の要約の様式にプログラムで書き出せることです。 section ごとに見出しを分け、source が inconsistency の行は別の枠に入れます。

査定担当には、次のような1枚を渡します。

【事案】C-2026-08812 自動車 報告書:38ページ 調査会社:○○調査

【依頼事項への答え】
 ・一時停止の有無 … 相手方は停止線の手前で停止せずと調査会社が判断(p.21)
 ・相手車両の速度 … 記載なし

【責任割合の根拠(調査会社の所見)】
 ・交差点の見通しは双方とも不良(p.9)
 ・相手方は一時停止の標識を認識していたと聴取で述べた(p.15)  ※要確認

【支払判断で確かめる論点】
 ・被保険者の申告の損傷部位と、現場の痕跡の位置に差があるとの所見(p.24)

【報告書の中の食い違い(AIの指摘)】
 ・事故の時刻:聴取記録 p.14 と、映像の確認結果 p.19 で約10分の差

【記載なし】 相手車両の速度、目撃者の連絡先の確認結果

「依頼事項への答え」を先頭に置くのは、査定担当が最初に知りたいことだからです。 「記載なし」の行は、そのまま調査会社への追加の照会の材料になります。

Step8

システムへ連携する

つなぎ先方式内容
事故の管理システム添付の読み取り、ファイルの添付、通知報告書を拾い、要約を添付して査定担当に知らせる
Claude APIAPI呼び出し(PDF、構造化出力)報告書の要約と引用の抜き出し
要約の様式プログラムからの読み取り事故の種類ごとの項目

事故の管理システムの事案の項目には書き込みません。 要約は添付として置き、経過の欄に載せるのは、査定担当が確定させた後です。 事案の項目に自動で書き込むと、確かめていない要約が事案の記録として残ります。

調査会社への連絡もしません。 「記載なし」の項目を調査会社に照会するかは、査定担当が決めます。

Step9

人が確認する

要約の全行を、査定担当が読みます。

  1. 「要確認」「照合不可」「割合の記載」の行を先に見る … 報告書の該当ページを開き、要約が報告書どおりかを確かめます
  2. 依頼事項への答えと「記載なし」を見る … 調査会社への追加の照会が要るかを決めます
  3. 責任割合の根拠と支払判断の論点の行は、該当ページの前後まで読む … 要約だけで判断しません
  4. 食い違いの指摘を確かめる … 両方のページを開き、本当に食い違っているかを見ます
  5. 要約を直して確定させる … 直した行と理由を残します

3番目が、AIに任せられない部分です。 調査会社の所見は、前後の段落で条件や留保が付いていることがあります。要約の1行は道案内で、判断の根拠は報告書の原文です。

5番目の記録は、様式と指示を直す材料になります。 査定担当が同じ種類の行を毎回直しているなら、項目の決め方か指示の言い方に原因があります。月に1回、直された行を項目ごとに数え、多い項目から様式を見直します。

目標は、240件をならして1件18分です。 報告書が短く照合済みの行ばかりの事案は短く、食い違いの多い事案は長くかかります。

Step10

例外に対処する

起きること対応
パスワードや暗号化のかかったPDF要約せず、査定担当に知らせて調査会社に送り直しを依頼する
サイズ・ページ数が上限を超える写真の付録を分けて本文と図面だけで要約する
文字の無いページが大半要約は作るが、全行を「照合不可」にし、先頭に注意を出す
報告書でない書類が「調査報告書」として添付される要約の冒頭で書類の種類を確かめ、違えば止めて担当者に知らせる
追補が届く元の報告書と合わせて作り直し、前の版を残す
引用がどのページにも無い行を残して「要確認」にする
割合の数字が要約に出る印を付け、査定担当が削る
返ったJSONの値が想定外大文字・小文字を区別せずに比べ、それでも合わなければ「要確認」
Claude API が応答しない添付を未処理のまま残し、次の回で再試行する
調査の依頼事項の記録が無い依頼事項の項目を作らず、先頭に「依頼事項の記録なし」と出す
1つのPDFに複数の事案の報告書が綴じられている要約せず、事案ごとに分けて添付し直すよう担当者に知らせる

上から3行目は、調査会社によっては毎回起きます。 手書きの聴取記録を撮影して綴じる調査会社の報告書は、照合できるページが少なくなります。調査会社に、文字として読めるPDFで送ってもらうよう頼むのが、いちばん効く対策です。

Step11

記録を残す

  • 要約に使った報告書の版(追補を含む)
  • AIの出力のJSONと、照合の結果
  • 査定担当が確定させた要約と、直した行・理由
  • 「記載なし」の項目と、調査会社へ照会したかどうか
  • 要約を作った日時と、使ったモデル

3つ目が、後から最も必要になる記録です。 査定の判断が問われたときに、査定担当が要約のどの行を直し、報告書のどこを根拠にしたかを示せます。

照合の結果を調査会社ごとに数えると、受け取り方を見直す材料になります。 「照合不可」が多い調査会社には、文字として読めるPDFでの提出を相談します。

04実装レベルの3段階

最小構成:伏せ字をしたPDFを手でAIの画面に渡し、項目ごとに要約させる / 1件ごとの要約
半自動化:上記+添付を起点にプログラムで動かし、引用を照合して1枚の様式に書き出す / 要約、引用の照合、様式への書き出し
本格構成:上記+事故の管理システムの経過の欄への登録と、調査会社への照会の下書きまで行う / 要約から照会までの一連

本記事の想定は半自動化です。 要約の作成と照合は1件ごとに閉じた作業で、事故の管理システムに書き込まずに、添付と通知だけで査定担当の手元の時間が減ります。 本格構成は、照合の結果が安定してから進めます。 経過の欄への登録を自動にすると、査定担当が確定させる前の要約が記録に残る経路ができます。登録は、査定担当が確定のボタンを押したときだけにします。 調査会社への照会の下書きも、本格構成で足す候補です。 「記載なし」の項目と、食い違いの候補のうち確かめたいものを選ぶと、照会の文の下書きが出る形です。照会するかどうか、何を聞くかは査定担当が選び、送るのも査定担当です。 照会の答えが追補として届けば、第7章のトリガーで要約が作り直されます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
10 名
月間件数
240 件
1件あたり現在時間
45 分
1件あたり導入後時間
18 分
現在  240件 × 45分 ÷ 60 = 180 時間/月
導入後 240件 × 18分 ÷ 60 = 72 時間/月
月間削減時間
108h
削減率
60%
年間削減時間
1,296h
年間金額換算(時間単価4,000円)
518万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 自動車保険・火災保険・賠償責任保険の保険金の査定で、外部の調査会社に事故の調査を依頼している損害保険会社の損害サービスの拠点。調査報告書が数十ページに及び、査定担当が通読して要約メモを書いている場合。担当者によって要約の書き方や拾う論点が違い、上席の確認で差し戻しが起きている場合。
向いていない
  1. 調査を依頼する事案が月に数件で、査定担当が報告書を通読しても負担にならない場合。調査報告書の多くが手書きの書面を撮影した画像で、文字として照合できない場合。なお、責任割合の判断、保険金を支払うかどうかの判断、免責事由に当たるかの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 過去の事案から、調査報告書を10件選ぶ(うち数件は、上席の確認で論点の見落としが分かったものを入れる)
  2. 当事者の氏名・住所・連絡先・傷病の内容を伏せたPDFを用意する
  3. 手元のAIサービスの画面にPDFを渡し、第7章の項目どおりに要約させ、各行にページと原文の引用を付けさせる
  4. 出てきた要約の引用を、報告書のページで1つずつ確かめる
  5. 当時の担当者の要約メモと並べ、論点の拾い漏れが無いかを見る

10件は必ずやってください。 プログラムを組む前に、「引用が原文どおりか」と「割合や支払の結論を書かないか」を確かめます。

出てきた内容判断
引用がおおむね原文どおりで、当時見落とした論点が拾えているプログラムの組み立てに進む
割合の数字や支払の結論を書く指示とプログラムの印で直る。構成は有効
引用が言い換えられていて、原文と合わない引用の長さと「一字一句」の指示を見直す

3行目は、引用を長く書かせたときによく起きます。 引用を短い一続きの文字に限ると、ほとんどが原文と合うようになります。照合が通らない行が多いままプログラムを組むと、「要確認」ばかりの要約になり、査定担当が結局通読します。

試す前に、伏せ字をしたPDFでも外部のサービスに渡してよいかを、個人情報の担当に確かめてください。 伏せても、事故の状況の記述だけで当事者が分かることがあります。

08実装時につまずきやすいポイント

問題対策
要約に責任割合の数字や支払の結論が出る指示で禁じ、割合の数字をプログラムで拾って印を付ける
引用が言い換えられて照合できない40字以内の一続きの文字に限り、「一字一句」を指示する
報告書に無い所見をAIが作る「記載なし」を書かせ、照合できない行を「要確認」にする
調査会社の見解とAIの指摘を取り違えるsource で分け、様式でも別の枠に入れる
手書きの撮影ページが照合できない「照合不可」にし、調査会社に読めるPDFを頼む
写真の付録で上限を超える写真の付録を分け、本文と図面だけで要約する
傷病の詳しい内容が経過の欄に広がる記載の有無とページだけを書かせる
要約だけで判断してしまう論点の行は該当ページの前後まで読む運用にする
確かめていない要約が事案の記録に残る事案の項目に自動で書き込まない
enum の値の大文字・小文字がずれる値を小文字の英字にし、大文字・小文字を区別せずに比べる
食い違いの指摘でどちらが正しいかを書く2か所の原文を並べるところまでにさせる
依頼事項の記録が無く、先頭の項目が作れない依頼の記録を残す運用を課で決める

上の3行が、この構成の失敗のほとんどです。 どれも、要約を報告書の原文の範囲に閉じ込められているかで決まります。

下の2行は、運用の側の問題です。 食い違いの指摘は便利ですが、AIが「どちらが正しいか」まで書くと、査定担当がそれを前提に調査会社に照会してしまいます。依頼事項の記録は、要約の質を最も左右する入力なので、早いうちに習慣にします。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 事故の当事者・目撃者の氏名と住所、聴取の記録、事故の状況、そしてけがの状況や通院の記載です。金融分野における個人情報保護に関するガイドラインは、要配慮個人情報と、保健医療などに関する情報を「機微(センシティブ)情報」とし、決められた場合を除いて取得・利用・第三者提供を行わないこととしています。

  1. 機微な情報の利用目的と範囲を確かめる … 同じガイドラインは、保険業の適切な業務運営を確保する必要性から、本人の同意に基づき業務遂行上必要な範囲で取得・利用する場合を例外の1つに挙げ、その事由を逸脱しないよう特に慎重に扱うこととしています。要約に傷病の詳しい内容を書かせないのは、この範囲を広げないためです
  2. 外部のサービスに渡すことを、委託の手続きとして整理する … ガイドラインには委託先の監督の条文があります。報告書を外部のAIのサービスに渡すことが社内の規程でどう扱われるかを、個人情報の担当と確かめてから始めます
  3. 利用するサービスのデータの扱いを確かめる … Claude API の公式の説明では、保持したデータは明示の許可なくモデルの学習に使われず、会話の内容は既定では保持されない(一部のモデルを除く)とされ、ゼロデータ保持の取り決めも申し込めます。どのモデルを使い、どの取り決めにするかを決めておきます
  4. 要約は判断ではない … 責任割合・支払・免責の判断は、査定担当と上席が報告書の原文をもとに行います
  5. 要約を契約者や相手方に見せない … 要約は社内の作業の記録です

誤りが起きた場合のリスクは、報告書に無いことが要約に載って判断の材料になることと、論点が要約から落ちて見落とされることの2つです。 前者は引用の照合と「要確認」で、後者は「記載なし」と依頼事項への答えを先頭に置くことで防ぎます。

10まず何から始めるか

1週目:要約の様式と社内の手続きを決める

自動車・火災・賠償の事故の種類ごとに、要約の項目の様式を決めます。あわせて、報告書を外部のAIのサービスに渡すことを、個人情報の担当と整理します。 ここが決まるまで、実際の報告書は使いません。

2週目:10件で試す

伏せ字をした過去の報告書10件で、手元のAIサービスに要約させます。引用が原文どおりか、割合や支払の結論を書いていないかを最優先で見ます。

3週目:照合を作る

PDFからページごとの文字を取り出し、引用を照合するプログラムを作ります。この時点では、2週目の要約の引用を照合にかけ、「要確認」がどれくらい出るかを数えます。

4週目:添付からの一連をつなぐ

事故の管理システムの添付を起点に、要約・照合・様式への書き出し・通知までをつなぎます。査定担当2名で、1週間使ってもらいます。

2か月目: 課の全員に広げ、査定担当が要約を直した行の割合と、「要確認」「照合不可」の割合を調査会社ごとに数えます。3か月目以降: 照合不可の多い調査会社に提出の形を相談します。上席が事案の相談で報告書を最初から読み直さなくなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-08/最終更新:2026-10-08
確認した内容情報源確認日
要配慮個人情報と、労働組合への加盟・門地・本籍地・保健医療・性生活に関する情報を機微(センシティブ)情報とし、決められた場合を除き取得・利用・第三者提供を行わないこととすること(第5条第1項)。保険業その他金融分野の事業の適切な業務運営を確保する必要性から、本人の同意に基づき業務遂行上必要な範囲で取得・利用・第三者提供する場合が例外に含まれること(同項第8号)。事由を逸脱しないよう特に慎重に取り扱うこと(同条第2項)。委託先の監督の条文(第10条)があること。令和6年3月の版であること個人情報保護委員会: 金融分野における個人情報保護に関するガイドライン2026-10-08
PDF のリクエストの上限が32MB、ページ数の上限が600(コンテキストが100万トークン未満のときは100)であること。パスワードや暗号化のないPDFが対象であること。各ページが画像に変換され、抽出したテキストと一緒に渡されること。1ページあたり1,500〜3,000トークン程度を使うことClaude Docs: PDF support2026-10-08
output_config.format に type: "json_schema" を指定すると返答がスキーマに沿ったJSONになること。enum が使えること。enum の大文字・小文字が保証されず、大文字・小文字を区別せずに比べるよう推奨されていることClaude Docs: Structured outputs2026-10-08
保持したデータが明示の許可なくモデルの学習に使われないこと。会話の内容が既定では保持されないこと(一部のモデルは30日の保持が必要)。ゼロデータ保持の取り決めを申し込めることClaude Docs: API and data retention2026-10-08

責任割合・保険金の支払・免責の判断は、査定担当と上席が報告書の原文をもとに行ってください。 本記事は個人情報保護委員会・Anthropic の公開している情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1104)についてのご相談はこちらから。

AI活用について相談する
目次