hyperframes-motion-director

HyperFrames Motion Director

曖昧な動画の依頼を、レビュー可能な HyperFrames 制作物に仕上げるためのスキルです。まず簡潔なブリーフ／デザイン案を作成してください。ユーザーが方向性を確認するまでは、素材、コンポジション、スナップショット、レンダリング、レビューには進まないでください。

HyperFrames がレンダリングを担当します。このスキルでは、演出、素材、レイアウト、モーション計画、納品時のチェックを扱います。

具体的な製品、ツール、スキル、CLI、アプリ、API、ワークフロー、テンプレートライブラリ、クリエイティブシステムを紹介する動画では、シネマティックなメタファーの短編だけではなく、プレミアムな製品プロモーションとして制作してください。動画では製品の実証が必要です。主張を目に見える形で裏付けるため、コマンド、カード、スクリーンショット、出力プレビュー、モジュール、数値、チップ、アイコン、マーク、ワークフローの状態を表示してください。

基本原則

最終的な視聴体験から逆算してください。

1. 視聴者に何を覚えてほしいですか？
2. 伝えたいポイントをどのメタファーで表現しますか？
3. どの画像ステージがフレームに奥行き、文脈、緊張感を与えますか？
4. どのフレームで、ビジュアルの方向性が優れていることを証明しますか？
5. 視聴者が見続けたくなる動きは何ですか？
6. フック、リビール、実証、CTAをどのビートで伝えますか？
7. それらのビートを通じて注意を誘導するには、どのようなモーションが必要ですか？
8. 言葉を増やすよりも、意味を凝縮して伝えられるビジュアルオブジェクトは何ですか？
9. 動画が確実に再現可能な形でレンダリングされることを、どの検証で証明しますか？

まず、明瞭な静止フレームとタイミングを組み立ててください。アニメーションコードを書くのは、フレーム計画が機能してからです。

優れた静止フレームは通過条件です。完成した動画をスクリーンショットだけにすると意味が損なわれるべきです。そうならない場合、モーションは表面的な仕上げにすぎません。

基本スタイル

ユーザーが明示的に変更を求めない限り、次の厳格なスタイルを基本とします。

• 背景は深い黒 #050505。
• ミニマルなシネマティック照明、高コントラスト、大きなネガティブスペース、低輝度。
• 白、グレー、暖色系のゴールドのみ。暖色系のゴールドは控えめなアクセントとして使用してください。
• 雑誌の表紙のような構図：支配的なシンボルまたはフレーズを一つに絞り、説明的な要素をまとめて配置しない。
• 目立ちすぎない紙の粒子、浅い被写界深度、ボリュームヘイズ、細いリムライト、局所的なメタリックハイライト。
• テキスト、画像、コンポジション、色で、ひとつのポイントを一体となって表現してください。
• 新しい動画では、生成した背景画像または提供された背景画像のステージを基本とします。奥行き、メタファー、または製品の文脈を生み出す必要があります。

デフォルトで禁止するもの：

• 一般的なイラスト、ECサイトのバナーのような構図、アイコンの羅列、ありきたりなテック系ダッシュボード、ネオンのサイバーパンク、多色パレット、雑然としたグラデーション、装飾的な粒子、コンセプトを説明する図、雑然としたコラージュ。
• メタファーを使うほうが明確な場合に、記事の表面をそのまま描くこと。
• PPTのような場面展開：静的なタイトルカード、繰り返しのフェードアップ、同一の中央揃えレイアウト、何もない黒のフェード、壁紙にテキストを重ねただけの画面。

プレミアム製品プロモーションのルール

製品、ツール、CLI、SaaS、API、スキル、テンプレート、ワークフロー、システムのプロモーションでは、シネマティックな黒はあくまで土台です。それだけでは不十分です。

プレミアムな製品プロモーションには、ビジュアルコンポーネントが必須です。背景画像、大きなタイトル、スキャンライン、シンボル一つだけで実装に進まないでください。それでは単調な動画になります。プレミアムなプロモーションには、製品を本物らしく感じさせる再利用可能なコンポーネントライブラリが必要です。

ビジュアルコンポーネントがない製品プロモーションは、進行不可です。「ビジュアルコンポーネント」とは、コンテンツスロット、スタイルルール、状態、モーションとのインタラクション、スナップショットによる実証を備えた、製品固有の、再利用可能な可視要素です。一般的なテキストボックス、単独のラベル、装飾的な枠線、浮遊する線、背景グラデーション、定まった位置のないアイコンは該当しません。

動画内に、製品の実証を支えるエコシステムを構築してください。

• 製品の証拠となるアーティファクト：コマンド、UI サーフェス、出力カード、スクリーンショット、生成例、モジュールラベル、テーマスタック、プロバイダーチップ、数値、検証結果、レポート、または変更前後の状態。
• コンポーネントライブラリ：コマンドカード、出力／下書きカード、統計ブロック、モジュールチップグループ、プロバイダーチップグループ、証拠カード、製品フレーム、固定されたルート／シグナル、テーマ／出力スタック、CTA バッジ、または同等の製品固有サーフェス。
• アイコンと装飾のシステム：マーク、チップ、レール、ブラケット、グロー、断片、パネル、影、テクスチャには名前を付け、再利用可能にし、意味と結び付ける必要があります。
• モーションインタラクション：各主要コンポーネントは、シーンに登場するだけでなく、製品の状態変化を示す必要があります。
• コピーの段階構成：課題 → 仕組み → 証拠 → 確信 → CTA。どの製品にも当てはまるような文言は書き直してください。

コンテンツから導き出す製品ビジュアルコンポーネントの範囲：

• コンポーネント数は、ソース内の表現、製品の仕組み、証拠となる主張、アクションから導き出してください。4、6、12など、固定の数を目標にしてはいけません。
• 主張が実際の、または忠実に再現された製品の状態に依存する場合は、具体的な製品サーフェスを含めてください。
• ソースにモジュール、プロバイダー、機能、テーマ、モード、ステータスが含まれる場合に限り、分類コンポーネントを含めてください。
• 動画に CTA がある場合は、最後のアクションコンポーネントを含めてください。
• 前半がタイトルと雰囲気だけにならないよう、重要な仕組みや証拠を示すコンポーネントを早い段階で登場させてください。
• すべての製品コンポーネントについて、役割、ソース、コンテンツスロット、ビジュアル状態、モーションインタラクション、スナップショットのタイムスタンプ、削除テストを定義してください。
• 画面に表示されるすべての製品コンポーネントは、入力、ルート指定、展開、組み立て、表示、スキャン、検証、変換、カウント、ロック、エクスポート、公開、保存、折りたたみ、引き渡しのいずれかの動作を実行する必要があります。静止したまま配置するだけでは不十分です。
• 高品質な縦型生成画像を使った制作では、ソースに基づくビジュアルコンポーネントシートを少なくとも1枚生成してください。収録する要素数はコンテンツに基づいて決め、事前に決められた数に合わせてはいけません。各シートには、明確な分離境界、一貫したスタイル、名前付きの役割、使用するシーン、クロップ枠、モーション上の目的、削除テストを備えた、製品固有のコンポーネントを含めてください。採用したコンポーネントは実装前にそれぞれ個別にクロップし、背景透過のローカルアセットにしてください。
• 1枚のシートでは混み合って十分な解像度や分離領域を確保できない場合は、ヒーローオブジェクトを別途生成してください。ただし、個別のヒーロー生成はコンポーネントシートの代わりではなく、補足として扱ってください。
• テキスト量の多いコマンド、スクリーンショット、UI、証拠となる状態は、公式アセットまたはコードネイティブな再構築を使って忠実に再現してください。この忠実性の要件は、ソースに基づくコンポーネントシートを省略してよいという意味ではありません。Image Gen の利用に適したビットマップオブジェクト、素材パーツ、証拠表示に適したシェル、シンボル、スタンプ、遷移オブジェクト、製品固有の前景要素には、コンポーネントシートを活用してください。

コンポーネントライブラリが文章だけで構成されている場合、スナップショットにコンポーネントが表示されない場合、ラベルだけが異なる汎用カードばかりの場合、コンポーネントが画面上にあるだけで何も動作しない場合、またはモーションで製品の状態変化を示せていない場合は、製品プロモーション動画の納品を中止してください。

製品プロモーション動画を提案、絵コンテ作成、実装、レビューする前に、特にユーザーから高品質な参考例が提示された場合や、アイコンライブラリ、装飾要素、画像素材、アニメーションインタラクション、最上級のデザイン品質が欠けていると指摘された場合は、references/premium-product-promo.md を参照してください。

ブリーフでは、製品に基づいてアセット一覧を作成してください。製品／ブランドのロックアップ、具体的なサーフェス、証拠となるアーティファクト、分類、繰り返し登場するモーションオブジェクトは、ソースとストーリーが求める場合に限って含めてください。ビジュアル一覧で製品の仕組みを証明できない場合は、プロジェクトを調査し、既存のアセットを使用するか、製品に適したモックアップを生成するか、スクリーンショットを撮影してください。それができない場合は、成果物が高品質な製品プロモーション動画ではなく、コンセプト動画になることを明記してください。

ソース主導のビジュアルシステムルール

ビジュアルの豊かさは、ビジュアルの質と同じではありません。アセット、アイコン、カード、生成された小道具を増やしても、汎用的だったり、コピーと一致していなかったり、別のプロジェクトにもそのまま使えたりすれば、十分ではありません。

ビジュアルコンポーネントを提案する前に、ユーザーのテキスト、プロジェクト、記事、README、製品画面、または確定済みのコピーから、ソース主導のビジュアルシステムを抽出してください。

• ソースのフレーズ：ビジュアル化する価値のある、正確な文、主張、名詞、動詞、数値、感情的な緊張感。
• 具体的な名詞／エンティティ：製品画面、ファイル、フォルダー、コマンド、スクリーンショット、ドキュメント、人、モジュール、指標、プラットフォーム、状態。
• プロセスの動詞：書く、ルーティングする、収集する、確認する、公開する、保存する、エクスポートする、比較する、折りたたむ、復元する、成長する、引き継ぐ、または同等の動作を示す表現。
• ビジュアルモチーフ：中核となる比喩を1つと、シーンをまたいで繰り返せる3〜5種類のコンポーネントファミリー。
• テキストとコンポーネントの対応表：主要なビジュアルコンポーネントごとに、それが翻訳するソースのフレーズを明記します。
• 大きなテキストボックスの置き換え案：長いテキストブロックを、オブジェクト、チップ、図、証拠を示す画面、動きのある言葉、短いキャプションに置き換えます。
• 汎用要素の却下リスト：テキストが文字どおり示していない限り、無関係なあらゆる製品に合う小道具やアイコンは禁止します。

