前回、キーボードのおまけでDaVinci Resolve Studioのライセンスを手に入れました。目的はひとつ、ClaudeにResolveを操作させることです。今回はその本題です。
動画生成AIには、構造的な制約があります。1回の生成で出せる長さが短いことです。MiniMax H3は最長15秒、他のモデルも5〜30秒程度で、これは学習のしかたに由来します。モデルは一定の長さの映像を丸ごと1本のシーケンスとして扱うように学習されていて、長くすると計算量がフレーム数の二乗で増え、後半ほど人物や場面が崩れやすくなる。前々回の記事で15秒に11分かかっていたのはそのためです。H3は1クリップの中に複数カットを入れることもできますが、「じゃあ1分頼めばいい」とはならず、短い尺を作って編集でつなぐのが前提の道具なのです。
そして、つなぐだけでは済みません。タイトルを載せる、BGMを混ぜる、カットごとにバラバラな音量を揃える、1カットだけ撮り直して差し替える。こういう仕上げは、生成モデルの外側、つまり編集ソフトの仕事です。
そこで今回は、Claudeに ComfyUI(MiniMax H3)とDaVinci Resolve Studioの両方を操作させました。私がやったのは題材と演出の指示、そして完成品の目視です。170万円の自宅AI環境の主砲、GALLERIA(RTX 5090)の上で、ComfyUIとResolveが同居して働きました。
まず完成品をどうぞ
「雨の夜のコーヒースタンド」。バリスタの参照画像1枚と、屋台の参照画像1枚から、8カット・57秒の短編です。タイトル、カット間のディゾルブ、BGM、音量の統一は全部Resolve側で、Claudeがスクリプトで組みました。

比較のために、H3が出した「生の1カット」も置いておきます。これがResolveに入る前の素材です。
分担: 人間が決めて、Claudeが2つのアプリを動かす
構成はこうです。ClaudeはComfyUIのAPI(localhost:8188)にプロンプトを投げてカットを生成し、DaVinci ResolveにはMCP経由でPythonスクリプトを流し込みます。Resolve側のMCPサーバは「Resolveの状態確認」「スクリプト実行」「APIリファレンス検索」など14個のツールを持っていて、Claudeは分からないAPIをその場で調べながら書きます。
| 工程 | 誰が | 何をしたか |
|---|---|---|
| 題材・演出の決定 | 私 | 「雨の夜のコーヒースタンドのバリスタ」、03_quality(14 step)の高速化スタック、タイトル・ディゾルブ・音声クロスフェード・BGM・ラウドネス正規化を指定 |
| 絵コンテとプロンプト | Claude | 8カット(7〜10秒)の英語プロンプト。セリフは日本語で指定 |
| 生成の投入と監視 | Claude | ComfyUI APIに順番に投入し、完了ログを監視。BGMはMiniMax Music 3で生成 |
| Resolveの組み立て | Claude | プロジェクト作成→素材取込→タイムライン→トランジション→タイトル→BGM→正規化→書き出しをスクリプトで |
| 目視チェック | 私 | 完成版を見て、おかしいカットを3つ指摘 |
| 撮り直し | Claude | 指摘に合わせてプロンプトを締めて再生成、再組み立て |
生成の時間はこうでした。採用した8カットで合計812秒(13.5分)。没になった5テイクが710秒。BGMが2回で165秒。そしてResolveの1080p書き出しは3.2秒です。RTX 5090だと、編集ソフトのレンダーは一瞬で終わります。
| カット | 尺 | 内容 | 生成時間 |
|---|---|---|---|
| 01 | 10.1秒 | 引きの店構え、雨、カウンターを拭く(タイトル重ね) | 122秒 |
| 02 | 7.3秒 | 手元のクローズアップ、ミルで豆を挽く | 86秒 |
| 03 | 7.3秒 | 客が小銭を置く「いらっしゃいませ。今日も雨ですね。」 | 95秒 |
| 04 | 10.1秒 | ハンドドリップ、黒猫がカウンターに乗る | 130秒 |
| 05 | 7.3秒 | カップを渡す「熱いので、気をつけて。」 | 87秒 |
| 06 | 7.3秒 | 風で揺れる提灯を押さえて空を見上げる | 86秒 |
| 07 | 10.1秒 | 雨が止んだ夜道で手のひらを空に「あ、やんだ。」 | 126秒 |
| 08 | 7.3秒 | 提灯を消し、猫を抱いてカメラを見る | 80秒 |
H3のフレーム数は「17の倍数+5」に丸められるので、7秒と頼むと175フレーム(7.3秒)、9.5秒と頼むと243フレーム(10.1秒)になります。
H3にはできないことを、Resolveで足した
ここが今回の本題です。生成モデル単体では作れない、あるいは作りにくいものを、Claudeが編集ソフト側で足しました。

