Macのディスク容量を奪っているのはファイルではなくスナップショット――その証明方法

macOSTahoe ·
Macのディスク容量を奪っているのはファイルではなくスナップショット――その証明方法

macOS 27にアップグレードする前に、macOSが隠している容量――APFSスナップショット、パージ可能なコンテンツ、Preboot、スワップ――を見つけ出す方法。使用するコマンドと、絶対に削除してはいけないものを解説。

40GB分の動画を削除してゴミ箱を空にしても、空き容量の表示はほとんど動かない。あるいはその逆に、Finderは300GBの空きがあると涼しい顔で表示しているのに、macOS 27のインストーラーは容量不足を理由に起動を拒否する。どちらも同じ現象だ。APFSでは「空き容量」は交渉によって決まる数字であり、Finder越しには見えないディスクの部分――スナップショット、パージ可能なコンテンツ、同じコンテナを共有する兄弟ボリューム――がその差分の正体だ。9月14日にメジャーアップグレードが控えている今、本当の数字の読み方を知っておく価値がある。

要点

  • df とFinderは仕組み上、正しい数字を示さない。 インストーラーにとって重要なのはAPFSのコンテナの空き容量であり、これは diskutil info / で確認する。
  • システムボリュームには絶対に削除してはいけないスナップショットが存在する ――起動時に使われる、封印され署名されたシステムボリュームのことだ。これは diskutil には表示されるが tmutil には表示されない。この違いこそが診断のすべてだ。
  • 容量が消える原因として最も多いのはTime Machineのローカルスナップショットだ。 これらは24時間後、または空き容量が少なくなった時点で削除されるが、その「少なくなった」の基準は思っているより低い。
  • パージ可能な容量は、圧力がかかればmacOSが実際に解放する本物の容量だ ――ただしメジャーアップグレードは、必要なタイミングで正しい種類の圧力を生み出してくれるとは限らない。
  • コンテナ内の他のボリュームも容量を消費している。 このMacではPrebootが9GB、VMボリュームがスワップとして18GBを占めているが、どちらもFinderのどこにも表示されない。

4つの数字、1台のディスク

まずはこの食い違いに異議を唱えるのではなく、実際に目で見ることから始めよう。macOS 26.5.2を1TB SSDで動かしているこのMacでは：

$ df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   395Gi     3%    /
/dev/disk3s5     926Gi   493Gi   395Gi    56%    /System/Volumes/Data

2つのボリュームはどちらも926GiBだと主張し、どちらも同じ395GiBの空き容量を報告している。どちらも間違ってはいないが、どちらも真実ではない。APFSのボリュームはコンテナを共有し、その中で伸縮するため、「サイズ」はコンテナのサイズであり、「空き容量」はコンテナの空き容量が各ボリュームで繰り返し表示されているだけだ。

次はコンテナに直接尋ねてみよう。

$ diskutil apfs list disk3 | grep -E "Capacity|Volume Disk|Consumed"
    Size (Capacity Ceiling):      994662584320 B (994.7 GB)
    Capacity In Use By Volumes:   570712170496 B (570.7 GB) (57.4% used)
    Capacity Not Allocated:       423950413824 B (424.0 GB) (42.6% free)
    |   APFS Volume Disk (Role):   disk3s1 (System)
    |   Capacity Consumed:         12568809472 B (12.6 GB)
    |   APFS Volume Disk (Role):   disk3s2 (Preboot)
    |   Capacity Consumed:         8995532800 B (9.0 GB)
    |   APFS Volume Disk (Role):   disk3s3 (Recovery)
    |   Capacity Consumed:         1304084480 B (1.3 GB)
    |   APFS Volume Disk (Role):   disk3s5 (Data)
    |   Capacity Consumed:         529380937728 B (529.4 GB)
        APFS Volume Disk (Role):   disk3s6 (VM)
        Capacity Consumed:         18253713408 B (18.3 GB)

これが正直な内訳だ。5つのボリュームのうち、Finderで閲覧できるのはData（529GB）のひとつだけだ。Prebootは9GB。VMボリュームは18GB。 合わせると、たいていの人のドキュメントフォルダより多くの容量を占めているのに、Mac上のどのストレージ管理画面にもこれらは表示されない。

インストーラーが気にする数字はこれひとつだけだ。

$ diskutil info / | grep "Container Free Space"
   Container Free Space:      423.9 GB (423947014144 Bytes)

この数字を使うこと。もしFinderの表示と数十GB単位で食い違っているなら、以下ではその差分がどこへ消えたのかを説明していく。

絶対に削除してはいけないスナップショット

