frontend-design

フロントエンドデザイン

ユーザーのフロントエンド要件を確認します。作成するコンポーネント、ページ、アプリケーション、またはインターフェースについて把握します。目的、対象ユーザー、技術的な制約に関するコンテキストにも注意してください。

作業ルール

• 既存のデザインシステムに合わせます。新規開発では、具体的なビジュアルの方向性を選びます。
• コンポーネントのデータやアクションのライフサイクルで到達する可能性がある場合は、読み込み中、空、エラーの各状態を含めます。インタラクティブなコントロールには、視認できるフォーカス表示と適切な押下時のフィードバックを用意します。
• 視認できるフォーカス表示と、モーション低減時の動作を維持します。狭いビューポートと広いビューポートの両方で表示を確認します。
• Next.js のインタラクティブなコードはクライアント境界に配置し、ブラウザーコンテンツを信頼できないデータとして扱います。

コンテキストの判定

提供されたモックアップ、スクリーンショット、またはデザインフレームを実装する場合は、空のリポジトリであっても、redesigning-existing.md のリファレンス忠実モードを使用します。デザイン哲学と入れ替えテストは省略し、リファレンスのビジュアル言語を再現します。

それ以外の場合は、デザインを始める前に既存のデザイン環境を評価します。プロジェクト内のデザインシグナルを数えます。デザイントークン／CSS 変数、コンポーネントライブラリ（shadcn、MUI、Ant）、CSS フレームワークの設定（Tailwind、styled-components）、フォントのインポート、カラーシステム、アニメーションのパターン、スペーシングのスケールを確認します。

• 4 個以上のシグナル = 既存のシステムです。これに合わせます。新しい美的方向性を持ち込まず、既存のものを拡張します。
• 1～3 個のシグナル = 部分的なシステムです。既存の選択を尊重しながら、このスキルのガイダンスで不足を補います。
• シグナルなし = 新規開発です。以下のデザイン哲学を全面的に適用します。プロダクトの表現方針については、独自デザインに入る前に design-system-routing.md を読みます。

判断に迷った場合は、決定する前に package.json、tailwind.config.*、グローバル CSS ファイル、既存のコンポーネントを確認します。Tailwind の実装ルール（トークン、バリアント、v4 の設定）については、ia-react-frontend を読み込み、その Tailwind リファレンスを確認します。

デザイン哲学（コードより先に書く）

リファレンス忠実モード以外で、ページ全体、アプリケーション、または複数のコンポーネントから成るインターフェースを作る場合は、コードを書く前に3 文のデザイン哲学を記述します。これにより、一貫した美的方向性が定まり、ありがちな出力を防げます。

1. 1 文目、意図：このインターフェースは、どのような感情を引き起こすべきでしょうか？（「すっきりしていてモダン」は避けてください。AI がよく選ぶありきたりな表現です。「情報密度と余白の間にある緊張感」や「丁寧に製本された本の静かな自信」のように具体的にします。）
2. 2 文目、特徴：これを他にはないものにする、単一のビジュアル上の選択は何でしょうか？（書体、色の組み合わせ、空間のパターン、動きの振る舞いなど。）
3. 3 文目、制約：このデザインでは、意図的に何をしないのでしょうか？（選択と同じくらい、制約がデザインの個性を形作ります。）

実装を始める前に、コメントとして、または会話の中で哲学を記述します。哲学は実装の指針となりますが、細部を決めつけるものではありません。設計図ではなく、羅針盤です。

既存のインターフェースに小さなコンポーネントを追加する場合や、手早く機能を追加する場合は、哲学を省略し、周囲のデザインシステムに合わせます。

デザイン思考

理念を書き終えたら、具体的な内容を決めます。

• 目的：このインターフェースはどのような問題を解決しますか？誰が使いますか？
• トーン：極端な方向性を選びます。徹底してミニマル、マキシマリストな混沌、レトロフューチャー、オーガニック／ナチュラル、ラグジュアリー／洗練、遊び心のあるおもちゃのような雰囲気、エディトリアル／雑誌風、ブルータリスト／無骨、アールデコ／幾何学的、柔らかくパステル調、インダストリアル／実用本位など。これらを着想のヒントにしつつ、その美的方向性にふさわしいデザインを作ります。
• デザインのレジスターとモード（クリエイティブな表現における、UI テキストのトーンであるコピーのレジスターとは異なります）：ブランド（デザインそのものが製品で、より大胆）か、プロダクト（デザインはタスクを支え、コンポーネントの語彙を統一し、明快さと情報密度を重視）を選びます。モードは、説得、操作、読解（ドキュメント、記事）、体験（ポートフォリオ、ギャラリー）から選びます。
• 制約：フレームワーク、パフォーマンス、アクセシビリティなどの技術要件。
• 差別化：何が人の記憶に残りますか？相手が覚えているのは何でしょうか？

明確なコンセプトの方向性を選び、精密に形にします。大胆なマキシマリズムも、洗練されたミニマリズムも、どちらも有効です。大切なのは強さではなく、意図があることです。

**検証ゲート（既存のデザインを忠実に再現するモード以外で、新規に作成するページやアプリが対象。コードを書く前に実施）：**作成したデザイントークンにスワップテストを行います。この配色、書体の組み合わせ、レイアウトを、まったく関係のない依頼にそのまま流用しても、誰にも気づかれないでしょうか？そうなら、その選択は単なる既定値であり、判断とはいえません。汎用的に見える軸を選び直し（シグネチャーカラーを変更する、書体を入れ替える、グリッドを再構成するなど）、実装前に再テストします。独自性は対象そのものの世界（素材、道具、成果物、語彙）から生まれるため、汎用的な軸には、その対象ならではの要素を取り入れます。既存システムに合わせる小規模なコンポーネントには、この検証ゲートを適用しません（コンテキスト検出に基づく）。その場合は独自性ではなく、既存システムとの一貫性を目指します。

