⟐ Claude Code/2026-04-04上級

Claude Code + Figma MCP 実装ガイド：AIデザインツール連携で個人制作を自動化する

Stitch・Figma Make・Claude Code を組み合わせたプロ実践ワークフローの全手順。Design.md の体系化、Figma MCP の詳細仕様、コンポーネント自動生成の最適化まで解説します。

Claude Code²⁴² Figma MCP デザイン自動化 Design-md advanced⁹

✦ プレミアム記事

Figma のデザインを Claude Code に渡すと、そのままコンポーネントが立ち上がってくる。初めてそれが成功した夜のことを、今でもよく覚えております。嬉しさで胸が熱くなった一方、その後の数週間で気づいたのは「最初の生成が動くこと」と「運用に耐えること」は別物だという事実でした。

個人開発でいくつものアプリと複数のサイトを一人で回していると、デザインと実装の往復に費やす時間が、そのままリリース速度の上限になります。だからこそ Figma MCP を腰を据えて使い込んできました。

その過程で見えてきた仕様の境界、Design.md の設計、そして運用してみて初めてわかった落とし穴を、私が計測した実測値とともにここへ書き残します。公式ドキュメントの要約ではなく、私自身が手を動かして掴んだ勘所を、そのままお渡しできればと思います。

Figma MCP の詳細仕様

Figma MCP は Claude Code が Figma デザインを「読める」プロトコルです。しかし「何が読めて、何が読めないか」を正確に理解することが、スムーズな自動生成の第一歩です。

Figma MCP が取得できるデータ

Claude Code が Figma から自動的に受け取れる情報は以下の通りです。

1. レイヤー構造（Hierarchy）

{
  "id": "1:2",
  "name": "Button Primary",
  "type": "component",
  "parent": "3:4",
  "children": [
    {
      "id": "5:6",
      "name": "Icon",
      "type": "icon"
    },
    {
      "id": "7:8",
      "name": "Label",
      "type": "text"
    }
  ]
}

Figma ファイル内の全レイヤー、グループ、コンポーネントが JSON で表現されます。これが React コンポーネントの粒度決定に直結します。

2. デザイントークン（Design Tokens）

カラー: RGB 値、16 進数表記、変数参照（Figma Variables）
タイポグラフィ: フォント名、ウェイト、サイズ、行高、文字間隔
間隔・サイズ: パディング、マージン、ボーダー幅、コーナー半径
シャドウ・エフェクト: X オフセット、Y オフセット、ぼかし度、色

これらは Tailwind CSS のクラス、または CSS 変数として自動マッピングできます。

3. コンポーネント定義（Component Metadata）

コンポーネント名（スラッシュ区切り、例: Button / Primary / Large）
プロパティ（variant, size, disabled state など）
各プロパティの選択肢（enum 値）
デフォルト値

{
  "componentName": "Button / Primary",
  "properties": {
    "size": {
      "type": "enum",
      "options": ["small", "medium", "large"]
    },
    "state": {
      "type": "enum",
      "options": ["default", "hover", "active", "disabled"]
    }
  }
}

これが TypeScript interface の自動生成を可能にします。

4. アニメーション＆Interaction

Figma の Prototype 機能で定義したインタラクション（click → color transition など）も JSON で表現されます。Claude Code はこれを CSS animation または framer-motion で実装します。

Figma MCP が読めない・読みにくいデータ

逆に、以下は MCP では取得できません：

画像アセット本体: Base64 エンコードは可能ですが、参照URLとして扱うべき
複雑な mask や blend mode の完全な再現: CSS では表現困難な効果は手動調整が必要
カスタムプラグイン内のデータ: プラグイン固有の情報は MCP を通さない
Figma 外部ツール（Stitch からのインポート等）のメタデータ: 構造化情報は Design.md に明示的に記録する必要がある

重要な心構え：MCP は「完全な自動化」ではなく「初期生成の大幅な短縮」です。複雑な効果や高度なカスタマイズは、生成後の手動調整で仕上げるという前提で進めます。

接続そのものでつまずいたときの確認順序

仕様を押さえていても、そもそも Claude Code が Figma に届かなければ始まりません。私はこの入口で何度か止まりました。私が実際に踏んだ順に、確認すべき箇所を残しておきます。

症状	原因	対処
ツール一覧に Figma が現れない	Dev Mode MCP サーバーが未起動	Figma デスクトップアプリの設定から MCP サーバーを有効化する（ブラウザ版では動きません）
接続はあるのに「デザインを取得できない」と返る	URL に node-id が含まれていない	フレームを選択して「選択範囲へのリンクをコピー」した URL を渡す
取得結果がほぼ空	シート権限の不足	Dev Mode の利用には有償シートが前提。閲覧のみの招待では中身まで届きません

この構成はローカルで動く Figma デスクトップアプリを経由するため、アプリを閉じている時間帯は何も取れません。手元で対話的に使っている間は意識しませんが、生成を自動化の一部に組み込んだ途端、この「アプリが起きていること」という前提を忘れて詰まりました。夜間バッチにデザイン取得を含めたい場合は、事前に JSON をエクスポートして渡す構成に切り替えるほうが安定します。

生成品質は Figma 側の作り方で決まる

MCP の仕様を把握したあと、私が一番時間を投じたのは Claude Code 側のプロンプトではなく、Figma 側の整え方でした。同じ画面でも、レイヤーの組み方ひとつで生成物の質がまるで変わる。それに気づいたとき、手が止まりました。

渡す前の 15〜20 分。ここが効きます。

レイヤーを「役割の名前」で呼ぶ

Frame 123 や Group 45 のまま渡すと、生成されるコンポーネント名も意味を失います。HeroSection・PricingCard・NavigationBar のように役割で命名しておくと、コンポーネント名もクラス名も、そのまま読めるものになりました。

レイヤー名は Claude Code に届く最短のドキュメントです。

繰り返す要素は Figma コンポーネントとして切り出す

ボタン、カード、ヘッダー。二度以上現れる要素を Figma コンポーネントとして明示しておくと、Claude Code はそれを React コンポーネントとして分離してくれます。コンポーネント化していない要素は、同じ見た目でも別々のマークアップとして重複生成されがちです。

Atoms → Molecules → Organisms の粒度を Figma 側で先に決めておく。その手間が、あとの重複排除にかかる時間を丸ごと消してくれます。

絶対座標をやめてオートレイアウトにする

4 つの中で最も効果が大きかったのがこれでした。

Figma 側の指定	生成されるコード	画面幅を変えたとき
絶対座標（x, y 固定）	position: absolute・固定 px	崩れる（手直し必須）
オートレイアウト	Flexbox / CSS Grid	そのまま追従する

オートレイアウトで組んだ画面は、レスポンシブの手直しがほとんど要りません。絶対座標のまま渡した画面は、生成後にレイアウトを書き直すことになり、自動生成した意味が薄れました。

見た目に出ない仕様はアノテーションに書く

ホバー時の opacity、スクロール連動のフェードイン。静止画には映らない挙動は、Figma のアノテーションで明示します。

Design.md の「Animation & Motion」が値の出どころなら、アノテーションは「どこに適用するか」の出どころです。この 2 つが揃って初めて、インタラクションが仕様どおりに生成されます。

整えた場合とそうでない場合の差

観点	整えたデザイン	整えていないデザイン
コンポーネント再利用	Figma の階層どおりに分離される	同じ見た目が複数回インライン展開される
レスポンシブ	Flexbox / Grid で追従	固定 px で崩れる
命名の一貫性	役割名がそのまま反映される	Frame1・Group2 が残る
生成後の手直し	微調整のみ	構造から書き直し

渡す前の 15〜20 分で、生成後の数時間が消える。私にとってこれは、Figma MCP を使ううえで最も投資対効果の高い工程でした。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Figma MCP が取得できる/できないデータの境界を JSON 実例で把握し、手動調整が必要な箇所を先に切り分けられる

