Media > AI活用ユースケース > カスタマーサポート > 保険金を支払えない・一部だけ支払う事案の通知文を、約款の該当箇所と理由を添えてClaudeで下書きし、決まった言い回しと不服申立ての案内の抜けを確かめる

保険金を支払えない・一部だけ支払う事案の通知文を、約款の該当箇所と理由を添えてClaudeで下書きし、決まった言い回しと不服申立ての案内の抜けを確かめる

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

支払担当が不払・一部支払と判断した事案について、査定の記録の認定事実と適用条項から、理由を説明する通知文の下書きを Claude で作ります。社内の定型文と相談窓口の案内がそろっているか、金額と条項が記録と合っているかは、プログラムで確かめます。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
n8n/Power Automate/Python
対象業界
保険/金融
対象部門
カスタマーサポート
対象業務
内容確認・チェック/書類作成
主な課題
属人化している/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
生成
主な効果
入力漏れ削減/品質標準化/工数削減
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
200h/月
AI導入後
75h/月
想定削減
63%
年間削減
1,500h
モデル条件による試算値です。実在企業の実績ではありません。

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

導入前(Before)
  1. 支払担当が査定を終え、支払システムに結論・適用条項・認定事実・算定の内訳を入力する
  2. 通知文の雛形を開き、契約者名・証券番号・事故日を書き入れる
  3. 約款のデータベースで適用条項を探し、条文を雛形に貼る
  4. 認定した事実と条項をつないで、理由の段落を書く
  5. 一部支払の場合は、算定の内訳を支払システムから写して表にする
  6. 課長が読み、言い回しと条文と金額を確かめて承認する
  7. 郵送またはWebの契約者ページで送る
導入後(After)
  1. 人支払担当が査定を終え、支払システムの結論・適用条項・認定事実・算定の内訳を確定する
  2. 自動確定をきっかけに、結論が不払か一部支払の事案を取り出す
  3. 自動対象外の事案(解除・不正請求の疑い・訴訟中など)を規則で外し、担当者に戻す
  4. 自動契約の始期に効いている版の約款から、適用条項の条文を取り出す
  5. 自動Claude API が、認定事実と条項から理由の本文を書き、各段落がどの事実とどの条項に対応するかを返す
  6. 自動本文に、条文・金額・算定の表・定型文・相談窓口の案内をプログラムが差し込み、通知文を組み立てる
  7. 自動定型文の一致、条項番号と金額の一致、禁止の言い回し、案内の有無を規則で検査する
  8. 人支払担当が、理由の本文が査定の判断と合っているかを確かめて直す
  9. 人課長が、検査の結果と本文を見て承認する
  10. 【人/自動】 承認された通知文を送り、送付した版を残す
各工程の詳しい説明を読む
  1. 支払担当が査定を終え、支払システムに結論・適用条項・認定事実・算定の内訳を入力する
  2. 通知文の雛形を開き、契約者名・証券番号・事故日を書き入れる
  3. 約款のデータベースで適用条項を探し、条文を雛形に貼る
  4. 認定した事実と条項をつないで、理由の段落を書く
  5. 一部支払の場合は、算定の内訳を支払システムから写して表にする
  6. 課長が読み、言い回しと条文と金額を確かめて承認する
  7. 郵送またはWebの契約者ページで送る

(a)理由の段落に時間がかかる。 4番目は、認定した事実を契約者が読める言葉に直す作業です。「本件損害は経年による腐食に起因するものと認められ」を、そのまま書けば契約者に伝わらず、崩しすぎれば条文と食い違います。1件に20分前後かかります。

(b)定型文と相談窓口の案内が抜ける・古い。 雛形をコピーして使い回すうちに、相談窓口の案内が古い版のままになったり、書き換えの途中で段落ごと消えたりします。指定紛争解決機関の連絡先は変わることがあり、日本損害保険協会のそんぽADRセンターは、2025年6月30日以降、電話番号を全国共通の番号に一本化しています。

(c)金額と条文の写し間違い。 5番目で支払システムの値を手で写すと、桁や項目の取り違えが起きます。 3番目で貼る条文が、契約の始期に効いている版の約款ではなく、新しい版の約款になっていることもあります。

