デザインシステムとは — スタイルガイドとの違い

「うちにはデザインシステムがあります」という言葉を発注者から聞いたとき、制作者はまず実態を確認しなければならない。その「デザインシステム」が、実際にはカラーパレットとフォントの一覧をまとめたPDFである、というケースが現場では珍しくない。

両者が混同されやすいのは、どちらも「デザインの基準をまとめたもの」という外形を持つためである。Webサイトのリニューアル案件では、発注者が「前回制作時に作ったスタイルガイドがある」と資料を提示してくることがある。ところがその中身は配色とフォントの指定のみで、ボタンの状態遷移も、フォームのエラー表示の仕様も、間隔の命名規則も存在しない。それでも「デザインシステムがある」という前提で会話が進むと、制作の後半でゼロから仕様決定をすることになる。

この混同は制作者側にも存在する。コンポーネントライブラリをFigmaで構築し「デザインシステムを整備した」と言う現場があるが、そのコンポーネントにどう命名するか・いつ追加するか・誰がレビューするかのルール（ガバナンス）が存在しなければ、半年後には誰も参照しない負債になる。

概念の違いを理解しないまま進めることによる実害は、プロジェクトの中盤以降に表れる。「スタイルガイドに書いてある」と「デザインシステムで定義されている」は、運用上の重さがまったく異なる。前者は参照されないことがあり、後者は実装と連動して強制力を持つ。この違いを制作者も発注者も正確に把握していることが、長期的な品質維持の前提となる。

スタイルガイドとは、ブランドやプロダクトのビジュアル表現に関するルールを文書化したものである。典型的な内容は以下の通りだ。

• プライマリカラー・セカンダリカラーの16進数コード
• 見出し・本文・キャプションのフォントファミリーとサイズ
• ロゴの使用ルールと禁止事項
• 写真・イラストのトーン&マナー

スタイルガイドは「参照するドキュメント」として機能する。制作者がビジュアルの一貫性を保つための手引きであり、そこには本来「このドキュメントを見れば作れる」という情報が揃っている。

スタイルガイドで十分に解決できる問題がある。単一のコーポレートサイトを制作会社が都度制作するような場合、発注者がブランドカラーとフォント指定をまとめた文書を持っていれば、都度の確認コストを削減できる。印刷物・バナー・SNS用画像など、比較的独立したアウトプットを一貫したビジュアルで量産する際にもスタイルガイドは有効だ。

一方でスタイルガイドが解決できない問題もある。インタラクティブな状態（ホバー・フォーカス・ディセーブル・エラー）の仕様、コンポーネント同士の組み合わせルール、デザインと実装の乖離の防止、新規メンバーが加わったときの判断の一貫性維持——これらはスタイルガイドの範囲を超えている。スタイルガイドは「見た目の基準」を提供するが、「作り方の基準」は提供しない。

デザインシステムとは、コンポーネント・トークン・原則・ガバナンスの4要素が統合された「製品」である。Figmaで管理されるデザインデータと実装コードが連動し、判断基準が文書化され、更新手順が定められている状態を指す。

コンポーネント

ボタン・フォーム・カード・モーダルといったUIの構成単位を、状態別・バリアント別に定義したものである。コンポーネントはデザインファイル上の共有ライブラリとして存在するだけでなく、ReactやVueなどのコードコンポーネントと対応している状態が望ましい。「デザインと実装が一致している」ことがコンポーネントの価値の核心だ。

コンポーネントが整備されていると、新しいページを作るときにゼロから設計するのではなく、既存のコンポーネントを組み合わせる作業になる。これは制作速度を上げるだけでなく、意図しないバリエーションの発生を防ぐ。

トークン

色・間隔・フォントサイズ・角丸・影などの値に名前をつけたものである。#1a73e8 という値を直接使うのではなく color-primary-500 という名前で参照することで、テーマ変更や値の一括更新が可能になる。

トークンはデザインと実装の「共通言語」として機能する。デザイナーがFigmaで spacing-4 を使い、エンジニアがCSSで --spacing-4: 16px; を参照していれば、デザインと実装の乖離が構造的に防がれる。トークンがなければ、ブランドカラーを変更するたびに全ファイルを手作業で修正することになる。

原則

「いつどのコンポーネントを使うか」「なぜこのデザイン判断をしたか」を記述したドキュメントである。例えば「プライマリボタンは1画面に1つまで」「エラーメッセージはフィールドの直下に表示する」といったルールが原則に当たる。

原則は、コンポーネントだけでは伝わらない「判断の根拠」を担う。新しいメンバーがデザインシステムを使い始めたとき、原則があれば「この状況では何を使うか」の判断が自己解決できる。逆に原則がなければ、判断のたびにベテランメンバーへの確認が必要になる。

ガバナンス

デザインシステムをどう管理・更新・進化させるかのルールである。具体的には、新しいコンポーネントを追加するときのプロセス、既存コンポーネントを変更するときの承認フロー、廃止予定コンポーネントの移行期間の設定などが含まれる。

