人数はそのままで請求の処理が速くなり、誤った支払いも減ります。監督当局にも顧客にも、健康情報は自社のシステムの中だけにあると説明できます。
保険会社 · 12 / 12
保険金請求・引受審査向けプライベートLLM
保険金請求の書類、治療歴、保険申込書を自社のシステム上で読み、担当者が早く判断できるよう要約します。顧客の健康情報はどこにも出ていきません。
保険会社 「請求1件ごとに診断書、領収書、治療記録が何十ページもあって、担当者が全部自分で読んでいる。AIに手伝わせたくても、顧客の健康情報だから外には出せない」
よくある課題
医療保険の請求1件には、診断書、何枚もの領収書、画像でスキャンされた治療記録が付いてきます。支払担当者はすべてを読み、約款の条件と照らし合わせ、要約を入力してから承認します。請求が集中する時期には仕事が何週間分もたまり、顧客から「まだ順番は来ないのか」と毎日電話がかかってきます。引受審査の側でも、申込書と健診結果を同じように読んでいます。
どの書類にも健康情報が含まれています。健康情報はタイの個人情報保護法(PDPA)上のセンシティブデータで、保険業の監督当局の規制も受けるため、外部のツールに読ませることはできません。そのためチームは自分たちで読み続けています。
解決の方法
言語モデルを自社サーバー、または会社が管理するクラウドアカウントに導入し、いま使っている保険金支払システムと契約管理システムにつなぎます。請求が届くと、システムがスキャン画像を含む全ページを読み、何の治療にいくらかかったかをその契約の補償内容と照らし合わせて1ページにまとめます。条件外の項目や、まだ届いていない書類も指摘します。
引受審査の側では、申込書と健診結果から健康歴を要約し、医師に追加で確認すべき点も示します。権限は役割に従い、健康情報はその案件の担当者だけが閲覧できます。閲覧はすべて監査ログに残り、DPO(データ保護責任者)とコンプライアンス部門が確認できます。外部APIは呼び出しません。
要約と指摘まではシステムが行い、請求の承認・否認と、引き受けるかどうかの判断は権限を持つ社員が行います。システムが異常として示した案件は、必ず調査チームに回り、人が先に確認します。
仕組みの流れ
- LINE OAと支店から届く請求書類
- 申込書と健診結果
- システム上の約款条件
- 過去の請求履歴
- スキャン画像を含めて書類を読む
- 補償内容と照合
- 要約し追加確認が必要な点を指摘
- すべてのアクセスを記録
- 支払担当者への1ページ要約
- 引受担当者への要約
- 異常案件は調査チームへ
- DPOとコンプライアンス部門向け監査ログ
導入前と導入後
導入で得られるもの
- 01
スキャンされた診断書、領収書、治療記録を読み、請求内容を1ページに要約する、自社システム内のモデル
- 02
請求項目を約款の条件と給付表に照らし、補償対象外の項目や不足書類を指摘
- 03
申込書と健診結果から健康歴を要約し、医師に追加で確認すべき点も示す引受審査アシスタント
- 04
過去に異常が見つかった案件と似たパターンの請求を見つけ、人が先に確認するよう調査チームへ回付
- 05
役割に応じた権限:健康情報はその案件の担当者だけが閲覧でき、PDPAに沿ってすべてのアクセスを監査ログに記録
立場ごとのメリット
自社のインフラに導入し、保険金支払システムと契約管理システムには当初、読み取り専用で接続します。権限はActive Directoryに従い、すべてのアクセスを監査ログに記録します。設計はDPOと一緒に行います。
支払担当者は領収書を1枚ずつ読むことも、要約を自分で入力することもなくなり、判断の分かれる案件にじっくり向き合えます。
向いている業種
お使いのシステムと連携
開発プロセス
- 1
ヒアリング
要件・ユーザー・成功指標を定義し、着手前に範囲と価格を確定。
- 2
設計
UXとアーキテクチャを設計。プロトタイプ承認後に開発へ。
- 3
開発
AIで加速したスプリント。毎週デモ、シニアがレビュー。
- 4
テスト
合意した範囲に対してQA・セキュリティ・性能を検証。
- 5
公開・保守
本番リリース、チームトレーニング、月次保守プラン。