ui-ux-kit

UI/UX キット

意図が伝わり、ブランドに固有のインターフェースをデザインします。テンプレートのような見た目にはせず、今後作成するすべてのページの一貫性を保つ唯一の信頼できる情報源（DESIGN_SYSTEM.md）を残します。マーケティング、ダッシュボード、アプリ、ストア、コンテンツ／ドキュメント、モバイル、リデザイン、独立したデザインシステムなど、あらゆる画面に対応します。

手順は順番どおりに進めてください。譲れない手順が4つあります。

• Step 1 routing — ひとつのレシピを使うのではなく、適切なルールを適用します。
• Step 2.7 concept — 作成を始める前に、独自性のあるアイデアをひとつ決めます。
• Step 4.5 adversarial review — 作者ではなく批評家として成果物を評価します。
• Step 5 documentation — 必ず DESIGN_SYSTEM.md を残します。

最優先の原則はひとつです。要件を読み、それに合わせて調整してください。 すべてのルールは賢明なデフォルトであり、反射的に適用するものではありません。要件がデフォルトと矛盾する場合は、要件を優先し、その旨を伝えて進めてください。

このファイルは常に読み込まれるコアです。詳細な情報は references/ にあり、必要に応じて読み込みます。

• references/surface-rules.md — 画面ごとのルール（ランディングページ、ダッシュボード、アプリ、モバイル、ストア、コンテンツ）。作成を始める前に、Step 1 で選んだプロファイルのセクションを読み込んでください。
• references/quality-floor.md — Step 3/4 の詳細：コントラストの計算、グラデーション／ガラス表現、アイコン、画像、アクセシビリティの最低基準、9つのパフォーマンス改善策、公式デザインシステムの表。Step 3 に進んだら読み込んでください。
• references/experiential.md — 3D／WebGL／物理表現の段階。Step 2 で選んだ場合に限り読み込んでください。
• references/component-libraries.md — 機能からライブラリを選ぶための早見表。
• references/DESIGN_SYSTEM.template.md — Step 5 の成果物テンプレート。

---

Step 1 — 要件を分析してから振り分ける（必須）

1a. 要件を抽出する

次の項目を特定します：画面の種類（ランディング／マーケティング、ダッシュボード／管理画面、アプリ／プロダクト、モバイル、ストア、ポートフォリオ、リデザイン、デザインシステムのみ）、ブランド、業界、対象ユーザー、デザインスタイル、カラーシステム（60/30/10 に割り当て）、タイポグラフィの意図、アニメーションのレベル、カード／セクションのスタイル、画像の方針、技術スタック／プラットフォーム。 ユーザーが色と名前しか指定していない場合は、業界とスタイルからほかの項目を推測します。その場合は、ユーザーが修正できるよう、推測した内容を列挙してください。

1b. デザインの読み取りを1行で示す

「次のように捉えています：<surface> の <audience> 向けで、デザインの方向性は <style>、<color/type/motion summary>、<stack> で構築。」

1c. 画面プロファイルに振り分ける（最初に一致したものを選択。複合ケースには注意）

プロファイルを選んだら、作成を始める前に、すぐ Read ツールを使って、記載された references/surface-rules.md のセクションを開いてください。そのルールと画面別の必須チェック項目は、任意ではなく必須です。複合的な要件の場合は、該当する2つのセクションを読みます。

プロファイル	該当する場合	→ 今すぐ読む
ランディング／マーケティング	ランディングページ、マーケティング、キャンペーン、ポートフォリオ、長文コンテンツ	references/surface-rules.md §B1 — ページ構成 + ヒーロー + コンバージョン
ダッシュボード／管理画面／データ	ダッシュボード、管理画面、アナリティクス、コンソール、社内ツール	references/surface-rules.md §B2 — 情報密度、テーブル、チャート
アプリ／プロダクト UI	ウェブアプリ、SaaS の画面、設定、オンボーディング、フロー	references/surface-rules.md §B3 — ナビゲーション + フォーム + すべての状態
E コマース／ストア	ストア、ショップ、カタログ、商品詳細ページ、カート、チェックアウト	references/surface-rules.md §B5 — 商品一覧、商品詳細ページ、カート、チェックアウト、信頼性
コンテンツ／エディトリアル／ドキュメント	ブログ、記事、ドキュメント、KB、ニュース、長文の読み物	references/surface-rules.md §B6 — 読みやすい行長、目次、本文
モバイル／ネイティブ	iOS、Android、React Native、Flutter	references/surface-rules.md §B4 — HIG／Material、タッチ操作、セーフエリア
リデザイン	既存の UI の「リデザイン／改善／修正／整理」	まず監査（1d）を行い、その後、該当するプロファイルのセクションを読む
デザインシステムのみ	「デザインシステム／トークン／DESIGN_SYSTEM.md を作成」	ページの作成を省略 → Step 3 → 4 → 5。成果物そのものが納品物です

1d. 再設計の監査（再設計プロファイルのみ）

変更を加える前に、既存のコード／UIを確認し、（a）正常に機能していて維持すべきもの（ブランド、配色、情報設計、コンポーネント）、（b）ステップ3と事前確認ゲートに照らして評価した、具体的な凡庸さ／品質上の問題、（c）最小限の変更で最大限の問題を解決するための変更点を列挙してください。問題のないものを全面的に作り直してはいけません。現在のUIを実際に見ることも監査の一部です。「求められない限りブラウザーを開かない」というルールは、構築後の検証パフォーマンスについてのものであり、ここには当てはまりません。監査の根拠として、現在の状態をレンダリング／スクリーンショットで確認してもかまいません（その旨を伝えてください）。できない場合は、監査がコードのみであり、確信度が低いことを明記してください。