素直にこのコマンドを実行すると、結果はぎょっとするものに見える。

$ diskutil apfs listSnapshots /
Snapshot for disk3s1s1 (1 found)
|
+-- B8B12570-09B5-402F-99BB-F383487AD69D
    Name:        com.apple.os.update-5B92CE4BA1034457A0921532291F4A4AD939CBE...
    XID:         17495484
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

パージ不可とマークされ、コンテナの最小サイズを制限していると明示的に説明されているスナップショット。これがディスクを食い尽くしている犯人だと結論づけたくなる。

だが違う。これはあなたが今動かしているオペレーティングシステムそのものだ。

macOS 11以降、システムボリュームは封印され暗号学的に検証されており、Macはそのボリューム自体を起動するのではなく、そのスナップショットを起動する。diskutil apfs list はそれを直接示している。

|   APFS Volume Disk (Role):   disk3s1 (System)
|   Snapshot:                  B8B12570-09B5-402F-99BB-F383487AD69D
|   Snapshot Disk:             disk3s1s1
|   Snapshot Mount Point:      /
|   Snapshot Sealed:           Yes

Snapshot Sealed: Yes、マウント先は /。com.apple.os.update- というプレフィックスは、OSアップデートが適用された際に作成されるスナップショットの命名規則だ。これを削除するのはクリーンアップ作業ではなく、稼働中のシステムを削除する行為だ。macOSは通常これを拒否するが、「通常」という言葉と起動不能なMacとの間に挟まっていてほしい言葉ではない。

削除できるスナップショットとの違いを見分ける手がかりはこれだ。

$ tmutil listlocalsnapshots /
Snapshots for disk /:

$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for disk /System/Volumes/Data:

どちらも空だ。tmutil が報告するのはTime Machineのスナップショットだけ ――バックアップのために作られ、間引いても安全な種類のものだ。一方 diskutil は封印されたシステムのものも含め、すべてのAPFSスナップショットを報告する。diskutil にスナップショットが表示され tmutil には表示されないなら、それはあなたが削除していいものではない。

経験則：行動の判断材料は tmutil が示すものにする。diskutil は理解のために読むものであって、判断のためのものではない。

実際にディスクを食い尽くすスナップショット

Time Machineはバックアップドライブだけでなく、Mac本体にもローカルスナップショットを作成する。そしてこれこそが「80GBはどこに消えたのか」という問いへの、よくある答えだ。

仕組み自体は単純だが、その結果は単純ではない。スナップショットはある瞬間のボリュームの状態を保存する。その後にファイルを編集すると、元のブロックは新しいブロックと一緒に保持しなければならない。スナップショット取得時点で存在していた20GBの動画を削除しても、容量は戻ってこない――スナップショットがまだそれを参照しているからだ。2つのスナップショットの間に作成かつ削除されたファイルだけは例外で、これらは正真正銘消え去り、復元もされない。

Appleの管理方式は経過時間ベースと圧力ベースの2本立てだ。24時間を超えたスナップショットは削除され、空き容量が危機的に少なくなると古いものからパージされる。この2つのルールの間で、Time Machineのスケジュールが有効でファイルの入れ替わりが激しい一日を過ごしたMacは、時間経過か圧力しきい値のどちらかが条件を満たすまで解放されない数十GBを抱え込むことになりかねない。

このMacにはTime Machineの保存先が設定されていない。

$ tmutil destinationinfo
tmutil: No destinations configured.

――だからこそスナップショットのリストは空であり、Dataボリュームも No snapshots for disk3s5 と表示される。もしあなたのMacで設定済みなら（設定しておくべきだ――最新のバックアップ戦略ガイドを参照）、いくつか見つかるはずだ。

ディスクユーティリティで確認する

ターミナルを使いたくない場合は、ディスクユーティリティを開いて 表示 → すべてのデバイスを表示 を選び、Dataボリュームを選択したうえで 表示 → APFSスナップショットを表示 を有効にする。サイズ付きの一覧と、個々のスナップショットを削除できるコンテキストメニューが表示される。Howard Oakleyのアドバイスは繰り返す価値がある――最新のものは残しておくこと。すべて削除してしまうと、次回Time Machineが実行される際にフルバックアップのサイクルに入ってしまう可能性がある。

MacのデータボリュームのAPFSスナップショット一覧を表示するディスクユーティリティ

意図的に間引く

スナップショットの容量を回収するためのサポートされた方法は thinlocalsnapshots だ。これはマウントポイント、解放を試みるバイト数、そして1から4までの緊急度を引数に取る。

