design-systems

デザインシステム

デザインシステムの専門家として、デジタル製品を大規模に展開する際に一貫性をもたらす、相互につながったパターンと共有プラクティスについてご案内します。推奨事項は、Brad FrostのAtomic Design手法、Alla Kholmatovaのパターン主導のアプローチ、Nathan Curtisのシステムガバナンスモデル、W3C Design Tokens仕様、そしてMaterial Design 3、Polaris（Shopify）、Carbon（IBM）、Spectrum（Adobe）などの実際のシステムを基盤としています。

デザインシステムは、ほかの製品に役立つ製品です。決して「完成」することはありません。優れたシステムかどうかは、初日にどれだけ包括的かではなく、1年後も役に立ち、使われ続け、進化し続けているかで測られます。

---

コアコンセプト

2種類のパターン

あらゆるデザインシステムは、切り離せない2つのレイヤーから構成されます（Kholmatova）。

種類	対象	例
機能パターン	ユーザーが操作する具体的な構成要素	ボタン、フォームフィールド、カード、モーダル、ナビゲーション、タブ
知覚パターン	ブランドの個性を表現する美的特性	カラーパレット、文字サイズの尺度、余白、モーション、声とトーン、アイコンのスタイル

ボタンは機能パターンです。角丸、色、シャドウ、フォントの太さ、ホバー時のアニメーションは、そのボタンに適用される知覚パターンです。両方のレイヤーに取り組む必要があります。

コンポーネントの階層（Atomic Design）

UIの粒度を示す5つのレベルです。これは直線的なプロセスではなく、思考モデルです。

レベル	定義	例	デザインシステムでの役割
アトム	それ以上分解できない最小の要素	ラベル、入力欄、ボタン、アイコン、色見本、フォントスタイル	デザイントークン＋基本コンポーネント
モレキュール	ひとまとまりとして機能する、アトムのシンプルなグループ	検索フォーム（ラベル＋入力欄＋ボタン）、フォームフィールド（ラベル＋入力欄＋補助テキスト）	コアコンポーネント
オーガニズム	モレキュールとアトムで構成される複雑なコンポーネント	サイトヘッダー、商品カードのグリッド、チェックアウトフォーム、フッター	複合コンポーネント
テンプレート	オーガニズムを配置するページレベルのレイアウト。実際のコンテンツは含みません	ダッシュボードのレイアウト、設定ページの構成、記事テンプレート	レイアウトパターン
ページ	実際のコンテンツを含む、具体的なテンプレートのインスタンス	ライブデータを表示するホームページ、エッジケースのコンテンツを含むプロフィール	検証とストレステスト

最初にアトムをデザインし、次にモレキュールをデザインするわけではありません。すべてのレベルに同時に取り組みます。この階層はシステムを整理するためのものであり、ワークフローを規定するものではありません。

デザイントークン

デザイントークンは、デザインシステムのアトミックな値です。デザイン上の決定を、名前付きでプラットフォームに依存しない形で表現します。

トークンの階層（3層アーキテクチャ）：

階層	目的	例	変更するタイミング
グローバル／参照	利用可能なすべての値を含む基本パレット	blue-500: #2563EB、space-4: 16px	まれに変更します。ブランドレベルの決定時
セマンティック／エイリアス	グローバル値を参照する、用途に応じてマッピングされたトークン	color-action-primary: {blue-500}、space-inline-md: {space-4}	意味が変わるとき
コンポーネント	セマンティックトークンを参照する、コンポーネント固有のトークン	button-bg-primary: {color-action-primary}	コンポーネントのデザインが変わるとき

命名規則（W3C準拠）：

{category}-{property}-{variant}-{state}
color-background-primary-hover
space-padding-card-default
font-size-heading-lg

コンポーネントコードでは、生の16進数コード、ピクセル値、マジックナンバーを決して使わないでください。必ずトークンを参照してください。

---

デザインシステムを構築するタイミング

必要とする兆候

• 同じ製品に3人を超えるデザイナー、または5人を超える開発者が関わっている
• ビジュアル監査で、10種類以上のボタンスタイル、5種類以上の文字サイズの尺度、または3種類以上のモーダル実装が見つかる
• チームが既存のパターンを再発明するため、新機能の開発に時間がかかる
• 同じカテゴリでアクセシビリティ違反が繰り返し発生する
• ブランド刷新またはプラットフォーム移行が計画されている

まだ必要としない兆候

• デザイナーまたは開発者が1人だけの場合。個人用のスタイルガイドで十分です
• 製品が急速な探索や方向転換の段階にある場合。方針が定まってから体系化します
• 画面が20未満の場合。導入の負担がメリットを上回ります

---

インターフェースの棚卸し（5段階の監査）

システムを構築する前に、既存のものを監査します。これは、組織の合意を得るうえで最も説得力のある資料です。

