結論:危ないのは「SQL Serverを使っている自覚がない」会社。アプリ改修が絡むため、気づいた時には間に合わない
Microsoftのデータベース SQL Server 2016の延長サポートが2026年7月14日に終了する。残り約1か月だ。Microsoft Learnのライフサイクル情報によれば、メインストリームサポートは2021年7月13日に既に終わっており、7月14日以降は新たなセキュリティ更新が提供されなくなる(後述のESUを除く)。対象エディションはEnterprise/Standardに加え、ExpressやWeb、Developerも含む全エディション である。
このEOLが厄介なのは、影響を受ける企業の多くに「SQL Serverを使っている」自覚がないことだ。販売管理・会計・人事給与・生産管理のパッケージ製品は、同梱または前提DBとしてSQL Serverの上で動いている ものが多く、2016〜2020年頃に導入したパッケージなら2016世代のDBが現役で残っている可能性が高い。そしてDBの更改は単なる入れ替えでは済まない。パッケージ側の対応バージョン確認・アプリ改修・データ移行・業務テストが連鎖する ため、リードタイムは月単位になる。OSのEOLより「気づいてから間に合わせる」のが難しい典型だ。
しかも今年の夏はEOLが連発する。6月30日にはAmazon Linux 2のサポート終了が控え、7月14日にはSQL Server 2016と同日にSharePoint Server 2016/2019なども終わる。インフラとDBの期限が2週間差で並ぶこの夏は、自社のIT資産台帳を総点検する好機である。
押さえるべき1点:DBのEOL対応は「DB担当」の仕事ではなく「パッケージ資産」の仕事だ。問うべきは「SQL Server 2016はあるか」ではなく「うちの業務パッケージは何のDBの上で動いているか」である。
2026年の主要Microsoft製品サポート終了一覧
Microsoft Learnの「2026年のサポート終了」ページから、企業システムに関わりの深いものを抜粋する。
| 終了日 | 製品(固定ライフサイクル等) |
|---|---|
| 2026年1月13日 | Dynamics CRM 2016、Visual Studio 2022 17.10(LTSC) |
| 2026年4月14日 | Dynamics NAV 2016、Dynamics C5 2016 ほか |
| 2026年7月14日 | SQL Server 2016、SQL Server 2014(ESU 2年目終了)、SharePoint Server 2016/2019、Project Server 2016/2019、Dynamics GP 2016/2016 R2、Visual Studio 2022 17.12(LTSC) |
| 2026年10月13日 | Office LTSC 2021(Word/Excel/Outlook等)、Office 2021、Windows 10 2016 LTSB、Windows Server 2012/2012 R2(ESU 3年目終了)、Windows 11 24H2 Home/Pro、Windows Server 2022(メインストリーム終了・延長サポートへ移行) |
| 2026年11月10日 | .NET 8(LTS)、Windows 11 23H2 Enterprise/Education、PowerShell 7.4(LTS) |
SQL Server 2016単体のライフサイクルは次のとおりだ。
| 項目 | 日付 |
|---|---|
| リリース | 2016年6月1日 |
| メインストリームサポート終了 | 2021年7月13日 |
| 延長サポート終了 | 2026年7月14日 |
| ESU(拡張セキュリティ更新)1年目 | 2026年7月15日〜2027年7月13日 |
| ESU 2年目/3年目 | 〜2028年7月18日/〜2029年7月17日 |
なお、現在サポート対象なのは Service Pack 3適用済み の環境のみで(SP3のサポート終了日=延長サポート終了日)、対象エディションはDeveloper/Enterprise/Enterprise Core/Express/Standard/Webの全てである。
なぜ「基幹パッケージの裏のDB」は放置されるのか
第一に、導入時にDBを意識していない からだ。パッケージベンダーが構築一式を納品するケースでは、DBのバージョンは納品書の片隅にしか残らない。資産管理台帳に「販売管理システム」とは載っても「SQL Server 2016 Standard」とは載らない。
第二に、更改にアプリの都合が絡む からだ。DBだけ新しいバージョンに上げようとしても、パッケージ側が対応していなければ動かない。パッケージの対応バージョン確認→パッケージ自体のバージョンアップ(場合によっては後継製品への乗り換え)→DB更改→データ移行→業務テスト、という連鎖になり、ベンダーの作業枠の確保も含めると数か月単位の案件になる。サポート切れの古いパッケージ基盤が攻撃対象になり続ける構図はAdobe月例にみる「レガシー放置」の代償でも扱った。
第三に、「動いているから」の慣性 だ。DBは障害がなければ存在を忘れられる。しかしEOL後のDBは、新たな脆弱性が修正されないまま基幹データ(取引先・会計・個人情報)を抱え続けることになり、取引先からのセキュリティチェックや監査で指摘される対象になる。延命か更改かの判断を先送りするほど選択肢は減る。判断軸はレガシーシステムの延命 vs リプレース判断フローを参照してほしい。
更改はコストだけの話ではない。2016世代のDBに塩漬けされた販売・会計データは、BI・AI活用の足かせにもなっている。DB更改を「守りの義務」で終わらせず、データ基盤整備の起点にすれば投資の回収余地は広がる。
1か月でやる棚卸し:5つの手順
- 業務パッケージの一覧を作る。 販売管理・会計・人事給与・生産管理・ワークフローなど、部門導入を含めて全パッケージを列挙する。
- 各パッケージのDB種別とバージョンを確認する。 サーバ上で `SELECT @@VERSION` を実行するか、ベンダーに照会する。「SQL Server 2016」とともに、既にEOLの2014以前が残っていないかも見る。
- SP3適用状況を確認する。 2016でもSP3未適用なら既にサポート外であり、緊急度が一段上がる。
- パッケージベンダーに対応方針を書面で照会する。 「新しいSQL Serverへの対応バージョンはどれか」「バージョンアップ費用と納期」「7月14日までに完了しない場合の暫定策」を確認する。
- 間に合わない環境の経過措置を決める。 ESU(1年目:2026年7月15日〜2027年7月13日)の利用可否・条件をベンダー・Microsoftに確認しつつ、ネットワーク分離や接続元制限など露出を下げる暫定防御を併用する。
チェックの勘所:手順4の照会は口頭でなく書面で行うこと。ベンダーの回答(対応可否・費用・納期)は更改計画の根拠資料になり、万一の際に「確認していた」ことの証跡にもなる。
よくある質問(FAQ)
Q. 7月14日を過ぎるとSQL Server 2016は使えなくなるのか? A. 使えなくなるわけではなく、動き続ける。ただし新たなセキュリティ更新・修正・サポートが提供されなくなるため、以降に発見される脆弱性は塞がれない。基幹データを抱えるDBであることを踏まえると、「動くが守られない」状態の放置は経営リスクとして扱うべきだ。
Q. ESU(拡張セキュリティ更新プログラム)で延命できるか? A. Microsoftのライフサイクル情報では、SQL Server 2016のESUが1年目(2026年7月15日〜2027年7月13日)から3年目(〜2029年7月17日)まで設定されている。ただしESUはセキュリティ更新に限られる延命措置であり、提供条件・費用は契約形態によって異なるため、利用可否は販売パートナー・Microsoftに確認が必要だ。あくまで更改までの時間を買う手段と位置づけるべきである。
Q. 無償版のExpress Editionで小さなツールを動かしているだけでも対象か? A. 対象だ。ライフサイクル情報の対象エディションにはExpressも明記されている。部門の小規模ツールや計測器付属ソフトの裏で動くExpressは台帳から漏れやすく、むしろ典型的な見落としポイントである。
Q. どうせ更改するなら、何に移行すべきか? A. パッケージ継続ならベンダーの対応する新しいSQL Serverへの更改が基本線だ。一方、パッケージ自体が老朽化しているなら、後継製品・クラウドERP・再構築を含めた比較検討の好機になる。基幹刷新の期限問題はSAP ECC 2027 EOL問題と同根であり、DB更改を入口に基幹全体の刷新ロードマップを描くことを勧める。
発注・更改判断に落とすための確認観点
システム開発や基盤更改の記事を読むときは、ニュースそのものよりも自社の要件に変換できるかが重要である。確認すべきは、対象システム、利用部門、業務影響、現行保守の期限、データ移行の難易度、権限・ログ・監査要件、移行中の業務継続方法である。
特にRFPや要件定義では、製品名やベンダー名を先に書くと比較が歪む。先に書くべきなのは、処理量、可用性、権限、監査、移行制約、運用体制である。ニュースをきっかけに検討を始める場合でも、発注書には自社の制約条件を具体化して入れる必要がある。
GXOへ相談する前に整理しておくと早い情報
相談前には、現行システムの概要、利用人数、主要業務、連携先、保守期限、障害履歴、困っている改修、予算感、希望時期をまとめる。詳細な仕様書がなくても、画面・帳票・データの棚卸しから要件を復元できる。
90日で要件定義へ進めるロードマップ
最初の30日は、現行業務と現行システムの棚卸しに使う。画面、帳票、データ、連携、利用者、例外処理、障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書よりも現場の運用が正になっているため、担当者ヒアリングも必要である。
31日目から60日目は、刷新・更改の目的を決める。保守期限への対応だけなのか、業務改善、データ活用、AI導入、セキュリティ強化まで含めるのかで、要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。
61日目から90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限、ログ、監査、非機能、移行、テスト、保守、運用体制を含める。ニュースを見て急いで製品選定に入るより、この90日を使って発注側の物差しを整える方が、失敗コストは小さい。
いつGXOに相談すべきか
- 業務パッケージの 裏で動くDBのバージョンを把握できておらず、棚卸しから支援がほしい
- パッケージベンダーの見積もりが妥当か、更改か刷新かの判断を中立の立場で 比較検討したい
- DB更改を機に、塩漬けデータをBI・AIに使えるデータ基盤へ 引き上げたい
GXOはレガシーシステム刷新で基幹パッケージ・DBの棚卸しから更改・移行までを伴走し、データ活用基盤構築で更改後のデータ活用設計を、DX/システム開発でパッケージに収まらない業務の再構築を支援している。7月14日まで残り1か月、まず台帳づくりから始めてほしい。→ 相談はこちら
関連記事
- Amazon Linux 2サポート終了は2026年6月30日、残り18日|放置EC2の確認手順
- SAP ECC 2027 EOL問題|S/4HANA移行の費用とタイムライン
- Windows 10サポート終了まで半年|企業が今やるべき移行チェックリスト
- レガシーシステムの延命 vs リプレース判断フロー|投資判断8軸
編集部注:公開後の更新方針
本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。
読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。
参考資料
- Microsoft Learn「2026 年のサポート終了 - Microsoft Lifecycle」(2026年7月14日:SQL Server 2016、SharePoint Server 2016/2019ほか)
- Microsoft Learn「SQL Server 2016 - Microsoft Lifecycle」(延長サポート終了2026年7月14日、ESU 1〜3年目、SP3・対象エディション)
- AWS「Amazon Linux 2 FAQs」(2026年6月30日サポート終了)
本記事は2026年6月12日時点の公開情報をもとに作成。サポート期限はMicrosoftのライフサイクルポリシー上の日付(太平洋時間基準)であり、ESUの提供条件・価格は契約形態によって異なる。対応判断の前にMicrosoft Learnの一次情報の最新版を必ず確認すること。
「うちの基幹の裏で、何のDBが動いているか」答えられますか
業務パッケージとDBの棚卸し、ベンダー見積もりの妥当性評価、更改か刷新かの方式比較、更改を機にしたデータ基盤整備まで、特定ベンダーに依存しない立場で支援します。7月14日に間に合わない場合の経過措置の設計にも対応します。
※ 営業電話はしません | オンライン対応可 | 棚卸しの進め方の相談だけでもOK