ファイル命名規則の作り方2026｜探し物を減らす7ルール

ファイルが見つからない原因は、保存場所ではなく名前にあることが多い。中身が 最終版.docx・最終版2.docx・これで完成_修正後.docx で埋まっていれば、開いて確かめる以外に手はない。

この記事では、Windows・macOS・クラウドのどれでも壊れないファイル命名規則を7ルールにまとめる。編集部で検証した「日付6書式の並び順テスト」「パス長の予算表」「一括リネーム所要時間試算」とテンプレート4種も掲載する。

ファイル名で探し物の時間が決まる理由

整理の話はフォルダ構成から始まりがちだが、実務で効くのは名前だ。フォルダは1ファイルに1か所しか割り当てられないが、名前は日付・案件・種類・版数を同時に持てる。整理が続かないのも「保存した瞬間」と切り離されているからで、命名規則なら決まった要素を並べるだけで判断が消える。

「検索できるから適当でいい」も半分しか正しくない。全文検索が効くのはテキスト形式に限られ、画像・動画・音声・スキャンPDF・圧縮ファイルの中身は多くの環境で対象外だ。命名規則の役割は「見つける」より「候補を1〜3件に絞る」ことにある。同じ構造はChromeブックマークバーの整理やPC・デジタル整理術でも起きる。

【編集部実測】日付6書式で並び順はどう変わるか

命名規則の解説はほぼ例外なく「日付は YYYY-MM-DD にせよ、名前順が日付順になるから」と書く。ところが実際にエクスプローラーで並べると、そのとおりにならない場合がある。6書式をソートして検証した。

検証の方法と前提

5つの日付（2025-12-31 / 2026-01-15 / 2026-08-05 / 2026-08-25 / 2026-11-02）を6書式で文字列化した計30件を、2種類の並び替えにかけた。判定は「結果が時系列と完全一致するか」のみ。

• 辞書順：ZIPの一覧、スクリプト言語の標準ソート、クラウドのAPI一覧で使う素朴な文字列比較。
• 自然順：エクスプローラーの既定。連続した数字を数値として比較する。Microsoftの StrCmpLogicalW 関数が実体で、File3 が File11 より前に並ぶ。

実測結果：辞書順と自然順で結論が変わる

各書式が2つの並び替えで時系列を保てたかを示す。

辞書順で崩れなかったのは YYYY-MM-DD と YYYYMMDD だけだった。2026-8-5 や 2026年8月5日 は、辞書順だと11月が1月の隣（書式により直前にも直後にも）に来て、8月25日が8月5日より前に来る。文字単位では 11 の 1 が 8 より小さいためだ。

エクスプローラーだけ見ていると気づけない落とし穴

今回の最重要点はここだ。自然順の列では、2026年8月5日 もゼロ埋めなしの 2026-8-5 も時系列に並んでいる。自分のPCを眺めているぶんには何も起きない。「この書き方で困っていない」という体感は嘘ではないのだ。

問題はファイルがPCの外に出た瞬間に起きる。ZIPで渡した先の一覧、クラウドのWeb画面、スクリプト処理、社内システムへの一括アップロード——これらの多くは辞書順だ。手元で整然としていた並びが相手の画面では崩れる。この2書式を推す理由は「Windowsで並ぶから」ではなく「どこに持っていっても並ぶから」である。ISO 8601 の書き方でもある。

迷わないための命名規則7ルール

覚えるのは「日付から始め、決まった順番に決まった記号でつなぐ」だけ。

ルール1〜3：日付・区切り記号・要素の順番

ルール1：先頭は日付、書式は YYYYMMDD か YYYY-MM-DD に固定。前節の実測どおり、この2つ以外は環境が変わると崩れる。文字数優先なら8桁、読みやすさ優先ならハイフンあり。混在させないこと。

ルール2：要素の区切りはアンダースコア、単語内はハイフン。研究データ管理で広く使われる流儀で、20260805_新規サイト立ち上げ_企画書_v03.docx なら「日付／案件／種類／版数」が一目で分かる。半角スペースはURL化で %20 に化けるので使わない。

ルール3：要素の順番を固定する。目的は並び順ではなく、作るときに考えずに済ませることだ。案件を主軸にするなら「案件＿日付＿種類＿版数」でもよい。1つに決めて動かさないのが本質だ。

