マルチエージェントで長尺AI動画を生成するOSS「ViMax」が選ばれる理由

AI動画生成の OSS を自社プロダクトに採用するかどうか、判断に迷っていませんか。Open-Sora や Wan2.1 のような「単一の動画生成モデル」は次々登場している一方で、脚本作りからショット組み立てまでを一気通貫で自動化したい場合、何を選ぶべきかは依然として曖昧です。

そこで注目されているのが、香港大学 Data Intelligence Lab@HKU が公開する OSS「ViMax」です。Director、Screenwriter、Producer、Video Generator という映画制作の役割をマルチエージェントに分担させ、長尺動画を組み立てる設計を採用しています。GitHub Stars は 6,500 を超え、MIT ライセンスで商用利用も可能です。

ただし、技術記事として深掘りすると「単一の動画生成モデルではない」「商用 API オーケストレーターである」という重要な性質が見えてきます。この性質を理解しないまま Open-Sora や Wan2.1 と同列に比較すると、採用判断を誤りかねません。

本記事では、初見のエンジニアが ViMax を自プロジェクトで採用すべきか判断するために必要な情報を、「何ができる OSS なのか」「類似 OSS と何が違うのか」「メンテナンスは健全か」「採用判断のチェックポイントは何か」という 4 つの論点に沿って整理します。なお、本記事は README・GitHub API・公式ドキュメント・関連論文の文献調査をもとに執筆しており、動作検証は行っていません。

ViMax とは何か

ViMax は、香港大学 Data Intelligence Lab（HKUDS）が公開している、マルチエージェント方式の長尺 AI 動画生成フレームワークです。公式の説明文には「Agentic Video Generation (Director, Screenwriter, Producer, and Video Generator All-in-One)」と記載されています（出典: HKUDS/ViMax リポジトリ）。

ここでポイントになるのが、ViMax は「テキストから動画を生成する基盤モデル」そのものではなく、複数の専門エージェントが脚本作成・ストーリーボード設計・参照画像選定・ショット生成・連結までを担当する「オーケストレーター」であるという点です。動画クリップそのものの生成は、Google Gemini / Veo や ByteDance Doubao Seedance などの外部 API に委ねる構造になっています。

現在の AI 動画生成が抱える 3 つの制約

README では、現状の AI 動画生成技術が抱える典型的な制約として、以下の 3 点が示唆されています。

• 数秒〜十数秒の短尺クリップしか作れず、物語性のある長尺コンテンツが組み立てづらい
• 同一シーン内のキャラクターや背景の一貫性を保ちにくい
• 映像だけが先行し、脚本やナラティブが欠落しがちである

ViMax はこれらを単一の巨大モデルで解こうとせず、役割分担した複数エージェントの協調で解決しようとしています。

ViMax の解決アプローチ

具体的には、Screenwriter（脚本家）に相当するエージェントが入力アイデアや小説本文を脚本に変換し、Storyboard Artist（絵コンテ作成者）に相当するエージェントがシーンとショットを設計します。続いて Reference Image Selector が過去ショットとの整合性を保ったまま参照画像を選び、Image Generator・Video Generator にあたるツール群がショット単位の素材を並列生成します。最後に MoviePy などで連結し、1 本の長尺動画として出力する流れです。

人間の映画制作プロセスに対応付けてエージェントを切り出している点が、Open-Sora や Wan2.1 のような単一モデル系 OSS との大きな違いになります。

基本スペック

数値は GitHub API（2026 年 5 月時点）より取得しました（出典: HKUDS/ViMax リポジトリ）。Stars 6,500 超、Forks 1,000 超という規模は、研究室発の OSS としては比較的早期から注目を集めている水準です。

ViMax で何ができるのか

ViMax の README では、4 つの主要ユースケースが示されています。それぞれ入力形式と用途が異なるため、自分のプロジェクトがどのモードに該当するかを最初に確認してください。

Idea2Video

最も汎用的なモードが Idea2Video です。README には次のような最小入力例が記載されています（出典: HKUDS/ViMax README）。

idea = """
If a cat and a dog are best friends, what would happen when they meet a new cat?
"""
user_requirement = """
For children, do not exceed 3 scenes.
"""
style = "Cartoon"

idea でストーリーの種を渡し、user_requirement でシーン数や対象視聴者などの制約を加え、style で映像トーンを指定するという 3 変数構造です。脚本構造や絵コンテは Screenwriter や Storyboard Artist 系エージェントが内部で組み立てます。

