「古いサーバーやシステム、動いてはいるから」——そう言って更新を後回しにしている業務システムはありませんか。経理・受発注・顧客管理など、日々の業務を支えている基幹部分ほど、動いているうちは触りたくない気持ちはよく分かります。ですが2026年は、その「動いているから大丈夫」という前提が崩れる節目の年です。
古いOS・ミドルウェアのサポート終了が相次ぐタイミングで、脆弱性が見つかっても修正プログラムが提供されなくなります。攻撃者にとっては「入り口が塞がれない」状態が続くということでもあります。放置していいラインと、今すぐ手をつけるべきラインをどう見極めるか、中小企業の経営者・情シス担当向けに整理します。ただし、サポート切れのサインは自社のサーバーOSだけを見ていても見落とすことがあります。この点は後半で詳しく触れます。
先に、要点をまとめます。
- Windows Server 2012 R2は2026年10月・2016は2027年1月に、延長セキュリティ更新（ESU）も含めて完全にサポートが終了する。逆算すると、いま動いていても数ヶ月〜1年強で「修正プログラムが来ないサーバー」に変わる
- サポート終了=即攻撃されるわけではないが、新しい脆弱性が見つかっても直せない状態が積み上がる。過去の実例でも、サポート終了後に見つかった脆弱性は深刻度の高いものが多い
- 全システムを一斉に作り直す必要はない。棚卸し→リスク評価→優先順位付けの3手順で、限られた予算を「本当に危ないところ」から充てるのが現実的
※本記事は2026年7月時点の公開情報にもとづいています。サポート期限・脆弱性の状況は変化するため、対応の判断には必ずMicrosoft等の一次情報をご確認ください。
Windows Serverのサポート終了はいつ？何が起きるのか？
Windows Server 2012 R2は2026年10月13日に、2016は2027年1月12日に延長セキュリティ更新（ESU）を含めて完全にサポートが終了します。
Microsoftの公式ライフサイクル情報によると、Windows Server 2012 R2は2023年10月に通常の延長サポートを終えたあと、有償のESU（Extended Security Updates）で3年間だけ猶予が設けられていました。その最終年（Year 3）が2026年10月13日で終わります。ここを過ぎると、ESUを契約していても新しい修正プログラムはもう提供されません。Windows Server 2016は延長サポートの終了日自体が2027年1月12日で、そこから先はESUの契約有無にかかわらずセキュリティ更新が止まります。
サポートが終了すると起きることは、単純です。OSやミドルウェアに新しい脆弱性が発見されても、修正プログラム（パッチ）が配布されなくなります。ソフトウェアの脆弱性は毎月のように新しく見つかり続けるため、「サポート終了時点で安全だったから、しばらくは大丈夫」という考え方は成り立ちません。時間が経つほど、直せない穴が積み上がっていきます。
見落としがちなのが、サーバーOSだけでなく、その上で動くデータベースや業務アプリの土台も同じタイミングでサポートが切れているケースがあることです。SQL Serverなどのミドルウェアは独自のサポート期限を持っており、OSとバージョンの組み合わせによっては、すでにサポート対象外になっている場合もあります。自社のシステムがどのOS・ミドルウェアの上で動いているかを棚卸しする作業は、老朽化した基幹システムをいつ・どう替えるかという判断とも直結します。刷新そのものの進め方は老朽化した社内システムをいつ・どう刷新するか【2026年版】で手順ごとに解説しているので、あわせてご確認ください。
サポート切れのシステムを放置すると、実際どんなリスクがあるのか？
サポート切れ直後に必ず攻撃されるわけではありませんが、時間の経過とともに「直せない脆弱性」を悪用する攻撃の的になりやすくなります。
IPA（情報処理推進機構）が過去に公表した調査では、旧OSのサポート終了後に検出された脆弱性のうち、深刻度の高いものが多数を占めていたと報告されています。サポートが切れたシステムは「脆弱性が無くなる」わけではなく、「脆弱性が見つかっても直せない」状態に変わるだけです。攻撃者から見れば、パッチが提供されない古いシステムほど、時間をかけて攻略しやすい標的になります。
中小企業にとって特に厄介なのは、被害の発覚が遅れやすい点です。IPAが2026年に公開した中小企業向けのセキュリティ資料でも、OS・ソフトウェアの更新を怠っていたり、ウイルス対策ソフトが古いまま放置されていたりする内部の脆弱性が、多くの企業で積み重なっている実態が指摘されています。専任の情シス担当がいない会社ほど、システムが「動いているかどうか」だけで判断され、裏側のサポート期限やパッチ適用状況までは追えていないことが少なくありません。
万一インシデントが起きた場合の影響は、システムの復旧費用だけにとどまりません。顧客データの流出があれば通知・謝罪対応が発生し、取引先からの信頼低下、業務停止による機会損失、原因調査の専門費用まで積み重なります。サポート切れの放置は「いつか直せばいい保守の話」ではなく、経営リスクとして扱うべき性質のものです。
サポート切れシステムを放置した場合と対応した場合の分かれ道。放置すると脆弱性の蓄積・インシデントリスクの上昇・対応コストの後払い増加につながり、早期対応だと棚卸しからリスク評価、段階的な対策で被害を未然に防げる
対応の選択肢にはどんなものがある？費用感も含めて比較
サポート切れへの対応は「延命」「隔離」「移行」「作り直し」の4パターンに大別でき、システムの重要度によって選び方が変わります。
すべてのシステムを同じ方法で対応する必要はありません。それぞれの特徴とおおよその費用感を整理します。
| 対応方法 | 内容 | 向いているケース | 費用感の目安 |
|---|---|---|---|
| ESU（延長セキュリティ更新）の契約 | 有償でパッチ提供期間を延ばす一時しのぎ | すぐには作り直せないが、あと1〜2年で移行予定がある | サーバー1台あたり年間数万円〜。台数・エディションで変動 |
| ネットワークからの隔離 | インターネットや基幹LANから切り離し、限定的に使い続ける | 社外に公開しておらず、閉じた環境で完結する古いシステム | ネットワーク再設計費用。数十万円規模のことが多い |
| クラウド移行（リホスト中心） | 既存の仕組みを大きく変えずクラウド基盤に載せ替える | アプリ自体は使えるが、土台のOSだけが古い | 数百万円〜。アプリ改修が伴うと上振れ |
| フルスクラッチでの作り直し | 業務に合わなくなった仕組みごと再設計する | 業務フローとシステムの乖離が大きく、パッチ対応だけでは限界がある | 規模により数百万円〜数千万円 |
ESUや隔離は「時間を買う」対応であり、根本解決にはなりません。とはいえ、繁忙期をまたいで一気に作り直すのが現実的でない場合、まず延命策で猶予を作りつつ移行計画を立てるという順序は十分に合理的です。フルスクラッチでの作り直しを検討する場合の保守費用の考え方はシステム保守費用の相場は？【2026年版】で開発費の15〜20%という目安を解説しています。予算を確保する段階でご参照ください。
何から手をつければいい？優先順位のつけ方
限られた予算とリソースの中では、「棚卸し→リスク評価→優先順位付け」の3手順で、最も危ないシステムから対応するのが現実的です。
- 棚卸し：自社が使っているサーバー・PC・業務システムのOS・ミドルウェアのバージョンを一覧化する。仕様書が残っていない場合は、稼働中のサーバーに直接ログインしてバージョン情報を確認するところから始めます
- リスク評価：それぞれについて「いつサポートが切れるか」「インターネットに公開されているか」「個人情報・決済情報など重要なデータを扱っているか」を確認する。外部公開かつ重要データを扱うシステムほど優先度が高くなります
- 優先順位付け：評価結果をもとに、今年度中に対応する対象・来年度以降でよい対象・隔離で足りる対象に仕分ける
この3手順を自社だけで進めるのが難しい場合、外部の開発会社に現状調査から依頼する方法もあります。仕様書が無い、担当者が退職していて経緯が分からない、といった状態からの調査にも対応できるのが、システムの引き継ぎ・レスキューを専門にする支援です。老朽化したシステムをどう作り替えるかまで含めて相談したい場合は、システムリプレースの支援内容もご覧ください。
御社の場合、外部に公開しているシステムが1つでもあれば、そこが最優先の棚卸し対象になります。まずは「どこにどんなシステムがあるか」を洗い出すところから始めれば、優先順位は自然と見えてきます。
対応でよくある失敗例と、避け方
現場でよく見られる失敗パターンを3つ挙げます。
- 失敗例1: サポート終了日だけを見て、直前に一気に動こうとする。ベンダーへの発注が集中する時期は見積もり・着手までに時間がかかりやすく、期限直前の駆け込みは選択肢が狭まります。半年〜1年前から動き出すのが安全です
- 失敗例2: 「古いシステムを新しいサーバーにそのまま載せ替えれば終わり」と考えてしまう。OSだけ新しくしても、その上で動くアプリやライブラリが対応していなければ結局動かない、というケースは珍しくありません。アプリ側の依存関係も含めた棚卸しが必要です
- 失敗例3: 対応をIT担当者だけの問題にしてしまう。予算判断や業務停止のリスクは経営判断そのものです。情シス担当が問題意識を持っていても、経営層に「なぜ今やるべきか」が伝わっていないと、対応が先送りにされがちです
これらはいずれも、最初の棚卸しとスケジュールの前倒しでかなりの部分を防げます。
まとめ
この記事で持ち帰れることは次の2つです。
- 自社のシステムがいつサポート切れになるかを、日付で把握できるようになったこと
- 全部を一度に作り直すのではなく、外部公開・重要データの有無で優先順位をつけて対応すればよいと判断できるようになったこと
Windows Server 2012 R2は2026年10月、2016は2027年1月という期限は、すでに動き出している企業も多い一方で、まだ手つかずの企業も少なくありません。まずは自社のサーバー室や契約書を確認して、稼働中のOSのバージョンを1つメモしてみてください。そこから、対応の優先順位が見えてきます。
古いシステムの現状調査やサポート切れへの対応方針について相談したい場合は、お問い合わせからお気軽にご連絡ください。
よくある質問
Q. サポートが終了したサーバーは、すぐに使えなくなりますか？
いいえ、サポート終了後もシステム自体は動き続けます。ただし新しい脆弱性が見つかっても修正プログラムが提供されなくなるため、時間の経過とともにセキュリティリスクが高まっていきます。すぐに停止するわけではないが、放置してよい理由にもならない、というのが正確な理解です。
Q. ESU（延長セキュリティ更新）を契約すれば、ずっと使い続けられますか？
いいえ、ESUは無期限ではありません。Windows Server 2012 R2の場合、ESUは最大3年間で終了し、2026年10月13日以降は契約していても更新プログラムが提供されなくなります。ESUはあくまで移行までの時間を確保する一時的な措置と考えてください。
Q. うちは社内ネットワークだけで使っているので、対象外ではないですか？
社外に公開していないシステムは相対的にリスクは下がりますが、ゼロにはなりません。社内のPCがウイルスに感染し、そこから社内ネットワーク経由で古いサーバーが攻撃される、といった経路もあります。外部公開の有無はリスク評価の一項目であり、対応不要と判断する根拠にはなりません。
Q. サポート切れのシステムが複数ある場合、何を最優先にすべきですか？
インターネットに公開されているシステムと、個人情報・決済情報など重要なデータを扱っているシステムを最優先にしてください。この2つの条件に当てはまるシステムほど、攻撃者に狙われた場合の被害が大きくなります。
Q. クラウド移行とフルスクラッチでの作り直し、どちらを選ぶべきですか？
現在のアプリケーションが業務に合っている場合は、まずクラウド移行（リホスト）でOSの土台だけを更新する方法が費用を抑えやすい選択です。一方で業務フローとシステムの機能が大きく乖離している場合は、土台だけ変えても使いにくさが残るため、フルスクラッチでの作り直しを検討する価値があります。
運営・編集