ファイル名の一括変更: what it does and where it breaks down

ファイル名の一括変更 is the phrase for taking a folder of files and rewriting all of their names in one pass. The mechanics of it are shallow enough to learn in a minute. What is worth knowing before running it on four hundred files is what the operation actually touches, what it leaves alone, and the small number of places where it reliably goes wrong.

A batch rename is not four hundred small decisions. It is one rule, applied four hundred times, with no human looking at each result. That single property explains both why it is useful and why the failures are shaped the way they are.

What a rename actually changes

A file name is not stored inside the file. It is an entry in the directory that holds the file. Renaming rewrites that entry and nothing else. The bytes of the document do not move, the creation date does not reset, and on the same volume the operation is instantaneous no matter how large the file is. A 40 GB video renames as fast as a text file.

The same system call does moving and renaming. On one volume, moving a file to another folder and changing its name are the same operation with different arguments. This is why the terminal uses mv for both, and why a rename can fail with the same permission error as a move: what gets checked is write access to the folder holding the entry, not access to the file itself.

The consequence that matters: anything that remembered the old name now points at nothing. The file is intact and findable, but a link, a script, an import statement, or a catalog entry that stored the path has quietly broken. Nothing announces this. The rename reports success because the rename succeeded.

The three shapes macOS ships with

Finder has a batch rename built in, and it offers exactly three modes. Select more than one item, Control-click, and choose Rename.

In the pop-up menu below Rename Finder Items, choose to replace text in the names, add text to the names, or change the name format. Source: support.apple.com

Replace Text takes a string to find and a string to put in its place. It is a plain substitution with no word boundaries and no pattern syntax, so it matches anywhere in the name, including inside the extension.

Add Text puts a fixed string before or after the existing name. Useful for prefixing a project code, harmless in the sense that the original name survives intact.

Format discards the existing name and builds a new one from a custom string plus an index, a counter, or a date, placed before or after that string. It also asks for a starting number. This is the mode that turns forty files into Report 001 through Report 040, and it is also the only one of the three that destroys the information in the old names.

Those three cover most real work. What they cannot do is apply a condition. There is no way to say "only the files from March" or "only if the name already contains a client code". Selection is the only filter, which is why people reach for other routes.

The extension is part of the name

Finder presents the extension as if it were a separate attribute of the file. It is not. It is the last few characters of the same string, and every rename mode operates on the whole string unless the tool has been told otherwise.

This produces two failures. The first is a replacement that reaches into the extension: swapping doc for document across a folder turns .doc into .document, and the affected files stop opening in the app that made them. Apple's guide is direct about the risk.

Filename extensions, the period followed by a few letters or words that you see at the end of some filenames (for example, .jpg). If you change an extension, you may no longer be able to open the file with the app that was used to create it. Source: support.apple.com

The second is invisibility. Each file carries a flag that hides its extension in Finder, and a global setting in Finder settings controls whether extensions are shown at all. With extensions hidden, Format mode can build a name that looks clean in the window while the real name has lost its suffix or gained a second one. Turning on "Show all filename extensions" before any bulk operation removes the guesswork, and it is the one preference worth changing permanently.

The counter is only as good as the ordering

Format mode numbers files in the order they appear in the window. That ordering is not a property of the files, it is a property of how the window happens to be sorted at that moment, and this is the single most common source of a batch rename that technically worked and is still wrong.

Sorting by name is lexical, so photo10 comes before photo2. Files named by a camera cross a rollover point, and IMG_9998, IMG_9999, IMG_0001 sort into an order that has nothing to do with when the shutter fired. Sorting by date modified reorders anything that was edited after the fact. Sorting by date created is usually the intent, and it is usually not what the window is set to.

A selection made in a search results window is worse, because such a window can contain files from a dozen different folders. The rename applies to all of them, and the counter runs across the whole set. The count shown in the rename sheet is the only confirmation of how many files are in scope, and reading it takes one second.

Names built out of metadata

The reason dedicated renaming tools exist is that the most useful name is often already inside the file. A photo carries the date the shutter opened, the camera make and model, the dimensions, and sometimes GPS coordinates. An audio file carries artist, album, track title, album year, and track number. Renamer documents exactly which EXIF and ID3 fields it can pull into a name, and the distinction it draws between the EXIF original date and the digitized date matters for scans: for a digital camera the two are the same, while for a negative scanned years later the digitized date records the scan.

