結論: 刷新費用は「規模 × 移行難易度」で決まる

レガシーシステムのリプレイスを検討するとき、発注者が最初に知りたいのは「結局いくらで、どのくらいかかるのか」だと思います。先に結論から書きます。費用と期間は、ほぼ「規模(作り直す範囲の大きさ)× 移行難易度(止められなさ・データの厄介さ)」で決まります。FIXIT が AI 駆動開発のクリエイティブスタジオとして関わってきた実案件のレンジを規模別にまとめると、次の早見表になります。

規模内容の目安費用レンジ(税抜)期間の目安
部分リプレイスフロントエンドのみ刷新 / 業務画面 2〜3 本の先行刷新500 万〜1,000 万円1〜2 か月
中規模刷新数ドメインの業務システム / API のリアーキテクチャ1,200 万〜2,500 万円2〜4 か月
基幹システム刷新全ドメインの作り直し / 基幹連携・大規模データ移行を含む2,500 万〜4,500 万円4〜6 か月

このレンジは「同じものを従来開発で作り直した場合より安く・早い」数字である点に注意してください。後述するように、AI 駆動開発ではレガシー刷新の期間がおおむね半分になりますが、費用が同じ比率で半分になるわけではありません。期間が縮んでも、既存仕様の調査精度やデータ移行の検証工数は削れないからです。このギャップを理解しておくと、相場から外れた見積もりに気づきやすくなります。

刷新そのものをどう進めるかの全体像は システム刷新サービス にまとめていますが、本記事では「いくら・どのくらい」という数値面に絞って、実案件の実数値で内訳まで掘り下げます。

費用が変動する 5 つの要因

同じ「業務システムをリプレイスする」でも、費用は倍以上変わることがあります。見積もりを取る前に、自社のシステムがどこに当てはまるかを把握しておくと、提示金額の理由が読めます。差を生むのは主に次の 5 つです。

1. コード行数(作り直す総量)

最も素直な変数です。フロントエンド、バックエンド、バッチ処理を合わせた総行数が増えるほど、読み解きと書き直しの両方で工数が増えます。ただし行数は「目安」にすぎません。10 万行でも単純な CRUD 中心なら軽く、3 万行でも複雑な業務計算が絡むと重いからです。行数は最初の規模感を掴むための入口として使い、次のドメイン数と合わせて見るのが実務的です。

2. ドメイン数(密結合の度合い)

受注・在庫・出荷・請求のように、システムがいくつの業務ドメインで構成され、それらがどれだけ密結合になっているかが、設計と移行の難易度を大きく左右します。ドメインが密結合だと「機能 1 つの変更が他の機能に波及する」ため、切り分けながら段階移行する設計に手間がかかります。実案件では、ドメインを依存関係から並べ替えて移行順序を決める作業自体が、計画フェーズの大きな比重を占めました。

3. データ移行の難易度

レガシー刷新でコストが読みにくいのが、ここです。旧 DB から新 DB への ETL は、データ量だけでなく「データの汚れ具合」で工数が決まります。NULL 許容のカラム、半角全角の混在、SJIS 由来の文字化け、過去の運用で生まれた不整合レコードなど、エッジケースが多いほど移行スクリプトの作り込みと検証回数が増えます。データが綺麗なら数十万円で済む移行も、汚れていれば数百万円規模になり得ます。

4. 業務停止制約(止められなさ)

24 時間稼働の基幹システムのように「業務を止められる時間が限られる」ほど、カットオーバーの難易度が跳ね上がります。停止枠が 4 時間しかないなら、その枠内で確実に移行を終えるために ETL のリハーサルを何度も繰り返す必要があり、その分の工数が上乗せされます。逆に夜間や週末に長時間の停止が許されるなら、移行の段取りはずっと楽になり費用も抑えられます。

5. 現行ドキュメントの有無

設計書や仕様書が残っているか、現行の挙動が把握できているかで、棚卸し(調査)工数がまったく変わります。「設計を知っている人がもういない」「ドキュメントが実態と食い違っている」という状況では、コードを解析して仕様を復元するところから始める必要があり、調査だけで相応の工数がかかります。後述するように、この読み解き工程こそ AI 駆動開発で最も短縮効果が出る領域です。

