こんにちは、UI/UXデザイナーの新井です。

突然ですが、デザインシステム構築の工程で、Variables（変数）の定義と登録って皆さんはどうされていますか？

 色、数値、スペースの命名規則に悩み、それをFigmaにひたすら入力していく。作業量が多い割に、後戻りも発生しやすい。できる限り自動化したくなる領域だと思います。

そこで「何とか自動化できないかな…」と思い、生成AI機能「Figma Make」と最新LLM（GPT-5.2）を組み合わせて、既存デザインから「整理されたVariables」を半自動で生成し、Figmaへ登録する流れを検証してみました。

結論として、WebサイトのTOPページのデザイン（画像またはFigmaデータ）があれば、Tailwind CSSの規則に寄せたVariablesを生成・整形し、さらに色味の補正やスペーシングの規格化といった“リファクタリング”までAIに任せることができました。
ゼロイチの新規開発だけでなく、既存プロダクトの運用改善にも効くアプローチになりそうです。

今回の検証環境と、解決したい課題は以下です。

デザインカンプはあるがVariablesが未定義。後付けでシステム化したい。ただし、独自ルールを増やすより、標準的なTailwind CSSの規則に則って整理したい。

最初に、AIに「デザインシステムの構造」を宣言します。ここで重要なのは、Primitive（原始的な値）とSemantic（意味的な値）を分けることです。

• Primitive：Blue-500、Spacing-4 のような基礎値
• Semantic：Button-bg、Text-primary のような用途値

この交通整理をしておかないと、AIは「Blue」と「Button-Blue」を混在させて出力しがちで、後から直すコストが増えます。この段階で、出力構造の方向性を固定できると、以降の調整がかなり楽になります。

特に指示しなかったのですが、プレビュー用の管理画面も生成されました！
※実験モデルである「Gemini3」でも試したのですが、こちらはJSONコードのみが生成されました。

抽出された色やスペースを見ていくと、微妙に数値がズレていたり、階調の色相が揺れていたりと、運用フェーズで“じわじわ効いてくる”乱れが混ざっていることがあります。
今回はこれを人力ではなくAIに「ルールに寄せて整頓する」役割を持たせました。

抽出された青が、階調ごとに色相がブレていたり、ややくすんで見えるケースがあったのでFigma Makeに調整を依頼しました。

AI側の作業としては、色相の揺れを抑えつつ、50〜950の階調として扱いやすい分布に再配置する、という形になります。ここを揃えると、UI全体の統一感が上がり、後からコンポーネントを増やす時の破綻が減ります。

「15px」「92px」など、特に意図されていない余白が混在していたので、Tailwindのルールに寄せてFigma Makeに調整をお願いしました。

不規則なものを規則化する場合は、「Tailwind基準に寄せる」など基準を予め決めると判断が速いです。AIはここで迷いにくく、整頓係として機能します。

Variablesが整ったら、次に「その変数を使ってコンポーネントを揃える」段階に進みます。
今回は検証として、Tailwind UIのApplication UI相当のカテゴリ（Buttons / Forms / Navigation / Feedback / Overlaysなど）を幅広くカバーするようFigma Makeに依頼しました。

最後に、生成・修正したトークンをFigmaへ登録します。今回の結論としては、Figmaの標準インポート機能に完全準拠したDTCG形式で出力できれば、プラグイン無しでも安定してインポートできました。

※Figmaに取り込む際は、最終的にDTCG JSONとして出力してインポートします（TS化はプロジェクト側の管理都合です）

• /design-tokens/tokens.json を削除し、/design-tokens/tokens.ts に変換（TypeScriptとしてエクスポート）
  • DTCG仕様に準拠した厳格フォーマットでデータ生成
  • colorはオブジェクト形式（colorSpace, components, alpha, hex）
  • dimensionもオブジェクト形式（value, unit）
  • fontFamilyは単一フォント名
  • 参照（alias）はスラッシュ区切り
  • shadowトークンは除外

• DesignTokenViewer.tsx のインポートパスを修正

FigmaのVariablesウィンドウにある「Import variables」機能は、DTCG形式でのJSON読み込みが可能です。 ここでポイントなのがJSONの階層構造です。今回はルートキーに primitive や semantic を置くことで、インポート時にVariables内でトップレベルのグループとして分類されるようにしました。 （※コレクション自体を分けたい場合は、ファイルを分割して個別にインポートするか、インポート後に手動で移動させるのが確実です）

また、color や dimension の表現形式が合っていないと特定の型だけ読み込めないことがあるため、今回は以下のようにオブジェクト形式に固定しています。

{
  "primitive": { // ← このキーがFigma上の第1階層（グループ）になります
    "color": {
      "blue": {
        "500": {
          "$type": "color",
          "$value": {
            "colorSpace": "srgb",
            "components": [0.231372549, 0.509803922, 0.964705882],
            "alpha": 1,
            "hex": "#3B82F6"
          }
        }
      }
    },
    "dimension": { ... }
  }
}

Variables Importは、検証・切り分けのためのフォールバックとして有用です。インポートが詰まったときに、未対応型や表現形式の違いを早く見つける用途で使えます。
ただし最終的には、標準インポート機能で安定して通る形式に寄せられたため、運用の中心は標準インポート機能に置く方がシンプルでした。

• color の $value は必ずオブジェクト形式（colorSpace / components[0-1] / alpha / hex）にする。#RRGGBB や rgba(...) の文字列は使わない。
• dimension は { "value": 数値, "unit": "px" } のみ（"16px" のような文字列は使わない）。
  • ※補足： Tailwind CSSの実装では rem 単位や単なる係数（number）を使いますが、Figmaのキャンバス上で正しくサイズを反映させるため、今回はあえて px 単位の dimension として定義しています。
