技術拆解 002｜hyperframes：HTML を書くだけで動画が作れる、HeyGen が動画レンダリングをオープンソース化

一、これは何か

hyperframes は HeyGen がオープンソース化した動画生成フレームワークだ。一言で言うと：HTML/CSS を書いて、MP4 動画にレンダリングする。

「動画を作る」という作業を、「Web ページを書く」作業に置き換えてくれる。フロントエンドができれば動画が作れる——タイトルアニメーション、データチャート、ブランドモーショングラフィックスを HTML + CSS で書けば、あとは確定的な MP4 にレンダリングしてくれる。

主な事実：

• GitHub リポジトリは heygen-com/hyperframes、スター数は約 4.6 万。2026 年 3 月に作成され、半年でこの規模に到達。ライセンスは Apache 2.0
• TypeScript 実装、Node.js ≥ 22 が必要、npm パッケージ名はそのまま hyperframes
• キャッチコピーは “Write HTML. Render video. Built for agents.”——最後の一文がポイントだ：AI プログラミングエージェント専用に設計されている
• 同じエンジンで 3 つの使い方ができる：ローカル CLI で個人利用、AI エージェントにスキル（skills）として追加、ホスティングプラットフォームのレンダリングカーネルとして利用

二、コアメカニズム：なぜ「HTML を書く」ことが「動画を作る」ことに等しくなるのか

この設計の鍵は、3 つの技術的な決断にある。

第一に、動画 = タイムライン上の Web ページのスナップショット。 従来の動画はフレームの連続だが、hyperframes は各フレームを「ある時点の HTML ページの状態」として扱う。CSS で書いたトランジションアニメーションを 1 フレームずつスクリーンショットしてエンコードし、MP4 を出力する。ブラウザで見えるアニメーション効果がそのまま完成品の効果になる——頭の中でタイムラインを換算する必要がなく、WYSIWYG だ。

第二に、シーク可能なアニメーション（seekable animations）。 これがフレームワーク全体の核心だ。普通の Web ページのアニメーションは「再生されたら終わり」で時間は不可逆だが、hyperframes はすべてのアニメーションが「任意の時点にジャンプして状態を取得できる」ことを要求する。確定的でシーク可能であってこそ、フレーム単位のレンダリングが成立する——同じ時点なら常に同じ画面がレンダリングされ、従来の画面録画方式のような前後フレームのちらつきやランダム要素の跳ね返りが発生しない。

第三に、Skills 体系がエージェントに友好的。 20 個のスキルが内蔵されており、AI エージェントに「動画の計画 → 正当な HTML の作成 → シーク可能なアニメーションの接続 → メディアの追加 → lint → プレビュー → レンダリング」という完全な生産フローを教え込んでいる。入り口はルーティングスキル /hyperframes で、エージェントはこれを読めばどのワークフローを呼び出すべきかがわかる。インストールは 1 行：npx skills add heygen-com/hyperframes。Claude Code、Cursor、Gemini CLI、Codex すべてに対応している。

この組み合わせの直接的な結果：「AI で Web ページを書けるエージェント」が瞬く間に動画生産能力を手に入れる。 After Effects を学ぶ必要も、動画エンコードを理解する必要もない。HTML のスキルが高ければ高いほど、質の高い動画が作れる。

三、技術評価：亮点と限界

まず亮点から。いずれもエンジニアリングレベルの確かなものだ：

1. 確定的レンダリング。 同じコードなら常に同じ動画が出力される。これはコンテンツ生産にとって必須の要件だ——フォントサイズを 1 つ変えて再レンダリングしても、他の部分が勝手に変わることがない。従来の「画面録画して動画にする」方式ではこれは実現できない。
2. スキル設計が成熟している。 単に API をエージェントに渡すのではなく、「生産フロー」そのものをエージェントに教え込んでいる（まず計画、次に作成、次に lint、次にプレビュー、最後にレンダリング）。README には「どのスキルをインストールするか、必要に応じてインストールする方法、非インタラクティブ実行の処理方法」が非常に詳しく書かれている——実際に使い込み、痛い目に遭ってきたプロジェクトだとわかる。
3. エコロジーポジションが賢い。 HeyGen は AI デジタルヒューマン動画を手がける商業企業だが、レンダリングエンジンをオープンソース化し、創作の入り口をエージェントに委ねることで、「HTML を書ける全世界のエージェント」を自社エコロジーの潜在的ユーザーに変えてしまっている。

次に限界についても、はっきりさせておこう：

1. 作れるのは「グラフィックモーション動画」であり、「実写動画」ではない。 タイトルアニメーション、データ可視化、プロダクト紹介、インフォグラフィックのモーション——こうしたものは高速かつ高品質に作れるが、実写の人物映像を生成することは期待しないほうがいい。それは別の技術路線だ。
2. レンダリングはローカル計算。 動画レンダリングは CPU/GPU を消費する。長尺動画や高解像度の動画をローカルでレンダリングするには時間がかかり、瞬時に出力されるわけではない。
3. 品質の上限は HTML の力量に依存する。 フレームワークは「安定して Web ページを動画に変える」役割を担うが、ページ自体のデザイン性やアニメーションのリズムは、人（あるいはエージェント）のレベルで決まる。
4. リリースされてまだ半年。 API は急速に反復されており、本番環境で採用するならバージョンアップに追従する覚悟が必要だ。

四、価値判断：誰が注目すべきで、誰は急がなくていいのか

