Macで大きいファイルを探す｜容量を食っている場所から見る

mac 大きい ファイル 探す で調べはじめる場面は、たいてい容量の警告が出た直後です。ところが大きいファイルを1つずつ探して消しても、空きは思ったほど増えません。容量を食っているのは1本の巨大な動画ではなく、小さいファイルが何万件も溜まったフォルダであることが多いためです。この記事では、ファイル単位ではなくフォルダ単位から降りていく手順、空き容量の数字が画面と食い違う理由、見つかっても消してはいけないものの見分け方までを順に整理します。

先に見るのはファイルではなくフォルダ

容量が減った原因を探すとき、最初に「大きいファイルの一覧」を出すのは効率がよくありません。理由は2つあります。

ひとつは、大きいファイル1本を消しても効果が限られることです。手元の環境で調べると、開発用のディレクトリ1つが14GBを占めていても、その中に1GBを超える単体のファイルは1本も無い、という状態が普通に起きます。中身は数万件の小さいファイルで、1件ずつ消す対象にはなりません。

もうひとつは、消してよいかの判断がフォルダ単位でしか付かないことです。ファイル名だけを並べた一覧には、それが何に使われているかの情報がありません。置かれている場所が分かれば、キャッシュなのか、書き出した中間ファイルなのか、消してはいけない書類なのかが判断できます。

したがって手順は、上から順に大きいフォルダへ降りていく形になります。ディスク全体で最も容量を食っているフォルダを特定し、その中で最も大きい子フォルダへ進み、これを繰り返して原因の場所まで辿ります。一覧を眺めて当たりを付けるのではなく、必ず分岐の大きいほうへ進むので、階層が深くても数回の操作で行き着きます。

空き容量の数字が画面と合わないことがある

原因を探す前に、いま何GB空いているのかを確定させます。ここで最初の落とし穴があります。

df -h /

この1行で返るのは、macOSの起動ボリュームのうち読み出し専用のシステム側の使用量です。手元の環境では使用量13GBと返り、ディスクが空いているように見えます。実際に書類やアプリのデータが入っているのは別のボリュームで、そちらを指定すると数字が変わります。

df -h /System/Volumes/Data

同じ時点でこちらは使用率98%と返りました。APFSでは起動ディスクが複数のボリュームに分かれていて、両者が同じ空き容量を共有しています。/ だけを見て「空いている」と判断すると、原因を探す前提から間違えます。

さらにもう1段、パージ可能領域という考え方があります。Time Machineのローカルスナップショットやキャッシュのように、空きが必要になったときにmacOSが自動で解放する分です。Finderの情報ウインドウとターミナルの数字が食い違う原因はここにあることが多く、この分を人が急いで消しに行く必要はありません。判断の順序としては、まずデータ側のボリュームの使用率を確定させ、次に解放されない実体を探します。

ターミナルで容量を食っている場所を降りる

フォルダ単位の容量は du で出します。全部を表示すると読めないので、深さと閾値を指定します。

du -h -d 1 -t 500M ~/ | sort -h

-d 1 は1段下までの集計、-t 500M は500MB未満を表示しない指定、sort -h は単位付きの数字を小さい順に並べ替える指定です。macOSの sort は -h を持っているので、KやMやGが混ざった出力をそのまま並べ替えられます。表示された中で最も大きいフォルダを次の起点にして、同じ1行を繰り返します。

閾値は環境に合わせて動かします。ホーム直下を見るときは500MB、深い階層に降りたら100MBのように下げると、分岐が見えます。閾値を付けずに走らせると、数千行が流れて読めなくなるうえ、集計そのものに時間がかかります。上限を決めて表示を絞るほうが、結果として原因に早く着きます。

du が返す数字は、ファイルの中身の大きさではなくディスク上で占めている領域です。小さいファイルが何万件もあるフォルダでは、1件ごとの最小単位の積み上がりで、中身の合計より大きく出ることがあります。中身の大きさで比べたいときは -A を足しますが、空きを増やす目的で見るなら既定のままのほうが実態に合っています。

権限のないディレクトリに当たると1行ずつエラーが流れるので、読みにくいときは 2>/dev/null を足します。捨てているのはエラーだけで、集計の結果は残ります。ただしシステム領域を含めて調べたい場合、権限の無い場所は集計から抜け落ちるので、合計が実際より小さく出ることは頭に入れておきます。

別のボリュームを巻き込みたくないときは -x を足します。外付けディスクやネットワーク共有をマウントしたまま du を走らせると、そちらまで集計して戻ってこなくなります。

ファイル単位で大きいものを並べる

フォルダで原因の場所まで辿り着いたら、そこから先はファイル単位で見ます。

find ~/Movies -type f -size +1G -exec du -h {} + | sort -h

-size の単位は後ろに付けます。c がバイト、k がキロバイト、M がメガバイト、G がギガバイトです。単位を書き忘れると512バイト単位のブロック数として解釈されるので、意図しない結果になります。-exec ... {} + の形にすると、見つかったものをまとめて du に渡すので、件数が多くても速く済みます。

索引を引く道具も使えます。

mdfind "kMDItemFSSize > 1073741824"

こちらはSpotlightの索引から1GBを超えるファイルを即座に返します。索引に入っているものだけが対象なので、索引を切ったボリュームや索引の対象外のディレクトリは出てきません。速さが要るときはこちら、確実さが要るときは find、という使い分けになります。

