デザイン画面からコードを書き換える — Figma Makeがローカル開発環境に直結した

Figmaは「デザインツール」だった。過去形で書いてもいいかもしれない。

5月28日、FigmaはMakeの新機能として、ローカルコードベースへの直接接続を限定ベータで公開した。デザインキャンバス上の要素をクリックし、自然言語で指示を出すと、AIコーディングエージェントが手元のプロジェクトのコードを書き換える。ブランチの作成からPRの発行までFigmaの中で完結する。

これは「デザインツールにAI機能を足した」という話ではない。デザインとコードの間にあった最後の手作業を、ツールごと消しにきた動きだ。

何ができるようになったのか

Figma Makeはもともと、プロンプトからUIプロトタイプを生成する機能として2025年にリリースされた。React + TypeScriptのコードを自動生成し、Figmaの中でプレビューできる。ここまでは既存の話。

今回の拡張は、その「コード生成」の出口をローカルの開発環境に直接つないだ点にある。

具体的な操作はこうだ。Figma Makeをローカルのプロジェクトに接続すると、キャンバス上で3つの方法でコードを編集できる。

1つ目は、画面上の要素を直接アノテーションする方法。ボタンやカードをクリックし、「余白を広げて」「背景色をブランドカラーに」といった指示を出す。AIがコード側の対応する箇所を特定し、変更を加える。

2つ目は、チャットベースの編集。「ログインフォームのバリデーションを追加して」のように、より大きな変更をテキストで指示する。

3つ目は、Figma MCPとの連携だ。フレームURLやコンポーネントリンクを貼り付けると、エージェントが実際のデザインシステムを参照してコードを生成する。FigmaのMCPサーバーを以前から使っていた開発者にとっては、その延長線上にある機能だろう。

ターミナルを開かずにPRを出す

正直、一番「おっ」と思ったのはブランチ・PR機能だ。

Figma Makeの中でコード変更を行ったあと、そのままブランチを切ってコミットし、PRを作成できる。ターミナルを一度も開かなくていい。デザイナーがコードの変更をプレビューし、問題なければワンクリックでPRとして提出する——という流れが現実になる。

ここに既存のFigma MCP連携を重ねると、さらに面白い絵が見えてくる。たとえば、デザインシステムのトークンをFigma上で変更し、それをMake経由でコードに反映させ、PRとしてレビューに回す。デザイナーとエンジニアの「受け渡し」という概念自体が溶けていく。

対象プランと制約

ベータ期間中はクレジットを消費しない。試すだけならコストはゼロだ。

ただし、利用できるのはProfessional、Organization、Enterpriseプランのフルシートユーザーに限られる。CollabシートとDevシートのユーザーはドラフトでのみ使用可能。Starter、Education、Governmentプランは対象外。

現時点での制約もいくつかある。

まず、ベータは「限定」だ。全ユーザーへの一斉開放ではなく、段階的にロールアウトされる。ウェイトリストに登録して待つ必要がある場合もある。

もう一つ気になるのは、サポートされるフレームワークの範囲だ。Figma Makeが生成するコードはReact + TypeScriptがベースであり、Vue.jsやSvelteなど他のフレームワークへの対応がどこまで広がるかは未知数。既存のプロジェクトが非Reactの場合、現時点では恩恵を受けにくい。

CursorやClaude Codeとの棲み分け

「AIでコードを書く」という領域には、すでにCursor、Claude Code、Windsurf、Devinといったプレイヤーがひしめいている。Figma Makeがこの土俵に入ってくることで、競合するのか、それとも補完し合うのか。

結論から言えば、棲み分けは明確だ。

CursorやClaude Codeは「コードのコンテキスト」から出発する。コードベース全体を理解し、ロジック・テスト・インフラまで含めて変更を加える。対してFigma Makeは「デザインのコンテキスト」から出発する。視覚的な要素——レイアウト、スペーシング、カラー、コンポーネントの構造——をデザインファイルと突き合わせながらコードを書く。

たとえば「認証フローのバックエンドロジックを書き直す」ならClaude Codeの仕事。「ダッシュボードのカードコンポーネントをFigmaのデザイン通りに修正する」ならFigma Makeの仕事。出発点が違うから、行き着く先も違う。

ここで面白い組み合わせが浮かぶ。Figma MCPをCursorに接続し、Figma Makeも並行して使う。デザイン起点の変更はMakeで、ロジック起点の変更はCursorで。両方ともFigmaのデザインシステムを参照しているから、UIの一貫性は保たれる。

「デザインレビュー」の意味が変わるかもしれない

この機能が成熟したとき、もっとも影響を受けるのは「デザインレビュー」の工程だろう。

現状、デザインレビューは「Figmaのファイルを見て、実装後のブラウザと見比べる」というプロセスだ。デザイナーがエンジニアに修正依頼を出し、エンジニアがコードを直し、またブラウザでプレビューする。このラウンドトリップに数時間から数日かかることも珍しくない。

Figma Makeがローカルコードに接続されていれば、デザイナーが自分で「余白を4px広げて」とキャンバス上で指示し、コード側に反映されたプレビューをその場で確認できる。修正がpx単位の微調整なら、PRを出してエンジニアにapproveだけもらえばいい。

ただし、これが機能するのは「デザイナーがコードの影響範囲を理解している」前提があるときだ。見た目の変更がレイアウト崩れやアクセシビリティの問題を引き起こすケースは珍しくない。Figma Makeがその検知まで行えるかどうかで、この機能の実用度は大きく変わる。

ベータのうちに試しておく価値はある

Figma Makeのローカルコード接続は、率直に言ってまだ「未完成品」だ。限定ベータであり、サポートフレームワークも限られ、大規模なコードベースでの実用性は未検証。

それでも試す価値がある理由は、ベータ中はクレジット消費がゼロだからだ。GAになればAIクレジットが課金されるため、コストなしで触れる今のうちに、自分のワークフローに合うかどうかを確かめておくのが賢い。

Figmaは2026年度の収益が前年比46%成長しており、デザインツールの支配的ポジションは揺るがない。そのFigmaがコーディング領域に本格参入してきた。デザイナーにとっても、フロントエンドエンジニアにとっても、この動きは無視できない。