Figma Make プロンプト設計スキル（Unity画面向け）

Claude Codeで画面要件を壁打ちし、Figma Makeに貼り付けるプロンプトを生成する。 出典: Figma公式「8 Essential Tips for Figma Make」/ Ashrafの2段階プロンプト戦略 / iret「1000プロンプトのコツ」ほか

重要な前提: Figma MakeはMCPから起動できない（Figma MCPはMakeファイルの読み取りのみ対応）。 このスキルの成果物は「ユーザーが手でFigma Makeに貼るプロンプト」である。生成後の取り込みは Make生成 → ユーザーがFigma Designに貼り出し → レイヤー整理 → Figma MCPで取得 が標準手順。

フェーズ0: プロジェクト現状確認（ヒアリングの前に必ず行う）

対象画面が既にUnityに実装されている場合、ユーザーに聞く前に実装から事実を洗い出す:

1. UXML/USSを読む（プロジェクトのUIディレクトリ。例: Assets/_Project/UI/）— 静的なUI要素・命名・現在のレイアウト構造を把握
2. コントローラC#を読む（Assets/_Project/Scripts/）— コードで動的生成される要素を必ず拾う（例: おにぎりクリッカーのショップ行はUXMLに存在せず BuildShop() が生成する。UXMLだけ見ると要素が漏れる）
3. 現状スクショを確認（保存済みのものがなければuloopで撮る）— 現在の見た目（Before）を把握
4. ゲームの仕様・文言を把握（表示テキスト、ショップアイテム名、数値フォーマット等はプロンプトにそのまま使う）

この結果から「UI要素インベントリ（名前・種類・表示内容・状態変化）」を作り、フェーズ1に持ち込む。 新規画面（実装がまだない場合）はこのフェーズをスキップし、フェーズ1で全てヒアリングする。

フェーズ1: 壁打ち（入力ロック — ユーザーヒアリング）

フェーズ0で「事実」は揃っている前提で、ここではユーザーにしか決められないデザイン意思を聞く。 原則は「抽象的な言葉で聞かず、実物を見せて選ばせる」（視覚探索）。 以下が揃うまでプロンプトを生成しない。

1-a. 事実の確認（テキストで済む項目）

1. 画面名・用途（フェーズ0の結果を提示して確認）
2. プラットフォームと解像度 — 原則 1920x1080 横型で固定（Game View解像度と一致させ、後のスクショ比較を成立させるため）
3. UI要素の全列挙 — フェーズ0のインベントリを提示し、追加/削除/変更したい要素をユーザーに確認（曖昧な「いい感じに」は禁止）
4. 各要素の状態変化 — フェーズ0でコードから拾った状態一覧を提示し、演出強度を3段階の選択式で聞く: 控えめ（色変化のみ）/ 標準（色＋スケール）/ 派手（パーティクル・バウンス等）

1-b. スタイル探索（3ステップ。トークンを口頭で聞かない）

Step1: 方向出し（30秒診断） — AskUserQuestion等で以下を聞く:

• 形容詞対5つ（セマンティックディファレンシャル法）を「どちら寄りか」で: かわいい ⇔ かっこいい / ポップ ⇔ シック / 和風 ⇔ 洋風・未来的 / フラット ⇔ リッチ（質感） / にぎやか ⇔ ミニマル
• 避けたいテイスト・NG（必須）: 例「子供っぽすぎ / ごちゃごちゃ / 暗すぎ / 無機質 / 特になし」。語彙のないユーザーでも「嫌なもの」は即答できる
• 参考ゲーム: こちらからジャンルに合う候補を3〜5個提示して選ばせる（自由回答も可）。余裕があれば Game UI Database（https://www.gameuidatabase.com/）/ Interface In Game（https://interfaceingame.com/）で「近い画面を1枚」見つけてもらう。**良い例だけでなく嫌いな例も理由付きで**聞くと絞りが速い
• 任意: 好きなゲームUIのスクショを1〜3枚＋それぞれ「どこが好きか（色？形？密度？）」を一言ずつ（ムードボード方式）

