AI動画生成の用語集｜I2V・CFG・steps・LoRAを本番の設定値と実測で解説

用語はグループごとに表にまとめ、表の列は 4 つにしています。

前提として、このサイトの動画は 2 段構えで作っています。

1. 開始画像を SDXL で作る（顔は PuLID で固定）
2. その画像を Wan 2.2 I2V に渡し、約 5 秒の動画にする

以下の用語は、ほぼすべてこの 2 段のどこかに出てきます。

I2V を選んでいる理由は顔です。文章だけで動画を作ると、同じキャラを毎回同じ顔で出す手段がありません。先に静止画で顔を固め、動画側はそれを動かすことに専念させています。動画は開始画像の色や見た目を引き継ぐので、見た目の問題はたいてい開始画像の段階で直せます。

2026 年 7 月に調べた時点で、Wan の重みが公開されているのは 2.2 までで、それ以降の版は API 経由でしか使えませんでした。手元の GPU で動かすなら、この組み合わせが現実的な選択肢です。

latent は、この構成だと 2 回出てきます。開始画像を latent に変換する「エンコード」と、完成した latent を 81 枚の画像に戻す「デコード」です。サンプリングは合計 4 ステップのうち、前半 2 ステップを高ノイズ用モデル、後半 2 ステップを低ノイズ用モデルが担当し、前半はノイズを残したまま後半へ渡します。

ComfyUI で一番高くついたのは、設定値ではなく反映漏れでした。ステップ数を減らす変更を入れた直後、実行中のプロセスは再起動されず、古いキャッシュも残っていて、旧設定のまま動いていました。経緯は生成時間の短縮記録の記事に書いています。

• I2V: 動画で直したい見た目は、まず開始画像で直せないかを考える
• SDXL: ステップを削る前に純粋な生成時間を測る。うちは 30 steps で 11〜12 秒だった
• ComfyUI: 変更したら、ログに出る実際の値で反映を確かめる
• latent: 「エンコードで落ちたのか、デコードで落ちたのか」を分けて考えるための言葉として覚える

PuLID は実写の顔しか扱えません。内部の顔検出が実写の顔を前提にしているためで、イラストでは顔が取れず動きません。イラストで同じキャラを保つ検証をした時に IPAdapter を使ったのはこのためで、その比較は同じキャラの顔を保つ方法の記事で詳しく書いています。なお IPAdapter が必要とする画像認識モデルは、動画側で使っているものをそのまま流用できました。

効かせる範囲を工程の 70% で止めているのは、後半を本体モデルに任せるためです。顔の造作は前半で決まり、肌や光の細部は後半で決まります。

PuLID には運用上の落とし穴もありました。GPU サーバー側の起動スクリプトが動いておらず、PuLID が使う顔検出ライブラリが入らないまま ComfyUI が起動していたことがあります。PuLID の読み込みは失敗していました（生成を止めていた期間なので実害なし）。「ComfyUI が起動した」と「顔が正しく出る」は別なので、今は再開前に実際に 1 枚生成して顔を目で見ています。

もう 1 つ、顔がカメラから外れる動きは避けています。顔を固定しているのは開始画像だけなので、体ごと回って戻ってきた顔は動画モデルが描き直した顔になり、同一性が保てません。

LoRA は一般に「キャラを覚えさせる」用途で紹介されますが、うちの本番のワークフローで使っているのは動画を 4 ステップで作れるようにする蒸留 LoRA です。高ノイズ用・低ノイズ用の 2 本を、それぞれ強度 1.0 で当てています。顔は PuLID で足りているので、キャラ用の LoRA は作っていません。

本体のファイルを 26.6GB から 13.3GB の形式に替えた時、心配したのは LoRA が当たらなくなることでした。そこで当たる箇所の数を数え、切り替え前後で 607 箇所のまま変わらないことを確かめてから入れ替えています。

• PuLID: 再開前に 1 枚作って顔を見る。回転する動きは使わない
• IPAdapter: 強度は 0.5・0.7・0.9 のように幅を取って試す
• LoRA: 本体を差し替えたら、LoRA が当たる数が変わっていないか確認する
• seed: 比較する時は必ず固定、本番ではランダム。固定しないと、速くなったのか軽い絵を引いただけなのか区別できない

steps と CFG は掛け算で効きます。CFG が 1.0 を超えると、1 ステップごとに「指示あり」と「指示なし」を 2 回計算します。以前の 8 ステップ × CFG 2.0 はモデル計算 16 回、今の 4 ステップ × CFG 1.0 は 4 回です。

CFG だけを 2.0 から 1.0 にした時の実測です。

43% 短くなりました。ただしこの時は、プロンプト側の別の不具合と重なって画質を正しく評価できず、判定を保留しています。その不具合を直した後、steps と shift も含めて測り直して採用しました。

