【ClaudeCode】VRAM8GBのグラボでローカルAI動画生成環境を丸ごと作ってもらった話

AI画像生成はできていたけど、AI動画生成だけずっと諦めていた

最初にお断りしておく、これは業務改善とかじゃなくて趣味の話（雑記）である。

私は以前からStable Diffusionを使ってローカル環境でAI画像生成をやっていた。ローカルで完結する分、外部サービスの利用制限や料金を気にせず好きなだけ生成できるのが気に入っている。

当然、動画生成もやりたい。ただ、うちのグラボはRTX 2080 SUPERでVRAMが8GBしかない。過去に一度Stable Video Diffusionを導入してみたことがあったが、まともに動かず断念した。

ComfyUIの存在も知ってはいた。が、ノードを繋いでワークフローを組む方式が難しそうと感じており、また「どうせVRAMの壁に当たって動かないだろう」という諦観もあり、なかなか手を付けられずにいた。

そこで、Claude Codeに環境構築ごと投げてみることにした。ノード構築の手間だけでなく、VRAM8GBという厳しい条件の中で「何が動いて何が動かないか」の判断や、動くとしてもどこまで速度を詰められるかの検証まで、一括で任せられるのではないかと思ったからだ。結果として、想像していたよりずっと簡単な指示だけで、まぁとりあえずの動画生成環境が手に入った。

先に結論を書いておく

この記事は経緯がかなり長いし、正直Claude任せにするならあんまり気にする必要もない。まず要点だけ先に書いておく。

1. 私が出した指示は非常にシンプルだった。環境構築・環境調査・依存関係のトラブル対応・性能チューニングという、内容的にはかなり専門的な作業を一通りこなしているが、私自身が打った指示は次のような短い一言がほとんどだ。

「D:\Program Files\Stable\stable-diffusion-webui ここにstable diffusion webuiをインストールしているのだけど、画像から動画にしたりテキストから動画にできるように拡張機能を入れたい」

「見るに耐えんクオリティだなぁ」

「なんかチラつくなぁとは知覚できる。overlap上げて試してみて」

こちらが投げたのは感想や要望程度で、原因の特定や対処方法の検討はすべてClaude任せである。

2. VRAM8GBでも、工夫次第でそれなりの速度まで持っていけた。特に効いたのが「VAEデコード」というAI動画生成の一工程のやり方を変えるだけで、生成時間が20分13秒から63秒まで縮んだ。約19倍の高速化になる。ステップ数やモデルサイズを削る方向ではなく、VRAMに収まりきらないデータの処理方法を変えただけでこの差が出たのが一番の発見だった。詳しい原因は後述する。

最終的にできあがった環境では、1280x704の解像度・5秒程度の動画を約134秒で生成できている。VRAM8GBという、動画生成では最低ラインに近いスペックでもここまでできた。
まぁモデルが5Bとかなので、t2vの品質はお察しだが、i2vはプロンプトを拘ればそれなりに遊べるかも？というぐらいになった。
実際にstable diffusionで作った画像をcomfyuiのi2vで生成した動画は以下。なおこれは解像度が検証したのより良いやつなのでもっと時間がかかっている。

なお、この記事の後半には、Claude Codeを使わずに手動で同じ環境を再現するための手順も載せている。ここから先の「経緯」を読み飛ばしたい人は、「Claude Codeを使わない場合の導入手順」まで直接ジャンプしてもらって構わない。

経緯:何を、どう指示したか

ここからは実際のやりとりを追っていく。長くなるので、興味がある部分だけ拾い読みしてもらえればと思う。

現状調査と、AnimateDiffの限界

最初の指示は前述の通り、既存のA1111環境に動画生成の拡張機能を入れてほしいという内容だった。ここでClaude Codeがまずやったのは、環境を自分で調査することだった。A1111のバージョン、Pythonとtorchのバージョン、GPUのVRAM、導入済みの拡張機能とモデルを一通り確認した上で、次の事実を報告してきた。

• A1111本体は開発が停滞しており、最新版でも2024年7月のタグが最終である
• 私の手持ちモデルは全てSDXL系だが、動画生成用の拡張機能「AnimateDiff」とSDXLの相性は最悪で、拡張機能の作者自身が「非常にがっかりする」とドキュメントに明記している
• VRAM実測でも、SDXLだと512px・8フレームで8.66GBを要求してくる一方、SD1.5モデルなら512px・16フレームで4.2〜5.6GBに収まる
• 2026年時点でのローカル動画生成の本命はComfyUI + Wan 2.2系であり、A1111は周回遅れの選択肢である

