タグ: windows11

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の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 11 バージョン 25H2 一般ユーザーへのロールアウト開始と既知の不具合まとめ

Microsoft は 2025年9月30日、Windows 11 バージョン 25H2 の一般ユーザー向けロールアウトを正式に開始しました。これまで Insider プログラムを通じてテストが行われてきたビルドが、いよいよ一般ユーザーの手元に段階的に届き始めています。

今回の更新は「25H2」という名前から大規模な機能追加を連想するかもしれませんが、実際には 24H2 と同じコードベースを共有しており、根本的な変更は多くありません。むしろ本更新の狙いは、新機能を大量に投入することではなく、安定性の維持とサポート期間のリセットにあります。Windows 11 は年に 1 回の大規模アップデートを経て、利用者が最新の状態を継続的に保てるよう設計されており、25H2 への移行によって再び数年間のサポートが保証される仕組みです。

一方で、一般ユーザーに向けた提供が始まったばかりということもあり、いくつかの不具合や制約が報告されています。これらは主に特殊な利用環境や一部の機能に限定されますが、業務用途や特定アプリケーションを利用するユーザーにとっては無視できない場合もあります。

本記事では、25H2 の配布状況を整理するとともに、Microsoft が公式に認めている既知の不具合や海外メディアで報じられている注意点をまとめ、適用前に知っておくべきポイントを解説します。

25H2 のロールアウト概要

Windows 11 バージョン 25H2 は、2025年9月30日から一般ユーザー向けに段階的に配布が始まりました。今回の展開は、Windows Update を通じたフェーズ方式のロールアウトであり、一度にすべてのユーザーへ配布されるわけではありません。まずは互換性が高いと判定された環境から順次適用され、時間をかけて対象範囲が拡大していきます。そのため、まだ更新通知が届いていないユーザーも数週間から数か月のうちに自動的にアップデートが提供される見込みです。

今回の更新の大きな特徴は、Enablement Package（有効化パッケージ） という仕組みが使われている点です。これは 24H2 と 25H2 が同じコードベースを共有しているため、実際には OS の大規模な置き換えを行わず、あらかじめ埋め込まれている機能を「有効化」するだけでバージョンが切り替わる方式です。このため、適用にかかる時間は通常のセキュリティ更新プログラムに近く、従来のように長時間の再起動や大規模なデータコピーを必要としません。結果として、エンタープライズ環境における互換性リスクも抑えやすいと考えられます。

また、25H2 へ更新することで サポート期間がリセットされる 点は見逃せません。

  • Home／Pro エディション：24か月間のサポート
  • Enterprise／Education エディション：36か月間のサポート

このサポートリセットは、Windows 10 時代から継続されている「年次アップデートごとにサポートを更新する」仕組みの一環であり、企業ユーザーにとっては計画的な運用管理を続ける上で重要です。特に長期利用が前提となる法人や教育機関では、25H2 への移行によってセキュリティ更新を含む公式サポートを再び長期間受けられるようになります。

さらに Microsoft は、24H2 と 25H2 を同一サービス ブランチで管理しており、セキュリティ更新や品質更新は共通のコードベースから提供されます。つまり、25H2 への移行は「大規模アップグレード」というより、安定した環境を継続するための定期メンテナンス に近い位置づけです。

25H2 のロールアウトは新機能追加の華やかさこそ少ないものの、ユーザーにとっては 安全性・安定性を担保するための重要な更新 であり、今後数年間の Windows 11 利用を見据えた確実なステップといえるでしょう。

既知の不具合と注意点

25H2 は安定性を重視した更新ですが、リリース初期にはいくつかの不具合が確認されています。これらは主に特殊な利用環境や特定の操作で発生するため、すべてのユーザーに影響するわけではありません。ただし業務システムや特定のアプリケーションを利用している場合は、事前に把握しておくことが重要です。

1. DRM／HDCP を利用する映像再生の問題

最も注目されている不具合のひとつが、著作権保護された映像コンテンツの再生トラブルです。

  • 症状：Blu-Ray や DVD、あるいはストリーミングサービスなどで再生時に画面が真っ黒になる、フリーズする、映像が出力されないといった問題が報告されています。
  • 原因：Enhanced Video Renderer（EVR）を使用するアプリケーションが、DRM／HDCP と組み合わさることで正常動作しないケースがあるとされています。
  • 影響範囲：映画視聴用の再生ソフト、業務で Blu-Ray を利用する法人環境など。日常的に PC をメディアプレイヤーとして使うユーザーにとっては深刻な制約となり得ます。
  • 回避策：現時点で Microsoft が恒久的な修正を提供しておらず、明確な回避策は示されていません。問題が出た場合は旧バージョンでの利用継続、または代替ソフトの利用を検討する必要があります。

2. WUSA（Windows Update Standalone Installer）の不具合

もう一つの問題は、管理者や企業ユーザーに影響する更新適用の不具合です。

  • 症状：ネットワーク共有フォルダ上に置いた .msu ファイルを直接実行すると「ERROR_BAD_PATHNAME」が発生し、インストールが失敗する。
  • 影響範囲：特に企業ネットワークで一括配布を行う管理者や、オフライン環境で更新を適用するユーザー。一般家庭では遭遇する可能性は低い。
  • 回避策：.msu ファイルをいったんローカル PC にコピーしてから実行することでインストール可能。Microsoft は将来的に修正を行うと発表済み。

3. Windows Defender Firewall のエラーログ

一部環境では、Windows Defender Firewall がエラーログを出力するという報告があります。

  • 内容：内部コードに関連するログが「エラー」として記録されるが、実際のファイアウォール機能には影響はないと Microsoft は説明。
  • 影響範囲：セキュリティログを監視している企業や、管理者が不具合と誤認する可能性がある。一般ユーザーには実害はほとんどない。

4. その他の報道ベースの問題

Wccftech や Neowin などの海外メディアでは、初期段階で「4件の既知の問題」が指摘されていると報じられています。ただし、その中にはすでに Microsoft が公開している項目と重複するものも含まれ、今後の修正状況によって内容は変化する可能性があります。NichePCGamer でも日本語で同様の注意喚起がまとめられており、ユーザーは随時 Microsoft のリリースヘルスページを確認することが推奨されます。

不具合情報への向き合い方

25H2 の既知の不具合は、全体として「特殊な利用ケースに限定されるもの」が多いと言えます。日常的にウェブブラウジングや Office、メールなどを利用するユーザーにとっては、更新を適用しても大きな問題に直面する可能性は低いでしょう。

しかし、

  • 映像再生を業務や趣味で行うユーザー
  • ネットワーク経由で Windows 更新を一括管理する企業環境

では影響が出る可能性があります。そのため、こうした環境ではリリースヘルスページの更新を追い、必要に応じて更新を一時的に保留する判断も検討すべきです。

おわりに

Windows 11 バージョン 25H2 は、表向きは新機能の大規模追加を伴わないアップデートですが、実際には 安定性とサポートリセットを提供する重要な節目 となるリリースです。Microsoft が近年採用している Enablement Package 方式により、24H2 からの移行は比較的スムーズであり、互換性リスクも低く抑えられています。そのため、日常的に Windows を利用する大多数のユーザーにとっては、25H2 への更新は「不可欠なメンテナンス」と言えます。

一方で、既知の不具合として DRM／HDCP を利用した映像再生や WUSA を経由した更新適用の問題が確認されており、特定の環境では不便や制約を被る可能性があります。これらは一般的な利用に直結するものではないものの、Blu-Ray 再生や企業ネットワークでの運用といったニッチなケースにおいては業務に支障を与えかねません。

以上を踏まえると、推奨される対応は次の通りです。

一般ユーザー向け

  • 更新は基本的に適用推奨。25H2 ではサポート期間が再び延長されるため、セキュリティ更新を長期的に受けられる利点は大きい。
  • 不具合は限定的で、日常的な PC 利用（ウェブ、メール、Office、ゲームなど）に重大な影響はほぼない。
  • 更新の適用は自動的に配信されるため、ユーザー側の操作は最小限で済む。

法人・管理者向け

  • 段階的適用を推奨。検証環境や一部の端末で先行適用し、業務アプリや社内システムとの互換性を確認してから全社展開するのが望ましい。
  • DRM 問題や WUSA の制約は、メディア利用やオフライン更新のワークフローに依存する企業で特に影響が出やすいため注意が必要。
  • リリースヘルスページ（Microsoft Release Health）を定期的にチェックし、解決済み／新規の既知問題を随時確認することが必須。

慎重派ユーザー向け

  • 映像再生や特殊な更新手順に依存している場合は、修正が進むまでアップデートを見送る選択肢も現実的。
  • ただし、長期的にはセキュリティリスク回避のため更新は不可欠。更新停止は一時的な対応にとどめ、早期に移行することが推奨される。

総合評価

25H2 は、目新しい機能の追加こそ少ないものの、Windows 11 ユーザーにとって 安定性の確保とサポート延長 という確かな価値を持つ更新です。特定の利用環境で不具合が報告されている点は注意すべきですが、全体的には「安心して適用できる」アップデートに位置付けられます。

今後数か月は段階的に配信が進むため、利用者は自身の環境に通知が届いた段階で適用し、必要に応じて不具合情報をフォローアップしていくのが最適解といえるでしょう。

参考文献

Windows 11 24H2 ― SSD破壊問題はKB5064081でサイレント修正されたのか

2025年夏、Windows 11 version 24H2 で配信された累積更新プログラムの適用後に、一部のユーザー環境で SSD が突然認識されなくなる、あるいはデータが消失するという深刻な事例が報告されました。特に日本国内からの報告が目立ち、影響を受けたユーザーからは「システムドライブが起動しなくなった」「BIOSレベルでSSDが認識されない」といった声が寄せられ、単なるOSの不具合にとどまらず、ハードウェアに物理的な損傷を与えるのではないかという強い懸念が広がりました。

この問題は「SSD破壊問題」と呼ばれ、メディアやコミュニティで大きな注目を集めました。Microsoft は当初から「社内のテレメトリや検証環境ではSSDの故障を再現できていない」と説明しており、公式に不具合として認めたわけではありません。しかし、ユーザー側ではアップデート後に実際の被害が相次いだことから、原因が Windows Update にあるのか、それともハードウェアやファームウェアに起因するのかを巡って混乱が続いています。

