Webサイトやアプリを複数人で開発していると、ボタンの色やフォントサイズがページごとにバラバラになってしまうことがあります。デザイナーが指定した青と、エンジニアが実装した青が微妙に違う、という状況も珍しくありません。こうした問題を根本から解消するための考え方が、デザイントークンです。
デザイントークンという言葉を聞いたことはあっても、具体的に何を指すのか、どう使えばよいのか、わからないまま放置している方もいるかもしれません。この記事では、デザイントークンの基本的な概念から、導入を判断するための軸、実際に整備する手順、注意点までを順を追って説明します。
デザイントークンとは何か、その目的と対象
デザイントークンとは、色・余白・フォントサイズ・角丸の大きさといった視覚的なデザイン値に名前をつけて管理する仕組みです。たとえば「#1A73E8」という色コードに color-brand-primary という名前をつけます。そのトークン名をデザインツールとコードの両方で参照します。
値ではなく名前を介してデザインを参照することで、後から色を変更する際に一箇所だけ修正すれば全体に反映できます。これが、デザイントークンの最大の目的です。
対象となる主な値は次のとおりです。
- カラー（ブランドカラー、テキストカラー、背景色など）
- タイポグラフィ（フォントサイズ、行の高さ、フォントウェイト）
- スペーシング（余白・パディング・マージンの基準値）
- 角丸（border-radius）やシャドウ
- アニメーションの速度や遅延時間
デザイントークンはデザインシステムの構成要素の一つです。デザインシステム全体を整備していなくても、トークンだけを先行して導入することは十分に可能です。
導入するかどうかを判断する基準
デザイントークンは便利な仕組みですが、すべてのプロジェクトに必要というわけではありません。いくつかの判断基準を確認することで、導入の優先度を見極めやすくなります。
チームの規模と分業体制が一つ目の軸です。デザイナーとエンジニアが分かれていて、デザインツールとコードの両方でデザイン値を管理している場合、トークンは特に効果を発揮します。一人がデザインも実装も担う小規模なプロジェクトであれば、CSSカスタムプロパティだけで十分なケースもあります。
更新頻度とブランドの変化可能性が二つ目の軸です。将来的にブランドリニューアルやテーマ変更が見込まれる場合、トークンで管理しておくと変更コストを抑えられます。一方、公開後にほとんど変更しないサイトであれば、急いで整備する必要は低いかもしれません。
複数プラットフォームへの展開が三つ目の軸です。Webサイトとモバイルアプリをまとめて開発している場合、同じトークンを各技術スタック向けに変換できます。一貫性を保ちやすくなる点が大きなメリットです。Webだけの単一プロジェクトではこの恩恵は限定的です。
以上の三軸で当てはまる条件が多いほど、デザイントークンの導入優先度は高まります。
デザイントークンを整備する手順と進め方
デザイントークンを整備する手順は、大きく四つのステップに分けられます。一気にすべてをトークン化しようとすると管理が破綻しやすいため、小さく始めて徐々に広げることを意識してください。
- 現状の棚卸し：既存のCSSやデザインファイルに散在している色・フォントサイズ・余白の値を書き出します。どの値が何種類あるかを把握することが出発点です。
- トークンの命名と設計：値に名前をつけます。命名は何であるかではなく何に使うかを意識すると管理しやすくなります。たとえば
color-blue-500よりもcolor-text-linkのほうが用途が明確です。プリミティブと意味的なトークンを二階層に分けて管理する設計も広く使われています。 - フォーマットの選定と出力：トークンはJSONやYAML形式で定義します。Style DictionaryなどのツールでCSS変数・Sass変数・iOS向けファイルに変換するのが一般的な方法です。Figmaを使っている場合はVariables機能やプラグインと連携できます。
- コードとデザインへの適用と運用ルール策定：CSSカスタムプロパティとして出力したトークンをコンポーネントに適用します。直接の値の記述を禁止するルールをチームで共有してください。デザインファイル側でも同名の変数を参照するよう設定します。
整備後は、新しい値が必要になるたびにトークンを定義してから実装するフローを習慣化することが重要です。この手順を守らないと、再び値の散在が起きやすくなります。
命名とスコープに関する注意点とリスク
デザイントークンを運用するうえで最も注意が必要なのは、命名の一貫性が崩れることです。チームメンバーがそれぞれ異なる命名規則でトークンを追加し続けると、管理が複雑になります。どのトークンが何を指すかわからなくなる前に、命名規則をドキュメント化しておいてください。
トークンを細かくしすぎるリスクもあります。すべての値を個別にトークン化しようとすると、トークン数が膨大になります。探すコストが上がるため、どこまでをトークンにするかのスコープをあらかじめ決めておくことが大切です。
デザインとコードの乖離も継続的なリスクです。Figmaのトークン名とコードのトークン名が一致していないと、変更が片方にしか反映されません。デザインツールとコードリポジトリの同期方法を、導入前に決めておく必要があります。
さらに、テーマ切り替え（ライトモードとダークモードなど）に対応する場合は設計がより複雑になります。意味的なトークン（color-bg-primaryなど）を用意して、モードごとに参照先の値を切り替える設計が必要です。最初から対応するか後から追加するかを、着手前に判断してください。
なお、デザイントークンの仕様を標準化しようとするW3C Design Tokens Community Groupの動きもあります。仕様は現在も検討中のため、ツール選定の際は各ツールの公式ドキュメントで対応状況を確認してください。
よくある疑問への客観的な回答
CSSカスタムプロパティとデザイントークンは別物ですか
CSSカスタムプロパティ（CSS変数）は、デザイントークンをWeb実装で表現する手段の一つです。デザイントークンはプラットフォームに依存しない概念です。JSONなどで定義したあと、CSSカスタムプロパティやSass変数、iOSの定数ファイルなど複数の形式に変換して使います。Webのみのプロジェクトであれば、CSSカスタムプロパティだけで運用することもできます。
小規模なサイトでも導入すべきですか
ページ数が少なく更新頻度も低いサイトであれば、トークン管理ツールを導入せずに対応できます。CSSカスタムプロパティをファイルの先頭にまとめるだけでも、同様の効果を得られます。重要なのはツールではなく、値に名前をつけて一箇所で管理するという考え方です。プロジェクトの規模に合わせた実装方法を選んでください。
デザイントークン導入前のチェックリスト
整備を始める前に、以下の項目を確認しておくと準備がスムーズです。Web制作で使われる用語全般を参照しながら、チーム内の認識を揃えておくことも助けになります。
- 現在のデザイン値（色・フォント・余白）が何種類あるか把握できているか
- デザインツールとコードのどちらを正とするか決まっているか
- 命名規則の方針（プリミティブ・意味的の二階層など）を合意しているか
- 出力形式（CSSカスタムプロパティ・Sass・iOSなど）が決まっているか
- ダークモードなどのテーマ切り替えへの対応を先に決めているか
- トークンを追加・変更するときの承認フローが決まっているか
- デザインファイルとコードの同期方法が具体的に決まっているか
デザイントークンは、一度整備すれば長期にわたってデザインの一貫性を保つ基盤になります。まずは色とフォントサイズだけをトークン化する小さなスタートでも、チーム全体の作業効率は改善されます。サイト制作の体制や設計方針を見直したい場合は、トークン整備と合わせて検討してみてください。
デザインと実装の橋渡しとなる仕組みに興味がある方は、Webマーケティング支援のページも参考にしてください。具体的な疑問がある場合はお問い合わせからご相談いただけます。
