Windows Server のサポート終了（EOL）対応の進め方

サーバー室の隅で、来客用の紙コップの箱に埋もれるようにして稼働している1台のタワー型サーバー。電源ランプだけが緑色に光り続け、誰もそのOSのバージョンを正確に言えない。総務の担当者に聞いても「昔からあるやつです。触ると壊れそうで怖いので触っていません」という答えが返ってくる。こうした光景は、決して珍しいものではありません。

そのサーバーが動かしているのが Windows Server で、しかもすでにEOL（サポート終了）を迎えている、あるいは数年以内に迎えることが分かっている場合、多くの担当者はこう考えます。「動いているのだから、今すぐ何かする必要はないだろう」。この判断は半分正しく、半分間違っています。EOLを迎えた瞬間にサーバーが停止するわけではありません。しかし、EOL後のサーバーは「壊れても誰も直してくれない」「新しい攻撃手法が見つかっても二度と修正されない」状態のまま、社内の重要な業務を支え続けることになります。

この記事は、古いWindows Serverが動き続けている中小企業で、EOL対応の必要性はうっすら分かっているものの、何から着手すればよいか分からない担当者に向けて書きました。情シスの専門教育を受けていない、総務や経理と兼任でシステム管理を担っている方を想定しています。専門用語は都度言い換えながら、判断の順番と進め方を具体的に整理します。

この記事で分かること

Windows ServerのEOL(サポート終了)がなぜ危険なのか、自社のサーバーがいつEOLを迎えるのかの調べ方、EOL対応として現実的に取りうる選択肢、そして実際に対応を進める際の手順とスケジュール感を解説します。結論を先に言うと、EOL対応で最初にやるべきことは次の3つです。

• 現状把握: 自社のWindows Serverのバージョンと、そのEOL日を正確に特定する
• リスクの言語化: 放置した場合に何が起きうるかを、経営層に説明できる形に整理する
• 選択肢の比較: 延命(ESU等)・移行・廃止のどれを取るか、コストと期限から逆算して決める

「今すぐ全部入れ替える」ことがゴールではありません。会社の予算とスケジュールに合わせて、現実的な着地点を見つけることがこの記事のゴールです。

そもそもEOL(サポート終了)とは何か

結論から言うと、EOLとは「そのソフトウェアに対するセキュリティ更新プログラムの提供が、メーカーによって打ち切られること」です。Windows Serverでいえば、Microsoftがそのバージョンに対する修正プログラムの配布を止める期日を指します。

EOLという言葉は、日本語では「サポート終了」や「延長サポート終了」と訳されます。ここで誤解しやすいのは、「EOLを迎えたら、そのサーバーが動かなくなる」というイメージです。実際にはそうではありません。EOLを過ぎても、OSは何事もなかったかのように起動し続け、業務アプリケーションも通常どおり動きます。

問題は、その裏側で起きていることです。

Windows Server 2012 R2の延長サポートは2023年10月10日に終了しました。それ以降、Windows Server 2012/2012 R2に新たに発見された脆弱性は、拡張セキュリティ更新プログラム(ESU)を別途契約しない限り、二度と修正されません。

——Microsoft Learn「拡張セキュリティ更新プログラムに関するFAQ」より

つまりEOL後のサーバーは、「新しい鍵をかけられなくなった建物」のような状態になります。今ある鍵(既存の修正済みの脆弱性)はそのまま機能しますが、新しく見つかった穴(未修正の脆弱性)は永久に塞がれません。しかも、攻撃者はEOLを迎えた製品を積極的に狙います。理由は単純で、EOL後のシステムは「攻撃しても報告される心配が少なく、成功率が高い」からです。

Windows Serverの各バージョンはいつEOLを迎えるのか

結論から言うと、EOL日はバージョンごとに異なり、正確な日付はMicrosoft公式のライフサイクルページで確認する必要があります。「だいたいこれくらい」という感覚で判断すると、数ヶ月単位でずれることがあります。

2026年8月時点でMicrosoft Learnのライフサイクル情報ページに掲載されている、主要バージョンの延長サポート終了日(=事実上のEOL日)は次のとおりです。

