Figmaの「Instance Swap Property」を極める：コンポーネント・アーキテクチャの極致
デザインシステムが「静的なアセット集」である時代は終わった。今、我々が構築すべきは、実行時（レンダリング時）の柔軟性を担保しつつ、メモリ消費とレイヤー構造を極限まで最適化した「コンポーネント・エンジン」である。
今回は、FigmaのInstance Swap Propertyを単なる「入れ替え機能」としてではなく、高度な抽象化レイヤーとして掌握するための技術的知見を共有する。
—
1. 抽象化のパラドックス：なぜInstance Swapが必要か
多くのデザイナーが陥る罠は、「Variantの爆発」だ。アイコンの種類が増えるたびにバリアントを増やし、プロパティが数十個に及ぶコンポーネントは、メンテナンス不能な技術的負債となる。
Instance Swap Propertyの本質は「依存性の注入（Dependency Injection）」にある。
コンポーネント自身が具体的な子要素を保持するのではなく、プロパティとして外部から「注入」することで、以下のメリットを得る。
- レイヤー深さの固定化: 構造がフラットになり、描画コストを低減。
- メモリ・フットプリントの削減: 大量のバリアントを定義するよりも、インスタンスを参照する方がFigmaのメモリ消費効率が圧倒的に良い。
—
2. 実践：スケーラブルなアイコン・アーキテクチャ
アイコンを直接コンポーネント内に埋め込まず、`IconComponent`というインターフェースを定義せよ。
設計手順：
1. Atomic Icon Libraryの構築: すべてのアイコンを独立したコンポーネントとして定義。
2. Instance Swapの設定: 親コンポーネント（例：Button）に `Icon` プロパティを付与。
3. Preferred Valuesの制限: ここが重要だ。`Preferred Values` を使って、そのコンポーネントで利用可能なアイコンを「Design SystemのIconセット」に制限する。これで開発者は迷わない。
—
3. DevOps的アプローチ：APIとスクリプトによる完全自動化
手動で数千のインスタンスプロパティを設定するのは狂気の沙汰だ。我々はコードを書く。Figma Plugin APIを使い、コンポーネントのメタデータを解析・自動生成するスクリプトを走らせる。
以下のスクリプトは、選択したコンポーネントセットに対して、特定の命名規則に基づきインスタンススワッププロパティを自動割り当てする雛形である。
/
- Figma Plugin APIを用いた自動設定スクリプト
- 命名規則: “Icon/Set/Name” に基づいてスワッププロパティを自動アサイン
/
async function autoAssignInstanceSwap(node: ComponentNode) {
const icons = figma.currentPage.findAll(n => n.type === “INSTANCE” && n.name.startsWith(“Icon/”));
// コンポーネントのプロパティ設定を更新
// Instance Swap Propertyを定義して、フィルタリングされたアイコンを割り当てる
node.setProperties({
“Icon”: {
type: “INSTANCE_SWAP”,
defaultValue: icons[0].mainComponent,
preferredValues: icons.map(i => i.mainComponent)
}
});
console.log(`Optimized component: ${node.name}`);
}
—
4. パフォーマンス・ハック：レンダリング負荷の最適化
大規模なデザインシステムにおいて、Instance Swapの多用はブラウザ上のFigmaのレンダリング負荷を上げる可能性がある。以下の指針を守れ。
- ネストの深さを3階層以内に抑える: Instance Swapの中にInstance Swapを入れ子にすると、Figmaの再計算ロジックが指数関数的に重くなる。
- インスタンスの切り離しを許容する: 複雑すぎるコンポーネントは、あえて「Detached Instance（切り離し）」を許可し、Local Componentとして最適化する戦略も必要だ。
- Lazy Loadingを意識した構造: 頻繁に使わない大規模なモーダルなどは、メインのコンポーネントから切り離し、別ファイルで管理して必要に応じてライブラリとしてインポートする。
—
5. 伝説的アーキテクトからの提言
デザインシステムとは、「制約のデザイン」である。
Instance Swapを単なる便利機能として使うのではなく、「どの要素を差し替え可能にするか」というインターフェース設計として捉え直せ。コンポーネントのプロパティをAPIの型定義のように厳格に管理すれば、デザイナーとエンジニアの間の「手戻り」はゼロに近づく。
君たちが今日構築するコンポーネントは、単なる図形ではない。それは組織の生産性を左右する「コード」である。
もし、貴殿がさらに深いレベルでの自動化や、デザインシステムのCI/CDパイプライン構築に興味があるなら、次はFigma APIとGitHub Actionsを連携させた「デザイン・リント」の世界へ足を踏み入れるべきだ。
技術は裏切らない。洗練された構造だけが、複雑なプロダクトを救うのだ。