Novel2Video と Script2Video

長文の小説や既存スクリプトを入力として渡す用途には、Novel2Video と Script2Video が用意されています。Script2Video の README 入力例は以下の通りです（出典: HKUDS/ViMax README）。

script = """
EXT. SCHOOL GYM - DAY
A group of students are practicing basketball in the gym. ...
John: (dribbling the ball) I'm going to score a basket!
Jane: (smiling) Good job, John!
...
"""
user_requirement = """
Fast-paced with no more than 20 shots.
"""
style = "Animate Style"

スクリーンプレイ形式の入力をそのまま受け取れる前提になっており、Novel2Video の場合は内部で長文を圧縮した上で脚本へ変換します。リポジトリ上には agents/novel_compressor.py という長文圧縮専用のエージェントが置かれており、長尺コンテンツのアダプト用途を強く意識していることが分かります（出典: HKUDS/ViMax/agents ディレクトリ）。

AutoCameo

ユーザー自身の写真を取り込んで作中キャラクターとして登場させる「AutoCameo」モードも README に記載されています。ただし、README のロードマップ表記からは AutoCameo の完全な統合は段階的に進められている状況がうかがえます。プロダクションでの利用を検討する場合は、最新の README とコミットログで対応状況を確認してください。

アーキテクチャ

ViMax のアーキテクチャを理解する鍵は、README に示された 9 層のパイプライン構造と、リポジトリの agents/・pipelines/・tools/ という 3 つのディレクトリの対応関係です。

9 層パイプラインの概要

README には以下のレイヤ構造が記載されています。

1. INPUT LAYER（アイデア／脚本／小説／参照画像／スタイル／設定）
2. CENTRAL ORCHESTRATION（エージェントスケジューリング、リトライ・フォールバック）
3. SCRIPT UNDERSTANDING（キャラ・環境抽出、シーン境界、スタイル意図）
4. SCENE & SHOT PLANNING（ストーリーボード、ショットリスト、キーフレーム設計）
5. VISUAL ASSET PLANNING（リファレンス画像選択、Look/Style ガイダンス）
6. ASSET INDEXING（参照画像のカタログ化、埋め込みベクトル化）
7. CONSISTENCY & CONTINUITY（キャラ・環境トラッキング、時間的整合性）
8. VISUAL SYNTHESIS & ASSEMBLY（画像生成、ベストフレーム選択、組み立て）
9. OUTPUT LAYER（フレーム、クリップ、最終動画、ログ）

この層構造は、入力 → 計画 → 視覚的合成 → 出力という制作プロセスを忠実にコード化したものと読み取れます。

agents/ 配下に並ぶ役割エージェント

リポジトリの agents/ ディレクトリ には、専門エージェントを実装した Python ファイルが 14 本ほど並んでいます。代表的なものを抜粋すると次の通りです（出典: HKUDS/ViMax/agents ディレクトリ）。

それぞれが独立した Python ファイルとして配置されており、自社向けに置き換えや拡張がしやすい構成になっています。これは「ブラックボックスではないか」を懸念する読者にとって重要な観察点です。

pipelines/ がモードごとの司令塔

各ユースケースに対応するパイプラインは pipelines/ 配下に整理されています。idea2video_pipeline.py、novel2movie_pipeline.py、script2video_pipeline.py の 3 本が並び、それぞれが対応する main_xxx.py のエントリポイントから呼ばれる構造です（出典: HKUDS/ViMax リポジトリ）。

tools/ による外部 API 抽象化

実際の画像生成・動画生成・リランキングは、tools/ 配下のラッパー経由で外部 API を呼ぶ作りになっています。image_generator_nanobanana_google_api.py（Gemini Nano Banana）、video_generator_veo_google_api.py（Google Veo）、video_generator_doubao_seedance_yunwu_api.py（Doubao Seedance）などのファイル名から、どの API を束ねているかが直接読み取れます。

加えて、PR #33 では render_backend.py と protocols.py が追加され、画像生成器・動画生成器を共通の抽象化レイヤ越しに差し替えやすくする設計が導入されています。具体的なツール群と RenderBackend の構造は、ViMax のコードリーディング起点として有用です。

RAG ベースの長尺一貫性

