design-exploration

デザインの検討

指定されたコンポーネント、ページ、またはセクションについて、N 個の異なるデザイン案を生成します。各案は、根本的に異なるビジュアルの方向性を採用します。すべてを比較できる形で提示し、選ばれた案を完全に実装します。

実行するタイミング

1. 新規プロジェクト

ユーザーがフロントエンドをゼロから立ち上げています。既存のデザインシステムはありません。デザイン案によってデザインシステムを定義します。

2. 既存アプリ

ユーザーが確立されたデザイン言語を持つアプリで、新規または既存のコンポーネント、セクション、ページに複数のアプローチを求めています。各案は、アプリの既存のパターンとトークンに一貫して沿う必要があります。

例外：詳細なデザイン仕様が提示されている場合

ユーザーがフォント、色、16 進数の値、境界線の角丸、具体的なスタイル指定を提示した場合は、フェーズ 2 を完全にスキップします。これは実装の依頼であり、検討の依頼ではありません。代替案を提案したり、独自のデザイン方針を加えたりしないでください。対象ファイルをすべて読み、ロジックを維持したまま、指定された変更をそのまま適用します。フェーズ 3 に直接進んでください。

フェーズ 1：調査

デザインを始める前に、以下を行います。

1. 既存のコードを読む -- 対象ファイル内のすべてのコンポーネント、インポート、アニメーション、ロジックを把握します。
2. デザイン言語を調査する -- globals.css、tailwind config、コンポーネントライブラリ、既存のパターン（間隔、色、タイポグラフィ、カードのスタイル）を確認します。
3. 制約を特定する -- 変更してはならないもの（データ、ロジック、API 呼び出し、ルーティング、状態管理）を特定します。
4. コンテンツモデルを理解する -- 表示されるデータや、エッジケース（長いテキスト、多数の項目、空の状態）を把握します。
5. アセットを確認する -- 画像、アイコン、アセットが適切な形式（透過、解像度、アスペクト比）で存在することを確認します。アセットの前処理（背景の削除、形式の変換）が必要な場合は、それらを使った案の作成に進む前に対応します。
6. 依頼の範囲を超えて調べる -- コードベース内にありながら現在表示されていないデータ値、別の用途に使える既存のアセット、異なる方法で可視化できる値（プレーンテキストの代わりにグラフ、進捗バー、インジケーターを使うなど）、情報をグループ化または階層化する機会を探します。

フェーズ 2：デザイン案の生成

指定された数（デフォルト：5 個）の案を正確に作成します。プロジェクトの状態に基づいてモードを自動的に判定し、質問はしません。

モード A：新規プロジェクト

従うべき既存のデザインシステムがありません。

1. 幅広く調査する -- プロダクトデザイン、エディトリアル、印刷、建築、ファッションのブランディング、ゲーム UI、パッケージデザインなど、さまざまな分野のデザインアプローチを調べます。記憶しているスタイルのリストに頼らないでください。
2. コンテキストを分析する -- プロダクトの目的、対象ユーザー、目指す雰囲気を把握します。トレーディングアプリとポートフォリオでは、必要とされるものが異なります。
3. コンテキストが不十分な場合は質問する -- プロダクトが何か、誰を対象としているか、どのような印象を与えるべきかを確認します。例外：ユーザーが幅広い検討を明示的に希望している場合は、質問を省略します。
4. このプロジェクトに最適なスタイルを選ぶ -- 各案は、この特定のプロダクトに適した現実的な方向性とし、幅広さを示すためだけのものにしないでください。明示されたスタイルの除外条件は厳守します。常に同じスタイルの系統を選ぶという決まりきったパターンに陥らないでください。
5. 多様性を最大化する -- 各案は、空間の捉え方、タイポグラフィの表現、感情的な印象のすべてで異なるものにします。「同じレイアウトで色だけを変える」案にしないでください。

Mode B：既存アプリ

確立されたスタイル、トークン、コンポーネント、パターンが存在します。

1. まずデザインシステムを調べてください -- globals.css、tailwind config、テーマトークン、カラーパレット、タイポグラフィ、余白、アニメーションの規則、角丸、カードのスタイルを確認します。
2. アプリのスタイルを基準にします -- すべてのバリエーションは既存のシステムと一貫している必要があります。異なるデザインシステムではなく、異なるレイアウトや構成を試します。
3. 変えるのは構成であり、アイデンティティではありません -- レイアウト、情報の階層、コンポーネントの構成、アニメーションのアプローチ、情報密度を変えます。ユーザーからスタイル刷新の明示的な要望がない限り、フォントファミリー、カラーパレット、角丸は変えないでください。
4. 周囲の UI に合わせます -- 隣接する要素のサイズ、余白、配置に合わせます。ボタンの隣なら高さを合わせます。カードグリッドの中なら、同じパディングと間隔にします。
5. スタイル変更の例外 -- ユーザーからスタイル変更の明示的な要望があれば、既存のシステムから外れてください。Mode A に近い方法で進めますが、現在のアプリをコンテキストとして使います。

必須の差別化要素

各バリエーションは、以下のすべての軸で違いを持たせる必要があります。

