Azure SQLへの移行やSQL Serverの延命を検討している管理者が最初に押さえるべき点は、Extended Security Updates（ESU）は「古いSQL Serverを使い続けるための恒久策」ではなく、移行までの時間を確保するための限定的なセキュリティ更新策だということです。Azure SQL DatabaseやAzure SQL Managed Instanceへ移行できるなら、将来のパッチ適用やOS更新の運用負荷を大きく減らせます。一方、オンプレミスやホステッド環境に残す場合は、Azure Arc、ライセンス条件、課金単位、更新プログラムの適用方法を早めに確認する必要があります。
2026年5月22日に公開または更新された公式情報を踏まえると、管理者が確認すべきポイントは大きく3つです。対象バージョンのSQL ServerがESUの対象か、Azure Arc経由で管理できる状態か、そしてESUを使う期間内にAzure SQL Managed InstanceやAzure SQL Databaseなどへ移行する計画があるかです。特にSQL Server 2012やSQL Server 2014を含む古い環境は、「更新を受け取れるか」だけでなく、「いつまでに脱却するか」を同時に決める必要があります。
Extended Security Updates（ESU）とは何か
Extended Security Updates（ESU）は、延長サポートが終了したSQL Serverに対して、一定期間だけ重要なセキュリティ更新を受け取るための仕組みです。Microsoft Learnの該当ドキュメントでは、SQL Server 2014（12.x）向けのESUが説明されており、ESUには新機能、機能改善、顧客要望による修正は含まれないとされています。また、SQL ServerのESUは定期的な月次リリースではなく、MSRCでCriticalと評価された脆弱性が見つかった場合に提供される性質のものです。(Microsoft Learn)
つまり、ESUは「古いSQL Serverを通常サポートと同じ状態に戻す制度」ではありません。あくまで、移行・アップグレード・再構築までのリスクを下げるための最低限のセーフティネットです。
特に注意したいのは、ESUには技術サポートそのものが含まれない点です。オンプレミスやホステッド環境でサポートを受けるには、Software Assurance、Premier/Unified Supportなど別のサポート契約が必要になる場合があります。Azure上でホストしている場合は、Azure Supportプランを利用する考え方になります。(Microsoft Learn)
Azure SQLとESUの関係
Azure SQLとESUの関係は、少し誤解されやすい部分です。Azure SQL DatabaseやAzure SQL Managed InstanceにESUを適用するというより、サポート終了したSQL Serverをどう扱うかの選択肢として、Azure SQLへの移行が重要になります。
Azure SQL DatabaseはフルマネージドなPaaSデータベースで、MicrosoftがSQLエンジンやOSコードのパッチ適用、更新、バックアップなど多くの管理作業を担います。Azure SQL Databaseは最新の安定版SQL Database Engineとパッチ済みOS上で稼働するため、ユーザーがSQL Server本体やOSのセキュリティ更新を個別に管理する運用とは大きく異なります。(Microsoft Learn)
Azure SQL Managed Instanceも、SQL Serverとの高い互換性を持ちながら、MicrosoftがSQLおよびOSコードのパッチ適用や更新を管理するPaaSです。既存SQL Serverからの移行負荷を抑えつつ、バックアップ、高可用性、自動パッチ適用などの運用負荷を減らせるため、SQL Server依存の強い業務システムでは有力な移行先になります。(Microsoft Learn)
| 選択肢 | 向いているケース | 管理者が見るべきポイント |
|---|---|---|
| Azure SQL Database | 単一DB、SaaS、マイクロサービス、SQL Server固有機能への依存が少ないシステム | 互換性、接続方式、パフォーマンス、メンテナンスウィンドウ |
| Azure SQL Managed Instance | SQL Server Agent、クロスDB、既存SQL Server機能への依存が大きいシステム | T-SQL差分、ネットワーク、バックアップ/復元、更新ポリシー |
| SQL Server on Azure VM | OSやSQL Server構成を細かく制御したいシステム | VMの更新管理、SQL Server IaaS Agent、ESU条件 |
| オンプレミス/他クラウド＋Azure Arc | すぐに移行できないが、ESUで一時的に保護したい環境 | Azure Arc接続、ライセンス、課金、パッチ適用手順 |
判断の軸はシンプルです。アプリケーションを変更できるならAzure SQL Database、SQL Server互換性を優先するならAzure SQL Managed Instance、OSまで含めて制御が必要ならSQL Server on Azure VM、一時的に残すならAzure ArcでESU管理を検討します。
2026年時点で押さえるべき変更点
2026年時点で重要なのは、SQL Server 2016の延長サポート終了が近づいていることです。Microsoftのサポート終了ページでは、SQL Server 2016の延長サポートは2026年7月14日に終了し、同日からSQL Server 2016のESUが開始されると案内されています。また、SQL Server 2014のESUは2027年7月12日に終了する予定です。(Microsoft)
さらに、Microsoftは2026年4月1日以降に提供される新しいWindowsおよびSQL Server向けESUについて、Azure、オンプレミス、他のパブリッククラウド、購入チャネルにかかわらず一貫した価格モデルを導入すると説明しています。ただし、この変更は既存のSQL Server 2014 ESUには適用されないとされています。(aka.ms)
この変更により、管理者は「Azureに置けばESUコストが常に有利」と単純には判断しにくくなります。今後は、ESU料金だけでなく、移行後の運用負荷、セキュリティリスク、監査対応、可用性、バックアップ設計まで含めて比較する必要があります。
ESUの対象範囲と影響を受ける環境
ESUの影響を受けるのは、主にサポート終了後もSQL Serverを稼働させる環境です。たとえば、SQL Server 2014、過去にSQL Server 2012を使っていたシステム、今後対象になっていくSQL Server 2016などが検討対象になります。
SQL Server 2012については、MicrosoftのライフサイクルFAQで、延長サポート終了日が2022年7月12日、ESU Year 3の終了日が2025年7月8日と示されています。したがって、2026年時点でSQL Server 2012が残っている場合は、ESUの新規適用を前提にするのではなく、移行、分離、廃止、またはサポートされるバージョンへのアップグレードを優先して検討すべきです。(Microsoft Learn)
影響範囲を調べるときは、SQL Server本体だけを見てはいけません。SQL Server Analysis Services、SQL Server Integration Services、SQL Server Reporting Services、Power BI Report Serverなどの関連サービスもESUサブスクリプションの対象として扱われる場合があります。公式ドキュメントでも、これらの関連サービスがSQL Server ESUサブスクリプションでサポートされると説明されています。(Microsoft Learn)
影響調査で確認すべき項目
| 確認項目 | 確認する理由 | 見落としやすいポイント |
|---|---|---|
| SQL Serverのバージョン | ESU対象か、移行対象かを判断するため | インスタンス単位でバージョンが違う |
| エディション | 課金やライセンス条件に影響するため | Developer/Expressを本番相当で使っている |
| 実行場所 | Azure、オンプレミス、他クラウドで条件が変わるため | ホステッド環境やAVSを分類できていない |
| コア数 | vCore/pCore課金の見積もりに必要 | VMに割り当てたvCPUとSQL Server利用状況が一致しない |
| Arc接続状態 | Azure Arc経由のESU管理に必要 | エージェント切断や証明書期限切れ |
| 更新方式 | 自動更新か手動適用かを決めるため | WSUSや既存運用に組み込めると思い込む |
| HA/DR構成 | パッシブレプリカの扱いに影響するため | フェールオーバー時の課金切り替えを未確認 |
まずは、対象サーバーで以下のようなT-SQLを実行し、バージョン、エディション、更新レベルを棚卸しします。
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('EngineEdition') AS EngineEdition;複数インスタンスがある環境では、サーバー名単位ではなくインスタンス単位で一覧化してください。1台のサーバーにSQL Server 2014と2019が混在している、開発用だと思っていたインスタンスが本番バッチに使われている、といったケースは珍しくありません。
Azure ArcでESUを使う場合の管理ポイント
Azure Arcを使うと、オンプレミスや他クラウド上のSQL ServerをAzure側から管理し、ESUサブスクリプションをAzure課金として扱えます。公式ドキュメントでは、Azure Arcによって有効化されたSQL Server ESUは、仮想コア、物理コア、無制限の仮想化を使う物理コアという複数のライセンス方式で管理できると説明されています。ESUをサブスクライブするには、アクティブなSoftware Assuranceがあるか、SQL Serverソフトウェアに対して従量課金制課金を有効にする必要があります。(Microsoft Learn)
Azure Arc対応SQL Serverの前提条件として、Azureサブスクリプション、Azure Connected Machine Agent、ネットワーク要件、Microsoft.AzureArcDataとMicrosoft.HybridComputeのリソースプロバイダー登録などが必要です。また、SQL Server 2012以降の64ビットSQL Serverが対象として示されていますが、サポートされない構成もあるため、事前確認が欠かせません。(Microsoft Learn)
Azure Arc導入前に確認すること
| 項目 | 確認内容 |
|---|---|
| Azureサブスクリプション | 課金先、リソースグループ、タグ設計を決める |
| リソースプロバイダー | Microsoft.AzureArcData と Microsoft.HybridCompute を登録する |
| ネットワーク | Azure Arcデータ処理サービスへアウトバウンド443で接続できるか確認する |
| 権限 | オンボーディング担当者に必要なAzure権限とOSローカル管理者権限を付与する |
| SQL Server権限 | Azure拡張機能がSQL Serverへ接続できる状態か確認する |
| 対象外構成 | コンテナー、古すぎるSQL Server、同名インスタンスなどがないか確認する |
| 運用ルール | 誰がArc接続、ESU有効化、課金確認、更新適用を承認するか決める |
特に、ネットワーク制限が厳しい環境ではAzure Arcの接続要件でつまずきやすくなります。プロキシ、ファイアウォール、名前解決、証明書、アウトバウンド通信の許可範囲を、セキュリティ部門と早めに調整してください。
更新プログラムの適用で失敗しやすいポイント
SQL Server ESUを有効化しても、更新プログラムが自動的に安全に適用されるとは限りません。Microsoft Learnでは、Azure Arc対応SQL Serverの自動更新はメンテナンスウィンドウを設定し、ホストOSレベルで動作し、インストール済みの全SQL Serverインスタンスに適用されると説明されています。さらに、現時点ではWindowsホストのみで動作し、ImportantまたはCriticalに分類されたWindowsおよびSQL Server更新を適用する一方、Important/CriticalではないService PackやCumulative Updateは手動インストールが必要です。(Microsoft Learn)
ここで重要なのは、ESUとCUの関係です。SQL Server 2014 ESUでは、ESUに最新の累積更新プログラム（CU）が含まれると説明されています。通常サポート期間中にGDRのみを適用していた環境では、ESUを受け取るタイミングで初めてCU相当の変更が入る可能性があるため、本番適用前に最新CUで検証しておくことが推奨されます。(Microsoft Learn)
パッチ適用前の実務チェック
| チェック項目 | 実施内容 |
|---|---|
| 検証環境 | 本番に近いデータ量、照合順序、ジョブ、リンクサーバーを再現する |
| バックアップ | フルバックアップ、ログバックアップ、復旧手順を確認する |
| 性能基準 | Query Store、待機統計、主要バッチ時間を更新前に記録する |
| 接続影響 | アプリ側のリトライロジック、タイムアウト、接続プールを確認する |
| メンテナンス枠 | OS再起動、SQL Server再起動、フェールオーバー時間を見込む |
| ロールバック | 復旧手順、判断基準、責任者を事前に決める |
本番DBでは「更新が成功したか」だけでなく、「更新後に問い合わせ性能が落ちていないか」「夜間バッチが締め時間に間に合うか」「監視アラートが増えていないか」まで確認します。
課金とライセンスで注意すべき点
Azure ArcによるSQL Server ESUサブスクリプションでは、使用状況が1時間ごとに報告され、エディションと対象バージョンに基づいてメーターが選択されます。仮想マシンでp-core ESUライセンスを指定していない場合は、OSEに表示される仮想コア合計に基づいて測定され、最小はOSEあたり4 vCoreです。物理サーバーの場合も、条件に応じて物理コア合計に基づいて測定されます。(Microsoft Learn)
また、接続断にも注意が必要です。SQL ServerのAzure拡張機能が接続を失うと課金が停止し、サブスクリプションが中断されます。証明書の期限切れなどで完全に接続が失われると、再オンボード後に新しいESUサブスクリプションを有効化し、関連する請求を支払う必要がある場合があります。長期オフラインやリソース移動は、意図しない課金やカバレッジ断につながるため監視対象に含めるべきです。(Microsoft Learn)
コスト管理では、以下のようなタグをAzureリソースに付けておくと、後から追跡しやすくなります。
| タグ例 | 用途 |
|---|---|
SystemName | 業務システム名を識別する |
Owner | 責任部門や担当チームを明確にする |
MigrationDeadline | ESU終了前の移行期限を可視化する |
Environment | Production、Staging、Developmentを区別する |
CostCenter | 請求先や部門別集計に使う |
ESUは「更新費」ではなく「移行猶予に対する費用」と捉えるべきです。月次のAzure Cost ManagementでESU関連コストを確認し、移行プロジェクトの進捗とセットでレビューする運用にしてください。
Azure SQLへ移行する場合の判断基準
ESUを使うか、Azure SQLへ移行するかを決めるときは、単純に「移行できるか」ではなく「どのAzure SQLに移すべきか」を検討します。Azure SQLの移行ガイドでは、Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VMというAzure SQLファミリーへの移行ドキュメントが整理されています。(Microsoft Learn)
Azure SQL Databaseを選びやすいケース
Azure SQL Databaseは、アプリケーションごとにDBが分かれている構成、WebアプリやSaaS、マイクロサービスに向いています。OS管理やSQL Serverインスタンス管理をなくし、データベース単位でスケールやバックアップを考えたい場合に適しています。
ただし、SQL Server Agent、クロスデータベーストランザクション、インスタンスレベル設定、CLR、リンクサーバーなどに強く依存している場合は、そのまま移すのが難しいことがあります。移行前に互換性評価を行い、アプリケーション側の改修量を見積もりましょう。
Azure SQL Managed Instanceを選びやすいケース
Azure SQL Managed Instanceは、既存SQL Serverとの互換性を重視しつつ、PaaS化したい場合に向いています。SQL Server Agent、クロスDBクエリ、ネイティブバックアップ/復元、Managed Instance linkなど、SQL Serverに近い運用・移行機能を使えるため、大規模な既存業務システムの移行先として検討しやすい選択肢です。(Microsoft Learn)
ただし、Azure SQL Managed InstanceにもオンプレミスSQL Serverとの差分はあります。たとえば、物理パス指定が使えない、接続はTCPのみ、SSRSはネイティブサービスとして実行できないなど、設計変更が必要になる部分があります。移行前にSQL Server機能の利用状況を棚卸ししてください。
SQL Server on Azure VMを選びやすいケース
SQL Server on Azure VMは、OS、SQL Server構成、エージェント、サードパーティ製バックアップ、監視ツール、特殊なミドルウェアを引き続き制御したい場合に向いています。移行難易度は比較的低くなりやすい一方、OSとSQL Serverの更新管理、バックアップ、可用性、監視は引き続き自社責任が大きくなります。
「ひとまずAzure VMに移す」だけでは、運用負荷の削減効果は限定的です。長期的にはAzure SQL Managed InstanceやAzure SQL Databaseへの再移行も視野に入れておくと、ESU後の再延命を避けやすくなります。
管理者と開発者が今すぐやるべき手順
ESU対応は、ライセンス担当だけで完結しません。DBA、インフラ管理者、アプリケーション開発者、セキュリティ担当、経理・調達部門が同じ一覧を見て進める必要があります。
| 手順 | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | SQL Serverのバージョン、エディション、配置、コア数を棚卸しする | SQL Serverインベントリ |
| リスク分類 | 本番、準本番、開発、廃止予定に分類する | 優先度リスト |
| 移行先選定 | Azure SQL Database、Managed Instance、Azure VM、継続運用を比較する | 移行方針 |
| ESU設計 | Arc接続、課金、ライセンス、更新方式を決める | ESU設計書 |
| 検証 | CU/ESU適用、性能、ジョブ、アプリ接続を確認する | 検証結果 |
| 展開 | メンテナンス枠を決め、本番適用する | 作業計画書 |
| 終了計画 | 移行後にESUを解約し、古い環境を停止・廃止する | 廃止チェックリスト |
開発者は、DBバージョンだけでなくアプリ側の振る舞いも確認してください。Azure SQLではメンテナンスやフェールオーバーが発生する前提で、接続リトライ、冪等性、トランザクション境界、タイムアウト設定を見直す必要があります。特に古いアプリケーションでは、接続エラーを即失敗として扱う実装や、長時間トランザクションを前提にした処理が問題になりやすいです。
ESUを使う場合の判断基準
ESUを有効化すべきなのは、次のようなケースです。
- すぐに移行できない本番システムがある
- サポート終了SQL Serverに機微情報や重要業務データが残っている
- 移行プロジェクトが進行中で、完了まで数か月から数年かかる
- 監査やセキュリティ基準上、未更新のDBサーバーを放置できない
- Azure Arc接続やライセンス条件を満たせる
反対に、ESUだけで延命し続ける前提は避けるべきです。ESUは最大3年という期限付きの制度であり、提供される更新も限定的です。新機能や通常の不具合修正、設計変更は期待できません。ESU導入時点で、移行完了日と廃止日をチケットやプロジェクト計画に明記しておくことが重要です。
よくある誤解
Azure SQLを使えばすべてのSQL Server問題が自動で解決する？
Azure SQL DatabaseやAzure SQL Managed Instanceはパッチ適用やバックアップなど多くの管理負荷を減らせますが、アプリケーション互換性、接続設計、権限、性能、コスト設計は利用者側で確認が必要です。特にオンプレミスSQL Serverのインスタンス機能を多用している場合は、Azure SQL Managed Instanceのほうが移行しやすいことがあります。
ESUを有効化すれば通常サポートと同じになる？
同じにはなりません。ESUは限定的なセキュリティ更新であり、新機能、機能改善、通常の不具合修正を提供するものではありません。技術サポートもESU自体に含まれるわけではありません。(Microsoft Learn)
SQL Server 2012もまだESUで守れる？
2026年時点では慎重に扱うべきです。MicrosoftのライフサイクルFAQでは、SQL Server 2012のESU Year 3終了日は2025年7月8日とされています。SQL Server 2012が残っている場合は、ESU前提ではなく、移行・隔離・廃止を優先してください。(Microsoft Learn)
Azure Arcに接続すれば更新適用まで完全自動化される？
完全自動ではありません。Azure Arc対応SQL Serverの自動更新は設定できますが、対象はメンテナンスウィンドウ内でのImportant/Critical更新などに限られます。CUやService Packなど、条件によっては手動対応が必要です。(Microsoft Learn)
まとめ：ESUは移行までの安全網として使い、Azure SQLへの移行計画を同時に進める
SQL ServerのExtended Security Updatesは、サポート終了後のリスクを一時的に下げるための重要な選択肢です。ただし、ESUは通常サポートの代替ではなく、移行までの猶予期間を確保するための仕組みです。
管理者はまず、SQL Serverのバージョン、エディション、配置場所、コア数、Azure Arc接続可否を棚卸ししてください。そのうえで、Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VM、Azure Arc経由のESU継続のどれが現実的かを判断します。
開発者は、移行先に合わせて接続リトライ、SQL Server固有機能、ジョブ、バッチ、性能特性を確認しましょう。ESUを有効化する場合でも、同時に移行完了日と廃止日を決めることが重要です。短期的にはESUで守り、長期的にはAzure SQLなどのマネージド環境へ移行する。この2段構えが、古いSQL Serverを安全に減らすための現実的な進め方です。
コメント