レガシーシステム刷新は、COBOLや汎用機（メインフレーム）、オフコンといった古い技術基盤を現代的なアーキテクチャへと移行する取り組みです。経済産業省が公表した「DXレポート」では、既存レガシーシステムを放置した場合、2025年以降に年間最大12兆円の経済損失が生じるリスクが指摘されており、企業は刷新を急務と捉えています。しかし多くの現場では「何を・どこまで変えるか」という対象範囲の整理が曖昧なまま着手してしまい、プロジェクト途中で想定外の影響範囲が浮上して計画が崩れるという失敗が繰り返されています。
刷新プロジェクトを確実に成功させるには、まず「見直すべき対象範囲を体系的に棚卸しすること」と「各対象範囲にどの刷新手法を当てるかを決めること」の両軸を押さえなければなりません。本記事では、COBOL・EBCDIC文字コード・バッチ運用などレガシー固有の見直し対象を7分類に整理し、AWSが体系化した7RやIPAの4分類といった主要な刷新手法の一覧と、各対象への当て方を解説します。費用・期間の目安も合わせて整理していますので、社内でのスコープ合意や検討ロードマップ策定にお役立てください。なお、刷新全体の進め方や工程管理については、レガシーシステム刷新の完全ガイドもあわせてご参照ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新で見直すべき対象範囲の全体像（資産の7分類）
レガシーシステムの刷新では、「アプリケーションを書き換えれば終わり」という誤解が根強くあります。しかし実際には、プログラム資産だけでなく、データ・バッチ・ハードウェア・外部連携・非機能要件・人的知識まで、多岐にわたる資産が刷新の対象となります。JUASの調査では約7割の企業がレガシー化を課題と感じていますが、その多くが対象範囲の定義不足によってプロジェクトを失敗させています。以下に、刷新時に棚卸し・見直すべき資産を7分類で整理します。
(1) プログラム資産（言語・フレームワーク）
最も直接的な見直し対象がプログラム資産です。COBOL・PL/I・RPGなど保守人材が枯渇しつつある言語で書かれたアプリケーション、さらにVB6やDelphiなど現代のIDE・クラウドに対応していない言語資産も対象となります。棚卸しでは、ソースコード本数・行数だけでなく、モジュール間の依存関係・循環参照・デッドコードの有無まで確認することが不可欠です。富士通の「ソフトウェア地図」のようなアプリ資産の複雑度・依存関係を可視化するツールを活用すると、リファクタリング優先度や刷新コストを精度高く見積もれます。
(2) データ資産（マスタ・トランザクション・文字コード）
データ資産の棚卸しは、プログラム資産と同等かそれ以上に重要です。メインフレーム環境ではEBCDIC文字コードが使われており、UTF-8やShift-JIS環境に移行する際に文字化けや桁落ちが生じるリスクがあります。特に全角カナ・旧字体・機種依存文字を含むマスタデータは、移行前に徹底したクレンジングが必要です。また、トランザクションデータの保有期間・件数・増加傾向を把握することで、クラウドDBの選定やパーティショニング設計に直結します。データベース方式がIMS（階層型）やIDMS（ネットワーク型）の場合、リレーショナル・NoSQLへの論理設計変換も対象範囲に含まれます。
(3) バッチ処理・ジョブ運用
基幹系レガシーシステムでは、夜間バッチが業務の根幹を担っているケースが大半です。JCL（Job Control Language）で定義された何百本ものジョブが複雑な依存関係で連鎖しており、ドキュメントが整備されていないことも珍しくありません。刷新時にはジョブスケジューラの棚卸し・依存関係マップの作成・処理の並列化余地の検討が必要です。クラウド化に際しては、AWS Batch・Azure Data Factory・GCPのCloud Composerなどへの置換、またはジョブスケジューラ製品（JP1・Hitachi JP1など）の継続活用か刷新かも判断対象となります。
(4) ハードウェア・汎用機・OS・ミドルウェア
メインフレーム（IBM System z等）・オフコン（NECのACOS、富士通のGS21等）・UNIXサーバーのEOL（サポート終了）は、ハードウェア更改の主な契機です。棚卸しでは、現行機のEOL時期・保守ベンダーの継続可否・仮想化対応状況を確認します。OSはz/OS・HP-UX・TruUNIX64など特定ベンダー依存が多く、Linuxへの移行検討が一般的です。ミドルウェアはTPモニタ（CICS・IMS TM等）・メッセージングミドルウェア・プリンタスプーラなども含まれ、これらが廃止になった場合の代替手段の検討まで対象範囲に含めます。
(5) 外部連携・周辺システム
基幹システムは、EDI・FTP・固定長テキスト連携など旧式プロトコルで周辺システムと密結合しているケースが多くあります。棚卸しでは、連携先システムの数・プロトコル・データフォーマット・連携タイミング（リアルタイム/バッチ）を一覧化します。刷新対象の基幹システムがAPIに切り替わると、連携先のシステムも改修が必要になるため、外部連携の影響範囲は必ず刷新計画に含めなければなりません。特にEDIは取引先との標準仕様（JEDICXや個社EDI）への対応確認が必要で、SaaSへの切り替えも選択肢として検討します。
(6) 非機能要件（性能・可用性・セキュリティ）
レガシーシステムでは非機能要件が暗黙の前提として蓄積しており、刷新後に「以前はできていたのに」という問題が発生しがちです。棚卸し対象としては、ピーク時のトランザクション数・バッチ処理の時間枠制約・RTO/RPO・セキュリティパッチ適用ポリシーなどがあります。メインフレームは高信頼性を前提とした設計になっているため、クラウドへ移行する際は可用性ゾーン設計・フェイルオーバー設定で同等以上の信頼性を担保することが求められます。また、暗号化方式・認証方式・アクセスログの取り方も現行基準（PCI DSS・ISO27001等）に合わせた見直しが必要です。
(7) 運用・保守体制と属人化したノウハウ
最後に、しかし非常に重要な棚卸し対象が「人的資産」です。COBOLやJCLを解読できるエンジニアは年々減少しており、特定の担当者しか知らない業務ロジック・障害対応手順・年次処理のノウハウがドキュメント化されていないまま放置されているケースが多々あります。刷新の対象範囲に「暗黙知の文書化・移転」を明示的に含め、ヒアリング調査やリバースエンジニアリングによる要件の可視化工程を計画に組み込むことが重要です。運用体制についても、ITILベースの運用設計への移行や、DevOpsを前提とした新組織・新プロセスへの切り替えを検討範囲に含めます。
刷新手法の一覧と各対象範囲への当て方（7R・IPA4分類）
対象範囲の棚卸しが完了したら、次は「各対象にどの刷新手法を適用するか」を決定します。現在、刷新手法の体系として最も広く参照されているのがAWSの7R（7つの移行戦略）とIPAの4分類です。それぞれの手法が「どのレガシー資産・どの状況に向くか」を理解することで、プロジェクト計画の精度が格段に向上します。
AWSの7Rと対象範囲別の適用指針
AWSが定義した7Rは、クラウド移行時の戦略選択に使われる7つのアプローチです。それぞれの手法について、先に整理した7分類の対象範囲との対応を示します。
Rehost（リホスト）: いわゆる「リフト＆シフト」。アプリケーションやOSをほぼそのまま仮想マシンやクラウドIaaSに移設します。変更コストが最小限で済む反面、レガシー構造はそのまま温存されます。対象: ハードウェア（汎用機のEOL対応）・OS移行に向く手法です。COBOLアプリをそのままLinux上のCOBOLランタイムで動かす構成も、広義のリホストに含まれます。
Relocate（再配置）: VMwareワークロードをVMware Cloud on AWSなどに再配置するように、インフラレベルで再配置する手法です。対象: ハードウェア・ミドルウェアの延命に適しています。
Replatform（リプラットフォーム）: データベースをRDS managed serviceに切り替えるなど、一部の基盤を最適化しながらアプリは大きく変えない手法です。対象: データ資産（DBエンジン切替）・ミドルウェア（TPモニタのAPIゲートウェイ化）などに向きます。
Repurchase（リパーチェス）: 既存カスタムシステムをSaaS製品に置き換える手法です。対象: 外部連携（EDI SaaS化）・周辺業務系（HR・会計・CRM）の刷新に最も適しています。
Refactor（リファクタ）: アーキテクチャを根本から見直し、マイクロサービス化・クラウドネイティブ化を図る手法です。対象: プログラム資産（COBOLのJava/Pythonへの書き換え）・バッチ処理のAPI・イベント駆動化に向く最も変革度が高い手法です。
Retire（廃止）: 使われていない機能・システムを廃止します。対象: プログラム資産のデッドコード・廃止業務システムが該当します。棚卸しで見つかった不要機能はこの手法を積極的に適用することで、全体コストを圧縮できます。
Retain（現状維持）: 刷新対象外とする判断です。コンプライアンス上の理由や刷新コスト対効果が低い資産は意図的に現状維持とします。対象: 非機能要件を満たしている安定稼働中の補助システムが典型例です。
IPAの4分類と対象範囲への当て方
IPAは国内基幹系レガシーを念頭に、刷新手法を4つに分類しています。7Rと重複する概念もありますが、日本のメインフレーム・オフコン環境により即した分類です。
リビルド: 現行システムの機能仕様を維持しつつ、新技術・新アーキテクチャで全面再構築する手法です。7RのRefactorに近く、COBOLアプリをJavaや.NETで書き直す場合がこれに当たります。対象: プログラム資産・バッチ処理・データ資産の論理設計変換に適しています。変革度が最も高く、コスト・期間も最大規模となります。
リライト: ソースコードレベルで自動変換ツール等を活用し、言語・プラットフォームを切り替える手法です。COBOL→Javaの自動変換ツール（Micro FocusのEnterprise Analyzerなど）を使い、機能ロジックを維持したままコードを変換します。対象: プログラム資産（言語変換）が主な対象で、バッチロジックの保持が重要な場合に選択されます。
リホスト: 7RのRehost・Relocateに対応。対象: ハードウェア・OS・ミドルウェアの移設が主目的の場合に選択します。アプリに手を加えないため最短期間での移行が可能ですが、構造的負債は温存されます。
ハードウェア更改: 汎用機・オフコンをより新しいハードウェアや汎用サーバー・仮想化基盤に置き換える手法です。対象: ハードウェア・OSに限定した最小変更の手法で、アプリ・データ構造は維持します。EOL対応の緊急措置として選ばれることが多いです。
対象範囲×手法の選択マトリクス（整理）
以下に、7分類の対象範囲ごとに適用しやすい手法を整理します。
(1) プログラム資産（COBOL等）: Refactor（リビルド）・Retire（廃止）・Replatform（リライト自動変換）
(2) データ資産（EBCDIC含む）: Replatform（DBエンジン刷新）・Refactor（論理設計変換）
(3) バッチ処理・ジョブ運用: Refactor（クラウドネイティブジョブ化）・Replatform（クラウドジョブスケジューラへ移行）
(4) ハードウェア・汎用機・OS: Rehost・Relocate・ハードウェア更改
(5) 外部連携・周辺システム: Repurchase（SaaS化）・Replatform（API化）・Retire（廃止）
(6) 非機能要件: Refactor（可用性・セキュリティ設計の刷新）・Replatform（マネージドサービス活用）
(7) 運用・属人化ノウハウ: Refactor（運用設計・ドキュメント整備）・Retain（一部維持しながら段階移行）
手法別の費用・期間とポートフォリオアプローチ
刷新手法を選定する際、費用と期間の目安は意思決定の重要な判断基準です。しかし、現実のレガシーシステム刷新プロジェクトでは単一の手法だけで完結することはほとんどなく、対象資産ごとに異なる手法を組み合わせる「ポートフォリオアプローチ」が求められます。以下に費用・期間の目安と、ポートフォリオアプローチの考え方を解説します。
手法別の費用・期間目安
手法ごとの費用・期間の概算を以下に整理します。なお、実際のプロジェクトコストはシステム規模・複雑度・並行稼働期間等によって大きく変動します。
クラウド移行型（Rehost・Relocate・ハードウェア更改）
費用目安: 数百万〜1,000万円台
期間目安: 3〜6ヶ月
特徴: アプリを変更しないため最小コスト・最短期間。ただし構造的負債は残存し、将来的な再刷新が必要になる可能性があります。
再構築型（Refactor・リビルド・リライト）
費用目安: 2,000万〜数千万円規模（大規模では1.5億〜5億円超）
期間目安: 12〜18ヶ月以上（大規模では3〜5年）
特徴: 変革度が最大で、技術的負債の根本解消につながります。一方、要件定義・設計工程が長く、SI費用が全体の60〜75%を占めるのが一般的です。
小〜中規模（単一業務システム）の刷新
費用目安: 3,000万〜1.5億円
期間目安: 6〜18ヶ月
特徴: 周辺系・サブシステムの刷新に多いパターンで、SaaS置換（Repurchase）や一部Replatformが選ばれるケースが多いです。
中〜大規模（基幹＋複数周辺）の全面刷新
費用目安: 1.5億〜5億円
期間目安: 18ヶ月〜5年
特徴: 対象範囲が広いため、ポートフォリオアプローチによる段階的な刷新が不可欠です。全工程を一括（ビッグバン）で完了させようとすると、リリース直前の障害・手戻りリスクが極めて高くなります。
ポートフォリオアプローチの重要性
ポートフォリオアプローチとは、全資産に同一の刷新手法を一律に適用するのではなく、各対象資産の重要度・複雑度・コスト対効果に応じて最適な手法を個別に割り当てる考え方です。たとえば同一の基幹システムでも、「会計モジュールはRefactor（リビルド）、帳票出力はRepurchase（SaaS化）、旧式EDI連携はRetire（廃止）、人事マスタのみReplatform」という組み合わせが現実的な解となることが多いです。
ポートフォリオアプローチを実践する上で重要なのがストラングラーパターン（Strangler Fig Pattern）の採用です。ストラングラーパターンとは、一気にシステム全体を切り替える「ビッグバン移行」を避け、機能単位で新旧システムを並行稼働させながら段階的に古い機能を新システムへ置き換えていく手法です。たとえばオーダー管理の新システムを先行稼働させ、在庫管理・出荷管理・請求管理を順次移行することで、各ステップのリスクを限定できます。
ポートフォリオアプローチを成功させるポイントは以下の3点です。
1. 対象資産の棚卸しを完了させてから手法を選択する（棚卸し前の手法決定は禁物）
2. 各資産の「ビジネス価値」と「技術的負債の深刻度」をマトリクスで評価し、優先順位を設ける
3. 段階移行計画を立て、各フェーズのスコープ・判断ゲート・ロールバック条件を明確にする
対象範囲の定義精度を上げるための実践ポイント
対象範囲の棚卸し精度を高めるために、実務で有効とされる方法をいくつか紹介します。まずドキュメントのリバースエンジニアリングです。既存ドキュメントが乏しい場合、富士通の「ソフトウェア地図」のような可視化ツールを使ってソースコード・JCL・DB定義から依存関係マップを自動生成することで、調査工数を大幅に削減できます。
次に現場ヒアリングによる暗黙知の掘り起こしです。COBOLエンジニアや業務担当者へのインタビューを構造化し、「障害が起きたときどう対応しているか」「年次処理で特別に気をつけている点は何か」など、ドキュメントに現れない運用知識を吸い上げます。この工程を怠ると、刷新後に不可解な障害が頻発する原因になります。
さらにインベントリシートの整備も有効です。対象システム・モジュール・連携先・データフロー・担当者・EOL情報をスプレッドシートで一元管理し、プロジェクト関係者が常に参照できる状態にします。このインベントリが、後工程の手法選択・工数見積もり・テスト計画の土台となります。
まとめ：対象範囲の棚卸しが刷新成功の鍵
本記事では、レガシーシステム刷新で見直すべき対象範囲を7分類（プログラム資産・データ資産・バッチ処理・ハードウェア・外部連携・非機能要件・運用ノウハウ）に整理し、7R（Rehost/Relocate/Replatform/Repurchase/Refactor/Retire/Retain）とIPAの4分類（リビルド/リライト/リホスト/ハードウェア更改）を「どの対象範囲にどの手法を当てるか」という視点から解説しました。さらに費用・期間目安と、ポートフォリオアプローチ・ストラングラーパターンの重要性についてもご説明しました。
レガシーシステム刷新で失敗しないための最大のポイントは、「手法を先に決めない」ことです。先に手法（クラウド移行や全面再構築）を決めてから対象範囲を当てはめようとすると、資産の実態に合わない計画が生まれ、手戻りや予算超過につながります。正しい順序は、まず対象資産を7分類で棚卸しし、各資産のビジネス価値・技術的負債の深刻度・移行コストを評価した上で、最適な手法を割り当てていくことです。この「対象範囲起点の考え方」こそが、2025年の崖（年間最大12兆円の経済損失リスク）を乗り越えるための実務的なアプローチといえます。
COBOLや汎用機・EBCDICデータといったレガシー固有の課題は、一般的なシステム移行とは異なる専門知識と経験を要します。刷新プロジェクトの計画立案から対象範囲の棚卸し、手法選択・ポートフォリオ策定まで、経験豊富なパートナーとともに進めることを強くおすすめします。