ガバナンスはデザインシステムを「生きたシステム」として維持するための仕組みだ。コンポーネントライブラリを作っても更新プロセスが決まっていなければ、プロダクトの変化に追いつけなくなり、やがて誰も参照しない古いドキュメントになる。デザインシステムの長期的な価値はガバナンスの設計によってほぼ決まると言っていい。

デザインシステムの導入は規模だけで判断するものではない。「同じ判断を何度するか」が本質的な判断基準である。

デザインシステムが有効な状況

複数のプロダクトやページを横断して一貫性を維持する必要があるとき。コーポレートサイト・採用サイト・サービスサイトを別々のチームが制作していると、色や余白の微妙なズレが積み重なり、ブランドの統一感が損なわれる。デザインシステムがあれば「トークンを参照する」だけで一貫性が担保される。

機能追加・改修が継続的に発生するサービスやアプリの場合。新機能のデザインを毎回ゼロから考えていると、同じような機能でも画面ごとにUIが異なってしまう。コンポーネントを組み合わせることで、新機能の設計時間を短縮しつつ一貫性を保てる。

デザイナーとエンジニアが協働する開発チームの場合。デザインファイルの仕様と実装コードが乖離していると、ピクセル単位の確認作業が発生し続ける。コンポーネントとトークンを介した連携により、確認コストを構造的に削減できる。

スタイルガイドで十分な状況

単発の制作プロジェクトで、リニューアル後に更新頻度が低い場合。コーポレートサイトを制作して数年間ほぼ変更しないのであれば、スタイルガイドで色・フォントを定めておくだけでも実用上は問題ない。

制作チームが少人数（1〜2名）で、コンポーネントを共有する相手がいない場合。デザインシステムの真価はチーム間・プロダクト間での共有にある。共有相手がいなければ管理コストに見合わない。

ブランディング用途の静的アウトプット（パンフレット・バナー・印刷物）が中心の場合。インタラクション状態の定義が不要なケースでは、スタイルガイドで必要な情報は揃う。

判断の目安として、「デザインに関する同じ決定を月に3回以上している」と感じるなら、デザインシステムへの投資を検討するタイミングである。

デザインシステムは完璧な状態から始める必要はない。小さく始めて育てることが、長期的な定着につながる。

ステップ1：既存プロダクトの監査

まず、現在存在するデザインの実態を把握する作業から始める。既存のWebサイトやアプリのスクリーンショットを並べ、何種類のボタンが存在するか、何種類の青が使われているかを数える。この作業を「UIインベントリ」と呼ぶ。

インベントリを取ると、意図せず生まれたバリエーションの多さに気づく。3種類のプライマリカラーが存在する、フォントサイズが12種類使われている、ボタンの角丸が4px・6px・8pxと混在している——こうした実態が可視化されると、何を統一すべきかの優先度が自然と明確になる。

ステップ2：トークンの定義

監査結果をもとに、まずトークンを定めることを推奨する。コンポーネントより先にトークンを固めることで、コンポーネントの設計時に参照すべき値が確定する。

最初に定義すべきトークンは、カラー・間隔・フォントサイズの3領域である。カラーはプリミティブトークン（blue-500: #1a73e8）とセマンティックトークン（color-primary: blue-500）の2層構造にすると、テーマ変更への対応が容易になる。間隔は4pxや8pxを基準とした倍数系列（4・8・12・16・24・32・48・64）で定義するケースが多い。

ステップ3：コアコンポーネントの構築

トークンが定義できたら、使用頻度の高いコンポーネントから順に整備する。最初に着手すべきは、ほぼ全ページで使われるButton・Input・Typography・Spacingである。これら4つが揃うと、既存ページの多くがカバーできる。

コンポーネントを作る際は、バリアント（サイズ・カラー・状態）を網羅することが重要だ。ボタンであれば、サイズ（small/medium/large）、カラー（primary/secondary/ghost）、状態（default/hover/focus/disabled/loading）の組み合わせを最初から定義しておく。後から状態を追加するたびにデザインと実装を修正するコストが発生するためだ。

ステップ4：原則とガバナンスの文書化

コンポーネントとトークンが整ったら、それを「どう使うか」の原則と「どう更新するか」のガバナンスを文書化する。

原則の最低限の内容は、各コンポーネントの「使う状況と使わない状況」の記述である。ガバナンスの最低限の内容は、「新しいコンポーネントが必要になったとき誰がどのように決定するか」のフローである。最初は簡素でよい。ガバナンスは使いながら改善するものであり、最初から完璧を目指すと文書作成だけで疲弊する。

デザインシステム構築で最も陥りやすい失敗は、「完成してから使う」という発想だ。Figmaの共有ライブラリにコンポーネントを追加した時点から、次のプロジェクトで使い始めることが定着の近道である。使いながら不足を発見し、発見のたびに追加する——この反復がデザインシステムを実用的なものに育てる。

参考文献

Design Systems 101 (2021)

Atomic Design — Chapter 2: Atomic Design Methodology (2016)

Design Systems Handbook (2017)