launch-video について
launch-video は、プロジェクト固有の製品ショーリール制作を支援するスキルです。ストーリー調査、ビジュアル設計、音楽との同期、映像のレビューと納品を案内します。
主な機能
- 01プロジェクトの主張と根拠を調査
- 02プロジェクト固有のビジュアル構想を策定
- 03音楽タイムラインに沿ってショットを計画
- 04シーンとサウンドトラックのタイミングを同期
- 05レンダーをレビューして納品を準備
活用シーン
- 01リポジトリから製品ショーリールを制作
- 02技術的な仕組みを映像表現に変換
- 03アニメーションと生成音楽を同期
- 04完成映像をレビューしてパッケージ化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ dzhng/ skills --skill launch-videoインストール後、Claude Code で/launch-videoを入力して読み込まれたか確認します。
詳細
ローンチ動画
基準となるのはショーリールです。モーションデザイナーが自分の実力を示すために履歴書に載せる作品です。躍動感と野心があり、音楽に合わせて構成された、本格的なプロダクションであり、デモやプロトタイプではありません。思い切り作り込んでください。ストーリーはリポジトリが提供します。表現の腕前はあなた次第です。ここにテンプレートはありません。ほかのプロジェクト向けに見た目を差し替えられるような作品なら、失敗です。
ワークフロー
- ストーリーを見つける。 README、ドキュメント、ベンチマーク、ブランドアートを読みます。それぞれ出典を示しながら、何をするものかを一行で、内部でどう動くのか(視聴者は技術に詳しい人です)、そして何を証拠として印象づけるべきかを説明できたら完了です。リポジトリで裏付けられない主張には印を付け、意味を勝手に作り上げないでください。
- 作る前に演出する。 プロジェクトの本質(メタファー、ブランドアート、仕組み)から育てた視覚的コンセプトを一つ選びます。パネルを並べるのではなく、独自のルック、カメラ、決めの演出を持つ世界を作ります。次に、その仕組みに馴染みのある現実世界のたとえを一つ選びます(都市を建設する、厨房を切り盛りする、強盗を実行するなど)。各ステップをそのたとえに当てはめ、たとえの語彙で名前を付け、ひと目で説明できる身近な小道具をそれぞれに用意します(測量士の三脚、杭、クレーン、検査スタンプなど)。気の利いた演出より、わかりやすいリズムを優先します。視聴者が言葉を読まなくても、すでに知っているものを手がかりに各ステップを理解できるようにします。音楽のタイムラインに沿ったショットリストとして書きます。各ショットにカメラの動きと、モーションデザイナーが誇れる見せ場が一つずつ記されていたら完了です。説明が「カード/パネル/リストが現れる」だけのショットは、作り直します。
- 一つのタイミングソースから映像と音楽を作る。 すべてのイベント時刻を一か所にまとめ、シーンとサウンドトラックの両方がそこを参照するようにします。そうすれば、ヒットのタイミングをぴたりと合わせられます。音楽をコードで合成すれば、この同期を正確に保てます。
- ディレクターとしてレビューする。 ドラフトをレンダリングし、各ショットをコンタクトシートに並べ、計画を見ていないサブエージェントに新鮮な目で批評してもらいます。その後、各ショットにショーリールとして成立しているか問いかけます。サンプルではなく、すべてのショットが合格するまで修正と再レンダリングを繰り返します。
- 納品する。 サムネイルを作成し(以下のルールを参照)、マスターをレンダリングします(1080p60、高品質の H.264、320k AAC)。Finder で表示し、レンダリング結果と生成音声を除外したうえで、プロジェクトを独立したパッケージとしてリポジトリにコミットします。コマンド、タイミングの原則、主張の出典と方法論を記載した短い README を用意し、それらは映像の外に置きます。
ホワイトペーパーではなく、マーケティングを
製品と、印象に残るいくつかのメリットを先に伝えます。方法論、サンプルサイズ、欠損データの許容範囲、ベンチマークの注意事項、出典の引用は、動画やキービジュアルではなく、パッケージの README またはリンク先のレポートに記載します。細かい注記、アスタリスク付きの脚注、免責事項のブロック、自己弁護のようなナレーションは加えないでください。主張の正確さを保つために範囲を絞る必要があるなら、見出しそのものを絞ります。誤解を招く見出しを小さな文字で取り繕ってはいけません。各フレームは、見た目の品質だけでなく、読む負担も確認します。
説明するより、見せる
テキストの使用は最終手段です。画面に言葉を出す前に、それを不要にする映像を見つけます。変化するオブジェクト、変わっていく世界、アイデアを動きで表現する演出を使います。映像では伝えられない場合に限り、テキストを残します。製品の実際のコマンド、名前、正確さが必須の主張がこれに当たります。唯一の例外は状況の案内です。各ショットには何が起きているかを示す見出しを一つ付けます(動きに合わせて数値が増えるライブカウントのようなものでもかまいません)。そうしないと、優れたアニメーションも無秩序な動きに見えてしまいます。 ドラフトがラベル、キャプション、字幕で状況を説明しようとしているなら、テキストを書き換えるのではなく、ショットそのものを作り直します。
ショーリールにふさわしいか
モーションデザイナーは、このショットを自分のリールに入れるでしょうか?説明動画やデモに傾いている兆候は次のとおりです。
- アニメーション付きスライドデッキ。 要素がスライドインして、そのまま止まる静的なレイアウトです。リールではカメラが常にどこかへ動き、構図も変化し続けます。
- 見るのではなく、読む。 段落、UIカード、本文、見出しの下の字幕(字幕が必要な見出しは、アイデアが2つあるということ)です。リールでは、ドラマチックなスケールで短い言葉を打ち出し、仕組みはビジュアルで伝えます。
- メタファーが成立していない。 描写している内容と一致しない動きです。分割すると主張している部品を無視するカットや、背景とのコントラストが低く誰にも読めないラベルなどが該当します。画面上のオブジェクトに即した動きにしてください。
- 手法が1つだけ。 すべての要素が同じ方法で飛び出します。リールでは、奥行きとパララックス、スケールの対比、次のショットへ要素を引き継ぐマッチカットやトランジション、スピードランプ、照明と色の変化、パーティクルと物理演算、デザインとして動くタイポグラフィなど、幅広い表現を見せます。
- 平坦。 前景も背景も光もなく、すべてが同じ平面、同じスケールにあります。
- 音楽に無頓着。 動きが音楽を無視しているか、音楽が映像を駆動せず、映像の下で鳴っているだけです。
- 試作段階の3D。 フラットな光の下にある、テクスチャのないプリミティブにレンズ表現がないと、技術デモに見えます。作品を3Dにするなら、ゲームのシネマティックのように仕上げてください。表面のディテールや光を拾うベベルを備えた物理ベースのマテリアル、反射と柔らかな影、ブルームを加えるエミッシブ、そしてレンズ効果(アンビエントオクルージョン、被写界深度、グレイン、インパクト時の色収差)を使います。
ルール
- スクリーンショットではなく、作り直す。 UIはすべて、動かせるパーツに分解します。
- エフェクトの判断には、ライブプレビューではなくレンダリング済みのフレームを使う。 フレーム単位でレンダリングする環境(たとえばRemotionの手動アドバンス)では、ライブプレビューでは問題なく見えるポストエフェクトのスタックやキャンバスレイヤーが、気付かないうちに欠落することがあります。
- 主張は正確に保つ。 見出しに記載する主張をソースと照合し、見出しで適用範囲を明確にします。裏付けとなる証拠はドキュメントに残し、画面に何を載せるかは上記のマーケティングルールに従います。
- 音を聴くことはできません。 測定によってミックスを確認します(統合ラウドネスは約−11〜−14 LUFS、スペクトログラムでは指定のタイミングにライザーとインパクトがあること)。引き継ぎ時には、音声を耳ではなく測定で確認したと伝えます。
- サムネイル。 フィード(X)では早い段階のフレームが選ばれ、1フレームだけのポスターはスキップされます。そのため、プレビューを約0.3秒間プリロールとして保持してから、冒頭に移動します(音楽も同じ長さだけずらします)。再生時に画面がちらつかないよう、プリロールの背景を冒頭と同じにします。最適なプレビューは、製品が機能している様子(名前、タグライン、実行完了したコマンドとその出力)です。見出しの数字は、それに見合う見せ場となるショットを用意し、キーアートの静止画も別に用意します。