Figma Implement — デザインからコードへは何をしますか？

あらゆる Figma デザインを本番コードに変換します。ガイドフローがプロジェクトを自動検出し、デザインシステムのコンポーネントをコードコンポーネントにマッピングし、プロジェクトの規約に沿ったコードを生成します。

アクティベーション時

現在のモデルを確認します。Opus でない場合は、以下の警告をユーザーに表示します。

「注意 — 現在 [モデル名] を使用しています。このプラグインはデザインからコードへの正確な変換に Claude Opus で最適に動作します。切り替えるには以下を実行してください:

/model opus

または、現在のモデルのまま続行しても構いません。」

すでに Opus の場合は、このメッセージを表示せずにスキップします。

その後、ガイドフローを開始します。質問は一度に1つずつ行い、各応答を待ちます。

フェーズ 0: Figma に接続

Figma MCP が接続されていることを確認します。

mcp__figma__whoami または mcp__plugin_figma_figma__whoami をサイレントで呼び出してみます。成功したらフェーズ 1 に進みます。

失敗した場合:

「Figma MCP が接続されていません。プラグインの README (Figma MCP セットアップセクション) のセットアップ手順に従ってください。Figma アクセストークンと 1 つの CLI コマンドが必要です。準備ができたら教えてください。確認します。」

応答を待ちます。 whoami を再度試します。成功したら続行します。それでも失敗する場合は、トークンを確認して Claude Code を再起動するよう提案します。

フェーズ 1: プロジェクトを把握する

プロジェクトをスキャンして、スタック、規約、既存コンポーネントを理解します。

「コードの書き方を理解するためにプロジェクトをスキャンします...」

以下のチェックをサイレントで実行します:

1a. フレームワーク検出

package.json を読み取り → 特定する: React? Vue? Svelte? Next.js? Remix? Astro?
tsconfig.json を読み取り → TypeScript または JavaScript?

1b. CSS フレームワーク検出

確認する: tailwind.config.* → Tailwind CSS
確認する: *.module.css → CSS Modules
確認する: styled-components または @emotion → CSS-in-JS
確認する: .scss ファイル → Sass
確認する: プレーンな .css → vanilla CSS

1c. コンポーネントライブラリ検出

package.json の依存関係を読み取り:
  @mui/* → Material UI
  @chakra-ui/* → Chakra UI
  antd → Ant Design
  @eds/* → Epic Design System
  @radix-ui/* → Radix
  カスタム → src/components/ をスキャンして社内ライブラリを検出

1d. 既存コンポーネントの在庫

グロブ: src/components/**/*.{tsx,jsx,vue,svelte}
各ファイルから: コンポーネント名、props インターフェース、使用パターンを抽出

1e. コーディング規約

確認するファイル命名: PascalCase.tsx? kebab-case.tsx? フォルダ内の index.tsx?
確認するインポートスタイル: 絶対パス (@/components) または相対パス (../components)?
確認するエクスポートスタイル: default export または named export か?

検出結果を提示します:

「プロジェクトで以下の情報が見つかりました:

フレームワーク: [React/Vue/など] + [TypeScript/JavaScript] CSS: [Tailwind/CSS Modules/など] コンポーネントライブラリ: [MUI/Chakra/カスタム/なし] 既存コンポーネント: [N] 個が src/components/ にあります [上位10〜15個のコンポーネント名を一覧表示] 規約: [PascalCase ファイル、絶対インポート、default export、など]

これは正しいですか？プロジェクトのセットアップについて何か共有すべきことはありますか？」

応答を待ちます。 ユーザーが修正した場合は理解を調整します。

フェーズ 2: Figma デザインを取得する

「Figma デザインの URL を共有してください（特定のフレーム/ノードが選択されているもの）。」

応答を待ちます。 URL から fileKey と nodeId を抽出します。

次にデザインを取得します:

get_design_context({ nodeId, fileKey })
get_screenshot({ nodeId, fileKey })

スクリーンショットを表示します:

「実装するデザインはこちらです: [スクリーンショット]

確認できる内容: [セクションと要素の簡単な説明]

