mcpField
M
motion-graphic-director

motion-graphic-director

github.com/maizecobraクリエイティブ・メディア4103 回インストール36 週間前に更新
リポジトリ

motion-graphic-director について

Remotionのモーショングラフィックス動画を実装前に計画するスキルです。台本分析、ビジュアル設計、フレーム単位のタイミング策定を進め、コーディング前に承認を挟みます。

主な機能

  1. 01台本と感情の流れを分析
  2. 02シーンごとのビジュアル設計書を作成
  3. 03フレーム計算ツールでタイミングとスプリングを確認
  4. 04ビート表とトランジション仕様を作成
  5. 05実装前の承認ステップ

活用シーン

  1. 01SRTやナレーション原稿をシーン案に整理
  2. 02動画制作前にビジュアル案を確認
  3. 03レンダリング前にタイミングやトランジションの問題を発見

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/maizecobra/motion-graphic-director-skill --skill motion-graphic-director

インストール後、Claude Code で/motion-graphic-directorを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
package.json
LICENSE
examples/
video-example-1.md
video-example-3.md
video-script-1.md
video-script-2.md
video-script-3.md
video-example-2.md
references/
design-doc-format.md
design-system.md
motion-graphic-prompts.md
frame-timing-format.md
editorial-patterns.md
scripts/
srt_to_script.py
frame_calculator.py

詳細

モーショングラフィックディレクター

このスキルでは、コードに触れる前に、プロのモーショングラフィックディレクター兼動画編集者のように考えます。最終的な Remotion 動画の品質は、ここで下すデザイン上の判断の質、そして実装に入る前にそれらの判断を正確なフレーム番号へ落とし込めるかどうかで決まります。

ワークフロー

すべての動画は、次の手順どおりに進めます。手順を省略しないでください。

1. SRT/Script Input
2. Script Analysis       →  script-[name].md
3. Visual Ideation       →  video-design-[name].md   (shown to user for approval)
4. User Approves Design
5. Frame Timing          →  frame-timing-[name].md   (calculator + beat table for every scene)
6. User Approves Timing
7. Remotion Build        →  uses remotion-best-practices skill

手順 3 と手順 5 の両方で、先へ進む前にユーザーの承認が必要です。手順 5 は任意ではありません。レンダリングではなく書面上で、タイミングの不具合、無音区間の問題、spring の設定ミス、トランジションの競合をすべて見つける段階です。


手順 1:スクリプトを解析する

SRT ファイルを受け取った場合は、同梱の変換スクリプトを実行します。

python scripts/srt_to_script.py <input.srt> "<Video Title>" [output.md]

これにより、SRT の各字幕キューに 1 つのセグメントを割り当て、正確なナレーションテキストを含む script-[name].md が生成されます。形式は examples/ にあるサンプルスクリプトと同じです。セグメント名は汎用のプレースホルダー(「Segment 1」など)になっているため、手順 2 の分析で意味のあるシーン名に変更します。

SRT ではなくナレーションのテキストをそのまま受け取った場合は、同じ形式に手作業で構成します。正確な形式については references/design-doc-format.md を、参考例については examples/video-script-1.md を参照してください。


手順 2:アイデアを出す前に分析する

何かをデザインする前に、スクリプトから次の項目を抽出します。

  • 核心となる主張 — 証明すべき唯一のアイデアは何か?
  • 感情の起伏 — どこで緊張感が高まるか? どこで安堵が訪れるか? クライマックスはどこか?
  • 重要な用語 — 専用の視覚的メタファーを用意すべき言葉や概念は何か?
  • 想定視聴者 — テクノロジーに詳しい人か、一般の人か? どのような不安や好奇心を抱いていると想定するか?
  • 動画の長さ — セグメントごとのペース配分を決めます

この分析が、あらゆるデザイン上の判断の土台になります。省略しないでください。


手順 3:デザインのアイデアを出す

ここが最も重要なクリエイティブ工程です。プログラマーではなく、ディレクターとして考えます。

主要なデザイン上の判断(まずこれを決める)

