interface-design

インターフェースデザイン

一流のデザインチーム――Linear、Vercel、Stripe、Appleのような――の技術で、プロダクトのインターフェースを構築します。彼らと汎用的な出力の違いは、才能ではありません。すべての判断がきちんと決定され、階層が明確で、何百もの細部が一度に正しく整っていることです。このスキルで、そこに到達できます。

対象範囲

使う場面： ダッシュボード、管理パネル、SaaS アプリ、ツール、設定ページ、データインターフェース。

使わない場面： ランディングページ、マーケティングサイト、キャンペーン、ブランドのみの制作。それらには、マーケティング／フロントエンドデザインのスキルを使ってください。

このスキルだけで完結できます。方向性、ビジュアルの階層、デザインシステムのアーキテクチャ、本番品質の UI をリリースするために必要な仕上げとモーションの要点が、すべてここにそろっています。

---

問題点

汎用的な出力を生成してしまうでしょう。あなたの学習データには何千ものダッシュボードが含まれており、そのパターンは強固です。ドメインを探り、特徴を名付け、意図を明示するというプロセスをすべて踏んでも、テンプレートのようなものを生み出してしまうことがあります。冷たい構造に暖色を合わせ、ありきたりなレイアウトに親しみやすいフォントを合わせたものです。

これは、意図が文章に宿る一方で、コード生成がパターンを引き出すから起こります。その隔たりで、デフォルトが勝ってしまうのです。プロセスは助けになりますが、技術の高さを保証するものではありません。自分の出力を見直し、デフォルトにはない具体的な工夫を知っておく必要があります。

基準： 同じようなプロンプトを与えられた別の AI が、実質的に同じ出力を生成するなら、あなたは失敗しています。単に違いを作るために違うのではありません。このユーザー、このタスク、この世界からインターフェースが生まれた結果として、違いが生まれるのです。デフォルトからデザインすると、デフォルトが共有されているため、すべてが同じに見えます。

---

デフォルトが潜む場所

デフォルトはインフラのような顔をしています。デザインするのではなく、ただ動けばよいと感じる部分に潜んでいます。

• タイポグラフィは容器のように感じられます。 しかし、文字はデザインを支えているのではなく、文字そのものがデザインです。見出しの太さ、ラベルの個性、段落の質感は、誰かが一言でも読む前にプロダクトの印象を形作ります。いつものフォントを選ぶなら、デザインしていないということです。
• ナビゲーションは足場のように感じられます。 しかし、ナビゲーションこそがプロダクトです。今どこにいるのか、どこへ行けるのか、何が重要なのかを示します。空間に浮かぶページはコンポーネントのデモであって、ソフトウェアではありません。
• データは見せ方の問題に感じられます。 しかし、画面に表示された数字だけではデザインとは言えません。それを見る人にとって、それは何を意味するのでしょうか。進捗リングと積み重ねたラベルは、どちらも「10個中3個」を示せます。一方は物語を伝え、もう一方は空間を埋めます。
• トークン名は実装の細部に感じられます。 しかし、--ink と --parchment は世界観を想起させます。一方、--gray-700 と --surface-2 が想起させるのはテンプレートです。トークンだけを読んだ人にも、どんなプロダクトなのか見当がつくべきです。

構造上の判断などありません。すべてがデザインです。「なぜこれなのか？」と問うのをやめた瞬間に、デフォルトが支配し始めます。

---

まず意図を明確にする

コードに触れる前に、次の問いに答えてください。方向性についてユーザーの確認が必要な場合を除き、簡潔な作業メモにまとめます。

• この人は誰ですか？「ユーザー」ではありません。実際の人物です。この画面を開くとき、どこにいますか？ 5分前に何をしていて、5分後には何をするでしょうか？ 朝7時にコーヒーを飲む教師と、深夜にデバッグする開発者と、投資家との面談の合間にいる創業者は、それぞれ異なります。
• 何を達成しなければなりませんか？ 動詞で答えます。提出物を採点する。壊れたデプロイを見つける。支払いを承認する。答えによって、何を前面に出し、何を後に回し、何を隠すかが決まります。
• どんな印象にすべきですか？ 意味のある言葉で表現します。「すっきりしてモダン」では何も伝わりません。どのAIもそう言います。ノートのように温かく？ ターミナルのように冷たく？ トレーディングフロアのように密度高く？ 読書アプリのように落ち着いて？ これが色、書体、余白、情報密度など、あらゆる要素を形づくります。

プロンプトが曖昧すぎて人物、タスク、印象を特定できない場合は、簡潔な質問を1つしてください。責任を持って仮定できる文脈がある場合は、簡潔に明示して作業を進めます。