1e. カテゴリー反射テスト（色／テーマを選ぶ前に実施）

業界だけで配色を推測できてしまうなら――「フィンテック → ネイビー＋ゴールド」、「ヘルスケア → 白＋ティール」、「暗号資産 → 黒地にネオン」、「コーヒー → クリーム＋ブラウン」、「AIスタートアップ → 暗色に紫のグラデーション」――それは判断ではなく、学習データへの反射です。カテゴリーから答えが明白でなくなるまで見直してください。依頼内容で明示的に指定されている場合に限り、その指定を優先します。

---

ステップ2 — 不足していることだけを確認する（必須）

**ユーザーが提供した情報を使ってください。不足している内容だけを尋ねてください。**提供済みの情報を再度尋ねることも失敗です。

1. プロンプトを棚卸しする — 各チェックリスト項目を、表現が大まかでも提供済み（「フィンテックのスタートアップ」、「ブランドブルー #1A4FFF」、「Next.js リポジトリ」なども該当）または不足として印を付けます。
2. 不足している項目だけを AskUserQuestion で尋ねます。まとめて尋ねる場合は4項目以下（通常は1ラウンド以下、多くの場合は質問なし）です。すべて提供済みなら、質問を省略して依頼内容を言い換えます。
3. 同じことを再度尋ねたり、指定されたフレームワーク／配色／ニッチを覆したりしてはいけません。

チェックリスト（不足している場合に限り、それぞれ確認します）：

1. ニッチ／業界 — ムードや画像の方向性を決めます。
2. 技術スタック／プラットフォーム — 既存のプロジェクトがある場合は、確認せずにそのスタックを採用します。
3. デザインの方向性 — ミニマル、モダン、エディトリアル、大胆、ラグジュアリー、ブルータリスト、遊び心のあるデザインを提案します。
4. 配色 — 決めつけてはいけません。名前と16進数カラーコードを添えた配色案を2〜3種類提案するか、希望を尋ねます。指定がある場合は、それを60／30／10の比率に割り当てて次に進みます。
5. アニメーションのレベルとライブラリ — なし／控えめ／滑らか／動き豊かのいずれか、および GSAP ／ Framer Motion ／ CSS のみ。
6. 画像／アセットの方針 — AI 生成、ストック素材、Web 素材、ユーザー提供のいずれか。
7. 体験のレベル — 標準（DOM ＋ CSS／GSAP／Framer — 適切なデフォルト）または没入型（3D／WebGL／物理演算 — ユーザーが没入型体験を求めていて、コンテンツもそれを正当化する場合に限ります。選択された場合は、シーンの構築前に references/experiential.md を読んでください）。ニーズに合わせてレベルを選びます。3D を無理に使ったり、没入型の依頼内容を平坦化したりしてはいけません。

ロゴは別の質問です（未対応の場合に限り、単独で尋ねます）：AI 生成、ニッチに関連するWeb画像、テキストのワードマークを提案し、ロゴは SVG／PNG で提供するよう事前に伝えてください。

回答を得たら、まず依頼内容全体を1つの段落で言い換えてから、作業に進みます。

Step 2.5 — AI アセットの生成（黙って中断しない）

ユーザーがAI 生成を選んだ場合は、実際の画像を生成してください。API キーを確認して見つからなかったからといって、プレースホルダーに切り替えてはいけません。順序：

1. /chatgpt-image-gen — 最優先、API キー不要。 ブラウザーを介して、ユーザーがログイン済みの ChatGPT を操作します。ログインしていない場合は、その旨を明確に伝え（「Chrome のウィンドウが開いています。ログインしてから教えてください」）、確認を待ってください。非対話型／ヘッドレス実行（ログインできる人がいない場合）は、オプション 2 に直接進み、それも利用できない場合は、プレースホルダーであることを明記したアセットモジュールを雛形として作成し、再生成が必要であることを伝えてください。ログインできないヘッドレス実行を、ログイン待ちで止めてはいけません。
2. INFERENCE_API_KEY が設定されている、または指定された場合は、/ai-image-generation（inference.sh）を使用します。設定されていない場合は、確認するか、/chatgpt-image-gen に切り替えることを提案してください。

構築前の参考画像には、/imagegen-frontend-web（セクションごとに 1 枚）または /imagegen-frontend-mobile の使用を検討してください。ユーザーが明示的に同意した場合に限り、カスタム SVG／テキストマークで代用してください。生成したアセットは 1 つのファイルから差し替えられるよう、独立させてください（1 つの Logo コンポーネント／アセットモジュール）。

---

Step 2.6 — 実際のデザインリファレンスを集める（重要度の高い作業では必須）

モデルの平均的なデフォルトではなく、受賞歴のある実績ある作品を参考にデザインを決めてください。これは、ありきたりなデザインを避ける最も効果的な方法の 1 つです。ユーザーが「調査不要」と伝えた場合、または参考資料を提示した場合に限り、省略できます。

**ウェブにアクセスできない場合：**その旨を伝えたうえで、名前の挙がる実例（「Linear の情報密度／Stripe の抑制された表現／Arc の遊び心」など）を基に考え、Step 2.7 とカテゴリ連想テストをより重視してください。リファレンスを利用できなかったことを明記してください。

