《綿貫佳祐のFigma思考ラボ｜Vol.4》バリアブルで何を「定義」すべきか？ 〜デザイントークンの粒度と規律を考える〜（前編）

Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はどう活用しているのだろう」と感じている方も多いのではないでしょうか。

本連載では、Figmaの使い方や、Figmaを軸にしたワークフローを紹介します。ただし、単なる機能解説ではありません。各機能をどう捉え、どんな思考で使いこなしていくのか–––––その“思考”に焦点を当ててお届けします。ときには1人のUIデザイナーとして、ときにはチームの一員として、私がどのようにFigmaと向き合っているのかを共有していきます。

第4回は、「バリアブル（Variables）」にフォーカスして深掘りしてみましょう。

はじめに：バリアブルをめぐる温度差

前回の記事ではコンポーネントの設計思考について掘り下げました。その中でバリアブル機能に少し触れましたが、今回はこのバリアブルを主役に据えて、デザイントークンという考え方と合わせて深掘りしていきます。

オートレイアウト・コンポーネントと同様に、バリアブルに対する温度感も人によってかなり異なります。きちんとバリアブルを定義して運用しているチームもあれば、色やサイズはその都度感覚で選んでいるという方もいます。

大まかに整理すると、以下のような違いがありそうです。

	バリアブルをしっかり設定する派	都度判断する派
色・余白・サイズの選び方	定義済みの値から適切なものを選ぶ	既存のものを使うか、新たに設定する場合は感覚で選ぶ
一貫性	データとしての一貫性	見た目としての一貫性
値に対する名前	毎回つける、同じ値であっても意味が違えば違う名前をつける	「明るい黄色」「小さめの文字」などの主観的な名前で呼ぶ

どちらの立場にも、それぞれの経験や制作スタイルに基づいた合理性があると思います。ただ、この温度差がなぜ生まれるのか、そしてどのような場面でバリアブルが力を発揮するのかを考えてみると、見えてくるものがあります。

デザイントークンという考え方

バリアブルの話に入る前に、その背景にある「デザイントークン」という概念を整理しておきます。デザイントークンとは、色、余白、フォントサイズといったデザイン上の意思決定を「名前と値のペア」として定義・管理する仕組みです。

例えば、プロダクト全体で使うプライマリカラーを#55C500という値で直接指定するのではなく、color-brandという名前で定義し、その名前を通じて参照するという考え方です。

「Adobe Spectrum」のデザイントークンに関する資料がとてもわかりやすいので、概念を掴みたい方はぜひ参照してみてください。

Figmaのバリアブルは、このデザイントークンの考え方をFigma上で実現するための仕組みです。バリアブルに値を登録し、それをデザインデータの各要素に紐づけることで、見た目とデータを一貫して管理できるようになります。

この連載ではこれまで、オートレイアウト（構造を作る仕組み）、コンポーネント（部品を管理する仕組み）を取り上げてきました。バリアブルはこれらに続くものとして、「デザイン上の共通言語を定義する仕組み」という位置づけで捉えると良いと思います。

どの粒度まで設定すべきか？

従来のトークン階層

デザイントークンの設計には、一般的に知られた階層構造があります。

1. グローバルトークン（プリミティブトークン）: 色のパレットやサイズの基本値など、最も基礎的な値の定義
   • blue-500text-lgspace-4のように、値そのものに近い名前を付ける
     
2. エイリアストークン（セマンティックトークン）: グローバルトークンに意味を持たせた名前を付けたもの
   • color-primarytext-headingspace-mdのように、用途や意味を名前で表現する
     
3. コンポーネントスペシフィックトークン: 特定のコンポーネントに紐づく値の定義
   • button-paddingcard-border-radiusのように、コンポーネント名を含む

以前、デザイントークンの粒度についてQiita記事で言及したことがあるので、より詳しく知りたい方はこちらも参考にしてください。

●どこまで作り込む？事業や会社の規模にあわせたデザインシステムの考え方（綿貫佳祐）
https://qiita.com/kskwtnk/items/d0aabd33a8cf8ca109c4

この3層構造は、プロダクトの規模が大きくなるほど、その価値を発揮します。

グローバルトークンで基本の色やサイズを定義し、エイリアストークンで「この色はこういう意味」と紐づけ、必要に応じてコンポーネント固有のトークンで補完するといった具合に、段階的に意味を積み上げていく設計です。

AI時代に求められるトークンの粒度

ここで、AI活用の観点からトークン設計を考えてみます。AIを前提にすると、セマンティックなトークン名がAIにデザインの意図を伝えるという点が重要になります。

例えば、color-red-500というプリミティブな名前だと、AIにとっては「赤い色」という情報しかありません。そうすると「エラー表示を作って」と指示したときに、red-500を使うこともあればred-600を使うこともあります。つまり、周辺のコードなどに影響されて、出力が定まらないのです。

一方、color-errorというセマンティックな名前であれば、AIは「これはエラー時に使う色だ」と意図を理解できます。「同じ指示をすれば同じコードが生成される」というのが大事なポイントです。

では、デザイナーがFigma上で設定したバリアブルが、コード上ではどのような形になるかを見てみましょう。 以下はTailwind CSS v4での例です。

@theme inline {
  --color-primary: var(--color-sky-500);
  --color-primary-hover: var(--color-sky-600);
  --color-success: var(--color-emerald-500);
  --color-error: var(--color-red-500);
  --color-warning: var(--color-amber-500);
}

