古いシステムを延命すると決めたら：延命の期限の決め方と、延命の間にやる6つのこと（判断シートつき）

「このシステム、そろそろ作り直したほうがいいですよ」と、保守会社や社内の担当から言われている。でも、作り直す予算は今年はない。来年度の予算に入れられるかも分からない。だから当面は今のまま使う。

こうした「当面このまま」という判断は、多くの会社で行われています。それ自体は悪いことではありません。業務の繁忙期を避けたい、ほかの投資を先にしたい、次のシステムの形がまだ決まらない。今すぐ作り直さない理由は、たいていもっともです。

困るのは、「当面」がいつまでなのかを決めないまま、何もせずに時間が過ぎることです。その間に、システムを動かしている部品のサポートが切れ、直せる人が辞め、ある日の障害をきっかけに、慌てて次のシステムを決めることになります。

この記事では、今のシステムを使い続けると決めたときに、それを「期限つきの計画」にする進め方をまとめます。

• 延命と「何もしない先送り」は何が違うか
• 延命の期限の決め方（部品のサポートの期限と、直せる人）
• 延長サポートで延ばせるものと、延ばせないもの
• 延命の間にやる6つのこと
• 延命をやめて次に進む合図

そもそも直すか作り直すかの判断の基準は、「古いシステムは直すか、作り直すか」で書きました。延命と刷新の費用の比べ方は、「延命と刷新を、5年の費用で比べる」にまとめています。この記事は、その判断で「当面は延命」と決めた後の進め方に絞ります。

レガシーシステムの一般的な見分け方や、改修の範囲の考え方は、SucSak の「レガシーシステムの改修はどこまで？見積もりの読み方も解説」や「レガシーシステムの人材不足はどうする？退職前に決めること」にもまとまっています。

延命は「何もしない」ことではない

まず、言葉を整理します。この記事でいう延命は、次の3つがそろった状態です。

1. いつまで使うかの期限が決まっている
2. その期限まで安全に使うための手当てをしている
3. 期限までに次に移る準備を進めている

どれか一つでも欠けると、延命ではなく先送りになります。

経済産業省が2025年5月にまとめた「レガシーシステムモダン化委員会 総括レポート」は、保守が切れる部品への対応や、システムの移行を先送りしてきた結果、各所で問題が続いていると指摘しています。同じレポートには、技術の変化に付いていかないと、保守の期限が「意図せずに」やってくる、とも書かれています。

印象的なのは、モダン化（古いシステムを今の形に移すこと）を決めたきっかけの調査です。上位に並ぶのは、保守の要員が離れる、保守料が上がる、障害が続く、といった、外から迫られた「受け身」の理由でした。自分たちの計画で決めたのではなく、追い込まれてから決めた会社が多い、ということです。追い込まれてから決めると、期間も予算も選べる手も限られます。

延命の目的は、この「追い込まれる」状態を避けることです。期限を自分たちで決め、その日に向けて準備を進めておけば、次のシステムを選ぶときに、時間をかけて比べられます。

同じレポートは、古い技術で作られていても、運用と保守の体制が整い、仕様が明らかで、改良できるなら、レガシーシステムとは言えない、とも書いています。延命の間の手当ては、今のシステムをこの状態に近づける作業でもあります。

延命の期限は、一番早く切れる部品で決まる

延命の期限を決めるときに、最初に見るのは、システムを動かしている部品のサポートの期限です。

業務システムは、一つの製品でできているわけではありません。サーバーの OS、プログラムの言語、データベース、フレームワーク、ミドルウェア、そして機器。それぞれに、作った会社や団体が決めたサポートの期限があります。期限が過ぎると、脆弱性が見つかっても修正が出なくなります。

IPA は、Windows 10 のサポート終了についての注意喚起の中で、サポートが終わると新しい脆弱性が見つかっても修正が行われないこと、そして OS の上で動くアプリケーションについても更新の計画が必要なことを書いています（IPA「Windows 10 のサポート終了に伴う注意喚起」）。

部品が多いほど、どれか一つが先に切れます。延命の期限の上限は、一番早く切れる部品の日です。

たとえば、2026年11月11日時点で、業務システムによく使われる部品の期限は次のとおりです。

