【テクニカル・上級編】Figmaの「Component Property」と「Boolean」を組み合わせた無限に拡張可能な汎用カードコンポーネントの作り方 – UI/UX・デザインツール活用バイブル

限界突破のコンポーネント設計：Figma PropertyとBooleanによる「ゼロ・レイヤー肥大化」カードコンポーネントの構築手法

デザインシステムが成長フェーズからスケールフェーズへと移行する際、最も高確率でチームを崩壊させる癌（がん）は何だと思うか？

それは、「カードコンポーネントの無限肥大化」だ。

ECサイトのプロダクトカード、SaaSのダッシュボード、記事のフィード。あらゆる文脈で「ちょっとしたバリエーション違い」が発生するたびに、ジュニアやミドルクラスのデザイナーがVariant（バリアント）を量産する。結果として、1つのカードに数百個のVariantがぶら下がり、Figmaのメモリ消費量は跳ね上がり、Auto Layoutの再計算地獄によってキャンバスはカクつく。エンジニアが実装に落とし込む際も、Figmaのインスペクターは使い物にならなくなっている。

これを解決するのが、Component Property（コンポーネントプロパティ）とBoolean（真偽値）変数を極限まで突き詰めた「アトミック・マトリクス構造」だ。

本稿では、数千コンポーネントを抱える大規模デザインシステムを破綻させず、かつAPI連携や自動テストまで視野に入れた、プロトタイピングの領域を越えた「システム設計」の極意を伝授する。

—

1. 肥大化の元凶：「Variant乱用病」の構造的欠陥

多くのチームが犯す最大の過ちは、「状態の組み合わせをすべてVariantで表現しようとすること」だ。

例えば、以下のような仕様を持つカードを考えてみよう。

  • サムネイル画像（有 / 無）
  • バッジ（有 / 無 / テキスト可変）
  • タイトル（1行 / 2行）
  • サブタイトル（有 / 無）
  • 進捗バー（有 / 無）
  • アクションボタン（単体 / 2択 / 無）

これを愚直にVariantの掛け合わせで作るとどうなるか？
$2 \times 3 \times 2 \times 2 \times 2 \times 3 = 144$ 通りのVariantが生成される。これはシステムとして完全に破綻している。レイアウト構造に変更が生じた際、144個すべてを手動で修正する地獄が待っている。

エキスパートの解：構造の分解とBooleanの極限活用

真にスケーラブルなコンポーネント設計とは、「レイアウトの骨格（Layout Structure）は1つに固定し、内部パーツの生死（Existence）とコンテンツ（Content）をPropertyに委譲する」ことだ。

FigmaのComponent Propertyにおける `Boolean` は、単なる「表示・非表示のスイッチ」ではない。DOMツリーの条件付きレンダリング（Conditional Rendering）をビジュアルでエミュレートするための最適化レイヤーである。

—

2. 実装アーキテクチャ：ゼロ・レイヤー肥大化カードの構築

ここからは、実際に「無限に拡張可能でありながら、内部構造が極限までスリムなカード」の構築手順を、レイアウトエンジニアの視点で解説する。

Step 1: オートレイアウトの「ネスト（入れ子）戦略」

カード全体を一つの巨大なAuto Layoutフレームにしてはならない。セクションごとにコンポーネントを完全に分離し、マスターカード内部でスロット（Slot）的に組み込む。

