映画を一本思い浮かべてほしい。主人公がリビングにいて、ランドリールームへ行き、しばらく後にまたリビングへ戻ってくる。戻ってきたリビングは、さっきと同じリビングでなければならない。ソファの位置も、窓の向きも、テーブルの上に置かれた物もそのままであるべきだ。人間の監督にとっては当たり前のこの作業が、脚本を受け取ってシーンを一片ずつ作り出すAIには意外と難しい。
ATAS(Any Time, Any Space)は、この問題を新しい映像モデルを作って解くのではなく、既存の映像生成器に二種類の「記憶」を付け足して解く。一つは部屋の空間構造を収めるシーン記憶、もう一つはそこで起きた出来事を収めるイベント記憶だ。そして生成器が新たに作ったシーンをそのまま信じるのではなく、検証を通ったものだけをこの記憶に取り込む。著者らは、映像生成器4種において、ショット(長尺映像を分けた一片)間の一貫性指標がいずれも改善し、各生成器で最も高い総合スコアを得たと報告している。
人間には簡単なことが、なぜAIには難しいのか。これまでのシステムは、ショット間の連続性を主に三つの方法で保ってきた。直前の数フレームを渡すか、テキスト要約を伝えるか、参照画像を検索して付けるやり方だ。すぐ後に続くショット同士なら、これで十分だ。
問題は「非連続」の要求だ。途中に別のシーンがいくつも挟まった後にさっきの部屋へ戻ったり、さっきの出来事をもう一度持ち出してほしいという要求には、これらの手がかりは無力だ。直前のフレームはついさっきのランドリールームを収めているだけで、三ショット前のリビングの配置を同じ基準座標の上に保持しているわけではないからだ。論文はこれを「持続する世界状態(world state、ショットが変わっても保たれるシーン・出来事の共通記録)」がないために生じる問題と見る。この状態を保つには二つが必要だ。第一に、過去の観測を空間と時間の両方から再び取り出せるように保存しなければならない。第二に、生成物の誤りを無闇に受け入れてはいけない。生成されたシーンの視覚的・幾何学的な誤りがそのまま状態に入り込むと、一度ずれた部屋がその後のすべての復帰ショットを汚染する。
この問題をめぐって三つの系統の試みがあった。第一に、長尺映像生成そのものを伸ばす側は、一度により長い文脈を見たりカメラ・モーションを制約したりするが、複数クリップの観測をどう保存して再び取り出すかは定めていない。第二に、エージェント型映像システム(脚本を受け取って複数回にわたり自ら次のショットを決めて作るAI)は脚本分析・ショット計画・審査を付け足すが、ショット間に残すものがたいていプロンプトや参照画像のような「編集用の文脈」であり、共有座標系やイベント-時刻の索引がない。第三に、明示的記憶の側は点群や3D表現で空間を記憶するが、生成した観測を「未来の状態として受け入れるかどうか」を判定する段階がない。ATASの差別点は二つだ。空間記憶とイベント記憶を分けること、そして観測を記憶に入れる前に検証することだ。
ATASの設計を一文に縮めると、映像制作を「見える成果物」と「記憶に残す証拠」に分離したことだ。記憶は二種類に分かれる。
シーン記憶(scene memory)は、部屋の空間構造を共有座標系(すべての観測を同じ基準軸の上に合わせておくこと)に保存する。リビングを最初に撮ったシーンが入ってくると、それがその部屋の座標基準になり、以降受け入れられたシーンはこの基準に合わせて整列され、静的点群(空間を無数の点の座標で表したもの)として統合される。このとき動く領域は除き、固定された構造だけを残す。後でそのリビングへ戻る要求が来たら、保存された座標を要求された位置とカメラアングルから改めて描画し、参照画像として生成器に渡す。家の骨格を3Dで記憶しておき、どの方向からでも再び取り出して描いてくれる設計図の保管庫に近い。
イベント記憶(event memory)は、動くシーンを別に置く。「どのシーンの、どんな出来事が、いつ」なのかで索引を付け、その出来事をシーン座標系に登録したフレームごとの証拠(RGB-D・マスク・動的点群)と、出所・時刻といったメタデータとして保管する。後から「さっきのあの出来事を、あの時間区間で」もう一度取り出してほしいという要求が来たら索引ですぐに探し出し、合致する記録がなければ空の結果を返す。ここで重要なのは、この記憶が「誰がどう動いた」といった整理された結論ではなく、そのときの観測をシーン座標系上のフレームごとの証拠として保存している点だ。元映像を丸ごと保管するのとは違う。
全体の流れはこうだ。脚本を受け取ると「ワールド状態コンパイラ」が、長い脚本を生成器が一度に作れる映像の長さに合わせて小さなショット要求に分割する(複雑な脚本をさらに小さな単位へと分け続けるやり方だ)。各要求には、何を撮るか、どのシーンか、その部屋のどのあたりでどんなカメラから見るか、どの時間区間か、そして出来事であればどんな出来事かが含まれる。この要求で二つの記憶を参照して文脈を作り、その文脈を条件として生成器が短いクリップを作る。
生成されたクリップはすぐには記憶に入らない。まず「候補の観測」となり、二つの判定を別々に受ける。一つは映像審査 — このクリップを最終映像に使えるか。もう一つは登録 — 再構成した結果がシーン座標系にきちんと合致するか。状態の更新は、この二つを通過し、さらに出所・シーン範囲・以前の状態バージョンまで合致したときにのみ行われる。「最終映像に使えるか」と「記憶に入れるほど信頼できるか」は別の問いだ。映像としては問題ないが座標整列に失敗したクリップは、最終映像には残るが、後のショットの条件としては使われない。ずれた観測が世界状態へ流れ込んで次のショットを汚染する道を、この分離が断ち切る。
評価は標準ベンチマーク、持続性タスク、統制分析で構成される。読者の立場からは、三つの問いにまとめて見るのが早い。同じ部屋に戻れるか、同じ出来事を再現できるか、コストはどれくらいかかるか。比較対象は生成器4種(MiniMax-H3・Wan 2.7・HappyHorse 1.0・Wan 3.0)とエージェント5種(I2V Extension・VGoT・Mora・MovieAgent・ReCA)で、各生成器ブロック内で同一条件でのみ比較する。
標準ベンチマーク(VBench・ST-Bench・ViStoryなどの公開評価ツール)で測ると、ATASはMiniMax-H3・Wan 3.0・HappyHorse 1.0において報告されたすべての総合スコアで首位に立った。例えばWan 3.0では総合平均0.734で、2位のReCA(0.648)を上回る。Wan 2.7ではVBenchの一項目でReCA(0.854)にわずかに及ばなかったが(ATAS 0.846)、総合平均(0.656対0.612)は最も高かった。オープンソースでも商用でも同じパターンが出た。著者らは、この利得が特定の生成器が優れているからではなく、ショットを横断する持続状態から来ていると見る。
方法はこうだ。生成した復帰シーンを実際のターゲット画像と、両画面に共通して見える領域だけを切り出して比較する。指標はPSNR_C・SSIM_C(高いほど良い画質類似度)とLPIPS_C(低いほど良い知覚距離)だ。比較対象にはエージェント方式だけでなく、3Dでシーンを描き直す手法(FlexWorld・ViewCrafter)も含まれる。結果はATASがPSNR_C 15.968、SSIM_C 0.385、LPIPS_C 0.284で比較対象を上回った。
映像と文章を一緒に理解するAI(ビジョン言語モデル)に、元の出来事フレーム、出来事の説明・区間、要求カメラ、生成クリップを与え、五つの軸で採点させる。同じ映像をそっくり複製したかではなく、「その出来事がそのカメラから蘇るか」を見る。そのため、同期したターゲット映像は使わない。
| 軸 | ATAS | 備考 |
|---|---|---|
| 出来事の同一性 | 0.750 | 首位 |
| 時間順序 | 0.688 | 首位 |
| 視点の実装 | 0.650 | 首位 |
| キャラクター/物体の一貫性 | 0.917 | ReCAと同率 |
| 動作/状態の保存 | 0.688 | ReCA 0.700にわずかに劣勢 |
この表の最後の行が核心を分ける。残された難しさは、その出来事を「見つけてくる」ことにあるのではなく、動作と状態を「そっくり再現する」ことにある。この二つは別の仕事だ。一つは正しい過去の証拠を探して生成器に渡す仕事であり、もう一つは生成器がその証拠どおりに動きを実際に描き出す仕事だ。ATASが担うのは前者だ。後者は生成器自身の能力次第であり、正しい証拠が手にあっても生成器が同じ動作を忠実に描き出せなければ、このスコアは遅れる。
保存する証拠の量を変えながらメモリコストを、そして六つのメモリ設定にわたって実行時間・リトライ・スループットを測る。
| 指標 | 記憶なし | 持続記憶 |
|---|---|---|
| ショットあたりリトライ | 1.00 | 0.54 |
| リトライを反映した納品時間 | 359秒 | 339秒 |
| ストーリーあたり実行時間 | 51.9分 | 64.9分 |
| スループット | 7.28ショット/時 | 6.21ショット/時 |
| ショットあたりメモリオーバーヘッド | — | 98秒 |
まとめるとトレードオフだ。記憶を積み上げて検証するコストを払う代わりに、誤った状態が後ろへ波及して生じる無駄な再生成を減らす。総演算量そのものは増える。
検証ゲートの効果は二つに分けて見るべきだ。一つは今すぐ見える効果だ。記憶を多く積むほど映像審査の却下率が52.6%(記憶なし)から36.8%(全状態)へと着実に下がり、中間設定もすべて同じ方向なので、この改善が最終構成でだけ生じたわけではない。もう一つは複数ショットにわたる効果で、一度ずれた観測が後のショットへ波及して誤差が積み上がるのを防ぐ側だ。ここまでは確認された結果だ。ただし構成要素をすべて入れた最後の段階でスコアが大きく上がらなかったことについて、著者らは、検証が新しい情報を加えるというより、すでに持っている能力を守ってくれるという意味だと読む。この箇所は測定値ではなく著者らの解釈だ。
| 追加した要素 | 変化 |
|---|---|
| フレーム履歴 | 記憶なしに比べ三指標すべて上昇 |
| 静的シーン証拠 | LPIPS_C 0.030低下(改善) |
| シーン更新 | C-Top10 0.041上昇 |
| イベント記憶 | 再捕捉スコア大きく上昇、空間変化は小さい |
| 再帰的コンパイル | イベントスコア 0.508 → 0.711 |
著者らが認めた限界がある。イベント再捕捉において、動作・状態の正確な再現はReCAにわずかに及ばなかった。人間評価では六基準すべてで平均1位だったが、基準ごとのばらつきが大きかった。
| 基準 | 平均 |
|---|---|
| 脚本への忠実度 | 4.40 |
| キャラクターの一貫性 | 4.22 |
| 視覚的な魅力 | 4.10 |
| 叙述の一貫性 | 3.77 |
| 背景の一貫性 | 3.62 |
人間は、ショットが脚本に忠実か、キャラクターがつながっているかははっきり感じ取るが、環境全体の一貫性と物語全体の流れはまだ解ききれていないと感じる。効率の面で総演算量が増える点も著者らは隠さない。
まだ答えられていない問いもある。この方式は「最初の観測が座標系を正しく立てる」という前提に寄りかかっているが、最初の登録が傾けば、その後の整列はすべてその基準に縛られる。シーン記憶が固定された構造だけを残し動く領域を除く設計も、家具が動かされたり照明が変わったりして「静的だと信じていたもの」が変わる物語でどう動作するかは確認されていない。比較が生成器4種・エージェント5種・3D手法いくつかに限られる点も、他の環境への一般化を見積もるとき念頭に置くべきところだ。
この論文は映像研究だが、AI PMエージェントを扱う我々にとって役立つのは映像技術ではなく「状態更新のルール」だ。
一つ場面を描いてみよう。AIプロジェクトマネージャーが、何日も、何セッションにもわたって一つのプロジェクトの状態を積み上げる。昨日の会議で「決済は既存の店舗チェーンを再利用する」と決まったのに、今日エージェントが作った要約には「決済はToss PGの新規申請で進める」という一文が紛れ込む。もっともらしいが誤りだ。ありがちな設計なら、この要約がそのままプロジェクトメモリに入り、来週の会議準備のときにその汚染された状態を再び読み、同じ誤りを再生産する。ATASが映像で防ごうとした、まさにその伝播だ。
ATASの処方を移すと二筋になる。第一に、成果物の納品と状態の登録を分離する。要約の中の「決済=新規申請」という誤りは報告書の段階で正して送り出す。同時に、その決定がプロジェクトの持続状態に事実として登録されるには、元の会議記録との照合・出所・以前の状態バージョンとの整合を別途経させる。報告書を直して送り出す仕事と、その内容を長期記憶に事実として刻む仕事は別の判定だ。第二に、状態を「整理された結論」ではなく「いつ・どこで・何が出たのか索引され、出所の付いた証拠」として保管する。そうしてこそ、後で「あの決定はいつ、どの会議で出たのか」をチャンネル(空間)と日付(時間)で辿り直し、決定の出所を保存できる。
検証ゲートを付けるコストがタダではない点も併せて見るべきだ。ATASでそうだったように処理オーバーヘッドが付き、総作業量が増えうる。その代わり、誤った状態が後ろへ波及して生じる手戻りが減る。ただしこのトレードオフが我々の業務で実際に得になるかは、手戻りの減少分と追加コストを直接測ってみて初めて答えられる問いとして残しておく。
何から始めるか一つだけ選ぶなら、今のエージェントの成果物が「納品」と「記憶登録」を同じ一度の判定で処理していないか、そこから確認してほしい。二つがくっついているなら、そこが汚染の広がる最初の入口だ。
比較において、同じブロック内の手法は同じ生成器・プロンプト・長さ予算・評価プロトコルを共有し、ATASはこのインターフェースを比較全体で固定している。特定の生成器に有利なセッティングではなく、4つの生成器すべてで同じ改善パターンが出たという点が根拠だ。
いいえ。ATASは生成器の上に載せる枠組みであり、生成器を再学習させない。脚本をショット要求に分割し、記憶から証拠を参照して条件として与え、生成されたクリップを検証して記憶を更新するルールだけを外側で回す。