AI動画生成のレンダラーをRemotionからHyperFramesへ切り替えた理由

ブラウザ自動化の上に動画パイプラインを構築するという発想は、設計段階では非常に明快に見えます。Reactコンポーネントでシーンを組み立て、CSSでトランジションを指定し、ヘッドレスChromiumインスタンスが各フレームをFFmpegのパイプへ流し込みます。私たちはこのアーキテクチャを本番環境で数か月運用し、数十本の動画バッチを書き出してきました。

しかし今週初め、フラッグシップである38.8秒のローンチ動画で詳細なベンチマーク測定を実施したところ、アーキテクチャの根本的な見直しを迫られる結果となりました。

従来のRemotionパイプラインではMP4の生成に74.2秒を要し、生成ファイルは21.0 MBに達しました。まったく同一のタイムラインをHyperFrames向けに再構成したところ、書き出しは22.4秒で完了し、ファイルサイズは11.2 MBに縮小。18フレームの自動画質監査でも10点満点中8.6点を記録しました。

文字の鮮明さや音声同期を一切損なうことなく、レンダリング速度は3.3倍に向上し、ファイル容量は47%削減されました。ヘッドレスChromeが動画生成で直面する技術的な限界と、直接GPU描画が動画パイプラインの費用対効果をどのように変えるのかを詳しく解説します。

ヘッドレスChromeに支払う計算オーバーヘッド#

バッチ動画生成でRemotionがボトルネックになる理由を理解するには、ヘッドレスChromiumがコードを動画フレームへ変換する内部処理を追う必要があります。

Remotionはブラウザを実時間ディスプレイとしては扱いません。仮想時間を1フレームずつ進めて処理します。毎秒30フレームで再生される38.8秒の動画では、単純計算で以下の処理が発生します。

38.8秒 × 30 fps = 1,164フレーム

この1,164フレームのすべてにおいて、パイプラインは次の手順を同期実行します。

1. Reactランタイムへ仮想時間の経過を通知。
2. Reactのレイアウト更新、コンポーネント差分、CSSスタイルの再計算。
3. Chromium内部のコンポジターレイヤーへDOMをラスタライズ。
4. DevTools ProtocolまたはCanvasデータ転送を通じてピクセルバッファを抽出。
5. プロセス間通信（IPC）を経由して未圧縮ピクセルデータを外部のFFmpegプロセスへ転送。
6. 生フレームをH.264動画としてエンコード。

マルチプロセス並列化を適用しても、この構成ではプロセスの境界をまたぐデータ転送に大半のクロックサイクルが奪われます。フレームのスナップショットを取得するためだけに完全なブラウザエンジンを複数起動している状態となり、CPUは動画の圧縮エンコードよりもIPCバッファの受け渡しやブラウザのレイアウト計算に多くの時間を消費してしまいます。

同時実行数の多いクラウドワーカーではこのオーバーヘッドがさらに蓄積し、ワーカーインスタンス1台あたりのメモリ消費が1.5GBに膨らみ、スレッド競合によって処理が遅延して生成キューが滞留する要因になっていました。

直接GPU描画：HyperFramesのアプローチ#

HyperFramesはプログラムによる動画生成を、ブラウザ自動化ではなくグラフィックスパイプラインの視点から再構築しています。

リモートデバッグのブリッジを介して画像フレームを吸い出すためにブラウザスタック全体を起動するのではなく、HyperFramesは宣言的な構成ツリーを直接グラフィックス描画命令へコンパイルします。テキスト、SVGシェイプ、画像、音声トラックは、ミリ秒単位でシーク可能な単一の決定論的タイムライン上に配置されます。

コンパイラを実行すると、各フレームはネイティブに評価されます。

# SceneVerso コンポジター実行コマンド
hyperframes render \
  --project ./timeline \
  --out ./out/render.mp4 \
  --width 1920 \
  --height 1080 \
  --fps 30

Chromiumのプロセス分離やDevToolsのキャプチャ往復が存在しないため、フレームごとのIPCボトルネックが完全に解消されます。タイムラインの状態をメモリから直接参照し、ハードウェアアクセラレーションによる幾何変換を施して、エンコーダーへ直接ストリーミングします。

ベンチマーク：実測テレメトリの比較#

4つのシーン、文字アニメーション、SVGアイコン、音量ダッキング付きBGM、11箇所のカットを含む38.8秒の同一入力データで両エンジンを比較検証しました。

ビルドマシンから直接取得した実測データは次のとおりです。

実時間比は開発者向けツールにおいて決定的な指標です。0.52倍速のパイプラインでは、生成される動画1秒に対して約2秒の待機時間が発生します。一方、1.73倍速であれば実際の再生速度よりも速く書き出せるため、30秒のプロダクト紹介クリップなら18秒未満で手元に届きます。

ファイルサイズの削減効果も顕著でした。どちらのコンポジターも標準的な1080p H.264で出力するよう設定していましたが、HyperFramesはエンコード前の段階でカラーバッファとアルファブレンドを直接管理するため、ブラウザ特有のアンチエイリアスのにじみが発生せず、シャープなベクターエッジを維持できます。ノイズの少ないクリーンなラスタ平面は、固定品質係数（CRF 18）での圧縮効率が大幅に向上します。

Remotionを引き続き採用するユースケース#

技術的な意思決定には常にトレードオフが伴います。標準コンポジターを切り替えたからといって、Remotionを完全に排除したわけではありません。

Remotionは以下の2つの領域において依然として非常に強力であり、SceneVersoでは副次エンジンとしてサポートを継続しています。

1. 高度なグラフ表現や動的テキスト配置: 動的なFlexbox折り返し、自動追従する表組み、あるいはブラウザのテキスト長測定API（measureTextなど）に厳密に依存するSVGパスの自動トレースを行う場合、Chromiumが提供するレイアウト機能の信頼性は極めて高い水準にあります。
2. Reactエコシステムのコンポーネント描画: インタラクティブなデータテーブルや地図ライブラリなど、既存のReactコンポーネントツリーを動画内に直接組み込む必要がある場合、ネイティブなReact環境で描画することが確実な選択肢となります。

こうした特殊な要件に対して、SceneVersoではプロジェクト単位でエンジンを切り替えられるマニフェスト設定を提供しています。

{
  "version": "1.0",
  "project": "architecture-diagram",
  "engine": "remotion",
  "scenes": [...]
}

エンジンの指定がない場合、一般的な解説動画やショート動画には自動的にHyperFramesが適用されます。

SceneVersoの制作パイプラインへの影響#

この描画エンジンの変更は、SceneVersoの制作コスト構造を大きく改善しました。

SceneVersoは「外部の音声APIやクラウド生成へ課金する前に、まずマニフェストをレビューして承認する」という厳格な原則で運用されています。完成動画1分あたりの目標ユニットエコノミクスは0.13〜0.16ドルです。

• ElevenLabsによる音声合成: 約0.09ドル / 分
• ライセンス済みBGM音源: 約0.04ドル / 分
• コンポジティング計算費: 約0.01ドル / 分（セルフホストランナー）

クリップ1本あたり74秒を要していた環境では、バッチ生成時にコンピュートサーバーがすぐに飽和していました。22秒まで短縮されたことで、専用ワーカー1台あたり1時間に150本以上の動画を安定して書き出すことが可能になりました。

動画制作の自動化において、書き出しの高速化は単なる快適さの問題ではありません。開発者向けCLIとしてリアルタイムに使えるか、あるいは時間のかかるバックグラウンド処理になってしまうかを分ける重要な境界線なのです。