マイクロソフトが「Code Video Model」をオープンソース公開：コードで動画を生成

マイクロソフト研究所（Microsoft Research）は、新たな動画生成フレームワーク「Code Video Model（コード動画モデル）」を発表しました。

これは、AIによる動画生成の「ガチャ要素（不確実性）」を減らし、まずはコードを書くアプローチによって、画面のレイアウト、動作軌道、物理的な運動をあらかじめ明確に指定できるようにするものです。

現在の動画生成モデル（主流の動画拡散モデルなど）は、テキストから直接動画を生成する際、いわばブラックボックスのような状態に陥りがちです。

• 物理法則の多くを「推測」に頼っている：モデルは主に学習で得た視覚的パターンから動きを推測しているだけであり、重力や速度などの物理量を逐一計算しているわけではありません。そのため、オブジェクトの貫通や反重力のような不自然な動きが生じやすくなります。
• 制作プロセスの精密な制御が困難：カメラをどう動かすか、オブジェクトをどこに配置するか、どのような軌跡をたどるかといった配置を、プロンプトだけで生成前に正確に把握することは困難です。気に入らない点があった場合、わずかなディテールを変更するためだけに動画全体を最初から再生成しなければならないことも少なくありません。

Code Video Model の主要な機能と特徴

Code Video Model は、本格的な生成を行う前段階として、確認および編集が可能なコードによるプリビズ（事前可視化）の工程を追加しており、主に4つの機能をもたらします。

シーン配置やオブジェクトの移動軌道を直接編集できる。AIが記述したプログラムは、オブジェクトを指定された座標に配置し、時間経過に伴う移動経路を設定します。登場人物の進行ルートを変更したい場合や、シーン内の家具の配置間隔を調整したい場合は、対応する座標パラメータを直接編集し、まずはプレビュー上で効果を確認できます。

さらに、同一シーンをベースにした局所的な差し替えも可能です。論文では、アーチ門を開口部に変更する、人型ロボットを四足歩行ロボットに置き換える、左側のルートを右側のルートに変更するといった事例が示されています。プログラムと参照画像はいずれも元のデータをベースに対応する修正が加えられ、無関係な環境、カメラワーク、タイムラインの一貫性を保ちながら、指定された要素のみを変更することを目指します。ただし、最終的な完成映像には意図しない追加の変化が生じる可能性もあります。

左右にスワイプして全体を表示、または下部をクリックして高解像度の元画像を開きます。

カメラワークとシーン内のアクションを独立して設計できる。カメラのパン、ドリー、周回移動などはコードを通じて個別に制御でき、オブジェクト自体の動きとは切り離して設定できます。たとえば、被写体をあるポーズで静止させたまま、カメラだけをその周囲で回転させ続けるといった演出が可能です。

運動の参照元として物理方程式を導入できる。バネの振動や二重振り子の運動など、数学的に記述できるシーンにおいては、プログラムが対応する運動方程式に基づいて挙動を計算し、その後の生成に向けた物理的リファレンスを提供します。たとえば二重振り子は連結された2本の振り子アームからなり、互いの運動が複雑に影響し合います。プログラムは連成する運動方程式に基づいて時間変化に伴う角度と位置を計算し、その結果を簡易モデルの動きとしてレンダリングします。方程式が拘束するのはあくまでコードによるプレビュー段階であり、最終的な完成映像がこれらの運動に追従しているかどうかは別途確認が必要です。

プレビューを確認してから生成でき、大規模モデルの再学習も不要。まずはシンプルな3次元プレビューを確認し、動きやカメラワークを調整した上で、動画モデルに渡して質感や光と影を生成させます。論文では既存の MiniMax-H3 を採用しており、簡易モデルを入力するタイミングを切り替えることで生成を誘導するため、モデルの重み自体は変更せずに維持されます。

コア原理：映画の「プリビズ」を作るようにコードを書く

この技術は、従来の映画産業における事前可視化（プリビズ：Previs）のワークフローから着想を得ています。まずはシンプルな3Dシーンを用いてカメラ位置、役者の立ち位置、カットのテンポをシミュレーションし、配置を確定させてから本格的な撮影やポストプロダクションへと移行する手法です。

Code Video Model は、この産業的な制作プロセスをAI動画生成へと導入しました。

