Figma MCPとCursorでデザインする：実装とデザインの往復を短くする

デザインから実装までの往復は、意外と時間がかかります。Figmaで見た見た目を口頭やスクリーンショットで伝え、Cursorでコードを書き、差分を見てまたFigmaへ戻る。このやり取りの途中で、余白・色・コンポーネントの意図がすり替わることは少なくありません。

Figma MCPをCursorへつなぐと、エージェントはスクリーンショットだけでなく、コンポーネント、変数、レイアウトなどの構造化されたデザイン情報を参照できます。本記事では、2026年8月時点の公式情報をもとに、Figma MCPとCursorを使ったデザイン〜実装の進め方と、人が見るべき境界を整理します。

Figma MCPとは何か

MCP（Model Context Protocol）は、AIエージェントが外部ツールやデータへ接続するための仕組みです。Figma MCPサーバーは、Figmaのファイルやツールへの構造化されたアクセスをCursorなどのMCP対応クライアントへ提供します。

公式ガイドによると、Figma MCPでは次のような用途が想定されています。

選択したフレームやコンポーネントのデザインコンテキストを読む
変数、レイアウト、FigJam、Makeのリソースを参照する
デザインからコードを生成する
Code Connectを使い、実際のコードコンポーネントとの対応を保つ
Cursor側からFigmaキャンバスへ書き戻し、ネイティブなFigmaコンテンツを作成・更新する
動いているWeb UIを、編集可能なFigmaレイヤーとして送る

つまり、「画像を見て雰囲気を再現する」のではなく、デザインの構造と意図をエージェントの入力にすることがポイントです。

Cursorへのつなぎ方

Figmaは、remote MCPとdesktop MCPの2種類を提供しています。機能が広く、通常の利用で推奨されるのはremote MCPです。desktop版は、組織・Enterprise向けの特定用途向けです。

Cursorでremote MCPを使う標準的な手順は次のとおりです。

Cursorのチャットで /add-plugin figma を実行し、Figmaプラグインを追加する
Cursor Settings → Tools & MCP を開く
Installed MCP Servers から Figma を Connect し、認証を完了する

認証後、CursorからFigmaファイルや選択フレームを参照できるようになります。利用時は、対象のFigmaリンクや選択範囲をチャットへ渡し、「このフレームを既存のコンポーネント設計に合わせて実装して」のように依頼します。

なお、フルに使うにはDev ModeへアクセスできるFigmaのseatが必要です。seatによっては月次の利用制限があるため、チーム導入前に権限と上限を確認してください。

Cursorから使う4つの実践パターン

Figma MCPには、単一の「Figmaを使う」操作だけがあるわけではありません。目的に応じて、Figmaからコードを作る、コードからFigmaを作る、コンポーネントの対応関係を登録する、既存のFigmaを編集するという使い分けがあります。

CursorのFigmaプラグインには、こうした作業を支援するAgent Skillsが含まれます。意図だけを文章で伝えても利用できますが、作業方向を明確にしたいときは、次のスラッシュコマンドから始めると分かりやすくなります。

Figmaのフレームを実装する：/figma-design-to-code
ローカルのコードをFigma画面へ反映する：/figma-generate-design
Figmaコンポーネントとコードを対応付ける：/figma-code-connect
Figmaの既存画面を直接編集する：/figma-use
新しいFigmaファイルを作成する：/figma-create-new-file

/figma-code-to-design というコマンド名ではなく、コードからFigmaへ反映する用途は /figma-generate-design です。

1. Figmaの画面をコードにする（Figma → Code）

Figmaのフレームを、既存プロジェクトのコンポーネントとして実装したいときの流れです。Cursorのチャットで、まず次を実行します。

/figma-design-to-code

続けて、対象フレームのnode-idを含むURL、実装先、守るべき既存ルールを渡します。

このFigmaフレームをSvelte 5で実装してください。
https://www.figma.com/design/FILE_KEY/Project?node-id=123-456

