楽天の保険子会社で進めていた「生損保一体型基幹システム」が事実上頓挫し、減損損失や金融庁からの報告徴求命令にまで発展しています。
一方、滋賀銀行は次世代勘定系システムの開発を途中であきらめ、ベンダーとの契約を打ち切って和解金80億円を受け取るという異例の決断をしました。
ダイヤモンド・オンライン+1
どちらも「攻めのDX」「老朽システムからの脱却」という旗印でスタートしたプロジェクトです。それなのになぜ、大きな損失や路線変更という結果に至ってしまったのか。
この記事では、ニュースや専門記事をもとに、楽天と滋賀銀行で何が起きたのかをやさしく解説しつつ、日本企業が同じ轍を踏まないためのヒントを考えていきます。
目次
そもそも「基幹システム」って何？
まず前提として、「基幹システムってそんなに大事なの？」というところから整理しておきます。
イメージとしては、会社の“心臓と血管”＋“大福帳（昔の帳簿）”を全部まとめたものだと思ってください。銀行なら預金・融資・振込などの取引を記録する「勘定系システム」、保険会社なら契約情報や保険金支払を管理するシステムがこれに当たります。ウィキペディア
ここが止まると、お金の動きや契約処理そのものが止まるので、銀行ならATMが動かない、保険なら保険金が支払えない、というレベルの大事故になります。だからこそ、「古くて限界が見えているのに、壊すのも怖い」 という、非常に扱いが難しい存在になっているわけです。
楽天：生損保一体型基幹システムの“夢”と現実
夢の構想：生保と損保を一つの基幹システムに
楽天保険グループは、老朽化した楽天生命・楽天損保の基幹システム（開発から40年以上経過）を一気に刷新し、業界初の「生保と損保の一体型基幹システム」を作ろうとしていました。ダイヤモンド・オンライン+1
2023年11月には、グループとして生損保一体型基幹システムの構築開始を正式発表。クラウドネイティブな「Rakuten One Cloud」をフル活用し、マイページやスマホアプリと基幹システムがシームレスに連携、AIチャットボットが手続きをサポートする、といった“楽天らしい”DX構想が描かれていました。楽天ライフ+1
ざっくり言うと、
「バラバラで古いエンジンを全部捨てて、最新仕様のハイブリッドエンジンに総載せ替えする」
という、かなり野心的なプロジェクトだったわけです。
現実は：迷走・減損・金融庁の報告徴求命令
ところが、この「夢のエンジン換装」は順調には進みませんでした。
週刊ダイヤモンドの特集では、新基幹システムの開発が遅延・迷走し、最終的には金融庁から報告徴求命令が出る事態にまで発展したことが報じられています。ダイヤモンド・オンライン+1
楽天グループのIFRS決算資料を見ると、保険事業のところに
-
生損保一体型基幹システムの一部について「無形資産の除却損」
-
損保向け基幹システム開発計画の見直しに伴う「減損損失 約96億円」
といった記載があり、計画の見直し・中止に伴ってかなり大きな損失を計上していることがわかります。StockWeather+2Rakuten Group, Inc.+2
さらに、保険システム関連を巡ってIBMとの訴訟解決費用も発生しており、決算上は「一時的費用」として並んで記載されています。Yahoo!ファイナンス+1
つまり、「業界初の生損保一体型」プロジェクトは、技術・スケジュール・ガバナンスの面で破綻し、一部は捨てざるを得ない状態になった、というのが決算と報道から見える現実です。
どこが無理筋だったのか
外から見ていても分かる“無理筋ポイント”は、少なくとも三つあります。
一つ目は、生保と損保を一つのシステムにまとめる難易度の高さです。生命保険は超長期の契約管理、損保は事故や自然災害など短期的な支払処理が中心で、業務ロジックや規制もかなり違います。これを一つの共通基盤で全部さばこうとすると、要件定義もテストも爆発的に複雑になります。
二つ目は、**老朽システムの歴史的な“しがらみ”**です。楽天生命・楽天損保の基幹は40年以上運用されてきたレガシーで、保険業特有のカスタマイズが積み重なっています。ダイヤモンド・オンライン+1 これをきれいに抽象化して新システムに乗せ替えるには、業務側と一緒に「どのルールを捨てるか」「どこまで標準に寄せるか」を決める必要がありますが、そこを一気にやろうとしたことで、現場とシステムのギャップが広がったと考えられます。
三つ目は、ガバナンスとリスク管理の視点です。金融庁が報告徴求命令まで出したのは、「このままではシステムリスクが顧客保護に影響し得る」と判断したからです。ダイヤモンド・オンライン+1 大規模システム刷新では、計画遅延や品質問題が起きたときに、どの時点でブレーキを踏み、スコープを絞るのかが重要ですが、そこが後手に回った可能性があります。
滋賀銀行：次世代勘定系を途中で諦め、ベンダー変更へ
日立との「次世代基幹系」計画
滋賀銀行は、地方銀行として早い段階から「次世代基幹系システム」の構築に取り組んでいました。2021年には日立製作所と組んで新しい勘定系システムの開発に着手し、当初は2024年1月稼働を目指していました。しがぎん+1
しかし、2023年2月の時点で同行は稼働時期の延期を発表します。公式リリースでは、「想定を上回るハードルの高さ」と「安定的な銀行システム提供の観点からサービスイン時期を延伸する」と説明しており、この段階で既に難航していたことがうかがえます。しがぎん+1
開発中止と和解金80億円
そして2024年12月、滋賀銀行は日立との間で「次世代基幹系システムの構築計画を中止する」ことで合意したと発表しました。和解金80億円を受け取り、特別利益として計上するという、かなりインパクトのある結末です。日経オンライン+2FinBridge+2
銀行側の説明によると、現行システムは安定稼働しており、2027年1月に更改を予定していること、次の一手については改めて検討するとしています。FinBridge
簡単に言えば、
「無理に新システムを完成させてリスクを取るくらいなら、一度チャラにしてやり直した方がまだマシ」
と判断したわけです。
ベンダー変更と「BankVision on Azure」へのシフト
そこから一歩進んだ最新の動きとして、2025年9月、滋賀銀行はオープン勘定系システム「BankVision on Azure」を次期勘定系の中核として採用すると発表しました。沖縄タイムス＋プラス+1
BankVision on Azureは、地銀向けに共同利用されてきた勘定系「BankVision」をクラウド（Microsoft Azure）上で提供するもので、「自前で一から作る」より、「実績ある共同システムをクラウド化した基盤に乗る」方向へ舵を切ったということになります。
同じ銀行でも、楽天のように“超カスタム新システム”へ突っ込んで迷走したケースと、滋賀銀行のように“途中で止めて共同利用型オープン勘定系へ乗り換える”ケースで、かなり対照的な絵になってきました。
楽天と滋賀銀行に共通する「ハマりがちな落とし穴」
業種も規模も違う2社ですが、見えてくる構造的な要因は案外似ています。
まず一つ目は、“全部を一気に変えようとした”ことです。
楽天は「生損保一体型」という、業界的にもチャレンジングな構想を一度に実現しようとしました。ダイヤモンド・オンライン+1 滋賀銀行も、勘定系という銀行の心臓部を次世代システムに一気に置き換えようとしていました。しがぎん+1 どちらも、段階的なスモールスタートではなく、“フルモデルチェンジ”を狙った結果、要件・テスト・移行の複雑さに飲み込まれた印象があります。
二つ目は、自社の業務の複雑さを過小評価した可能性です。
保険も銀行も、「過去の制度」「商品」「個別対応」の積み重ねで業務がぐちゃぐちゃになりがちです。それをシステム化するために、昔の担当者がCOBOLなどで頑張って書いた結果、「魔改造されたレガシー」が出来上がります。ここを“シンプルな新システム”に乗せ替えるには、「何を捨てるか」を決める痛みが必要なのですが、そこが甘いまま設計に入ると、最終的に要件が膨れあがって破綻しやすくなります。
三つ目は、ベンダー依存とガバナンスの弱さです。
楽天のケースでは、開発ベンダーを強く推した経営陣や、金融庁からの報告徴求命令など、経営とプロジェクト現場の間に相当な温度差があったことが指摘されています。ダイヤモンド・オンライン+1 滋賀銀行のケースでも、日立との契約を途中で打ち切る形になり、最後は和解金という形で決着しました。日経オンライン+1 発注側が「丸投げ」、受注側が「何とかします」と言ってしまい、リスクと責任の分担が曖昧なまま大型案件が走り出す──日本のITプロジェクトでありがちな構図が、ここでも顔を出しています。
同じ失敗を防ぐには？ 日本企業が取るべき現実的な対策
では、これから基幹システム刷新に挑む企業は、何に気をつければいいのでしょうか。
一番大事なのは、“全部を一度に変えない”勇気を持つことだと思います。
家のリノベーションに例えると、家族が住んだまま「骨組みから全部やり直し」をやろうとするから大変になるのであって、「まずキッチンだけ」「次は水回りだけ」とフェーズを分ければ、リスクもコストもコントロールしやすくなります。
滋賀銀行が最終的に、“自前フル構築”ではなく“共同利用型のBankVision on Azureを採用する”方向へ切り替えたのは、そうした現実路線の一つと言えるでしょう。沖縄タイムス＋プラス+1
次に重要なのが、自社業務の“棚卸し”と“あきらめ”です。
レガシーシステムを開いてみると、「昔のキャンペーン専用の条件」「特定の大口顧客だけの特別処理」などが延々と残っていたりします。すべてを新システムに引き継ごうとすると、永遠に終わりません。
「今の時代に不要なものは切り捨てる」「標準機能で対応できる範囲に業務を合わせる」という判断を、経営が腹をくくって行えるかどうかがポイントになります。楽天のように、業務・商品・チャネルすべてを一体で変えようとすると、その覚悟が中途半端だと一気に行き詰まります。楽天ライフ+2新日本インシュアランス+2
三つ目は、契約とプロジェクトガバナンスの設計です。
・「要件定義」「基本設計」「移行計画」などの各フェーズごとに、きちんと“立ち止まって見直す”マイルストーンを作ること。
・ベンダー側だけでなく、発注側にもアーキテクトやPMOを置き、第三者レビューやリスク評価を行うこと。
・うまく行かなかった場合に備えて、出口条件（スコープ縮小・フェーズ分割・契約解消）のルールをあらかじめ決めておくこと。
滋賀銀行は最終的に「中止＋和解」という苦い選択を取りましたが、そこで無理に突っ込まなかったからこそ、BankVision on Azureへの乗り換えという次の一手を打てたとも言えます。日経オンライン+1
最後に、経営のコミットと“地に足のついたDX”です。
楽天の保険システムのように、「業界初」「クラウドネイティブ」「AI活用」といったキラキラしたキーワードは魅力的ですが、足元のレガシーとのギャップを埋める地味な作業こそがDXの本体です。楽天ライフ+2ダイヤモンド・オンライン+2
経営がそこから目をそらしてしまうと、どれだけ予算を投じても、最終的には「頓挫」「中止」「減損」という結果になりかねません。
まとめ
楽天の生損保一体型基幹システム頓挫と、滋賀銀行の次世代勘定系開発中止＆ベンダー変更は、「日本企業の基幹システム刷新がいかに難しいか」を見せつける象徴的な二つの出来事でした。
どちらも“攻めのDX”を掲げてスタートしながら、結果としては大きな損失や遠回りを強いられています。しかし、そこで終わりではなく、滋賀銀行のように現実的な選択肢へ舵を切り直した例も出てきています。沖縄タイムス＋プラス+1
これから同じような刷新に挑む企業にとって大切なのは、「夢」と同じくらい「現実」を直視すること。
全部を一気に変えようとせず、段階的に、そして業務の“断捨離”を伴う覚悟を持って進められるかどうかが、成功と失敗の分かれ目になっていきそうです。
ひとりごと
過去の基幹システムを全部捨てて ERP(Enterprise Resource Planning)を手を加えずに業務をシステムに合わせて変える。
というのが正解です。
また、ERPの導入でも日本企業の多くは、自社の業務を合わせてシステムに手を加えすぎという行為です。
海外との取引のある企業ならば、世界標準のERPを採用し、取引を円滑にする。
中小企業ならば、それこそ そのまま使うことで業界の業務に合わせることがもっともコストのかからない唯一の方法です。
基幹システムを世界標準、業務標準にして、余計なシステム保守にコストをかけず、本業に投資すべき
もっとも「現場の猛反対」は覚悟してください。