スタイルを表す語は、検索を主導する重要な要素です。 ブリーフで方向性（ミニマル、エディトリアル、ブルータリスト、ラグジュアリー、大胆、遊び心のある、モダン、スイス風など）が示されている場合は、そのスタイルを軸に3 種類の検索を実行し、構築前にデザインの方向性を定めてください。

• そのスタイルの参考デザイン — 「<style> <surface> デザインアワード」。
• そのスタイルの配色 — 「<style> <industry> に最適なカラーパレット」。採用を決める前に、検索結果をカテゴリ連想テストにかけてください。
• そのスタイルのフォント — 「<style> <surface> に最適なフォント」。Move A→C の選択を確認し、さらに絞り込んでください。

方法： ギャラリーを WebSearch し、上位の結果を WebFetch して具体的なパターンを確認してください。 画像中心のギャラリー（Awwwards、Dribbble）をテキスト取得しても、視覚的な手がかりはほとんど得られません。 視覚的な根拠を得るには、ビジョン機能を使ったブラウジング（/use-my-browser／/agent-browser でスクリーンショットを取得）または名前の挙がる実例を優先してください。WebFetch は主に構成、名称、コピーの確認に使います。ログインが必要な情報源には、ライブセッションでブラウザースキルを使用してください。徹底的に調べる場合は /deep-research を使ってください。

情報源： ランディングページ／ブランド → Awwwards、Godly、Land-book、Lapa Ninja、Httpster、Refero。 アプリ／ダッシュボード → Mobbin、Page Flows、UI Sources、Refero。モバイル → Mobbin、Apple／Google のギャラリー。ムード → Dribbble、Behance、Cosmos、Savee。

模倣ではなく、応用する。 各リファレンスをプロジェクト独自のトークンに合わせて調整してください。簡潔な「参考にしたリファレンス」メモを出力し、リンクを 3～5 件と、それぞれから取り入れた具体的な工夫を記載してください。

---

ステップ 2.7 — デザインコンセプトを1つに決める（必須）

避けるべきパターンを避けるだけでは、無難でも平凡なデザインになってしまいます。必要なのは、積極的な取り組みです。構築を始める前に、際立ったコンセプトを1つに決め、それを具体的な判断に反映させます。

1文で書きます。形容詞ではなく、具体的な軸となるアイデアにしてください。

「コンセプトは <具体的なアイデア1つ> です。これを <レイアウト>、<書体>、 <色>、<モーション> で表現します。」

• 弱い例： 「モダンで、クリーンで、プロフェッショナルなフィンテックダッシュボード。」（デフォルト設定であり、コンセプトではありません）
• 強い例： 「精密機器のように感じられるトレーディングターミナル。あらゆる場所で等幅数字を使い、極細のグリッドを敷き、ほぼ黒の背景に信号のような緑を1色だけアクセントとして使い、ティッカーのようにデータをアニメーション表示する。」

コンセプトは反証可能でなければなりません（どの競合にも当てはまるなら、さらに具体化してください）。また、{レイアウト、書体、色、モーション、画像} のうち3つ以上に表れている必要があります。デザインシステムの「デザインの個性／コンセプト」として記録してください。敵対的レビューでは、コンセプトが反映されているかを確認します。

---

ステップ 3 — センスを持ってデザインする（品質基準）

以下の共通原則は、すべての画面に適用されます。 構築する前に、ステップ 1 のプロファイルに対応する references/surface-rules.md のセクションと、references/quality-floor.md（コントラストの計算、グラデーション／ガラス表現、アイコン、画像、アクセシビリティの全基準、9つのパフォーマンス改善策、公式デザインシステムの表）を読んでください。これらの内容も以下の原則に加えて適用してください。まだ開いていない場合は、今すぐ開いてください。

色 — まず戦略を決め、その後 OKLCH で 60/30/10 を適用する

• まず戦略を選びます： 抑制型（色味を付けたニュートラルカラー＋アクセント1色を10％以下にする。製品／ダッシュボードのデフォルト）、強調型（彩度の高い1色を30～60％に使う）、フルパレット（役割を定めた3～4色）、全面着色型（画面全体を色で満たす）。「10％以下」のルールは抑制型にのみ適用されます。反射的にすべてをこのルールに押し込めないでください。
• 60/30/10： 60％を主要色（背景／広い面積のサーフェス）、30％を二次色（浮き上がったセクション／カード）、10％をアクセント（ボタン／リンク／フォーカスリング）にします。
• OKLCH で作業します。 L が 0 または 100 に近い場合は彩度を下げます。生の #000／#fff を使うのではなく、すべてのニュートラルカラーにブランドの色相をわずかに加えます（彩度は約 0.005～0.01）。ただし、コンセプトで純粋なインクの色を明示的に求める場合（ブルータリズム、輪郭のはっきりしたエディトリアルデザイン、真の OLED ブラック）は例外です。その場合、純粋な #000／#fff を使うのは、デフォルトではなく、意図的に選び記録した判断です。
• プロジェクトごとにパレットは1つだけにします。 暖色系と寒色系が入り交じらないようにし、セクション7で CTA の色を突然変えないでください。
• ダークモードは反転ではなく、派生させます。 テーマのセマンティックトークン（--bg、--surface、--surface-raised、--text、--text-muted、--accent）を使い、生の hex 値を反転してはいけません。ダークモードでは、色味を帯びたほぼ黒の色（L 約 0.15～0.20）を使い、サーフェスは明るくして浮き上がらせ（影はごくわずかに見える程度にし）、アクセントの彩度を下げて明度を上げます。また、テキストのコントラストは各組み合わせを個別に再検証してください。

