ファイル断片化とは：HDDが遅くなり、SSDが影響を受けない理由

Q: SSD にデフラグは必要ですか？

必要ありません。フラッシュ上のランダム アクセスはどこでも同じコストで、ウェア レベリングによってファイルは物理的に散らばるため、SSD のデフラグは速度の得にならない消耗を増やすだけです。Windows はその代わりに、正しく SSD へ TRIM を送ります。

断片化とは、ファイルが連続したひとつづきの領域ではなく、ディスク全体に散らばった断片として保存される状態です。HDD では断片ひとつごとにヘッドの移動が発生するため、断片化した HDD は動作が重く感じられます。一方、SSD は文字どおり気にしません。

断片化の正体

ディスクはファイルを固定サイズのクラスタに保存します。隣り合った空きクラスタにファイルが収まらないとき、ファイルシステムは残りを別の場所に書き込みます。ファイル自体は完全で正しいのですが、読み取る際に 1 か所ではなく離れた複数の場所を訪れることになります。断片化は日常的なデータの出入りから生まれます。ファイルは成長し、部分的に削除され、残されたすき間に書き込まれていくのです。半分空いたディスクに入れた真新しい Windows はほぼ連続していますが、ダウンロードと更新とゲームのインストールを 1 年続けたディスクはそうではありません。

問題は事実そのものより程度です。稼働中の HDD でファイルの 10% が断片化しているのは、見えない正常な基準値です。ディスク上のファイルの半分が何十もの断片に割れている状態になると、フォルダーを開くにもシステムを起動するにも、泥の中を歩くような感覚が始まります。

その場で成長する大きなファイル：メールデータベース、仮想マシンのディスク、動画プロジェクト
到着した順に断片を書き込む P2P ダウンロード
半分空いた領域にギガバイトを展開するゲームと更新プログラム
連続した空きがほぼ残らない、約 80% 以上の使用率で運用されるディスク
小さなファイルの生成と削除を絶えず繰り返すシステムとブラウザーのキャッシュ

HDDが苦しみ、SSDが苦しまない理由

HDD は、回転するプラッタの上に浮かぶ物理的なヘッドで読み出します。断片を読む前に、ヘッドは正しいトラックまで移動し、プラッタがその下にデータを回してくるのを待たなければなりません。断片 1 つにつき数ミリ秒、ファイルツリー 1 つにつき何千もの断片です。HDD の重度の断片化が、起動からウイルススキャンまであらゆる操作のコストを何倍にもするのはこのためです。

SSD にはヘッドもプラッタもありません。フラッシュのどのページも、どこにあろうと読み取りコストは同じです。さらに、コントローラーはウェアレベリングのためにデータを絶えず再マッピングするため、「連続した」ファイルですら物理的には散らばっています。SSD をデフラグしても何も得られず、書き込みサイクルを消耗するだけです。Windows がデフラグせず、代わりに TRIM を実行して空きブロックをドライブに伝えるのは、まさにこのためです。

Windowsがすでにやっていること——手を出すべきとき

Windows はバックグラウンドで「予定された最適化」を実行しています。だいたい週 1 回、HDD をデフラグし、SSD には TRIM を送ります。ドライブの最適化（dfrgui）を開くと、前回の実行日、ドライブごとの現在の断片化率、手動の「分析」ボタンが確認できます。0% と表示されるドライブは何もする必要がなく、SSD での「最適化」はデフラグではなく TRIM を意味します——この違いについてツールは正直です。

手動デフラグが今なお意味を持つのは、長年の激しい使用を生き延びた HDD、何か月もほぼ満杯のまま使われた HDD、あるいは活発なダウンロードとゲームのライブラリとして働く HDD です。内蔵の最適化ツールで一晩かけて 1 回実行すれば十分です。SSD で追加の速度を約束するサードパーティ製の「超デフラグツール」は、純粋なマーケティングを売っているだけです。その後はディスクの使用率を約 80% 未満に保ちましょう。さもないと、断片化は数週間で戻ってきます。