動画制作 (make-video)

動画制作 (Make a video)

ユーザーがあなたと一緒にYouTube動画を作ります。長尺解説動画（16:9）とShorts（9:16）を、コードでアニメーション化し、 Remotionで描写、Geminiの音声でナレーションをつけ、キャラクタースプライトが登場することがよくあります。このスキルがその全プロセスです。 ツールは<videokit>、このスキルのリポジトリのvideokitフォルダにあります（何かを実行する前に references/toolkit.mdを読んでください）。<videokit>が実際のパスに置き換えられていない場合は、 ユーザーにリポジトリをクローンした場所（vk.pyがあるフォルダ）を尋ね、そのパスを使用してください。

ユーザーが最も重視するのは以下の3点であり、これらがプロセスの設計理由です。

1. ドラフトが承認されるまで、何も作り始めないこと。 ユーザーは、ストーリーと各シーンがどのように 見え、聞こえるかを先に見たいのです。トランジション、アニメーション、照明、効果音、品質についてです。 計画を変えるのは数分のコストですが、レンダリングをやり直すには数時間かかります。
2. プロフェッショナルに見えること。 モーションブラー、イーズされたモーション、奥行き、本物のような 照明、すべての動作に対応するサウンド、クリーンな1080pを備えた、意味のあるトランジション。 references/pro-look.mdに、それが実際に何を意味するか、どのコンポーネントがそれを実現するかが 記載されています。
3. 完成した動画が欲しいのであって、質問の嵐は望んでいないこと。 レビューエージェントが プロセス中の疑問に答え、固定の10項目チェックリストに基づいて作業を採点します。ユーザーは スコアが9/10に達した時点で動画を受け取ります。references/review.mdにその方法が書かれています。 誰が何を決定するか、チェックリスト、プロンプト、そしていつ停止するか。レビューは早い段階 （ドラフト、アニマティック）で行われ、変更が安価なうちに実施され、最後だけではありません。

ステージ

各✋は停止を意味します。続行する前に回答を待ちます。✋ user: ユーザーが決定します。✋ reviewer: レビューエージェントが決定します（動画全体に対して1つのエージェントが担当し、SendMessageで継続 - review.mdを参照）。

0. 概要 (Brief) ✋ user

リクエストから判断できないことを、AskUserQuestionで尋ねます（1回の呼び出しで最大4つの質問。残りは2回目の呼び出しで）。 以下の項目について、トピックから推測できる場合でも、勝手に仮定しないでください。

• フォーマット: 長尺動画 (16:9, 1920×1080) · Short (9:16, 1080×1920, 3分未満) · 両方（長尺動画とそこからカットした3～5本のShort）。
• ナレーション: AI音声（Gemini TTS。サンプルを送信します）· ナレーションなし（音楽＋画面上のテキスト）· ユーザー自身の録音。
• ルック: トピックに合った具体的なスタイルを3～4個提案します（例：本物の光を使ったシネマティックなコード描画空間、 クリーンでフラットなモーショングラフィックス、手描きの落書き、絵本の切り絵）。それぞれ一行で説明します。
• キャラクター: 既存のキャラクタースプライト（<videokit>/sprites内。python vk.py charactersで一覧表示）· 画像生成ツール（Gemini Nano Bananaなど。有料）で新しく生成· 絵文字 · コードで描画 · なし。
• その他すべてのアセット（小道具、オブジェクト、アイコン、背景）- これは毎回別途質問します。 コードで描画（無料。エフェクトライブラリのルック）· 絵文字（無料。Emojiコンポーネント、他と同様に照明が当たる）· 画像生成ツール（Geminiなど。有料）· ドラフトでアセットごとに決めるミックス。毎回尋ねます。 ここでユーザーが選択した場合のみ、生成画像が使用されます。
• 音楽: オリジナルスコア（ムード: 不思議 / 緊張 / 遊び心 / 壮大）· この動画のために一音一音作曲されたスコア （シーンに同期したテーマ、コード、ヒット音 - toolkit.md参照「A composed score」）· ユーザー自身の曲 （ユーザーが音声と歌詞を送信。ダウンロードは禁止）· なし。

