基幹システムのリプレイスとは？費用相場・移行方式・AI活用まで発注者向けに整理【2026年】

基幹システムのリプレイス（再構築・入れ替え）は、多くの企業にとって10年前後に一度しか訪れない大型プロジェクトです。それだけに社内に経験者がいないことが多く、「何から手を付ければよいのか」「費用はいくらかかるのか」「どの方式を選べばよいのか」が分からないまま、ベンダーの提案を比較する段階に進んでしまいがちです。

この記事は、中堅・大手企業で情報システムや経営企画を担当する方に向けて、費用相場・刷新方式の選び方・移行戦略・発注先の見極め方を、特定の製品に誘導しない立場から整理したものです。あわせて、近年リプレイスの前提を変えつつあるAIの活用（レガシーコードの解析・仕様書の復元）についても、現時点で言えることを慎重にまとめます。

基幹システムのリプレイスとは：検討が始まる典型的なきっかけ

基幹システムとは、販売・購買・在庫・生産・会計・人事といった、事業の中核業務を支えるシステムの総称です。リプレイスは、老朽化した基幹システムを新しい基盤・仕組みに置き換えることを指します。サーバーの更改やバージョンアップと違い、多くの場合は業務プロセスやデータ構造の見直しを伴うため、「システムの入れ替え」であると同時に「業務の再設計」の性格を持ちます。情報システム部門だけの案件ではなく、業務部門と経営の関与が前提になるのはこのためです。

検討が始まるきっかけは、おおむね次の4つに集約されます。

• 老朽化：基幹システムの更改サイクルは10年前後と言われます。ハードウェアやミドルウェアが限界を迎え、性能劣化や改修コストの増大が目に見えてくる時期です
• 属人化：開発当時の担当者が退職し、ドキュメントも残っておらず、「何がどう動いているのか誰も説明できない」状態になる。改修のたびに調査から始めることになり、変更のスピードとコストが悪化します
• サポート終了：OS・データベース・パッケージ製品のサポート終了（EOL）が期限を区切ります。経済産業省がDXレポートで指摘した「2025年の崖」も、レガシーシステムの維持限界を示した言葉として、この文脈で使われてきました。2025年という年自体はすでに過ぎましたが、21年以上稼働のレガシー基幹系が消えたわけではなく、老朽化と属人化のリスクは今も同じ構図で進行しています
• 法改正・制度対応：税制や法制度の変更のたびにシステム改修が必要になりますが、古いシステムほど対応の難易度とコストが上がり、制度対応が刷新の引き金になることがあります

注意したいのは、これらのきっかけの多くが「限界が来てから」表面化する点です。基幹システムの刷新は検討開始から稼働まで年単位の時間がかかるため、限界を迎える前に検討を始められるかどうかが、選択肢の広さをそのまま左右します。追い込まれてからの刷新は、方式の比較検討や移行リハーサルの時間を削ることになりがちです。

リプレイスの標準的な進め方

先に全体像を押さえておきます。リプレイスの標準的なステップは次の7段階です。以降の章は、このうち特に判断を誤りやすい箇所を掘り下げるものだと捉えてください。

1. 現状分析：現行システムの機能・データ・課題を棚卸しする。仕様が不明な部分がどれだけあるかも、ここで明らかにする
2. 要件定義：刷新の目的を定め、新システムに求める要件と「やらないこと」を確定する
3. ベンダー・方式選定：刷新方式（後述の3分類）を決め、複数社の提案を同じ条件で比較する
4. 設計・開発：要件を設計に落とし、構築・カスタマイズを進める
5. データ移行：現行データの調査・クレンジング・移行リハーサルを行う
6. 並行稼働：新旧システムを並行運用し、結果を突き合わせて検証する
7. 切替：判定基準を満たしたことを確認して本番を切り替え、旧システムを停止する

順序そのものは目新しくありませんが、失敗プロジェクトの多くは、この並びの前半（現状分析・要件定義）を軽くしたぶんの負債を、後半（データ移行・並行稼働）で払わされる構図になっています。

費用相場の実態：規模別レンジと、見積もりがブレる理由

「基幹システム リプレイス 費用」で調べると、サイトによって数字が大きく異なることに気づくはずです。これは調査の母集団や対象範囲が違うためで、幅があること自体が実態です。複数の公開調査を突き合わせると、企業規模別のレンジはおおむね次のようになります。

ただし、出典によってレンジの取り方はかなり異なります。上の表は「桁感をつかむための目安」であって、自社の見積もりを判定する基準にはなりません。

