更新履歴
- 2026/02/26 08:20… 【重要】修復インストールによる暫定解決策と検証結果を追記
- 2026/02/25 15:00… cmdからのKB5077241削除は失敗（エラー0x800f0926を確認）
- 2026/02/25 13:20… 第一回現状報告（原因推定セクションを補完）
【重要】このブログのスタンス：速報性と予防効果を最優先する理由（クリックで展開）
当サイトのトップページにも記載していますが、改めて、私たちの情報発信における最も重要なスタンスについてお話しさせてください。
トラブルシューティング手法などの一般記事は十分な精査を行った後に公開していますが、毎月のWindows Updateに関する記事においては「速報性と予防効果を最優先」してお届けしています。
なお、公開内容に錯誤などが含まれていた場合は、速やかに修正や続報の提供を行っています。この点はご了承の上、ご寛容ください。
このサイトではWindows Update情報や、Winの不具合情報などを発信する上で、完全な正確性より、速報性や予防効果に重きを置いているなどいくつかの注意点があります。
これは、単なる免責事項ではありません。読者の皆様のPCを深刻なトラブルから守るために、私たちが最も大切にしている編集方針です。
まとめ/推奨
【重要】適用してしまった場合、少なくとも私の手元環境では「プレビューKB5077241の削除は不能（エラー 0x800f0926）」という状況に陥っています。【解決への道】通常の削除が拒絶されるため、現時点での最善策は「修復インストール（インプレースアップグレード）」によるシステム基盤の上書きです。これにより、問題のKBを「未適用（利用可能）」の状態へ押し戻せることを実機で確認しました。
【絶対回避】 25H2/24H2環境のユーザーは、プレビューKB5077241の適用を直ちに停止してください。また、一見異常がないと見えても「隠れ不具合が顕在化していない」という可能性も低くありません。
自動適用への警戒： 本件はプレビューKB単体ではなく、同時に降るダイナミックKBがシステム深部を書き換えている疑いがあり、ネット接続だけで不具合が強制導入される恐れがあります。
安定稼働重視の方： 今回はOSの根幹（UEFI/回復基盤）に手が入っています。3月の正式版配信後、安全が確認されるまで様子見を強く推奨します。
⚠️ 既に不調に陥った方へ
コマンドラインからの削除（wusa/DISM）はエラーで失敗する可能性が非常に高いです。
ネット接続を遮断した状態でのバックアップからのリストア、または本記事追記の「修復インストール」による回復を検討してください。
※8分04秒
検証環境（AMD Ryzenシステム）
| CPU | AMD Ryzen 5 5600（6コア12スレッド） |
|---|---|
| メモリ | 24GB |
| マザーボード | ASUS B450M-PLUS GAMING |
| グラフィック | MSI GeForce RTX 3050 VENTUS 2X XS 8G OC |
| ストレージ | システム：Intel SSD 7 (1TB M.2) / データ：HDD 3台（計8TB） |
| OS | Windows 11 Pro 64bit (25H2対応) + Microsoft 365 |
状況追跡記述セクション
2026/02/26 KB5077241適用者の暫定解決策
- 修復インストールは100％安全な操作ではありません。不具合が発生している状態であっても、システムイメージバックアップを取得した後に実行するようにしてください。修復インストールに失敗した場合は、取得したイメージでリストアし、MSの対応を待ってください。
- 厳密には100％の解決策とはいえませんし100％安全とは言えないが、修復インストールを実行することで手元での不具合発生は収まった。
- ある意味次善の策です。KB5077241適用者であっても不具合の発生がない場合は、「ミリに修復インストールを試みる必然はないと考えてください。ある程度以上の障害発生規模であればMSより修正パッチが配信されると考えられますので、それを待つという選択肢も考慮してください。
- KB5077241適用者で適用前のシステムイメージを取得してある場合は、修復インストールではなく、イメージからのリストアを優先してください。
- 絶対とは言いませんが、今回のような障害発生にシステム領域の空き容量不足がえいきょうする、また今後影響するということは十分以上に考えられます。システム領域（特にEFI領域）が100MBのママの方は「【システム領域不足】WinUpやOSアップグレードの失敗を解消する【2025/09/15】」を参考にシステム領域を拡張する、ないしはこの機会に「【2026年問題対応版】Windowsの「不調の呪縛」を断つ、最高純度のクリーンインストール「黄金順序」【2026/02/23】」を参考にして今後のWinUpに耐えOS運用が安定する環境構築してみるとよいかと思います。
手元PCでの修復インストール実行後の状態検証結果について
2/25にMSサイトより取得した現状の最新イメージで実行した。
あくまで私の手元PCでの結果である。
この記事で書いた不具合は解消した。
cmd（管理者）から三つのチェックを実行し問題なしであった。
cmdより実行した三つのチェック
コンポーネントストアの「健康診断」（1分）
管理者権限のターミナル（PowerShell）で以下を実行してください。
Dism /Online /Cleanup-Image /CheckHealth
システムファイルの「整合性確認」（1～5分）
続けて以下を実行します。
sfc /scannow
CBS.log の「ゴースト」検索（1分）
もっとも重要な「深層の確認」です。以下のコマンドで、ログから異常を抽出します。
findstr /c:”HRESULT = 0x800f0926″ %windir%\Logs\CBS\CBS.log
私の結果（成功例）
- DISM (CheckHealth): 「コンポーネント ストアが壊れていることは検出されませんでした」とあり、管理基盤の整合性は完全に保たれています。
- SFC (scannow): 「整合性違反を検出しませんでした」となっており、システムファイルの書き換えも正常に完了しています。
- 「0x800f0926」の消滅：
findstr で何も出力されなかったのは、ログの中にあの「削除不能（Permanent）」を示す呪いのコードが一切記録されていない、つまり物理的に不整合が排除された証拠
WinUpの状況
※ 修復インストールを行っても、通常修復インストール前のWinUp履歴はそのまま保持されるため履歴は画像のようになります。
この状態でUpdateを実行した結果：
最終のロール（2/11付け）であるKB5077181が再検出され、正常に適用が開始されました。
最終結果：
KB5077181が適用され、問題のプレビュー更新KB5077241が「未適用（利用可能）」の状態に戻りました。今回の修復インストールの目的は成功し、システムの整合性が回復したと判断してよいと考えられます。
修復インストール直後のWinUp履歴
この状態でWinUpを実行した結果：最終のロール（この場合は2/11付け）であるKB5077181が検出され適用が開始します。
更新結果：KB5077181が適用され、プレビュー更新KB5077241が表示された状態（未適用の状態）になっていますので、今回の修復インストールの目的は成功、2月の定例は適用され2月のプレビューは適用されていない状態になったと判断してよいかと考えられます。
2026/02/25 15：00 cmdからのKB5077241削除は失敗しました
まだ検証途中ではありますが、コマンドでの削除失敗のエラー表示を見ると「KB削除不能」の可能性が非常に高いため、ここで一度記事を更新します。
もがいては見ますが、9割方、（MSからの修正が来るなどしない限り）現時点の状況のままではKB5077241は一度導入してしまうと削除ができないと考えられます。
このあと外部メディアから鼓動した回復環境からも試みてみますが、エラー内容から「KB削除は不能」という可能性が非常に高いです。
CMD検証結果の衝撃的な分析
1. エラーコード 0x800f0926 の正体
wusaコマンドで吐き出されたこのコードは、一般的に「このパッケージはアンインストールできません（DISM_E_PACKAGE_NOT_REMOVABLE）」を意味します。 つまり、Windows Update側がこのKB5077241を「後から消せる更新」ではなく、「システムの一部として固定された（Permanent）コンポーネント」としてフラグを立ててしまった証拠です。
2. DISMで「検出不能」という異常事態
dism ... findstr 5077241 を実行して何も返ってこない（20260225ScreenShot00011.png）のは、さらに不可解です。
-
パッケージの「変名」あるいは「断片化」： 本体のKB番号ではなく、内部的なコンポーネント名に分割されて組み込まれている可能性があります。
-
動的更新による「隠蔽」： KB5079271（セットアップ・エンジンの更新）によって、パッケージ管理リストのインデックス自体が書き換えられ、従来の検索に引っかからなくなっている恐れがあります。
【技術的見解】なぜ削除に失敗するのか
井上さんが推測された通り、カーネルやUEFIへの深い干渉が原因で、システムが「今さら古い状態には戻せない」と拒絶している構図です。
-
「修理道具」が壊れている： セットアップバイナリ（KB5079271）が上書きされたことで、アンインストールを実行する「wusa」や「DISM」そのものが、新世代の整合性チェックに阻まれて動かなくなっています。
-
不可逆な変更： 2026年問題に対応した証明書の書き換えが、OS上のファイルレベルではなく、ハードウェア（NVRAM）に近いレイヤーで既に完了してしまっているため、ファイルだけ消そうとしても整合性エラーで弾かれます。
これは「たぶん詰み」の証明です
このスクリーンショット（CMDの失敗）は、読者にとって「自力でコマンドを叩いても無駄である可能性が高い」ことを示す、極めて重要な「救済の断念勧告」になります。
管理者権限のCMDから強制削除を試みましたが、エラー 0x800f0926（削除不能）で跳ね返されました。
さらに、DISMコマンドでもパッケージ自体が検出されないという、OSの管理基盤が書き換えられた「ゴースト現象」を確認しています。
これは、今回の更新が「後戻りのできないシステム置換」であることを示唆しており、安易にコマンドを試してシステムをさらに破壊するリスクを冒すべきではありません。
読者の方で、すでにKB5077241を導入したという方は、不具合具現化の有無にかかわらず、MSの対応がでるまで現状維持、削除などは試みないようにしてください。
発生した障害の状況（以下のセクションは記事開始時の分です）
適用直後（再起動前）の不具合状況（既報告分）
- エクスプローラーのフリーズ： デスクトップアイコンの消失、および操作不能なプチフリーズの発生。
- アプリケーションの連鎖クラッシュ： Chromeのフリーズ、Visual Studio JIT Debuggerの頻発。
- Hyper-Vの異常： 仮想マシンの「状態保存」に失敗し、強制終了せざるを得ない状態。
不具合状況（新規判明/追加分）
- 回復環境（WinRE）の英語化・ループ： 再起動後のオプション画面が英語になり、Enter押下でWinロゴ画面へ戻るループ挙動を確認。
- UIからのKB削除・復元が失敗： 設定画面からのアンインストールおよび「システムの復元」が共にエラーで進行不能。
- スマホ連携アプリの起動不可： 特定の標準アプリが開けなくなる不具合を確認。
プレビューKB5077241について
KBの内容
2026年2月24日公開の24H2/25H2向け非セキュリティ・プレビュー更新プログラムです。
主な変更点は「バッテリーアイコンの刷新」「スタートメニューの再設計」といったUI変更に加え、「2026年問題に対応したセキュアブート証明書の自動更新」、「ネイティブ版Sysmonの導入」、「Quick Machine Recovery（QMR）の自動有効化」、そして膨大なAIコンポーネントの更新が含まれています。
更新内容より手元障害を引き起こした原因と考えられる事項
- セキュアブートCA更新（2026年問題）： UEFI（物理チップ）側の鍵を書き換えるプロセスが、2回再起動や回復環境の挙動不安定に直結していると考えられます。
- ネイティブSysmonの干渉： システムイベントを監視するSysmonが標準搭載されたことで、既存のセキュリティツールや画像キャプチャツール等と競合し、エクスプローラーのフリーズを招いている可能性があります。
- Quick Machine Recovery (QMR) の不整合： Pro版デバイスで自動的にオンとなったQMR機能が、従来の「システムの復元」や回復環境のパスと衝突し、英語化や削除失敗を引き起こしている疑いがあります。
- 巨大なAIコンポーネントの負荷： 4GB超の更新データのうち、セマンティック分析等のAI部品がAMD環境の特定のドライバスタックと競合し、アプリの連鎖クラッシュを誘発していると推察されます。
ウェブ上で確認できた「KB5077241」の不穏な動き（2026/02/25 13時過ぎ時点）
現在、国内外のコミュニティや技術サイトで以下の事象が確認されています。
-
「チャンネルの混乱」による大混乱： Reddit等の海外コミュニティでは、Release Previewチャンネル（RP）に設定しているのに、強制的にBeta版（ビルド26220系統）が降ってくるという「謎の挙動」が報告されており、ユーザー間で混乱が起きています。
-
タスクマネージャーやエクスプローラーのハング： 一部のユーザーから「タスクマネージャーのアイコンが消え、CPU使用率が0%のまま固まる」「エクスプローラーがクラッシュする」といった、私の環境に近い報告が出始めています。
-
インストール失敗のループ： 「0x800f0983」エラーで適用に失敗し、何度も再起動を繰り返す事例がMicrosoft公式コミュニティでも報告されています。
-
QMR（Quick Machine Recovery）の自動有効化： リリースノートにも記載がありますが、Pro版でこの機能が自動的にオンになったことが、回復環境（WinRE）の挙動を変えてしまっている可能性が非常に高いです。
KB5079271 / KB5079270など検証が困難な事項についての考察
KB5079271 / KB5079270については強制的に自動適用されてしまうため、独立した検証は困難ですが、これら「動的更新プログラム（Dynamic Update）」が今回の不具合の決定的な証拠（スモーキング・ガン）となっている可能性があります。
また、システムの復元画面において、2月10日配信のKB5077181の日付が「2/18」と表示されていた点も無視できません。これは通常の更新履歴には現れない「サイレントな修正更新」が実行され、システムの整合性に何らかの影響を与えた可能性を示唆しています。
1. KB5079271 / KB5079270 がもたらした致命的影響
今回の「英語化」「ループ」「復元失敗」という三重苦の正体は、以下の2つの動的更新による影響が疑われます。
【KB5079270：WinRE（回復環境）の破壊者】
- 公式の説明： 「Windows 回復環境 (WinRE) を強化します」。
- 実害との関連： 私の環境で回復環境が英語化し、ループが発生した主因と考えられます。WinREの書き換えプロセスにおいて、日本語リソースの消失やブートパスの汚染が起きた可能性が高いです。
【KB5079271：セットアップ・エンジンの汚染】
- 公式の説明： 「Windows セットアップ バイナリ…を改善します」。
- 実害との関連： 更新のアンインストールやシステム復元を制御するエンジン（wusa.exe等）自体が「改善（書き換え）」された結果、UIからの修復操作が物理的に機能しなくなったと推察されます。いわば「修理道具そのものが壊された」状態です。
2. 2月18日の「KB5077181修正配信」の謎
2月11日の定例配信から1週間後である「2月18日」に、初期の不具合（100MBの壁問題等）に対する「裏パッチ」がサイレントに配信されていた可能性があります。この修正が当たっている状態で、さらに25日のプレビューKBやWinRE強化KBが重なったことで、バイナリレベルでの世代のミスマッチ（ねじれ）が限界を超え、爆発したというシナリオが濃厚です。
3. 技術的見解のまとめ
【技術的結論】なぜ今回は「詰み」に近いのか：
今回のKB5079270がWindows最後の砦である「回復環境」を破壊し、KB5079271が「修復システム自体」を無効化してしまった恐れがあります。
この「修復機能の連鎖的な全滅」こそが、画面の英語化やアンインストール失敗を招いている真犯人である可能性が極めて高いと判断しています。
コメント