また、トピック、尺、言語が明確でない場合は、それらも確定させます。その後、プロジェクトを作成します。 python -X utf8 vk.py new <folder> --title "..." --format long|short|both （videokitフォルダから実行。プロジェクトはその隣に作成されます）。

1. ドラフト (Draft) ✋ reviewer、その後 ✋ user

トピックを調査し（すべての事実を確認。今日の日付に依存するものに注意）、script.mdを書き （ナレーション。> の行ごとに1行の録音行）、次にプロジェクト内のテンプレートからplan.mdを書きます。 references/draft.mdが各セクションを説明しています。核心はシーンごとの表です。各ショットについて、 ナレーション、見えるもの（とキャラクターがそこで何をするか）、カメラとアニメーション、 イン/アウトのトランジション、照明と色彩、効果音、音楽を記載します。さらに、ルック、モーション、 照明、トランジション、サウンドの計画、品質仕様、Shorts（「両方」の場合）、出典付きの事実、 コストも含めます。フックの選択肢も2～3個書きます（それぞれ最初のセリフと最初のフレーム）。 Shortの場合は、draft.mdの「最初の3秒」のルールに従います。1秒までに驚き、フレーム0でアクションと音、 明るい最初のフレーム。実際のShortのデータでは、視聴回数はここで決まることが示されています。 ユーザー自身のデータはreferences/channel-numbers.mdにあります。

ドラフトレビュー: plan.mdとscript.mdを使用してレビュアーを起動します（review.md「起動」を参照）。 見つかったすべての欠陥と、ドラフトがスコア2未満の項目に対して修正できるものを修正します。 そのフックの選択をドラフトに取り入れ、採用したものとしなかったものをout/review/decisions.mdに記録します。

その後、ユーザーに表示します。チャットに短い要約（数行のストーリー、シーンのコンパクトなリスト、 ユーザーが決定する必要があること、レビュアーの予測スコアを一行で）とplan.mdへのリンクを表示します。 承認または変更を求め、修正し、ユーザーがゴーサインを出すまで繰り返します。 それまでは録音、生成、アニメーションを一切行わないでください。これがユーザーのルールです。

2. 音声 (Voice、ナレーションがある場合)

• デフォルト音声（video.json: Gemini "Kore"、speed 1.2）は質問不要です。新しい音声や スタイルの場合: vk.py voice samples → サンプルを送信（SendUserFile）→ ✋ user: ユーザーが耳で選びます （エージェントは聞こえないため、これはレビュアーには回しません）。video.jsonのspeedとともに設定します。
• vk.py voice record（キャッシュあり。同じ行は他のプロジェクトから無料で再利用）、次に vk.py words（単語のタイミング＋各行がスクリプト通りかどうかのチェック。フラグが立ったものは聞いてください）。
• Gemini 402 = プリペイドクレジット切れ: 停止してユーザーに伝えます。

3. ルック (Look) ✋ reviewer

• 承認されたドラフトのアセットリストに従って、すべてのアセットを作成します（コード、絵文字、Gemini、または既存）:
  • 既存のスプライトはscripts/build.pyのCHARACTERS / PROP_DIRSに配置。
  • 生成画像（承認された場合のみ）: Gemini (Nano Banana) などの画像生成ツールを使用し、透明PNGにカットして 同様に取り込みます（toolkit.md「Gemini pictures」）。
  • 絵文字: <Emoji char="🚀" .../> (fx/emoji.tsx) にシーンのリムライトとコンタクトシャドウを追加。
  • コード: fxライブラリ（LitSphere、Sun、図形、DrawPath...）を使用してシーン内で描画。
