ファイル名の一括変更 alternatives: what you can drop

Most searches for ファイル名の一括変更 start in the same place: a folder where nothing matches anything else, and renaming looks like the way out. Before spending an afternoon on rules and patterns, it is worth asking a narrower question. How much of what is being encoded into those names has to live in a name at all?

A filename on macOS is doing several jobs at once, and only one of those jobs has no alternative. Separating them shrinks the rename job to a fraction of the files in the folder, and the files that get skipped stay findable.

A filename is carrying four different things

Look at a long filename and it usually decomposes into four parts. A date, so the list sorts in order. A category word, so the file can be picked out of a crowd. A version marker, so the latest one is obvious. And a short description of what is actually inside.

Length is not the problem. The problem is that four independent facts are welded into one string, so changing one of them means rewriting the whole thing across every file. Rename the category, rewrite everything. Change how the fiscal year is split, rewrite everything. A large share of bulk rename jobs exist only because the four parts cannot be edited separately.

Three of those four parts have somewhere else to live. The date is already recorded by the filesystem and often inside the file. The category can sit in tags. The version can sit in a history feature. What is left is the description, which is the part a name is genuinely good at.

Date order is a view, not something a name has to carry

Putting a date at the front of a name exists to make a list sort chronologically. Clicking the Date Created or Date Modified column heading in a Finder list view produces the same order and writes nothing to disk.

Photos and video carry a capture time inside the file, so an image library sorts correctly with no name at all. Scanned documents from many devices carry the same field. The catch is that this value describes when the file came into existence, not what period the contents refer to. A receipt from March that got scanned in September has a September timestamp. Anywhere those two dates disagree, switching from the name to the column changes the order, so it pays to check a handful of files before dropping the date from the name.

Dates that should stay in the name are the ones that travel. A file sent to a client, a document that gets printed, an export that some other system will read in two years. Sort columns are a property of the machine looking at the folder. Names go with the file. When a date does stay, writing it as YYYY-MM-DD keeps alphabetical order and chronological order identical.

Tags hold a classification that a name can only hold once

Category words like invoice, contract, or reference inside a filename can move to Finder tags. A file can carry several tags at the same time, which is the case a filename handles badly. Expressing two categories in a name means the name gets longer and the pattern for finding either one gets more fragile.

Applying them in bulk is not slow. With files selected in the Finder, Control-1 through Control-7 add or remove the seven favourite tags, and Control-0 strips all tags from the selection. A mistake costs one keystroke to undo, which is a different risk profile from a rename applied to four hundred files.

Two limits are worth knowing before moving classification out of names. Tags are an attribute attached to the file rather than part of its contents, so round trips through a zip archive, a differently formatted drive, or some upload and download cycles can drop them. And tags are readable on the Mac and in iCloud, but not by whoever receives the file.

Tags work with all your files and folders, whether you store them on your Mac or keep them in iCloud. Source: support.apple.com

Version markers can often leave the name

Suffixes like _final, _v2, and _revised drive a large share of bulk renames, because every round of edits adds another file next to the last one.

For documents being edited in place, the version does not need to be in the name. A file kept in iCloud Drive records a version each time it is saved, and earlier states can be restored from the app's own menu. Text and code can hand versioning to a separate system entirely. In both cases the row of near identical files stops appearing, so there is nothing left to rename.

There is a middle case that trips people up. A file that has been edited in an app which does not save versions, and has never been sent anywhere, still tends to accumulate copies because the habit of duplicating before a risky edit is a good one. Those copies are disposable rather than versioned, and the right treatment is deletion rather than a renaming scheme. Sorting the folder by modification date and keeping the newest one usually settles it in under a minute, which is faster than designing a naming convention for files nobody will open again.

The version has to stay in the name when copies have already been sent out. Once someone else is working from _v2, changing what that name refers to breaks the conversation. Keeping delivered versions in their own folder with frozen names, separate from the working file, draws a clear line around which files a bulk rename is allowed to touch.

Renaming only to find things later can be replaced by a search

