ce-frontend-design

フロントエンドデザイン

汎用的な AI らしい見た目を避け、独自性のある本番品質のフロントエンドインターフェースを作成するためのガイドです。このスキルでは、既存の状態を把握し、デザインを計画し、意図を持って構築し、視覚的に検証するという全ライフサイクルを扱います。

優先順位

このスキルのルールはすべてデフォルトであり、必須ではありません。

1. 既存のデザインシステム／コードベースのパターン -- 最優先であり、常に尊重します
2. ユーザーの明示的な指示 -- スキルのデフォルトより優先されます
3. スキルのデフォルト -- 新規開発の場合、またはユーザーがデザインの指針を求めている場合に適用します

既存のパターンが確立されているコードベースで作業するときは、そのパターンに従います。ユーザーがデフォルトと相反する方針を指定した場合は、ユーザーの指示に従います。

ワークフロー

Detect context -> Plan the design -> Build -> Verify visually

---

レイヤー 0：コンテキストの検出

デザイン作業を始める前に、コードベースを調べて既存のデザイン上の手がかりを確認します。これにより、このスキルの独自性を重視したガイダンスをどの程度適用するかを判断します。

確認する項目

• デザイントークン／CSS 変数：--color-*、--spacing-*、--font-* カスタムプロパティ、テーマファイル
• コンポーネントライブラリ：shadcn/ui、Material UI、Chakra、Ant Design、Radix、またはプロジェクト固有のコンポーネントディレクトリ
• CSS フレームワーク：tailwind.config.*、styled-components のテーマ、Bootstrap のインポート、命名規則に一貫性のある CSS Modules
• タイポグラフィ：HTML／CSS のフォントインポート、@font-face 宣言、Google Fonts のリンク
• カラーパレット：定義済みの色階調、ブランドカラーのファイル、デザイントークンのエクスポート
• アニメーションライブラリ：Framer Motion、GSAP、anime.js、Motion One、Vue Transition のインポート
• 間隔／レイアウトのパターン：一貫した間隔スケールの使用、グリッドシステム、レイアウトコンポーネント

プラットフォームに備わっているファイル検索およびコンテンツ検索ツール（例：Claude Code の Glob／Grep）を使って、これらの手がかりを探します。通常のファイル探索にシェルコマンドは使わないでください。

モードの分類

検出した手がかりに基づいて、モードを選択します。

• 既存システム（複数のカテゴリにわたり 4 つ以上の手がかりがある）：既存のシステムを優先します。スキルの美的な指針（タイポグラフィ、色、動き）は、確立されたシステムより優先度が下がります。構造に関する指針（構成、コピー、アクセシビリティ、検証）は引き続き適用されます。
• 部分的なシステム（手がかりが 1～3 個）：既存のものに従い、慣例が見つからない領域にのみスキルのデフォルトを適用します。たとえば、Tailwind が設定されていてもコンポーネントライブラリがない場合は、Tailwind のトークンに従いつつ、コンポーネント構成にはスキルのガイダンスを適用します。
• 新規開発（手がかりが検出されない）：スキルのガイダンスをすべて適用します。
• 不明確（手がかりに矛盾がある、または判断が難しい）：作業を進める前にユーザーに確認します。

ユーザーへの確認

コンテキストが不明確な場合は、プラットフォームの応答を待つ質問ツールを使用します。Claude Code では AskUserQuestion（スキーマが読み込まれていない場合は、先に select:AskUserQuestion を指定して ToolSearch を呼び出します）、Codex では request_user_input、Gemini では ask_user、Pi では ask_user（pi-ask-user 拡張機能が必要）を使用します。実行環境に応答を待つツールがない場合、または呼び出しでエラーが発生した場合（例：Codex の編集モード）に限り、チャット上で選択肢を提示します。スキーマの読み込みが必要というだけの理由で代替してはいけません。確認を省略したまま進めてはいけません。ユーザーが選択を断った場合は、「部分的なシステム」モードとみなし、慎重に進めます。

質問例：「[検出された手がかり] が見つかりました。既存のデザインパターンに従いますか、それとも独自性のあるものを作成しますか？」

---

レイヤー 1：ビルド前の計画

コードを書く前に、短い文を 3 つ書きます。これにより一貫性が生まれ、コードを書く前にユーザーが方向性を修正するための確認ポイントになります。

