ゲームアセット制作の流れ｜AIゲーム開発の発注・検収・差し替え

2026年10月4日

バーティカルスライスで「この品質で作れる」と確かめたら、いよいよ量産（プロダクション）に入ります。量産の中心になるのが、ゲームに入る素材＝アセットを、決めた品質と規格で、決めた数だけそろえる工程です。完成までの速さと品質を左右するのは、絵や 3D モデルを作る技術そのものより、「何を・何個・どの仕様で・誰が・いつまでに作り、どう確かめて、どうゲームに差し替えるか」を管理できるかどうかです。全体の流れは「ゲーム開発の全工程マップ」で確認できます。

本記事では、アセットリストの作り方、仕様の決め方、仮素材から本素材への差し替え、スタイルガイド、外注の発注書・検収・リテイク、購入素材とフォントのライセンス確認、管理のしかたを順に解説し、最後に生成AIを使う場合の分担と落とし穴を、筆者の実例とあわせて紹介します。BGM と効果音は「ゲームのBGM・効果音の作り方」、3DCG の技術的な詳細は、記事の中で紹介する 3DCG の解説記事で扱います。

夕宮たいだ

ふぁ……みんな〜、今日は「素材をそろえる」話だよぉ。1枚描くより、100枚をそろえるほうがずっと大変なんだぁ。順番に見ていこ〜。

ゲームアセットとは

ひとことで：ゲームの中で使う素材（絵・3D・アニメーション・UI・エフェクト・文章・音など）のことで、プログラムが読み込んで使う「部品」です。

種類	例	主に決める仕様
2D の絵	背景・立ち絵・アイコン・カードの絵	縦横の画素数、透過、基準点
3D	キャラクター・小物・建物	ポリゴン数、テクスチャの大きさ、単位と軸
アニメーション	歩く・攻撃・表情	コマ数、ループするか、骨の名前
UI	ボタン・枠・アイコン	状態（通常・選択・押下・無効）、伸び縮みする部分
エフェクト	爆発・光・魔法	連番の枚数、重ね方、画面への負荷
文章	台詞・説明文・用語	1行の文字数、表記の決まり、差し込む変数
音	BGM・効果音・声	形式・ループ・音量（詳しくは音の記事）

アセット制作の難しさは、1点の質より、量とそろい方にあります。数百点の素材を、別々の人（や AI）が、別々の時期に作っても、同じゲームに見えなければなりません。そのために、次の流れで進めます。

①アセットリストを作る（何を・何個・どの仕様で）
②仕様とスタイルガイドを決める（どう作るか・どう見せるか）
③仮素材で組む（ゲームは先に動かしておく）
④作る・発注する
⑤検収する（決めた観点で確かめる）。直しがあればリテイクを出す
⑥本素材に差し替え、ゲームの中で確かめる
⑦版を管理し、確定させる

ゲームアセット制作の流れ。リストと仕様を決め、仮素材で組み、作る・発注して検収し（直しはリテイクで戻す）、本素材に差し替えて版を確定する。下をライセンスと生成AIの使用の台帳が通る — 図1：検収とリテイクを繰り返しながら、仮素材を本素材に差し替えていく

アセットリストを作る

ひとことで：何を・何個・どの仕様で・誰が・いつまでに作るかを1つの表にまとめ、量の見積もりと進み具合の基準にします。

アセットリストは、ゲームに入る素材を1行ずつ並べた表です。企画書や仕様書、シナリオを頭から読み、場面やステージごとに必要な物を書き出して作ります。列の例を挙げます。

ID	名前	種類	仕様	数	担当	期限	状態
bg_town_day	街の広場（昼）	背景	1920×1080・PNG	1	外注	第8週	発注済み
chr_hero_face	主人公の表情差分	立ち絵	立ち絵と同じキャンバス・透過 PNG	10	自作＋AI	第6週	仮素材
ui_btn_main	決定ボタン	UI	通常・選択・押下・無効の4状態	4	自作	第5週	検収済み
fx_hit_small	小さな打撃の光	エフェクト	連番8コマ・加算合成	1	購入素材	第7週	ライセンス確認済み

ほかに「優先度（必須／あれば良い）」「使う場所（どの画面・どの場面か）」「仮か本か」「版」などの列を足すと便利です。優先度を付けておくと、期限が迫ったときに削る物をすぐ選べます（「ゲーム開発のスケジュールとマイルストーン」）。

