Figma デザインから実装まで - Claude Code Skills によるUI自動生成の精度を劇的に上げる方法

2026年2月25日 16:52

本記事は株式会社BOOST Tech Blogの記事です。https://note.com/boost_jp/m/m9accace8769d

はじめに

AI に UI 実装を依頼したとき、こんなことが起きていませんか？

Figma のデザインを指定して AI に実装を頼むと一瞬で画面が出来上がりますが、確認すると想定と全然違う UI が出来上がっていて、色や余白がおかしいことが多々あります。結局、全部書き直したり細かく修正指示したりしているうちに数時間かかってしまい、AI に丸投げできるはずだったのに手戻りばかりで時間がかかった経験をした人も多いのではないでしょうか。

AI コーディングツールの登場で生産性は大きく向上しました。一方で、AI に丸投げするだけでは期待通りの結果が得られないケースもあります。本記事では Figma のデザインからコード生成を高精度で実現する Claude Code Skills について紹介します。

技術スタック・ツール

今回の記事を執筆するにあたって、検証した環境の技術スタック・ツールは以下の通りです。

Figma ※1
React / Next.js
Tailwind CSS
TypeScript
Claude Code（検証時：Opus 4.5）
Playwright

※1 公式ドキュメントでは Dev シートでも動作するとされていますが、検証時はうまく動作しなかったため、フルシートで実施しています。

問題の分析：AI が Figma 通りに実装できない理由

AI が Figma 通りに実装できない理由は、仮説として大きく 2 つあると考えています。

1 つ目は、コンテキストが大きすぎること。ページ全体や深いネスト構造を一度に実装しようとすると、AIが処理する情報量が多すぎて、親子関係や隣接する要素とのスタイル調整を適切に考慮できません。

2 つ目は、デザインの意図を汲み取れないこと。デザインをマークアップに変換する際の空間的な理解や、HTML/CSS がどのようにレンダリングされるかという認知力が低いためだと考えています。

※ 検証時は Opus 4.5 を使用しましたが、モデルの進化によって空間認知能力やコンテキストの問題が解決される可能性があります。

解決策：デザインとコードをつなぐ承認型の開発プロセス

これらの課題に対して、以下の2つの観点から解決アプローチを設計しました。

1. コンポーネントの分解・再利用による実装効率化とコンテキスト削減

コンポーネントの再利用

フロント実装時は、同じようなコンポーネント（Button、Inputなど）を毎回新規実装していては開発効率も上がらず、コンテキストは大きくなってしまいます。そのため、既存コンポーネントを確実に再利用できる仕組みが必要です。

どのように実現するか

(1) コンポーネント単位への分解と共通化

実装する UI をコンポーネントに分解し、既存のコンポーネントなのか、新規に実装が必要なコンポーネントなのかを判断して既存コンポーネントであれば再利用します。

(2) 一意性の確保でAIが同一コンポーネントを認識

AI が一意に判別できる形でコンポーネント情報を提供し、既存コンポーネントの再利用を可能にします。

具体的には、各コンポーネントファイルに Figma のコンポーネントを判別できる情報 (IDのようなもの) を記載しておくことで、AI は「このデザインは既に実装済み」と判断でき、詳細な取得をスキップできます。

また、複数のページで同じコンポーネント（例：Button）を使用する場合は、Figmaで元のコンポーネントから「インスタンス」として配置してください。これにより、元のコンポーネントへの参照情報が保持され、MCPが「このボタンは既存のButtonコンポーネントと同じもの」と判定できるため、既存実装を再利用できます。

実装方法は後述の「コンポーネントの一意特定とコンテキスト削減」で説明しますが、以下のイメージです。

こうすることで実装範囲を新規コンポーネントのみに限定でき、以下の効果が得られます。

コンテキスト量の削減に伴い、コンテキスト過多によるAIの精度低下を抑制
AIは新規コンポーネントの実装と、コンポーネントツリーの設計に集中できる

今回は Figma を利用していますが、自身のプロジェクトで利用するデザインツールに合わせてコンポーネントを一意に判断できる方法を見つけると良いと思います。

2. 人が確認・承認できるポイントを設計する (Human in the loop)

解決手法：実装前の計画レビューフロー

