ゲーム案件のUIをWordPressや静的HTMLに当て込むとき、Figmaのスクショだけ渡して「雰囲気で合わせて」と言われると、実装側の解釈が毎回ズレます。私もWebディレクターとして、HUDやメニュー画面の修正を並行しているので、ゲームUI仕様 Markdown を1ファイルに固定してから Cursor を開く運用に切り替えました。本記事は、新作シーズンで画面数が増える前に、Figma → Markdown → 実装の流れを整える手順です。Figmaから実装へ渡す柱記事と併せて読むと、案件全体の線がつながりやすいです。
この記事でわかること
- Figma Dev Modeから拾うべき数値と命名の最小セット
- ゲームUI向けMarkdownテンプレの章立て
- Cursor Project Rulesと仕様書を組み合わせる順番
先に結論
- 向いている人: FigmaでゲームUIを受け取り、自分または外注がHTML/CSS/WordPressで実装するWeb制作者。画面状態（通常・ホバー・無効）が3種類以上ある案件
- 向いていない人: すでにUnityやUnreal側でUIを完結させており、Webに載せない案件。1画面だけのLP修正なら、テンプレより都度プロンプトの方が早いこともあります
- 私のおすすめ: まず 1画面分だけ Markdown仕様を書き切り、CursorでCSSを1ブロック生成 → 人間が目視修正 → テンプレを増やす
私は仕様書を書く時間を惜しがりがちなので、最初の1画面はコンポーネント名と余白だけに絞って、それでも実装が止まらなくなったら項目を足しています。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
なぜゲームUIはMarkdown仕様が必要か
ゲームUIは、一般のコーポレートサイトより 状態分岐 が多いです。ボタンの通常・押下・クールダウン、タブの選択中、ダイアログのオーバーレイ透明度など、Figma上はフレームが並んでいても、実装者には「どれが同じコンポーネントか」が伝わりにくいです。
| 渡し方 | メリット | デメリット |
|---|---|---|
| PNG書き出しのみ | 早い | 数値・状態が欠ける |
| Figmaリンクのみ | 最新が1箇所 | コメントが散らばる |
| Markdown仕様＋Figma | 検索・差分がGitで追える | 初回の作成コスト |
執筆時点（2026年9月・日本時間）の秋は、据置・PC向けタイトルのUIリニューやイベント画面が増えやすい時期です。Famitsuや4Gamerで話題になる大作ほど、公式サイトの特設ページやコラボLPにゲームUIトーンを持ち込む案件が増えます。そのときWeb側が「雰囲気コピー」だけだと、ボタン角丸やグロー効果の再現で手戻りが出やすいです。
事前準備：Figma側で揃える3点
Figma 側の整理が終わってからMarkdownを書くと、仕様書が短く済みます。
- コンポーネント命名 — 画面名_部品名_状態（例:
HUD_ skillBtn_default）。コンポーネント命名を案件ごとに揃える手順と同じルールを使うと、Markdownの見出しと1対1になります - Auto Layoutの固定 — 可変幅のメニューは、最小幅とパディングをDev Modeで確認できる状態にする。Auto LayoutでHUDを整える流れを済ませていると、数値の転記が楽です
- 書き出し形式の決定 — WebPやSVGのどちらを正とするかを1行で決める。WebP中心の書き出し手順は別記事で触れていますが、仕様書の「アセット章」に拡張子と倍率を書いておけば、実装側が迷いません
向いていないケースは、Figmaがラフのままでコンポーネント化されていないときです。その場合は先にFigma内を整え、Markdownは後回しにした方が、二重の手戻りを避けられます。
Markdownテンプレの章立て（コピー用）
リポジトリ直下に docs/game-ui-spec.md のような1ファイルを置く想定です。章立ては次のとおりがバランスよいです。
# 案件名 / 画面名
## スコープ（対象URL・非対象）
## デザイントークン（色・フォント・角丸）
## コンポーネント一覧（表）
## 画面別レイアウト（余白・ブレークポイント）
## アセット一覧（ファイル名・形式・@2x要否）
## インタラクション（ホバー・disabled・遷移）
## 未確定・要確認
ゲームUI仕様 Markdown では、トークン章に「HPバーの赤/黄/緑」など ゲーム固有の意味 を1列足すと、実装者がCSS変数名を決めやすくなります。例: --color-hp-warning: #E6A817; /* Figma: HUD/hpBar/warn */
色コードだけ並べるより、Figmaのレイヤー名をコメントに残すと、あとからデザイン差し替えが来ても追跡しやすいです。
Figma Dev Modeから転記する順番
- カラースタイルとテキストスタイル — 16進とfont-size/line-heightを表にする
- 代表コンポーネント1つ — ボタンまたはタブを選び、padding・gap・border-radiusを転記
- フレーム全体 — キャンバス幅（例: 390 / 768 / 1280）ごとにmax-widthと余白
- エフェクト — ドロップシャドウや外光（グロー）は、ぼかし半径まで書く。ゲームUIは「光るボタン」が多く、ここを省略すると再現率が落ちます
Dev Modeが使えないプランのときは、Figma上で要素を選択し、右パネルの数値を手打ちで構いません。体験談ではなく、執筆時に確認した公式の仕様として、プランによる機能差はクライアントに先に確認してください。
Cursorで仕様書を実装に渡す手順
- Gitリポジトリに
docs/game-ui-spec.mdをコミットする - Cursor Project RulesでWordPress修正範囲を固定した例と同様に、
.cursor/rules/に 「game-ui-spec.md を正とする」 旨を1ファイル追加する - Cursorのチャットで
@docs/game-ui-spec.mdを参照させ、1コンポーネントずつ CSSまたはBlade/HTMLを生成させる - 生成結果は 必ず人間がFigmaと並べて目視 する。AIはグローやグラデーションを近似しがちです
- WordPress（Cocoon）案件なら、上書きCSSファイル名をルールに書き、テーマ本体を触らない
Cursor は、仕様書が長いほど一発生成の精度が上がりますが、一度に全画面を頼まない方が安全です。私の現場では、HUD → モーダル → 設定画面の順に区切っています。
WordPress当て込みとの住み分け
ゲームUIトーンのLPをWordPressに載せる場合、仕様書のスコープ章に「固定ページのみ」「ブログ本文は対象外」と書いておくと、プラグインやウィジェットへの波及を防げます。静的HTMLからBladeへ移す案件では、WebP書き出しからWordPressへ載せる流れと章立てを揃えると、画像パスと仕様書のファイル名が一致します。
実装時に触るファイル例:
public/assets/css/style-game-ui-overrides.css（新規・上書き専用）resources/views/page-event.blade.php（固定ページテンプレ）
Cocoonのみの案件では、子テーマまたはカスタムCSS欄に同じ内容を写す運用でも構いません。正本はMarkdown に置き、WordPress側は生成物、という関係を崩さないことが重要です。
失敗しやすい点
- スクショだけ仕様書に貼る — 検索も差分も効かない。最低でもトークン表はテキストで
- 状態の漏れ — disabledだけ実装されず、本番で押せるボタンが残る
- @2xの有無が未記載 — Retinaでボタンがボヤける。アセット章に倍率を必須化
- Project Rulesと仕様書の矛盾 — Rules側に古い色が残ると、Cursorが古い値を優先することがある
価格やプランは執筆時点（日本時間）の情報です。FigmaやCursorの機能名は変更されることがあります。
よくある質問
Q. ゲームUI仕様 Markdownはどのくらいの長さが目安ですか？
A. 1画面あたり200〜400行 が目安です。それ以上は画面を分割し、ファイルを spec-hud.md / spec-menu.md のように分けると、Cursorの参照も軽くなります。全画面を1ファイルに詰め込むと、更新のたびに差分が読みにくくなります。
Q. Figmaを使わず、ゲーム本体のスクショだけの案件でも使えますか？
A. 使えますが、数値は実装者が計測する前提になります。ColorPickerとルーラーで拾った値をMarkdownに書き、Figmaリンクは「参考スクショ」として添付する形が現実的です。精度はFigma Dev Modeより落ちるので、クライアント確認の回数を増やしてください。
Q. CursorだけでFigmaの代わりになりますか？
A. なりません。Cursorは 仕様書に沿ったコード生成 が得意で、レイアウトの創作や状態設計はFigma側の仕事です。役割分担は「Figma＝見た目の正本」「Markdown＝実装契約」「Cursor＝下書き生成」と覚えると混乱しにくいです。
Q. 既存のWordPressテーマを壊さない最短手順は？
A. Cursor Rulesで修正範囲を固定し、仕様書のスコープに 触ってよいディレクトリ を列挙してください。生成CSSは必ず overrides ファイルに閉じ、テーマの style.css 直編集はルールで禁止にします。
まとめ
ゲームUI仕様 Markdown は、Figma Dev Modeの数値とコンポーネント名を1本にまとめ、Cursorで実装下書きを出すための契約書です。今日やることは次の3点だけで十分です。
- Figmaで代表ボタン1つの数値をDev Modeから転記する
- 上記テンプレで
docs/game-ui-spec.mdを作成する - Cursor Project Rulesに「仕様書を正とする」1行を足す
Figma でデザインを固め、Cursor で下書きを出し、最後は人の目でFigmaと並べる——この順を1画面で回せれば、秋の増えるUI案件でも手戻りが減りやすいです。関連: Figma制作ワークフロー柱 / ゲーム機選び方ハブ / WordPressブロックテーマ選定
