catch-img

Claude Code to Figmaを試してみた

目次

  1. はじめに
  2. Claude Code to Figmaとは何か
  3. 従来のワークフローと、その課題
  4. セットアップ手順
    • 【重要】ローカルサーバーとリモートサーバーの違い
    • 4.1. リモートMCPサーバーに接続する(Code to Canvasに必須)
    • 4.2. (任意)ローカルサーバーも併用する場合
    • 4.3. 接続を確認する
  5. 実際に使ってみた
    • 5.1. Claude Codeで簡単なUIを構築する
    • 5.2. 「Send this to Figma」でキャンバスに送る
    • 5.3. Figma上で編集してみる
  6. 使ってみて感じたメリット
  7. 注意点・現時点での制約
  8. デザイナーとエンジニアの協業はどう変わるのか
  9. まとめ


はじめに

こんにちは、DIVXエンジニアのsakuraです。

プロダクト開発の現場で、こんな経験はないでしょうか。
AIコーディングツールを使えば、UIのプロトタイプは数分で作れる。でも、それをデザイナーに共有するには「ローカルで動かして見てもらう」か「スクリーンショットを送る」しかない。デザイナーからは「ここの余白をもう少し詰めたい」とフィードバックが来るけれど、それを試すにはまたコードを触る必要がある——。
「作るのは速いのに、共有と手戻りで時間が溶けていく」。これがAIコーディング時代のワークフローに残されたボトルネックだと感じていました。

2026年2月17日、FigmaがMCPサーバーの新機能として「Claude Code to Figma」(正式名称:Code to Canvas)を公開しました。これは、Claude Codeで構築したUIをFigmaの編集可能なフレームとして取り込める機能です。FigmaはAnthropicのClaude Codeだけでなく、OpenAIのCodexなど複数のAIコーディングツールをMCPという標準プロトコルを通じてサポートする方針を取っており、本記事ではその中でもClaude Codeとの連携に焦点を当てて紹介します。

この機能の本質は、単にコードをFigmaに送れるということではありません。これまで「デザイン → 実装」の一方通行だった開発フローが、「コード → Figma → コード」の双方向サイクルに構造変化する、その入口になる機能だと捉えています。

本記事では、セットアップ手順と実際の操作に加えて、この構造変化が「エンジニアがAIでUIを作る時代に、デザイナーとの協業はどう変わるのか」という視点も含めてお伝えできればと思います。


Claude Code to Figmaとは何か

Claude Code to Figmaは、Figma MCPサーバーを介して、Claude Codeで構築中のUIをブラウザからキャプチャし、Figmaの編集可能なフレームに変換する機能です。

ポイントは、スクリーンショットではないという点です。取り込まれた画面はFigma上で編集可能なレイヤー構造を持っており、テキストの変更、要素の移動、複製といった通常のFigma操作がそのまま行えます。

また、複数画面を一度にキャプチャすることもできるため、オンボーディングフローや設定画面の遷移など、一連の画面を並べて俯瞰するといった使い方も可能です。

主な特徴をまとめると、以下のとおりです。

  • Claude Codeで構築したUIを、ブラウザの描画状態からFigmaフレームに変換できる
  • ページ全体だけでなく、キャプチャツールバーから特定のセクションや個別の要素を選んでキャプチャすることも可能
  • 取り込まれたフレームはフラット画像ではなく、Figma上で編集可能
  • 複数画面の一括キャプチャに対応しており、フロー全体を並べて確認できる
  • Figma MCPサーバーを通じて双方向にやり取りでき、Figmaのデザインを再びコードに戻すことも可能
  • ただし、利用にはリモートMCPサーバーへの接続が必要(詳しくはセットアップ手順で解説)


従来のワークフローと、その課題

これまでの一般的なプロダクト開発では、「デザイン → 実装」の一方通行が前提でした。デザイナーがFigmaでUIを設計し、エンジニアがDev Modeやデザインスペックを見ながらコードに落とし込む。この流れ自体は合理的ですが、AIコーディングツールが普及した今、新しい種類の摩擦が生まれています。

エンジニアの「作ったけど見せられない」問題
Claude CodeやCursorを使えば、UIプロトタイプは10分で作れます。しかし、それをデザイナーに見せようとした瞬間に手が止まります。「このURLにアクセスして」→ 環境構築が必要。「スクショ送ります」→ 静止画では細部が伝わらない。「画面録画しました」→ 「ここの余白を変えたらどうなる?」に答えられない。AIで作る速度と、チームに共有する速度のギャップが、新たなボトルネックになっていました。

