ファイル命名規則:チーム向け完全ガイド

実際の現場で生き残るファイル命名規則はこの形式を使う：YYYY-MM-DD_ProjectCode_DocType_Descriptor_vNN.ext。常にISO 8601日付（ソート順が正しくなる）、短いプロジェクトコード（3〜10文字）、DocTypeのコントロールボキャブラリー、ケバブケースのディスクリプタ、2桁バージョン番号（v02であってv2ではない）、重要でない箇所は小文字。例：2026-06-12_TANAKA-RB_contract_master-services-agreement_v02.pdf。形式そのものより一貫性が重要——一つ決めて、文書化して、オンボーディングと週次クリーンアップで強制する。

日付を先頭に置く理由

ISO 8601日付（YYYY-MM-DD）をファイル名の先頭に置くとソートが解決する。2026-06-12_report.pdfはどんなファイルシステムでも、どんなクラウドドライブでも、どんなツールでも2026-06-13_report.pdfの隣に来る。日付を末尾に移せばソートは崩れ、中間に置けばランダムになる。

ISO 8601を使う理由は具体的だ。

テキストとして正しくソートされる
ロケールをまたいで曖昧さなく解析できる（06/05/2026は6月5日か5月6日か？）
全ての大手テクノロジー企業のログが使う国際標準と一致する

タイムゾーンが複数にまたがるチームでの時間依存ファイルには時刻を追加する：2026-06-12T1430Z_meeting-notes.mdはUTCを使う。「いつ作られたか」がハンドオフの明確さに影響する場合に有用だ。

スケールするプロジェクトコード

2番目の位置に短いプロジェクトコードがあると、フォルダ構造に頼らずプロジェクトでファイルを検索できる。機能するルール：

3〜10文字、全て大文字、ハイフン使用可
最初の3〜4文字でクライアントまたは社内ユニットを識別
オプションのサフィックスでプロジェクトタイプまたはフェーズを識別

例：TANAKA-RB（田中商事リブランド）、INTL-ONBRD（社内オンボーディング）、FINOPS-Q2（財務オペレーションQ2）、TANAKA-SUP-001（田中商事サポートエンゲージメント1号）。

プロジェクトコードのレジストリをNotion、Confluence、または共有スプレッドシートで管理する。新しいプロジェクトを作るとき30秒でコードを登録する。3カ月後に誰かがTANAKArebrandと呼び、自分がTanaka-RBと呼んで両方のファイルが存在する事態を防ぐ。

DocTypeのコントロールボキャブラリー

ドキュメントタイプのスロットには固定リストが必要だ。なければreport、Report、REPORT、rpt、reprt、summary、summary-report、final-reportが全て同じ意味で並ぶことになる。

スターターボキャブラリー：

brief — プロジェクトブリーフ、クリエイティブブリーフ
spec — 技術仕様またはデザイン仕様
contract — 法的合意、SOW、NDA
invoice — 請求書類
proposal — 提案書、ピッチ
report — 定期または臨時のレポート
presentation — デッキ、ピッチ、全社集会
design — デザインアセットおよび納品物
video — 生または完成済みの動画コンテンツ
audio — ポッドキャスト、ナレーション、ソースオーディオ
dataset — CSV、Excel、JSONのデータファイル
note — 議事録、作業メモ
template — 再利用可能な出発点

リストを短く保つ。誰かがwhitepaperを追加したければ、reportと本当に違うかを問う。リストレベルでの規律は複利で効いてくる。

実際に機能するバージョン番号付け

v1、v2、v3はv10に達するまで機能する。v10はv2の前にソートされてしまう。最初から2桁のバージョン番号を使う：v01、v02、v03、...、v10、v11。

99バージョンを超える可能性のある長期プロジェクトには最初から3桁：v001。

メジャーバージョンとドラフトを区別する：

v01は最初のコミット済みバージョン
v01.1、v01.2はメジャーバージョン内のマイナードラフト
メジャーバージョンは新鮮な目でレビューする価値のある実質的な変更時にバンプ

