showcase

Start your response with:

──────────── ✨ SHOWCASE ─────────────
》》》 Entering showcase mode...

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

必須の準備

frontend-designを読み、Context Gathering Protocol に従ってください。利用できるコンテキストを再利用し、重要な情報が不足している場合にのみ質問してください。

タイミング、イージング、振り付け、動きを減らす設定に関する期待値については、モーションのリファレンスを確認してください。 説得力のある奥行き、レイヤー構成、状態遷移が意欲的なエフェクトに欠かせない場合は、エレベーションシステムを確認してください。 「特別な体験」が高コストな流行の盲目的な模倣に陥らず、プロダクトに即した具体的なものになるよう、AI スロップ検出を確認してください。

このスキルでは特に重要です：何が「特別」なのかは、コンテキストによって決まります。クリエイティブなポートフォリオにパーティクルシステムを使えば印象的です。同じパーティクルシステムを設定ページに使えば、場違いで見ていられません。一方、即座に楽観的保存を行い、状態遷移をアニメーションで表現する設定ページも、それだけで特別な体験になります。何が適切かを決める前に、プロジェクトの個性と目標を理解してください。

実装前に重要な選択を確定する

ユーザーがすでに選んでいる方向性を再利用してください。クリエイティブな方向性を任された場合は、適切なアプローチを選び、その範囲内で進めてください。

方向性がまだ決まっておらず、選択肢によって動作、アクセシビリティ、パフォーマンスコスト、スコープに大きな違いが生じる場合は、具体的な選択肢をいくつか提示し、不足している判断をユーザーに尋ねてください。その間も、独立して進められる準備は続けてください。ユーザーがすでに承認したことについて、再度承認を求めてはいけません。

ブラウザー自動化を使って反復する

技術的に意欲的なエフェクトは、ほとんどの場合、最初からうまくいくことはありません。ブラウザー自動化ツールを必ず積極的に使い、作業をプレビューして、見た目を確認し、反復してください。エフェクトが適切に見えると思い込まず、実際に確認してください。複数回の改良を想定してください。「技術的に動く」状態と「特別に見える」状態の差は、コードだけでなく、視覚的な反復によって埋められます。

---

ここでの「特別」とは何かを見極める

適切な技術的挑戦の方向性は、作業対象によってまったく異なります。手法を選ぶ前に、こう問いかけてください。この特定のインターフェースを使うユーザーが「わあ、これはいいね」と感じるのは、どんな体験でしょうか？

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

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

訪問者主導の構成、階層的なヒーローの準備、モバイル向けの構成、スクロール位置ごとの検証には、ランディングページのストーリーテリングを活用してください。メインのビジュアル演出をオファーと結びつけ、最後のアクションに確実にたどり着けるようにしてください。

機能的な UI の場合

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

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

「わあ」と思わせる要素は目には見えなくても、使うと実感できます。ちらつくことなく 5 万件の項目を絞り込む検索、メインスレッドを決してブロックしない複雑なフォーム、ほぼリアルタイムで処理を行う画像エディターなどです。インターフェースが一瞬たりともためらわないことが大切です。

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

チャートやダッシュボードでは、滑らかな動きが「すごさ」を生みます。膨大なデータセットを扱う、Canvas/WebGL による GPU 加速レンダリング、データの状態間をつなぐアニメーション付きトランジション、自然に落ち着くフォースディレクテッドグラフレイアウトなどです。

共通点：実装のどこかに、ユーザーがウェブインターフェースに期待する範囲を超える工夫があります。手法はエクスペリエンスを支えるものであり、その逆ではありません。

ツールキット

技術名ではなく、実現したいことを基準にまとめています。

トランジションを映画のように演出する

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

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

• スクロール駆動アニメーション（animation-timeline: scroll()） — スクロール位置に連動する Tailwind 互換のキーフレームです。視差効果、プログレスバー、リビールシーケンスを、追加の JavaScript なしで実行できます。（Chrome/Edge/Safari、Firefox：フラグ経由のみ — 必ず静的なフォールバックを用意してください）

Tailwind ユーティリティの表現力を超えるレンダリングを行う

• WebGL（すべてのブラウザー） — シェーダー効果、ポストプロセッシング、パーティクルシステムなどに使えます。ライブラリ：Three.js、OGL（軽量）、regl。Tailwind ユーティリティでは表現できない効果に使用します。
• WebGPU（Chrome/Edge、Safari は部分対応、Firefox：フラグ経由のみ） — 次世代の GPU コンピューティングです。WebGL より高機能ですが、ブラウザーの対応は限定的です。必ず WebGL2 にフォールバックしてください。
• Canvas 2D / OffscreenCanvas — カスタムレンダリングやピクセル操作、または Web Workers と OffscreenCanvas を使って負荷の高いレンダリングをメインスレッドから完全に移動する場合に使用します。
• SVG フィルターチェーン — ディスプレイスメントマップ、乱流、モルフォロジーで有機的な歪み効果を実現します。トリガーとレイアウトの制御には Tailwind ユーティリティを使用します。

