この記事の注目ポイント: FigmaはConfig 2025でFigma Makeを発表し、自然言語プロンプトや既存デザインから高忠実度のプロトタイプを生成できるようになった。これにより、プロトタイプをPRDの代替として使い、仮説検証→共有→フィードバックのサイクルを高速化する狙いだよ。GAは2025年7月24日で、Supabase連携やReactのnpmパッケージインポートもサポートする。
以下は3分で読める解説だよ。元ニュースの要点に、現場で使うときの注意点や開発者目線の補足を加えてまとめるね。
深掘り解説
まず何が変わるかを簡潔に。Figma Makeは「prompt-to-prototype」を前提にしていて、PMや非エンジニアでも会話的にプロトタイプを作れるようにしている。
主な機能は次の通り。
- プロトタイプをPRDに置き換え：テキストベースの長いPRDを減らし、インタラクティブなプロトタイプで要件確認をする流れ。
- Supabase統合：プロトタイプに簡易バックエンドをつなげて、実データに近い検証が可能。
- Reactのnpmパッケージインポート：デザインシステムや既存コンポーネントを使い、視覚と動作の一致度を高める。
- AnthropicのClaude 3.7 Sonnetを基盤にしたAIで、自然言語からUI生成。
現場でのメリットは明快だよ。意思決定が早くなる、ユーザーテストの初期段階で現実味のある挙動が検証できる、デザイナーとPMのコミュニケーションコストが下がる、という点だね。
ただし注意点もある。ツールチェーンの依存度が上がると、プロジェクトの可搬性やガバナンスが課題になるんだ。
具体的な運用上の落とし穴（エンジニア視点）:
- 出力されたプロトタイプと本番コードの差分：見た目は一致しても、パフォーマンスやエラーハンドリング、セキュリティは調整が必要。
- npmパッケージ導入の管理：プライベートパッケージやバージョン管理の運用ルールが必要。
- バックエンド接続の安全性：Supabaseなどを使う場合、ダミーデータと実データの取り扱い基準を決めておくこと。
- 責任の所在：PM主導でプロトタイプを作れる分、最終的なコード品質の責任を誰が持つかを明確に。
導入のコツとしては、まず小さな実験（1機能分）でプロトタイプ→ユーザーテスト→開発へ移すパイプラインを作ることをおすすめするよ。
チェックリスト:
- Design SystemとMake上のコンポーネントの整合性を確認する。
- npmパッケージのアクセス権・バージョン方針を決める。
- プロトタイプから本番移行までのQAフロー（テスト、セキュリティ、パフォーマンス）を定義する。
まとめ
Figma Makeはプロトタイプ主導のワークフローを現実的に後押しするツールだよ。PMや非エンジニアが仮説を素早く形にできる一方で、開発チームは出力物の品質管理や運用ルール整備を早めに取り組む必要がある。
まずは小さな機能で試して、デザインシステムとCI/デプロイのルールを合わせていくと良い。うまく運用できれば、チームの合意形成とリリーススピードがぐっと上がるはずだよ。
参考リンク
- 元記事: Prototypes are the new PRDs
- Config 2025 Launches (プレスリリース)
- Figma Make Is Now Available to All Users (GA発表)
- CMSWire: Figma Make の分析記事
- Figma リリースノート
- Figma ヘルプ: npmインポート手順等
※内容の正確性には万全を期していますが、最新の仕様や公式情報については、必ず上記の参考リンク先をご確認ください。