Step2: スタイルタイル3案の生成→選択 — Step1の結果から方向性の違う3案を自己完結HTML（インラインCSS・1ファイル）で生成し、プレビュー保存先（例: materials/style-previews/<日付>/）に保存して提示する:

• 各案は実画面の縮小版モック（メインボタン・カウンター・ショップ行2つ程度）で、実際の文言（「おにぎり: 0」「自動にぎり手」等）を使う
• 各案の下部にトークン表（色HEX・角丸・フォント方針）を印字する — 「選択＝トークン確定」になり、後から聞き直す必要がなくなる
• 3案は意図的に方向を離す。1案をやや極端にすると「全部OK」型の迎合回答を検出できる（アウトライアープローブ）
• 「どれが近い？ AのボタンとBの背景を混ぜる、もアリ」と選択/ミックスを聞く

Step3: トークン確定 — 選ばれた案から色(HEX)・角丸・余白・フォント方針を逆算し、以下の8カテゴリチェックリスト（Anthropic frontend-designスキル由来）で「どの案の何を継承するか」を1行ずつ確定する（案の選択だけだと背景や質感が未決のまま残るため）:

タイポグラフィ / 色&テーマ / モーション / 背景 / レイアウト密度 / 装飾 / 質感 / コンポーネント形状

仕上げに signature を1問: 「この画面が記憶に残るとしたら、その1要素は何にしたい？」（例: 巨大おにぎりの照り、ショップの木札風デザイン）。Makeプロンプトの [Visual Style] の核になる。

選好プロファイルの保存: 確定したトークン・形容詞対の回答・NGテイスト・**演出仕様（どの操作で何がどう動くか。例: おにぎり押下で縮む＋「+1」が浮いて消える）**を選好ドキュメント（例: docs/デザイン選好.md）や壁打ちログに保存する。演出は静的デザインに残らずMCPでも取得できないため、この記録がUnity実装時の唯一の仕様源になる。同じゲームの別画面をヒアリングする際はこれを読み、差分だけ質問する（トンマナの一貫性維持）。

理解チェックポイント: 生成前に「フェーズ0で確認した事実／スタイル探索で決まった意思（選択案・トークン・NG・signature）／まだ足りない情報」を要約してユーザーに確認する。

フェーズ2: プロンプト生成（2段階方式）

①システムセットアップ用プロンプト（最初に1回だけ投入）

これから[ゲーム名]のUI画面を作ります。まず以下をこのプロジェクトの共通ルールとして設定してください。

デザイントークン:
- PRIMARY_COLOR: #xxxxxx / SECONDARY_COLOR: #xxxxxx / BG_COLOR: #xxxxxx
- 角丸: カード12px・ボタン8px / 基本余白: 16px / フォント: [和文ゴシック等]

コンポーネントライブラリ「[ゲーム名] UI Kit」として、ボタン(通常/押下/無効)・
カウンター表示・リスト行 の基本コンポーネントを先に定義してください。
以後の画面生成ではこのライブラリのコンポーネントだけを使ってください。

画面は必ず width:1920px / height:1080px の固定サイズコンテナとして作ってください。
可変幅（レスポンシブ）レイアウトにせず、ウィンドウに合わせてリサイズしないでください。

Makeはサイズ指定を厳守しないことがある（4:3相当で生成された実例あり）。プロンプトで固定を明示しつつ、最終保証はフェーズ4の載せ替え工程で行う。

②スクリーン生成用プロンプト（画面ごと）

5要素（Context / Description / Platform / Visual Style / UI Components）＋最小構造足場で構成:

画面デザインモードで、「[ゲーム名] UI Kit」を使って新しい画面「[画面名]」を作ってください。

