動画生成の自動化にHyperFramesが選ばれる理由｜Remotionとの違い

動画制作を自動化したい、という要件は近年あちこちで立ち上がっています。ところが候補となるフレームワークを並べてみると、どれも「コードで動画を作れる」と書かれているだけで、本番の自動レンダリングパイプラインに載せる判断ができません。スター数の伸びは勢いを示しますが、採用可否の根拠にはなりません。

判断材料として本当に必要なのは別の軸です。コンポジションをどの形式で書くのか（HTML か、React コンポーネントか、独自 API か）。アニメーションをどのモデルで駆動するのか。ライセンスがチーム規模や商用利用の条件を満たすのか。レンダリングをどこで実行でき、分散時にどんな制約が付くのか。そして、リポジトリの API がまだ動く段階なのか安定した段階なのか。この 5 点が揃わないと、候補を残すか外すかをチームに説明できません。

HyperFrames は、こうした候補群のなかで「素の HTML を書いて、それを決定論的な MP4 にする」という一点に設計を寄せた OSS です。GitHub の heygen-com/hyperframes は 2026 年 10 月 5 日時点でスター 56,838、ライセンスは Apache-2.0、最終 push は同日と開発が継続しています。最も直接的な比較対象である Remotion とは、オーサリング形式・アニメーション駆動モデル・ライセンスという 3 つの軸で明確に分かれます。

本記事は、GitHub API で取得したリポジトリメタデータと、公式ドキュメント・README の記述を突き合わせて整理したものです。実行環境へのインストールや動作検証は行っておらず、公開ドキュメントに基づく机上の整理であることを先にお断りしておきます。記載した数値はすべて 2026 年 10 月 5 日時点の取得値です。

本記事では、HyperFrames の設計思想、コンポジションを記述する際の契約（data 属性と決定論の制約）、CLI とレンダリング経路の選択軸、エージェント連携の構成、そして公式が示す Remotion との差分と採用前に把握すべき制約を解説します。

HyperFramesとは｜HTMLで動画を定義するOSSの位置づけ

GitHub リポジトリ heygen-com/hyperframes の README は、HyperFrames を「HTML・CSS・メディア・シーク可能なアニメーションを、決定論的な MP4 動画に変換するためのオープンソースフレームワーク」と定義しています。リポジトリの description はさらに短く「Write HTML. Render video. Built for agents.」の 3 文です。HTML を書く、動画をレンダリングする、そしてそれはエージェントのために作られている、という優先順位がそのまま表れています。

GitHub API で取得した基本情報は次のとおりです。

※ 上記はすべて 2026 年 10 月 5 日時点の取得値です。

ここで先に押さえておきたいのは、このリポジトリはアーカイブされておらず、他リポジトリのフォークでもないという点です。動画生成の領域はフォークが派生しやすく、「どれが本流か」が見えにくくなりがちですが、heygen-com/hyperframes は本流のリポジトリとして単独で開発されています。最終 push とリリースがいずれも同日という点も、開発が止まっていないことを示しています。

利用形態は 3 通りが README に示されています。ローカルで CLI として使う、AI コーディングエージェントからスキル経由で使う、そしてホスト型オーサリングワークフローの背後にあるレンダリングコアとして使う、という使い分けです。ひとつのツールが「開発者向け CLI」と「エージェント向けの実行基盤」と「SaaS の内部エンジン」を兼ねる構成になっています。

開発元は HeyGen で、公式ドキュメントの Introduction によれば HeyGen 本体の製品内で本番利用されています。加えてコミュニティでの採用事例が ADOPTERS.md にまとめられており、tldraw や TanStack といった外部チームの名前が掲載されています。開発元が自社製品で使い、かつ社外チームも使っている、という二重の裏付けがある状態です。

なお本記事の記述はすべて、公開されている README・公式ドキュメント・GitHub API の取得値に基づいています。CLI のインストール、プレビューの起動、レンダリングの実行といった動作確認は行っていません。レンダリング品質や処理時間に関する数値は公式ドキュメントが示している範囲のみを引用し、それ以外は踏み込まずに整理しています。

動画生成の自動化でHyperFramesが解いている課題

HyperFrames の設計を理解する鍵は、「エージェントが書けるフォーマットは何か」という問いの立て方にあります。