ルール4〜5：バージョンと連番の書き方

ルール4：版数は v ＋2桁ゼロ埋め（v01、v02…）。「最終版」「確定」は使わない。必ず「最終版の修正版」を生み、意味が崩壊する。ゼロ埋めは辞書順で v10 が v2 より前に来るのを防ぐためだ。

ルール5：連番は3桁ゼロ埋めを既定に。2桁だと100件目で破綻し全件リネームになる。件数が読めないものは最初から 001 で始める。

ルール6〜7：長さと固有名詞の扱い

ルール6：ファイル名は拡張子込み30〜40文字を目安に。技術的上限はもっと長いが、実務ではパス全体の長さが効く（次章）。長くなる原因は「フォルダ名の情報をファイル名にも書く」ことだ。

ルール7：固有名詞は略さず、表記を1つに決める。ABC商事・ABC・エービーシー の混在は検索を殺す。表記ゆれを潰すのが検索精度を上げる最も安上がりな投資だ。

使ってはいけない文字と名前の一覧

使えない文字を選べば保存やコピーで止まる。一覧を手元に置くのが早い。

Windowsが受け付けない9文字

次の9文字は使えない。OSがパスの解釈に使う記号だからだ。

末尾の半角スペースやピリオドも避ける。Windowsが黙って削除する。

予約名（CON・PRN・AUX・NUL・COM1〜9・LPT1〜9）

使えないのは文字だけではない。MS-DOS時代から続くデバイス予約名も、大文字小文字を問わず使えない。CON・PRN・AUX・NUL・COM1〜COM9・LPT1〜LPT9 だ。

厄介なのは拡張子を付けても回避できない環境がある点だ。従来のWindowsでは CON.txt も CON と同じ扱いになる。Windows 11では緩和されたが NUL は今も特別扱いで、共有先の環境が揃う保証もないので避けたい。

クラウド同期で問題になる文字

OSに加え同期側の制限も効く。

• 記号：# % は2017年6月より前に作られたテナントでは同期がブロックされる。& はURLやスクリプトに渡す場面で扱いが面倒になる。
• 機種依存文字：丸数字（①②）、ローマ数字（Ⅰ Ⅱ）、㈱などは環境をまたぐと化ける。
• パス全体の長さ：OneDrive・SharePointではデコード後のパス全体が400文字を超えられない。

【編集部試算】パス長の予算表

「ファイル名は短く」の根拠がこの上限だ。何文字まで許されるか計算した。

260文字と400文字という2つの上限

Windowsには MAX_PATH という上限があり、ドライブレターから拡張子までの合計が260文字（実質259文字）に制限される。Windows 10 バージョン1607以降は設定やレジストリで長いパスを有効化できるが、これはOS側の許可にすぎずアプリ側が対応していなければ効果がない。古いインストーラーは今も止まる。

もう一方がクラウド側の400文字だ。OneDrive・SharePointではパス全体が400文字以内、同期時は各セグメント255文字以内という制約も加わる。

階層の深さと名前の長さのトレードオフ

起点を C:\Users\username\OneDrive - CompanyName\ドキュメント（47文字）とし、各階層のフォルダ名を一定と仮定して積み上げた。

数値は起点47文字＋（階層数×（1＋フォルダ名））＋1＋ファイル名で算出した総パス長。太字は259文字超。

フォルダ名20文字・ファイル名40文字なら6階層でも214文字で余裕がある。一方、フォルダ名30文字・ファイル名80文字の「丁寧に書いた」状態は5階層目で283文字となり MAX_PATH を超える。400文字の上限は全パターン未到達だった。

そのまま使えるテンプレート4種

文字数は編集部で実際に数えた実測値である。

4つのテンプレートと実測文字数

記入例はそのまま置き換えられる。

4種とも23〜31文字で「ファイル名40文字」の枠内に収まる。フォルダ名20文字と仮定して階層5まで積んでも総パス長は176〜184文字となり、MAX_PATH に75文字の余裕が残った。

フォルダ名と役割を重複させない

運用のコツはフォルダ名にある情報をファイル名に繰り返さないことだ。2026年度\ABC商事\ に 20260805_ABC商事_見積書_v01.pdf を置くと案件名が二重になる。ここは 20260805_見積書_v01.pdf（20文字）で足りる。

