[For English Readers]
This article explains a bug where the mouse and keyboard do not work in the Windows Recovery Environment (WinRE) after a Windows Update. We provide a fully automated batch file (.bat) to fix this issue by extracting and replacing the winre.wim file from a Windows 11 ISO. Please use your browser’s translation feature to read the full guide.
【解決済み】KB5070773 で WinRE の問題は修正されました!(2025/10/21追記)
本記事で解説してきた Windows 回復環境(WinRE)でマウスやキーボードが反応しない不具合は、Microsoft が 2025年10月20日にリリースした帯域外(OOB)更新プログラム「KB5070773」によって完全に修正されました。
【解決】WinREのマウス・キーボードが動かない問題、KB5070773で修正完了
▼ Microsoft公式情報
- 2025年10月20日 – KB5070773 (OSビルド 26200.6901および26100.6901) 帯域外 (Microsoft Support)
- Windows 11 バージョン 24H2 の既知の問題と通知
Windows Update の画面から更新のチェックを行い、KB5070773 を適用すれば、WinRE は正常に動作するようになります(WinRE のバージョンは 10.0.26100.6901 に更新されます)。
筆者の環境で検証した結果、以前に当サイトの自動化バッチファイルで「winre.wim」を入れ替えた環境でも、KB5070773 を適用することで問題なく修正されることを確認済みです。
これにより、本記事で紹介したバッチファイルによる「winre.wim」の入れ替え作業は、基本的には不要となりました。(ただし、WinRE イメージを手動で更新する技術的な解説として、記事内容は引き続き残しておきます。)
【軽微な不具合について】 なお、筆者の検証中に、修正された WinRE 環境から「続行」を選択して Windows を 再起動した際、まれにサインイン画面でキーボードが反応しなくなることがありました。この場合は、キーボードの USB を一度抜き挿しすることで解決しました。通常の再起動ではこの現象は発生しませんでした。
Microsoft による迅速な修正対応と、情報提供や検証にご協力いただいた読者の皆様に、心より感謝申し上げます。
【2025/10/21追記】読者様からの貴重なご報告によると、Windows Update で KB5070773 をインストールしたにもかかわらず、WinRE のバージョンが古いまま(10.0.26100.6891)で、マウス・キーボードが反応しない不具合も解消されない、というケースがあるようです。
筆者も同様の現象を一部環境で確認しました。
Windows 11 バージョン 24H2 および 25H2 をお使いの皆さん、最近、PC にトラブルが発生した際に利用する「Windows 回復環境(青い画面)」で、マウスやキーボードが突然反応しなくなり、操作できずに困っていませんか?
先日、当サイトのユーザー様から、まさにこの「回復環境でマウスが動かない」というお問い合わせをいただき、調査した結果、特定の更新プログラムが原因であることが判明しました。
通常モードでは問題なく使えるのに、回復環境だけ使えないという、非常に厄介なこの不具合について、その原因と対処法を詳しく解説します。
この記事の背景:一人の読者様からのご報告
この不具合は、2025年10月15日の夕方(17:50)、当サイトの熱心な読者様から「回復環境でマウスが動かない」という一件のお問い合わせをいただいたことから調査が始まりました。
すぐに検証を開始したところ、これは個人的な環境の問題ではなく、Windows Update に起因する深刻な不具合であると判断。調査を続けた結果、翌朝の未明(2025年10月16日 午前4:14)には、更新履歴には表示されない隠された更新プログラム「KB5067039」が不具合の直接的な原因であることを特定し、ご報告いただいたユーザー様に返信いたしました。
(その後のさらなる調査で、この更新プログラムに含まれる「USBHUB3.SYS」というドライバーファイルが根本的な実行犯であることを突き止めています。)
この記事は、その調査結果をまとめ、より多くの皆様がこの問題を解決できるよう、緊急で公開したものです。
【2025/10/19 追記】Microsoft がこの問題を公式に認めました
2025年10月17日、Microsoft はこの WinRE の不具合を公式に認め、現在修正に取り組んでいることを発表しました。近日中に修正プログラムがリリースされる見込みです。
▼ Microsoft の公式発表ページ
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#3696msgdesc
それまでの間、緊急で回復環境を操作する必要がある場合は、本記事で解説する対処法をご検討ください。
不具合の概要:回復環境でマウス・キーボードが動かない!
- 症状:
- Windows 11 バージョン 24H2 / 25H2 の PC で、「システム」>「回復」から PC の起動をカスタマイズする(回復環境を起動する)または Shiftキーを押しながら再起動すると、青い画面(Windows 回復環境)が表示されます。
- この画面で、USB接続のマウスやキーボードが全く反応しなくなり、操作ができない。
- 通常モードやセーフモード、BIOS/UEFI 設定画面ではマウス・キーボードは正常に動作する。
- 発生する PC:
- Windows 11 バージョン 24H2 および 25H2 を実行しているデバイス。
回復環境でマウス・キーボードが反応しなくなった場合は、電源ボタンの長押しで終了してください。この状態では Windows はまだ起動していないので、システムには影響しません。
- 回復環境は独立したシステム: Windows の回復環境(WinRE)は、普段私たちが使っている Windows とは別の、軽量で独立した OS(Windows PE ベース)で動作しています。
- システムファイルへの影響が少ない: 回復環境では、システムの復元や修復といった特殊な操作を選ばない限り、通常の Windows のシステムファイルに対して書き込みなどの重要な処理は行われていません。
したがって、回復環境でフリーズした際に強制終了しても、通常の Windows の起動やデータに影響を与える可能性は非常に低いです。
追記:さらに、ユーザー様からの貴重な情報によると、各種バックアップソフトで作成したレスキューメディア(USBメモリなど)で起動した場合も、同様に USBマウスや USB HDD が認識されなくなるとのことです。
これは、多くのレスキューメディア作成ツールが、PC に現在インストールされている WinRE をベースとして利用するため、PC 本体の WinRE が影響を受けると、そこから作成されるレスキューメディアにも問題が引き継がれてしまうことが原因です。
この不具合の原因は特定の更新プログラム
この困った不具合の原因は、検証した結果、Microsoft がひっそりとリリースした特定の更新プログラム「KB5067039」にあることが判明しました。
- 更新プログラム名: KB5067039: Windows 11 バージョン 24H2 および 25H2、Windows Server 2025 向けの安全な OS 動的更新: 2025 年 10 月 14 日
- 厄介な点:
- この更新プログラムは、「信頼性モニター」や Windows Update の「更新履歴」には表示されません。そのため、ユーザーがいつインストールされたかを確認しづらいのが特徴です。
- システムに自動的に適用されるタイプの更新プログラムです。
【補足】WinREが更新されたことをイベントビューアーで確認する方法
この「ひっそりと行われる更新」は、イベントビューアーでその痕跡を確認できます。
- Windowsキー + R を押して「ファイル名を指定して実行」を開き、「」と入力して Enter を押してイベントビューアーを起動します。
- 左側のツリーから「Windows ログ」>「システム」を選択します。
- 右側の操作メニューから「現在のログをフィルター」をクリックします。
- 「イベント ソース」のドロップダウンメニューから「WinREAgent」を見つけてチェックを入れます。
- 「<すべてのイベント ID>」と表示されている欄に「4501」と入力し、OK をクリックします。
これにより、WinRE が更新された際のログのみが表示されます。イベントID 4501 のログが見つかれば、あなたの PC の WinRE が自動的に更新された証拠となります。
WinRE のバージョンと不具合の関係
詳細な検証の結果、この不具合は特定のバージョンの Windows 回復環境(WinRE)でのみ発生することを確認しました。
- 不具合が発生する WinRE バージョン:
10.0.26100.6891- このバージョンがデバイスにインストールされると、回復環境でマウス・キーボードが反応しなくなります。
- 不具合が発生しない WinRE バージョン:
10.0.26100.6713(一つ前のバージョン)10.0.26100.5059(現時点で Windows 11 25H2 の ISO に含まれるバージョン)- これらのバージョンでは、マウス・キーボードは正常に動作します。
KB5067039 が適用されることで、WinRE のバージョンが 10.0.26100.6891 に更新され、この更新プログラムの公式ページによると、USBドライバーも更新されていることがわかります。この USBドライバーの不整合や欠落が、マウス・キーボードの動作不良を引き起こしていると考えられます。
Windows RE イメージのバージョンを確認する方法と簡単に確認できるツール
Windows 回復環境(WinRE)は、PC が起動しないなどの重大なトラブルが発生した際に、システムを修復するための「最後の砦」とも言える重要な機能です。
しかし、その回復環境で肝心のマウスやキーボードが動かなくなってしまっては、ユーザーはどうやって PC を修復すれば良いのでしょうか。「システムの復元」や「スタートアップ修復」など、いざという時のための重要な選択肢が目の前にあるのに、何も選べないという絶望的な状況に陥ってしまいます。
このような重要な機能に影響を及ぼす不具合が、ユーザーに知らされないまま自動更新されてしまうことに、不安を感じるのも無理はありません。
この不具合への対処法
現在のところ、この不具合を根本的に解決するには、以下の 2つの方法が考えられます。
対処法1:Windows REイメージ (winre.wim) を以前のバージョンに戻す
この方法は、WinRE のイメージファイルを、不具合が発生しない以前のバージョン(10.0.26100.6713 または 10.0.26100.5059)に手動で置き換えるものです。
【注意点】
この操作はシステムファイルを直接扱うため、PC 操作に慣れていない方には推奨しません。誤った操作はシステムの不安定化や起動不能に繋がる可能性があります。実行する場合は、必ず自己責任で慎重に行ってください。
具体的な手順としては、以下の流れになります。
- 以前のバージョンの Windows RE イメージ (winre.wim) ファイルを、Windows 11 25H2 の ISO から入手する。
- 管理者権限でコマンドプロンプトを起動し、WinRE を無効化する。
reagentc /disable - 現在の
winre.wimファイルを、入手した以前のバージョンのファイルで置き換える。(通常はC:\Windows\System32\Recoveryフォルダ内)- WinRE を無効化すると、
C:\Windows\System32\Recoveryフォルダ内にwinre.wimが現れます。(隠しファイル)
- WinRE を無効化すると、
- WinRE を再度有効化する。
reagentc /enable- WinRE を有効化すると、
C:\Windows\System32\Recoveryフォルダ内のwinre.wimが消えます。
- WinRE を有効化すると、
- PC を再起動し、回復環境でマウス・キーボードが動作するか確認する。
【追記】winre.wimを簡単に入れ替える自動化バッチファイル
対処法2:Microsoft による公式修正パッチのリリースを待つ
この不具合は Microsoft の更新プログラムによって引き起こされているため、Microsoft が問題を認識し、将来的に修正パッチをリリースする可能性が高いです。
- 緊急で回復環境を操作する必要がない場合は、PC を通常通り使用し、Windows Update を通じて公式の修正が提供されるのを待つのが最も安全な方法です。
- Microsoft は通常、このような重大な不具合については、速やかに修正プログラムをリリースする傾向があります。
2025/10/17:Microsoft は、この問題を認めました。この問題を解決するためのソリューションを近日中にリリースできるよう取り組んでいるとのこと。
追記:応急的な回避策:PS/2 接続のキーボード・マウスやタッチパッドを使う
こちらもユーザー様からいただいた非常に有益な情報です。
この不具合は USB 関連のドライバーに起因するため、PS/2 端子で接続された古いタイプのキーボードやマウス、そしてノートPC のタッチパッドは影響を受けずに正常に動作することがあります。
もしご自宅に PS/2 接続のキーボードやマウスがあれば、それを使って回復環境を一時的に操作することが可能です。
セーフモードに入りたい場合
何らかの理由でセーフモードに入りたい場合は、次のページで紹介している「詳細ブート オプション」を有効化することで確実に入ることができます。
【昔のF8キーを復活】Win11/Win10でセーフモードを起動する手順
まとめ
Windows 回復環境でマウス・キーボードが動かなくなる現象は、特定の Windows Update プログラムによって引き起こされる既知の不具合です。
緊急で回復環境を操作する必要がある場合は、WinRE イメージの手動でのダウングレードが必要になるかもしれません。しかし、最も安全なのは Microsoft からの公式修正を待つことです。
もしこの不具合に遭遇し、不安な場合は、無理に自分で操作せず、PC に詳しい方や専門家にご相談ください。
【追記】この不具合は Microsoft へ報告済みです
当サイトでは、この Windows 回復環境におけるマウス・キーボードの不具合について、2025/10/16 に Microsoft のフィードバックHub へ報告済みです。Microsoft による早期の調査と修正プログラムのリリースを期待しています。
【追記】KB5067039 はいつ、どのように適用されるのか?
この「ひっそりとした更新」は、一体いつ適用されるのでしょうか。当サイトで検証した結果、「KB5067039」は、2025/10/14 以降の累積更新プログラム(例:「KB5066835」)をインストールする際に、自動的に適用されることが判明しました。
具体的には、以下の検証を行いました。
- まず、テスト環境で「KB5066835」を一度アンインストールします。
- 次に、Windows RE イメージ (winre.wim) のバージョンを、不具合の発生しない以前のバージョン
10.0.26100.6713に手動で戻します。 - その状態で、再度「KB5066835」をインストールします。
- 結果、Windows RE イメージのバージョンは、再び不具合の発生する
10.0.26100.6891に更新されてしまいました。
このことから、「KB5066835」のような月例の更新プログラムを適用するプロセスの中で、「KB5067039」がバックグラウンドで強制的に適用されていることがわかります。
Microsoft の公式情報によると、この更新プログラムは WSUS(Windows Server Update Services)を通じて、以下のように構成された場合に自動的に同期されると説明されており、これが累積更新プログラムと同時に適用される仕組みのようです。
分類: 更新
Windows 11 バージョン 24H2 および 25H2 の場合
製品: Windows 11
分類: 更新
Windows Server 2025の場合
製品: Microsoft Server オペレーティング システム – 24H2
KB5066835 をアンインストールしても Windows RE イメージ (winre.wim) のバージョンは戻りません。Microsoft は、公式ページにて「この更新プログラムは、Windows イメージに適用されると削除できません。」と明言しています。
【追記】winre.wimを簡単に入れ替える自動化バッチファイル
この回復環境の不具合を、より簡単かつ安全に解決するため、Windows 11 の ISO ファイルから「winre.wim」を抽出し、システム上のファイルと置き換えるまでの一連の作業を半自動で行うバッチファイルを作成しました。
このツールは、
- 現在の「winre.wim」を自動でバックアップ
- ISOファイルから適切な「winre.wim」を抽出
- システムの保護されたファイルを安全に上書き
といった、コマンド操作に慣れていない方には少し難しい手順を自動化します。筆者の環境で実際に検証し、問題なく動作することを確認済みです。
事前準備
必要なもの(事前に準備しておいてください):
⚠️ BitLocker / デバイス暗号化が有効な環境での注意点
お使いの PC の Cドライブが BitLocker やデバイスの暗号化で保護されている場合、バッチファイルの最後のステップ「WinRE の再有効化 (reagentc /enable)」がエラーになることがあります。
これを防ぐための最も確実な方法は、バッチファイルを実行する前に、一時的に BitLocker(またはデバイスの暗号化)を完全に無効化(復号)しておくことです。
【重要】暗号化を完全に解除(復号)した場合の注意点
バッチファイル実行後、再度 BitLocker を有効にすると、新しい回復キーが生成されます。必ず新しい回復キーを安全な場所にバックアップしてください。
- Windows 11 の ISO ファイルをダウンロードし、空き領域が 20GB 以上ある任意のフォルダーに保存してください。
- 7-zip をダウンロードしてインストールしてください。
- https://7-zip.opensource.jp/(7-zip 公式ページ)
- バッチファイルを Windows 11 の ISO ファイルと同じ場所に置いてください。
このバッチファイルは、処理の途中で Windows のインストールイメージ(「install.wim」など)という数GB の大きなファイルを一時的に展開します。
そのため、バッチファイルを置いたドライブに最低でも 20GB 程度の空き領域を確保してから実行してください。空き領域が不足していると、処理が途中で失敗する原因となります。
バッチファイルのダウンロード
対象ファイル:「WinREイメージの抽出・適用ツール.bat」
ハッシュ値(SHA256):89549edc14838c362828a93670f0260b540ad1773a3718d735de0909e5e7926f
バッチファイルをダウンロードしたら解凍し、中にある「WinREイメージの抽出・適用ツール.bat」を Windows 11 の ISO ファイルと同じ場所に置いてください。
英語バージョン:
対象ファイル:「WinRE_Repair.bat」
ハッシュ値(SHA256):acd9d6c7b3e9a7661e97fe472caec2f0f3c008a540f01317531143c77afa2c6b
バッチファイル内の下記の部分をご自身の環境合わせて変更してください。
:: =============================================================================
:: 2. 設定値 (ここをあなたの環境に合わせて変更してください)
:: =============================================================================
SET "ISO_FILENAME=Win11_25H2_Japanese_x64.iso"
SET "SEVENZIP_PATH="
Win11_25H2_Japanese_x64.iso が ISO ファイルの名称です。
SET “SEVENZIP_PATH=” の部分は、通常は修正する必要はありません。「7z.exe」を通常ではない場所に保存している場合にのみ修正してください。
バッチファイルの内容と使い方
1.バッチファイルをダブルクリックで起動します。
2.「ユーザーアカウント制御」が表示されますので「はい」をクリックします。
3.コマンドプロンプトが表示され、まず設定内容を表示します。
- ISO ファイル:
ISO ファイル名 - 作業フォルダー:
バッチファイルが置かれているパス - 7-Zip 実行パス:
C:\Program Files\7-Zip\7z.exe
ここで Enter を押すと次の処理を実行します。
4.ステップ1: ISO をマウントし、下記のような Windows エディション情報を表示します。
インデックス: 1
名前: Windows 11 Home
説明: Windows 11 Home
サイズ: 22,689,601,389 バイト
インデックス: 2
名前: Windows 11 Education
説明: Windows 11 Education
サイズ: 23,636,557,841 バイト
インデックス: 3
名前: Windows 11 Pro
説明: Windows 11 Pro
サイズ: 23,659,047,210 バイト
5.ステップ2:抽出したいWindowsエディションのインデックス番号を入力してください:と表示されますので、ここでご自身の使用しているエディションのインデックス番号を入力して Enter を押します。
使用しているエディションがわからない場合:
1.スタートボタンの上で右クリック>「ターミナル」をクリックします。
2.次のコマンドを入力して Enter を押します。
(Get-CimInstance -ClassName Win32_OperatingSystem).Caption
すると、現在のエディションが表示されます。
6.ステップ3 ~ ステップ4:自動的に 7-zip を使用し、ISO ファイルから Windows イメージの抽出を開始します。
※「install.wim(または install.esd)」と「Winre.wim」が抽出されます。
7.ステップ5:抽出が完了すると、抽出したwinre.wimを現在のシステムに適用しますか? (自己責任で実行してください) [Y,N]?と聞かれますので、置き換える場合は「y」を、置き換えない場合は「n」を入力してください。
8.置き換えない場合は、ステップ6:不要な一時ファイル「install.wim(または install.esd)」を削除します。
置き換える場合は、下記の処理を行います。
- WinRE を無効化します。
- 「Backup」フォルダーを作成し、現在のバージョンの「Winre.wim」をバックアップします。
- 抽出した「winre.wim」を現在の「Winre.wim」に上書きします。
- WinRE を再度有効化します。
- ステップ6:不要な一時ファイル「install.wim(または install.esd)」を削除します。
▼この動画は、バッチファイルが実際に動作する様子を撮影した実行デモ動画です。
【2025/10/20 追記】根本原因が判明!犯人は「USBHUB3.SYS」でした
先日より調査を続けておりましたが、ついに、この回復環境でマウスやキーボードが動かなくなる不具合の根本的な原因を特定しました。
原因となっていたのは、WinREイメージ (winre.wim) に含まれる「USBHUB3.SYS」という一つのドライバーファイルでした。
KB5067039 の適用により、この「USBHUB3.SYS」が不具合を含んだ新しいバージョン (10.0.26100.6891) に置き換えられてしまうことが、マウスやキーボードを無効化していた直接の原因です。
検証:USBHUB3.SYS を古いバージョンに戻すと正常に動作
この仮説を証明するため、以下の手順で WinREイメージ内の「USBHUB3.SYS」のみを、正常に動作していた古いバージョン (10.0.26100.1) に手動で置き換える検証を行いました。
- WinRE の無効化:
reagentc /disableを実行して、現在の回復環境を無効化します。 - WinREイメージのマウント: DISM コマンドを使い、
C:\Windows\System32\Recoveryにある「Winre.wim」を一時的なフォルダにマウント(展開)します。 - 「USBHUB3.SYS」の置き換え: マウントしたフォルダ内の
Windows\System32\driversにある、問題の「USBHUB3.SYS (バージョン 10.0.26100.6891) 」を、正常な古いバージョン (10.0.26100.1) のファイルで上書きします。 - WinREイメージのアンマウント: 変更を保存(コミット)して、「Winre.wim」をアンマウントします。
- WinRE の有効化:
reagentc /enableを実行して、修復した回復環境を再度有効化します。
その結果、回復環境を起動したところ、マウスとキーボードは問題なく正常に動作することを確認しました。
この検証により、「USBHUB3.SYS」が不具合の直接的な原因であることが確定しました。
当サイトで配布している自動化バッチファイルは、「Winre.wim」全体を正常なものに入れ替えるため、この問題の根本的な解決策となります。Microsoft からの公式な修正も、この「USBHUB3.SYS」を修正する形で行われるものと思われます。
USBHUB3.SYS とは何者か?
今回の不具合の根本原因である「USBHUB3.SYS」。Microsoft の公式ドキュメントには、その役割が以下のように書かれています。
USB hub driver (Usbhub3.sys)
The new hub driver, in the USB driver stack for 3.0 devices, uses the KMDF driver model. The hub driver primarily performs these tasks:
- Manages USB hubs and their ports.
- Enumerates devices and other hubs attached to their downstream ports.
- Creates physical device objects (PDOs) for the enumerated devices and hubs.
Windows loads the hub driver as the FDO in the hub device stack. Device enumeration and hub management in the new driver are implemented through a set of state machines. The hub driver relies on KMDF for power management and PnP functions. In addition to hub management, the hub driver also performs preliminary checks and processing of certain requests sent by the USB client driver layer. For instance, the hub driver parses a select-configuration request to determine which endpoints will be configured by the request. After parsing the information, the hub driver submits the request to the USB host controller extension or further processing.
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-3-0-driver-stack-architecture
これを分かりやすく解説すると、「USBHUB3.SYS」は USB 3.0 ポート全体の『支配人』や『交通整理官』のような、極めて重要な役割を担っているということです。
USBHUB3.SYS の主な仕事
Microsoft の解説によると、この「支配人」の主な仕事は以下の通りです。
| 仕事内容(Microsoftの解説) | 分かりやすい例え(支配人の仕事) |
| USBハブとそのポートを管理する | ビルのフロア(ハブ)と各部屋のドア(ポート)を管理する。 |
| ポートに接続されたデバイスを列挙する | 新しい客(USB 機器)が来たら、身元を確認し、宿泊者名簿に登録(列挙)する。「キーボード様、ご到着です」とシステムに知らせる。 |
| 列挙したデバイスの PDO を作成する | 登録した客(USB 機器)に対して、部屋の鍵(PDO という ID)を発行する。これにより、システムはその客を個人として認識し、やり取りができるようになる。 |
| クライアントドライバーからの要求を処理・転送する | 客(マウスドライバーなど)からの「お湯が欲しい」というリクエストを受け取り、内容を確認し、ボイラー室の担当者(コントローラードライバー)に正確な指示を伝える。 |
もし、この「支配人」に問題があったらどうなるか?
今回の不具合は、まさにこの「支配人(USBHUB3.SYS)」自身に深刻なバグがあった状態です。
- 宿泊者名簿に登録できない(列挙の失敗):支配人が機能不全に陥っているため、新しい客(マウスやキーボード)が来ても、その存在に気づかず、宿泊者名簿に登録(列挙)することができません。
- 部屋の鍵を発行できない(PDO の作成失敗):名簿に登録できないため、当然、部屋の鍵(PDO)も発行されません。
その結果、システム(Windows)にとっては、マウスもキーボードも「このビルには存在しない客」ということになってしまいます。だから、USBポートに何を接続しても、カーソルは動かず、キー入力も一切受け付けられなかったのです。
このように、「USBHUB3.SYS」は単なる部品の一つではなく、USB デバイスがシステムに認識されるための最初の関門であり、最も重要な役割を担っています。この支配人が機能不全に陥れば、その先の全ての USB 通信が停止してしまうのは、当然の結果です。
Microsoft への報告と、修正を早めるためにできること
当サイトでは、この Windows 回復環境の不具合について、詳細な検証結果と共に Microsoft のフィードバックHub へ正式に報告済みです。
当初、皆様に Upvote(賛成票)を募るため共有リンクの掲載を試みましたが、筆者の環境ではリンクが Windows Insider Program 参加者専用として生成されてしまい、多くの方がアクセスできない状態にあることが判明しました。
ご不便をおかけしてしまい、大変申し訳ございません。
報告自体は Microsoft の担当チームに届いておりますので、今後の公式な修正をお待ちいただければと思います。
2025/10/21【重要追記】インストールメディアからの修復と、そこに潜む「罠」
多くの読者様から、「メディア作成ツールで作成した USBメモリから起動すれば、問題なく回復環境が使えた」というご報告をいただいています。これは完全に正しい情報であり、有効な回避策の一つです。
なぜ、USBメディアから起動すると使えるのか?
その理由は、PC が起動する「回復環境」が 2種類あるためです。
- PC本体の回復環境: PC の HDD/SSD 内にあり、「winre.wim」が使われます。これは Windows Update によって不具合のあるバージョンに汚染されています。
- インストールメディアの修復環境: USBメモリの中にあり、「boot.wim」という別のイメージが使われます。
USB から PC を起動(USB ブート)すると、PC 本体の壊れた回復環境(winre.wim)は一切使用されず、USBメモリの中にある、独立した修復用の小さな OS(boot.wim)が起動します。だから、マウスもキーボードも正常に動作するのです。
【警告】メディア作成ツールで作成したUSB内に含まれる winre.wim は使ってはいけない
しかし、ここに非常に重要な「罠」があります。
筆者が実際に最新のメディア作成ツールでダウンロードされる ISO ファイルを検証したところ、その中に含まれている「winre.wim」のバージョンは、不具合の発生する 10.0.26100.6891 でした。
つまり、この USBメディアは「起動して使う」分には問題ありませんが、その中にある「winre.wim」を「PC 本体の修復用にコピーして使おう」とすると、結局同じ不具合を PC にインストールしてしまうことになるのです。
※公式ページから直接ダウンロードした ISO ファイルに含まれる「winre.wim」は問題ありません。
2025/10/29:Windows 11 メディア作成ツールは、2025/10/28 に新しいバージョン 10.0.26100.7019 に更新されましたが、ISO ファイルに含まれる「winre.wim」のバージョンは、不具合の発生する 10.0.26100.6891 のままであることを確認しました。
まとめ
| 実行する方法 | 使われるイメージ | 結果 |
| USBブートで「コンピューターの修復」 | 「boot.wim」 | OK 👍 |
| ISO 内の「winre.wim」を PC にコピー | 「winre.wim」 | NG 👎 (不具合あり) |
このことから、Microsoft から公式な修正パッチがリリースされるまでの間、PC 本体の回復環境を根本的に修復するには、本記事で解説している自動化バッチファイルを使い、正常に動作することが確認されているバージョンの「winre.wim」を適用する方法が現時点で最も確実な手段となります。







