ファイル命名規則:実際に使えるテンプレートとルール

クライアントにファイルを送ろうとしたら、フォルダには final_v2、final_FINAL、final-new が並んでいる。ひとつ開いて、もうひとつ開いて、結局同僚に「どれを送ったっけ?」とメッセージする。仕事そのものは終わっているのに、探すのに手間取る。これが問題です。

そこで効いてくるのが、しっかりしたファイル命名規則です。いい名前なら、ファイルを開かなくても、それが何で、どこに属していて、最新版かどうかが他人にも分かります。さらに、別のコンピュータや共有ドライブ、別のOSに渡っても壊れない名前でなければなりません。

どのチームでもコピーして使える命名テンプレート ​

まずはこの名前を見てください。

NORTH-2026-03-14_brand-logo-concept_v03_final.psd

左から読んでいきます。NORTH はプロジェクト、2026-03-14 は日付、brand-logo-concept は中身の説明、v03 はバージョン、final はステータス、.psd はアプリが付けた拡張子です。

順番が大事です。いちばん変わらない要素を先頭に置きます。たいていはプロジェクトコードです。そうすれば並べ替えたフォルダの中で、プロジェクトごと、さらに時間順にまとまります。説明を先頭に置くと、別プロジェクトのファイルがリストのあちこちに散らばって、本来は名前がやるべき仕事を検索が肩代わりするはめになります。

6つの要素とその順番 ​

つまずきやすいところがいくつかあります。説明に書くのは中身であって、仕上がり具合ではありません。「brand-logo-concept」はOKですが、「new-version」はNGです。「新しい」は明日になれば嘘になるからです。その意味を担うのがステータスですが、それも短いリストに限った場合だけです。誰かが「final-ish」や「approved-maybe」を足し始めた瞬間に、ステータスは検索できる要素ではなくなります。

バージョンもまた別物です。v03でもまだドラフトということはあるし、v07で最終ということもあります。この2つの概念を別々の枠に入れておけば、final2やfinal-really-finalのような名前は必要なくなります。

製品や機能の名前も付けるなら、Sprelloの製品ネーミングガイドが参考になります。同じ規律をネーミングの側から扱っていて、ラベルを短く、一貫して、部外者にも読み取りやすく保つ話です。

他人テスト ​

保存する前に、3つ自問してください。

• これは何か? ファイルを開かなくても、説明部分で答えが分かるか。
• どのプロジェクトのものか? コードを見ればひと目で分かるか。
• 最新版か? バージョンとステータスで判断がつくか。

6つの要素を毎回すべて使う必要はありません。個人の写真なら、日付と説明だけで足りるかもしれません。必要なのは、毎回同じ順番を守ることです。そうすれば、要素が欠けていても残りの位置がずれません。

命名規則が現場で崩れてしまう理由 ​

努力が足りないグループは多くありません。足りないのは、忙しい週でも生き残る合意のほうです。

ラベルのない引き出しが並んだキャビネットを想像してください。書類はどこかに入っているのに、探すには封筒をひとつずつ開けるしかありません。「presentation」「presentation new」「presentation March」だらけの共有フォルダも同じです。ファイルはあるのに、取り出す仕組みがないのです。

散らかりの大半は、2つのパターンから生まれます。

名前が揺れていく。 ある人は日付を14-03-2026、別の人は2026-03-14と書き、3人目は締め切りに追われて日付を飛ばす。1か月もすれば、同じプロジェクトに日付の書式が3種類、バージョンの付け方が2種類並び、並べ替えは意味をなさなくなります。

名前が書いた本人にしか通じない。 「Draft for Sarah」は、保存した日なら明快です。でも半年後、Sarahが別のチームに移ったあとでは、誰にも何も伝えません。未来の自分も、ここでは他人です。1年後にそのファイルの置き場所が分からなければ、書いたのが自分でも、その名前は失敗でした。

これはまれな問題ではありません。Daniel CowardがLinkedInで公開した2026年の業種横断調査は、200社以上、およそ10,000ファイルを対象にしていて、ファイル名の73%に、日付の書式の不統一、あいまいなバージョン表記、文脈の欠落といった問題があったと報告されています。

機能する規則が実際に解決すること ​

• 見つけやすさ: プロジェクトコードで検索すれば、フォルダをまたいでも関連ファイルがすべて出てくる。
• 並べ替え: 手作業で並べ直さなくても、リスト表示がプロジェクト順・時系列順になる。
• 引き継ぎ: デザイナー、開発者、指導教員、クライアントが、聞かなくても正しいファイルを特定できる。

