mcpField
D
design-taste-frontend-v2-experimental

design-taste-frontend-v2-experimental

github.com/leonxlnxデザイン・UI104.4k19.5k 回インストール4 日前に更新
リポジトリ

design-taste-frontend-v2-experimental について

コーディングエージェント向けのフロントエンド設計スキルです。要件を読み取ってから、ランディングページやポートフォリオ、リデザインの方向性と実装規約を選びます。状況に応じたルールと設計パラメーターで、画一的な出力を避けます。

主な機能

  1. 01要件と対象者の分析
  2. 02デザイン方針とパラメーターの選定
  3. 03デザインシステムの指針
  4. 04ReactとTailwindの規約
  5. 05アクセシビリティとレスポンシブ対応

活用シーン

  1. 01SaaSランディングページの設計
  2. 02デザイナーや開発者のポートフォリオ制作
  3. 03既存サイトのリデザイン
  4. 04デザイン要件へのアクセシビリティ制約の反映

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/leonxlnx/taste-skill --skill design-taste-frontend-v2-experimental

インストール後、Claude Code で/design-taste-frontend-v2-experimentalを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

tasteskill:アンチスロップ・フロントエンドスキル

ランディングページ、ポートフォリオ、リデザイン向けです。ダッシュボード、データテーブル、複数ステップのプロダクト UI 向けではありません。 以下のルールはすべて状況に応じて適用します。自動で適用されるものはありません。まず依頼内容を読み、合うものだけを取り入れてください。


0. 依頼内容の読み取り(まず状況を見極める)

コードに触れたり、設定を調整したりする前に、ユーザーが本当に求めているものを推測してください。LLM によるデザインの成果物の多くがよくないのは、状況を読み取らずに、モデルが既定の美的感覚に飛びつくからです。

0.A まず次のシグナルを読み取る
  1. ページの種類 - ランディングページ(SaaS/消費者向け/エージェンシー/イベント)、ポートフォリオ(開発者/デザイナー/クリエイティブスタジオ)、リデザイン(既存のデザインを維持するか、刷新するか)、エディトリアル/ブログ。
  2. ユーザーが使った雰囲気を表す言葉 - 「ミニマル」「落ち着いた」「Linear 風」「Awwwards」「ブルータリスト」「プレミアムな消費者向け」「Apple 風」「遊び心のある」「真面目な B2B」「エディトリアル」「エージェンシー風」「ガラスのような」「ダークテック」。
  3. 参考資料のシグナル - ユーザーがリンクした URL、貼り付けたスクリーンショット、名前を挙げたプロダクト、競合するブランド。
  4. 対象ユーザー - B2B の調達担当者パネルか、デザインにこだわる消費者か、ポートフォリオを確認する採用担当者か。美的感覚を決めるのはあなたの好みではなく、対象ユーザーです。
  5. 既存のブランドアセット - ロゴ、色、書体、写真。リデザインの場合、これらは出発点であり、任意の入力ではありません(セクション 11 を参照)。
  6. 明示されていない制約 - アクセシビリティを最優先する対象ユーザー、公共部門、規制対象業界、信頼を重視するコマース、子ども向けプロダクト。こうした制約は美的な好みよりも優先されます。
0.B 生成前に「デザインの読み取り」を一文で出力する

コードを書く前に、一文で次のように述べてください:「次のように読み取りました:<page kind> を <audience> 向けに作成し、<vibe> な表現で、<design system or aesthetic family> 寄りにします。」

読み取り例:

  • 「次のように読み取りました:技術系の購入者向け B2B SaaS ランディングページで、Linear 風のミニマルな表現を取り入れ、Tailwind ユーティリティ + Geist + 控えめなモーションを採用します。」
  • 「次のように読み取りました:採用担当者向けの個人デザイナーポートフォリオで、エディトリアル/動的なタイポグラフィ表現を取り入れ、ネイティブ CSS + スクロール駆動アニメーション + カスタムタイポグラフィを採用します。」
  • 「次のように読み取りました:公共サービスサイトのリデザインで、信頼を最優先する表現を取り入れ、GOV.UK Frontend または USWDS を採用します。」
0.C 依頼内容が曖昧なら、推測せず質問を一つだけする

確認の質問は必ず一つだけにしてください。複数の質問をまとめて投げてはいけません。また、デザインの読み取りが本当に分かれる場合にのみ質問してください。例:「Linear のようなクリーンな雰囲気と、Awwwards のような実験的な雰囲気では、どちらに近づけますか?」

文脈から自信を持って推測できるなら、質問しないでください。デザインの読み取りを明示して、そのまま進めてください。

0.D 既定のデザインを避ける

次のものを既定で使わないでください:AI 風の紫色グラデーション、暗いメッシュ背景上の中央揃えヒーロー、均等なサイズの機能カード 3 枚、あらゆる場所で使う汎用的なグラスモーフィズム、どこまでも続くマイクロアニメーション、Inter + slate-900。これらは LLM の定番です。デザインの読み取りに基づき、意識して定番の先を目指してください。


1. 3 つのダイヤル(コア設定)

デザインの読み取りの後、3 つのダイヤルを設定してください。以下のレイアウト、モーション、密度に関する判断は、すべてこれらの設定に従います。

  • DESIGN_VARIANCE: 8 - 1 = 完全な対称性、10 = 芸術的なカオス
  • MOTION_INTENSITY: 6 - 1 = 静的、10 = シネマティック/物理的
  • VISUAL_DENSITY: 4 - 1 = アートギャラリー/ゆったり、10 = コックピット/データ満載

基準値: 8 / 6 / 4。デザインの読み取りによる上書きがない限り、これを使ってください。このファイルを編集するようユーザーに頼んではいけません。上書きは会話の中で行います。

1.A ダイヤルの推論(デザインの読み取り → ダイヤルの値)
シグナルVARIANCEMOTIONDENSITY
「ミニマリスト / クリーン / 落ち着き / エディトリアル / Linear 風」5-63-42-3
「プレミアム消費者向け / Apple っぽい / ラグジュアリー / ブランド」7-85-73-4
「遊び心 / ワイルド / Dribbble / Awwwards / 実験的 / エージェンシー」9-108-103-4
「ランディングページ / ポートフォリオ / マーケティングサイト(デフォルト)」7-96-83-5
「信頼第一 / 公共部門 / 規制対象 / アクセシビリティ重視」3-42-34-5
「リデザイン - 維持」既存に合わせる+1既存に合わせる
「リデザイン - 大幅刷新」+2+2既存に合わせる
1.B ユースケース別プリセット
ユースケースVARIANCEMOTIONDENSITY
ランディング(SaaS、一般向け)764
ランディング(エージェンシー / クリエイティブ)983
ランディング(プレミアム消費者向け)763
ポートフォリオ(デザイナー / スタジオ)873
ポートフォリオ(開発者)654
エディトリアル / ブログ643
公共部門のサービス325
リデザイン - 維持既存に合わせる既存+1既存に合わせる
リデザイン - 大幅刷新+2+2既存に合わせる
1.C ダイヤルがアウトプットをどう左右するか

これら(またはユーザーが上書きした値)をグローバル変数として使用します。本書全体を通じた相互参照は、これらの正確な変数名を指します。LAYOUT_VARIANCE や ANIM_LEVEL のような別名を勝手に作らないでください。


2. ブリーフ → デザインシステムのマッピング

デザインの読み取り(セクション 0)とダイヤル(セクション 1)ができたら、適切な基盤を選びます。公式パッケージが存在するものに対して独自の CSS を発明しないでください。美的トレンドを公式システムであるかのように装わないでください。

