デザイナーがFigmaで作った画面が、そのままアプリになる。この期待でLovableとFigmaの連携を調べ始めた方が、最初に確認すべきことがあります。連携には3つの方法があり、それぞれ取り込めるものが違うということです。
ここを知らずに「Figmaから取り込める」とだけ理解して進めると、実際に取り込んだ結果に落胆します。方法によっては、ビジュアルそのものは再現されず、色やタイポグラフィといった定義だけが渡るからです。
この記事では、2026年9月1日時点の公式ドキュメントにもとづき、3つの方法の違い、必要な環境、そして再現できる範囲の限界を整理します。なお本記事は公開情報にもとづく整理であり、実際の再現度はデザインファイルの構造によって変わります。導入前に自社のファイルで試すことを前提にお読みください。
連携には、どんな方法があるのか?
公式ドキュメントによれば、Figmaのデザイン、トークン、コンポーネントを取り込む方法は3つあります。Figmaプラグインを使う方法、Figma MCP経由で接続する方法、そして.figファイルをアップロードする方法です。
3つは代替関係ではなく、取り込める対象が異なります。他の外部サービスとの接続と同様、まず何を渡したいのかを決めることが先です。公式ドキュメントは複数の手法を併用できるとしており、実務では「デザイン定義は.figで、個別画面はプラグインで」といった使い分けが現実的です。
まず全体像を押さえてください。判断の軸は、必要な環境の重さと、取り込めるものの性質です。
| 方法 |
必要な環境 |
取り込めるもの |
| Figmaプラグイン |
FigmaのDev席以上。Lovableデスクトップアプリは不要 |
選択したフレーム・コンポーネントのビジュアルデザイン |
| Figma MCP |
Lovableデスクトップアプリ+Figmaデスクトップアプリ、Dev Mode有効化、Dev席またはFull席(Starterプラン除外) |
デザインファイルへのリアルタイムアクセスとコンポーネントのプロパティ |
| .figファイルのアップロード |
Figmaの全プランに対応。追加インストール不要 |
変数コレクション、色、タイポグラフィ、フレーム構造、参照用サムネイル |
この表で最も重要なのは3行目です。.figアップロードは最も手軽ですが、取り込まれるのは定義と構造であり、ビジュアルデザインそのものは再現されません。「ファイルを上げれば画面ができる」と誤解しやすい部分なので、期待値の設定に注意してください。
Figmaプラグインは、どう使うのか?
最も導入しやすいのがこの方法です。デザインツールから離れずに作業できます。
公式ドキュメントによれば、Lovableのプラグインをインストールしたうえで、Figma上でフレームまたはコンポーネントを選択し、Lovableのワークスペースへ送信します。選択してエクスポートするだけで、Lovable側で直接使える形になるとされています。
制約も明記されています。1回のエクスポートで最大100ファイル、各ファイルの上限は20MBです。フレームが大きすぎる場合は分割が必要になります。全画面を一度に送ろうとして失敗するのは、この制約に触れているケースです。
利用にはFigmaのDev席以上が必要とされています。デザイナーが全員Full席、実装担当がViewer席という構成の組織では、誰がプラグインを実行するかを先に決めておいてください。席の割り当てが実務上のボトルネックになることがあります。
Figma MCPは、何が違うのか?
3つのうち最も環境要件が重く、その代わり継続的な連携ができるのがこの方法です。
公式ドキュメントによれば、Figma MCPはリアルタイムでデザインファイルにアクセスし、コンポーネントのプロパティを検査して、構築時にその文脈を利用できるとされています。手動でのエクスポートが不要になる点が、プラグインとの最大の違いです。

