Figma Web UI 開発規範（Framelink MCP 版）
Figma デザインから Web フロントエンド UI を開発する際の再現精度低下問題を解決します。根本原因は、Figma の「キャンバスデータ」（絶対座標、インラインカラー、ピクセルレイヤーの重なり）をそのまま「実装データ」として扱い、コピーしてしまうことで、レスポンシブ対応の失敗、色やフォントの不正確さ、リソースの欠落が発生することです。
このスキルは Framelink figma-developer-mcp の以下の 2 つのツールを対象としています：
| ツール | チャネル | 役割 |
|---|---|---|
get_figma_data | 正確チャネル | fileKey + nodeId でキャンバスデータ（レイアウト、コンテンツ、ビジュアル、コンポーネント情報）を取得 |
download_figma_images | ビジュアルチャネル | ノード ID に基づき SVG/PNG/GIF をローカルディレクトリにエクスポート |
注意：これは Framelink 版であり、公式 Figma MCP Server（公式ツールは
get_design_context/get_variable_defs/download_assets）ではありません。本スキルの方法論は両方に共通ですが、ツール名は Framelink のものに従っています。ターゲットがデスクトップアプリケーション（Qt Widget / QML / WinUI / Flutter）の場合は、
figma-ui-desktopを使用し、このスキルは使用しません。
中核原則
- デュアルチャネルを並行して使用し、単一チャネルでのコーディングは禁止。正確チャネルは正確な数値を、ビジュアルチャネルは全体的なレイアウトとテキストを提供します。どちらか一方だけを使用すると、必ず再現が歪みます——特に、ビジュアルチャネルだけを使用する（スクリーンショットを見て推測するのと同じ）か、データチャネルだけを使用する（盲目的にコードを書くのと同じ）場合です。
- 正確な値を使用し、視覚的に推定しない。色、フォントサイズ、行高、フォントウェイト、間隔、角丸、枠線、シャドウは、すべてデザインから正確な値を取得します。
- まずデザインを要求し、自発的に UI を書き始めない。
- 実装後は必ず検証ループを実行する：スクリーンショットをデザインと比較 → 欠陥を発見して自動修正 → 人間が細かい問題を指摘して反復。100% を一度で達成する魔法はなく、7～8 割の再現はプロセスで、残りは検証ループで補います。
ワークフロー
フェーズ 1: 大まかな読み取り（要件と構造の理解）
デザインが大きい場合は、一度に全量を取得してコンテキストが過負荷になるのを避けるため、まず大まかに読み取ります：
get_figma_dataでトップレベルの構造を取得（depthで探索の深さを制御し、浅い層から開始）、どのページ/セクション/コンポーネントがあるかを把握。download_figma_imagesで全体ページの画像をエクスポートし、レイアウトとテキストを理解。
フェーズ 2: 詳細読み取り（実装前に正確なデータを取得）
実装する特定のコンポーネント/セクションに対して、同時に以下を呼び出します：
get_figma_data（nodeIdを指定し、ノードごとに座標、色値、フォントサイズ、間隔、角丸、枠線を読み取る）download_figma_images（そのセクションの画像をエクスポートし、コンポーネントの相対位置関係を確認）
取得後、コードを書く前に構造分析を実施：
- どのノードが繰り返しパターン（カード、リスト項目、ボタン）か → コンポーネントに抽出
- どの絶対配置が実際にはレイアウト（横並び、中央揃え、両端揃え）か → flex/grid に変換
- どのノードが意味的な役割（ナビゲーション/フォーム/リスト）か → ターゲットフレームワークの既存コンポーネントライブラリにマッピング
- 画像/アイコンノード →
download_figma_imagesで元ファイルをダウンロードし assets に配置、手書きはしない
フェーズ 3: 実装
- 色、フォントサイズ、間隔はデザインの正確な値を使用し、「だいたい同じ」では済ませない
- プロジェクトの既存コンポーネントライブラリを優先的に使用。まずコンポーネントの props（theme/size/variant）を確認し、スタイルの重複定義を避ける
- アイコンはプロジェクトのアイコンライブラリを使用し、サードパーティのアイコンは使わない
- スタイルファイルの命名、CSS クラス名の規則、ネスト階層はプロジェクトの規約に従う
フェーズ 4: 検証ループ
Playwright MCP でローカルページのスクリーンショットを撮り、デザインのスクリーンショットと並べて比較。明らかな欠陥は自動修正。人間が細かい問題（間隔、フォントウェイト、色の微妙な差）を特定し、AI に正確な修正を依頼して次の反復に進む。
怠惰防止の鉄則
AI は単一チャネルだけでコードを書こうとする傾向があるため、明確に要求する必要があります：
- 「get_figma_data と download_figma_images を同時に呼び出してデザインを読むこと」
- 「画像/スクリーンショットだけでデザインを読んでコードを書くことは許可しない」
- 「get_figma_data の正確な値を一行ずつ読み、色、フォントサイズ、間隔を比較し、視覚的な推定をしないこと」
コンポーネント規範（プロジェクトに応じて置き換え）
以下はテンプレートです。実際のプロジェクトに適用する際は、そのプロジェクトの規約に置き換えてください：
- プロジェクトのコンポーネントライブラリ（例：
@notta/components）を優先的に使用。不明な場合は積極的にユーザーに確認 - まずコンポーネントライブラリの props を確認し、スタイルの重複定義を避ける
- アイコンはプロジェクトのアイコンライブラリを使用
- スタイルファイルの命名、CSS クラス名の規則、ネスト階層はプロジェクトの規約に従う
再現精度自己チェックリスト
生成後、項目ごとに確認（「全体的に似ているか」よりも信頼性が高い）：
- 色（正確な hex が使用されているか、近似値ではないか）
- フォントサイズ / 行高 / フォントウェイト
- 間隔 / マージン / パディング
- 角丸 / 枠線 / シャドウ
- レイアウト（flex/grid がデザインの配置と等価か）
- z-index / 階層
- アイコン/画像は元ファイルを使用しているか、手書きではないか
参考元
方法論は公式 Figma MCP + Playwright の UI 開発フロー（「Figma mcp と Playwright mcp で UI 開発・デバッグ効率を向上」参照）から着想を得ています。中核となる考え方は「デュアルチャネル + 検証ループ + 怠惰防止の明確な要求」であり、ツール名は Framelink figma-developer-mcp に適合させています。