追加のソフトを入れずにMacで重複ファイルを見つける方法は？

ハッシュ値を取ってまとめるのが確実である。`find . -type f -size +1M -exec shasum -a 256 {} +`を実行するとファイルごとのハッシュ値が並び、並べ替えると中身が同じものが隣り合う。結果はテキストに書き出し、読んでから消す。写真は例外で、写真アプリのサイドバーにある「ユーティリティ」の「重複項目」を使うほうが安全である。

重複したファイルは、どちらを残せばよい？

他から参照されている側を残す。プロジェクトの中にあるもの、リポジトリの中にあるもの、他の人と共有しているフォルダの中にあるものが該当する。日付では決めない。通常のコピーでは新しい日時が入るため、日付が新しいほうは改良版ではなく控えであることが多い。

名前に「conflicted copy」が入ったファイルは消してよい？

まとめて消してはいけない。競合コピーは、同期される前に2か所で同じファイルを編集したときに作られるもので、片方にしか無い編集が入っている。両方を開いて違いを手で突き合わせ、不要になったほうだけを削除する。

片付けても重複がまた増えるのはなぜ？

作られる仕組みを変えていないためである。同じファイルの落とし直し、放置された同期の競合、写真の取り込み直し、作業前のフォルダ複製が、それぞれのペースで新しい重複を作り続ける。ダウンロードフォルダを週に1回空にし、同期の競合を見つけた日に片付けるだけで、流入の大半は止まる。

Macの重複ファイルは、どちらを残すかで決まる

Macの重複ファイルの話は、たいてい順番が逆になっている。検出ソフトを入れ、一覧を出し、全選択して消す、という流れでは、一番難しい判断が手つかずのまま残る。中身がまったく同じ2つのファイルがあったとき、どちらが「控え」で、どちらが他の作業から参照されている本体なのか、という判断である。ここを外すと、重複を残す損失（ディスク容量）よりはるかに大きい損失（作り直しになる書類、切れたリンク、1か所にしか無かった写真）が出る。ここでは、何をもって一致と呼ぶかを決め、どこから重複が湧いてくるのかを押さえ、その上で消す手順に進む。

「重複」と呼ばれているものは、性質の違う4種類

重複判定には4つの基準があり、どの道具もこのうち1つを採用している。どれを使っているかが分かると、誤検出も取りこぼしも説明がつく。

判定基準	拾えるもの	誤って拾う・取りこぼすもの
名前が同じ	別フォルダに散った複製	無関係なプロジェクトの`index.html`や`IMG_0001.JPG`を大量に拾う
名前とサイズが同じ	フォルダごと複製したもの	名前が変わった`資料 (1).pdf`を取りこぼす
中身が完全に同じ	名前に関係なく本当の重複	書き出し直したもの、圧縮し直したものは別扱いになる
見た目や音が似ている	解像度違いで取り込み直した写真	意図して残した切り抜き違いまで候補に挙げる

名前一致は最も速く、最も当てにならない。開発用のフォルダで同名ファイルを探すと結果が数百件出るが、それらはすべて正しく検出されており、同時にすべて無意味である。ビルドの仕組みやフレームワークは、同じ名前のファイルが別の場所にあることを前提に動いているためである。

中身の一致（ハッシュ値の一致）だけが、確信を持って削除できる基準になる。ハッシュが同じ2つのファイルは入れ替えても結果が変わらない。弱点は書き出しに弱いことで、画質を変えて保存した写真、投稿用に再エンコードした動画、2回PDFに書き出した書類は、人から見れば同じ内容だがハッシュ値としては完全な別物になる。

似ているかどうかの判定は反対の性質を持つ。同じ写真を解像度違いで持っているケースを拾える唯一の基準だが、結果を一覧の文字だけで検証できない。1秒違いで撮った2枚を意図して残しているのか、取り込み直しただけなのかは、プレビューを並べないと分からない。似ている判定の結果は、行として処理せず、画像として見比べる前提で扱う。

Macで重複が生まれる経路は5つに絞れる

重複はランダムに増えない。日常的に使っているMacでは、発生源はほぼ次の5つで、それぞれ痕跡の形が違う。

