Webサイトやアプリの規模が大きくなるにつれて、「ボタンのスタイルがページごとに微妙に違う」「同じような見出しなのにフォントサイズがバラバラ」といったUIの不整合が発生しがちです。これらの問題は、デザインの一貫性を損なうだけでなく、開発効率の低下やメンテナンスコストの増大にもつながります。
こうした課題を解決するのがデザインシステムです。デザインシステムとは、UIコンポーネント、デザイントークン、ガイドラインなどを体系的にまとめた「デザインの共通言語」のことで、Google（Material Design）、Apple（Human Interface Guidelines）、SmartHR（SmartHR Design System）など、多くの企業が構築・公開しています。
この記事では、デザインシステムの基本概念から構築手順、運用のコツまでを解説します。
デザインシステムの構成要素
デザイントークン
デザイントークンは、デザインシステムの最も基礎的な要素です。色、フォントサイズ、余白、角丸、影などの「デザイン上の値」を変数として定義したもので、デザインとコードの間で共通の値を参照する仕組みとして機能します。
例えば、メインカラーを#3B82F6と直接指定するのではなく、--color-primaryというトークンに格納しておきます。メインカラーを変更する場合、トークンの値を1箇所変えるだけで、サイト全体に反映されます。
UIコンポーネント
UIコンポーネントは、ボタン、入力フォーム、カード、モーダル、ナビゲーションなど、再利用可能なUI部品です。各コンポーネントのデザインパターン（バリエーション、ステート、サイズなど）をあらかじめ定義し、Figmaのコンポーネントライブラリやコードのコンポーネントライブラリとして管理します。
デザインガイドライン
トークンやコンポーネントの「使い方」を説明するドキュメントです。「どのような場面でこのボタンを使うのか」「余白のルール」「アイコンの使用ルール」「文章のトーン&マナー」などを明文化します。
デザインシステムは「デザイントークン → UIコンポーネント → ガイドライン」の順に積み上げて構築するのがおすすめです。トークンが土台としてしっかり定義されていれば、コンポーネントの設計がスムーズに進みます。
デザイントークンの設計方法
トークンの階層構造
デザイントークンは、以下の3つの階層に分けて設計するのが一般的です。
- プリミティブトークン（Global Token）：色やフォントサイズなどの「生の値」を定義する最下層。
--blue-500: #3B82F6のように色名とレベルで管理する - セマンティックトークン（Alias Token）：プリミティブトークンに「意味」を持たせたもの。
--color-primary: var(--blue-500)のように用途名で参照する - コンポーネントトークン：特定のコンポーネントに限定したトークン。
--button-bg-primary: var(--color-primary)のようにコンポーネント名を含める
プリミティブトークンだけでは「何に使う色なのか」が分からないため、セマンティックトークンの設計が重要です。--blue-500ではなく--color-primaryと命名することで、デザインの意図がコードに反映されます。
色のトークン設計
色のトークンは、まずプリミティブトークンとしてカラーパレットを定義し、その上にセマンティックトークンを構築します。
- ブランドカラー：primary、secondary、tertiaryなどのブランドを表す色
- 機能カラー：success（成功）、warning（警告）、error（エラー）、info（情報）
- ニュートラルカラー：背景色、テキスト色、ボーダー色などに使うグレーの階調
- 表面カラー：surface-primary（メインの背景）、surface-secondary（セクション背景）など
タイポグラフィのトークン設計
フォントサイズ、行間（line-height）、フォントウェイト（太さ）、レタースペーシング（字間）などをトークンとして定義します。
- フォントサイズ：xs（12px）、sm（14px）、md（16px）、lg（20px）、xl（24px）、2xl（32px）のようなスケールを定義
- 行間：tight（1.25）、normal（1.5）、relaxed（1.75）などの段階を設ける
- フォントウェイト：regular（400）、medium（500）、bold（700）などを定義
スペーシング（余白）のトークン設計
余白の値をトークン化することで、サイト全体の余白に一貫性を持たせることができます。4の倍数または8の倍数のスケール（4px、8px、12px、16px、24px、32px、48px、64px）が広く採用されています。
UIコンポーネントの設計と管理
コンポーネントの粒度を決める
コンポーネントの粒度（どこまで細かく分けるか）は、Atomic Designの考え方を参考にすると整理しやすくなります。
- Atoms（原子）：ボタン、ラベル、アイコン、入力フィールドなど最小単位のUI要素
- Molecules（分子）：検索バー（入力フィールド＋ボタン）、フォームグループ（ラベル＋入力フィールド＋エラーメッセージ）など、Atomsの組み合わせ
- Organisms（有機体）：ヘッダー、フッター、カードリスト、ナビゲーションバーなど、Moleculesの組み合わせ
- Templates/Pages：ページ全体のレイアウトパターン
コンポーネントのバリエーション設計
各コンポーネントに対して、以下の観点でバリエーションを設計します。
- タイプ：Primary（主要）、Secondary（補助）、Tertiary（第3）、Ghost（枠線のみ）
- サイズ：Small、Medium、Large
- 状態（ステート）：Default、Hover、Active、Focus、Disabled、Loading
コンポーネントのバリエーションを増やしすぎると、管理コストが膨大になります。最初は必要最小限のバリエーションだけを作り、実際の開発で必要になったタイミングで追加するのがおすすめです。「将来使うかもしれない」バリエーションを先に作ると、使われないまま放置されるケースが多くなります。
Figmaでのデザインシステム構築
Figma Variablesの活用
Figmaでは、Variables（変数）機能を使ってデザイントークンを定義できます。色、数値、文字列、ブール値をVariablesとして登録し、コンポーネントのプロパティにバインドすることで、トークンの変更がデザイン全体に即座に反映されます。
さらに、VariablesのModes機能を使えば、ライトモードとダークモードの色セットを切り替えたり、デスクトップとモバイルで異なるスペーシングを適用したりすることも可能です。
コンポーネントライブラリの公開
Figmaで作成したコンポーネントは、チームライブラリとして公開することで、他のファイルからも参照できるようになります。コンポーネントを更新したら、ライブラリを「Publish」するだけで、参照しているすべてのファイルに更新通知が届きます。
デザインシステムの運用と維持
ドキュメントの整備
デザインシステムは構築して終わりではなく、継続的な運用と更新が必要です。各コンポーネントの使用ルール、トークンの命名規則、変更履歴などをドキュメントとして整備しておくことで、チームメンバーが正しくデザインシステムを活用できるようになります。
Storybookを導入すれば、UIコンポーネントのカタログを自動生成でき、各コンポーネントの見た目や挙動を確認しながら開発を進められます。
ガバナンスの確立
デザインシステムの品質を維持するためには、変更管理のルールを決めておく必要があります。
- コンポーネントの追加・変更を誰が承認するか
- 変更の影響範囲をどのように評価するか
- バージョン管理はどのように行うか（セマンティックバージョニングなど）
- 定期的なレビューの頻度とメンバー
小規模チームでのデザインシステムの始め方
最小限の構成から始める
デザインシステムの構築は、大がかりなプロジェクトにする必要はありません。以下の3ステップで小さく始めましょう。
- Step 1：色のトークンを定義する（メインカラー、サブカラー、テキスト色、背景色）
- Step 2：タイポグラフィのトークンを定義する（見出し、本文、キャプションのフォントサイズ・行間）
- Step 3：最頻出のコンポーネントだけを作る（ボタン、入力フィールド、カード）
最初から完璧なデザインシステムを目指す必要はありません。実際のプロジェクトで使いながら徐々に拡充していくのが、現実的かつ持続可能なアプローチです。
既存プロジェクトからの抽出
既にあるWebサイトやアプリのUIを棚卸しして、共通のパターンを抽出するのも有効な方法です。「すでに使っている色」「すでに使っているボタンのスタイル」をリストアップし、それを整理・統一するところからデザインシステムを構築できます。
よくある質問（Q&A）
Q：デザインシステムは何人のチームから必要ですか？
A：1人のプロジェクトでもデザインシステムは有効です。自分自身の作業効率を上げるため、色やフォントサイズを変数化しておくだけでも十分な効果があります。チームの規模が大きくなるほどデザインシステムの恩恵は大きくなりますが、始めるタイミングに「早すぎる」ということはありません。
Q：デザイントークンとCSS変数は同じものですか？
A：CSS変数（カスタムプロパティ）はデザイントークンの実装手段の一つです。デザイントークンは概念であり、CSS変数以外にもJSON形式で定義してビルドツールで各プラットフォーム用に変換する方法もあります。W3C Design Tokens Community Groupが標準化を進めています。
Q：Atomic Designは必ず採用すべきですか？
A：Atomic Designはコンポーネントの粒度を考える上で有用なフレームワークですが、必ずしも厳密に5階層（Atoms、Molecules、Organisms、Templates、Pages）に分ける必要はありません。プロジェクトの規模に応じて、2〜3階層に簡略化しても問題ありません。
Q：デザインシステムの構築にどのくらい時間がかかりますか？
A：規模によりますが、最小限のトークンとコンポーネント（色・タイポグラフィ・ボタン・フォーム）であれば1〜2週間で構築できます。本格的なデザインシステムの場合は3〜6か月を見込む必要がありますが、完成を待ってから使い始めるのではなく、作りながら並行して活用するのが効率的です。
Q：公開されている他社のデザインシステムをそのまま使っても良いですか？
A：Material DesignやSmartHR Design Systemなどの公開デザインシステムは、学習やインスピレーションの参考にはなりますが、そのまま使うと自社のブランドやUI要件に合わない部分が出てきます。構造やトークン設計のパターンを参考にしつつ、自社の要件に合わせてカスタマイズするのが現実的なアプローチです。
まとめ
デザインシステムは、デザイントークン、UIコンポーネント、ガイドラインの3つの要素で構成され、UIの一貫性と開発効率を両立させる仕組みです。トークンは「プリミティブ → セマンティック → コンポーネント」の3層構造で設計し、コンポーネントはタイプ・サイズ・ステートのバリエーションを定義します。
まずは色とタイポグラフィのトークン定義から始めて、最頻出のコンポーネントを3〜5種類作るところからスタートしましょう。構築して終わりではなく、継続的な運用とチームでのルール共有が、デザインシステムを「使われるもの」にするための鍵です。
