UIデザイナーが作業効率向上のために定義した、デザインデータにおけるレイヤー命名規則

ARアドバンストテクノロジ株式会社（ARI）でUIデザイナーをしている、ダーヤマです。

デザイナーの皆さんはもちろん、エンジニアの皆さんも、Figmaなどのデザインデータのレイヤー名を見て「これ、どういうルールで付けているんだろう...？」と悩んだことはありませんか？ 私自身、レイヤー名のルールや一貫性について、日々頭を抱えています。

この課題を解決するため、デザインデータのレイヤー命名規則をルール化しました。この記事では、そのプロセスをご紹介します。

命名ルール作成の経緯

私にとってレイヤーの命名は、地味に時間が取られる厄介な作業でした。また、全体的に一貫性のある命名にできておらず、他のデザイナーとの共同作業で統制が取りづらいという問題も生じていました。

実は、弊社デザインチーム内でも以前「レイヤー名をルール化するべきか？」という議論が持ち上がったことがあります。しかし、スピード重視で進行する案件も多数あり、「ルール化は人によっては余計な手間になり、かえって効率が落ちる可能性がある」という判断から、あえてルールは設けないことになりました。

そのため今回は、個人の作業効率と品質を向上させるため、独自の命名ルールを考案することにしました。コーディングの知識が浅いデザイナーでも容易に運用でき、ノンデザイナーのエンジニアにも理解がしやすいルールを目指します。

現状の課題

命名の基準が定まらないまま作業を進めてしまうことがあり、その結果、以下のような課題が発生しています。

• 文字列の表記方法
  • 大文字や小文字、単語区切りの記号など文字列の表記が毎回異なる
• レイヤー名に使う名称の判断
  • そもそも何の名称を採用するかの判断基準が定まっていない
• 汎用的なレイヤー名の使い分け
  • wrapper、container、item など汎用的な名称を一貫性なく使用してしまう
• 設定の都合で括ったグループの命名
  • オートレイアウトや余白調整の都合だけでグルーピングしたレイヤーに適切な命名ができない

これらの課題を解決するため、ChatGPTと壁打ちをしながらルールを確立していきます。

命名ルール作りの方針

今回のルール設計では、次の点を重視しました。

1. コーディングの知識が浅い人でも運用できるルール

• わかりやすい英単語以外、HTMLタグに基づく命名は使わない
  • ⭕️：title header footer table section（nav, imgなど、広く知られている略語もOK）
  • ❌：h1〜h6 div ul ol li dl dt
• 学習コストを削減し、誰でもすぐに理解・運用できるようにする

2. コーディング時にもわかりやすいルール

• エンジニアがデザインデータを見たときに、そのレイヤーがUIのどの役割を果たしているのか即座に理解できるようにする

以上の方針のもと、現状の課題を１つずつ解決していきます。

文字列の表記方法

まず、文字列の表記方法を決めます。

大文字・小文字、そして区切り文字（ハイフン 、アンダースコア 、半角スペース）をどう組み合わせるか、表記方法は多岐にわたります。どのようにすれば、入力しやすく分かりやすいデータになるか悩ましい点です。

表記方法の例

スタイル名	記法	記述例	特徴
キャメルケース（camelCase）	単語の先頭を大文字にしてつなげる	layerName	JSなどでよく使われる。単語の区切りが見えにくい
パスカルケース（PascalCase）	キャメルケースの最初の文字を大文字にする	LayerName	様々な言語のクラス名でよく使われる
スネークケース（snake_case）	単語間をアンダースコアでつなげる	layer_name	Pythonの変数、URLなどによく使われる
ケバブケース（kebab-case）	単語間をハイフンでつなげる	layer-name	CSSのクラス名などによく使われる
ローワーケース（lower case）	単語間にスペースを入れる	layer name	人が読む文章に近く、可読性が高い

まず、スペース区切りは書き出し時のファイル名として不都合が生じる可能性があるため、ハイフンやアンダースコアを用いる形式が適切だと判断しました。

さらに、すべて小文字で統一することで、大文字・小文字の選択に迷うことがなくなります。

これらを踏まえると、スネークケース（snake_case）もしくはケバブケース（kebab-case）のどちらかに絞られました。

結論：ケバブケース（kebab-case）に決定

デザインデータとの相性の良さと入力のしやすさの観点から、最終的にケバブケース（kebab-case）を採用することにしました。

• 表記例：primary-button table-header
  • Shiftキーの使用が最小限で済むため効率的に入力でき、誤入力の恐れが少ない
  • CSSのクラス名などで頻繁に使用されており、エンジニアにとっても見慣れているスタイル

レイヤー名に使う名称の判断

続いて、レイヤー名に採用する名称の判断に迷うという課題を解消するため、明確な採用基準を定めます。

レイヤーの命名は、UIの構造階層に基づき、大きく「範囲」「モジュール」「要素」 の3つにカテゴライズできます。

分類	意味	例
範囲（Scope）	UI上でのまとまりや範囲を示す	header footer section main wrapper
モジュール（Module）	役割や機能を持つ部品（繰り返し使用される単位など）	nav card menu form table list
要素（Element）	モジュールを構成する最小単位の要素	text image icon button input checkbox

今回のルールでは、以下の方針をとることにしました。

1. 「範囲 → モジュール → 要素」の順で考える

レイヤーが 「範囲」「モジュール」「要素」 のどの階層に属するかを意識し、外側の階層（構造）から順に意味を固めていきます。
「まず範囲を決めてから、中身のモジュール、最後に要素」という順序で考えると迷わずに命名できます。

