2026/04/28Claude Code

ツール比較AI活用AIエージェント

HyperFramesとは？使い方・料金・Remotionとの違いまで徹底解説【2026年版】

「HyperFramesって結局どういうツールなの？」「HTMLで動画が作れるらしいけど、料金はかかるの？」「Remotionから乗り換える価値はある？」——2026年に入ってAI動画まわりのオープンソースが一気に増えたことで、こうした疑問を持つ方が増えました。

結論から言うと、HyperFramesはHeyGenが公開したApache 2.0のオープンソースで、HTMLとCSSで書いた内容をそのままMP4に書き出すレンダリングフレームワークです。ライセンス料は無料、席数上限もレンダー課金もありません。同時期に公開されたBrowser-Useのvideo-useとよく並べて語られますが、こちらは「撮影済み素材を編集して仕上げる」側で、そもそも役割が違います。

株式会社Fyveは受託開発でAI活用の実装を担当しており、過去にはクライアント向けのPR動画案件も手がけてきました。本記事では、HyperFramesとは何か・使い方・料金・Remotionとの違いを実装目線で整理したうえで、video-useとの使い分けまで通しで解説します（2026年8月時点の情報です）。

結論：HyperFramesは「合成」、video-useは「編集」

はじめに全体像を書きます。この2つを同じ土俵で比較しようとすると本質を見誤ります。立ち位置で言えばこうなります。

HyperFrames：HTMLとCSSで動画を「組み立てる」ためのレンダリングフレームワーク。ゼロから合成的に動画を生成する用途。プロダクト紹介、データ可視化、ソーシャル動画、Webサイトを動画化するなど、ジェネレーティブな動画制作が主戦場
video-use：撮影済みの素材フォルダを与えると、完成品のfinal.mp4を返してくる「編集スキル」。トーキングヘッド、モンタージュ、チュートリアル、トラベル、インタビューなど、実写ベースの編集作業が主戦場

つまり、HyperFramesは「合成（generative）」、video-useは「編集（cutting）」というのが最も粗い差分です。これを踏まえた上で、まずHyperFrames単体の中身を詳しく見ていきます。

HyperFramesとは：HTMLで動画を書くレンダリングフレームワーク

キャッチコピーと開発元

HyperFramesの公式メッセージは「Write HTML. Render video. Built for agents.」。AIアバター動画SaaSで知られるHeyGenが公開したオープンソースで、ライセンスはApache 2.0です。リポジトリはheygen-com/hyperframesで公開されています。

公式ドキュメントでは「HTML、CSS、メディア、シーク可能なアニメーションを、決定的なMP4に変換するオープンソースのフレームワーク」と定義されています。ローカルのCLIから使うことも、AIコーディングエージェントからスキル経由で使うことも、ホスティングされた制作ワークフローのレンダリングエンジンとして組み込むこともできます。

HeyGen本体（アバター動画SaaS）との関係

ここは検索してたどり着いた方が最初につまずくポイントなので先に整理します。HeyGenは有料のAIアバター動画SaaSですが、HyperFramesはそれとは別の、単体で完結するオープンソースです。

公式のクイックスタートには「HyperFramesは無料のオープンソースであり、ローカルでのレンダリングはHeyGenのクレジットを消費しない」と明記されています。HeyGenのアカウントを持っていなくても、手元のマシンにNode.jsとFFmpegさえあれば動きます。

逆に言えば、HeyGen側のホスティングサービスや、音声・アバター・生成メディアといったオプションを使う場合には別途費用が発生します。この線引きは後述の「料金」の節で詳しく扱います。

設計思想

核は4つあります。

HTMLネイティブ：作成物の一次形式はReactコンポーネントではなくHTML。「エージェントはすでにHTMLを話す」という前提に立ち、ビルドステップを排しています
確定的レンダリング：同じ入力からは常に同じMP4が出る。CIに乗せる前提の作りで、回帰テスト用にGit LFS経由で参照MP4をホストしています
Frame Adapterパターン：アニメーションランタイム（GSAP / Lottie / CSS / Three.js）を差し替え可能。フレーム精度でシークできるライブラリを選べる
AI優先：CLIは非対話型がデフォルト。Claude Code、Cursor、Gemini CLI、Codexといったコーディングエージェントから呼ばれる前提で設計されています

技術スタックと動作要件