デザイナーの「触れないから判断できない」問題
エンジニアから共有されたスクリーンショットや動画を見て、「このボタンをもう少し右に」「フォントサイズを1段階下げたい」と思っても、それを自分の手で試す方法がありません。Figmaで改めて同じ画面を作り直すか、テキストでフィードバックを書いてエンジニアに戻すか。いずれも「思いついた瞬間に試す」ことができず、フィードバックの質と速度の両方が犠牲になっていました。

途中参画デザイナーの「既存画面をなぞり直す」問題
これは私が実際に経験したケースです。正式リリースに向けてデザイナーが途中から参画することになった案件で、すでに動いている画面のFigmaデータが存在しなかったため、デザイナーはまず既存のUIを見ながらFigma上でトレースする作業から始める必要がありました。本来であれば改善提案やUX設計に時間を使いたいところを、「今あるものを再現する」作業に工数が取られてしまったのです。

プロジェクトの進め方としてそうなることもあるので、これ自体が問題というわけではありません。ただ、もしこのときClaude Code to Figmaがあれば、既存の画面をキャプチャしてFigmaに取り込むだけでトレース作業を大幅に省略でき、デザイナーは最初から「改善」に集中できたのではないかと思います。

Claude Code to Figmaは、まさにこの隙間を埋める機能だと感じました。


セットアップ手順

【重要】ローカルサーバーとリモートサーバーの違い

Figma MCPサーバーにはローカル(デスクトップ)サーバーリモートサーバーの2種類があり、それぞれ使える機能が異なります。

サーバー種別

接続先

Figma→コード

コード→Figma

ローカル(デスクトップ)

http://127.0.0.1:3845/mcp

✅ 対応

❌ 非対応

リモート

https://mcp.figma.com/mcp

✅ 対応

✅ 対応

「コードで作ったUIをFigmaに送る」(Code to Canvas)を行うには、リモートMCPサーバーへの接続が必須です。ローカルサーバーのみでは、Figmaのデザインをコードに変換する方向の機能しか利用できません。

なお、プランの制約にも注意が必要です。リモートサーバーはすべてのシート・プランで利用可能ですが、ローカル(デスクトップ)サーバーは有料プラン(Professional / Organization / Enterprise)のDevシートまたはFullシートが必要です。無料プランやViewシート・Collabシートではローカルサーバーは利用できません。

私は最初ローカルサーバーだけを設定して「Send this to Figma」を試みましたが、generate_figma_designツールが利用できず、コードからFigmaへの送信ができませんでした。この点は公式ドキュメントにも明記されていますが、見落としやすいポイントなので注意が必要です。

なお、リモートサーバーでのCode to Canvas機能は、2026年3月時点でClaude Code、Codex(OpenAI)、VS Codeが対応クライアントとして公式ヘルプセンターに記載されています。ただし、一部の情報源ではClaude CodeとCodexのみとされており、VS Codeの対応状況が食い違っています。CursorやWindsurfは非対応です。最新の対応状況は公式ドキュメントを確認してください。

以上を踏まえて、セットアップ手順を解説します。

ステップ1:リモートMCPサーバーに接続する(Code to Canvasに必須)

公式で推奨されている方法は、Figmaプラグインのインストールです。ターミナルで以下のコマンドを実行してください。

claude plugin install figma@claude-plugins-official

このプラグインには、MCPサーバーの設定に加えて、デザイン実装やCode Connectなどのワークフロー用Agent Skillsも含まれています。

プラグインを使わず手動で接続する場合は、以下のコマンドでリモートMCPサーバーを登録します。

claude mcp add --transport http figma https://mcp.figma.com/mcp

初回接続時にはFigmaのOAuth認証フローが起動するので、ブラウザでFigmaアカウントにログインして認証を許可してください。

ステップ2:(任意)ローカルサーバーも併用する場合

Figmaのデザインを選択ベースでコードに変換する機能も使いたい場合は、ローカルサーバーも追加で設定します。有料プラン(Professional / Organization / Enterprise)のDevシートまたはFullシートが必要です。

Figmaデスクトップアプリを開き、以下のいずれかの方法でMCPサーバーを有効化します。

  • 方法A: Dev Modeに切り替えて(Shift + D)、右サイドバーのインスペクトパネルから「デスクトップMCPサーバーを有効化」をクリック
  • 方法B: 左上のFigmaメニューから「基本設定(Preferences)」→「ローカルMCPサーバーの有効化(Enable Dev Mode MCP Server)」を選択