README の「Why HyperFrames?」は、第一の理由として HTML-native であることを挙げ、コンポジションは data 属性付きの HTML ファイルであり、React も独自のタイムライン形式も不要だと述べています。続く Agent-friendly の項では、エージェントは既に HTML を書ける、という前提が示されています。これは設計上の賭けです。LLM の学習データにおいて HTML と CSS は圧倒的な分量を占めますが、特定フレームワークのコンポーネント記法はその一部にとどまります。動画のオーサリングをエージェントに任せたいなら、エージェントが最も慣れた言語で書けるようにするのが近道だ、という発想です。

もうひとつの設計上の選択は、出力の形です。公式ドキュメントの Introduction は、ユーザーが作りたい動画を自然言語で説明し、エージェントが HTML・CSS・JavaScript を含む編集可能なプロジェクトフォルダを生成する、という流れを示しています。結果が「潰された（flattened）ブラックボックス」ではなくフォルダであるため、エージェント・ブラウザ上のエディタ（Studio）・自作ツールが同じファイル群に対して協働できます。生成した動画が気に入らなかったときに、プロンプトを書き直して丸ごと再生成するしかないのか、該当するファイルを開いて直せるのか。この差は運用の自由度に直結します。

3 つめの柱が決定論です。README の Deterministic の項は、同一入力から同一フレーム、同一フレームから同一出力が得られると述べています。Introduction 側はこれを別の角度から説明しており、HyperFrames は再生に依存せず「正確なフレーム」をプロジェクトに要求するため、低速なマシンで実行してもフレーム落ちが起きない、としています。動画を手作業で書き出す用途ではこの性質の重みは伝わりにくいのですが、CI に組み込んで回帰テストしたい、スケジュール実行で毎日同じテンプレートから動画を量産したい、という用途では前提条件になります。実行環境の速度で出力が変わるパイプラインは、自動化の土台にはできません。

運用の軽さという観点では、ビルドステップが不要であることも挙げられています。index.html がそのまま再生でき、ブラウザで直接プレビューできる、というのが README の記述です。バンドラの設定や依存関係の解決という層が挟まらないため、生成されたプロジェクトをそのまま開いて確認できます。アニメーションについても、GSAP・CSS animations・Lottie・Three.js・Anime.js・WAAPI・自作ランタイムのいずれも持ち込めるアダプタ方式が採られています。

そして、HeyGen の OSS であることから生じやすい懸念に触れておきます。「結局はホスト型サービスへ誘導されて、レンダリングごとに課金されるのではないか」という懸念です。これについては 公式の Quickstart が明確に書いています。

HyperFrames is free and open-source, and local rendering does not use HeyGen credits. Your coding agent and any optional hosted, voice, avatar, or generated-media services may have their own costs.

ローカルレンダリングは HeyGen のクレジットを消費しません。一方で、コーディングエージェント自体の費用や、任意で使うホスト型・音声・アバター・生成メディア系サービスには個別の費用が発生しうる、という書き分けです。無償の範囲と有償になりうる範囲が公式に区切られているため、ここは判断材料として扱えます。

コンポジション契約の仕組み｜data属性とシーク型レンダリング

ここからは、採用した場合に「何を書かされるのか」を見ていきます。HyperFrames のコンポジションは data 属性付きの HTML ですが、その属性には明確な契約があり、守らないとレンダリングが成立しません。出典は 公式の HTML スキーマリファレンス です。学習コストを見積もるうえで、公式トップページだけでは見えないこの層を先に押さえておくと判断が早くなります。

コンポジションルートとクリップの必須属性

コンポジションのルート要素に必須なのは、一意な ID を与える data-composition-id、フレーム寸法を px で指定する data-width と data-height、そして最上位のルートにのみ必要な data-start="0" です。総レンダー長を指定する data-duration は、メディアやアニメーションから推論できる場合は省略できますが、Three.js を使う場合・終端のないアニメーションの場合・タイムラインを持たないコンポジションの場合には必要になります。タイムラインを登録しないコンポジションでは data-no-timeline を宣言しておくと、待機タイムアウトによる遅延を避けられます。

時間を持つクリップ側の必須属性は、タイミングと編集とアニメーションのための安定した識別子となる id と、開始時刻を秒数または相対タイミング式で与える data-start です。data-duration は DOM 要素とネストコンポジションでは必須で、画像は既定 3 秒、動画と音声はソース側の長さが使われます。class="clip" は必須ではなく推奨される慣例で、フルフレームのボックスレイアウトを与えます。

README の「How It Works」には、これらを使ったコンポジションの例が掲載されています。

