design-taste-frontend

Name: design-taste-frontend
Author: nexu-io

github.com/nexu-ioデザイン・UI104.6k2.7k 回インストール1 日前に更新

リポジトリ

design-taste-frontend について

ランディングページ、ポートフォリオ、リデザイン向けのフロントエンド設計スキルです。コーディングエージェントが要件に合う表現を選び、画一的なデザインを避ける指針を示します。

主な機能

01ページ種別・対象者・制約の把握
02一文でデザイン方針を提示
03変化度・動き・密度の調整
04デザインシステムと実装方法の提案
05レスポンシブ・文字・コンポーネントの規則

活用シーン

01要件に沿った SaaS ランディングページの企画
02デザイナーや開発者のポートフォリオ制作
03ブランド素材を保ったウェブサイトの刷新

インストール

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

$npx skills add https://github.com/nexu-io/open-design --skill design-taste-frontend

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

同梱ファイルLICENSE

詳細

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

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

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

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

0.A まず次のシグナルを読み取る

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

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 ダイヤルの推論（デザインの読み取り → ダイヤルの値）

シグナル	VARIANCE	MOTION	DENSITY
「ミニマリスト / クリーン / 落ち着き / エディトリアル / Linear 風」	5-6	3-4	2-3
「プレミアム消費者向け / Apple っぽい / ラグジュアリー / ブランド」	7-8	5-7	3-4
「遊び心 / ワイルド / Dribbble / Awwwards / 実験的 / エージェンシー」	9-10	8-10	3-4
「ランディングページ / ポートフォリオ / マーケティングサイト（デフォルト）」	7-9	6-8	3-5
「信頼第一 / 公共部門 / 規制対象 / アクセシビリティ重視」	3-4	2-3	4-5
「リデザイン - 維持」	既存に合わせる	+1	既存に合わせる
「リデザイン - 大幅刷新」	+2	+2	既存に合わせる

1.B ユースケース別プリセット

ユースケース	VARIANCE	MOTION	DENSITY
ランディング（SaaS、一般向け）	7	6	4
ランディング（エージェンシー / クリエイティブ）	9	8	3
ランディング（プレミアム消費者向け）	7	6	3
ポートフォリオ（デザイナー / スタジオ）	8	7	3
ポートフォリオ（開発者）	6	5	4
エディトリアル / ブログ	6	4	3
公共部門のサービス	3	2	5
リデザイン - 維持	既存に合わせる	既存+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 React	Shopify 管理 UI では必須
Atlassian / Jira 風のプロダクト	`@atlaskit/*` + `@atlaskit/tokens`	公式 Atlassian DS
GitHub 風の開発ツール / コミュニティページ	`@primer/css` または `@primer/react-brand`	公式 Primer。マーケティングには Brand バリアント
英国公共部門のサービス	`govuk-frontend`	法的・規制的に期待される
米国公共部門 / 信頼第一	`uswds`	同上
スピード重視の地元ビジネス / エージェンシー MVP	Bootstrap 5.3	地味だが速く、動く
モダンでアクセシブルな React 基盤	`@radix-ui/themes`	プリミティブ + 洗練されたテーマ
コンポーネントを自社で所有するモダン SaaS	shadcn/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 Glass	Apple はこれを 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 を使ったテキストだけのページは、手抜きです。

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

まず画像生成ツールを使います。 環境内で画像生成ツール（generate_image、MCP 画像ツール、IDE 統合型生成ツール、OpenAI 画像ツールなど）が少しでも利用できる場合は、必ず使って、セクションに合わせたアセットを作成してください。ヒーロー画像、プロダクト写真、テクスチャ背景、ムード画像などを生成します。セクションに合ったアスペクト比にしてください。手書きの CSS のほうが速そうだからといって、この手順を省略してはいけません。
次に実際のウェブ画像を使います。 画像生成ツールを利用できない場合は、実際の写真ソースを使ってください。使用可能なデフォルト：
- プレースホルダー用の写真には https://picsum.photos/seed/{descriptive-seed}/{w}/{h} を使用します（シードにはセクションを表す説明を含めてください。例：marrow-cookware-kitchen）。
- ブリーフに指定されている場合は、実際のストック画像またはブランドの URL を使います。
- 明示的に許可されている場合は、オープンライセンスのソース（直接 URL での Unsplash、Pexels）を使います。
最後の手段として、ユーザーに伝えます。 どちらも利用できない場合は、ページを手書き 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 スティッキースタック - 標準的なひな形