When the goal of a consistent naming scheme is purely retrieval, the search side can absorb the job. macOS search matches on contents, kind, date range, and tags, not just on names. A search built once can be saved and opened from the sidebar, and it stays current as files arrive.

Nothing moves and nothing is rewritten, which changes what a mistake costs. A wrong search shows the wrong list until the criteria are edited. A wrong rename is applied identically to every selected file and has to be reversed.

Saved searches also age differently from folders. A folder built around a project stops being useful when the project ends, and the files sit there because moving them is work. A search defined by criteria keeps returning whatever currently matches, so a rule such as invoices modified in the last ninety days needs no maintenance at all. The cost is that the list is computed rather than stored, so it cannot be backed up, handed over, or opened on a machine that does not have the same files.

The boundary is the same one as before. A saved search lives on one machine. Zip the folder, send it, and the recipient sees filenames only. This is why the useful rule is to leave working files alone and clean up names at the moment of handover, rather than maintaining a naming scheme continuously.

Where renaming has no substitute

Five categories have no alternative, and they are worth listing because they are narrower than they feel.

Files that go to another person. Nothing that lives on this Mac travels with them. Files that get printed, where the name is often what appears in the header. Files published to the web, where the name becomes part of the URL. Numbered sequences, where video and photo workflows rely on the name for ordering. And files consumed by another system that expects a naming convention.

In a downloads folder holding several thousand items, the share that meets any of these is small. The practical test is whether the file will ever leave the machine. If it will not, the name only has to be readable by one person.

Two of these five deserve a closer look, because they are the ones that punish a late fix. Numbered sequences are read positionally by editing and rendering tools, so a gap or an inconsistent width shows up as a missing frame or an out of order clip rather than as an error message. Files consumed by another system are worse, because the convention is often undocumented and enforced silently: an import that expects a date prefix simply skips the rows it cannot parse. In both cases the rename has to happen before the file is handed over, not after something looks wrong downstream.

The remaining three are recoverable. A file sent with a confusing name can be sent again. A printout can be reprinted. A published URL can be redirected. Knowing which failures are cheap and which are not is what decides how much checking a given batch deserves.

What each route actually solves

Route	What it fixes	Cost of a mistake	Survives being sent to someone
Bulk rename	Identification, ordering, handover	Applied to every selected file	Yes
Finder tags	Classification, overlapping categories	One keystroke	No
Folder structure	Large, permanent divisions	Move the files back	Yes, if the folder is sent
Sort column	Chronological order	Click another column	No
Saved search	A live list matching criteria	Edit the criteria	No
Desktop stacks	Visual grouping only	Turn the setting off	No

The last column is the decision. Anything that stays on the machine can be handled by a route that does not survive transit, which means it does not need to be renamed at all.

Rules for the part of the name that stays

Whatever is left in the name should be built so it never has to be rewritten. macOS itself imposes very little.

You can use numbers and most symbols. You can't include a colon (:) or start the name with a period (.). Some apps may not allow you to use a slash (/) in a filename. Source: support.apple.com

In practice the receiving end is stricter than the filesystem. Spaces get split by import scripts. Windows machines treat upper and lower case as the same, so two files that coexist on a Mac can collide after being sent. Sequence numbers need their width fixed before the tenth file exists, since 1, 10, 11, 2 is what plain alphabetical ordering produces. Three digits covers 999 items with the order intact.

Keep separators down to two kinds, such as an underscore between fields and a hyphen inside a field. Once three or more separators are mixed, any future pattern that tries to split the name needs exception handling, and the next bulk rename gets harder rather than easier.

What to change first

Open the folder, sort by name length, and take the ten longest filenames. Split each one into date, category, version, and description, then mark which of the four has somewhere else to live. For most people two of the four disappear immediately, and the rename job that seemed to need an afternoon turns out to cover a few dozen files.

If the counting, the tagging, and the actual rename are each happening in a different window, that split is its own source of friction, and Atriens exists to put the folder, the terminal, and the AI in one place. How it compares with two pane and tag focused tools is set out on the comparison page, and the remaining details are answered in the FAQ.