費用の内訳についても、公開調査ではおおむね次のような構成比が示されています。パッケージ導入を想定した場合、ライセンス費用が3〜4割、カスタマイズ開発が4〜5割、データ移行が1〜1.5割という目安です（比率は案件の性質により大きく変動します）。加えて、稼働後の年間保守費用は構築費の1〜2割程度とされることが多く、更改サイクルが10年前後だとすれば、運用期間中の保守費の累計は初期構築費に匹敵する規模になりえます。なお、基幹システムのリプレイスは、当メディアの他記事で扱う新規Webシステム開発（数百万円規模が中心）より対象範囲が広く、桁が一つ上がるのが通常です。初期費用の安い提案が総額でも安いとは限らないため、初期費用だけでなく運用期間全体の総額（TCO）で比較する視点が欠かせません。

では、なぜ見積もりはこれほどブレるのか。主な理由は4つあります。

1. 最大の費目が変動費だから：内訳で最も大きいカスタマイズ開発は、自社業務とパッケージ標準機能の差分で決まります。この差分は要件定義が進むまで確定しません
2. 現行仕様が分からないまま見積もるから：ドキュメントのないシステムの刷新は、見積もりの前提そのものが「推定」になります。仕様のブラックボックス化は、費用ブレの最大の構造要因です
3. データ移行の難易度が事前に見えにくいから：長年運用したシステムのデータには、重複・欠損・独自コード体系が蓄積しています。その汚れ具合は、実データを調査するまで分かりません
4. 方式によって費用構造が根本的に違うから：後述するERP導入・マイグレーション・リビルドでは、費用の内訳も山の位置もまったく異なります。方式が決まる前の見積もりは比較対象になりません

実務上の対策はふたつあります。ひとつは、相見積もりを取る際に前提条件を自社側で揃えること。現行システムの資料・対象業務の範囲・移行対象データの概要を同じ内容で各社に渡さなければ、返ってくる金額は前提の違いを映しているだけで、比較になりません。もうひとつは、概算見積もりを確定額として扱わないこと。現状分析が終わる前の数字は、どの会社が出しても前提の置き方次第で動きます。むしろ「この段階では確定できない」と幅の根拠を説明する会社のほうが、見積もりの精度に誠実だと言えます。

見積書そのものの読み方や費目の妥当性の確認方法は、システム開発の費用相場と見積もりガイドで詳しく解説しています。

刷新方式の3分類：ERP・マイグレーション・リビルド

基幹システムの刷新方式は、大きく3つに分類できます。それぞれ費用・期間・得られるものが異なり、どれが正解かは業務の特性で決まります。

補足すると、マイグレーションは「業務を変えない」という点で消極的な選択に見えますが、実際には時間を買う判断として機能します。EOLの期限が迫っているとき、まず基盤を刷新して延命し、業務の再設計は落ち着いてから取り組む、という二段構えです。また、この3方式は排他ではありません。会計はパッケージ、競争力に関わる業務はリビルド、当面触れない領域はマイグレーション、と業務領域ごとに方式を組み合わせる構成も、中堅企業では現実的な解になります。

Fit to Standardの功罪：合う業務と合わない業務

近年のERP導入では「Fit to Standard」、つまりパッケージをカスタマイズするのではなく、業務側を標準機能に合わせる考え方が主流になっています。カスタマイズ費用とバージョンアップ時の負債を抑えられる、業務プロセスを世の中の標準形に見直す機会になる、という点で合理的な考え方です。

一方で、すべての業務が標準に合うわけではありません。整理すると次のようになります。

• Fit to Standardが合う業務：会計・人事給与・購買など、法制度や商慣行で手順が標準化されている業務。ここで独自性を維持しても競争力にはつながりにくく、標準に寄せる利点が大きい領域です
• 合わない業務：特殊な受注形態、独自の生産管理・価格決定ロジックなど、その会社の競争力の源泉になっている業務。ここを無理に標準へ合わせると、システムは新しくなったのに現場の強みが失われる、という本末転倒が起こりえます

つまりFit to Standardは、適用する業務を選べば強力に働き、一律に適用すると副作用が出る考え方です。「標準に合わせられるか」ではなく「標準に合わせてよい業務か」を問うのが正しい使い方だと言えます。

中堅企業でしばしば起こるのは、「業務の8割はパッケージで足りるが、残り2割が致命的に合わない」という状況です。この2割をどう扱うか──アドオン開発で対応するか、周辺システムとして個別開発に切り出すか、業務側を変えるか──が方式選定の実質的な分かれ目になります。「どの製品を選ぶか」の前に「どの業務を標準化し、どの業務の独自性を守るか」を自社で決めておくことが、方式選定の出発点です。この整理を製品選定より先に行うかどうかで、後工程のブレ幅が大きく変わります。