そうした中で、2025年8月末に配信された KB5064081 を適用した一部のユーザーから「SSD破壊問題が発生しなくなった」との報告が出始めました。このことが「Microsoft がサイレントに修正したのではないか」という推測を呼び、さらに議論を呼んでいます。本記事では、KB5064081 の内容とこの「解消報告」が意味すること、そして現時点で考えられるシナリオについて整理します。

KB5064081 とは何か

KB5064081 は、2025年8月29日に公開された Windows 11 version 24H2 向けの累積的なプレビュー更新プログラムであり、適用後の OS ビルド番号は 26100.5074 となります。通常、この種の「プレビュー更新」は月末にリリースされ、本番適用前に利用者からのフィードバックを収集する役割を担っており、セキュリティ修正というよりは不具合修正や機能改善に重点が置かれています。

今回の KB5064081 では、以下のように幅広い修正が含まれています。

  • アプリの安定性向上 textinputframework.dll に関連する不具合により、Sticky Notes や Notepad が予期せずクラッシュする問題を修正。
  • システムのクラッシュ対策 dbgcore.dll に起因する不具合により、Explorer などのアプリケーションが不安定になる現象を解消。
  • 認証関連の修正 Kerberos を利用したクラウド共有へのアクセス時に発生するクラッシュを修正し、エンタープライズ環境での安定性を改善。
  • ログイン時の遅延改善 ログイン画面で「Just a moment」や白い画面が数分続く現象を改善。
  • マルチメディア関連の改善 Miracast でテレビへ映像をキャストした際に数秒後に音声が停止する不具合や、オーディオサービスが応答を停止して再生できなくなる問題を修正。
  • ストレージ関連の改善 ReFS（Resilient File System）で大容量ファイルを扱う際、バックアップアプリが過剰にメモリを消費する不具合を修正。
  • IME・入力システムの修正 中国語 IME で拡張文字が正しく表示されない問題や、タッチキーボード利用時に特定条件下で入力不能になる現象を改善。
  • ARM64 デバイスでの最適化 ARM64 環境におけるアプリインストール処理の遅延を解消し、モバイルデバイスでの操作感を改善。

以上のように、KB5064081 は Windows の幅広い領域にわたって修正を加えるパッチであり、単一の不具合だけでなく OS 全体の安定性やユーザー体験を改善することを目的としています。ただし、公式のリリースノートには SSD に関連する修正内容は一切記載されていません。それにもかかわらず、ユーザーの一部から「SSD破壊問題が起きなくなった」という報告があり、これが「サイレント修正説」を生むきっかけとなっています。

公式見解と不透明さ

今回の問題に関して、Microsoft は公式に「KB5064081 が SSD 破壊問題を修正した」とは一切発表していません。むしろ同社は一貫して「社内の検証環境およびテレメトリデータでは SSD 障害を再現できていない」と説明しており、現時点では Windows Update が直接的な原因であると認めていないのが実情です。

公式ドキュメント（リリースノート）にも SSD に関する記述はなく、あくまで「アプリのクラッシュ修正」「ログイン画面遅延の改善」「ReFS のメモリ使用修正」といった一般的な安定性向上が並ぶにとどまっています。したがって、KB5064081 を適用した後に SSD 問題が発生しなくなったというユーザーの報告は、公式な根拠に裏付けられたものではなく、あくまでコミュニティやメディアを通じて流布している「観測事例」にすぎません。

さらに不透明さを増しているのは、Microsoft 以外の関係者の動きです。Phison など一部の SSD コントローラーメーカーは「現象を調査中」としていますが、具体的なファームウェア修正やリコールといった明確なアクションは示していません。結果として、「Windows Update によるソフトウェア的な問題なのか」「一部メーカーのファームウェア起因なのか」「両者が特定条件下で組み合わさった複合要因なのか」といった点は、依然として結論が出ていません。

こうした状況は、ユーザーにとって大きな混乱を招いています。例えば、あるユーザーは KB5064081 適用後に SSD が安定したと報告している一方で、別のユーザーは依然としてストレージの異常を経験しており、報告内容が一致していないのです。このばらつきは、環境ごとの差（SSD の型番、ファームウェアのバージョン、利用状況、書き込み量など）によって挙動が変化している可能性を示唆しています。

結果として、現段階では「KB5064081 が SSD 破壊問題を修正した」と断定することはできず、Microsoft の公式見解とユーザー報告の間に大きなギャップが存在する状態が続いています。この「不透明さ」こそが、サイレント修正説やファームウェア流通問題といった複数の仮説を生み出し、さらなる議論を呼んでいるのです。

別の可能性 ― ファームウェア問題

今回の SSD 破壊問題を巡っては、Windows Update 側の不具合だけではなく、SSD 自体に起因するファームウェアの問題が関与している可能性が指摘されています。特に注目されているのが、エンジニアリングプレビュー版（開発途上版）のファームウェアが誤って市場に出回っていたのではないかという仮説です。

ハードウェアの世界では、製品が正式出荷される前にメーカー内部や限られたパートナー環境で検証を行うための「エンジニアリングサンプル」や「プレビュー版ファームウェア」が存在します。これらは未完成であり、安定性や互換性が十分に確認されていないため、本来であれば一般市場に流通することはありません。しかし PCDIY! の検証報告によれば、実際に入手した SSD でこの未完成版ファームウェアが動作しており、その環境で 24H2 の更新を適用すると SSD が認識されなくなる現象を再現できたとされています。

もしこの見立てが正しいとすれば、問題の本質は Windows Update そのものではなく、試験段階のファームウェアを搭載した SSD がユーザーの手に渡ってしまったことにあります。これは製品管理や品質保証の観点から重大な問題であり、たとえ Windows 側で何らかの修正や回避策が盛り込まれたとしても、根本的な解決にはつながりません。市場に流通してしまった SSD をユーザーが容易に識別することは困難であり、ファームウェアの更新やリコール対応が必要になる可能性すらあります。

さらに厄介なのは、このような SSD が特定の条件下でのみ不具合を引き起こす点です。たとえば大容量データの連続書き込みや、SSD の使用率が高い状態で発生頻度が高まると報告されており、通常利用では問題が顕在化せず「隠れた地雷」として存在するケースも考えられます。ユーザーからの報告内容が一定しない背景には、このようなファームウェアのばらつきがある可能性が否定できません。

この視点から見ると、KB5064081 によって「解消した」とされる現象は、OS 側で間接的にトリガー条件を避けるようになったか、あるいはファームウェア依存の挙動が別の形に変化しただけという解釈も成り立ちます。つまり「Windows Update が問題を修正した」のではなく、「不安定なファームウェアを持つ SSD が市場に存在する」という事実こそが根本原因である可能性があるのです。

過去の事例から見える「サイレント修正」の可能性

Windows Update では、過去にも「サイレント修正ではないか」と噂されたケースが存在します。代表的なのが、2020年2月に配信された KB4535996 です。この更新を適用すると「コール オブ デューティ モダン・ウォーフェア」や「レインボーシックス シージ」など一部の人気ゲームでパフォーマンスが低下する不具合が報告されましたが、その後の更新プログラム適用によって改善が確認されました。しかし、リリースノートにゲーム性能の修正に関する具体的な言及はなく、ユーザーの間で「サイレント修正ではないか」との声が広がりました。

このように、過去にも修正内容が明示されないまま挙動が改善された事例はあり、「サイレント修正はあり得ない」とは言い切れません。今回の KB5064081 に関しても同様に、公式に触れられていないものの副次的に問題が解消された可能性があるという見方が生まれる背景には、こうした前例の存在があるのです。

おわりに

今回取り上げた Windows 11 24H2 における SSD 破壊問題は、単なるソフトウェアの不具合にとどまらず、ハードウェア側の挙動やファームウェア管理、そして更新プログラムの透明性といった複数の論点を巻き込んでいます。KB5064081 を適用した一部の環境で SSD 問題が再発しなくなったとの報告が出ていることは確かに注目に値しますが、Microsoft が公式に「SSD 問題を修正した」と明言していない以上、それを直接的な解決策とみなすのは時期尚早です。あくまで「副次的に改善が生じた可能性がある」という程度に留めておくのが妥当でしょう。

さらに PCDIY! の検証が示すようにエンジニアリングプレビュー版のファームウェアが引き金になったとすると、エンジニアリングプレビュー版のファームウェアが市場に流通していた可能性があることを示唆することになり、そのことが新たなリスク要因となります。本来ユーザーの手に渡るはずのない試験版ファームウェアが製品に組み込まれているとすれば、今後も想定外の不具合が発生する可能性を否定できません。OS 側で問題が一時的に緩和されたとしても、根本的な解決はハードウェアメーカーの対応に委ねられる部分が大きいのです。

また、過去にも KB4535996 で発生したゲーム性能の低下が、その後のアップデートで修正されたことが「サイレント修正されたのではないか」と噂された事例があることから、今回の KB5064081 に関しても同様の憶測が出るのは自然な流れだといえます。Microsoft が必ずしもすべての修正をリリースノートで明示するわけではない以上、「サイレント修正の可能性」を完全に否定することはできません。

こうした状況を踏まえると、ユーザーとして取るべき姿勢は「OS 更新を過信しないこと」です。SSD 問題が解消したという報告が事実であったとしても、それは限定的な環境での改善にすぎず、別の不具合やデータ消失リスクが将来発生しない保証はありません。したがって、3-2-1 バックアップルール（3つのコピーを、2種類のメディアに保存し、そのうち1つはオフサイトに保管する）を引き続き徹底し、どのような不測の事態にも備えておくことが最も現実的なリスク対策といえるでしょう。

参考文献

Windows 11 25H2 ― ISO 提供開始とその背景

Microsoft が進める Windows 11 の最新大型アップデート「25H2」は、2025 年下半期に登場予定の重要なリリースです。すでに Windows Insider Program の Release Preview チャネルでは、一般公開に先駆けて ISO イメージファイルが配布され、開発者や IT 管理者、テストユーザーが新しい環境を検証できるようになっています。これにより、クリーンインストールや仮想マシンへの導入、また企業環境における早期テストが現時点で可能となり、安定版の公開を待たずに準備を進めることができます。

Windows 11 は従来の半年ごとの更新から年 1 回の大型更新へと移行しており、25H2 はその最新の成果です。24H2 と同じ「shared servicing branch」をベースにしているため、コードベースは共通で、既に組み込まれている新機能は有効化されていない状態で保持されています。これらは正式リリース時に enablement package (eKB) によって有効化される仕組みであり、ユーザーにとっては小規模な更新でありながら大きな変化を受け取れる設計になっています。こうした仕組みは、アップデート時の負担を減らし、互換性や安定性を重視する企業利用に特に有効です。

