← 一覧に戻る
Remotion プロモ動画スキル 実装計画
2026年3月12日 22:30 → 3月13日 更新（音声あり版 + テストリスト追加）
一言でいうと
サービス情報を渡すだけで、TikTok/Instagram向けの縦型プロモ動画を自動生成するスキル
なぜこれが必要なのか
新しいサービスやアプリを作ったとき、「何ができるか」を伝えるショート動画を毎回手作業で作るのは非効率。何が当たるか分からないから、とにかく量産して反応を見たい。
nuchiの構想は「サービスを作る → 自動で動画を作る → SNSに投稿 → 反応を見る」というループ。その第一段階として、サービスの情報（URLや説明文）を渡すとRemotion（Reactで動画を作るツール）がプロモ動画を自動生成するスキルを作る。
放置した場合のリスク: 動画制作がボトルネックになり、アイデアの検証速度が落ちる。手作業だと1本に何時間もかかるが、自動化すれば数分で完成する。
ゴールと非ゴール
スコープ内
- サービス情報 → 縦型動画（9:16、15-60秒）
- BGM + 効果音 + テキストオーバーレイ + VOICEVOXナレーション
- URLからの自動スクショ撮影
- 量産可能な設計
- 独立したスキルとして動作
スコープ外
- ずんだもん解説動画（既存スキルが担当）
- アナリティクス連携（将来の別スキル）
- Kling/Sora/Veo3のAI動画生成
- Kling/Sora/Veo3のAI動画合成（将来拡張）
再利用できる既存資産
remotion-voicevox-template
既に持っているRemotion v4テンプレート。プログラマティック（コードから自動で）レンダリングの仕組みが構築済み。@remotion/bundler（ビルドツール）と@remotion/renderer（レンダリングツール）を使って、コマンドラインからの動画出力が可能。SNSプラットフォーム別の変換スクリプトもある。
逆瀬川さんの設計思想（参考記事）
- 状態遷移の再現 — 画面録画ではなく、Reactコンポーネント（UIの部品）として画面の動きを再現する。これにより品質が安定し、修正も容易
- フレームスクショ駆動 — 動画の特定フレーム（コマ）をスクショして評価→修正のループを回す。
npx remotion still --frame=N（特定フレームを画像として書き出すコマンド）を使う
- Opening → Demo → CTA の3部構成 — 冒頭で注目を引き、デモで価値を見せ、最後にアクション（ダウンロード等）を促す
アーキテクチャ（全体設計）
スキル（Claude Codeの拡張機能）とRemotionテンプレート（動画の実体）の2層構造。スキルが「指揮者」としてテンプレートを操作する。
remotion-promo-video/
├── skills/
│ └── promo-video/
│ ├── SKILL.md
│ └── references/
│ ├── schemas.md
│ ├── shot-patterns.md
│ └── style-guide.md
├── agents/
│ └── promo-composer.md
├── commands/
│ └── promo-video.md
└── scripts/
├── capture-screenshots.ts
└── render-promo.ts
remotion-promo-template/
├── src/
│ ├── Root.tsx
│ ├── PromoVideo.tsx
│ ├── components/
│ │ ├── Opening.tsx
│ │ ├── DemoSection.tsx
│ │ ├── FeatureHighlight.tsx
│ │ ├── CTA.tsx
│ │ ├── MockBrowser.tsx
│ │ └── TextOverlay.tsx
│ └── types.ts
├── scripts/
│ └── render-promo.ts
└── public/
├── screenshots/
├── bgm/
└── se/
テストリスト（t-wada式: 実装前に全て書き出す）
t-wadaの教え: 「テストリストを作る」ことが最も重要。実装前に「何を検証すべきか」を全て書き出しておく。テストが通ればそれでいい。
Phase 0: スキーマ契約
- □ PromoConfig に serviceName（サービス名）が必須
- □ PromoConfig に url が含まれる場合、URLとして有効か検証
- □ PromoConfig に duration を指定しない場合、デフォルト30秒になる
- □ PromoConfig に narration: true を指定するとVOICEVOXナレーション生成対象になる
- □ PromoOutput に outputPath が含まれ、.mp4 で終わる
- □ 不正な入力（空文字、型違い）でバリデーションエラーが返る
Phase 1: スクショキャプチャ
- □ URLを渡すと screenshots/ にPNG画像が保存される
- □ 保存されたPNGが1080x1920（縦型）のサイズになっている
- □ 存在しないURLを渡すとエラーが返る（クラッシュしない）
- □ タイムアウト設定が効いている（30秒で打ち切り）
Phase 1.5: VOICEVOX音声生成
- □ ナレーションテキストを渡すとWAVファイルが生成される
- □ 生成されたWAVの長さ（秒数）が取得できる
- □ VOICEVOX未起動時にわかりやすいエラーが返る
- □ 話者ID（speaker）を指定できる（デフォルト: ずんだもん）
Phase 2: Remotionコンポーネント
- □ Opening コンポーネントの frame=0 でサービス名が表示されている
- □ DemoSection コンポーネントにスクショ画像が表示されている
- □ CTA コンポーネントの最終フレームにアクション文言が表示されている
- □ ナレーション付きの場合、音声の長さに合わせてシーン長が調整される
- □ 3部構成のトータル長が指定された duration（秒数）と一致する
Phase 3: レンダリング
- □ render-promo.ts が MP4 ファイルを出力する
- □ 出力されたMP4が 1080x1920, 30fps である
- □ ナレーション音声が動画に含まれている（音声トラックが存在する）
- □ BGM音声と重なっている場合、ナレーションがBGMより大きい
- □ ファイルサイズが50MB以下（SNSアップロード制限内）
Phase 4: スキル統合
- □ 「プロモ動画作って」で SKILL.md がトリガーされる
- □ 「ずんだもん動画」ではトリガーされない（既存スキルに委譲）
- □ URL + サービス名の入力から動画ファイルまで一気通貫で生成される
TDD実装フェーズ（Red-Green-Refactor）
上のテストリストを元に、各フェーズでRed → Green → Refactorを回す。
Phase 0
スキーマ契約 — 「何を受け取り、何を返すか」
目的: スキルの入出力の「契約書」を先に定義する。これが全ての土台になる。
RED
PromoConfig型（入力: サービス名・URL・説明文・narrationフラグ等）とPromoOutput型（出力: 動画ファイルパス・メタデータ）のバリデーションテストを書く
GREEN
型定義とバリデーション関数を実装してテストを通す
Phase 1
スクショキャプチャ — 「サービスの画面を撮影する」
目的: URLを渡すとPlaywright（ブラウザ自動操作ツール）がサービスのスクショを撮影する。これが動画の主要素材になる。
RED
URL入力 → スクショ画像ファイル出力のテストを書く
GREEN
capture-screenshots.ts を実装
REFACTOR
モバイル・デスクトップ両サイズ対応
Phase 1.5 (新規)
VOICEVOX音声生成 — 「ナレーションを作る」
目的: ナレーションテキストをVOICEVOX（音声合成エンジン）に渡してWAVファイルを生成する。既存remotion-voicevox-templateの連携コードを流用。
RED
テキスト入力 → WAVファイル出力 + 長さ取得のテスト
GREEN
generate-voice.ts を実装（既存VOICEVOX連携から流用）
REFACTOR
話者選択・速度調整オプション追加
Phase 2
Remotionコンポーネント — 「動画の見た目を作る」
目的: Opening → Demo → CTA の3部構成コンポーネントを作る。逆瀬川方式のフレームスクショで品質を確認しながら進める。ナレーション音声の長さに合わせてシーン長を自動調整。
RED
各コンポーネントのスナップショットテスト + 音声長に応じたシーン長テスト
GREEN
Opening / DemoSection / CTA コンポーネントを実装
REFACTOR
TransitionSeries（シーン遷移アニメーション）で3部を接続
Phase 3
レンダリングパイプライン — 「動画ファイルを書き出す」
目的: bundle()（ビルド）→ selectComposition()（動画選択）→ renderMedia()（書き出し）のパイプラインを繋げる。ナレーション音声トラックも合成する。
RED
render-promo.ts が音声付きMP4ファイルを出力するテスト
GREEN
レンダリングスクリプトを実装
REFACTOR
SNS別変換（TikTok/Instagram/Shorts）を追加
Phase 4
スキル統合 — 「Claude Codeから使えるようにする」
目的: SKILL.md（スキルの定義ファイル）を書き、/promo-video コマンドで呼び出せるようにする。skill-creatorのevals（評価テスト）でトリガー精度を検証する。
RED
SKILL.md のトリガーテスト（正しい入力で発火するか、誤発火しないか）
GREEN
オーケストレーターSKILL.mdを実装
REFACTOR
フレームスクショ駆動の自己改善ループを追加
技術的な設計判断
| 判断ポイント | 決定 | 理由 |
|---|
| 新規プラグイン vs 既存拡張 | 新規プラグイン | YAGNI。ずんだもん動画とは目的が違う。混ぜると複雑になる |
| 音声 | VOICEVOX ナレーション付き | 既存 remotion-voicevox-template のVOICEVOX連携を流用。BGM+SE+ナレーションで訴求力UP |
| スクショ取得 | URL指定でPlaywright自動撮影 | 手動提供もフォールバックとして対応。Playwrightなら1枚2秒で撮影可能 |
| 縦型/横型 | 縦型（9:16）専用 | TikTok/Instagram/Shortsはすべて縦型。横型は将来対応 |
| 動画長 | 15-60秒 | SNSの最適長。TikTokは15秒、Instagramリールは30-60秒が推奨 |
Codex（GPT-5.4）からの指摘
1. 「2日で作れる」と「2日で検証できる」は別物 — 動画が作れることと、その動画が実際にバズるかどうかは別の検証軸。v1では「動画が自動生成できること」にフォーカスし、SNS投稿→分析は次のフェーズにする。
2. フレームスクショ駆動が最大の差別化 — 逆瀬川方式のnpx remotion still --frame=Nによる品質チェックループは、AIに「自分の出力を見て改善する」能力を与える。これは他の動画生成ツールにはない強み。
3. ショットパターンのカタログ化が量産の鍵 — 冒頭の掴み方（問題提起/数字インパクト/Before-After等）をパターン化しておくと、同じサービスでも複数バリエーションの動画を自動生成できる。
次のアクション
1
Phase 0: スキーマ契約テストを書く
PromoConfig / PromoOutput の型定義とバリデーションテストから着手。入出力の契約が全ての土台。
2
Phase 1-3: Red → Green → Refactor を回す
各フェーズでテストリストを先に作り、Redが通ったらGreenを最小限で実装。Refactorは必要最小限に。
3
Phase 4: skill-creator evals で品質保証
SKILL.mdのトリガー精度をevals（テスト）で検証。nuchiが言う「Test Listだけしっかりやってあとは放置」の思想。Greenに満たされればそれでいい。
ポイント
見送ったもの: Kling/Sora/Veo3などのAI動画生成API連携。魅力的だが、v1ではRemotionのプログラマティックレンダリングに集中する。AI生成動画は品質のばらつきが大きく、「量産して検証ループを回す」という目的に合わない。
nuchiの本質的な要望: 個別の動画ではなく「仕組み」。サービスを作る→動画が勝手にできる→反応を見る、このループが自動で回ること。今回のスキルはそのループの第一段階（動画生成）を担う独立パーツとして設計している。
参考にした記事: 逆瀬川さんのRemotion プロモ動画スキル記事。状態遷移再現・フレームスクショ駆動・Opening→Demo→CTAの3部構成を全面的に採用している。