mac 不要なファイル検索の前に｜消していいファイルを見分ける基準

起動ディスクの空きが二桁ギガを切って、まず思いつくのが重複ファイルの削除です。ところが mac 不要なファイル検索と打って出てくる道具を入れて走らせても、削除の候補が数千件並ぶだけで、どれを消していいのかは結局判断がつきません。問題は検出の精度ではなく、判断の基準を決めていないことにあります。この記事では、Macの容量が実際にどこへ消えているのかを分解したうえで、標準機能とターミナルと無料の道具をどう使い分けるか、そして何に触ってはいけないかを順に整理します。

「不要なファイル」は性質の違う3種類が混ざっている

削除の候補を1つの山として扱うと、必ず手が止まります。実際には性質のまったく違う3種類が混ざっているためです。

• 複製されたもの。同じ内容のファイルが別の場所に2つ以上ある状態。写真の書き出し、メール添付の保存、プロジェクトフォルダごとのコピーで増える
• 再生成できるもの。消しても手順を踏めば元に戻せるもの。ビルドの中間生成物、パッケージマネージャの取得済みファイル、キャッシュ、書き出し済みの動画
• もう参照されないもの。終わった案件の素材、使わなくなったアプリ、古いバックアップ、対応が終わったフォーマットのファイル

この3つは、判断にかかるコストがまったく違います。再生成できるものは、消して困ったら作り直せばよいので判断が要りません。参照されないものは、日付と案件名だけで機械的に切れます。判断に時間がかかるのは複製の山だけで、しかも複製は容量の削減効果が最も小さいことが多い。3種類のうち、最初に手を付けるべきなのは複製ではなく、再生成できるものです。

開発の環境が入っているMacなら、この分類だけで景色が変わります。ビルドの中間生成物、コンテナのイメージ、依存パッケージの実体は、どれも数ギガから数十ギガの単位になり、しかも設定ファイルさえ残っていればコマンド1つで戻せます。写真の重複を1件ずつ確認していく前に、こちらを先に片付けたほうが労力あたりの回収量ははるかに大きくなります。

重複を消しても容量が減らないことがある

重複検出の道具を信用しすぎると、必ずここでつまずきます。ファイルが2つあるからといって、ディスクを2倍使っているとは限らないためです。

現在のMacの標準的なファイルシステムであるAPFSには、ファイルの複製を作るときに中身をコピーしない仕組みがあります。ファインダで複製したり、cp -c を使って複製したりした場合、実体は1つのまま、参照だけが増えます。中身に変更を加えた部分だけが後から実際に書き込まれる方式です。この状態のファイルは、内容の照合でも名前の照合でも「重複」として検出されますが、片方を消しても解放される容量はほぼゼロになります。

ハードリンクも同じ結果になります。Time Machineのローカルスナップショットや、一部のバックアップの仕組みが作る参照は、見た目には別のファイルとして並びます。

もう1つ、削除しても空きが増えない代表的な原因がゴミ箱です。Appleのサポートページははっきり書いています。

ゴミ箱は空にしてください。ファイルをゴミ箱に移動しても、ゴミ箱を空にしない限り、そのファイルが使っているストレージ容量は解放されません。 出典: support.apple.com

スナップショットも同様で、削除したはずのデータがしばらく保持され続けます。ディスクユーティリティやファインダが表示する空き容量に「パージ可能」という区分が出るのはこのためです。削除した直後に空きが増えないからといって、道具が壊れているわけではありません。

つまり、重複の検出結果は容量の削減量の見積もりにはなりません。実際に効いたかどうかは、削除の前後でストレージの表示を見比べて判断します。

ストレージの内訳を先に読む

道具を入れる前に、システム設定を開いて内訳を見ておきます。Appleメニューからシステム設定を選び、サイドバーの一般からストレージに入ると、カテゴリごとの使用量が並びます。カテゴリの横に詳細情報のボタンが出ていれば、そこから中身の一覧まで進めます。