<div id="stage" data-composition-id="launch" data-start="0" data-width="1920" data-height="1080">
  <video
    class="clip"
    data-start="0"
    data-duration="6"
    data-track-index="0"
    src="intro.mp4"
    muted
    playsinline
  ></video>

  <h1 id="title" class="clip" data-start="1" data-duration="4" data-track-index="1">Launch day</h1>

  <audio
    data-start="0"
    data-duration="6"
    data-track-index="2"
    data-volume="0.5"
    src="music.wav"
  ></audio>

  <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
  <script>
    const tl = gsap.timeline({ paused: true });
    tl.from("#title", { opacity: 0, y: 40, duration: 0.8 }, 1);
    window.__timelines = window.__timelines || {};
    window.__timelines.launch = tl;
  </script>
</div>

出典: https://github.com/heygen-com/hyperframes （README「How It Works」）

動画・見出し・音声が同じ HTML ツリーの中に並び、GSAP のタイムラインが <script> の中で組まれています。独自の DSL やタイムライン JSON を学ぶ必要はなく、普段書いているマークアップに時間軸の属性が加わっただけ、という構造です。

トラックは表示専用という落とし穴

上の例に data-track-index が出てきますが、この属性の意味は従来の動画編集ツールの常識とは異なります。公式リファレンスは、data-track-index は Studio のタイムライン上のレーンであり表示専用だと明記しています。レンダリングはこの値を一切読まず、クリップの重なりも防ぎません。

つまり、同じトラックインデックスを持つ 2 つのクリップは時間的に重なりえます。トラックはスケジューリングの制約ではなく、Studio の UI 上で整理するための行にすぎません。では描画順は何が決めるのかというと、CSS の z-index です。重ね順を制御したいときに触るのはトラック番号ではなく z-index だという点は、既存の動画編集ツールの感覚を持ち込むと確実に誤解する箇所です。

逆に言えば、重なりの制御を CSS に委ねている分、Web の作法をそのまま使えます。レイアウトとレイヤリングの知識が動画制作にそのまま転用できる、というのが HTML ネイティブであることの実利です。

メディア再生はフレームワークが所有する

メディア要素の扱いにも明確な禁止事項があります。公式リファレンスは、play() や pause() を呼ぶこと、currentTime を命令的に設定することを禁じています。再生の制御は HyperFrames 側が所有しているため、コンポジション側が割り込むとシークの前提が崩れます。

音声の扱いにも宣言の義務があります。時間を持つ動画要素はすべて、muted か data-has-audio="true" のいずれかを宣言する必要があります。音声を含む動画の場合は data-has-audio="true" が必要で、同時に muted にすることはできません。音声があるのかないのかをフレームワークに明示させる設計で、暗黙の推論に頼らない形になっています。

メディア固有の属性としては、ソース内のオフセットを指定する data-media-start、ランタイムや Studio 上のオフセットを指定する data-playback-start、0.1 から 10 の範囲で再生速度を指定する data-playback-rate、音量を指定する data-volume（1 が 0 dB、最大 3.98 が +12 dB に相当）、フェードを指定する data-fade-in と data-fade-out が用意されています。音量の上限がデシベル換算で示されている点からも、音声ミックスまで仕様として織り込まれていることがわかります。

決定論を成立させる3つの制約

決定論的なレンダリングは無条件に得られるものではなく、コンポジション側がいくつかの制約を守ることで成立します。公式リファレンスが挙げている条件は 3 つに整理できます。

第一に、タイムラインは有限であり、かつ { paused: true } の状態で作る必要があります。先の README の例でも gsap.timeline({ paused: true }) と書かれていました。自動再生させてしまうと、レンダラがシークする前にアニメーションが進んでしまいます。

第二に、タイムラインは window.__timelines にコンポジション ID をキーとして同期的に登録する必要があります。例では window.__timelines.launch = tl; の 1 行がこれに当たります。非同期に登録するとレンダラが登録前に走り出すため、同期であることが要件になっています。

第三に、壁時計時刻への依存、シードなしの乱数、無限リピートを避ける必要があります。Date.now() を参照するアニメーションや、Math.random() をシードなしで使う演出は、同じ入力から同じフレームを得るという前提を壊します。

この 3 点の背後にある役割分担は明快です。シークはフレームワークが制御し、コンポジション側は「任意の時点における視覚状態」を記述する責務だけを負います。「時間が進んだらこう動く」ではなく「この時刻ではこう見える」を書く、という発想の転換が必要になります。

