【実務・中級編】Figmaのコンポーネントプロパティ（Component Properties）の高度なネスト活用術と命名規則のベストプラクティス – UI/UX・デザインツール活用バイブル

Figmaコンポーネントプロパティの極意：ネスト地獄を断ち切り、デザインシステムをコードへ直結させる設計論

こんにちは。テックリードとして日々デザインシステムとフロントエンドの橋渡しをしているあなたなら、こんな悪夢に直面したことがあるはずだ。

「ボタンの中にアイコンがあり、そのアイコンの色を変えたいだけなのに、インスタンスを3階層も掘らなければならない」
「デザイナーが勝手に命名したプロパティのせいで、コード側のコンポーネントAPIと完全に乖離している」
「コンポーネントが肥大化しすぎて、Figmaが重い上に誰も触れない『ブラックボックス』と化している」

Figmaのコンポーネントプロパティ（Component Properties）は強力だが、設計思想なしに導入すると、単なる「設定項目の多いゴミ屋敷」を生み出す。

今回は、このカオスを完全に制御し、開発スピードを劇的に高めるための高度なネスト活用術と命名規則のベストプラクティスを、プロダクトデザイナーとエンジニアの共通言語として授けよう。

—

1. 基礎の再定義：なぜ「プロパティの継承問題」が起きるのか

まず、Figmaのプロパティ構造の根本的な仕様を理解する。
コンポーネントを入れ子（ネスト）にする際、子コンポーネントのプロパティを親コンポーネントへ露出（Expose）させる忘備録として、以下の鉄則がある。

> 「親は子のプロパティを自動で引き継がない。手動でバインド（Expose）し続ける必要がある」

これが、いわゆる「プロパティの継承問題」の正体だ。
例えば、`Button`の中に`Icon`があり、さらにその中に`SVG Path`があるとする。Button側で「Iconの表示/非表示」「Iconの種類」「Iconの色」を制御したい場合、それぞれの階層で適切にプロパティを「再露出（Nested Instance Propertiesの紐付け）」しなければ、インスタンスの階層が深くなるにつれてコントロールを失う。

解決のアプローチ：コンポーネントの「カプセル化」

オブジェクト指向プログラミングと同様に、UIコンポーネントもカプセル化すべきだ。

露出させるべきもの: 外部（親や利用者）から意味を持つパラメータ（例: `Button`のラベル、サイズ、状態、主要アイコンの有無）。
隠蔽すべきもの: 実装の詳細（例: アイコン内部のパディング、SVGのベジェ曲線の制御点）。

無闇にすべてのプロパティを露出させると、認知負荷が跳ね上がる。「利用者がコンポーネントを配置した瞬間に、何を設定すべきか迷わない状態」を作ることがプロパティ設計のゴールだ。

—

2. チーム開発を救う：命名規則（Naming Convention）のベストプラクティス

デザイナーとエンジニアの共通言語を作る。ここが曖昧だと、Figmaとコード（React / Vue等）のメンタルモデルが乖離し、レビューのたびに無駄な摩擦が生まれる。

我がチームで実績を出している命名規則のルールセットを公開する。

基本原則

1. キャメルケース（camelCase）の徹底: プロパティ名はすべて `camelCase`（例: `hasIcon`, `iconName`）で統一する。これはJSXのPropsと完全に一致させるためだ。
2. 真偽値（Boolean）にはプレフィックスをつける: `is`（状態）, `has`（包含）, `show`（表示切替）を必ず頭につける。
3. インスタンススワップ（Instance Swap）には用途を示す: 単なる `icon` ではなく、位置を示すプレフィックスをつける（例: `iconLeft`, `iconRight`）。

プロパティ種別ごとの命名マトリクス

この命名規則を徹底するだけで、Figmaの右サイドバー（デザインパネル）が、そのままReactのPropsテーブルのように機能し始める。

—

3. 実践：実用的なUIパーツ（高機能カードコンポーネント）の構築手順

「サムネイル、バッジ、タイトル、説明文、アクションボタン（アイコン付き）」を持つ複雑なカード（`Card/Interactive`）を例に、ネストプロパティの極意を実演する。

階層構造

`Card/Interactive` (親)
`Badge` (子1)
`Button/Primary` (子2)
`Icon` (孫)

手順：プロパティのバインド

1. 最下層（Icon）: プロパティとして `iconName`（Instance Swap）を設定。
2. 中層（Button/Primary）:

Button自体のテキストをプロパティ化 (`label`)。
子であるIconのインスタンスを選択し、右パネルのInstance Swapアイコンから、「1で設定したIconのプロパティ」をバインドする。これにより、Buttonのインスタンス上から孫のIconを変更可能になる。

3. 最上層（Card/Interactive）:

Badgeの表示/非表示をプロパティ化（`hasBadge: Boolean`）。
Badgeのテキストをプロパティ化（`badgeText: Text`）。
Buttonの表示/非表示（`hasAction: Boolean`）と、Button内部のプロパティ群（`buttonLabel`, `iconLeft`など）をすべて親のレイヤーに露出させる。

これで、開発者は親である`Card/Interactive`を選択するだけで、孫パーツのアイコンやテキストまで一元管理できるようになる。余計なレイヤーをクリックして選択し直すストレスから解放される瞬間だ。

