デザイントークン

英語名 Design Tokens
読み方 デザイン トークンズ
難易度
所要時間 数日〜数週間（初期構築）
提唱者 Salesforce（Lightning Design System）
#デザインシステム #実装連携 #一貫性
目次

ひとことで言うと
#

色、フォントサイズ、余白、角丸などのデザインの基本値を「トークン」という名前つき変数として一元管理する仕組み。デザインツールとコードの両方で同じトークンを参照することで、デザインと実装のズレをなくし、変更にも強くなる。

押さえておきたい用語
#

押さえておきたい用語
グローバルトークン（Primitive）
生の値を定義する最下層のトークン。blue-500: #3B82F6 のように色名＋段階で命名する。
セマンティックトークン（Semantic）
意味や用途で命名されたトークン。color-primary: blue-500 のようにグローバルトークンを参照する。
コンポーネントトークン
特定UIコンポーネント専用のトークン。button-background: color-primary のようにセマンティックトークンを参照する。
Single Source of Truth（SSOT）
トークンの定義元を1つに絞ること。JSONで管理し、Figma・CSS・iOS・Androidに変換するのが理想。
Style Dictionary
Amazonが開発したトークン変換ツール。1つのJSON定義から複数プラットフォーム向けの出力を自動生成する。

デザイントークンの全体像
#

グローバル→セマンティック→コンポーネントの3層構造でトークンを管理する
グローバル生の値を定義blue-500: #3B82F6色・サイズ・余白直接参照しない›セマンティック意味で命名color-primary: blue-500テーマ切替の切り替え対象›コンポーネント特定UIの値btn-bg: color-primaryコードで実際に参照する値トークンのソースは1つ（Single Source of Truth）
デザイントークン導入の進め方フロー
1
対象の洗い出し
繰り返し使われる色・サイズ・余白を特定
→
2
3層設計
グローバル→セマンティック→コンポーネントで整理
→
3
実装・同期
Figmaとコードの両方でトークンを参照
→
4
運用ルール策定
追加・変更・廃止のプロセスを定める

こんな悩みに効く
#

  • デザインで指定した色と実装の色が微妙にずれている
  • ブランドカラーを変更するたびに、全画面を手作業で直している
  • Web・iOS・Androidでデザインがバラバラになる

基本の使い方
#

ステップ1: トークン化する対象を決める

デザインの中で繰り返し使われる基本値を洗い出す。

  • 色: プライマリ、セカンダリ、背景、テキスト、エラーなど
  • タイポグラフィ: フォントファミリー、サイズ、行間、太さ
  • スペーシング: 余白（4px, 8px, 16px…）
  • その他: 角丸、シャドウ、ボーダー、アニメーション

ポイント: まず使用頻度が高いものからトークン化する。いきなり全部やろうとしない。

ステップ2: トークンの階層を設計する

トークンを3層構造で整理するのが一般的。

  • グローバルトークン（Primitive）: 生の値。blue-500: #3B82F6 のように色名＋段階で定義
  • セマンティックトークン（Semantic）: 意味で定義。color-primary: blue-500、color-error: red-500
  • コンポーネントトークン: 特定UIの値。button-background: color-primary

ポイント: コードで直接使うのはセマンティックトークン以上。グローバルトークンは直接参照しない。

ステップ3: トークンをツールとコードに実装する

デザインツールと開発環境の両方でトークンを参照できるようにする。

  • Figmaのローカル変数やスタイルとしてトークンを登録
  • コードではCSS変数、Sass変数、JSON形式で管理
  • Style DictionaryやTokens Studioなどのツールで変換・同期する

ポイント: トークンのソースは1つ（Single Source of Truth）にする。JSONで管理し、そこからFigma・CSS・iOS・Androidに変換するのが理想。

ステップ4: 運用ルールを決める

トークンの追加・変更・廃止のプロセスを定める。

  • 新しいトークンを追加する際のレビュープロセス
  • 既存トークンを変更する際の影響範囲の確認方法
  • 非推奨トークンの移行期間とマイグレーションガイド
  • バージョニングの方針

ポイント: トークンの数が無制限に増えないよう、追加には承認プロセスを設ける。

具体例
#

例1：100画面のWebアプリにダークモードをトークンだけで実現する

課題: 100画面以上のWebアプリにダークモードを追加したいが、色がハードコードされていて影響範囲が膨大。

トークン設計:

/* グローバルトークン */
--gray-100: #F3F4F6;
--gray-900: #111827;

/* セマンティックトークン（ライトモード） */
--color-bg-primary: var(--gray-100);
--color-text-primary: var(--gray-900);

/* セマンティックトークン（ダークモード） */
[data-theme="dark"] {
  --color-bg-primary: var(--gray-900);
  --color-text-primary: var(--gray-100);
}

結果: セマンティックトークンの値を切り替えるだけで、100画面すべてが自動的にダークモードに対応。個別の画面修正はゼロ。以降のカラー変更も、トークンの値を1箇所変えるだけで全画面に反映されるようになった。

例2：3プラットフォーム間のデザイン差異を4人チームがトークンで解消する

課題: Web・iOS・Androidでボタンの角丸やフォントサイズが微妙にずれている。デザイナー1名がFigmaで修正しても、エンジニア3名がそれぞれ手動で実装するため、ズレが繰り返し発生。

対応: JSON形式でトークンを定義し、Style Dictionaryで各プラットフォーム向けに自動変換する体制を構築。

{
  "border-radius-button": { "value": "8px" },
  "font-size-body": { "value": "16px" }
}

→ CSS変数、Swift定数、Kotlin定数に自動変換

結果: デザイン修正の反映時間が平均3日から0.5日に短縮。プラットフォーム間の差異報告が月12件からゼロになった。

例3：SaaS企業がリブランディングでカラー変更を1日で全サービスに反映する

課題: ブランドカラーを青系から緑系に変更。対象はWebアプリ、マーケティングサイト、社内ツールの計3プロダクト・200画面以上。従来なら3ヶ月かかる見積もり。

対応: 事前にセマンティックトークンで全プロダクトを統一管理していたため、グローバルトークンの色定義を差し替えるだけで対応。

  • --brand-primary: #2563EB（青）→ --brand-primary: #16A34A（緑）
  • 関連するホバー色・アクティブ色もグローバルトークン側で一括更新

結果: 200画面以上のカラー変更が1日で完了。手作業の修正箇所はゼロ。「3ヶ月の見積もりが1日」という事実が、トークン管理への社内投資の説得材料になった。

やりがちな失敗パターン
#

  1. トークンの粒度が細かすぎる — ボタンの状態ごと、画面ごとにトークンを作ると管理不能になる。セマンティックレベルで共通化できるものは共通化する
  2. 名前の付け方に一貫性がない — primary-btn-bg、buttonBackgroundPrimary、btn_primary_color が混在すると混乱する。命名規則を最初に決めて厳守する
  3. デザインツールとコードが別管理になる — Figmaのスタイルとコードの変数が同期されていないと、結局ズレが生じる。自動同期の仕組みを構築する
  4. 最初から完璧なトークン体系を目指す — 全プロパティをトークン化してから始めようとすると、いつまでも導入できない。色とタイポグラフィから始めて段階的に拡張するのが現実的

まとめ
#

デザイントークンは、デザインの基本値を名前つき変数として一元管理する仕組み。グローバル→セマンティック→コンポーネントの3層構造で設計し、デザインツールとコードの両方から同じトークンを参照する。テーマ切り替えやブランド変更にも強く、デザインシステムの基盤となる重要な仕組み。

↑ 目次に戻る