レガシーシステムは作り直すべきか｜改修で延ばせる限界と、リプレースに踏み切る判断基準【2026年】

2026-10-05 2026-10-04

十数年前に作ったシステムが、いまも動いている。止まってはいないけれど、少し直すだけで見積もりが跳ね上がる。作った会社の担当者はもういない。そろそろ作り直したほうがいいのか、まだ直しながら使えるのか。判断がつかないまま、毎年の保守費だけが出ていく。

こうした状態のシステムは、レガシーシステムと呼ばれます。ただし、この言葉には「古いから悪い」という響きがあって、そのまま受け取ると「作り直すしかない」という結論に流れがちです。実際には、直して使い続けたほうが合理的な場合もあります。

この記事では、いまのシステムがどのくらいレガシー化しているのかを測る方法と、改修を続ける、一部だけ置き換える、全面的に作り直すという3つの選択肢の分かれ目を整理します。Enlyt（エンライト）が実際に関わった、既存の仕組みを残したまま一部だけ新しくした進め方にも触れます。

なお、スマートフォンアプリのリニューアルについては判断の材料が違うので、アプリのリニューアルで作り直す前にで別に扱っています。表計算ソフトで業務を回していて、そもそもシステムがないという場合は、エクセルの共有はどこまでできるかのほうが近いはずです。

レガシーシステムとは？何年たったら古いのか

レガシーシステムに、年数の定義はありません。20年動いていても手を入れやすいシステムはありますし、5年前に作ったものが誰も触れない状態になっていることもあります。

実務上は、技術そのものの古さより、次のどちらかが起きている状態を指して使われます。ひとつは、変えたいときに変えられないこと。もうひとつは、中で何が起きているのかを社内の誰も説明できないことです。

レガシー化を示す6つの状態

• 使っている技術のセキュリティ更新が終了している、または終了が近づいているのに、更新や移行の計画が立っていない
• 設計書や仕様書が残っておらず、動いているプログラムだけが正解になっている
• そのシステムに手を入れられる人が、社内にも委託先にも限られている
• 長年の改修が積み重なり、1か所を変えると別の場所に影響が出る
• 他のシステムやサービスとデータを連携する機能やAPIが用意されていない
• 画面や操作が現在の業務の流れと合っておらず、人が手で補っている

いくつ当てはまるかで深刻度が決まるわけではありません。ただ、これらが重なると、影響調査や引き継ぎ、テストの負担が増え、改修を進めにくくなることがあります。

「2025年の崖」は結局どうなったのか

経済産業省が2018年に出したDXレポートで示された「2025年の崖」という言葉が、レガシーシステムの話にはよく登場します。既存システムが部門ごとに作られ、過剰なカスタマイズで複雑化・ブラックボックス化している状態を解消できなければ、2025年以降に最大で年間12兆円、当時の約3倍にあたる経済損失が生じる可能性がある、という試算でした。老朽化そのものではなく、変えられない状態が続くことを問題にしています。

その2025年は過ぎました。ここで注意しておきたいのは、2025年がすべてのシステムに共通する更新期限だったわけではないこと、そしてこの12兆円という数字が、2025年に実際に発生した損失額を示したものでもないことです。

自社の判断に使えるのは、こうした全体の試算ではなく、使っている製品のサポート期限と、業務への影響のほうです。自治体であれば、情報システムの標準化という別の期限もあります。

崖という比喩よりも、自分たちが使っている技術の期限表を見るほうが、判断の材料になります。これは後ろの章で扱います。

いまの状態を測る6つの指標

「なんとなく古い」という感覚だけでは、稟議にも開発会社への相談にも判断材料が不足しがちです。どのくらいレガシー化しているのかを社内で確認できるものから見ていきます。まずは既存の見積書や運用の記録から確認できます。

1　同じくらいの改修に対する見積もりが、以前より上がっているか

過去3年から5年の改修見積もりを並べてみます。規模が似ている改修でも、年を追うごとに工数が増えているなら、システムの中で変更しにくい状態が進んでいる可能性があります。

比べるときは、単価が上がっているのか、工数が増えているのかを分けて確認します。単価だけが上がっている場合は、システムの状態とは別の要因です。