—

4. プロの生産性を爆上げするキーボードショートカット

Figmaの操作速度は、コンポーネント設計のテンポに直結する。マウス操作を極限まで減らすためのショートカット。

Mac: `Option` + `Command` + `K` （コンポーネント化）
Win: `Alt` + `Ctrl` + `K`
プロパティ編集への高速アクセス:
コンポーネントを選択した状態で `Return`（レイヤー内へフォーカス）
プロパティパネルの項目上で `Tab` キーを駆使し、マウスを使わずに命名や値の調整を完結させる。
インスタンスのドリルダウン（深掘り選択）:
`Command` (Mac) / `Ctrl` (Win) を押しながらクリックすると、ネストされた孫コンポーネントを一発で直選択できる。これを覚えるだけで、プロパティ設計時のバインド作業スピードが3倍になる。

—

5. 絶対に入れるべき神プラグイン

デザインシステム構築のボトルネックを解消する、現代の必須プラグインたち。

1. Component Code Generator

Figmaのコンポーネントプロパティやバリアントの構成を解析し、自動でReact（TypeScript）やVueのPropsインターフェースの雛形をきれいに吐き出してくれる。デザイナーの命名規則がそのままコードの型になる感覚を体験してほしい。

2. Masterrenamer

ネストが深くなると散らかりがちなレイヤー名やプロパティ名を、正規表現や一括置換で美しく整理整頓するためのマストツール。

3. Token Studio for Figma (旧Figma Tokens)

コンポーネントプロパティとデザイントークン（Design Tokens）をシームレスに結合し、JSONとして書き出すための業界標準。後述する設定ファイルの連携基盤となる。

—

6. 実戦投入：デザインシステム連携のための設定ファイル構成例

Figmaで作り上げた美しいコンポーネントプロパティの構造は、そのままコードベースのデザインシステム（例: Tailwind CSSやChakra UI、あるいは自社製Design System）に同期させるべきだ。

以下に、Figmaのプロパティ構造をコード側へトランスパイルする際に用いる、実用的なJSON/YAMLのデザイントークンおよびコンポーネントメタデータのベストプラクティス構成例を示す。

`card-interactive.config.json` (コンポーネントメタデータ定義)

Figmaのプロパティ構造と、ReactコンポーネントのPropsをマッピングするための定義ファイル。

{
“component”: “InteractiveCard”,
“figmaComponentKey”: “a1b2c3d4-e5f6-7890-abcd-ef0123456789”,
“description”: “サムネイル、バッジ、アクションボタンを持つインタラクティブカード”,
“properties”: {
“hasBadge”: {
“type”: “boolean”,
“defaultValue”: true,
“reactProp”: “showBadge”,
“description”: “バッジの表示・非表示を切り替えます”
},
“badgeText”: {
“type”: “text”,
“defaultValue”: “New”,
“reactProp”: “badgeLabel”,
“description”: “バッジ内に表示するテキスト”
},
“hasAction”: {
“type”: “boolean”,
“defaultValue”: true,
“reactProp”: “isActionable”,
“description”: “アクションボタンエリアの表示制御”
},
“buttonLabel”: {
“type”: “text”,
“defaultValue”: “詳細を見る”,
“reactProp”: “actionText”,
“description”: “アクションボタンのラベル”
},
“iconLeft”: {
“type”: “instance_swap”,
“allowedCategories”: [“arrows”, “actions”],
“defaultValue”: “ArrowRight”,
“reactProp”: “leftIcon”,
“description”: “ボタン内に配置するアイコン”
}
}
}

`design-tokens.yaml` (デザイントークンとの統合)

プロパティのバリアント（Variant）制御をコード側と一貫させるためのYAML定義。

==========================================
Design Tokens: Card Component Variants
==========================================
component:
card:
intent:
primary:
background: “{color.surface.default}”
border: “{color.border.subtle}”
elevated:
background: “{color.surface.raised}”
boxShadow: “{shadow.md}”

# FigmaのVariantプロパティ名と完全一致させる
variants:
size:
sm:
padding: “{spacing.3}”
borderRadius: “{radius.sm}”
md:
padding: “{spacing.4}”
borderRadius: “{radius.md}”
lg:
padding: “{spacing.6}”
borderRadius: “{radius.lg}”

この設定ファイルをGitHub等のリポジトリで一元管理し、CI/CDパイプラインやStyle Dictionaryなどのツールを用いてFigma Variables/Tokensと同期させることで、「デザインとコードの乖離」という永遠の課題に終止符を打つことができる。

—

結びにかえて

Figmaのコンポーネントプロパティは、単なる「レイアウトの効率化ツール」ではない。「デザインシステムというプロダクトのAPI設計そのもの」である。

プロパティのネスト構造を整理し、厳格な命名規則を敷き、コードの世界とデータ構造を同期させる。この泥臭くも美しい設計プロセスをチームに浸透させた時、あなたのプロジェクトの開発スピードは次元の違う領域へと加速する。

さあ、今すぐFigmaを開き、その複雑怪奇なネストコンポーネントの構造をリファクタリングしにいこう。