Cumulative Update 4 for SQL Server 2025（KB5081495）をAzure SQL関連の更新として確認する場合、最初に押さえるべき結論は「Azure SQL Databaseに管理者が手動で適用する更新プログラムではない」という点です。KB5081495は、SQL Server 2025 on Windows／Linux向けの累積更新プログラムで、SQL Server本体のビルドを17.0.4035.5に更新し、CU3以降に提供された11件の修正を含みます。(Microsoft Learn)
一方で、Azure SQL Managed Instance、SQL Server on Azure VM、Azure Arc対応SQL Server、オンプレミスのSQL Server 2025を運用している場合は、影響範囲や確認ポイントが変わります。特に、SESSION_CONTEXTを使うアプリケーション、MSDASQL経由のリンクサーバー、Contained Availability Group、Full-Text Search、JSON関連機能を使っている環境では、適用前の検証を省略しないことが重要です。(Microsoft Learn)
Cumulative Update 4 for SQL Server 2025（KB5081495）の基本情報
KB5081495は、SQL Server 2025向けの4番目の累積更新プログラムです。公式ページでは、リリース日は2026年4月16日、バージョンは17.0.4035.5とされています。日本語版Microsoft Learnページは2026年5月27日に更新されています。(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 更新プログラム名 | Cumulative Update 4 for SQL Server 2025 |
| KB番号 | KB5081495 |
| 対象 | SQL Server 2025 on Windows、SQL Server 2025 on Linux |
| SQL Server製品バージョン | 17.0.4035.5 |
| SQL Serverファイルバージョン | 2025.170.4035.5 |
| Analysis Services製品バージョン | 17.0.25.223 |
| 含まれる修正 | SQL Server 2025 CU3以降の11件の修正 |
| 適用前提 | SQL Server 2025を実行していること |
| 再起動 | 適用後に必要になる場合あり |
| レジストリ変更 | 不要 |
注意したいのは、Microsoft Download Centerは常に最新のSQL Server 2025 CUを提供する、という点です。KB5081495を指定して検証・適用したい場合は、Microsoft Update Catalogや社内配布基盤で対象KBとビルド番号を確認してください。Microsoftの最新版一覧では、SQL Server 2025の累積更新としてCU5も掲載されているため、実運用では「CU4を適用するのか」「現時点の最新CUまで上げるのか」を切り分けて判断する必要があります。(Microsoft Learn)
Azure SQLでの影響は利用形態によって異なる
「Azure SQL」と一口に言っても、Azure SQL Database、Azure SQL Managed Instance、Azure VM上のSQL Serverでは管理責任が異なります。KB5081495の扱いも同じではありません。
| 利用形態 | KB5081495への対応 | 管理者が見るべきポイント |
|---|---|---|
| Azure SQL Database | 管理者がKB5081495を手動適用するものではない | メンテナンスウィンドウ、Service Health、アプリのリトライ設計 |
| Azure SQL Managed Instance | 更新ポリシーによってSQLエンジン機能や更新の受け取り方が変わる | ProductUpdateType、更新ポリシー、移行・フェールバック要件 |
| SQL Server on Azure VM | 通常のSQL ServerとしてCU適用対象になる | Azure Update Manager、WSUS、Microsoft Update Catalog、再起動計画 |
| Azure Arc対応SQL Server | 構成によって自動更新や手動適用を管理 | ホストOS単位の更新、重要／緊急更新とCUの扱い |
| オンプレミスSQL Server 2025 | 通常のSQL Server更新として適用 | 検証環境、バックアップ、ロールバック、アプリ回帰テスト |
Azure SQL Databaseはフルマネージドサービスであり、SQLやOSコードのパッチ適用・更新はMicrosoftが処理します。そのため、Azure SQL Databaseの管理者がKB5081495のインストーラーをダウンロードして適用する運用はありません。実務上は、メンテナンスイベントによる短時間の再構成に備え、接続リトライ、監視、メンテナンス通知を確認することが中心になります。(Microsoft Learn)
Azure SQL Managed Instanceでは、更新ポリシーが重要です。SQL Server 2025更新ポリシーを選ぶと内部データベース形式はSQL Server 2025に合わせられ、SQL Server 2025向けの最新更新を受け取ります。一方、Always-up-to-date更新ポリシーはAzure上の最新SQLエンジン機能をより早く利用できる反面、SQL Server 2022／2025更新ポリシーへ戻せないなど、移行・復旧面の制約があります。(Microsoft Learn)
SQL Server on Azure VMでは、KB5081495は通常のSQL Server累積更新プログラムとして扱います。Azure Update Managerを使うと、SQL Serverの累積更新やOS更新を管理できますが、Automated PatchingとAzure Update Managerを同時に使うとスケジュール競合や意図しない更新につながる可能性があるため、どちらで管理するかを統一してください。(Microsoft Learn)
CU4で修正された主な領域
KB5081495には11件の修正が含まれています。単に「修正が入った」と見るのではなく、自社環境で使っている機能に照らして優先度を付けるのが実務では重要です。(Microsoft Learn)
| 修正領域 | 主な内容 | 影響を確認すべき環境 |
|---|---|---|
| Database Mail | Contained Availability Groupでsp_RunMailQuery使用時、添付ファイルなしでメール送信される問題を修正 | CAGとDatabase Mailを併用している環境 |
msdb権限 | SQL Serverアップグレード時にmsdb内のストアドプロシージャなどの権限が失われる問題を修正 | SQL Server 2025へのアップグレード直後の環境 |
| Linux／SQLPAL | 内部スレッドが意図しない待機状態になり、応答停止につながる可能性を修正 | SQL Server 2025 on Linux |
| SSIS関連 | SSIS機能なしでSQL Serverをインストールした場合にDTSWizard.exeが開かない問題を修正 | インポート／エクスポートウィザードを使う管理端末 |
| Full-Text Search | 古いWord文書のインデックス作成や、特定言語の語形変化検索で発生する問題を修正 | フルテキスト検索を使う文書検索システム |
| CAG監査 | Contained Availability Groupの監査機能におけるメモリ破損を修正 | CAGと監査を併用する高可用性環境 |
| Windows Server 2025 | sys.dm_xe_session_targets照会時のアクセス違反を修正 | Windows Server 2025上のSQL Server |
| JSON | Json_containsの比較モードを0または1に制限 | SQL Server 2025のJSON機能を使う開発環境 |
| CAGのDB追加 | CAGへのデータベース追加制御を厳格化 | 複数CAGを管理するDBAチーム |
| レプリケーション／I/O | 大量のlazy writer I/O時に発生し得る非yielding schedulerやダンプを修正 | 高負荷I/O、レプリケーション環境 |
| Full-Text Searchの語形変化 | FREETEXT、FREETEXTTABLE、FORMSOF(INFLECTIONAL, ...)関連の失敗を修正 | 多言語検索、自然言語検索を使うアプリ |
管理者が特に確認したいのは、変更が「性能改善」だけではなく、権限、接続検証、CAGの操作制限、JSON関数の入力値制限にも及ぶ点です。たとえば、Json_containsに0または1以外の比較モードを渡しているテストコードや、CAGに対する自動デプロイスクリプトがある場合、CU適用後に挙動が変わる可能性があります。
既知の問題：SESSION_CONTEXTを使うアプリは優先確認
KB5081495の既知の問題として、SESSION_CONTEXTを使うクエリが並列実行プランで動作した場合に、不正な結果やアクセス違反ダンプが発生する可能性が示されています。特に、セッションが再利用のためにリセットされるケースで問題が起こり得ます。(Microsoft Learn)
SESSION_CONTEXTは、接続単位で値を保持し、アプリケーション側のユーザーID、テナントID、処理モードなどをSQL Server側に渡す用途で使われることがあります。以下のような実装がある場合は、CU適用前に確認してください。
SELECT
OBJECT_SCHEMA_NAME(object_id) AS schema_name,
OBJECT_NAME(object_id) AS object_name
FROM sys.sql_modules
WHERE definition LIKE '%SESSION_CONTEXT%';確認すべきポイントは、単に該当コードがあるかどうかではありません。大きな結合、集計、検索条件を含むクエリで並列プランが発生していないか、コネクションプールを使うアプリケーションでセッション値の初期化が適切か、負荷テスト時に想定外の結果やダンプが出ていないかを見ます。
MicrosoftのSESSION_CONTEXTドキュメントでは、回避策としてトレースフラグ11042によりSESSION_CONTEXTを直列実行させる方法が示されています。ただし、トレースフラグはクエリ性能に影響する可能性があるため、本番環境へ入れる前に対象ワークロードで必ず検証してください。(Microsoft Learn)
既知の問題：MSDASQLリンクサーバーはエラー7416に注意
もう1つ重要な既知の問題が、MSDASQLを使うリンクサーバークエリです。OLE DB Provider for ODBC DriversであるMSDASQLを使い、プロバイダー文字列@provstrを指定している構成では、エラー7416が発生する場合があります。エラーメッセージは「ログインマッピングが存在しないため、リモートサーバーへのアクセスが拒否された」という内容です。(Microsoft Learn)
この問題は、SQL Server 2025の2026年4月以降のCU／GDR更新に加え、Azure SQL Managed Instanceにも関係します。原因は、Database Engine側の接続検証がより厳格になったことです。以前のビルドでは許可されていた構成でも、CU適用後に失敗する場合があります。(Microsoft Learn)
実務での確認ポイントは次のとおりです。
| 確認項目 | 内容 |
|---|---|
| リンクサーバーの有無 | MSDASQLプロバイダーを使っているか確認する |
@provstrの使用 | プロバイダー文字列を指定しているリンクサーバーを抽出する |
| 実行ユーザー | sysadmin以外のユーザーで実行される業務処理をテストする |
| 回避策 | 不要であれば@provstrを削除する、またはUser IDを追加する |
| 避けたい対応 | 影響ユーザーへ安易にsysadmin権限を付与する |
Microsoftは回避策として、構成上不要であれば@provstrを削除する方法、または@provstrにUser IDを追加する方法を示しています。一方、sysadmin権限を付与すれば回避できる場合があるものの、推奨されていません。(Microsoft Learn)
適用前に管理者が確認すべきこと
CU適用で失敗しやすいのは、更新プログラムそのものよりも「適用対象の把握不足」です。特にAzure環境では、PaaS、IaaS、Managed Instance、Arc管理のSQL Serverが混在しやすいため、最初に資産を分類してください。
| 手順 | 確認内容 | 具体的な作業 |
|---|---|---|
| 現状把握 | どのSQLサービスかを分類する | Azure SQL Database、Managed Instance、Azure VM、Arc、オンプレを分ける |
| バージョン確認 | 現在のSQL Serverビルドを確認する | SERVERPROPERTYや管理ツールで確認 |
| 影響機能の抽出 | 既知の問題や修正対象機能を使っているか確認 | SESSION_CONTEXT、MSDASQL、CAG、Full-Text Search、JSON、Replication |
| 検証環境で適用 | 本番相当のクエリとジョブを実行 | SQL Agent、ETL、帳票、夜間バッチを含める |
| メンテナンス計画 | 停止・再起動・フェールオーバーを考慮 | 業務影響の少ない時間帯を設定 |
| 適用後確認 | エラー、性能、権限、ジョブを確認 | Query Store、SQL Server Error Log、アプリログを確認 |
SQL Serverのビルド確認には、次のようなT-SQLを使えます。
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel,
SERVERPROPERTY('ProductUpdateReference') AS ProductUpdateReference;Azure SQL Managed Instanceの更新ポリシーを確認する場合は、次のT-SQLが有効です。
SELECT SERVERPROPERTY('ProductUpdateType') AS ProductUpdateType;ProductUpdateTypeがCUであれば、対応するSQL Serverメジャーバージョンの累積更新によって更新されます。Continuousであれば、Always-up-to-date更新ポリシーにより、SQL Serverのリリース周期とは独立して新機能が提供されます。(Microsoft Learn)
Azure SQL Managed Instanceでは更新ポリシーと移行経路を確認する
Azure SQL Managed Instanceで最も見落としやすいのは、更新ポリシーが将来の移行・復旧設計に影響する点です。
SQL Server 2025更新ポリシーでは、内部データベース形式がSQL Server 2025に合わせられます。この場合、Azure SQL Managed InstanceからSQL Server 2025へデータベースを復元でき、SQL Server 2025とのManaged Instance linkによるリアルタイムレプリケーション、双方向フェールオーバー、災害対策構成を利用できます。(Microsoft Learn)
一方、Always-up-to-date更新ポリシーは、Azure SQL Managed Instanceで利用可能な最新機能を早く取り込める反面、いったん有効化するとSQL Server 2022またはSQL Server 2025更新ポリシーへ戻せません。また、SQL Server 2022／2025とのデータベース形式整合性に基づく復元や双方向フェールオーバーの利点を失う場合があります。(Microsoft Learn)
移行や災害対策を考えている場合は、次の判断基準で選ぶと実務的です。
| 要件 | 選びやすい更新ポリシー |
|---|---|
| SQL Server 2025との復元・フェールバックを重視する | SQL Server 2025更新ポリシー |
| 最新のAzure SQL機能を開発環境で早く試したい | Always-up-to-date更新ポリシー |
| SQL Server 2022との互換性を重視する | SQL Server 2022更新ポリシー |
| 将来要件がまだ固まっていない | いきなりAlways-up-to-dateにせず、戻せない変更を避ける |
デプロイテンプレートやIaCを使ってManaged Instanceを作成している場合は、更新ポリシーを明示的に設定してください。Microsoftは、将来変わる可能性のあるシステム既定値に依存しないよう、デプロイテンプレートに更新ポリシー構成を追加することを推奨しています。(Microsoft Learn)
Azure SQL Databaseではメンテナンスとリトライ設計が重要
Azure SQL Databaseでは、管理者がKB5081495を直接適用するのではなく、Microsoftがサービス側で更新を行います。ただし、更新が完全に無視できるわけではありません。計画メンテナンス中に短時間の再構成が発生し、アプリケーションが再接続を求められることがあります。(Microsoft Learn)
Microsoftのドキュメントでは、計画メンテナンス時の再構成は一般に短時間で完了し、アプリケーション側では新しいプライマリレプリカへ再接続する必要があると説明されています。長時間クエリは再構成時に中断される可能性があるため、夜間バッチや大量データ処理ではリトライ可能な設計にしておくことが重要です。(Microsoft Learn)
本番ワークロードでは、次を確認してください。
| 確認項目 | 実務上のポイント |
|---|---|
| メンテナンスウィンドウ | 業務ピーク外に設定できるか確認する |
| 事前通知 | 非既定のメンテナンスウィンドウでは事前通知を活用する |
| 接続リトライ | 一時的な接続断、エラー40613などを想定する |
| 長時間処理 | バッチやETLを再実行可能にする |
| Service Health | 計画メンテナンスやサービス状態を監視する |
Azure SQL Databaseのメンテナンスウィンドウは、計画された更新による影響を予測しやすくするための機能です。ただし、ハードウェア障害や負荷分散、サービスレベル変更など、すべてのフェールオーバー要因を防ぐものではありません。(Microsoft Learn)
SQL Server on Azure VMではAzure Update Managerの設計を見直す
SQL Server on Azure VMでは、Azure SQL Databaseとは違い、SQL ServerのCU適用は管理者側の運用設計に含まれます。Azure Update Managerを使うと、複数VMの更新評価、オンデマンド更新、メンテナンスウィンドウに合わせたスケジュール適用ができます。(Microsoft Learn)
特に注意したいのは、Azure Update ManagerとAutomated Patchingを併用しないことです。両方を有効にすると、想定外のスケジュール競合やメンテナンスウィンドウ外の変更につながる可能性があります。Azure Update Managerへ統一する場合は、Automated Patchingを無効化したうえで運用してください。(Microsoft Learn)
適用計画では、以下を事前に決めておくとトラブルを減らせます。
| 項目 | 決めること |
|---|---|
| 配布方法 | Azure Update Manager、WSUS、Microsoft Update Catalog、手動適用のどれを使うか |
| 適用単位 | 単一VM、可用性グループ単位、環境単位のどれで進めるか |
| 再起動 | OS再起動が必要になった場合の業務影響 |
| ロールバック | アンインストール手順、バックアップ、スナップショット方針 |
| 監視 | SQL Server Error Log、Windowsイベントログ、アプリ監視の確認項目 |
ダウンロードとファイル検証で確認すべき点
KB5081495を固定で扱う場合、ビルド番号とファイルハッシュを確認します。Microsoft Learnでは、SQLServer2025-KB5081495-x64.exeのSHA256ハッシュ確認コマンドとして、次の形式が示されています。(Microsoft Learn)
certutil -hashfile SQLServer2025-KB5081495-x64.exe SHA256公式ページに掲載されているSHA256ハッシュは次の値です。
E8050B7619939C6C0F2CA352DA50F8659F0BEFD63798A4EDC84210F084EA199B社内配布サーバーや構成管理ツールに登録する場合は、ファイル名だけでなく、KB番号、ビルド番号、ハッシュ値を記録しておくと、後から「どの更新をどの環境へ入れたか」を追跡しやすくなります。
適用後に確認すべきテスト項目
CU適用後の確認は、SQL Serverが起動するかどうかだけでは不十分です。今回の修正内容と既知の問題を踏まえると、次のテストを優先するのが現実的です。
| テスト対象 | 確認内容 |
|---|---|
| アプリケーション接続 | 接続プール再利用時にセッション値が正しく初期化されるか |
SESSION_CONTEXT利用クエリ | 並列プランが発生する重いクエリで結果が正しいか |
| リンクサーバー | MSDASQLと@provstrを使う処理がエラー7416にならないか |
| SQL Agentジョブ | 夜間バッチ、ETL、レポート出力が正常完了するか |
| Database Mail | 添付ファイル付きメール送信が正しく動作するか |
| Full-Text Search | インデックス作成、FREETEXT、語形変化検索が失敗しないか |
| JSON処理 | Json_containsの比較モード指定が0または1に収まっているか |
| 高可用性構成 | Always On、CAG、レプリケーションで同期・フェールオーバーに異常がないか |
| 権限 | msdb内のストアドプロシージャ、ジョブ、運用ユーザー権限が維持されているか |
特に、権限とリンクサーバーは本番適用後に初めて発覚しやすい領域です。管理者アカウントでの疎通確認だけで終わらせず、実際のアプリケーション実行ユーザー、SQL Agentプロキシ、運用用ログインで確認してください。
失敗しやすいポイント
KB5081495の適用で失敗しやすいのは、次のようなケースです。
| 失敗パターン | 起こり得る問題 | 対策 |
|---|---|---|
| Azure SQL Databaseにも手動適用が必要だと誤解する | 不要な作業計画を作ってしまう | Azure SQL DatabaseはMicrosoft管理の更新であると整理する |
| CU4と最新CUを混同する | 検証したビルドと本番適用ビルドがずれる | KB番号とビルド番号をセットで管理する |
| Download Centerから取得したファイルをCU4と思い込む | 最新CUを取得してしまう可能性がある | CU4固定ならMicrosoft Update Catalogや社内承認済みファイルを使う |
SESSION_CONTEXTを検索しない | 並列プラン時の不具合を見逃す | DB内モジュールとアプリSQLの両方を確認する |
| リンクサーバーをsysadminだけでテストする | 一般実行ユーザーでエラー7416が発生する | 実行ユーザーごとにテストする |
| Azure Update ManagerとAutomated Patchingを併用する | 更新タイミングが競合する | 更新管理の仕組みを1つに統一する |
| CU適用後に機能追加して再適用しない | 後から追加した機能がCU水準にならない | SQL Server機能追加後はCU再適用を検討する |
SQL ServerのCUパッケージは、対象インスタンスに現在インストールされているコンポーネントだけを更新します。たとえばCU適用後にAnalysis Servicesなどの機能を追加した場合、その新しい機能を同じCU水準にするにはCUを再適用する必要があります。(Microsoft Learn)
次に取るべきアクション
Azure SQL Databaseを使っている場合は、KB5081495のインストーラー適用ではなく、メンテナンスウィンドウ、事前通知、Service Health、アプリケーションのリトライ設計を確認してください。
Azure SQL Managed Instanceを使っている場合は、まずSERVERPROPERTY('ProductUpdateType')で更新ポリシーを確認し、SQL Server 2025更新ポリシー、SQL Server 2022更新ポリシー、Always-up-to-dateのどれで運用しているかを把握します。そのうえで、SQL Server 2025との復元・フェールバック要件があるか、将来の移行経路に制約が出ないかを確認してください。
SQL Server on Azure VM、Azure Arc対応SQL Server、オンプレミスSQL Server 2025を運用している場合は、現在のビルド番号を確認し、CU4を固定で適用するのか、最新CUまで上げるのかを決めます。その後、SESSION_CONTEXT、MSDASQLリンクサーバー、Contained Availability Group、Full-Text Search、JSON処理、レプリケーションを中心に検証し、メンテナンスウィンドウ内で段階的に展開するのが安全です。
KB5081495は小さな修正の集合に見えますが、認証・権限・接続検証・高可用性・検索・JSONといった実運用に近い領域へ影響します。まずは自社環境で使っている機能を棚卸しし、ビルド番号、更新ポリシー、既知の問題、適用後テストを1つのチェックリストにまとめることから始めてください。
コメント