従量課金のゲームアセット生成サービスに不満を持ち、自分でパイプラインを構築したというガチの備忘録。1キャラあたり7モーション・計58スプライトを、人間の作業は「実行ボタンを押す」「良いコマを選ぶ」だけで納品形式まで持っていく。
🎯 完成したパイプライン
キャラシート1式 → LoRA学習 → ポーズ生成 → 動画AIでモーション化 → 生成AIでドット絵変換 → 透過・正規化
すべてComfyUI上のノードグラフで一気通貫。筆者いわく「100%納得できる品質は作れなかったが、可能性を感じた」。
🔑 この記事でわかること
- ComfyUIで「静止画生成 → 動画AIでモーション化 → フレーム選別 → ドット絵変換」を一気通貫
- Codex CLI（ChatGPTサブスク）をComfyUIのカスタムノードとして叩く方法
- 生成AIでアニメフレームの一貫性を保つプロンプト設計（と失敗パターン）
- 「AIが描いたドット絵風画像」を本物の1ドット=1ピクセルに正規化する方法
- 非決定的で高価な生成工程を安全に運用する設計原則
⚙️ ComfyUIとは
Stable Diffusion等をノードグラフ（箱を線でつなぐ）で動かすワークフローエンジン。AUTOMATIC1111（WebUI）が「1枚絵のガチャ」向けなのに対し、ComfyUIは多段処理の自動化に強い。ワークフロー自体がJSONファイルで再現性が高い。
📝 各ステップの詳細
前提：キャラ同一性はLoRAで担保
プロンプトではなくLoRAで同一性を担保。ChatGPTで多視点キャラシート作成 → img2imgでベース画風に寄せる → kohya_ssで学習。IP-Adapterも試したがv-pred系SDXLと相性悪く崩壊。LoRAが結局安定。
Step1-2：ポーズ生成と選別
- Idle/Walkは既存スプライトをdepth ControlNetの型として使い、LoRA付きtxt2imgで候補生成
- depthは武器シルエットも固定するので、武器が違うキャラには武器ごとの型が必要
- チビキャラ（2頭身）にはopenpose不可、depth一択
- 人間の選択はComfyUIのImage Filter系ノードで「実行→クリックで選ぶ」だけ
- 循環問題：攻撃の振りかぶり型を作るには振りかぶりの絵が必要→新規ポーズはプロンプト駆動txt2imgか動画AIに任せるのが正解
Step3-4：動画AI（Wan2.2 I2V）でモーションを「発明」させる
画像生成AIは左右の脚認識が難しく中割りが安定しない。ここを動画AIに丸投げ。立ち絵1枚を始点に「She starts to walk / performs an attack combo...」で49フレーム生成し、良いフレームを選別。
- start-only（終点なし）が基本。始点と終点を両方固定するFLF方式は「終点品質が全てを支配」し事故りやすい
- 攻撃のように動きがはみ出すモーションは始点画像に余白を付ける
- 背面モーションは「振り返り」との戦い。向き固定はnegative プロンプト、動きはpositiveで誘導
- 歩行はキーフレーム不要だがループには使えない（冒頭が必ずidle→歩き出しの遷移になる）
Step5：ドット絵変換（本記事の肝）
LoRAで細かいデザイン担保が難しく、画像ガチャ状態に。方針変更でドット絵で誤魔化すことに。ここが最も試行錯誤した工程。
機械変換では「ドット絵」にならない。縮小＋減色は「縮小しただけの画像」。ドット絵の本質（意図を持った輪郭線・ベタ塗り・クラスタ陰影）は描き方の問題。ピクセルアートLoRAも品質不足。
決め手はCodex（ChatGPTのコーディングエージェント）内蔵の画像生成ツール。「本物のピクセルクラスタ・輪郭・キャラ同一性の維持」を単体テストで確認し、ローカルCodex CLIを子プロセスで叩くカスタムノードを作成。
🛠️ Codex CLIをComfyUIノードにする技術
codex execを非対話モードで呼び、画像を添付して結果PNGを回収- ハマりどころ：
codex execはstdinがパイプだと入力を待ってハング → プロンプトを-でstdinから渡して即クローズで回避
- APIキー不要（ChatGPTサブスクのログインをそのまま使用）。ただしプランのレート制限を消費
- seedがなく毎回結果が変わる。この非決定性が運用設計を要求する
🎨 一貫性の設計：リファレンス方式と役割分離プロンプト
フレームを1枚ずつ独立変換するとデザインが揺れる（武器の意匠・服の紋様がコマごとに別物）。対策は2段構え：
- リファレンス方式：毎フレーム変換時に承認済みドット絵1枚を「Image A（基準）」として添付。モーション姿勢別に基準を持つ
- 役割分離プロンプト（最重要の学び）：「迷ったらImage Aをコピーせよ」と強い追従指示を入れるとポーズまでAからコピーされる事故が発生。最終形は明示的な役割分離：
- Image B（対象フレーム）＝ POSEの唯一のソース。体勢・手足・歩幅・武器角度。絶対にAからポーズを借用しない
- Image A（基準）＝ DESIGNとレンダリングスタイルの唯一のソース。ピクセルクラスタサイズ・輪郭太さ・パレット
🔧 その他の技術要素
- オプティカルフロー方式：Frame0だけドット絵化し、残りはRAFTでピクセルを物理的にワープ。原理的に絵柄が揺れない。Idle（微小な揺れ）では本採用だが、Attack/Walkでは姿勢変化が大きく不適
- サイズ・位置の機械補正：生成AIの±数%サイズ揺れ・20%超の位置ズレを、元フレームとのbbox比較で補正。高さ比のみでスケール補正（幅を混ぜると相殺される罠）。bbox中心で平行移動
- グリッドピッチ自動推定：Codex出力の「ドット絵風」を真の1:1にするため、エッジ強度プロファイルの自己相関ピークからグリッド周期を推定。倍音への誤ロック対策や探索下限の調整が必要
- 透過は色キー＋境界連結判定：AIセグメンテーションは白背景と同色の装飾まで背景誤認。古典的色キー抜き＋「縁に連結した領域だけ背景」判定＋1px膨張でエッジの中間色除去（順序が大事）
- クロップは各フレームのアルファ最小枠。ゴミドットが残るとキャンバスが不自然に大きくなり一目で発覚 → 品質保証が前工程に移る
⚖️ 妥協点：位置・サイズの統一は諦めた
- フレーム内のズレは機械補正で解決
- フレーム間の整列は意図的に捨てた（最小枠crop + Unityのピボットで整列）
- モーション間のサイズ統一は揃えきれず妥協。1:1ドット画像を非整数倍スケールすると格子が壊れるため原理的に不可能
🏗️ 運用設計：非決定性との付き合い方
- 生成と後処理を同一ワークフローに同居させない：高価で非決定的な工程（Codex生成）と無料で再実行したい工程（透過・正規化・クロップ）を分離。生成物は必ずディスクに落とす
- フレーム単位の永続ディスクキャッシュ：(参照画像+対象画像+プロンプト)のハッシュ → 結果PNG。途中失敗からの再開・再起動耐性・意図的再抽選の明示操作
📦 量産アーキテクチャ：キャラ2人目を10分で立ち上げる
「キャラ固有情報」と「共通処理」を分離。chars/alice.jsonのようなキャラプロファイル（LoRAファイル名・SD用タグ断片等）を正本とし、共通ワークフローから参照する設計。
💭 ざっくり一言で
「画像生成AIの"ガチャ感"を動画AI＋Codex＋機械補正のパイプラインでねじ伏せた、ガチの個人開発アプローチ。非決定性とどう付き合うかの設計思想が学び深すぎる」——ゲーム開発者＆AI workflow界隈でウケるわけだわ🔥