これが解決する真の問題：動画コンテンツの生産コスト。 プロダクト紹介のモーション動画やデータ可視化の短編は、以前なら AE を起動してデザイナーのスケジュールを押さえる必要があったが、今ではフロントエンドができる人（あるいはエージェント 1 体）が HTML で書き上げられる。

最も注目すべき 3 種類の人：

• コンテンツクリエイター/自媒体：オープニング、タイトルカード、データグラフのモーションを自分で書いて自分で修正でき、デザイナーのスケジュールに依存しない
• AI エージェントを使い慣れている開発者：エージェントにスキルをインストールすれば、「動画を説明 → 完成品を出力」というフローがすでに回せる
• プロダクトマーケティング/グロース担当者：異なるバージョンのプロダクト紹介動画を大量生成して A/B テストができ、限界コストはゼロに近づく

急がなくていい人：実写ニーズしかないチーム、フロントエンドの基礎がなくエージェントも使わない個人ユーザー（学習コストが直接 CapCut のテンプレートを使うより高くつく可能性がある）。

一言で判断するなら：これは「動画ツール」ではなく、「動画生産能力をコード生産ラインに組み込む」ためのインフラストラクチャだ——すでに AI でコードを書いている人にとってはタダで手に入る生産能力であり、コンテンツ業界にとってはまた 1 つの「スキルの水平移動」：Web ページのスキルがそのまま動画のスキルになる。

五、どう導入するか

方式 1：AI エージェントにインストール（推奨）

npx skills add heygen-com/hyperframes

インストールが終わったら、エージェントに直接こう言えばいい：

/hyperframes を使って 10 秒のプロダクト紹介動画を作って。タイトルはフェードイン、背景は動画、軽い BGM をつけて。

注意：非インタラクティブ/エージェント環境では npx hyperframes skills update を使う（コアセットだけを厳選してインストールするため）。インタラクティブなピッカーで全選択すると 20 個すべてがインストールされるが、普通はそこまで必要ない。

方式 2：ローカル CLI

npm install -g hyperframes

Node.js ≥ 22 が必要。（同フレームワークのアニメーション仕様に沿った）HTML を書き、レンダリングコマンドを実行すれば MP4 が出力される。

導入パスの提案：まず公式 Playground（hyperframes.dev）でオンラインで使い心地を試す → 次にローカルに CLI をインストールして最初の 1 本作る → 最後にエージェントにスキルをインストールして量産化する。公式ドキュメントには Catalog（データチャートなどの既製コンポーネントブロック）と Showcase（事例集）があるので、見よう見まねで改造するのが最速の入門方法だ。

六、自分で同様のシステムを作るには

hyperframes は突き詰めれば 3 つのことをしている：Web ページのレンダリング、フレーム単位の切り出し、エンコードして動画にする。自分で使えるバージョンを組むなら、技術路線はこうなる：

第 1 層：ヘッドレスブラウザでフレーム単位にスクリーンショット。 Playwright または Puppeteer で HTML を開き、一定のステップで時間パラメータを変更しながら 1 フレームずつ page.screenshot() する。鍵はアニメーションを「時間パラメータ駆動」で書くこと——すべての状態が 1 つの t 変数で決まるようにする。これが「シーク可能」の自作版だ。

第 2 層：フレームシーケンスのエンコード。 ffmpeg で PNG シーケンスを MP4 に合成する（ffmpeg -framerate 30 -i frame_%04d.png -c:v libx264 out.mp4）。このステップは成熟したツールなので、落とし穴はない。

第 3 層（任意）：エージェントスキルをラップする。 「動画の仕様」（サイズ、長さ、アニメーションの書き方、乱数の禁止）を SKILL.md にまとめ、エージェントに仕様通りに HTML を書かせる——このステップこそが hyperframes の真の参入障壁だ：コードが難しいのではなく、生産規範をエージェントが実行可能なフローとして落とし込んでいる点にある。

自作版と hyperframes の差はどこに出るか：確定性の保証（同フレームなら同画面になるよう膨大な作業が積まれている）、メディア同期（音声トラックの位置合わせ）、レンダリングパフォーマンス。だから私の提案は：まず hyperframes を使い、それでカバーできないシナリオ（自前のレンダリングパイプラインに埋め込む必要があるなど）が出てきたら自作を検討する——レンダリング原理を学ぶのが目的なら、自作してみるのが最高の授業料になるが。

結論

hyperframes の価値は「HTML を動画に変える」というテクニックにあるのではなく、抽象化レベルを正しく選んだ点にある：動画の本質は「タイムライン上の UI 状態」であり、この本質を最も成熟したレンダリングエンジン（ブラウザ）と最も普及したスキル（HTML/CSS）に委ねれば、残りのエンジニアリング的な問題はすべて解決可能になる。

一般の人にとって、今回の話で最も重要な示唆はこれだ：AI 時代のコンテンツ生産能力は、「特定のソフトを使えること」から「自分が何を欲しいか説明できること」に移り変わりつつある。 HTML が書ける人は動画生産能力をタダで手に入れるし、書けない人もエージェントを使いこなせば同じく生産能力をタダで手に入れる——前提として、こういう生産ラインが存在することを知っている必要はあるが。

---

参考出典

• GitHub リポジトリ：https://github.com/heygen-com/hyperframes
• 公式ドキュメント：https://hyperframes.heygen.com/introduction
• Playground オンライントライアル：https://www.hyperframes.dev/
• コンポーネントカタログ：https://hyperframes.heygen.com/catalog/blocks/data-chart