目次
「移行にいくらかかるのか」。レガシーシステムの刷新を検討し始めた情シス担当者が、最初にぶつかる壁がこの問いだ。ベンダーに見積もりを依頼しても、金額の妥当性を判断できない。社内で予算を確保しようにも、根拠となる数字がない。本記事では、レガシーシステム移行の費用相場を規模別・言語別に整理し、見積もりの内訳やコスト削減のポイントを具体的な数字で解説する。
レガシーシステム移行の費用が読みにくい理由
移行費用の見積もりが難しいのには、構造的な原因がある。まず、その背景を押さえておきたい。
「現行システムの中身がわからない」という根本問題
JUAS(日本情報システム・ユーザー協会)の「企業IT動向調査2025」によると、レガシーシステムが残存している企業は依然として6割を超えている(出典:JUAS 企業IT動向調査2025)。問題は、これらのシステムの多くが「ブラックボックス化」していることだ。設計書が散逸し、開発当時の担当者もいない。そもそも何がどう動いているのか、正確に把握できていない。
この状態で見積もりを取ると、ベンダー側もリスクを織り込んだ金額を提示せざるを得ない。結果として、見積もりが膨らむ。あるいは、着手後に想定外の改修が発覚し、追加費用が発生する。
IT予算の8割が「守り」に消えている現実
経済産業省のDXレポートでは、日本企業のIT予算の約8割が既存システムの維持・運用に費やされていると指摘されている(出典:経済産業省 DXレポート)。移行のための新規投資に回せる余力が少ない。限られた予算だからこそ、費用の相場感と内訳を把握しておく必要がある。
レガシーシステム移行の費用相場|規模別の目安
移行費用は、対象システムの規模によって大きく異なる。ここでは3つの規模帯に分けて目安を示す。
小規模システム(機能数:数十程度)
| 項目 | 目安 |
|---|---|
| 費用レンジ | 2,000万〜8,000万円 |
| 期間 | 3〜6ヶ月 |
| 想定人月 | 20〜80人月 |
| 典型例 | 部門内の業務ツール、小規模Webアプリ |
部門単位で使われている業務システムや、限定的な機能を持つWebアプリが該当する。依存関係が限定的なため、比較的見通しが立てやすい。ただし、VB6やAccess系のツールは画面数が少なくてもロジックが複雑に絡み合っているケースがある。見た目の規模だけで判断しないことが重要だ。
中規模システム(機能数:数十〜数百)
| 項目 | 目安 |
|---|---|
| 費用レンジ | 5,000万〜3億円 |
| 期間 | 6〜18ヶ月 |
| 想定人月 | 50〜300人月 |
| 典型例 | 複数部門にまたがる販売管理、在庫管理 |
複数部門で利用される基幹系サブシステムが該当する。外部システムとの連携、バッチ処理の移行、データマイグレーションなど、考慮すべき要素が増える。この規模帯が最も見積もりのブレ幅が大きい。
IPA(情報処理推進機構)のソフトウェア開発分析データ集では、開発規模500FP(ファンクションポイント)以上のプロジェクトで工期・工数ともにばらつきが顕著になることが報告されている(出典:IPA ソフトウェア開発分析データ集2022)。
大規模システム(全社基幹・ホスト刷新)
| 項目 | 目安 |
|---|---|
| 費用レンジ | 2億〜10億円超 |
| 期間 | 1〜3年 |
| 想定人月 | 300人月〜 |
| 典型例 | ERPリプレイス、メインフレーム脱却 |
全社の基幹システムやメインフレームの刷新が該当する。プロジェクト体制も大規模になり、PMO(プロジェクトマネジメントオフィス)の設置やベンダー複数社の統括が必要になる。10億円を超える案件も珍しくない。
レガシーシステム移行の費用相場|言語・技術別の特徴
移行費用は、現行システムの技術スタックによっても大きく変動する。主要な言語・技術別に特徴を整理する。
COBOL(メインフレーム系)
COBOLからJavaやC#への移行は、レガシーマイグレーションの中でも最も費用が高くなりやすい。理由は3つある。
1つ目は、COBOL技術者の人月単価が高騰していること。ベテラン技術者の退職が進み、市場に残るCOBOL経験者の単価は上昇傾向にある。2つ目は、ソースコード行数が膨大なケースが多いこと。数十万〜数百万ステップに及ぶシステムも存在する。3つ目は、業務ロジックがプログラムに直接埋め込まれており、仕様の抽出に時間がかかること。
自動変換ツールを使う場合の目安として、ソースコード1行あたり0.5〜3.0ドル程度が業界水準とされる。ただし、自動変換後の手修正工数が全体コストの30〜50%を占めるケースも報告されている(出典:日経クロステック「COBOLシステムの移行で見逃しがちなあの費用」)。
VB6 / VBA / Access
VB6やAccessで構築された業務ツールは、中堅企業に多く残っている。画面数やロジック量が一見少なく見えても、以下の理由で費用が膨らむ傾向がある。
- スプレッドコントロール(表計算コンポーネント)が多用されている場合、移行先での再実装に工数がかかる
- イベントドリブンな処理構造のため、単純な言語変換では移行できない
- テストデータやテスト手順が文書化されていないケースが多い
小規模なVB6ツールの移行でも、1,000万〜3,000万円程度は見込む必要がある。
Java(古いフレームワーク)
StrutsやSpring Boot 1.x系で構築されたJavaシステムの移行は、言語そのものは変わらないため比較的コストを抑えやすい。フレームワークのバージョンアップと周辺ライブラリの互換性対応が中心になる。費用の目安はシステム規模によるが、同規模のCOBOL移行と比べて50〜70%程度に収まることが多い。
ただし、独自フレームワークを組み込んでいる場合は別だ。解読と再設計の工数が大幅に増加する。
PHP(レガシーバージョン)
PHP5系やCakePHP 2.x、FuelPHPなど、サポートが終了したバージョンで動いているシステムは、セキュリティリスクが喫緊の課題になる。移行費用そのものはJavaやCOBOLに比べて低い傾向にあるが、テスト工数が想定以上にかかるケースがある。型宣言が緩い言語特性上、移行後の動作保証に手厚いテストが必要になるためだ。
PHPレガシーシステムの移行判断基準については、レガシーPHP診断の記事で詳しく解説している。
移行費用の内訳|見積もりのどこに費用がかかるのか
見積書の金額だけを見ても、妥当性は判断できない。内訳を理解しておくことが交渉の前提になる。
費用内訳の標準的な構成比
| 工程 | 構成比の目安 | 内容 |
|---|---|---|
| 要件定義・設計 | 30〜40% | 現行調査、要件整理、移行方式の決定 |
| 実装・変換 | 25〜35% | コーディング、自動変換、手修正 |
| テスト | 20〜30% | 単体・結合・総合テスト、移行リハーサル |
| データ移行 | 10〜20% | データクレンジング、変換、検証 |
| PM・品質管理 | 10〜15% | 進捗管理、品質レビュー、リスク管理 |
注目すべきは「要件定義・設計」の比率が最も高い点だ。これは現行システムの調査に膨大な工数がかかることを意味する。仕様書が残っていないシステムでは、リバースエンジニアリングでコードから仕様を復元する作業が必要になる。この工程の工数が見積もり全体を左右する。
人月単価の相場感
開発工程の人月単価は、技術者のスキルレベルと役割によって異なる。2025年時点の一般的な相場は以下のとおりだ。
| 役割 | 人月単価の目安 |
|---|---|
| プロジェクトマネージャー | 100〜150万円 |
| アーキテクト・上級SE | 80〜130万円 |
| SE(中堅) | 60〜100万円 |
| プログラマー | 40〜70万円 |
COBOL技術者やメインフレーム経験者は、上記より2〜3割高くなる傾向がある。希少性がそのまま単価に反映されている。
移行費用を抑える4つのポイント
限られた予算でプロジェクトを成功させるために、実務で有効なコスト削減のアプローチを4つ紹介する。
1. 移行前に現行システムを可視化する
見積もりの精度を上げる最も効果的な方法は、移行対象の構造を事前に把握しておくことだ。システムの全体像、モジュール間の依存関係、データフローが可視化されていれば、ベンダーはリスクバッファを最小限に抑えた見積もりを出せる。
「何がどう動いているかわからない」状態で見積もりを依頼すると、不確実性の分だけ金額が上乗せされる。事前の可視化投資は、移行コスト全体の削減に直結する。
システム刷新のROI算出方法については、ROI算出の記事で詳しく解説している。
2. 段階的に移行する
全システムを一括で移行する「ビッグバン方式」は、失敗リスクが高い。優先度の高いサブシステムから段階的に移行する「段階移行方式」のほうが、初期投資を分散でき、途中での軌道修正も可能になる。
まずは最もリスクの高い部分、たとえばセキュリティ脆弱性が深刻なモジュールや、保守コストが突出して高い領域から着手するのが定石だ。
3. 自動変換ツールを活用する
COBOLからJavaへの変換やフレームワークのバージョンアップでは、自動変換ツールの活用がコスト削減に有効だ。手作業による全面リライトと比べて、工数を40〜60%削減できるケースもある。
ただし、自動変換ですべてが解決するわけではない。変換後のコードが可読性に欠ける場合や、業務ロジックの再検証が必要な場合は、追加の手修正工数を見込んでおく必要がある。
4. AI解析で調査工数を削減する
近年、AIを活用してレガシーシステムの構造解析を自動化するアプローチが広がっている。NTTデータの事例では、COBOLソースコードから設計書を自動復元する技術が実用化されている(出典:NTTデータ「レガシーシステムのモダナイゼーションを加速する、生成AIの活用法」)。
移行プロジェクトの費用内訳で最大の比率を占める「要件定義・設計」工程の工数を削減できるため、プロジェクト全体のコストに与えるインパクトが大きい。大和総研のレポートでも、生成AIの活用によりプロジェクトコストを最大40%削減できる可能性が指摘されている(出典:大和総研「レガシーマイグレーションとは?AI活用の動向を解説」)。
「移行にいくらかかるのか」を正確に知るには、まず現行システムの構造を把握する必要がある。
SysDockは、AIマルチエージェントがソースコードを解析し、システムの全体像をWord・PowerPoint・React Flowフロー図の3点セットで可視化する。ソースコード非送信、1週間納品、完全後払い。移行見積もりの前に、まず構造を把握する——その第一歩を30万円から。
まとめ
レガシーシステム移行の費用は、規模・言語・現行システムの状態によって大きく変動する。本記事のポイントを整理する。
- 規模別の費用目安は、小規模で2,000万〜8,000万円、中規模で5,000万〜3億円、大規模で2億〜10億円超。中規模帯のブレ幅が最も大きく、見積もり精度の確保が特に重要になる。
- 言語別では、COBOL移行が最も高コスト。技術者の希少性、コード量の多さ、業務ロジックの埋め込みが主な要因だ。VB6やAccess系も、見た目以上に費用がかかるケースが多い。
- 費用の最大構成要素は「要件定義・設計」工程。現行システムの調査に工数がかかるため、事前の可視化によって見積もり精度を上げることがコスト削減の鍵となる。
- AI活用による工数削減は現実的な選択肢。構造解析の自動化や自動変換ツールの併用で、プロジェクト全体のコストを大幅に圧縮できる可能性がある。
移行の見積もりを依頼する前に、自社システムの構造を正確に把握しておくこと。それが、予算の精度とプロジェクトの成功率を同時に高める最善の手段だ。
SysDockの料金体系と納品物の詳細は、料金体系の記事で確認できる。
よくある質問(FAQ)
Q. 移行費用の見積もりは無料で取れますか?
A. 多くのベンダーが初回の概算見積もりを無料で対応している。ただし、正確な見積もりには現行システムの調査が必要になり、その調査費用が別途発生するケースが一般的だ。SysDockの構造解析レポートがあれば、調査工数を短縮でき、見積もり精度も向上する。
Q. 自動変換ツールだけで移行は完了しますか?
A. 自動変換はあくまで移行作業の一部だ。変換後のコードレビュー、業務ロジックの検証、テストは人手による作業が不可欠になる。自動変換で削減できるのは実装工程の40〜60%程度と考えるのが現実的だ。
Q. クラウド移行とオンプレ移行では費用はどちらが高いですか?
A. 初期費用はクラウド移行のほうが低くなる傾向がある。ただし、クラウドのランニングコストは月額で発生するため、5年単位のTCO(総所有コスト)で比較する必要がある。JUAS企業IT動向調査2025でも、クラウドランニングコストの上昇がIT予算に影響を与えていると報告されている。
Q. 移行中に現行システムの運用は止まりますか?
A. 段階移行方式であれば、現行システムの運用を継続しながら移行を進められる。本番切り替え時に短時間の停止が発生するケースはあるが、並行稼働期間を設けることでリスクを最小限に抑えられる。
現場改善に役立つ関連ツール
GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。
移行費用シミュレーター
4つの質問で、システム移行の概算費用レンジがわかります。
システムの規模感は、どのくらいですか?
正確にわからなくても大丈夫です。感覚で選んでください
どの言語で作られているか、ご存知ですか?
聞いたことがある程度でOKです。不明なら「わからない」で
移行・刷新のスケジュール感は?
社内の温度感で選んでください
移行の見積もりは、すでに取っていますか?
ベンダーからの提案・見積書の有無