数え漏れが多いのは「差分」です。立ち絵1人に表情が10種類なら10枚、8方向に歩くキャラクターの歩きが4コマなら32枚、ボタン1つに4つの状態があれば4枚、多言語に対応するなら、文字の入った画像は言語の数だけ必要です。リストには「1つの素材に何種類の版があるか」を必ず書き、合計の枚数で見積もります。

表計算ソフトで作る場合も、ID とファイル名を一致させ、CSV などの機械で読める形で書き出せるようにしておきます。スクリプトでリストとフォルダを照らし合わせれば、「リストにあるのにファイルがない」「仮のまま残っている」を自動で数えられます。

夕宮たいだ

うぐぅ……表情や向きの差分を数えたら、思ってた倍になってた、ってあるあるなんだぁ。先に数えておこうねぇ。

仕様を決める（サイズ・形式・命名・色空間）

ひとことで：作る前に、大きさ・形式・名前・色の扱い・基準点などを決め、誰が作っても（AI が作っても）同じ規格でそろうようにします。

項目	決めること	例
大きさ	縦横の画素数。3D なら実寸とポリゴン数の上限	立ち絵は全キャラクター同じキャンバスの大きさにする
形式	書き出す形式と、元データの形式	書き出しは PNG、元データはレイヤー付きのまま保管
透過と余白	背景を透かすか、周りに余白を残すか	立ち絵は切り抜き、周りに少し余白を残す
基準点（ピボット）	置いたときに基準になる点	立ち絵は足元の中央、3D のキャラクターは足元の中心を原点にする
足元の位置	地面に立つ位置をそろえる	立ち絵の足元を、画像の下端から同じ高さにそろえる
命名	ファイル名の規則	種類_名前_状態_番号（例：chr_hero_smile_01）
色空間	色の画像か、データの画像か	色を表す画像は sRGB、法線やラフネスなどのデータはリニアとして読み込む
表示の大きさ	ゲームの中で何画素で表示されるか	表示より大きく作って縮める。ドット絵は整数倍で拡大する

テクスチャの大きさは、512・1024・2048 のような2の累乗にそろえることがよくあります。エンジンによっては、2の累乗でない画像の扱いを読み込みの設定で決めます（例：Unity の「Non Power of 2」は、2の累乗でない画像を、読み込むときに近い大きさへ拡大・縮小する設定です）。

命名と版の付け方は「アセット命名・バージョン規則」、色空間は「DCC→エンジンの色合わせ」、3D のテクスチャの解像度の決め方は「UVとテクセル密度の設計」で詳しく解説しています。

仕様は文章だけでなく、仕様どおりに作った見本を1点用意すると伝わります。外注先にも AI にも、「この見本と同じ規格で」と渡せるからです。

仮素材から本素材への差し替え

ひとことで：最初は仮の素材でゲームを組み、あとで同じ名前・同じ大きさ・同じ基準点の本素材に置き換えるだけで済むように作っておきます。

素材がそろうのを待っていると、プログラムも遊びの調整も止まってしまいます。そこで、最初は仮素材（単色の四角、灰色の箱、仮の絵）でゲームを組み、本素材ができた物から差し替えます。差し替えを楽にするには、次のように作ります。

名前と置き場所を本番と同じにする：本素材のファイルで上書きするだけで差し替わる
大きさ・基準点・当たり判定を本番と同じ規格にする：差し替えたら位置がずれる、を防ぐ
コードに素材の場所を直接書かない：素材の一覧（データの表）から読む形にしておく
仮素材は、仮だと一目で分かる見た目にする：例えば派手なピンクの単色、市松模様、「仮」の文字
仮の状態を記録し、発売前に自動で検査する：アセットリストで状態が「仮」の物や、仮素材だけに使う色（例：ピンク）が残っていないかを、ビルドの前にスクリプトで調べる
仮で置いた購入素材や生成素材も、出どころを記録する：仮のつもりの素材がそのまま製品に残ると、ライセンスや開示の確認から漏れる

仮素材（ピンクの人型）と本素材（灰色の人型）を、同じ名前・同じ大きさ・同じ基準点でそろえ、上書きするだけで差し替える。下にビルド前の自動検査 — 図2：名前・大きさ・基準点をそろえておけば、上書きするだけで差し替わる

夕宮たいだ