ビジネス書類にセマンティックバージョニング（v1.2.3）を使わない。ソフトウェアとAPIには適切だが、契約書やデッキには不適切だ。

finalの罠：ファイル名に「final」という単語を入れない。それはfinal、final-final、final-final-REAL、final-use-this-oneを保証する。「final」の意味にはv02を使い、バージョン番号を信頼する。

ケバブケースのディスクリプタ

ディスクリプタのスロットだけが自由形式の部分だ。守るべきこと：

小文字
ケバブケース（単語をハイフンで区切る）
短く：2〜5語
一目でわかる具体性：q2-revenue-forecastはforecastより優れる

master-services-agreementは良い。MasterServicesAgreement.pdfは悪い——大文字小文字を区別しない検索で結果が不一致になり、スクリーンリーダーが奇妙に読み上げる。master services agreementは悪い——ファイル名のスペースはコマンドラインパイプラインとURLエンコーディングを壊す。

警察国家なしの強制

200人の組織で全ファイルの命名を手動で強制はできない。できること：

オンボーディング: 入社1週目の15分でサンプル付きの命名規則を説明
テンプレート: /Knowledge/Templates/に事前命名済みのテンプレートファイルを置き、正しい形から始められるようにする
レビュー中のその場修正: 成果物をレビューするとき、誤命名ファイルをインラインでリネームし軽くコメントを付ける
週次クリーンアップパス: ローテーションで担当が10分でドリフトを修正
自動リネームボット: ハイボリュームフォルダには、新ファイルを監視してメタデータに基づいてリネームするスクリプト。Python＋watchdog＋os.renameは半日のプロジェクト

契約書、請求書、署名済み書類などの記録リポジトリには厳格な強制を検討する：SharePointドキュメントライブラリは保存前にメタデータフィールドを必須にできる。Workspace Business Plus以上のGoogle Driveラベルは特定フォルダで必須にできる。

形式固有の拡張子

拡張子は思われているより重要だ。

.pdf は編集すべきでない最終書類向け
.docxと.xlsxは編集可能なOfficeファイル向け。.docと.xlsは避ける（セキュリティ問題のある非推奨形式）
.pptxはプレゼンテーション向け。.keyはMac専用環境のみ
.mdは技術的なノートと社内wikiに——ソータブルで、Gitでdiff可能で、永久に読める
.csvはデータ交換向け。.xlsxはフォーマット付きの最終分析向け
.mp4はH.264またはH.265エンコードの動画向け。真のProRes編集が必要でなければ.movを避ける
.psd、.ai、.inddはAdobeソースファイル向け。.figはFigmaソース向け

迷ったら、専門ソフトなしで10年後も読めるフォーマットを選ぶ。PDFとMarkdownはほぼ常にそのベットに勝つ。

特殊文字と長さの上限

一部の文字はファイルシステムやクラウドツールを壊す：

避けるべき：/ \ : * ? " < > | ——WindowsやmacOSを壊すものがある
ファイル名のスペースは避ける——コマンドライン、URL、一部のツールを壊す
非ASCII文字は多言語チームで一貫して使う場合を除き避ける（ダイアクリティカルマークは現代システムでは動くが一部のレガシーツールで壊れる）
フルパスは255文字以内に保つ——一部のWindowsツールはまだこれを超えると失敗する

履歴を壊さない移行

既存の混乱に新しい規則を適用するとき、過去のファイルをリネームしない。既存のリンク、ブックマーク、参照が壊れる。代わりに：

特定の日付以降の全新規ファイルに新しい規則を適用する
進行中の業務で触れるファイルのみリネームする
アーカイブを2〜3年かけて自然に入れ替える

10,000ファイルのドライブ全体を遡及的にリネームするのは40時間のプロジェクトで、多くの場合コストに見合わない。前向きな規律が後向きなクリーンアップに勝る。

https://hexatransfer.com をお試しください——無料・アカウント不要・最大10GB。