言語：TypeScript中心
キャプチャ：Puppeteerでブラウザを動かしてフレームを撮り、FFmpegでエンコード
シェーダー：WebGLによる遷移エフェクト
動作要件：Node.js 22以上、FFmpeg。開発時（回帰テストのゴールデンMP4を取得する場合）はGit LFSも必要

Git LFSの導入コマンドは公式READMEに主要OS分が記載されています。macOSはbrew install git-lfs、Ubuntu / Debianはsudo apt install git-lfs、Windowsはwinget install GitHub.GitLFSです。Windows向けの手順が公式に用意されている点は、社内の実務環境がWindows中心の企業にとって判断材料になります。

パッケージ構成

モノレポで以下のように役割が分かれています。

hyperframes：CLI本体（作成・プレビュー・リント・レンダリング）
@hyperframes/core：型・パーサ・ランタイム・リンター・アダプタ
@hyperframes/engine：Puppeteer + FFmpegのキャプチャエンジン
@hyperframes/producer：レンダリングのフルパイプライン
@hyperframes/studio：ブラウザ上の編集UI
@hyperframes/player：埋め込み可能なWebコンポーネント
@hyperframes/shader-transitions：WebGLシェーダー遷移集
@hyperframes/sdk：アプリケーションからコンポジションを編集するSDK
@hyperframes/aws-lambda：Lambdaレンダリング用SDK

この構成が示しているのは、「CLIで手元で使う」から「自社サービスのレンダリング基盤として組み込む」までを1つのプロジェクトでカバーしようとしているということです。後述するレンダリング先の選択肢の広さも、このパッケージ分割に対応しています。

HTMLスキーマ：data属性で時間軸を表現

HyperFramesの肝はHTMLのdata属性に時間情報を載せることです。例えば次のように書きます。

data-composition-id：構成のID
data-start：要素が出現するフレーム/時刻
data-duration：表示の継続時間
data-track-index：トラックの重なり順
data-width / data-height：ステージサイズ（例: 1920×1080）
data-volume：オーディオの音量（0.0〜1.0）

つまり、CSSやGSAPで見た目を作り、data属性で「いつ、どこに、どのレイヤーで」を宣言するだけ。タイムラインUIを提供する代わりに、HTMLそのものをタイムラインにしてしまったわけです。これは「LLMがHTMLを書けるなら、LLMが動画を書けるはず」という発想の徹底に他なりません。

得意な動画タイプ

プロダクト紹介動画（フェードイン、背景動画、ナレーション）
データ可視化（アニメーション付きチャート、バーチャートレース）
ソーシャル動画（縦9:16、キャプション同期）
Webサイトの動画化（URLからの自動生成スキルあり）
Remotion資産の移行（HTML構成への翻訳ガイドあり）

カタログ（Catalog）に登録された部品はnpx hyperframes add <name> で追加でき、オーバーレイやシェーダー遷移、データチャートを部品単位で組み込めます。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

HyperFramesの使い方：インストールから最初のMP4まで

ここからは実際の手順です。前提として必要なのはNode.js 22以上とFFmpegの2つだけで、専用のインストーラーやアカウント登録はありません。

手順1：プロジェクトを作る

まず作業フォルダでプロジェクトを初期化します。

npx hyperframes init my-video：新規プロジェクトを作成する
cd my-video：作成されたフォルダに移動する

この時点で、HTMLファイルとアセットを含んだ雛形が展開されます。npm installやビルドステップは挟みません。HTMLがそのまま作品の一次形式なので、エディタで開けば中身をすぐに読めます。

手順2：ブラウザでプレビューする

プロジェクトフォルダ内で次を実行します。

npx hyperframes preview：ローカルのプレビュー（Studio）をブラウザで開く

ライブリロードが効くので、HTMLやCSSを書き換えると即座に反映されます。ここで開くのが後述のHyperFrames Studioで、タイムラインやキャプションをGUIで編集することもできます。

手順3：MP4に書き出す

仕上がりを確認したら書き出します。

npx hyperframes render --output video.mp4：MP4を生成する

ここでPuppeteerがフレームを進めながらスクリーンショットを取り、FFmpegがエンコードします。同じ入力からは同じMP4が出る決定的レンダリングなので、CIに組み込んで「毎週の数値レポート動画を自動生成する」といった使い方が成立します。

コーディングエージェントに作らせる場合