(d)書きぶりが担当者ごとに違う。 同じ「経年劣化による一部不払」でも、担当者によって説明の長さも順序も違います。契約者からの再照会や苦情の多くは、結論そのものより、説明が分からないことから始まります。

  1. 【人】 支払担当が査定を終え、支払システムの結論・適用条項・認定事実・算定の内訳を確定する
  2. 【自動】 確定をきっかけに、結論が不払か一部支払の事案を取り出す
  3. 【自動】 対象外の事案(解除・不正請求の疑い・訴訟中など)を規則で外し、担当者に戻す
  4. 【自動】 契約の始期に効いている版の約款から、適用条項の条文を取り出す
  5. 【自動】 Claude API が、認定事実と条項から理由の本文を書き、各段落がどの事実とどの条項に対応するかを返す
  6. 【自動】 本文に、条文・金額・算定の表・定型文・相談窓口の案内をプログラムが差し込み、通知文を組み立てる
  7. 【自動】 定型文の一致、条項番号と金額の一致、禁止の言い回し、案内の有無を規則で検査する
  8. 【人】 支払担当が、理由の本文が査定の判断と合っているかを確かめて直す
  9. 【人】 課長が、検査の結果と本文を見て承認する
  10. 【人/自動】 承認された通知文を送り、送付した版を残す

7番目が、この設計の分かれ目です。 検査に通らない通知文は、支払担当の画面に出る前に止めます。 定型文の抜けや金額の食い違いは、人が見つけるものではなく、機械が見つけて直させるものにします。

8番目で支払担当が見るのは、理由の本文だけです。 条文も金額も案内も、差し込みと検査で確かめ済みです。人の時間を、説明が査定の判断を正しく伝えているかという一点に集めます。

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

構成図
支払システム(結論・適用条項・認定事実・算定の内訳)
   │  支払担当が査定を確定
   ▼【トリガー】確定の記録
Python(社内のサーバー)
   ├──▶ 不払・一部支払の取り出し、対象外の事案の除外
   ├──▶ 契約の始期の版の約款から条文を取り出す
   ▼
Claude API ── 構造化出力でJSON
   │   ① 理由の本文(段落ごと)
   │   ② 各段落が根拠にした認定事実と条項
   ▼
Python ── 条文・金額・算定の表・定型文・相談窓口の案内を差し込む
   │       定型文の一致、条項と金額の一致、禁止の言い回しを検査
   ▼
【支払担当が本文を確かめる → 課長が承認】
   ▼
郵送・契約者ページで送付(送付した版を保存)
役割想定する製品代替候補
処理Claude API(不払・一部支払の理由の本文の作成。構造化出力)OpenAI API、Gemini API
連携Python(取り出し、条文と定型文の差し込み、検査、組み立て)Power Automate、n8n
保管社内の文書管理(定型文のマスタ、送付した版、ログ)SharePoint、Box
査定の記録既存の支払システム各社の支払システム

支払システムと約款のデータベースは、新しく足すものではありません。 この構成はどちらも読むだけで、査定の記録を書き換えません。 新しく作るのは、定型文のマスタです。冒頭のあいさつ、不払の通知の決まり文句、再査定の申し出の方法、社内の相談窓口、指定紛争解決機関の案内を、版と有効期間付きで1か所にまとめます。

基準の土台は、金融庁の「保険会社向けの総合的な監督指針」です。 保険金等支払管理態勢の着眼点では、不払いとなる場合について、約款等の根拠条文の記載を含め不払いの理由となる説明が、顧客に対して丁寧かつ分かりやすいものとなっているかが挙げられています。顧客の問い合わせに応じて保険金等の算定根拠を丁寧かつ分かりやすく説明しているかも挙げられています。一部支払の算定の表は、ここに応えるためのものです。

事後の検証についても書かれています。 同じ着眼点では、不払いの理由を顧客に対して説明するためのモデル文書を、苦情・問い合わせ等を通じて把握した課題を踏まえて見直し・改善する態勢と、実際に顧客に送付された不払通知について、当該内容が適切であったかどうかを検証する態勢が挙げられています。定型文のマスタと送付した版の保存は、この検証を回すための仕組みです。

相談窓口の案内の土台は、日本損害保険協会のページです。 そんぽADRセンターは、保険業法に基づく指定紛争解決機関として、苦情解決手続と、紛争解決手続(和解案の提示等)を行うとされ、自賠責保険の保険金の支払等に関するものは自賠責保険・共済紛争処理機構が所管とされています。商品によって案内する機関が変わるので、案内の定型文は商品の区分で切り替えます。

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