1. ビジュアルアイデンティティ

  • 2~3 色のカラーパレットを選びます。一般的には、暗色またはニュートラルな背景色 1 色、鮮やかなアクセントカラー 1 色、「エラー/誤り」状態用の第 2 アクセントカラー 1 色です。
  • すべての色に 意味 を持たせます。視聴者が色と感情を結び付けて覚えられるようにします(例:緑=正解/進行、赤=誤り/警告)。
  • 主役となるタイポグラフィのスタイルを 1 つ選びます(等幅フォント/ハッカー風、太字セリフ/エディトリアル、すっきりとしたサンセリフ)。

2. 中心となる視覚的メタファー

  • 核心となる主張を視覚化する、中心的なメタファーは何か?
  • このメタファーはフックで登場させ、結末で再び登場させます。

3. ペース配分の設計

  • この種の動画は徹底してテンポが速く、動きが絶えず、無音区間がなく、映像は常にナレーションのリズムに沿っています。感覚を養うため、サンプルファイルをよく確認してください。
  • 静止要素を、目的もなく約 22 フレーム(30 fps で約 0.73 秒)を超えて放置してはいけません。何も動いていない場合は、意図的な理由が必要です。
  • 緊張感のカーブを設計します:フック → 展開 → パターンの中断 → 解説 → クライマックス → 結末 → CTA
  • 緊張と緩和のパターンについては references/editorial-patterns.md を参照してください。

4. モーショングラフィックの表現

  • 繰り返し使う代表的なアニメーションを 2~3 種類決めます。
  • アイデア集として references/motion-graphic-prompts.md を読んでください。
セグメントごとのデザインルール

各セグメントについて、次の質問に順番に答えます。

  1. このセグメントに入る時点で、視聴者はどのような心理状態か?
  2. 終わるまでに理解してもらうべき唯一の概念は何か?
  3. その概念を表す最も効果的な視覚的メタファーは何か?
  4. 背景や環境はどのように動いているか?
  5. 何を、どのようにアニメーションで登場させるか?
  6. このセグメントからどのように、そしてなぜその種類のトランジションで移行するか?
  7. これらの選択をした理由は何か?(エディトリアル上の意図。必ず記述する)

ステップ 4:デザインを文書化する

セグメントごとに 1 つのセクションを設けた video-design-[name].md ファイルを出力します。

各セグメントは、video-example ファイルとまったく同じ 4 つのサブセクション形式に従います。

## [timestamp] | [Scene Name]

**Backgrounds & Tints:** ...

**Motion Graphics & Typography:** ...

**Transitions & Pacing:** ...

**Editorial Thinking/Intent:** ...

このドキュメントは、ユーザーが確認して承認するものです。熟練した開発者が質問せずに実装できるだけの詳細を記載する必要があります。

実例をすべて含む形式については、references/design-doc-format.md を参照してください。


ステップ 5:フレームタイミングドキュメント

このステップは、デザインの承認後、Remotion コードの作成前に行います。

フレームタイミングドキュメント(frame-timing-[name].md)では、デザインドキュメントにあるすべてのクリエイティブ上の決定を、正確なフレーム番号に変換します。これはエンジニアリング仕様書です。ここでのすべての単位はフレームです。秒でも「だいたい半分」でもありません。アニメーションの各ビート、各トランジションの区間、各ホールドに、明示的なフレーム範囲を設定します。

次の問題を、レンダリング前に文書上で検出します。

  • 無音区間(最後のアニメーション後に、シーンが長時間アイドル状態で止まる)
  • スプリングの設定ミス(減衰不足のスプリングがポップせずに振動する)
  • トランジションの競合(シーンレベルの開始アニメーションが TransitionSeries と競合する)
  • フレーム計算の誤り(トランジションの重複分を差し引かなかったため、TOTAL がずれる)
  • フェーズの順序ミス(フェーズ 1 が完了する前にフェーズ 2 が開始する)
サブステップ A — フレーム計算ツールを実行する
python scripts/frame_calculator.py \
  --fps 30 \
  --durations <S1_dur> <S2_dur> ... <SN_dur> \
  --transition <T_dur> \
  --names "Scene 1 Name" "Scene 2 Name" ... \
  --last-anim <last_anim_local_1> <last_anim_local_2> ... \
  --springs "springLabel:damping:stiffness[:mass]" ...

