Figma MCP Server×Claude Codeで、デザイナーと開発者を双方向につなぐ

2026年03月24日 17時00分更新

文● 新屋拓海／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Figma MCP Server × Claude Code：画面とFigmaデザインを双方向に連携する」を再編集したものです。

※本記事の文章は、一部生成AIを用いて作成しています。

はじめに

以前の記事では、Claude Codeを使ってHTML/CSSのモック画面を作る方法を紹介しました。

https://tech-blog.cloud-config.jp/2026-03-02-make-mockScreen-with-ClaudeCode

ただ、作った画面をデザイナーにどのような形で共有するか、Figma上の修正があった場合にどのようにコードに取り込むかなど、以下の3つの課題が残っていました。

・デザイナーがモック画面を確認するのに、URLやスクリーンショットの共有が必要になる
・Figma上にモック画面がないため、デザインの修正提案を反映する際に手間がかかる
・「最新の画面」がどれなのか、開発者とデザイナーの間で分かりにくくなってしまう

この記事ではFigma MCP Serverを使って、コードとFigmaデザインを双方向に連携するワークフローを試してみたので紹介します。

対象読者

・Claude CodeやAIコーディングツールを使ってモック画面を作成している方
・Figma MCP Serverに興味がある方

この記事で解説しないこと

・Claude Code自体の導入方法やセットアップ
・Figmaの基本的な操作方法
・MCPの仕組みの詳細な技術解説

試したツール・ワークフロー

この記事では、以下2つのFigma MCPサーバーのツールを使用しました。

方向	ツール	役割
コード → Figma	generate_figma_design	ブラウザで描画した画面をキャプチャしてFigmaに取り込む
Figma → コード	get_design_context	Figmaのデザインから参照コード・スクリーンショット・メタデータを取得する

Figma MCP Serverは、Claude CodeのようなAIエージェントからFigmaのデザインデータを読み書きできるMCPサーバーで、上記の他に読み取り系や作成系、Code Connect系など、合わせて13のツールを提供しています。

※generate_figma_design ツールはリモートMCPサーバーでのみ利用可能です。デスクトップMCPサーバーを使用している場合は利用できないため、事前に接続方式を確認しておくことをおすすめします。

参考：Tools and prompts | Developer Docs

作業のワークフローとしては、以下のものになります。

開発者がモック画面を作成
　　↓ generate_figma_design（キャプチャ → Figmaに取り込み） 
デザイナーがFigma上で確認・修正
　　↓ get_design_context（参照コード・スクリーンショットを取得） 
開発者がReactプロジェクトに反映

今回の技術スタック

実践に入る前に、今回使用した技術スタックを紹介します。

実践（1）ではHTML/CSS、実践（2）では以下の構成を使用しています。

カテゴリ	技術
フレームワーク	React
言語	TypeScript
スタイリング	Tailwind CSS
ビルドツール	Vite
パッケージマネージャー	pnpm
デザインツール	Figma
MCP連携	Figma MCP Server
AIコーディング	Claude Code

get_design_context が返す参照コードはReact + Tailwind CSS形式のため、プロジェクトもこの構成にしておくと参照コードをほぼそのまま活用できます。

HTML/CSSプロジェクトの場合は、JSX → HTMLの変換とTailwind CSS → 素のCSSへの書き換えが追加で必要になります。

実践（1）：コード → Figma（generate_figma_design）

ここからは実際の手順を紹介します。

まず、Claude Codeで、HTML/CSSで作成したタスク管理ダッシュボードの画面をFigmaに書き戻してみます。

流れとしては「開発サーバー起動 → API呼び出し → キャプチャ実行 → 結果確認」の4ステップです。

1. 開発サーバーを起動する

generate_figma_design ツールはブラウザの描画結果をキャプチャするため、あらかじめローカルで画面を配信するHTTPサーバーを起動します。

2. generate_figma_design を呼び出す

Claude Codeから generate_figma_design ツールを呼び出します。主なパラメーターは以下の3つです。

パラメーター	値（例）	説明
outputMode	existingFile	既存のFigmaファイルに反映する
fileKey	dummy-file-key	書き戻し先のFigmaファイルキー
prompt	画面の説明	どのような画面をキャプチャするかの指示

fileKey はFigmaファイルのURLから取得します。

