ゲーム開発や映像制作の現場では、コマンドラインからAIモデルを呼び出してアセットを生成する働き方が現実的な選択肢になってきた。GUIツールのスライダーを手で動かす代わりに、プロンプトとパラメータを設定ファイルに書き、スクリプトで一括投入する。この変化の本質は「生成が速くなった」ことではなく、「制作プロセスを設計し、何度でも再実行できるようになった」ことにある。
本記事は、エンジニアやテクニカルアーティストがCLIとスクリプトを軸に、ゲーム用のテクスチャ、2Dスプライト、3D用の参照画像、シネマティック動画、効果音までを一貫して生成するための実践ガイドだ。単発のプロンプト例を並べるのではなく、ディレクトリ設計、設定ファイルの粒度、ジョブ管理、品質チェック、よくある失敗まで含めて、手を動かせる形で整理する。
前提：CLI×AIでアセット制作は何が変わるのか
従来のアセット制作は、DCCツールやペイントソフトを開き、人間が手で作るか既存素材を加工するのが基本だった。AI生成が加わっても、GUIで1枚ずつ生成していては作業は「速い手作業」のままで、自動化の恩恵は限定的になる。CLIと設定ファイルを軸に据えると、次の3点が変わる。
第一にバッチ化。100種類の壁テクスチャ、30体分のキャラクター立ち絵、20カット分の背景素材を1回のコマンドで生成できる。第二に再現性。プロンプト、シード、解像度、モデル名、各種パラメータをファイルとして保存しておけば、同じ条件を後から再現できる。第三に差分管理。プロンプトの変更がGitの差分として残るため、アートディレクションの変化を追跡でき、レビューも「何が変わったか」を軸に進められる。
手作業と自動生成の役割分担
すべてをAIに任せる必要はない。向いている作業と向いていない作業を最初に切り分けておくと、後戻りが減る。
自動生成に向いているのは、バリエーションが必要な素材、プロトタイプ段階の仮素材、量産前提の背景や小物、ローカライズ用の差分素材、ループ用の短尺音声などだ。逆に、主人公の顔立ちのように厳密なアートディレクションが求められる要素、ブランドの象徴となるロゴ、法務確認が必要な二次的創作物は、人間の手作業とレビューを前提にしたほうが安全である。
実務では「AIで80点の素材を大量に作り、人間が20点を選んで磨く」という分業が最も費用対効果が高い。ゼロから手で作るのではなく、候補集合を作って選別する工程にAIを置くイメージだ。
導入前に決めておくべき3つの指標
1つ目は生成1件あたりの所要時間。待ち時間が長いモデルは、バッチ本数を絞るか低解像度の下見生成と組み合わせる。2つ目は再現性。同じ入力から同じ品質が得られるかどうかを、シード固定で検証しておく。3つ目はレビュー工数。生成物1件を何秒でOKかNGか判断できるかを測り、コンタクトシートや比較画像の自動生成に投資する判断材料にする。
パイプライン設計：フォルダ構成と設定ファイル
自動化が破綻する最大の原因は、モデルでもプロンプトでもなく、ファイルの置き場所と命名規則が場当たり的であることだ。最初にディレクトリ構造を固定する。
project/
prompts/
textures/
sprites/
refs/
shots/
audio/
config/
pipeline.yaml
style-guide.yaml
scripts/
generate.py
review.py
assets/
raw/
approved/
rejected/
logs/
metadata/
prompts には用途別にプロンプトのテンプレートを置く。config にはパイプライン全体の設定とスタイルガイドを置く。assets/raw は生成直後の未選別素材、approved は人間が承認した素材、rejected は不採用素材だ。rejected を消さずに残すのが重要で、後から「なぜ却下したか」を学ぶ材料になる。
命名規則を先に決める
命名規則は、種別_被写体_バリエーション番号_解像度_シード のように機械可読な形にする。たとえば tex_wall_cyberpunk_v03_2048_s118273.png のような形式だ。人間が読めることと、スクリプトで正規表現抽出できることの両方を満たす必要がある。シードをファイル名に含めておくと、後から同じ条件を再投入するときに迷わない。
プロンプトをYAMLで外部化する
プロンプトをコードに埋め込むと、修正のたびにスクリプトを編集することになる。YAMLに切り出し、スクリプトはそれを読むだけにする。
style_guide:
palette: muted cyan and rust
lighting: overcast, soft rim light
camera: 35mm, slight low angle
forbidden: text, watermark, extra limbs
textures:
wall_concrete:
subject: weathered concrete wall panel
detail: fine cracks, chipped edges
tiling: seamless horizontal and vertical
size: 2048x2048
variants: 8
floor_wet_asphalt:
subject: wet asphalt with shallow puddles
detail: neon reflection, light rain
tiling: seamless
size: 2048x2048
variants: 6
この方式の利点は、スタイルガイドを1か所変えるだけで全カテゴリの出力トーンが揃うことだ。逆に、カテゴリごとにスタイルを混在させると、ゲーム内でアセットの質感がバラバラになる。スタイルガイドは「憲法」として扱い、例外を作るときは理由をコメントではなくコミットメッセージに残す。
テクスチャ・2Dスプライト・背景の自動生成
ゲーム開発で最も量が必要になるのが、テクスチャと2D素材だ。ここでのプロンプト設計は、次の順序で組み立てると安定する。
- 被写体（何を描くか）
- 素材感（金属、布、石、樹脂など）
- ライティング（光源の方向、硬さ、色温度）
- カメラ（焦点距離、アングル、被写界深度）
- スタイル（画風、レンダリング傾向）
- 技術指定（解像度、タイル化、透過、アスペクト比）
- 除外指定（文字、透かし、不要な要素）
この順序を守ると、要素を1つずつ差し替えて比較検証できる。たとえばライティングだけを変えた8枚を並べれば、ライティングの影響範囲がすぐに分かる。
タイル化とシームレス化のコツ
背景テクスチャは、端と端をつないだときに継ぎ目が出ないかが最大の関門だ。プロンプトに「水平方向と垂直方向にシームレス」と明記し、生成後の検証を自動化する。検証は簡単で、左端の列と右端の列のピクセル差分、上端と下端の差分を計算し、閾値を超えたら不採用フォルダに移動する。目視では見落としやすい継ぎ目を、数値でふるいにかけられる。
スプライトシートとアルファチャンネル
2Dキャラクターのスプライトは、透過チャンネルの品質が命になる。輪郭に白い縁が残る、髪の毛の隙間が埋まる、半透明部分が濁るといった問題が起きやすい。対策として、生成時は単色背景を指定し、背景除去は専用の処理に任せる。生成モデルに透過を直接求めると失敗が多い。背景除去後に縁を1ピクセル収縮させる処理を挟むと、貼り付けたときの浮きが目立たなくなる。
アニメーション用のフレーム分割は、体のパーツ位置がフレーム間でずれると破綻する。参照画像を固定した上で、ポーズだけを変えた連番を生成し、位置合わせは後工程で行うのが現実的だ。
用途別テンプレートの例
| 用途 | 解像度 | 透過 | 主な指定 |
|---|---|---|---|
| 壁テクスチャ | 2048角 | 不要 | シームレス、拡散反射のみ |
| 小物アイコン | 512角 | 必要 | 真上から、影なし |
| 立ち絵 | 1024x2048 | 必要 | 正面、腰上、単色背景 |
| 背景パノラマ | 4096x2048 | 不要 | 水平パン想定、遠景を簡略化 |
テンプレートを表として残しておくと、新しいメンバーが参加したときに迷わない。
3Dモデル用の参照画像シーケンスを生成する
3Dモデリングの前工程では、多方向からの参照画像があると作業効率が大きく変わる。これをAIで自動生成するのが、CLIワークフローの強みだ。
基本の考え方は、ターンテーブル撮影をプロンプトで再現すること。被写体、ライティング、背景を完全に固定し、カメラ角度だけを15度刻みで変更した24枚を生成する。角度指定は「正面」「左45度」「真後ろ」のような自然言語でもよいが、可能なら数値で与えたほうが再現性が高い。
ライティングを固定する理由
角度ごとにライトが動くと、参照画像としての価値が半減する。陰影がばらつくと、モデラーは面の向きを誤解する。スタイルガイドに「光源はカメラ左上45度、環境光は一定」と書き、全カットで同じ記述を使う。モデルによっては指示の解釈が揺れるため、生成後にヒストグラムを比較して極端に暗いカットを弾く自動チェックを入れる。
フォトグラメトリとノーマルマップへの展開
生成した多方向画像は、フォトグラメトリの入力としても、ハンドモデリングの下敷きとしても使える。ノーマルマップが必要な場合は、高さ情報を推定する処理を挟む。AI生成画像は実写と違いレンズ歪みや露出が均一なため、フォトグラメトリとの相性は悪くない。ただし反射や透明素材は破綻しやすいので、拡散反射主体の被写体に絞るのが安全だ。
注意点として、生成画像はあくまで「見た目」であり、実際の寸法情報を持たない。スケール感は人間が決め、モデル側で数値を調整する。参照画像を絶対視すると、ゲーム内で大きさが破綻する。
シネマティック動画とループ素材の量産
カットシーンやトレーラー用の映像は、画像生成よりも一貫性の管理が難しい。ここではショットリストを先に確定させ、それぞれに参照画像とプロンプトテンプレートを割り当てる。
ショットリストは表形式で管理する。カット番号、尺、カメラワーク、被写体、参照画像のパス、使用モデル、優先度の7列があれば実務では足りる。カット番号をファイル名の先頭に置くことで、編集ソフトに読み込んだときの順序が自動で揃う。
一貫性を保つ3つのテクニック
1つ目は参照画像の固定。各カットに前後のカットから切り出したフレームを参照として渡す。2つ目はプロンプトのテンプレート化。スタイル、レンズ、色温度の記述を全カットで共通化し、変えるのはカメラワークと被写体だけにする。3つ目は生成順序の制御。物語の起点となるカットを最初に生成し、それを基準に前後へ展開すると、色調のドリフトが抑えられる。
ループ素材を作るときの注意
背景ループや環境映像は、最終フレームと最初のフレームがつながらなければならない。もっとも確実な方法は、最初のフレームを静止画として生成し、それを始点と終点の両方に指定して動画を生成することだ。加えて、動きの速度を一定にし、カメラの移動を円軌道や往復運動に限定すると継ぎ目が目立ちにくい。
解像度と生成時間のトレードオフ
高解像度の長尺生成は時間がかかる。実務では、まず540p程度の低解像度で全カットを生成して構成を確認し、承認されたカットだけを高解像度で再生成する二段階方式が効率的だ。この方式なら、構成変更による手戻りを最小限にできる。
音声・効果音・BGMをパイプラインに組み込む
視覚素材だけでなく、聴覚素材も同じパイプラインで扱える。効果音のプロンプトは、次の要素を含めると狙いに近づく。
- 音源（何が鳴っているか）
- 距離と空間（近接、遠景、屋内、洞窟など）
- 残響と反射（乾いた、響く、金属的）
- 長さとループ可否
- 除外指定（音楽、話し声、クリックノイズ）
たとえば「砂漠の風、遠景、低い唸り、ループ可能、音楽なし」といった具合だ。生成した音声は必ず波形を確認し、先頭と末尾の無音を整える。ループ素材はクロスフェードをかけて継ぎ目を消す。
BGMとステム分割
BGMはテンポと楽器編成を明示すると安定する。「90 BPM、低弦と打楽器のみ、緊張感、2分、盛り上がりは中盤」のように書く。ゲームでは、状況に応じて音量を動的に変えるため、ステム（楽器別トラック）があると便利だ。生成モデルがステム分割に対応していない場合は、複数パターンを生成してレイヤーとして重ねる方法でも近い効果が得られる。
ナレーションとローカライズ
ナレーションは、言語、話速、トーン、間の取り方を指定する。多言語展開を見据えるなら、同じ原稿を言語別に生成し、尺の差を吸収するために映像側のカット尺を調整できるようにしておく。音声の長さは言語によって2割以上変わることがあり、ここを想定していないと字幕と音声がずれる。
ミックス段階では、効果音、BGM、ナレーションのラウドネスを揃える。配信やストア提出を想定するなら、目標ラウドネスをあらかじめ決めておき、書き出し時に自動計測して記録する。
ジョブ管理と再現性をどう確保するか
生成は失敗するものだ。ネットワークエラー、モデル側の一時的な混雑、キュー詰まりは日常的に起きる。想定した失敗として扱い、再試行を前提に設計する。
ジョブキューの基本設計
- 各ジョブに一意のIDを振り、入力パラメータのハッシュから生成する
- 同じハッシュの結果が既にあれば生成をスキップする（冪等性）
- 失敗時は指数バックオフで再試行し、上限回数を超えたらキューから外す
- 進捗とエラーをログに構造化して出力する
- 並列度はモデルごとの制限に合わせて制御する
冪等性は特に重要だ。パイプラインを途中で止めて再実行したとき、既に生成済みの素材を二重に作らないだけで、待ち時間とストレージの両方が節約できる。
メタデータを必ず保存する
生成したファイルと同じ名前のメタデータファイルを残す。含めるべき情報は、プロンプト全文、シード、モデル名、解像度、生成日時、パイプラインのバージョン、使用したスタイルガイドのハッシュだ。これを保存しないと、半年後に「この素材をもう一度」と言われたときに再現できない。
{
"asset": "tex_wall_cyberpunk_v03_2048_s118273.png",
"prompt": "weathered concrete wall panel, fine cracks, seamless, overcast soft light",
"seed": 118273,
"model": "image-model-a",
"size": "2048x2048",
"style_hash": "a91f2c",
"pipeline_version": "1.4.0"
}
ログの読み方
ログは「生成リクエスト数」「成功率」「平均所要時間」「再試行回数」の4指標で見る。成功率が急落したらモデル側の問題、所要時間が伸びたらキュー詰まり、再試行が増えたらパラメータの不整合を疑う。数字を眺める習慣があるだけで、原因切り分けの速度が変わる。
品質チェックとレビュー工程の自動化
生成物が増えるほど、目視レビューがボトルネックになる。自動で弾けるものは自動で弾き、人間は判断が必要なものだけを見る。
自動チェックで弾ける項目
- 解像度とアスペクト比が仕様どおりか
- 透過が必要な素材にアルファチャンネルがあるか
- タイル素材の端の差分が閾値以内か
- 画像が単色や極端なぼけになっていないか（分散の下限チェック）
- 音声のピークが基準を超えていないか、先頭と末尾が無音か
- ファイルサイズが想定範囲に収まっているか
これらは数行のスクリプトで判定できる。落ちたものを不採用フォルダに移し、理由をファイル名かメタデータに記録する。
人間が見るべき項目
自動チェックを通過した素材を、コンタクトシート（一覧画像）にして並べる。1画面に20枚程度を並べると、スタイルの逸脱が一目で分かる。レビューでは次の3点だけを見る。アートディレクションに沿っているか、ゲーム内で使ったときに破綻しないか、他の素材と並べて違和感がないか。
レビューの結果は、承認、条件付き承認、却下の3段階で記録する。条件付き承認には修正内容を必ず書き、次のバッチ生成のプロンプトに反映する。このフィードバックループを回すことで、同じ指摘を繰り返さなくなる。
よくある失敗とトラブルシューティング
プロンプトが長すぎて焦点がぼける
要素を詰め込みすぎると、モデルはどれを優先すべきか判断できず、平均的な出力に落ち着く。1プロンプトにつき主題は1つか2つに絞り、残りはスタイルガイドに逃がす。
モデルを変えたらスタイルが崩れた
モデルごとに色味、コントラスト、輪郭の傾向が違う。パイプラインの途中でモデルを差し替えると、前後で質感が変わる。対策は、モデル切り替え時に代表カットを数枚だけ再生成して比較し、必要ならポストプロセスで色調を揃えることだ。
ループの継ぎ目が目立つ
始点と終点のフレームを一致させ、動きを周期的にする。それでも残る場合は、映像編集側で30フレーム程度のクロスフェードをかける。
生成待ちで作業が止まる
低解像度の下見生成と、高解像度の最終生成を分ける。夜間にバッチを流し、朝にレビューする運用にすると、待ち時間そのものが消える。
権利とライセンスの確認を後回しにする
生成物の利用条件は、モデルやプランによって異なる。商業利用の可否、再配布の可否、学習への利用条件を、パイプラインに組み込む前に確認する。確認結果はドキュメントとして残し、アセットごとではなくプロジェクト単位で管理すると運用しやすい。
自動化しすぎて品質が落ちる
全工程を無人化すると、微妙な逸脱が蓄積する。承認ゲートを2か所（下見段階と最終段階）だけ設け、そこだけ人間が判断する運用が現実的だ。
よくある質問
Q1. プログラミング経験が浅くてもCLIワークフローは組めるか
組める。最初は手動で1件生成し、そのコマンドをそのままシェルスクリプトに貼るところから始めればよい。パラメータを変数化し、ループで回し、ログをファイルに出す。この3段階で、実用的な自動化の8割は達成できる。
Q2. どのくらいの規模から自動化すべきか
同種の素材を20件以上作る見込みがあれば自動化の価値がある。10件以下なら手動のほうが速いことも多い。判断基準は「同じ手順を何回繰り返すか」だ。
Q3. GUIツールと併用する意味はあるか
ある。最終的な色調整や合成、納品形式への変換はGUIのほうが速いことが多い。AI生成とバッチ処理をCLIで担い、仕上げをGUIで行う分担が現実的だ。
Q4. 生成結果が毎回ばらつくのを抑えるには
シードを固定し、プロンプトを外部ファイル化し、スタイルガイドを一元管理する。この3点だけでもばらつきは大きく減る。加えて、生成後の自動チェックで外れ値を弾く。
Q5. 3Dモデルの参照画像は何枚必要か
ターンテーブル用途なら15度刻みの24枚、ハンドモデリングの下敷きなら8枚程度で足りることが多い。まず8枚で試し、破綻する角度があれば追加する。
Q6. 音声素材の品質はどう担保するか
波形の目視と、ピーク、ラウドネス、無音区間の自動計測を組み合わせる。ループ素材は必ず継ぎ目を再生して確認する。
Q7. チームで運用するときの注意点は
プロンプトと設定ファイルをバージョン管理下に置き、変更理由をコミットに残す。担当者ごとにプロンプトを書き換える運用にすると、再現性が失われる。
Q8. 生成に失敗したときの切り分け手順は
まずプロンプトを単純化して再実行する。次にモデルを変えずにパラメータだけ戻す。それでも失敗するなら入力データ（参照画像や音声ファイル）の形式を疑う。この順序で切り分けると、原因が入力側か設定側かを短時間で判別できる。
まとめ：パイプラインは資産である
CLIからAIを呼び出してゲーム用アセットを作る取り組みは、単発の生成テクニックの集合ではない。ディレクトリ構造、設定ファイル、ジョブ管理、メタデータ、品質チェック、レビューゲートという6つの部品を組み合わせた、ひとつの制作システムだ。
最初から完璧なパイプラインを組む必要はない。まず1種類のテクスチャを8枚生成し、命名規則を決め、メタデータを保存する。次にジョブをループで回し、失敗時の再試行を入れる。慣れてきたら参照画像のシーケンス生成や動画カットへ広げていく。段階を踏めば、各段階で得た知見がそのまま次の自動化の設計図になる。
結果として得られるのは、素材そのものだけでなく「同じ品質の素材を何度でも作り直せる力」だ。アートディレクションが変わっても、仕様が変わっても、パイプラインがあれば数時間で新しい候補集合を用意できる。この再現性こそ、CLIとAIを組み合わせる最大の価値である。
