基幹システム刷新の判断基準｜5テーマと4手法で決める

◆監修・編集責任者　小園 将隆　2026年8月17日

B2B EC-COLUMN

基幹システムの刷新とは何か、判断はどの順番で決まるのか

基幹システムの刷新の判断基準とは、目的の言語化・現行調査・手法選択・投資対効果とリスクの見極めという4点で決める判断の手順です^*1。症状の有無ではなく、この4点を順番に確かめることが刷新の可否を左右します。稼働年数だけでは決まりません。

刷新とは基盤を含めて作り替えることを指す

IPA（独立行政法人情報処理推進機構）は、ソフトウェアの品質・信頼性向上に取り組む公的機関です。「システム再構築を成功に導くユーザガイド 第2版」^*1は、現在利用しているシステムの基盤を始めとする製品を新しいものに変える取り組みが、マイグレーションやシステム再構築と呼ばれてきたと整理しています^*1。そのうえで、4つの手法の定義は企業や書籍によって異なるとしたうえで、本ガイドでは現行システムのどのレイヤの設計情報を維持するかによって4種類に分類すると明記しています^*1。

この線引きを最初に押さえておくと、「刷新すべきか」という問いを、単なる機能改善の要否と混同せずに検討できます。

判断は4つのステップで決まる

同ガイドは、再構築の判断を①現行システムの調査・分析②新システムの要求事項分析③再構築手法の選択④再構築手法の決定という4ステップで進めると整理しています^*1。症状を並べて「当てはまったら検討」で終わらせず、この順番で判断材料をそろえてから決めることが、判断の精度を左右します。

61%がレガシーを抱え、過半が移行先を決めていない

経済産業省 商務情報政策局 情報産業課は2025年5月28日、「DXの現在地とレガシーシステム脱却に向けて」を公表しました^*2。同調査は2024年12月17日〜2025年2月14日に実施され、約4,000社への調査に対する回答は799社です^*2。ユーザー企業の61%がレガシーシステムを保有し、大企業に限ると74%に上ります^*2。メインフレーム保有企業のうち52%はすでに他の基盤へ移行済み（n=333）ですが、移行先の形態は過半が未決定です^*2。判断を迫られながら、次の一手を決めきれていない企業が少なくありません。

「古い」と「レガシー」は違う――5つの要因で判定する

刷新を検討する担当者がまず確認すべきなのは、稼働年数ではなく5つの要因への該当有無です。経済産業省のレポート^*2は、レガシーシステムを技術3要因・経営2要因で定義しています。

技術の老朽化・肥大化と複雑化・ブラックボックス化という3つの技術要因

技術面の要因は3つです^*2。技術そのものが古くなる「技術の老朽化」を指します。加えて、改修を重ねてシステムが大きく入り組む「肥大化・複雑化」、仕様書と実装が乖離した「ブラックボックス化」も含まれます。いずれも改修コストや障害対応の難易度を押し上げます。

IT投資不足と古い制度としがらみという2つの経営要因

経営面の要因は2つです^*2。基盤やアプリケーションへの更新投資が長く行われていない「IT投資がされていない」状態を指します。加えて、古い業務ルールや商習慣がシステムに固定化される「古い制度としがらみ」も含まれます。技術要因だけでなく、この経営要因も併せて確認する必要があります。

メインフレームでもレガシーとは限らず、脱却後も再びレガシー化しうる

同レポートは、メインフレーム等の古い技術で構築されていても、保守体制が整備され仕様が明確であればレガシーシステムには当たらないと明記しています^*2。逆に、いったん新しい基盤へ移行しても、更新投資を怠れば再びレガシー化する可能性があります。「古い技術＝レガシー」という単純な図式で判断しないことが重要です。

観点	確認項目
技術の老朽化	保守可能な技術者を確保できているか。 ハードウェア・OSのサポート期限が迫っていないか。
肥大化・複雑化	改修のたびに影響範囲の特定に時間がかかっていないか。
ブラックボックス化	仕様書と実装が一致しない箇所を把握できているか。
IT投資の不足	数年以上、基盤への更新投資をしていない状態が続いていないか。
古い制度としがらみ	古い運用に合わせた業務ルールが温存されていないか。

刷新の目的を5つのテーマで言語化する

