Azure SQLを利用している管理者・開発者が今回まず押さえるべき点は、「Editions and Supported Features of SQL Server 2019」はAzure SQLの料金プランやサービス階層そのものを説明するページではなく、SQL Server 2019のエディション別に使える機能を確認するための基準表だということです。
特に重要なのは、SQL Server 2019をオンプレミス、Azure VM、または既存システムで使っている場合に、Azure SQL DatabaseやAzure SQL Managed Instanceへ移行しても同じ機能が使えるとは限らない点です。SQL Server 2019の機能表で「Enterpriseなら使える」「Standardでは制限がある」と分かっても、Azure SQLではPaaS特有の制限や代替機能を別途確認する必要があります。Microsoft Learnでも、SQL Server 2019のエディション別機能表はSQL Server 2019に適用される内容であり、Azure SQLについては別の機能比較ページを参照するよう案内されています。(Microsoft Learn)
まず結論：Azure SQLで見るべきポイントは「SQL Server 2019の機能をそのまま持ち込めるか」
今回の公式情報を実務で読むなら、確認すべきことは大きく3つです。
1つ目は、現在利用しているSQL Server 2019のエディションです。Enterprise、Standard、Web、Express、Developerでは、CPU・メモリ・高可用性・暗号化・管理ツールなどに差があります。
2つ目は、利用中の機能が移行先で使えるかどうかです。たとえば、SQL Server 2019 Enterpriseで使っているAlways On可用性グループ、リソースガバナー、オンラインインデックス再構築などは、StandardやExpressでは利用可否が変わります。Azure SQL DatabaseやAzure SQL Managed Instanceへ移行する場合は、さらにAzure SQL側のサポート状況も確認が必要です。
3つ目は、SQL Server 2019のサポート状況です。SQL Server 2019はメインストリームサポートが2025年2月28日に終了し、延長サポートは2030年1月8日までとされています。運用中のシステムでは、機能表だけでなく、更新プログラムの適用方針や将来の移行計画もあわせて見直す必要があります。(Microsoft Learn)
2026年5月8日更新情報として読むときの注意点
社内の更新通知や技術情報配信では「2026年5月8日に公開・更新」と扱われることがありますが、Microsoft Learn上の該当ページには、現時点で「Last updated on 2025-11-28」と表示されています。したがって、2026年5月8日付の情報として確認する場合でも、SQL Server 2019の仕様がその日に大きく変更されたと断定せず、現在掲載されている公式の機能表をもとに判断するのが安全です。(Microsoft Learn)
実務では、日付そのものよりも次の観点で確認してください。
| 確認項目 | 見るべきポイント | 実務上の判断 |
|---|---|---|
| 対象製品 | SQL Server 2019に適用される情報か | Azure SQLの仕様表として読まない |
| エディション差 | Enterprise、Standard、Web、Expressの違い | 移行・縮小・コスト削減時の機能欠落を確認 |
| Azure SQLとの差 | Azure SQL Database / Managed Instanceで使えるか | PaaSの制限や代替機能を確認 |
| サポート期限 | 延長サポート内か、更新プログラムを適用しているか | セキュリティ更新と移行計画を分けて管理 |
SQL Server 2019のエディション別機能表で確認すべき内容
SQL Server 2019には、Enterprise、Standard、Web、Developer、Evaluation、Expressなどのエディションがあります。DeveloperはEnterprise相当の機能を含みますが、運用サーバーではなく開発・テスト用途のライセンスです。EvaluationはEnterprise相当の機能を含む評価版で、評価利用期間が定められています。(Microsoft Learn)
Azure SQLを使っている場合でも、SQL Server on Azure VMやオンプレミスSQL Serverから移行する場面では、このエディション差がそのままリスクになります。
スケール制限：ExpressやWebからの移行では容量・メモリ制限を見落としやすい
SQL Server 2019のエディション別機能表では、Database Engineの最大計算容量、バッファープールの最大メモリ、列ストアキャッシュ、メモリ最適化データ、リレーショナルデータベースサイズなどが整理されています。たとえばExpressはリレーショナルデータベースサイズが10GBに制限され、バッファープールの最大メモリもEnterpriseやStandardより大きく制限されます。(Microsoft Learn)
小規模な社内ツールや検証環境でExpressを使っている場合、最初は問題なくても、ログ、添付ファイル管理、履歴テーブル、分析用テーブルが増えると10GB制限に近づきます。Azure SQL Databaseへ移行するなら、Expressだから小さくてよいと決めつけず、実データサイズ、増加率、インデックスサイズ、バックアップ保持要件を確認してください。
高可用性：Always Onを使っている環境は移行先で設計をやり直す
SQL Server 2019の高可用性機能では、Always On可用性グループはEnterpriseで利用でき、Standardでは基本的な可用性グループがサポートされます。Standardの基本的な可用性グループは、1つのデータベースと2つのレプリカをサポートする位置づけです。(Microsoft Learn)
ここで注意したいのは、Azure SQL DatabaseやAzure SQL Managed Instanceでは、オンプレミスSQL ServerのAlways On構成をそのままユーザーが管理するわけではない点です。Azure SQLではAzure側が高可用性を管理し、PaaSで使えない、または制限される機能があります。(Microsoft Learn)
移行時は、既存のAlways On、ログ配布、フェールオーバークラスターをそのまま再現しようとするのではなく、Azure SQL Databaseならフェールオーバーグループ、Azure SQL Managed Instanceならフェールオーバーグループやサービス階層ごとの可用性設計を検討します。
セキュリティ：暗号化・監査は「使えるか」だけでなく運用方法を確認する
SQL Server 2019では、行レベルセキュリティ、Always Encrypted、動的データマスキング、サーバー監査、データベース監査などが複数エディションでサポートされています。一方、TDEやバックアップ暗号化、拡張キー管理はエディションによって利用可否が異なります。(Microsoft Learn)
Azure SQLに移行する場合は、暗号化機能の有無だけでなく、鍵管理、監査ログの保存先、Microsoft Entra ID認証、ネットワーク制御もあわせて確認してください。特に、オンプレミスではSQL Server認証中心だった環境をAzure SQLへ移すと、ID管理や接続文字列の見直しが必要になることがあります。
パフォーマンス：Enterprise前提のチューニング機能に注意する
SQL Server 2019では、リソースガバナー、I/Oリソース管理、オンライン非クラスター化列ストアインデックス再構築、メモリ最適化TempDBメタデータなど、一部のパフォーマンス関連機能がEnterprise中心に提供されています。(Microsoft Learn)
また、インテリジェントなクエリ処理では、スカラーUDFのインライン化やテーブル変数の遅延コンパイルは複数エディションで利用できますが、自動チューニング、行ストアのバッチモード、バッチモードアダプティブ結合などはEnterpriseでのみサポートされる項目があります。(Microsoft Learn)
「Azureに移せば自動的に速くなる」と考えるのは危険です。移行前に、CPU使用率、待機統計、クエリストア、インデックス断片化、メモリ使用量、日次バッチの処理時間を記録し、移行後に比較できる状態にしておきましょう。
Azure SQL DatabaseとAzure SQL Managed Instanceで影響が出やすい機能
Azure SQL DatabaseとAzure SQL Managed Instanceは、SQL Serverの最新安定版と共通のコードベースを共有し、多くの標準SQL言語、クエリ処理、データベース管理機能が共通です。ただし、Azureがデータベースを管理するPaaSであるため、高可用性やファイルシステムアクセスなど、一部機能には制限があります。(Microsoft Learn)
Azure SQL Databaseは「単一データベース中心」の設計に向いている
Azure SQL Databaseは、単一データベースやエラスティックプールを中心に設計したい場合に向いています。一方で、SQL Server Agent、サーバーレベルの機能、クロスデータベース処理、ファイルシステムアクセスなどは、オンプレミスSQL Serverと同じ感覚では使えません。
たとえば、Azure SQL DatabaseではSQL Server Agentは利用できず、代替としてElastic Jobsなどを検討します。また、BACKUPコマンドはユーザー主導の通常運用ではなく、自動バックアップが中心です。(Microsoft Learn)
向いているケースは、以下のような環境です。
- Webアプリケーションごとにデータベースを分離したい
- インスタンス管理を減らしたい
- 自動バックアップ、スケーリング、PaaS運用を優先したい
- SQL Server Agentやサーバーレベル機能への依存が少ない
Azure SQL Managed Instanceは「SQL Serverに近い移行先」だが完全互換ではない
Azure SQL Managed Instanceは、SQL Serverに近い機能を必要とする移行先として検討しやすいサービスです。SQL Server Agent、データベース間クエリ、Service Broker、リソースガバナーなど、Azure SQL Databaseでは利用できない一部機能を使える場合があります。(Microsoft Learn)
ただし、完全なオンプレミスSQL Serverではありません。たとえば、ファイルパスの指定や一部のファイルシステム操作、特定のトレースフラグ、復元方法、タイムゾーン設定などは制限や条件があります。Managed Instanceを選ぶ場合でも、「SQL Server 2019で使っているから大丈夫」ではなく、Azure SQL Managed Instanceの機能比較表で1つずつ確認してください。
SQL Server on Azure VMはSQL Server 2019のエディション差がそのまま残る
Azure VM上にSQL Server 2019を構築している場合は、基本的にIaaS上のSQL Serverです。そのため、SQL Server 2019のEnterprise、Standard、Web、Expressといったエディション差が運用に直接影響します。
Azure SQL DatabaseやManaged Instanceとは異なり、OS、SQL Serverインスタンス、バックアップ、パッチ適用、監視、HA/DR構成の責任範囲が広くなります。自由度は高い一方で、管理負荷も大きくなるため、コストだけでなく運用体制も含めて判断しましょう。
管理者が確認すべき設定と棚卸し手順
Azure SQLへの移行やSQL Server 2019の見直しを行う場合は、まず現状把握から始めます。エディション、バージョン、互換性レベル、利用中の機能を確認しないまま移行すると、移行テストの後半で「この機能は移行先で使えない」と判明しやすくなります。
Microsoftは、SQL Serverのバージョンとエディション確認方法として、SSMS、エラーログ、SELECT @@VERSION、SERVERPROPERTYなどを案内しています。(Microsoft Learn)
SELECT
SERVERPROPERTY('Edition') AS edition,
SERVERPROPERTY('ProductVersion') AS product_version,
SERVERPROPERTY('ProductLevel') AS product_level,
SERVERPROPERTY('EngineEdition') AS engine_edition;次に、データベースごとの互換性レベルを確認します。互換性レベルが古いままだと、新しいSQL ServerやAzure SQLへ移行しても、期待したクエリ最適化や機能が有効にならない場合があります。
SELECT
name,
compatibility_level
FROM sys.databases
ORDER BY name;さらに、エディション固有の機能を使っていないか確認します。sys.dm_db_persisted_sku_featuresは、現在のデータベースで有効になっているエディション固有機能を一覧化するために使えます。Microsoft Learnでは、このビューにより、特定エディションでのみサポートされる機能がデータベースで使われているかを確認できると説明されています。(Microsoft Learn)
SELECT
DB_NAME() AS database_name,
feature_name
FROM sys.dm_db_persisted_sku_features;このクエリで行が返ってきた場合は、移行先のエディションやAzure SQLサービスでその機能がサポートされるか確認してください。ただし、すべての運用上の差分をこのビューだけで検出できるわけではありません。SQL Server Agentジョブ、リンクサーバー、CLR、ファイルアクセス、メンテナンスジョブ、認証方式、バックアップ手順などは別途棚卸しが必要です。
開発者が確認すべきコード・接続・デプロイ上の注意点
開発者が特に注意すべきなのは、SQL Server 2019の機能そのものよりも、アプリケーションが暗黙的に依存している動作です。
たとえば、次のような実装はAzure SQLへの移行時に問題になりやすいです。
| 確認対象 | よくある問題 | 対応の方向性 |
|---|---|---|
| 接続文字列 | サーバー名、暗号化設定、認証方式が古い | Microsoft Entra ID認証や暗号化必須設定を確認 |
| SQL Server Agent依存 | 定期処理をAgentジョブだけで実装している | Azure SQL DatabaseではElastic JobsやAzure Automationを検討 |
| ファイル操作 | BULK INSERTや証明書操作でローカルファイルを参照 | Azure Blob Storage経由の方式へ変更 |
| クロスDBクエリ | 3部構成名やリンクサーバーに依存 | Managed Instanceの利用可否やElastic Queryを検討 |
| CLR・外部処理 | SQL Server上で外部実行に近い処理をしている | App Service、Functions、コンテナーなど外部化を検討 |
Azure SQL Databaseではファイルシステムアクセスがなく、代替としてAzure Blob Storageに対するBULK INSERTやOPENROWSETを使う構成が案内されています。SQL Server AgentもAzure SQL Databaseでは利用できないため、ジョブ実行の設計を移行前に変更する必要があります。(Microsoft Learn)
移行時に失敗しやすいポイント
EnterpriseからStandard相当へ移ると機能差でつまずく
コスト削減のため、EnterpriseからStandardへ移行するケースでは、単にライセンス費用だけを見ると失敗します。Always On可用性グループ、オンラインインデックス操作、リソースガバナー、高度なクエリ処理機能など、Enterprise前提の運用が含まれていないか確認してください。
特にメンテナンス時間を短縮するためにオンラインインデックス再構築を使っている環境では、移行後にメンテナンスウィンドウが長くなる可能性があります。バッチ処理、夜間バックアップ、インデックス再構築、統計更新のスケジュールを実測値で見直しましょう。
Azure SQL Databaseに移るとインスタンス単位の発想が通用しない
Azure SQL Databaseでは、SQL Serverのインスタンス全体を自分で管理する前提ではありません。データベース単位のPaaSとして考える必要があります。
そのため、サーバーレベルログイン、SQL Server Agent、リンクサーバー、データベースメール、ファイル配置、復旧モデルなど、オンプレミスSQL Serverで当たり前だった設計がそのまま使えない場合があります。Azure SQL Databaseでは完全復旧モデルが前提となり、単純復旧モデルや一括ログ復旧モデルは利用できません。(Microsoft Learn)
SQL Server 2019の更新プログラム適用と機能確認を混同する
エディション別機能表は「どの機能がどのエディションで使えるか」を確認する資料です。一方、セキュリティ更新や累積更新プログラムは別の管理対象です。
2026年5月時点のMicrosoft Learnでは、SQL Server 2019向けにMay 2026のGDRやCU32 + GDRが掲載されています。運用中のSQL Server 2019では、機能差の確認とあわせて、現在のビルド番号が最新のセキュリティ更新方針に沿っているか確認してください。(Microsoft Learn)
SELECT @@VERSION;ビルド番号を確認したら、SQL Serverの更新履歴と照合し、テスト環境で適用検証を行います。本番環境では、バックアップ取得、メンテナンス時間、アプリケーション接続確認、ロールバック手順を事前に用意してください。
Azure SQLへの移行判断は3パターンで考える
SQL Server 2019からAzure SQLへ移行する場合、最初に移行先を決めるのではなく、現在の依存機能から逆算すると判断しやすくなります。
| 現在の状況 | 向いている移行先 | 判断基準 |
|---|---|---|
| 単一DB中心で、サーバーレベル機能への依存が少ない | Azure SQL Database | 運用負荷を減らし、PaaS化したい |
| SQL Server Agent、データベース間クエリ、インスタンス機能が必要 | Azure SQL Managed Instance | SQL Serverに近い互換性を優先したい |
| OSやSQL Serverインスタンスを細かく制御したい | SQL Server on Azure VM | 既存構成を大きく変えずにAzureへ移したい |
最も避けたいのは、「Azure SQL」と一括りにして移行先を決めることです。Azure SQL DatabaseとAzure SQL Managed Instanceは似ている部分もありますが、サポートされる機能、管理範囲、ネットワーク、バックアップ、ジョブ実行、リソース制限が異なります。Microsoft Learnでも、Azure SQL DatabaseとManaged Instanceの機能やリソース制限は別表で整理されています。(Microsoft Learn)
実務チェックリスト：今すぐ確認すべき項目
移行や見直しに着手する前に、以下を確認してください。
| チェック項目 | 確認方法 | 完了の目安 |
|---|---|---|
| SQL Server 2019のエディション | SERVERPROPERTY('Edition') | 全インスタンスで一覧化済み |
| ビルド番号 | @@VERSIONまたはSERVERPROPERTY('ProductVersion') | 更新履歴と照合済み |
| 互換性レベル | sys.databases | 古い互換性レベルのDBを把握済み |
| エディション固有機能 | sys.dm_db_persisted_sku_features | 移行先での可否を確認済み |
| Agentジョブ | SSMSやmsdbのジョブ一覧 | Azure SQL Database移行時の代替案あり |
| バックアップ方式 | 現行手順書、ジョブ、保存先 | PaaSの自動バックアップと整合済み |
| HA/DR構成 | Always On、ログ配布、FCIの有無 | Azure側の代替設計を作成済み |
| 認証・権限 | SQLログイン、Windows認証、Entra ID | 接続方式の変更影響を確認済み |
| パフォーマンス基準値 | Query Store、待機統計、バッチ時間 | 移行前後で比較可能 |
まとめ：SQL Server 2019の機能表は「Azure SQL移行の棚卸し表」として使う
「Editions and Supported Features of SQL Server 2019」は、Azure SQLの新機能発表として読むより、SQL Server 2019からAzure SQLへ移行する前の棚卸し表として使うのが実務的です。
まず、現在のSQL Server 2019のエディション、ビルド、互換性レベル、利用機能を確認します。次に、その機能がAzure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VMのどれで無理なく使えるかを比較します。最後に、バックアップ、HA/DR、ジョブ、認証、監査、パフォーマンスの移行設計を作ります。
最初に行うべき作業は、全SQL Serverインスタンスでエディションとバージョンを取得し、利用中のエディション固有機能を洗い出すことです。その結果をもとに、Azure SQL Databaseで十分か、Managed Instanceが必要か、Azure VMで維持すべきかを判断してください。
コメント