契約の静的チェック手段も用意されています。公式の Core パッケージのドキュメントによれば、検証用に @hyperframes/lint パッケージがあり、Core 側は validateHyperframeHtmlContract() を公開しています。契約違反をレンダリング前に検出できるため、CI に組み込む際の足場になります。

ネストコンポジションと変数

テンプレート化して量産する用途のために、コンポジションの入れ子と変数の仕組みも用意されています。

ネストは、<div> に参照先のルート ID と一致する data-composition-id を与え、data-composition-src で別ファイルのコンポジションを指定する形で行います。あわせて data-start・data-duration・data-width・data-height・data-playback-start・data-variable-values を付与でき、中身のスタイルやスクリプトは <template> に格納します。

変数は data-composition-variables に JSON スキーマの配列として宣言し、data-var-text・data-var-src・CSS の var(--variableId) でバインドします。テキストを差し替える、画像のソースを差し替える、CSS の値を差し替える、という 3 経路が揃っているため、同一の構成で差分だけを変える動画の量産に向いた設計になっています。レイアウトは共通、テキストと素材だけ案件ごとに差し替える、という要件にはこの仕組みが素直に当たります。

CLIとレンダリング経路の選択軸｜ローカル・AWS Lambda・ホスト型

ローカルの開発ループと前提要件

実行環境の前提は README に明記されており、Node.js 22 以降と FFmpeg が必要です。バッジでも node >= 22 が示されています。FFmpeg が前提になっているのは、ヘッドレス Chrome が各フレームをシークして取得した画像を FFmpeg がエンコードする、というパイプライン構成に由来します。

ローカルでの開発ループは 3 コマンドです。

npx hyperframes init my-video
cd my-video
npx hyperframes preview      # preview in browser with live reload
npx hyperframes render       # render to MP4

出典: https://github.com/heygen-com/hyperframes （README「Manually with the CLI」）

init でプロジェクトを作成し、preview でライブリロード付きのブラウザプレビューを開き、render で MP4 に書き出す、という流れです。README の Stack 表には、CLI が担う機能として scaffold・preview・lint・inspect・render が挙げられています。あわせて lint や doctor、snapshot、publish といったサブコマンドの存在も示されており、契約違反の検出や環境の診断を CLI 側で完結できる構成になっています。CLI がデフォルトで非対話であることも README に明記されており、エージェントや CI から呼ぶ前提が最初から織り込まれています。

パッケージ構成と差し替えポイント

HyperFrames はモノレポとして複数パッケージに分割されています。README の Packages セクションに基づく構成は次のとおりです。

この分割は、採用時の組み込み方を考えるうえで重要です。自社のジョブ基盤から直接レンダリングを呼びたい場合は CLI を経由せず producer や engine を叩く選択肢があります。プレビュー UI だけを自社アプリに埋め込みたいなら player の Web コンポーネントが該当します。Studio をそのまま使うのか自作のエディタを被せるのかも分けて考えられます。レイヤーが明示されているため、「どこまで公式のものを使い、どこから自作するか」の線を引きやすい構成になっています。

AWS Lambda分散レンダリングのコストと制約

長尺や大量の動画をレンダリングする場合、ローカル実行では時間が足りません。公式の AWS Lambda レンダリングのドキュメントによれば、分散レンダリングは Step Functions のワークフローで並列のチャンクワーカーに処理を分散し、S3 をストレージとして経由する構成です。

コマンドは次のとおりです。

hyperframes lambda deploy [--stack-name] [--region] [--concurrency] [--memory]
hyperframes lambda render ./project --width 1920 --height 1080 --wait
hyperframes lambda progress <renderId>
hyperframes lambda destroy

出典: https://hyperframes.heygen.com/deploy/aws-lambda

加えて、プロジェクトを事前ステージングする sites create と、テンプレートのパーソナライズ向けの lambda render-batch も用意されています。

前提条件は、AWS の認証情報、deploy と destroy に必要な AWS SAM CLI、Lambda ハンドラの ZIP をビルドするための bun、@hyperframes/aws-lambda パッケージ、そして HyperFrames リポジトリのソースチェックアウト（別の場所からデプロイする場合は HYPERFRAMES_REPO_ROOT の設定）です。ローカル実行に比べて必要なものが一段増えます。デプロイ経路は CLI 経由・SAM 直接・AWS CDK の 3 通りがあり、生成されるインフラは同一だとされています。

