Lovable（LovableAI）とは？料金・使い方とRLSのセキュリティ対策【2026年10月】

Lovable（ラバブル）は、作りたいアプリを文章で伝えると、画面・データベース・認証・公開までを含むWebアプリを生成するAIビルダーです。「LovableAI」とも呼ばれますが、正式な製品名はLovableで、公式サイトは lovable.dev です。この記事では、2026年10月時点の公式ドキュメントをもとに、料金とクレジットの減り方、生成されるコードの技術スタック、バックエンドの選び方、GitHubへの持ち出し方、公開前に確認すべきデータベースのアクセス制御を順に説明します。

まとめ：Lovableの料金・技術スタック・安全性の要点

• 何ができるか：自然言語の指示でフルスタックのWebアプリを生成し、lovable.appのサブドメインか独自ドメインで公開できる。ネイティブのスマホアプリ（React Native）は生成しない
• 料金：Freeは1日5クレジット（月30まで）。Proは月100クレジットで月額25ドルから、Businessは同じ100クレジットで月額50ドルから。コードのダウンロード、コード編集、独自ドメインはPro以上
• クレジットの減り方：Plan modeは1メッセージ1クレジット＋調査分、Build modeは作業量に応じた従量。公式の例では「ボタンを灰色に」が0.50、「認証を追加」が1.20
• 技術スタック：2026年5月13日以降に作ったアプリはTanStack Start（サーバーサイドレンダリング）、それ以前のアプリはReact＋Vite。スタイルはTailwind
• 持ち出し：GitHub・GitLab・Bitbucketと双方向同期でき、Freeでも使える。生成物の権利は利用者に帰属すると公式が明記している
• 安全性：ブラウザからデータベースを直接呼ぶ構成では、行単位のアクセス制御（RLS）の設定漏れがそのまま情報漏えいになる。2025年にはCVE-2025-48757として報告された。公開時に自動で走るQuick scanの結果は必ず確認する

社内ツールや検証用のWebアプリを短期間で作る用途には向きます。ネイティブアプリや、Python・Goなど他言語のバックエンドが必須の案件には向きません。判断の詳細は後半の章で扱います。

Lovableの正体：GPT Engineerから生まれたAIアプリビルダー

LovableAIの呼称とLovableの開発元

Lovableを開発しているのは、スウェーデンのストックホルムに拠点を置くLovable社です。前身は、Anton Osika氏が2023年に公開したオープンソースのコード生成プロジェクト「GPT Engineer」で、その商用版を2024年12月3日付の公式ブログで「Lovable」に改名しました。公式ブログは、Lovableのローンチを2024年11月と記しています。

資金調達は、2025年12月18日にシリーズBで3億3,000万ドル（評価額66億ドル）、2026年8月12日にシリーズCで4億ドル（評価額133億ドル、Menlo Venturesが主導）を公表しています。シリーズCの発表では、ローンチ以来の作成プロジェクト数が6,000万件を超えたとしています。株式会社100は、自社サイトでLovableの日本公式パートナーと案内し、日本語での契約・導入支援を提供しています。

自然言語でアプリを作る開発スタイル全般についてはバイブコーディングの語源と意味、AIが自律的にコードを書く仕組みについてはコーディングエージェントの仕組みと主要ツールの選び方で解説しています。

生成されるコードの技術スタック：TanStack StartとReact＋Vite

公式FAQによると、2026年5月13日以降に新規作成したアプリはTanStack Start（Reactベースのフルスタックフレームワーク）で生成され、サーバーサイドレンダリングで動きます。それより前に作ったアプリはReact＋Viteの構成のままで、公開URLでは検索エンジンやAIクローラー向けにプリレンダリングした内容を返します。古いプロジェクトはTanStack Startへ移行する機能が用意されています。スタイリングはどちらもTailwindです。

この違いは、Lovableの外にアプリを移すときに効いてきます。React＋Viteのアプリは静的ファイルにビルドされるので、S3＋CloudFrontのような静的ホスティングにそのまま置けます。TanStack Startのアプリはサーバー側のコードを実行するため、サーバーを動かせるホスティングが必要です。2025年以前の解説記事にある「LovableはReact＋Viteを出力する」という説明は、2026年5月以降の新規アプリには当てはまりません。

作れないもの：ネイティブアプリと他言語のバックエンド

公式FAQは、LovableはWebアプリを作るもので、React Nativeのプロジェクトは生成しないと明記しています。スマホにインストールさせたい場合の選択肢は2つで、公開したアプリをPWA（ホーム画面に追加できるWebアプリ）にするか、Capacitorで包んでApp StoreやGoogle Playに申請するかです。Capacitorの仕組みと要件はCapacitorの仕組みと採用判断で扱っています。

