【テクニカル・上級編】Figmaの「Variables（変数）」機能完全ガイド！条件分岐とモード切替の実装方法 – UI/UX・デザインツール活用バイブル

Figma Variablesの真髄：UIを「静的アセット」から「実行可能コード」へ昇華させるエンジニアリング

多くのデザイナーやエンジニアは、FigmaのVariables（変数）を単なる「テーマ切り替え用ツール」だと思っている。それは大きな誤解だ。Variablesの真の姿は、Figmaのキャンバス上に構築された、型安全かつイベント駆動型のインメモリ・ステートマシンである。

本稿では、単なる使い方の解説は省く。どうすればVariablesを極限まで抽象化し、デザインシステムとプロダクトコードの境界を消滅させるか。そのアーキテクチャの核心に迫る。

—

1. 変数の抽象化：単なる「色」で管理するな

多くのチームが陥る罠は、`Primary / 500` のようなハードコードされた変数定義だ。これでは、将来的なデザインシステムの刷新で死ぬ。

推奨アーキテクチャ：トークンレイヤーの分離

Primitive Tokens: 色のパレット、数値（Spacing/Radius）。これらは変更しない。
Semantic Tokens: `bg-surface-primary`, `text-on-brand`。
Component Tokens: `button-primary-bg`。

この3層構造をFigmaの「Collection」と「Group」で厳密に管理せよ。API経由でコードへ変換する際、`Primitive`を直接参照するコードは即座にCIで弾くパイプラインを構築するのが、真のDevOpsである。

—

2. モード切替の深淵：条件分岐の「再帰的構造」

Variablesの`Mode`は、CSSの`:root`や`data-theme`属性と一対一で対応させるべきだ。しかし、複雑な論理（例：ユーザー権限によるUI表示切り替え）をプロトタイプで検証したい場合、単純な切り替えでは破綻する。

高度なロジック実装：State-Machine pattern

プロトタイプ上で複雑な条件分岐が必要な場合、「状態保持用の非表示レイヤー」をダミーコンポーネントとして用意し、そこにVariablesをバインドせよ。

Tips: 複数の条件が絡む場合、Boolean変数を多用するのではなく、`Enum`的な文字列変数を作成し、条件を「文字列の組み合わせ」で管理せよ。これにより、プロトタイプのアクションが「if-elseのネスト」から「状態遷移」へと進化する。

—

3. 数値計算による動的プロトタイピングの極致

FigmaのVariablesは、簡単な加減乗除をサポートしている。これを利用すれば、「計算可能なプロトタイプ」が実現できる。

例えば、ショッピングカートの合計金額を動的に計算する場合：
1. `item_price`（Number）
2. `quantity`（Number）
3. `total_price`（`item_price quantity`としてバインド）

この計算ロジックは、そのままフロントエンドの `useMemo` や `computed` プロパティの挙動と一致させるべきだ。プロトタイプで動かないロジックは、実装段階で必ず不具合を生む。

—

4. プロダクトコードとの同期：CLIによる完全自動化

GUIでポチポチ設定しているようでは、開発効率は頭打ちだ。FigmaのREST APIを叩き、VariablesをJSONとして抽出し、それをデザインシステムのトークンファイル（Style Dictionaryなど）に変換するパイプラインを構築せよ。

以下は、Node.jsでFigmaのVariablesをフェッチし、型定義ファイルを生成する簡易スクリプトの断片だ。

Figma API経由でVariablesを抽出し、TypeScriptのEnumとして出力するスクリプト

/
const axios = require(‘axios’);
const fs = require(‘fs’);

async function syncFigmaVariables(fileKey, token) {
const url = `https://api.figma.com/v1/files/${fileKey}/variables/local`;
const { data } = await axios.get(url, { headers: { ‘X-Figma-Token’: token } });

// 変数定義を解析して、型安全なTypeScript定義に変換するロジック
const variables = data.meta.variables;
const tsContent = `export const ThemeVariables = ${JSON.stringify(variables, null, 2)};`;

fs.writeFileSync(‘./src/tokens/figma-variables.ts’, tsContent);
console.log(‘Successfully synced variables to code.’);
}

// パイプラインに組み込むことで、デザイン変更が即座にコードの型定義を更新する

—

5. パフォーマンスとメモリ最適化のハック

Variablesを過剰に定義しすぎると、Figmaのメモリ消費量は急増する。特に、数千個の変数を抱える大規模システムでは、以下のガイドラインを厳守せよ。

1. Scopeの制限: 変数を使用しないコンポーネントにはScopeを制限せよ。これにより、UIのレンダリング負荷が軽減される。
2. 不要なネストの排除: 階層が深すぎる変数は、参照時の計算コストを増大させる。フラットかつ論理的なグループ構造を維持すること。
3. 変数の断捨離: 3ヶ月間参照されていない変数は、API経由でログを出し、定期的に削除するスクリプトを走らせよ。

—

最後に：デザインは「実装」である

UI/UXエンジニアにとって、Variablesは単なる「設定ファイル」ではない。それは、ユーザー体験を記述するためのドメイン特化言語（DSL）だ。

設計の段階で「このロジックはコードでどう表現されるか」を意識し、Figmaとコードの間に「概念的なズレ」を一切残さないこと。それができれば、あなたのチームは、プロトタイプと本番コードの乖離という、この業界最大の呪縛から解放されるだろう。

さあ、ツールを使い倒せ。Figmaの向こう側に、本当のエンジニアリングが待っている。