カテゴリー: Windows

Windows 11 セキュリティパッチ KB5068861 ― スタートメニュー刷新と既知の不具合

2025年11月、MicrosoftはWindows 11向けの最新セキュリティパッチ「KB5068861」を公開しました。本パッチは、Windows 11 バージョン25H2および24H2を対象とする定例の「Patch Tuesday」更新に位置づけられ、OSビルド番号はそれぞれ26200.7171および26100.7171となっています。

今回の更新では、セキュリティ修正に加え、スタートメニューの刷新やタスクバーの改善など、ユーザーインターフェイスに関わる変更も含まれています。特に、スタートメニューの新しいスクロール表示方式や、バッテリーアイコンの色分け表示など、操作性と視認性の向上が図られました。また、タスクマネージャー終了時にプロセスが残留する不具合の修正や、ハンドヘルド端末での電力効率改善など、システム安定性の向上も目的としています。

一方で、共有フォルダー上の検索が極端に遅くなる、または結果が正しく表示されないといった不具合報告も確認されており、企業環境では適用前の検証が推奨されています。

本記事では、KB5068861の主な変更点、既知の不具合、および適用時の注意点について整理し、安全かつ効果的にパッチを運用するための指針を解説します。

更新概要

KB5068861は、2025年11月11日（米国時間）に配信が開始されたWindows 11向けの定例セキュリティパッチです。対象となるバージョンはWindows 11 25H2および24H2で、適用後のOSビルド番号はそれぞれ26200.7171および26100.7171となります。本更新は、Microsoftの月例更新（いわゆる「Patch Tuesday」）の一環として提供されており、セキュリティ修正と機能改善の双方を含んでいます。

配布経路はWindows Updateを通じた自動配信が基本ですが、Microsoft Update Catalogから手動でダウンロードし、オフライン環境で適用することも可能です。また、企業環境ではWindows Server Update Services（WSUS）やMicrosoft Intuneを経由して配布管理を行うことができます。

今回のパッチでは、Windowsコンポーネントのセキュリティ修正に加え、スタートメニュー、タスクバー、タスクマネージャーといったユーザーインターフェイス関連の改良も含まれています。これにより、操作性やシステムの安定性が向上する一方で、特定環境ではパフォーマンス低下の報告もあるため、適用前に環境に応じた検証を行うことが推奨されます。

主な変更点

KB5068861では、セキュリティ修正に加えて、ユーザーエクスペリエンスの向上を目的とした複数の機能改善が実施されています。特に、スタートメニューやタスクバーなど、日常的に利用されるUI要素に関する更新が注目されます。

まず、スタートメニューのレイアウトが刷新され、アプリ一覧がスクロール形式で表示されるようになりました。従来の固定リスト方式に比べて視認性が高く、より多くのアプリを効率的に操作できる設計となっています。また、アプリグループやカテゴリ管理の柔軟性も向上し、ユーザーインターフェイスの一貫性が改善されています。

次に、タスクバーのバッテリーアイコンが改良され、残量に応じて色が変化するようになりました。緑は充電中または高残量、黄は省電力モード、赤は低残量を示し、視覚的に状態を把握しやすくなっています。加えて、バッテリー残量を常時パーセンテージ表示できる設定が新たに導入されました。

タスクマネージャーでは、終了時にプロセスが残留する不具合が修正され、システムリソースの解放処理がより安定化しました。また、一部のハンドヘルドPC（携帯型ゲーミングデバイスなど）で発生していた低消費電力モードへの移行不具合も解消され、電力効率が向上しています。

これらの変更により、Windows 11の操作性・安定性・省電力性能が総合的に改善されており、日常利用から業務用途まで幅広い環境での利便性向上が期待されます。

既知の問題と対処法

KB5068861の適用後、一部の環境で不具合が報告されています。これらはすべてのシステムに発生するものではありませんが、企業ネットワークや特定の構成下で注意が必要です。

まず、最も多く報告されているのは、ネットワーク共有フォルダー上でのファイル検索が極端に遅くなる、または結果が正しく表示されないという問題です。特にActive Directoryドメインに参加している環境や、SMB共有を利用する業務システムで影響が確認されています。この不具合はWindows Searchサービスのインデックス処理に関連しているとみられ、Microsoftからの修正版提供は現時点で未定です。暫定的な対処として、該当更新を一時的にアンインストールする、またはローカル検索の利用に切り替える方法が推奨されています。

次に、一部のユーザー環境で更新プログラムのインストールが途中で失敗する事例が報告されています。代表的なエラーコードは「0x80070306（Error 774）」であり、これは破損したシステムファイルや一時的なWindows Updateキャッシュに起因する場合があります。この場合、管理者権限で以下のコマンドを実行し、システムの整合性を確認することが有効です。

DISM /Online /Cleanup-Image /RestoreHealth  
sfc /scannow

それでも改善しない場合は、Microsoft Update Catalogからパッチをダウンロードし、オフラインで手動インストールを行う方法が推奨されます。

また、万一アップデートの適用後に動作異常やパフォーマンス低下が発生した場合は、以下のコマンドでアンインストールが可能です。

wusa /uninstall /kb:5068861

アンインストール後は再起動を実施し、システムの安定性を確認してください。

これらの問題は一部環境に限定されるものの、業務システムを運用する企業では、展開前にテスト環境での検証を行うことが望ましいとされています。

適用時の注意点

KB5068861を適用する際は、事前準備と適用後の確認を適切に行うことが重要です。特に企業環境やドメイン管理下のシステムでは、更新による影響範囲が広いため、慎重な対応が求められます。

まず、更新前には必ずシステムのバックアップを取得してください。システムイメージや重要データのバックアップを取得しておくことで、適用後に不具合が発生した場合でも迅速にロールバックが可能となります。特に、ファイルサーバーや業務アプリケーションを稼働させている端末では、更新適用の前後で動作確認を行うことが推奨されます。

次に、企業環境では段階的な適用が望ましいとされています。まずは検証用端末でKB5068861を導入し、共有フォルダー検索や社内システムへのアクセスなど、業務で利用する主要機能の動作確認を行ってください。問題が発生しないことを確認したうえで、全社的な展開を実施するのが安全です。

また、パッチ適用後はWindows Searchやネットワーク共有機能など、一部の機能で遅延や動作不安定がないかを確認することが望まれます。タスクマネージャーやバッテリー表示などのUI要素に変更が加えられているため、運用マニュアルや社内ヘルプ資料を更新しておくことも有効です。

最後に、更新適用後にエラーやパフォーマンス低下が確認された場合は、イベントビューアーやWindows Updateログを参照して原因を特定し、必要に応じてアンインストールまたは次回更新での修正を検討してください。安定した運用を維持するためには、定例パッチごとの動作検証と記録を継続的に行うことが重要です。

おわりに

KB5068861は、Windows 11の安定性と安全性を向上させるための重要なセキュリティパッチです。スタートメニューやタスクバーといったUIの刷新、タスクマネージャーの安定化、電力効率の改善など、ユーザー体験の向上を意識した更新が多く含まれています。一方で、共有フォルダー検索の遅延やインストール失敗といった不具合も一部で報告されており、環境によっては注意が必要です。

特に企業や組織での運用においては、適用前のバックアップ取得とテスト環境での事前検証が欠かせません。動作確認を行ったうえで段階的に展開することで、想定外のトラブルを回避しやすくなります。また、更新適用後は、イベントログやパフォーマンスモニターなどを活用し、システムの安定性を確認することが推奨されます。

Microsoftは今後の月例更新でさらなる修正や最適化を予定しており、今回のパッチもその一環として位置づけられます。利用者は最新のセキュリティ状態を維持するため、更新の適用を怠らず、継続的な監視と運用体制の整備を行うことが求められます。

参考文献

Windows 11の新スタートメニューに奇妙な不具合 ― アプリが表示されない・リストが勝手にスクロール

Microsoftが2025年10月に配信したWindows 11のプレビュー更新（非セキュリティ更新、KB5067036）では、長らくテストが続いていた新しいスタートメニューが一般ユーザーにも展開されました。これにより「おすすめ」セクションの削除や、1ページ構成のレイアウト改善が実現し、使いやすさが向上したとされています。

しかし、実際に利用してみると、この新スタートメニューにはいくつかの奇妙な不具合が存在していることが明らかになりました。海外メディアNeowinが報告した内容を中心に、問題点を整理します。

不具合1：新規インストールしたアプリが「すべてのアプリ」に表示されない

Neowinの記者が最初に確認したのは、新しくインストールしたアプリがスタートメニューに即座に反映されない問題です。
具体的には、VMware Workstationをインストールしても「すべてのアプリ」一覧にVMwareフォルダーが表示されず、ショートカットも検索結果に出てこないという事象です。

実際には、フォルダー自体は

C:\ProgramData\Microsoft\Windows\Start Menu\Programs

内に作成されており、エクスプローラーから「ファイルの場所を開く」で確認できます。つまり、ショートカットは存在しているにもかかわらず、UI上に反映されないという状態です。

一度エクスプローラーやシステムを再起動すると正常に表示されるようになるため、キャッシュまたはインデックス更新に関わる不具合とみられます。なお、フォルダー構造を作成するタイプのアプリで発生しやすい傾向があるようです。

不具合2：初回クリックでリストが勝手にスクロール

もう一つの問題は、スタートメニューを再起動後に初めて開いた際、任意のアプリをクリックするとリストが勝手に先頭へスクロールするというものです。
たとえば「フォト」アプリを開こうとしても、勝手にリスト最上部に戻ってしまう現象が発生します。

この問題は1回だけ発生する一過性の不具合で、2回目以降は正常動作するとのことです。Microsoftは10月初旬のInsider Build 26220.6780で修正済みとしていますが、一般向け安定版では依然として残っていると報告されています。

品質保証への疑問

これらの不具合は、同記者が複数の環境（メインPC・ノートPC・仮想マシン）で再現したとされています。開発期間が数か月に及んだにもかかわらず、このような基本的なUIバグが残っている点について、記事ではMicrosoftの品質保証体制に疑問を呈しています。

さらに、タスクマネージャーが正常終了せず、プロセスが重複してメモリやCPUを消費する別の既知不具合にも触れ、「AI統合や広告機能の強化ばかりが優先され、基本品質が犠牲になっている」と批判しています。

おわりに

新しいWindows 11のスタートメニューは、デザイン面では明確に進化を遂げています。しかし、現時点ではアプリ表示や動作の安定性に問題が残る状況です。

特に、業務環境などで新アプリを頻繁に導入するユーザーは、表示遅延や誤作動による混乱を避けるため、修正版が正式リリースされるまでアップデートの適用を控えるのが賢明かもしれません。

Microsoftが今後の安定版アップデートでこれらの不具合をどのように修正するのか、引き続き注目する必要があります。

参考文献

噂されるWindows 11「26H1」―Snapdragon X2 Eliteとの関係

Windows 11の次期大型アップデートとして、「26H1」という名称のバージョンが2026年初頭に登場する可能性が報じられています。複数の海外メディア（Neowin、Windows Report、Notebookcheckなど）がこの情報を取り上げており、現時点ではMicrosoftからの公式発表は行われていません。したがって、本件はあくまで噂ベースの情報として扱う必要があります。

報道によれば、この「26H1」アップデートは従来のH2（年後半）リリースとは異なり、特定のハードウェア、特にQualcommの新型プロセッサ「Snapdragon X2 Elite」を搭載したデバイスを対象とする可能性が指摘されています。このチップはTSMCの3nmプロセスを採用し、最大18コア構成や80TOPS級のNPU性能を備えるなど、AI処理を重視した設計が特徴とされています。

本記事では、Windows 11「26H1」に関して現在報じられている情報を整理し、その背景にある技術的意図や、Snapdragon X2 Eliteとの関連性について考察します。なお、記載する内容はいずれも正式発表前の段階に基づくものであり、最終的な仕様やリリース時期は変更される可能性があります。

Windows 11 26H1とは何か

Windows 11「26H1」とは、現時点で正式に発表されていない将来のWindows 11機能更新版を指すとみられる仮称です。「26H1」という名称は、Microsoftがこれまで採用してきた半期リリースの命名規則に基づくもので、2026年の前半（Half 1）を意味します。ただし、Microsoftは現在、Windows 11の年間機能更新を「年1回・後半（H2）」に限定しており、公式なロードマップ上に「H1」リリースは存在していません。そのため、「26H1」という名称はあくまで内部的なビルド系列、または限定的なリリースを示すものと考えられています。

報道各社によると、この「26H1」は従来の全ユーザー向けアップデートとは異なり、特定の新型デバイスを対象にした限定的な更新になる可能性が指摘されています。特に、Qualcommの最新ARMプロセッサ「Snapdragon X2 Elite」を搭載するWindows PC向けに提供される“先行的なOS最適化版”であるとの見方が有力です。このため、既存のx86／AMD／Intelベースのデバイス向けには、同年後半に予定されるとみられる「26H2」更新が一般提供されると予測されています。

また、Windows Insider Program（テストプログラム）においても、「26H1」に関連する明確なビルド番号やリリースブランチは現時点で確認されていません。したがって、「26H1」は現段階では正式な製品名ではなく、リーク情報やOEMメーカー向け準備版の内部呼称である可能性が高いと考えられます。いずれにせよ、Microsoftがこの更新をどのような位置づけで展開するかは、今後の公式発表を待つ必要があります。

26H1が「特定デバイス向け」とされる理由

Windows 11「26H1」が「特定デバイス向け」であると報じられている背景には、Qualcommの新型プロセッサ「Snapdragon X2 Elite」との密接な関係があるとみられます。複数の海外メディア（Neowin、Windows Report、Notebookcheckなど）は、この更新が主にSnapdragon X2 Eliteを搭載するARMベースのWindowsデバイスを対象に提供される可能性が高いと指摘しています。これは、従来のx86系プロセッサ向けWindowsではなく、新世代のARMプラットフォームへの最適化を目的とする「専用対応版」としての性格を持つと考えられています。

Snapdragon X2 Eliteは、TSMCの3nmプロセスで製造され、最大18コア構成、80TOPS級のNPU性能を備えた高性能SoC（System on Chip）です。このチップは、AI推論やローカル生成AI処理など、オンデバイスAIを重視する「Copilot+ PC」戦略の中核を担うとされています。Microsoftは、これらのAI機能を活かすためのOSレベルの最適化を進めており、特にNPUの利用や電力効率、ドライバ互換性など、ハードウェア依存の要素を26H1でサポートする必要があるとみられています。

