動画を作りたいとき、従来の選択肢はAfter EffectsやPremiere Proのようなソフトウェアか、あるいはRemotionのようにReactで組むかのどちらかでした。でも「AIエージェントに動画を作らせたい」という場面では、どちらもすこし文脈が合わない気がします。エージェントがGUIを操作するのは難しいし、Reactのコンポーネント設計をエージェントに任せるのも教えるコストが高い。そんな隙間を狙って登場したのが、HeyGen社によって公開されたHyperFramesです。この記事では機能の紹介と、設計レベルで何が上手くできているのかを一緒に見ていきます。
リポジトリ: https://github.com/heygen-com/hyperframes
どんなフレームワークか
HyperFramesを一言で言うと、「HTMLとCSSで書いたレイアウトをMP4動画として書き出すフレームワーク」です。PuppeteerでChromeをヘッドレス駆動し、GSAPやAnime.jsといったアニメーションライブラリを使って各フレームをシーク可能な状態で制御しながら、FFmpegでMP4に合成するという仕組みを取っています。
想定しているユーザーは大きく3種類いて、CLIを直接叩くエンジニア、Claude CodeやCursorなどのAIコーディングエージェント経由で使う人、そしてHeyGen社が運営するホスト型ワークフローの裏側としての利用、です。特にエージェント向けの設計には力が入っていて、20本のSkillファイルを搭載し、エージェントが「どのワークフローを選ぶか」から「どのアニメーションAPIを使うか」まで判断できる情報を構造化して渡しています。スター数は43,000を超えており、公開直後から注目を集めているリポジトリです。
設計でここが上手い
ルーターSkillという考え方
Skill設計で最も面白い点は、/hyperframes というルーターSkillの存在です。エージェントがこのSkillを読むことで、10種類の制作ワークフローのうちどれを使うべきかを判断できます。「プロダクトのURLを渡したら/product-launch-video、PRのURLなら/pr-to-video、楽曲ファイルなら/music-to-video」という具合に、入力の性質からワークフローへの経路が一対一で定まるように設計されています。
これは単なるドキュメントの整理ではなく、エージェントが誤ったワークフローに迷い込むことを防ぐアーキテクチャ上の判断です。20本のSkillを同列に並べていたら、エージェントは毎回全Skillを参照してから判断することになり、トークン消費が増えます。ルーターを1本置くことで、「まずルーターだけ読む→必要なワークフローSkillだけオンデマンドで読む」という2段階の参照になり、無駄な読み込みを防いでいます。
data-* 属性によるタイミング制御
HTMLの data-* 属性でアニメーションのタイミングを記述するというアイデアは、エージェントとの相性が良いです。Reactベースのアプローチでは、コンポーネントのpropsやhooksの知識が必要になりますが、HTMLの属性であれば「このdivに data-in="0.5" を付けると0.5秒後に入場する」という構造をエージェントが直感的に扱えます。属性の組み合わせで制御できる範囲が決まっているので、エージェントが誤った使い方をしたときもlintコマンドで検出できます。
Skillのオンデマンド展開
npx hyperframes skills update を実行するとコアセット（ルーターと主要ドメインSkill）だけがインストールされ、各ワークフローは必要になった時点でルーターが自動的に追加取得します。全Skillを最初から読ませるのではなく、必要なものだけをタイミングよく展開するという設計は、コンテキストウィンドウを大きなリソースとして扱っている証拠です。エージェントに20本のSkillを一括で押し込むと、その分コンテキストが圧迫される。それを避けるための設計がインストール段階から組み込まれています。
FFmpegとPuppeteerの組み合わせの意味
HTMLを動画にするアプローチとして、CanvasAPIを直接叩く方法もあります。しかしHyperFramesはPuppeteerでブラウザ環境をそのまま使う道を選んでいます。これはCSS、SVG、Webフォントなどブラウザのレンダリングエンジンが持つ表現力をそのまま使えるということを意味します。自分が普段書いているHTML/CSSで動画を作れるという体験は、Remotionで「Reactで書ける」と言うのと同じ発想ですが、学習コストはHTMLのほうが低い場合が多いです。
こういう人に向くかも
AIエージェントを使って動画コンテンツを自動生成したい、というユースケースにもっとも素直にはまります。特に、GitHubのPRを渡すと変更内容の解説動画を作る /pr-to-video ワークフローは、開発チームのドキュメント自動化に直結する用途です。リリースノートを動画にしてSlackに流す、という運用もイメージしやすいです。
一方で、動画編集の経験が少ないWebエンジニアが「HTMLの知識だけでそれなりの動画を作りたい」という場面でも使えます。GSAPやCSSアニメーションはWebエンジニアにとって馴染みのある道具なので、After Effectsのタイムラインを学ぶより入門の壁が低いです。ただ、音声・BGM・字幕まで含めた複雑な構成になると、SkillとCLIコマンドの組み合わせを理解する必要があるため、ある程度手を動かす覚悟は要ります。
設計の良し悪しをどこで見るか
機能の単一性と責務の分散
「HTMLを動画に変換する」というコアの責務は明確に絞られています。ただし実際のSkill群を見ると、音声ミキシング（/hyperframes-audio）、Figmaからのアセット取り込み（/figma）、レジストリブロックの管理（/hyperframes-registry）まで、かなり広い責務を抱えています。コアはシンプルでも、Skill層が拡張されるにつれて「何でもできるツール」に近づいているのは事実です。これは「動画制作に必要なものを全部揃える」という判断なので一概に悪いとは言えませんが、自分のプロジェクトに導入するとき、使うSkillの範囲を最初に絞っておかないと学習コストが積み上がります。
ドキュメントの深度
READMEには20本のSkillの概要が全て記載されていて、Quickstart・Showcase・Playground・Catalog・Docsの5つのリンクが冒頭に並んでいます。公式サイトにプレイグラウンドがあるのは導入のハードルを下げる意味で大きいです。ただ、各Skillファイルの詳細はGitHub上では直接読めず、インストール後のローカルファイルか公式ドキュメントを参照することになります。「使い始めるまでの道のり」は整っているが、「中身を事前に把握してから導入判断する」という読み方は少しやりにくいかもしれません。
メンテナンスの継続性
HeyGen社はAI動画生成の商業サービスを運営していて、HyperFramesはその技術基盤の一部でもあります。これはメンテナンスが継続しやすい構造ですが、同時に「商業サービスの方向性に引きずられてOSSとしての設計が変わる可能性がある」というリスクでもあります。Apache-2.0ライセンスで公開されているので商用利用は問題なく、ライセンスの明確さという観点では安心です。
想定外の使われ方への備え
Remotionからの移行ワークフロー（/remotion-to-hyperframes）が用意されているのは、「既にRemotionで作ったものを持ち込みたい」という需要を想定していることを示しています。既存資産との接点を設計段階から考えているのは、ユーザー像の広げ方として興味深いです。一方で、HyperFramesで作った成果物を別の動画編集ツールに持ち込む逆方向は、MP4という標準フォーマットで出力されるので自然に可能です。
自分が書くなら、どこを変えるか
Skillのオンデマンド展開の仕組みは良いと思いますが、skills add コマンドと hyperframes skills update の2つが並存している点はすこし引っかかります。READMEには「インタラクティブ環境では skills add、エージェントや非インタラクティブでは skills update」と書かれていますが、この使い分けを初見のユーザーが即座に理解するのは難しいです。エージェントが自動実行する場合に誤ったコマンドを選ぶと全20本がインストールされてしまうという注意書きも、少し複雑です。コマンドを1本に統合して、インタラクティブかどうかを自動検出する設計にすると迷いが減るのではないかと思います。
また、data-* 属性によるタイミング記述の仕様が、ドキュメントのどこを見ればまとまっているのかが少し分かりにくいです。/hyperframes-core Skillを読めば分かるという設計なのですが、そのSkillをインストールしていない段階では確認できません。属性の一覧とサンプルをREADMEかドキュメントサイトの入口に置くと、「とりあえず試してみよう」というエンジニアが増えるかもしれません。
導入を検討するときのチェック観点
以下の観点を確認してから導入を判断すると、後から「思っていたものと違う」という状況を避けやすいです。
- Node.js 22以上とFFmpegが既に環境に入っているか、または入れる権限があるか
- AIエージェント（Claude Code、Cursor等）との組み合わせで使うのか、CLIを直接叩くのか
- 使うワークフローが
/product-launch-videoや/pr-to-videoなど特定のものに絞れているか（全Skills導入は後からでよい） - GSAPやCSSアニメーションの基礎知識がチームにあるか（エージェントに全部任せる場合は不要だが、検証時に役立つ）
- 出力がMP4であることで要件を満たせるか（インタラクティブなWebアニメーションとしての出力は別途対応が必要）
- Apache-2.0ライセンスで商用利用・社内利用が問題ないか
- HeyGen社のサービス依存（クラウドレンダリング等）を使わずにセルフホストできる範囲で用が足りるか
入口の選び方
HyperFramesは「HTMLで動画を書く」というシンプルなコンセプトの上に、エージェント向けの20本のSkill群と、複数の制作ワークフローを重ねた構造をしています。最初から全部を理解しようとすると量に圧倒されますが、/hyperframes ルーターSkillを起点にして必要なものだけを順に展開していくという使い方に沿えば、コンテキストの負荷は意外とコントロールできます。自分のプロジェクトで「エージェントに動画を作らせたい」というシナリオがあるなら、まずCLIでHello World相当の短い動画を1本作ってみることが、判断の出発点になるのではないでしょうか。