大きなテキストボックス、段落カード、汎用的なオフィス小道具を、プレミアムなビジュアルコンポーネントとして数えてはいけません。タイトルを主役にすることはできますが、ユーザーがタイポグラフィのみの映像を明示的に求めていない限り、それだけでビジュアルシステム全体を構成することはできません。

記事の動画化や、ナレッジ／ワークフローのプロモーションでは、ソーステキストをアセットの概要として扱ってください。ビジュアル要素がソースのフレーズ、主張、名詞、動詞、数値のいずれにも結び付かない場合は、削除するか再設計してください。静止画を見ても、段落を読まずにソースの内容が分からないなら、ビジュアルシステムは汎用的すぎます。

生成するコンポーネントシートは、ソース主導でなければなりません。採用する各アイテムには、ソースのフレーズ、コンポーネントファミリー、切り抜き／分離の計画、対象シーン、動きのアクション、削除テストが必要です。見栄えのよいアイコン集、汎用的な文房具、ランダムなUIカード、スタイルの混在した装飾にすぎないシートは却下してください。

次の場合は、納品を止めてください。

• ヒーローとなるフレームの大半が、大きなテキストボックスに支配されており、製品やソース固有のビジュアルへの翻訳が弱い。
• ビジュアルアセットが、別の動画にも使えるありふれたオフィス、デスク、紙、ダッシュボード、AI、生産性のイメージである。
• コンポーネントライブラリは数が豊富でも、統一されたモチーフ、スタイルの一貫性、ソースのフレーズとの対応が欠けている。
• 役割や動作の異なるコンポーネントではなく、ラベルだけが異なる同じ形のカードが繰り返されている。
• レビューレポートで「アセットの最低基準」は満たしている一方、ソーステキストの識別、モチーフの一貫性、大きなテキストの置き換えに失敗している。

リファレンスの忠実性とナラティブの境界に関するルール

ユーザーからスタイルプロンプト、画像、リポジトリ、ローカルパス、または名前付きリファレンスが提供された場合、ビジュアルシステムを説明または生成する前に、必ずその正確なソースを確認してください。Riso、エディトリアルコラージュ、プレミアムテックなどのスタイルラベルは、ソースを理解した証拠にはなりません。

ASSET_MANIFEST.json に次の内容を記録してください。

• 正確なソース：実際に確認した添付ファイル、テキストプロンプト、リポジトリ、パス、スクリーンショット、またはハウススタイルのセクション。
• 観察したビジュアルの文法：パレット、素材、エッジ処理、構図、タイポグラフィの関係、奥行き、遷移の動作など、ソースで確認できる具体的な特性を少なくとも3つ。
• ナラティブの境界：リファレンスが決定する要素と、置き換えてはならない要素。
• 避けるべき逸脱：プロダクトのストーリーを損なう、ありきたりな置き換え、近接する別のスタイル、または魅力的な仕掛け。

スタイルは表現の言語です。プロダクトのアクション、ソースの主張、登場人物、オブジェクト、証明の状態がストーリーの核です。その仕掛け自体がプロダクトの主張でない限り、プロダクトのプロモーションを、印刷、コラージュ、スキャン、機械など、スタイルの仕掛けを実演するものに変えないでください。

ユーザーがリファレンスのソースを訂正した場合、またはスタイルがストーリーを覆い隠していると指摘した場合は、アセットを追加生成する前に、ブリーフとアセットマニフェストを再確認してください。アニメーションだけを修正して、誤りを取り繕わないでください。

背景とモーションに関するルール

新しい動画制作では、原則として背景画像を計画してください。フェーズ1で必要なものを定義し、フェーズ2で確認後にアセットを生成または調達します。ユーザーから質の高いアセットが提供されている場合、または確認済みの方針がキネティックタイポグラフィのみの場合を除き、プロジェクト専用のビットマップアセットには Codex Image Gen を使用してください。

各フレームを、連携する次の4つのレイヤーとして扱ってください。

1. 舞台となる背景画像：雰囲気、奥行き、光、メタファー、またはプロダクトのコンテキスト。
2. メッセージとなるタイポグラフィ：読みやすい階層、固定されたセーフゾーン、管理された行数、画像の情報量が多い領域との意図しない重なりの防止。
3. 意味を凝縮するビジュアルオブジェクト：説明を置き換え、視線を誘導し、またはプロセスを証明する、抑制の効いたシンボル、機能的なアイコン、小道具、フレーム、マーク、またはテクスチャの断片。
4. 視線を導くモーション：シーンごとにメインの動きを1つ、任意の補助的な動きを1つとし、重要な情報を見せた後は静止させます。

画像の枚数、画像上のテキスト配置、モーションの文法、レビューのゲートには、references/motion-background-system.md を使用してください。

コンテンツに基づく画像アセット構成ルール

背景やコンポーネントの数を、尺だけで決めないでください。確認済みのソース、絵コンテ、モーション上の役割に基づいて、アセット構成を決定します。

• ビジュアルの世界：隣接するビートのうち、同じ空間的な舞台を無理なく共有できるものをまとめます。実際に異なる世界ごとに、独立した縦型背景を1つ生成します。高品質な複数シーン作品では通常、複数の背景が必要ですが、数は承認済みの分析に基づいて決定します。
• 移動可能な前景アセットの一覧：独立して動かす必要があるもの、主張を裏付けるもの、またはトランジションを担うものを、ソース固有のオブジェクトとしてすべて列挙します。この一覧に基づいて、透過コンポーネントの数を決定します。
• シートの方針：高品質な縦型の生成画像制作では、少なくとも1枚のコンポーネントシートを使用します。すべてのアセットを十分な間隔と実用的な解像度で配置できる場合は、1枚を使用します。1枚に詰め込みすぎたり、アセットを縮小したりする必要がある場合は、複数のシートに分割するか、主要オブジェクトを個別に生成します。
• 切り抜きの要件：各ソースシートを保持し、承認されたアイテムをすべて名前付きの透過 PNG に切り抜き、外周を完全な透明状態に保ち、マットのにじみを除去します。また、暗色と明色の両方のコンタクトシートで切り抜きを確認します。
• マニフェスト：フェーズ1でアセットを決定した後に ASSET_MANIFEST.json を作成し、フェーズ2で承認済みのローカルパスを追加して更新します。マニフェストを、ビジュアルの世界、背景の割り当て、コンポーネント一覧、シート上のセル、切り抜き、対象シーン、モーションアクション、検証用シートの正式な情報源とします。

フェーズ1では、選択した数が必要な理由を明記してください。ソースに基づく分析をせずに「背景4枚、コンポーネント12個」のような固定目標を設定するのは、テンプレートの不備です。フェーズ2では、承認済みの数を暗黙に変更してはいけません。アセット分析を変更する場合は、改訂内容と理由を記録してください。

高品質な縦型制作のビットマップアセットを計画、生成、切り抜き、検証、レビューする前に、references/imagegen-asset-pipeline.md を使用してください。

モーションの役割に基づくアセット網羅ルール

ビジュアルアセットのライブラリを、数だけで評価してはいけません。同じ形状のカードが並ぶ大きなシートも、ビジュアル上のアイデアとしては1つにすぎません。

高品質な複数シーン作品では、承認済みのコンポーネント一覧で、次の3つの異なる役割を網羅する必要があります。

• ナラティブの軸：ビートをまたいで、同じ被写体、記事、人物、製品の画面、または主要オブジェクトを維持します。
• 製品の実証：主張を、実際の状態、結果、コマンド、スクリーンショット、数値、選択肢、または検証として目に見える形にします。
• トランジションの担い手：ストーリーの素材をシーン間で引き継ぐため、破る、折る、経路を示す、拭き取る、押印する、扇状に広げる、組み立てる、スキャンする、または別の方法で動かします。

対応関係が明示されていれば、1つのコンポーネントが複数の役割を担ってもかまいません。ただし、高品質な複数シーン作品には、独立して動かせるコンポーネントが少なくとも3つ必要です。これは一覧の目標数ではなく、2種類の異なる2オブジェクトの組み合わせを実証できる最小限のライブラリです。

実装前に、高品質な複数シーン作品について、少なくとも2種類の異なる組み合わせテストを記録してください。各テストでは、コンポーネントのセット、シーン、振り付け、スナップショットのタイムスタンプ、削除テストを明記します。同じコンポーネントのセットに別のラベルを付けても、2つ目の組み合わせにはなりません。

ファイル数は多くてもモーションの役割が1つしかない場合、実証用の画面がすべて同じシルエットの場合、またはコンポーネントが個別に登場するだけで、受け渡し、組み立て、置き換え、表示、変形を一緒に行えない場合は、アニメーションを開始しないでください。

アセット一覧またはコンポーネントシートを承認する前に、references/asset-choreography-and-render-qa.md を使用してください。

ピュアコード例外ルール

ピュアコードの黒いステージは例外であり、制作における既定の近道ではありません。ユーザーがタイポグラフィのみのモーションスタディを明示的に依頼していない限り、暗いグラデーション、大きなテキスト、半透明のカード、細い線だけで構成されている動画を、プレミアム品質または完成状態と判断しないでください。

記事から動画への変換、コンテンツシステム、ワークフロー、製品、チュートリアル、個人用ナレッジベース、ローカルフォルダー、またはツール比較のプロモーションでは、フェーズ 1 とフェーズ 2 に、コンテンツに由来するビジュアルアセットの最低基準を含める必要があります。

• 宣言されたビジュアルの世界をカバーするのに十分な数の、独立した背景ステージ、製品のスクリーンショット、ワークスペース／ファイルツリーのキャプチャ、生成されたメタファー画像、または提供された画像。
• 宣言されたソースフレーズ、仕組み、根拠の主張をカバーするのに十分な数の、テキストボックス以外のシーン固有の証拠ビジュアル。
• すべてのビットマップまたはスクリーンショットのローカルアセットパス、またはカスタムの SVG／3D／ベクターシステムがビットマップアセットより優れている理由について、ユーザーから明示的な承認を得ていること。
• フレームが「黒い背景＋タイトル＋カード」に陥っていないことを証明するスクリーンショットレビュー。

以下の場合は、最終納品をブロックしてください。

• assets/images にプレースホルダーしかないのに、レポートで豊かな背景やビジュアルアセットシステムがあると主張している。
• 変化する被写体、シーンの奥行き、具体的な証拠のある画面がないまま、同じ暗い背景ステージがすべてのビートに使われている。
• ピュアコードの例外を正当化する理由が、利便性、依存関係の不足、または「コード生成」であることだけである。
• 被写体にビジュアル環境、生成画像、製品のスクリーンショット、またはアーティファクトライブラリが必要なのに、モーションの大部分がテキスト／カードの移動と不透明度の変化である。

