design-standards

デザイン標準

あらゆる Web プロジェクトに適用できる、本番環境向けのデザイン標準です。技術スタックやツールを問いません。デザイントークン、コントラスト、階層、余白、モバイル対応ルール、リリース前チェックリストを網羅します。

このスキルは、ビジュアルシステムを定義する brand-identity と、その内容を文書化する brand-style-guide を補完します。このスキルは、実際のコンポーネントやページで標準を適用する日々の作業向けです。

---

使用する場面

• 新しいページ、セクション、コンポーネントを作成する
• UI の品質、アクセシビリティ、一貫性をレビューする
• 新しいプロジェクトのデザイントークンを設定する
• レイアウト、コントラスト、階層の問題を修正する
• ボタンやフォームの標準を確立する
• リリース前のデザインレビューを行う

使用しない場面

• ブランドアイデンティティをゼロから定義する（brand-identity を使用）
• 完成したブランドシステムを文書化する（brand-style-guide を使用）
• 正式なコンポーネントライブラリを構築する（design-system を使用）
• フロントエンドのコードアーキテクチャを設計する（frontend-component-build を使用）
• WCAG 準拠の修正を伴う、アクセシビリティに特化した監査を行う（accessibility-audit を使用）

---

必須入力

• 作成またはレビューするページやコンポーネント
• ブランドのデザイントークン（色、タイポグラフィ、余白）、またはそれらを定義する意思
• 対象デバイスとビューポート

ブランドトークンが未定義の場合は、まず references/design-tokens-template.md のテンプレートを使って、暫定的なセットを定義してください。

---

フレームワーク：6 つの標準

すべての UI に適用される 6 つの標準です。これらを徹底すれば、デザイン上の問題の大半は解消されます。

1. デザイントークン

UI の構築を始める前に、すべてのプロジェクトでトークンを定義する必要があります。トークンは信頼できる唯一の情報源です。

カラートークン（最低限）：

• ブランドのプライマリーカラー
• プライマリーカラーのホバー時の色（通常は 15〜25 パーセント暗くする）
• 背景のバリエーション（サーフェス、代替セクション、ヒーロー／ダーク、フッター）
• テキストの段階（見出し、本文、控えめなテキスト、ダーク背景上のテキスト）
• セマンティックカラー（成功、警告、エラー、情報）

スペーシングトークン：

• 一貫性のあるスケール（例：4、8、12、16、24、32、48、64、96）
• ページの最大幅
• セクションの垂直方向のパディング（大、中、小）
• カードのパディング
• グリッドの間隔

タイポグラフィトークン：

• ディスプレイ、H1〜H4、大きい本文、本文、小さいテキスト、キャプション
• それぞれのサイズ、ウェイト、行の高さ、文字間隔
• フォントのフォールバックスタック

角丸トークン：

• 小さめ（カード、バッジ）
• 標準（ボタン、入力欄）
• 丸型（アバター、ピル型ボタン）

トークンは一度文書化し、すべての場所で参照してください。値のハードコードは技術的負債です。

2. WCAG AA コントラスト（必須）

コントラストは好みの問題ではなく、最低基準です。AA に準拠していないデザインは、十分な視力を持つデザイナーにどう見えるかにかかわらず、問題があります。

要素	必要な比率
通常サイズの本文テキスト	4.5:1
大きいテキスト（18pt の標準ウェイト、または 14pt の太字）	3:1
UI コンポーネントとグラフィック要素	3:1

よくある問題を避けてください：

• 白地に薄いグレーの本文テキストを使い、コントラスト比が 2〜4:1 になる
• 暗いバリエーションを用意せず、ブランドカラーを本文テキストに使う
• フォームフィールドの薄い境界線のコントラスト比が 3:1 を下回る
• 白地に小さいサイズの明るいオレンジや黄色を使う

計算方法、コントラストチェッカー、ブランドカラーの活用方法については、brand-identity/references/contrast-and-accessibility.md を参照してください。

3. ビジュアル階層

適切にデザインされたページには、明確な視線の流れがあります。階層は次の要素から生まれます：

• サイズ。 最も大きな要素が最初に目に入ります。
• ウェイト。 同じサイズなら、太字は標準ウェイトよりも目立ちます。
• 色。 彩度の高い色はニュートラルな色より目立ちます。コントラストの高い色は低い色より目立ちます。
• 余白。 単独で配置された要素は強調されます。窮屈に配置された要素は目立たなくなります。
• 位置。 左上と中央は視線を集めます。端や隅は目立たなくなります。

階層を意図的に適用してください。すべてのビジュアル要素が階層を通じて認識できるようにします。3 つの要素がプライマリーな注目を奪い合うと、どれも勝ちません。

よくある問題：

• 複数の要素を「プライマリー」CTA としてスタイル設定する（曖昧さが生じます）
• 本文テキストと見出しのサイズが近すぎる
• ヒーロー画像がヒーローテキストと注目を奪い合う
• アイコン、見出し、画像のビジュアル上の強さが似ている

4. 余白とリズム

余白が、洗練されたレイアウトと雑然としたレイアウトを分けます。

ルール：

• 任意の値ではなく、余白のスケールを使用します
• 関連する要素は、関連のない要素より近くに配置します（近接の原則）
• セクションの余白：デスクトップでは最低64px、モバイルでは48px
• カードのパディング：デスクトップでは最低24px、モバイルでは16px
• フォームフィールドの間隔：フィールド間に最低16px
• タッチターゲット：最低44×44ピクセル