バックエンドの選択肢は、内蔵のLovable Cloud、Supabase連携、外部APIの呼び出しに限られます。PythonやGoでAPIサーバーを書き、それをLovableに育てさせるという使い方はできません。

Lovableの料金プランとクレジットの消費ルール

Lovableはワークスペース単位で契約し、メンバー全員でクレジットを共有します。料金は席数ではなくプランとクレジット量に応じて決まり、クレジットは開発や公開アプリの運用で消費します。公式ドキュメントのプラン表（2026年10月1日確認）の主な項目は次のとおりです。

ProとBusinessは、月間クレジットを100から10,000まで段階的に増やせます。たとえばProで月200クレジットなら月額50ドル、800クレジットの次の段階は1,200クレジット（月額294ドル）です。価格は変わることがあるため、契約前に公式の料金ページで確認してください。学生・教員は、月100クレジットのProを月払いで最大12か月50%割引で使えます。

Plan・Build・Chatの3モードで異なるクレジットの減り方

プロジェクトのチャットには3つのモードがあり、課金の仕組みがそれぞれ違います（公式のCredits and usage）。

• Plan mode：コードを変えずに変更方針をまとめる。1メッセージにつき1クレジットで、裏で調査を走らせた分が加算される
• Build mode：実際にコードを書き換える。費用は作業量に応じた従量で、公式の例は「ボタンを灰色に」0.50、「フッターを削除」0.90、「認証を追加」1.20、「画像付きのランディングページを作る」2.00クレジット
• Chat mode：コードに触れずに相談する。1日ごとの無料枠が先に使われ、2026年10月31日までの暫定の料金体系とされている

Build modeの1メッセージは最長10時間動き続けることがあり、既定では20クレジットを超えるたびに続行するか確認が入ります。大きな改修は先にPlan modeで方針を固め、その方針をBuild modeに渡す順にすると、方向違いの作業にクレジットを払わずに済みます。各返信の「More options」から、そのメッセージで使ったクレジットを確認できます。

無料プランでできることと、有料化が必要になる境目

Freeプランには月間クレジットが無く、使えるのは毎日0時（UTC）に付与される5クレジットだけです。しかも月30クレジットで打ち止めになるため、毎日使うと月の7日目以降は翌月1日まで付与されません。公式の例で数えると、小さな修正なら1日に5〜10回程度、認証の追加のような機能追加なら1日4回程度が目安です。

Freeでも公開とGitHub同期はできます。一方、Lovable上でコードを直接編集すること、コードをzipでダウンロードすること、独自ドメインをつなぐこと、公開サイトの「Edit with Lovable」バッジを消すことはできません。社外に見せるサイトとして独自ドメインで公開する段階で、Proへの切り替えが必要になります。

クレジットの繰り越しと失効の期限

ProとBusinessでは、使い残した月間クレジットが翌月に繰り越されます。ただし期限があり、月払いでは発行から2か月、年払いでは年間の契約期間が終わってから1か月で失効します。追加購入したクレジットの期限は購入から12か月です。毎日の5クレジットは繰り越されず、UTCの0時（日本時間の9時）にリセットされます。

公開したアプリのホスティングやデータベースの利用料も、Run creditsとして同じクレジット残高から引かれます。Free・Pro・Businessには毎月20クレジット分のCloud枠と4クレジット分のAI枠が付き、それを使い切ると通常のクレジットから差し引かれます。アプリを公開し続けるなら、開発に使うクレジットとは別に運用分を見込んでおく必要があります。

Lovableの使い方：プロジェクト作成から公開まで

1. lovable.devでアカウントを作り、トップの入力欄に作りたいアプリを文章で書く（画像も添付できる）
2. 生成されたプレビューを見ながら、チャットで修正を指示する。大きな変更はPlan modeで方針を確認してからBuild modeで実行する
3. ログインやデータ保存が必要なら、バックエンドとしてLovable CloudかSupabaseを有効にする
4. 公開ダイアログ（Publish）を開くと、公開前のセキュリティチェック（Quick scan）が自動で走る。指摘を確認してから公開する
5. 既定では「プロジェクト名.lovable.app」で公開される。独自ドメインは有料プランで設定する

公式ドキュメントは英語のみで、対応言語の一覧も載っていません。日本公式パートナーの株式会社100は、日本語で書いた指示の例を示して導入を案内しており、日本語での契約や導入支援も同社に相談できます。

Lovable CloudとSupabase連携の選び分け

Lovable Cloudは、データベース・認証・ファイル保存・エッジ関数をまとめて提供する内蔵バックエンドです。公式ドキュメントによると、Supabaseのオープンソース基盤の上に作られており、Supabaseのアカウントを別に作らなくても使えます。既存のSupabase連携も引き続きサポートされ、新しいプロジェクトではどちらかを選べます。