意図は一貫して反映させる必要があります。「温かい」と言いながら冷たい色を使うのは、意図に沿っていません。温かさが意図なら、面、テキスト、境界線、アクセント、意味を表す色、書体のすべてに温かさを反映します。密度が意図なら、余白、文字サイズ、情報設計のすべてを密度高くします。すべてのトークンが明示した意図に沿っているか確認してください。レイアウト、色温度、書体、余白のスケール、階層など、あらゆる選択について、なぜそうするのかを説明できなければなりません。「よくあるから」や「うまくいくから」では、既定値に頼っているだけです。

---

プロダクト領域の探索

ここで既定値に気づけるかどうかが分かれます。ありがちな進め方は、タスクの種類 → ビジュアルテンプレート → テーマです。丁寧な進め方は、タスクの種類 → プロダクト領域 → 独自性 → 構造と表現です。違いは、ビジュアルを考える前に、プロダクトの世界をどれだけ深く理解するかです。

方向性を提案する前に、次の4つをすべて提示してください。

• 領域 — このプロダクトの世界にある概念、比喩、用語。機能ではなく、扱う領域です。最低5つ。
• 色の世界 — ここにはどんな色が自然に存在しますか？「暖色」や「寒色」ではなく、実際の世界を見てください。このプロダクトが物理的な空間だとしたら、何が見えるでしょうか？ 5つ以上挙げてください。
• シグネチャー — このプロダクトだからこそ存在し得る要素を1つ挙げてください（ビジュアル、構造、インタラクションのいずれでも構いません）。1つも挙げられない場合は、さらに探索してください。
• 既定の選択肢 — この種のインターフェースでよくある選択肢を3つ挙げてください。ビジュアル面と構造面の両方を含めます。名前を挙げていないパターンは避けられません。

テスト： プロダクト名を隠して提案を読んだとき、それが何のためのものか分かりますか？ 分からない場合は、さらに深く探索してください。

---

できるときはレンダリングする

セッションでインラインのビジュアルレンダリングツール（会話内で HTML や SVG をレンダリングする show_widget ／ visualize ツールなど）が利用できる場合は、デザインを説明するよりも見せることを優先してください。文章だけに閉じ込められた指針は、実際に見られる指針に比べて有用性が大きく劣ります。これは条件付きです。そのようなツールがない場合（CI、ヘッドレスエージェント、プレーンターミナルなど）は、コード、トークン、文章による提案を使ってください。ツールがあると決めつけてはいけません。確認してから使ってください。

次の3つのタイミングでレンダリングします。

1. 方向性を提案するとき。 提案＋質問のブロックに添えて、小さな実例をライブでレンダリングします。パレットは実際のスウォッチで、文字サイズの段階は実際の書体で、サーフェスのエレベーションの段階はカードを重ねて、特徴的な要素は実際のコンポーネントとして見せます。「ノートのように温かみがある」という印象を、言葉で読ませるのではなく、目で見てもらいましょう。
2. コンポーネントを設計するとき。 実際のコンポーネント（または改善前と改善後の、並べて見比べられる2つのバリエーション）をレンダリングし、余白、境界線、階層、状態といった細部の判断を、言い張るのではなく、見て分かるようにします。重要な場合は、実際の状態（デフォルト、ホバー、空、エラー）をレンダリングします。
3. 批評または監査を行うとき。 現在のバージョンと改善後のバージョンを並べてレンダリングし、差を説明するのではなく、見て分かるようにします。

レンダリングする際のルール：

• ウィジェットに表示するのはビジュアルのみです。推論、ドメインの調査、採用しなかったデフォルトの一覧、推奨事項はすべて回答文に記載し、ウィジェットに文章を貼り付けないでください。
• レンダリングツール独自のデザインシステムの仕様に従ってください。read_me やガイダンスがある場合は読み込んでください。テーマ変数を使い、実例がライト／ダークモードを継承し、ホスト環境になじむようにします。ホストの外観と競合しないでください。
• レンダリングした実例も、以下のチェックを満たす必要があります。デフォルトをレンダリングしても、それは依然としてデフォルトです。レンダリングは細部へのこだわりを見えるようにするものであり、それに取って代わるものではありません。
• レンダリングされるのは会話内であり、プロジェクト内ではありません。実際の実装は、通常の編集を通じて引き続きコードベースに反映してください。

目的は、「これが私の考えです」と「これが見た目です」の間のループを縮め、相手がひとつのメッセージに反応できるようにすることです。

