SCAIL-2は、清華大学とZ.aiの研究チームが開発した、動画の動きを人物・キャラクター画像へ転送できるオープンソースのAIモデルです。1枚の画像と元動画だけで面倒な設定なし、「骨格なし」、でアニメーション化できる画期的なAIです。
今回はComfyUI v0.27で公式サポートされたSCAIL-2 INT8モデルを試してみました。
なぜ「骨格なし」が実用上の利点になるのか
これまでの多くのモデルとSCAIL-2の決定的な違いは、動きを伝える際の「情報の渡し方」にあります。
従来モデル（OpenPose等）の構造
- 仕組み： 動画 ➔ 棒人間（骨格）や深度マップに変換 ➔ AIに読み込ませる。
- 技術的な問題：映像を一度「点と線」に抽象化するため、手前の手と奥の体が重なった際の「奥行き」や、服の正確なひらつきなどの情報がその時点で消失します。
- 結果として、AIが肉付けする段階で「手足が突き抜ける」「指がバグる」といった破綻が起きていました。
せっかく元の動画で服がひらひら動いていたり、手前と奥で手が交差していても、棒人間にしてしまうと『ただの線』になってしまうため、情報が消えてしまっていました。その結果、手が体の中にめり込んだり、2人の人間が絡み合う動きをさせるとAIがパニックを起こして崩れてしまっていました。
SCAIL-2 の「End-to-end Driving（エンドツーエンド駆動）」
- 仕組み： 動画のピクセル（見た目そのもの）を直接DiT（Diffusion Transformer）のエンコーダーに渡す「Unified Motion Transfer」を採用。
- 情報の無損失： 棒人間に変換しないため、2人がハグするような複雑な接触、手前の手が奥に回るような前後関係（オクルージョン）をAIが空間的に正しく理解します。
- 人外への対応： 骨格の定義に縛られないため、人間の動画の動きを4本足の動物やモンスターの画像にそのまま転送する（Animal-driving）ことが、モデルの基本仕様として可能です。
コントロール用の追加モデル（棒人間や深度）を別で管理・調整する必要がなく、「元動画」と「キャラクター画像」の2つだけ用意すれば動くという、ノード（ワークフロー）のシンプル化が最大のメリットです。
人間以外（キャラクターや動物）も動かせる
骨格に依存しないため、人間以外のキャラクターも動かせます。
- メリット： モンスター、ファンタジーの生き物、あるいは4本足の動物の動画を元にして、イラストのキャラクターを同じように動かすといった「異次元のモーション転送」が可能です。
「Animation（動かす）」と「Replace（置き換える）」の二刀流
1つのモデルで2つのアプローチができます。
- Animate： 1枚のイラスト（背景白など）を、元動画の動きに合わせて動かす。
- Replace： 元の動画の背景はそのままに、「写っている人間だけを自分のイラスト（推しキャラなど）にすり替える」。
「FP8」と「INT8」
FP8： 浮動小数点（Floating Point）の8ビット。一般的に ComfyUI で巨大モデルを動かす際の標準です。
INT8： 整数（Integer）の8ビット。計算処理を整数に限定することで、グラフィックボード（GPU）の Tensor コア等の処理効率が最適化されます。
ComfyUI 公式ワークフローテンプレートの説明
ワークフロー（video_wan21_scail2_character_replacement.json）は、SCAIL-2を用いて、参照画像（キャラクター）と駆動動画を組み合わせ、動画内の人物を置き換える（あるいはアニメーションさせる）ためのComfyUI用のパイプラインです。
※追記：2026年7月14日にテンプレートにvideo_wan21_scail2_character_replacement_int8.jsonが追加されました。
ワークフローの全体像と主要な2つのモード
このワークフローには replace_mode（真偽値）というパラメータが存在し、用途に合わせて2つのモードを切り替えることができます。今回の構成ファイルではデフォルトで true（Replacementモード）に設定されています。
- Replacementモード（
replace_mode=true）:
駆動動画(元動画)に映っている特定の人物（トラッキング対象）を、参照画像のキャラクターへと「すり替える（置換する）」モードです。 - Animationモード（
replace_mode=false）:
参照画像のキャラクターに対し、駆動動画のモーションのみを転送して動作させるモードです。
主要なノードとその役割
入力エリア（Source Video and Reference image グループ）
- LoadVideo ノード:
動きの元となる駆動動画を読み込み、出力されたVIDEOデータを各サブグラフへ送信します。 - 30 LoadImage ノード:
適用したいキャラクターの参照画像を読み込み、IMAGEデータを各サブグラフへ送信します。
処理の核（サブグラフ構造）
このワークフローは、処理をカプセル化した「サブグラフ（Subgraph）」を連鎖させる構造になっています。内部には wan2.1_14B_SCAIL_2_fp16.safetensors や sam3.1_multiplex_fp16.safetensors（セグメンテーション用）といったモデルが配置されています。
- Character Replacement (SCAIL-2 Base) ノード:
動画の最初のチャンク（第1セグメント：デフォルトで81フレーム）を処理するベースノードです。segment_index = 1として動作します。 - Character Replacement (SCAIL-2 Extend) ノード: 第2セグメント以降（82フレーム目以降）を処理するための拡張用ノードです。前のセグメントからの出力画像（output）を
previous_framesインプットに接続し、前の動きや一貫性を引き継ぎながら生成を継続します。このとき、segment_indexを2以上の適切な数値に設定します。
長尺動画のフレーム計算とプレビュー
GetVideoComponents ノード:
LoadVideo から映像を分解し、画像（フレーム）、オーディオ、FPSを取得します。
GetImageSize ➔ ComfyMathExpression ➔ PreviewAny ノード:
動画全体のフレーム数（batch_size）を取得し、数式 ceil(a / (81 - 5)) を用いて、生成に必要な合計セグメント数を自動計算してテキストプレビューします。
81はデフォルトのフレームカウント（frame_count）です。5はセグメント間でラップ（重複）させるフレーム数（previous_frame_count）です。- これによって、長尺動画が何個のセグメントに分割されるかを算出します。
出力エリア
CreateVideo ➔ SaveVideo (First Segment) ノード:
最初のセグメントのみを動画として書き出し、中間確認ができます。
BatchImagesNode ➔ CreateVideo ➔ SaveVideo (Final output) ノード:
最初のセグメントと、続く拡張セグメントの出力を結合（バッチ化）し、最終的な一本の置き換え動画として書き出します。音声やFPSも自動的に同期されます。
公式は「数珠繋ぎ（セグメント分割）」にしている
公式ワークフローは「動画を3秒ごとに細切れにして、前の仕上がりを引き継ぎながら生成する」というアプローチ（サブグラフの連鎖）をとっています。
- 最初の3秒（1〜81フレーム）： Baseノードが真っ新な状態から動画を生成。
- 次の3秒（77〜157フレーム）： Extendノードの
previous_framesという入り口に、1.生成した動画を繋ぐ。
SCAIL-2は、この繋がれた過去の動画の「末尾の5フレーム（overlap）」を参照しながら続きを描きます。これによって、VRAMを節約しつつ、1本の繋がった動画を破綻させずに作ることができます。
長尺動画はExtendノードを複製して同じように繋ぐだけで生成可能です。
INT8 と FP8モデルで生成
VRAM 16GBの環境で生成しました。
wan2.1_14B_SCAIL_2_int8_convrot.safetensors 16.26GB
wan2.1_14B_SCAIL_2_fp8_scaled.safetensors 17.28GB
Google Flowで生成した、画像と動画を使用してアニメーションモードで6秒の動画生成。
6秒の動画5本の平均値は
- FP8：約224秒
- INT8：約200秒
秒単位の短縮効果：INT8はFP8に比べて、1本あたり24秒早く完了。
処理時間の短縮率：FP8（224秒）を基準とした場合、処理時間は約10.7%短縮。
最新のアニメーション生成モデルは、INT8（整数化）による情報のカットをうまく補正する技術が進化しています。特にアニメ調の映像や、動きが激しいシーンでは、人間の目にはFP8との微小なディテール差がほとんど認識できませんし、FP16にも肉薄しています。
VRAM 16GB環境では、SCAIL-2のINT8は確かに速くなりました。
ただし、「劇的に爆速化した」というよりは、同じ条件なら確実に少し速くなる、という印象です。
INT8の効果はGPUによって変わる
SCAIL-2のような重い動画生成では、GPUの処理性能だけでなく、VRAMの容量もかなり重要になります。RTX 3090は世代としては二世代前のGPUですが、VRAMは24GBあります。さらに、RTX 30シリーズはFP8に強い世代ではないため、INT8の方が相性よく動く可能性があります。そのため、私の環境では約10.7%短縮という結果でしたが、RTX 3090のようなVRAMに余裕のあるRTX 30シリーズでは、もっと大きな差が出る可能性があります。
低VRAM環境ではGGUFとの比較も重要
一方で、RedditではINT8だけでなく、GGUFの低VRAMワークフローもかなり話題になっています。
SCAIL-2 GGUFの低VRAMワークフロー投稿では、SCAIL-2を低コストで動かすために量子化し、低解像度でも品質は保たれている、と説明されています。Hugging Faceリポジトリとワークフローも共有されており、SCAIL-2を低VRAM環境で試したいユーザー向けの流れもあります。
さらに、INT8 ConvRotの解説投稿では、GGUF派の意見として「自分のVRAMに合わせやすい」「他の作業をしながらでも生成が失敗しにくい」というメリットが挙げられています。特に、ComfyUIのDynamic VRAMでRAM側に逃がす動きが発生すると、ブラウザタブを大量に開いているような環境では、生成失敗やシステムメモリ不足につながる可能性がある、という実用面の指摘も出ています。
私のVRAM16GBの環境では
- INT8：共有メモリに15GB以上あふれて、平均200秒
- GGUF Q4_K_M：VRAMは8GB程度の使用、平均330秒
このあたりを見ると、SCAIL-2の軽量化は単純に「INT8が最強」「GGUFは不要」という話ではなく
- INT8 ConvRotは速度と品質のバランスで有力
- GGUFはVRAM使用量を減らし、低VRAM環境で安定運用しやすい
このように、それぞれ役割が違うと考えた方がよさそうです。
