サーバーのOSサポート終了を過ぎたらどうなるか｜実際に起きることと、現実的な3つの選択肢

サポート終了とは、何が終わるのか

サポート終了（EOL：End of Life／End of Support）を過ぎても、サーバーは止まりません。 翌日も、その1年後も、たいていは問題なく動き続けます。

終わるのは、メーカーからの修正プログラムの提供です。 OSに新しい脆弱性が見つかっても、もう直されません。

つまりサポート終了日とは、「動かなくなる日」ではなく、 「それ以降に見つかる欠陥が、永久に直らなくなる日」です。 「問題なく動いているから大丈夫」という判断が通用しないのは、ここに理由があります。

もうひとつ注意したいのが、サポートが2段階に分かれている製品です。 Windows Server には「メインストリームサポート」と「延長サポート」があり、 セキュリティ更新が打ち切られるのは延長サポートの終了日のほうです。 逆に「まだサポート期間内です」と聞いていても、実際にはメインストリームが終わっているだけ、という場合もあります。 期限を確認するときは、どちらの日付なのかまで見てください。

サポート終了後に、実際に起きること

1. 脆弱性が、見つかっても直らない

サポート期間中であれば、脆弱性が公表されると、前後して修正プログラムが提供されます。 終了後は、公表だけがされて、修正は出ません。 危険な箇所が時間とともに増えていく一方で、減ることがない——これがEOLの本質的な問題です。 1年放置すれば1年分、3年放置すれば3年分、未修正の欠陥が積み上がります。

2. 攻撃する側にとって、狙いやすい相手になる

修正プログラムの内容からは、どこがどう危なかったのかを読み取ることができます。 サポートが継続しているバージョン向けに出た修正を手がかりに、 同じ弱点を抱えたまま放置されている古いバージョンを探す、という調べ方が成立します。 サポートが切れたOSは、攻撃する側から見ると「対策されていないことが分かっている相手」です。

インターネットに公開されているサーバーは、常時、自動的にスキャンされています。 相手が機械である以上、「うちのような会社は狙われない」という前提は成り立ちません。 規模ではなく、空いているかどうかで選ばれます。

3. 周辺のソフトウェアが、先に動かなくなる

OSのサポートが切れると、その上で動くものが順に対応をやめていきます。

• セキュリティソフトが、そのOS向けの提供を終了する
• ミドルウェアやライブラリの新しいバージョンが、インストールできなくなる
• 業務パッケージやクラウドサービスが、動作保証の対象外にする
• 暗号方式の世代交代により、証明書の更新や外部サービスとの通信が通らなくなる

そのため、セキュリティの問題より先に「業務上の不都合」として表面化することがあります。 この段階で慌てて対応すると、選べる手が少ないぶん、費用も時間も余計にかかります。

4. 取引先・監査・保険で問われる

取引先から提出を求められるセキュリティチェックシートに、 OSやミドルウェアのサポート状況を記入する欄が含まれることが増えています。 サイバー保険の加入・更新時にも、同様の確認があります。 ここで「サポート終了済み」と書くことになれば、取引条件や保険料に影響する可能性があります。

技術の問題として後回しにしていたものが、ある日、取引の問題として戻ってくる。 EOL対応を「いつかやること」から「期限のあること」に変えておく価値は、ここにもあります。

主なOS・ミドルウェアのサポート期限

2026年11月12日時点の情報です。最新の期限は、各ベンダーの公式情報をご確認ください。

Windows Server（延長サポートの終了日）

Windows Server 2016 の終了は、2027年1月12日です。 この記事を公開している2026年11月の時点で、残り約2か月しかありません。 移行には、動作確認・データ移行・切り替え当日の段取りまで含めて数か月かかることが珍しくないため、 いま着手していない場合、期限内の完了は難しい可能性があります。 その場合は、後述する延長サポートや緩和策まで含めて計画を立ててください。

参考：クライアント版の Windows 10 も2025年10月14日に終了しています。 Windows 10 のパソコンをファイルサーバーや共有機として使い続けている場合、 サーバーの棚卸しから漏れやすいので、あわせてご確認ください。

主なLinuxディストリビューション

注意が必要なのは CentOS 7 です。CentOS には「7の次」にあたる同系列の後継がないため、 バージョンを上げれば済む、という移行ができません。 AlmaLinux・Rocky Linux・Red Hat Enterprise Linux などへ、別のディストリビューションとして移ることになります。 多くの場合は中身の互換性が高く、見た目ほど大がかりにはなりませんが、 「アップデートで済む」前提で予算を組んでいると、計画の立て直しが必要になります。

見落とされやすい、OS以外のもの

期限があるのはOSだけではありません。とくにPHPはサポート期間が短く、 Webサイトや業務システムで広く使われている割に、意識されにくい部分です。

このほか、次のものにも同じようにサポート期限があります。

• VPN機器・ルーター・ファイアウォール・NAS のファームウェア
• データベース（MySQL、PostgreSQL、SQL Server など）
• 仮想化基盤（VMware、Hyper-V など）
• WordPress のプラグインやテーマ（更新が止まっているもの）

VPN機器は、終了後も「社外から社内につながる入口」として動き続けるため、 放置された場合の影響がとくに大きい部類です。 当社では、VPNなど通信機器の脆弱性調査と対策を10万円〜で承っています。

