Figma Makeレビュー：使い方と料金、開発への引き継ぎを解説

Figma Makeが最も力を発揮するのは、プロダクトのアイデアを支えるFigmaのフレームやデザインシステムが、すでにある場合です。実際に動くWebアプリを構築でき、公式ドキュメントには2種類のバックエンドが案内されています。ただし、ここでどちらを選ぶかによって、その後GitHubで開発を続けられるかが変わります。設計した体験を検証するために活用し、顧客データを扱い始める前に、エンジニアリングへどうつなぐかを決めておきましょう。

公開されている機能とAIクレジットの付与枠は、2026年10月15日に確認しています。 本レビューでは、公開中の製品ドキュメント、作業を次の工程へ引き継げるか、引き継ぎ時にどのような制約があるかを評価します。以下の手順は、読者が試せるように用意した架空の要件に沿ったものです。ログインして実施したテストではなく、生成品質を実測した結果でもありません。

Figma Makeとは？何ができる？

Figma Makeは、プロンプトと参照デザインから、編集可能なコードで動くインターフェースを生成します。静的なモックアップを見るだけでなく、検索の操作、フォーム入力、プロダクト内の画面遷移を試すのに役立ちます。Webアプリを公開し、保存されたデータに接続することもできます。インターフェースを設計するキャンバスはFigma Design、Webサイトを構築する別の作業環境がFigma Sitesです。Makeでは、デザインをどう動かしたいかを指示し、その動作を生成します。まずはFigma Makeを開いてみてください。作成ガイドに、プロンプトからプレビューを作るまでの流れが説明されています。

Figma Makeが向いている人は？代替ツールはどう選ぶ？

Figma Makeが特に向いているのは、承認済みのインターフェースと共有コンポーネントがあり、同僚も普段からFigmaでレビューしているデザイナーやPMです。大まかなアイデアを持つ創業者も使えますが、何もない状態からプロンプトだけで始めると、その強みの多くを生かせません。

以下の比較で重視するのは、何を出発点にするか、次に誰が編集するか、どうデプロイするかです。ワークフローを評価したものであり、各ツールが最初に生成する画面の見栄えを順位付けするものではありません。

バックエンドとコードの扱いの違いは、Figmaのバックエンドガイド、Lovable Cloud、v0のフルスタック開発ガイド、Claude Designに説明されています。

Lovable：デザインファイルより先に、作りたいアプリがあるなら

Lovableは、マネージドホスティング、データベース、認証、ストレージを備えたアプリビルダーです。「顧客が依頼を送り、スタッフが管理できるようにしたい」という要件から始める創業者にとって、有力な候補になります。GitHub連携では、リポジトリのアクティブなブランチで行った変更をLovable側へ戻せます。開発者がプロジェクトに加わるときに、この点が重要になります。

一方で考えておきたいのが、運用の責任を誰が持つかです。LovableのCloudドキュメントによれば、自前のSupabaseへ移行するには、データをエクスポートし、新しいプロジェクトでスキーマを作り直す必要があります。まず、そのマネージド環境がサービスの立ち上げに合っているかで選び、将来移行するときの担当者も決めておきましょう。

v0 by Vercel：コードを中心に開発を続けるなら

Vercelのv0はフルスタックアプリケーションを構築し、標準ではNext.jsを使用します。Next.jsは、インターフェースのコードとサーバー側の機能を組み合わせるWebフレームワークです。ドキュメントでは、バックエンドのエンドポイントやデータベースへの接続も扱っています。Figmaの情報を取り込む機能もあるため、Figmaのデザインを入力に使えること自体は、Makeだけの強みではありません。

生成したアプリケーションをエンジニアが保守し、そのフレームワークを土台に開発したい場合は、v0が適しています。目の前の成果物がデザインレビュー用で、アプリのコードを引き受ける人がまだいないなら、最初からv0を標準の選択肢にする必要はありません。判断の分かれ目は、プレビューが承認された後に何をするかです。

Claude Design：プロダクトUI以外の表現も検討するなら

Claude Designは、モックアップをはじめとするビジュアル制作に対応し、コードやデザインファイルに含まれるデザインシステムの情報を利用でき、Claude Codeとも連携します。現在の製品ページには、PDF、PowerPoint、HTMLへの書き出しも記載されています。プロトタイプと、それを説明する資料の両方が必要な創業者に合う幅広さです。