画像生成アセットの規律

Codex Image Gen は、完成したポスターではなく、合成用の素材を作成するために使用します。最終的なタイポグラフィ、タイミング、マスク、クロップ、視差、フォーカス移動、テキストのコントラストは HyperFrames が担当します。

生成する前に、画像ごとにアセットブリーフを作成してください。

• 役割：ステージ、シンボル、テクスチャ、アンカー、またはトランジション用画像。
• シーンでの用途：どのビートで使うか、何を伝える必要があるか。
• アスペクト比と目標サイズ：新規の縦型作品では通常 9:16。カットアウェイやパネルには標準のアスペクト比を使用します。
• レイアウトの制約：textRect、subjectRect、静かなテキストゾーン、安全な下端、モーションの範囲。
• 焦点となる被写体：側面、中央、上部、下部領域、または背景のみ。
• 余白：カードを置かずにテキストを配置できる場所。
• 照明と配色：暗いベース、制御されたコントラスト、必要な場合に限り控えめな温かみのあるゴールド。
• 禁止する内容：画像に焼き込まれたテキスト、偽の UI、偽のロゴ、ラベル、説明用アイコン、透かし、装飾過多、無作為なシンボル、テキストゾーン内の高周波ディテール。

生成後、実装前に実際の画像を確認してください。

• 役割が明確なアセットだけを残してください。
• テキストとディテール、顔、製品の輪郭、明るい継ぎ目、プラットフォームのオーバーレイが干渉する場合は、再生成するかクロップしてください。
• 最終アセットを参照する前に、プロジェクトのアセットフォルダーに移動してください。
• ローカルパスと採用したクロップを DESIGN.md または STORYBOARD.md に記録してください。
• 同じ役割を繰り返す余分な画像は、より優れた 1 枚に置き換えてください。

ビジュアルオブジェクトの規律

優れたモーション動画には、通常、背景とテキスト以上のものが必要です。説明を減らす、注意を引く、主張を裏付ける、または記憶に残るきっかけを作る場合に限り、オブジェクトを追加してください。

実装の前に、小規模なビジュアルオブジェクトシステムを定義します。

• 主要オブジェクト：視聴者に覚えてもらう小道具、シンボル、製品の表面、フレーム、素材のうち、中心となるものです。
• 機能的マーク：説明の代わりとなる、注意を引く、または根拠を示す、小さなアイコン、スタンプ、ブラケット、チェックマーク、レール、ラベル、ガイドマークを1〜3個使用します。
• テクスチャ要素：紙片、ほこり、紙、粒子、光、奥行きの手がかりなど、紙吹雪のようにならずに雰囲気を作る要素です。
• オブジェクトの動き：オブジェクトがどのように登場し、変化し、引き継がれ、またはビートを裏付けるかです。
• 削除テスト：オブジェクトを削除した場合に、どんな意味が失われるかを確認します。

厳守するルール：

• アイコンを大量に並べないでください。動画ごとにビジュアル表現は1種類で十分です。
• テキストの各行の横に小さなアイコンを置かないでください。
• ロケット、稲妻、きらめき、AI チップ、無作為なチェックマークなどの汎用的なシンボルは、ブリーフで具体的かつ必須とされていない限り避けてください。
• 不明瞭な比喩のラベルとしてアイコンを使わないでください。オブジェクトにラベルを付けないと意味が通じない場合は、比喩を設計し直してください。
• プロジェクト固有のオブジェクトを優先してください。原稿用紙、フィルムフレーム、スキャンレール、確認スタンプ、検査ブラケット、製品の表面、タイムライン、レンズ、カーソル、地図上のルート、封印、成果物などです。
• 20秒の縦型プロモーションでは、主要オブジェクトシステムは最大1種類、機能的マークは最大3種類にしてください。
• レビューレポートには、追加したビジュアルオブジェクトが必要か、控えめか、ストーリーを損なわずに削除できるかを記載してください。

アンカー付きコネクターのルール

線、ルートパス、レール、スキャンライン、弧線、下線、ブラケット、コネクターの光彩は、それだけで高級感を演出するものではありません。これらは補助オブジェクトです。具体的なオブジェクト、単語、コンポーネントの縁、ノード、カーソル、ステータスマーク、CTA のいずれかに結び付いている場合にのみ使用してください。

コネクターを残す前に、次の項目を明確にします。

• 開始アンカー：コネクターが始まる、正確なオブジェクトまたは単語です。
• 終了アンカー：コネクターが到達する、正確なオブジェクト、単語、ノード、またはコンポーネントです。
• 役割：明らかにする、誘導する、比較する、焦点を当てる、検証する、引き継ぐ、または締めくくることです。
• 動き：装飾のように漂うのではなく、どのように状態を変化させるかです。
• セーフゾーン：テキスト、CTA、製品の表面、プラットフォームのオーバーレイと交差してはならない領域です。
• 削除テスト：削除した場合に、どんな意味、根拠、注意の方向付けが失われるかを確認します。

次の場合は、コネクターを却下するか置き換えてください。

• 見える始点と終点がなく、線が何もない空間に漂っている。
• 線が単なる上品な区切り、装飾線、または曲線にすぎない。
• 線がタイトルや製品の根拠と競合している。
• 同じつながりを、カードの縁、ステータスドット、ノードの並び、チップの状態、フレームの角、進捗ストリップ、カーソル、ハイライト、CTA の枠線で、より明確に表現できる。
• その線がなくても、視聴者がシーンを同じように理解できる。

高級感のある製品プロモーションでは、コンポーネントに付随するシグナルを優先してください。カード上端・下端のハイライト、ノードの並び、ステータスドット、短い進捗ストリップ、検査用の角、スクリーンショット上のチェックマーク、CTA の縁のライティングなどです。これらは、自由に漂う弧線よりも、作り込まれた印象になり、装飾的に見えにくい傾向があります。

サポートアセットの判断基準

装飾用アセットを必須にしないでください。必須にするのは、サポートアセットを使うかどうかの判断です。優れたモーションビデオには背景が1つだけでは足りないことがよくありますが、追加するビットマップ、SVG、マーク、テクスチャ、シェイプにはすべて、意味上の役割、ビジュアルシステムとの関係、モーション上の目的が必要です。

新しい動画制作のブリーフごとに、背景ステージ以外のサポートアセットが必要かどうかを判断してください。

• シンボル：中心となる比喩、製品のシルエット、数字を表すオブジェクト、またはビジュアルのアンカー。
• テクスチャ：フレームに触感を与えるグレイン、霞、素材の表面、シャドウプレート、ダスト、または光の減衰。
• ライト／マスク／トランジションプレート：ビートを見せたり、つないだりするために使うスイープ、アパーチャ、ワイプ素材、マット、フォーカスレイヤー、またはモーフ素材。
• セマンティックグリフ：アイデアを簡潔に表す、意味を担う最小限のマーク。アイコンセットではありません。
• 製品／UIの断片：ストーリーに証拠が必要な場合に限って使う、製品、インターフェース、チャート、または証拠となる領域の忠実な切り抜き。
• モーションアクセント：明確な注目誘導またはトランジションの役割を持つライン、きらめき、軌跡、パス、括弧、レール、または粒子状のディテール。

サポート用ビットマップアセットをHyperFrames／CSS／SVGでよりきれいに作成できない場合は、確認後にCodex Image Genを使用してください。生成画像よりもコード生成のライン、マスク、シンプルなグリフ、ベクターマーク、タイポグラフィのほうが鮮明で、制御しやすく、アニメーション化も容易な場合は、それらを優先してください。

各サポートアセットには、役割、素材元、ビットマップの場合はローカルパス、背景とのビジュアル上の関係、安全領域、モーション上の目的、開始／終了のタイミング、削除条件を明記する必要があります。意味、奥行き、トランジションの連続性、製品の証拠、または読みやすさを強化しないサポートアセットは削除するか、使用しないでください。

コンテンツに基づくサポートアセットの指針：

• 秒数ではなく、ビジュアルの世界の数を数えてください。隣接するビートで同じ背景を共有できるのは、空間的な世界、テキスト用の安全領域、ストーリー上の役割が本当に同じ場合に限ります。
• 素材に含まれる名詞、プロセスを表す動詞、証拠となる主張、トランジションの役割から、動かすオブジェクトの数を決めてください。あらかじめ決めた数に合わせるためにアセットを追加したり削除したりしないでください。
• まず公式の製品／UIアセットを使用してください。宣言したアセット一覧で必要とされている場合に限り、雰囲気を表す素材、比喩的なプレート、マスク、コンポーネントシート、ヒーローオブジェクト、または証拠の提示に適した切り抜きを生成してください。
• シンプルなライン、マスク、タイポグラフィ、鮮明なベクターマークは、ビットマップ素材の利点がない場合、コードで生成してください。

1つの動画内で生成するすべてのアセットは、配色、光の方向、レンズ／テクスチャの表現、コントラストのレベル、ネガティブスペースの扱いを含む、同じアートディレクションに統一してください。切り抜き要素ごとに明確な役割が定められ、アニメーション前に個別に分離される場合に限り、アセットシートを使用できます。1枚のシートでは切り抜きの安全性や実用解像度が損なわれる場合は、追加のシートを使うか、ヒーローアセットを個別に生成してください。

PPT風モーションを避けるためのルール

質の低いモーション制作は、しばしば不透明度のフェードだけを使った静止ポスターの連続になってしまいます。これは品質上の失敗として扱ってください。

実装の前に、複数のビートで構成される動画では、必ずモーション制作プランを定義してください。

• カメラの動き：プッシュ、パン、視差、フォーカス送り、クロップによる発見、または意図的な静止。
• テキストの動き：テキストの登場、定着、強調、退出、次のビートへの橋渡しの方法。
• SVG/CSS3 の構成：どのマスク、パス、走査線、フレーム、下線、クリップパス、ブレンドモード、フィルター、CSS 変数でトランジションを表現するか。
• GSAP の演出：ラベル、絶対タイミング、意味のあるトランジション、読みやすさを保つ静止時間を備えた、一時停止状態のマスタータイムライン。
• シグネチャーモーションの瞬間：アイデアにふさわしい、記憶に残る動き。

テキストのトランジション、SVG/CSS レイヤー、GSAP タイムライン、または動画が PPT らしくなりすぎていないかを判断する前に、references/motion-craft.md を参照してください。