命名はもっと大きな整理の仕組みの一部です。大量のアセットを抱えるチームには、カテゴリやラベルがコレクションの成長に耐える方法を扱った拡張性のあるデジタルアセット分類の作り方が役に立ちます。

規則の価値は、チームがどれだけ使うことに合意しているかで決まります。誰も読まない文書の中の完璧なテンプレートでは何も変わりません。だから、作る過程そのものが、合意を生み出すものでなければなりません。

6ステップで命名規則をつくる ​

細かく見ていく前に、全体の流れを1ページで確認しておきます。

1. 目的を言葉にする。 どのファイルにも素早く答えさせたい3つの問いを書き出します。たいていは、何であるか、どのプロジェクトのものか、どのバージョンかです。目的のないルールは、締め切りに追われた最初の場面で捨てられます。なぜ大事なのかを誰も説明できないからです。

2. 4〜6個の要素を選び、順番を固定する。 プロジェクトコード、日付、説明、バージョン、ステータス、役割から選びます。避けたいのは、誰も埋めない要素を足すことです。チームが全ファイルに保管場所やクライアントの連絡先を記録しないなら、入れないでください。半分が空欄になる要素は、全員のパターンを崩します。

3. 区切り文字と大文字小文字を決める。 要素の内側の単語はハイフン、要素グループのあいだはアンダースコアでつなぎます。プロジェクトコード以外は小文字で統一し、スペースは使いません。スペースはコマンドラインのスクリプトやWebリンクを壊すことがあり、ダブルクリックでの選択もしづらくします。方式はひとつに決めて、ハイフンとアンダースコアを自由に混ぜさせないこと。

4. 日付とバージョンのルールを固定する。 日付は YYYY-MM-DD、バージョンは v01 から始め、日付が作成日なのか納品日なのかを最初に一度だけ定義します。これだけで、半数が作成日、半数が納品日で日付を付けるという、何年も続きがちな静かな揉めごとを防げます。

自分のガイドを書き始める前に、手順が実際に適用される様子を短い動画で見ておきましょう。

5. 1ページのガイドを書く。 良い例5つと悪い例5つ、それに、書き換えない過去のファイルのような例外へのルールを1つ入れます。1ページにおさめてください。12ページもの標準は、命名がお役所仕事だという合図になり、人はお役所仕事を避けて通ります。そのページは、誰も開かない規程フォルダではなく、ファイルを保存する場所に貼っておきましょう。

6. 進行中のプロジェクト1つで、2週間試す。 そのあと、いちばん破られたルールを2〜3個見直します。試験運用を飛ばすと、誰にも使われないルールができあがります。ある要素が保存の瞬間に用意しにくいと、気づくのが遅すぎるからです。

試験運用中に何度も破られるルールがあったら、それはチームの怠慢ではなく、そのルールについての情報として受け取りましょう。

うまく回っているかどうかの見分け方 ​

並べ替えたリストが年表のように読める。チームの誰もが、最新の最終版を10秒以内に見つけられる。新しく入った人が、1ページのガイドだけで初日から正しくファイル名を付けられる。

正しく並ぶ日付とバージョンの書式 ​

3-4-26、2-11-26、10-3-26が入ったフォルダを開いてみてください。リスト表示では先頭の文字で並ぶので、10-3-26が2-11-26より前に来て、時系列がぐちゃぐちゃになります。ここにv1、v10、v2を加えると、コンピュータはv10をv2より前に置きます。テキストの並べ替えは1文字ずつ読むので、「1」が「2」より先になるからです。

どちらも不注意の問題に見えます。実際は書式の問題で、仕組みで直せます。

日付を年から始める理由 ​

YYYY-MM-DD は、どのファイルマネージャでも時系列に並びます。いちばん大きな単位が先頭にあり、どの単位も桁数が固定されているからです。DD-MM-YYYYは日で並ぶので、毎月1日がかたまってしまいます。しかも3-4-26には別の問題もあります。読み手の地域によって3月4日とも4月3日とも読めてしまうし、2桁の年は世紀を推測に任せることになります。

Microsoft自身のガイダンスも、クロスプラットフォームの作業については同じ結論です。Microsoftのファイル命名に関するドキュメントは、辞書順の並べ替えを改善するために YYYY-MM-DD のような日付を先頭に置く書式を支持していて、一括処理のときのあいまいさを減らすために、プロジェクトやバージョンのトークンを安定させることも勧めています。

日付とバージョンは別々に持つ ​

日付は、ファイルが作られた、または納品された時点を記録します。バージョンは、その作業の何回目の版かを記録します。別々の事実なので、同じ日の2つのファイルでバージョンが違うことも、同じバージョンが後日あらためて納品されることもあります。ひとつにまとめると、どちらかの情報が失われます。