本記事では、この Windows 11 25H2 の ISO 提供に焦点をあて、入手方法や特徴、利用する際の注意点、そして今後の展望について解説していきます。

背景

Windows 11 のアップデートサイクルは現在、年１回の大型機能更新（feature update）が主流となっており、2025 年下半期に実施されるほぼ次の更新が 25H2 です。25H2 は「shared servicing branch（共有サービシング ブランチ）」上に構築されており、機能はすでにシステム内に組み込まれているもののデフォルトでは無効化されています。正式リリース時に enablement package (eKB) として、それらの機能を有効にする設計です。この方式により、ユーザーや組織は既存の 24H2 から大きな変更なしにアップデート可能で、互換性と安定性を重視できます。

2025 年 8 月 29 日、Microsoft は Windows Insider Program の Release Preview チャネル向けに Build 26200.5074 を含む 25H2 を配信開始しました。公式発表の際に「ISO は翌週提供予定（next week）」とされていました。 

しかし ISO の提供は当初予定より 1 週間程度遅延しました。公式ブログ投稿にて「ISO 提供は遅れている（delayed and coming soon）」との追記があり、実際に ISO イメージは 2025 年 9 月 10 日（またはその近辺）に公開されました。 

この遅延の理由について、Microsoft は具体的な詳細を公表していません。品質チェックや安定性検証、あるいは翻訳など付随作業の調整が影響した可能性があると報じられています。 

以上の経緯により、ISO の提供開始は “Release Preview チャネル配信から翌週” という当初見込みより少し遅れましたが、「数週間」ではなく 1 週間程度の遅れであったことが事実に近いと考えられます。

ISO ファイルの提供状況

Windows 11 25H2 の ISO ファイルは、Windows Insider Program に参加しているユーザー向けに提供されています。Microsoft はまず 2025 年 8 月 29 日に Release Preview チャネルで Build 26200.5074 を公開し、その際に「ISO は翌週に提供予定」と案内しました。しかし実際には予定より少し遅れ、2025 年 9 月 10 日前後に公式に ISO が公開されました。この遅延について Microsoft は詳細を明らかにしていませんが、公式ブログに「ISO 提供が遅れている」という追記が行われ、品質確認や安定性の検証作業が背景にあったと見られています。

ISO ファイルは Microsoft の公式サイト Windows Insider Preview Downloads から入手可能で、ダウンロードには Microsoft アカウントで Insider Program にサインインする必要があります。提供されるエディションには Windows 11 Home、Pro、Education、Enterprise が含まれており、利用する言語や SKU に応じた選択が可能です。ISO のサイズはおおむね 7GB 前後であり、エディションや言語によって若干の差があります。

この ISO は以下のような用途で利用できます。

  1. クリーンインストール 既存の環境を初期化し、Windows 11 25H2 を新規インストールするために使用可能です。
  2. 仮想マシン環境での検証 Hyper-V や VMware、VirtualBox などに ISO をマウントしてテスト用の環境を構築できます。
  3. OOBE（Out-of-Box Experience）の確認 初期セットアップ画面やアカウント登録、地域・言語設定の動作確認が可能で、企業や開発者が導入テストを行う際に有用です。
  4. 企業環境での早期検証 Windows Update for Business や WSUS での配布に先立ち、ISO を使って新バージョンの導入検証を行うことができます。

注意点として、この ISO はあくまで Insider Preview 用の提供であり、正式リリース版ではありません。そのため、安定性や互換性の面でリスクがあるため、本番環境への導入は推奨されていません。Microsoft も公式ブログで「テスト用途を想定している」と明記しており、開発者や管理者が検証目的で利用することを前提にしています。

25H2 の ISO 提供は計画からやや遅れたものの、リリースプレビュー段階で幅広いテストを可能にし、正式リリースに向けてフィードバックを収集する重要な役割を担っています。

利用時の注意点

Windows 11 25H2 の ISO は、Insider Program 向けに提供されている プレビュー版 であるため、利用にあたってはいくつか注意すべき点があります。以下では、特に重要な観点を整理します。

1. 本番利用は非推奨

25H2 の ISO はまだ正式リリース前の段階であり、安定性や互換性が十分に検証されていません。そのため、企業や個人が業務で使う本番環境に導入するのは推奨されません。想定外の不具合や一部アプリケーションの非互換が発生する可能性があります。あくまでも テスト環境や仮想マシンでの検証用途 に限定すべきです。

2. アップデート方式の特殊性

25H2 は 24H2 と同じコードベースを持ち、enablement package (eKB) によって新機能を有効化する仕組みを採用しています。ISO からクリーンインストールする場合にはすでに 25H2 として導入されますが、24H2 から更新する場合は小規模な eKB 更新として適用されます。テストの際には、この挙動の違いを理解して検証する必要があります。

3. ハードウェア要件

Windows 11 のシステム要件は従来通り厳格に適用されます。特に TPM 2.0、セキュアブート、対応 CPU などの条件を満たさない PC では、インストール自体が拒否されるか、非公式な方法でしか導入できません。古い PC での利用は動作保証外となるため、事前にハードウェア要件を確認しておくことが重要です。

4. 更新チャネルとの関係

ISO は Release Preview チャネルのビルドをベースとしており、導入後はそのまま Insider チャネルの更新を受け取ることになります。今後もプレビュー更新が配信されるため、安定性を重視する場合は Insider の設定を見直す必要があります。検証後に安定版へ戻す場合は、再インストールが必要になる点に注意してください。

5. 言語・エディション選択

Microsoft が提供する ISO には複数のエディション（Home、Pro、Education、Enterprise）が含まれています。ダウンロード時に言語を選択できるものの、選択を誤ると検証環境での要件に合わない場合があります。企業で利用する場合は、実際に運用しているエディションと同じものを選択することが推奨されます。

6. フィードバックの重要性

Insider 向け ISO の大きな目的は、実利用環境での不具合や互換性問題の早期発見です。利用中に問題を確認した場合は、フィードバック Hub を通じて Microsoft に報告することが推奨されています。これにより正式リリース版の品質向上につながります。

25H2 の ISO は「早期検証とフィードバック収集」を目的に提供されているため、利用者は本番利用を避けつつ、テスト環境での互換性確認や動作検証に活用するのが最適といえます。

今後の展望

Windows 11 25H2 の ISO 提供は、正式リリースに向けた準備段階として大きな意味を持ちます。今回の提供スケジュールを見ると、Microsoft は従来以上に 品質保証と互換性確認を重視していることがうかがえます。Release Preview チャネルでの展開から ISO 提供までに一定のタイムラグを設けたことは、テスト結果やフィードバックを反映させるための余地を確保する狙いがあったと考えられます。

今後、25H2 は Insider Program を経て 2025 年末までに一般提供 (GA: General Availability) が予定されています。企業環境では、今回の ISO 提供をきっかけに、既存アプリケーションや業務システムとの互換性検証を進める動きが加速するでしょう。特に eKB による有効化方式が継続されるため、既存の 24H2 環境からの移行コストは小さく、スムーズなアップデートが期待されます。

一方で、正式版リリースに至るまでの過程で、セキュリティ強化や管理機能の改善といった要素がさらに加えられる可能性があります。特に近年の Windows は AI を活用した機能やセキュリティ関連の強化策を段階的に導入しており、25H2 においても Copilot の強化 や エンタープライズ向けセキュリティ機能の拡充 が注目されます。これらの機能がどのタイミングで有効化されるかは今後の重要な焦点です。

また、企業 IT 部門にとっては、25H2 の安定性や長期サポートの有無が導入計画に直結します。Microsoft は通常、秋の大型アップデートを LTSC（Long-Term Servicing Channel）やサポートポリシーの基準に設定する傾向があるため、25H2 も長期運用を見据えた採用候補となる可能性があります。

Windows 11 25H2 は「大規模な変化を伴わないが確実に進化を積み重ねるリリース」として位置づけられ、今後の正式公開に向けて、安定性・互換性・セキュリティを中心とした完成度の高い仕上がりが期待されます。企業・個人問わず、正式リリース時には比較的安心して移行できるアップデートになると見込まれます。

おわりに

Windows 11 25H2 の ISO 提供は、Microsoft が進める年 1 回の大型アップデート戦略の一環として重要な意味を持っています。今回の提供経緯を振り返ると、まず 2025 年 8 月 29 日に Release Preview チャネルで 25H2 が公開され、その後「翌週に ISO 提供予定」と告知されましたが、実際の提供は約 1 週間遅れ、9 月上旬になってからの公開となりました。このスケジュールの変化は、Microsoft が安定性と品質を優先している姿勢を示すものであり、ユーザーにとっては信頼性の高いリリースが準備されている証といえます。

ISO ファイル自体は、クリーンインストールや仮想マシンでの検証、OOBE のテストなど、さまざまな用途に利用できます。特に企業や IT 管理者にとっては、新バージョンの互換性や導入影響を早期に確認できる点が大きなメリットです。一方で、プレビュー版であるため不具合や非互換のリスクが存在し、本番環境での導入は避けるべきという制約もあります。Insider Program を通じて集められるフィードバックは、正式リリースに向けた最終調整に不可欠であり、ユーザーが品質改善に寄与する重要なプロセスとなっています。

今後、25H2 は enablement package による効率的なアップデート方式を通じて正式提供され、既存の 24H2 環境からスムーズに移行できることが期待されます。安定性とセキュリティの強化に加え、Copilot などの新機能がどのように展開されるかも注目されるポイントです。

総じて、今回の ISO 提供は「次期正式リリースに備えた検証の場」であり、Microsoft の更新戦略を理解するうえでも重要な一歩となりました。利用者は本番環境に適用するのではなく、テスト環境での動作確認や互換性検証に活用し、正式リリースに向けた準備を進めるのが最も賢明な活用方法といえるでしょう。

参考文献

Windows 11 2025年9月セキュリティアップデート ― KB5064081がもたらす新機能と注意点

2025年9月9日、MicrosoftはWindows 11向けに最新のセキュリティアップデート（KB5064081、ビルド26100.5074）をリリースしました。本アップデートは毎月の定例配信「Patch Tuesday」の一環として提供されるものであり、従来の不具合修正や脆弱性への対応に加え、ユーザー体験を大きく変える新機能やインターフェースの刷新が含まれています。

