デザイナーのためのVibe Coding入門：Figma Makeでデザインをアプリに変える方法

FigmaがFigma Makeを発表して以来、デザイナーコミュニティである質問が繰り返されています。「もうエンジニアを待つ必要はない？」この問いの背景には、デザイナーの役割変化に対する不安と期待が入り混じっています。このガイドはvibe codingが世界を変えるという話をするためのものではありません。より実践的な問いに答えます。どんな状況で自分で作るべきか、そしていつ手放すべきか。4つの実際のシナリオ、ツール選定フレームワーク、プロンプト戦略を通じて、最初の一歩を明確にします。

TL;DR

• Figma Makeが最も適している場面：ステークホルダーデモ、インタラクティブプロトタイプ、デザインシステム検証（dev-handoffには不向き）
• 4つのシナリオ別判断フレームワーク：「vibe codingする vs エンジニアに渡す」の判断基準
• デザイナーのツール選定：Figma Makeで始める → LovableでMVP → Boltで素早い検証 → v0でフロントエンドコンポーネント
• リスク開示：著作権はあなたの責任、複雑さとともに品質は低下、エンジニアレビューなしで本番環境にはデプロイしないこと

まず理解すべきこと：Figma Makeでできることとできないこと

Figma Makeは2025年5月7日のConfig 2025でオープンベータとして公開され、現在は有料プランのフルシートユーザーに提供されています。コア機能は、自然言語プロンプトや既存のFigmaフレームを入力として受け取り、動作するReactアプリを出力することです。デザイナーにとって最も魅力的な点は、Figma Design Libraryを読み取り、既存のブランド設定（タイポグラフィ、カラートークン、コンポーネント）を自動適用できることです。

しかし、Figma Makeの出力コードをエンジニアに直接渡せるのでしょうか？答えはノーです。かなり深刻なレベルで。

UX Collectiveの実証レポートによると、Figma Makeは意味のない<div>タグに過度に依存したコードを生成し、<header>や<nav>といったセマンティックHTMLが欠如しています。これはアクセシビリティとSEOに深刻な影響を与えます。2025年7月のMETR研究では、AI支援を使った場合、熟練開発者でもタスク完了に19%多くの時間がかかることが判明しました。その大半はプロンプト作成、出力の待機、生成されたコードのレビューに費やされています。Figmaも明確に述べています。Figma Makeは迅速なプロトタイピングツールであり、本番対応の開発環境ではない、既存のコードベースでの反復作業には適していません。

Figma Makeが本当に輝く3つのシナリオ：

1. ステークホルダーデモ（静的デザインをクリッカブルなプロトタイプに変換）
2. デザイン決定の迅速な検証（実際のUIでトークンがどう見えるか確認）
3. ユーザビリティテスト（テスト参加者が実際にクリックできる環境）

料金：Figma MakeはフルシートのFigma有料プランが必要です。Figma Professionalは年払い$12/editor/月、月払い$15/editor/月です。Figma Makeは現在フルシートに含まれており、追加費用なしで利用できます。

4つのシナリオ別判断フレームワーク

vibe codingするかどうかを決める前に、まず問いかけてください。「この成果物の目的は何か？」

シナリオ	推奨	適したツール	理由
ステークホルダーデモ	自分でvibe coding	Figma Make、Lovable	静的フレームをインタラクティブなプロトタイプに素早く変換、静的スライドデッキに代わる
デザインシステムトークン検証	自分でvibe coding	Figma Make、Anima	実際のUIでカラー・スペーシングトークンの見え方を確認できる
社内ツールMVP	複雑さによる	Lovable、Bolt	データベースとバックエンドが必要ならLovable；フロントのみならBoltで十分
製品機能の反復	エンジニアに渡す	Cursor（エンジニアが操作）	コードベース品質管理、エッジケース処理、技術負債の管理が必要

核心的な判断基準：この成果物が本番環境に入る必要がない、またはデモ後に廃棄できるなら、自分でvibe codingする価値があります。エンジニアが後から引き継ぐことが予想されるなら、最初からエンジニアを巻き込む方が、AIが生成したコードをクリーンアップするよりも効率的です。

