every Tech Blog

株式会社エブリーのTech Blogです。

トップ > AI > CursorとFigma-Context-MCPを使ってLPの開発効率を上げる
最終更新日

CursorとFigma-Context-MCPを使ってLPの開発効率を上げる

AI LLM 生成AI

はじめに

こんにちは。デリッシュキッチン開発部の村上です。
弊社ではエンジニアとPdM全員にCursorを配布しており、生成AIを活用した開発を積極的に行っています。

prtimes.jp

エンジニア組織では開発生産性10倍を目標としていますが、そこに到達するためには新しい技術やツールに触れながら、 ある意味でこれまでの開発のやり方を根底から疑ってみて、生成AIの活用を前提とした新しい組織・業務設計をしていく大胆さが求められていきます。

そんな中で、私の所属する組織ではちょうどLPの開発について考える機会がありました。
LPはそこまで複雑な機能はなく、基本的にはデザインに基づいたコーディングが中心になりますが、地味に時間がかかります。
そこで、最近話題のFigma-Context-MCPを使った検証をしているのでそこで得た知見を紹介しようと思います。

今月の初めには弊社CTOもMCPサーバーに関する記事をあげているのでぜひこちらもご覧ください。
tech.every.tv

Figma-Context-MCPとは

Figma-Context-MCPとは、FigmaのデザインデータをCursorなどのAIコーディングツールの "ツール呼び出し" として扱えるようにする Model Context Protocol (MCP) サーバーです。Figma APIから取得した複雑なJSONの情報を整理してLLMに橋渡しすることによって、効率的にデザイン解析やコード生成が可能になります。

github.com

始め方

セットアップは簡単で公式のクイックスタートを見ればすぐに利用することができますが、こちらでも簡単に説明します。

Figmaアクセストークンの取得

Figma-Context-MCPはFigma APIを通してFigmaの情報にアクセスするのでアクセストークンが必要になります。
アクセストークンはアカウントの設定メニューからSecurityタブを開けば、アクセストークン発行の導線が見つかります。公式ドキュメントによると File content と Dev resources の読み取り権限が実行に必要なため注意してください。

Cursor側でMCPサーバーを設定

こちらも公式ドキュメントからほとんど変えていないですが、.cursor/mcp.json にMCPサーバーの設定を追加します。
（※2025年4月27日時点でバージョン指定をしていないと接続エラーとなるため、最新のv0.2.1を指定しています）

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp@0.2.1",
        "--figma-api-key=<API KEY>",
        "--stdio"
      ]
    }
  }
}

シンプルなLPデザイン構成でコード生成を試す

まずは実際に弊社内でデザインされているLPのFigmaデータから部分的に切り出してシンプルな画像要素中心のLPで検証してみます。 今回は題材として、デリッシュキッチンが手掛けている冷凍宅配弁当の「Meals」のデザインデータを使います。

Figmaの構造

切り出したFigmaのLPデータは以下のような構造で画像が中心となっているため、とてもシンプルです。

test1（Frame）
├── Group 48（Group）
│   └── kv（Group）
│       ├── 帯（Group）
│       │   ├── このページをご覧の方 限定！（Text）
│       │   └── Rectangle 40（Rectangle）
│       └── kv_food（Image）
└── diet_onayami（Image）

LP生成

Cursorから指示を出してみます。Figmaでは「Copy Link to Section」という形でセクションのリンクを取得できるのでそのリンクを使用します。
Figmaでページ全体を共有すると複数デザインがおいてある場合にすぐにContext上限で応答パフォーマンスも悪くなるため、生成したいものだけに絞ることをお勧めします。

以下のfigmaのデザインを参照して、コーディングを行ってください。

@<figmaの該当セクションのURL>

デザインと生成されたLPのスクショを比較したのがこちらです。
ヘッダーの位置がずれてしまっていたり、marginが余計に入ったりと満足のいくものが出てきません。

Auto Layout機能を使ってレイアウトを認識させる

調べていくと公式ドキュメントのBest Practicesで以下の言及がされていました。

Use auto layouts—the MCP isn't great at handling floating or absolutely positioned elements just yet

どうやらMCPはGroupで指定された絶対値参照のレイアウトが得意ではないようでAuto Layoutを使うことが推奨されていました。私はFigmaについては初心者なので詳しいわけではないですが、Auto LayoutはCSSでいうflexboxのように要素を規則的に並べることが出来る機能で要素の並び方や要素間のgapを定義することができます。

さっそく、kvと 全体（test1）にAuto Layoutを適用して、Figmaを更新してみます。