コストについては、公式ドキュメントが Lambda の GB 秒（課金対象時間 × 設定メモリ）に、Step Functions の標準ワークフローにおける状態遷移ごとの少額な料金が加わると説明しています。掲載されているサンプル出力は、480 フレーム・Lambda 呼び出し 5 回のレンダリングで Lambda が $0.0210、Step Functions が $0.0004、合計 $0.0214 です。ただし S3 の転送料は含まれておらず、実際の支出は AWS の請求データで確認すべきだと注記されています。

採用判断に直結する制約は 4 点です。

• 完了 Webhook がありません。progress によるポーリング、または Step Functions を直接監視する必要があります
• 分散 AWS 経路は SDR のみです。HDR 出力は対象外です
• クロスリージョンのフェイルオーバーがありません。リージョンごとに独立してスタックをデプロイする必要があり、マルチリージョンのオーケストレーションは組み込まれていません
• テンプレート変数には 256 KiB の上限が効きます。Step Functions の実行入力の上限に由来します

Webhook がないという点は、既存のジョブ基盤に接続する設計に影響します。レンダリング完了をイベントで受け取る前提のアーキテクチャをすでに持っている場合、ポーリング層を自分で用意するか、Step Functions の状態変化を拾う仕組みを自前で足すことになります。

レンダリング経路を整理すると次のようになります。

Google Cloud Run については補足が必要です。この経路は 公式の HyperFrames と Remotion の比較ガイドに記載がありますが、README の Stack 表には列挙されていません。本記事では「公式の比較ガイドに記載がある」という位置づけに限定して言及します。採用を検討する場合は、公式ドキュメント側で現在の対応状況を確認してください。

エージェント連携の構成｜21個のスキルとルーター設計

HyperFrames の description にある「Built for agents」が具体的に何を指すのかを見ていきます。

スキルの導入方法と「コアセット」という考え方

README によれば、公開されているスキルは 21 個あります。重要なのはその入れ方です。/hyperframes がルーター兼ケイパビリティマップとして位置づけられており、まずこれを読む対象とされています。そのうえで、個別の作成ワークフローはオンデマンドで導入する構成です。

導入経路は 3 系統あります。

claude plugin marketplace add heygen-com/hyperframes
claude plugin install hyperframes@hyperframes

出典: https://github.com/heygen-com/hyperframes （README「Quick Start」）

Claude Code 向けにはプラグインとして追加し、/hyperframes:hyperframes から呼び出す形です。スタンドアロンのスキルとして入れる場合は npx skills add heygen-com/hyperframes、エージェントや非対話実行向けには npx hyperframes skills update が用意されており、後者はコアセットのみを main ブランチから導入します。

「全部入れない」という設計意図が README には明示されています。対話的なピッカーは何も事前選択せず、Core Skills だけで足りるとされています。一方、非対話実行で --skill を指定しなかった場合は 21 個すべてが導入されます。スキルの数が増えるとエージェントのコンテキストを圧迫するため、必要なものだけを読み込ませる前提になっています。また skills add は skills.sh のレジストリ上の blob を解決するため、main ブランチの最新から数時間遅れることがある、という注意も書かれています。最新の挙動を前提にする場合は hyperframes skills update 側を使う、という使い分けになります。

対応するエージェントとして README が挙げているのは、Claude Code・Codex・Cursor・Gemini CLI・IBM Bob・OpenCode などです。特定のエージェントに閉じない形で配布されています。なお、リポジトリの topics には mcp が含まれていますが、MCP 連携の詳細については公式ドキュメント上で確認できなかったため、本記事では断定を避けます。

作成ワークフローとドメインスキルの役割分担

21 個のスキルは、用途ベースの作成ワークフローと、能力ベースのドメインスキルに分かれています。

作成ワークフロー系のスキルは、作りたい動画の種類に対応しています。

一方、ドメインスキルはオンデマンドで読み込まれる原子的な能力です。/hyperframes-core・/hyperframes-animation・/hyperframes-keyframes・/hyperframes-creative・/hyperframes-cli・/hyperframes-audio・/hyperframes-registry・/media-use・/figma が該当します。アニメーションの付け方を知りたいときに -animation を、音声の扱いを知りたいときに -audio を、という形で必要な知識だけを引き込む設計です。

ここで /remotion-to-hyperframes について注意が必要です。README はこれを Remotion からの一方向の移行専用であり、新規作成用ではないと明記しています。既存の Remotion プロジェクトを持ち込む経路としては使えますが、新しく動画を作る目的で呼ぶものではありません。

frame.mdとカタログによる再現性の担保

