2万人が「使える」生成AIをどう育てるか？〜損保ジャパン2万人の社員が使う生成AI機能を育てた、プロンプト改善とUX設計の軌跡〜

© 2024 Sompo Japan Insurance Inc. All Rights Reserved. 2万人が「使える」生成AIをどう育てるか？
〜損保ジャパン2万人の社員が使う生成AI機能を育てた、プロンプト改善とUX設計の軌跡〜 SOMPOホールディングス株式会社 2026年2月20日デジタルデータ戦略部

© 2024 Sompo Japan Insurance Inc. All Rights Reserved. 1
小林勇喜 (WEBアプリケーションエンジニア) 物流、自動車、ゲーム業界等において、新規サービスの立ち上げや既存システムの大規模リプレイスなどに従事。2023年4月より現職。チーフエンジニアとして、保険金支払業務の顧客コミュニケーション領域改善プロジェクトをリードしている。自己紹介藤野智彦(インフラエンジニア) 製造業向け基幹システム開発に従事。その後、機械学習プラットフォームのバックエンド開発やインフラ構築などに従事。2022年1月より現職。インフラエンジニアとして開発環境構築やSRE領域を担当。最近は生成AIの機能開発にも携わっている。 SOMPO Digital Lab（ＳＯＭＰＯホールディングス株式会社）

本日お伝えしたいことビジネスサイドとのパートナーシップ

目次 1 2 3 プロジェクト概要生成AIを用いた要約機能の実装要約機能の導入効果 4 プロンプト構築における課題と解決策 5 プロンプトエンジニアリングと品質評価 6 精度とコストのトレードオフ 7 課題ドリブンでの機能選定まとめ 8

1. プロジェクト概要 https://www.sompo-japan.jp/company/initiatives/sjr/

1. プロジェクト概要

1. プロジェクト概要プロジェクトの現在地今後 LINEツールの移行を完了。基幹システム連携を実現し、全国の拠点で稼働中。コミュニケーションツールの2点目として、メールシステムの統合(API)を間も無く展開予定。ユーザーの声やA/Bテストを通してUIや機能のブラッシュアップを継続中以降もシステム連携を計画中。

2. 課題ドリブンでの機能選定生成AI機能を実装するにあたって・・・

2. 課題ドリブンでの機能選定技術ドリブン課題ドリブン AIなど新技術業務フローへの無理な適用現場ニーズとの乖離現場で定着せず、使われない現場の具体的な課題・非効率を特定問題解決の手段としてAIを適用業務フローに自然に組み込む利便性を実感し、定着・生産性改善

2. 課題ドリブンでの機能選定 https://www.sompo-hd.com/-/media/hd/files/news/2025/20251226_1.pdf

2. 課題ドリブンでの機能選定これまでの業務フロー担当者による手動対応お客さま 1. メッセージ内容を要約 2. 対象の事故を検索 3. 経緯として登録 LINE送受信 LINE送受信基幹システム・人によって粒度が異なる。・時間がかかる。・ツールの切替が発生。・改めて事故を検索、登録の手間が発生。

2. 課題ドリブンでの機能選定改善案担当者による対応お客さま基幹システム 1. メッセージ内容を AI要約 2. 要約結果を確認 3. 経緯として登録(API) LINE送受信 LINE送受信

3. 生成AIを用いた要約機能の実装 Generated by Nano Banana Pro

3. 生成AIを用いた要約機能の実装 • ビジネス、開発が一体となったスクラム開発。 • 新オペレーションモデルを体現するモデル拠点にて先行導入。 • 全国へ展開し、施策の効果検証を実施。リリース(全国) リリース(モデル拠点) 開発Sprint フィードバック実業務利用での早期フィードバック全国利用での幅広いフィードバック • 全国展開へ向けた情報整理・システム改修。

4. 要約機能の導入効果引継ぎ・状況把握効率化経緯入力の効率化・品質向上業務管理の利便性向上 • 経緯入力内容が簡潔・標準化され、進捗の状況把握や担当者間の共有・引継ぎが容易になった。 • 基幹システムに連携しているため、経緯登録が早くなった。 • 経緯とともに行動予定を登録できるのが便利。特に、解決までに時間を要するケースとの親和性が高いと感じました。 (現場アンケート) • 一連の業務に要する時間が1/3に削減された。