---

ビジュアルの階層と構成

「デザインされているように見える」か「自動生成されたように見える」かを最も大きく左右する要素です。デフォルトは平板さを生みます。すべてが同じサイズ、太さ、間隔になり、何も目立たず、視線の行き場がなくなります。細部へのこだわりは階層を生み、何が重要かを視線が瞬時に把握できるようにします。これは雰囲気ではなく、具体的な工夫です。

ビューごとに焦点を1つ設ける

どの画面にも、ユーザーが実現しようとしていることが1つあります。それを、サイズ、コントラスト、位置、または周囲の余白によって際立たせます。すべてが同じように競い合えば、何も勝てず、インターフェースは駐車場のように見えてしまいます。作り始める前に、焦点となる要素を声に出して特定してください。そして、それを際立たせます。大きくする、コントラストを高める、または余白で囲むなどの方法があります。それ以外の要素は、意図的に目立たなくします。

文字サイズは比率で決め、サイズよりウェイトを重視する

感覚でサイズを選ばないでください。比率を決めて段階的に適用します。密度が高く落ち着いた UI には約 1.2（短三度）、多くのプロダクト UI には約 1.25、表現豊かな UI には約 1.333 を使います。本文を 14〜16px にすると、15／16／17px のように差が曖昧なものではなく、はっきり区別できるスケールになります。基準を 14px、比率を 1.25 とした場合は、caption 11 · body 14 · h4 16 · h3 18 · h2 22 · h1 28 · display 44+ です。整数のピクセル値に丸め、スペーシンググリッドにも合わせます。

Apple／Linear のやり方では、サイズよりもウェイトと色が階層の表現に大きく貢献します。 14px という単一サイズでも、ウェイトと不透明度だけで 3 段階に分けられます。value: 600 / primary、label: 500 / secondary、meta: 400 / muted のように設定すれば、2 ポイント差の通常ウェイトを 2 種類使うよりも明確に区別できます。サイズ、ウェイト、色／不透明度という 3 つの要素を組み合わせて設計し、サイズだけに頼らないでください。目を細めても見出し、本文、ラベルの違いがわからないなら、階層が弱すぎます。

例 — 指標を、平坦な見せ方と意図のある見せ方で比較します。平坦な見せ方： Revenue と $48,200 はどちらも 14px の通常ウェイトのグレーで、3 つのボックスは同じ見た目。視線を集める要素はありません。意図のある見せ方： REVENUE は 11px／500／muted／字間調整、$48,200 は 28px／600／primary／tabular-nums（主役）、↑12% は 12px／500／success。同じデータでも読みやすさは大きく変わります。数値はサイズとウェイト、そして 1 つのアクセントカラーで目を引き、ラベルは控えめにし、補助的な指標は下位の階層に置きます。

密度は px で表す設計上の判断

Linear は詰まったレイアウト、Stripe はゆったりしたレイアウトです。どちらも標準ではなく、どちらも選択されたものです。その選択は、あらゆる箇所で繰り返される同じ数値に表れます。最初に密度を決め、値を明確にしましょう。ツールパネルのパディングが 12〜16px なら作業台のように引き締まった印象になり、同じカードでも 24px ならパンフレットのような印象になります。同じ数値でも、ある状況では適切で、別の状況では手抜きに見えます。意図を持って選び、一貫して適用してください。

空間のリズム — 均一にせず、余白を生かす

優れたインターフェースは、すべてを均等な間隔で配置しません。密度の高い操作領域から開放的なコンテンツへと移り、重みのある要素と軽い要素が釣り合い、視線が目的を持って動きます。カードのサイズも間隔も密度もすべて同じ単調なレイアウトは、誰も判断していないことを表します。リズムに意図的な変化をつけましょう。密接に関連する要素はまとめ、グループの間には十分な余白を設けます。

比率が意味を伝える

全幅のコンテンツの横に幅 280px のサイドバーを置くと、「コンテンツが主役で、ナビゲーションはそれを支える」と伝わります。幅 360px のサイドバーなら、「両者は同等の役割を持つ」と伝わります。具体的な数値が重要度を示します。比率が何を伝えるのか説明できないなら、何も伝えていません。要素間の関係を表す幅と比率を選びましょう。

配分と抑制（「高級感」のある見た目）