すでに切れているものも少なくありません。PHP 7.4 以前、MySQL 8.0（Oracle の延長サポートは2026年4月まで。Oracle の Lifetime Support Policy）、CentOS 7（2024年6月30日）、Office と Access の 2016・2019（2025年10月14日）、SQL Server 2016（2026年7月14日）などです。

PHP 8.2 を使っている場合の具体的な進め方は、「PHP 8.2 のサポート終了までにやること」で書きました。

部品の一覧の作り方

部品の一覧は、次の5つの列があれば作れます。

版が分からない部品があれば、それ自体が最初の課題です。保守会社に頼めば、サーバーの中を見て一覧にしてもらえることがほとんどです。IPA の「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026年3月）も、IT の資産を管理して、サポートが切れたものを洗い出すことを求めています。

この記事の「刷新か延命かの判断シート」には、この一覧の表が入っています。部品ごとにサポートが終わる日を入れると、残りの月数と、システムごとに一番早く切れる日が自動で出ます。

延長サポートで延ばせるもの、延ばせないもの

部品によっては、お金を払ってサポートを延ばせるものがあります。

代表的なのが、Microsoft の延長セキュリティ更新（ESU）です。延長サポートが終わった後も、重要なセキュリティの更新を、最長3年受け取れる有償の仕組みです。Windows 10 の法人向けや、SQL Server、Windows Server に用意されています。Windows Server 2016 についても、2026年2月に ESU の提供が発表されました（Microsoft の発表）。

ただし、Microsoft 自身が ESU を「最後の手段」であり「一時的な橋渡し」だと説明しています（ESU のよくある質問）。延長されるのは重要なセキュリティの更新だけで、技術的な問い合わせの窓口は含まれません。途中から加入すると、それより前の期間の分もまとめて払う決まりです。延長は最長3年で、その先はありません。

Oracle のデータベースや Java にも、追加の費用を払って受けられる延長のサポートがあります。Red Hat Enterprise Linux 8 は、通常の保守が2029年5月31日まで、その後の延長の契約で2033年5月31日まで延ばせます（Red Hat）。

反対に、延ばせないものもあります。PHP、PostgreSQL、Node.js、Laravel のようなオープンソースの部品は、公式の期限の後に延長の窓口がありません。外部の会社が独自に修正を出すサービスはありますが、公式のものではないので、使うなら中身と期間を確かめる必要があります。

延長サポートは、延命の期限を後ろにずらす手段です。期限が延びたぶん、次に移る準備の時間ができます。その時間を準備に使わなければ、延長の費用を払って、同じ問題を数年後に持ち越すだけになります。

直せる人がいなくなる時期も、期限になる

延命の期限を決めるもう一つの軸は、人です。

部品のサポートが残っていても、今のシステムを直せる人がいなくなれば、延命は続けられません。不具合が出ても直せない、法改正に合わせた変更ができない、という状態になるからです。

経済産業省の総括レポートは、運用と保守が特定の人に頼った状態になり、障害が起きても応急の手当てしかできなくなる危うさを書いています。前に触れたとおり、モダン化を決めたきっかけの上位にも、保守の要員が離れることが挙がっています。

次のことを確かめておきます。

• 今のシステムを直せる人は、社内と保守会社を合わせて何人いるか
• その人が、退職や異動、担当替えで離れる予定はあるか
• 保守会社との契約は、いつまで続けられるか。値上げや、保守の終了を告げられていないか

直せる人が1人しかいない場合は、その人がいなくなる時期を、延命の期限の候補にします。そして、その前に2人目を育てるか、保守を引き受けてくれる別の会社を探します。保守会社の変え方は、「開発会社を途中で変えるとき」にまとめています。

延命の期限は、部品で一番早く切れる日と、直せる人がいなくなる時期の、早いほうです。この日を社内で共有し、「この日までに次の形を決めて、移り終える」という約束にします。

延命の間にやる6つのこと

期限を決めたら、その日まで安全に使い、次に移れるようにするための作業を進めます。順番の目安とともに、6つにまとめます。

1. 外からつながる口を減らす

最初に手を付けたいのが、外からシステムにつながる口を減らすことです。社外から直接使えるようにしている画面、インターネットに開いている管理画面、使っていない古い機能のページ。サポートが切れた部品を使っている場合は特に、外から届く場所を減らすことが、攻撃を受ける危険を小さくします。

