Mac のローカル Time Machine スナップショットを削除する

ストレージ公開日 更新日 約9分で読めます

Time Machine のローカルスナップショットは、バックアップ先が使えない間の復元点を起動ボリュームに保ちます。古いブロックを参照することはありますが、存在自体は障害ではありません。Apple はその領域を使用可能として数え、古くなるか別の処理が容量を必要とすると自動削除します。

通常の容量確認後も保存、コピー、インストールが失敗するときだけ検討します。tmutil listlocalsnapshots / は読み取り専用です。Apple の公開手順は自動バックアップを一時的に切り、削除を待ってから再度有効にする方法です。高度な削除はローカル復元点を失うため、定期清掃には使いません。

誤ったメンタルモデル

空き容量を「見えるファイルの合計」だと思いがちです。APFS ではむしろ「参照が残っていないブロック」に近いです。ファイルが Finder から消えても、スナップショットが参照しているエクステントは残ります。最後の参照が落ちるまで、df はそのブロックを使用中として数え続けます。

会話では次の 3 種類の数字が混ざりがちです。

数字 答えていること
Finder / アプリの「サイズ」 まだ見える名前付きファイルの論理サイズ
df の使用量 / 空き マウントされたファイルシステムの会計ルール後の報告値
ストレージの「パージ可能」 複数の回収可能プールをまとめた上限の目安

パージ可能はフォルダではありません。ローカルスナップショット、一部のキャッシュ、追い出し可能なクラウド内容、会計上のゆとりなどが含まれます。前後の df を示さずに「パージ可能 47.2 GB を解放」と約束するツールは、当て推量です。

仕組み：コピーオンライトとスナップショット

スナップショットは作成時の extent を記録し、後の書き込みは新しいブロックを使います。古いブロックが残る仕組みは説明できますが、一覧にあるスナップショットが現在の処理を止めている証明にはなりません。Apple は自動管理と使用可能容量への算入を説明しています。

ファイルが現在のボリュームから消えてもローカルスナップショットは古いブロックを参照でき、別の処理が容量を必要とすると macOS が管理されたスナップショットを回収します。
物理ブロックを保持しながら、その容量が新しい処理に使用可能と扱われることがあります。

ローカルスナップショットの名前は次のような形です。

com.apple.TimeMachine.2026-07-28-091530.local

末尾の .local が、バックアップ先の項目ではなくディスク上のローカルスナップショットである目印です。

ローカル、外付け、その他のスナップショット

種類 場所 どうするか
/ 上のローカル TM スナップショット 起動ボリューム システム管理。必要性を証明した場合だけ手動削除
Time Machine バックアップ 外付けまたはネットワークボリューム 本物の履歴。内部の空きを増やすために消さない
その他の APFS スナップショット 同じボリューム、別の名前 所有者を把握しているときだけ削除
iCloud ストレージを最適化 クラウド + ローカル実体化 追い出しポリシーであり、tmutil ではない

diskutil apfs listSnapshots / は Time Machine 以外も表示できます。他のソフトも APFS スナップショットを作れます。中身が分からない TM 以外のスナップショットを、適当な最適化ツールで消さないでください。

APFS コンテナがユーザファイル、スナップショット、消去可能領域、空き領域に分かれます
物理容量はファイル、スナップショット、パージ可能データ、空きに分かれます。システムデータはストレージ上の分類であり、空にすべき単一フォルダではありません。

ラボ：削除せずに測る

Finder の使用可能容量、diskutil info /、失敗した処理を記録し、一覧だけを取ります。

date
df -h /
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /
diskutil apfs list

項目があることは復元点の証拠であり、容量障害の証拠ではありません。元の処理を再試行し、分類表示ではなく成功か失敗かで判断します。

出力の読み方

listlocalsnapshots が空。 ローカル TM スナップショットは原因ではありません。du やツリーマップでフォルダを測り（大きなファイルを探す）、キャッシュ、写真、Docker、デバイスのバックアップを見ます。

スナップショットがあり、物理的な空きも少ない。 それは普通の証拠であって診断ではありません。Finder の使用可能容量を確かめ、容量が必要な処理をもう一度試してから Time Machine を触ります。

diskutil apfs list に複数ボリュームのコンテナが出る。 空きはコンテナ単位で共有されます。もう一方のボリュームのせいで片方のラベルだけ満杯に見えることも、その逆もあります。起動ボリュームのラベルだけでなく、コンテナの空きを見てください。

権限エラー。 ターミナルに一部の保護された領域のフルディスクアクセスがないだけかもしれません。アクセスの問題であって、ディスクが空である証拠ではありません。

条件をそろえた実験

整理前後を比べるには、Finder の使用可能容量、diskutil info /、失敗している処理の結果を記録します。スナップショットは削除せず一覧するだけにします。容量を空ける必要がある場合は、不要と確認したファイルか、別の場所に検証済みのバックアップがあるファイルを削除します。ゴミ箱の中身を確認してから空にし、同じ処理をやり直します。ストレージの分類の更新が遅れていても、書き込みが失敗したとは限りません。実際の処理が成功するかを確かめます。

tmutil でできること

まず自動管理に任せる

通常の保存や更新が動くなら操作不要です。

Apple の公開手順

実際の処理が容量不足で失敗し、他のファイルで説明できない場合は、自動バックアップを一時的に切り、数分待ってから必ず再度有効にします。