ブラウザのダウンロード。同じファイルを2回落としても上書きされず、請求書-2.pdfや請求書 (1).pdfになる。ダウンロードフォルダに番号付きの連なりが溜まるのはこれが理由
クラウド同期の競合。2台の端末で同期前に同じファイルを編集すると、両方が残されて片方の名前が変わる。Dropboxでは名前に「conflicted copy」と日付が入る。この種類は最も価値が高い。片方にしか無い編集が含まれており、まとめて消すと作業が消える
手作業の版の連なり。企画.docx、企画-v2.docx、企画-最終.docx、企画-最終2.docx。中身が違うのでハッシュ上は重複ではないが、実際に要るのは最後の1本だけで、残りは念のため残っているだけである
写真やカードの取り込み。同じSDカードや同じ共有アルバムを2回取り込むと、別のファイル名で中身が同じ画像が並ぶ
作業前のフォルダ複製。危ない整理をする前にプロジェクトのコピーやデスクトップ旧を丸ごと作る。容量としては最大の発生源で、同時に一番片付けやすい。複製した時点でツリー全体が一致していたかどうか、という1つの問いに還元できる

一覧をサイズ順ではなく発生源ごとに並べ直すと、数百行が5つの判断に縮む。発生源はパスを見れば分かる。番号付きはダウンロードフォルダ、競合コピーは同期フォルダ、版の連なりは作業中の書類の隣、取り込みは日付付きのフォルダ、作業前の複製は元フォルダの1つ上の階層にある。

日本語のファイル名は、同じに見えて一致しないことがある

日本語環境で名前を基準に重複を探すときは、濁点と半濁点の扱いを知っておく必要がある。「が」という文字には、1文字として保存する形（NFC）と、「か」と濁点の2文字に分けて保存する形（NFD）の2通りがあり、画面ではどちらも同じに見える。

現在のMacの標準であるAPFSは、この2つを同じ名前として扱う。実際に同じフォルダでNFCとNFDの同名ファイルを作ろうとすると、別のファイルにはならず既存のファイルと衝突する。Finderの中で作業している限り、問題は表に出ない。

表に出るのは外へ出したときである。文字列そのものは書かれた形のまま保存されるため、外付けドライブのexFATやNAS上、ZIPの中身、スクリプトでの文字列比較では別物として扱われる。macOSで作ったZIPをWindowsで開くと濁点が分かれて見えることがあるのはこのためで、その状態でMacとWindowsの両方にあるファイルを名前で突き合わせると、同じファイルが「片方にしか無い」と判定される。

名前で重複を探して結果が腑に落ちないときは、中身のハッシュ値で取り直すのが早い。ハッシュは名前の表現方法の影響を受けない。

同じ理由で、日本語のファイル名を含むフォルダをlsやfindの結果として並べ替えると、見た目が同じ名前が離れた位置に来ることがある。並び順が不自然なときは名前の壊れではなく表現の違いを疑う。どうしても表記をそろえたい場合は、外へ渡す前に名前を一括で付け直しておくと、受け取った側での突き合わせが楽になる。重複の整理と命名の整理が同じ作業に見えるのは、この点で実際につながっているためである。

写真は標準機能に任せたほうが安全

画像はハッシュ値での比較が効きにくく、写真アプリのライブラリはパッケージなので中を直接触ると壊れる。ここだけは標準機能が最適解になる。

重複する写真やビデオをライブラリから簡単に削除できます。ライブラリに重複した写真やビデオがある場合は、「ユーティリティ」の「重複項目」コレクションに自動的に表示されます。出典: support.apple.com

この機能は削除ではなく結合で、画質の高いほうと付随する情報を残す。結合したものは「最近削除した項目」に入り、30日以内なら戻せる。取り消せる操作から先に片付けるのが手順として正しい。

ここで注意したいのは、ライブラリの中のファイルをFinderやターミナルから直接消してはいけないという点である。写真アプリのライブラリは1つのパッケージとして扱われており、中の画像だけを抜くとライブラリ側の管理情報と食い違って壊れる。容量を空けたい場面ほど中を開きたくなるが、開いた時点で失敗している。ライブラリの中身は写真アプリの操作でだけ動かす、と決めておくとよい。取り込み元のSDカードやダウンロードした画像のフォルダは、ライブラリの外にあるので通常のファイルとして扱える。

日付が新しいほうが原本とは限らない

同じ中身の2つを前にしたとき、新しいほうを残したくなる。Macではその判断が逆になることのほうが多い。

普通のcpでコピーすると、コピー先には現在時刻が入る。元のファイルは自分の更新日時を保ったままである。つまり1月に最後に編集したファイルをコピーすると、コピーのほうが今日の日付になり、元のファイルは1月のままになる。日付順に並べて新しいほうを残すと、控えを残して本体を消すことになる。