まず奥行きで区別し、反射的に境界線を使わない

• コンテナを区別して浮き上がらせる主な方法は、背景のコントラストと（色相を付けた）シャドウです。すべてを囲む境界線ではありません。 境界線自体を完全に禁止するわけではありませんが、高さを表すデフォルトの方法としては適切ではありません。境界線は、平坦なサーフェス上で認識できる縁が必要な入力欄／コントロールの輪郭、情報量の多いデータ UI における細い区切り、表のセル／行の罫線、:focus-visible リングには正当な理由があり、使用が想定されています。これらの用途には使い、カードやセクションを区別する際の安易な手段としては使わないでください。
• 高さのあるサーフェスの中に、さらに別の高さのあるサーフェスを入れてはいけません（カードの中にカードを重ねないでください）。
• 奥行きの階層は1つだけにします：ページのベース → 浮き上がったセクション → 浮遊要素。
• 高さ／選択状態は背景色で変化させ、装飾的な境界線の表示／非表示で変化させないでください。

テキストのコントラスト（必須 — 白背景に灰色の本文を決して使わない）

• 本文／補足テキストは WCAG AA（≥4.5:1）を満たし、大きなテキスト（≥24px または ≥19px の太字）と UI／グラフィック要素は ≥3:1 を満たす必要があります。オフホワイトに明るい灰色（例：#fff 上の #9aa）は不合格です。
• 目視ではなく計算で確認してください。ライトモードとダークモードをそれぞれ確認します。線形化の式と OKLCH-Δ45 の事前チェックについては references/quality-floor.md を参照してください。数値を示さずに「AA に合格」と断言してはいけません。
• 控えめな補足テキスト／セカンダリテキストも、高いコントラストを保つ必要があります。読みやすくなるまで暗くしてください。

タイポグラフィ — ブランドに合うフォントを選び、スケールを固定する

タイポグラフィは、デザインが凡庸に見えるかどうかを最も左右します。反射的にいつも同じフォントを使ってはいけません。 次の3つのステップで選びます。

ステップ A — パーソナリティを言語化する（1〜2語）：企業的で洗練された、エディトリアルで高級感のある、温かみのある人間的な、力強く目立つ、遊び心のある／ファンキー／カートゥーン調、スイス風ミニマル、ブルータリズム的で技術的、エレガントでファッション性のある、など。必ず何らかのパーソナリティがあります。要件に記載がない場合は、業界と対象ユーザーから推測してください。推測することで、タイポグラフィがテンプレート的ではなく、意図して選ばれたように見えます。

シグナルがない場合のデフォルトはニュートラルなグロテスク体で、セリフ体ではありません。 パーソナリティがニュートラル／モダン／企業的／ミニマル（よくある「プロフェッショナル／クリーン／指定なし」のケース）の場合は、以下の企業的で洗練されたカテゴリから、セルフホスト可能なグロテスク・サンセリフ体を選び、どれを選んだか、またその理由を述べてください。毎回同じフォントを選ぶのではなく、細かなニュアンスに応じて使い分けます（Geist、Hanken Grotesk、Mona Sans、Neue Montreal、Space Grotesk はいずれも適しています）。フォントを1つだけ指定するのも、別の形での反射的な選択です。セリフ体やディスプレイ書体を使うのは、パーソナリティが明確にエディトリアルで高級感のあるもの、エレガントでファッション性のあるもの、またはヘリテージ系である場合に限ります。「モダンでミニマル」という要件にセリフ体を使うのは誤った推測であり、不合格です。

ステップ B — パーソナリティ → カテゴリ → フォントを対応させる（セルフホスト可能なもの、またはブランドが独自フォントを所有していない場合は Google Fonts を使用）。パーソナリティ→カテゴリ→フォントの対応表は references/quality-floor.md にあります。この要件のニュアンスに合う行を選び、フォントとパーソナリティのつながりを1行で説明してください（どの要件にも同じように当てはまりそうなら、反射的に選んでいます）。

ステップ C — 意図を持って組み合わせる。 見出しにはパーソナリティを持たせ、本文は控えめで読みやすくし、どちらも同じ感情的な系統にそろえます。書体ファミリーは最大2つ（必要に応じて等幅フォントを追加）です。強調には、同じファミリーのイタリック体／太字を使います。

反射的な選択を避ける（必須）： デフォルトで Inter を選んではいけません。シグナルがない要件には、グロテスク・サンセリフ体（セリフ体は不可）を選び、具体的なフォントとその理由を説明してください。「クリエイティブ／プレミアム」という要件だけを理由にセリフ体を選んではいけません。遊び心のある／カートゥーン調のブランドには、企業的なグロテスク体を決して使ってはいけません。

• タイポグラフィのスケールはトークンとして一度だけ定義（display、h1、h2、h3、body-lg、body、body-sm、caption、button）し、すべての箇所で参照します。場当たり的なサイズをインラインで指定せず、同じ役割には、セクションが変わっても同じサイズを使います。
• 最小サイズ： 本文は 16px 未満にしません。キャプションは約13〜14px、行の高さは約1.5、行長は 60〜75ch とします。
• レスポンシブ対応もスケールに含めます。流体的な clamp() を優先し、モバイルでは見出しを縮小します。テキストを切り抜いたり、省略したりしてはいけません。