• aliasは {...} 形式で、パス区切りは / に統一する（. 区切りは避ける）。

今回のように、取り込み先の仕様が厳格で、かつ「一部の型だけ落ちる」現象が起きるケースでは、「1回の修正で当てにいく」方式だと外しやすく、時間を溶かしがちです。ここで役に立ったのが、GPT-5.2を“修正係”としてではなく、切り分けの設計役として使う進め方でした。

エラー文は一見すると情報量が多いのですが、実際に効いていた論点は「未対応トークン型が混ざっている」「colorやdimensionの表現形式が仕様とズレている」「参照パスの区切りが合っていない」のように、少数に収束しました。
原因を圧縮できると、修正の優先順位が決まり、試行が速くなります。

今回は、同じゴール（標準インポート機能で落とさず入る）に対して、原因仮説ごとに出力を枝分かれで用意し、試す順番を固定しました。

• 最小変更で通す版（未対応型の除外、命名の整理）
• 表現形式を仕様に寄せる版（color/dimensionをオブジェクト化、aliasを/へ）
• 参照を実値に解決する保険版（参照解決が怪しい場合の切り分け）

この順序で進めると、失敗しても必ず切り分けが前に進み、短いサイクルで「どの制約が効いているか」を特定できます。

最終的に「標準インポート機能で通る仕様」が分かった時点で、次に必要なのは“二度と同じ罠に落ちないこと”です。
そこで、使う $type の範囲、color/dimensionの表現形式、aliasの区切り、shadow除外といった条件を生成ルールとして明文化し、Figma Make側の出力も安定させました。

この形にしておくと、次回以降は「生成→インポート→微調整」に集中でき、デバッグに時間を取られにくくなります。GPT-5.2は、修正作業そのものよりも、こうした切り分けと運用ルール化の部分で効果が出やすいと感じました。

AIを単なる抽出ツールとして使うのはもったいないです。
「ばらつきを揃える」「標準規格に寄せる」「重複を統合する」といったリファクタリングの指示を出すと、元データよりも運用しやすい設計に近づきます。

後から分けると、名称も参照も崩れていきます。最初のプロンプトで構造を固定し、AIの出力癖を抑えるのが効きました。

コンポーネントを作ることよりも、揃った変数にリンクし続けることが重要でした。土台が整っていると、展開が速く、破綻しにくいです。

ここまでの内容は、Variablesを整えてFigmaに取り込むところまででした。
ただ、Variablesを“作れる”だけでは成果になりません。実務で価値が出るのは、それがチームや案件の中で「合意形成」「品質担保」「運用」に効くときです。そこで最後に、Tailwindで直接実装できる前提を踏まえつつ、今回のフローをあえてFigmaで回す意義を整理します。

結論、TailwindだけでもUIは作れます。
ただ、案件で効いてくるのは「作る」以外の領域、つまり合意形成・品質担保・運用です。Figmaを用意する意味はここにあります。

• 合意形成の速度
  コードは完成形の議論に寄りがちです。Figma上にトークンとコンポーネントがあると、仕様・見た目・状態（hover/disabled/emptyなど）を同じ画面で確認でき、意思決定が速くなります。  
• 仕様の抜け検出（後戻り削減）
  実装が進んでから「この状態が必要だった」「この文言の長さで崩れる」などが出ると手戻りが重い。Figmaで状態を揃えておくと、抜けを早めに潰せます。  
• 品質の説明可能性
  非エンジニアが関わる局面では、コードだけだと品質の根拠が共有しにくい。Variablesとコンポーネントは「このUIはこのルールで一貫している」という根拠になります。  
• 実装との接続点
  Code Connectやトークン運用（Variables ↔ CSS/TS）を前提にすると、Figmaは“飾り”ではなくUI仕様の契約面になり、実装とデザインの距離が縮まります。

Tailwindは“作る力”が強い一方、Figmaは“揃える力・合意する力・保つ力”が強いと感じます。リードタイム短縮や後戻り削減が重要な案件ほど、Figmaの価値が出やすいと感じました。

デザインシステムをFigmaで起こす目的は、見た目の統一だけではありません。
属人性を減らし、変更に強い状態を作ることが本質です。

• 属人化の解消（引き継ぎ・増員に強い）
  “頭の中のルール”をVariablesとコンポーネントにして外に出す。チームが変わっても品質が落ちにくくなります。
• 設計の再利用（毎回ゼロから議論しない）
  Primitive（値）とSemantic（意味）が分かれていると、「値を変える」と「意味を変える」の議論が分離でき、影響範囲が読みやすい。
• レビューが設計レビューになる
  好みの議論ではなく「ルールに沿っているか」の議論に寄せられ、品質が安定します。
• プロセス可視化とフィードバックの取りやすさ
  顧客と“どこが決まっていて、どこが未決か”を共有しやすい。AIを併用すれば速度は上がり、判断は人間が握れます。

Figma MakeとLLMを組み合わせると、Variables構築という単純作業の削減だけでなく、標準化と品質向上（整頓・リファクタリング）まで同時に進められることが分かりました。

特に、既存デザインがあるのにシステム化されていないプロジェクトでは、今回の「逆生成 → リファクタリング → インポート」の流れが効きます。
AIは整頓と生成に強く、人は判断と合意形成に強い。この分業を成立させる場として、FigmaのVariablesは実務上の価値が出やすいと感じました。