# Mac の大きなファイルを安全に見つけて消す > APFS のスナップショット、クローン、purgeable 容量を解釈し、削除前に所有者と復元可能性で大きなファイルを分類します。 Published: 2026-06-07 | Updated: 2026-08-08 ディスクを何が使っているかは、Finder をフォルダごとに眺めるより、測る方が早いです。 測定には解釈も必要です。40 GB の Photos ライブラリと 40 GB のインストーラは同じではなく、 APFS のスナップショット、クローン、パージ可能容量のせいで、正しいツール同士でも合計が 違って見えることがあります。 ここではディスク容量の数え方、測り方、大きな項目を安全に見つける方法をまとめます。 ## ディスクは満杯なのに、ファイルの合計が合わない理由 最近の Mac は APFS ファイルシステムを使っており、APFS の空き容量の報告は Finder の表示と一致しません。ギガバイトを隠しているのは次の 2 種類です。 - **ローカルスナップショット。** Time Machine はバックアップの合間に、内蔵ディスク上の 時点スナップショットを保持します。すでに削除したファイルの領域も、スナップショットが 参照しているあいだは固定され、macOS が間引くまで解放されません。Apple によると、 時間単位のスナップショットは通常おおよそ 24 時間保持され、古くなるか空きが必要になると [自動的に削除されます](https://support.apple.com/102154)。一覧は次のコマンドです。 ``` tmutil listlocalsnapshots / ``` - **パージ可能領域。** APFS はキャッシュ、ローカルスナップショット、再ダウンロード可能な コンテンツをパージ可能とマークします。何かが領域を必要としたとき、macOS が自分で 回収する空きです。macOS はこれを利用可能として数え、Finder も利用可能の合計に 含めることがあります。手作業で確実に消すことはできません。 数字は次のコマンドで確認できます。 ``` df -h / diskutil apfs list diskutil apfs listSnapshots / ``` `df` はマウントされたファイルシステムが使う／空きとみなす量を報告します。 `diskutil apfs list` は共有コンテナ、そのボリューム、残り容量を示します。 `diskutil apfs listSnapshots /` は起動ボリュームに付いているスナップショットを一覧します。 Finder がディスクをファイルの説明より満杯に見せるときは、これらの表示で 通常のファイル使用とスナップショット・共有 APFS 容量を切り分けられます。 ## コマンドラインで実使用量を測る 重いフォルダを探すなら、`du`（disk usage）が中心です。ホームフォルダから： ``` du -sh ~/* ~/Library 2>/dev/null | sort -h ``` `-s` は項目ごとの要約、`-h` は人が読めるサイズ、`sort -h` へのパイプで 大きいものが最後になります。大きな結果を 1 つずつ掘り下げます。保護されたアプリデータには Terminal にフルディスクアクセスが必要なことがあり、クラウドフォルダや開発用ツリーを またぐホームフォルダの走査は時間がかかることがあります。 この数字は常に物理割り当てと一致するわけではありません。ハードリンクは同じ実体ファイルに 複数の名前を与え、APFS クローンはどちらかが変わるまでブロックを共有します。そのため フォルダ合計とコンテナの空きは、別の問いに答えることがあります。候補の特定に `du` を使い、 影響の大きい削除の前に Finder の情報を見る と APFS 容量表示で確認してください。 フォルダではなく個別の大きなファイルを探すなら、`find` でサイズを絞ります。 ``` find ~/Downloads ~/Movies ~/Desktop -type f -size +500M -print 2>/dev/null ``` ホーム全体ではなく、ユーザーが管理するフォルダから始めてください。このコマンドは 忘れた動画書き出し、ディスクイメージ、アーカイブを、すべてのアプリデータベースを 渡り歩かずに拾います。ルートの一覧は必要なときだけ広げます。 対話的なターミナルマップなら、`ncdu` で選んだフォルダをサイズ順に閲覧できます。 まずは読み取り専用の発見ツールとして扱い、候補を特定したら Finder で表示し、 `ncdu` 内の見慣れないツリーから直接消すのではなく、ゴミ箱へ移してください。 ## 見えない領域を取り戻す 問題が単一ファイルではなくスナップショットやパージ可能領域なら、 ユーザーが管理する実領域を先に空け、macOS がローカルスナップショットや パージ可能キャッシュを自動で老化・間引く余地を与えます。Time Machine ディスクを 再接続するとバックアップ履歴は増えますが、手作業のスナップショット削除コマンドではありません。 どちらの種類も、手で強制する必要はほとんどありません。 ## リストでは足りないときの視覚マップ
ディスク分析がディスク全体をツリーマップで示し、ライブラリが 155.84 GB で最大ブロックを占め、www、Downloads、その他のユーザフォルダが横に小さなブロックとして並びます
ディスク全体のツリーマップ： いちばん大きいフォルダがいちばん大きいブロックで、クリックでどれにも潜れます。Mole の Analyze 画面です。
ターミナル上のサイズは有用ですが、ディスク全体を頭に保持するのは難しいです。 ツリーマップは各フォルダをサイズに比例した矩形で描き、いちばん大きいものが いちばん大きいブロックになるので、どこに重みがあるか一目で分かります。 [Mole](https://mole.fit/) の Analyze 画面は、上のパス単位の走査のグラフィカルな対応物です。 ルートからディスク全体をマップし、クリックで掘り下げ、Finder で表示したり ゴミ箱へ送ったりできます（右クリックメニューから、サイズ確認つきで、ゴミ箱を空にするまで 復元可能）。ホームフォルダのようなナビゲーション用ルートには削除オプションがなく、 誤クリックで構造的なものを消すことはできません。好きな方を使ってください。 ツリーマップとコマンドは同じ問いに答えます。 ## 内部： ディスクアナライザが速く保たれる仕組み 空きを作るのにこの節は不要ですが、素直なスクリプトが這うのに、よいディスクマップが 秒で返る理由が気になったことがあるなら、形はこうです。例は [Mole のオープンソース コマンドラインツール](https://github.com/tw93/Mole)、 特に `cmd/analyze` の Go アナライザです。ネイティブアプリは別の Swift スキャナですが、 どちらも並行度を上限付きにし、ハードリンクを重複排除します。
Mole CLI のディスク分析はディレクトリを読み、境界付き作業をキューし、ファイルとフォルダを別経路で計測し、ハードリンクを重複排除し、最大結果をヒープに保持し、残った項目を描画します
CLI アナライザでは、キューが未処理作業を上限付きにし、別予算がディレクトリ歩行と du プロセスを抑え、ハードリンク重複排除が各バイトを一度だけ数え、Top-N ヒープが木全体のソートを避けます。
遅いやり方は分かりやすいものです。すべてのフォルダを歩き、すべてのファイルを `stat` し、 全部足してからソートする。数百万の小さなファイルがあるホームディレクトリでは、 遅くかつメモリを食います。スキャナは 3 つの考え方で両方の罠を避けます。 **上限はあるが、単一の上限ではない。** 素朴な並列はフォルダごとにゴルーチンを増やし、 ディスクを溶かします。スキャナはリソースごとに別予算を持ちます。ディレクトリワーカーの プール（2 から 12、コア数に合わせて拡大）、同時に最大 4 つのずっと小さな `du` サブプロセスのプール（`du` 自体がすでに I/O 並列なので、増やしてもディスクが スラッシングするだけ）、そして未処理作業が何千もの積み上がったゴルーチンに 膨らまないキュー上限です。これらを 1 つの上限に潰すと、ディスクツールは遅いか メモリ食いのどちらかになります。 **勝者だけ残す。** 欲しいのはいちばん大きいフォルダであって、全部ではありません。 だからスキャナはディスク全体をソートしません。測定した項目を 2 つの最小ヒープに 流し、一方は上位 30 フォルダ、もう一方は上位 20 ファイルを保持します。ヒープが 満杯のとき、新しい項目はいちばん小さな生存者と比較され、勝てなければ捨てます。 ファイル数に対しておおよそ線形で、メモリに持つのは数十件だけです。数百万件の ソートではありません。 **各バイトは一度だけ数える。** ハードリンクが複数あるファイルは、リンクごとに 足してしまいます。スキャナは各ファイルの `(device, inode)` ペアを初めて見たときに 記録し、以降はスキップします。合計が `du` と一致するのはこのためです。この重複排除に 依存したフォルダ合計はキャッシュすらしません。走査順に依存し、後の単独再走査を 汚染するからです。 どれも特殊な技ではありません。「ディスクを埋めているものは何か」に秒で答えるツールと、 答えないシェルループの差であり、上のツリーマップはまさにこのエンジンのフロントエンドです。 ## 削除する前に分類する 大きな項目を見つけたことは、削除の許可ではありません。候補を次の 3 つに分けます。 - **置き換え可能：** 検証済みのインストーラ、再現可能なビルド成果物、文書化された キャッシュ。削除前に再ダウンロードや再ビルドのコストを確認します。 - **個人または業務運用：** 写真、メッセージ、プロジェクトアーカイブ、仮想マシン ディスク、モデル重み、デバイスバックアップ。所有アプリ経由で書き出し、バックアップ、 または引退させます。 - **アプリ管理またはシステム管理：** パッケージデータベース、コンテナ、Photos や Mail の ライブラリ、スナップショット、`/System` 配下のすべて。アプリの操作を使うか、 触らないでください。 大きなフォルダがもう使っていないアプリのものなら、文書化されたアンインストーラに従い、 そのあと[残骸を確認](https://mole.fit/ja/blog/how-to-completely-uninstall-apps-on-mac)してください。 通常のファイルはまずゴミ箱へ移し、関係するアプリとプロジェクトが動くあいだは そのまま置いてください。ゴミ箱を空にするのが不可逆な一歩です。 単一の大きなファイルを超えた広いクリーンアップは、 [ファイルを失わずに空きを増やす方法](https://mole.fit/ja/blog/how-to-free-up-space-on-mac)を参照してください。 ## 繰り返し使える手順 まず `df`、APFS 容量、ストレージ設定を比べ、問題が実際の物理的な逼迫なのか 分類の問題なのかを把握します。次に選んだルートを測り、いちばん大きい枝を掘り下げ、 所有権と復元可能性で候補を分類します。置き換え可能なデータから消し、個人データは バックアップと所有アプリで扱い、通常の削除は結果を確認するまでゴミ箱で復元可能な 状態に保ちます。 --- Canonical HTML page: https://mole.fit/ja/blog/how-to-find-large-files-on-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt