AIキャラを毎日動かすまでに踏んだ罠（全8回）　　　　　　　　　　　　　（最終回）　AIに何をどう指示すればいいか——指示文まとめ

第8回（最終回）　AIに何をどう指示すればいいか——指示文まとめ

ここまで7回、私が踏んだ罠を書いてきました。最終回は、同じことをやろうと
する人が、その罠を踏まずに済むための指示文をまとめます。

私が実際に使っているものと同じ文面です。伏せずに全部載せます。

この記事が渡すもの・渡さないもの

先に範囲をはっきりさせます。

| 内容 | 環境が違っても効くか |
|---|---|
| 画像生成AIへの指示文 | そのまま効く |
| やってはいけない指示のリスト | そのまま効く |
| 背景色を自分のキャラから決める手順 | そのまま効く |
| 切り抜き処理の考え方と判別式 | Python+PILがあれば効く |
| 動き量の測定と受け入れ判定 | ffmpeg+numpyがあれば効く |
| 動き量の基準値 | 解像度が違うので、割合に直して使う |
| GPU設定の具体値 | カードが違うので、求め方だけ使う |
| ComfyUIのワークフロー本体 | そのままでは動かない |

コードをそのまま貼れば動く、という記事ではありません。 渡すのは
「AIに何をどう頼むか」の文面と、出来上がったものを受け入れるかどうかの
判断基準です。

以下の指示文は、Claude / ChatGPT など、あなたが普段使っているAI
アシスタントにそのまま貼り付けて使ってください。

指示文①　画像生成AIにキャラ絵を作らせる

Gemini等の画像生成AIに貼り付けます。参照画像を1枚添付した状態で使います。

参照画像のキャラクターで、ポーズだけを変えた画像を1枚作ってください。

【人物】
- 1人だけ。他の人物は入れない
- 服装・髪型・髪色・顔立ち・画風は参照画像と完全に同じ
- 服や小物に文字・ロゴ・模様の文字を一切入れない

【ポーズ】
- 立ちポーズ。椅子やソファに座らない
- 家具・小物・持ち物に触れない、寄りかからない
- 上半身から腰までが画面に大きく入る構図
- 腕や髪が画面の端に接しないよう、周囲に余白を空ける