特に注目すべき点は、これまでプレビュー版や一部のユーザーに限定的に提供されていた機能が、正式に広範なユーザーへ展開され始めたことです。たとえば、AIを活用した「Recall」や「Click to Do」といった機能は、従来のOSの枠を超えてユーザーの行動履歴や作業効率をサポートする役割を担うようになりました。さらに、Windows Helloや通知センター、タスクマネージャーといった日常的に利用する要素の改善も行われており、見た目や操作性の面でも利便性が高まっています。

また、今回のアップデートは単なる新機能追加にとどまらず、Microsoftが推進する「Copilot+ PC」戦略とも密接に関連しています。高性能NPUを備えたデバイスに最適化された機能群は、AIをネイティブに組み込んだ新しいWindowsの方向性を明確に示しており、今後のプラットフォーム進化の布石となるものです。

このように、KB5064081はセキュリティ更新としての役割を果たすと同時に、Windows 11の利用体験を大きく進化させるマイルストーンともいえる重要なアップデートとなっています。

アップデートの概要

今回配信されたKB5064081は、Windows 11 バージョン24H2を対象とした累積的なセキュリティアップデートであり、ビルド番号は26100.5074となります。リリース日は2025年9月9日で、定例の「Patch Tuesday」に合わせて世界同時に配信されました。Patch Tuesdayは、企業システム管理者にとって特に重要な更新日であり、脆弱性修正や新機能追加が一度に適用されるため、運用計画や検証作業に直結します。

今回のアップデートには、既知のセキュリティホールの修正やシステムの安定性改善に加えて、ユーザーインターフェースの刷新やAIを活用した新機能の導入といった「機能更新的な要素」も含まれています。従来、セキュリティ更新と機能強化は分けて提供されることが多かったのに対し、本アップデートでは両者が一体的に提供されており、Windows 11が「AIネイティブOS」として進化を続けていることを示しています。

また、配信方式は段階的ロールアウトが採用されており、すべてのユーザー環境に同時に反映されるわけではありません。利用環境やハードウェア構成によっては、更新直後には一部の新機能が無効化された状態で提供され、後から有効化される仕組みになっています。このため、企業ユーザーは検証環境での挙動確認を経て本番環境へ展開する際に注意が必要です。

さらに、今回のアップデートは「Copilot+ PC」向けの要素を多く含んでおり、高性能NPUやBitLocker対応といった特定のハードウェア要件を満たすデバイスでなければ利用できない機能が存在します。これはMicrosoftが進めるAI統合戦略の一環であり、今後のWindowsプラットフォームが従来型PCとCopilot+ PCで差別化されていく兆候ともいえます。

追加された主な新機能

2025年9月9日に公開された KB5064081（ビルド 26100.5074）には、ユーザー体験や管理機能の向上に寄与する多数の変更と新機能が含まれています。以下に、公式情報や信頼できる報道に基づいた内容をまとめます。

1. Recallアプリのホーム画面刷新（Copilot+ PC専用）

  • Recallのホーム画面が再設計され、検索・最近のアクティビティ・トップコンテンツへのアクセスが容易になりました。タイムラインは別ページで提供されます。  

2. Click to Doにインタラクティブチュートリアル（Copilot+ PC専用）

  • 初回起動時に表示される、テキストと画像で操作を案内するチュートリアルが追加されました。再表示も可能です。  

3. 通知センターに秒表示

  • タスクバーの時計に「秒」単位の表示を追加。Settings > 時刻と言語 から有効化可能。  

4. Windows Search：写真検索のグリッド表示

  • 画像検索結果がグリッド形式で表示されるようになり、ビジュアルの識別性が向上。インデックス未完了時の通知表示も追加。  

5. ウィジェットボードとロック画面の刷新

  • ウィジェットパネルが左ペイン付きの新デザインに。複数ダッシュボード（初期は欧州限定）が追加可能。
  • Discoverフィードに Copilot キュレーション付きストーリーが展開。
  • ロック画面のウィジェットカスタマイズがグローバル対応へ拡張。

6. Windows HelloのUI刷新

  • サインイン画面や認証方法選択をより視覚的に分かりやすく改善。パスキーやRecall、Microsoft Store などでも一貫した新デザインが適用。

7. 設定アプリの強化

  • SettingsにAIエージェントが統合。自然言語で問題を記述し設定を検索・自動構成可能（Copilot+ PC向け、対象拡大中）。
  • 「最近のAIアクティビティ」セクションが追加され、テキスト・画像生成を実行した外部アプリの履歴を表示。  
  • アプリの位置情報やカメラなどへのアクセス許可ダイアログが、画面暗転＋視覚強化された形式に更新。  
  • アクティベーション状態表示用ダイアログ（期限切れなど）のUIも刷新。  
  • 高度設定ページ、デバイスカード、追加された時間・言語設定（Control Panelから移植されたもの）も含む。  

8. タスクマネージャーのCPU指標改善

  • 業界標準のCPU計測メトリクスを採用。
  • “Details” タブに新たに“CPU Utility”列が追加可能。  

9. Windows Backup for Organizations（商用向け）

  • 個人向けアプリと同様の機能を備えた、組織用バックアップソリューションが正式提供開始。

10. ファイルエクスプローラーの視覚改良

  • コンテキストメニューにセパレーター導入。
  • ホーム画面にユーザーアイコン付き「Activity」列。「Recommended」セクションではMicrosoft 365パーソナルカードのプレビュー可能。  

11. PowerShell 2.0の廃止

  • レガシーな PowerShell 2.0 が正式に削除・非推奨に。

その他（計画されていたが延期された機能）

  • Settingsホームに「Your Device Info」カード表示。
  • Control PanelからSettingsへのその他移行機能：追加時計や時刻サーバー形式、地域フォーマット、Unicode UTF-8対応など。

利用方法と注意点

アップデートの入手方法

今回のKB5064081は、通常のWindows Update経由で配信されます。

  • 個人ユーザーは自動更新を有効にしていれば順次適用されます。
  • 企業や組織環境では、WSUS（Windows Server Update Services）やMicrosoft Intune経由で配布・制御が可能です。特に業務システムに影響が出る可能性があるため、テスト環境での検証を経て本番環境へ展開する運用が推奨されます。

また、Microsoft Update Catalogからスタンドアロンパッケージ（.msuファイル）をダウンロードして手動適用することも可能です。

機能の段階的展開

本アップデートで追加された新機能の一部は、インストール直後には無効化された状態で提供されます。これはMicrosoftが採用しているControlled Feature Rollout（CFR）と呼ばれる仕組みによるもので、ユーザー環境や地域ごとに段階的に展開されます。したがって、同じKBをインストールしても利用可能な機能に差が出る場合があります。

早期利用の方法（ViveTool）

新機能を即座に試したい場合は「ViveTool」を利用して手動で有効化することが可能です。例えば、以下のコマンドを実行すると、一部の非公開機能を強制的にオンにできます。

vivetool /enable /id:57048218

ただし、この方法は正式サポート対象外であり、将来的に不具合や予期せぬ挙動が発生するリスクもあるため、検証環境での利用が望ましいとされます。

ハードウェア要件への注意

今回のアップデートで導入された Recall や Click to Do などの機能は、いわゆる Copilot+ PC を対象にしており、以下の条件を満たす必要があります。

  • NPU（Neural Processing Unit）が40 TOPS以上の性能を持つこと（例：Qualcomm Snapdragon X Elite / X Plus）。
  • BitLockerまたはDevice Encryptionが有効化されていること。
  • Windows Helloが利用可能な環境であること。

これらの要件を満たさないデバイスでは、該当機能が表示されないか、利用が制限されます。そのため、従来型のPCユーザーにとっては「更新後に新機能が見つからない」という状況が起こり得ます。

システム互換性と運用上の注意

  • 企業環境では、セキュリティ更新と新機能追加が同時に行われるため、従来よりも互換性検証の重要度が増しています。特にセキュリティポリシーや独自ツールとの干渉に注意が必要です。
  • PowerShell 2.0の廃止により、レガシースクリプトや管理ツールの一部が動作しなくなる可能性があります。該当環境ではPowerShell 5以降への移行を前提にした運用見直しが求められます。
  • UI刷新（Windows Hello、認証ダイアログなど）により、ユーザーサポートの現場では操作方法や画面デザインの変化に対応した案内が必要になります。

アップデート適用に関するリスクと対策

  • 大規模アップデートに伴うドライバーの互換性問題は過去にも報告されているため、特に業務用PCでは事前のバックアップと段階的導入が推奨されます。
  • 更新後の不具合に備えて、システム復元ポイントやイメージバックアップを作成してから適用するのが安全です。
  • 配信停止やロールバックが必要な場合、wusa /uninstall /kb:5064081 コマンドでアンインストールが可能です。

まとめ

利用にあたっては、更新そのものは従来どおりWindows Updateから実施可能ですが、

  • 機能展開のタイミング
  • ハードウェア要件の有無
  • CFRによる段階配信
  • レガシー機能廃止の影響

といった複数の要素を考慮する必要があります。特に企業ユーザーはセキュリティ修正と新機能導入の両面での検証・準備が不可欠です。

今後の展望

今回のKB5064081によるアップデートは、単なるセキュリティ修正にとどまらず、Windows 11がAIネイティブOSとして進化していく方向性を明確に示しています。特に「Recall」や「Click to Do」のようなCopilot+ PC向け機能は、従来のPC体験を大きく変えるものであり、ユーザーの行動やデータをインテリジェントに記録・支援するという新しい利用スタイルを押し広げていくでしょう。

AI統合の加速

MicrosoftはすでにCopilotをWindowsやOfficeに統合していますが、今回のアップデートでOSレベルでのAI統合がさらに強化されました。今後は、設定管理、検索、ファイル操作など、日常的な操作のあらゆる場面にAIが組み込まれることが予想されます。また、外部アプリケーションの利用履歴やAI生成のアクティビティをOSが直接把握できるようになった点からも、AIがOSの中核機能にシームレスに組み込まれる方向が見て取れます。

Copilot+ PCとの棲み分け

