Figmaコンポーネント設計の基本。AIに渡せる指示文つき

こんにちは、bravesoftのUI/UXデザイナーの池田です。アプリやWebサービスの設計に携わっています。

これまで、アプリや Web サービスの設計で、共通のデザインシステムをもとに複数 サービスのコンポーネントを作る案件や、一からデザインシステムを組み立てる案件に携わってきました。 

最近は、Figma のコンポーネント設計も AI に任せられる場面が増えています。でも、 自分が普段編集しやすい形やルールで作ってもらうには、ルールを言語化して伝える必要があります。そこで今回は、案件の中で意識してきたコンポーネント設計の判断を、ルールとして整理してみました。 

デザインシステムについては、全3編で書く予定です。第1編はコンポーネント設計、第2編は Variables（バリアブル・変数）と Style、第3編は複数人で作業するときのルールを取り上げます。

この記事では、AI に Figma のコンポーネントを作ってもらいたい方や、生成されたものをレビューしたい方に向けて、設計のルールを紹介します。

前半では、その前提になるコンポーネント設計の基本を説明し、後半ではAIに渡せる指示文にまとめています。基本をすでに知っている方は、6章の指示文から読むこともできます。

1. 基本の用語説明

コンポーネントは、ボタンや入力欄、カードなど、画面の中で繰り返し使う要素を再利用できるようにしたものです。まず、元になるMain component（メインコンポーネント）を一つ作ります。そこから作成し、各画面に配置して使うものが Instance（インスタンス）です。

Main componentは、部品の設計図のようなものです。設計図を直すと、つながっているInstanceにも変更が反映されます。たとえばボタンの高さを変えたいときは、画面ごとに直す必要はありません。Main componentを一度直せば、すべてのInstanceに反映されます。

Instanceでは、文言やアイコンを画面に合わせて変えられます。高さや余白などの共通部分は、Main componentから受け取ります。画面ごとの差分は残したまま、共通部分だけを更新できます。

Variants と Component properties の使い分け

コンポーネントを設計するときは、大きさや状態の違いと、文言やアイコンの変更 を分けて考えています。

Variants（バリアント）
大きさや状態の違いを、別バージョンとして用意する機能です。たとえば、ボタンの small・medium・large や、default・hover・ disabled などを、一つの Component set（コンポーネントセット）にまとめます。

Component properties（コンポーネントプロパティ）
文言やアイコンなど、コンポーネントの一部分を変更するために設定する項目です。文言を書き換える Text、 表示・非表示を切り替える Boolean、部品を差し替える Instance swap などがあります。

たとえばボタンなら、大きさの違いは Variants で用意し、文言は Text property で 変更します。文言が違うだけなら、別の Variant を作る必要はありません。 Figma では Variant も Component properties の一種ですが、この記事では使い分けを説明するため、分けて呼びます。 なお、名前の似た Variables（バリアブル・変数）は、色や余白などの値を共通で管理する仕組みです。こちらは第2編で説明します。

2. 基本パーツのコンポーネント設定

ここでは、よく使う基本パーツについて、コンポーネント名・プロパティ名・値の付け方をまとめます。パーツごとに名前がばらつかないよう、私が普段使っているルールを一覧にしました。 

まず基本となるデフォルトのコンポーネントを作ります。そこからステータスや状態が必要など別verが必要な場合は、Variantで別verとして追加します。その後オンオフなど切り替えだけで変更できるアイコンの表示・非表示や文言の変更は Variants を増やさず、Text や Boolean などの Component properties で設定します。 各プロダクトで必ず使う基本要素の設定例を記載しています。必要なプロパティや状態はプロダクトによって変わる ので、実際の画面で使うものを選んで設定しています。またコンポーネント名とプロパティ名、Variant の値は、ローワーキャメルケースに揃えています。先頭を小文字にして、単語の区切りを大文字にする書き方です。

◆ 別バージョン（Variant property）　◇ 部分的な切り替え（Component properties）

ボタンや入力欄のような小さなパーツは、基本的に一つのコンポーネントで完結します。変化も一つの要素の中で起きるので、Variant propertyも決めやすくなります。一方、リストやテーブルは、見出しと行のように、複数のコンポーネントを組み合わせて作ることが多くなります。そのため、次の章で分けて見ていきます。

3. リストとテーブルのコンポーネント設定

リストやテーブルで決めどころになるのは、statusをセル・行・テーブルのどこに持たせるかです。まず、基本の設定は次のとおりです。

