デザインからコーディングに渡すとき、いちばん時間を食うのは「数値のすり合わせ」です。ボタンの余白がデザインと1px違う、色コードが微妙に違う、ブレークポイントの名前が実装と一致しない。私もWordPressや静的コーディングを自分でやるので、このズレは何度も経験しています。
Figma Variables（バリアブル）は、色・数値・文字列などを変数として束ね、コンポーネントやモード（ライト/ダークなど）で切り替えられる機能です。この記事では、Variablesの概念説明だけでなく、制作現場で導入する手順と、実装側と名前を揃える運用に絞って書きます。
先に結論
- 向いている人: コンポーネント単位でデザインを回す人、同じ案件でデザインと実装の両方を触る人、小さなデザインシステムをチーム内で回したい人
- 向いていない人: 1ページ完結のランディングだけで今後更新しない案件、Variables未対応の古いFigmaファイルしか触らない環境
- 私のおすすめ: まず色とスペーシングだけVariables化。命名は実装（CSSカスタムプロパティ）と1:1で揃える。全トークンを一度に作らない
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
私は実装直前の手戻りを減らすために、Figmaの手順を短く固定しています。
Variablesで解決できるズレ
| ズレの種類 | 従来 | Variables導入後 |
|---|---|---|
| 色 | コンポーネントごとに直指定 | 変数を差し替えて一括更新 |
| 余白 | 8px/16pxがバラバラ | spacingトークンで統一 |
| ライト/ダーク | ファイル複製や手作業 | モード切替で同一コンポーネント |
| 実装との対応 | 口頭やメモ | 変数名をCSS変数名に合わせる |
Variablesは魔法ではありません。命名規則と更新フローを決めないと、別の形でカオスになります。大事なのは「一箇所の正本」をFigmaとコードのどちらかに決めること。私は小規模案件ではFigmaを正本にし、実装時にCSS変数へ写すパターンが多いです。
導入前に決める3つのこと
1. スコープ
全プロジェクトのデザインシステムか、単一案件か。最初は単一案件の「色＋スペーシング＋角丸」だけで十分です。
2. 命名規則
例: color/primary/default、space/md、radius/sm。スラッシュ区切りはFigmaのコレクション整理に向きます。実装側は --color-primary-default のようにケバブケースへ変換するルールを文書化します。
3. モードの数
ライト/ダークの2モードから始めるのが無難。ブランド切り替えまで最初から入れると複雑になります。
手順1: コレクションを作る
Figmaのローカル変数（またはライブラリ）で、コレクションを分けます。
- Color: ブランド色、テキスト、背景、ボーダー
- Spacing: 4, 8, 12, 16, 24, 32… など8段階以内
- Radius: sm, md, lg
- Typography（任意）: フォントサイズ、行間（文字列変数や数値変数）
コレクションを分けると、デザイナーが色だけ更新するときに迷子になりにくいです。
手順2: プリミティブとセマンティックを分ける
デザインシステムでよく使う2層構造です。
プリミティブ
blue-500、gray-100 など、名前が値そのものの色。
セマンティック
color/text/primary → プリミティブ gray-900 を参照。
color/bg/surface → プリミティブ white を参照。
実装ではセマンティック名をCSS変数にし、テーマ切り替えはセマンティック層だけ触る。Figma Variablesでも同じ参照構造にすると、ライト/ダークのモード切替が楽になります。
手順3: コンポーネントにバインドする
既存コンポーネントの塗りやパディングを、直値ではなく変数に差し替えます。一気に全部やらず、ボタンとカードから始めるのが現実的です。
- ボタンの背景色 →
color/action/primary - ボタンの padding →
space/smspace/md - 角丸 →
radius/md
コンポーネントのバリアント（Primary / Secondary）も、変数のモードや別変数で表現できます。古いスタイルが残っていると「半分だけVariables化」になり、ズレが残るので、触ったコンポーネントは最後までやり切る意識が必要です。
手順4: 実装側への引き渡し
デザイナーからエンジニアへ渡すとき、次のどれかをセットにします。
- FigmaのDev Modeで変数名を確認できる状態
- 変数一覧をMarkdownやJSONでエクスポート（プラグインや手動）
- StorybookやCSSファイルに同名のカスタムプロパティを先に定義
私がコーディングもやる場合は、:root { --color-text-primary: ... } を先に書き、Figmaの値と数値を照合します。名前が一致していると、あとから値だけ変えても両方更新しやすいです。
モード（ライト/ダーク）の運用
Variablesのモードは、同じ変数名で値セットを切り替えます。color/bg/surface がライトでは白、ダークでは濃いグレー、という形です。
注意点は、コントラスト比です。モードを増やしたら、テキスト色と背景色の組み合わせを主要画面で確認してください。アクセシビリティの数値はツールで測る習慣を。WCAGの厳密な適合は案件要件次第ですが、読めない組み合わせは避けたいです。
ライブラリとしてチーム共有する場合
複数ファイルで同じVariablesを使うなら、ライブラリファイルを1つ作り、プロジェクトファイルからリンクします。更新時はライブラリを公開し、各ファイルで更新を受け入れる流れになります。
フリーランスでクライアントのFigmaを触る場合、権限とライブラリの所有者を確認。クライアント組織のライブラリに載せるか、案件用にコピーするかは契約と運用で決めます。
失敗しやすいポイント
最初から全トークンを定義
メンテされずに死んだ変数が増える。最小セットから。
命名が実装と違う
primary-blue と --color-primary が対応しない。最初に対応表を1ページ作る。
古いスタイルと混在
同じボタンに直値と変数が混ざる。触ったら全部変数へ。
スペーシングの段階が多すぎ
12段階あると選ぶのが遅い。8段階以内が現場では回りやすい。
ダークモードを後から無理やり
最初からセマンティック層を作っておくと楽。後付けは手戻り大。
プラグインとエクスポート
Figmaからコードへ値を運ぶプラグインはいくつかあります。案件によってはTokens Studioなどを使うチームもあります。重要なのはプラグインの流行より、チームで続くフローを選ぶこと。私の一人案件では、Dev Modeと手動のCSS変数で足りることが多いです。
コストの目安
FigmaのVariables機能は、プランによって利用範囲が異なります。執筆時点（2026年5月・日本時間）の料金と機能は公式を確認してください。フリーランス1人なら、無料〜プロフェッショナルプランのどちらかで足りる案件がほとんどです。組織ライブラリやDev Modeの本格利用は、クライアント側のプランに依存することもあります。
Dev Modeと実装者への引き渡し
Figma Dev Modeでは、変数にバインドされたプロパティが開発者向けに表示されます。デザイナーがVariablesで名前を整えておくと、実装側が「このpaddingは何px？」という質問を減らせます。
引き渡し物は、Figmaリンクに加えて、変数一覧のスクリーンショットまたはエクスポートがあると親切です。特に色のセマンティック名とプリミティブの対応表は、1ページで十分効きます。
コンポーネントライブラリとの併用
Variablesはデザインシステムの「値」、コンポーネントは「部品」です。ボタンコンポーネントが color/action/primary を参照している状態を作ると、ブランド色の変更が一括で効きます。
既存のコンポーネントライブラリがStyles中心の場合、新規コンポーネントからVariables化し、古いコンポーネントは案件の余裕があるときに置き換える、という段階移行が現実的です。一晩で全置換は、大規模チームでもリスクが高いです。
コード側のCSS変数テンプレ例
実装でよく使うのは、次のような構造です（例）:
:root {
--color-text-primary: #1a1a1a;
--color-bg-surface: #ffffff;
--space-md: 16px;
--radius-md: 8px;
}
Figmaの変数名 color/text/primary を --color-text-primary に変換するルールを、プロジェクトのREADMEか .cursor/rules に1行書いておくと、デザイナーとエンジニアの両方が迷いません。私が一人でデザインと実装をやる場合も、未来の自分のためのメモになります。
レビューと変更管理
Variablesの値を変えたら、影響範囲をコンポーネント一覧で確認します。Figmaの「変更されたライブラリを確認」フローを、週1のデザインレビューに組み込むと、意図しない色のズレが本番に出にくくなります。
クライアントに「色を少し変えた」と伝えるとき、Variablesがあれば変更箇所の説明がしやすいです。逆に、Variablesなしで直値だらけのファイルは、変更の影響が追いにくく、見積もりも膨らみやすいです。
デザイントークンの段階的導入ロードマップ
第1週: 色プリミティブ10色と、セマンティック5種を定義。
第2週: スペーシング8段階、角丸3段階。
第3週: ボタン・入力・カードの3コンポーネントにバインド。
第4週: 実装のCSS変数と突合、差分を修正。
4週間で全ページ完了を目指さない。新規画面からVariables前提で作り、旧画面は触ったときに直す。
小規模チームでの役割分担
デザイナーがVariablesの正本を持ち、エンジニアがCSS変数を実装で正本にする、の二重正本は危険です。どちらか一方を「数値の源」に決め、もう一方は同期イベントで更新。一人兼業なら、Figmaを源にして実装時に写す、で十分なことが多いです。
コンポーネント更新時のチェックリスト
- 変数参照が外れていないか
- ダークモードの見え方
- フォーカスリングの色（アクセシビリティ）
- ボーダーとシャドウのトークン化の要否
影やぼかしまでVariables化するかは、案件の規模次第。最初は色・スペース・半径に留め、必要になったら拡張。
失敗から学ぶ典型例
「全色をVariables化したが誰も名前を覚えていない」→ セマンティック層を10個に絞る。
「実装が直値のまま」→ PRレビューでCSS変数使用を必須化。
「モードが3つあるが2つしか使わない」→ 使わないモードは削除して認知負荷を下げる。
WordPressテーマ実装との接続
テーマの style.css や SCSS の変数ファイルに、Figmaのトークンを写すとき、_variables.scss を1ファイルにまとめる方法が多いです。PHPテンプレートには直値を書かず、クラス経由でトークンを参照する。既存テーマが直値だらけなら、触ったコンポーネントからVariables対応のCSSに置き換える。
デザインレビュー会議での見せ方
ステークホルダーに「Variablesで管理しています」と言うより、「色の変更は1箇所で済みます」とメリットで伝える方が通りやすいです。Before/Afterでボタン色を一括変更するデモは、理解が一気に進みます。
トークン数の上限目安
色プリミティブ20、セマンティック15、スペーシング8、半径3——これ以上増やす前に、本当に必要かレビュー。トークンが増えるほど、選ぶコストと教育コストが上がります。デザインシステムは小さく始めて、案件の要求で増やす方が、個人・小チームでは回りやすいです。
引き継ぎ時のドキュメント
後任のデザイナーや実装者に渡すとき、Figmaファイルのリンク、Variablesコレクション名の一覧、CSS変数ファイルのパス、命名変換ルールの1ページ、の4点セットがあると、オンボーディングが早いです。
よくある質問（デザイナー向けの社内メモ例）
「変数名、長くてもいい？」→ 長すぎるとDev Modeで見づらい。3階層まで。
「古い色、消していい？」→ 参照が残っていないか検索してから。
「ダークだけ後から」→ セマンティック層があれば可能。直値だらけだと地獄。
実装後のズレを検知する
Storybookや簡単なスタイルガイドページを1枚用意し、Figmaのスウォッチと並べて見比べる。月1回で十分。ズレはだいたい「誰かが直値で上書きした」ところから発生します。VariablesとCSS変数の両方を正本にしないと、どちらかが古くなります。
よくある質問
Q. VariablesとStyles（スタイル）の違いは何ですか？
A. 従来のColor StyleやText Styleも再利用には有効です。Variablesは数値・文字列も含め、モード切替や参照チェーンがしやすいのが違いです。新規案件なら色とスペーシングはVariables、タイポグラフィはText Styleのまま、という併用もありです。既存ファイルがStyles中心なら、一気に移行せず新コンポーネントからVariables化する方が安全です。
Q. 小さなLP1枚でも使う価値はありますか？
A. 更新予定がほぼなく、コンポーネントも少ないなら、オーバーヘッドの方が大きいことがあります。同じブランドで複数ページを作る、またはライト/ダーク両方出すなら、早めにVariablesを入れた方が後が楽です。
Q. 実装がTailwindの場合、Variablesとどう対応させますか？
A. tailwind.config の theme.extend にFigmaのトークンを写すか、CSS変数をTailwindから参照する形です。変数名をFigmaとconfigで揃える表を1枚作ると、デザイン変更時の更新箇所が分かりやすくなります。
Q. クライアントにVariablesの運用を説明するには？
A. 「色と余白の名前を決めて、変更が一箇所で済む」くらいの平易さで十分です。技術詳細より、修正コストが下がることを伝えると理解されやすいです。納品時に変数一覧のスクリーンショットを添えるのも手です。
既存案件への後付け導入
すでに画面が100枚あるプロジェクトにVariablesを後から入れるのは大変です。新規ページからVariables前提で作り、旧ページは改修のたびに少しずつ直す。クライアントに「デザインシステム整備期間」を見積もりに含めると、現実的なスケジュールになります。
実装者が一人（兼業）のとき
デザイナーとエンジニアが同じ人なら、Figmaとコードの同期はその日の終わりに5分やれば足りることが多いです。チームに分かれた瞬間に、変数一覧の共有が効いてくる。将来を見据えて、最初から名前を揃えておく投資は無駄になりにくいです。
補足
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。完璧なトークン設計を目指すより、今の案件で繰り返し使う色と余白から始め、名前を実装と揃えることを優先してください。小さく始めて運用で増やす方が、一度だけ巨大なデザインシステムを作って誰も使わない、という結末を避けやすいです。
Variablesは、デザインと実装の橋です。
綺麗さより再現性——Figmaではそこを優先しています。
まとめ
Figma Variablesは、デザインと実装のズレを減らすための「共通の名前と値の辞書」です。色とスペーシングから始め、セマンティック層と実装のCSS変数を揃える。全部一度にやらないのが続けるコツです。
次にやることは、今の案件ファイルで使っている色を5つだけ書き出し、Variablesのコレクションに移すこと。ボタン1つにバインドできれば、あとは同じパターンの繰り返しです。