ビッグバン移行か、段階移行か：判断基準の比較表

方式と並んで重要なのが移行戦略です。全業務を一斉に新システムへ切り替えるビッグバン移行と、業務領域や拠点ごとに順次切り替える段階移行のどちらを選ぶかで、プロジェクトの組み立ては大きく変わります。どちらが優れているという話ではなく、次の4つの軸で自社の状況を評価して決める問題です。

それぞれのリスクの現れ方も対照的です。ビッグバン移行は、問題が切替日に集中します。切替の可否を判定する基準（どのテストが通っていれば進むのか）と、問題発生時に旧システムへ戻す切り戻し計画──どの時点までなら戻れるのか、戻した場合に切替後のデータをどう扱うのか──をあらかじめ文書化しておくことが必須です。段階移行は、新旧システムが併存する期間の二重運用コストとデータ突合の負担が積み上がります。併存期間を漫然と延ばさないよう、各段階の完了条件を先に決めておく必要があります。

実務では、コア業務はビッグバンで切り替えつつ周辺業務を段階的に寄せていく、といった折衷案も珍しくありません。たとえば会計と販売管理を連休中に一斉切替し、拠点ごとの在庫管理は稼働が安定してから順次移す、という組み立てです。大切なのは、提案書に「なぜこの移行戦略なのか」が上の4軸で説明されているかどうかです。移行戦略の記述が薄い提案は、切替直前になってから計画を作り始めることになり、そのときにはもう選択肢が残っていません。

AI駆動開発でレガシー刷新はどう変わったか

基幹システム刷新の最大のリスクは、費用でも技術でもなく、現行仕様のブラックボックス化です。ドキュメントがなく、有識者も退職している。この状態では要件定義の土台となる「現行がどう動いているか」が分からず、見積もりは推定になり、移行の検証も「何と比べて正しいのか」の基準を欠きます。前述の「見積もりがブレる理由」の根っこも、失敗の多くの根っこも、実はここにあります。

従来、この問題への対処は、人手でソースコードを読み解く「現行調査」しかありませんでした。膨大な工数がかかるため調査範囲を絞らざるをえず、絞った範囲の外から問題が出る、という構造的な弱点を抱えていました。「触ると壊れるかもしれないから触らない」という判断が積み重なり、システムの寿命だけが延びていく──多くの現場で起きてきたのは、この膠着です。

この前提が、生成AI（大規模言語モデル）の進化で変わりつつあります。誇張を避けて言えば、「AIで刷新が安く早くなる」と断定できる段階ではありませんが、移行の最大リスクであるブラックボックス化に対して、AIによる解析が現実的な打ち手になってきた、というのが現時点での正確な評価です。具体的に効果が出やすいのは次の工程です。

• レガシーコードの解析：大量のソースコードを読み、処理の流れ・データの依存関係・使われていない機能を整理する作業は、AIが比較的得意とする領域です。人手では範囲を絞るしかなかった調査を、広くかけられるようになりました
• 仕様書の復元：ドキュメントのないシステムから、コードを根拠に仕様書のドラフトを起こす使い方です。AIの出力をそのまま正とするのではなく、業務を知る担当者が検証する前提ですが、「ゼロから書き起こす」のと「ドラフトを検証・修正する」のでは負担が大きく違います
• 移行テストコードの生成：現行システムの挙動を固定するテストを整備し、新システムが同じ入力に同じ結果を返すかを機械的に検証する。移行の正しさを「人の記憶」ではなくテストで担保する土台になります
• 段階移行時の新旧突合：並行稼働期間中、新旧システムのデータを突き合わせて差異を洗い出す作業の補助。段階移行の弱点である二重運用の負担を軽くする方向に働きます

共通する注意点として、AIの出力には必ず人の検証が必要です。特に仕様の復元は、コードに書かれていない「なぜそうなっているか」（業務上の経緯や例外運用）をAIは知りません。AIが調査の裾野を広げ、人が業務知識で検証するという分業が成立している体制かどうかが、発注側の確認ポイントになります。

AI活用をうたう会社に依頼する場合は、商談で次の点を確認してください。第一に、こちらが渡すソースコードや業務データがAIの学習に使われない設定・契約になっているか。主要なAI開発ツールには法人向けにデータを学習利用しない利用形態が用意されており、対応できる会社なら具体的に説明できます。第二に、AIが生成した仕様書やテストコードを誰がどの手順で検証してから納品するのか。この2点に即答できない場合、AI活用は看板だけの可能性があります。

