基幹システムのリプレイス（入れ替え）｜進め方・費用・失敗対策

【1分でわかるこの記事の要約】

• 基幹システム刷新は経営の最重要課題：IT予算増額企業の4割以上が理由に挙げる「基幹システムリプレイス」は、老朽化によるコスト膨張やセキュリティリスクを解消し、事業の柔軟性を高めるための避けて通れない経営判断です。

• 「現状把握（ASIS解析）」が成否を分ける：最大の失敗要因は、仕様書がない・属人化している現行システムの仕様が不明なまま要件定義に入ることです。AI等を活用したASIS解析で現状を正確に可視化することが、手戻りやコスト増を防ぐ鍵となります。

• 段階的移行とリスク管理の徹底：巨額損失を招く一括移行（ビッグバン方式）は避け、周辺系からコア系へ段階的に移行すべきです。最低2回のデータ移行リハーサルと、万が一のための「切戻し計画」策定がプロジェクト成功には不可欠です。

基幹システムの保守コストが年々膨らみ、障害対応に追われている——10年以上稼働した基幹システムを抱える企業にとって、リプレイス（入れ替え）は避けて通れない経営判断だ。基幹システムのリプレイスは「現状把握→要件定義→設計・製品選定→データ移行→並行稼働→本番切替」の6ステップで進める。成功の鍵は、最初の「現状把握」にある。仕様書がない・古い・属人化しているシステムをリプレイスする場合、ASIS解析で正確に現状を可視化しなければ、要件定義の段階で手戻りが発生する。ITR「IT投資動向調査2026」によると、2025年度にIT予算を増額する企業は過去最高の47%に達し、うち44.5%が「基幹システムの刷新」を理由に挙げた。本記事では、基幹システムリプレイスの進め方、費用相場、4つの移行方式、失敗事例と5つの対策を解説する。

基幹システムのリプレイスとは？定義とタイミング

基幹システムのリプレイス（入れ替え）とは、老朽化した現行システムを廃止し、新しいシステム（パッケージ、SaaS、スクラッチ開発）に全面的に置き換えることを指す。「リプレイス」はITの専門用語で、日本語では「入れ替え」と同義だ。既存のコードを活かす「リビルド（再構築）」や、環境だけ変える「リホスト」とは根本的に異なる。

なお、「マイグレーション（移行）」はデータや環境を別の場所へ移す作業全般を指す上位概念であり、リプレイスはシステムそのものを置き換える行為を指す。リプレイスにはデータのマイグレーションが伴うが、両者はイコールではない。

リプレイスと他の手法の違い

リプレイスを検討すべき5つのタイミング

1. 保守コストがIT予算の70%を超えた: 新規投資に回せる余力がなくなり、事業成長が停滞する。

2. EOL/EOSL（サポート終了）が迫っている: ハードウェアやミドルウェアのサポート終了により、セキュリティリスクが急上昇する。

3. ベテラン技術者の退職が見込まれる: COBOL、RPG、PL/I等のレガシー言語を扱える技術者が退職すると、障害対応すらできなくなる。

4. 業務プロセスの大幅な見直しが必要: 現行システムに業務が縛られ、新しいビジネスモデルに対応できない。

5. 障害発生頻度が許容水準を超えた: 月に複数回の障害が発生し、業務に支障をきたしている。

基幹システムの全体像を知りたい方はこちら

リプレイスの判断基準｜本当にリプレイスが最適か

リプレイスは最もコストと期間がかかる手法だ。すべてのケースでリプレイスが最適とは限らない。判断を誤ると、億単位の投資が無駄になる。

手法選択の判断マトリクス

判断の軸は「業務プロセス変革の必要性」と「既存コードの再利用可能性」の2つだ。

• 業務プロセスを大幅に変えたい + 既存コードが再利用できない → リプレイスが最適

• 業務は現行踏襲 + コードが再利用できる → リホストで十分

• 業務は変えたいが既存ロジックは活かしたい → リビルドが適切

ASIS解析で判断精度を上げる

この判断マトリクスを使うには、「既存コードの再利用可能性」を正確に評価する必要がある。仕様書がないシステムでは、ASIS解析で現行システムの業務ロジック、外部連携、データ構造を可視化することが前提になる。

