2026年7月1日に公開された Microsoft 公式ブログ「What’s new across Microsoft SQL in 2026 so far」は、Azure SQL 管理者にとって「今すぐ全環境を変更しなければならない告知」というより、AI活用、Microsoft Entra 認証、TDE鍵管理、イベント連携、Microsoft Fabric 連携をどこから採用するか判断するための更新一覧です。特に Azure SQL Database / Azure SQL Managed Instance / SQL database in Microsoft Fabric を運用している企業は、GA機能とPreview機能を分けて確認し、認証・暗号化・開発ツール・リアルタイム連携の棚卸しを進める必要があります。(Microsoft for Developers)
今回のポイントは、Azure SQL が単なるクラウドRDBではなく、RAGやベクトル検索、イベント駆動アーキテクチャ、Fabric上の分析基盤とつながる「AI時代の業務データ基盤」へ寄っていることです。一方で、Preview機能を本番に入れる判断、Microsoft Entra と Azure RBAC の混同、TDEの鍵ローテーション設計、TLSや古いドライバーの確認を怠ると、移行や運用でつまずきやすくなります。
Azure SQL の新機能・変更点で最初に押さえるべき結論
今回の公式まとめでは、Microsoft SQL 全体として SQL Server、Azure SQL、SQL database in Fabric、SSMS、VS Code 拡張、ドライバーまで広く更新されています。Azure SQL 管理者が優先して見るべき領域は、次の4つです。
| 優先度 | 確認領域 | 主な更新 | 管理者が見るべき理由 |
|---|---|---|---|
| 高 | 認証・権限 | Microsoft Entra server-level logins と fixed server roles がGA | SQL認証依存を減らし、ID統制を Entra 側に寄せやすくなる |
| 高 | 暗号化・鍵管理 | TDEのversionless keysがGA、AES keysがPreview | CMK運用、鍵ローテーション、コンプライアンス対応に影響する |
| 中 | AI・ベクトル検索 | AI_GENERATE_EMBEDDINGS と CREATE EXTERNAL MODEL がGA | RAGや類似検索をSQL内で扱いやすくなる |
| 中 | Fabric・リアルタイム連携 | Change Event Streaming、SQL database in Fabricの照合順序・移行支援 | 分析基盤やイベント駆動システムへのデータ連携方法が変わる |
重要なのは、すべてを一度に有効化することではありません。GA機能は採用候補として検証を進め、Preview機能は本番利用の可否、サポート範囲、リージョン対応、既存設計への影響を確認する、という切り分けが現実的です。
2026年前半の Microsoft SQL 更新は何が変わったのか
Microsoft の発表では、2026年3月の SQLCon / FabCon 以降、Microsoft Build 2026 を中心に SQL Server、Azure SQL、SQL database in Fabric にわたる更新が整理されています。公式ブログでは各項目が GA または Preview として区分されているため、管理者はまず「使える機能」と「評価段階の機能」を混同しないことが大切です。(Microsoft for Developers)
GAとして確認すべき主な更新
GAになった機能は、社内標準化や運用設計の候補にしやすい領域です。特に Azure SQL では、Entra認証、AI埋め込み生成、TDE鍵管理が実務上の注目点です。
| 機能 | 対象 | できること | 実務での使いどころ |
|---|---|---|---|
| Microsoft Entra server-level logins / fixed server roles | Azure SQL Database など | Microsoft Entra ID のユーザー、グループ、アプリをサーバーレベルのプリンシパルとして扱う | SQL認証の削減、グループベースの権限管理、監査しやすいID統制 |
| AI_GENERATE_EMBEDDINGS / CREATE EXTERNAL MODEL | Azure SQL Database、Azure SQL Managed Instance | T-SQLから外部AIモデルを呼び出し、ベクトル埋め込みを生成 | RAG、文書検索、類似レコード検索、FAQ検索 |
| TDE versionless keys | Azure SQL Database | Key Vault / Managed HSM の特定バージョンではなく、鍵名ベースで最新の有効な鍵を利用 | CMKローテーション時の運用負荷低減 |
| Regex support for LOB types in T-SQL | Microsoft SQL | varchar(max) / nvarchar(max) に対する正規表現対応 | 長文データ、ログ、自由記述項目のパターン処理 |
Microsoft Learn の Azure SQL Database 更新情報でも、Microsoft Entra server principals は2026年6月にGAとして記載されています。あわせて、AES keys for TDE はPreview、160/192 vCoreのHyperscale Premium-seriesはPreviewとして整理されています。(Microsoft Learn)
Microsoft Entra server-level logins は認証設計の見直しポイント
Azure SQL の Microsoft Entra 認証は、単に「AzureにログインできるからSQLにも入れる」という仕組みではありません。Microsoft Learn では、Azure SQL に接続してクエリを実行するには、対象データベース側に Microsoft Entra principals を作成する必要があり、Azure RBAC の SQL Server Contributor や SQL DB Contributor は管理操作向けであって、データベース接続権限そのものではないと説明されています。(Microsoft Learn)
この点は、移行時に非常に間違えやすいポイントです。たとえば、Azure管理者権限を持つユーザーが「ポータルでSQLリソースを管理できる」ことと、「データベース内のテーブルをSELECTできる」ことは別です。権限設計では、次のように役割を分けて考える必要があります。
| 権限の種類 | 管理対象 | よくある誤解 | 正しい確認ポイント |
|---|---|---|---|
| Azure RBAC | Azureリソースの作成、変更、削除 | RBACを付ければSQLデータにもアクセスできる | データアクセスにはSQL側のプリンシパルと権限が必要 |
| Microsoft Entra admin | Azure SQL の初期Entra管理者 | 個人アカウントだけでよい | 運用ではEntraグループを管理者にする方が引き継ぎやすい |
| Server-level login | サーバーレベルのID | contained userだけで十分 | 複数DB横断やサーバーロール管理ではlogin設計が効く |
| Database user / role | データベース内の権限 | ログイン作成だけで権限付与完了 | 各DBでユーザー作成、ロール付与、最小権限を確認 |
実務では、まず既存のSQL認証ログインを棚卸しし、アプリケーション、運用担当者、バッチ、BIツール、監視ツールの接続方式を分類します。そのうえで、人間の管理者はEntraグループ、アプリケーションはマネージドIDまたはサービスプリンシパル、緊急用には限定的なブレークグラスアカウント、という形に寄せると運用しやすくなります。
AI_GENERATE_EMBEDDINGS でAzure SQL内のRAG設計が現実的に
AI_GENERATE_EMBEDDINGS と CREATE EXTERNAL MODEL は、Azure SQL Database と Azure SQL Managed Instance でGAとなった重要なAI関連機能です。Microsoftの説明では、CREATE EXTERNAL MODEL がAIモデルのエンドポイントや認証情報をデータベースオブジェクトとして定義し、AI_GENERATE_EMBEDDINGS がT-SQL内でそのモデルを呼び出してベクトル配列を生成します。生成したベクトルは VECTOR 型の列に保存し、VECTOR_DISTANCE や VECTOR_SEARCH で検索できます。(Microsoft for Developers)
これにより、文書や商品説明、問い合わせ履歴、ナレッジベースを外部ETLだけに頼らず、SQLの中で埋め込み生成から検索まで扱いやすくなります。たとえば、問い合わせ管理システムで過去チケットの本文をベクトル化し、新規問い合わせに近い過去事例を検索する、といった構成が取りやすくなります。
ただし、導入時には次の点を確認してください。
| 確認項目 | 内容 |
|---|---|
| 外部REST呼び出し | Azure SQL Managed Instance と SQL Server 2025 では、外部RESTエンドポイント呼び出しを有効化する設定が必要。Azure SQL Database では不要 |
| 認証情報 | Azure OpenAI など外部モデルのAPIキーや認証情報をデータベーススコープ資格情報として扱う |
| 権限 | CREATE EXTERNAL MODEL には作成権限、AI_GENERATE_EMBEDDINGS の実行には対象モデルへのEXECUTE権限が必要 |
| コスト | 埋め込み生成はAIモデル呼び出しを伴うため、SQLリソースだけでなくAI側の課金やレート制限も見る |
| データ保護 | 個人情報や機密文書を外部モデルに送る場合、DLP、マスキング、監査ログ、契約条件を確認する |
特に注意したいのは、便利だからといって本番データをそのまま埋め込み生成に流すことです。RAG基盤では、投入対象の列、機密情報の除外、再生成タイミング、モデル変更時の再インデックス方針まで決めておく必要があります。
TDE versionless keys と AES keys は鍵管理の実務に効く
Azure SQL Database の TDE では、versionless keys がGAになりました。Microsoft Learn では、TDEプロテクター設定時にKey Vaultキーの特定バージョンを指定する方法と、バージョンを含まないキー識別子を使う方法の両方が説明されており、Azure SQL Database は最新の有効なキーを解決して利用するとされています。(Microsoft Learn)
従来、CMKをローテーションするたびにSQL側の参照キーURIを更新していた環境では、versionless key URI によって運用負荷を下げられる可能性があります。セキュリティチームがKey Vault側で鍵をローテーションし、DBAが都度SQL側のTDE protectorを更新する、といった手順を簡素化しやすくなります。
一方で、AES keys for TDE はPublic Previewです。Microsoft Learn では、Azure SQL Database の customer-managed TDE が構成に応じてRSAとAESの両方をサポートし、AESキー対応はPublic PreviewでAzure SQL Databaseに限定され、リージョンやサービス展開状況によって利用可否が変わる可能性があると説明されています。(Microsoft Learn)
TDE関連で管理者が確認すべきこと
| 項目 | 確認ポイント |
|---|---|
| Key Vault / Managed HSM | soft-delete と purge protection が有効か |
| キー権限 | Azure SQL のIDに get、wrap key、unwrap key の権限があるか |
| キーURI | versionless key URI に切り替える対象とタイミングを決めているか |
| 監査 | キー操作、TDE変更、アクセス失敗をログで追えるか |
| Preview利用 | AES keysを本番標準にする前に、サポート条件、リージョン、復旧手順を検証したか |
暗号化の更新は、機能を有効化することよりも、復旧手順を確認することが重要です。鍵の無効化、Key Vault障害、権限変更ミスが発生した場合にデータベースへ接続できるか、誰が戻せるか、監査証跡をどこで確認するかまで手順化しておきましょう。
Change Event Streaming はCDCやポーリング設計の見直し候補
Change Event Streaming、略してCESは、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instanceで導入されたPreview機能です。Microsoft Learn では、INSERT、UPDATE、DELETEといったDMLの増分変更をほぼリアルタイムで取得し、Azure Event HubsへCloudEventとして送信する機能として説明されています。イベントはJSONまたはAvro Binaryでシリアライズされます。(Microsoft Learn)
これにより、従来の「数分おきにSQLをポーリングする」「CDCテーブルを別プロセスで読み取る」「ETLバッチで差分連携する」といった構成を、一部の用途で置き換えられる可能性があります。たとえば、注文テーブルの変更をEvent Hubsへ送り、在庫、通知、分析、監査ログの各システムが独立して購読する、といったイベント駆動設計に向いています。
ただし、Preview段階では次のような確認が欠かせません。
| 確認項目 | 理由 |
|---|---|
| 対象テーブルの選定 | すべてのテーブルを流すとイベント量、コスト、下流処理が膨らむ |
| Event Hubs設計 | パーティション、保持期間、コンシューマーグループ、再処理方法が必要 |
| 個人情報の扱い | 変更前後の値を含む場合、イベント側にもデータ保護が必要 |
| 順序性と冪等性 | 下流システムで重複受信や順序ずれに耐える設計が必要 |
| 既存CDCとの使い分け | ETL、監査、イベント通知で求める粒度が異なる |
CESは「便利なリアルタイム連携」ですが、データベース外に変更データを流す仕組みでもあります。セキュリティレビューなしに導入すると、SQL内では保護されていたデータがEvent Hubsや下流アプリに広がるリスクがあります。
SQL database in Fabric は多言語・移行・アプリ連携が進む
SQL database in Microsoft Fabric では、Full collation support、Migration assistant、Fabric Apps with SQL database がPreviewとして挙げられています。Full collation support では、SQL database in Fabric 作成時に Azure SQL Database の照合順序を利用できるようになり、多言語データ、検索、並べ替え、レポート、アプリ開発で柔軟性が増します。([Microsoft Fabric Community][7])
日本語環境で特に見落とせないのが照合順序です。移行元SQL ServerやAzure SQL Databaseと照合順序が違うと、文字列比較、LIKE検索、並べ替え、重複判定、インデックス利用に差が出る可能性があります。SQL database in Fabric へ移行する場合は、テーブル定義だけでなく、照合順序、文字コード、大小文字・アクセント・かなの扱いもテストしてください。
Migration assistant は、SQL ServerワークロードをFabricへ移す際の複雑さを下げるためのPreview機能です。Microsoft Fabric Communityでは、手動のスキーマ変換、複雑なETL、再設計の負担を減らし、SQL ServerからFabricへの移行を進めやすくするものとして紹介されています。([Microsoft Fabric Community][8])
ただし、移行支援ツールがあるからといって、移行計画が不要になるわけではありません。実務では次の順序で確認すると失敗しにくくなります。
| 手順 | 確認内容 |
|---|---|
| 現状把握 | DBサイズ、照合順序、依存ビュー、ストアドプロシージャ、ジョブ、外部連携を棚卸し |
| 移行可否評価 | Fabric側で未対応のT-SQL、権限、接続方式、パフォーマンス特性を確認 |
| 小規模検証 | 代表的なテーブルとクエリで検索結果、並べ替え、実行時間を比較 |
| セキュリティ設計 | Entra ID、ワークスペース権限、データアクセス、監査ログを整理 |
| 本番移行計画 | 切り戻し、差分同期、停止時間、利用者周知を決める |
Hyperscale の 160 / 192 vCore Preview は高負荷統合向け
Azure SQL Database Hyperscale では、Premium-series の160 vCoreと192 vCoreオプションがPreviewとして示されています。Microsoft Learn の更新情報でも、単一HyperscaleデータベースとHyperscale elastic poolsの両方で160/192 vCoreオプションがPreviewとして記載されています。(Microsoft Learn)
この更新は、すべての環境に関係するものではありません。むしろ、大規模SaaS、シャーディング数を減らしたいアプリ、ピーク時のCPUボトルネックが明確なワークロード、統合による運用簡素化を狙う環境向けです。
導入判断では、単に「vCoreを増やせば速くなる」と考えないことが重要です。CPU待ちではなく、ロック、I/O、クエリプラン、アプリ側の接続プール、tempdb利用、ログ生成がボトルネックであれば、スケールアップだけでは効果が限定的です。Preview利用前に Query Store、待機統計、実行プラン、アプリケーションのタイムアウト傾向を確認しましょう。
SSMS・VS Code・SQL MCP Server は開発体験を変える
今回の更新では、Azure SQL本体だけでなく、開発ツールの更新も大きな意味を持ちます。SSMS 22.7.0 では GitHub Copilot Agent Mode、SQL Formatter、Schema Compare などのPreviewが挙げられています。SSMS 22.6.0ではStorage BrowserやDACPAC import/exportでEntraベース認証、SSMS 22.5.0ではSQL ServerからAzure SQLへの移行支援やSQL project item templatesが示されています。(Microsoft for Developers)
MSSQL extension for VS Code では、Schema Designer with GitHub Copilot、Data API builder with GitHub Copilot、SQL Notebooks がGAとして整理され、Azure SQL Database provisioning はPreviewとして扱われています。開発者がローカルやエディタ内でスキーマ設計、API生成、ノートブック分析、Azure SQLプロビジョニングまで進めやすくなる流れです。(Microsoft for Developers)
SQL MCP Server も注目点です。Microsoftは、SQL MCP ServerをData API builderの機能として位置付け、JSON構成で接続先、公開するテーブル・ビュー・ストアドプロシージャ、権限を定義できると説明しています。DABの抽象レイヤーにより、REST、GraphQL、MCPの権限制御をそろえやすくなります。(Microsoft for Developers)
重要なのは、SQL MCP Serverが単純なNL2SQL、つまり自然言語からSQLを自由生成する仕組みを目指していない点です。Microsoftは、モデルの非決定性による誤った複雑クエリ生成を避けるため、Data API builderの抽象レイヤーとQuery Builderを使う方向性を説明しています。これは、企業がAIエージェントにデータアクセスを許可する際の安全性を考えるうえで大きな設計思想です。(Microsoft for Developers)
設定変更と移行期限はどう見ればよいか
今回の2026年7月1日の公式まとめ自体は、多数の機能更新を整理したものであり、Azure SQL利用者全員に対して「この日までに必ず移行」といった一律の移行期限を示す告知ではありません。したがって、管理者はあわてて全機能を有効化するのではなく、GA機能、Preview機能、既存のセキュリティ要件を分けて確認するのが現実的です。(Microsoft for Developers)
ただし、Azure SQL運用全体ではTLS設定の確認は引き続き重要です。Microsoft Learn の接続設定では、Azure SQL Databaseで現在サポートされる最小TLSバージョンはTLS 1.2であり、TLS 1.0と1.1は廃止され使用できないと説明されています。古いドライバーやサードパーティ製アプリがある場合は、接続失敗や認証エラーの原因になります。(Microsoft Learn)
管理者向けチェックリスト
| チェック項目 | 具体的な確認内容 |
|---|---|
| GA / Previewの分類 | 採用候補、検証のみ、本番禁止の3段階に分ける |
| 認証方式 | SQL認証、Entraユーザー、Entraグループ、マネージドIDを棚卸し |
| 権限設計 | Azure RBACとSQL内権限を混同していないか確認 |
| TDE / CMK | versionless key URI、Key Vault権限、鍵ローテーション、復旧手順を確認 |
| AI機能 | 外部モデルに送るデータ、APIキー管理、コスト、監査を確認 |
| CES | Event Hubs、イベント形式、個人情報、再処理、下流システムを設計 |
| Fabric移行 | 照合順序、T-SQL互換性、権限、性能、切り戻し計画を検証 |
| クライアント | TLS 1.2以上、最新ドライバー、ODBC/OLE DB/.NET/Python/PHP/Goの互換性を確認 |
| 開発ツール | SSMS、VS Code拡張、DACPAC、SQL Project、Copilot利用ルールを整備 |
実務で失敗しやすいポイント
Azure SQL の更新を追うときは、新機能そのものよりも「既存運用との接点」で問題が起きます。特に次の点は、導入前に必ず確認してください。
| 失敗例 | 何が起きるか | 対策 |
|---|---|---|
| Preview機能を本番前提で設計する | 仕様変更、リージョン未対応、サポート制限で計画が崩れる | PoC環境で評価し、本番採用はGA後に再判断する |
| Entra権限をAzure RBACだけで済ませる | ポータル管理はできてもSQL接続やクエリ実行ができない | SQL側のlogin、user、roleを明示的に設計する |
| AI埋め込み生成で機密データを無条件に送る | 個人情報や機密文書が外部AIエンドポイントに渡る | 対象列の限定、マスキング、監査、承認フローを設ける |
| TDE鍵をローテーションして終わりにする | SQL側の参照、権限、復旧手順に不備が残る | versionless key、Key Vault権限、障害時手順をテストする |
| CESを単なるCDC置き換えと考える | 下流の重複処理、順序制御、再送設計が不足する | Event Hubsとコンシューマー側の設計を先に固める |
| Fabric移行で照合順序を軽視する | 検索結果やソート順、重複判定が変わる | 移行前後で代表クエリの結果差分を比較する |
これから管理者が取るべき行動
まず、Azure SQL Database、Azure SQL Managed Instance、SQL database in Fabric、SQL Serverを横断して、どの環境がどの更新の影響を受けるかを一覧化してください。次に、GA機能はセキュリティ・運用標準への取り込み可否を検討し、Preview機能は検証環境でのみ評価する方針を明文化します。
特に優先すべき作業は、Microsoft Entra認証の棚卸し、TDEのCMK運用確認、TLS 1.2以上に対応したクライアント確認、AI_GENERATE_EMBEDDINGSのPoC、Fabric移行候補データベースの照合順序チェックです。Azure SQL の2026年前半の更新は、単なる機能追加ではなく、ID、暗号化、AI、イベント連携、分析基盤を一体で見直すきっかけになります。
すべてをすぐ導入する必要はありません。まずは「本番標準にできるGA機能」「検証にとどめるPreview機能」「既存環境で先に直すべきセキュリティ設定」を分け、運用チーム、開発チーム、セキュリティチームで同じ判断表を共有することから始めましょう。
[7]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Announcing-Full-Collation-Support-for-SQL-Databases-in-Microsoft/ba-p/5172032 “
Announcing Full Collation Support for SQL Database… – Microsoft Fabric Community
“
[8]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Introducing-Migration-assistant-for-SQL-database-in-Fabric/ba-p/5172048 “
Introducing Migration assistant for SQL database i… – Microsoft Fabric Community
“
コメント