記事用の挿絵を SDXL で生成して、そこで止まっている。動かしたいが、商用利用の可否がはっきりしないモデルに手を出す気にはなれない。AIdeaLab が2026年7月13日に公開した「AnimeGen」は、この足踏みを解消できる候補だ。ライセンスを条文まで読んで確かめた。
目次
まず何が公開されたのか
テキストから動画を作る T2V と、静止画から動画を作る I2V の2種類が Hugging Face に置かれている。ベースは Alibaba の Wan2.2-T2V-A14B と Wan2.2-I2V-A14B で、14B のエキスパートを2つ持つ MoE 構成。アニメ表現向けに追加学習したものだ。
経産省・NEDO の GENIAC 支援を受け、香川県の KDDI クラスタで NVIDIA H200 を24基使って学習したとプレスリリースに書かれている。学習フレームワークは DiffSynth-Studio。
フレーム補間のデモも公開されているが、これは独立したモデルではない。I2V のリポジトリに含まれるコード例として提供されていて、デモの実装も aidealab/AnimeGen-I2V をロードしている。
ここで1点、各所の記述を訂正しておきたい。「2025年10月のβ版から約半年」と紹介されることが多いが、当時のβは Google アカウント登録制の無償Webサービスで、重みの配布ではなかった。今回起きたのは、クローズドβからオープンウェイトへという配布形態そのものの転換だ。Hugging Face のリポジトリ作成日は6月17日で、7月13日は公開告知の日付になる。
関連して、animegen.jp は2025年10月のβ登録ページのまま更新されていない。フッターの表記も「© 2025」、CTA も「ベータテストに参加」、名称は「AnimeGen（仮称）」のままだ。今回のリリースの資料として参照すると混乱する。
ライセンスを条文まで読んだ
ここが今回いちばん確かめたかった部分だ。「商用利用可」と報じられていても、実際には独自条項が足されているモデルは珍しくない。LICENSE ファイルを取得して全文を照合した。
改変のない標準の Apache License 2.0 だった。 冒頭は Apache License / Version 2.0, January 2004 で、第1条から第9条まで標準の文面どおり。RAIL や Llama 系のような使用制限付き条項の挿入は一切ない。
依存関係も追った。高速化に使う lightx2v/Wan2.2-Lightning も Apache-2.0、ベースの Wan 2.2 自体も Apache-2.0。ライセンスチェーン全体がクリーンだった。Lightning のリポジトリには「生成されたコンテンツに対する権利を主張しない」という記述もある。
| 項目 | 条件 |
|---|---|
| 商用利用 可 | 追加許諾・料金・報告義務なし |
| 生成物への帰属表示 | 不要 |
| モデル自体の再配布 | 可。第4条により著作権表示・LICENSE・NOTICE の保持と変更点の明示が必要 |
| 派生モデルの作成 | 可。特許ライセンスの明示付与（第3条）あり |
禁止用途はライセンス条項ではない
モデルカードには、実在人物のディープフェイク、なりすまし、誤解を招く報道風コンテンツ、ハラスメントや非同意の描写、未成年に見えるキャラクターの性的コンテンツなどを禁止する記述がある。読み違えたくないのは、これが LICENSE ファイルの外にあるポリシー表明だという点だ。法的拘束力のある使用許諾条件として書かれてはいない。
倫理的に守るべき内容であることに変わりはない。ただ「ライセンス違反になる」と「ポリシーに反する」は扱いが違うので、記事や社内資料に書き写すときは区別しておきたい。モデルカードには「利用者は、自らの利用が適用法・プラットフォーム規約・倫理指針に適合することを確認する責任を負う」とも書かれている。
出力物の権利は別問題として残る
Apache-2.0 は重みに対するライセンスであって、生成された動画の著作権を保証するものではない。既存の作品に似た出力が出た場合の権利処理は利用者の責任として残る。
学習データの構成は非開示だ。プレスリリースは「日本国内の著作権法および関連法令に基づき、適切に実施しております」と述べるにとどまる。過去作の AIdeaLab-VideoJP が「CC-BY / CC-0 のみ」を訴求していたのに対し、今回は著作権法30条の4への依拠に後退している。追加学習の手法やデータ規模、パラメータの差分も公開されていない。
批判も出ている。GENIAC は税金による支援なのに学習データが開示されない点と、「国産」と呼ばれる一方で基盤が中国製の Wan 2.2 である点。この2つは根拠を示して議論できる。
公式サンプルが既存アニメ作品に似ているという指摘も流れているが、こちらは出所が匿名の投稿による視覚的な印象で、データセットが非開示である以上、検証する手段がない。未検証の指摘として扱うのが妥当だと考えている。
手元で動かす前に知っておきたい罠
筆者は背景除去も文字起こしもローカル完結で作ってきたので、この手のモデルはまず手元に落とす。今回は落とし方から注意が要った。
git clone すると I2V は約114GB 落ちてくる。 フラット形式の safetensors（28.6GB × 2）に加えて、diffusers 形式の transformer/ と transformer_2/ が二重に収録されているためだ。
from huggingface_hub import snapshot_download
# フラット形式だけ取る（diffusers 形式の重複を避ける）
snapshot_download(
"aidealab/AnimeGen-I2V",
allow_patterns=["*.safetensors", "*.json", "*.md"],
ignore_patterns=["transformer/*", "transformer_2/*"],
)VRAM も素直ではない。1エキスパートが 28.6GB あるので、bf16 のままでは 24GB のカードに載らない。公式のサンプルコードが float8 へのキャストと CPU オフロードを両方入れているのはこのためだ。
transformer_high.enable_layerwise_casting(
storage_dtype=torch.float8_e4m3fn, compute_dtype=torch.bfloat16)
transformer_low.enable_layerwise_casting(
storage_dtype=torch.float8_e4m3fn, compute_dtype=torch.bfloat16)
pipe.enable_model_cpu_offload()推奨は RTX 4090 以上とされているが、これは保守的な値らしい。RTX 3090 24GB を fp8 で動かした報告、RTX 5060 Ti 16GB で sequential CPU offload を使いフレーム補間に4分25秒という報告、RTX 4070 12GB での稼働報告がある。
日本の NullpoLab 氏が GGUF 量子化版（Q4_K_M から Q8_0 まで4段階を各エキスパート分）を公開していて、こちらなら 12GB 級でも 480p が動くという報告もある。
ComfyUI の資産がそのまま効く
既に ComfyUI で Wan 2.2 を回しているなら、ここが一番の朗報だと思う。
safetensors のヘッダを直接読んで確認したところ、キーの命名が Wan ネイティブ形式になっていた（blocks.0.cross_attn.q.weight、dim 5120、FFN 13824、40ブロック）。patch_embedding.weight の形状は T2V が [5120,16,1,2,2]、I2V が [5120,36,1,2,2] で img_emb.* を持たない。これは Wan 2.2 の I2V として正しい形だ（2.2 で CLIP 画像エンコーダが廃止された）。
ComfyUI 標準の Wan 2.2 A14B テンプレートの UNETLoader に、そのまま差し替えて載る形式になっている。VAE とテキストエンコーダはリポジトリに含まれないので、Comfy-Org の wan_2.1_vae.safetensors と umt5_xxl を別途用意する。新しいワークフローを組み直す必要はない。
GGUF 版を使うなら city96 の ComfyUI-GGUF（UnetLoaderGGUF）が要る。配布元の README には設定まで書かれていて、4ステップ LoRA の HIGH 側の strength を 2 にすること、総8ステップを high 0→4 / low 4→8 で分割することが指定されている。
プロンプトの前置きを省かない
公式実装は、渡したプロンプトの先頭に "Japanese anime style, " を自動で付けている。自前でパイプラインを組むときにここを省くと品質が落ちる。
width, height, secs = 832, 480, 5
output = pipe(
prompt="Japanese anime style, " + prompt, # 前置きは必須
negative_prompt="3d, cg, photo, stop, wait",
height=height, width=width,
num_frames=int(16 * secs + 1),
guidance_scale=1.0, num_inference_steps=8,
generator=torch.Generator("cuda").manual_seed(42),
).frames[0]
export_to_video(output, "output.mp4", fps=16)ネガティブに stop, wait が入っているのは、被写体が静止してしまう症状への対策と読める。
事故が多いのが LoRA の取り違えだ。高速化用の Lightning LoRA は T2V と I2V でフォルダが別になっている。GGUF 版を配布している方の README にも、自分が取り違えたという記述があるほどで、ここは最初に確認しておきたい。I2V 側は Wan2.2-I2V-A14B-4steps-lora-rank64-Seko-V1/ で、推論ステップ数も4になる。
どこまで動かせるか
仕様は 832×480 または 1280×720、16fps、フレーム数は 16 × 秒数 + 1。81フレームで約5秒が上限の例として示されている。
そして品質の限界を、公式が自分で明記している。複雑なキャラクター動作での不安定さ、フレーム間での同一性のドリフト、時間方向のちらつき、手や指や目の不整合。利用者の検証でも、軽い動きは良好、中程度で手に残像、大きい動きで破綻という傾向が一致している。
寄りの構図と小さい動きに限定するのが実用解だと考えている。720p より 480p のほうが良い結果になりやすいという報告も複数あり、480p に落として浮いた VRAM で fps を 8 から 16 に上げたら劇的に改善した、という具体例もある。
公式が触れていない挙動として、最初の約2秒が硬直するという報告がある。トリミングで対処されている。生成した動画をそのまま使わず、頭を落とす前提で尺を長めに取っておくといい。
公式自身が「完成品ではなく、これから育てていくための公開」と位置づけ、最大の課題を「参考画像をもとにした安定したアニメ生成」だとしている。絵コンテやビデオコンテを作るためのものと捉えるのが正確だ。
SDXL の挿絵を動かす流れ
既存の静止画生成からどう繋げるかを、順に書いておく。
まず入力画像を用意する。I2V の公式コードは、指定した max_area からアスペクト比を保ったまま mod_value の単位に丸める処理を持っている。SDXL の出力をそのまま渡しても内部で調整されるが、あらかじめ 832×480 に近い比率で作っておくとトリミングの意図が崩れない。
次に動きの指示を書く。ここは静止画のプロンプトとは考え方が変わる。何が写っているかは入力画像が持っているので、書くべきはどう動くかになる。「風で髪が揺れる」「まばたきをする」「visor の光が明滅する」といった、小さく閉じた動作を1つか2つ。
生成したら等倍で再生して手と目を見る。破綻していれば動きの指示を小さくする。ここを繰り返すことになるので、1本あたりの生成時間が短い設定（480p、短い尺）で回すほうが試行回数を稼げる。
仕上げに頭を落とす。最初の約2秒が硬直するという報告があるので、必要な尺より長めに生成してトリミングする前提で組んでおく。
アイキャッチを動かす用途で足りるか
記事のアイキャッチを軽く動かしたいだけなら、この範囲で十分だと考えている。寄りの構図で、髪や衣服が揺れる程度の動き。カメラは固定。尺は2秒から3秒。ループさせるなら最初と最後が繋がるように選ぶ。
全身が歩く、振り向く、複数キャラクターが絡む、といった動きは現状では厳しい。公式が「複雑なキャラクター動作での不安定さ」と書いているのはそのままの意味だ。
他の選択肢と比べてどうか
動画生成は選択肢が増えている。今回のモデルを選ぶ理由があるとすれば、次の3点になる。
| 観点 | AnimeGen |
|---|---|
| ライセンス 強い | Apache-2.0 で、依存も含めチェーン全体がクリーン |
| アニメ表現 | Wan 2.2 に対して追加学習済み |
| 既存資産 | ComfyUI の Wan 2.2 ワークフローがそのまま使える |
逆に選ばない理由もはっきりしている。クラウドのサービスを使えば VRAM の心配は要らないし、動きの自由度も高い。手元に落とす意味があるのは、生成枚数が多い場合と、データを外に出したくない場合だ。
筆者は後者の理由でローカルを選ぶことが多い。背景除去のツールも文字起こしのツールも、完全にオフラインで動くように作ってきた。動画も同じ方針で試している。
筆者ならこう組む
ゲーム用のアセットを量産したときに学んだのは、数値のメトリクスだけで合格を判定すると見切れや台座残りを見逃すということだった。透過処理では、暗い被写体が黒く見えて誤判定したり、台座が残っているのに数値上は問題なしと出たりする。最終的に「不透明な単色に合成して目視する」手順に行き着いた。
動画も同じで、生成後に等倍で再生して手と目を見るまでは判断を保留したい。フレーム単位のスコアが良くても、通して見ると指が溶けている、ということは起きる。
筆者なら、まず GGUF 版と ComfyUI の既存ワークフローで 480p・寄り・小さい動きに絞って試す。SDXL で作った挿絵を I2V に入れて、記事のアイキャッチを軽く動かす用途なら、この範囲で足りる。フル精度の 114GB を落とすのは、その結果を見てからでいい。
ローカルでの画像生成環境についてはAIでゲームアセットを量産した回で扱っている。手元の SDXL 出力を1枚、I2V に通してみるところから始めるのがいい。
