モダナイゼーション手法 7R 完全ガイド｜AWS などが整理する代表的な分類と中堅企業の選び方

「モダナイゼーション手法に『6R』や『7R』があるらしいが違いが分からない」「リホスト・リライト・リプレースという言葉が混在していて混乱する」——基幹システム刷新を検討する経営者・情シス責任者から、こうした問いが届きます。クラウド移行・モダナイゼーションの代表的な分類として、AWS などのクラウドベンダーが整理に用いている 『7R』（Rehost／Replatform／Repurchase／Refactor or Re-architect／Retire／Retain／Relocate）があります。本記事では、7R の全体像、費用・期間の目安、5R／6R／7R の経緯、中堅企業の選び方フレームを整理します。

結論：モダナイゼーションには『7R』という代表的な分類がある

クラウド移行・モダナイゼーションの代表的な分類として 『7R』 があります。AWS などのクラウドベンダーが移行戦略の整理に用いる考え方で、『何を、どこまで変えるか』 によって 7 つに分類されます。システムの状況や経営判断に応じて、サブシステム単位で使い分けるのが実務的な使い方です。

費用・期間の前提条件：上記は 150～300 名規模の中堅企業で、基幹システムの一部または主要サブシステムを対象とした場合の概算（当社想定） です。実際の費用・期間は、対象範囲・画面数・帳票数・バッチ本数・外部連携数・データ移行量・テスト範囲・並行稼働の有無・要件定義の深さ・業務改革の有無・パッケージのカスタマイズ量・クラウド／ライセンス費用・移行後の運用保守範囲によって大きく変動します。一般相場ではなく自社想定の概算としてご覧ください。

7R は、「動かす（移行する）」3 手法／「作り直す」2 手法／「動かさない」2 手法 の 3 グループに分けて理解すると整理しやすくなります。すべての基幹システムを 1 つの R で扱う必要はなく、サブシステム単位で 7R を組み合わせる のが現実解です。

『動かす』系 3 手法｜リホスト・リプラットフォーム・リロケート

業務ロジックを維持したまま、システムを別環境に動かす ことを主目的とする 3 手法を整理します。

① リホスト（Rehost）｜環境だけ変える

既存のソースコード・業務ロジックをそのまま、OS／インスタンスレベルで動作環境を変える 手法です。「Lift and Shift」とも呼ばれます。メインフレーム→クラウド、オフコン→Linux サーバなどの移行で選ばれます。

② リプラットフォーム（Replatform）｜土台を最新化する

コードはほぼ維持しつつ、OS・データベース・ミドルウェアのバージョンアップやクラウドネイティブ DB への移行 など、土台部分だけを最新化する手法です。「Lift, Tinker, and Shift」とも呼ばれ、リホストよりやや踏み込んだアプローチです。

⑦ リロケート（Relocate）｜仮想化基盤ごと別環境へ移動

リホストと似ていますが、仮想化基盤ごと、またはハイパーバイザレベルで別環境へ移動する 点が異なります。代表的なケースは、自社データセンターの VMware 仮想マシンを、クラウド上の VMware 互換サービスへそのまま移動するパターンです。

『作り直す』系 2 手法｜リパーチェス・リファクタリング／リアーキテクチャ

業務要件レベルから見直して刷新する 2 手法を整理します。業務改革を伴うことが多く、業務影響と費用が大きくなる一方、長期的な投資対効果が出やすい領域です。

③ リパーチェス（Repurchase）｜パッケージ／SaaS に置き換える

既存システムを 業界特化型 ERP パッケージ／SaaS／クラウドプラットフォームに置き換える 手法です。「Drop and Shop」とも呼ばれます。自社でコードを保持せず、業務をパッケージ標準に合わせる「Fit to Standard」が基本方針になります。旧来の 5R 分類でいう「Replace」に近い考え方で、AWS 系の 6R／7R では「Repurchase」として整理されます。

④ リファクタリング／リアーキテクチャ（Refactor / Re-architect）｜コード・設計を変える

7R では リファクタリングとリアーキテクチャを 1 つのカテゴリとしてまとめて扱う ことが多くなっています。業務ロジックを維持しつつ コードをオープン系言語（Java／C#／.NET 等）に書き直す（リファクタリング） から、システムの設計自体を変える（リアーキテクチャ：マイクロサービス化／API ファースト化など） までを扱います。旧 5R の「Revise」や「Rebuild」に近い領域も、実務上は Refactor／Re-architect の検討範囲に含めて扱われることがあります。

『動かさない』系 2 手法｜リタイア・リテイン

7R には 『動かさない』という選択肢 も含まれています。すべてのシステムを移行する必要はなく、廃止・現状維持も正規の経営判断として位置づけられている点が重要です。

⑤ リタイア（Retire）｜廃止する