つまり「今使っているモデルではまともに動かない」「そもそも今からやるならA1111ではない」という、まぁそうだろうねという正直な報告だった。この判断を受けて3択(SD1.5モデルの追加導入・ComfyUIの導入・Deforumの追加)を提示され、どうせならと全部やってもらうことにした。

ComfyUI導入と、動くかどうかの実測確認

ComfyUIの導入自体はインストーラーの展開だけなので難しくない。重要だったのは、その先の判断だ。うちのRTX 2080 SUPERは「Turing」という世代のGPUで、最新のCUDAでは対応が切られる一歩手前にある。同梱されるtorchが本当にこの世代のGPUに対応しているのか、Claude Codeは「対応しているはず」で済ませず、実際にGPU上で行列演算をさせて確認していた。

結果はGPU上でのfp16演算まで正常に通り、無事に動作確認が取れた。

あわせて、A1111側で使っているモデル(チェックポイント22本・VAE・LoRA類)をComfyUIからも参照できるよう、設定ファイルで共有させている。

VRAM8GBで「何が動くか」をサイズから判定する

ComfyUIで動画生成をする場合、本命はWan 2.2という動画生成モデル系列になる。ただし同じWan 2.2でも複数のサイズ・形式があり、当然VRAM8GBでは選べる範囲が限られる。ここでClaude CodeはHugging Face(モデルの配布サイト)のAPIから各モデルの実ファイルサイズを取得し、8GBに収まるかどうかを判定していった。

モデル	最小サイズ	VRAM8GBで動くか
Wan 2.2 TI2V-5B(通常版)	10.00 GB	厳しい
Wan 2.2 TI2V-5B(GGUF量子化版)	3.81 GB	動く
Wan 2.2 14B(高精細版)	14.29 GB × 2本	不可
その他の大型モデル(MiniMax-H3、LTX-2.3等)	29〜42 GB超	不可

結論として、8GBで現実的に動くのは「Wan 2.2 TI2V-5B」というモデルを、GGUF(モデルを圧縮する量子化形式の一種)で軽量化した版だけだった。このモデル1本でテキストからの動画生成と、画像からの動画生成の両方をカバーできる。実際にダウンロードして動かしたところ、704x480・49フレームの動画が正常に生成できることを確認できた。

依存パッケージが壊れて、A1111が起動しなくなった

ここが今回の作業で一番ヒヤッとした場面だ。AnimateDiffを動かすのに必要な拡張機能「ControlNet」を導入した際、その依存パッケージが既存環境のnumpy(Pythonの数値計算ライブラリ)を勝手に新しいバージョンへ上げてしまい、A1111そのものが起動しなくなったとClaudeが報告してきた。なにをしてくれとんねん。

その後Claudeが直せば直したで、今度は別のライブラリ(mediapipe)のバージョン不整合でControlNetが読み込めなくなり、それを直すとまた別のパッケージが芋づる式に壊れる、という連鎖が起きた。最終的にはnumpy・protobuf・mediapipeのバージョンをそれぞれ特定の組み合わせに固定し、依存関係10個ほどを1つずつ実際にインポートして動作確認するところまでやって、ようやく全部エラーなく起動する状態に落ち着いた。

正直、ここは私が自力でやっていたら心が折れていたと思う。原因の特定から復旧まで、丸ごと引き受けてもらえたのは大きかった。

生成が遅すぎる問題を、実測で切り分ける(この記事の核心)

環境自体はできた。ただ、最初に生成した動画の画質を見て、私は正直こう思った。

「見るに耐えんクオリティだなぁ」

原因は解像度だった。使っていたWan 2.2 TI2V-5Bの学習解像度は1280x704なのに、「VRAM8GBで確実に落ちないように」と初期設定が704x480に抑えられていたため、画質が大きく崩れていたのだ。ネイティブ解像度の1280x704に上げたところ、画質は本当に多少改善したが今度は1本の生成に22分56秒もかかるようになった。

「ステップ数(生成の反復回数)を減らせば速くなるはず」という仮説で、4ステップで動く蒸留版モデル(Turbo版)を試したが、20分13秒とほとんど変わらなかった。ステップ数は原因ではなかったということになる。

ここでログの進捗表示を細かく確認したところ、実際に時間がかかっていたのは生成のサンプリング処理(23秒)ではなく、その後の「VAEデコード」という、生成結果を実際の映像データに変換する工程だった。1280x704・49フレーム分のデータがVRAMに収まりきらず、GPUとCPUの間でデータを行き来させながら処理していたため、ここだけで19分以上溶けていたのだ。ステップ数を減らしても、そもそもボトルネックが別の場所にあったので速くならなかったわけである。

