100種類超のExcel運用から脱却。事業部門主導のAWS活用でリスクデータを一元管理し、分析の質を高める

SOMPOグループは、大きく「損害保険事業」と「ウェルビーイング事業」の2つの領域を軸に、グローバルに事業を展開しています。損害保険事業には、国内の損害保険事業に加え、先進国から新興国まで29カ国・地域に拠点を有する海外保険事業が含まれます。ウェルビーイング事業には、国内生命保険事業、介護事業、そして健康・介護・老後資金といった社会課題の解決を目指す事業が含まれます。

持株会社であるSOMPOホールディングス株式会社のリスク統括部は、持株会社の立場からグループ全体を横断的に把握し、多岐にわたる統合リスク管理（ERM）を推進する組織です。大規模災害や市場急変時のリスクの定量化（シミュレーション評価）による「財務健全性のモニタリング（守り）」を行うとともに、最適なリスクテイクを後押しして経営の意思決定を導く「経営の羅針盤（攻め）」としての役割も担っています。

「どのようなリスクが存在するか、リスクが発生した際にどの程度の影響があるかを計測することが、私たちの主なミッションです」と、SOMPOホールディングス株式会社のリスク統括部 数理グループ 課長である早瀬 義人氏は説明します。

AWS上にデータ分析基盤を構築するプロジェクトの根底にあったのは、グループ全体で推進する「DDA（Data, Digital,AI）戦略」と歩調を合わせ、「リスクデータの一元管理」を実現したいという思いでした。

同部は四半期ごとに、抱えているリスクの大きさを算出して社外に開示しています。四半期開示に向けた集計や日々の計算では、従来、Excelファイルの受け渡しでデータを連携していました。使っていたExcelは、少なくとも100種類以上。しかも課題は「種類」だけではありません。

もうひとつが「集計時期」です。集計は四半期ごとに行うため、3月末時点の結果はAというファイル、6月末時点の結果はBというファイル……と集計時期ごとに分かれていきます。過去の数字をたどるには、その都度別の保管場所を探さなければなりません。

さらに、集計時期の違うファイルをまとめようとすると、Excelのファイルサイズの制約に直面します。Aに100個の情報があっても、次の工程に渡せるのは10個だけ、といった情報の切り取りが必要でした。そのため「もう少し細かく見たい」となるたびに元のファイルまで遡ることになり、時間がかかるうえ、どのデータが最新版であるかも判別しにくい状態です。さらに、ファイルごとに作業手順も保管場所も微妙に違っており、人数が多くなればなるほど、オペレーションの乖離が生じてしまう状況に、「どの業務でも共通して使える基盤が欲しい」という思いが募ります。

そもそもリスクの計算では膨大な数のシナリオを扱います。その結果を手元のツールで集計するには、処理能力の面でも限界がありました。

「保険会社にとって、数字の誤りは許されません。そして、手順がばらばらでは、誤りを正そうとしても“モグラ叩き”になる。オペレーションが10個あれば、10個叩きに行かないといけないのです」と、同社のリスク統括部 数理グループである中島 哲也氏は語ります。

「このタイミングで対策を講じなければ状況が悪化してしまう」という危機感から、データ分析基盤の刷新が動き出しました。

プロジェクトの推進は慎重に行われました。まず社内での検討段階を設け、中島氏を中心に「どのような運用形態が望ましいか」を整理しました。ウォーターフォール型の開発において全体のコスト感を把握する必要があったため、段階的な運用イメージを描き、不足している要素を洗い出した上で、外部からIT分野の知見を補いました。この段階ではコンサルティング会社の支援を活用しました。

AWSの採用は当初からの決定事項ではありませんでした。クラウド上にスクラッチで構築する案、社内サーバーを活用する案などを並べ、メリット・デメリットを比較検証した上での選択でした。リスク定量化の領域では、分析手法の変更に応じた柔軟なカスタマイズが常に求められます。オンプレミス環境でゼロから構築するよりも、拡張性と俊敏性に優れたクラウド環境であれば、事業部門が主体となって迅速に開発・改善を進められます。新しい取り組みを容認する組織風土があったことも、選定を後押ししました。