エージェントに動画を作らせるうえで課題になるのは、スケール感の推測です。Web 向けのデザイン仕様をそのまま持ち込むと、画面で見る前提のフォントサイズや余白が動画では小さすぎる、といったずれが生じます。

HyperFrames はこの問題に frame.md という仕組みで対応しています。README の Stack 表はこれを、デザインシステムを「カメラ向け」に反転させた DESIGN.md のスーパーセットと説明しています。Web 文脈のデザイン仕様を動画文脈に読み替えた記述を置くことで、エージェントがスケールを推測せずに動画を構成できるようにする、という狙いです。関連するデザインテンプレートは hyperframes.dev のデザインページで公開されています。

もうひとつの再現性の担保がカタログです。既製のブロックを組み込む形で、トランジション・ソーシャルオーバーレイ・アニメーション付きチャートなどを追加できます。

npx hyperframes add flash-through-white   # shader transition
npx hyperframes add instagram-follow      # social overlay
npx hyperframes add data-chart            # animated chart

出典: https://github.com/heygen-com/hyperframes （README「Catalog」）

README の Stack 表は、カタログの収録範囲としてトランジション・オーバーレイ・キャプション・チャート・マップ・エフェクトを挙げています。各ブロックの仕様は 公式のカタログページで確認できます。エージェントに一から作らせるのではなく、検証済みのブロックを組み合わせさせることで、出力のばらつきを抑える設計です。

HyperFramesとRemotionの違い｜類似OSSとの選定比較

Remotionとの差分3軸

HyperFrames と Remotion は対立する存在ではありません。README は「HyperFrames is inspired by Remotion」と明記しており、公式の比較ガイドも用意されています。技術的な土台も共通しており、どちらもヘッドレス Chrome でフレームを取得し FFmpeg でエンコードします。

その上で、差分は 3 つの軸に整理できます。いずれも公式の比較ガイドに基づきます。

1 つめはオーサリング形式です。 HyperFrames は HTML・CSS・JavaScript（GSAP のタイムラインを含む）を 1 ファイルで書きます。Remotion は TypeScript で書かれた React コンポーネントを要求し、ビルドステップとコンポーネントアーキテクチャが前提になります。この差は、既存資産の持ち込みやすさに直結します。すでに HTML と CSS で作ったアニメーションがあるなら前者が素直で、React のコンポーネントライブラリとデザインシステムを持っているなら後者が素直です。エージェントに引き渡す場合も、プレーンな HTML を渡すのか JSX のプロジェクト構造を渡すのかで前提が変わります。

2 つめはアニメーションの駆動モデルです。 ここが最も根本的な違いです。公式ガイドの表現を借りると、HyperFrames は「時計を見るのではなくアニメーションを駆動する」モデルで、アニメーションを一時停止させ、正確な時刻へシークしてからフレームを取得します。Remotion はフレーム番号を読んで値を計算するモデルで、タイミングの計算を開発者側が扱います。

この違いが実利として効くのは、既存のブラウザランタイムを使うときです。シークモデルであれば、GSAP・WAAPI・Lottie といったブラウザ上のアニメーションランタイムを、そのまま決定論的に描画できます。それぞれのランタイムの内部実装をフレーム番号ベースに書き換える必要がありません。逆に、フレーム番号から値を計算する単純さを好むなら Remotion のモデルのほうが見通しが良い場面もあります。

3 つめはライセンスです。 HyperFrames は Apache-2.0 で、公式ガイドは「Apache 2.0 はシート数のカウントもライセンスレビューも不要」と述べています。Remotion は独自のモデルで、個人および 3 人までの企業は無償、それを超える場合は有償です（Remotion 公式サイト）。チーム規模が一定を超える組織では、この差が実務上の判断を左右します。

公式ガイドは選定指針も明示しています。既存の HTML・Web 素材がある場合、ビルド基盤を持ちたくない場合、AI エージェントによるオーサリングを使いたい場合、シート制限のないオープンライセンスが必要な場合は HyperFrames を選ぶ。チームがすでに React を使っている場合、本番での実績の長さが必要な場合、成熟した Lambda インフラが必要な場合、既存のコンポーネントライブラリとデザインシステムを活かせる場合は Remotion を選ぶ、という整理です。

移行については前述のとおり、/remotion-to-hyperframes が Remotion からの一方向の移行専用スキルとして用意されています。

Motion Canvas・Revideoとの棲み分け

「コードで動画を作る」という領域には、Remotion 以外にも別のアプローチをとるプロジェクトがあります。GitHub API で 2026 年 10 月 5 日に取得した値を並べると次のようになります。