HyperFramesの本領はここです。Claude CodeやCodexなどのエージェントにスキルを入れておけば、HTMLを自分で書かずに動画を作らせられます。

npx skills add heygen-com/hyperframes --full-depth：スキルを導入する（選択画面では「Core Skills」を選ぶ）
npx hyperframes skills update：非対話環境・CI向けの導入／更新
npx hyperframes skills check：導入済みスキルが最新かを確認する
npx hyperframes skills update pr-to-video：特定のワークフローだけを追加する

導入後は、エージェントに対して/hyperframes を起点に依頼します。公式クイックスタートに載っている依頼文はこの形式です。

Using /hyperframes, make a 10-second product intro for https://example.com.

/hyperframes はルーターとして動き、依頼の種類（プロダクトサイト、GitHubのプルリクエスト、Figmaファイルなど）に応じて適切なワークフローを選びます。エージェント側の対応状況としては、公式READMEがClaude Code・Cursor・Gemini CLI・Codexおよびスキルに対応するコーディングエージェントを挙げており、ドキュメントにはGoogle AntigravityとGitHub Copilot CLI向けの個別手順も用意されています。

CLIコマンド早見表

公式のCLIガイドに掲載されている主なコマンドです。「動画を作る」以外に検査系・調査系が厚いのが特徴で、これはエージェントが自分で結果を確認できるようにするための設計です。

npx hyperframes init my-video：新規プロジェクトを作る
npx hyperframes preview：Studioを開く
npx hyperframes lint：HTML構造を検証する
npx hyperframes check：ブラウザ・レイアウト・モーション・コントラストを点検する
npx hyperframes snapshot --at 0,2,5：指定した時点のレビュー用フレームを書き出す
npx hyperframes render --output output.mp4：動画ファイルを生成する
npx hyperframes publish：共有可能なブラウザリンクを作る
npx hyperframes doctor：マシン側の構成を診断する
npx hyperframes info：プロジェクトのメタデータを確認する
npx hyperframes transcribe <file>：音声を文字起こしする
npx hyperframes tts <script>：台本からナレーションを生成する
npx hyperframes capture <url>：Webサイトの内容をキャプチャする
npx hyperframes add <name>：カタログの部品を追加する
npx hyperframes compositions：コンポジションの一覧を出す
npx hyperframes keyframes：キーフレームの挙動を確認する
npx hyperframes compare v1/ v2/：バージョン間を比較する

各コマンドのフラグはnpx hyperframes <command> --help で確認できます。lint check snapshot compare が揃っているのは、人間が目視する代わりにエージェントが自己点検するためです。GUIの動画編集ソフトをAIに操作させるのが難しい理由が「画面を見ないと判断できない」ことだとすれば、HyperFramesはその判断材料をコマンドの出力として提供している、という整理ができます。

HyperFrames Studio：プレビューがそのまま編集画面になる

npx hyperframes preview で開くStudioは、単なる再生プレビューではなく編集UIです。公式ドキュメントには以下の操作が項目立てされています。

ストーリーボード：構成全体の流れを俯瞰して確認する
キャンバス：フレーム内の要素を直接編集する
タイムライン：各要素の開始・長さを調整する
アニメーション / キーフレーム：動きの付き方を編集する
キャプション：字幕を編集する
アセットとカタログ：素材と部品を管理する
変数とテンプレート：差し替え可能な項目を定義する
スライドショー：連続表示のパターンを組む
エクスポート：書き出しとレンダー履歴を管理する

実務目線で重要なのは「変数とテンプレート」です。ここを設計しておくと、同じ構成のまま文言・数値・画像だけを差し替えた動画を量産できます。月次レポート動画、商品ごとの紹介動画、担当者ごとの挨拶動画といった「型は同じで中身だけ違う」案件は中小企業の現場に多く、ここが自動化の効きどころになります。

もう一点、Studioがあることの意味は非エンジニアが最終確認に入れることです。HTMLで組んだ動画を、社内の非エンジニアがブラウザ上でテロップの誤字だけ直して書き出す、という分業が成立します。コードを書ける人がボトルネックにならない構造を作れるかどうかは、受託でも社内利用でも運用コストに直結します。

HyperFramesの料金：無料で使えるが、費用が発生するのはどこか

「hyperframes 料金」で検索される方が一定数いるので、ここは明確に整理します。

HyperFrames本体は無料