このレイヤーはどの階層？
↓
① ページの構造・区切り → 範囲（section header footer main）
↓
② UIの機能単位？ → モジュール（card nav tabl form list）
↓
③ モジュール内部の部品？ → 要素（text image icon button）

2.英単語1語〜2語とし、識別が必要な場合は先頭に補足名を付与

基本的に単語1語〜2語で完結させ、短くシンプルな名称を心がけます。同名の要素が複数あり区別が必要な場合や、レイヤーを見ただけでは役割が分かりにくい場合、親名や役割、位置情報など補足となる名称を先頭に付与して識別します。

• 基本的な命名の例
  • header footer title table-header side-nav
• 識別が必要な場合の命名の例
  • 親名を追加：table-cell table-header-cell
  • 役割を追加：submit-button cancel-button
  • 位置情報を追加：left-group right-group

この整理により、レイヤー名から意味が把握でき、共同作業や後のデータ運用も容易になります

汎用的なレイヤー名の使い分け

header、 footer、nav など、使用する場面が限定的な名称は使い所がわかりやすい一方で、
wrapper、container、item のような汎用的に使える名前は「どこでどう使うか」が曖昧になりがちです。箇所によって解釈が変わり、命名がバラついてしまうことがあります。

そこで、それぞれの命名の役割を整理して、しっかり認識することにしました。
単に「箱」や「グループ」としてまとめるのではなく、「このレイヤーは何をするためのものか」を名前から理解できるようにします。

よく使う汎用レイヤー名一覧

名称	役割
wrapper	外枠。ページ幅制御や左右センター寄せなど、全体を包む役割。
container	コンテンツ全体を入れる箱。
contents	中身。主要な内容物を包むレイヤー。
section	ページ内の意味的な区切りを定義する大きなまとまり。
item	繰り返し登場するモジュールや要素。リストやカードなど。
inner	親要素の内側の層。内容物全体を包む。
row / column	方向（横／縦）を意味として表すグルーピング。

上記の他、汎用的すぎる名称は、そのレイヤーが「なぜ存在するのか」が分からなくなるため、単体での命名は避けます。
もし使用する場合は、先頭に中身の分類や位置情報を付与して意味を補足することとします。

• 単体使用を避ける名称の例
  • group box area block など
• 使用する場合の例
  • text-group form-box gallery-area bottom-block

設定の都合で括ったグループの命名

Figma のオートレイアウトを使用していると、余白や配置調整など、表現上の設定のためだけにレイヤー（グループ）を追加することがよくあります。こうした「意味を持たないグループ」の命名が曖昧になりがちです。

そこで、レイアウト調整専用のグループには layout を使うというルールを定義します。

名称	役割
layout	Auto Layoutの設定、余白、揃え、配置といった、純粋なレイアウト調整のためだけに存在する層。

• 役割を明確にする
  • 「見た目の調整のためだけに存在する」ことが名前から分かるようにする
• 構造や機能とは区別する
  • コンテンツや機能を示す名前（header card など）とは混同しない

このように役割を明確にすることで、デザインデータを見た誰もが、そのレイヤーが「なぜ存在するのか」を即座に理解でき、後からの修正や引き継ぎの際にも迷うことのない命名ができます。

作成した命名ルールまとめ

上記で定めた指針をまとめると、以下5つのシンプルな命名ルールができました。

1. 文字列はケバブケース（kebab-case）で表記する。
2. 外側の階層から順に沿って命名を考える（範囲 → モジュール → 要素）。
3. 命名は 単語1～2語を基本 とし、識別が必要な場合は先頭に補足名を付ける。
4. 汎用的なレイヤー名は用途を明確にして使う。
   意味が曖昧な名称を用いる場合は、先頭に補足名を付ける。
5. 設定の都合でレイヤー追加が必要な場合はlayout を使用する。

UI 画面を使用した具体的な命名例

それでは、作成したルールを基に、実際のUIモジュールに当てはめた命名例を見てみましょう。

サンプルとして、カードやテーブルを含む画面のデザインを用意しました。

1. ヘッダー

• 「group」のみでは意味が曖昧なので、位置情報を付加してleft-group right-groupと命名。
• アイコンが複数存在するため、それぞれ先頭に役割名を追加。

2. カードのリストを含むセクション

• sectionで囲い、範囲は最初に定義。
• card-list や card など、一目で何を指すか理解できるモジュール名を使用。
• card-title, card-image, category など、要素は役割が分かるように。

3. テーブルを含むセクション

• table-header table-bodyで構造を明示。
• セルの違いが一目でわかるよう、「cell」をそれぞれtable-header-cellとtable-data-cell に分けて識別。

これで、レイヤー命名に悩む時間を減らし、共同作業や引き継ぎでも迷わない命名ルールが確立できました。
このルールにより、他のデザイナーやエンジニアも「このレイヤーは何をするものか」がすぐ理解できるため、デザインデータの受け渡しがスムーズになります。

おわりに

本記事では、命名に関する課題を解決するため、個人の作業効率とデータ品質を向上させる命名ルールの作成についてご紹介しました。

今回はレイヤー名の命名規則を考えましたが、今後は色やフォントなどのデザイントークン、コンポーネントにおけるバリアントやプロパティの命名についても、より明確なルールを検討していく予定です。

命名ルールを定めることは、導入時は一時的に手間が増えるように感じるかもしれませんが、一度ルールが定着すれば、デザイナーとエンジニア間の共通言語となり、コミュニケーションコストが劇的に削減されます。この記事が、皆さんのチームにおけるデザイン資産の整理や協業促進の一助となれば幸いです。

最後までお読みいただき、ありがとうございました。

参考記事