【背景】
- 背景は単色のベタ塗り。鮮やかなマゼンタ(#FF00FF)
- グラデーション・模様・家具・観葉植物・床・壁を描かない
- 人物の影を背景や地面に落とさない

なぜこの文面なのか

各項目に、実際に起きた失敗が1対1で対応しています。

| 項目 | 書かないと起きること |
|---|---|
| 1人だけ | 3人並びのキャラクターシートが届く。腕と髪が繋がって切り抜けない |
| 座らない | ソファごと背景を抜くことになり、宙に浮いた座り姿勢になる |
| 文字を入れない | Tシャツに「LOGO」というプレースホルダーがそのまま描かれる |
| 上半身から腰まで | 全身だと縦横比が1:5近くになり、画面上で細く小さくなる |
| 端に接しない | 腕や髪が画面外で切れて、切り抜き後の形が破綻する |
| 影を落とさない | 地面の影が人物の一部として拾われる |

絶対に書いてはいけない1行

✗ 背景を透過にしてください

画像生成AIは透過PNGを出力できません。頼むと、透過を意味する市松模様を
「絵として」描くことがあります。背景が単色でなくなるので、かえって
切り抜けなくなります。

衣装を変えたいとき

プロンプトで「浴衣を着せて」と書いても、参照画像が別の服なら、モデルは
元絵と衝突します。着てほしい服を着た参照画像そのものを用意してください。
衣装は文言では変えられません。

手順②　自分のキャラに合う背景色を、実測で決める

「白がいちばん抜きやすい」は一般論としては正しいのですが、あなたのキャラが
白い服を着ていたら最悪の選択です。白を透過させると、服も一緒に消えます。

私は白でシャツを失い、緑で黒スーツを失いました。

正しい順番は、キャラの色を先に調べてから背景色を決めることです。
以下をAIアシスタントに貼ってください。

添付したキャラクター画像について、背景色に使う色を決めたいです。
次を実測してください。

1. 画像内の人物部分（背景を除く）に含まれる全画素の色を集める
2. 候補色（マゼンタ #FF00FF、緑 #00FF00、白 #FFFFFF、青 #0000FF）
   それぞれについて、人物部分の全画素との「最も近い距離」を計算する
3. 距離がいちばん大きい候補色を推奨として提示する
4. 各候補について、「危険な部位」（その色に近い服や小物）があれば
   具体的に指摘する

距離はRGB空間のユークリッド距離で構いません。
結果は数値付きで報告してください。推測ではなく実測値でお願いします。

判断の目安

私のキャラの場合、マゼンタとの最短距離が42以上ありました。透過の閾値を
25に置いても、絶対にキャラを食いません。

最短距離が閾値の1.5倍以上あれば安全、というのが目安です。距離が閾値に
近い候補色は避けてください。

| 背景色 | 危険な部位（私の場合） |
|---|---|
| 白 | 白シャツ、白キャミソール、クリーム色のニット |
| 緑 | 黒いスーツ |
| マゼンタ | 該当なし |

服の色が変われば、安全な背景色も変わります。衣装を増やすたびに測り直して
ください。

指示文③　切り抜きスクリプトをAIに作らせる

ここが、私がいちばん遠回りをしたところです。

最初、背景除去AI（rembg）を使っていました。賢いモデルなので任せておけば
いいと思ったのです。実際には、単純な色キーのほうが10倍正確でした。

| 手法 | 半透明になった画素の割合（少ないほど良い） |
|---|---|
| rembg | 9.6〜17.3% |
| 背景色を直接キー | 0.45〜1.47% |

理由は単純で、背景に「キャラに絶対含まれない色」を敷いた時点で、背景と
前景を確実に区別できる情報がすでに画像に埋め込まれているからです。その
状態で推定モデルを通すのは、確実なものを不確実にする作業でした。

しかも rembg は「人のシルエット」を賢く推定しようとするあまり、腕と胴の
間の隙間まで塗り潰していました。

以下をAIアシスタントに貼ってください。

マゼンタ(#FF00FF)背景のキャラクター画像から、人物だけを切り抜いて
透過PNGにするPythonスクリプトを作ってください。

【使ってはいけないもの】
- rembg等の背景除去AIモデルは使わないでください。
  背景に「キャラに含まれない色」を敷いてあるので、色との距離だけで
  確実に判別できます。推定モデルを挟むと、腕と胴の間の隙間を
  塗り潰される・内部に穴が空く等の劣化が起きます。

【処理の順番】
1. 背景色との距離からアルファチャンネルを作る
   （背景色は画像の四隅から自動取得してください。決め打ちにしない）
2. morphological erosion で細い接続を切り、いちばん大きい塊だけを残す
   （複数のキャラが接触して写り込んだ場合に分離するため）
3. 縁に残った背景色を「除去」する
4. 指定した縦横比にトリミングする

【3番について重要】
縁に残ったマゼンタを「色補正」で目立たなくしようとしないでください。
明るいマゼンタを暗くしても、暗い紫のフチが残るだけです。
彩度の高いマゼンタは、着色ではなくアルファから除去してください。
そこは「色を直す」場所ではなく、そもそも前景ではない場所です。

【検証も実装してください】
- 切り抜き結果を緑地に並べたコンタクトシートを出力する
  （目視で穴やフチの残りを確認するため）
- 半透明になった画素の割合を数値で出力する
- 人物内部に穴が空いていないか（囲まれた透明領域の面積）を数値で出力する

混入した背景色を判別する式

生成AIが背景の色をキャラ自身に塗り込んでしまうことがあります。マゼンタ
背景の場合、混入したマゼンタだけを選び出す判別式はこれです。

min(R, B) - G

この値が正になるのはマゼンタ系だけで、肌・茶髪・青・白はすべて負になります。
構造上、キャラの色を誤って変えることができません。

ただし限界があります。数十px規模の大きな汚れは、局所的な処理では消せません。
無理に消すと描線ごと潰れます。大きく汚れた元絵は、諦めて描き直したほうが
早いです。

指示文④　「動いていないクリップ」を自動で弾く

画像から動画を作るとき、同じ絵・同じプロンプトでも、乱数の初期値（シード）
だけで動きの量が2桁変わります。

| 対象 | 変更点 | 動いた画素数 |
|---|---|---|
| あるポーズ | プロンプトを変更 | 287 → 変化なし |
| 同じポーズ | シードを変更 | 287 → 28,153（98倍） |
| 別のポーズ | シードを変更 | 202 → 179,687（889倍） |

889倍です。しかもこれは、私が数か月そのまま使っていたクリップの話でした。

プロンプトをどれだけ工夫しても、シードが外れなら動きません。 そして
出来上がったクリップを見ても、動いていないことに気づけません。短いですし、
キャラは常に画面の同じ位置にいるからです。

だから、測って自動で引き直します。以下をAIアシスタントに貼ってください。

画像から動画を生成する既存のスクリプトに、「動きが足りないクリップを
自動で作り直す」仕組みを追加してください。

【背景】
同じ入力画像・同じプロンプトでも、シードによって動きの量が2桁変わることが
実測で分かっています。目視では判別できないため、数値で受け入れ判定します。

【実装してほしいこと】
1. クリップを1本生成する
2. 生成されたmp4から、先頭フレームと20フレーム目を取り出す
3. 2枚のRGB差分を取り、差が8を超えた画素の数を数える
4. その画素数が「画面全体の画素数の約1%」未満なら、シードを変えて生成し直す
5. あらかじめ決めた複数のシードを順に試し、最大6回で打ち切る
6. どのシードも基準に届かなかった場合は、いちばん数値が良かったものを
   採用したうえで、ログに「基準未達」と明示的に記録する

【重要な条件】
- 基準未達を黙って通さないでください。記録に残らないと、動いていない
  クリップが何か月も使われ続けます（実際にそうなりました）
- フレームを取り出すとき、`-vframes 2` のような取り方だと、シーク直後の
  重複フレームを拾って「動いていない」と誤判定します。
  フレーム番号を明示して取得してください
- 毎回、測定結果を数値でログに残してください

実際に測るコード

import subprocess, io, numpy as np
from PIL import Image

def frame(path, n):
    out = subprocess.run(
        ['ffmpeg','-i',path,'-vf',f'select=eq(n\\,{n})',
         '-vframes','1','-f','image2pipe','-vcodec','png','-'],
        capture_output=True).stdout
    return np.array(Image.open(io.BytesIO(out)).convert('RGB'), dtype=np.float32)

a, b = frame(clip, 0), frame(clip, 20)
d = np.abs(a - b)
print('mean_diff=%.2f' % d.mean(), 'changed_px=%d' % (d.mean(axis=2) > 8).sum())

基準値の決め方

私は 92万画素中10,000画素（約1.1%）を基準にしました。解像度が違えば
画素数も変わるので、割合で決めてください。

`mean_diff` のほうが解像度に依存しないので、こちらを主に使うのが確実です。

| mean_diff | 見え方 |
|---|---|
| 10以上 | 明確に動く |
| 5〜6 | 動きは分かる |
| 3〜4 | やや弱い |
| 3未満 | ほぼ静止。引き直す |

試すシードは固定しておく

毎回ランダムに引くのではなく、固定のリストを順に試すほうが再現性が
出ます。私が使っているのはこの6つです。

SEEDS = [7, 12345, 4242, 99, 31337, 808]

効果（実測）

自動リトライを入れて7ポーズ生成した結果です。

| ポーズ | 試行回数 | 結果 |
|---|---|---|
| A | 1回 | 65,284 |
| B | 1回 | 84,240 |
| C | 2回 | 15,149 |
| D | 5回 | 22,484 |
| E | 5回 | 98,266 |
| F | 6回全滅 | 7,808（基準未達） |

1回で基準を超えたのは7本中4本でした。自動化していなければ、半数近くを
手作業で引き直すか、動いていないものをそのまま出荷していたことになります。

もう1つ、動きを殺す落とし穴

クリップが十分動いているのに、完成した動画では止まって見えることがあります。

私の場合、ゆっくり拡大する演出（Ken Burns効果）が、キャラ合成の「後」に
画面全体へかかっていました。 画面全体が漂うので、キャラ自身の動きが
埋もれます。

✗ キャラを合成する → 画面全体にズームをかける
○ 背景にだけズームをかける → キャラを合成する（または、ズームを使わない）

「動いていない」のと「動きが打ち消されている」のは、目で見る限り区別が
つきません。 画面を上下左右に分割して、それぞれの変化量を測ってください。
キャラの領域だけが動いていれば正常です。

手順⑤　GPU設定を、自分のカードで求める

私の値（電力上限80%、ファン85%固定、75℃で待機）をそのまま使わないで
ください。 カードが違えば適正値も変わります。求め方だけ書きます。

まず、今スロットルしているかを見る

`nvidia-smi` でスロットル要因を確認します。ここで見るべきは1点だけです。

| 表示 | 意味 | 対応 |
|---|---|---|
| SW Thermal Slowdown = Active | ドライバが温度を理由にクロックを落としている | 正常な自主規制。ただし遅くなっている |
| HW Thermal Slowdown = Active | 緊急保護が働いている | 危険域。すぐ冷やす |

HW側が Not Active なら、壊れる心配はありません。 温度の数字そのものより、
こちらを見てください。私は86℃を見て慌てましたが、実際にはHW側は一度も
作動していませんでした。

冷却は「保護」ではなく「性能」

ファンを固定しただけで、こうなりました。

| | 温度 | ファン | クロック | スロットル |
|---|---|---|---|---|
| 変更前 | 81℃ | 79%(自動) | 2505MHz | SW Thermal Active |
| ファン85%固定 | 67℃ | 85% | 2805MHz | なし |

14℃下がって、クロックが300MHz上がりました。 熱いまま回すのは、危険
なのではなく遅いのです。

ファンを回しすぎて壊れないか

壊れません。GPUファンは連続運転を前提に設計されており、定格寿命は一般に
3万〜6万時間以上です。高速回転で起きるのは軸受けの摩耗で、数時間で壊れる
性質のものではありません。実際の代償は騒音とホコリの吸い込みです。

いちばん効いたのは扇風機だった

| | 温度 | ファン回転 | クロック |
|---|---|---|---|
| ファン85%のみ | 77℃ | 81% | 2565MHz |
| ＋扇風機 | 74℃ | 60% | 2595MHz |

ファンが81%→60%に下がって、それでも温度が低い。 ケースの中の空気を
入れ替えないと、GPUのファンをいくら回しても同じ空気をかき混ぜているだけ
です。ソフトで細かく詰めるより、外気を送るほうが効きました。

温度を見て待たせる

最後に、これをAIアシスタントに貼ってください。

生成処理の前に、GPU温度を確認して、しきい値を超えていたら下がるまで
待機する処理を追加してください。

- nvidia-smi で温度を取得する
- しきい値（例：75℃）を超えていたら、一定間隔で再確認しながら待つ
- 待機した場合は「何℃から何秒待って何℃になったか」をログに残す
- タイムアウトを設けて、無限に待たないようにする

私の環境では「85℃ → 135秒待機 → 71℃」で動いています。人が張り付いて
監視しなくても、勝手に自分を抑えてくれます。

手順⑥　GPUが1枚なら、同時に動かさない

文章生成にローカルLLMを使い、動画生成にComfyUIを使う場合、両方が同じGPUを
取り合います。

私の環境（VRAM 12GB）では、ComfyUIが11.8GB占有すると、残り0.2GBでは
LLMのモデルが載りません。そして厄介なことに、エラーで落ちません。

[16:52:11] Topic: pagenum#3
[16:57:11] Ollama call failed (timed out); trying next fallback
[16:57:12] Using pre-written text (no generator available today)

5分待って諦め、黙って定型文に差し替わります。 動画は普通に1本
できあがるので、ログを見に行かない限り気づけません。

VRAMの解放を要求する処理も入れましたが、VAEデコード中には効きません。
結局、順番に実行するのが確実でした。

文章生成と動画生成を、同じGPU上で同時に実行しないようにしてください。

- 動画生成が走っている間は、文章生成を開始しない
- 文章生成がフォールバック（定型文など）に落ちた場合は、
  「落ちた」という事実を必ずログに残す
- どの生成手段が実際に使われたかを、実行ごとに記録に残す
  （後から「本当にLLMが使われたか」を確認できるようにするため）

最後の1行が重要です。私は設定フラグを戻し忘れたまま、ローカルLLMを
一度も呼ばずに数日運用していたことがあります。実際に何が使われたかを
記録していなければ、気づけません。

指示文⑦　「手で書いた一覧」を作らせない

素材が7枚だった頃は問題なく動いていたコードが、31枚に増えた時点で静かに
壊れました。しかも4か所同時にです。

| 不具合 | 手で書いて管理していたもの |
|---|---|
| 動画の途中で服が変わる | カットで使うポーズ名がコードに直書き |
| 画像の形が狂う | 縦横比の表に新しい24枚が載っていない |
| 直したのに反映されない | キャッシュ判定が「ファイルの有無」だけ |
| 動画全体が静止画になる | アニメ可否の判定対象が全ポーズ固定 |

4つとも、エラーも警告も出しませんでした。 動画は毎回きちんと1本
できあがっていました。