この 5 つのうち、発注側が事前にコントロールしやすいのは「作り直す範囲(コード行数・ドメイン数)」と「業務停止制約の緩和」です。初回フェーズで刷新範囲を絞り、停止枠を確保できるよう業務側と調整しておくだけでも、費用とリスクをかなり抑えられます。

規模別の費用・期間レンジ

冒頭の早見表をもう少し具体的に分解します。それぞれの規模で、どんな状態のシステムが対象になり、何に費用がかかるかを整理します。費用はすべて税抜です。

部分リプレイス: 500 万〜1,000 万円・1〜2 か月

古いフロントエンドだけを Next.js + TypeScript に切り出す、あるいは特に古びた業務画面を 2〜3 本だけ先行して刷新するケースです。バックエンドや DB は当面そのまま残し、影響範囲を限定します。エンジニア採用が難しい古いフロント技術から脱却したい、まず効果を確かめてから全体刷新に進みたい、という場合の入口として有効です。費用の大半は実装とテストで、データ移行が絡まないぶん見積もりも読みやすくなります。

中規模刷新: 1,200 万〜2,500 万円・2〜4 か月

数個の業務ドメインを作り直す、あるいは密結合な API をドメインごとに分割してリアーキテクチャするケースです。フロントエンドとバックエンドの両方に手を入れ、対象ドメインのデータ移行も伴います。費用を押し上げるのは、ドメイン間の依存を解きほぐす設計と、移行データの検証です。多くの案件がこのレンジに収まります。

基幹システム刷新: 2,500 万〜4,500 万円・4〜6 か月

全ドメインを作り直し、基幹システムとの連携や大規模なデータ移行を含む、最も重いケースです。業務停止制約が厳しく、ドキュメントが残っていないことも多いため、棚卸しと移行設計に大きな比重がかかります。AI はこの調査・移行の工程をかなり速くできるため、従来開発に比べて期間短縮の効果が最も出やすい領域でもあります。刷新の全体手順は システムリプレイスの進め方ガイド で工程ごとに整理しているので、進め方の段取りはそちらも参照してください。

実案件の内訳例: 工数はどこに配分されるか

「総額 2,000 万円」と言われても、内訳が分からなければ妥当性は判断できません。ここでは実際の流通業の基幹システム刷新案件を例に、工数がどこに配分されたかを示します。年商 100 億規模の卸売・流通業者で、受注・在庫・出荷・請求を含む 14 ドメインを刷新し、通常見積もり 8 か月・9 人月の規模を 4 か月・4.5 人月で完了させた案件です。詳細は レガシーシステムを半分のコストで刷新した事例 にまとめています。

レガシー刷新の工数配分は、新規開発とは比重が異なります。標準的な配分はおおむね次のようになります。

工程工数配分の目安中身
棚卸し・調査15〜25%現行仕様の解析、ドメイン責務マップ、暗黙の業務ルールのドキュメント化
移行設計・計画10〜15%移行順序の決定、ウェーブ分割、並行運用の設計
実装(新フロント / 新 API)25〜35%テスト先行での機能開発、AI を使った実装
データ移行15〜25%ETL スクリプト作成、差分検証、リハーサル
並行運用・カットオーバー10〜20%段階リリース、Feature Flag 運用、本番移行

新規開発と比べて目立つのは、棚卸し・調査とデータ移行の比重が大きい点です。新規ならゼロから作るだけですが、刷新は「既存の挙動を保ったまま作り直す」ため、現行仕様を正しく把握する工程と、データを欠損なく移す工程が不可欠になります。この案件ではデータ移行の ETL リハーサルを合計 23 回実施し、4 時間の業務停止枠内で完全移行を完了させました。逆に言えば、見積書でこの 2 つの工程がほとんど計上されていない場合は、後から工数が膨らむか、移行事故のリスクを抱えているサインです。

AI 駆動開発で期間と工数を半分にできる理由

前述の流通業の案件では、通常見積もり 8 か月・9 人月が 4 か月・4.5 人月になりました。なぜ半分に縮むのか、仕組みを押さえておくと見積もりの妥当性を判断しやすくなります。

従来のレガシー刷新で最も時間を食っていたのは、実装そのものではなく「既存システムの読み解き」と「データ移行の検証」でした。AI 駆動開発では、ここに Claude Code や Cursor といった AI エージェントを実プロジェクトに組み込みます。

