figma-implement-design について
Figma のデザインをプロジェクトのコードに反映するスキルです。既存のデザインシステムや規約に沿って UI を実装する開発者向けで、Figma MCP からデザイン情報とスクリーンショットを取得してから実装・検証します。
主な機能
- 01Figma からデザイン情報とスクリーンショットを取得
- 02ファイルとノードの識別子を解析
- 03アセットを取得しプロジェクト規約に準拠
- 04コンポーネントを再利用しデザイントークンを対応付け
- 05スクリーンショットとレイアウト・見た目を比較
活用シーン
- 01Figma デザインに基づく UI コンポーネントの実装
- 02Figma ページのプロジェクト UI への反映
- 03実装とデザインスクリーンショットの照合
MCP 対応
デザイン情報、ノードメタデータ、スクリーンショット、アセットの取得に Figma MCP への接続が必要です。リモートサーバーまたは figma-desktop MCP を利用できます。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tech-leads-club/ agent-skills --skill figma-implement-designインストール後、Claude Code で/figma-implement-designを入力して読み込まれたか確認します。
同梱ファイルLICENSE.txt
詳細
デザインを実装する
概要
このスキルでは、Figma のデザインをピクセル単位で正確に本番環境対応のコードへ変換するための、体系的なワークフローを提供します。Figma MCP サーバーとの一貫した連携、デザイントークンの適切な使用、デザインとの 1:1 の視覚的な一致を実現します。
前提条件
- Figma MCP サーバーに接続でき、アクセス可能であること
- ユーザーが次の形式の Figma URL を提供すること:
https://figma.com/design/:fileKey/:fileName?node-id=1-2:fileKeyはファイルキーです1-2はノード ID(実装する特定のコンポーネントまたはフレーム)です
- または
figma-desktopMCP を使用する場合:ユーザーは Figma デスクトップアプリでノードを直接選択できます(URL は不要です) - プロジェクトに確立されたデザインシステムまたはコンポーネントライブラリがあること(推奨)
必須のワークフロー
次の手順を順番どおりに実行してください。手順を省略しないでください。
ステップ 0:Figma MCP をセットアップする(まだ設定されていない場合)
Figma MCP が接続されていないために MCP 呼び出しが失敗した場合は、いったん停止してセットアップしてください。
- エージェントの MCP 設定に Figma MCP サーバーを追加します。
- URL:
https://mcp.figma.com/mcp
- URL:
- エージェントで必要な場合は、リモート MCP クライアントを有効にします。
- エージェントの認証フローに従って OAuth でログインします。
ログインに成功したら、ユーザーはエージェントを再起動する必要があります。再試行時にステップ 1 から続行できるよう、その旨を伝えて応答を完了してください。
ステップ 1:ノード ID を取得する
オプション 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
オプション B:Figma デスクトップアプリの現在の選択を使用する(figma-desktop MCP のみ)
figma-desktop MCP を使用し、ユーザーが URL を提供していない場合、ツールはデスクトップアプリで開いている Figma ファイル内の現在選択されているノードを自動的に使用します。
注: 選択に基づくプロンプトは、figma-desktop MCP サーバーでのみ機能します。リモートサーバーでは、コンテキストを抽出するためにフレームまたはレイヤーへのリンクが必要です。ユーザーは Figma デスクトップアプリを開き、ノードを選択しておく必要があります。
ステップ 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")を使用して、個々の子ノードを取得します
ステップ 3:視覚的な参照をキャプチャする
同じファイルキーとノード ID を指定して get_screenshot を実行し、視覚的な参照画像を取得します。
get_screenshot(fileKey=":fileKey", nodeId="1-2")
このスクリーンショットを視覚的な検証の基準として使用します。実装中はいつでも参照できるようにしておいてください。
ステップ 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 の仕様が競合する場合は、デザインシステムのトークンを優先しつつ、視覚的な一致に向けてスペーシングやサイズを最小限調整します
- アクセシビリティに関する WCAG の要件に従います
- 必要に応じてコンポーネントのドキュメントを追加します
Step 7: Figma と照合して検証する
完了とする前に、最終的な UI を Figma のスクリーンショットと照合して検証します。
検証チェックリスト:
- レイアウトが一致している(スペーシング、配置、サイズ)
- タイポグラフィが一致している(フォント、サイズ、太さ、行の高さ)
- 色が正確に一致している
- インタラクティブな状態が設計どおりに動作する(ホバー、アクティブ、無効)
- レスポンシブ動作が 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 デザインが同じレベルの注意と細部へのこだわりをもって実装されることを保証できます。