Figma MCPレイヤー生成の実務: デザイン to コードを崩さない運用契約

生成機能の価値は高いが、破綻ポイントは別にある

Figma MCPの進化で、VS Code上でレイヤーを直接生成できるようになり、従来の「デザイン引き継ぎ待ち」は大きく減りました。一方で、実運用では別の問題が急に目立ちます。どこまで自動生成を許可するか、どこから人間が責任を持つかが曖昧なまま走ると、短期の速度と引き換えに中長期の整合性を失います。

まず3つの責任ゾーンを固定する

System-owned: デザイントークン、タイポスケール、余白原則、a11y初期値
Product-owned: 画面構成、ユースケース分岐、実験バリアント
Engineer-owned: 状態管理、非同期制御、性能最適化、エラー処理

レイヤー生成は基本的にProduct-owned領域で活用し、System-owned領域は厳格に保護、Engineer-owned領域は自動確定しない、という原則が安全です。

「生成前契約」を用意する

導入前に、少なくとも次を文書化します。

生成対象として許可するコンポーネント範囲
変更不可のトークン集合
必須命名規則
マージ前に通すa11y要件
退行時の巻き戻し手順

これがないと、レビューが好みの議論になり、速度も品質も下がります。

速度を落とさない品質ゲート

Gate A: デザインシステム適合

生成結果が承認済みAPIとトークン境界を逸脱していないかを静的検査で判定します。

Gate B: アクセシビリティ基準

キーボード操作、フォーカス可視性、セマンティック構造、コントラストを最低条件として自動検査します。

Gate C: 実行時整合

ハイドレーション境界、バンドル予算、操作遅延目標を壊していないかをCIで確認します。

典型的な失敗と予防策

失敗1: トークンドリフト

似た値が増殖し、正規トークンを迂回する。 → 未登録エイリアスをCIで即失敗させる。

失敗2: 見た目一致・意味劣化

UIは同じでも見出し階層やARIAが崩れる。 → セマンティックスナップショットを導入する。

失敗3: 責任の押し付け合い

生成物の品質責任がデザイナー/エンジニア間で曖昧。 → PRテンプレートに責任分界を明記する。

組織運用はHub-and-Spokeが合う

Hub（共通基盤）: 生成ポリシー、Lint、テンプレート管理
Spoke（各プロダクト）: ドメイン文脈への適用、業務要件への最適化

この形だと、チームごとの独自ルール乱立を防ぎつつ、局所最適も維持できます。

追うべき指標

デザイン更新から出荷可能PRまでの時間
生成後に構造的書き直しが必要だった比率
生成UIに起因するa11y欠陥率
トークン準拠率の推移
デザイン起点PRのレビュー往復回数

書き直し率が高止まりするなら、生成レベルが細かすぎるか契約が弱いサインです。

まとめ

Figma MCPは「引き継ぎ省力化ツール」ではなく、設計契約を実行可能にする基盤です。責任分界・品質ゲート・測定を先に設計したチームほど、速度と一貫性を同時に伸ばせます。