長尺動画でキャラクターや背景の一貫性を保つために、ViMax は faiss-cpu と langchain を活用した RAG ベースの参照画像インデックスを利用しています。pyproject.toml の依存関係には faiss-cpu>=1.12.0、langchain>=0.3.26、langchain-community>=0.3.27 などが並んでおり、ベクトル検索を前提とした「過去ショットからのリファレンス引き当て」を実装する設計が読み取れます（出典: HKUDS/ViMax の pyproject.toml）。

設定と利用フロー

ViMax の利用は YAML ベースの設定ファイルでモデルを切り替える構成です。configs/idea2video.yaml の実物は次のようになっています（出典: configs/idea2video.yaml）。

chat_model:
  init_args:
    model: google/gemini-2.5-flash-lite-preview-09-2025
    model_provider: openai
    api_key:
    base_url: https://openrouter.ai/api/v1
  max_requests_per_minute: 500
  max_requests_per_day: 2000

image_generator:
  class_path: tools.ImageGeneratorNanobananaGoogleAPI
  init_args:
    api_key:
  max_requests_per_minute: 10
  max_requests_per_day: 500

video_generator:
  class_path: tools.VideoGeneratorVeoGoogleAPI
  init_args:
    api_key:
  max_requests_per_minute: 2
  max_requests_per_day: 10

working_dir: .working_dir/idea2video

3 つのモデル階層

設定ファイルは chat_model・image_generator・video_generator の 3 階層に分かれています。チャットモデルは脚本生成や計画立案などのテキスト処理に、画像生成器はリファレンス画像・キーフレーム生成に、動画生成器はショット単位の動画合成に使われます。それぞれが独立したクラスパスとレート制限を持ち、個別に差し替え可能です。

OpenRouter + Gemini のデフォルト構成

デフォルトの chat_model は OpenRouter 経由で Google Gemini 2.5 Flash Lite を呼ぶ構成です。model_provider: openai と書かれていますが、これは OpenAI 互換 API として OpenRouter にアクセスする設計を意味します。

MiniMax プロバイダ対応

2026-03-23 にマージされた PR #36 では、MiniMax の OpenAI 互換 API がファーストクラスでサポートされました。model_provider: minimax を指定するだけで base URL が解決され、MINIMAX_API_KEY 環境変数経由でキーを供給できます。利用可能な MiniMax モデルとコンテキスト長は次の通りです（出典: HKUDS/ViMax PR #36）。

1M トークンのコンテキストは、長編小説の Novel2Video モードで脚本生成を 1 リクエストで完結させたい場合に効いてきます。

レート制限のデフォルト値が示すもの

注目したいのが video_generator のレート制限です。デフォルトでは max_requests_per_day: 10 と設定されています。これは利用者が Google Veo の API を呼ぶ頻度を、ViMax 側でも 1 日 10 件に抑えていることを意味します。動画生成 API は単価が高いため、無料枠や検証用途を前提とした設定です。本番運用で大量に動画を量産する場合は、API ベンダーのレート制限と料金プランを別途確認する必要があります。

類似 OSS との位置づけ

ここまで読んで「Open-Sora や Wan2.1 と何が違うのか」が気になっている読者は多いはずです。結論を先に書くと、ViMax と Open-Sora・Wan2.1 は「同じ動画生成 OSS」と一括りにできない、別レイヤのプロジェクトです。

Open-Sora との比較

hpcaitech/Open-Sora は、Sora ライクな動画生成基盤モデルを民主化することを目的とした OSS です。Open-Sora 2.0 は 11B 規模の Diffusion Transformer として 2025-03 に公開されており、2〜16 秒・最大 720p のクリップを直接生成できます。重みも配布されており、自前で学習・推論する用途に向いています。

一方の ViMax は、Open-Sora のようなモデルを「内包する」のではなく、Google Veo や Doubao Seedance のような商用 API を tools/ 配下のラッパーで束ね、脚本作成・ショット計画・整合性管理を含む長尺組み立てを担当します。動画生成そのものの責務は外部 API に委ねているため、Open-Sora とは抽象レイヤが異なります。

自前で重みをロードしてカスタム学習したい場合は Open-Sora、商用 API を組み合わせて長尺・物語性のある動画を組み立てたい場合は ViMax、という棲み分けになります。

Wan2.1 との比較

Wan-Video/Wan2.1 は、Alibaba Tongyi Lab がオープン化した動画基盤モデルです。Text-to-Video、Image-to-Video、Video-to-Audio、動画編集などの機能を備え、T2V-1.3B モデルは 8GB 程度の VRAM で動作可能と公表されており、消費者向け GPU でローカル生成できる点が大きな強みです。中英文字の描画にも対応しています。