左右にスワイプして全体を表示、または下部をクリックして高解像度の元画像を開きます。

1. まずコードで骨組みを構築：高速プレビューと直接編集

テキストプロンプトを入力すると、コーディングAgent（論文内ではGPT-6を使用）がまず実行可能な Three.js プログラムを記述します。

Agentはコードの記述を終えると、キーフレームおよび動画全体をカバーするフレーム画像をレンダリングし、プロンプトと照らし合わせながら構図、遮蔽、運動、時系列を検証した上で、必要に応じてコードを修正し再レンダリングを行います。コードの生成と修正はAIに任せることもできますし、クリエイター自身がプログラム内のパラメータを微調整することも可能です。

このコードは「シーン構築およびカメラ監督」の役割を明確に担います。3次元空間内にジオメトリを配置し、物体の空間移動を設定し、仮想カメラの移動軌道を設計し、必要に応じて数学方程式を用いて力学的な挙動を計算します。

論文の報告によると、このプログラムのレンダリングは1分未満で完了し、低精度のプロキシ動画（Proxy Video）、すなわち簡易モデルによるプレビューが得られます。続いてシステムはプロキシ動画から代表フレームを抽出し、画像生成モデル（GPT-Image-2など）を呼び出して、目的の光と影、質感、リアルな撮影スタイルを備えた参照画像（Reference Image）として再描画します。あるいは、ユーザーがあらかじめ用意したスタイルの参照画像を直接アップロードすることも可能です。

このアプローチがもたらすメリットは極めて明確です。高速であり、かつ「見たままが得られる（WYSIWYG）」点にあります。テーブルの配置位置や車の走行速度に納得がいかない場合、コード内の対応する座標や速度パラメータを調整するだけで、簡易モデルを再レンダリングしてすぐに確認できます。単純なパラメータの変更であれば、わずか1行のコード修正で済む場合もあります。なお、ここでの「1分未満」とは簡易モデルのレンダリング時間のみを指し、AIによるコード生成、参照画像の作成、最終動画の生成にかかる時間は含まれません。

付属のブラウザビューアは、タイムラインのシーク、コマ送り表示、ソースコードの閲覧に対応しています。クリエイターは3次元視点を自由に周回、平行移動、ズームすることができ、グリッド、カメラの軌道、視錐台（カメラが撮影可能な空間範囲）を表示させて、オブジェクト同士の位置関係や、カメラがどこを通過し何を捉えるかを検証できます。

2. 「プラスチック感」の課題を克服：サンプリング初期の条件付け

簡易なコード動画ができたあと、それをどのようにリアルな最終映像へと仕上げるのでしょうか。

ここには重要な課題があります。もしコード動画を条件付けリファレンスとして動画拡散モデルの全工程にそのまま入力し続けると、AIはその簡素なジオメトリや平坦なマテリアルまでも模倣してしまい、最終映像に「プラスチック感」が残りやすくなります。

この課題を解決するため、研究チームは再学習を必要としないスケジューリング機構である「サンプリング初期の条件付け（Early-step Conditioning）」を提案しました。

チームの実験観察によると、生成の各フェーズにおいて簡易モデルが与える影響は異なります。

• サンプリング初期段階：簡易モデルは主に画面のレイアウト、カメラワークの変化、主体の動きを確立するのに役立つ。
• サンプリング後期段階：簡易モデルを参照し続けると、その簡素な外観が材質やテクスチャの細部にまで入り込みやすくなる。

この特性に基づき、研究チームは各段階の役割と入力タイミングを設計しました。標準的な20ステップのデノイズイテレーションを例にとると、システムは最初の5ステップ（全体の25%）のみ低精度のプロキシ動画を条件としてモデルに入力し、画面の空間構図とアクションの骨格を素早く定着させます。そして第6ステップ以降はプロキシ動画の入力を取り下げ、参照画像とテキストプロンプトのみに基づいて質感、光と影、細部の生成を進めます。参照画像とテキストは生成プロセス全体を通じて常に保持されます。

また、動画モデルは簡易モデルでは省略されていた形状や関節の細かな動きを補完します。そのため、前段階のプログラムではすべての3Dアセットを精緻に作り込む必要はなく、主要な構造と動きを過不足なく提示するだけで十分です。