ここで多くの人が引っかかるのが「システムデータ」という区分です。Appleの説明では、ほかの特定のカテゴリに当てはまらないAppleと他社のファイル全体を指す一般的なカテゴリだとされています。つまりこれは1つの場所ではなく、行き場のなかったものの寄せ集めです。ログ、キャッシュ、仮想マシンのイメージ、コンテナのデータ、アプリが専用の領域に置いた作業ファイルが全部ここに入ります。この区分が50GBを超えているなら、探すべきは写真の重複ではありません。

内訳を読むときの見方は単純です。上位3つのカテゴリで全体の大半を占めているはずなので、そこだけを相手にします。書類が最大なら重複と大きなファイルの検出が効きますし、システムデータが最大なら開発環境とアプリの作業領域を疑う。この判断を先にしておかないと、削除の道具が出す数千件の候補の中から、効かない側を選び続けることになります。

iCloudへ退避させる選択肢を検討するなら、有料の容量が必要になる点も先に確認しておきます。同じページによれば、iCloudストレージは月々150円の50GBプランから用意されています。ローカルの空きを増やす手段としては有効ですが、無料で完結する話ではありません。

macOSに最初から入っている重複の見つけ方

追加のアプリを入れなくても、種類が限定されていれば標準機能で足ります。

写真については、macOS Ventura 13以降の写真アプリに重複した項目を集めるアルバムがあります。完全に同じファイルだけでなく、書き出しのサイズが違うだけの組み合わせも拾い、結合すると解像度やメタデータの情報量が多いほうを残してくれます。写真が容量の上位に来ているなら、他の道具を試す前にここを見る価値があります。

音楽のライブラリは、ミュージックアプリのメニューから重複した項目を表示できます。同じ曲名と演奏者の組み合わせを一覧にする機能で、optionキーを押しながら選ぶと、完全に一致するものだけに絞り込めます。

ファインダのスマートフォルダは、条件を保存した検索窓として使えます。「サイズが100MBより大きい」「最後に開いた日が1年より前」といった条件を組み合わせて保存しておくと、掃除のたびに同じ条件を打ち直さずに済みます。ただしスマートフォルダは内容の同一性を判定できません。名前とサイズと日付の一致までが限界で、それ以上は別の手段が必要になります。

ダウンロードフォルダは、条件を考えるまでもなく最初に見る場所です。インストーラの入っていたディスクイメージ、展開済みのzipファイル、同じファイルの連番が付いた再ダウンロード分が溜まります。ここは中身を1件ずつ判断せず、日付で古い順に並べて機械的に処理してかまいません。

ターミナルで重複と大物を数える

標準のコマンドだけで、重複の検出と大きなファイルの特定は済みます。追加の道具を入れるかどうかは、この結果を見てから決めれば十分です。

大きなファイルを探すなら、find ~ -type f -size +500M のようにサイズの下限を指定します。ディレクトリ単位で見たいときは du -sh */ を目的のフォルダで実行して、sort -h に通します。これで、どのフォルダが容量を持っているかが1画面で分かります。

内容が同一かどうかの判定には、ハッシュを使います。find . -type f -size +1M -exec shasum {} + で対象のハッシュを一覧にし、ハッシュの列だけを sort して uniq -d に通せば、同じ内容を持つ組み合わせが残ります。サイズの下限を先に入れておくのが要点で、小さなファイルまで対象にすると計算に時間がかかるうえ、消しても容量に響きません。

索引を使う検索も併用できます。macOSに付属する mdfind のマニュアルページには、次のように書かれています。

The mdfind command consults the central metadata store and returns a list of files that match the given metadata query. The query can be a string or a query expression. 出典: macOSに付属する mdfind(1) のマニュアルページ

索引を引くため結果が速く返り、-onlyin で範囲を絞れます。ただし索引に入っていないもの、たとえば検索のプライバシーに登録されたフォルダや、索引が無効な外付けディスクの中身は出てきません。網羅性が要る場面では find を、速さが要る場面では mdfind を使う、という分け方になります。