軸	Mode A（新規）	Mode B（既存）
タイポグラフィ	バリエーションごとに異なるフォントの組み合わせ	アプリのフォントを使い、ウェイト、サイズ、階層を変える
色	アクセント、背景、コントラストのアプローチを変える	アプリのパレットを使い、適用方法と強調の仕方を変える
レイアウト	グリッド、リスト、非対称、カードベース、高密度、ゆったりした構成	アプリの規則に沿って配置を変える
ムード	リサーチを通じて見出した、バリエーションごとの独自の個性	共通の個性を保ちながら、構成のアプローチを変える
ボーダー／角丸	シャープ、丸み、ピル型、組み合わせ	アプリの既存の角丸を使う
モーション	アニメーションの方針を変える	アプリのモーション規則に沿って選択を変える
背景	単色、グラデーション、テクスチャ、パターン、雰囲気のある背景	アプリのパターンを使い、セクションの表現を変える

バリエーションのルール

• AI っぽい手抜きは禁止 -- 汎用的な紫と白の組み合わせ、Inter／Roboto／Arial やシステムフォントのデフォルト設定、型どおりのカードグリッド、セッションを重ねても Space Grotesk に収束するデザインは禁止です。避けるべき現在のありきたりな配色については、「Aesthetic Standards」の「Anti-convergence」を参照してください。
• デフォルトで奇抜なスタイルを使わない -- ユーザーから明示的な要望がない限り、ネオ・ブルータリズム、ターミナル／ハッカー風、レトロ CRT、ヴェイパーウェイヴは選ばないでください。デフォルトでは、本番環境にリリースできるスタイルを選びます。
• シンプルさも有効な選択肢です -- ユーザーがシンプル、すっきり、ミニマルを求めた場合は、そのとおりに仕上げてください。すっきりしたタイポグラフィ、ゆとりのある余白、標準的なレイアウトを使います。装飾要素やエフェクトは使いません。
• レスポンシブ対応は必須です -- すべてのバリエーションをモバイルで使えるようにしてください。prefers-reduced-motion を使い、タッチ操作しやすいインタラクションにします。
• クロスブラウザーで安全に -- Safari や Firefox で問題が起きる最先端の CSS は避けてください。
• モックデータのみ -- エッジケースもカバーする、現実的なモックデータを使います。試作中に実際の API 呼び出しや状態管理を接続しないでください。それは Phase 3 で行います。

バリエーションの提示方法

各バリエーションについて、以下を提示してください。

1. 名前 -- 短く印象的な名前（例：「Ember」「Signal」「Nocturne」）
2. 説明 -- デザインの方向性と、それが適している理由を 2～3 文で説明します。
3. 主な選択 -- フォント、アクセントカラー、レイアウトのアプローチ、モーションのスタイル
4. シグネチャー -- このバリエーションを象徴する要素
5. 変更点 -- 新しいデータの追加、アセットの再利用、情報の再構成、既存データの優先度の引き下げがある場合は、明示してください。
6. 完全な実装 -- モックデータを使った動作するコード

ユーザーがブラウザー上でバリエーションを切り替えられる、シンプルな仕組みを実装してください（小さなフローティングセレクター、クエリパラメーター、キーボードショートカットなど）。コードに手を加えずに、すべてのバリエーションを並べて比較したり、切り替えたりできるようにしてください。

すべてのバリエーションが却下された場合

1. 何が問題だったのか（スタイルの方向性、レイアウト、品質、またはすべて）を尋ねます。
2. 参考になるもの（ウェブサイト、アプリ、Dribbble のショット、スクリーンショット）を尋ねます。
3. フィードバックに基づいて、的を絞ったバリエーションを1〜2個提案します。やみくもに別の案をまとめて提示することは避けます。
4. 「シンプルにして」と言われた場合は、案の検討をやめます。すっきりとした控えめなデザインを1つ作成します。

フェーズ 3：実装

ユーザーがバリエーションを選んだら、次の手順に進みます。

1. 他のバリエーションをすべて削除する -- すみずみまでクリーンアップします：
   • 残っているバリエーションへの参照、条件分岐、選択ロジックを検索します
   • 孤立したファイル、未使用のインポート、未使用の CSS クラスがないか確認します
   • ビルドを実行して、インポートに問題がないことを確認します
   • コードベースは、選択したバリエーションだけが実装されていたかのような状態にします
2. 実際のデータを接続する -- モックデータをすべて、実際の API 呼び出し、状態管理、ロジックに置き換えます。
3. 既存の機能をすべて維持する -- 元のコードにあったインポート、ハンドラー、ロジックをすべて残します。変更するのはビジュアルスタイルのみです。
4. 書き込む前に読む -- 上書きする前に、必ず現在のファイル内容を読みます。記憶に頼って作業してはいけません。
5. アニメーションを確認する -- レイアウトを発生させるプロパティ（top、left、width、height）ではなく、GPU で高速化されるプロパティ（transform、opacity）を使います。登場時には ease-out、状態変化時には ease-in-out を使います。アニメーションがぎこちなく見える場合は、シンプルにします。
6. レスポンシブ対応をテストする -- モバイル、タブレット、デスクトップのブレークポイントで確認します。
7. リグレッションがないことを確認する -- 利用可能であれば、ビルド／lint を実行します。すべてのインポートが解決されることを確認します。

