「このページのボタンは青、あのページのボタンは少し違う青、別のページのボタンは角丸が違う」——画面ごとに微妙に異なるUIは、ユーザーに「このサービスは作りが雑だ」という印象を与えます。さらに、修正が必要になったとき、すべての画面を個別に直す必要が生じます。
よくある失敗パターンは「毎回ゼロから作る」ことです。新しい画面を作るたびに、ボタンのスタイルを一から定義する。フォームのレイアウトを毎回考える。色をその場で決める——これらは「早く作れる」ように見えて、実際には同じ判断を何度も繰り返し、一貫性のないUIを生み出します。
「なんとなく作った」UIは、プロダクトがスケールするにつれて崩壊します。画面数が増えるほど、一貫性の維持コストは指数的に増大します。デザインシステム思考——コンポーネントとトークンでUIをルール化し、再利用可能な設計資産を作ること——が、長期的な品質と開発速度を両立させます。
1. 原則の定義
ルール化して再利用する（Design System Thinking）とは、色・余白・フォント・コンポーネントをデザイントークンとコンポーネントライブラリとして定義し、すべての画面でこれらの設計資産を再利用することで、UIの一貫性を保ちながら開発速度を高める原則。
本質は「UIは設計資産の組み合わせである」ということです。すべての画面をゼロから作るのではなく、定義済みのコンポーネント（ボタン・カード・フォーム）とトークン（色・余白・フォント）を組み合わせて画面を構築します。新しいコンポーネントが必要になったときは、既存のルールに従って作り、システムに追加します。
2. いつ使うか（適用場面）
特に重要になるケース
- 複数の画面・機能を持つプロダクト: 画面数が5を超えたら、コンポーネントとトークンの定義を始める。早ければ早いほど、後からの修正コストが下がる。
- チームで開発する場合: デザイナーとエンジニアが同じコンポーネント名・トークン名を使うことで、コミュニケーションコストが下がる。
- 長期運用するプロダクト: ブランドカラーの変更・ダークモード対応・アクセシビリティ改善——これらをトークンで管理していれば、一箇所の変更が全体に反映される。
- デザインの一貫性が重要な場面: エンタープライズ向けSaaS・金融・医療など、信頼性が重要なプロダクトでは、UIの一貫性がブランド信頼に直結する。
トレードオフが起きる場面
- 初期コストの増大: コンポーネントとトークンを定義する初期コストは高い。MVP・プロトタイプ段階では、最小限のルール化に留める。
- 柔軟性の制約: コンポーネント化を徹底すると、「この画面だけ特別なデザインにしたい」という要求に応えにくくなる。「例外」を作るコストと、一貫性のメリットを比較する。
3. なぜ重要か（設計判断の核）
UIは「毎回ゼロから作るもの」ではなく、「設計資産を組み合わせて作るもの」だ。ルール化された設計資産は、チームの生産性を何倍にも高める。
設計判断の基準
- 「この設計判断は、他の画面でも使えるか？」→ 使えるなら、コンポーネント・トークンとして定義する。
- 「このコンポーネントを修正したとき、すべての画面に自動的に反映されるか？」→ 反映されないなら、コンポーネント化が不完全。
優先順位の考え方
- 1. デザイントークン（最優先）: 色・余白・フォントサイズをトークンで定義する。これだけで、ダークモード対応・ブランド変更が容易になる。
- 2. 基本コンポーネント: ボタン・入力欄・カード・モーダルなど、頻繁に使うコンポーネントを定義する。
- 3. パターン・テンプレート: 複数のコンポーネントを組み合わせた「フォームパターン」「リストパターン」などを定義する。
例外条件
- ワンオフのキャンペーンページ・ランディングページなど、再利用を前提としない単発のUIでは、デザインシステムへの準拠を緩めることができる。ただし、ブランドカラー・フォントは必ずトークンを使う。
4. 具体の設計ルール（チェックリスト）
最低ライン（Must - これ守らないと危険）
これがないと、UIの一貫性が保てず、修正コストが膨大になります。
理想ライン（Better - できると強い/プロの品質）
「一貫性がある」を超えて「変更に強い設計資産」の状態です。
5. UI例
同じ「ボタンコンポーネント」でも、デザインシステム思考の有無で一貫性と修正コストは大きく変わります。
改善プロセス
- 色をトークンに置き換える:
#3B82F6→color-primaryのように、すべての色をトークン名で参照する。テーマ変更時にトークンの値を変えるだけで、全体に反映される。 - コンポーネントを統一する: 各画面で個別定義されているボタンを、一つの
Buttonコンポーネントに統一する。バリアント（variant="primary"・variant="danger"）でスタイルを切り替える。 - ドキュメントを整備する: 「このコンポーネントはいつ使うか」「使ってはいけないケース」をドキュメント化し、チーム全員が同じルールで使えるようにする。
6. 関連リンク
- 関連リファレンス（理論）: 認知負荷 (Cognitive Load), ヤコブの法則 (Jakob's Law), テスラーの法則 (Tesler's Law)
- 用語集（定義）: デザインシステム
- 関連するUI原則（横）: デザインと実装が壊れない設計 (Design & Implementation Durability), コンポーネントの視覚一貫性 (Component Consistency), 多言語/i18n 前提のUI (Internationalization UI)
7. まとめ
今日から直せる一手
担当しているプロダクトのボタンコンポーネントを確認してください。画面ごとに微妙に違う色・サイズ・角丸があれば、今日中に一つのButtonコンポーネントに統一してください。
チームに共有するなら一言 「UIは毎回ゼロから作るものではない。ルール化された設計資産を組み合わせて作るものだ。」
