PromptからUI実装へ: Figma MCP時代のデザイン×開発運用モデル

MCP連携が変えるのは「成果物」ではなく「受け渡し」

エディタからデザインツールへUIレイヤーを直接生成できるようになると、変わるのは作業効率だけではありません。仕様受け渡しの単位が、画像や文書から「実行可能な意図」に変わります。

つまり、デザインと実装の間にある翻訳コストを下げるチャンスですが、同時に運用設計を誤ると、見た目だけ揃って中身が崩れる危険も増えます。

初期導入で失敗しやすい3パターン

プロンプトがコンポーネント契約に紐づいていない
トークン/余白規約を無視した生成を許してしまう
デザイナーとエンジニアの責任境界が曖昧

ツールの問題ではなく、ほぼ運用モデルの問題です。

Contract-Firstで組む3点セット

導入時は次の3成果物を先に整備します。

Intent Spec: 目的、ユーザーフロー、状態遷移、アクセシビリティ要件
Component Map: 利用可能プリミティブ、トークン空間、レスポンシブ分岐
Validation Checklist: コントラスト、フォーカス順、エラー時挙動、読み上げ整合

この3つがあるだけで、生成精度とレビュー効率が大きく上がります。

本番運用で必須のガードレール

1. トークンの権威は単一化する

生成レイヤー内でローカルトークンを許すと、短期間でデザイン崩壊が始まります。トークン参照は中央レジストリのみ許可するのが原則です。

2. プロンプトテンプレートはコード管理する

テンプレートは“運用資産”です。Gitで管理し、レビュー対象にし、オーナーを明確化します。

3. アクセシビリティを後工程に回さない

最小タップ領域、フォーカス順、セマンティクス、色コントラストをプロンプト段階で明示し、生成時に満たさせます。

4. 画像比較だけでレビューしない

スクリーンショット差分だけでは本質が見えません。コード差分とデザイン差分を同じレビュー文脈で扱う仕組みが必要です。

推奨チーム編成: Triad方式

Design Steward: パターン言語とトークン整合を守る
Engineering Integrator: 機能制約を生成指示へ翻訳
Quality Verifier: 境界状態と操作整合を検証

直列ハンドオフより速く、責任の所在も明確です。

健全な導入を示すKPI

生成レイヤーの一次受入率
リリースあたりトークン違反件数
アクセシビリティ修正リードタイム
マージ後のデザイン/実装乖離率
UI中心PRのレビューサイクル時間

特に重要なのは、複数リリースで乖離率が下がり続けることです。

効果が高いユースケース

標準化されたB2Bダッシュボード
フォーム中心の業務画面
管理系UIや運用コンソール
多言語展開で構造が安定した画面

一方、ブランド訴求中心の探索デザインは人手主導が依然有利です。

60日導入ロードマップ

Week 1–2: 成果物定義、責任者、受入基準策定
Week 3–4: 単一プロダクト面で小規模検証
Week 5–6: テンプレート版管理とトークン検査導入
Week 7–8: 隣接チームへ展開し運用手引きを公開

まとめ

MCP時代のデザイン生成は、デザインを自動化する話ではありません。意図と制約をつないだまま実装まで届ける契約設計の話です。ここを仕組み化できたチームほど、速く、ブレずに、改善を積み上げられます。