書類の命名規則がうまくいかないとき｜確かめる順番

書類の命名規則がうまくいかない、という相談には中身の違う訴えが混ざっています。規則どおりに付けた名前が検索に引っかからない場合、名前は揃っているのに一覧の並びが想定と違う場合、規則を決めたのに従っているファイルが少数派になっている場合。この3つは壊れている層が違うので、規則の文面を書き直して全部リネームし直すという最初の一手は、3つのうち1つにしか効きません。どの層で止まっているかを分けてから手を動かすと、確かめる作業は数個のコマンドで済みます。

規則そのものが守れる形になっているか

最初に見るのは、決めた規則がそもそもファイルシステムに収まるかどうかです。ここが外れていると、以降の確認はすべて空振りします。

名前に入れる項目は、日付、相手、書類の種類、版、状態のうち必要なものだけに絞ります。項目を1つ増やすたびに名前の長さを消費し、長さには上限があるためです。APFSのボリュームでは、名前1つに入るのは255文字までです。日本語でも英数字でも同じ255文字ですが、絵文字は1つで2つ分を消費するため127個で上限に達します。日本語の255文字はディスク上では765バイトを占めますが、数え方はバイトではないので、バイト数で見積もると余計に短く見積もることになります。

上限を超えたとき、名前は途中で切られるのではなく、操作そのものが「File name too long」で失敗します。道具によってはこの失敗を画面に出さず、そのファイルだけ飛ばして処理を続けます。規則を決めた段階で、いちばん長くなる場合の名前を1件だけ作ってみると、あとで大量のファイルを処理してから気づく事態を避けられます。

もう1つ、表記ゆれの余地を残していないかも見ます。日付を2026-09-12と書くか2026.09.12と書くか、区切りを下線にするか半角空白にするかを規則に書いていないと、書く人ごとに違う形になります。半角空白を許すと、名前の末尾に空白が紛れ込んだときに画面上では見分けが付きません。点で区切る書き方にも別の落とし穴があり、最後の点より後ろを拡張子として読む道具にかかると、日付で終わる名前は拡張子が.12のファイルとして扱われます。

規則の書き方そのものも、守れるかどうかを左右します。項目の順番と桁数まで1行に書いて、正しい例を2件添えておくと、あとから加わった人がその形を真似られます。順番と桁数が書かれていない規則は、直近のファイルの見た目が基準になるため、時間が経つほど最初に決めた形から離れていきます。規則の置き場所は、対象のフォルダの中に、並びの先頭に来る名前で置いておくのが手間がかかりません。

画面の名前とディスク上の名前が食い違っている

規則どおりに付けたはずの名前が検索に出てこない。この症状の多くは、Finderが表示している名前と、ディスクに書かれている名前が別物であることが原因です。

いちばん分かりやすいのが斜線です。macOSのPOSIXの層は、名前の中に斜線を持てません。Finderは入力を受け付けたうえで、斜線の位置にコロンを書き込みます。Finderの画面に2026/09/12_請求書.txtと出ているファイルは、ディスク上では2026:09:12_請求書.txtという名前です。Finderは以後も斜線として表示し続けるので、置き換えが起きたことは画面からは分かりません。スクリプトや同期の道具や書庫の道具が実体の名前を読んだ瞬間に、規則に無い文字が出てきます。日付を斜線で区切る規則を決めていると、規則は完璧に守られているように見えて、何とも一致しないという状態になります。

2つ目は末尾の空白です。名前の最後に付いた半角空白は、そのまま保存され、どの一覧でも見えません。ターミナルで一覧を行末の印付きで出すと見つかります。ls | sed -n l を実行すると各行の末尾にドル記号が付くので、末尾に空白があるファイルは「提案書_v2 $」のように、記号の手前に隙間が見える形で出ます。表計算のセルから名前をコピーして貼り付けたときに混入しやすく、空白が1つあるだけで完全一致の検索は外れます。

3つ目は、ファイルが外を回ってきた場合に出ます。HFS+で初期化されたボリュームは、名前を分解した形で保存します。「が」は「か」と濁点の印の2文字として書かれ、APFSは入力されたままの形で保存します。画面上の見た目は同じで、文字列として比べると別物です。先週まで全件に一致していたスクリプトが、同じファイルを古い外付けディスクに退避して戻しただけで1件も一致しなくなるのは、この違いによるものです。

実体を直接読む

名前が正しく見えるのに一致しないときは、画面を信用せずに実体を読みます。フォルダの一覧を取り出して、各項目を正規化した形と比べれば、見た目が同じ2つの名前が別の文字列かどうかがその場で分かります。分かったあとの直しは1回のリネームで済み、それより大事なのは、どの経路がその違いを持ち込んだかが特定できることです。経路は概ね3つで、古い形式のボリュームを往復した、別のアプリから名前を貼り付けた、Finderで持てない文字を入力した、のいずれかに収まります。

名前は正しいのに並びが合わない

ターミナルの一覧とFinderの一覧が食い違うときは、名前ではなく並べ方の話です。2つの規則が同時に動いていて、どちらも設計どおりに動いています。

Finderは名前の中の数字を数として比べるので、会議資料2が会議資料10より前に来ます。ls は文字として先頭から比べるので、同じ6件が1、10、100、11、2、9の順に出ます。手元のmacOS 26で同じ6件を両方に通した結果は次のとおりです。

