Figma Dev ModeのMCPでコンポーネントをコード化する手順

Figma Dev Mode MCPとは何か — デザインをコードに変換する仕組み

Figma Dev Mode MCPは、Figmaのデザインファイルを直接読み込ませ、選択したフレームやコンポーネントに対応するコードをAIに生成させる仕組みだ。MCP（Model Context Protocol）はAIツールが外部のデータやサービスと安全にやり取りするための共通規格で、Figma Dev Mode MCP Serverはこの規格に沿ってデザイン情報をエディタに渡すベータ機能として提供されている。

従来のAI支援コーディングは、スクリーンショットを見せて「似たコードを書いて」と頼む方式が中心だった。MCP経由ではレイヤー構造やAuto Layoutの設定、使用しているスタイル変数といった構造化情報がそのまま渡るため、見た目だけでなく実装の意図に近いコードが出力されやすい。

Figmaと連携するとできること — コード化だけではない実務での使い方

「選択したコンポーネントのコード化」が入口だが、接続してみると価値はむしろその周辺にある。実務で効く使い方を挙げる。

デザインをそのまま実装コードに変換する

Figma上でフレームを選択し「これを実装して」と依頼するだけで、Auto Layoutの入れ子がflexboxに、余白・角丸・フォント指定が実数値でコードに反映される。出力先はReactに限らない。EC-CUBEのTwigテンプレート、WordPressテーマのPHP、ShopifyのLiquidなど、「このプロジェクトの流儀で書いて」と指定すれば既存コードベースに合わせた形で生成される。スクリーンショット貼り付けとの決定的な違いは、カラーコードや余白が「目測」ではなく「デザインデータの実数値」で出てくることだ。

デザイントークンを抽出して変数定義に落とす

Figmaで定義した色・スペーシング・タイポグラフィの変数（バリアブル）を読み取り、CSSカスタムプロパティやSCSSの変数ファイルとして書き出せる。デザイナーがトークンを更新したら、差分を反映した変数定義を再生成する、という運用が回るようになる。逆に言えば、Figma側でトークンが整備されていないと生成コードは数値ベタ書きになるので、この機能はデザインシステム整備の動機付けにもなる。

実装済み画面とデザインの食い違いを検出する

「実装したこの画面、Figmaの指定とズレていないか確認して」という使い方ができる。AIがFigmaから正しい余白・色・フォントサイズを取得し、実装コードの値と突き合わせる。人間が目視でやると見落とすpaddingの2pxズレや、微妙に違うグレーの検出はAIのほうが確実に速い。デザインレビューの往復回数を減らせる。

既存コンポーネントを流用した提案を受ける

Claude Codeはプロジェクトのソースコードも読めるため、「このデザイン、既存のコンポーネントで組めるか」という相談ができる。ゼロから生成させるのではなく、手元のボタンやカードのコンポーネントを流用し、足りない差分だけ新規実装する提案をさせると、生成コードの手直し量が大きく減る。エディタ単体のコード生成機能との差はここに出る。

Figma Dev Mode MCPを接続してコンポーネントをコード化する手順

接続自体は難しくないが、順番を間違えると「サーバーは起動しているのにエディタから見えない」状態になりやすい。Figma側でサーバーを立ち上げてから、エディタへ登録する順序を守ることが重要だ。

MCPサーバーの起動とCursor・VS Codeなどエディタへの接続設定

Figmaデスクトップアプリでデザインファイルを開き、Dev Modeに切り替える（ツールバー右のトグル、またはShift+D）。検査パネルのMCP serverセクションで「Enable desktop MCP server」を有効にすると、ローカルサーバーが立ち上がる。エンドポイントは http://127.0.0.1:3845/mcp で、ポート番号は3845固定だ。なおDev Modeを使うにはProfessional以上のプランのDevシートまたはフルシートが必要で、無料プランでは利用できない。

次にCursorやVS CodeなどMCP対応のエディタ側で、MCPサーバーの設定にこのURLを登録する。Claude Codeでの具体的な接続手順はClaude CodeでFigmaデザインを直接参照・操作する方法で扱っているので参考にしてほしい。

接続できたかは、エディタのMCPツール一覧にFigmaのサーバーが表示されているかで確認できる。実際に動作しているかを確かめる一番早い方法は、Figma上でコンポーネントを1つ選択し、AIに「このコンポーネントをコード化して」と依頼することだ。構造化情報が渡っていれば、レイヤー名やAuto Layoutの向きを反映したコードが返ってくる。

生成コードが元デザインと食い違う典型パターンとその原因

生成コードがデザインと微妙にズレる原因の多くは、MCPサーバーが「今Figma上で選択されているノード」しか渡さないという制約にある。選択が古いフレームのままだったり複数フレームを跨いでいたりすると、AIは不足情報を推測で埋め、余白や配置がずれたコードになりやすい。

• 絶対配置（position:absolute）で出力される — Auto Layoutの入れ子構造が複雑でflexへのマッピングに失敗した場合
• 色やスペーシングが数値ベタ書きになる — デザイントークン（変数）が未設定、またはコンポーネント側に紐づいていない場合
• 一部の子要素だけが抜け落ちる — 選択したノードに非表示レイヤーやバリアント違いが含まれていた場合

これらは壊れているのではなく、渡された情報の範囲でしかコードを作れないという仕組み上の限界だ。プロトタイプ段階で構造をざっと組む用途には十分強力だが、生成コードをそのまま本番実装に採用するのではなく、自社のコンポーネントライブラリやトークン定義に合わせて手動修正する前提で使うのが実務的な判断になる。