※ FigmaのバージョンやUIの更新によって表示が異なる場合があります。どちらの方法でも同じ機能が有効化されます。

有効化後、以下のコマンドでClaude Codeに登録します。

claude mcp add --transport http figma-dev-mode-mcp-server http://127.0.0.1:3845/mcp

リモートサーバーとローカルサーバーの両方を設定しておくと、コード→Figma(リモート経由)Figma→コード(ローカル経由の選択ベース)の双方向で使えるようになります。

ステップ3:接続を確認する

Claude Code上で /mcp コマンドを実行し、generate_figma_design ツールが一覧に表示されていることを確認してください。表示されていれば、Code to Canvas機能が利用可能な状態です。

もし表示されない場合は、一度Claude Codeを再起動してみてください。Figmaフォーラムでも同様の報告があり、既存の接続を解除してから再認証することで解決するケースが報告されています。


実際に使ってみた

セットアップが完了したところで、実際にClaude Codeで簡単なUIを作り、Figmaに送るまでの流れを試してみました。

Claude Codeで簡単なUIを構築する

今回は検証用として、Claude Codeにシンプルなダッシュボード画面を作ってもらいました。「ユーザー管理画面のダッシュボードをReactで作って」という程度のプロンプトで、それなりに見栄えのするUIが生成されます。

ローカルの開発サーバーで画面をブラウザに表示したら、準備完了です。

「Send this to Figma」でキャンバスに送る

Claude Codeに対して 「ローカルサーバーを起動して、UIをキャプチャし新しいFigmaファイルに送って」 のように入力します。シンプルに「Send this to Figma」でも動作しますが、公式ガイドではこのように具体的な指示が推奨されています。入力すると、Claude Codeがブラウザウィンドウを開き、キャプチャ用のツールバーが表示されます。

ここがポイントなのですが、キャプチャはページ全体だけでなく、要素単位でも行えます。キャプチャツールバーを使って、ページ全体・特定のセクション・個別のボタンやカードなど、送りたい範囲を選んでFigmaに送ることができます。たとえば「ヘッダー部分だけ」「サイドバーだけ」といった粒度での抽出も可能です。

キャプチャが完了してClaude Codeに「終わった」と伝えると、Figmaファイルのリンクが返ってきます。送信後にFigmaのファイルを開くと、キャプチャした要素がそれぞれ個別のフレームとして配置されていました。

Figma上で編集してみる

取り込まれたフレームを触ってみると、テキスト要素は個別に選択・編集でき、ボタンやカードといったコンポーネントもレイヤーとして分かれていることが確認できました。試しにボタンのラベルを変えたり、カードの配置を入れ替えたりしてみましたが、通常のFigma操作と同じ感覚で編集できます。スクリーンショットを貼り付けたときのような「触れない画像」ではなく、ちゃんと"デザインデータ"になっているというのが率直な感想です。


使ってみて感じたメリット:誰の・どの瞬間が変わるのか

実際に一通り触ってみて、「これは便利だ」以上に「チームの動き方が変わるな」と感じた場面がいくつかありました。

エンジニアの「共有する瞬間」が変わる

従来、UIプロトタイプを作った後は「Slackにスクショを貼る」「ローカル環境のURLを共有する」が定番でした。Claude Code to Figmaでは、作ったUIをそのままFigmaに送れるので、プロトタイプを作った直後に、チーム全員がアクセスできる状態で共有できます。デザイナーに「環境構築をお願いする」必要がなくなり、共有のハードルがほぼゼロになりました。

デザイナーの「フィードバックする瞬間」が変わる

これが最も大きな変化だと感じました。従来はスクリーンショットに赤入れをするか、テキストで「ここを右に10px」と書くしかなかったフィードバックが、Figma上で直接要素を動かして「こういうことです」と見せられるようになります。言葉で伝える手間と、伝わらないリスクの両方が大幅に減ります。

途中参画デザイナーの「スタートラインに立つ瞬間」が変わる

前述した既存画面のトレース問題に対しても、Code to Canvasは効果を発揮します。すでに動いている画面をキャプチャしてFigmaに取り込めば、トレース作業をほぼスキップして、改善提案やUX設計からスタートできます。デザイナーが「再現」ではなく「創造」に時間を使えるようになるのは、チームにとっても大きなメリットです。


注意点・現時点での制約

一方で、いくつか注意すべき点もありました。

Code to Canvasにはリモートサーバーが必須

