Upgrade to Pro — share decks privately, control downloads, hide ads and more …

その問い合わせ対応、本当に“人”がやる必要がありますか? 損害保険ジャパンが仕掛けるAIエージ...

その問い合わせ対応、本当に“人”がやる必要がありますか? 損害保険ジャパンが仕掛けるAIエージェント革命

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

Other Decks in Technology

Transcript

  1. 自己紹介 • 2015年 損害保険ジャパンに入社 • 営業現場で5年間代理店営業を経験。 • DX推進部にて社内向けの生成AI PJTやLLMによる照会業務効率化の PJTのプロジェクトマネージャーとしてPJTを推進している。

    • 2022年 損害保険ジャパンに転職 • DX推進部 開発推進グループ チーフエンジニア • おしそんLLMを始め、LLMの利活用を進めるためのプロジェクト にリードエンジニアとして従事 楠木 裕次郎 眞方 篤史
  2. 損害保険ジャパンにおける生成AIの展開方法 2022年頃から内製開発をベースに汎用型、業務特化型にスコープを分けて展開を開始 汎用型生成AI (SOMPO AI Chat) 業務特化型生成AI (おしそんLLM) 生成AIを広く多くの社員に利用してもらうための取組。 社内版生成AIツールを使って全社員がさまざまな業務に自発的かつ自由に活用し、

    各職員自身が効率化の観点などから活用した活動を社内で活発に情報共有している状態を目指すもの。 特定の業務フローやシステムに生成AIを組み込んで、業務効率化を目指す取組。 代理店営業における問い合わせフローや保険金支払における有無責判定などにおける課題 に対して業務フロー内や裏側で生成AIを活用し業務効率化を目指すもの。
  3. 損害保険ジャパンにおける生成AIの展開方法 2022年頃から内製開発をベースに汎用型、業務特化型にスコープを分けて展開を開始 汎用型生成AI (SOMPO AI Chat) 業務特化型生成AI (おしそんLLM) 生成AIを広く多くの社員に利用してもらうための取組。 社内版生成AIツールを使って全社員がさまざまな業務に自発的かつ自由に活用し、

    各職員自身が効率化の観点などから活用した活動を社内で活発に情報共有している状態を目指すもの。 特定の業務フローやシステムに生成AIを組み込んで、業務効率化を目指す取組。 代理店営業における問い合わせフローや保険金支払における有無責判定などにおける課題 に対して業務フロー内や裏側で生成AIを活用し業務効率化を目指すもの。
  4. アップデート履歴と現場への浸透施策 2023年度 2024年度 2025年度 ~3Q 4Q 1Q 2Q 3Q 4Q

    1Q 2Q 3Q 4Q トライアル 全社展開 ファイル添付機能 ログイン機能 アプリ機能 Web検索機能 アプリ作成機能 フロントは完全内製開発でユーザーからの要望等をアジャイルに取り込み 3ヶ月に1度のペースで機能のアップデートを行いながら現場社員への研修展開等で定着を目指す。 全社展開後は登録率 20% MAUは10%前後と苦戦 ファイル添付機能により 活用幅が広がり、MAU が 15%~20%程度まで上昇 現場への好事例展開等を継続的に実施 現場発信での研修や投稿等もみられる ように Web検索機能やアプリ作成機能のため の研修開催により本社部門を中心に利 用が定着(MAU35%) 現場市民開発でさらな る定着を目指す ユーザーからのFBを踏まえた定期的なUI改修、最新のモデルの追加 etc 全社員視聴の衛星放送/ポータル画面への掲載/Chatスペースへの投稿/エリアごとの研修等 生成AIリーダーシップ研修 e-learning (生成AIの基礎的な知識の習得) 生成AIリーダーシップ研修 ワークショップ (生成AIを活用して業務効率化を目指すためのユースケース発掘) 機能改修 施策展開 登録率: 40% MAU :15%~20% 登録率: 45% MAU :20%~ 登録率: 65% MAU :35% 登録率: 20% MAU :10%
  5. 反復利用できるプロンプト 個人で、一回しか使えないユースケース 複数人で反復して活用するユースケース • 業務改善のアイディアをもらう • 初めての業務に対して進め方の方針を考え てもらう • 自動化(GASやVBA)のコードを出力してもら

    う • 営業週報を作成する • 毎月開催している勉強会の内容を作成する • 顧客ごとの事故対策を検討する プロンプトとして確立する必要はない プロンプトとして確立させ、 複数人が反復して活用できる状態を目指す
  6. 損害保険ジャパンにおける生成AIの展開方法 2022年頃から内製開発をベースに汎用型、業務特化型にスコープを分けて展開を開始 汎用型生成AI (SOMPO AI Chat) 業務特化型生成AI (おしそんLLM) 生成AIを広く多くの社員に利用してもらうための取組。 社内版生成AIツールを使って全社員がさまざまな業務に自発的かつ自由に活用し、

    各職員自身が効率化の観点などから活用した活動を社内で活発に情報共有している状態を目指すもの。 特定の業務フローやシステムに生成AIを組み込んで、業務効率化を目指す取組。 代理店営業における問い合わせフローや保険金支払における有無責判定などにおける課題 に対して業務フロー内や裏側で生成AIを活用し業務効率化を目指すもの。
  7. おしそんとは? 代理店さん QAデータベース 教えて!SOMPO本体 QA更新/データ投入 (主に)商品部 検索 QA生成 検索/ 照会ログ

    営業店/本社 営業店 照会 代理店さん 営業店 回答 質問入力 不明点解消 ③ ・「教えて!SOMPO」の愛称 ・代理店からの質問に、参考となるFAQや規定集などを提示する検索システム
  8. おしそんLLMとは? おしそんが抱える各種問題を解決するため、LLMを活用した1問1答を実現するためのシステム 代理店さん 検索文生成 QAデータベース 教えて!SOMPO本体 QA更新/データ投入 (主に)商品部 検索 QA生成

    検索/ 照会ログ 営業店/本社 営業店 照会 代理店さん 営業店 回答 回答案生成 質問入力 不明点解消 照会内容投入 回答案の示唆 本社照会内容 投入 ① ② ③ 回答案の示唆 • 代理店さんが検索文をうまく作成できずに、欲し い回答に辿りつかない • 検索を諦め、営業店に電話等で照会するため対 応負荷が大きい ①解きたい課題 • 規定・QA等の点在する 情報から回答を作成す るため、多大な時間を 要する ②解きたい課題 • 新商品や商品改定等 の都度、新たなQA作 成、メンテナンスを行わ なければならない • 各担当者のマンパワー で実施 ③解きたい課題
  9. おしそんLLMとは? 照会回答の効率化を目指し、AIが回答文を自動作成することで照会回答時間を削減する仕組み ドキュメント 規定集、Q&A、 SDW(予定) おしそん 検索機能 代理店さん/ 営業店 LLM

    回答 ② 検索機能を介して   質問に沿った当社固有の知識を提供  例)ゴールド免許特約とは...  ① ユーザーがおしそん上で照会を実施  例) ゴールド免許特約は、***の条件で  適用可能でしょうか? ③ 検索によって得られたドキュメントを  根拠としつつ回答を生成する  例)適用可能です。  おしそんLLM
  10. おしそんLLM開発の歴史 • 2023年3月 生成AIのビジネスでの活用を行うべく、DX推進部内で勉強会を開催。ビジネスメンバーと一緒に社内活用について議論 • 2023年4月 感度の高いビジネスユーザから、生成AIをおしえてSOMPOに活用できないか相談が来る • 2023年5月 内製エンジニアチームとビジネスユーザがタックを組んで、 1週間でクイックにプロトタイプを実装 • 2023年6月 ビジネス部門にプロトタイプを披露。動くものを見せることで、成果物のイメージがクリアに。

          ビジネス部門も積極的に、学習データの整備など、結果の検証、プロンプトの改修など泥臭い作業に協力してくれた • 2023年12月 初期プロトタイプを現場展開。 不評。。。UXを大幅に変更 • 2024年2月 テキストの構造化やチャンクの見直しなど投入データの前処理により、検索精度が向上 • 2024年5月 本社商品部での追加PoCおよび学習データへのラベリングを実施  質の高い学習データの蓄積 • 2024年10月 現行バージョンを現場でPoC開始。実施検証でデータをためながら、 内製で少しずつ精度向上 • 2025年4月 LLMによる評価手法を確立。これによりモデル切替時や新商品追加時の客観的なスコア評価が可能に • 2025年6月 9,000人以上のユーザが毎日利用している
  11. おしそんLLMからおしそんエージェントへ • 質問からエージェントが自律的にタスクを計画 。Actionを利用してタスクを実行しながら PDCAサイクルを回す(例:ユーザ追加質問、知らない単語をWEB検索、検索クエリーの修 正、社員に結果を確認など) おしそんエージェント 社内データ FAQ/規定集等 検索システム

    マルチターン (追加質問) 社内データ 契約情報 回答 履歴 回答 ユーザ フィードバック WEB検索 API チャット A2A 自動音声 エンドユーザ 代理店 システム エージェント 社員に質問 ユーザフィード バック アプリ / フォーム Action Action Action Action Action 学習データを保存
  12. 今日話すこと ― エージェント開発で直面した3つの壁 ワークフロー設計 エージェントをどの様に 構築するべきか? 開発の流れは? 1. 2. 3.

    評価戦略 何をどう評価するのか、 評価データをどう構築す るか? 精度・コストの壁 エージェント化によって 複雑なタスクが解ける様 になるのか?
  13. エージェントをどう開発するか? エージェントの実装パターンは、大きく「ワークフロー型」と「自律型」に分けられる。 ワークフロー型 自律型 事前に定義 LLMが動的に判断 処理フロー 特徴 業務フローをパターン化でき ている必要があるが、デバッ

    グが容易で予測可能性も高い 柔軟なタスクに対応できる可能 性があるが、コストが高くなり がちで事前のデバッグが困難 適用領域 業務フローを事前に定義 できるユースケース全般 ソフトウェアの コーディング等 エージェント=「自律型」とは限らない。むしろ、「業務のエージェント化を目指す=パターン化できている」 状態であると考えると、ワークフロー型での実装が自然な選択。
  14. エージェントをどう開発するか? STEP 2 開発環境整備 SDKの選定等 STEP 1 ワークフロー選定 アーキテクチャを決める STEP

    3 評価データ構築 エージェントごとの 評価データを構築 STEP 4 精度向上 プロンプトチューニング等 STEP 5 デプロイ アプリ開発チームへの 引き継ぎ等 ポイント:ワークフロー選定 ➢ 大枠でも良いのでユースケースの「どこか らどこまで」を「どうやって」エージェン トに任せるかを決める ➢ 「エージェントの実装」だけが正解ではな い、トレードオフを理解してPlan Bの用意 を ポイント:評価データを早期に構築 ➢ ワークフローの大枠を決めたら、開発環境 の整備と並行して評価軸をチームで合意 ➢ 各エージェント単位+ワークフロー全体で の評価データセットを構築 ➢ 手戻りを最小化し、早期に精度検証を行う ことが重要
  15. エージェントをどう開発するか? STEP 2 開発環境整備 SDKの選定等 STEP 1 ワークフロー選定 アーキテクチャを決める STEP

    3 評価データ構築 エージェントごとの 評価データを構築 STEP 4 精度向上 プロンプトチューニング等 STEP 5 デプロイ アプリ開発チームへの 引き継ぎ等 先に決めたこと 後回ししたこと E2Eで評価を回せる基盤 まず全体を通して評価できる基盤を作り、ボトルネックを特定できる様に 評価指標(KPI)の定義 網羅性(論点を全てカバー)とシンプルさ(回答の短さ)を設定 ワークフローの大枠 RAG vs エージェンティックRAGの比較構成を早期に決定 各ステップの細かい調整 プロンプトチューニング等、各ステップの最適化は後回しに 💡この順番が重要 細部の最適化より先に「測れる状態」を作ることで、定量的に確認しながら 判断することができる
  16. エージェントをどう開発するか? 今回はワークフロー型を採用し、照会対応に必要なプロセスをエージェント化。 教職員共済は等級継承可能 でしょうか? 等級継承できる場合はどの様 な 手続きを踏めば良いですか? 照会 照会内容の 明確化

    質問の分解 回答根拠の 検索 回答生成 回答要約 回答根拠の 検索 回答生成 Q1: 教職員共済は等級 継承可能か? Q2: 等級継承の際の 手続き はい、可能です… 1 2 3-1 4 3-2 3-1 3-2
  17. エージェントをどう評価するか? ➢ 個別評価ではエージェントごとに専用の評価データセットを構築 ◦ 例:照会内容の明確化を行うエージェントの評価例(人力でのレビュー) AIが判定した 内容 人のレビュー結 果 ➢

    LLMを用いた評価データ構築/評価の自動化 ◦ 上記の様な人手での評価は信頼性は高いが、コスト・網羅性の部分で限界がある ▪ 開発時にはLLMによる自動生成データも同時に利用 • エッジケース・人力で作成が難しいケースを効率的に評価 ▪ LLMによる評価(LLM-as-a-Judge)は不可欠 ▪ エンドユーザー向けにリリースする際には、レッドチーミング(安全性・脆弱性の検証) 等も 検討が必要
  18. 結果 ➢ 「エージェント化すれば複雑な問題が解ける」わけではない ◦ 構成が複雑になるほど、エラーの連鎖(エージェントの小さなミスが全体のミスを招く)・コスト増の リスク ➢ プロンプトチューニングの限界 ◦ 個別エージェントの精度向上を試みたが、意外とすぐ頭打ちになる

    ▪ プロンプトで救える範囲には限界がある ◦ 根本的にはワークフロー設計・タスク分解の見直し、あるいはfine-tuning等が必要 RAG(非エージェント) エージェント 精度 42% 36% コスト 9.1円 20.6円 速度 10秒程度 20~30秒
  19. まとめ ➢ 照会対応のプロセスの自動化を目指し、エージェント開発を行った。 ◦ エージェント開発においては、比較対象として非エージェントのRAGを用いたシステムと比較 ◦ 精度、速度、コストの全ての面で非エージェントのRAGが優れているという結果に ➢ 当初の構想では全てをエージェント形式に置き換える想定だったが、上記の結果を踏まえ一部 (「照会内容の明確化」)のみをエージェント化することを検討中。

    ◦ 照会内容の明確化は会話の中で動的に質問を生成する等、エージェント化との親和性が高い ➢ 学び 構成は柔軟に見直す • 最初の設計に固執しない • 幻滅しない • 「エージェント化」はAll or Nothing ではない 定量・定性の評価どちらも重要 • 定量評価 : 個別エージェントの最適化時 等で精度を追うフェーズ • 定性評価: 改善ポイントを見つける (評価の深さが重要)