概要
最近出たuse_figmaプラグイン…
ずっとUI系の仕事をしてたので、さすがに試してみたいですよね。
ということで触ってみたという記事です。
ついでにDESIGN.mdなるものも出てきたらしく。
指示さえできれば、指示されできればしっかりしたデザインをAIで作れるんじゃ？って検証も一緒にしたいと思います。
情報
use_figma plugin: https://github.com/figma/mcp-server-guide/blob/d8bcb41b17ae473b3a830129bcd451ee1911e512/skills/figma-use/SKILL.md
figma公式: https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/
DESIGN.md: https://qiita.com/miruky/items/a6312c14e6352376ec00
環境
- Windows11 home
- WSL2 Ubuntu22.04.4
- Cursor 2.6.22 Proプラン
環境設定
プラグインインストール
Cursor Settings > Plugins > Figma
figma-useがあることを確認したら（しなくてもいいが。）Add to Cursorでプラグインをインストール
Figma MCP接続
再びCursorSettings > tools & MCP > Plugin MCP Servers からconnect
DESIGN.mdの作成
CLAUDE.mdと同じ要領で作れるとのことで、agentに作らせてみる。
だいたいどんなUIデザインにしたいかな～を頭に浮かべつつ・・・
あなたはWebUIデザイナです。
DESIGN.mdを作成してください。
以下詳細な要件です。
全体的なデザインはモダンなWebUIで、デザインベースはそちらに任せる。
ユースケースはiOSブラウザ、Windowsブラウザ。
色はオレンジと黄色を基調とした暖かみのあり家庭的な構成とし、色度が低めで目に優しいカラーベースを取る。
ボタンインタラクションはホバー、押下、選択中、通常の4種類。
遷移、UIを説明する文章などは最小限に、アイコンなど非テキスト的な表現をベースとする。
その他、今のプロジェクトに必要なUIの内、上記で定義されていない内容があれば質問して↑こんな指示をしてみて、
↓こんなのを生成させてみた。
# Meal Menu App — Web UI デザインガイド
本書は [docs/plan/implementation-plan.md](../docs/plan/implementation-plan.md) の Web フロント（Next.js + Tailwind + FullCalendar）に対する**見た目とインタラクションの規範**である。実装は [tailwind.config.ts](./tailwind.config.ts) と [src/app/globals.css](./src/app/globals.css) にトークンを反映していく。
## 1. スコープと前提
| 項目 | 内容 |
|------|------|
| アプリ | Meal Menu App（献立カレンダー） |
| 対象画面 | `/`（ログイン導線）、`/app`（献立カレンダー：月・週・日・リスト表示、範囲選択・イベント操作）、`/app/menus`（メニュー CRUD） |
| クライアント | **iOS Safari**、**Windows**（Chrome / Edge / Firefox を想定した一般的な挙動） |
| テーマ | **ライトのみ**。ダークテーマ用の色トークンは定義しない |
## 2. デザイン原則
- **トーン**: モダンな Web UI。家庭的で暖かみのある印象を、**低彩度**のオレンジとイエロー（クリーム〜アンバー系）で表現する。
- **情報量**: 画面説明・遷移を文章で長く書かない。可能な範囲で**アイコン・レイアウト・色分け**で状態を伝える。
- **ラベル**: ナビや主要操作は**アイコンを主**とし、短いラベルは任意。アイコンのみのコントロールは [§7](#7-アイコンと非テキスト-ui) と [§8](#8-アクセシビリティ) に従う。
## 3. カラートークン（セマンティック）
彩度は抑え、背景と本文のコントラストは **WCAG 2.1 の AA（本文 4.5:1 相当）** を満たすことを前提に調整する。下表の例は参照用であり、実装時は測定して微調整してよい。
| トークン名 | 用途 | 例（参照） |
|------------|------|------------|
| `--color-background` | ページ全体の下地 | ごく薄いクリーム〜ウォームグレー |
| `--color-surface` | ヘッダー・カード・パネル | 白に近いオフホワイト |
| `--color-surface-elevated` | モーダル・ドロップダウン等の一段上 | `surface` よりわずかに明るい or 影で区別 |
| `--color-border` | 区切り線・入力枠 | 低彩度のオレンジグレー |
| `--color-text-primary` | 見出し・本文 | 暖みのあるダークブラウン〜チャコール |
| `--color-text-muted` | 補助・メタ情報 | `text-primary` より明度を上げた色 |
| `--color-accent` | 主 CTA・リンク強調・選択の主色 | **ミュートされたオレンジ** |
| `--color-accent-soft` | ハイライト背景・バッジ・「今日」など | **低彩度のイエロー〜ピーチ** |
| `--color-danger` | 削除・エラー（使用頻度は低め） | 彩度を抑えたテラコッタ〜レッドブラウン |
| `--color-success` | 成功（任意） | 彩度を抑えたオリーブ〜セージ |
**禁止に近いこと**: ネオン調の高彩度オレンジを全面背景にしない。`accent` は「塗りつぶしの大面积」より、ボタン・フォーカス・小さな強調に使う。
## 4. タイポグラフィ
- **フォント**: ルートレイアウトで読み込んでいる **Geist** 系（`--font-geist-sans` 等）を既定とする。変更する場合は本書と [src/app/layout.tsx](./src/app/layout.tsx) を同時に更新する。
- **階層**（目安）:
| 役割 | 目安 |
|------|------|
| ページタイトル | 例: `text-xl`〜`text-2xl`、`font-semibold` |
| セクション見出し | 一段階小さく、`font-semibold` |
| 本文 | `text-sm`〜`text-base`、`leading-relaxed` |
| キャプション・補助 | `text-xs`〜`text-sm`、`text-muted` |
- **行の長さ**: 説明文が続くブロックは **最大幅を制限**（例: `max-w-prose` 相当）し、長文は避ける（§2 と整合）。
## 5. スペーシング・レイアウト・タッチ
- **コンテナ**: メインコンテンツは既存と同様、**最大幅 ~72rem（`max-w-6xl` 前後）** を基準とし、横余白は `px-4` 程度を維持する。
- **タッチターゲット（iOS）**: タップ可能な要素は **最短辺 44px 相当以上**（`min-h-[44px] min-w-[44px]` または十分な `padding`）を満たす。
- **密度**: 献立カレンダー・メニュー一覧は誤タップを避けるため、リスト行・カレンダーセル内の操作域は余白を確保する。
## 6. ボタンとインタラクション
すべてのボタンおよび「ボタン相当」のクリック領域（セグメント切替・ツールバーのアイコンボタン等）は、次の **4 状態**を区別できること。
| 状態 | 条件 | 見た目の指針 |
|------|------|----------------|
| **通常** | デフォルト | `accent` または `surface`＋`border`。本文とのコントラストを確保 |
| **ホバー** | ポインタが乗る（`:hover`、タッチでは該当しにくい） | 背景を一段変化、または境界・影をわずかに強める |
| **押下** | クリック中（`:active`） | ホバーより一段暗く、または内側に沈む影で「押している」ことを示す |
| **選択中** | トグル ON・セグメント選択・リストの現在行など（`aria-pressed="true"` / `aria-current` / `data-state=selected` 等と対応） | `accent-soft` の背景＋`accent` の境界または下線で明確に |
**キーボード（Windows 含む）**: `:focus-visible` 時は **必ず視認できるフォーカスリング**（`accent` 系のアウトラインまたはリング）を付与する。マウスだけの `:focus` と区別してよい。
## 7. アイコンと非テキスト UI
- **セット**: 新規にアイコンライブラリを入れる場合は **Lucide React** を第一候補とする（未導入でもよい。導入時は依存関係とツリーシェイクを考慮）。
- **一貫性**: 献立カレンダー・メニュー・ログアウトなど、**同じ意味には同じアイコン**を使う。ストローク太さ・グリッドサイズ（例: 20px / 24px）を揃える。
- **装飾**: アイコン色は `text-primary` / `text-muted` / `accent` のいずれかに寄せ、カラフルな絵文字に頼らない。
## 8. アクセシビリティ
- **名前**: アイコンのみのボタン・リンクには **`aria-label`**、または画面上は隠した短いテキスト（visually hidden）で**操作名**を必ず付与する。
- **状態**: 選択中・展開済みなどは `aria-expanded` / `aria-pressed` / `aria-current` を適切に使う（§6 の「選択中」と連動）。
- **コントラスト**: §3 の前提を満たさない組み合わせは採用しない。
## 9. FullCalendar（サードパーティ）
[src/app/globals.css](./src/app/globals.css) の `--fc-*` 変数は、**§3 のトークンと矛盾しない**ようにマッピングする。
| FullCalendar 変数 | マッピングの考え方 |
|-------------------|-------------------|
| `--fc-page-bg-color` | `--color-background` に合わせる |
| `--fc-neutral-bg-color` | `--color-surface` またはややニュートラルな拡張 |
| `--fc-border-color` | `--color-border` |
| `--fc-button-bg-color` 等 | ツールバーボタンは §6 の「通常／ホバー／押下／選択中」に対応できる色 |
| `--fc-today-bg-color` | `--color-accent-soft` |
| `--fc-button-text-color` | `--color-surface` 上で読める色（必要ならボタン専用のオンカラー） |
カレンダー内の献立イベント（`.meal-banner` 等）も、**本文が読めるコントラスト**とトークンとの整合を保つ。
## 10. 実装メモ（Tailwind との関係）
- **CSS 変数**: `:root` に §3 の名前を定義し、Tailwind の `extend.colors` で `background: 'var(--color-background)'` のように参照する方法を推奨する。
- **併用**: コンポーネント単位で `bg-[var(--color-accent)]` のように直接参照してもよいが、**名前の一覧は本書と `globals.css` で一致**させる。
- **既存の `--background` / `--foreground`**: ルートの意味を本トークン体系に寄せるか置き換えるかは実装 PR で決め、本書のセマンティック名を優先する。
## 11. 本書で扱わないもの
- **ダークモード**用のパレット（§1）。
- **コンポーネントごとのピクセルパーフェクト仕様**の網羅（必要なら Figma や個別issueで補完）。
---
*最終更新: デザイン変更時に本書を更新し、実装（Tailwind・globals・FullCalendar 上書き）と同期すること。*
figma_useプラグインでfigma上にデザインを作ってもらう
いよいよ本題。
Figma上にデザインを作ってもらう…！！
/figma-use あなたは熟練のWebUIデザイナです。
@apps/web/DESIGN.md に従い、このプロジェクトに沿うUIデザインをfigma上に作成してください。・・・ん？
じょ、じょうげん・・・？？？
ｲﾔｱｱｱｱｱｱｱｱｱｱｱ
悲しみの課金。そして続き。
出来上がったものが以下。
・・・・・・・・・🤔
Figma Makeと大差なくね？？？？？？？
適当に作らせたUIの色付け版みたいになっちゃった。
多分指示が悪かった、、、のだと思いたい。。。
（プロンプトエンジニアリング下手なんでもっと勉強しなければ…）
もう少し調べてみた
どうやらDESIGN.mdはCLAUDE.mdとは違い、便宜上のファイルのようで、
別にこの名称じゃなくてもいいし、なんなら複数ファイルに跨っていても良いらしい。
→最終的にCLAUDE.mdでルーティングできてれば問題ない。
そして、Stitch向けのテンプレート ということらしい。
まぁ概念は応用できるが、完全に同じ使い方は難しそう。
そして、サンプルではこれを元にチャットベースでUI構築を行い、index.htmlを作成することで作っていたよう。
つまりfigmaなどのデザインツールとMCP連携して云々はそもそも使い方が違いそう。
思い描いたワークフロー
画期的じゃん！って思ったのは理由があって、
これ業務活用することでデザイナが抱える属人性の低下や、発生しがちな用語の定義ブレ、
その他あらゆる問題をmdに強制させて、チーム開発の速度・精度向上、さらにエンジニアリングを追加してフロント実装も手軽にできるようにできるのでは？！
って考えてた。
どゆことっていうと、
md（DESIGN.md）を一種の仕様書のように扱うことができ、
md ↔ figma で最終的にデザイン設計を複数のmdに残すことで、
デザインノウハウの回収、流用のベース（skill化など）に応用できる
って考えてた。
結局はコードベースになっちゃうけど、
個人的にfigmaが仕様書です！のスタイル大嫌いだからむしろこうなってほしい感はある。。。
あったのだが！力及ばず・・・
どこかでリベンジしたみ
もう少し手を加えてみる
ちょっと悔しいのでプロンプト修正
/figma-use
https://www.figma.com/design/IKKjvbf33ZD9zbUs5wce8E/Meal-Menu-App---Web-UI--DESIGN.md-?node-id=0-1&p=f&t=BWaZoI4S6TLTZSw9-0
@apps/web/DESIGN.md に従いUIを作成してもらったが、ここからデザインの修正を加えたい
まず元々apps/webに作成されたデザインがベースのようになっているが、これを一切廃止し、完全新規でDESIGN.mdに従った条件でリデザインして欲しい。
次にポップアップで表示されるべき内容のデザインがないため、全ポップアップ遷移を含めてデザイン作成をしてほしい。
またアイコンはSVGで作成し、テキストによる説明は基本NGとする。
レスポンシブデザインに対応し、iOS、PC、ブラウザ拡縮などに対応し、適切なUXを得られるようなUIをデザインして欲しい。
なお使い回しが可能なものに関してはコンポーネント化すること。
以上条件に従って修正して。
おお、悪くないか？
（Googleマークはアウトなんじゃ・・・）
あ、だめそう。
やっぱり仕様に起こされてない部分が激よわ。
全画面分の要件をドキュメント化することができれば実現可能なのか？
→それはデザイナにとって嬉しいのか・・・？
今回はタイムオーバー
次やるときはもう少し情報仕入れてリベンジしたい！
＼ 最新情報をチェック ／
コメント