対処として、VAEデコードを「タイル分割」方式(映像を小さく分割してから変換し、あとで結合する処理)に切り替えたところ、20分13秒だった生成時間が63秒まで縮んだ。約19倍の高速化だ。

ただし、これで終わりではなかった。タイル分割にした動画を見ると、今度はチラつきが気になった。

「なんかチラつくなぁとは知覚できる。overlap上げて試してみて」

Claudeの最初の仮説は「タイルの継ぎ目部分の重なり(overlap)を増やせば直るはず」というものだったが、これは外れだった。overlapを倍にしても画質(PSNRという指標で比較)は変化せず、処理時間だけ63秒から170秒に悪化した。4パターンを実測で比較した結果、本当の原因は「時間方向の分割サイズ(temporal_size)」だとわかった。この値を調整したところ、チラつきの指標(隣接フレーム間の差分)がタイル分割なしの基準値とほぼ一致するまで改善し、しかも処理時間はそれまでで最速の52秒になった。

「なんとなく良くなった」で終わらせず、生成した動画を実際に数値で比較して判定していたのが印象的だった。AIがそこまで動画の中身を判別できるとは知らなかった。
最終的な設定と処理時間の推移は次の通りである。

段階	設定	生成時間
初期設定	704x480 / 49フレーム / 20ステップ	約3分(低画質)
ネイティブ解像度化	1280x704 / 49フレーム / 20ステップ	22分56秒
Turbo版導入	1280x704 / 49フレーム / 4ステップ	20分13秒
VAEデコードをタイル分割化	同上 + タイル分割	63秒(約19倍)
パラメータ最適化	タイル・重なり・分割サイズを調整	52秒
尺を5秒に延長	121フレーム	134秒

最後に尺を延ばす方法も聞いてみた。

「ちらつきはOK。動画の秒数は延ばすにはどうすれば?」

ComfyUIのソースコードを読んで仕様を確認した上で、フレーム数の指定方法を教えてもらい、121フレーム(約5秒)まではVRAMに余裕を残したまま伸ばせることを実測で確認した。これはWan 2.2 TI2V-5Bがもともと学習している尺の長さでもあるらしい。

認証が必要なサイトからのダウンロードも、ブラウザ操作で解決

Wan 2.2は実写寄りの学習が中心で、アニメ調の絵は苦手だ。そこでLoRA(モデルの絵柄を追加学習で変える追加データ)を当てたいと思ったが、目当てのアニメ系LoRAはCivitaiというサイトにしかなく、ダウンロードにログイン認証が必要だった。

「ログイン済みのブラウザあるからclaude in chromeで対応できん? Retro 90's Anime / Golden Boy Styleだけでいいや」

Claude Codeと連携するChrome拡張機能「Claude in Chrome」を使い、私がログイン済みのブラウザをそのまま操作してダウンロードしてもらった。目当てのLoRAは容量違いのバージョンが複数あり、既定で選ばれる方は使っているモデルサイズと合わないものだったが、正しいバージョンを選び直してダウンロードまで進んだ。
ただ、ClaudeCodeでやったのが良くなかったのか保存先を選ぶダイアログが表示されると処理が止まった。仕方なく自分で保存先を指定した。Claude CoworkだったらClaude in chromeが操作して出たダイアログの操作もできたんだろうか。

ダウンロード後は、ファイル名だけで信用せず、LoRAファイルの中身(テンソルの次元数)を直接確認して、本当に使っているモデルサイズ向けのファイルかどうかまで検証していた。

今回わかった落とし穴

一連の作業を通して分かった、ハマりやすいポイントをまとめておく。

• VAEデコードを通常方式のままにすると、同じ設定でも52秒が20分13秒に化ける。VRAM8GBではWan系のVAEがそのままでは収まらないため
• タイル分割の「重なり(overlap)」を増やしてもチラつきは直らないことがある。原因が別(時間方向の分割サイズ)にあるケースがあるため
• 蒸留版(Turbo)モデルはステップ数・CFG値が専用設定に固定される。特にCFG1ではネガティブプロンプトが完全に無効になる
• AnimateDiffにSDXL系モデルは使わない方がいい。SD1.5系のモデルを別途用意する必要がある
• ControlNetの導入は既存のPython環境を壊しうる。numpy・protobuf・mediapipeあたりのバージョン固定が必要になる場合がある
• VRAM8GBではA1111とComfyUIを同時に起動しない方がいい。両方が VRAMを取り合って共倒れになる（する奴いないと思うけど）
• Civitaiからのダウンロードはバージョン選択に注意する。既定で大きいサイズのモデル向けが選ばれていることがある

