本記事が扱う事象は、Windows 11 バージョン 24H2／25H2 で、エクスプローラーやスタートメニューなどのUI（ユーザーインターフェース）が起動しない、または動作が不安定になる問題です。主な対象は企業・管理端末で、プロビジョニング（展開）後の初回ログオンや、非永続OS（non-persistent OS installation：非保持型）環境で発生しやすい条件が示されています。Microsoft はサポート文書 KB5072911 を通じて原因と回避策を提示し、その回避策の記載を更新しました。 (マイクロソフトサポート)
影響の整理：何が起きているのか、どこまで影響するのか
本件は、Windows 11 の画面表示と操作を担う複数の要素が同時に成立しない形で表面化し、ログオン後の基本操作が成立しないケースが想定されています。 (マイクロソフトサポート)
Microsoft の説明では、2025年7月以降に公開された月例の累積更新プログラムを、Windows 11 24H2／25H2 の端末へ適用したあとに症状が出る可能性があるとされています。具体例として KB5062553 や KB5065789 が挙げられており、更新適用のタイミングと関連づけられています。 (マイクロソフトサポート)
そのため、一般家庭の個人端末というより、管理対象デバイスや組織端末での再現が中心という整理になります。一方で「非常に起こりにくい」とされる範囲でも、展開方法が似ている場合は条件差が生じる可能性があるため、発生条件の切り分けが実務上の確認点となります。 (マイクロソフトサポート)
以上を踏まえると、問題の中心は「更新の適用」そのものではなく、更新後の初期化手順が一部環境で完了しない点に置かれており、次にその条件と症状を分解して整理します。 (マイクロソフトサポート)
発生条件と症状：プロビジョニングとログオンのタイミングが鍵
発生しやすい条件は「更新適用後、初回ログオン前後で必要なアプリ要素の準備が間に合わない」点に集約されます。 (マイクロソフトサポート)
Microsoft は、永続OSの初回ユーザーログオン時、または VDI（virtual desktop infrastructure：仮想デスクトップ基盤）などの非永続OSで毎回のログオン時に、症状が出やすいと説明しています。言い換えると、更新の展開フローとユーザーセッションの開始が近接するほど成立条件が厳しくなる構造です。 (マイクロソフトサポート)
症状としては、Explorer.exe（エクスプローラー）で黒い画面のままログオンする、スタートメニューが開かない、タスクバーが表示されない、起動直後にクラッシュする、などが例示されています。さらに StartMenuExperienceHost（スタートメニュー実行ホスト）や shellhost.exe（シェルホスト）など、シェル系コンポーネントにも波及しうる整理です。 (マイクロソフトサポート)
この結果、UI操作の入口が複数同時に停止し、個別のアプリ障害として切り分けにくい状態になります。ただし、同じ「表示されない」でも原因が単一とは限らないため、次に Microsoft が示した原因説明（なぜ起きるのか）を確認します。 (マイクロソフトサポート)
原因説明：XAML依存パッケージの登録遅延という構造
Microsoft は、XAML（Extensible Application Markup Language：拡張アプリケーション マークアップ言語）関連パッケージが更新後に「時間内に登録されない」ことを原因として挙げています。 (マイクロソフトサポート)
サポート文書では、XAML コンポーネントをホストする組み込み依存関係パッケージの更新後に、予期しない動作が発生しうると整理されています。対象として MicrosoftWindows.Client.CBS、Microsoft.UI.Xaml.CBS、MicrosoftWindows.Client.Core などのパッケージ名が明示されており、依存関係の成立が前提になっている点が示されています。 (マイクロソフトサポート)
つまり、UIを構成する各プロセスが「起動できない」直接原因は個別プロセスの欠陥というより、起動前に必要な依存パッケージの登録が完了しない点にある、という因果関係です。この点から、対処はファイルの置き換えではなく「登録のやり直し」と「シェル側の再読み込み」に寄せた構成になります。 (マイクロソフトサポート)
なお、Microsoft は恒久対応について「作業中であり、追加情報があれば更新する」としており、現時点では回避策が中心です。そうすることによって業務継続を図る設計ですが、次にその回避策自体が更新された点を整理します。 (マイクロソフトサポート)
回避策と更新点：SiHost再起動とスクリプト、そして引用符の修正
回避策は「不足パッケージの再登録」→「SiHost（Shell Infrastructure Host：シェル基盤ホスト）の再起動」でUI側に反映させる手順として提示されています。 (マイクロソフトサポート)
サポート文書は大きく、(1) 手動でのパッケージ登録、(2) 非永続OS向けのログオンスクリプト（logon script：ログオン時実行）の2系統を示します。手動登録では Add-AppxPackage -Register を用い、対象の appxmanifest.xml を登録したうえで SiHost を再起動し、Immersive Shell（没入型シェル）側に取り込ませるという流れです。ログオンスクリプトでは explorer.exe の起動を待機させ、必要パッケージが揃ってからシェルを立ち上げる説明が付いています。 (マイクロソフトサポート)
そのため、現場での運用設計は「単発端末の復旧」か「展開基盤での再発防止」かで分岐します。要点を整理すると、次の比較で位置づけが分かれます。
| 区分 | 主な対象 | 手順の骨格 | 実例（抜粋） |
|---|---|---|---|
| 手動登録 | 既に影響が出たユーザーセッション | 依存パッケージを再登録し、SiHost を再起動 | Add-AppxPackage -Register -Path "C:\Windows\SystemApps\...\appxmanifest.xml" |
| ログオンスクリプト | 非永続OS（VDI等） | Explorer 起動前に登録を完了させる | powershell.exe ... "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\...'" |
| 反映操作 | 両系統で共通 | 再読み込みでUIを成立させる | SiHost 再起動／サインアウト |
ただし、回避策は内容だけでなく「記載の更新」も発生しました。Microsoft の変更履歴（Change log）では、2026年1月7日に「手動登録コマンド内の引用符を、単引用符から二重引用符へ置き換えた」旨が明記されています。ここはコマンドをコピペする運用と相性が強く、パッケジ名やパスの扱いを統一する意図が読み取れます。 (マイクロソフトサポート)
| 変更日 | 更新点 | 影響する範囲 |
|---|---|---|
| 2025-12-02 | IT管理者向けの説明拡充、症状表の追加 | 症状理解と切り分け |
| 2026-01-07 | 手動登録コマンドの引用符を修正 | 回避策の実行手順 |
他方、Neowin など一部メディアは「回避策の更新」として報じていますが、文書上の更新点は上記のとおりで、まずは公式記載と差分の確認が判断材料として重要です。 (マイクロソフトサポート)
今後の整理：恒久対応待ちの間に残る確認点
恒久対応が提示されるまでの期間は、発生条件の把握と回避策の適用単位（端末／基盤）の整理が中心課題になります。 (マイクロソフトサポート)
Microsoft は解決策（Resolution）を「作業中」とし、追加情報が入り次第アップデートするとしています。つまり、現時点での運用は回避策の適用が前提となり、更新プログラムそのものに固定の修正パッチが含まれるかどうかは未確定です。 (マイクロソフトサポート)
この点から、実務上は「どの展開フローでプロビジョニングしているか」「初回ログオンの自動化がどこまで進んでいるか」「非永続OSで毎回の登録が必要になる設計か」を並行して点検する構造になります。なお、同じ KB を適用しても、端末の初期状態やセッション開始条件で再現性が変わるため、単純な端末差では片付けにくい類型です。 (BleepingComputer)
一方で、回避策の文面が更新された事実は、Microsoft 側でも手順の正確性を継続的に調整していることを示します。以上を踏まえると、回避策の実装は「一度作って終わり」ではなく、公式文書の変更履歴と合わせて維持管理する対象として扱う必要があります。 (マイクロソフトサポート)
