重複ファイルの整理: how to decide what you need

A folder holds report.pdf, report-1.pdf, and report copy 2.pdf. The external drive probably holds the same three. Searching for 重複ファイルの整理 erabikata usually starts at that screen, with the assumption that the missing piece is a tool. It is not. The missing piece is a set of four decisions, and every tool on the market assumes you have already made them: what the duplicates are costing you, how a copy is recognised, which side survives, and how far the deletion can be undone. Make those decisions and the tool choice takes ten minutes. Skip them and any tool stalls at the same point, with a list of four thousand candidates and no rule for clearing it.

Start from the cost, not the count

Three different problems get called duplicate files, and they pull in different directions.

The first is disk space. The second is retrieval, where a search returns the same document name five times and none of them is obviously current. The third is accuracy, where the risk is attaching the wrong version of a contract to an email.

Only the first cares about file size. If the goal is free space, the entire result set below a few megabytes is noise, no matter how many thousands of entries it contains. Ten thousand duplicated text files move the free space number by almost nothing, while three copies of a video export move it by more than the rest of the scan combined. If the goal is retrieval, size is irrelevant and the scan should be pointed at the folders you search daily, which are usually small.

The accuracy case is different again. There, deleting nothing may be the right answer. What fixes it is a single location that is defined as authoritative, so that every other copy is understood to be disposable by definition. That is a filing decision, not a scanning decision, and no duplicate finder produces it for you.

Write the goal down in one line before looking at any product page. Free 200 GB on the external drive. Stop seeing three versions of the invoice in search results. The line decides which of the next four sections actually matter to you, and it is short enough that you will not argue with it later.

How the copy was made decides how it can be found

Detection methods are usually presented as a feature list. They are easier to choose between when they are mapped against the way the copies got there in the first place.

How the copy appeared	Byte identical	Found by name	Found by hash	Found by visual similarity
Finder duplicate, or a drag to a second drive	Yes	Often, if the suffix survived	Yes	Yes
Downloaded twice from the same link	Yes	Usually	Yes	Yes
Exported again at a different size or quality	No	Rarely	No	Yes
Same photo imported from two devices	Usually	Rarely, the numbering collides	Yes	Yes
Saved as a new version after an edit	No	Sometimes	No	Only for images
Sync conflict copy from a cloud service	Yes	Yes, the name carries a marker	Yes	Yes

The practical reading of that table is that hashing covers most of the ways files get duplicated by accident, and misses exactly one common case: the same image exported more than once. Visual similarity covers that case and nothing else, and it brings a class of error the other methods do not have, because two photographs taken a second apart are genuinely similar and genuinely different.

Name matching is fast and almost never worth trusting on its own. Camera numbering guarantees collisions across devices, and Japanese filenames add a second trap, since the same characters can be stored in two different normal forms and compare as unequal even though the screen shows the same text. If the library is bilingual, check how a candidate tool handles that before trusting a name based result. A vendor that documents which locales the product was built against is telling you something the feature list does not.

The keeper rule is the part that gets skipped

Finding duplicates is the easy half. The list arrives, every row has two or three paths, and the work of deciding which path survives begins. Done by hand at five seconds per row, a modest result set is a full afternoon, which is why most cleanups are abandoned at this exact point.

A keeper rule has to be something a machine can evaluate. That limits the options to roughly five:

• Keep the oldest file, treating the first copy as the original.
• Keep the newest file, treating the last edit as the truth.
• Keep whichever copy sits inside a folder you designate as canonical.
• Keep the copy with the shallowest path.
• Keep the copy whose name lacks a copy marker or a trailing number.

The third rule is the one that holds up over time, because it turns every decision into a question about location rather than content. Documents is canonical, Downloads is disposable, the external drive is an archive. Once that is stated, most rows resolve without being read.

Timestamps are the tempting choice and the fragile one. Copying, restoring, and syncing all rewrite them, so a file that was created years ago can carry a creation date from last Tuesday. Use dates as a tiebreaker after the location rule, never as the primary rule.

Decide how much of this has to be reversible