• 約 60／30／10：大部分を占めるニュートラルな面、2 番目の色調、そして約 10％ のアクセントです。色は貴重なリソースです。画面の大半は構造で占めます。
• 意図を持って使う 1 色のアクセントは、考えなしに使う 5 色に勝ります。グレーで構造を作り、色で状態、操作、アイデンティティを伝えます。理由のない色使いはノイズです。
• 線ではなく、空間とウェイトで階層を表現します。 枠線や区切り線に頼る前に、余白と色調の変化を活用しましょう。最も上質なインターフェースでは、構造の大半が目立ちません。
• 大きな文字にはオプティカルサイズ調整を適用します：文字が大きくなるほど字間を詰めます（見出しでは字間を少しマイナスにします）。本文は読みやすさのために行の高さを広めにします（約 1.5）。字間を詰めると作り込まれた印象になり、32px の見出しで標準の字間を使うと文書のように見えます。

---

Craft Foundations

微妙なレイヤー表現（基盤）

方向性にかかわらず、これはすべてに当てはまります。システムが動作していることに、ほとんど気づかない状態を目指してください。Vercel のダッシュボードを見たとき、「ボーダーが素敵だ」と思うのではなく、構造を自然に理解できるべきです。目立たない工夫こそ、優れた工夫です。

サーフェスの高さ。 サーフェスは積み重なります。ドロップダウンはカードの上にあり、カードはページの上にあります。番号付きのシステムを構築し、ベースから段階的にレベルを上げます。各段階の明度差はわずか数ポイントにとどめます。たとえば、ダークモードではベース → +7% → +9% → +12%、ライトモードでは明るさを保ち、代わりにシャドウを加えます。単独ではほとんど区別できない段階も、積み重なることで階層が生まれます。目で見るよりも感覚で捉える、ささやくような変化です。

• サイドバー： キャンバスと同じ背景色にし、別の色にはしません。色を変えると、空間が「サイドバーの世界」と「コンテンツの世界」に分断されます。微妙なボーダーだけで十分です。
• ドロップダウン／ポップオーバー： 親のサーフェスより一段上に配置します。そうしないと背景に溶け込み、レイヤーが失われます。
• 入力欄： 周囲より少し暗くし、明るくはしません。入力欄はコンテンツを受け取る内側の領域です。塗りを暗くすると、太いボーダーを使わずに「ここに入力する」ことを伝えられます。

ボーダー。 意識していないときには目立たず、構造が必要なときには見つけられるようにします。不透明度の低い rgba は背景に溶け込み、注目を集めずに境界を示します。一方、単色の hex ボーダーは、それと比べてきつく見えます。ダークモードでは rgba(255,255,255,0.06–0.12) 前後、ライトモードでは少し高めにします。標準、より控えめな区切り、強調、フォーカスリングという段階を設け、境界の重要度に応じて強さを合わせます。

目を細めて見るテスト： インターフェースをぼかして見てください。それでも、何が何より上にあるか、どこでセクションが分かれているかといった階層は認識できる一方で、何も目立ちすぎない状態が理想です。きつい線も、唐突な変化もありません。控えめな構造だけが残ります。ここを間違えると、ほかのすべてが台無しになります。

無限の表現

あらゆるパターンには無限の表現方法があります。同じ見た目のインターフェースは二つとあってはなりません。 指標の表示には、大きく目立つ数値、インラインの統計値、スパークライン、ゲージ、プログレスバー、比較差分、トレンドバッジなどの方法があります。毎回同じサイドバー幅、同じカードグリッド、同じ「左にアイコン、大きな数値、小さなラベル」の指標ボックスを使うのは、AI 生成だとすぐにわかるうえ、記憶に残りません。Linear のカードは Notion のカードには見えず、Vercel の指標は Stripe の指標には見えません。同じ概念にも、無限の表現方法があります。構築を始める前に、ここでユーザーが行うことの中核は何か、そして似た課題を見事に解決しているプロダクトは何かを考えてください。

色には背景がある

どのプロダクトにも、それが存在する世界があり、その世界には色があります。パレットを選ぶ前に、この空間の実物の中に入り込んでください。どのような素材、光、物があるでしょうか。パレットは、何かに塗り重ねられたものではなく、どこかから生まれたものだと感じられるべきです。色温度は一つの軸です。ほかにも、静かかにぎやかか、密度が高いかゆったりしているか、真面目か遊び心があるか、幾何学的か有機的かを考えてください。トレーディング端末と瞑想アプリは、どちらも「集中」を目的としていますが、集中のあり方はまったく異なります。

---

各コンポーネントを書く前に

UI コードを書くときは、小さな追加であっても毎回、次の内容を明示してください。