工数が増える理由はいくつかあります。影響範囲の調査に時間がかかるようになっている、過去の改修の上に積む形になっていて手数が増えている、テストしなければならない範囲が広がっている、といったことです。見積書の内訳が工程ごとに分かれていれば、どこが膨らんでいるかまで追えます。見積書の読み方はシステム開発の見積もりを人月から読み解くで扱っています。

2　ひとつ機能を足すまでに、何日かかっているか

依頼してから実際に使えるようになるまでの日数です。以前は2週間だったものが2か月かかるようになっているなら、システムの変更が、業務上必要な時期に間に合わなくなっている可能性があります。

この日数も、影響調査や開発に要した時間と、委託先の着手待ちや社内の承認待ちを分けて見てください。待ち時間が長い場合は、システムの構造に加えて、委託先の体制や社内の承認手順にも改善の余地がないかを確認します。

この指標は、費用より経営に説明しやすいという利点があります。制度が変わった、料金体系を変えたい、新しい窓口を作りたい。そのたびにシステムの改修を待つことになり、待っている間は手作業で回す。その手作業にかかっている人件費は、保守費の請求書には出てきません。

3　そのシステムに手を入れられる人が、何人いるか

数えるときは、業務の内容を説明できる人と、技術的に改修できる人を分けます。自治体であれば、職員が業務の仕様を把握し、委託先の技術者がプログラムを改修する、という分担になっていることが多いためです。片方だけがいても改修は進みません。

どちらかが特定の1人や2人に偏っていて、代わりの担当者も引き継ぎ資料もない場合は、異動や退職によって改修が止まるおそれがあります。

観光施設や自治体のように、担当者の異動が定期的にある組織では、ここが先に効いてきます。仕組みを理解している人が替わると、前任者が口頭で把握していた前提が引き継がれず、残っている資料だけでは説明がつかない部分が出てきます。

4　設計書と仕様書が、いまの状態と合っているか

資料が残っているかどうかではなく、残っている資料が現在の動きと一致しているかを見ます。改修のたびに資料を更新していないと、紙の資料とプログラムの中身がずれていきます。

ずれていると、作り直すときにも改修するときにも、まず現状を調べるところから始めることになります。この調査は見積もりに乗ってくる作業なので、資料の状態がそのまま費用に反映されます。

5　障害と、人の手による補いが、どれくらい起きているか

月に何回止まったか、月に何回手作業で直したかを数えます。止まる回数だけでなく、「システムがこうなっているから、毎月この作業を人がやっている」という運用の回避策も数に入れます。

この回避策は、現場に定着してしまうと誰も問題だと思わなくなります。棚卸しのときに現場へ聞いて回ると、想定より多く出てくることがあります。

6　依存している技術に、期限が来ているか

サーバーのOS、データベース、プログラムの実行環境。これらにはそれぞれサポート終了の期限があります。ここだけは社内の事情と関係なく外部要因として期限がくるので、別の章に分けました。

判定の目安

6つの指標を、おおまかに3段階で見ます。該当する段階が混在するのが普通なので、どの指標がどの段階にあるかを並べて見てください。

この表は、相談や検討の優先順位を整理するためにこの記事で置いた目安です。公的な判定基準ではありません。実際の対応時期は、業務への影響と、調達や調査、移行に必要な期間を踏まえて決めることになります。

右側の列に入る指標が増えるほど、改修を重ねる前提が崩れていきます。ただし、右側がひとつあるだけで全面的な作り直しが決まるわけではありません。どの指標が右側に来ているかによって、取るべき選択肢が変わります。

サポート終了という、コントロールできない期限

6つの指標のうち、社内の判断で先送りできないのがこれです。セキュリティ更新の提供が終了し、延長更新制度も利用できない場合は、新しく見つかった脆弱性の修正を受けられなくなります。個人情報や決済を扱うシステムであれば、ここは期限として扱うことになります。

自社のシステムが何の上で動いているかは、保守を委託している会社に聞けば出てきます。まずはサーバーのOS、データベース、プログラムの実行環境とそのバージョンを確認します。あわせて、利用しているフレームワークや主要なライブラリ、組み込んでいるパッケージ製品のサポート期限も確認してください。

通常のサポートや主要なサポート段階が終了しているもの

