「モダナイゼーションには色々な手法があるらしいが、結局 リホスト・リライト・リプレースの違い がよく分からない」「3 つのうち自社にはどれが合うのか、判断軸が知りたい」——基幹システム刷新を検討する経営者・情シス責任者から、こうした問いが届きます。3 つの手法は 『どこまで作り直すか』 のグラデーション上に並んでおり、選び方を誤ると 費用が膨らむ・業務影響が大きくなる・将来的に再投資が必要になる といった失敗につながります。なお IT 業界では「リプレース」という言葉が広く使われますが、本記事では特に パッケージ／SaaS への置き換え を指して用います。本記事では、3 手法の違い・費用・業務影響を比較し、自社に合う手法の選び方フレームと、選択ミスの失敗事例を整理します。
『リホスト・リライト・リプレース、自社にはどれが合うか客観評価したい』 25 年の経験で、現行システムと業務要件から最適な手法を一緒に整理します。 無料相談 ＞結論：3 手法は『どこまで作り直すか』のグラデーション
リホスト・リライト・リプレースは 『業務ロジック・コード・業務プロセスをどこまで作り直すか』 のグラデーション上に並ぶ 3 つの選択肢です。左ほど「動かすだけ」、右ほど「業務改革を伴う抜本的刷新」となり、費用・期間・業務影響が段階的に変わります。
| 手法 | 何を変えるか | 費用目安（当社想定） | 期間 | 業務影響 |
|---|---|---|---|---|
| ① リホスト | 動作環境（サーバ／仮想化基盤／クラウド等）を中心に変える。コード変更は最小限 | 1,000 万～3,000 万円 | 6～12 ヶ月 | 小 |
| ② リライト | 業務ロジックは維持しつつ、コードをオープン系言語（Java／C#／.NET 等）に書き直す | 3,000 万～1.5 億円 | 12～24 ヶ月 | 中（業務は維持しやすいが、仕様再整理・テスト負荷が大きい） |
| ③ リプレース | パッケージ／SaaS に置き換え、業務をパッケージ標準に合わせる | 3,000 万～1 億円 | 12～24 ヶ月 | 大 |
費用・期間の前提条件：上記は 150～300 名規模の中堅企業で、基幹システムの一部または主要サブシステムを対象とした場合の概算（当社想定） です。実際の費用・期間は、対象範囲・画面数・帳票数・バッチ本数・外部連携数・データ移行量・テスト範囲・パッケージのカスタマイズ量・ライセンス費用・クラウド利用料・運用保守範囲によって大きく変動します。一般相場ではなく自社想定の概算としてご覧ください。
クラウド移行戦略でよく使われる 7R 分類（AWS などが整理する分類）に当てはめると、リホストは Rehost、リライトは主に Refactor に近い手法です（システム構造や連携方式まで見直す場合は Re-architect に近づきます）。リプレースは本記事のようにパッケージ／SaaS への置き換えを指す場合、Repurchase に近い考え方として整理できます。
3 手法の詳細比較｜何を、どう変えるか
3 手法それぞれの中身を、メリット・デメリット・適合ケースの観点で詳しく整理します。
① リホスト（Rehost）｜環境を中心に変える
既存のソースコード・業務ロジックをできるだけ維持し、動作環境を新しい基盤へ移す 手法です。「Lift and Shift」とも呼ばれます。メインフレームやオフコンのアプリケーションを、エミュレーション環境や互換実行環境を利用して新しい基盤へ移すケースで選ばれます。
| メリット | 3 手法の中では短期・低コストになりやすい／業務影響が小さい／ハードウェア保守切れ対策として有効／既存運用ノウハウを活かせる |
|---|---|
| デメリット | レガシーコードが残るため、技術者依存・保守コストの問題は解決しにくい／クラウドネイティブのメリットを十分に享受できない／延命策で終わると、数年後に再投資が必要になる場合がある |
| 向いている状況 | ハードウェア／OS の保守切れが迫っており、短期に対応したい／業務改革の余裕がない／投資余力が限定的 |
② リライト（主に Refactor）｜コードを書き直す
業務ロジックは維持しつつ、ソースコードをオープン系言語（Java／C#／.NET 等）に書き直す 手法です。7R 分類では主に Refactor に近い手法ですが、システム構造や連携方式まで見直す場合は Re-architect に近い領域になります。COBOL・RPG などのレガシー言語からオープン系への自動変換ツールを使うケースもあれば、人手で再設計・再実装するケースもあります。
| メリット | レガシー言語からの脱却／技術者市場の厚いオープン系言語へ移行可能／クラウドネイティブ化への土台を作れる／業務独自仕様を維持できる |
|---|---|
| デメリット | 変換後のコードが機械翻訳的になりやすく、追加リファクタリングが必要なケースが多い／RPG／COBOL 固有機能の再現に課題／費用・期間が大きくなりがち／仕様再整理・テスト負荷が大きい |
| 向いている状況 | 業務独自仕様は維持したいが、技術基盤をオープン系に移したい／長期的な保守コストを下げたい／業務改革は別フェーズで取り組みたい |
③ リプレース（Repurchase）｜パッケージ／SaaS に置き換える
既存システムを 業界特化型 ERP パッケージ／SaaS／クラウドプラットフォームに置き換える 手法です。「Drop and Shop」とも呼ばれます。自社でコードを保持せず、業務をパッケージ標準に合わせる「Fit to Standard」が基本方針になります。なお、IT 業界では「リプレース」という言葉が広く使われますが（ハードウェアリプレース・スクラッチ再構築への置き換えなども含む）、本記事では特に パッケージ／SaaS への置き換え を指します。
| メリット | 自社で保守する範囲を抑えられる／業界ベストプラクティスを取り込める／パッケージ標準に合わせられる場合は長期 TCO を最適化しやすい／業務改革と一体で進められる |
|---|---|
| デメリット | 業務をパッケージに合わせる労力／独自業務がパッケージで吸収できない場合のカスタマイズ費用がかさみ、結果として TCO が悪化する可能性も／30 年蓄積した業務独自仕様を捨てる経営判断が必要 |
| 向いている状況 | 業務独自性が業界差別化に直結しない／業務改革を含めて抜本的に刷新したい／中堅企業では有力な選択肢の一つ |
3 手法の費用・期間・業務影響の比較マトリクス
中堅企業（150～300 名規模・主要サブシステムを対象とした当社想定の概算）の典型的な費用・期間・業務影響を 7 つの評価軸で並べると、それぞれの違いが見えてきます。
| 評価軸 | ① リホスト | ② リライト | ③ リプレース |
|---|---|---|---|
| 初期費用 | 1,000 万～3,000 万円 | 3,000 万～1.5 億円 | 3,000 万～1 億円 |
| 期間 | 6～12 ヶ月 | 12～24 ヶ月 | 12～24 ヶ月 |
| 業務影響 | 小（業務継続） | 中（業務は維持しやすいが、仕様再整理・テスト負荷が大きい） | 大（業務プロセス見直し） |
| 5 年 TCO（総保有コスト） | 中～大（再投資リスクあり） | 中～大 | 中～大（サブスク・カスタマイズ次第） |
| レガシー依存解消 | △（コード維持） | ◎（オープン系へ移行） | ◎（コード自体を保持しない） |
| 業務改革の度合い | 無 | 低～中 | 高 |
| 失敗時の影響範囲 | 小～中（旧環境を並行維持していれば切り戻し計画を設けやすい） | 中（仕様再現・テスト品質に依存） | 大（業務プロセス変更と一体になりやすい） |
初期費用だけ見ればリホストが最も安く見えることが多いですが、レガシー依存が残るため 数年後に再投資が必要になる場合があります。そのため、初期費用だけでなく 5 年 TCO（総保有コスト）で比較 することが重要です。
自社に合う手法の選び方｜4 つの判断軸でフローチャート化
3 手法から自社に合う選択肢を絞り込むには、次の 4 つの判断軸 を順に確認するのが現実的です。中堅企業の典型的な意思決定パスを整理します。
| 判断軸 | 確認するポイント | 選びやすくなる手法 |
|---|---|---|
| ① 動機の緊急度 | ハードウェア保守切れ・技術者退職など、外的圧力で動かざるを得ないか | 緊急性高：リホスト 緊急性中：リライト 緊急性低（戦略主導）：リプレース |
| ② 業務独自性の強さ | 業務独自仕様が業界差別化に直結しているか | 独自性高：リライト 独自性中：リライト or リホスト 独自性低：リプレース |
| ③ 投資余力と期間 | 1～3 年で投じられる予算と、現場が許容できる期間 | 予算小・短期：リホスト 予算中・中期：リライト or リプレース 予算大・長期：リライト |
| ④ 業務改革の意志 | 同時に業務プロセスを見直したいか、現行業務をそのまま維持したいか | 業務維持：リホスト or リライト 業務改革：リプレース |
4 軸を当てはめると、中堅企業に多いパターンは次の 3 種類に集約されます：
- パターン A：『緊急回避型』 — 動機緊急度が高く、投資余力が限定的 → リホスト で延命し、その後の本格刷新を検討
- パターン B：『業務維持型』 — 業務独自性が強く、業務改革は別フェーズに → リライト でレガシー基盤だけ刷新
- パターン C：『業務改革型』 — 業務独自性が低く、業務改革と基盤刷新を同時に進めたい → リプレース でパッケージ／SaaS に乗り換え
ただし、中堅企業の基幹システムは複数のサブシステムから構成されており、サブシステムごとに最適な手法が異なる のが普通です。「会計はリプレース、独自性の高い販売管理はリライト、周辺システムはリホスト」のように、サブシステム単位で 3 手法を組み合わせる 設計が現実解です。
選択ミスの『よくある失敗パターン』
失敗 1：『初期費用が安い』だけでリホストを選ぶ
「リホストが最も安い」という理由で安易に選び、レガシー技術者依存・保守コスト増大・業務改革の機会損失 が積み上がって、数年後に再投資が必要になるパターン。初期費用ではなく『5 年 TCO（総保有コスト）』で比較 することが、手法選定の鉄則です。
失敗 2：『業務改革』を伴わずリプレースを選ぶ
業務独自性が強い企業がリプレース（パッケージ／SaaS）を選び、業務を「パッケージに合わせて変える」覚悟が経営層に無いまま着手するパターン。独自業務をパッケージにカスタマイズで再現しようとして費用が 2～3 倍に膨らみ、保守性も下がる 結果になります。リプレースは Fit to Standard（業務をパッケージに合わせる）が大前提。これを経営として受け入れられないなら、リライトを選ぶべきです。
失敗 3：自動変換ツールを過信したリライト
リライトで 自動変換ツールで構文上は変換できても、変換後のコードが保守しやすい設計になるとは限りません。追加リファクタリングが必要になり、当初予算を超過するケースもあります。自動変換工数だけでなく、追加リファクタリング工数・テスト工数・設計見直し工数を別建てで予算化 してください。
失敗 4：3 手法のどれか 1 つに絞ろうとする
基幹システムは会計・販売管理・生産管理・在庫管理など複数のサブシステムから構成されています。サブシステムごとに最適な手法は異なる のが普通です。一律「リホスト」「リライト」「リプレース」を選ぶより、サブシステム単位で 3 手法を組み合わせた方が、費用・業務影響・リスクのバランスを取りやすくなります。
失敗 5：移行手法を決めてから業務要件を整理する
「リプレースで進める」と決めてからベンダー選定に入ったが、業務要件が整理されておらず要件定義フェーズが大幅に延びる ケース。手法選定の前後で 『業務要件の棚卸し・業務独自性の整理』を必ず実施 し、その結果をベースに手法を再評価するのが正しい順序です。
まとめ｜リホスト・リライト・リプレースは『5 年 TCO とサブシステム単位の最適化』で選ぶ
リホスト・リライト・リプレースは 『どこまで作り直すか』のグラデーション 上に並ぶ 3 つの選択肢です。初期費用・期間・業務影響が大きく異なる一方、『どれか 1 つを選ぶ』のではなく『サブシステム単位で組み合わせる』 ことで、費用・業務影響・リスクのバランスを取りやすくなります。手法選定の本質は、コスト比較ではなく 『5 年 TCO（総保有コスト）』『業務独自性』『業務改革の意志』『投資余力と期間』の 4 軸での経営判断 にあります。
- 3 手法の整理：リホスト（環境だけ）・リライト（コード書き直し）・リプレース（パッケージ／SaaS）
- 選定の 4 つの判断軸：① 動機の緊急度 ② 業務独自性の強さ ③ 投資余力と期間 ④ 業務改革の意志
- 意思決定の順序：手法を決める前に『業務要件の棚卸し』を完了させる
- サブシステム単位の最適化：会計はリプレース／独自性の高い販売管理はリライト／周辺はリホスト のように組み合わせる
- 判断のコツ：初期費用ではなく 5 年 TCO で比較。リホストの「短期に安い」は数年後に再投資となる場合がある
株式会社クオンツでは、『現行システムの棚卸し』『3 手法の組み合わせ設計』『5 年 TCO 試算』『モダナイゼーションプロジェクト支援』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のシステム規模・業務要件・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