Lovable Cloudのリージョンは、有効化した時点で固定されます。後から移すことはできないので、利用者が日本にいるならアジア太平洋を選んでから有効化します。ドイツ・日本・米国東部といった国単位のリージョンは、Enterpriseプランでの個別相談です。個人情報を国内に置く必要がある案件では、Enterprise契約か、自分で東京リージョンを選べるSupabase連携を検討します。

Supabaseを直接管理したい、あるいは将来Lovableから離れる可能性が高いなら、最初からSupabase連携を選ぶ方が移行は楽です。Supabaseの認証の設計はSupabase Authの非対称JWT鍵とRLS連携で解説しています。

GitHub連携とLovableからの持ち出し方

LovableのGit同期は、GitHub・GitLab・Bitbucketのいずれか1つのリポジトリと双方向で同期する機能です（公式のGit sync解説）。Lovableでの変更はリポジトリへ、リポジトリへのpushはLovableへ反映されます。リポジトリの接続と切断ができるのは、ワークスペースかプロジェクトのオーナーまたは管理者です。

運用上の制約は次の4点です。

• Lovableが編集・同期するブランチは常に1本だけで、既定はmain。ブランチの切り替えはLovableが作業中にはできない
• 新しいブランチは、mainではなく「現在同期中のブランチ」から作られる。mainから切りたいときは先にmainへ戻す
• Lovable側とGitHub側の両方に相手に無いコミットができると、Lovableは変更を lovable-sync ブランチへpushする。手元で同じブランチを並行して触る運用は避ける
• 同期はLovableから書き出す方向で始まり、既存のリポジトリをLovableに取り込むことはできない。いったん切断して再接続すると、元のリポジトリではなく新しいリポジトリが作られる

公式は、Lovableで作ったアプリ・コード・コンテンツの権利は利用者に帰属し、商用利用も他のホスティングへの移動もできると説明しています（オープンソースのライセンスなど第三者の権利は別）。移すときに引き受ける作業も公式が列挙しており、CI/CDの構築、SSL・CDN・スケーリングの運用、データベースのバックアップ、認証とデータ分離、シークレット管理、AIプロバイダーとの契約が利用者側に移ります。Lovable Cloudを削除すると元に戻せないため、先にデータベースをエクスポートし、必要なストレージ内のファイルもダウンロードしてから作業します。

Lovableは安全か：RLS未設定によるデータ露出とCVE-2025-48757

CVE報告時点（2025年）のLovableの生成アプリは、ブラウザから公開用のAPIキー（anonキー）でデータベースを直接呼び出す構成でした。PostgreSQLでは、誰がどの行を読めるかをテーブルへの権限（GRANT）と行レベルセキュリティ（RLS）のポリシーで制御します。公開用のキーで使うロールに表の権限が付いていると、行を絞る仕組みはRLSのポリシーだけになります。RLSが無効だったり、ポリシーが緩すぎたりすると、アプリの画面を経由せずにテーブルの中身を読み書きされます。なお、スーパーユーザーやBYPASSRLS属性を持つロールにはRLSが効きません。

この問題は2025年にCVE-2025-48757として登録されました。NVDの記述は「2025年4月15日までのLovableで、RLSポリシーが不十分なため、認証されていない攻撃者が生成サイトの任意のテーブルを読み書きできる」というもので、CVE採番機関のMITREが付けたCVSS 3.1の基本値は9.3（CRITICAL）です（NVDのCVE-2025-48757）。発見者の公開記事によると、発見は2025年3月20日、Lovableへの通知は翌21日、一般公開は5月29日でした。発見者はReplit社に所属しています。Lovable側は、各アプリのデータ保護は利用者の責任だとしてこの登録に異議を唱えており、NVDにもその旨が注記されています。

責任の所在がどちらであっても、利用者がRLSを確認しなければデータは守られません。次のSQLは、Supabaseと同じanon（未ログイン）とauthenticated（ログイン済み）のロールを作り、表への権限を両方に付けた状態で、RLSの有無とポリシーによる違いをPostgreSQL 18.6で確かめた検証から、ポリシー設定部分を抜粋しています。実行にはpublic.notesテーブル、UUID型のuser_id列、authenticatedロール、auth.uid()関数と必要な権限の準備が必要です。

-- 本人の行の参照と新規追加を許可する（更新・削除は対象外）
ALTER TABLE public.notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "own notes: select" ON public.notes
  FOR SELECT TO authenticated USING ((SELECT auth.uid()) = user_id);
CREATE POLICY "own notes: insert" ON public.notes
  FOR INSERT TO authenticated WITH CHECK ((SELECT auth.uid()) = user_id);

最後の行が見落としやすい点です。書き込みの拒否は new row violates row-level security policy for table "notes" というエラーで返りました。一方、USING (true) のポリシーは「RLSは有効」という見た目のまま全件を公開します。RLSが有効かどうかだけを確認しても安全とは言えないので、ポリシーの条件まで読みます。有効化漏れを検知する手順はSupabase RLSの設定手順と有効化漏れの検知にまとめています。