自社のサーバーがどのバージョンかを確認するには、サーバーにログインし、システム情報(「winver」コマンドや「システムのプロパティ」画面)を見れば表示されます。分からない場合は、保守を委託しているベンダーに問い合わせるか、社内のシステム管理台帳(もしあれば)を確認してください。台帳がない場合は、社内で稼働しているシステムを一覧化する台帳を作るところから始める必要があります(詳しくは後述の「棚卸し」の項目で扱います)。特にWindows Server 2016はEOLまで残りわずかで、Windows Server 2016のサポート期限とESUの費用・移行判断でも移行判断の考え方が扱われています。

Windows Server 2012 R2の例で具体的に見てみます。Microsoft Learnのライフサイクル情報ページには、次のようなサポート日程が明記されています。

つまりWindows Server 2012 R2は、すでに延長サポートそのものは終了しており、現時点でセキュリティを保つには有償のESU契約が必須の状態です。しかもそのESUも、Year3が終わる2026年10月13日以降は購入手段自体がなくなります。「まだESUで延命できるから大丈夫」と考えている場合も、その延命期間にはっきりとした期限があることを押さえておく必要があります。

• 台帳がなく、そもそも何が動いているか分からない場合は、まず『前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること』の「可視化」の手順を先に行うことをおすすめします。

なお、上記の表の日付は「延長サポート終了日」であり、これより前に「メインストリームサポート終了日」という区切りもあります。メインストリームサポート終了後は新機能の追加が止まりますが、セキュリティ更新は延長サポート終了日まで継続します。実務上は、延長サポート終了日=EOL日として押さえておけば十分です。

なぜ「動いているから大丈夫」ではないのか

結論から言うと、EOL後のサーバーは「今日は大丈夫」でも「来月は大丈夫」とは限らない、確率的なリスクを抱え続ける状態になります。

EOL後に起きるリスクは、主に3種類に分けられます。

1. 未修正の脆弱性を突かれる攻撃: OSやミドルウェアに新しい脆弱性が発見されても、EOL後のバージョンには修正プログラムが提供されません。ランサムウェアなどの攻撃者は、こうした「二度と直らない穴」を狙う専用のツールを使い回します。
2. 周辺ソフトウェアのサポート切れの連鎖: セキュリティ対策ソフト、バックアップソフト、業務アプリケーションのベンダーも、古いOSへの対応を順次打ち切っていきます。ある日突然「このOSではサポート対象外です」と言われ、他の問題が起きても保守を受けられなくなることがあります。
3. ハードウェア故障時に代替機が用意できない: サーバー本体も経年劣化します。故障した際に同じ世代のハードウェアがすでに製造中止になっており、新しいハードウェアでは古いOSが正常に動作しない、というケースも珍しくありません。

これらのリスクが厄介なのは、「いつ発生するか分からない」という点です。1年間何も起きないこともあれば、EOLを迎えた直後に大きな脆弱性が発見されることもあります。IPA(情報処理推進機構)も毎年「情報セキュリティ10大脅威」でサポート切れ製品の利用を注意喚起の対象としています。「うちは今まで何も起きていないから大丈夫」という経験則は、次の1年を保証してくれません。

経営層への説明で使いやすい例え: 「車検が切れた車を、事故を起こさず運転し続けられるかもしれません。しかし事故が起きたときに保険が使えず、全額自己負担になります。EOL後のサーバーも同じで、"壊れる確率"自体が上がるわけではなく、"壊れたときに詰む"状態になるということです」

放置した場合、具体的に何が困るのか

結論から言うと、最も深刻な実害は「セキュリティインシデントが起きたときの被害の大きさ」と「取引先からの信用低下」の2つに集約されます。

セキュリティインシデントのリスク

EOL後のサーバーがランサムウェアなどに感染した場合、それが単一障害点（SPOF）になっていると、その1台の停止が全社の業務停止に直結します。受発注データ、顧客情報、会計データなどが暗号化されたり流出したりすれば、取引先への説明義務や、場合によっては個人情報保護法に基づく報告義務も発生します。

取引先からの信用低下

近年は、取引先の情報セキュリティ体制を確認したうえで取引を継続するかどうかを判断する企業が増えています。取引先からのセキュリティ調査票に「OSのサポート状況」を問う項目があり、そこで「EOL済みかつ対策なし」と回答せざるを得ない状況は、取引継続の判断材料としてマイナスに働く可能性があります。