- 実装先: src/lib/components/AnalyticsCard.svelte
- 既存のButton、Card、CSS変数を優先して再利用する
- モバイル幅でも崩れないようにする
- 実装後に型チェックを実行する

このワークフローでは、まずFigmaからデザインコンテキストを読みます。取得される情報は生成用コードの雛形ではありますが、そのまま貼り付けるものではありません。プロジェクトのフレームワーク、コンポーネント、トークン、スタイル規約へ合わせて実装する必要があります。

特に重要なのは、Figma URLにnode-idを含めることです。ファイル全体のURLだけでは、どの画面・フレームを実装するか曖昧になります。Figmaで対象フレームを選択し、リンクをコピーして渡すとよいでしょう。

2. 動いている画面をFigmaへ作る（Code → Figma）

ユーザーが言う「code-to-design」に近いのはこちらです。Cursorでは、まず次を実行します。

/figma-generate-design

既存のWeb画面やコンポーネントを、Figma上の編集可能な画面へ変換・更新します。

対象となるFigmaファイルを先に用意し、コードの場所と反映先を明示します。

src/routes/pricing/+page.svelte の画面を、
次のFigmaファイルの「Pricing」ページへ反映してください。
https://www.figma.com/design/FILE_KEY/Product-UI

既存のFigmaコンポーネント、変数、テキストスタイルを優先して使い、
スクリーンショットを単に貼り付けるのではなく、編集可能なレイヤーとして作成してください。

反映先のFigmaファイルがまだない場合は、先に新規ファイルを作ります。

/figma-create-new-file design Product UI

作成されたファイルURLを、続く/figma-generate-designの依頼文へ貼り付けます。

Web画面をFigmaへ反映する場合は、二つの成果物を組み合わせると精度が上がります。

実行中のWeb画面をキャプチャし、実際の余白・画像・表示状態を視覚的な参照にする
Figmaのデザインシステムからコンポーネント、変数、スタイルを再利用し、編集可能な画面を組み立てる

前者だけでは画像化された画面になり、後者だけでは既存UIとの見た目がずれることがあります。既存のFigmaコンポーネントを使って編集可能な構造を作り、キャプチャを見比べて調整するのが実務的です。

3. Code Connectで、Figmaと実装の対応を登録する

Figmaのボタンやカードと、コード上のButton.svelteやCard.svelteを結び付けたいときは、Code Connectを使います。Cursorのチャットで次を実行します。

/figma-code-connect

このリポジトリの src/lib/components/Button.svelte を、
FigmaのButtonコンポーネントとCode Connectで対応付けたいです。
既存のpropsとvariantを確認して、必要なCode Connectファイルを提案・作成してください。
FigmaコンポーネントURL: https://www.figma.com/design/FILE_KEY/Design-System?node-id=80-120

Code Connectがあると、デザインから実装するときに、似た見た目の新規コンポーネントを生成する代わりに、対応する既存コンポーネントを使う判断がしやすくなります。デザインシステムを運用するチームでは、ボタン、入力欄、カード、見出しなどの共通部品から対応付けるのがよいでしょう。

4. Figmaの画面を直接編集する

既存のFigma画面へセクションを追加したり、コンポーネントのバリアントを差し替えたりする用途では、Cursorのチャットで次を実行します。

/figma-use

編集対象のファイルURLと、何を変更してよいかを明確にします。

このFigmaファイルのDashboard画面に、空状態のセクションを追加してください。
https://www.figma.com/design/FILE_KEY/Product-UI?node-id=200-300

- 既存のEmpty Stateコンポーネントを使う
- 新しい色や余白の値は作らず、既存の変数を使う
- 変更前後を確認できるよう、対象ノードを報告する

書き込み操作では、誤ったページやフレームを変更しないよう、最初は小さな対象から始めます。既存のコンポーネント、変数、テキストスタイルを確認してから編集し、変更後はスクリーンショットで確認する流れが安全です。

何が変わるのか

