Figma MCPでClaude Codeにできることは、スクリーンショットを貼る場合とどう違うのか？
スクリーンショットではClaudeはピクセルしか見えないが、Figma MCPを通すと構造化データを読める。レイアウト、色や間隔の変数、コンポーネントだ。そのため、近い色コードを推測するのではなく、自分のトークンを使える。
逆方向も可能だ。Claude Codeで「Send this to Figma」と言うと、ブラウザで動いているUIが編集可能なFigmaフレームとして取り込まれる。
無料のStarterプランでも試せるか？
接続はできるが、すぐに制限に当たる。DEV Communityの説明では、StarterプランとView、Collabの席は月に最大6回のツール呼び出しまでで、設定とテストだけで使い切ることがある。
実務で使うなら、有料プランのDevまたはFullの席が推奨されている。まず小さな範囲で価値を確かめてから、席を買うかを決めたい。
なぜ一度に一つのフレームだけをリンクするのか？
ページ全体や非常に大きなフレームを貼ると、応答が遅くなったり途中で切れたりするからだ。get_metadataというツールはこのために用意されており、軽量な構造マップを返して、Claudeが必要なノードだけを取得できるようにする。
実務では、ページをコンポーネントやセクションに分け、一つずつリンクして実装する。ページ全体を一度に渡さない。
生成されたコードをそのまま使ってよいか？
勧められない。記事は、ReactとTailwindの出力をそのまま使うと、既存のコンポーネントと重複する並行したUIキットができうること、レイヤー名が整っていない（たとえば「Group 5」）とコードも意味をなさないことを警告している。
そのためルールファイルには、出力を最終コードではなく記述として扱い、終える前にスクリーンショットと比較するという一項がある。どちらの記事も定量的な品質データを示していないので、品質は自分で確かめる必要がある。
FigmaのMCPサーバーを使うと、Claude Codeが、スクリーンショットや文章での説明に頼らず、デザインを直接読める。コードを書かないデザイナーやPMにとって節約できるのは、画面を要件に翻訳する手間だ。本稿は、DEV CommunityとBuilder.ioの二つの実践記事をもとに、接続方法、Claudeが読めるもの、つまずきやすい箇所を整理する。どちらも定量的な成果は示しておらず、Builder.ioは競合製品も販売しているので、以下で明記する。
一つ目は読む方向だ。Figmaのリンクを貼ると、Claude Codeがレイアウト、変数、コンポーネントを読み、それをもとにコードを生成する。二つ目は書く方向で、Claude Codeで「Send this to Figma」と入力すると、ブラウザ上で動いているUI（本番、ステージング、localhost）が編集可能なFigmaフレームとして取り込まれる。テキストは編集でき、ボタンは独立したコンポーネントになり、レイアウトはauto-layoutになる。後者はgenerate_figma_designというツールを使い、これはClaude Code限定でリモートMCP限定だ。
二つの記事の手順は一致している。まずターミナルでFigmaのリモートサーバーを追加する（--scope userを付けると全プロジェクトで使える）。
claude mcp add --transport http --scope user figma https://mcp.figma.com/mcp
次にClaude Codeを起動して/mcpと入力し、figmaを選んでAuthenticateを選び、ブラウザでOAuthのサインインを完了する。トークンを手で貼る必要はない。もう一度/mcpと入力して緑の表示になれば成功だ。一覧にfigmaがなければClaude Codeを再起動する。MCPサーバーは起動時に読み込まれるからだ。claude mcp listでも確認できる。Connectedなら正常、Needs authenticationなら/mcpをもう一度実行、Failed to connectならURLが/mcpで終わっているか、トランスポートがhttpかを確認する。
別の方法としてプラグインがある。claude Plugin install figma@claude-plugins-official だ。プラグインかサーバーのどちらか一方だけを使う。両方入れると、ClaudeにFigmaのツールが重複して見える。
DEV Communityの記事は四つの読み取りツールを挙げている。get_design_contextは、リンクしたフレームをReactとTailwindの構造にまとめて返し、コードの出発点になる。get_variable_defsは、色、間隔、書体の変数とスタイルを取得し、Claudeが直書きの値ではなくトークンを使えるようにする。get_metadataは、大きな選択範囲の軽量な構造マップを返し、必要なノードだけを取得できるようにする。get_screenshotは、比較用にフレームの画像を渡す。ほかにキャンバスへの書き込み機能（ベータ）があり、リモートサーバー限定で、ベータ期間中は無料だ。
記事は、プロジェクトのCLAUDE.mdに、毎回の作業手順を固定する節を追加することを勧めている。
## Figma MCP rules 1. Run get_design_context first. 2. If the response is too large, use get_metadata to find the nodes you need. 3. Run get_screenshot before coding. 4. Treat the output as a description, not final code. 5. Before finishing, compare the result against the screenshot.
実際のプロンプトは、たとえば次のようになる。「このフレームを src/components/marketing/PricingCard.tsx のReactコンポーネントとして実装して。既存のButtonを再利用し、デザイントークンを使って：（Figmaのリンク）」。成功したかを簡単に判断するには、コードを書く前にClaudeがget_design_contextとget_screenshotを呼んでいるかを見ればよい。
第一に、プランの制限だ。有料プランのDevまたはFullの席が推奨されており、StarterプランとView、Collabの席は月に最大6回のツール呼び出しまでで、設定だけで使い切ることもある。有料席には1分あたりの上限がある。第二に、リンクする範囲だ。ページ全体や非常に大きなフレームを貼ると、応答が遅くなるか途中で切れるので、一度に一つのフレームかコンポーネントにする。第三に、出力が並行したUIキットを生むことがある。ReactとTailwindの出力をそのまま使うと既存のコンポーネントと重複しうるため、プロンプトでフレームワークと再利用するコンポーネントを指定する。第四に、レイヤー名だ。「Group 5」のような汎用名は、意味のないコードを生む。
Builder.ioの記事は、コードをFigmaに送る方向の制限も挙げている。レイヤーはビジネスロジック、イベントハンドラ、状態管理を持たない。エクスポートは一方向で、その後のデザイン更新はやり直しになる。注釈のある要素はMCPが失敗することがある。WindowsのWSLユーザーには欠落があり、get_codeにはCode Connectが必要で、それは組織向けとエンタープライズ向けのプランにしかない。記事は最後に自社製品を勧めているため、この部分はベンダーの見解として読んでほしい。
まず席を確認する。Starterや閲覧専用の席なら月6回の呼び出しはほとんど役に立たず、ツールが使えないように見えてしまう。実務で使うにはDevまたはFullの席が必要で、それは追加の席のコストになる。
次に利用量だ。どちらの記事もトークン消費や測定した時間短縮に触れていないため、このワークフローにどれほどの価値があるかは言えない。実際の小さなコンポーネントを一つ選んで最後まで実行し、かかった時間と修正回数を記録してから、席を買う価値があるかを判断したい。整ったレイヤー名と完全な変数が、最も安い投資だ。同じデザインファイルがより正確に読まれ、やり直しも減る。