一方で、従来のIntelやAMDプロセッサを搭載するx86系デバイスは、これらの新しいAIアクセラレータを標準搭載していない場合が多く、Snapdragon X2 Elite専用の機能更新をそのまま適用することは技術的に難しいと考えられます。そのため、MicrosoftはARMデバイス向けに先行して26H1を提供し、一般的なx86デバイス向けには後続の「26H2」で同等または統合された機能を展開する可能性があります。

このように、26H1が「特定デバイス向け」とされるのは、WindowsのARM最適化とAI統合戦略を段階的に進めるための施策であると理解できます。すなわち、Snapdragon X2 Eliteを中心とした新しいハードウェア世代に対応するための技術的基盤整備が、このアップデートの主目的であると推察されます。

Snapdragon X2 EliteとはどんなSoCか

Snapdragon X2 Eliteは、Qualcommが2025年に発表したWindows PC向けのハイエンドSoC（System on Chip）であり、同社が展開する「Snapdragon Xシリーズ」の最新世代に位置づけられています。このチップは、ARMアーキテクチャを採用した次世代ノートPC向けプラットフォームとして設計され、特にAI処理性能と電力効率の両立を重視しています。製造はTSMCの3nmプロセスで行われ、最大18コア構成を備えた新設計のOryon CPUを中心に、高速メモリ（LPDDR5X）、強化されたAdreno GPU、そして80TOPS級のNPU（Neural Processing Unit）を統合しています。

このNPU性能は、オンデバイスAI処理を前提とするMicrosoftの「Copilot+ PC」構想に対応する水準であり、AI生成機能やリアルタイム推論をローカルで実行することを可能にします。また、通信面でもWi-Fi 7およびBluetooth 5.4をサポートし、セキュリティ機能としてQualcomm独自の「Snapdragon Guardian」やハードウェアレベルの暗号化機構を備えています。これらの特徴から、Snapdragon X2 Eliteは従来のARMベースWindowsデバイスよりも明確に高性能化・本格化した「PCクラスSoC」として位置づけられており、MicrosoftがARM版Windowsの普及を再び強化するための鍵となる製品とみられています。

基本仕様

Snapdragon X2 Eliteの基本仕様は、Qualcommがこれまで展開してきたモバイル向けチップとは一線を画す、PCグレードの設計思想に基づいています。製造プロセスにはTSMCの3nm技術が採用され、これにより高い電力効率と発熱抑制を実現しています。CPUにはQualcomm独自設計の「Oryon」コアが搭載されており、最大18コア構成（上位モデルの場合）で動作します。最上位モデル「X2 Elite Extreme」では最大5.0 GHzのブーストクロックが報告されており、シングルスレッド性能の強化が図られています。

キャッシュメモリは最大53 MBとされ、従来モデルに比べて大幅に増加しています。メモリはLPDDR5Xを採用し、最高9,523 MT/sで動作、帯域幅は最大228 GB/sに達します。これにより、マルチスレッド処理やAI推論などのメモリ負荷が高いタスクにおいても、スループットが向上しています。GPUは改良版のAdreno X2を搭載し、グラフィックス性能の向上とDirectX 12 Ultimate対応を目指した最適化が施されています。

また、AI処理を担うNPU（Neural Processing Unit）は80 TOPS（毎秒80兆回の演算）クラスの性能を持ち、ローカル環境での生成AIやリアルタイム推論を可能にする設計です。通信機能としては、Wi-Fi 7とBluetooth 5.4を標準サポートし、5Gモデムの統合もオプションとして提供されます。さらに、セキュリティ面では「Qualcomm SPU（Security Processing Unit）」と「Snapdragon Guardian」により、OSレベルおよびクラウド連携の両面で暗号化とデバイス保護を強化しています。

これらの要素を総合すると、Snapdragon X2 Eliteは従来のモバイル向けARMチップを超え、ノートPC市場におけるx86系CPUの競合製品として位置づけられる高性能SoCであるといえます。MicrosoftのWindows 11における新しいAI機能群を支える基盤としても、極めて重要な役割を担うと考えられます。

性能と目的

Snapdragon X2 Eliteの性能と設計目的は、Windows環境におけるARMアーキテクチャの実用的な性能向上と、AI処理を中心とした新しい計算モデルへの対応にあります。Qualcommは本チップを、従来の「Snapdragon X Elite」シリーズを大幅に上回る性能を持つ次世代プラットフォームとして位置づけており、特にCPU、NPU、GPUの三要素の総合的な性能強化を進めています。

CPU性能については、前世代比で最大50％のマルチスレッド性能向上が報じられており、単純な省電力型モバイルプロセッサではなく、PC用途を前提としたパフォーマンス設計がなされています。高クロック化されたOryonコアと大容量キャッシュにより、従来のARM版Windowsデバイスで課題とされてきたアプリケーション起動の遅延やエミュレーション時の処理負荷が軽減されると見込まれます。特にMicrosoftが提供する「Prism」エミュレーションレイヤーとの組み合わせにより、x86アプリケーションの動作効率が改善される可能性が指摘されています。

AI処理能力については、NPUの80TOPSという演算性能が注目されています。これは、ローカル環境での生成AIモデル実行や、画像・音声認識、CopilotなどのWindows統合AI機能をデバイス単体で処理可能にする水準です。Microsoftが推進する「Copilot+ PC」認定要件では、NPUが40TOPS以上であることが基準とされていますが、Snapdragon X2 Eliteはその2倍の性能を有し、オンデバイスAIの主力チップとして明確に上位に位置づけられています。

GPU面でも、Adreno X2 GPUが採用され、3Dレンダリングや動画処理、AI推論補助などで従来モデルより高い処理効率を示すとされています。これにより、軽量なクリエイティブ用途やAI支援型のグラフィック処理にも対応可能です。

このように、Snapdragon X2 Eliteの目的は、単なる省電力ARMデバイスの拡張ではなく、AIネイティブなWindows環境を実現するための基盤を提供することにあります。Qualcommはこのチップを通じて、ARMアーキテクチャのPC市場での地位を強化し、Microsoftはそれを支えるOS最適化を進めることで、x86依存からの段階的な脱却を目指していると考えられます。

Microsoftがこのタイミングで更新を準備する理由（推測）

MicrosoftがこのタイミングでWindows 11の新たな更新版「26H1」を準備しているとみられる背景には、複数の戦略的要因が考えられます。最大の理由は、Qualcommの新型プロセッサ「Snapdragon X2 Elite」に代表される次世代ARMプラットフォームの登場に合わせ、OS側の最適化を早期に行う必要がある点です。ARMアーキテクチャを採用したWindows PCは、これまで互換性やパフォーマンス面でx86ベースのPCに劣後してきましたが、X2 Eliteの登場によってその差を縮める技術的土台が整いつつあります。Microsoftは、これに合わせてOSの電力管理、スケジューラ、NPU統合APIなどの基盤を調整することで、新しいハードウェアの性能を最大限に引き出すことを狙っていると考えられます。

また、同社が推進している「Copilot+ PC」構想の実現に向けても、Snapdragon X2 Elite対応は不可欠です。Copilot+ PCは、ローカルAI処理を中心としたWindowsエクスペリエンスの強化を目的としており、その要件として高性能NPU（少なくとも40TOPS以上）を搭載することが定義されています。X2 Eliteはこの基準を大幅に上回る性能を持つため、Microsoftにとっては最適なリファレンスプラットフォームとなります。これにより、WindowsのAI関連機能（Copilot、Recall、Cocreatorなど）の実用化と最適化を、既存のx86デバイスよりも早い段階で検証できる環境を整備できるとみられます。

さらに、MicrosoftはWindowsのアップデート戦略を柔軟化し、ハードウェアごとに段階的な機能展開を行う方針を強化していると考えられます。これまでの「全デバイス同時配信」から、「対象デバイス限定の先行配信」へと移行する動きは、Windows 11の23H2や24H2で既に一部見られました。26H1がもしSnapdragon X2 Elite専用の早期アップデートであれば、それは同社がハードウェア最適化型リリースモデルを試験的に拡大している一例といえます。

以上の点から、Microsoftがこの時期に新たな更新を準備しているのは、単なるスケジュール上の都合ではなく、次世代ARMデバイスの市場投入とAI機能群の強化という二つの流れを同時に前進させるための戦略的判断であると推察されます。

現時点での不確定要素

現時点において、Windows 11「26H1」に関する情報はすべて非公式であり、複数の点で不確定要素が残されています。まず、Microsoft自身が「26H1」という名称を正式に使用した事実は確認されていません。現在も同社の公式ドキュメントやWindowsリリース情報ページでは、機能更新は「年1回・H2（後半）」の提供方針が明示されており、H1（前半）リリースに関する記載は存在していません。そのため、「26H1」は開発コードやテストブランチを指す内部的な呼称である可能性が高いと考えられます。

また、この更新が実際に一般ユーザーへ配信されるかどうかも不明です。報道では、Snapdragon X2 Eliteを搭載した一部のARMデバイス向けに限定的な形で提供されるとの見方が多いものの、対象デバイスや配信範囲、配信経路（OEM限定・Insider Program限定など）は明らかにされていません。特に、既存のx86系デバイスに26H1が展開されるか、あるいは別バージョン（26H2など）として後追い提供されるのかについては、確たる情報が得られていません。

さらに、更新内容そのものについても詳細が不明です。NPU最適化やAI機能拡張、電力効率改善といった方向性が示唆されていますが、どの機能が実際に含まれるかは確認されていません。特にCopilot関連の新機能やRecallなどのAI要素が搭載されるかどうかは、Microsoftの今後の発表に依存します。

このほか、Windows Insider Programにおける関連ビルド（いわゆるRS_PRERELEASEやGE_RELEASEブランチなど）の出現も現時点では確認されていません。したがって、26H1はあくまで開発・検証段階にある可能性が高く、現段階で一般提供を前提とした確定情報とは言えません。結論として、26H1の存在、対象範囲、提供時期、機能内容のいずれもが現時点では推測の域を出ておらず、今後のMicrosoftおよびOEM各社の公式発表が確定情報を得る唯一の手段といえます。

今後注視すべきポイント

今後、Windows 11「26H1」に関して注視すべきポイントはいくつかあります。第一に、MicrosoftおよびQualcommからの正式な発表の有無です。現時点では、両社とも「26H1」やそれに相当する機能更新版に関する公式声明を出していません。もし今後、MicrosoftがWindows Insider Program向けに新しいブランチやビルドを公開した場合、それが26H1の存在を裏付ける最初の確証となる可能性があります。また、Qualcomm側がSnapdragon X2 Elite搭載デバイスの具体的な発売時期やOEMパートナーを発表することで、対応するWindowsバージョンの位置づけが明確になることも予想されます。

第二に、OEMメーカー各社（Microsoft、Lenovo、HP、ASUS、Samsungなど）の製品発表動向です。これらのメーカーがSnapdragon X2 Eliteを搭載したWindowsデバイスを2026年前半に投入する場合、そのプリインストールOSとして26H1が採用されるかどうかが注目点となります。特にMicrosoftが自社製品であるSurfaceシリーズにおいてX2 Eliteを採用する場合、それは26H1の商用利用開始を意味する可能性があります。

第三に、WindowsのAI機能群の展開状況です。Microsoftは2024年以降、「Copilot」「Recall」「Cocreator」などのAI機能を順次拡張しており、これらが次期更新でどのように進化するかが焦点となります。Snapdragon X2 Eliteは80TOPS級のNPU性能を備えているため、これを活かすための新しいAI APIやタスクスケジューリング機構が26H1で導入される可能性があります。したがって、AI関連の機能追加や要件変更に関するMicrosoftの発表は、OS更新の方向性を把握するうえで重要な指標になります。

最後に、Insider Program参加者や開発者コミュニティからのフィードバック動向も重要です。過去の大型更新と同様、プレビュー版での不具合や性能検証結果が正式版の提供時期に影響を与える可能性があります。特にARMベースのWindows機は互換性検証の負荷が高く、初期段階でのユーザー報告がリリース計画の調整要因となる場合があります。

MicrosoftおよびQualcommからの正式発表、Snapdragon X2 Elite搭載機の発売タイミング、AI機能の拡張計画の3点が、今後26H1に関する動向を見極める上での最重要項目であるといえます。

おわりに

現時点で報じられている情報を総合すると、Windows 11「26H1」は正式発表前の段階にあり、Microsoft内部で開発または検証が進められているとみられる更新版です。複数の報道によれば、このアップデートは従来の全デバイス向け機能更新とは異なり、Qualcommの最新ARMプロセッサ「Snapdragon X2 Elite」を搭載するデバイスを主な対象とした限定的なリリースになる可能性が指摘されています。X2 Eliteは3nmプロセス、最大18コア、80TOPS級NPUを備える高性能SoCであり、Microsoftが推進する「Copilot+ PC」戦略やオンデバイスAI処理の中核を担うチップとして期待されています。

このような背景から、26H1は単なる機能追加ではなく、新しいハードウェア世代に最適化された「ARMネイティブ環境への移行版」としての位置づけを持つと考えられます。特に、AI機能群の強化や電力効率の最適化、NPU対応のAPI整備といった、次世代のWindowsプラットフォームを見据えた基盤的更新である可能性が高いといえます。

ただし、Microsoftからの公式発表はまだ行われておらず、リリース時期、対象範囲、機能内容のいずれも確定していません。報道内容はすべて現時点での推測またはリーク情報に基づくものであり、最終的な製品仕様とは異なる場合があります。そのため、今後の動向を把握するには、MicrosoftおよびQualcommの正式な発表、ならびにSnapdragon X2 Elite搭載デバイスの市場投入スケジュールを継続的に注視することが重要です。

参考文献

Windows 11更新KB5067036でタスクマネージャーが終了しない不具合 ― Microsoftが既知問題として調査中

2025年10月28日、MicrosoftはWindows 11向けにプレビュー版の累積更新プログラム「KB5067036」を公開しました。この更新は、正式配信前に機能改善や不具合修正を先行適用できる「オプション更新（プレビュー更新）」として提供されており、対象はWindows 11 バージョン24H2および25H2です。

本更新では、エクスプローラー（File Explorer）の動作安定性向上や一部のエラー修正などが含まれており、次回の定例更新に向けた検証目的で配信されています。しかし同時に、一部環境において「タスクマネージャーが終了しない」という不具合が報告されており、Microsoftも公式に調査中であることを明らかにしています。

この記事では、このKB5067036に関する不具合の詳細、Microsoftの公式対応状況、そして現時点での回避策について整理します。

不具合の内容

今回報告されている不具合は、タスクマネージャー（Task Manager）を「×」ボタンで閉じた際に、プロセスが正しく終了しないというものです。通常であれば、ウィンドウを閉じると同時にタスクマネージャーのプロセス（taskmgr.exe）は停止しますが、本更新「KB5067036」を適用した環境では、バックグラウンドでプロセスが残留する事例が確認されています。

