概要
Figma MCPを使った高品質なコード生成を実現するために、Figmaデータをどのように作れば良いのか、どのようなプロンプトで指示を出せば良いかを調べました。
20パターンの検証で分かったことを記事にしています。
この記事で分かること
- Variables, Auto Layout, Layer Names, Annotationsが生成コードに与える影響
- 20パターンの検証結果と、各機能の組み合わせでの発見
- 最終的な推奨設定とプロンプトテンプレート
想定読者
- Figma MCPを使ってコード生成したいデザイナー・エンジニア
- デザインシステムを構築しているチーム
- AIコード生成の品質を高めたい人
結論(先に知りたい方向け)
20パターンの検証を通じて得られた結論を先に示します。
詳細な検証過程は後述します。
推奨Figma設定
当たり前の結論かもしれませんが、全要素を有効にすることを推奨します。
- Variables: Figmaデータ作成時の効率化、デザイントークンの一貫性
- Auto Layout: 最重要、これがないと絶対配置から脱却できない
- Layer Names: 可読性、デバッグ性の向上(優先度はやや低め)
- Annotations: セマンティック化、型定義の改善(優先度は低め)
推奨プロンプト
以下のようなプロンプトで、実装上の必須要素を明示的に指示することが重要です。
Please generate a React TypeScript component with Tailwind CSS from the Figma page [PAGE_NAME] in [FIGMA_URL].
IMPORTANT Requirements:
1. Variables Mapping:
- Map Figma Variables to standard Tailwind classes
- Use `bg-slate-50` instead of `bg-[var(--slate-50)]`
- Use `text-sm` instead of `text-[length:var(--size-sm)]`
2. Semantic HTML:
- Use semantic elements (`header`, `nav`, `main`, `aside`, `footer`)
- Use <button> for interactive elements
- Use <a> for links
3. Interactive Elements:
- Add hover states (hover:text-blue-600)
- Add transitions (transition-colors)
- Add focus states where appropriate
4. Code Quality:
- Use TypeScript interfaces for props and data
- Use data-driven approach with .map() for repeated elements
- Next.js Image/Link components where applicable
- Clean, production-ready code
Use @figma-mcp-server to access the design.
重要な要素
検証を通じて、以下の要素が重要であると分かりました。
Figma設定とプロンプトの両方が重要
適切なFigmaデータが作れていなければ、どれだけ詳細なプロンプトを書いても良いコードは生成されません。
特にAuto Layoutが無効の場合、絶対配置のコードしか生成されず、プロンプトでの改善には限界がありました。
一方で、Figmaデータが整っていても、プロンプトが不十分だと期待した品質に達しません。
両方を最適化することで初めて高品質なコード生成が実現します。
Variablesは推奨(ただし適切なプロンプトが前提)
検証の途中までは「Variablesを設定するとむしろアウトプット品質が低下する」という状態でした。
これはかなり意外でしたが、今回の検証環境では何度試しても同じような出力になったので、まったく誤りというわけではないと思います。
シンプルなプロンプトではVariables有効時にセマンティックHTML化が抑制される問題が発生しましたが、包括的なプロンプトで解決しました。
適切なプロンプトを使用すれば、VariablesはTailwind標準クラスに正しく変換され、実務として有益です。
Auto Layoutは必須
Auto Layoutがないと絶対配置のコードになり、保守性が大きく低下します。
他の要素と異なり、Auto Layoutはプロンプトだけでは補えない根本的な構造の問題に関わるため、最も重要な要素です。
Figma MCPを活かすための3要素
- 適切なFigmaデータ作成: Variables, Auto Layout, Layer Names, AnnotationsとAIが参照できそうなものはできるだけ使う
- 包括的なプロンプト使用: 明示的で詳細な指示
- 継続的な改善: プロンプトとFigmaデータの最適化
以降のセクションでは、これらの結論に至るまでの検証過程を詳しく説明します。
検証の背景と目的
Figma MCPは、Figmaのデザインからコードを生成できる強力なツールです。
しかし、「どのようにFigmaデータを作れば高品質なコードが生成されるのか」という疑問がありました。
Figmaには色々な機能がありますが、それらがコード生成品質にどう影響するのかを理解するため、全20パターン(2^4=16の基本パターン + プロンプトバリエーション4パターン)の検証をしました。
検証設計
検証する4要素
Variables
Figmaで定義した色、サイズ、余白など、いわゆるデザイントークンです。
これが生成コードで標準Tailwindクラス(例: bg-slate-50, text-sm)に変換されることを期待しました。
Auto Layout
いわずと知れたレイアウトの機能です。
これによって絶対配置ではなく、flexやgridベースのレスポンシブなコードが生成されることを期待しました。
Layer Names
レイヤーに意味のある名前を付けることです。
セマンティックなHTMLの生成やコードの可読性、デバッグ性を向上させることを期待しました。
Annotations
デザインの意図や実装上の注意などを記述する機能です。
型定義やインタラクションの改善につながることを期待しました。
検証パターン
有効にする機能数で4セッションに分けて検証したあと、追加でプロンプトの違いによるアウトプットの差を検証しました。
| セッション | 検証内容 | パターン数 |
|---|---|---|
| セッション0 | ベースライン(全要素無効) | 1 |
| セッション1 | 単独効果 | 4 |
| セッション2 | 2要素組み合わせ | 6 |
| セッション3 | 3要素組み合わせ | 4 |
| セッション4 | 全要素有効 | 1 |
| セッション5, 6 | プロンプトバリエーション | 4 |
各パターンには、4桁のコード(例: v0110)を割り当てました。各桁は左から順に Variables, Auto Layout, Layer Names, Annotationsの有効(1)/無効(0)を表します。
検証環境
検証には以下の環境を使用しました。
- Next.js 16.0.6(App Router)
- React 19.2.0
- TypeScript 5.9.3
- Tailwind CSS 4.1.7
create-next-appでスキャッフォールド後、各パターン用のページを作成(app/v0000/page.tsx〜app/v1111-3/page.tsx)しています。
FigmaデータとしてはダッシュボードのようなUIを用意しました。
そして、同じ見た目で各種機能を使用している・していないで16パターンを作成しています。
そして、セッション0から4では以下のシンプルなプロンプトを使用しました。
Please generate a React TypeScript component with Tailwind CSS from the Figma page [PAGE_NAME] in [FIGMA_URL].
Use @figma-mcp-server to access the design.
Generate clean, production-ready code following React best practices.
このシンプルなプロンプトにより、Figma設定のみの影響を観察することを意図しました。
評価観点
生成されたコードを以下の観点で定性評価しました。
- レイアウト・ビジュアルの正確性: Figmaデザインとの一致度
- コードの品質: マークアップの正確性、命名の適切さ、TypeScript型定義
- Tailwind CSSの使い方: 標準クラスの使用、任意値の削減
- 保守性: 可読性、再利用性
なお評価の補足として、以下があります。
- レイアウト・ビジュアルの正確性については、全パターンでFigmaデザインとの高い一致度が得られた
- そのため本記事では主にコード品質、Tailwind CSSの使い方、保守性に焦点を当てて比較する
- 今回は単一ページの実装を検証対象としたため、コンポーネントの分割や命名規則については評価対象外とする
- 実務ではこれらも重要な観点となるものの、検証が大変になり過ぎるため仕方なく除外
セッション0: ベースライン(v0000)
このセッションで分かること:
全要素無効の状態では絶対配置による脆弱な構造になり、レスポンシブ対応などが不可能。
まず、全要素を無効にしたベースライン(v0000)を検証しました。
結果として生成されたコードは、絶対配置による脆弱な構造でした。
// v0000: 全要素無効
<div className="bg-slate-50 relative size-full">
<div className="absolute h-[304px] left-[24px] top-[24px] w-[256px]">
<div className="absolute h-[232px] left-0 top-0 w-[256px]">
<div className="absolute bg-blue-100 h-[40px] left-0 rounded-[8px] top-0 w-[256px]">
{/* コンテンツ */}
</div>
</div>
</div>
</div>
主な特徴
- すべての要素が
absoluteで配置 - 固定ピクセル値(
left-[24px],w-[256px])による脆弱な構造 - レスポンシブ対応が不可能
- 要素の追加・削除が困難
このベースラインを起点に、各要素の効果を検証していきます。
セッション1: 単独効果の検証
このセッションで分かること:
Auto Layoutを適用すると、絶対配置のコードからflexのコードになり、最も効果的。
Variablesは単体では期待した標準クラス変換を行わない?
Variables単体(v1000) - 期待外れの結果
Variables単体での検証では、デザイントークンが標準Tailwindクラスに変換されることを期待していました。
しかし、そうは行きませんでした。
// v0000: ベースライン(Variables無し)
className="text-[length:var(--size-sm,14px)]"
className="rounded-[var(--radius-lg,8px)]"
// v1000: Variables有効
className="text-[length:var(--size-sm,14px)]" // 変わらず
className="rounded-[var(--radius-lg,8px)]" // 変わらず
主な特徴
- CSS変数
var()の参照は生成される - しかしTailwindの標準ユーティリティ(
text-sm,rounded-lg)への変換はされない - フォールバック値付きの記述のみ
Variables単体では期待した効果は得られませんでした。
MCPがVariablesを認識はするものの、Tailwind設定との統合は行わなかったのだと推測されます。
Auto Layout単体(v0100) - 大きな改善
Auto Layoutの検証では、大きな改善が見られました。
// v0000: ベースライン(絶対配置)
<div className="absolute h-[304px] left-[24px] top-[24px] w-[256px]">
<div className="absolute h-[232px] left-0 top-0 w-[256px]">
<div className="absolute bg-blue-100 h-[40px] left-0 rounded-[8px] top-0 w-[256px]">
{/* コンテンツ */}
</div>
</div>
</div>
// v0100: Auto Layout有効(flex)
<div className="flex flex-col gap-[var(--size-8,32px)]">
<div className="flex flex-col gap-[var(--size-2,8px)]">
<div className="bg-blue-100 rounded-[var(--radius-lg,8px)]">
{/* コンテンツ */}
</div>
</div>
</div>
// v0000: 3層の絶対配置ラッパー(必要性が低い)
<div className="absolute ...">
<div className="absolute ...">
<div className="absolute ...">
<button>New Project</button>
</div>
</div>
</div>
// v0100: 必要最小限の構造
<button className="bg-blue-600 h-[40px] rounded-[var(--radius-lg,8px)]">
New Project
</button>
主な改善点
- 構造の明瞭さ:
flex,flex-col,gapによる意図の明確化 - 余白の一貫性:
gapで子要素間の余白を統一 - レスポンシブ対応: 相対的なレイアウトにより画面サイズへの適応が容易
- 保守性: 要素の追加・削除・並び替えが簡単
- 階層の簡潔さ: 不要な絶対配置用のラッパーが減少
また、若干細かい粒度の話ですがテーブルレイアウトも改善されました。
// v0000: 絶対配置のセル
<div className="absolute h-[46px] left-0 top-0 w-[243px]">
<p>Project</p>
</div>
<div className="absolute h-[46px] left-[243px] top-0 w-[200px]">
<p>Team</p>
</div>
// v0100: セマンティックなテーブル構造
<table className="w-full">
<thead>
<tr className="border-b border-slate-300">
<th className="text-left px-4 py-3">Project</th>
<th className="text-left px-4 py-3">Team</th>
</tr>
</thead>
</table>
Auto Layoutがコード品質に与える影響は大きなものでした。
Layer Names単体(v0010) - デバッグ支援
Layer Namesの検証では、data-name属性の追加によるデバッグ性の向上が確認できました。
// v0000: 意味のないネスト構造
<div className="absolute h-[304px] left-[24px] top-[24px] w-[256px]">
<div className="absolute h-[232px] left-0 top-[256px]">
{/* ... */}
</div>
</div>
// v0010: セマンティックな属性付き
<div data-name="Aside" className="absolute h-[304px] left-[24px] top-[24px] w-[256px]">
<div data-name="Menu" className="absolute h-[232px] left-0 top-[256px]">
<div data-name="Current page" className="absolute bg-blue-100 h-[40px]">
{/* ... */}
</div>
<div data-name="Link" className="absolute h-[40px]">
{/* ... */}
</div>
</div>
</div>
実用的な価値
- デバッグ支援: ブラウザのDevToolsでFigmaレイヤー名を確認可能
- ドキュメント性: コンポーネントの役割が自己文書化される
ただし、コード構造そのものは変わらず、絶対配置が残ります。Layer Namesだけでは保守性・拡張性は向上しません。
Annotations単体(v0001) - 効果は限定的
Annotations単体の検証では、ほとんど変化が見られませんでした。
一部変化はあったものの、その内容はAnnotationsではなくTop Level Frameの名前がdata属性に記載されたというものだったので、直接的な影響は無かったと判断します。
セッション1のまとめ
単独効果ランキング
- Auto Layout(
v0100) - 構造・保守性に大きな改善 - Layer Names(
v0010) - デバッグ性・可読性の向上 - Variables(
v1000) - CSS変数の参照が追加されるが変換は不完全 - Annotations(
v0001) - 現時点で実質的な効果は無し
この時点での暫定的なベストプラクティスは、Auto Layoutを最優先で設定することでした。
セッション2: 2要素組み合わせの検証
このセッションで分かること:
Auto Layout + Layer Namesが優れた可読性を実現。
Variables + AnnotationsでTypeScript型定義が生成されるという予想外の動き。
セッション2では、6パターンの2要素組み合わせを検証しました。
| コード | 組み合わせ | 評価 |
|---|---|---|
v1100 |
Variables + Auto Layout | 中 |
v1010 |
Variables + Layer Names | 低 |
v1001 |
Variables + Annotations | 高 |
v0110 |
Auto Layout + Layer Names | 高 |
v0101 |
Auto Layout + Annotations | 中 |
v0011 |
Layer Names + Annotations | 低 |
Variables + Auto Layout(v1100) - 期待された相乗効果なし
VariablesとAuto Layoutの組み合わせなら、CSS変数がTailwind標準クラスに変換されるかもしれないと期待していました。
しかし、その仮説は不成立でした。
// v1100: Variables + Auto Layout
<div className="bg-[var(--slate-50,#f8fafc)] flex flex-col">
<div className="bg-[var(--blue-100,#dbeafe)] rounded-[var(--radius-lg,8px)]">
<p className="text-[color:var(--blue-600,#2563eb)] text-[length:var(--size-sm,14px)]">
Dashboard
</p>
</div>
</div>
// 期待していた出力
<div className="bg-slate-50 flex flex-col">
<div className="bg-blue-100 rounded-lg">
<p className="text-blue-600 text-sm">Dashboard</p>
</div>
</div>
Auto Layoutによる flex, flex-col は生成されますが、色やサイズはセッション1と同様に var() を使った任意値のままでした。
Variables + Annotations(v1001) - 想定外のTypeScript型定義生成
Variables + Annotationsの組み合わせでは、想定外の成果がありました。
TypeScript interfaceが生成されたのです。
// v1001: Variables + Annotations
interface NavItem {
icon: string;
label: string;
active?: boolean;
}
interface FeaturedProject {
image: string;
title: string;
description: string;
}
interface Project {
name: string;
team: string;
status: "Active" | "Completed" | "Planning";
progress: number;
}
export default function V1001Page() {
const navItems: NavItem[] = [
{ icon: imgFrame37, label: "Dashboard", active: true },
{ icon: imgFrame39, label: "Projects" },
];
const featuredProjects: FeaturedProject[] = [
{
image: imgFrame74,
title: "Project Phoenix",
description: "Develop a new marketing strategy",
},
];
}
主な改善点
- TypeScript interfaceの生成:
NavItem,FeaturedProject,Project - データ駆動のアプローチ: 配列 +
.map()による柔軟なレンダリング - Union型の使用:
status: "Active" | "Completed" | "Planning" - セマンティックHTML:
header,nav,aside,main,sectionを活用
ただしレイアウトは絶対配置ベースのため、完璧ではありません。
Annotationが「デザイン仕様の意図」を伝え、MCPが型定義を生成したのでしょうか。
Annotationは他要素との相乗効果で真価を発揮するということかもしれません。
Auto Layout + Layer Names(v0110) - 高い可読性
Auto Layout + Layer Namesの組み合わせは、セッション2の時点では最も可読性の高いコードを生成しました。
// v0110: Auto Layout + Layer Names
<div className="bg-slate-50 flex flex-col">
<div className="bg-slate-50 border-b border-slate-300 sticky top-0" data-name="Header">
<div className="flex items-center justify-between px-6 py-3">
<div className="flex gap-10 items-center" data-name="Container">
<div className="h-6 w-[135px]" data-name="Logo">
{/* ... */}
</div>
<div className="flex gap-6" data-name="Links">
<p>Dashboard</p>
<p>Projects</p>
</div>
</div>
</div>
</div>
</div>
主な特徴
- flexレイアウト: 柔軟で保守性の高い構造
- セマンティックな属性:
data-nameでコンポーネントの役割が明確 - 標準Tailwindクラス:
bg-slate-50,text-blue-600,border-slate-300(一部) - 階層の明瞭さ: Header, Container, Logo, Linksなどが明示的
デバッグ体験も優れています。
ブラウザのDevToolsで data-name="Header" を見つけやすく、Figmaのレイヤー構造とコードの対応付けが容易です。
ただ、ここまでTailwind CSSの標準のクラス名が指定されなかったのに、ここに来て一部指定された理由は分かりません。
いずれにしても、この時点では、Auto Layout + Layer Namesが最適解と考えられました。
その他の組み合わせ
- Auto Layout + Annotations(
v0101): Auto Layout効果のみ、Annotationによる型定義改善は今回は見られず - Variables + Layer Names(
v1010): 絶対配置のまま、改善なし - Layer Names + Annotations(
v0011): セマンティックなHTMLは生成されるが絶対配置のまま
セッション2のまとめ
- Auto Layoutは必須条件: Auto Layoutがない組み合わせは絶対配置から脱却できない
- Variables + Annotationsの意外な効果: TypeScript型定義が生成される
- ただし常に生成されるわけではない
- 条件は不明
- Auto Layout + Layer Namesが暫定ベスト: 可読性・保守性がともに良い
セッション3: 3要素組み合わせの検証
このセッションで分かること:
Variablesが他要素の効果を抑制している?
v0111(Variables無し)がv1110(Variables有り)より高品質
セッション3では、4パターンの3要素組み合わせを検証しました。
| コード | 組み合わせ | 評価 |
|---|---|---|
v1110 |
Variables + Auto Layout + Layer Names | 中 |
v1101 |
Variables + Auto Layout + Annotations | 中 |
v1011 |
Variables + Layer Names + Annotations | 低 |
v0111 |
Auto Layout + Layer Names + Annotations | 高 |
Auto Layout + Layer Names + Annotations(v0111) - 暫定ベスト
v0111は、セッション3時点で最も高い品質でした。
// v0111: Auto Layout + Layer Names + Annotations
<div className="bg-slate-50 min-h-screen">
<header className="bg-slate-50 border-b border-slate-300 sticky top-0 z-10">
<div className="flex items-center justify-between px-6 py-3">
<nav className="flex gap-10 items-center">
<a href="#" className="hover:text-blue-600">Dashboard</a>
<a href="#" className="hover:text-blue-600">Projects</a>
</nav>
</div>
</header>
<aside className="bg-white border-r border-slate-200">
<nav className="flex flex-col gap-2 p-4">
<a href="#" className="bg-blue-100 text-blue-600 px-4 py-2 rounded-lg">
Dashboard
</a>
<a href="#" className="hover:bg-slate-100 px-4 py-2 rounded-lg">
Projects
</a>
</nav>
</aside>
</div>
主な特徴
- セマンティックHTML:
<header>,<nav>,<aside>,<a>を使用 - インタラクティブ要素:
hover:状態、適切な<a>タグ - Flexboxレイアウト:
flex,flex-col,gap - 標準Tailwindクラス:
bg-slate-50,text-blue-600,rounded-lg
標準Tailwindクラスが適用されるとき、されないときの差が分かりませんが、少なくない場合で任意値のクラスが使われてしまうことだけは確かなようです。
Variables + Auto Layout + Layer Names(v1110) - Variablesが無い方が品質が高い
ここで、想定していなかったアウトプットがありました。
v1110が、v0111よりも品質が劣っていたのです。
// v1110: Variables + Auto Layout + Layer Names
<div className="bg-[var(--slate-50,#f8fafc)] flex flex-col">
<div className="bg-[var(--slate-50,#f8fafc)] border-[var(--slate-300,#cbd5e1)]">
<p className="text-[color:var(--slate-950,#020617)]">Dashboard</p>
</div>
</div>
// v0111: Auto Layout + Layer Names + Annotations(= Variables無し)
<header className="bg-slate-50 border-b border-slate-300">
<a href="#" className="text-slate-950">Dashboard</a>
</header>
v1110の問題点
- セマンティックHTMLが生成されない(
<div>,<p>のまま) - CSS変数の冗長な記述が残る
- インタラクティブ要素が欠如
標準Tailwindクラスが適用されないだけでなく、Variablesが他要素の効果を打ち消しているようにすら見えます。
セッション3のまとめ
この時点での暫定結論は以下の通りでした
- 推奨設定:
v0111(Auto Layout + Layer Names + Annotations) - Variablesは使わない方が良い可能性
VariablesはFigma側の作業効率を高める重要な機能ですが、コード生成品質では逆効果となる可能性すら見えてしまいました。
理屈と違いすぎて驚いていますが、ひとまず検証を進めます。
セッション4: 全要素有効(v1111)
このセッションで分かること:
全要素有効のv1111がまさかにv0111より劣る。
セッション4では、全要素を有効にしたv1111を検証しました。
すべての機能を有効にすれば最高品質になるはず、という期待がありました。
しかし結果は、v0111に劣っていました。
// v1111: 全要素有効
<div className="bg-[var(--slate-50,#f8fafc)] flex flex-col">
<div className="bg-[var(--slate-50,#f8fafc)] border-b border-[var(--slate-300,#cbd5e1)]">
<div className="flex items-center justify-between px-6 py-3">
<p className="text-[color:var(--slate-950,#020617)]">Dashboard</p>
</div>
</div>
</div>
// v0111: Variables無し(比較)
<header className="bg-slate-50 border-b border-slate-300">
<div className="flex items-center justify-between px-6 py-3">
<a href="#" className="text-slate-950">Dashboard</a>
</div>
</header>
v1111の問題点
- セマンティックHTML化されない(
<div>,<p>のまま) - CSS変数の冗長な記述
- インタラクティブ要素が欠如(
<a>ではなく<p>) -
data-name属性もない
この結果だけを見ると、先ほど記載した「Variablesが他要素の効果を打ち消している」可能性を本当に考えた方が良いのかとも悩みます。
セッション4時点の結論
この時点での結論は以下の通りでした
推奨設定: v0111(Auto Layout + Layer Names + Annotations)
Variablesは推奨しない
しかし、Figmaのデータ作成でVariablesを使わないのは非効率過ぎます。
実験結果を捏造・隠蔽したい意図はありませんが、Variablesを使って上手くコードが出力されるような設定の仕方を探す方が建設的だと考え、検証の仕方を変更することにしました。
セッション5: 転換点 - プロンプトの詳細化
このセッションで分かること:
プロンプトでVariables変換を明示すれば標準Tailwindクラスに変換される。
ただしセマンティックHTMLには至らず。
検証のきっかけ
よくよく考えると、個人リポジトリでの開発ではVariablesは標準Tailwindクラスにもカスタムの変数にも正しく変換されています。
違いがあるとしたら指示をするプロンプトです。
これまでの検証では、極力Figma MCPの素の挙動が見たいを思いシンプルなプロンプトを使用していました。
そのため、もしかするとプロンプトでVariablesの変換を明示的に指示すれば、問題ない結果を得られるのではと考えました。
詳細プロンプトの内容
以下の詳細プロンプトを用意しました。
Please generate a React TypeScript component with Tailwind CSS from
the Figma page [PAGE_NAME] in [FIGMA_URL].
IMPORTANT: This Figma design uses Variables (design tokens) for colors,
spacing, and typography. Please map these Variables to standard Tailwind
classes whenever possible:
- Color variables (e.g., slate-50, blue-600) → Tailwind color classes (bg-slate-50, text-blue-600)
- Spacing variables → Tailwind spacing scale (p-4, gap-6, etc.)
- Typography variables → Tailwind text utilities (text-sm, font-medium)
Avoid using CSS custom properties like `var(--slate-50)` or arbitrary
values like `bg-[var(--slate-50)]`. Use standard Tailwind classes directly.
Use @figma-mcp-server to access the design.
Generate clean, production-ready code following React best practices.
検証結果
v0111-2(Variables無し + 詳細プロンプト)とv1111-2(全要素 + 詳細プロンプト)を検証しました。
v0111-2は、v0111とほぼ同等の出力をでした。
Variablesがないため、プロンプトの詳細化の影響は限定的だと考えられます。
しかしv1111-2では改善が見られました。
// v1111: シンプルなプロンプト(セッション4)
<div className="bg-[var(--slate-50,#f8fafc)] flex flex-col">
<div className="bg-[var(--slate-50,#f8fafc)] border-[var(--slate-300,#cbd5e1)]">
<p className="text-[color:var(--slate-950,#020617)] text-[length:var(--size-sm,14px)]">
Dashboard
</p>
</div>
</div>
// v1111-2: 詳細プロンプト(セッション5)
<div className="bg-slate-50 flex flex-col">
<div className="bg-slate-50 border-b border-slate-300">
<p className="font-medium text-sm text-slate-950">
Dashboard
</p>
</div>
</div>
Variablesが標準Tailwindクラスとして出力されています。
しかし問題も残りました
- セマンティックHTML化は達成されず(依然として
<div>,<p>のまま) -
data-name属性なし - インタラクティブ要素なし(
v0111-2では<a>,<button>が使用されていた)
改めて方針を立てる
この検証により、プロンプトの詳細化でVariablesは有効化されると分かりました。
しかしv0111-2とv1111-2を比較すると、依然としてv0111-2の方が優れていました。
| 観点 | v0111-2(Variables無し) | v1111-2(Variables有り) |
|---|---|---|
| Tailwind標準クラス | bg-slate-50 |
bg-slate-50 |
| セマンティックHTML |
<header>, <nav>, <a>
|
<div>, <p>
|
| インタラクティブ要素 |
hover:, <button>
|
なし |
| データ駆動アプローチ |
.map() 使用 |
ベタ書き |
プロンプト詳細化でVariablesのCSS変数問題は解決しましたが、他要素の効果(セマンティックHTML化など)は依然として抑制されているようにも見えます。
Claude Codeの自己報告から分かったこと
セッションの履歴を再度眺めていて、v1111-2の生成時にClaude Codeが以下のように報告しているのに気がつきました。
I've converted the Figma-generated code to use standard Tailwind classes instead of CSS variables:
### Color Conversions
- bg-[var(--slate-50,#f8fafc)] → bg-slate-50
- text-[color:var(--slate-950,#020617)] → text-slate-950
### Spacing Conversions
- gap-[var(--size-10,40px)] → gap-10
- px-[var(--size-4,16px)] → px-4
### Typography Conversions
- text-[length:var(--size-sm,14px)] → text-sm
Claude Codeが明示的に「変換を実行した」と記載しています。
であれば、Figma MCPだけで成立しているわけではないので、シンプルな指示ではなく詳細に指示しないと実務的な検証にはならなそうです。
セッション5の結論
この時点での結論は以下の通りでした。
- Figma MCPだけの範囲には限界がある: 半ば当たり前の話であるものの、Figmaデータだけでなくプロンプトの品質も出力を左右する
- Variablesは詳細プロンプトで有効化される: ただし他要素の効果の抑制は残っている?
-
v0111が依然として最適解: セマンティックHTML、インタラクティブ要素、データ駆動の観点で優れている
セッション6: 包括的プロンプトによる解決
このセッションで分かること:
セマンティックHTML化もプロンプトで明示すれば実現。
v0111とv1111がほぼ同等品質になり、全要素有効+包括的プロンプトが最終的な推奨内容。
包括的プロンプトの内容
セマンティックHTML化やインタラクションについても、プロンプトで明示的に指示すれば問題ないのではないかと思い、その方針で進めます。
以下のプロンプトを用意しました。
Please generate a React TypeScript component with Tailwind CSS from
the Figma page [PAGE_NAME] in [FIGMA_URL].
IMPORTANT Requirements:
1. Variables Mapping:
- Map Figma Variables to standard Tailwind classes
- Color variables → bg-slate-50, text-blue-600
- Spacing variables → p-4, gap-6
- Typography variables → text-sm, font-medium
- Avoid CSS variables like var(--slate-50)
2. Semantic HTML:
- Use semantic elements: <header>, <nav>, <aside>, <main>, <section>
- Use <a> for links, <button> for actions
- Avoid generic <div> and <p> where semantic alternatives exist
3. Interactive Elements:
- Add hover states with transitions (hover:text-blue-600 transition-colors)
- Use proper interactive elements
- Include accessible attributes (aria-label, alt)
4. Code Quality:
- Define TypeScript interfaces for data structures
- Use data-driven approach with .map() for repeated elements
- Next.js Image/Link components where applicable
- Clean, production-ready code
Use @figma-mcp-server to access the design.
検証結果
v0111-3(Variables無し + 包括的)とv1111-3(全要素 + 包括的)を検証し、両者がほぼ同等の出力となりました。
// v0111-3: Variables無し + 包括的プロンプト
<header className="bg-slate-50 border-b border-slate-300 sticky top-0">
<nav className="flex gap-10 items-center">
<Link href="#" className="hover:text-blue-600 transition-colors">
Dashboard
</Link>
</nav>
</header>
// v1111-3: 全要素 + 包括的プロンプト
<header className="bg-slate-50 border-b border-slate-300 sticky top-0">
<nav className="flex gap-10 items-center">
<a href="#" className="hover:text-blue-600 transition-colors">
Dashboard
</a>
</nav>
</header>
両者の比較
| 観点 | v0111-3 | v1111-3 |
|---|---|---|
| セマンティックHTML | 良好 | 完璧 |
| Tailwind標準クラス | 良好 | 完璧 |
| インタラクション |
hover:, transition-colors
|
hover:, transition-colors, hover:ring-2
|
| データ駆動 |
.map() 使用 |
.map() 使用 |
| TypeScript型定義 | あり | あり(5つのinterface) |
v1111-3がやや優位な点
- TypeScript型定義が充実(5つのinterface)
-
transition-*クラス - hover効果(
hover:ring-2) - Enterキーのハンドラー
v0111-3がやや優位な点
- Next.js
<Link>component使用 - データ駆動の若干の充実度
総合評価としてはほぼ互角です。
ただ、先ほども記載した通りFigmaデータ作成時にVariablesを使わないわけにはいかないので、実務的にはv1111-3(全要素有効 + 包括的プロンプト)を推奨します。
主な結論
セッション6の検証により、以下のような結論に至りました。
- 包括的なプロンプトで問題は解消:
v0111-3とv1111-3は実質的に同等の品質 - Variablesは実務で推奨可能: Figma側の効率化メリットを享受しつつ、コード品質も担保できる
プロンプトで明示的に指示することで、以下のすべてを達成できました
- Variables → 標準Tailwindクラス変換
- セマンティックHTML化
- インタラクティブ要素の生成
- TypeScriptの型定義生成
- データ駆動アプローチ
途中までは「Variablesは推奨しない」という結論になりそうでしたが、そうならない道を見つけられてホッとしています。
先ほども書きましたが実験結果を歪めたいという意図ではなく、Figmaデータを作成するときに値をベタで書くのは非効率過ぎるから、という理由です。
最終結論: 推奨設定とベストプラクティス
推奨Figmaデータ
当たり前と言えるかもしれませんが、可能であればすべての機能を活用する方が良いです。
その中でも役割や優先度は以下のようになっています。
- Variables: Figmaデータ作成時の効率化、デザイントークンの一貫性
- Auto Layout: 最重要、これがないと絶対配置から脱却できない
- Layer Names: 可読性、デバッグ性の向上(優先度はやや低め)
- Annotations: セマンティック化、型定義の改善(優先度は低め)
推奨プロンプト: 包括的な指示
包括的なプロンプトのテンプレート(再掲)
Please generate a React TypeScript component with Tailwind CSS from
the Figma page [PAGE_NAME] in [FIGMA_URL].
IMPORTANT Requirements:
1. Variables Mapping:
- Map Figma Variables to standard Tailwind classes
- Color variables → bg-slate-50, text-blue-600
- Spacing variables → p-4, gap-6
- Typography variables → text-sm, font-medium
- Avoid CSS variables like var(--slate-50)
2. Semantic HTML:
- Use semantic elements: <header>, <nav>, <aside>, <main>, <section>
- Use <a> for links, <button> for actions
- Avoid generic <div> and <p> where semantic alternatives exist
3. Interactive Elements:
- Add hover states with transitions (hover:text-blue-600 transition-colors)
- Use proper interactive elements
- Include accessible attributes (aria-label, alt)
4. Code Quality:
- Define TypeScript interfaces for data structures
- Use data-driven approach with .map() for repeated elements
- Next.js Image/Link components where applicable
- Clean, production-ready code
Use @figma-mcp-server to access the design.
各セクションの意図
- Variables Mapping: Figma Variablesを標準Tailwindクラスに変換するよう明示
- Semantic HTML:
<div>や<p>ばかりではなくセマンティックな要素を使うよう指示 - Interactive Elements: hoverステートやtransitionを含めるよう指示
- Code Quality: TypeScript型定義やデータ駆動アプローチを促進
各要素の役割まとめ
| 要素 | 役割 | プロンプトなしでの効果 | 包括的プロンプト使用時 |
|---|---|---|---|
| Variables | デザイントークンの一貫性 | CSS変数のまま | 標準クラスに変換 |
| Auto Layout | Flexboxレイアウト | 絶対配置から脱却 | さらに改善 |
| Layer Names | デバッグ性 |
data-name属性 |
同左 |
| Annotations | セマンティック化・型定義 | 限定的 | 機能 |
設定パターンの最終比較
| パターン | Variables | Auto Layout | Layer Names | Annotations | プロンプト | 総合評価 |
|---|---|---|---|---|---|---|
v0000 |
シンプル | 低 | ||||
v0100 |
✔︎ | シンプル | 中 | |||
v0110 |
✔︎ | ✔︎ | シンプル | やや高 | ||
v0111 |
✔︎ | ✔︎ | ✔︎ | シンプル | やや高 | |
v1111 |
✔︎ | ✔︎ | ✔︎ | ✔︎ | シンプル | 中 |
v1111-2 |
✔︎ | ✔︎ | ✔︎ | ✔︎ | 詳細 | 高 |
v1111-3 |
✔︎ | ✔︎ | ✔︎ | ✔︎ | 包括的 | 高 |
実務への応用
組織での活用
組織でFigma MCPを活用する際は、以下を推奨します。
- プロンプトテンプレートの標準化: 包括的プロンプトを基準に、プロジェクト固有の要件を追加
- デザインシステムとの統合: Figma Variablesとコードベースのデザイントークンを対応付け
- ドキュメント化: Layer Namesの命名規則、Annotationsの使い方などを文書化
ケース別の推奨設定
新規プロジェクト
- Figmaデータ: 全要素有効
- プロンプト: 包括的プロンプト
- 理由: 最初から高品質なコード生成が可能
既存プロジェクト
- Figmaデータ: 最低限Auto Layoutは必須、他は段階的に導入
- プロンプト: 包括的プロンプト、他ツールを含めたコンテキストウィンドウの量次第では詳細〜シンプルなプロンプトでも可
- 理由: Auto Layoutがないと絶対配置のまま、ただしAuto Layoutだけならシンプルなプロンプトでも問題なく実装される
デザインシステム・コンポーネントライブラリ構築中
- Figmaデータ: 特にVariablesを重視
- プロンプト: 包括的プロンプト
- 理由: デザイントークンの一貫性が重要
まとめ
20パターンの検証を通じて、Figma MCPを活かすための知見が得られました。
- 適切なFigmaデータ作成: Variables, Auto Layout, Layer Names, AnnotationsとAIが参照できそうなものはできるだけ使う
- 包括的なプロンプト使用: 明示的で詳細な指示
- 継続的な改善: プロンプトとFigmaデータの最適化
当初は「Figmaデータさえしっかりしていれば良いコードが生成される」と考えていました。
しかし実際には、Figmaデータとプロンプトは相互に補完する関係にあり、どちらか一方だけでは不十分でした。
両方を最適化することで、ようやく高品質なコード生成が実現するようです。
この調査が、Figma MCPを活用する皆さんの参考になれば幸いです。

