デザインシステムという言葉を聞いたことがあるだろうか。Googleの「Material Design」、Appleの「Human Interface Guidelines」、デジタル庁の「デザインシステムβ版」——名前は知っていても、「結局何なのか」「自分のプロジェクトにどう関係するのか」を明確に説明できるエンジニアは意外と少ない。
デザインシステムは「UIの設計図」ではない。「チーム全員が同じ言語でUIを語るための仕組み」だ。色の名前、ボタンの種類、余白の取り方——こうした設計の判断を属人的な感覚ではなく、共通のルールとして定義し、コードとドキュメントで共有する。それがデザインシステムの本質だ。
2026年現在、デザインシステムの重要性はさらに増している。Claude DesignのようなAIデザインツールが登場し、「コードベースからデザインシステムを自動構築する」時代になった。AIがUIを生成する時代だからこそ、デザインシステムという「仕様書」がなければ、毎回バラバラなUIが生成されてしまう。
この記事では、デザインシステムの基本概念から3層構造の実装、有名企業の事例、AI時代における変化まで——エンジニアがコードレベルで理解できる形で解説する。
デザインシステムとは何か — スタイルガイドとの違い、3層構造
デザイントークン — 色・フォント・余白をコードで管理する方法
コンポーネント — 再利用可能なUI部品の設計原則
有名事例 — デジタル庁・Material Design・Shopify Polaris・IBM Carbon
AI時代の変化 — Claude Design・DESIGN.mdとの連携
デザインシステムとは — 「UIのルールブック」を理解する
デザインシステムとは、プロダクトのUI（ユーザーインターフェース）に一貫性を持たせるための、設計ルール・再利用可能なコンポーネント・ドキュメントの集合体だ。
もう少し具体的に言えば、以下の問いに対する「チーム共通の答え」を体系化したものがデザインシステムだ。
- プライマリカラーは
#2563EBか#1D4ED8か？ - ボタンの角丸は
4pxか8pxかfull-roundedか？ - 見出しのフォントサイズは
24pxか1.5remか？ - エラーメッセージは赤いバナーで出すのか、インラインで出すのか？
- モーダルを閉じるボタンは右上か左上か？
こうした判断を個々のデザイナーやエンジニアが毎回考えていたら、UIは必ずバラバラになる。デザインシステムは、これらの判断を一度決めて、全員で共有する仕組みだ。
スタイルガイドとの違い
デザインシステムと混同されやすい概念を整理する。
| 概念 | 範囲 | 形式 | 例 |
|---|---|---|---|
| スタイルガイド | ビジュアルルールのみ | ドキュメント（PDF・Wiki） | 「プライマリカラーは#2563EB」 |
| コンポーネントライブラリ | 再利用可能なUI部品 | コード（React/Vue等） | <Button variant="primary"> |
| デザインシステム | 上記すべて＋ガイドライン＋設計原則 | コード＋ドキュメント＋Figma | Material Design全体 |
スタイルガイドは「何色を使うか」。コンポーネントライブラリは「何を使うか」。デザインシステムは「なぜ、どう使うか」まで含む。
デザインシステムの3層構造
デザインシステムは一般に、以下の3層で構成される。この構造はデジタル庁からGoogleまで、規模を問わず共通している。
（Design Tokens）"] --> B["コンポーネント
（Components）"] B --> C["ガイドライン
（Guidelines）"] A -.->|"色・フォント・余白"| A1["#2563EB / Inter / 16px"] B -.->|"UIパーツ"| B1["Button / Card / Modal"] C -.->|"使い方のルール"| C1["エラーは赤バナー
確認はモーダル"]
| 層 | 役割 | 具体例 |
|---|---|---|
| デザイントークン | 最小単位の設計値。色・フォント・余白・影・角丸 | --color-primary: #2563EB |
| コンポーネント | トークンを使って構築された再利用可能なUI部品 | <Button>, <Card>, <Modal> |
| ガイドライン | コンポーネントの使い方・禁止パターン・アクセシビリティ要件 | 「削除ボタンは必ず確認ダイアログを出す」 |
デザイントークンとは — UIの「変数」をコードで管理する
デザイントークンは、デザインシステムの最も基礎的な構成要素だ。「UI の設計値に名前をつけたもの」と理解すればよい。
なぜデザイントークンが必要か
デザイントークンがない世界を想像してみよう。
/* トークンなし: 同じ青が3種類のハードコード */
.header { background: #2563EB; }
.button { background: #2564EB; } /* 微妙に違う */
.link { color: #2563eb; } /* 大文字小文字の違い */
デザイントークンがあれば、設計値は1箇所で管理され、全UIが自動的に統一される。
/* トークンあり: Single Source of Truth */
:root {
--color-primary: #2563EB;
--color-primary-hover: #1D4ED8;
--color-text: #1A1A2E;
--font-heading: 'Inter', sans-serif;
--font-size-h2: 1.5rem;
--spacing-md: 16px;
--radius-md: 8px;
}
.header { background: var(--color-primary); }
.button { background: var(--color-primary); }
.link { color: var(--color-primary); }
デザイントークンの階層構造
実務で使われるデザイントークンは、3つの抽象レベルに分かれる。
| レベル | 名前 | 例 | 役割 |
|---|---|---|---|
| Primitive | 生の値 | blue-500: #2563EB |
カラーパレットの定義 |
| Semantic | 意味を持つ名前 | color-primary: {blue-500} |
用途に基づく命名 |
| Component | コンポーネント固有 | button-bg: {color-primary} |
特定UIへの適用 |
{
"color": {
"blue": {
"500": { "value": "#2563EB" }
},
"primary": { "value": "{color.blue.500}" },
"button": {
"background": { "value": "{color.primary}" }
}
}
}
Primitiveだけでは「何に使うか」がわからない。Semanticレイヤーが「この色はプライマリ用途」と意味を与え、Componentレイヤーが「ボタンの背景はプライマリ」と具体的に紐づける。
Tailwind CSSでのトークン管理
フロントエンドの現場では、Tailwind CSSの設定ファイルがデザイントークンの役割を果たすケースが多い。
// tailwind.config.js
module.exports = {
theme: {
colors: {
primary: '#2563EB',
'primary-hover': '#1D4ED8',
secondary: '#7C3AED',
background: '#FAFAFA',
text: '#1A1A2E',
error: '#DC2626',
success: '#16A34A',
},
fontFamily: {
heading: ['Inter', 'Noto Sans JP', 'sans-serif'],
body: ['Inter', 'Noto Sans JP', 'sans-serif'],
mono: ['JetBrains Mono', 'monospace'],
},
spacing: {
xs: '4px',
sm: '8px',
md: '16px',
lg: '24px',
xl: '32px',
},
borderRadius: {
sm: '4px',
md: '8px',
lg: '16px',
full: '9999px',
},
},
}
このファイルが「デザイントークンの実装」そのものだ。bg-primary、text-error、rounded-md ——Tailwindのユーティリティクラスがトークンの参照になる。
Web、iOS、Androidで同じデザインシステムを使う場合は、Amazon発のオープンソースツール Style Dictionary が有力だ。JSONで定義したトークンをCSS変数・SwiftUI・Android XML・Tailwind設定に自動変換できる。
コンポーネント — 再利用可能なUI部品の設計原則
デザイントークンが「素材」なら、コンポーネントは「部品」だ。トークンを使って構築された再利用可能なUI要素がコンポーネントにあたる。
コンポーネントの分類
コンポーネントはAtomic Design（Brad Frost提唱）の考え方で階層化されることが多い。
| レベル | 名前 | 例 | 説明 |
|---|---|---|---|
| Atom | 最小要素 | ボタン、入力欄、ラベル、アイコン | これ以上分解できないUI要素 |
| Molecule | 小さな複合体 | 検索バー（入力欄+ボタン）、フォームフィールド（ラベル+入力欄+エラーメッセージ） | Atomの組み合わせ |
| Organism | セクション | ヘッダー、カード一覧、サイドバー | Moleculeの組み合わせでページの一部を構成 |
| Template | ページ構造 | ダッシュボードレイアウト、記事ページ | Organismの配置を定義 |
| Page | 最終画面 | トップページ、設定画面 | 実データが入ったTemplate |
ボタン/入力欄"] --> B["Molecule
検索バー"] B --> C["Organism
ヘッダー"] C --> D["Template
ダッシュボード"] D --> E["Page
実画面"]
コンポーネントの実装パターン
デザインシステムのコンポーネントは、バリアント（variant）パターンで実装するのが標準的だ。
// Button コンポーネント（React + Tailwind）
type ButtonVariant = 'primary' | 'secondary' | 'danger' | 'ghost';
type ButtonSize = 'sm' | 'md' | 'lg';
const variantStyles: Record<ButtonVariant, string> = {
primary: 'bg-primary text-white hover:bg-primary-hover',
secondary: 'bg-gray-100 text-gray-800 hover:bg-gray-200',
danger: 'bg-error text-white hover:bg-red-700',
ghost: 'bg-transparent text-primary hover:bg-gray-50',
};
const sizeStyles: Record<ButtonSize, string> = {
sm: 'px-3 py-1.5 text-sm rounded-sm',
md: 'px-4 py-2 text-base rounded-md',
lg: 'px-6 py-3 text-lg rounded-md',
};
export function Button({ variant = 'primary', size = 'md', children, ...props }) {
return (
<button className={`${variantStyles[variant]} ${sizeStyles[size]}`} {...props}>
{children}
</button>
);
}
// 使用例
<Button variant="primary" size="md">保存する</Button>
<Button variant="danger" size="sm">削除</Button>
<Button variant="ghost">キャンセル</Button>
このパターンなら、デザイントークン（bg-primary）がコンポーネントに組み込まれ、使う側は variant を選ぶだけでブランドに準拠したUIが生成される。
有名事例 — 世界と日本のデザインシステムを比較する
デザインシステムの具体像を掴むには、実際の事例を見るのが一番だ。世界的に有名な事例と日本の事例を比較する。
デジタル庁デザインシステム（日本）
日本で最も注目すべきデザインシステムがデジタル庁のβ版（design.digital.go.jp）だ。
| 項目 | 内容 |
|---|---|
| 目的 | 「誰一人取り残されない、人に優しいデジタル化」の実現 |
| バージョン | v2.13.0（β版） |
| フォント | Noto Sans JP（本文）、Noto Sans Mono（コード） |
| 提供形式 | HTML/CSS/JavaScript、React/Tailwind CSS、Figma |
| 特徴 | アクセシビリティファースト。全コンポーネントにアクセシビリティチェック済み |
| ライセンス | 誰でも無料で利用可能 |
デジタル庁のデザインシステムの最大の特徴はアクセシビリティへの徹底だ。全てのサンプルコードにキーボード操作・スクリーンリーダー対応が組み込まれている。行政サービスは「全国民が使えなければならない」という制約があるため、アクセシビリティが最優先事項となっている。
また、デザイントークンをベースにしたTailwind CSSプラグインも公式提供しており、エンジニアがすぐに実装に取り込める点も実用的だ。
Google Material Design
Material Designは世界で最も普及したデザインシステムだ。2014年の初版から10年以上進化し続けている。
| 項目 | 内容 |
|---|---|
| コンセプト | 「Material Metaphor」 — UIが物理的な表面のように振る舞う |
| 特徴 | 影（Elevation）、リップルエフェクト、レスポンシブモーション |
| 提供形式 | Web Components、Android Jetpack Compose、Flutter |
| トークン管理 | Material Theme Builder でカスタマイズ |
| ターゲット | クロスプラットフォーム（Android中心） |
Material Designの強みはクロスプラットフォーム対応だ。Android、Web、Flutter——どの環境でも同じ設計言語が使える。一方で、Apple環境では「Androidっぽい」と感じるユーザーもおり、iOS向けにはApple HIG（Human Interface Guidelines）との使い分けが必要になる。
Shopify Polaris
ECプラットフォームShopifyのデザインシステム「Polaris」は、エンジニアフレンドリーな事例として参考になる。
| 項目 | 内容 |
|---|---|
| コンポーネント数 | 90以上（React） |
| 特徴 | EC特化。商品管理・注文処理・ダッシュボードに最適化 |
| 提供形式 | React、Figma UI Kit |
| ドキュメント | コンポーネントごとに「Do / Don’t」の使い方ガイド |
Polarisの優れた点は、全コンポーネントに「Do（推奨）」と「Don’t（非推奨）」の具体例がドキュメントに含まれていること。「ボタンにはアクション動詞を使う（Do: 商品を追加 / Don’t: 送信）」のように、エンジニアが迷わない指針が用意されている。
IBM Carbon
IBMのCarbon Design Systemは、エンタープライズ向けの重厚な事例だ。
| 項目 | 内容 |
|---|---|
| 特徴 | アクセシビリティ重視、データ可視化コンポーネント充実 |
| 提供形式 | React、Angular、Vue、Web Components、Svelte |
| 強み | 5フレームワーク対応。チャート・テーブル等のデータUI |
| オープンソース | GitHub上で完全公開 |
SmartHR Design（日本）
日本のSaaSスタートアップから生まれたデザインシステムとして、SmartHR Designは特筆すべき事例だ。
| 項目 | 内容 |
|---|---|
| コンセプト | 「すべての人によりよい体験を届けるためのデザインシステム」 |
| 特徴 | デザイントークン・コンポーネント・アクセシビリティ・コミュニケーションガイドラインまで網羅 |
| 提供形式 | SmartHR UI（オープンソース） |
| アクセシビリティ | WCAG準拠、代替テキスト・多言語対応・ロービジョン対応を含む |
| OSSか | Yes（「情報をオープンにすることは社会に良い影響をもたらす」が方針） |
SmartHR Designが優れている点は、日本語環境に特化した設計判断が随所にある点だ。日本語フォントの行間、敬語・丁寧語のトーンガイドライン、多言語対応まで——日本のSaaS開発者にとって最も参考になるデザインシステムの一つだ。
事例比較まとめ
| デザインシステム | ターゲット | 特化領域 | FW対応数 | OSSか |
|---|---|---|---|---|
| デジタル庁 | 行政サービス | アクセシビリティ | 2（HTML/CSS, React） | Yes |
| SmartHR Design | SaaS（HR） | 日本語環境・a11y | React | Yes |
| Material Design | 汎用（Android中心） | クロスプラットフォーム | 3+ | Yes |
| Shopify Polaris | EC | 商品管理・ダッシュボード | 1（React） | Yes |
| IBM Carbon | エンタープライズ | データ可視化 | 5 | Yes |
| Apple HIG | Apple製品 | プラットフォーム体験 | SwiftUI | No |
| Salesforce Lightning | CRM・SaaS | 業務アプリ | 1（Vanilla CSS） | Yes |
共通点は「全てオープンソースまたは無料公開」という点。デザインシステムは秘密にするものではなく、公開してエコシステム全体の品質を底上げするものだ。自分のプロジェクトでデザインシステムを作る際は、これらの事例をベースに始めるのが最も効率的だ。
AI時代のデザインシステム — Claude DesignとDESIGN.mdが変えるもの
2026年、デザインシステムの役割が大きく変わりつつある。AIがUIを生成する時代になり、デザインシステムは「人間が読むドキュメント」から「AIが参照する仕様書」としての性格を強めている。
Claude Designによる自動構築
Claude Designは、コードベースやFigmaファイルを読み込んでデザインシステムを自動構築する。手動でトークンを定義する時代から、AIが既存のコードから設計値を抽出する時代に移行しつつある。
【Claude Designのデザインシステム構築フロー】
1. GitHubリポジトリまたはローカルフォルダを接続
2. Claude Opus 4.7がコードを解析
3. カラーパレット・タイポグラフィ・コンポーネントを自動抽出
4. デザインシステムとして構造化
5. 以降のプロジェクトに自動適用
DESIGN.mdの登場
DESIGN.mdは、AIエージェント（Claude Code、Cursor等）がUIを生成する際に参照するMarkdown形式の仕様書だ。Figma TokensやStyle DictionaryがJSONベースでツール連携を前提としているのに対し、DESIGN.mdはプレーンテキストでLLMが直接読める。
# DESIGN.md
## Color Tokens
| Token | Value | Usage |
|-------|-------|-------|
| primary | #2563EB | CTA buttons, links |
| secondary | #7C3AED | Accents, tags |
| background | #FAFAFA | Page background |
| text | #1A1A2E | Body text |
| error | #DC2626 | Error states |
## Typography
- Heading: Inter, 700, 1.5rem
- Body: Inter, 400, 1rem
- Code: JetBrains Mono, 400, 0.875rem
## Components
### Button
- Primary: bg-primary, text-white, rounded-md
- States: hover(darken 10%), disabled(opacity 50%)
- Min-width: 120px, padding: 8px 16px
このファイルをプロジェクトルートに置くだけで、Claude Codeは毎回一貫したUIを生成する。awesome-design-mdリポジトリには58ブランド分の実装例が公開されている。
デザインシステムの未来
人間が手動で管理"] C["AI時代のデザインシステム"] --> D["Claude Design + DESIGN.md
AIが自動構築・参照"] B --> E["エンジニアが実装に変換"] D --> F["Claude Codeが直接実装"] E --> G["UIの一貫性"] F --> G
デザインシステムの本質——「チーム全員が同じ言語でUIを語る」——は変わらない。変わるのは「チーム」の定義だ。2026年のチームにはAIエージェントが含まれる。AIがデザインシステムを理解し、遵守できる形式で定義することが、これからの標準になっていく。
デザインシステムを「大規模なプロジェクトのもの」と思わなくてよい。DESIGN.mdを1ファイル書くだけで、AIが一貫したUIを出力するようになる。書き方の詳細はDESIGN.md入門を参照。
デザインシステムの始め方 — 小さく始めて育てる
最後に、自分のプロジェクトでデザインシステムを始めるための実践的なステップを示す。
ステップ1: 最小限のトークンを定義する
最初から完璧なシステムを作ろうとしない。まずはカラー・タイポグラフィ・スペーシングの3カテゴリだけ定義する。
:root {
/* カラー */
--color-primary: #2563EB;
--color-text: #1A1A2E;
--color-background: #FAFAFA;
--color-error: #DC2626;
/* タイポグラフィ */
--font-sans: 'Inter', 'Noto Sans JP', sans-serif;
--font-size-base: 1rem;
--font-size-lg: 1.25rem;
--font-size-xl: 1.5rem;
/* スペーシング */
--space-sm: 8px;
--space-md: 16px;
--space-lg: 24px;
}
ステップ2: DESIGN.mdに書き出す
定義したトークンをDESIGN.mdとしてリポジトリに配置する。AIエージェントが参照できるようになる。
ステップ3: 最も使うコンポーネントを3つ作る
全コンポーネントを最初から用意する必要はない。まずは以下の3つから。
- Button: Primary / Secondary / Danger の3バリアント
- Card: タイトル + 本文 + アクション
- Input: ラベル + 入力欄 + エラーメッセージ
ステップ4: ガイドラインは使いながら追加する
「こういうケースはどうする？」という疑問が出たときに、その都度ガイドラインを追加する。必要になるまで書かない。
ステップ5: Claude Designで加速する
ある程度コードが溜まったら、Claude Designにコードベースを接続してデザインシステムを自動構築してみる。手動で定義した内容とAIが抽出した内容を比較・統合することで、より堅牢なシステムに仕上がる。