技術3要因・経営2要因での判定に加えて、刷新に踏み切るには「何のために刷新するのか」を言語化する必要があります。IPAのガイド^*1は、再構築の目的を5つのテーマに整理しています。

HW/SW老朽化対応・維持コスト削減・業務スリム化・柔軟性向上・要員不足対応という5テーマ

5つのテーマは、ハードウェア・ソフトウェアの老朽化対応、維持コストの削減、業務プロセスのスリム化、事業環境変化への柔軟性向上、要員不足への対応です^*1。自社の課題がどのテーマに当てはまるかを言葉にすることが、次のステップである手法選択の起点になります。

目的が曖昧だと進むか止めるかも決められない

IPAのガイドは、再構築の目的がはっきりしないと、再構築に進むべきか止めるべきかの判断も曖昧になると明記しています^*1。5テーマのどれにも当てはまらない、あるいはどれにも薄く当てはまるだけの場合は、刷新以外の選択肢を検討する余地があります。

優先度は保守性重視か柔軟性重視かで分かれる

複数のテーマが同時に当てはまる場合は、運用コスト削減・保守性の向上を優先するのか、業務スリム化・柔軟性向上を優先するのかで、選ぶべき手法の方向性が変わります^*1。優先順位を決めずに進めると、後述する手法選択の段階で判断が揺れやすくなります。

柔軟性向上を目的に挙げる企業では、受発注や取引先とのデータ連携を新たに増やしたいという事情が背景にあることが少なくありません。この場合、基幹システムを全面的に作り替えなくても、受発注・EC側の仕組みを切り出して先行して整える選択肢が成立し得ます。連携方式の具体的な設計は別稿に譲ります。

判断の前に、現行システムを6つの観点で調べる

目的を言語化したら、次はIPAのガイドが示す現行システムの調査観点^*1に沿って、自社の現状を具体的に把握する段階に入ります。

資産・処理方式・非機能要件で現行の規模と作りを押さえる

調査観点の柱は、システム資産の量・種類、オンラインやバッチといった処理方式、性能や可用性などの非機能要件です^*1。これらを押さえることで、再構築の規模感や難易度をおおまかに見積もれます。

業務知識の保有状況が判断を左右する

もう一つの重要な観点が、業務知識を持つ有識者やドキュメントがどれだけ残っているかです^*1。この調査には、システム構成の理解に加えて、現場の業務プロセスに精通した担当者の関与が欠かせません。有識者がすでに退職・異動している場合は、調査そのものに時間がかかる点を見込んでおく必要があります。

業務データと保守状況が投資対効果の比較元になる

業務データの量・構造、現行システムの運用コストと保守コストも調査観点に含まれます^*1。これらは、後述する投資対効果の判断で「刷新した場合と現状維持を続けた場合のどちらが有利か」を比較する土台になり、業務データの移行実務については別稿で扱います。

現状のコストを可視化したうえで、自社の数字で判断材料を整理するには無料相談を利用するという選択肢もあります。第三者の視点を交えると、調査観点の抜け漏れに気づきやすいでしょう。

刷新の手法は4つ――何を変えるかで決まる

現行調査が終わったら、手法の選択に進みます。IPAのガイドは、業務仕様・基盤・開発言語のどれを変えるかによって、候補となる手法を絞り込む考え方を示しています^*1。

業務仕様・基盤・開発言語の変更有無で候補が決まる

4つの手法は次のとおりです^*1。既存の基盤だけを更新する「ハードウェア更改」と、開発言語や業務仕様を変えずに基盤を移す「リホスト（既存の資産を新しい基盤に移す手法）」の2つがあります。加えて、業務仕様を維持しながら開発言語を刷新する「リライト」、業務仕様から作り直す「リビルド」も含まれます。どこまで変える必要があるかが、選ぶべき手法を決めます。

リビルドは柔軟性を高められるがコストと有識者の関与がより高く求められる

IPAのガイドの記述に沿うと、リビルドは保守性や業務の柔軟性を大きく高められる一方、コストと業務有識者の関与がより高く求められます^*1。リホストやリライトは業務仕様の再現性を確保しやすい半面、保守性や柔軟性は現行システムと同程度にとどまります^*1。「変えれば変えるほど良い」わけではなく、目的に見合った変更範囲を選ぶことが重要です。

