AI Director：「一言で動画生成」を、検証できる制作パイプラインに分解する

AI Director は Hackson '+81 Builders: Make Tokyo a Builder City' のプロジェクトです。扱おうとしているのは、「生成」という二文字に隠れがちな問題です。一本の映像の難しさは、最初のショットが出てくる前ではなく、出てきた後にこそ現れます。ナレーションがショットより2秒長かったらどうするのか。2番目のショットのキャラクターは、1番目と同じ顔なのか。ブラウザを閉じて開き直したとき、直したセリフ、選んだ声、すでに課金して送信したタスクは残っているのか。

「一言で動画を生成する」デモは分かりやすいですが、届くのは1つのショットであって、1本の映像ではありません。AI Director の選択は逆です。監督の仕事を、絵コンテ、キャラクター、ナレーション、ショット、エクスポートという、個別に確認できる工程に分け、ローカルで動く監督用ワークスペースにしました。プロジェクトは perfact-tang/AIDirector_AI-81builders にあります。

検証できる絵コンテがあってこそ、映像になる

AI Director の入口は素材のアップロードではなく、何を撮るかを明確に書くことです。まず視覚スタイルを選びます。リアルな3D、日本のアニメ、2.5D のいずれかです。次にショットのテンポを5秒か10秒で選び、アイデアを入力します。AI はそれをもとに、絵コンテ、キャラクター、ナレーション、各ショットのプロンプトを含む制作計画を起草します。

重要なのは次の段階です。返ってくるのは、絵コンテらしい自由文ではなく、プロジェクト JSON です。バックエンドは組み込みの direct-h3-storyboards Skill を読み込み、その説明、参考資料、JSON テンプレートをモデルのコンテキストに入れ、validate_storyboard.mjs で出力を検証します。検証に通らない場合は最大2回まで再試行します。検証を通った構造だけがワークスペースに進みます。

一見するとただの実装詳細ですが、これはプロダクトの形そのものを決めています。自由文は読むことしかできませんが、構造化されたプロジェクトは項目ごとに編集でき、後続の工程で使え、エクスポートして開き直せます。絵コンテは AI に見せる下書きではなく、パイプライン全体の最初の契約なのです。

5つの工程。人の確認は常に入る

続く流れは、ガチャというより映画制作に近いものです。

1. 絵コンテとキャラクター：AI が起草したキャラクターとショットを確認し、セリフ、プロンプト、尺、アスペクト比を編集します。
2. キャラクター画像：キャラクターの画像プロンプトをコピーし、いつもの外部サービスで画像を生成して、アップロードし保存します。アプリ自身はキャラクター画像を生成しません。この工程をあえて外に置くことで、画像モデルの選択権を使う人に残しています。
3. ナレーション：ショットごとにセリフを編集し、声を選びます。1本ずつでも、まとめてでも生成できます。音声は Edge TTS で合成します。
4. ショット：ショットのプロンプト、ファーストフレームのプロンプト、尺、アスペクト比を確認します。各動画は、そのショットの現在のナレーションと、プロンプトに登場するキャラクターの保存済み画像を参照します。キャラクターがいないショットには、シーン参照画像が必要です。動画は ai& の Videos API を通じて MiniMax H3 で生成します。
5. プレビューとエクスポート：音声と動画を順番に再生するプレーヤーで確認し、生成ファイルを ZIP にまとめてダウンロードし、プロジェクト JSON を保存します。

人は「ワンクリック生成」のボタンの前で消えるのではなく、判断が必要な各所に役割を残します。キャラクターは似ているか、ナレーションは自然か、ショットのプロンプトは正確か、どれをやり直すか。AI が起草と生成を担い、監督が判断と取捨を担います。

ナレーションを編集に合わせる。編集をナレーションに合わせない

ナレーションは、このパイプラインで最も問題が表面化しやすい工程です。TTS はテキストから音声を作りますが、そのショットが5秒しかないことは知りません。しかも絵コンテの尺は、上流で変わる可能性があります。何もしなければ、結果は2つしかありません。ナレーションを切るか、ショットを長くするかです。