「数あるクラウドサービスの中でAWSを選んだ最大の理由は社内での活用実績が最も多かったことです。サポート体制が整っており、採用しやすいサービスでした。一方で、厳格な自社セキュリティポリシーを満たしつつ自由度を確保できるかという点が、最も懸念したポイントでした」（早瀬氏）。

サーバーワークスとの接点は、システム化の検討を始めた初期段階でした。コンサルティング会社に該当領域の専門家がおり、推薦された複数社の中に含まれていました。2025年4月にRFPを提示し、5社程度からの提案を比較検討しました。

サーバーワークスが高く評価されたポイントは3つあります。1つ目は迅速な対応力で、提案書を最も早く提出した点です。2つ目は内容の網羅性です。「当社のRFPは5〜10ページ程度でしたが、要件を正確に理解された上で、70〜80ページに及ぶ具体的なアプリケーション構成を含む提案書を作成いただきました」（早瀬氏）。そして3つ目が、プレゼンテーション時の説得力でした。

「システム開発は硬直的なスケジュールで進めるものという認識がありましたが、最終提案の際に“状況に応じて柔軟に対応します”と明確にご提示いただけたことが、決定の重要な要素になりました。開発後の運用・保守まで含めた提案内容であったため、構築後の運用プロセスを具体的にイメージできました」（中島氏）。

「システム構築そのものが目的ではなく、将来的に現場で運用するためのツールに過ぎません。構築したシステムを自社で理解し、実際の業務オペレーションに定着させられるかが最大の課題でした」（早瀬氏）。

プロジェクトの成否を分けるのは、「運用後の姿が具体的にイメージできるか」という点でした。提案から支援開始まで、わずか2ヶ月でプロジェクトが本格始動しました。

事業部門が主体となる大規模なシステム開発は、SOMPOホールディングス社内において一般的な事例ではありません。利用者がリスク部門に限定される「部門システム」をゼロからプロジェクト化して開発するケースは稀でした。それでも数理グループが主体となった理由は、本領域が極めて専門的であり、業務内容を熟知した担当者が主導しなければ推進できないプロジェクトだったからです。

「部内に専門知識を持つメンバーが少なかったため、外部の知見を活用しながら進めました。また社内の他部署に存在するAWSやクラウドの専門家からもサポートを受けました。不安はありましたが、サーバーワークスの手厚い支援により、完遂することができました」（早瀬氏）。

全社ガバナンスとの整合は、社内のCCoE（Cloud Center of Excellence：全社的なクラウド活用推進組織）が担いました。「ベンダー選定やシステム設計に関してレビュー・フィードバックを受けました。アドバイザーとしてプロジェクトに関与していただきました」。関与形態は書面ベースのレビューが中心であり、CCoEのメンバーが開発現場へ常駐することはありませんでしたが、選定ベンダーや進捗状況を適宜報告しながら進めました。

AWS利用ガイドラインの適用もCCoEの管轄領域でした。チェック項目が多岐にわたる詳細なリストでしたが、中島氏は「当社からガイドラインを提示し、実装への適用をお願いしました。すべての項目に対して、誠心誠意対応していただきました」と振り返ります。チェックリストを通じた確認作業自体がAWSの理解を深める機会となり、今後のシステム運用における基盤知識の獲得につながりました。

サーバーワークスのエンジニアである松田 浩孝は、次のように述べています。「セキュリティ管理において重要なのは、異常を検知すること、そして検知後に誰がどのような対処を行うかを明確にすることです。今回はSOMPOホールディングス様がこの点を重視されていたため、具体的な設定値と運用基準に落とし込み、実務で運用可能かという観点から詳細な検証を実施しました」

プロジェクトにおける主要な課題の1つは、横断的に管理されていなかった業務フローを一元管理し、システムの仕様へ落とし込む工程でした。開発着手前に事前の整理を行っていたものの、開発プロセスの中で仕様変更や手戻りが複数発生しました。