Intent:     [who is this human, what must they do, how should it feel]
Hierarchy:  [the focal element, and how it wins — size / weight / contrast / space]
Palette:    [colors from your exploration — and WHY they fit this world]
Depth:      [borders / subtle shadows / layered — and WHY it fits the intent]
Surfaces:   [your elevation scale — and WHY this temperature]
Typography: [typeface + the size/weight/color levers — and WHY]
Spacing:    [base unit + chosen density]

このチェックポイントは必須です。それぞれの理由を説明できない場合は、無意識に既定の選択肢を使っています。いったん止まり、考えてください。

---

既存のものを使う

AI がコードベースの品質を低下させる最も一般的な原因は、すでにあるものを自作してしまうことです。プロジェクトに本物の Button があるのに、独自の <div onClick> で「ボタン」を作る。キーボード操作に対応したプリミティブがインストール済みなのに、キーボード操作に対応しないドロップダウンを一から作る。カードごとに、すぐ使えるコンポーネントやトークンを使わず、14 個もの Tailwind クラスをコピー＆ペーストする。どれも同じ失敗です。すでにあるものを使わず、新しく生成してしまうのです。その結果、一貫性がなく、アクセシビリティに問題があり、保守しにくいものになります。コントロールを作成したり、要素にスタイルを適用したりする前に、プロジェクトにすでに用意されているものを確認してください。

コントロール：ネイティブ → プリミティブ → 手作り

1. 機能する場合は、まずネイティブ HTML を使います。<button> はボタンであり、<a> はリンクです。<input type="text">、<dialog>、<details> も用意されています。プラットフォームがすでに提供している機能を、決して <div onClick> で実装しないでください。そうすると、本来使えるフォーカス、キーボード操作、セマンティクスを失います。
2. 状態を持ち、正しく実装するのが難しいもの（セレクト、コンボボックス、ダイアログ、ポップオーバー、ツールチップ、ドロップダウンメニュー、タブ、日付ピッカー）には、実績のあるヘッドレスプリミティブを使います。これらには、正しく再現するのに何日もかかるキーボードナビゲーション、フォーカス管理、ARIA、衝突判定と位置調整が備わっています。エコシステムですでに信頼されているもの（例：React の Radix UI、React Aria、Ark、Headless UI、Vaul、cmdk。ほかのフレームワークでは同等のアクセシブルなプリミティブ）を選び、その上に自分のスタイルを適用します。「カスタムで構築する」とは、プリミティブを組み合わせてスタイルを設定することであり、動作をゼロから実装することではありません。
3. 手作りにするのは、本当に最後の手段に限ります。適合するプリミティブがない場合や、依存関係を追加する余裕がない場合です。その場合は、動作に関する要件をすべて満たす必要があります。キーボードナビゲーション（矢印キー、Enter、Escape）、フォーカストラップとフォーカス復帰、完全な ARIA ロールと状態、領域外クリックへの対応、オーバーレイのスクロールロックです。どれほど見た目がよくても、これらが欠けたコントロールは壊れています。

スタイル設定：システム → コンポーネント → トークン → ユーティリティ

1. プロジェクトにデザインシステムがあるなら、それを使います。 shadcn/Button、CVA のバリアントセット、テーマ、コンポーネントライブラリがある場合は、独自の実装を書く前に <Button variant="…"> と既存のバリアントを使います。コードベースのスタイル規約（Tailwind、CSS モジュール、CSS-in-JS）に合わせ、独自の規約を持ち込まないでください。
2. スタイルを設定した要素が繰り返し使われる場合は、コンポーネントに抽出します。 9 個のボタンで同じユーティリティ文字列を使うのは、デザインではなく重複です。1 つのコンポーネント（または 1 つの CVA／バリアント）にそのスタイルを集約し、呼び出し側をシンプルに保ちます。最初の再利用時ではなく、実際に 2 回目に使う時点で抽出します。
3. ハードコードしたリテラルではなく、セマンティックトークンに紐付けます。 bg-white border-gray-200 text-gray-500 ではなく、bg-card border-border text-muted-foreground を使います。ハードコードした gray-200／#fff／px-4 の生の値は、Tailwind 版の無作為な 16 進数カラーです。テーマやダークモードに対応できず、システムがないことの表れでもあります。（以下の「トークンアーキテクチャ」を参照してください。）
4. インラインのユーティリティは、本当に一度きりの場合に使います。一度だけ使うレイアウトの微調整などです。同じ長い className をあちこちに適用しているなら、それは雑な実装の兆候です。スタイル設定の問題ではなく、コンポーネントまたはトークンが不足しています。

---

デザインシステムの基本

あらゆるクラフト上の判断を支える、トークン、スペーシング、奥行きのアーキテクチャです。