実装に進む前に、AI が生成した実装計画を人がレビュー・承認するチェックポイントを設けます。

具体的には、生成された実装計画を人がレビューし承認することで、AI が苦手な空間認知や構造設計の部分を人がカバーします。実装計画に含まれる実装詳細やコンポーネントツリーを確認し、デザインの意図を汲み取れていない場所があれば計画を修正させることで最終的な実装の品質が向上します。

これは AI 開発のベストプラクティスとして広く認識されており、Claude Code の公式ドキュメントでも「Explore first, then plan, then code」として、Plan モードで調査・計画を立てて人間の確認・承認を得てから実装に進むワークフローが推奨されています。

手法：Figma からコードの自動生成フロー

ここまで説明した2つの観点を、Claude Code の Skill として具体化しました。本セクションでは、中心となる自動生成 (/figma-to-code) スキルの仕組みとワークフローを紹介します。

具体的には以下の図のように、Figma URL（node-id を含む）を AI に渡して Figma MCP 経由でデザイン情報を取得し、既存コンポーネントの再利用判定と実装計画の生成、そして実装を行うようにします。

以下スキルの一部を抜粋したものと、スキル全体の url を添付してます。

# UI デザイン要件定義と実装

Figma デザインから UI コンポーネントの要件定義を行い、実装を支援するスキルです。

## 実行フロー

### Phase 1: 情報収集

以下の情報をユーザーに記入・選択させる

1. Figma の URL（node-id を含む）を確認

### Phase 2: 既存コンポーネントの確認

1. `/components/ui/` 配下のコンポーネントファイルを読み取り
2. 各ファイルの先頭コメントから Figma 情報（fileKey, node-id）を抽出
3. 新規追加する Figma ノードの情報と照合し、同一コンポーネントを特定
4. Figma 情報がないコンポーネントは、名前やプロパティから再利用可能性を判断

### Phase 3: Figma デザイン情報の取得

**新規コンポーネントのみ詳細取得**：

1. **URL から node-id を抽出**
   - URL パターン: `https://figma.com/design/:fileKey/:fileName?node-id=X-Y`
   - node-id 部分を抽出（例: `node-id=11-3265` → `11:3265`）

2. **既存コンポーネントで対応可能か判断**
   - 既存の `/components/ui/` で対応可能 → 名前とパスのみ記録

3. **Figma MCP ツールでデザイン情報を取得**（新規コンポーネントのみ）

### Phase 4: 実装方針の提案

以下の情報を含む実装方針を **ExitPlanMode ツール** で提案し、ユーザーの承認を待ちます：

#### 提案内容

1. **コンポーネント構造（ツリー形式）** [**最重要**]
   - 全コンポーネントを階層構造で表示
   - 各コンポーネントに（既存）または（新規）のラベルを付ける
   - 例:
     ```
     ページ名
     ├── Header（既存活用）
     │   ├── Logo（新規）
     │   └── Navigation（既存）
     └── Content
         ├── Card（既存）
         │   ├── CardTitle（既存）
         │   └── CustomIcon（新規）
         └── Footer（新規）
     ```

2. **既存コンポーネント活用リスト**
   - コンポーネント名、ファイルパス、用途

3. **新規作成コンポーネントリスト**
   - `/components/ui/` 配下（汎用・Storybook 必須）
   - `/app/components/` 配下（ページ固有）
   - アイコンやユーティリティ

4. **実装手順**
   - Phase 単位で段階的な実装計画

#### ⚠️ 重要な注意事項

**ExitPlanMode の plan パラメータには、上記の詳細なツリー構造を省略せずにすべて含めること。**
簡略化や要約は禁止。ユーザーが全体像を把握できるよう、完全な情報を提供すること。

### Phase 5: 実装

承認後、以下の順序で実装：

1. **TodoWrite ツールでタスク管理**
2. **コンポーネント実装**
   - Figma デザインをもとに実装
   - 既存パターンを踏襲
3. **Storybook ファイル作成**（/components/ui/ のみ）
   - 各コンポーネントの `.stories.tsx` を作成
4. **型定義作成**
   - proto ファイルがある場合は参照
5. **既存コードへの統合**
6. **完了報告**

## 配置ルール