ツール選定ガイド：Figma Make vs Lovable vs Bolt vs v0 vs Cursor

ツールを選ぶ前に、3つの質問に答えてください：

1. バックエンド機能が必要か（データベース、ユーザー認証、API連携）？
2. この成果物は誰が使うか（自分のテスト / ステークホルダー / ユーザー / エンジニア）？
3. 学習曲線にどれくらいの時間を使えるか？

Figma Make — デザイナーにとって最も自然な出発点

Figmaエコシステムに直接組み込まれており、コンテキスト切り替えが不要です。デザインはすでにある、Makeがそれを動かします。早期コンセプト探索と迅速なプロトタイピングに最適（Muzliの2026年三層アーキテクチャのLayer 1：探索層）。制限はコード品質が低く、dev-handoffには不向きです。

Lovable — 完全なMVPを作るなら最善

「実際に使えるアプリを公開する」ことが目標なら、Lovableは現在、非エンジニアに最も優しいフルスタックツールです。データベース、ユーザー認証、バックエンドを内蔵し、平易な言葉のプロンプトで大部分の機能を実現できます。月$25から。デザインシステムは手動で記述が必要（Figma MakeがLibraryを自動読み取りするのとは異なる）。

Bolt — 最速のブラウザネイティブプロトタイピング

インストール不要でブラウザ内でプロンプトをプレビューに変換。「5分以内に結果を見たい」という検証ペースにはBoltが最適。複雑なバックエンドロジックには限界があります。月$20-30。

v0（Vercel）— フロントエンドコンポーネントの最良ツール

高品質なReact + Tailwind UIコンポーネント（ダッシュボード、ランディングページ、UIキット）を生成したいなら、v0の出力品質は現在のツールの中で高いレベルです。ただし、バックエンド/DB生成能力はなく、完全なアプリ構築ツールではありません。

Cursor — デザイナーがここから始めるべきではない

CursorはエンジニアのためのAI支援IDEであり、ノーコードツールではありません。使いこなすには、ファイル構造の理解、言語の構文、AIが生成したコードの正確性を判断する能力が必要です。コーディング知識がゼロのデザイナーにとって、Cursorの学習曲線は1週間以内に挫折につながります。まずFigma MakeやLovableで自信をつけてから、Cursorに移行するかどうかを検討してください。

実践：Figma Makeでデザインをクリッカブルなアプリに変える手順

Figmaの公式ドキュメントに基づく基本操作フローです。

ステップ1：Figmaフレームを準備する

Figma Makeに入る前に、デザインファイルがDesign Libraryにリンクされていることを確認します。Figma MakeはStyle（色、タイポグラフィ）とComponentライブラリを読み取り、ブランド設定を自動適用します。フレームがLibraryから分離している場合、Makeが視覚スタイルを推測することになり、結果は期待通りにならないことが多いです。

ステップ2：Figma Makeを起動し、最初のプロンプトを書く

Figmaのドラフトエリア右上の「Make」をクリックして新しいFigma Makeファイルを作成します。チャットパネルの「+」をクリックして「Import from Figma」を選択するか、デザインフレームを直接AIチャットにコピー＆ペーストします（現在1度に最大3フレームをサポート）。

最初のプロンプトに含めるべき内容：

• アプリの目的とターゲットユーザーを説明する
• デザインと一致させたい要素を指定する
• インタラクションの動作を定義する

例：「これはPM向けの週次レポートトラッカーです。貼り付けたデザインフレームに基づいてホームページを作成し、既存のカラーとタイポグラフィシステムを維持してください。左側にナビゲーションパネル、右側にタスクリスト、タスクアイテムをクリックすると詳細が展開されます。」

ステップ3：反復改善

Figma Makeは2つの修正方法をサポートしています。チャットでの指示入力（「見出しを一段階大きくして」「カードの影を濃くして」）か、Edit toolでプレビューの特定要素を直接クリックして修正する方法です。

ステップ4：公開またはGitHubプッシュ

