showcase

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

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

必須の事前準備

ユーザーは /showcase でこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。ここにはデザインの原則、アンチパターン、コンテキスト収集プロトコルが含まれています。先に進む前にこのプロトコルに従ってください。デザインのコンテキストがまだ存在しない場合は、必ず $setup を先に読み込んでください。

タイミング、イージング、演出、動きを減らす設定への配慮については、モーションのリファレンスを参照してください。 説得力のある奥行き、レイヤー構成、状態遷移が意欲的な効果の鍵となる場合は、エレベーションシステムを参照してください。 「特別な体験」が高コストな流行の盲目的な模倣に陥らず、製品に固有のものとなるよう、AI スロップ検出を参照してください。

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

実装前に提案する

このスキルは、意図を外す可能性が最も高いものです。すぐに実装を始めてはいけません。必ず次の手順を踏んでください。

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

この手順を省くと、恥ずかしい仕上がりになり、作り直しが必要になるおそれがあります。

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

技術的に意欲的な効果が一度でうまくいくことは、ほとんどありません。ブラウザー自動化ツールを必ず積極的に使い、仕上がりをプレビューして、見た目を確認し、改善を重ねてください。効果が正しく見えると決めつけず、実際に確認してください。何度も調整を繰り返すことを想定してください。「技術的には動く」状態と「特別な体験に見える」状態の差は、コードだけではなく、見た目を確認しながら反復することで埋まります。

---

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

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

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

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

機能的な UI

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

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

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

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

チャートやダッシュボードでは、滑らかさが「驚き」を生みます。大規模なデータセットを扱うためのCanvas/WebGLによるGPUアクセラレーションレンダリング、データ状態間のアニメーション付きトランジション、自然に落ち着く力指向グラフレイアウトなどです。

共通点：実装のどこかが、Webインターフェースに対するユーザーの期待を超えています。手法はエクスペリエンスを高めるためのものであり、その逆ではありません。

ツールキット

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

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

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

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

• スクロール駆動アニメーション（animation-timeline: scroll()） — JS不要の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を使うこと
• ユーザーが明示的に許可する前に音を追加すること
• デザインの基本的な弱点を技術的な野心で覆い隠すこと。まずはほかのスキルを活用して修正してください
• 並外れた演出をいくつも競合させること。集中がインパクトを生み、過剰さはノイズを生みます

結果を検証する

• 驚きのテスト：初めて見る人に見せてください。反応がありますか？
• 取り除くテスト：機能を取り除いてください。体験が損なわれたと感じますか、それとも誰も気づきませんか？
• 端末のテスト：幅の狭いブラウザー、中程度の幅のブラウザー、ノートパソコン／デスクトップのブラウザーで動かしてください。それでもスムーズですか？
• アクセシビリティのテスト：モーションの低減を有効にしてください。それでも美しいですか？
• コンテキストのテスト：このブランドとオーディエンスに合っていますか？

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