https://error-daizenn.hatenablog.com/entry/2025/10/19/205810

2025年10月14日に配信されたWindows 11向けセキュリティ更新プログラム「KB5066835（OS Build 26100.6899）」が、思わぬ問題を引き起こしています。回復モード（Windows Recovery Environment／WinRE）でUSBマウスやキーボードが反応しなくなるという深刻な不具合が、全世界で報告されているのです。
この問題は、Windows 11の24H2および25H2バージョン、さらにWindows Server 2025環境でも確認されています。
「パソコンが起動しない」「修復モードに入っても操作ができない」といったユーザーの声が続出し、企業のIT管理者たちの間でも警戒が広がっています。

今回の記事では、この問題の発生状況から原因の推定、Microsoftの公式対応、そして回避策までをわかりやすく解説していきます。特にWindowsの回復環境を頻繁に使うエンジニアや企業管理者にとっては必見の内容です。

2025年10月14日公開のセキュリティ更新が原因

この不具合を引き起こしているのは、2025年10月14日に配信されたKB5066835更新プログラムです。Windows 11の24H2および25H2バージョン、そしてWindows Server 2025向けに同時配信されました。
Microsoftが「セキュリティと安定性の向上」を目的として提供した更新ですが、結果的に回復モードでUSB入力が動かないという致命的なバグを含んでしまいました。

配信直後からユーザーコミュニティで「修復画面でキーボードが効かない」「マウスカーソルが出ない」といった投稿が急増。特に再インストールやブート修復を試みたユーザーが影響を受けています。

回復環境（WinRE）で入力デバイスが完全に無反応に

問題が発生するのは、Windowsの通常起動ではなく、**WinRE（Windows Recovery Environment）**と呼ばれる特別な起動モードです。ここは、システムが起動できない時に「修復」「リセット」「バックアップからの復元」を行うための重要な領域です。
しかしKB5066835を適用すると、この環境に入った瞬間、USB接続のキーボードとマウスが完全に無反応になるという現象が起きます。
画面にメニューは出ているのに、操作が一切できない――つまり、ユーザーはシステム修復ができず、詰んでしまう状況です。

一方で、通常のWindows起動時にはキーボードやマウスは正常に動作します。このため「ハードウェアの故障ではない」と判明しています。WinRE専用のドライバロード処理に異常があると見られています。

OSビルド26100.6899で発生する現象の詳細

対象となるのはOSビルド26100.6899の環境で、Windows 11 24H2および25H2にインストールされた場合に発生します。企業向けのWindows Server 2025でも同様の報告があります。
このビルドを導入すると、以下のような症状が現れます。

・回復モードに入るとキーボード・マウスが全く反応しない
・USBポートを切り替えても改善しない
・PS/2接続デバイスも無効になる場合がある
・BIOSレベルでは入力ができるが、WinRE画面で止まる

このため、回復モードに依存したトラブルシューティングが不可能になります。
特に企業の運用現場では、停電や障害対応時にWinREから修復するケースが多いため、影響はかなり深刻です。

Microsoftが10月17日に不具合を正式認識

Microsoftは2025年10月17日付で、この問題を公式ドキュメントにて認めました。
**「USB入力デバイスがWindows Recovery Environment内で動作しない不具合を確認している」**とし、現在修正版を開発中であると発表しています。
修正版のリリース時期は「数日以内を目指している」とのことですが、正確な日時はまだ公開されていません。

この迅速な認知には、RedditやMicrosoftフォーラムでの報告が役立ったようです。
特に「Windows Insider」コミュニティ内では、検証用マシンでの再現例が多数確認され、スクリーンショット付きの投稿が相次ぎました。

一般ユーザーから企業サーバーまで広範囲に影響

今回の問題の厄介な点は、対象が特定の環境に限られていないことです。
家庭用ノートPCから企業の仮想環境まで、あらゆる構成で報告が寄せられています。
IT系掲示板では「Hyper-V上の仮想マシンでもWinREが操作不能になった」「ドメイン管理下のWindows Server 2025でも影響を受けた」との書き込みも確認されています。

さらに、開発者向けのローカルホスト接続（127.0.0.1）がエラーを返すという副作用も同時に報告されており、Web開発環境に支障をきたすケースも出ています。
Microsoftの内部ビルドで共通モジュールが更新されたことが原因ではないか、と専門家は分析しています。

ネットワーク接続やファイルプレビューにも副作用

WinRE問題の影に隠れがちですが、KB5066835の導入後にネットワーク診断が失敗する現象も広く確認されています。
特にlocalhost通信が拒否されることで、ローカル開発サーバーを利用しているユーザーは「接続が確立できない」「テスト環境が動かない」と混乱しています。

さらに、エクスプローラーのプレビュー機能が空白になる不具合も発生。画像やPDFのサムネイルを確認できず、作業効率が落ちてしまうという声も多く上がっています。
これらの副作用は、24H2以降で導入された「セキュリティ分離機構（Security Isolation Mechanism）」が関係している可能性があり、今回のバージョン特有の問題と見られています。

RedditやXでの報告が急増中

今回のトラブルは、公式発表前からSNSや掲示板で急速に拡散しました。
特にRedditのr/Windows11や**X（旧Twitter）**では、「回復画面でキーボードもマウスも効かない」「リセット操作ができず完全に詰んだ」といった投稿が相次ぎました。
あるユーザーは、ノートPCの電源が入らずWinREに入ったが、操作ができないため初期化も修復もできなかったと報告。別の投稿では、企業の管理者がサーバー群で同様の症状を確認したとも述べています。
中には「USBハブを抜き差しすると一瞬反応した」「古い有線キーボードでは動いた」という例もありますが、再現性はなく、根本的な解決には至っていません。