計算ツールは次の内容を出力します。

  • 各シーンと各トランジション区間の絶対開始/終了フレーム
  • 各シーンのローカルフレームと絶対フレームの相互変換
  • シーンごとの無音区間の警告(トランジション終了前のアイドル状態が 22f を超える場合に通知)
  • 各設定のスプリング ζ(減衰比)と収束時間

これらの数値を手計算しないでください。 1 フレームのずれがコードに気づかれないまま波及します。計算ツールを実行し、出力をそのままフレームタイミングドキュメントのヘッダーに貼り付けてください。

スプリング解析を含む 6 シーンの動画での実行例:

python scripts/frame_calculator.py \
  --fps 30 \
  --durations 150 180 150 210 200 120 \
  --transition 15 \
  --names "Hook" "Definition" "Solution" "Demo" "Processing" "Dialogue" \
  --last-anim 125 150 110 178 177 95 \
  --springs "errorStamp:10:300" "staccatoPop:28:400" "cardEntrance:12:200"
サブステップ B — シーンごとのビート表を作成する

各シーンについて、個別のアニメーションビートをすべて網羅するフレーム範囲の表を作成します。 範囲は連続している必要があり、空白や説明のない飛びがあってはなりません。各行にローカルフレームと絶対フレームの両方の列が必要です。

フレーム範囲(ローカル)絶対範囲動作内容注記/リスク
0–440–44......
45–5245–52......
............

作成済みのアニメーションがない範囲も、名前付きホールドとして必ず表に含めます。 「Hold — [何が表示されたままか、どのマイクロアニメーションによって動きが保たれるか]」と記載します。範囲を空白のままにしないでください。

サブステップ C — トランジションごとに専用セクションを作成する

各トランジションに専用のセクションを設けます。シーンの表の中でトランジションを要約しないでください。 各トランジションのセクションでは、次の点すべてに答える必要があります。

  1. 使用するプレゼンテーション — 正確なインポートパスと関数呼び出し
  2. 使用するタイミング — linearTiming と springTiming のどちらを使うか、その理由
  3. 編集上の意図 — 物語のこのビートでこのトランジションを使う理由。この場面で別の種類を使うと何が問題か
  4. 重複区間中の各シーンの動作 — 終了するシーンの最後の T フレームで何が表示/アニメーションしているか、開始するシーンの最初の T フレームで何が表示されるか
  5. 具体的なリスク — このトランジションの発生箇所で問題になり得ること
サブステップ D — フレーム計算を検証する

コードを確定する前に、合計を手動で検証します。

TOTAL = sum(all scene durations) - (num_transitions × transition_duration)

この計算をドキュメント内に明記してください。TOTAL が SCENE_TIMING.TOTAL および Root.tsx durationInFrames に設定した値と一致しない場合、動画の末尾が途中で切れるか、空白になります。これは必須の確認事項です。

6 シーンからなる VibeCodingPRD 動画の完全な形式仕様と実例については、references/frame-timing-format.md を参照してください。

ステップ 6:承認を待つ

フレームタイミングドキュメントをユーザーに提示します。承認を得るまでは Remotion コードの作成を始めないでください。変更を求められた場合は、コードではなくフレームタイミングドキュメントを修正します。

この段階でユーザーからデザインドキュメントの変更を求められた場合は、更新後の尺で計算ツールを再実行してから次に進みます。尺の変更は、後続のすべての絶対フレーム番号に波及します。


ステップ 7:Remotion で構築する

デザインドキュメントとフレームタイミングドキュメントの両方が承認されたら、remotion-best-practices スキルを使って実装します。フレームタイミングドキュメントを仕様として使用します。

主要な実装原則:

  • すべてのアニメーションは useCurrentFrame() によって駆動します。CSS トランジションは使用しません。
  • シーンのタイミング定数はフレームタイミングドキュメントから導きます。コンポーネントにマジックナンバーを使いません。
  • TransitionSeries を使う場合、SCENE_X_START の値は不要です。位置は自動計算されます。必要なのは尺の定数だけです。
  • 選択したパレットの色は、インラインではなく定数として定義します。
  • デザインドキュメントに記述された視覚的メタファーは、すべてコードに反映します。
  • フェーズ N の開始フレームはハードコードせず、フェーズ N-1 の終了フレームから導きます:
    const PHASE2_START = PHASE1_END + HOLD_DURATION; // NOT a literal number
    

