レガシーシステム更改では、四層で対象範囲を洗い出して絞り込み、残す・捨てる・載せ替えに仕分けたうえで、期限に合う手法を選びます。
期限内に更改を終えるには、対象範囲と手法の選び方を押さえることが欠かせません。全体像・費用・進め方はレガシーシステム更改の完全ガイドをご覧ください。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム更改で見直すべき対象範囲の全体像
レガシーシステム更改の対象範囲は、古いプログラムを新しく書き直すことより広く、アプリケーションのロジック、データベース、インフラ基盤、外部システムとの連携、運用・バッチ処理といった複数の層が絡み合っています。それぞれの層に、見直すべきかどうかの判断が必要です。
期限から逆算して対象範囲を絞るには、まずこの全体像を層ごとに把握することが出発点になります。
インフラ・アプリ・データ・連携の四層による対象の捉え方
更改の対象は、四つの層に分けて洗い出すと全体を把握できます。
- インフラ層：メインフレームや汎用機、保守期限が迫るサーバー・ストレージ・ネットワーク機器。
- アプリケーション層：COBOLなどで書かれた業務ロジックやバッチ処理。
- データ層：独自形式のファイルや古いデータベースに蓄積された業務データ。
- 連携層：他システムや外部サービスとのインターフェース、帳票、EDIなどの入出力。
EOLや保守期限が引き金の更改では、まずインフラ層が起点になります。サーバーやOSのサポートが切れると、その上で動くアプリケーションやデータも連動して移す必要が出てくるためです。
つまり、どの層に期限が来ているかを特定すれば、対象範囲に含めるべき最小限の範囲が見えてきます。たとえば、期限が来ているのがインフラ層だけなら、アプリは極力そのまま移すリホストを選び、対応範囲を狭めるという判断ができます。
注意したいのは、層と層がつながる境界部分です。アプリケーションが特定のOSバージョンや古いミドルウェアの仕様に依存していると、インフラだけを新しくしても正しく動かないことがあります。
データ層でも、独自形式のファイルを前提に作られたバッチが、データベースを移し替えた途端に動かなくなることがあります。対象範囲を四層で捉えたうえで、境界ごとの依存関係まで洗い出しておくことが、更改後の不具合を防ぐ前提になります。
残す機能・捨てる機能・載せ替える機能の三分類
既存機能は、必要性と実装の状態から三つに分類します。
- 残す：現在も業務に不可欠で、要件が変わっていない機能。
- 捨てる：使われていないデッドコードや、廃止済み業務だけを処理する機能。
- 載せ替える：業務上必要だが実装が古く、新しい標準へ置き換える機能。
この仕分けは効果が大きく、実際にある製造業の更改では、資産を洗い出した結果、移行が必要なプログラムが想定の約60%にまで絞り込めた例があります（出典：各社公開資料に基づく相場感）。
残りの40%は、デッドコードや不要機能でした。つまり、更改の対象範囲をこの三分類で見直すだけで、コスト・期間・リスクのすべてを圧縮できます。
仕分けで判断が難しいのは、「載せ替える」に分類される機能です。業務上は必要でも実装が古い機能は、今回の更改で新しい標準に置き換えるか、基盤だけ移して次サイクルで作り直すかを選ぶことになります。この判断で効いてくるのが期限です。
期限まで余裕がなければ、まずはそのまま移して期限を回避し、改善は後回しにします。一方で、期限に余裕があれば、この機会に標準的な作りへ載せ替えます。
同じ「載せ替える」機能でも、期限との兼ね合いで適用する手法が変わります。こうして絞り込んだ対象に、どの手法を当てるかが次の課題になります。
更改の手法一覧：7Rとハードウェア更改の使い分け
更改の対象範囲が見えたら、次は各機能をどの手法で移すかを決めます。代表的なフレームワークとして、AWSの提唱する「7R」と、IPAによる4分類があります。
これらは、どこまで作り変えるかを段階的に示したものです。期限と予算に応じて使い分けることが、更改成功の核心になります。
7R（リホスト・リプラットフォーム・リファクタなど）の定義
AWSの「7R」は、更改の手法を7つに分けたものです（出典：AWS）。その7つは、Rehost（リホスト）、Relocate（リロケート）、Replatform（リプラットフォーム）、Repurchase（リパーチェス）です。残りの3つは、Refactor（リファクタ）、Retire（リタイア）、Retain（リテイン）です。
この7つは、基盤を移す、標準へ移す、作り直す、廃止する、維持するという5つの動きに分けて見ると、違いが分かります。
- 基盤を移す：Rehostはアプリをそのまま移し、Relocateは仮想化環境ごと移します。
- 標準へ移す：Replatformは基盤を最適化し、RepurchaseはパッケージやSaaSへの切り替えです。
- 作り直す：Refactorは内部構造を変えて、保守性を高める方式です。
- 廃止する：Retireは使われていない機能を終了し、対象の縮小につながります。
- 維持する：Retainは機能を当面残し、次の更改サイクルに回します。
更改で特に出番が多いのは、上から数えてRehostとReplatformです。これらは業務ロジックを大きく変えずに基盤だけを新しくできるため、保守期限やEOLという期限を最短で回避するのに適しています。
RefactorやRepurchaseは効果が大きい反面、期間と費用がかさむため、期限に余裕がある機能や次サイクルに回せる機能に当てるのが現実的です。
クラウド移行型のリホストは数百万〜1,000万円台で3〜6ヶ月程度、業務を整理し直す再構築型は2,000万円規模以上で12〜18ヶ月以上が一つの相場とされます（出典：各社公開資料に基づく相場感）。単一業務システムの更改全体では3,000万〜1.5億円、基幹と複数の周辺システムを含む場合は1.5億〜5億円規模に及ぶこともあります。
IPAの4分類とハードウェア更改の位置づけ
IPAは、レガシー更改の手法を次の4分類で整理しています（出典：IPA）。
- リビルド：要件を整理し直して作り直す方式。
- リライト：既存ロジックを別言語へ自動・半自動で変換する方式。
- リホスト：アプリをそのまま新基盤へ移す方式。
- ハードウェア更改：アプリに手を入れず、保守切れの機器だけを置き換える方式。期限回避を最優先する場面で選ばれます。
業務影響は最も小さく、保守期限やEOLを契機とする更改では重要な選択肢になります。ただし根本的な脱却にはならず、ブラックボックス化や技術者枯渇の課題は残ります。実務では、まずハードウェア更改やリホストで期限を回避し、その後にリプラットフォームやリビルドで段階的に本格更改を進めるのが定石です。
手法は単独ではなく、期限の近い機能は軽い手法、時間が取れる機能は重い手法と組み合わせます。期限から逆算して再構築が間に合わないと判断できれば、軽い手法で期限を回避し、本格更改は次サイクルへ回せます。
費用と期間の目安には、次のような幅があります。
- クラウド移行型のリホスト：数百万〜1,000万円台で3〜6ヶ月程度。
- 業務を整理し直す再構築型：2,000万円規模以上で12〜18ヶ月以上が一つの相場とされます（出典：各社公開資料に基づく相場感）。
- 単一業務システムの更改全体：3,000万〜1.5億円。
- 基幹と複数の周辺システムを含む更改：1.5億〜5億円規模に及ぶこともあります。
費用は規模で大きく変わるため、手法と費用・期間をセットで把握しておくと、更改計画の精度が高まります。
更改時に必ず見直すべき機能・領域
手法を使い分ける前提として、更改で特に注意して見直すべき機能・領域があります。基盤だけを移せばよいと油断すると、移行後に思わぬ不具合が出やすい箇所です。更改で見落とされがちな重点領域は三つあります。
夜間バッチ・帳票・外部連携インターフェース
更改で最も見直しが必要なのは、夜間バッチ処理と帳票、外部システムとの連携インターフェースです。これらは長年の運用で複雑化していることが多く、特定のハードウェアやOSの挙動に依存している場合もあります。
基盤を移した途端に処理時間が変わったり、文字コードや改行コードの違いで帳票が崩れたりする事故は、更改の現場で繰り返し起きています。バッチの処理順序やタイミング依存、データ受け渡し形式は、丁寧に検証すべき領域です。
逆に、ここを見直すと改善につながることもあります。前述の製造業の更改では、汎用機上で8時間かかっていた夜間バッチが、更改後には90分へと約80%短縮されました（出典：各社公開資料に基づく相場感）。古い基盤の制約で長時間化していた処理は、新しい基盤で速くなることも珍しくなく、バッチや連携は更改を機に性能や運用負荷を見直す対象でもあります。
データ形式・セキュリティ・運用保守の機能
二つ目の重点領域はデータ形式です。独自形式のファイルや古い文字コードでデータを保持していることが多く、新しいデータベースへ移す際は変換とマッピングが必要です。軽視すると、桁あふれや文字化け、日付フォーマットの不整合が移行後に表面化するため、対象範囲を決める段階で、どのデータをどう変換するかを早めに洗い出しておくことが重要です。
三つ目はセキュリティと運用保守の機能です。EOLを迎えたOSやミドルウェアは、パッチが提供されなくなるため、更改で脆弱性を解消することが大きな目的になります。監視・ログ取得・バックアップ・権限管理などの運用機能は、標準的な仕組みへ置き換えることが望ましく、属人的な手作業から標準化・自動化すると、運用負荷とリスクの双方を下げられます。「縁の下の機能」もリストへ含めることが、安定稼働につながります。
大量の機器では、これらを一つずつ手作業で洗い出すのは現実的ではありません。ユニリタの事例では、200種・30,000台のネットワーク機器や10,000台のサーバーの通信ログを集計し、保守費の高い機器や利用実態を見える形にしました（出典：ユニリタ）。作業負担は約5分の1に軽減され、数億円規模の投資対効果が得られています。対象が広いほど、データに基づく絞り込みが更改の精度を高めます。
まとめ
対象範囲を四層と三分類で整理し、7RやIPAの手法と、更改時に見直す重点領域を見てきました。
更改の成否は、対象範囲を意図的に絞り込めるかどうかにかかっています。
期限が来ている層を特定し、残す・捨てる・載せ替えるに仕分けたうえで、期限の近い機能には軽い手法、時間が取れる機能には重い手法を当てます。この組み合わせの設計こそが、期限内に確実な更改を実現する鍵です。
riplaでは、現行システムの資産の洗い出しから対象範囲の見極め、手法の選定までを一気通貫で支援しています。どこから手をつけるべきか迷う段階でも、まずは現状の機能と期限を整理するところからご相談ください。
開発を相談する前に確認できる無料ホワイトペーパーを紹介します。
- レガシーシステム刷新の完全ガイドブックを読めます。
- 【2026年最新版】AI駆動開発の完全ガイドブックを読めます。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。