ai-ui-ux-motion-engine

AI UI/UX モーションエンジン

根拠に基づいて、プロジェクト固有の体験を作成します。リファレンスは構造、ビジュアル、インタラクションの入力として扱い、ブランド、コピー、コード、保護対象のアセットを模倣する許可とは見なしません。

妥協できないルール

• 編集する前に、該当する AGENTS.md、信頼できる情報源となるドキュメント、デザインシステム、現在の作業ツリーの変更を確認します。
• 対象範囲、受け入れ基準、依存関係、費用、検証計画を明確に定めます。
• 正確性の目標を満たせる最短の方法を使います。実際の製品では、信頼できる情報源がある場合は evidence-accurate を標準とし、見栄えを優先して正確性を黙って犠牲にしてはいけません。CAD、合成、実写映像が必要な場合は、早い段階で伝えます。
• ユーザーが明示的に変更を許可しない限り、既存のスタックを維持します。
• 観察事項、事実、提案、生成されたビジュアライゼーション、未知の事項を明確に区別します。
• モーション、JavaScript、無制限のデータ利用がなくても、コンテンツと操作を利用できるようにします。
• 直接的な根拠なしに、映画のような品質との同等性、製品の正確性、アクセシビリティ、パフォーマンス、リリース準備完了を主張してはいけません。
• ユーザーの許可なく、有料サービスを設定したり、プロバイダーの規約に同意したり、クレジットを消費したりしてはいけません。
• 要望された全画面、ホームページ、または看板となるシネマティックな体験を、補助的なショットに格下げしてはいけません。カメラの回転、ドリー、ズーム、パララックス、静止画像の表示は、看板となる体験ではありません。

必須のシネマティック演出意図ゲート

リクエストまたは参考資料から、次のいずれかが示唆される場合は、このゲートを有効にしてください。

• シネマティックで、プレミアム感や没入感のあるスクロール体験。
• 製品の登場、組み立て、爆発、破裂、変形。
• カメラのオービット、ドリー、マクロ撮影による詳細確認、または演出された製品のジャーニー。
• スクロールで制御される写真の動き。
• 視点やオブジェクトの状態変化が印象を生み出す参考資料。

ユーザーがトリガーワードを使ったり、必要なツールを把握していたりする必要はありません。

ページを編集する前に、次の手順を実行してください。

1. ユーザーが求める成果を intent.requestSummary にコピーし、印象的な瞬間、展開、見せ場、必要な効果、受け入れられない代替案を記録します。利用可能な素材のうち最も簡単なものに合わせて、リクエストを書き換えてはいけません。
2. 真実性モードを分類します。
   • illustrative：詳細を創作してもかまいません。
   • identity-locked：同一の架空製品またはコンセプト製品の一貫性を維持する必要があります。
   • evidence-accurate：見える数量、形状、ラベル、仕組みを、信頼できる製品資料に一致させる必要があります。
3. 参考資料または希望するシーン、利用可能な元画像やCAD、主役となる演出と補助的な演出の数および配置、対象デバイス、メディアプロバイダーへのアクセス、許可されたクレジット数／試行上限を確認します。参考資料が動画の場合は、利用可能なトランスクリプト、プロンプトパック、説明へのリンクに加えて、主要なキーフレームも確認してください。要約や単独のスクリーンショットだけをもとに、その制作ワークフローを再構成してはいけません。
4. 必要な依存関係を明確に説明します。写真のようなカメラ移動や物理的な変形には、適切な元素材に加えて、画像／動画生成、3D、またはコンポジットの手段が必要です。CSSで見えない製品の視点を作り出すことはできません。
5. 必要なプロバイダーまたは元素材を利用できない場合は、シネマティック素材の制作を中止します。静的なレイアウト／フォールバックを誠実に提示し、フェード、ズーム、ストックの背景動画を同等のものとして代用してはいけません。
6. assets/cinematic-brief.example.json をもとにシネマティックブリーフを作成し、scripts/validate-cinematic-brief.mjs で検証したうえで、生成前に費用と利用条件に関する承認を得ます。検証に失敗した場合は、アップロードも費用の支出も行ってはいけません。
7. ページを再設計したり、素材ライブラリ全体を生成したりする前に、印象的な瞬間だけを切り出した非公開のプルーフを1つ作成します。
8. 自動技術チェックと概要コンタクトシートを使って、意図からの逸脱を検出します。リスクのある遷移だけを高密度でサンプリングし、欠陥が検出された場合、または仕組みの正確さが重要な場合に限り、すべてのフレームを確認します。承認された試行回数を超えてはいけません。その後は動きを簡素化するか、手法を変えるか、阻害要因を報告してください。
9. assets/creative-acceptance.example.json をもとにクリエイティブレビュー用JSONを作成し、scripts/validate-creative-acceptance.mjs を実行します。メディアの技術検証に合格しても、物語性、インパクト、クリエイティブ面での承認が証明されるわけではありません。
10. クリエイティブバリデーターに --stage integration を指定して合格した後、オーナーが承認した素材だけを組み込みます。周囲のUIで補えるかを確かめるために、質の低いプルーフを実運用のヒーロー領域に配置してはいけません。