この状態で再度タスクマネージャーを開くと、新たなインスタンスが起動し、既存のプロセスと並行して動作を続けます。その結果、複数のtaskmgr.exeが同時に稼働し、CPUやメモリなどのシステムリソースを無駄に消費する可能性があります。特にメモリ容量の少ない端末や常時監視ツールを併用している環境では、体感的なパフォーマンス低下が生じることもあります。

この不具合はWindows 11 バージョン24H2および25H2のプレビュー更新を適用した一部の環境で確認されており、Microsoftも公式の「Windowsリリース健康ダッシュボード」において既知の問題として登録しています。現時点で恒久的な修正は提供されていませんが、Microsoftは調査を進めており、今後の更新プログラムで修正される見込みです。

KB5067036に含まれるその他の修正・既知の不具合

本更新プログラム（対象： Windows 11 バージョン 24H2／25H2）には、タスクマネージャー関連の不具合以外にも複数の修正項目および既知の問題が含まれています。

修正済みの主な項目

  • ドライバーのインストール時に「エラー 0x80070103」が発生していた問題について改善が含まれています
  • サーバー側アプリケーションで HTTP.sys を使用している環境において、ウェブサイト（例： Internet Information Services）が読み込めず「ERR_CONNECTION_RESET」等のエラーが発生していた問題が、この更新により解消されています
  • 著作権保護コンテンツの再生に失敗していた環境に対し、保護コンテンツ再生機能の改善が含まれています
  • ファイル・エクスプローラー（File Explorer）で大容量アーカイブ（例：1 GB以上）の展開時に「Catastrophic Error（0x8000FFFF）」が発生していたという報告を受け、本更新で改善が行われています

既知の問題（報告ベース／公式アナウンス含む）

前述のタスクマネージャーの問題以外について、Microsoftは既知の問題として認識していません。しかし、他の複合的な運用報告として「更新インストール失敗」や「システム起動不能（Auto Repairモード）となる」可能性が散見されていますが、これらは公式に「既知の問題」として明記されていないため、リスクとしては監視が必要です。

以上のように、KB5067036は機能改善・不具合修正を多方面で実施している更新プログラムですが、運用環境においては未解決の既知問題も併存している点を踏まえて、導入時には慎重な検討が求められます。

Microsoft 公式対応状況

1. リリース概要
この更新は、Windows 11 バージョン 24H2 および 25H2 を対象とした、非セキュリティの「プレビュー」更新プログラムです。目的は「機能、パフォーマンス、および信頼性の改善」です。

2. 既知の問題の公表状況
公式リリースノートでは、KB5067036 に対して「現在既知の問題なし（No known issues）」と記載されています。
ただし、公式「リリースヘルスダッシュボード」には、この更新を起点とする「タスクマネージャーが閉じた後もバックグラウンドで実行し続ける可能性がある」という既知の問題が、対応中（Mitigated）として掲載されています。

3. 回避策・運用指針

  • Microsoft は「調査中」である旨を記載しており、恒久的な解決策の時期について明示されていません。
  • 運用者に対しては、該当更新の適用にあたって影響をモニタリングするよう促されています。
  • 業務環境では、安定性確保のためプレビュー更新の適用を慎重に検討すべきという判断材料となります。

4. 今後の見通し
Microsoft はこの不具合の修正を「次期更新またはパッチで提供する予定」と案内しており、適用時期は明確にはされていません。現時点では回避策運用が現実的な対処です。

このように、KB5067036 に対して Microsoft は既知の問題を認識し、調査・修正対応中としており、運用者はその情報を踏まえた適用判断が求められます。

影響と今後の見通し

今回のKB5067036に含まれる不具合は、タスクマネージャーが終了後もバックグラウンドで動作を継続するという挙動であり、一般的な利用環境においてもリソース消費の増加やパフォーマンス低下を引き起こす可能性があります。特にメモリ搭載量が少ない端末や複数アプリケーションを同時に実行する環境では、動作の遅延やシステム負荷の上昇といった影響が顕著になるおそれがあります。

Microsoftは本件を公式に既知の問題として認識し、修正に向けた対応を進めていますが、現時点（2025年11月初旬）では恒久的な修正パッチはまだ提供されていません。そのため、今後の定例更新、特に**2025年11月12日に予定されている月例更新（Patch Tuesday）**において、もしこの不具合が修正対象として反映されない場合、同様の事象が正式版更新を通じて広範囲に再現されるリスクがあります。

プレビュー更新で発生した問題が月例更新へ引き継がれるケースは過去にも確認されており、特に今回のようにタスクマネージャーというシステム管理ツールに関わる不具合は、運用管理者にとって影響が大きいものです。したがって、業務端末や検証環境を運用している場合は、今後の更新配布前後におけるMicrosoftのリリースノートやリリース健康ダッシュボードの内容を注視する必要があります。

なお、プレビュー更新を未適用の環境では、修正版の正式配布が確認されるまで適用を控えることが安全策といえます。既に適用済みの場合は、タスクマネージャーの挙動とリソース使用状況を継続的に監視し、異常が見られる場合は手動終了や一時的な回避策を実施することが推奨されます。

おわりに

KB5067036は、Windows 11の機能改善や安定性向上を目的としたプレビュー更新として提供されていますが、その一方でタスクマネージャーが正常に終了しないという不具合が確認されており、Microsoftも公式に既知の問題として認識しています。現時点では恒久的な修正が行われておらず、今後の定例更新で対応が予定されている段階です。

この不具合は、システムの動作停止やデータ損失といった重大障害には直結しないものの、長時間利用時におけるパフォーマンス低下や運用監視への影響を引き起こす可能性があります。特に企業や業務端末では、プレビュー更新の適用を制御し、安定版としての修正版公開を待つ判断が望ましいといえます。

Windows Updateは利便性向上と同時に、新機能導入や構成変更を伴うため、プレビュー段階での検証と慎重な導入判断が今後も重要です。管理者や利用者は、Microsoftの公式リリース情報やリリース健康ダッシュボードを定期的に確認し、更新適用前後のシステム挙動を監視することで、予期せぬトラブルの影響を最小限に抑えることができます。

参考文献

Windows 11大型アップデートの光と影：知っておくべき5つの衝撃的な真実

Windowsの新しい大型アップデートと聞けば、多くのユーザーが胸を躍らせるでしょう。より洗練されたデザイン、革新的な機能、そして向上した生産性。Microsoftが提供する未来への期待は尽きません。しかし、最新のWindows 11プレビュー版が明らかにしたのは、単なる輝かしい未来だけではありませんでした。そこには、魅力的な新機能の「光」と、早期導入者が直面する深刻なリスクという「影」が、はっきりと存在していたのです。この記事では、公式発表の裏に隠された5つの衝撃的な真実を、ユーザーの生の声と共に深く掘り下げていきます。

1. スタートメニューがiPad風に大変身、しかしカスタマイズ性は向上

今回のアップデートで最も大きな変更が加えられたのが、Windowsの顔とも言えるスタートメニューです。そのデザインは大きく刷新され、メインエリアにはアプリリストが配置され、「カテゴリビュー」と「グリッドビュー」という新たな表示方法が導入されました。特にカテゴリビューは、アプリを種類ごとに自動でグループ化し、まるでiPadのアプリシェルフのような直感的な操作感を提供します。さらに、スマートフォンとの連携を深めるPhone Linkも統合され、スマートフォンから最近の写真や通知を確認したり、テキストメッセージへの返信やスマートフォンの画面表示に直接ジャンプしたりできます。

Microsoftはこの変更を「アプリへのアクセスをより速く、よりスムーズにするために構築された」ものだと説明しています。

この大胆な変更は、長年のWindowsユーザーにとっては大きな驚きかもしれません。しかし業界アナリストの視点で見れば、これはMicrosoftがWindows 8や初期Windows 10の硬直的なデザイン哲学から戦略的に撤退し、長年のユーザーフィードバックに応えた結果です。その証拠に、カスタマイズ性はむしろ向上しています。ユーザーは「おすすめ」フィードを完全に無効化し、より多くのアプリをピン留めできるようになりました。これはユーザーエージェンシー（主体性）を重視する姿勢の表れであり、非常に重要な進化と言えるでしょう。しかし、この洗練されたインターフェースの裏では、システムの根幹を揺るがす問題が静かに進行していました。

2. AI機能が隅々まで浸透、しかしユーザーの反応は賛否両論

Windows 11は、AI機能をOSの隅々にまで深く統合しようとしています。例えば、「Fluid Dictation」は、音声入力中に文法や句読点をリアルタイムで修正するインテリジェントな機能です。また、「Click to Do」を使えば、画面上のテキストを選択するだけで、リアルタイム翻訳や単位変換といった操作がCopilotを通じて可能になります。

これらの機能は、間違いなく日々のPC作業を効率化する可能性を秘めています。しかし、すべてのユーザーがこのAIの波を歓迎しているわけではありません。コミュニティサイトRedditのスレッドでは、あるユーザーが次のような冷ややかなコメントを投稿しています。

もっとAIのダラダラしたやつをあげるよ!!!

この一言は、単なる皮肉以上の意味を持ちます。これは、近年のテック業界全体に見られる「AI機能の肥大化（AI feature bloat）」に対するユーザーの растущую скептицизмを象徴しています。ユーザーは、真の生産性向上よりもマーケティング目的で追加されたと感じるAI機能に、うんざりし始めているのです。最先端の機能が、必ずしもすべてのユーザーに受け入れられるわけではないという現実がここにあります。

3. バッテリーアイコンの進化：小さな改善が大きな満足感を生む

革新的な機能ばかりがアップデートの価値ではありません。時には、地味ながらも実用的な改善が、ユーザー体験を大きく向上させることがあります。タスクバーのバッテリーアイコンに加えられた変更は、その好例であり、ユーザーエクスペリエンスデザインにおける重要な教訓を示しています。

新しいアイコンは充電状態を色で直感的に示し（充電中は緑、20%以下で黄色）、多くのユーザーが長年望んでいたバッテリー残量のパーセンテージ表示もついに実装されました。この新しいアイコンはロック画面にも表示されます。この細やかな改善は、Microsoftがようやく、長年放置されてきた低レベルのユーザーの不満点に対処し始めたというシグナルです。これは、安定した予測可能なユーザー体験が、人目を引く新機能と同じくらい重要であることを同社が理解している証左と言えるでしょう。

4. 最先端の代償：アップデートでUSB機器が動かなくなる悲劇

プレビュー版の導入は、最先端の機能をいち早く体験できる一方で、深刻なリスクを伴います。今回、そのリスクが最も衝撃的な形で現れたのが、ハードウェアの互換性問題でした。Redditには、アップデート後にUSBデバイスが全く機能しなくなったという悲痛な報告が複数寄せられています。

あるユーザーは、「Lenovo T16 Gen1」をアップデートしたところ、すべてのUSB周辺機器が反応しなくなったと報告。また別のユーザーは、「TP-Link」製のUSB Wi-Fiアダプターが機能しなくなり、インターネットに接続できなくなりました。ロールバックすれば正常に動作することから、原因がこのビルドにあることは明らかです。

Microsoftが華々しく新機能を紹介する裏で、ユーザーはPCの基本的な接続性さえ失うという現実に直面しています。これは、Microsoftの先進的な機能開発と品質保証プロセスの間に存在する、看過できない緊張関係を浮き彫りにしています。

5. 基本機能さえも不安定に？ 終わらないアップデートエラーと検索クラッシュ

問題はハードウェアだけに留まりません。Windowsの根幹をなす基本機能でさえ、不安定になるリスクが露呈しています。Redditでは、日常的な操作に深刻な影響を与える問題が報告されています。

  1. アップデートの失敗: 複数のユーザーが、アップデートのインストールがエラーコード 0x800f0983 で失敗する問題を報告しています。
  2. Windows Searchのクラッシュ: OSの重要な機能である検索が、起動直後にクラッシュするという報告も挙がっています。エラーログには twinapi.appcore.dll というコアシステムファイルが原因であることが示されており、問題が表層的なものではなく、OSの根幹に関わる根深いものであることを物語っています。

ここで注目すべきは、報告されている不具合の「種類」です。これらは単なる見た目の不具合ではありません。ハードウェアドライバー（USB）、アップデート機構そのもの、そして検索というコア機能といった、OSの根幹をなすレイヤーでの失敗です。これはプレビュービルドの奥深くに潜在的な脆弱性があることを示唆しており、表面的なバグよりもはるかに深刻な問題です。

おわりに

今回のWindows 11大型アップデートプレビュー版は、まさに「諸刃の剣」です。カスタマイズ性の高いスタートメニューや統合されたAI機能といった革新的な「光」がある一方で、USBデバイスの認識不能や基本機能のクラッシュといった深刻な不安定さという「影」も併せ持っています。

Microsoftが目指すAIドリブンの未来と、ユーザーが求める日々の安定性。この二つのバランスをどう取るかが、今後のWindows 11、ひいては同社の成功を占う試金石となるでしょう。

未来のWindowsを垣間見せる魅力的な進化と、PCが使い物にならなくなるかもしれないという現実的なリスク。あなたは、これらの新機能のために不安定になるリスクを受け入れますか？それとも、安定した正式リリースを待ちますか？

参考文献

WSUSを狙うリモートコード実行攻撃 ― CVE-2025-59287の詳細と防御策

2025年10月下旬、Microsoft Windows Server Update Services（WSUS）において、リモートから任意のコードが実行される深刻な脆弱性「CVE-2025-59287」が報告されました。本脆弱性は、WSUSが受信するデータを不適切に処理することに起因しており、攻撃者が認証を経ずにサーバー上でシステム権限のコードを実行できる可能性があります。すでに実際の攻撃も確認されており、Microsoftは通常の更新サイクルとは別に緊急パッチを配信する異例の対応を行いました。

WSUSは、企業や組織におけるWindows更新管理の中核を担う重要なコンポーネントです。そのため、この脆弱性は単一のサーバーに留まらず、全社的なシステム更新の信頼性にまで影響を及ぼすリスクを内包しています。本記事では、CVE-2025-59287の概要と攻撃の実態、Microsoftによる緊急対応、そして運用者が取るべき対策について整理します。

CVE-2025-59287の概要

CVE-2025-59287は、Windows Server Update Services（WSUS）に存在する深刻なリモートコード実行（RCE）脆弱性です。この問題は、WSUSがクライアントから受け取るデータの逆シリアライズ処理に不備があることに起因しており、細工されたリクエストを送信することで、攻撃者が認証なしにサーバー上で任意のコードを実行できる可能性があります。CVSSスコアは9.8と極めて高く、最も危険な分類に該当します。