エイジレスの実績では、富士通メインフレーム上のCOBOLアプリケーション（仕様書不完全）をASIS解析した結果、コアロジックの80%が再利用可能と判明し、当初予定していたリプレイスからリライトに方針転換したケースがある。ASIS解析なしにリプレイスを決断していれば、数千万円の過剰投資になっていた。

基幹システムリプレイスのメリット4つとデメリット3つ

メリット

メリット1: 業務効率の大幅な改善

手作業のバッチ処理、紙ベースの承認フロー、二重入力——こうした非効率が、新システムへの置換で解消される。在庫管理や注文処理の自動化により、処理時間が1/3以下に短縮した製造業の事例もある。

メリット2: 保守コストの削減

レガシーシステムの保守には、言語対応可能なベテラン技術者の確保、旧型ハードウェアの延命対応、独自ミドルウェアのライセンス費用がかかる。新システムに置き換えることで、年間の保守コストを30〜50%削減できるケースが多い。

メリット3: セキュリティの強化

サポートが終了したOSやミドルウェア上で動くレガシーシステムは、セキュリティパッチが適用されない。新システムへの置換は、セキュリティリスクを根本的に解消する。

メリット4: 事業の柔軟性向上

API連携、マイクロサービス、クラウドネイティブ——新しいアーキテクチャを採用することで、新規事業や市場変化への対応スピードが格段に上がる。

デメリット

デメリット1: 初期コストの大きさ

パッケージ型で数千万円、スクラッチ型で億単位のコストがかかる。投資回収に3〜5年を要するのが一般的だ。

デメリット2: データ移行のリスク

旧システムから新システムへのデータ移行は最大のリスクポイントだ。データ形式の違い、マスタの不整合、外部連携先との仕様の差異——これらが移行後のシステム障害の原因になる。

デメリット3: 組織への影響

新システムの操作方法習得、業務プロセスの変更、一時的な生産性低下——リプレイスは技術だけでなく、組織にも大きな負荷をかける。教育・定着に6ヶ月〜1年を見込む必要がある。

基幹システムリプレイスの進め方6ステップ

リプレイスは以下の6ステップで進める。全体の期間は規模によって異なるが、中規模（数百〜数千ユーザー）で12〜24ヶ月が目安だ。

Step 1: ASIS解析による現状把握（1〜2ヶ月）

現行システムのソースコード、データ構造、業務ロジック、外部連携先を棚卸しする。仕様書がない・古い場合は、AIを活用したコード解析が有効だ。エイジレスでは独自AI「ARIADNE」と精鋭部隊「TITANS」（平均年齢57歳、300名）の組み合わせで、数万本規模のプログラムでも約1ヶ月でASIS解析を完了する。COBOL、RPG、PL/I、アセンブラに対応している。

この工程の成果物（業務ロジック一覧、外部連携マップ、データ辞書）が、以降のすべてのステップの土台になる。

「仕様がわからない」を解決する、新しいアプローチ。

独自AI「ARIADNE」× 精鋭部隊「TITANS」が、

レガシーシステムの仕様を可視化します。

無料相談はこちら

Step 2: 要件定義（2〜3ヶ月）

ASIS解析の結果をもとに、新システムに必要な機能を定義する。現行踏襲する機能と、新たに追加・変更する機能を明確に分ける。「すべてを現行踏襲」は危険だ。不要な機能まで移行すると、コストが膨らむ。ASIS解析で可視化した業務ロジックを精査し、廃止できる機能を特定する。

Step 3: 設計・製品選定（2〜4ヶ月）

パッケージ（ERP）、SaaS、スクラッチ開発のいずれかを選択する。

製品選定ではRFP（提案依頼書）を作成し、複数ベンダーから提案を受ける。ASIS解析の成果物をRFPに添付すれば、ベンダーの提案精度が格段に上がる。

Step 4: データ移行（2〜3ヶ月）

旧システムから新システムへのデータ移行は、リプレイスの成否を左右する工程だ。

データ移行で押さえるべき3点:

• マスタデータの整合性: コード体系や名称の統一

• トランザクションデータの範囲: 過去何年分を移行するか

• 外部連携先への影響: EDI、API連携の仕様確認