1. チームを編成する：デザイン、開発、プロダクト、QA のメンバーを含めます。多様な視点があれば、より多くの不整合を見つけられます
2. 共有キャンバスを用意する：Google Slides、Miro、または FigJam を使い、パターンのカテゴリごとにセクションを分けます
3. スクリーンショットを集める：全員が実際のプロダクトから UI パターンのスクリーンショットを撮ります。カテゴリ：ボタン、フォームフィールド、ナビゲーション、カード、モーダル、タイポグラフィ、アイコン、色、スペーシング
4. 調査結果を発表する：カテゴリごとにまとめたスクリーンショットをすべて表示します。不整合は一目瞭然です。同じ問題を解決するボタンのスタイルが15種類、グレーの色合いが8種類、カードのレイアウトが4種類あります
5. 次のステップを決める：統合の優先順位を付けます。最もよく使われ、最も一貫性のないパターンから始めます

監査カテゴリのチェックリスト：

• ボタンと CTA
• フォーム入力とコントロール
• ナビゲーションパターン
• カードとコンテンツコンテナ
• モーダルとオーバーレイ
• 使用中のタイポグラフィスタイル
• 使用中の色の値
• 使用中のスペーシングの値
• アイコンのスタイル
• 読み込み中と空の状態
• エラーとフィードバックのパターン

---

コンポーネント仕様

システム内のすべてのパターンに仕様が必要です。仕様が不完全だと、実装にばらつきが生じます。

必須項目

項目	記載する内容
名前	文脈に依存せず、構造に基づいた名前にします。「Product card」ではなく「Card」、「Login modal」ではなく「Modal」
目的	満たすユーザーニーズを1文で記載します。目的を説明できない場合、そのパターンは不要かもしれません
構成要素	名前付きのサブパーツ（例：Card = 画像 + タイトル + 説明 + アクション）
バリエーション	使い分けの指針を含む、正当なバリエーション。最大5種類です。それ以上ある場合は、パターンを分割する必要があることを示しています
状態	デフォルト、ホバー、アクティブ、フォーカス、無効、読み込み中、エラー、空
動作	インタラクションのルール：何が何を引き起こすか、キーボードのサポート、アニメーション
コンテンツのガイドライン	最小／最大の文字数、切り詰めのルール、プレースホルダーテキスト
アクセシビリティ	ARIA ロール、キーボードナビゲーション、スクリーンリーダーの動作、コントラスト要件
レスポンシブ時の動作	ブレークポイントごとのコンポーネントの適応方法
使用するトークン	コンポーネントが参照するデザイントークン
関連パターン	一緒によく使われるパターン、または混同しやすいパターン

「同じか、別か？」の判断

2つの要素の見た目が似ていても、異なるパターンである可能性がある場合：

• 目的が同じ ＋ 動作が同じ → 見た目が異なっていても同じパターン → 統合する
• 見た目が同じ ＋ 目的が異なる → 別のパターン → 分ける
• 目的が同じ ＋ 動作が異なる → 別のパターンである可能性が高い → さらに調査する

目的と動作がパターンの同一性を決めます。見た目では決まりません。

---

命名パターン

原則

1. 内容ではなく構造で命名する：「Homepage carousel」ではなく「Carousel」、「Status badge」ではなく「Badge」
2. 機能に基づく名前を使う：「Primary action」は目的を伝えます。「Blue button」は見た目を伝えます（見た目は変わる可能性があります）
3. 協力して名前を決める：デザイナー、開発者、コンテンツストラテジストを巻き込みます。特定の職種の人にしか理解できない名前ではうまくいきません
4. 具体的にする：テキスト入力、セレクト、チェックボックス、トグルがある場合、「Input」では曖昧です
5. どこでも同じ名前を使う：デザインファイル、コード（クラス名、コンポーネント名）、会話、ドキュメントで同じ名前を使います

命名のテスト

優れたパターン名は、次の3つの条件を満たします：

• 新しいチームメンバーが、名前だけでそれが何か推測できる
• ビジュアルデザインが完全に変わっても、その名前を使い続けられる
• パターンが登場するあらゆるコンテキストで、その名前を使える

---

ガバナンス

貢献モデル

モデル	仕組み	最適な対象
集中型	専任のシステムチームがすべてを管理します。プロダクトチームは変更を依頼します	大規模な組織（デザイナー／開発者が50人以上）、厳格なブランドの一貫性が求められる場合
連携型	プロダクトチームがパターンをシステムに還元します	中規模の組織、動きの速いプロダクト、分散型チーム
ハイブリッド型	コアチームが基盤（トークン、コアコンポーネント）を管理します。プロダクトチームはドメイン固有のパターンを管理します	ほとんどの組織 — 一貫性とスピードのバランスを取れます

パターンのライフサイクル

Proposed → Under Review → Accepted → Built → Documented → Published → [Deprecated]

新しいパターンの受け入れ基準：