この脆弱性は、企業ネットワーク内で広く利用されるWSUSサーバーに直接影響を及ぼすため、攻撃が成立した場合、組織全体の更新配信基盤が制御されるリスクを伴います。Microsoftは2025年10月23日に緊急パッチを公開し、迅速な適用を強く推奨しています。

脆弱性の内容と影響範囲

CVE-2025-59287は、Windows Server Update Services（WSUS）のサーバーコンポーネントにおける「信頼されていないデータの逆シリアライズ（deserialization of untrusted data）」に起因する脆弱性です。攻撃者は、WSUSが利用する通信ポート（既定ではTCP 8530および8531）に対して特定の形式で細工したリクエストを送信することで、サーバー側で任意のコードを実行させることが可能になります。この処理は認証を必要とせず、匿名のリモートアクセスでも成立する点が極めて危険です。

影響を受けるのは、WSUSロールを有効化しているWindows Server環境です。Windows Server 2012、2016、2019、2022、2025など広範なバージョンが対象とされています。一方で、WSUSをインストールしていない、または無効化しているサーバーはこの脆弱性の影響を受けません。Microsoftは、特にインターネットに直接接続しているWSUSサーバーや、ネットワーク分離が不十分な環境において、実際の攻撃リスクが高いと警告しています。

攻撃が成功した場合、攻撃者はシステム権限（SYSTEM権限）を取得し、任意のコマンド実行、マルウェア配置、さらには他のサーバーへの横展開といった被害につながるおそれがあります。そのため、脆弱性の重大度は「Critical（緊急）」とされ、早急なパッチ適用が求められています。

技術的背景（逆シリアライズによるRCE）

この脆弱性は「逆シリアライズ（deserialization）」の処理不備を突く形式のリモートコード実行です。サーバー側が外部から受け取ったバイナリ化されたオブジェクトを復元（deserialize）する際に、入力の検証や型の制限を行っていないため、攻撃者が細工したオブジェクトを注入すると任意の型インスタンスを生成させられます。生成されたインスタンスが持つ振る舞い（コンストラクタやデシリアライズ時のフック処理）を利用して、サーバー側で任意コードを実行させるのが基本的な攻撃パターンです。

WSUSのケースでは、特定のクッキー処理経路（AuthorizationCookie を扱うエンドポイント）を通じて暗号化されたデータが受け渡されます。攻撃者はこれを偽造し、サーバーが復号してデシリアライズする処理に細工データを混入させることで、BinaryFormatter 等の汎用デシリアライザが復元したオブジェクトの副作用を利用してコード実行に持ち込みます。ここで問題となる点は二つあります。第一に、デシリアライズ対象の型を厳格に限定していないこと。第二に、暗号化や署名の検証が不十分だと、外部からの改ざんを検出できないことです。

BinaryFormatter のような汎用的なシリアライズ実装は「ガジェットチェーン」と呼ばれる既存クラスの組み合わせを経由して任意コード実行に至るリスクが既知です。ガジェットチェーンはアプリケーションに元々含まれるクラスのメソッド呼び出しを連鎖させることで、攻撃者が望む副作用（ファイル作成、プロセス起動、ネットワーク接続など）を引き起こします。これが SYSTEM 権限で起こると被害の深刻度は一気に増します。

対策としては原則的に次の方針が有効です。第一に、外部入力をデシリアライズしない設計に改めること。どうしても必要な場合は、安全なシリアライズ形式（たとえば JSON）へ移行し、ホワイトリスト方式で許可する型を明示的に限定すること。第二に、受信データは改ざん防止のため強力に署名・検証すること。第三に、暗号化キー管理と暗号化モードの適切化（IV の扱い等）を徹底すること。最後に、既知の危険なシリアライズライブラリ（例：BinaryFormatter）は使用を避け、プラットフォームが提供する安全策を適用することを推奨します。

ログと検出面では、異常なプロセス生成（例：wsusサービス → w3wp.exe → cmd/powershell）や未承認の外部アクセス試行、失敗／成功したデシリアライズ例外の増加を監視ポイントとしてください。これらは侵害の初期兆候として有用です。

攻撃の確認と実態

複数のセキュリティベンダーおよび当局が、CVE-2025-59287 を悪用する「in-the-wild（実攻撃）」を報告しています。攻撃は主に外部公開された WSUS サーバーを標的とし、既定のポート（TCP 8530/8531）経由で細工したリクエストを送り込み、認証を経ずにリモートコード実行を試みる事例が観測されています。観測された痕跡には異常なプロセス生成（例：wsus サービスから w3wp.exe を経て cmd/powershell が起動される連鎖）や不審なクッキー／復号処理の試行が含まれます。加えて、PoC や攻撃手法の技術情報が公開されたことで、二次的な悪用拡大のリスクが高まっている点にも留意が必要です。

実際の攻撃報告

複数のセキュリティベンダーが、CVE-2025-59287 の「実際の攻撃（in-the-wild exploitation）」を確認したと報告しています。Huntress は 2025-10-23 23:34 UTC 頃から公開された WSUS インスタンス（既定ポート 8530/8531）を狙った攻撃を複数顧客環境で観測したと公表しています。

米国の CISA は同脆弱性を Known Exploited Vulnerabilities（KEV）カタログに追加し、実攻撃の証拠があることを明示しています。これにより組織は優先的に対処するよう求められています。

攻撃の拡大に拍車をかけた要因として、PoC（概念実証）や技術解説が公開された点が挙げられます。報道各社は PoC の存在とそれに伴う悪用の増加を指摘しており、実際に複数の攻撃報告が後追いで確認されています。

これを受けて Microsoft は 2025-10-23 に out-of-band（緊急）パッチを提供し、報告された攻撃に対処するための追加修正版も短期間で出しています。攻撃の痕跡としては、WSUSサービスから IIS プロセス（w3wp.exe）を経て cmd/powershell が生成されるなどのプロセス連鎖や、不審な AuthorizationCookie の復号試行が観測されています。

結論として、CVE-2025-59287 は実際に悪用されていることが確認されており、公開済みの PoC と組み合わせて短期間で被害が拡大するリスクがあります。速やかなパッチ適用と、公開ポート（8530/8531）の遮断、侵害痕跡のログ調査を優先してください。

想定される侵入経路

想定される侵入経路は主に以下の通りです。

  1. インターネット公開された WSUS への直接アクセス
    • WSUS がファイアウォール／プロキシ越しに外部から到達可能で、ポート 8530/8531 が開放されている場合。攻撃者はこれらのポートを通じて細工した AuthorizationCookie を送信し、認証を要さずにデシリアライズ処理を誘導します。
  2. 境界機器の設定ミスやポートフォワーディング
    • DMZ やリバースプロキシの誤設定、あるいは誤ったポート転送により本来内向けのみの WSUS が外部から到達可能になっているケース。これにより外部からのリクエストで脆弱性を突かれます。
  3. 内部ネットワークからの悪用（内部犯行・踏み台）
    • 社内端末や侵害済みホストから WSUS に対して攻撃が行われる場合。VPN 接続やリモートアクセス経路を足掛かりに内部から細工リクエストを送る手法です。
  4. プロキシや中間装置の改竄／MITM によるクッキー注入
    • ネットワーク経路上の装置が侵害されていると、正規トラフィックに細工データや偽 AuthorizationCookie を挿入される可能性があります。暗号検証が不十分だと改竄を検出できません。
  5. 管理用端末の乗っ取りによる設定操作経路
    • 管理者の作業端末や自動化ツール（管理スクリプト、CI 等）が侵害され、正規の管理操作に偽装して悪意あるデータを WSUS に送信するケースです。
  6. PoC 公開によるスクリプト化攻撃の横展開
    • 公開された PoC を改変し、自動化スキャン／エクスプロイトツールとして大量に実行されることにより、露出している WSUS を次々に狙われます。

攻撃はこれらのいずれか単独、または組み合わせで成立します。特に「外部から到達可能な WSUS」と「内部の踏み台奪取」は高リスクです。検出指標としては、外部からの 8530/8531 宛アクセスの急増、不審な AuthorizationCookie の受信・復号試行、WSUS 関連プロセスからの異常なプロセス生成（w3wp.exe → cmd/powershell 等）を監視してください。

Microsoftの緊急パッチ対応

CVE-2025-59287の深刻さを受け、Microsoftは2025年10月23日に通常の月例更新とは別枠でOut-of-band（緊急）セキュリティ更新プログラムを公開しました。これは、同脆弱性がすでに実際の攻撃で悪用されていることを確認したうえで、迅速な修正を提供するための異例の対応です。対象は、WSUSロールを有効にしているすべてのサポート中のWindows Server製品であり、更新プログラムの適用後にはシステムの再起動が必要とされています。Microsoftは本パッチの適用を「最優先事項」と位置づけ、管理者に対して即時の展開を強く推奨しています。

対応内容と対象環境

Microsoftが提供した緊急パッチは、WSUSサーバーの逆シリアライズ処理における検証不備を修正するものです。本更新では、AuthorizationCookieを含むデータ復号処理の検証が強化され、外部から細工されたオブジェクトが復元されないように制御が追加されました。また、暗号鍵および復号ロジックの管理方式が改良され、デシリアライズ対象の型を厳密に制限する仕組みが導入されています。これにより、攻撃者が任意コードを挿入して実行する経路が遮断される設計となっています。

緊急パッチは通常の月例更新とは別に提供されたOut-of-band（OOB）セキュリティ更新プログラムであり、代表的なものとしては以下の更新が含まれます。

  • Windows Server 2025: KB5070881（OS Build 26100.6905）
  • Windows Server 2022 / 23H2: KB5070882
  • Windows Server 2019: KB5070883
  • Windows Server 2016: KB5070884
  • Windows Server 2012 / 2012 R2: KB5070885

いずれもWSUSロールを有効にしているサーバーが対象であり、オンプレミス環境・仮想マシン環境・クラウド上のハイブリッド構成を問わず適用が必要です。更新プログラムはWindows Update、Microsoft Update Catalog、または既存のWSUSを通じて入手できます。適用後にはシステム再起動が必要とされています。

暫定対策と注意点

MicrosoftはCVE-2025-59287に関して、緊急パッチを適用できない場合に備えた暫定的な防御策を案内しています。これらは恒久的な解決ではありませんが、攻撃リスクを軽減する手段として有効です。

まず第一に、WSUSサーバーを外部ネットワークから隔離することが推奨されています。具体的には、ポート8530（HTTP）および8531（HTTPS）をインターネット側に公開しないようファイアウォールで遮断することが重要です。攻撃はこれらのポートを経由して行われるため、外部からのアクセスを防ぐだけでも大部分のリスクを抑止できます。

第二に、WSUSロールを一時的に停止または無効化する対応です。更新配信が業務上必須でない場合や、短期間の停止が許容される環境では、ロールの無効化により脆弱なサービスを一時的に遮断することが可能です。Microsoftも、パッチ適用までの間はこの方法を安全策として挙げています。

第三に、アクセスログとプロセス挙動の監視強化が推奨されます。攻撃が成立した場合、「wsusservice.exe」や「w3wp.exe」から「cmd.exe」や「powershell.exe」などが派生する異常なプロセス連鎖が観測される傾向があります。これらの挙動が検出された場合、即時のネットワーク隔離とフォレンジック調査が必要です。

なお、Microsoftの緊急パッチ適用後も、WSUSの一部機能（同期エラー詳細の表示）が一時的に無効化されていることが公式に確認されています。これはリモートコード実行脆弱性の再発を防止するための暫定措置であり、今後の更新で再有効化される予定です。そのため、更新適用後に一部の管理情報が表示されなくなった場合でも、異常ではなく仕様上の変更と理解することが必要です。

今後取るべき対応と教訓

CVE-2025-59287は、システム更新基盤そのものが攻撃対象となった稀有な事例です。WSUSは企業内で広く利用される更新配信サーバーであり、その侵害は単一サーバーに留まらず、ネットワーク全体の信頼性やセキュリティモデルを揺るがす結果につながりかねません。今回の事案は、ソフトウェア更新機構の安全設計と運用管理の両面における脆弱性を浮き彫りにしました。

Microsoftは緊急パッチを迅速に提供しましたが、根本的な教訓は、更新インフラが「攻撃者にとって高価値な標的である」という事実を再認識することにあります。今後はパッチ適用やアクセス制御に加え、更新配信経路のセグメント化、不要ロールの削除、安全なシリアライズ方式への移行など、設計段階からの防御強化が求められます。また、既存のゼロトラスト戦略や内部監査プロセスを通じて、同様の設計上のリスクが他のシステムにも存在しないかを点検することが重要です。

パッチ適用と防御強化

最優先の対応は、Microsoftが提供する緊急パッチ（Out-of-band更新プログラム）を速やかに適用することです。CVE-2025-59287はすでに実際の攻撃が確認されているため、未適用のサーバーを放置することは極めて危険です。特に、WSUSロールを有効にしているWindows Server環境（2012、2016、2019、2022、2025など）は全て対象となります。更新プログラムはWindows Update、Microsoft Update Catalog、または既存のWSUS経由で取得可能であり、適用後には再起動が必要です。適用状況は「winver」やPowerShellコマンド（Get-HotFix -Id KB5070881 など）で確認できます。

パッチ適用に加えて、防御強化策の恒久的実施も重要です。まず、WSUSサーバーを外部ネットワークから隔離し、ポート8530（HTTP）および8531（HTTPS）を外部に公開しないよう設定してください。もし他システムからの中継やリバースプロキシを使用している場合は、通信経路を明確化し、認証およびTLS構成を再点検することが推奨されます。

また、WSUSを運用するサーバーのアクセス権限とロール分離を強化することも効果的です。特に、管理者権限を持つアカウントの利用制限、WSUSサービスアカウントの最小権限化（least privilege原則）を徹底することで、仮に脆弱性が再発しても被害を限定できます。さらに、シリアライズやデシリアライズを扱うアプリケーションでは、BinaryFormatterなど既知の危険な機構を使用しないよう設計を見直すことが望まれます。

防御の最終層としては、EDR（Endpoint Detection and Response）やSIEM（Security Information and Event Management）による監視を強化し、プロセス生成やネットワーク通信の異常を早期に検知できる体制を整えることが求められます。特に、w3wp.exe や wsusservice.exe から cmd.exe・powershell.exe が起動されるような挙動は侵害の兆候として警戒すべきです。これらの技術的対策を多層的に組み合わせることで、再発防止と長期的な運用安全性を確保できます。

安全な更新管理への見直し