品質基準

デザインドキュメントを確定する前に、各セグメントについて次のリストを確認します。

  • 背景に意図を持たせています。既定のグレーではなく、色やテクスチャが設定されています。
  • テキストを画面に表示するだけでなく、少なくとも 1 つの視覚的メタファーがあります。
  • トランジションには、具体的なイージングの説明があります(単に「フェードイン」ではありません)。
  • 編集意図では、視覚的に何が起こるかだけでなく、視聴者の心理も説明されています。
  • 色が一貫して使われています。同じ色は全体を通して同じ意味を持ちます。
  • 冒頭のフックが最初の 2 秒で注意を引きます。
  • 少なくとも 1 つのパターン割り込み(トーンの変化、ミーム、予想外のビジュアル)があります。
  • 最後のセグメントで視覚的な空白を作り、CTA やオチに集中できるよう、すべての要素を取り除きます。
  • ペースに変化があります。すべてのセグメントの視覚的な密度が同じではありません。
  • すべてのシーンにホールド期間中のマイクロアニメーションがあります(完全な静止フレームはありません)。

フレームタイミングドキュメントを確定する前に、すべてのシーンについて次のリストを確認します。

  • すべてのフレーム範囲が説明されており、理由のない空白がありません。
  • すべての範囲について、ローカルフレーム番号と絶対フレーム番号の両方が示されています。
  • 無音状態のアイドルフレームが予算内(≤ 22f)であるか、明確な理由が記されています。
  • すべてのスプリング設定を計算ツールで実行し、ζ が意図した範囲内にあります。
  • すべてのトランジションに、意図とリスクを記載した専用セクションがあります。
  • フレーム数の合計は、明示的な計算式を記載して検証されています。
  • フェーズの開始フレームは導出された値であり、リテラルではありません。

問題が起きる可能性があること

実際の制作で遭遇した失敗パターンを以下に示します。どれも、コードレビューでは正しく見えたレンダリングを台無しにしました。コードを 1 行でも書く前に把握してください。


1. 無音状態 — 静止した余韻

どのように見えるか: シーン内の最後のアニメーションが終わった後、トランジションが始まるまで 1~3 秒間、シーンが静止します。視聴者は離脱し、視聴時間が低下します。

なぜ起きるか: 最後のアニメーションが実際に終わるタイミングを考慮せず、「余裕を持たせる」ためにシーンの尺を長めに設定した場合に起きます。尺が 180f で、最後のアニメーションがローカルフレーム 120 で終わるシーンには、60 フレーム(何も起きない 2 秒間)の静止した余韻があります。

検出方法: 計算ツールで --last-anim フラグを実行します。idle > 22f と報告されたシーンには、静止した余韻があります。

修正方法:

  • シーンの尺を短くし、scene_duration ≈ last_animation_end + 20f hold + transition_duration となるようにします。
  • (デザイン上の理由で)尺を短くできない場合は、ホールドをつなぐマイクロアニメーション(グローのパルス、カーソルの点滅、周囲を漂うパーティクルなど)を追加します。フレームを完全に静止させてはいけません。

予算: 最後に作成したアニメーションの終了から、トランジションの退出開始までのアイドルフレームを ≤ 22 にします。30fps で約 0.73 秒です。視聴者が離脱せずに最終状態を把握するには十分な長さです。


2. Spring の設定ミス — 持続的な振動

どのように見えるか: 一度だけ軽快にオーバーシュートして「ポン」と現れるべき要素が、代わりに何度も前後に跳ね返ります。ピル型カード、チェックマーク、アイコンの表示がすべて震えているように見え、素人っぽい印象になります。アニメーションがきれいに止まりません。

