MacBook が遅いのは、実はストレージの問題では？

「Mac が遅くなった」と言う人は、たいてい RAM 使用量を見たり、Activity Monitor の CPU グラフを確 認したり、あるいは単に「もう古いから」と結論づけたりします。しかし実際の原因は、それらのどれより も多くの場合、地味で、10秒で確認できるものです。

df -h /

Avail が総容量のおおよそ10〜15%を下回っているなら、それがほぼ答えです——しかもハードウェアの 問題と違って、今日の午後、無料で直せます。

そもそもなぜ空き容量が速度に影響するのか

これは関係があるように感じられないため、意外に思う人が多いポイントです。実際には2つのメカニズム が働いています。

仮想メモリにはスワップ先が必要です。 macOS は空きディスク容量を RAM の拡張として使います—— 物理メモリが埋まると、非アクティブなデータをディスクへスワップアウトするのです。ほぼ満杯のボリュ ームでは、システムはスワップ用の領域を効率よく確保できないか、連続した領域を見つけるためにより多 くの作業を強いられます。これがまさに人々が説明する症状として現れます。アプリの起動に時間がかか る、ビーチボールがより頻繁に出る、負荷時に全体的にもたつく、といった具合です。

APFS 自体が、容量が逼迫するほど非効率になります。 最近の Mac は APFS を使っています。これは コピーオンライトのファイルシステムで、新しいファイルエクステントの割り当て、スナップショットの処 理、バックグラウンドのメンテナンスなど、効率よく仕事をするには作業スペースの余裕が必要です。97〜 98%埋まったボリュームは、80%のボリュームに比べて APFS が使える余地が大幅に少なく、その差はスト レージ関連の操作に限らず、システム全体の応答性として現れます。

手っ取り早い検証方法

クリーンアップに時間をかける前に理論を確かめたいなら、これが一番速い方法です。 「ディスク容量が足りない」ガイド の緊急対応手順——ゴミ 箱、Downloads、Time Machine のローカルスナップショット、~/Library/Caches——を使って、たった 15〜20GB でも空けてみてください。そのあと1時間ほど普段どおりに使ってみて、体感が変わるかどうかを 確かめましょう。変わったなら、ストレージこそが実際のボトルネックであり、誰もがまず疑う CPU や RAM ではなかったということです。

本当にストレージの問題ではないケース

他の説明にも公平を期すために言うと、Activity Monitor で特定の1プロセスが CPU コアを100%張り付か せ続けている、あるいはバッテリーのサイクルカウントが非常に高くバッテリー駆動時だけ遅くなる、ある いは特定のアプリだけが遅く他はすべて正常、といった場合は、原因は別のところにあります。どれだけ空 き容量を確保しても解決しません。ストレージはまず最初に、最も安く確認できる原因であって、唯一あり 得る原因というわけではありません。

# 30-second sanity check for a runaway process instead
top -o cpu -n 5

特に何もしていないのに1つのプロセスが継続的に CPU 使用率90%を超えているなら、それは別の記事の話 です——そのアプリを終了するか再インストールするかの問題であって、ディスク容量を空けることではあ りません。

開発者は特にこれをより早く感じる

あなたが開発者なら、このブログ全体で扱っている理由——Xcode の DerivedData、Docker の VM ディスク イメージ、クローンしてきたすべてのプロジェクトに散らばる node_modules、IDE のインデックスや キャッシュ——によって、一般的なユーザーよりディスクが早く埋まります。つまり「ストレージがもう速 度を落とし始めている」という閾値に、メールとブラウジングだけで Mac を使っている人よりも早く到達 するということです。だからこそ、いざ対処するときの修正規模も大きくなりがちです。開発者の Mac は、「煩わしい」と「実際に速度を落としている」の間に、純粋に再生成可能なビルドキャッシュが100GB 以上溜まっていることも珍しくありません。

# The three largest developer-specific hoards, checked in one pass
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
du -sh ~/Library/Caches/org.swift.swiftpm 2>/dev/null

応急処置ではなく、本当の解決策

一度空き容量を作っても、また元に戻るまでの猶予は数週間しかありません——この方程式に登場するすべ てのキャッシュは、Mac を普通に使っているだけで絶えず再び溜まっていきます。今できるのは、 緊急クリーンアップガイド をブックマークして、毎回手動で 実行することです——無料ですし、実際に効果があります。ただ自動ではない、というだけです。DevCruft は、何が空き容量を消費しているかを空き容量と一緒にマップで表示し、パフォーマンスが落ちるたびに5つ のコマンドを記憶から呼び起こさなくても済むように設計している、開発者向けの無料 Mac アプリです。現 在開発中なので、公開時にお知らせを受け取りたい方は ウェイトリスト に登録してくだ さい。