今回は、変数の増えすぎによる管理の破綻を防ぎ、スモールスタートで運用を回すための「2層トークン構造」と「ガバナンス設定」を整理して解説します。
バリアントの過剰な肥大化を抑え、日々のコンポーネント制作を効率化していきましょう。

1. Figma Variables（変数）とは？Stylesとの決定的な違い

FigmaのVariables（変数）を導入する際、最初に突き当たる疑問が「これまでのStyles（スタイル）と何が違うのか」という境界線です。
両者の役割を曖昧にしたまま導入してしまうと、デザイン作業中に「どちらを適用すべきか」で迷いが生じてしまいます。

使い分けの判断基準は、管理したいデータが「単一の値（Atomic Value）」か「複合パッケージ（Compound Properties）」かという点にあります。
それぞれの性質を正しく理解すれば、迷うことなく適切な機能を選択できます。

Variablesで管理すべき「単一値」

Variablesは、カラーコードや余白のpx値など、それ以上分解できない単一のデータを保持することに特化しています。
最大の特徴は、Mode（モード）機能によって、Light／Darkテーマのように状況に応じた値を瞬時に切り替えられる点です。

• ソリッドカラー: 背景色、テキスト色、ボーダー色などの単一のカラー値
• 数値（Number）: 余白（Padding／Gap）、角丸（Radius）、要素の幅・高さ
• ブーリアン（Boolean）: UIパーツの表示・非表示を制御する真偽値
• 文字列（String）: 多言語展開のラベルやステータス表示のテキスト

Stylesで管理し続けるべき「複合プロパティ」

一方のStylesは、複数のプロパティが組み合わさったパッケージです。
単一のVariablesでは表現しきれないリッチなビジュアル設定は、今後も変わらずStylesが主役を務めます。

• タイポグラフィ（Text Styles）: フォント名、サイズ、ウェイト、行間、文字間隔のセット
• グラデーション: 複数の色とカラーストップ位置の組み合わせ
• エフェクト: 複数のドロップシャドウやレイヤーブラーの重ねがけ

「カラーと数値はVariables、タイポグラフィとグラデーションはStyles」という基本原則をチーム内で共有するだけで、運用の混乱は一気に解消されます。
なおタイポグラフィに関しては、Text Stylesというパッケージを使いつつ、フォントサイズや行間の数値にのみVariablesを紐づけるハイブリッド運用が実務では扱いやすいです。

自分自身も初期はすべてを変数化しようとして混乱しましたが、この分担ルールに落ち着いてからは迷いが完全になくなりました。

2. 破綻を防ぐ「2層トークン構造（PrimitiveとSemantic）」の設計ルール

デザインシステムやトークン設計の解説書を開くと、よく「3層構造（Primitive / Semantic / Component）」が推奨されています。
しかし、現場で最初から3層すべてを厳密に構築しようとすると、設定の手間と認知的負荷に圧倒されて運用が破綻しがちです。

これから導入する段階であれば、まずは最も重要な「Primitive」と「Semantic」の2層構造からスモールスタートすることをおすすめします。
この2階層さえしっかり組めていれば、中規模までのUI設計で困ることはほとんどありません。

Tier 1：Primitiveトークン（生の値）

Primitiveトークンは、具体的なカラーコードや数値を定義する「生の素材置き場」です。
ここには「ボタン」や「背景」といった画面上の役割や意味を持たせず、純粋な色の名前や数値のスケールとして定義します。

• 命名例: _primitive/color/blue/600、_primitive/space/16、_primitive/radius/8
• 値の実装: #2563EB、16px、8px
• 運用のルール: PrimitiveトークンはUIに直接適用せず、後述するSemanticトークンから参照させるためだけに使用します。

Tier 2：Semanticトークン（役割と意味）

Semanticトークンは、「その値をどこで、何の目的で使用するのか」というデザイン上の役割を定義する階層です。
UIをデザインする際にデザイナーが選択パネルから選ぶのは、すべてこのSemanticトークンになります。

• 命名例: color/surface/brand、color/text/primary、space/layout/md
• 値の実装: _primitive/color/blue/600（Primitiveを参照するエイリアス）
• 運用のルール: 画面の背景色を変えたいときは、色コードを直打ちするのではなく、このSemanticトークンを割り当てます。

このように「生の色」と「画面上の役割」を分離しておくことで、将来的にブランドカラーが刷新された際も、参照元のPrimitiveを1箇所書き換えるだけでサイト全体のトーンが一瞬で更新されます。
また、特定のボタンや入力フォーム専用の「Componentトークン」は、必要に迫られた段階で初めて追加すれば十分です。

実務で運用する際も、まずは主要な無彩色とブランドカラー数色から2層化を始めることで、チームメンバーへの負担を最小限に抑えられます。

3. 実務でよく使う4つのVariables設定手順

