ダークモード対応について
お問い合わせ

デザインと開発をつなぐ共通言語 - デザイントークンのすすめ

X-tech推進本部 齋藤

なぜデザインと開発はズレるのか

デザイナーがFigmaで丁寧に作ったデータを、エンジニアが実装する。 ごく日常的なプロセスですが、その中には見えにくい摩擦が潜んでいます。

「この青、デザインと微妙に違う」 「この余白って何px？」

ひとつひとつは些細に見えますが、積み重なると無視できないコミュニケーションコストになります。 それだけではなく、デザインの一貫性が担保できず、最終的な成果物の品質に影響します。

デザイントークンという共通言語

こうしたすれ違いの根本は、デザインと開発の間に共通の参照先がないことです。 この問題に対するひとつの答えが、デザイントークンという考え方です。

色・タイポグラフィ・余白・角丸といった、デザイン上の意思決定を名前付きの変数として一元管理します。
#2B7FFF という値を直接使うのではなく、color.brand.primary という名前で参照する。
名前が「値」ではなく「役割」を表すことで、UIのどの文脈で使われる色なのかが伝わります。

それがデザインと開発の共通言語になります。
デザイナーはFigmaの変数として、エンジニアはCSS Custom Propertiesとして、この同じ名前を参照する。
デザイントークンを整備することで、認識のズレが生まれにくくなります。

この考え方の共通仕様化を進めているのが W3CのDesign Tokens Community Group（DTCG） で、2025年10月にはトークンフォーマットの仕様も公開されています。

主要ツールの中には、このフォーマットへの対応を進めていたり前向きな関心を示すものが出てきており、特定ツールに依存しない共通フォーマットとして徐々に浸透しつつあります。

Tailwind CSSのthemeを参考にする

とはいえ、仕様に沿ってゼロからトークンを設計しようとすると、定義すべき項目は膨大です。
色のスケール、タイポグラフィのバリエーション、余白の体系...。
気がつくとトークン設計自体がひとつのプロジェクトになってしまいます。

そこで役立つのが Tailwind CSS の theme を参照する方法です。

Tailwind CSS のデフォルト theme には、色のスケール、余白の単位、フォントサイズなど、実践的に整理されたデザイン判断が揃っています。
これをそのまま全部採用するのではなく「自分たちのプロジェクトに必要なものはどれか」を考えながらピックアップして使うのがポイントです。
例えばブランドカラーとして使う数色、スペーシングの基準となる単位、見出しと本文のフォントサイズ。
まずそれだけを選んで定義するところから始めれば十分です。

Style Dictionary などのツールを使えば、JSONで定義したトークンからCSS Custom Propertiesを生成し、FigmaのVariables（変数機能）と対応させることもできます。

// color.json
{
  "color": {
    "blue": {
      "$type": "color",
      "300": { "$value": "#8ec5ff" },
      "500": { "$value": "#2b7fff" },
      "700": { "$value": "#1447e6" },
    },
    "rose": {
      "$type": "color",
      "300": { "$value": "#ffa1ad" },
      "500": { "$value": "#ff2056" },
      "700": { "$value": "#c70036" },
    },
  }
}
:root {
  --color-brand-primary: var(--color-blue-700);
}

...

button {
  background-color: var(--color-brand-primary);
}

Figmaで color/brand/primary という変数を定義し、コードでは --color-brand-primary として参照します。
同じ構造、同じ命名。これがデザインとコードをつなぐ橋になります。

最初から完璧なトークン体系を用意する必要はありません。まずブランドカラーと基本的なスペーシングだけで十分です。
Tailwind CSSの既存themeを参考にしながら、プロジェクトに合わせて少しずつ育てていけます。

Figma MCPでAIにも通じる

トークンを整備することのもうひとつの効果があります。AIとの連携です。

Figma MCPは、AIアシスタントがFigmaのデザインデータを直接参照できるようにする仕組みです。
これを使うと、AIに「このコンポーネントをコードで実装して」と指示する時、Figmaのデータを文脈として渡せます。

ここでトークンが整備されているかどうかが、大きな差になります。

トークンがない状態では、AIはデザインの意図を読み取る語彙を持ちません。
生成されるコードに color: #3B82F6 のようなベタ打ちの値が入りやすいのは、AIがその値の意味を判断する手がかりがないからです。

一方、トークンが整備されていれば、AIは color.brand.primary という名前からデザイン上の役割を理解し、システム全体と整合した判断を自律的に行えるようになります。
細かく指示しなくても、デザインの意図をAI自身が正しく解釈して動ける状態に近づきます。

ゴールはAIへの指示精度を上げることではなく、AIがデザインとコードの意図を正しく理解し、自律的に駆動できる環境を作ることです。
Figma MCPはその入り口であり、トークンはAIが判断するための語彙になります。

さらに今後の可能性として期待されているのが、コードからデザインへの逆方向です。
コードやトークンの変更を起点に、FigmaのデザインをAIが更新するワークフロー。
AIが両方向を橋渡しし、設計と実装が自律的なループで連携できる未来が、少しずつ近づいています。

育てながら使う

デザイントークンは完成させるものではなく、育てていくものです。

Tailwind CSSのthemeを参考にすることで、ゼロから設計するコストを大幅に下げられます。
そこにFigmaのVariablesを対応させ、チーム内で命名の規則を揃えていく。
それだけで、デザインと開発の会話はかなりスムーズになります。

そして整備されたトークンは、AIが自律的に正しく動くための語彙でもあります。
Figma MCPを通じてAIが設計の意図を読み取り、トークンに基づいてコードを判断し、必要とあればFigmaにも反映する。
そんなワークフローが現実に近づいた時、デザインと開発の連携はまったく新しいかたちになるでしょう。

デザイナーと開発者の共通言語を整備することは、同時にAIをそのループの一員として迎え入れるための準備でもあります。

2026年の記事一覧に戻る