フォルダ・ファイル命名規則の実務ガイド｜受領・制作・納品を迷わず管理する方法【2026年版】

フォルダ名を揃えるだけでは足りない――受領・制作・納品を分ける実務設計

案件のフォルダ整理は、見た目を整えるための作業ではありません。

受領した原本を守り、制作途中のデータと納品済みファイルを分離し、第三者でも最新版を判断できる状態をつくるための業務設計です。

本記事では、もともとの01_received、02_created、03_deliverdという考え方を出発点に、Windows、macOS、クラウドストレージをまたいでも運用しやすいフォルダ構成とファイル命名規則へ再構成します。

本記事の対象

映像、写真、デザイン、文書、Web制作など、ローカルファイルとオンライン成果物を併用する案件を想定しています。組織規模にかかわらず使える一般的な構成とし、特定の個人環境だけに依存するルールは避けています。

本記事で得られる3つのポイント

  1. 受領・制作・納品・保管を混在させない標準フォルダ構成が分かります。
  2. Windows、macOS、クラウド間で問題を起こしにくい命名規則が分かります。
  3. 「final」「最新版」を増殖させない版管理と納品手順を導入できます。

なぜ重要か：「どれが原本か」「どれが最新版か」「何を納品したか」を短時間で判断できなければ、確認、復旧、再送、引き継ぎのコストが制作作業そのものを圧迫するためです。

続きを読む

現時点の結論：フォルダで工程を分け、ファイル名で状態を示す

推奨構成

フォルダは案件のライフサイクル、ファイル名は内容・状態・版を示すために使います。

project-name/
├── 00_admin/
├── 01_received/
├── 02_working/
├── 03_deliverables/
└── 90_archive/

規則を細かくしすぎると守られなくなるため、まずは5つの保存場所と、日付・案件・内容・状態・版の5要素に絞ります。

前回からの変更点

従来案 変更後 変更理由
管理情報の専用場所なし 00_adminを追加 契約、要件、議事録、URL台帳を制作物から分離するため
02_created 02_working 完成物ではなく制作途中の場所だと明確にするため
03_deliverd 03_deliverables 綴りを修正し、「納品物」という格納対象を名詞で示すため
旧版の専用場所なし 90_archiveを追加 旧版と不採用案を日常作業から退避するため
YYMMDDと末尾連番 YYYYMMDDとv001 長期保管時の年と版の意味を明確にするため

気になったポイント

POINT 1

日付を更新のたびに変えるか

更新日を毎回ファイル名へ反映すると並び替えには便利ですが、同じ論理ファイルが別名で増え、共有リンクや編集ソフトの参照関係を壊す場合があります。日付が何を表すかを決め、更新回数は版番号で管理する方が安定します。

POINT 2

英数字に統一する理由

現在の主要OSでは日本語ファイル名も通常使用できます。ただし、ZIP、古いソフト、海外環境、Web、コマンドライン、クラウド同期をまたぐほど互換性の条件が増えるため、外部共有と長期保管では英数字中心が無難です。

POINT 3

納品フォルダを共有してよいか

クライアントへフォルダ単位で共有する場合は、契約資料、内部メモ、旧版、作業用データが混ざっていないことを確認します。共有範囲は03_deliverables以下に限定する方が管理しやすくなります。

備忘録：最初に決めるのは名前より役割

命名規則だけを細かくしても、保存場所の役割が曖昧であれば整理は続きません。先に「受領原本」「制作中」「納品済み」を分離し、その後に日付、案件名、状態、版番号を揃える順番が実務的です。

規則の品質は長さではなく、説明を受けていない担当者でも同じ判断ができるかどうかで評価します。

5つの基本フォルダと役割

フォルダ 用途 主な内容 運用原則
00_admin 案件管理 契約、見積、要件、議事録、進行表、URL台帳 制作素材と分離する
01_received 受領物 提供資料、ロゴ、原稿、写真、映像、音声 原本を直接編集しない
02_working 制作中 編集データ、中間書き出し、レビュー用ファイル 日常作業はここで行う
03_deliverables 納品物 提出済みデータ、納品書、確認記録 納品時点の状態を固定する
90_archive 保管物 旧版、不採用案、完了後の作業データ 通常作業から退避する

00_admin：契約・要件・URLを管理する

00_admin/
├── 01_contract/
├── 02_requirements/
├── 03_schedule/
├── 04_minutes/
└── links.md