今回のCVE-2025-59287は、更新配信基盤であるWSUSそのものが攻撃経路となり得ることを明確に示しました。これを受け、組織は単にパッチを適用するだけでなく、更新管理全体の設計と運用を再評価する必要があります。WSUSは多くのシステムに更新を一括配信できる利便性を持つ一方で、その信頼性が損なわれると全社的な被害へ直結するリスクが存在します。

まず、更新配信経路の分離とセグメント化が基本方針となります。WSUSサーバーを業務ネットワークや外部インターネットから直接到達可能な位置に配置することは避け、管理専用ネットワーク上に限定することが推奨されます。また、上位サーバーから下位サーバーへの同期を行う場合も、双方向通信を最小化し、必要な通信ポートのみを明示的に許可する設計が求められます。

次に、署名および検証プロセスの厳格化が必要です。更新データやメタデータの改ざんを防ぐため、TLS 1.2 以降の暗号化通信を必須とし、証明書の有効期限や信頼チェーンを定期的に検証する体制を整えることが推奨されます。Microsoftの提供する更新ファイルはデジタル署名付きであるため、署名検証を無効化する設定やキャッシュ代替配布などは避けるべきです。

さらに、更新配信インフラの可視化と検証サイクルの確立が求められます。脆弱性情報の収集を定期化し、CVEやKB番号単位での適用状況を可視化することで、パッチ管理の遅延や漏れを防ぐことができます。また、緊急パッチ（Out-of-band update）が配信された際には、自動配信設定に頼らず、検証環境での影響確認を経て段階的に展開する運用が望ましいとされています。

最後に、今回の事例は、更新システムもまたセキュリティ防御層の一部であるという認識を再確認する契機です。更新基盤の設計・運用・監査を定期的に見直し、ゼロトラストの原則に基づく防御体系の中で維持することが、今後の安全なシステム運用において不可欠です。

おわりに

CVE-2025-59287は、組織のシステム運用において「更新基盤そのものの安全性」がいかに重要であるかを改めて浮き彫りにしました。WSUSは多くの企業や行政機関で利用される中核的な更新管理システムであり、その信頼性が損なわれることは、単なる単一サーバーの障害にとどまらず、組織全体のセキュリティ体制を揺るがす結果につながります。今回の脆弱性が実際に悪用された事実は、更新配信という日常的な仕組みが攻撃者にとっても魅力的な標的であることを示しています。

Microsoftは迅速な緊急パッチを提供しましたが、真の対応は「修正を当てること」で終わりではありません。今後は、更新配信の構成を安全に保つための設計見直し、アクセス制御の徹底、そして脆弱性情報への継続的な対応が不可欠です。また、WSUSに限らず、運用基盤の全てのレイヤーにおいて安全設計（Secure by Design）の考え方を適用することが求められます。

本事案を一過性のインシデントとして片付けるのではなく、更新システムの信頼性と防御力を向上させる契機として捉えることが重要です。組織全体でこの教訓を共有し、再発防止と継続的改善の文化を根付かせることが、今後のセキュリティ強化への最も確実な一歩となります。

参考文献

Windows 11で顕在化したマシンSID重複問題 ― 認証失敗の原因と対策

2025年に入り、一部のWindows環境で「ドメインにログオンできない」「リモートデスクトップ接続が拒否される」「ファイル共有にアクセスできない」といった認証関連の障害が報告されています。これらの事象は、特定の更新プログラム（例：KB5065426など）を適用した後に発生しており、その根本原因の一つとして「マシンSID（マシンID）の重複」が指摘されています。

マシンSIDとは、Windowsが各コンピュータに割り当てる固有の識別子であり、アクセス制御や認証の基礎として利用される重要な情報です。本来はOSインストール時に一意に生成されるものですが、Sysprep（System Preparation Tool）を用いずにディスクイメージを複製した場合などでは、このSIDが複数のマシンで重複することがあります。

これまではマシンSIDの重複によって重大な不具合が起こるケースはほとんどありませんでしたが、Windows 11以降では認証メカニズムの整合性検証が強化され、重複SIDを持つ環境でKerberosやNTLM認証が失敗する事例が明確に確認されています。

本記事では、この問題の背景と技術的な仕組み、発生原因、そして防止策としてのSysprepの重要性について解説します。

マシンSID（マシンID）とは何か

マシンSID（Machine Security Identifier、以下マシンIDとも呼びます）は、Windowsが各コンピュータを識別するために割り当てる固有の識別子です。SID（Security Identifier）はWindowsのセキュリティモデルの基盤を構成する要素であり、ユーザー、グループ、サービス、そしてマシンそのものを一意に識別するために使用されます。

Windowsでは、アクセス制御リスト（ACL）や認証情報の照合においてSIDが参照されます。たとえば、あるフォルダに対してアクセス権を付与すると、その設定はユーザー名ではなく、実際にはユーザーSIDを基準に保持されます。同様に、ローカルコンピュータを識別するためにもSIDが利用され、これが「マシンSID」と呼ばれるものです。

マシンSIDは、Windowsのインストール時に自動的に生成されます。これにより、同一ネットワーク上に複数のマシンが存在しても、それぞれが固有の識別子を持つことになります。しかし、ディスクのクローン作成や仮想マシンのテンプレート展開を行う際に、Sysprep（System Preparation Tool）を使わずにイメージを複製すると、元のSIDがそのまま複製先にも引き継がれ、複数のマシンが同一SIDを共有してしまうことがあります。

一見すると同じ見た目の独立したPCであっても、SIDが重複している場合、Windows内部では「同一マシン」として扱われることがあり、認証やアクセス制御の整合性に問題が生じます。特に、KerberosやNTLMといった認証プロトコルでは、このSIDをもとにマシン間の信頼関係を検証するため、SID重複はログオンエラーや共有アクセスの拒否といった障害を引き起こす要因となります。

つまり、マシンSIDはWindowsのセキュリティ構造を支える根幹的な識別子であり、同一ネットワーク上で重複してはならない値です。運用上は、OSの展開や仮想マシンの複製を行う際に、各マシンが一意のSIDを持つよう管理することが不可欠です。

Sysprepとは何か

（generalize）」するためのプロセスを担います。一般化とは、特定のコンピュータ固有の情報を一時的に削除し、再起動時に新しい環境として再構成できる状態にすることを指します。

Windowsを通常インストールすると、その環境にはマシンSID、ネットワーク設定、デバイスドライバ、イベントログ、ライセンス情報など、ハードウェアやインストール時点に依存した情報が含まれます。これらをそのまま複製して別のマシンに展開すると、同一SIDを持つクローンが複数台生成され、認証やネットワーク上の識別で衝突が発生する可能性があります。Sysprepはこの問題を防ぐため、これらの固有情報を初期化し、次回起動時に新しいSIDや構成情報を自動生成させる役割を果たします。

Sysprepを実行する際には、/generalize オプションを指定するのが一般的です。このオプションにより、マシンSIDを含む固有データが削除され、システムが「未構成状態」となります。その後、再起動時にWindowsが再構成プロセスを実行し、新しい識別子を生成します。これによって、同一イメージから展開された複数のマシンがそれぞれ固有のSIDを持ち、KerberosやNTLMなどの認証メカニズムが正しく動作するようになります。

また、Sysprepは企業や教育機関などで大量のPCを一括展開する際に不可欠な手段です。テンプレートマシンをあらかじめ設定しておき、Sysprepで一般化したイメージを複数のデバイスに展開することで、設定の一貫性と識別の独立性を両立できます。

なお、SysprepはMicrosoftが公式にサポートする唯一の一般化手法であり、過去に存在した「NewSID」などのサードパーティツールは既に非推奨となっています。Sysprepを経ずに複製した環境では、現在のWindows 11以降で報告されているような認証エラーや共有アクセスの不具合が発生する可能性が高いため、運用上は常に一般化済みのイメージを利用することが推奨されます。

マシンSIDの重複が発生するケース

マシンSIDの重複は、Windowsの設計上「SIDがインストール時に一度だけ生成される」という性質に起因します。したがって、同じインストール済みシステムを複数のマシンに複製した場合、すべての複製先が同一のSIDを保持することになります。以下では、実際に重複が発生しやすい典型的なケースを説明します。

1. Sysprepを実行せずにディスクイメージを複製した場合

最も一般的なケースです。

運用現場では、あるマシンを初期設定した後に、その環境をディスクイメージとして他のPCへ複製し、同一構成の端末を短時間で用意することがあります。しかし、Sysprepを実行せずにイメージ化を行うと、元のマシンSIDが複製先にもそのまま引き継がれます。結果として、ネットワーク上で複数のマシンが同じSIDを持つ状態となり、認証処理やアクセス制御に支障をきたす可能性があります。

2. 仮想マシンのテンプレートやスナップショットをそのまま展開した場合

仮想化環境（Hyper-V、VMware、VirtualBox、Proxmox など）では、テンプレートやスナップショットを使って新しい仮想マシンを生成する運用が一般的です。テンプレート作成時にSysprepを実行していない場合、そのテンプレートから派生したすべての仮想マシンが同一SIDを共有します。特にVDI（仮想デスクトップ）やテスト環境では、短時間で多数のインスタンスを立ち上げることが多く、この問題が顕在化しやすくなります。

3. バックアップイメージを別マシンにリストアした場合

システムバックアップを取得し、障害対応や構成複製の目的で別のマシンにリストアする場合にもSID重複は発生します。バックアップにはマシンSIDが含まれており、復元後の環境は元のマシンと同一SIDを持つことになります。特にドメイン参加済みのマシンをこの方法で復元した場合、ドメインコントローラとの信頼関係が失われ、認証エラーを引き起こすことがあります。

4. 非公式ツールでSIDを変更またはコピーした場合

かつては Sysinternals の「NewSID」など、SIDを変更するための非公式ツールが存在しました。しかし、これらのツールは既にMicrosoftのサポート対象外であり、最新のWindowsビルドでは正常に動作しません。さらに、SID以外の関連識別情報（セキュリティデータベースやACL設定など）との整合性を壊す危険性があり、運用環境での使用は推奨されません。

5. 仮想ディスク（VHD/VHDX）を複数の仮想マシンで共有起動した場合

1つの仮想ディスクを複数の仮想マシンで同時に使用する構成でも、SID重複が発生します。ディスク上のシステムは同一のSIDを保持しており、各マシンは内部的に同一識別子として認識されます。そのため、SMB共有や認証トークンの発行時に整合性エラーが発生しやすくなります。

まとめ

マシンSIDの重複は、「OSを新規インストールせず、既存環境をコピー・複製した場合」に必ず発生します。これを防ぐ唯一の確実な方法は、イメージ作成前に Sysprepの/generalizeオプションを実行してSIDを初期化することです。特にドメイン参加環境や仮想化インフラでは、この手順を標準化することが、今後の認証トラブル防止に不可欠です。

なぜ今になって問題が顕在化したのか

マシンSIDの重複は、Windows NTの時代から理論的には存在していた問題です。しかし、長らく実運用上はほとんど問題視されていませんでした。これは、Windowsの認証設計やネットワーク動作が、マシンSIDの重複を直接的に検証することを想定していなかったためです。ところが、Windows 11以降の更新プログラムではセキュリティモデルが強化され、従来黙認されてきた環境が「正しくない構成」として扱われるようになりました。

Windows 10以前では問題が顕在化しなかった理由

Windows 10までのバージョンでは、マシンSIDの重複があっても、通常の運用で深刻な支障が生じることはほとんどありませんでした。ローカル環境では各マシンのアクセス制御リスト（ACL）が個別に管理されており、他のマシンのSIDと衝突しても影響がなかったためです。ドメイン環境でも、認証時にはマシンSIDではなくドメインSIDが優先的に使用されるため、重複は実質的に無視されていました。

このため、過去には「マシンSIDの重複は神話に過ぎない」との見解がMicrosoft自身から示されています。2009年にMark Russinovich（当時Sysinternalsの開発者）が発表したブログ記事「The Machine SID Duplication Myth」では、「同一マシンSIDによる実害は確認されていない」と明言されており、以後も多くの運用現場でSysprepを省略したイメージ展開が行われてきました。

Windows 11以降での変化

しかし、Windows 11（特に24H2以降）では、セキュリティの一貫性検証が強化されました。KerberosやNTLMなどの認証プロトコルにおいて、マシンSIDの一意性がより厳密に参照されるようになり、SIDの重複がある場合には認証を拒否する挙動が導入されています。

特に、2025年8月以降に配信された累積更新プログラム（例：KB5065426など）では、ドメイン参加済みマシンやSMB共有を利用する環境で「SEC_E_NO_CREDENTIALS」や「STATUS_LOGON_FAILURE」といったエラーが頻発する事例が報告されました。Microsoftはこれについて、「重複SIDを持つPC間での認証処理が正しく行えないことを確認した」と公式に説明しています。

背景にあるセキュリティ設計の変化

Windows 11世代では、ゼロトラストモデル（Zero Trust Architecture）の原則に基づき、システム間の信頼関係を明示的に検証する設計へと移行しています。マシンSIDのような基礎的な識別情報についても、これまで以上に厳密な一意性が要求されるようになりました。その結果、これまで問題として顕在化しなかった構成上の欠陥が、セキュリティ上の不整合として表面化したのです。

まとめ

マシンSIDの重複という現象自体は新しいものではありません。しかし、Windows 11およびその後の更新によって、認証処理における整合性検証が強化された結果、「これまで通用していた構成が通用しなくなった」という形で問題が顕在化しました。セキュリティ強化の観点から見れば自然な進化ですが、イメージ展開を前提とする環境では、従来の運用手順の見直しが避けられない状況となっています。

発生している主な事象

マシンSIDの重複によって生じる問題は、主に認証処理の失敗として現れます。特に、Windows Updateの適用後にKerberosまたはNTLM認証が適切に動作しなくなり、ログオンやリモート接続、共有アクセスなどが拒否される事例が確認されています。これらの障害は、企業ネットワークや仮想化環境を中心に報告されており、複数台のマシンが同一SIDを共有している構成で発生する傾向があります。

1. ログオン時の認証エラー

最も多く報告されているのは、ドメインログオンやローカル認証時の失敗です。Windows Update適用後に突然ドメインに参加できなくなり、ユーザーが正しい資格情報を入力してもログオンできない状態となります。イベントログには以下のような記録が出力されます。

  • イベントID 4625（ログオン失敗）
    「An account failed to log on（アカウントのログオンに失敗しました）」というメッセージとともに、Security ID: NULL SID が表示される場合があります。
  • イベントID 4768（Kerberos 認証チケット要求失敗）
    Kerberos 認証でチケットが発行されず、KDC_ERR_PREAUTH_FAILED または SEC_E_NO_CREDENTIALS が記録されることがあります。