なお、ここでの「最初の5ステップ」とは、モデルが動画全体を生成する際の「最初の5回の計算ラウンド」を指しており、各ラウンドごとに動画全体が更新される計算ステップのことです。動画タイムライン上の「最初の5秒」を意味するわけではありません。

最初の5ステップというのは著者らの実験におけるデフォルト構成であり、実際には調整が可能です。実験では、簡易モデルを適用する時間を長くすると、通常は最終映像が元の構造により忠実になるものの、簡易モデルの平坦な外観が持ち込まれやすくなります。逆に短くすると、構造的な拘束力が弱まります。これは制御の強さと画面の質感との間のトレードオフを調整することを意味します。

具体的にどのような用途に使えるのか？

このような分業体制は、アクション、移動ルート、カメラアングルなどを試行錯誤しながら繰り返し修正する必要がある制作作業に特に適しています。以下の3組の比較は、プロジェクトの公式デモから引用したものです。

1. バレットタイム：アクションは静止、カメラは回り続ける

映画でおなじみの「バレットタイム」撮影では、2つの要素を同時に満たす必要があります。被写体のアクションが瞬間的に静止し、その周囲をカメラが滑らかに周回・前進し続けることです。テキストによる指示だけで「どのアクションの瞬間に静止させ、カメラをその後どこまで回転させるか」を正確に指定するのは極めて困難です。

コードを用いれば、物理時間とカメラ時間を2つの独立した変数に分解して個別に計算できます。

プログラムはまずバイクとライダーを特定のフレームでワールド座標系内に静止させ、同時に仮想カメラがライダーの周囲を回り続けるよう制御します。動画拡散モデルはこの簡易モデルを受け取ったあと、その動作とカメラワークをガイドとしながら、路面の豊かな反射、車体のマテリアル、背景のディテールを生成します。

2. ロボットのルート変更：まず経路を修正し、結果を確認

ロボットの動作シミュレーションでは、具体的な環境に合わせて移動ルートを試行錯誤しながら調整することが求められます。プロンプトだけを書き換えて再生成した場合、移動経路以外のシーン全体の細部まで勝手に変わってしまう恐れがあります。

コードという中間層が存在することで、変更する箇所が明確になります。ロボットの折り返しルートを変更したい場合、クリエイターはプログラムを開き、ウェイポイントリスト（route=[v(-0.75, 6.75), ...]）内のいくつかの座標数値を書き換えるだけで、1分足らずで新しいプレビュー動画をレンダリングできます。経路に問題がないことを確認した上で、動画モデルに渡して最終映像を生成します。

以下の事例では、コードによるプレビューで人型ロボットが研究室のドアへ向かう動きを設計し、完成映像ではそれをベースに室内のライティング、金属の反射、メカニカルな関節のディテールが補完されています。

3. 屋内建築のカメラワークとプロダクト撮影

空間構造が複雑な屋内ウォークスルーの撮影では、家具のレイアウトを整えるだけでなく、その間をカメラがスムーズに通り抜けるよう設計する必要があります。

Three.js プログラムを用いれば、ソファ、階段、窓の位置を明確に定義し、カメラが通過する軌跡を設定できます。事前に簡易モデルを確認することで、カメラがソファに近づいているか、視点を持ち上げているか、あるいは階段に向きを変えているかを検証した上で、最終的な画面の質感やライティングを決定できます。

これはプロダクト撮影においても同様です。たとえばスポーツカーを撮影する場合、コードによって車体の外観からホイールのアップへと移行するカメラワークをあらかじめ設定できます。簡易モデルによって視線の軌跡とパースペクティブの変化を確定させたあと、動画モデルが金属ボディの流れるような映り込みやホイールの機械的テクスチャを描き込みます。

評価データ：構造と質感のより優れたバランス

生成クオリティを体系的に測定するため、研究チームは22のテストケースからなる評価ベンチマーク「CodeVideoBench」を構築しました。シーン編集、ロボットシミュレーション、軌跡変更、ゲーム、プロダクト撮影、建築カメラワーク、物理法則、バレットタイムの8大応用カテゴリを網羅しています。

評価は主に3つのコア指標に基づいて実施されました。