Wan2.1 単体は「動画生成器」として強力ですが、脚本生成・ストーリーボード設計・キャラクター整合性管理といった「制作プロセス側」のロジックは提供しません。ViMax の tools/ 抽象化に Wan2.1 を組み込む構成はアーキテクチャ的にはあり得ますが、現時点で公式サポートされたコネクタは確認できません。

「自前 GPU でモデル推論まで完結させたい場合は Wan2.1」「商用 API を束ねて演出付きの長尺動画を作りたい場合は ViMax」と整理できます。

Mora との比較

研究文脈での類似プロジェクトとしては lichao-sun/Mora（Lehigh University + Microsoft、arXiv:2403.13248）が挙げられます。Mora は Prompt Selection、Text-to-Image、Image-to-Image、Image-to-Video、Video-to-Video の 5 エージェントで Sora を模倣する研究プロトタイプです。

Mora が「Sora 互換のジェネラリスト動画生成」を狙っているのに対し、ViMax は Director / Screenwriter / Producer / Video Generator という映画制作の役割分担をエージェントに割り当てており、制作プロセスそのものの設計が異なります。マルチエージェント協調の研究ベースラインとして Mora を、長尺・整合性重視の実装志向で ViMax を、という棲み分けが見えてきます。

4 軸の比較表

最後に、4 軸で整理すると以下のようになります。

この表を見ると、ViMax が「動画生成モデル」ではなく「制作プロセス用オーケストレーター」というポジションにあることが、改めて確認できます。

開発元とメンテナンス状況

OSS の採用判断で気になるのが、開発元の実績と現在の活動状況です。研究プロトタイプが放置されたまま停止するケースは少なくないため、ここを冷静に観察しておく必要があります。

HKUDS とは何者か

ViMax の開発元は、HKUDS（Data Intelligence Lab@HKU）という香港大学 Computer Science の研究室です。代表者の Chao Huang 准教授のラボページは Data Intelligence Lab@HKU で公開されています。

このラボは ViMax 以外にも、軽量 RAG フレームワークの LightRAG や、グラフ構造に対する LLM 拡張系の GraphGPT 系列など、複数の注目 OSS を継続的に公開してきました。Google Scholar の引用数も 11,000 を超え、研究的なバックグラウンドは強い部類に入ります。

コミット履歴から見た開発活動

GitHub API から取得したリポジトリメタによると、ViMax の直近 push は 2026-03-29 です。それ以前にも 2026 年 1〜2 月、2025 年末にかけてコミットが続いており、放置されたリポジトリではないことが確認できます（出典: HKUDS/ViMax リポジトリ）。

外部コントリビュータの存在

直近の主要 PR を見ると、PR #33（画像・動画生成器の RenderBackend 抽象化、2026-02-28 マージ）と PR #36（MiniMax プロバイダ追加、2026-03-23 マージ）の 2 本が、いずれもコアメンバー外のコントリビュータからの貢献でマージされています。研究室内で閉じない開発体制になりつつある兆候として、好意的に評価できる要素です。

リリースタグがない点

一方で、ViMax には現時点で Git タグ付きのリリースが存在せず、pyproject.toml 上では 0.1.0 の開発版段階となっています。Open Issues も 35 件あり、規模としては中程度です。

プロダクション利用を検討する場合は、コミット SHA で固定するなどの運用が必要になります。Semantic Versioning 運用が始まるまでは「main を追う前提」のプロジェクトと捉えてください。

採用判断のチェックポイント

ここまでの情報を踏まえ、ViMax を自プロジェクトに採用するかどうかを判断するためのチェックポイントを整理します。

ライセンスと商用利用

ViMax のライセンスは MIT です。商用利用・改変・再配布が可能で、著作権表示とライセンス全文の同梱を条件に、社内プロダクトへの組み込みも問題なく行えます。archived や disabled、fork はいずれも false で、アクティブな公開リポジトリです（出典: HKUDS/ViMax リポジトリ）。

環境要件

README に明記されている対応 OS は Linux と Windows です。macOS の明示的なサポート記載はないため、Mac で開発する場合は WSL や Linux サーバを別途用意する想定が現実的です。

ランタイムは Python 3.12 以上、パッケージマネージャは uv を採用しており、uv sync を起点とするインストールフローが README に記載されています。