ほえ〜、仮素材をわざと派手なピンクにしておくのって、消し忘れ防止なんだぁ。地味だけど、効くんだねぇ。

スタイルガイドを作る

ひとことで：絵柄・色・線・光・比率などの決まりごとを、見本の画像つきでまとめ、誰が作っても同じゲームに見えるようにする資料です。

スタイルガイドは、バーティカルスライスで決めた見た目を、量産のために言葉と画像に落とした物です（「バーティカルスライスとは」）。

項目	書くことの例
色	使う色の範囲、キャラクターごとの色、影の色
線	線の太さと色、線を描くか描かないか
光	光の向き、明るさ、影の濃さ
比率	頭身、キャラクターと建物・小物の大きさの比
質感	塗り方、描き込みの量、質感の付け方
文字	UI の書体、大きさ、色
良い例・悪い例	合格の見本と、やってはいけない例を並べた画像

いちばん大切なのは、何を「正」（基準）にするかを決めておくことです。キャラクターの設定画、立ち絵、ドット絵の見本など、資料が増えるほど、資料どうしが食い違います。食い違ったときにどれを優先するかを、スタイルガイドの最初に書きます。また、スタイルガイドは長くしすぎず、画像を中心にまとめたほうが、実際に見てもらえます。

外注の発注・検収・リテイク

ひとことで：発注書で目的・仕様・見本を渡し、決めた観点で検収し、直してほしい点は場所・理由・変えない所まで具体的に伝えます。

発注書に書くこと

目的と使われ方：どの画面で、どの大きさで表示されるか。何を伝える絵か
納品物：数・大きさ・形式・レイヤーの分け方・ファイル名
見本と NG 例：スタイルガイド、参考の画像。参考にするのは「どこか」（色か、構図か、雰囲気か）を書く
守ってほしい所と、任せる所：変えてはいけない所（キャラクターの特徴・寸法）と、制作者の判断に任せる所
段階と確認の時期：ラフ→線画→仕上げ、など。早い段階ほど直しが安いので、ラフで方向を確かめる
期限・金額・支払日・リテイクの回数
権利：著作権を譲り受けるのか、使う許可をもらうのか。宣伝・移植・グッズに使う範囲、クレジットの表記、制作者が実績として公開してよい時期
生成AIの扱い：制作者が生成AIを使ってよいか。こちらが納品物を生成AIで加工したり、生成AIへの入力に使ったりしてよいか

日本では、2024年11月に施行されたフリーランス・事業者間取引適正化等法により、フリーランス（従業員のいない個人など）に仕事を頼むときは、業務の内容・報酬の額・支払期日などの取引条件を、書面か、メールや SNS のメッセージなどで明示する義務があります。頼む側に従業員がいなくても対象です（公正取引委員会の案内）。ここでの説明は法的な助言ではありません。契約の最終確認は、公式の案内や専門家で行ってください。

検収の観点

検収は、納品物が発注どおりかを確かめる作業です。観点を先に決めて発注書にも書いておくと、検収で揉めません。「レビュー・QAの設計」の3つの軸（技術・表現・規約）に沿って整理すると、次のようになります。

観点	確かめること	確かめ方
技術（仕様）	大きさ・形式・命名・透過・基準点・レイヤー	機械で判定できる物は、スクリプトで自動にする
表現	絵柄・色・比率がスタイルガイドに合うか。ゲームの中で読めるか	実際の画面に、表示する大きさで入れて見る。他の素材と並べる
規約（権利）	他の作品に似すぎていないか、使ってはいけない素材が入っていないか、文字や記号の誤り	ロゴ・実在の商標・誤字を確かめる

表現の検収は、原寸の画像を1枚ずつ見るだけでは足りません。ゲームで表示する大きさで、隣に並ぶ素材と一緒に見て初めて、浮いている色や、潰れて読めない細部に気づけます。

リテイクの出し方

リテイク（作り直しの依頼）は、具体的に、優先順位を付けて、まとめて出します。

伝わりにくい例	伝わる例
もう少しかっこよく	マントの裾を今の半分の長さに（走る動きで脚が隠れるため）。顔と色は今のまま
全体的に暗い	影の色を、スタイルガイドの影の色（灰色がかった青）に。全体の明るさは変えない
なんか違う	目の形を設定画に合わせる（今は丸すぎる）。設定画の該当する所を添付