4. 要約機能の導入効果ランニングコスト(After) モデル：Gemini2.5 Flash Light コスト：5,000円 / 特定月ランニングコスト(Before) モデル：Claude 3.5 Sonnet (Bedrock) コスト：63,000円 / 特定月

前半のまとめ AI機能の導入判断 • 技術ドリブンではなく、課題ドリブンで。 • AI活用機能は選択肢の一つ。まずは、業務の見直しができないかを検討。開発の進め方 • ビジネスと開発の一体化したチームでの開発は必須。 • 必ず短いスパンでのフィードバックループを回そう。効果 • AI要約と人による確認で、品質を担保しつつ業務効率化を実現できた。 • ユーザーの生の声を聞くことで新たな発見があった。

5. プロンプトの構築で直面した「要約タスクの課題」背景課題①：評価の属人化生成AIの出力結果は、ビジネス担当者の感覚（「なんとなく良い・悪い」）に依存しやすく、たとえ同じ出力でも品質基準が異なり、チーム全体で一貫した品質を保つことが困難になってしまう。背景課題②：コストのジレンマ全てのケースを人間が目視確認すると、膨大な時間とコストがかかってしまう。（生成AIを活用する意味、、）効率化を求めてAIを導入したのに、その品質確認に多大な工数がかかるという矛盾に直面する。解決策：評価の自動化「何をもって良しとするか」「何が業務として致命にならないか」を明確に定義し、ツールで自動採点（定量評価）できる仕組みを作りをする。ビジネス担当者は業務要件の観点に集中して評価をすることで、評価工数を削減しながら、客観的な品質を担保することが可能になる。

5. 自動化を阻む最大の壁：「共通言語」がない Before: 埋まらない溝 Action: 泥臭い翻訳作業感覚 vs 論理の衝突ビジネス担当者（感覚的）エンジニア（困惑）感覚を「評価ルール」に変換する徹底ヒアリング感覚のルール化（構造化）「なぜダメなのか？」「逆にOKな例は？」「どうなれば合格？」を問い続け、暗黙知を引き出す。「大事なこと」→必須項目の欠落と定義「失礼なケース」→断定表現の禁止と定義「実務上必要な観点が網羅されていない懸念がある」「お客様への配慮が欠けている懸念がある」「実務上必要なことを具体的に教え欲しい」「失礼なケースとは具体的になんですか？」

5. 自動化を阻む最大の壁：「共通言語」がない Before: 埋まらない溝 Action: 泥臭い翻訳作業感覚 vs 論理の衝突ビジネス担当者（感覚的）エンジニア（困惑）感覚を「評価ルール」に変換する徹底ヒアリング感覚のルール化（構造化）「なぜダメなのか？」「逆にOKな例は？」「どうなれば合格？」を問い続け、暗黙知を引き出す。「大事なこと」→必須項目の欠落と定義「失礼なケース」→断定表現の禁止と定義「実務上必要な観点が網羅されていない懸念がある」「お客様への配慮が欠けている懸念がある」「実務上必要なことを具体的に教え欲しい」「失礼なケースとは具体的になんですか？」「品質」という曖昧な基準を異なるドメイン知識を持つ方とどう共有するか？

5. 解決策：ビジネスと膝を突き合わせて言語化する評価基準を作る3つのステップ 1 3 【利用シーンの特定】〜誰が、何を決めるのか〜【合格ラインの決定】〜どこまでなら許せるか〜この要約を見て、誰が（担当者/システム）、どんな判断（振込/連絡/入力）をするのか？（例：担当者が「等級への影響があるか」を判断し、お客様へ案内する。）生成AIの出力結果が100点満点でなくとも、「業務が止まらない最低限のライン（許容範囲）」を決める。（例：日本語が多少不自然でも、「等級への影響あり/なし」の結論が正しければ合格。など）後続業務含め、業務判断を誤らせる「致命的なミス」は何か？（例：本当は等級が下がるのに、「下がらない」と嘘の情報が混ざること。） 2 【失敗リスクの抽出】〜何が起きると困るか〜目的利用者は様々な利用ケースがあるため、一言一句決まった「正解」を作ることが困難。そのため「その要約から業務が正しく回るか、業務上の致命がないか」を合格の基準（許容範囲）とする。評価基準を作る3つのステップ

