基幹システムのリプレイス｜再構築・刷新の5つの方式とタイミングの見極め方

基幹システムのリプレイスは、「業務のやり方を変えるか」「基盤を変えるか」「プログラムを作り直すか」の3つの問いで方式がほぼ決まります。業務を変えないなら基盤だけ移すリホストやリライト、業務を変えるなら再構築・パッケージ置換・SaaS移行が候補です。この記事では、リプレイスの5つの方式の違い、方式を選ぶための採点表の記入例、一括か段階かの決め方、残り期間から選べる方式の早見表を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

基幹システムのリプレイスとは：最初に「方式」を決める理由

基幹システムのリプレイスとは、販売・購買・在庫・生産・会計などを支える現行システムを、新しいシステムに置き換えることです。「再構築」「刷新」「更改」もほぼ同じ意味で使われますが、実際の中身は、サーバーを入れ替えるだけのものから、業務の進め方ごと作り直すものまで幅があります。

オフコンや自社サーバー上で長年改修を重ね、仕様書が現状と合わなくなった基幹システムほど、どの方式を選ぶかで、費用だけでなく社内の誰がどれだけ関わるかが大きく変わります。

同じ「リプレイス」でも、方式によって費用・期間・社内の負担・リスクの性質がまったく違います。方式を決めないまま複数のベンダーに見積もりを頼むと、ある会社は既存プログラムの移植で、別の会社はERPパッケージの導入で見積もり、比べようがない提案がそろいます。方式は、ベンダーに声をかける前に発注側で仮決めしておくのが基本です。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」（2018年）も、再構築手法の選択を「システム再構築企画のスタートライン」と位置づけています。手法によって、検討すべきリスクも計画の立て方も変わるためです。

なお、この記事は「どの方式で置き換えるか」の比較と判断に絞ります。そもそも基幹システムとは何か、見直しのサインは何かは基幹システムとはで、構想から稼働までの全体の段取りは基幹システム導入の進め方で解説しています。オフコンからの移行に特化した比較はオフコン移行先の比較をご覧ください。

リプレイスの5つの方式：何を変えて、何を残すか

IPAのガイドは、現行システムを踏襲する再構築の手法を「ハードウェア更改・リホスト・リライト・リビルド」の4つに分け、これとは別に「パッケージ製品の利用」を扱っています。分け方の軸は、業務仕様・基盤・開発言語のどれを変えるかです。ガイドの用語集によると、リホストは業務仕様を変えずにOSやミドルウェア、ハードウェアを移し、同じ言語を使い続けるもの。リライトは業務仕様を変えずに基盤を移し、アプリケーションを別の言語で書き換えるものです。

中小企業の基幹システムでは、これにクラウドの業務アプリを使うSaaS移行を加えた、次の5つで考えると整理しやすくなります（ハードウェア更改はリホストの一部として扱います）。

この表で見てほしいのは、「業務のやり方」の列です。1と2は業務を変えないことが前提の方式で、3〜5は業務を変える方式です。業務を変えたいのにリホストを選ぶと、古い業務のやり方が新しい基盤の上でそのまま続きます。逆に、業務を変える覚悟がないままパッケージやSaaSを選ぶと、標準に合わない部分の追加開発が膨らみます。

クラウドへの移行を考える場合も、同じ整理が使えます。AWSの移行ガイド（AWS Prescriptive Guidance）は、移行戦略を「Retire（廃止）、Retain（維持）、Rehost、Relocate、Repurchase（別製品への置き換え）、Replatform、Refactor」の7つに分けています。中小企業の基幹システムでは、リホスト（Rehost）かSaaS・パッケージへの置き換え（Repurchase）のどちらかになることが多く、一部の機能は廃止する（Retire）という選択肢も同時に検討すると、移す対象が減ります。クラウド化そのものの論点は基幹システムのクラウド化で扱っています。

方式ごとの費用・期間・リスクの違い

方式ごとの費用や期間は、システムの規模や現行の状態で大きく変わるため、ここでは金額ではなくどこに費用とリスクが集まるかで比べます。

リホストやリライトは「業務を変えないから安くて早い」と思われがちですが、IPAのガイドはこれらの方式に特有のリスクを指摘しています。現行の仕様が文書で残っていないと、テストをどこまでやれば品質を保証できたと言えるのか判断できず、新旧の結果が食い違ったときの原因調査も難航する、という点です。ガイドには、リホスト前提で進めたものの、設計書がなく、現行の保守会社もシステム全体の業務知識を持っていなかったため、テスト期間とリリースが大幅に延びたトラブル事例が紹介されています。

パッケージ置換についても、同じガイドは、企画段階でパッケージと現行業務の突き合わせ（Fit&Gap分析）が不十分なまま進み、開始後に想定以上の機能拡張が必要と分かってコストとスケジュールが膨らむ例は少なくない、としています。パッケージへの置き換えを選ぶなら、フィットアンドギャップ分析を見積もりの前に行うことが前提です。