スクショではなく、構造を渡せる

従来の「スクショを貼って再現して」では、余白の意図、トークン、再利用コンポーネントの境界が曖昧になりがちです。Figma MCPでは、エージェントがレイアウトや変数などの構造情報を参照できるため、「見た目が近いコード」ではなく、「デザインシステムに沿った実装案」へ寄せやすくなります。

実装からデザインへの戻りも短くなる

remote MCPでは、コード側の変更をFigmaへ戻す流れも想定されています。たとえば、実装で調整したUIを編集可能なレイヤーとしてキャンバスへ送る、ネイティブなFigma要素を更新する、といった往復が可能です。デザインと実装が一方通行ではなく、同じ文脈で会話できるようになります。

Code Connectで「本物のコンポーネント」に寄せられる

デザイン上のカードと、コード上の Card.svelte が別物だと、AIが毎回新しい見た目を生成しがちです。Code Connectで対応関係を持たせておくと、エージェントは既存コンポーネントを優先しやすくなります。チームにデザインシステムがある場合、ここが品質の差になります。

それでも人が決めること

Figma MCPは、デザインと実装の往復を短くしますが、意思決定を代行するわけではありません。少なくとも次は人が見る必要があります。

コンポーネント境界：新規作成か、既存コンポーネントの拡張か
命名と責務：一時的な見た目の再現ではなく、再利用できる単位になっているか
アクセシビリティ：コントラスト、フォーカス、キーボード操作、代替テキスト
レスポンシブ：デスクトップだけの見た目を固定していないか
状態：hover、disabled、error、空状態、読み込み中
権限と機密：公開できないデザイン、顧客データ、未発表のプロダクト情報をプロンプトへ含めないこと

また、エージェントが生成したコードは、通常のPull Requestと同じ品質ゲートを通します。見た目が近いだけでは、既存のルーティング、状態管理、テスト、デザイン・トークンとの整合を保証できません。

実務でうまくいく進め方

おすすめは、最初から「ページ全体をAIに任せる」のではなく、小さな単位で往復することです。

対象を1画面、または1コンポーネントに絞る
Figmaで該当フレームを選び、リンクまたは選択範囲をCursorへ渡す
「既存のデザイン・トークンとコンポーネントを優先して実装して」と指示する
生成差分をレビューし、余白・状態・アクセシビリティを確認する
必要な修正だけをFigma側へ戻し、デザインの正本を更新する

このとき、プロンプトには「何を作るか」だけでなく、「何を守るか」を書きます。たとえば、色はCSS変数を使う、カードは既存コンポーネントを拡張する、新規依存を増やさない、モバイル幅でも破綻しない、といった制約です。

チーム導入で先に決めておくこと

個人で試す分には接続だけで始められますが、チームで使うなら次を決めておくと安全です。

誰がFigmaの正本を持つか：デザインファイルの編集権限とレビュー担当
Code Connectの対象範囲：ボタン、フォーム、カードなど、まず接続する共通部品
AIへ渡してよい情報：未公開デザイン、顧客名・実データ、社外秘の数値を含めない
レビュー観点：見た目一致だけでなく、再利用性、a11y、既存実装との整合
seatと利用上限：Dev Modeアクセスと、MCP利用の制限

Figma MCPは便利なほど、権限の広いアカウントや、機密デザインへのアクセス経路にもなります。GitHubのアクセス権管理と同様に、最小権限と監査の意識が必要です。

まとめ

Figma MCPとCursorの組み合わせは、「AIにデザインを見せてコードを書かせる道具」というより、デザインの構造を開発エージェントへ渡すための接続点です。スクリーンショット中心のやり取りと比べ、コンポーネントや変数の意図を保ったまま実装へ移しやすくなります。

一方で、品質は依然としてチームのデザインシステム、レビュー、権限管理に依存します。まずは1コンポーネントの往復から試し、Code Connectとレビュー観点を整えたうえで、画面単位へ広げるとよいでしょう。