レガシーシステム刷新戦略｜リホスト・リプラットフォーム・リビルドの選び方

「基幹システムの保守を担当できるエンジニアが社内に2名しかおらず、1名が来年定年退職を迎える」——2026年の今、こうした切迫した相談が後を絶ちません。経済産業省が2018年に「2025年の崖」として警鐘を鳴らしたレガシーシステム問題は、多くの企業にとって「いつか対処すべき課題」から「今すぐ着手しなければ事業継続が危うい経営課題」へと変わっています。

COBOLで書かれた数十万行の基幹システム、サポートが終了した旧ERPパッケージ、属人化したスクリプトの集合体として動き続ける業務システム。これらの刷新には、システムの現状に応じた正しいアプローチの選択が不可欠です。

本記事では、リホスト・リプラットフォーム・リビルドの3つの刷新アプローチの比較と選び方、AI活用による移行加速、3つの失敗パターン、そしてストラングラーパターンの実践的な適用方法を解説します。技術負債の全体像については技術負債の解消アプローチもあわせてご覧ください。

この記事で分かること

• 「2025年の崖」の2026年現在の実態と、レガシーシステムが事業に与える4つのリスク
• リホスト・リプラットフォーム・リビルドの比較と選定フレームワーク
• AIを活用したレガシーコード解析・移行の加速手法
• 刷新プロジェクトの典型的な3つの失敗パターンと回避策
• ストラングラーパターンによる段階的移行の実践手順

「2025年の崖」— 2026年の現実

経済産業省のDXレポートが指摘した「2025年の崖」とは、老朽化・複雑化・ブラックボックス化したレガシーシステムが残存した場合に、2025年以降、年間最大12兆円の経済損失が生じる可能性があるという警告でした。2026年の今、この警告は多くの企業で現実のものとなっています。

リスク1: 保守人材の枯渇

COBOLやRPG、PL/Iなど、レガシー言語を扱えるエンジニアの高齢化と退職が加速しています。2026年時点でCOBOL技術者の平均年齢は60歳を超えており、新たにこれらの言語を習得する若手エンジニアはほとんどいません。

人材紹介会社を通じてCOBOLエンジニアを採用しようとしても、単価の高騰と人材プールの縮小により、採用は年々困難になっています。「保守できる人がいなくなる前に刷新する」というのは、もはや猶予のない期限付きの課題です。

リスク2: IT予算の硬直化

古いシステムの保守・運用にIT予算の7〜8割が消費され、新規の投資に回す余裕がなくなる「守りのIT」状態に陥る企業が多く見られます。DXを推進したくても、レガシーシステムの保守コストが足かせとなり、新しい取り組みに踏み出せないという悪循環です。

リスク3: ビジネスアジリティの喪失

市場環境の変化に合わせて業務ロジックを変更したくても、レガシーシステムの複雑な依存関係と影響範囲の不透明さが障壁になります。「1つの項目を追加するだけで数カ月かかる」「仕様変更の影響範囲が分からないので手を付けられない」といった状況は、競争力の低下に直結します。

リスク4: セキュリティの脆弱性

サポートが終了したOS・ミドルウェア・データベース上で稼働するシステムは、セキュリティパッチが提供されません。既知の脆弱性が放置された状態は、サイバー攻撃の格好の標的です。個人情報漏洩や業務停止のリスクを抱え続けることになります。

3つの刷新アプローチ — 体系的な比較

レガシーシステムの刷新には、大きく分けてリホスト・リプラットフォーム・リビルドの3つのアプローチがあります。それぞれの特徴を正しく理解し、自社の状況に合ったアプローチを選択することが成功の前提条件です。

リホスト（Rehost）— インフラだけを入れ替える

既存のアプリケーションにほぼ手を加えずに、実行環境を新しいインフラ（クラウドIaaS等）に移行するアプローチです。「リフト&シフト」とも呼ばれます。

適しているケース: ハードウェアのEOL（End of Life）やデータセンターの廃止が喫緊の課題で、アプリケーション自体は安定稼働している場合。「まずインフラだけ延命し、アプリケーションの刷新は次のフェーズで」という段階的な戦略にも有効です。

見落とされがちなリスク: リホスト後のクラウド環境で、オンプレミス時代と同じ運用コストが発生するケースがあります。クラウドのメリット（オートスケーリング、マネージドサービス等）を活かすアーキテクチャになっていないため、「クラウドに移したのにコストが下がらない」という状況に陥りやすい点に注意が必要です。