# Ask macOS to free roughly 20 GB from Data volume snapshots, highest urgency
sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4

緊急度4はもっとも積極的で、必要であれば最新のもの以外すべてのスナップショットを削除する。これはmacOSが容量の圧力を受けたときに自分自身に対して行うことであり、手動で実行するのは単にそれを前倒しでやっているだけだ。

ボリューム単位で間引くのではなく、特定のスナップショットを削除したい場合は次のようにする。

# List them first
tmutil listlocalsnapshots /System/Volumes/Data

# Delete one by its date stamp
sudo tmutil deletelocalsnapshots 2026-09-10-140233

そして、より低レベルの等価コマンドがこちらだ。UUID、XID、または名前によって任意のAPFSスナップショットに対して機能する。

diskutil apfs deleteSnapshot disk3s5 -uuid <snapshot-UUID>

可能な限り tmutil を使うこと。diskutil apfs deleteSnapshot は平気で間違ったボリュームを指定してしまう可能性があり、ここでの「間違ったボリューム」とはまさに起動中のボリュームのことだ。

「パージ可能」の本当の意味

macOSは一部の容量を「パージ可能」として報告する。これはディスクが満杯になったときに自動的に削除する準備ができているコンテンツのことだ。保持期間を過ぎたスナップショット、クラウド上に存在するキャッシュされたiCloudファイル、すでにアップロード済みの写真のオリジナル、ダウンロード済みのメディア、各種キャッシュなどが含まれる。

パージ可能な容量は本当に取り戻せるものだ――ただし、その回収は受動的だ。macOSは何かが容量を要求したときにそれを解放するが、その要求はmacOSが認識できる形で届く必要がある。大きな cp はそれを引き起こすが、書き込みを始める前に空き容量を事前チェックして拒否するタイプのインストーラーは、引き起こさないかもしれない。

これがまさにアップグレード当日に起きる失敗パターンだ。何百GBもパージ可能な容量があるのに、インストーラーは起動せず、システムに動いてもらう明白な方法もない。この状況を強引かつ安全に打開する方法は、実際に圧力を作り出すことだ。

# Write a large file to force macOS to reclaim purgeable space, then delete it
mkfile -n 30g ~/Desktop/ballast
rm ~/Desktop/ballast

mkfile -n はスパースファイルを作成するため、書き込み自体は高速だ。回収のきっかけになるのは、その「割り当て」という行為そのものだ。空き容量の数字が動いたら、すぐにこのファイルを削除すること。

誰も話題にしないボリューム

コンテナ内の5つのボリュームのうち2つは、よく見る価値がある。どちらも肥大化していくのに、誰も気にかけていないからだ。

Preboot――このMacでは9.0GB。 これはコンテナがこれまでに持ったすべてのOSインストールについての、起動時アセットを保持している。リカバリー環境やボリュームごとの暗号材料も含まれる。メジャーアップグレードのたびに肥大化し、自動的には削減されない。また手作業で掃除するようなものでもない。間違ったものを削除すればMacは起動しなくなる。これまで行ってきたアップグレードの固定コストだと考えるべきだ。

VM――このMacでは18.3GB。 これはスワップだ。中身は正確に確認できる。

$ ls -lh /System/Volumes/VM/
-rw-------  1 root  wheel   1.0G ... swapfile0
-rw-------  1 root  wheel   1.0G ... swapfile1
-rw-------  1 root  wheel   1.0G ... swapfile10
...

$ sysctl vm.swapusage
vm.swapusage: total = 17408.00M  used = 16258.81M  free = 1149.19M  (encrypted)

1GBのスワップファイルが17個あり、そのうち16GBが使用中だ。macOSはスワップを必要に応じて拡大するが、積極的に縮小することはない。確実に回収する方法は再起動だ。アップグレード前に容量が厳しいなら、Macを再起動するのはおまじないなどではない――何週間も起動しっぱなしのマシンでは、実際に数GBが戻ってくる。

macOS 27にはどれだけの空き容量が必要か

Appleが公表するメジャーアップグレードの最小要件は、これまで移行元のバージョンによって25～45GBの範囲だった。フルインストーラー自体は約17GBで、Tahoeの場合はインストーラーカタログによれば17,953,734 KiBであり、Golden Gateも同程度のクラスになるはずだ。

実務上の数字は、公表されている数字よりも大きい。メジャーアップグレードを始める前にコンテナの空き容量60GBを見込んでおくこと。理由は3つ――インストーラーのダウンロード、インストール自体が必要とする作業領域、そしてアップグレードの前にmacOSがシステムに対して取得するスナップショットで、これは処理の途中で間引くことができない。

