overdrive

Start your response with:

──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...

従来の限界を超えるインターフェースを作りましょう。これは単なる視覚効果の話ではありません。ブラウザーの力を最大限に活用して、インターフェースのあらゆる部分を特別な体験にすることです。たとえば、100 万行を処理するテーブル、トリガーから変形するダイアログ、ストリーミング形式のフィードバックでリアルタイムに検証するフォーム、映画のようなページ遷移などです。

必須の事前準備

/impeccable を呼び出してください。デザイン原則、アンチパターン、コンテキスト収集プロトコルが含まれています。先に進む前にこのプロトコルに従ってください。デザインコンテキストがまだない場合は、必ず最初に /impeccable teach を実行してください。

このスキルでは特に重要です：何を「特別」とするかはコンテキストによって決まります。クリエイティブなポートフォリオにパーティクルシステムを取り入れるのは印象的です。同じパーティクルシステムを設定ページに取り入れると、場違いで恥ずかしいものになります。しかし、瞬時に反映される楽観的な保存と、アニメーション付きの状態遷移を備えた設定ページもまた、特別な体験になります。何が適切かを判断する前に、プロジェクトの個性と目標を理解してください。

実装の前に提案する

このスキルは、判断を誤るリスクが最も高いものです。実装にいきなり取りかかってはいけません。必ず次の手順に従ってください。

1. 異なる方向性を 2～3 案検討する — 技術、野心の度合い、美的アプローチの違いを考慮します。それぞれの案について、仕上がりの見た目や使い心地を簡潔に説明してください。
2. 推測できない点は、ユーザーに直接確認してください。 これらの案を提示し、コードを書く前にユーザーに選んでもらいます。ブラウザーの対応状況、パフォーマンスへの影響、複雑さなどのトレードオフも説明してください。
3. ユーザーが確認した方向性に沿ってのみ、作業を進めてください。

この手順を省くと、作り直しが必要になるような、見ていられないものを作ってしまうリスクがあります。

ブラウザー自動化で反復する

技術的に野心的な効果は、最初からうまくいくことはほとんどありません。ブラウザー自動化ツールを積極的に使って作業をプレビューし、見た目を確認して、改善を繰り返してください。効果が適切に見えると決めつけず、実際に確認してください。何度も調整を繰り返すことを想定してください。「技術的に動く」状態から「特別な見た目」への隔たりを埋めるのは、コードだけではなく、視覚的な反復です。

---

ここでの「特別」の意味を見極める

適切な技術的な挑戦の度合いは、何を作っているかによってまったく異なります。手法を選ぶ前に、次のことを考えてください。この特定のインターフェースを使うユーザーが「すごくいい」と感じるのは、どんな体験でしょうか？

ビジュアル／マーケティング向けの画面

ページ、ヒーローセクション、ランディングページ、ポートフォリオなどでは、「すごさ」は感覚に訴えるものになることがよくあります。スクロールに連動する表示、シェーダー背景、映画のようなページ遷移、カーソルに反応するジェネレーティブアートなどです。

機能的な UI

テーブル、フォーム、ダイアログ、ナビゲーションなどでは、「すごさ」は使い心地にあります。View Transitions によって、トリガーになったボタンから変形して現れるダイアログ、仮想スクロールによって 60 fps で 10 万行を描画するデータテーブル、即時性を感じられるストリーミング検証付きフォーム、スプリング物理を使ったドラッグ＆ドロップなどです。

パフォーマンスが重要な UI

「すごさ」は目には見えなくても、使えば感じられます。5 万件の項目をちらつかずに絞り込む検索、メインスレッドを決してブロックしない複雑なフォーム、ほぼリアルタイムで処理する画像エディターなどです。インターフェースが決して遅れないことが重要です。

データ量の多いインターフェース

チャートやダッシュボードでは、「すごさ」は滑らかさにあります。大規模なデータセットを Canvas/WebGL で GPU アクセラレーション描画すること、データ状態間をアニメーションで遷移させること、自然に落ち着く力学ベースのグラフレイアウトなどです。

共通する点：実装のどこかが、ユーザーのウェブインターフェースに対する期待を超えています。手法は体験を支えるものであり、その逆ではありません。

ツールキット

テクノロジー名ではなく、実現したいことを基準に分類しています。

画面遷移を映画のように演出する

• View Transitions API（同一ドキュメント内：すべてのブラウザー、ドキュメント間：Firefox は非対応）— 状態間で共有要素をモーフィングします。リスト項目を詳細ページに展開したり、ボタンをダイアログに変化させたりできます。ネイティブの FLIP アニメーションに最も近い機能です。
• @starting-style（すべてのブラウザー）— CSS のみで、表示状態を display: none から表示に切り替える際のアニメーションを実現します。開始時のキーフレームも指定できます。
• スプリング物理 — cubic-bezier の代わりに、質量、張力、減衰を使って自然な動きを実現します。ライブラリ：motion（旧 Framer Motion）、GSAP、または独自のスプリングソルバー。

アニメーションをスクロール位置に連動させる

• スクロール駆動アニメーション（animation-timeline: scroll()）— JavaScript 不要の CSS のみで実現できます。視差効果、プログレスバー、順次表示など、すべてをスクロール位置に連動させられます。（Chrome／Edge／Safari、Firefox：フラグのみ — 必ず静的なフォールバックを用意してください）

CSS の枠を超えて描画する

