レガシーシステム刷新の進め方｜現状把握から移行まで全手順 

【1分でわかるこの記事の要約】

• レガシーシステム刷新とは、老朽化やブラックボックス化による技術的負債を根本から解消する取り組みであり、2026年現在、大企業の74%がレガシーを抱え、富士通メインフレームの2030年製造終了も迫る中、もはや回避できない経営課題となっています。

• 刷新の手法にはリホスト、リライト、リビルド、リプレイスの4つがありますが、いずれを選ぶにしても成否を分けるのは最初のステップである現状把握（ASIS解析）の精度であり、これを省略したプロジェクトは手戻りの連鎖でコストが2〜3倍に膨らむ失敗に陥りがちです。

• AI解析とベテラン技術者の知見を融合させることで、仕様書のないシステムでも従来の1/10のコストと期間で全容を可視化でき、データに基づいた精度の高い刷新計画の策定が可能になります。

「仕様書が存在しない」「担当者が退職して仕様を知る人がいない」——レガシーシステムを抱える企業の多くが、刷新の必要性を感じながらも最初の一歩を踏み出せずにいます。

レガシーシステム刷新とは、老朽化・ブラックボックス化したシステムを新しい技術基盤に移行する取り組みです。 刷新を成功させる鍵は、移行作業そのものではなく、最初のステップである現状把握（ASIS解析）にあります。仕様書がないシステムでも、AIによるコード解析とベテラン技術者の知見を組み合わせれば、全容を可視化したうえで最適な刷新手法を選定できます。

この記事では、レガシーシステム刷新の具体的な進め方を5ステップに分解し、手法の比較から費用・期間の目安、失敗パターンと回避策まで体系的に整理しました。特に、刷新の成否を分ける「現状把握（ASIS解析）」のフェーズについて、AI×ベテラン技術者を活用した具体的な進め方を深掘りします。

レガシーシステム刷新とは？更改・再構築・マイグレーションとの違い

レガシーシステム刷新とは、老朽化・ブラックボックス化した既存システムを、新しい技術基盤やアーキテクチャに移行する取り組みです。単にハードウェアを入れ替える「更改」や、業務ロジックをそのまま別環境に移す「マイグレーション」とは異なり、技術的負債そのものの解消を目的とします。

レガシーシステムの定義と全体像については「レガシーシステムとは？問題点やリスクを詳しく解説」で詳しく解説しています。

用語の使い分け

刷新の文脈では、似た用語が混在して使われがちです。以下で整理します。

なぜ今レガシーシステム刷新が急務なのか

2025年5月、経済産業省は「レガシーシステムモダン化委員会総括レポート」を公表しました。企業の61%にレガシーシステムが残存しており、大企業では74%にのぼるという実態が明らかになっています。

レガシーマイグレーション市場はCAGR 10.0%で成長し、2025年度には5,118億円規模に達しています（デロイト トーマツ ミック経済研究所調べ）。市場の拡大は、それだけ多くの企業が刷新に動いていることの証拠です。

レガシーシステムが企業にもたらすリスクの全体像はレガシーシステムのリスクと評価手法で詳しく解説しています。もう一つ見逃せないのが、富士通メインフレームの撤退スケジュールです。2030年に製造終了、2035年に保守撤退——富士通メインフレーム上でCOBOLを稼働させている企業にとって、刷新は「やるかどうか」ではなく「いつまでにやるか」の問題に変わっています。

可視化の有無がモダナイゼーションの成否を分ける

経産省モダン化委員会総括レポートは、停滞を打破する鍵として「可視化→内製化→モダン化」の3段階を提示しています。注目すべきは、可視化に取り組んでいる企業とそうでない企業の差です。

• 可視化に取り組んでいる企業: IT資産の棚卸し完了率71%

• 情報共有が進んでいない企業: 可視化未実施率66%

刷新プロジェクトの進捗は、「可視化」の有無と直結しています。この記事で「ステップ1：現状把握」を最重要ステップと位置づけているのは、このデータが裏付けています。

レガシーシステム刷新の4つの手法を比較