具体的な策定手順（ワークショップ）ビジネスが5つの質問について話し合うことで、曖昧な「良し悪し」を明確な「評価ルール」に変換する。質問（問いかけ）ルールへの変換（評価軸）アウトプット Q1. 生成AIに出力された内容から、次になにを決めるか？情報の網羅性判断材料が揃っているか要約品質に関する評価軸 - 要点の網羅性（顧客の状況、要望、対応内容などの要点を押さえているか） Q2. 間違うとどのような実害が出るか？正確性・安全性嘘がないか、法令を守れているか業務適合性に関する評価軸・保険用語の適切な使用（専門用語の正確な使用）・保険金支払いの条件についての正確な記述 Q3. 最低限ないと困る情報は？必須項目絶対に落としてはいけない情報正確性・事実性に関する評価軸・重要な情報の欠落がないか（保険適用条件に関わる情報など） Q4. 必ず使う言葉・使ってはいけない言葉は？用語の正しさ社内用語・禁止ワードの遵守倫理・コンプライアンスに関する評価軸・差別的・偏見のある表現がないか・不適切な断定や約束がないか Q5. 元の情報に答えがない時はどうするか？嘘（ハルシネーション）対策正確性・事実性に関する評価軸・事実の歪曲がないか（事故状況、被害状況、対応内容など） 5. アウトプット：4つの「共通言語」

評定表 5. NG/許容ラインのすり合わせ言語化によって得られた成果 NG/許容ラインを明文化した効果点数付け自体が「なんとなく」にならない各点数の具体的な基準を定義したことで、評価者によるブレが大幅に減少 3点以下は「理由」と「改善案」を必須化なぜその点数か？を記載することで、ネクストアクションが明確になる評価→改善サイクルが止まらない「何を直せばいいか分からない」状態を解消し、継続的な改善が可能に

6. システムプロンプト構築・評価サイクル STEP1 初期定性レビュー（方向性の確認） STEP2 定量評価（自動評価による品質測定） STEP3 詳細定性評価（人の目による最終確認） STEP4 デリバリー（ユーザーへの展開） • 生成AIの出力で業務上許容できる範囲（評価軸）を洗い出す。 • 原案となるベースのシステムプロンプトを確定する。 • 評価用の検証データを50件-100件程度用意し、評価ツール（ AI TrustEval）でまとめて定量的に採点し、スコアの分布を確認する。 • 「合格点に達しているか」「致命的なミスがないか」を数値で把握する。 • 定量評価では測れない「業務上の違和感や致命」がないかを評価軸をもとに5段階で評価を行う。 • 1~3点のデータについては「評価理由」「改善点」を明文化し、システムプロンプトの修正・変更を行う。 • ユーザー受け入れテスト（UAT）を実施し、「生成AIの精度」と「UI観点」の最終確認をする。 • 今の品質を基準点（ベースライン）として本番環境への反映（デリバリー）を行う。

6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval） Pythonスクリプトの場合アプリにした理由ビジネスの端末によってはエンジニアしか実行できないビジネスが自主的に評価プロセスを回してほしかった結果がCSV/ログで見づらい直感的に結果を確認し、改善点を議論したかった初期開発段階では導入しづらい機能として盛り込むか判断する段階で使いたかった評価ツールを構築した理由

6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval）目的・100件程度の検証データで品質を定量計測・スコア分布から改善の方向性を特定ツールデータセット、システムプロンプトの管理、定量評価、結果の比較成果・一定数のまとまったデータ数で評価することにより、多様なユースケースの評価ができる・定量的な点数により「現状のシステムプロンプトが業務で使えるか」の判断の確度が上がる・評価は何度でも実行可能なため、同じ物差しで継続的に「比較評価」できる（例：モデル変更時の比較評価）