前述のとおり、コードからFigmaにUIを送る generate_figma_design ツールはリモートMCPサーバー(https://mcp.figma.com/mcp)でのみ利用可能です。ローカル(デスクトップ)サーバーだけを設定した状態では、Figmaのデザインをコードに変換する方向の機能しか使えません。私自身、最初にここでつまずいたので、これからセットアップする方はまずリモートサーバーの接続から始めることをおすすめします。Figmaのフォーラムでも同じ問題に遭遇しているユーザーが多く、見落としやすいポイントです。

対応クライアントが限定的

Code to Canvas機能は、2026年3月時点の公式ヘルプセンターではClaude Code、Codex(OpenAI)、VS Codeが対応クライアントとして記載されています。ただし一部の情報源ではClaude CodeとCodexのみとする記載もあり、VS Codeの対応状況は情報によって食い違いがあります。CursorやWindsurfなど他のエディタは非対応です。導入前に最新の公式ドキュメントを確認することをおすすめします。

Figmaデスクトップアプリが必須(ローカルサーバー利用時)

ローカルサーバーを併用する場合は、ブラウザ版のFigmaでは利用できません。チームメンバー全員がデスクトップアプリを使っているとは限らないため、導入時にはその点の確認が必要です。なお、リモートサーバーのみの利用であればデスクトップアプリは不要です。

取り込まれたフレームはコンポーネントではない

Figmaに取り込まれたフレームは、あくまでキャプチャ結果をレイヤー構造に変換したものです。既存のデザインシステムのコンポーネントと自動的に紐づくわけではないため、デザインシステムとの整合性を保つには手動での調整が必要です。

精密なデザイン再現には限界がある

細かいピクセル単位の調整や、複雑なアニメーションの再現はキャプチャの範囲外です。あくまで「構造とレイアウトの共有」が主な用途であり、最終的なデザインの仕上げは人の手で行う前提と考えたほうがよさそうです。


デザイナーとエンジニアの協業はどう変わるのか

Claude Code to Figmaがもたらす最も大きな変化は、開発フローの構造そのものが変わることだと考えています。

従来のフロー(一方通行)

デザイナーがFigmaで画面設計 → エンジニアがコードに変換 → 「想定と違う」 → デザイナーがFigmaを修正 → エンジニアがコードを修正 → 繰り返し

このフローでは、デザインと実装の間を「人が手動で橋渡し」するため、1回の修正サイクルに数時間〜数日かかることも珍しくありません。

Code to Canvas以降のフロー(双方向サイクル)

エンジニアがClaude CodeでUIを構築 → Figmaに送信 → デザイナーがキャンバス上で修正・ブラッシュアップ → Figma MCPサーバー経由でコードに戻す → エンジニアが仕上げ

このフローでは、デザインとコードの間をMCPが自動で橋渡しします。デザイナーは「自分の土俵」であるFigma上で直接改善でき、エンジニアはその結果をコードに反映できます。1回のサイクルが数十分に短縮される可能性があります。

特に大きいのは、「誰が最初に手を動かすか」の選択肢が増えることです。デザイナーが先に動いてもいいし、エンジニアが先にプロトタイプを作ってもいい。起点が柔軟になることで、「デザイン待ち」「実装待ち」で手が止まる時間が減ります。

ただし、これはデザイナーの仕事がなくなるという話ではありません。むしろ逆で、AIが初期プロトタイプを量産できるようになった今、「10案の中から最適な1案を選び、磨き上げる」というデザイナーの判断力と造形力は、これまで以上に重要になります。Code to Canvasはデザイナーの仕事を奪うのではなく、「判断に集中できる環境」を作るものだと感じました。


まとめ

Claude Code to Figmaの本質は、「コードをFigmaに送れる便利機能」ではなく、開発フローの一方通行が双方向に変わる構造変化の入口です。

エンジニアは「作った瞬間にチームに共有」できるようになり、デザイナーは「受け取った瞬間に自分の手で改善」できるようになる。それぞれの「待ちの時間」が減ることで、チーム全体の開発速度が変わります。

ただし、セットアップ時に注意すべき点がひとつあります。コードからFigmaに送る機能(Code to Canvas)にはリモートMCPサーバーの接続が必須で、ローカルサーバーのみでは利用できません。この点は公式ドキュメントに記載があるものの見落としやすく、実際に私もここでつまずきました。これからセットアップする方はぜひ気をつけてください。

まだ公開されたばかりの機能であり、対応クライアントの制限やデザインシステムとの連携など課題もあります。しかし、「デザイン→実装」という長年の前提が揺らぎ始めていることは確かです。気になった方は、ぜひ一度試してみてください。


お悩みご相談ください