複数のコンポーネントを組み合わせる場合の設計方法に、決まった正解はありません。私は「どこまでが同時に変わるか」で分けると、考えやすいと感じています。

セルに持たせる
一つの入力欄だけがerrorになる、特定のセルだけがselectedになるなど、変化がセルの中で完結する場合。

行に持たせる
選択によって背景色、チェックボックス、操作ボタンが一緒に変わるなど、複数のセルがまとまって変化する場合。

テーブル全体に持たせる
loading、empty、errorなど、一覧そのものの表示が切り替わる場合。

この区切り方なら、テーブル全体にすべての組み合わせをVariantsとして持たせずに済みます。もしテーブル全体で持つと、「3行目だけ選択中で、2列目のセルだけエラー」のような組み合わせを、すべて別のVariantとして作ることになります。そうならないように私は切り分けて設定しています。リストや検索結果も同じです。一件分のステータスは項目側、loadingや0件表示は一覧側というように、状態が変わる範囲に合わせて分けています。

4. よく使う便利テクニック

ここまで扱ってきたのは、状態や大きさ、文言のように、あらかじめ決められる変化です。ただ、実際に画面を作っていると、部品そのものや中身を差し替えたい場面も出てきます。そうした場面で、作業を楽にするために私がやっていることを二つ紹介します。

アイコンは 差し替えた後も色が残る構造にする

アイコンは、同じ場所で検索、閉じる、戻るなどを切り替えることができるので、 Instance swap と相性のよいパーツです。ただ、差し替えたときに設定していた色 が外れて、付け直しになることがあります。 これは、差し替えるアイコン同士で内部のレイヤー名や構成が違うときに起こりや すいです。レイヤー名と構成がそろっていると、上書きした設定を引き継いでくれるようになります。 

そのため、アイコンの内部は Vector だけのシンプルな構成にして、レイヤー名も icon、vector、stroke などに統一しています。 一覧やナビゲーションのよ うに何度もアイコンを差し替えるところでは、色を付け直す手間が減ります。

モーダルの中身は、Slotsで組み替える

アイコンのように差し替える候補の構造が近い場合は、Instance swap を使っています。一方、モーダルやポップアップは、外枠や閉じるボタンが共通でも、中身はフォーム、説明文、画像など、画面ごとに大きく変わります。

以前は、中身の違いも Variants にして切り替えることがありました。ただ、その方法だと内容が増えるたびに Variant も増えていきます。外枠を共通にしたいだけなのに、その画面でしか使わない中身までコンポーネントとして管理することになり、 Component set が膨らんでいました。 

そこで使っているのが、比較的新しく追加された Slots です。Slots は、Main component の中に用意する、Instance 側で中身を自由に組み替えられるエリアです。Figma では、Component properties の一種にあたります。 作り方は、Main component 内で本文用のフレームを選び、右クリックから「Convert to slot」を選びます。外枠は共通のコンポーネントとして管理しながら、内側だけを Instance 側で組み替えられます。

Slots には、初期コンテンツや優先インスタンス（差し替え候補）も設定できます。 最初の形を用意しておいて、必要な画面では自由に変更できます。 私の場合は、枠、余白、閉じるボタンなど、どの画面でも共通にしたい部分を Main component に残し、画面ごとに変えたい本文エリアを Slots にしています。 

Variants は決まった状態を切り替えるもの、
Slots は共通部分を残したまま中身を組 み替えるもの、
と考えると使い分けやすくなりました。

ただ、使用中に問題が起きたこともありました。Main component を編集したときに、Instance 側で変更していた中身が元に戻ってしまいました。 

原因は特定できていませんが、Figma の仕様では、Slots のプロパティを削除すると Instance 側の中身が初期状態に戻ります。複数人で触っているデザインシステムなので、誰かの操作が重なった可能性もあります。 今回はバージョン履歴から復元できましたが、この経験から、Slots を使っている Main component は、基本的に更新を避けるようにしています。更新するときは、 Instance 側の中身が戻っていないか確認しながら進めてください。

コンポーネント設計の要点

ここまで説明した命名ルールと、コンポーネント設計の要点をまとめます。

• コンポーネント名とプロパティ名、Variant の値はローワーキャメルケースに揃える
• 状態や大きさは Variants に、文言やアイコンは Component properties 
• 複数の要素が一緒に変わる場合は、セル・行・一覧のどこまでが動くかを見て、状態を持たせる階層を決める
• アイコンを差し替えるときは、内部の構造をそろえて色を引き継ぐように
• モーダルのように外枠が共通で中身が変わるものは、Slots で中身だけを替える