• WebGL（すべてのブラウザー）— シェーダー効果、ポストプロセッシング、パーティクルシステムを実現します。ライブラリ：Three.js、OGL（軽量）、regl。CSS では表現できない効果に使用してください。
• WebGPU（Chrome／Edge、Safari は一部対応、Firefox：フラグのみ）— 次世代の GPU コンピューティングです。WebGL より高機能ですが、ブラウザーの対応は限られています。必ず WebGL2 にフォールバックしてください。
• Canvas 2D／OffscreenCanvas — カスタム描画、ピクセル操作、または Web Workers と OffscreenCanvas を使って重い描画処理をメインスレッドから完全に移動します。
• SVG フィルターチェーン — 変位マップ、乱流、形態学的処理によって、有機的な歪み効果を実現します。CSS でアニメーション可能です。

データに命を吹き込む

• 仮想スクロール — 数万件の項目があるテーブルやリストでは、表示領域内の行だけを描画します。単純なケースではライブラリは不要です。複雑なケースでは TanStack Virtual を使用します。
• GPU アクセラレーション対応のチャート — SVG／DOM では扱いきれない大規模データセットの可視化には、Canvas または WebGL で描画します。ライブラリ：deck.gl、regl ベースのカスタムレンダラー。
• アニメーション付きデータ遷移 — チャートの状態を置き換えるのではなく、モーフィングします。D3 の transition()、または DOM ベースのチャートには View Transitions を使用します。

複雑なプロパティをアニメーションさせる

• @property（すべてのブラウザー）— 型を指定したカスタム CSS プロパティを登録し、通常は CSS で補間できないグラデーション、色、複雑な値をアニメーション可能にします。
• Web Animations API（すべてのブラウザー）— CSS と同等のパフォーマンスで、JavaScript からアニメーションを制御します。組み合わせ、キャンセル、反転が可能です。複雑な振り付けの基盤となります。

パフォーマンスの限界に挑む

• Web Workers — 計算処理をメインスレッドから移動します。負荷の高いデータ処理、画像操作、検索インデックス作成など、カクつきの原因となる処理に使用します。
• OffscreenCanvas — Worker スレッドで描画します。複雑なビジュアルをバックグラウンドで描画しながら、メインスレッドを空けておけます。
• WASM — 計算負荷の高い機能で、ネイティブに近いパフォーマンスを実現します。画像処理、物理シミュレーション、コーデックなどに使用します。

デバイスと連携する

• Web Audio API — 空間オーディオ、音声連動型のビジュアライゼーション、音によるフィードバックを実現します。開始にはユーザー操作が必要です。
• デバイス API — 方向、周囲の明るさ、位置情報にアクセスします。使用は必要最小限にとどめ、必ずユーザーの許可を得てください。

注：このスキルの目的は、インターフェースの「使い心地」を高めることであり、製品の「機能」を変えることではありません。リアルタイムコラボレーション、オフライン対応、新しいバックエンド機能の追加は製品上の判断であり、UI の拡張ではありません。既存の機能を特別な使い心地にすることに注力してください。

規律をもって実装する

プログレッシブエンハンスメントは必須です

すべての技術で、機能が利用できない場合も適切に動作するようにしてください。拡張機能がなくても、優れた体験を提供できなければなりません。

@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}

if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* CSS-only fallback must still look good */

パフォーマンスのルール

• 60fps を目標にします。50fps を下回る場合は、簡素化してください。
• 常に prefers-reduced-motion を尊重してください。美しい静的な代替手段を用意してください。
• WebGL コンテキストや WASM モジュールなど、負荷の高いリソースはビューポートに近づいたときにのみ遅延初期化します。
• 画面外の描画は一時停止します。見えないものは停止してください。
• 開発マシンだけでなく、実際のミドルレンジデバイスでテストしてください。

洗練こそが違いを生みます

「すごい」と「並外れている」の差は、最後の20％の磨き込みにあります。スプリングアニメーションのイージングカーブ、段階的に表示する演出のタイミングオフセット、トランジションに物理的な感覚を与える繊細な二次モーション。動く最初のバージョンで公開するのではなく、そうなるのが必然だと感じられるバージョンを公開しましょう。

絶対にしてはいけないこと：

• prefers-reduced-motion を無視すること。これはアクセシビリティ要件であり、単なる提案ではありません
• ミドルレンジのデバイスでカクつきを引き起こすエフェクトを公開すること
• 実用的なフォールバックなしに最先端のAPIを使うこと
• ユーザーの明示的なオプトインなしに音を追加すること
• 技術的な野心でデザインの基本的な弱点を覆い隠すこと。まずはほかのスキルを使って弱点を解消しましょう
• 互いに競合する並外れた演出を重ねること。集中がインパクトを生み、過剰さはノイズを生みます

結果を検証する

• 驚きのテスト：まだ見たことのない人に見せてみましょう。反応がありますか？
• 取り除くテスト：それを取り除いてみましょう。体験が損なわれたと感じますか、それとも誰も気づきませんか？
• デバイスのテスト：スマートフォン、タブレット、Chromebookで動かしてみましょう。それでもスムーズですか？
• アクセシビリティのテスト：動きを抑える設定を有効にしてみましょう。それでも美しいですか？
• 文脈のテスト：これはこのブランドとオーディエンスに合っていますか？

「技術的に並外れている」とは、最新のAPIを使うことではありません。ウェブサイトではできないと思っていたことを、ユーザーがインターフェースで体験できるようにすることです。