AIアニメのファイル命名とは
悪いファイル名は、違うクリップが承認されるまで危険に見えません。監督が scene04_final.mp4 にコメントし、編集者が scene04_final_new.mp4 をアップロードし、アーカイブには scene04_final_revised_real.mp4 が残る。2つはクロップテストで、1つには正しい芝居ビートがありますが、どのプロンプトや選択済みテイクから来たのか、名前からはわかりません。
AIアニメ制作では、この問題が増幅します。各ショットに、プロンプト下書き、参考ボード、生成テイク、選択済みテイク、クリーンアップ済み完成版、声のパス、プラットフォームクロップ、カバーフレーム、アーカイブコピーが発生するからです。girl_rooftop_good.mp4 は個人実験なら使えるかもしれませんが、エピソード、言語、アスペクト比、レビュー状態、修正履歴が入ると崩れます。
命名規則は、ファイルを見つけやすくするためのもので、すべての文脈をファイル名に背負わせる必要はありません。その文脈はすでに ArcLoop の中にあります。プロジェクト、エピソード（EP1、EP2……）、絵コンテの中のショットカードです。ArcLoop の外に残すファイル——ローカル書き出しや、まだ資産に紐づいていない Reference image——は、ファイル名にプロジェクト、エピソード、ショット、バージョンを識別できるだけの構造があれば十分です。命名を制作フローに結びつけるには ワークフローテンプレート を使い、同じキャラクターとロケーションに長期的な連続性が必要なときは ArcLoopワールド を使います。
アニメファイル名の基本原則
名前は制作順に並ぶべきです。最も広い単位から置きます。プロジェクト、エピソードまたはシーケンス、ショット、アセット種別、バリエーション、バージョン、状態です。自然にソートできると、レビュアーは全部開かずにフォルダを確認できます。
コアの名前には、シーンの説明ではなく安定した番号を使います。「ショット2」のような番号は、「バルコニーの告白」よりも脚本修正に強いです。説明語は短いバリエーションラベルとして使えますが、番号がアンカーであり続けるべきです。
状態語彙は小さくします。draft、select、review、approved、final、rejected、archive など、限られた集合を使います。チームメイトがそれぞれ状態語を作り始めると、命名はルールではなくなります。
長い説明はファイル名に詰め込まないでください。プロンプトの内容、ショットのメモ、すべてのキャラクター名は、ファイル名に書き込む必要はありません。それらはもともとショットカードの中にあり、アイデンティティはショットが @ で参照するキャラクターアセットの中にあります。
承認済み作業を上書きから守ります。変更されたファイルに同じ名前を再利用しないでください。バージョンを上げるか、状態を変えます。基本的ですが、唯一の承認済みテイクを後のテストで静かに置き換える事故を防げます。
ファイル命名ワークフロー
まず、プロジェクトが実際に使う単位を選びます。短い単発クリップなら、プロジェクト、ショット、アセット種別、バージョン、状態だけで足りるかもしれません。エピソード作品なら、プロジェクト、シーズン、エピソード、シーケンス、ショット、テイク、バリエーション、バージョン、状態が必要かもしれません。誰も検索しないフィールドは足さないでください。
シンプルなパターンを定義します。実用的な例は PROJECT_EPISODE_SHOT_TYPE_VARIANT_v##_STATUS.ext です。たとえば GARDEN_E01_SH012_clip_master_v03_approved.mp4。大文字小文字を統一し、スペースを避けると、各ツールで書き出しが安定します。
type と variant の許可値を作ります。Type は prompt、ref、take、clip、cover、voice、caption、manifest、note。Variant は master、vertical、square、clean、subbed、cropA、paletteB などです。許可値があると、フォルダのブレを防げます。
バージョンルールを書きます。下書きや修正では、ファイル内容が変わるたびにバージョンを上げます。状態変更は、状態付きコピーを作る場合も、マニフェスト状態を更新する場合もあります。ワークフロー次第です。重要なのは、内容変更で承認済みファイルを上書きしないことです。
ファイル名はプロジェクトに結びつけるだけでよく、それを置き換えようとする必要はありません。プロジェクト、エピソード、ショットを含む短い名前で十分です。本当の拠り所は、あくまで ArcLoop の中のショットカードと、ショットが @ で参照するキャラクターまたはシーンアセットです。
一括書き出し前に命名レビューを行います。重複ID、欠けたバージョン、混在した状態語、元ショットのないファイル、マスターに見えるプラットフォームバリエーションを確認します。数分で済み、数時間を節約できます。
乱れた古いフォルダにはリネーム経路を文書化します。すでに編集者やクライアントへ共有済みのファイルは、新パッケージが受け入れられるまで、古い名前をマニフェストの別名として残します。リネームは追跡性を上げるためのもので、昨日のファイルを指すコメントスレッドを壊すためではありません。
何をファイル名に書き、何を ArcLoop の中に残すか
ファイル名が小さいままでいられるのは、本当の文脈がすでに ArcLoop の中にあるからです。キャラクターとシーンの資産、ストーリー概要、そして各ショットがその絵コンテの中で占める位置です。つまり、NIGHT_E02_SH006_clip_vertical_v02.mp4 というローカルファイルも短く読みやすいままでいられます。詳細な物語とアイデンティティの文脈は、名前ではなく、紐づいたプロジェクトの中にあるからです。
チームにとっての実用的な境界線は、ファイル名が識別を担い、ArcLoop が意味を担う、というものです。プロジェクト、エピソード、ショット、種別、バリエーション、バージョンを名前に入れます。物語そのものはストーリー概要に入れ、実際のアイデンティティ参照はショットの説明文の中の @ で持ち込みます。
チームがローカルファイルの命名ルールを決めたら、最初の書き出しの前に書き留めておくだけでよく、それは ArcLoop の外だけに適用されます。プロジェクトの内部では、各ショットはもともとその絵コンテの中に安定した位置を持っているからです。誰も、承認後に1シーズン分を手作業でリネームする必要はありません。
同じ習慣は、複数の試みを比較するときにも役立ちます。Canvas 上では、あるショットを分岐させ、別のテイクを試し、以前のアイデアに戻ることができ、それでもどれがどれかを見失いません。ローカルに書き出すファイルに安定した名前を付ければ、この履歴をプロジェクトの外でもはっきりさせておけます。
プロンプト例 1：Copper Harbor の命名ルール
Copper Harbor というオリジナル2Dアニメプロジェクトのローカル書き出しファイル用に、ファイル命名規則を1つ作成してください。
制作の形：短編3話、再登場する船長キャラクター、各話8〜12ショット、マスター書き出し、縦型ソーシャルカット、カバー画像、字幕ファイル。
命名パターン：COPPER_E##_SH###_TYPE_VARIANT_v##_STATUS.ext。
許可する TYPE 値：clip、cover、caption、ref。
許可する VARIANT 値：master、vertical、square、subbed。
許可する STATUS 値：draft、review、final。
バージョンルール：ファイルが変わるたびに v## を増やす。すでに共有したファイルは上書きしない。
メタデータルール：物語、ショットの説明文、`@` による資産参照は ArcLoop のプロジェクト自体に残す。ファイル名はあくまでラベルであり、アーカイブではない。
このプロンプトは、チームが守れる短さと、よくあるミスを捕まえられる厳しさを両立します。
## プロンプト例 2：テイク選択セットの命名
```text
Copper Harbor エピソード2、ショット7のテイク選択セット用ファイル名を準備してください。
ショットの背景：Captain Elian Ro が桟橋でひび割れたコンパスを手にし、銅色の灯台の背後で霧が晴れていく。
命名が必要なファイル：Canvas の分岐から書き出された3つのテイク。うち1つはコンパスがモデルからずれていたため却下された。
プロジェクトの命名パターンを使い、説明はファイル名に入れない。
出力例：
COPPER_E02_SH007_take_v01.mp4
COPPER_E02_SH007_take_v02_select.mp4
COPPER_E02_SH007_take_v03_rejected.mp4
注記：v03 が却下された理由は、ショットの説明文かプロジェクトに残すメモに書き、ファイル名には書かない。
ショット説明は今でも有用ですが、置き場所はショットカードです。ファイル名は運用できる形に保ちます。
## プロンプト例 3：乱れた書き出しフォルダのリネーム
```text
承認済みの命名ルールを使って、乱れた Copper Harbor 書き出しフォルダを監査し、リネームしてください。
現在の問題：ファイル名が final.mp4、final2.mp4、good_vertical.mp4、cover_new.png、captions_real.srt になっている。
既知の対応関係：final.mp4 は E01 SH010 master v02。final2.mp4 は E01 SH010 master v03。good_vertical.mp4 は E01 SH010 vertical v01。cover_new.png は E01 cover v02。captions_real.srt は E01 captions v01。
リネーム計画：新しいファイル名を作り、リネーム後のコピーが確認されるまで元のファイルを残し、旧名から新名への対応をチーム全員が見られる場所に書き留める。
クリエイティブな内容、プロンプト、字幕、承認メモは変更しない。
対応情報が十分でないファイルは、推測せずにフラグを立てる。
これが命名整理の正しい使い方です。既知の事実を対応づけ、クリエイティブ変更を避け、足りない来歴は推測しません。
## AIアニメのファイル命名でよくある失敗
最も多い失敗は、`final` を早く使いすぎることです。ファイルは、クリエイティブ選択済み、納品レビュー中、プラットフォームクロップ、アーカイブ済みのどれかかもしれません。`final` は必要なチェックを通過した納品物だけに使います。
もうひとつの失敗は、物語全体を名前に詰め込むことです。`sad-captain-foggy-pier-compass-closeup-best-v2` は便利に見えますが、ソートを壊し、承認状態も残しません。物語語彙はショットカードへ置きます。
チームが命名ルールを混在させることもあります。ある制作者は `E1S4`、別の制作者は `ep01-shot004`、編集者は `scene4` と書く。生成開始前に1つのパターンを決めます。
4つ目の失敗は、プラットフォームバリエーションがマスターのように見えることです。縦クロップ、正方形クロップ、字幕付き版、クリーンマスターは別の納品物です。variant フィールドで明確にします。
## FAQ：AIアニメのファイル命名
### すべての AIアニメファイル名に入れるべきフィールドは？
プロジェクト、必要ならエピソードまたはシーケンス、ショットID、アセット種別、バリエーション、バージョン、状態を使います。小さなプロジェクトでは使わないフィールドを落とせますが、変更されたファイルにはバージョンが必要です。
### キャラクター名をファイル名に入れるべきですか？
通常は不要です。キャラクターのアイデンティティはすでにマイアセットの中の資産上にあり、ショットが `@` で参照すれば持ち込まれるので、ファイル名に繰り返し書く必要はありません。代わりにエピソード番号とショット番号を使います（`E02_SH007` のように）。そのほうが並び替えやすく、脚本の書き直しにも強いです。
### 却下テイクはどう扱いますか？
有用な失敗を説明する場合だけ、却下ファイルを1つ残します。`rejected` を付けて命名し、理由はメタデータに置きます。あいまいな名前の重複却下を何十個も残さないでください。
### 文脈を失わずに、ファイル名を短く保つには？
ショットの説明文、`@` による資産参照、そしてキャラクターアセットそのものは、プロジェクトの中でこのショットに紐づいたままです。ファイル名に必要なのは短いハンドルだけです。プロジェクト、エピソード、ショット、バージョンです。
### 命名ルールはいつ作るべきですか？
最初の本番バッチ前です。制作後の命名は片付けで、制作前の命名は予防です。プロジェクト設定にパターンを入れ、すべてのプロンプト、テイク、クリップ、字幕、カバーが同じルールに従うようにします。
### すでに古いファイルが乱れた名前を使っていたら？
何かを変更する前に、旧名から新名への対応をチーム全員が見られる記録としてまとめます。元となるショットが明確なファイルだけをリネームします。不確かなファイルは来歴をでっち上げず、レビュー待ちとしてフラグを立てます。