移行リハーサルを最低2回は実施し、移行にかかる時間とデータの整合性を検証する。

Step 5: 並行稼働・テスト（2〜3ヶ月）

旧システムと新システムを同時に稼働させ、出力結果を突合する。業務部門のユーザーにも参加してもらい、実際の業務フローでの動作を検証する。切戻し計画（新システムに問題があった場合に旧システムに戻す手順）も必ず用意する。

Step 6: 本番切替・教育（1〜2ヶ月）

新システムへの切替は、業務影響を最小化するタイミング（月末処理の後、長期休暇中など）を選ぶ。切替後は集中的なユーザー教育を実施し、問い合わせ窓口を設置する。

基幹システムの移行について詳しく知る

4つの移行方式と選び方

リプレイスの移行方式は、プロジェクトのリスク管理に直結する。JUAS「企業IT動向調査2018」によると、500人月以上のプロジェクトでは48.0%が納期未達に終わっている。大規模ほどリスク分散が不可欠だ。

基幹システムの場合、一括移行（ビッグバン方式）は避けることを強く推奨する。周辺系→コア系の順に段階的に移行し、各フェーズで成果を確認してから次に進むのが定石だ。

基幹システムリプレイスの費用相場と内訳

リプレイスの費用は方式と規模によって大きく異なる。以下は中規模企業（従業員300〜1,000名）の目安だ。

方式別費用相場

費用の内訳

注意すべきは、ASIS解析を省略してもコストは下がらないという点だ。むしろ、ASIS解析の省略が要件定義の手戻りを招き、総コストが1.5〜2倍に膨れるケースが多い。ASIS解析にかかるコストは全体の3〜5%程度で、投資対効果は極めて高い。

モダナイゼーションの費用について詳しく知る

失敗しないための5つのポイント

基幹システムのリプレイスで失敗を防ぐために、5つのポイントを押さえる。

ポイント1: ASIS解析を省略しない

最も多い失敗は、「現行システムの仕様がわからないまま要件定義に入る」ことだ。仕様書がない・古い・属人化しているシステムほど、ASIS解析の価値は大きい。AIを活用すれば、従来の1/10のコスト・1/10の期間で解析が完了する。

ポイント2: 段階的に移行する

一括切替（ビッグバン方式）はリスクが高い。周辺系→コア系の順に段階的に移行し、各フェーズの成果を確認してから次に進む。

段階的移行の例:

• Phase 1: 経理・人事など独立性の高い業務

• Phase 2: 購買・在庫管理など外部連携がある業務

• Phase 3: 販売・生産管理などコア業務

ポイント3: データ移行計画を甘く見ない

データ移行の失敗は、リプレイス失敗の最大要因だ。マスタデータの不整合、文字コードの変換ミス、外部連携先との仕様差異——これらは事前のリハーサルでしか発見できない。最低2回の移行リハーサルを必ず実施する。

ポイント4: 切戻し計画を用意する

新システムに重大な不具合が見つかった場合に、旧システムに戻す手順を事前に策定する。切戻し判断の基準（どの程度の障害で切り戻すか）と、切戻しにかかる時間の見積もりも明確にしておく。

ポイント5: 教育と定着支援に投資する

新システムの機能がいくら優れていても、ユーザーが使いこなせなければ意味がない。切替の1ヶ月前から操作研修を実施し、切替後も3ヶ月間はヘルプデスクを設置する。「マニュアルを配布して終わり」では定着しない。

レガシーシステムの刷新について詳しく知る

リプレイスの失敗事例と成功事例

失敗事例：江崎グリコのERPリプレイス（2024年）

江崎グリコは2024年4月、SAP S/4HANAへのERPリプレイスで大規模なシステム障害を起こした。ほぼすべての冷凍食品が出荷停止に追い込まれ、全面復旧に約7ヶ月を要した。純利益は36.8%減少。原因は、移行リハーサルの不足、切り戻し計画の不備、データ移行の検証不足と指摘されている。

この事例は、前章の「5つのポイント」すべてに関わる教訓を含んでいる。ASIS解析の省略、ビッグバン方式のリスク、データ移行の軽視——いずれかを回避していれば、被害の規模は大幅に抑えられた可能性が高い。

成功事例：マツモトプレシジョンのSAP ERP導入（2021年）

