SORA vs Remotion
2026年3月24日、OpenAIは「We're saying goodbye to Sora」と発表した。1日あたり1500万ドル（約22億円）の運用コストに対してライフタイム収益は210万ドル。Disneyとの10億ドル投資契約も破談になり、4月17日にはSoraヘッドのBill PeeblesとCPOのKevin Weilが同日退社した。SORAが登場したとき、テキストから映像を「生成」するというアプローチが動画制作を変えると言われたが、半年で消えた。
Introducing Claude Design by Anthropic Labs: make prototypes, slides, and one-pagers by talking to Claude.
— Claude (@claudeai) 2026年4月17日
Powered by Claude Opus 4.7, our most capable vision model. Available in research preview on the Pro, Max, Team, and Enterprise plans, rolling out throughout the day. pic.twitter.com/2BgBGtgYGX
そのタイミングでClaude Designのプロモーション動画が出た。洗練されたアニメーション、システムの動作を流れるように見せる構成、「これが欲しかった」と思わせる演出。しかしながら、この動画は、SORAのような動画生成でも、後から画面を撮り直して演出を作り直しているのでもなく、画面開発とプロモーションビデオがコードとして一体化して生成されるRemotionのような質感を感じた。
RemotionはReactコンポーネントとして動画を記述し、各フレームを決定論的にレンダリングするライブラリだ。currentFrame という変数に応じてDOMがどう変化するかを書けばそれが動画になる。バージョン管理できるし、差分も取れるため、コードが映像の設計図になる。SORAはプロンプトから映像を確率的に吐き出すが、Remotionはコードが動いた軌跡がそのまま動画になるからこそ、LLM が生成しやすく、再現性が高く、編集しやすい。
もちろん、SORAが代替するのは俳優の演技を含めてのものだったのであろうが、フォトリアルな3DCGキャラクターを適切に動かして後からの演出を入れられるスクリプトを生成するアプローチのが随分とリーズナブルだったのではないかとも思われる。画面や商品であれば一貫性も大事だ。
8番出口の攻略ツールを作るような気分でVRTを組む
そんなこともあって、自分で作るソフトウェアやゲームにもスクリプトから動かして、スクリーンショットや動画を撮るプロセスの自動化を試行錯誤をしているのだけど、これ自体がe2eのスモークテストとして動いてくれる側面がある。
スモークテストとは電子基板に通電して「煙が出ないか」確認する工程から来た言葉で、システムの主要 な動作を一通りなぞって基本的に動くかを確認する最小限のテストだ。最小限のテストとはいえ、ボタンを押してスクリーンショットを撮っていくe2eテストを手作業で作るのは大変だったのだけど、Claude CodeとPlaywrightを使うことでかなりの部分まで自動化が行える。
特に効果が高いのが、デザインを含む修正を依頼した時で、PlaywrightがネイティブでスクリーンショットのDiff比較をサポートするようになったことで、意図せぬ場所の表示まで崩れたりしていないかをVRT（Visual Regression Testing）の一部として自然に組み込めるようになった。
「一連の操作フローを実行して異変がないかを確認して、異変があればテストを止めて通知する」なんてことを自動実行できるように整備していると、『8番出口』を想起する。『8番出口』は2023年のインディーゲームで、地下通路を歩き続けて出口を目指す構造を持つ。異変がない通路は通過し続け、異変を見つけたら引き返す。SKILLにこのゲームの攻略情報として、確認観点や通知方法を書き出しながら自動実行結果を眺めて手直ししつつも、徐々に人間が介在しなくても動くようになっていく。
僕自身はいわゆるアクションゲームやシューティングゲームよりも、入念に準備をして放置するタイプのゲームが好みであった。『A列車で行こう』『ザ・タワー』『ダンジョンキーパー』『影牢』。最近も『ポケモン・スリープ』をやっているし、『Loop Hero』などタワーディフェンス系も好む。
そう見ると退屈なテスト作業が8番出口をAI Agentに自動攻略させるかのような奇妙なメタゲームに変換されていき、このような形でのゲームプレイワーキングが実現されていくのかもしれないと思ったりもする。結局のところで広い意味での「攻略本」をエージェントが実行可能な形で記述することに価値が宿る。
テスト結果からユーザーマニュアル・プロモを生成する
そして、このテストケース実行結果からユーザーマニュアルやプロモーションビデオを作ることもできる。一部のデザイン変更のたびにスクショ付きのマニュアルやプロモーションビデオの素材撮影をしていたら1日仕事になってしまうため、古いままの画面になっていたり、作り直すのに気合を入れたり、外注費用すら検討する必要があった。
それが、spec.mdとコードとSKILLを提示して、e2eスモークテストのスクショエビデンスや実行動画を取りまとめることでマニュアルは自動生成できるし、動画スクリプト自体を大きく変換しなくても、素材の部分差し替えできるようにしておくことでプロモーションビデオまで最新の画面デザインやUI操作に更新される。
テストエビデンス → ユーザーマニュアル → プロモーション動画。この3つは同じものの密度と演出の違いに過ぎない。Playwrightが撮ったスクリーンショットはそのままマニュアルのスクリーンショットになり得る。シーケンスをRemotionでつなげばプロモーション動画の素材になる。"Docs as Code"の思想をさらに推し進めた先に"Promo as Code"という地点がある。
とはいえ、e2eテストの実行にはそれなりに時間がかかる。内部的にブラウザを起動してシナリオを流して比較するというプロセスは、ユニットテストのような即時フィードバックとはいかない。だからこそ会議が多い日や、サーバーサイドにCIを逃がせる環境があるときに回すのが向いている。8番出口を歩くのは自分ではなく、エージェントに任せるのだけど、だからこそエージェントを自分で作るところに面白さの起点がある。
正直なところで、プロモーションビデオ生成までは素人仕事ってのが現状だけど、SKILLに蒸留できさえすればとなる部分も多い。また何が機能的に実現できたらプロモーションで映えるかなんて逆流もできる。Dropboxは先にプロモーションビデオから公開したが、SNSにおけるアテンションという観点でもコード生成とビデオ生成が一体化して実現できている状況が望ましく、その前提としての生成動画 as a Codeが重要な要素になっていくのではないかと考えている。