会話から制作の要件を詰め、その後もClaudeや書き出した成果物で作業を続けるなら、候補になります。一方、既存のFigmaフレームを軸にレビューするチームでは、Makeのほうが手元の情報を直接生かせます。HTMLを書き出せても、それだけでアカウント、データ、デプロイの保守担当が決まるわけではありません。

さらに広く候補を比較するには、AIデザインツール一覧をご覧ください。

Figma Makeの使い方

Figma Makeは、最初のプロンプトで対象の操作を絞り込むと活用しやすくなります。「スタートアップのサービスを作って」では、プロダクトもインターフェースもモデル任せになります。設計済みの予約フローがあれば、何を採用し、何を直すかを具体的に判断できます。

Figma Makeのチュートリアル：予約画面からプロトタイプを作る

ここでは、利用者がサービスを選び、空いている日時を指定して、予約リクエストを送信するという架空の要件を使います。まずはサンプルの内容を用意し、顧客アカウントなしで始めましょう。予約をどう保存するかを決める前に、利用者がこの流れを理解できるかを確かめます。

1. 1

   フレームを準備する

   予約画面を含むFigma Designのフレームを選びます。意味が伝わるボタンラベルと、プロトタイプで表現したい選択済み、選択不可、エラーの各状態を用意してください。コピーするのはフレームそのものです。正確なデザイン情報が必要な場合、Figmaはスクリーンショットよりも、構造を持つフレームの利用を推奨しています。

2. 2

   Makeファイルを作成し、参照デザインを添付する

   ファイルブラウザーで「Drafts」を開き、「Make」をクリックします。コピーしたフレームをプロンプトに貼り付けてください。「Add context」から添付用のモーダルを開き、デザインやフレームのリンクを追加する方法もあります。会話にURLだけを記すのではなく、実際のフレームを参照情報として渡します。

3. 3

   動作と、今回実装する範囲を伝える

   添付したデザインを維持し、利用者がサービスと空き日時を選び、必須項目の入力チェックを経て、確認画面を見られるように指示します。最初のバージョンではサンプルデータを使い、バックエンドには接続しないことを明記してください。「Send」をクリックしてプレビューを生成します。

4. 4

   うまく進まない操作も試す

   必須項目を空欄にして送信する、選択できない日時を選ぶ、日時を選んでからサービスを変更する、確認画面から戻る、といった操作を試します。その結果、何が起きたのかが画面から伝わるかを確認してください。ボタンが反応するだけでは不十分で、意図どおりに反応して初めて役立ちます。

5. 5

   問題のある箇所を絞って修正する

   新しいMakeファイルでは、「Edit」で要素を選択し、プロパティを変更して「Apply」をクリックするか、具体的な問題に注釈を付けます。動作の修正と広範囲な見た目の変更は分けて行い、狙った問題が直ったかを判断できるようにしましょう。

これらの操作は、Figmaの作成手順、添付ガイド、編集ガイドに沿っています。以前に作成したMakeファイルでは、旧編集インターフェースが残っている場合があります。

予約フローに使うFigma Makeのプロンプト例

最初のプロンプト：「添付した予約画面のフレームを見た目の参照にしてください。利用者がサービスと空いている日時を選び、必須の連絡先情報を入力して、確認画面を見るまでのフローを作ってください。内容は架空のサンプルを使ってください。フレームの情報階層とコンポーネントのスタイルを維持してください。バックエンドにはまだ接続しないでください。どの部分が模擬動作なのかを説明してください。」

修正用のプロンプト：「選択したサービスが変わったら、それまで選んでいた日時を解除し、選び直す必要があるようにしてください。レイアウトと見た目のスタイルは維持してください。日時の選択欄のそばに、その理由を説明する文を表示してください。」

これは、最初の指示と修正後に求める仕様を示した例です。実際の生成結果を報告しているわけではありません。最初のバージョンが、変更後のサービスでは使えない日時をそのまま引き継いでしまうなら、修正の対象は状態管理の問題です。前の選択が変わったとき、アプリケーションは保持している情報も更新する必要があります。