| ディレクトリ | 対象 | 例                           | Storybook |
|-------------|------|-------------------------------|:----------|
| `/components/ui/` | Figma ライブラリから取り込んだコンポーネント | Button, Input, Messaging, Tag | 必須 |
| `/components/icons/` | Figma ライブラリの icon コンポーネント | Check, ChevronDown, TriangleAlert, X | 任意 |
| `/app/components/pages/` | ページごとに固有のコンポーネント | MemberCard, ProjectList       | 不要 |

**判断基準**：
- Figma ライブラリから取り込んだものは `/components/ui/`
- Figma ライブラリの icon は `/components/icons/`
- ページ固有の実装は `/app/components/pages/`

コンポーネントの一意特定とコンテキスト削減

コンポーネントの一意特定の仕組み

/figma-to-code スキルの重要なポイントは、Figma URL に含まれる情報を使ってコンポーネントを一意に特定することです。

Figma の URL は以下のような構造になっています。

https://figma.com/design/:fileKey/:fileName?node-id=X-Y
                        ^^^^^^^^              ^^^^^^
                        ファイルを識別          ノードを識別

この URL から抽出できる fileKey と node-id を組み合わせることで、「どのFigmaファイルの、どのコンポーネント」なのかを一意に特定できます。

各コンポーネントファイルの先頭には fileKey と node-id を含むような以下の Figma 情報を記載しておきます。

/**
 * Figma Information:
 * URL: https://www.figma.com/design/ABC123/MyDesign?node-id=11-3265
 * fileKey: ABC123
 * node-id: 11-3265
 */
export function Button({ children, variant = 'primary' }) {
  // ...
}

この情報があることで、AI は「この Figma ノードは既に Button コンポーネントとして実装済み」と即座に判断できます。

コンポーネント再利用の判定ルール

fileKey + node-id が一致 → 既存コンポーネントを再利用
Figma情報がない場合 → コンポーネント名やプロパティから類似性を判断

コンテキスト削減の効果

例えば、以下のような複数コンポーネントを組み合わせた UI を実装する場合を考えます。

ProductCard
├── ProductImage
├── ProductInfo
│   ├── Title
│   ├── Price
│   └── Rating（既存：components/ui/rating）
├── Button（既存：components/ui/button）
└── WishlistIcon（既存：components/icons/heart）

従来のアプローチでは、AI は既存の Rating、Button、WishlistIcon などのコンポーネントのデザイン詳細（色、サイズ、余白、状態バリエーションなど）もすべて Figma から取得し、コンテキストに含める必要がありました。

/figma-to-code スキルでは、fileKey + node-id で既存コンポーネントを特定した場合、そのコンポーネントの配下要素の詳細取得をスキップします。AI は「既存の Button を使う」という情報だけを保持すればよく、Button 内部の実装詳細は不要になります。

これによりコンテキスト量の削減と、コンテキスト過多による AI の精度低下を抑制することができます。AI は新規コンポーネントの実装と、コンポーネントツリーの設計に集中することができるようになります。

生成される Plan 例

以下、スキル実行後に実際に生成される Plan の重要部分だけをスクショした画像を添付します。

上から順に、以下の 3 つのセクションで構成されています。

コンポーネント構造ツリー：全コンポーネントを階層構造で表示し、「既存」「新規」のラベルで一目で把握できます
既存コンポーネント活用リスト：再利用するコンポーネントのファイルパスと用途を一覧化します
新規作成コンポーネントリスト：新規実装が必要なコンポーネントのファイルパスと props の概要を提示します

人がレビューするのはこのツリー構造が中心です。コンポーネントの親子関係や既存コンポーネントの再利用判断など、AI が苦手な空間認知の部分を承認ステップで人がカバーします。承認後、AI は Plan の内容に従って実装を進めるため、実装フェーズでの手戻りを大幅に削減できます。

まとめ

これまで、AI が Figma 通りに実装できない課題と、その解決策について紹介してきました。

/figma-to-code スキルによる設計・承認フローを導入することで、AI が苦手な空間認知や構造設計の部分を人がカバーしつつ、コンポーネントの一意特定によるコンテキスト削減で AI の精度を向上させることができました。