1. ビジュアルの方針 -- 雰囲気、素材感、エネルギーを説明する 1 文

   • 新規プロジェクトの例：「余白をたっぷりとったクリーンなエディトリアル調。セリフ体の見出しと、彩度を抑えたアースカラー」または「データを前面に押し出した高密度のダッシュボード。等幅フォントのアクセントと、暗い面による階層構造」
   • 既存のコードベース：既存の美的スタイルと、新しい作業でそれをどう発展させるかを説明します

2. コンテンツ計画 -- ページに何をどの順番で配置するか

   • ランディングページ：ヒーロー、サポート、詳細、CTA
   • アプリ：主要なワークスペース、ナビゲーション、補足コンテキスト
   • コンポーネント：どのような状態があり、何を伝えるか

3. インタラクション計画 -- 印象を変える具体的な動きのアイデアを 2～3 つ

   • 「アニメーションを追加する」ではなく、「ヒーローの読み込み時に段階的にフェードイン、セクション間のスクロールに合わせた視差効果、カードのホバー時に拡大」
   • 既存のコードベースでは、既存のモーションライブラリを使って、追加するインタラクションだけを説明します

---

レイヤー 2：デザインの基本指針

これらの原則は、すべてのコンテキストタイプに適用されます。優先順位に従い、既存のデザインシステムとユーザーの指示が優先されます。

タイポグラフィ

• 個性が際立つ、印象的なフォントを選びます。既存のコードベースで使われている場合を除き、よくあるフォント（Inter、Roboto、Arial、システム標準フォント）は避けます。
• 明確な理由がない限り、書体は最大 2 種類にします。ディスプレイ／見出し用フォントと本文用フォントを組み合わせます。
• レイヤー 0 で既存のフォントが検出された場合は、そちらを優先します。

色とテーマ

• CSS 変数を使って、一貫性のあるパレットを設定します。控えめで均等に分散したパレットより、支配的な色と鮮やかなアクセントの組み合わせが効果的です。
• 白地に紫を基調とすることや、ダークモードを前提にすることは避けます。コンテキストに応じてライトとダークを使い分けます。
• プロダクトにすでに複数色のシステムがある場合を除き、アクセントカラーはデフォルトで 1 色にします。
• 検出された既存のカラートークンを優先します。

構成

• コンポーネントではなく、構成から始めます。最初のビューポートは文書ではなくポスターとして扱います。
• ボーダー、シャドウ、カードなどの装飾を加える前に、余白、配置、スケール、トリミング、コントラストを活用します。
• デフォルトではカードを使わないレイアウトにします。ユーザーのインタラクションを収める役割がある場合（クリック可能な項目、ドラッグ可能な単位、選択可能なオプション）はカードを使えます。カードのスタイルを取り除いても理解しやすさが損なわれないなら、カードにすべきではありません。
• 構成に関するルールはすべてデフォルトです。ユーザーはこれらを上書きできます。

モーション

• 視覚表現が中心となる作業では、意図的な動きを 2～3 つ実装します。登場時のアニメーション、スクロール連動または奥行き効果、ホバーまたは表示切り替えのトランジションを 1 つずつ用意します。
• プロジェクトに既存のアニメーションライブラリがあれば、それを使用します。
• 既存のライブラリが見つからない場合は、フレームワークに応じて次のデフォルトを使います。
  • CSS アニメーション：汎用的な基本選択肢
  • Framer Motion：React プロジェクト
  • Vue Transition / Motion One：Vue プロジェクト
  • Svelte transitions：Svelte プロジェクト
• 動きは短い録画でもはっきり分かり、モバイルでも滑らかで、ページ全体で一貫している必要があります。装飾目的にすぎない場合は削除します。

アクセシビリティ

• デフォルトではセマンティック HTML を使います。何でも div にするのではなく、nav、main、section、article、button を使います。
• WCAG AA の最低基準を満たす色のコントラストを確保します。
• すべてのインタラクティブ要素にフォーカス状態を設けます。
• 適切に実装すれば、アクセシビリティと美しさは両立できます。

画像

• 画像が必要な場合は、抽象的なグラデーションや偽の 3D オブジェクトより、実写またはリアルな写真を優先します。
• テキストを重ねる領域の色調が安定した画像を選ぶか、生成します。
• 環境で画像生成ツールを利用できる場合は、プレースホルダーのストック画像ではなく、コンテキストに合ったビジュアルを作成するために使います。

---

コンテキストモジュール

