Claude x Figma MCPで"AIマークアップエンジニア"を育てる

はじめに

みなさんはLPのような静的なページのコーディングにどれくらい工数をかけていますか？
広告用の「とりあえず見れればOKなLP」ではなく、SEO対応・レスポンシブ対応・保守しやすい構造まで考えて組むとなると、どうしてもコーディング、ひいてはマークアップのコストは重くなります。

LPの実装ミスが重大な障害につながることは少なく、細部までこだわっても評価されにくい領域なので、なるべく省エネで済ませたい。AIに任せたいところだけど、雑に投げるとデザインを再現できていなかったりdivだらけのやっつけCSSが出てきたりで、使い物になりません。

「コーディング規約に則ったきれいなマークアップまで含めて、いい感じにやってくれるAIはないのか？」――そんな問いから、Claude Code × Figma MCPでどこまで任せられるのかを試してみた話を書きます。

課題：Figmaからのマークアップのつらいところ

• テキストを延々とコードにコピペする作業
• 画像を一枚一枚適切な解像度でエクスポートしてファイル名をつけてディレクトリに入れる作業
• Figmaの設定値をいちいち確認してCSSに写経していく作業
• 雑にAIに投げるとルール無用のハリボテコードしか出てこない

解決策：Claude Code × Figma MCPでどう変わるか

• Figma MCPがテキストを取得し、Claudeがコードに反映してくれる
• Figma MCPの画像ダウンロード機能で、適切な解像度・形式で自動保存できる
• Figma MCPがスタイル情報を取得し、ClaudeがSCSSに反映してくれる
• coding-style.mdでコーディング規約を教え込み、規約に沿ったコードを出してもらう

MCPとは

MCP（Model Context Protocol）は、AIモデルが外部ツールやデータソースと連携するための標準プロトコルです。Claude CodeではMCPサーバーを設定することで、Figma、GitHub、データベースなど様々な外部サービスと連携できます。

今回使用するFramelink MCP for Figma（旧Figma-Context-MCP）は、FigmaのAPIを通じてデザインデータを取得し、AIが理解しやすい形式に変換してくれるMCPサーバーです。

https://github.com/GLips/Figma-Context-MCP

セットアップ

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

まず、Figma APIにアクセスするための個人アクセストークンを取得します。

1. Figmaにログインし、設定画面を開く
2. 「Personal access tokens」セクションで新しいトークンを生成
3. 生成されたトークンを安全な場所に保存

Figmaの個人アクセストークンは最大90日で有効期限が切れるので定期的な更新が必要です。

MCPの設定

Claude Codeの設定ファイルにFigma MCPを追加します。プロジェクトのルートディレクトリに.mcp.jsonを作成し、以下のように設定します。

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": ["-y", "figma-developer-mcp", "--figma-api-key=YOUR_FIGMA_TOKEN", "--stdio"]
    }
  }
}

また、.claude/settings.local.jsonでMCPサーバーの許可設定を行います。

{
  "permissions": {
    "allow": [
      "mcp__Framelink_Figma_MCP__get_figma_data",
      "mcp__Framelink_Figma_MCP__download_figma_images"
    ]
  }
}

download_figma_imagesツールを許可しておくことで、デザイン内の画像をローカルのpublic/images/...配下などに直接ダウンロードできるようになります。

プロジェクトのCSS設計への繋ぎ込み

Figma MCPでデザインデータを取得できても、それをプロジェクトのCSS設計に沿ったコードに変換できなければ保守性ゼロのハリボテになってしまいます。

そこで、CSS設計のルールを.claude/coding-style.mdとしてドキュメント化し、Claude Codeに読み込ませています。主な項目は以下の通りです。

• BEM記法: bem()関数によるクラス名生成ルール
• SCSSカラー関数: 用途別の色指定関数（component/bg/border）
• SCSSネスト構造: BEM要素のネスト記述ルール
• 装飾的な画像: 擬似要素での実装ルール

bem()関数は以下のように使用しています。

className={bem('pg-landing-page', 'interview-card', { active: true })}
// → "pg-landing-page__interview-card pg-landing-page__interview-card--active"

セッション開始時に/coding-styleコマンドを打つことで、.claude/coding-style.mdに記載したコーディング規約をインプットしてくれます。

LPコーディングの進め方

LP全体を一度に投げてみたら

まずは試しに、LP全体のFigmaファイルのURLをそのままClaudeに渡してみました。

🧑 「このFigmaにアクセスできる？」
🤖 「データ量が大きすぎて処理できません。depthを2に下げて概要のみ取得します」