実行可能な主役素材ゲート

ユーザーが明示的に小規模な補助ショットを求めている場合を除き、全画面、ホームページ、ヒーロー、主役、没入型、複雑な、バースト、分解、または演出されたスクロールジャーニーのリクエストは flagship として扱います。有料の生成を実行する前に、次を実行してください。

node scripts/validate-cinematic-brief.mjs cinematic-brief.json --check-files
node scripts/render-cinematic-prompt.mjs cinematic-brief.json --mode flagship

バリデーターは、ティアの格下げ、カメラ移動だけのストーリー、冒頭／展開／見せ場の欠落、元素材の不足、要求された変形の欠落、未検証のプロバイダールートを拒否する必要があります。手動でプロンプトを作成して、この検証を回避してはいけません。

生成後、視覚的な証拠を記録し、次を実行してください。

node scripts/validate-creative-acceptance.mjs creative-review.json --stage review

オーナーが該当する非公開プルーフを承認した後に限り、--stage integration を使用してください。コーデック、キーフレーム、コンタクトシート、スクロール配信のチェックに合格したことを、クリエイティブブリーフへの合格の証拠として扱ってはいけません。

プログラムによるプロバイダー利用のルール

ブラウザー制御よりも、構造化されたプロバイダーアクセスを優先してください。Codex で Higgsfield を使う場合：

1. 認証済みの Higgsfield CLI を優先します。
2. コネクターをネイティブに公開するクライアントでは、Higgsfield MCP を使用します。
3. アカウントで利用できる場合は、サポートされている API を使用します。
4. すべてのプログラム経由の手段で利用できない、必須の操作を行う場合に限りブラウザー制御を使用し、その正確な制限を概要に記録します。

Higgsfield で生成する前に、scripts/higgsfield-preflight.mjs を実行してください。これはクレジットを消費せずに、CLI アカウントの接続を確認します。プロバイダーを利用する前に、tool-connections.md を最後まで読んでください。

最初の応答は簡潔にしてください。求める精度、ソースの準備状況、プロバイダーの利用権限と支出権限、希望する配置、納期または作業時間の予算を確認します。スキルで判断できる実装の詳細について、ユーザーに選択を求めないでください。

「初回」とは、適切なプロフェッショナル向けの進め方を選び、範囲を限定した実証をすぐに行うことを意味します。確率的なプロバイダーによる初回のレンダリングが必ず合格することを保証するものではありません。

必要な情報が不足している場合は、最初の応答を短くしてください。

この体験には、一般的な CSS ではなく、シネマティックなソースモーションが必要です。承認済みのメディアプロバイダーと適切なリファレンスがあれば制作できますが、まず必要な精度、主要なシーン／配置、ソース素材、プロバイダーへのアクセス、クレジット上限を確認する必要があります。ページを変更する前に、非公開のシグネチャーシーケンスを 1 つ実証します。基本的な写真の表示演出で代用することはありません。

このゲートが有効になった場合は、cinematic-intake.md、generated-product-scrubber.md、cinematic-prompts.md を最後まで読んでください。

標準ワークフロー

1. 要件とベースラインを確認する

目標、対象ユーザー、ルート、コンテンツ／エビデンスのルール、対象デバイス、フレームワーク、リリース範囲、現在のビルド／テスト状況を記録します。workflow.md を読んでください。

2. リファレンスを抽出する

構図、タイポグラフィ、色、画像、出現方法、スクロール、ホバー、ドラッグ、カメラの動き、オブジェクトの状態、タイミングを把握します。再利用できる原則と、アイデンティティに固有の素材を区別してください。ローカル録画を実行する場合：

bash scripts/extract-reference-frames.sh <video> <output-directory>

media-pipeline.md を読んでください。

3. 方向性を 1 つに絞る

目標／対象ユーザー、トーン、構図、タイポグラフィ、色／メディア、モーション／モーション低減、特徴的な差別化要素を含む、実装可能な 7 行を作成します。「すっきりしていてモダン」だけでは先に進まないでください。

4. アーキテクチャを選択する

意図する体験を保てる、最も軽量な仕組みを選びます。

• ローカル状態や出現時の変化には CSS。
• シンプルな表示演出には Intersection Observer またはネイティブのスクロールアニメーション。
• コンポーネントの連動したモーションには既存のモーションライブラリ。
• 意図的なピン留めやタイムラインには GSAP。
• 写真のようなカメラ／オブジェクトの変化には生成メディアまたは撮影素材。
• 正確なスクロールスクラブにはオールイントラ動画または Canvas フレーム。
• 自由に操作できる視点や、正確で信頼性の高いメカニクスには WebGL／3D。

シネマティックな製品モーションでは、メディアそのものが体験です。まずメディアを実証してください。足りない映像を CSS トランスフォームで作り出せると期待しないでください。

拡張しやすく、無駄のない標準構成を使います。

