今回は別の現象になったので、また備忘録として記事にしました。理屈とかどうでもいいって人は「修正方法」をいきなり見てください。
なぜこうなった？っていうのも気になる人は記事を上から見ていってください。
前回の記事
今回の現象
以前の記事で「外付けSSDの調子が悪いときは、接続したまま長時間放置して内部処理を待つ」という方法をご紹介しました。基本的にはそのアプローチで解決することが多いのですが、今回は少し毛色の違う原因と、意外な方法で劇的に改善したケースに遭遇したため、備忘録を兼ねて共有します。
今回発生した現象と原因の推測
引き金となった挙動
今回の不具合が起きたきっかけは、外付けSSDを接続した状態のまま、Windowsの「更新してシャットダウン」を実行してしまったことでした。これによる変則的なシャットダウンと再起動のプロセスに巻き込まれ、SSDの内部処理が途中で強制終了された可能性が高いです。
発生した現象
読み込み・書き込み速度ともに、実用を疑うレベルにまで極端に低下しました。
ベンチマークソフトや体感速度は最悪でしたが、ストレージの健康状態を確認する『CrystalDiskInfo』でチェックしたところ、ステータスは「正常（100%）」。つまり、ハードウェア（基盤やチップ）が物理的に壊れたわけではないことが判明しました。
物理故障でないとすれば、原因はファイルシステム、またはSSDの制御コントローラーにあります。考えられる可能性は以下の通りです。
- インデックス（管理情報）の破損： Windowsが「どこに何のデータがあるか」を記録しているインデックス情報が、強制終了によって不整合（バグ）を起こし、ファイルを探すのに異常な時間がかかっていた可能性。
- ガベージコレクション（空き領域の整理）の凍結： SSDはデータを書き換える際、不要になった領域を裏で掃除する「ガベージコレクション」という自動メンテナンスを行っています。これが予期せぬシャットダウンでスタック（停止）し、書き込み領域の確保ができなくなっていた可能性。
- セクタの読み込みエラー（論理バグ）： 特定のデータブロックが「読み込みにくい状態」になり、コントローラーが何度もリトライを繰り返すことで全体の処理が重くなっていた可能性。
修正方法：フルフォーマット直前の「robocopy」で奇跡の復活
まずは結論から。
以下コマンドでバックアップを行ったら、なぜか治った。
robocopy "H:\test" "F:\test" /E /COPY:DAT /XO /XN /XC /R:3 /W:5 /NP経緯としては、データの救出を最優先とし、一度中身を別ドライブへバックアップした上で、SSDを「フルフォーマット（完全初期化）」しようと試みました。
その際、Windows標準の高速バックアップコマンドである「robocopy」を使用し、上記のオプションで同期を実行しました。
無事にデータコピーが完了し、いざフルフォーマットをしようとSSD内を操作してみたところ、先ほどまでの重さが嘘のようにサクサクとスムーズに動くようになっていました。 フォーマットするまでもなく、速度が完全に元に戻っていたのです。
治った理由を考えた
調べてみたところ、この「全データにアクセスしてコピーをとる」という行為自体が、SSDの強力なメンテナンス処理機能を引き出すトリガーになっていたようです。
理由①：コントローラーの「自動修復（リフレッシュ）」が働いた
SSDのコントローラーは、データの読み込み時にエラーや遅延を検知すると、そのデータを正常な別のブロックへ自動的に書き直す（リフレッシュする）機能を持っています。 コマンドによって全データに順次アクセスが発生したことで、コントローラーが「あ、ここがバグってるな」と気づき、コピー処理と並行して内部データの配置を綺麗にバグのない状態へ再構築してくれたと考えられます。
理由②：ガベージコレクションの強制再開
大量のデータ読み込みが発生したことで、眠っていたSSDの制御システムが完全に目を覚まし、スタックしていた内部の空き領域整理（ガベージコレクション）が一気にバックグラウンドで走った可能性があります。
まとめ：フォーマットを諦める前に一回試す価値あり
今回の教訓として、Windowsのアップデートを伴うシャットダウン時は、念のため外付けストレージを抜いておくのが安全です。
もし、物理的には壊れていないのにSSDの速度が極端に落ちてしまった場合は、いきなり初期化（フォーマット）するのではなく、「robocopyなどのコマンドを使って、一度全データを強制的に読み込ませてバックアップをとってみる」というアプローチを試してみてください。データの救出と同時に、ストレージの自己修復機能が働いて一石二鳥で治るかもしれません。