outputMode は existingFile（既存ファイルに反映）と newFile（新規ファイル作成）の2種類から選べます。

呼び出すと、以下の3つが返ってきます。

・captureId：キャプチャ処理の識別子
・captureUrl：ブラウザで読み込むためのURL
・captureScript：index.html に埋め込むJavaScriptコード

3. キャプチャを実行する

返ってきたcaptureScriptを一時的にコードに追加します。

その状態でcaptureUrlをブラウザで開くと、Figma側が描画結果を自動的に取り込んでくれます。

今回はHTMLファイルなので、index.html の <head> 内にscriptを埋め込みます。

<head>
  <!-- 既存のhead要素 --> 
  <script type="module">
   /* generate_figma_designが返却したキャプチャスクリプト */ 
  </script> 
</head>

キャプチャが完了したら、埋め込んだスクリプトを削除して開発サーバーを停止します。

コードをGitで管理している場合、削除し忘れるとキャプチャスクリプトがコミットに含まれる可能性があるので、注意してください。

4. 結果を確認する

Figmaファイルを開くと、ダッシュボード画面がデザインとして入っています。スクリーンショットではなく、Figma上で編集可能なデザインデータとして入っているため、デザイナーはこのままFigma上でレビューや修正ができます。

ブラウザの描画結果をそのままキャプチャするため、CSSのグラデーションやフォントのレンダリングが忠実に再現されます。Tailwind CSSで指定した色も、Figma上で正しく再現されていたのが印象的でした。

一方、以下のようなずれもありました。

・円グラフ（ドーナツチャート）の形状が崩れていた
・一部のカード間の余白やカラム幅がフロントエンドの画面表示と異なっていた

ずれが確認できたのはこの2箇所で、テキスト・色・ボタンなどの基本要素は正確に再現できていました。

見た目の微調整であればFigma側の修正は軽微ですが、オートレイアウトの再設定やFigmaコンポーネント化まで行う場合は追加の手作業が必要になります。

実践（2）：Figma → Reactコード（get_design_context）

次に、Figmaに取り込んだデザインをデザイナーが修正したと仮定して、その修正内容をReactプロジェクトに反映してみます。

このレイアウトが崩れている箇所をFigma側で修正したフレームを使用しました。

流れは「デザインコンテキスト取得 → 参照コードの適用」の2ステップです。

1. get_design_context でデザインコンテキストを取得する

Claude Codeから get_design_context を呼び出します。
fileKey と nodeId を渡すと（取得方法は実践（1）末尾の補足を参照）、以下の情報が返ってきます。

・参照コード：React + Tailwind CSS形式の単一コンポーネント（今回は約500行）
・スクリーンショット：ノードの見た目を示す画像
・アセットURL：アイコン画像のダウンロードURL（7日間有効）

Figmaファイル側でCode Connectやアノテーションが設定されている場合は、コードベースのコンポーネントとの対応付け情報やデザイナーの注釈も取得できます。

2. 参照コードをReactプロジェクトに適用する

返ってきた参照コード（約500行の単一コンポーネント）を9ファイルに分割し、プロジェクトの構成に合わせて修正しました。

具体的な修正項目は以下です。

項目	参照コード	適用後
コンポーネント構成	約500行の単一コンポーネント	9ファイルに分割（Sidebar, Header, StatCard等）
アイコン	Figma APIのアセットURL	lucide-reactコンポーネントに差し替え
Figma固有の属性・クラス	data-node-id、data-name、冗長なCSSクラス	削除
レイアウト	w-[259px] 等のピクセル固定値	flexレイアウトと相対サイズに変更

修正後は types/（型定義）、data/（モックデータ）、components/（Dashboard, Sidebar, Header, StatCard等の7コンポーネント）の構成に整理しました。

手動でFigmaの画面から値を読み取っていた頃と比べ、UIデータをMCP経由で直接取得できるため、正確に反映することができました。

一方で、参照コードをそのまま使えるわけではなく、プロジェクトに合わせた修正が必要でした。主な修正箇所と体感の手間は以下のとおりです。

