老朽化した基幹システムを刷新しようと決めたとき、最初に直面するのが「どの手法で進めるべきか」という問いです。レガシーシステムのモダナイゼーション（既存システムの刷新）には、リホスト・リプラットフォーム・リファクタリングなど複数の標準的な手法があり、それぞれ費用・期間・効果・リスクが大きく異なります。経済産業省のDXレポートが警鐘を鳴らした「2025年の崖」では、レガシーを放置した場合に2025年以降で年間最大12兆円もの経済損失が生じるリスクが指摘されており、刷新は待ったなしの経営課題です。ところが手法の違いを正しく理解しないまま着手すると、過剰な投資をしたり、逆に問題を先送りしただけで終わったりという失敗に陥りかねません。
本記事では、レガシーシステムのモダナイゼーションの対象範囲と、AWSが提唱する「7R」（リホスト／リロケート／リプラットフォーム／リパーチェス／リファクタリング・リアーキテクト／リタイア／リテイン）を中心とした標準的な手法の一覧を、特徴・費用・期間・適用ケースの観点から比較して整理します。あわせて、全体像を体系的に整理したレガシーシステムのモダナイゼーションの完全ガイドもあわせてご覧いただくと、手法選定から費用感までの俯瞰がしやすくなります。本記事は、その完全ガイドのなかでも「手法そのものの定義と使い分け」に焦点を絞り、システム全体に単一手法を当てはめるのではなく複数手法を組み合わせる「ポートフォリオアプローチ」の考え方までを掘り下げる内容です。
▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド
モダナイゼーションの対象範囲と手法選定の前提
モダナイゼーションの手法を理解する前に、まず「何を対象に、どこまで変えるのか」という対象範囲を押さえる必要があります。レガシー刷新の対象は、システムを構成する複数のレイヤーにまたがります。具体的には、サーバーやネットワークといったインフラ、OSやミドルウェアといった基盤ソフトウェア、業務処理を担うアプリケーション、そして蓄積されたデータの4つです。手法によって、このどこまでに手を入れるかが変わるため、対象範囲の理解が手法選定の出発点になります。
刷新が対象とする4つのレイヤー
モダナイゼーションの対象範囲は、刷新の深さによって段階的に広がります。最も浅いのはインフラ層の置き換えで、老朽化したハードウェアやデータセンターをクラウドへ移すレベルです。次が基盤ソフトウェア層で、OSやデータベース、ミドルウェアを新しい製品へ更改する範囲を指します。さらに踏み込むとアプリケーション層に到達し、業務ロジックそのものを再構成します。最も深い刷新ではデータ構造まで含めて再設計することになります。
重要なのは、どのレイヤーまで手を入れるかによって、得られる効果とコスト・リスクが比例して大きくなるという点です。インフラ層だけの刷新であれば短期間・低コストで完了しますが、技術的負債そのものは温存されます。逆にアプリケーション層やデータ層まで作り直せば、保守性や拡張性を抜本的に高められる一方、費用と期間、移行リスクは大きく膨らみます。この「効果とコストのトレードオフ」を、対象範囲の地図のうえで把握することが第一歩です。
手法選定の前提となる現状把握
適切な手法を選ぶには、その前提として現行システムの現状把握（AS-IS可視化）が欠かせません。どのアプリケーションがどの業務に紐づき、互いにどう依存しているのかが見えていなければ、リホストで済むのかリビルドが必要なのかを判断できないからです。仕様書が失われブラックボックス化しているレガシーシステムでは、この現状把握だけで相応の工数がかかります。逆にいえば、ここを丁寧に行うことが手法選定の精度を決定づけます。
近年は、こうした現状把握を支援するツールも登場しています。たとえば富士通の「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化し、どこに技術的負債が集中しているかを地図のように示すツールです。こうした可視化によって、システム全体を一律に扱うのではなく、部分ごとに最適な手法を割り当てる判断がしやすくなります。なお、刷新を外部へ委託する際の要件整理やRFP作成については別途検討が必要ですが、本記事ではまず手法そのものの理解に集中します。
標準的な手法の一覧（7R）と各手法の特徴
レガシー刷新の標準的な手法を語るうえで最も広く参照されるのが、AWSが提唱する移行戦略の「7R」です。これは7つの手法をそれぞれ「Re」で始まる英単語で表したもので、Rehost（リホスト）、Relocate（リロケート）、Replatform（リプラットフォーム）、Repurchase（リパーチェス）、Refactor／Rearchitect（リファクタリング・リアーキテクト）、Retire（リタイア）、Retain（リテイン）から構成されます。指示でよく挙がる「リホスト／リプラットフォーム／リファクタリング／リアーキテクト／リビルド／リプレース／リテイン」という分類も、この7Rとほぼ対応しています。ここでは各手法の特徴を、変更の度合いが小さいものから順に整理します。
変更が小さい手法（リテイン・リタイア・リロケート・リホスト）
まず、システムにほとんど手を加えない、あるいは現状維持に近い手法群です。
・リテイン（Retain）：あえて刷新せず現行システムを保持する判断。刷新の必要性が低い、または時期尚早なシステムに適用します。
・リタイア（Retire）：使われていない、重複している機能を廃止する判断。棚卸しによって不要資産を見極め、刷新対象を絞り込みます。
・リロケート（Relocate）：仮想化基盤などを大きく変えず、稼働環境だけを別の場所（クラウド等）へ移す手法です。
そのうえで実務上の中心となるのがリホスト（Rehost）です。これは「リフト＆シフト」とも呼ばれ、アプリケーションのコードや構成をほぼ変えずに、稼働基盤だけをクラウドや新しいサーバーへ移す手法を指します。改修範囲が小さいため、後述するように費用も期間も最小限で済み、ハードウェア老朽化への対処やデータセンター撤退を急ぐケースで第一候補になります。ただし、アプリケーション内部の技術的負債はそのまま残るため、根本的な保守性改善にはつながらない点に注意が必要です。
変更が大きい手法（リプラットフォーム・リパーチェス・リファクタリング／リアーキテクト）
次に、アプリケーションへより踏み込んで手を入れる手法群です。リプラットフォーム（Replatform）は、アプリケーションの中核ロジックは変えずに、データベースやミドルウェアといった一部の基盤を新しいものへ置き換える手法です。たとえばオンプレミスの商用データベースをクラウドのマネージドサービスへ移すといった形で、リホストより一段深く、保守コスト削減や運用効率化の効果が得られます。改修と効果のバランスが取りやすく、現実的な選択肢として採用されることが多い手法です。
さらに変更が大きいのが、リパーチェス（Repurchase／リプレース）とリファクタリング・リアーキテクト（Refactor／Rearchitect）です。
・リパーチェス：自社で作り込んだ独自システムを廃し、SaaSやパッケージ製品へ「乗り換える」手法。会計や人事など標準業務で有効です。
・リファクタリング／リアーキテクト：既存の業務ロジックを再設計し、クラウドネイティブな構成へ作り替える手法。一般に「リビルド（再構築）」と呼ばれる抜本刷新もこの系統に含まれます。費用・期間・リスクは最大ですが、保守性と拡張性を根本から高められます。
手法ごとの費用・期間・適用ケースの比較
手法の特徴を理解したら、次に気になるのが費用と期間です。同じ「モダナイゼーション」でも、選ぶ手法によって投資額は数百万円から数億円まで大きく開きます。ここでは、クラウド移行型（リホスト系）と再構築型（リビルド系）を対比させながら、規模別の費用・期間の目安と、それぞれがどんなケースに適するかを整理します。なお、ここで示す金額や期間はあくまで一般的な目安であり、対象システムの規模や複雑度によって変動する点はご留意ください。
クラウド移行型と再構築型の費用・期間目安
まず手法タイプ別の目安です。クラウド移行型（リホスト等）は、改修範囲が小さいため数百万円〜1,000万円台、期間は3〜6ヶ月程度で完了するケースが一般的です。一方、業務ロジックを作り直す再構築型（リビルド等）になると、2,000万円〜数千万円規模に膨らみ、期間も12〜18ヶ月以上を要することが少なくありません。リプラットフォームやリパーチェスはその中間に位置し、変更範囲に応じて費用・期間が変動します。同じ刷新でも、手法選択が投資規模を一桁単位で左右することがわかります。
次に、対象システムの規模別に見た全体費用の目安です。
・要件定義・業務棚卸しのみ：200万〜500万円。本格刷新の前段として現状把握だけ行う場合の費用感です。
・小〜中規模（単一業務システム）：3,000万〜1.5億円。このうちSI費（設計・開発の人件費）が全体の60〜75%を占めるのが一般的です。
・中〜大規模（基幹＋複数周辺システム）：1.5億〜5億円規模。複数システムの連携や移行が絡むため、費用も期間も大きくなります。
手法ごとの適用ケースの見極め方
費用と期間を踏まえると、手法ごとの適用ケースが見えてきます。ハードウェアの保守期限が迫っている、データセンターから早急に撤退したいといった「時間が最優先」のケースでは、低コストで短期間のリホストやリロケートが適します。一方、業務ロジックが肥大化・複雑化して改修が困難になっている、技術者の属人化が深刻だといった「構造そのものが問題」のケースでは、費用と期間がかかってもリファクタリング・リビルドで根本から作り直す価値があります。
会計・人事・給与といった、自社独自である必要性が低い標準業務であれば、リパーチェス（SaaS・パッケージへの乗り換え）が有力な選択肢になります。逆に、競争力の源泉となる独自業務はパッケージに合わせにくいため、リファクタリングで作り込む判断が妥当です。日本の代表的な公的指針であるIPA（情報処理推進機構）も、刷新手法を「リビルド・リライト・リホスト・ハードウェア更改」の4分類で整理しており、システムの状態と目的に応じた使い分けを推奨しています。費用の大小ではなく、「何を解決したいか」を起点に手法を選ぶことが重要です。
単一手法ではなくポートフォリオで組み合わせる考え方
ここまで7Rの各手法と費用・期間を見てきましたが、実務で最も重要なのは「システム全体を一つの手法で刷新しようとしない」という視点です。レガシーシステムは複数の業務システムが複雑に絡み合った集合体であり、その全体に単一の手法を当てはめるのは現実的ではありません。むしろ、システムを構成要素に分解し、それぞれに最適な手法を割り当てる「ポートフォリオアプローチ」こそが、現実的かつ効果的な刷新の進め方になります。
なぜ単一手法では最適化できないのか
システム全体を一律にリホストすれば、たしかに短期間・低コストで移行は完了します。しかし、競争力の源泉となる中核業務に潜む技術的負債は温存されたままで、数年後に再び刷新を迫られることになります。逆に、すべてをリビルドで作り直そうとすれば、本来は手を入れる必要のない安定稼働中のシステムにまで多額の投資をすることになり、費用と期間が膨れ上がってプロジェクト自体が頓挫しかねません。どちらの極端も、全体最適にはなりません。
そこで有効なのが、システムを業務単位・機能単位に分解し、それぞれの重要度と老朽度に応じて手法を割り当てる考え方です。たとえば、競争力の核となる独自業務はリファクタリングで作り直し、会計・人事はリパーチェスでSaaSへ移行し、安定稼働中の周辺システムはリホストで延命する、といった具合に組み合わせます。前提となる現状把握によって各システムの状態を可視化しておけば、この割り当ての精度が高まります。これがポートフォリオアプローチの本質です。
段階的移行とストラングラーパターン
ポートフォリオアプローチと表裏一体なのが、移行の進め方です。複数の手法を組み合わせる以上、すべてを一度に切り替える「ビッグバン（全社一括）」は現実的ではなく、リスクも極めて高くなります。基幹システムを一斉に入れ替えた結果、移行計画の不備から深刻な業務停止に至った例も実在します。そのため、機能単位で新旧を並行稼働させながら少しずつ置き換えていく「ストラングラーパターン」と呼ばれる段階的移行が推奨されます。
ストラングラーパターンでは、旧システムを稼働させたまま、刷新した機能を一つずつ新システムへ移し替え、最終的に旧システムを「絞め殺す（strangle）」ように廃止していきます。これにより、各段階で動作を検証でき、問題が起きても影響範囲を限定できます。ポートフォリオで割り当てた手法を、この段階的移行の枠組みに乗せて優先順位をつけて進めることで、リスクを抑えながら着実に刷新を完了させられます。手法選定と移行設計は、必ずセットで考えることが成功の鍵です。
まとめ
本記事では、レガシーシステムのモダナイゼーションの対象範囲と標準的な手法の一覧について、AWSの7R（リホスト／リロケート／リプラットフォーム／リパーチェス／リファクタリング・リアーキテクト／リタイア／リテイン）を軸に、各手法の特徴・費用・期間・適用ケースを比較して解説しました。手法は変更の度合いによって幅広く、費用も数百万円のクラウド移行型から数億円規模の再構築型まで開きがあります。クラウド移行型は3〜6ヶ月・数百万円台、再構築型は12〜18ヶ月以上・2,000万円〜数千万円規模が一つの目安となり、対象システムの規模が大きくなれば全体費用は1.5億〜5億円に達することもあります。重要なのは費用の大小ではなく、「何を解決したいか」を起点に手法を選ぶことです。
そして実務で最も大切なのは、システム全体に単一手法を当てはめるのではなく、業務・機能ごとに最適な手法を割り当てる「ポートフォリオアプローチ」を取ることです。そのうえで、ビッグバンによる一括移行を避け、ストラングラーパターンによる段階的移行で着実に進めることがリスク低減につながります。「2025年の崖」が示すように、レガシーの放置は年々リスクを増幅させます。まずは現状把握によって自社システムを可視化し、どの部分にどの手法が適するかを見極めることから始め、最適な手法の組み合わせを、経験豊富なパートナーとともに具体化していくことをおすすめします。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。