これらはいずれも、マシンSIDの整合性が失われ、認証トークンが正しく発行・照合できないことが原因とされています。

2. リモートデスクトップ接続（RDP）の失敗

更新プログラム適用後、リモートデスクトップ（RDP）による接続試行時に「ログオン試行が失敗しました（The logon attempt failed）」というメッセージが表示されるケースがあります。

マシンSIDが他の端末と重複している場合、クライアント認証情報の検証段階で不一致が発生し、セッションが拒否されます。これは、ドメイン内でRDPアクセスを制御している環境（グループポリシーやNTLMベースの認証が関係する環境）で特に発生しやすい事象です。

3. ファイル共有やプリンタ共有へのアクセス不能

マシンSIDの重複により、SMB（Server Message Block）通信で行われる認証が失敗し、ファイル共有やプリンタ共有が利用できなくなる事例も確認されています。ユーザーがネットワーク共有フォルダにアクセスしようとすると、認証ダイアログが繰り返し表示されたり、「アクセスが拒否されました」というエラーが発生します。

Microsoft Q&Aフォーラムでは、特に更新プログラム KB5065426 適用後にこの問題が頻発しており、同一SIDを持つマシン間でSMB共有が機能しなくなることが報告されています。

4. サービスアカウントおよびシステム間通信の不具合

ドメイン参加マシン同士で通信するサービス（たとえばIIS、SQL Server、ファイル同期システムなど）でも、認証トークンが無効化され、接続が確立できないケースがあります。これは、内部的にKerberosチケットやNTLMトークンを利用しているため、マシンSIDの重複によって整合性が失われることに起因します。

5. 再起動後にのみ発生するケース

一部の報告では、更新プログラムの適用直後ではなく、再起動後に問題が発生する傾向が見られます。これは、再起動によって新しいセキュリティトークンが生成される際にSID重複が検出され、認証が拒否されるためと考えられます。

まとめ

以上のように、マシンSIDの重複はWindows 11以降の更新によって顕在化し、以下のような認証関連の不具合として表れています。

  • ドメインログオンの失敗
  • RDP（リモートデスクトップ）接続の拒否
  • SMB共有・プリンタ共有のアクセス不能
  • サービスアカウントによる通信の停止

いずれのケースも、根本的な原因は「同一マシンSIDを持つ複数の端末が存在すること」にあり、これを解消しない限り再発の可能性が高いと考えられます。

影響を受ける認証メカニズム

マシンSIDの重複による認証エラーは、Windowsが採用する複数の認証メカニズムのうち、特にSIDを識別情報として参照する方式に影響を及ぼします。Windowsネットワークでは、ユーザーやマシンを特定する際にSID（Security Identifier）を用いて整合性を検証しており、このSIDが重複していると、認証トークンやチケットの検証に失敗します。

特に影響が顕著なのは、ドメイン環境で利用される Kerberos 認証 と、ワークグループ環境や一部のレガシーシステムで用いられる NTLM 認証 の2種類です。いずれもマシンSIDを認証情報の一部として扱うため、重複したSIDを持つマシン間では「同一マシンである」と誤認されるか、逆に「信頼できない別マシン」として扱われ、認証に失敗します。

以下では、それぞれの認証メカニズムがどのような仕組みで動作し、どのようにマシンSID重複の影響を受けるのかを解説します。

Kerberos認証

Kerberos認証は、Windowsドメイン環境において標準的に使用されているチケットベースの認証方式です。Active Directory（AD）ドメインコントローラ上の認証サービス（KDC: Key Distribution Center）が中心的な役割を担い、ユーザーおよびマシンの身元をチケットの発行によって保証します。

認証の基本的な流れは、クライアントがKDCに対して認証要求を行い、KDCがクライアントのSIDを含む認証チケット（TGT: Ticket Granting Ticket）を発行するというものです。以後の通信では、このチケットを提示することで、クライアントは再度パスワードを送信することなくサーバーリソースへのアクセスを行うことができます。この仕組みにより、Kerberosは高いセキュリティと効率性を両立しています。

しかし、マシンSIDが重複している環境では、この認証フローが破綻します。Kerberosチケットには、マシンのSIDをもとにした識別情報が含まれており、KDCはこれを照合してクライアントの一意性を検証します。もし複数のマシンが同一SIDを共有している場合、KDCはチケットの発行または更新時に整合性を確認できず、認証を拒否することがあります。その結果、ドメインログオンの失敗、リモートデスクトップ（RDP）接続の拒否、SMB共有へのアクセス不能といった事象が発生します。

特にWindows 11以降では、セキュリティモデルが強化され、チケット発行時のSID検証がより厳密に実施されています。そのため、従来のようにマシンSID重複が黙認されるケースは減少し、SIDの整合性が保証されない環境ではKerberos認証そのものが成立しなくなっています。

要するに、Kerberos認証は「一意なマシンSIDを前提とした信頼関係の上に成り立つ仕組み」であり、この前提が崩れると、ドメイン環境におけるあらゆる認証・アクセス制御が機能しなくなるという点に注意が必要です。

H3: NTLM認証

NTLM（NT LAN Manager）認証は、Kerberosが導入される以前からWindowsで使用されてきたチャレンジ・レスポンス方式の認証プロトコルです。現在でも、ワークグループ環境や一部のレガシーシステム、Kerberosが利用できないネットワーク経路においては、後方互換性のために引き続き使用されています。

NTLM認証は、ユーザーのパスワードを直接送信せず、ハッシュ値を用いてサーバー側とクライアント側で相互に整合性を確認することで成り立っています。クライアントがログオン要求を送信すると、サーバーはランダムなチャレンジ値を返し、クライアントはパスワードハッシュを基にレスポンスを計算します。サーバー側では同様の計算を行い、結果が一致すれば認証が成立します。この仕組みにより、平文パスワードがネットワーク上に流れないという利点があります。

しかし、NTLMは設計上、認証の文脈をSID（Security Identifier）に強く依存しています。特に、マシンアカウントやローカルセキュリティコンテキストを用いた認証では、マシンSIDが認証トークンの生成および検証に関与します。そのため、複数のマシンが同一のSIDを共有している場合、サーバー側ではどのクライアントが本来のリクエスト元であるかを識別できず、結果として「資格情報が無効」「認証に失敗しました」といったエラーを返すことになります。

この問題は特に、SMB（Server Message Block）を利用したファイル共有やプリンタ共有など、NTLM認証を前提とする通信で顕著に現れます。Windows Update（例：KB5065426）以降では、セキュリティ検証が強化されたことにより、同一SIDを持つマシン間でのNTLM認証が明示的に拒否されるようになりました。その結果、従来は動作していた共有フォルダへの接続やリモートリソースのアクセスが突然不能になる事例が多数報告されています。

つまり、NTLM認証においてもKerberosと同様に、マシンSIDの一意性は前提条件です。SIDが重複した環境では、認証トークンの信頼性が損なわれ、ネットワーク越しの認証全体が破綻します。現行のWindowsでは、このような構成がセキュリティ上「不正な状態」として検出されるようになっており、今後はNTLMベースの環境でもSysprepによるSID初期化が不可欠となっています。

どのように対策すべきか

マシンSIDの重複による認証失敗は、Windowsの設計そのものに起因する構造的な問題であるため、根本的な対策は「各マシンが一意のSIDを持つように構成を見直すこと」に尽きます。特に、Sysprepを用いずにディスクイメージや仮想マシンを複製している場合は、展開プロセスの修正が必要です。以下に、代表的な対策手順と運用上の注意点を示します。

1. Sysprepを用いたイメージの一般化

最も基本的かつ確実な対策は、Sysprep（System Preparation Tool）による一般化（/generalize）を実施することです。

Sysprepを実行すると、マシンSIDを含む固有情報が初期化され、次回起動時に新しいSIDが自動的に生成されます。これにより、複数のマシンが同一イメージから展開されたとしても、それぞれが固有の識別子を持つ状態になります。

実行例（管理者権限のコマンドプロンプトで実行）：

sysprep /generalize /oobe /shutdown

/generalize はSIDを初期化するオプション、/oobe は初回セットアップ画面を有効化するオプションです。Sysprep実行後に取得したイメージをテンプレートとして利用すれば、安全に複製展開が可能になります。

2. 既存環境でのSID確認と再展開の検討

すでに多数の端末や仮想マシンを展開済みの場合、まず現状のSIDを確認し、重複が存在するかを把握することが重要です。SIDはSysinternalsツールの PsGetSid や PowerShellコマンドを用いて確認できます。

例：

PsGetSid.exe

または

Get-WmiObject Win32_ComputerSystemProduct | Select-Object UUID

もし同一SIDのマシンが複数確認された場合、再度Sysprepを実施してSIDを再生成するか、OSを再インストールすることが推奨されます。SIDの一部のみを変更する非公式ツールやレジストリ操作は、セキュリティデータベースとの不整合を引き起こす可能性があるため避けるべきです。

3. テンプレートおよび自動展開手順の見直し

仮想化基盤やクローン展開を行う運用では、テンプレート作成時点でのSysprep実施を標準化することが不可欠です。特にVDI環境、Hyper-VやVMwareでのゴールデンイメージ管理、またはクラウド上の仮想マシン展開（Azure、AWSなど）においては、イメージ作成後の「一般化」を怠ると、すべてのインスタンスが同一SIDを共有するリスクがあります。

運用ルールとして、イメージ化前に /generalize を含むSysprep実行を義務化し、テンプレート更新時にその状態を維持することが望ましいです。

4. 一時的な回避策（推奨されない方法）

Microsoftは一部の環境向けに、重複SIDチェックを一時的に無効化するグループポリシーやレジストリ設定を案内しています。しかし、これらはあくまで暫定的な回避策であり、セキュリティリスクを伴います。SID重複自体は解消されないため、将来的な更新で再び認証エラーが発生する可能性が高く、恒久的な解決策にはなりません。

根本的な修正を行うまでの一時的措置としてのみ利用すべきです。

5. 運用ポリシーと検証プロセスの整備

今回の問題を教訓として、イメージ配布やシステム複製のプロセスを運用ポリシーとして明文化し、更新や配布前に検証を行う体制を整えることが望まれます。

特に以下の点を定期的に確認することが効果的です。

  • テンプレート作成時にSysprepが確実に実行されているか。
  • 展開済みのマシンでSIDが重複していないか。
  • 新しいWindows更新プログラムの適用後に認証エラーが発生していないか。

まとめ

マシンSID重複による認証失敗は、Windows 11以降のセキュリティ強化によって顕在化した構成上の不備です。最も有効な対策は、Sysprepによるイメージの一般化を徹底することです。既存環境では、SIDの重複を早期に検出し、再展開やテンプレート修正を通じて正常な識別体系を再構築することが求められます。

運用の効率化とセキュリティの両立のためには、イメージ管理手順を体系的に見直し、SID一意性の確保を組織的な標準として維持することが不可欠です。

おわりに

マシンSIDの重複は、Windowsの仕組み上、古くから存在する潜在的な問題でした。しかし、Windows 11以降の更新プログラムにおいて認証処理の厳格化が進んだ結果、これまで見過ごされてきた構成上の不備が明確な障害として顕在化しました。特に、KerberosやNTLMといったSIDに依存する認証方式においては、重複したSIDを持つマシン間で認証トークンの整合性が失われ、ログオンや共有アクセスの失敗といった深刻な影響が発生しています。

この問題の根本原因は、Sysprepを用いずにディスクイメージや仮想マシンを複製することにあります。Sysprepを実行せずに展開された環境では、複数のマシンが同一の識別子を持つことになり、Windowsのセキュリティモデルが前提とする「一意なSIDによる信頼関係」が崩壊します。その結果、認証基盤が正しく機能しなくなるのです。

対策としては、イメージ展開時に Sysprepの/generalizeオプションを必ず実行すること、および既存環境でSID重複が疑われる場合には PsGetSidなどを用いて確認し、再展開または再構成を行うこと が推奨されます。また、仮想化や自動デプロイを行う運用環境では、テンプレート作成時に一般化プロセスを標準化し、再利用するすべてのイメージが一意のSIDを生成できる状態であることを保証することが重要です。

本件は、単なる一時的な不具合ではなく、Windowsのセキュリティ設計の根幹に関わる構成管理上の問題です。今後の環境構築においては、効率性だけでなく、SIDの一意性を含むセキュリティ整合性の維持を重視した運用へと移行することが求められます。

参考文献

WinRE操作不能不具合を修正 ― Windows 11用緊急パッチ「KB5070773」の詳細

2025年10月20日、MicrosoftはWindows 11向けに緊急の「Out-of-band（OOB）」更新プログラム「KB5070773」を配信しました。本更新は通常の月例更新とは異なり、特定の重大な不具合を迅速に修正するために提供されたものです。対象となるのは、Windows 11 バージョン24H2および25H2を利用するシステムです。これらの環境では、直前の累積更新プログラム（KB5066835）適用後に、Windows回復環境（WinRE）でマウスやキーボードが反応しなくなる問題が確認されていました。

WinREは、システム障害時に復旧やリセットを行うための重要な機能です。その操作が不能になることは、復旧不能なトラブルへ直結する恐れがあり、企業・個人を問わず深刻な影響を及ぼします。そのため、Microsoftは異例のタイミングでKB5070773をリリースし、問題解消を図りました。

本記事では、この更新プログラムの概要と修正内容、そして適用時に留意すべき点について整理します。

KB5070773の概要

KB5070773は、Microsoftが2025年10月20日に配信したWindows 11向けの緊急更新プログラム（Out-of-band Update）です。対象となるのは、最新バージョンである24H2および25H2を利用しているシステムであり、適用後のOSビルド番号はそれぞれ以下のとおりです。

  • バージョン25H2：ビルド 26200.6901
  • バージョン24H2：ビルド 26100.6901

この更新は、10月14日に配信された累積更新プログラム「KB5066835」に起因して発生した不具合を修正するために提供されたものです。KB5066835を適用した一部環境では、Windows回復環境（WinRE）でマウスおよびキーボードが認識されず、操作が一切行えない状況が確認されていました。WinREは、OSが正常に起動しない場合やトラブルシューティングを行う際に利用される重要なシステム領域であり、その機能停止は深刻な問題と位置づけられます。

Microsoftはこの不具合を「高優先度の回復機能障害」と判断し、通常の月例パッチスケジュールを待たずに緊急対応を実施しました。KB5070773の配信はWindows Updateを通じて順次行われており、手動でのインストールもMicrosoft Updateカタログから可能です。特に企業環境や管理対象デバイスでは、復旧手段が制限されるリスクを避けるため、早期の適用が推奨されています。

