こんにちは！UIデザイナーのYunyです。
- Figmaで作業しているとレイヤー名が「Frame 123」や「Group 45」で埋め尽くされてしまう方
- ClaudeやMCP、Cursorなどを使ったAIコード生成で、レイヤー構造の粗さによる出力の乱れに悩んでいる方
- 実務で無理なく続けられる「AIレディ」なレイヤー命名規則や整理のルールを知りたい方
Figmaで夢中になってデザインを作っていると、気づけばレイヤーパネルが「Frame 482」や「Rectangle 12」の山になっていた経験はないでしょうか。
過去の自分もまさにその状態で、見た目が完成すれば問題ないと整理を後回しにしていました。
しかし、デザインデータをClaudeやMCP（Model Context Protocol）などのAIに読み込ませてコードを生成する機会が増えたことで、その考えは大きく変わりました。
レイヤー名が整っているデータと乱雑なデータでは、AIが出力するコードの品質と精度に決定的な差が生まれるからです。
今回は、エンジニアへのハンドオフはもちろん、AIとの連携でも破綻しない「AIレディ」なFigmaレイヤー命名ルールとデータ管理の習慣について詳しく解説します。
現場でそのままコピーして使えるネーミング一覧や、AIにレイヤー名を自動整理させるためのプロンプトも用意しましたので、ぜひ日々の制作に役立ててみてください。
- なぜ今、Figmaのレイヤー名が重要なのか？（AI・MCP連携の新常識）
- 迷ったらここから！「AIレディ」なFigma命名の基本と考え方
- 1. ページ・セクション単位の命名例
- 2. コンポーネント・カード単位の命名例
- 3. パーツ・最小要素（Atom）の命名例
- 4. レイアウト・構造用コンテナの命名例
- コピペで使える！FigmaエージェントやAIにレイヤーを自動リネームさせる指示プロンプト
- 手間を最小化する！実務で無理なく続く3つのデータ管理習慣
- 1. Groupを排除し「Auto Layout」を徹底する
- 2. ページとSection機能で「ステータス」を明確に分ける
- 3. 完璧主義を捨てる「引き算の整理術」
- 終わりに
なぜ今、Figmaのレイヤー名が重要なのか？（AI・MCP連携の新常識）
これまでFigmaのレイヤー整理といえば、「他のデザイナーやエンジニアへの思いやり」という文脈で語られることがほとんどでした。
もちろんチーム開発における可読性も大切ですが、現在のUX/UIデザインの現場では「AIに対するコンテキストの提供」という極めて実利的な理由が加わっています。
現在では、MCPサーバー経由でFigmaのデータを直接LLMに渡したり、Claude CodeやCursor、v0などのツールを使ってデザインからフロントエンドコードを一気に生成するワークフローが急速に普及しています。
以前の記事でも触れたように、AIはデザインの座標情報だけでなく、レイヤー名や階層構造を「意味的なメタデータ」として解釈してコードを組み立てます。
もしフレーム名が「Frame 389」、ボタンが「Rectangle 12」のままだと、AIはその要素が何のためのUIなのかを視覚的な位置関係だけで推測しなければなりません。
その結果、すべての要素が意味のない <div> タグでラップされた、メンテナンス性の極めて低いスパゲッティコードが出力されてしまいます。
一方で、フレームに hero-section、ボタンに btn-primary という適切な名前がついていれば、AIは即座にセマンティックなタグ（<header> や <button>）を選択し、適切なCSSクラスを割り振ってくれます。
また、Dev ModeやCode Connectを利用する際にも、整ったレイヤー名は開発者との共通言語として機能します。
つまり、現在のFigmaにおけるレイヤー整理とは、「コードの設計図をデザイン段階で定義する作業」そのものなのです。
迷ったらここから！「AIレディ」なFigma命名の基本と考え方
AI（ClaudeやCursor等）と人間がどちらも直感的に構造を理解できるようにするには、いくつか共通のベースラインを持っておくと便利です。
ポイントとなるのは、色や形といった見た目ではなく、UIにおける「役割（セマンティクス）」を名前の基準にすることです。
例えば、背景が青いからといって BlueButton と名付けてしまうと、後からカラーテーマを変更した際に矛盾が生じるだけでなく、AIもそのボタンの重要度を判断しづらくなります。btn-primary や btn-submit のように、その要素が果たす機能や役割を英語のケバブケース（kebab-case）またはスラッシュ（/）を用いて記述するのが扱いやすいベースラインとなります。
もちろん、チームのコーディング規約やプロジェクトの文脈によって最適な命名は異なります。
ここでは、「まずはここから始めると破綻しにくい」実務でおすすめのネーミング参考例をご紹介しますので、現場のルールに合わせて柔軟にアレンジしながら活用してみてください。
1. ページ・セクション単位の命名例
Webサイトやアプリの大きな領域を区切るフレームには、HTML5のセマンティックタグを意識した命名を行います。
header--global: サイト共通の最上部ヘッダー（ロゴ、主要ナビゲーション等）nav--primary: メインナビゲーションバーsection--hero: ファーストビューのメインビジュアル・キャッチコピー領域section--features: サービスの特徴や強みを紹介するセクションsection--pricing: 料金プラン一覧を表示するセクションsection--testimonials: ユーザーの声や導入事例のセクションsection--faq: よくある質問（アコーディオン等）のセクションsection--cta: ページ下部のコンバージョン誘導（登録・問い合わせ）領域footer--main: サイト共通の最下部フッター（コピーライト、補助リンク等）
2. コンポーネント・カード単位の命名例
複数回再利用されるUIブロックやカード要素には、中身のコンテンツの種類を明記します。
card--article: ブログやニュースの個別記事カード（サムネイル、タイトル、日付等）card--product: ECサイトなどの商品カード（画像、価格、カートボタン等）card--pricing-plan: 料金プランごとの個別カードmodal--dialog: 警告や確認を促すモーダルダイアログdrawer--menu: 画面端からスライドして出現するドロワーメニューtab--container: タブ切り替えの全体コンテナtoast--notification: 画面端に一時表示される通知メッセージ
3. パーツ・最小要素（Atom）の命名例
ボタンやフォーム入力欄などのインタラクティブな要素は、状態や用途を識別しやすく命名します。
btn--primary: 最も目立たせたい主要アクションボタンbtn--secondary: 補助的なアクションボタン（枠線のみのゴーストボタンなど）btn--icon-only: アイコンのみで構成された円形・正方形ボタンinput--text: テキスト入力フィールドinput--search: 検索専用のインプットフィールドbadge--status-active: 有効状態を示すステータスバッジavatar--user: ユーザーの丸型プロフィール画像icon--arrow-right: 右矢印などのベクターアイコン
4. レイアウト・構造用コンテナの命名例
Auto Layoutのネストによって生じる中間レイヤーには、レイアウトの方向や余白の意図がわかる名前を付けます。
container--inner: 最大幅（Max-Width）を制御するインナーコンテナstack--vertical: 縦方向に要素を等間隔で並べるAuto Layoutフレームstack--horizontal: 横方向に要素を等間隔で並べるAuto Layoutフレームgrid--3col: 3列で要素をグリッド配置するAuto Layoutフレーム
コピペで使える！FigmaエージェントやAIにレイヤーを自動リネームさせる指示プロンプト
「ルールは分かったけれど、作業中に1つひとつのレイヤーを手動でリネームするのは時間がかかる」と感じる方も多いはずです。
そのような場合は、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`
# 出力時の注意
- 装飾のためだけの無意味なパスは過剰に細分化せず、親フレームの役割を明確にすることを最優先してください。
- 既存のコンポーネント名やバリアントプロパティが設定されている場合は、その定義を尊重してください。このプロンプトを一度セットしておけば、デザインが完成した段階で範囲を選択して実行するだけで、わずか数秒で「AIレディ」なデータ構造が完成します。
手動で作業する場合は、Figma標準のショートカット Cmd + R（Windowsは Ctrl + R）による正規表現置換を併用すると、連番の付与やプレフィックスの追加が効率的に行えます。
手間を最小化する！実務で無理なく続く3つのデータ管理習慣
レイヤー整理を日々の実務で定着させるためには、気合いや完璧主義に頼らない「仕組み化」が欠かせません。
自分の実務経験を通して確立した、作業スピードを落とさずにデータを美しく保つ3つの習慣をご紹介します。
1. Groupを排除し「Auto Layout」を徹底する
デザインを作るとき、要素をまとめるために Cmd + G（グループ化）を使う癖がある場合は、今すぐShift + A（Auto Layout化）に切り替えることをおすすめします。
グループ機能は単に複数の要素をバウンディングボックスで囲っているだけに過ぎず、コード上の階層構造とは一致しません。
一方でAuto Layoutを適用したフレームは、Webにおける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%完璧に命名しようとしないこと」です。
アイコンの中の小さなベクターパスや、カードの背景にある微妙なグラデーションの四角形まで律儀にリネームしようとすると、デザインを考える時間そのものが奪われてしまいます。
押さえるべきは以下の「3つの重要階層」だけです。
- 画面全体のフレーム名（Screen）
- 大枠のセクション名（Section）
- 主要なコンポーネント名（Card / Button / Modal等）
この上位3階層さえセマンティックに整っていれば、AIもエンジニアもUIの全体構造を正確に把握できます。
細かい下層レイヤーはAIの自動リネームに任せるか、必要最小限の整理に留めるという「良い意味での割り切り」を持つことが、習慣を長く続ける秘訣です。
終わりに
最後までお読みいただき、ありがとうございます！
Figmaのレイヤー整理は、一見すると地味で面倒な作業に思えるかもしれません。
しかし、AIとの協業が当たり前になったこれからの時代において、「意味を持ったクリーンなデータを作るスキル」は、デザイナー自身の意図を正確にプロダクトへ変換するための強力な土台となります。
まずは今日作る画面のフレーム名を、いつもの「Frame 1」から「section--hero」に変えてみることから始めてみませんか。
小さな命名の習慣が、チームの開発体験とAIの出力クオリティを劇的に変えてくれるはずです。
これからも、心地よいデータ設計とモダンなデザインワークフローを一緒に楽しんでいきましょう。
それでは、良いデザインライフを！