Step1

処理の起点を決める

支払担当が支払システムで査定を「確定」にしたことを起点にします。 確定の記録を10分おきに読み、結論が不払か一部支払のものだけを取り出します。 支払の通知は従来の仕組みのまま動かし、この構成は通らせません。

確定より前には動かしません。 査定の途中で通知文を作ると、認定事実が追加されたときに本文と記録が食い違います。確定の後に査定が覆ったときは、作った下書きを破棄し、もう一度確定したときに作り直します。

1件ずつ動かし、同じ事案で二度確定されたときは、前の下書きを残したまま新しい版を作ります。 支払担当がどちらを使ったかを、後から追えるようにするためです。

月末や大きな自然災害の後は、確定が一度に増えます。 台風の後の風災の事案のように、同じ種類の不払・一部支払が数日で数百件確定することがあります。そのときも1件ずつの処理は変えず、承認の画面に事故の種類で並べて出します。 同じ種類の事案を続けて見ると、課長は本文の書きぶりのばらつきに気づきやすくなります。

Step2

入力データを集める

データ中身取得元
査定の記録結論(不払/一部支払)、適用条項の番号、認定した事実(項目ごと)、支払担当の判断のメモ支払システム
算定の内訳請求額、認定損害額、免責金額、減額の項目と金額、支払額支払システム
契約の情報商品、約款の版、保険期間、補償の種類契約管理システム
約款の条文契約の始期に効いている版の、適用条項の原文約款のデータベース
定型文のマスタ冒頭、結び、再査定の申し出、社内の相談窓口、指定紛争解決機関の案内(商品の区分ごと)社内の文書管理
書き方の決まり使わない言い回し、敬語の決まり、平易な言い換えの例支払管理部の文書

質を決めるのは、認定した事実が項目に分かれていることです。 「現地調査の結果、屋根材の腐食が認められた」「腐食は事故日より前から生じていたと修理業者が述べた」のように、1項目1事実で記録されていれば、本文の各段落をどの事実に結びつけたかを確かめられます。

支払担当の判断のメモも渡しますが、本文の材料にはさせません。 メモには「契約者は電話で納得していない様子」「修理業者の説明に一部疑問あり」といった、契約者に伝える前提で書かれていない内容が入ります。渡すのは、どの事実を重く見て判断したかの順序を本文に反映させるためで、メモの文言を本文に写すことは指示で禁じます。 メモに疑いを示す語があれば、前処理で対象外の事案かどうかを確かめ直します。

Claude に渡すのは、査定の記録・条文・書き方の決まりまでです。 算定の内訳と定型文は渡しません。渡すと、本文の中で金額を書き、窓口の名前を言い換えて書きます。 それらは後で差し込むので、本文には要りません。

Step3

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

取るものどこから何に使うか
結論・適用条項・認定事実支払システムの査定の記録本文の材料
算定の内訳支払システムの算定の記録算定の表の差し込み。AIには渡さない
約款の版契約管理システムの契約の情報条文を取り出す版を決める
条文約款のデータベース(版と条項番号で引く)本文の材料と、条文の差し込み
定型文定型文のマスタ(商品の区分と有効期間で引く)差し込み。AIには渡さない

条文は、契約の始期に効いている版から取ります。 約款は改定されるので、同じ条項番号でも版によって文言が違います。新しい版の条文を貼ると、契約者の手元の約款と通知文が食い違います。 版の特定は、Claude ではなくプログラムが行います。

定型文は、送付する日に有効な版を引きます。 指定紛争解決機関の連絡先や社内の窓口は、送る時点で正しいことが要ります。 条文が契約の始期で決まるのとは、基準の日が違います。下書きを作った日と承認して送る日がずれたときは、送る直前に定型文の版をもう一度引き直し、変わっていれば組み立て直します。

条文が長い条項は、該当する項だけを取り出します。 1つの条に十を超える項や号がある免責の条項では、条全体を貼ると契約者はどこが自分に当たるのか分かりません。査定の記録の適用条項を項・号の単位まで記録しておき、その単位で原文を取り出します。

Step4