• 主要なユーザージャーニーごとに、フラッグシップとなる映像を 1 つ用意する。
• 承認済みのチャプター、クロップ、自然な逆再生を、内容の正確さを保てる場合に再利用する。
• 新たな事実を実際に伝える場合に限り、3～5 秒の補助ショットを追加する。
• それ以外の箇所では、コードネイティブのモーションを使う。

ソースとプロバイダーの準備が整っている場合、非公開の実証には 15～30 分、承認済みのフラッグシップ映像とスクロール実装には 30～60 分、派生物または補助的な組み込みには 5～10 分を目標とします。新規または一貫性のないソース一式、エビデンス上重要なメカニクス、CAD、コンポジット作業に限り、75～120 分を見込んでください。これらは目標であり、保証ではありません。時間の上限を超えた場合は、エビデンスを報告し、続行する前に承認を得てください。

5. 範囲を区切って実装する

セマンティックなコンテンツ、大枠のレイアウト、承認済みのシグネチャーモーション、マイクロステート、レスポンシブな構成、編集上の仕上げを構築します。テキスト、ラベル、アクションは生成メディアに焼き込まず、DOM 内に保持してください。

プロセスの肥大化を防ぎます。ページの作業に入る前にメディアを検証し、プロバイダーとソースの調査は実行ごとに一度だけ行います。検証前に複数の再設計やドキュメント作成の工程を重ねず、最初に対象コンポーネントのテストを実行し、最終統合後に回帰テスト全体を一度だけ実行します。技術的な証拠は自動で記録してください。

クライアント／モデルがサブエージェントに対応している場合、2 つ以上の独立した作業ストリームがあり、委任によって時間を短縮できるときは、並列実行を標準とします。ソースの監査、プロバイダーの機能と最新コストの確認、ブリーフの検証、メディアの準備／QC、ブラウザーの確認、ドキュメント作成を並列化します。視覚的な解釈、真実性のモード、クリエイティブの方向性、費用、受け入れ判断は、能力の高いマルチモーダルモデルを使うリードに任せます。範囲を限定できる機械的な作業には、より高速で十分な能力を備えたモデルを使います。メディアを確認できないモデルに視覚的な QC を割り当てたり、複数のエージェントに同じファイルを同時に編集させたり、有料生成、承認、依存関係のある工程を並列化したりしないでください。判断の前に、作業結果を統合してください。

6. 検証する

各コンポーネントの実装後に、ポインター、キーボード、タッチ、モーション低減、対象ビューポート、コンソール／ランタイムの挙動、対象を絞ったチェックをテストします。シネマティックメディアについては、さらに、アイデンティティ／数／形状、最初と最後の状態、前後方向へのスクラブ、クロップ、フォールバックも検証します。その後、次を実行します。

node scripts/audit-motion-safety.mjs <project-directory>
node scripts/validate-scroll-media.mjs <shipping-scroll-master.mp4> \
  --poster <shipping-poster.jpg>
node scripts/validate-package.mjs

問題があれば出荷を中止します。メディアバリデーターが失敗する、最初のデコード済みフレームの後にポスターが再表示される、シークが重複する、方向をすばやく変えたときに古いフレームや空白フレームが表示される、ポスターのクロップやスケールが最初のデコード済みフレームと異なる、またはフィルムが静止画像のクロスフェードだけで構成されている場合は、スクラバーを出荷しないでください。ゲートをすべて通過するまでは、番号付きのキャンバスシーケンスまたは静的なフォールバックを使用してください。安定した 6 つのチェックポイントだけでは不十分です。

引き渡し前に、プロジェクトの回帰テスト全体を基準として実行してください。verification.mdをお読みください。

リソースの使い分け

• cinematic-intake.md：必須の質問、異議申し立て、ティア、費用、停止ルール。
• cinematic-prompts.md：再利用可能な単一アクション、フラッグシップ、例示用プロンプトの厳密な契約。
• generated-product-scrubber.md：シネマティック制作とスクロール配信のゴールデンパス。
• media-pipeline.md：参照資料、ffmpeg、オールイントラビデオ、フレーム、ポスター、配信。
• tool-connections.md：プロバイダーの事前確認と外部ツールの境界。
• motion-patterns.md：コードネイティブなモーション。
• framework-recipes.md：スタック固有の実装。
• accessibility-performance.md：モーションの安全性とパフォーマンス。
• prompts.md：ユーザー向けリクエストのテンプレート。
• source-coverage.md：出典情報と既知の制限。

再利用可能なアセットとスクリプト：

• assets/cinematic-brief.example.json
• assets/creative-acceptance.example.json
• assets/cinematic-scroll-controller.js
• scripts/validate-cinematic-brief.mjs
• scripts/validate-creative-acceptance.mjs
• scripts/higgsfield-preflight.mjs
• scripts/test-cinematic-regressions.mjs
• scripts/render-cinematic-prompt.mjs
• scripts/prepare-scroll-media.sh
• scripts/validate-scroll-media.mjs

完了レポート

選択した方向性、メディアのティア、真実性のモードを報告してください。参照資料／プロバイダー、モデル／設定、試行回数、クレジット、変更したファイル、QC とブラウザーの証拠、フォールバック、未解決の視覚的推定、非公開／ステージング／本番のリリース状況も報告してください。