HyperFramesはApache 2.0ライセンスのオープンソースです。自己ホスティング・改変・再配布・あらゆる規模での商用利用が認められており、レンダー単位の課金も席数上限もありません。個人プロジェクトでも、数人のスタートアップでも、大企業でも、条件は同じです。

加えて公式クイックスタートには「ローカルでのレンダリングはHeyGenのクレジットを消費しない」と書かれています。手元のマシンで完結する限り、支払いは発生しません。

費用が発生しうる3つの場所

一方で、実務投入すると次のところにコストが乗ります。ここを見落とすと試算がずれます。

ホスティングされたレンダリング：HyperFrames Cloudのようなマネージド環境を使う場合。ローカルにChromeやFFmpegを持たずに済む代わりに、サービス側の費用がかかります
音声・アバター・生成メディア：公式が「オプションのホスティングサービス、音声、アバター、生成メディアには別途費用が発生する可能性がある」と明記しています。tts や transcribe の裏側で外部サービスを使う場合はその分の料金です
自社クラウドの実行費用：AWS LambdaやGoogle Cloud Runで分散レンダリングする場合、HyperFramesは無料でもクラウド側の実行費用とストレージ費用は自社負担です

つまり「フレームワークの利用料はゼロ、外に出した処理の分だけ実費」という構造です。長尺・大量本数を回す計画があるなら、レンダリングをどこで走らせるかを先に決めてから試算するのが正しい順序になります。

HyperFrames vs Remotion：書き方・レンダリング方式・ライセンスの違い

HyperFramesを検討する方の多くが、比較対象としてRemotionを挙げます。Remotionは「Reactで動画を作る」分野で長く使われてきた実績のあるライブラリです。公式ドキュメントにもHyperFrames vs Remotionの比較ガイドが用意されているので、そこに書かれている内容を軸に整理します。

違い1：書き方（HTML/CSS/JS か、React/TypeScript か）

HyperFramesはHTML・CSS・JavaScriptとGSAPのタイムラインで書きます。RemotionはReactコンポーネントとして書き直す必要があります。公式の表現では、既存のWeb素材はHyperFramesなら「たいていほぼそのまま持ち込める」のに対し、Remotionでは「Reactコンポーネントとして書き直す」ことになります。

ここは既存資産の性質で決まります。コーポレートサイトをNext.jsとGSAPで作っているなら、そのモーションをHyperFramesへ持ち込むのは自然です。逆にすでにReactのデザインシステムとコンポーネント群がある組織では、Remotionのほうが翻訳のコストが小さくなります。

違い2：レンダリング方式（シークか、フレーム番号か）

ここが最も技術的に本質的な差です。

HyperFrames：アニメーションを一時停止し、指定した瞬間へシーク（正確な時点へジャンプ）させてからフレームをキャプチャする
Remotion：コードがフレーム番号を読み取り、そのフレームにおける値を返す

結果としてどちらも決定的なレンダリングになりますが、アプローチが逆向きです。HyperFramesは「既存のアニメーションを外から止めて撮る」、Remotionは「フレーム番号を入力に値を計算する」。前者はGSAPやLottieなどシーク可能なライブラリの資産をそのまま活かせる一方、後者はアニメーションのロジック自体をコードで書き下す前提になります。

違い3：ライセンスと費用

企業導入ではここが決め手になることが多い項目です。

HyperFrames：Apache 2.0。席数のカウントもライセンス審査もありません
Remotion：個人、従業員3人以下の営利組織、非営利組織は無料。従業員4人以上の営利企業は有償のCompany Licenseが必要です

Remotionの有償プランは公式サイトに掲載されており、2026年8月時点では「Remotion for Creators」が1シートあたり月額25ドル、「Remotion for Automators」がレンダーあたり0.01ドル・月額100ドルの最低利用額、Enterprise Licenseが月額500ドルからという構成です。最新の条件はRemotion公式のライセンスページで確認してください。

従業員4人以上の企業が動画生成をプロダクトに組み込むなら、Remotionでは本数に比例した費用が発生します。HyperFramesにはその区分がないため、「何本作っても追加のライセンス費用が出ない」ことに価値がある用途では差が大きくなります。ここが、HyperFramesが企業利用の選択肢として話題になった主因です。

違い4：エコシステムの成熟度

公式ドキュメントはこの点を正直に書いています。「Remotionのほうが古く、はるかに確立している。テンプレートも、チュートリアルも、回答済みの質問も、本番運用の歴史もはるかに多い」。