一方で、新機能の多くがCopilot+ PCに限定されていることは、Windowsユーザー全体を二分化する可能性を含んでいます。今後のWindowsは、ハードウェア性能によって利用可能な機能が大きく異なるプラットフォームへ移行することが予想されます。これは、PC市場において新しいハードウェアへの買い替え需要を喚起する狙いもあると考えられます。従来型PCを利用するユーザーにとっては、アップデート後に「何も変わっていない」と感じる一方で、Copilot+ PCユーザーには全く異なる体験が提供されるという状況が広がっていくでしょう。

セキュリティと互換性

今回のアップデートではPowerShell 2.0の廃止など、レガシー機能の整理も進んでいます。これはセキュリティリスクを軽減する一方で、古いシステムやスクリプト資産に依存しているユーザーにとっては対応が求められる領域です。今後も同様の互換性切り捨てが進むことが想定され、企業ユーザーは常に最新の開発環境や運用フレームワークへの移行を計画的に進める必要があります。

Windowsの方向性

総じて、今回のアップデートは「AIによる支援を前提としたOS」への転換点と位置付けられます。従来はユーザーが能動的に操作していた領域にAIが積極的に介入し、効率性や利便性を高める方向へ進む一方、データ活用やプライバシー保護のバランスが今後の重要なテーマになるでしょう。また、Microsoftはクラウドサービス（Microsoft 365、OneDrive、Azure）と連携する形でWindowsを強化しており、今後もローカル環境とクラウドが一体化した体験が広がっていくと考えられます。

このアップデートは、Windowsの未来像を垣間見せるものであり、ユーザーにとっては利便性向上の恩恵と同時に、新しいハードウェアや運用体制への適応が求められる重要な節目となります。

おわりに

2025年9月のセキュリティアップデート（KB5064081、ビルド26100.5074）は、Windows 11にとって単なる脆弱性修正にとどまらず、OSの進化を示す重要な節目となりました。RecallやClick to DoといったCopilot+ PC専用機能の登場は、AIを中核に据えた「次世代のWindows体験」が現実のものになりつつあることを示しています。また、通知センターへの秒表示やWindows HelloのUI刷新といった細やかな改善は、日常的な利用シーンにおける利便性を確実に高めています。

一方で、このアップデートは課題も浮き彫りにしました。特にCopilot+ PC向け機能は高性能NPUやBitLocker、Windows Helloといったハードウェア要件を満たさない限り利用できないため、すべてのユーザーが同じ恩恵を受けられるわけではありません。この「体験の分断」は、今後のWindows利用環境に大きな影響を与える可能性があります。従来型のPCユーザーには「アップデートしたのに変化が感じられない」という認識が広がる一方、Copilot+ PCユーザーは全く異なるレベルの体験を享受できるようになるでしょう。

さらに、PowerShell 2.0の廃止に象徴されるように、古い資産やレガシー機能は順次整理され、セキュリティとモダナイゼーションの両立が図られています。これは組織にとって、システム移行や互換性検証を怠らない体制づくりを求めるシグナルでもあります。

総じて、今回のアップデートは「AI統合の加速」「ユーザー体験の刷新」「互換性整理による将来指向」という三つの柱を含むものです。今後もMicrosoftはこの方向性を強め、クラウドやAIとの融合を前提にしたWindowsを進化させていくと考えられます。ユーザーや企業は、この流れにどのように対応し、どの段階で新しい環境へ移行していくかを見極めることが求められます。

KB5064081は単なるセキュリティ更新ではなく、Windowsの未来に向けた「布石」として位置づけられるアップデートといえるでしょう。

参考文献

Windows 11 KB5063878適用後に広がるSSD破壊問題 ― リテール版も無縁ではない現実

2025年夏、Windows 11の更新プログラムを適用した一部ユーザーから「SSDが突然認識されなくなった」「PCが起動しなくなった」という報告が相次ぎました。当初は特殊なエンジニアリングサンプル特有の問題とされていましたが、その後リテール版SSDでも同様の障害が確認され、状況はより深刻なものとなっています。

特に恐ろしいのは、症状が単なるシステムエラーや一時的な不具合にとどまらず、SSD自体が完全に消失し、OSはもちろんBIOSからも認識されなくなるという点です。復旧不可能に陥った事例もあり、ストレージ機器の物理故障と同等、あるいはそれ以上のダメージを引き起こしています。これは、単なるアップデート不具合を超えた「最悪のシナリオ」に近づきつつある事象といえるでしょう。

さらに問題を複雑にしているのは、MicrosoftやPhisonといったメーカーが大規模な検証を行っても再現できなかった点です。つまり、ユーザー環境によっては突如として致命的障害が発生する一方、公式側では「原因不明」とされ続けているのです。そのため、ユーザー視点では「いつ自分のPCが起動不能になるか分からない」という極めて不安定な状態に置かれています。

現状、確実な予防策は存在せず、問題は収束していません。リテール版SSDでも発生し得ることがほぼ確定的となった今、私たちに残された現実的な手段はただ一つ――日常的にバックアップを取り、最悪の事態を前提とした備えをしておくことです。本記事では、この問題の経緯と技術的背景を整理したうえで、ユーザーが今なすべき対応について考えます。

問題の経緯

この問題が初めて広く注目されたのは、2025年8月に配信されたWindows 11 24H2向け更新プログラム「KB5063878」を適用した一部ユーザーの報告からでした。国内外のフォーラムやSNSには「アップデート直後にSSDが認識されなくなった」「OSが起動できない」「BIOSからもドライブが消えた」といった深刻な書き込みが立て続けに投稿され、状況は瞬く間に拡散しました。特に日本の自作PCコミュニティでの報告が端緒となり、海外メディアも相次いで取り上げる事態となりました。

当初は、テスト用に配布されたエンジニアリングサンプル（プレリリース版ファームウェアを搭載したSSD）でのみ発生しているのではないかと考えられていました。しかし、その後のユーザー報告や検証の中で、市販されているリテール版SSDにおいても障害が確認され、「一部の限定的な環境にとどまらない可能性」が浮上しました。

この報告を受けて、Microsoftは直ちに調査を開始しましたが、「更新プログラムとSSD障害の間に直接的な因果関係は認められなかった」と結論づけました。同様に、Phisonも4,500時間以上に及ぶ大規模な検証を行ったものの、再現には至らず「問題は確認されていない」と発表しました。しかし、実際のユーザー環境では確実に障害が発生していることから、両者の発表はユーザーの不安を解消するには至りませんでした。

一方で、台湾の技術コミュニティ「PCDIY!」が独自に実機テストを実施し、Corsair MP600やSP US70といった特定モデルのエンジニアリングファームウェアでのみ再現に成功しました。この結果から「エンジニアリングサンプル由来説」が一時的に有力となりましたが、すでにリテール版でも発生報告が上がっていたため、「本当に限定的な問題なのか」という疑念は払拭できませんでした。

さらに技術系メディアの一部は、SSDの使用率が60%以上の状態で大容量ファイルを書き込んだ際に障害が引き起こされやすいという観測を紹介しました。これにより、単なるファームウェアの問題ではなく、使用環境や書き込みパターンといった複合的要因が関与している可能性も指摘されています。

このように、ユーザーの間で広がった不具合報告、メーカーによる「再現できない」との公式見解、そしてコミュニティによる部分的な再現実験が錯綜し、問題は「原因不明のまま、実害が発生し続けている」という最悪の構図を呈しているのが現状です。

技術的背景

今回の問題の最大の特徴は、従来のアップデート不具合とは異なり「ハードウェアそのものが消失したかのように扱われる」点です。多くのケースでSSDはOSからだけでなくBIOSレベルでも検出不能となり、ユーザーからは「SSDが物理的に壊れた」と同じ状況だと報告されています。単なるファイルシステムの破損やデータ消失とは次元が異なり、ストレージデバイス全体が機能を失う極めて深刻な状態です。

技術的に注目されている要素は大きく三つあります。

1. ファームウェアの違い

メーカーがテストで使用するリテール版SSDと、ユーザーが入手したエンジニアリングサンプル（開発途中のファームウェアを搭載した製品）では挙動が異なります。台湾コミュニティの再現試験では、正式に出荷されたリテール版では問題が発生しなかった一方、プレリリース版ファームウェアを搭載した個体ではSSD消失が再現されました。つまり、同じ製品シリーズでもファームウェアの差異が障害発生に直結していた可能性が高いと考えられます。

2. 使用環境とトリガー条件

一部の技術系サイトは「SSD使用率が60％を超えた状態で大容量ファイルを連続書き込みすると障害が発生しやすい」と指摘しています。これは、ガーベジコレクションやウェアレベリングなどSSD内部の管理処理が過負荷となり、ファームウェアの不具合が顕在化するケースと考えられます。もしこれが正しければ、リテール版でも特定条件下で発生し得ることを示唆しています。

3. 検証の限界

MicrosoftやPhisonは数千時間に及ぶ検証を行い、問題は再現できなかったと報告しました。しかし、これはあくまで「標準化されたテスト条件での結果」に過ぎません。実際のユーザー環境はSSDの使用年数、温度条件、残容量、接続方法など多様であり、こうした要素の組み合わせによって初めて不具合が顕在化する可能性があります。メーカー側が把握していない「現場特有の条件」が存在することが、この問題の再現を難しくしているのです。

総合すると、今回の障害は「ファームウェアの設計上の脆弱性」と「ユーザー環境に依存する特殊条件」の両方が重なったときに顕在化する問題だと考えられます。エンジニアリングサンプルが特に脆弱だったのは事実ですが、リテール版でも完全に無関係とは言えない状況が確認されており、根本的な原因はまだ解明途上にあります。

唯一の対策

現時点で、この問題に対する明確な修正プログラムやメーカー公式の恒久対策は存在していません。MicrosoftもPhisonも「再現できなかった」との見解を示しているため、原因の完全解明には時間がかかるでしょう。つまり、ユーザー自身が自衛するしかなく、唯一無二の有効な対策は「定期的なバックアップ」に尽きます。

バックアップの重要性は従来から指摘されてきましたが、今回の問題は「OSが突然立ち上がらない」「SSD自体が消失する」といった、事実上の即死に近い障害が発生する点で特異です。通常の不具合なら修復ツールや再インストールで回復できる可能性がありますが、SSDが物理的に認識されなくなる状況ではデータ復旧の手段が一切残されないことになります。

