Remotion カウントダウンビデオパイプライン は何をしますか？
Goal: 与えられたテーマと BGM から、88～90 秒 / 16:9 / ナレーションなし / 中英バイリンガル字幕 / すべてのシーンを楽曲の強いビートでカット した動画を生成し、 さらにカバー 3 種類、公開パッケージ、事実確認リスト を出力します。処理全体はコードで完結し、字幕を変更する場合は文字列を書き換えるだけでよく、再レンダリングには約 35 分かかります。
使用するタイミング
- 「このテーマを Douyin の知識動画 / ゲーム理論解説動画にしてほしい」
- 「特定の BGM でビートに合わせた動画を作りたい」
- 「小説のこの部分を動画にしてほしい」（フィクション IP の場合は
references/fact-check.mdを参照） - 完成品セット が必要な場合：動画 + カバー + 公開用キャプション + 事実確認
使用してはいけないタイミング
- ナレーションの吹き替え が必要な場合（本パイプラインは字幕のみのナラティブです。吹き替えが必要な場合は、まず TTS トラックを生成してからアラインする必要があります）
- 実写 / AIGC 素材のミックス編集 を行う場合（本パイプラインはコードによる SVG 描写のみです）
- 動画ではなく 画像 + テキスト のみが必要な場合
〇、スタイル DNA（最初に読んでください。すべて実測に基づいています）
| 項目 | 仕様 | 理由 |
|---|---|---|
| 画面サイズ | 1920×1080 / 30fps（縦向きは別途 Composition） | アカウントは 16:9 に固定。データ上、内容効率が高い |
| 長さ | 88～90 秒（約 42 小節） | 「60～90 秒 / 1 話」のテスト枠に最適 |
| 音声 | ナレーションなし、BGM + 合成効果音 | スタイル上の要件。TTS のアラインコストも回避 |
| 字幕 | 中英バイリンガルの 2 行、中国語は 22 文字以内、各フレーズの表示時間 ≥2.2 秒 | このアカウントのスタイル（Douyin の一般的な推奨は 1 言語だが、これはアカウント固有の選択） |
| 導入 | 最初の 1 秒 = 完全な対立文 + 具体的なオブジェクト | 2 秒離脱率が最大の弱点 |
| ナラティブ | 1 人の人物 + 1 つの問題 + 1 つの因果連鎖 | 「概念図鑑」や「群像ミックス」は避ける |
| 構造 | フック → タイトル → ルール → トラップ → 反撃 → 逆襲 → 暴露 → 昇華 → エンディング | references/script-template.md を参照 |
| リズム | 各シーンは楽曲の強いビートでハードカット。重要なアクションはビートに合わせる | カウントダウンは音楽の構造に基づくもので、手動アラインではない |
| ビジュアル | 暗めの背景 + メタル/木/金色の質感 + 大きなフォント + 少数のラベル | スマートフォンの縮小表示でも可読性を確保 |
| セーフゾーン | シーンの要素の y 座標 ≤ 850。字幕は y≈870～1000。左上のヘッダーは y 50～95 | 実測で最も失敗しやすい部分 |
| エンディング | スクリーンショット可能なリスト（保存ポイント）+ 質問文を必ず入れる | 保存率が最大の弱点 |
| 正確性 | フィクション IP は「図はイメージです」と明示。事実は階層に分けて表示 | references/fact-check.md を参照 |
一、8 ステップのワークフロー（順番に実行。スキップ不可）
ステップ 1：プロジェクトの立ち上げ（テーマ選択と確認）
- ユーザーがテーマを指定しない場合、まず 3 つの候補を提示（各候補に以下を明記：一文のコア / 最初の 1 秒のフック / なぜ描写可能か / 保存ポイント / リスク）。ユーザーが選択する。
- 候補はユーザーに提示する前に存在確認を行うこと：フィクション IP なら章名やエントリが確認できること。知識系なら出典が確認できること。
- ユーザーが選択後、そのテーマの原典資料を入手する（原文の段落が最良。二次情報のみの場合は、その出典の階層を明記。ステップ 8 参照）。
ステップ 2：音声トラックとビート解析（すべての時間制御の基礎）
# ① 音声トラック抽出（mp4/mp3 対応。システムに ffmpeg がない場合、自動的に imageio-ffmpeg のバイナリを使用）
python scripts/extract_audio.py 入力.mp4 work/ # → work/audio.f32 + work/music.mp3
# ② ビート / 強いビート / セクション / 調性
python scripts/analyze_beats.py work/audio.f32 src/beats.json
# ③ エネルギー分析、ウインドウ選択（重要なステップ）
python scripts/scan_energy.py src/beats.json work/audio.f32 --seconds 89
- 出力は以下を提供：START_BAR / END_BAR、小節ごとのエネルギーマップ、無音部分がウインドウの何パーセントを占めるか。
- 反転（どんでん返し）は無音部分の直後の最初の強いビートに配置 — これが動画全体で最も価値のある 1 秒です。
- ウインドウはエンディングの減衰部分を除外しないこと（切れの悪い終わり方を防ぐ）。
- もし曲がすでにシリーズで使用済みの場合、まだ使用されていない後半部分を優先的に選ぶ。視覚的な重複を避けるため。
ステップ 3：脚本を書く（src/script.ts）
- 各シーンは
bars（占める小節数）を宣言。すべてのシーンの bars の合計は END_BAR − START_BAR と等しくなければならない（そうでない場合、placeScenesが比例拡大縮小し警告を表示）。 - 字幕は
subsに記述：{zh, en, at}、atはシーン内の何拍目か（例：4.5 のような半拍も可）。1 フレーズあたり 4～5 拍が最適。 - 効果音は
cuesに記述：{id, beat, sfx, vol, impact}。impact:'big'= 白フラッシュ + 画面振動 + 色収差 + 音楽サイドチェインで 40 フレーム分ボリュームダウン。 - リズム予算：
フレーズ数 × 2.5～3 秒 ≈ 総時間。89 秒で約 30 フレーズ。
ステップ 4：ビジュアル部品とシーン（src/*/kit.tsx + src/*/scenes.tsx）
- 部品を先にすべて書き終えてからシーンを書く：1 テーマあたり通常 6～10 個の部品（例：鉄の箱 / 錠 / 鍵 / シュレッダー / 電子レンジ / 人物シルエット / 彫像 / ランプ / 宝くじ / カウンター / 道玉）。
- すべての部品は純粋な SVG。座標は 1920×1080 でハードコード。
translate/scaleで再利用する。 - シーンコンポーネントはビートに合わせて部品を配置することのみ担当：
const bf = (n) => beatFrame(scene, n)。出現は常にpp(f, bf(n), 8)のようなイージング関数を使用。 - チェックリストは
references/visual-kit.mdを参照。
ステップ 5：プロジェクトのセットアップ
1 つのプロジェクトに複数の動画を含める場合：src/<episode>/{script.ts,timeline.ts,fx.tsx,kit.tsx,scenes.tsx,Main.tsx} として構成。
src/Root.tsx に 2 つ目の <Composition> を登録。各動画は独自の beats.json と music.mp3 を使用する。
- 2 つ目の動画は独自のビート処理ラッパーを持つ必要がある（
fx.tsxの Shell/ImpactFlash は当該動画の cueFrame を使用する必要がある。そうしないと衝撃点がずれる）。 - オーディオは
<Audio startFrom={OFF}>で、内容全体は<Sequence from={-OFF}>でラップする。これによりシーン内部で「音楽フレーム」ベースで時間指定ができる。 - 詳細は
references/pipeline.mdを参照。
ステップ 6：静止画チェック（合格するまでレンダリングしない）
node <node> node_modules/@remotion/cli/remotion-cli.js still <Comp> out/s1.png --frame=<シーンの中間フレーム>
各シーンを 1 枚ずつ静止画として出力し、目視で以下を確認：
- 字幕がシーンの要素と重なっていないか（最も多い問題）
- 要素の重なり（ラベル同士、ラベルと図形）
- セーフゾーン（要素の y ≤ 850）
- スマートフォンの縮小表示でテキストが読めるか（中国語文字 ≥24px、メインタイトル ≥120px）
ステップ 7：レンダリングと出力検証
node <node> node_modules/@remotion/cli/remotion-cli.js render <Comp> out/<name>.mp4 --codec=h264 --crf=18 --concurrency=6
python scripts/check_mp4.py out/<name>.mp4 # 長さ / トラック数 / 解像度 / オーディオパラメータ
check_mp4.py は ffprobe を必要としません：mp4 ボックスを直接解析し、vide + soun の 2 トラック、長さの一致、1920×1080、AAC 48kHz を確認します。
ステップ 8：納品
python scripts/make_covers.py --src out/<静止画>.png --crop x0,y0,x1,y1 \
--title メインタイトル --kicker サブタイトル --sub 一言キャッチ --out-prefix out/カバー_XXX
以下 4 点を納品：
- 完成動画 mp4（ワークディレクトリのルートにコピー。ファイル名にテーマを含める）
- カバー 3 種類（16:9 / 3:4 / 9:16）——絶対に自動フレームキャプチャを使用しないこと
- 公開パッケージ（本文 + 固定コメント + カバー案 + 24 時間判定表）。テンプレートは
references/cover-and-publish.md - 事実確認リスト（フィクション IP には必須）+ 絵コンテ（タイムコード表）
二、不変のルール（すべて実測から得られた教訓）
- 最初のフレームはタイトルではなくフック：完全な対立文 + 具体的なオブジェクト（「人質は電子レンジの中に閉じ込められ、カウントダウンが進んでいる」）。
- 字幕のセーフゾーン：シーンの要素はすべて y ≤ 850 に配置。字幕は 870～1000。静止画チェックではこれを優先的に確認。
- 1 行の字幕 ≤22 文字、表示時間 ≥2.2 秒。中国語の主文 + 英語の対訳の 2 行。
- エンディングはスクリーンショット可能であること：3 ステップ / 3 信号のリスト + 「まずは保存しておくことをおすすめします」という文言。感想だけで終わるエンディングは保存されない。
- 無音部分 = 反転ポイント：
scan_energy.pyが無音部分が何小節目にあるかを教えてくれます。最も強力な反転をその後ろに配置してください。 - 大規模衝撃は控えめに：
impact:'big'は白フラッシュ + 画面振動 + 色収差 + 音楽のボリュームダウンを引き起こします。動画全体で 5～8 回で十分。多すぎると慣れてしまいます。 - 等速スライドは使用しない：すべての出現はイージング（
Easing.out(cubic)）を使用。ラベルの出現には少しの移動 + スケールを加える。 - フォント：「古いテキスト用に切り詰められたサブセットフォント」は使用しない（新しいテキストで文字が欠ける可能性があります）— システムフォントスタック
'Noto Sans SC','Microsoft YaHei'を直接記述してください。 - public/ は全体がコピーされる：使用する効果音のみを配置する（例：148 個 → 16 個。レンダリングごとに 60MB のコピーを削減）。
- Remotion の ETA は初期に過大表示される：「残り 3 時間」と表示されても心配しないでください。実測では安定して 約 1.35 フレーム/秒、2700 フレームで約 35 分です。
- フィクション IP の 3 段階注釈：原典原文 / 読者による整理 / 私の推測 — 動画内では最初の 2 段階の共通部分のみを記述。残りは事実確認リストに回す。
- 動画内に数字をハードコードしない（「四つの十二支」→「いくつかの十二支」）、章番号もハードコードしない（「第 359 章」→「第 359 章前後」）。
三、ディレクトリ構成
<project>/
├── public/music.mp4/3 # この動画の BGM
├── public/music.f32(+.json) # ビート解析用（削除可能）
├── public/sfx/*.wav # 調性に合わせて合成した効果音
├── src/beats.json # analyze_beats の出力
├── src/script.ts # スクリプト全体（内容変更はここだけ）
├── src/timeline.ts # シーン→ビートマッピング + OFF/TOTAL
├── src/Root.tsx # Composition の登録
├── src/fx.tsx # 画面振動 / 白フラッシュ / 色収差 / バイリンガル字幕
├── src/<episode>/** # 2 つ目以降のエピソード：独立した script/timeline/fx/kit/scenes/Main
├── tools/ # このスキルの scripts/
└── out/ # 静止画 + 完成動画 + カバー
四、参考ファイル
references/pipeline.md— 環境セットアップとコマンド一覧（このマシン固有のすべての注意点を含む：ffmpeg / scipy / npm なし）references/script-template.md— 脚本構造テンプレート + 拍数変換表 + 今回の 2 動画の実際のタイムコードreferences/visual-kit.md— ビジュアル部品の仕様、セーフゾーン、配色、よくある重なり問題references/sfx-and-mix.md— 効果音合成（調性に合わせる）、サイドチェイン、ラウドネスreferences/fact-check.md— フィクション IP の事実確認方法と「読者による再話」の注釈仕様（利用可能な Bilibili API を含む）references/cover-and-publish.md— カバー 3 種類の仕様 + 公開パッケージテンプレート + 24 時間判定examples/十日终焉-两集.md— 2 つの実例の構造、データ、決定記録
五、能力範囲（ユーザーに対して誠実に）
- 本パイプラインはナレーションを生成しません。吹き替えが必要な場合は、別途 TTS を用意し、字幕を再アラインする必要があります。
- ネットワーク制限環境（多くのドメインが DNS でブロックされている）では、フィクション IP の詳細は二次情報しか得られない場合があります — その場合はステップ 8 の事実確認リストに必ず含め、推測を記述しないでください。
- レンダリングは計算負荷が高い処理です。4 コアのノート PC で 1 本の 89 秒 1080p 動画に約 35 分かかります。「数分で出力」と約束しないでください。
- 著作権：BGM を Douyin 動画から抽出するのは、自己参照目的にのみ適しています。公開時には、プラットフォーム内の楽曲ライブラリ / オリジナルサウンドカードを使用してください。