高度なコマンド

手元の man tmutil は thinlocalsnapshots mount_point [purge_amount] [urgency] を記載しています。現在のマニュアルと最新バックアップを確認し、文脈のない裸コマンドを使わないでください。削除は外付け履歴を書き換えませんが、Mac 上の復元点を消します。最後にバックアップを戻し、失敗した処理を再試行します。

ボリュームのローカルスナップショットを削除する

ディスクが本当に逼迫していて、listlocalsnapshots に項目が並ぶときです。

tmutil deletelocalsnapshots /

バージョンによっては、スラッシュ一つの形ではなく日付で指定したローカルスナップショットを削除します。使っている OS で文書化されている形を優先し、そのあと必ず一覧し直します。

tmutil listlocalsnapshots /
df -h /

APFS は extent を非同期で解放することがあるため、空きが増えるまで数秒から数分かかります。二回測ってください。

これらのコマンドと混同しないもの

  • バックアップ先に対する tmutil delete は本物のバックアップ履歴を消します。別の操作であり、失うものが大きくなります。
  • Finder で /.MobileBackups の下のフォルダを消すこと はサポートされた手順ではありません。tmutil かシステムの回収を使います。
  • 手動削除を試したあと Time Machine を切ったままにすること は、一時的な容量確認とバックアップの不在を交換しています。自動バックアップを戻してください。
  • APFS の仕組みを説明せずに root を求めるサードパーティの「スナップショット最適化ツール」 はリスクだけ増やし、df で確かめ直せることは何も教えてくれません。

実例

システムデータが大きくスナップショットもある一方、macOS 更新が開始できるなら修理は不要です。更新が容量不足で失敗するなら、実ファイルとゴミ箱を測り、一つ変更して再試行します。それでも説明できない場合だけスナップショット削除を限定的な実験にし、バックアップを戻して更新を再試行します。失敗が続くなら別のライブデータを調べます。

間引き後も空きが増えない理由

ローカルスナップショットが消えたあとも、次があり得ます。

  • ストレージ見積もりの主因が、ほかのパージ可能クラス（クラウド実体化、再生成可能なキャッシュ）だった。
  • 疎ファイルやクローンで、論理サイズと物理サイズがずれる（合計が一致しない理由）。
  • ゴミ箱にまだ同じボリューム上の削除物が残っている。
  • APFS コンテナ内の別ボリュームが空きプールを共有している。
  • TM 以外のスナップショット、または Time Machine 先が関連データを保持している。

それぞれに計測経路があります。スナップショットは一章にすぎません。

安全のための前提

積極的に間引く前に：

  1. 外付け Time Machine や、実際に開いて試した別の復元パスへの 最近の成功バックアップ を確認する。
  2. 削除した過去の版の復元点は失われる。新しいスナップショットはその後の状態を記録するだけで、消した過去の版を補えない。復元できるかは別のバックアップ次第と理解する。
  3. 前後の空き差分を示せないツールより、文書化された tmutil を優先する。

ローカルスナップショットは普通のものです。内蔵ボリュームが満杯で、最近消したデータがまだ固定されているときだけ急ぎます。

よくある失敗

システムデータの数字を追う。 目標は使える容量と、更新や保存ができる Mac であり、見た目の灰色ブロックを小さくすることではありません。

内部の空きが少ないからといって外付けバックアップディスクを消す。 ローカルスナップショットとバックアップ履歴を取り違えています。

パージ可能が大きく見えたからといって Library フォルダを適当に消す。 パージ可能は安全なパスの地図ではありません。

間引き直後に一度だけ測る。 待ってから、もう一度 df を取ってください。

コンテナの会計を無視する。 APFS では、1 つのボリュームラベルが全体ではありません。

確認ツールが合う場所

Mole の Analyze ビューのディスクマップは、大きなライブフォルダを示せます。Mole はディスク分析、アプリの手入れ、確認してから掃除するクリーンアップを、ネイティブ Mac アプリにまとめています。システムデータは、いまも macOS と各アプリが管理します。スナップショットについては、真実源として tmutil と前後の df を使ってください。

作業の順序

  1. バックアップ先と自動バックアップを確認します。
  2. Finder、diskutil info /、失敗した処理を記録します。
  3. 大きなユーザーファイルとゴミ箱を先に測ります。
  4. ローカルスナップショットを読み取り専用で一覧します。
  5. 同じ処理がまだ失敗する場合だけ Apple の手順か現在のマニュアルを使います。
  6. バックアップを戻し、処理が成功したら止めます。

参考リンク

ローカルスナップショットは、Time Machine が起動ディスク上で短期の取り消しを得る APFS の仕組みです。tmutil と df を一緒に読めるようになれば、「30 GB 消したのに何も起きない」は、怪しげなソフトを信じる理由ではなく、検証できるメカニズムになります。

よくある質問

ローカルスナップショットの削除は外付け履歴に影響しますか？

外付け履歴は書き換えませんが、Mac にだけあった最近の復元点は失われます。

ゴミ箱を空にしてもすぐ増えないのはなぜですか？

分類更新が遅い場合があり、古いブロック参照もあり得ます。ただし管理された領域は使用可能として扱われ、必要時に回収されます。元の処理で確認してください。

全部削除して安全ですか？

定期清掃にはしません。実際の容量障害、最新バックアップ、明確な証拠がそろう場合だけです。