Claude Codeを使わない場合の導入手順

ここからは、Claude Codeを使わずに同じ環境を手動で作りたい人向けの手順だ。上から順にやれば同じ状態になるはず。ただ試したわけではないので是非ClaudeCodeやCodexと相談してみてほしい。

ComfyUI本体とカスタムノード

1. ComfyUIの公式リリースページから "ComfyUI_windows_portable_nvidia.7z" をダウンロードして展開する
   https://github.com/comfyanonymous/ComfyUI/releases

2. カスタムノードを導入する
cd ComfyUI_windows_portable/ComfyUI/custom_nodes
git clone --depth 1 https://github.com/Comfy-Org/ComfyUI-Manager.git
git clone --depth 1 https://github.com/city96/ComfyUI-GGUF.git

cd ../..
./python_embeded/python.exe -m pip install "gguf>=0.13.0" sentencepiece protobuf
./python_embeded/python.exe -m pip install -r ComfyUI/custom_nodes/ComfyUI-Manager/requirements.txt

モデルの配置

配置先フォルダ	入手元
ComfyUI/models/diffusion_models/	huggingface.co/hum-ma/Wan2.2-TI2V-5B-Turbo-GGUF (Q6_K版)
ComfyUI/models/text_encoders/	huggingface.co/city96/umt5-xxl-encoder-gguf (Q5_K_M版)
ComfyUI/models/vae/	huggingface.co/QuantStack/Wan2.2-TI2V-5B-GGUF (VAEフォルダ内)

ワークフローの設定

run_nvidia_gpu.batでComfyUIを起動し、テンプレートから「Wan 2.2 5B TI2V」を読み込んだ上で、次のノードを差し替える。

元のノード	差し替え後
UNETLoader	Unet Loader (GGUF)
CLIPLoader	CLIPLoader (GGUF)(typeは"wan"を指定)
VAEDecode	VAE Decode (Tiled)(tile 512 / overlap 128 / temporal_size 64 / temporal_overlap 8)
KSampler	steps 4 / cfg 1.0
Wan22ImageToVideoLatent	1280 x 704 / length 121

※ UNETLoaderとCLIPLoaderは、現行のComfyUIのUI上では「Load Diffusion Model」「Load CLIP」という表示名にリネームされている。ノード検索で上の名前のまま探すと見つからないことがあるので、UI上はこちらの名前で探すこと。

この設定が、前述の「63秒→52秒」まで詰めた最適化のポイントをそのまま反映したものになる。ここだけ真似すれば、遅くて使い物にならない状態を避けられるはずだ。

(参考)A1111 + AnimateDiffを使う場合

ComfyUIではなく、使い慣れたA1111側で動画生成を試したい場合の手順も一応載せておく。ただし前述の通りSDXLモデルとの相性は悪いので、SD1.5系のモデルを別途用意する前提になる。

cd stable-diffusion-webui/extensions
git clone --depth 1 https://github.com/Mikubill/sd-webui-controlnet.git
git clone --depth 1 https://github.com/continue-revolution/sd-webui-animatediff.git

# モーションモジュールを extensions/sd-webui-animatediff/model/ に配置する
#   huggingface.co/conrevo/AnimateDiff-A1111 の motion_module/mm_sd15_v3.safetensors など

# SD1.5系のモデルを models/Stable-diffusion/ に配置する

# ControlNet導入後は依存関係が壊れやすいため、バージョンを固定しておく
cd ..
./venv/Scripts/python.exe -m pip install "numpy==1.26.2" "protobuf==3.20.0" "mediapipe==0.10.14"

起動後は「設定 → Optimizations」内の「Pad prompt/negative prompt to be same length」を必ずONにしてApply settingsを押しておくこと。これをやらないと、無関係な動画が2本同時に生成されてしまう。

まとめ

VRAM8GBという、動画生成では最低ラインに近いグラボでも、工夫次第でそれなりの速度まで持っていけることが分かった。しかも、その工夫を見つけるための試行錯誤(環境判定・依存関係の修復・原因の切り分け・実測での比較)を、私自身はほとんど手を動かさずに済ませられた。

個人的に一番印象に残っているのは、遅さの原因がステップ数でもモデルサイズでもなく、VAEデコードという見落としがちな工程にあったことだ。当てずっぽうで設定をいじるのではなく、ログを見て実測で切り分けるというアプローチだったからこそ、19倍という数字にたどり着けたのだと思う。

「ローカルでAI動画生成をやってみたいけど、グラボが非力だから」「ComfyUIのノード構築が大変そうで手を付けられていない」という人には、一度Claude Codeに環境構築ごと相談してみることをすすめたい。