このアプローチは Claude Code に限らず他の AI ツールでも応用でき、利用するデザインツールに合わせてコンポーネントを一意に特定できるデザイン情報を AI が認知できるようにできれば、デザイン通りの UI 実装が可能になると思います。

この環境に興味を持った方へ

BOOST では、Claude Code や Gemini などの AI ツールを活用して高速な開発体制を実現し、本記事で紹介した Claude Code Skills も試行錯誤を重ねながら開発に取り込んでいます。AI を最大限に活用することで、プロダクト開発に集中できる環境を整えていますので、興味をお持ちの方はぜひ BOOST で一緒に働きませんか。

補足：デザイン変数の同期

Figma の実運用では Tokens が使われることが多い

フロントエンド開発では、色やスペーシングなどのデザイン値を Token（定数）として定義し、コンポーネントで変数として注入するケースが多いと思います。色や数値を直接ハードコードすることでデザインを実現することもできますが、マジックナンバー問題やデザインの一貫性に課題があります。

Figma を利用している場合は Variables 機能があり、色・余白・フォントサイズなどを「変数」として定義できます。例えば Primitive/Red/100 に #F9D5D8 を設定し、Semantic/Border/Container/danger から変数 (=Primitive/Red/100) を参照するような設定が可能です。この Variables をコード側（Tailwind CSS など自分たちの利用する CSS フレームワーク）に同期することで、マジックナンバー問題を解決し、デザインシステムとして一貫性のある実装が可能になります。

Figma MCP を使う上での注意

/figma-to-code を実行した際、Figma MCP が生成するコードの形式は、Figma で Variables（Tokens）を使用しているかどうかで異なります。

Tokens が利用されている場合は、Tailwind CSS の任意値記法で CSS 変数が埋め込まれます。

<Button className="text-[var(--semantic/textandicon/component/enabledbutton,#5774D8)]">
  購入する
</Button>

Tokens が利用されていない場合（直接色や数値を指定）は、style 属性としてインラインスタイルで出力されます。

<Button style={{ backgroundColor: "#A3B5EC" }}>
  購入する
</Button>

Tokens の利用の有無にかかわらず、Figma MCP 経由で UI を実装させる際には以下のような課題が発生します。

text-[var(--semantic/textandicon/component/enabledbutton,#5774D8)] や #A3B5EC を見ても、どんな UI になるか想像しにくい
--semantic/textandicon/component/enabledbutton は事前に CSS ファイルに定義しておかないと利用できない
IDE による Tailwind Class の補完が効かない

Tokens の同期スキルで解決

これらの課題に対して、Tokens を同期するスキル (/sync-design-tokens) を作成しました。このスキルを利用することで、Export/Import Variables プラグインでエクスポートした Figma Variables の JSON ファイルを Tailwind の拡張として自動変換し、Figma で定義されたデザイントークンを Tailwind クラスとして直接利用できるようになります。

生成されるコード例

実行すると以下のようなコードが生成されます。

globals.css：

Figma Variables で定義された色のデータを RGB から HSL 形式に変換します。

@layer base {
  :root {
    --semantic-textandicon-component-enabledbutton: 220 13% 46%;
    /* ...その他のデザイントークン */
  }
}

tailwind.config.ts：

CSS 変数を Tailwind でエイリアスとして利用できるようにします。

const config: Config = {
  theme: {
    extend: {
      colors: {
        semantic: {
          textandicon: {
            component: {
              enabledbutton: "hsl(var(--semantic-textandicon-component-enabledbutton) / <alpha-value>)",
            },
          },
        },
      },
    },
  },
}

使用例：

Figma で Semantic/TextAndIcon/Component/EnabledButton の変数に設定された色が、text-semantic-textandicon-component-enabledbutton として Tailwind クラスで利用できるようになりました🎉

<Button className="text-semantic-textandicon-component-enabledbutton">
  購入する
</Button>

このデザイン変数の同期スキルを実行した後の /figma-to-code スキルによって提案される実装計画では Tailwind の任意値記法やマジックナンバーが利用されることはなくなり、必ず tailwind.config.ts に同期された Tailwind Class を利用してくれるようになりました。

デザイン同期スキル (/sync-design-tokens) の url を添付していますので、興味があれば確認してみてください。