2026年10月時点で、業務システムでよく使われてきたもののうち、通常のサポートや主要なサポート段階が終わっているおもなものです。延長の仕組みが続いているものもあるので、補足欄を合わせて見てください。

以下は各製品・公式プロジェクトのサポート期限です。OSベンダー、クラウド事業者、別途契約した保守サービスから更新を受けている場合は、その対象範囲と期限も確認してください。Linuxディストリビューションのように、上流とは別の保守期間を持つものもあります。

2027年末までに終了するもの

この表には、サポートが終了するものと、別のサポート段階や延長更新制度へ移るものが含まれています。その後に受けられる支援は、右の列で確認してください。

表を読むときに気をつけたい点が3つあります。

• 同じ製品でもエディションによって終了日が違います。Windows 11は、同じバージョンでもHome・Pro版と、Enterprise・Education版で1年ずれます
• 「サポート終了」が何を指すかは製品ごとに違います。PHPはバグ修正までの期間とセキュリティ修正までの期間が分かれていますし、Windows ServerやSQL Serverはメインストリームと延長サポートで数年の差があります
• 延長の制度は製品によって中身が違います。MicrosoftのESUは対象となるセキュリティ更新を提供する制度で、通常のサポートや機能追加を続けるものではありません。一方、Red Hatのメンテナンスサポートのように、対象となる不具合の修正まで提供されるものもあります。契約が要るかどうか、何が提供されるのか、いつまでかを製品ごとに確認します

日付は変更されることがあります。Red Hatは将来の終了日について、近似値であり変更の可能性があると自社のページに明記しています。記事の表を根拠にするのではなく、下の確認先で自社の該当バージョンを確かめてください。

期限の確認先

• Microsoft製品（Windows、Windows Server、SQL Server、.NET）　Microsoft ライフサイクル検索
• PHP　Supported Versions
• PostgreSQL　Versioning Policy
• Oracle Java　Java SE Support Roadmap
• Red Hat Enterprise Linux　Life Cycle
• Ubuntu　Release cycle
• Node.js　Previous Releases
• MySQL　EOL Notice
• CentOS　CentOS Linux
• Python　Status of Python versions

自治体のシステムには、もうひとつの期限がある

地方公共団体の情報システムには、標準化という別の枠組みがあります。原則として令和7年度までに標準準拠システムへ移行することを目指すとされており、その期限は2026年3月末で過ぎています。

デジタル庁が2026年6月30日に公表した資料によると、2026年3月末時点で、対象となる全34,366システムのうち、24,353システム（70.9%）が標準準拠システムへの移行を完了しています。一方、同年度末までに移行できなかった「特定移行支援システム」は10,013システム（29.1%）です。これらを有する団体は、全1,788団体のうち1,015団体（56.8%）になります。

特定移行支援システムについては移行完了の期限をあらためて設定し、概ね5年以内に移行できるよう国が支援するという整理です。支援のための基金の設置年限は令和12年度まで延長されました。

なお、標準化基準に適合したシステムを使うことは法律上の義務ですが、クラウドの活用については、国が整備した環境においてクラウドを活用して情報システムを利用するよう努める、という努力義務の書き方になっています。詳しくは総務省の資料で確認できます。

標準化の対象は20業務です。観光情報、公共施設の予約、地域交通などのシステムは、通常この20業務には含まれません。ただし、更新を検討するときは、自治体全体のセキュリティや調達の方針、他のシステムとの連携条件も確認します。対象外のシステムほど後回しになりやすく、気づいたときには基盤ソフトの期限だけが来ている、という形になりがちです。

レガシーシステムに対して、取れる選択肢は3つ

レガシーシステムの話は「脱却するかどうか」の二択で語られることが多いのですが、実際にはその間に選択肢があります。

改修を続けて使う

いまの仕組みを残したまま、必要なところだけ直していく進め方です。基盤ソフトのバージョンだけを上げる作業が必要になることもあります。

改修範囲を限定できれば、費用と業務への影響を抑えやすくなります。一方で、6つの指標が右側に寄っているシステムでは、調査やテストの負担が増え、改修1件あたりの費用が上がりやすくなります。いつまで続けるのかを決めずに選ぶと、判断が先送りになりやすくなります。