Microsoftの公式フォーラムでも「KB5066835を適用したらリカバリができない」というスレッドが多数立ち、数百件を超える返信が寄せられています。
これほど短期間で報告が集中した更新不具合は、2023年の『KB5023706プリンター障害』以来とも言われています。

一時的な回避策：KB5066835をアンインストールする手順

Microsoftは一時的な回避策として、WinREに入らずにKB5066835をアンインストールする方法を案内しています。
ただし、この操作には通常のWindows環境でログインできることが前提です。

(1) スタートメニューから「設定（Settings）」を開きます。
(2) 「Windows Update」→「更新の履歴（View update history）」を選びます。
(3) 「更新プログラムをアンインストール」をクリックします。
(4) 一覧の中から「KB5066835」を探して選択し、「アンインストール」をクリックします。
(5) PCを再起動します。

この手順でマウス・キーボードの不具合は解消されますが、同時にセキュリティ修正も失われるため注意が必要です。
Microsoft自身も「恒久的な解決策ではない」としており、修正版が配布されるまでは、WinREに入る操作を控えることが推奨されています。

Microsoftの公式対応状況と今後の修正版リリース予定

Microsoftによると、この問題は内部で「緊急優先度（Critical Priority）」として扱われており、現在修正版（Hotfix）のテスト段階に入っているとのことです。
同社のサポートページでは「今後の更新プログラムで解決予定」と明記され、最短で10月下旬の累積更新（Cumulative Update）で修正される見込みです。

また、公式サポートでは「USBデバイスドライバの初期化順序に問題がある」と説明しており、特定のブート構成でドライバ読み込みがスキップされることを確認したとしています。
つまり、更新内容そのものというよりも、ドライバ制御の内部処理にバグが存在しているということです。

自動更新を止めるべきタイミングとは？

一部のユーザーは「そもそも自動更新を止めておけば良かった」と後悔しているようですが、これは簡単な問題ではありません。
セキュリティ更新には、ゼロデイ脆弱性（Zero-day vulnerability）の修正も含まれているため、停止するリスクも大きいのです。
しかし、今回のように回復環境すら操作できないほどの不具合が出てしまうと、「しばらく様子を見る」判断も現実的です。

専門家の間では、「新しい更新が出たら最低でも48時間は様子を見る」「企業の場合はテスト環境で先行適用してから本番に展開する」という運用が推奨されています。
これは、2020年代後半のWindows更新トラブルが増加傾向にあることを踏まえた実践的な対策です。

エンジニア・管理者の間で起きている現場の混乱

企業のIT現場では、今回の不具合により障害復旧作業が滞るケースが報告されています。
たとえば、クラウド基盤のバックアップからリストアする際、WinREを使った復旧操作ができないため、別の物理メディアからブートして対応せざるを得ない状況です。
また、学校や官公庁など複数端末を一括管理している現場では、「KB5066835を含む更新を配信停止にするスクリプトを緊急適用した」との報告もあります。

現場エンジニアたちの本音として、「更新のたびに動作確認をする手間が限界に達している」という声が多く聞かれます。
この問題を機に、Windows更新の信頼性そのものを見直す必要があるという意見も出ています。

フォーラムの声：「これじゃ回復できない」「企業PCも詰む」

フォーラムでは、ユーザー同士の情報共有も活発に行われています。
「この状態でブート修復どうやってやるの？」「サーバーの復元ポイントにアクセスできない」「BitLocker解除もできなくなった」など、切実な声が並びます。
一方で、「外部USBメディアからの起動で回避できた」「PS/2ポートを有効化したら動いた」といった応急報告もあり、ユーザー間で協力しながら検証が続いています。

まるで“みんなでバグを直している”ような雰囲気で、技術フォーラムはちょっとした研究室のような熱気に包まれています。

過去の類似トラブルとの比較と教訓

今回の問題は、**2022年の「KB5012170セキュアブート障害」や2024年の「KB5034201ネットワーク認証バグ」**など、過去の大型アップデート不具合を思い出させます。
いずれのケースも、セキュリティ更新がドライバやブート関連モジュールに干渉し、結果としてPCが操作不能になるという点で共通しています。

専門家たちは、「Microsoftの更新テストプロセスに、WinRE環境の検証が十分含まれていないのではないか」と指摘しています。
つまり、“本番復旧の最後の砦”であるWinREがテストの盲点になっていた可能性があるということです。

まとめ：更新の信頼性をどう守るか、私たちにできる対策

今回のKB5066835問題は、単なる一時的な不具合ではありません。
システムの「自己修復機能」が使えなくなるという、本質的なリスクを浮き彫りにした出来事です。
Microsoftが迅速に修正版を出す見込みとはいえ、今後も同様のトラブルが起きないとは限りません。

そのため、今後の対策として次のようなポイントが重要になります。

・自動更新を即日適用せず、情報を確認してから導入する
・修復メディア（USBまたはDVD）を常に作成・保管しておく
・BitLockerや回復キーを別デバイスに保存しておく

そして何より、トラブル発生時には慌てずに情報を共有し、コミュニティの知見を活用することが大切です。
今回のように多くのユーザーがSNSやフォーラムで声を上げたからこそ、Microsoftも迅速に対応へ動きました。

みなさんの環境ではこのKB5066835、どうでしたか？
もし同じような症状に遭遇した方がいれば、回避できた方法や試した手順をコメント欄で共有してください。
――このトラブルを“全員で乗り越える”ことが、次の安心につながるはずです。