発注側の視点でのAI駆動開発の全体像はAI駆動開発とは：発注側が知っておくべき変化に、代表的なツールであるClaude Codeの企業開発での使いどころはClaude Codeで企業のアプリ開発はどこまでできるかにまとめています。

失敗パターン5つと回避策

基幹システムの刷新でつまずくポイントは、実はかなり定型化しています。裏を返せば、典型パターンをあらかじめ知っておくだけで、かなりの部分は計画段階で予防できるということです。代表的な5つと回避策を挙げます。

1. 現場要望の「全部載せ」

要件定義で各部署の要望を集めると、必ず現行機能の踏襲に加えて改善要望が積み上がります。すべてを盛り込むとカスタマイズが膨張し、予算と期間が破綻します。回避策は、刷新の目的に照らした優先順位付けと、「今回はやらないことリスト」の明文化です。要望を切る判断は現場同士ではできないため、経営層を含む意思決定の場を設計に組み込みます。

2. ベンダーへの丸投げ

要件定義から任せきりにすると、自社の業務を知らないまま設計が進み、出来上がってから「業務に合わない」が噴出します。外部に任せてよいのは技術と進行管理であって、「自社の業務がどうあるべきか」の判断は外注できません。業務を語れる社内担当者を専任に近い形でアサインできるかが、プロジェクトの成否を左右します。兼務で片手間の対応しかできない体制なら、スケジュールを遅らせてでも人の手当てを先に行うほうが、結果的に早く着きます。

3. データ移行の軽視

データ移行は「最後にデータを流し込むだけ」と見なされがちですが、長年のデータには重複・欠損・独自運用が蓄積しており、終盤に発覚すると切替日を直撃します。回避策は、プロジェクト序盤に実データの品質調査を行い、移行リハーサルを本番前に複数回計画しておくことです。あわせて、「すべてのデータを移す」を前提にしないこと。過去データのどこまでを新システムに載せ、どこからを参照用のアーカイブに残すかを決めるだけで、移行の難易度は大きく変わります。データクレンジングの責任分担（自社かベンダーか）も契約時に決めておきます。

4. 並行稼働期間の不足

スケジュール遅延のしわ寄せは、たいてい終盤の並行稼働・検証期間に来ます。検証不足のまま切り替えると、問題が本番業務の中で発覚します。回避策は、月次決算などの締め処理を最低1サイクルは新旧並行で回し、結果を突合してから切替を判定すること。並行稼働は「削ってよいバッファ」ではなく品質保証の工程だと、計画段階で位置づけておくことが重要です。

5. 刷新目的の不在

「古くなったから替える」だけで走り出すと、判断基準がないため「現行どおりに」が合言葉になり、古い業務プロセスを新しい技術で複製するだけの結果になります。回避策は、着手前に「この刷新で何を変え、何を守るのか」を1枚に文書化し、以後のすべての判断の物差しにすることです。前述の要望の取捨選択も、方式選定も、この物差しがあって初めて機能します。

発注先選定のチェックポイント

ERPベンダーと受託開発会社の使い分け

発注先は大きく、ERPパッケージのベンダー・導入パートナーと、個別開発を行う受託開発会社に分かれます。どちらが上ということはなく、業務の特性で使い分けるものです。

• 標準業務が中心で、Fit to Standardで進められそうな場合：ERPベンダー・導入パートナーが第一候補です。製品知識と導入方法論の蓄積は個別開発では代替できません
• 独自業務が競争力で、スクラッチやカスタム開発の比重が高い場合：受託開発会社が候補になります。パッケージの制約から自由に、業務に合わせた設計ができます
• 併用する場合：会計など標準業務はパッケージ、競争力に関わる業務は個別開発で周辺システムとして構築し、連携させる構成も現実的な選択肢です。この場合は全体のデータ設計に責任を持つ主体を決めておくことが重要です

提案書で見るべき点

候補が出そろったら、提案書を次の観点で読み比べてください。金額の大小より、工程の解像度に差が出ます。

