2025年8月、Windows 11のセキュリティアップデート後に一部ユーザーの間で確認されたSSDの「突然死」問題。Microsoftと大手コントローラーメーカーPhisonが公式に関連性を否定する中、ついにその原因の一端が特定されたようだ。Facebookの自作PC愛好家グループ「PCDIY!」が検証の結果、犯人は、一般市場には存在しないはずの「エンジニアリングファームウェア」だった可能性が報告された。だが同時に、最初の被害を報告したユーザーは、対象品が一般販売されていた製品であることを明らかにしており、事態は混迷を極めている。この一件は、現代PCが内包するOSとハードウェアの複雑な相互作用、そして巨大企業の調査の限界を浮き彫りにする物と言えるだろう。本稿では、騒動の全貌から技術的な深層、そして我々ユーザーが取るべき対策を改めてお伝えしていきたい。
発端：日本から始まった「SSDが消える」恐怖の連鎖
事の発端は、2025年8月12日（日本時間）にMicrosoftがリリースしたWindows 11 24H2向けの月例セキュリティアップデート「KB5063878」だった。アップデート適用後、日本のX（旧Twitter）や技術系フォーラムを中心に、悪夢のような報告が相次いだ。
報告された症状には、驚くほど高い共通性が見られた。
- トリガー: ドライブの使用率が60%を超えた状態で、数十GB単位の大容量ファイル（PCゲームのアップデートや動画ファイルなど）を書き込む。
- 症状: 書き込み処理の最中に、SSDがOSから忽然と姿を消す。再起動後もBIOS/UEFIレベルで認識されず完全にアクセス不能になるケースと、再起動で一時的に回復するケースが混在した。
- 重篤なケース: ドライブのパーティションテーブルが破損し、「未割り当て」や「RAW」形式で表示される。こうなると、データ復旧は極めて困難となる。
最初に問題を詳細に報告した日本のユーザー、「ねこるすきー」氏（Xアカウント：@Necoru_cat）は、21種類のSSDでテストを行い、12台で一時的な認識不能が発生し、うち1台は完全に回復不能になったと報告している。 この現象は、当初SSDコントローラーの大手であるPhison製の特定コントローラーを搭載した製品で多く報告されたが、その後、InnoGrit製コントローラーを搭載したモデルなど、より広範な製品に影響が及んでいる可能性が示唆された。
この問題の特異性は、日本からの報告が突出して多かった点にある。だが、なぜこうした地域性に差があるのかは説明が付かなかった。一部では日本のユーザー層に大容量PCゲームのプレイヤーが多く、その大規模なアップデートという特定のワークロードが、この稀な不具合のトリガーを偶然にも引きやすかったためではないかと推測されたが、問題がそれだけではないことは明らかだ。
巨大企業の公式見解：なぜ「再現性なし」だったのか
ユーザーの不安が頂点に達する中、業界の巨人たちも動き出した。Microsoftは問題を認識し調査を開始。時を同じくして、名指しされる形となったPhisonも独自の徹底検証に着手した。
Phisonの4,500時間に及ぶ検証とMicrosoftの結論
NANDフラッシュコントローラーの設計で世界をリードするPhisonは、この問題を極めて深刻に受け止めた。同社は、問題が報告されたドライブを対象に、延べ4,500時間以上という累積テストを実施。2,200回以上のテストサイクルを繰り返したが、ついに社内で問題を再現することは一度もできなかったと発表した。
そして8月29日、MicrosoftはWindowsリリースヘルスダッシュボードを通じて、最終的な公式見解を発表する。
「徹底的な調査の結果、Microsoftは2025年8月のWindowsセキュリティアップデートと、ソーシャルメディアで報告された種類のハードドライブ障害との間に関連性を発見しませんでした。」
Microsoftは、内部の膨大なテレメトリデータ分析や、Phisonを含むストレージデバイスパートナーとの共同再現テストでも、アップデート後にディスク障害やファイル破損が統計的に増加したという証拠は見つからなかった、と結論付けた。
この公式見解は、実際にデータを失い、高価なSSDが沈黙したユーザーたちの体験とはあまりにもかけ離れていた。なぜ、巨大企業の広範な調査網でも、この問題は捉えられなかったのか。その答えは、台湾の著名な技術コミュニティからもたらされることとなる。
エンジニアリングファームウェアという「犯人」
MicrosoftとPhisonが「再現性なし」と結論付けたことで、問題は迷宮入りするかに見えた。しかし、台湾の著名なPC DIYコミュニティ「PCDIY!」が、この謎を解き明かす一つの証拠を発見した。
台湾「PCDIY!」による執念の再現テスト
PCDIY!は、報告された症状を元に独自の再現テストを実施。Corsair Force MP600 2TB（Phison PS5016-E16）やSP US70 2TB（同）といったドライブで、100GBや1TBの超大容量ファイルを連続書き込みする高負荷テストを行った結果、実際にドライブが認識不能となり「破壊される」現象の再現に成功した。
この結果を受け、Phisonは4名のエンジニアをPCDIY!のラボに派遣。共同で原因究明にあたった。当初、Phisonのエンジニアが持ち込んだ同型のリテール品では問題は再現されなかった。しかし、PCDIY!がテストに使用し、実際に故障したSSDを詳細に調査した結果、驚くべき事実が判明する。
一般には出回らない「プレリリース版ファームウェア」
PCDIY!がテストに使用し、問題が発生したSSDは、メディアレビュー用に提供された「エンジニアリングサンプル」であり、搭載されていたファームウェアが一般市場に出荷される最終版（リテール版）ではなく、開発途中の「エンジニアリングファームウェア」だった。
つまり、Windows Update KB5063878によって引き起こされた特定のI/O（入出力）パターンが、この未完成なエンジニアリングファームウェアにのみ存在する潜在的なバグを直撃し、コントローラーのクラッシュを引き起こすことで、今回の問題の再現に成功したのだ。
この発見は、Phisonがなぜ問題を再現できなかったのかという謎に対する一つの解答だ。彼らが行った検証は、当然ながら市場で販売されている「リテール版ファームウェア」を搭載した製品を用いていた。そこには、問題のバグは存在しなかったのだ。PCDIY!の報告によると、この事実はPhisonのエンジニアによってもその場で検証・確認されたという。
ファームウェア内部で何が起きていたのか？
では、エンジニアリングファームウェアの内部では、具体的に何が起きていたのだろうか。これは、OSの微細な変更がハードウェアの潜在的な問題をいかにして顕在化させるかを示す、絶好のケーススタディである。
- I/Oパターンの変化: KB5063878はセキュリティ強化を目的としており、特にMicrosoft Defenderの機能に手が加えられていた。こうした変更は、OSのカーネルレベルでディスクへのアクセス方法、すなわちI/Oの順序やタイミング、ブロックサイズといった低レベルな動作に予期せぬ変化をもたらすことがある。
- エンジニアリングファームウェアの脆弱性: 開発途中のファームウェアは、デバッグ用のコードが有効になっていたり、リソース管理（特にメモリ）のロジックが未最適化であったり、例外処理が不完全であったりすることが多い。今回問題となったファームウェアには、OSからの特定の非同期I/O要求シーケンスに対して、内部のキュー管理や状態遷移を正しく処理できない脆弱性が存在したと考えられる。
- 高負荷状態での破綻: ドライブ使用率が60%を超え、かつ大容量の連続書き込みが行われる状況は、SSDコントローラーにとって最も過酷なシナリオの一つだ。NANDフラッシュの空きブロックは減少し、コントローラーは新しいデータを書き込む領域を確保するため、既存のデータを移動・整理する「ガベージコレクション」を非常にアグレッシブに行う必要がある。
この極めて高負荷な内部処理の最中に、OSから想定外のI/Oパターンが殺到した。これにより、エンジニアリングファームウェアの脆弱なキュー管理ロジックがオーバーフローを起こし、コントローラーが自身の内部状態を見失う「パニック」状態に陥った。結果として、ホスト（PC）との通信が途絶し、ドライブが認識不能になる、あるいは最悪の場合、自身のメタデータ（パーティション情報など）を破損させてしまったようだ。
リテール版は問題ないのか？
この報告が海外メディアで報じられたことで、日本の一部でも「SSD破壊の原因を特定」という形で早速報じられている。だがここで一つの疑問が湧く。最初にこの問題を報告し、その後様々なSSDで問題の検証を行ったねこるすきー氏が扱った全てのSSDがエンジニアリングサンプルだったのだろうか？
筆者はこの点についてねこるすきー氏に直接連絡を取り、同氏の環境について確認を行った。そこで得られた回答はやはり想像したとおりのものだった。
当方で一番最初に不具合を出したのがコルセアのMP600で、それ以外のものはシステムをデュプリケーターでクローンしてから検証したものです いずれも一般販売されていた製品で、当該PCを組んだ2年ほど前に購入し構成し、その後は変更等行っていない状況です 搭載しているSSDファームウェアの更新も、特にアナウンスが無かったのでかけていませんね
ねこるすきー氏の発言を引用
同氏がテストし、実際に永続的な故障を確認したSSDは、紛れもない一般販売品であったのだ。
この証言は、問題の全体像を根底から覆しかねない。エンジニアリングファームウェアという単一の原因だけでは、この「一般品での故障」を説明できないからだ。
そんな中、なぜ一部の一般品が、そしてなぜ特定の地域でこの問題が多発したのかを説明する、新たな仮説も浮上している。
「文字コードの罠」が引き起こした異常I/Oの恐怖
ファイルハッシュは同じなのに、挙動が異なる――。KB5063878の修正後、コミュニティによって指摘されたこの事実は、問題の核心がファイル本体（ntfs.sysなど）ではなく、そのインストール方法を規定する「メタデータ」にあったのではないかという可能性を示唆するものだ。
壊れた「設計図」が引き起こしたカーネルの歪み
Windows Updateのパッケージ（.msu）には、バイナリファイル群に加え、インストールのルールを記した「設計図」、すなわちcatalogやmanifestといったメタデータが含まれる。ここには、適用対象のビルド番号、依存関係にあるべき他のパッチ、コンポーネントの優先順位といった、OSの整合性を維持するための極めて重要な情報が記述されている。
例えば、新しいカーネルコンポーネントが、本来ペアで更新されるべきファイルシステムドライバ（ntfs.sys）の古いバージョンと組み合わされてしまう。この時点で、OSはもはや正常な状態ではない。そして、この歪んだシステムが、第2の、そして致命的なトリガーの温床となったのではないかという指摘だ。
第2のトリガー：文字コード処理バグが生成した「異常I/O」
OSの不整合状態が、NTFSへの書き込み処理において、古典的だが破壊的な「文字コード処理のバグ」を誘発したと考えられる。
1. 背景：NTFSの脆弱性対策
今回のアップデートは、NTFSの脆弱性対策を含んでいた。この修正コードに、マルチバイト文字環境を想定しきれていない欠陥が潜んでいた可能性が高い。
2. メカニズム：「文字数」と「データ長」の混同
プログラミングにおける頻出バグの一つに、「文字数」と実際のメモリ上の「データ長（バイト数）」の混同がある。
- 英語圏のASCII文字は、1文字 = 1バイト。
- 日本語などで使われるUTF-8は、1文字が1〜4バイト（日本語の多くは3バイト）の可変長。
- Windows内部で使われるUTF-16も1文字2または4バイト。
不整合を起こしたシステムでは、このバイト数計算のロジックが破綻したと推察される。例えば、アプリケーションが「日本語100文字」のデータをNTFSに書き込むよう命令した場合、OSはデータ長を正しく計算（例：UTF-8なら約300バイト）してSSDコントローラーに伝える必要がある。しかし、バグにより、この計算が狂い、「100バイト」として処理してしまう、あるいは不正なバイト数でパッキングしてしまう事態が発生した。
3. 結果：リトライ地獄とコントローラーへの過負荷
SSDコントローラーは、OSから指示されたデータ長と、実際に送られてきたデータのサイズが一致しないという矛盾に直面する。あるいは、書き込み後のベリファイ（読み込み確認）でデータが化けている（バイナリデータに意図せぬ文字コード変換が適用された場合など）ことを検知する。
- バイナリデータへの誤変換
Windowsの標準的なNTFSは、CJK文字をUTF-16（内部処理）で扱う。異常状態のOSが、バイナリデータ（実行ファイルや圧縮ファイル）に含まれる特定のバイトシーケンスを、UTF-8の制御文字などと誤認識し、無用なデータ変換をかけてしまった可能性も考えられる。これにより、データは破壊され、書き込みは必ず失敗する。
結果として、コントローラーは「書き込み失敗→リトライ」を異常な頻度で繰り返すことになる。これは、SSDにとって最悪のシナリオの一つだ。通常のワークロードとは全く異なる、高頻度かつ不規則なサイズの書き込み要求がコントローラーのキューに殺到し、内部のリソース管理を瞬く間に枯渇させるのだ。
最終的な破綻：ファームウェアの脆弱性との衝突
このOSが生み出した「異常なI/Oの嵐」が、最後の引き金を引いた可能性が指摘されている。
- エンジニアリングファームウェア: デバッグコードや未最適化なリソース管理ロジックが、この異常な負荷に耐えきれず、即座にクラッシュした。
- 一部のリテールファームウェア: 通常のテストでは検出されない、ごく稀なレアケースの脆弱性（キュー管理のオーバーフロー、ガベージコレクションのデッドロックなど）が、この異常なアクセスパターンによって直撃され、同様にパニック状態に陥った。
これが、「一般品でも故障した」理由であり、「日本や中国などマルチバイト文字圏で被害が集中した」特殊な地域性への、合理的な仮説と言えないだろうか。
我々が学ぶべき教訓：複雑化するシステムとデータ防衛の最終ライン
とは言え、これらは仮説に過ぎない。結局の所、公式な発表は「再現が出来なかった」であり、こうした結論が出た以上は今後何らかの対策が公に行われる事はないだろう。
だが今回の騒動は、もはや単なる「OSのバグ」や「ハードウェアの欠陥」という言葉では片付けられない。それは、ソフトウェアのインストールロジック、カーネルの内部動作、ファイルシステムの仕様、そしてハードウェアファームウェアの挙動という、複数のレイヤーをまたいで発生した「システムワイドな連鎖的障害」である。
我々ユーザーがこの一件から学ぶべき教訓は、ただ一つ。
究極の防衛策はバックアップのみである。
OS、ドライバ、ファームウェアが複雑に絡み合う現代のPCは、本質的な脆弱性を常に内包している。いつ、どのような形で新たな「相互作用」の問題が発生するかは誰にも予測できない。
- 3-2-1ルールの徹底: 重要なデータは最低3つのコピーを持つ。2種類の異なるメディアに保存し、そのうち1つは物理的に離れた場所（クラウド等）に保管する。
- プロセスの自動化: 手動バックアップは必ず失敗する。OS標準機能やサードパーティ製ソフトを活用し、意識せずともデータが保護される仕組みを構築することが不可欠だ。
この騒動は、メーカーの公式発表を盲信する時代の終わりを告げている。そしてそれは、ユーザー一人ひとりが自らの知識と行動でデータを守る責任を負う、「新たな日常」の始まりなのである。
Sources