一部だけを置き換える

いまの仕組みは動かしたまま、業務のうち効果の大きい部分だけを新しく作り、既存システムとつなぐ進め方です。対象を分けて順に置き換える場合は、段階的な移行として進められます。

基盤全体の刷新とは別に、既存システムを活かしながら利用者との接点を改善した例もあります。Enlytが関わった地域交通の事例では、既存の配車システムはそのまま残し、利用者が予約する画面だけをLINE上に新しく作りました。既存システムのAPIと連携する形にしたため、裏側の仕組みを作り直さずに、電話予約に頼っていた層が自分で予約できる経路を増やしています。この進め方の実際は乗車予約アプリの開発事例にまとめています。

自治体の観光情報でも、既存Webサイトのスマートフォンでの使いにくさに対して、店舗検索や営業状況の確認ができるLINEミニアプリを用意した例があります。こちらは観光情報のLINEミニアプリの開発事例をご覧ください。

全面的な作り直しに比べて、一度に動かす範囲が小さくなります。途中でやめる判断もできます。ただし、新旧が並んで動く期間が生まれるため、どちらが正しいデータを持つのかを決めておく必要があります。段階的に置き換える場合は、各段階で残す機能と廃止する機能、そして旧システムをいつまで保守するのかも決めます。

もうひとつ注意があります。入口の画面だけを新しくしても、既存システムの保守やサポート期限の問題は残ります。利用者の使いやすさを改善する判断と、基盤を更新する判断は、それぞれ分けて確認する必要があります。

全面的に作り直す

いまの仕組みを置き換えて、新しく構築する進め方です。長年の制約から離れられますが、期間も費用も大きくなり、業務への影響も広がります。

作り直すと決めた後は、既製品で賄う部分と自社向けに作る部分をどう分けるかという話になります。この分かれ目はパッケージ・SaaS、ローコード、フルスクラッチの違いと選び方で扱っています。進め方と工程についてはWebシステム開発とはが参考になります。

3つの比較

どれを選ぶかの分かれ目

全面的に作り直すほうへ傾く条件

• 基盤ソフトのサポートが終了している、または1年以内に終了し、そのバージョンだけを上げることが技術的に難しい
• 手を入れられる人がいない状態になっていて、改修の依頼先そのものが見つからない
• 業務の流れ自体が当時と変わっていて、いまの画面構成では合わせきれない
• データを他のシステムやサービスに渡す必要が出ているのに、連携する機能やAPIを作れない

このうち複数が同時に起きているときは、改修を重ねても同じ問題に戻ってきます。

一部だけ置き換えるほうが合う条件

• 困っているのが特定の業務や特定の利用者に集中していて、他は問題なく回っている
• データを保持している中核の部分は安定していて、使いにくいのは入口の画面のほうである
• 一度に全部を止める余裕がない、または年度の区切りで予算を分ける必要がある
• 既存システムにデータを連携する機能やAPIがあるか、作れる見込みがある

観光施設や自治体で起きている困りごとは、「中の仕組みが悪い」よりも「利用者から見た入口が使いにくい」ほうであることがあります。その場合、入口だけを新しくして裏側とつなぐほうが、費用も期間も小さく収まります。

いま作り直さない判断が合理的なケース

作り直さないという結論も、条件を決めたうえで選べば判断です。

• 基盤ソフトの期限に余裕があり、接続経路と扱う情報を確認したうえで、当面の運用に支障がないと判断できる
• 業務そのものが数年以内に変わる見込みがあり、いま作り直すと作り直しが二度になる
• 対象業務を外部のサービスに移す検討が進んでいて、システムを作る前提自体が変わりうる
• 要件を決める担当者を確保できておらず、まずは社内体制と現行資料の整理を進める必要がある

この判断を選ぶ場合は、「いつまで様子を見るか」と「何が起きたら動くか」を決めて記録しておきます。それがないと、様子を見ているのか忘れているのかの区別がつかなくなります。あわせて、延期している間も保守と必要な安全対策は続けます。作り直さないことと、手を入れないことは別です。

作り直すと決めた後に出てくること

仕様書が残っていないシステムをどう扱うか

