まずは動画を見て欲しい
まずはこれを見て欲しい。
これは、私が先日公開した「ローマ字クイズ」PWAアプリの紹介動画を、Codex と HyperFrames を使って生成したものだ。
驚いたのは、キャプチャ画像も、音声ファイルも、動画素材も一切渡していないのに、
完成度の高い動画が作れてしまったこと。
最初に与えたプロンプトは、たったこれだけだった。
URL:
https://b.aries67.com/tool/rome/
目的:
小学生向け学習アプリ紹介
尺:
45秒
雰囲気:
親しみやすい教育系
見せたい点:
3択UI
スマホ対応
無料
PWAこれだけで、Codex は対象URLを解析し、
- 小学生向け
- 3択学習UI
- スマホ向け
- 学習モード
- PWA対応
- 無料で使える
といったアプリの特徴を読み取り、動画の構成を自動で組み始めた。
さらに面白いのは、こちらが指示していない要素まで拾い始めたことだ。
例えば、「練習モード」のような文言はプロンプトに含めていない。しかし Codex は、実際のHTMLやUI構造を確認しながら、
「このアプリはどういう用途なのか」
「どこを見せるべきか」
を推論し、動画用のコピーやナレーションへ反映していった。
つまり今回の生成は、単なる「テキストから動画」ではない。
Codex が、
- Webサイトを読む
- UI構造を理解する
- 特徴を抽出する
- シーン構成を考える
- ナレーションを作る
- タイムラインを構築する
という、“制作工程そのもの” を組み始めた実験だった。
HyperFramesとは何か ─ “動画編集ソフト”ではない
今回使った HyperFrames は、ぱっと見は「AI動画生成ツール」に見える。
しかし、実際に触ってみると、これは従来の動画編集ソフトとはかなり思想が違う。
AfterEffects や Premiere のような既存の動画編集ソフトは、
- レイヤー
- タイムライン
- キーフレーム
- エフェクト
をGUI上で操作しながら映像を作っていく世界だった。
だが、HyperFrames は違う。
本質は、
HTML/CSS/JavaScript をベースに、
“Webそのものを動画へ変換する”という思想にある。
実際、生成されたプロジェクトの中身を見ると、
- index.html
- SCRIPT.md
- STORYBOARD.md
- narration.wav
- scene別wav
- capture
- manifest
などが並ぶ。
つまり HyperFrames は、「動画ファイル」を直接作っているのではない。
まず、
- Web構造
- シーン設計
- ナレーション
- タイムライン
- モーション
を“構造化された制作データ”として組み上げ、その最終成果物として MP4 をレンダリングしている。
この感覚は、むしろ Web開発 に近い。
実際、HyperFrames Studio の画面を見た瞬間、かなり驚いた。
タイムラインがあり、Scene が並び、音声波形が並び、プレビューが動く。
しかし、その裏側では HTML が動いている。
つまりこれは、
「動画編集ソフト」
というより、
Web Runtime ベースの映像コンパイラに近い。
しかも、そこへ Codex のようなエージェントAIが接続されることで、
- URL解析
- シーン設計
- コピー生成
- TTS生成
- scene分割
- タイムライン調整
- レンダリング
までが、半自律的に進行していく。
ここで、Notebook LM を思い出した。
Notebook LM は、
「知識をインフォグラフィックスと音声にするAI」
だ。
一方、HyperFrames は違う。
Web体験そのものを、
映像へ変換し始めている。この方向性は、かなり大きな変化だと思う。
HTMLの豊かな表現力を動画にしようという意欲的な試みの結晶が、HyperFrames だ。
内部的にはNotebook LM もそうなのかもしれない。
とはいえ、HyperFrames は、AIが操作することを前提にしている。
StudioのGUI画面を触るのは、あなたではなくCodexだ。
現実は「依存地獄」だった
CodexでHyperFrames を使うのはかんたんだ。
プラグインから選ぶだけ。
……とは言え、実際の作業はそんな綺麗な話では終わらなかった。
むしろ最初に待っていたのは、
依存の嵐だった。
今回の構成は、
- WSL2 Ubuntu
- Node.js（nvm）
- HyperFrames CLI
- ffmpeg
- Chrome headless
- Python
- TTS
- ONNX Runtime
など、多数のコンポーネントが絡む。
つまり実態としては、
「AI動画生成」
というより、
Linux + Web Runtime + AI Orchestrationだった。
最初にハマったのは、HyperFrames の capture。
URLを解析してスクリーンショットを取得する機能だ。
最初は、
capture completedと表示されるのに、中身が空。
原因を辿ると、
Chrome headless shell 未導入だった。
さらに、
libnss3.so が無いで停止。
結局、
sudo apt install libnss3で復旧した。
ここで見えてきたのは、HyperFrames が単なる動画生成AIではなく、
Browser Automationを内部で多用していることだ。
つまり、
- Browser capture
- HTML rendering
- CSS animation
- Snapshot generation
を、本物のChrome headlessで動かしている。
だから WebRuntime が必要になる。
さらに、
- pip が無い
- ensurepip が無い
- PEP668
- kokoro-onnx
- voices-v1.0.bin
など、Python周辺でも次々と詰まった。
この辺りから、だんだん気付き始めた。
これは、
「AIが動画を作っている」
というより、
AIが“制作パイプライン”そのものを構築しているのではないか、と。
実際、Codex は途中から、
- scene分割
- wav分離
- speed調整
- token limit回避
- TTS切り替え
などを、自律的に判断し始めていた。
特に面白かったのは、
長い台本を一括合成
↓
Kokoro の token limit に到達
↓
1文ずつ scene分割
↓
FFmpeg で結合という流れ。
これ、人間の動画編集者が普通にやるワークフローそのものだ。
しかも、Codex はそれを、
- SCRIPT.md
- STORYBOARD.md
- scene wav
- timeline
といった“中間成果物”を維持しながら進めていた。
単なるブラックボックスではない。
かなりソフトウェア開発的な思想で、動画制作が組み上がっていく。
この辺りは、かなり未来感があった。
一番ハマったのは、日本語TTSだった
今回、最も苦労したのは動画生成ではなかった。
日本語TTSだった。
最初は、HyperFrames が推奨していた Kokoro ONNX をそのまま使った。
お馴染みのあの女性の声だ。
構成としてはかなり先進的で、
- ONNX Runtime
- 軽量モデル
- scene別wav生成
- CLIベース
など、ローカルAI時代を強く意識した作りになっている。
最初は、
「これはローカルで全部完結できるのでは？」と期待した。
しかし、現実はそう甘くなかった。
まず、Kokoro は長文に弱い。
長いナレーションを一括で渡すと、
token limit exceededのような形で停止する。
ところが、ここで Codex が面白い動きを始めた。
最初は単純に台本を短縮していたのだが、それでも制限に引っかかると、
scene分割
↓
sentence分割
↓
wav分離
↓
FFmpeg結合という工程を、自律的に組み始めた。
つまり、
「長いから失敗した」
で止まるのではなく、
“制作工程を変更して問題回避”し始めたのだ。
これはかなり驚いた。
しかも scene ごとに wav を分けていた。
つまり、
- scene-01.wav
- scene-02.wav
- scene-03.wav
のような構造になっていた。
これは実際の動画制作現場でもよくやる方法だ。
なぜなら、
- リテイクしやすい
- 秒数調整しやすい
- BGMと合わせやすい
- scene差し替えが容易
だからだ。
つまり Codex は、
“動画編集ワークフロー”そのものを理解しているように見えた。
ところが、問題はまだ終わらない。
ようやく生成された wav を聞いてみると、
日本語なのに英語っぽく読まれるのである。
例えば、
「ローマ字の練習、楽しく続けたいなら。」が、
“ローゥマァジィ…”
のような妙な発音になる。
最初は script 側を疑った。
しかし、script 自体は正常だった。
原因は、
voice/lang 指定だった。
さらに調べると、
- Kokoro ONNX の version
- voices-v1.0.bin
- 日本語voice
- lang=ja
- jf_alpha
などが複雑に絡み始める。
しかも、環境によって動作が微妙に違う。
最終的に、
「これは実験用途としては面白い。
だが、現時点で実用日本語TTSとしては厳しい」という結論になった。
そこで、Codex は方針転換を始める。
Kokoro を諦め、
Edge TTSへ切り替えたのだ。
しかも、scene分割構造は維持したまま。
結果として、
- scene別wav
- 日本語自然発音
- 45秒ちょうど
- MP4レンダ成功
まで到達した。
しかも、実際に聞いてみると、
Edge TTS のほうが、
はるかに自然で聞きやすい。これはかなり印象的だった。
ローカルAIの理想を追って Kokoro に挑み、
最後はクラウド側の Edge TTS に落ち着く。
この流れは、今のAI時代を象徴している気がする。
Kokoro TTS とEdge TTSで生成した音声の比較
どういう感じかは、以下で確かめて欲しい。
Script:
ローマ字クイズ。小学生向けの三択学習アプリです。Kokoro TTS で生成したおかしな音声
Edge TTS で生成した正しい音声
「動画を作っている」というより、
「AIプロデューサーと一緒に制作進行している」ような感覚感覚になっていた。
特に印象的だったのは、
“長いから失敗”ではなく、
“では、工程を分割しよう”へ進んだことだ。
ここに、Agent AI 的な匂いを強く感じた。
つまり Codex は、
「命令を実行するAI」
ではなく、
“完成へ到達するための経路”を探し始めている。
Token消費は重い ─ ただし初回だけだと思う
今回、Codex の 5時間制限枠を初めてかなり意識した。
結果として、使用量は約30％まで到達した。
普段、
- コーディング
- Markdown整形
- ドキュメント生成
程度では、ここまで消費することはあまり無い。
しかし今回は違った。
なぜなら Codex がやっていたのは、
単なるコード生成ではなかったからだ。
実際には、
- URL解析
- Browser capture
- Scene設計
- 台本生成
- TTS
- wav分割
- タイムライン調整
- render
- validate
- snapshot
- FFmpeg制御
など、かなり大規模な workflow を動かしていた。
しかも途中で、
- lib不足
- TTS失敗
- token limit
- 発音問題
- PEP668
などに遭遇し、そのたびに workflow を組み替えていく。
つまり今回の消費は、
“制作”ではなく、
“動画制作環境のブートストラップ”に近かった。
実際、今回かなり時間を食ったのは、
- WSL2
- Node
- nvm
- ffmpeg
- Chrome headless
- Python
- TTS
- ONNX
- Edge TTS
などの環境整備だった。
逆に言えば、ここを一度通してしまえば、次回以降はかなり軽くなる気がする。
実際、途中からは、
「URLを渡す」
↓
「capture」
↓
「scene生成」
↓
「render」へ近づいていった。
だから今回の30％消費は、
“初回構築コスト”として見るべきだろう。
【後日追記】
2本目にけいさんクイズアプリのプロモーション動画を、前回環境を引き継いで作成したら、消費率は83％程度に収まった。これがリアルなToken消費量だろうと思う。
とは言え、動画系が重いのは間違いない。
特に今回のように、
- TTS
- Browser automation
- FFmpeg render
- AI orchestration
まで絡むと、普通のコーディングタスクより遥かに Token を使う。
その意味では、Codex はかなり “Agent AI” 寄りだ。
単にコードを書くだけではない。
- 状況確認
- workflow変更
- scene構築
- render調整
など、制作工程全体へ介入してくる。
だから、この用途で本格的に使うなら、Proプラン前提だと思う。
一方で、
「たまに1本、紹介動画を作る」
程度なら、Plusでも十分現実的だろう。
特に今回感じたのは、
AI動画生成の本当のコストは、
GPUではなく“制作工程”側へ移り始めているということだった。
結論 ─ Webサイトが、自分で動画になる時代
今回の実験で、一番印象的だったのはここだ。
最終的に私がやったことは、
URLを渡しただけに近い。
もちろん、その後には、
- WSL
- ffmpeg
- Chrome
- Python
- TTS
- ONNX
- Edge TTS
など、現実的な調整は大量に入った。
だが、本質的には、
「サイトを読ませた」だけなのである。
すると Codex は、
- UI構造を確認し
- 小学生向けであることを推論し
- PWAであることを理解し
- sceneを組み
- コピーを書き
- ナレーションを生成し
- timelineを構築し
- MP4をレンダリングした
しかも途中で問題が起きると、
workflowそのものを書き換えるような動きを見せ始めた。
これはかなり衝撃だった。
従来、
「動画制作」
というのは、
- キャプチャ
- 編集
- 音声
- BGM
- タイムライン
- 書き出し
を人間が手作業で組み立てる世界だった。
しかし今回見えたのは、
Web体験
↓
構造解析
↓
Scene化
↓
映像化という、別の流れだ。
しかも、その中核にあるのは、
- HTML
- CSS
- Browser Runtime
- FFmpeg
- TTS
といった、極めて Web技術的なスタックだった。
これはもう、
「AI動画編集」
というより、
“Web Runtime が映像制作基盤になり始めている”と表現したほうが近い気がする。
そして、NotebookLM が
「知識をインフォグラフィックスと音声化」したように、
HyperFrames は、
「Web体験を映像化」し始めている。
今回の動画は、まだ45秒の小さな紹介動画に過ぎない。
だが、ここから先、
- LP紹介
- SaaSデモ
- PWA紹介
- WebGL演出
- 自動多言語化
- Shorts生成
などへ繋がっていく未来は、かなり見えている。
URLを渡す。
すると AI が、
- サイトを読む
- 特徴を理解する
- sceneを考える
- 台本を書く
- ナレーションを生成する
- timelineを構築する
- renderする
そして、Webサイトが “自分で動画になる”。
そんな時代が、もう始まりかけているのかもしれない。
あなたも今晩、自社のWebサイトで紹介動画を作らせてみるといい。