✦Design.md を唯一の真実として設計し、色・タイポ・余白の変更を Figma とコードへ波及させる同期ルールを組める

✦個人開発での実測（初期生成 20〜30 秒・更新往復 2〜3 時間→15〜30 分）をもとに、どこを自動化しどこに人手を残すかの判断軸を持てる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

Design.md：デザインシステムの中枢

Stitch から始まった設計案は、Design.md で「システム化」されることで、初めて再利用性と保守性を持つようになります。

Design.md の構造（実務レベルの構成）

実務レベルの Design.md は以下のような構成を持ちます：

1. Color Tokens

Token Name	Hex Code	RGB	Usage
primary-50	#EBF8FF	rgb(235, 248, 255)	背景
primary-500	#3B82F6	rgb(59, 130, 246)	CTA・見出し
primary-900	#1E3A8A	rgb(30, 58, 138)	テキスト・枠線

2. Typography System

Role	Size	Weight	Line Height	Usage
H1	48px	700	1.2	ページタイトル
H2	32px	700	1.3	セクション見出し
Body-Large	16px	400	1.6	本文
Body-Small	12px	400	1.5	キャプション

3. Spacing Scale

8px (s) | 16px (m) | 24px (l) | 32px (xl) | 48px (xxl)

4. Component Specifications

Button の例：

variant: primary / secondary / ghost
size: sm (32px) / md (44px) / lg (56px)
states: default / hover / active / disabled
Padding: 12px 24px (md)、Border-radius: 8px

5. Layout Grid

Desktop: 12列、gap 24px、max-width 1200px
Mobile: 4列、gap 16px、full-width

6. Animation & Motion

Fast (150ms): ホバー状態
Normal (250ms): 遷移・状態変化
Slow (400ms): 入場・出場アニメーション
Easing: cubic-bezier(0.4, 0, 0.2, 1)（デフォルト）

7. Responsive Breakpoints

xs: 320px | sm: 640px | md: 768px | lg: 1024px | xl: 1280px

8. Change Log

### v1.2.0 (2026-04-04)
- 追加: ダークモード色スケール
- 変更: Button padding 12px 24px → 14px 28px

### v1.1.0 (2026-03-15)
- 追加: Input エラーステート仕様

Design.md と Figma の同期戦略

Design.md が「真実の源」であり、Figma はその「ビジュアル実装」という関係です。

同期ルール：

カラーコード変更 → Design.md を更新 → Figma の全コンポーネントに適用
新しいコンポーネント追加 → Design.md に仕様を記録 → Figma でビジュアル化
月1回、Design.md と Figma のずれを監査する

Claude Code + Figma MCP 実装パターン（実践編）

パターン1: 完全自動生成（シンプルなサイト）

/code
Figma: https://figma.com/design/xxx/SimpleLP

要件:
- Next.js + App Router
- Tailwind CSS
- Noto Sans JP対応
- 日本語テンプレート

Design.md参照: [上記テンプレート]

Claude Code の自動実行：

Figma MCP で構造解析
Design.md から Tailwind config 自動生成
React コンポーネント一式生成
TypeScript interface 自動定義
page.tsx（ホーム）自動生成

生成物の実例：トークンと interface の対応

冒頭で見たコンポーネント定義の JSON が、実際にどんなコードへ落ちるのか。Design.md のトークンと突き合わせると、対応関係はこうなります。

// tailwind.config.ts — Design.md「Color Tokens」からの生成結果
export default {
  theme: {
    extend: {
      colors: {
        primary: {
          50: "#EBF8FF",  // primary-50: 背景
          500: "#3B82F6", // primary-500: CTA・見出し
          900: "#1E3A8A", // primary-900: テキスト・枠線
        },
      },
    },
  },
};

// Button.tsx — Component Metadata の enum がそのまま Props になる
interface ButtonProps {
  size?: "small" | "medium" | "large";
  state?: "default" | "hover" | "active" | "disabled";
}