優れたモーションは意味を変えます。明らかにし、比較し、変形し、圧縮し、解放し、方向を示し、または証明します。モーションを取り除いてもストーリーが変わらないなら、再設計してください。

短尺の縦型プロモーション動画に関する必須条件：

• 20 秒以下の動画では、フックまたは中心的な視点を示すフレームの少なくとも 1 つで、中央または上部中央にテキストのインパクトを持たせてください。そうでない場合は、その領域を占める、より強力なビジュアル上の主役と、それが注目を集めるうえでより効果的な理由を記録してください。
• 最初の 0～2 秒で、最初に視線を集める対象、最も大きな単語またはオブジェクト、スクロールを止めるモーションイベントを示してください。
• 3 つ以上のビートで同じ textRect、同じテキストの登場方法、同じリズムを使う場合は、ストーリーボードに PPT リスクの印を付け、実装前にレイアウトまたはモーションを再設計してください。
• 重要なテキストの演出の少なくとも 1 つには、マスク、走査、分割、圧縮、組み立て、パスの受け渡し、またはそれに相当する実際のトランジション手法を使ってください。不透明度と y 位置だけの変化は、補助的な動きに限られます。
• レビューレポートには、PPT 風モーションに関する判定を含めてください。スクリーンショットにしても意味がほとんど損なわれない動画は、まだ完成ではありません。

キネティックテキストリレールール

ユーザーがテキスト、アイコン、クールなトランジション、左／右への押し出し、上／下への押し出し、ワイプ、スキャン、タイピング、単語ごとの動き、またはキネティックタイポグラフィのような演出を求めた場合は、背景画像を主役にしたシネマティックショートではなく、キネティックテキストリレーのプロモーションを標準として選びます。

優れたキネティックプロモーションは、視覚的なイベントが連なるものです。単語、アイコン、オブジェクト、トランジション用の仕掛けが、次のビートへと注目を引き継ぎます。

このスタイルを提案または実装する前に、リレーの文法を定義します。

• キーワードの連なり：視聴者の記憶に残る4〜8個の単語または短いフレーズ。
• キーワードごとのアクションオブジェクト：抽象的な機能を視覚的なイベントに変えるアイコン、カーソル、波形、タイムライン、フレーム、ブラシ、スキャンレール、スタンプ、製品タイル、コードカーソル、または別の小さなオブジェクト。
• ビートごとの方向：左への押し出し、右への押し出し、上への持ち上げ、下への押し込み、放射状のバースト、クロップによる表示、スキャン、タイプオン、圧縮、拡大、ワイプ、ディゾルブ、または意図的なハードカット。
• リレーオブジェクト：前のビートから次のビートへ何を引き継ぐか。視覚的に見えるか、論理的に示唆されている必要があります。
• ヒーローフレームとトランジションの中間点：各ビートに、読み取れる静止フレームを1つ設け、各トランジションに、確認できる中間点を1つ設けます。
• モーション消失テスト：動きを取り除いてもストーリーがほとんど変わらない場合、そのビートの演出は不十分です。

1本の動画では、テキストリレーの表現方法を1つに絞ります。行ごとのアイコンや装飾的なステッカーの寄せ集めは避けます。各オブジェクトは、次の単語を押し出す、隠す、スキャンする、明らかにする、圧縮する、分割する、タイプする、または引き継ぐ必要があります。

10〜18秒のキネティックプロモーションでは、納品前に次の標準スコアカードを使用します。

• 20点：最初に目を引くインパクトがあり、最も大きな単語／オブジェクトが最初の0〜2秒で視聴者を引きつける。
• 20点：重要なテキストに、フェード／移動を超える演出が施されている。
• 20点：アイコンや小さなオブジェクトがトランジションに参加している。
• 20点：隣接するビートが、方向、オブジェクト、マスク、線、カーソル、スキャン、またはカメラの動きを通じてリレーの連続性を保っている。
• 10点：動きのある瞬間と読み取りやすい静止時間が交互に配置されている。
• 10点：最後のブランド／CTAがすっきり決まり、連鎖の終わりとして感じられる。

目標は100点です。100点未満の場合は、次に行う修正を明示する必要があります。90点未満では最終納品できません。70点未満ではレンダリング前に修正が必要です。60点未満ではトランジションマップを作り直す必要があります。

背景上のテキストレイアウトルール

テキストが背景画像の上または近くに表示されるすべてのビートについて、画像生成やアニメーションコードの作成を始める前にレイアウトの仕様を決めます。この仕様では、画像の比率、被写体の位置、テキスト軸、テキスト用の静かな領域、クロップ時の安全領域、タイトルサイズの段階、動きの範囲、モバイルでの安全境界を定めます。

生成画像、画像上のテキスト処理、ストーリーボードのヒーローフレーム、またはHyperFramesのレイアウトCSSを計画する前に、references/text-over-background-layout.mdを使用します。

画面下半分のテキストは、CTA、証拠を示す静止画面、または被写体が主役のフレーム用に確保します。フック、中央の視点、強調するキーワードは、通常、中央または中央上部で目を引く必要があります。テキスト領域を選ぶ前に、最初の1秒で視聴者の目をどこに導くかを決めます。

新しい動画ブリーフには、候補となるレイアウト戦略を必ず記載します。デザインシステムには、標準の戦略と許可されるバリエーションを記載します。ストーリーボードでは、生成画像または提供画像を確認した後、背景上にテキストを置く各ビートの最終レイアウト仕様を確定します。最終仕様は、1080x1920のキャンバスに描画できるだけ具体的でなければなりません。

Layout contract: cinematic side-title stage / 9:16 / left axis / textRect x=8% y=24% w=44% h=28% / subjectRect x=54% y=20% w=36% h=46% / quiet zone left 46% / safeBottomY<=85% / title tier main / motion stays inside textRect

仕様には、レイアウトの意図、画像比率、テキスト軸、テキストの矩形領域、被写体の矩形領域、静かな領域、下端の安全境界、タイトルサイズの段階、動きの範囲を含めます。中国語以外、または縦型以外の制作では、意図的に仕様を調整し、変更内容を記録します。

生成画像の静かなテキスト領域に、細部、顔、製品の輪郭、UIテキスト、またはコントラストの強いテクスチャが入っている場合は、動きを加える前に再生成またはクロップし直します。動きで、背景上のテキスト構図の破綻を補うことはできません。

レンダリングフレームの整合性ゲート

ブラウザーのプレビューは計画の根拠です。レンダリングされた MP4 フレームは納品の根拠です。

各シーンについて、SCENE_SCHEMA.json に開始、読み取り可能なホールド、終了のチェックポイントを宣言します。シーンにテキスト、透過アセット、製品 UI、レイヤー化されたカード、または複合コンポーネントが含まれる場合は、最終 MP4 から該当するフレームを抽出して確認します。

厳守事項：

• コンポーネントのコンテナ、テキスト、コントロール、シャドウ、ハイライト、装飾シェルは、トランスフォーム、不透明度、クリッピング、オクルージョンについて、同じオーナーグループを共有します。コンテナが背後にある状態で、子要素がオブジェクトの手前に出てはいけません。
• 透過アセットをテキスト、フレーム、安全領域に合わせて配置する場合は、視認可能なアルファ境界を基準にします。PNG のキャンバス矩形は視認可能なオブジェクトではありません。
• テキストをコントロール、カード、バッジ、検索フィールド、または狭いフレーム内に収める必要がある場合は、エクスポート後のフォントメトリクスを測定します。ブラウザーで収まっていても、レンダリングフレームでのはみ出しは許容されません。
• ヒーローホールドだけでなく、開始、ホールド、終了を確認します。動きによって、承認済みの静止フレームの間にクリッピングや重なりが生じることがあります。
• レンダリングフレームのパス、タイムスタンプ、名前付きのアサーションがないレビューは、証拠になりません。

ブラウザーと MP4 の内容が一致しない場合は、MP4 を正とします。レイアウトの契約、複合要素のオーナーシップ、アルファ境界に基づく配置、またはフォントサイズを更新し、再レンダリングしてフレームを再抽出します。

オクルージョン、視認可能な境界、エクスポート時のパリティ、証拠のワークフロー全体については、references/asset-choreography-and-render-qa.md を使用してください。

デザインエンジニアリング契約ルール

SVG、CSS、GSAP の調査は、エフェクトを増やすためではなく、プロダクションを支える基盤として扱います。目標は、小規模なモーションデザインコンパイラーです。

brief -> scene schema -> vector templates -> motion primitives -> GSAP timeline -> browser snapshots -> render

新しいプロダクション作業では、実装前に以下の契約を作成または更新します。

• SCENE_SCHEMA.json：構造化されたシーン、コンテンツスロット、レイアウト契約、タイミング、プリミティブの連鎖、意味的な選択理由、読み取り可能なホールド、スナップショットテスト。
• VECTOR_TEMPLATES.json：quote_card、data_point、comparison など、固定スロット、安全なジオメトリ、アイコン／装飾ルール、許可されるプリミティブ、却下テストを備えた、承認済みの SVG シーンシステム。
• MOTION_PRIMITIVES.json：maskReveal、pathDraw、clipWipe、staggerText、numberCount など、意味的なユースケース、必須セレクター、GSAP プロパティ、中間点の要件、却下テストを備えた、承認済みのモーション語彙。

LLM はテンプレートの選択、スロットへの入力、許可されたプリミティブの選択を行えます。ただし、ブリーフで探索的なアートが明示的に求められ、リスクが文書化されている場合を除き、プロダクションフレーム用の SVG ジオメトリ、モーションプリミティブ、タイミング文法を自由に作り出してはいけません。

新しいテンプレート、プリミティブ、トランジションデバイス、アイコンシステム、またはバッチ生成モードを追加するか判断する前に、references/design-engineering.md を参照してください。

厳守事項：

• スタイルの幅を広げる前に、小規模な承認済みの語彙から始めます。
• プリミティブは見た目の新しさではなく、意味的な役割に基づいて選びます。
• 短いプロモーションでは、マスク、clipPath、パス、SVG のストローク、または CSS 構造のうち少なくとも 1 つで、重要なリビールまたはトランジションを実現します。
• 中国語テキストのレイアウトは、最終納品前にブラウザーのスナップショットで測定します。
• トランジションの中間点は検査できる状態にします。中間点のフレームが空白になるのは品質上の不備です。
• 自然言語の成果物だけでプロジェクトが合格し、構造化された契約が不要な場合、そのプロジェクトは依然としてプロンプト主導であり、プロダクションに対応できる状態ではありません。

GSAP の振り付けに関するルール

プレミアムなモーションの振り付けエンジンとして GSAP を使用します。コンポジション全体に独立したトゥイーンを散在させないでください。