保守ベンダーからの見放され

EOLを迎えたOSの上で動くアプリケーションについて、開発・保守を委託しているベンダーが「これ以上はサポートできません」と契約更新を拒否するケースもあります。この場合、トラブルが起きても自力で対応せざるを得なくなります。

いずれのリスクも「今すぐ確実に起きる」ものではありません。しかし、経営層に予算を確保してもらうためには、「起きるかもしれない」ではなく「起きたときの損失規模」を具体的に示すことが有効です。

EOL対応の3つの選択肢

結論から言うと、EOL対応には「延命」「移行」「廃止」の3つの選択肢しかありません。それぞれの特徴とコスト構造を理解したうえで、自社の状況に当てはめて選ぶ必要があります。

選択肢1: ESU(拡張セキュリティ更新プログラム)による延命

Windows Server 2012/2012 R2のように、EOL後もMicrosoftが有償で「拡張セキュリティ更新プログラム(ESU)」を提供している場合があります。ESUは最大3年間、緊急および重要度の高いセキュリティ更新のみを継続提供する仕組みです。

Microsoft Learnの公式FAQによると、ESUの位置づけは次のように説明されています。

「ESUプログラムは、サポートが終了した後に特定のレガシMicrosoft製品を実行する必要があるお客様向けの最後の有料オプションです。長期的なソリューションとしてではなく、サポートされている新しいプラットフォームに移行する際にセキュリティを維持するための暫定的な措置です」

——Microsoft Learn「製品ライフサイクルに関するFAQ – 拡張セキュリティ更新プログラム」より

つまりESUは「移行までの時間を金で買う」選択肢です。ESU自体は恒久対応ではなく、あくまで移行準備期間の一時しのぎとして設計されています。

ESUのライセンス費用は、オンプレミス環境の場合「Year1・Year2・Year3のいずれも、年間フルライセンス価格の100%相当」が目安とされており(SQL Server 2012のYear1のみ75%という例外あり)、コア数に応じて加算される仕組みです。正確な金額は自社の契約形態(ボリュームライセンスの種類、コア数、仮想/物理)によって変わるため、Microsoftパートナーや販売代理店への確認が必須です。この記事では「相場」を断定せず、確認が必要な項目として明示するにとどめます。

なお、Azure仮想マシン上で稼働させている場合は、ESUが無料で提供される特典があります。オンプレミスのサーバーをそのままAzureへ移行(リホスト)することで、ESU費用を抑えつつ延命する、という選択肢も存在します。

選択肢2: 新しいバージョンへの移行

最も根本的な解決策は、EOLを迎えていない新しいバージョンのWindows Server、あるいはクラウドサービスへ移行することです。移行には主に3つのパターンがあります。

• 同一環境内でのバージョンアップ: 既存のサーバー機に新しいOSを載せ替える、または新しいサーバー機を調達して移行する
• クラウドへのリフト&シフト: Azure等のクラウド仮想マシンへそのまま移行する。ハードウェアの故障リスクから解放される利点がある
• SaaS/クラウドサービスへの置き換え: そもそもサーバーを持たず、ファイルサーバーならクラウドストレージ、社内システムならSaaSに置き換えることでサーバー自体を廃止する

どのパターンを選ぶかは、そのサーバーで動いているアプリケーションが新しいOS上でも問題なく動作するか(互換性)、レガシーシステム化していないか、という点に大きく左右されます。古い業務システムがそのサーバーでしか動かないVBAマクロや専用ソフトに依存している場合、単純なOS入れ替えでは済まず、アプリケーション側の改修や再構築を伴う場合があります。この判断は、社内の情報だけでは難しいことが多く、保守ベンダーやシステム開発会社への相談が現実的です。

選択肢3: 廃止(そのサーバーの役目を終わらせる)

サーバーが担っている機能を精査した結果、「実はもう誰も使っていない」「他のシステムに機能が移っていて、このサーバーだけ止め忘れている」というケースも実務ではよくあります。この場合は、移行ではなく単純に廃止することが最も安全でコストもかからない選択肢になります。

廃止の判断をする際は、次の点を必ず確認してください。

• そのサーバー上のデータで、法定保存期間内のものが残っていないか(会計データ、契約書類等)
• 他部署や取引先が、気づかないうちにそのサーバーを参照していないか
• ドメインコントローラーなど、他のシステムの認証基盤になっていないか

