Figma「Component Swap Property」の高度なネスト活用！複雑なアイコン・アバターシステムの極限構築術
現場でデザインシステムを構築していると、必ずぶち当たる壁があります。
「ボタン内のアイコンを差し替えるために、5回もダブルクリックして階層を潜らなければならない」
「アバターのオンラインステータスやバッジを切り替えるたびに、コンポーネントの構造が崩れる」
こうした「デザインシステムの肥大化と操作性の悪化」という愚行を今すぐ止めましょう。
Figmaの「Instance Swap Property（インスタンス切り替えプロパティ）」と「Expose Nested Instances（ネストされたインスタンスの露出）」を正しく理解し、アーキテクチャレベルで設計すれば、どれほど複雑な階層を持つコンポーネントであっても、最表面の右サイドバー（プロパティパネル）から完全に一元制御できるようになります。
本稿では、プロダクトのスケールに耐えうる「アバターシステム」および「アイコン・ボタンシステム」の構築手法を軸に、コードとのシームレスな連携を見据えた最高峰の設計論を解説します。
—
1. 階層の深いコンポーネントにおける「インスタンス置き換え」の限界と課題
まず、なぜ従来のネスト構造が現場の生産性を著しく低下させていたのか、その解剖から始めます。
従来のネスト構造における3大悪夢
1. ディープ・クリックの極限ストレス（ドリルダウン地獄）
`Card` ＞ `CardHeader` ＞ `UserBlock` ＞ `Avatar` ＞ `StatusBadge` ＞ `Icon` という6階層のネストがあった場合、末端のアイコンを変えるためだけにトリプルクリック以上を繰り返し、レイヤーの深部を目指す必要がありました。
2. オーバーライドの消失とレイヤー破壊
バリアントを切り替えた際、階層内部のレイヤー構造や命名規則が微妙に異なると、選択していたアイコンやテキストのオーバーライドがリセットされます。痺れを切らしたデザイナーやエンジニアが「デタッチ（Detach Instance）」を行い、デザインシステムが崩壊する原因になります。
3. コード（React/Vue）との概念的乖離
コード側では `
これらを根本解決するのが、Instance Swap Property の真の活用です。
—
2. 親コンポーネントから子孫パーツをダイレクト制御する高度テクニック
親コンポーネントのプロパティパネルに、子孫パーツの切り替えスイッチを直接エクスポート（再割り当て）する構造を作ります。
ここでは例として、プロダクト内で最も多様なバリエーションを持つ「高度なアバターシステム」を構築します。
[ Root Component: Avatar ]
├── Image Component (Swap Property: “Avatar Image”)
├── Status Indicator (Swap Property: “Status Icon”)
└── Badge Component (Swap Property: “Badge Element”)
ステップ1: 末端パーツのコンポーネント化と「プライベート化」
まず、切り替え対象となるリソース（ステータスアイコンやバッジ）を整理します。
このとき、チームのライブラリサーチを汚染しないよう、コンポーネント名に `_` (アンダースコア) または `.` (ドット) を接頭辞として付与します。
- `_Avatar/Status/Online`
- `_Avatar/Status/Offline`
- `_Avatar/Status/Busy`
- `_Avatar/Badge/Premium`
- `_Avatar/Badge/Verified`
> Tech Lead’s Point:
> 接頭辞 `_` または `.` をつけたコンポーネントは、別ファイルからライブラリとして参照した際に「公開コンポーネント」一覧から非表示になります。検索ノイズを極限まで減らすプロの必須テクニックです。
ステップ2: 子コンポーネントへの「Instance Swap Property」の定義
1. 中間層のコンポーネント（例: `_Avatar/Status-Base`）を選択。
2. ネストされた内部インスタンスを選択し、右サイドバーの「Instance Swap」アイコンをクリック。
3. プロパティ名を作成（例: `Status Icon`）。
ステップ3: 「Expose Nested Instances」によるプロパティの爆速引き上げ
親コンポーネント（例: 最表面の `Avatar`）の右サイドバーにある 「Properties」 の `＋` ボタンを押します。
メニューから 「Nested instances」 を選択し、直下または深い階層にある子コンポーネントを選択してチェックを入れます。
これだけで、親コンポーネントのパネル上に、子孫コンポーネントが持つすべてのプロパティが一括露出（Expose） されます。
—
3. メンテナンス性を保ちながらバリエーションを無限に増やす設計の裏技
単にプロパティを露出させるだけでは完璧とは言えません。「選択肢が多すぎてどれを選べばいいか分からない」という事態を防ぐための 「Preferred Instances（優先インスタンス）」 設定と 「Slot Pattern（スロットパターン）」 を組み合わせます。
技1: Preferred Instances（優先インスタンス）の徹底活用
Instance Swap Propertyを定義する際、「Preferred Instances（優先設定）」 に、その場所に入ることが許可されたコンポーネントだけを明示的に登録します。
- `Status Icon` の Property 設定:
- 優先インスタンスとして `_Avatar/Status/` のみを指定。
- 効果:
利用者がプロパティパネルでドロップダウンを開いた際、何千とあるコンポーネントの中から「ステータス用のアイコンのみ」が最優先でグリッド表示されます。選ぶべきでないコンポーネントの混入をUIレベルで防ぎます。
技2: Universal Slot Pattern（スロットパターン）
ボタンの中に「テキストだけでなく、任意のカスタムグラフィックや複雑なタグを入れたい」という要求に対する完全解です。
1. `_Slot/Empty` という名前に空のAuto Layout（サイズ 0x0、または最小サイズ固定）を持つコンポーネントを作成。
2. 親コンポーネント（例: `ModalHeader`）のコンテント挿入部に `_Slot/Empty` のインスタンスを配置。
3. そのインスタンスに対して `Content Slot` という Instance Swap Property を定義。
4. 開発者やデザイナーは、後から自作した任意のコンポーネントを `Content Slot` 経由で差し込む。
これにより、親コンポーネントの構造（PaddingやGap）を維持したまま、中身だけを無限に拡張可能 になります。
—
4. デザインシステムとコード（React / TypeScript）の完全同期
Figma上のプロパティ設計は、そのままフロントエンドの `Props` 設計と1:1で対応していなければなりません。以下は、本設計をそのままコードに落とし込むためのJSON形式のコンポーネント仕様書（Tokens / Component Spec）のベストプラクティスです。
`avatar-component.spec.json`
{
“$schema”: “http://json-schema.org/draft-07/schema#”,
“name”: “Avatar”,
“description”: “高度に抽象化されたアバターコンポーネントの仕様定義”,
“properties”: {
“size”: {
“type”: “string”,
“enum”: [“sm”, “md”, “lg”, “xl”],
“default”: “md”,
“figmaType”: “Variant”
},
“avatarImage”: {
“type”: “string”,
“description”: “アバター画像のインスタンス切り替え”,
“default”: “_Avatar/Image/Default”,
“figmaType”: “InstanceSwap”,
“preferredInstances”: [
“_Avatar/Image/Default”,
“_Avatar/Image/UserPlaceholder”,
“_Avatar/Image/CompanyPlaceholder”
]
},
“statusIcon”: {
“type”: “string”,
“description”: “オンライン状態を示すステータスアイコン”,
“default”: “_Avatar/Status/Offline”,
“figmaType”: “InstanceSwap”,
“preferredInstances”: [
“_Avatar/Status/”
]
},
“showBadge”: {
“type”: “boolean”,
“default”: false,
“figmaType”: “Boolean”,
“description”: “バッジの表示/非表示切り替え”
}
},
“codeMapping”: {
“reactComponent”: “
“importPath”: “@/components/ui/Avatar”
}
}
この仕様ファイルを単一の真実（Single Source of Truth）として扱い、Figmaとコード（Reactの `Type definitions`）の双方をビルドパイプラインで自動同期させるのが現代のテックリードの仕事です。
—
5. 爆速開発を実現するキーボードショートカット＆神プラグイン
Figma作業の速度を極限まで高めるための、現場必須のショートカットとプラグインです。
開発スピードを激変させる隠れたキーボードショートカット
| ショートカット (Mac) | 機能 | 活用シーン |
| :— | :— | :— |
| `Enter` | 子階層へ全一括ダイブ | 複数選択したコンポーネント内の全子要素を一括選択する |
| `Shift + Enter` | 親階層へ全一括ジャンプ | ディープな階層から一瞬で親コンポーネントに戻る |
| `Cmd + R` | 一括リネーム (Batch Rename) | アンダースコア `_` の一括付与や正規表現置換 |
| `Shift + I` | インスタンス・資産ランチャー | コンポーネント検索窓を開き、ドラッグ＆ドロップで配置 |
| `Option + Cmd + K` | コンポーネント作成 | アナログな右クリックを完全に排除 |
開発効率を高める神プラグイン4選
1. Master
- 用途: 既に作成して散らばってしまった要素を、後から既存のメインコンポーネントのインスタンスに一括変換する。
2. Tokens Studio for Figma (Figma Tokens)
- 用途: JSONベースでデザインシステムを管理し、Instance SwapのルールやTokensをGitリポジトリへ自動同期（Sync）する。
3. Component Properties Generator
- 用途: 既存のレイヤー構造からVariantやInstance Swap Propertyをワンクリックで自動推論・生成する。
4. Instance Switcher
- 用途: ネストされた深い階層のインスタンス切り替えを、キーボード操作のみで爆速で行う。
—
6. チーム開発で絶対守るべきコンポーネント運用ルール
コンポーネントシステムは、構築した瞬間から風化が始まります。チーム全体でクオリティを維持するための運用原則を以下のように規定してください。
チーム共有化ルール（レギュレーション）
1. 「直接選択してのカラー・アイコン変更」の完全禁止
- 破綻の最大の原因です。キャンバス上のコンポーネント内部をダブルクリックして色を変えたり、手動でアイコンを貼り替えることを禁止します。必ず 「右サイドバーのプロパティパネル」 経由で変更させてください。
2. 非公開コンポーネントの命名徹底 (`_` Prefix)
- Instance Swapの選択肢としてのみ存在する末端パーツには、必ず頭に `_` をつけること。ライブラリのトップレベルを散らかす行為は「コードにおけるグローバル変数の汚染」と同義です。
3. TypeScriptのProps名とFigmaプロパティ名の完全一致
- Figmaで `Status Icon` とするなら、コード側も `statusIcon`（キャメルケース）または `Status Icon`（Figma表記に合わせる）とし、デザイナーとエンジニアが会話する際の命名対話コストをゼロにします。
—
結論：美しさは「使いやすさ」の中に宿る
コンポーネントシステムの美しさは、見た目のビジュアルではなく「使う人がどれだけ迷わずに操作できるか」という構造の洗練度で決まります。
今回解説した `Instance Swap Property` の高度なネスト活用と `Preferred Instances` の設計を徹底すれば、デザインファイル内での無駄なディープクリックは全滅し、エンジニアはコードのPropsと完全に同期したFigmaコンポーネントから正確な意図を読み取れるようになります。
今すぐ自社システムのアバターやボタンコンポーネントを開き、深すぎるレイヤー構造をリファクタリングしましょう。その1行のプロパティ定義が、チーム全体の開発スピードを劇的に加速させるはずです。