"use client";
import { useRef, useEffect } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function StickyStack({ cards }: { cards: React.ReactNode[] }) {
  const ref = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();

  useEffect(() => {
    if (reduce || !ref.current) return;
    const ctx = gsap.context(() => {
      const cardEls = gsap.utils.toArray<HTMLElement>(".stack-card");
      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,
        });
        gsap.to(card, {
          scale: 0.92,
          opacity: 0.55,
          ease: "none",
          scrollTrigger: {
            trigger: cardEls[i + 1],
            start: "top bottom",
            end: "top top",
            scrub: true,
          },
        });
      });
    }, ref);
    return () => ctx.revert();
  }, [reduce]);

  return (
    <div ref={ref} className="relative">
      {cards.map((card, i) => (
        <div
          key={i}
          className="stack-card sticky top-0 min-h-[100dvh] flex items-center justify-center"
        >
          {card}
        </div>
      ))}
    </div>
  );
}

重要なポイント：start: "top top"、pin: true、最後以外の各カードをピン留めし、拡大縮小／不透明度のトランスフォームは次のカードのスクロールトリガーによって制御します（次のカードが現れるにつれて、前のカードが縮小します）。

5.B 水平パン - 標準的なひな形

"use client";
import { useRef, useEffect } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

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

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

  return (
    <section ref={wrap} className="relative overflow-hidden">
      <div ref={track} className="flex h-[100dvh] items-center">
        {children}
      </div>
    </section>
  );
}

重要なポイント：start: "top top"、pin: true、end: "+=${distance}"（スクロール距離＝水平方向の移動に必要な距離）、scrub: 1。ラッパーをピン留めし、ユーザーが縦にスクロールするにつれて内側のトラックが水平方向にスライドします。

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 の state で window.scrollY を使ってスクロール進捗を独自に計算すること。同じ理由で、フレームごとに再レンダリングが発生します。
React の state を更新する requestAnimationFrame ループ。代わりにモーション値（useMotionValue + useTransform）を使用してください。
レイアウトトランジション： 表示状態の変化（リストの並べ替え、モーダルの展開、ルート間で共有する要素）には Motion の layout と layoutId props を使用してください。「念のため」という理由で静的コンテンツを layout props で囲まないでください。計測処理のコストがかかります。
段階的な表示のオーケストレーション： 表示の順序が重要な場合は、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.5s。ヒーロー画像には 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: all 0.3s cubic-bezier(0.16, 1, 0.3, 1)。読み込み時に表示する要素には、連鎖的に animation-delay を設定します。transform と opacity を重視します。
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（日常的なアプリ）： 標準的なウェブアプリの間隔（py-16～py-24）。
8～10（コックピット）： パディングを詰めます。カードボックスは使わず、1px の線でデータを区切ります。必須：すべての数値に font-mono を使います。

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

デフォルトではデュアルモードです。印刷物を模したエディトリアルデザインでない限り、ライトモード専用だと決めつけないでください。

8.A トークン戦略（いずれかを選び、統一する）

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」ではなく、文脈に合った、上質で実在感のある名前を考案してください。
中身のない動詞は禁止です。 「Elevate」「Seamless」「Unleash」「Next-Gen」「Revolutionize」ではなく、具体的な動詞を使ってください。

9.E 外部リソースとコンポーネント

手作りの SVG アイコンは禁止です。 Phosphor／HugeIcons／Radix／Tabler を使ってください。明示的なリクエストがある場合に限り、Lucide を使えます。
装飾用の SVG を手作りすることは、デフォルトでは強く推奨されません（セクション 4.8 を参照）。
<div> を使った偽のスクリーンショットは禁止です。 スクリーンショットを模して、<div> の四角形で偽の製品 UI を作ることは絶対に避けてください。実際の画像、生成画像を使うか、プレビューを省略してください。
リンク切れの Unsplash URL は禁止です。 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行につき最大1つです。何にでも使うデフォルトの区切り文字（「foo · bar · baz · qux · quux」など）にしないでください。区切りを設ける必要がある場合は、改行、細い罫線、列を使ってください。
リスト、ナビゲーション、バッジのすべてに装飾用の色付きステータスドットを付けるのは禁止です。 「ONE Q4 SLOT OPEN」の前、すべてのナビゲーションリンクの前、すべてのタスク行の前に色付きドットを置くことは、デフォルトで禁止です。ドットがサーバーの状態や利用可否など実際の意味を表し、控えめに使われている場合に限り、使用できます。 ダッシュとタイポグラフィ上の装飾
デザイン要素としても、それ以外の場所でも、em ダッシュ（—）は使用しないでください。 完全かつ例外のない禁止事項については、以下のセクション 9.G を参照してください。見出し、アイブロウ、ピル、本文、引用、帰属表示、キャプション、ボタンのテキスト、代替テキストで、em ダッシュ文字を使うことは禁止されています。通常のハイフン（-）を使用してください。
<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 らしさを強く感じさせます。

