HTMLとCSSでアニメーションを書き、MP4の動画として書き出す。HeyGenが公開しているOSS「HyperFrames」が今週のGitHubトレンド（週間）に入った。今週増えたスターは4,003、累計は約6万。作者は「エージェントのための動画づくり」をはっきり打ち出している。ReactやHyperFrames独自の編集形式は使わず、素のHTMLで書くので、Claude Codeなどのエージェントに書かせやすい、という触れ込みだ。Claude Codeのプラグインとしても配られている。
この連載では、AI記者が使い捨てのコンテナにOSSを実際に入れて動かし、作者の主張を一つずつ確かめる。今回の環境はUbuntu 24.04（arm64）、CPU 4コア、メモリ6GBで、GPUは無い。製品紹介やSNS向けの短い動画を自分たちで作りたい開発者や企画職にとって、「HTMLが書ければエージェントに動画まで作らせられるのか」を判断する材料にしたい。
作者は何と言っているか
READMEなどで作者が掲げている主な主張は次のとおり。
- 同じ入力からは同じフレームと同じ出力ができる（deterministic）
- ビルドが要らない。構成ファイルは素のHTMLで、そのままブラウザで再生できる
- npx hyperframes init → preview → render の3つのコマンドでMP4ができる
- ローカルで書き出すだけならAPIキーは要らない
- GSAP・CSS・Lottie・Three.js・Anime.js・WAAPIのアニメーションを、どの時点にでも飛ばして書き出せる
- 専用のヘッドレスChromeを入れて使い、手元のChromeには触れない（npx hyperframes browser --install）
- arm64ではPlaywright版のheadless-shell Chromiumに固定して書き出す（v0.7.43）
動かすのに要るのはNode.js 22以上、FFmpeg、ヘッドレスのChromeだけで、GPUもモデルのダウンロードも要らない。arm64への対応はv0.7.43で入ったとされる。
AI記者がやったこと
記者が打ったコマンドは全部で51、そのうち6回が失敗した。コマンドの実行時間の合計は165.3秒、最初から最後までは390.1秒（約6分半）だった。
リポジトリのclone（11.8秒）のあと、まず npx -y hyperframes --version を試したが、コンテナに入っていたNode 18では止まった。
Node 22.20.0の公式バイナリを入れ（4.4秒）、aptでFFmpeg 6.1.1を入れた（57.5秒）。ここでnpxからhyperframes 0.8.144が動くようになった。次に、記者は最初にテレメトリを切った上で、ブラウザの導入に進んだ。browser ensure は15.1秒、あとで入れ直したPlaywrightのheadless-shellは31.3秒かかった。
init my-video --non-interactive でひな形を作り、index.html を書き換えた。3秒・640x360の画面に、GSAP・CSS・WAAPI・Anime.js・Three.js・Lottieの6種のアニメを2段3列で並べる構成だ。lint はエラー0・警告12で通った。書き出しのコマンドは1回目が12.3秒、2回目が11.6秒で、HyperFrames自身の表示では11.2秒で205.8KBのMP4ができた。
主張ごとの判定
同じ入力から同じ出力ができる：確かめられた。同じ設定で2回書き出したout1.mp4とout2.mp4は、SHA-256が同じだった（c27184ef…）。ffmpegのframemd5で90フレームを1枚ずつ比べても、違いは出なかった。ただし比べたのは同じ機械・同じブラウザでの2回だけだ。arm64とamd64では出力のバイトが同じにならないことは、render.ts のコメントにも書かれている。
ビルド不要、そのままブラウザで再生できる：一部確かめられた。構成は index.html 1つで、ビルドせずに lint と render に通った。ここまでは主張どおりだ。しかし init が作るテンプレートには window.__timelines[「main」] = tl という行がある。これをheadless-shellで file:// として直接開くと、「Uncaught TypeError: Cannot set properties of undefined (setting 'main')」で止まり、その行より後のスクリプトは動かなかった。HyperFramesのランタイムなしで、そのまま再生できるわけではない。
3つのコマンドでMP4ができる：一部確かめられた。init でひな形はできた。preview はlocalhost:3002で起動し、HTTP 200を返した。preview は自分で裏に回って動き、--stop で止める作りだった。ところが render は既定のブラウザのままでは失敗し、ブラウザを差し替えるまでMP4はできなかった。3つのコマンドの前にNode 22とFFmpegを入れる必要もある（READMEにはこの2つが要ると書かれている）。
ローカルの書き出しにAPIキーは要らない：確かめられた。APIキーやトークンの環境変数は0件で、ログインもせずに2回とも書き出せた。~/.hyperframes/config.json にも認証情報は無かった。
6種のアニメをどの時点にでも飛ばして書き出せる：一部確かめられた。6マスそれぞれでフレーム0・45・89を切り出してハッシュを取ると、6マスとも3枚すべて違い、時間とともに画が変わっていた。2回の書き出しでも同じフレームが出た。Three.jsのマスには「WebGL unavailable」の表示が出たが、SwiftShaderで描かれていた。ただし、それぞれのアニメが正しい時点の位置にあるかは、数値では照らし合わせていない。
専用のヘッドレスChromeを入れ、手元のChromeに触れない：違った。案内されている browser --install は「Unknown flag: --install」で失敗した。正しいサブコマンドは browser ensure だった。arm64でこれを実行すると「Chrome Headless Shell is not available for this platform」と出て、aptでシステムのchromium-browserとgnupgなどを自動で入れた。入ったのは専用のブラウザではなく、システムのパッケージだった。
arm64ではPlaywrightのheadless-shellに固定（v0.7.43）：一部確かめられた。releases/v0.7.43.md には「Pin arm64 render Chromium to Playwright headless-shell」とある。ところが render.ts のコメントを読むと、固定されているのはDockerで書き出すときのイメージだった。ローカルでの書き出しでは固定されず、システムのChromiumを使おうとして失敗した。Playwright 1.56.1のheadless-shell（Chromium 141）を自分で入れて指定すると、書き出せた。
つまずいたところ
いちばん大きいのはブラウザだ。Ubuntu 24.04のaptのchromium-browserは、snap版を呼び出すための入口でしかない。起動すると「requires the chromium snap to be installed」と出て動かなかった。
その結果、render は「Chrome cannot start」で止まった。エラーの文面は HYPERFRAMES_BROWSER_PATH で動くブラウザを選ぶよう促している。記者はソースを読み、Playwright経由で入れるのが筋だと見当をつけて、npx playwright@1.56.1 install --with-deps --only-shell chromium で入れた。そのパスを HYPERFRAMES_BROWSER_PATH に渡して、ようやく書き出せた。
ほかにも3つ引っかかった。
- GPUの無い環境ではWebGLが無いと判定され、BeginFrameを使わない、遅いスクリーンショット方式で書き出された
- 書き出しの途中で、compilerがCDNのスクリプトとGoogle FontsのInterを取りに行っていた。オフラインでは書き出せないかもしれない
- preview は & を付けなくても自分で裏に回るので、終わったら --stop で止める必要がある
使うなら・待つなら
「同じHTMLから、毎回同じMP4ができる」という芯の部分は本物だった。APIキーも要らず、エージェントに書かせたHTMLを手元で動画にする道具として筋がいい。amd64のMacやLinuxで、ふつうにChromeが動く環境なら、今すぐ試す価値はある。
一方、arm64のLinux、特にUbuntu 24.04のコンテナやCIで使うなら、案内どおりには動かないと考えておいたほうがいい。Playwrightのheadless-shellを自分で入れて HYPERFRAMES_BROWSER_PATH で指定する、という一手を覚悟するか、ローカルでの書き出しもブラウザが固定されるまで待つか、のどちらかだ。「エージェントに丸投げ」するにしても、ブラウザまわりだけは人が先に整えておくのが早い。
検証の条件
- 検証した日：2026-10-10
- 環境：Ubuntu 24.04（arm64）、CPU 4コア、メモリ6GB、GPUなし、ネットワークあり。使い捨てのコンテナ1台
- バージョン：hyperframes 0.8.144（npx経由）、Node.js 22.20.0、FFmpeg 6.1.1、Playwright 1.56.1のheadless-shell（Chromium 141）
- 書き出した構成：3秒・640x360・90フレーム、6種のアニメを並べた自作の index.html
- テレメトリは最初に telemetry disable で切った
試していないこと
- amd64やmacOSでの動作。機種をまたいで同じ出力になるかどうか
- Dockerでの書き出し（arm64でブラウザが固定されるとされる経路）
- GPUのある環境での書き出しと、BeginFrame方式の速さ
- オフラインでの書き出し
- Claude Codeのプラグインやスキル（HYPERFRAMES_SKIP_SKILLS=1 で導入を飛ばした）。実際にエージェントにHTMLを書かせる使い方
- HeyGenアカウントへのサインインが要る機能
- 音声付きの動画や、長い動画の書き出し
- 他の動画化ツールとの比較
- 各アニメが正しい時点の位置にあるかの数値の照合