実装するすべてのコンポジションでは、次の項目を使用してください。

• HyperFrames の制御に登録された、一時停止状態のマスタータイムラインを 1 つ使用します。
• hook、reveal、proof、cta などのタイムラインラベルを使用します。
• delay の連鎖ではなく、位置パラメーターを使用します。
• 共通の再生時間とイージングには、タイムラインのデフォルト値を使用します。
• x、y、xPercent、yPercent、scale、rotation、svgOrigin などの GSAP のトランスフォームエイリアスを使用します。
• 要素を非表示／表示する際は、生の opacity ではなく autoAlpha を使用します。
• 同じターゲット／プロパティに後続の from()／fromTo() トゥイーンを重ねる場合は、immediateRender: false を設定します。
• 使用前にプラグインを登録します。

プレミアムな GSAP プラグインは、演出に必要な場合にのみ使用します。

• 大きな中国語のフック文、キーワードの連なり、CTA のロックアップには SplitText を使用します。
• ロゴのストローク、起点が固定された証明用コネクター、スキャンレール、ルートノードのシグナル、検査ブラケットには DrawSVGPlugin を使用します。
• あるアイデアが別のアイデアへ視覚的に変化する場合は MorphSVGPlugin を使用します。
• オブジェクトの動きでレールやパスに沿って視線を誘導する場合は MotionPathPlugin を使用します。
• シグネチャーとなる 1 つのモーションには CustomEase を使用します。

GSAP プラグインはすべて、公開されている gsap パッケージから取得します。古いプライベートレジストリ、Club GSAP、認証トークンに関する手順は追加しないでください。

GSAP タイムライン、プラグインの使用、プレミアムなテキスト表示、SVG パスの描画、モーフィング、モーションパス、カスタムイージング、パフォーマンスに影響するモーションを実装する前に、references/gsap-choreography.md を確認してください。

デフォルトの言語とフォーマット

ユーザーが別の言語やフォーマットを明示的に指定しない限り、新規動画制作では中国語のプロモーション映像をデフォルトとします。中国語のコピー、縦型のフレーミング、ソーシャル動画の視聴習慣によってレイアウト全体が変わるため、このデフォルトは重要です。

• 言語：画面内のコピーは、デフォルトで簡体字中国語にします。英語の製品名、モデル名、コード用語、ブランド名は、素材に含まれている場合にのみ残します。
• フォーマット：デフォルトで縦型の 9:16 にします。
• サイズ：デフォルトで 1080x1920 にします。
• プラットフォームの想定：プロンプトで YouTube の長尺動画、基調講演のスクリーン、ウェブサイトのヒーロー、デスクトップのランディングページなど、横長の表示面が明示されていない限り、縦型表示の Douyin／TikTok／Reels／Shorts スタイルを想定します。
• 長さ：短いプロモーションモーション動画では、デフォルトで 10～15 秒にします。証拠や CTA に余裕が必要な場合は 15 秒にします。
• セーフマージン：プラットフォーム UI、字幕、CTA に備えて、上下に広めのマージンを確保します。重要なテキストを下部のオーバーレイ領域に配置しないでください。
• コピーの密度：中国語の縦型動画では、1 ビートあたりの文字数を減らし、改行を増やし、横長のデスクトップ映像より大きな文字を使用します。

ユーザーが YouTube、ウェブサイトのヒーロー、基調講演、ワイドスクリーン映像を指定した場合は、意図的にフォーマットを変更し、その理由をブリーフに記載します。気づかれないまま横長のデフォルトへ移行しないでください。

出力の執筆基準

作成するすべての成果物、特に BRIEF_DESIGN_PROPOSAL.md、DESIGN.md、STORYBOARD.md、REVIEW_REPORT.md は、制作指示として直接使える内容にします。

次の点を守ってください。

• 短く、具体的な文にします。
• プロジェクト固有の事実、決定事項、制約を記載します。
• 画面に何を表示するか、何を動かすか、何を生成するか、何を確認するかを明確に述べます。
• ユーザー向けの提案文には、別の言語を指定されない限り、平易な中国語を使用します。

次の点は避けてください。

• 中国語または英語で、対比を軸に展開する言い回しを繰り返すこと。
• AI 風の自己説明、独り言、プロセスの説明、内部推論。
• ありきたりな誇張表現、営業文句、スローガン、大げさな形容詞。
• 関係のない視覚理論、プラットフォームへの論評、デザイン上の余計な情報。
• 決定事項、ルール、リスクを 1 行で示せるのに、長く説明すること。

フェーズ 1 の提案文は簡潔にまとめます。ユーザーが方向性をすばやく承認できるよう、要点、ビジュアル計画、素材計画、レイアウト、モーション、リスク、確認依頼を記載します。売り込み資料やブレインストーミングの記録のような文体にはしないでください。

2段階ルール

新しい動画制作は、必ず次の2段階に分けてください。

フェーズ1：概要／デザイン提案

簡潔な提案を作成し、ユーザーの確認を待ちます。画像の生成、アニメーションコードの作成、動画のレンダリング、HyperFrames のコンポジション全体の構築は、確認を得るまで行いません。

提案には、次の内容を含めてください。

• 本質：核となる視点、最大の対立、感情の中心、強調するキーワード、視覚的な比喩。
• 関連する場合は、製品の証拠となる要素の一覧：既存のアセット、製品の画面、コマンド、スクリーンショット、出力例、数値、モジュール、分類体系、プロバイダー、確認項目、不足している要素。
• ソースに基づくビジュアルシステム：ソース内のフレーズ、具体的な名詞、プロセスを表す動詞、モチーフの系統、テキストからコンポーネントへの対応表、大きなテキストボックスの置き換え計画、汎用的なビジュアルの却下リスト。
• 構成：中心となるシンボル／大きなタイトル／人物のアンカー／巨大な数字。
• フォーマット：言語、プラットフォーム、アスペクト比、ピクセルサイズ、長さ、FPS、安全マージン。指定がなければ、簡体字中国語、縦型 9:16、1080x1920 をデフォルトとします。
• 画像の要否：生成したビットマップ画像が必要かどうか、各アセットの役割、画像の比率、テキスト用の余白、禁止する内容、HyperFrames に残すべき要素。
• アセット数の分析：異なるビジュアル世界、動かせる前景要素の一覧、数の根拠、シート数、個別に生成するヒーローオブジェクト、予定している ASSET_MANIFEST.json。
• 背景の計画：画像の役割、レイアウトの条件、被写体の位置、テキスト用の安全領域、トリミングのリスク、確認後に Codex Image Gen を使うかどうか。
• ライティング基準：簡潔で、プロジェクトに即した表現にし、独り言、汎用的な誇張表現、同じ対比表現の繰り返しを避けます。
• ビジュアルオブジェクトの計画：主要なオブジェクト、機能を持つマーク、テクスチャ要素、各オブジェクトが必要な理由、除外するオブジェクトの種類。
• 補助アセットの計画：シンボル、テクスチャ、トランジション用プレート、意味を持つグリフ、製品／UI の断片、モーションのアクセントが動画に必要かどうか、コード生成で残す要素、装飾にしかならない場合に削除すべき要素。
• 製品プロモーションに必須のビジュアルコンポーネントライブラリ：コマンドカード、出力カード、統計ブロック、チップ、証拠カード、アンカー付きシグナル、ルートノードの連続、スクリーンショット、アイコン、マーク、パネル、CTA バッジと、それぞれの意味的な役割。
• コネクター／ラインの判断：ルート、レール、弧、下線、スキャンライン、パスが必要かどうか、そのアンカー、役割、安全領域、削除テスト、コンポーネントに付随させる代替案。
• アイコン／装飾システム：必要なアイコン、マーク、断片、グロー、パネル、枠線、チップ、テクスチャレイヤーと、それらが証明する内容。
• コピー戦略：課題、仕組み、証拠、信頼性、CTA。他の製品にも当てはまる汎用的な文言は書き換えます。
• タイポグラフィ：タイトル／補足／CTA のサイズ、タイトルのサイズ区分、行の高さ、文字間隔、最大行数、テキスト間の余白、はみ出しへの対処。
• レイアウト：視覚的な重心、レイアウトの条件、グリッド／配置、トリミングしても安全な領域、モバイルでのオーバーレイのリスク。
• モーション：メインの登場演出、背景の動き、補助アセットの振り付け、トランジションのスタイル、静止時間、イージング、効果音のタイミング、モーションの範囲、静止させるべき要素。
• モーションの作り込み：カメラの動き、キネティックタイポグラフィ、テキストのトランジションパターン、SVG/CSS3 レイヤー、GSAP タイムラインの構造、特徴的なモーションの見せ場。
• 関連する場合は、キネティックテキストのリレー計画：キーワードの連鎖、アクションオブジェクトの連鎖、プッシュ／ワイプ／スキャンの方向マップ、リレーオブジェクト、トランジション中間点のスナップショット、100点満点でのアンチPPT目標スコア。
• リスクの確認項目：読みにくくなる、雑然とする、スタイルから逸脱する、視覚的にありきたりになる要因。
• アンチPPTのリスク：作品が映像ではなくスライドのように感じられる要因と、それを避ける演出方針。
• 視線誘導マップ：最初に視線を集める対象、中央にインパクトを置くかどうか、そのテキストを中央、上部中央、サイドタイトル、下部の安全領域のいずれに置くか、その理由。

フェーズ1の最後に、明確な確認依頼を添えてください。制作は、ユーザーが確認、修正、または明示的に進行を指示した後にのみ開始します。

フェーズ 2：本番制作

確認後、本番用成果物を作成または更新し、必要な画像を生成して、HyperFrames のコンポジションファイルを実装します。その後、検証、スナップショットの作成、レンダリングを行い、タスクの要件に応じてレビュー用成果物を作成します。

対象範囲

HyperFrames のコンポジション、製品ローンチ動画、ウェブサイトから動画へのプロジェクト、記事を動画にした作品、基調講演での発表、キネティックタイポグラフィ、トランジションを多用したテキスト／アイコンのプロモーション動画、音楽に同期したモーショングラフィックス、既存の HyperFrames 動画編集にこのスキルを使用します。

単純なコピーライティング、静的ポスター、通常のランディングページ、汎用的な広告コピー、コードを使わない MP4 の直接編集には使用しません。

新しい動画を作成する場合は、まず BRIEF_DESIGN_PROPOSAL.md を作成し、確認を待ちます。確認後、必要に応じて DESIGN.md、STORYBOARD.md、必要なアセット、HyperFrames のコンポジションファイル、REVIEW_REPORT.md、および任意で REVIEW_PACK.md を作成または更新します。