リプラットフォーム（Replatform）— 基盤を最適化する

アプリケーションの基本的なアーキテクチャは維持しつつ、データベース・ミドルウェア・ランタイム環境を最新のものに置き換えるアプローチです。

適しているケース: ビジネスロジック自体は有効だが、基盤技術（データベースエンジン、アプリケーションサーバー、フレームワーク等）が陳腐化している場合。Oracle DatabaseからPostgreSQLへの移行、Java EEからSpring Bootへの移行などが典型例です。

見落とされがちなリスク: 基盤の置き換えに伴い、アプリケーションコードの修正が想定以上に広範囲に及ぶケースがあります。「データベースを変えるだけ」と見積もっていたのに、SQL方言の違いやストアドプロシージャの移行で工数が膨らむパターンは非常に多いです。

リビルド（Rebuild）— ゼロから再構築する

既存システムの業務要件を踏まえつつ、最新の技術スタックとアーキテクチャでゼロから再構築するアプローチです。マイクロサービスアーキテクチャやクラウドネイティブ設計を採用し、将来の変更に柔軟に対応できる基盤を構築します。

適しているケース: 現行システムのアーキテクチャが根本的に時代遅れで、ビジネス要件も大幅に変化している場合。「今のシステムを延命するよりも、未来のビジネスに合わせて作り直す方が合理的」と判断できる場合に選択します。

見落とされがちなリスク: 「現行の全機能を再構築する」と定義した瞬間に、プロジェクトの規模は肥大化します。現行システムには10年以上かけて蓄積された業務ロジックが存在し、ドキュメント化されていない暗黙の仕様も含まれます。完全な再現を目指すと、期間・コストともに当初見積もりの2〜3倍に膨らむことが珍しくありません。

選定フレームワーク

判断軸	リホスト	リプラットフォーム	リビルド
緊急度	高（即時対応）	中（半年〜1年）	低（中長期計画）
予算規模	小（数百万円〜）	中（数千万円〜）	大（数千万〜億円）
技術負債の深刻度	低（インフラが主）	中（基盤技術が主）	高（全面的に深刻）
ビジネス要件の変化	小さい	中程度	大きい
期間	数カ月	半年〜1年	1〜3年
リスク	低	中	高

AI活用によるレガシー刷新の加速

2026年のレガシーシステム刷新では、AIの活用が移行の速度と品質を大幅に向上させています。

レガシーコードの自動解析とドキュメント化

ドキュメントが不足した（あるいは存在しない）COBOLコードの処理フローやビジネスロジックを、AIが自動的に解析・文書化できます。数万行のコードを人手で読み解く作業が、数日〜数週間から数時間〜数日に短縮されるケースも報告されています。

特に有効なのは、AIによる「暗黙の仕様」の発見です。コメントもドキュメントも存在しないが、特定の条件で特殊な処理が行われるロジック——こうした暗黙の仕様は人手のコードレビューでは見落とされやすいですが、AIによる網羅的な解析で発見できる可能性があります。

コード変換の支援

COBOLからJava、Python、C#へのコード変換をAIが支援します。2026年時点では完全な自動変換は依然として困難ですが、変換のたたき台を生成し、エンジニアがレビュー・修正するワークフローにより、手作業での書き直しと比較して移行速度が大幅に向上します。

AIコーディングツールの活用方法についてはAIコーディングで開発速度は上がるのかも参考にしてください。

テストケースの自動生成と回帰テスト

既存システムの入出力パターンを分析し、移行後のシステムで同等の動作を検証するためのテストケースを自動生成します。特に回帰テストの網羅性が向上し、「移行したら動かなくなった」というリスクを大幅に低減できます。

既存システムの本番データ（匿名化処理済み）をAIに入力し、テストシナリオとテストデータを自動生成する手法は、テスト工程の工数を半減させた事例もあります。

3つの失敗パターンと回避策

レガシーシステム刷新プロジェクトの失敗には共通するパターンがあります。以下の3つを事前に理解し、対策を講じることが重要です。

失敗パターン1: ビッグバン移行による全面停止

旧システムを一度に新システムへ全面切り替えする「ビッグバン移行」は、最もリスクの高いアプローチです。切り替え時にデータ不整合、性能問題、未検出のバグが一斉に顕在化し、業務全体が停止する事態に陥るケースが少なくありません。