修正項目	規模感	体感の手間
コンポーネント分割	1ファイル → 9ファイル	中（分割の設計判断が必要）
アイコンの差し替え	20か所	やや大（スクリーンショットと照合しながら1つずつ対応）
Figma固有の属性・冗長クラスの削除	ほぼ全要素	小（機械的に削除できる）
固定ピクセル値 → flexレイアウト	複数個所	中（レイアウト方針の判断が必要）

最も手間がかかったのは、Figmaのレイヤー構造がそのまま反映された冗長なコードの整理でした。1つのテキスト要素に3〜4段のdivがネストされていたり、不要なCSSクラスが含まれていたりするため、そのままコードを反映するのではなく、読み解いて書き直す姿勢が必要です。

実装したコードをFigmaに書き戻してみる

最後に、実装したコードを修正し、Figma側に反映する手順を試してみました。

具体的には、get_design_context で取得したデザインをReactに反映した後、棒グラフの土曜日のバーだけエメラルドグリーンに変更し、その修正結果を generate_figma_design でFigmaに書き戻しました。

結果がこちらです。

コードの変更結果がそのままFigma上のデザインに反映されるため、スクリーンショットを送って「ここの色を変えました」と伝えるよりも、コミュニケーションコストは低いと感じました。

一方で、Figma側に反映した際に、オートレイアウトが外れていたり、Figma上のコンポーネントが適用されていなかったりしたので、ここは対策が必要だと考えています。

良かった点と課題・対策案

今回Figma MCPサーバーを使ってみて、良かった点と課題・対策案をまとめました。

良かった点

・開発者のコード成果物が、スクリーンショットではなくFigma上で編集可能なデザインデータとして取り込める
・デザイナーの修正内容を、参照コードとスクリーンショットの両方で受け取れる
・「何が変わったのか」を視覚的にもコード的にも確認できる
・React + Tailwind CSSを採用しているプロジェクトであれば、Figma→コードへの変換の手間を大幅に減らすことができる
・既存のFigmaファイルに直接追加できるため、共有の手間が省ける

課題・対策案

コード → Figma（generate_figma_design）側
・キャプチャスクリプトの埋め込み・URLの読み込み・スクリプトの削除という手順が毎回必要で頻繁に行う作業としてコストが高い
　・Viteプラグインや環境変数でスクリプトの埋め込み・削除を自動化できれば、手順を簡略化できる可能性がある
・Figmaに反映した際に、一部でオートレイアウトが外れていたり、コンポーネント化されていない箇所があった
　・これはブラウザの描画結果をキャプチャする仕組み上の制約であり、現時点ではFigma側での手動修正が必要になる
・captureIdは使い捨てであるため、複数ページをキャプチャするにはページ数分の呼び出しが必要になる
　・こちらもツール側の仕様のため、現時点では回避が難しい

Figma → コード（get_design_context）側
・取得したコードの量が多い場合、プロジェクトの技術スタックに合わせたコードの修正を行う手間が発生する
　・Figma MCP Serverが提供する create_design_system_rules であらかじめプロジェクトのルールを定義しておくと、参照コードをプロジェクトの規約に近い形で出力してくれるため、修正の手間を減らせる可能性がある
・get_design_context はアイコンをFigma APIのアセットURLとして返すため、対応するアイコンライブラリにマッピングする必要がある
　・Figma側でCode Connectを設定し、コンポーネントとコードの対応を定義しておくことで改善できる可能性がある
・デザインの規模が大きい場合、get_design_context は出力サイズに制限がかかる場合がある
　・取得するノードを分割して呼び出すことで回避できる
・Figma側にCode Connectやデザイントークンが設定されていない場合、取得できる情報が限定的になってしまう
　・これはFigma側の整備に依存するため、デザインチームと協力して事前にCode Connectやデザイントークンを設定しておくことが重要になる

まとめ

今回は、Figma MCP Serverを使って、モック画面とFigmaデザインを双方向に連携するワークフローを紹介しました。

参照コードの整理やアイコンのマッピングなど、適用工程にはそれなりの手間がかかります。

ただ、デザインデータの正確な読み取りやスクリーンショットの同時取得がその工程を大きく助けてくれるので、手動で値を転記していた頃と比べると確実に楽になっています。

他にもいくつかFigma MCPのツールはあるので、さらに効率的に画面とFigmaデザインの連携ができないかを今後も試してみたいと思います。

最後まで読んでいただき、ありがとうございました。