必要な環境は多めです。Lovableのデスクトップアプリが必須で、加えてFigmaのデスクトップアプリとDev Modeの有効化、FigmaのDev席またはFull席(Starterプランは対象外)が求められます。ローカルで動くサーバーの仕組みであるため、Lovableのデスクトップアプリからのみ利用できます。
組織で使う場合には、もうひとつ条件があります。公式ドキュメントによれば、Enterpriseのワークスペースでは管理者がローカルのデスクトップMCPサーバーを有効化する必要があります。情報システム部門の承認が前提になるということです。検証を始める前に、この確認を済ませておいてください。
.figファイルのアップロードでは、何が取り込まれるのか?
最も手軽で、最も誤解されやすいのがこの方法です。取り込まれるものを正確に把握してください。
公式ドキュメントによれば、抽出されるのは変数コレクション、色、タイポグラフィ、フレーム構造、そしてレイアウト参照用に生成されるサムネイルです。カラースタイルとテキストスタイルも含まれます。Figmaの全プランで利用でき、追加のインストールは不要です。
一方で、取り込まれないものも明記されています。インタラクティブなデザインやコンポーネントはインポートされず、ビジュアルデザインそのものは再現されません。つまりこの方法は「デザインを画面にする」ためではなく、「デザインシステムの定義を渡す」ためのものだと理解すべきです。
デザイン側の準備としては、ローカル変数の活用が推奨されています。Variablesパネルで色や余白を変数として定義しておけば、その定義がそのまま渡ります。逆に、変数を使わず個別に色を指定しているファイルでは、渡せる情報が少なくなります。
実務的な使い方はこうです。まず.figでブランドの定義を渡し、続いて個別の画面はプラグインで送るか、プロンプトで指示する。この順序であれば、全画面が一貫したトーンで生成されます。
再現できる範囲の限界は、どこにあるのか?
期待値の設定が、この連携で最も重要です。ここを誤ると、デザイナーと実装側の双方に不満が残ります。
まず前提として、Figmaは静的なデザインを表現するツールであり、アプリは状態を持ちます。ホバー、ローディング、エラー、空状態、権限による表示の切り替え。これらはデザインファイルに存在しないか、存在しても別フレームとして分離されています。どの方法で取り込んでも、状態の設計は別途プロンプトで指示する必要があります。
次に、レスポンシブの挙動です。デザインファイルの特定の幅で作られたレイアウトが、あらゆる画面幅でどう振る舞うべきかは、ファイルからは読み取れません。ここも指示で補う領域です。
そして日本語特有の論点があります。公式のプロンプト・ベストプラクティスは、プレースホルダーの文言では反応する材料がないとして実コンテンツでの設計を推奨していますが、これは日本語ではさらに切実です。英字のダミーテキストで組まれたデザインに日本語を流すと、行の高さも折り返しも変わります。Figmaの段階から実際の日本語コピーで組んでおくことが、手戻りを減らす最短経路です。
コストはどう発生するのか?
連携そのものの費用と、生成の費用は別です。ここを混同すると見積もりを誤ります。
公式ドキュメントによれば、エクスポートやアップロードそのものはクレジットを消費せず、消費が発生するのはプロンプトを送信したときです。つまりFigmaからの取り込みを何度試しても、それ自体では費用は増えません。
費用が効いてくるのは、取り込んだ後の反復です。実装を担うBuild modeは使用量ベースで、変更ファイル数やロジックの複雑さ、コード探索量によって消費が変動します。デザインの再現度を上げるために細かく修正を重ねると、そのぶん消費します。
抑える方法は2つです。ひとつは、大きな方針をPlan modeで先に固めること。Plan modeはコードを書かずに計画を提示し、メッセージあたり1クレジット固定で動きます。もうひとつは、1メッセージ1変更に絞り、変更してよい範囲を毎回明示することです。消費の内訳はプロジェクト単位の利用状況で確認できます。
なお、デザインの標準化に関する機能はプランで分かれます。公式料金ページによれば、デザインシステムはPro以上、デザインテンプレートはBusiness以上とされています。ブランドガイドラインを複数人で共有する用途では、この差が判断材料になります。
取り込んだ後、公開までに何が必要になるのか?
デザインが画面になった時点は、まだ折り返し地点です。ここから先の工程を見積もっていないと、「見た目はできたのに公開できない」という状態で止まります。
まず必要なのが、データと動作の実装です。Figmaから渡るのは見た目であって、フォームの送信先も、一覧の並び替えも、権限による表示の切り替えも含まれていません。プロンプトライブラリを参照しながら、保持する項目と選択肢を言語化して指示してください。
次が公開前の点検です。公式ドキュメントによれば、公開ダイアログを開くとBasic Scanが自動実行され、行レベルセキュリティ(RLS)ポリシーのリンティングやデータベースの設定確認、依存パッケージの脆弱性が対象になります。より詳細なDeep Scanは手動で起動でき、手動実行はいずれも無料です。ただし実践ガイドにあるとおり、認証していない訪問者に何が見えるかといった業務判断は人が行います。
そして公開です。lovable.appのURLへの公開は全プランで無料ですが、独自ドメインには有料プランが必要です。デザインにこだわった外部公開ページであれば、独自ドメインの設定まで含めて計画してください。利用規約にも、ミッションクリティカルな用途には独自ドメインを使うべき旨が記載されています。
連携を試す前に、決めておくべきことは何か?
環境を整えてから試すほうが、評価が正確になります。準備なしに試すと、ツールの限界ではなくファイルの状態を評価してしまいます。
第一に、検証に使うファイルを1つ選ぶことです。代表的な画面を含み、かつ変数がある程度整備されているものが適します。整備されていないファイルで試すと、渡る情報が少なく、連携そのものの評価を誤ります。
第二に、Figmaの席の割り当てを確認することです。プラグインにはDev席以上、MCPにはDev席またはFull席が必要とされています。検証担当者の席が足りていなければ、そこで止まります。
第三に、Lovable側のプランを確認することです。プラン一覧によれば機能はプランで分かれており、業務データを扱う検証を行うなら、学習利用の既定値がプランによって異なる点も確認が必要です。2026年9月9日以降、Free・Proの顧客データは学習に利用される可能性があり、Business・Enterpriseのワークスペースデータは契約にもとづき既定で対象外です。
第四に、詰まったときの参照先を決めておくことです。公式のトラブルシューティングと、有料プランであればサポートが窓口になります。検証中に止まって放置されると、そのまま評価が終わってしまいます。
デザイナーと実装側で、どう分担すべきか?
ツールの話より、体制の話のほうが成果を左右します。連携がうまくいっている組織には共通点があります。
第一に、デザイン側で変数を整備していることです。色・余白・タイポグラフィが変数として定義されていれば、.fig経由で定義がそのまま渡り、以降の画面が一貫します。整備されていないファイルからは、渡せる情報が限られます。
第二に、状態とレスポンシブの仕様を文章で用意していることです。Figmaに存在しない情報は、誰かが言語化しなければ生成に渡りません。デザイナーが書くのか、実装側が書くのかを決めてください。
第三に、実データで組んでいることです。ダミーテキストのまま渡すと、日本語を入れた瞬間にレイアウトが崩れ、その修正が反復として費用になります。
この3点を整えたうえで、繰り返し使う前提の指示はナレッジ機能に登録しておくと、毎回書き直す必要がなくなります。配色、フォント、UI言語、命名の方針といった「変わらないこと」を書くのが要点です。
よくある質問(FAQ)
Figmaのデザインが、そのまま完全に再現されますか?
方法によります。プラグイン経由では選択したフレーム・コンポーネントのビジュアルが渡りますが、.figアップロードでは変数や構造の抽出が中心で、ビジュアルそのものは再現されないと公式ドキュメントに記載されています。用途に応じて方法を選んでください。
どの方法から試すべきですか?
環境要件が最も軽い.figアップロードでデザイン定義を渡し、次にプラグインで個別画面を送る、という順序が始めやすいといえます。MCPはデスクトップアプリと席の条件が揃ってから検討してください。
エクスポートが失敗します。
1回のエクスポートは最大100ファイル、各ファイル20MBまでという制約があります。フレームが大きい場合は分割してください。全画面をまとめて送ろうとした場合に起きやすい症状です。
Figmaの席が足りません。
プラグインの利用にはDev席以上、MCPはDev席またはFull席(Starterプランは対象外)が必要とされています。席の割り当てを変えられない場合は、.figアップロードが選択肢になります。
デザイン変更を反映し続けるには、どうすればよいですか?
継続的な連携を求めるならMCPが該当します。ただしLovableとFigmaの両デスクトップアプリが必要で、Enterpriseワークスペースでは管理者による有効化が前提になります。運用に乗せる前に環境と承認を確認してください。
取り込んだ後、デザイナーはどこで確認しますか?
生成された画面をプレビューで確認してもらうのが基本です。細部の修正は文章で再指示するより、プレビュー上で対象要素を指し示すほうが正確に伝わります。
まとめ:3つの方法は、取り込めるものが違う
LovableとFigmaの連携には、プラグイン、Figma MCP、.figファイルのアップロードという3つの方法があります。プラグインは選択したフレーム・コンポーネントのビジュアルを送るもの、MCPはデスクトップアプリを前提にデザインファイルへリアルタイムにアクセスするもの、.figアップロードは変数・色・タイポグラフィ・フレーム構造を抽出するものです。
とくに注意すべきは.figアップロードで、インタラクティブなデザインやコンポーネントは取り込まれず、ビジュアルそのものは再現されません。デザイン定義を渡すための手段として使い、個別画面はプラグインやプロンプトで補うのが実務的です。
そして、どの方法を使っても渡らないものがあります。状態の設計、レスポンシブの挙動、そして日本語での実コンテンツです。この3つを言語化する担当を決めることが、連携を成功させる条件になります。連携そのものはクレジットを消費せず、費用が効くのは取り込んだ後の反復です。
Lovableの全体像はLovableとは?できること・料金・使い方を日本公式パートナーが徹底解説を、デザイン体制を含めた導入設計のご相談は株式会社100の問い合わせ窓口でお受けしています。