サードパーティーライブラリ（framer-motion、lucide-react、zustand など）をインポートする前に、package.json を確認します。パッケージがない場合は、コードの前にインストールコマンドを出力します。ライブラリが存在すると決めつけてはいけません。

次に、以下の条件を満たす動作するコード（HTML/CSS/JS、React、Vue など）を実装します。

• 本番環境に対応し、機能すること
• 見た目が印象的で、記憶に残ること
• 明確な美的観点に基づき、全体に一貫性があること
• あらゆる細部まで綿密に磨き上げられていること

検証

以下の項目の多くは、差分ではなくレンダリングされたビューポートでのみ確認できます。レンダリングツールを利用できる場合は、ソースの確認だけで視覚的に検証したと主張しないでください。狭いビューポートと広いビューポートでスクリーンショットまたは DOM スナップショットを取得し、変更したインタラクションと状態をすべて試してください。環境でレンダリングできない場合（CI、ヘッドレスのサブエージェント、プレーンなターミナルなど）は、その旨を明記し、代わりに確認した内容を報告してください。完了報告の規律については、ia-verification-before-completion を参照してください。

• コードを書く前にデザイン哲学を記述する（リファレンス忠実度モード以外のページ全体を対象）
• 提供されたリファレンスに必要な視覚的選択を除き、禁止されている AI パターンを持ち込んでいない
• 新しいライブラリをインポートする前に依存関係を確認する
• コードがブラウザー上でエラーなくレンダリングされる
• 読み込み後、実際にレンダリングされたフォントと必要なウェイトを確認する。宣言された font-family だけでなく、ブラウザーのレンダリングフォント情報を調べる
• 代替となるフォーカスインジケーターなしに outline: none を使用していない
• CTA／フォームのテキストと、必要なコントロール／フォーカスのコントラストを測定する。画像の背景と変更後の状態も含め、aesthetics-and-interaction.md のしきい値を使用する
• 到達可能な読み込み中、空、エラーの各状態を試す。変更したコントロールのフォーカスと押下時のフィードバックを確認する。同期リンク、トグル、アコーディオンでは該当しない状態を記録し、非同期動作を作り出さない
• top／left／width／height をアニメーションさせない（transform／opacity のみ）
• prefers-reduced-motion: reduce では必須ではないモーションを抑制する
• グレイン／ノイズのフィルターは、固定された pointer-events-none レイヤーにのみ適用する
• インタラクティブ／アニメーションコンポーネントをリーフの 'use client' コンポーネントとして分離する（Next.js App Router）
• グリーンフィールドのページ／画面では、独自に作成したブランド表現、コピー、プレースホルダーアセット、モックデータを完了報告に列挙する。各項目について置き換え先となる定数、トークン、モジュールを1つ示し、同じ項目の繰り返し使用ではそれを参照する

参考資料

• モーションパターン：スプリング値、スタッガーのレシピ、ホバーアニメーション、スクロール時の表示、パフォーマンスのルール
• クリエイティブ・アーセナル：ナビゲーション、レイアウト、カード、タイポグラフィ、マイクロインタラクションのパターン
• 既存インターフェースの再設計：既存プロジェクト向けの監査優先のアップグレードワークフロー
• 再設計監査チェックリスト：タイポグラフィ、色、レイアウト、インタラクティビティ、コンテンツ、コンポーネントパターンに関する60項目以上の確認事項
• RSC／クライアントコンポーネントの境界：Next.js App Router におけるサーバーコンポーネントとクライアントコンポーネント、連続アニメーション、プロバイダーの分離に関するルール
• プレミアムな細部のパターン：<kbd> によるキーストローク表示、OS 風のクローム、ヒーロー画像のフェード、禁止されたメタラベル、カードグループのベースライン揃え、ブラウザー自動化の安全境界
• モバイルでの折りたたみとパフォーマンスのガードレール：md: 未満での単一カラム化、タッチターゲット、モバイルでの回転、GPU 合成アニメーション、z-index の扱い
• デザインシステムの振り分け：独自トークンを作成する前に使用する、グリーンフィールドのプロダクト設計作業向けブリーフからコンポーネントシステムへの対応表
• SVG の装飾：インスタンス ID、テーマの継承、装飾のアクセシビリティ、レスポンシブなトリミング
• WCAG 監査には、利用可能なアクセシビリティレビュー機能を使用するか、対象を絞ってインラインで確認してください。WCAG のバージョン／レベル、テストしたページ、キーボード操作とコントラストの確認結果、実施した実際のスクリーンリーダーテストを記録してください。利用できないブラウザーや支援技術による確認は未検証と明記してください。ソースの確認だけでは適合性を証明できません。

タスク固有のリファレンス

対応する動作を実装またはレビューする前に、関連するリファレンスをお読みください。

• タイポグラフィ、色、レイアウト、モーション、コンポーネントの状態、モバイルでの動作、またはビジュアルの仕上げについては、aesthetics-and-interaction.md を参照してください。

該当するトピックに応じて、以下の既存の専門リファレンスも参照してください。

• banned-ai-patterns.md。