• スタイルフレームを3～4個作成します。ドラフトのキーモーメントをフルに照明し、コンタクトシートとして （vk.py stills ...）レビュアーに送信します（「途中の選択」）。ルックを承認するか、変更すべき点を 指示します。回答をログに記録します。

4. ビルド (Build)

1. scripts/build.py: ドラフトから設定を入力 - ポーズ、キュー (c.at(line, 'phrase'))、MOVES （各セクションの登場方法）、effects()（すべてのイベントに対応するサウンド）、music() （ムード、強弱の弧、アクセント - または作曲スコア）、ambience()、YouTubeテキスト。 vk.py buildを実行。

2. シーン: src/scenes/にシーンごとに1ファイル。キューに基づいてストーリー秒単位で記述し、src/fx （カメラ、深度レイヤー、照明、パーティクル、キネティックテキスト、キャラクタートラック）を使用します。 それらをsrc/Video.tsxにトランジションとともにリストアップします。キャラクターをアクションの中に 保ちます（画面上のものの上に立つ、乗る、指さす、反応する）。浮遊しているだけのキャラクターは 埋め草と見なされます。まずすべてのショットをブロッキングします。配置、キューへのタイミング、動きを 行ってから、照明とリッチネスパスに進みます。「動き」はキャラクター以上のものを意味します。ブロッキングから、 各ショットにはドリフトまたは移動するカメラ、CamLayer深度バンド、そして動いている何か別のものがあります。 キャラクターの背後が静止した世界でスコア20/20を獲得したShortでも、実際に動きを見ると退屈すぎると 評価されました。

3. アニマティック (Animatic) ✋ reviewer: vk.py animaticで動画全体を実サイズの半分、実際の音声で、 モーションブラーなしでレンダリングします（30秒のShortで約1.5分）。これに対してペーシングチェックを 実行します。レビュアーに送信します（アニマティックプロンプト）。仕上げ作業の前に、ここでフック、 タイミング、明瞭さを修正します。

4. Shorts（「両方」の場合）: build.pyでkit.shorts.buildを使用して仕様を設定。src/shorts/にShortごとに1シーン。

5. リッチネスパス: references/pro-look.mdの「リッチにする」に従ってショットごとに確認し、ショットが 平板な箇所にエフェクトを追加します。各ショットには以下が必要です:

   • 奥行きのある背景
   • 見える光
   • 世界に溶け込む被写体
   • 前面にあるもの
   • 決して止まらないカメラ
   • 背景の動き
   • フィニッシュ
   • サウンド

   すべての動画はリッチに感じられるべきなので、これは仕事の一部であり、追加作業ではありません。 ただし、すっきりと保つために抑制のルールを守り、テキストにはエフェクトをかけないでください。

5. チェック (Check、クリーンになるまでループ)

vk.py qaで、すべてのキューとすべてのトランジション中間点をコンタクトシート（out/qa/）にレンダリングし、 次に自動チェックを実行します → out/qa/<comp>_checks.md: YouTube/TikTokのボタンやタイトルの下にあるテキスト、 44 px未満のテキスト、重なりやフレームからはみ出しているもの（ページ自体で測定）、最新のレンダリングでは、 画像がほとんど変わらないストレッチ、背景が静止しているショット（フレームの25%未満しか動いていない）、 音声の途切れ、フレーム端の露出した帯、ループの継ぎ目、ラウドネスをチェックします。リストアップされた すべての問題を修正し、「確認推奨」の項目も確認します。次に、references/pro-look.mdのチェックリストに 照らしてコンタクトシートを確認します - トランジションの中間、照明の方向、シーン内のキャラクター、 平板なフレームがないこと（平らまたは空っぽに見えるものはすべてエンリッチ）。修正し、再度実行します （vk.py qa --autoはチェックのみを再実行。約1分）。フルレンダリングの前に短いテストレンダリング （vk.py render --frames 0-150）を行い、実際の動きとレンダリング速度を確認します。レンダリングは 変更のない4秒チャンクを再利用するため、修正後はレンダリングを再実行するだけです（--freshはキャンバス 描画を変更したか、ビデオファイルを交換した場合のみ）。