タイミングが音楽、ナレーション、または正確なタイミングに依存する場合は、BEAT_MAP.json を使用します。振り付け、背景の動き、マスク、トランジションに個別のマップが必要な場合は、MOTION_MAP.json を使用します。8 秒を超える複数シーンの動画では、通常どちらか一方が必要です。

既存の編集では、まずプロジェクトを読み込みます。依頼で変更が必要な場合を除き、現在のビジュアルシステムを維持します。影響を受けるアーティファクトだけを編集し、関連する検証を再実行します。

納品後にユーザーのフィードバックから視覚的な不具合が見つかった場合、その修正を一度限りのパッチとして扱わないでください。不具合を REVIEW_REPORT.md に追加し、根本原因を記載します。その不具合を許した上流の仕様またはテンプレートを更新し、スナップショットとレンダリングのチェックを再実行します。また、SKILL.md、テンプレート、検証スクリプトに小さなルールの更新が必要かどうかを判断します。

必須ワークフロー

1. 要件の確認

次の項目を抽出または推定します。

• 元となる記事、トピック、または製品のテーマ。
• 目標と CTA。
• 対象ユーザー。
• 言語とプラットフォーム。指定がない場合は、縦型ソーシャル動画向けの簡体字中国語のプロモーションコピーをデフォルトとします。
• アスペクト比とピクセルサイズ。プラットフォームまたはユーザーから別の指定がない限り、デフォルトは 9:16 と 1080x1920 です。
• 尺。
• 製品またはオファー。
• 必須の訴求ポイント。
• トーンとスタイル。
• 利用可能なアセット。
• 厳守する制約。

詳細が不足している場合は、慎重に仮定し、ブリーフに記載します。不足項目によって制作ができない場合に限り、質問します。

動画全体を計画する際は、references/workflow.md を読みます。

1.5. 本質の抽出

デザインの前に、次の項目を抽出します。

• 中心となる視点。
• 最大の対立。
• 感情の中心。
• 視覚的に強調する価値があるキーワード。
• 動画全体を支える視覚的なメタファーを 1 つ。

抽象的なアイデアを、抑制の効いたシンボルに置き換えます。例：AI による代替は消された人間のシルエットに、不安は今にも切れそうな糸に、時間は暗闇の中のカウントダウンに、成長はひび割れの中の光に、情報過多はブラックホールに引き込まれるデータの断片に、長期主義は遠くに灯る唯一の明かりに、プラットフォームの移行は黒いオベリスクまたはデータタワーに、自動化は静かな機械に入っていく書類に置き換えます。

2. 承認用ブリーフ

templates/BRIEF_DESIGN_PROPOSAL.template.md から BRIEF_DESIGN_PROPOSAL.md を作成するか、同じ構成を回答内に提示します。

簡潔で明確な内容にします。制作上の合意事項として扱います。この提案を提示したら作業を止め、確認を求めます。

3. デザインシステム

templates/DESIGN.template.md から DESIGN.md を作成します。

デザインシステムでは、タイポグラフィ、配色、スペーシング、密度、メタファーシンボル、ビジュアルオブジェクトシステム、背景画像システム、生成画像プラン、テキストオーバーイメージのルール、モーションの個性を指定する必要があります。これにより、後続のステップが新たなビジュアル言語をその場ででっち上げることを防ぎます。

製品プロモーションの場合、デザインシステムではさらに、製品の証拠インベントリ、ソース駆動のビジュアルシステム、必須ビジュアルコンポーネントライブラリ、アイコン／装飾システム、アセットライブラリ、コピーのはしご、モーションインタラクションルールを指定する必要があります。背景1枚とタイトルだけのデザインシステムは、ユーザーが明示的にミニマルなコンセプトフィルムを求めていない限り、プレミアムな製品プロモーションには不十分です。

ビジュアル品質、タイポグラフィ、レイアウト、モーションを判断する前に references/visual-standard.md を読んでください。 製品、ツール、CLI、API、ワークフロー、スキル、テンプレート、またはリファレンス駆動のプロモーション作業の前に references/premium-product-promo.md を読んでください。 画像枚数、背景の役割、アニメーションの文法、テキストオーバーイメージの扱いを決める前に references/motion-background-system.md を読んでください。 レイアウト契約、画像比率、テキスト矩形、被写体矩形、タイトルの階層、クロップセーフゾーン、下部セーフ境界を決める前に references/text-over-background-layout.md を読んでください。 キネティックタイポグラフィ、CSS/SVG レイヤー、シーン遷移、GSAP 構造、アンチ PPT 品質ゲートを決める前に references/motion-craft.md を読んでください。 シーンスキーマ、ベクターテンプレート、モーションプリミティブ、テンプレート選択ルール、レンダー検証、バッチテンプレートを決める前に references/design-engineering.md を読んでください。 タイムライン、ラベル、位置パラメータ、GSAP プラグインの使用、SplitText、DrawSVG、MorphSVG、MotionPath、CustomEase、パフォーマンスルールを実装する前に references/gsap-choreography.md を読んでください。 スタイルリファレンス、アセットの役割カバレッジ、コンポジットの所有権、透過アセットの位置合わせ、レンダリングフレームの証拠を承認する前に references/asset-choreography-and-render-qa.md を読んでください。

4. ストーリーボードとコピー

templates/STORYBOARD.template.md から STORYBOARD.md を作成します。

デフォルトの短いモーション展開：

Hook -> Tension -> Metaphor Reveal -> Proof -> CTA

10 秒のナレーションなしキネティックタイポグラフィ動画では、テキストを簡潔に保ちます。通常は、1 つのビートにつき 1 つのアイデアで十分です。

素材に合わせて構成を選びます。

• 中央のシンボル：トレンド、インサイト、AI、プラットフォーム、哲学。
• 巨大なタイトル：対立、サスペンス、感情、視点。
• 人物を主軸にする：チュートリアル、インタビュー、パーソナルブランド、方法論。
• 巨大な数値：成長、節目、データの衝撃。

各ビートには以下が必要です。

• タイミング。
• 画面上のテキストまたはビジュアルアクション。
• ヒーローフレームのタイムスタンプ。
• レイアウトとビジュアルの階層。
• 注意マップ：最初に目を引く対象、主要な焦点領域、テキストを中央で主役にするか、被写体に譲るか。
• ヒーローテキストゾーン：中央、上部中央、サイド、下部セーフゾーン、分割のいずれかと、その理由。
• 背景画像の状態とテキストセーフゾーン。
• レイアウト契約。textRect、subjectRect、タイトル階層、safeBottomY、モーション境界を含みます。
• テキストトランジション：出現、固定、強調、退出、ブリッジ。
• テキストトランジションの手法：マスク、スキャン、分割、圧縮、組み立て、引き継ぎ、または静止させる明確な理由。
• モーションをなくした場合に変わること。
• モーションの方向：カメラ、背景、シンボル、テキスト、SVG／CSS レイヤー、トランジションの動き。
• 注意を引く対象と静止／ホールドの要件。
• 退出時のトランジション。
• 該当する場合は音声またはリズムに関するメモ。
• 品質に関するメモ。
• 比喩の役割：このフレームが抽象的なアイデアのどの部分を担うか。
• 該当する場合はプロダクトの証明としての役割：主張に信頼性を持たせる、製品固有の成果物、コンポーネント、数値、スクリーンショット、出力、コマンド、チップ、アイコン、またはマーク。
• 該当する場合は原文フレーズとビジュアルへの変換：このビートが、どの原文の正確なフレーズをコンポーネント、モーション、シンボル、または証明面へ変換するか。
• 該当する場合はコンポーネントのインタラクション：タイピング、ルーティング、扇状展開、組み立て、チェック、ロック、公開、保存、エクスポートなど、コンポーネントが実行する状態変化。
• 該当する場合はコネクターの固定先：線、レール、パス、下線、円弧が正確にどのオブジェクトをつなぐか、およびコネクターが浮いて見える場合に置き換える、コンポーネントに付随するシグナル。

音楽、サウンドデザイン、ナレーション、ビートヒット、またはキャプションが重要な場合は、references/audio-sync.md を読みます。

5. デザインエンジニアリング契約

テンプレートから制作契約を作成または更新します。

• templates/SCENE_SCHEMA.template.json から SCENE_SCHEMA.json。
• templates/VECTOR_TEMPLATES.template.json から VECTOR_TEMPLATES.json。
• templates/MOTION_PRIMITIVES.template.json から MOTION_PRIMITIVES.json。

契約では以下を固定する必要があります。

• 承認済みのシーンテンプレートとそのスロット。
• レイアウトの幾何情報、textRect、subjectRect、safeBottomY、タイトル階層、視覚的な中央揃えの許容誤差。
• シーンごとのモーションプリミティブの連鎖。
• 各プリミティブの意味に基づく選択理由。
• GSAP ラベル、位置パラメーター、変換エイリアス、プラグイン要件、autoAlpha ポリシー。
• トランジション中間点のスナップショット要件。
• 合成の所有権、アルファ表示範囲の決定、開始／ホールド／終了のエクスポートチェックポイント。
• テンプレートとプリミティブの却下テスト。
• レイアウト、SVG の幾何情報、タイミングの文法を変更せずにコンテンツを一括置換できるかどうか。

新しい作業では、実装時に文章から SVG の幾何情報や GSAP のタイミングを直接考案させないでください。まずストーリーボードを契約に変換してから、契約に基づいて実装します。

実行します。

node scripts/validate_design_engineering.mjs <project-dir>

6. ビジュアルアセット計画

確定した提案でビットマップアセットが必要な場合は、HyperFrames の実装前に生成または調達してください。複数のシーンを使う高品質な縦型コンテンツでは、ASSET_MANIFEST.json に定義された、コンテンツに基づく独立した縦型背景と前景オブジェクトのセットを生成してください。再利用可能な背景を1つだけ用意したり、アセット数を固定したりすることを標準にしないでください。

製品プロモーションでは、背景画像だけで済ませないでください。公式アセット、リポジトリアセット、スクリーンショット、生成したモックアップ、コードで作成したカード、SVG アイコン、チップグループ、パネル、固定表示するシグナル、出力プレビューなどを含むアセットライブラリを構築してください。各アセットは、製品の主張を裏付けるか、モーションインタラクションを支えるものである必要があります。ビジュアルコンポーネントライブラリのない製品プロモーションは、実装の準備ができていません。