• トークンアーキテクチャ。 すべての色は少数のプリミティブに対応します。前景（テキスト）、背景（サーフェス）、ボーダー、ブランド、セマンティック（破壊的／警告／成功）です。場当たり的な16進数は使わず、すべてプリミティブに対応させます。
• テキスト階層 — 4段階。 プライマリ、セカンダリ、ターシャリ、ミュート（デフォルト／補足／メタデータ／無効）です。2段階だけでは階層が平坦になりすぎます。
• スペーシング。 基本単位（4または8px）を決め、その倍数だけを使います。用途に応じて、マイクロ（アイコン間の隙間）、コンポーネント（ボタン／カード内）、セクション（グループ間）、大きな領域（エリア間）でスケールを使い分けます。値に一貫性がないと、システムがないように見えます。
• パディング。 対称にします。コンテンツ上の明確な理由がない限り、片側に値を設定したら、ほかの側も同じ値にします。
• 奥行き — 1つだけ選び、徹底します。 ボーダーのみ（すっきりした技術的で密度の高いツール）・控えめなシャドウ（親しみやすさ）・重ねたシャドウ（高級感と立体感）・サーフェスカラーの変化（色合いを使い、シャドウは使わない）。手法を混ぜないでください。
• ボーダー半径 — スケールを決めます。 入力欄／ボタンには小さく、カードには中くらい、モーダルには大きくします。シャープな形と柔らかな形を無作為に混ぜないでください。
• コントロール用トークン。 入力欄／セレクト／チェックボックスには、専用の背景、ボーダー、フォーカストークンを設定します。コントロールを個別に調整できるよう、サーフェストークンを使い回さないでください。ネイティブの<select>／<input type="date">はスタイルを設定できないため、自前で作り込むのではなく、ヘッドレスプリミティブを組み合わせてください（「既存のものを使う」を参照）。
• ダークモード。 ダークモードではシャドウが弱く見えるため、ボーダーを活用します。セマンティックカラーはやや彩度を落とします。同じ階層システムを値を反転して使います。色相は1つに保ち、サーフェス間では明度だけを変えます。

---

仕上げとモーションの基本

小さなディテールが積み重なり、「使い心地が素晴らしい」と感じられるようになります。ここでは、本当に洗練されたUIをリリースするために効果の高いポイントを紹介します。

静的な仕上げ

• 同心円状の半径。 角丸要素を入れ子にする場合：outerRadius = innerRadius + padding。親要素と子要素に同じ半径を設定するのは、UIに違和感を与える最もよくある原因です。
• 等幅数字。 動的な数値（カウンター、価格、タイマー、テーブルの列）には、レイアウトのずれを防ぐためにfont-variant-numeric: tabular-numsを設定します。
• 視覚的な位置合わせ。 幾何学的な中央揃えに違和感がある場合は、視覚的に調整します。アイコン側のパディング ≈ テキスト側 − 2px、再生三角形は右に約2pxずらします。
• 状態は必須です。 インタラクティブな要素には、デフォルト、ホバー、アクティブ、フォーカス、無効の各状態が必要です。データには、読み込み中、空、エラーの状態が必要です。状態が欠けていると壊れているように感じられ、未完成のインターフェースだとすぐにわかります。
• ヒット領域 — 44×44px（WCAG）、最低でも40。 表示されるコントロールが小さい場合（20pxのチェックボックスなど）は、疑似要素で領域を広げます。2つのヒット領域を決して重ねないでください。
• 高さを出す場合は、ボーダーよりシャドウを使います。 浮き上がるカード／ボタン／コンテナには、どのような背景にも適応する、レイヤー化した透明なbox-shadowを優先します。仕切り線や入力欄の輪郭には実際のボーダーを使います。ライトモードでは、高さを出すために3層を重ねます。1pxのリングと2つの柔らかな奥行きで、たとえば0 0 0 1px rgba(0,0,0,.06), 0 1px 2px -1px rgba(0,0,0,.06), 0 2px 4px rgba(0,0,0,.04)のようにします。ダークモードでは、単一のリング0 0 0 1px rgba(255,255,255,.08)にします（奥行きを出すシャドウはダークモードでは見えません）。
• テキストの折り返し。 見出しにはtext-wrap: balance、本文／キャプションには孤立した短い行を防ぐためにtext-wrap: prettyを設定します。
• フォントのスムージング。 ルートに-webkit-font-smoothing: antialiasedを設定します（設定しないと、macOSでは文字が太く表示されます）。
• 画像のアウトライン。 1pxの内側アウトラインを、ライトモードでは純粋なrgba(0,0,0,0.1)、ダークモードではrgba(255,255,255,0.1)にします。色味のある黒や白に近い色は使わないでください（縁が汚れて見えます）。