AIへ渡す前に整形する

  1. 対象外の事案を外す … 告知義務違反・重大事由による解除、不正請求の疑いで調査中、訴訟・調停中、弁護士が代理人の事案は、この構成を通さずに担当者に戻します
  2. 約款の版の特定 … 契約の始期と商品から、効いている約款の版を決めます
  3. 条文の取り出し … 適用条項の番号で条文の原文を取り出します。番号が約款に無ければ、Claude を呼ばずに担当者に戻します
  4. 認定事実の並べ替え … 時系列か、判断に効いた順かを、査定の記録の項目の順序のまま渡します
  5. 個人を特定する情報を外す … 契約者名・住所・証券番号・口座は渡しません。事故の場所は市区町村までにします
  6. 相手方の情報の扱い … 対物の事案では、相手方の氏名や車両の番号が認定事実に書かれていることがあります。相手方は「相手方」と置き換えて渡します

1番目を最初に置くのは、誤って送ったときの重さが違うからです。 解除や不正請求の疑いの事案では、説明の一言が法的な争いの材料になります。 文書の作りが同じでも、この構成の対象から最初に外します。

Step5

AIに処理させる

させるのは、認定事実と適用条項をつなげて、なぜその結論になったかを契約者に分かる言葉で書き、各段落の根拠を示すことだけです。

本文の部品書く中身
結論の一文不払か一部支払か。金額は書かず、差し込みの印を置く
事実の段落査定で認めた事実を、契約者に分かる言葉で並べる
当てはめの段落その事実が、どの条項のどの部分に当たるかを書く
一部支払の説明減額の項目ごとに、なぜ減額したかを書く。金額は差し込みの印
させないこと理由
支払うかどうかの判断と、結論の変更査定の結論のまま書く
査定の記録に無い事実や理由の追加契約者が反論できない理由が生まれる
条文の書き写し・要約の差し替え条文はプログラムが原文を差し込む。本文では言い換えだけ
金額・日付・電話番号・窓口名の記載差し込みの印を置き、プログラムが入れる
契約者を責める・疑う言い回し不正の疑いの事案は対象外。言い回しの決まりに従う

2行目がいちばん起きやすい失敗です。 「経年劣化による腐食」という認定事実から、Claude は「定期的なメンテナンスが行われていなかったため」と理由を足したがります。記録に無い理由は、契約者にとって初めて聞く非難になり、それが苦情の始まりになります。

Step6

指示内容を固定する

あなたは損害保険会社の保険金サービス部で、保険金を支払えない、または一部だけ支払う
理由を契約者に説明する通知文の本文を書く担当です。結論は査定で決まっています。

【書くもの】
- conclusion ……結論の一文。不払か一部支払かを書く
- facts ……査定で認めた事実の段落
- application ……その事実が、どの条項のどの部分に当たるかの段落
- reductions ……一部支払の場合、減額の項目ごとの説明

【厳守事項】
- 【査定の記録】の結論を変えないでください。
- 【査定の記録】の認定事実に無い事実や理由を書かないでください。
  「〜のため」「〜が原因で」など、記録に無い因果関係を足さないでください。
- 各段落の fact_ids と clause_ids に、根拠にした認定事実の番号と条項番号を入れてください。
  根拠を示せない段落は書かないでください。
- 条文を書き写したり要約したりしないでください。条文は別に掲載します。
  本文では「約款の第◯条の『〜』という定めに当たります」のように、該当する語句だけを引いてください。
  引く語句は、【条文】の中の文字列をそのまま使ってください。
- 金額は書かないでください。金額を示す箇所には {{amount:項目名}} と書いてください。
- 日付、電話番号、窓口の名前、不服の申し出の方法を書かないでください。別に掲載します。
- 契約者を責める、疑う、反論を封じる言い回しを使わないでください。
  【書き方の決まり】の使わない言い回しに従ってください。
- 専門用語は、【書き方の決まり】の言い換えの例に沿って、契約者に分かる言葉にしてください。
  言い換えたときは、もとの約款の語句も括弧で残してください。
- 【支払担当の判断のメモ】は、どの事実を先に説明するかの順序を決めるためだけに使い、
  メモの文言や、メモにだけ書かれた事柄を本文に書かないでください。