「置き換えない」選択肢も比べる：延命と廃止

5つの方式と並べて、現行のまま延命する、機能ごと廃止するという選択肢も検討の表に載せておきます。比べる相手がないと、どの方式の費用が妥当かを判断できないからです。

• 延命：延長保守の契約、部品の確保、仮想化による基盤の入れ替えなどで数年つなぐ。業務に大きな不満がなく、数年後に事業の大きな変化（統合・拠点再編）が見えている場合に合理的です。延命の費用は年々上がりやすく、保守できる人がいなくなる時期も読みにくい点に注意します。
• 廃止：使われていない帳票、月に数回しか使わない機能、Excelで代わりがきく処理を、移さずにやめる。移す対象が減るほど、どの方式でも費用とテストの量が減ります。

延命を選ぶ場合も、「いつまで延命し、その間に何を準備するか」を決めておかないと、数年後に同じ判断を、より短い残り期間で迫られます。

方式の選び方：要求事項を採点して候補を絞る

IPAのガイドは、再構築手法を選ぶ手順として、新システムへの要求事項を一つずつ「業務仕様の変更が必要か」「基盤の変更が必要か」「言語の変更が必要か」で評価し、優先度で重みをつけて集計する方法を示しています（重みの例は、必須3点・推奨2点・可能ならば1点）。集計結果の組み合わせから、次のように候補を選びます。

• 業務仕様・基盤・言語のどれも変えない → ハードウェア更改
• 基盤だけ変える → リホスト
• 基盤と言語を変える → リライト
• 業務仕様と基盤を変える → リビルド（言語はどちらでもよい）

この考え方を、パッケージ置換とSaaS移行も含めて使えるように広げた採点表の記入例が次の表です。

※説明用の例です（従業員150名・2工場の食品メーカー、現行はオフコン上のCOBOLで自社開発、を想定）。○は変更が必要、×は変更しないことが必要、―は関係しない。

この例では「業務を変える」「基盤を変える」が多いため、候補はリビルド系（再構築・パッケージ置換・SaaS移行）になります。ここから3つに絞るには、次の2つの質問を使います。

1. 業務を製品の標準に合わせられるか
   受注・出荷・請求・在庫の流れが業界の一般的な形に近く、例外は運用で吸収できるなら、パッケージ置換かSaaS移行が候補です。Fit to Standardの考え方で、合わせられる業務と合わせられない業務を分けます。
2. 合わせられない業務は、会社の強みか
   独自の原価計算や特殊な生産指示のように、競争力の源泉になっている業務だけが合わないなら、パッケージ置換＋その部分だけ追加開発、またはその部分だけ自社開発して連携する形を考えます。合わない部分が広く、しかもそれが強みなら再構築が候補に残ります。

「請求書の様式は今のまま」のように、業務を変えないことを求める要求が少数でも残る場合は、その扱いを記録しておきます。IPAのガイドも、候補の選定によって実現できなくなった要求事項を記録し、どう扱うかを決めておくことを勧めています。パッケージを選んだ後で「請求書の様式だけは変えられない」となれば、それが追加開発の候補になるからです。追加開発の判断基準はERPのアドオンとはで解説しています。

一括切替か段階切替か：リプレイスの範囲の分け方

方式と同じくらい結果を左右するのが、一度にどこまで置き換えるかです。全業務を同じ日に切り替える「一括切替」と、業務や拠点ごとに順番に切り替える「段階切替」があります。

プロジェクトの規模が大きいほど予定どおりに進みにくいことは、調査でも示されています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書 2026」（2025年度調査、東証上場企業とそれに準じる企業が対象）では、システム開発の工期が「予定より遅延」した割合は、10人月未満のプロジェクトで9.6％だったのに対し、500人月以上では47.8％でした。予算の「予定より超過」も、10人月未満の6.0％に対し500人月以上は42.2％です。規模の小さい単位に分けることは、遅延と超過のリスクを抑える有力な手段です。

ただし、段階切替には別の手間がかかります。切り替えた業務と、まだ旧システムで動いている業務の間に、一時的な連携（ブリッジ）を作る必要があるからです。判断の目安は次のとおりです。

• 一括切替が向く：業務の範囲が狭い、販売・在庫・会計が強く結びついていて分けにくい、旧システムの延命が難しい
• 段階切替が向く：拠点や事業ごとに業務が独立している、会計や人事など他と切り離しやすい業務がある、一度に現場の教育をしきれない

一括と段階のほかに、新旧のシステムを一定期間同時に動かす「並行稼働」という切り替え方もあります。同じ取引を両方に入力して結果を比べるため安心感はありますが、現場の入力は2倍になります。中小企業で全業務を並行稼働させるのは負担が大きく、月次の締め処理や請求書の発行など、間違えたときの影響が大きい処理に限って1〜2か月行う、という使い方が現実的です。切り替え当日の判定と切り戻しの考え方は稼働判定と本番切替で扱っています。