Variablesの概要と構造を把握したところで、実務で頻出する4つの変数の具体的な設定手順を見ていきましょう。
日常のUI設計でこれら4種類を使いこなせるようになると、制作スピードとデータの整合性が格段に上がります。

① カラー変数（Color）：ダークモードとテーマ切り替え

カラー変数の真価は、複数モード（Mode）によるテーマ切り替えにあります。
LightモードとDarkモードをひとつのコレクション内で共存させる手順は以下の通りです。

1. ローカル変数パネルでコレクションを新規作成し、モード列を「Light」「Dark」の2つ用意します。
2. Semantic階層に color/surface/primary という名前でカラー変数を作成します。
3. Light列の値には _primitive/neutral/50（明るいグレー）を割り当て、Dark列には _primitive/neutral/900（濃いグレー）をエイリアスとして割り当てます。
4. 作成した変数をフレームやカードのFillに適用します。

この設定を済ませておけば、親フレームの右パネルにある「Change variable mode」からDarkを選ぶだけで、子要素のコンポーネント全体が一瞬で反転表示されます。
画面ごとに別々のカンプを用意する必要がなくなるため、メンテナンスの工数を大幅に削減できます。

② 数値変数（Number）：8ptスペーシングと角丸の共通化

余白や角丸の数値をハードコード（直接入力）せず、Variablesで共通化することで、デザインの秩序が自然と保たれます。
特に8ptグリッドルールを採用しているプロジェクトでは、数値変数の導入が大きな威力を発揮します。

1. space/4, space/8, space/16, space/24, space/32 などの基準スケールを数値変数として登録します。
2. オートレイアウト（Auto Layout）のPaddingやGapの入力欄にマウスを乗せ、表示される変数アイコンから対応する数値を割り当てます。
3. 角丸（Radius）についても同様に、radius/sm (4px), radius/md (8px), radius/lg (16px) を用意してコンポーネントに紐付けます。

手入力による「7px」や「15px」といった微細なズレがなくなり、チーム全体のデザイン品質が均一になります。
余白を変数にバインドしておけば、後から「全体の情報密度を少し上げたい」となった場合でも、変数の数値を調整するだけで全画面に反映されます。

③ ブーリアン変数（Boolean）：バリアント肥大化の防止

ブーリアン変数は、要素の表示（true）と非表示（false）を切り替えるための真偽値データです。
バリアント（Variants）を無駄に増やしたくない場面や、コンポーネント内のパーツの出し入れに重宝します。

1. has_icon や is_badge_visible というブーリアン変数を作成し、初期値を true に設定します。
2. コンポーネント内の対象レイヤー（例: アイコン）を選択し、右パネルのレイヤー表示（目のアイコン）を右クリックして変数をバインドします。
3. インスタンス側で変数の値を false に切り替えると、レイヤーが自動的に非表示になります。

従来は「アイコンあり」「アイコンなし」で別々のバリアントを作成していましたが、ブーリアン変数を使えば1つのコンポーネント内で完結します。
結果としてバリアントの総数を半分に圧縮でき、キャンバスの動作軽量化にも直結します。

④ 文字列変数（String）：多言語展開と動的ラベル

文字列変数は、テキストレイヤーに入力される文言をデータとして保持する仕組みです。
画面レイアウトを崩さずに多言語（日本語／英語）での見え方を検証したい場面で役立ちます。

1. label/submit_button という文字列変数を作成します。
2. モード列を「JA」「EN」に分け、JAには「送信する」、ENには「Submit」と入力します。
3. ボタン内のテキストレイヤーを選択し、テキスト設定の「Apply variable」から割り当てます。

英語化によってボタン幅が想定を超えて広がらないか、テキストが意図せず折り返されないかを、デザイン段階で即座にチェックできます。
開発チームへ画面を引き渡す前に文字あふれを検知できるため、手戻りを未然に防ぐことができます。

4. デザイナーが迷わないための「ガバナンス」設定（スコープ・非公開）

Variablesを本格的に運用し始めると、「変数の候補が多すぎて、どれを選べばいいか分からない」という新たな問題が発生しがちです。
この検索ストレスを解消するために、Figmaが用意している2つのガバナンス機能を初期段階で必ず設定しておきましょう。

スコープ（Scope）設定で不要な変数を非表示にする

スコープ設定は、変数を「どのプロパティパネルに表示させるか」を絞り込める機能です。
変数の編集画面を開き、「Scoping」のチェックボックスを調整することで設定できます。

• 角丸用の変数: 「Corner radius」のみにチェックを入れ、余白やサイズからは除外する。
• 余白用の変数: 「Auto layout padding and gap」のみに絞り込む。
• テキストカラー用の変数: 「Text fill」のみに限定し、背景色や線色の候補から隠す。

これにより、デザイナーが角丸を設定しようと選択パネルを開いた際、パディング用の数値変数が候補に出なくなります。
選択画面のノイズが消え、誤った変数を適用してしまうヒューマンエラーを未然に防止できます。