社内だけで使う業務なら、社外から使えないようにする。社外から使う必要がある場合は、VPN の中だけにする、つなげる場所を限る、といった方法があります。IPA の中小企業向けのガイドラインも、サポートが切れた OS やソフトウェアは利用をやめるか更新することを求めています。すぐに更新できないなら、少なくとも外から届かないようにしておきます。

2. バックアップから戻せるかを確かめる

バックアップを取っているかではなく、バックアップから本当に戻せるかを確かめます。

IPA の同じガイドラインには、こんな事例が載っています。VPN の機器の入れ替えを半年待っている間に、ランサムウェアに感染した会社です。年2回、バックアップから戻す訓練をしていた基幹システムは5日で動き始めました。一方、ほかの社内システムは戻るまでに41日かかり、ファイルの2割強を失いました。費用は約2.5億円以上だったと書かれています。

同じ会社の中で、訓練していたシステムとしていなかったシステムの差が、5日と41日です。延命しているシステムほど、障害や事故が起きたときに直せる人が限られます。戻す手順を書き、実際に戻してみることを、少なくとも年に1回は行います。

3. データを取り出せるようにする

次のシステムに移るとき、一番時間がかかるのがデータの移行です。延命の間に、今のシステムからデータを取り出せるようにしておきます。

• どのデータが、どの表（テーブル）に入っているか
• 画面や帳票の出力ではなく、元のデータをまとめて取り出す方法があるか
• 取り出したデータの項目の意味が分かるか

古いシステムでは、データの持ち方が今の業務と合わなくなっていることがあります。同じお客様が何件も登録されている、使わなくなった項目に別の意味のデータが入っている、といったことです。移行の直前に気づくと、移行の計画そのものが延びます。延命の間に一度取り出してみて、中身を確かめておきます。

4. 今の動きを書き起こす

経済産業省の総括レポートは、IT の資産を見える化すると、保守の期限が近い部品が分かること、そして仕様を復元して属人性をなくすことを、モダン化の進め方として挙げています。IPA の「レガシーシステム刷新ハンドブック」（2021年11月改訂）も、刷新の最初の作業として、システム全体の構成図を作り、詳しい人を特定することを示しています。同じハンドブックは、設計を後から組み立て直せるだけの記録が残っていないことが多い、とも書いています。

延命の間にやりたいのは、次の3つを文書にすることです。

• システムの構成：どのサーバーで、何が動き、どこにつながっているか
• 業務の流れとシステムの役割：誰が、どの画面で、何をしているか。夜間の処理や月末の処理も含める
• 例外と決まり：「この取引先だけ値引きの計算が違う」のような、プログラムの中にだけある決まり

最近は、AI を使ってプログラムを読み、仕様の下書きを作る方法も使えるようになりました。ただ、プログラムに書いていない業務の決まりは、使っている人に聞かないと分かりません。直せる人と、業務を知っている人がいるうちに進めます。

5. 上げられる版は上げる

延命は、何も変えないことではありません。部品のうち、業務の動きを変えずに版を上げられるものは、延命の間に上げておきます。PHP の版を上げる、OS をサポートの残る版に移す、といった作業です。

版を上げると、延命の期限そのものを後ろにずらせます。また、版を上げる作業を通じて、どこが直しにくいかが見えてきます。版上げが小さな改修で済むなら、延命を続ける理由になります。反対に、古い書き方が多くて大きな改修になると分かれば、書き換えや作り直しを考える材料になります。

6. 次の手の調査と、予算の準備を進める

最後に、期限までに次の形を決めるための準備です。

• 次の候補（版上げ・基盤の移行・書き換え・製品への置き換え・作り直し）を並べ、どれが合うかを調べる
• 延命を続けた場合と、刷新した場合の費用を、5年の合計で比べる
• 予算の時期から逆算して、いつまでに何を決めるかを決める

経済産業省の総括レポートは、中堅・中小企業については、パッケージや SaaS を原則にすべきだと書いています。会計や勤怠のように、どの会社でもやり方がほぼ同じ業務は、その考え方が合います。一方で、取引先との独自のやり取りや、自社の強みになっている業務まで製品に合わせると、強みが薄れることもあります。業務ごとに、製品に任せる部分と作る部分を分けて考えます。この分け方は、「古いシステムは直すか、作り直すか」の5つ目の基準で詳しく書きました。

費用の比べ方は「延命と刷新を、5年の費用で比べる」にまとめています。

延命の間の費用を、年額で出しておく