レガシーシステム刷新の手法は、Gartnerが提唱した「7R」フレームワーク（Retain / Retire / Rehost / Replatform / Refactor / Rearchitect / Rebuild + Replace）で体系的に整理できます。ここでは、日本企業の刷新プロジェクトで特に採用頻度が高い4つの手法に絞って比較します。

リホスト（基盤移行）

同じアプリケーションを新しいインフラ（サーバー・クラウド）に移行する方法です。アプリケーションコードには手を加えないため、コスト・期間・リスクが最も小さい選択肢です。ただし、ソフトウェアの技術的負債はそのまま残ります。ハードウェアの保守切れが差し迫っている場合の「時間稼ぎ」として有効です。

リライト（言語変換）

既存のビジネスロジックを維持しつつ、COBOL→Java、RPG→C#など別言語に書き換える方法です。保守人材の確保が困難になったレガシー言語からの移行で採用されます。

ロジックの正確な移植が最大の課題です。元のコードの仕様が不透明なまま変換を進めると、テスト段階で想定外の不具合が続出するリスクがあります。エイジレスが手がけた富士通メインフレームCOBOL→NetCOBOLのストレートコンバージョンでは、AIで生成したテスト仕様書をTITANS（COBOL経験者6名）が精査・修正し、この課題を解消しました。

リビルド（再構築）

業務要件を再定義し、ゼロからシステムを構築する方法です。自由度は最も高いですが、コスト・期間・リスクもすべて最大です。業務プロセスそのものの見直しが必要な場合に選択されます。

三菱オフコン上のProgress2アプリケーション（5万本超）では、リビルドが選択されました。しかし外部連携部分の仕様がブラックボックス化しており、リビルドだけでは前に進めない——この課題に対し、AIによる全量ASIS解析で仕様を可視化する方法で解決しています。

リプレイス（パッケージ置換）

既存システムをERPなどのパッケージやSaaSに置き換える方法です。標準的な業務プロセスに移行可能な場合に有効ですが、自社固有のカスタマイズが多い場合にはFit & Gap分析が不可欠です。

レガシーマイグレーションの手法についてさらに詳しくは「レガシーマイグレーションの手法と進め方」で解説しています。

手法の選定基準

どの手法を選ぶにしても、「今のシステムが何をしているか」を正確に把握していなければ、精度の高い判断はできません。

レガシーシステム刷新の進め方【5ステップ】

レガシーシステム刷新は、場当たり的に進めると高確率で失敗します。ここでは、刷新プロジェクトを5つのステップに分解し、各フェーズで何をすべきかを具体的に解説します。

ステップ1：現状把握（ASIS解析）で全容を可視化する

刷新プロジェクトの出発点にして最重要ステップです。

対象は全IT資産の棚卸し、既存コードの解析、業務フローの整理です。このステップで作成すべき成果物は、IT資産台帳、復元された仕様書、システム間連携図——これらがなければ、後続のステップはすべて砂上の楼閣になります。

問題は、仕様書が存在しない、あっても10年以上前の情報で使い物にならない、というケースが大半を占めることです。この場合、ソースコードから仕様を復元するASIS解析（As-Is解析）が必要になります。具体的な進め方は次のセクションで詳しく解説します。

仕様がわからないシステムの現状把握でお困りの方は、AIを活用したASIS解析を検討してみてください。

無料相談はこちら

ステップ2：優先順位をつけ刷新計画を策定する

現状把握の結果をもとに、刷新の優先順位を決定します。判断軸は「ビジネスインパクト」と「技術リスク」のマトリクスです。

• ビジネスインパクト: そのシステムが止まった場合の事業損失の大きさ

• 技術リスク: ハードウェアの保守期限、担当者の退職リスク、セキュリティ脆弱性の深刻度

ロードマップは90日・180日・365日の3段階で作成し、短期的な成果（クイックウィン）を早期に出す設計にします。経営層への報告材料として、投資対効果（ROI）の試算も含めます。

ステップ3：刷新手法を選定し体制を構築する

ステップ1の解析結果とステップ2の優先順位に基づき、前セクションの比較表を参考に手法を選定します。

