ゲームUIのモックをFigmaで渡す案件では、見た目より先にコンポーネント名のばらつきで手戻りが起きることがあります。ボタンが btn_ok と Button/Primary と UI-BTN-01 で混在していると、エンジニアは「どれが正本か」を毎回Slackで確認します。私はWebディレクションと実装の橋渡しをしている側で、Figma コンポーネント 命名 ゲームUIを整えるタイミングは、スクショ注釈の前・Auto Layoutの後、いわゆる納品前の1時間に固定しています。
本記事では、据置ゲームやモバイルゲームのUI案件で使える命名の型と、Figma上で一括置換しやすい階層の作り方を手順に落とします。画面キャプチャの注釈フローはゲームUIスクショのFigma注釈に任せ、Auto Layoutの組み方はFigma Auto Layoutのワークフローと併読してください。以下は、私が実際に運用しているテンプレと、各社公式ヘルプで説明されているコンポーネント／バリアントの考え方を分けて書きます。
この記事でわかること
- ゲームUI向けに接頭辞と階層を決める4ステップ
- Button・Icon・Modalで使い分ける命名例
- 納品前チェックリストと、開発に渡すREADMEの書き方
先に結論
- 向いている人: FigmaでゲームHUD・メニュー・ポップアップを渡すWeb／UIデザイナー。エンジニアがUnityやUnrealではなくWeb実装側の案件でも、名前で検索できる状態にしたい人
- 向いていない人: 1画面だけのラフで、コンポーネント化しない人。命名よりピクセルパーフェクトだけを優先する短期ラフ
- 私のおすすめ: 案件開始日に接頭辞表を1枚決め、以降は
Component/Category/Nameの3階層だけ使う。バリアントはProperty=Valueに寄せ、日本語ラベルはレイヤー名ではなく説明用フレームに書く
私は命名を後回しにすると必ず直す羽目になるので、最初のHUD1枚を作る前に接頭辞表だけ先にクライアントに送っています。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
命名を決める前に揃える3つの前提
ゲームUIは、一般のコーポレートサイトより状態数が多いです。通常ボタンでも、通常／押下／無効／ローディング／選択中がセットになります。命名以前に、次を紙かFigJamに書きます。
- 画面ID — 例:
SCR-Title,SCR-Battle,SCR-Shop（実装のシーン名に近づける） - コンポーネントカテゴリ —
Button,Icon,Label,Modal,List,Gauge,Tab - バリアントの軸 — 例:
State=Default|Pressed|Disabled,Size=S|M|L,Theme=Light|Dark
案件全体の入口はFigma制作フローの柱にもまとめていますが、ゲームUIだけはカテゴリ語を英語固定にすると、開発側の検索と一致しやすいです。日本語はコンポーネント名ではなく、FigmaのDescriptionや納品READMEに書きます。
手順1: 接頭辞表を1枚作る（15分）
案件フォルダ直下に 00_Naming ページを作り、表形式で次を固定します。
| カテゴリ | 接頭辞（コンポーネント名） | 例 |
|---|---|---|
| ボタン | Button/ |
Button/Primary, Button/Secondary |
| アイコン | Icon/ |
Icon/Close, Icon/Currency |
| テキスト | Label/ |
Label/Title, Label/Body |
| モーダル | Modal/ |
Modal/Confirm, Modal/Reward |
| ゲージ | Gauge/ |
Gauge/HP, Gauge/MP |
やってはいけない例は、画面ごとに別名を作ることです。タイトル画面だけ TitleBtnStart、ショップだけ ShopBuy にすると、共通化できたはずのPrimaryボタンが分裂します。共通化できるものは最初から同じ Button/Primary に寄せ、バリアントで Label=Start|Buy を変える方が後から楽です。
Figmaの有料プランやDev Modeの詳細は公式を確認してください。制作チームで https://www.figma.com/ からプランを揃えている場合は、命名表をチームライブラリのDescriptionに貼っておくと、外注デザイナーにも同じルールが伝わります。
手順2: コンポーネントを3階層に揃える（30分）
私が使う階層は Category / Name / Variant です。Figmaのスラッシュ区切りと相性がよく、左パネルで並び替えやすいです。
- Category — 上表の
Button,Iconなど - Name — 役割名（Primary, Close, Confirm）。色名（Red, Blue）は避け、役割で名付ける
- Variant — Figmaのバリアントプロパティ（
State,Size）。レイヤー名に_hoverを足すより、プロパティ側に寄せる
具体例です。ホラー系のタイトルで「続きから」「新規」を同じPrimaryボタンに載せる案件では、Button/Primary に Label=Continue|NewGame のバリアントを付け、画面側のインスタンスだけ差し替えました。Townfallのような難易度選択UIをPS5向けに注釈した記事（画面明るさとHDRの設定）とは別軸ですが、難易度ボタンも Button/Primary + Label=Easy|Normal|Hard にすると、実装側のボタンクラスが1つで済みます。
色名でコンポーネントを分けると、ダークモード追加のたびに複製が増えるので、私は役割名だけにしています。
手順3: 画面フレーム側は「SCR-」で束ねる（20分）
コンポーネント名とは別に、画面フレームは SCR-Shop / Composition のように先頭に SCR- を付けます。中身のインスタンスはすべて Button/, Icon/ から置き、フレーム名にボタン名を入れないようにします。
画面フレームの命名例:
SCR-Title / 1920x1080 / JASCR-Battle / HUD / SafeAreaSCR-Shop / Modal-Reward
エンジニア向けに「どの画面にどのモーダルが載るか」をREADMEに書くとき、SCR-IDとModal名だけ列挙すれば足りることが多いです。ピクセル値の表は納品チェックリスト側に寄せ、本手順では名前の索引だけを整えます。
手順4: 納品前にRenameと検索で抜けを潰す（15分）
Figmaの Rename（一括置換）を使う前に、必ずバージョン履歴かブランチを切ります。私は次の順で確認します。
- 左パネルで
Button/を検索 —btn,BTN,ボタンが残っていないか Icon/を検索 — 24pxアイコンがバラバラなサイズ名になっていないか- 未コンポーネント化のグループ — 名前が
Group 47のまま残っていないか - Description — 日本語の操作説明が空のPrimaryボタンがないか
抜けが多いときは、スクショ注釈用の別フローより先にここを直した方が、注釈番号の付け直しが減ります。WordPress案件でSVGを載せる前処理はSVGサニタイズの手順が別記事です。
開発に渡すREADMEの最小テンプレ
命名表だけPDFで送るより、Markdown 10行の方が刺さることが多いです。
# UI Component Index
- Button/Primary … 主要CTA。Variant: State, Label
- Button/Secondary … キャンセル・戻る
- Icon/Close … モーダル共通
- Modal/Confirm … SCR-Shop, SCR-Title で共用
ZIPに含めるか、FigJamの1リンクにまとめるかは案件次第です。Figmaファイル内の 00_Naming ページをリンク1本で渡す運用でも十分です。
READMEは長く書かず、検索キーワードだけ並べると、実装側からの質問が減ります。
失敗しやすいパターン
- 画面名をコンポーネント名に混ぜる —
BattleButtonAttackのように増殖する - テキスト内容をコンポーネント名にする — ローカライズで全改名になる
- バリアントをレイヤー複製で表現 —
Button/Primary,Button/PrimaryHoverが別コンポーネントになる - アイコンだけPNG書き出し名とFigma名を別ルール —
icon_close.pngとIcon/Closeは対応表をREADMEに1行追加
仕様やメニュー名は執筆時点（2026年9月27日・日本時間）のFigma一般機能に基づきます。UI表記はアップデートで変わることがあります。
よくある質問
Q. ゲームUIでもWebコンポーネントと同じ命名でよいですか？
A. カテゴリ語（Button, Icon, Modal）はWebと共通にした方が、実装がReactなどWeb技術の案件ではそのまま転用しやすいです。GaugeやSkillIconなどゲーム固有は Gauge/ Icon/Skill のようにCategoryだけ増やす形が安全です。
Q. バリアントが20を超えると管理がつらいです
A. Labelバリアントを列挙しすぎないのが近道です。文言はインスタンス上のテキストレイヤーで差し替え、バリアントはStateとSizeだけに絞る案件が多いです。20を超えるなら、コンポーネントを分割（Button/Primary, Button/Chip）してください。
Q. 外注デザイナーがルールを破ったときの直し方は？
A. ファイルを触る前に命名表ページをスクショし、Renameで一括修正します。DiscordやSlackで口頭説明より、Figmaの 00_Naming を唯一の正にした方が再発が減ります。
Q. Dev Modeやエクスポート名も同じにすべきですか？
A. コンポーネント名とエクスポート名の対応表をREADMEに1段追加すれば足ります。全部一致は理想ですが、PNGスプライト案件では icon_close.png のような短名を許容し、表で Icon/Close と紐付ける運用も現実的です。
まとめ
Figma コンポーネント 命名 ゲームUIの要点は、案件初日にCategory/Name/Variantの3階層を決め、画面フレームは SCR- で束ね、納品前にRename検索で btn や Group 47 を消すことです。開発側は名前で検索できるだけで、実装とQAの速度が上がります。
今日やることは1つ。既存ファイルで Button/ 検索をかけ、接頭辞が混在していたら 00_Naming ページを作る——それだけでも次の差し替えが楽になります。
Figmaのチーム運用をこれから整える場合は、https://www.figma.com/ のプランと権限（編集者／閲覧者）を先に揃えてから命名表を配布してください。
関連: Figma制作フローの柱 / ゲームUIスクショ注釈 / Web納品チェックリスト