よくある失敗：

• 類似する状況で余白が一貫していない（あるカードのパディングは24px、次のカードは32px）
• 余裕がなく、セクション同士が混ざり合っている
• モバイルでタッチターゲットが44ピクセル未満
• リズムがなく、見出しが小見出しに直接くっついている

5. モバイルのルール

ユーザーの大半はモバイルを利用しています。デスクトップを先に設計すると、モバイルで必ず問題が起きます。

基準：

• 完了と判断する前に、375〜390ピクセルのビューポートでテストします
• すべてのインタラクティブ要素は最低44×44ピクセルにします
• 固定表示の下部バーがある場合、ページのラッパーにバーの高さと同じ分の下部パディングを設定します
• 最大幅の制約なしに、ピクセル単位の固定幅を指定しません
• 本文のテキストは14ピクセル未満にしません
• タップターゲットのすべての辺に、最低8ピクセルの間隔を設けます
• モーダルとポップオーバーのコンテンツはスクロール可能にし、本文のスクロールはロックします
• iOSの自動ズームを防ぐため、フォーム入力のテキストサイズは最低16pxにします

よくある失敗：

• ブラウザーの開発者ツールでは動作するものの、実機では崩れるデザイン
• 固定表示のナビゲーションが、対策なしにビューポートの80pxを占める
• 幅の広すぎる要素が1つあるために、横スクロールが発生する
• 見た目に問題はなくても、ほかのタップターゲットに近すぎて操作できないタップターゲット

6. コンポーネントの一貫性

同じものは、どこでも同じ見た目にします。バリエーションを設ける場合は、意図的に行います。

一貫性を保つための原則：

• ボタン：プライマリスタイル、セカンダリスタイル、ゴーストスタイルをそれぞれ1つずつ使用します。5種類にはしません。
• カード：基本となるカードパターンを1つ用意し、バリエーションを設けます。ページごとに専用のカードは作りません。
• アイコン：アイコンセット全体で、線の太さと角のスタイルを統一します
• アバターとブランドマーク：形状のルールを1つ選び（rounded-lgまたは完全な円形）、それを一貫して使います
• フォーム入力：入力状態（デフォルト、フォーカス、エラー、無効）のセットを1つ用意し、すべての場所で使用します

よくある失敗：

• ページ間で一貫性なく、異なる「プライマリボタン」が3種類使われている
• rounded-2xlの角丸カードもあれば、rounded-xlのカードもある
• セクションによってアイコンのスタイルが変わる
• ページによって、ブランドアバターが四角形になったり円形になったりする

---

ワークフロー

1. トークンを確認します。 まだトークンが定義されていない場合は、まず実用的なセットを定義します。定義内容を文書化します。
2. 階層をスケッチします。 マークアップを書く前に、主要なアクション、副次的なアクション、補足コンテンツを特定します。閲覧順序が適切か確認します。
3. モバイルファーストで構築します。 まず最小の対象ビューポートに合わせてレイアウトし、その後に拡張します。
4. トークンを適用します。 すべての値をトークンセットから使用します。色、サイズ、余白をハードコードしません。
5. コントラストを確認します。 すべてのテキストと背景の組み合わせがAAに合格することを確認します。すべてのUI要素が3:1に合格することを確認します。
6. ビューポートのブレークポイントでテストします。 最低でも375、768、1024、1440で確認し、何も崩れないことを確かめます。
7. references/preship-checklist.md の出荷前チェックリストを実行します。

---

失敗パターン

• トークンなしで設計する。 色や余白をハードコードすると、保守が難しくなり、規模の拡大とともに一貫性が失われます。
• コントラストの確認を省く。 特に、テキストに使うブランドカラーに注意します。多くのブランドカラーはAAに合格しません。
• デスクトップだけを対象に設計する。 モバイルでは、あらゆるレイアウト上の問題が明らかになります。最初でも最後でもよいので、必ずモバイルでテストします。
• 何でも角丸にする。 「モダン」を「何もかも角丸にする」と捉えることです。角丸はツールであり、デフォルトではありません。
• 視覚的な階層が曖昧になる。 3つの要素がすべて主要な要素として競い合い、読者がどこを見ればよいかわからなくなります。
• タッチターゲットの要件に違反する。 見た目はよくても、実機で指による操作性を損なう32pxのボタンです。
• コンポーネントが一貫性を失う。 ページごとにカードやボタンを一から作り直すと、デザインシステムが損なわれます。

---

出力形式

このスキルでは、成果物よりも設計上の判断やレビュー用のメモを多く作成します。出力には以下が含まれます。

• デザイントークンファイル（プロジェクトの開始時）：design-tokens.md または同等のファイル
• コンポーネントまたはページのレビュー：6つの基準に照らして評価し、具体的な修正案を記載した Markdown のメモ
• 出荷前チェックリストの結果：チェックリストの各項目の合否とメモ

コンポーネントのコード（HTML、CSS、フレームワーク固有のマークアップ）を生成する場合も、SKILL.md は特定のスタックに依存しません。スタック固有のパターンはリファレンスファイルに記載されています。

---

リファレンスファイル

• references/design-tokens-template.md - あらゆるプロジェクトでトークンを設定するためのテンプレート。
• references/preship-checklist.md - 出荷前の最終デザインレビュー用チェックリスト。
• references/tailwind-patterns.md - 任意。Tailwind を使用するプロジェクト向けのコンポーネントパターン（ヒーロー、カード、ボタン、データ行）。