Windows 11 バージョン 24H2を導入した一部の環境で、エクスプローラーやスタートメニューなどのUIが起動しない不具合が確認されています。
Microsoftはサポート文書「KB5072911」を通じて原因を「XAML依存パッケージの登録遅延」と説明し、手動登録やログオンスクリプトによる回避策を提示しました。
本記事では、問題の仕組み、発生しやすい条件、そして回避策の更新内容（2026年1月修正版）を整理し、現場で安定運用するための実装ポイントを分かりやすく解説します。
企業端末やVDI環境でWindows 11を運用する管理者にとって必読の、実務的トラブルシューティングガイドです。
Windows 11 24H2で発生しているUI不具合の概要
ここでは、Windows 11 バージョン 24H2で報告されているUI（ユーザーインターフェース）不具合の全体像を整理します。
特に、エクスプローラーやスタートメニューが起動しないといった深刻な症状が確認されており、管理端末や仮想環境での影響が注目されています。
Explorerやスタートメニューが起動しない症状とは
Microsoftが確認している主な症状は、Windowsのログオン後に画面が黒いまま操作できない、スタートメニューが反応しない、タスクバーが消えるなどです。
これらの現象は、Explorer.exeやStartMenuExperienceHost.exe、ShellHost.exeなどのプロセスが正常に初期化されないことによって発生します。
多くの場合、ユーザーがサインインした直後に発生し、再起動しても改善しないことがあります。
症状が表面的には「黒い画面」や「UIが固まる」だけに見えるため、ハードウェアトラブルやGPUドライバーの問題と誤認されやすい点も注意が必要です。
| 主な症状 | 発生タイミング | 関連プロセス |
|---|---|---|
| 黒い画面でログオン停止 | 初回ログオン直後 | Explorer.exe |
| スタートメニューが開かない | 更新後のセッション開始時 | StartMenuExperienceHost.exe |
| タスクバーが表示されない | UI初期化フェーズ | ShellHost.exe |
この問題は、単一のアプリ障害ではなく、WindowsのUI全体の初期化プロセスが途中で止まることに起因しています。
そのため、ユーザー操作だけで解決できるケースは少なく、システム管理者による技術的対処が必要です。
影響する環境 ― 非永続OSやプロビジョニング端末で多発
Microsoftの説明によると、このUI不具合は一般的な個人端末ではなく、管理対象デバイスや仮想デスクトップ（VDI）環境で多く報告されています。
特に、プロビジョニング直後や更新プログラム適用後の初回ログオン時に発生しやすい傾向があります。
この条件下では、OS構成要素の登録処理がユーザーログオンと同時進行するため、依存パッケージの登録が完了する前にUIが起動しようとして失敗します。
| 環境タイプ | 特徴 | 発生リスク |
|---|---|---|
| 非永続OS（VDIなど） | ログオンごとに新規イメージを展開 | 高 |
| プロビジョニング済み端末 | 展開直後に初回ログオンが走る | 中 |
| 個人利用PC | 更新後も永続環境で保持 | 低 |
つまり、影響範囲は限定的でありながら、発生した場合の影響は非常に大きいという性質を持ちます。
そのため、企業IT部門では更新管理ポリシーの見直しや、初回ログオン手順の調整が求められています。
次章では、この問題の根本原因である「XAML依存パッケージ登録の遅延」について、構造的な視点から解説します。
原因の正体 ― XAML依存パッケージの登録遅延
この章では、Windows 11 24H2でUIが起動しなくなる根本原因について解説します。
Microsoftの公式説明によると、問題の核心は「XAML関連パッケージが正しく登録されないこと」にあります。
つまり、更新プログラムの適用後にUI構成要素が依存しているコンポーネントの登録が遅れ、結果としてエクスプローラーなどが起動できなくなる仕組みです。
XAMLとは何か（Windows UIの基盤構造）
XAML（Extensible Application Markup Language：拡張アプリケーションマークアップ言語）は、WindowsのUIを定義するためのXMLベースの言語です。
スタートメニューやタスクバー、設定アプリといったWindows 11の主要UIは、このXAMLコンポーネントを通じて描画されています。
これらの要素は「Microsoft.UI.Xaml.CBS」などの依存パッケージを介して構成されており、OSのUI全体がモジュール的に組み立てられています。
| パッケージ名 | 役割 | 関連するUI要素 |
|---|---|---|
| MicrosoftWindows.Client.CBS | Windowsクライアントの中核UIコンポーネント | シェル全体（Explorer、タスクバーなど） |
| Microsoft.UI.Xaml.CBS | XAMLベースのUI制御を提供 | スタートメニュー、設定画面 |
| MicrosoftWindows.Client.Core | コアUI要素の依存関係を管理 | システムホストプロセス（SiHostなど） |
これらのパッケージの登録が失敗、または遅延すると、UIを構成するアプリ群が参照できなくなり、結果として画面が表示されなくなります。
依存パッケージの登録が遅れる理由
更新プログラムの適用後、Windowsは内部で多数のAppxパッケージを再登録します。
しかし、プロビジョニングや非永続OSのような環境では、この登録処理が完了する前にユーザーのログオンが発生する場合があります。
このタイミングの競合こそが、UI不具合の直接的な引き金です。
具体的には、初回ログオン中に「Microsoft.UI.Xaml.CBS」や「MicrosoftWindows.Client.CBS」の登録が終わらず、Explorer.exeが必要なライブラリを参照できない状態に陥ります。
| 状況 | 発生メカニズム | 影響する要素 |
|---|---|---|
| 更新直後にログオン | 依存パッケージの登録未完了 | Explorer.exe 起動失敗 |
| 非永続OS（VDI） | 毎回再登録が必要 | シェル初期化遅延 |
| 展開直後のプロビジョニング | 初回ログオンと処理が競合 | スタートメニュー未描画 |
つまり、更新プログラムそのものに欠陥があるわけではなく、更新後の環境初期化プロセスの同期不全が問題なのです。
Microsoftが説明する技術的背景と再現条件
Microsoftは、KB5072911の中で本問題を「依存関係パッケージの登録遅延に起因する一時的な不具合」と分類しています。
この分類からも、システム自体が破損しているわけではなく、正しい順序で再登録すれば解消することが示唆されています。
実際、同社は恒久対応（Resolution）を「作業中」としつつも、当面は回避策による暫定運用を推奨しています。
再現条件としては、特に以下の2点が重要です。
- 更新プログラムの適用直後にユーザーログオンが発生する。
- 初期設定フェーズでAppxパッケージ登録が完了していない。
このため、同じ更新を適用しても、環境によって発生したりしなかったりする「再現性のばらつき」が見られます。
次章では、Microsoftが提示した具体的な回避策（KB5072911）をもとに、実際の対処手順を整理します。
KB5072911が示す回避策 ― 登録のやり直しとSiHost再起動
ここでは、Microsoftがサポート文書「KB5072911」で示した具体的な回避策を整理します。
この回避策は、UIを構成する依存パッケージを再登録した上で、Windowsのシェル基盤プロセスである「SiHost（Shell Infrastructure Host）」を再起動することで問題を解消するという流れです。
一見すると複雑に見えますが、要点を押さえればシンプルな手順です。
手動登録手順 ― Add-AppxPackageによる修復方法
最も直接的な対処法は、PowerShellを使ってXAML関連の依存パッケージを再登録する方法です。
この手法は、すでにUIが起動しない端末や、ログオン後に黒い画面が表示される環境での復旧に用いられます。
手順の概要は以下の通りです。
| ステップ | 操作内容 |
|---|---|
| 1 | 管理者権限でPowerShellを起動 |
| 2 | 対象パッケージのappxmanifest.xmlを指定し、Add-AppxPackage -Registerで再登録 |
| 3 | SiHost（Shell Infrastructure Host）を再起動 |
| 4 | UIが復旧したか確認し、必要に応じてサインアウト／再ログオン |
実際のコマンド例は次の通りです。
Add-AppxPackage -Register -Path "C:\Windows \SystemApps\Microsoft.UI.Xaml.CBS\AppxManifest.xml"
登録完了後、Stop-Process -Name sihost -Force を実行してSiHostを再起動します。
この処理によって、XAML依存パッケージが再びUIプロセスから参照可能となり、Explorerやスタートメニューが起動できるようになります。
非永続OS向けログオンスクリプトの仕組み
もう一つの回避策は、VDI（Virtual Desktop Infrastructure：仮想デスクトップ基盤）や非永続OS環境向けに用意された「ログオンスクリプト」です。
これは、ユーザーのログオン時に自動でパッケージ登録を実行し、依存関係を整えた上でExplorerを起動させる仕組みです。
スクリプトの骨格は次のようになります。
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows \SystemApps\Microsoft.UI.Xaml.CBS\AppxManifest.xml'"
ログオンスクリプトを利用することで、仮想環境ごとに毎回登録をやり直す形になります。
非永続OSではユーザープロファイルがセッションごとにリセットされるため、この方式が安定稼働に向いています。
| 運用パターン | 目的 | 適用対象 |
|---|---|---|
| 手動登録 | 既に発生した端末の復旧 | 単発の障害端末 |
| ログオンスクリプト | 毎回の登録遅延を防止 | VDI・非永続OS |
どちらの方法も本質は同じで、「依存パッケージを確実に登録してからUIを起動する」ことにあります。
2026年1月更新 ― 引用符修正の意味と注意点
Microsoftは、2026年1月7日にKB5072911の記載を更新し、手動登録コマンド内の引用符を「単引用符（'）」から「二重引用符（"）」に修正しました。
この変更は、一見小さく見えますが、PowerShellでパスを指定する際の解釈を統一するための重要な修正です。
たとえば、環境変数や空白を含むパスを扱う場合、単引用符だと文字列が正しく展開されず、登録に失敗することがありました。
二重引用符に変更することで、スクリプトの動作がより安定し、実行エラーを防ぐことができます。
| 更新日 | 更新内容 | 意図 |
|---|---|---|
| 2025年12月2日 | 症状表と管理者向け説明を追加 | 発生条件の明確化 |
| 2026年1月7日 | 手動登録コマンドの引用符を修正 | スクリプト実行の安定化 |
このように、Microsoftは手順の精度を継続的に見直しており、実運用では公式文書の変更履歴を常に確認することが推奨されます。
次章では、これらの回避策を現場でどう実装すべきか、安定運用の観点から整理します。
実務者のための安定運用ガイド
ここでは、KB5072911で示された回避策を、実際の運用現場でどのように組み込むべきかを整理します。
単にコマンドを実行するだけではなく、「どの単位で」「どのフェーズで」適用すべきかを明確にすることが、安定稼働の鍵になります。
特に、VDI（仮想デスクトップ）やプロビジョニング基盤を運用する管理者にとって、適切な適用範囲の判断が重要です。
端末単位での復旧 vs 展開基盤での再発防止
UI不具合がすでに発生した端末に対しては、個別復旧として手動登録手順を用いるのが最も確実です。
一方で、再発防止を目的とする場合は、OSイメージや展開スクリプトにあらかじめ登録手順を組み込む方が効果的です。
次の表は、両アプローチの使い分けを整理したものです。
| 対処の方向性 | 主な目的 | 適用対象 | 代表的な方法 |
|---|---|---|---|
| 個別端末の復旧 | 既発生端末のUI復元 | 単一ユーザーセッション | 手動登録（Add-AppxPackage） |
| 展開基盤での再発防止 | 組織全体の安定稼働 | マスターイメージ、非永続VDI | ログオンスクリプトの導入 |
実務上のポイントは、「一時復旧」と「予防実装」を明確に分けることです。
これにより、更新後の再発や異なる端末での再現を防止し、保守コストを大幅に減らすことができます。
VDI環境でのスクリプト実装ポイント
VDI（Virtual Desktop Infrastructure）や非永続OS環境では、ユーザープロファイルが毎回リセットされるため、ログオンごとにパッケージ登録を実行する仕組みが必要です。
スクリプト実装のポイントは、「Explorer.exeの起動前にAdd-AppxPackageを実行する」ことです。
この順序を誤ると、UIの依存関係が再び途切れてしまうため、スクリプトの中ではプロセス待機を組み込むのが一般的です。
| 処理順序 | 内容 |
|---|---|
| 1 | PowerShellスクリプト起動（ExecutionPolicyをBypass） |
| 2 | Add-AppxPackageコマンドで依存パッケージを登録 |
| 3 | 5〜10秒待機してExplorer.exeを起動 |
| 4 | 必要に応じてログファイルで実行結果を記録 |
特に仮想環境では「実行タイミング」がUI安定性に直結するため、スクリプトのテストを十分に行うことが推奨されます。
また、CitrixやVMware HorizonなどのVDIプラットフォームでは、セッションスクリプトの登録場所や実行権限にも注意が必要です。
恒久対応（Resolution）待ち期間中の運用設計
MicrosoftはKB5072911において、「恒久的な修正（Resolution）は作業中」と明言しています。
したがって、現時点ではこの回避策を運用レベルで維持することが前提になります。
管理者は、次の3つのポイントを定期的にチェックすることが望ましいです。
- 最新の累積更新プログラム（CU）適用後に挙動が変わっていないか。
- Microsoftのサポート文書（KB5072911）の変更履歴に更新がないか。
- 展開スクリプトの署名や実行ポリシーが最新ポリシーに準拠しているか。
この3点を運用監視ルーチンに組み込むことで、回避策が長期運用に耐えられるようになります。
恒久対応が提供されるまでは、「継続的な検証」と「更新差分の追跡」が、安定運用を維持するための最重要ポイントです。
まとめ ― 回避策の定期見直しと今後の注視点
ここまで、Windows 11 バージョン 24H2で発生しているUI不具合の概要と、Microsoftが提示した回避策について詳しく解説してきました。
最後に、運用担当者が今後押さえておくべきポイントと、恒久対応が提供されるまでに行うべき管理策を整理します。
Microsoftの今後の対応予定
Microsoftは、KB5072911の中で「この問題の恒久的な修正（Resolution）は現在作業中であり、更新があればドキュメントを改訂する」と明記しています。
そのため、現段階では累積更新プログラムの中に修正コードが含まれているわけではなく、暫定的な回避策が唯一の安定手段となります。
Microsoftの更新履歴を追うと、2025年12月および2026年1月の2度にわたり文書修正が行われており、細部の改善が進められていることが分かります。
| 更新日 | 変更点 | 意図 |
|---|---|---|
| 2025年12月2日 | 症状表と影響範囲の拡充 | 発生条件の可視化 |
| 2026年1月7日 | PowerShellコマンドの引用符修正 | スクリプト精度の向上 |
これらの更新は、Microsoft側で手順精度の検証を継続している証拠であり、恒久対応が公開されるまでの間は「ドキュメントの最新化」を維持することが求められます。
管理者が今行うべき確認ステップ
実務上、IT管理者が今すぐ取り組むべきアクションは次の3つに整理されます。
- 展開済みのWindows 11 24H2端末で、UI不具合の再現有無を確認する。
- VDIや非永続OS環境において、ログオンスクリプトの実行順序を検証する。
- KB5072911の変更履歴とMicrosoft Updateカタログを定期的に確認する。
特に、環境差によって発生条件が異なるため、複数の端末で同一検証を行い、共通点を把握することが重要です。
また、PowerShell実行ポリシーの管理や署名の設定も、運用上のトラブルを未然に防ぐ観点で見直すと良いでしょう。
| 確認項目 | 頻度 | 目的 |
|---|---|---|
| 不具合再現の有無 | 毎月の更新適用後 | 影響範囲の早期検知 |
| ログオンスクリプト実行結果 | 四半期ごと | 登録遅延の再発防止 |
| KB5072911の更新履歴 | 月次で確認 | 最新手順への追従 |
つまり、今回の不具合は「一度直して終わり」ではなく、運用の一部として継続的にモニタリングすべき対象です。
定期的な検証と情報更新のルーチン化が、最も実効性のある対策になります。
今後の更新で恒久的な修正が配布された際には、これまでの回避策を段階的に解除し、標準環境への復帰を進めることが推奨されます。
最後にまとめると、KB5072911は単なる一時的な修復策ではなく、Windows 11のUI構造そのものに関わる重要な技術的知見を含んでいます。
運用担当者は、これを教訓に「更新タイミングと初期化プロセスの管理」がいかにシステム安定性に直結するかを理解しておくことが望まれます。