Deletion is not one action. Tools offer some subset of four levels, and they differ in how much damage a wrong rule can do.

Reporting only writes the candidate list to a file and changes nothing. Move to Trash is reversible for as long as the Trash is not emptied. Replace with a link deletes one side and leaves a pointer, so both paths still open the file while only one body exists on disk. Permanent deletion leaves a backup as the only route back.

Pick the level from whether the target is backed up, not from how confident the rule feels. Folders inside a Time Machine backup tolerate an aggressive setting because the recovery path is known. External drives usually sit outside the backup set, which means the first pass over an archive drive should be reporting only, every time.

One capability is worth more than the deletion modes themselves: a written log of what was removed and where it came from. Months later, when a file cannot be found, the log is what separates deleted from never existed. A tool that deletes silently is a tool that makes every future search inconclusive.

Some folders should never be in the scan

Pointing a scanner at the whole disk produces a result set full of things that must not be touched, and the volume of false candidates is what makes the list unreviewable.

Application bundles contain repeated resources by design. Photo libraries manage their own internal copies and originals. Development folders hold thousands of identical small files across dependency trees, and deleting one side breaks the build. Mail storage and virtual machine images have similar internal structure. None of these are duplicates in any useful sense.

Cloud folders deserve a deliberate decision rather than a default. When storage optimisation is enabled, a file can appear in the listing while its body lives in the cloud. Hashing that file forces a download, so a scan across an optimised folder can pull tens of gigabytes and run for hours before producing anything. Either exclude those folders or materialise them first, knowingly.

Exclusion quality is a real differentiator between products. Check whether patterns can be saved, whether they apply to nested folders, and whether the exclusion list travels between scans. A comparison of file managers that lists scope and exclusion behaviour side by side is more useful at this stage than a feature count, because a tool without persistent exclusions turns every run into manual work.

One cleanup, or a job that runs every week

This is the fork that changes which category of tool fits.

A single cleanup needs very little. Finder sorted by name, a few minutes of reading, and the job is done. The tooling question barely exists.

Recurring duplication is a different problem. Browser downloads, AirDrop transfers, repeated exports, and screenshots all generate copies continuously, so a folder cleared today returns to its previous state within weeks. What matters then is not detection quality but repeatability: can the same scope, the same rule, and the same exclusions be run again next month without being rebuilt by hand.

That points toward tools whose configuration is expressible as text or as a saved job rather than as a sequence of clicks. Anything that has to be reassembled through a dialog each time will quietly stop being run. A file manager with a built in terminal sits in this category because the repeatable part stays next to the folder it applies to, and the published feature list is where to confirm whether saved scopes and scripted runs are actually supported.

What to check on a product page before paying

Four facts matter more than the feature grid, and all four are visible on official pages.

Check whether the product is still being sold. Check whether new signups are open, since some tools remain available to existing customers while closed to everyone else. Check whether the company behind it has changed hands, which happens often in Mac utilities and usually changes the update cadence. Check whether pricing has been revised recently, because a recent change tells you which model the vendor is moving toward.

Then read the pricing page for structure rather than for the number. One time purchase or recurring charge. Per machine or per person. Whether major versions are included. Where the free tier stops, which in this category is frequently at scanning, with deletion reserved for the paid tier. That boundary is the single most important line on the page for a duplicate finder, because a free scan that cannot act is a report, not a cleanup.

Operational limits tend to live in the FAQ rather than on the marketing page: network volumes, external drives, whether the app needs Full Disk Access, what happens to the log. If the target is an archive drive or a NAS, read that section before installing anything.

What to change first

Pick one folder that can be rebuilt if it goes wrong, usually Downloads, and run a report only scan against it with a hash based method. Look at the candidate count and how many rows the location rule would resolve without a human reading them.

That number is the decision. If the rule clears most of the list, the remaining work is small and almost any tool will do. If it does not, the problem is the filing rule rather than the scanner, and buying software will not move it. When the rule holds and the job needs to repeat, choose on scope control, exclusions, and logging, which is what a file manager with a built in terminal such as Atriens is aiming at.