体制構築で最大のボトルネックになるのが、レガシー言語に精通した人材の確保です。COBOL・RPG・PL/Iなどの技術者は年々減少しており、社内で確保できない場合は外部のベテラン人材を活用する必要があります。

ステップ4：段階的に移行を実行する

移行方式は、全システムを一括で切り替える「ビッグバン方式」と、モジュール単位で段階的に切り替える「段階移行方式」の2つがあります。リスクを抑えるなら段階移行方式が推奨されます。

移行期間中は新旧システムの並行運用が必要です。データ移行では、移行前後のデータ整合性の検証が特に重要になります。

ステップ5：テスト・検証・運用定着

単体テスト→結合テスト→業務テスト→負荷テストを段階的に実施します。移行判定基準を事前に設定しておき、基準を満たさない場合のロールバック計画も用意します。

移行後の運用マニュアル整備と関係者への引き継ぎも、このステップに含まれます。刷新は「移行して終わり」ではなく、新システムが安定稼働するまでがプロジェクトです。

刷新の成否を分ける「現状把握」の具体的な進め方

5ステップの中で、特に刷新の成否を左右するのがステップ1の現状把握です。ここからは、その具体的な進め方を深掘りします。

なぜ現状把握なしの刷新は失敗するのか

仕様書がないまま刷新に着手し、テスト段階で「動かない」「データが合わない」が続出する。手戻りの連鎖で期間とコストが膨れ上がり、最終的にプロジェクトが頓挫する——これは刷新プロジェクトで繰り返される典型的な失敗パターンです。

その原因は明確です。長年のツギハギ改修で構造が複雑化したレガシーシステムでは、修正の影響範囲が予測困難になっています。「このプログラムを修正すると、別のどのプログラムに影響するか」を正確に把握できない状態で移行設計を行えば、前提そのものが崩れます。

AIを活用したコード解析・仕様書自動生成

2026年現在、生成AIを活用したレガシーコード解析が実用化段階に入っています。NTTデータの「tsuzumi for COBOL」、富士通の「Fujitsu PROGRESSION」、CTCの「re:Modern」など、大手SIerもAI解析ツールの提供を始めています。

AIによるコード解析では、プログラム構造の可視化、処理フローの抽出、依存関係の分析、仕様書の自動生成が可能です。COBOL・RPG・PL/I・アセンブラといったレガシー言語にも対応しており、従来のベテラン技術者による人海戦術と比較して、1/10のコスト・1/10の期間で解析を完了できるケースが出ています。

ただし、AIには限界があります。AIはコードの構造やロジックを読み解けますが、「なぜそのロジックが存在するのか」——すなわち、業務的な意図までは読み解けません。

ベテラン技術者の暗黙知を活かすアプローチ

「このIF文は、20年前に特定の取引先から要望があって追加された例外処理」「この変数名は当時の担当者の命名規則で、こういう意味」——こうした暗黙知は、長年そのシステムに携わってきたベテラン技術者の頭の中にしかありません。

AIの解析結果をベテラン技術者が検証し、業務知識で補完する「AI × ベテラン融合」のアプローチが、精度と速度を両立する方法です。

エイジレスでは、独自AI「ARIADNE」と精鋭部隊「TITANS」（22,000名超のDBから上位1.3%を厳選した300名、平均年齢57歳）がこの融合を実現しています。富士通メインフレーム上のCOBOLアプリケーション（ストレートコンバージョン案件）では、ARIADNEが生成したテスト仕様書と保守ドキュメントをTITANS（COBOL経験者6名）が精査・修正し、SIerや保守ベンダーとの折衝まで担当しました。三菱オフコンのProgress2アプリケーション（5万本超）では、「人手による解析は不可能」と判断されていたシステムに対し、AIで全量ASIS解析を実施。P2言語を読めるエンジニアが業務ヒアリングと並行してAI出力を照合し、仕様書に落とし込みました。

「攻めの資料」と「守りの資料」

ASIS解析の成果物は、目的に応じて2つの方向性に分かれます。

