hyperframes-video-beats

HyperFrames Video Beats

このスキルを使うと、トークヘッド動画とトランスクリプトから、ナレーションを支えつつ、話者を不必要に覆わない、テンポのよいモーショングラフィックスを作成できます。

主な目標

視聴者が内容を把握し、興味を持ち続けられるようにします。それぞれのビートは、次のいずれかに答える必要があります。

• 視聴者に何を覚えてもらうべきか？
• どの概念を視覚的に整理する必要があるか？
• どの統計、対比、転換点を強調すべきか？
• テンポが落ち着き、視聴者が注意を失いそうな箇所はどこか？

間があるからといって、グラフィックスを追加しないでください。視覚的な補助が役立つトピック、転換点、根拠、またはメンタルモデルがナレーションにある場合に、グラフィックスを追加してください。

最初の確認

1. プロジェクトの指示（AGENTS.md、ローカルのスキルドキュメント、プロジェクト固有のメモ）を読みます。
2. ルートコンポジション、現在のビートスケジュール、共有 CSS、トランスクリプトを確認します。
3. ルートの data-start / data-duration エントリ、またはマスターの SHOW 配列から、カバレッジマップを作成します。
4. リクエストされた範囲と、未カバーの間について、トランスクリプトのチャンクを抽出します。
5. 任意のタイムスタンプではなく、ナレーションに基づいてトピックの範囲を特定します。
6. 各トピックに全画面のクランプルドペーパービート、ローワーサードのグラスカード、または新しいビートなしのどれが必要かを判断します。

ローカルで実行できる高速なコマンドを使います。rg、Select-String、および小規模な Node/PowerShell のトランスクリプトスクリプトを優先してください。

ビートの種類を決める

全画面のクランプルドペーパーを使う

ナレーションが、画面全体を一時的に使う価値のある主要な主張、リスト、セクションマーカー、引用、または統計に差しかかったら、ペーパーで画面を切り替えます。

適した用途：

• フックの結びや「この動画では」の概要
• 主要なセクションの切り替え
• 大きな統計や研究結果
• 印象に残る主張
• 短い引用やモットー
• 視聴者に立ち止まって見てもらう必要がある対比

ルール：

• 短く保ちます。通常は4～12秒です。
• 黒いテキストは控えめに使います。
• アクセントカラーを使うのは、真の統計数値か、極めて重要な単語1つだけにします。
• 長い説明をペーパーで画面全体を切り替えて覆わないでください。
• 特に指定がない限り、全画面テキストを遊び心のあるもの、大きすぎるもの、過度に太字のものにしないでください。

グラスモーフィズムのローワーサードを使う

話者を見せたまま、現在のアイデアをグラフィックで補足する場合は、グラスのローワーサードを使います。

適した用途：

• 説明の補助
• トピックラベル
• 方程式形式のメンタルモデル
• 小さなリスト
• 「これが意味すること」の説明
• 長いトークヘッド区間のテンポ調整
• 短縮した全画面または分割画面のビート後に続けるカード

ルール：

• ローワーサードは画面の下3分の1または下半分に配置します。
• 顔を覆わないようにします。
• テキストは簡潔にします。見出し1つと任意の短いサブライン、または2～4項目のリストにします。
• 小さなフラッシュを何度も入れるより、トピックの範囲ごとにカードを1枚使います。
• ユーザーがデザイン変更を求めない限り、既存のグラスカードのスタイルを維持します。

テンポの目安

長尺のYouTubeトークヘッド動画の場合：

• 動画の序盤では、視覚的なビートがない状態を20～30秒以上続けないようにします。
• 本編では、ビートがない状態を30～45秒以上続けないようにします。
• 説明が密なセクションでは、各文ではなく、おおよそトピックの範囲ごとにローワーサードを使います。
• 大きなペーパーでの画面切り替えは、標準ではなく、時折入れる句読点のようなアクセントとして使います。
• 既存のビートが長すぎると判断され、手動で短縮されている場合は、その判断を尊重し、その後に短めの新しいカードを入れて補います。

スケジュールを確認する際は、DOM の順序だけでなく、表示スケジュールに基づく実際の空白区間を報告してください。ルートのタイムラインに SHOW 配列がある場合、通常はその配列が表示範囲の基準になります。

タイミングの決め方

すべてのビートのタイミングを、文字起こしのトピックに合わせます。

1. トピックが始まる最初の単語やフレーズを見つけます。
2. 可能であれば、その目印の0.2〜0.6秒前にビートを開始します。
3. トピックが終わるか、自然に次へ移るまでビートを表示し続けます。
4. 次のビートがすぐ始まる場合は、意図的に引き継ぐのでなければ、その0.1〜0.5秒前に消します。
5. サブ要素の表示開始を、話されるフレーズに合わせます。

避けるべき失敗例：

• カードはトピックに合っているものの、話者がそのトピックについて20〜40秒話し続けているのに、表示が5〜8秒しか続かない。