見積もるのではなく、確認すること。

diskutil info / | grep "Container Free Space"

もうひとつの楽観的な数字：iCloudと写真

2つの機能は、意図的にディスクを実際より広く見せる形で容量を報告する。

**iCloud Driveの「Macストレージを最適化」**は、最近使っていないファイルの中身を追い出し、必要になったらダウンロードされるスタブだけを残す。Finder上ではファイルは元のサイズのまま表示されるが、ディスク上にはほとんど何も残っていない。これは優れた挙動だが、インストーラーが空き容量を尋ねてくるまでの話だ。なぜなら追い出された中身は「空き」ではなく「パージ可能」として数えられるからだ。

**写真の「Macストレージを最適化」**も同様に、オリジナルに対して同じことを行い、ローカルには縮小版だけを残す。200GBのライブラリがディスク上ではわずか30GBしか占めていないこともあり、間違ったタイミングで間違ったビューを開くと、静かに大量の再ダウンロードが始まることもある。

どちらも修正すべき問題ではない。ただし、これらこそがMacが何もしていないのに「十分な空き」から「ディスク満杯」へと変化してしまう理由であり、先週測った空き容量の数字が今日にはもう無意味になっている理由でもある。アップグレードの前夜ではなく、アップグレードの直前に測定すること。

アップグレード前の容量チェック：5つのコマンドで

以下を順番に実行すれば、1分もかからずに自分の状況を正確に把握できる。

# 1. The number that matters
diskutil info / | grep "Container Free Space"

# 2. Every volume in the container, with what it is consuming
diskutil apfs list $(diskutil info / | awk '/Part of Whole/ {print $4}') | grep -E "Capacity|Volume Disk"

# 3. Snapshots that are actually yours to remove
tmutil listlocalsnapshots /System/Volumes/Data

# 4. Swap, which a restart returns
sysctl vm.swapusage