名前の付け方	Finderの並び	ls の並び
会議資料1、2、9、10、11、100	1、2、9、10、11、100	1、10、100、11、2、9
3桁で桁を揃えた場合	001、002、009、010、011、100	001、002、009、010、011、100

桁を揃えると食い違いが消えます。フォルダ1つに収まる件数なら3桁、1年分の日次の書類なら4桁が目安です。版の番号も同じ性質を持つので、v2とv10はv02とv10と書きます。

並びが壊れて見えて、実は壊れていない場合も2つあります。名前の先頭に空白や記号が入っていると、そのファイルだけ先頭に来ます。もう1つは、Finderの表示順が名前ではなく追加日になっている場合で、このときは命名規則は並びに一切効きません。リネームに手を付ける前に、表示順の設定を見るほうが早く済みます。

規則を守っているファイルが少数派になっている

これがリネームでは直らない症状です。フォルダの中に、性質の違う2つの集団が入っているためです。

人が自分で保存したファイルは規則に従います。名前を考えている人がその場にいるからです。それ以外の経路で入ってきたファイルは、送り出した側の名前をそのまま持っています。ブラウザからの取得はサーバーが付けた名前、スキャナは自前の連番、カメラはDSCと数字、メールの添付は送信者の規則、画面の保存はシステムの日時の書式です。多くのフォルダでは、規則に従っているファイルのほうが少数で、しかもそれは元々見失いにくいファイルです。

ここは推測より数えたほうが早く進みます。直近30件の到着を、人が名付けたものと機械が名付けたものに印を付けて分けると、割合はすぐ見えます。そのうえで、いちばん多く例外を生んでいる入口を1つだけ直します。スキャナの出力の書式を1回変えるほうが、あとから何度もリネームするより、かけた時間あたりの効き方が大きくなります。例外が生まれなくなるためです。

入口を直せない場合は、届いたものを全部リネームするか、何もしないかのどちらかを選びます。半分だけ適用した状態がいちばん扱いにくく、一覧をたどっても検索しても全件が揃わないうえ、どちらの失敗なのかも判別できません。

一括で名前を変えたときに静かに消えるもの

規則は正しいのに、一括リネームの途中で件数が合わなくなることがあります。原因は3つに収まります。

長さの上限に当たった場合は、前述のとおり失敗して飛ばされます。ロックされた項目は「Operation not permitted」を返し、権限の問題に見えますが、情報ウインドウでロックを外せば通ります。

いちばん静かなのが、大文字小文字だけが違う名前の衝突です。標準の起動ボリュームは大文字と小文字を区別しないため、One.txtがあるフォルダでtwo.txtをONE.TXTに変えると、残るのは1件だけになります。名前は元のOne.txtのまま、中身がtwo.txtの内容に置き換わります。警告も確認も出ません。手元で同じ操作を再現したところ、ゴミ箱にも何も入りませんでした。大文字小文字の違いだけで2つの書類を区別する規則は、区別するサーバー上では成立し、Mac上ではファイルを失います。

ポップアップメニューで「フォーマット」を選択し、ファイルに適用する名前のフォーマットを選択して、名前の前またはあとに追加するインデックス、カウンタ、または日付を選択します。

出典: support.apple.com

Finderの名称変更は、選んだ項目すべてに同じ変換を当てます。衝突しそうな組み合わせが含まれていても、選択の順に処理されるため、実行してから気づくことになります。件数の多いフォルダでは、実行前と実行後の件数を控えておくと、飛ばされたファイルの有無がその場で分かります。

確かめる順番

同じ直しを3回繰り返さないために、次の順に進めます。

• ls の出力とFinderの画面を突き合わせ、ディスク上の名前が画面と同じかを決める
• ls | sed -n l で行末の印を出し、見えない文字が無いかを見てから名前が正しいと結論する
• Finderの表示順の設定を見て、そのうえで2つの並びを比べ、食い違うなら数字の桁を揃える
• 直近30件の到着を経路別に数え、例外をいちばん多く生む入口を特定する
• ここまで済ませてから一括でリネームし、先に最長の名前1件で試す

窓を行き来した回数を数えてみる

上の手順で分かりにくいのは、どれも「フォルダを見ながら、同じフォルダにコマンドを当てる」作業だという点です。一覧はファイル管理の窓にあり、ls の結果はターミナルの窓にあります。確認のたびにパスを打ち直すか、アイコンを引きずってくるかを繰り返すことになります。5秒で終わる確認が2分になる原因は、リネームそのものではなく、この往復です。

そこを縮める作り方として、フォルダとターミナルとAIが同じ窓にある形のファイル管理があります。一覧の並びとコマンドの結果を同じ画面で見比べられるため、上の確認は窓を移らずに済みます。どこまでを1つの窓で扱えるのかはできることにまとまっています。手元のMacで確認を始めたあと、続きを別の端末で見たい場面もあるため、iPhone・iPadから続きをも合わせて見ておくと、確認の途中で止まったときの扱いが決まります。

道具を入れ替えるかどうかを決める前に、他の選択肢との違いを一度並べておくほうが判断が速くなります。ファイル管理の道具ごとに、ターミナルを内側に持つか、外の窓に任せるかが分かれます。その差は他のファイル管理との比較にまとまっています。費用が判断の軸になる場合は料金を先に見ておくと、無料で足りる範囲との線引きがはっきりします。