AI Director は、新しく生成したナレーションごとに尺を合わせます。ショットの現在の尺と比較し、その後ワークスペースで尺を変更した場合も同じです。

• すでに収まっている場合は、元の速度のまま。
• 長すぎる場合は、FFmpeg の atempo フィルターで加速します。初期倍率は「元の長さ / 目標の長さ」です。
• 加速後にもう一度測り、必要なら補正します。残った隙間は短い無音で埋めます。
• 無理に合わせるために音声の内容を切ることはしません。

UI には元の長さ、最終的な長さ、実際に適用した倍率が表示され、これらの値はエクスポートするプロジェクト JSON にも書き込まれます。測定には、コンテナが報告する長さではなく、デコード後の音声サンプルを使います。MP3 エンコーダーのパディングによる誤判定を避けるためです。動画を送信する前と、ナレーションを最終動画に戻すときも、同じ測定方法を使います。

さらにキャッシュがあります。元の TTS ファイルをローカルに残すので、目標の尺を変えたときは元の録音を再利用でき、同じテキストと同じ声でもう一度リクエストする必要はありません。時間だけでなく、呼び出しコストも節約できます。テンポを何度も調整する編集作業では、「生成が速い」ことより現実的な効果があります。

生成を止めても、送信済みタスクはキャンセルできない

動画生成は API 費用が発生する可能性があるため、バッチ操作は2つのモードに分かれています。続きから生成は既存の結果を残し、不足しているショットや変更されたショットだけを生成します。最初から再生成は対象のショットをすべて作り直しますが、古い動画は新しい結果が成功して置き換わるまで保持されます。

停止の意味も、ローカルとリモートで分かれています。ナレーションの生成を止めると、作業中のローカルプロセスもキャンセルされます。動画の生成を止めても、できるのは追加の送信を防ぐことだけです。すでに ai& に送信されたタスクはキャンセルできず、バックグラウンドで処理が続いている可能性があります。アプリは既存のタスク ID を復旧用に保持し、プロジェクトをインポートしても有料の送信キューを自動で再生しません。

この設計は、生成リクエストを送った時点で、その状態は完全にはローカルで制御できないという現実を認めています。状態が不明な送信がある場合は、まず ai& のコンソールで確認し、それから新しいタスクを作るか決めるのが正しい進め方です。生成を繰り返しクリックして、二重課金を招くべきではありません。費用と規約は生成前に確認します。アカウントの料金はワークスペースで確認でき、サービスが求める場合は動画サービスの規約も利用者本人が ai& のコンソールで承諾する必要があります。

ローカル優先を、ファイル単位まで具体化する

AI Director のフロントエンドは React + Vite、バックエンドは Express です。開発時はフロントエンドが 5173、バックエンドが 3001 で動き、/api へのリクエストはフロントエンドからローカルバックエンドへプロキシされます。API キーはバックエンドの .env にだけ置き、VITE_ 変数には入れません。ブラウザのコードに混入させないためです。

データの保存先も明確に分かれています。

プロジェクト JSON はキャラクター画像とナレーションを保持できますが、動画は常に別のローカルファイルです。別のコンピューターに移すときは、動画の ZIP をダウンロードし、.local/videos/ も保持する必要があります。ブラウザのデータを消すと、ブラウザ内の下書きとワークスペースの記録も消えます。脚本生成のタスク記録はバックエンドのメモリにしかないため、バックエンドを再起動する前に完成したプロジェクトをエクスポートしておくべきです。

この境界は、データがどこへ行くかも説明します。脚本のブリーフは ai& に、ナレーションのテキストは Microsoft の Edge TTS に、動画生成を依頼するときは参照素材が ai& に送られます。ローカル優先は完全オフラインという意味ではありません。何が手元に残り、何が出ていくのかを、少なくとも明確にするという意味です。

Skill は契約であり、プロンプトの一部ではない

direct-h3-storyboards は、システムプロンプトに適当に差し込む説明文ではありません。独自のディレクトリを持ち、指示、参考資料、JSON テンプレート、バリデーター、テストを含みます。npm run skills:install はこれをプロジェクトの .local/skills/ にコピーします。インストールはローカルで完結し、ネットワークリクエストは送りません。npm run skills:verify は、インストールされたコピーと組み込みのソースが一致するかを比較します。

