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

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

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

第5回は、前回に引き続き「バリアブル（Variables）」にフォーカス。バリアブル設計の判断フローを、実践的に学んでいきましょう。

実践：バリアブル設計の判断フロー

判断のための3つの質問

バリアブル化すべきかどうか迷ったときは、以下の3つの質問をしてみてください。

1. そのデザイン上の値は、複数の箇所で使われているか？
   • YES → バリアブルとして定義する
   • NO → 基本的にはバリアブル化しない。ただし、一度しか使わなくても「この赤はエラーを表す赤だ」のように明確な意味があり、将来的に他の箇所でも使う可能性があるなら、エイリアスとして定義しておく価値はある
     
2. その値の意味を、名前だけで他の人に伝えられるか？
   • YES → 適切な名前でトークン化する
   • NO → そのページ固有の装飾的な値など、無理に名前を付けられない場合はバリアブル化しない。ただし、名前が付けられないということは、その値を使う基準自体が曖昧な可能性があることには注意
     
3. AIにその値の使い方を説明できるか？
   • YES → その使い方をエイリアストークンとして定義する。AIとの協働がスムーズになる
   • NO → グローバルトークンのまま、あるいはバリアブル化しないという選択肢もある。すべての値をトークン化する必要はなく、プロジェクトの規模や段階に応じて判断する

コードに変換しづらいバリアブルを避ける

バリアブルを設計するとき、コードへの変換しやすさを意識すると質が上がります。以下は、デザイナーがやりがちですが実装側で困るパターンです。

見た目ベースの色命名

light-blue、dark-grayのように、見た目の印象で色に名前を付けてしまうケースです。

これはダークモード対応時などに破綻します。明るい背景色の上のlight-blueは少々の強調などを表現すると思いますが、暗い背景色の上でのlight-blueだとかなり強めに強調してしまいます。

バリアブルにはモードという機能があり、color-primaryという1つのセマンティックな名前に対して、ライトモードとダークモードで異なる値を設定できます。見た目ベースの命名では、このモードの恩恵を受けられません。

このモード機能はコンポーネントと組み合わせたときに真価を発揮します。

コンポーネント内の色や余白をバリアブルで指定しておけば、親フレームのモードを切り替えるだけで、コンポーネント内部の値が一括で変わります。ライト/ダークモードの切り替えはもちろん、ブランドカラーの差し替えでも同じ仕組みが使えます。

コンポーネント自体には手を加えず、バリアブルのモード設定だけで見た目が切り替わるというのは、運用面で非常に効率的です。

規則性のない余白の値

デザイナーが目で見て微調整した結果、12px、14px、18px、22pxのような不規則な値が余白に混在してしまうケースです。

コード上ではこれらがgap-[14px]のようなマジックナンバーになり、トークンとして体系的に管理できません。

4の倍数（4, 8, 12, 16, 24, 32…）のような規則的なスケールにしておけば、spacing-1からspacing-8のように体系的に管理でき、コード側のユーティリティクラスとも自然に対応します。 規則的であるということは、覚えやすく、説明しやすく、コードに変換しやすいということです。

抽象化できていない命名

hero-section-margin-top、sidebar-card-paddingのように、ページ上の特定の場所に依存した名前を付けるケースです。

コンポーネントスペシフィックトークンとの違いが難しいかもしれませんが「明確な意図がないのにやたら詳細な名前」になっていたら黄色信号です。同じ値なのに別の名前で定義が増殖しがちで「これとこれは同じ値なのか、それとも意図的に違う値なのか」が判断できなくなります。

spacing-md、spacing-lgのようにかなり抽象的な名前にするか、section-spacing、card-spacingなど少し具体性を持たせるかはプロダクトによりますが、いずれにしてもある程度抽象度を上げておいた方が再利用性が高く、管理もシンプルです。

デザイントークンが「設計図」になる時代

デザインデータはボタンの形やレイアウトといった見た目を伴う具体的なものですが、デザイントークンはそれ単体では見た目を持ちません。しかし、色・余白・フォントサイズといったデザインの基本要素を定義したトークンがあれば、AIはそこからUIを組み立てられます。

さらに、私が以前実験したところ、デザイントークン（UIの設計図）とER図（データの設計図）を組み合わせることで、AIが生成するコードの品質が上がることがわかりました。データ構造が明確になると、AIがUI実装にも注意を払う余裕が生まれるように見えました。

詳しくはQiitaに記事を書いているので、興味があれば見てみてください。

●【実際良さそう】AIに実装させるならER図を用意した方が良い説
https://qiita.com/kskwtnk/items/718118497e2966dfcab1

実践事例: ハナユメの開発チーム

弊社で運営している、結婚式場探しを支えるハナユメというサービスの開発チームでも、私がサポートに入りバリアブル化を進めていました。

ページによってコンテンツ幅が違ったり、似たようなUIなのに若干だけ色が違ったりしていましたが、バリアブルを設定することで「このときはこれ」と意思決定が明確になったように思います。 明確に名前がついたことで「このバリエーションが足りないのでは？」と新たな議論を生むきっかけにもなりました。

また、あわせてAIエージェントも導入していましたが、やはりバリアブル化をしてからのほうが生成されるコードの精度が上がりました。

まとめ

前回〜今回は、Figmaのバリアブル機能と、その背景にあるデザイントークンという概念について、粒度の考え方から実践的な設計指針まで掘り下げてきました。

ポイントは以下です。

• デザイントークンは、デザイン上の意図を「名前と値のペア」として管理する概念であり、Figmaのバリアブルはその実現手段
  
• トークンの粒度は、プロダクト規模だけでなく、AI活用も視野に入れて考える
  • セマンティックなトークン名は人間にもAIにも意図が伝わる
    
• バリアブルに設定した値以外を使わない規律が、チームの一貫性と持続性を支える
  • 例外が多い場合はトークン設計を見直すシグナル
    
• トークンで表現しきれない部分は「暗黙知」であり、属人性のリスクを抱えているため、できる限りトークンとして明文化する
  
• コードへの変換しやすさを意識した命名と値の設計が、デザインと実装の橋渡しをスムーズにする
  
• コンポーネントとバリアブルを連携させることで、部品の形と意味を一体で管理でき、変更にも強くなる

バリアブルの活用も、最初から完璧を目指す必要はありません。まずは主要な色やサイズから始めて、プロダクトの成長に合わせて体系を充実させていきましょう。

その過程で、チーム内の「暗黙知」が少しずつ「共通言語」に変わっていきます。

文：綿貫佳祐