「FigmaのこのUI、AIにそのまま実装してもらえたらいいのに」
そう思って Figma MCP を調べ始めた人は多いと思います。
先に結論から言います。
Figma MCP は、FigmaのUIをスクショや言葉で説明する代わりに、Figmaの画面そのものをAIに見せられる接続口です。
「上にヘッダー、その下にカードが横並びで、スマホでは縦積み……」と自分で言葉にして渡す代わりに、Figmaの構造をAIが直接読んでくれます。
ただ、画面を丸ごと渡せば実装が出てくる、というほど単純ではありませんでした。
むしろ、どこで詰まるかを知っておくほうが、最初の一歩は軽くなります。
私は本業のWeb制作、個人開発アプリで、Figma MCP を毎日 Claude Code につないで使っています。
毎日使っている経験から、Figma MCP の設定だけでなく、FigmaをAIに見せて実装前の認識合わせに使えるようになるところまで、何を・どの粒度で渡せばいいかを持ち帰れるようにまとめました。
Claude Code への接続から、大きいフレームで詰まったときの回避まで。
ただ、AIツールは動きが速いので、料金やエンドポイント、対応エディタは変わる可能性がある前提で読んでください。
実際にFigma MCPも出た当初から現在は、接続の仕組み等が変更になっていたりします。
- Figma MCP で何ができて、何ができないのか(接続口であって、完成コードを吐く魔法ではない)
- Claude Code への接続手順と、毎日使っている当事者の実物8手順
- 大きいフレームで詰まったとき、何を・どの粒度で渡せばいいか
記事を書いている人

R(アール)
Web制作の現場で17年(現役進行中)。精密栄養カウンセラー。
個人開発をアプリ6本並行しながら、AIと「作る・届ける」を実験しています。
うまくいったことも、月収2,000円みたいな冴えない数字も、隠さず公開中。
教える人ではなく、少し先で転んで戻ってきた人として、あなたと同じ目線で現在地を観測していけたらと思います。
Figma MCPで何ができるか

「結局、何ができるツールなの?」と思いますよね。
名前は物々しいですが、やっていること自体は、わりとシンプルです。
Figma MCP(公式名は Figma MCP server、いわゆる Dev Mode MCP Server)がやってくれるのは、Figmaのデザイン情報、つまりコンポーネント・変数・レイアウトデータなどを、AIコーディングエージェントに「文脈」として渡すことです。もともと Dev Modeでデザイン情報を開発者に渡す仕組み を、人ではなくAIエージェント向けに開いたもの、と捉えるとイメージしやすいです。
そのうえで、選んだフレームからコードを生成できます。
読み取るだけにとどまらず、コードやライブのWeb UIをFigmaキャンバスに書き戻す双方向の機能もあります(書き込みは2026年6月時点でベータ・無料期間中で、将来的に有料機能になる予定とされています)。
私の使い方は、もっと地味です。
Figmaで作った小さいUIを Claude Code に読ませて、レイアウトや余白、階層、コンポーネントの感じを把握させ、Vue / React / SwiftUI の実装の叩き台を作ってもらう。
これが中心です。
「そのまま完成コードを吐かせる」ためでなく、「実装に入る前に、AIにこの画面の理解を持たせる」ために使っています。
でも、AIに見せたら、いい感じに全部コードにしてくれるんですよね?

それが、正直そこまで甘くなかったんです。最初は私もそう期待していました。出てくるのは『完成品』でなく『叩き台』と『この画面をどう読んだか』。価値はむしろそこにありました
サーバーは2系統あります。
普段使うのは remote版で、こちらが公式の推奨です。
- remote版(推奨)
Figmaがホストする型。デスクトップアプリ不要で、機能がいちばん広い。
エンドポイントは https://mcp.figma.com/mcp。利用できるかどうかと回数は、Figmaのプランとシートタイプで変わります。公式のレート制限では、View / Collab シートは月6回まで、Dev / Full シートは上限が緩くなっています(2026年6月時点)。 - desktop版
ローカルで動かす型。エンドポイントは http://127.0.0.1:3845/mcp。
Figmaデスクトップアプリで Dev Mode に切り替えて有効化します。
Figma公式はこれを「特定の organization / enterprise 向けのユースケース」と位置づけていて、基本は remote版を推奨しています。
迷ったら remote版で問題ありません。
私も remote版を使っています。
繋ぐ手順自体は、数ステップで終わります。
Figma MCPの使い方|Claude Codeへの接続・設定手順

ここが「figma mcp 使い方」で来た人がいちばん見たいところだと思います。Claude Code への接続から書きます(2026年6月時点・変わる可能性あり)。
いちばん手軽なのは公式プラグインを入れる方法です。
Claude Code で次を実行すると、MCP設定と合わせて関連の Agent Skills まで入ります。
claude plugin install figma@claude-plugins-officialプラグインを使わず、手動で接続することもできます。
私はこちらでも試しました。
claude mcp add --transport http figma https://mcp.figma.com/mcpこのあと新しい Claude Code のインスタンスを立ち上げ、/mcpを実行して figma を選び、Authenticate を押すと、OAuth の画面で Allow Access を求められます。
Figmaアカウント(OAuth)が必要です。承認まで通れば接続完了です。
手順自体は数ステップで、一度きりです。
より詳細な手順はオフィシャルドキュメントに記載があります。
設定が面倒なら、手で書くのと変わらないんじゃ……

接続は一度だけなので、そこは身構えなくて大丈夫です。変わるのは『AIに状況を説明する時間』のほう。これがどう変わるかは、このあとの8手順で実物を見せます
Cursor や VS Code でも、remote版のエンドポイント(https://mcp.figma.com/mcp)は共通です。
Cursor はエージェントチャットで /add-plugin figmaを打つか、公式のディープリンクから Install → Connect → Allow access で繋がります。
VS Code はコマンドパレットから MCP の設定ファイル(mcp.json)を開き、figma サーバーを http 型で追加します。
{
"servers": {
"figma": {
"url": "https://mcp.figma.com/mcp",
"type": "http"
}
}
}VS Code 側は GitHub Copilot を有効にしておくのが前提です。
なお、接続できるのは Figma の MCP Catalog に載っているクライアントだけで、2026年6月時点の代表例は VS Code / Cursor / Windsurf / Claude Code / Codex とされています。
実際のワークフロー(私の8手順)

設定が済んだら、いよいよ本番です。
といっても、身構えるほど難しいことはしていません。
私が自作アプリで毎日やっている流れを、そのまま並べます。
- Figmaで実装したい画面を作る
- 実装したい範囲だけを選ぶ(1画面まるごとでなく)
- その選択(またはレイヤー)のリンクをコピーする
- Claude Code にそのリンクを貼る
- 「このUIを実装したい。まず構造を読み取って、実装方針を出して」と頼む
- いきなりコードを書かせず、コンポーネントの分割・状態・CSSやレイアウトの方針を確認する
- 方針に問題がなければ実装してもらう
- 出てきたコードを見ながら、人間が調整する
鍵は手順5と6です。
リンクを貼ってすぐ「実装して」と言いたくなるのですが、私はそこで一度止めて、まず「この画面をどう読んだか」をAIに説明させるようにしています。
remote版は、Figmaでコピーしたリンクや選択を貼って文脈を渡す「リンクベース」の仕組みです。
だからこそ、何を渡したかをこちらが分かっていないと、出力もぶれます。
最初に方針を確認しておくと、後の手戻りが大きく変わります。
逆に、いきなりコードを出させると、想定と違う分割で組まれていて、結局ほどく作業から始まることになりました。
試しに、リンクを貼った直後に「実装方針だけ先に」と挟んでみると、出力の落ち着き方が変わると思います。
詰まりやすい点

ここからは、使い始めの私が実際にハマったところです。
できれば先に知っておいて欲しいなと思うところをまとめました。
大きいフレームを丸ごと渡すと重い
最初、私は1画面まるごと Claude Code に渡して「いい感じに実装して」とやりました。
Figma全体をAIがうまく理解してくれると期待しましたが、やっぱり、扱いづらかった。
情報量が多すぎて、応答が重くなったり、欲しい粒度で返ってこなかったりしました。
対処はシンプルで、小さく切り出すだけです。
ヘッダーだけ、カードだけ、フォームだけ、モーダルだけ、実装したいエリアだけ。
1回で扱えるのは小さなセクションか、小さい画面ひとつ程度、と考えておくと安全です。
大きい選択は遅延や不完全な応答、エラーを招くので、論理的なまとまりで分割するのが推奨されています(AIMultiple や Locofy の検証でも同様の指摘があります)。
ここで覚えておきたいのが「切り出しの設計」です。
どこを読ませるかを人間が決める。これが Figma MCP を使ううえで、地味ですが効いてくる部分でした。
Claude Code でのトークン超過
大きいフレームを渡すと、Claude Code では別の形でも跳ね返ってきます。
トークン超過です。これは公式が既知の問題として挙げているもので、たとえば次のようなエラーが出ます。
Error: MCP tool "get_design_context" response (351378 tokens)
exceeds maximum allowed tokens (25000)公式の回避策は、Claude Code の環境変数 MAX_MCP_OUTPUT_TOKENSを 50000〜100000 など大きめに上げることです。
ただ私自身は、値を上げる前に、渡す範囲を絞るほうで対処しています。
結局のところ、AIに渡す前に、人間が読み取り範囲を設計する、という同じ話に戻ってくるからです。
設定値で殴るより、切り出しで軽くするほうが、出力も素直でした。
えっ、35万トークン……? そんなに膨らむんですか

大きい画面を丸ごと渡すと、そうなり得ます。だから『全部見せて任せる』でなく『この範囲だけ見せる』。範囲を絞れば、この数字自体が出てこなくなります
Code Connect が無いと既存コンポーネントを作り直す
もう一つ、地味に効いた詰まりどころです。
私のプロジェクトには既に Button コンポーネントがあったのに、AIが似たようなボタンを新規で作り直してしまったことがありました。
似たものが増えかけて、ヒヤッとしました。
これは Code Connect が無い状態で起きやすい挙動です。
Code Connect は、Figmaのコンポーネントと実コードのコンポーネントを結びつける仕組みで、Figma公式も「コードでのコンポーネント再利用を一貫させる一番の方法で、これが無いとモデルは当て推量する」と明言しています。
Code Connect をすぐに用意できないときは、指示で補えます。
私が使っている言い方はこんな型です。
- 「新規で作らず、既存の Button を使って」
- 「`src/components/Card.vue` に寄せて」
- 「新しいコンポーネントを作らず、既存の設計に合わせて」
渡すデザインだけでなく、寄せてほしい既存コードまで名指しで伝える。
これで重複コンポーネントの乱立はかなり防げます。
そもそも Figmaのコンポーネント命名を整理しておく と、「既存の Button を使って」という指示自体が通りやすくなります。AIが当て推量する余地が減るからです。
実務でどういう粒度で使うか

最後に、毎日使ってみて、結局何が変わったのかを正直に書きます。
入れる前、私は Figma を見ながら「上にヘッダー、カードは横並び、スマホでは縦積み、余白は24px……」と自分で仕様を言語化して、それを Claude Code に渡していました。Claude Code を起点にしたデザイン工程としては、逆向きに Claude Codeから叩き台のデザインを起こすところ も試していて、作る側と読む側で同じ Claude Code を行き来している感覚です。
入れた後は、Figmaの構造をAIに見せたうえで「この画面をどう理解したか」「どんなコンポーネントに分けるべきか」「実装に入る前に足りていない情報は何か」を相談できるようになりました。
変わったのは、コードを書く速度というより、実装前の会話の質でした。
Figmaを共通の前提に置いて、実装方針そのものを相談できる。
これが私にとっていちばん大きい変化です。
最初の説明と、叩き台を作るところは、体感でかなり楽になりました。
正直に言うと、時間の数字はまだちゃんと計測していません。
だから「○時間が○時間になった」とは言えません。
ただ、最初の足場が早く立つようになったのは確かです。
一方で、最後の調整と、既存コードへの統合は、今も人間が確認しています。
ここは Figma MCP を入れても変わりませんでした。
ここまで使ってきて思うのは、Figma MCP は「デザイナー不要・エンジニア不要」の話ではなく、デザインと実装の間にある翻訳コストを下げる接続口だ、ということです。
「Figma MCP でデザイナーもエンジニアもいらなくなる」みたいな語られ方には、毎日使っている側として、少し違和感があります。
実際は、FigmaをAIに見せること自体がゴールではありません。
何を・どの粒度で・何の目的で渡すかを設計するところに、まだ人間の役割がかなり残っています。
だから結論はシンプルです。
Figma MCP は、Figmaの画面をAIに見せる接続口です。
丸投げで実装は完成せず、何を・どの粒度で・何の目的で渡すかは、人間が設計します(2026年6月時点)。
なお、公式の Figma MCP のほかに Framelink のようなサードパーティ製のサーバーもあります。
用途で選ぶのは構いませんが、同じFigmaデータを触る複数のMCPサーバーを同時に動かすと、エージェントが混乱して出力がぶれます。
併用はせず、どちらかに寄せるのが無難でした。
ツールを入れることが目的ではない

Figma MCP、慣れてくると「効くのは設定じゃなくて、渡し方なんだな」とわかってきます。どこをAIに任せ、どこを自分で握るかという話は、Figmaの生成AI側でも同じで、AIに任せる場面と手動に戻す場面の判断 に整理しています。
私が遠回りして気づいたのは、結局この3つでした。
- 画面まるごとは渡さず、実装したい範囲を小さく切り出して渡す
- いきなりコードを書かせず、まず「どう読んだか」を説明させる
- 既存コンポーネントを使うなら、名指しで明示する(「既存の Button を使って」)
派手なコツではないですが、この3つを意識するだけで、最初の一歩、けっこう変わると思います。
そしてもうひとつ。
Figma MCP が結局映してくれるのは、自分のデザインから実装に落とす工程で、どこで手戻りしているかです。
切り出しの粒度なのか、コンポーネントの整合なのか。あなたの場合は、どこでしょう。
まずは、いちばん小さいパーツをひとつ選んで、リンクを貼ってみるところから。
そこで「最初の説明がいらない」と感じたら、もう半分は掴んでいます。
私自身も毎日この使い方で、実装に入る前の手数が減りました。
どこをAIに渡して、どこを自分で握るか。その現在地の観測を、メルマガで毎週書いています。
同じところで手を動かしている人に、たぶん役に立つはずです。
