ファイル名の一括変更: the setup order that holds up

Renaming a few hundred files on a Mac takes about four clicks. The reason it swallows an afternoon is that the four clicks happen at the wrong point, before the decisions that the clicks depend on have been made. Open the folder, select everything, bring up the rename sheet, and only then notice that eleven of the selected files should not be touched. Cancel, reselect, open the sheet again, and stall on whether the date belongs at the front or the back. The work is not hard. The sequence is what breaks.

This is the order that holds up, and the specific decision that belongs in each step.

The sequence, and why the middle step is the one people skip

There are four stages, and each one has a finish condition you can state as a fact rather than a feeling.

Stage	What happens	Done when
Confirm the targets	Gather what is being renamed into one place and count it	The count is a number you can say out loud
Build the pattern	Decide the shape of the new name	It is written down as a single line of text
Test	Apply it to a small subset and look at the result	The new names have been read, not assumed
Widen	Apply it to the rest and check nothing vanished	The before and after counts match

The stage that gets dropped is the third. Testing on twenty files feels like a detour when the whole job is only two hundred. The arithmetic does not support that instinct. A bad rule applied to twenty files costs a minute to notice and a minute to redo. The same rule applied to two hundred files removes the original names, which were the only record of what each file used to be, and recovery means going back to a backup if one exists.

Nothing in this sequence depends on volume. A forty file job runs through the same four stages, faster.

Stage one: gather the targets, then count them

Selecting files in place, inside the folder where they already live, leaves room for the wrong thing to be included. Building a working folder that contains only the targets eliminates that entire class of mistake, because there is nothing else present to select by accident.

How the gathering happens depends on what defines the set.

• Defined by location: duplicate the folder itself.
• Defined by kind, such as every PNG: search with a kind filter, then copy the results into a new folder.
• Defined by a date range: add a created date condition to the same search.
• Defined by content, such as every file containing the word invoice: search the text rather than the names, then copy what matches.

Once the folder exists, read the item count at the bottom of the Finder window and write it down. That number is what the final reconciliation compares against. Without it, files can disappear during the rename and nothing will indicate that they did.

Copy, not move

Gathering by copying leaves the originals where they were. If the rule turns out to be wrong three stages later, the recovery is to delete the working folder and start again, which takes seconds. Gathering by moving turns the same mistake into a restore operation. Unless the drive is genuinely short on space, the copy is the cheaper option by a wide margin.

Stage two: write the finished name as one line

The pattern has to exist as text before the rename sheet opens. Holding it in your head is what causes the drift, where the first fifty files follow one convention and the rest follow a slightly different one.

One line in a text editor is enough:

• 20260911_kanda_estimate_v2.pdf
• 20260911_kanda_notes.md

Writing that line forces four decisions that would otherwise surface halfway through the job. Where the date sits and how many digits it uses. What identifier stands in for the client or project. What word describes the content. Which character separates the fields.

Pick one separator, either an underscore or a hyphen, and never mix them. Mixed separators make it impossible to target a specific field later, because there is no reliable way to describe where one field ends. Write dates as eight digits with no punctuation, which makes a plain name sort produce a chronological order for free.

For the identifier, resist using the full company or project name. Long names get truncated in list views, and a company that rebrands turns every filename into stale information. A short code of four to eight characters, plus a small lookup table kept alongside the files, ages better.

Then hold the pattern next to the current names and look for information that exists now and has no slot in the new pattern. Anything in that category is about to be deleted. Either widen the pattern or drop those files from the set.

Stage three: leave out anything whose name is an address

Some filenames are not just labels. They are addresses that something else uses to find the file, and renaming them breaks the caller rather than the file.

• Images referenced from a web page or a slide deck by a relative path.
• Media referenced by a video or audio project file, which stores the name and will ask for a relink when reopened.
• Files read by source code, since import statements do not follow a rename.
• System items and the home folder. Apple's own documentation is direct about this one.

These are some items you should not rename: App folders and any items that came with your system, such as the Library folder. Source: support.apple.com

