【2026年版】レガシーシステムをAIで改修した事例8選｜COBOL・基幹システムの実名事例を紹介
レガシーシステムの改修に生成AIを使った国内の実名事例は、その中でも多く公表されているものが「金融」関連です。2025年から2026年にかけて日本IBMや富士通が公表した事例は、明治安田生命・三井住友銀行・ソニー銀行・JCBと、保険と銀行とカードに集中しています。
一方でシステム改修を考えているが、「基幹システムを触れる人がいない」、「仕様書が残っていない」という悩みは業種を問いません。
この記事では、2025〜2026年に公表された実名事例8件を、国内6件・国外2件に分けて紹介します。あわせて、AI事例として紹介されがちな「自動変換ツールによる移行」との見分け方も書きます。仕様書が残っていないシステムの読み解き方そのものは、仕様書がないシステムを改修する手順で扱っています。
目次
- レガシー改修でAIが効いているのは3つの工程
- 国内の事例6選｜2025〜2026年に公表されたもの
- 「AIで移行した」と紹介される事例の見分け方
- 国外の事例2選｜先行しているのは銀行と製造業
- 8件を並べて分かること
- 自社で始めるときの3ステップ
- レガシー資産の改修を検討するなら、スパイクスタジオへご相談ください
レガシー改修でAIが効いているのは3つの工程
公表されている事例を並べると、AIが担っている作業は次の3つに集中しています。逆にいえば、システムをまるごと置き換える用途で使われている例は、国内ではまだ確認できません。
- 既存コードの解析と仕様の復元｜何をしているコードかを文章で出す。仕様書が無い部分の穴埋めに使う
- 設計書とコードの生成｜復元した仕様をもとに、内部設計書やソースコードを書かせる
- テストケースの生成｜移行前後で同じ結果になるかを確かめるテストを作らせる
効果として公表されている数字も、この3工程に対応しています。明治安田生命は内部設計・コーディング・単体テストの一連作業で約25%の効率化を公表しました（日本IBM・明治安田生命 共同リリース、2025年3月）。三井住友銀行のシステムでは、OS更新にともなう非互換の調査時間が約65%削減されました（実証は日本総合研究所と富士通。富士通・日本総合研究所 共同リリース、2025年1月）。ブラジルのItaú Unibancoは、メインフレームアプリの調査とテストの時間を90%超削減したと発表しています（AWS公式ブログ、2026年2月）。
順序にも共通点があります。いきなりコードを変換させるのではなく、まず解析させて仕様を人が確定し、そのあとで生成に進んでいます。仕様が固まらないまま生成に入ると、出てきたコードが正しいかどうかを誰も判定できなくなるためです。
国内の事例6選｜2025〜2026年に公表されたもの
ここからは1件ずつ、対象システム・使った工程・公表された数字の順に紹介します。数字が公表されていないものは、その旨をそのまま書いています。
①保険の改修事例｜明治安田生命が設計からテストまでを生成AIで連携し約25%効率化
明治安田生命は2025年3月、日本IBMとともにメインフレーム上のCOBOLシステムの開発工程に生成AIを適用した結果を公表しました。対象は個人保険システムや企業保険システムの実業務の成果物です。
やり方は工程の連結でした。生成AIで内部設計書を作り、それを入力として生成AIにコーディングさせ、さらに単体テストケースを作らせる。この一連の作業で約25%の効率化を実現したとしています。あわせて、要件定義から外部設計、テストまでの追跡可能性の確認にも生成AIを使っています。2025年4月からは実業務でのパイロット運用に入りました。
②銀行の改修事例｜三井住友銀行のシステムでOS更新の非互換調査を約65%短縮
日本総合研究所と富士通は2025年1月、三井住友銀行のシステムを対象にした共同実証の結果を公表しました。対象はRHEL（Red Hat Enterprise Linux）のバージョンアップにともなう非互換への対応です。三井住友銀行は実証の対象で、発表主体は日本総合研究所と富士通です。
C言語とシェルスクリプトで書かれた約380キロステップのアプリケーションに対し、生成AIで非互換の箇所を抽出させました。検証期間は2024年11月5日から2025年1月15日まで。抽出された非互換情報は約400個で、抽出にかかる時間は約65%削減されています。基幹システムそのものの書き換えではなく、更新のたびに発生する調査作業をAIに寄せた例です。
③銀行の改修事例｜ソニー銀行が新勘定系の機能開発に生成AIを適用
ソニー銀行は2025年10月、富士通の勘定系ソリューション「Fujitsu Core Banking xBank」を採用した新勘定系システムの機能開発に、生成AIの適用を始めたと発表しました。適用開始は2025年9月です。
使われているのは、富士通独自のナレッジグラフで拡張したRAG（検索拡張生成。社内の資料を検索してAIの回答の根拠にする仕組み）です。2026年4月までに全機能の開発へ広げる計画で、開発期間の20%短縮を目指すとしています。この20%は目標値であり、実績値ではありません。
④カード会社の改修事例｜JCBが設計からテストまでにwatsonxを組み込み約20%効率化
ジェーシービー（JCB）は2025年12月、日本IBMとのAIパートナーシップを公表しました。対象は国内外の主要業務を支える複数の基幹システムです。
生成AI「watsonx」を設計からテストまでの全工程に組み込んでいます。具体的には、外部設計書からプログラム設計書とCOBOLコードを生成させること、単体テストケースを網羅的に生成させることなどです。一部のシステムでは、設計からテストの工程で約20%の開発効率化を達成したとしています。
⑤保険システム子会社の改修事例｜東京海上日動システムズが生成コードの95%以上で動作
東京海上日動システムズは、オンプレミスやAmazon EC2上で動いていたレガシーなJavaのモノリシックアプリケーション（機能が1つの塊になっているアプリ）を、AWS Lambda中心のサーバーレス構成に作り替える検証を行いました。
使ったのはAmazon Bedrock上のClaude 3.5 Sonnetです。既存コードの構造解析、REST APIの定義、バックエンドとフロントエンドのコード生成をAIが担当しました。検証用の小規模アプリケーションを対象としたPoCでは、95%以上が生成AIの作ったコードで動作しています。COBOLではなくJava資産が対象という点で、他の事例とは毛色が違います。
出典AWS公式ブログ（東京海上日動システムズとの共同執筆）（2025年1月28日）
⑥製造業の改修事例｜トヨタシステムズがCOBOL未経験者で基幹開発を回す体制を作った
トヨタシステムズは2025年11月、日本IBMと共同開発した生成AIツール「TG4X（Toyota Systems GenAI for DX）」と、2025年10月に設立した「レガシーコードラボ」を公表しました。対象はトヨタグループの基幹業務システムで、COBOLとPL/Iで構築されています。
狙いは工数の削減ではなく、担い手の確保です。レガシー言語での開発経験がない次世代人材が、TG4Xを使ってCOBOLやPL/Iのコードと仕様を理解し、基幹システムの開発を進める体制を作りました。このリリースでは、削減率などの数字は示されていません。国内の非金融では、生成AIをレガシー改修に使った実名事例そのものが今のところ少なく、この1件が数少ない公表例です。
「AIで移行した」と紹介される事例の見分け方
事例を集めるときに一番つまずくのがここです。COBOLからJavaへの移行事例は数多く公表されていますが、その多くは生成AIではなくルールベースの自動変換ツールによるものです。まとめ記事では、この2つが区別されないままAI事例として並んでいることがあります。
たとえば日本航空（JAL）のマイレージ関連データ連携システムの移行は、AI事例として紹介されることがあります。実際には、TISの自動変換ツール「Xenlon〜神龍 Migrator」によるCOBOLからJavaへのリライトです。TISの公式リリースは一貫して「リライトツール」「変換ツール」と説明しており、AIという語は使われていません。移行そのものは2023年8月から2024年3月までの8か月で完了し、業務トラブルはゼロと発表されています（TIS ニュースリリース、2025年5月23日）。成果としては十分ですが、AIで移行した事例ではありません。
国外にも同じ形の例があります。ING Bankは、メインフレーム上で動いていた約150万行のCOBOL資産（CICS・DB2・JCLのバッチを含む）をJavaに刷新し、2022年2月からLinux上で本番稼働させました。検証では約20億件のトランザクションを照合しています。ただしこの移行に使われたのはSoftwareMining社の自動変換ツールで、生成AIではありません（SoftwareMining 事例ページ）。AIが出てくるのは移行後の話で、同行のCOO兼チーフ・トランスフォーメーション・オフィサーであるMarnix van Stiphout氏は2025年7月のインタビューで、AIを活用したツールによって、レガシーコードの透明性を高めたり、より効果的な保守を可能にしている。また、全体としてモダナイゼーションの取り組みを加速したりすることで、開発者の生産性は大きく向上すると述べています（McKinsey インタビュー、2025年7月）。これは全社的な方針としての発言です。先に自動変換で移行を終え、そのあとAIを解析と保守に回すという順序で進めた事例です。
どちらが優れているという話ではありません。仕様が明確で量が多いものは自動変換ツールのほうが速く、確実です。生成AIが効くのは、仕様が分からない部分の解読や、設計書とテストを作り直す作業です。他社事例を自社の判断材料にするなら、次の3つを確かめてください。
- 発表元の一次情報に「生成AI」「LLM」の語があるか（まとめ記事ではなく公式リリースで確かめる）
- AIを使ったのはどの工程か（解析なのか、コード生成なのか、テストなのか）
- 数字が実績値か目標値か（「〜を目指す」は目標値です）
国外の事例2選｜先行しているのは銀行と製造業
国外では、AIによる解析とテストの自動化を組み合わせた大規模な移行が公表されています。国内より対象規模が大きく、数字も具体的です。
⑦ドイツ｜Mercedes-BenzがCOBOL130万行をJavaへ、6か月未満で障害ゼロの稼働
Mercedes-Benzは2025年12月のre:Inventで、メインフレーム上のグローバル受注システムの刷新を発表しました。AWS上で生成AIとエージェント型のリファクタリングを使い、約130万行のCOBOLをJavaに変換しています。
最初のコミットから本番稼働まで6か月未満で、障害ゼロでの切り替えを達成したとしています。対象は受注システムで、止められない業務での実績です。
⑧ブラジル｜Itaú Unibancoが調査とテストを90%超削減し、50年前の基盤を作り替えた
ラテンアメリカ最大の銀行であるItaú Unibancoは、メインフレームアプリケーションの調査とテストの工程を自動化し、調査・テスト時間を90%超削減、モダナイゼーション自体も手作業比で75%高速化したと公表しています。
別のプロジェクトでは、50年前から動いていた明細照会の基盤をクラウドネイティブな構成に作り替えました。運用コストは約80%減、応答時間は2秒から191ミリ秒に短縮され、7000万人の顧客に対応しています（AWS公式ブログ、2026年5月）。
8件を並べて分かること
公表された事実だけを並べると、次のようになります。数字が無い事例は空欄です。
| 企業・団体 | 対象 | AIを使った工程 | 公表された数字 |
|---|---|---|---|
| 明治安田生命 | COBOL基幹 | 設計・コーディング・単体テスト | 約25%効率化 |
| 三井住友銀行（実証は日本総合研究所・富士通） | C・シェル 約380キロステップ | 非互換の抽出 | 抽出時間 約65%削減 |
| ソニー銀行 | 新勘定系 | 機能開発 | 開発期間20%短縮（目標値） |
| JCB | 複数の基幹システム | 設計〜テスト | 約20%効率化（一部のシステム） |
| 東京海上日動システムズ | レガシーJavaアプリ | 解析・API定義・コード生成 | 生成コードの95%以上が動作（小規模アプリのPoC） |
| トヨタシステムズ | COBOL・PL/I基幹 | コードと仕様の理解 | — |
| Mercedes-Benz | COBOL 約130万行 | 変換・リファクタリング | 6か月未満・障害ゼロ |
| Itaú Unibanco | メインフレームアプリ | 調査・テスト | 90%超削減・75%高速化 |
共通点は3つあります。
1つ目は、効果が出ているのが工程の一部だという点です。国内6件はすべて設計・調査・テストといった工程単位で、システム全体をAIで置き換えたと発表しているのは国外のMercedes-Benzの1件だけです。
2つ目は、公表されている実績値が工程によって幅がある点です。実績値として公表されているのは約25%（明治安田生命、内部設計から単体テストまで）・約65%（三井住友銀行のシステムでの非互換調査）・約20%（JCB、一部のシステム）の3件です。この3件では、設計から実装までを含む工程が20%台、調査だけに絞った工程が約65%でした。
3つ目は、対象を先に絞っていることです。全面刷新ではなく、非互換の調査、単体テスト、明細照会といった単位で切り出されています。
自社で始めるときの3ステップ
事例の進め方を、自社に置き換えられる形に落とします。
まず、対象を「変更頻度が高く、仕様が分からない」部分に絞る
最初から全面刷新を狙うと、判断すべきことが多すぎて止まります。三井住友銀行のシステムでの実証が非互換の調査に、Itaú Unibancoが明細照会に絞ったように、単位を小さく取ります。
実践ポイント
直近1年の改修依頼の件数を、システムの機能単位で数えてください。件数が多く、担当できる人が1人しかいない機能が最初の候補です。使われていない機能に手を入れても効果は出ません。
次に、変換ではなく解析から入る
いきなりコードを書き換えさせず、まず「このコードは何をしているか」を文章で出させます。ここで出た説明を、現場の担当者が読んで直す。この工程が仕様書の代わりになります。手順の組み立て方は仕様書がないシステムを改修する手順で扱っているので、この記事では事例に共通する順序だけを示します。
実践ポイント
明治安田生命は内部設計書の生成から、トヨタシステムズはコードと仕様の理解から入っています。どちらも解析が起点です。まず1機能を選び、AIが出した処理の説明を現場の担当者が読める日本語で受け取るところまでを試してください。
最後に、テストを先に作る
明治安田生命もJCBも、単体テストの生成を工程に組み込んでいます。AIの出力を人が検証できる状態を先に作るという順序です。テストが無いままコードを生成させると、確認の工数が増えて元が取れません。
実践ポイント
移行前のシステムに実データを流し、入力と出力の組を記録してください。移行後に同じ入力で同じ出力になるかを比べる形にすれば、仕様書が無くても検証できます。
どこから切り出すか、自動変換ツールと生成AIのどちらを使うかは、コードを見ないと決められません。既存システムのどこからAIを使えるかを相談することができます。対象の切り出し方から一緒に整理します。
レガシー資産の改修を検討するなら、スパイクスタジオへご相談ください
スパイクスタジオのAIモダナイゼーションは、既存システムを読み解いて動かせる状態に戻すところから支援します。
- 既存コードの解析と、仕様書が無い部分の仕様の復元
- 移行の対象範囲と、自動変換ツールと生成AIの使い分けの設計
- 移行前後の動作を比べるテストの整備
- 改修を続けられる体制づくり（AI人材育成と組み合わせた進め方）
「どこから手を付けるべきか分からない」「そもそも自社の資産量が分からない」という段階でも構いません。現状の整理からご一緒します。レガシーシステムの改修についてスパイクスタジオに相談する