構築する対象に合ったモジュールを選択します。既存のアプリケーション内で作業する場合は、機能の内容にかかわらず、デフォルトでモジュール C を選択します。

モジュール A：ランディングページとマーケティング（グリーンフィールド）

デフォルトのセクション順序：

1. ヒーロー — ブランド／製品、提供価値、CTA、主役となるビジュアルを1つ
2. サポート — 具体的な機能、オファー、または実績を1つ
3. 詳細 — 雰囲気、ワークフロー、製品の奥行き、またはストーリー
4. 最終CTA — コンバージョン、開始、訪問、または問い合わせ

ヒーローのルール（デフォルト）：

• 1つの構成にします。ダッシュボードにはしません。画面全体に広がる画像か、主役となるビジュアル面を使います。
• ブランドを最初に、見出しを2番目に、本文を3番目に、CTAを4番目に配置します。
• テキスト列は狭く保ち、画像の落ち着いた領域に固定します。
• 明確な理由がない限り、セクション数は合計6つまでにします。
• H1の見出しは1つにします。ファーストビュー内の主要CTAは1つにします。

コピー：

• 見出しに意味を担わせます。補足コピーは通常、短い1文にします。
• デザインの解説ではなく、製品の言葉で書きます。UIにプロンプトの文言やAIについての解説を含めません。
• 各セクションの役割は1つにします。説明、実証、掘り下げ、またはコンバージョンです。
• すべての文に掲載するだけの価値が必要です。コピーは増やすより減らすことを基本にします。

モジュール B：アプリとダッシュボード（グリーンフィールド）

デフォルトのパターン：

• 落ち着いたサーフェスの階層、明快なタイポグラフィと余白、少ない色数、密度が高くても読みやすい情報、最小限の装飾を使います。
• 次の要素を軸に構成します：主要な作業領域、ナビゲーション、副次的なコンテキスト／インスペクター、操作や状態を示す明確なアクセント1色。
• カードは、それ自体がインタラクション要素である場合（クリック可能な項目、ドラッグ可能な単位、選択可能なオプション）のみ使います。意味を損なわずにパネルを通常のレイアウトにできるなら、カードの装飾を取り除きます。

コピー（マーケティングではなく実用性）：

• 価値の訴求、雰囲気、ブランドの語り口よりも、状況の把握、ステータス、操作を優先します。
• セクション見出しには、その領域の内容や、そこでユーザーができることを示します。良い例：「プランのステータス」「検索指標」。悪い例：「可能性を解き放つ」。
• ホームページのヒーローに載せられそうな文は、製品UIらしく聞こえるまで書き直します。
• 判断基準：担当者が見出し、ラベル、数値だけをざっと見ても、ページの内容をすぐに理解できますか？

モジュール C：コンポーネントと機能（既存アプリでのデフォルト）

既存のアプリケーションに追加する場合：

• 既存のビジュアル言語に合わせます。このモジュールの目的は、目立たせることではなく、既存の一部としてなじませることです。
• 周囲のコードで使われている余白のスケール、角丸、カラートークン、タイポグラフィを引き継ぎます。
• インタラクションの品質を重視します。明確な状態（デフォルト、ホバー、アクティブ、無効、読み込み中、エラー）、状態間の滑らかな遷移、ひと目で分かる操作可能性を実現します。
• 新しいコンポーネント1つのために、新たなデザインシステムを導入してはいけません。既存アプリの角丸が4pxなら、8pxのコンポーネントを追加しません。

---

厳守するルールとアンチパターン

デフォルトで避けるもの（上書き可能）

これらは、このスキルの推奨方針です。ユーザーはどれでも上書きできます。

• 最初の印象が、ありきたりなSaaSのカードグリッドになっている
• 紫と白の配色、ダークモードを前提とした設計
• グリーンフィールドの作業で、使われすぎているフォント（Inter、Roboto、Arial、Space Grotesk、システムのデフォルトフォント）を使う
• 統計、スケジュール、ピルの集まり、ロゴの集合で雑然としたヒーローセクション
• 同じ雰囲気を別の言葉で繰り返すセクション
• ストーリー上の目的がないカルーセル
• 複数のアクセントカラーが競合している
• 実際のビジュアルコンテンツの代わりに、装飾的なグラデーションや抽象的な背景を使う
• デザインの解説のように聞こえるコピー（「シームレスな統合を体験してください」など）
• 画像の混雑した側にテキストが配置される、左右分割型のヒーロー