【結論】{decision}
【支払担当の判断のメモ】{adjuster_note}
【査定の記録(認定事実は番号付き)】{findings}
【条文(条項番号付き)】{clauses}
【一部支払の減額の項目名】{reduction_items}
【書き方の決まり】{style_rules}

「記録に無い因果関係を足さない」を具体的な語で書かないと、理由が増えます。 「足さないでください」だけでは、Claude は因果関係を足すことを事実の追加だと思いません。「〜のため」「〜が原因で」と、足す形そのものを名指しします。

「言い換えたときは、もとの約款の語句も括弧で残す」のは、言い換えが条文から離れたときに気づくためです。 支払担当は括弧の中の語句と言い換えを見比べるだけで、言い換えが条文の範囲を超えていないかを確かめられます。

Step7

出力形式を固定する

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

{
  "claim_ref": "",
  "decision": "denied | partial",
  "conclusion": "",
  "paragraphs": [
    {
      "part": "facts | application | reductions",
      "text": "",
      "fact_ids": [],
      "clause_ids": [],
      "quoted_terms": []
    }
  ],
  "placeholders": []
}

1つ目の理由は、根拠を機械で照合できることです。 Python が fact_ids と clause_ids を査定の記録と突き合わせ、記録に無い番号を根拠にした段落に印を付けます。 quoted_terms の語句が条文の中に一字一句あるかも確かめます。

2つ目は、差し込みの印を検査できることです。 placeholders に挙がった {{amount:項目名}} が、算定の内訳の項目名とすべて対応するかを見ます。対応しない印が1つでもあれば、通知文を組み立てません。

組み立てた後の検査は、次の表のとおりです。

検査内容通らないとき
定型文の一致冒頭・結び・再査定の申し出・社内の窓口・指定紛争解決機関の案内が、有効な版と一字一句同じか組み立てをやり直す
案内の区分商品の区分に合った紛争解決機関の案内か(自賠責の事案は別の機関)止めて担当者へ
条項番号本文と掲載の条文の番号が、査定の記録の適用条項と同じか止めて担当者へ
金額差し込んだ金額が算定の内訳と同じか。本文に数字が直書きされていないか止めて担当者へ
言い回し使わない言い回しの一覧に当たる語がないか印を付けて担当者へ
根拠根拠の番号が記録にあるか、引いた語句が条文にあるか印を付けて担当者へ

3つ目は、検査の結果を承認の画面に並べられることです。 課長の画面には、本文の横に検査の結果の一覧が出ます。すべて通っていれば、課長は本文を読むことだけに時間を使えます。

Step8

システムへ連携する

つなぎ先方式内容
支払システム確定の記録を読む結論・適用条項・認定事実・算定の内訳
契約管理システム証券番号で読む商品と約款の版
約款のデータベース版と条項番号で読む条文の原文
Claude APIMessages API の呼び出し本文の作成。構造化出力
定型文のマスタ商品の区分と送付日で読む差し込む定型文
承認の画面社内の文書管理下書き、検査の結果、承認の記録

支払システムには書き込みません。 通知文の送付の記録は、承認の後に従来どおりの手順で付けます。この構成が支払システムに書けるようにすると、下書きの段階で送付済みの印が付く事故が起き得ます。

送付は、承認の後に既存の送付の仕組みで行います。 郵送の印刷と、契約者ページへの掲載の両方とも、課長の承認の記録がない通知文は流れないようにします。

Step9

人が確認する

  1. 検査で止まったものを直す … 定型文の区分、条項番号、金額の食い違いは、多くが査定の記録の入力の誤りです。 記録を直して確定し直します
  2. 本文が査定の判断を正しく伝えているかを見る … 支払担当が、印の付いた段落と、言い換えと括弧の約款の語句を見比べます
  3. 契約者の事情に合わせて書き足す … 電話でのやり取りで約束したこと、先に伝えた説明との関係などを、支払担当が書き足します
  4. 課長が承認する … 検査の結果を確かめ、本文を読んで承認します

2番目を省かないでください。 検査は、定型文と数字と番号が合っているかしか見られません。本文が査定の判断を正しく伝えているかは、判断した本人にしか分かりません。

課長は、支払担当が直した箇所を色分けで見ます。 下書きのままの段落と、担当者が書き足した段落が分かれていれば、課長が重点的に読むべきは書き足した段落です。 書き足した段落は検査の根拠の照合を通っていないからです。