仕上がりの基準も具体的にします。テキストの折り返し、キーボードフォーカス、選択できない状態、長いサービス名、幅の狭い画面でのレイアウトを確認しましょう。見栄えのよいスクリーンショットでは、これらを確かめられません。レビューする人がタスクを完了でき、操作ができないときにはその理由を理解できてこそ、プロトタイプに価値があります。

Figma Makeでデザインシステムを使う：色以外のルールも引き継ぐ

Figma Makeは、完成画面をまねるだけでなく、デザインシステムのコンポーネントやルールを使えると、さらに役立ちます。デザイントークンとは、色や余白などの値に名前を付けたものです。コンポーネントは、動作が定義された再利用可能なUI要素を指します。トークンの値が合っていても、適切なコンポーネントを使っているとは限りません。

Figma Make kitsの活用

Figma Make kitsでは、npmパッケージ、公開済みライブラリのスタイルと変数、文章で記したガイドラインを組み合わせられます。npmパッケージは再利用可能なコードを配布するためのものなので、キットには見た目の参照だけでなく、実装に必要な情報も含められます。公式の手順は「Settings」→「Create a kit」→「Assemble your kit」と進み、アセットを追加してガイドラインを記述し、テストしてから同僚向けに公開する流れです。キットを使うには、有料プランのFull seatが必要です。FigmaのMake kitsガイド

アプリのプロンプト欄で「Select a Make kit」をクリックし、フローを生成する前に公開済みのキットを選びます。予約の例なら、承認済みのボタン、入力欄、日時選択のコンポーネントがあれば含めてください。そのうえで、使い方のルールを説明します。プライマリーボタンは有効なリクエストを送信するために使う、空いていない日時は見分けられる状態で残しつつ選択できなくする、入力チェックのメッセージは修正が必要な項目のそばに置く、といった内容です。

こうしたルールは、「ブランドらしくして」という指示よりも重要です。生成された紫色の長方形はプライマリーボタンに似ていても、無効状態、フォーカスの表示、アクセシブルなラベルが欠けているかもしれません。アクセントカラーが見慣れた色かだけでなく、コンポーネントの使い方と操作の意味が適切かを確認しましょう。

事前の準備も必要です。Figmaのパッケージ要件では、ビルド環境で動作することと、周辺のワークスペースの存在に依存しないことが求められています。現在のコンポーネントが、大きなリポジトリ内に点在する非公開モジュールに依存しているなら、エンジニアにパッケージの準備を依頼してください。

ライブラリから抽出できても、トークンが完全に保たれるわけではありません。 Make kitsのガイドによると、変数の一部を抽出し、値を直接記述した簡略なCSSに変換するため、元の変数構文はそのまま保持されません。状態に関するルールはガイドラインに記し、生成されたスタイルを確認してから、プロトタイプにデザインシステムが正しく引き継がれているかを判断してください。

Figma Makeのテンプレート

Figma Makeのテンプレートは、同じような画面や体験を繰り返し作るときの出発点に向いています。一方、キットは再利用するデザインシステムの情報を渡すものです。レビュー済みの予約フローの土台を作っておけば、同僚はそこから派生版を作れます。Figmaは、ほかの共有と再利用の方法とあわせてテンプレートを説明しています。

プロジェクトで常に守るルールにはガイドラインを使い、明示的に呼び出して繰り返し行うレビューにはカスタムスキルを使います。すでにデザインシステムを運用しているチームには、当サイトのFigma Makeカスタムスキル・デザインシステムパックが構成のたたき台になります。指示は自分たちのトークンとコンポーネントに合わせて調整してください。レビューの最終判断は、人が行う必要があります。

データが残るWebアプリを作る

Figma Makeのドキュメントには現在、アプリケーションのバックエンドとコンテンツ管理システムであるPayloadと、データベースおよびバックエンドサービスのSupabaseが案内されています。バックエンドは、目に見えるインターフェースの裏で情報を保存し、処理を行います。予約の確認画面を表示するだけなのか、利用者がブラウザーを閉じた後もスタッフがその依頼を取り出せるのかは、ここで変わります。