ゼロ埋めが、バージョンを正しく並べる決め手です。数字は必ず2桁で、v01からv99まで書けば、v02はv10より前に来ます。プロジェクトが99回を超えるのが明らかなら、途中で切り替えずに最初からv001で始めてください。

安定したトークンはスクリプトにも役立ちます。固定のプロジェクトコードと少数のステータス語があれば、一括処理ツールが確実にファイルを拾えます。パターンが固まったら、Macでのファイル名一括変更のガイドを一度読んでおく価値があります。データ量の多いチームなら、多くの自動実行にわたってバージョントークンがあいまいにならないようにしなければならないロボティクスデータのバージョン管理のやり方に、同じ規律を見いだすはずです。

タイムゾーンをまたぐチームなら、納品日はチーム自身のタイムゾーンで付け、そのルールをガイドに書いておきましょう。真夜中近くに送られたファイルにも、合意した日付がひとつ付きます。

最後に、バージョンの水増しを防ぐルールをひとつ。バージョンを上げるのは、他の人に送る保存のときだけ。自分が保存するたびではありません。 手元の作業用の保存は、あなたの自由です。バージョン番号は、他人とのコミュニケーションのための道具なのです。

転送で壊れる文字・アクセント・長さの制限 ​

よくある思い込みを、ここで疑ってみましょう。Macが受け付ける名前なら大丈夫、という考えです。

大丈夫ではありません。上限を決めるのは、ファイルを作ったMacではなく、ワークフロー内でいちばん厳しいシステムです。 手元では完全に合法な名前でも、Windowsボリュームへのコピーに失敗したり、同期サービスに勝手に改名されたり、深いフォルダ階層の奥で届かなくなったりします。命名のアドバイスの多くは、読みやすさの話で終わります。でもファイルを失う原因になるのは、転送リスクの部分です。

アクセント問題をやさしく説明すると ​

アクセント付きの文字は、2通りの方法で保存できます。ひとつは合成済みの1文字として、もうひとつは基本の文字と別の結合記号の組み合わせとして。画面上では、どちらも同じに見えます。

ファイル名のUnicodeガイドが説明するように、macOSでは分解形、つまりNFD系の名前が一般的に見えるのに対し、Linux環境ではNFCが使われるか、正規化されないままになることが多くあります。この食い違いが、見た目は同じテキストなのに、ファイル名が重複して見えたり、比較に失敗したり、スクリプトが壊れたり、同期の競合が起きたりする原因になります。

もうひとつ落とし穴があります。ファイル名の長さは、見た目の文字数ではなくバイトで数えられ、アクセント付きの文字を分解するとバイト数が増えます。つまり、上限以内に見える名前が、転送や処理のあとに1コンポーネント255バイトの上限を超えることがあるのです。Finderで文字数を数えても、偽りの安心しか得られないのはこのためです。

ASCIIのみの名前という選択のトレードオフ ​

すべてをプレーンなASCIIに制限すれば、たしかに相互運用性は上がります。でもその代わりに、アクセシビリティ、検索性、文化的な正確さを犠牲にします。スペイン語、ドイツ語、日本語など、多くの言語で誤った表記を強いることになるからです。同僚に、スクリプトが動くように自分の名前を間違えて綴ってくれと頼むのは、ルールではなく責任放棄です。

代わりに、レイヤーを分けたやり方をとりましょう。

• 母語の表示名は残す。 人名や地名は、人が読む場所では正しい綴りのままにする。
• ツールが許すなら、保存前にNFCに正規化する。 どのシステムも同じバイト列を比較するようになる。
• 機械用の識別子には、ASCIIのスラッグを持つ。 スクリプトや同期ツールはスラッグで照合し、人は表示名を読む。
• 実際の転送経路でテストする。 チームが本当に使っているNAS、クラウドドライブ、Gitリポジトリを通して、サンプルファイルを往復させる。

Unicodeは使ってかまいません。ただし一貫して正規化し、バイト長を検証し、転送を無事に生き延びるかを確かめてください。

クリエイター・開発者・学生・研究者向けの職種別テンプレート ​

どの職種でも、使う要素は同じです。変わるのは、どの要素がいちばん重みを持つかです。職種ごとに、苦しめられる混乱の種類が違うからです。

クリエイターは、クライアントまたはプロジェクトのコードとアセットの種類を先頭に置きます。ひとつのキャンペーンに、同じバナーの何百ものイテレーションが入ることもあるので、バージョンは曖昧であってはならず、アセットの種類でホームページのバナーとSNS用のトリミングがひと目で区別できなければなりません。アセットの要素がないと、寸法を確かめるためにファイルを開くはめになります。

