システムマイグレーションの費用相場は？規模別・方式別の目安とAIによる削減方法

システムの老朽化が進み、マイグレーション(移行)を検討し始めたものの、「一体いくらかかるのか」の見当がつかず動き出せない。そうしたご相談を多くいただきます。

この記事では、システムマイグレーションの費用相場を規模別・移行方式別に整理したうえで、費用の内訳、見積もりが膨らみやすい要因、そしてAIの活用によって費用がどう変わるのかを解説します。

規模別の費用相場

マイグレーションの見積もりは、対象システムの規模を基本に算出されるのが一般的です。規模の単位には「ステップ数」、つまりソースコードの行数がよく使われます。規模別のおおよその目安は次のとおりです。

ただし、これはあくまで一般的な目安です。同じ規模でも、コードの複雑さ・ドキュメントの有無・移行方式によって、実際の金額は数倍変わることがあります。「自社の場合はいくらか」については、後述する無料診断などで個別に概算を確認するのが確実です。

自社システムのステップ数がわからない場合でも、開発時の資料や保守ベンダーへの確認でおおよその規模を把握できます。見積もり依頼の前にわかる範囲で整理しておくと、話が早く進みます。

移行方式による費用の違い

同じシステムでも、どの方式で移行するかによって費用は大きく異なります。代表的な3方式の比較です。

リホストは安く早く済む一方、古いコードがそのまま延命されるため、保守人材の確保難や改修のしづらさといった根本的な課題は残ります。リビルドは理想的ですが、要件定義からやり直すため費用・期間とも最大になり、プロジェクトの難易度も上がります。

中間に位置するリライトは、「機能を変えずに技術だけを新しくする」現実的な選択肢です。従来は人手による書き換えとテストの工数が膨大で高額になりがちでしたが、この工数をAIで大きく圧縮できるようになったことが、近年の最も大きな変化です。

費用の内訳

マイグレーション費用の主な内訳は次のとおりです。

• 現行調査・解析：既存システムの構造・仕様・依存関係の調査
• 変換・実装：新しい言語・フレームワーク・基盤への書き換え
• テスト・検証：移行前と同じように動くことの確認
• 移行・切替：データ移行、本番切替、並行稼働
• プロジェクト管理：進行管理、品質管理、関係者調整

見落とされがちですが、マイグレーションではテスト・検証の比重が非常に大きいのが特徴です。「移行前とまったく同じように動くこと」を確認する作業に、プロジェクト全体の半分近い工数がかかることも珍しくありません。見積もりを比較する際は、テスト・検証にどれだけの工数が計上されているかを確認してください。テスト工程の工数が少ない見積もりは、一見安くても本番切替後の障害リスクを抱え込むことになります。

テスト工程の重さは業界の統計でも確認できます。IPAのソフトウェア開発分析データ集2022では、既存システムの機能仕様をほとんど変えずに作り直す再開発63件の工程別工数比率は、平均で製作0.326に対して結合テスト0.207、総合テスト0.163でした。2つのテスト工程を合わせると製作工程を上回ります。この集計にはマイグレーション特有の現行調査や新旧の動作比較は含まれていません。

見積もりが膨らむ要因

相場より高い見積もりが出てくる場合、多くは次のいずれかが原因です。

1. 設計書・仕様書が残っていない。現行調査に多くの工数がかかります
2. 仕様を知る担当者がいない。属人化により、動作の意図を推測しながら進めることになります
3. 長年の改修でコードが複雑化している。影響範囲の特定に時間がかかります
4. 移行中もシステムの改修を止められない。移行作業と並行して変更を取り込む必要があります

これらはいずれも「不確実性」に伴うリスク費用として見積もりに上乗せされます。逆に言えば、この不確実性を技術でカバーできるベンダーを選べば、費用は大きく下がる余地があります。

行数以外で費用を左右する要素

相場表がステップ数を軸にしているため、「行数を伝えれば金額が決まる」と思われがちですが、行数は指標の一つにすぎません。同じ10万ステップでも、定型的な画面が並ぶシステムと、複雑な業務ルールが集中したバッチ処理を抱えるシステムでは、解析と変換の手間もテストの難しさも別物です。仕様書の有無、外部システムとの連携の数、特殊な部品やライブラリへの依存、Web化のような仕様変更の有無、そして新旧の動作比較とテストの難易度など、行数のほかにもこうした要素が金額を左右します。