Payloadでは、作りたいアプリを説明してバックエンドの作成を承認し、コンテンツ管理画面である「CMS」タブからレコードを管理します。アプリとデータはFigmaがホスティングします。Supabaseは、Makeの「Settings」→「Integrations」→「Supabase」から別途接続します。MakeでのSupabaseの設定は、関連付けられたテーブルからなる完全なデータベーススキーマを作る方式ではなく、単純なデータ項目を保存するキーバリューストアを使います。Figmaのバックエンドドキュメント

同じ予約の要件で続けるなら、次のように指示します。「サービスと予約リクエストを管理するPayloadバックエンドを追加してください。利用者はリクエストを送信でき、スタッフはそれを管理できるようにしてください。公開するサービス情報と非公開の連絡先情報を分けてください。アクセスルールは、実装する前に説明してください。」

続いて、管理画面から保存されたリクエストを確認します。利用者向けの画面を再読み込みし、意図した保存済み情報が読み込まれることを確かめてください。未認証の利用者がスタッフ専用のレコードにアクセスできないかも確認します。これらは、自分たちの実装を受け入れるための確認項目です。生成した時点で満たされていると保証するものではありません。

予約を申し込む仕組みと、予約枠を確約する仕組みは別物です。 リクエストであれば、スタッフの承認を待つことができます。予約を確定するには、競合する申し込み、キャンセル、空き状況の変化に対応するルールが必要です。確実な予約枠を提供する業務なら、このフローを完成と判断する前にエンジニアに参加してもらいましょう。

実務上の利点は、インターフェースとレコード管理の作業を一緒に検証できることです。ただし、誰が責任を持つかは明確にする必要があります。データモデル、権限、復旧の手順は、誰かが決めなければなりません。管理画面を生成しても、業務上の判断まで代わりに行ってくれるわけではありません。

公開方法と、その後の運用担当を決める

Figma Makeからは直接公開できます。Figma Sitesを経由する必要はありません。Makeで「Publish」をクリックし、タイトルを設定してアプリを公開します。専用URLが発行され、カスタムドメインも設定できます。その後に変更を加えたら、公開版を更新する必要があります。Makeの公開ガイド

予約プロトタイプでは、見てもらう相手がレビュー担当者なのか、見込み顧客なのかを決めましょう。レビュー担当者には、模擬動作の範囲を正確に伝える必要があります。顧客には、分かりやすい確認、間違いを訂正する方法、送信されたリクエストに対応する担当者まで含めたサービスが必要です。最終レビューはデプロイ済みのURLで行い、訪問者が実際に使う状態を確認してください。

Figma Sitesでの公開が向いている場合

Figma Sitesは、画面上でデザインを編集しながら維持するマーケティングサイトに向いています。公式に案内されている手順は、Figma DesignのフレームをSitesのブレークポイントへコピーし、レスポンシブレイアウトを調整して公開する流れです。ブレークポイントとは、特定の表示幅の範囲に合わせて用意するレイアウトです。ページの構成や更新が主な作業になる場合に役立ちます。デザインをFigma Sitesへ移す

予約の操作にはMakeを使い、その周辺のマーケティングサイトには、担当者にとって編集しやすいならSitesを検討するとよいでしょう。ただし、外部へ持ち出す方法が両製品で同じだとは考えないでください。FigmaのSitesの公開ドキュメントには、サイトのコードを外部公開用にエクスポートすることは現在できないと記載されています。

エンジニアへの引き継ぎに含めるもの

Figma Makeのコードエディターでは、ZIP形式でのダウンロードが可能です。現在のGitワークフローのドキュメントでは、アクセスが許可されたGitHubリポジトリをクローンし、ブランチで作業して、プルリクエストを作成する方法も説明されています。プルリクエストを使うと、共有のアプリケーションに変更を取り込む前に、エンジニアがレビューできます。これらは出発点も必要な条件も異なる方法です。

コードと一緒に、意図する動作、模擬動作だと分かっている機能、データの管理責任、アクセスルール、未解決の不具合も引き継ぎます。予約フローなら、日時の選択が申し込みなのか、確定した予約なのかを明記してください。曖昧なままでは、エンジニアが受け取るのは、誤った業務ルールをきれいに実装したアプリになりかねません。

Figma Makeの料金を考える：AIクレジットの付与枠

