ファイル名の一括変更: how to decide what you need

Choosing how to do ファイル名の一括変更 on a Mac is usually framed as a tool question, and that is the wrong order. The same job has a different right answer depending on whether there are thirty files or thirty thousand, and whether this is a one time cleanup or something that will come back every Monday. Those two numbers rule out most of the options before any tool is opened.

What follows is a set of questions to answer in sequence. Each one eliminates methods rather than recommending one, which is faster than reading feature lists.

Count first, then decide

Two numbers decide almost everything: how many files are in scope, and how often this will happen again.

The count determines how the result gets verified. Up to about thirty files, every new name can be read before committing. Past a few hundred, reading is no longer possible, and errors stop being visible individually. They show up as a folder where everything is consistently wrong, which looks exactly like a folder where everything is consistently right. Past a few thousand, the run itself takes long enough that an interruption becomes a real scenario, and knowing how far it got matters.

The frequency determines whether the method has to survive. Building a reusable automation for a job that happens once is a poor use of an afternoon. Retyping the same conditions every week is how typos get introduced. A reasonable threshold is the third occurrence: once a job is known to be recurring, it earns a form that persists.

These two numbers also settle how much preparation is proportionate. A one off job on a small folder deserves almost none: opening the sheet and reading the example line is the whole safety procedure. A recurring job on a large folder deserves a written down scope, a dry run, and a record of what changed, because the same rule will be applied again by someone who has forgotten the details. Most of the frustration around bulk renaming comes from applying the wrong level of ceremony, either building a pipeline for thirty files or running an untested pattern across twenty thousand.

Counting is less obvious than it sounds. The item count at the bottom of a Finder window describes the current folder only. If the files are spread across subfolders, the number that matters comes from a search that flattens the hierarchy, or from the command line. When those two numbers differ by a lot, the scope of the job is not yet defined, and defining it is more urgent than choosing a tool.

Question one: can the result be read before it happens

The worst outcome in a bulk rename is discovering the mistake afterwards. Every method that is worth using offers some way to look first.

The Finder rename sheet builds an example line from the first item in the selection and updates it live as the fields are filled in. If that line is wrong, nothing has been written yet.

On the command line, zsh ships with a rename function that has a dedicated flag for this. After autoload -U zmv, a command such as zmv -n '(*).txt' '$1.md' prints every rename it would carry out and touches nothing. Removing the -n is the only difference between a tested pattern and an untested one.

When neither is available, duplicating the folder and running against the copy still works. Whether that is practical depends on size: a folder of documents duplicates instantly, a folder of camera originals does not, and that constraint is itself part of the decision.

Above a few hundred files, deciding where to look matters more than looking harder. Read the first few entries, the last few, and the longest and shortest names in the list. Pattern errors surface on the unusual names first, so scanning the extremes finds them faster than scanning the middle.

Question two: is there a way back

Reversibility varies more between methods than any other property, and it is rarely mentioned in a feature comparison.

A rename done in the Finder can be reversed immediately from the Edit menu. The undo slot holds one operation, and the next action replaces it. That makes the sequence matter: check the result before doing anything else, because a single unrelated click removes the way back.

A rename done from the command line has no undo at all. Reversing it requires a mapping from old names to new ones, which only exists if the list of targets was written to a file before the run. That is a one line preparation, and it is the difference between a recoverable mistake and a permanent one.

Files under cloud sync sometimes have a third option, because the service keeps earlier versions. Version history records contents, though, and not every service tracks the name separately. Anyone planning to rely on that should test it on a single file before running a batch of four hundred.

Question three: what material is available to build the new name from

The Finder rename sheet offers three operations: replacing text, adding text before or after, and applying a format.

Format: Choose Format in the pop-up menu, choose a name format for the files, then choose to put the index, counter, or date before or after the name. Enter a name in the Custom Format field, then enter the number you want to start with. Source: support.apple.com

Anything outside that list is outside the tool. Reordering a date that sits in the middle of a name, padding numbers that were written without padding, applying different treatment based on a condition: none of these have an entry point. Repeated failure with the sheet is usually not operator error but a request the sheet was never built to accept.