不要になったシステムを廃止する 手法です。基幹システム刷新の機会に、業務でほとんど使われていない／使用頻度が著しく低いサブシステムを棚卸しし、廃止判断するケースが該当します。

⑥ リテイン（Retain）｜現状を維持する

移行せず現状を維持する 判断です。すべてのシステムを今すぐクラウドへ移行する必要はありません。「いつ動かすか」を経営判断として明確に決める ことが、リテインを「先送り」と区別するポイントです。

5R／6R／7R の経緯

モダナイゼーション手法の分類は、クラウド移行の実務に合わせて 5R → 6R → 7R へと再整理 されてきました。それぞれの構成を整理します。

5R から 6R への変化は、単純な「項目追加」ではなく、クラウド移行の実務に合わせて分類を再整理したもの です。日本の IT 業界では、執筆時点（2026 年）で 5R・6R・独自整理の解説記事も多く残っており、用語が混在 しています。本記事では AWS などが整理に用いる代表的な分類として 7R を採用 していますが、ベンダー提案書やコンサルレポートでは「リライト」「リプレース」「リビルド」などの旧称が使われることもあるため、用語の対応関係を理解しておくことが重要です。

中堅企業の選び方フレーム｜手法選定の 4 つの判断軸

中堅企業（年商 50～500 億円規模）が 7R から手法を選ぶ際、判断材料が多すぎて迷うケースが多くなります。実務では 次の 4 つの軸 で絞り込むのが現実的です。

実務でよく見られるのは、『緊急性が高いがコストはかけたくない → リホストで延命 → その後 Refactor／Repurchase で本格刷新』 という段階戦略です。ただし、リホストで安心して動かなくなる「先送りパターン」も多いため、最初から本命の手法を据えるか、リホストの期限を明確に区切るか を経営判断として整理しておく必要があります。

モダナイゼーション手法選定の『よくある失敗』

失敗 1：『コスト』だけで手法を選ぶ

「リホストが最も安い」という理由でリホストを選ぶと、レガシー技術者依存・保守コストの増大・業務改革の機会損失 が積み上がり、5 年後に再投資が必要になるケースがあります。初期費用ではなく『5 年 TCO（総保有コスト）』で比較 することが、手法選定の鉄則です。

失敗 2：『手法』だけ決めて『業務要件』を後回し

「Refactor にする」と決めてからベンダー選定に入ったが、業務要件が整理されておらず要件定義フェーズが大幅に延びる ケース。手法選定の前後で「業務要件の棚卸し・業務独自性の整理」を必ず実施してください。

失敗 3：自動変換ツールを過信

Refactor で「自動変換ツールで 100% 変換できる」と説明を受けて選んだが、変換後のコードが機械翻訳的で保守困難・追加リファクタリングが必要 になり、当初予算の 2～3 倍に膨らむケースがあります。自動変換工数だけでなく、リファクタリング工数・テスト工数を別建てで予算化 してください。

失敗 4：『7R のどれか 1 つ』に決めようとする

基幹システムは複数のサブシステム（会計・販売管理・生産管理・在庫管理など）から構成されています。サブシステムごとに最適な手法は異なる のが普通です。「会計は Repurchase、独自性の高い販売管理は Refactor、周辺システムは Rehost、利用頻度の低い旧システムは Retire」のように、サブシステム単位で 7R を組み合わせる 設計が現実解です。

まとめ｜モダナイゼーション手法は『7R をサブシステム単位で組み合わせる』が現実解

モダナイゼーションには 7R（Rehost／Replatform／Repurchase／Refactor／Retire／Retain／Relocate）という代表的な分類があります。AWS などのクラウドベンダーが移行戦略の整理に用いる考え方で、現在クラウド移行検討時の共通言語として広く使われています。どれか 1 つを選ぶのではなく、サブシステム単位で 7R を組み合わせる のが中堅企業の現実解です。手法選定の本質は、コスト比較ではなく 『5 年 TCO（総保有コスト）』『業務独自性』『業務改革の意志』『投資余力と期間』の 4 軸での経営判断 にあります。

• 7R の整理：動かす系 3 手法（Rehost・Replatform・Relocate）／作り直す系 2 手法（Repurchase・Refactor）／動かさない系 2 手法（Retire・Retain）
• 選定の 4 つの判断軸：① 動機の緊急度 ② 業務独自性の強さ ③ 投資余力と期間 ④ 業務改革の意志
• 意思決定の順序：手法を決める前に『業務要件の棚卸し』を完了させる
• サブシステム単位の最適化：会計は Repurchase／独自性の高い販売管理は Refactor／利用頻度の低い旧システムは Retire のように組み合わせる

株式会社クオンツでは、『現行システムの棚卸し』『7R の組み合わせ設計』『5 年 TCO 試算』『モダナイゼーションプロジェクト支援』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のシステム規模・業務要件・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。