目標は、支払担当の確認を1件10分、課長の承認を5分にすることです。 以前の40分のうち、雛形の書き入れ・条文の貼り付け・金額の写しが無くなり、理由の段落は書く仕事から直す仕事に変わります。

Step10

例外に対処する

起きること対応
解除・不正請求の疑い・訴訟中の事案この構成を通さない。 担当者が従来どおり書き、法務部門が確かめる
適用条項の番号が約款に無いClaude を呼ばずに担当者へ。査定の記録の入力の誤りを疑う
自賠責の事案が混ざった案内の区分を切り替える。区分が決まらなければ止める
認定事実が自由記述の1項目だけ根拠の照合ができないため、印を付けて担当者に書いてもらう
本文に数字が直書きされた組み立てを止めて再実行。2回続けば担当者へ
定型文のマスタに有効な版が無い全件を止めて、支払管理部に知らせる
応答がスキーマに合わない1回だけ再実行し、だめなら「下書きなし」で担当者へ
拒否(stop_reason: "refusal")や途中で切れた応答スキーマに合わないことがあるため、同じく再実行の後、人へ
確定の後に査定が覆った下書きを破棄し、再確定のときに作り直す

6行目だけは、1件ではなく全件を止めます。 定型文に有効な版が無いのは、マスタの更新の手違いで、その日に作るすべての通知文に同じ抜けが入ります。 1件ずつ担当者に回すより、元を直すほうが早く確実です。

Step11

記録を残す

  • 査定の記録・条文・書き方の決まりのうち、Claude に渡した入力の全文
  • Claude が返したJSONの全文
  • 組み立てた通知文と、使った定型文の版と約款の版
  • 検査の結果(通ったもの、止まったもの、その理由)
  • 支払担当が直した後の本文と、下書きとの差分
  • 承認者と承認日時、送付日と送付の方法

3つ目の版の記録は、送った後の検証のために要ります。 監督指針の着眼点にある、実際に送付された不払通知の内容が適切であったかの検証は、どの版の定型文と約款で作ったかが分からなければ始められません。

5つ目の差分は、モデル文書を見直す材料になります。 支払担当がどの部品のどの言い回しを直したかを集めると、書き方の決まりに足すべき言い換えと、使わない言い回しが見えてきます。 苦情の記録と並べて見ると、なお分かりやすくなります。

保存の期間は、通知文そのものと同じ扱いにします。 入力の全文には事故と損害の詳細が含まれるため、通知文の保存の決まりを超えて長く持たず、閲覧できる人も支払管理部と監査の担当に限ります。

04実装レベルの3段階

最小構成:伏せた認定事実と条文をAIサービスの画面に貼り、本文を書かせる / 1件ごとの理由の本文
半自動化:上記+Python で支払システムから記録を取り、API を呼び、雛形に本文を貼るところまで / 本文の作成と雛形への貼り付け
本格構成:上記+約款の版の特定、条文・金額・定型文の差し込み、検査、承認の画面、版の保存 / 通知文の組み立てと送付前の検査まで

最小構成では、条文・金額・定型文は従来どおり手で入れます。 本文がどこまで書けるかを確かめる段階です。 半自動化で、1件40分が25分程度になります。 本文の下書きは出ますが、条文の貼り付け・金額の写し・課長の照合が残ります。本格構成で15分になり、この段階が本記事の想定です。 差が大きいのは、課長の目の照合と担当者の写し作業が、差し込みと検査に置き換わるからです。 段階を飛ばさないでください。 半自動化で1か月回すと、支払担当が本文のどこを直すかが見えます。それを書き方の決まりに足してから、検査を組みます。

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

前提値(モデル条件)
対象人数
12 名
月間件数
300 件
1件あたり現在時間
40 分
1件あたり導入後時間
15 分
現在  300件 × 40分 ÷ 60 = 200 時間/月
導入後 300件 × 15分 ÷ 60 = 75 時間/月
月間削減時間
125h
削減率
63%
年間削減時間
1,500h
年間金額換算(時間単価3,500円)
525万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

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

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

AI活用について相談する

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