推奨：

• 1枚のカードをトピック全体にわたって表示し、ナレーションの展開に合わせて途中でサブラインやリスト項目を追加します。

良いパターン：

The bottleneck
Not enough AI inside real workflows.
The problem is adoption, not raw talent.

The bridge
Skills + Workflows = 40 hrs saved

In this video
-> The study
-> The stats
-> The paths you can take
-> What actually matters

コンテンツの書き方

一目で理解できるように書きます。視聴者が1秒以内にカードの内容を理解できるようにします。

使用するもの：

• 短い名詞句
• 直接的なラベル
• カード1枚につき1つのメンタルモデル
• 意味がある場合に限り数字
• 動作を明確にする場合は動詞

避けるもの：

• ナレーション全体の繰り返し
• 長い文
• 曖昧な誇張表現
• 強調語の多用
• グラフィック内で動画の使い方を説明すること

ビジュアルスタイルのルール

まず、そのプロジェクトのデザインシステムに従います。このプロジェクト群では、以下を使用します。

• 落ち着いたプロフェッショナルなタイポグラフィ。
• ペーパー型ビートでは黒をメインのテキスト色にします。
• アクセントカラーの青は、主要な統計数値か、まれに使う力強いキーワードに限ります。
• 既存のダークなすりガラス調を使ったガラスカード。
• 話者の顔にかからないローワーサードカード。

ペーパー型ビートでは：

• キッカー、ラベル、矢印、出典、引用、補足テキストには黒を使います。
• フォントのウェイトは控えめにします。
• ユーザーから明示的な要望がない限り、遊び心のある特大文字は避けます。
• しわのある紙の動きは決定論的にします。

ガラスカードでは：

• .glass-card dim lower-third または既存の最も近いクラスを再利用します。
• 画面下部中央への配置を優先します。
• カードはコンパクトにします。
• アイデアに構造がある場合は、数式／リスト用ヘルパーを使います。

HyperFrames の実装ルール

プロジェクトの AGENTS.md と HyperFrames の lint ルールに従います。

• マウントする、時間指定の要素にはすべて data-start、data-duration、data-track-index を設定します。
• ルートにマウントする、表示される時間指定の要素には、プロジェクトで使われている想定のクリップ／レイヤークラスを設定します。
• サブコンポジションでは、一時停止状態の GSAP タイムラインを window.__timelines に登録します。
• tl.set({}, {}, SLOT); で各サブコンポジションのタイムラインを固定します。
• 決定論的なロジックのみを使用します。
• レンダリングが停止する可能性のある方法で、動画要素の寸法やメディアプロパティをアニメーションさせないでください。
• HTML の編集後に npx hyperframes lint を実行します。

ビートを追加する場合：

1. compositions/beats/NNN-short-name.html を作成します。
2. index.html にルートマウントを追加します。
3. マスター可視性スケジュールがある場合は、追加または更新します。
4. サブコンポジションの SLOT を、マウントした時間に合わせます。
5. プロジェクトで意図的に複数のオーバーレイトラックを使用していない限り、同一トラックで重なりがないことを確認します。

カバレッジスキャン

編集後、マスタースケジュールをスキャンします。

• 表示開始順にビートを並べます。
• 目標のしきい値を超えるギャップを表示します。
• 文字起こしに裏付けとなる概念がある箇所に限り、ビートを追加またはタイミングを調整します。

このプロジェクトのパターンでは、厳密なスキャンしきい値を30秒、本文の許容最大しきい値を45秒とします。

検証

完了前に：

1. HyperFrames のリンターを実行します。
2. すべてのエラーを修正します。
3. 既知で、かつ進行を妨げない警告があれば、別途記載します。
4. ユーザーがレンダリング可能な出力を求めている場合は、適宜レンダリングまたはスモークレンダリングを行います。
5. 変更した正確なファイルパスとタイムスタンプをユーザーに伝えます。

実用的なデフォルト値

プロジェクトのコンテキストで別途指定がない限り、以下をデフォルトとして使用します。

• 全画面のペーパー概要：8〜10秒。
• 全画面のペーパー統計：5〜8秒。
• ガラスのローワーサードによる説明：12〜30秒。
• 長いトピック向けのガラスカード：25〜45秒。サブ要素は段階的に表示します。
• ビート開始の先行時間：0.2〜0.6秒。
• ギャップスキャンのしきい値：30秒。
• ローワーサードの幅：約68〜72vw、最大約1240〜1280px。

維持する内容

レビュー中に確認した、ユーザーの好みや判断を維持してください。

• ビートが長すぎるとユーザーが指摘した場合、一般的な網羅ルールを満たすためだけに元に戻さないでください。
• ガラス風カードのスタイルが承認されている場合、再設計せずに再利用してください。
• タイポグラフィが承認されている場合は安定させ、局所的なサイズや太さのみを調整してください。
• 話者の顔が重要な場合は、画面中央のカードよりもローワーサードカードを優先してください。