手法	現行資産の活用度	業務仕様の再現性	保守性・柔軟性	コスト・業務有識者の関与
ハードウェア更改	最も高い（基盤のみ更新）	完全に維持	現行と同等	最も小さい
リホスト	高い（言語・仕様は不変）	高い	現行と同等*1	比較的小さい
リライト	中程度（言語のみ刷新）	高い	現行と同等*1	中程度
リビルド	低い（業務仕様から刷新）	設計次第で変動	現行より高められる*1	最も大きい*1

業務単位・サブシステム単位で手法を分けてよい

システム全体を1つの手法に統一する必要はありません。IPAのガイドは、オンライン業務はリビルド、バッチ業務はリライトまたはリホストとする組み合わせ例を挙げています^*1。手法を決めたあとの移行の進め方は、別稿で扱います。

パッケージ・SaaSを先に検討する――中堅・中小の原則

ここまでの4手法は現行資産をどう扱うかの選択ですが、その手前に開発方式そのものの選択があります。経済産業省は、この開発方式の選び方について中堅・中小企業向けの方針を示しています^*2。

現行機能の維持にこだわらず、あるべき業務の姿から検討する

同レポートは、現行機能保証や現行踏襲へのこだわりを見直し、あるべき業務の姿から検討することを求めています^*2。現状の機能をそのまま新システムに引き継ごうとすると、選択肢が狭まり、パッケージやSaaS（ソフトウェア・アズ・ア・サービス。事業者がインターネット経由で提供する既製のソフトウェア）の活用が難しくなります。

中堅・中小企業はスクラッチ開発を避けるのが原則

経済産業省は、中堅・中小企業に対してスクラッチ開発（ゼロから独自に構築する開発方式）を避け、パッケージやSaaSの利用を原則とすべきだと明記しています^*2。自社で開発体制を抱え続けるコストと、パッケージ活用によって得られる保守性を比較したうえで方針を決める必要があります。

Fit&Gap分析でギャップの大きい業務だけ最小限のカスタマイズにとどめる

パッケージ導入時には、Fit&Gap分析（自社業務とパッケージの標準機能の差分を洗い出す分析）が欠かせません^*2。大きなギャップがある業務だけに絞り、最小限のカスタマイズにとどめる方針が示されています^*2。同レポートによれば、現行システムでカスタマイズしている企業は、移行先でもカスタマイズを続ける割合が高いというデータもあります^*2。惰性で積み増さないよう、あらかじめ方針を決めておくことが望まれます。

決定は投資対効果とリスクで行う――「今はやらない」も選択肢

目的の言語化、現行調査、手法の絞り込みを経て、最後は投資対効果とリスクによる決定です。IPAのガイドのステップ4^*1に沿って進めます。

ステップ4は投資対効果の確認からリスクの抽出・評価・対応方針・手法決定へ進む

ステップ4は、投資対効果の確認、リスクの抽出と評価、対応方針の検討、手法の決定という順で進みます^*1。手法を先に決めてから投資対効果を後付けで説明するのではなく、この順番を守ることが判断の一貫性を保ちます。

刷新しないと決める場合の3条件

調査と検討の結果、「今は刷新しない」という結論も成立し得ます。ただし、先送りにする場合は、次の3条件の管理が欠かせません。

基幹連携側の固定期限としては、NTT東日本がINSネット64・INSネット64ライト・INSネット1500について、2028年12月31日にサービスの提供を終了すると公表しています^*5。なお「ディジタル通信モード」のデータ通信サービスは、2024年1月から地域ごとに順次終了しています^*5。個別の業務システムやパッケージの保守終了期日は、提供元の公式アナウンスで確認する運用を徹底してください。

先送りの結末は受動的な意思決定が上位を占める

経済産業省のレポートは、モダン化を決断する契機として、システム障害の頻発や保守サポート要員の確保不能といった受動的な要因が上位に並ぶことを示しています^*2。自律的に決断する企業は少なく、多くは問題が顕在化してから動いています。IPA「DX動向2025」も、日本のレガシーシステムの状況は2024年度と2023年度で傾向がほとんど変わらず、刷新が頭打ちになっている様子がうかがえると分析しています^*3。3条件のいずれかが崩れた時点で、あらためて判断のステップ1に戻る運用が現実的です。