「業務フローをA→B→Cという一連の流れとしてそのままシステム化する予定でしたが、詳細を確認したところ、AとBの間に別の処理が存在していることが判明する事例がありました」（中島氏）。

現場業務への解像度が不足していたため、明文化の過程で整理漏れが生じていました。しかしこの作業を通じて、従来可視化されていなかった隠れた業務プロセスが明確化されました。中島氏が評価する点は、この局面におけるサーバーワークスの柔軟な対応でした。

「規定通りの仕様以外の変更を受け付けないという形式的な対応をされると開発が停滞してしまいますが、仕様変更が発生した場合でも、既存枠組みの中でどのように吸収できるかを検討し、適宜受け入れていただきました。早い段階から柔軟なサポートを提供していただいたことが、プロジェクト推進上の安心感につながりました」（中島氏）。

プロジェクト期間中は、週1〜2回の定例ミーティングを継続して実施しています。不明点や確認事項を精査した上で、質問して数理グループが回答する形式で進められました。課題管理はチケット単位で行い、テキストのみでは伝わりにくいニュアンスをミーティングで補完します。

プロジェクト途中で、当初の対象範囲に含まれていなかった追加開発の要望が発生しました。シミュレーション結果を加工し、統計処理を行って出力用データに変換する集計機能の実装です。

「開発体制を含めて検討いただき、対応可能という回答をいただいたことは、大きな安心感につながりました。結果としてスコープを縮小することなく、コストとスケジュールの調整により追加実装を実現しました。通常開発と並行して約4ヶ月間で追加開発を完了し、品質を維持したまま期日通りに納品されました」（中島氏）。

サーバーワークスのエンジニアである佐藤 航太郎は「数値の正確性が厳格に求められる案件であったため、緻密な計算検証が必要でした。設計情報を1項目ずつ明確に定義し、お客様と相互確認を行いましたが、仕様書の詳細なロジックまで把握された上での適切なご指摘をいただきました」と振り返ります。

本番リリース前の2025年12月には、ユーザー向けの勉強会を実施しました。3日間で計4回、1回あたり2〜3時間程度。管理者レベルとユーザーレベルの内容を切り分け、管理職を除く20〜30名程度が参加しています。

数理グループが意識したのは、特にツールの使い方について、実データに近いものを用意して説明してもらうことでした。ユーザーにとっては初めて触れるシステムでしたが、どういうものか理解できた、AWSに対する抵抗感が払拭できたという反応が得られたといいます。

勉強会の前には、パイロット的に何人かに実際に触ってもらう機会も設けました。開発に一切関与していないメンバーが、マニュアルだけを見て操作するという形です。マニュアルの整備や円滑な導入に向けた環境づくりがしっかりされていた、と数理グループは振り返ります。

プロジェクトは2026年2月に完了し、同年3月から実務での本格運用が始まりました。一連の伴走のメリットとして数理グループが挙げるのは、単なるシステム開発者としてではなく、データ処理のプロフェッショナルとして伴走してもらえた点です。複雑なユーザー要件を深く理解したうえで、それをユーザーが実際にどう扱うべきかというレベルにまで落とし込んで考えてくれたといいます。

また、最も素晴らしいと感じた強みは、ユーザー要件を深く的確に理解する能力の高さです。自分たちでは対処しきれない課題に対しても、常に複数の解決案を提示してもらえたことが、大きな助けになりました。

もっとも、柔軟性は一方通行ではありませんでした。サーバーワークスの技術マネージャーである松井 宏司は「ユーザーに今回のシステムを出した際、もっとこうできないかという要望がいくつか出てきた場面で、早瀬様がそれを非常に柔軟にさばいてくださり、我々の改修が追加されないような形で調整してくださいました。お互いに柔軟な対応ができたおかげで、プロジェクトを成功に導けたと思っています」と振り返ります。

