Figmaのバリアントを使うと、ボタンの通常・ホバー・無効状態を1つのコンポーネントセットで管理でき、インスタンス切り替えにかかる時間を削減できます。公式ヘルプに基づく最新手順と、フリーランス案件で即使える命名ルールを解説します。
▶ 3日で初案件PR
この記事でわかること
コンポーネント化→プロパティ追加→命名固定の3ステップでバリアントを設定する手順、プロパティ名を「State / Size / Type」に統一してチームでも崩れない命名ルール、フリーランス案件でボタン1種類から始めて3週間で主要UI8種を整備する進め方。
今の仕事について、一番近いものは？
この記事の結論
FigmaのバリアントはコンポーネントをまとめてUI状態を一元管理する機能です。先にコンポーネント化してからバリアントを追加し、プロパティ名を「State / Size / Type」などの短い英語で統一すれば、チームでも崩れない設計が実現します。フリーランス案件でも、ボタン1種類から始めて横展開するだけで、デザインシステム構築の土台が3時間以内に整います。
今日やるべき1つ
既存のボタンコンポーネントを1つ選び、右サイドバーの「プロパティ」から「バリアント」を追加して「State」プロパティに「default / hover / disabled」の3値を設定する（所要時間：30分）。
状況別ショートカット
| 状況 | 読むべきセクション | 所要時間 |
| バリアントとコンポーネントの違いを整理したい | Figmaバリアントは状態差分を1セットで管理 | 3分 |
| 作成手順を今すぐ確認したい | Figmaバリアントは5ステップで作成完了 | 5分 |
| 自分の状況に合った設計方法を知りたい | Figmaバリアント設計は3パターンで判断 | 3分 |
| 命名ルールや失敗を避けたい | Figmaバリアントは命名ルール3原則で崩れない | 4分 |
| 実際の失敗例と成功例を参考にしたい | Figmaバリアント実践は2事例で設計が変わる | 4分 |
| 管理ミスを今すぐ防ぎたい | Figmaバリアントは5つの仕組みで管理を自動化 | 5分 |
| プロトタイプとの連携を知りたい | Figmaバリアントはプロトタイプと2段階で連携 | 3分 |
Figmaバリアントは状態差分を1セットで管理
コンポーネントとバリアントは似た言葉が並ぶため、使い分けに戸惑うことがあります。ここでは両者の役割の違いと、バリアントが解決する具体的な問題を整理します。
バリアントはコンポーネントの状態違いをまとめる仕組み
バリアントとは、1つのコンポーネントに対して複数のバリエーションを持たせる機能です（Figma公式ヘルプ：バリアントの作成と使用）。「通常ボタン」「ホバーボタン」「無効ボタン」を別々のコンポーネントとして管理していた場合、名前の統一や配置管理で毎回一定の作業が発生します。バリアントを使うと、これらを1つのコンポーネントセットに収納でき、インスタンス側のサイドバーから値を選ぶだけで切り替えられます。UI状態の管理コストが構造的に削減される設計になっています。
コンポーネントセットはバリアントの入れ物
コンポーネントセットとは、複数のバリアントをまとめて収納するグループのことです。ライブラリから「ボタン」をドラッグしてキャンバスに配置したとき、右サイドバーに「State」や「Size」といったプロパティが表示されるのは、その実体がコンポーネントセットになっているからです。バリアントは単体では機能せず、必ずコンポーネントセットの中に存在します。コンポーネントセット名がライブラリでの検索キーになるため、設計段階で名前を確定させておくと後から混乱しません。
バリアント追加はコンポーネント化が前提
バリアントはコンポーネントにしか追加できません。この前提を知らずに操作すると「バリアント追加ボタンが表示されない」という問題が必ず発生します。レイヤーパネルでフレームやグループを選択している状態では追加できないため、まず対象レイヤーを選択して「コンポーネントを作成」（Mac: Option+Command+K、Windows: Alt+Ctrl+K）を実行してからバリアント追加に進む順序が必須です。フリーランス案件でWebデザイナーとして活動する際に初めてバリアントを設定する場面で最も多いつまずきがこの手順の前後間違いです。コンポーネント化の確認が、全作業の中で最初に行うべき唯一のチェックポイントです。
インスタンスとメインコンポーネントの役割分担
メインコンポーネントはコンポーネントセット内で定義を持つ元データで、キャンバスに配置されるのはその複製であるインスタンスです。インスタンス側ではバリアントの値を切り替えられますが、形状やスタイルの変更はできません。形状を変えたい場合はメインコンポーネントを編集します。この役割分担を理解することで、「インスタンスを変更したら全部変わった」「思った箇所が変更できない」といった混乱が解消されます。
見落としがちな「変更の方向」
メインコンポーネントへの変更はすべてのインスタンスに伝播しますが、インスタンス側でのプロパティ値変更はそのインスタンスにのみ適用されます。この非対称の動きを知らないまま使うと、特定の画面だけ意図しない状態で表示されるトラブルが起きます。デザインシステムの更新作業では、変更をメインコンポーネントに加えるか・インスタンスに加えるかを意識的に選択する習慣が、運用ミスを防ぐ上で直接的に効いてきます。
CHECK
▶ 今すぐやること: 現在のFigmaファイルを開き、バリアントを付けたいUIが既にコンポーネント化されているかをレイヤーパネルで確認する（5分）
Q: コンポーネントとバリアントはどう使い分けますか？
A： コンポーネントは「再利用可能な部品を作る概念」、バリアントは「その部品に状態の違いを持たせる機能」です。ボタン1つに通常・ホバー・無効の3状態が必要なら、コンポーネントを先に作り、そこにバリアントを追加する流れになります。
Q： バリアントを使わないとどんな問題が起きますか？
A： 状態ごとにコンポーネントが増え続けるため、ライブラリが肥大化して目的のコンポーネントを探す時間が増えます。命名規則が崩れると、チームで共有したときにどのコンポーネントがどの状態かが判別できなくなります。
Figmaバリアントは5ステップで作成完了
バリアントの追加操作は5つのステップに整理でき、最初の1つ目のUIであれば30分以内に完成します。手順の全体像を把握してから着手すると、途中で詰まるポイントを事前に回避できます。
ステップ1〜2：コンポーネント化とバリアント追加
対象のレイヤーを選択し、右クリックメニューから「コンポーネントを作成」を実行します（または前述のショートカット）。コンポーネントになったことをレイヤーパネルの菱形アイコンで確認したら、右サイドバーの「プロパティ」セクションにある「＋」ボタンをクリックして「バリアント」を選択します。この時点でコンポーネントセットが生成され、デフォルトで2つのバリアントが並んだ状態になります。コンポーネント化前に「バリアント」オプションが表示されない場合は、フレームやグループが選択されている可能性があるため、レイヤーパネルの菱形アイコンの有無を最初に確認してください。
ステップ3：プロパティ名と値の設定
コンポーネントセットを選択した状態で右サイドバーを確認すると、「Property 1」という初期プロパティ名が表示されます。これを「State」などの意味が明確な名前に変更します。続いて各バリアントをクリックすると右サイドバーに値欄が表示されるため、「default」「hover」「disabled」など実態に合う語を入力します。プロパティ名と値は後から変更できますが、インスタンスがすでにキャンバスに配置されている状態で変更すると設定が初期化されるケースがあるため、初期設定の時点で確定させてください。
ステップ4：各バリアントのスタイル編集
バリアントを追加しただけでは見た目は同じです。それぞれのバリアントを選択して、色・不透明度・ボーダーなどを状態に合わせて変更します。hoverバリアントでは背景色を暗くし、disabledバリアントでは不透明度を下げるといった差分を付けます。見た目の差分を付けずにプロパティ値だけ変更しても、インスタンス側で切り替えた結果が視認できないため、プロパティ値の変更と見た目の変更を同時に完了させることが、設定ミスを防ぐ最短の方法です。
ステップ5：インスタンス配置と切り替え確認
キャンバスの別フレームにインスタンスを配置し、右サイドバーで「State」の値を切り替えて見た目が変わるかを確認します（Figma公式ヘルプ：バリアントの作成と使用）。切り替えができない場合は、インスタンスではなくメインコンポーネント自体を選択している可能性があります。レイヤーパネルで「インスタンス」と表示されているかを確認することで即座に判別できます。切り替え確認まで完了して初めてバリアント設定は完成と判断できます。
CHECK
▶ 今すぐやること: ボタンコンポーネント1つにStateプロパティを追加し、default・hover・disabledの3値を設定して切り替えを確認する（30分）
Q: バリアント追加後に「切り替えができない」場合の原因は何ですか？
A： 最も多い原因は「コンポーネントではなくフレームを選択している」ことです。レイヤーパネルで菱形アイコンの有無を確認してください。次に多い原因はプロパティ値が空白のままになっているケースです。右サイドバーで各バリアントの値が正しく入力されているかを確認します。
Q： バリアントは後から増やせますか？
A： 増やせます。コンポーネントセットを選択した状態で右サイドバーの「＋」からバリアントを追加できます。ただし既存のインスタンスには新しいプロパティが即座に反映されないため、追加後はインスタンス側のサイドバーで値を手動で確認してください。
Figmaバリアント設計は3パターンで判断
バリアントの設計範囲はプロジェクトの規模と運用形態によって最適解が変わります。以下の診断で自分に合うパターンを3分で把握できます。
Q1: デザインファイルを複数人で共有・編集しますか？
Yesの場合はQ2へ進んでください。Noの場合（自分1人のみ）はResult A（シンプル設計）が該当します。
Q2: プロジェクトの想定期間は3ヶ月以上ですか？
Yesの場合はResult C（フルシステム設計）が該当します。Noの場合はResult B（チーム最小設計）が該当します。
Result A：シンプル設計（1人・短期案件向け）
State（default / hover / disabled）の1プロパティのみに絞ります。バリアント数は3〜5つが上限の目安です。必要以上に作り込むとメンテナンスコストが上がるため、案件の納期内に使いきれる範囲で設計します。対象UIを1つ選んでStateプロパティのみで設定を完成させてください（所要時間：30分）。
Result B：チーム最小設計（複数人・短期案件向け）
Stateに加えてSize（small / medium / large）を追加し、命名規則をチームで1つのドキュメントに明文化します。バリアント数は最大12個（3状態×4サイズ）を上限として、それ以上は別コンポーネントに分割することをチームで合意します。命名規則ドキュメントを作成してチームに共有してください（所要時間：1時間）。
Result C：フルシステム設計（複数人・長期案件向け）
State / Size / Typeの3プロパティを設計し、コンポーネントセット名をライブラリ検索に最適化します。バリアント数が20を超えるコンポーネントはセット分割を検討します。対象コンポーネントの一覧をスプレッドシートで整理して優先順位を付けてください（所要時間：2時間）。フリーランスとして複数の案件で作業効率を高める観点からも、設計規模を最初に決めておくことが重要です。
CHECK
▶ 今すぐやること: 上記Q1〜Q2に答えて自分のResultを確認し、今日の作業量を30分・1時間・2時間のいずれかに確定させる（3分）
Q: バリアントのプロパティは何個まで追加できますか？
A： Figmaの仕様上の上限は設定されていませんが、実務上は3〜4プロパティが管理しやすい限界です。プロパティが増えると組み合わせが急増するため、5プロパティ以上で組み合わせが膨大になる場合は設計を見直すサインです。
Q： 1人作業でもバリアントを使う意味はありますか？
A： あります。バリアントがないとUIの状態が増えるたびに類似コンポーネントが増殖し、後からプロトタイプを作るときに正しいコンポーネントを探す時間が増えます。状態が3種類以上あるUIにはバリアントを使うと、6ヶ月後の自分が迷わない設計になります。
Figmaバリアントは命名ルール3原則で崩れない
追加するたびにプロパティ名がバラバラになる問題は、フリーランスがチーム案件に入ったときに特に顕在化します。命名が崩れると、ライブラリを使う側が正しいバリアントを探せなくなるため、受け取り側の作業時間が増えます。
原則1：プロパティ名は英語・先頭大文字で統一
プロパティ名は「State」「Size」「Type」のように、意味が明確な英語1語を先頭大文字で使います。日本語や混在表記（「状態」「state」「STATE」）が混ざると、ライブラリで検索したときにヒットしない・表示順が崩れるといった問題が起きます。英語統一は見た目の問題ではなく、機能的な正確性の問題です。命名ルールの崩れは審美的な問題ではなく、チーム全員の作業時間に直結するコスト問題として扱うべきです。
フリーランスのWebデザイナーが「プロパティ名を日本語にしていたら、他のデザイナーがどのバリアントを使えばいいかわからなくなった」と報告するケースが実際に起きています（【Figma】コンポーネントの使い方解説2 | バリアント編）。
原則2：値は小文字・スラッシュ区切りなし
プロパティの値は「default」「hover」「disabled」「focused」「loading」のように、すべて小文字で記述します。「Hover」「HOVER」「hover状態」といった表記ゆれは、ライブラリ利用時に同じ値として認識されない場合があります。値の語数は1〜2語にとどめます。「button-primary-default」のように長くすると選択UIで切れて判別できなくなります。短くて意味が通る語を選ぶことが、ライブラリを長期的に使いやすく保つ条件です。
原則3：コンポーネントセット名でグループを表す
コンポーネントセット名は「Button/Primary」「Input/Text」のようにスラッシュで階層を表します（スラッシュ前後のスペースなしで統一）。スラッシュ階層はFigmaのアセットパネルで自動的にグループ化されるため、「Button」と入力するだけでPrimary・Secondary・Ghostが一覧で確認できる状態になります。スラッシュを使わないとすべてのコンポーネントがフラットに並び、ライブラリが大きくなるほど目的のコンポーネントを探すコストが上がります。フリーランスが納品するファイルでは、発注先チームが今後使い続けることを前提に、スラッシュ階層を必ず設定してください。
CHECK
▶ 今すぐやること: 既存ファイルのコンポーネントパネルを開き、プロパティ名の表記ゆれが1つでもあれば今日中に統一する（20分）
Q: 命名ルールを途中で変えると既存のインスタンスはどうなりますか？
A： プロパティ名を変更すると、そのプロパティを参照していた既存インスタンスの設定がリセットされます。大規模に変更する場合は、新旧プロパティ名の対応表をあらかじめ作成してから変更作業を進めることで、作業漏れを防げます。
Q： チームで命名ルールを統一するにはどうすればよいですか？
A： FigmaファイルのカバーページまたはNotionに命名規則ドキュメントを1つ作り、全員がそこを参照する運用が最もシンプルです。ドキュメントには「OK例／NG例」を並べて記載すると、新メンバーが加わったときの習得時間が短縮されます。
PR提供: 日本デザインスクール（デザスク）
Figmaバリアント実践は2事例で設計が変わる
同じバリアント機能を使っても、設計方針の違いで6ヶ月後の保守コストが大きく変わります。成功例と失敗例を並べることで、自分のプロジェクトに合う設計規模の判断基準が明確になります。
ケース1（成功パターン）：ボタン1種類から始めて3週間で横展開
フリーランスのAさんは、Webアプリのリデザイン案件でFigmaを初めてチーム共有する状況に置かれました。最初からすべてのUIにバリアントを適用せず、使用頻度が最も高いPrimaryボタンの1コンポーネントのみから始めました。StateプロパティにDefault・Hover・Disabledの3値を設定し、チーム内でレビューを経て命名規則を確定。その後、Input・Tagの順で横展開し、3週間で主要UIコンポーネント8種のバリアント設定が完了しました。ライブラリ公開後、チームメンバーからの「どれを使えばいいか分からない」という質問がゼロになったと報告しています。
チーム案件でコンポーネントライブラリを整備したWebデザイナーは「小さく始めて徐々に広げる進め方で、チームの混乱なくコンポーネントライブラリを整備できた」と語っています（習うより慣れる！FigmaでWebデザイン〜ボタン作成で学ぶバリアント）。
最初からすべてのUIに一斉適用していれば、命名規則が安定する前に大量のコンポーネントが作られ、後から整理し直す工数が新規作成の2倍以上になっていた可能性があります。
ケース2（失敗パターン）：プロパティ増やしすぎで管理崩壊
フリーランスのBさんは、ECサイトのデザインシステム構築を1人で担当しました。State・Size・Type・Color・Roundedの5プロパティを最初から全コンポーネントに設定し、バリアント数がボタン1種で多数のパターンに膨らみました。インスタンス配置時に選択肢が多すぎてどの組み合わせが正解か分からなくなり、プロジェクト後半で大半のバリアントが使われないまま放置されました。
デザインシステム構築を担当したフリーランスデザイナーは「最初に設計しすぎて、後半は誰もバリアントを使わなくなってしまった」と振り返っています（Figmaのコンポーネント”バリアント”機能を知る）。
最初のバリアント設計を「State×Sizeの2プロパティ・最大12パターン」に絞っていれば、使われないバリアントを量産することなく、プロジェクト内で実際に機能するライブラリとして運用できた可能性があります。フリーランスとしてデザイン案件に継続的に参加するためにも、使われないバリアントを量産しない設計判断が重要です。
CHECK
▶ 今すぐやること: 現在のプロジェクトで「使われていないバリアント」がないかアセットパネルで確認し、不要なものを削除または非表示にする（15分）
Q: 途中からバリアントのプロパティ数を減らすことはできますか？
A： できます。コンポーネントセットを選択して右サイドバーからプロパティを削除できます。ただし削除したプロパティを参照していたインスタンスの設定はリセットされるため、影響範囲をFigmaの「インスタンスを確認」機能で確認してから実行してください。
Figmaバリアントは5つの仕組みで管理を自動化
バリアントの設定が増えるにつれ、「どれが最新か分からない」「誰かが命名を間違えた」といった管理コストが積み上がります。以下の5つのハックを順に適用することで、バリアント管理の属人的な手作業をゼロに近づけられます。
ハック1：Stateプロパティ固定で切り替えミスを削減
【対象】：複数人でFigmaライブラリを共有しているチームのデザイナー。
【手順】：まず既存コンポーネントを洗い出し、状態違いが3種類以上あるUIをリストアップします（15分）。次にStateプロパティのみを先に追加し、値を「default / hover / disabled」の3語に固定します（10分）。最後に全チームメンバーにSlackでプロパティ名と値の一覧を共有し、今後の追加時もこの一覧に従う旨を合意します（5分）。
【コツと理由】：「最初に使う値を全員で合意してから追加する」と切り替えミスを防止できます。後から追加した値と既存の値で表記ゆれが生まれると、同じ「無効状態」が「disabled」「Disabled」「無効」と3種類存在するコンポーネントセットができ上がります。インスタンス側で正しい値を選べなくなり、切り替え作業のたびに確認工数が発生します。事前の合意コスト（30分）が後の修正コスト（数時間）を構造的に削減します。
【注意点】：値の追加は全員の合意なしに行わないでください。1人が勝手に追加した値は、他のメンバーのインスタンスに反映されないだけでなく、命名ルールのドキュメントとの乖離を生み出します。
ハック2：スラッシュ階層で検索時間を短縮
【対象】：コンポーネント数が20を超えたFigmaファイルを管理しているデザイナー。
【手順】：まずアセットパネルを開き、現在のコンポーネント一覧をフラットに確認します（5分）。次にコンポーネントセット名を「Button/Primary」「Button/Secondary」「Input/Text」のようにスラッシュ区切りで階層化します（20分）。最後にアセットパネルで検索して階層ツリーが表示されることを確認します（5分）。
【コツと理由】：スラッシュ階層を採用する理由は、Figmaのアセットパネルが「/」前後の文字列を自動的にグループ化して表示するからです。コンポーネント数が多いファイルでは、スラッシュなし設計と比較して目的コンポーネントの発見速度が向上します。スラッシュ階層はFigma公式が推奨する構造化手法でもあります（Figma公式ヘルプ：バリアントの作成と使用）。
【注意点】：スラッシュの前後にスペースを入れると「Button / Primary」と「Button/Primary」が別コンポーネントとして認識されるため、スペースなし「Button/Primary」に統一します。変更後に検索して期待通りにグループ化されているかを必ず確認してください。
ハック3：バリアント複製後の値変更で設定漏れをゼロ化
【対象】：バリアントを追加するたびに「見た目は変えたが値を変え忘れた」トラブルを経験したデザイナー。
【手順】：まずコンポーネントセット内の既存バリアントを複製（Option+ドラッグまたはCtrl+D）します（1分）。次に複製直後にプロパティ値を変更して見た目と値が一致するよう編集します（5分）。最後にインスタンスを別フレームに配置して値を切り替え、複製したバリアントが選択できるかを確認します（2分）。
【コツと理由】：「複製した瞬間に値を変える」順番に切り替えると設定漏れが防止できます。値を変えずに見た目だけ変えても、インスタンス側では同じプロパティ値が2つ存在する状態になり、どちらが正しいか判別できない問題が生じます。複製→即値変更の順を習慣化することで、設定漏れによる手戻りが構造的に発生しなくなります。
【注意点】：複製時にコンポーネントセットの枠外にドラッグしてしまうと、単独のコンポーネントとしてセット外に配置されます。複製後は必ずコンポーネントセットの紫枠の内側に収まっていることをキャンバスで確認してください。枠外に出た場合は削除して再度セット内から複製する方が確実です。
ハック4：オートレイアウトを先に設定してサイズ変更を自動化
【対象】：バリアントのサイズ違い（small / medium / large）を手動で整えていて作業時間がかかっているデザイナー。
【手順】：まずメインコンポーネントにオートレイアウトを設定し、パディングと間隔を数値で指定します（10分）。次にSizeプロパティを追加し、smallバリアントではパディングを8px、mediumは12px、largeは16pxとフレームサイズを変えるかわりにパディングのみで差分を表現します（15分）。最後にインスタンスを配置して各サイズが自動でリサイズされることを確認します（5分）。
【コツと理由】：サイズ違いを「フレームの幅・高さの数値を直接変える」方法で管理している場合、要素が1つ増えるたびに全サイズのバリアントを手動で再調整する必要があります。オートレイアウトを先に設定してからSizeバリアントをパディングの差分で表現すると、テキストや要素が増えても他のサイズバリアントが自動追従するため、再調整作業が発生しません。オートレイアウトとバリアントの組み合わせはFigmaが公式に推奨する効率化の基本構造です。
【注意点】：オートレイアウトを設定する前にフレームサイズを固定値で指定していた場合、オートレイアウト追加後にサイズが崩れることがあります。既存コンポーネントに後からオートレイアウトを追加する際は、コピーを別フレームで検証してから本番のコンポーネントに適用してください。
ハック5：命名規則ドキュメントで新規参加者の習得を短縮
【対象】：フリーランスとして複数のチーム案件に関わり、案件ごとに異なる命名ルールに対応しているデザイナー。
【手順】：まずFigmaのカバーページにコンポーネント命名規則のフレームを1つ作成します（30分）。次にプロパティ名・値・コンポーネントセット名のOK例とNG例を並べて記載します（30分）。最後にFigmaのページを共有URLでチームに送り、オンボーディング資料として位置付けます（5分）。
【コツと理由】：「FigmaファイルのカバーページにFigmaで直接記載する」と参照率が高くなります。デザイナーが作業中にルールを確認したい瞬間は、Figmaを開いている状態だからです。別ツールに切り替える手間が参照のハードルを上げ、「知っているけど確認しない」状態を生み出します。Figma内にドキュメントを置くことで参照コストがゼロになり、命名ルールの遵守率が向上します。チームで作業効率を上げる仕組みづくりとして、ドキュメントの置き場所設計は重要な投資です。
【注意点】：ドキュメントを作ること自体に時間をかけすぎる必要はありません。完璧なドキュメントを1日かけて作るより、OK例を3つ・NG例を3つだけ書いた簡易版を1時間で作って共有する方が、チームに使ってもらえる可能性が高くなります。
CHECK
▶ 今すぐやること: ハック1のStateプロパティ固定から始め、既存コンポーネントのプロパティ値一覧をFigmaのカバーページに書き出す（30分）
Q: オートレイアウトなしでもバリアントは使えますか？
A： 使えます。ただしサイズ違いのバリアントを管理する場合、オートレイアウトなしでは各バリアントのサイズ調整が手動になるため、要素が変わるたびに全バリアントを個別に修正する作業が発生します。初期設定に時間がかかりますが、オートレイアウトを先に設定することで後の修正コストが大幅に下がります。
Figmaバリアントはプロトタイプと2段階で連携
インタラクションの設定先を間違えると、レビューで「状態遷移が動かない」という指摘を受けて手戻りが発生します。バリアントとプロトタイプの役割分担を正確に把握することで、設定ミスを事前に防げます。
インタラクティブコンポーネントの仕組み
インタラクティブコンポーネントとは、コンポーネントセット内のバリアント同士をプロトタイプのインタラクションで接続し、インスタンスを配置するだけでホバー・クリック時の状態遷移が動く仕組みです（Figma公式ヘルプ：バリアントを使ったインタラクティブコンポーネントの作成）。通常のプロトタイプはフレーム間の画面遷移を作るものですが、インタラクティブコンポーネントはコンポーネント内部でバリアント間の遷移を設定できる点が異なります。ボタンのホバー状態をすべてのフレームで個別に設定する手間なく、コンポーネント側に1回設定するだけで全インスタンスに反映できます。
2段階の設定手順
第1段階として、コンポーネントセットを選択してプロトタイプモードに切り替え、defaultバリアントからhoverバリアントへの接続線を引きます。トリガーを「マウスオーバー」、アクションを「次に変更」に設定します。第2段階として、インスタンスをキャンバスに配置し、プロトタイプのプレビューモードで実際にマウスを乗せてhover状態に変わるかを確認します。設定はコンポーネント側に1回行うだけで、全インスタンスに自動反映されます。多数のフレームがあっても1回の設定で全画面のインタラクションを完成できます。
インタラクション設定が不要なケース
インタラクションの設定が必要なのは、「プロトタイプで状態遷移を見せる必要がある」場合に限られます。静的なデザイン確認や開発者への仕様伝達が目的であれば、バリアントの切り替えはインスタンス側のサイドバー操作で十分であり、インタラクション設定は不要です。プロトタイプが不要な段階でインタラクションを設定すると、ファイルのパフォーマンスが低下し、プロトタイプビューのレスポンスが遅くなるケースがあります。フリーランスとして納品物の範囲を判断する際は、「この案件でプロトタイプが必要かどうか」を事前にクライアントと合意してから設定作業に入ってください。
CHECK
▶ 今すぐやること: プロトタイプが必要な案件かどうかを確認し、必要な場合のみdefault→hoverのインタラクション1つを試験的に設定して動作確認する（20分）
Q: インタラクティブコンポーネントとプロトタイプのフレーム遷移はどう使い分けますか？
A： コンポーネント内の状態変化（ホバー・フォーカス・押下など）はインタラクティブコンポーネントで設定し、画面間の遷移（ページAからページBへ）はフレーム間のプロトタイプで設定する、という役割分担が基本です。両方を混在させると設定の追跡が難しくなるため、「状態変化はコンポーネント内で完結させる」原則を守ってください。
Q： インタラクティブコンポーネントの設定を解除するにはどうすればよいですか？
A： プロトタイプモードでコンポーネントセットを選択し、バリアント間の接続線をクリックしてDeleteキーで削除します。接続線を削除するだけで設定が解除され、バリアント自体は残ります。
Figmaバリアントをコンポーネント化から始める：設計規模の決め方と次の一歩
バリアントは「コンポーネント化→プロパティ追加→命名固定→横展開」の順で設定すれば、フリーランス案件でも3週間で主要UIのライブラリ整備が完了します。最初から多くのプロパティを設計するのではなく、Stateの1プロパティを1コンポーネントで完成させることが最も重要な出発点です。チームで共有するファイルでは、命名規則をFigmaのカバーページに記載するだけで参照コストがゼロになり、命名の崩れを構造的に防げます。
バリアントの設定を完成させることよりも、「使われるライブラリを作ること」に目的を置いて設計規模を決めてください。完璧なデザインシステムよりも、チーム全員が迷わず使える小さなライブラリの方が、プロジェクトの生産性に直結します。
| 状況 | 次の一歩 | 所要時間 |
| まだバリアントを一度も使っていない | ボタン1つでStateの3値を設定して切り替えを確認する | 30分 |
| バリアントはあるが命名が崩れている | 既存プロパティ名の表記ゆれをリストアップして統一する | 20分 |
| チームで共有するファイルを整備したい | カバーページに命名規則のOK例・NG例を3つずつ記載する | 1時間 |
| プロトタイプの状態遷移を設定したい | default→hoverのインタラクション1つを試験設定して動作確認する | 20分 |
Figmaコンポーネントバリアントに関するよくある質問
Q: バリアントとコンポーネントセットは同じものですか？
A： 異なります。コンポーネントセットは複数のバリアントをまとめる入れ物で、バリアントはその中に含まれる個々の状態違いのコンポーネントです。コンポーネントセットを選択すると右サイドバーにプロパティ一覧が表示され、バリアントを選択すると個々の値が編集できる状態になります。
Q： バリアントを削除するとインスタンスはどうなりますか？
A： 削除したバリアントを参照していたインスタンスは、設定がリセットされてコンポーネントセットの最初のバリアント（通常はdefault）に戻ります。削除前にFigmaの「このコンポーネントを使用している場所を表示」機能で影響範囲を確認してから実行してください。
Q： 無料プランのFigmaでもバリアントは使えますか？
A： 使えます。バリアントおよびインタラクティブコンポーネントはFigmaの有料・無料プランを問わず利用できる機能です（Figma公式ヘルプ：バリアントの作成と使用）。ただしライブラリとして他のファイルに共有する機能（チームライブラリ）は有料プランが必要です。
【出典・参照元】
Figma公式ヘルプ：バリアントの作成と使用 – バリアントの追加手順、プロパティと値の設定、インスタンスからの切り替え方法
Figma公式ヘルプ：バリアントを使ったインタラクティブコンポーネントの作成 – インタラクティブコンポーネントの設定手順、次に変更アクション
【Figma】コンポーネントの使い方解説2 | バリアント編 – 命名規則の実践例、コンポーネントセットの運用体験
習うより慣れる！FigmaでWebデザイン〜ボタン作成で学ぶバリアント – ボタンバリアントの実践事例、小さく始める設計手法
Figmaのコンポーネント”バリアント”機能を知る – バリアント設計の失敗事例、作り込みすぎの問題