※ スター数・最終 push は 2026 年 10 月 5 日時点の取得値です。redotvideo/revideo は midrender/revideo にリダイレクトされるため、後者を正式表記としています。

Motion Canvas は、独自の TypeScript ジェネレータ API で解説アニメーションを作る方向性のプロジェクトです。インタラクティブなエディタを備え、技術解説やチュートリアル映像の制作に強みがあります。一方で、既存の HTML 資産を持ち込むことやエージェントによるオーサリングは射程外で、最終 push も 2026 年 7 月 2 日です。

Revideo は Motion Canvas から派生し、サーバーサイドでの動画生成に寄せたプロジェクトです。方向性としては HyperFrames と重なる部分がありますが、スター数 4,082 と規模が小さく、最終 push も 2026 年 7 月 15 日です。本番パイプラインの選定候補として HyperFrames や Remotion と同列に並べるのは、規模と更新頻度の両面で慎重に判断すべき段階と見られます。

結論として、HyperFrames の直接的な比較対象は Remotion です。Motion Canvas と Revideo は「コードで動画」という括りでは隣接しますが、HTML をオーサリング形式にしていない点で性質が異なります。

どちらを選ぶかの判断フロー

ここまでの差分を、判断の順番として整理します。上から順に答えていくと、候補が絞れます。

1. React 資産があるか — 動画ロジックを React コンポーネントで組みたい、既存のデザインシステムを流用したいなら Remotion。HTML と CSS のアニメーション資産があるなら HyperFrames
2. ライセンス制約があるか — チームが 3 人を超え、シート課金やライセンスレビューを避けたいなら Apache-2.0 の HyperFrames。予算上の制約がなければこの軸は判断から外せます
3. 主体はエージェントか人間か — エージェントに動画制作を任せたいなら、スキル体系と非対話 CLI を前提にしている HyperFrames。人間が書くことが前提ならどちらでも成立します
4. 分散レンダリングの要件は何か — HDR 出力が必要なら HyperFrames の分散 AWS 経路は適用できません。完了通知をイベントで受け取る必要があるなら、ポーリング層を自作する前提になります
5. 安定版 API が必要か — 後述の成熟度の論点に関わります。長期保守の計画を安定した API の上に立てたいなら、1.0 に到達していない 0.8 系であることを織り込む必要があります

HyperFrames採用前に確認すべき制約とチェックリスト

ここまでは設計と差分を見てきました。最後に、採用判断の前に把握しておくべき制約を整理します。

成熟度とメンテナンス状況の読み方

まず成熟度です。最新リリースは v0.8.127 で、メジャーバージョン 1.0 に到達していません。公開は 2026 年 3 月 10 日で、2026 年 10 月 5 日時点で約 7 か月が経過しています。この期間にパッチ番号が 127 まで進んでいるのは、リリース頻度が極端に高いことを意味します。

この数字は両方向に読めます。活発に開発されている証拠である一方、0.8 系であること自体が API 変更の可能性を示しています。長期保守の計画を立てる段階では、バージョンを固定して追従方針を決めるなどの備えが必要です。open issues は 161 件あります。

一方、メンテナンス状況の健全性を支える根拠は複数あります。

• 最終 push が 2026 年 10 月 5 日、最新リリースも同日で、開発が止まっていません
• archived と fork がいずれも false で、本流のリポジトリとして単独で開発されています
• 開発元の HeyGen が自社製品内で本番利用しています（公式ドキュメント Introduction）
• 外部チームの採用事例が ADOPTERS.md に掲載されており、tldraw や TanStack の名前が挙がっています
• Discord・GitHub Issues・SECURITY.md・CONTRIBUTING.md が整備されており、報告と貢献の窓口が明示されています

「開発元が自社で使っている」と「社外のチームも使っている」が両方揃っているプロジェクトは、片方だけのプロジェクトより継続性の見通しが立ちます。成熟度（0.8 系）と活動量（日次のリリース）を分けて評価するのが、この種のリポジトリの読み方になります。

運用前提と機能上の制約

採用時に設計へ影響する制約を列挙します。

実行環境の前提 — Node.js 22 以降と FFmpeg が必要です（README）。AWS Lambda 経路を使う場合は、加えて AWS の認証情報・AWS SAM CLI・bun が必要になります。CI ランナーのイメージに FFmpeg が含まれているか、bun を入れられるかは事前に確認が必要な項目です。

