frontend-design について
frontend-designは、単独コンポーネントからアプリ全体まで、本番品質のインターフェースを作るスキルです。文脈に沿ったビジュアル設計、実装指針、具体的なアクセシビリティと品質の確認項目を備えています。
主な機能
- 01ページまたはコンポーネントの責務を計画
- 02明確なビジュアル方針を選定
- 03動作するフロントエンドコードを作成
- 04タイポグラフィ、色、動き、レイアウトの指針
- 05アクセシビリティと実装品質の自己確認
活用シーン
- 01レスポンシブなアプリページの設計
- 02独立した再利用可能コンポーネントの構築
- 03インターフェースのアクセシビリティと実装品質の点検
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ waybarrios/ opencode-power-pack --skill frontend-designインストール後、Claude Code で/frontend-designを入力して読み込まれたか確認します。
詳細
このスキルでは、ありがちな「AI っぽい」見た目を避け、独自性のある本番品質のフロントエンドインターフェースを作成する方法を説明します。細部の美しさと創造的な工夫に徹底的にこだわって、実際に動作するコードを実装し、提出前に自己批評の評価基準に照らして監査します。
ユーザーは、構築するコンポーネント、ページ、アプリケーション、またはインターフェースのフロントエンド要件を提示します。目的、対象ユーザー、技術上の制約などの背景情報が含まれる場合もあります。
範囲と要件
デザインを検討する前に、依頼を分類し、適切な責任範囲を計画します。構造、動作、連携、アクセシビリティに大きく影響する情報が不足している場合に限り質問します。要件が十分であれば、追加のやり取りなしで進めます。
- ページまたはアプリケーション:ユーザージャーニー、情報設計、コンテンツの階層、ナビゲーションとルートのコンテキスト、ページレベルの状態、ビューポート全体に対応するレスポンシブな構成、統一感のあるビジュアルコンセプトを計画します。
- 独立したコンポーネントまたは再利用可能なコンポーネント:責務、公開する入力とコンテンツ、イベント、バリエーション、該当する場合は読み込み中・空・エラー・無効・選択済みの各状態、ホスト環境、固有のサイズ設定、キーボード操作とフォーカスのセマンティクス、トークン、コンポジションの境界を計画します。
- ハイブリッドな作業:両方のレイヤーを計画し、ページが担う要件を再利用可能なコンポーネントの内部に持ち込まないようにします。
この後のデザイン検討、実装、一般化を避けるための指針、自己批評、任意の検証は、いずれの進め方でも共通です。これらの段階を進め方ごとに重複させないでください。
デザインの検討
コーディングを始める前に背景を把握し、大胆な美的方向性を決めます。
- 目的:このインターフェースはどのような問題を解決しますか?誰が使いますか?
- 雰囲気:極端な方向性を選びます。極めてミニマル、マキシマリストな混沌、レトロフューチャー、オーガニック/ナチュラル、ラグジュアリー/洗練、遊び心のあるおもちゃ風、エディトリアル/雑誌風、ブルータリスト/粗削り、アールデコ/幾何学的、柔らかい/パステル調、インダストリアル/実用本位など、多くの選択肢があります。これらを発想のヒントにしつつ、選んだ美的方向性に忠実なデザインを作ります。
- 制約:技術要件(フレームワーク、パフォーマンス、アクセシビリティ)。
- 差別化:記憶に残るものにする要素は何ですか?見る人が覚えている、ひとつのポイントは何ですか?
重要:明確なコンセプトの方向性を選び、精密に実現します。大胆なマキシマリズムも洗練されたミニマリズムも適しています。重要なのは強さではなく、意図が明確であることです。
次に、以下の要件を満たす実際に動作するコード(HTML/CSS/JS、React、Vue など)を実装します。
- 本番品質で、機能すること
- 視覚的に印象的で、記憶に残ること
- 明確な美的視点のもと、全体に一貫性があること
- 細部まで丁寧に磨き上げられていること
フロントエンドの美学に関するガイドライン
以下に注力してください。
- タイポグラフィ:美しく、個性的で、興味を引くフォントを選びます。Arial や Inter のようなありふれたフォントは避け、フロントエンドの美しさを高める、個性と趣のある意外性のあるフォントを選びましょう。個性的なディスプレイフォントと、洗練された本文用フォントを組み合わせます。
- 色とテーマ:一貫性のある美学を貫きます。一貫性を保つために CSS 変数を使いましょう。控えめで均等に配色されたパレットよりも、主役となる色に鮮やかなアクセントを加えた配色が効果的です。
- モーション:エフェクトやマイクロインタラクションにアニメーションを使います。HTML では CSS だけで実現できる方法を優先します。利用可能な場合は、React で Motion ライブラリを使います。インパクトの大きい場面に注力しましょう。段階的に表示する(animation-delay)演出を組み合わせた、よく練られたページ読み込み時のアニメーションは、散発的なマイクロインタラクションよりも大きな楽しさを生み出します。スクロール時の演出や、意外性のあるホバー状態も活用しましょう。
- 空間構成:意外性のあるレイアウト。非対称性。重なり。斜めの流れ。グリッドからはみ出す要素。ゆとりある余白、または計算された密度。
- 背景とビジュアルの細部:単色をデフォルトにするのではなく、雰囲気と奥行きを生み出します。全体の美学に合う、文脈に即したエフェクトやテクスチャを加えましょう。グラデーションメッシュ、ノイズテクスチャ、幾何学模様、重ね合わせた透明表現、印象的なシャドウ、装飾的なボーダー、カスタムカーソル、粒状感のあるオーバーレイなど、創造的な表現を取り入れます。
よく使われるフォントファミリー(Inter、Roboto、Arial、システムフォント)、ありきたりな配色(特に白い背景に紫のグラデーション)、予測可能なレイアウトやコンポーネントのパターン、文脈に即した個性のない型にはまったデザインなど、ありふれた AI 生成の美学は絶対に使わないでください。
創造的に解釈し、文脈に合った、本当にデザインされたと感じられる意外性のある選択をしてください。どのデザインも同じにしてはいけません。ライトテーマとダークテーマ、さまざまなフォントや美学を使い分けてください。世代を重ねるごとに、よくある選択肢(たとえば Space Grotesk)へ収束することは絶対に避けてください。
重要:実装の複雑さを、美学上のビジョンに合わせてください。マキシマリストなデザインには、豊富なアニメーションやエフェクトを含む精巧なコードが必要です。ミニマリストまたは洗練されたデザインには、抑制、精密さ、余白、タイポグラフィ、繊細な細部への細心の注意が必要です。ビジョンを巧みに実現することが、エレガンスにつながります。
忘れないでください。モデルには、並外れた創造性を発揮する力があります。常識にとらわれず、個性的なビジョンを徹底的に追求したときに何が生み出せるのか、遠慮せず示してください。
具体的な工夫(デフォルトに逆らう)
モデルは放っておくと、統計的な中心へと流れていきます。白い背景、青または紫のボタン、Inter書体、中央に配置された1枚のカード、あるいは3列のグリッドです。それぞれのデフォルトに、意識して逆らいましょう。
- タイポグラフィ:方向性に合った、特徴的な書体を1つ選びましょう。エディトリアルなら Fraunces、Playfair Display、Crimson Pro、プロダクトなら Clash Display、Satoshi、Cabinet Grotesk、テクニカルなら IBM Plex、Source Sans 3、コードなら JetBrains Mono、Fira Code などです。はっきりとしたコントラストをつけましょう。極端なウェイトの組み合わせ(400対600ではなく、200対800)や、3倍以上のサイズ差を使います。Space Grotesk は避けましょう。優れた書体ですが、収束の罠としてよく知られています。
- レイアウト:中央揃えのカラムに戻るのではなく、作り始める前にレイアウトの型を決めましょう。ベン・トーグリッド、分割画面、非対称またはブロークングリッド、マガジン、サイドバーなどです。ベン・トーグリッド(ブロックのサイズに変化をつけ、最も大きな要素を先に配置する)を使うと、ありきたりな「AI」風の見た目にせず、ダッシュボードに構造を与えられます。
- 色:控えめに均等配分したパレットより、支配的な色に鋭いアクセントカラーを1色組み合わせるほうが効果的です。ありきたりなブランドブルーではなく、IDEのテーマや、特定の文化・時代の美学など、具体的なものを基準にしましょう。また、役立つ場面では色に意味を持たせます。
- トークンとテーマ設定:色、スペース、角丸、シャドウの値はすべてCSSカスタムプロパティ経由で指定し、マジックナンバーをあちこちに散らさないようにしましょう。ダークモードはスタイルを再設定するのではなく、
.darkの下でこれらの変数を再定義して実装します。ユーザーがすでにブランドやデザインシステムを持っている場合は、そのトークンを取り込み、デフォルトは一切使わないようにしましょう。 - 形容詞より具体的な着想を:「モダンでクリーン」のような表現は、結局デフォルトに逆戻りします。素材、時代、ソフトウェアなど、具体的なものを参考にしましょう。
- 生成ごとに変化をつける:上記の書体やレイアウトのリストは、毎回選ぶためのメニューではなく、出発点です。ローテーションして使いましょう。同じ方向性、書体の組み合わせ、パレットを繰り返さないでください。以前扱ったものに似た依頼でも、意図的に違いを出しましょう。異なるプロダクト向けの2つのインターフェースが、同じテンプレートだとすぐにわかるようではいけません。個々の出力がそれぞれ良く見えても、出力全体が同じような見た目になること自体が失敗です。
返す前の自己批評
モデルは平凡な出力を自信満々に褒める傾向があるため、「これはよさそうか?」と自問しないでください。代わりに、以下の具体的な合否チェックを実施し、コードを返す前にすべての不合格項目を修正してください。これらは WCAG 2.2 AA と基本的な品質を対象としています。好みの問題ではなく、マークアップから確認できる項目です。
アクセシビリティ:
- 本文テキストのコントラスト比は 4.5:1 以上です。大きなテキスト(24px 以上、または太字で 18.66px 以上)、UI コントロールの境界線、意味のあるアイコンは 3:1 以上です。意味を色だけで伝えることはありません。
- セマンティクスにはネイティブ要素を使用します。アクションには
<button>、ナビゲーションには<a href>、入力には実際の<label>を使います。ページまたはドキュメントには<h1>がちょうど 1 つあり、見出しは順序どおりで、適切な<header>、<nav>、<main>、<footer>ランドマークがあります。コンポーネントは、ネイティブコントロール、ラベル、アクセシブルな名前、コンポーネント内の見出し順を管理します。この基準を満たすためだけに、ドキュメントレベルの<h1>、グローバルなランドマーク、<meta name="viewport">を追加することはありません。 - すべての
<img>にalt属性があります(装飾目的の場合は空のalt="")。アイコンのみのコントロールにはアクセシブルな名前があります。 - ARIA の第一の原則:ARIA ロールよりネイティブ要素を優先します。誤った ARIA より、ARIA を使わないほうが適切です。
- すべてのインタラクティブ要素はキーボードで操作でき、視認できるフォーカスインジケーターを表示します。各コンポーネントはキーボード操作とフォーカスの動作を管理します。より強力な代替手段なしに、デフォルトのアウトラインを削除してはいけません。
- ページまたはドキュメントには
<meta name="viewport">があり、ズームを無効にしていません。ページレベルのコンテンツは、幅 320px まで単一カラムにリフローし、ページ全体の横スクロールが発生しません。コンポーネントはホストまたはコンテナー内でリフローします。本質的に二次元のコントロールでは、意図しないページのはみ出しを防ぎ、キーボード操作を維持しながら、必要な内部スクロールを許容できます。
品質:
- 文字サイズは意図的なスケールに従い、本文の
line-heightは 1.5 以上です。行の長さは 45~75 文字程度に保ち、サイズにはrem/emを使用します。 - 余白は、一貫したスケール(4/8px 刻みまたはトークン)に従い、その場しのぎの値を使いません。
@media (prefers-reduced-motion: reduce)ブロックで、必須でない動きを弱めるか取り除きます。1 秒間に 3 回を超えて点滅するものはありません。- 汎用的なデフォルトの特徴を残しません。Inter/Roboto/Arial を使わず、白地に紫のグラデーションにせず、依頼内容に合わないのにカードを 1 枚だけ中央に配置することもありません。
- 結果がデフォルトのテンプレートのように見えたり、以前の生成物のように見えたりしてはいけません。よくあるパターンや、すでに作成したものに似ている場合は、レイアウトの種類、フォントの組み合わせ、または配色を変えて、再生成してください。
任意の検証
任意の検証で、npm を使ってクロスプラットフォームで実行できます(Windows、Linux、macOS)。利用可能なものを使い、残りは問題なくスキップしてください。これらを必須条件にしないでください。
- 静的検証、ブラウザー不要:
npx html-validate <file>は、不正なマークアップ、altの不足、ラベルのないコントロール、誤った ARIA や冗長な ARIA を検出します。完全にオフラインで実行でき、最も手軽な最初のチェックです。 - レンダリング後の DOM(ヘッドレスブラウザーが必要):
npx pa11y --standard WCAG2AA <url>(または axe-core)を使うと、ページのレンダリング後に初めて判明する、計算済みコントラストやアクセシブルな名前を検証できます。 - 視覚情報のみを使った自己批評ループ(任意):ビジョン対応モデルを使用し、ヘッドレスブラウザーを利用できる場合は、Playwright(ユーザーのシステムブラウザーではなく、同梱の分離された Chromium、Firefox、または WebKit)で結果をレンダリングしてスクリーンショットを撮り、上記の基準と照らし合わせて画像を批評し、条件を満たすまで反復してください。テキストのみを扱うモデルの場合は、スクリーンショットをスキップし、コードを直接確認してください。
メモ
ここに記載するガイダンスは、Anthropic のフロントエンド美学に関するクックブック、"Harness design for long-running application development"(2026-03-24)にあるジェネレーター/評価器のパターン、ならびに Vercel v0 と shadcn/ui のテーマ設定をもとに、統合して言い換えたものです。アクセシビリティの基準値は WCAG 2.2 と MDN に基づいています。対象は、コントラストの 1.4.3 と 1.4.11、リフローの 1.4.10、テキスト間隔の 1.4.12、フォーカスの可視化の 2.4.7 です。2026-05-27 に検証済みです。