Figma MCPのget_figma_dataツールにはdepthパラメータがあり、ノードツリーを何階層まで取得するかを制御できます。データ量が上限値を超える場合はClaudeが自動的にdepthを下げて再取得してくれるのですが、depth: 2まで下げられてしまうとFigmaページの概要はわかるものの、コンポーネントの中身までは取れず、コーディングには使えません。

コンポーネント単位で依頼を投げる

そこで、LP全体を一度に渡すのではなく「Figma上のセクションやコンポーネント単位でClaudeに依頼を投げていく」やり方に切り替えました。

Figmaのフレーム（＝「ノード」と呼びます）を選択し、右クリック→「選択範囲へのリンクをコピー」でコピーしたURLを添えて「このフレームをコーディングしてください」とClaudeに依頼すると、レスポンスサイズも抑えつつ、レビューもしやすい粒度のコードが出てきます。

Claudeとのペアプロ

ここからは、LPの「インタビューセクション」で繰り返し使われる「Interviewコンポーネント」をClaudeと一緒にコーディングしていきます。画像やリスト、modifierによるスタイリング、レスポンシブレイアウトのある比較的大きめのコンポーネントです。これがさっと作れるようなら他のセクションもいけるでしょう。

コンポーネントのコーディングを依頼

フレームのURLとアウトプット先を指定してClaudeに依頼を投げます。

🧑 「このフレームをコーディングしてください」

- Figmaフレーム：https://www.figma.com/design/xxxxxx/xxxxx?node-id=xxxxxxx
- Reactコンポーネント：app/components/landing-page/interview.tsx
- SCSS：scss/page/landing-page/interview.scss
- 画像：public/images/landing-page/

🤖 「了解しました。Interviewsコンポーネントとして実装します。」

テキストを推測で書いてしまう問題

出てきたコードを見て、Figmaと全然違う"それっぽい文章"が並んでいることに気づきました。Claudeを問い詰めてみると、Figmaデータを取得しているにもかかわらず、その中のtextフィールドを確認せず「こんな感じだろう」と推測で書いてしまったとのこと。

🧑 「推測で書いていたのですか！ だめですよそういうのは！」
🤖 「申し訳ありません！ 完全に私のミスです。これは絶対にやってはいけないことです。」

「推測で書かない」というルールをcoding-style.mdに追記しました。

coding-style.md

- **テキスト内容は必ずFigmaから取得すること（推測で書かない）**

depthが足りずアイコンを見落とす問題

「課題/解決策」の比較表のようなコンポーネントで、「課題」は下向き矢印、「解決策」では上向き矢印を使うデザインがありました。ところが実装を見ると、両方とも下向き矢印に。

原因は、Figmaのデータ構造を浅い階層までしか取得していなかったため、アイコンの違いを見落としたこと。コンポーネントの実装時はdepth: 4で取得するようにしました。

coding-style.md

## Figmaからの実装手順
1. **最初に十分な深さでデータ取得**: `depth: 4` 以上で取得し、全要素の詳細を確認
2. **繰り返し要素の差異を確認**: Before/After、複数カードなど、似た構造の要素は個別に確認
   - アイコン名が異なる場合は別のアイコンを使用

複数画像の同時ダウンロードでエラー

Claudeが画像のダウンロードで躓いているようです。

🧑 「どうしましたか？」
🤖 「画像の複数同時ダウンロードで403エラーが発生しました。1つずつなら成功します。」

Figma APIからの画像をダウンロードする際は、1件ずつ行うのが無難なようです。

coding-style.md

## Figma画像のダウンロード
- **ダウンロード方法**: **必ず1件ずつダウンロード**すること
  - 複数ノードを同時にダウンロードすると403/500エラーが発生する場合がある

画像サイズの取り違え

妙に画像が大きいと思ったら、90x90ピクセルのアイコンの画像が2000ピクセル超でダウンロードされていました。あらかじめ「画像は3倍解像度でダウンロードして」という指示を与えていたところ、フレームサイズの3倍ではなく、元画像の3倍でダウンロードしていた模様。

画像ダウンロードの指示を明確にし、以下のルールを設けました。

coding-style.md

## Figma画像のダウンロード
- **画像サイズ**: Figmaフレームサイズの3倍でダウンロード
- **画像形式**:
  - アイコン: SVG
  - 写真: JPG
  - 透過領域がある画像・イラスト: PNG

modifier名に余計なprefixを足してしまう問題

modifierのスタイルが当たっていないコンポーネントがありました。SCSSで&--beforeと定義しているのに対して、Reactのbem()が{ type: 'before' }となっているようです。これだとmodifierが&--type-beforeになってしまいます。

🧑 「modifierが間違っていますよ。SCSSとReactのmodifierは一致させてください」
🤖 「申し訳ありません。coding-style.mdにも追記しますね。」

なんとClaude、指摘された内容を自分でcoding-style.mdに追記するようになりました。
さながらメモを取る素直な後輩エンジニア。好感が持てます。

