Windows 11版別.NET 7月KB対応表｜23H2～26H1の正しい更新番号と配布手順

2026年7月のWindows 11向け.NET Framework累積更新は、OSのバージョンごとにKB番号が異なります。結論として、23H2はKB5101004、24H2はKB5101001、25H2はKB5100998、26H1はKB5101002です。4つのKBを全端末へ一括配布するのではなく、各端末のWindows 11バージョンに一致するKBを割り当てます。(マイクロソフトサポート)

更新前には.NET Frameworkを使用しているアプリやサービスを終了します。更新対象ファイルが使用中だった場合は再起動が必要になるため、業務端末でも再起動可能なメンテナンス時間を確保しておくことが重要です。(マイクロソフトサポート)

Windows 11版別.NET 7月KB対応表

2026年7月14日に公開された.NET Framework更新プログラムの対応関係は、次のとおりです。

Windows 11のバージョン	配布する.NET KB	Microsoft Support上の対象	手動ダウンロード時のアーキテクチャ
Windows 11 23H2	KB5101004	.NET Framework 3.5、4.8.1	x64、Arm64
Windows 11 24H2	KB5101001	.NET Framework 3.5、4.8.1	x64、Arm64
Windows 11 25H2	KB5100998	.NET Framework 3.5、4.8.1	x64、Arm64
Windows 11 26H1	KB5101002	Microsoft Supportでは4.8.1	x64、Arm64

Microsoft Update Catalogでも、23H2、24H2、25H2、26H1ごとに異なるパッケージが登録されています。同じKB番号の中でもx64版とArm64版が分かれているため、手動配布ではOSバージョンだけでなくアーキテクチャも確認してください。(Microsoft Update Catalog)

判断基準は、次のように整理できます。

23H2端末にはKB5101004
24H2端末にはKB5101001
25H2端末にはKB5100998
26H1端末にはKB5101002
x64端末にはx64パッケージ
Arm64端末にはArm64パッケージ

OSバージョンを第一キー、アーキテクチャを第二キーとして配布対象を決めると、誤配布を防ぎやすくなります。

23H2端末ではエディションも確認する

Windows 11 23H2のHomeおよびProは、2025年11月11日にサービスを終了しています。一方、EnterpriseおよびEducationは2026年11月10日まで月例セキュリティ更新を受け取ります。(Microsoft Learn)

そのため、23H2端末が見つかった場合は、KB5101004を配るだけでなくエディションも確認します。

23H2のエディション	実務上の対応
Enterprise、Education	KB5101004の配布対象として管理
Home、Pro	OS自体がサービス終了済みのため、25H2などへの移行を優先

サービス終了済みのOSに.NET Framework更新を適用しても、Windows 11全体がサポート対象に戻るわけではありません。

26H1はMicrosoft SupportとCatalogの表記差に注意する

26H1向けKB5101002には、Microsoft公式ページ間で表記差があります。

Microsoft Supportの記事では「.NET Framework 4.8.1向け」と記載され、前提条件も.NET Framework 4.8.1です。一方、Microsoft Update Catalogのパッケージ名は「.NET Framework 3.5 and 4.8.1」と表示されています。どちらも26H1向けの識別子はKB5101002です。(マイクロソフトサポート)

また、Microsoft Update Catalogでは、KB5101002のx64版が「Windows Insider Pre-Release」、Arm64版が「Windows 11」と表示されています。配布ツールで製品名だけをフィルター条件にすると、x64パッケージを見落とす可能性があります。KB5101002、version 26H1、x64またはArm64という3点を確認してください。(Microsoft Update Catalog)

なぜWindows 11の版ごとにKBが異なるのか

今回の4つの更新は、修正内容の大部分が共通しています。しかし、Windows 11の各バージョンでは、搭載されるコンポーネントやサービス基盤が異なります。そのため、.NET Framework servicingではOSバージョンごとに別の更新パッケージが用意されています。

KB番号が分かれている以上、次のような運用は避けるべきです。