コンポーネント（再利用可能に構築する）

ボタン、カード、バッジ、ナビゲーションバー、フッター、フォーム、入力欄、特徴紹介／CTA セクションに加え、フィードバックの基本コンポーネント（Toast、Spinner、Modal、Skeleton、空状態／エラー状態）は、それぞれ一度だけ定義して再利用します。インタラクティブな状態は基本コンポーネント内に実装します。場当たり的なインラインのバリエーションは使いません。機能に基づいてコンポーネントのベースを選び（references/component-libraries.md を参照）、プロジェクトごとにスタイル付きのベースを1つだけ使い、トークンに合わせてテーマを変更します。ライブラリのデフォルトの見た目をそのまま使ってはいけません。

インタラクションのフィードバックと状態（静的でも無反応でもない）

• すべてのインタラクティブ要素に、状態一式を用意します： デフォルト、ホバー、 フォーカス（:focus-visible。:focusではありません）、アクティブ／押下（視覚的に表示 — わずかに縮小して影を変化させ、即座に反応）、無効。
• フォーカスリングには:focus-visibleを使い、キーボードまたはプログラムによるフォーカス時にだけ表示して、マウスクリック時は非表示にします。 マウスクリックのたびにリングが点滅すると粗雑な印象になります — ただし、解決策は:focus-visibleであり、outline:noneを使ったり、リングを削除したりしてはいけません（WCAG 2.4.7に違反し、キーボードユーザーを締め出します）。多くのコンポーネントライブラリでは、デフォルトで:focus（マウスでも表示）を使っています — :focus-visibleに割り当て直してください。
• フローティング要素は画面内に収めます。 ツールチップ、ドロップダウン、ポップオーバー、メニュー、セレクト、日付ピッカーには、画面端で反転・移動してビューポート内に収める衝突対応の配置を使います。はみ出したり、端で切れたりしてはいけません。Popover API／anchor配置、または配置エンジン（Floating UI、あるいは内包しているRadix／Headless UI）を使ってください。端付近で画面外にはみ出す固定オフセットによる手動配置は避けてください。
• 非同期アクションは、開始した瞬間に読み込み状態（ラベルを作業中の動詞に変更してスピナーを表示する、またはスケルトンを表示する）を示します。説明なくUIをフリーズさせてはいけません。
• すべてのアクションに、明示的な成功／エラーのフィードバック（トースト／インライン表示／マイクロフィードバック）を返します — アイコンまたはラベルを組み合わせ、色だけで示してはいけません。
• フォーム： 入力中ではなくフォーカスを外したときにインライン検証を行い、フィールドの下にエラーを表示し、必須マーカーと補足テキストを表示します。入力欄の上にラベルを配置します（プレースホルダーをラベル代わりにしてはいけません）。送信を無効にする場合は、その理由を表示します。
• データビューには3つの状態を設計します： 空（役立つ内容でブランドに沿ったもの）、読み込み中（スケルトン／スピナー）、エラー（復旧可能で再試行できるもの）。すべてを共有コンポーネントとモーショントークンから制御します。

モーション

• 一貫性があり、目的に沿ったものにします。同じ時間とイージングを再利用します。マイクロインタラクションは約150～300msとし、表示時はイーズアウト、非表示時はイーズインを使い、リニアは避けます。アニメーション対象は**transform／opacityのみ**にします。
• モーションには明確な目的を持たせます — 階層、フィードバック、ストーリーテリング、状態を伝えます。何を伝えるのかを一文で説明できない場合は、削除してください。
• prefers-reduced-motionには必ず対応します — 即座に表示し、コンテンツを完全に見える状態にします。すべてのインタラクティブ要素でポインターカーソルを使います。

UXコピーとコンテンツ（プレースホルダーではなく、人が書いたように）

• 汎用的な表現より具体的な表現を優先します。 見出しには、対象ユーザーに向けて、その機能が何をするのかを書きます。「ワークフローを向上」「シームレスなソリューション」「次世代プラットフォーム」のような表現は避けます。同じカテゴリのどの企業にも当てはまるなら、書き直してください。
• CTAは動詞から始めます：「14日間のトライアルを開始する」＞「始める」。1つの目的には1つのラベルを使います。
• 実際のデータ、またはモックデータであることを明示したデータを使います — 「Acme／John Doe／Lorem ipsum」を実データとして公開してはいけません。精密に見える架空の統計値も使いません。
• マイクロコピーでUXを支えます： 空の状態では次のアクションを説明します。エラーでは何が起きたのかと解決方法を伝えます（「問題が発生しました」だけでは不十分です）。読み込み中のボタンには実行中の処理を示します。

アイコン、画像、グラデーション／ガラス表現、アクセシビリティの最低基準、および公式デザインシステムに関する誠実さを示す表は、すべてreferences/quality-floor.mdに記載されています — この手順の一部として適用してください。

ステップ 4 — 構築（信頼できる唯一の情報源を優先し、常にモジュール化する）