判断を通す体制は経営層との情報共有とCxOの設置

同レポートは、経営層との情報共有やCxO（最高情報責任者等の経営幹部職）の設置と、モダン化の進捗の間に相関が見られると分析しています^*2。一方で、中期経営計画に大規模システムの導入・刷新を記載している企業は12%にとどまります^*2。情報システム部門だけで検討を完結させるのではなく、経営層と材料を共有する体制づくりが判断の前提となるでしょう。判断を社内で通す説明資料の作り方は別稿に譲ります。

この一連の調査と整理は、現行システムの資産・業務知識・保守コストを横断して洗い出す作業になります。社内の有識者が離れている場合は、調査観点の抜け漏れの確認や、業界の一般的な水準との比較を外部に依頼する選択肢もあります。切替方式の設計や、ベンダーへの要件提示は、別稿で扱います。

まとめ：基幹システム刷新は目的・現状・手法・投資対効果の4段で決める

本稿では、基幹システムを刷新すべきかどうかを判断する手順を整理しました。要点は3つに集約できます。第一に、判断の起点は「古いかどうか」ではなく、経済産業省が示す技術3要因・経営2要因への該当有無です^*2。第二に、刷新の目的をIPAの5テーマのいずれかで言語化できるかどうかが、進むか止めるかの分かれ目になります^*1。第三に、手法は業務仕様・基盤・開発言語のどれを変えるかで4種類から選び、最終判断は投資対効果とリスクで行います^*1。この手順に沿って現状を確認すれば、次に何を調べるべきかが見えてきます。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

基幹システムは何年で刷新すべきですか

稼働年数だけでは判断できません。経済産業省はレガシーシステムを技術3要因・経営2要因で定義しており^*2、年数にかかわらず保守体制が整い仕様が明確であればレガシーには当たりません。判断は年数ではなく、5要因の該当有無と、ハードウェア・ソフトウェアの保守終了期日で行います。

リホストとリビルドはどちらを選ぶべきですか

業務仕様を変更する必要があるかどうかで分かれます^*1。業務仕様を維持したまま基盤や言語だけを更新するなら、リホストやリライトが選択肢になります。保守性・柔軟性を大きく高めたい場合はリビルドが候補になりますが、コストと業務有識者の関与がより高く求められます^*1。

刷新の判断は情報システム部門だけで決められますか

決めきるのは難しいといえます。経営層との情報共有やCxOの設置とモダン化の進捗には相関が見られますが^*2、中期経営計画に大規模システムの導入・刷新を記載している企業は12%にとどまります^*2。情報システム部門の分析を経営層と共有する体制づくりが判断の前提になります。

パッケージへの移行でカスタマイズはどこまで許容されますか

経済産業省は中堅・中小企業に対し、現行機能の維持にこだわらない方針を示しています^*2。Fit&Gap分析で大きなギャップがある業務に絞り、最小限のカスタマイズにとどめる考え方です^*2。現行システムでカスタマイズしている企業は、移行先でも続ける割合が高い傾向が確認されており^*2、作り込みの積み増しには注意が必要です。

「今は刷新しない」と決めた場合、何を管理しておけばよいですか

保守終了期日・業務有識者とドキュメントの確保・IT資産の可視化の3点です。IT資産を可視化しておくと、老朽化したシステムや保守期限が近いソフトウェアの潜在的なリスクを特定できます^*2。この3つのいずれかが崩れた時点で、あらためて判断し直す運用が現実的です。

1. *1　出典：独立行政法人情報処理推進機構（IPA）技術本部ソフトウェア高信頼化センター（SEC）「システム再構築を成功に導くユーザガイド 第2版 〜ユーザとベンダで共有する再構築のリスクと対策〜」（2018年2月26日発行）
2. *2　出典：経済産業省 商務情報政策局 情報産業課「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）
3. *3　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025 日米独比較で探る成果創出の方向性」（2025年6月26日公表）
4. *4　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査 報告書 2026 ユーザー企業のIT投資・活用の最新動向」（2026年4月公開、2025年度調査）
5. *5　出典：東日本電信電話株式会社「INSネット（ディジタル通信モード）のサービス終了について」（2024年3月7日公表）