• 3つ以上のコンテキストで使用されている（または必要とされている）
• 目的が明確に文書化されている
• アクセシビリティ要件を満たしている（最低でも WCAG 2.2 AA）
• レスポンシブ時の動作が定義されている
• コンテンツガイドラインが含まれている
• チームメンバー2人以上がレビューしている

システムを維持し続ける

デザインシステムが失敗する最大の原因は放置です。立ち上げ時には熱意があっても、6か月以内に衰退します。

予防チェックリスト：

• 専任の担当者（個人またはチーム）と割り当てられた時間 — 1人の稼働時間の最低20%
• システム優先のワークフロー：変更はシステムで発生し、その後プロダクトに反映します。逆の順序にはしません
• パターンライブラリと本番コードを自動同期する
• リリースごとに変更履歴を公開する
• ライブラリと実際のプロダクトを比較する監査を四半期ごとに実施する
• 貢献プロセスを文書化し、手間なく参加できるようにする — システムを使うほうがゼロから作るより簡単であること
• 関係者と定期的に「システムの現状」をレビューする

---

システムの成熟度レベル

レベル	特徴	注力事項
1 — アドホック	共通パターンがありません。各機能を個別に構築します	インターフェースの棚卸しを実施します。一貫性に欠ける点を上位10個特定します
2 — 成長期	一部のスタイル（色、フォント）は共通化されています。コンポーネントライブラリはありません	トークンを定義します。最もよく使われるコンポーネントを10〜15個文書化します
3 — 管理段階	コンポーネントライブラリがあります。導入は部分的です	ガバナンスプロセス。導入状況の指標。カバー範囲の不足を補います
4 — 体系化	すべての新しい作業はシステムを出発点とします	最適化。クロスプラットフォーム対応。高度なテーマ設定
5 — 定着	システムがプロダクトの意思決定を導き、チーム文化の中心となっています	イノベーション。コミュニティからの貢献。業界をリードします

ほとんどの組織は、初年度にレベル3、2年以内にレベル4を目指すべきです。レベル5に達する組織はまれであり、組織全体の大きな取り組みが必要です。

---

よくある間違い

間違い	うまくいかない理由	代わりに行うこと
プロダクトで使われる前にシステム全体を構築する	フィードバックの循環がありません。パターンが実際のニーズに合いません	実際のプロダクトと並行して構築します。動作するコードからパターンを抽出します
コンテンツに基づいてパターンに名前を付ける（「ヒーローバナー」「プロダクトカード」）	コンテンツが変わったり、パターンが再利用されたりすると、名前が適切でなくなります	構造と目的に基づいて名前を付けます
システムを一度きりのプロジェクトとして扱う	メンテナンスをしなければ、システムは衰退します	ロードマップ、バックログ、専用リソースを備えたプロダクトとして扱います
開発者向けのドキュメントしか用意しない	デザイナー、PM、コンテンツストラテジストがシステムを利用できません	分野をまたいで活用できるドキュメントにします
コンポーネントのバリアントが多すぎる	認知的負荷が高まり、使い方に一貫性がなくなります	バリアントは最大5つにします。5つを超える場合は、別々のパターンに分割します
コンポーネント仕様でアクセシビリティを考慮しない	アクセシビリティを後から追加すると、コストが5〜10倍になります	ARIA、キーボード操作、コントラストの要件をすべての仕様に組み込みます
他社のシステムを丸ごとコピーする	他社と自社では状況もトレードオフも異なります	他社から学びつつ、自社固有のプロダクト、チーム、ユーザーに合わせて構築します

---

参考ファイル

特定のトピックについて詳しく知りたい場合は、以下を読み込んでください。

• references/component-hierarchy.md — アトム、分子、生命体、テンプレート、ページの詳細な説明、識別ガイドライン、構成ルール
• references/design-tokens.md — トークンのアーキテクチャ、命名規則、W3C 形式、テーマ設定、プラットフォームへの提供
• references/pattern-documentation.md — 解剖図、状態、コンテンツルール、アクセシビリティを含む包括的なパターン項目の作成方法
• references/governance-and-maintenance.md — 貢献モデル、ライフサイクル管理、バージョン管理、コミュニケーション、導入戦略
• references/perceptual-patterns.md — カラーシステム、タイポグラフィのスケール、スペーシングシステム、モーションの原則、ボイス＆トーンのガイドライン

テンプレート

• templates/component-spec-template.md — コンポーネント仕様書一式
• templates/design-system-audit-template.md — インターフェースの一覧とシステムの評価
• templates/token-architecture-template.md — デザイントークンの構造と命名規則

例

• examples/system-audit-walkthrough.md — 架空のeコマース製品をエンドツーエンドで監査し、不整合と統合計画を明らかにする例
• examples/component-spec-walkthrough.md — Card コンポーネントを目的からアクセシビリティまで仕様化する例