削除まで一気に流すのは避けます。-delete や xargs rm を試す前に、候補を一度テキストファイルに書き出して、目で読んでから実行する。ターミナルからの削除はゴミ箱を経由しないため、取り消しがききません。

無料で使える道具の違い

追加の道具が要ると判断した場合、無料で使えるものだけでも用途は分かれます。

道具	費用	得意なこと	苦手なこと
dupeGuru	無料のオープンソース	内容とファイル名の両方での重複検出、音楽と写真の専用モード	容量の全体像の把握
GrandPerspective	無料のオープンソース	使用量を面積で表示して大物を見つける	重複の判定
OmniDiskSweeper	無料	フォルダを容量順に降りていく操作	重複の判定
shasum と find の組み合わせ	標準搭載	条件を細かく指定した抽出	結果を目で確認する作業

選ぶ基準は機能の多さではありません。いま自分が答えたい問いが「同じものが何個あるか」なのか「どこが重いのか」なのかで決まります。内訳を読んだ結果、書類が最大なら前者、システムデータが最大なら後者です。

Homebrewを使っているなら、jdupes や rmlint のようなコマンド行の道具も選択肢に入ります。どちらもハードリンクへの置き換えや、除外条件の指定に対応していて、同じ処理を毎月繰り返すような使い方に向いています。ただし削除の自動化は、判断の基準が固まってから最後に導入するものです。基準がないまま自動化すると、消してはいけないものを速く消せるようになるだけです。

触ってはいけない場所と、消してよい場所

削除の事故は、たいてい同じ場所で起きます。

避けるべきなのは、ホームフォルダの中のライブラリフォルダです。アプリの設定、鍵、ライセンス、メールの実体がここにあります。中に大きなファイルが並んでいても、名前から用途が読めないものは触らないでおきます。写真のライブラリも同様で、パッケージの中身を直接開いて個別のファイルを消すと、ライブラリごと壊れます。バージョン管理下のリポジトリにある .git のディレクトリも、履歴そのものなので削除の対象外です。

逆に、消してよいと判断しやすいものもあります。Xcodeを使っているならDerivedDataの中身は中間生成物で、消してもビルドし直せば再生成されます。JavaScriptのプロジェクトにあるnode_modulesも、設定ファイルが残っていれば復元できます。Homebrewの取得済みファイルは brew cleanup で整理でき、Dockerを使っているなら docker system df で使用量を確認してから不要なイメージを落とせます。どれも「消しても手順で戻せるか」という1つの基準で判断できます。

判断に迷うものは、その場で消さずに隔離します。デスクトップに退避用のフォルダを1つ作って移し、日付を名前に入れておく。2週間使わずに済んだものは、そのまま消して問題ありません。これは容量が逼迫している場面では使えませんが、ふだんの掃除では最も安全な手順です。

探す作業と消す作業の間で時間が消えている

掃除が終わらない本当の理由は、検出の精度ではありません。検出した後の往復にあります。

流れを追うと形が見えます。ターミナルでハッシュを取って候補の一覧が出る。中身を目で確かめたいのでファインダに切り替え、パスを貼り付けてフォルダを開く。判断して戻り、また次の候補を開く。1件あたりは数秒ですが、候補が300件あれば、その数秒が全部積み上がります。逆にファインダで大きなファイルを見つけたときは、それをコマンドで処理するためにパスをコピーして窓を移る必要があります。

ここで効くのが、フォルダとターミナルとAIが同じ窓にあるという配置です。一覧を見ている場所とコマンドを打つ場所が同じ作業ディレクトリを共有していれば、パスのコピーと窓の切り替えがまるごと消えます。この配置で何ができるのかはできることに整理されていて、2画面型やターミナル常駐型など別の課題を解いている道具との違いは他のファイル管理との比較で比べられます。導入前に費用を確かめたい場合は料金に条件が書かれています。

道具を替える前に、次の掃除で回数を数えることをすすめます。候補を目で確かめるために窓を切り替えた回数が10回程度なら、この記事の前半で挙げた分類と標準機能だけで足ります。数十回を超えているなら、それは検出の問題ではなく配置の問題です。