Figma、GitHub、Googleドキュメントなど、オンライン上に実体がある成果物は、URLだけでなく、用途、所有者、共有権限、状態、最終確認日をlinks.mdへ記録します。

01_received：受領原本を保全する

01_received/
├── 20260926_client-materials/
│   ├── documents/
│   ├── images/
│   ├── video/
│   └── audio/
└── received-log.md

受領物は原則として改変せず、制作に使う場合は02_workingへ複製します。received-log.mdには、受領日時、提供者、受領方法、内容、差し替えの有無、注意事項を記録します。

撮影素材の注意点：カメラカードの原本はフォルダ構造を維持します。アプリ固有の管理ファイルを削除したり、素材名を一括変更したりすると、XML、プロキシ、音声同期などの参照関係を壊す場合があります。

02_working：制作中データを整理する

02_working/
├── 01_source/
├── 02_project/
├── 03_review/
├── 04_export/
└── 99_temp/

01_source

制作に使用する複製素材を置きます。

02_project

編集ソフトやデザインツールのプロジェクトファイルを置きます。

03_review

確認依頼用の中間成果物を置きます。

04_export

用途別の書き出しデータを置きます。

99_temp

削除しても再生成できるキャッシュや一時ファイルを置きます。

03_deliverables：実際に渡したファイルだけを残す

03_deliverables/
├── 20260926_delivery-01/
│   ├── files/
│   ├── delivery-note.pdf
│   └── checksum.txt
└── delivery-log.md

納品候補ではなく、実際にクライアントへ渡したファイルだけを保存します。納品後の修正は02_workingへ戻して新版を作成し、過去の納品物を上書きしません。

納品ログに残す項目

納品日時、宛先、納品方法、ファイル名、版、承認者を記録します。映像では、ファイル容量、再生時間、解像度、フレームレート、コーデックも残すと照合しやすくなります。

90_archive：旧版と不採用案を退避する

旧版、不採用案、作業終了後も一定期間残す中間データを退避します。oldやmiscのように意味が広すぎる名称は避け、必要に応じて移動理由と保管期限を記録します。

注意：90_archiveはバックアップではありません。機器故障、誤削除、ランサムウェアなどに備えるバックアップは、別媒体または別サービスで設計します。

ファイル名の標準形式

標準書式

YYYYMMDD_project_content_status_vNNN.ext

20260926_hogehoge-pj_design_draft_v001.ai
20260926_hogehoge-pj_design_review_v002.pdf
20260927_hogehoge-pj_design_approved_v003.pdf
要素 ルール 例
日付 4桁年のYYYYMMDD 20260926
案件名 短く固定した識別子 hogehoge-pj
内容 対象が分かる名詞 logo-guide
状態 定義済みの語だけを使用 draft、review
版数 3桁のゼロ埋め v001、v002
拡張子 アプリが付与したものを維持 .psd、.pdf、.mp4

日付は「何の日付か」を先に決める

  • 受領データ：受領日
  • 撮影素材：撮影日
  • 制作ファイル：初版作成日または更新日。案件内で統一する
  • レビュー書き出し：書き出し日
  • 納品フォルダ：納品日

同日に複数版が生じる場合は、通常v001、v002で管理します。放送、報道、撮影現場など、時刻自体が意味を持つ場合だけYYYYMMDD-HHMMを使います。

状態名と版番号を分ける

状態 推奨語 意味
作業中 wip 編集中で未確定
初稿 draft 最初に提示する案
確認中 review 確認・フィードバック待ち
修正済み revised 指摘を反映済み
承認済み approved 内容の承認が完了
納品済み delivered 実際の納品が完了
保管対象 archived 通常作業から退避済み

finalは技術的に禁止された語ではありません。ただし、final2、final_final、最新版が増える運用は避けます。状態はapproved、版はv003のように分けて表します。

使用する文字と避ける文字

区分 内容
推奨 半角英小文字a-z、半角数字0-9、ハイフン-、アンダースコア_
避ける記号 " * : < > ? / \ |、先頭・末尾の空白、末尾のピリオド
避ける名称 CON、PRN、AUX、NUL、COM0～COM9、LPT0～LPT9など
避ける運用 大文字・小文字だけで別ファイルを区別する、意味不明な略称を使う、拡張子を手作業で変更する

