新作シーズンで設定画面のフレームが増えると、見た目は揃っているのに実装でタブ順がバラバラになることがあります。私もWebディレクターとしてゲームUIの当て込みを並行しているので、ゲーム設定 UI Figma の段階で「どの項目が次にフォーカスするか」を表に固定してから実装に渡す運用にしています。HUDのAuto Layoutは別記事の手順で触れていますが、今回は音声・画質・操作・アクセシビリティのような設定メニュー専用です。
この記事でわかること
- 設定画面で先に決めるべき「タブ」と「フォーカス順」の違い
- Figma上で表に起こす最小項目（状態名・ラベル・次フォーカス）
- 実装側へ渡すときのファイル構成とCursor連携の位置づけ
先に結論
- 向いている人: Figmaでゲームの設定UIを受け取り、HTML/CSSやエンジンUIに落とす制作側。タブが3つ以上あり、コントローラーとキーボードの両方を想定している案件
- 向いていない人: 設定が1画面・項目5個以下で、プロトタイプ段階で毎日レイアウトが変わる案件（表の更新コストが上回る）
- 私のおすすめ: まず「操作」タブだけ表に書き切り、実装で1周通してから他タブを足す。全部を一度に完璧にしない方が、発売週の修正に強いです
私は最初「表なんて後でいいや」と思っていましたが、コントローラーのL1/R1タブ切り替えと、キーボードのTab移動が食い違ったときに一晩潰れたので、今はFigmaの段階で表を必須にしています。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
設定UIで「タブ順」と「フォーカス順」を分ける
ゲーム設定は、プレイヤーがどの順番で項目を触るかが体験そのものになります。混同しやすいのは次の2つです。
| 用語 | 意味 | 例 |
|---|---|---|
| タブ順 | 画面上のタブ（音声／画質／操作）を左右に切り替える順序 | L1で左、R1で右 |
| フォーカス順 | 1タブ内でハイライトが移動する順序 | 上から下、またはZ字型 |
ゲーム設定 UI Figma では、タブはフレーム横並び、フォーカスはコンポーネントのインスタンス順で表現されがちです。しかし実装では、見た目の並びとフォーカス順が一致しないことがあります（2列レイアウトで右列から入る、など）。表に「次フォーカスID」を書くと、デザインと実装の認識ズレが減ります。
表に書く最小セット（1タブ分のテンプレ）
FigmaのDev Modeで数値を拾う前に、論理名を揃えます。私はスプレッドシートでもMarkdownでもよいですが、案件ごとに次の列を固定しています。
- focus_id … 実装で使う一意のID（例:
settings.audio.master） - 表示ラベル … ローカライズキーまたは日本語確定文
- コンポーネント状態 … 通常／フォーカス／無効／オン／オフ
- 入力種別 … トグル／スライダー／ドロップダウン／ボタン
- 次フォーカス（下） … 下キーまたは十字キー下
- 次フォーカス（右） … 右キー（2列レイアウト用）
- タブグループ …
audio/video/controlsなど
スライダーは「値の範囲」と「刻み」も列を足します。公式仕様が無い場合は、仮のmin/maxをグレー表示し、プロデューサー確認待ちと明記します（体験談と仕様を混ぜません）。
Figma側の準備（コンポーネント命名）
設定行は、毎回バラバラな名前だと表が書けません。私は次のルールに寄せています。
- コンポーネント:
SettingRow / Type=Toggleのように型をvariantで分ける - インスタンス名:
audio_master_volumeのようにfocus_idと同じ英数字 - タブフレーム:
Tab_Audio,Tab_Videoでプレフィックス統一
コンポーネント命名の別記事と併用すると、エクスポート時のファイル名も揃いやすいです。命名が直せない案件では、表の focus_id 列だけ先にプロデューサーと合意し、Figma名は後追いでも構いません。
英語のIDは堅いですが、ローカライズでラベルが変わってもフォーカス順が崩れないので、私はここを日本語より先に固定します。
Dev Modeで拾う数値と、表に書かないもの
Dev Modeは余白・フォント・色の共有に向いています。設定UIの表では、次だけFigmaから転記します。
- 行の高さ・左右パディング（タッチターゲット44px相当があるか）
- フォーカス枠の太さと色（コントラスト確認用）
- スライダーのトラック長（実装でヒット領域を決める）
一方、デフォルト音量や画質プリセットの推奨値はゲームデザイン文書側の話です。表に書くのは「その項目が存在するか」「無効化条件」までに留め、バランス調整は別シートに分けます。発売週に新作の画質設定記事のようにプレイヤー向けガイドが出るタイトルでも、UI表は操作の正本、推奨値はパッチノートやヘルプテキストが正本、と役割を分けると更新が楽です。
コントローラー操作を表に落とすコツ
据置機の設定画面は、十字キー／スティック／肩ボタンの割り当てがセットです。表に次の行を足すと実装者が助かります。
| 操作 | 期待動作 | 表での記載例 |
|---|---|---|
| L1 / R1 | タブ切り替え | tab_prev / tab_next |
| 〇（決定） | トグル反転またはサブメニュー | action=activate |
| ×（戻る） | 1階層戻る／変更破棄確認 | action=back |
「戻る」で変更を保存するか破棄するかは、タイトルごとにポリシーが違います。未確定なら表のセルを「要確認」にし、実装は確認ダイアログを仮置きにします。私の経験では、ここを曖昧にした案件ほど、発売後にパッチでUIが揺れます（一般論として、確認ダイアログは最初から入れた方が安全なことが多いです）。
キーボードとマウス（PC版）の追記列
Steam版やPC版を同時に作る場合、表に PC列 を足します。
Tab/Shift+Tabの移動順がコントローラーと同じか- マウスホバー時にフォーカスリングを出すか
- スライダーがドラッグのみか、クリックで値ジャンプするか
PCだけマウスホバーでフォーカスが飛ぶと、コントローラー操作のテストと結果がずれます。フォーカスは常に1つを原則にし、ホバーは見た目だけ変える——と表の注記欄に書いておくと、実装の議論が短くなります。デスクでWin11とコントローラーを併用する人向けの環境整理はゲームバー設定が別軸ですが、「設定画面の操作感」は本表が先です。
実装渡しのパッケージ構成
私がFigmaから渡すときの最小パッケージは次の3点です。
- 設定UIのFigmaリンク（該当ページにピン留め）
- フォーカス順表（CSVまたはMarkdown）
- スクリーンショット1枚（フォーカスがかかっている状態の例）
Markdown仕様まで含める案件は、Cursorで仕様を起こす手順に続けて渡します。順番は表 → 仕様Markdown → 実装です。表が無いままCursorにスクショだけ渡すと、フォーカス順の生成が推測になりやすいです。
レビュー会で見るチェックリスト（15分）
納品前に、私は次だけを画面共有で確認します。
- 最初のフォーカスはどの項目か（起動直後）
- 最後の項目から「下」に押したとき、タブ内でループするか次タブに行くか
- 無効項目をスキップするか止まるか
- 変更を保存せず戻ったときの挙動
アクセシビリティの完全対応はタイトル規模次第ですが、フォーカスが行方不明にならないことだけは表で担保できます。大規模案件は柱のFigma制作フローも参照してください。
発売週に表を更新するときのルール
9月のように複数タイトルが重なる週は、設定項目がパッチで増えることがあります。表を「完成品」として封印せず、次の更新ルールを先に決めます。
- 追加行 … 末尾に追記し、既存の
focus_idは変更しない - 削除行 … 行を消すのではなく
deprecated列に日付を入れ、実装は1バージョン猶予で非表示 - 順序変更 … 変更理由を1行メモ（例: 「チュートリアル後に字幕項目を前面へ」）
私はクライアント向けに、表のGit履歴かFigmaのバージョン履歴とセットで渡します。スクショだけ再送すると、どの行が変わったかが伝わらず、実装側が全行再走査することになります。表は生きたドキュメントとして扱う方が、長期運用のコストは下がります。
パッチ当日はデザインの見た目より、表の差分メールを先に送るようにしています。見た目は後から追いつけますが、フォーカスが壊れるとプレイテストが止まります。
よくある質問
Q. タブが増えたとき、表はどう更新しますか？
A. focus_idを増やすだけにします。既存IDの「次フォーカス」列を書き換えるときは、実装に差分を明示します。タブ挿入は tab_order 列を1つ足すと、L1/R1の循環も追跡しやすいです。
Q. 設定項目が100を超えると表が重いのでは？
A. 重くなります。その場合はタブごとにシート分割し、共通部品（行コンポーネント）だけマスタ表にします。全項目を1枚に固めない方が、発売後のパッチ運用に向きます。
Q. Figmaのプロトタイプリンクで足りませんか？
A. クリックデモには向きますが、全フォーカス経路の網羅には向きません。プロトタイプはプレゼン用、表は実装用——と役割を分けるのが安全です。
Q. コントローラー記事と何が違いますか？
A. ACE COMBAT 8向けコントローラー比較のように、プレイ用デバイス選びはガジェット記事です。本記事はゲーム内メニューの設計と実装の橋渡しで、カテゴリも制作向けです。
まとめ
ゲーム設定 UI Figma では、見た目のフレームより先に、タブ順とフォーカス順の表を1タブ分でも書き切って実装に渡すと、発売週の手戻りが減ります。今日やるなら、手元の設定画面で「操作」タブだけ列を埋め、次フォーカスIDを英語で固定するところから始めてください。
関連: Figma Auto LayoutでHUDを整える / CursorでUI仕様Markdown / Figma制作の柱