コンテンツシステム、ワークフロー、ローカルフォルダー、ナレッジベース、チュートリアル、記事から動画へのプロモーションでは、ユーザーがタイポグラフィのみの映像を明示的に承認していない限り、画像アセットフォルダーが空でもよいと安易に判断しないでください。宣言されたすべてのビジュアル世界と、目に見える証拠が必要なすべての情報源の主張を網羅できるよう、具体的なビジュアル段階と裏付けとなるビジュアルを十分に用意してください。抽象的なカードより、実際のローカルワークフロー素材のほうが通常は効果的です。たとえば、ファイルツリーの切り抜き、下書きのスクリーンショット、ゲートレポート、指標テーブル、ワークスペースパネル、製品画面、生成した象徴的な背景プレートなどです。

各 Codex Image Gen のリクエストでは、次の点を守ってください。

• 背景ステージ、中央のシンボル、テクスチャ、製品・人物・オブジェクトのアンカー、トランジション用プレート、意味を持つグリフ、製品・UI の断片、またはモーションアクセントに必要なアセットだけを生成してください。
• 各画像またはサポートアセットに、役割を1つと対象シーンを1つ割り当ててください。
• アスペクト比、目標サイズ、主題を配置する位置、テキスト用の空白領域、切り抜きに安全な領域、プラットフォーム上で避けるべき境界、禁止する内容を指定してください。
• 生成前に、サポートアセットのスタイル規定、安全領域、モーションの目的、表示・退出タイミング、削除の条件を指定してください。
• 確認済みの参照スタイルとナラティブ上の境界を正確にプロンプトに反映してください。スタイル名だけに頼らないでください。
• コンポーネントのモーション上の役割を明示してください。ナラティブアンカー、製品の裏付け、トランジションの担い手、または情報源に基づく明示的な拡張のいずれかです。
• 余白を活かした簡潔な構図、使いやすいネガティブスペース、暗いコントラストを指定し、正確なタイトル文字が必要な場合を除き、画像に文字を焼き込まないでください。
• 可能な限り、タイポグラフィ、裏付けとなる注記、CTA、ロゴ、マスク、切り抜き、視差、フォーカス移動、タイミングは HyperFrames で処理してください。

生成後は、次の手順に従ってください。

• 返された画像がレイアウト仕様に合っているか確認してください。
• テキスト用の空白領域に文字がある画像、偽の UI、偽のロゴ、ラベル、透かし、無関係なアイコン、細部が過剰な画像、主題の配置が不明瞭な画像は却下してください。
• 画像に読みやすいテキストを載せられない場合は、実装前に切り抜きを調整するか、再生成してください。
• コンポーネントシートの元画像を保持し、採用した各アイテムを名前付きの透過 PNG に切り抜き、外周の透明部分とマット処理の仕上がりを確認し、暗色・明色のコンタクトシートを作成してください。
• 見た目が豊かなシートでも、採用したすべてのアイテムが同じシルエットを繰り返していたり、同じモーション上の役割に集中していたりする場合は却下してください。
• アニメーションを実装する前に、宣言したコンポーネントの組み合わせテストを実行してください。
• アニメーションコードを書く前に、node scripts/validate_image_assets.mjs <project-dir> を実行してください。
• 採用したアセットを参照する前に、プロジェクトのアセットフォルダーに保存してください。

7. アニメーション前のレイアウト

まず、読みやすく静止したフレームを作成してください。動きを加える前に、停止した状態でもフレームの内容が明確に伝わる必要があります。

各シーンで、以下を確認してください。

• メインメッセージが、対象プラットフォームの表示サイズで読みやすいこと。
• 背景画像に明確な役割があり、テキストの邪魔にならないこと。
• テキストが、細部の多い場所ではなく、意図して設けた余白に配置されていること。
• 選択したレイアウトのルールが、画像とメッセージの形状に合っていること。
• 画像の比率が標準的で、元画像のランダムな縦横比をそのまま踏襲していないこと。
• 意図的に分割する場合を除き、テキストの矩形内でタイトル、補足、CTA、根拠の注記がひとまとまりで読みやすく配置されていること。
• 被写体の矩形内で、顔、製品の縁、UI テキスト、シンボルが安全でないトリミング領域に入っていないこと。
• タイトルのサイズ階層が、実際の文字数、言語、行数、スマートフォンでの視認距離に合っていること。
• 下部と右上のプラットフォーム用セーフゾーン内に、CTA、字幕、根拠の注記、補足行、ブランドロックアップが収まっていること。
• テキストが重ならず、安全な余白からはみ出していないこと。
• テキストコンテナに最大幅、最大行数、オーバーフロー時の動作が設定されていること。
• 長い単語、中国語と英語が混在するテキスト、CTA ラベルが、それぞれのボックスからはみ出さないこと。
• フォントサイズがブレークポイントごとに固定され、ビューポート幅に応じて拡大縮小されないこと。
• 階層が明確であること。
• シーンを支配するアイデアが一つであること。
• シーンを支配するビジュアル要素が一つで、目的のない装飾がないこと。
• コネクター、線、レール、弧、下線、パスには視認できるアンカーと意味上の役割があること。ない場合は、コンポーネントに付随するシグナルに置き換えること。
• CTA またはブランドロックアップが視覚的に弱くないこと。
• アイコンのラベルがなくても、メタファーを理解できること。
• フレームがハウススタイル（黒、簡素、映画的、白／グレー／暖色系ゴールド）に沿っていること。

レイアウトが機能してから、GSAP などのモーションを追加してください。

8. モーション

アニメーションを追加する前に、references/visual-standard.md と references/motion-background-system.md を読んでください。

モーションは、流れと強調を明確にするために使ってください。すべての要素に同じような y 方向の移動と不透明度変化による登場を適用しないでください。主要なテキストには、読めるだけの表示時間を確保してください。

各シーンをアニメーション化する前に、次の問いに答えてください。

• 注意を向ける対象は何ですか？
• 背景、シンボル、テキスト、製品の各レイヤーのうち、最初に動くものはどれですか？
• 視聴者が読み取れるよう、静止させる必要がある要素はどれですか？
• 表示後の静止時間はどこですか？
• この動きは、ノイズを加えるのではなく、どのように意味を変えますか？
• 構造を担う CSS3／SVG の仕掛けはどれですか？（マスク、パス、クリップ、走査線、フレーム、下線、パースペクティブレイヤー、ブレンドなど）
• 線、パス、レール、弧、下線を使う場合、どのオブジェクトを正確なアンカーにしますか？また、カードの縁、ノード、ステータスドット、プログレスストリップ、CTA の枠線より優れているのはなぜですか？
• 次のシーンへの橋渡しとなるよう、消えてしまうだけの汎用的なフェードではなく、退出するテキストをどう活用しますか？

HyperFrames で GSAP を使う場合：

• タイムラインは一時停止状態にしてください。
• HyperFrames で制御できるよう、タイムラインを登録してください。
• タイミングには明示的な位置パラメーターを使ってください。
• タイムラインの構築は同期的かつ決定論的にしてください。
• 無関係な要素ごとのエフェクトではなく、ラベル付きのマスタータイムラインを優先してください。
• レンダリング上重要なモーションでは、レイアウトをずらすプロパティを避け、transform、opacity、filters、masks、clip paths、CSS variables をアニメーション化してください。

動きが十分に強いかを判断する前に references/motion-craft.md を読んでください。レンダリングの前に references/hyperframes-stability.md を読んでください。

セレクター、ラベル、タイミング、イージング、トランジションの確認が難しくなる場合に限り、templates/MOTION_MAP.template.json から任意の MOTION_MAP.json を作成してください。

9. 検証

プロジェクトで利用できる、最も強力なチェックを実行してください。次を優先してください。

npx hyperframes doctor
npx hyperframes lint
npx hyperframes validate
npx hyperframes inspect
npx hyperframes snapshot <composition> --at <times>

プロジェクトやインストール済みの HyperFrames のバージョンで異なるコマンド構文が使われている場合は、ローカルのパッケージドキュメントまたは CLI のヘルプを確認し、適宜対応してください。

最終成果物の検証は必須です。依存関係が不足していてコマンドを実行できない場合は、そのことを明記し、実行可能な静的チェックは行ってください。

ローカルでの決定論的なチェックには、必要に応じて同梱のスクリプトを使ってください。

node scripts/check_assets.mjs <project-dir>
node scripts/validate_artifacts.mjs <project-dir>
node scripts/validate_design_engineering.mjs <project-dir>

10. レンダリング

レビューにはドラフトレンダリングを使用し、最終納品には高品質レンダリングまたは Docker レンダリングが利用可能な場合はそれを使用します。

npx hyperframes render --quality draft --output renders/draft.mp4
npx hyperframes render --quality standard --output renders/review.mp4
npx hyperframes render --docker --quality high --output renders/final.mp4

インストール済みの CLI に合わせてフラグを調整してください。

11. レビューレポート

templates/REVIEW_REPORT.template.md から REVIEW_REPORT.md を作成します。

レポートには次の内容を含めます。

• 出力ファイル。
• 検証ステータス。
• スナップショットのタイムスタンプ。
• 時間範囲ごとの視聴メモ。
• 問題点。
• 次に推奨する編集。

出力、スナップショット、レポートがそろったら、scripts/build_review_pack.mjs <project-dir> を使用して REVIEW_PACK.md を作成します。

品質ゲート

動画の準備が完了したと伝える前に、次の項目を確認してください。