注意点として、pyproject.toml には torch・torchaudio が pytorch-cu128（CUDA 12.8）ホイールで pin されており、GPU 環境を前提とした構成になっています。さらに PyPI のデフォルト index に清華大学ミラー（pypi.tuna.tsinghua.edu.cn）が設定されている点も覚えておいてください。日本のネットワーク環境からインストールする場合、index の切り替えやプロキシ設定の調整が必要になる可能性があります。

API コスト想定

動画生成は Google Veo や ByteDance Doubao Seedance などの外部 API に依存します。configs/idea2video.yaml のデフォルト設定では、動画生成のレート制限が max_requests_per_day: 10 に絞られています。

これは「無料枠で軽く触る」前提の保守的な値です。本番運用や商用サービスに組み込む場合は、対象 API の料金体系・レート上限・地域別の利用条件を必ず別途確認してください。長尺動画 1 本の生成に必要なショット数を見積もると、月間コストが大きく変わる可能性があります。

採用に向くケース・向かないケース

ここまでの観察をもとに、採用判断の指針を整理すると次のようになります。

採用に向くケース:

• 商用動画生成 API（Gemini / Veo / MiniMax / Doubao 等）を束ねて、脚本〜ストーリーボード〜長尺動画を一気通貫で組み立てたい
• 動画モデルを自前で学習させる予定はなく、API オーケストレーターとして OSS を活用したい
• マルチエージェントの実装を読み解き、自社用に拡張する余力がある

採用が向きにくいケース:

• 動画モデルの重みをローカルで動かしてオフライン推論したい（Wan2.1 や Open-Sora の方が適合）
• 厳密なバージョン固定とサポート契約を必要とするミッションクリティカル用途
• GPU を用意できず、商用 API のコストも負担できない

README の Coming Soon 項目に注意

README のロードマップには「AutoCameo の完全統合」「Dev mode branch」「Shot planning の改善」などが Coming Soon として記載されています。これらは現時点で完全実装が保証されていない機能群です。採用検討時には、必要な機能が現在のメインブランチに入っているかをコミットログで確認してください。

まとめ

最後に、本記事の冒頭で挙げた 4 つの論点に沿って、ViMax の採用判断材料を総括します。

何ができる OSS なのか: ViMax は単一の動画生成モデルではなく、Director・Screenwriter・Producer・Video Generator の役割を担うエージェントを束ねる「制作プロセスのオーケストレーター」です。Idea2Video・Novel2Video・Script2Video・AutoCameo の 4 モードを提供し、商用動画生成 API を組み合わせて長尺・整合性のある動画を生成します。

類似 OSS と何が違うのか: Open-Sora と Wan2.1 は「動画生成モデルそのもの」を提供する OSS であるのに対し、ViMax は「動画生成 API を束ねる」アーキテクチャを採用しています。同じ「AI動画生成 OSS」のカテゴリでも、解決している問題の階層が異なります。マルチエージェント研究プロトタイプの Mora とも、制作プロセス志向（Director/Screenwriter/Producer 分担）という設計思想の点で差別化されています。

メンテナンスは健全か: Stars 6,538、Forks 1,028、直近 push は 2026-03-29、最近の主要 PR はいずれもコアメンバー外からの貢献でマージされており、活発な開発状況にあります。香港大学 Data Intelligence Lab という研究室の継続的な OSS 公開実績も、健全性の傍証になります。一方で、Git タグ付きリリースがない点は留意が必要です。

自プロジェクトに採用していいのか: MIT ライセンスで商用利用は可能です。ただし、Linux / Windows 限定・Python 3.12 以上・CUDA 12.8 想定・PyPI 清華大ミラー設定・動画 API への課金前提という諸条件があり、用途と環境の整合を事前に取る必要があります。「商用 API を束ねたい」「自社向けにエージェントを拡張する余力がある」プロジェクトに向き、「動画モデルを自前で動かしたい」「厳密なバージョン固定が必要」用途には Wan2.1 や Open-Sora の方が適合します。

ViMax を選ぶ判断軸は、究極的には「動画生成モデル自体を作るのか、それとも動画生成 API の上に制作プロセスを構築するのか」という設計思想の選択です。前者なら Open-Sora や Wan2.1、後者なら ViMax、というのが本記事の整理です。採用検証を進める場合は、まず README とリポジトリの agents/・pipelines/・tools/ を実コードレベルで読み解き、自社の責任分界点と一致するかを確かめてください。