[Master Card Component] (Auto Layout: Vertical, Gap: 12px)
├── 1. Media Container (Auto Layout) [Boolean: hasMedia]
│ └── Image / Video Slot
├── 2. Header Block (Auto Layout: Vertical, Gap: 4px)
│ ├── Badge Row (Auto Layout: Horizontal) [Boolean: hasBadge]
│ └── Title Text (Text Property: titleText)
├── 3. Body Block (Auto Layout: Vertical) [Boolean: hasBody]
│ └── Description Text (Text Property: bodyText) [Text #2 lines constraint]
└── 4. Footer Block (Auto Layout: Horizontal, Space-between)
├── Metadata (Text Property: metaText) [Boolean: hasMeta]
└── Action Group (Auto Layout) [Boolean: hasAction]

Step 2: Booleanプロパティの厳密な命名規則とバインディング

Figmaの右サイドバーに並ぶプロパティ群が汚染されているチームのプロダクトは、例外なくコード品質も低い。プロパティの命名はAPIのスキーマ定義と同様に厳格に行うべきだ。

  • `is[Noun]Visible` ではなく、単に `Has [Element]` （例: `Has Media`, `Has Badge`）とするのがFigmaのUIUXにおいて最も認知負荷が低い。

【重要】ネストされたレイヤーのプロパティ伝播（Property Exposing）
子コンポーネントのレイヤーの可視性を、親マスターコンポーネントのプロパティに直接バインドさせる。
1. 子要素のレイヤー（例：「Badge」フレーム）を選択。
2. プロパティパネルの「Layer Visibility（目のアイコン）」の右側にあるダイヤ型アイコン（Create boolean property）をクリック。
3. `Has Badge` というプロパティ名で紐付ける。

これにより、インスタンス化した際に、親のプロパティパネルからトグル一つでDOMの存在を制御できるようになる。

—

3. メンテナンス性を落とさないためのプロの技：レイヤー制約と「Min-width/Height」ハック

Booleanで要素を非表示（`false`）にした際によくあるバグが、「消したはずの領域にパディング（余白）が残り、不自然な空白が生じる現象」だ。

FigmaのAuto Layoutは、非表示になった要素のスペースを自動的に詰める（Collapsed）仕様になっているが、パディングを持つ親フレームの挙動や、絶対配置（Absolute position）が混ざると、この自動縮退がバグる。

ハック：ゼロ・グラビティ・コンテナの採用

条件付きで表示が切り替わるエリアは、必ず「中身が空のときに高さ・幅が完全に0になるラッパーフレーム」で包むこと。

  • ラッパーのAuto Layout設定：
  • Direction: Vertical / Horizontal
  • Spacing: 0
  • Padding: 0
  • Resizing: Hug / Hug

この構造を徹底することで、Booleanをオフにした瞬間にレイアウトが美しく巻き上がり、ピクセルパーフェクトな崩れのないカードが実現する。

—

4. 自動化とスケーリング：API / CLIによるデザインシステム管理

ここまでの設計を人力で行うのは、もはやモダンなエンジニアリングの範疇ではない。Figma REST APIやPlugin APIを活用し、コンポーネントの構造やプロパティの整合性をプログラムで担保するべきだ。

以下は、Figma Plugin APIを使用して、指定したカードコンポーネントのBooleanプロパティとレイヤーのバインディング漏れを検知・自動修正するTypeScriptスクリプトの概念実証（PoC）コードである。

/

  • Figma Plugin API Script: Validate & Enforce Card Component Properties
  • アーキテクト向け自動化パイプラインの一部として動作する検証スクリプト

/

interface CardNodeValidationResult {
nodeId: string;
nodeName: string;
missingBooleanBindings: string[];
}

function auditCardComponent(masterCard: ComponentNode): CardNodeValidationResult {
const requiredBooleanProperties = [‘Has Media’, ‘Has Badge’, ‘Has Meta’, ‘Has Action’];
const existingProperties = Object.keys(masterCard.componentPropertyDefinitions);

const missingBindings: string[] = [];

// 必須プロパティが定義されているかチェック
for (const prop of requiredBooleanProperties) {
if (!existingProperties.includes(prop)) {
missingBindings.push(prop);
}
}

// 子レイヤーとプロパティの紐付け検証（簡易ロジック）
// 実際の実装ではnode.boundPropertiesを走査する

return {
nodeId: masterCard.id,
nodeName: masterCard.name,
missingBooleanBindings: missingBindings,
};
}

// 実行エントリーポイント
function runDesignSystemAudit() {
const selection = figma.currentPage.selection;
if (selection.length === 0) {
figma.notify(‘監査対象のマスターカードを選択してください。’);
return;
}

selection.forEach((node) => {
if (node.type === ‘COMPONENT’) {
const result = auditCardComponent(node);
if (result.missingBooleanBindings.length > 0) {
console.warn(`[DesignSystem Warning] カード “${result.nodeName}” に不足しているプロパティ:`, result.missingBooleanBindings);
figma.notify(`警告: ${result.nodeName} のプロパティ定義に不整合があります。コンソールを確認してください。`);
} else {
figma.notify(`成功: ${result.nodeName} は設計基準を満たしています。`);
}
}
});
}

// 実行
runDesignSystemAudit();

このようなスクリプトをCI/CDパイプライン（Figma Actionsや独自Webhooks）に組み込み、デザインファイルがMainブランチにマージされる前に自動バリデーションを通す。これが、真の意味での「エンジニアリングされたデザインシステム」である。

—

5. 結び：デザインとコードの境界線を消し去るために

FigmaのComponent PropertyとBooleanの組み合わせは、単なる「デザインを楽にする便利機能」ではない。これは、UIの構造を抽象化し、フロントエンドのコンポーネント設計（React/VueのProps設計）と完全にシンクロさせるための最強のインターフェースだ。

Variantの数に依存した力技の設計は今すぐ捨て去れ。
プロパティを洗練させ、構造を極限まで削ぎ落とし、APIやスクリプトで統制された「無限に拡張可能な汎用カード」こそが、プロダクトを次のステージへ押し上げる唯一の解である。

スポンサーリンク
タイトルとURLをコピーしました