老朽化した基幹システムの刷新では、対象範囲と手法の選び方が最初の判断になります。手法によって費用・期間・効果・リスクは異なり、AWSの7Rで整理できます。
システム全体の検討には、レガシーシステムのモダナイゼーションの完全ガイドもご覧ください。機能ごとの手法の組み合わせは、後半で詳しく扱います。
刷新の種類・工程・費用・会社選定は、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で解説しています。
モダナイゼーションの対象範囲と手法選定の前提
手法を比べる前に、「何を対象に、どこまで変えるのか」という対象範囲を押さえておく必要があります。レガシー刷新の対象は、システムを構成する複数のレイヤーにまたがるため、範囲の見極めが欠かせません。
具体的には、サーバーやネットワークといったインフラ、OSやミドルウェアといった基盤ソフトウェア、業務処理を担うアプリケーション、蓄積されたデータの4つのレイヤーです。手法によって、どこまで手を入れるかが変わります。そのため、対象範囲の理解が手法選定の出発点になります。
刷新が対象とする4つのレイヤー
モダナイゼーションの対象範囲は、刷新の深さに応じて段階的に広がります。最も浅いのはインフラ層の置き換えで、老朽化したハードウェアやデータセンターをクラウドへ移すレベルです。次は基盤ソフトウェア層で、OSやデータベース、ミドルウェアを新しい製品へ更改する範囲を指します。
さらに踏み込むと、業務ロジックそのものを再構成するアプリケーション層に至ります。最も深い刷新では、データ構造まで含めて再設計することになります。どのレイヤーまで手を入れるかによって、得られる効果とコスト・リスクは比例して大きくなります。
たとえば、インフラ層だけの刷新であれば短期間・低コストで完了しますが、技術的負債そのものは温存されます。一方で、アプリケーション層やデータ層まで作り直すと、保守性や拡張性を抜本的に高められる代わりに、費用と期間、移行リスクが大きく膨らみます。そこで、効果とコストのトレードオフは、対象範囲の全体像をもとに把握することが第一歩になります。
手法選定の前提となる現状把握
適切な手法を選ぶ前提として、現行システムの現状把握（AS-IS可視化）が欠かせません。どのアプリケーションがどの業務に紐づき、互いにどう依存しているかが見えていなければ、リホストで済むのか、リビルドが必要なのかを判断できないからです。
仕様書が失われブラックボックス化したレガシーシステムでは、現状把握だけで相応の工数がかかります。裏を返せば、ここを丁寧に行うことが手法選定の精度を決めます。刷新を外部に委託する場合は、要件の整理やRFP（提案依頼書）の作成を別途検討する必要があります。
近年は、こうした現状把握を支援するツールも登場しています。一例として、富士通の「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化し、どこに技術的負債が集中しているかを地図のように示すツールです。こうした可視化によって、システム全体をまとめて扱わず、部分ごとに最適な手法を割り当てやすくなります。
標準的な手法の一覧（7R）と各手法の特徴
レガシー刷新の標準的な手法は、AWSが提唱する移行戦略の「7R」で最も広く参照されています。7Rは「Re」で始まる7つの選択肢で、リホスト、リロケート、リプラットフォーム、リパーチェス、リファクタリング／リアーキテクト、リタイア、リテインに分かれます。
よく使われる「リホスト／リプラットフォーム／リファクタリング／リアーキテクト／リビルド／リプレース／リテイン」という分類も、この7Rとほぼ対応しています。各手法の特徴は、変更の度合いが小さい順に並べています。
変更が小さい手法（リテイン・リタイア・リロケート・リホスト）
変更が小さい手法は、システムにほとんど手を加えないか、現状維持に近い選択です。リテイン、リタイア、リロケートが該当します。
- リテイン（Retain）：あえて刷新せず、現行システムをそのまま保持することです。刷新の必要性が低い、または時期尚早なシステムが対象になります。
- リタイア（Retire）：使われていない機能や重複している機能を廃止することです。棚卸しで不要な資産を見極め、刷新の対象を絞り込みます。
- リロケート（Relocate）：仮想化基盤などを大きく変えず、稼働環境だけを別の場所（クラウド等）へ移す手法です。
変更の小さい手法のなかでも、実務で中心となるのがリホスト（Rehost）です。これは「リフト＆シフト」とも呼ばれ、アプリケーションのコードや構成をほぼ変えずに、稼働基盤だけをクラウドや新しいサーバーへ移す手法を指します。
改修範囲が小さいため、後述するように費用も期間も最小限で済みます。特に、ハードウェアの老朽化への対処やデータセンター撤退を急ぐケースでは、第一候補になります。
アプリケーション内部の技術的負債はそのまま残るため、根本的な保守性の改善にはつながらない点に注意が必要です。
変更が大きい手法（リプラットフォーム・リパーチェス・リファクタリング／リアーキテクト）
変更が大きい手法は、アプリケーションの中身へ踏み込んで手を入れる選択です。リプラットフォーム、リパーチェス、リファクタリング／リアーキテクトが該当します。
- リプラットフォーム（Replatform）：中核ロジックは変えず、一部の基盤を新しいものへ置き換える手法です。
- リパーチェス（Repurchase／リプレース）：独自システムを廃し、SaaSやパッケージ製品へ乗り換える手法です。
- リファクタリング／リアーキテクト（Refactor／Rearchitect）：既存の業務ロジックを再設計し、クラウドネイティブな構成へ作り替えることです。
リプラットフォームで置き換えるのは、データベースやミドルウェアといった一部の基盤です。たとえば、オンプレミスの商用データベースをクラウドのマネージドサービスへ移すといった形で、リホストより一段深く、保守コスト削減や運用効率化の効果が得られます。改修と効果のバランスが取りやすいため、現実的な選択肢として採用されることが多い手法です。
リパーチェスは、自社で作り込んだ独自システムが対象で、会計や人事など標準業務で有効です。
リファクタリングやリアーキテクトには、一般に「リビルド（再構築）」と呼ばれる抜本刷新も含まれます。費用・期間・リスクは最大ですが、保守性と拡張性を根本から高められます。
手法ごとの費用・期間・適用ケースの比較
手法の特徴が分かったら、次は費用と期間が気になるところです。同じモダナイゼーションでも、選ぶ手法によって投資額は数百万円から数億円まで大きく開きます。
クラウド移行型（リホスト系）と再構築型（リビルド系）を対比すると、規模別の費用・期間の目安と、それぞれが適するケースが分かります。なお、ここで示す金額や期間は一般的な目安で、対象システムの規模や複雑度によって変動する点にご留意ください。
クラウド移行型と再構築型の費用・期間目安
クラウド移行型と再構築型では、費用と期間の目安が大きく異なります。
- クラウド移行型（リホスト等）：改修範囲が小さいため、費用は数百万円〜1,000万円台、期間は3〜6ヶ月程度で完了するケースが一般的です。
- 再構築型（リビルド等）：業務ロジックを作り直すため、費用は2,000万円〜数千万円規模に膨らみ、期間も12〜18ヶ月以上を要することが少なくありません。
リプラットフォームやリパーチェスはその中間に位置し、変更範囲に応じて費用・期間が変動します。同じ刷新でも、手法の選択が投資規模を一桁単位で左右することが分かります。
全体費用は、どこまで刷新するかと規模によって、要件定義だけの200万〜500万円から大規模の1.5億〜5億円まで幅があります。
- 要件定義・業務棚卸しのみ：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・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。