ファイル名が2週間で使えなくなる理由
悪いファイル名は、違うクリップが承認されるまで危険に見えません。監督が scene04_final.mp4 にコメントし、編集者が scene04_final_new.mp4 をアップロードし、アーカイブには scene04_final_revised_real.mp4 が残る。2つはクロップテストで、1つには正しい芝居ビートがありますが、どのプロンプトや選択済みテイクから来たのか、名前からはわかりません。
AIアニメ制作では、この問題が増幅します。各ショットに、プロンプト下書き、参考セット、生成テイク、選択済みテイク、クリーンアップ済み完成版、声のパス、プラットフォームクロップ、カバーフレーム、アーカイブコピーが発生するからです。girl_rooftop_good.mp4 は個人実験なら使えるかもしれませんが、エピソード、言語、アスペクト比、レビュー状態、修正履歴が入ると崩れます。
命名規則は、ファイルを見つけやすくするためのもので、すべての文脈をファイル名に背負わせる必要はありません。その文脈はすでに ArcLoop の中にあります。プロジェクト、エピソード（EP1、EP2……）、絵コンテの中のshot cardです。ArcLoop の外に残すファイル——ローカル書き出しや、まだ資産に紐づいていない Reference image——は、ファイル名にプロジェクト、エピソード、ショット、バージョンを識別できるだけの構造があれば十分です。命名を制作フローに結びつけるには キャラクタープロフィール項目 を使い、同じキャラクターとロケーションに長期的な連続性が必要なときは ArcLoopワールド を使います。
編集に耐える命名のルール
名前は制作順に並ぶべきです。最も広い単位から置きます。プロジェクト、エピソードまたはシーケンス、ショット、アセット種別、バリエーション、バージョン、状態です。自然にソートできると、レビュアーは全部開かずにフォルダを確認できます。
コアの名前には、シーンの説明ではなく安定した番号を使います。「ショット2」のような番号は、「バルコニーの告白」よりも脚本修正に強いです。説明語は短いバリエーションラベルとして使えますが、番号がアンカーであり続けるべきです。
状態語彙は小さくします。draft、select、review、approved、final、rejected、archive など、限られた集合を使います。チームメイトがそれぞれ状態語を作り始めると、命名はルールではなくなります。
長い説明はファイル名に詰め込まないでください。プロンプトの内容、ショットのメモ、すべてのキャラクター名は、ファイル名に書き込む必要はありません。それらはもともとshot cardの中にあり、アイデンティティはショットが @ で参照するキャラクターアセットの中にあります。
承認済み作業を上書きから守ります。変更されたファイルに同じ名前を再利用しないでください。バージョンを上げるか、状態を変えます。基本的ですが、唯一の承認済みテイクを後のテストで静かに置き換える事故を防げます。
命名パターンの組み立て方
まず、プロジェクトが実際に使う単位を選びます。短い単発クリップなら、プロジェクト、ショット、アセット種別、バージョン、状態だけで足りるかもしれません。エピソード作品なら、プロジェクト、シーズン、エピソード、シーケンス、ショット、テイク、バリエーション、バージョン、状態が必要かもしれません。誰も検索しないフィールドは足さないでください。
シンプルなパターンを定義します。実用的な例は 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 の中のshot cardと、ショットが @ で参照するキャラクターまたはシーンアセットです。
一括書き出し前に命名レビューを行います。重複ID、欠けたバージョン、混在した状態語、元ショットのないファイル、マスターに見えるプラットフォームバリエーションを確認します。数分で済み、数時間を節約できます。
乱れた古いフォルダにはリネーム経路を文書化します。すでに編集者やクライアントへ共有済みのファイルは、新パッケージが受け入れられるまで、古い名前をマニフェストの別名として残します。リネームは追跡性を上げるためのもので、昨日のファイルを指すコメントスレッドを壊すためではありません。
何をファイル名に、何を ArcLoop に
ファイル名が小さいままでいられるのは、本当の文脈がすでに ArcLoop の中にあるからです。キャラクターとシーンの資産、ストーリー概要、そして各ショットがその絵コンテの中で占める位置です。つまり、NIGHT_E02_SH006_clip_vertical_v02.mp4 というローカルファイルも短く読みやすいままでいられます。詳細な物語とアイデンティティの文脈は、名前ではなく、紐づいたプロジェクトの中にあるからです。
チームにとっての実用的な境界線は、ファイル名が識別を担い、ArcLoop が意味を担う、というものです。プロジェクト、エピソード、ショット、種別、バリエーション、バージョンを名前に入れます。物語そのものはストーリー概要に入れ、実際のアイデンティティ参照はショットの説明文の中の @ で持ち込みます。
チームがローカルファイルの命名ルールを決めたら、最初の書き出しの前に書き留めておくだけでよく、それは ArcLoop の外だけに適用されます。プロジェクトの内部では、各ショットはもともとその絵コンテの中に安定した位置を持っているからです。誰も、承認後に1シーズン分を手作業でリネームする必要はありません。
同じ習慣は、複数の試みを比較するときにも役立ちます。Canvas 上では、あるショットを分岐させ、別のテイクを試し、以前のアイデアに戻ることができ、それでもどれがどれかを見失いません。ローカルに書き出すファイルに安定した名前を付ければ、この履歴をプロジェクトの外でもはっきりさせておけます。
ローカルファイルに名前をつける前に、ArcLoop 内でこの境界線がどう機能するかを見ておきましょう。
IP Project を開き、マイアセット（My Assets）へ移動します。繰り返し登場するキャラクターごとに Character asset を作成します——Copper Harbor なら船長の Elian Ro です。参考画像をコンテンツライブラリ（Library）にアップロードし、その asset に Bind して Main image として設定します。別角度や衣装の画像があれば Reference image として追加してください。
Episode 1 に入り、Generate Shots をクリックします。ArcLoop が Story Outline をもとに shot card のセットを生成します。各 shot card で @Captain Elian Ro と入力すると、船長の外見情報が引き込まれます——顔や服装を毎回説明し直す必要はありません。そのショット固有の情報だけを書きます：アクション、カメラアングル、照明。
まず Shot 1 の画像を生成してフレーミングとキャラクターデザインを確認してから、動画を生成しましょう。複数のショットをまとめて処理するには AI Chat Panel を使います："Generate videos for Shots 1, 2, and 3." テイクに満足したら、Edit でタイムラインに並べてトリミングします。
ローカルのファイル名が重要になるのは Export の段階だけです。その時点で、shot card——@ 参照、説明文、そして Storyboard 内の位置——がすべての意味ある情報をすでに保持しています。ファイル名は短くてソートしやすいラベルであれば十分です。
例 1：Copper Harbor の命名ルール
Write a file naming convention for local exports from the Copper Harbor project.
Production shape: 3 short episodes, one recurring captain character asset (@Captain Elian Ro), 8 to 12 shots per episode. Export types include master clips, vertical social cuts, cover images, and caption files.
Naming pattern: COPPER_E##_SH###_TYPE_VARIANT_v##_STATUS.ext
Allowed TYPE values: clip, cover, caption, ref.
Allowed VARIANT values: master, vertical, square, subbed.
Allowed STATUS values: draft, review, final.
Version rule: increment v## whenever file content changes. Never overwrite a file already shared with the team.
Context rule: story detail, shot descriptions, and @asset references all stay inside the ArcLoop project. The filename is a short handle, not a substitute for the shot card.
このプロンプトは、チームが守れる短さと、よくあるミスを捕まえられる厳しさを両立します。
例 2：テイク選択セットの命名
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 が却下された理由は、ショットの説明文かプロジェクトに残すメモに書き、ファイル名には書かない。
ショット説明は今でも有用ですが、置き場所はshot cardです。ファイル名は運用できる形に保ちます。
例 3：乱れた書き出しフォルダのリネーム
承認済みの命名ルールを使って、乱れた 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。
リネーム計画：新しいファイル名を作り、リネーム後のコピーが確認されるまで元のファイルを残し、旧名から新名への対応をチーム全員が見られる場所に書き留める。
クリエイティブな内容、プロンプト、字幕、承認メモは変更しない。
対応情報が十分でないファイルは、推測せずにフラグを立てる。
これが命名整理の正しい使い方です。既知の事実を対応づけ、クリエイティブ変更を避け、足りない来歴は推測しません。
ファイル命名が崩れるパターン
最も多い失敗は、final を早く使いすぎることです。ファイルは、クリエイティブ選択済み、納品レビュー中、プラットフォームクロップ、アーカイブ済みのどれかかもしれません。final は必要なチェックを通過した納品物だけに使います。
もうひとつの失敗は、物語全体を名前に詰め込むことです。sad-captain-foggy-pier-compass-closeup-best-v2 は便利に見えますが、ソートを壊し、承認状態も残しません。物語語彙はshot cardへ置きます。
チームが命名ルールを混在させることもあります。ある制作者は E1S4、別の制作者は ep01-shot004、編集者は scene4 と書く。生成開始前に1つのパターンを決めます。
4つ目の失敗は、プラットフォームバリエーションがマスターのように見えることです。縦クロップ、正方形クロップ、字幕付き版、クリーンマスターは別の納品物です。variant フィールドで明確にします。
よくある質問
すべての AIアニメファイル名に入れるべきフィールドは？
プロジェクト、必要ならエピソードまたはシーケンス、ショットID、アセット種別、バリエーション、バージョン、状態を使います。小さなプロジェクトでは使わないフィールドを落とせますが、変更されたファイルにはバージョンが必要です。
キャラクター名をファイル名に入れるべきですか？
通常は不要です。キャラクターのアイデンティティはすでにマイアセットの中の資産上にあり、ショットが @ で参照すれば持ち込まれるので、ファイル名に繰り返し書く必要はありません。代わりにエピソード番号とショット番号を使います（E02_SH007 のように）。そのほうが並び替えやすく、脚本の書き直しにも強いです。
却下テイクはどう扱いますか？
有用な失敗を説明する場合だけ、却下ファイルを1つ残します。rejected を付けて命名し、理由はメタデータに置きます。あいまいな名前の重複却下を何十個も残さないでください。
文脈を失わずに、ファイル名を短く保つには？
ショットの説明文、@ による資産参照、そしてキャラクターアセットそのものは、プロジェクトの中でこのショットに紐づいたままです。ファイル名に必要なのは短いハンドルだけです。プロジェクト、エピソード、ショット、バージョンです。
命名ルールはいつ作るべきですか？
最初の本番バッチ前です。制作後の命名は片付けで、制作前の命名は予防です。プロジェクト設定にパターンを入れ、すべてのプロンプト、テイク、クリップ、字幕、カバーが同じルールに従うようにします。
すでに古いファイルが乱れた名前を使っていたら？
何かを変更する前に、旧名から新名への対応をチーム全員が見られる記録としてまとめます。元となるショットが明確なファイルだけをリネームします。不確かなファイルは来歴をでっち上げず、レビュー待ちとしてフラグを立てます。