あわせて、次の点を守ります。

直す所と、変えない所の両方を書く：直したら良かった所まで変わってしまう、を防ぐ
「必須」と「できれば」を分ける：リテイクの回数が決まっている場合は特に大切
仕様違反の直しと、方針の変更を区別する：発注書どおりでない物は直してもらう。発注後に方針を変えたなら、追加の依頼として扱う
意見はまとめて1回で出す：小出しにすると、直しが何周も続く

夕宮たいだ

「なんか違う」だけのリテイク、絶対ダメだよ！どこを・なぜ・どう直すか、変えない所まで書いてねぇ。

購入素材とフォントのライセンス確認

ひとことで：無料でも有料でも、商用利用・クレジット・改変・再配布・使える条件を確かめ、どこで使ったかを台帳に残します。

素材サイトで買った・もらった素材やフォントには、それぞれ利用条件（ライセンス）があります。確かめる項目は次のとおりです。

商用利用できるか（販売するゲームに入れてよいか）
クレジット（作者名などの表記）が必要か
改変してよいか
再配布にあたらないか（素材そのものを、取り出せる形で配ることになっていないか）
使えるエンジンやツール、買う人の売上の規模などの条件
生成AIに関する条項（AI の学習やデータ収集に使うことを禁じる、など）
規約の版と、確認した日

具体例を挙げます（2026年10月時点）。

Fab（Epic Games の素材ストア）：有料素材の Standard ライセンスには、直近12か月の総収入が10万ドル以下の買い手向けの Personal と、それを超える買い手向けの Professional がある。また、NoAI の印が付いた素材は、生成AIのためのデータ収集に使ってはいけない（Fab のライセンスと価格の説明）
RPGツクールの付属素材：2026年6月22日の改定で、正規に購入した人は、他社のツールで作った作品にも使えるようになった。ただし、改変した素材を単独で商用利用することや、素材そのものの頒布はできない（RPGツクール公式の利用規約）
効果音サイト：筆者が確認した効果音サイトの規約にも、AI の学習データへの利用を禁じる条項がありました

フォントは特に注意が必要です。メイリオや游ゴシックなど Windows に付属するフォントは、ゲームに同梱できません（ビットマップフォントに変換して同梱するのも不可）。一方、これらのフォントで作った文字の画像（ロゴなど）は、ゲームに入れられます（非商用に限られたソフトで作った場合などを除く。Microsoft のフォントの再配布に関する FAQ）。Google Fonts の Noto Sans JP などの SIL Open Font License（OFL）のフォントは同梱できますが、フォント単体での販売はできません。同梱するときは、ライセンス文（OFL.txt）と著作権表示も一緒に入れるのが安全です。無料のフォントでも、商用不可やクレジット必須などの条件が付くことがあります。

確認した内容は、素材の台帳に残します。素材名・入手元の URL・ライセンスの名前と版・確認日・使った場所・表記の要否・規約の控え（画面写真や PDF）を1行にまとめておくと、クレジットの作成や、発売前の確認がすぐに終わります。権利の考え方の詳細は「ゲーム開発の権利と規約」で解説しています。ここでの説明も法的な助言ではないので、最終確認は各規約の原文で行ってください。

夕宮たいだ

ぁぅ……パソコンに入ってるフォントだから使っていい、とはならないんだよねぇ。同梱する前に、ライセンスを確かめてねぇ。

アセットの管理（版と置き場所）

ひとことで：元データと書き出したデータを分けて保管し、名前と版の規則をそろえ、大きなファイルに向いたバージョン管理で履歴を残します。

元データと書き出しを分ける：レイヤー付きの元データ（PSD・.blend など）と、ゲームが読む書き出し（PNG・FBX など）を別のフォルダに置き、両方を残す
名前と版の規則をそろえる：「最終」「最新」のような名前を使わず、v001 のような版番号を付ける（「アセット命名・バージョン規則」）
大きなファイルに向いた管理を選ぶ：GitHub では、Git LFS を使わない通常の Git だと 100 MiB を超えるファイルは受け付けられず、Git LFS の無料枠は保存 10 GiB・転送 10 GiB/月（Free・Pro、2026年10月時点の GitHub Docs）。ほかに Perforce P4（旧 Helix Core。5ユーザー・20ワークスペースまで無料）、Unity Version Control、SVN などがある（選び方は「ゲームエンジンの選び方と開発環境」）
同時に編集しない仕組みを使う：絵や 3D のファイルは、2人が同時に直すと結合できない。Git LFS のファイルロックのような「編集中の印」を使う
リストと状態をつなぐ：アセットリストの「状態」の列に、検収に通った版を書く