デザインシステムをチームで共有して作業するなら、ProfessionalのFull seatを選びましょう。月3,000 AIクレジットが含まれ、Starterの付与枠は月500、1日あたりの上限は150です。Makeは共通のAIクレジット枠を消費し、消費量はモデル、タスク、参照情報によって変わります。シートに付与されるクレジットは毎月リセットされ、翌月には繰り越されません。契約を決める前に、FigmaのAIクレジットの仕組みとFigmaの料金を確認してください。クレジットの付与枠は、完成させられるプロトタイプ数の保証ではありません。

導入前に押さえたいFigma Makeの制約

Figma Makeの制約は、選んだワークフローによって変わります。「バックエンドは作れない」と考えるのも、「プロダクト全体を任せられる」と考えるのも、導入判断の前提として適切ではありません。

Payloadでホスティングするアプリは、現時点ではGitで開発を続けられない

Figma MakeのPayloadバックエンドのドキュメントには、Payloadを使うアプリでは、GitHub連携とローカルのコードベースで作業する方法がまだ利用できないと記載されています。また、現在のPayloadのホスティング先は米国東部です。アプリを作った後に気付く細かな仕様としてではなく、選定を左右する条件として扱ってください。Payloadの制約

エンジニアがすぐに自分たちのリポジトリで同じプロジェクトを引き継ぐ必要があるなら、Payloadを選ぶ前に、対応可能な方法を確認しましょう。今後の機能追加が予定されていても、今必要な引き継ぎの条件を満たすことにはなりません。

Figma MakeとFigma Designの間で、変更が自動的に往復するわけではない

Figma Makeの標準の「Copy design」は、現在のプレビューから編集可能なレイヤーを作成します。そのレイヤーは静的なもので、Makeファイルから切り離されており、デザインシステムにも自動では紐付きません。ただし、利用可能な変数を対応付けることはできます。Copy designのドキュメント

コピーは、デザインへの意見を集めたり、見た目の方向性を検討したりするために使います。キャンバスで日時選択のUIを変更したら、その変更を動作するアプリへどう戻すかを明確に決めてください。そうしなければ、デザインレビューとプロトタイプが、気付かないうちに別のプロダクトを示すようになります。

Git関連の機能は、それぞれ仕組みが異なる

Figma Makeの別機能であるPush to GitHubは、専用のリポジトリを作成し、一方向にプッシュします。その後のプッシュによって、Makeの外で行った編集が上書きされる場合があります。この制約を、先ほど説明した新しいリポジトリのクローン方式にも当てはめてはいけません。

ローカルのコードベースで作業する方法も、別の選択肢です。ドキュメントでは、Mac用のFigma Betaデスクトップアプリと参加が認められたアカウントを使う、限定的なクローズドベータとして案内されています。リポジトリのセットアップも必要です。デザイナーが既存の本番アプリを直接編集できると約束する前に、チームがどの方法を利用できるかを確認しましょう。

公開アプリのパスワードは、すべての共有リンクを保護するわけではない

Figma Makeのパスワード保護は公開済みアプリに適用され、プレビューにはファイルの共有権限が適用されます。機密性のあるコンセプトをチーム外へ送る前に、両方を確認してください。公開と共有では、それぞれアクセスを判断する必要があります。公開とアクセスの設定

生成された動作にも、受け入れ基準が必要

Figma Makeでは、難しい業務上のケースが解決していなくても、フローが完成したように見えることがあります。予約の例なら、競合するリクエスト、キャンセルされた予約、アクセシビリティ上の問題で操作できないUI、誤解を招く確認表示を評価してください。これらはレビューで確認すべき項目であり、今回のテストで観測した不具合ではありません。

公開できる状態とは、「想定する利用者がタスクを完了でき、担当者がその結果に対応できる」状態だと考えると実用的です。本物らしいモックアップだけでは、どちらの条件も満たせません。

結論：Figma Makeで体験を検証し、その先の運用まで決める

Figma Makeは、すでにFigmaのアセットを持ち、実際に動くプロダクト体験を評価したい創業者、PM、デザイナーにとって、有力な選択肢です。キット、対象を絞った編集、バックエンドの選択肢を使うことで、画面の見た目を超えた議論ができます。