正しいフレームですか？」

確認を待ちます。

フェーズ 3: コンポーネントマッピング

すべての Figma 要素をコードコンポーネントにマッピングします。 これは重要なステップです。

「デザインをコードコンポーネントにマッピングします...」

Figma デザインの各要素について:

プロジェクトに一致するコンポーネントが存在するか確認します（フェーズ 1d の在庫から）
存在する場合 → 正しい props で再利用します
存在しない場合 → プロジェクトの規約に従って新しいコンポーネントを作成します

マッピングを提示します:

「こちらが実装計画です:

既存コンポーネントを再利用:

Figma 要素あなたのコンポーネント設定する Props
プライマリボタン <Button variant="primary"> label, onClick
テキスト入力 <TextField> label, placeholder
アバター <Avatar> src, name, size
... ... ...

新しく作成するコンポーネント:

Figma 要素新しいコンポーネント保存場所
統計カード <StatsCard> src/components/StatsCard.tsx
... ... ...

[N] 個の要素 が既存コンポーネントを再利用します。[M] 個の新しいコンポーネント が必要です。

進めましょうか？」

確認を待ちます。

フェーズ 4: セクションごとに実装

一度にすべてを生成せず、段階的に構築します:

レイアウト構造 — 外側のコンテナ、グリッド、レスポンシブブレークポイント
ナビゲーション — ヘッダー、サイドバー、パンくずリスト（可能なら既存を再利用）
プライマリコンテンツ — メイン機能エリア
セカンダリコンテンツ — サイドバー、フッター
データコンテンツ — テーブル、カード、フォーム（現実的なデータを使用）

各セクション終了後:

ファイルを保存する
開発サーバーが実行中ならブラウザで確認する
Figma のスクリーンショットと比較する

実装ルール

既存コンポーネントを再利用する。 既存の Button がある場合、新しいものを作成しない。
規約に従う。 ファイル命名、インポート、エクスポート — プロジェクトが既に行っている方法に従う。
CSS 手法に合わせる。 Tailwind なら Tailwind。CSS Modules なら CSS Modules。混在させない。
Figma スペックが真実の情報源。 スペーシング、色、タイポグラフィを正確に一致させる。
位置計算: 絶対要素の場合: CSS position = Figma 子要素 − Figma 親要素。自動レイアウトには flexbox/grid を使用する。
SVG のサニタイズ: SVG から preserveAspectRatio="none" を削除する。

フェーズ 5: Playwright で検証する

「実装が完了しました。デザインと一致しているか確認します...」

Playwright MCP を使用して実装を Figma と比較します:

開発サーバーの URL が不明な場合は尋ねます（例: http://localhost:5173）
ナビゲート: browser_navigate({ url })
ビューポートを Figma フレームサイズに合わせる: browser_resize({ width: [figma width], height: [figma height] })
ブラウザのスクリーンショットを撮る: browser_take_screenshot({ type: "png" })
フェーズ 2 の Figma スクリーンショットと比較する
コンソールエラーを確認する: browser_console_messages({ level: "error" })
アクセシビリティスナップショットを取得する: browser_snapshot() — 構造が一致しているか確認する

「比較結果:

Figma: [スクリーンショット]

ブラウザ: [スクリーンショット]

コンソールエラー: [エラーがあれば表示、なければ 'なし']

不一致: [差異を一覧表示、または '問題なし']

調整が必要ですか？それとも /figma-validate で完全な検証を実行しますか？」

重要なルール

フェーズ 0 は必須です。 Figma 接続チェックをスキップしないでください。
フェーズ 1 はプロジェクトごとに 1 回実行します。 検出結果はセッション中キャッシュします。
フェーズ 3 のマッピングは確認が必要です。 ユーザーが計画を承認するまでコードを生成しないでください。
作り直すより再利用。 常に既存コンポーネントを最初に確認してください。
プロジェクトに合わせる。 新しいパターン、フレームワーク、規約を押し付けないでください。
セクションごとに。 ページ全体を一度に生成しないでください。

Figma Implement — デザインからコードへ