発生する理由: Spring の減衰比 ζ が 0.5 未満です。damping: 8, stiffness: 400 の場合、ζ = 0.2 で、大きく減衰不足です。要素は 3 秒以上振動します。damping: 28, stiffness: 400 の場合、ζ = 0.7 で、減衰不足は軽度です。約 105% まで一度だけきれいにオーバーシュートし、12 フレームで収まります。

計算式:

ζ = damping / (2 × sqrt(stiffness × mass))
ζ < 0.5  →  wrong. Will oscillate.
0.5–0.85 →  correct for pops. Single overshoot, snappy settle.
0.85–1.0 →  correct for slides and magnetic clicks. Near-critical, smooth.
> 1.0    →  overdamped. Slow creep, no overshoot. Use for deliberate heavy entrances.

見つける方法: 計算ツールで --springs "label:damping:stiffness" を実行します。ζ < 0.5 の設定にはフラグが付けられます。コンポーネントを作成する前に実行してください。

修正方法: 減衰を大きくします。stiffness が 400 の場合、damping を 28 にすると ζ = 0.70 になります。stiffness が 200 の場合、damping を 20 にすると ζ = 0.71 になります。目安として、ポップ表示には ζ ∈ [0.65, 0.80] を目指してください。

避けるべき、よくある設定ミスのプリセット:

// WRONG — ζ = 0.20, will bounce for 3 seconds
spring({ damping: 8, stiffness: 400 })

// WRONG — ζ = 0.25, same problem
spring({ damping: 10, stiffness: 400 })

// CORRECT — ζ = 0.70, single pop
spring({ damping: 28, stiffness: 400 })

3. TransitionSeries と競合する独自の表示アニメーション

どのように見えるか: TransitionSeries のスライドまたはワイプでシーンが入ると、空白のパネルがスライドしてきた後、トランジションの途中でコンテンツが突然表示されます。または、スライド中にコンテンツがクリップされ、スライドが完了して初めて表示されます。

発生する理由: シーンコンポーネントの最外側にある AbsoluteFill に、clipPath、transform、または opacity の表示アニメーションが適用されています。TransitionSeries は各シーンを独自のコンテナでラップし、そのラッパーにトランジションの transform を適用します。内側の AbsoluteFill に clip-path や transform が設定されていると、ラッパーの transform に重ねて合成され、次のようになります。

  • 内側の要素に clip-path → スライド中はコンテンツが表示されない(クリップ率 0%)
  • 内側の要素に transform → transform が二重に適用され、誤った位置に移動する
  • 内側の要素に opacity → スライドとは独立してフェードし、ゴースト効果が生じる

典型例: 最外側の AbsoluteFill に円形のワイプ用 clip-path を設定するケース:

// WRONG — clip-path at frame 0 is 0%, so scene slides in blank
<AbsoluteFill style={{ clipPath: `circle(0% at 50% 50%)` }}>

見つける方法: フレームタイミングのドキュメントで、トランジションのリスクに関するセクションに、入ってくるシーンの最外側の要素に表示アニメーションがあるかどうかを明記する必要があります。ある場合は、TransitionSeries のトランジションを適用する前に削除してください。

修正方法: すべての表示アニメーションを、最外側の AbsoluteFill の内側にある子要素へ移動します。最外側の要素は、transform、clip-path、アニメーション付き opacity のない単純なコンテナにしてください。コンテナの動きは TransitionSeries に任せます。


4. フレーム計算の誤り — TOTAL の間違い

どのように見えるか: 最後のシーンが終わる前に動画が途切れたり、CTA の後に黒い空白が残ったりします。または、Remotion Studio のタイムラインプレビューに、動画は 935 フレームのはずなのに 1010 フレームと表示されます。

発生する理由: トランジションの重なりを差し引かずに、シーンの長さの合計を TOTAL に設定しています。共有のトランジション長を T とする N 個のシーンの場合:

TOTAL = sum(durations) - (N - 1) × T

各トランジションは、隣接するシーンと T フレーム分重なります。これを忘れると、TOTAL が実際のコンポジションの長さより大きくなります。

見つける方法: フレーム計算ツールは、明示的な計算式を出力します。

Verify: 150+180+150+210+200+120 - (5×15) = 1010 - 75 = 935