向いている
  1. 火災保険・自動車保険の車両や物損・傷害保険などの保険金請求を月に数千件受け付け、そのうち不払や一部支払となる数百件の通知文を支払担当が書いている損害保険会社・少額短期保険業者・共済。査定の結論・適用条項・認定した事実・算定の内訳が支払システムに項目として残っている場合。不払通知の書きぶりが担当者ごとに違い、社内の検証で定型文や相談窓口の案内の抜けが指摘されている場合。
向いていない
  1. 不払・一部支払の通知が月に数十件で、書く時間そのものが小さい場合。査定の記録が自由記述のメモだけで、結論・適用条項・認定した事実を項目として取り出せない場合。支払うかどうかの判断を機械に任せたい場合(この構成は判断を代替しません)。告知義務違反や重大事由による解除、不正請求の疑いで調査中の事案など、法務部門や弁護士の判断を経る事案(この構成の対象から外します)。

07最小構成で試す方法

  1. 先月送った不払・一部支払の通知文から10件を選ぶ(その後に苦情や再照会があったものを入れる)
  2. その10件の査定の記録から、結論・適用条項・認定事実を、契約者名や証券番号を伏せて書き出す
  3. 法人として契約しているAIサービスの画面に、認定事実と条文を貼る
  4. 「この認定事実と条文だけを使って、保険金を支払えない(または一部だけ支払う)理由を契約者に分かる言葉で書いてください。記録に無い理由や因果関係を足さないでください。金額と連絡先は書かないでください。各段落に、根拠にした認定事実の番号を付けてください」と指示する
  5. 出てきた本文を、実際に送った通知文と、その後の苦情の内容と並べて比べる

比べるときに見るのは、苦情の種になった箇所です。 実際の通知文で契約者が分からないと言った箇所が、下書きではどう書かれているかを見ます。

出てきた内容判断
認定事実だけで分かる説明になったPython での連携に進む
記録に無い理由が足された指示の書き方で直る。構成は有効
認定事実が少なく、説明にならなかった査定の記録の書き方が先。 AIの問題ではない

3行目が出ることは珍しくありません。 失敗ではなく、通知文を書くたびに支払担当が記憶で補っていたことが分かったということです。認定事実を1項目1事実で残す書き方を支払管理部で決め、同じ10件で試し直してください。

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

問題対策
記録に無い理由や因果関係が足される足す形を名指しで禁じる。 根拠の番号を照合する
言い換えが条文の範囲を超えるもとの約款の語句を括弧で残させ、見比べる
本文に金額や電話番号が書かれる差し込みの印を置かせ、直書きを検査で止める
新しい版の約款の条文が貼られる版は契約の始期でプログラムが決める
古い定型文が使われる定型文は送付日に有効な版をマスタから引く
自賠責の事案に別の機関を案内する商品の区分で案内を切り替え、決まらなければ止める
認定事実が自由記述の1項目だけ査定の記録を1項目1事実で残す決まりを作る
解除や不正の疑いの事案が混ざる最初の規則で外す
支払担当が本文を読まずに回す印の付いた段落を先頭に出し、承認の画面で見せる
定型文のマスタの更新の手違い有効な版が無ければ全件を止める

上の2行が、この構成の失敗のほとんどです。 どちらも、Claude が説明を「分かりやすく」しようとして、記録や条文から離れることから起きます。分かりやすさと正確さがぶつかったときは、根拠の番号と括弧の約款の語句で、正確さの側に引き戻します。

真ん中の4行は、AIの外で起きる失敗です。 約款の版、定型文の版、案内の区分は、人が雛形をコピーしていた時代から起きていた誤りで、機械にすれば止められます。 この構成の効果の半分は、ここから来ます。

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