AIゲーム開発でのアセット制作

ひとことで：生成AIは素材の初稿、文字や細かい図形はコード、合成と検収の判定はスクリプトに任せ、絵柄の「正」と合格の判断と権利は人が持ちます。

GDC の2026年の調査（回答2,300人超）では、業務で生成AIを使う人は全体の36%でした。その人たちの使い道は、調査・ブレストが81%、コードの支援が47%だったのに対し、アセット生成は19%で、報告書も、生成AIは素材づくりのような創作の作業にはあまり使われていないようだ、とまとめています。同じ調査では、生成AIが業界に悪影響を与えていると考える人が52%で、ビジュアル・テクニカルアートの職種では64%でした。絵を描く人と一緒に作るときや外注するときは、生成AIをどこに使うかを、前もって共有しておくことが大切です。

生成AIで素材を作る流れ

流れは外注とほぼ同じで、発注書→生成→検収→直し、です。違うのは、1回の生成が速くて安いぶん、検収と直しの回数が多くなることです。発注書（プロンプト）には、作る物の説明だけでなく、外注と同じく目的・仕様・見本・守る所を書きます。

一度にすべての差分を作らず、段階に分けるのも有効です。例えば立ち絵なら、まず通常の表情の1枚を作って承認し、それを基準に表情差分を作ります。基準の1枚が決まる前に差分を作ると、基準を直すたびに差分も全部作り直しになるからです。

分担：生成AIは素材を描く・文字や細かい図形はコード・合成はスクリプト

担当	向いている物	理由
生成AI	背景・キャラクターの絵・アイコンの絵柄・質感	初稿を速く、たくさん作れる
コード	文字・数字・記号・盤の線・牌やカードの図柄など、正確さが要る形	生成AIは、文字や規則的な図形が崩れやすい
スクリプト（合成・変換）	ロゴや文字の重ね合わせ、縮小版、状態違い（暗くした版など）、切り出し	同じ処理を何十枚にも正確に繰り返せる
人	基準（正）の決定、合格の判断、権利の確認	最終的な責任を持つ

アセット制作の分担。生成AI（素材の絵）・コード（文字・細かい図形）・スクリプト（合成・縮小・検収）・人（正・合格・権利）が、1枚の完成した素材に合流する — 図3：生成AIは素材の絵、コードは文字や細かい図形、スクリプトは合成と検収。基準・合格・権利の判断は人が持つ

検収をスクリプトで機械化する

生成AIの素材は数が多くなるので、検収のうち「仕様」の部分はスクリプトで判定します。例えば、画像の大きさ、透過、余白、足元の位置（いちばん下の不透明な画素の行）、身長（頭の上端から足元まで）、ファイル名の規則などです。機械で判定できる物を先に落とせば、人は「表現」の判断に集中できます。

人が決めること・確かめること

絵柄の「正」：どの資料を基準にするか。食い違ったらどれを優先するか
合格の判断：ゲームの中で表示したときに読めるか、このゲームらしいか
権利：使ったサービスの利用規約とプランの条件、既存の作品に似すぎていないか、開示が必要か
どの案を採るか：たくさんの案から選ぶのは人です

重心はどう動くか

初稿を作る手間は大きく減ります。その代わり、検収・直し・そろえる作業が仕事の中心になり、スタイルガイド・発注書・検収のスクリプトが、量産を支えるいちばん大事な資産になります。1点あたりにかかる人の時間は、描く時間ではなく「確かめて判断する時間」になるので、見積もりもその時間で測ります。

落とし穴