プレス加工業のマツモトプレシジョンは、手動の生産管理・在庫管理をSAP ERPにリプレイス。導入後、売上総利益が30%改善し、営業利益率は3ポイント上昇、全従業員の基本給与が4%アップした。成功の鍵は、経営層がプロジェクトに深く関与し、ERPの導入と業務プロセスの見直しを並行して実施した点にある。

「入れ替え」はコストだけでなく、業務プロセス改革の機会でもある。新システムの導入をゴールにするのではなく、業務改善とセットで計画することが成果につながる。

よくある質問（FAQ）

Q. 基幹システムのリプレイスにかかる期間は？

規模と方式による。SaaS導入で3〜6ヶ月、パッケージ（ERP）で12〜18ヶ月、スクラッチ開発で18〜36ヶ月が目安だ。ASIS解析やデータ移行の期間も含めた全体スケジュールを立てることが重要だ。

Q. パッケージ（ERP）とスクラッチ開発、どちらを選ぶべき？

標準的な業務フローに近い企業はパッケージが適している。独自の業務要件が多い企業はスクラッチが必要になる。まずASIS解析で現行業務を可視化し、パッケージの標準機能でカバーできる範囲を評価してから判断するのが正しい順序だ。

Q. データ移行で最もリスクが高いポイントは？

外部連携先との仕様差異だ。EDI接続やAPI連携を行っているシステムでは、新旧システム間のデータ形式の違いが移行後の障害原因になりやすい。外部連携先との事前調整と、移行リハーサルでの検証が不可欠だ。

Q. リプレイスとリビルド（再構築）、どちらが適切か？

業務プロセスを大幅に変えたい場合はリプレイス、現行の業務ロジックを活かしたい場合はリビルドが適している。ASIS解析で「既存コードの再利用可能性」を評価し、判断マトリクスに当てはめて決定する。

Q. リプレイス後の保守体制はどう構築する？

ベンダーとの保守契約に加え、社内にシステム管理者を配置する。リプレイスの過程で作成したドキュメント（業務ロジック一覧、データ辞書、運用マニュアル）を整備し、属人化を防ぐ。特にASIS解析で作成した成果物は、長期的な保守の基盤になる。

Q. リプレイスとマイグレーションの違いは？

マイグレーションはデータや環境を別の場所へ移す作業全般を指す上位概念。リプレイスはシステムそのものを新しい製品やサービスに置き換える行為だ。リプレイスにはデータのマイグレーション（移行）が伴うが、マイグレーション＝リプレイスではない。

Q. 社内にITに詳しい人材がいなくてもリプレイスは可能か？

可能だ。リプレイスを支援するベンダーやコンサルタントに依頼するのが一般的だ。ただし「丸投げ」は禁物。自社の業務を知る社員がプロジェクトに参加し、必要な機能を伝えることが成功の条件になる。

まとめ

基幹システムのリプレイスは、企業のIT投資で最も規模が大きいプロジェクトの一つだ。成功のために押さえるべきポイントを改めて整理する。

1. ASIS解析から始める: 仕様がわからないまま進めると、要件定義で手戻りが発生し、コストと期間が膨らむ。

2. リプレイスが最適かを判断する: 業務変革の必要性とコード再利用可能性の2軸で、リプレイス/リビルド/リホストの最適解を選ぶ。

3. 6ステップを省略しない: ASIS解析→要件定義→設計・選定→データ移行→並行稼働→本番切替。特にデータ移行と並行稼働は十分な時間を確保する。

4. 失敗パターンを事前に潰す: ASIS解析の省略、ビッグバン方式、データ移行の軽視、切戻し計画の欠如、教育不足——この5つを避ければ、リプレイスの成功確率は大幅に上がる。

リプレイスの第一歩は、現行システムの正確な把握にある。「仕様書がない」「ベテランが辞めたら誰もわからない」——こうした状態なら、まずASIS解析で現状を可視化してほしい。

「仕様がわからない」を解決する、新しいアプローチ。

独自AI「ARIADNE」× 精鋭部隊「TITANS」（平均年齢57歳）が、

レガシーシステムの仕様を可視化します。

無料相談はこちら

基幹システムの刷新について詳しく知る