これは実務では無視できない差です。詰まったときに検索して解決策が見つかるかどうかは、導入初期の工数を左右します。安定性と情報量を優先するならRemotion、ライセンスの自由度とエージェント連携を優先するならHyperFrames、という整理が2026年8月時点では妥当です。

Remotionからの移行はできるのか

公式に移行用のスキルが用意されています。useCurrentFrame と interpolate をHyperFramesのタイムラインのトゥイーンに対応づける仕組みで、公式の説明では典型的なコンポジションのおよそ80%は機械的に変換され、残りの20%は誤変換せずにフラグを立てるとされています。

裏を返せば、2割は人が判断して書き直す前提です。「スイッチひとつで移行完了」ではないので、資産の規模が大きい場合は小さな1本で試してから判断するのが安全です。

レンダリング先の選択肢：ローカルからクラウドまで

公開当初のHyperFramesは分散レンダリングの手段を持っていませんでしたが、2026年8月時点ではローカルから自社クラウドまで複数の実行先が用意されています。公式ドキュメントの整理は次のとおりです。

CLI（ローカル / CI）：人またはCIジョブが起点になる場合。制作中のレンダリングはここ
Producer（Nodeアプリ）：バックエンドから入力を渡し、進捗の受信・キャンセル・エンコード制御をCLIを起動せずに行いたい場合
Engine（フレーム単位）：独自のキャプチャ・検査・レンダリング基盤を作る場合
HyperFrames Cloud（マネージド）：ローカルにChromeやFFmpegを持たずにレンダリングしたい場合
AWS Lambda / Google Cloud Run：レンダリングを自社のクラウドアカウント内で走らせる必要がある場合。どちらもワーカーへ分散し、メディアの保存も自社クラウド内で完結します
ホステッドテンプレート：Vercel・Cloudflare・Modal上に小さなプレビューアプリとレンダーAPIを立てる場合

公式の指針は「仕事を完了できる最も高レベルの層を選ぶ」（CLI → Producer → Engine の順に降りる）で、クラウドの選択はあくまでパイプラインをどこで実行するかの話だとしています。

実務判断としては、まずCLIで手元レンダリングから始めて構いません。本数が増えて所要時間が問題になった段階で、Lambda / Cloud Runへ持っていくかマネージドに寄せるかを決める、という順番が無駄がありません。最初からクラウド前提で設計すると、動画1本作る前にインフラ構築で止まります。

video-useとは：素材フォルダに対話するだけで完成品が出る編集スキル

キャッチコピーと開発元

video-useはBrowser-Useチームが公開したオープンソース。Browser-Useは「LLMでブラウザを操作する」分野の代表格で、video-useはその思想を動画編集に持ち込んだものです。提供形態はClaude CodeのSkillとして動作することが前提で、Claude本体に組み込んで使います。

設計思想：5つの柱

テキスト＋オンデマンド可視化：LLMに動画を全フレーム読ませない。文字起こしを軸に判断し、必要なときだけタイムラインビューのPNGを生成して目視代わりにする
オーディオ主体・映像従属：話している内容を最初に確定し、映像はそのカット境界に従う
確認→実行→自己評価→保存：レンダリング後にもう一度自分で見直すループを内蔵
コンテンツタイプへの先入観なし：トーキングヘッドだろうがトラベル動画だろうが、メニューやプリセットを切り替えない
12の厳格ルール＋表現の自由：プロダクションとして守るべき制約は固定し、それ以外は自由

技術スタック

言語：Python中心
文字起こし：ElevenLabs Scribe APIで単語レベルのタイムスタンプを取得
動画処理：FFmpeg
素材取得：yt-dlp（YouTube等から素材を引っ張れる）
アニメーション：Manim、Remotion、PIL
必要なAPIキー：ElevenLabs（必須）

パイプライン

文字起こし：単語レベルのタイムスタンプを得る
パッキング：takes_packed.mdとして約12KBのテキストに圧縮（フレーム単位だと膨大なトークンが必要になるため、テキスト主導で扱える形に変換）
LLM推論：どこを残し、どこを切るかを判断
EDL（編集判断リスト）の生成：In/Out点とエフェクト指示を構造化
レンダリング：FFmpegで実際にカット・色補正・字幕焼き込み
自己評価ループ：各カット境界でタイムラインビュー（フィルムストリップ＋波形＋単語ラベル）を生成し、視覚的なジャンプ、オーディオのポップ、隠れた字幕を検出。問題があれば修正→再レンダリング