• 攻めの資料（DX検討用）: 要件定義書など。刷新後の新システム設計に使う資料です。「これからどうするか」を決めるための土台になります

• 守りの資料（保守用）: 詳細設計書、テスト仕様書など。現行システムの安定運用に使う資料です。「今のシステムを正しく動かし続ける」ための材料になります

同じASIS解析の結果から、目的に応じた形式で成果物を生成できる点が、このアプローチの強みです。「守りの資料」による保守改善の具体策はレガシーシステム保守の課題と解決策で解説しています。

「ベテランが辞めたら誰もわからない」——そんなレガシーシステムの課題、まずは現状把握から始めませんか？

ASIS解析の資料をダウンロード

レガシーシステム刷新の費用・期間の目安

レガシーシステム刷新の費用と期間は、対象システムの規模と選択する手法によって大きく変わります。ここでは手法別の目安と、見積精度を左右する要素を整理します。

手法別の費用・期間比較

※上記は一般的な参考値です。規模・複雑度・ベンダーにより大幅に変動します。

費用・期間を左右する5つの要素

1. 対象システムの規模（プログラム本数、ステップ数）

2. レガシー言語の種類（COBOL / RPG / PL/I / アセンブラ）

3. 仕様書の有無（ない場合、ASIS解析コストが追加される）

4. 外部連携の数と複雑度（EDI接続先、他システムとの連携箇所数）

5. 並行運用期間の長さ（新旧システムの同時稼働期間）

見積精度を高めるためのASIS解析

「仕様がわからない状態での見積」と「ASIS解析後の見積」では、精度が根本的に異なります。仕様が不透明なまま作成した見積は、プロジェクト進行中にスコープが変動し、最終的なコストが当初見積の2〜3倍に膨らむケースがあります。

ASIS解析を先に実施することで、対象システムの正確な全容（プログラム本数、依存関係、複雑度）が判明し、手法の選定と見積の精度が格段に向上します。可視化の具体的な手法はレガシーシステムの可視化手法と進め方も参照してください。AI活用により、ASIS解析自体も従来の1/10のコスト・1/10の期間で実施可能です。数万本規模のプログラムでも約1ヶ月で完了した実績があります。

レガシーシステム刷新の失敗パターンと回避策

レガシーシステム刷新はプロジェクトの難易度が高い分、失敗リスクも無視できません。ここでは、繰り返される3つの典型的な失敗パターンと、その回避策を解説します。

失敗パターン1：現状把握の不足による手戻り

ASIS解析を省略または簡略化して移行に着手した結果、テスト段階で「動かない」「データが合わない」が続出。手戻りの連鎖で期間とコストが当初計画を大幅に超過するパターンです。

回避策: 刷新予算にASIS解析コストを含め、「省略して良い工程」ではなく「プロジェクトの成否を決める工程」と位置づける。仕様書がない場合はAIを活用したコード解析を検討する。

失敗パターン2：「業務改革なき刷新」の罠

技術基盤だけ新しくして業務プロセスを据え置いた結果、新システムに旧い業務ロジックをそのまま移植。「使い勝手が変わらない」「投資効果が見えない」と経営層から批判されるパターンです。

回避策: 刷新と業務プロセスの見直しをセットで計画する。ASIS解析で現状を把握するだけでなく、To-Be（あるべき姿）の業務設計も同時に進める。「攻めの資料」（要件定義書）を成果物に含めることで、この罠を回避できます。

失敗パターン3：人材不足によるプロジェクト停滞

COBOL・RPG・PL/Iなどのレガシー言語を読めるエンジニアが確保できず、現行システムの解析が進まない。プロジェクト全体が停滞するパターンです。

回避策: 社内ベテラン技術者の知見を退職前に早期に引き出す。AIによるコード解析で人手への依存度を下げる。社内だけで対応が困難な場合は、レガシー言語に精通した外部の専門人材を活用する。22,000名超の人材DBから上位1.3%を選抜した300名規模の精鋭組織を持つベンダーも存在します。

成功企業に共通する3つの要素

1. 現状把握（ASIS解析）を省略しなかった — 最初の工程に十分な時間とコストをかけた

