スケールするデザイントークン: 崩れないデザインを支える基盤

デザイントークンという言葉は、いまでは広く使われている。だが、実際の運用に耐える設計になっている例は、思ったより少ない。多くのチームで見かけるのは、Figmaのカラースタイルに命名しただけの、事実上ただの一覧表だ。トークンが力を発揮するのは、それを「変更に耐える契約」として設計したときだけだ。

三層モデル: プリミティブ・セマンティック・コンポーネント

もっとも普及している構成は三層モデルだ。プリミティブ層は、原色や書体サイズなど、意味を持たない生の値。セマンティック層は、「本文の色」「危険を示す色」といった意味付きのトークン。コンポーネント層は、「ボタンの背景」「モーダルの枠線」といった、部品単位の紐付けだ。

変更は基本的にセマンティック層で行う。プリミティブを触るとサイト全体に飛び火する。コンポーネント層だけで直そうとすると、抜け漏れが出る。この中間層があるかどうかで、運用の負担は桁で変わる。

ダークテーマ対応で崩れるかどうかは、この中間層があるかで決まる。値ではなく意味を切り替えるからだ。

ツール依存を捨てる

Figma、Sketch、コード——どこか一つに閉じたトークン運用は、ツール切り替えの瞬間に破綻する。W3Cが進めているデザイントークン仕様草案は、この問題に対する業界的な回答だ。JSONベースの共通フォーマットを介して、複数のツール間で同期する。導入コストは決して小さくないが、長く運用する前提なら投資に見合う。

更新の作法

トークンの更新は、まず「何のためにこの色/余白/書体を使うか」の意味から議論する。「そろそろ緑を変えたい」から始めると、周辺との整合が破綻する。「エラー表示のトーンを、警告と分けて弱めたい」——このように意味から入ると、変更範囲が自然に絞られる。

コンポーネント設計との接続

トークンだけが整っていても、コンポーネントが自由に上書きしていれば意味がない。逆に、コンポーネントは整っていてもトークンが場当たりだと、テーマ切り替えができない。両方が揃わないと機能しない。コンポーネント側の運用はコンポーネントライブラリの現場運用を参照。トークンの変更をレビューで詰める段取りはデザインレビューを短く回すでも扱っている。

反論: 小規模チームには過剰

三層モデルとツール横断のフォーマットは、5人以下のチームには重い。この主張には根拠がある。ただし、「小規模のうちは軽く、拡大したら整える」が、実際にはほぼ機能しない。整えるタイミングが訪れる前に、場当たり運用が固まってしまう。小さいうちに、セマンティック層だけでも意識しておくのが現実解だと私たちは考える。

参照

• W3C Design Tokens Community Group. “Design Tokens Format Module (Editor’s Draft).” （2026-06時点の最新版）
• Curtis, Nathan. “Naming Tokens in Design Systems.” Medium, 2020.

デザイントークンは、目に見える成果を派手には作らない。だが、変更に耐える基盤があるかどうかは、5年目のプロダクトで残酷なほど見えてくる。設計としてのトークンは、その5年目のために持つ。