命名規則が崩壊する現場 — よくあるトラブルパターン
ファイル管理 命名規則が定まっていない制作現場では、必ず同じ種類のトラブルが繰り返される。その現場を具体的に見ていこう。
Webリニューアル案件の終盤、デザイナーからディレクターに「どのファイルを最終版として入稿しますか？」という確認が来た。納品フォルダを開くと、以下のようなファイルが混在していた。
design_top.psd
design_top_v2.psd
design_top_final.psd
design_top_final2.psd
design_top_final_OK.psd
design_top_最終.psd
design_top_最終確認済み_20260815.psd
このうち「どれが本当の最終版か」を確認するには、各ファイルの更新日時・ファイルサイズ・中身を逐一開いて確認するしかない。1ファイルであればまだしも、画像・テキスト・HTML・CSS・JavaScript・ドキュメント類が混在する実際の案件では、この確認作業だけで数時間を失う。
命名規則の崩壊が引き起こす具体的な問題を列挙する。
1. 上書き事故
異なる担当者が同名ファイルを別々に更新し、片方の作業が消去される。クラウドストレージの同期タイミングによっては、直前まで行った作業が無音で上書きされる。
2. 取り違え納品
修正前のファイルを誤って納品する。「_draft」「_wip」などの未完成印がなく、完成版と同じ命名になっているファイルが混在することで発生する。
3. レビューサイクルの崩壊
クライアントへのフィードバック依頼メールに添付したファイルと、実際にレビューされたファイルが食い違う。「前回送ったバージョンに戻してほしい」という要望に対応できなくなる。
4. 担当者交代時の引き継ぎ不能
フォルダ構成 ルールが存在しないため、新担当者が現状把握に数日を要する。最悪の場合、どのファイルが有効なのかを前任者に確認しなければ判断できなくなる。
5. 外部パートナー間の認識ズレ
フリーランスのデザイナー・エンジニア・ライターなど複数の外部パートナーが関与する案件では、それぞれが異なる命名規則で納品してくる。ディレクターがとりまとめる際に名称統一作業が発生し、見積もり外の工数が積み上がる。
これらの問題は「担当者の意識が低い」という属人的な問題ではない。ルールが存在しないために、各人が善意で命名しても結果として混乱が生まれる構造的な問題である。
ファイル名設計の原則 — 三要素と禁止事項
ファイル名 つけ方の基本は、三要素の組み合わせに集約される。この構造を理解すれば、どんな種類のファイルにも応用できる。
命名規則の三要素
要素1：日付（YYYYMMDD形式）
日付は必ずISO 8601準拠の8桁数字（例：20260910）を使う。「R6.9.10」「2026/9/10」「Sep-10」といった形式は使用禁止とする。理由は二つある。第一に、ファイル名でソートしたとき日付順に並ばない。第二に、OS・クラウドサービス間での文字列解釈が一致しない場合がある。
要素2：案件名またはコンテンツ名
半角英数字とアンダースコアのみを使う。スペース・スラッシュ・カッコ・アンパサンド（&）・プラス（+）は禁止とする。日本語はすべて禁止ではないが、ファイルをURLやシステムに組み込む可能性がある場合（Webファイルなど）は必ず半角英数字に変換する。
案件名は短縮表記を案件開始時に決定する。例えば「ABCコーポレーションWebサイトリニューアル」であれば「abccorp-web」のようにプレフィックスを決める。この短縮表記を全担当者が統一して使うことがフォルダ管理の精度を高める。
要素3：バージョン（v01形式）
バージョンは「v＋ゼロ埋め2桁」で統一する（v01, v02, v03…）。「v1」「ver1」「V1」「_1」「(1)」は全て異なる表記として扱われてしまうため、チーム全員で記法を統一することが必須である。
標準的なファイル名の構造例：
{YYYYMMDD}_{案件短縮名}_{コンテンツ名}_{バージョン}.{拡張子}
例：
20260910_abccorp-web_top-design_v01.psd
20260915_abccorp-web_top-design_v02.psd
20260920_abccorp-web_top-design_v03-final.psd
禁止事項リスト
ファイル名には以下を絶対に含めないこと：
| 禁止事項 | 理由 |
|----------|------|
| 半角スペース | URLエンコードの問題・シェルスクリプトでのパスエラー |
| 日本語・全角文字（Webファイル） | 環境依存の文字化け・URLでの%エンコード問題 |
| / \ : * ? " < > | | OSのファイルシステムで予約された文字 |
| final・最終・完成 | バージョン語義が重複し混乱を招く |
| 新しい・コピー・(2) | 自動生成名であり内容を示さない |
| 今日の日付のみ | 案件名・コンテンツ名がなければ後から識別不能 |
拡張子の扱い
拡張子は必ず表示し、変更しないこと。Macのデフォルト設定では拡張子が非表示になっているが、作業中はファインダーの「すべてのファイル名拡張子を表示」を有効化して運用する。拡張子を誤って変更すると、ファイルが開けなくなる事故が起きる。
バージョン管理を統一する — 「最終版」問題の解決
「最終版」問題は日本の制作現場特有の混乱として広く認識されている。この問題の根本原因は、「最終」という語義が状況によって変わることにある。
- クライアントへの初回提案時点では「初版」
- クライアントからの修正指示を反映した時点で「修正版」
- クライアントの最終承認を得た時点で「最終版」
- 印刷所・実装担当者への入稿時点で「入稿版」
これらの段階を「最終」「final」「OK」などで区別しようとするため、ファイル名が「final_finalOK_本当に最後」のように破綻する。
バージョン番号だけで管理する原則
解決策は単純である。「最終版」という表現を一切使わず、バージョン番号とステータスフラグの組み合わせのみで管理する。
バージョン番号の運用ルール：
| 段階 | ファイル名例 | 意味 |
|------|------------|------|
| 作業中 | _v01.psd | 最初の作業ファイル |
| 提案用 | _v01-proposal.psd | クライアント提示版 |
| 修正後 | _v02.psd | 修正指示反映済み |
| 承認済み | _v03-approved.psd | クライアント承認確定 |
| 入稿用 | _v03-release.psd | 実装・入稿向け書き出し |
「-approved」「-release」などのステータスフラグは、案件開始時にチームで定義したものだけを使用する。新しいフラグを各自が勝手に追加しないことがルールの核心である。
旧バージョンファイルの保管
承認後の旧バージョンファイルは削除せず、_archive フォルダに移動して保管する。削除してしまうと、後から「以前の提案に戻してほしい」「あのときのデザインを参照したい」という要求に対応できなくなる。
/project
/design
/top-page
20260910_abccorp-web_top-design_v03-approved.psd ← 有効ファイル
/_archive
20260905_abccorp-web_top-design_v01.psd
20260908_abccorp-web_top-design_v02.psd
この構造により、現在有効なファイルとアーカイブの分離が明確になる。ディレクターだけでなく、外部デザイナーや開発担当者が初めてフォルダを開いたときにも、どのファイルを参照すべきかが一目で分かる。
フォルダ構成の設計 — 案件フォルダの標準テンプレート
フォルダ構成 ルールの設計では、「誰が・いつ開いても理解できる構造」を最優先とする。
案件フォルダの標準構成
/{案件短縮名}_{YYYYMMDD開始}
/01_brief ← ヒアリングシート・要件定義・提案書
/02_contract ← 契約書・発注書・見積書・NDA
/03_reference ← 参考資料・競合調査・素材提供物
/04_design ← デザインファイル（用途別サブフォルダ）
/wireframe
/visual
/icon-logo
/_archive
/05_dev ← コーディング・実装ファイル
/06_content ← テキスト原稿・画像素材・動画
/07_deliverable ← 納品物（クライアントへの引き渡し分）
/08_report ← 進捗報告・議事録・検収書
/00_admin ← 雑多な管理ファイル（参照頻度が低いもの）
番号プレフィックスを付与する理由は、フォルダをソートしたときに論理的な順序で並ぶようにするためである。アルファベット順ではbriefよりcontractが前に来るが、業務フローとしてはbrief（ヒアリング）が先行するため、番号で順序を明示する。
フォルダ構成設計の三原則
原則1：フォルダは「誰が使うか」で切る
たとえば/designフォルダの中を「デザイナー用」「ディレクター用」で切ってはいけない。チームメンバーは変わるが、ファイルの用途（ワイヤーフレーム・ビジュアル・アイコン）は変わらない。属人的な分類より機能的な分類の方が長期間使い続けられる。
原則2：入れ子は3階層まで
フォルダの深さが4階層以上になると、パスが長くなりすぎてWindowsの260文字制限に抵触する場合がある。また、どこに何があるかを把握するコストが急増する。最大3階層を原則とし、分類が増えそうな場合はサブフォルダを新設するより命名規則で対処する方向を検討する。
原則3：フォルダ名も半角英数字を基本とする
「04_デザイン」のような日本語フォルダ名は一見分かりやすいが、ターミナル・スクリプト・クラウドAPIを通じてアクセスするときに文字エンコード問題が生じやすい。英語表記が難しい場合は「04_design」のように英語化を徹底する。
納品フォルダの設計
/07_deliverableフォルダは特別な扱いが必要である。このフォルダに入ったファイルは「クライアントへ引き渡し済み」を意味する最終成果物である。
- 納品後にこのフォルダの内容を変更しない
- 納品日付をフォルダ名に含める（例：
20260920_final-delivery） - 納品物と検収書を同一フォルダに保管する
この運用により、「いつ何を納品したか」の追跡が容易になり、後から「あのファイルを送ってほしい」「納品時点のバージョンを確認したい」という要求にも即対応できる。
受発注間の合意形成 — 着手前に決めるべきこと
ファイル管理 命名規則とフォルダ構成 ルールは、チーム内だけでなく、発注者と受託者の間でも合意しておく必要がある。合意がなければ、受託者が丁寧に管理したファイルも、発注者側で「使えない」状態になる。
合意すべき5項目
1. 命名規則（日付・案件名・バージョンの記法）
発注者側の社内ルールと受託者の命名規則が衝突する場合は、案件専用の命名規則を別途定める。どちらかの規則を一方的に押しつけると、そちらのルールに慣れていない側で命名ミスが増える。
2. フォルダ構成の標準テンプレート
どのフォルダ構造を採用するかを共有ドキュメントに明記し、双方が同じテンプレートから作業を開始する。
3. ファイル共有手段とアクセス権
Google Drive・Dropbox・Notionデータベースのどれを使うかと、誰がどのフォルダに書き込み権限を持つかを決める。「全員が全フォルダにアクセスできる」という設定は、誤操作による事故リスクが高い。
4. バージョンの確定手続き
「どのファイルを最終版とするか」の確定は、口頭ではなくメール・チャットのテキストで行う。「20260920_abccorp-web_top-design_v03.psd を最終版として承認します」という一文があれば、後から双方がバージョンを参照できる。
5. 保管期間と廃棄ルール
特にフリーランス案件では、納品後のファイル保管について取り決めをしておく必要がある。電子帳簿保存法の対象となる取引帳票（請求書・発注書等）は法定保存期間のルールが適用される。一方、制作中のドラフトファイルについては双方で保管期間を合意する。
合意書式の例
案件開始時のキックオフドキュメントに「ファイル管理規約」セクションを設け、以下の内容を明記することを推奨する。
【ファイル管理規約（案件：{案件名}）】
1. 命名規則
- 形式：{YYYYMMDD}_{案件短縮名}_{コンテンツ名}_{vXX}.{拡張子}
- 日本語ファイル名：禁止
- スペース使用：禁止
2. フォルダ構成
- 共有フォルダURL：{URL}
- テンプレート準拠：{参照先ドキュメント}
3. バージョン確定
- 最終版の確定は {メール / チャット} で文書化する
4. 保管期間
- 納品物：納品日から{X}年
- 中間ドラフト：納品検収後{Y}ヶ月で廃棄
この一文書が存在するだけで、後のトラブルの発生確率は大幅に下がる。受発注の双方が「ルールがあること」を認識して作業するだけで、自然と命名規則に従う行動が生まれるからである。
ファイル管理は地味な業務に見えるが、プロジェクト全体の品質と信頼性を支える基盤である。ファイル名 つけ方の統一・フォルダ構成 ルールの共有・バージョン管理の徹底という三点を案件着手時に整備することで、後工程での無用なコストと摩擦を大幅に削減できる。
参考文献
電子帳簿保存法関連情報（国税庁） (2024年)
情報セキュリティ10大脅威 2024（IPA） (2024年)
国民のためのサイバーセキュリティサイト（総務省） (2024年)