こんにちは！UIデザイナーのYunyです。
- Figmaで作業しているとレイヤー名が「Frame 123」や「Group 45」で埋もれてしまう方
- Claude CodeやCursor等のAIコード生成で、レイヤー構造の乱れによる出力精度の低下に悩んでいる方
- 実務で無理なく続けられるセマンティックなレイヤー命名規則や整理習慣を身につけたい方
Figmaで集中してデザインを作成していると、気づけばレイヤーパネルが「Frame 482」や「Rectangle 12」の山になっていた経験は誰もが一度はあるはずです。
自分自身も以前は見た目が完成していれば問題ないと後回しにしてしまい、修正やハンドオフのたびに目的の要素を探す手間が発生していました。
しかし、デザインデータをClaude CodeやMCP（Model Context Protocol）などのAIツールに連携させてフロントエンドコードを生成する機会が増えたことで、その重要性を強く実感するようになりました。
レイヤー名と階層構造が論理的に整っているデータは、AIが解析するコードの構造やHTMLタグの選定精度にも良い影響を与えてくれます。
今回は、エンジニアへのスムーズなハンドオフはもちろん、AIとの協業でも破綻しない「実務で無理なく続く」Figmaレイヤー命名ルールと管理習慣を整理しました。
現場ですぐに参照できる命名早見表や、AIにレイヤー名を一括整理させるプロンプトも用意しましたので、日々の制作の参考にしてみてください。
- なぜ今、Figmaのレイヤー名が重要なのか？（AI・MCP連携の実務メリット）
- 迷ったらここから！「AIレディ」なFigma命名の基本と考え方
- 1. ページ・セクション単位の命名例
- 2. コンポーネント・カード単位の命名例
- 3. パーツ・最小要素（Atom）の命名例
- 4. レイアウト・構造用コンテナの命名例
- コピペで使える！AIエージェントにレイヤーを自動リネームさせる指示プロンプト
- 手間を最小化する！実務で無理なく続く3つのデータ管理習慣
- 1. Groupを排除し「Auto Layout」を徹底する
- 2. ページとSection機能でステータスを分ける
- 3. 完璧主義を捨てる「引き算の整理術」
- まとめ：意味を持ったデータ構造が開発体験を高める
なぜ今、Figmaのレイヤー名が重要なのか？（AI・MCP連携の実務メリット）
色や装飾ではなくUIにおける役割（セマンティクス）に基づいて英語のkebab-caseで命名し、Auto Layoutで論理的な親子関係を組むことです。これにより、エンジニアへの伝達ミスを防ぐだけでなく、AIが適切なHTMLタグやCSSクラスを推論して出力する前提条件を整えられます。
これまでFigmaのレイヤー整理といえば、チームメンバーへの配慮という文脈で語られる場面が多かった印象があります。
もちろんチーム開発における可読性も不可欠ですが、現在のUIデザインの現場では「AIに対するコンテキストの提供」という直接的なメリットが加わっています。
現在では、MCPサーバーを経由してFigmaのデータを直接LLMに渡したり、CursorやClaude Codeなどのツールを使ってデザインから実装コードを生成するワークフローが定着しつつあります。
AIはデザインの座標情報だけでなく、レイヤー名や階層の親子関係を意味的なメタデータとして解釈しながらHTMLやコンポーネントを組み立てます。
レイヤー整理とあわせてバリアントの増殖を防ぐ設計手法については、以下の記事で詳しく解説しています。
コンポーネント構造をよりスマートに整えたい際に役立つはずです。
もしフレーム名が「Frame 389」、ボタンが「Rectangle 12」のままだと、AIはその要素がどのような役割を持つUIなのかを視覚的な位置関係だけで推測しなければなりません。
その結果、すべての要素が無意味な <div> タグで囲まれ、CSSクラスの意図が読み取れない保守性の低いコードが出力されやすくなります。
一方で、親フレームに section--hero、ボタンに btn--primary という適切な名前が設定されていれば、AIはセマンティックなタグ（<header> や <button>）を的確に選びます。
Dev Modeでコードを確認するエンジニアにとっても、整ったレイヤー名は共通言語としての仕様書の役割を果たしてくれます。
FigmaのDev Modeを活用したエンジニア連携の基礎については、以下の記事で料金体系や機能差分をまとめています。
デザインデータの受け渡しを効率化したい際に役立つはずです。
つまり、現在のFigmaにおけるレイヤー整理とは、「実装の骨組みをデザイン段階で定義する作業」そのものといえます。
迷ったらここから！「AIレディ」なFigma命名の基本と考え方
AIと人間がともに構造を直感的に把握できるようにするためには、共通のベースラインを持っておくと迷いません。
意識したいのは、色や形状といった装飾的な見た目ではなく、UIにおける「役割・機能（セマンティクス）」を名前に反映させることです。
例えば、背景が青いからといって BlueButton と名付けてしまうと、テーマ変更時に名前の不整合が生じ、AIもそのボタンの視覚的優先度を判断しにくくなります。btn--primary や btn--submit のように、そのパーツが果たす機能や優先度を英語のケバブケース（kebab-case）で記述するのが実務でおすすめのベースラインです。
チームの規約やプロジェクトの文脈によって最適な形式は異なりますが、まずは以下の「実務で扱いやすい命名早見表」を基準として持っておくと命名の迷いを大幅に減らせます。
| 対象階層 | 推奨命名パターン（kebab-case） | 具体例 | 想定されるHTMLタグ | 実装・AI連携時のメリット |
|---|---|---|---|---|
| 画面全体 | screen--[画面名] | screen--dashboardscreen--checkout | <main> / <body> | 画面単位のスコープを明確にし、ページ全体のコンポーネント分割が正確になる |
| 大枠セクション | section--[役割] | section--herosection--pricing | <header>, <section>, <footer> | セマンティックタグへの置換が自然に行われ、ランドマーク構造が整う |
| UIカード・ブロック | card--[コンテンツ名] | card--articlecard--plan | <article>, <li>, <div> | 再利用可能な独立コンポーネントとしてコードが分離・生成されやすい |
| ボタン・アクション | btn--[役割/状態] | btn--primarybtn--secondary | <button>, <a> | クリック可能なアクション要素として認識され、適切なインタラクションが付与される |
| 入力フォーム | input--[種別] | input--textinput--search | <input type="..."> | 入力フィールドとして識別され、ラベルやバリデーション構造と正しく結びつく |
| レイアウトコンテナ | stack--[方向]container--inner | stack--verticalcontainer--inner | <div> (Flex/Grid) | 無駄なタグの深さを防ぎ、CSSのFlexbox構造（flex-direction）と直結する |
1. ページ・セクション単位の命名例
Webサイトやアプリケーションの大きな骨組みを定義するフレームには、HTML5のセマンティック構造を意識した命名を適用します。
大枠のフレーム名が明快であるほど、ページ全体の情報アーキテクチャが開発者にもAIにも一目で伝わります。
header--global: サイト共通の最上部ヘッダー（ブランドロゴや主要ナビゲーション等）nav--primary: メインナビゲーションバーsection--hero: ファーストビューのメインビジュアルおよびキャッチコピー領域section--features: サービスの強みや機能一覧を提示するセクションsection--pricing: 料金体系やプラン比較を提示するセクションsection--faq: よくある質問をアコーディオン等で提示するセクションsection--cta: ページ下部のコンバージョン誘導（会員登録や資料請求）領域footer--main: サイト共通の最下部フッター（コピーライトや利用規約リンク等）
2. コンポーネント・カード単位の命名例
画面内で繰り返し使われるUIブロックやカード要素には、格納されているコンテンツの種類を明記します。
コンポーネントとしての粒度を揃えておくことで、実装時に独立したコンポーネントファイルへ切り出しやすくなります。
card--article: ブログやニュースの個別記事カード（アイキャッチ、タイトル、公開日等）card--product: ECサイト等の商品カード（商品画像、価格表示、カートボタン等）card--pricing-plan: 料金プラン別の個別比較カードmodal--dialog: 確認や警告をユーザーに促すモーダルウィンドウdrawer--menu: 画面端からスライドインするナビゲーションドロワーtab--container: タブの切り替え領域を統括する親コンテナ
3. パーツ・最小要素（Atom）の命名例
ボタンや入力フォームなどのインタラクティブなUIパーツは、状態や視覚的優先度を識別しやすい名称にします。
見た目のスタイル名ではなく、ユーザーの操作目的を名前に含めるのがポイントです。
btn--primary: 画面内で最も目立たせたい主要アクションボタンbtn--secondary: 補助的なアクションを受け持つサブボタン（枠線のみのスタイル等）btn--icon-only: アイコン単体で構成される正方形や円形の操作ボタンinput--text: 標準的な1行テキスト入力フィールドinput--search: 検索専用のインプットフィールドbadge--status-active: 有効状態や稼働中を示すステータスバッジavatar--user: ユーザーのプロフィール画像を表示する円形フレーム
4. レイアウト・構造用コンテナの命名例
オートレイアウトを多重ネストした際に発生する中間フレームには、並びの方向やレイアウトの意図がわかる名前を付与します。
親フレームのレイアウト意図が整理されていると、AIがCSSを生成する際も無駄なラッパーを作らずに済みます。
container--inner: 画面の最大幅（Max-Width）を制御する中央寄せコンテナstack--vertical: 縦方向に要素を等間隔で配置するAuto Layoutフレームstack--horizontal: 横方向に要素を均等配置するAuto Layoutフレームgrid--3col: 3列で要素を並べるグリッド配置用Auto Layoutフレーム
オートレイアウトのネスト構造や破綻しない余白設計については、以下の記事で詳細な組み立て方を解説しています。
レイアウトを綺麗に組むためのステップとして役立ちます。
コピペで使える！AIエージェントにレイヤーを自動リネームさせる指示プロンプト
命名のルールが理解できても、制作途中にすべてのレイヤーを手作業でリネームするのは手間がかかると感じる場面もあります。
そのような場合は、FigmaエージェントやClaude、MCPツールなどにプロンプトを渡し、一括でセマンティックな命名へ置換してもらうアプローチが実用的です。
以下の指示文をFigmaエージェントの入力欄や、デザインデータを読み込ませたClaude / MCPの指示欄にそのまま貼り付けて活用してみてください。
以下のルールに従って、選択されたFigmaデザイン内のすべてのフレームおよびレイヤー名を、セマンティックでAI-readyな英語名（kebab-case）に一括リネームしてください。
# 命名規則の基本方針
1. デフォルトの名前（"Frame 123", "Rectangle 4", "Group 12" 等）はすべて適切な役割名に変更する。
2. 色や装飾の見た目（"BlueBox", "RoundBtn"）ではなく、UIの「役割・機能（セマンティクス）」に基づいて命名する。
3. 命名はすべて小文字の英語（kebab-case）を使用し、BEM形式（block--element または block--modifier）を意識する。
# 階層別の命名ガイドライン
- ページ最上位フレーム: screen--[画面名]（例: screen--dashboard, screen--checkout）
- 大枠のセクション: section--[役割]（例: section--hero, section--features, section--pricing）
- 主要ナビゲーション・ヘッダー: header--global, nav--main, footer--global
- カード・ブロック要素: card--[コンテンツ名]（例: card--product, card--article）
- インタラクティブ要素: btn--[用途/状態]（例: btn--primary, btn--secondary, input--text）
- Auto Layoutの入れ子構造: stack--vertical, stack--horizontal, container--inner
- テキスト要素: text--heading, text--subheading, text--body, text--caption
- アイコン・画像: icon--[名前], img--thumbnail, img--cover
# 出力時の注意
- 装飾のためだけの無意味なパスは過剰に細分化せず、親フレームの役割を明確にすることを最優先してください。
- 既存のコンポーネント名やバリアントプロパティが設定されている場合は、その定義を尊重してください。このプロンプトを登録しておけば、デザインが一段落した段階でフレームを選択して実行するだけで、短時間で整ったデータ構造に変換できます。
手作業で手早く修正したい場合は、Figma標準のショートカット Cmd + R（Windowsは Ctrl + R）による一括リネーム機能を活用し、連番の付与やプレフィックスの追加を組み合わせる方法も効率的です。
手間を最小化する！実務で無理なく続く3つのデータ管理習慣
レイヤー整理を日々の実務に定着させるためには、気合いや完璧主義に頼らない「仕組み化」が欠かせません。
自分の実務経験を通して確立した、作業スピードを落とさずにデータを管理しやすい状態に保つ3つの習慣を紹介します。
1. Groupを排除し「Auto Layout」を徹底する
デザインを組む際、複数の要素をまとめるために Cmd + G（グループ化）を使う癖がある場合は、Shift + A（Auto Layout化）を基本にするのがおすすめです。
グループ機能は単に複数の要素をひとまとめの枠で囲っているだけであり、コード上の階層構造とは一致しません。
一方でAuto Layoutを適用したフレームは、CSSにおけるFlexbox（display: flex）のレイアウト構造と直結します。
Auto Layoutで組んでおくだけで要素の余白や並び順が論理的に整理され、AIにとってもHTMLの入れ子構造を正確に推論しやすいデータになります。
2. ページとSection機能でステータスを分ける
1つのキャンバス上に初期のアイデア出しと最終版のデザインが混在していると、AIにデータを読み込ませる際にどれが本番データなのか判別できなくなります。
Figmaのファイル内は、あらかじめ以下のように明確なゾーニングを行っておくのが実務上安全です。
Design System / Components: 共通で使うボタンやカラー、タイポグラフィのマスターコンポーネントを配置するページWorking (WIP): アイデア出しやデザインの試行錯誤を行う作業用ページReady for Dev: 完成し、エンジニアへのハンドオフやAIコード生成に渡すFIX版だけを配置するページ
また、キャンバス内ではFigmaの「Section（セクション）」機能を使い、ステータス（In progress / Ready for dev）を明示しておくと、開発者もAIも迷わず正しいデータにアクセスできます。
トークンや変数の整理によってコンポーネントの管理を効率化する方法は、以下の記事で体系化しています。
大規模なデザインデータを破綻させずに運用したい場合の参考になります。
3. 完璧主義を捨てる「引き算の整理術」
日々の実務で最も大切なのは、「すべての下層レイヤーを100%完璧にリネームしようとしないこと」です。
アイコンの中の極小ベクターパスや、カード背景の装飾パーツまで1つずつ命名しようとすると、肝心のUI設計に使える時間が削られてしまいます。
実務で押さえるべきは以下の「3つの主要階層」です。
- 画面全体のフレーム名（Screen）
- 大枠のセクション名（Section）
- 主要なコンポーネント名（Card / Button / Input等）
この上位3階層さえセマンティックに整っていれば、AIもエンジニアもUIの全体構造を十分に把握できます。
細かい下層レイヤーはAIの自動リネームを活用するか、必要最小限の整理に留めるという「割り切った運用」を持つことが、ルールを形骸化させずに長く続けるためのポイントです。
まとめ：意味を持ったデータ構造が開発体験を高める
Figmaのレイヤー整理は、単なる見た目の美しさにとどまらず、設計の意図を正確にコードへ変換するための土台となります。
AIツールとの連携が進む現在の制作現場では、整ったデータ構造そのものが開発スピードと実装品質を支える要素です。
まずは次に作成する画面のフレーム名を、デフォルトの「Frame 1」から「section--hero」に変更してみることから始めてみてください。
小さな命名の積み重ねが、チーム全体のハンドオフを円滑にし、AIを活用した実装ワークフローをより確実なものにしてくれます。