読み解きの工程では、Claude Code に既存のコードベース、既存テスト、過去の障害履歴を読み込ませ、ドメイン責務マップ・触ると危険なホットスポット一覧・暗黙の業務ルールを、引用元の行番号付きで短期間にドキュメント化します。前述の案件では最初の 2 週間でドキュメントが 100 ページ近く揃い、棚卸しの所要工数が従来の 1/3〜1/4 になりました。人間が「仕様を全部把握してから書き直す」のではなく、AI に読み解かせて人間が判断する協業に切り替えるのが要点です。

実装の工程では、テストを先に書いて AI に実装を生成させるスタイルを採ります。刷新案件では「既存システムの仕様 = テスト」という対応関係が直感的で、「既存挙動を保ったままモダンスタックに書き直して」と明確な指示が出せるため、AI との相性が特に良くなります。この進め方は AI 駆動 TDD で詳しく扱っています。データ移行も、業務ルールを文章で渡すと SQL と TypeScript の移行スクリプトが生成され、結果差分を自動テストで検証する流れにできます。データ移行リハーサルの実務（停止枠から逆算した検証）は データ移行リハーサルの進め方 で詳しく扱っています。

ただし、すべての工程が同じだけ速くなるわけではありません。要件の合意形成、非機能要件の検討、本番移行の段取りといった「人と話して決める」「責任を持って判断する」工程は AI に置き換えられません。だからこそ、期間は半分になっても費用は半分にならないのです。AI で浮いた時間を、移行の検証と品質の作り込みに再投資する。これが速度と品質を両立させる刷新の費用構造です。刷新を AI 駆動でどう進めるかは レガシーモダナイゼーションサービス にも整理しています。

相見積もりで確認すべき項目と、安すぎる見積もりの注意点

刷新は金額が大きく、発注先選びの失敗が痛いため、相見積もりを取る方が多いと思います。金額の高低だけで判断すると失敗しやすいので、次の項目を揃えて比較してください。

  • 棚卸し(現行仕様の調査)とデータ移行の工数が明示的に計上されているか
  • 前提条件(対象ドメイン数、移行対象のデータ量、業務停止枠、対応環境、運用範囲)が文書で明記されているか
  • 移行のリハーサル回数とカットオーバー手順、切り戻し(ロールバック)の段取りが見積もりに含まれているか
  • 「AI で速い」の中身、つまり AI が書いたコードと移行スクリプトを誰がどうレビューし品質を担保するのかが説明できるか
  • 検収の基準と、カットオーバー後の不具合対応(瑕疵対応)の範囲・期間が決まっているか

発注者がいちばん不安なのは「高すぎないか」よりむしろ「安すぎないか」かもしれません。明確に相場を下回る刷新見積もりには、たいてい理由があります。よくあるのは、棚卸しとデータ移行の工数がほとんど計上されておらず実装だけで金額が組まれている、前提条件が「一式」とだけ書かれて対象範囲や停止枠が明記されていない、というパターンです。こうした見積もりは、現行仕様の調査不足で後から追加費用がかさむか、移行事故でカットオーバーが失敗するか、どちらかになりがちです。

逆に高めの見積もりでも、棚卸し・移行・リハーサルが丁寧に積まれているなら根拠のある金額です。レガシー刷新では「調査と移行にどれだけ工数を割いているか」が、その会社の刷新経験の深さをそのまま映します。

まとめ

レガシー刷新の費用は、部分リプレイスで 500 万〜1,000 万円、中規模刷新で 1,200 万〜2,500 万円、基幹システム刷新で 2,500 万〜4,500 万円(いずれも税抜)が実案件レンジの目安です。費用と期間は「規模 × 移行難易度」で決まり、コード行数・ドメイン数・データ移行の難易度・業務停止制約・現行ドキュメントの有無という 5 つの変数が金額を左右します。AI 駆動開発を使うと、読み解きとデータ移行の検証が速くなるため期間はおおむね半分に縮みますが、要件定義と品質保証の工数は削れないため費用は同じ比率では下がりません。見積もりを読むときは、棚卸しとデータ移行の工数、前提条件、リハーサルとカットオーバーの段取りが明記されているかを確認してください。

自社のシステムがいくら・どのくらいで刷新できるか、概算を知りたい方は 無料相談 からお問い合わせください。既存システムの状態を伺えれば、規模感と費用レンジの当たりをつけるお手伝いをします。刷新の進め方そのものは システム刷新サービス もあわせてご覧ください。