常に避けるもの（品質の最低基準）

ユーザーが誰も望まない、明確な品質上の問題です。

• UIにプロンプトの文言やAIについての解説が漏れ出している
• コントラストの問題 — 画像や背景上のテキストが読めない
• フォーカス状態が視覚的に示されていないインタラクティブ要素
• 適切なHTML要素があるのに、意味のないdivを並べている

リトマスチェック

ビジュアル確認に進む前に、手早く自己レビューします。すべてのチェックがあらゆる状況に当てはまるわけではありません。どれが該当するかは判断してください。

• 最初の画面で、ブランドや製品がはっきりと伝わりますか？
• 強い視覚的な基準点が一つありますか？
• 見出しだけを流し読みして、ページの内容を理解できますか？
• 各セクションには、それぞれ明確な役割が一つありますか？
• カードは、使われている箇所で本当に必要ですか？
• 動きは階層や雰囲気を高めていますか。それとも、ただあるだけですか？
• 装飾的な影をすべて取り除いても、デザインに高級感がありますか？
• コピーはプロンプトのようではなく、製品らしい語り口になっていますか？
• 新しい制作物は既存のデザインシステムに合っていますか？（モジュール C）

---

ビジュアル確認

実装後、見た目を確認します。これは妥当性を確かめるものであり、ピクセル単位のレビューではありません。一度確認します。目立った問題があれば修正します。問題がなさそうであれば、次に進みます。

ツールの優先順位

最初に利用できる選択肢を使います。

1. 既存プロジェクトのブラウザーツール -- Playwright、Puppeteer、Cypress などがすでにプロジェクトの依存関係にある場合は、それを使います。確認のためだけに新しい依存関係を追加しないでください。
2. ブラウザー MCP ツール -- ブラウザー自動化ツール（例：claude-in-chrome）がエージェントの環境で利用できる場合は、それを使います。
3. agent-browser CLI -- ほかに利用できるものがなく、agent-browser がインストールされている場合は、それを使います。インストールされていない場合は、ユーザーに「agent-browser がインストールされていません。必要な依存関係をインストールするには /ce-setup を実行してください。」と伝えてから、次の選択肢に進みます。
4. 頭の中でのレビュー -- ブラウザーにアクセスできない場合（ヘッドレス CI、インストール権限がないなど）は、リトマスチェックに基づいて自己レビューし、ビジュアル確認を省略したことを記します。

確認する項目

• 出力は、ビルド前の計画で示したビジュアルの主旨に合っていますか？
• 明らかな視覚上の問題（レイアウトの崩れ、読めないテキスト、画像の欠落など）はありますか？
• コンテキストモジュールの意図に沿った見た目になっていますか（ランディングページはランディングページらしく、ダッシュボードはダッシュボードらしく、コンポーネントは周囲になじんでいますか）？

範囲の管理

反復は一度です。スクリーンショットを撮り、リトマスチェックに照らして確認し、目立った問題を修正して次に進みます。成果物にはスクリーンショットを含めます（PR の説明、会話の出力など）。

一度の確認を超える反復的な改善（スクリーンショットの確認と修正を複数回繰り返すこと）については、ce-design-iterator エージェントを参照してください。

---

創造性

このスキルは構成を提供しますが、目指すのは型にはまった出力ではなく、AI らしい粗雑さを避けた個性のある制作物です。

ゼロから作る場合は、大胆な美的方向性を選びます。雰囲気を検討してください。極限までミニマル、マキシマリスト、レトロフューチャー、有機的・自然、ラグジュアリー・洗練、遊び心のあるもの、エディトリアル、ブルータリスト、アールデコ、柔らかくパステル調、インダストリアルなど、あるいはコンテキストに合うものを考案します。表現の可能性は無限にあります。これらを発想の手がかりにしつつ、プロジェクトにふさわしいデザインを作りましょう。

問いかけてください。何がこの制作物を忘れがたいものにしますか？人々の記憶に残る、たった一つのものは何ですか？

実装の複雑さは、美的なビジョンに合わせます。マキシマリストなデザインには、豊富なアニメーションやエフェクトを盛り込んだ複雑なコードが必要です。ミニマリストなデザインには、節度と精密さ、そして余白、タイポグラフィ、細部への丁寧な配慮が必要です。優雅さは、強烈さではなく、ビジョンをうまく形にすることで生まれます。