廃止によって別の業務が止まってしまっては本末転倒です。廃止は「止めて数週間様子を見てから完全に電源を切る」など、段階を踏んで進めることをおすすめします。

3つの選択肢をどう比較すればよいか

結論から言うと、判断の軸は「残されている時間」と「予算」の2つの掛け算です。どちらも潤沢にあるケースは稀なので、現実的にはトレードオフになります。

現実の進め方としては、まず「廃止できるサーバーがないか」を最初に洗い出すことをおすすめします。廃止できれば、それだけで対応すべき台数が減り、残りのサーバーに集中できるからです。そのうえで、残ったサーバーについて「今年度中に移行を完了できるか」「間に合わなければESUで時間を稼ぐか」を検討する、という順番が効率的です。

実際の進め方:4ステップのロードマップ

結論から言うと、EOL対応は「棚卸し→リスク評価→計画策定→実行」という4ステップで進めます。焦って1台だけ対応して満足するのではなく、社内のサーバー全体を俯瞰したうえで優先順位をつけることが重要です。

ステップ1: 棚卸し(1〜2週間)

社内で稼働しているすべてのサーバーについて、OSのバージョンとEOL日を一覧化します。台数が少なければ手作業でも構いませんが、この機会にシステム管理台帳としてExcelやスプレッドシートにまとめておくと、今後のパッチマネジメントや更新計画にも流用できます。一度作った台帳は、EOL対応が終わったら捨てるのではなく、以後も更新し続ける社内の共有資産として運用することをおすすめします。

棚卸しで最低限記録しておきたい項目は次のとおりです。

• サーバー名・設置場所
• OSバージョンとEOL日
• 主な用途(ファイルサーバー、業務アプリのDB、認証基盤など)
• そのサーバーが止まった場合に影響を受ける部署・業務
• 保守を委託しているベンダーの有無と連絡先

ステップ2: リスク評価と優先順位づけ(数日)

棚卸しが終わったら、「EOL日が近いもの」と「止まったときの影響が大きいもの」の2軸で優先順位をつけます。すでにEOLを迎えていて、かつ全社の基幹業務に関わるサーバーが最優先です。逆に、EOLまでまだ数年あり、影響範囲も限定的なサーバーは後回しにしても構いません。

ステップ3: 計画策定と予算確保(1〜2ヶ月)

優先度の高いサーバーから、「延命」「移行」「廃止」のどれを取るかを決め、必要な予算とスケジュールを経営層に提示します。ここで重要なのは、リスクを煽るだけでなく、「いつまでに、いくらで、何をするか」を具体的に示すことです。予算の承認にはIT導入補助金のような外部の補助制度が使える場合もあるため、自治体や商工会議所の窓口で確認する価値があります。

ステップ4: 実行とテスト(規模による)

計画に沿って移行やESU契約を実行します。移行の場合は、本番環境をいきなり切り替えるのではなく、テスト環境や一部業務での先行運用を挟むことをおすすめします。特に古いシステムほど、想定していなかった依存関係(特定のドライバー、特定のバージョンのExcelマクロなど)が動作不良の原因になることがあるため、余裕を持ったテスト期間を確保してください。

対応を進める際によくある落とし穴

結論から言うと、EOL対応でつまずくパターンの多くは「技術的な難易度」よりも「進め方の順番」に原因があります。ここでは実務でよく見られる失敗例を紹介します。

落とし穴1: OSだけ入れ替えて、アプリが動かなくなる

サーバーのOSを新しいバージョンに入れ替えたところ、その上で動いていた古い業務アプリケーションが起動しなくなった、というケースは非常によくあります。特に、開発元がすでに存在しない、あるいはサポートを終了している業務アプリを使っている場合は要注意です。OSの移行計画を立てる前に、必ず「そのサーバー上で何が動いているか」をアプリケーション単位で洗い出し、それぞれの新OSへの対応状況を個別に確認してください。

落とし穴2: バックアップを取らずに移行作業に入る

