Figma MCPとチケット駆動AI開発が変えるデザイン→実装プロセス

トレンドシグナル

GitHub Changelogで、VS Code経由でFigma MCPを活用しデザイン層を扱う流れが示された。
Qiita/Zennでは、Issue起点でAIに作業させる運用設計が話題化。
現場では「コードは速くなったが、設計意図の伝達ミスが増えた」という声が増えている。

本当のボトルネックは“実装速度”ではなく“連携精度”

AI導入でコード生成は高速化しました。しかし、以下の摩擦が顕在化しています。

チケットに設計意図が十分に落ちない
プロンプト品質が個人依存で再現性が低い
レビューが差分中心で、UX意図のズレを見逃す

MCPのように設計メタデータを実装環境へ接続する動きは、この意味ギャップを埋めるための重要な一歩です。

これからのデザイン→実装スタック

レイヤ1: 機械可読な設計文脈

スクリーンショット貼付だけでは不十分。コンポーネント状態・バリアント・制約条件を機械が参照できる形で持つ必要があります。

レイヤ2: チケットを実行契約にする

「何を満たせば完了か」「何を変更してはいけないか」を、AIも人も読める形で記述する。曖昧な要件はAI運用で破綻しやすい。

レイヤ3: タスク種別別プロンプト

自由入力より、類型ごとのテンプレート化が効きます。

UI不具合修正
コンポーネント移行
アクセシビリティ修正
レスポンシブ最適化

レイヤ4: 意図トレース付きレビュー

差分だけでなく「どの設計ノードを参照し、どの制約で実装したか」をレビューに添付する。ここがないと再現性が続きません。

実践パターン：Spec-Locked AI Execution

運用しやすい形として、仕様拘束型の実行パターンが有効です。

デザイン側が変更対象を限定公開
チケットに参照ノードと受け入れ条件を明記
タスク種別に対応するプロンプトテンプレを適用
実装差分を制約チェックで自動検証
差分＋意図整合の双方を満たしたら承認

この流れで「コードは正しいが体験は違う」事故を大幅に減らせます。

進捗評価に使うべき指標

行数や生成回数ではなく、プロダクト価値に寄せて計測します。

UI変更の一次レビュー通過率
意図不一致による再オープン率
デザイン承認からデプロイまでの時間
AI関与変更のアクセシビリティ回帰率

組織的に必要な変化

デザイン連携はプラットフォーム課題になる

設計メタデータが開発実行に入る以上、プラットフォーム側で次を整える必要があります。

設計コンテキストのアクセス制御
設計バージョンとコード参照の整合管理
どの設計情報で実装されたかの監査ログ

マネージャはプロンプト資産を運用対象にする

プロンプトテンプレートとチケットスキーマは、もはや任意文書ではなく運用品質を左右する資産です。責任者を置いて保守すべきです。

リスクと回避策

制約なし自動化 速度は上がるがUI一貫性が崩れる。
メタデータ境界でのロックイン 特定ツール形式に依存しすぎると将来の移行コストが高騰。
見た目品質への過信 綺麗な差分でも要件逸脱は起こる。意図検証を省略しない。

まとめ

次の勝負は「もっと賢い補完」ではなく、設計文脈・チケット契約・プロンプト統制・意図レビューを一体化した運用設計です。ここを作ったチームほど、AI実装を安定してスケールできます。