• デフォルトまたはオーバーライドが明示されています：簡体字中国語、9:16、1080x1920、および垂直方向のセーフマージン。
• BRIEF_DESIGN_PROPOSAL.md の確認後にのみ、新規動画の制作が開始されています。
• 必須の成果物が存在するか、省略した成果物について説明されています。
• 新規制作では SCENE_SCHEMA.json、VECTOR_TEMPLATES.json、MOTION_PRIMITIVES.json が存在するか、例外が文書化されています。
• シーンスキーマは、承認済みのベクターテンプレートとモーションプリミティブを参照しています。
• モーションプリミティブには、意味に基づく選定理由と却下テストが含まれています。
• GSAP タイムラインでは、適切な場合にラベル、位置パラメーター、デフォルト値、変換エイリアス、autoAlpha を使用しています。
• GSAP プラグインの使用は登録・文書化され、意味上の役割に基づいて選定されています。
• 承認済みのテンプレートがある場合、実装で制作向け SVG ジオメトリを自由に考案していません。
• 依頼されたビルドでは、文章だけでなく、スキャフォールド／コンポジションのソースが生成されています。
• アニメーション前に静的なヒーローフレームが機能しています。
• 最初のフレームとヒーローフレームの主要なビジュアル要素は、視覚的に中央に配置されるか、意図的にずらされ、端の安全範囲内に収まっています。また、ブラウザーのスナップショットとレンダリング済み MP4 の静止画の両方で確認されています。
• タイポグラフィのみで構成されない動画では、ビジュアルアセットの最低要件を満たしています：背景または実証用アセットがローカルに存在し、スクリーンショット／レンダリング済みフレームには黒い背景とテキスト／カードだけではないビジュアルがあり、純粋なコードで対応する例外は明示的に承認されています。
• テキストはセーフマージン、最大行数、オーバーフロー規則、クロップ安全領域、プラットフォームのオーバーレイ領域に収まっています。
• テキストを背景に重ねるビートでは、textRect、subjectRect、safeBottomY、タイトル階層、静穏領域、モーション範囲が宣言されています。
• 生成画像は使用前に、役割、対象シーン、テキスト用の静穏領域、承認済みのローカルパス、使用可能なクロップが定義されています。
• 製品プロモーションには、製品の実証用インベントリ、必須ビジュアルコンポーネントライブラリ、アイコン／装飾システム、アセットライブラリ、コピーの段階構成、コンポーネントのインタラクション計画が含まれています。
• 製品、記事、ワークフロー、ナレッジのプロモーションには、ソースに基づくビジュアルシステムが含まれています：ソースのフレーズ、名詞、プロセスを示す動詞、モチーフの系統、テキストからコンポーネントへのマッピング、大きなテキストボックスの置き換え、汎用ビジュアルの却下。
• 製品プロモーションは、承認済みのソースに基づくコンポーネントインベントリを満たしています。ソースで必要とされる具体的なサーフェス、分類体系、実証、または最終アクションの各コンポーネントがすべて含まれ、主要な各コンポーネントのスナップショットによる証拠があります。
• ヒーローフレームによって、ソーステキストの内容が伝わることが実証されています。視聴者には、汎用的なオフィス小物、大きなテキストボックス、見栄えのよいアセットパックだけでなく、ソース固有のオブジェクト、アクション、数値、または製品の状態が見える必要があります。
• 製品プロモーションのストーリーボードでは、ソースで必要とされる具体的なビジュアルコンポーネントをすべて明記し、その数の根拠を説明しています。プリセットのコンポーネント数を分析の代わりにすることは認められません。
• 製品プロモーションのコピーは具体的です。課題、仕組み、実証、信頼性、CTA が汎用的な内容になっていません。
• 製品プロモーションのスナップショットは、タイトルカードだけでなく、製品を実証するフレームになっています。
• 製品プロモーションのコネクターは、視認できる製品コンポーネントに固定されるか、カードに付随するシグナルに置き換えられています。宙に浮いた弧や装飾的な線は残っていません。
• 新規動画では、サポートアセットの採否が、採用しない場合も含めて文書化されています。
• ビットマップを生成する場合、ASSET_MANIFEST.json に承認済みのビジュアルワールド、背景数の判断、コンポーネントインベントリ、シートの方針、切り抜き画像のパス、実証用シートが記録されています。
• ASSET_MANIFEST.json に、スタイルの正確な参照元、観察されたビジュアル文法、ナラティブの境界、避けるべき逸脱、モーション役割の網羅性、コンポーネントの異なる組み合わせを試すテストが記録されています。
• プレミアムな複数シーンの画像制作では、宣言されたビジュアルワールドごとに独立した縦型背景を使用しています。時間に基づいて背景数を固定する方法や、背景を1つだけ使う近道は却下されています。
• 承認されたコンポーネントシートの各項目は、個別の透過アセットとして存在し、明暗のコンタクトシートレビューに合格し、コンポジションから参照されています。
• サポートアセットは、生成またはアニメーション化する前に、役割、ソース、スタイルの固定、セーフゾーン、モーションの目的、開始／終了タイミング、削除条件が定義されています。
• サポートアセットは、主要なテキスト、シンボル、製品、CTA と競合していません。
• 複数シーンの制作には、意味のあるシーン間のつなぎ、読み取れるホールド、モーション設計計画が含まれています。
• キネティックリレー制作には、キーワードの連鎖、アクションとオブジェクトの連鎖、方向マップ、リレーの連続性、中間地点のスナップショットが含まれ、スコアは 90 以上です。
• シーンスキーマ、ベクターテンプレート、モーションプリミティブのチェックを含む、デザインエンジニアリングの検証が実行されています。
• 合成された子要素では、変形、不透明度、クリッピング、オクルージョンの所有者が1つに統一されています。
• キャンバスの余白によって位置合わせが変わる場合、透過アセットの配置には、アルファが可視な範囲を使用しています。
• テキスト量の多いシーンやレイヤー構成のシーンでは、最終 MP4 から開始、読み取り可能なホールド、終了の各チェックポイントが抽出されています。
• 幅の狭いテキストコンテナは、エクスポートされたフォントの計測とレンダリング済みフレームのオーバーフローレビューに合格しています。
• タイポグラフィ、ビジュアルオブジェクト、画像の表示段階、モーションはすべて、抽出された本質を支えています。
• フェードアップの繰り返し、同じ中央揃えレイアウト、何もない黒い間、汎用アイコンの乱雑な配置、入れ替え可能な壁紙のような背景を避けています。
• タイミングは決定論的で、HyperFrames の検証または利用可能な最善の代替手段が実行されています。
• ヒーローフレームのスナップショットとレビュー結果が存在するか、阻害要因が報告されています。
• ユーザーから報告されたビジュアル上の不具合はすべて、根本原因、変更した上流の成果物、再実行の証拠、スキル／テンプレート／バリデーターのルール更新が必要かどうかとともに記録されています。

最初のフレームにおけるビジュアルの中心チェック

最初の0〜2秒で、動画に意図が感じられるかどうかが決まります。縦型のプロモーション動画では、最初に読み取れる静止フレームと、最初に製品の価値を示す静止フレームを確認してください。

• 視覚的に最も目立つ要素を特定します。タイトルブロック、数字、カードの重なり、製品の画面、スクリーンショット、シンボル、CTA、ルートオブジェクトなどです。
• CSS上の中心だけでなく、視覚上の中心を確認します。まとまりとして認識される要素の中心を意図した軸に合わせるか、ずらす場合は絵コンテでその理由を説明します。
• 端との間隔を確認します。意図的なトランジションとして切り抜く場合を除き、重要なカード、スクリーンショット、製品の端、ラベル、CTAが見切れてはいけません。
• ブラウザーのスナップショットだけでなく、実際にレンダリングされたMP4の静止フレームを確認します。レンダリング時のスケール、変形、遠近感によって、切り抜きの問題が明らかになることがあります。
• ヒーロー要素を意図的に中心からずらす場合は、バランスを取るカウンターウェイトを記録します。タイトル、シンボル、光、カード、ネガティブスペース、動きの方向などです。

安定性に関する必須ルール

以下は使用しないでください。

• Date.now() など、レンダリングに影響する動きのための実時間のアニメーション状態。
• レンダリングに影響するビジュアルでの、シードを指定していない Math.random()。
• メインアニメーションのタイミングを決める手段としての setTimeout、setInterval、requestAnimationFrame。
• コアタイムラインの非同期な構築。
• 必須アセットのレンダリング時のネットワークリクエスト。
• 手動での video.play()、video.pause()、または制御されていないメディア時間の変更。
• レンダリングタイムラインでの無限のアニメーションループ。

シード付きの乱数、固定の長さ、固定のfps、固定の寸法、ローカルアセット、明示的なタイムライン位置を使用してください。ブリーフに別の出力サイズが記載されていない場合、新しい動画のデフォルトの寸法は、9:16の縦型出力向けの 1080x1920 です。

参考資料

• 制作ワークフロー全体については、references/workflow.md を読んでください。
• 生成背景セット、コンポーネントシート、透明な切り抜き、アセットマニフェスト、画像アセットの検証を計画する場合は、references/imagegen-asset-pipeline.md を読んでください。
• 提供されたスタイル参考資料を使用する場合、アセットの役割の網羅性を承認する場合、コンポーネントの組み合わせをテストする場合、透明アセットの位置を合わせる場合、またはレンダリングされたMP4のフレームを検証する場合は、references/asset-choreography-and-render-qa.md を読んでください。
• スタイル、タイポグラフィ、レイアウト、動きを評価する場合は、references/visual-standard.md を読んでください。
• レイアウト契約、テキスト矩形、被写体矩形、タイトル階層、切り抜き安全領域、モバイル向けセーフエリアを計画する場合は、references/text-over-background-layout.md を読んでください。
• キネティックタイポグラフィ、CSS3/SVGの構造、GSAPによる振り付け、シーン遷移、PowerPoint風の表現を避ける改善を計画する場合は、references/motion-craft.md を読んでください。
• シーンスキーマ、SVGテンプレートライブラリ、モーションプリミティブカタログ、選択ルール、ブラウザーでの検証、バッチテンプレートモードを計画する場合は、references/design-engineering.md を読んでください。
• GSAPタイムライン、プラグインの登録、SplitText、DrawSVG、MorphSVG、MotionPath、CustomEase、位置パラメーター、パフォーマンスを計画する場合は、references/gsap-choreography.md を読んでください。
• 音楽、ナレーション、字幕にタイミングを合わせる場合は、references/audio-sync.md を読んでください。
• レンダリング動作を実装またはデバッグする前に、references/hyperframes-stability.md を読んでください。

テンプレート

制作成果物には、templates/ 内のテンプレートを使用してください。

• BRIEF_DESIGN_PROPOSAL.template.md
• DESIGN.template.md
• STORYBOARD.template.md
• REVIEW_REPORT.template.md
• SCENE_SCHEMA.template.json
• VECTOR_TEMPLATES.template.json
• MOTION_PRIMITIVES.template.json
• ASSET_MANIFEST.template.json

任意のテンプレート：

• BEAT_MAP.template.json
• MOTION_MAP.template.json

ローカルスキルチェック

このスキルには、決定論的なユーティリティスクリプトが含まれています。

node scripts/check-structure.mjs
node scripts/create_project.mjs <target-dir>
node scripts/check_assets.mjs <project-dir>
node scripts/validate_image_assets.mjs <project-dir>
node scripts/validate_artifacts.mjs <project-dir>
node scripts/validate_design_engineering.mjs <project-dir>
node scripts/build_review_pack.mjs <project-dir>

check-structure.mjs はスキルパッケージをチェックします。ほかのスクリプトは、プロジェクトのひな形作成、ローカルアセットのチェック、成果物の完全性検証、デザインエンジニアリング契約の検証、任意のレビューパック生成に役立ちます。これらのスクリプトでビジュアル品質が保証されるわけではありません。検出できるのは、ワークフロー、構造、再現性に関する問題のみです。