現在のLovableには2種類のセキュリティスキャンがあります（公式のSecurity overview）。Quick scanは公開ダイアログを開くたびに自動で走り、RLSの無いテーブル、全員を通すポリシー、依存パッケージの脆弱性を数秒で確認します。Deep scanはアプリのコード全体を読んで権限や秘密情報の漏れを調べますが、通常は手動で実行するため、公開前と大きな変更の後に確認します。例外として、サインインなしで使えるMCP連携を持つアプリは公開時にDeep scanも自動で走り、Enterpriseでは定期実行を設定できます。公式ドキュメントも、スキャンは本格的なセキュリティレビューの代わりにはならないと明記しています。個人情報を扱うアプリなら、スキャンの後にポリシーを人の目で読むところまでを公開の条件にしてください。

アプリの外側のデータの扱いも確認します。公式FAQによると、2026年9月9日以降、FreeとProではプロンプト（添付した画像やファイルを含む）、コード、生成物などがAIモデルの学習に使われる場合があります。除外するには「Account settings → Preferences → AI model training」で学習利用を無効にします。BusinessとEnterpriseのワークスペースのデータは既定で学習対象から外れ、アプリの利用者のデータは学習に使われません。また、FreeとProで公開したアプリはURLを知っていれば誰でも開けます。閲覧者をワークスペースのメンバーなどに絞る設定はBusiness以上で使えます。

Lovableを選ばない方がよい場面と代替ツール

Lovableは、Webアプリを短期間で形にして、必要ならGitHub経由で開発者に引き継ぐ用途に向いています。次の条件に1つでも当てはまるなら、別の選択肢を先に検討します。

• ネイティブアプリが必須：React Nativeを生成しないため、Capacitorで包む追加作業が必要になる
• Python・Goなどのバックエンドが決まっている：バックエンドはLovable Cloud・Supabase・外部APIに限られる。多言語の実行環境が要るならReplit（ブラウザで開発・公開できるオンライン開発環境）の方が合う
• 毎月の費用を固定したい：Build modeは作業量に応じた従量課金で、公開後はホスティング分もクレジットから引かれる
• データの国内保管が契約条件：Lovable Cloudで日本リージョンを指定できるのはEnterpriseだけ

UIコンポーネントをNext.js前提で作るならv0（Vercel）、ブラウザ内で動くフルスタック開発ならBolt.new、非エンジニアがバックエンド込みで一気に作るならWix傘下のBase44が比較対象になります。Lovableの特徴は、Git同期がFreeプランでも使え、生成コードを外へ持ち出す前提で設計されている点です。

よくある質問

Lovableは無料で使えますか？

Freeプランで無料で使えます。毎日5クレジットが付与されますが、月30クレジットが上限です。公開とGitHub同期はFreeでもできますが、コードの直接編集・ダウンロード・独自ドメインにはPro（月100クレジットで月額25ドルから）が必要です。

Lovableは日本語に対応していますか？

公式ドキュメントは英語のみで、対応言語の一覧はありません。株式会社100は、自社サイトでLovableの日本公式パートナーと案内し、日本語での契約・導入支援を提供しています。同社は日本語で書いた指示の例を示して導入を案内しています。

Lovableで作ったアプリは安全ですか？

RLSポリシーは安全性を支えるアクセス制御の一つです。認証、サーバー側の認可、入力処理、秘密情報の管理も確認する必要があります。2025年にはRLSの不備によるデータ露出がCVE-2025-48757として報告されました。公開時に自動で走るQuick scanに加えてDeep scanを手動で実行し、ポリシーの条件が「本人の行だけ」になっているかを確認してください。

Lovableで作ったアプリは商用利用できますか？

できます。公式は、Lovableで作ったアプリ・コード・コンテンツの権利は利用者に帰属し、商用利用も他のホスティングへの移動もできると説明しています。ただし、含まれるオープンソースのライセンスなど第三者の権利には従う必要があります。

Lovableでスマホアプリは作れますか？

Lovableが作るのはWebアプリで、React Nativeのネイティブアプリは生成しません。スマホで使わせたい場合は、公開したアプリをPWAにしてホーム画面に追加してもらうか、Capacitorで包んでApp StoreやGoogle Playに申請します。

関連記事

• Bolt.newとは？料金・使い方・対応フレームワークを実データで解説【2026年版】
• Base44とは？Wixが約120億円で買収したバイブコーディングAIの料金・使い方・競合比較
• v0（Vercel）とは？料金・使い方・APIを2026年最新解説
• Supabase RLSの設定手順とAuth連携ポリシー設計｜有効化漏れの検知まで
• バイブコーディングとは？語源・由来と意味・読み方を解説【2026年版】