Claude Code × Figma MCPで、デザインの初速を上げる

前回の記事から11日後に、世界が変わっていた

3月13日に「Figma MCP×Cursor Rulesで実現するデザインレビューと品質管理」という記事を公開しました。

あの時点でのFigma MCPは、あくまで読み取りとレビューが主な使い道でした。
FigmaのデータをAIが参照して、ルール違反を指摘したり、実装との差異を検知したりする。
そこまでが射程で、AIがFigmaのキャンバスに直接書き込むことはできなかったんですよね。

それが、公開から11日後の3月24日に変わりました。

"use_figma" というMCPツールがFigma公式からオープンベータとして公開されて、AIがFigmaのPlugin APIを通じてキャンバスに直接アクセスできるようになりました。

前回の記事を公開した時点では、Figma MCPは読み取り専用でした。
レビューや照合には使えても、キャンバスへの書き込みはできなかったため、便利ではあるけれど、実務でがっつり活用するには用途が限定的だな、という感覚がありました。

"use_figma" の登場で、それが変わりました。
AIには初期構築を任せて、デザイナーは「これで本当にユーザーに伝わるか」という判断に集中できる。そういう使い方が、ようやく現実になったように感じました。

Claude Code × Figma MCPの仕組み

"use_figma" は、Figma公式が提供するMCPツールです。
このツールを通じて、AIはFigmaのPlugin APIを介してキャンバスに直接アクセスできるようになります。テキストを書き換えたり、フレームを作ったり、レイヤーを操作したり、人間がFigmaのUIで手を動かしていたことを、AIが直接実行できるようになるイメージです。

Claude Codeにおける役割分担はシンプルで、

• use_figma：FigmaのPlugin APIを通じてキャンバスを操作するツール
• CLAUDE.md：プロジェクトのルール定義ファイル。デザインルールやFigmaの操作方針をAIに伝える

ちなみに今回は、同じタイミングでCursorからClaude Codeに乗り換えたこともあり、Claude Code × Figma MCPの組み合わせで実験しています。
CursorとClaude Codeの比較については別の記事で改めて書く予定です。

前回記事のCursor RulesがCLAUDE.mdに変わっただけで、「ルールを明示的に定義して、AIに守らせる」という考え方は変わっていません。

1. デザインルール抽出

まず最初にやったことは、FigmaのデータからデザインルールをAIに抽出させることです。
対象のFigmaファイルのURLをClaude Codeに渡して、「このデザインデータからカラートークン・タイポグラフィ・スペーシングのルールを読み取って、design-rule.mdとして書き出して」と指示しました。

約7分後、design-rule.md が自動生成されました。内容は、使用しているカラーのhex値一覧、フォントの種類とウェイト、コンポーネント間のスペーシングの規則など。
手作業で洗い出せばそれなりに時間のかかる作業が、指示一つで完了した感じです。
このファイルが、次のステップで「叩き台を作る」際のルール定義として機能します。

2. コラムページをFigmaに出力

続いて、本命のフローです。
既存のページを参考にしながら、新しくコラム記事ページの叩き台を作らせました。指示の骨子はこの3つ。

• 既存の2ページのデザインを参照すること
• 先ほど作成した design-rule.md のルールに準拠すること
• コラムページに必要なパーツを自律的に判断して構成すること

しばらく待つと、FigmaのキャンバスにPCとSP両方のフレームが生成されていました。
いくつか、見ていて「おっ」と思ったポイントがあります。

フォントの選択が、意図を読んでいた。
design-rule.md に記載されていたNoto Sans JPとZen Old Minchoを、AIが文脈から判断して使い分けていました。「このフォントを使って」とは明示的に指示していなかったので、既存デザインとルールの雰囲気を汲んで選んでくれた感じがして、少し驚きました。

レイヤー命名が、意味のある構造になっていた。
ArticleContents FeaturedImage MetaRow BodyContainer など、機能を示す命名がついていました。AIが生成したからといって Frame 1 Group 42 のような無機質な名前になるわけじゃないんだ、という発見でした。後から人間が触りやすい構造になっていたのは素直に嬉しかったです。

コラムに必要なパーツを、自分で判断していた。
記事の画像エリア、見出し階層、本文ブロック、リスト表現、ページネーション。こちらが細かく指定しなくても、「コラムページとして必要なもの」をAIが判断して盛り込んでいました。

Figmaの「キャンバス操作」をしてみて

プロンプトを徐々に育てていく

最初の指示だけではカラートークン適用されませんでした。
生成されたフレームを見ると、テキストカラーがhex値の直打ちになっていて、Variablesがバインドされていない状態でした。
生成後に「テキストカラーにText/Default/Primaryを適用して」と追加で指示したところ、きちんとVariablesが適用されました。
最初の指示にカラー適用のルールを含めておけばよかっただけで、CLAUDE.mdの書き方で改善できる部分だったと気づきました。
ただ、コンポーネントの差し替えは思ったように適用できず、結果的にFigmaで手動で差し替えました。
全部一発でうまくいくことの方が少ないので、試行錯誤を重ねながらプロンプトを育てていこうと考えてます。

AIに任せるより、手動の方が早い作業がある

初回のデザイン生成はトークンの消費量をさほど気にしませんでしたが、カラートークンの適用と、既存コンポーネントを参照して差し替える作業は、消費量のわりに出力までの時間がかかりすぎると感じました。
トークンを気にしながら作業するのは本質的ではないですが、指示してから結果が返ってくるまでの時間で考えても、この2つは手動で対応した方が圧倒的に早かったです。
AIに任せる作業と、自分でやる作業の切り分けを意識することが、今の段階では大事だと思っています。

「使える案件」と「まだ難しい案件」がある

今回うまくいったのは、ページ数が少なく、デザインもシンプルで、操作のコンテキストを読み取る必要がなかったから、というのが正直なところだと思っています。
AIが判断しなければならないことが少ない状況だったことの方が、コンポーネントが整理されているかどうかより、効いていた気がします。

アプリやSaaSのように状態分岐が多く、すでに運用されているプロダクトの場合は、前提やコンテキストの共有が大変すぎるので、今の段階でAIに頼めるのは新規サービスやウェブサイトなどのコンテキストがシンプルなものから試すのが良いと感じています。
ゼロスタートで、スコープが明確で、参照すべきデザインの量が限られている。
そういう条件が揃っているとき、Figma MCPは力を発揮してくれると感じています。
読み取り・レビュー用途については、引き続き安定して使えています。
前回の記事で紹介したフローは今も実用的なので、書き込みの精度が上がるまでは両方の用途を使い分けていく形がよさそうです。

初速を上げるための環境が揃ってきた

「ゼロから作らない」という考え方は、AIが普及してからずいぶん広まりました。
叩き台はAIに任せて、人間はブラッシュアップに集中する。そのマインドセット自体は、もう当たり前になってきていると思います。

Figmaのキャンバスに直接書き込めるようになったことで、その「任せる」の射程が一段階広がった感じがしています。
テキストや構成をAIに出させることはできていても、Figmaのフレームとして形にするまでは結局自分でやっていた。そこが、今回初めてつながりました。

デザインの初速を上げるための環境が揃ってきている中で、あとは何をAIに任せて何を自分でやるかの切り分けを、プロジェクトごとに育てていくことだと思っています。
"use_figma" が登場してまだ日が浅く、これからも機能は進化していくはずです。
ツールが変わるたびにプロンプトを育てながらプロセスをアップデートして、「デザイナーの本来の仕事」に近づいていく。
それを、焦らずに続けていけたらと思います。