$ touch -t 202601010000 a.txt
$ cp a.txt c.txt      # 日時は今日になる
$ cp -p a.txt d.txt   # 日時が保たれる
$ stat -f "%N mtime=%Sm" a.txt c.txt d.txt
a.txt mtime=Jan  1 00:00:00 2026
c.txt mtime=Sep  4 23:41:54 2026
d.txt mtime=Jan  1 00:00:00 2026

-pを付けると元の日時が保たれる。rsync -aで運んだファイルやバックアップから戻したファイルが本来の日付を保っているのに、Finderでドラッグしたファイルが今日の日付になるのはこの違いによる。ダウンロードも同じで、書かれた時期に関係なく落とした日の日付が入るため、落とし直したファイルは常に手元の版より新しく見える。

日付が意味を持つのは競合コピーだけである。名前に入っている日付は競合が起きた時刻であり、編集の時刻ではない。どちらを残すかではなく、どちらを開いて確かめるかを示すものとして読む。

一覧を作ってから消す

安全な進め方は、削除の前に読める一覧を作ることである。1MBより大きいファイルに絞ってハッシュ値を取り、値でまとめると、並べ替えて検討できる形になる。

find . -type f -size +1M -exec shasum -a 256 {} + | sort > /tmp/hashes.txt
awk '{ if ($1 == prev) print; prev = $1 }' /tmp/hashes.txt

命令の細部より、結果をファイルに書き出すことのほうが重要である。テキストになっていれば親フォルダ順に並べ替えられる。同じファイルが10か所に散っている一覧は判断が難しいが、そのうち9つがデスクトップ旧の下にあると分かれば、判断は1回で済む。サイズの下限を付けるのも効く。小さいファイルまで全部計算すると時間がかかるうえ、消しても容量が変わらない一致で一覧が埋まる。

消す前に、いったん隔離する段を挟むと事故が減る。削除ではなく、日付を付けた1つのフォルダへまとめて移し、1週間置いてから中身を消す。この期間に何かが壊れれば、壊れたという事実そのものが「参照されていた側を消した」という答えになる。ターミナルのrmはゴミ箱を経由せず、取り消す手段が無いので、一覧から直接削除につなげない。移動ならmvで戻せる。

残す1本の決め方は、ファイルそのものではなく置かれている場所で決まる。他から参照されているもの（プロジェクトの中、リポジトリの中、他の人と共有しているフォルダの中）が残る。参照は1つのパスしか指せないので、それ以外は定義上参照されていない。ダウンロード、デスクトップ、書類フォルダの直下は受け皿であり、そこから出て所定の場所に入っているほうが、すでに片付けが済んでいる側である。競合コピーだけは例外で、両方を開いて手で突き合わせてから片方を消す。

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

この作業で時間を食うのは、判定そのものではなく画面の切り替えである。ハッシュ値はターミナルで出て、中身の確認はフォルダの画面で行い、消す操作はまた別の場所になる。往復が増えるほど「後でやる」に流れ、重複は次の四半期まで残る。フォルダとターミナルとAIが同じ窓にある状態なら、一覧を出してからプレビューで確かめて隔離するまでが同じ画面で完結する。

道具として何がどこまでできるのかはできることに整理してある。重複の検出だけを行う専用ソフトと、ファイル管理そのものを引き受ける道具では解いている問題が違うので、その差は他のファイル管理との比較を見たほうが早い。費用の条件は料金にまとめてある。

閲覧のされ方を見ると、重複の記事を読んだ人が次に進むのは、容量の話ではなくファイル名の一括変更と整理の記事であることが多い。重複が増える原因が命名と置き場所の決めごとの弱さにある、という見立てと合っている。消す作業を繰り返すより、発生源を1つずつ塞ぐほうが結果的に短い。

塞ぎ方は難しくない。ブラウザの保存先を毎回聞く設定にするか、週に1回空にするフォルダに固定する。同期の競合はその日のうちに片付ける。数か月後に見つけた競合コピーは、どちらの段落が正しかったかを誰も覚えていないので、もう突き合わせられない。作業前の「念のため」の複製は、期限の無い控えとして残り続けるため、後から消す判断が付かなくなる。Time Machineが同じ役割をすでに果たしていることを思い出せば、その複製は作った日の時点で要らない。導入後に出やすい疑問はよくある質問にまとめてある。