Anything ambiguous goes into a separate folder and stays named as it is. Leaving a file badly named costs nothing ongoing. Tracking down a broken reference three weeks later costs more than the rename saved.

Stage four: choose the tool from the shape of the rule

Only now does the tool matter, because only now is the rule specific enough to match against what each tool can express.

The Finder rename sheet handles three shapes: replacing text inside the names, adding text before or after them, and rebuilding the name around an index, counter, or date. What it cannot express is a condition. Every selected item receives the same treatment, so anything of the form "only the PDFs" has to be resolved during selection rather than during renaming.

Tool	Expresses	Reversible	Suits
Finder rename sheet	Replace, add, reformat, applied uniformly	Undo works immediately afterward	One off jobs where the set is already filtered
Shortcuts and Automator	Multi step flows, saved and rerun	Depends on the actions used	Jobs that recur on a schedule
Shell commands	Conditions, nesting, transforms of existing fields	No undo at all	Rules too specific for a sheet

Apple positions the automation route as something that does not require a scripting background, and notes that workflows built there can be imported into the Shortcuts app and rerun as a collection. That matters when the same rename happens every month, because the second run costs nothing.

The shell route is the fastest way to express a complicated rule and the only one with no safety net. Print the before and after pairs first, read them, and only then run the operation. Against a copied working folder, even a bad run is disposable.

When the pattern needs a field the names do not contain

A common stall happens at the point where the pattern calls for a capture date, a client code, or a version number that simply is not present in any of the current filenames. No rename tool can invent it, which is why the job appears to be impossible and gets abandoned.

The information usually exists somewhere other than the name. Photos carry a capture date in their metadata. Documents carry a created date on the file itself. Client codes live in the folder path rather than the filename, because the files were sorted into per client folders at the time. Each of those is a source the rename can read from instead of the name.

That changes which tool fits. The Finder sheet can insert a date, but it uses the file dates rather than embedded metadata. Reading a capture date out of a photo, or promoting a folder name into the filenames it contains, needs the automation route or the shell. It is worth checking which source is available before concluding the pattern is unworkable, because the field is often one level away.

If the value genuinely does not exist anywhere, drop it from the pattern rather than filling it with a placeholder. A name containing unknown in every position is worse than a shorter name, because it looks like real information during a search and matches nothing useful.

Stage five: twenty files, then the rest, then the count

Apply the rule to roughly twenty files and check three things. Are the extensions intact, since a replacement string containing a dot can eat them. Did any two files land on the same name, which means the pattern is missing a distinguishing field. Is the numbering in the order you expected, since counters follow the sort order visible in the window at the moment the rename runs, not the alphabetical order of the names.

Reading the list of new names is not sufficient on its own. Open two or three files and confirm the contents match what the name now claims. A filter that pulled in the wrong project is invisible in a list of names and obvious the moment a file is opened.

When that subset is clean, run the rest. Then compare the item count against the number recorded in stage one. A lower count means collisions overwrote something, in which case the working folder gets discarded and rebuilt from the originals with an extra field in the pattern. A matching count means sorting by name and scanning the result is the last check worth doing.

Keep the pattern where the next run can find it

Batch renaming feels expensive every time mostly because the decisions get made from scratch every time. The line written in stage two, plus the identifier lookup table, belongs inside the folder it describes. With those two files present, the next round skips straight to gathering and testing.

The larger version of the same move is to shift naming to the moment of saving. A file written with the right name never needs renaming. Batch renaming is a tool for collapsing a backlog, not a maintenance strategy for files that have not been created yet.

What to change first

The expensive part of this sequence is the checking in stages three and five, where reading a list, running a command, and looking at the result each happen in a different window. Collapsing that into one place removes the context switch that makes the habit fail. The scope of what a file manager can absorb here is laid out under Features, the tradeoffs against other tools under Compared with other file managers, and the cost under Pricing.

If the pattern has not been written down as one line yet, write it. Nothing earlier or later in the sequence can be finished without it, and everything a tool like Atriens can speed up sits downstream of that line.