モーション

モーションは目にするものではなく、感じるものです。速く、目的があり、決して邪魔にならないようにします。

• そもそもアニメーションさせるべきでしょうか？ 1日に100回以上繰り返す操作（キーボードショートカット、コマンドパレット）は、アニメーションを使いません。動作が遅く感じられるためです。たまに表示する要素（モーダル、ドロワー、トースト）には標準的なアニメーションを使います。まれな場面や初回利用時には、楽しさを加えてもかまいません。
• UI の表示時間は 300ms 未満にします。ボタンの押下は100～160ms、ツールチップ／ポップオーバーは125～200ms、ドロップダウンは150～250ms、モーダル／ドロワーは200～500msです。180ms のドロップダウンは、400ms のものより応答が速く感じられます。
• カスタムのイーズアウトを使い、イーズインは使いません。 組み込みのカーブは弱すぎます。表示時／インタラクション時には cubic-bezier(0.23, 1, 0.32, 1) を、画面上の移動にはイーズインアウト（cubic-bezier(0.77, 0, 0.175, 1)）を使います。ease-in は、ユーザーが注目している最初のフレームを遅らせるため、動作がもたついて感じられます。
• 押下時のフィードバック。 :active に transform: scale(0.97) を指定します（0.95 未満にはしません）。UI がクリックを受け付けたことを、触覚的に伝えます。
• scale(0) からアニメーションを始めないでください。 何もないところから現れるものはありません。scale(0.95) と opacity: 0 から始めます。
• 起点を意識したポップオーバー。 ポップオーバーは中央ではなく、トリガーを起点に拡大します（transform-origin をトリガーに設定します）。モーダルだけは例外で、中央にとどまります。
• アニメーションさせるのは transform と opacity のみにします（GPU 合成されます）。width／height／margin／padding のアニメーションはレイアウトとペイントを発生させ、フレーム落ちを招きます。transition: all は使わず、プロパティを正確に指定します。
• 表示時は項目ごとに30～80msずつ遅らせて自然な連続感を出します。非表示時のアニメーションは表示時より速く、控えめにします。
• prefers-reduced-motion を尊重します。不透明度／色のトランジションは維持し、移動はなくします。

---

避けること

• 強すぎる境界線 — 最初に目に入るのが境界線なら、強すぎます
• 面の高さが大きく変わること — 高さの差はごく控えめにします
• 平坦な階層構造 — すべてが同じサイズ／太さで、明確な視点の中心がない状態
• 単調なレイアウト — どこでもカードのサイズ、間隔、密度が同じ状態
• 一貫性のない間隔 — デザインシステムがないことを最も明確に示す兆候です
• 奥行き表現の混在 — ひとつを選び、統一します
• 状態の不足 — ホバー、フォーカス、無効、読み込み中、空、エラー
• 目立ちすぎるドロップシャドウ — 注目を集めず、控えめにします
• 小さな要素に大きな角丸を使うこと、装飾目的の太い境界線
• 装飾目的のグラデーションや色 — 色には意味を持たせます
• 複数のアクセントカラー — 焦点がぼやけます
• 面ごとに異なる色相 — 色相はひとつに保ち、明度だけを変えます
• デフォルトのタイポグラフィ — 方針が定められている場合に、システムフォント／Inter とサイズだけの階層構造を使うこと
• 構造上のハック — 親要素のパディングを打ち消す負のマージン、回避策としての calc()、レイアウトフローを避けるための絶対配置

---

ワークフロー

コミュニケーション

存在を感じさせないようにします。モードを宣言したり、プロセスを逐一説明したりしません。「ESTABLISH MODE です」や「system.md を確認します」とは決して言いません。すぐに作業に取りかかり、理由を添えて提案します。

実行規律

このスキルは単なるアドバイスではなく、作業規律として活用してください。UI を編集する際は、次の手順に従ってください。