ただし、この interface をそのまま使うことはおすすめしません。hover や active は実際には CSS の擬似クラスで扱うため、私は生成後に state を Props から外し、disabled だけを boolean に直しています。Figma の定義に忠実なコードと、React として自然なコードは、最後の一歩だけずれるのです。

逆に、interface に variant?: string のような曖昧な型が現れたときは、ほぼ例外なく Figma 側のコンポーネントプロパティが enum として定義されていません。生成コードの型を見れば Figma 側の整備漏れが逆引きできる。私はこの逆引きを、生成直後レビューの起点にしております。

パターン2: カスタマイズが必要な場合

/code
Figma: https://figma.com/design/xxx/ComplexApp

課題:
1. トグルアニメーション（framer-motion必須）
2. 複雑な Grid layout（Design.md 「Layout Grid System」参照）
3. 多言語テキスト長バリエーション

指示:
- コンポーネント自動生成後、animation部分は framer-motion で実装
- Grid は CSS Grid、Design.md参照
- i18n ライブラリ導入、日本語テキスト配列を別ファイル管理

パターン3: デザイン更新のチェーン反応

既存コード + Figma デザイン更新の場合：

/code
Figma update: https://figma.com/design/xxx/ComplexApp

変更点:
- Button font-weight: 600 → 700
- Button padding: 12px 24px → 14px 28px
- Card border-radius: 4px → 12px
- Primary color: #3B82F6 → #2563EB

指示:
- 変更前後のdiff検出
- Button.tsx、Card.tsx のみ更新
- 他component依存関係検証
- regression test実行

Design.md のメンテナンス戦略

バージョニング規則

X.Y.Z

X = メジャーリセット（ブランド刷新）
Y = 新コンポーネント・色体系拡張
Z = 微調整（padding、フォント weight等）

更新ログの記録

### v1.2.0 (2026-04-04)
- Added: Dark mode tokens
- Changed: Button padding 12px 24px → 14px 28px
- Deprecated: old color-accent-light token

### v1.1.0 (2026-03-15)
- Added: Input error state specification

Claude Code ブリーフィングのテンプレート

Good：

/code
Figma: https://figma.com/design/abc/MyProject
Design System: 上記 Design.md に従う

Color Tokens:
- Primary: #3B82F6
- Neutral-900: #111827
[... 詳細 ...]

実装要件:
- Next.js 15 + App Router
- Tailwind CSS v4
- TypeScript strict mode
- i18n: next-intl (EN, JA)

Poor（これはダメ）：

/code
Figma: https://figma.com/design/abc/MyProject
デザイン通りにコンポーネント作成して

（← Design.mdなく、色コードやpaddingが不明確。
     質問が増えて反復が増える）

アニメーションを Claude Code に正しく実装させる

Figma の Prototype で定義したインタラクションは JSON で取得できますが、transition の具体値までは自動で埋まりません。そこで Design.md の「Animation & Motion」を仕様の出どころとして明示します。

たとえばボタンのホバーは、Design.md に次のように記録しておきます。

項目	値
Property	background-color
From → To	#3B82F6 → #2563EB
Duration	150ms
Easing	cubic-bezier(0.4, 0, 0.2, 1)

生成されたコンポーネントに対しては、次のように指示します。

/code
Design.md の「Animation & Motion」セクションを参照し、
すべての CSS transition を実装してください。
duration と easing は仕様値どおりに固定してください。

こうしておくと、Claude Code は勝手に ease や 300ms を補わず、仕様値のとおりに transition: background-color 150ms cubic-bezier(0.4, 0, 0.2, 1); を書き込みます。動きの「揺れ」を仕様で押さえること。それが複数画面での一貫性につながります。

公式ドキュメントには書かれていない、運用してみて気づいたこと

Figma MCP を数ヶ月使い込むうちに、ドキュメントには載っていない癖がいくつも見えてきました。個人開発の壁紙アプリや癒し系アプリの管理画面を、この手順で作り直してきた実感を書き残します。

1. 「1 画面ずつ」渡すほうが速い