開発者は、すでに小文字の名前とスペースなしを課しているリポジトリの中で作業するので、それに逆らわないでください。名前は代わりにコンポーネントとドキュメントの種類に使います。shop-api_auth-flow_spec_v02.mdなら、レビュアーはシステムのどの部分の話かがすぐ分かります。コミット履歴がすでに記録している日付より、そのほうが大事です。

学生は、まず指導教員の指定に従ってください。指定がなければ、科目コード、課題、提出ステータスを名前に入れましょう。クラス全員分の提出物をさばく採点者が、数秒であなたの課題を見つけられます。提出物がひとつの共有受信箱に届くなら、苗字も役に立ちます。

研究者は、いちばん賭け金が高い職種です。生データと整形済みデータは別の名前にし、生ファイルは読み取り専用にして、すべてを研究IDと日付に結びつけます。整形済みデータが生データを同じ名前で上書きしたら、その研究は再現できません。

例外を扱っても仕組みを壊さないために ​

ときには、プラットフォームが独自のルールを課してきます。提出ポータルがアップロードを改名したり、ツールが特定のパターンを要求したりします。そのときはプラットフォームに従い、人が読める名前をREADMEやプロジェクトの索引に記録して、つながりが切れないようにします。

言語をまたぐ場合も同じです。表示名は母語のまま、機械用の識別子はASCIIのままにしておけば、人もツールも満足します。

命名は、フォルダ構成が負荷の一部を引き受けているときにいちばんうまく機能します。だからこれらのテンプレートは、あらゆる情報をファイル名に詰め込もうとせず、きちんとしたプロジェクトのフォルダ構成と組み合わせてください。クライアント、キャンペーン、地域、チャネルをひとつの名前に詰め込んでいるなら、そのうちのいくつかはフォルダに属します。

ひとつの規則を採用して、チェックを自動化する ​

そもそも合意に至らないチームは多くあります。Smallpdfが2026年に米国の働く社会人1,000人を対象に行った調査では、55%が、チームに共有された標準的な命名規則がないと答えました。

だから、強制の前に採用があります。1ページのガイドを公開し、ファイルを作る人たちの承認を得て、全体に展開する前に、進行中のプロジェクト1つに適用します。組織全体へのメール一斉送信で告知された規則は、金曜までには死んでしまいがちです。

自動化の3つのレベル ​

レベル1は、届いた時点でファイルをチェックする。 受信用フォルダに、macOSならAutomatorのフォルダアクションのような名前変更ルールを設定したり、新しいダウンロードにフラグを立てたり修正したりするフォルダ監視ツールを使ったりします。選択肢を比べているなら、フォルダを監視して新しいファイルに反応できるツールを紹介したMac向けの自動化アプリの概要が参考になります。

レベル2は、すでにあるものを監査する。 WindowsやLinuxの短いスクリプトで、ガイドと同じ要素の順番に照らして、パターンに反するファイルをすべて一覧にできます。プロジェクトのフォルダに対して実行すれば、ズレがすぐに見えます。誰におさらいが必要かも含めて。

レベル3は、傾向を追う。 四半期ごとの監査で、規則に反する名前の数を数え、その数を時系列でグラフにします。減っていくなら、チームに習慣が根づいてきた証拠です。増えていくなら、どこかのルールが守りにくすぎて見直しが必要だということで、厳しく取り締まる必要はありません。

既存のファイルはどうするか ​

アーカイブを闇雲に改名しないでください。旧名と新名の対応表を残しておけば、文書、チケット、メールの中のリンクが切れたときに直せます。まず進行中のプロジェクトから改名し、閉じたアーカイブは、まだ誰かが検索するのでなければそのままにしておきます。

今週、ひとつだけやってみてください。次のプロジェクトを選んで、そのテンプレートを1ページに書き、フォルダを1つそれに合わせて改名し、ファイルが追加されるたびに動くチェックを1つ設定する。その小さく動く実例は、方針の発表よりずっとよく人を説得します。

名前が整ったら、今度はフォルダそのものも見分けやすくしましょう。Tintdはフォルダの名前を読み取って、合ったアイコンと色を選びます。さらにFolder Watcherが、指定した場所に作られた新しいフォルダに自動でスタイルを付けるので、きちんと名前の付いたプロジェクトは、Finderでもひと目で分かるようになります。たったいま作った命名の仕組みの上に、視覚的な整理がどう乗るのか、Tintdで確かめてみてください。