これをフレームタイミングのドキュメントに記載してください。SCENE_TIMING.TOTAL が一致しない場合は、Root.tsx が誤った値を読み込む前に修正してください。

修正方法: 定数で TOTAL = sum(durations) - (N-1) × transition_duration を設定します。トランジションごとに長さが異なる場合は、それぞれを個別に差し引いてください。


5. フェーズの順序 — フェーズ 2 が文の途中で始まる

どのように見えるか: タイプライター形式のトランスクリプトに続いて UI 要素(ピル、カード、チェックマーク)が表示されるシーンで、トランスクリプトの入力が終わる前に UI 要素が表示され始めます。タイプライター表示と UI が互いに注意を奪い合います。

なぜ起こるのか: PHASE2_START が、実際のトランスクリプト終了フレームから導出されず、固定値としてハードコードされていました。トランスクリプトの長さは変わります(デザイナーが 60 文字で作成した後、VO が 74 文字に更新されました)が、ハードコードされた定数はその変更に合わなくなります。

修正方法: フェーズの開始フレームは、必ず直前のフェーズの実際のアニメーション終了位置から導出してください。

const TRANSCRIPT_END = TRANSCRIPT_START + Math.ceil(TRANSCRIPT.length / CHARS_PER_FRAME);
const PHASE2_START   = TRANSCRIPT_END + HOLD_FRAMES; // HOLD_FRAMES = 12

const PHASE2_START = 113; のように記述してはいけません。コンテンツが変更された時点で動作しなくなります。


6. 唐突なカット — トランジションなしの状態変化

どのように見えるか: 要素が 1 フレームで消えたり、色が変わったりします。視聴者はぎょっとします。効果ではなく、バグのように見えます。

なぜ起こるのか: {frame >= PHASE2_START && <NewElement />} のような条件式では、条件が真になった正確なフレームで要素が不透明度 100%で表示されます。表示開始アニメーションが計画されていません。

必ず避けるべき唐突なカットの例:

  • REC インジケーター:{frame < PHASE2_START && <RecDot />} — 1 フレームで消えます。修正方法:interpolate を使って 10 フレームかけてフェードアウトさせます。
  • シーン間の切り替え:TransitionSeries を使わずにシーン間をハードカットします。修正方法:fade() だけの場合でも、すべてのシーン切り替えに TransitionSeries のトランジションを使ってください。
  • 真空への移行:暗いシーンから純白へ瞬時に切り替わります。修正方法:白い背景は 6 フレーム以上かけてフェードインさせてください。1 フレームだけの白いフラッシュは、レンダリングの不具合のように見えます。
  • 状態色の急変:カオスを表す線が 1 つの色から 1 フレームで赤に切り替わります。このケースは意図的です(フリーズが効果です)が、今後の開発者が「修正」しないよう、ビート表に明記してください。

7. サイズとスケール — 1080×1920 で要素が小さすぎる

どのように見えるか: Remotion Studio では技術的に読めるテキストが、スマートフォンの画面では読めなくなります。カードは力強いメッセージではなく、UI の装飾のように見えます。動画は縦型動画ではなく、縮小されたデスクトップサイトのような印象になります。

なぜ起こるのか: 縮小プレビューを見ながらサイズを決めたか、1080×1080 または 16:9 のレイアウトからサイズをコピーし、9:16 向けに再調整しなかったためです。

1080×1920(30fps)での最小サイズのルール:

要素の種類最小サイズ推奨サイズ
ヒーロー/中央のコンセプトテキスト80px100–140px
シーン見出し/主要ラベル40px48–60px
本文/説明文28px32–36px
ターミナル/コード/等幅フォント22px26–30px
UI ラベル/キャプション18px20–24px
下回ってはいけないサイズ16px—

パディングのルール:

  • 幅 1080px のフレームの左右のパディング:片側あたり最低 80px。有効なコンテンツ幅:920px。
  • 上下のセーフゾーン:それぞれ 80px。コンテンツは上端から 80px 以内に始めたり、下端から 80px 以内で終わったりしないようにしてください。
  • カード/ピル:内部パディングは最低 16px。枠線が見えるようにしてください(ストローク幅 1.5px 以上)。