[Context] これは[誰向け]の[ジャンル]ゲームの[画面名]です。
[Platform] PC・1920x1080固定・横型。
[Visual Style] [参考テイスト]。[トーン形容詞2-3個]。
[UI Components] 構造の足場（**主要要素は実寸をpxで指定する** — 後の1920×1080載せ替え時の破綻を防ぐ）:
- 画面左中央: [メイン要素]（例: 直径520pxの円形ボタン）
- 上部: [カウンター等]
- 右側: [リスト等（行の構成要素を列挙。例: 行の高さ96px）]
[Behavior] [状態変化を条件分岐で]（例: 所持数が足りない行の購入ボタンはグレーアウト）

制約:
- これはWebアプリではなくゲームのUIです。Webフォーム/管理画面/ダッシュボード的な見た目を避けてください
- ドロップシャドウの多用・複雑なグラデーションは避け、単色ベース＋強弱は明度差で表現してください
- すべてのレイヤーに意味のある名前を付け、Auto Layoutを使ってください
- 上記[UI Components]に列挙した要素だけで構成してください。指定にないUI（設定・実績・通知・ヘッダーアクション・装飾的な統計表示等）を追加しないでください。追加した方が良いと思う要素があれば、デザインに入れずにテキストで提案してください
- アイコンや絵柄は絵文字（🍙等）で表現してください。画像アセットやカスタムイラストを作らないでください

要件外要素の禁止と絵文字統一の理由（実運用で確認）: Makeは放っておくと設定/実績ボタン・統計表示等を自主的に追加し、ゲームロジックと結線されない「動かない飾り」がUnity側に残る。また絵文字はUnity UI Toolkitがそのままカラー描画できる（Unity 6 / macOSで実機検証済み）ため、画像エクスポート問題を丸ごと回避できる。

Unity変換を見据えた制約（②に必ず含める理由）

生成物は最終的にUXML/USSへ翻訳される。USSは box-shadow / CSS Grid / blur が使えない（詳細: uitk-import スキルの references/css-to-uss-checklist.md）。 Figma段階で多用されると変換で破綻するため、影・ぼかし・複雑なグラデーションを避ける指示をプロンプト側に仕込む。

フェーズ3: 修正プロンプトの定型

• 大枠はやり直さずピンポイント指定: 「[要素名]の[プロパティ]を[具体値]に」（「もう少し大きく」ではなく「幅を320pxに」）
• 色・角丸・余白の微調整はプロンプトではなくFigmaのPoint and Editツールをユーザーに勧める
• レイアウトの大改造はMakeで粘らない → 「Designに貼り出して手で直す」ことを提案（iret知見）
• 要素が多い画面で生成が長い/タイムアウトする場合: 「ページ/セクションごとに分割して生成してください」を先頭に足す

フェーズ4: 引き渡しチェックリスト（Make完了後にユーザーへ案内）

• 生成画面をFigma Designファイルに貼り出したか
• レイヤー名がセマンティックか（Group 45 → ShopRow 等にリネーム）
• Auto Layoutが維持されているか
• フレームサイズが1920x1080か。Make出力が別サイズ（4:3等）だった場合は、Designに1920×1080のフレームを新規作成し、その中へ移して再レイアウトする。比率が違うときは全体を一括スケールせず、主役要素（メインボタン等）は壁打ちで決めた寸法まで個別に拡大し、余った幅は余白・パネル幅の調整で吸収する（一括で流し込むと主役が小さくなる）
• 正解画像のエクスポート: 対象フレームを右クリック→Export（PNG・1x）で書き出し、正解画像置き場（例: docs/design-refs/<画面名>.png）に保存したか（MCPのget_screenshotはファイル保存できないため人力必須。これがUnity検証のground truthになる）
• 以上を満たしたらFigma MCP（get_variable_defs → get_design_context → get_screenshot）で取り込み、 uitk-import スキル（プロジェクトルート .claude/skills/uitk-import/）でUXML/USS化する