ポイントはLLMに動画を「見せない」設計です。動画を読むのであり、視聴するのではない。フレームをそのままLLMに食わせると桁違いのトークンを消費するため、テキスト＋必要時のみPNGダンプという軽量な交互作用に振り切っています。

得意な動画タイプ

トーキングヘッド（自分や講師がカメラに向かって話す動画）
モンタージュ（複数素材のテンポ良いつなぎ）
チュートリアル動画（フィラー除去とテロップで仕上げる）
トラベル動画
インタビュー動画

標準で組み込まれている処理

「えー」「あー」「言い直し」の自動カット
無音の詰め
カット箇所への30msフェード（クリックノイズ防止）
カラーグレーディング（ウォーム・シネマティック、ニュートラル・パンチなど）
字幕焼き込み（デフォルトは2語ずつの大文字、ショート動画で見るスタイル）
必要に応じてManim・Remotion・PILでオーバーレイアニメーションを生成

Claude Codeを使った動画編集の自動化そのものについては、こちらの記事でも扱っています。

Claude CodeClaude Codeで動画編集｜何ができるか入門

共通点：両者がAIエージェント時代に共通して持つもの

立ち位置は別物ですが、同時期に登場したことには必然があります。両者には共通の設計DNAがあります。

エージェントから呼ばれる前提：HyperFramesはスキル経由のスラッシュコマンド、video-useはClaude CodeのSkillとして提供。GUIを前提としていない
FFmpeg依存：最終的な動画書き出しは結局FFmpeg。LLMはあくまで構成判断と入出力の橋渡しを担う
テキストベースの中間表現：HyperFramesはHTML、video-useはMarkdown（takes_packed.mdとproject.md）。LLMに食わせやすい形式で意思決定を行う
確定性 / 再現性：HyperFramesは入力同一→出力同一を保証、video-useは自己評価ループで仕上がりを安定化
セッションの永続化：HyperFramesはHTMLそのものが永続化、video-useはproject.mdに進捗を保持
既存パイプラインとの結合容易性：FFmpegさえ動けば良いので、CIやサーバ常駐ワーカーに乗せやすい

決定的な違い：合成か、編集か

本質的な差を一覧にします。

入力：HyperFrames＝HTMLファイル＋アセット／video-use＝撮影済み動画ファイルの入ったフォルダ
主軸：HyperFrames＝視覚デザイン（CSS / GSAP / シェーダー）／video-use＝音声と発話内容
創作行為の単位：HyperFrames＝コンポーネント・トラック・タイムライン／video-use＝カット・テロップ・色
主言語：HyperFrames＝TypeScript／video-use＝Python
主依存：HyperFrames＝Puppeteer＋FFmpeg＋WebGL／video-use＝FFmpeg＋ElevenLabs Scribe
LLMの役割：HyperFrames＝コンポジションを書く（プログラミング）／video-use＝EDLを判断する（意思決定）
得意な被写体：HyperFrames＝架空の世界（プロダクトUI、データ）／video-use＝現実の被写体（人、風景）
距離感：HyperFrames＝After Effects + Remotionの後継／video-use＝Premiere Pro + Descriptの後継

HyperFramesは「コードで世界を組み立てる」、video-useは「現実から要らない部分を削る」と言い換えても良いくらいの差があります。

技術設計の比較：レンダリングパイプラインで見る違い

HyperFramesのパイプライン

HTMLをパース（@hyperframes/core）
data属性からタイムラインを構築
Puppeteerでブラウザに描画させ、各フレームのスクリーンショットを取得
音声トラックをミックス
FFmpegでMP4にエンコード

ライブプレビューはブラウザで直接DOMを再生するため、開発体験が早い。確定レンダリング時はアニメーションを止めて時点へシークするため、実時間ではなくフレーム精度で再現できます。

video-useのパイプライン

素材フォルダをスキャン
各クリップをElevenLabs Scribeに渡して単語レベルのタイムスタンプ付き文字起こしを取得
パック化テキストをLLMに渡して残す/切るを決定
EDLを生成
FFmpegでカット・カラーグレーディング・字幕焼き込み
結果を自己評価。NGならEDLを修正して再レンダリング

