「動画をコードで書く」と聞くと、多くの人は身構えるかもしれません。動画とはタイムライン上でクリップを並べ、トランジションを挟み、書き出す——そういう視覚的で職人的な作業だという先入観があるからです。ところが、AIコーディングエージェントが日常の開発に入り込んだいま、この前提が静かに崩れつつあります。エージェントはコードを書くのは得意でも、動画編集ソフトのタイムラインをドラッグすることはできません。ならば、動画のほうを「コードで書けるもの」に変えてしまえばいい——そう発想したのが、本記事で解説する hyperframes（ハイパーフレームズ） です。

hyperframesは、AIアバター動画で知られる HeyGen（heygen-com） がオープンソースとして公開した動画フレームワークです。一言でいえば「Write HTML. Render video. Built for agents.（HTMLを書く。動画をレンダリングする。エージェントのために作られた）」。HTML・CSS・各種アニメーションで動画のシーンを記述すると、ヘッドレスChromeとFFmpegを通じて 決定論的なMP4 に変換します。ライセンスはApache-2.0、開発言語はTypeScript、GitHubスター数は執筆時点で 35,145 に達し、直近も活発に更新されている注目のプロジェクトです。

なお、hyperframesの名前を当サイトで見かけたことがある読者もいるかもしれません。デザイン生成OSS「Open Design（nexu-io）」は動画機能の描画コアとしてHyperFramesを取り込んでおり、コーディングエージェントで動画を編集する「video-use」もアニメーション生成手段の一つとしてこれを挙げています。つまり同じ技術がすでに複数のツールに組み込まれているわけですが、本記事では hyperframes そのものを単体ツールとして 、仕組み・スキル群・実運用・他ツールとの違いまで一段深く掘り下げます。

hyperframesとは何か — 「HTMLを書く。動画をレンダリングする」

hyperframesの正体を最短で説明すると、「HTML・CSS・メディア・シーク可能なアニメーションを、決定論的なMP4動画にレンダリングするフレームワーク」です。ここで大事なのは、これが「動画編集ツール」ではなく「動画をコードで書くための基盤」だという点です。タイムラインをドラッグして素材を切り貼りするのではなく、Webページを作るのと同じ感覚でシーンを記述し、それを動画として書き出す——発想の出発点がまるで違います。

公式は、hyperframesの使い方を大きく3通りに整理しています。

  • ① ローカルのCLIとして使う：手元のマシンでコマンドを叩き、HTMLで書いたシーンをMP4にレンダリングする、もっとも素朴な使い方です。
  • ② AIコーディングエージェントからスキル経由で使う：Claude CodeやCursorなどのエージェントにhyperframesの「スキル」を追加し、「この製品紹介動画を60秒で作って」といった自然言語の指示から動画を生成させる使い方です。ここがhyperframesの真骨頂で、後述する約20個のスキルがエージェントの手足になります。
  • ③ ホスト型オーサリングの描画コアとして使う：Open Designのような別のアプリケーションが、内部の動画レンダリングエンジンとしてhyperframesを組み込む使い方です。ユーザーはhyperframesの存在を意識せず、その出力だけを受け取ります。
ポイント：hyperframesは「動画編集」ではなく「動画をコードで書く」ツール

従来の動画編集ソフトは、完成済みの素材（撮影した映像やレンダリング済みのアニメーション）を並べて仕上げる道具です。hyperframesはその前段——「動画そのものをHTML/CSSとアニメーションのコードとして定義し、それをMP4に焼き上げる」ところを担います。だからこそ、コードを書くのが得意なAIエージェントと相性が良いのです。

この「エージェントのために作られた（Built for agents）」という設計思想は、ただのキャッチコピーではありません。AIエージェントに動画を作らせようとしたとき、最大の障害になるのが 再現性 です。エージェントは試行錯誤しながら成果物を改善していきますが、その過程で「昨日は正しくレンダリングされた動画が、今日は微妙にズレる」といったことが起きると、改善のループが成立しません。hyperframesはこの問題を「決定論的レンダリング」という設計で正面から解いています。仕組みは次の章で詳しく見ますが、まずは「エージェントが安心して何度でも作り直せるように、出力が毎回同じになるよう作られている」という一点を押さえておいてください。