したがって、以下のような多層的なバックアップ戦略が求められます。

  1. 重要ファイルのコピー
    • ドキュメント、写真、業務データなどを外付けHDD/SSDやNASに定期的にコピーする。
    • クラウドストレージ（OneDrive, Google Drive, Dropboxなど）も有効。特にバージョン管理機能があるサービスは誤削除対策にもなる。
  2. システム全体のイメージバックアップ
    • Windowsの標準機能やサードパーティ製ソフト（例：Macrium Reflect, Acronis True Imageなど）を利用し、OSごとバックアップを作成する。
    • これにより、SSDが消失しても新しいストレージに復元できる。
  3. バックアップの多重化
    • 外付けドライブ1台のみに頼ると、そのドライブ自体の故障で全てを失うリスクがある。
    • 可能なら「外付けドライブ＋クラウド」など複数手段を組み合わせる。
  4. 定期的な検証
    • バックアップを取っているだけでは不十分。定期的に復元テストを行い、正常にリストアできるか確認する必要がある。

また、SSDに関しては以下の運用上の工夫も一定のリスク低減につながります。

  • 使用率を常に80％未満に抑え、余裕を持たせて運用する。
  • 大容量書き込みを行う際には、事前にバックアップを済ませる。
  • ファームウェアの更新が提供されている場合は、信頼できる公式ソースから適用する。

これらの対策を実践することで、万一PCが突然起動不能になっても、データそのものは守ることができます。バックアップは面倒に感じられる作業かもしれませんが、SSDの消失リスクを前にすれば、唯一確実に未来を守る行動であることは疑いようがありません。

おわりに

Windows 11とSSD「破壊」問題は、当初は一部のエンジニアリングサンプルに限定された現象と考えられていました。しかしその後、リテール版SSDでも報告が相次ぎ、一般ユーザーにとっても他人事ではない事象であることが明らかになっています。メーカーは「再現できない」と説明し続けていますが、現実にはSSDが突然消失し、復旧不可能になるケースが存在するのです。これは、ソフトウェア更新による一時的な不具合や性能低下の範囲を超え、ユーザーの生活や業務を直撃する「もっとも悪い結果」に近いものだと言えるでしょう。

重要なのは、この問題が「いつ誰の環境で起きるのか分からない」という点です。使用しているSSDのモデルやファームウェアが直接の要因でなくても、使用率や書き込み条件といった複合的な要因が絡むことで、誰もが潜在的にリスクを抱えている可能性があります。つまり、いくら自分のPCが安定して動いているからといって油断はできません。

こうした状況下でユーザーが取れる選択肢は極めて限られています。ファームウェア更新や今後の修正パッチに期待することはできますが、それは外部に依存する解決策であり、即効性も確実性もありません。唯一、今すぐにできて、確実に自分のデータを守れる手段は「バックアップを取ること」だけです。外付けドライブでもクラウドでも構いません。定期的に複数の手段でバックアップを確保し、いざという時に復元できる体制を整えておくことが最終的な防御線になります。

今回の問題は、SSDという基幹ストレージに潜むリスクを浮き彫りにしました。便利で高速な技術が進化する一方で、その裏には突然の故障や予期せぬトラブルが常に潜んでいます。だからこそ、日々の運用に「バックアップ」という習慣を組み込み、いつでも最悪のシナリオに備えておくこと――それが私たちに課された現実的な対処法です。

参考文献

Windows 11 KB5063878アップデートとSSD障害報告 ― PCDIY!検証とPhisonの真相解明

2025年夏、Windows 11 の大型アップデートを適用した一部ユーザーから「SSDが突然認識されなくなった」「ドライブが壊れてデータが消失した」といった深刻な報告が相次ぎました。特に KB5063878 や KB5062660 といった更新プログラムの適用後に発生するという証言が重なったことで、コミュニティやメディアでは「Windows Update が SSD を破壊しているのではないか」という疑念が一気に広がりました。

SNS や海外フォーラムでは、システムディスクが RAW 化して起動できなくなった例や、大容量ファイルをコピー中にエラーが発生してSSDが消失したといった体験談も共有され、不安を持つユーザーが増加。バックアップを呼びかける声や、アップデートの適用を控える動きも見られました。

一方で、マイクロソフトやSSDメーカー側は「現時点でアップデートと物理的故障の因果関係は確認されていない」と説明し、真相は不明のままでした。こうした中で注目されたのが、台湾のハードウェアレビューサイト PCDIY! による独自検証です。Facebookグループで公開された実測結果は、疑惑の背景を理解するうえで重要な手がかりとなりました。

本記事では、このPCDIY!の検証内容を整理し、現在判明している事実と、依然として残る疑問点について解説します。

PCDIY!の実測内容

台湾のハードウェアレビューサイト PCDIY! は、Windows 11 のアップデート後にSSDが破損したという報告を受け、実際に自らのテスト環境で大規模なストレージ検証を行いました。テストでは 「100GB〜1TBの超大容量ファイルを繰り返し書き込み続ける」という高負荷シナリオ を設定し、一般的なベンチマークソフトでは見えにくい長時間連続書き込み性能や安定性を確認しました。

その結果、以下の現象が確認されました。

  • Corsair Force Series MP600 2TB コントローラ：Phison PS5016-E16-32 → テスト中に突然認識不能となり、完全に動作不能。PCからドライブが消失し、再起動しても認識されない状態に陥った。
  • Silicon Power US70 2TB コントローラ：Phison PS5016-E16-32 → Corsairと同様に動作不能。ファイル転送途中でエラーが発生し、そのままアクセス不能になった。
  • Apacer AS2280F4 2TB コントローラ：Phison PS5026-E26-52 → ドライブが壊れることはなかったが、連続使用を続けると速度が大きく低下。特に空き容量が減った状態では「越用越慢（使うほど遅くなる）」現象が顕著に表れ、転送速度が当初の半分以下にまで落ち込んだ。

テストは、AMD Ryzen 9 9950X3D を搭載した AM5 プラットフォーム と Intel Core Ultra 285K を搭載した LGA1851 プラットフォーム の双方で行われ、いずれも最新の Windows 11 24H2 環境＋問題となっている更新プログラムを適用済み という条件で実施されています。

さらに、PCDIY!はハイエンドの冷却装置や安定した電源を備えた環境を整え、ハードウェア的なボトルネックや電源不足といった要因を排除したうえで検証しており、環境依存ではなくソフトウェアやファームウェアに起因する問題を浮き彫りにする意図がありました。

これらの検証結果により、当初は「Windows 11 の更新が SSD を直接破壊したのではないか」という強い疑念が浮上しました。しかしその後の調査で、実際に破損したSSDが エンジニア向けの未完成ファームウェアを搭載していた ことが明らかになり、問題の構図が大きく変わることになりました。

Phisonによる現地調査

PCDIY!の報告を受けて、SSDコントローラメーカーである Phison（群聯電子） は非常に迅速に対応しました。問題が発覚した直後、Phisonは4名のエンジニアを台湾のPCDIY!テストラボに派遣し、実際に現場で同じ条件下での再現実験を行いました。メーカー自らがレビュー現場に足を運ぶのは異例であり、それだけ事態を重く見ていたことが分かります。

Phisonのエンジニアは、PCDIY!が使用したのと同型のSSDを持ち込み、同一環境下で徹底的な検証を開始しました。条件は以下の通りです。

  • テスト環境
    • AMD Ryzen 9 9950X3D 搭載の最新 AM5 プラットフォーム
    • Intel Core Ultra 285K 搭載の最新 LGA1851 プラットフォーム
    • 最新の Windows 11 24H2 環境に、問題とされた更新プログラム（KB5063878 / KB5062660）を適用済み
  • テスト内容
    • 100GB〜1TBの大容量ファイルを連続して書き込み
    • SSDに高い負荷をかけ続け、認識エラーや性能低下が再現するかどうかを確認

数時間にわたる集中的なストレステストが行われましたが、Phisonが持ち込んだドライブでは 一度も破損やクラッシュは発生せず、速度低下も見られませんでした。つまり、同じモデル名・同じ条件のSSDであっても、PCDIY!が経験した「SSDが完全に認識不能になる」という現象は再現できなかったのです。

この時点で、Phisonは「問題はOSや更新プログラムだけに起因するものではなく、個別のドライブに依存する可能性が高い」と判断しました。特に、PCDIY!の環境で実際に破損したSSDはすでにOSから認識されなくなっており、簡易な診断ツールでもアクセス不能な状態でした。そのため、Phisonはこれらのドライブを回収し、本社の研究所で詳細なファームウェア解析とメモリセルレベルの診断を行うことを決定しました。

さらに、Phisonは自社ラボで既に 累計4,500時間以上、2,200回以上のテストサイクル を実施しており、その中で同様の異常は一度も確認されていませんでした。つまり「大規模な社内検証では問題は見つからなかったのに、PCDIY!の個体では深刻な障害が発生した」という事実が浮き彫りになったわけです。

こうした調査の過程を経て、最終的に「破損したSSDがエンジニア向けの未完成ファームウェアを搭載していた」という真相が突き止められることになります。

真相の判明 ― エンジニア版ファームウェア

PhisonとPCDIY!による共同調査の結果、問題の核心がようやく明らかになりました。PCDIY!で破損や異常が発生した Corsair Force Series MP600 および Silicon Power US70 のSSDは、いずれも市販されている通常製品ではなく、エンジニアリングサンプル（Engineering Sample、略してES版） と呼ばれる試作段階の個体だったのです。

ES版SSDは、メーカーがファームウェアの完成前にパートナーやレビューサイトに提供するもので、最終的な製品版とは異なります。正式リリース前のため、ファームウェアの安定性が十分に保証されておらず、エラー処理や例外動作に不具合が残っている可能性が高いのが特徴です。本来であれば量産前の検証や内部テストのために使われるもので、一般消費者が購入することはまずありません。

今回のケースでは、このES版SSDに未完成のファームウェアが搭載されていたため、Windows 11の更新による高負荷書き込み条件下で障害が顕在化しました。Phisonの正式版ファームウェアでは4,500時間以上の耐久テストを経て問題が確認されていないことから、根本原因はWindows Updateではなく、試作版ファームウェアに存在した不具合であることが確定的となりました。

この発見によって「Windows 11のアップデートがSSDを破壊する」という当初の疑念は大きく後退しました。むしろ、PCDIY!の検証は、製品として市場に流通する前のハードウェア・ファームウェアが持つリスクを浮き彫りにしたと言えます。

