# Mac のローカル Time Machine スナップショットを削除する > tmutil でローカルスナップショットを一覧・間引きし、purgeable 領域を理解したうえで、本番バックアップディスクを消さずに空き容量を増やします。 Published: 2026-07-28 | Updated: 2026-08-08 20 GB の書き出しを削除し、ゴミ箱を空にしても、空き容量はほとんど増えません。ついクリーナーを入れたくなります。多くの場合、そのブロックはまだ起動ボリューム上の **ローカル Time Machine スナップショット** に保持されています。ストレージ設定では、その影響が [システムデータ](https://mole.fit/ja/blog/what-is-system-data-on-mac) や曖昧な「パージ可能」の数字にまとめられるため、すでに正しいことをした後でも灰色のバーは大きく残ります。 これはラボ形式のガイドです。APFS のコピーオンライトがブロックをどう固定するか、システムツールでスナップショットをどう測るか、`tmutil` が実際に何を変えるか、本物のバックアップディスクを消さずに容量をどう空けるか。終われば、スナップショットによる固定と「本当にフォルダが見つからない」問題を、5 分以内に見分けられるようになります。 **短い答え：** ファイルを消しても空きが増えないときは、`tmutil listlocalsnapshots /` でスナップショットを一覧し、`tmutil thinlocalsnapshots` で間引き、APFS に固定されたブロックを解放させます。外付けの Time Machine ディスク上のバックアップはどちらでもそのまま残ります。ローカルスナップショットは起動ボリューム上の一時コピーにすぎません。 ## 誤ったメンタルモデル 空き容量を「見えるファイルの合計」だと思いがちです。APFS ではむしろ「参照が残っていないブロック」に近いです。ファイルが Finder から消えても、スナップショットが参照しているエクステントは残ります。最後の参照が落ちるまで、`df` はそのブロックを使用中として数え続けます。 会話では次の 3 種類の数字が混ざりがちです。 | 数字 | 答えていること | |---|---| | Finder / アプリの「サイズ」 | まだ見える名前付きファイルの論理サイズ | | `df` の使用量 / 空き | マウントされたファイルシステムの会計ルール後の報告値 | | ストレージの「パージ可能」 | 複数の回収可能プールをまとめた上限の目安 | パージ可能はフォルダではありません。ローカルスナップショット、一部のキャッシュ、追い出し可能なクラウド内容、会計上のゆとりなどが含まれます。前後の `df` を示さずに「パージ可能 47.2 GB を解放」と約束するツールは、当て推量です。 ## 仕組み：コピーオンライトとスナップショット Time Machine が **ローカルスナップショット** を作ると、ボリュームはエクステントの凍結されたビューを記録します。その後の書き込みは新しいブロックを割り当てます。古いブロックは、いずれかのスナップショットがまだ必要としている間、生き続けます。ファイルを削除すると、ライブボリューム側のポインタが外れるだけです。 だから、次のような流れがよく起きます。 1. `df -h /` で空き容量を記録する。 2. 自分で管理できる大きな不要ファイルを削除し、ゴミ箱を空にする。 3. 空き容量はほとんど動かない。 4. `tmutil listlocalsnapshots /` にはまだエントリがある。 5. ローカルスナップショットを thin または削除したあと、空きが増える（数分かかることもある）。 Apple はローカルスナップショットを自動管理だと説明しています。外付けバックアップの合間に作られ、短い期間だけ保持され、[容量が必要になると間引き](https://support.apple.com/102154) されます。バックアップディスクが外れているときに、直近の版を復元するのに役立ちます。外付けメディア上の完全な Time Machine 履歴の代わりにはなりません。
ライブボリューム上の削除済みファイルはローカルスナップショットが参照している間ブロックを占め、スナップショットが間引きされて初めてブロックが解放されます
Finder で削除するとライブ参照は外れます。そのエクステントは、まだ指しているローカルスナップショットがすべて間引きまたは削除されるまで割り当てられたままです。
ローカルスナップショットの名前は、だいたい次のような形です。 ``` com.apple.TimeMachine.2026-07-28-091530.local ``` `.local` 接尾辞は、バックアップ先のエントリではなく、ディスク上のローカルスナップショットであることの一般的な目印です。 ## ローカル、外付け、その他のスナップショット | 種類 | 場所 | どうするか | |---|---|---| | `/` 上のローカル TM スナップショット | 起動ボリューム | 容量が逼迫したら `tmutil` で間引き | | Time Machine バックアップ | 外付けまたはネットワークボリューム | 本物の履歴。内部の空きを増やすために消さない | | その他の APFS スナップショット | 同じボリューム、別の名前 | 所有者を把握しているときだけ削除 | | iCloud ストレージを最適化 | クラウド + ローカル実体化 | 追い出しポリシーであり、`tmutil` ではない | `diskutil apfs listSnapshots /` は Time Machine 以外も表示できます。他のソフトも APFS スナップショットを作れます。中身が分からない TM 以外のスナップショットを、適当な最適化ツールで消さないでください。
APFS コンテナがユーザファイル、スナップショット、消去可能領域、空き領域に分かれます
物理容量はファイル、スナップショット、パージ可能データ、空きに分かれます。システムデータはストレージ上の分類であり、空にすべき単一フォルダではありません。
## ラボ：何かを消す前に測る ターミナルを開き、基準値を取ります。数字は書き留めてください。記憶は当てになりません。 ``` date df -h / tmutil listlocalsnapshots / diskutil apfs listSnapshots / diskutil apfs list ``` ### 出力の読み方 **`listlocalsnapshots` が空。** ローカル TM スナップショットは問題ではありません。`du` やツリーマップ（[大きなファイル](https://mole.fit/ja/blog/how-to-find-large-files-on-mac)）でフォルダを洗い、キャッシュ、写真、Docker、デバイスバックアップを見てください。 **スナップショットがあり、空きが少ない。** 固定の可能性は高いです。間引きに進み、再計測します。 **`diskutil apfs list` が複数ボリュームを持つコンテナを示す。** 空きはコンテナ単位で共有されます。別ボリュームのせいで、あるボリュームラベルは満杯に見え、コンテナにはまだ余裕がある、あるいはその逆、ということがあります。起動ボリュームのラベルだけでなく、コンテナの空きを見てください。 **権限エラー。** 保護されたツリーでは、ターミナルにフルディスクアクセスがないことがあります。それはアクセスの問題であり、ディスクが空だという証拠ではありません。 ### 制御された実験 自分の Mac で確かめたい場合： 1. `df` の空きバイトを控える。 2. 大きな不要ファイル（再作成できるディスクイメージなど）を内蔵ボリュームにコピーし、削除してゴミ箱を空にする。 3. 数秒以内に再度 `df` を比較する。 4. スナップショットを一覧する。 5. 空きがほとんど動かずスナップショットがあるなら間引き、2 分待ち、また `df`。 これで「Finder からファイルが消えた」と「新しい書き込み用にブロックが空いた」を切り分けられます。 ## `tmutil` でできること ### まずシステムに間引きさせる 空きが少しだけ厳しい程度なら、そのまま使い続けてください。アップデートのインストール、大きな書き込み、容量ぎりぎりでの利用などで、macOS が古いローカルスナップショットを勝手に落とすことがよくあります。副作用が最も少なく、直近の復元ポイントも長く残せます。 ### 空き目標まで間引く `tmutil thinlocalsnapshots` は、ローカルスナップショットから要求した量まで回収するようシステムに頼めます。フラグは macOS の版で少し違います。直しているマシンで `man tmutil` を確認してください。概念としては「この名前の 1 時間分を消す」ではなく、「ローカルスナップショットから最大 N バイト空けて」と言っていることになります。 インストーラに余裕が必要で、かつ可能なら新しいローカル復元ポイントは残したいときに使います。 ### ボリュームのローカルスナップショットを削除する ディスクが致命的に満杯で、`listlocalsnapshots` にエントリがあるとき： ``` tmutil deletelocalsnapshots / ``` 版によっては、単一スラッシュ形式ではなく、名前付きローカルスナップショットの日付ベース削除を使います。自分の OS の文書どおりの形式を優先し、必ず再一覧します。 ``` tmutil listlocalsnapshots / df -h / ``` 空きは数秒から数分で増える想定です。APFS はエクステントを非同期に解放することがあります。2 回サンプリングしてください。 ### これらのコマンドと混同しないこと - **バックアップ先に対する `tmutil delete`** は本物のバックアップ履歴を消します。別操作で、リスクも高いです。 - **Finder で `/.MobileBackups` 以下のフォルダを消す** のはサポートされた掃除ではありません。`tmutil` かシステムの回収を使います。 - **Time Machine をオフにする** は、ローカルスナップショットの空き解放に不要で、まだ必要なバックアップ方針を失うことがあります。 - **APFS の仕組みを説明せず root を求めるサードパーティの「スナップショット最適化」** は、`df` で再確認できることを教えずリスクだけ増やします。 ## 実例（数字を暗記するのではなく、物語を読む） 週末に動画を書き出したあと、例えばこうだとします。 - ストレージのシステムデータが約 120 GB、パージ可能が「最大」40 GB。 - 25 GB の書き出しを削除してゴミ箱を空にする。 - `df` の空きは約 2 GB しか増えない。 - `tmutil listlocalsnapshots /` に、直近 1 日分の `.local` エントリがいくつかある。 読み取り：削除した書き出しの多くは、まだローカルスナップショットから参照されています。次の実験は `~/Library` を適当に消すことではなく、ローカルスナップショットの間引きです。 `tmutil deletelocalsnapshots /`（または成功した thin）のあと： - スナップショット一覧は空になるか短くなる。 - `df` の空きが数分で数十 GB 増える。 - ストレージのシステムデータ数字は遅れたり再分類されたりすることがあるので、`df` と実際の作業負荷を信じてください。 スナップショット一覧がすでに空なのに空きがまだ動かないなら、スナップショットとの戦いはやめてください。別の問題です。大きなライブフォルダ、疎ファイル、クローン、同じボリューム上のゴミ箱、コンテナ内の別ボリュームなどです。 ## 間引き後も空きが増えない理由 ローカルスナップショットが消えたあとも、次があり得ます。 - ストレージ見積もりの主因が、ほかのパージ可能クラス（クラウド実体化、再生成可能なキャッシュ）だった。 - 疎ファイルやクローンで、論理サイズと物理サイズがずれる（[合計が一致しない理由](https://mole.fit/ja/blog/daisydisk-alternative)）。 - ゴミ箱にまだ同じボリューム上の削除物が残っている。 - APFS コンテナ内の別ボリュームが空きプールを共有している。 - TM 以外のスナップショット、または Time Machine 先が関連データを保持している。 それぞれに計測経路があります。スナップショットは一章にすぎません。 ## 安全のための前提 積極的に間引く前に： 1. 外付け Time Machine や、実際に開いて試した別の復元パスへの **最近の成功バックアップ** を確認する。 2. 消す途中版は、新しいスナップショットができるまでオフラインでは復元できないと受け入れる。 3. 前後の空き差分を示せないツールより、文書化された `tmutil` を優先する。 ローカルスナップショットは普通のものです。内蔵ボリュームが満杯で、最近消したデータがまだ固定されているときだけ急ぎます。 ## よくある失敗 **システムデータの数字を追う。** 目標は使える容量と、更新や保存ができる Mac であり、見た目の灰色ブロックを小さくすることではありません。 **内部の空きが少ないからといって外付けバックアップディスクを消す。** ローカルスナップショットとバックアップ履歴を取り違えています。 **パージ可能が大きく見えたからといって Library フォルダを適当に消す。** パージ可能は安全なパスの地図ではありません。 **間引き直後に一度だけ測る。** 待ってから、もう一度 `df` を取ってください。 **コンテナの会計を無視する。** APFS では、1 つのボリュームラベルが全体ではありません。 ## 確認ツールが合う場所 [Mole](https://mole.fit/) の Analyze ビューのディスクマップは、大きなライブフォルダを示せます。Mole はディスク分析、アプリの手入れ、確認してから掃除するクリーンアップを、ネイティブ Mac アプリにまとめています。システムデータは、いまも macOS と各アプリが管理します。スナップショットについては、真実源として `tmutil` と前後の `df` を使ってください。 ## 作業の順序 1. 本物のバックアップパスがまだあることを確認する。 2. `df -h /` と `tmutil listlocalsnapshots /` を記録する。 3. スナップショットがあり容量が少ないなら、`tmutil` でローカルスナップショットを間引きまたは削除し、待ち、再計測する。 4. スナップショットが残っていなければ、フォルダを測り、所有権に沿って [自分のキャッシュ](https://mole.fit/ja/blog/how-to-clear-cache-on-mac) や大きなユーザーファイルを片づける。 5. 削除を受け入れたあとでだけゴミ箱を空にする。 6. 以前失敗した作業（インストーラ、書き出し、アップデート）を走らせ、収まることを確認する。 ## 参考リンク - Apple: [About Time Machine local snapshots](https://support.apple.com/102154) - Apple: [macOS Storage](https://support.apple.com/guide/mac-help/syspf5a64aa6/mac) - このサイトの関連記事： [システムデータ](https://mole.fit/ja/blog/what-is-system-data-on-mac)、 [容量を空ける](https://mole.fit/ja/blog/how-to-free-up-space-on-mac)、 [大きなファイルを探す](https://mole.fit/ja/blog/how-to-find-large-files-on-mac) ローカルスナップショットは、Time Machine が起動ディスク上で短期の取り消しを得る APFS の仕組みです。`tmutil` と `df` を一緒に読めるようになれば、「30 GB 消したのに何も起きない」は、怪しげなソフトを信じる理由ではなく、検証できるメカニズムになります。 ## よくある質問 ### ローカルスナップショットを消すと、Time Machine のバックアップディスクに影響しますか？ いいえ。ローカルスナップショットは起動ボリューム上にあり、設計上は一時的です。外付けバックアップディスクは独自の完全な履歴を保持します。ローカルスナップショットの間引きや削除が、バックアップディスク上の何かを書き換えることはありません。 ### ゴミ箱を空にした直後に空き容量が変わらないのはなぜですか？ APFS では、ファイルのブロックは最後の参照が落ちるまで割り当てられたままです。スナップショットがまだそのエクステントを参照していると、`df` は使用中として数え続けるため、スナップショットが間引きされるか期限切れになってからしか空きは戻りません。 ### ローカルスナップショットを一度にすべて消しても安全ですか？ ディスク容量としては安全です。バックアップディスクにはすべてのバックアップが残ります。失うのは、バックアップとバックアップのあいだの時点へ起動ボリュームを復元する能力だけです。それも macOS がだいたい 24 時間以内に捨てていたものです。 --- Canonical HTML page: https://mole.fit/ja/blog/how-to-delete-local-time-machine-snapshots-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt