動画生成AIの使い分け — アニメはVidu、リアルはKling

先に結論を書きます。

アニメはVidu、リアルはKling。

1話約1分のAIアニメを29話ぶん作り、並行して実案件の映像制作でも生成AIを使ってきた結果、この2つに落ち着きました。以下、それぞれの使いどころを書きます。

Vidu — アニメーションの精度が高い

Viduには Flash と Cinematic の2つのモードがあります。この使い分けが分かると一気に楽になります。

Flash：速くて安い。簡単な動作に強い

とにかく生成が速く、コストが安い。 そしてアニメーションの精度がとにかく高い。

得意なのは簡単な動きです。

• ちょっとしたセリフを喋る
• 立ち上がる、歩く

こういう「日常の芝居」を大量に作るなら、Flashで十分です。というより、Flashが最も向いています。

Cinematic：絵柄そのものを変えたいとき

Cinematicは少し複雑なものが得意です。ただ「複雑」といっても、動きが激しいという意味ではありません。

私がCinematicを使うのは、ファーストフレームとエンドフレームで絵柄を全く変えたいときです。

• 等身大のキャラクターから、SDキャラクターに変える
• リアルな背景から、抽象的な背景に変える

つまり演出をガラッと切り替える瞬間です。こういう指定をすると、Cinematicはシームレスにシーンを入れ替えてくれたり、トランジションになるアクションを入れて形にしてくれたりします。

After Effectsで作るような演出を、生成側で成立させてくれる感覚です。

実際の生成回数とコスト

尺を先に決めて渡すようにしてから、2〜3回の生成で完成カットが出るようになりました。

体感値ですが、2分程度の動画で1,000〜2,000円かからないくらいで書き出しまで到達しています。

（この「尺を先に決める」という設計については別記事に詳しく書きました）

Kling — リアルな描写と、ちょっとした芝居

Klingはリアルな描写とちょっとした芝居に強い、というのが実感です。

日本ではViduが最近出てきた印象がありますが、2年ほど前、日本で最初に触りやすかった動画モデルはKlingでした。私たちも、そこから入っています。

当時どう使っていたか

東京タワーのアミューズメント施設の映像制作で使いました。LED背景が四面ある空間で、その背景映像を作る仕事です。

手順はこうでした。

1. 商品画像から、新しいイメージを生成する
2. そのイメージをKlingで動かす

当時としては、これで十分成立しました。

ただし、当時は人物が苦手だった

正直に書くと、人物は「全くと言っていいほど」苦手でした。

武者が刀で暖簾を切る、という動きを作ったことがあります。結果は:

• 途中で日本刀が西洋の剣に変わる
• 刀を振る手の動きがおかしい

これが2年前の水準です。

逆に、得意だったもの

同じ施設のVJイベントでは、うまくいきました。

怪しげな世界観のイベントだったので、虫が動く、壺から虫が出てくるといったモーションを作りました。これはすごく面白くできました。

ここから言えるのは、当時のAI動画は「実在感」が苦手で、「非現実的なモーション」が得意だったということです。用途を選べば、当時から実務で使えたわけです。

いまのKling

その後かなり良くなりました。いまはリアルな普通の芝居のシーケンスで使われることが増えている印象です。だから「リアルはKling」です。

Seedance — Higgsfield経由でないと荒れる

Seedanceもよく使っています。現在進行中の、ある映画監督のAI作品でも使っています。

そして重要なことがひとつ。

私はSeedanceを、Higgsfield経由で使っています。

SeedanceのAPIを直接叩いたこともあるのですが、人物の表現がかなり荒れます。 Higgsfieldを通すと安定する。同じモデルのはずなのに、です。

良い面は明確で、アニメだろうが実写だろうが、わりと何でもござれ。そしてアクション・動きに強い。

一方で、アクションについては言いたいことがあります（これは別記事に書きました）。要約すると、寄りのカットを積み上げて「ごまかす」やり方を、モデルが理解している。それは能力でもあり、限界でもあります。

Hailuo — 使っていません

正直に書きます。Hailuoはほとんど使っていません。

一度だけ書き出したことがありますが、思ったような感じが出ませんでした。それ以来、選択肢に入っていません。

比較記事で「使っていないものを並べる」のは意味がないので、これ以上は書きません。

Higgsfield — 品質ではなく「ラッパー」として

Higgsfieldは、生成品質そのもので選ぶサービスではありません。さまざまなAPIをラッピングしたプラットフォームとして便利、というのが本質です。

• Geminiで作った画像を、Seedanceで動かせる
• 「Seedanceを使うのはもったいない」と思う場面では、Klingに切り替えられる

このモデル間の行き来が、制作では効きます。

ただしSeedanceの件のように、経由すると品質が変わることもある。これは推測ですが、Higgsfieldがモデル提供側と話をつけていて、許可された環境を作っているからではないかと考えています。単なるAPI中継ではないのだろう、と。

注意点

各モデルの特性を分かっていない状態でラッパーを触ると、コストが上がるだけです。

「便利そうだから」で入ると、片っ端から試して課金だけが積み上がります。先にモデルの得手不得手を知っておくことが前提条件です。

ローカル（WAN 2.2）を使うのは、この3つのとき

クラウドがこれだけ使えるのに、なぜローカルを維持するのか。理由は3つあります。

① コストを抑えたいとき

② 権利的に、よそに出せないものを扱うとき

LLMやクラウドに情報を渡せない案件があります。ローカルでやらざるを得ない事情があるとき。商業案件では意外と頻繁に効いてきます。

③ リファレンスとなるキーフレームが、すでに存在するとき

たとえば「キャラクターシートを使ってGPTで画像を生成した。これを動かしたい」という場面。絵はもう決まっていて、簡単な動きを付けるだけなら、WANで十分です。そのぶんコストが抑えられます。

なお、参照画像（キャラクターシートなど）から生成する用途では、WANよりFluxの方がうまくいった印象があります。ローカル＝WAN、と決めつけない方がいいと思います。

バッチ処理の落とし穴

ComfyUIが使える状態ならCLIで一括処理ができます。これは利点です。

ただし、バッチで回すと良いものと悪いものが混在します。

• 向く: YouTubeやSNS向けに大量に吐き出したいとき
• 向かない: 何か狙いがあるもの

「AIで量産する」と「狙いのある1本を作る」は、別の作業です。 ここを混ぜると、大量の使えない素材を前に途方に暮れることになります。

まとめ

「一番きれいなモデル」ではなく「この用途にいちばん割の合うモデル」を選ぶ。 物差しは時間のコストとお金のコストの2つだけです。