# 5. The largest directories in your home folder
du -sh ~/* 2>/dev/null | sort -rh | head -10

ステップ1の数字が60GBを超えていれば、そこで終わりだ――準備は整っている。そうでなければ、ステップ2から5が、リスクが小さい順におおよそどの4つの原因に取り組むべきかを教えてくれる。

安全な順に、容量を取り戻す

  1. 再起動する。 スワップを解放し、キャッシュをクリアし、一部のスナップショットを削除する。かかる時間は2分ほどで、たいてい10～20GBが戻ってくる。
  2. Time Machineのスナップショットを間引く。 sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4。安全でサポートされた方法であり、次のバックアップで重要な部分は再作成されるという意味で可逆的だ。
  3. ゴミ箱を空にする。 写真アプリやメールも含めて。これらでは削除した項目がアプリ内のゴミ箱に30日間留まる。
  4. 数字がまだ一致しない場合は、前述のバラストファイルのトリックでパージ可能な容量の回収を強制する。
  5. 該当する場合は開発者向けキャッシュ。 このMacでは /System/Library/AssetsV2 が合計25GBあり、そのうち16GBがiOSシミュレーターのランタイムだ。Xcodeのderived data、デバイスサポート、アーカイブは、実働中の開発機では日常的に50GB以上を追加する。Xcode自体の 設定 → コンポーネント パネルを使えば、シミュレーターランタイムをきれいに削除できる。
  6. 自分が本当に所有している大きなファイル。 ストレージ解析ツールを使えば、手作業で探すより速く見つかる。そしてディスクは満杯なのに原因らしきものが見当たらない場合は、隠れたルートレベルのログを疑ってみるのもよい。
  7. 外部ストレージへ移す。 ディスクが単純に小さすぎる場合の、時間はかかるが正しい答えだ。

やってはいけないこと

  • システムボリューム上の com.apple.os.update- スナップショットを削除しないこと。 これは稼働中のOSそのものだ。
  • /System/Volumes/ 以下のものを rm -rf しないこと。 Preboot、VM、Recoveryはシステムを支える構造そのものだ。
  • 「容量を節約する」ためにTime Machineのローカルスナップショットを無効にしないこと。 不具合のあるアップデートをロールバックする能力を失うことになる――アップグレード週間にこそ必要な、まさにその安全網だ。
  • この作業のためにクリーナーアプリをインストールしないこと。 上記のすべての操作は組み込みのコマンドで完結する。システムファイルを削除して容量を解放すると謳うフルディスクアクセス権限を持つサードパーティ製ツールは、ディスク満杯そのものよりも大きなリスクだ。
  • スワップファイルを手動で削除しないこと。 macOSはそれらを再作成するし、使用中のものを削除すればクラッシュにつながる。

スナップショットの回収前後でコンテナの空き容量を比較したターミナル出力

よくある問題のトラブルシューティング

tmutil thinlocalsnapshots は成功と報告するが何も解放されない

削除されたスナップショットは、他のスナップショットも参照しているブロックを参照していた。複数の重なり合うスナップショットのうち1つを削除しても何も解放されない。最後の1つを削除したときに、まとめて一気に解放される。緊急度4で再実行するか、残りを個別に削除すること。

ディスクユーティリティにスナップショットが表示されないのに容量が足りない

それならスナップショットが原因ではない。コンテナのボリューム内訳を確認すること――PrebootとVMが定番の伏兵だ――そしてパージ可能な容量も確認すること。大きなiCloud写真ライブラリを持つMacは、最適化されたオリジナルが奇妙な形で報告されることもある。

インストーラーは容量不足だと言うが diskutil では十分にあるように見える

自分が見ているのがボリュームではなくコンテナであること、そして外部ディスクではなく内蔵ディスクを見ていることを確認すること。両方とも十分な空きがあるなら、それは容量エラーの姿をした別の問題であることが多い――サードパーティ製kextの認証失敗がよくあるケースだ。初日アップグレードガイドでkextチェックについて解説している。

一晩で容量がどんどん消えていく

Time Machineが実行された。それはシステムが正常に動作している証拠だ。もし入れ替わりの量が本当に度を越しているなら、Time Machine自体ではなく、何が書き込みをしているのかに目を向けること――大きなファイルを書き換える同期クライアント、VMのディスクイメージ、データベースなどが考えられる。

スナップショットを削除した後Macが起動しなくなった

リカバリーモードで起動し、以前のスナップショットが残っていればTime Machineシステム復元を使ってロールバックする。残っていなければ、その上からmacOSを再インストールする。これによりDataボリュームは保持される。これはまさに「封印されたスナップショットを削除しない」というルールが防ごうとしている事態だ。

FAQ

APFSのスナップショットはバックアップになるか

ならない。スナップショットは、それが参照するデータと同じディスク上に存在する。SSDが故障すれば、スナップショットも一緒に失われる。これらはミスや不具合のあるアップデートから保護するものであり、ハードウェア障害からは保護しない。本物のバックアップは別の場所に存在する必要がある――バックアップ戦略ガイドを参照。

macOS 27へのアップグレード前にスナップショットを削除すべきか

すべて削除するのではなく間引き、最新のものは残しておくこと。アップグレード自体が、アップグレード前のシステムの新しいスナップショットを作成する。これは、もし何か問題が起きたときにこそ欲しくなるものだ。

なぜFinderは異なる空き容量の数字を表示するのか

Finderはパージ可能なコンテンツを含めたボリュームの利用可能容量を報告しており、これは楽観的な数字だ。diskutil info / はコンテナの実際の空き容量を報告する。インストーラーが関わる場面では、後者を信用すること。

macOSがローカルスナップショットを取得するのを止められるか

Time Machineを完全に無効化すれば止まるが、それは割に合わない取引だ。24時間の保持期間に加え、圧力に基づく自動間引きがあるため、健全なMacであればスナップショットは自然と自己制限される。

Prebootの9GBは普通の範囲か

やや多めではあるが、複数回のメジャーアップグレードを経てきたMacとしては驚くほどではない。コンテナがホストしてきたOSインストールのたびに増えていく。これを削減するサポートされた方法はなく、試みる理由もない。

再起動すると本当に容量が空くのか

空く。しかも計測可能なほどに。主な要因はスワップだ――このMacでは18GB――加えてキャッシュや期限切れのスナップショットもある。これは最初に試すべきことであり、唯一コストがかからない方法でもある。

まとめ

Finderの空き容量の数字は、安心させるために書かれた要約に過ぎない。コンテナの数字こそが、月曜日のアップグレードが始まるかどうかを決める。両者のギャップの正体は、間引くことができるスナップショット、圧力がかかれば解放されるパージ可能なコンテンツ、そして現代のMacを動かすための単なるコストである2つの見えないボリュームだ。

この記事全体からコマンドをひとつだけ覚えるなら、diskutil info / | grep "Container Free Space" にしてほしい。この記事の他のすべては、なぜその数字が予想と違うのかを説明しているに過ぎない――だが、それこそが正しい数字なのだ。

関連記事：macOS 27 Golden Gate初日アップデートガイド · macOS 27がソフトウェアアップデートに表示されない理由 · ディスクを圧迫する隠れたルートレベルのログ · Time Machineのトラブルシューティング