作り直す場合も一部を置き換える場合も、いまの仕組みが何をしているかが分からないと、新しいものの要件が決まりません。資料が残っていないときは、動いているシステムから読み解く作業が必要になります。

この作業には、プログラムとデータベースの調査と、現場への聞き取りの両方が要ります。現場でしか把握されていない運用の回避策は、資料にもプログラムにも出てこないことがあるためです。

読み解いた結果は、次に作り直すときのために資料として残しておくと、同じ調査を繰り返さずに済みます。要件のまとめ方は仕様書とは。書き方と落とし穴で扱っています。

新旧が並んで動く期間の設計

切り替えは、ある日を境に一斉に入れ替わるとは限りません。業務を止められない場合、しばらく新旧が並んで動く期間が生まれます。

この期間について、あらかじめ決めておきたいことがあります。どちらが正しいデータを持つのか、両方に入力する運用になるのか、片方だけでよいのか。問題が起きたときに元に戻すのか、前に進めるのか。戻す場合、どこまで戻せばよいのか。

年度の区切りがある組織では、切り替えの時期そのものが制約になります。年度末に重なる業務を避けて計画を立てると、準備の期間が逆算で決まります。

データの移し替え

長く運用しているシステムでは、入力ルールの変更や表記のゆれが蓄積していることがあります。途中でルールが変わっていたり、使われなくなった項目が残っていたり、同じ意味の値が複数の書き方で入っていたりします。

移す前に、どこまで整えてから移すのか、何年分を移すのかを決めます。データを整理せずに移すと、不要な項目や表記のゆれも引き継いでしまいます。移さないと決めたデータをどう参照できるようにしておくかも、合わせて考える部分です。

移した結果の確かめ方も決めておきます。本番の切り替え前に移行を試し、件数や金額、関連するデータの整合性と、主要な業務が通るかを確認します。切り替えの直前まで更新されたデータをどう反映するかも、そのときに決める項目です。

既存システムとつなぐ場合の技術的な判断は、既存システムとの連携方法でも触れています。

相談する前に、社内でそろえておきたいもの

最初の相談では、何に使っているシステムか、いま困っていること、対応したい時期を、分かる範囲でお伝えいただければ十分です。次の項目まで整理できていると、その後の検討を進めやすくなります。すべて埋まっていなくても構いません。

• いま動いているシステムの一覧と、それぞれが何に使われているか
• サーバーのOS、データベース、プログラムの実行環境とそのバージョン
• 過去3年から5年の改修の記録。内容、費用、かかった期間
• 残っている設計書や仕様書と、それが最後に更新された時期
• 現場で行われている手作業の回避策
• とくに困っている業務と、困っているのが誰か
• 予算の枠と、動かせない時期

このうち技術的な項目は、保守を委託している会社に聞けば答えが返ってきます。業務側の項目は、現場に聞いて回る必要があります。

費用の目安を先に知りたい場合はシステム開発の費用相場とシステム保守費用の相場を、社内で予算を通すときの考え方はDX推進の費用をご覧ください。

よくある質問

レガシーシステムは何年たったらそう呼ばれますか

年数の基準はありません。変えたいときに変えられるか、中で何が起きているかを説明できるかで判断します。20年動いていても手を入れやすいシステムはあります。

リプレースとリプレイス、どちらが正しいですか

どちらも同じ意味で使われています。英語のreplaceをどう書き写すかの違いで、どちらが誤りということはありません。見積書や契約書では、同じ文書の中で表記をそろえておくと読みやすくなります。

マイグレーションとリプレースはどう違いますか

マイグレーションは、システムやデータを別の環境へ移すことです。サーバーをクラウドへ移す、といった使い方をしますが、移行にあわせてプログラムや構成を変更する場合も含みます。リプレースは、既存のシステムや製品を新しいものに置き換えることです。モダナイゼーションは、既存システムを現在の要件に合わせて改善する取り組み全般を指します。これらは重なる場合もあるので、提案を受けたときは、何をどこまで変える話なのかを確認しておくと行き違いが減ります。

サポートが終了した基盤ソフトを使い続けると、すぐ問題が起きますか