方式別に起きやすい落とし穴

どの方式にも、その方式ならではの失敗の型があります。方式を決めたら、次の点を計画に織り込んでおきます。

• リホスト・リライト：テストの終わりが決まらない
  IPAのガイドが指摘するとおり、現行の仕様書がないと、新旧の結果を比べる「現新比較テスト」で不一致が出たときに、どちらが正しいか判断できません。テストの範囲と完了条件を、着手前に決めておきます。使っていないプログラムは移行の前に洗い出して外します。
• リライト：変換できない処理が残る
  変換ツールは定型的な処理には強い一方で、帳票の細かな制御や特殊な画面処理は手作業になりがちです。変換率の見込みと、残りの手作業の見積もりを分けて出してもらいます。
• 再構築：要件が膨らみ続ける
  「せっかく作り直すなら」と要望が増え、範囲が決まりません。最初に「やらないこと」を決め、要望は優先度をつけて段階に振り分けます。費用と期間の考え方はスクラッチ開発とはも参考にしてください。
• パッケージ置換：追加開発が標準を上書きする
  現場の「今と同じに」に応え続けると、製品のバージョンアップのたびに追加開発の改修が必要になります。追加開発の上限（件数や費用）を、経営として先に決めておきます。
• SaaS移行：はみ出した業務がExcelに戻る
  標準に合わない業務を切り捨てると、その業務は表計算ソフトに戻り、データが再び分断されます。はみ出す業務を一覧にして、運用で吸収するのか、別のサービスと連携するのかを決めます。

方式は1つに決めなくてよい：業務ごとの組み合わせ

基幹システム全体に1つの方式を当てはめる必要はありません。中小企業の刷新で現実的なのは、業務ごとに方式を変える組み合わせです。たとえば、会計と人事給与はSaaSに移し、販売・在庫はERPパッケージに置き換え、強みになっている独自の見積・原価計算だけを自社開発で作り直して連携する、という形です。

組み合わせる場合は、業務と業務の間をつなぐデータ連携の設計が要になります。どのシステムを取引先・品目のマスタの「正」とするか、連携のタイミングを日次にするか即時にするかを、方式の決定と同時に決めておきます。ここが曖昧なまま進むと、システムごとにマスタが分かれ、刷新前と同じ二重入力が残ります。

リプレイスのタイミング：残り期間で選べる方式が変わる

リプレイスの時期は、ハードウェアの保守期限、OSや製品のサポート期限、事業の節目（期首、拠点の新設）などで決まります。ここで押さえておきたいのは、期限までの残り期間が短いほど、選べる方式が減ることです。

たとえば、サーバーOSのWindows Server 2016は、Microsoftの公式ライフサイクル情報で延長サポートの終了が2027年1月12日（米国時間）とされています。2026年11月の時点で、このOS上で動く基幹システムの刷新を始める場合、残りは約2か月しかありません。この期間で業務の見直しを伴う方式を終えるのは現実的ではなく、まずはリホストやセキュリティ対策でつなぎ、並行して本命の方式を検討する、という二段構えになります。SAP ERPを使っている会社の保守期限の論点はSAP 2027年問題とはで解説しています。

※目安です。システムの規模、データ量、社内の体制によって変わります。

期限が迫ってから方式を決めると、業務を変える方式は選べなくなります。保守期限が分かっているなら、期限の2年前には方式の検討を始めると、比較したうえで選べます。

方式を決める前のチェックリスト

ベンダーに見積もりを依頼する前に、次の項目を社内で確認してください。

• リプレイスの目的（保守切れ対応か、業務改善か、その両方か）を経営と合意している
• 要望を「業務を変える」「業務を変えない」に仕分けている
• 現行システムの仕様書・プログラム一覧・利用状況がどの程度残っているか把握している
• 現行システムを保守している会社が、全体の業務知識を持っているか確認した
• 使われていない機能・帳票・プログラムを洗い出した
• 廃止する機能、SaaSや別システムに切り出す機能の候補がある
• パッケージやSaaSを候補にするなら、標準に合わせられない業務の一覧がある
• 一括切替か段階切替かの方針と、その理由がある
• 保守期限・サポート期限から逆算した残り期間を把握している
• 方式の選定で実現できなくなる要求と、その扱いを記録している

よくある質問

まとめ

基幹システムのリプレイスは、「業務を変えるか」「基盤を変えるか」「プログラムを作り直すか」で、リホスト・リライト・再構築・パッケージ置換・SaaS移行の5つの方式に分かれます。要求事項を採点して候補を絞り、業務を標準に合わせられるかで最終的に選ぶ。規模が大きいなら段階に分け、期限から逆算して方式の検討を早めに始める。この順で考えれば、見積もりの比べようがない、選んだ方式と要望が合わない、という事態を避けられます。

自社にどの方式が合うか判断がつかない場合は、無料診断で現行システムの状態と要望を整理し、候補となる方式を絞り込めます。