詳細な数値測定は今後実施する予定ですが、業務効率化の観点では明確な効果を確認しています。「感覚値として、リスク量の自動計測にかかる作業時間は概ね半分程度になっている」と早瀬氏はいいます。

AWS Step Functionsを実行すればボタンひとつで結果が出てくるようになり、確認の仕方そのものが変わりました。ログの時刻やデータの投入時刻はいつか。見るべきポイントが絞られ、確認箇所は大きく減少しています。個別の環境に分かれていたデータ管理や作業フローがクラウド基盤上で一元化・標準化されたことで、データの受け渡しに伴うオペレーショナルリスクも極小化されました。

変化が大きいのはガバナンス面です。データの履歴が細かく取れるようになり、これまでのやり方では見えていなかった部分が可視化されました。仕方がないと割り切って省略し、そのまま集計に回していた部分まで、しっかり見られるようになっています。扱えるデータ量自体も増えたため単純な時間の比較だけでは効果を測りにくい面はあるものの、確認できるポイントが増えたことで「分析の質」も上がっていると早瀬氏は評価します。ヒューマンエラーについても、実際に起こった件数というより、発生リスクそのものを削減できているという実感があるといいます。

もうひとつの大きな成果が、メンバーのデータ活用に対する意識の変化でした。現場から、一元化されたこのデータソースを活かして、親和性の高い他の業務領域にもシステムの活用を広げられないか、という前向きな議論が生まれるようになったのです。これまで使える道具はExcelしかなく、サイズの大きいデータは部分的に切り取りながら扱うしかありませんでした。できることが増えた今は、この基盤を前提に業務のやり方そのものを再構築する検討を進めています。

現在、同部ではExcelからAWSのクラウドBI・データ分析ツールであるAmazon Quickへの移行作業を進めています。Amazon Quickは、主に各担当者がシミュレーション結果から必要なデータを任意に抽出する用途で活用されており、リスクデータの構造に合わせたダッシュボードの表示形式について検証を重ねています。

新たなツールの定着に向け、同部では「業務特性に応じた使い分け」を基本方針として掲げています。大容量データの処理や複雑な集計にはAmazon Quickを活用し、小規模な処理や即時性を求める作業には従来通り小回りの利くExcelを利用するという、ユーザーの実務に即したバランスの良い運用を推進しています。

すでにコア業務である「リスク量の自動計測」プロセスは新基盤への移行を完了しており、構築された基盤はデータウェアハウス（DWH）として確実に機能しています。ユーザーに対しては、「データベース集計による処理スピードの向上」、「集計ロジック可視化による業務引き継ぎの容易化」、「生成AIのコード記述サポートによる作業負荷軽減」という3つのメリットを提示することで、スムーズな移行と意識変革を後押ししています。

将来的な大規模展開などの長期的な構想については足元の定着を優先し、当面は構築した基盤の運用とユーザーへの浸透を最優先課題として位置付けています。その上で、サーバーワークスに対しては、運用フェーズで発生するユーザーからの改善要望への迅速な対応と、クラウド環境におけるセキュリティの維持・管理を期待しています。

「当事者意識を持ってシステム開発の全工程に関与したのは初めての経験でしたが、要件のドキュメント化やスケジュール遵守、柔軟な仕様変更対応など、極めて信頼性の高いパートナーシップを構築できました」と早瀬氏は振り返ります。中島氏も「当初は保険業界固有の業務知識をお持ちではありませんでしたが、ドメイン知識を深く理解した上でシステム構築へ落とし込んでいただきました。そのプロフェッショナルな姿勢に感謝しております」と語り、今後の継続的な支援と伴走への高い信頼を寄せています。

最後に、同様の課題を抱える企業へのメッセージとして、中島氏は「業務オペレーションの改善においてシステム化は有効な手段であり、特に構築の過程で既存の曖昧な業務フローが不可避的に明文化されるメリットがあります。自社内で目指すべき運用像を定義し、不足する知見を外部パートナーと補完し合うことが成功の鍵になります」と締めくくりました。