_（アンダースコア）によるライブラリ非公開化

Primitiveトークン（生の値）をデザイナーが間違えてUIに直接選んでしまう事故を防ぐための機能です。
Primitiveを直接適用してしまうと、Modeを切り替えても色が反転しなくなる原因になります。

Figmaでは、コレクション名やグループ名の先頭に _ （アンダースコア）または . （ドット）を付けるだけで、ライブラリ公開（Publish）の対象から一括除外できます。

• 設定例: _primitive` というコレクション名、または `_color/blue/600 というグループ名

この設定を行っておけば、チームメンバーの画面には目的が明確なSemanticトークン（例: color/surface/brand）だけがクリーンに表示されます。
事故が起きない「仕組み」を初期に整えておくことが、無理のない継続運用の秘訣です。

実務でも「間違えて選べない構造」をあらかじめ作っておくことで、デザインレビュー時の指摘事項を大幅に削減できます。

5. 開発連携（Dev Mode・Code Syntax・AIコード生成）を見据えた設計

Variablesを構造化して管理する恩恵は、デザイナー単体の作業効率化にとどまりません。
エンジニアへのハンドオフ（実装引き渡し）の円滑化や、近年のAIコーディング連携においても非常に強力な武器となります。

Code Syntaxの登録で実装の翻訳コストをゼロにする

Figmaの変数設定画面には、「Code syntax」という入力欄が用意されています。
ここにエンジニアリング側で使用する変数名（CSS Custom Propertiesなど）をあらかじめ登録しておきます。

• Figmaの変数名: color/surface/brand
• Web（CSS）のCode syntax: var(--color-surface-brand)
• iOS（SwiftUI）のCode syntax: Color.surfaceBrand

エンジニアがDev Modeで要素をインスペクトした際、脳内変換することなく、コードをそのままコピー＆ペーストして実装に組み込めます。
デザインとコードの命名が1対1で同期するため、デザインレビュー時の手戻りも激減します。

AIコーディング・MCP連携における構造化データの価値

近年、CursorやClaude CodeなどのAIエージェントを活用したフロントエンド開発が急速に浸透しています。
FigmaのVariablesによってデザイン上の決定事項が構造化されていると、AI連携の精度が飛躍的に高まります。

AIはFigmaのデータを解析する際、単なるHexコードではなく「これは背景色としての役割を持つトークンである」という文脈を正確に読み取ります。
その結果、ハードコードされた汚いスタイルではなく、デザインシステムの思想を反映したメンテナンス性の高いコードを一発で生成してくれます。

次のステップ：あわせて深掘りしたい知見

Variablesを基礎から理解した後は、コンポーネントプロパティやダークモード設計と組み合わせることで、UIの管理破綻をより強固に防げるようになります。

バリアントの過剰な肥大化を防ぎ、ボタンや入力フォームを最小限のパーツで設計する具体的な実践テクニックは、以下の記事で体系的に解説しています。

Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術

Boolean・Text・Instance Swapの3大プロパティを活用し、増えすぎたバリアントを最小限に抑えるコンポーネント設計術とスロット運用のコツを解説します。

VariablesのMode機能を活用して、ライトモードとダークモードを一瞬で切り替える具体的な配色ルールと変数設計は、以下のガイドが参考になります。

ダークモードは必要？3つの導入基準とFigma変数設計・便利プラグイン

ダークモードの導入基準から配色の4大ルール、Figma VariablesのMode機能を活用した破綻しない2層変数設計とおすすめプラグインを解説します。

数値変数をAuto LayoutのPaddingやGapに割り当てて、崩れないレスポンシブコンポーネントを組む手順については、こちらの記事で詳しく解説しています。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaのオートレイアウトを基礎から徹底解説。リサイズ挙動（Hug/Fill/Fixed）の使い分けや崩れないネスト構造、実務で役立つコンポーネント余白設計をまとめました。

まとめ：まずはカラー数色・スペーシングからのスモールスタート

Figma Variablesは、一見すると設定項目が多くて難解な機能に感じられるかもしれません。
しかしその本質は、「デザインの意思決定を一貫したルールで整理整頓するための道具」にすぎません。

• カラーと数値はVariables、タイポグラフィとグラデーションはStylesで管理する
• 生の値（Primitive）と役割（Semantic）のシンプルな2層からスタートする
• スコープ設定と _（非公開設定）でデザイナーの選択肢を適切に絞り込む
• Code Syntaxを登録してエンジニアへの引き渡しとAIコード生成を円滑にする

最初から大規模なデザインシステムを組もうと気負う必要はありません。
まずはプロジェクトのブランドカラー数色や、よく使うスペーシングの数値から少しずつ変数化してみてください。
小さな整理整頓の積み重ねが、将来的にチーム全体を支える強固な制作基盤へと育っていくはずです。

The post Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】 first appeared on デザペディア.