2. 経営層のコミットメントがあった — トップダウンの方針と現場ボトムアップの知見の両輪で推進

3. 段階的な移行で小さな成功体験を積み上げた — ビッグバンではなく、モジュール単位で成果を出しながら進行

レガシーシステム刷新に関するよくある質問（FAQ）

Q1. レガシーシステム刷新と基幹システム刷新の違いは？

レガシーシステム刷新は、COBOL/メインフレーム等のレガシー技術に起因する技術的負債の解消が主眼です。基幹システム刷新は、ERP導入や業務プロセス改革など業務システム全体の更新が主眼です。両者が重複するケースもありますが、起点となる課題が異なります。

Q2. レガシーシステム刷新の費用はどのくらいかかりますか？

手法・規模により数百万〜数十億円と幅があります。正確な見積にはASIS解析が有効で、AI活用により従来の1/10のコストで現状把握を実施できるケースもあります。詳しくは「費用・期間の目安」をご覧ください。

Q3. 仕様書がないシステムでも刷新できますか？

可能です。AIによるコード解析でソースコードから仕様を復元するアプローチがあります。ベテラン技術者の知見と組み合わせることで、業務意図まで含めた正確な仕様書を生成できます。詳しくは「現状把握の具体的な進め方」をご覧ください。

Q4. COBOL/RPGのシステムを刷新するにはどうすればよいですか？

まずASIS解析で現在のコードの仕様を正確に把握します。そのうえで、リライト（Java/C#等への言語変換）かリホスト（基盤移行）を選択するのが一般的です。2026年時点ではAIによるコード変換ツールの実用化も進んでいます。

Q5. 刷新中に業務が停止するリスクは？

段階的な移行方式と新旧システムの並行運用により、業務停止リスクを最小化できます。ビッグバン方式（一括切替）よりも段階移行方式が推奨されます。十分なテスト期間の確保も不可欠です。

Q6. リホスト・リライト・リビルド・リプレイスのどれを選ぶべきですか？

目的と現状によります。基盤だけの問題ならリホスト、言語の問題ならリライト、抜本的刷新ならリビルド、標準パッケージで済むならリプレイスが適しています。ASIS解析の結果に基づいて判断するのが最も精度の高い方法です。詳しくは「4つの手法を比較」をご覧ください。

Q7. 刷新プロジェクトの期間はどのくらいですか？

規模と手法により3ヶ月〜3年と幅があります。リホストは短期（3〜6ヶ月）、リビルドは長期（1〜3年）が目安です。ASIS解析のフェーズはAI活用により従来の1/10の期間で完了する手法もあります。

Q8. 社内で刷新の予算を確保するにはどうすればよいですか？

ASIS解析の結果をもとに「現状維持コスト（TCO）」と「刷新コスト」を定量的に比較する資料を作成することが有効です。経営層には「やらないリスク」——保守コストの増大、人材枯渇、事業機会の損失——を数字で示します。

まとめ：レガシーシステム刷新は「現状を知る」ことから始まる

この記事のポイントを整理します。

• レガシーシステム刷新は「更改」「マイグレーション」とは異なり、技術的負債の根本的な解消を目的とする取り組み

• 手法は4つ（リホスト / リライト / リビルド / リプレイス）。自社のシステム状況に応じた選定が重要

• 刷新を成功させる鍵は、移行作業そのものではなく、最初のステップである現状把握（ASIS解析）にある

• 仕様書がないシステムでも、AI × ベテラン技術者の融合アプローチで全容を可視化できる

• 失敗を防ぐには「現状把握の徹底」「業務改革との両立」「レガシー言語人材の確保」の3点を押さえる

レガシーシステムの仕様が不透明で刷新の第一歩を踏み出せない方は、まずASIS解析で現状を可視化することから始めてみてください。

従来の1/10のコストで、レガシーシステムを可視化。22,000名超の人材DBから厳選した上位1.3%の精鋭が対応します。

無料相談はこちら ｜ 資料をダウンロード

関連記事

• レガシーシステムの定義と7つのリスクを詳しく解説

• レガシーマイグレーションの手法と進め方