Figma MCP を使えば、デザインファイルから直接コードを生成できます。しかし実際にプロジェクトへ導入してみると、「デザインをそのままコード化するだけ」では思ったような成果は得られませんでした。
本記事では、Vue 3 / TypeScript を使った実際のフロントエンド開発プロジェクトで、Figma MCP と Cursor を組み合わせて画面実装を行った際の運用ノウハウをまとめます。
結論：うまくいったのは AI モデルではなく実装フロー
最初に結論からお伝えします。今回の取り組みで最も効果があったのは、AI モデルの性能そのものではなく、実装フローを整備したことでした。
- Plan（実装計画）をレビューする工程が最も重要だった
- 既存コンポーネントの再利用は、プロンプトの指示だけでは十分に保証されなかった
- 実装後の確認・修正は、最終的に人間が行う前提で運用する必要があった
AI に実装を「お願いする」のではなく、AI が出した計画をレビューし、必要なら修正してから実行させる。このひと手間が、実装品質を大きく左右しました。
全体の実装フロー
ポイントは、AI に一気通貫で実装させるのではなく、計画立案 → 人間によるレビュー → 実行 → レビューという工程を必ず挟むことです。AI 任せにする範囲と、人間が確認する範囲を明確に分けたことで、実装のブレを抑えられました。
実装ルールをファイル化して毎回読み込ませる
Figma MCP をそのまま使うと、生成されるコードは React / Tailwind ベースのことが多く、既存のコンポーネントを無視して新しいものを作ってしまう傾向があります。この問題への対策として、「実装ルールファイル」を用意し、AI エージェントに毎回読み込ませる運用にしました。
ルールファイルには、主に以下を定義しています。
- 使用する技術スタックを明記する — 参考資料が古いバージョンの表記になっていても、実際のリポジトリの構成を優先させる
- 既存コンポーネントを優先させる — 新規作成の前に、似た役割を持つコンポーネントがすでにないか確認させる
- デザインツールの出力はそのまま使わない — レイアウトや余白、階層構造の参考情報としてのみ扱い、実際のコードは自分たちのフレームワーク・スタイルに変換させる
- 責務を分離させる — 画面（page）、UI コンポーネント、状態管理、ユーティリティ、型定義の役割を明確にする
- 完了条件を明確にする — 実装後にリンターや型チェックを必ず実行させ、今回の変更によるエラーと元からあるエラーを区別して報告させる
これは「過去に何度も発生した失敗」を先回りしてルール化したものです。同じルールを毎回読み込ませることで、セッションが変わっても実装の品質をある程度安定させることができました。
計画レビューが最も重要な工程だった
実装フローの中で最も重要だったのが、AI が立てた実装計画（Plan）をレビューする工程です。
計画の中に、再利用すべき既存コンポーネントが明記されているかを確認します。記載されていなければ、その場で人間が計画を編集して追記します。計画は AI にとっての「設計書」のような役割を持つため、この段階で方針を修正しておくと、その後の実装でも比較的その方針が維持されやすい傾向がありました。
逆に、計画をレビューせずにそのまま実行させると、ルールファイルに明記していても、既存コンポーネントを無視して新規のコンポーネントを作ってしまうケースが見られました。ルールを書くだけでは不十分で、実行前に人間が一度確認する工程を挟むことが、品質を保つ上で欠かせませんでした。
実装後のレビューでは、以下の観点を確認しています。
- デザインと実装の見た目が一致しているか
- 既存コンポーネントを利用しているか
- コンポーネントの責務が適切に分離されているか
- 不要なスタイルが増えていないか
見た目に差異がある場合は、デザインのスクリーンショットとコード上の該当箇所を具体的に指定して修正を依頼すると、効率よく直せます。
モデル選択とコストの実感
上位モデルと、コストを抑えたモデルとでは、実装の再現性に明確な差がありました。
上位モデルは、既存コンポーネントの再利用率が高く、ルールファイルの指示にも比較的忠実に従ってくれました。一方で、API 課金ベースで運用する際に $200／月 の利用上限を設定していたところ、わずか 5日でその上限に達しました。継続的な運用としては、コストが高くなりがちだという実感です。
コストを抑えたモデルは、同じルールファイル・同じ入力を渡しても、既存コンポーネントがあるにもかかわらず新しいコンポーネントを作成してしまうケースがありました。人間によるチェックの手間が増えるため、「低コストだから総合的に安い」とは必ずしも言えないというのが実感です。
このため、現在は計画立案の段階も含めてコストを抑えたモデルで運用しつつ、人間が計画を修正してから実行するという運用に落ち着いています。モデルの性能に依存するのではなく、レビューの仕組みでカバーするという方針です。
今後の検討事項
今回は API 課金ベースのツールで運用しましたが、上位モデルを利用すると短期間でコストがかさむことが分かりました。次回同様の取り組みを行う際は、Claude Code や Codex のような、サブスクリプション型の開発支援ツールも比較対象にしたいと考えています。これは、API の従量課金と比較して、総コストや運用効率が改善する可能性があるためです。
まとめ
Figma MCP のようなツールを使えば、デザインからコードへの変換自体は簡単に行えます。しかし、実際のプロジェクトで品質を保ちながら運用するには、AI にすべてを任せるのではなく、計画のレビュー → 実行 → 実装後のレビューという工程を人間が担う前提で設計することが重要だと感じました。
今回得られた最大の学びは、プロンプトを長く精密に書くことよりも、AI と人間の役割分担を明確にした実装フローを整えることの方が、実装の品質と生産性を両立させる上で効果的だったという点です。