マーケティングコピーで 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」などを置くのは気取った印象になります。写真クレジットを記載してよいのは、許可を得た実際の写真について、実際の撮影者をクレジットする場合に限ります。それ以外の場合は、キャプションを省くか、「Sage の 6 クォートモデル。」のような、機能的で簡潔なキャプションを 1 行で記載してください。
マーケティングページにバージョン情報フッターを置かないでください。 「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を参照してください。
比較表示に、塗りつぶした背景トラックのあるスコアバーや進捗バーを使わないでください。 「YのうちX」の比較を表示する場合は、数値と小さなアイコンを使うか、背景トラックのない小さなインラインバーを使ってください。部分的な塗りつぶしを重ねた大きな 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つまでです。

9.G EMダッシュ禁止（最もよく見抜かれる要素）

EMダッシュ（—）は完全に禁止です。 これはLLMが多用する文体上の癖であり、制作物で最も目につく要素です。「使用は控えめに」「自然な文章の範囲ならよい」「本文なら問題ない」といった例外は一切ありません。

見出しでの使用は禁止です。 ピリオドかコンマを使ってください。
アイブロウ、ラベル、ピル、ボタンのテキスト、画像キャプション、ナビゲーション項目での使用は禁止です。 改行、列、細い罫線で置き換えてください。
本文での使用は禁止です。 文を組み直してください。ピリオドで2文に分けるか、コンマ、括弧、コロンを使ってください。
引用の出典表記での使用は禁止です。 通常のハイフンを前後にスペースを入れて使う（-）か、改行して名前を小さめのウェイトで表示してください。
区切りとして使うエンダッシュ（–）も禁止です。 日付の範囲（2018-2026）にはハイフンを使ってください。数値の範囲（€40-80k）にもハイフンを使ってください。

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

通常のハイフン -（複合語、範囲、マークアップの区切り線に使用）
数式のマイナス記号（-5°C）

ユーザーに見える出力に — または – が1文字でも含まれていると、出力は事前チェックに不合格となり、書き直す必要があります。

このルールに例外はありません。これまでもエージェントは「控えめに使う」と表現すると、EMダッシュの制限を無視してきました。ここでは二者択一のルールです。EMダッシュは一切使えません。

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

これは語彙集であり、ライブラリではありません。エージェントは、これらのパターン名を把握し、それらについて意思疎通し、設計時に考慮し、設計の読み解きで必要と判断したときに活用できるようにしておく必要があります。実装とコードスケッチはブロックライブラリ（セクション 12）にあり、反復的に追加されます。

ヒーローのパラダイム

非対称分割ヒーロー - 片側にテキスト、もう片側にアセットを配置し、広い余白を設けます。
エディトリアル・マニフェスト・ヒーロー - 大きな文字を使い、アセットは配置せず、ポスターに近い見せ方にします。
ビデオ／メディアマスク・ヒーロー - ビデオ背景の上に、マスクとして文字を切り抜いて表示します。
キネティックタイプ・ヒーロー - アニメーションするタイポグラフィを主役のビジュアルにします。
カーテンリビール・ヒーロー - スクロール時に、カーテンのようにヒーローの各パーツを表示します。
スクロール固定ヒーロー - コンテンツが背後でスクロールしている間、ヒーローを固定します。

ナビゲーションとメニュー

Mac OS Dock の拡大表示 - 画面端にナビゲーションを配置し、ホバー時にアイコンを滑らかに拡大します。
マグネティックボタン - カーソルに向かって引き寄せられます。
グーメニュー - サブ項目が粘性のある液体のように離れていきます。
Dynamic Island - ステータスやアラートを表示する、形状が変化するピル型 UI です。
コンテキスト対応ラジアルメニュー - クリックした位置から円形メニューが展開します。
フローティング・スピードダイヤル - FAB から、曲線状に並ぶ二次アクションがバネのように展開します。
メガメニューの表示 - 全画面のドロップダウンで、コンテンツを段階的にフェードインさせます。

レイアウトとグリッド

弁当箱グリッド - 非対称なタイルのグループ化です（Apple Control Center）。
メイソンリーレイアウト - 行の高さを固定せず、段違いに配置するグリッドです。
クロマグリッド - 控えめなアニメーション付きグラデーションを使った境界線やタイルです。
分割画面スクロール - 2 つの領域が反対方向にスライドします。
スティッキースタック・セクション - スクロール時にセクションを固定し、積み重ねます。

カードとコンテナー

視差チルトカード - マウス座標を追跡して 3D 傾斜します。
スポットライト境界線カード - カーソルの下で境界線が光ります。
グラスモーフィズムパネル - 内部で屈折するすりガラスです。
ホログラフィック・フォイルカード - ホバー時に虹色が変化します。
Tinder スワイプスタック - カードを物理的に積み重ね、スワイプして取り除きます。
変形モーダル - ボタンが展開して、それ自体がダイアログになります。

スクロールアニメーション