この構成で扱うデータ: 事故の状況、損害の内容、傷害の事案では通院や入院の情報、対物の事案では相手方の情報です。契約者名・住所・証券番号・口座は、AIに渡しません。

  1. 個人を特定する情報を外へ出さない … 渡すのは認定事実と条文だけで、契約者名や証券番号は差し込みの段階でプログラムが入れます。 傷害の事案の通院・入院の情報は、認定事実の中に必要な範囲で残ります。センシティブ情報を扱うことを前提に、社内の取扱い基準に沿って渡す範囲を決めます
  2. APIのデータの扱いを確かめておく … Claude API の公式の説明では、会話の内容は既定では保持されない一方、Covered Models に指定されたモデルは30日の保持が必要とされ、Files API と Batch 処理はゼロデータ保持(ZDR)の対象外です。この構成は Messages API で直接渡し、Files API と Batch 処理を使いません
  3. 支払の判断をAIに寄せない … この構成は、決まった結論を説明するだけです。下書きを読んだ支払担当が、文章に引っぱられて結論を変えることのないよう、結論は査定の確定の後にしか下書きを作りません
  4. 送付を自動にしない … 不払の通知は、契約者にとって重い文書です。課長の承認の記録が無いものは送らないようにします
  5. 送った通知文を検証する … 監督指針は、送付された不払通知の内容が適切であったかを検証する態勢を挙げています。送付した版と、直した差分と、その後の苦情を並べて、定型文と書き方の決まりを見直します
  6. 対象外の事案の線引きを文書にする … 解除・不正請求の疑い・訴訟中の事案を外す規則は、支払管理部と法務部門で決め、規則の変更も記録します

誤りが起きた場合のリスクは、記録に無い理由が契約者に伝わることと、相談窓口の案内が抜ける・誤ることの2つです。 前者は根拠の照合と支払担当の確認で、後者は定型文の差し込みと検査で防ぎます。どちらも、AIに書かせる範囲を本文に限ったことで、確かめられるようになっています。

10まず何から始めるか

1週目:定型文を1か所に集める

通知文の雛形を全部集め、冒頭・結び・再査定の申し出・社内の窓口・指定紛争解決機関の案内を取り出します。版がいくつ出回っているかを数えます。 複数あれば、それ自体が第3章の(b)の原因です。

2週目:10件で試す

先月の通知文から、苦情や再照会のあったものを含めて10件を選び、伏せた認定事実と条文で本文を書かせます。記録に無い理由が足されていないかを最優先で見ます。

3週目:査定の記録の書き方を決める

試した結果から、認定事実を1項目1事実で残す書き方を支払管理部で決めます。使わない言い回しと、専門用語の言い換えの例もあわせて決めます。

4週目:支払システムから本文までをつなぐ

Python で確定の記録を読み、対象外の事案を外し、条文を取り出して Claude API を呼び、本文を雛形に貼るところまで作ります。この時点では、差し込みと検査は人が行います。

2か月目: 定型文のマスタと約款の版の特定、差し込みと検査を足し、承認の画面を作ります。3か月目以降: 送った通知文の差分と苦情を毎月並べ、書き方の決まりと定型文を見直します。検査で止まる件数が、査定の記録の入力の誤りだけになった時点で、この構成は完成です。


11関連ユースケース

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

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

技術仕様確認日:2026-10-15/最終更新:2026-10-15
確認した内容情報源確認日
保険金等支払管理態勢の着眼点として、不払いとなる場合に約款等の根拠条文の記載を含め不払いの理由となる説明が丁寧かつ分かりやすいものとなっているか、顧客の問い合わせに応じて算定根拠を丁寧かつ分かりやすく説明しているか、不払いの理由を説明するモデル文書を見直し・改善する態勢と、実際に送付された不払通知の内容の適切さを検証する態勢があるか、が挙げられていること。高度な法的判断を要するものは法務部門等の意見を聞く態勢が求められること金融庁: 保険会社向けの総合的な監督指針(令和8年10月)II-4-4-32026-10-15
そんぽADRセンターが保険業法に基づく指定紛争解決機関として苦情解決手続と紛争解決手続(和解案の提示等)を行うこと。自賠責保険の保険金の支払等に関するものは自賠責保険・共済紛争処理機構が所管とされること。2025年6月30日以降、電話番号を全国共通の番号に一本化したこと日本損害保険協会: 相談対応、苦情・紛争の解決(そんぽADRセンター)2026-10-15
構造化出力を output_config.format に type: "json_schema" で指定すること。拒否や max_tokens で切れた応答がスキーマに合わないことがあることClaude Docs: Structured outputs2026-10-15
会話の内容が既定では保持されないこと。Covered Models は30日の保持が必要でZDRの対象外であること。Files API と Batch 処理がZDRの対象外であることClaude Docs: API and data retention2026-10-15

支払の可否の判断と、通知文の最終的な内容は、支払担当と支払管理部が決めてください。 本記事は上記の公開情報で確認できた範囲だけを扱っています。相談窓口の連絡先は、送付の時点の公式の案内で確かめてください。

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

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

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

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