当たり前のようでいて、実際の現場で最も多いトラブル原因です。移行作業中に予期しないエラーが発生し、元のサーバーのデータを壊してしまうと、目的だったはずの「安全のための対応」が「最大のインシデント」に変わってしまいます。移行やアップグレードの作業に着手する前には、必ず独立した場所(別のディスク、クラウドストレージ等)にバックアップを取得し、リストア手順まで確認しておくことが鉄則です。

落とし穴3: 「今のうちに全部一新しよう」と対象を広げすぎる

EOL対応をきっかけに、社内のシステム全体を刷新しようという機運が高まることがあります。志としては悪くありませんが、対象を広げすぎると、当初のゴールだったEOL対応そのものが期限に間に合わなくなるリスクがあります。EOL対応はまず「セキュリティ更新が止まる状態を解消する」ことを最優先のゴールとして固定し、それ以外の刷新は別プロジェクトとして切り分けることをおすすめします。

落とし穴4: 見積もりを1社だけに依頼して即決してしまう

移行作業を外部ベンダーに依頼する場合、時間がないからといって1社の見積もりだけで即決してしまうと、相場感が分からないまま契約してしまうリスクがあります。可能であれば複数社から見積もりを取り、提案内容の違い(移行範囲、テスト期間の有無、移行後のサポート体制)を比較したうえで判断してください。緊急度が高い場合でも、最低限「なぜその金額なのか」の内訳は確認すべきです。

落とし穴5: EOL日の直前に慌てて動き出す

延長サポート終了日の1〜2ヶ月前になってから初めて動き出すと、移行先の選定、見積もり取得、テスト、本番切り替えのすべてを圧縮したスケジュールで行うことになり、無理な突貫工事になりがちです。この記事の表にあるとおり、EOL日は数年前から公式に決まっています。理想を言えば、EOL日の1年前には棚卸しと計画策定を終えていることが望ましいペースです。

経営層への説明で使える伝え方

結論から言うと、経営層への説明では「専門用語を避け、金額と期限で語る」ことが最も伝わりやすい方法です。

情シス専任者がいない中小企業では、EOL対応の必要性を稟議に通すこと自体が最初のハードルになります。以下のような伝え方が有効です。

• 期限を明示する: 「あと◯年でセキュリティ更新が止まります」という具体的な日付を示す(この記事の表を参照)
• リスクを金額換算する: 「もし攻撃を受けて業務が止まった場合、1日あたりの損失は◯円規模になり得ます」と、自社の日商や取引規模から逆算する
• 他社事例を示す: IPAの「情報セキュリティ10大脅威」など、公的機関が発表している脅威動向を根拠として提示する
• 段階的な予算計画を示す: 「今年度は緊急度の高い1台だけ」「来年度に残りを計画的に」という分割案を提示し、一度に大きな予算を求めない

経営層が最も警戒するのは「よく分からないまま大きな金額を求められること」です。逆に言えば、判断材料を具体的に示せれば、予算確保の話は驚くほどスムーズに進むこともあります。

まとめ:今日からできる最初の一歩

古いWindows ServerのEOL対応は、一度に全部を解決しようとすると気が重くなるテーマです。しかし、やるべきことを分解すれば、今日からでも着手できます。

• まず、自社のサーバーのOSバージョンを確認し、この記事の表と照らし合わせてEOL日を特定する
• EOL日が近い、あるいはすでに過ぎているサーバーがあれば、そのサーバーが止まった場合の影響範囲を書き出す
• 「延命」「移行」「廃止」のどれが現実的かを仮決めし、概算の予算感を掴む
• 経営層への説明資料を、専門用語を避けて金額と期限ベースでまとめる

完璧な移行計画をいきなり作る必要はありません。まずは「自社にEOL済み・EOL間近のサーバーが何台あるか」を正確に把握することが、すべての対応の出発点になります。

次に読むべき記事

社内システムの全体像がまだ整理できていない、引き継ぎ資料がなく何が動いているか分からない、という段階の方は、先に『前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること』を読むことをおすすめします。EOL対応の前提となる「何が動いているかを可視化する」手順を、より実践的なステップで解説しています。

また、Windows Server単体だけでなく、Office LTSC 2021やWindows 10のESUなど複数の期限が同時に重なっている場合は、『2026年10月13日、3つのサポートが同時終了する。中小企業の対応優先順位』で、3製品を横断した優先順位の付け方を整理していますので、あわせて確認してください。