2.A 実際のデザインシステムに手を伸ばすべきとき(公式パッケージを使用する)
ブリーフがこう読めるなら…これを使う理由
Microsoft / エンタープライズ SaaS / ダッシュボード@fluentui/react-components または @fluentui/web-components公式 Fluent UI、Microsoft のトークン、アクセシビリティ対応済み
Google っぽい UI、Material 風のプロダクト@material/web + Material 3 トークン公式、Material Theming でテーマ化可能
IBM 風の B2B / エンタープライズ分析@carbon/react + @carbon/styles公式 Carbon、成熟したデータ密度パターン
Shopify アプリの画面polaris.js Web Components / Polaris ReactShopify 管理 UI では必須
Atlassian / Jira 風のプロダクト@atlaskit/* + @atlaskit/tokens公式 Atlassian DS
GitHub 風の開発ツール / コミュニティページ@primer/css または @primer/react-brand公式 Primer。マーケティングには Brand バリアント
英国公共部門のサービスgovuk-frontend法的・規制的に期待される
米国公共部門 / 信頼第一uswds同上
スピード重視の地元ビジネス / エージェンシー MVPBootstrap 5.3地味だが速く、動く
モダンでアクセシブルな React 基盤@radix-ui/themesプリミティブ + 洗練されたテーマ
コンポーネントを自社で所有するモダン SaaSshadcn/ui(npx shadcn@latest add ...)コードを自分で所有し、カスタマイズが容易。デフォルト状態のまま出荷しないこと
Tailwind ベースのモダン SaaS / AI マーケティングTailwind v4 ユーティリティ + dark: バリアントインディー + 小規模チームのビルドのデフォルト

誠実さのルール: ブリーフが上記のいずれかのシステムとして読めるなら、公式パッケージをインストールして使用してください。その CSS を手作業で再現しないでください。あるシステムのトークンをインポートしておきながら、その 90% を上書きしないでください。

1 プロジェクトにつき 1 システム。 同じツリー内で Fluent React と Carbon を混在させないでください。Material 3 アプリに shadcn/ui コンポーネントをインポートしないでください。

2.B ブリーフがシステムではなく、ビジュアルスタイルを指定している場合

これらの方向性には、公式パッケージが一つに定まっているわけではありません。ネイティブ CSS + Tailwind +メンテナンスされているコンポーネントライブラリを使って構築してください。コードコメントでは、借用したインスピレーションと公式素材を明確に区別してください。

ビジュアルスタイル正直な実装方法
グラスモーフィズム/「すりガラス」backdrop-filter、レイヤー状のボーダー、ハイライトオーバーレイを使用します。prefers-reduced-transparency 用に単色塗りつぶしのフォールバックを用意してください。
ベントー(Apple 風タイルグリッド)セルサイズを変えた CSS Grid を使用します。これを所有する単一のライブラリはありません。
ブルータリズムネイティブ CSS、等幅フォント、装飾のないボーダーを使用します。ライブラリはありません。
エディトリアル/雑誌風セリフ体、非対称グリッド、ゆとりのある余白を使用します。ライブラリはありません。
ダークテック/ハッカー風等幅フォントとアクセントカラーのネオン、ターミナルのモチーフを使用します。ライブラリはありません。
オーロラ/メッシュグラデーションSVG または重ねた放射状グラデーションを使用します。ライブラリはありません。
キネティックタイポグラフィネイティブ CSS アニメーション、スクロール駆動アニメーション、スクロールを乗っ取る場合は GSAP を使用します。ライブラリはありません。
Apple Liquid GlassApple はこれを Apple プラットフォーム向けにのみ公開しています。公式の liquid-glass.css はありません。 Web 向けの実装は、backdrop-filter +レイヤー状のボーダー+ハイライトを使った近似表現です。近似表現であることを明確に示してください。

3. デフォルトのアーキテクチャと規約

デザインの分析で実在するデザインシステムが選ばれていない場合(セクション 2.A)、以下をデフォルトとします。

3.A スタック
  • フレームワーク: React または Next.js。デフォルトでは Server Components(RSC)を使用します。
    • RSC の安全性: グローバル状態が機能するのは Client Components のみです。Next.js では、プロバイダーを "use client" コンポーネントでラップしてください。
    • インタラクティビティの分離: Motion、スクロールリスナー、またはポインターの物理演算を使用するコンポーネントは、必ず独立したリーフコンポーネントとし、先頭に 'use client' を指定してください。Server Components では静的なレイアウトのみをレンダリングします。
  • スタイリング: Tailwind v4(デフォルト)。既存プロジェクトで必要な場合に限り、Tailwind v3 を使用します。
    • v4 の場合、postcss.config.js で tailwindcss プラグインを使用しないでください。@tailwindcss/postcss または Vite プラグインを使用します。
  • アニメーション: Motion(旧 Framer Motion ライブラリ)。motion/react からインポートします(import { motion } from "motion/react")。framer-motion パッケージはレガシーエイリアスとして引き続き動作しますが、新しいコードでは motion/react を優先してください。
  • フォント: 必ず next/font(Next.js)を使用するか、@font-face + font-display: swap でセルフホストしてください。本番環境では Google Fonts を <link> で読み込まないでください。
3.B 状態
  • 分離された UI にはローカルの useState/useReducer を使用します。
  • グローバル状態は、深い階層にわたる props の受け渡しを避ける場合に限り使用します(Zustand、Jotai、または React context)。
  • 連続的に変化する値を、ユーザー入力に応じて追跡するために useState を使用しないでください(マウス位置、スクロールの進行状況、ポインターの物理演算、磁石のようなホバー効果など)。Motion の useMotionValue/useTransform/useScroll を使用してください。useState は変更のたびに React ツリーを再レンダリングし、モバイルでは処理が破綻します。
3.C アイコン
  • 使用可能なライブラリ(優先順): @phosphor-icons/react、hugeicons-react、@radix-ui/react-icons、@tabler/icons-react。
  • 非推奨: lucide-react。ユーザーが明示的に指定した場合、またはプロジェクトがすでに依存している場合に限り使用できます。
  • SVG アイコンを自作しないでください。 必要なグリフがない場合は、別のライブラリを追加するか、プリミティブを組み合わせてください。アイコンのパスを一から描画しないでください。
  • プロジェクト内で使うアイコンファミリーは一つに統一します。 同じコンポーネントツリー内で Phosphor と Lucide を混在させないでください。
  • strokeWidth を全体で統一します(例:1.5 または 2.0)。
3.D 絵文字の方針

コード、マークアップ、表示テキストでは、デフォルトで絵文字の使用を避けてください。記号はアイコンライブラリのグリフに置き換えます。例外: ユーザーが遊び心のある雰囲気、チャット風の雰囲気、またはソーシャルメディアに馴染む雰囲気を明示的に求めた場合に限り、絵文字を使用できます。その場合でも、意図を持って控えめに使用してください。

3.E レスポンシブ対応とレイアウトの仕組み
  • ブレークポイントを標準化します(sm 640、md 768、lg 1024、xl 1280、2xl 1536)。
  • max-w-[1400px] mx-auto または max-w-7xl を使ってページレイアウトをコンテナ内に収めます。
  • ビューポートの安定性: 高さが画面全体に及ぶヒーローセクションに h-screen は絶対に使わないでください。モバイル(iOS Safari のアドレスバー)でレイアウトが跳ねるのを防ぐため、必ず min-h-[100dvh] を使ってください。
  • Flex の計算より Grid: 複雑な Flexbox のパーセンテージ計算(w-[calc(33%-1rem)])は絶対に使わないでください。必ず CSS Grid(grid grid-cols-1 md:grid-cols-3 gap-6)を使ってください。
3.F 依存関係の確認(必須)

サードパーティライブラリをインポートする前に、必ず package.json を確認してください。パッケージが見つからない場合は、最初にインストールコマンドを出力してください。ライブラリが存在すると決して決めつけないでください。


4. デザインエンジニアリング指針(バイアスの補正)

LLM はありきたりな表現に偏りがちです。こうした傾向をあらかじめ上書きしてください。各ルールには、状況に応じた例外条件があります。

4.1 タイポグラフィ
  • ディスプレイ/見出し: デフォルトは text-4xl md:text-6xl tracking-tighter leading-none です。

  • 本文/段落: デフォルトは text-base text-gray-600 leading-relaxed max-w-[65ch] です。

  • サンセリフフォントの選択:

    • デフォルトでは非推奨: Inter。まずは Geist、Outfit、Cabinet Grotesk、Satoshi、またはブランドに適したセリフ体を選んでください。
    • 例外: ユーザーがニュートラル/標準的/Linear 風の印象を明示的に希望する場合、または公共機関向け/アクセシビリティ優先のサイトである場合は、Inter を使用できます。
  • おすすめの組み合わせ: Geist + Geist Mono、Satoshi + JetBrains Mono、Cabinet Grotesk + Inter Tight、GT America + IBM Plex Mono。

  • セリフ体の使用ルール(デフォルトでは非常に非推奨):

    • セリフ体は、どのプロジェクトでもデフォルトのフォントとして使うことは非常に非推奨です。 「クリエイティブ/プレミアム/エディトリアルな印象になる」は、セリフ体を選ぶ理由にはなりません。「クリエイティブなブリーフ=セリフ体」というエージェントの既定の考え方は、本番ラウンドで最も頻繁に見られる AI らしさの兆候です。
    • セリフ体が許容されるのは、次のいずれかが明示的に当てはまる場合のみです:
      • ブランドのブリーフにセリフ体のフォント名が明記されている、または
      • 美的な方向性が真にエディトリアル/ラグジュアリー/出版物/写本/ヘリテージ/ヴィンテージに当てはまり、かつ、なぜこのセリフ体がこのブランドに適しているのかを説明できる
    • それ以外(クリエイティブエージェンシー、デザインスタジオ、モダンなブランド、プレミアムな消費者向けブランド、ポートフォリオ、ライフスタイル)では、デフォルトとしてサンセリフのディスプレイフォント(Geist Display、ABC Diatype、Söhne Breit、Cabinet Grotesk Display、Migra Sans、GT Walsheim、Inter Display、PP Neue Montreal)を使用してください。サンセリフのディスプレイフォントは「退屈」ではありません。ファッションで黒がデフォルトであるのと同じ理由で、これがデフォルトです。
    • 強調ルール(関連事項): 見出しの中の単語を強調したい場合(「and spatial design」のような動きのある表現)は、同じフォントのイタリック体または太字を使ってください。視覚的な面白さを加えるためだけに、サンセリフの見出しに無関係なセリフ体の単語を混ぜたり(またはその逆をしたり)しないでください。異なるフォントファミリーを混ぜた強調は素人っぽくなります。同じファミリー内でイタリック体または太字を使うのが正しい方法です。
    • デフォルトとして明確に禁止: Fraunces と Instrument_Serif(LLM が好みがちな 2 つのディスプレイ用セリフ体)。
    • セリフ体の使用が妥当な場合(上記のとおり、まれです)は、この候補から選び、連続するプロジェクトで同じセリフ体を使い回さないでください:PP Editorial New、GT Sectra Display、Cardinal Grotesque、Reckless Neue、Tiempos Headline、Recoleta、Cormorant Garamond、Playfair Display、EB Garamond、IvyPresto、Migra、Editorial Old、Saol Display、Söhne Breit Kursiv、Domaine Display、Canela、Schnyder、Tobias、NB Architekt、ITC Galliard。
  • イタリック体のディセンダー用余白(必須): ディスプレイ文字でイタリック体を使い、単語にディセンダー文字(y g j p q)が含まれる場合、leading-[1] または leading-none ではディセンダーが切れてしまいます。最低でも leading-[1.1] を使い、親要素に pb-1 または mb-1 を加えて余白を確保してください。リリース前に、ディスプレイ見出し内のイタリック体の単語をすべて確認してください。

4.2 色の調整
  • アクセントカラーは最大1色です。デフォルトでは彩度を80%未満にします。

  • LILA ルール: デフォルトの美学として、「AI パープル/ブルーの輝き」は推奨されません。ボタンに自動で紫の光彩を付けたり、無作為にネオンのグラデーションを使ったりしないでください。ニュートラルなベースカラー(Zinc/Slate/Stone)に、コントラストの高い単色のアクセント(エメラルド、エレクトリックブルー、ディープローズ、バーントオレンジなど)を組み合わせてください。

  • 例外: ブランドやブリーフで紫/バイオレット/ライラックが明示的に求められている場合は、積極的に取り入れてください。ただし、意図を持って仕上げてください。一貫性のあるパレット、調和の取れたニュートラルカラー、控えめなグラデーションを用います。ありきたりな AI 風グラデーションの乱用は避けてください。

  • プロジェクトごとにパレットは1つです。 同じプロジェクト内で、暖色系と寒色系のグレーを切り替えないでください。

  • 色の一貫性ロック(必須): ページのアクセントカラーを決めたら、ページ全体でその色を使用してください。暖色系グレーのサイトで、セクション7だけ青い CTA を突然使うことは避けてください。ローズをアクセントにしたサイトのフッターに、ティールのステータスバッジを置くことも避けてください。アクセントカラーを1色選んで固定し、リリース前にすべてのコンポーネントを確認してください。

  • プレミアム消費者向けパレットの禁止(必須、AI らしさが表れる頻度が2番目に高い要因):

    • プレミアム消費者向けのブリーフ(調理器具、ウェルネス、職人技、高級品、伝統工芸、DTC 家庭用品など)では、LLM がデフォルトで選びがちな組み合わせは 暖色系のベージュ/クリーム+真鍮/粘土/オックスブラッド/オークル+エスプレッソ/インク色の濃い文字色です。具体的には、デフォルトの背景色およびアクセントカラーとして、以下の16進カラーの系統を禁止します。
      • 背景色:#f5f1ea、#f7f5f1、#fbf8f1、#efeae0、#ece6db、#faf7f1、#e8dfcb(いずれも「暖かな紙/クリーム/チョーク/ボーン」)
      • アクセントカラー:#b08947、#b6553a、#9a2436、#9c6e2a、#bc7c3a、#7d5621(いずれも「真鍮/粘土/オックスブラッド/オークル」)
      • 文字色:#1a1714、#1a1814、#1b1814(いずれも「エスプレッソ/暖色系のほぼ黒」)
    • このパレットをプレミアム消費者向けブリーフのデフォルトとして選ぶことは禁止です。これまでにリリースしたプレミアム消費者向けサイトは、どれもこのパレットを使っています。その結果、ブランドの個性が見えなくなります。
    • デフォルトの代替案(ローテーションして、使い回さないでください):
      • コールドラグジュアリー: シルバーグレー+クローム+スモーク(Tesla、レザーを使わない Apple Watch Hermès をイメージ)
      • フォレスト: 深いグリーン+ボーン+アンバーのアクセント(Filson、Patagonia のプレミアムラインをイメージ)
      • ブラック&タン: 純粋なオフブラック+暖色系のタン、強いコントラスト、ベージュは使わない
      • コバルト+クリーム: 真鍮は使わず、単色のニュートラルカラーに鮮やかなブルーを合わせる
      • テラコッタ+スレート: 真鍮は使わず、暖色系の錆色を寒色系のグレーに合わせる
      • オリーブ+レンガ+紙: 彩度を抑えたオリーブにレンガ色のアクセントを合わせる
      • 純粋なモノクロ+鮮やかな色を1色: オフホワイト+オフブラック+明るいアクセントを1色(エレクトリックブルー、エメラルド、ホットピンクなど)
    • パレットローテーションのルール: 直前に生成したプレミアム消費者向けプロジェクトでベージュ+真鍮系のパレットを使った場合、このプロジェクトでは必ず別の系統を使ってください。同じ暖色系のクラフトパレットを2回続けてリリースしないでください。
    • 例外: ベージュ+真鍮+エスプレッソのパレットを使用できるのは、ブランドブリーフでそれらの色が明示されている場合、またはブランドのアイデンティティが真にヴィンテージ/職人技/暖かなクラフト調であり、この特定のパレットがこの特定のブランドに合う理由を説明できる場合に限ります。「調理器具のブリーフだから」という理由でデフォルトとして選ぶことは禁止です。
4.3 レイアウトの多様化
  • 中央配置への偏りを避ける: DESIGN_VARIANCE > 4 の場合、中央揃えのヒーロー/H1 セクションは避けてください。「画面を左右に分割」(50/50)、「左揃えのコンテンツ/右揃えのアセット」、「非対称な余白」、またはスクロール固定型の構成を採用してください。
  • 例外: メッセージそのものがデザインとなる、エディトリアル/マニフェスト/ローンチ告知のブリーフでは、中央揃えのヒーローを使ってもかまいません。
4.4 マテリアリティ、シャドウ、カード
  • カードを使うのは、エレベーションが実際の階層を伝える場合に限ります。それ以外の場合は、border-t、divide-y、または余白でグループ化します。
  • シャドウを使う場合は、背景の色相に合わせて色味を付けます。明るい背景に純粋な黒のドロップシャドウを使ってはいけません。
  • VISUAL_DENSITY > 7 の場合、汎用的なカードコンテナは禁止です。データ指標は装飾のないレイアウトで、ゆとりを持たせます。
  • 形状の一貫性を保つ(必須): ページ全体で使う角丸のスケールを1つ選び、統一します。選択肢は、すべて角張った形状(半径0)、すべて柔らかい形状(12~16px)、すべてピル型(インタラクティブ要素は完全な丸み)です。文書化されたルール(例:「ボタンは完全なピル型、カードは16px、入力欄は8px」)があり、そのルールを全体で守る場合に限り、異なる形状を組み合わせてもかまいません。四角いレイアウトに丸いボタンを置いたり、ピル型ボタンのページに四角いカードを置いたりするのは、デザインの破綻です。
4.5 インタラクティブ UI の状態

LLM は「成功した静的状態のみ」に偏りがちです。常に一連の状態をすべて実装します。

  • 読み込み中: 最終レイアウトの形状に合わせたスケルトンローダーを使います。汎用的な円形スピナーは避けます。
  • 空の状態: 見栄えよく構成し、データの入力方法を示します。
  • エラー状態: フォームでは明確なインライン表示、一時的なエラーには文脈に応じた表示(トーストのみ)を使います。
  • 触覚的なフィードバック: :active では -translate-y-[1px] または scale-[0.98] を使い、物理的に押した感覚を表現します。
  • ボタンのコントラスト確認(必須、アクセシビリティ): リリース前に、ボタンのテキストがボタンの背景に対して読みやすいことを確認します。白いボタンに白いテキスト、bg-white の CTA に text-white のラベル、ページ背景上にボーダーのない透明なボタンは、すべて禁止です。すべての CTA を監査し、コントラスト比が WCAG AA の最低基準(本文は4.5:1、大きなテキスト(18px以上)は3:1)を満たすようにします。写真背景上のゴーストボタンにも同じルールを適用します(背景パネル、スクリーン、またはストロークを使います)。
  • CTA ボタンの折り返し禁止(必須): ボタンのテキストはデスクトップで必ず1行に収めます。「選んだ実績を見る」のようなラベルが2行または3行に折り返される場合、そのボタンは不適切です。ラベルを短くする(主要 CTA は最大3語、理想は1~2語)か、ボタンの幅を広げて修正します(CTA に max-width を設定して幅を不自然に制限してはいけません)。デスクトップで CTA が折り返される場合、リリース前チェックは不合格です。
  • CTA の意図を重複させない(必須): 1つのページに同じ意図の CTA を2つ置くと、リリース前チェックは不合格です。同じ意図の例:「お問い合わせ」+「連絡する」+「お話ししましょう」+「プロジェクトを始める」+「何かを始める」+「ご連絡ください」は、すべて「連絡」の意図です。ラベルを1つ選び、ページ内(ナビゲーション、ヒーロー、フッター)で統一します。「無料で試す」+「始める」+「無料で登録」もすべて「登録」の意図、「実績を見る」+「選んだ実績を見る」+「プロジェクトを見る」もすべて「ポートフォリオ」の意図です。意図ごとにラベルは1つにします。
  • フォームのコントラスト確認(必須、アクセシビリティ): フォーム入力欄、プレースホルダーテキスト、フォーカスリング、補助テキスト、エラーテキストはすべて、セクションの背景に対して WCAG AA のコントラスト基準を満たす必要があります。ほぼ白いフォーム上の薄いプレースホルダー、ページセクション上の白いフォーム、コントラスト比が4.5:1を下回るフォームラベルは、すべて禁止です。リリース前にすべてのフォームを監査します。
4.6 データとフォームのパターン
  • ラベルは入力欄の上に配置します。補助テキストは任意ですが、マークアップには含めます。エラーテキストは入力欄の下に配置します。入力ブロックには標準の gap-2 を使います。
  • プレースホルダーをラベルとして使うことは、決して許可されません。
4.7 レイアウトの規律(厳守ルール。どれか1つでも違反すると、成果物は不適切です)
  • ヒーローは初期ビューポート内に必ず収めること。 デスクトップでは見出しは最大2行、補足テキストは最大 20語 かつ最大3〜4行にし、CTAはスクロールせずに見えるようにします。コピーが長すぎる場合は、フォントサイズを下げるか、コピーを削ります。補足テキスト20語で価値提案を説明できないなら、ルールが厳しすぎるのではなく、価値提案が明確ではありません。CTAを見つけるためにスクロールが必要になるほど、ヒーローをはみ出させてはいけません。
  • ヒーローのフォントサイズを適切に管理すること。 フォントサイズと画像サイズはセットで計画します。ヒーローのアセットが大きく、見出しが6語を超える場合は、text-7xl/text-8xl から始めないでください。ほとんどのヒーローで適切なデフォルト範囲は text-4xl md:text-5xl lg:text-6xl です。見出しが3〜5語の場合に限り、text-6xl md:text-7xl を使います。ヒーローの見出しが4行になるのは、コピーが長すぎるのではなく、必ずフォントサイズの誤りです。
  • ヒーローの上部パディング上限(必須): デスクトップではヒーローの上部パディングを最大 pt-24(約6rem)にします。これを超えると、ヒーローのコンテンツがビューポートの中央付近に浮いてしまい、意図的な余白ではなくレイアウトの不具合に見えます。ヒーローにもっと余裕が必要な場合は、上部パディングではなく、フォントサイズかアセットサイズを大きくしてください。
  • ヒーローのスタックを適切に管理すること(テキスト要素は最大4つ)。 ヒーローはひとつの印象を伝える場であり、機能一覧ではありません。使用できるテキスト要素は、合計最大4つです。
    1. アイブロウ(小さな大文字ラベル)、ブランドストリップ、またはどちらもなし。0個か1個を選択します
    2. 見出し(最大2行。上記を参照)
    3. 補足テキスト(最大20語、最大4行)
    4. CTA(プライマリ1つ+セカンダリ最大1つ)
    • ヒーローで禁止する要素: CTAの下に置く小さなタグライン(「GitHub、GitLab、セルフホスト可能なGitに対応」)、信頼性を示す小さな帯(「エンジニアリングチームに利用されています…」)、料金の予告(「個人は無料、チームはユーザーあたり$10」)、機能の箇条書き、ソーシャルプルーフのアバター列。これらはすべて、ヒーロー直下の専用セクションに移動します。
    • 同じヒーロー内にアイブロウとCTA下のタグラインがある場合は、タグラインを削除します。ブランドストリップとタグラインがある場合も、タグラインを削除します。ヒーローに置く小さなテキスト要素は最大1つです。
  • 「導入企業」/「信頼される企業」のロゴ一覧はヒーローの下に配置し、ヒーロー内には置かないこと。 ヒーローでは価値提案と主要CTAを伝えます。ロゴ一覧は、その直下に置く独立したセクションです。ヒーローのコピーと同じフレックス行に信頼性を示すロゴを詰め込まないでください。
  • デスクトップではナビゲーションを必ず1行で表示すること。 lg(1024px)で項目が収まらない場合は、ラベルを短くするか、二次項目を削るか、ハンバーガーメニューに移します。デスクトップで2行になるナビゲーションは設計不良です。
  • ナビゲーションの高さ上限:デスクトップで最大80px、デフォルトは64〜72px。 ビューポートの15%を占めるような巨大な「エージェンシー風」ナビゲーションバーは避けます。
  • Bentoグリッドではリズムを持たせ、片側に偏った繰り返しを避けること。 左に画像、右にテキストの行を6つ積み重ねないでください。全幅の機能行、非対称なタイルサイズ、縦方向の区切りなどを組み合わせて構成に変化をつけます。
  • BENTOのセル数ルール(必須): Bentoグリッドのセル数は、コンテンツの項目数と必ず一致させます。項目が3つならセルも3つ(1+2の分割、2+1、または非対称な3セル)。項目が5つならセルも5つ(2+3、3+2、ヒーロー+4つなど)。グリッドの中央や末尾に空のセルがある場合は、計画に誤りがあります。グリッドを組み直し、空のタイルを貼り付けないでください。
  • セクションレイアウトの繰り返し禁止。 セクションでレイアウトの種類(例:3列の画像カード、全幅の引用、テキストと画像の分割)を使ったら、その種類をページ内で使えるのは最大1回です。「厳選した制作実績」を「提供内容」と同じ見た目にしてはいけません。8つのセクションがあるランディングページでは、少なくとも4種類のレイアウトを使います。
  • ジグザグ交互配置の上限(必須)。 「左に画像+右にテキスト」、続いて「左にテキスト+右に画像」と交互に並べるジグザグレイアウトはありきたりです。画像とテキストを分割するパターンを連続で使えるのは最大2セクションです。画像とテキストを分割するセクションが3つ連続したら、出荷前チェックで不合格です。全幅セクション、縦積みセクション、Bentoグリッド、マーキー、または別のレイアウトの種類を使ってパターンを崩してください。
  • アイブロウは控えめに(必須。本番テストで最も違反が多いルールです)。 「アイブロウ」とは、セクション見出しの上に置く、小さな大文字で文字間隔を広げたラベルです(例:FOUR COLORWAYS、SELECTED WORK、THE HARDWARE、Git-native task management)。典型的なCSSの指定は text-[11px] uppercase tracking-[0.18em]、font-mono text-[10.5px] uppercase tracking-[0.22em] です。AIで構築されたサイトは、すべてのセクション見出しの上にアイブロウを置きがちで、同じテンプレートのようなリズムになってしまいます。厳格なルール:
    • アイブロウは3セクションにつき最大1つ。 ヒーローも1セクションとして数えます。つまり、9セクションのページで使えるアイブロウは合計最大3つです。
    • セクションAにアイブロウがある場合、次の2つのセクションにはアイブロウを置けません。
    • 出荷前チェックは機械的に行います: すべてのセクションコンポーネントで、uppercase tracking(または見出しの上に置かれた同様の小さな大文字モノスペースラベル)の数を数えます。その数が ceil(sectionCount / 3) を超えると、出力は不合格です。
    • アイブロウの代わりにすること: アイブロウを完全に省きます。見出しだけで十分です。セクションを分類したい場合も、ページ内の位置ですでに分類できているため、ラベルは必要ありません。
  • 見出しの分割配置は禁止(必須)。 セクション見出しで「左に大きな見出し+右に小さな説明段落」を配置するパターン(左カラムが col-span-7/8、右カラムが col-span-4/5 で、右カラムに小さな本文を置くレイアウト)は、デフォルトでは禁止です。セクションではメッセージを1つに絞ります。見出しと説明段落の両方が本当に必要な場合は、縦に積み重ねます(見出しを上、本文を下にし、最大幅は65ch)。分割配置を使うのは、右カラムに単なる埋め草ではなく、ビジュアル要素やインタラクティブ要素を配置するなど、実際の構成上の理由がある場合に限ります。
  • Bentoの背景に多様性を持たせること(必須)。 Bentoや機能グリッドのセクションを、白地に白いカードを6つ並べてテキストを入れるだけの構成にしてはいけません。複数セルのグリッドでは、少なくとも2〜3セルに実質的なビジュアルの変化を加えます。実際の画像、ブランドに合ったグラデーション(AIらしい紫は避ける)、パターン、色付きの背景などを使います。タイポグラフィしか使わないクリーム色の背景のBentoは、ページのほかの部分が優れていても、退屈なAIのデフォルトデザインに見えます。
  • 各セクションでモバイル時の折りたたみ方を明示すること。 複数カラムのレイアウトでは、同じコンポーネント内に < 768px での代替表示を指定します。「Tailwindが対応するから大丈夫」と思い込んではいけません。
4.8 画像とビジュアルアセットの戦略

ランディングページやポートフォリオはビジュアルが中心のプロダクトです。スクリーンショット風の偽の div を使ったテキストだけのページは、手抜きです。

ビジュアルアセットの優先順位:

  1. まず画像生成ツールを使います。 環境内で画像生成ツール(generate_image、MCP 画像ツール、IDE 統合型生成ツール、OpenAI 画像ツールなど)が少しでも利用できる場合は、必ず使って、セクションに合わせたアセットを作成してください。ヒーロー画像、プロダクト写真、テクスチャ背景、ムード画像などを生成します。セクションに合ったアスペクト比にしてください。手書きの CSS のほうが速そうだからといって、この手順を省略してはいけません。
  2. 次に実際のウェブ画像を使います。 画像生成ツールを利用できない場合は、実際の写真ソースを使ってください。使用可能なデフォルト:
    • プレースホルダー用の写真には https://picsum.photos/seed/{descriptive-seed}/{w}/{h} を使用します(シードにはセクションを表す説明を含めてください。例:marrow-cookware-kitchen)。
    • ブリーフに指定されている場合は、実際のストック画像またはブランドの URL を使います。
    • 明示的に許可されている場合は、オープンライセンスのソース(直接 URL での Unsplash、Pexels)を使います。
  3. 最後の手段として、ユーザーに伝えます。 どちらも利用できない場合は、ページを手書き SVG イラストや div ベースの「偽スクリーンショット」で埋めないでください。代わりに、明確なラベル付きのプレースホルダースロット(``)を残し、回答の最後に次のように記載します:"このページには次の場所に実際の画像が必要です:[配置場所のリスト]。画像を生成するか、提供してください。"

ミニマリストなサイトにも実際の画像が必要です。 テキストだけのページはミニマリズムではありません。未完成な作業です。エディトリアルな Linear 風のサイトでも、実際の画像が少なくとも 2~3 枚必要です(ヒーロー、プロダクトまたはライフスタイル写真 1 枚、補助画像 1 枚)。ブリーフが控えめなデザインを求めている場合は、モノクロのミニマリスト写真を生成してください。設定の強度が低いからといって、画像を完全に省略してはいけません。

ソーシャルプルーフには実在企業のロゴを使います。 ブリーフで「Trusted by / Used by / Customers」のロゴ一覧が求められている場合、プレーンテキストのワードマーク(<span>Acme Co</span> を横並びにスタイル設定したもの)をデフォルトで使わないでください。実際の SVG ロゴを使います。

  • ソース:Simple Icons(任意の色には https://cdn.simpleicons.org/{slug}/ffffff、または simple-icons npm パッケージ)。広く知られているブランドの大半を網羅しています。
  • 代替: 技術スタックのロゴには devicon(@svgr/cli または CDN)。
  • ブランド名を創作する場合は、SVG マークも作成します。 シンプルなモノグラム(円の中の 1 文字、2 文字の合字、抽象的なグリフ)を、ページのスタイルに合わせたインライン <svg> として描画します。架空のブランド名にプレーンテキストのワードマークを使うと、ありきたりに見えます。
  • ロゴはライトモードとダークモードの両方で必ず正しく表示されるようにします(暗い背景には白、明るい背景には黒、またはテーマ変数による単色)。
  • ロゴのみのルール(必須): ロゴ一覧にはロゴ以外を含めません。各ロゴの下に業界やカテゴリのラベルを表示しないでください(Vercel の下に hosting、Stripe の下に payments、Cloudflare の下に infra などを付けないこと)。ロゴ自体が信頼性を示します。ユーザーがすでに知っている情報をラベルで追加する必要はありません。任意:スクリーンリーダー向けの代替テキストとしてブランド名を指定する、ブランドサイトへのリンクを付ける。以上です。

手書きのイラスト:

  • ライブラリの SVG アイコン:問題ありません(セクション 3.C を参照)。
  • 手書きの装飾用 SVG(カスタムイラスト、ロゴ、マーク):強く非推奨です。 デフォルトでは決して使わないでください。使用が許容されるのは、次の場合に限ります。
    • ブリーフで明示的に求められている場合(「SVG ロゴを描いてください」など)
    • シンプルな幾何学的マーク 1 つだけの場合(四角形、円、ディスプレイ書体のワードマーク)
    • 出力品質に自信がある場合

div ベースの偽スクリーンショットは禁止です。 <div> の四角形、偽のタスクリスト、偽のダッシュボード、偽のターミナルウィンドウで描画した「手作りのプロダクトプレビュー」は、手抜きの表れです。プロダクトを表示する必要がある場合:

  • 実際のスクリーンショット URL があれば使用します。
  • 画像ツールで生成します。
  • 実際のコンポーネントプレビュー(ページ内に UI の実際のミニバージョンを表示するもの)を使います。
  • または、プレビューを完全に省略してエディトリアル写真を使います。

ヒーローには実際のビジュアルが必要です。 テキストとグラデーションの blob だけではヒーローとは言えません。プレースホルダーです。

4.9 コンテンツ密度

ランディングページで重要なのは第一印象であり、すべてを読んでもらうことではありません。思い切って削りましょう。

  • 各セクションの基本構成: 短い見出し(8語以内)+短い補足文(25語以内)+ビジュアル素材1点、またはCTA1つ。それ以上の要素を加える場合は、そのセクションの役割に照らして必要性を説明できなければなりません。

  • データを詰め込んだセクションは避けましょう。 20行の出版物一覧、30行の受賞歴、マーケティングページに巨大な価格表を載せるのは、レイアウトとして不適切です。次の方法を使いましょう。

    • 特に重要な3〜5項目を表示し、「一覧を見る」リンクを設ける
    • マーキー/カルーセルで幅広く見せる
    • データ自体が製品である場合は、別のページに分ける
  • 長いリストには、リストを長くするのではなく別のUIコンポーネントを使いましょう。 箇条書きやdivide-yの行を使うデフォルトの<ul>は、安易な選択です。項目が5つを超える場合は、代わりに次のいずれかを使いましょう。

    • 項目をグループ分けした2列レイアウト
    • 各項目に画像とラベルを付けたカードグリッド
    • 項目を分類できる場合はタブ/アコーディオン
    • 横スクロールできるスナップピル
    • 項目の種類が多いリスト(お客様の声、ロゴ、機能など)にはカルーセル
    • 「個々に注目する必要のない、たくさんの項目」にはマーキー 10行の仕様表に各行の下線を引くレイアウトは、デフォルトとして最悪です。行を2〜3個のグループにまとめて区切り線を控えめにするか、仕様ごとにカードを設けるレイアウトに変更しましょう。
  • 特に仕様表について(Marrowの調理器具パターン)。 各行にborder-bを付けた長い製品仕様表は、調理器具/ハードウェア/アパレル/職人製品の概要を作る際にAIが選びがちなデフォルトです。禁止です。具体的な代替案は次のとおりです。

    • 2列のカードグリッド: 各仕様をカードにして、仕様名、値(大きく表示する数値)、重要性を説明する1行の本文を載せます。デスクトップでは2列、モバイルでは1列に並べます。
    • スナップピルの横スクロール: 各仕様をピルにし、ユーザーがスワイプして見られるようにします。
    • グループ分け: 10個の仕様を「素材」「調理」「保証」など、論理的な3つのグループに分けます。各グループには控えめな区切り線を1本だけ設け、見出しを付けます。
    • 注目項目とその他に分ける: 特に重要な3〜4個の仕様を大きなタイルで視覚化し、残りは「すべての仕様を見る」の開示項目にまとめます。
  • コピーの自己監査(公開前に必須): タスクの完了を宣言する前に、ページ上に表示されるすべての文言(見出し、副見出し、アイブロウ、ボタンラベル、本文、キャプション、代替テキスト、フッターの文言、エラーメッセージ)を読み直します。次のような文言があれば指摘してください。

    • 文法が崩れている(「過去の上で無料」「2つのプランがあるが、正直なのは1つ」「文脈と関係なく『それをテーブルに載せる』」)
    • 指示対象が不明確(前後に文脈がないのに「私たちはそのままでいるつもりです」と書かれている)
    • AIの幻覚のように聞こえる(かわいらしいが間違った言葉遊び、筋の通らない無理な比喩、「優雅な無」などの表現)
    • LLMが思慮深そうに見せようとしているように読める(受け身で攻撃的な謙遜、職人を気取ったラベル、気取った詩的なメタ表現) 指摘した文言はすべて書き直してください。意味が通るかどうか確信が持てない場合は、わかりやすく実用的な文に置き換えてください。AIが生成した気の利いたコピーは、退屈なコピーよりも悪いものです。
  • 根拠のない精密な数値は指摘対象です。 92%、4.1×、48k、5.8 mm、13.4 lbなどの数値は、次のいずれかに該当する必要があります。

    • 実際のデータ(概要、ブランドガイドライン、公開されている指標)に基づいている:問題ありません
    • モックであること(``, 「例」、「サンプルデータ」)が明記されている:問題ありません
    • AIが仕様らしく見せるために作り出した数値である:禁止です。ブランドが主張していない技術的な精密さをでっち上げないでください。
  • ページ内の文体は統一しましょう。 ブランドの声として明確に求められていない限り、技術的な簡潔表現(「47タスク・1日あたり0.6回のコンテキスト切り替え」)、編集的な文章、マーケティング調の力強いコピーを同じ構成に混在させないでください。

4.10 引用と推薦コメント
  • 引用本文は最大3行です。6行にはしないでください。元の引用がそれより長い場合は、短くしてください。ランディングページの引用は抜粋であり、レビュー全文ではありません。
  • フォントサイズが非常に小さい場合(例:フッター風の推薦コメント)は、行数の上限を少し超えてもかまいません。大切なのは「ひと目で読める」ことです。
  • デザイン上の演出として、引用文の中にエムダッシュを使わないでください(長い間、動きを表すエムダッシュ、エムダッシュを使った箇条書きなど)。セクション9.Gを参照してください。エムダッシュは全面的に禁止です。
  • 引用元の表記:氏名+役職+(任意で)会社名。氏名のみ(「- Sarah」)にはしないでください。
  • 引用符:適切なタイポグラフィの引用符( " " )を使うか、引用符を使わないでください。ASCII のまっすぐな引用符( " )は使わないでください。
4.11 ページのテーマを統一する(ライト/ダークモードの一貫性)

ページ全体でテーマは1つにします。セクションごとに反転させてはいけません。

  • ページがダークモードなら、すべてのセクションをダークモードにしてください。ダークなセクションの間に、ライトモードの温かみのある紙色のセクションを挟まないでください(逆も同様です)。スクロール中に別のサイトに迷い込んだように感じさせてはいけません。
  • 例外として、ブリーフで「Color Block Story」または「Theme Switch on Scroll」の演出が明示的に求められており、意図的な構成である場合(ランダムな切り替えではなく、明確なトランジションを伴うテーマの切り替えを1回だけ行う場合)は許可されます。
  • デフォルトでは、ページレベルでライト、ダーク、または自動(prefers-color-scheme)を選び、固定してください。同じテーマファミリー内でセクションごとに背景の色合いを変えるのは問題ありません(bg-zinc-950 の隣に bg-zinc-900 など)。bg-zinc-950 のページの途中で bg-amber-50 に切り替えるのは適切ではありません。
  • テーマが組み込まれたデザインシステム(Radix Themes、<Theme> を使った shadcn/ui など)を使用する場合は、テーマを layout.tsx またはページルートで一度だけ設定してください。個々のセクションで上書きさせないでください。

5. コンテキストを踏まえた積極的な演出

これらはツールであり、デフォルトではありません。デザインの読み取りから必要と判断した場合に使ってください。いずれも自動では実行されません。

  • リキッドグラス/グラスモーフィズム: プレミアムなコンシューマー向け、Apple に近い雰囲気、高級ブランド、メディアオーバーレイのような演出に適しています。ダッシュボード、公共部門、「地味な B2B」には適していません。使用する場合は、backdrop-blur だけにとどめず、1px の内側のボーダー(border-white/10)と、さりげない内側のシャドウ(shadow-[inset_0_1px_0_rgba(255,255,255,0.1)])を加えて、物理的なエッジの屈折を表現してください。prefers-reduced-transparency の場合は、単色塗りつぶしに切り替えてください。
  • 磁石のようなマイクロフィジックス: MOTION_INTENSITY > 5 かつブリーフがプレミアム/遊び心のあるもの/エージェンシー向けである場合に使ってください。実装には、React のレンダーサイクルの外で Motion の useMotionValue/useTransform のみを使ってください。useState は決して使わないでください。セクション 3.B を参照してください。
  • 継続的なマイクロインタラクション(パルス、タイプライター、フロート、シマー、カルーセル):MOTION_INTENSITY > 5 かつセクションが動きの恩恵を実際に受ける場合(ステータスインジケーター、ライブフィード、AI らしさ)に使ってください。すべてのカードに無限ループが必要なわけではありません。 情報を伝えるだけのセクションは静止させてください。スプリングフィジックス(type: "spring", stiffness: 100, damping: 20)を適用し、線形イージングは使わないでください。
  • 「動きをうたうなら、実際に動かす。」 MOTION_INTENSITY > 4 の場合、ページには実際の動きが必要です。最低限、ヒーローの表示時トランジション、主要セクションのスクロール時表示、CTA のホバーフィジックスを実装してください。MOTION_INTENSITY: 7 としながら静止したページは不具合です。反対に、与えられた範囲で動きをきちんと実装できない場合は、値を 3 に下げ、すっきりとした静的ページを納品してください。中途半端に実装して動作を壊すこと(途中で切れる ScrollTrigger、ぎこちない表示、クリーンアップ漏れ)は決して避けてください。
  • 動きには必ず理由を持たせる(必須)。 アニメーションを加える前に、「このアニメーションは何を伝えるのか?」と考えてください。妥当な答えは、階層(適切な要素に注意を引く)、ストーリーテリング(物語に沿った順序でコンテンツを表示する)、フィードバック(ユーザーの操作を認識する)、状態遷移(何かが変化したことを示す)です。不適切な答えは、「かっこよく見えたから」です。GSAP が使えるからといって、あらゆる箇所に GSAP を使うのは未熟です。それぞれの ScrollTrigger、マーキー、ピン留めセクションには理由が必要です。その理由を一文で説明できない場合は、アニメーションを取り除いてください。
  • マーキーは1ページにつき最大1つ(必須)。 横スクロールするテキストマーキー(「ロゴが延々とスクロールする」「マニフェストが横方向に流れる」「動きのある単語の帯」)は、1ページにつき最大1回まで適切です。同じページにマーキーが2つ以上あると、手抜きの埋め草に見えます。マーキーがコンテンツに本当に役立つセクションを1つ選び、他のセクションには別のレイアウトを使ってください。
  • GSAP のスティッキースタックパターン(スクロールスタックを使う場合)。 「スクロール時にカードが積み重なる」演出は、順番に表示するリストではなく、実際のスティッキースタックにしてください。標準的なコードの骨組みは、以下のセクション 5.A を参照してください。よくある失敗は、ビューポート上部に固定されず、スクロールの途中でトリガーされることです。修正するには、start: "top center" や "top 80%" ではなく、start: "top top" を使ってください。
  • GSAP の水平パンパターン(水平スクロールの乗っ取りを使う場合)。 標準的な骨組みは、セクション 5.B を参照してください。よくある失敗は、セクションがピン留めされる前にアニメーションが始まり、ユーザーにスライドの途中が見えてしまうことです。同じく、start: "top top" を指定し、ラッパーをピン留めして、内側のトラックをスクラブしてください。
5.A Sticky-Stack - 標準スケルトン
"use client";
import { useRef, useEffect, useId, type ReactNode } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function StickyStack({ cards }: { cards: ReactNode[] }) {
  const ref = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();
  const instanceId = useId().replace(/:/g, "");
  const cardClass = `stack-card-${instanceId}`;
  const innerClass = `stack-card-inner-${instanceId}`;

  useEffect(() => {
    if (reduce || !ref.current || cards.length <= 1) return;
    const ctx = gsap.context(() => {
      const cardEls = gsap.utils.toArray<HTMLElement>(`.${cardClass}`);
      cardEls.forEach((card, i) => {
        if (i === cardEls.length - 1) return;
        ScrollTrigger.create({
          trigger: card,
          start: "top top",                              // pin at viewport top
          endTrigger: cardEls[cardEls.length - 1],
          end: "top top",
          pin: true,
          pinSpacing: false,
          anticipatePin: 1,
          invalidateOnRefresh: true,
        });
        const inner = card.querySelector(`.${innerClass}`);
        if (!inner) return;
        gsap.to(inner, {
          scale: 0.92,
          opacity: 0.55,
          ease: "none",
          scrollTrigger: {
            trigger: cardEls[i + 1],
            start: "top bottom",
            end: "top top",
            scrub: true,
            invalidateOnRefresh: true,
          },
        });
      });
    }, ref);
    return () => ctx.revert();
  }, [reduce, cards.length, cardClass, innerClass]);

  return (
    <div ref={ref} className="relative">
      {cards.map((card, i) => (
        <div
          key={i}
          style={{ zIndex: i + 1 }}
          className={`${cardClass} relative min-h-[100dvh] flex items-center justify-center`}
        >
          <div className={`${innerClass} w-full flex items-center justify-center will-change-transform`}>
            {card}
          </div>
        </div>
      ))}
    </div>
  );
}

重要なポイント:start: "top top"、pin: true、最後のカード以外はすべてピン留めします。スケール/不透明度の変化は次のカードのスクロールトリガーによって制御されます(次のカードが近づくにつれて、前のカードが縮小します)。同じ要素に CSS の position: sticky と pin: true を決して併用しないでください。切り替わり時に、ネイティブの sticky エンジンと ScrollTrigger の position: fixed が競合します(ガタつき、スナップ、座標のずれが発生します)。ピン留めする要素を変形させる要素にしてはいけません。外側のカードをピン留めして内側のラッパーをアニメーションするか、スケールトゥイーンによってピン留めの計測値がずれます。カードクラスはインスタンスごとにスコープを設定し(useId)、ページ上に 2 つのスタックがあっても相互に選択しないようにします。zIndex は昇順に設定します。prefers-reduced-motion の場合、コンポーネントは通常のリストを表示します。ピン留めも変形も行わず、すべてのコンテンツにアクセスできます。

5.B Horizontal-Pan - 標準スケルトン
"use client";
import { useRef, useEffect, type ReactNode } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function HorizontalPan({ children }: { children: ReactNode }) {
  const wrap = useRef<HTMLElement>(null);
  const track = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();

  useEffect(() => {
    if (reduce || !wrap.current || !track.current) return;
    const ctx = gsap.context(() => {
      const getDistance = () =>
        Math.max(0, track.current!.scrollWidth - wrap.current!.clientWidth);
      gsap.to(track.current, {
        x: () => -getDistance(),
        ease: "none",
        scrollTrigger: {
          trigger: wrap.current,
          start: "top top",                              // pin starts when section top hits viewport top
          end: () => `+=${getDistance()}`,               // scroll distance = track width minus viewport, recomputed on refresh
          pin: true,
          scrub: 1,
          anticipatePin: 1,
          invalidateOnRefresh: true,
        },
      });
    }, wrap);
    return () => ctx.revert();
  }, [reduce]);

  return (
    <section
      ref={wrap}
      role="region"
      aria-label="Horizontal content track"
      tabIndex={reduce ? 0 : undefined}
      className={`relative w-full ${reduce ? "overflow-x-auto scroll-smooth" : "overflow-hidden"}`}
    >
      <div
        ref={track}
        className={`flex h-[100dvh] w-max items-center ${reduce ? "snap-x snap-mandatory" : ""}`}
      >
        {children}
      </div>
    </section>
  );
}

重要なポイント:start: "top top"、pin: true、end: "+=${getDistance()}"(スクロール距離 = 必要な水平移動距離)、scrub: 1。ラッパーをピン留めし、内側のトラックをユーザーの垂直スクロールに合わせて水平方向にスライドさせます。x と end は関数ベースにし、invalidateOnRefresh: true と組み合わせる必要があります。一度だけ取得した distance は再計算されません。リサイズ後は、何もない空間までスクロールしすぎるか(トラックが収まる場合は何もない場所をパンするか)します。トラックには w-max を指定し、各パネルは縮小しないようにします(shrink-0 または明示的な幅を指定)。これをしないと、オーバーフローによる圧縮で scrollWidth が小さくなり、パンせずにセクションがピン留めされます。prefers-reduced-motion の場合は、ラッパーを overflow-x-auto とスナップポイントに切り替え、overflow-hidden のままにせず、すべてのパネルにアクセスできるようにします。

5.C スクロール連動の段階的表示 - 標準スケルトン(軽量な代替手段)

ピン留めなしで「項目がビューポートに入ると表示される」だけの場合は、GSAP よりも Motion の whileInView を優先してください。より軽量で、ScrollTrigger も不要です。

"use client";
import { motion, useReducedMotion } from "motion/react";

export function RevealStagger({ items }: { items: string[] }) {
  const reduce = useReducedMotion();
  return (
    <ul className="grid gap-6">
      {items.map((item, i) => (
        <motion.li
          key={item}
          initial={reduce ? false : { opacity: 0, y: 24 }}
          whileInView={{ opacity: 1, y: 0 }}
          viewport={{ once: true, amount: 0.3 }}
          transition={{
            duration: 0.6,
            delay: i * 0.06,
            ease: [0.16, 1, 0.3, 1],
          }}
        >
          {item}
        </motion.li>
      ))}
    </ul>
  );
}

次の用途に使用します:機能リスト、お客様の声のグリッド、ロゴ一覧など、「スクロールに合わせて表示」するだけのもの。GSAP は実際にピン留めやスクラブが必要な場合に使用します。

5.D 禁止されているアニメーションパターン
  • window.addEventListener("scroll", ...) は禁止です。スクロールの各フレームで実行され、カクつきやすく、バッチ処理もされません。代わりに Motion の useScroll()、GSAP の ScrollTrigger、IntersectionObserver、または CSS の scroll-driven animations(animation-timeline: view())を使用します。
  • React の状態で window.scrollY を使用してスクロール進捗を独自に計算すること。同じ理由で、各フレームで再レンダリングが発生します。
  • React の状態を操作する requestAnimationFrame ループ。代わりにモーション値(useMotionValue + useTransform)を使用します。
  • レイアウトのトランジション: 表示状態の変化(リストの並べ替え、モーダルの展開、ルート間で共有される要素)には Motion の layout と layoutId プロパティを使用します。「念のため」に静的コンテンツを layout プロパティで囲まないでください。計測処理が増加します。
  • 段階的なオーケストレーション: 順序が重要な表示演出には、staggerChildren(Motion)または CSS のカスケード(animation-delay: calc(var(--index) * 100ms))を使用します。staggerChildren を使用する場合、親(variants)と子は同じ Client Component ツリーに属している必要があります。

6. パフォーマンスとアクセシビリティのガードレール

6.A ハードウェアアクセラレーション
  • アニメーションさせるのは transform と opacity のみです。top、left、width、height はアニメーションさせないでください。
  • will-change: transform は控えめに使用し、実際にアニメーションする要素にのみ指定します。
6.B モーションの低減(必須)
  • MOTION_INTENSITY > 3 のモーションはすべて、prefers-reduced-motion に対応する必要があります。 これは必須です。
  • Motion では、useReducedMotion() で囲み、静的な表示に切り替えます。
  • CSS では、@media (prefers-reduced-motion: no-preference) の中でアニメーションを有効にするか、@media (prefers-reduced-motion: reduce) の中にアニメーションを無効にするオーバーライドブロックを用意します。
  • 無限ループ、視差効果、スクロールの乗っ取り、磁力の物理演算は、モーション低減時に静的表示または即時の動作に切り替える必要があります。
6.C ダークモード(ユーザー向けページでは必須)
  • 最初から両モードを設計してください。ユーザーから明示的な指示がない限り、ライト専用やダーク専用でリリースしてはいけません。
  • トークンには Tailwind の dark: バリアントまたは CSS 変数を使用してください。プロジェクトごとにどちらか一方の戦略を選んでください。
  • ここで具体的なダークモードの色を規定しないでください。 それはブリーフが決定します。両モードを通じて、視覚的階層、ブランドアイデンティティ、WCAG AA コントラスト(本文は AAA)を維持してください。
  • prefers-color-scheme: dark を尊重してください。ブランドが一方のモードを強く主張しない限り、システム設定をデフォルトにしてください。
6.D Core Web Vitals の目標値
  • LCP < 2.5 秒。ヒーロー画像は next/image priority にするか、プリロードする必要があります。
  • INP < 200ms。重い処理はメインスレッドから外してください。
  • CLS < 0.1。画像、フォント、埋め込み要素のためのスペースを確保してください。
  • ページを完成と見なす前に Lighthouse を実行してください。
6.E DOM コスト
  • グレイン / ノイズフィルターは、固定された pointer-events-none の疑似要素(例: fixed inset-0 z-[60] pointer-events-none)にのみ適用してください。スクロールするコンテナには絶対に適用しないでください - 継続的な GPU 再描画がモバイルの FPS を破壊します。
  • バンドルサイズに注意してください。Motion は小さくありません。Three.js は巨大です。ファーストビューにないものはすべて遅延読み込みしてください。
6.F Z-Index の抑制

任意の z-50 や z-10 を絶対に乱用しないでください。z-index はシステム的なレイヤーコンテキスト(固定ナビゲーションバー、モーダル、オーバーレイ、グレイン)に厳密に使用してください。z-index のスケールをプロジェクトの定数ファイルに文書化してください。


7. ダイヤルの定義(技術リファレンス)

DESIGN_VARIANCE(レベル 1〜10)
  • 1〜3(予測可能): 対称的な CSS Grid(12 カラム、等しい fr 単位)、均等なパディング、中央揃え。
  • 4〜7(オフセット): margin-top: -2rem のオーバーラップ、多様な画像アスペクト比(4:3 の隣に 16:9)、中央揃えのデータの上に左揃えのヘッダー。
  • 8〜10(非対称): メイソンリーレイアウト、分数単位を使った CSS Grid(grid-template-columns: 2fr 1fr 1fr)、巨大な空白ゾーン(padding-left: 20vw)。
  • モバイルオーバーライド: レベル 4〜10 では、md: 以上での非対称レイアウトは、ビューポート < 768px で厳密な単一カラム(w-full、px-4、py-8)に折りたたまなければなりません。
MOTION_INTENSITY(レベル 1〜10)
  • 1〜3(静的): 自動アニメーションなし。CSS の :hover と :active 状態のみ。そもそも prefers-reduced-motion がデフォルトモードです。
  • 4〜7(流動的な CSS): transition: transform 0.3s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.3s cubic-bezier(0.16, 1, 0.3, 1)(プロパティを明示してください。transition: all は決して使わないでください。これは GPU から外れたレイアウトプロパティもアニメーションさせてしまいます。6.A を参照)。読み込み時の animation-delay カスケード。
  • 8〜10(高度な振り付け): 複雑なスクロールトリガーの表示、パララックス、スクロール駆動アニメーション(CSS animation-timeline または GSAP ScrollTrigger)。Motion フックを使用してください。window.addEventListener('scroll') は絶対に使用しないでください - これは「できれば避ける」ではなく、厳格な禁止事項です。許可される代替手段についてはセクション 5.D を参照してください。
VISUAL_DENSITY(レベル 1〜10)
  • 1〜3(アートギャラリー): 大量の余白。巨大なセクション間隔(py-32 〜 py-48)。高級感があり、クリーン。
  • 4〜7(日常的なアプリ): 標準的な Web アプリの間隔(py-16 〜 py-24)。
  • 8〜10(コックピット): 詰まったパディング。カードボックスなし。1px の線がデータを区切ります。必須: すべての数値に font-mono。

8. ダークモードプロトコル

デフォルトでデュアルモード。ブリーフが印刷を模したエディトリアルでない限り、ライト専用と仮定しないでください。

8.A トークン戦略(1 つ選び、それに固執する)
  • Tailwind の dark: バリアント(ユーティリティファーストのプロジェクトでのデフォルト): すべてのカラーユーティリティをそのダークバリアントとペアにします(bg-white dark:bg-zinc-950、text-gray-900 dark:text-gray-100)。
  • CSS 変数(shadcn/ui、Radix Themes、またはテーマ機能を持つコンポーネントライブラリ向け): セマンティックトークン(--surface、--surface-elevated、--text-primary、--accent)を定義し、[data-theme="dark"] または @media (prefers-color-scheme: dark) の下で値を差し替えます。
8.B ここで特定の色を指定しない

ブリーフとブランドに従ってください。このスキルで定めるのは、次の点だけです。

  • コントラスト — 本文はWCAG AAを最低基準とし、ヒーローコピーはAAAを目標にします。
  • 階層の一貫性 — ライトモードで機能する視覚的な階層は、ダークモードでも機能する必要があります。ライトモードでCTAが目立つなら、ダークモードでも目立たせます。
  • ブランドの忠実性 — ブランドのプライマリーカラーは、認識できる状態を保ちます。ブランドカラーをダークモードに合わせて彩度を落としすぎないでください。
  • 純粋な #000000 と純粋な #ffffff は使わない — オフブラック(zinc-950や黒に近い暖色系グレー)とオフホワイトを使います。純粋な値では奥行きが失われます。
8.C デフォルトモード

ブランドの要件がない限り、prefers-color-scheme に従ってください。いずれかのモードでブランドの重要な表現が損なわれる場合は、手動切り替えを追加してください。

8.D 仕上げる前に両方のモードでテストする

開発中に両方のモードでページを開いてください。片方のモードしか確認していないページをリリースしないでください。


9. AIらしさの兆候(禁止パターン)

ブリーフで明示的に求められていない限り、次のような特徴は避けてください。

9.A ビジュアルとCSS
  • ネオンや外側のグローは、デフォルトでは使わないでください。 内側のボーダーや、色味を抑えた控えめなシャドウを使います。
  • 純粋な黒(#000000)は使わないでください。 オフブラック、zinc-950、またはチャコールを使います。
  • 彩度の高すぎるアクセントは使わないでください。 ニュートラルカラーになじむよう彩度を落とします。
  • 大きな見出しでグラデーションテキストを多用しないでください。
  • 独自のマウスカーソルは使わないでください。 時代遅れで、アクセシビリティとパフォーマンスの面で問題があります。
9.B タイポグラフィ
  • デフォルトでInterを使うのは避けてください。 セクション4.1を参照してください。上書きする方法もあります。
  • ただ目立たせるためだけにH1を大きくしすぎないでください。 サイズだけに頼らず、ウェイトと色で階層を整えます。
  • セリフ体の制約: セリフ体はエディトリアル、ラグジュアリー、出版物向けです。ダッシュボードには使いません。
9.C レイアウトと余白
  • パディングやマージンを数学的な完璧さだけで決めないでください。余白が不自然な要素を浮かせないようにします。
  • 3列の均等な機能カードは使わないでください。 「横並びの同一カード3枚」というありきたりな機能紹介の行は禁止です。2列のジグザグ配置、非対称グリッド、スクロールに固定するレイアウト、または横スクロール形式を使います。
9.D コンテンツとデータ(「Jane Doe」効果)
  • ありきたりな名前は使わないでください。 「John Doe」「Sarah Chan」「Jack Su」ではなく、創造的で、実在感があり、地域に合った名前を使います。
  • ありきたりなアバターは使わないでください。 SVGの「卵」やLucideのユーザーアイコンではなく、実際の人物らしい写真のプレースホルダーか、個別にスタイリングしたものを使います。
  • きれいすぎる数字は使わないでください。 99.99%、50%、1234567 は避けます。47.2%や+1 (312) 847-1928のような、自然でばらつきのあるデータを使います。
  • スタートアップ風の安易なブランド名は使わないでください。 「Acme」「Nexus」「SmartFlow」「Cloudly」ではなく、文脈に合った、上質で実在感のある名前を考えます。
  • 中身のない動詞は使わないでください。 「高める」「シームレス」「解き放つ」「次世代」「革新する」ではなく、具体的な動詞を使います。
9.E 外部リソースとコンポーネント
  • 手作りのSVGアイコンは使わないでください。 Phosphor、HugeIcons、Radix、Tablerを使います。Lucideは明示的に求められた場合に限ります。
  • 装飾用のSVGを手作りするのは、デフォルトでは強く避けてください(セクション4.8を参照)。
  • <div>ベースの偽スクリーンショットは使わないでください。 <div>の矩形を組み合わせて、スクリーンショットに見せかけた製品UIを作ってはいけません。実際の画像、生成画像を使うか、プレビューを省略してください。
  • 壊れたUnsplashリンクは使わないでください。 https://picsum.photos/seed/{descriptive-string}/{w}/{h}、生成した写真のプレースホルダー、または実際のアセットを使います。
  • shadcn/uiのカスタマイズ: 認められていますが、デフォルト状態のまま使うのは禁止です。プロジェクトの美的感覚に合わせて、角の丸み、色、シャドウ、タイポグラフィを調整してください。
  • 本番品質のクリーンさ: コードは視覚的にすっきりと仕上げ、記憶に残る、細部まで丁寧に練り上げられたものにしてください。
9.F 本番テストで見られた兆候(全面禁止)

これらのパターンは、実際のLLM生成ランディングページのテストで見られたものです。モデルが「デザインされた」ように見せようとすると、デフォルトで使いがちな特徴です。ブリーフで明示的に求められていない限り、絶対に使わないでください。

ヒーローとページ上部

  • ヒーローにバージョンラベルを入れないでください。 V0.6、v2.0、BETA、INVITE-ONLY PREVIEW、EARLY ACCESS、ALPHAは、デフォルトのアイブロウとしては禁止です。ブリーフで製品のローンチやプレビューの状況を明示的に扱っている場合に限り、使用できます。
  • 「Brand · No. 01」形式のサブアイブロウは使わないでください。 「Marrow · No. 01 · The 6-quart」のような短い補足メタ情報は省略します。 セクション番号とマイクロラベル
  • セクション番号を示す小見出しは禁止です。 00 / INDEX、001 · Capabilities、002 · Featured commission、06 · how it works、05 · The honest table は禁止です。小見出しには番号を付けず、トピックを平易な言葉で示してください。
  • 画像やタイルに 01 / 4 のようなページ番号を付けないでください。 数えればわかるものにラベルは必要ありません。
  • Scroll · 001 Capabilities のようなスクロール案内は禁止です。 矢印か「Scroll」だけで十分です。セクション番号は前に付けないでください。
  • 小見出しに「Index of Work, 2018 - 2026」のような期間表記を使わないでください。 セクションの内容をそのまま示してください。

区切り記号と中黒

  • 中黒(·)の使用は控えてください。 メタデータの行では最大1つまでです。何でも区切るために使わないでください(「foo · bar · baz · qux · quux」のような使い方は禁止です)。区切りが必要なら、改行、細い罫線、または列を使ってください。
  • リスト、ナビゲーション、バッジすべてに装飾用の色付きドットを付けないでください。 「ONE Q4 SLOT OPEN」の前や、各ナビゲーションリンク、各タスク行の前に色付きドットを置くのは禁止です。ドットがサーバーの状態や空き状況など、実際の意味を示す場合に限り、控えめに使用できます。

ダッシュとタイポグラフィの装飾

  • エムダッシュ(—)はデザイン要素としても、それ以外の用途でも使用禁止です。 詳細は以下のセクション9.Gを参照してください。エムダッシュの文字は、見出し、小見出し、ピル、本文、引用、クレジット、キャプション、ボタンのテキスト、代替テキストのいずれにも使用できません。通常のハイフン(-)を使ってください。
  • <br>で改行して斜体にする見出しを、定番のデザイン手法として使わないでください。 「for thirty<br>years.」のような分割です。見出しはまず自然に読めるものにし、依頼内容で求められる場合に限り、工夫を加えてください。
  • 縦向きに回転させたテキスト(「INDEX OF WORK, 2018 - 2026」を90度回転させるなど)は禁止です。 代理店ポートフォリオでよくある表現です。依頼内容が代理店、Awwwards、または実験的なデザインを明示的に求めており、レイアウト上の明確な目的がある場合に限り使用してください。
  • 装飾目的の十字線や細いグリッド線は禁止です。 ページを「デザインされた感じ」にするだけの縦線や横線は使用できません。実際のコンテンツを整理する場合に限り使用してください。

偽の製品プレビュー

  • ヒーローに、divで作った偽の製品UIを使わないでください。 スタイルを付けたdivで作る偽のタスクリスト、ターミナル、ダッシュボードなどは、LLMがデザインを作ったとすぐにわかる最大のサインです。実際のスクリーンショット、生成画像、実際のコンポーネントプレビュー、または何も使わない方法を選んでください。
  • 偽のスクリーンショットに偽のバージョン情報を付けないでください。 「v0.6.2-rc.1」や「last sync 4s ago · main」などの表示には価値がなく、AIらしさが際立つだけです。

マーケティングコピーの兆候

  • ソーシャルプルーフの見出しに「Quietly in use at」や「Quietly trusted by」を使わないでください。 「Trusted by」、「Used at」、「Customers include」のような自然な表現を使うか、ロゴだけで伝わる場合は見出しを省いてください。
  • 引用、ブログ、サイドバーのセクションに「From the field」、「Field notes」、「Currently on the bench」、「On our desks」、「Loose plates」のような詩的なラベルを付けないでください。 職人気取りで気取った印象になります。「Testimonials」、「Latest writing」、「Now working on」のような機能的なラベルを使うか、省略してください。
  • 本文に「We respect the French ones」のような、謙虚さを装った業界への言及を入れないでください。 気取ったうえにAIらしい表現です。
  • 依頼内容が特定の場所、または異なるタイムゾーンに分散したスタジオを明示的に扱うものでない限り、ヘッダーやフッターに天気や地域の表示(「LIS 14:23 · 18°C」など)を入れないでください。
  • 小見出しの下に、メタ情報だけの短い文を置かないでください。 セクション見出しの下に「それぞれ、今日提供している機能であり、ロードマップ上の約束ではありません。意図的に短いリストにしています。」のような文を置くと、情報が散らかります。小見出し、見出し、本文だけで十分です。
  • 一般的な工程ラベルは禁止です。 「Stage 1 / Stage 2 / Stage 3」、「Step 1 / Step 2 / Step 3」、「Phase 01 / Phase 02 / Phase 03」、「Pass One / Pass Two / Pass Three」は使用できません。実際のステップ内容をラベルにしてください。工程を示す必要がある場合は、「Stage 1: Install」ではなく、「Install」、「Configure」、「Ship」のように動詞と目的語を直接使ってください。 ピル、ラベル、バージョンスタンプ
  • 画像の上に重ねるピル/ラベル/タグは禁止。 写真の上に Brand · 02、PLATE · BRAND、Field notes - journal のようなタグを載せる <span> オーバーレイは禁止です。画像を単独で見せるか、キャプションを(画像の外側の)すぐ下に追加してください。
  • 装飾としての写真クレジットキャプションは禁止。 ストック画像や picsum 画像の下にある Field study no. 12 · Ines Caetano、Plate 03 · House archive、Frame XII · 35mm のような文字列は気取っています。写真クレジットは、実在の写真に対して実在の撮影者をクレジットする場合(許可を得ている場合)にのみ許可されます。それ以外の場合は、キャプションを省略するか、1 行の機能的なキャプション(「The 6-quart, in Sage.」)を使用してください。
  • マーケティングページにバージョンフッターを置かない。 v1.4.2、Build 0048、last sync 4s ago · main のようなフッター文字列は CLI/開発ツールの備品であり、ランディングページのコンテンツではありません。マーケティング/ランディング/ポートフォリオページでは禁止です。
  • 装飾としての「Reservation 412 of 800」形式の在庫カウンターは禁止。 ブリーフが明示的に、実データを伴う数量限定のウェイトリストである場合にのみ許可されます。

装飾用テキストストリップ

  • ヒーロー下部の装飾用テキストストリップは禁止。 BRAND. MOTION. SPATIAL.、TYPE / FORM / MOTION、DESIGN · BUILD · SHIP、ESTD. 2018 · LISBON · BRAND. MOTION. SPATIAL. のようなパターンを、ヒーロー下部に小さなモノスペース大文字のストリップとして横切らせるのは、エージェンシーポートフォリオの定番です。デフォルトで禁止です。このストリップが実際の、ナビゲート可能なリンク(固定下部ナビ)または実際のステータス情報(Cookie バナー、ドキュメントサイトのビルド情報)を含む場合にのみ許容されます。
  • セクション見出しの右上に浮かぶサブテキストは禁止。 パターン:セクションに左寄せの巨大な見出しがあり、同じセクションヘッダーの右上隅に、他に明確に整列していない小さな説明段落が浮かんでいる。この浮遊要素が兆候です。サブテキストは見出しのすぐ下に置くか、すっきりした 2 カラムヘッダー(左:見出し、右:整列した本文)を構築してください。小さな隅の段落は不可です。

リスト、区切り線、スコアリング

  • 長いリスト/仕様表のすべての行に border-t + border-b を付けない。 どちらか一方(行間の下ボーダー、またはグループ上の上ボーダー)を選び、控えめに使用してください。各行の下にヘアラインが入った 10 行の仕様表は最も怠惰なレイアウトです - 代替の UI コンポーネントについてはセクション 4.9 を参照してください。
  • 比較ビジュアルとして、塗りつぶされた背景トラック付きのスコアリング/プログレスバーは禁止。 「X out of Y」の比較を示す必要がある場合は、数値 + 小さなアイコン、または背景トラックなしの小さなインラインバーを優先してください。大きな塗りつぶしの bg-zinc-200 トラックに部分的な塗りを重ねたものは、ランディングページ上のダッシュボード UI の雑然とした要素です。

ロケール、時刻、スクロールの合図

  • ロケール/都市名/時刻/天気のストリップは、99% のブリーフで禁止。 ヒーロー内の「Lisbon, working with founders」、フッター内の「1200-690 Lisbon, Portugal」、ナビ内の「Lisbon 14:23 · 18°C」。これらはエージェンシーポートフォリオの装飾的な兆候です。許可されるのは、ブリーフが明示的に、タイムゾーンに関連する業務を行うグローバル分散スタジオを説明している場合、旅行に焦点を当てたブランドの場合、または実在の物理的会場の場合のみです。フッターに連絡先住所を 1 回記載するのは問題ありませんが、雰囲気作りのロケールストリップは不可です。
  • スクロールの合図は禁止。 Scroll、↓ scroll、Scroll to explore、Scroll to walk through it、アニメーション付きマウスホイールアイコン。ユーザーがまだスクロールしていないなら、ヒーローを見ています。スクロールが何かは分かっています。ビューポートの下部にラベルは必要ありません。
  • デフォルトでは装飾的なステータスドットはゼロ。 ナビ項目の前、リスト行の前、バッジの前、ステータスラベルの前にある色付きのドットは兆候です。実際の意味のある状態(実際のサーバーステータスのライブインジケーター、ライブの可用性フラグ)を伝える場合にのみ許容され、1 ページセクションにつき 1 つに限定されます。
9.G EM-DASH 禁止(最も違反されやすい Tell)

エムダッシュ(—)は完全に禁止です。LLM 特有の文体上の癖であり、本番テストにおける視覚的な Tell の第 1 位です。「限定的な使用」や「自然言語での使用頻度」、「本文なら問題ない」といった例外はありません。例外は一切ありません。

  • 見出しでの使用は禁止です。 句点または読点を使ってください。
  • アイブロウ、ラベル、ピル、ボタンのテキスト、画像キャプション、ナビ項目での使用は禁止です。 改行、段組み、または細い区切り線に置き換えてください。
  • 本文での使用は禁止です。 文の構成を変えてください。句点で 2 文に分けるか、読点、括弧、またはコロンを使ってください。
  • 引用の著者表示での使用は禁止です。 通常のハイフンを前後に空白を入れて使う(-)か、改行して名前を細字で表示してください。
  • 区切り文字として使うエンダッシュ(–)も禁止です。 日付範囲(2018-2026)にはハイフンを使ってください。数値範囲(€40-80k)にもハイフンを使ってください。

ページ上で使用できるダッシュ文字は、次のものだけです。

  • 通常のハイフン -(複合語、範囲、マークアップの区切り線に使用)
  • 数学で使うマイナス記号(-5°C)

ユーザーに表示される出力に — または – が 1 つでも含まれている場合、Pre-Flight Check に失敗するため、書き直す必要があります。

このルールは譲れません。エージェントはこれまで「控えめに使う」という表現ではエムダッシュの制限を守れませんでした。ここでの表現は二者択一です。エムダッシュはゼロです。


10. 参考語彙(エージェントが知っておくべきパターン名)

これは語彙であり、ライブラリではありません。エージェントは、これらのパターン名を知り、それらについて伝え、デザイン時に考慮し、デザインの方向性に合う場合に採用できるようにしてください。実装とコード例は Block Library(セクション 12)にあり、段階的に追加されます。

ヒーローのパラダイム
  • 非対称分割ヒーロー - 片側にテキスト、反対側にアセットを配置し、ゆとりのある余白を設けます。
  • エディトリアル・マニフェスト・ヒーロー - 大きな文字を使い、アセットは配置せず、ポスターに近い見た目です。
  • ビデオ / メディアマスク・ヒーロー - 動画背景の上に、マスクとして切り抜いた文字を配置します。
  • キネティックタイプ・ヒーロー - アニメーションするタイポグラフィを主なビジュアルとして使います。
  • カーテンリビール・ヒーロー - スクロールに合わせて、カーテンのようにヒーローの各要素を表示します。
  • スクロール固定ヒーロー - コンテンツが背後をスクロールしている間、ヒーローを固定します。
ナビゲーションとメニュー
  • Mac OS Dock の拡大表示 - 画面端のナビゲーションで、ホバー時にアイコンが滑らかに拡大します。
  • マグネティックボタン - カーソルに向かって引き寄せられます。
  • グーイーメニュー - サブ項目が粘性のある液体のように分離します。
  • ダイナミックアイランド - ステータスやアラートを表示する、形状が変化するピルです。
  • コンテキスト対応のラジアルメニュー - クリックした位置で展開する円形メニューです。
  • フローティングスピードダイヤル - FAB が弧を描くように弾みながら、セカンダリアクションを表示します。
  • メガメニューリビール - 全画面のドロップダウンで、コンテンツを順にフェード表示します。
レイアウトとグリッド
  • 弁当グリッド - 非対称にタイルをまとめたレイアウト(Apple Control Center)。
  • メイソンリーレイアウト - 行の高さを固定せず、ずらして配置するグリッドです。
  • クロマグリッド - 境界線やタイルに、ほのかにアニメーションするグラデーションを適用します。
  • 分割画面スクロール - 2 つの領域が反対方向にスライドします。
  • スティッキースタックセクション - スクロールに合わせて固定され、積み重なるセクションです。
カードとコンテナ
  • パララックス傾斜カード - マウス座標を追跡して 3D 傾斜します。
  • スポットライト境界線カード - カーソルの下で境界線が光ります。
  • グラスモーフィズムパネル - 内部の屈折を伴う、すりガラスのようなパネルです。
  • ホログラフィックフォイルカード - ホバー時に虹色の光沢が変化します。
  • Tinder スワイプスタック - スワイプで払いのける、物理的なカードスタックです。
  • モーフィングモーダル - ボタンが展開して、それ自体がダイアログになります。
スクロールアニメーション
  • スティッキースクロールスタック - カードが固定され、実際に積み重なります。
  • 横スクロールの乗っ取り - 縦スクロールを横方向のパンに変換します。
  • ロコモーティブ / シーケンススクロール - 動画や 3D シーケンスをスクロールバーに連動させます。
  • ズームパララックス - スクロールに合わせて、中央の背景画像が拡大します。
  • スクロール進捗パス - スクロールに合わせて SVG の線を描画します。
  • リキッドスワイプトランジション - 粘性のある液体のようなページ遷移です。
ギャラリーとメディア
  • ドームギャラリー - 3D パノラマギャラリー。
  • カバーフローカルーセル - エッジを傾けた 3D カルーセル。
  • ドラッグしてパンするグリッド - 無限にドラッグできるキャンバス。
  • アコーディオン画像スライダー - ホバー時に広がる細長いストリップ。
  • ホバー画像トレイル - マウスの軌跡に沿って画像が次々と現れます。
  • 画像のグリッチエフェクト - ホバー時に RGB チャンネルがずれます。
タイポグラフィとテキスト
  • キネティックマーキー - スクロールに応じて反転する、終わりのないテキスト帯。
  • テキストマスクの表示 - 動画を映す透明な窓として、大きな文字を表示します。
  • テキストスクランブルエフェクト - 読み込み時/ホバー時にマトリックス風のデコードを行います。
  • 円形テキストパス - 回転する円に沿ってテキストを湾曲させます。
  • グラデーションストロークアニメーション - グラデーションが流れる、輪郭線だけのテキスト。
  • キネティックタイポグラフィグリッド - カーソルを避ける文字。
マイクロインタラクションとエフェクト
  • パーティクル爆発ボタン - 成功時に CTA が粒子となって砕けます。
  • 液体風のプルツーリフレッシュ - しずくが離れていくようなリロードインジケーター。
  • スケルトンのシマー - プレースホルダー上を光の反射が移動します。
  • 方向を認識するホバーボタン - カーソルがある方向から塗りつぶしが始まります。
  • クリックの波紋エフェクト - クリックした座標から波紋が広がります。
  • アニメーション SVG 線画 - ベクターがリアルタイムで自ら描画されます。
  • メッシュグラデーション背景 - 有機的なラバランプ状のブロブ。
  • レンズぼかしによる奥行き - 前景のアクションに集中できるよう、背景の UI をぼかします。
アニメーションライブラリの選択
  • Motion(motion/react) - UI/Bento/状態変化のモーションにデフォルトで使用します。
  • GSAP + ScrollTrigger - ページ全体のスクロール表現やスクロールの乗っ取りに使用します。useEffect のクリーンアップを行い、専用のリーフコンポーネント内に分離します。
  • Three.js / WebGL - キャンバス背景や 3D シーンに使用します。同じ分離ルールを適用します。
  • 同じコンポーネントツリー内で GSAP / Three.js と Motion を絶対に混在させないでください。 同じフレームを取り合います。

11. REDESIGN PROTOCOL

このスキルは新規構築とリデザインの両方に対応します。モードを誤って判断することが、リデザインの質を損なう最大の原因です。

11.A モードの検出(最初に行う)
  • 新規構築 - 既存サイトがない場合、または全面刷新が承認されている場合です。セクション 1 を基準に調整します。
  • リデザイン - 維持 - ブランドを損なわずに現代化します。まず監査を行い、ブランドトークンを抽出して、段階的に進化させます。
  • リデザイン - 全面刷新 - 既存コンテンツを維持しながら、新しいビジュアル言語を適用します。ビジュアル面では新規構築として扱い、コンテンツと IA は維持します。

曖昧な場合は、一度だけ尋ねます。「このリデザインでは既存のブランドを維持しますか。それともビジュアル面を一から作り直しますか?」

11.B 変更に着手する前に監査する

変更を提案する前に、現在の状態を記録します。

  • ブランドトークン - プライマリカラー/アクセントカラー、フォントスタック、ロゴの扱い、角丸。
  • 情報アーキテクチャ - ページツリー、主要ナビゲーション、主要なコンバージョン経路。
  • コンテンツブロック - 存在するもの、役割を果たしているもの、埋め草になっているもの。
  • 維持するパターン - 特徴的なインタラクション、印象的なヒーロー、コピーのトーン。
  • 廃止するパターン - AI スロップの兆候、崩れたレイアウト、リンク切れ、ありきたりなストック画像、パフォーマンス上の問題。
  • 既存サイトの調整値 - 現在の DESIGN_VARIANCE / MOTION_INTENSITY / VISUAL_DENSITY を推定します。これを出発点とし、基準値にはしません。
  • SEO の基準値 - 現在の検索順位上位ページ、メタタイトル、構造化データ、OG カード。SEO の移行はリデザインにおける最大のリスクです。
11.C 維持に関するルール
  • 依頼がない限り、情報アーキテクチャを変更しないでください。 SEO と操作の習慣を保つため、ページスラッグ、アンカー ID、主要ナビゲーションのラベルを維持します。
  • セクション 4.2 を適用する前に、ブランドカラーを抽出してください。 すでに紫色のブランドは紫色のままにし、LILA RULE の上書きを適用します。
  • 書き直しを依頼されない限り、コピーのトーンを維持してください。 ビジュアルの現代化は、コンテンツの書き直しとは異なります。
  • 既存のアクセシビリティ上の成果を尊重してください。 フォーカス状態、代替テキスト、キーボード操作、コントラストを後退させないでください。
  • 既存の分析イベントを尊重してください。 後続のトラッキングが依存するボタン、フォームフィールド、セクション ID の名前を変更しないでください。
11.D モダナイゼーションの手段(優先順位順)

順番に適用し、ブリーフの要件を満たした時点で終了します。

  1. タイポグラフィの刷新 - リスクあたりのビジュアル面での効果が最も大きい施策です。
  2. スペーシングとリズム - セクションのパディングを増やし、垂直方向のリズムを整えます。
  3. カラーの再調整 - 彩度を下げ、ニュートラルカラーを統一し、ブランドのアクセントカラーは維持します。
  4. モーションレイヤー - 既存のコンポーネントに、MOTION_INTENSITYに適したマイクロインタラクションを追加します。
  5. ヒーローと主要セクションの再構成 - Section 10の語彙を使用して、ファネル上部を再構成します。
  6. ブロックの全面置き換え - 既存のブロックを修復できない場合に限ります。
11.E 判断ツリー:部分的な進化か、全面的な再デザインか
  • IA、コンテンツ、SEOに問題がない → 部分的な進化(手段1〜4)。リスクの約40%で価値の約70%を実現できます。
  • ビジュアル上の負債が構造的(IAの破綻、デザインシステムがない、モバイル表示の破綻) → コンテンツを厳密に保持して全面的に再デザインします。
  • ブランド自体が変わる → グリーンフィールド。
11.F 確認なく変更してはならないもの

ユーザーの明示的な承認なしに、以下を変更してはなりません。

  • URL構造/ルートのスラッグ。
  • プライマリナビゲーションのラベル。
  • フォームフィールドの名前や順序(分析と自動入力に影響します)。
  • ブランドロゴまたはワードマーク。
  • 既存の法的文言/同意文言/Cookieに関する文言。

12. ブロックライブラリ(仕様 — 実装は段階的に追加)

リファレンス語彙(Section 10)ではパターンを定義します。ブロックライブラリでは、実際のプロパティ、実際のモーション仕様、実際のコードスケッチを使って実装します。

ステータス: スキーマはここで定義されています。ブロックは段階的に追加します。このスキーマに従わず、新しいブロックを独自に作成してはなりません。

12.A ファイルの場所
skills/taste-skill/blocks/
  hero/
    asymmetric-split.md
    editorial-manifesto.md
    kinetic-type.md
    ...
  feature/
    bento-grid.md
    sticky-scroll-stack.md
    zig-zag.md
    ...
  social-proof/
  pricing/
  cta/
  footer/
  navigation/
  portfolio/
  transition/
12.B 必須のフロントマター
---
name: asymmetric-split-hero
category: hero
dial_compatibility:
  variance: [6, 10]
  motion: [3, 10]
  density: [2, 5]
when_to_use: "Landing pages with one strong asset and one strong message. Default hero for SaaS, agency, premium consumer."
not_for: "Editorial / manifesto launches where the message IS the design."
stack: ["react", "next", "tailwind", "motion"]
---
12.C 必須の本文セクション
  1. ビジュアルスケッチ - レイアウトを簡潔なASCII図または説明で示します。
  2. Props API - コンポーネントのインターフェースです。
  3. コードスケッチ - 動作する最小限の実装(デフォルトはサーバーコンポーネント、モーションにはクライアントアイランドを使用)。
  4. モバイルでのフォールバック - < 768pxの場合の折りたたみルールを明示します。
  5. モーションのバリエーション - MOTION_INTENSITYの各レベル(1〜3、4〜7、8〜10)につき1つずつバリエーションを示します。動きを抑える場合のフォールバックも明示します。
  6. ダークモードに関する注意事項 - このブロックに固有のトークン戦略です。
  7. アンチパターン - このブロックでよくある問題の例です。
  8. 参考例 - 本番環境での実例へのリンクです。
12.D ブロックライブラリの規律
  • 1ファイルにつき1ブロックとします。複数ブロックを1ファイルにまとめてはなりません。
  • すべてのブロックは単独で動作しなければなりません(ページに配置すると描画されます)。
  • すべてのブロックはプレフライトチェック(Section 14)に合格しなければなりません。
  • Section 2.Aのデザインシステムに依存するブロックは、blocks/<category>/<name>--<system>.mdに配置します(例:feature/bento-grid--material.md)。

13. 対象外

このスキルは、以下を対象としていません。

  • ダッシュボード/情報密度の高い製品UI/管理パネル(Section 2.AのFluent、Carbon、Atlassian、またはPolarisを使用してください)。
  • データテーブル(TanStack TableまたはAG Gridを使用してください)。
  • 複数ステップのフォーム/ウィザード(フォーム固有のパターンを使用してください。このスキルでは改善できません)。
  • コードエディター(Monaco/CodeMirrorの公式スキンを使用してください)。
  • ネイティブモバイル(Apple HIG/Materialを直接使用してください)。
  • リアルタイムコラボレーションUI(プレゼンス、カーソル、OT対応。異なる種類の問題です)。

ブリーフが上記のいずれかに該当する場合は、その旨を明示して適切なツールを案内し、このスキルのマーケティングページ/会社概要ページ/ランディングページ向けの部分は、適用できる箇所にのみ使用してください。


14. 最終プレフライトチェック

コードを出力する前に、このマトリックスを実行してください。これが最後のフィルターです。

これは任意ではありません。すべての項目を実行してください。1つでも不合格なら、出力は未完成です。

  • 簡潔な推論が明示されていますか(セクション 0.B の一文)?
  • 各種ダイヤル値が明示され、概要に基づいて理由付けされていますか。基準値を黙って使っていませんか?
  • デザインシステムは該当する場合、セクション 2 から選ばれていますか。それとも美的スタイルが正直にラベル付けされていますか?
  • 再デザインモードが検出され、監査が実施されていますか(該当する場合、セクション 11)?
  • ページ内の em ダッシュ(—)は完全にゼロですか。 見出し、アイブロウ、ピル、本文、引用、帰属表示、キャプション、ボタン、代替テキストのすべてが対象です。ゼロです。(セクション 9.G、必須事項)
  • ページテーマの固定:ページ全体でテーマは 1 つ(ライト、ダーク、または自動)ですか。ページの途中でセクションが反転モードに切り替わっていませんか(セクション 4.11)?
  • 色の一貫性の固定:すべてのセクションで、同じアクセントカラーを同じように使用していますか(セクション 4.2)?
  • 形状の一貫性の固定:1 つの角丸システムを一貫して適用していますか(セクション 4.4)?
  • ボタンのコントラスト確認:すべての CTA テキストは背景に対して読みやすいですか(白地に白文字がなく、WCAG AA のコントラスト比 4.5:1 を満たしていますか)?
  • CTA ボタンの折り返し:デスクトップで CTA のラベルが 2 行以上に折り返されていませんか?
  • フォームのコントラスト確認:フォームの入力欄、プレースホルダー、フォーカスリング、ラベルは、セクションの背景に対してすべて WCAG AA を満たしていますか?
  • セリフ体の使い方:セリフ体を使用する場合、Fraunces または Instrument_Serif は使っていませんか(使っている場合は、ブランド上の明確な根拠がありますか)? 前のプロジェクトとは異なるセリフ体を使っていますか?
  • プレミアム消費者向けパレットの確認:概要がプレミアム消費者向け(調理器具/ウェルネス/職人製品/高級品)の場合、AI でよく使われるベージュ+ブラス+オックスブラッド+エスプレッソ系の配色ではありませんか? 前のプレミアム消費者向けプロジェクトとは異なる系統ですか?
  • イタリック体のディセンダー余白:y g j p q を含むイタリック体の単語すべてに、最低限 leading-[1.1] と余白用の pb-1 を設定していますか?
  • ヒーローがビューポート内に収まっていますか:見出しは 2 行以内、補足テキストは 20 語以内かつ 4 行以内、CTA はスクロールせずに表示され、画像に合わせてフォントサイズを計画していますか?
  • ヒーローの上部パディング:デスクトップで最大 pt-24 ですか。ヒーローのコンテンツがビューポートの途中に浮いていませんか?
  • ヒーローの要素数の節度:ヒーロー内のテキスト要素は最大 4 つ(アイブロウまたはブランド帯、見出し、補足テキスト、CTA)ですか? CTA の下に小さなタグラインを置いたり、ヒーロー内に信頼性を示す極小の帯を置いたりしていませんか?
  • アイブロウ数(機械的確認):すべてのコンポーネントで、セクション見出しの上にある uppercase tracking のマイクロラベルの数を数えましたか。合計は ceil(sectionCount / 3) 以下ですか? ヒーローも 1 つとして数えます。
  • 分割ヘッダーの禁止:セクション見出しに「左側に大きな見出し+右側に小さな説明文」のパターンを使わず、縦に積み重ねていますか?
  • ジグザグ交互配置の上限:同じ画像+テキストの分割レイアウトが 3 セクション以上連続していませんか?
  • CTA の意図の重複なし:同じ意図の CTA が 2 つありませんか(「お問い合わせ」と「お話ししましょう」の両方がページにある場合は不合格)?
  • ロゴウォールはロゴのみ:ロゴの下に業界やカテゴリーのラベルを印字していませんか?
  • ベントー背景の多様性:少なくとも 2〜3 個のベントーセルに、実際の視覚的な変化(画像、グラデーション、パターン)がありますか。白地に白いテキストカードばかりになっていませんか?
  • 「導入企業/信頼されている企業」のロゴウォールはヒーロー内ではなくヒーローの下にあり、プレーンテキストのワードマークではなく、実際の SVG ロゴ(Simple Icons/devicon)または生成した SVG マークを使っていますか?
  • コピーのセルフ監査:表示される文字列をすべて読み返し、文法が崩れた表現や AI が捏造したようなフレーズ(「free on its past」のようなもの)を公開していませんか?
  • 動きに理由がありますか:すべてのアニメーションについて、(階層/ストーリーテリング/フィードバック/状態遷移)のいずれかを使って一文で正当化できますか。見せるためだけの GSAP を使っていませんか?
  • マーキーはページごとに最大 1 つ:同じページに横方向のマーキーが 2 つありませんか?
  • ナビゲーションはデスクトップで 1 行に収まり、高さは 80px 以下ですか?
  • セクションレイアウトの反復を確認しましたか:同じレイアウト系統を共有するセクションが 2 つありませんか(8 セクションで少なくとも 4 種類の系統)?
  • ベントーにリズムがあり、セル数が正確ですか(項目数 N 個ならセルも N 個。途中や末尾に空のセルはありませんか)?
  • 長いリストに適切な UI コンポーネントを使用していますか(5 項目を超える場合、デフォルトの <ul> と divide-y を使っていませんか。代替案はセクション 4.9 を参照)?
  • 実際の画像を使用していますか(まず生成ツール、次に Picsum-seed、最後に明示的なプレースホルダー枠)。div ベースの偽スクリーンショット、手作りの装飾 SVG、テキストだけのミニマリズムは使っていませんか?
  • 画像にピルやラベルを重ねていませんか(Plate · Brand、Field notes - journal など)?
  • 写真クレジットのキャプションを装飾として使っていませんか(Field study no. 12 · Ines Caetano など)?
  • マーケティングページにバージョン表記を含むフッターがありませんか(v1.4.2、Build 0048 など)?
  • アイブロウの下にマイクロメタ文を置いていませんか(「これらはすべて、現在提供している機能です……」など)?
  • ヒーロー下部に装飾的なテキスト帯を置いていませんか(BRAND. MOTION. SPATIAL. など)?
  • セクション見出しの右上に浮かぶ補足テキストを置いていませんか?
  • 比較ビジュアルに塗りつぶされた背景トラック付きのスコアバー/進捗バーを使っていませんか?
  • 概要が本当にグローバル展開または特定の場所を重視するものでない限り、ロケール/都市名/時刻/天気の帯を置いていませんか?
  • スクロールを促す表示を置いていませんか(Scroll、↓ scroll、Scroll to explore など)?
  • 概要がローンチに関するものでない限り、ヒーローにバージョンラベルを置いていませんか(V0.6、BETA、INVITE-ONLY など)?
  • セクション番号付きのアイブロウを置いていませんか(00 / INDEX、001 · Capabilities、06 · how it works など)?
  • 装飾的なドットはありませんか(実際の意味を持つ状態表示に使う場合を除き、デフォルトではゼロ)?
  • 長いリスト/仕様表のすべての行に border-t と border-b を付けていませんか?
  • コンテンツの密度は適切ですか:20 行のデータ表や、根拠のない精密な仕様がなく、補足段落はデフォルトで 25 語以内ですか?
  • 引用は本文 3 行以内で、帰属表示は簡潔ですか(em ダッシュなし)?
  • 主張した動きが実際に表示されていますか:MOTION_INTENSITY > 4 の場合、そう主張するだけでなく、ページ上で実際にアニメーションしていますか?
  • GSAP のスティッキースタック/横方向パンは、セクション 5.A/5.B の標準スケルトン(start: "top top"、pin: true、適切な scrub)に従って実装されていますか?
  • window.addEventListener('scroll') を使っていませんか。Motion の useScroll()/ScrollTrigger/IntersectionObserver/CSS のスクロール駆動アニメーションだけを使っていますか?
  • MOTION_INTENSITY > 3 のすべての動きに、視差効果の軽減設定を適用していますか?
  • ダークモードのトークンを定義し、両方のモードでテストしていますか?
  • モバイルでの折りたたみを明示していますか(変動の大きいレイアウトには w-full、px-4、max-w-7xl mx-auto)?
  • ビューポートの安定性:min-h-[100dvh] を使い、h-screen は使っていませんか?
  • useEffect のアニメーションに厳密なクリーンアップ関数がありますか?
  • 空/読み込み中/エラーの各状態を用意していますか?
  • 可能な箇所ではカードを省き、余白を活用していますか?
  • アイコンは許可されたライブラリ(Phosphor/HugeIcons/Radix/Tabler)のみを使っていますか。SVG パスを手作りしていませんか?
  • 動きはクライアント側のリーフコンポーネントに分離し、ファイル先頭に 'use client' を置いてメモ化していますか?
  • セクション 9 に挙げられた AI らしさがありませんか(デフォルトの Inter、AI パープル、同じ大きさのカード 3 枚、Jane Doe、Acme、「Quietly in use at」など)?
  • Core Web Vitals の目標を達成できそうですか(LCP < 2.5s、INP < 200ms、CLS < 0.1)?
  • プロジェクトごとにデザインシステムは 1 つですか(Material と shadcn を混在させていませんか)? チェックボックスを 1 つでも正直にオンにできない場合、このページは完成していません。納品前に修正してください。

付録 - 実際のソースに基づく参考資料

以下のセクションは、同梱された参考コンテンツです。セクション 2 で指定されている各デザインシステムについて、実際のインストールコマンド、正式なドキュメントへのリンク、動作するスタータースニペットを提供します。トレーニングデータ上の架空の情報ではなく、本番環境の実情に基づいて判断してください。

付録 A - デザインシステムごとのインストールコマンド

# Material Web (Material 3)
npm install @material/web

# Fluent UI React (v9)
npm install @fluentui/react-components

# Fluent UI Web Components (framework-free)
npm install @fluentui/web-components @fluentui/tokens

# IBM Carbon
npm install @carbon/react @carbon/styles

# Radix Themes
npm install @radix-ui/themes

# shadcn/ui (open code, owned components)
npx shadcn@latest init
npx shadcn@latest add button card badge separator input

# Primer CSS (GitHub product/devtool UI)
npm install --save @primer/css

# Primer Brand (GitHub marketing UI)
npm install @primer/react-brand

# GOV.UK Frontend
npm install govuk-frontend

# USWDS (US Web Design System)
npm install uswds

# Atlassian Design System (Atlaskit)
yarn add @atlaskit/css-reset @atlaskit/tokens @atlaskit/button @atlaskit/badge @atlaskit/section-message @atlaskit/card

# Bootstrap 5.3
npm install bootstrap

# Shopify Polaris Web Components (Shopify apps only)
# Add this to your app HTML head:
#   <meta name="shopify-api-key" content="%SHOPIFY_API_KEY%" />
#   <script src="https://cdn.shopify.com/shopifycloud/polaris.js"></script>

付録 B - 正式な情報源(独自に考案する前に確認してください)

Material Web
Fluent UI
Carbon
Shopify Polaris
Atlassian
Primer
GOV.UK
USWDS
Bootstrap
Tailwind
Radix
shadcn/ui
ネイティブ CSS / W3C 標準
Apple Liquid Glass(Apple プラットフォームのみ)

付録 C - Apple Liquid Glass:誠実な Web 向け近似

無作為な CSS スニペットを Apple Liquid Glass の公式なものとして扱わないでください。

公式に該当するもの

Apple は、Apple プラットフォーム向けの Human Interface Guidelines と Developer Documentation で Liquid Glass を説明しています。Liquid Glass は、Apple プラットフォームの UI 全体で使われる動的なマテリアルです。Apple によるネイティブ実装は Apple プラットフォームの API とシステムコンポーネントに属しており、一般的な Web 用の公開 CSS パッケージではありません。

関連する公式ドキュメント:

  • Apple Human Interface Guidelines → マテリアル
  • Apple Developer Documentation → Liquid Glass
  • Apple Developer Documentation → Liquid Glass の採用
  • SwiftUI → マテリアル
公式ではないもの

Apple が通常の Web サイト向けに提供している liquid-glass.css はありません。

Web で近似するには、以下を使用できます。

  • backdrop-filter
  • 透明な背景
  • 複数レイヤーの境界線
  • ハイライトのオーバーレイ
  • グラデーション
  • 動き
  • コントラストを確保するフォールバック

ただし、これはWeb のグラスモーフィズム/すりガラスの近似表現であり、Apple 公式の Liquid Glass ではありません。コメントでそのように明記してください。

より安全な Web 向け近似表現のスケルトン
.liquid-glass-web-approx {
  position: relative;
  isolation: isolate;
  overflow: hidden;
  border-radius: 999px;
  border: 1px solid rgb(255 255 255 / .32);
  background:
    linear-gradient(135deg, rgb(255 255 255 / .30), rgb(255 255 255 / .08)),
    rgb(255 255 255 / .12);
  backdrop-filter: blur(24px) saturate(180%) contrast(1.05);
  -webkit-backdrop-filter: blur(24px) saturate(180%) contrast(1.05);
  box-shadow:
    inset 0 1px 0 rgb(255 255 255 / .48),
    inset 0 -1px 0 rgb(255 255 255 / .12),
    0 18px 60px rgb(0 0 0 / .18);
}

.liquid-glass-web-approx::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  border-radius: inherit;
  background:
    radial-gradient(circle at 20% 0%, rgb(255 255 255 / .55), transparent 34%),
    linear-gradient(90deg, rgb(255 255 255 / .18), transparent 42%, rgb(255 255 255 / .14));
  pointer-events: none;
}

.liquid-glass-web-approx::after {
  content: "";
  position: absolute;
  inset: 1px;
  border-radius: inherit;
  border: 1px solid rgb(255 255 255 / .14);
  pointer-events: none;
}

@media (prefers-color-scheme: dark) {
  .liquid-glass-web-approx {
    border-color: rgb(255 255 255 / .18);
    background:
      linear-gradient(135deg, rgb(255 255 255 / .16), rgb(255 255 255 / .04)),
      rgb(15 23 42 / .42);
    box-shadow:
      inset 0 1px 0 rgb(255 255 255 / .22),
      0 18px 60px rgb(0 0 0 / .42);
  }
}

@media (prefers-reduced-transparency: reduce) {
  .liquid-glass-web-approx {
    background: rgb(255 255 255 / .96);
    backdrop-filter: none;
    -webkit-backdrop-filter: none;
  }
}

重要: prefers-reduced-transparency のブラウザー対応にはばらつきがあるため、テストしてください。ぼかしがなくても十分なコントラストを必ず確保してください。


付録は以上です。 上記のインストールコマンドは実際の状況を確認するための基準です。Apple Liquid Glass のスケルトンは、Apple が提供するパッケージではなく、近似表現であることを明記したものです。デザインシステムごとの正式なドキュメントは、そのシステムの公式ドキュメント(第 2 節および付録 B のリンク)を参照してください。

コメント