終了した翌日に動かなくなるわけではありません。問題は、セキュリティ更新の提供が終了し、延長更新制度も利用できない場合に、新しく見つかった脆弱性の修正を受けられなくなることです。ただし、インターネットから直接アクセスできない環境だからといって、それだけで使い続けてよいと判断できるわけではありません。接続の経路、扱っている情報、更新を受けられる制度があるか、バックアップと復旧の手順を確認したうえで、いつまで続けるのかと、その間の対策を決めます。

いまの開発会社以外に相談してもよいですか

相談すること自体に問題はありません。ただし、現行システムの資料や、データベースの中身を見られるかどうかで、他社が出せる見積もりの精度が変わります。契約でソースコードや資料の扱いがどうなっているかを先に確認しておくと、話を進めやすくなります。会社を選ぶときの基準はシステム開発会社の選び方で扱っています。

Enlytでは、他社が開発したシステムやアプリについて、現状把握から運用の整理、改善の方向性の検討までをプロダクト引き継ぎ・改善サービスとして扱っています。資料が残っていない場合も、ソースコードを確認して仕様を読み解き、ドキュメントを作成するところから対応しています。

一部だけ置き換えると、かえって複雑になりませんか

新旧が並ぶ期間は、構成としては複雑になります。そのため、どちらが正しいデータを持つのかを決めておくことと、置き換える範囲を業務の区切りで切ることが前提になります。範囲の切り方が曖昧なまま始めると、どちらにも属さない処理が残ります。

Enlytの関わり方

Enlytでは、作り直すかどうかを決める前の段階から相談を受けています。いまの仕組みの何が問題で、どこまでを今回の対象にするのかを一緒に整理したうえで、進め方と費用を出す順番です。受注前の無料コンサルティングとして行っています。現行システムの詳細な調査が必要な場合は、調査の範囲や費用についてもご相談時に確認します。

全部を作り直す提案に寄せないことも、ここでの方針です。既存の仕組みを残して入口だけを新しくしたほうが目的に合う場合は、その形を提案します。既存システムのAPIと連携する構成や、紙や電話に頼っていた経路を補う仕組みは、これまでにも手がけてきました。

国内のプロジェクトマネージャーが窓口と設計を担い、海外の開発チームと組む体制です。AIも活用して作業の効率化を図り、品質を保ちながら開発費用を抑えることを目指しています。

これまでの開発の内容と進め方は開発実績の一覧に、対応範囲はサービス紹介ページにまとめています。進め方や費用の考え方を先に知りたい場合は、お役立ち資料もご利用ください。

まとめ

レガシーシステムかどうかは、年数では決まりません。同程度の改修に必要な工数の推移、機能追加にかかる日数、手を入れられる人の数、資料と実態の一致、障害と手作業の回避策、基盤ソフトのサポート期限。この6つを並べると、いまどの段階にいるのかが見えてきます。

そのうえで取れる選択肢は3つあります。改修を続ける、一部だけ置き換える、全面的に作り直す。真ん中の選択肢は見落とされがちですが、困りごとが特定の業務に集中している場合は、一部だけ置き換える方法が適していることがあります。

サポート終了の期限だけは、社内の都合で動かせません。まずは、自社のシステムがどのOS、どのデータベース、どの実行環境で動いているかを保守の委託先に確認して、公式のページで期限を調べるところから始めてみてください。そこで余裕があると分かれば、落ち着いて他の指標を見ていけます。

関連記事

• アプリのリニューアルで作り直す前に｜維持費と使われ方から判断する4つの選択肢
• フルスクラッチ開発とは？パッケージ・ローコードとの違いと選び方
• Webシステム開発とは？できること・構築の流れと費用が変わる仕組み
• システム開発の見積もりを人月から読み解く
• システム開発の費用相場【2026年】
• システム保守費用の相場
• DX推進の費用は中小企業でいくら？
• エクセルの共有はどこまでできるか
• 仕様書とは？書き方と落とし穴
• LINEミニアプリと既存システムの連携方法

金子 遼平

フィリピンの語学学校スタッフとして5年間勤務後、Enlytに参画。 現在はフィリピン在住で完全リモートにて、開発ディレクター・PM・デザイナーとして複数プロジェクトを担当。 UI/UX設計とプロジェクトマネジメントを横断できる点を強みとし、リモート環境下でも安定した品質とスピードを実現している。

View More