Microsoftの公式情報では、OneDriveとSharePointで使えない記号、予約名、先頭・末尾の空白に関する制約が示されています。ファイル名は、目安として拡張子を除き80文字以内に抑え、フォルダ階層も必要以上に深くしない方が扱いやすくなります。

版管理はファイル名とシステム履歴を併用する

管理方法 適した用途 注意点
ファイル名のvNNN 外部共有、納品、ローカル保存 版を増やす担当とタイミングを決める
クラウドの版履歴 共同編集、誤編集からの復元 保持条件と管理者設定を確認する
Git ソースコード、テキスト資産 巨大な映像ファイルには別設計が必要
納品ログ 納品物の確定と追跡 実ファイルとの一致を確認する

写真・映像制作での命名例

20260914_shinjuku_walk_cam-a_001.mov
20260914_shinjuku_walk_audio-main_001.wav
20260918_shinjuku_walk_edit_review_v003.mp4
20260926_shinjuku_walk_master-4k_approved_v001.mov
20260926_shinjuku_walk_youtube-4k_delivered_v001.mp4

撮影素材は撮影日、案件名、カメラまたは音声系統、連番を基本にします。編集物は日付、案件名、成果物、状態、版数を基本にします。解像度、用途、言語などは、識別に必要な場合だけ追加します。

オンライン成果物はURL台帳で管理する

# Project Links

- Service: Figma
- URL: https://www.figma.com/...
- Owner: project-owner@example.com
- Access: client-view / team-edit
- Status: approved
- Last checked: 2026-09-26
- Backup/export: 20260926_project_design_approved_v003.fig

Googleドキュメント、Googleスプレッドシート、Figma、GitHubなどは、URLショートカットだけに依存しません。所有者、共有権限、承認状態、最終確認日、必要に応じてエクスポート先を記録します。

標準運用フロー

1．開始案件開始時に標準フォルダ一式を複製します。
2．受領受領物を01_receivedへ保存し、受領ログを記録します。
3．制作使用素材を02_workingへ複製し、そこで作業します。
4．確認レビュー提出ごとに版番号を増やします。
5．承認承認された成果物だけを03_deliverablesへ複製します。
6．納品日時、宛先、方法、ファイル名、URLを納品ログへ記録します。
7．修正納品後の修正は02_workingへ戻し、新版として作成します。
8．完了一時ファイルを整理し、旧版を90_archiveへ移します。

既存データは一括改名しない

既存データを一度に改名すると、編集ソフトのリンク切れ、クラウド同期の競合、共有先の混乱を招く場合があります。新規案件または小規模案件から試し、レビューと納品を一度行ってから規則を確定します。

STEP 1新規案件で標準フォルダを試します。
STEP 2案件コード、状態語、日付の意味を1ページに定義します。
STEP 3レビューと納品を一度実施します。
STEP 4迷った箇所だけを修正します。
STEP 5確定後、新しい案件へ順次展開します。

導入後のチェックリスト

  • 受領物の原本が保全されている
  • 制作中データと納品物が分離されている
  • 日付、案件、内容、状態、版をファイル名から判断できる
  • final、final2、最新版が増殖していない
  • 納品済みファイルを後から上書きしていない
  • URL成果物の所有者と共有権限が記録されている
  • Windowsやクラウドで問題になる文字を使っていない
  • バックアップ対象と再生成可能な一時ファイルが分かれている
  • 説明を受けていない担当者でも構造を判断できる

まとめ：命名規則は小さな内部統制

命名規則の目的は、ファイル名を美しく揃えることではありません。受領原本の保全、最新版の識別、誤納品の防止、引き継ぎの円滑化を、無理なく継続できる形で実現することです。

まずは00_admin、01_received、02_working、03_deliverables、90_archiveの役割を守り、更新するファイルをYYYYMMDD_project_content_status_vNNN.extへ統一します。

ファイル名だけに全情報を背負わせず、版履歴、メタデータ、URL台帳、受領ログ、納品ログを組み合わせることが、長く使える運用の要点です。

確認に使用した主な公式資料

調査上の留意点

命名規則そのものに、すべての組織へ適用できる単一の正解があるわけではありません。本記事は、OSとクラウドサービスの公式制約を確認したうえで、制作案件に導入しやすい運用例として整理しています。実際の導入時には、使用する編集ソフト、共有サービス、納品先、保存期間、情報管理規程に合わせて調整してください。

出力日時：2026年09月26日 11時57分05秒（日本時間）

タグ

関連投稿