よくある間違い:

  • 中央揃えのコンテナに maxWidth: 800 を指定する — 問題ありませんが、幅の狭いコンテナで使用可能なスペースを埋めるよう、width: '100%' も追加してください。
  • ターミナルの行に fontSize: 18 を指定する — デスクトップでは読めても、モバイルでは見えません。26 以上を使用してください。
  • カードの枠線:border: '1px solid ...' — 1080px では細すぎます。最低 1.5px を使用してください。

レイアウトコードを書く前に: 重要な情報を伝えるすべての要素について、具体的なピクセル幅とフォントサイズをフレームタイミング文書の「Notes / Risks」列に記入してください。プレビューで腕の長さほど離れて読めない場合、視聴者はスマートフォンで読むことができません。


8. 色の意味のずれ

どのように見えるか: 中立的またはネガティブな要素にアクセントカラーが使われ、見る人がこれまでに身につけた色の連想が混乱します。または、エラー/状態を示す色が意図せず装飾に使われます。

例:

  • 問題を示すシーンで、カーソルに緑のアクセントカラーを使います。シーンでは誤りを示しているのに、カーソルは「正しい」という印象を与えます。
  • 「見栄えがよい」という理由で、装飾的な境界線に赤の状態色を使います。すると見る人は無意識に、その境界線を警告として受け取ります。
  • まだ「保留中」の項目も含め、すべてのリスト項目に緑のチェックマークを付けます。本当に成功した場面を迎える前に、緑が持つ意味の重みを使い切ってしまいます。