1. 現状分析の工程が明示されているか：標準的な進め方は「現状分析 → 要件定義 → ベンダー・方式選定 → 設計・開発 → データ移行 → 並行稼働 → 切替」です。いきなり要件定義から始まる提案は、現行仕様の把握という土台を飛ばしています
2. データ移行が独立した工程・体制で見積もられているか：「移行支援一式」の一行で済まされていないか。データ調査とリハーサルの計画があるか
3. 移行戦略の選択理由が書かれているか：ビッグバンか段階かが、前述の4軸に相当する根拠とともに説明されているか
4. 契約形態のフェーズ分割を提案できるか：仕様が固まっていない調査・検証フェーズは準委任で柔軟に進め、要件が確定した本開発は請負で成果に責任を持つ、という使い分けを提案できる会社は、不確実性の扱いに慣れています
5. 運営会社の事業継続性：基幹システムは10年単位の付き合いになります。保守を担う会社が10年後も存在しそうか。上場の有無や財務情報の開示は、その判断材料のひとつになります

比較の進め方としては、上の5点を評価項目にした簡単な評価表を作り、提案説明の場で各社に同じ質問をぶつけるのが実用的です。とくに「現行仕様が不明な部分をどう調査するか」という質問への答えには、その会社の進め方の思想がよく表れます。人手の調査だけを前提にする会社、AI解析を組み込んだ調査を提案する会社、調査自体を軽く見て要件定義に急ぐ会社──回答の質は金額表よりも雄弁です。

よくある質問

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

規模と方式によりますが、中堅企業の基幹システム刷新は、検討開始から稼働まで年単位で見るのが現実的です。特に現状分析と要件定義は、社内の合意形成を含むため想定より時間がかかります。また、切替時期は決算期や繁忙期を避ける制約があるため、単純な作業量以上にカレンダーの制約を受けます。切替希望時期（EOLや繁忙期など）から逆算し、余裕を持って着手してください。

Q. 現行システムのベンダーにそのまま任せるべきでしょうか？

一長一短です。現行ベンダーは仕様と経緯を知っているため調査コストが小さい一方、現行踏襲に寄りやすく、比較対象がないと提案と価格の妥当性を検証できません。現行ベンダーを候補に含めたうえで、複数社から提案を取り、同じ条件で比較するのが無難です。なお、AIによるコード解析が使えるようになったことで、「仕様を知っているのは現行ベンダーだけ」という構図は以前より緩和されつつあります。

Q. 一部の業務だけ先に刷新することはできますか？

可能です。段階移行の考え方そのもので、切り出しやすい周辺業務から新システムに移し、コアは当面維持する進め方は珍しくありません。予算を分散できるほか、小さい範囲で新しい開発体制やベンダーとの相性を確かめられる利点もあります。ただし成否は新旧システム間のデータ連携設計にかかっています。連携部分を暫定のつもりで雑に作ると、その暫定が何年も残ることになるため、切り出す順番と連携方式は全体計画の中で決めてください。

Q. 補助金は使えますか？

中小企業向けには、省力化投資補助金などシステム投資に使える可能性のある制度があります。ただし対象要件・補助率・公募時期は年度ごとに変わるため、中小企業庁など公式の最新情報を確認したうえで、申請スケジュールをプロジェクト計画に織り込んでください。補助金の採択時期に合わせて要件定義を急ぐと順序が逆になるため、制度はあくまで計画に載せられる範囲で使う、という順序を守るのが安全です。

まとめ：ブラックボックスを解くことが刷新の出発点

本記事の要点を整理します。

• 費用相場は出典により幅が大きい。中堅企業では2,000万〜1億円が目安だが、実額はカスタマイズ量と現行仕様の把握度で決まる
• 方式は「どの業務を標準化し、どの業務の独自性を守るか」を自社で決めてから選ぶ。ERP・マイグレーション・リビルドに絶対の優劣はない
• 移行戦略は、業務停止許容度・データ整合性・予算平準化・現行の寿命の4軸で判断する
• 最大のリスクは現行仕様のブラックボックス化。AIによるコード解析・仕様復元は、この構造問題への現実的な打ち手になりつつある
• 発注先は、金額よりも現状分析・データ移行・移行戦略の解像度と、10年付き合える事業継続性で選ぶ

本メディアを運営するSwooo（東証グロース上場・株式会社アイビス、証券コード9343）は、Claude Codeなどを活用したAI駆動開発とノーコード開発を組み合わせ、累計50件以上の開発支援を行ってきました。基幹システムの刷新を検討される場合は、ドキュメントのない既存システムの解析・仕様復元を含む調査・検証フェーズは準委任で、要件が固まった本開発は請負で、というフェーズ分割のご提案が可能です。「仕様が分からず、刷新の見積もりの取りようがない」という段階からでもご相談いただけます。

→ 基幹システムの刷新について相談する（無料）