• 構造スコア（Structure）：画面内の空間配置、主体の動作、カメラワークがコードによる簡易モデルにどれだけ忠実であるか。
• スタイルスコア（Style）：材質、光と影、撮影の質感が参照画像に十分に合致しているか、あるいは簡易モデルのプラスチック感が残っていないか。
• 画質スコア（Quality）：映像の連続性と動きの自然さ、ちらつき（フリッカー）、テアリング、アーティファクトの有無。

同じく MiniMax-H3 をベースとし、全ステップで簡易モデルを入力し続ける R2V と比較して、Code Video Model は著者らの実験においてより高い総合スコアを記録しました。Qwen-27B による自動評価を例にとると、両者はそれぞれ 85.17点 と 75.22点 でした。

しかし、トレードオフをより明確に示しているのは人間によるブラインドテストの結果です。Code Video Model の構造スコアは 6.92点 であり、全ステップ R2V の 7.81点 を下回った一方、スタイルスコアは 8.46点 に達し、R2V の 6.02点 を上回りました。総合スコアは 8.17点 で、R2V は 7.64点 でした。

すなわち、簡易モデルの入力を早期に打ち切ることで、完成映像は参照画像の外観により近づく一方で、元の構造に対する追従性は一部損なわれることになります。本手法の強みは「制御性と質感のバランス」にあり、すべての動作がより精密になったと一概に言えるわけではありません。

なお、これらのスコアは著者らが独自に作成した22件のテストケースに基づくものであり、人間によるブラインドテストの参加人数や統計的有意性は開示されていません。したがって、この結論は本実験の設定範囲内において適用されるものです。

適用限界と現在の利用方法

コードによるプレビューではパラメータを厳密に設定できますが、最終的な映像を生成するのは依然として動画モデルであるため、レイアウト、姿勢、運動のいずれも指定から乖離する可能性があります。厳密な物理的精度やフレーム単位での正確な位置合わせが求められるタスクに適用する場合は、完成した映像を個別に検証する必要があります。

また、参照画像と簡易モデルの整合性も重要です。論文では、人型ロボットの簡易モデルに対して犬の参照画像を与えた結果、元の主体を維持したまま、画面内に別途犬が追加生成されてしまう事例が報告されています。また、屋内の参照画像を全体的に青色へと変更した場合でも、完成映像はおおむね元の温かみのある自然光へと戻ってしまい、一部にしか青色が反映されないケースもありました。コードと参照画像はそれぞれクリエイターの意図を表現しますが、モデルが常にそれらを指示通りに合成できるとは限りません。

開発者が現在試すには

現在公開されている入口は GitHub リポジトリ であり、コード、プリセットサンプル、評価ベンチマークが含まれています。

開発者はまず sports_car、tank_boarding、loft_tour などのサンプルから始めることができます。これらのサンプルにはプロンプト、プロキシ動画、参照画像がすでに用意されているため、コードの記述や簡易モデルのレンダリングをスキップして、後半の動画生成パイプラインを先行して実行可能です。

ローカル環境での実行には、MiniMax-H3 モデルと NVIDIA GPU 環境が必要です。リポジトリでは Ubuntu 22.04 および CUDA 12.6 互換ドライバの使用が推奨されています。プロンプトの入力から全パイプラインを一貫して実行する場合は、GitHub Copilot CLI によるコード生成や画像モデルのAPI呼び出しも必要となります。なお、リポジトリには必要最小限のVRAM容量や全工程の実測処理時間は記載されていないため、現時点では「誰でもワンクリックですぐに使える動画作成ツール」と見なすことはできません。

レポートでは、コードによる簡易モデルを用いて Seedance 2.5 を誘導する事例も示されており、このプレビュー構想が他の動画モデルにも応用可能であることが示唆されています。ただし、それらの事例はプロプライエタリな商用APIを通じて同様の「最初の5ステップ」スケジューリング制御を実行できることを証明したものではありません。

Code Video Model が注目に値する理由は、クリエイターが最終的な生成を行う前に、視覚的に確認でき、直接手を入れて修正でき、何度でも再実行できるカメラワークと演出の設計図を手に入れられる点にあります。まずコードを用いて「物体がどう動き、カメラがどう撮るか」を確定させ、その上で動画モデルに目標とする質感を実現させるというアプローチは、動画制作の試行錯誤においてより具体的な手掛かりを提供してくれます。