モデル / データセット
Alisa0808/vox-director avatar
Alisa0808/vox-director

vox-director レビュー: 1行のトピックから Vox 風ペーパーコラージュ動画を組み立てるエージェントスキル

Turn one topic into a finished Vox-style paper-collage explainer/ad video — automated end to end on Atlas Cloud + ffmpeg. An agent skill.

スター 1,914フォーク 294PythonMIT
GitHub

ひと目でわかる

これは何?
トピックを渡すとビートマップ、コラージュ静止画、モーション、ナレーション、BGM、字幕までを Atlas Cloud API とローカル ffmpeg で通すエージェントスキル。2つの人間承認ゲートを挟む設計と、モデル依存のコスト構造を読む。
誰に向いている?
向いているのは、Vox 風のペーパーコラージュという見た目を短尺で量産したい個人や小規模チームで、Atlas Cloud の API キーと ffmpeg を用意でき、生成物を目で選ぶ手間を許容できる場合だ。向かないのは、モデル選定やプロンプト設計を自分で握りたい場合、あるいは Atlas Cloud 以外の推論基盤に載せ替えたい場合で、README にはモデル ID がハードコードされた表があり、差し替えの手順は示されていない。
商用利用できる?
できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 35 日前です。
何の言語で書かれている?
主に Python です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

解こうとしている問題は「絵コンテ以降の全部」

動画生成の道具は増えたが、1本の説明動画を作る作業は依然として工程の連鎖だ。台本を書き、カットごとの画を作り、動かし、声を当て、音楽を敷き、字幕を焼く。vox-director が引き受けるのはこの連鎖そのもので、README の説明ではトピックを1行渡すと mp4 が出てくる。対象は、Vox の説明動画で使われる紙の切り抜き、破れた縁、テープ、ハーフトーンの網点、新聞の切り抜き、ビートごとのフラットな色、大きな見出し文字という編集的なコラージュの見た目を、自分でデザインせずに量産したい人だ。動画編集ソフトの操作を覚える代わりに、エージェントに一言投げる操作を選ぶ層に向いている。逆に、実写の撮影済み素材を活かしたいだけの用途や、コラージュ以外の画風を求める用途は想定外で、その場合は別の道具を探すほうが早い。

beats.json を軸にした6段階のパイプライン

処理は1プロジェクトにつき1つの beats.json を中心に回る。最初にトピックから物語の弧を選び、ビートマップを書く。ここが GATE 1 で、人間がビート構成を承認するまで先に進まない。次に同じビートを3から4種類のテーマで描き分けるスタイルの比較工程があり、GATE 2 として見た目を目で選ぶ。以降は自動で、ビートごとにコラージュのポスターを1枚生成し、そのポスターを動かし、ナレーターとBGMを付け、ffmpeg で連結、BGMをナレーションの下にダッキング、字幕とウォーターマークを焼き込んで final.mp4 に至る。README はこの流れを B-roll と呼び、同じエンジンを再利用する入力モードを2つ挙げている。話し手の映像が既にある場合は A-roll として ASR でビートに区切り、顔やリップシンクをフレーム単位で保ったままコラージュ風に作り替える。静止画が1枚ある場合は C-roll として、被写体を写真のステッカーとして切り出し、描き直さずに各ビートのポスターへ配置する。

見た目は画像生成の段で決まり、動きは後から足す

設計の要点として README が明示しているのは2つだ。1つ目は、コラージュらしさは画像の段で決まるという考え方。各ビートは完成したコラージュのポスターとして生成され、破れた紙や切り抜き、網点、見出し文字といった要素はすべてその画像の中に入る。ポスターが濃いコラージュでなければ、後工程では挽回できないと説明されている。2つ目は、動きは後付けだという点。既定では AI の動画モデルがポスター全体を動かす「生きているポスター」の経路を取る。一方で、紙が1枚ずつ組み上がるような演出が必要な場合は、ローカルのキーフレームエンジンがポスターをパーツに分解し、フレーム単位で動かす任意の経路がある。README はこの経路について、コンテンツフィルタを通らずピクセル単位で正確だと述べており、実在の人物を扱う場面に向くとする。フィルタを回避できるという主張は生成基盤側のポリシーと衝突しうる論点なので、採用前に自分で意味を確認したほうがよい。

モデルは表で固定され、実行前に一覧を取り直す

README には用途ごとのモデル表がある。コラージュのポスターは google/nano-banana-2/text-to-image、非実写のアニメーションは google/gemini-omni-flash/image-to-video、実在の人物やブランドを扱う場合は kwaivgi/kling-video-o3-pro/image-to-video、トーキングヘッドの作り替えは google/gemini-omni-flash/video-edit、写真をコラージュに固定するのは google/nano-banana-2/edit、ナレーションは xai/tts-v1、実在の人物の声でのナレーションは bytedance/seed-audio-1.0 のボイスクローン、音楽は minimax/music-2.6、要素の切り抜きは youchuan/v8.1/remove-background という割り当てだ。ただし README 自身がモデル ID は変わりうると注記し、実行前に GET https://api.atlascloud.ai/api/v1/models から最新の一覧を取得する実装だと説明している。表を仕様として読むのではなく、実行時に解決される参照として読むべきだ。A-roll では gemini-omni-flash/video-edit が失敗した場合に seedance-2.0/reference-to-video へ自動で再試行する記述があり、経路が1本ではないことが分かる。