分散レンダリングは SDR のみ — HDR 出力が要件に含まれるパイプラインには、分散 AWS 経路を適用できません。

完了 Webhook がない — lambda progress によるポーリング、または Step Functions の直接監視が必要です。イベント駆動のジョブ基盤と接続する場合は、変換層を自前で用意することになります。

クロスリージョンのフェイルオーバーがない — リージョンごとに独立したスタックのデプロイが必要です。

テンプレート変数は 256 KiB まで — Step Functions の実行入力の上限に由来します。大量のデータを変数として渡す設計では、S3 経由などの別経路を検討する必要があります。

Git LFS が約 240 MB — README の Development Note によれば、packages/producer/tests/**/output.mp4 のゴールデン回帰ベースラインに Git LFS（約 240 MB の MP4）が使われています。フルクローンには git lfs install が前提です。CI でソースのみが必要な場合は GIT_LFS_SKIP_SMUDGE=1 を付けて LFS をスキップできます。Lambda デプロイにリポジトリのチェックアウトが必要であることと併せて、CI のクローン設定に影響します。

ライセンスと課金の切り分け — ライセンスは Apache-2.0 で、商用利用のしきい値やシート数の制限はありません。ローカルレンダリングは HeyGen のクレジットを消費しません。一方で、HeyGen のホスト型クラウドレンダリングを使う場合はホスト型サービス側の条件が別途発生します。また Quickstart が注記しているとおり、コーディングエージェント自体の費用や、任意で使う音声・アバター・生成メディア系サービスの費用は別勘定です。「OSS だから無償」で止めず、どの経路を使うかで費用の発生箇所が変わる点を押さえておく必要があります。

向くケース・向かないケース

以上を踏まえると、適合する条件は次のように整理できます。

向くケース

• 既存の HTML・CSS によるアニメーション資産があり、それを動画に転用したい
• エージェントに動画制作を任せたい、または非対話の自動レンダリングを前提にしたい
• CI に組み込んで動画出力の回帰テストをしたい（決定論的レンダリングが前提条件を満たす）
• チーム規模が大きく、シート課金やライセンスレビューを避けたい
• テンプレート化して差分だけ変える動画を量産したい（ネストコンポジションと変数が該当）

向かないケース

• 動画ロジックを React コンポーネントとして組みたい、既存の React デザインシステムを活かしたい
• HDR 出力を分散レンダリングで行う要件がある
• 安定版 API を前提に長期の保守計画を立てる必要がある（0.8 系であり API 変更の可能性がある）
• レンダリング完了を Webhook で受け取る設計を変えられない

最後に、本記事の限界を明示しておきます。本記事は公開ドキュメント・README・GitHub API の取得値に基づく整理であり、実行環境での動作検証は行っていません。レンダリング品質・処理時間・大規模運用時の挙動については公式ドキュメントが示している範囲を超えて言及していません。採用を判断する段階では、自プロジェクトの素材と要件で小さく検証することをおすすめします。

まとめ｜HyperFramesをどう位置づけるか

HyperFrames は、HTML オーサリング・シーク型の決定論的レンダリング・Apache-2.0 ライセンスという 3 点に設計を寄せた動画レンダリングフレームワークです。2026 年 10 月 5 日時点でスター 56,838、フォーク 5,101、主要言語は TypeScript、最終 push は同日で、アーカイブもフォークもされていません。開発元の HeyGen が自社製品で本番利用し、ADOPTERS.md には外部チームの採用も掲載されています。

Remotion との関係は、択一ではなく前提の違いによる分岐です。React 資産とデザインシステムを持っているチームには Remotion のモデルが素直で、HTML と CSS の資産がありエージェントに制作を任せたいチームには HyperFrames が素直です。チーム規模が 3 人を超える場合はライセンスがもう一つの分岐点になります。機能表を突き合わせる前に、この 2〜3 の分岐を自チームの前提に当てて答えるほうが判断は速く進みます。

同時に、0.8 系で 1.0 に到達していないこと、分散レンダリングが SDR のみで完了 Webhook を持たないことは、本番パイプラインの設計に直接影響します。活動量の多さと API の安定性は別の指標として評価するのが妥当です。

次の一歩としては、Quickstart で前提と無償範囲を確認し、HTML スキーマリファレンスで書き方の契約を把握し、HyperFrames と Remotion の比較ガイドで公式の選定指針に当たる順序が効率的です。実際の出力イメージは Showcase で確認できます。

関連情報

動画生成の自動化パイプラインの設計や、OSS を前提とした開発体制の整備をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。