一方で、この結論は新たな論点も提起しました。

  • 本来一般市場には出回らないはずのエンジニア版SSDが、なぜPCDIY!のテスト環境に存在したのか。
  • 仮にレビュー用として提供されたものであれば理解できますが、万が一、流通経路の混乱や管理の不備によって ES版ファームウェア搭載SSDが市販品に紛れ込むリスクは本当にゼロなのか。

Phisonや各SSDベンダーは「リテール版では正式版ファームウェアが搭載されており、消費者が入手する製品は安全である」と説明しています。しかし、ユーザーからすれば「自分の購入したSSDが確実に正式版ファームウェアを搭載しているのか」という懸念は残ります。今回の件は、OSやアップデートだけではなく、ハードウェア供給プロセスの透明性や品質管理の重要性を再認識させる事例となりました。

Apacer SSDの速度低下について

PCDIY!の検証で注目されたもう一つの事例が、Apacer AS2280F4 2TB（Phison PS5026-E26-52搭載） で確認された「越用越慢（使うほど遅くなる）」現象です。このSSDはCorsairやSilicon Powerのように突然故障することはありませんでしたが、連続して大容量ファイルを書き込み続けると速度が顕著に低下し、一定の使用時間を超えると当初の転送速度を維持できなくなりました。

この現象の背景には、現代のSSD設計に共通する複数の仕組みがあります。

  1. SLCキャッシュ 多くのTLC/QLCベースのSSDは、一部のセルをSLCモード（1セル1ビット）として運用し、書き込み速度を一時的に高速化しています。しかし、キャッシュ領域が使い切られると、本来のTLC/QLC速度に落ち込み、書き込みが大幅に遅くなります。
  2. Over-Provisioning (OP) SSD内部に確保された予備領域で、書き換え負荷を分散させる仕組みです。空き領域が十分にある場合は性能を維持できますが、ドライブ使用率が50％を超え、OP領域が逼迫するとガベージコレクションの負荷が増し、速度が低下します。
  3. Garbage Collection（GC）と書き換え特性 SSDは上書きができないため、一度データを書いたセルを消去してから再利用します。この「消去＋書き直し」処理が頻繁になると、連続書き込み時に速度が顕著に落ちます。特に大容量ファイルを扱う場合、空きブロックの再利用効率が下がり、性能低下が発生しやすくなります。

PCDIY!のテストでは、100GB〜1TB規模の大容量データを連続書き込みするという極端なシナリオを採用しており、この状況ではSLCキャッシュがすぐに枯渇し、さらにOP領域やGCの負担が増大するため、速度低下が如実に現れました。これはApacer製品に限らず、ほとんどのコンシューマー向けSSDが抱える特性です。

さらに重要なのは、通常のWindowsフォーマットではこの速度低下を解消できないという点です。フォーマットは論理的なファイルシステムを初期化するに過ぎず、SSD内部のキャッシュ状態や未使用ブロックの整理までは行いません。そのため、速度低下を根本的に解決するには、以下のような専用手段が必要です。

  • SSDメーカーが提供する 「Secure Erase（完全消去）」ツール を使用する。
  • 一部のマザーボード（ASUSやASRockなど）に搭載されている BIOSレベルのSSD消去機能 を利用する。

これらの方法を用いることで、セルの状態がリフレッシュされ、SSDの転送速度を初期状態に近い水準へ回復させることが可能です。

したがって、Apacer AS2280F4で確認された速度低下は製品の欠陥ではなく、SSDが本来的に持つ設計上の制約が高負荷テストで顕在化したに過ぎません。日常的な使用シナリオ（OSやアプリの起動、通常のファイル操作）ではほとんど問題にならず、実利用で大きな支障が出るケースは限定的と考えられます。

おわりに

今回のPCDIY!の実測とPhisonの現地調査によって、当初広まっていた「Windows 11 のアップデートがSSDを直接破壊する」という強い疑念は大きく後退しました。実際には、PCDIY!のテスト環境に存在していた エンジニアリングサンプル版ファームウェア が原因であり、市販されている正式版SSDでは再現されないことが確認されています。つまり、一般ユーザーが購入したSSDで同じように突然クラッシュして消失するリスクはきわめて低いといえます。

しかし、今回の騒動は単なる「技術的な誤解の解消」で終わる話ではありません。むしろ、いくつかの重要な疑問を新たに突きつけています。

  • 市場流通の透明性 本来は一般流通しないはずのエンジニアリングサンプル版SSDが、一般ユーザーの環境に存在していたのはなぜか。メーカーからレビュワーへ提供されたものであれば説明はつきますが、それでも「未完成ファームウェアが動作するSSD」が実際に利用可能な状態にあったこと自体が、サプライチェーンの管理体制に不安を残します。
  • 消費者が確認できない不透明性 ユーザーが手元のSSDにどのバージョンのファームウェアが搭載されているかを明確に判断するのは容易ではありません。メーカーが「市販品はすべて正式版」と説明しても、実際にその保証をエンドユーザーが独自に検証する手段は乏しいのが現状です。
  • 再発の可能性 今回のケースはファームウェアに起因するものでしたが、OSアップデートとハードウェアの相性が思わぬトラブルを引き起こす可能性は常に存在します。特に高負荷・大容量転送など、日常利用では再現しにくい条件下で問題が潜むこともあり、ユーザーの不安は完全には払拭できません。

まとめると、今回の「SSD破壊騒動」は、表面的には「エンジニア版ファームウェアが原因」として決着を見たように見えます。しかし、裏を返せば、ハードウェアメーカーとソフトウェアベンダーの間の情報共有や品質管理がどこまで徹底されているのか、そして市場に流れる製品が本当にすべて安全なのかという、より大きな問題を私たちに突き付けたともいえるでしょう。

消費者にとって最も重要なのは、自分が入手した製品が確実に正式版であるという「安心感」です。その保証が揺らぐ限り、不安は完全には解消されません。今回の件は一つの答えに到達したように見えて、実際にはまだ多くの問いを残しており、この問題はまだ終わっていないのです。

参考文献

Windows 11 25H2 ― ISO配布延期が企業の検証プロセスに与える影響

Microsoftは2025年8月末、Windows 11 バージョン25H2（Build 26200.5074）をRelease Previewチャネルで提供開始しました。当初の発表では、すぐにISOイメージが公開され、ユーザーや企業が自由にクリーンインストールできるようになる予定でした。しかし実際には、ISOの提供は「来週公開予定」から「遅延中、まもなく公開」という表現に修正され、具体的な公開日程は明らかにされていません。

この「ISO配布延期」は一見すると些細な遅れに思えるかもしれませんが、企業のシステム部門やIT管理者にとっては深刻な問題です。新しいWindowsの評価や検証は、単なる不具合確認にとどまらず、機能削除や仕様変更が既存システムや運用にどのような影響を与えるかを確認する重要なプロセスです。そのためには、旧環境の影響を一切排除したクリーンインストール環境で検証を行うことが不可欠です。

ISOが入手できない状況では、検証用PCや仮想環境に新バージョンを完全な初期状態で導入することができず、互換性の確認作業が後ろ倒しになります。特に、半年先から1年先の展開を見据えてスケジュールを組んでいる企業では、検証開始が遅れることがそのまま導入全体の遅延に直結しかねません。本記事では、このISO配布延期が具体的にどのような影響を及ぼすのかを整理し、企業のシステム担当者にとってのリスクと課題を考察します。

Windows 11 25H2の特徴と変更点

Windows 11 25H2は、従来の大型アップデートとは異なり「イネーブルメントパッケージ（eKB）」方式で提供されます。これは、既存の24H2環境に小規模な更新プログラムを適用することで、新バージョンを有効化する仕組みです。この方式はすでにWindows 10でも採用されており、インストールの所要時間が短く、システム全体への影響も少ないというメリットがあります。利用者からすれば、通常の月例更新プログラムと同じ感覚でアップデートが完了するのが大きな特徴です。

しかし「軽量な更新」である一方で、25H2にはいくつかの重要な変更点も含まれています。特に注目すべきは以下の2点です。

  1. PowerShell 2.0 の削除 PowerShell 2.0は長年利用されてきたスクリプト実行環境ですが、セキュリティ上の懸念が指摘され、以前から非推奨とされていました。25H2ではついに完全削除となり、古いスクリプトや管理ツールが動作しなくなる可能性があります。運用自動化や管理業務で依存している企業では、移行計画やコード修正が必須となります。
  2. WMIC（Windows Management Instrumentation Command-line）の削除 WMICはシステム情報の取得や管理を行うための古いコマンドラインツールです。現在ではPowerShellベースのWMIコマンドレットに移行が推奨されており、25H2での削除はその流れを確定的なものにしました。資産管理ツールや監視システムなど、WMICを呼び出す仕組みを利用している環境では動作不良が発生する可能性があります。

加えて、25H2は「新機能追加」が目立たないリリースとなる点も特徴です。Microsoft自身も25H2について「新機能は含まれず、安定性やセキュリティ改善に重点を置いた更新」と説明しています。したがって、ユーザー体験が大きく変わることはありませんが、裏側では従来機能の整理やセキュリティ強化が進められており、企業環境への影響度は決して小さくありません。

これらの変更は一般ユーザーにとっては目立たないものの、システム管理者にとっては大きな意味を持ちます。特に、既存の運用スクリプトや監視基盤がどの程度新しい仕様に対応できるかを事前に把握しておく必要があります。そのため、25H2の評価は単なるアップデート確認ではなく、既存環境への影響評価と移行計画立案の起点となるのです。

ISO配布延期の影響

Windows 11 25H2のISOイメージが提供されないことは、個人ユーザーにとっては「少し待てばよい」程度の話に見えるかもしれません。しかし、企業のシステム部門やIT管理者の立場からすれば、これは単なる遅延以上の深刻な問題を意味します。なぜなら、ISOがなければクリーンインストールによる検証環境の構築ができないためです。

1. クリーンインストール検証の重要性

アップグレードによる動作確認では、既存のアプリケーションや設定が残ってしまい、真に新しい環境での挙動を把握することはできません。とくに企業では、システム障害が発生した際のトラブルシューティング手順や、ゼロベースからのセットアップ手順を検証する必要があります。ISOがないことで、この「完全な初期状態の再現」ができず、検証作業の信頼性が損なわれます。

2. 削除・変更機能の依存確認ができない

