はじめに
近年、プロダクト開発の現場では「Design to Code」という概念が大きな注目を集めています。
これは、デザインツールで作成されたUIデザインを直接コードに変換する技術のことで、開発効率の大幅な向上が期待されています。
この流れの中で、Figma社は、Dev Mode（開発者向けの表示モード）やCode Connect（コードとデザインの同期機能）といった機能をリリースしてきました。
このような背景の中、つい最近では「Figma MCP」が話題となりました。
私たちのチームでは、このFigma MCPとAI搭載コードエディタ「Cursor」を組み合わせることで、実際のプロダクト開発に挑戦してみました！
本記事では、その導入過程で得られた知見、そして実際の運用における工夫について紹介します。
🤖 Figma MCPとは
Figma MCPについては、こちらの記事が非常にわかりやすくまとめられているため、説明を割愛します。
🎯 チームでの導入背景
今回Figma MCPの連携に取り組んだ背景には、AIの力を借りることで、
- 📊 UIコンポーネント実装の工数削減
- 🧠 少人数のチームでもUIの開発速度を向上
が期待できるのではないかと考えました。
🔧 実装ステップと運用上の工夫
Figma MCPとCursorを連携させる際、最初に直面したのはチーム内での設定共有の問題です。
APIキーの共有問題
Figma MCPを使用するためには、各開発者がFigmaのAPIキーを取得し、.cursor/mcp.jsonファイルに設定する必要があります。
しかし、このAPIキーは個人単位で発行されるため、リポジトリにそのまま含めることはできません。
また、mcp.jsonファイルは環境変数の読み込みに対応していないという制約もありました。
これらの課題に対応するため、以下のように対応しています。
-
mcp.sample.jsonを作成し、リポジトリに含める -
.gitignoreに.cursor/mcp.jsonを追加 - チームメンバーには各自の環境で
mcp.sample.jsonをコピーしてmcp.jsonを作成し、自分のAPIキーを設定するよう依頼
// mcp.sample.json
{
"mcpServers": {
"figma-developer-mcp": {
"command": "npx",
"args": ["-y", "figma-developer-mcp", "--stdio"],
"env": {
"FIGMA_API_KEY": "{個人のAPIキーを記載}"
}
}
}
}
この方法は簡易的ですが、少人数チームであれば特に問題はないので、現状この方法を採用しています。
ただ、個人単位のAPIキーの設定や各個人に作業を委ねる点において、あまりスマートではないと感じています...
もし、よりスマートな方法で運用されている方がいらっしゃいましたら、ぜひコメントで教えていただけると嬉しいです！
🎉 成功事例と課題点
ここからは、「実際、プロダクト開発に取り入れてどうなの？」「自分で開発したほうが早いんじゃない？」といった疑問に対する知見を共有したいと思います。
成功した点
Figma MCPとCursorを組み合わせることで、以下のような成果を得ることができました。
- ⚡ UI実装の高速化: 単純なコンポーネントであれば、数分で実装が完了
- 🎨 視覚的な正確さ: 生成されたUIは、デザインとの視覚的な一致度が高い
特に、UIの再現度については70〜80%の精度で実装できており、修正作業を含めても従来の手作業に比べて大幅な時間短縮が実現できました。
課題点
一方で、AIに任せて実装してリリースできるかと言えば、そうではありません。実際は以下のような課題がありました。
- 📋 コンポーネント構造の問題: 生成されたコードは1つの巨大なコンポーネントになりがち
- 📏 コーディング規約との不一致: チームのコーディングルールに従わないコードが生成される
- 🧩 デザインシステムの未活用: 既存のデザインシステムのコンポーネントが活用されず、独自実装されてしまう
特に最後の点は、別リポジトリでデザインシステムを管理している場合、顕著な問題として挙げられます。
AIが独自にコンポーネントを実装してしまうため、デザインシステムとの一貫性が失われてしまいます。
また、フロントエンド開発においては、単純なUIの実装以外にも考えなければいけないことがありますよね。
- サーバーコンポーネントとクライアントコンポーネントの適切な使い分け
- コンポーネント間での状態管理の設計
- パフォーマンスを考慮したコンポーネントの分割
これらの設計判断は、プロジェクトの要件や制約に応じて適切に行う必要があり、一発で完璧な生成が行われるかと言われると難しいところです。
💡 精度向上のための工夫
先ほど挙げた課題に対して、いくつか効果的だった工夫をご紹介したいと思います！
cursor_rulesの活用
Cursorにはcursor_rulesという機能があり、AIに特定のコーディング規約やプロジェクト構造を理解させることができます。
Figma MCPに限った話ではなく、AIでの開発においてcursor_rulesは大きな役割を担っています。
cursor_rulesについては、既に記事が上がっているので、気になる方は調べてみてください！
チームでは以下のようなルールを定義しています。（一部抜粋）
- 📂 プロジェクトの構造とフォルダ構成
- 📏 コーディング規約とスタイルガイド
- 🧩 コンポーネント分割の方針
これにより、生成するコードの品質を大幅に向上させることができました。
# cursor_rules.mdc（抜粋）
## コンポーネント設計
- コンポーネントは function コンポーネントで定義する
- 可能な限り React Server Components を利用
- 不要な 'use client' 指定を避ける
- 適切な ErrorBoundary を導入
## デザイン
- プロジェクト独自の共通コンポーネントは /src/app/components/ 配下を利用
既存実装の参照
Cursorでは、ファイルやフォルダを参照しながら会話できる機能があります。
これを活用し、既存の画面実装を参考にするよう指示することで、実装方法の統一性を高めることができました。
管理画面の開発においては、
- 📋 一覧表示、詳細表示、編集フォームなど、画面の基本構成が似通っている
- 🔄 同じようなデータフローやエラーハンドリングが必要
- 🎨 デザインパターンが統一されている
ため、以下のような指示をCursorに与えることで高精度な実装が可能でした。
「このFigmaデザインを実装する際に、
src/app/admin/users配下のディレクトリ構成とコンポーネント分割を参考にしてください。特に、一覧表示のテーブルコンポーネントとページネーションの実装方法を踏襲したいです。」
このように、既存の管理画面の実装を参照することで
- 💡 コンポーネントの分割粒度が適切になる
- 🔗 データフェッチやエラーハンドリングのパターンが統一される
- 🎯 プロジェクト固有の要件やルールに沿った実装ができる
結果として、生成されたコードのレビュー指摘も大幅に減少しました。
Cursorの細かいTipsに関しては、別で記事が上がっていますので、ぜひ御覧ください！
なるべくノードの単位を小さくする
Figmaから取得するノードの単位も重要な要素でした。
大きすぎるフレームを選択すると、精度が下がる傾向にありました...
- 🧩 機能単位で小さなコンポーネントに分割されたフレームを選択
- 🔄 複雑な画面は複数回に分けて生成
- 🔍 共通コンポーネントは個別に生成してから組み合わせる
例えば以下のページを実装する場合、青枠単位で参照すると精度が高いアウトプットを得られます。
📊 実際の効果
実際使ってみてどうなの？というところも気になりますよね！
正確な計測は行っていないですが、体感で約40%ほど作業時間が短縮されたと思います。
しかし、慣れるまでは自分で実装したほうが早いな...と感じることもありました。
その誘惑に負けず、プロンプトの工夫やcursor_rulesの工夫によって、AIベースの実装を取り入れていくことが重要かなと思います！
🤔 残された課題
- 🧩 デザインシステムとの連携をもっと上手くしたい！
現状、デザインシステムのコンポーネントを理解させることに、改善の余地があります。
既に一度実装されたことのある画面やコンポーネントについては、同様の実装を提案してくれますが、新しい画面でデザインシステムのコンポーネントが使われている場合、デザインシステムのコンポーネントを提案してくれないという課題が残っています...
ワークスペースに別リポジトリのフォルダを入れて参照する方法もありますが、なるべくシンプルな運用を見つけたいところです。
もし良いアイデアや実践例をご存知の方がいらっしゃいましたら、ぜひコメントで教えてください！
🎬 まとめ
Figma MCPとCursorの連携は、UI実装やフロントエンドエンジニアの役割に大きな影響を与えると思います。
- 📚 AIにコンテキストを与える:
cursor_rulesなどを活用して、AIにプロジェクトの背景や方針を理解させることが重要 - 🎨 デザインの精緻化: AIがうまく理解できるよう、Figmaのデザインデータも構造化されている必要がある
- 👨💻 エンジニアの役割変化: フロントエンドエンジニアは実装の詳細よりも、アーキテクチャやユーザー体験の設計に注力できるようになる
これからのフロントエンド開発では、AIツールをうまく活用しながら、より高い価値を生み出す領域にフォーカスしていくことが重要だと感じました！
📚 参考資料
Discussion