HyperFramesが「描く」のに対し、video-useは「読み解いて削る」。レンダリングパイプラインの構造そのものに、対象が架空か現実かの違いが現れています。

どちらを使うべきか：4つの判断軸

軸1：入力素材があるか、ないか

撮影済みの動画素材があるなら video-use。素材がなく、ゼロから生成するなら HyperFrames。これが最も大きな分岐です。

軸2：被写体が現実か、抽象か

人間が話している、風景が映っている、現実の動きを記録した動画なら video-use の独壇場です。プロダクトのUIアニメ、グラフ、ロゴモーション、抽象的な遷移なら HyperFrames が向いています。

軸3：制作チームのスタックは何か

フロントエンド寄り（TypeScript、React、CSS）の開発チームなら HyperFrames が自然に馴染みます。Python・データ系の現場や、字幕・音声処理が日常業務にあるならvideo-useが手に馴染むはずです。

軸4：何をAIに任せたいか

「動画を新しく作ってもらいたい」場合はHyperFrames。「素材はあるので仕上げてほしい」場合はvideo-use。前者はゼロイチの生成、後者は最後の一押しの自動化です。

受託の現場から見たそれぞれの位置づけ

私は過去に、ある建設会社向けにPR動画を制作した経験があります。3分弱の本編1本＋2分弱のショート版2本という構成で、撮影は提携カメラマン、編集はクラウドソーシングの編集者と分業しました。会社説明会のスライドの間に挿入したり、リール用に切り抜いたりと用途が分かれるため、最終的に複数のバリエーションを書き出す必要があります。

こうした「実写素材があり、用途別に複数バリエーションを切り出す」案件は、まさにvideo-useが想定する世界です。フィラー除去・カラーグレーディング・テロップという定型作業をAIに任せ、編集者は構成判断と最終チェックに集中する形に再設計できます。

一方で、別件のWebサイト制作では、サイトの世界観に合わせたモーションロゴやヘッダーのキネティックタイポグラフィが必要になります。こうした「ゼロから合成的に作る」用途は、HyperFramesの得意領域です。Webサイト本体をNext.jsとGSAPで作っているなら、HyperFramesのHTML+GSAPスタックは違和感なく溶け込みます。

つまり受託の現場で言えば、video-useは編集パートナーの代替、HyperFramesはモーショングラフィックス制作の代替として位置付けるのが現実的です。両方を併用するシナリオも素直に成立します。video-useで本編を仕上げ、HyperFramesでオープニング・エンディング・図解パートを生成し、最終的にFFmpegで結合する。これが2026年8月時点のAI時代の動画制作ワークフローのひとつの完成形だと考えています。

ショート動画の編集を自動化した実装記録も公開しています。

Claude CodeClaude Codeでショート動画編集を自動化した実装記録

導入時の注意点

HyperFramesの注意点

Node.js 22以上とFFmpegが前提。開発用の回帰テスト資産を取得する場合はGit LFSも必要になります
エコシステムの成熟度はRemotionに劣ると公式が明記しています。テンプレートや事例の少なさは初期工数として見込んでおくべきです
カタログの部品は便利な一方、案件特化のテンプレートは自前で組む必要があります
音声合成や文字起こしはCLIにありますが、品質要件が高い場合は外部サービスとの差し替えを設計に含めてください
クラウドレンダリングを使う場合、フレームワークは無料でもクラウド側の実行費用は自社負担です

video-useの注意点

ElevenLabs APIキーが必須。文字起こしの品質と料金がそのままアウトプットの品質と料金に直結する
話者判別やフィラー検出は外部依存のため、対象言語・ノイズ環境で精度が変わる
LLMが動画を「視聴」しないため、被写体の表情やカメラワークの良し悪しは判断できない（音声と単語で判断する）
自己評価ループで解決できる範囲には限度があるため、最終チェックは人間が行う運用にした方が安全

HyperFramesに関するよくある質問

HyperFramesは無料で使えますか

はい。Apache 2.0ライセンスのオープンソースで、商用利用に追加課金や席数上限はありません。ローカルでのレンダリングにHeyGenのクレジットも消費しません。費用が発生するのは、ホスティングされたレンダリング、音声・アバター・生成メディアなどのオプション、AWS LambdaやGoogle Cloud Runを使った場合のクラウド実行費用です。

HeyGenのアカウントは必要ですか