対応するアニメーションのランタイムも幅広く、GSAP / Lottie / Three.js / Anime.js / CSS / WAAPI（Web Animations API）/ TypeGPU といったアダプタが用意されています。キネティックタイポグラフィのような凝ったモーションはGSAPやAnime.jsで、Lottieで書き出したベクターアニメーションはそのまま、3D表現はThree.jsで、シンプルな動きはCSSやWAAPIで——と、Webフロントエンドの技術資産をほぼそのまま動画制作に転用できます。「新しい動画専用言語を覚える」のではなく、「すでに知っているWeb技術で動画を書く」という体験が、学習コストを大きく下げています。

仕組み：HTMLが決定論的MP4になるまで

hyperframesの核心は、その レンダリングパイプライン にあります。ここを理解すると、なぜ「決定論的」で「エージェント向き」なのかが腑に落ちます。

hyperframesのレンダリングパイプライン。HTML/CSS/GSAPで書いたシーンを、ヘッドレスChromeがフレーム単位でシークして描画し、FFmpegで結合して決定論的なMP4を生成する流れ

流れを追いましょう。まずエージェント（または人間）が、動画のシーンを HTML・CSS・GSAPなどのアニメーション として記述します。これは実質的にWebページを作る作業と変わりません。次に、この「時間とともに変化するWebページ」を、ヘッドレスChrome が読み込みます。ここが第一のポイントです。

普通に画面を録画するなら、アニメーションを実時間で再生しながらキャプチャすることになります。しかしこの方式は、マシンが重ければコマ落ちし、速ければ間延びする——つまり 実行環境に結果が左右される という致命的な弱点を抱えます。hyperframesはこれを避けるために、実時間の再生ではなく 「フレーム送り（シーク）」 でレンダリングします。「1秒地点はこう」「1.033秒地点（30fpsの次のコマ）はこう」と、各フレームの時刻をChromeに指定し、その瞬間の画面を1枚ずつ正確に描画させるのです。マシンの速度がいくら違っても、指定した時刻の見た目は常に同じになります。ここから 決定論性 が生まれます。

こうして1フレームずつ描画された静止画（フレーム列）を、最後に FFmpeg が1本の動画に結合し、MP4として書き出します。入力（HTML・CSS・素材・設定）が同じなら、途中のフレーム描画も、最終的なMP4も、毎回まったく同じになる——これがhyperframesのいう「決定論的MP4（deterministic MP4）」の正体です。

