Design System

デザインシステムとは何か、「コンポーネントライブラリ」と同じものなのか。

デザインシステムとコンポーネントライブラリは頻繁に混同されるが、範囲が異なる。コンポーネントライブラリは再利用可能なコードブロック（ボタン、入力欄、カード）の集合であり、「何が使えるか」を教えてくれる。デザインシステムはより完全なもので、コンポーネント自体に加えて、使用ルールと理由も含む——どんな場面でボタンを使い、どんな場面でリンクを使うべきか、カラーシステムの背後にある意味は何か、アクセシビリティ基準をどう適用するか。これは「いつ、なぜそう設計されたか」に答えるものであり、単に「どんな部品があるか」ではない。

例えるなら、コンポーネントライブラリは窓、ドア、タイルが詰まった建材カタログのようなもの。デザインシステムはそのカタログに加えて「この家の建築基準」も一緒に渡してくれる——どんな材料があるかだけでなく、それらをどう組み合わせれば同じスタイル、同じ基準になるかも教えてくれる。

デザインシステムはなぜわざわざ構築されるのか、何を解決しているのか。

プロダクトの規模が大きくなると、同じチーム内でも人によって描くボタンの色や余白が徐々にずれていくことがよくある——意図的ではなく、それぞれが個別に判断を重ねた結果、時間が経つと「同じプロダクト内に5種類の青がある」といった状況が蓄積される。デザインシステムが解決する核心的な問題は、デザインと開発の両方が参照できる単一の情報源を持つことで、「この色は結局どの青なのか」といった繰り返しのコミュニケーションを減らし、チームが拡大するにつれてインターフェースのスタイルが徐々に制御不能になるリスクを下げることにある。

開発側にとってのもう一つのメリットは、理論上「ほぼロスのない受け渡し」を実現できる点だ——デザインファイルで使われているコンポーネントとエンジニアが実際にコードで持っているコンポーネントが同じものであれば、引き渡し時に仕様を再推測する必要がなく、デザインが更新された際もコードを同期して更新でき、両者が別々のバージョンを維持してずれていくことを防げる。

デザインシステムは実際どんな要素で構成され、どう機能するのか。

完全なデザインシステムには通常いくつかの階層がある。

1. デザイントークン：最も基本的な原子単位で、色、フォントサイズ、余白などの具体的な数値。この数値はデザインツールとコードの両方に存在し、双方が同じ数値セットを参照する。
2. コンポーネントライブラリ：デザイントークンを組み合わせた再利用可能なインターフェース要素——ボタン、入力欄、カードなど。
3. 使用ガイドライン／ドキュメント：各コンポーネントをいつ使うべきか、いつ使うべきでないかを説明する——ボタンとリンクの使い分け、アクセシビリティ基準の適用方法など。
4. ガバナンスプロセス：誰がコンポーネントの追加や変更権限を持つか、変更はどう審査されるか、バージョンはどう管理されるか——この層がデザインシステムが時間とともに技術的負債を蓄積するかどうかを左右する。

ShopifyのPolarisはよく引用される実例だ。当初はコンポーネントライブラリとして始まり、その後デザイナーと開発者の両方に対応する完全なパターン・デザインシステムへと拡張され、バージョン管理により複数のプロダクト間で一貫性がありながら拡張可能な体験を維持できるようになっている。

Claudeや他のAIツールでデザイン案を生成する場合、デザインシステムはあなたに実際どう関係するのか。

チームが既にデザインシステムを持っている場合、AI生成インターフェースの最も価値ある使い方は、既存のデザイントークンとコンポーネントルールを読み取らせることであり、毎回ゼロから新しいビジュアルスタイルを生成させることではない——そうすることで、既存プロダクトと一貫性のある出力になり、本体のプロダクトと噛み合わない孤立したスタイルの島にならずに済む。チームがまだデザインシステムを持っていない場合、AIで複数の方向性を素早く生成する際は、各方向がそれぞれ独自の色や余白の慣習を積み上げてしまわないよう注意が必要だ。そうでなければ、システムが確立する前にさらに多くの不整合を生み出すことになる。

実務上のより現実的な順序は、まずAIツールに参照させられる既存のデザインシステムがあるか確認することだ。なければ、小規模な探索でまず基礎トークン（色、フォントサイズ、余白）を確定させ、その基盤の上でAIに拡張生成させる——毎回の生成がそれぞれ新しいビジュアル言語を発明するのではなく。