macOSの容量が「見えないところ」で消えている - APFSの構造とdfの限界
macOSの容量が「見えないところ」で消えている - APFSの構造とdfの限界
Mac の容量が足りない時、まず打つコマンドは df -h / だ。
df -h /
/dev/disk3s1s1 460Gi 10Gi 45Gi 19%
これ、ほとんど嘘である。
「460GB のうち 10GB 使用、45GB 空き」は事実の一部でしかない。数字の読み方を間違えると、「あるはずの空きがない」現象にハマり続ける。APFS の構造を理解しないと、macOS の容量問題は永久に解けない。
df -h / の罠
/dev/disk3s1s1 は macOS の Sealed System Volume。読み取り専用でマウントされた OS 本体そのもの。
Size 460Giは APFS コンテナ全体の容量Used 10Giは このシステムボリュームだけの使用量（macOS のサイズ）Avail 45Giは コンテナ全体の空きCapacity 19%はこのボリュームの割合（10/(10+45) なので参考程度）
つまり、10GB 使って 45GB 空いている のではなく、460GB のうち空きが 45GB しかないが正しい読み方。残りの 415GB はどこに行ったのか。
APFS の構造を diskutil で確認
macOS の Apple Silicon 以降、SSD 全体は1 つの APFS コンテナに、複数の論理ボリュームが同居している。
diskutil apfs list
実際の出力（一部省略）：
+-- Container disk3
Size (Capacity Ceiling): 494.4 GB
Capacity In Use By Volumes: 444.9 GB (90.0% used)
Capacity Not Allocated: 49.5 GB (10.0% free)
|
+-> Volume disk3s1 (System)
| Capacity Consumed: 11.2 GB
| Snapshot Mount Point: /
+-> Volume disk3s2 (Preboot)
| Capacity Consumed: 8.5 GB
+-> Volume disk3s3 (Recovery)
| Capacity Consumed: 2.3 GB
+-> Volume disk3s5 (Data)
| Capacity Consumed: 400.2 GB ← ★
| Mount Point: /System/Volumes/Data
+-> Volume disk3s6 (VM)
Capacity Consumed: 22.6 GB ← ★
Mount Point: /System/Volumes/VM
これで全体像が見える。
| ボリューム | 役割 | サイズ |
|---|---|---|
| System (disk3s1) | macOS 本体（読み取り専用） | 11.2 GB |
| Preboot | 起動処理・APFS メタデータ | 8.5 GB |
| Recovery | リカバリパーティション | 2.3 GB |
| Data (disk3s5) | ユーザーデータ領域 | 400.2 GB |
| VM (disk3s6) | 仮想メモリ（スワップ） | 22.6 GB |
"Data" が 400GB 食っている。これが本丸。
そして "VM" が 22.6GB。これも普通じゃない。
VM ボリューム 22.6GB の正体
VM ボリュームは macOS の 仮想メモリのスワップファイルが置かれる場所。/private/var/vm/swapfile0, sleepimage などが実体。
- 通常時は 1〜3GB 程度
- 22.6GB は「長期間再起動していない」サイン
- Claude Desktop / Dia / Ollama / Chrome などメモリ大食らいを同時に動かしていると蓄積しやすい
sleepimageは RAM サイズ相当（32GB 積んでるなら 32GB になり得る）
対策
# 即効：再起動
sudo reboot
# 再起動しないで縮めたい場合（非推奨、システムに不信感与える）
sudo dynamic_pager -P # 一時停止
sudo rm -f /private/var/vm/swapfile*
sudo dynamic_pager -R # 再開
素直に再起動するのが無難。22GB が戻ってくる。
これは「容量管理アプリが真っ先に提案すべき事項」だと思う。
diskutil apfs listで VM 22GB を検出したら即「再起動推奨」と表示するだけで、ユーザーの容量問題の相当数が解決する。
Data ボリューム 400GB の内訳
ホーム配下（~/）を du で測ると、せいぜい 230GB（掃除後）。つまり残り 170GB がホーム外にいる。
ホーム外の大物候補：
sudo du -h -d 1 /Applications /opt /usr/local /Library /private/var 2>/dev/null | sort -hr | head -15
結果（実例）：
53G /Library
46G /Library/Application Support
33G /Applications
7.8G /private/var
5.5G /Applications/Xcode.app
3.9G /Library/Audio
3.3G /opt/homebrew
1.9G /private/var/db
1.5G /private/var/folders
1.0G /private/var/vm
/Library 53GB。しかもそのうち /Library/Application Support が 46GB。
/Library と ~/Library は別物
ここは macOS のディレクトリ構造が紛らわしいポイント。
| パス | 役割 | 誰が管理 |
|---|---|---|
/Library |
システム共有のアプリデータ | システム全体（全ユーザー共用） |
/System/Library |
macOS 本体のライブラリ | OS（読み取り専用） |
~/Library |
ユーザー固有のアプリデータ | ログイン中のユーザー |
/Library/Application Support に 46GB あるということは、どのアプリかがユーザー個別データとは別にシステム共通領域にも大量のデータを置いているということ。よくある例：
- Audio プラグイン（Logic Pro や DAW 関連のサンプルライブラリ、GarageBand の音源）
- 電子音楽機材のドライバ（Waves、Blackmagic ATEM、Native Instruments など）
- 開発者ツールのドライバ（Xcode 関連）
- 一部の 3D / 映像ツールの共通素材
Logic Pro と GarageBand の音源だけで 20GB 超えることもある。DAW を使う人にはよくある話。
/private/var/folders の肥大
/private/var/folders にアプリの一時ファイルがアプリ毎の UUID ディレクトリに書かれる。Chrome / Dia / Claude Desktop / VS Code のキャッシュの一部がここに行く。これが数十GBに肥大することもある。
sudo du -h -d 2 /private/var/folders 2>/dev/null | sort -hr | head
「見える容量」と「本当の容量」の乖離
ここまで見ると、macOS で容量を正確に把握するには以下を全部見る必要があることが分かる。
| 確認すべきこと | コマンド |
|---|---|
| 全ボリュームの使用量 | df -h（パス指定なし） |
| APFS コンテナ構造 | diskutil apfs list |
| スナップショット | diskutil apfs listSnapshots / |
| ホーム配下 TOP | du -h -d 1 ~/ | sort -hr |
Library 配下（~/ と / 両方） |
du -h -d 1 ~/Library / sudo du -h -d 1 /Library |
/private/var/folders |
sudo du -h -d 2 /private/var/folders |
| 巨大単発ファイル | sudo find / -type f -size +5G 2>/dev/null -exec ls -lh {} \; |
CleanMyMac の「スマートスキャン」や DaisyDisk の円グラフは、この全部をカバーしていない。表示されない死角がある。
Purgeable Space の罠
もう一つ、macOS 特有の落とし穴がある。Purgeable Space（削除可能な領域）。
macOS は、iCloud Drive で「オプティマイズ済み」になっているファイル、Photos の最適化キャッシュなど、「いつでも解放できるが、表示上は使用中扱い」の領域を持つ。
これは「About This Mac > Storage」では Purgeable として可視化されるが、df では「使用中」にカウントされる。つまり：
- Finder 上の表示：「100GB空き」
- 実際の物理空き：40GB
- Purgeable：60GB（必要になれば解放される）
この挙動が分からないと、「空きあるはずなのに書き込めない」「消しても減らない」という混乱を招く。
Purgeable を強制的に解放する公式手段は存在しない（一時ファイル大量作成で圧力をかけるハックはある）。素直に iCloud 設定を変える方が早い。
ストック型 vs フロー型
容量問題を解くには、2 種類の増え方を切り分ける必要がある。
ストック型
過去の残骸が放置されているタイプ。
- 古い iPhone バックアップ（AnyTrans, MobileSync）
- 未使用 Ollama モデル
- 過去の Xcode DerivedData
- 使っていないアプリのデータ
→ 一度削除すれば終わり。
フロー型
継続的に増殖するタイプ。根本対策しないと、60GB 空けても 1 ヶ月で戻る。
- VM スワップ（再起動が必要）
/Library/Application Supportの DAW 音源追加- 業務データ（写真・動画）の日々の追加
- Downloads に貯まる zip/pdf
- Docker.raw（イメージ build/pull のたびに肥大）
- Chrome/Dia/Claude のキャッシュ
- Zoom 録画
→ 運用自体を変える必要がある。外付け/NAS 退避、定期スクリプト、自動クリーンアップなど。
まとめ
df -h /は嘘つき。df -h（パスなし）とdiskutil apfs listの両方を見る- VM ボリュームが 5GB 超えたら 再起動すべきサイン
/Libraryと~/Libraryは別物。両方見ないと全貌は見えない/private/var/foldersは一時ファイルの魔窟、たまに掃除すべき- ストック型とフロー型を切り分けないと、永遠に 60GB を消し続ける
- Purgeable Space の存在を知っておくと混乱が減る
CleanMyMac も DaisyDisk も解決してくれない、この「見えないところで消えている」問題こそが、容量管理アプリの最大のテーマだと思う。