最新OS用のKBを古いバージョンにも配る
KB5100998を24H2と25H2の両方に配る
4つのKBを全Windows 11端末へ無条件に割り当てる
Microsoft Update Catalogからx64版だけをダウンロードし、Arm64端末にも配る

Windows UpdateやWSUSでは適用性判定によって対象外になることがあります。しかし、不要な割り当てはコンプライアンスレポートを分かりにくくし、手動インストールや独自配布ツールでは「この更新プログラムはお使いのコンピューターには適用できません」といった失敗につながります。

自社端末のWindows 11バージョンを確認する方法

1台だけ確認する場合

キーボードのWindowsキーとRキーを押し、次のコマンドを実行します。

winver

表示された画面の「バージョン」で、23H2、24H2、25H2、26H1のいずれかを確認します。

アーキテクチャは、Windows 11の「設定」から次の順に確認できます。

設定
→ システム
→ バージョン情報
→ システムの種類

「64ビットオペレーティングシステム、x64ベースプロセッサ」であればx64版、「ARMベースプロセッサ」であればArm64版を選びます。

PowerShellで必要なKBまで判定する

複数の情報を一度に確認したい場合は、PowerShellで次のスクリプトを実行します。

$cv = Get-ItemProperty `
    'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

$kbMap = @{
    '23H2' = 'KB5101004'
    '24H2' = 'KB5101001'
    '25H2' = 'KB5100998'
    '26H1' = 'KB5101002'
}

$displayVersion = $cv.DisplayVersion

$expectedKb = if ($kbMap.ContainsKey($displayVersion)) {
    $kbMap[$displayVersion]
} else {
    '対象外または要確認'
}

[pscustomobject]@{
    ComputerName     = $env:COMPUTERNAME
    Edition          = $cv.EditionID
    WindowsVersion   = $displayVersion
    OSBuild          = "$($cv.CurrentBuild).$($cv.UBR)"
    Architecture     = (Get-CimInstance Win32_OperatingSystem).OSArchitecture
    ExpectedDotNetKB = $expectedKb
}

24H2端末で実行した場合は、次のように必要なKBが表示されます。

ComputerName     : PC-001
Edition          : Enterprise
WindowsVersion   : 24H2
OSBuild          : 26100.xxxx
Architecture     : 64 ビット
ExpectedDotNetKB : KB5101001

この結果をCSVへ出力すれば、配布グループを作成するための棚卸しにも利用できます。

管理対象が多い場合

数十台以上を管理している場合は、Intune、Configuration Manager、WSUS、資産管理ツールなどから、少なくとも次の項目を抽出します。

必要な情報	使用目的
デバイス名	配布結果の追跡
WindowsのDisplayVersion	配布するKBの決定
エディション	23H2のサポート状態確認
OSアーキテクチャ	x64、Arm64パッケージの選択
更新管理方式	WUfB、WSUS、手動配布の切り分け
業務アプリの種類	パイロット対象と再起動時間の決定

「Windows 11」という製品名だけでグループ化してはいけません。23H2から26H1までが混在している環境では、必ずDisplayVersionでコレクションやデバイスグループを分けます。

2026年7月.NET更新の主な変更点

セキュリティ修正

今回の更新では、Microsoft Support上で17件のCVEが案内されています。内容には、サービス拒否、セキュリティ機能のバイパス、特権昇格、改ざん、リモートコード実行に関する脆弱性が含まれます。

特にCVE-2026-50649は、.NET Frameworkのリモートコード実行脆弱性として記載されています。このため、単なる動作品質の改善だけではなく、通常のセキュリティ更新として配布判断が必要です。(マイクロソフトサポート)

Microsoft側の案内状態が「情報提供」と表示されていても、Microsoft Update CatalogやWSUS上の分類は「Security Updates」です。「情報提供だから配布しなくてよい」と判断せず、通常の月例パッチ運用に組み込むのが適切です。(Microsoft Update Catalog)

HttpWebRequestが停止する問題を修正

.NETライブラリでは、同期型のHttpWebRequest接続が、特定のサーバー構成を使用したセキュア接続で停止することがある問題が修正されています。(マイクロソフトサポート)

次のような業務アプリでは、更新後の確認を優先します。

HTTPSで外部APIを呼び出す.NET Frameworkアプリ
プロキシサーバーを経由するクライアント
古い社内システムと同期通信するデスクトップアプリ
認証付きWebサービスへ接続するバッチ処理
長時間稼働するWindowsサービス

今回の修正によってハングが解消される可能性がありますが、接続先サーバー、TLS設定、プロキシ、タイムアウト処理の組み合わせによって動作が変わることがあります。代表的な接続先を含むテストを実施してください。

Visual Studioのx86ネイティブデバッガーを修正

.NET Runtimeでは、Visual Studioのx86ネイティブデバッガーを使って混合コードアプリをステップ実行した際、一部の浮動小数点値が正しく表示されない問題が修正されています。(マイクロソフトサポート)

影響を受けやすいのは、次の環境です。

x86でビルドされた業務アプリ
C++と.NETを組み合わせた混合コード
浮動小数点計算をデバッグする開発端末
古いVisual Studioプロジェクトを保守している環境

通常利用者の画面や操作方法が大きく変わる更新ではありません。ただし、開発端末ではデバッガーの表示結果が変わるため、過去の調査結果と比較する際に注意が必要です。

Microsoftが把握している既知の問題

Microsoftは、23H2、24H2、25H2、26H1向けの各更新について、現時点では既知の問題を認識していないとしています。(マイクロソフトサポート)

ただし、「既知の問題なし」は、すべての業務アプリで動作保証されているという意味ではありません。独自開発アプリ、古い.NET Frameworkアプリ、プリンターやスキャナーと連携するシステム、常時稼働サービスでは、代表端末を使ったパイロット配布が必要です。

更新前に確認すること

配布を開始する前に、次の項目を確認します。

確認項目	判断基準
Windows 11バージョン	23H2、24H2、25H2、26H1のどれか
エディション	23H2の場合はEnterpriseまたはEducationか
アーキテクチャ	x64かArm64か
.NET Frameworkの利用状況	デスクトップアプリ、サービス、IIS、バッチの有無
メンテナンス時間	アプリ停止と再起動が可能か
パイロット端末	本番と同じアプリ構成を持つか
配布後の確認担当	IT部門とアプリ担当者を決めているか

.NET Framework 3.5の有効状態を確認する

.NET Framework 3.5の状態は、管理者権限でPowerShellを開き、次のコマンドで確認できます。

Get-WindowsOptionalFeature `
    -Online `
    -FeatureName NetFx3 |
    Select-Object FeatureName, State

23H2、24H2、25H2向け更新の前提条件は、.NET Framework 3.5または4.8.1がインストールされていることです。26H1向けのMicrosoft Support記事では、.NET Framework 4.8.1が前提条件とされています。(マイクロソフトサポート)

更新のためだけに.NET Framework 3.5を新たに有効化する必要はありません。実際に有効になっているコンポーネントと、更新プログラムの適用性判定に従います。

管理方法別の配布手順

Windows UpdateとWindows Update for Business

Windows UpdateおよびWindows Update for Businessでは、更新プログラムが利用可能であり、端末の適用性に応じてダウンロード、インストールされます。(マイクロソフトサポート)

企業環境では、次の順序で展開します。

IT部門とアプリ管理者の検証端末
各部門の代表端末
一般業務端末
重要業務端末
常時稼働端末

更新リングを分けても、24H2と25H2を同じリング内で管理することは可能です。ただし、レポート上ではOSバージョン別に正しいKBが入っているか確認してください。

WSUSとConfiguration Manager

各更新はWSUSから同期可能で、分類は「Security Updates」です。(マイクロソフトサポート)

実務では、次のようにデバイスコレクションを分けます。

Windows 11 23H2 → KB5101004
Windows 11 24H2 → KB5101001
Windows 11 25H2 → KB5100998
Windows 11 26H1 → KB5101002

WSUSでは適用性判定が行われますが、承認対象はOSバージョンごとに分けた方が、未適用理由やエラーを追跡しやすくなります。

26H1を管理する場合は、製品フィルターだけでなく更新タイトルとKB5101002も確認します。特にMicrosoft Update Catalogのx64版では製品表示がほかのアーキテクチャと異なるため、同期結果や検索条件を確認してください。

Microsoft Update Catalogから手動配布する場合

閉域環境や独自配布ツールで更新する場合は、Microsoft Update CatalogでKB番号を検索します。

選択時には、次の3項目が一致していることを確認します。

KB番号
Windows 11のバージョン
x64またはArm64

例えば24H2のx64端末では、単にKB5101001を検索するだけでなく、パッケージ名に次の要素が含まれていることを確認します。

.NET Framework 3.5 and 4.8.1
Windows 11, version 24H2
x64
KB5101001

ファイル名だけを見て判断せず、Catalogのタイトル、製品、アーキテクチャを確認してから社内配布システムへ登録します。

更新時に停止しておくアプリとサービス

Microsoftは、更新前にすべての.NET Frameworkベースのアプリを終了することを推奨しています。対象ファイルが使用されている場合は、更新後に再起動が必要です。(マイクロソフトサポート)

停止対象には、画面上で開いているアプリだけでなく、バックグラウンドで動作するものも含まれます。

.NET Framework製のデスクトップアプリ
Windowsサービス
IISのアプリケーションプール
タスクスケジューラから実行されるバッチ
常駐型の業務クライアント
帳票、会計、在庫、勤怠などの業務システム
Visual Studioでデバッグ中のアプリ

常時稼働システムでは、アプリ担当者と停止手順を確認してから更新します。アプリを停止できない状態で無理に適用すると、更新途中でファイルがロックされ、想定外のタイミングで再起動を要求される可能性があります。

適用後に確認すること

更新後は、単にWindows Updateが終了したことだけでなく、正しいKBが適用され、業務アプリが正常に動作することまで確認します。

正しいKBが記録されているか確認する

端末の「設定」から、次の順に更新履歴を開きます。

設定
→ Windows Update
→ 更新の履歴

端末のバージョンに対応するKBを検索します。

Windows 11のバージョン	確認するKB
23H2	KB5101004
24H2	KB5101001
25H2	KB5100998
26H1	KB5101002

PowerShellからWindows Updateの履歴を検索する場合は、次のスクリプトを利用できます。

$kbPattern = 'KB5101004|KB5101001|KB5100998|KB5101002'

$searcher = (
    New-Object -ComObject Microsoft.Update.Session
).CreateUpdateSearcher()

$total = $searcher.GetTotalHistoryCount()

$searcher.QueryHistory(0, $total) |
    Where-Object { $_.Title -match $kbPattern } |
    Select-Object Date, Title, ResultCode

同じKBが複数回表示される場合は、失敗後に再試行された可能性があります。最新の実行日時と結果を確認してください。

業務アプリのスモークテストを行う

適用後は、少なくとも次の操作を確認します。

アプリを正常に起動できる
ユーザー認証が成功する
データベースへ接続できる
HTTPSの外部APIへ接続できる
印刷や帳票出力ができる
Windowsサービスが起動している
IISアプリへアクセスできる
定期バッチが正常終了する
x86混合コードのデバッグ結果に問題がない

特にHttpWebRequestを利用するシステムでは、通常接続だけでなく、プロキシ経由、認証付き接続、タイムアウト時の処理まで確認すると安全です。

配布で失敗しやすいポイント

24H2と25H2を同じKBだと思い込む

24H2と25H2は別の.NET Framework KBです。

24H2：KB5101001
25H2：KB5100998

端末名や導入時期では判断せず、DisplayVersionを確認してください。

Windows本体の累積更新KBと混同する

Windows本体の累積更新と.NET Frameworkの累積更新は、別のKBとして管理されます。

Windows本体の更新が成功していても、.NET Framework更新が失敗または保留になっている可能性があります。コンプライアンスレポートでは、OS更新と.NET更新を分けて確認してください。

Arm64端末にx64パッケージを配る

Copilot+ PCなどではArm64端末が含まれることがあります。PCの外観やメーカー名では判断できないため、「システムの種類」または管理ツールのアーキテクチャ情報を確認します。

再起動不要と決めつける

再起動は常に必須ではありませんが、対象ファイルが使用中であれば必要です。

.NET Frameworkアプリ、Windowsサービス、IISが稼働している企業端末では、再起動が発生する前提で利用者へ案内した方が安全です。

既知の問題なしを理由に検証を省略する

Microsoftが既知の問題を認識していなくても、自社独自アプリとの組み合わせまでは保証されません。代表的な業務アプリを搭載した端末へ先行配布し、少なくとも1回の業務サイクルを確認してから全社展開します。

まとめ

2026年7月のWindows 11向け.NET Framework更新では、端末のOSバージョンに応じて次のKBを配布します。

23H2 → KB5101004
24H2 → KB5101001
25H2 → KB5100998
26H1 → KB5101002

配布作業では、まずDisplayVersionとアーキテクチャを棚卸しし、OSバージョン別のグループを作成します。その後、代表端末へパイロット配布し、.NET Frameworkを使用するアプリやサービスを停止したうえで本番展開します。

適用後は、正しいKBのインストール結果、再起動状態、HTTPS通信、業務アプリ、Windowsサービス、IIS、バッチ処理を確認します。特に23H2ではエディションのサポート状態、26H1ではMicrosoft公式ページ間の表記差にも注意してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows 11版別.NET 7月KB対応表｜23H2～26H1の正しい更新番号と配布手順

Windows 11版別.NET 7月KB対応表

23H2端末ではエディションも確認する

26H1はMicrosoft SupportとCatalogの表記差に注意する

なぜWindows 11の版ごとにKBが異なるのか

自社端末のWindows 11バージョンを確認する方法

1台だけ確認する場合

PowerShellで必要なKBまで判定する

管理対象が多い場合

2026年7月.NET更新の主な変更点

セキュリティ修正

HttpWebRequestが停止する問題を修正

Visual Studioのx86ネイティブデバッガーを修正

Microsoftが把握している既知の問題

更新前に確認すること

.NET Framework 3.5の有効状態を確認する

管理方法別の配布手順

Windows UpdateとWindows Update for Business

WSUSとConfiguration Manager

Microsoft Update Catalogから手動配布する場合

更新時に停止しておくアプリとサービス

適用後に確認すること

正しいKBが記録されているか確認する

業務アプリのスモークテストを行う

配布で失敗しやすいポイント

24H2と25H2を同じKBだと思い込む

Windows本体の累積更新KBと混同する

Arm64端末にx64パッケージを配る

再起動不要と決めつける

既知の問題なしを理由に検証を省略する

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows 11版別.NET 7月KB対応表｜23H2～26H1の正しい更新番号と配布手順

Windows 11版別.NET 7月KB対応表

23H2端末ではエディションも確認する

26H1はMicrosoft SupportとCatalogの表記差に注意する

なぜWindows 11の版ごとにKBが異なるのか

自社端末のWindows 11バージョンを確認する方法

1台だけ確認する場合

PowerShellで必要なKBまで判定する

管理対象が多い場合

2026年7月.NET更新の主な変更点

セキュリティ修正

HttpWebRequestが停止する問題を修正

Visual Studioのx86ネイティブデバッガーを修正

Microsoftが把握している既知の問題

更新前に確認すること

.NET Framework 3.5の有効状態を確認する

管理方法別の配布手順

Windows UpdateとWindows Update for Business

WSUSとConfiguration Manager

Microsoft Update Catalogから手動配布する場合

更新時に停止しておくアプリとサービス

適用後に確認すること

正しいKBが記録されているか確認する

業務アプリのスモークテストを行う

配布で失敗しやすいポイント

24H2と25H2を同じKBだと思い込む

Windows本体の累積更新KBと混同する

Arm64端末にx64パッケージを配る

再起動不要と決めつける

既知の問題なしを理由に検証を省略する

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル