FigmaがMCPで「デザインとコードの壁」を壊しにきた — 双方向ワークフローの本気度

デザイナーとエンジニアの間には、長年にわたって埋まらない溝があった。

Figmaでデザインが仕上がる。エンジニアがそれを受け取ってコードに落とす。出来上がったUIをデザイナーが見る。「余白が違う」「フォントウェイトが微妙に違う」「ホバー状態を実装し忘れている」。Figmaに戻り、コメントを残し、またエンジニアに差し戻す。このループを何度繰り返しても、"Figmaで見た通りのもの"と"ブラウザで動くもの"の間にはわずかな齟齬が残り続ける。

Figmaがこの構造的な問題に、MCPを使って正面から挑んできた。

AI Design Development MCPとは何か

2026年3月、Figmaは「AI Design Development MCP」を発表した。Model Context Protocol（MCP）を活用して、デザインファイルとコーディングツールを双方向につなぐ仕組みだ。

MCPをご存じでない方のために簡単に説明すると、Anthropicが2024年末にリリースしたオープンプロトコルで、AIモデルと外部ツールをつなぐための標準規格だ。「AIのUSB-C」と呼ばれることもある。2026年4月現在、OpenAI、Microsoft、AWSなど主要プレイヤーが採用し、事実上の業界標準になりつつある。FigmaのMCPサーバーもこの規格に則って動く。

対応しているAIコーディングツールはCursor、Warp、Factory、Firebender、Augment、そしてClaude Code、GitHub Copilot CLIなど。開発者が使っている主要な環境のほとんどをカバーしている。

「読む」から「書く」へ — 双方向の意味

これまでのFigma×AI連携の多くは「読み取り専用」だった。AIがFigmaファイルを参照してコードを生成する。方向は常にデザイン→コードの一方通行。

今回の発表で変わったのは、AIエージェントがFigmaファイルに書き込めるようになった点だ。

use_figmaという新しいツールが追加され、Cursorや他のMCP対応エージェントがFigmaファイルの中に直接コンポーネントを作成・変更できるようになった。しかも「ただ図形を置く」のではなく、既存のデザインシステム（コンポーネント、変数、トークン）を参照しながら、その文脈に合った形で変更を加える。

具体的なフローはこうだ。

開発中のUIをブラウザで動かしながら、その状態をFigmaのキャンバスに「editable frame」として送り込む。デザインチームとエンジニアチームが同じキャンバス上でUIを確認し、方向性について議論する。変更が決まったら、デザインコンテキストをCursorなどのコーディングツールに引き戻して実装を更新する。

プロダクション環境のUIがそのままFigmaに入り、そこで決めた変更がコードに反映される。デザインとコードが同期した状態を保てる、理論上は。

Skillsという設計思想

Figmaが今回採用した「Skills」という仕組みは、地味だが面白い。

エージェントがFigmaの中でどう動くかを定義するのがSkillで、その実体はMarkdownファイルだ。Figmaが用意するデフォルトの/figma-useスキルに加え、チームが独自にスキルを書いて追加できる。

「このデザインシステムのコンポーネントを使って、モバイル画面を作る」「既存のフレームのコピーを作って、ダークモード版を生成する」——こうした指示をMarkdownで記述し、エージェントに渡せる。Figmaの操作を熟知した人間なら誰でもスキルを書けるという設計は、コードを書けないデザイナーがAIワークフローの設計者になれることを意味している。

FigJam・Slides・BuzzへのAI画像ツール展開

MCPとは別軸で、FigJam、Slides、Buzzにも新しいAI画像機能が追加された。Expand（画像の拡張）、Erase（特定部分の削除）、Isolate（被写体の切り出し）、Vectorize（ラスターからベクター変換）の4機能だ。

これ自体は各所で類似機能がリリースされており「Figmaも追いついてきた」という程度の話だが、Figmaのプロダクト群（デザイン→プレゼン→SNS素材）をまたがって同じAI画像処理ツールが使えることに意味がある。ブレスト用のFigJamボードで使ったビジュアルを、そのままSlidesのプレゼンやBuzzのマーケティング素材に転用できる。「ツールの切り替えコスト」を削ることへの意識が、Figma全体の設計思想として一貫してきた印象だ。

現実的な評価 — 素直にすごいが、懸念もある

デザイン→コードのギャップを埋める試みとしては、今回の発表は本気度が高い。「AIがデザインシステムの文脈を理解した上でFigmaを直接編集する」というのは、単なるコード生成の延長ではない。デザインとエンジニアリングの協働の構造そのものを変えようとしている。

一方で、正直に言えばいくつか気になる点がある。

まず実運用での精度だ。コンポーネントライブラリを持ち、変数やトークンが整理されたデザインシステムを前提にした話で、そういった体制が整っていない組織——大多数の中小チームがここに含まれる——には恩恵が薄い可能性がある。Figmaファイルが「とりあえず作ったレイヤー構造」の状態では、エージェントが書き込んでも整合性が取れないだろう。

次にデザイナーの役割の変化だ。エージェントがデザインシステムに則ったUIを自動生成できるなら、「既存コンポーネントの組み合わせ」に近い作業はAIが代替していく。スキルを書いてエージェントを制御する立場に回ることで、デザイナーの仕事は「設計の監修」へとシフトする。これをチャンスと見るかスレットと見るかは、個々の判断による。

料金面も確認しておきたい。FigmaのMCP APIは現在ベータ期間中は無料だが、正式リリース後は有料化される見通しだ。具体的な価格はまだ公開されていない。Figmaのプランに乗っかる形になるのか、API呼び出し従量制になるのかによって、ヘビーユーザーのコスト感は大きく変わる。

デザインとコードの「最後の壁」に挑む

AIコーディングツールが急速に進化した2025〜2026年、意外な形で浮き彫りになったのがデザインとコードのギャップだ。Claude CodeやCursorがコードを書ける速度が上がった分、「デザインどおりか確認する工数」が相対的に重くなった。

Figmaのアプローチが興味深いのは、このギャップを「MCPという共通プロトコルで両側から埋める」戦略を採った点だ。デザイン側がエージェントに開き、コード側もエージェントに開く。真ん中でMCPがつなぐ。

思い描く世界は単純に言えば、「Figmaで見た通りのものが、最初から実装される」未来だ。デザイン差し戻しのループが消えるかもしれない。

それが本当に実現するかどうかは、これから数ヶ月のユーザーの検証にかかっている。デザインシステムが整ったチームがまず恩恵を受け、そこからどう一般化するか。Figmaがプロダクトとして最も重要な実験を始めた、そう捉えるのが今の筆者の見立てだ。

参考リンク