Figmaで集中してデザインを作成していると、気づけばレイヤーパネルが「Frame 482」や「Rectangle 12」の山になっていた経験は誰もが一度はあるはずです。
自分自身も以前は見た目が完成していれば問題ないと後回しにしてしまい、修正やハンドオフのたびに目的の要素を探す手間が発生していました。

しかし、デザインデータをClaude CodeやMCP（Model Context Protocol）などのAIツールに連携させてフロントエンドコードを生成する機会が増えたことで、その重要性を強く実感するようになりました。
レイヤー名と階層構造が論理的に整っているデータは、AIが解析するコードの構造やHTMLタグの選定精度にも良い影響を与えてくれます。

今回は、エンジニアへのスムーズなハンドオフはもちろん、AIとの協業でも破綻しない「実務で無理なく続く」Figmaレイヤー命名ルールと管理習慣を整理しました。
現場ですぐに参照できる命名早見表や、AIにレイヤー名を一括整理させるプロンプトも用意しましたので、日々の制作の参考にしてみてください。

なぜ今、Figmaのレイヤー名が重要なのか？（AI・MCP連携の実務メリット）

これまでFigmaのレイヤー整理といえば、チームメンバーへの配慮という文脈で語られる場面が多かった印象があります。
もちろんチーム開発における可読性も不可欠ですが、現在のUIデザインの現場では「AIに対するコンテキストの提供」という直接的なメリットが加わっています。

現在では、MCPサーバーを経由してFigmaのデータを直接LLMに渡したり、CursorやClaude Codeなどのツールを使ってデザインから実装コードを生成するワークフローが定着しつつあります。
AIはデザインの座標情報だけでなく、レイヤー名や階層の親子関係を意味的なメタデータとして解釈しながらHTMLやコンポーネントを組み立てます。

レイヤー整理とあわせてバリアントの増殖を防ぐ設計手法については、以下の記事で詳しく解説しています。
コンポーネント構造をよりスマートに整えたい際に役立つはずです。

Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術

バリアントの過度な増殖を防ぎ、レイヤー構造をシンプルに保つコンポーネントプロパティの実践ガイド。

もしフレーム名が「Frame 389」、ボタンが「Rectangle 12」のままだと、AIはその要素がどのような役割を持つUIなのかを視覚的な位置関係だけで推測しなければなりません。
その結果、すべての要素が無意味な <div> タグで囲まれ、CSSクラスの意図が読み取れない保守性の低いコードが出力されやすくなります。

一方で、親フレームに section--hero、ボタンに btn--primary という適切な名前が設定されていれば、AIはセマンティックなタグ（<header> や <button>）を的確に選びます。
Dev Modeでコードを確認するエンジニアにとっても、整ったレイヤー名は共通言語としての仕様書の役割を果たしてくれます。

FigmaのDev Modeを活用したエンジニア連携の基礎については、以下の記事で料金体系や機能差分をまとめています。
デザインデータの受け渡しを効率化したい際に役立つはずです。

Figma Dev Mode（開発モード）の使い方と料金体系｜できること・できないことと実装連携【2026】

エンジニアとのハンドオフやCode Connect連携をスムーズにするDev Modeの機能差分と実務での活用法を網羅。

つまり、現在のFigmaにおけるレイヤー整理とは、「実装の骨組みをデザイン段階で定義する作業」そのものといえます。

迷ったらここから！「AIレディ」なFigma命名の基本と考え方

AIと人間がともに構造を直感的に把握できるようにするためには、共通のベースラインを持っておくと迷いません。
意識したいのは、色や形状といった装飾的な見た目ではなく、UIにおける「役割・機能（セマンティクス）」を名前に反映させることです。

例えば、背景が青いからといって BlueButton と名付けてしまうと、テーマ変更時に名前の不整合が生じ、AIもそのボタンの視覚的優先度を判断しにくくなります。
btn--primary や btn--submit のように、そのパーツが果たす機能や優先度を英語のケバブケース（kebab-case）で記述するのが実務でおすすめのベースラインです。

チームの規約やプロジェクトの文脈によって最適な形式は異なりますが、まずは以下の「実務で扱いやすい命名早見表」を基準として持っておくと命名の迷いを大幅に減らせます。

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フレーム

オートレイアウトのネスト構造や破綻しない余白設計については、以下の記事で詳細な組み立て方を解説しています。
レイアウトを綺麗に組むためのステップとして役立ちます。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

要素の可変と余白を論理的に管理し、Flexbox準拠のクリーンな構造を作るためのオートレイアウト設計手順。

コピペで使える！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も迷わず正しいデータにアクセスできます。

トークンや変数の整理によってコンポーネントの管理を効率化する方法は、以下の記事で体系化しています。
大規模なデザインデータを破綻させずに運用したい場合の参考になります。

Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】

デザイントークンの2層構造と命名規則を整理し、バリアントの増えすぎを防ぐ変数の実践ガイド。

3. 完璧主義を捨てる「引き算の整理術」

日々の実務で最も大切なのは、「すべての下層レイヤーを100%完璧にリネームしようとしないこと」です。

アイコンの中の極小ベクターパスや、カード背景の装飾パーツまで1つずつ命名しようとすると、肝心のUI設計に使える時間が削られてしまいます。
実務で押さえるべきは以下の「3つの主要階層」です。

1. 画面全体のフレーム名（Screen）
2. 大枠のセクション名（Section）
3. 主要なコンポーネント名（Card / Button / Input等）

この上位3階層さえセマンティックに整っていれば、AIもエンジニアもUIの全体構造を十分に把握できます。
細かい下層レイヤーはAIの自動リネームを活用するか、必要最小限の整理に留めるという「割り切った運用」を持つことが、ルールを形骸化させずに長く続けるためのポイントです。

まとめ：意味を持ったデータ構造が開発体験を高める

Figmaのレイヤー整理は、単なる見た目の美しさにとどまらず、設計の意図を正確にコードへ変換するための土台となります。
AIツールとの連携が進む現在の制作現場では、整ったデータ構造そのものが開発スピードと実装品質を支える要素です。

まずは次に作成する画面のフレーム名を、デフォルトの「Frame 1」から「section--hero」に変更してみることから始めてみてください。
小さな命名の積み重ねが、チーム全体のハンドオフを円滑にし、AIを活用した実装ワークフローをより確実なものにしてくれます。

The post Figmaレイヤー整理と命名規則｜AI実装とチーム開発で破綻しない設計ルール【2026】 first appeared on デザペディア.