6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval）

各データケースの点数の平均値を表す総合スコア評価基準の記載 6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval）

インプットデータ毎に「なぜその点数なのか」「何が不足しているか」をAIが言語化・インプットデータ毎に「なぜその点数なのか」「何が不足しているか」をAIが点数化・言語化 6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval）

データセットの評価結果とプロンプトの内容から「プロンプト自体の改善提案」もする 6. LLM-as-a-Judge 実践のための定量評価ツール（AI TrustEval）

6. AI TrustEval 技術スタック Monorepo構成（UV Workspace） Frontend • Dash 3.2+ • Plotly • Mantine UI Evaluation • DeepEval • Gemini • GPT • Claude DevOps • Python 3.13+ • UV (高速) • Ruff / MyPy • pytest-asyncio • Docker ✓ 非同期処理対応 ✓ マルチプロバイダ対応 ✓ 型安全（Python 3.13+） ✓ CI/CD統合 Backend • FastAPI • PostgreSQL 17 • SQLAlchemy • Alembic • asyncpg

6. ガイドライン化による横展開目的ビジネスが自立して「プロンプトの構築・評価・改善」を回せるよう、方法・手順・Tipsを標準化したいプロンプトを構築する上で、属人的判断に依存せず、業務要件に的した評価軸や評価の自動化によって継続的なプロンプトの改善を実現したい

7. コスト×品質の意思決定 - トレードオフの無限ループを防ぐ方法ポイント先に「最低合格ライン」と「予算上限」を固定する両方を満たす領域だけを「採用」とする設計思想：トレードオフの解消「精度を上げればコストが上がる」「コストを下げれば精度が落ちる」という議論のループを防ぐため、品質下限とコスト上限という2つのガードレール（制約条件）を最初に合意する。この枠内に収まる解決策のみを採用候補に選択していく。

7. モデル選定とコスト戦略 - モデル選定の最適化 Phase 1：初期検証・プロンプト開発目的：実現可能性（フィジビリティ）の確認手段：最高性能モデル Phase 2：コスト最適化・本番適用目的：精度の維持 × コスト最小化成果： ROI（コスト対効果）成果：到達可能な最高精度の確立手段：軽量モデル

まとめビジネス成果 • 適切なプロンプトエンジニアリングと評価プロセスを経ることで、最新モデルでなくても実業務に耐えうる品質を出せる • シンプルなことから始めても効果は出る（人員規模による） • 結果として極めて高いROIを実現できた技術的アプローチ • 評価基準を作り「暗黙知の言語化」から始める • 評価プロセスを LLM-as-a-Judge で自動化する • ビジネスも「継続的な改善」と「評価プロセスを回せる環境」を作る

SOMPO Digital Labでは、一緒に事業課題に取り組んでいく仲間を募集しています。 We are hiring! https://sompo.io/ja/recruit アプリケーションエンジニアインフラエンジニア QAエンジニア • チーフエンジニア • AIエンジニア • アプリエンジニア • システムアーキテクト • SREテックリード • SREプロジェクトリード • SRE • ITアーキテクト • セキュリティエンジニア • QAリードエンジニア • QAエンジニア

Appendix

要約機能のアーキテクチャ

2万人が「使える」生成AIをどう育てるか？ 〜 損保ジャパン2万人の社員が使う生成AI機能を育...

2万人が「使える」生成AIをどう育てるか？ 〜 損保ジャパン2万人の社員が使う生成AI機能を育てた、 プロンプト改善とUX設計の軌跡 〜

More Decks by SOMPOホールディングス デジタル・データ戦略部

Other Decks in Technology

Featured

Transcript

2万人が「使える」生成AIをどう育てるか？〜損保ジャパン2万人の社員が使う生成AI機能を育...

2万人が「使える」生成AIをどう育てるか？〜損保ジャパン2万人の社員が使う生成AI機能を育てた、プロンプト改善とUX設計の軌跡〜

More Decks by SOMPOホールディングスデジタル・データ戦略部