Figma デスクトップ UI 開発規範（Framelink MCP 版）
Figma デザインからデスクトップ UI を開発する際に、忠実度が低くなる問題を解決します。根本原因は、Figma の「キャンバスデータ」（絶対座標、インラインカラー、ピクセルレイヤーの重なり）をそのまま「実装データ」として扱い、直接コピーすることでレイアウトが不自然になったり、色やフォントの指定が不正確になったり、リソースが欠落することにあります。
デスクトップで公式 Figma MCP Server ではなく Framelink を使う理由: 公式 MCP の主要ツール
get_design_contextはデフォルトで Web コード（React/Tailwind、Vue/HTML/iOS に切り替え可能）のみを生成し、Qt Widget / QML / WinUI / Flutter をサポートしておらず、有料です。Framelink は「フレームワーク非依存の Figma データのみを提供し、翻訳はモデルに任せる」という立場をとっています。この「短所」は、デスクトップの多フレームワーク環境においてはむしろ利点となります。モデルがキャンバスデータを取得し、任意のターゲットフレームワークに翻訳できるため、Web に固定されることがありません。
本スキルは、Framelink figma-developer-mcp の以下の 2 つのツールを対象としています。
| ツール | チャネル | 役割 |
|---|---|---|
get_figma_data | 正確チャネル | fileKey + nodeId に基づきキャンバスデータ（レイアウト、コンテンツ、ビジュアル、コンポーネント情報）を取得 |
download_figma_images | ビジュアルチャネル | ノード ID に基づき SVG/PNG/GIF をローカルディレクトリにエクスポート |
ターゲットが Web フロントエンド（React/Vue/HTML）の場合は、
figma-ui-webを使用してください。
核心原則
- 二重チャネルを並行して使用し、片方のみでのコーディングを禁止する。正確チャネルは正確な数値を、ビジュアルチャネルは全体のレイアウトとテキストを提供します。どちらか一方のみでは必ず再現性が低下します。
- 正確な値を使用し、視覚的な推定は行わない。色、フォントサイズ、フォントウェイト、スペーシング、角丸、ボーダー、シャドウはすべてデザインの正確な値を取得します。
- まずデザインを要求し、自発的に UI を書き始めない。
- 実装後は必ず検証サイクルを完了する：実際にアプリを実行したスクリーンショットとデザイン稿を比較 → 欠陥を発見して自動修正 → 人手でチェックしてさらに反復。
ワークフロー
フェーズ1：概観（要件と構造の理解）
デザインが大きい場合は、一度に全量を取得してコンテキストが過負荷になるのを防ぐため、まず概観します。
get_figma_dataでトップレベルの構造を取得（depthで走査階層を制御し、浅い階層から始める）。どのようなページ / セクション / コントロールがあるかを把握します。download_figma_imagesで全体のインターフェース画像をエクスポートし、レイアウトとテキストを理解します。
フェーズ2：精読（実装前の正確なデータ取得）
実装する特定のセクション / コントロールに対して、同時に以下を呼び出します。
get_figma_data（nodeIdを指定し、ノードごとに座標、色値、フォントサイズ、スペーシング、角丸、ボーダーを読み取る）download_figma_images（そのセクションの画像をエクスポートし、コントロール間の相対位置関係を確認する）
データを取得したら、まず構造分析を行ってからコードを書きます。
- どのノードが繰り返しパターンか（リストアイテム、カード、ボタン）→ ターゲットフレームワークのカスタムコントロール / コンポーネントに抽出
- どの絶対位置指定が実際にはレイアウトか（横並び、中央揃え、両端揃え、グリッド）→ 下記のマッピングテーブルに従い対応フレームワークのレイアウトに変換
- どの要素が意味的な役割か（ナビゲーション / フォーム / リスト）→ ターゲットフレームワークの既存コントロールライブラリにマッピング
- 画像 / アイコンノード →
download_figma_imagesで元ファイルをダウンロードしリソースディレクトリに配置。手書きはしない
フェーズ3：実装（フレームワーク非依存の翻訳）
色、フォントサイズ、スペーシングはデザインの正確な値を使用します。翻訳時は下記の「キャンバス概念 → ターゲットフレームワーク」マッピングテーブルを参照し、コントロールをでっち上げないこと。ターゲットフレームワークに標準のレイアウト / コントロールがあればそれを使用し、絶対座標は「どうしても正確なピクセル位置が必要な場合」にのみ残します。
フェーズ4：検証サイクル
デスクトップには Playwright のようなブラウザ自動化ツールがないため、検証方法は次の通りです。実際にコンパイル・実行したプログラムのスクリーンショットを、デザイン稿のスクリーンショットと並べて比較し、明らかな欠陥があれば自動修正。人手によるチェックでより細かい問題（スペーシング、フォントウェイト、色の微妙な差）を特定し、AI に正確な修正を依頼して次の反復サイクルに入ります。
キャンバス概念 → ターゲットフレームワーク マッピングテーブル
Figma のキャンバスは絶対座標＋ピクセルレイヤーであり、実装時には各フレームワークのレイアウトセマンティクスに翻訳する必要があります。翻訳時はこのテーブルを参照してください。
| キャンバス / デザイン概念 | Qt Widget | QML (Qt Quick) | WinUI 3 (XAML) | Flutter |
|---|---|---|---|---|
| 横並び | QHBoxLayout | Row | StackPanel (Orientation=Horizontal) | Row |
| 縦並び | QVBoxLayout | Column | StackPanel (Orientation=Vertical) | Column |
| グリッドレイアウト | QGridLayout | Grid / GridLayout | Grid | GridView / Table |
| 絶対位置指定 | setGeometry / move | Item + x/y | Canvas + Canvas.Left/Top | Stack + Positioned |
| 重なり / オーバーレイ | 子ウィジェットの重ね合わせ / raise() | z プロパティ / Stack | Canvas.ZIndex | Stack |
| 中央揃え | addStretch / setAlignment | anchors.centerIn | HorizontalAlignment/VerticalAlignment=Center | Center / Align |
| 両端揃え | 両側に addStretch | anchors.left/right + margins | マージンによる割り当て | MainAxisAlignment.spaceBetween |
| スペーシング | QSpacerItem / layout spacing | spacing プロパティ | Margin / Padding | SizedBox / Padding / Spacer |
| 色 | QPalette / stylesheet | Theme / プロパティバインディング | リソースディクショナリ ResourceDictionary | ThemeData / ColorScheme |
| フォントサイズ / フォント | QFont | font.pixelSize | FontSize | TextStyle.fontSize |
| 角丸 | stylesheet border-radius | Rectangle radius | CornerRadius | BorderRadius |
| 影 | QGraphicsDropShadowEffect | DropShadow | ThemeShadow / DropShadow | BoxShadow |
| アイコン | QIcon / リソース | Image / アイコンフォント | FontIcon / SymbolIcon | Icon |
| コンポーネントの再利用 | カスタム QWidget サブクラス | カスタム QML Component | UserControl / カスタムコントロール | Widget |
| 状態 / バリアント | 列挙型 + update() | State / プロパティ駆動 | VisualStateManager | setState / AnimatedWidget |
怠け防止の鉄則
AI は片方のチャネルだけでコードを書きがちです。以下のように明確に要求してください。
- 「
get_figma_dataとdownload_figma_imagesを同時に呼び出してデザインを読むこと」 - 「画像やスクリーンショットだけでデザインを読んでコードを書くことは許可しない」
- 「
get_figma_dataの正確な値を一行ずつ読み、色、フォントサイズ、スペーシングを比較し、視覚的な推定は行わない」 - 「マッピングテーブルに従い、ターゲットフレームワークの標準レイアウト / コントロールに翻訳し、でっち上げない」
忠実度セルフチェックリスト
生成後、各項目を確認します（「全体的に似ているか」よりも信頼性が高いです）。
- 色（正確な値を使用しているか、近似値ではないか）
- フォントサイズ / フォントウェイト
- スペーシング / マージン / パディング
- 角丸 / ボーダー / シャドウ
- レイアウト（ターゲットフレームワークの標準レイアウトに翻訳されているか、絶対座標をそのままコピーしていないか）
- 階層 / 重なり順序
- アイコン / 画像は元のファイルを使用しているか、手書きではないか
- 繰り返しパターンはコンポーネント / カスタムコントロールに抽出されているか
参考情報
本手法は、公式 Figma MCP + Playwright による UI 開発フロー（「Figma mcp と Playwright mcp を使った UI 開発とデバッグ効率化」を参照）から着想を得ています。「二重チャネル + 検証サイクル + 怠け防止の明確な要求」という中核的な考え方を保持し、ツール名を Framelink figma-developer-mcp に適合させ、マッピングテーブルをデスクトップ向けの複数フレームワークをカバーするように拡張しています。