ただし単体で送る可能性があるものは、フォルダの文脈が消えても意味が通る名前にする。添付された 20260805_見積書_v01.pdf は受け取った側に何の見積書か分からない。あわせてフォルダ操作のショートカットキーとObsidianのナレッジ管理術も併用しやすい。

既存ファイルを一括で直す手順

次に来るのが「過去の数千件をどうするか」だ。全部は直さなくていい。ただし直すと決めた分を手作業でやってはいけない。

【編集部試算】手作業と一括リネームの所要時間

手作業は1件15秒（中身を確認し打ち直すまで）、一括リネームツールは準備5分＋1件0.02秒として算出した。

見るべきは削減率より、一括リネーム側の所要時間が件数にほとんど連動しない点だ。100件でも3,000件でも5〜6分で終わる。逆に手作業は3,000件で750分＝12時間30分となり放置される。100件を超えたらツールに切り替えればよい。

PowerRenameでの実務手順と注意点

Windowsなら、Microsoftが無料配布するPowerToysのPowerRenameが使いやすい。エクスプローラーでファイルを選び右クリックから起動する。正規表現が使え、実行前にプレビューが出る。

1. 対象フォルダをコピーしてバックアップを取る。Ctrl+Z で直前の操作は戻せるが、複数回の変更や同期フォルダでは戻しきれない。
2. 10件程度で試す。正規表現の当たり方は実データでしか分からない。
3. プレビューを1件ずつ確認する。想定外のファイルが入っていないか見る。
4. 日付が名前から取れないものは分ける。更新日時から機械的に付けると、コピーでリセットされた日時が入り込む。

最も重要なのは、共有フォルダやクラウド同期フォルダで一括リネームをかけないこと。他のメンバーが参照中だとリンク切れが連鎖し、同期側では「大量削除＋大量新規作成」と扱われて長時間止まる。ローカルに退避してから戻すのが安全だ。関連してタイピング速度・通知を減らす設定・タイムブロッキングも併用しやすい。

よくある質問

迷いやすい4点を挙げる。

日本語のファイル名は使わないほうがいいですか

社内で完結しWindows同士でやりとりするなら日本語で問題ない。英数字に寄せたほうがよいのは、海外とのやりとり・Webサーバーへの直置き・コマンドラインで頻繁に扱う場合の3つだ。「日付と版数だけ半角英数字」の折衷でも並び順の恩恵は受けられる。

日付は先頭と末尾のどちらに置くべきですか

時系列で追う資料（議事録・日報・写真・ログ）は先頭に置く。案件で束ねる資料（提案書・見積書・契約書）は案件名を先頭にして日付を後ろに回すほうが探しやすい。ただし同一フォルダ内で混在させない。

バージョンはv01とv1のどちらがいいですか

ゼロ埋めした v01 を推奨する。v1 だと辞書順で v10 が v2 より前に来て最新版が埋もれる。エクスプローラーは自然順なので見えないが、ZIPで渡した先やクラウドのWeb画面では崩れる。前章の日付書式と同じ現象だ。

すでに数千件ある古いファイルも全部直すべきですか

直さなくてよい。過去のファイルは「探されたときに初めて価値が発生する」ので、探した1件をその場で改名するほうが費用対効果が高い。まず新規保存分にだけ規則を適用し、過去分は今年のものや主要案件など触る範囲だけを一括処理する。

まとめ

要点を整理する。

• 日付は YYYY-MM-DD か YYYYMMDD に固定。実測で辞書順と自然順の両方を通ったのはこの2書式だけだった。
• エクスプローラーで並んでいても安心しない。2026年8月5日 や 2026-8-5 は自然順では並ぶが、ZIPやクラウド一覧の辞書順で崩れる。
• 要素はアンダースコア、単語内はハイフンで区切り、版数は v01、連番は 001 とゼロ埋めする。
• 使えない9文字と予約名を避ける。クラウド同期では # % と機種依存文字にも注意。
• フォルダ名20文字・ファイル名40文字を目安に。試算では6階層でも214文字で259文字に収まった。
• 過去分は100件を超えたら一括リネーム。1,000件で250分が5.33分、97.9%の削減となった。

命名規則の効果は、探す時間が減ること以上に、保存のたびの「どう名前を付けるか」という判断が消えることにある。まずは今日の新規保存分だけ、テンプレートを1つ当てはめてみてほしい。