こんにちは！
UIデザイナーのYunyです。
- FigmaのVariables（変数）機能に興味はあるが、「設定や管理が難しそう」と導入をためらっている方
- デザインシステムやトークン設計のハードルの高さに不安を感じているデザイナー
- デザイナーと一緒にVariablesを導入したいけれど、どこから手をつければいいか悩んでいるエンジニア
最近、MCP（Model Context Protocol）サーバーを導入して、FigmaとAIエージェントの連携を触り始めました。
デザインデータとコードが目の前で同期していく様子を見るのは、新しい道具を手に入れたときのような純粋なワクワク感があります！
ただ、こうした新しい機能や便利な仕組みを試すときって、同時に「覚えることが多そうだな」「せっかく導入しても、管理が追いつかずに散らかって破綻してしまうのではないか」という不安もつきまといますよね。
実はFigmaのVariables機能も、同じような心理的ハードルから導入を一歩踏み出せずにいる方が多いのではないでしょうか。
「Variablesを構築しようとコレクションを開いたものの、何から作ればいいか分からず15分で閉じてしまった」「変数が増えすぎて適用するときに迷い、最後には数値を直接入力してしまって罪悪感を覚える」といった、デザイナーの現場ならではの挫折や悩みもよく耳にします。
今回は、そんなVariablesへの心理的ハードルを下げ、最初から完璧を目指さずに「これならできそう」と思えるスモールスタートの設計と運用の基本ルールをお話しします。
- 1. なぜFigmaのVariablesは「ハードルが高そう」に見えるのか？
- 2. 【一歩目】StylesとVariablesの「境界線（使い分け）」をスッキリ整理する
- Variables（単一値）で管理するもの
- Styles（複合値）で管理するもの
- 3. 【設計】破綻を防ぐ「シンプルな階層構造」の作り方
- Tier 1：生の値の箱（Primitiveトークン）
- Tier 2：役割の箱（Semanticトークン）
- 4. 【運用のコツ】デザイナーを迷わせない「ガバナンス」設定
- スコープ（Scope）設定で不要な変数を非表示にする
- 「非公開（Hide from publishing）」で生の色を選択肢から隠す
- 5. 【発展】開発実装（Handoff）や自動化・AI連携も視野に入れよう
- まとめ：最初はスモールスタートでOK
- 終わりに
1. なぜFigmaのVariablesは「ハードルが高そう」に見えるのか？
FigmaにVariables（変数）機能が搭載されてから、デザインシステム構築の現場では大きな変化が起きています。これまでStyles（スタイル）だけでは難しかった「モード切り替え（ライトモードとダークモードなど）」や「画面サイズに応じた数値の動的な変更」が、Figmaのネイティブ機能として実現できるようになりました。
それにもかかわらず、多くのデザイナーや開発チームが導入に二の足を踏んでしまうのには、いくつかの理由があります。
- 「Stylesとの使い分けや移行コストが分からない」
すでにStylesでカラーや文字を管理しているため、Variablesに移行するメリットや、それぞれの役割分担が整理しきれていないケースです。 - 「3層構造（Primitive, Semantic, Component）という概念が難解」
デザイントークンの設計手法としてよく語られる「3層構造」が複雑に見え、最初からそこまで厳密に設計しなければならないのかと圧倒されてしまいます。 - 「変数が増えすぎて管理しきれなくなるのが怖い」
変数を作成していくうちに名前空間がゴチャゴチャになり、検索性が低下したり、デザイナーの選択ミスが増えたりする運用への不安です。
実は、Variablesは「大規模で完璧なデザインシステム」を作るためだけのものではありません。最初は少人数や小さなプロジェクトから、不要な設定を削ぎ落として「整理整頓の箱」を作る感覚で始めていけば、決して難しくはありません。
2. 【一歩目】StylesとVariablesの「境界線（使い分け）」をスッキリ整理する
導入にあたって最初に行うべきは、StylesとVariablesの役割分担をシンプルに整理することです。ここが曖昧なままだと、デザインデータを操作する際に迷いが生じてしまいます。
使い分けの判断基準は、そのデータ構造が「単一値」か「複合値」かという点にあります。
Variables（単一値）で管理するもの
Variablesは、カラーのHex値、スペーシングや角丸の数値、特定のテキスト文言（文字列）など、それ以上分解できない「単一のデータ値」を保持します。
最大の特徴は、Mode（モード）機能によって、Light/Darkテーマのように状況に応じた値を保持できる点です。
- 管理対象: ソリッドカラー（不透明度含む単一色）、スペーシング（余白の数値）、角丸（Border Radiusの数値）、コンポーネントの表示切り替え（真偽値）など。
Styles（複合値）で管理するもの
Stylesは、複数のプロパティが組み合わさった「パッケージ」です。
- 管理対象: タイポグラフィ（フォントファミリー、サイズ、ウェイト、行間、文字間隔のセット）、グラデーション（複数の色と位置の組み合わせ）、複雑なエフェクト（ドロップシャドウやブラーの重ね掛け）など。
「カラーはVariablesで一元管理し、タイポグラフィはStylesで管理する」という基本ルールにするだけで、迷いは一気に解消されます。
特にタイポグラフィに関しては、フォントサイズや行間を個別にVariablesで適用しようとすると、デザイナーが毎回テキストレイヤーに対して複数の変数を選択することになり、作業ミスや認知負荷が増大してしまいます。
そこで、Text Stylesという「器」を従来通り提供しつつ、そのスタイル内のフォントサイズや行間の設定値に対してのみ、背後でVariables（数値変数）を割り当てるという「ハイブリッドな連携方法」が最も実用的です。
3. 【設計】破綻を防ぐ「シンプルな階層構造」の作り方
デザインシステムやトークン設計の文脈では、よく「プリミティブ（Primitive）」「セマンティック（Semantic）」「コンポーネント（Component）」の3層構造が推奨されます。
しかし、これから導入する段階でこれらすべてを一度に構築しようとするのは、ハードルが高すぎます。最初は、最も重要な「2つの階層」だけを作り、エイリアス（参照）で繋ぐスモールスタートをおすすめします。
Tier 1：生の値の箱（Primitiveトークン）
すべての具体的な値を定義する階層です。ブランド名やコンポーネント名、画面上の用途は含めず、純粋な色の名前や数値として定義します。
- 命名例:
color/blue/600 - 値の実装:
#2563EB - 注意点: この生の値は、次のセマンティック変数の「参照先」としてのみ使用し、実際のUIコンポーネントに直接適用してはいけません。直接適用すると、ダークモードなどのテーマ切り替えが機能しなくなります。
Tier 2：役割の箱（Semanticトークン）
「その値をどこで、何の目的で使用するのか」というデザイン上のルールを定義する階層です。デザイナーがUI作成時に直接選択するのは、このセマンティックトークンです。
- 命名例:
color/surface/brand - 値の実装:
color/blue/600（Primitiveを参照するエイリアス）
カラー以外のスペーシングや角丸といった数値データについても、同様の考え方で整理できます。
以前公開した記事「Material Design 3入門：UIデザインの「感覚」を「ロジック」に変える」でも詳しく触れたように、システムの中に「役割」という抽象的な階層を一枚挟むことで、デザインの変更や多言語展開に対する柔軟性が格段に高まります。
なお、コンポーネント専用の「Tier 3（Componentトークン）」については、最初は作る必要はありません。ボタンや入力フォームの背景色を個別に変えたくなったときに、初めてセマンティック変数を参照する形で追加すれば十分です。
4. 【運用のコツ】デザイナーを迷わせない「ガバナンス」設定
Variablesを作った後に起こりがちな問題が、「変数リストが膨大すぎて、設定したいプロパティに合う変数がどれか分からなくなる」という混乱です。
これを防ぐために、Figmaが用意している「ガバナンス機能」を初期設定の段階で活用しましょう。
スコープ（Scope）設定で不要な変数を非表示にする
スコープ機能は、変数を「どのプロパティパネルに表示させるか」を制限できる設定です。
例えば、角丸の数値変数は「Corner radius」のみにスコープを設定し、余白の数値変数は「Auto layout」のみに設定します。
これにより、デザイナーが角丸を設定しようと選択画面を開いたときには、パディングやフォントサイズなどの無関係な変数が自動的にフィルタリングされ、必要な変数だけがスッキリと表示されます。選択の手間が省け、人為的な入力ミスも未然に防ぐことができます。
「非公開（Hide from publishing）」で生の色を選択肢から隠す
デザイナーがUIを構築する際、Primitiveトークン（生の色）を直接選べないように制限をかけます。
Figmaでは、コレクション名やグループ名の先頭に _ （アンダースコア）または . （ドット）を付けるだけで、そのグループ全体をライブラリのパブリッシュ（公開）対象から一括して除外できます。
これにより、他のファイルからライブラリを使うデザイナーのカラー選択画面には、目的が明確なSemanticトークン（例: color/surface/brand）だけが表示され、間違って生の色（例: color/blue/600）を選択してしまう事故を防ぐことができます。
こうしたデザインシステムにおける「選択肢の制限」がもたらす効果については、「デザインハーネスとは？無数の選択に疲れた日々を軽くする「適度な制約」の知見」という記事でも、チーム内の認知負荷を下げるための制約デザインとして詳しく紹介しています。
5. 【発展】開発実装（Handoff）や自動化・AI連携も視野に入れよう
Variablesの設計が整うと、その恩恵はデザイン作業の効率化だけにとどまらず、開発チームへのハンドオフ（引き渡し）の自動化や、AIを活用した新しいプロダクト開発（AI駆動開発）の基盤としても大きな強みを発揮します。
- コードフレンドリーな命名規則
Figma上の変数名は、そのままプログラムの変数（CSS Variablesなど）として出力されることを考慮し、大文字やスペースを避け、スラッシュ/で階層化した小文字・ケバブケース（ハイフン繋ぎ）で記述します（例:color/surface/brand）。 - Code syntaxの登録
FigmaのDev Mode（開発モード）に搭載されている「Code syntax」を利用し、Figmaの変数名と、実際のコードベースでのCSS変数名（例:var(--eds-color-surface-brand)）を紐づけておきます。これにより、エンジニアが開発画面でインスペクトした際、脳内翻訳することなく、コードをそのままコピー＆ペーストして使用できます。 - W3C規格と自動化パイプライン
W3Cの「Design Tokens Community Group（DTCG）」標準に準拠した形式で変数を管理することで、FigmaからJSON形式で書き出したトークンデータを、エンジニアリング側のCSSやSwiftUI、Androidの各コードへCI/CDを通じて完全自動で変換・同期する仕組み（Style Dictionaryの活用など）を導入しやすくなります。 - AI駆動開発における構造化データの価値
近年、コーディングAIエージェントを用いて画面を実装する手法が広がっています。FigmaのVariablesによってデザイン上の意思決定がJSONデータとして構造化されていれば、AIエージェントはその意味（コンテキスト）を正確に読み取り、「ここは単なるグレーではなく、背景の役割を持っている」と解釈した上で、非常に正確でメンテナンスしやすい実装コードを自動生成してくれます。
完璧な自動化パイプラインを最初から構築する必要はありませんが、Variablesを正しく設計しておくことは、将来的にチーム全体が圧倒的な開発スピードを手に入れるための、最初の大切な一歩になります。
まとめ：最初はスモールスタートでOK
Figma Variablesは、一見すると設定項目が多くて難解な機能に見えるかもしれません。しかし、その本質は「デザインと開発の意思決定を一貫したルールで整理整頓するための道具」です。
破綻を防ぎ、スムーズな運用を始めるためのステップをおさらいしましょう。
- カラーはVariables、タイポグラフィはStylesという使い分けから始める
- 生の値（Primitive）と役割（Semantic）のシンプルな2層からスタートする
- スコープ設定と非公開設定（_アンダースコア）でデザイナーの選択肢を適切に絞り込む
- スラッシュ
/を用いたコードフレンドリーな命名を徹底する
最初から完璧なシステムを求めず、まずはプロジェクトのメインカラー数色や、よく使うスペーシングから少しずつ変数化してみてください。小さな整理整頓の積み重ねが、いずれチーム全体を支える堅牢なデザインシステムへと成長していくはずです。
終わりに
最後までお読みいただき、ありがとうございます！
FigmaのVariables機能は、単なるデザインツールのアップデートではなく、デザインとエンジニアリングの境界線をゆるやかに繋ぎ、ものづくりの進め方を面白く変えてくれる可能性を秘めています。
最初は「ちょっと色をいくつか変数にしてみよう」くらいの軽い気持ちから、まずは一歩を踏み出してみませんか？
それでは、良いデザインライフを！