データに躍動感を与える

• 仮想スクロール — 数万件のデータを含むテーブルやリストでは、表示範囲内の行だけをレンダリングします。シンプルなケースではライブラリは不要です。複雑なケースには TanStack Virtual を使用します。
• GPU 加速チャート — SVG/DOM では処理しきれない大規模データセットのデータ可視化を、Canvas または WebGL でレンダリングします。ライブラリ：deck.gl、regl ベースのカスタムレンダラー。
• アニメーション付きデータトランジション — チャートの状態を置き換えるのではなく、変形させます。D3 の transition() または DOM ベースのチャート向けの View Transitions を使用します。

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

• Tailwind 互換の @property トークン（すべてのブラウザー） — グラデーション、色、複雑な値のアニメーションなど、Tailwind ユーティリティでは直接表現できない高度な効果に限り、型付きテーマ変数を登録します。
• Web Animations API（すべてのブラウザー） — transform と opacity を効率的にアニメーションさせる、JavaScript 駆動のアニメーションです。合成、キャンセル、反転が可能です。複雑な振り付けを実現する基盤となります。

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

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

デバイスと連携する

• Web Audio API — 空間オーディオ、音声に反応するビジュアライゼーション、音によるフィードバックを実現します。開始するにはユーザーの操作が必要です。
• Device APIs — 画面の向き、周囲の明るさ、位置情報を取得します。使用は控えめにし、必ずユーザーの許可を得てください。

注記：このスキルの目的は、インターフェースの「体験」を高めることであり、プロダクトの「機能」を変えることではありません。リアルタイムコラボレーション、オフライン対応、新しいバックエンド機能の追加はプロダクト上の判断であり、UI の改善ではありません。既存の機能を格別な体験にすることに集中してください。

規律を持って実装する

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

あらゆる手法が、機能を段階的に落としても自然に動作する必要があります。機能強化がなくても、十分に良い体験を提供してください。

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

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

パフォーマンスのルール

• 60fps を目標にしてください。50fps を下回ったら、簡素化してください。
• prefers-reduced-motion を必ず尊重してください。美しい静的な代替表示を用意してください。
• 重いリソース（WebGL コンテキスト、WASM モジュール）は、ビューポートに近づいてから遅延初期化してください。
• 画面外のレンダリングは一時停止してください。見えないものは停止してください。
• 開発マシンだけでなく、実際のミドルレンジデバイスでもテストしてください。

仕上げが違いを生みます

「クール」と「格別」の差は、最後の 20％の仕上げにあります。スプリングアニメーションのイージング曲線、段階的な表示のタイミング調整、トランジションに物理的な感触を与えるさりげない二次モーションなどです。動作する最初のバージョンでリリースせず、必然性を感じさせるバージョンをリリースしてください。

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

• prefers-reduced-motion を無視すること — これは提案ではなく、アクセシビリティ要件です
• ミドルレンジデバイスでカクつきを引き起こすエフェクトをリリースすること
• 機能する代替手段なしに、最先端の API を使用すること
• ユーザーが明示的に許可する前に音を再生すること
• 技術的な野心でデザインの基本的な弱点を覆い隠すこと — まず他のスキルを使って解決してください
• 複数の格別な演出を重ねて競合させること — 集中はインパクトを生み、過剰さはノイズを生みます

結果を検証する

現在のキャプチャ、インタラクションの証拠、利用できないツールの制約については、ビジュアル検証に従ってください。承認済みの参照資料がある場合は、参照資料への忠実度を確認してください。利用できない場合に、2 人目のレビュアーや実機を必須にしないでください。

• 驚きのテスト：初めて見る人に見せて、反応がありますか？
• 削除テスト：それを取り除くと、体験は損なわれますか？ それとも誰も気づきませんか？
• デバイステスト：狭いブラウザー、中程度の幅のブラウザー、広い画面で精密なポインターを使えるブラウザーで実行しても、滑らかですか？
• アクセシビリティテスト：モーション低減を有効にしても、美しいままですか？
• コンテキストテスト：これはこのブランドとオーディエンスにふさわしいですか？

覚えておいてください。「技術的に格別」であることは、最新の API を使うことではありません。ウェブサイトではできないと思われていたことを、インターフェースで実現することです。