flowchart LR A["シーンを記述
HTML / CSS / GSAP / Lottie / Three.js など"] --> B["ヘッドレスChrome
各フレームの時刻をシーク(頭出し)"] B --> C["フレーム列を描画
1コマずつ静止画として取得"] C --> D["FFmpegで結合
フレーム列 → 動画ストリーム"] D --> E["決定論的MP4
同じ入力 → 毎回同じ出力"] E -.->|"エージェントが検証して
再レンダリング"| A

この「シークして描く」という方式は、hyperframesのもう一つの重要概念である シーク可能性（seekability） と表裏一体です。任意のフレームを正確に描くには、アニメーションが「時刻 t を与えれば、その瞬間の状態が一意に決まる関数」でなければなりません。逆にいえば、実時間の経過やランダム性、外部の状態に依存するアニメーションは、シークすると破綻します。そこでhyperframesには シーク安全なキーフレーム を扱うための専用スキル（hyperframes-keyframes）が用意されており、「どう書けばシークしても壊れないアニメーションになるか」というノウハウが体系化されています。

なぜ「決定論」と「シーク可能性」がエージェント運用に効くのか

AIエージェントは「作る→確認する→直す」を高速で回して品質を上げます。このとき出力がブレると、エージェントは「自分の修正が効いたのか、たまたまなのか」を判別できず、改善が空回りします。hyperframesは出力を決定論的に固定することで、エージェントの反復を意味のあるものにします。さらにシーク可能なので、動画全体をレンダリングせずとも「問題が起きた特定フレームだけ」を素早く確認でき、デバッグの単位が細かくなります。動画をコードとして扱えることの実利が、ここに集約されています。

決定論的であることは、Git管理やCI/CDとの相性の良さ にも直結します。シーンの定義がHTML/CSS/コードである以上、動画の「ソース」はテキストとしてバージョン管理できます。そして同じソースからは同じ動画が生成されると保証されているため、「レビューではソース（差分）を見れば、生成される動画がどう変わるか予測できる」「CI上で自動レンダリングしても、ローカルと同じ結果になる」といった、ソフトウェア開発で当たり前の営みを、動画制作に持ち込めます。動画を「バイナリの完成品」ではなく「再現可能なビルド成果物」として扱える——これがhyperframesがもたらす発想の転換です。

約20のスキルと用途別ワークフロー

hyperframesを「エージェントのためのツール」たらしめているのが、約20個のスキル です。スキルはオンデマンドで読み込まれる仕組みになっており、エージェントは必要なときに必要なスキルだけをコンテキストに載せます。全部を一度に抱え込まないため、コンテキストを圧迫しません。

hyperframesの公式デザインテンプレート4種のコラージュ。Bold Poster / Cobalt Grid / Biennale / Creative Mode。それぞれ配色・レイアウト・タイポグラフィが異なる

スキル群の入口になるのが、ルーターの役割を持つ /hyperframes です。これは「能力マップ」兼「意図ルーター」で、ユーザーの依頼内容を読み取り、「その目的ならこのワークフロースキルを使うべき」と適切なスキルへ振り分けます。以下、主なスキルを 作成ワークフロー と ドメインスキル に分けて整理します。

目的別の「作成ワークフロー」スキル

  • /product-launch-video：製品紹介動画（〜3分、推奨は30〜90秒）。もっとも需要が大きい用途の一つです。
  • /website-to-video：既存のWebサイトをもとにPR動画を起こす。
  • /pr-to-video：GitHubのPull Requestから、変更点や新機能を解説する動画を作る。gh CLI経由でPR情報を取得します。開発チームのリリースノートを動画化する、といった使い方が想定できます。
  • /embedded-captions：字幕を焼き込む。
  • /talking-head-recut：トーキングヘッド（話者の正面映像）にグラフィックを重ねて再編集する。
  • /motion-graphics：〜10秒程度のモーショングラフィックス。キネティックタイポグラフィやロゴアニメーション向け。
  • /music-to-video：楽曲のビートに同期した動画を作る。
  • /slideshow：プレゼン・デッキ形式の動画。
  • /faceless-explainer：顔出しなしの解説動画。
  • /general-video：どのワークフローにも当てはまらないときの汎用フォールバック。
  • /remotion-to-hyperframes：Remotionプロジェクトからの移行（一方向）。

描画を支える「ドメインスキル」

  • /hyperframes-animation：アニメーションの扱い全般。
  • /hyperframes-keyframes：前章で触れた、シーク安全なキーフレームの書き方。決定論性を保つ要のスキルです。
  • /hyperframes-creative：クリエイティブな表現のためのスキル。
  • /media-use：BGM・効果音（SFX）・画像・ロゴなどのメディア素材を、ローカルに解決して組み込む。
  • /hyperframes-cli：CLIの操作。
  • /hyperframes-registry：レジストリ（後述するブロック/コンポーネントの提供元）の扱い。
  • /figma：Figmaとの連携。
「ルーター＋オンデマンド読み込み」というスキル設計

20個ものスキルを一度にエージェントへ渡すと、コンテキストが膨れ上がって肝心の作業に使える余地が狭まります。hyperframesは入口の/hyperframesを「意図ルーター」に据え、依頼内容に応じて必要なスキルだけを呼び出す構成にしています。これは、当サイトでも繰り返し取り上げてきた「スキルをオンデマンドで読み込み、コンテキストを節約する」というエージェント設計の定石を、動画制作という具体的な領域で実装した好例です。

スキルとあわせて、hyperframesは デザインテンプレートとレジストリのブロック/コンポーネント を同梱しています。上のコラージュにある「Bold Poster」「Cobalt Grid」「Biennale」「Creative Mode」は、その公式デザインテンプレートの一部です。ゼロから配色やレイアウトを組み立てなくても、こうしたテンプレートを土台に、エージェントが素早く見栄えのする動画を組み上げられます。

hyperframesの公式Creative Modeテンプレート。自由度の高い表現向けのデザインプリセット

たとえば「Creative Mode」は、定型のレイアウトから離れて自由度の高い表現をしたいときのプリセットです。テンプレートは単なる見た目のスターティングポイントであり、そこにhyperframes-creativeやhyperframes-animationのスキルを組み合わせることで、「テンプレの安心感」と「独自の表現」を両立させられます。テンプレートに縛られるのではなく、テンプレートから出発して崩していく——という使い方が想定されています。

実際の使い方 — 導入・CLI・エージェント運用

ここからは、hyperframesを実際に動かす流れを見ていきます。前提として、Node.js 22以上 が必要です。レンダリング時にはヘッドレスChromeとFFmpegが使われるため、環境が揃っているかは後述のdoctorコマンドで確認できます。

導入：スキルの追加

もっとも重要なのが、導入コマンドです。

npx skills add heygen-com/hyperframes --full-depth --yes

ここで --full-depth は必須級のオプション です。これを付けないと、skills addはskills.shレジストリのblob（キャッシュ）から取得しますが、このblobはmainブランチより 数時間古い ことがあります。活発に更新されているプロジェクトゆえ、古いバージョンを掴むと最新のスキルや修正が反映されません。--full-depthを付けると現行のmainをそのまま取得できるため、公式もこの付け方を推奨しています。--yesは対話的な確認をスキップするフラグで、エージェントからの自動実行にも向きます。

注意：--full-depth を省くと数時間古いスキルを掴む

導入で最初につまずきやすいのがここです。「スキルを追加したのに公式ドキュメントと挙動が違う」という場合、--full-depthなしでレジストリのキャッシュを取得しているケースを疑ってください。活発なプロジェクトほど、この数時間の差が効いてきます。

導入が済むと、対応エージェント（Claude Code / Cursor / Gemini CLI / Codex など）からhyperframesのスキルが使えるようになります。あとはエージェントに「この製品の紹介動画を60秒で作って」「このPRの変更点を解説する動画にして」と依頼すれば、入口の/hyperframesルーターが適切なワークフロースキルへ振り分け、シーンのHTMLを書き、レンダリングまで進めてくれます。

CLI：8つのコアコマンド

エージェント経由でも、手元での直接操作でも、実体として動くのはCLIです。主なサブコマンドは次の通りです。

  • init：プロジェクトの初期化。
  • lint：シーン定義の静的チェック。
  • check：検査（シーク可能性など、レンダリング前の妥当性確認）。
  • snapshot：スナップショット取得。特定フレームの見た目を固定して差分検出に使う発想です。
  • preview：プレビュー。全編をレンダリングせずに確認する。
  • render：本レンダリング。フレームをシークして描画し、FFmpegでMP4に結合する中核コマンド。
  • publish：公開・書き出し。
  • doctor：環境診断。Node・ヘッドレスChrome・FFmpegなどの前提が揃っているかをチェックします。導入直後にまず叩くべきコマンドです。
flowchart TD A["init
プロジェクト初期化"] --> B["doctor
前提環境を診断"] B --> C["lint / check
シーンの静的検査・妥当性確認"] C --> D["preview / snapshot
部分確認・差分検出"] D --> E["render
本レンダリング(MP4生成)"] E --> F["publish
書き出し・公開"] E --> G["cloud render
HeyGenホスト型でレンダリング"] E --> H["lambda deploy / render / progress
AWS Lambdaで分散レンダリング"]

ローカルでの一連の流れは、init で雛形を作り、doctor で環境を確認し、lint/check でシーンの妥当性を検証し、preview/snapshot で部分的に見た目を確かめてから、render で本番のMP4を生成し、必要に応じて publish で書き出す——という順序になります。ソフトウェア開発の「init → lint → test → build」に驚くほど似た体系で、動画制作がビルドパイプラインとして扱われていることがよく分かります。

スケールさせる：クラウドとLambda

ローカルレンダリングに加えて、hyperframesは大規模・高速化のための経路も持っています。cloud render はHeyGenが提供するホスト型のクラウドレンダリングで、手元のマシンの性能に縛られずにレンダリングを回せます。さらに lambda deploy / lambda render / lambda progress は、AWS Lambda上に分散してレンダリングする仕組みです。動画は「フレームごとに独立して描ける」性質を持つため、フレーム列を複数のLambda関数に分割して並列描画すれば、長尺・高解像度でもレンダリング時間を短縮できます。決定論的であること（どのマシンで描いても同じ結果になること）が、この分散レンダリングの正しさを担保している点にも注目してください。

hyperframesの公式Cobalt Gridテンプレート。青系の配色とグリッドレイアウトを基調としたデザインプリセット

npmパッケージは hyperframes として公開されているため、上記のスキル導入とは別に、Node.jsプロジェクトの依存として組み込んで、③の「描画コアとして使う」用途に発展させることもできます。Open DesignがHyperFramesを動画機能の描画エンジンとして取り込んでいるのは、まさにこの使い方の実例です。

他の動画ツールとの違い — Remotion・従来編集ソフトとの比較

hyperframesの立ち位置を掴むには、既存の動画制作アプローチと並べてみるのが早道です。ここでは「hyperframes / Remotion / 従来の動画編集ソフト」を、いくつかの観点で事実ベースに比較します。優劣を断じるのではなく、それぞれ得意な領域が異なる、という前提で読んでください。

観点 hyperframes Remotion 従来の動画編集ソフト
作り方 HTML・CSS＋GSAP/Lottie/Three.jsなど複数アダプタでシーンを記述 動画をReactコンポーネントとして記述 GUIのタイムラインで素材を配置・編集
再現性・決定論 同じ入力→毎回同じMP4（シーク描画で保証） プログラム的で再現性は高い 手作業に依存し、同じ結果の再現は保証されない
エージェント連携 「Built for agents」。約20スキルで意図ルーティング ライブラリとして呼べるが、専用スキル群はhyperframesほど整備されていない GUI前提でエージェントからの直接操作は困難
ソース管理 シーン定義をテキストとしてGit管理・CI可能 コードなのでGit管理可能 プロジェクトファイルはバイナリ寄りで差分が見にくい
出力 決定論的MP4（ローカル/クラウド/Lambda） 動画（レンダリングサーバやLambda対応） 各種動画フォーマット
学習コスト 既存のWeb技術資産を流用でき低め Reactの知識が前提 ソフトの操作習熟が必要（作業自体は直感的）
ライセンス/提供元 Apache-2.0・OSS（HeyGen製） 独自ライセンス（用途により有償） 多くは商用製品

この表から読み取れる差別化の軸は、大きく3つです。

第一に、「Web技術で書けること」。Remotionが「React（JSX）で書く」ことを前提にするのに対し、hyperframesは素のHTML/CSSを土台に、GSAP・Lottie・Three.js・Anime.js・WAAPI・TypeGPUといった複数のアニメーションランタイムをアダプタで受け止めます。フロントエンド開発者がすでに持っている引き出しを、そのまま動画制作に転用できる幅の広さがあります。

第二に、「エージェント前提の設計」。Remotionもプログラムから動画を生成できますが、hyperframesは最初から「AIコーディングエージェントが動画を作る」ことを主眼に据え、ルーター＋約20スキルという形でエージェントの作業手順まで作り込んでいます。「ライブラリとして呼べる」ことと「エージェントが迷わず使えるように整備されている」ことは別物で、hyperframesは後者に踏み込んでいます。

第三に、「決定論を明示的な設計目標にしていること」。従来の動画編集ソフトは、そもそも手作業が前提なので「同じ操作をすれば同じ結果」という保証はありません。hyperframesはシーク描画によって決定論性を担保し、それをGit管理・CI・分散レンダリングといった開発の営みに接続します。

補足：同じ技術が他ツールに「取り込まれて」もいる

冒頭でも触れたように、hyperframesの動画レンダリング技術は、Open Designの動画機能（HyperFrames）や、video-useのアニメーション生成手段の一つとして、他ツールにも組み込まれています。つまり「hyperframes vs 他ツール」という対立だけでなく、「hyperframesが他ツールの描画コアになる」という補完関係も成り立ちます。単体で使うか、より大きなワークフローの部品として使うか——3つの使い方（CLI／エージェント／描画コア）が用意されているのは、この両面に応えるためです。

使いどころと注意点

最後に、hyperframesがどんな場面で効くのか、そして導入前に押さえておくべき点を整理します。

特に向いているのは、まず「AIエージェントで動画制作を自動化したいチーム」です。 すでにClaude CodeやCursorを日常的に使っているなら、スキルを1つ追加するだけで「動画を作る」能力が手に入ります。製品リリースのたびに紹介動画を作る、PRごとに変更点の解説動画を添える、といった 定型的だが手間のかかる動画制作 を、依頼文だけで回せるようになります。pr-to-videoのように開発フローに直結したスキルがあるのは、開発者向けツールとしてのhyperframesの性格をよく表しています。

次に、「動画をコード資産として管理したい開発者」です。 シーン定義がHTML/CSSとコードである以上、動画のソースはGitでバージョン管理でき、レビューも差分ベースで行えます。決定論的だからこそ、CIで自動レンダリングしてもローカルと同じ結果が得られます。「動画をビルド成果物として扱う」という発想に価値を感じる人には、強く刺さるはずです。

フロントエンド技術の資産を持つ人にも好適です。 GSAPでのアニメーション、Lottieでのベクター表現、Three.jsでの3D——こうした技術をすでに使っているなら、その知識をほぼそのまま動画に転用できます。新しい動画専用言語を覚え直す必要がありません。

一方で、注意点もあります。

導入前に押さえておきたい前提
  • 実行環境：Node.js 22以上、ヘッドレスChrome、FFmpegが必要です。まずdoctorで診断を。
  • シーク可能性の制約：決定論性を保つには、アニメーションが「時刻を与えれば状態が一意に決まる」ものでなければなりません。実時間やランダム性に依存する書き方はシークで破綻します。hyperframes-keyframesスキルのノウハウを踏まえる必要があります。
  • クラウド利用のコスト：ローカルレンダリングは無料ですが、cloud renderやLambdaレンダリングを使う場合は、HeyGenのホスト環境やAWSの利用料が別途かかります。
  • 素材のライセンス：ツール本体はApache-2.0ですが、出力動画に組み込むBGM・画像・フォントの権利は各素材のライセンスに従います。
  • 向かない領域：実写映像の切り貼りや色補正が中心の編集は、hyperframesの守備範囲ではありません。そこは従来の編集ソフトや、[video-use](/tool/video-use-ai-video-editing/)のような「実写素材をエージェントで編集する」ツールが向きます。hyperframesが得意なのは、あくまで「コードで書くタイプの動画」（モーショングラフィックス、キネティックタイポ、スライドショー、製品説明など）です。

言い換えれば、hyperframesは「プログラムで定義できる動画」に強く、「撮影した映像を仕上げる編集」は別のツールに任せる、という住み分けになります。この線引きを理解しておけば、期待とのズレは起きにくいでしょう。実写編集のvideo-use、デザイン生成のOpen Design（その描画コアとしてのhyperframes）、そして単体のhyperframes——同じ「動画×AIエージェント」の潮流の中で、それぞれが違う役割を担っています。

まとめ：動画を「再現可能なビルド成果物」に変えるOSS

hyperframesは、HeyGenが公開した「HTMLを書いて動画をレンダリングする、エージェントのためのOSSフレームワーク」です。ヘッドレスChromeがフレームをシークして描画し、FFmpegで結合することで、同じ入力なら毎回同じ結果になる決定論的MP4を生成します。この決定論性が、AIエージェントの反復・Git管理・CI・分散レンダリングを可能にし、動画を「バイナリの完成品」から「再現可能なビルド成果物」へと変えます。約20のスキルとルーター、複数のアニメーションアダプタ、公式テンプレートが、エージェントによる動画制作を実務レベルに引き上げています。動画制作の自動化を考えているなら、一度は触れておく価値のある一本です。

TLDR

  • hyperframesとは：HTML・CSS・アニメーションを 決定論的なMP4 にレンダリングするHeyGen製OSS。「Write HTML. Render video. Built for agents.」。Apache-2.0・TypeScript・⭐35,145・Node >= 22。
  • 仕組み：ヘッドレスChromeが実時間再生ではなく フレームをシーク（頭出し） して1コマずつ描画 → FFmpegで結合。だから同じ入力なら毎回同じ出力になる。
  • 3つの使い方：① ローカルCLI ② AIコーディングエージェントからスキル経由 ③ ホスト型オーサリングの描画コア。
  • 約20のスキル：入口は意図ルーター /hyperframes。product-launch-video・pr-to-video・motion-graphics・slideshow などの作成ワークフローと、hyperframes-keyframes（シーク安全）・media-use などのドメインスキル。
  • 導入：npx skills add heygen-com/hyperframes --full-depth --yes（--full-depth必須＝現行mainを取得）。対応エージェントは Claude Code / Cursor / Gemini CLI / Codex。
  • CLI：init / lint / check / snapshot / preview / render / publish / doctor に加え、cloud render・lambda deploy/render/progress。
  • 他ツールとの違い：Remotion（React記述）に対しWeb技術＋複数アダプタ、エージェント前提の整備、決定論を明示目標に。実写編集は守備範囲外（そこはvideo-use等）。
  • 注意点：Node 22＋ヘッドレスChrome＋FFmpegが前提／シーク可能な書き方が必要／クラウド利用は別料金／素材ライセンスは各自確認。

参照ソース