test1（Auto Layout）
├── Group 48（Group）
│   └── kv（Auto Layout）
│       ├── 帯（Group）
│       │   ├── このページをご覧の方 限定！（Text）
│       │   └── Rectangle 40（Rectangle）
│       └── kv_food（Image）
└── diet_onayami（Image）

この状態で先ほどと同じ指示でLP生成を行った結果が以下の画像です。 Auto Layoutを指定しただけでその他は構造も命名も変えていませんが、要素の位置を認識してデザイン通りに配置してくれています。画像中心のレイアウトであれば、ここから縦に数を増やしてもアウトプットの精度は大きく変化せず安定していました。

もう少し複雑なLPデザイン構成でコード生成を試す

ほとんどのセクションが画像となっているデザイン構成であれば、前述の方法でもかなりLPの開発をショートカットできそうですが、そういったケースだけではなさそうです。もう少し構成要素が多いものでみてみましょう。

Figmaの構造

今回、Auto Layout設定は一部に設定していますが、要素やその配置は先ほどよりやや複雑です。

test3（Auto Layout）
└── nutrition（Frame）
    ├── title（Group）
    │   ├── icon_point（Image）
    │   ├── nutrition_title（Image）
    │   └── nutrition_title_bg（Image）
    └── 栄養基準（Auto Layout）
        ├── Group 31（Group）
        │   ├── 糖質・脂質・塩分・野菜量など8項目の栄養基準（Text）
        │   └── Rectangle 25（Rectangle）
        ├── nutrition_ingredients_img（Image）
        └── ※上記に合わせて脂質(10~20g)、炭水化物(15~35g)の基準を設定（Text）

LP生成

先ほどと同じ指示でLP生成をしてみます。

以下のfigmaのデザインを参照して、コーディングを行ってください。

@<figmaの該当セクションのURL>

生成されたLPをみてみるとデザインに比べて、大きく崩れていることがわかります。

絶対値で重なって構成されている要素は一つの画像として扱う

大きく崩れた部分は以下のtitleのGroup配下の要素でした。

test3（Auto Layout）
└── nutrition（Frame）
    ├── title（Group）
        ├── icon_point（Image）
        ├── nutrition_title（Image）
        └── nutrition_title_bg（Image）

今回のFigmaデザインでは3つの画像で一つのヘッダーセクションを構成していましたが、これは前述したように絶対値を苦手とするMCPではコード生成のクオリティが下がります。可能な限り、こういった要素は一つの画像にまとめると自動生成が楽になります。

同一テキスト間で違う文字サイズ、色を使う場合はテキストごと分ける

Figmaでは同一テキストパーツでも途中から別の文字サイズ、色を適用することが可能です。今回だと「糖質・脂質・塩分・野菜量など8項目の栄養基準」の部分はデザインだと「8項目の栄養基準」の部分のテキストサイズが大きく、テキストカラーも緑に変わっています。

しかし、MCPでデザインデータを取得するとその情報がLLMに渡す過程で欠落してしまいます。以下はMCPでのツール応答の該当箇所を抜粋したものです。Figmaとしてはoverrideしたstyle情報は持っているようですが、少なくともv0.2.1のFigma-Context-MCPではそのスタイリングには対応していなさそうです。

children:
  - id: '5414:5619'
    name: 糖質・脂質・塩分・野菜量など 8項目の栄養基準
    type: TEXT
    textStyle: style_S5EO4M
    fills: fill_WTN9RR
    layout: layout_8PK5H6
    text: |-
      糖質・脂質・塩分・野菜量など
      8項目の栄養基準
globalVars:
  styles:
    style_S5EO4M:
      fontFamily: Noto Sans
      fontWeight: 700
      fontSize: 14
      lineHeight: 1.3620000566755022em
      letterSpacing: 10%
      textAlignHorizontal: CENTER
      textAlignVertical: TOP
    fill_WTN9RR:
      - '#322012'

そこでこうしたデザインをLPに反映させるためにはテキストパーツ自体を分けて配置することで認識することができます。

Figmaの構成を修正してLPを再生成

これら2点を改善できるようにFigmaの構成を見直していきます。

  • section_titleで1つの画像にする
  • text_wrapper配下でそれぞれスタイルの違うテキストを配置

Figmaの最終構成は以下のようになります。

test3（Auto Layout）
└── nutrition（Frame）
    ├── section_title（Image）
    └── 栄養基準（Auto Layout）
        ├── Group 31（Group）
        │   ├── text_wrapper（Auto Layout）
        │   │   ├── 糖質・脂質・塩分・野菜量など（Text）
        │   │   └── 8項目の栄養基準（Text）
        │   └── Rectangle 25（Rectangle）
        ├── nutrition_ingredients_img（Image）
        └── ※上記に合わせて脂質(10~20g)、炭水化物(15~35g)の基準を設定（Text）