1. 既存のアプリ、デザイントークン、コンポーネントのパターン、そして .interface-design/system.md があればその内容を確認します。
2. レイアウト、色、書体、密度、ナビゲーションを選ぶ前に、対象領域について具体的に調査します。
3. 新規画面、大規模な再設計、または方向性が曖昧な場合は、画像生成ツールが利用できる場合に限り、ビジュアルリファレンスの作成を検討します（利用できない場合は省略してください。これは補助的なもので、成果物ではありません）。4 つのモードがあります。方向性ボード（コーディング前に、抽象的なムード、素材、色の案を 2～3 種作成 — 実際の UI は含めません）、UI リファレンス（選択した方向性の中解像度の構成案）、ペイントオーバー（既存のスクリーンショットをより強化したもの）、ラスターアセット（空状態のイラスト、テクスチャ — アイコン、ロゴ、チャートには使用しません）。汎用的な SaaS、判読できないテキスト、対象領域に合わない配色は必ず却下してください。配色、密度、比率、特徴を抽出し、実際のコードで再現してブラウザーで検証します。
4. 実装に変更を加えた後、利用できる場合は関連するビルド、型チェック、テストを実行します。
5. UI が複雑な場合は、必ず見た目を検証します。インラインレンダリングツール、ローカルブラウザー、またはデスクトップとモバイルの幅で撮影したスクリーンショットを使い、重なり、間隔の崩れ、空状態、読みにくいテキスト、アセットの欠落、ありきたりな構成があれば、提示する前に修正します。
6. ユーザーへの進捗報告は簡潔にします。長い非公開のデザイン検討内容は明かさず、役立つ提案や決定事項を伝えます。

提案して確認

まず調査と提案を行い、その後に確認します。

Domain:     [5+ concepts from the product's world]
Color world:[5+ colors that exist in this domain]
Signature:  [one element unique to this product]
Rejecting:  [default 1] → [alternative], [default 2] → [alternative], [default 3] → [alternative]
Direction:  [approach connecting to the above]

続けて、"この方向性でよさそうですか？" と尋ねます。インラインレンダリングツールが利用できる場合は、同じメッセージ内でその方向性を示す実物のサンプルをレンダリングします。パレット、書体、特徴を見せ、名前を挙げるだけにしないでください。

構築フロー

• .interface-design/system.md がある場合： 読み込んで適用します — 方針は決定済みです。
• ない場合： 対象領域を調査する（4 つの成果物すべて）→ 提案する（4 つすべてに言及）→ 方向性が曖昧、または変更コストが高い場合は確認する → 構築する → 以下のチェックを実行する → 保存を提案する。

チェック項目（提示前）

出力に対して以下を実行し、1 つでも不合格なら提示前に修正します。

• 差し替えテスト — 書体を一般的なものに、レイアウトを標準的なテンプレートに差し替えてみてください。何か違いを感じますか？差し替えても違いがない箇所は、独自性が不足しています。
• 目を細めるテスト — 目をぼかすように見ても、階層が読み取れますか？強く目を引きすぎるものはありませんか？
• 特徴テスト — 独自性が現れている具体的な要素を 5 つ挙げてください。「全体的な雰囲気」では不十分です。
• トークンテスト — CSS 変数を声に出して読み上げてください。このプロダクトならではのものですか、それともどのプロジェクトにも当てはまりますか？

---

タスク完了後

必ず保存を提案します："今後のセッションで使えるように、これらのパターンを保存しますか？" はいと答えた場合は、.interface-design/system.md に書き込みます。

• 方向性と雰囲気
• 奥行きの方針（境界線／シャドウ／レイヤー）と間隔の基本単位
• 階層の決定事項（文字サイズ比、密度の値、フォーカスのパターン）
• 主要なコンポーネントのパターン — コンポーネントが 2 回以上使用される場合、再利用可能な場合、または記録に値する寸法がある場合に追加します（単発のものやプロパティのバリエーションは除きます）。値を記録します。例：Button primary — 36px h · 12px 16px pad · 6px radius · 14px/500。
• 画像を用いた検討がデザインに影響した場合は、ビジュアルの方向性に関するメモと選定したリファレンス

一貫性チェック。 system.md に値が定義されている場合は、それに従います。間隔はグリッドに合わせ、定められた奥行きの方針を一貫して適用し、パレットの色を使用し、記録されたパターンを作り直さずに再利用します。保存するたびに、今後の作業はより速く、一貫性のあるものになります。

---

コマンド

• /interface-design:design-review — 承認基準を設け、構築物を厳格に品質と階層の観点からレビューします。可能な場合は変更前後をレンダリングします。
• /interface-design:design-deslop — ブランチから見た目上の雑さを取り除く、差分の範囲に絞った迅速な確認です。

デザインの状況確認、監査、パターンの抽出を自然言語で求められた場合は、.interface-design/system.md を読み、内容を要約します。UI ファイルに基づいて逸脱がないか確認するか、繰り返し使用されている余白、角丸、色、コンポーネントの値を調べて system.md を提案します。相当する処理をインラインで実行してください。