Figma ファイル全体を一度に渡すと、レイヤー数が数百を超えたあたりから生成がぶれ始めます。私の手元では、1 画面（コンポーネント 20〜40 個程度）に区切って渡したときの初期生成が概ね 20〜30 秒で安定したのに対し、10 画面をまとめて渡すと途中で命名が揺れ、手直しに 1 時間以上かかりました。フレーム単位で切り出す。これが一番効きました。

2. Design Tokens は「Figma Variables 化」してから渡す

生の Hex 値のまま渡すと、Claude Code は同じ色でも #3B82F6 と bg-blue-500 を混在させがちです。Figma 側で Variables に登録し、Design.md にトークン名で書いておくと、生成結果の color 参照が 8 割方トークン名に揃いました。後から一括で色を変えられる状態を、最初に作っておく価値は大きいです。

3. 生成の往復は「差分だけ」に絞ると激減する

デザイン更新時に「全部作り直して」と頼むと、無関係なファイルまで書き換わり、回帰確認に時間を取られます。変更点だけを箇条書きにして「該当コンポーネントのみ更新・他は触らない」と明示したところ、1 回の更新にかかる時間が 2〜3 時間から 15〜30 分に縮みました。この「触らせない」指示は、設計書の質が Claude Code の速度を決めるで扱った「考えさせない仕様書」の考え方と地続きです。

4. アクセシビリティは生成直後に必ず一度落ちる

自動生成された初期コードは、コントラスト比やフォーカスリングが Design.md の想定より弱いことが多いです。私は生成直後に、コントラストとキーボード操作を必ず一度チェックする工程を挟んでおります。ここを省くと、後から個別修正が積み上がって、かえって遅くなります。

こうした癖は、デザインカンプから Claude Code だけで LP を実装する方法や React・Next.js の実践ワークフローと組み合わせると、より安定して回せるようになります。

実装フロー全体（タイムライン）

Day 1: Setup（3.5時間）

Design.md 作成・ファイナライズ（2時間）
Stitch で初期案 3 パターン生成（1時間）
最終案を 1 つ選定（30分）

Day 2: Figma 精製（4.5時間）

Figma Make でアニメーション・タイポグラフィ調整（2時間）
component 配置・hierarchy 整理（1.5時間）
QA：色・サイズ・スペーシングを Design.md と一致確認（1時間）

Day 3: Code Generation（2時間）

Claude Code で Figma URL 貼り付け → 初期生成（30分）
生成物レビュー・指示修正（1〜2時間）
TypeScript compile チェック、動作確認（30分）

Day 4+: Polish & Launch（4時間）

レスポンシブテスト、アクセシビリティチェック（1時間）
内容データ（copy, image）統合（2〜3時間）
デプロイ、GA / GSC セットアップ（1時間）

合計作業時間：約 14〜16 時間（フルスクラッチなら 5〜7 日相当）

全体を振り返って：なぜこのワークフローが強いのか

質の保証: Stitch（多数の初期案）→ Figma（専門家レベルの仕上げ）→ Claude Code（実装）という 3 段階により、各フェーズで質を管理できる
自動化による時短: 特に Code 生成フェーズで、手動コーディングの 70〜80% が削減される
保守性: Design.md という「唯一の真実」を持つことで、デザイン変更の波及が管理しやすくなる
反復の軽さ: 修正指示が簡潔で、再生成が早い。従来の「デザイナーと開発者のやり取り」とは比較にならない速度

個人開発の「デザイン + 開発」という 2 つの山を、この仕組みはまとめて低くしてくれます。最初の一歩には、1 画面だけ選んでトークンを Design.md に起こし、Claude Code に生成させてみるのがよいと思います。効果を確かめるのに、それ以上の準備は要りません。

最終的に大事なのは「信頼」です。Figma を信頼し、Design.md を信頼し、Claude Code を信頼する。その積み重ねの先に、一人でも回せる自動化が育っていきます。

拙い実践記ではありますが、あなたの制作の時間を少しでも取り戻す助けになれば幸いです。お読みいただき、ありがとうございました。