figma-implement-design について
既存リポジトリで Figma デザインをコードとして実装するためのスキルです。デザイン情報とスクリーンショットの取得、プロジェクト規約の再利用、参照デザインとの照合を支援します。
主な機能
- 01Figma ノード情報とスクリーンショットの取得
- 02アセットのダウンロード手順
- 03既存コンポーネントとトークンの活用
- 04見た目と操作の検証
活用シーン
- 01コードベースへの Figma コンポーネント実装
- 02Figma フレームからの画面構築
- 03UI のレイアウトとタイポグラフィの照合
- 04既存プロジェクト規約に沿った Figma アセットの適用
MCP 対応
デザイン情報、スクリーンショット、アセットの取得に Figma MCP サーバーへの接続が必要です。`get_design_context`、`get_screenshot`、必要に応じて `get_metadata` を使う手順を示します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ figma/ mcp-server-guide --skill figma-implement-designインストール後、Claude Code で/figma-implement-designを入力して読み込まれたか確認します。
詳細
デザインを実装する
概要
このスキルでは、Figma のデザインをピクセル単位で正確に本番環境対応のコードへ変換するための、体系的なワークフローを提供します。Figma MCP サーバーとの一貫した連携、デザイントークンの適切な使用、デザインとの 1:1 の視覚的な一致を実現します。
スキルの範囲
- 成果物がユーザーのリポジトリ内のコードである場合は、このスキルを使用します。
- ユーザーが Figma 内のノードを作成、編集、削除するよう求めた場合は、figma-use に切り替えます。
- ユーザーがコードや説明から Figma の全ページ画面を構築または更新するよう求めた場合は、figma-generate-design に切り替えます。
- ユーザーが Code Connect のマッピングのみを求めた場合は、figma-code-connect に切り替えます。
- ユーザーが再利用可能なエージェントルール(
CLAUDE.md/AGENTS.md)を作成するよう求めた場合は、figma-create-design-system-rules に切り替えます。
前提条件
- Figma MCP サーバーに接続でき、アクセス可能であること
- ユーザーから次の形式の Figma URL が提供されていること:
https://figma.com/design/:fileKey/:fileName?node-id=1-2:fileKeyはファイルキーです1-2はノード ID(実装する特定のコンポーネントまたはフレーム)です
- または
figma-desktopMCP を使用する場合:ユーザーは Figma デスクトップアプリでノードを直接選択できます(URL は不要です) - プロジェクトに確立されたデザインシステムまたはコンポーネントライブラリがあることが望ましいです
必須のワークフロー
以下の手順を順番に実行してください。省略しないでください。
Step 1:ノード ID を取得する
Option A:Figma URL から解析する
ユーザーから Figma URL が提供された場合は、ファイルキーとノード ID を抽出し、MCP ツールに引数として渡します。
URL の形式: https://figma.com/design/:fileKey/:fileName?node-id=1-2
抽出する値:
- ファイルキー:
:fileKey(/design/の後に続く部分) - ノード ID:
1-2(node-idクエリパラメーターの値)
注: ローカルのデスクトップ MCP(figma-desktop)を使用する場合、ツール呼び出しのパラメーターとして fileKey を渡しません。サーバーは現在開いているファイルを自動的に使用するため、必要なのは nodeId のみです。
例:
- URL:
https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15 - ファイルキー:
kL9xQn2VwM8pYrTb4ZcHjF - ノード ID:
42-15
Option B:Figma デスクトップアプリの現在の選択を使用する(figma-desktop MCP のみ)
figma-desktop MCP を使用していて、ユーザーから URL が提供されていない場合、ツールはデスクトップアプリで開いている Figma ファイル内の現在選択されているノードを自動的に使用します。
注: 選択状態に基づくプロンプト指定は、figma-desktop MCP サーバーでのみ機能します。リモートサーバーでコンテキストを取得するには、フレームまたはレイヤーへのリンクが必要です。ユーザーは Figma デスクトップアプリを開き、ノードを選択しておく必要があります。
Step 2:デザインのコンテキストを取得する
抽出したファイルキーとノード ID を使って get_design_context を実行します。
get_design_context(fileKey=":fileKey", nodeId="1-2")
次のような構造化データが得られます。
- レイアウトのプロパティ(Auto Layout、制約、サイズ設定)
- タイポグラフィの仕様
- 色の値とデザイントークン
- コンポーネントの構造とバリアント
- 間隔とパディングの値
応答が大きすぎる、または途中で切れている場合:
get_metadata(fileKey=":fileKey", nodeId="1-2")を実行し、ノードの概要マップを取得します- メタデータから必要な子ノードを特定します
get_design_context(fileKey=":fileKey", nodeId=":childNodeId")を使って、子ノードを個別に取得します
Step 3:視覚的な参照を取得する
同じファイルキーとノード ID を使って get_screenshot を実行し、視覚的な参照を取得します。
get_screenshot(fileKey=":fileKey", nodeId="1-2")
このスクリーンショットは視覚的な検証のための正解データです。実装中はいつでも確認できる状態にしておいてください。
Step 4: 必要なアセットをダウンロードする
Figma MCP サーバーから返されたアセット(画像、アイコン、SVG)をダウンロードします。
重要: 以下のアセットルールに従ってください:
- Figma MCP サーバーが画像または SVG に対して
localhostのソースを返した場合は、そのソースをそのまま使用してください - 新しいアイコンパッケージをインポートしたり追加したりしないでください。すべてのアセットは Figma のペイロードから取得してください
localhostのソースが提供されている場合は、プレースホルダーを使用または作成しないでください- アセットは Figma MCP サーバーに組み込まれたアセットエンドポイントから提供されます
Step 5: プロジェクトの規約に合わせて変換する
Figma の出力を、このプロジェクトのフレームワーク、スタイル、規約に合わせて変換します。
主要な原則:
- Figma MCP の出力(通常は React + Tailwind)は、最終的なコードスタイルではなく、デザインと動作の表現として扱ってください
- Tailwind のユーティリティクラスは、プロジェクトが推奨するユーティリティまたはデザインシステムのトークンに置き換えてください
- 機能の重複を避けるため、既存のコンポーネント(ボタン、入力欄、タイポグラフィ、アイコンラッパー)を再利用してください
- プロジェクトのカラーシステム、タイポグラフィスケール、スペーシングトークンを一貫して使用してください
- 既存のルーティング、状態管理、データ取得のパターンを尊重してください
Step 6: 1:1 のビジュアルパリティを達成する
Figma デザインとのピクセルパーフェクトなビジュアルパリティを目指してください。
ガイドライン:
- デザインを正確に一致させるため、Figma への忠実さを優先してください
- ハードコードされた値は避けてください。Figma に該当するものがある場合は、Figma のデザイントークンを使用してください
- デザインシステムのトークンと Figma の仕様が競合する場合は、デザインシステムのトークンを優先し、ビジュアルに合わせるためにスペーシングやサイズを最小限だけ調整してください
- アクセシビリティについては WCAG の要件に従ってください
- 必要に応じてコンポーネントのドキュメントを追加してください
Step 7: Figma と照合して検証する
完了とする前に、最終的な UI を Figma のスクリーンショットと照合して検証してください。
検証チェックリスト:
- レイアウトが一致している(スペーシング、配置、サイズ)
- タイポグラフィが一致している(フォント、サイズ、ウェイト、行の高さ)
- 色が正確に一致している
- インタラクティブな状態がデザイン通りに動作する(hover、active、disabled)
- レスポンシブな挙動が Figma の制約に従っている
- アセットが正しく表示される
- アクセシビリティの基準を満たしている
実装ルール
コンポーネントの構成
- UI コンポーネントは、プロジェクトで指定されたデザインシステムのディレクトリに配置してください
- プロジェクトのコンポーネント命名規則に従ってください
- 動的な値に本当に必要な場合を除き、インラインスタイルは避けてください
デザインシステムとの統合
- 可能な限り、常にプロジェクトのデザインシステムのコンポーネントを使用してください
- Figma のデザイントークンをプロジェクトのデザイントークンに対応付けてください
- 一致するコンポーネントが存在する場合は、新規作成するのではなく、それを拡張してください
- デザインシステムに追加した新しいコンポーネントはすべてドキュメント化してください
コード品質
- ハードコードされた値は避けてください。定数またはデザイントークンに切り出してください
- コンポーネントは組み合わせ可能で再利用しやすい状態に保ってください
- コンポーネントの props に TypeScript の型を追加してください
- エクスポートされるコンポーネントには JSDoc コメントを含めてください
例
例 1: ボタンコンポーネントを実装する
ユーザーの依頼: 「この Figma のボタンコンポーネントを実装してください: https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15」
実行内容:
- URL を解析して、fileKey=
kL9xQn2VwM8pYrTb4ZcHjFと nodeId=42-15を取得する get_design_context(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")を実行する- 視覚的な参照のために
get_screenshot(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")を実行する - アセットエンドポイントから、ボタンのアイコンをダウンロードする
- プロジェクトに既存のボタンコンポーネントがあるか確認する
- ある場合は新しいバリアントを追加して拡張し、ない場合はプロジェクトの規約に従って新しいコンポーネントを作成する
- Figma の色をプロジェクトのデザイントークンに対応付ける(例:
primary-500、primary-hover) - パディング、角丸、タイポグラフィについてスクリーンショットと照合して検証する
結果: Figma のデザインに一致し、プロジェクトのデザインシステムに統合されたボタンコンポーネント。
例 2: ダッシュボードレイアウトの構築
ユーザーの指示: "Build this dashboard: https://figma.com/design/pR8mNv5KqXzGwY2JtCfL4D/Dashboard?node-id=10-5"
手順:
- URL を解析し、fileKey=
pR8mNv5KqXzGwY2JtCfL4Dと nodeId=10-5を抽出する get_metadata(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")を実行して、ページ構造を把握する- メタデータからメインセクション(ヘッダー、サイドバー、コンテンツエリア、カード)とその子ノード ID を特定する
- 主要な各セクションについて
get_design_context(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId")を実行する - ページ全体について
get_screenshot(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")を実行する - すべてのアセット(ロゴ、アイコン、チャート)をダウンロードする
- プロジェクトのレイアウトプリミティブを使ってレイアウトを構築する
- 可能な場合は既存のコンポーネントを使って各セクションを実装する
- Figma の制約に照らしてレスポンシブな動作を検証する
結果: Figma デザインに一致し、レスポンシブなレイアウトを備えた完成したダッシュボード。
ベストプラクティス
常にコンテキストの取得から始める
推測に基づいて実装してはいけません。必ず最初に get_design_context と get_screenshot を取得してください。
段階的な検証
最後にだけでなく、実装中に頻繁に検証してください。これにより問題を早期に発見できます。
逸脱を文書化する
(アクセシビリティや技術的な制約のためなど)Figma デザインから逸脱する必要がある場合は、その理由をコードのコメントに記載してください。
再作成より再利用
新しいコンポーネントを作成する前に、必ず既存のコンポーネントを確認してください。Figma を正確に再現することよりも、コードベース全体の一貫性の方が重要です。
まずデザインシステムを優先する
判断に迷う場合は、Figma の値をそのまま翻訳するよりも、プロジェクトのデザインシステムのパターンを優先してください。
よくある問題と解決策
問題: Figma の出力が途切れている
原因: デザインが複雑すぎるか、ネストされたレイヤーが多すぎて、1 回のレスポンスで返せない。
解決策: get_metadata でノード構造を取得し、特定のノードを get_design_context で個別に取得してください。
問題: 実装後にデザインが一致しない
原因: 実装されたコードと元の Figma デザインの間に見た目の差異がある。 解決策: 手順 3 のスクリーンショットと並べて比較してください。デザインコンテキストのデータで、余白、色、タイポグラフィの値を確認してください。
問題: アセットが読み込まれない
原因: Figma MCP サーバーのアセットエンドポイントにアクセスできないか、URL が書き換えられている。
解決策: Figma MCP サーバーのアセットエンドポイントにアクセスできることを確認してください。サーバーは localhost の URL でアセットを提供します。変更を加えず、そのまま使用してください。
問題: デザイントークンの値が Figma と異なる
原因: プロジェクトのデザインシステムのトークンの値が、Figma デザインで指定された値と異なっている。 解決策: プロジェクトのトークンと Figma の値が異なる場合は、一貫性のためにプロジェクトのトークンを優先し、視覚的な忠実度を保つために余白やサイズを調整してください。
デザイン実装の理解
Figma 実装ワークフローは、デザインをコードに変換するための信頼性の高いプロセスを確立します。
デザイナーにとって: 実装がデザインどおりのピクセル単位の精度で一致するという安心感。 開発者にとって: 推測を排除し、手戻りを減らす構造化されたアプローチ。 チームにとって: デザインシステムの整合性を保つ、一貫性のある高品質な実装。
このワークフローに従うことで、すべての Figma デザインが同じレベルの注意と細部へのこだわりをもって実装されることを保証できます。