Figmaのバリアブルでcolor-primaryを定義し、その値としてsky-500に相当する色を設定しているのと、構造としてはまったく同じです。デザイナーがFigma上で登録したバリアブルは、このようにコードに変換されて実装で使われています。

セマンティックなトークンにしておくと、AIだけでなく人間にとっても意図が明確になります。前後の文脈なしにbg-red-500が使われていると意図を読み解くのが難しいですが、bg-errorと書かれていれば「エラー時の背景色」だとすぐにわかります。

グローバルトークンから始めるか、エイリアストークンから始めるか

従来のアプローチでは「まずグローバルトークンを網羅的に定義し、必要に応じてエイリアストークンを作る」というボトムアップの進め方が多かったと思います。

しかし、AIとの協働を前提にする場合、最初からエイリアストークンもセットで定義してしまうほうがスムーズかもしれません。なぜなら、グローバルトークンだけが大量にある状態では、AIにとっても人間にとっても「どの値をどの場面で使うべきか」の判断材料が足りないからです。

もちろん、これは新規プロダクトの場合の話です。既存プロダクトであれば、現在の値を整理しながら段階的にエイリアス化していくほうが現実的でしょう。

大事なのは「とりあえずグローバルトークンだけ定義して終わり」にしないことです。AI前提の時代では、最低限でもエイリアストークンまで定義することで、共通言語としての価値が高まります。

「バリアブルに設定した値だけを使う」という規律

例外が多いのはトークン設計の問題

複数人でプロダクトを作る場合、原則としてバリアブルに設定した値以外は使わないという規律が重要です。「この場面だけ特別に」「微調整したいから」と例外を許容し始めると、バリアブルで管理されている値とそうでない値が混在し、一貫性が徐々に崩れていきます。

ただここで大切なのは、例外が多く発生している場合、それはメンバーの規律の問題もそうですが、トークン設計の問題である可能性が高いということです。「必要な値がトークンとして定義されていない」「粒度が合っていないからやむを得ず例外的な値を使っている」といったケースは少なくありません。

例外が出てきたら、それをきっかけにトークン体系を見直す姿勢が大切です。

コンポーネントの中にマジックナンバーを残さない

この規律は、特にコンポーネントにおいて重要度が増します。

コンポーネントはライブラリとしてチーム全体に公開されるものです。その内部に#4097DBや16pxといった値が直接指定されていると、影響範囲がとても大きくなります。

プライマリカラーを変更したいとき、バリアブルで管理されていれば1カ所の変更で済みますが、値が直接指定されているコンポーネントが10個あれば、10箇所を手動で探して修正する必要が出てきます。

逆に言えば、コンポーネント内の値をバリアブル経由にしておくことで、トークン体系の変更がライブラリ全体に自然と波及するようになります。

前回の記事で「コンポーネントはコードのコンポーネントと構造を揃える」という話をしましたが、コードの世界でもコンポーネント内にマジックナンバーを書くのは避けるべきとされています。デザインデータでも同じ考え方を持っておくと、デザインと実装の一貫性が保たれます。

言語化できていないデザイン判断のリスク

トークンで表現しきれない部分というのは、言い換えれば、個人の感覚に依存している部分です。つまり、チーム内で言語化されていない暗黙知があるということです。

今のチームメンバーの間では、暗黙の了解として成り立っているかもしれません。しかし、メンバーが異動や退職になった後はどうでしょうか。新しいメンバーが同じデザイン判断を再現できる保証はありません。

いわゆる「職人芸」を良しとしない、という考え方です。個人の優れたスキルや感覚は素晴らしいものですが、それがチームの持続性に依存するのはリスクです。できる限り、デザイン上の意図をトークンという形で明文化しておくことが、チームとしての一貫性と持続性を支える基盤になります。

トークンは「共通言語」になる

バリアブルに名前を付けて管理するということは、デザイン上の意図に言葉を与えるということです。

名前が付いていれば、議論の精度が上がります。「この余白、もう少し広くして」という曖昧な指示が「spacing-mdをspacing-lgに変更して」という具体的な会話になります。デザイナー同士、デザイナーとエンジニア、さらにはAIとの間でも、同じ名前で同じ値を指し示せます。これが共通言語としてのトークンの力です。

デザインレビューやコードレビューの場面でも、トークン名が共有されていれば「ここで使うべきはcolor-primaryじゃなくてcolor-secondaryでは？」といった議論がスムーズに行えます。

前回の記事でコンポーネント設計について触れましたが、バリアブルはコンポーネントと組み合わせることで共通言語としての力がさらに発揮されます。

例えば、カードコンポーネントにvariant: defaultとvariant: mainというバリアントがあり、それぞれ背景色が異なるとします。

この背景色を直接カラーコードで指定するのではなく、color-surface-defaultとcolor-surface-mainというバリアブルを適用します。こうすると、プライマリカラーの変更やテーマの見直しがあっても、バリアブル側の1カ所を変えるだけでコンポーネント全体に反映されます。

コンポーネントが「部品の形」を定義するものだとすれば、バリアブルは「部品の中で使われる色や余白の意味」を定義するものです。この2つが連携すると、チーム全体で統一した意思を持ってデザインデータを作成できます。

《Vol.5へ続く》

文：綿貫佳祐