Figma命名規則ガイド｜コンポーネント管理を整理する実務テクニック

SHARE

Figmaのコンポーネントが50個を超えたあたりから、探すのに時間がかかり始めます。

100個を超えると、もう誰も全体像を把握できません。「あのボタン、なんて名前だっけ」とSlackで聞く回数が増えたら、それは命名規則を見直すサインです。

この記事では、コンポーネント命名の3原則と、すぐコピペできるチートシートを用意しました。まずは早見表だけでも持ち帰ってください。

目次

コンポーネント命名の3原則

ルールはシンプルです。

[カテゴリ] / [要素名] / [バリエーション]
原則 内容 例
カテゴリで分ける UIの役割で最上位を分類 Base/, Common/, Feature/
要素名で特定する 何のコンポーネントか一目でわかる名前 Button, Card, Modal
バリエーションで区別する サイズ・スタイル・状態の違いを末尾に Primary, Large, WithIcon

この3層だけ守れば、コンポーネントが500個になっても破綻しません。

命名チートシート（コピペ用）

現場でよく使うUI要素の命名パターンを一覧にしました。そのままFigmaに貼れます。

UI要素 命名パターン バリエーション例
Button Button/[Style]/[Size] Button/Primary/Large,
Button/Ghost/Small
Input Input/[Type]/[State] Input/Text/Default,
Input/Password/Error
Card Card/[用途]/[レイアウト] Card/Blog/WithImage,
Card/Product/Horizontal
Modal Modal/[Type]/[Size] Modal/Alert/Small, Modal/Form/Large
Nav Nav/[Type]/[配置] Nav/Menu/Horizontal,
Nav/Breadcrumb/Default
Form Form/[要素]/[State] Form/Select/Active,
Form/Checkbox/Checked
Badge Badge/[Style]/[Size] Badge/Status/Small,
Badge/Count/Default
Avatar Avatar/[Shape]/[Size] Avatar/Circle/Large,
Avatar/Square/Small

バリアントのプロパティ命名

コンポーネント名とは別に、バリアントのプロパティにも命名ルールが必要です。混同しやすいポイントなので、明確に分けておきます。

コンポーネント名:  Button/Primary/Large
                   ↑ Figmaのレイヤー名。スラッシュで階層化

プロパティ名:      size = Large / style = Primary / state = Default
                   ↑ バリアントのプロパティ。右パネルで切り替える値

プロパティの命名ルール:

種類 プロパティ名 値の例
テキスト label, subtext,
placeholder		 任意のテキスト
ブール hasIcon, isDisabled,
showBadge		 true / false
選択 size, variant, alignment Small, Medium, Large

ブールは has / is / show
で始めると、何を切り替えるプロパティなのか迷いません。

命名の基本ルール

チートシートの背景にある考え方を押さえておきます。

PascalCaseに統一する

Button/Primary/Large     ← PascalCase（推奨）
button/primary/large     ← camelCase
button_primary_large     ← snake_case

Figmaはスラッシュ /
をフォルダ区切りとして扱います。PascalCaseで統一すると、アセットパネルの表示が揃い、視認性が上がります。

正直、PascalCaseかcamelCaseかは好みの問題です。ただし、チーム内で1つに決めて絶対に混在させない。これだけは譲れません。

省略形ルール

省略形は便利ですが、統一しないと逆に混乱します。チームで使う略語は一覧にしておきましょう。

正式名 省略形 使ってOK？
Background Bg OK
Navigation Nav OK
Information Info OK
Button Btn NG（短すぎて検索で引っかからない）
Image Img NG（同上）
Description Desc OK（長いので省略推奨）

判断基準は「Figmaの検索窓で引っかかるか」。Btnで検索する人はほぼいません。Buttonで検索します。

用語を統一する

地味だけど、ぶっちゃけここが一番崩れやすいポイントです。

サイズ:    Small / Medium / Large  （sm / md / lg と混ぜない）
状態:      Default / Hover / Active / Disabled
スタイル:  Primary / Secondary / Ghost / Outline

1人が Hover と書き、別の人が OnHover
と書いた瞬間に、命名規則は壊れます。用語集はNotionでもスプレッドシートでもいいので、1つの場所にまとめてください。

フォルダ構造テンプレート（コピペ用）

コンポーネントの階層構造は、Base
/ Common / Feature の3層で設計するのがおすすめです。