25H2では、PowerShell 2.0やWMICといった古い機能が削除されました。これらは企業の資産管理や監視スクリプト、インストーラなどで今なお利用されている場合があります。クリーンインストール環境で実際に動作させて初めて、依存関係がどこに潜んでいるかを確認できます。ISOが配布されないことで、この重要な検証作業が進められなくなり、結果的にシステム移行計画全体が停滞します。

3. 展開スケジュールへの影響

多くの企業は半年〜1年先のOS展開を見据え、早期から検証を開始します。ISOが遅れれば、検証開始が遅れ、それに伴って展開スケジュールも後ろ倒しになります。社内ポリシーの改訂、利用者向けマニュアル整備、教育計画といった付随作業にも影響が及び、最終的に導入の遅延やコスト増大を招く可能性があります。

4. セキュリティとコンプライアンスへのリスク

新しいWindowsリリースでは、セキュリティ機能の強化や一部仕様の変更が行われることがあります。これを早期に確認できなければ、脆弱性対策や監査対応の準備が遅れ、業種によっては法規制やコンプライアンス上のリスクが発生します。特に金融、医療、公共機関といった分野では、検証の遅れが直接的に業務リスクへとつながります。

要するに、ISO配布の遅延は「単に新しいOSを試せない」という話ではなく、企業の検証プロセス全体を止め、導入計画やセキュリティ評価を遅延させる重大な要因になり得ます。

まとめ

Windows 11 25H2のISO配布延期は、一般利用者にとっては「少し待てば済む話」に映るかもしれません。しかし、企業のシステム部門にとっては影響が大きく、単なる遅延では片づけられません。

まず、ISOがなければクリーンインストール環境での検証ができず、削除・変更された機能に対する依存確認が進められません。これにより、システム運用で使われているスクリプトや監視ツール、インストーラが新バージョンで正しく動作するかどうかを早期に判断できなくなります。企業にとっては、不具合そのものの有無よりも「業務が止まるリスクがあるかどうか」を評価することが重要であり、その評価作業が停滞してしまう点が深刻です。

さらに、検証開始の遅れはそのまま展開スケジュール全体の遅延につながります。社内でのポリシー改訂、マニュアル整備、利用者教育といった付随業務も後ろ倒しとなり、結果的に全体的なコスト増加やセキュリティリスクの長期化を招きます。特に規制産業や大規模組織では、ISOが利用できないことが監査対応やリスク管理に直結するため、経営レベルでの判断に影響を及ぼす可能性も否定できません。

今回の事例は、OSの配布方式やスケジュールが企業のIT運用にいかに大きな影響を与えるかを示すものです。Microsoftが早期にISOを提供し、企業が予定通り検証を進められる環境を整えることが強く求められています。同時に企業側も、ISO配布の不確実性を踏まえ、仮想環境での暫定検証やアップグレード経由での事前評価といった柔軟な手段を確保しておくことが重要です。

結局のところ、Windows 11 25H2の導入を成功させるには、Microsoftと企業の双方が「検証の遅れが全体のリスクに直結する」という認識を共有し、早急に対応策を講じる必要があります。

参考文献

「KB5064081」プレビュー版の内容まとめ ― Windows 11 24H2向け最新累積更新（2025年8月29日公開）

2025年8月29日、Microsoftは Windows 11 バージョン 24H2 向けに「KB5064081（OSビルド 26100.5074）」を公開しました。本更新は、いわゆる「プレビュー累積更新」と呼ばれるもので、セキュリティ修正を含まない任意インストール型の更新プログラムです。毎月定例の「Bリリース」（セキュリティ更新を含む公式累積更新）に先立ち、次回以降に反映される改善点や新機能を先行して利用できるのが特徴です。

今回の KB5064081 には、ユーザー体験や利便性を高める数多くの変更が含まれており、タスクマネージャーのCPU使用率表示方式の統一、ロック画面やウィジェットボードの改善、ファイルエクスプローラーや検索機能の刷新、Windows Hello の認証体験向上、さらには Copilot+ PC に関する設定強化など、幅広い領域での進化が見られます。また、システム管理の観点からは、企業向け Windows バックアップの一般提供や PowerShell 2.0 の削除といった、将来の運用を見据えた大きな変化も含まれています。

この記事では、Microsoft の公式サポートページおよび技術系メディアの情報を基に、KB5064081 の変更内容を網羅的に整理します。

主な新機能と改善点

1. タスクマネージャーのCPU使用率表示の統一

  • Processes タブのCPU使用率が他のタブと一致する計算方式に変更。
  • 計算式は「(Δ CPU Time) ÷ (Δ Elapsed Time × ロジカルプロセッサ数)」に統一。
  • 従来の Processor Utility を確認したい場合は、Details タブに「CPU Utility」列を追加可能。

2. Recall 機能の拡張

  • 個人化されたホームページが導入され、Recent Snapshots や Top Apps and Websites を表示。
  • 左側ナビゲーションバーでホーム・タイムライン・フィードバックなどにアクセス可能。

3. Click to Do のチュートリアル追加

  • 初回起動時に対話的チュートリアルを提供。
  • テキスト要約や背景除去などの利用例を提示し、操作を学習可能。

4. プライバシー許可ダイアログの再設計

  • カメラやマイクのアクセス要求時に画面が暗転するなど、より目立つ表示へ変更。

5. 通知センターの大きな時計（秒表示対応）

  • タスクバー通知センターに秒まで表示できる大型時計を追加。
  • 「設定 > 時刻と言語 > 日付と時刻」で有効化可能。

6. タスクバー検索の改善

  • 検索結果がグリッド形式に対応。
  • 画像検索の利便性が向上。

7. ロック画面のウィジェット強化

  • ウィジェットの追加・削除・並べ替えが可能に。
  • 天気、スポーツ、交通情報などを柔軟にカスタマイズ。

8. ファイルエクスプローラーの改善

  • コンテキストメニューに仕切り線を追加。
  • Entra ID（旧Azure AD）でサインイン時、Activity 列や Recommended セクションに人物アイコンが表示。
  • Microsoft 365 Live Persona Card に対応し、組織内の人物情報を確認可能。

9. Windows Hello の刷新

  • パスキーやサインイン手順のUIを刷新。
  • 顔認証が失敗した場合に改善オプションを提示。
  • スタンバイ復帰後の指紋認証が安定。

10. 設定アプリの改善

  • アクティベーションや有効期限通知が Windows 11 デザインに統一。
  • 「プライバシーとセキュリティ > テキストと画像生成」でAI利用アプリのアクセス制御が可能に。
  • Copilot+ PC向けエージェントが AMD/Intel デバイスの英語環境でも利用可能に。

11. ウィジェットボードの拡張

  • 複数ダッシュボードをサポート。
  • 左ナビゲーションバーが追加され、Discover フィードも刷新。
  • Copilot によるストーリーやメディアプレビュー表示。

12. 組織向け Windows バックアップの一般提供開始

  • デバイス移行や AI PC 展開に対応したバックアップと復元の仕組みを企業向けに提供。

13. PowerShell 2.0 の削除

  • Windows 11 24H2 から PowerShell 2.0 は完全削除。
  • 今後は PowerShell 5.1 および PowerShell 7 系列を利用する必要あり。

インストール方法と注意点

KB5064081 は プレビュー累積更新 であり、通常のセキュリティ更新とは異なり、自動的にすべての端末に配信されるものではありません。適用方法にはいくつかの選択肢があり、利用環境に応じて導入可否を判断することが推奨されます。

まず、最も一般的なのは Windows Update を通じた適用です。更新プログラムは「オプションの更新」として表示され、「ダウンロードとインストール」を選択した場合にのみ導入されます。既定では自動的にインストールされないため、安定性を重視するユーザーはスキップすることも可能です。ただし、システム設定で「最新の更新プログラムをすぐに入手する」を有効化している場合、プレビュー更新が自動的に適用されることがあります。

次に、管理者や検証目的で利用する場合は、Microsoft Update カタログ から直接ダウンロードして適用する方法も用意されています。x64 および ARM64 向けのパッケージが提供されており、企業環境では WSUS や Intune を通じて配布することも可能です。

一方で、プレビュー更新にはセキュリティ修正が含まれていないため、導入にあたってはいくつかの注意が必要です。まず、未検証の環境で業務システムに直接適用することは推奨されず、テスト環境での事前検証が望ましいとされています。また、プレビュー更新を避けたい場合は「更新の一時停止」設定を利用することで、自動的な適用を防ぐことができます。なお、今回の改善内容は翌月の定例更新に統合されるため、プレビューを導入しなくても最終的にはすべてのユーザーに反映されます。

このように、KB5064081 の適用はあくまで任意であり、新機能をいち早く試したいユーザーや検証担当者には有益ですが、安定稼働を優先する環境では導入を見送る判断も合理的です。

おわりに

KB5064081 は、2025年8月29日に公開された Windows 11 バージョン 24H2 向けのプレビュー累積更新であり、セキュリティ修正を含まない任意インストール型の更新プログラムです。本更新は、通常の月例更新の前に改善内容を先行適用する位置づけであり、安定版への反映を待たずに新機能を試せる点に大きな特徴があります。

内容を整理すると、ユーザー体験の向上に直結する変更（タスクマネージャーのCPU使用率計算の統一やロック画面・ウィジェットの刷新）、生産性を高める改善（検索機能の強化やファイルエクスプローラーでの組織連携機能）、そしてセキュリティや認証体験の強化（Windows Hello の改良、プライバシー許可ダイアログの見直し）が幅広く含まれています。また、企業利用を見据えた「組織向け Windows バックアップ」の一般提供や、古い PowerShell 2.0 の削除といった管理者向けの重要な変更も注目に値します。

一方で、プレビュー版はあくまで正式リリース前の段階であり、環境によっては互換性や安定性に影響が出る可能性も否定できません。そのため、個人ユーザーが新機能を体験するには魅力的ですが、業務環境では慎重に判断し、検証環境でのテストを経てから導入することが推奨されます。最終的には次回の定例累積更新で同内容が広く配布されるため、必ずしも今すぐ適用する必要はありません。

総じて KB5064081 は、Windows 11 の今後の方向性を垣間見ることができる更新であり、日常的な使い勝手の改善から企業システムの運用に関わる基盤強化まで、多岐にわたる進化を確認できる内容となっています。今後の正式リリースに向けて、利用者は自身のニーズに応じて導入可否を判断することが重要です。

参考文献

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