課題を見つけてもすぐに技術に飛びつかない。「課題ドリブン」で開発対象を厳選
損保ジャパンは岐路に立たされていた。年々甚大化する自然災害、そして2024年1月の業務改善命令を受け、新中期経営計画で改革のための全社横断プロジェクト「SJ-R」を始動した。そのなかで保険金サービスでは「適切な保険金支払いとお客さまの満足を実現」を掲げている。
今回の開発プロジェクトでフォーカスしたのは顧客とのコミュニケーションの改善だ。従来、顧客とのコミュニケーション手段は電話、メール、LINEなどが並行しており、個別最適でアプリが開発されてきた。そのため現場では顧客に合わせてアプリを切り替える必要があり、これは職員の認知負荷を高め、業務を煩雑化させていた。
現状の課題を打破すべく、各チャネルをAPIで連携し、あらゆるコミュニケーションを「1つのプラットフォーム」に集約することを目指した。まずはLINEの統合から着手し、現在では開発を終え、全国の拠点で利用されている。続いてメールの統合ツールも開発完了を間近に控えている。
こうして開発してきた統合コミュニケーション基盤に、今度は生成AIを活用した機能を実装することになった。SOMPO Digital Lab 小林勇喜氏は「技術ドリブンな発想で作られたものは、結局現場で使われないことも少なくありません。そこで私たちは徹底した課題ドリブンを貫きました」と強調する。
同社では、まず業務プロセス自体を見直し、ROIを厳しく判断したうえで開発に移るというスタンスを徹底している。小林氏は「NOと言える判断や開発対象の厳選は、ビジネスと開発が一体化したアジャイルチームだからこそ実現できた強みだと考えています」と話す。
生成AIを活用して実装したのは要約機能だ。LLMが得意な領域でもある。業務現場では、顧客とやりとりすると、追って基幹システムに案件（対象となる事故）とともに経緯を記録しなくてはならない。保険業法で定められているので必須だ。この要約の品質が担当者のスキルや経験に依存して属人化し、時間がかかる作業となっていた。
小林氏は「1件ごとの作業は小さくても、積み重ねると膨大な時間が職員の方々を圧迫していました。もし私たちがビジネスサイドと切り離された受託的な開発チームでしたら、この苦労に気づけなかったと思います。重要な改善ポイントでした」と話す。
ビジネスと開発が一体となって進めたスクラム開発 モデル選定はガードレールで
今回の実装は3つのステップからなる。1つ目はAIによるやりとりの要約。チャットエリアから要約したいメッセージを選び、「要約する」ボタンをクリックする。ここで自動車保険や火災保険など保険種別ごとに必要な情報がもれなく入るようにしている。2つ目は人間が介在して要約結果を確認する。そして3つ目は「経緯登録」ボタンをクリックすることで基幹システムへ登録を済ませる。
このフローに変えた結果、1回のオペレーションにかかる時間は従来の1/3にまで短縮できた。
開発プロセスは、ビジネスと開発が一体となるスクラム開発で、スプリントは1週間単位で回している。小林氏は「毎日顔を合わせ、作ったものをすぐ見せてフィードバックをもらう。このスピード感が私たちの武器です」と言う。
しかし展開は慎重に行う。新しいオペレーションモデルができたら、いきなり全国展開するのではなく、モデル拠点で先行導入を行う。ここで業務要件と開発した新機能の間にどのような乖離があるかを検証し、マニュアルを整備したうえで、全国の拠点に展開する。なおリリース制御には、コードをデプロイしながらも機能のオン／オフを切り替えられる「Feature Flag」を活用し、ロールアウトの安全性とスピードを両立させている。
現場からは「浮いた時間で、お客さまへより迅速で丁寧な対応ができるようになった」と好評だ。さらに経緯入力内容が簡潔・標準化され、進捗の状況把握や担当者間の共有・引継ぎにも良い効果をもたらした。
当初はAmazon Bedrock経由でClaude Sonnetを利用しており、ある月の実績ではコストは6万3000円ほど。後にコストと精度・速度のバランスを再検討し、現在ではVertex AI経由のGemini 2.5 Flash-Liteを利用している。同程度の利用量で比較すると、月間のコストは約5000円ほどに収まった。なお要約機能はマイクロサービス化しているため、モデルを変更しても裏側の接続先を変えるだけでスムーズに移行できた。
このモデル選定では「品質下限」と「コスト上限」のガードレールを先に決め、両方を満たす領域だけを採用することにした。まず開発フェーズでは、コスト度外視で最高性能のモデルで実現可能性と最高精度を確認する。そして次のフェーズでは、その精度を維持できるラインまでプロンプトをチューニングして、徐々に安価なモデルへと置き換えていくという手法を採り、モデル選定を最適化した。
暗黙知を言語化する評価基準作成 独自ツール「AI TrustEval」でプロンプト改善
ここからはプロンプト構築の詳細に踏み込んでいこう。「要約」には正解が1つではないため、従来のシステム開発とは異なる課題に直面した。課題とは評価の属人化とコストのジレンマだ。前者は、同じ出力でも担当者によって評価が割れてしまうこと、後者は品質を担保するために人間の目視評価を増やすと工数が増えてしまうことだ。
実際に新機能をビジネス担当者に見せると「実務上必要な観点が網羅されていない」「お客さまへの配慮が欠けている」とフィードバックされるも、エンジニアは「実務上必要なこととは具体的に何か？」「失礼にあたるケースとは？」と困惑してしまっていた。両者の間には知識や感覚に大きなギャップがあったのだ。
この“感覚”を明文化するために評価基準を策定した。同社 藤野智彦氏は「ポイントはエンジニアだけで作らないことです。ビジネスと膝を突き合わせ、ワークショップ形式で一緒に作成しました。このプロセス自体がビジネスとエンジニアの認識を合わせる貴重な機会となりました」と話す。
評価基準は3つのステップで言語化した。まず（1）「利用シーンを特定」し、誰が何を決めるのかを整理した。続いて（2）「失敗リスクの抽出」では、何が起きると後続業務を含めて致命的になるのかを洗い出した。そして（3）「合格ラインの決定」では、業務が止まらない最低限の許容範囲を決めて合意した。こうして曖昧だった良し悪しを4つの明確な評価軸「要約品質」「業務適合性」「正確性・事実性」「倫理・コンプライアンス」に落とし込み、5段階の評定表も作成した。
評価基準ができると、次の4ステップでサイクルを回した。（1）「初期定性レビュー」では、生成AIの出力で許容範囲を洗い出すなど、方向性を確認する。続いて（2）「定量評価」では、検証データを評価ツールで定量的に採点することで品質を測定する。そして（3）「詳細定性評価」では、定量評価で測れない「業務上の違和感や致命的なものがないか」を5段階で評価するなど、人間の目による最終確認を行う。最終的な（4）「デリバリー」では、ユーザー受け入れテストを実施し最終確認した後に、ユーザーに展開する。この4ステップを定義することで、属人化を排除し、ビジネス側の工数を削減した。
特徴的なのが（2）「定量評価」だ。ビジネス担当者が自主的に評価プロセスを回しやすいように、独自の評価ツールとなるWebアプリケーション「AI TrustEval」を構築した。これを用いて100件程度の検証データから品質を定量計測できるようになり、業務で使えるかどうかの判断確度が上昇した。
「AI TrustEval」は評価データの管理、プロンプトの管理、生成AIによる評価といった機能を持つ。AIが自動で採点するので、ビジネス担当者はAIが低評価をつけたものや判断に迷ったものの確認だけに集中できるようになり、評価工数が劇的に削減できた。
技術スタックはUV WorkspaceによるMonorepo構成で、Frontend、Backend、Evaluationの3パッケージを管理している。FrontendはPythonで完結するDash、BackendはFastAPIの非同期構成にしている。評価エンジンは「DeepEval」（GEvalをカスタマイズ）を利用し、Gemini・GPT・Claudeのマルチプロバイダに対応している。
暗黙知の言語化から始まる評価基準の策定と、ツールによる評価プロセスの自動化により、軽量モデルでも実業務に耐えうる品質を実現し、高いROIにつなげることができた。
藤野氏は「これによりビジネス主導でAIを育てられる環境が作れた」と手応えを語る。ビジネスが自立してプロンプトの構築・評価・改善を回せるよう、方法・手順・Tipsを標準化した。今回のプロセスで得られた成果は「システムプロンプト構築ガイドライン」として社内へ横展開し、他のプロジェクトでも活用できるようにしている。生成AIで業務課題を解決しただけではなく、組織でAIを継続的に育てていくための土壌が生まれた。
ＳＯＭＰＯホールディングスからのお知らせ
ＳＯＭＰＯホールディングスではエンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