「ステップを増やせば画質が上がる」は、蒸留モデルには当てはまりませんでした。使っている高速化 LoRA は最初から 4 ステップ向けに作られています。8 ステップは設計点から外れていただけで、時間を倍払って見返りがありませんでした。

CFG を 1.0 にした代償は、動画段の negative prompt が効かなくなることです。うちでは開始画像の段階では negative が効くこと、動画は開始画像の見た目を引き継ぐこと、公開前に人が確認する工程があることで許容しています。投入直後の本番動画を目視した範囲では、実害は確認されませんでした。

sampler と scheduler は、モデルが想定している組み合わせから始めるのが安全です。画像と動画で値が違うのは、それぞれの定番設定に合わせているからです。別系統のイラスト用モデルを検証した時は、推奨の Euler / normal / CFG 4.5 を実写用とは別に持たせました。実写用の設定を流用すると崩れるモデルだったためです。

後から、同種のサービスが本番で使っている設定を確認する機会がありました。動画側の 720×1280 / 81 フレーム / 4 steps / CFG 1.0 / shift 5.0 / euler・simple はすべて一致していました。この組み合わせは画質を削った特別な設定ではなく、標準的な値です。

denoise は、I2V では探しても見つからないことがあります。うちの動画ワークフローでは開始画像を「条件」として渡し、latent 自体はノイズから作ります。前半・後半の分担は denoise ではなく「何ステップ目から何ステップ目まで」で指定しています。

• steps: 蒸留 LoRA を使うなら、まずその LoRA の設計ステップ数で試す
• CFG: 下げると速いが negative が効かなくなる。別の安全網があるかを先に確認する
• sampler / scheduler: モデルの推奨の組み合わせから始め、理由なく混ぜない
• shift: 他の値と同時に変えると効果を分けられない（うちはそうしてしまった）
• denoise: I2V で「開始画像からどれだけ離れるか」を調整したい時、この値が効くとは限らない

81 フレーム / 16fps は Wan 2.2 の標準値で、ここは変えていません。変えたのは「5 秒に何を入れるか」の方です。動作の切り替わりが 0 回の動画は却下率 44%、2 回だと 62% で、詰め込むほど却下が増えていました。1 本に入れる切り替わりは今は 3 つまでにしています。

解像度は、下げればたいていの問題が消えます。開始画像を latent に変換するエンコードは、本来なら数秒で終わる処理です。ところが VRAM が埋まっていて毎回失敗し、遅い分割方式にやり直して実測 145〜147 秒かかっています。720 から 640 に下げれば通常の方式に収まる見込みでしたが、公開する動画の画質を落としてまで取る 150 秒ではないと判断しました。

「最初から分割方式でエンコードする」も検討しましたが、分割方式そのものが遅いので、常に 150 秒かかる状態に固定されるだけです。根本の原因は GPU を他の処理と共有していることで、専有できる環境に移れば消える種類の無駄です。

一方、デコードは最初から分割方式にしています。81 フレームを一括で GPU に展開していた頃、メモリ不足の警告が出た直後に ComfyUI のプロセス全体が落ちたためです。分割方式のデコードは約 65 秒かかり 1〜2 割遅くなりますが、落ちて 1 本を失うより安いという判断です。

縦横比には、揃え切れていない箇所が残っています。開始画像は 832×1216、動画は 720×1280 で、比率が少し違います。比率の違う画像を渡すと動画の段階で合わせ込みが入るため、イラストで検証した時は開始画像を最初から 720×1280 で作りました。本番の実写側はまだ 832×1216 のままです。

• frames / fps: 5 秒に入れる動作は少ない方が通る。長さを変える前に中身を減らす
• 解像度: 下げればメモリ問題は消えるが、公開物の画質との交換になる
• VAE: ログで「エンコード」と「デコード」のどちらが重いかを分ける
• tiled decode: 速度より安定を取るなら先に入れておく。落ちてからでは 1 本ぶん遅い
• 縦横比: 開始画像と動画の比率は揃えておく方が、評価がぶれない

画像生成のテキスト理解は、否定をうまく扱えません。no wrinkles と書くと、「no」の意味は伝わらず、wrinkles という語への注意だけが残ります。避けたいものの名前を positive に書くこと自体が、それを呼び込みます。

2026 年 8 月に文面を機械で洗い出したところ、キャラ設定や衣装の文面に否定表現が 36 箇所、positive で指示しながら negative で禁じている自己矛盾が 55 箇所見つかりました。どれも書いた時点では誰も気づいていません。

鏡を禁じていた元の理由は、「反射に写った顔が増える」のを防ぐことでした。目的を直接書けば、場面そのものを殺さずに済みます。

反直感だったのは色です。動画の途中で色味が変わる問題に対して、動画側の negative に色や照明の語を 12 色ぶん詰め込んだところ、色ブレはむしろ悪化しました。注意が「色」という概念に集中するためだと考えています（推測）。全部削って最小限に戻し、色の制御は開始画像の段階に任せています。