自社のサーバーが今どの状態か、確認する

対策を考える前に、まず現状を把握します。 次のコマンドは読み取りだけなので、稼働中のサーバーで実行しても業務に影響はありません。

Linuxサーバーの場合

# ディストリビューションとバージョン
cat /etc/os-release

# カーネルのバージョン
uname -r

# よく使うミドルウェアのバージョン
php -v
mysql --version

Windowsサーバーの場合

# 「ファイル名を指定して実行」から
winver

# PowerShell で確認する場合
(Get-CimInstance Win32_OperatingSystem).Caption

サーバーがどこにあるか分からない場合

社内にあるのか、どこかのデータセンターにあるのか、誰が管理しているのかが分からない。 ——これも珍しいことではありません。その場合は、保守や管理を委託している会社に、次の3点を確認してください。

• 現在のOSとそのバージョン、そしてサポート終了日
• 保守契約に、OSのアップデートが含まれているかどうか
• 終了日までにどう対応する予定か。その費用は誰の負担か

3つ目は、契約書に明記されていないことが多い部分です。 「保守契約を結んでいるから大丈夫」と考えていたら、OSの更新は範囲外だった、という行き違いが起きやすいところなので、 文面で残しておくことをおすすめします。

現実的な3つの選択肢

選択肢1：OSをアップデートする

同じ系列の新しいバージョンへ上げる方法です。構成を大きく変えずに済むため、費用も期間も最小で収まります。

• 向いているケース：Windows Server 2016 → 2022／2025、Ubuntu 22.04 → 24.04 など、後継バージョンがある場合
• 注意点：上で動いている業務システムが、新しいOSで問題なく動くかの確認が必要です。とくに古い言語・古いライブラリに依存しているシステムは、ここで引っかかることがあります

当社では、サーバーのOSアップデートを3万円／台〜で承っています。

選択肢2：新しいサーバーを立てて移行する

現行機はそのままに、新しいサーバーを別に用意し、動作確認をしてから切り替える方法です。 元の環境が残るため、問題が起きたときに戻せるのが利点です。

• 向いているケース：CentOS 7 のように同系列の移行先がない場合。ハードウェア自体も古い場合。この機会にクラウドへ移す場合
• 注意点：費用は選択肢1より上がります。一方で、サーバーの老朽化という別の問題を同時に片付けられるため、総額では有利になることもあります

仕様書がなく、中身が分からないシステムが乗っている場合でも、解析してドキュメント化したうえで移行する進め方ができます。

選択肢3：有償の延長サポートで、時間を買う

メーカーや第三者が提供する延長サポート（Windows の ESU、Red Hat の ELS、Ubuntu Pro など）を利用し、 セキュリティ更新だけを受け取り続ける方法です。

• 向いているケース：期限までに移行が間に合わないことが確定している場合。移行先の検討にもう少し時間が必要な場合
• 注意点：これは解決ではなく猶予です。年数を重ねるほど割高になる設計が一般的で、いつかは必ず終わります。「延長している間に、いつまでに何をするか」を決めてから使ってください

いずれの場合も、移行の前後で脆弱性診断を行うと、残っている問題を把握したうえで切り替えられます。 費用の目安は脆弱性診断の費用相場にまとめています。

すぐには上げられない事情がある場合

「古い業務システムが、そのOSでしか動かない」。これは実際によくある状況で、 技術的な怠慢というより、事業上の制約です。 この場合でも、被害が起きる確率と、起きたときの大きさは下げられます。

• インターネットから直接届かないようにする。公開をやめる、あるいはVPNや固定IPからに限定する
• ネットワークを分ける。万一侵入されても、そこから他の端末やサーバーへ広がらないようにする
• どうしてもWeb公開が必要なら、WAFを前に置く。既知の攻撃パターンを手前で止める
• アカウントを棚卸しする。使われていない管理者アカウントを消し、多要素認証をかける
• ログを監視する。侵入を防げなくても、早く気づければ被害は小さくできる
• バックアップを別の場所に持ち、実際に戻せるか試す。同じサーバー上のバックアップは、ランサムウェアで一緒に暗号化されます

ただし、これらはすべて延命であって治療ではありません。 期限を決めずに緩和策だけを積み重ねると、数年後に、より悪い条件で同じ判断を迫られます。 「いつまでに、どう移行するか」を決めたうえでの時間稼ぎとして使ってください。

まとめ

• サポート終了は「動かなくなる日」ではなく「直らなくなる日」。動いていることは、安全の根拠になりません
• 直近では、PHP 8.2 が2026年12月31日、Windows Server 2016 が2027年1月12日、Ubuntu 22.04 LTS が2027年5月に終了します
• まず cat /etc/os-release や winver で現状を確認する。委託先には「OSの更新が保守契約の範囲か」を文面で確認する
• 選択肢はアップデート／新サーバーへの移行／有償の延長サポートの3つ。延長サポートは猶予を買うものであって、解決ではありません
• すぐに上げられない場合も、届く範囲を絞る・監視する・戻せるようにしておくことで、被害の大きさは変えられます

「自社のサーバーがどういう状態なのか分からない」「保守会社に聞いたが、要領を得ない」という段階でも構いません。 現在の構成をお聞かせいただければ、期限がいつで、どこから手をつけるべきかをご回答します。