スティッキースクロールスタック - カードを固定し、物理的に積み重ねます。
横スクロールへの変換 - 縦スクロールを横方向のパンに変換します。
Locomotive／シーケンススクロール - スクロールバーに連動したビデオや 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. 再設計プロトコル

このスキルは、新規構築と再設計の両方に対応します。モードを誤って判断することが、再設計の成果物が低品質になる最大の原因です。

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 現代化の手段（優先順位順）

順番に適用し、依頼が満たされた時点で終了します。

タイポグラフィの刷新 - リスクあたりのビジュアル改善効果が最も大きい手段です。
余白とリズム - セクションのパディングを増やし、縦方向のリズムを整えます。
色の再調整 - 彩度を下げ、ニュートラルカラーを統一し、ブランドアクセントは維持します。
モーションレイヤー - 既存のコンポーネントに、MOTION_INTENSITY に応じたマイクロインタラクションを追加します。
ヒーローと主要セクションの再構成 - セクション10の用語を使って、ファネル上部の構成を見直します。
ブロック全体の置き換え - 既存のブロックを修復できない場合に限ります。

11.E 意思決定ツリー：部分的な進化か全面再設計か

IA、コンテンツ、SEOに問題がない → 部分的な進化（手段1～4）。約40％のリスクで、価値の約70％を実現できます。
ビジュアル上の負債が構造的（IAの破綻、デザインシステムがない、モバイル表示の破綻） → コンテンツを厳格に維持して全面再設計します。
ブランド自体が変わる → 新規構築。

11.F 明示的な承認なしに変更してはならないもの

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

URL構造／ルートスラッグ。
プライマリナビゲーションのラベル。
フォームフィールドの名前や順序（分析機能と自動入力が壊れます）。
ブランドロゴまたはワードマーク。
既存の法的事項／同意／Cookieに関する文言。

12. ブロックライブラリ（契約 - 実装は段階的に追加）

参照用語集（セクション 10）ではパターンを定義しています。ブロックライブラリでは、実際の props、実際のモーション仕様、実際のコードスケッチを用いてそれらを実装します。

**ステータス：**スキーマはここで定義しています。ブロックは段階的に追加します。このスキーマに従わずに、新しいブロックを独自に追加しないでください。

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 必須の Frontmatter

---
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 必須の本文セクション

ビジュアルスケッチ - レイアウトの簡単な ASCII 図、または説明。
Props API - コンポーネントのインターフェース。
コードスケッチ - 最小限の動作する実装（デフォルトはサーバーコンポーネント、モーションにはクライアントアイランド）。
モバイル向けフォールバック - < 768px に対する明示的な折りたたみルール。
モーションのバリアント - MOTION_INTENSITY の各帯域（1-3、4-7、8-10）につき 1 つのバリアント。モーション低減時のフォールバックを明示します。
ダークモードに関する注意事項 - このブロックに固有のトークン戦略。
アンチパターン - このブロックでよくある失敗例。
参考資料 - 実際の本番環境での例へのリンク。

12.D ブロックライブラリの規律

1 ファイルにつき 1 ブロック。複数のブロックを 1 つのファイルにまとめないでください。
すべてのブロックは単独で動作する必要があります（ページに配置するとレンダリングされます）。
すべてのブロックは Pre-Flight Check（セクション 14）に合格する必要があります。
セクション 2.A のデザインシステムに依存するブロックは、blocks/<category>/<name>--<system>.md の下に配置します（例：feature/bento-grid--material.md）。

13. 対象外

このスキルは、次の用途には対応していません。

ダッシュボード／情報量の多いプロダクト UI／管理パネル（セクション 2.A の Fluent、Carbon、Atlassian、または Polaris を使用してください）。
データテーブル（TanStack Table または AG Grid を使用してください）。
複数ステップのフォーム／ウィザード（フォーム固有のパターンを使用してください。このスキルでは改善できません）。
コードエディター（公式のスキンを備えた Monaco／CodeMirror を使用してください）。
ネイティブモバイル（Apple HIG／Material を直接使用してください）。
リアルタイムコラボレーション UI（プレゼンス、カーソル、OT 対応 - 異なる問題領域です）。

依頼内容が上記のいずれかに該当する場合は、その旨を明示して適切なツールを提示し、このスキルのマーケティングページ／概要ページ／ランディングページ向けの部分のみ、該当する画面に適用してください。

14. 最終事前チェック

コードを出力する前に、このチェック表を実行してください。これが最後の確認です。

これは必須です。すべての項目を確認してください。いずれかの項目に不合格なら、出力は未完成です。

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

以下のセクションは、同梱された参考コンテンツです。セクション 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 が通常の 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 のリンク）を参照してください。

Markdown 対応

ログインしてコメント

基本情報

作者: nexu-io
リポジトリ: nexu-io/open-design
カテゴリ: デザイン・UI
インストール数: 2,708
GitHub スター: 104,635

問題を報告