満足したら、ステークホルダーのテスト用にパブリックURLに直接公開するか、NotionやプレゼンテーションにEmbedできます。さらなる開発が必要な場合はGitHubにプッシュできます（GitHubアカウントが必要）。

デザイナーのプロンプト戦略：ビジュアル言語からAI言語への切り替え

これはvibe coding初期にデザイナーが最もよく直面する障壁です。デザイナーはビジュアルで考えますが、AIはテキスト指示が必要です。Animaのデザインシステム統合研究に基づく3つの原則でプロンプト品質を大幅に向上できます：

原則1：コンポーネント名を使う、視覚的な説明ではなく

弱いプロンプト	強いプロンプト
青いボタンを作って	Button/Primaryを使用し、新しいボタンバリアントは作らないで
テキストを大きくして	見出しをHeading/H2（24px、SemiBold）に設定して
少しスペースを追加して	spacing-4（16px）のpaddingを適用して

原則2：まず全体の雰囲気（Vibe）を説明し、その後インタラクションの複雑さを追加する

すべての要件を一度に詰め込まないでください。まずAIに全体的なトーンを確立させてから、インタラクティブな動作を段階的に追加します。

良い順序：「穏やかな記帳ダッシュボードをデザインしてください。柔らかい色調、角丸カード、薄いグレーの背景で」→ 満足したら：「各カテゴリカードにクリックして展開するアニメーションを追加し、展開後にその月の明細を表示して」

原則3：外見だけでなく、使用コンテキストを説明する

「これは高齢者向けのアプリです。フォントは十分な大きさで、ボタンはタップしやすく、小さいインタラクション要素は避けてください」の方が「テキストとボタンを大きくして」よりもAIに多くの判断根拠を与えます。

公開前に知っておくべき3つのリスク

この章はこの記事で最も重要な部分だと考えています。なぜなら、ほとんどのデザイナー向けvibe codingガイドはここを省略しているからです。

リスク1：著作権責任はあなたにあり、Figmaにはない

Figma Makeの公式ドキュメントには「ユーザーがコンテンツの著作権を確保する責任を負う」と明記されています。AIは生成中にウェブからサードパーティのフォント、パッケージ、画像を取り込む可能性があります。公開前に、出所が確認できないビジュアル要素がないか確認してください。

リスク2：複雑さが増すほど品質は低下する

現在のすべてのvibe codingツールに共通する制限があります。機能の複雑さが増すにつれて、AIのコードの一貫性が徐々に低下します。アプリに複数のページ、複数の状態、複雑なデータロジックが加わると、AIは以前のデザイン決定を「忘れ」始め、新しい要素が古い要素と一致しなくなります。

実務的なアドバイス：vibe codingをより小さなスコープ（1ページ、1ユーザーフロー）に制限してください。vibe codingで完全で複雑なシステムを構築しようとしないでください。

リスク3：エンジニアのレビューなしにvibe codingアプリを本番環境にデプロイしない

セキュリティの専門家は（The New Stack, 2026）、厳密なレビューなしに本番環境にデプロイされたAI生成コードが深刻なセキュリティインシデントを引き起こす可能性があると警告しています。AIは機能を実現するために既知の脆弱性があるライブラリパターンを導入したり、動作するように見えるが実際には脆弱な認証ロジックを生成したりすることがあります。

vibe codingアプリがデモやユーザビリティテスト専用なら、リスクは管理可能です。しかし、実際のユーザーデータ、支払いフロー、ログイン機能が関わる場合は、必ずエンジニアにコードレビューをしてもらってから公開してください。

今すぐできること

デザイナーはエンジニアになる必要はありません。しかし、どんな状況で自分で作るかを選ぶことができるようになりました。Figma Makeはその選択肢を与えてくれます。うまく使えばアクセラレーターになり、誤って使えば技術負債になります。

まずステークホルダーデモ一つから始めてください。来週予定しているプレゼンを探して、静的なスクリーンショットを見せる代わりに、Figma Makeでデザインをクリッカブルなプロトタイプに変えてみてください。このツールの限界を感じてから、どこまで進むかを決めてください。

エンジニア向けのvibe codingについては、vibe coding完全エンジニアガイドでより高度なワークフローを参照できます。