当社の見積では、対象システムの規模を基本に、コードや機能の複雑性、業務ロジック理解の必要度、インフラ基盤入れ替えの有無を加味して算出します。複雑性と業務ロジック理解の必要度は、行数を聞いただけでは判断できないため、無料診断でソースコードの一部を実際に解析して判断します。行数が少なくても業務ロジックが複雑なシステムは相場より高くなることがあり、行数が多くても定型的なコードが大半であれば相場より抑えられることもあります。

見積書を受け取ったときに、どの項目がどの根拠で積まれているのかを読み解く方法と、PoC(事前検証)で確認しておくべきことは、マイグレーションの見積方法で解説しています。

AI活用による費用の変化

生成AIの実用化により、マイグレーションの主要な工程は大きく効率化できるようになりました。

• コード解析：ドキュメントが残っていなくても、AIがソースコードから構造と仕様を読み取る
• コード変換：移行先の言語・フレームワークの規約に沿って、AIがコードを自動変換する
• テスト・検証：AIが「変換→検証→修正」のループを自律的に繰り返し、品質を作り込む
• ドキュメント生成：移行と同時に、最新のコードに対応した仕様書・設計書を生成する

先ほどの「見積もりが膨らむ4つの要因」のうち、ドキュメントの不在・属人化・コードの複雑化はいずれも、AIによるコード解析でカバーできる領域です。人手が前提だった時代に「高すぎて断念した」案件でも、AIを前提にすると現実的な金額に収まるケースが増えています。

当社のAIマイグレーションサービスでは、移行専用に独自開発したAIエージェントシステムにより、移行コスト・期間を従来手法の見積と比べて約60%削減しています。※当社実績案件(約25万行の基幹システム移行)で従来手法の見積と比較した値で、削減幅はシステム構成により変動します。

AIマイグレーションの仕組みや導入時の注意点は、AIマイグレーションとは？仕組みと効果、導入前に知っておきたい注意点で詳しく解説しています。また、FuelPHPで構築された約25万行の基幹システムを実際に移行したプロジェクトの詳細は、FuelPHPからLaravelへの移行事例で紹介しています。

移行費用を抑えるために発注側ができること

ベンダー選び以外にも、発注側の工夫で費用を抑えられるポイントがあります。

1. 対象範囲を絞る。使われていない機能や画面は移行対象から外します
2. 作業単位を分割して進める。システム全体を一度に変換するのではなく、業務単位・機能単位に分割して進めます。作業単位の分け方はAIマイグレーションの進め方で解説しています
3. 規模と構成を整理しておく。ステップ数・利用技術・連携システムをわかる範囲でまとめておきます
4. 複数の方式・ベンダーを比較する。同じ要件でも方式と体制により金額は大きく変わります
5. 小さく試せるベンダーを選ぶ。いきなり全体を発注せず、診断やPoCで品質と相性を確認してから進めます

まとめ

規模別・方式別の相場はあくまで出発点であり、実際の費用は「自社システムの状態」でほぼ決まります。検討の初期段階では、相場表だけで悩むよりも、実際のシステムに即した概算を無料で提示してくれるベンダーに診断を依頼するのが近道です。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は必須ではありませんので、お手元にないお客様もご安心ください。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. 概算見積もりを取るには何を用意すればよいですか？

システムの用途や利用者数といった概要と、ステップ数や画面数などおおよその規模感がわかれば概算は可能です。当社の無料診断では仕様書・設計書のご準備は必須ではなく、ソースコードから仕様を読み取ります。

Q. 期間はどのくらいかかりますか？

規模により数ヶ月〜1年以上と幅があります。従来は人手による書き換えとテストが期間の大半を占めていましたが、AIの活用により工期も費用と同様に短縮できるようになっています。規模別の目安と工程別の内訳はシステムマイグレーションの期間はどのくらい？で詳しく解説しています。

Q. 安さだけでベンダーを選ぶリスクはありますか？

あります。特にテスト・検証の工数を削った見積もりは、本番切替後の障害リスクに直結します。金額だけでなく、テストの範囲・方法と、移行後のドキュメントが納品されるかを確認することをおすすめします。