こんにちは！
UIデザイナーのYunyです。
- ボタンや入力フォームのVariantsが増えすぎて、キャンバスの管理に悩んでいる方
- Component Properties（ブール値・テキスト・インスタンス切り替え）の具体的な設定手順を知りたい方
- Variantsとプロパティ、新機能スロット（Slots）の使い分け基準をチームで統一したい方
UIデザインのコンポーネント設計を進める中で、「気づけば無駄なバリアントが増えすぎてしまったな」と感じた経験はないでしょうか。
「これって別の機能を使えばもっと減らせるんじゃないか」「もっとスマートにまとめられるはずでは」と、肥大化したバリアントの整理に悩む場面は多いはずです。
Figmaのコンポーネントプロパティ（Component Properties）を適切に組み合わせることで、バリアントの過剰な肥大化を防ぎ、スマートな運用体制を整えられます。
今回は、実務で迷わないプロパティの使い分け基準と、現場で役立つ具体的な設計手順を分かりやすく整理しました。
コンポーネントプロパティは、1つのコンポーネント内で要素の表示切替や文言・アイコンの差し替えを右パネルから直接操作できる機能です。構造やスタイルが根本から変わる差分のみをVariantsで管理し、要素のON/OFFや中身の変更はプロパティへ逃がすことで、バリアント数を最小限に抑えた保守性の高い設計を実現できます。
- 1. なぜ「バリアント爆発」が起きるのか？Variants単体運用の限界
- 掛け算で増え続けるバリアントの構造的課題
- 従来のVariantsとComponent Propertiesの根本的な違い
- 2. まず押さえたい「3大コンポーネントプロパティ」の役割と設定手順
- 1. Boolean（ブール値）：要素の表示・非表示をトグル化する
- 2. Text（テキスト）：キャンバスを崩さず右パネルから文言変更
- 3. Instance Swap（インスタンスの切り替え）：アイコンやパーツを素早く差し替える
- 3. 実践！ボタンと入力フォームでバリアントを激減させる設計手順
- 実践例1：ボタンコンポーネント（36バリアント → 6バリアントへ圧縮）
- 実践例2：入力フォーム（テキストフィールド）の設計
- 4. さらに一歩進んだ実務ワザ：ネストされたプロパティの公開
- 深い階層のレイヤーを開かずに親から直接操作する
- フロントエンド実装（React等のProps構造）との親和性
- 5. デタッチせずに中身を自由に入れ替える！注目の機能「スロット（Slots）」
- デタッチを防ぐ「スロット構造（入れ替え領域）」の仕組み
- 実務でのスロット設計：Instance Swapスロットと最新機能
- 6. Variants・プロパティ・スロットの使い分け判断基準マトリクス
- 迷わないための機能選定マトリクス
- チームで破綻させない運用のコツ
- 終わりに
1. なぜ「バリアント爆発」が起きるのか？Variants単体運用の限界
コンポーネントを設計する際、あらゆるバリエーションをVariantsだけで解決しようとすると、「掛け算によるパターンの急増」に直面します。
海外のデザインシステムや国内のUI設計現場では、この状態を「バリアント爆発（Variant Explosion）」と呼ぶこともあり、管理の破綻を招く典型的なつまずきポイントとなっています。
掛け算で増え続けるバリアントの構造的課題
例えば、標準的なアクションボタンをVariantsだけで作成する場合を考えてみましょう。
ボタンに必要な要素を細かく掛け合わせていくと、以下のようにパターン数が急速に膨らんでいくのが実態です。
- ボタンサイズ: 3種類（Small / Medium / Large）
- スタイル種別: 3種類（Primary / Secondary / Outline）
- アイコン構成: 4種類（アイコンなし / 左アイコン / 右アイコン / 両方アイコン）
これらのかけ合わせだけでも、3 × 3 × 4 = 36通り のバリアントがキャンバス上に並ぶ計算になります。
さらにHoverやActive、Disabledなどの状態（States）まで真面目に全部バリアントで再現しようとすると、1つのボタンだけで100個以上のバリアントを管理しなければならなくなってしまいます。
大量のバリアントを抱えたコンポーネントは、Figmaの動作を重くするだけでなく、共通の角丸や文字サイズを1箇所変更するだけで莫大な修正工数を生み出します。
「では世の中で運用されている優れたデザインシステムはどう管理しているんだろう？」と公式ライブラリを観察し、実務での構造を徹底的に洗い出してみました。
Material DesignやShopify Polarisなどの著名なデザインシステムを見てみると、バリアントの数は最小限に抑えられています。
見た目の骨格だけをバリアントに残し、要素の出し入れや中身の差し替えはコンポーネントプロパティへ綺麗に逃がしていることが分かりました。
従来のVariantsとComponent Propertiesの根本的な違い
バリアントの急増を防ぐために導入された仕組みが、コンポーネントプロパティ（Component Properties）です。
両者は対立する機能ではなく、コンポーネントの「変化の性質」に応じて以下のように明確な役割分担を持っています。
| 比較項目 | バリアント（Variants） | コンポーネントプロパティ（Component Properties） |
|---|---|---|
| 主な用途 | 見た目の構造やスタイルが根本から変わる変化 | 同一構造内での要素の出し入れやコンテンツ変更 |
| キャンバス上の実体 | 差分ごとに独立した別々のフレームが並ぶ | 1つのコンポーネント内に内部設定として保持される |
| 典型的な利用例 | サイズ（S/M/L）、スタイル（Primary/Ghost）、状態 | アイコン表示ON/OFF、ラベルテキスト変更、アイコン差し替え |
| ファイル容量への影響 | バリアント数に比例して描画負荷が増加する | 内部属性のためファイル容量やメモリ消費を大幅に削減 |
| 操作インターフェース | ドロップダウンから別の外見パターンを選択 | スイッチのトグル、入力欄、アセット選択ピッカー |
「構造そのものが切り替わるものはVariants」「中身の差し替えや表示切替はComponent Properties」という境界線を引くことが、破綻しないコンポーネント設計の第一歩となります。
2. まず押さえたい「3大コンポーネントプロパティ」の役割と設定手順
Figmaのコンポーネントプロパティにはいくつかの種類がありますが、実務で頻繁に活躍するのは「Boolean（ブール値）」「Text（テキスト）」「Instance Swap（インスタンスの切り替え）」の3つです。
それぞれの役割と具体的な設定方法を順番に見ていきましょう。
1. Boolean（ブール値）：要素の表示・非表示をトグル化する
Booleanプロパティは、コンポーネント内の特定のレイヤーをスイッチ（True / False）で表示・非表示できる機能です。
ボタンの左右アイコンや入力欄のヘルプテキストなど、「必要なときだけ出す要素」を扱う場面に適しています。
設定手順はとてもシンプルで、わずか数クリックの操作で完了します。
コンポーネント内の対象レイヤーを選択し、右サイドバーの操作を行うだけで連動が完了します。
- 対象レイヤーを選択: コンポーネント内の非表示にしたい要素（例:
Icon_Left）を選択します。 - レイヤーセクションのアイコンをクリック: 右パネル「レイヤー（Layer）」の右端にある「プロパティ作成アイコン（四角に下向き矢印）」をクリックします。
- 名前と初期値を設定: プロパティ名（例:
showLeftIcon）を入力し、デフォルト値（TrueまたはFalse）を指定して「プロパティを作成」を押します。
オートレイアウトが適用されたフレーム内でBooleanプロパティを使用すると、非表示にした際に自動で余白が詰まるため、手動で幅を調整する必要がなくなります。
アイコンあり用とアイコンなし用のバリアントを別々に用意していた手間が、このトグル1つで完全に解消されます。
2. Text（テキスト）：キャンバスを崩さず右パネルから文言変更
Textプロパティは、コンポーネント内の文字情報を右サイドバーのテキストフィールドから直接編集できる機能です。
キャンバス上の文字を何度もダブルクリックして深い階層に潜る手間を削減できます。
特に複数人で作業を進める際、ダブルクリックの誤操作でレイアウト位置やフォント設定を崩すミスを未然に防止できます。
設定手順は以下の3ステップで完結します。
- テキストレイヤーを選択: コンポーネント内の文字レイヤー（例:
Label）を選択します。 - テキストセクションのプロパティを作成: 右パネル「テキスト（Text）」セクションのコンテンツ横にあるプロパティ作成アイコンをクリックします。
- プロパティ名と初期テキストを登録: プロパティ名（例:
label）と、初期表示させたい文字列を入力して作成します。
インスタンスを選択した際、右サイドバーのプロパティ欄にテキスト入力ボックスが並ぶため、フォームに入力するような感覚でスピーディーに文言を流し込めるようになります。
3. Instance Swap（インスタンスの切り替え）：アイコンやパーツを素早く差し替える
Instance Swapプロパティは、コンポーネント内にネストされたインスタンスを、別のアセットへ素早く交換できる機能です。
ボタン内のアイコンやアバター画像、ステータスバッジなど、共通規格の別パーツへ切り替える際に重宝します。
設定は、ネストされているコンポーネントインスタンスを選択した状態で行います。
右パネルのコンポーネント名横にあるプロパティアイコンから、以下の手順で紐付けを行います。
- ネストされたインスタンスを選択: ボタン内のアイコンインスタンス（例:
Icon / Search）を選択します。 - インスタンス切り替えプロパティを作成: 右パネルのコンポーネント名横にあるプロパティ作成アイコンをクリックします。
- Preferred values（推奨値）の指定: プロパティ名（例:
leftIcon）を設定すると同時に、差し替え候補となるアイコン一覧を「推奨値（Preferred values）」として登録します。
この推奨値設定を活用することで、プロジェクト内で使用を許可したアセットのみをドロップダウンの上位に優先表示できます。
デザイナー仲間が数十〜数百個あるアイコン一覧から延々と探す手間を省き、デザインシステム全体の統一感を維持するのにも役立ちます。
3. 実践！ボタンと入力フォームでバリアントを激減させる設計手順
3大プロパティの役割を把握したところで、実務で誰もが作成する「アクションボタン」と「入力フォーム」を題材に、具体的な削減手順を検証してみましょう。
バリアントとプロパティを正しく組み合わせることで、どれほどデータ構造がシンプルになるかを体感できます。
実践例1：ボタンコンポーネント（36バリアント → 6バリアントへ圧縮）
まずは先ほど例に挙げた、サイズ3種×スタイル3種×アイコン状態4種で計36バリアントあったアクションボタンの再設計です。
このボタンコンポーネントを、以下の役割分担ルールに従って再構築します。
- Variantsに残すもの（見た目の枠組み）:
–Size: Small（高さ32px）/ Medium（高さ40px）/ Large（高さ48px）
–Variant: Primary（塗りつぶし）/ Secondary（枠線のみ） - Component Propertiesに逃がすもの（要素の制御）:
–showLeftIcon: Boolean（初期値: True）
–showRightIcon: Boolean（初期値: False）
–leftIcon: Instance Swap（推奨値: アロー、検索、プラスなど主要アイコン）
–label: Text（初期値: “Button”）
この再構成によって、キャンバス上に用意するバリアントは「3サイズ × 2スタイル = わずか6個」にまで激減します。
アイコンの有無や種類、テキストの長さはすべて右パネルから柔軟に切り替えられるため、デザインの自由度を損なうことなくキャンバスを大幅に軽量化できます。
さらに、ボタン全体に適切なオートレイアウトを設定しておけば、テキスト文字数やアイコンの出し入れに応じてボタン幅が自動伸縮します。
オートレイアウトの基礎やレスポンシブに連動する余白設計をあわせて理解しておくと、プロパティの効果を最大限に引き出すことができます。
実践例2：入力フォーム（テキストフィールド）の設計
入力フォームも、バリアントが増えすぎて管理が煩雑になりやすい代表的なUIコンポーネントです。
上部ラベルや必須マーク、下部のヘルプテキストやエラー表示など、付属する要素が多岐にわたるためです。
入力フォームでは、「状態（States）」のみをVariantsで切り替え、周辺パーツをプロパティ化するアプローチが極めて有効です。
具体的な分担ルールを整理してみましょう。
- Variantsで管理する要素:
–State: Default（通常）/ Focused（入力中・青枠）/ Error（エラー・赤枠）/ Disabled（非活性・グレー） - Component Propertiesで管理する要素:
–showLabel: Boolean（上部ラベルの表示切替）
–labelText: Text（ラベルの文言変更）
–placeholder: Text（入力欄内のプレースホルダー文言）
–showHelperText: Boolean（下部注釈の表示切替）
–showTrailingIcon: Boolean（末尾のクリアボタンやパスワード可視化アイコン）
周辺パーツをすべてバリアントとして掛け算すると数十パターンに及ぶ入力フォームも、4つの状態バリアントだけで完結します。
エラーメッセージの表示切替や文言変更も右パネルから数秒で調整できるため、画面仕様書の作成スピードも格段に向上します。
整ったレイヤー構造はプロパティの設定ミスを防ぎ、将来的なデザインシステムの拡張性を高める重要な土台となります。
チーム開発でも破綻しないレイヤーの階層ルールやセマンティックな命名規則については、以下の記事で体系的に解説しています。
4. さらに一歩進んだ実務ワザ：ネストされたプロパティの公開
複数のコンポーネントを組み合わせた複合的なUI（カードやリスト行など）を作る際、非常に重宝するのが「ネストされたプロパティの公開（Expose nested instances）」という機能です。
この機能を活用することで、親コンポーネントから子コンポーネントの操作パネルへダイレクトにアクセスできます。
深い階層のレイヤーを開かずに親から直接操作する
例えば、ヘッダー画像・タイトル・本文・アクションボタンで構成される「カードコンポーネント」の実装を想定してみましょう。
従来はカード内のボタン文言を変えるために、キャンバス上でカードを3〜4回ダブルクリックして深いレイヤーまで潜る必要がありました。
親コンポーネント側でネストプロパティを公開しておくと、カード全体を選択しただけで、内包されているボタンのプロパティが親の右パネルにそのまま表示されます。
設定手順は以下の通りです。
- 親コンポーネントを選択: カード全体のメインコンポーネントを選択します。
- プロパティ一覧から「ネストされたインスタンス」を追加: プロパティセクションの「＋」ボタンを押し、「ネストされたインスタンス（Nested instances）」を選択します。
- 公開したい子コンポーネントにチェック: カード内に配置されているボタンインスタンス（例:
Button）にチェックを入れます。
この設定を施しておくだけで、画面デザインを組む作業者はカードをクリックした瞬間に、ボタンのラベル打ち替えやアイコン切り替えを右パネルだけで完結できます。
階層を行き来する無駄なクリック操作を削減でき、画面作成のテンポがスムーズに向上します。
フロントエンド実装（React等のProps構造）との親和性
Component Propertiesを整える最大の恩恵の1つは、エンジニアの実装コード（ReactやVueのProps）と設計思想が1対1で直結する点です。
フロントエンド開発では、ボタンのアイコン有無を別コンポーネントとして量産せず、hasIcon={true} のようなPropsで制御するのが一般的です。
Figma側のプロパティ名とコード側のProps名を揃えておくことで、Dev Mode（開発モード）を開いたエンジニアは「どのプロパティを渡せばよいか」を一目で理解できます。
デザイナーとエンジニアの間で「このバリアントはどう実装すべきか」という仕様確認の往復が減り、チーム間の協業が格段にスムーズになります。
プロパティによる構造制御と、Variablesによる値のトークン管理を組み合わせることで、変更に強い柔軟なUIライブラリが完成します。
Figma変数の階層設計やPrimitive/Semanticの2層トークン運用については、以下のガイド記事で詳しく紹介しています。
5. デタッチせずに中身を自由に入れ替える！注目の機能「スロット（Slots）」
コンポーネント設計において、多くのデザイナーが一度は直面するのが「外枠は共通化したいけれど、中身のレイアウトやコンテンツだけは画面ごとに自由に変えたい」というジレンマです。
これを解決する最新の設計手法として注目されているのが、「スロット（Slots）」と呼ばれるアプローチです。
デタッチを防ぐ「スロット構造（入れ替え領域）」の仕組み
モーダルダイアログや汎用カードを作成する際、中身にフォームを入れたり、リストを入れたり、画像を並べたりとコンテンツの自由度が求められるケースは珍しくありません。
従来のFigmaでは、中身を自由に変えたいがためにコンポーネントをデタッチ（Detach instance）してしまい、デザインシステムから切り離されるトラブルが多発していました。
スロットの仕組みを取り入れると、コンポーネントの外枠（ヘッダーやフッター、余白、影）を保ったまま、中央のコンテンツ領域だけをごっそり自由なUIに差し替えることができます。
これにより、親コンポーネントのアップデート恩恵を受け続けながら、画面ごとの柔軟な表現を両立できます。
実務でのスロット設計：Instance Swapスロットと最新機能
実務でスロットを実装するには、主に以下の2つのアプローチがあります。
案件の規模やライブラリの運用ルールに応じて使い分けるのが実用的です。
- Instance Swapを活用した「スロットコンポーネント」:
– 中身の入れ替え領域にあらかじめダミーの「Slotコンポーネント」を配置し、プロパティでInstance Swap可能にしておく定番手法です。
– インスタンス配置時に、画面ごとに作成したカスタムフレーム（コンポーネント化済み）をスワップするだけで、外枠を崩さずに中身を丸ごと差し替えられます。 - Figmaの新機能「スロットに変換（Convert to slot）」:
– コンポーネント内のフレームを直接「スロット」として定義し、インスタンス側で中身を直接追加・削除・並べ替えられる公式アプローチです。
– 別途コンポーネント化する手間なく、インスタンスの枠内へ直接パーツをドラッグ＆ドロップして中身を構築できます。
単一のアイコン差し替えであれば通常のInstance Swapで十分ですが、「中身の構造自体が画面ごとに可変するコンテナ系UI」にはスロットを活用するのが最もスマートです。
6. Variants・プロパティ・スロットの使い分け判断基準マトリクス
「これはVariantsで作るべきか、プロパティにすべきか、それともスロットを使うべきか」と迷ったときは、以下の判断基準に沿って整理するのがおすすめです。
チーム内でのレビュー時にも、共通の判断軸としてそのまま活用できます。
迷わないための機能選定マトリクス
| 変更したい目的・要件 | 最適な機能 | 具体例 |
|---|---|---|
| 配色や構造が根本から変わる | Variants | Primary / Secondary、縦並び / 横並び |
| パーツの「表示 / 非表示」を切り替える | Boolean Property | アイコンの有無、バッジの有無 |
| 文言テキストを打ち替える | Text Property | ボタンラベル、見出し文言 |
| 単一のアイコン・パーツを差し替える | Instance Swap Property | 矢印 → 検索アイコン、ステータス変更 |
| 外枠を保ち中身のレイアウトを自由に変える | スロット（Slots） | モーダルの本文領域、汎用カードの中身 |
チームで破綻させない運用のコツ
コンポーネントプロパティやスロットは非常に便利ですが、何でもかんでも多機能化してしまうと、右サイドバーが設定項目で埋め尽くされて操作性が低下します。
実務で運用する際は、「頻繁に変更する要素トップ3〜4個」に厳選してプロパティ化するのがちょうど良いバランスです。
最初から完璧な網羅を目指すのではなく、日々のデザイン制作の中で「何度もダブルクリックして編集しているパーツ」を見つけたらプロパティ化する、という段階的なアプローチがおすすめです。
無理のない範囲でスモールスタートさせることで、チーム全体に自然とルールが定着していきます。
終わりに
最後までお読みいただき、ありがとうございます！
今回は、Figmaコンポーネントの肥大化を防ぎ、スマートに管理するためのコンポーネントプロパティ（Component Properties）の使い方と実務設計を解説しました。
バリアント、各種プロパティ、そしてスロットの役割を明確に分けるだけで、キャンバスの軽快さもメンテナンスの手間も大幅に改善されます。
デザインシステムは、作って終わりではなく「日々の制作を支えるための道具」です。
まずはよく使うボタンや入力フォームのアイコンから、プロパティによる効率化を試してみてはいかがでしょうか。
これからも、日々のコンポーネント設計やUI制作を一緒に楽しんでいきましょう。
それでは、良いデザインライフを！