延命にも費用がかかります。社内で延命を決めるときは、年額の見込みを一緒に出しておきます。

見落とされやすいのが、手作業と二重入力の人件費です。今のシステムが業務に合わなくなっていると、Excel への転記や、紙での確認が増えています。これは保守費の請求書には出てこない、延命の費用です。

JUAS の「企業IT動向調査報告書2026」によると、回答企業の IT 予算のうち、今の業務を維持するための費用が75.9%、新しい施策の費用が24.1%でした。この割合は数年変わっていません。調査の対象は東証上場企業などの大企業が中心で、中小企業の数字ではありませんが、今のシステムを維持する費用が、新しいことに使えるお金を圧迫しているのは、会社の大きさを問わない話です。

延命をやめて、次に進む合図

延命の期限は、状況が変われば前倒しします。次のどれかが起きたら、延命を続けるか、次の手に進むかを決め直す時期です。

• 部品のサポートの期限が、1年を切った
• 直せる人が1人になった、または退職の予定が分かった
• 同じような改修の費用や待ち時間が、前の年より大きく増えた
• 保守会社から、値上げや保守の終了を告げられた
• 業務を変えたい（取引先と Web でやり取りしたい、など）のに、今のシステムでは対応できない
• 障害が続き、戻すのに時間がかかるようになった

合図を前もって決めておくと、社内で「もう少し様子を見よう」と先送りにしにくくなります。延命を決めた日に、この合図も一緒に書き残しておきます。

刷新か延命かの判断シートの使い方

この記事の内容は、Excel の「刷新か延命かの判断シート」で、そのまま進められます。

• 部品の期限：部品ごとにサポートが終わる日を入れると、残りの月数と、システムごとに一番早く切れる日が出ます
• 刷新か延命かの判断：システムごとに、サポートの残り・直せる人・仕様の資料・改修の費用・業務を変えたいか・標準に合わせられる業務・止まったときの影響を選ぶと、続けにくさと、向いている方向、急ぐかどうかが出ます
• 5年の費用：延命と刷新の費用を5年の合計で比べます

架空の卸売会社の3つのシステムの記入例つきです。ブラウザで1つのシステムを試すなら、ツール「刷新か延命かの判断」も使えます。入力した内容はどこにも送りません。

刷新か延命かの判断シートの Excel をダウンロードする

登録は要りません。部品の期限の確かめ方から、延命の計画、刷新の見積もりで確かめる項目、社内での決め方までを順番にまとめた PDF「古いシステムの刷新・延命 判断ガイド」も用意しています。

クリーヴァに相談するとき

クリーヴァは、別の開発会社が作ったサービスを引き継いで、開発と保守を続けています。そのときも、最初にしたのは新しい機能づくりではなく、今の作りを把握し、次の計画を立てることでした（「資料の少ないシステムを引き継ぐとき」で書いています）。延命を決めたシステムでも同じで、部品の一覧と、戻せるかの確認から始め、延命の期限とその間にやることを一緒に決めたうえで、版上げや、次のシステムへの移り方をご提案します。

「今のシステムを、いつまで使えるのか分からない」という段階からご相談いただけます。部品と版の一覧がなくても構いません。

おわりに

延命は、作り直さないと決めることではなく、作り直すまでの時間を自分たちで決めることです。期限は、一番早く切れる部品の日と、直せる人がいなくなる時期の早いほう。その日まで、外からの口を減らし、戻せるかを確かめ、データと仕様を手元に残しておけば、次のシステムを選ぶときに、追い込まれずに比べられます。

出典（2026年11月11日に確認）

• 経済産業省「レガシーシステムモダン化委員会 総括レポート」（2025年5月28日）
• IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026年3月27日）
• IPA「Windows 10 のサポート終了に伴う注意喚起」（2024年10月15日公開、2026年6月26日更新）
• IPA「レガシーシステム刷新ハンドブック」（2021年11月16日改訂）
• JUAS「企業IT動向調査報告書2026」（調査は2025年9〜10月）
• Microsoft「延長セキュリティ更新プログラムのよくある質問」、各製品のライフサイクルのページ
• PHP「Supported Versions」、PostgreSQL「Versioning Policy」、Node.js「Release schedule」、Laravel「Release Notes」、Oracle「Lifetime Support Policy」、Red Hat「Life Cycle and Updates Policy」