切り戻しの判断基準が曖昧なまま切り替えを実行し、「問題が発生したが旧システムにも戻れない」という最悪の状況に追い込まれた事例もあります。

回避策: ストラングラーパターン（後述）を採用し、機能単位で段階的に移行します。1つの機能を切り替えて安定稼働を確認してから次の機能に進むことで、問題の影響範囲を限定し、切り戻しも容易になります。

失敗パターン2: 現行踏襲の罠 — 使われない機能の再実装

「現行のすべての仕様をそのまま再現する」を目標にしたリビルドは、過剰なコストと長期化を招きます。現行システムには、法改正前の旧ロジック、実験的に追加されたまま使われていない機能、当時のハードウェア制約に起因する非効率な処理など、刷新時に不要な機能が大量に含まれていることが一般的です。

ある製造業の基幹システム刷新では、現行の全機能を棚卸しした結果、実際に日常的に使用されている機能が全体の40%に過ぎなかったという事例もあります。

回避策: 刷新前に業務プロセスの棚卸しを徹底し、「本当に必要な機能」を見極めます。現行の操作ログやアクセスログを分析し、使用頻度の低い機能を特定します。不要な機能を刷新スコープから除外することで、期間とコストを大幅に抑制できます。

失敗パターン3: 経営層のコミットメント消失

レガシー刷新は1〜3年にわたる長期プロジェクトになることが多く、途中で経営環境が変化したり、他の優先課題が浮上したりして、経営層の関心が薄れるケースがあります。予算縮小やリソース引き上げが発生し、プロジェクトが中途半端な状態で凍結されると、旧システムと新システムの「二重運用」というさらに悪い状況に陥ります。

回避策: 3〜6カ月ごとに「ビジネス価値が目に見える成果」を出すマイルストーンを設計します。「最初の3カ月で月次決算の処理時間を50%短縮」「6カ月後に受注管理の新システムを稼働開始」など、経営層が投資効果を実感できる成果を継続的に示すことが、コミットメント維持の鍵です。

ストラングラーパターン — 段階的移行の実践

ストラングラーパターン（Strangler Fig Pattern）は、旧システムを段階的に新システムに置き換えていく移行手法です。名前の由来は、宿主の木を徐々に絞め殺していく絞め殺しの木（Strangler Fig）から来ています。

ストラングラーパターンの仕組み

旧システムの前段にファサード（ルーティング層）を配置し、リクエストの振り分け先を機能ごとに旧システムまたは新システムに切り替えます。移行が完了した機能から順に新システムにトラフィックを流し、最終的にすべてのリクエストが新システムに向かった時点で、旧システムを廃止します。

移行対象の優先順位付け

すべての機能を同じ優先度で移行するのではなく、以下の基準で優先順位を決定します。

1. ビジネスインパクトが大きい機能: 移行による業務改善効果が高い機能を優先する
2. 依存関係が少ない機能: 他の機能との結合が緩い機能は、単独で移行しやすい
3. 保守リスクが高い機能: 担当者が退職間近、ドキュメントが不在といった機能を早めに移行する
4. 変更頻度が高い機能: 頻繁に改修が発生する機能を先に新システムに移すことで、改修コストを即座に削減できる

移行ステップの具体例

1. ファサード層を構築し、全トラフィックをまず旧システムに透過的に転送する
2. 最初の移行対象機能を新システムに実装し、並行テストを実施する
3. ファサード層で該当機能のトラフィックを新システムに切り替える（カナリアリリースで段階的に）
4. 一定期間の安定稼働を確認後、次の機能の移行に着手する
5. 全機能の移行完了後、旧システムを廃止する

まとめ

レガシーシステムの刷新は、リホスト・リプラットフォーム・リビルドの3つのアプローチから、自社の緊急度・予算・技術負債の深刻度に合ったものを選択することが出発点です。ビッグバン移行ではなくストラングラーパターンによる段階的移行を採用し、3〜6カ月ごとにビジネス価値が目に見える成果を出しながら進めることが成功の鍵です。

AI活用によるレガシーコード解析・コード変換・テスト自動生成は、刷新の速度と品質を大幅に向上させます。「現行踏襲の罠」を避けるための業務棚卸し、経営層のコミットメント維持のための短期マイルストーン設計と合わせて、計画的に刷新を進めていくことが重要です。