Pattern based renaming on the command line can reorder captured fragments, which covers most of that gap. The harder case is material that is not in the name at all. A capture date, a camera model, or a page count lives inside the file, and reaching it requires a separate tool in the chain. Establishing early whether the needed material is inside the filename or inside the file removes about half the candidate methods immediately.

Question four: how far does it reach

Location constrains methods in ways that are easy to discover too late.

Subfolders are the first divide. The Finder acts on what is selected, so items nested below have to be gathered by a search before they can be selected. Command line tools can descend recursively, which is powerful and also how unrelated files get swept in. Stating the depth explicitly is safer than relying on the default.

External drives add a format constraint. A drive formatted for Windows using NTFS is readable on macOS but not writable, so contents open normally while renaming fails. Network shares add a permissions constraint: an account invited with view access cannot rename anything, and no choice of tool changes that.

Cloud sync adds a third. With storage optimisation active, files that have not been opened recently exist locally as placeholders. Renaming one triggers a download first, and a large batch stalls partway through. Materialising the whole selection before starting avoids a half finished run.

A half finished run is worth thinking about in advance rather than during it. If the naming pattern is built by replacing text that already exists, running the same command twice is harmless, because the second pass finds nothing left to replace. If the pattern appends a counter or a prefix, a second pass appends it again, and the folder ends up with names carrying two copies of the same fragment. Knowing which of those two kinds of rule is being used decides whether the response to an interruption is to rerun it or to work out where it stopped.

Shared locations add a timing constraint on top of all this. Renaming a file while a colleague has it open makes it appear to vanish on their side, so for shared folders the question is not only which method but when it runs.

Question five: does the method survive until next time

A method that persists is worth more than a method that is slightly faster today, provided the job recurs.

Finder operations do not persist. The same values get retyped every time, and every retype is another chance to mistype. A command can be saved as text, searched later, and edited into a variant for a related job, at the cost of opening a terminal and remembering what it was called. A Quick Action appears in the Finder context menu and runs against the current selection in two clicks, at the cost of having to open it again to see what it actually does.

With Automator, you don't need to know complicated programming or scripting languages to create automations. Source: support.apple.com

A reasonable split is to give frequently used jobs the shortest invocation and rarely used jobs the most readable form. It also helps to decide in advance when unused entries get deleted, otherwise the context menu fills with items whose purpose nobody remembers.

Two failures that sit outside the five questions

Extensions are the first. A condition that rewrites the end of a name can take the extension with it, and a file whose extension changed still looks correctly named while no longer opening in the app that made it. The Finder can be set to hide extensions, which means the visible text and the real name disagree. Turning extension display on before starting removes the ambiguity.

Collisions are the second. Removing a date from two files that differed only by date leaves two identical names. The Finder detects this and stops. A command line mv does not: the first file is overwritten and does not appear in the Trash. When a preview list is long, extracting just the new names, sorting them, and counting duplicates is the check that catches this. One duplicate means the pattern is not ready.

Putting the answers side by side

Method	Preview	Reversal	Reach	Persists
Finder rename sheet	Live example line	One step undo	Selected items only	No
Shortcuts	Swap the action for a notification	Build it yourself	As configured	Yes
Quick Action	Same as Shortcuts	Build it yourself	Selected items	Yes
Command line	Dry run flag	Mapping file you saved	Recursive	As saved text

Any empty cell in that row is the riskiest part of the job. A missing reversal column on a run of several thousand files is a stronger argument for testing on ten first than any amount of care during the run itself.

What to do first

Count the files, including anything in subfolders, and write that number down next to how many times this job is expected to recur. Thirty files once means the Finder sheet and nothing else. Several hundred recurring means a dry run and a saved form. Several thousand means running ten first and expanding only after the result is checked.

If the counting, the dry run, and the rename each happen in a separate window, the checks are the part that gets skipped, and Atriens is built around keeping the folder, the terminal, and the AI in one place. Details on how it lines up against other approaches are on the comparison page, and pricing is set out on the pricing page.