ルール: 緑=解決済み/正しい/進行中です。赤=故障/誤り/不足です。これらの意味はフレーム 0 で確立され、その後も決してずれてはいけません。「中立」または「保留中」の状態に3つ目の色が必要な場合は、薄いテキスト用のミュートカラー(ダークシステムでは #4A4A5A)を使ってください。アクセントカラーを装飾色として使ってはいけません。


9. ローカルフレームと絶対フレームの混同

どのように見えるか: シーンコンポーネント内の frame > 500 のようなアニメーションのトリガーが実行されません。useCurrentFrame() が返すのはローカルフレーム(0 から scene_duration-1)で、このシーンの長さはわずか200フレームだからです。この条件に到達することはありません。

原因: 開発者がアニメーションを絶対フレームで考えながら、条件をローカルフレームで記述した(またはその逆の)ためです。

ルール: シーンコンポーネント内では、useCurrentFrame() は0から始まるローカルフレームを返します。フレームタイミングのドキュメントに記載された絶対フレーム番号は、使用する前にローカルフレームに変換する必要があります。

// In the component — always local
const GLITCH_START = 73; // local frame 73 = absolute 73 (Scene 1 starts at absolute 0)

// For Scene 2 (absolute start = 135):
const WIPE_START = 10; // local — absolute equivalent is 135 + 10 = 145
// Never write: const WIPE_START = 145; // WRONG inside Scene 2 component

読者が初めて参照する必要のあるタイミング定数には、ローカル値と対応する絶対値の両方を示すコメントを付けてください。

const TYPE_START = 99; // local 99 = absolute 99 (Scene 1 starts at 0)

10. トランジション開始時のコンテンツのちらつき

どのように見えるか: スライドまたはワイプのトランジション中に、トランジションが完了するまで表示されるべきでないコンテンツ(テキスト、グロー、UI要素)が、次のシーンに一瞬表示されます。Scene N の退出と Scene N+1 のコンテンツの登場が同時に起き、見る人には入り乱れて見えます。

原因: Scene N+1 に設定されたアニメーションがローカルフレーム 0 から始まり、それがトランジションの開始フレームと同じだからです。そのため、15f のスライドトランジション中は、スライドが進行している間も Scene N+1 がローカルフレーム 0〜14 で動作します。Scene N+1 の冒頭のアニメーション(例:見出しのタイプライターアニメーション)がローカルフレーム 0 から始まると、コンテナがスライドの途中にある間も表示され、アニメーションが進行します。

修正方法: Scene N+1 の最初の設定済みアニメーションは、TRANSITION_DURATION 以降に開始するように設計してください(例:15f のトランジションならローカルフレーム 15)。このバッファ期間には、背景や環境だけを表示させ、コンテンツが現れる前にトランジションをきれいに完了させます。Scene 2 の WIPE_DURATION パターン(WIPE_DURATION = 10)は、まさにこのためのものです。スライドでシーンが入ってくる間に線の描画が始まらないよう、意図的にバッファを設けています。


同梱ファイル — こちらをお読みください

scripts/
  • scripts/srt_to_script.py — SRT 字幕ファイルを構造化された script-[name].md に変換します。使用方法:python scripts/srt_to_script.py <input.srt> "<Title>" [output.md]

  • scripts/frame_calculator.py — このファイルの先頭にある docstring をお読みください。 すべてのシーンとトランジションの絶対フレーム範囲を計算し、無音区間を検出して、スプリングの減衰比を分析します。フレームタイミングのドキュメントを作成する前に、ステップ5で実行してください。使用方法: python scripts/frame_calculator.py --fps 30 --durations ... --transition ... --names ... --last-anim ... --springs ...

examples/ — 品質のベンチマーク。何かをデザインする前に、これらを読んでください。

パフォーマンスの高いモーショングラフィック動画を、ショットごとに実際に分析した内容と、それに対応する正確なナレーション台本です。デザイン上の判断はすべて、これらが示す基準に照らして評価してください。

  • examples/video-example-1.md + examples/video-script-1.md — Claude Code のヒント動画(約54秒)。 参考にする点:ダークなハッカー風の美学、ネオンミントのアクセント、グリッチのフック、歯切れのよいチェックマークのポップ、コンテキストウィンドウのスライダーというメタファー、液体のアルファマットワイプ、視覚的な真空状態を作るCTA。
  • examples/video-example-2.md + examples/video-script-2.md — ZIP圧縮の解説動画(約56秒)。 参考にする点:温かみのあるベージュの配色、安全オレンジのアクセント、レトロコンピューティングのメタファー、パックマン風のゲーミフィケーション、線を描いていくフローチャート、可逆性によるロスレスの証明、AIへの転換をクライマックスにする構成。
  • examples/video-example-3.md + examples/video-script-3.md — Brand Gravity のマーケティング動画(約80秒)。 参考にする点:ミントグリーンの単色の世界、じょうごから墓石への変形を使ったフック、時空グリッドのメタファー、権威性を示すアンカーへのカット、企業のファサードの粉砕、顧客を軌道上に配置して解決を示す演出。

読むタイミング: ステップ2(スクリプト分析)の冒頭で、6つのファイルをすべて読んでください。「編集上の思考/意図」のセクションにある編集の掘り下げ具合を身につけてください。独自のデザインドキュメントでも、それと同じ深さが求められます。スクリプトを見ると、タイムスタンプがナレーションの密度にどう対応するかが正確にわかります。

references/ — デザインルールとフォーマット仕様。
  • references/design-doc-format.md — script-[name].md と video-design-[name].md の正確なフォーマットを、詳細な作成例と避けるべきアンチパターンとともに示しています。 ステップ4で読んでください。

  • references/frame-timing-format.md — ステップ5で最も重要なリファレンスです。 frame-timing-[name].md の正確なフォーマットを、VibeCodingPRD 動画の全6シーンと5つのトランジションを網羅した詳細な作成例とともに示しています。今後作成するすべての動画のフレームタイミングドキュメントは、ここで示す詳細さを満たす必要があります。ステップ5で読んでください。

  • references/design-system.md — 色の設計、タイポグラフィのレジスター、感情表現としてのイージング、シーンの密度調整、背景の奥行きに関するルールを説明しています。ステップ3で読んでください。

  • references/editorial-patterns.md — 緊張感のカーブ設計、パターンを崩す手法、認知的負荷を和らげる設計、視覚的メタファーの構築方法、フックの種類、CTAの真空状態を作る仕組み、ナラティブの構成パターンを説明しています。ステップ3で読んでください。

  • references/motion-graphic-prompts.md — 5つのカテゴリにわたる75種類のモーショングラフィックのコンセプト集です。セグメントのアニメーション表現をブレインストーミングする際に、ステップ3で読んでください。

コメント