1. まずトークンを整備します。 すべての色、タイポグラフィのスケール、余白、角丸、シャドウ、モーションの持続時間／イージングに対して、トークンレイヤー（CSS 変数／テーマ／Tailwind 設定）を 1 つ用意します。値をハードコードしてはいけません。 DESIGN_SYSTEM.md と完全に一致させます。
2. モジュール化された小さなコンポーネントにします。 再利用可能なプリミティブを一度だけ作成し、それらを組み合わせてページを構築します。ファイルごとに責務を 1 つにし、ファイルが大きくなったら分割します。状態はプリミティブ側に持たせます。
3. 承認済みの色と定義済みのコンポーネントのみを使います。共通のモーショントークンを使ってアニメーションを設定し、画像のスタイルを統一し、すべてのページをレスポンシブにします（ブレークポイントごとに各セクションを検証してください）。
4. レイヤーを適切に分離します — プリミティブにビジネスロジックやデータ取得を持たせず、機能モジュールがデータ／状態を管理します。共有ロジックは相互インポートではなく、共通の場所に配置します。
5. 依存関係を確認します — インポートする前に package.json を確認し、依存関係がない場合はインストールコマンドを出力します。プロジェクトのパッケージマネージャーに合わせます（ロックファイルから判定し、ロックファイルがなければ pnpm を使います）。
6. 体験重視のレイヤーはコード分割し、分離します（references/experiential.md を参照）— Standard ページは 3D レイヤーが読み込まれる前から、また 3D レイヤーなしでも表示され、利用できるようにします。

パフォーマンスとデリバリー（本番環境対応とは高速であること）

Core Web Vitals の目標値：LCP < 2.5s、CLS < 0.1、INP < 200ms。 9 つの施策すべてを適用します — 全リストは references/quality-floor.md にあります。要点は、体感速度の向上、初回ロードの縮小、クリティカルパスの CSS を優先、配信する JavaScript の削減、ファーストビュー外の遅延読み込み、メインスレッドの保護、レイアウトの安定化（CLS）、画像の最適化、キャッシュの適切な活用です。

エンジニアリングの原則

• DRY / KISS / YAGNI — 2 回以上使われる値やロジックは一度だけ定義します。動作する最もシンプルな方法を選び、今必要なものだけを作ります。
• 遅延的にコードを書く（/ponytail の段階的な選択肢）： JavaScript ライブラリよりネイティブ HTML/CSS（依存関係を追加する前に <dialog>、<details>、scroll-snap、:has() を使います）。新しい依存関係よりインストール済みの依存関係を使います。50 行より 1 行を選び、ファイル数を最小限にします。意図的な近道には ponytail: コメントを付けます。/ponytail がインストールされている場合は、複雑なコンポーネントで実行します。インストールされていない場合は、段階的な選択肢に従います。
• Ponytail が規定するのは 実装方法 であり、デザインに必要なもの ではありません。 トークンレイヤー、再利用可能なプリミティブ、すべての状態、空／読み込み中／エラーの状態、アクセシビリティ、敵対的レビュー、DESIGN_SYSTEM.md を省略してはいけません。実装の仕組みは簡潔にし、デザインシステム自体は妥協しません。

ステップ 4.5 — 敵対的レビュー（ドキュメント作成前に必須）

作者ではなく、敵対者の立場で評価してください。このパスでは、デザインが汎用的であると主張することが目標です。「汎用的ではない」という判断はすべて、修正すべき指摘事項です。

1. コンセプトテスト。 ブランド名を隠してみてください。競合他社のものにも見えるでしょうか。そうであれば、コンセプトを明確にし、ステップ 2.7 を再適用してください。
2. 反射テスト（1e）、攻撃者の視点で。 カラーパレットはカテゴリから予想できるものですか。書体は見慣れたデフォルトですか。そうだと仮定し、具体的な根拠を挙げて、その判断が間違っていると証明してみてください。
3. リファレンステスト。 各セクションで、具体的にどのプレミアムな工夫が実現されているかを挙げてください。正直な答えが「デフォルトの AI レイアウト」であるセクションはすべて作り直してください。
4. 実際の弱点を 1 つ挙げる。 最も弱い部分をはっきり述べ、修正してください。何も見つからないレビューはレビューとは言えません。
5. ヒーロー構成のセルフチェック（ランディングページ／マーケティングページ）。 ヒーローで採用している構成をはっきり述べてください。中央寄せのエディトリアル／特大タイポグラフィ／フルブリード／非対称のオフグリッド／分割のいずれかです。**答えが「分割」の場合は、分割を成立させる具体的で独自な工夫を 1 つ記述してください。**それができなければ、左側にテキスト、右側に画像という反射的なテンプレートです。分割ではない構成に作り直してください。また、ヒーローが垂直方向に中央配置されていること、上部に空白の帯がないこと、アイブロウにきらめき／AI アイコンや曖昧なタグラインがないことも確認してください。（スクリーンショットを撮るためのブラウザーがない場合、このセルフチェックの記述が、レンダリングでしか確認できないヒーローの粗雑さを防ぐ最後の砦です。）

重要度の高いブリーフでは、これを本当に独立したパスとして実行してください（新鮮な視点で読み直すか、サブエージェントを使います）。コンセプトテストの判定をデザインシステムに記録してから、数値で確認できるゲートを実行してください。

---

ステップ 5 — DESIGN_SYSTEM.md に記録する（必須）

デザイン全体の作成後、または改善後は必ず、プロジェクトのルートにある references/DESIGN_SYSTEM.template.md を基に DESIGN_SYSTEM.md を作成し、全 14 セクションに実際に使用した値（実際の HEX／OKLCH 値、実際のフォント、実際のコンポーネント仕様）を記入してください。今後の作業で同じルートをたどれるよう、セクション 1 にサーフェスプロファイル（ステップ 1）を記録してください。その後、ユーザーに次の文をそのまま伝えてください。

