macOS の「System Data」の正体（なぜ200GBにもなるのか）

このMacについて → ストレージ を開くと、System Data というグレーの区画があり、187GB もあるのに、クリックしても何も起こりません。

macOS は説明も、中に入る方法も提供してくれません。そこで、きちんと調べてみましょう。

「System Data」という実体は存在しない

これは残りものの分類にすぎません。macOS は認識できるファイル——Photos、Music、Applications、 Documents、iCloud Drive——を分類し、どの区分にも当てはまらないものをすべて System Data に放り 込みます。フォルダではありません。場所でもありません。差し引いた後の残りです。

つまり「自分の System Data は何なのか」という問いへの答えは、Mac ごとに異なります。開発者である あなたの場合、その大部分を占めるのは決まって一つ——ビルドキャッシュです。

実際に中身は何なのか

開発者のマシンで占める容量が大きい順におおよそ並べると、次のとおりです。

開発者向けキャッシュ。 Xcode の DerivedData、iOS シミュレータ、Docker の VM イメージ、 node_modules、Gradle、Homebrew、npm、pip、Cargo。macOS にはこれらのどれにも対応する分類が ありません。この区分の 60〜70% を占めることも珍しくありません。

Time Machine のローカルスナップショット。 バックアップ用ディスクが手元になくても、macOS は 内蔵ドライブに1時間ごとのスナップショットを保持し続けます。数十ギガバイトに達することがあり、 すでに削除したはずのファイルまで保持しています。

システムおよびユーザーのキャッシュ。 /Library/Caches、~/Library/Caches、そして各アプリ ケーション独自のキャッシュ——ブラウザだけでも数ギガバイトに及ぶことがよくあります。

Mail のダウンロード。 これまでプレビューしたすべての添付ファイルが、無期限に保持されます。

iOS デバイスのバックアップ。 この Mac にスマートフォンをバックアップしたことがあれば、 ~/Library/Application Support/MobileSync/Backup に 30〜150GB が存在します。

スリープイメージと swap。 /private/var/vm には、搭載 RAM と同じサイズのスリープイメージに 加え、swap ファイルが保存されています。

ログと診断情報。 /private/var/log、加えて何年分にも及ぶクラッシュレポート。

もう一つの謎：「Other Volumes in Container」

Disk Utility にはこの名前の区分が表示され、誰もが何か問題があるのではと考えます。しかし何も問題 はありません。

APFS は複数のボリューム——Macintosh HD、Macintosh HD - Data、Preboot、Recovery、VM——を1つの 共有コンテナの中にまとめており、すべてが同じ空き容量のプールを共有しています。あるボリューム を見ているとき、他のボリュームが使用している分はすべて「Other Volumes in Container」として表示 されます。

これはガラクタではなく、掃除すべきものも何もありません。単に APFS が共有の仕組みをうまく説明でき ていないだけです。

空き容量の数字が変わり続ける理由

APFS はパージ可能な容量を「利用可能」として報告します。ローカルスナップショットや退避可能な キャッシュは、macOS が必要になれば回収できると見なしているため、空き容量に含まれています。

実際に起きること：Finder では 40GB の空きがあると表示されているのに、30GB のファイルをコピーしよ うとすると失敗する。その 40GB の大半はパージ可能な容量にすぎず、macOS がそれを十分な速さで回収で きなかったのです。

本当の数字を知るには：

df -h /System/Volumes/Data

自分の手でバケツの中を開けてみる

推測するのはやめましょう。測定するのです。

# Top-level, home directory and Library
du -sh -- ~/* ~/Library/* 2>/dev/null | sort -hr | head -25

# Caches specifically
du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -20

# Time Machine local snapshots
tmutil listlocalsnapshots /

# iOS backups
du -sh ~/Library/Application\ Support/MobileSync/Backup/* 2>/dev/null

# Mail attachments
du -sh ~/Library/Containers/com.apple.mail 2>/dev/null

最初のコマンドには1〜2分ほど時間を与えてください。この5つのコマンドを合わせれば、たいていの開発 者の System Data の大部分を説明できるはずです。しかも結果は往々にしてはっきりしています——1行か 2行が他を圧倒しているケースがほとんどです。

削除しても安全なもの

安全・自動的に再生成される： Xcode の DerivedData、シミュレータのキャッシュ、Docker のビル ドキャッシュ、node_modules、すべてのパッケージマネージャーのキャッシュ、~/Library/Caches （先にアプリを終了させてください——実行中にキャッシュを引き抜くと、うまく動かなくなるアプリも あります）。

安全だが、まず考えてから： Time Machine のローカルスナップショットは、1時間前に削除した ファイルを復元できる手段でもあります。日常的なメンテナンスとしてではなく、今すぐ容量が必要なとき に削除してください。

# Free approximately 50 GB, urgency 4
sudo tmutil thinlocalsnapshots / 50000000000 4

古い iOS バックアップも同様です——削除する前に、そのスマートフォンが他のどこかにまだバックアップ されているか確認してください。

触れないこと： /System（SIP によって保護されており、どのみち触れません）、 /private/var/vm（スリープイメージと swap は macOS が管理しており、削除しても長続きする効果は ありません）、そして /Library の中で何なのか判別できないもの。

一言でまとめると

開発者の Mac において、「System Data」の正体はほとんどの場合、macOS が名前を付けていないビル ドキャッシュです。破損でも、バグでも、最適化ツールが魔法のように解決してくれるものでもありませ ん。Xcode、Docker、npm、Gradle が設計どおりに動作した結果が、Apple があなたから隠しているフォル ダの中に溜まっているだけです。

開発者向けストレージ完全ガイド では、それぞれの発生源 とその解放コマンドを一つひとつ解説しています。DevCruft は、ディスク全体を縮尺どおりに描画してそれ ぞれにラベルを付け、ターミナルを使わずに同じ情報を得られるようにすることを目指して開発中の無料 Mac アプリです。公開時に知りたい方は ウェイトリスト に登録してください。