Figmaのデザイントークンを使えば、色・文字・余白の定義を1か所で管理し、デザインと実装のズレを防げます。Figma Variables機能と連携させることで、少人数のフリーランス案件でも破綻しない運用が実現します。この記事では設計・命名・JSON出力・開発渡しまでを5ステップで解説します。
▶ 3日で初案件PR
この記事でわかること
最小15〜20個のトークンで始めるフリーランス向け設計手順、命名規則と3ツールを使ったJSON連携フロー、5つの実務ハックによる長期運用の安定化方法を解説します。
今のデザインの仕事で、一番近い悩みは？
この記事の結論
Figmaのデザイントークンは「値に名前をつけて一元管理する仕組み」です。フリーランスが扱う規模なら最小15〜20個のトークンから始めるだけで十分です。Figma Variables機能を使って階層を設計し、JSONでエクスポートすれば開発者へ確実に値を渡せます。命名規則と更新フローを最初に決めておくことが、長期運用の唯一の鍵です。
今日やるべき1つ
Figmaを開いて新規コレクションを作成し、プロジェクトで使っている主要カラー3〜5色をVariablesに登録してください（所要時間15分）。
状況別ショートカット
| 状況 | 読むべきセクション | 所要時間 |
| デザイントークンが何か知りたい | Figmaデザイントークンは3層で構造化 | 3分 |
| 何から設計すればよいか迷っている | Figmaデザイントークン設計は優先15項目で開始 | 5分 |
| 命名規則で悩んでいる | デザイントークンの命名規則は用途ベースで統一 | 4分 |
| 自分の案件に合う運用規模を知りたい | フリーランスのトークン運用規模を3分で診断 | 3分 |
| JSON出力と開発連携を今すぐ実行したい | FigmaトークンのJSON連携は3ツールで完結 | 5分 |
| 実務ハックをまとめて確認したい | Figmaデザイントークン運用は5つの仕組みで安定 | 7分 |
Figmaデザイントークンは3層で構造化
デザイントークンとは「UIに使う具体的な値（色・文字サイズ・余白・角丸など）に意味のある名前をつけて管理する仕組み」です。#1A73E8という16進数カラーコードにcolor-brand-primaryという名前をつけることで、デザイナーも開発者もその値を同じ名前で参照できるようになります。3層の構造を理解することが、運用設計の出発点です。
プリミティブトークンは生の値を保持する最下層
プリミティブトークンは、意味を持たない純粋な値そのものです。blue-500: #1A73E8やfont-size-16: 16pxのように、「この色」「このサイズ」を記録するだけです。プリミティブトークンは辞書のような存在であり、それ単体では「どこに使うか」を語りません。フリーランス案件でも、カラーパレット全体をプリミティブとして定義しておくことで、後から意味付けを変更しやすくなります。
エイリアストークンはプリミティブへの参照で意味をつける中間層
エイリアストークンは、プリミティブトークンを参照して「用途」を付与します。color-primary: {blue-500}という形で、プリミティブの値を直接書かず参照記法で連結します。これによりblue-500の値を#2A84F8に変更するだけで、color-primaryを参照しているすべての箇所が自動更新されます。変更が1か所で完結するこの構造は、長期運用において修正作業を削減できると実務経験者から報告されています（Figmaの基本とデザイントークンについて）。
「バリアブルを参照で連結しておけば、ブランドカラーの変更がコンポーネント全体に即時反映される」という声もあります（Figmaの基本とデザイントークンについて）。
セマンティックトークンはコンポーネントの役割を語る最上層
セマンティックトークンは、UIの意味（セマンティクス）に対して名前をつけます。button-background-primary: {color-primary}やtext-body: {font-size-16}のように、コンポーネントや要素の役割そのものを名前に込めます。開発者が実装時に迷わないのは、この層が「どこにどの値を使うか」を明確に語るからです。小規模案件では3層すべてを厳密に分ける必要はなく、プリミティブとセマンティックの2層だけで運用するシンプルな構成でも十分機能します（「デザイントークン」の階層構造でUI設計を「標準化」する）。
FigmaのVariables機能がトークン管理の中心
FigmaのVariables機能は、コレクション（グループ）とバリアブル（個別の変数）の2階層でトークンを管理します。コレクションには「Primitives」「Semantics」のような名前をつけ、その中にバリアブルを作成します。型はColor・Number・String・Booleanの4種類があり、デザイントークンの大半はColorとNumberで対応できます。Variables機能はFigma Professional以上のプランで利用でき、スコープ機能（適用できるプロパティの制限）も提供されています（最終回 Figmaでデザイントークンを活用する）。
なお、デザイントークンの設計方針をFigma AIデザイン完全ガイド｜7機能で作業時間を半減する方法と組み合わせて検討すると、AI機能を使った初稿生成との連携もスムーズになります。
CHECK
▶ 今すぐやること: FigmaでVariablesパネルを開き、「Primitives」という名前のコレクションを1つ作成する（5分）
Q: FigmaのVariablesとデザイントークンは同じものですか？
A： 厳密には異なります。デザイントークンは設計上の概念であり、Figma Variablesはその概念をFigma内で実現するための機能です。VariablesはデザイントークンをFigma上で管理する手段の1つと理解してください。
Q： プリミティブ・エイリアス・セマンティックの3層は必ず作らないといけませんか？
A： 必須ではありません。小規模案件ではプリミティブとセマンティックの2層、あるいはセマンティックのみで運用するケースも一般的です。規模とチーム構成に応じて最適な層数を選んでください。
Figmaデザイントークン設計は優先15項目で開始
トークン設計で最初につまずく理由は、すべてをいきなり完璧に定義しようとするからです。最初に定義すべき項目は限られており、優先順に着手することで設計が加速します。
最初にトークン化すべきはカラーと文字サイズの2カテゴリ
実務上、最もコストパフォーマンスが高いトークン化はカラーと文字サイズです。カラーは変更頻度が高く、複数コンポーネントへの影響が大きいため、最初にトークン化することで修正作業を大幅に削減できます。文字サイズも同様で、Webプロジェクトでは本文・見出し・キャプションの3サイズを定義するだけで、デザインと実装の乖離を大幅に防げると報告されています。カラー変更をしたとき「どこに影響するか把握できない」という状況は、トークン化によって解消されます。
余白と角丸は2番目に着手するトークン
スペーシング（余白）と角丸（border-radius）は、UIの統一感に直結する値です。8px基準（4・8・12・16・24・32・48）のようなスケールを1つ定義しておくことで、実装側が「何pxにすればいいか」と毎回相談する手間がなくなります。フリーランス案件では、余白の統一だけで開発者との確認往復が削減されたという実務報告があります（共通言語としてのデザイントークンとFigmaでの運用）。
「スペーシングトークンを定義してから、開発との齟齬が目に見えて減った」という声もあります（共通言語としてのデザイントークンとFigmaでの運用）。
影・透明度・アニメーションは規模が大きくなってから追加
シャドウ（box-shadow）、不透明度（opacity）、アニメーション時間（duration）は、プロジェクト後期または2期以降に追加するトークンです。最初からすべて定義しようとすると、設計コストが増大する一方、使用頻度が低いトークンが増えてコレクションが煩雑になります。フリーランスの単独案件では、カラー10〜15個・文字サイズ5〜6個・スペーシング7〜9個の合計25〜30個からスタートし、必要に応じて追加する方針が最も現実的です。
ライトモードとダークモードの切り替えはVariablesのモード機能で管理
Figma Variablesのモード機能を使うと、同じトークン名に対して「Light」「Dark」2つの値を持たせられます。color-background: #FFFFFF（Light）とcolor-background: #1C1C1E（Dark）を同一バリアブルに設定することで、デザインフレームのモード切り替えだけで全コンポーネントの配色が切り替わります。この設定は初期段階から行うと後の改修コストが大きく下がります。ただし、モードを使う場合はセマンティックトークンが必須になるため、プリミティブとセマンティックの2層構成を先に確定させてください（最終回 Figmaでデザイントークンを活用する）。
また、Webデザイン配色は3色70-25-5%で決まる｜初心者が今日から使える実践手順を参考にカラートークンの値を設計すると、プリミティブ定義の作業がよりスムーズに進みます。
CHECK
▶ 今すぐやること: 自分のプロジェクトで使っているカラー一覧をスプレッドシートに書き出し、プリミティブとセマンティックに分類する（20分）
Q: 既存のFigmaデータを後からトークン化することはできますか？
A： できます。ただし、既存コンポーネントに直接入力されている色や文字サイズをVariablesに差し替える作業が必要です。コンポーネント数が多い場合は、最も使用頻度の高い値から優先的に変換していくと現実的です。
Q： いくつのトークンから始めるのが適切ですか？
A： フリーランスの単独案件では15〜30個が適切な出発点です。100個以上定義してから使い始めると、管理コストが設計メリットを上回るリスクがあります。
デザイントークンの命名規則は用途ベースで統一
命名規則は最初にルールを決めておくことで後の混乱を避けられます。実務ではいくつかの迷いパターンが繰り返されており、それぞれに対応した命名方式が存在します。
用途ベース命名は「何に使うか」を名前に込める方式
用途ベース命名とは、color-button-primary-backgroundのように「カテゴリ-コンポーネント-状態-プロパティ」という構造で命名する方式です。色の値そのもの（blue-500）ではなく、使う場所（button-primary-background）を名前にすることで、開発者が実装時に迷わなくなります。この命名方式を採用したプロジェクトでは、開発者への仕様確認コストが削減されたという実務報告があります（「Tokens Studio for Figma」を使用してデザイントークンを管理する）。
階層ベース命名は規模が大きいチーム向けの方式
階層ベース命名はglobal/color/blue/500のようにスラッシュで階層を表現する方式です。Figmaでは/区切りでグループ化して表示されるため、トークン数が多いプロジェクトでは視認性が上がります。フリーランスの単独案件やデザイナー1名+開発者1名の体制では、用途ベース命名の方が実装側に伝わりやすく、結果的に往復確認が少なくなります。
命名の禁止ルールは最初に決めて文書化する
実務で破綻しやすい命名パターンとして、色名をそのまま使うケース（red、blue）、連番を使うケース（color1、color2）、略語を混在させるケース（bgとbackgroundが混在）の3つが代表的です。これらはトークン数が増えると検索性が著しく低下します。命名禁止ルールをREADMEや共有ドキュメントに1ページ書いて関係者に共有することが、長期運用の前提です。
CHECK
▶ 今すぐやること: 自分のプロジェクト用の命名規則を「カテゴリ-コンポーネント-状態-プロパティ」形式で3例作成し、ドキュメントに記録する（15分）
Q: 英語と日本語、どちらで命名すべきですか？
A： 開発者と共有する前提では英語を推奨します。JSONとしてエクスポートした場合、日本語のトークン名はCSSやTypeScriptでの変数名として扱いづらく、変換処理が必要になるためです。
Q： 命名規則を途中で変えることはできますか？
A： 技術的には可能ですが、開発側がすでにトークン名を参照している場合は全箇所の更新が必要になります。変更時は開発者へ事前連絡し、マイグレーション手順を共有してください。
PR提供: 日本デザインスクール（デザスク）
フリーランスのトークン運用規模を3分で診断
以下の質問に答えることで、自分の案件に最適な運用方針が分かります。
Q1: プロジェクトのページ数・画面数は何画面ありますか？
10画面以下の場合はQ2へ、11画面以上の場合はQ3へ進んでください。
Q2（10画面以下）: デザイナーと開発者は1名ずつ以内ですか？
1名ずつ以内の場合はResult Aへ、2名以上いる場合はResult Bへ進んでください。
Q3（11画面以上）: ライトモードとダークモードの両方が必要ですか？
必要な場合はResult Cへ、不要な場合はResult Bへ進んでください。
Result A: 最小構成（15〜20トークン）で開始
カラー5〜8個、文字サイズ3〜4個、スペーシング5〜6個の2層構成（プリミティブ+セマンティック）で十分です。Tokens Studioは使わず、Figma Variablesのみで管理し、JSON出力はFigma公式のAPIまたは「Export Design Tokens」プラグインで対応します。
Result B: 標準構成（30〜50トークン）で開始
カラー10〜15個、文字サイズ5〜6個、スペーシング7〜9個、角丸3〜4個の3層構成が適切です。Figma Variablesで管理し、JSON出力後にStyle Dictionaryで変換するフローを組みます。
Result C: 拡張構成（50〜80トークン）にモードを追加
Result Bの構成にライト/ダークモードを加えます。Figma Variablesのモード機能でLight/Darkを設定し、Tokens StudioでGitHub連携する自動化フローが有効です。
CHECK
▶ 今すぐやること: 上記診断を実行して自分のResultを確認し、対応するトークン数の目標値をドキュメントに記録する（3分）
Q: 案件途中でトークン数を増やすことはできますか？
A： できます。ただし、増やしたトークンを既存コンポーネントへ適用するリファクタリング工数が発生します。フェーズ2以降の追加を事前にクライアントへ説明しておくことを推奨します。
Q： フリーランスの一人案件では3層構成は過剰ですか？
A： 10画面以下かつデザイナー自身が実装も担当する場合は過剰になる可能性があります。2層（プリミティブ+セマンティック）またはセマンティックのみのフラット構成で始めてください。
FigmaトークンのJSON連携は3ツールで完結
デザインで定義した値を開発者へ渡す手順は、3つのツールの役割を理解するだけで全体像が把握できます。
Tokens StudioはFigmaとJSON管理のブリッジとして使う
Tokens Studioは、Figmaのプラグインとして動作し、トークンをJSON形式で管理できるツールです。GUI上でトークン名・値・型を入力すると、内部でJSONが生成されます。GitHubやGitLabと連携する機能があり、トークン変更をコミットとして記録できるため、変更履歴の追跡が可能になります。Tokens StudioはFigma Variablesとは独立した管理になるため、両方を並行使用する場合は同期ワークフローの設計が必要です（「Tokens Studio for Figma」を使用してデザイントークンを管理する）。
Export Design TokensプラグインはFigma VariablesをJSONに変換する
Figma公式コミュニティで公開されているExport Design Tokensプラグインは、Figma Variables内のコレクションをW3C Design Tokens仕様に準拠したJSONとして出力します。設定不要で使い始められるため、まずローカルでJSON出力を試したい場合の最短手段です。出力されたJSONは{“color-brand-primary”: {“$value”: “#1A73E8”, “$type”: “color”}}のような構造になります。
Style DictionaryはJSONを実装用フォーマットに変換するCLIツール
Style Dictionaryは、Amazonが開発しオープンソースで公開しているCLIツールです。デザイントークンのJSONを入力として受け取り、CSS Variables・SCSS Variables・TypeScript定数などのフロントエンド実装用ファイルを出力します。style-dictionary buildコマンド1つで変換が完了し、出力フォーマットはconfigファイルで指定します。Style Dictionaryを導入することで、デザイナーがJSONを渡すだけで開発者がすぐに使えるフォーマットへ自動変換されるため、「どう実装に渡せばいいか分からない」という問題が解消されます。
フリーランスの推奨フローは3段階で運用する
まずFigma Variablesでトークンを定義します（第1段階）。次に「Export Design Tokens」プラグインでJSONを書き出します（第2段階）。最後にJSONをStyle Dictionaryでフロントエンド用フォーマットへ変換し、開発者へ渡します（第3段階）。このフローで手作業は第2段階のプラグイン実行のみとなり、変更のたびにコピー&ペーストが発生しない設計になります。GitHubを介した自動化（Tokens Studio + GitHub Actions + Style Dictionary）は規模が大きくなってから導入してください。最初から自動化しようとすると、設定に費やす時間が実務運用の想定を大きく上回りがちです。
なお、開発者へのファイル受け渡しには大容量ファイル送る無料|8つの方法で即日解決で紹介されているツールを活用すると、大きなアセットバンドルもスムーズに共有できます。
CHECK
▶ 今すぐやること: 「Export Design Tokens」プラグインをFigmaにインストールし、テスト用コレクションのJSONを出力して中身を確認する（10分）
Q: Style DictionaryはNode.jsの知識がないと使えませんか？
A： 基本的な使い方はNode.jsのインストールとnpx実行のみなので、コマンドライン操作に慣れていれば問題ありません。デザイナーがCLIを使いたくない場合は、開発者にconfigだけ渡して変換を依頼する運用が現実的です。
Q： JSONのトークン名と実装のCSS変数名が変わってしまいます。
A: Style Dictionaryのtransformsとformatsで変換ルールを設定することで対応できます。color-brand-primaryをCSS変数–color-brand-primaryに変換する設定をconfigファイルに記述します。
Figmaデザイントークン運用は5つの仕組みで安定
実務で破綻しないトークン運用のために、フリーランスが知っておくべき具体的なハックを5つ紹介します。
ハック1: 例外値直接指定禁止ルールでトークン逸脱ゼロを実現
【対象】: デザイン修正のたびに例外カラーや例外サイズが増えてしまうフリーランスデザイナー
【手順】: まず「Variablesに存在しない値は使用禁止」というルールをプロジェクト開始時に文書化します（10分）。次にFigma内でローカルスタイルを新たに追加する際は、必ずVariablesへの登録を先に行うフローを設定します（5分）。月1回、コンポーネントをスキャンして直接指定値が混入していないか確認し、発見した場合は即座にVariablesへ置き換えます（30分）。
【コツと理由】: 「例外は都度判断する」という運用では、例外値が1つ許容された瞬間に「これくらいなら」という暗黙の基準が崩れます。3ヶ月後には例外が全体の相当割合を占めることが多く、長期的なメンテナンスコストが上がります。「Variablesにあるものから選ぶ」という選択の流れ自体を設計することで、例外が生まれる余地を物理的に減らせます。
【注意点】: 新しいUIパターンが登場したときにVariablesへの登録が遅延してデザインが止まるケースがあります。「未登録の場合は仮値として#TEMPプレフィックスを使い、翌営業日に正式登録する」というバッファルールも合わせて設定してください。
ハック2: 変更影響チェックフローで修正漏れをゼロに
【対象】: トークン値を変えたとき、どこに影響が出るか把握できずに修正漏れが発生するデザイナー
【手順】: 変更前に変更対象のVariablesを「コレクションで右クリック → 参照箇所を確認」して影響範囲を把握します（5分）。影響するコンポーネントをFigmaのページ一覧でリストアップし、変更前後でスクリーンショットを保存します（10分）。変更後に開発者へ「変更したトークン名・旧値・新値・影響コンポーネント一覧」をSlackまたはNotionで共有します（5分）。
【コツと理由】: 変更後の問題は開発ビルド後に発覚することが多く、その時点での修正は工数が増大します。変更前の5分で影響範囲を可視化することが、変更後の多大な修正コストを防ぎます。
【注意点】: Figmaの「参照箇所を確認」機能は現在のページのみ対象です。複数ページにまたがる場合は手動での確認が必要なため、ページ構成をシンプルに保つ設計が根本的な対策になります。
ハック3: 初回取引時のトークン共有テンプレートで認識ズレを防止
【対象】: 新規クライアントや初めて組む開発者にデザイントークンを説明するのに時間がかかるフリーランス
【手順】: 「トークン名・型・値・使用箇所の例」の4列を持つスプレッドシートを用意し、エクスポートJSONと併用します（15分）。初回打ち合わせで「このトークン名でデザインと実装を統一します」と宣言し、合意を取り付けます（5分）。変更が生じた場合は、スプレッドシートとFigma Variablesとエクスポートしたファイルの3点をセットで更新します（都度）。
【コツと理由】: 開発者にとってJSONは実装には使えますが、「なぜこの値か」を把握するには不向きです。人間が読めるスプレッドシートと機械が読めるJSONの2点セットで渡す方が、開発者からの確認質問が大幅に減ります。スプレッドシートは意図を、JSONは値を、それぞれ担当するという分業設計が機能する理由です。
【注意点】: スプレッドシートとJSONの二重管理は更新漏れリスクを生みます。「Figmaを更新したら必ずエクスポートとスプレッドシートも更新する」という1セット運用ルールを設定してください。
ハック4: トークン優先UIデザインで後からのリファクタリングをゼロに
【対象】: 新規デザイン時にフリーハンドで値を入力してしまい、後からトークン置き換えが発生するデザイナー
【手順】: 新しいUIを作るとき、まずVariablesコレクションを開いて「使える値があるか」を最初に確認します（2分）。既存のトークンで対応できる場合は必ずトークンを適用し、対応できない場合は先にVariablesへ追加登録します（5〜10分）。デザインレビュー前にコンポーネントを選択して「Applied Variables」一覧に空欄がないことを確認します（5分）。
【コツと理由】: デザイン後にトークンを付与しようとすると、値の近い別トークンとの選択で迷いが生じ、結果的に「とりあえず直接入力」が発生します。デザインの起点をトークン選択に置くことで、この迷いを構造的に除去できます。
【注意点】: Variablesに登録されていない値が本当に必要な新しいパターンの場合、「登録待ち」でデザインが止まることがあります。前述のバッファルール（#TEMPプレフィックス）を適用し、翌日に正式登録する運用で対応してください。
ハック5: 小規模案件向け最小トークンテンプレートで設計時間を短縮
【対象】: 毎回ゼロからトークン設計をしていて、プロジェクト初期に2〜3日を費やしてしまうフリーランス
【手順】: 過去案件から「ほぼ毎回使う」トークン20〜25個を抽出し、テンプレートFigmaファイルとして保存します（60分・初回のみ）。新規案件開始時にテンプレートファイルを複製し、クライアントのブランドカラーと文字仕様へ値だけ書き換えます（30分）。案件固有の追加トークンが生まれた場合は、テンプレートに反映するかを都度判断してテンプレートを育てます（都度5分）。
【コツと理由】: 色・文字サイズ・スペーシングのスケールは案件が変わっても構造が同じであり、変わるのは具体的な値だけです。構造と値を分離して考えることで、構造部分のテンプレート化が可能になります。コアトークン20個は案件をまたいで再利用できるため、設計時間の短縮につながります。
【注意点】: テンプレートをそのまま流用すると、前案件の命名規則がそのまま引き継がれることがあります。複製後に「コレクション名とプロジェクト固有のプレフィックス」を必ず書き換えてください。
このような作業効率化の仕組み全般については、作業効率上げる方法|フリーランスが5つの仕組みで時間を30%削減も合わせて参考にしてください。
CHECK
▶ 今すぐやること: 5つのハックの中で自分が最も課題と感じているものを1つ選び、今週中に手順の第1ステップだけ実行する（選択5分、実行は各ハックの所要時間参照）
Q: Tokens StudioとFigma Variablesのどちらを使えばよいですか？
A： 小〜中規模案件ではFigma Variablesのみで十分です。GitHubとの連携やバージョン管理が必要な大規模・長期案件ではTokens Studioの追加が有効です。
Q： トークン運用を始めた後、クライアントへはどう説明しますか？
A： 「デザインの値を一元管理することで、リニューアル時の変更コストを削減できます」という工数メリットで説明すると受け入れられやすいです。抽象的なシステム設計の話より、具体的な時間削減で伝えることを推奨します。
Figmaデザイントークンは最小20個から始める
Figmaのデザイントークンは、最小20個のVariablesから始めてフロー確立後に拡張することが、フリーランスにとって最も現実的な導入戦略です。プリミティブとセマンティックの2層構成で設計し、命名規則を最初に文書化することが長期運用の前提になります。JSON出力はExport Design TokensプラグインとStyle Dictionaryを組み合わせることで、手作業なしに開発へ値を渡せる仕組みが完成します。
デザイントークンは「使いながら育てるもの」です。今日カラー5色をVariablesに登録することが、1年後に破綻しない運用の起点になります。
| 状況 | 次の一歩 | 所要時間 |
| まだVariablesを触ったことがない | カラー5色をコレクションに登録する | 15分 |
| Variablesは使っているが構造が曖昧 | プリミティブとセマンティックに分類し直す | 30〜60分 |
| JSON出力を試したことがない | Export Design Tokensプラグインで出力する | 10分 |
| 開発者への渡し方が分からない | スプレッドシート+JSONの2点セットを作る | 20分 |
| 案件ごとに設計し直している | テンプレートFigmaファイルを作成する | 60分 |
Figmaデザイントークンに関するよくある質問
Q: FigmaのFreeプランでもデザイントークンは使えますか？
A： Figma Variablesは、Professionalプラン以上で利用可能です（2025年時点）。Freeプランではカラー・テキスト・エフェクトのローカルスタイルとして管理することになります。Variablesほど柔軟な参照連結はできませんが、スタイル機能でも基本的な一元管理は実現できます。
Q： Figma Variablesで管理したトークンをReactやVue.jsの実装に使うにはどうすればよいですか？
A： Export Design TokensプラグインでJSONを出力し、Style Dictionaryを使ってCSS Variables・TypeScript定数・SCSS変数のいずれかへ変換します。ReactやVue.jsでCSS Variablesを読み込む実装にすることで、デザイントークンの値を直接スタイルとして参照できます。
Q： デザイントークンとデザインシステムはどう違いますか？
A： デザイントークンはデザインシステムを構成する要素の1つです。デザインシステムは、トークン・コンポーネント・ドキュメント・運用プロセスを含む包括的な仕組みです。フリーランスの案件規模では多くの場合、デザイントークンと再利用コンポーネントの2要素で十分なシステムとして機能します。
Q： Tokens Studioは無料で使えますか？
A： 基本的な機能は無料で利用できます。GitHub・GitLab・Azure DevOpsとの同期機能（Sync）はProプラン（有料）が必要です。フリーランスの単独案件でGitHub連携が不要であれば、無料プランで十分です。
【出典・参照元】
Figmaの基本とデザイントークンについて – Figma Variablesの実務的な活用メモ
「デザイントークン」の階層構造でUI設計を「標準化」する – 階層構造と命名規則の解説
最終回 Figmaでデザイントークンを活用する – Variables活用と実装連携の実践解説
共通言語としてのデザイントークンとFigmaでの運用 – Figma運用とJSON連携の発表資料
「Tokens Studio for Figma」を使用してデザイントークンを管理する – Tokens Studioでのトークン作成・適用手順
Export Design Tokens – Figma Community – Figma公式コミュニティのエクスポートプラグイン