アセット命名・バージョン規則｜チームで事故らないルール作り
「HeroA_final2_本当に最終.ma」（.ma は Maya のシーンファイル形式）──冗談のようで、現場でほんとうに見かけるファイル名です。命名規則の不在は、コミュニケーションコストとして毎日少しずつチームを削っていきます。逆に、よく設計された命名規則は 読むだけで構造がわかる「無言のドキュメント」 として働き、レビューも自動化も滑らかに進みます。
本記事では、命名規則を設計するときの3原則・典型パターン・バージョン管理戦略・既存プロジェクトへの段階導入手順を、現場で「うちのルールどう決める?」と聞かれたときに即答できる粒度で整理します。
夕宮たいだふぁ……みんな〜、命名って地味だけど、めちゃくちゃ効くんだよぉ。「最終_v2_本当の最終」みたいなの、笑い話じゃなくて事故の入り口なんだぁ。一緒にルールの作り方を整理していこ〜。
1. なぜ命名規則が必要なのか
ひとことで：人間の認知コストを下げ、機械的な自動化を可能にするためです。
命名規則は単なる見た目の問題ではありません。実害は次の3点に集約されます。
- 取り違え事故：似た名前のファイルが複数あり、間違ったものを上書きする
- 検索コスト：何のファイルか名前から判断できず、毎回中身を開いて確認する
- 自動化の阻害：パイプラインスクリプトが想定外の名前で止まり、属人運用に戻る
少人数の短期プロジェクトなら「気合で覚える」でも回りますが、10人超え・半年超えのあたりから不在のコストが確実に表面化します。プロジェクト初期に1度ドキュメント化するだけで、その後の数百日のコミュニケーションが軽くなります。
2. 命名規則の3原則：一意性・可読性・機械可読性
ひとことで：衝突しない・人が読める・スクリプトで扱える、の3つを同時に満たします。
命名規則を設計するときの判断軸は次の3つです。下図のように3原則は三角形の関係にあり、どれかを犠牲にすると別のところで事故が起きます。
一意性（Uniqueness）
同じ名前のアセットが2つ存在しないこと。プロジェクト全体の名前空間で衝突しないように設計します。具体的には、カテゴリプレフィックス＋固有名＋バージョン の組み合わせで識別子を作ります。
可読性（Readability）
ファイル名を見ただけで、それが何のアセットか人間が判断できること。「a01.fbx」では何もわかりませんが、「CHR_HeroA_Body_v003.fbx」なら キャラクター・主人公A・体パーツ・3版 とその場で読み解けます。
機械可読性（Machine readability）
パイプラインスクリプトが、ファイル名を正規表現（パターンマッチで文字列を解析する記法）や split（文字列を区切り文字で分割するメソッド）で分解して構造を取り出せること。区切り文字を統一し、各フィールドの位置を固定することで、Python の name.split('_') だけで属性を取り出せる状態を目指します。
夕宮たいだ3つ覚えとけば、事故ぐっと減るんだよぉ。「人にも機械にも読みやすい」「ぶつからない」、これだけで違うんだぁ。気楽にいこ〜。
3. 典型パターン：プレフィックス・サフィックス・階層
ひとことで：[カテゴリ]_[アセット名]_[サブパーツ]_[バージョン].[拡張子] が現場の最大公約数です。
CHR_HeroA_Body_v003.fbx PRO_LightingDesk_v012.ma ENV_TownSquare_GroundPlane_v007.usd のように、下図の構成が広く使われます。それぞれの要素を分解して見ていきます。
カテゴリプレフィックス
アセットの種別を3〜4文字の大文字略号で先頭に置きます。種別が一目でわかると、検索・並べ替え・スクリプト分岐がすべて簡単になります。
| 略号 | 意味 | 例 |
|---|---|---|
| CHR | キャラクター | CHR_HeroA_Body |
| PRO | プロップ（小道具） | PRO_TreasureChest |
| ENV | 環境（背景） | ENV_TownSquare |
| FX | エフェクト | FX_Explosion_Small |
| UI | UIアセット | UI_HealthBar_Icon |
| ANM | アニメーション | ANM_HeroA_Idle |
| MAT | マテリアル | MAT_Stone_Mossy |
| TEX | テクスチャ | TEX_Stone_BaseColor |
略号自体に「正解」はありません。重要なのは プロジェクト内で1つに統一されている ことです。「CHARACTER」「Char」「CHR」が混在する状態を避けます。
サブパーツ・サフィックス
キャラクターのように複数のメッシュで1アセットを構成する場合、固有名は共通にしてサブパーツだけ変えます（CHR_HeroA_Body CHR_HeroA_Hair CHR_HeroA_Weapon）。テクスチャマップ系では用途サフィックスを組み合わせ、TEX_Stone_BaseColor TEX_Stone_Normal TEX_Stone_ORM のように最後にマップ種別を付けます。チャンネルパッキング規約のサフィックス（_ORM _MSK _BC 等）は CR-05 チャンネルパッキング戦略 で扱いました。
単語区切り：snake_case / camelCase / kebab-case
区切り文字は3つの選択肢があります。
| 形式 | 例 | 向き不向き |
|---|---|---|
| snake_case | CHR_HeroA_Body | DCC・ファイル名で最も無難 |
| camelCase | chrHeroABody | Maya のノード名や変数名向き |
| kebab-case | chr-heroA-body | Web URL 向き。UE では嫌われる場面あり |
ファイル名は snake_case、Maya ノード名は camelCase、Web URL は kebab-case という使い分けが無難です。プロジェクトで大原則を1つ決めたら、例外も含めて文書化します。
夕宮たいだていねいに整理するねぇ。区切り文字、プロジェクトでひとつに揃えとくのが大事なんだぁ。混在してると検索もスクリプトも一気にダメになるんだよぉ。
4. バージョン管理戦略：v番号と latest の運用
ひとことで：v番号で履歴を残し、latest で最新を指す、の二段構えが王道です。
バージョン管理は、命名規則の中で最も事故が起きやすい領域です。
バージョン桁数：v01 vs v001
ファイル名末尾の v 表記は、桁数を 最初に 決めます。
- v01〜v99：100版未満で完結する小規模アセット向き
- v001〜v999：長期プロジェクトの主要アセット向き
迷ったら v001 桁 で揃えるのが安全です。v9 v10 のように桁が変わると、ファイルマネージャでの並び順が「v1, v10, v11, v2, v3…」のように壊れる事故が頻発します。ゼロパディングは並び順の安定性のために絶対に必要です。
「latest」を指す3つの方式
「常に最新を参照したい」要件は必ず出てきます。実装方式は3つです。
| 方式 | 概要 | 向き不向き |
|---|---|---|
| ①シンボリックリンク | HeroA_latest.fbx → HeroA_v003.fbx の OS リンク | UNIX系で楽。Windows の SMB 共有で破綻しやすい |
②latest 名のファイル | 最新版を HeroA_latest.fbx として複製・上書き | 全 OS で動く。容量を食う |
| ③別ディレクトリ | published/ に最新だけを置く | 参照管理がきれい。発行手順が必要 |
ゲーム業界では ③別ディレクトリ方式 が広く使われています。work/HeroA_v003.fbx を作業ディレクトリに置き、レビュー通過後に published/HeroA.fbx（バージョン番号なし）として配信ディレクトリへ複製する流れです。リファレンス側は常に published/HeroA.fbx を見るので、作業中の半端な状態が参照されません。
夕宮たいだうぐぅ……latest の運用、最初みんな迷うんだぁ。シンボリックリンクは便利だけど Windows でハマったり、コピーは容量食うし、ディレクトリ分けるのは手順が増えるし……むずかしいねぇ。
5. リファレンスとプロジェクト構成
ひとことで：DCCのリファレンス機能とフォルダ階層を、命名規則と連動させて設計します。
リファレンス vs インポート
DCC（Maya / Houdini / Blender 等）には、外部ファイルを取り込む方式が2系統あります。
- リファレンス：外部ファイルへの「リンク」。元ファイルを更新すると参照先にも反映される
- インポート：外部ファイルの内容を「コピー」。取り込み後は元ファイルと切り離される
キャラクターやプロップなど、何度も更新される可能性があるアセット はリファレンスで運用します。レイアウトシーンは複数のキャラ・プロップをリファレンスで参照しておき、各アセットが更新されれば自動で反映される構造です。
リファレンスを安全に運用するには、「参照先のパスとファイル名が変わらない」ことが前提になります。命名規則とフォルダ構成が固まっていないと、リファレンスは即座に破綻します。
フォルダ構成の典型パターン
下図のように、/assets/{種別}/{固有名}/{サブカテゴリ}/ の3階層が基本です。例えば /assets/characters/HeroA/ の下に model/ texture/ rig/ anim/ のサブフォルダを切り、CHR_HeroA_Body_v003.fbx TEX_HeroA_BaseColor_v002.png RIG_HeroA_v005.ma のように配置します。
ポイントは 「アセット単位」でフォルダを切る ことです。種別単位（/models/all_models/）にすると、HeroA のモデル・テクスチャ・リグが別フォルダに散らばり、関連ファイルの追跡が困難になります。
バージョン管理システムとの関係
3D アセットは大半がバイナリ（テキストではない圧縮された生データ）で Git（プログラマー向けのバージョン管理ツール）の素のままでは扱いにくく、選択肢は Perforce（ゲーム業界の事実上の標準・商用）／Git LFS（Git Large File Storage：Git の大容量ファイル拡張）／Plastic SCM（Unity と統合された商用 VCS）の3つが代表です。どれを選んでも、命名規則とディレクトリ構成は VCS（Version Control System：バージョン管理システム）とは独立して設計 してください。VCS を乗り換えても命名規則が一貫していれば移行コストは大幅に下がります。
6. 既存プロジェクトへの段階導入
ひとことで：いきなり全リネームせず、新規アセットから段階的に切り替えます。
「明日からこの命名規則で運用します」と全アセットを一斉リネームするのは、ほぼ確実に事故ります。リファレンス先のパスが切れ、リグが壊れ、レイアウトが崩れます。現実的な導入手順は次の3段階です。
ステップ①：新規アセットから新規則を適用
まず 新規作成のアセットだけ に新ルールを適用します。既存アセットには手を付けません。新ルールでアセットが10〜20本溜まった段階で、ルールの抜け漏れが見えてくるので、ドキュメントを微修正します。
ステップ②：リネームバッチで主要アセットを移行
主要アセット（メインキャラ、頻用プロップ）だけを Python スクリプトで一括移行します。処理は「ファイル名のリネーム」「DCC ファイル内のリファレンスパス書き換え」「レイアウトシーンの参照更新」の3点。Maya cmds.file(reference=...)、Houdini hou.node().parm() などで API 経由で書き換えるのが鉄則で、手作業はほぼ確実に事故ります。
ステップ③：旧形式の deprecation 宣言
新規則のアセットが大半になった段階で、旧形式の「廃止予定（deprecation）」を宣言します。「2026年Q3末までに旧形式は使用禁止」のような期限付き告知をして、この期限以降は新規で旧形式を作らないルールにします。
夕宮たいだぁぅ……いきなり全部はキツいんだぁ。リファレンスが切れると、レイアウトもリグも全部壊れちゃうから、ほんと気をつけてねぇ。新規からじわじわが安全だよぉ。
7. ハンズオン演習
ひとことで：自プロジェクトの命名規則を、A4 1ページの雛形に書き起こします。
実装より先に ドキュメント化 が最優先です。次の項目を1ページに収めてください。
1. 適用範囲：このルールが適用されるプロジェクトと例外 2. カテゴリプレフィックス一覧：CHR / PRO / ENV / FX 等の略号と意味 3. 基本フォーマット：[カテゴリ]_[固有名]_[サブパーツ]_[バージョン].[拡張子] 4. 区切り文字：snake_case を採用、例外（Maya ノード名は camelCase）も明記 5. バージョン桁数：v001 形式で固定 6. latest 方式：published/ ディレクトリに最新版を発行 7. フォルダ構成例：/assets/{種別}/{固有名}/{サブカテゴリ}/ 8. VCS：使用するシステム（Perforce / Git LFS 等）と運用ルール 9. 改訂履歴：日付・改訂者・変更内容
ドキュメントは チームの誰もが10分で読める量 に抑えます。雛形ができたらリード3〜4人でレビューし、抜け漏れを潰してから公開します。
8. チェックリスト
ひとことで：命名規則を設計するときのセルフチェック項目です。
- [ ] 3原則（一意性・可読性・機械可読性）を満たしている
- [ ] カテゴリプレフィックスをプロジェクト内で1つに統一している
- [ ] 区切り文字（snake_case 等）を1つに決めて文書化している
- [ ] バージョン桁数（
v001形式）が決まっている - [ ] 「latest」の指し方が3方式のいずれかで明文化されている
- [ ] フォルダ構成がアセット単位で切られている
- [ ] リファレンスパスが固定される運用になっている
- [ ] 命名規則ドキュメントが A4 1ページに収まっている
- [ ] 既存プロジェクトには段階導入する計画がある
- [ ] 日本語ファイル名・スペース・特殊記号を使わないルールになっている
9. よくある間違い・トラブルシュート
ひとことで：区切り文字バラバラ・カテゴリ未統一・桁数不足・日本語名、が定番です。
区切り文字がバラバラ
CHR_HeroA-Body_v003.fbx のようにアンダースコアとハイフンが混在すると、split('_') で取れる要素数が予測できなくなり、スクリプトが破綻します。プロジェクト初期に1つに決め、文書化してください。
カテゴリプレフィックスが未統一
CHR_HeroA Char_HeroB CHARACTER_HeroC が混在すると、grep（コマンドラインの文字列検索ツール）や検索が機能しません。「キャラは CHR」と決め切ったら、その表記以外は CI（Continuous Integration＝継続的インテグレーション。コミット時に自動でテストやチェックを走らせる仕組み）でリジェクトするのが理想です。
バージョン桁数の不足
v01 v02 … v99 v100 のように桁が変わると、ファイルマネージャでの並びが時系列順に壊れます。最初から v001 の3桁で揃えるのが鉄則です。
日本語ファイル名
勇者A_本体_v003.fbx のような日本語ファイル名は、DCC で読めない・Perforce で文字化けする・シェルでエスケープが必要、といった事故が複合します。ファイル名は ASCII のみ が業界の鉄則です。
スペース・特殊記号・「最終」表記
ファイル名にスペース・括弧・記号（# ! & 等）を含めると、シェルとスクリプトでエスケープを強要されます。区切りはアンダースコアまたはハイフン、それ以外は使わない、で統一してください。同様に HeroA_final.ma HeroA_本当に最終.ma のように状態を名前に埋め込むのも典型的な敗北パターンで、バージョン番号 + 別ディレクトリ方式の latest で表現するのが正解です。
夕宮たいだふぁ……命名規則の全体像、これでだいたい OK ……かなぁ。あとはチームで決めて、ドキュメントに書いて、新規から導入していくだけだよぉ。地味だけど、効くんだぁ。
10. 次に読む記事
ひとことで：命名規則を支えるパイプライン自動化と、レビュー設計に進みます。
- CR-10 Pythonで横断パイプライン：命名規則を活かす自動化スクリプトの実装
- CR-14 レビュー・QAの設計：命名違反を弾くレビュー・自動チェックの組み立て方
- CR-08 USD入門：USD の Prim パス設計と命名規則の関係
- MY-B14 シーン保存の作法と命名規則：Maya 視点でのシーン保存運用詳細（公開準備中）