Finderで探す場合は、検索窓に文字を打つのではなく条件を使います。検索を開いてから「検索条件を表示」で行を足し、その他の項目から「ファイルサイズ」を選ぶと、大きさで絞った一覧になります。検索の範囲を「このMac」にしないとフォルダの中だけを見に行くので、先に範囲を確かめます。

溜まる場所には型がある

どのMacでも上位に来るフォルダは、ほぼ決まった型に収まります。原因を探す前に候補を知っておくと、降りる回数が減ります。

• ダウンロードフォルダ。受け取ったものを開いて用が済んでも、元のファイルは残り続けます。インストーラのディスクイメージが何十個も溜まっていることがあります
• 書き出し先に指定したフォルダ。動画や画像の書き出しは、同じ素材から何度も作り直すので、世代が積み上がります
• 開発用のディレクトリ。依存ライブラリと中間生成物が大半を占めます。消しても作り直せる性質のものですが、件数が万単位になるため削除自体に時間がかかります
• メールアプリが持つ添付の控え。送受信したものの実体が手元に残ります
• 仮想マシンやコンテナのディスクイメージ。1本で数十GBになり、中で削除しても外側のファイルは縮まないことがあります

このうち、消して効果が続くのは書き出し先とダウンロードフォルダです。開発用のディレクトリは作り直されるので、一度の削除では空きが戻りません。仮想マシンのイメージは、中で消すのではなく、外側の圧縮や再作成が必要になります。型が分かっていれば、du の結果に出たパスを見た時点で、消す価値があるかどうかの見当が付きます。

見つかっても消せないもの、消してはいけないもの

大きいファイルの一覧に出てくるもののうち、そのまま捨ててよいものは限られます。

Time Machineのローカルスナップショットは、バックアップ先が繋がっていない間も手元に取られます。実体の場所はFinderからは見えず、一覧にも現れません。存在を確かめるには次の1行です。

tmutil listlocalsnapshots /

アプリが作業用に持っている中間ファイルも、一覧の上位に来ます。書き出しの途中で作られたものは、本人が作ったつもりがないまま置かれ続けます。

本来なら、ここで大きいファイルが表示されているはずでしたが、問題になっているファイルが大き過ぎたのか、なぜか表示されていませんでした。 出典: syobochim.hatenablog.com

画面に用意されている一覧に必ず出てくるとは限らないため、ターミナル側からも確かめる価値があります。写真やビデオのライブラリは、見た目は1つの巨大なファイルですが、中身は多数の実体を束ねた入れ物です。これを直接消すと、アプリ側から見た管理情報ごと失われます。容量を減らすなら、アプリを開いて中身を整理する順序になります。

アプリのキャッシュも同様で、消しても動作はしますが、次に開いたときに作り直されるので空きは戻りません。減らす効果が続くのは、作り直されない実体のほうです。

同じ調べ方を次回のために残す

容量の調査は一度で終わりません。3か月後にまた同じことを調べるので、調べ方そのものを残しておく価値があります。

残す形は2つあります。ひとつは、閾値と深さまで決め打ちにした du の1行をシェルの別名として登録しておくこと。打ち直す回数が減るぶん、単位の書き忘れのような間違いも減ります。もうひとつは、そのときの集計結果をファイルに落としておくことです。

du -h -d 2 -t 100M ~/ 2>/dev/null | sort -h > ~/Desktop/usage-2026-09-26.txt

日付を入れた名前で保存しておけば、次に調べたときの結果と並べて差が見えます。どのフォルダが増えているのかが分かると、消す対象ではなく増える元を止める判断に移れます。容量が足りない状態は、一度の削除では解決せず、増える速さを下げたときだけ落ち着きます。

消す前に確かめる3つの順序

削除は戻せないので、順序を決めておきます。

• 何に使われているかを先に確かめる。パスの親をたどって、どのアプリやどの作業のものかを特定する
• 消す前に一度、別の場所へ移してしばらく様子を見る。動かなくなるものがあれば戻せます
• 同じものが増え続けるなら、1回消すのではなく作られる元を止める。書き出し先の設定や、自動で溜まる保存先を見直す

この3つを飛ばして一覧の上から消すと、同じ作業を1か月後に繰り返すことになります。容量の問題は、1回の掃除ではなく、増える速さのほうが本質です。増える速さが分からないときは、同じ du の1行を日を空けて2回走らせ、差を見ます。

探すたびに窓を3つ開いている

容量を調べる作業は、道具が分かれているせいで手数が増えます。

実際の流れはこうなります。Finderで空き容量を見て少ないことに気づく。ターミナルへ切り替えて du を走らせる。出てきたパスをコピーしてFinderへ戻り、中身を目で確かめる。消してよいか判断が付かないので、また別の窓でAIに相談する。1つのフォルダを判断するだけで、窓の切り替えが4回入ります。

階層を降りるたびにこれが繰り返されるので、実際に時間を使っているのはコマンドの実行ではなく行き来のほうです。フォルダとターミナルとAIが同じ窓にある状態なら、集計の結果に出たパスをそのまま開いて中身を確かめ、その場で判断まで進められます。この構成で何ができるかはできることに、Finderや他の道具との違いは他のファイル管理との比較にまとめてあります。費用の目安は料金にあります。

まず変えるとよいのは2点です。ひとつは、ファイルの一覧から入るのをやめて du -h -d 1 -t 500M でフォルダから降りること。もうひとつは、空き容量の確認を / ではなくデータ側のボリュームで行うことです。この2つを先に決めておけば、どこを消すかの判断は速くなります。