https://error-daizenn.hatenablog.com/entry/2025/10/21/221529

2025年10月14日に配信されたWindows 11のセキュリティ更新プログラム「KB5066835」。
その目的は、なんと175件もの脆弱性（vulnerability）を修正するという、過去最大級のセキュリティ強化でした。
しかし、蓋を開けてみるとこのアップデートが、開発者や企業ユーザーに深刻なトラブルをもたらしていることがわかりました。

Microsoft（マイクロソフト）が「安全性を高めるため」に配布したこの更新が、結果としてシステムの安定性を大きく崩してしまったのです。
「セキュリティを守ったはずが、開発環境が壊れた」――そんな声が世界中で広がっています。

特に影響を受けたのは、開発現場で日常的に使われるlocalhost（ローカルホスト）通信と、日々の作業に欠かせないファイルエクスプローラー（File Explorer）のプレビュー機能。
この2つが同時に壊れたことで、「コーディングができない」「ファイルの中身が見えない」といった混乱が各地で報告されています。

この記事では、KB5066835によって起きた不具合の内容・原因・Microsoftの対応、そして一時的な回避策までを詳しく解説します。
さらに、開発者コミュニティや企業IT担当者の声を交えながら、セキュリティと安定性の両立という難題についても考えていきます。

発生概要：2025年10月14日配信のKB5066835が引き起こした“修正による破壊”

この問題は、Microsoftが2025年10月の「Patch Tuesday（パッチ火曜日）」で配信したセキュリティ更新プログラム「KB5066835」を適用した直後から発生しました。
当初は「セキュリティ強化の大型アップデート」として歓迎されていましたが、配信後数時間で、開発者や企業ネットワーク管理者から通信エラー・プレビュー表示不能などの報告が相次ぎました。

特に被害が顕著だったのがlocalhost（ローカルサーバー）通信の途絶です。
開発環境でアプリをテストする際、ほとんどのプログラマーは127.0.0.1（ループバックアドレス）を使ってローカルサーバーを動かしています。
しかし、今回の更新を適用するとHTTP/2プロトコルでの通信がリセットされ、アプリが起動できず、デバッグが止まるという事態に。

開発者にとってこれは、まさに「心臓が止まるようなエラー」でした。
Visual StudioでWebアプリを実行しても、即座に「connection reset（接続がリセットされました）」のエラーが出て動かない。
この現象があらゆる開発現場で再現しており、Microsoftのフォーラムでは“ローカルでHTTP/2を使う開発者全員が影響を受ける”との警告も出ています。

一方、通常のインターネット接続やWebブラウジングには影響がないため、問題の発覚は遅れがちでした。
「本番環境では動くのに、テストでは動かない」という不思議な現象に、多くの開発者が首をかしげることになったのです。

修正したのは175件の脆弱性、しかし新たな不具合が続出

Microsoftはこの更新で、175件もの脆弱性を修正したと発表しました。
その中には**ゼロデイ攻撃（zero-day exploit）**に関連するものも含まれており、緊急度の高いパッチでした。
しかし、その規模の大きさこそが問題だったのかもしれません。

複数のセキュリティジャーナル（Cyber Insider、CNETなど）によると、KB5066835にはネットワークプロトコルとシステム描画処理に関する大幅な改変が含まれていました。
この結果、想定外の副作用がいくつも発生し、以下のような不具合が確認されています。

・localhost通信の失敗（HTTP/2がリセットされる）
・ファイルエクスプローラーのプレビューが読み込めない
・インストール時に「エラーコード 0x800f0982」などが出る
・開発ツール（Visual Studio、Docker Desktopなど）が通信不能になる

特に、File Explorerのプレビューウィンドウが動かなくなる現象は一般ユーザーにも影響を与えています。
WordやPDFファイルのサムネイルが表示されず、ファイルを開かないと中身が確認できないという不便な状態。
Microsoftのサポートページにも「プレビュー関連のレンダリングが失敗するケースを認識している」と記載されました。

つまり、セキュリティの“修正”が、ユーザー体験の“破壊”を引き起こしたのです。

localhost（127.0.0.1）通信が失敗、開発者環境でHTTP/2がリセットされる問題

最も深刻なのは、開発現場でのlocalhost通信障害です。
WebProNewsやThe Registerによると、この不具合はHTTP/2通信を扱う開発環境で発生し、localhost（127.0.0.1）宛てのリクエストが接続リセットされることで、開発サーバーが立ち上がらなくなります。

たとえば、Visual StudioやNode.jsのローカルサーバー、Docker上で動作するAPIテスト環境などで、開発者がブラウザでhttp://localhostにアクセスすると、「ERR_CONNECTION_RESET」が表示される。
原因は、KB5066835の中で変更された**ネットワークスタック（network stack）**の構成にあると見られています。

Microsoftはすでにこの現象を再現し、サポートフォーラムで次のように認めています。

「KB5066835の適用後、一部の環境でHTTP/2通信を利用するlocalhost接続がリセットされる問題を確認しています。
この不具合により、開発サーバーとの通信が断続的に失敗する場合があります。」

つまり、これは単なる偶発的な不具合ではなく、セキュリティ修正の副作用として明確に再現可能なバグということです。

さらに、この影響は開発者にとどまりません。
一部の企業システムでは、社内で運用するローカルWebアプリが同じループバック通信を使用しており、社内ポータルが動かなくなるケースも報告されています。
Microsoftは「Hotfix（緊急修正版）を最優先で準備中」と発表していますが、具体的な配信日はまだ示されていません。

File Explorerのプレビュー機能が動作しない現象も確認

もう一つの大きなトラブルが、File Explorer（ファイルエクスプローラー）でプレビューが表示されないという現象です。
この問題は、ファイルのサムネイル（縮小表示）やドキュメントのプレビューが真っ白になる、または読み込み中のまま止まる、という形で現れます。

Windows Latestによると、この現象は描画エンジン（rendering engine）の挙動変更に起因している可能性が高いとのこと。
KB5066835では内部的にDirect2DやWinUIの最適化が行われており、その一部がプレビュー処理と衝突しているようです。

Microsoftはまだ公式に「プレビュー問題」を既知の不具合として登録していませんが、複数のフォーラムで**“KB5066835をアンインストールしたら直った”**という報告が相次いでいます。

開発者には通信障害、一般ユーザーには操作の不便――このアップデートは、まさに両側からの悲鳴を招いています。

開発者・企業への影響：デバッグや社内アプリの動作が停止

今回の不具合は、特に開発現場と企業システムで深刻な影響を及ぼしています。
Windows 11の環境下で開発を行うエンジニアにとって、localhost通信はテストやデバッグに欠かせない仕組みです。
Visual Studio、Docker Desktop、XAMPP、Node.jsなど、あらゆる開発ツールがこの仕組みを前提に設計されています。

そのため、HTTP/2プロトコルでの通信がリセットされるという今回の問題は、**「アプリを起動できない」「APIのレスポンスが返らない」**という形で現れ、開発作業を完全に止めてしまいます。
中でも企業内で独自アプリケーションを構築・運用している部門では、社内サーバーへのアクセスが遮断されるトラブルが報告されています。

さらに、File Explorerのプレビュー機能の停止も業務効率に直結します。
ファイル名や拡張子だけで判別できないドキュメントを多数扱う部署では、プレビュー非表示によって確認作業が大幅に遅れることになりました。
特に設計部門やクリエイティブ職では、「サムネイルが見えないだけで日常業務が止まる」という声も。

つまり、KB5066835はセキュリティ向上を目的としながら、結果的に“業務停止”を引き起こす逆説的なアップデートになってしまったのです。

Microsoftの公式見解と緊急Hotfix（修正版）準備状況

Microsoftはこの問題を迅速に認識し、10月20日付で公式フォーラムに声明を発表しました。
そこでは以下のような文面が確認されています。

「KB5066835の適用後、一部の環境においてlocalhost通信がリセットされる、またはFile Explorerのプレビューが正しく動作しない問題を確認しています。
当社は原因を特定済みであり、近日中にHotfixをWindows Update経由で提供する予定です。」

CNETの報道によると、すでに修正版は社内テスト段階にあり、「数日以内に配信開始予定」とのことです。
このHotfixはネットワークスタックとレンダリングエンジンの両方を調整する形でリリースされる見込みで、HTTP/2通信リセットの修正が最優先項目とされています。

なお、Microsoft Learnに掲載された情報によれば、このような緊急パッチは「累積更新パッケージ」として配信されるため、KB番号が変更される可能性があるとのこと。
つまり、修正版が出た際は、新しい番号（例：KB5066950など）で表示される可能性が高いというわけです。

不具合の原因（推定）：ネットワークスタックと描画システムの衝突

複数の専門サイト（Bleeping Computer、Windows Latest、The Registerなど）の分析によると、今回のバグは2つの要素が絡み合って発生したと考えられています。

1つ目は**ネットワークスタック（network stack）**の変更です。
MicrosoftはKB5066835でHTTP/2およびHTTP/3通信に関する暗号化とセキュリティ制御を強化しました。
しかし、この強化によってlocalhost通信でも証明書検証が働くようになり、自己署名証明書を使う開発環境でリセットが発生したとみられます。

2つ目は**描画システム（rendering system）**の調整。
File Explorerではプレビュー表示の際、内部でサンドボックス化されたプロセスを起動します。
ところが、今回の更新でこのプロセスが正しく署名を確認できず、描画が途中で止まる現象が起きているようです。

要するに、どちらも「セキュリティ強化を目的とした変更」が引き金でした。
安全性を高めるための改修が、機能そのものを壊してしまった――まさに現代のアップデートジレンマです。

一時的な回避策：HTTP/2無効化・アップデートのロールバック手順

Hotfixが配信されるまでの間、ユーザーが取れる暫定的な対応策がいくつかあります。

(1) HTTP/2を一時的に無効化する
管理者権限のコマンドプロンプトで以下を入力します。

reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2 /t REG_DWORD /d 0 /f

これでHTTP/2が無効化され、localhost通信がHTTP/1.1で動作するようになります。
再起動後、開発環境で接続が回復することが多いです。

(2) KB5066835をアンインストールする
コントロールパネル → プログラムと機能 → インストールされた更新プログラムを表示 → KB5066835を右クリック → アンインストールを選択。
ただし、175件の脆弱性修正も同時に削除されるため、セキュリティ上のリスクが高くなります。

(3) システムの復元ポイントを利用する
更新直前に自動生成された復元ポイントがあれば、その状態へ戻すのが最も安全です。

(4) 企業環境では、更新一時停止を設定する
ドメイン管理者は、グループポリシー（gpedit.msc）を使って更新配信を一時的に止めることができます。

どの方法も恒久的な解決策ではありませんが、**緊急の業務継続には有効な“つなぎ”**になります。

企業システムでの注意点：更新停止のリスクと判断ポイント

セキュリティ修正を含む更新を止めるのはリスクも伴います。
Cyber Insiderによると、KB5066835で修正された175件のうち、少なくとも3件はゼロデイ攻撃（zero-day exploit）に関連する脆弱性だと報告されています。
つまり、更新を保留することでサイバー攻撃の標的になる危険性もあるのです。

そのため、企業IT部門では「部分的な更新停止」という折衷策をとるケースが増えています。
たとえば、開発者環境やテストサーバーのみKB5066835を除外し、一般社員の業務用端末には適用する――といった運用です。

“更新を止めるか、機能を止めるか”という二択を迫られているのが、今回の最大の問題と言えるでしょう。

専門家の意見：「セキュリティ強化と安定性は両立できるのか」

セキュリティ研究者のエリック・ソーン氏（CyberSec Labs）はこう指摘しています。

「ゼロデイ攻撃への即応性は評価すべきだが、検証不足の更新を急ぐとシステム全体を不安定にする。
今回のように、企業と開発者が両方で打撃を受けるのはテスト体制の課題だ。」

また、ソフトウェア品質保証の専門家ジェナ・ホール氏は、次のような見解を示しました。

「セキュリティと安定性は二律背反ではなく、テスト工程の設計次第で両立できる。
ただし現状のWindowsアップデートサイクルはあまりに速すぎ、QA（品質保証）が追いついていない。」

つまり、Microsoftの課題は単なるバグ修正ではなく、**“信頼を取り戻すための仕組み作り”**にあるというわけです。

他ユーザーの声：開発フォーラムとRedditで飛び交う報告

RedditやGitHubのIssueトラッカーでは、「KB5066835が原因で開発が止まった」という投稿が急増しています。
一部ユーザーは「HTTP/2を切れば動いた」と報告する一方で、「アップデート後、再起動ループに入った」という深刻な例もありました。

ある開発者はこうコメントしています。

「パッチを当てるたびに新しいトラブル。セキュリティを守るために生産性を犠牲にするのは本末転倒だ。」

まるで“パッチ疲れ”のような空気が漂う中、Microsoftへの信頼が試されている状況です。

まとめと議論：「あなたの環境ではKB5066835は安全だった？」

今回のKB5066835問題は、セキュリティと安定性という2つの軸のバランスをどう取るかという永遠のテーマを浮き彫りにしました。
175件の脆弱性を塞ぎながら、開発者の環境を止めてしまう――それが現代のWindowsアップデートの現実です。

あなたのWindows 11ではどうでしたか？
・File Explorerのプレビューは動いていますか？
・localhost通信は正常に動作していますか？
・それとも更新を見送っていますか？

コメント欄で、あなたの状況や回避策を共有してください。
このフォーラムでは、実際の体験談や検証結果をもとに、より安全で快適なWindows運用方法を一緒に考えていきましょう。

あなたの一言が、次のアップデート改善のヒントになるかもしれません。