| やりたいこと | H3単体では | Resolveでの実装 |
|---|---|---|
| タイトル | 文字が崩れる | Fusionの「Text+」で日本語+英語。フェードイン/アウト1秒 |
| カット間のつなぎ | 1クリップ内のカット割りはできるが、別々に生成したクリップ同士はつなげない | 各カットの両端に16フレームの「のりしろ」を残して並べ、Cross Dissolve(映像)+ Cross Fade +3dB(音声)を7か所 |
| BGM | 「No music」と書かないと勝手に鳴る上、カットごとに別の曲になる | MiniMax Music 3で52秒のローファイ・ジャズを別途生成し、A2トラックに配置。終わりを本編の終わりに揃え、フェードイン2秒・フェードアウト4秒 |
| 音量の統一 | カットごとにバラバラ(-38.5〜-11.4 LUFS) | セリフありは-18 LUFS、環境音のみは-27 LUFS、BGMは-26 LUFSに個別正規化。書き出しを実測して全体を-23 LUFS(EBU R128)に |
| 冒頭と末尾のフェード | できない | 映像・音声とも1秒のフェードイン、1.5秒のフェードアウト |
| アップスケール | 960×544が限界(5090でも1152×640でVRAMが溢れる) | クリップ属性のSuper Scale 2xで1920×1080に |
音量の話を少し補足します。H3のカットは、環境音だけのカット(-38.5 LUFS)とセリフのあるカット(-11.4 LUFS)で27dBも差がありました。そのままつなぐと、静かなカットの後で急にセリフが飛び出してきます。セリフのカットと環境音のカットで別々の目標値に揃えるのが、今回いちばん効いた「編集ソフトらしい」仕事でした。
Resolveのスクリプティング APIでつまずいた5か所
Claudeは最初からきれいに組めたわけではなく、APIの挙動を1つずつ試して回避策を見つけていきました。同じことをやる人のために残しておきます(Resolve 21.1で実測)。
- トランジションには「のりしろ」が要る:
AddTransitionは、クリップの外側に素材の余りがないと失敗します。しかもトランジションの尺は「のりしろのフレーム数と指定値の小さい方」。両端に16フレーム残して並べると、16フレームのディゾルブになります - タイトルは必ずV1に割り込む:
InsertFusionTitleIntoTimelineは、再生ヘッド位置のV1にインサート編集され、既存のクリップを押しのけます。回避策は、タイトルだけの別タイムラインを作り、それを本編のV2にネストすること。透過も保たれます - スクリプトに日本語を書けない: MCP経由の
run_scriptは非ASCII文字でエラーになります。タイトルの日本語は\u96e8\u306e\u591c(=「雨の夜」)のようにUnicodeエスケープして渡しました - グループのラウドネス正規化が効かない: クリップ単位の正規化は動きますが、全体を目標値に合わせる「相対」モードはレベルが変わりませんでした。書き出したファイルをPythonで実測(BS.1770-4を自前実装)し、全クリップを一律にオフセットする方式に切り替えました
- バスのリミッターはAPIから触れない: -23 LUFSのマスターは問題ありませんが、YouTube向けの-16 LUFSに上げるとピークが天井を超えます。Resolve内でリミッターを足す手段がAPIになく、-16 LUFS版だけはResolveの外でPythonのリミッターを掛けました
H3の破綻と、撮り直しで効いたプロンプト
完成版を見た私は、3つ指摘しました。「カップを渡したのにバリスタの手にもカップが残っている」「提灯を押さえる手が3本に見える」「屋台から歩いて行った先に、もう1台屋台がある」。Claudeが確認していた「中央の1コマ」では見えない破綻です。