ただし、選んだワークフローを次の担当者が引き継げないなら、判断は変わります。 ホスティングされたPayloadアプリは、コンテンツやリクエストの管理に適している場合がありますが、すぐにエンジニアへ引き継ぐなら、現時点のGitの制約が重要になります。アプリを起点に、マネージド環境とGit同期を使って始めるならLovable、開発者が保守するNext.js中心の構成ならv0、幅広いビジュアル表現を検討してClaudeで作業を続けるならClaude Designが向いています。

来週は、代表的なフレームを用意し、一連の操作が完結する最小の体験を作ってみてください。そして、最終的に担当する人に、その後の開発や運用へ進む方法をレビューしてもらいましょう。プロトタイプと引き継ぎ方法を一緒に承認することは、画面をさらに増やすよりも意味のある到達点になります。

よくある質問

Figmaでは何を作れますか？

この記事のワークフローでは、インターフェースの設計にFigma Design、実際に動く操作やアプリの生成にMake、画面を見ながらWebサイトを構築したい場合にSitesを使います。作業環境を選ぶ前に、作りたい成果物を決めましょう。

Figmaで新しいファイルを作るには？

Makeファイルを作るには、ファイルブラウザーで「Drafts」を開き、「Make」をクリックします。フレームを添付し、実現したい動作を説明してください。上記のチュートリアルは、Figmaの公式な作成手順に沿っています。

FigmaはUIツールですか、それともUXツールですか？

どちらの作業にも関係します。UIは人が見て操作するインターフェース、UXはタスクを完了するまでの体験です。Makeは実際に動くフローを検討するのに役立ちますが、適切な課題を解決しているかという調査と判断は、利用する側が担います。

Figma DesignとFigma Makeはどう違いますか？

Figma Designはデザインを作るキャンバスで、Makeはコードで動くインターフェースを生成します。標準の「Copy design」を使うと、静的な見た目を編集可能なレイヤーとして戻せますが、その後の変更が自動的に同期されるわけではありません。

Figma Makeよりも適したツールはありますか？

用途によってはあります。マネージドのアプリとバックエンドにはLovable、Next.jsを中心とした開発フローにはv0、さまざまな形式でビジュアルを検討するならClaude Designが有力な代替候補です。Makeの最大の強みは、手元にあるFigmaのデザインとデザインシステムを出発点にできることです。

Figma離れは進んでいるのでしょうか？

本レビューでは、顧客の移行動向を測定していません。個別の不満や乗り換え事例だけでは、全体の傾向は分かりません。自分たちの判断では、今のワークフローで完了できないデザインや引き継ぎの作業を、具体的に特定してください。

Figmaはなぜ下落しているのですか？

この問いが指すのは、株価、利用状況、あるいは製品に対する誰かの評価かもしれません。いずれも、それだけでMakeが自分たちのワークフローに合うかは判断できません。本レビューは市場での業績や評価を論じるものではなく、ドキュメントに記載されたデザイン、バックエンド、引き継ぎの方法を評価しています。

Figmaの最大の競合はどのツールですか？

Makeのすべての用途に対応する競合が、1つに決まるわけではありません。今回の導入判断では、アプリを起点に構築するならLovable、コードで開発を続けるならv0、会話からビジュアル制作を進めるならClaude Designを候補にしてください。実際に完了させたい作業に照らして比較しましょう。

CanvaとFigmaはどちらがよいですか？

この記事で扱うプロダクトのインターフェース設計なら、Figmaを選びましょう。マーケティング素材が必要なら、上で紹介したAIデザインツールの比較を使い、成果物に応じて選んでください。本レビューでは、CanvaとFigmaの出力品質を順位付けしていません。

Figma Makeは無料で使えますか？

StarterでMakeを試せます。公式に記載されている制約には、チームライブラリのスタイルを参照情報として使えないことや、Webへの一般公開がFigma Communityへの公開と結び付いていることがあります。機密性のあるプロダクトをチームで扱うなら、有料のFull seatを使うワークフローを検討してください。Figma Makeの利用条件と、上記のクレジット付与枠を確認しましょう。

ワークフローを採用する前に、AI業務ワークフロー監査チェックリストを使って、プロトタイプの担当者、必要なデータ、引き継ぎ方法を明確にしましょう。