シネマティック3Dウェブシーン は何をしますか?
人がアニメーションを説明するときは感情的な言葉を使います(「エピック」「スムーズ」「飲み込まれる」「まるで映画のように」)。 コードには正確な決定が必要です:画面に何が映るか、カメラの位置、何が動くか、速度、イージングの種類、照明の仕方、スクロールの各ポイントでテキストがどう振る舞うか。 これらの決定を推測に委ねると、技術的には正しくても「本人が思い描いたもの」にはならず、修正のたびにコストが膨らみます。
このスキルは2つのステップでそのギャップを埋めます:構築前に直接確認する(説明を正確で確定済みのシーン仕様に変換する)と実績のある基盤で構築する(仕様を確実に実装し、スムーズなスクロールを実現するアーキテクチャとテクニックライブラリを使う)です。
あらゆるシーンに機能します — バンドルされたポートフォリオ内のシーン(開くラップトップ、軌道を描くスキルアトム、発火して燃えるロゴ、ブラックホールトンネル)は方法論の実例であり、選択メニューではありません。
ファイル
references/scene-language.md 正確なモーション語彙 + 曖昧な言葉を具体化するための翻訳
references/scene-spec.md シーン仕様 / ストーリーボードフォーマット(実例付き)
references/techniques.md 各エフェクトの構築方法(カメラ、シェーダー、パーティクル、テキスト…)
references/architecture.md ピンスクロールシーンパターン、タイムライン、パフォーマンス、注意点
references/house-style.md デフォルトのビジュアルスタイル、および参考資料からスタイルを拾う方法
references/effects.md テンプレートの完成済みシーンを分析 — コピーまたは学習用
references/portfolio.md テンプレートから完全なポートフォリオを構築する
references/content-guide.md テンプレートのコンテンツフィールド
references/portrait-rig.md テンプレートのリビングポートレートヒーロー
template/ 完全なNext.jsポートフォリオサイト(実例)
scripts/create-site.mjs 新しい単一ページサイトを作成(Next.js、ハウス背景、シーン準備済み)
scripts/new-scene.mjs 新しいピンシーンをスキャフォールディング(セクション + タイムライン、3Dキャンバス、--no-canvasでDOMのみ)
scripts/video-frames.mjs 参照動画からフレームを抽出しモーションを分析
scripts/create-portfolio.mjs ポートフォリオテンプレート全体を新しいフォルダにコピー
scripts/retheme.mjs テンプレートのアクセントカラーを変更
ワークフロー
1. 本人のイメージを理解する
リクエストから以下を読み取る:ページの目的、各シーンが見せるべきもの、雰囲気、参考資料(サイト、動画、画像、映画、ゲーム)、およびハードな制約(既存サイト、フレームワーク、ブランドカラー)。
参考資料が与えられた場合は、何よりも先にそれを調査する — どんな説明よりも多くの情報を含んでいる。画像:観察する。動画:scripts/video-frames.mjs を実行し、フレームを順に確認する(下記「参照動画の読み方」参照)。ウェブサイト:開ける場合はスクロールし、間隔を置いてスクリーンショットを撮る。スタイル(色、光、タイポグラフィ、背景の動き)と振付(何がいつ動くか)は別々にメモする — 通常、人は参考資料からどちらか一方を欲しがるため、不明な場合はどちらかを尋ねる。
2. シーン仕様に変換する
references/scene-language.md を読み、references/scene-spec.md のフォーマットで仕様を書く。各シーンについて:1文でのアイデア、オブジェクト、ハウススタイルまたは選択したルック、そしてビートシート — スクロールの各範囲(0〜15%、15〜40%…)で画面に何が映るか、カメラの動き、モーション(動詞 + イージング + 時間)、ライト/色の変化、エフェクト(パーティクル、歪み、グロー)、テキストの動作。
曖昧な言葉はここで解決し、コードには持ち込まない。「吸い込まれる」は次のように変換する:タイトルの文字が画面中央に向かって螺旋状に移動し、各文字はボルテックスの端に達した時点で開始、150°回転しながら15%に縮小、6pxにぼかし、スクロールの10%の範囲で完了;背景は同じ範囲で中央に向かって歪む。ある言葉が2つの全く異なる意味を持ちうる場合は、2つの具体的な解釈を提示し、より可能性の高い方をデフォルトとして選ぶ。
3. 構築前に確認する
仕様を相手に見せる — 読むのに1分もかからず、数時間の手戻りを防げる。特にペーシング(速すぎ / 遅すぎ)と各シーンの重要な瞬間について、本人が思い描いていたものと違う部分を修正するよう依頼する。メッセージは短く:ビートシートと2〜3の絞った質問をデフォルトの回答と共に提示し、「はい、進めて」と答えられるようにする。
質問できない場合(単発または自動リクエスト)は、デフォルトのまま進め、最終メッセージに仕様を含めて本人が後で正確に指示を出せるようにする。
4. レイヤーごとに構築する
コードを書く前に references/architecture.md を読み、最初の「そもそもWebGLが必要か?」のテーブルを確認する。そして仕様内の各エフェクトについて references/techniques.md を読む。
コードの置き場所:
- 新規サイト(ランディングページ、商品ページ、任意の単一ページ):
node <skill-dir>/scripts/create-site.mjs <フォルダ>でハウス背景、フォント、リンター設定済みのNext.jsプロジェクトを作成する。シーンを追加する。 - 既存サイト:既存プロジェクト内で作業し、最初に
architecture.mdの「既存サイト内での作業」を読む。 - 完全なポートフォリオ:テンプレートから始める(
references/portfolio.md参照)。
その後、各シーンを以下の順序で構築し、各レイヤーを確認する:
- ブロックアウト — ピン留めセクション、ビートごとに1つのスロットを持つスクロールタイムライン、プレースホルダー形状、カメラパス。
scripts/new-scene.mjs <プロジェクト> <名前> --beats Nでこのスケルトンを生成する。既にワイヤリング済み(スクロール進行 → 共有タイムライン → 3DカメラとDOMキャプション、モーション軽減フォールバック、画面外では停止)。DOMのみのエフェクトには--no-canvasを追加する。スクロールして確認:ビートの順序とペースは正しいか? - モーション — 実際の動きとトランジション。仕様通りのイージングと持続時間。タイミングは人が最も反応する要素であり、見た目を整える前に正しくする。
- ルック — マテリアル、ライト、色、グロー、パーティクル、背景、タイポグラフィ。
- ポリッシュ — ポインターフォロー、アイドル時の微動、小さな二次モーション、モバイルフレーミング、モーション軽減。
ビルドと並行して npm run lint を実行する — Reactルールがフレームごとのミューテーションのミスをバグになる前にキャッチする。
5. 仕様と照合する
ビルド(npm run build)し、実行して、各ビートをそのスクロール位置でスクリーンショットする。各スクリーンショットをビートシートと1行ずつ比較する:そのオブジェクトは存在するか、カメラフレームは記述通りか、テキストは表示されているか、色は正しいか?一致しないものを修正してから見せる。スクロール後1秒待ってからスクリーンショットを撮る — シーンはイージングで配置される。また、スマートフォンサイズのビューポート(375×812)とモーション軽減も確認する。ブラウザツールがない場合は、シーンは構築したが未確認であることを率直に述べ、確認すべき項目をリストアップする。
6. 正確な言葉で洗練する
相手が反応したとき(「安っぽい」「やりすぎ」「ドラマチックじゃない」)、scene-language.md を使って元のリクエストと同じようにフィードバックを翻訳し、具体的な変更を提案し(「ダイブのタイミングをスクロールの8%から14%に遅らせ、0.3秒のホールドを追加」)、実行する。相手が確信が持てない場合は一度に1つだけ変更し、何が効果的だったかわかるようにする。
参照動画の読み方
node <skill-dir>/scripts/video-frames.mjs <動画> --every 0.25 --out frames/
ffmpeg が必要です(不足時はスクリプトがインストール方法を説明します)。フレームを順に確認し、時間の区間ごとに以下を書き留める:画面に何が映るか、何がどのように動いたか(方向、速度、イージング — 加速するか、オーバーシュートするか、落ち着くか?)、カメラ(静止、プッシュ、オービット、シェイク)、カット vs 連続移動、色と光。このリストがビートシートの初稿となる。速い瞬間については、その区間だけ --every 0.04 で再実行する(--from、--to を使用)。
非妥協事項
これらは実際の失敗から得られたものです;それぞれの理由は architecture.md にあります。
- すべてのシーンにモーション軽減版がある(静的レイアウトだが、すべてのコンテンツを表示する)。
- WebGLはクライアント側でのみ読み込まれ、そのセクションが画面外またはタブが非表示の場合は一時停止する。
- 3DとDOMのテキストは同じタイムライン関数を読み込むため、ずれることがない。
- ピン留めセクション内のスクロール連動値は、範囲配列ではなく関数変換を使用する。
- 擬似グロー(加算ハロー)を使用し、ポストプロセッシングブルームは使わない(ただし、本人がそのコストを受け入れた場合は除く)。
- ページのすべてのコンテンツはDOM内で実際の読み取り可能なテキストである — キャンバスだけに焼き付けてはいけない。
- コピー内で人物や製品に関する事実を決して捏造しない。デザインテキストは問題ないが、主張はダメ。与えられなかった価格、仕様、日付、統計、受賞歴は、可視の
[プレースホルダー]として入れる。 - 自動再生されるもの(ロード時のイントロなど)には可視のスキップコントロールがあり、すべてのシーンにはWebGLなしのフォールバック(ポスター画像または静的レイアウト)がある。
- 既存サイトでは、エフェクトに必要なものだけを変更し、何を動かしたかを明示する。
残すべきクレジット
テンプレートは原作者と、それが基盤とするオープンソース部品(React BitsのColorBendsとMagnet、dungyov.comのタイプペアリング)をクレジットしています。これらの部分を再利用する際はクレジットを残してください。