ローカルで使う分には不要です。必要なのはNode.js 22以上とFFmpegで、npx hyperframes init から始められます。HeyGen側のホスティングやアバター機能を使う場合のみアカウントが関係します。

Windowsでも動きますか

公式READMEにはWindows向けのGit LFS導入コマンド（winget install GitHub.GitLFS）が記載されており、Windows環境が想定に入っています。ただし前提となるNode.js 22以上とFFmpegの導入は別途必要です。実行環境の問題はnpx hyperframes doctor で診断できます。

Remotionから移行できますか

公式に移行用のスキルがあり、useCurrentFrame と interpolate をタイムラインのトゥイーンに対応づけます。公式の説明では典型的なコンポジションの約80%が機械的に変換され、残り20%は誤変換せずフラグが立つ形です。資産が大きい場合は、まず短い1本で変換精度を確かめてから全体の判断をしてください。

プログラミングができなくても使えますか

npx hyperframes preview で開くStudioにはストーリーボード・タイムライン・キャプションの編集UIがあるため、既存のプロジェクトを開いて文言やタイミングを直す作業はコードなしでも可能です。ただしゼロから構成を作る工程はHTMLかコーディングエージェントへの依頼が前提になります。

HyperFramesとvideo-useはどちらを先に触るべきですか

手元に撮影済みの動画素材があるならvideo-use、素材がなくゼロから作りたいならHyperFramesです。判断に迷ったら「入力に動画ファイルがあるかどうか」だけで切り分けてください。両者は競合ではないので、最終的に併用する形に落ち着くケースも多くあります。

AIエージェント時代の動画制作はどう変わるか

HyperFramesとvideo-useをそれぞれ触ってみると、共通して感じるのは「LLMが動画制作の指揮者になりつつある」という構図です。これまではNLE（Premiere、DaVinciなど）のタイムラインに人間が線を引いていました。これからは、自然言語の指示を受け取ったエージェントが、HTMLやEDLという中間表現を介して動画を組み立てる時代です。

そのためには、動画制作の知識が「コードで表現できる形」に整理されている必要があります。HyperFramesがHTMLのdata属性で時間軸を表したのも、video-useが動画を文字起こし＋EDLというテキスト中間表現に落としたのも、LLMが理解できる粒度で動画を再定義したという点で共通しています。

逆に言えば、動画制作のロジックを言語化・構造化できる現場ほど、AIによる効率化の恩恵を受けやすいということです。テンプレートが暗黙知のまま編集者の頭の中にある現場では、AIエージェントが入る余地はそれほど大きくありません。

まとめ：HyperFramesは「合成」、video-useは「編集」

HyperFramesはHeyGenが公開したApache 2.0のオープンソース。HTMLとCSSで動画を組み立て、MP4に書き出すレンダリングフレームワーク
使い方はnpx hyperframes init →preview →render の3ステップ。必要なのはNode.js 22以上とFFmpegだけで、エージェントから使う場合はnpx skills add heygen-com/hyperframes --full-depth を入れて/hyperframes で呼ぶ
料金はフレームワーク自体が無料。費用が乗るのはホスティング、音声・アバター等のオプション、自社クラウドの実行費用の3箇所
Remotionとの違いは書き方（HTML対React）、レンダリング方式（シーク対フレーム番号）、ライセンス（Apache 2.0対4人以上は有償）、成熟度（Remotionが優位）の4点。移行は公式スキルで約80%が機械変換される
レンダリング先はローカルCLIからHyperFrames Cloud、AWS Lambda、Google Cloud Runまで揃っている。まずローカルで始め、本数が増えてから移せばよい
video-useは素材フォルダに対話するだけでfinal.mp4を返す編集スキル。実写ベースの編集を担う
受託の現場では併用が現実的。本編はvideo-use、オープニングや図解はHyperFrames、結合はFFmpegという構成が成立する

動画制作はAIエージェントが介在することで、構成判断と仕上げが分離されつつあります。社内に動画ニーズがある中小企業にとっては、編集の外注フローを再設計する材料になりますし、開発会社にとってはクライアントワークの内部化のきっかけになります。株式会社Fyveとしては、まずHyperFramesで1本レンダリングしてみることを勧めます。動くものが手元に出れば、自社のどの動画がこの方式に載るかは自然に見えてきます。

この記事を読んでいるあなたへ無料プレゼント