"プロジェクトに DESIGN_SYSTEM.md ファイルが追加されました。今後のページ、セクション、コンポーネントのデザインガイドとしてこのファイルを使用し、ウェブサイト全体のビジュアルに一貫性を保ってください。"

---

出荷前チェック — 数値で確認できるアンチスロップゲート（唯一の基準）

アンチスロップは数値で確認します。1 つでも不合格なら、完了ではありません。このゲートが正規のチェックリストです。DESIGN_SYSTEM.template.md §12 はチェックリストを重複して記載するのではなく、ここを参照します。維持するチェックリストは 1 つだけです。以下の共通ゲートに加えて、references/surface-rules.md の末尾にあるプロファイル別のゲートも実行してください。

厳禁事項（1つでも該当したら不合格）

• ❌ 承認済みパレット以外の色。デフォルトの紫／青紫のグラデーション（承認済みの場合を除く）。デフォルトでの生の #000／#fff の使用（ピュアインクは、ブルータリスト／ハードなエディトリアル／真のOLEDなど、コンセプトで明確に求められ、かつ文書化されている場合に限り使用可能です）。
• ❌ デフォルトでLucideを使うこと。異なるアイコンファミリーを混在させること。構造を示すアイコンとして絵文字を使うこと。
• ❌ コントラストの低いテキスト（本文／補助テキストの組み合わせで、明るい背景・暗い背景を問わず4.5:1未満）。
• ❌ 本文テキストが16px未満であること。スケールの段階に対応していないインラインの個別サイズを使うこと。
• ❌ パーソナリティに合わないタイポグラフィ（コーポレート向けグロテスク体に遊び心のあるブランドを組み合わせる、汎用サンセリフ体でエディトリアルな表現をする、グロテスクサンセリフ体が適切なのにシグナルのないデフォルトとしてセリフ体を使うなど）。Move A→Cで選ばず、同じ組み合わせを反射的に使い回すこと。
• ❌ カードやセクションを分離・浮き上がらせる主な手段としてボーダーを使うこと。また、装飾的なボーダーの切り替えで浮き上がり／選択状態を変えること。（入力欄のアウトライン、トークンの区切り線、テーブルの罫線、フォーカスリングは問題ありません。これらは浮き上がりを表すものではありません。）
• ❌ 浮き上がったサーフェスを入れ子にすること（カードの中にカード、その中にさらにカード）。
• ❌ 静的なインタラクティブ要素（ホバー／フォーカス／アクティブ／無効状態がない）。非同期アクションで何も通知しないこと（読み込み中＋成功／エラーの状態がない）。空／読み込み中／エラー画面が空白であること。
• ❌ ヒーローのテキストが切れること。モバイルでテキストが省略されること。どのブレークポイントでもコンテンツが切れる／はみ出すこと。これには、ノートPCの高さが約700～800pxのときにヒーローが縦方向にはみ出すこと、上揃えになって中央配置でないこと、ヒーローの上に空の全幅帯／余白があること（不要なスペーサーや空セクションによってコンテンツが下へ押し下げられ、中央からずれること）が含まれます。
• ❌ 左にテキスト、右に画像（または右にモックアップ／動画）を配置するヒーロー構成は、デフォルトでは不合格です。 — Webで最もテンプレート化されたヒーロー構成だからです。採用できるのは、それを際立たせる具体的な工夫（非対称な比率、画像を端からはみ出させる、重なり／奥行きや動きの工夫）を明記し、それが実際に効果を発揮している場合に限ります。左にテキスト、右に角丸の画像カードを置いた単純な50／50構成は自動的に不合格です。別の構成（中央揃えのエディトリアル、大きなタイポグラフィ、全面表示、非対称／グリッド外）を選んでください。
• ❌ アイブロウ、バッジ、ピルに装飾的なきらめき／✨／✦／魔法の杖／「AI」の星アイコンを使うこと（「✨ AI-powered」という定番の表現）。また、実際のセクション名／カテゴリではなく、曖昧なタグライン（「色から完全なシステムへ」など）をアイブロウに使うこと。アイブロウは装飾ではなく、情報を伝えるものです。
• ❌ マウスクリックで表示されるフォーカスリング（:focusを:focus-visibleの代わりに使う、またはライブラリのマウスでも表示されるデフォルトをそのまま出荷するなど）。リングを削除するのではなく、:focus-visibleで修正してください。
• ❌ ビューポートの端からはみ出す、または切れるフローティング要素（ツールチップ／ドロップダウン／ポップオーバー／メニュー／セレクト／日付選択）。画面内に収まるよう、衝突を考慮した位置調整によって反転／移動させる必要があります。
• ❌ 水平カード行をデザインしたにもかかわらず、ネイティブのスクロールバーが見えること（overflow-x:autoによる見せかけの縦スクロールバーも含む。overflow-y:hiddenを設定し、スクロールバーを非表示にしてください）。スナップ／操作コントロール／滑らかなスクロールのない生のoverflow-x。mask-imageのフェードがなく、端が唐突に切れていること。スクロールバーの横でカードが半分だけ表示されていること。
• ❌ グラデーションテキスト（background-clip:text）。装飾的なガラス表現。アクセントとしての側面ストライプ border-left/right。
• ❌ 何でも詰め込んだ巨大なファイル。
• ❌ 要件にない3D表現を無理に追加すること、または没入型の要件を平坦化すること。フォールバックがない／モバイル向けの劣化対応がない／動きを減らす設定で静止表示されないWebGLシーン。キャンバスにコピーを埋め込むこと。クリティカルパスに重い3D／アニメーションのバンドルを含めること。
• ❌ 汎用的なAI SaaSレイアウトを調整せずに貼り付けること。カテゴリからパレットが推測できてしまうこと。コンセプトテストに失敗するデザイン。ありきたりな埋め草のコピー。
• ❌ ライブラリ／レジストリのコンポーネントをデフォルトテーマのまま使うこと（標準のshadcn／Aceternity／Magic UI、デフォルトのグラデーション、デモ用コピー）。1つのプロジェクトでスタイル付きコンポーネントのベースを複数使うこと。
• ❌ アクセシブルなプリミティブがあるのに、独自実装のdiv＋onClickウィジェットを使うこと。または、ネイティブHTML／CSSやインストール済みの依存関係でできることに、ライブラリ全体を追加すること。