絵柄のぶれ：同じ発注書でも、回ごと・向きごと・差分ごとに少しずつ揺れます。並べて検収し、ぶれの許容範囲を決めておきます
部分修正が苦手：「ここだけ直して」と頼むと、別の所まで変わることがあります。小さな直しは、画像編集やスクリプトで直接直すほうが確実です
見本と基準の食い違い：発注書に複数の資料を渡すと、資料どうしの食い違いを AI は自分では解決できません。どれが「正」かを発注書に書きます
利用規約と開示：生成AIの出力を商用に使える条件は、サービスやプラン、作った時期で違います（例：Midjourney の2026年5月版の規約では、年間売上100万ドルを超える会社は Pro か Mega のプランが必要）。Steam では、プレイヤーが触れる絵・音・文章などを生成AIで作った場合、内容の申告（Content Survey）で開示します。作業を効率化するための AI の利用は対象外です（2026年10月時点の公式ドキュメント）。どの素材にどの AI を使ったかを、アセットリストに記録しておくと、開示の文章をすぐに書けます

依頼文は、例えば次のように書きます（書き方の基本は「Claude Code プロンプト設計」）。

Goal: 実績アイコンの「未達成版」と「64px 版」を、達成版の画像から作るスクリプトを書く
Context: 達成版は art/achievements/src/*.png（1024px・透過）。未達成版の色の決まりは docs/style_guide.md の「実績」の節。
         生成AIで描き直さない。元の画像は上書きしない
Done when: 全アイコンの2種類が art/achievements/out/ に命名規則どおりに出力され、
           64px 版を並べた一覧画像と、縮小で絵柄が潰れて見分けにくい候補の一覧が出ている

筆者の実例

筆者のゲームでは、立ち絵を2段階で発注しています。まず通常の表情の1枚を作り、筆者が承認してから、表情差分10枚に進みます。発注書は複数のサブエージェントが並列で書き、検収はメインの Claude が画像を直接見たうえで、身長と接地（足元の位置）をスクリプトで機械判定します（並列での作業は「Claude Code サブエージェント・並列作業ガイド」）。

分担は「Codex が素材を描き、Claude が合成する」です。同じエンジンから派生させたカードゲームでは、実績アイコンの達成版（1024px）だけを Codex に描かせ、未達成版と縮小版はスクリプトで作りました。38枚中35枚がそのまま合格し、残る3枚は64px に縮めると潰れて見分けにくくなったため、描き直しています。「つみこめ！イカサマ魔法麻雀」のストア用のカプセル画像は、文字のない背景だけを描かせ、立ち絵とロゴを合成しました。麻雀牌の絵柄・盤の線・文字は、生成AIだと崩れるので、コードで描いています。

うまくいかなかったこともあります。発注書に「見本に従う」と書いたところ、見本と立ち絵が食い違い、筆者が「立ち絵が正」と決め直しました。また、生成AIは初稿は得意でも部分修正は苦手なので、直しは Claude が原寸の画素をスクリプトで直す形にしています（控えを取る→置き換える→差分を検査する）。麻雀ゲームの最初のストアの審査では、AI の利用の開示が薄いことも差し戻しの理由の一つでした。素材の種類ごと（画像・BGM・文章の下書き・コード／人が作った効果音／実行中の AI 生成はなし）に書き直して、審査を通っています。

夕宮たいだ

文字や盤の線はコードで描けば、崩れないでしょ？得意なものを得意な担当に回すのがコツなんだぁ。

よくある失敗と対処

ひとことで：多くは「数え漏れ」「仕様と基準のあいまいさ」「記録の不足」から起きます。

症状	主な原因	対処
素材の数が見積もりの倍になった	表情・状態・向き・言語の差分を数えていない	リストに「版の種類」の列を作り、合計の枚数で見積もる
仮素材が製品に残った	仮の記録と目印がない	仮だと分かる見た目にし、ビルドの前に自動で検査する
納品物を入れたら位置がずれる	大きさや基準点の仕様が文書になっていない	仕様表と、仕様どおりの見本1点を渡す
リテイクが何周も続く	基準があいまい、意見を小出しにした	発注前に見本と NG 例を渡し、ラフで方向を確かめ、意見はまとめて出す
素材によって絵柄がばらばら	スタイルガイドがない、「正」が決まっていない	正を決め、良い例・悪い例を並べたガイドを作る
フォントの規約違反に後から気づいた	Windows 付属のフォントを同梱した	同梱できるフォント（OFL など）に替える。文字の画像なら可
購入素材の条件を後で知った	入手したときに規約を記録していない	入手したその日に台帳へ書く
どの素材に AI を使ったか分からない	記録していない	アセットリストに「AI の使用・ツール・日付」の列を作る
作業中のファイルが上書きされて消えた	版の管理とロックをしていない	バージョン管理を使い、編集中のファイルはロックする