逆に、効いた negative もあります。フィルム写真風の雰囲気を書いたキャラで、開始画像が白黒に倒れることがありました。monochrome などを negative に入れて、常にカラーになるようにしています。

ほくろは negative で全面禁止しています。ほくろはランダムな位置に低い頻度で出るので、動画ごとに有無や位置が変わり、同じキャラに見えなくなるからです。一方でそばかすは許可しています。密度の高い模様として出るので、再現性が高いためです。

• prompt の長さ: 同じ意味の語を 10 個並べても効きは代表 1〜2 語と同じ。安全用の語もこの方針で整理した
• negative prompt: 色の問題を色の語で直そうとしない
• 否定形: 避けたいものは書かず、望む状態を書く
• 矛盾: positive と negative の衝突は目視では見つからない。機械で検査する

2026 年 8 月の記録では、動画 1 本は約 9 分（504〜572 秒）でした。そのうち実際に絵を作っているサンプリングと、モデルの読み込み等を並べます。

絵を作っている時間より、読み込み等の方が倍以上長い。サンプリングは 1 本全体の 4 分の 1 以下です。残りの 90〜158 秒は、この記録では内訳を分けていません。

読み込みが重いのには構造上の理由があります。開始画像用のモデルと 14B の動画モデル 2 本を 32GB の VRAM に同時には置けないので、毎本、開始画像を作った後にモデルを降ろし、動画モデルを載せ直しています。

6 月に内訳を取った時は、読み込みは約 45 秒でした。条件で大きく振れる区間です。開始画像でも、空いている時は約 20 秒、他の処理と競合した時は 88〜99 秒と、同じ種類の振れを測っています。競合による再読み込みが主因だと見ていますが、動画側は分離して測っていません（推測）。

fp8 では、一度誤った記録を書きました。ファイルを 13.3GB の形式に替えた時「メモリの逼迫も緩む」と書いたのですが、翌日の実測で誤りだと分かりました。読み取り専用で読み込んだファイルの領域は、OS が必要に応じて捨てられるからです。ファイル形式を替えた正当な理由は 1 つだけで、計算は元から fp8 で行われていたので、倍の大きさのファイルを読む見返りがゼロだったことです。

OOM は 2026 年 8 月 26 日に集中しました。ComfyUI が 1 日に 4 回強制終了され、動画 13 件が失敗しています。原因は ComfyUI がメモリの上限を知らなかったことでした。実際の上限は 57GiB なのに、ComfyUI はマシン全体の約 251GB を見て「まだ空いている」と判断し、モデルを RAM に溜め続けていました。

効きそうで効かなかった手段です。

採用したのは計画再起動です。解放されないメモリが閾値を超えたら新しいジョブの受け付けを止め、走っているジョブは完走させてから ComfyUI を再起動します。

停止時間は 141 秒。強制終了で約 12 分ぶんの動画を失うより安く済みます。

キューの設計では 2 つ失敗しています。最初は「待ちが空になったら再起動」にしましたが、処理役は 1 本終わるとすぐ次を取りに行くので空の瞬間が来ず、46.6GiB まで上がっても発動しませんでした。今は閾値を超えたら受け付けを一時停止し、確実に隙間を作っています。また閾値を低くしすぎると 1〜2 本ごとに再起動になるため、34GiB ではなく 45GiB に置いています。

バッチは 1 回 1 枚です。画像を 1 枚ずつ別々に頼むと毎回モデル読み込みを払う点は、同じキャラの顔を保つ方法の記事で測りました（1 枚目 96.5 秒、2 枚目以降 6.1 秒）。

• モデルロード: 2 つの大きなモデルを交互に使う構成では、読み込みがサンプリングより重くなりうる
• fp8: ファイル形式と計算時の形式は別物。どちらが効いているのかを分けて考える
• VRAM: 空き容量ではなく、どの工程で足りなくなるかを見る
• OOM: メモリ解放の API を呼ぶ前に、それが RAM を減らすのか増やすのかを確認する
• キュー: 「空いたら何かする」は、空かないキューでは永久に実行されない

25 語を並べてきましたが、設定を変える時にやることは多くありません。

1. 工程ごとの内訳を測る。サンプリングが全体の 4 分の 1 以下という状況もありえます
2. 1 度に 1 つだけ変える。seed・開始画像・プロンプトを固定する。shift を同時に変えたうちは、その効果を今も分離できていません
3. モデルの設計点から始める。4 ステップ蒸留なら 4 ステップ、推奨の sampler があればそれ
4. 速さと引き換えに失うものを先に書き出す。CFG 1.0 は negative prompt を失います
5. 反映をログの実際の値で確認する。書き換えたことと効いていることは別です
6. プロンプトの問題を語の追加で解決しようとしない。否定形と矛盾は機械で検査する