6. 最終 (Final) ✋ reviewer

• vk.py final（各Shortに対してvk.py final --comp Short-<id>）: 1080p H.264、v1/v2...としてバックアップ、 サイズ、fps、コーデック、-14 LUFS、トゥルーピークをチェック。電話プレビューや720pコピーは作成せず、 1080pファイルのみを提供します。その後、それに対してvk.py qa --autoを実行。
• 最終レビュー（review.md「ラウンドと停止条件」）: レビュアーがチェックリストに基づいて採点し、 タイトルを選択します。欠陥と優先度の高い修正項目を修正し、決定事項をログに記録し、再度レンダリングして、 新しいバージョンを以前のバージョンと比較できるように送信します。合格条件は18/20で、0点の項目がなく、 未解決の欠陥がないこと。3ラウンド後、またはラウンドで新しい発見がなくスコアが維持された場合は、 そこで停止します。
• TikTok（Shorts。ユーザーがそこにも投稿する場合）: vk.py final --platform tiktok → " (TikTok).mp4": グレインなし、ダスト半減、高ビットレート、軽いシャープネス。TikTokがアップロードを強く再エンコードするため。
• サムネイル（src/Thumbnail.tsx → 1280×720 jpg）、captions.srt、youtube.md（タイトル、チャプター付きの 説明、タグ、AI音声使用の開示）。Short用のshorts.md。

7. 納品 (Deliver)

完成した動画を、約30 MB未満の場合はSendUserFileで送信します（Shortは通常これに該当）。それ以外の場合は クリック可能なパスを提供します（TikTokカットは通常大きいので、そのパスを提供）。動画に何が含まれているかを シーンごとに要約し、チェック結果を報告します: レビュアーの最終スコア（および以前のラウンドのスコア）、 まだ2未満の項目、レビュアーのチャンネルノート（チャンネル全体に関するNote - 彼らの判断）、および レビュアーはサウンドをメーターのみで判断したこと（ユーザー自身の視聴によるサウンドチェックが最後の確認 であること）を伝えます。アップロードノートを追加します。その後、プロジェクトメモリノートを保存または更新します （何が、どこで作られたか、ユーザーが行った決定）。後でユーザーが投稿したShortのパフォーマンスについて尋ねた 場合は、その行をreferences/channel-numbers.mdに追加します。

常に適用されるルール

references/house-rules.mdに恒常的なルールがあります。動画ごとに一度読んでください。要約: APIキーを決して表示しない。Gemini画像は承認なしに使用しない。曲をダウンロードしたり、他のアーティストの 歌詞を画面に表示したりしない。「ちょっと聞きたいだけ」の質問には回答のみ、ビルドはしない。ビルド前に ドラフトを作成する。1080pのみ。レビュアーがステージの質問に答え、概要、ドラフト、新しい音声、金銭、 公開に関するものはユーザーが決定する。

参考文献

• references/review.md - レビューエージェント: 誰が何を決定するか、10項目のチェックリスト、各ステージの プロンプト、決定ログ、停止条件。
• references/draft.md - ドラフト（plan.md）の書き方と提示方法。Shortの最初の3秒ルールを含む。
• references/channel-numbers.md - ユーザー自身のYouTube統計（Shortごとの維持率、各オープニングの効果） とStudioの読み方のテンプレート。
• references/pro-look.md - プロフェッショナルスタンダード: トランジション、アニメーション、照明、 パーティクル、タイポグラフィ、サウンド、品質チェック、レンダリングパフォーマンス、およびそれぞれの コンポーネント。
• references/toolkit.md - videokitコマンド（自動チェック、アニマティック、TikTokカット）、 プロジェクトレイアウト、ストーリークロック、build.pyフック、Shorts、ミュージックビデオ、 Windowsの注意点。
• references/house-rules.md - 恒常的なルールとその理由。