実行時、バックエンドは決まった順序でこの Skill を解決します。まず DIRECTOR_SKILL_PATH、次にプロジェクトにインストールされたコピー、最後にリポジトリ組み込みのソースディレクトリです。CLI による自動の Skill 検出には頼らず、指示、必須の参考資料、プロジェクトテンプレートを明示的に読み込み、モデルの出力を検証します。代償は読み込みロジックを自分で保守する必要があることですが、利点は挙動を予測しやすいことです。同じ Skill のバージョン、同じテンプレート、同じ検証を使えば、モデルや実行が変わっても、出力構造が意図せずずれる可能性を下げられます。

これは、Skill の境界を明確にしておく必要があることも意味します。リポジトリの Skill は、より広い音声・音楽の計画ワークフローを説明していますが、このアプリが実際に実行するのは Edge TTS と ai& の MiniMax H3 だけであり、それらの追加生成器は動かしません。「ドキュメントに書いてあること」と「製品が実際にすること」を分けておくほうが、読者に推測させるより誠実です。

やらないこと

• キャラクター画像は生成しません。キャラクター画像は利用者が外部サービスで生成してアップロードする必要があります。キャラクターのいないショットには、シーン参照画像を自分で用意します。
• クラウドサービスではありません。フロントエンドもバックエンドもローカル利用を前提としており、使用中はターミナルを動かしておく必要があります。
• 動画をプロジェクト JSON に入れません。プロジェクトは開き直せますが、動画はローカルファイルと ZIP バックアップから復元します。
• 有料タスクを自動で再送しません。プロジェクトをインポートしても、生成リクエストは再送されません。
• UI 言語とコンテンツ言語を同一視しません。下部で簡体字中国語、English、日本語を切り替えられますが、変わるのは UI の文言だけです。セリフ、キャラクター名、プロンプト、プロジェクト内容、声の選択、読み上げ言語はそれぞれ独立しています。組み込み Skill は意図的に中国語の制作プロンプトを生成しつつ、名前、セリフ、歌詞の元の言語を保持します。

動かすために必要なもの

依存関係は少なくありませんが、どれも明確です。Node.js 22.12 以降、PATH の通った aiand CLI、venv と pip を備えた Python 3、そして libmp3lame を含む FFmpeg / ffprobe です。Windows では、これらの依存関係を WSL に入れる必要があります。設定したテキストモデルと動画モデルにアクセスできる ai& の API キーも必要です。

npm install
npm run skills:install
npm run skills:verify

python3 -m venv .venv
.venv/bin/python -m pip install -r requirements-tts.txt

cp -n .env.example .env
# .env に AIAND_API_KEY を記入

npm run dev

その後 http://127.0.0.1:5173/ を開きます。本番ビルドは npm run build、その後の npm start で 3001 番ポートからフロントエンドと API を提供します。デフォルトのテキストモデルは deepseek-ai/deepseek-v4.1-flash、動画生成は minimaxai/minimax-h3 です。ツールがデフォルトの場所にない場合は、AIAND_BIN、DIRECTOR_SKILL_PATH、EDGE_TTS_PYTHON、FFMPEG_BIN、FFPROBE_BIN で上書きできます。アプリのテストは mock またはローカルのメディア fixture を使い、有料の生成サービスは呼びません。FFmpeg に関わるテストには、ローカルに FFmpeg が必要です。

おわりに

AI Director の本当に面白いところは、AI にもう1つショットを生成させることではなく、監督の決定を、確認でき、修正でき、復元できるファイルの集まりに変えることです。検証済みの絵コンテ JSON、アップロードされたキャラクター画像、ショットの尺に合わせて調整されたナレーション、各ショットのプロンプト、そして復旧に使う生成タスク ID です。

一言で動画を生成するのは格好いいですが、届くのは一瞬の映像です。映像制作はパイプラインであり、取捨選択も、やり直しも、コストも、責任もあります。そのパイプラインを作ることは、もう1つきれいなショットを生成するよりも、「AI に映像制作へ参加してもらう」という問いそのものに近いのです。