Design System/
├── Base/                      ← 最小単位。他のコンポーネントの材料
│   ├── Button/
│   │   ├── Button/Primary/Large
│   │   ├── Button/Primary/Medium
│   │   ├── Button/Primary/Small
│   │   ├── Button/Secondary/Large
│   │   └── Button/Ghost/Medium
│   ├── Input/
│   │   ├── Input/Text/Default
│   │   ├── Input/Text/Error
│   │   └── Input/Password/Default
│   ├── Icon/
│   │   ├── Icon/System/Arrow
│   │   ├── Icon/System/Close
│   │   └── Icon/Social/Twitter
│   └── Badge/
│       ├── Badge/Status/Success
│       └── Badge/Count/Default
│
├── Common/                    ← 複数ページで使い回すパーツ
│   ├── Card/
│   │   ├── Card/Blog/WithImage
│   │   ├── Card/Blog/TextOnly
│   │   └── Card/Product/Horizontal
│   ├── Modal/
│   │   ├── Modal/Alert/Small
│   │   └── Modal/Form/Large
│   └── List/
│       ├── List/Product/Default
│       └── List/User/WithAvatar
│
└── Feature/                   ← 特定の画面専用
    ├── Dashboard/
    │   ├── Dashboard/StatCard
    │   └── Dashboard/Chart
    └── Profile/
        ├── Profile/UserInfo
        └── Profile/ActivityFeed

なぜ3層なのか？

  • Baseはデザイントークンと直結する最小部品。変更の影響範囲が最も大きいです
  • CommonはBaseを組み合わせた汎用パーツ。新規ページを作るときの「棚」になります
  • Featureは画面固有。再利用を前提としないので、命名もわかりやすさ優先でOKです

デザイントークンをBaseコンポーネントに適用しておけば、カラー変更やスペーシング調整を一括で反映できます。

よくある失敗3選

ここからは実際にやりがちな失敗パターンを紹介します。心当たりがあるものから直してみてください。

失敗1: 時系列命名

button_1
button_new
button_latest
button_final
button_final_v2        ← もはやギャグ

「新しいやつ」「最終版」は1週間後には意味を失います。役割で名前を付けましょう。

Button/Primary/Large     ← 何に使うか一目でわかる
Button/Secondary/Small   ← サイズも役割も明確

失敗2: 略語の不統一

BtnPrimary
SecondaryButton
ghost_btn
OutlineButton

同じチーム内でこれが混在しているプロジェクト、けっこう見かけます。

ルールは「ButtonはButtonと書く。略さない。例外なし」でいいんです。シンプルなルールほど守られます。

失敗3: フラットな構造

PrimaryButton
SecondaryButton
GhostButton
TextInput
PasswordInput
BlogCard
ProductCard

フォルダ階層がないと、コンポーネントが50個を超えた時点でアセットパネルがカオスになります。

スラッシュ /
を入れるだけでFigmaが自動的にフォルダ化してくれるので、Button/Primaryのように書き換えるだけ。5分で終わる改善です。

チーム運用のコツ

命名規則は作って終わりではありません。チームで運用し続ける仕組みが必要です。

用語集を1ページにまとめる

Notionやスプレッドシートに、以下の項目を1ページにまとめておきます。

項目 記載内容
ケースルール PascalCase統一
省略形リスト Bg, Nav, Info は OK / Btn, Img は NG
サイズ表記 Small / Medium / Large（sm/md/lgは使わない）
状態表記 Default / Hover / Active / Disabled
フォルダ構造 Base → Common → Feature の3層

これを「命名規則v1」として共有ドキュメントに置いておきましょう。

新メンバーのオンボーディング

新しいデザイナーがチームに入ったとき、命名規則のキャッチアップに1日かかるようなら、ルールが複雑すぎます。

おすすめの進め方:

  1. 用語集を渡す（上の表1枚）
  2. 既存コンポーネントを3つ触らせる –
    Button、Card、Modalあたりから
  3. 最初のコンポーネントはペアで作る –
    命名を一緒に考える
  4. レビューで命名だけチェックする –
    デザインのレビューとは分けて

3日目には自走できるくらいが理想です。

ボタンのステート管理との連携

命名規則が決まったら、ステート管理のルールも揃えましょう。Button/Primary/Large
のDefault、Hover、Activeをどうバリアントで表現するか。命名とステート設計はセットで考えると、後から破綻しません。

まとめ

Figmaの命名規則は、突き詰めると3つだけです。

  1. 3層構造 – カテゴリ / 要素名 / バリエーション
  2. 表記を統一 – PascalCase、省略形ルール、用語集
  3. フォルダで分類 – Base / Common / Feature

完璧なルールを最初から作ろうとしなくて大丈夫です。まずはこの記事のチートシートをコピペして、既存コンポーネントのうち一番よく使うものから名前を付け直してみてください。

Figmaコンポーネント設計の全体像はFigmaコンポーネント設計ガイドにまとめています。命名規則と合わせて読むと、設計の意図がより見えてきます。

参考になれば幸いです。

前の記事

Figmaコンポーネントの階層構造、プロの現場で使える設計テク…

次の記事

Figmaのコンポーネント運用を効率化する：プロパティとバリア…