修正された不具合

KB5070773で修正された主な不具合は、Windows回復環境（Windows Recovery Environment：WinRE）において、マウスおよびキーボードが正しく動作しなくなる問題です。この不具合は、10月の累積更新プログラム「KB5066835」を適用した後に一部の環境で発生し、WinREに入っても入力デバイスが認識されず、画面上の操作が一切行えないという症状が報告されていました。

WinREは、システムが起動不能となった際に「スタートアップ修復」や「システムの復元」「PCのリセット」などを実行するための重要な復旧機能です。そのため、入力が受け付けられない状態では、事実上あらゆる修復操作が不可能になります。特に企業や公共機関など、業務継続性（Business Continuity）を重視する環境においては、復旧プロセスの停止が深刻な影響を及ぼすおそれがありました。

本更新プログラムにより、WinRE内でUSB接続およびPS/2接続のマウス・キーボードが正しく認識されるよう修正されています。Microsoftによると、更新の適用後には従来どおりの操作が可能となり、回復メニュー全体の機能が正常に利用できることが確認されています。これにより、復旧機能の信頼性が回復し、緊急時のトラブル対応を安全に実行できるようになりました。

適用上の注意点

KB5070773は、緊急性の高い不具合修正を目的として配信されていますが、適用にあたってはいくつかの確認事項と注意点があります。まず、対象となるのは Windows 11 バージョン24H2および25H2 です。それ以前のバージョンには配信されませんので、更新を実施する前に「設定」→「システム」→「バージョン情報」でOSバージョンを確認することが重要です。

配信はWindows Update経由で自動的に行われますが、手動での適用も可能です。Windows UpdateでKB5070773が表示されない場合は、Microsoft Updateカタログから直接ダウンロードしてインストールできます。特に業務用PCやオフライン環境では、手動適用を検討する方が確実です。

適用前には、念のため 重要なデータのバックアップを取得 しておくことが推奨されます。今回の修正対象は回復環境（WinRE）であり、万一更新に失敗した場合にはシステム修復が難しくなる可能性があります。また、更新後にはWinREを実際に起動し、マウスやキーボードが正常に動作するかを確認することが望ましいです。

なお、KB5070773は通常の累積更新とは異なり、Out-of-band（臨時配信）で提供される特別な更新です。これにより、将来の月例更新にも同様の修正内容が統合される見込みですが、現時点では本パッチを速やかに適用することが最も確実な対策となります。特に企業や教育機関など複数端末を管理する環境では、配布スケジュールを早期に調整し、全端末への反映状況を確認する体制が求められます。

おわりに

今回のKB5070773は、Windows 11の回復環境に関わる重大な不具合を解消するため、通常の更新サイクルとは別に提供された異例のアップデートでした。WinREの操作不能は、システム障害時の復旧手段を失うことを意味し、一般利用者のみならず、業務システムや企業ネットワークにとっても深刻なリスクとなり得ます。Microsoftが迅速にOut-of-band配信を行ったことは、同社が問題の重要性を高く評価している証拠といえます。

本件は、日常的な更新管理の重要性を改めて示す事例でもあります。定期的なバックアップ取得や更新適用前後の動作確認を怠らないことで、トラブル発生時の影響を最小限に抑えることが可能です。また、複数の端末を運用する組織では、今回のような緊急パッチにも対応できる体制を整備することが求められます。

今後もWindowsの更新には、セキュリティ修正だけでなくシステム安定性に関わる修正が含まれる可能性があります。利用者としては、更新内容を正確に把握し、適切なタイミングで適用を行うことで、安全で信頼性の高い環境を維持することが重要です。

参考文献

「ローカルホスト問題は氷山の一角」── Microsoft Windows 11 累積更新プログラム KB5066835 の影響と対応策

先日、Microsoft が Windows 11（バージョン 24H2／25H2）および Windows Server 環境向けに配信した累積更新プログラム「KB5066835」が、ローカルホスト（127.0.0.1）への HTTP/2 接続不能という開発・運用環境に深刻な影響を与えていることを明らかにしました。

Windows 11 25H2の更新プログラムKB5066835でIISが応答しなくなる問題 ― Microsoftが既知の問題として公表

しかし、調査を進めると「localhost 接続失敗」は 問題の一部に過ぎず、FileExplorerのプレビュー機能停止、リカバリ環境（WinRE）での入力デバイス無反応、周辺機器機能の喪失など、複数の不具合が同時に確認されています。

本稿では、本件の影響範囲・主な不具合・エンタープライズで取るべき対策を整理します。

主な不具合事象

以下、報告されている代表的な不具合を整理します。

  1. ローカルホスト（127.0.0.1）で HTTP/2 接続不能 更新適用後、IIS や ASP.NET Core を使ったローカル開発／テスト環境で「ERR_CONNECTION_RESET」「ERR_HTTP2_PROTOCOL_ERROR」などが多発。 Microsoft はこれを HTTP.sys（カーネルモード HTTP サーバー）に起因する回帰（regression）と認定。 開発者・IT運用担当者にとって、ローカルデバッグ・モックサーバ・社内 Web サービス検証などに重大な支障を生じています。
  2. ファイルエクスプローラーのプレビュー機能停止 特定条件下（主にクラウド経由で取得した PDF 等）で、プレビューウィンドウが「このファイルはコンピューターを損なう可能性があります」という警告を表示し、プレビュー不可となる報告あり。 利用者体験の低下および、社内資料確認ワークフローへの影響が懸念されます。
  3. リカバリ環境（WinRE）で USB キーボード・マウスが反応しない Windows 11 の October 2025 更新適用後、一部機器環境で WinRE 起動時に入力デバイスが動かず、トラブル発生時の復旧操作が不能となる事象が確認されております。 これは非常時のシステム復旧・再インストール・セーフモード移行等のフェイルセーフ手順を損なうため、リスクが極めて高いです。
  4. 周辺機器（例：ロジクール製マウス／キーボード機能）で特定機能停止 一部外付けデバイスにおいて、更新後に独自ドライバ機能（カスタムボタン・ジェスチャー等）が作動しなくなった報告があります。 特にカスタマイズを多用する開発者・業務PC環境では操作性低下の懸念があります。

影響範囲と業務上の注意点

  • 対象となる OS：Windows 11 24H2／25H2、Windows Server 環境。
  • 規模：Microsoft 自身が “millions of Windows users” に影響の可能性があると明言しています。
  • エンタープライズ運用におけるリスク：
    • 開発／検証環境の停止
    • 社内アプリ・モックサーバの利用不能
    • 災害復旧／自動修復手順失効
    • 周辺機器依存ワークフローの乱れ
  • 注意点として、「該当不具合が全端末で発生するわけではない」という点も挙げられます。報告ベースでは「一部ユーザー」である旨が複数メディアで言及されています。

対応策（運用／技術視点）

エンジニアおよび統括部門が取るべき手順を以下に整理します。

  • 影響端末の特定
    Windows 11 24H2／25H2 を導入している端末をピックアップ。特に開発用途・社内サーバ用途・WinRE 活用端末を優先します。
  • 更新状況の確認とロールバック準備
    Windows Update を通じて最新の修正パッチが適用されているかを確認。Microsoft は既に HTTP/2 localhost の回帰問題を修正済みと発表しています。 ただし、影響発生中であれば当該更新（KB5066835 等）をアンインストールして旧バージョンに戻す検討も必要です。
  • 検証環境で事前テスト
    本番展開前に少数端末にてローカルホスト接続、ファイルプレビュー、WinRE 起動、周辺機器機能等を検証。異常があれば運用展開を遅延させる判断を可能とします。
  • 暫定回避策の実施
    ローカルホスト接続に問題がある場合、HTTP/2 を無効化して HTTP/1.1 を使うレジストリ改変が報告されています。 また、ファイルプレビューに対処するためには PowerShell による「Unblock-File」実行も可能です。 WinRE 入力デバイス問題がある環境では、外付け USB キーボード／マウスの代替手段を確保。または、別媒体からのリカバリ手順を整備。
  • 社内運用ポリシーとユーザー通知
    更新適用のタイミング・トラブル発生時の回避手順・ロールバック案内を文書化。ユーザー／開発者向けに影響の可能性と対応策を共有しておくことで、問い合わせ・混乱を低減します。

おわりに

今回の更新において「ローカルホスト接続不能」という開発検証領域に直結する問題が注目されていますが、これに留まらず、ファイルプレビューの不具合、リカバリ環境機能障害、周辺機器機能停止と、複数の回帰（regression）事象が併発している点が運用管理者・エンジニアにとって警鐘となるべき状況です。

一方でWinREのような通常運用から外れた状況や特定のデバイスによる不具合、一部の端末でのみ起こるという問題は事前検証では発見しにくいというのが現実です。

こういったことに対応するには、これまでどおり事前検証後に展開をすることを基本にしつつも、一斉展開するのではなく、業務の状況を鑑みながら順次展開し、不具合があればすぐに端末交換できる環境づくりが重要になります。また、最悪端末自体が使用不能に陥っても影響が出ないようにローカルにデータは残さない運用も必要になります。

流石に毎月のように致命的な不具合を起こすのは目に余るものがありますが、Windowsから脱却できない以上は自己防衛をするしかないというのが現実解になると考えられます。

参考文献

Windows 11 25H2の更新プログラムKB5066835でIISが応答しなくなる問題 ― Microsoftが既知の問題として公表

以前報告したKB5066835を適用すると、localhostへのアクセスができなくなる問題について取り上げました。

Windows 11の2025年10月累積更新「KB5066835」で「localhost」が動作不能に ― 開発者環境に深刻な影響

Microsoftは2025年10月14日に配信したWindows 11 バージョン25H2向け累積更新プログラム「KB5066835」において、Internet Information Services（IIS）を利用する環境でWebサイトが正常に読み込めなくなる不具合を公式に認めました。Microsoft Learnの「Windows release health」ページで、この事象を既知の問題（Known Issue）として掲載しています。

問題の内容

該当の更新プログラムを適用した環境で、HTTP.sysを使用するサーバー側アプリケーションが着信接続を正しく処理できず、IISでホストされるWebサイトが応答しなくなることがあります。具体的には、IISのサービスは起動しているものの、HTTPリクエストへの応答が返らない、または接続がリセットされる症状が報告されています。Microsoftは本問題を「HTTP.sysに関連する既知の問題」と明示しています。

影響範囲

本件はWindows 11 バージョン 25H2および 24H2およびWindows Server 2025に影響し、IISやその他HTTP.sysに依存するサーバーアプリケーションが対象となります。ローカル開発環境だけでなく、実運用サーバーにおいてもhttp://localhost/でアクセスしている場合は同様の症状が発生する可能性があります。

原因

Microsoftの公式説明によれば、更新プログラム適用後のHTTP.sysコンポーネントが、着信接続を処理する際に問題を引き起こすことが原因です。HTTP.sysはWindowsカーネルレベルでHTTP通信を処理する仕組みであり、IISをはじめとする多くのWebサーバー機能がこれに依存しています。この不具合により、HTTP.sys経由での通信が一部失敗する状況が生じています。

緩和策（Mitigation）

Microsoftは次の暫定的な対処法を案内しています。

  1. Windows Updateを最新の状態にすること
    [設定] > [Windows Update] > [更新プログラムのチェック] を実行し、すべての更新を適用します。
  2. 再起動を行うこと
    更新が適用済みであっても、システムの再起動によって問題が解消される場合があります。
  3. 管理対象デバイスではKnown Issue Rollback（KIR）を適用すること
    Microsoftは本問題に対するKIRを配信済みであり、企業や組織内で管理されるデバイスは、グループポリシー経由でKIRテンプレート（MSI形式）を導入することで自動的に問題を緩和できます。

今後の対応

Microsoftは、恒久的な修正（Permanent Fix）を今後のWindows Updateに含めて配信する予定としています。現時点では一時的な緩和策のみが提供されており、ユーザーは追加更新を受け取るまで上記手順による対処を行うことが推奨されています。

おわりに

本件の影響は非常に大きく、開発者だけでなく構成によっては本番環境にも深刻な影響を及ぼします。

システム管理者はゼロデイ攻撃の脅威からシステムを守るために素早いパッチ適用が求められる一方で、パッチ自体の不具合によるリスクを避けるためにシステムに対する影響調査を行わなければならないという板挟み状態に日々悩まされていることだと思います。

Windows Updateで累積更新プログラムを提供するたびに致命的な不具合を起こしている現状について、Microsoft自身はどのように考えているのか、今後どうしていくのかについては、公式からは明言されていません。この点は利用者の不安や不信感につながっています。

もしかすると、Windows自体が本番環境で使用していいOSなのか、PCで使用していいOSなのかを改めて考えるべきときにきているのかもしれません。

また、本更新プログラムでは回復環境において、USBマウスやキーボードが認識しなくなる事象も報告されています。こちらについても合わせて注意が必要です。

参考文献

Windows 11の2025年10月累積更新「KB5066835」で「localhost」が動作不能に ― 開発者環境に深刻な影響

2025年10月に配信されたWindows 11の累積更新プログラム（KB5066835ほか）を適用後、開発者環境において「localhost」への接続が失敗する現象が相次いで報告されています。

影響はIIS、IIS Express、.NET開発環境、さらにはローカルで動作するWebアプリケーション全般に及び、ブラウザ上では「ERR_CONNECTION_RESET」や「HTTP/2 PROTOCOL ERROR」などのエラーが表示される事例が確認されています。

本記事では、複数の一次情報源（Microsoft Q&A、Stack Overflow、TechPowerUp、The Registerなど）に基づき、この問題の発生状況・原因仮説・回避策を整理します。

発生状況

問題は、2025年10月のWindows 11累積更新（特にKB5066835、および先行するプレビュー更新KB5065789）をインストールした後に発生します。

ユーザー報告によると、次のような現象が確認されています。

  • http://localhost または https://localhost にアクセスすると通信がリセットされる
  • Visual StudioのIIS Expressデバッグが起動しない
  • ローカルHTTPリスナーを使用する認証フローや開発ツールが動作しない
  • 一部のサードパーティアプリケーションが内部HTTP通信の確立に失敗する

Stack OverflowやMicrosoft Q&Aフォーラムでは同様の症状が多数報告されており、再現性の高い不具合として注目されています。

想定される原因