この状態で再度生成をしてみます。
生成された結果は、上部に無駄なpaddingが存在してしまっていますが、そこだけ消せば、再現度は高そうです。

カルーセル要素のあるLPデザイン構成でコード生成を試す

次にデザインもコードのスタイリングも複雑なカルーセル要素のデザインのコード生成を検証してみます。

Figmaの構成

Auto Layout機能を使って、menu_otherがカルーセルの要素として配置されています。

test5（Auto Layout）
└── Frame 74（Auto Layout）
    ├── その他のメニュー（Text）
    └── menu（Frame）
        └── Frame（Auto Layout）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            ├── menu_other（Frame）
            └── menu_other（Frame）

LP生成

LP生成をしてみます。

以下のfigmaのデザインを参照して、コーディングを行ってください。

@<figmaの該当セクションのURL>

生成されたLPをみてみるとそもそもカルーセルを認識できずに縦並びになっています。

意味のある要素名でコードの生成精度を高める

公式ドキュメントのBest PracticesでAuto Layoutと一緒に語られているのがFigma上での命名についてです。

Name your frames and groups - Protip: Try Figma's AI to automatically generate names

これは単純に名前をつければいいのではなく、LLMが生成するコードのhtml構造やスタイルが正しくなるようにその要素を適切に表した名前にしないといけないということです。 エンジニアであれば、変数やhtmlのclass名に対して気をつかうようにFigmaの要素に対する命名もコードの生成精度に関わってきます。

今回のカルーセルであればカルーセルの要素だとわかるように命名するのが望ましいでしょう。

test5（Auto Layout）
└── Frame 74（Auto Layout）
    ├── その他のメニュー（Text）
    └── menu（Frame）
        └── carousel_container（Auto Layout）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            ├── carousel_item（Frame）
            └── carousel_item（Frame）

命名だけの違いですが、LPを生成してみると以前と変わってカルーセル形式でのスタイリングが適用されます。ただし、2つの修正は必要になります。

  • item要素の画像の絶対値が認識できないのでitemごと画像化を検討
  • 両側のpadding要素を排除

その他: 安定したコード生成をするためのCursorルール

今回のこれらの検証で何度か繰り返し生成をしていると挙動が不安定なケースがあったので最低限のルールとして./cursor/rulesに以下を配置しました。

## ガイドライン
- get_figma_dataでは必ずnodeIdを指定してください。
- download_figma_imagesが失敗した場合は正しいJSON形式で画像のダウンロードを再度試みてください。
- 画像はbackground要素でない限り、html上でimgタグを使ってください。

get_figma_dataでは必ずnodeIdを指定してください。

何回か指示を出しているとたまに渡したURLのセクション情報を無視して、ファイル指定のみでfigmaのデザインデータを取得しようとします。ファイルにデザインデータが多いとcontext情報が多くてスタックしてしまうので、忘れないようにルールを入れています。

download_figma_imagesが失敗した場合は正しいJSON形式で画像のダウンロードを再度試みてください。

2025年4月27日時点では画像のダウンロードはかなり不安定で「invalid parameter」という形でエラーが頻出します。ダメもとにはなりますが、リトライを明確に指示出しすることで成功確率は少し上がりました。

画像はbackground要素でない限り、htmlのimgタグを使ってください。

たまにfigmaの画像をcssのbackground-imageとして全て参照してしまい、スタイルが大きく崩れることがありました。基本的にはimgタグを使って画像を配置しつつ、命名で background_*と書いてあるときだけはbackground-imageとして使ってもらうなど使い分けると良さそうです。

まとめ

まだまだ検証は足りないですが、こうしてFigmaのMCPを使ってみると現状では人間がデザインからコードを起こしているから大きな問題にならない部分でもAIに生成させるとなるとひと工夫必要なケースが多く見えてきました。
今後の業務で活用できるレベルまで到達するにはいかにAIやMCPに相性の良いFigmaのデザイン手法を見つけ、組み立てていけるかを1から考えることが大切になりそうなので、エンジニアもデザイナーもより自分たちの領域を超えて、コミュニケーションを取っていくべきでしょう。

こうした業務での活用に伴う検証は短期的に見れば、非効率で直接書いた方が早いと思う場面は何度もありました。しかし、ここで費やした労力が将来的な開発スピードの大きな差になってくると思うので、弊社では引き続き生成AIを積極的に活用した業務改善にチャレンジしていきます！

ぜひ、この取り組みに興味を持った方は一度カジュアル面談でお話しましょう！