デザインシステム入門｜ブランドカラーの変更で3箇所直し忘れる、をコード1行で終わらせる

定義と、実際にコードで一括変更してみる

デザインシステムの本質は「部品集」ではなく「一貫性を保つ仕組み」。実際にトークンで色を変更すると、その効果が数字で見える。

デザインシステムの定義は、Figmaが公開しているものが分かりやすいです。“a set of building blocks and standards that help keep the look and feel … consistent”。製品や体験の見た目と使用感を一貫させる、部品と規約のセットです。

実際に動かして確かめる

以下は編集部が実際にNode.jsで実行したコードです。ブランドカラーを直書きした場合と、デザイントークン（変数）を使った場合で、色変更の作業がどう変わるかを比較します。

// ❌ ハードコード: 各コンポーネントが色を直接指定
const buttonStyleHardcoded = { background: "#3B82F6", color: "#FFFFFF" };
const linkStyleHardcoded = { color: "#3B82F6" };
const badgeStyleHardcoded = { background: "#3B82F6", color: "#FFFFFF" };

// ✅ トークン方式: 1つの変数を全コンポーネントが参照する
const tokens = { colorPrimary: "#3B82F6", colorOnPrimary: "#FFFFFF" };
function getButtonStyle() {
  return { background: tokens.colorPrimary, color: tokens.colorOnPrimary };
}
function getLinkStyle() {
  return { color: tokens.colorPrimary };
}

=== トークン方式: tokens.colorPrimary を1箇所変更 ===
変更後の button: { background: '#7C3AED', color: '#FFFFFF' }
変更後の link: { color: '#7C3AED' }
変更後の badge: { background: '#7C3AED', color: '#FFFFFF' }

→ 1行の変更が3つのコンポーネント全てに反映された

ハードコード方式では3箇所を手動で書き換える必要があり、1箇所でも直し忘れれば色の不整合が生まれます。トークン方式はtokens.colorPrimaryを1行変えるだけで、参照している全コンポーネントに反映されました。

この差が意味すること

コンポーネントが3つなら手作業でも耐えられますが、数十のボタン・カード・バッジがある実際のアプリでは、直書き方式は必ずどこかで整合性を崩します。トークンは「変更を1箇所に閉じ込める」ための最小の仕組みです。

個人開発は「3トークン」から始める

色・余白・文字サイズの3種類だけをトークン化すれば、UIの一貫性は大きく改善する。コンポーネント集の整備は後回しでよい。

デザインシステムという言葉の重さに反して、個人開発が最初にやることはシンプルです。色・余白・文字サイズの3種類を変数にするだけで、効果の大半を得られます。

最小構成の3トークン

実装はCSS変数でも十分

:root {
  --color-primary: #3B82F6;
  --color-on-primary: #FFFFFF;
  --space-sm: 8px;
  --space-md: 16px;
  --font-body: 16px;
  --font-heading: 24px;
}

作り込みすぎが最大の失敗——後追い型で拾う

最初から完璧なコンポーネント集を目指すと、本来の開発が止まる。画面を作りながら繰り返し出てきた部分だけをトークン・部品に昇格させる。

デザインシステムの失敗で最も多いのは、技術的な難しさではなく作り込みすぎです。最初から数十種類のコンポーネントとルールを整備しようとして、肝心のプロダクト開発が止まります。

後追い型という現実的なやり方

個人開発に向くのは、画面を作りながら繰り返し使うパターンが見えたら、そこで初めてトークンや共通部品に昇格させるやり方です。3回目に同じボタンのスタイルを書いたら共通化する、という程度の緩さで十分機能します。ボタンの状態表示（処理中・成功・失敗）を統一する話はUI/UXデザイン入門の記事とも重なります。

チームが増えたら投資を上げる