コンポーネントを作ること自体は難しくありません。
コンポーネントを作るときは、画面に配置したあと、どのように変更したり差し替えたりするかまで考えるようにしています。そうすると、必要な設定や、どの階層に状態を持たせるかを決めやすくなります。
あと設計については、ここでは詳しくは書きませんが、ファイルが重くならないように、階層を深くしすぎないシンプルな構成を意識しています。複数の画面を扱うので、後からの変更や一括変更がしやすいような柔軟性のある設計にしたいと考え制作しています。

5. AIに渡すルール

ここまでの命名ルールと設計の考え方を、AI にそのまま渡せる指示文 （Markdown）にまとめました。基本パーツごとの設定と、作ったあとの確認項目も含めています。

# Figmaコンポーネント設計ルール
 
## 前提
コンポーネントの変化は、2種類に分けて設計する。
- 表示・非表示や文言ではおさまらない変化（大きさ・状態）→ 別バージョンとして Variants
- 部分的な切り替え（文言・アイコン・表示と非表示）→ Component properties（中身を大きく替えるものは Slots）
このルールの対象は、コンポーネントだけ。色・文字・余白、Auto Layout、既存コンポーネントの再利用は含まない。
 
## ルール
1. 状態（status）は、別のコンポーネントにせず、Variantsにまとめる。
2. 文言はText property、アイコンの差し替えはInstance swap、表示の切り替えはBoolean propertyにする。
3. リストやテーブルは、セル・行・テーブル全体のどこで状態が変わるかを見て、状態を持たせる階層を決める。
   - 一つのセルだけが変わる → セルに持たせる
   - 複数のセルが一緒に変わる → 行に持たせる
   - 一覧そのものが変わる（loading・emptyなど）→ テーブル全体に持たせる
4. 外枠が共通で、中身が画面ごとに変わるもの（モーダルなど）は、Variantsを増やさず、本文エリアをSlotsにする。
   - Slots を使っている Main component は、基本的に更新を避ける。更新するときは、Instance側の中身が戻っていないか確認する。
5. アイコンは、内部をVectorだけの構成にし、レイヤー名をicon／vector／strokeなど同じ名前にそろえる。
 
## 名前の付け方
- コンポーネント名は、見た目（blue、bigなど）ではなく、役割が分かる名前にする（calendarModalなど）。
- ローワーキャメルケースにそろえ、ハイフンやアンダースコアを混ぜない。
- 略語は使わない（btn、tfなど）。
- プロパティ名は、状態はstatus、大きさはsize、文言はlabel、アイコンの差し替えはicon、表示・非表示はshowから始める（showIconなど）。
 
## 部品ごとの設定
- button：size（small／medium／large）、status（current／default／hover／disabled）、label、icon、showIcon
- textBox：status（empty／filled／disabled／error／focused／inputting）、label、inputText、helperText、icon、showIcon
- tab：status（default／selected／disabled）、label、icon、showIcon
- tag：type（カテゴリーやステータスごとの色・アイコン）、label
- list：基本単位は一件分の項目。status（open／endedなど）
- table：セル、行・列の順に組み立てる。status（selected／errorなど）
 
## 作ったあとの確認
- 状態ごとに別のコンポーネントができていないか。
- statusの値は、部品ごとの設定にあるものか。必要な状態が抜けていないか。
- 表示・非表示のプロパティは、showから始まっているか。
- アイコンの内部は、icon／vector／strokeにそろっているか。
- 名前は、役割が分かり、ローワーキャメルケースか。

私は、こうした基準をClaudeのスキルに入れて、生成やコンポーネント化の参考にしています。試している最中です。AIにコンポーネントを作ってもらうときの、ルールづくりの参考になればうれしいです。

---

今回まとめたのは、コンポーネント設計のルールです。デザインシステム全体をAIに作ってもらうには、色・文字・余白を管理する Style や Variables のルールも必要だと考えています。 

次の第2編では、その Style と Variables も精度高くAIに生成してもらえるように、どんなルールを伝えているかを紹介します。特にカラーや文字は一括生成して使うことが多いので、コンポーネントと合わせて生成できれば、あとからの調整の手間も減らせます。 

ちなみに第3編では少し変わって、デザインシステムを複数人で使い、更新していくためのルールについてを取り上げる予定です。

第2編まで読むと、コンポーネントに加えて色・文字・余白のルールもそろうので、プロジェクトの始まりに、意図に近いデザインシステムをAIにサクッと作ってもらいやすくなると思います。ぜひ次も読んでいただけるとうれしいです。