現時点でMicrosoftから公式な不具合告知や技術文書は発表されていませんが、各技術フォーラムでは以下のような分析が共有されています。

  1. HTTP/2ネゴシエーションの不具合 WindowsのHTTPスタック（HTTP.sys）レベルでHTTP/2ハンドシェイクが失敗している可能性が指摘されています。 一部のユーザーはHTTP/2を無効化することで通信が回復したと報告しています。
  2. カーネルモードHTTPドライバの変更 KB5066835ではセキュリティ強化目的の通信モジュール更新が含まれており、ローカルホスト通信の扱いに影響を与えた可能性があります。
  3. 既存環境との不整合 新規インストールされたWindows 11 24H2では問題が発生しないケースもあり、既存環境設定（IIS構成、証明書、HTTP.sysキャッシュなど）との不整合が誘発要因と考えられています。

回避策と暫定対応

現時点でMicrosoftが提供する公式修正版は存在しません。開発者コミュニティでは以下の暫定的な回避策が報告されています。

1. 更新プログラムのアンインストール

PowerShellで以下を実行して該当KBを削除する方法です。

wusa /uninstall /kb:5066835

またはプレビュー更新が原因の場合は kb:5065789 を削除します。

ただし、Windows Updateにより再インストールされる可能性があるため、Windows Updateの一時停止措置が追加で必要となります。

2. HTTP/2プロトコルの無効化

レジストリでHTTP/2を無効にすることで回避できたという報告があります。

設定は以下の通りです。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
EnableHttp2Tls = 0 (DWORD)
EnableHttp2Cleartext = 0 (DWORD)

再起動後に反映されます。

この方法は他のHTTP/2依存アプリケーションにも影響するため、慎重に実施する必要があります。

3. IISや関連機能の停止

一部ユーザーは、IISやWindows Process Activation Serviceを一時的に停止することで症状が緩和されたと報告しています。ただし副作用が大きく、根本的な解決策とは言えません。

Microsoftの対応状況

2025年10月17日時点で、Microsoft公式サポートページおよびWindows Release Healthには本不具合に関する記載はありません。ただし、TechPowerUpおよびThe Registerなどの報道によれば、社内で調査が進められている可能性が示唆されています。現状では「既知の問題（Known Issue）」として公表されておらず、次回以降の累積更新で修正されるかは不明です。

今後の見通し

今回の問題は、開発者のローカル環境に限定されるものの、影響範囲は広く、開発フロー全体に支障をきたす可能性があります。HTTP/2が標準化されて以降、ローカル通信も同プロトコルを用いる構成が増えており、根本原因の解明と恒久対策が求められます。

Microsoftが修正版を提供するまでの間は、上記の暫定回避策を適用するか、更新を保留する判断も検討すべきです。特に企業内の統合開発環境では、グループポリシーを利用して問題の更新を一時的にブロックする方法も有効です。

おわりに

2025年10月のWindows 11累積更新により発生している「localhost」接続障害は、開発者にとって無視できない問題です。HTTP/2通信の不具合が根底にあると見られ、暫定的な回避策は存在するものの、確実な解決にはMicrosoftの公式対応を待つ必要があります。

現時点では、影響を受けた環境では更新のロールバックやHTTP/2無効化を慎重に実施し、今後のパッチ情報を注視することが推奨されます。

私の環境ではDocker DesktopやJava開発環境が動作しているWindows 11に累積更新を適用しましたが、本事象は発生しませんでした。Docker Desktopの起動が少し時間かかったようにも感じましたが起動および接続はできているので問題なかったものと思われます。報告についてはMicrosoftプロダクトに集中しているようですので、.NETで開発している場合は十分注意する必要があります。

参考文献

以下が、ブログ執筆時に実際に参照した参考文献のリストです：

Windows 10、本日サポート終了 ― 10年の歴史と現状を総点検

Microsoft は 2025 年 10 月 14 日をもって Windows 10 のサポートを終了します。2015 年の提供開始から約 10 年にわたり、多くの企業・教育機関・個人ユーザーに利用されてきた Windows 10 は、安定性と互換性を重視した設計により、長期間にわたって業務システムや一般用途の基盤として定着しました。

今回のサポート終了により、Windows 10 は以降のセキュリティ更新や技術サポートの提供が終了します。これに伴い、更新プログラムの配信停止、脆弱性修正の非対応、そして一部アプリケーションやデバイスドライバーのサポート打ち切りといった影響が生じます。Microsoft は移行先として Windows 11 への更新を推奨しており、同時に一部のユーザー向けには有償または特定条件下での拡張セキュリティ更新（ESU）プログラムを提供しています。

また、Adobe や Trend Micro をはじめとする主要ベンダーも、Windows 10 のサポートを段階的に終了する方針を明らかにしています。これにより、サードパーティアプリケーションの利用環境にも制約が生じ、特に業務システムを Windows 10 上で維持している企業にとっては運用継続の可否が重要な検討課題となっています。

本稿では、サポート終了を迎えた Windows 10 の現状について、世界的なシェア動向、既知の不具合、主要アプリケーションの対応状況、ESU の展開、さらにサードパーティによる延命策までを整理します。

Windows 10のシェア状況\

調査会社 StatCounter のデータによると、2025年7月時点で世界における Windows 10 のシェアは約 44.6% でした。Windows 11 のシェアは約 52% であり、両者を合わせると Windows 系 OS がデスクトップ市場全体の約 96% を占めています。

日本国内でも同時期のデータでは、Windows 10 が約 45%、Windows 11 が約 52% と報告されています。

これらの統計からは、Windows 11 への移行が進む一方で、Windows 10 の利用率が依然として高い水準にあることが分かります。特に企業や教育機関などの業務端末では、アプリケーションの互換性や運用体制の理由から Windows 10 が継続使用されており、2025年10月のサポート終了時点でも相当数のデバイスが稼働している状況です。

サポート終了直前まで残った既知の不具合

Windows 10 の最終版であるバージョン 22H2 には、サポート終了直前の時点でも既知の不具合が残されています。Microsoft が公開している「Windows Release Health」では、これらの問題が引き続き掲載されており、10月14日以降は新たな修正が提供されないことが明記されています。

そのため、サポート終了後も一部の不具合が継続する可能性があります。以下では、公式に公表されている既知の問題の内容を示します。

最終ビルド（22H2）で報告された問題点

Microsoft が公表している既知の問題には、以下のようなものがあります。 

問題名内容概要
Windows 11 メディア作成ツールが Windows 10 で正しく機能しない可能性Windows 11 のメディア作成ツール（バージョン 26100.6584）が、Windows 10 デバイス上で予期せず終了したりエラーを表示したりする場合があるという問題。 
Web フィルタリングが有効なブラウザーで保護者の同意が表示されないファミリーセーフティ（Web フィルタリング）が有効な設定時、一部ブラウザーで保護者の同意プロンプトが表示されない問題が報告されている。 

これらはいずれも「既知の問題」としてリストアップされており、完全な解決がなされているという明示はされていません。 

Windows 10でサポートが終了するMicrosoft製アプリケーション

Microsoft のサポート文書によれば、Windows 10 のサポート終了に伴い、いくつかの Microsoft 製アプリケーションがその稼働環境としての Windows 10 に対するサポートを停止するか、制限される扱いとなります。以下が主要なものです。

Microsoft 365 アプリ（Office 系アプリ等）

Microsoft は、Windows 10 のサポート終了日である 2025年10月14日をもって、Windows 10 上での Microsoft 365 アプリのサポートも終了すると明示しています。 

ただし、Microsoft は例外措置として、Windows 10 上の Microsoft 365 アプリに対しては、2028年10月10日までセキュリティ更新の提供を継続する計画を示しています。 

Microsoft Store 経由インストール版 Microsoft 365 アプリ

Microsoft Store 経由でインストールされた Microsoft 365 アプリについては、2025年10月をもって 機能更新の提供が停止され、セキュリティ更新は 2026年12月 まで提供されると案内されています。

Windows 10でサポートが終了する主要サードパーティアプリケーション

Windows 10 のサポート終了に伴い、主要なサードパーティベンダーも順次、Windows 10 に対する製品サポートの終了や移行方針を発表しています。これらの製品は、Windows 11 以降の環境を標準動作対象とするものが増えており、今後は旧環境での継続利用が制限される可能性があります。

以下では、代表的なソフトウェアベンダーによるサポート終了方針について整理します。

Adobe製品（Creative Cloud／Acrobatなど）

Adobe の公式ヘルプページによれば、Creative Cloud の各デスクトップアプリケーションは、**最新バージョンおよびその一つ前（二世代前までを含む）**の OS に対して動作サポートを提供する方針を採っています。例えば、Creative Cloud 2025 においては、Windows 11（23H2／22H2／21H2）のほか、Windows 10（22H2／21H2）を対象とするアプリが含まれています。

Photoshop のシステム要件を見ると、Windows 10（22H2）での動作が明記されており、最低 RAM、GPU、記憶装置要件など具体的仕様が併記されています。 ただし、Adobe は LTSB や LTSC 系統のバージョンには対応しない旨も明示しており、特殊版 Windows 10 では動作制限が出る可能性があります。

Acrobat（PDF 関連アプリ）についての公式明記は、Creative Cloud の OS 要件ガイドラインの中で包括的な製品群の一部として扱われています。Adobe の方針として、Creative Cloud 製品は「最新 OS とその前後バージョンへの対応」を前提とする運用を継続するものとされています。

なお、Adobe は Premiere Rush を 2025年9月30日で提供終了（ダウンロード不可）にすると発表しており、これは一部 Adobe アプリケーションで機能削除・提供終了がすでに始まっている例です。

Adobe 製品においては Windows 10（特に 22H2／21H2）への互換性を一部維持してはいるものの、サポート対象 OS の範囲を「最新＋２世代」などで限定する方式を採用しており、Windows 10 のサポート終了後は順次制限が強まる可能性があります。

セキュリティソフト（Trend Micro／Symantec／Norton）

Trend Micro、Symantec（Broadcom）、Norton（Gen Digital 系列）といったセキュリティベンダーも、Windows 10 対応について公式要件やサポートポリシーを公開しています。以下はそれらから確認できる事実です。

Trend Micro

  • Trend Micro の最新版セキュリティソフトは、Windows 10 および Windows 11 をサポート対象 OS として明記しています。
  • ただし Trend Micro の一部製品、たとえば「Endpoint Encryption（TMEE）」では、Windows 10 22H2 を含む環境において、Full Disk Encryption や File Encryption 機能がサポート対象外になる旨が記載されています。
  • また、Trend Micro のクラウド型セキュリティ製品（Deep Security／Trend Cloud One）も Windows 10 環境での互換性が明記されています。

Symantec（Broadcom）

  • Symantec のエンドポイント製品（Symantec Endpoint Protection 14.x など）は、Windows 10 をサポート OS に含んでおり、Broadcom 社の製品互換性マトリクス上で Windows 10／Windows 11 の両対応が明示されています。
  • ただし、Symantec 製品のバージョンやリリース更新条件によって適用可能な Windows 10 のビルドや機能には制限がある旨も記載されています。

Norton（Gen Digital 系列）

  • Norton のサポート情報には、Windows XP／Vista／7 のサポート終了に関する記述はありますが、Windows 10 に対して明確に「サポート終了」を表明した文言は、少なくとも当該情報上では確認できません。
  • ただし、Norton の UWP（Universal Windows Platform）版アプリケーションについては、2026年3月31日付で提供・サポート終了を予定する旨の案内が出ています。
  • また、Norton 製品のサポートは「サポート終了期限に達していない製品に対してのみ提供する」というポリシーが公式に案内されています。

個人向けESU（拡張セキュリティ更新）のロールアウト状況

Microsoft は、Windows 10 の一般サポート終了に合わせて、個人利用者を対象とした拡張セキュリティ更新（Extended Security Updates、以下 ESU）の提供を開始しました。従来は法人契約向けに限定されていたプログラムを個人にも開放したものであり、Windows 10 Home および Pro エディションが対象となっています。

このプログラムでは、セキュリティ更新を継続して受け取るための登録手続きが順次展開されています。設定アプリから直接登録できる仕組みが導入されており、Microsoft アカウントを通じて有効化する形式が採られています。料金体系は段階的に設定されており、初年度は低価格、もしくは無償で利用できる地域も存在します。

2025年10月時点では、登録画面が表示されない利用者や、手続きの案内が遅延している事例が一部で報告されていますが、広範囲に及ぶ障害や混乱は確認されていません。大半のユーザー環境では、すでに更新プログラムの配信が行われており、段階的なロールアウトが概ね進んでいる状況です。

なお、ESU による更新内容は、これまでの Windows Update と同様に配信され、セキュリティ修正に限定されています。機能追加や仕様変更は含まれておらず、あくまで既存環境を安全に維持することを目的としています。Microsoft は今後、ESU の対象期間を最大 3 年間とする計画を公表しており、2028 年までの継続提供を想定しています。

Windows 10を引き続き保護するサードパーティの取り組み

Windows 10 のサポート終了後も、サードパーティによってセキュリティ維持を目的とした補完的な施策がいくつか発表されています。最も注目されているのは 0patch によるマイクロパッチ提供で、Windows 10 v22H2 を対象に少なくとも 5 年間、重要脆弱性に対するパッチを適用する計画が公式に示されています。

0patch の提供方式では、改変を伴わない “マイクロパッチ” を実行時メモリ上で当てる技術を用いるため、再起動不要でパッチ適用できる点が特徴です。これは、伝統的なアップデート方式よりも運用負荷を抑える設計です。

0patch の料金体系では、個人利用者向け “Pro” プランやエンタープライズ向けプランが用意されており、1 年契約、更新単位で利用できる方式です。

これらの取り組みは、Microsoft 提供の更新が終了したあとのセキュリティ維持策として選択肢を提供するものです。

おわりに

Windows 10 のサポート終了は、単に一つの OS の終焉というだけでなく、約10年にわたり企業・教育機関・個人ユーザーの基盤として機能してきた環境の節目を意味します。Microsoft は Windows 11 への移行を促進しつつ、移行が困難な利用者に対しては ESU（拡張セキュリティ更新）を提供することで、安全性を維持する手段を残しました。

一方で、サードパーティによる独自の延命策や補完的なセキュリティ支援も始まっており、0patch のようなマイクロパッチ配信サービスがその一例となっています。これらの動きは、従来の OS 依存型サポートに代わり、外部事業者や個人が自らのリスク管理を行う時代への移行を示しています。

今後は、Windows 10 のサポート終了によって生じる環境更新の波が、ハードウェアの更新やアプリケーションの再設計を促す契機となります。長期的な観点では、OS の更新サイクルに依存しないシステム設計や、クラウドサービスを中心とした運用への転換が求められます。サポート終了後も安全に利用を続けるためには、各組織が自らのシステム構成と運用方針を見直し、将来の移行計画を明確にすることが不可欠です。

参考文献

モバイルバージョンを終了