投稿する
マガジン
著者：アソバース編集部公開：更新：約8分で読めます

AIで作った素材をチームで共有する：命名規則とフォルダ構成

遊びをつくる

執筆にClaudeを使用しています。

同じ色と視点でそろえた木、宝箱、キツネの素材を、色鉛筆で描いたイラスト。
記事のテーマをもとに制作したAI生成イラスト。

AIツールで素材を量産できるようになると、今度は「どこに何があるかわからない」という問題が起きます。一人で作っているうちは多少ファイル名が雑でも乗り切れますが、チームになった瞬間にその混乱が全員に伝播します。「昨日の敵キャラの差分ってどれ？」「再生成したやつはどのバージョン？」という会話が増えてきたら、整理の仕組みが必要なサインです。 この記事では、AIで生成した素材をチームで扱うときに効くフォルダ構成と命名規則を具体的に示します。特定のAIツールやゲームエンジンには依存しない考え方なので、どのような制作環境でも応用できます。

この記事の目次
  1. なぜAI素材の管理は難しいのか
  2. フォルダ構成の基本設計
  3. 命名規則の設計
  4. プロンプトファイルの書き方
  5. 運用を続けるための判断基準
  6. 次の行動

なぜAI素材の管理は難しいのか

通常の素材と違い、AI生成素材には「同じプロンプトを使っても毎回微妙に変わる」「候補を大量に出して後から選ぶ」「プロンプトや設定が変わったことをファイル名だけでは追えない」という特性があります。

手作業で描いた素材なら「修正した」という行為が明確なので、_v2 を付けるタイミングもわかりやすいです。しかしAI素材は「気に入らなかったので再生成」を何十回と繰り返すため、バージョン管理の粒度の選び方が曖昧になりがちです。

また、生成時のパラメータ（プロンプト・モデル名・シード値など）はファイル自体に記録されず、後から復元できないことがほとんどです。命名規則とフォルダ構成は、この「見えない情報」をどう扱うかという問題でもあります。

フォルダ構成の基本設計

フォルダは「役割」と「状態」の2軸で整理します。役割は素材の種類（キャラクター・背景・UI・サウンドなど）、状態は制作フローの段階（生成候補・採用・却下）です。

/assets
  /characters
    /_candidates   ← 生成したが未採用
    /approved      ← チームが採用を決定したもの
    /rejected      ← 参照用に残す却下素材
  /backgrounds
    /_candidates
    /approved
    /rejected
  /ui
    ...
/prompts           ← プロンプトと生成設定を記録するテキスト群
/docs
  naming-guide.md  ← チーム内ルールの文書

_candidates にアンダースコアを付けるのは、多くのファイラーやIDEでフォルダ一覧をアルファベット順に並べたとき先頭に来させるためです。「まだ確定していない素材が一番目立つ場所にある」状態にすることで、整理忘れを防ぎます。

rejected フォルダを残す理由は、後から「やっぱりあの方向性に戻りたい」となったときに再生成コストをゼロにするためです。ストレージが気になるなら3ヶ月後に定期削除するルールを決めておくと運用しやすいです。

/prompts フォルダはこの構成の核心です。素材ファイルとは別に、生成に使ったプロンプト・モデル名・主要パラメータをテキストファイルで保存します。素材ファイルと同じ名前をベースにすることで、どの設定で何を作ったかを後から追えます。

命名規則の設計

ファイル名に含める情報を決めるときの原則は「ファイル名だけで素材の用途と状態がわかること」です。ただし長すぎるファイル名は入力ミスと検索ノイズを生みます。次の要素を優先度順に並べて取捨選択してください。

含めるべき要素

  1. 種別プレフィックス：chr（character）、bg（background）、ui、fx（エフェクト）など。検索やソートの基点になります。
  2. 対象の名称：enemy_slime、stage01_forest のように役割がわかる語。日本語は文字化けリスクがあるため英数字とアンダースコアに限定します。
  3. バリアント識別子：同一素材の差分には _a・_b などのアルファベット1文字か、_v01 形式の番号を使います。どちらかに統一し、混在させません。
  4. 状態フラグ（必要な場合のみ）：_wip（作業中）、_final など。ただしフォルダで状態を管理しているなら重複するので省略して構いません。

命名例

  • スライム敵キャラの候補A、ファイル名の例：chr_enemy_slime_a.png
  • 森ステージ背景の確定版、ファイル名の例：bg_stage01_forest_v03.png
  • HPバーのUI素材、ファイル名の例：ui_hpbar_fill.png
  • スライムの生成プロンプト、ファイル名の例：chr_enemy_slime_a.txt

v03 のように番号を2桁にするのは、ファイル名のソート順が v1・v10・v2 のようにずれるのを防ぐためです。最初から v01 にしておけばこの問題は起きません。

避けるべきパターン

  • スペースを含むファイル名（enemy slime.png）：スクリプトやゲームエンジンでパスを扱うときに予期しないバグの原因になります。
  • 日付をファイル名に含める（slime_20261020.png）：バージョン順とソート順が一致しなくなります。日付で追いたい場合はGitのコミット履歴か、スプレッドシートの管理台帳を使う方が合理的です。
  • final・final2・final_final の連鎖：これが起きたら _v 番号への切り替えどきです。

プロンプトファイルの書き方

素材ファイルと対になるテキストファイル（例：chr_enemy_slime_a.txt）には、最低限次の情報を残します。

[モデル]
Stable Diffusion XL / ComfyUI

[プロンプト]
a cute green slime monster, pixel art style, top-down view,
32x32 sprite, transparent background

[ネガティブプロンプト]
blurry, low quality, shadow

[主要パラメータ]
CFG Scale: 7  /  Steps: 30  /  Seed: 4829301

[生成日]
2026-10-15

[備考]
v01から輪郭を太くするよう調整。目の色をオレンジに変更。

このフォーマットをチームのリポジトリに docs/naming-guide.md として置いておくと、新しいメンバーが加わったときのオンボーディングコストを大幅に減らせます。テンプレートをコピーして埋めるだけにしておくのがポイントです。

運用を続けるための判断基準

命名規則は決めるより続ける方が難しいです。チームで使い始めるときに確認しておくべき問いをまとめます。

「誰がレビューするか」を決める：素材を _candidates から approved に移すのは、一人の担当者か、チーム全員の合意か。小規模チームでは「作った人以外が一人確認してから移す」というルールが現実的です。

「リネームは誰がやるか」を決める：AIツールが出力したままのファイル名（output_00342.png など）をルールに沿った名前に変えるタスクは見落とされやすいです。生成した人が即日リネームするか、週に一度まとめてリネームする日を設けるかを決めておきます。

「例外をどう扱うか」を決める：ルールに当てはまらない素材（外部から取得したフリー素材など）は専用フォルダ（例：/external）にまとめ、命名規則の例外として文書化します。無理に既存のルールに押し込もうとすると例外処理が増えてルール自体が崩れます。

次の行動

まず /docs/naming-guide.md にこの記事のフォルダ構成と命名例をベースにしたチーム専用のルール文書を1ページ作り、リポジトリのルートに置いてください。次に既存の素材フォルダを _candidates・approved・rejected の3段階に仕分けるところから始めると、現状の混乱が可視化されて優先的に整理すべき箇所が見えてきます。アソバースにゲームを投稿する際には、ZIPにまとめる前にこの構成で素材が整っているか確認すると、後から差し替えが必要になったときの作業が格段に楽になります。

マガジン一覧に戻る