The failure here is quiet. When a file has no such metadata, the rule still runs. Screenshots have no EXIF date from a camera. Images exported from an editor often lose the original tags. Audio ripped without tagging has empty ID3 fields. Depending on the tool, the result is a name with an empty slot in it, a set of files all reduced to the same base name, or a fallback to the file system date, which is the date the file arrived on this Mac rather than the date the content was made.

What a rename never does

Four things people expect from ファイル名の一括変更 that it does not do.

It does not move anything. Renaming a hundred files does not put them into folders by year or by client. That is a separate operation, usually a rule in an automation tool.

It does not deduplicate. Two identical photos with different names stay two identical photos after they have consistent names. Consistent naming makes duplicates visible, which is a real benefit, but nothing has been removed.

It does not touch contents. A document that references its own old filename in a header still says the old name.

It does not update references. Aliases usually survive because they track the file by an identifier rather than by path, but symbolic links, shared cloud links, catalog databases in photo and design apps, and any script holding a hard-coded path do not. Checking what points at a folder before renaming it is the step most people skip.

The five places it breaks

Collisions come first. Two files reduced to the same name cannot coexist. Finder stops and reports the problem. The terminal does not: mv a.txt b.txt overwrites b.txt with no prompt, no Trash, and no way back. Adding -n to mv turns that into a refusal to overwrite, which is the difference between a close call and a lost file.

Patterns that match more than intended come second. Replacing the string 2025 with 2026 also rewrites a client name, an invoice number, and a version suffix that happen to contain those digits. Even pattern-based routes surprise people: in zsh, zmv -n '(*)2025(*)' '${1}2026${2}' applied to a file named 2025_2025.txt produces 2025_2026.txt, because the first wildcard is greedy and swallows everything up to the last match. The -n flag prints what would happen and changes nothing, which is the cheapest way to find this out.

Length is third. On APFS a single name component stops at 255 characters. A rule that prepends a long project string to names that are already long fails on exactly the files that needed shortening most.

Character rules are fourth. Apple's guide states that a name cannot contain a colon or start with a period, and notes that some apps refuse a slash. The terminal is more permissive than Finder here, so a name created in one place can look wrong in the other.

Files that are not fully present are fifth. When storage optimization is on, a file in the cloud may be a placeholder rather than real bytes. Renaming triggers a download first, and on a large selection the run stalls partway through, leaving some files renamed and some not.

Three routes, compared

	Finder	Terminal (zmv)	Dedicated renaming app
Preview before running	Example line at the bottom of the sheet	-n prints every planned move	Live table of old and new names
Undo	Command+Z, for that session only	None. mv is final	Usually a built-in undo list
Conditional rules	No	Yes, through patterns	Yes, through stacked rules
Reads EXIF and ID3	No	Only with extra tools	Yes
Repeatable next month	No	Yes, as a saved command	Yes, as a saved preset
Cost	Free	Free	Roughly 19 to 42 US dollars

The honest summary is that Finder covers one-off cleanups, the terminal covers anything rule-shaped that you are willing to write out, and a paid tool earns its price when the same job returns every week. A closer look at how these routes divide up is in Compared with other file managers, and the price side of the question sits on the Pricing page.

Decide the naming rule before choosing the tool

Most of the pain in ファイル名の一括変更 comes from running a tool before deciding what the names should say. The decision is small and it is worth making once for a whole category of files.

Three fields is a workable ceiling: a date, a subject, and an identifier. Beyond three, names get long enough to hit the length limit and short enough on meaning that nobody reads them anyway.

Put the date first and write it as year, month, day with separators, because that is the one format that sorts correctly as text. 2026-03-04_acme_invoice and 2026-03-11_acme_invoice land in chronological order in every window, every list, and every terminal, without anyone needing to set a sort column. Writing the same date as 4-3-26 throws that away.

Keep the original identifier rather than deleting it. When a photo goes from IMG_4821.JPG to 2026-03-04_site-survey_4821.jpg, the number still matches the camera card, the invoice, and the export from the editing app. Format mode makes it very easy to discard that link, and it cannot be rebuilt afterwards.

Then write the rule down somewhere the rule will be found again. A tool preset, a shell function, or a line in the folder's own notes all work. The point is that the second time this job comes around, nobody is re-deriving the pattern from memory at the moment they are also under time pressure.

What to change first

Run the operation once with the preview visible and the count read out loud, on a duplicate of the folder rather than the original. If the same rename comes back next month, the thing to change is not the tool but the fact that it is manual: a saved rule, kept next to the folder it applies to, removes the decision entirely. Keeping the folder, the terminal and the rule in one window is the shape Atriens is built around.