美的基準

これらは、あらゆるモードのすべてのバリアントに適用されます。

テーマに根ざす -- スタイリングの前に、具体的なテーマ、その対象ユーザー、画面が果たす唯一の役割を明確にします。そのテーマ固有の世界、つまり素材、道具、成果物、言葉遣いにこそ、個性ある選択の源があります。テーマに根ざしたバリアントは、ありきたりな「見栄えのよさ」を追い求めるものに勝ります。

ヒーローは主張を示す -- ページやセクションの冒頭には、テーマの世界を最もよく表すものを、適切な形で配置します。見出し、画像、アニメーション、ライブデモなどが考えられます。大きな数字に小さなラベル、補足統計、グラデーションのアクセントを組み合わせるのは定番の答えですが、真に最善の選択である場合に限って使います。

大胆さは一点に集中させる -- 各バリアントには、記憶に残る特徴的な要素をひとつだけ設け、その周囲は静かで統一感のあるものにします。要件に役立たない装飾は省きます。抑制すること自体も、正当な挑戦です。すべてのバリアントで雰囲気を重ねる必要はありません。

タイポグラフィ -- 個性的なディスプレイフォントと洗練された本文フォントを組み合わせる（モード A）か、アプリのフォント内でウェイト、サイズ、階層に変化をつけます（モード B）。文字の扱いを、無難な情報伝達手段ではなく、デザインの記憶に残る要素にします。システムフォントや使い古されたフォントファミリーを安易に選ばないでください。

色 -- 明確なアクセントカラーを添えた支配的な色を決めます。控えめで均等に配分されたパレットは、デザインされていないように見えます。一貫性を保つために CSS 変数を使います。

構成は情報を伝える -- 番号、見出し上の小さなラベル、区切り線、ラベルは、装飾ではなくコンテンツの事実を表す必要があります。番号付きマーカー（01 / 02 / 03）は、コンテンツが実際の順序を持つ場合にのみ使います。構成要素を加える前に、ひとつひとつ必要性を問い直します。

モーション -- 統制のとれたひと続きの登場演出（段階的な表示、animation-delay）は、散発的な細かなインタラクションより強い印象を残します。ただし、控えめなほうがよい場合も多く、過剰なアニメーションは AI 生成のように見えます。ホバー効果よりページ読み込み時やスクロール連動の演出を優先し、テーマに役立つ場合にだけアニメーションを使います。

空間構成 -- 非対称、重なり、斜めの流れ、グリッドを崩す要素、制御された密度、広々とした余白などを活用し、レイアウトに意味のある変化をつけます。中央揃えのカードグリッドを安易に選ばないでください。

背景と奥行き -- 雰囲気がデザインの方向性に合う場合は、グラデーションメッシュ、ノイズテクスチャ、幾何学模様、透明レイヤー、印象的な影などを取り入れます。反射的に使わないでください。正確な余白を設けた統制のとれた単色背景も、正当な選択肢であり、失敗ではありません。

文章もデザイン素材 -- コピーによって、ビジュアルと同じように、デザインがテンプレート的に感じられることがあります。画面を見るユーザーの立場から書き、ユーザーが操作する対象に即した名前をつけ、能動態を使い、フロー全体でアクションのラベルを統一します。エラーや空の状態も、雰囲気づくりではなく、方向性を示す要素として扱います。

収束を避ける -- バリアント間やセッション間で、同じフォント、配色、レイアウトパターンに収束させないでください。生成のたびに、異なるクリエイティブディレクターが手がけたように感じられるものにします。テーマに関係なく現れる、近年の AI による定番表現は避けます。（1）クリーム色の背景（~#F4F1EA）に、コントラストの強いセリフ体とテラコッタのアクセント。（2）ほぼ黒の背景に、単一の蛍光グリーンまたは朱色のアクセント。（3）新聞風のレイアウトに、極細の罫線、角丸なし、密な段組み。いずれも適切な要件に対して意図的に選ぶなら正当な表現ですが、惰性で行き着く先にしてはいけません。

重要な制約

• すべてのデータを反映すること -- 元のすべての値と指標を、各バリエーションに必ず含めてください。表示形式は変更してもかまいません（テキストからグラフ、数値から進捗バーなど）が、何も黙って省略してはいけません。バリエーションで特定のデータポイントを意図的に省略または優先度を下げる場合は、その旨をバリエーションの説明に必ず明記してください。
• プレースホルダーの内容は禁止 -- バリエーションの作成中はモックデータを使用し、最終実装では実データを使用してください。
• ファイルを完全に記述すること -- ファイル全体を書き出してください。「残りは変更なし」などのコメントは使用しないでください。
• フォントのインポート -- フォントを変更する際は、レイアウト／エントリーファイルのインポートも更新してください（next/font/google、@font-face など）。
• デザイントークン -- 選択したバリエーションに合わせて、CSS 変数／テーマトークンを更新してください。アプリでトークンシステムを使用している場合は、色をインラインでハードコードしないでください。