数えられる制限

• 眉ラベル（小さな大文字のトラッキング付きラベル）：≤ ceil(セクション数 ÷ 3)。それぞれ実際のラベル／カテゴリである必要があります。装飾的なきらめき／AI アイコンや、眉ラベルとして使う曖昧なキャッチフレーズは不可です。
• ジグザグの連続（画像＋テキストの交互の行）：連続で ≤ 2 行。3 行目でパターンを崩します。
• ページ全体で、CTA の意図ごとにラベルは 1 つだけにします。
• プライマリ CTA のスタイルは 1 つにして、繰り返し使用します。セカンダリ CTA は控えめにし、CTA のテキストは 1 行に収めます（プライマリは ≤3 語）。
• マーキーは 1 ページにつき ≤ 1 個。 **テーマ：**ライト／ダークの反転は、意図的かつ一貫して繰り返されるシステムとし、偶発的な変化にしてはいけません。すべてのテキストの組み合わせで、どちらのテーマでも AA に準拠する必要があります。ユーティリティ用のサーフェスは、1 つのビュー内で単一のテーマに保ちます。
• **レイアウトファミリーの繰り返し：**複数のセクションがあるページでは、異なるセクションレイアウトファミリーを ≥3 種類使用します。
• 偽の精密な数値／汎用的な名前／埋め草のコピーは、実在するものかモックと明示したもの以外は 0 にします。

パフォーマンスのゲート

• ❌ width／height または aspect-ratio のない画像／メディア／埋め込み。
• ❌ Hero／LCP 画像が優先されていない、またはファーストビュー外の画像／コンポーネントが遅延読み込みされていない。
• ❌ transform／opacity 以外のプロパティをアニメーションさせること。
• ❌ display: swap を指定していないウェブフォント、またはクリティカルパス上のレンダリングをブロックする非クリティカルな CSS／JS。
• ❌ 初期パスでの重い／3D バンドル、コンポーネントの状態を介した連続的なスクロール／マウス駆動。
• ✅ 9 つすべてのレバーを適用します。 CWV の数値は、それらのレバーが目指す目標です。「レバーを通じて目標化した」と記載してください。実際に測定した場合に限り、数値を報告してください。

---

完了前の検証

1. 型チェック。 検出されたパッケージマネージャーを使って、プロジェクトの型チェック（<pm> run typecheck、または <pm> exec tsc --noEmit、または lint コマンド）を実行します。エラーを見つけるためだけに本番ビルドを実行しないでください。
2. 目視ではなく計算してください。計算可能な項目を確認します。 使い捨てスクリプトでコントラスト比を計算します（数式は references/quality-floor.md を参照）。これは必須であり、任意ではありません。
3. **レイアウト後にしか確認できない項目を、実際にレンダリングして検証します。**これは検証したふりをすることではなく、確認する唯一の方法です。ゲートでは、ソースからは確認できない複数のレンダリング結果を求めています。hero が高さ約 700px と約 800px のノート PC 画面で 100svh 内に収まること、幅 375／768／1280 でクリッピングやオーバーフローがないこと、水平レールに見えないスクロールバーが表示されないことです。これらの特定項目については、該当するビューポートでヘッドレススクリーンショット（/use-my-browser、/agent-browser、または Playwright）を取得して確認します。または、実際にレンダリングできない場合は、そのことを明示し、主張を「検証済み」から「目標に沿って構築したが、視覚的には未確認」に引き下げます。実際に確認していないレンダリング専用のゲート項目が合格したと主張してはいけません。（これは「検証のためにブラウザーを開かない」というルールの、認められた唯一の例外です。このルールでは、コードからすでに分かっている項目を、後から装飾目的でスクリーンショットに撮ることは引き続き禁止されています。）
4. 完了を宣言する前に、敵対的レビュー（4.5）と数えられる項目のゲートをもう一度、最終確認します。

今後の作業と更新

今後作成するすべてのページで、DESIGN_SYSTEM.md にある色、タイポグラフィ、余白、コンポーネント、アイコン、カード、アニメーション、画像のスタイルを再利用します。ユーザーが更新しない限り、新しいビジュアルスタイルを追加してはいけません。何か変更した場合は、スタイルにずれが生じないよう、ただちに DESIGN_SYSTEM.md を更新します。