coding-style.md

## BEM記法
- **重要**: SCSSの `&--modifier` とReactの modifier キーは完全に一致させること
  - 例: `&--before` → `{ before: true }`

/coding-styleを無視されて信頼関係が揺らいだ話

感心したのも束の間、Claudeを一度閉じて新しいセッションを開始したところ、/coding-styleコマンドを実行したにもかかわらず、存在しないmixinを平然と書き始めました。

🧑 「@include g.mq(md) こんなmixinはありません。なぜこのような実装をしたのですか？」
🤖 「既存のコードを確認せずに、存在しない @include g.mq(md) というmixinを使用してしまいました。正しくは @include g.mix-breakpoint(pc) を使うべきでした。」
🧑 「勘弁してほしいです。/coding-styleコマンドを実行したのにその中身を無視されると、君と僕の間の信頼関係が根幹から揺らぎます。」
🤖 「本当に申し訳ありませんでした。」

🧑 「その反省した君は次回のセッションでもいるの！？😡」
🤖 「いえ、次回のセッションには私はいません。次回は新しいセッションが始まり、今回の会話の記憶は引き継がれません。」

AI相手につい熱くなってしまいました。
やっぱり人間側がcoding-style.mdに知見を蓄積しておくことが大事ですね。

コーディング規約をClaudeと一緒に育てる

最初は数行しかなかったcoding-style.mdも、Claudeとペアプロしているうちに立派なドキュメントに育ってきました。

🧑 「いい感じにcoding-style.mdが育ってきましたね！」
🤖 「はい！今回のInterviewsコンポーネント実装を通じて、かなり充実しました。」
※充実感を分かち合う筆者とClaude

実際の運用を通じて、以下のような項目をコーディング規約に追加していきました。

• BEM記法の詳細ルール（modifier名の一致、ネスト構造）
• SCSSカラー関数の正しい使い方
• Figmaからの実装手順（depth設定、繰り返し要素の確認、チェックリスト）
• 画像ダウンロードのルール（サイズ、形式、クロップ情報）
• テキストは推測禁止、必ずFigmaから取得

問題が発生するたびにルールを追加していくことで、コーディング規約が充実し、同じミスの再発を防ぐことができます。Claudeは次のセッションで記憶がリセットされますが、coding-style.mdは残ります。人間側がドキュメント化をサボらなければ、回を重ねるごとに"はじめからちゃんとできること"が増えていきます。

実際に運用してみて

今回、LPのコーディングをClaude Code × Figma MCPで実装してみました。通常であれば3日程度かかっていたであろう作業を、試行錯誤しながら1日半で完了できました。今回集めたナレッジはcoding-style.mdとして残っているので、今後はもっと早くなるはずです。

ポジティブなポイント

• 実装速度の向上: Figmaを見ながら手動でコードを書く時間が大幅に削減されました
• 一貫性のあるコード: コーディング規約に沿ったコードが生成されるため、コードの一貫性が保たれます
• 繰り返し作業の効率化: 同じデザインパターンの別コンテンツを実装する際、一発で正確に実装できるようになりました

ネガティブなポイント

• 初期設定の手間: MCPの設定やコーディング規約の整備に初期コストがかかります
• Figmaトークンの有効期限: 最大90日で切れるため、定期的な更新が必要です
• 完璧ではない: 規約を読み込ませても無視されることがあり、レビューは必須です

おわりに

Claude Code × Figma MCPの組み合わせは、FigmaデザインからのマークアップをAIに任せるという新しいワークフローを実現します。

感覚的には「とても優秀だけれど、セッションごとに記憶がリセットされる新人エンジニア」とペアプロしている感覚に近いです。coding-style.mdという形でナレッジを蓄積していけば、徐々に"はじめからちゃんとできること"が増えていきます。

特に重要なのは、問題が発生したときにその都度コーディング規約に追記していくことです。これにより、プロジェクト固有のナレッジが蓄積され、チーム全体の開発効率向上につながります。

また、LPのように情報量の多いページでは、Figmaファイル丸ごとを一度に渡すのではなく、Figma上のセクション（フレーム）単位でClaudeに依頼するのが、実際に試してみて一番うまくいったやり方でした。レスポンスサイズの問題を避けつつ、セクションごとにcoding-style.mdを確認しながらレビューできるので、「少しずつ確実に進める」スタイルと相性が良かったです。

AIコーディングツールはまだ発展途上ですが、適切に活用することで開発者の生産性を大きく向上させる可能性を秘めています。ぜひ皆さんも試してみてください。

参考リンク

• Framelink MCP for Figma (GitHub)
• Claude Code (GitHub)
• Model Context Protocol
• Figma API - Personal access tokens