導入は clone と API キーの2手

エージェントスキルとして配布されるため、Claude Code のようにスキルを自動検出する環境ではそのまま拾われる。他のエージェントは AGENTS.md から SKILL.md をたどる形だ。リポジトリから入れる場合は git clone https://github.com/Alisa0808/vox-director.git ~/.claude/skills/vox-director を実行する。配布パッケージの vox-director.skill をダウンロードし、Claude のスキル UI から入れる経路も用意されている。その後、Atlas Cloud のコンソールで発行したキーを export ATLASCLOUD_API_KEY="sk-..." で環境変数に置く。依存はエージェント本体、Atlas Cloud の API キー、ffmpeg と ffprobe、そして字幕とウォーターマークのオーバーレイに使う Python 3 と Pillow だ。README は ffmpeg の導入例として brew install ffmpeg、Pillow として pip install pillow を示している。起動はコマンドではなく自然文で、たとえば言語、アスペクト比、尺を指定して短尺のコラージュ動画を依頼すると、ビートマップの草案、スタイル比較、各工程を経て out/<project>/final.mp4 が出力される。

止まりやすい箇所と、向かないケース

最初の制約は外部 API への依存だ。キーフレーム、モーション、音声、音楽のいずれも Atlas Cloud 経由のモデル呼び出しで、ローカルで完結するのは ffmpeg の連結と字幕の焼き込みだけになる。API キーが無効、残高不足、あるいはモデル ID が変わって解決に失敗すれば、パイプラインはそこで止まる。次に、人間の判断が2回挟まる点。ビートマップの承認とスタイルの選択は自動化されておらず、これを省いて完全無人で回す使い方は README の想定にない。さらに、見た目の品質は画像生成の段に強く依存するという設計上の性質がある。ポスターが狙ったコラージュにならなければ、後段のモーションや音声では補正できない。加えて、A-roll は既存のトーキングヘッド映像を前提とするため、素材の音声が ASR で正しく区切れない場合の扱いは README からは読み取れない。コラージュ以外の画風、実写の質感をそのまま残したい案件、モデル選定を自分で握りたい案件には適さない。

代替手段との違いは「見た目を固定するか、素材を起点にするか」

同じトピックから動画を作る道具として比較しやすいのは、汎用のテキストto動画モデルに直接プロンプトを投げる使い方だ。この場合、シーンごとの画風は毎回プロンプトとモデルの気分に委ねられ、ビート構成や尺の管理は人間が外側で行う。vox-director はビートマップという中間表現を先に固定し、その上で各ビートを1枚のポスターとして生成する。つまり見た目の一貫性を、モデルの出力ではなくビート構造の側で担保しようとする。もうひとつの対照は、既存のトーキングヘッド映像をそのまま編集する経路だ。こちらは素材の顔と声を保つことを優先し、画風の変換は行わない。vox-director の A-roll はその中間に立ち、顔とリップシンクをフレーム単位で維持しながら背景と画風だけをコラージュに置き換える。どの経路を取るかは、素材の有無と、見た目をどこまで揃えたいかで決まる。

維持コストとライセンスの見取り図

リポジトリは MIT ライセンスで、同梱の SKILL.md や references/ 配下のプロンプト集、テーマのプリセットを改変して自組織向けに調整することは許容される。ただし生成に使うモデル群の利用条件はライセンスの外側にあり、Atlas Cloud の契約と各モデル提供元のポリシーに従う。ここは法的助言ではなく、確認先の整理として読んでほしい。維持の観点で効いてくるのは、README が自ら認めているモデル ID の流動性だ。実行前にモデル一覧を取得する実装になっているため、ID が変わっても一覧側が更新されていれば動く可能性があるが、表に載った特定モデルが廃止された場合の代替は README には書かれていない。API の従量課金も固定費ではなく、尺とビート数に比例して増える。ビートごとにポスター生成とモーション生成の呼び出しが発生し、スタイル比較の工程では同じビートを3から4回描き直すため、GATE 2 を何度もやり直すほどコストが積み上がる構造だ。

編集部の結論

向いているのは、Vox 風のペーパーコラージュという見た目を短尺で量産したい個人や小規模チームで、Atlas Cloud の API キーと ffmpeg を用意でき、生成物を目で選ぶ手間を許容できる場合だ。向かないのは、モデル選定やプロンプト設計を自分で握りたい場合、あるいは Atlas Cloud 以外の推論基盤に載せ替えたい場合で、README にはモデル ID がハードコードされた表があり、差し替えの手順は示されていない。導入前に確認すべきは、GET https://api.atlascloud.ai/api/v1/models が返すモデル一覧に nano-banana-2 と gemini-omni-flash が現時点で含まれるか、そして A-roll で使う gemini-omni-flash/video-edit が自分の素材で通るかどうか。MIT ライセンスなので同梱物の改変は自由だが、生成に使う各モデルの利用条件は別途 Atlas Cloud 側で確認する必要がある。

公式情報源

  1. Alisa0808/vox-director on GitHub
  2. Issues
  3. License: MIT
  4. README
コミュニティノート

コミュニティノート