撮り直しは、シードを変えるだけでは同じ失敗を繰り返します。効いたのは、プロンプトで状態を明示することでした。
| 破綻 | 効いた書き方 |
|---|---|
| 渡したカップが分裂 | 「カップは画面内に1つだけ」「渡した後は両手が空で、残りの時間はカウンターに置いたまま」と、動作の後の状態を書く |
| 手が増える | 「左手はカウンターに置いたまま、右手だけで」「ゆっくり、手は2本」と、使わない方の手を固定する |
| 屋台が2台 | カメラを屋台の方に向けて固定し、「2歩で止まる」「通りに他の屋台はない」と歩く距離を制限する |
| 「止んできた」のに降り続ける雨 | H3は1ショットの中で天候を変えられない。「雨は撮影前にもう止んでいる。画面内に降る雨はゼロ。ひさしから雫が落ちるだけ」と、変化後の状態だけを書く。セリフも「あ、やんだ。」に |


雨の件は2段階でした。1回目の撮り直し(屋台を1台にする)では、「あ、やんできた。」と言いながら手のひらに雨粒が落ち続けていました。2回目で「もう止んでいる」と書き直して通っています。


4回の撮り直しはすべて1回で通りました。共通しているのは、「〜する」という動作ではなく「〜の状態である」と書くことです。H3は動作の途中経過を描くのが苦手で、始点と終点の状態を明示した方が安定します。
全カットをClaudeに目視させると、いくらかかるか
ここで正直な話を。今回の破綻3つは私が見つけました。Claudeが各カットの中央1コマしか見ていなかったからです。「全部見ればいいじゃないか」となりますが、画像1枚は約1,500〜1,900トークンです。
| 見る対象 | トークン |
|---|---|
| フル解像度の1コマ | 約1,500〜1,900 |
| 6コマのコンタクトシート1枚 | 約1,800 |
| 7秒のカットの全フレーム(175枚) | 約30万 |
全フレームは論外ですが、6コマのコンタクトシート2枚(12コマ)を1カットにつき見せるなら、8カットで約3万トークン。撮り直し込みでも10万トークン前後で、生成そのものの時間に比べれば安いものです。実際、撮り直しの確認はこのシート方式に切り替え、4本とも1回で判定できました。
ローカルのVLMに一次判定をさせる案もありますが、32GBのVRAMをH3が占有している私の環境では、ComfyUIを落とさないと動かせません。カット生成中に別のGPU処理を走らせると、VRAMが溢れて生成が3倍遅くなるのも実測済みです(Resolveの操作を同時にやったカット06が274秒かかりました)。
正直、気になっていること
- H3の空間把握: 猫が屋台の内側から出てくる、客の手が妙な角度で入る、といった違和感は残っています。直すには際限がないので、今回は「H3の能力」として受け入れました
- BGMの尺: Music 3に75秒を頼んだら45秒、120秒を頼んだら52秒しか出ませんでした。本編は57.5秒なので、曲の終わりを本編の終わりに揃えて、冒頭5秒は環境音だけで始める構成に逃げています
- -16 LUFS版だけResolveの外: バスのリミッターがAPIから触れない件。Resolveの中で完結させたかった
- セリフの発音: 前回の記事同様、H3の日本語には癖があります。今回は聞き取れる範囲でしたが、字幕を載せた方が親切です

まとめ
- 生成モデルは学習のしかた上、短い尺しか出せない(H3は15秒)。つなぐ・載せる・混ぜる・揃える・差し替えるは編集ソフトの仕事で、Claudeはその両方を操作できる
- Resolve側で足したのは、タイトル、ディゾルブと音声クロスフェード、BGM、カット別のラウドネス正規化、フェード、2倍アップスケール。RTX 5090なら1080pの書き出しは3秒
- ResolveのAPIには癖がある(トランジションにのりしろ、タイトルはネスト、日本語はエスケープ、グループ正規化は実測して手動)
- H3の破綻は「動作」ではなく「状態」で書くと直る。確認は中央1コマではなく6コマのシートで
- 目視のコストは、シート方式なら8カットで約3万トークン。生成時間に比べれば安い
Studioのライセンスを「おまけ」で手に入れた甲斐はありました。編集ソフトは、AI動画の「仕上げ」の場所になります。
次は、Resolveの文字起こしとAIナレーションで、H3のセリフに字幕を付けるところまでやってみたいと思っています。続報をお楽しみに。

コメント