Lovableとは？料金・無料プラン・使い方・日本語対応・Boltとの違いを徹底解説【2026年最新】

Lovable（ラバブル）とは、AIとチャットで対話するだけでWebアプリ・Webサイトを、画面からデータベース・公開（デプロイ）まで丸ごと構築できる「AIアプリビルダー」です。スウェーデン・ストックホルム発のスタートアップが開発し、2026年6月にTechCrunchが報じた時点で年間換算収益（ARR）5億ドル超・週100万件の新規プロジェクトという規模に達しています。

料金は無料プラン（1日5クレジット・月30まで）から使え、本格利用はPro月25ドル〜。2026年に課金体系がクレジット一本化され、ビルド・ホスティング・バックエンド実行・アプリ内AIをすべて1つの残高で賄う仕組みに変わりました。

この記事でわかること

• Lovableの定義・提供形態・作られる技術スタック（2026年9月時点）
• 無料プランでどこまでできるか／Pro・Business・Enterpriseの料金とクレジットの消費ルール
• Build／Planモード、Lovable Cloud、アプリ内AI、Git連携など現行機能
• 日本語対応の実態とデータ保存リージョン
• 登録から公開までの使い方の流れ
• Bolt・v0・Replit・Cursorとの選び分け
• 2026年4月に起きた情報露出インシデントの公式説明と発見者側の主張、公開前に確認すべき項目

この記事が想定する読者は、「コードは書けないがアプリのアイデアを形にしたい起業家・事業担当者」「社内の非エンジニア部門にAI開発ツールを展開できるか検討している情報システム・DX担当者」「BoltやCursorと比べてLovableを選ぶべきか迷っている人」です。

記載の料金・機能は2026年9月時点の公式ドキュメント・公式料金ページに基づきます。この領域は変化が速いため、契約前に公式ページで再確認してください。

Lovableとは：AIとの対話だけでフルスタックのWebアプリを作るツール

出典: Lovable 公式サイト

Lovableは、自然言語の指示（プロンプト）からWebアプリケーションを一気通貫で生成するブラウザ完結型のSaaSです。従来のノーコードツールと決定的に違うのは、ドラッグ＆ドロップの部品を並べるのではなく、実際のReactコードとバックエンドが生成される点にあります。生成物はGitHub／GitLabに同期でき、直接ダウンロードもできます。

「バイブコーディング」を最も広い層に届けたツール

Lovableのコンセプトは、コードの1行1行を制御するのではなく「こういうものが欲しい」とAIに伝えて開発するバイブコーディングです。実装の詳細をAIに委ね、人間は意思決定とレビューに集中するという発想で、プログラミング経験のない層まで開発の担い手を広げました。

バイブコーディングという手法そのものの仕組み・リスク・他ツールとの関係は、バイブコーディングとは？仕組み・ツール比較・リスクと始め方で体系的に整理しています。

数字で見るLovableの現在地（出典と時点を明記）

Lovableの規模は、バイブコーディング系ツールの中でも突出しています。ただし数字は報道時点で大きく変わるため、必ず「いつ・どこ発表か」とセットで理解してください。

ネット上でよく見かける「年商500億円突破」という表現には注意が必要です。 5億ドルは1ドル140〜150円換算で概ね700〜750億円規模であり、500億円という円換算は1ドル100円相当の古い前提に基づいています。さらにARRは会計上の年間売上ではなく、直近の月次収益を12倍した年間換算のランレートである点も、正確に押さえておきたいところです。

公式データレポートによれば、ユーザーの約3分の2はテック業界以外（教育・小売・メディア・金融・医療・不動産など）で、回答者の8割が「作ったものを収益化する意向がある」と答えています。趣味の試作ではなく、事業として使う層が中心になりつつある、というのが2026年のLovableです。

Lovableでできること：現行の主要機能

出典: Supabase 公式サイト

Lovableの中核は「チャット指示だけで、動いて公開されるところまで到達できる」ことです。2026年に入ってからモードの設計が刷新され、バックエンド・AI機能・チーム運用の各領域が大きく拡張されました。

「モードの刷新」が実務に与える影響

2026年時点でよく誤解されているのが、モードの名称です。かつての「Default／Chat／Agent」という3分割は現行のドキュメントには存在せず、現在はBuildモード（実装）とPlanモード（設計・調査）の2本立てに整理されています。

実務上のポイントは2つです。ひとつは、Planモードが1メッセージ1クレジット固定であること。要件が固まっていない段階でいきなりBuildを走らせるより、Planで方針を詰めてからBuildに渡す方が、結果的にクレジット消費を抑えられます。もうひとつは、Buildモードが最長10時間の長時間実行に対応したことで、「指示を出して離席し、戻って結果をレビューする」という使い方が現実的になった点です。

なお、仕様を先に固めてから実装させるアプローチをより厳密にやりたい場合は、仕様駆動を設計思想に組み込んだKiro（AWSの仕様駆動AIコーディングIDE）のような選択肢もあります。

アプリ内AIで使えるモデル（Claudeは非対応）

Lovable AIで内蔵コネクタとして提供されているのは、現時点ではGoogleのGemini系とOpenAIのGPT系です。公式ドキュメントにはAnthropic（Claude）のモデルは内蔵コネクタでは提供されないと明記されており、使いたい場合は自前のAPIキーを用意してバックエンド関数から直接呼び出す必要があります。「作るアプリにClaudeを組み込みたい」という要件がある場合は、最初から手間が発生する前提で計画してください。

LLMを組み合わせたAIアプリを作ること自体が目的なら、GUIでワークフローを組むDifyのようなアプリ開発基盤の方が適するケースもあります。

Lovableの料金プラン：クレジット一本化と無料枠の実力

2026年のLovableは、料金体系が大きく変わりました。かつては「ビルド用のサブスク」「Cloudホスティングの残高」「アプリ内AIの残高」が別々に課金されていましたが、現在は1つのクレジット残高で、ビルド・ホスティング・バックエンド実行・アプリ内AIをすべて賄う方式に統合されています。

もうひとつの重要な特徴が、席（シート）課金ではないことです。公式の料金ページは「プランは含まれるクレジット量で価格が決まり、席数では決まらない」と明記しており、ワークスペースのメンバー数は全プランで無制限です。非エンジニア部門への横展開を検討する企業には、この構造が効いてきます。

プラン一覧（2026年9月時点）

ProとBusinessは、同じプラン内でクレジット量に応じた段階的なティアが用意されています。たとえばProは100クレジット月25ドルから始まり、400クレジット月100ドル、1,000クレジット相当のティアを経て、10,000クレジット月2,250ドルまで。Businessは同じクレジット量でおおむねProの2倍の価格（100クレジット月50ドル、10,000クレジット月4,300ドル）です。年払いにすると月払い10か月分相当になり、実質2か月分が割引されます。

クレジットの消費・失効ルール（ここでつまずきやすい）

ここで混同されがちなのが、サブスクの実効単価とトップアップ単価は別物という点です。Proは月25ドルで100クレジットなので実効1クレジット0.25ドルですが、追加購入は1クレジット0.30ドル。Businessは実効0.50ドルに対し追加購入0.60ドルです。「使い切ってから買い足す」運用は、最初から上位ティアを選ぶより割高になります。

無料プランでどこまでできるか

Freeプランは1日5クレジット・月30クレジットが上限です。Buildモードの消費目安（0.50〜1.70クレジット）で計算すると、1日あたり3〜10回程度の指示が現実的な範囲になります。

• できること: 小さなランディングページや簡単なCRUDアプリを作り、.lovable.app のURLで公開して人に見せる。Cloud付与分20クレジット/月の範囲でDB・認証を試す。GitHubに同期してコードを持ち出す
• できないこと: 独自ドメインの設定、コードのエディタ内編集、デザインシステム、トップアップによるクレジット追加。月30クレジットの壁があるため、作り込みや長期の改修は途中で止まる

つまりFreeは「操作感とクレジット消費ペースを掴むためのお試し枠」と割り切るのが妥当です。1つのアプリを最後まで仕上げるつもりなら、Pro（月25ドル／100クレジット）が実質的な出発点になります。

人数が増えたときの料金構造（席課金との差）

Lovableがメンバー数で課金されないことは、チーム展開時に効いてきます。席課金モデルのツールとの構造差を整理します。

ただし注意点があります。人数が増えれば当然クレジット消費も増えるため、実際には上位ティアへの引き上げが必要になります。あくまで「使った分だけ課金され、使っていないメンバーの席代は発生しない」という構造の違いであり、無条件に安くなるわけではありません。逆に言えば、「全社に配布するが実際に触るのは一部」という導入初期のフェーズでは、この構造は明確に有利に働きます。

日本語対応とデータ保存リージョン

AIへの指示は日本語で問題なく通ります。一方、管理画面・エディタのUIは英語です。 「飲食店の予約管理アプリを作って。ログイン機能とカレンダー表示が欲しい」といった日本語プロンプトはそのまま解釈されますが、設定画面のメニューやエラーメッセージは英語で表示されるため、完全な日本語ローカライズを期待すると差を感じます。現時点の公式ドキュメントにはUI言語の切り替え設定に関する記載を確認できませんでした。

生成されるアプリの中身（画面文言・データ）を日本語にすることは当然可能です。日本語で指示すれば日本語UIのアプリが生成されます。

データの保存先については、Lovable CloudがAmericas / Europe / Asia Pacificの3リージョンから選択できます（2026年2月に拡張）。国内向けサービスでデータ所在地の要件がある場合は、プロジェクト作成時にAsia Pacificを選ぶことが検討の前提になります。ただしリージョン選択はCloudの機能であり、外部Supabaseを使う場合はSupabase側のリージョン設定に従います。

Lovableの使い方：登録から公開までの流れ

プログラミングの知識は不要で、すべてチャットと画面操作で完結します。

1. アカウント作成 — lovable.dev にアクセスし、Google・GitHub・Appleアカウントまたはメールでサインアップ。Freeプランはクレジットカード不要
2. バックエンド方式を決める — 新規プロジェクトでは、内蔵のLovable Cloudか外部Supabaseかを選びます。この選択は後から変更しにくいため、着手前に決めておくべき項目です
3. Planモードで方針を固める — いきなり作らせる前に、「どんな画面構成にすべきか」「認証はどう設計するか」をPlanモードで詰めます。1メッセージ1クレジット固定なので、試行錯誤のコストが読めます
4. Buildモードで作らせる — 「◯◯を作って」と日本語で指示すると、UI・ロジック・必要ならDBまで生成され、その場でプレビューできます。指示が具体的なほど手戻りが減り、結果的にクレジット消費も減ります
5. 動作確認と修正 — プレビューで触りながら「ボタンを大きく」「一覧をページングに」と追加指示します。エラーが出た場合もBuildモードが調査から修正まで担当します
6. セキュリティスキャンを実行 — 公開前にBasic scan／Deep scanをかけ、RLSポリシーの設定ミスや露出したシークレットがないか確認します
7. 公開する — 標準では <プロジェクト名>.lovable.app に公開されます。Pro以上なら独自ドメインの設定も可能で、2026年9月以降はチャット経由でドメインの購入・設定まで完結します
8. 必要ならコードを持ち出す — GitHub／GitLabに同期するか、直接ダウンロードして開発者に引き継ぎます

プロンプトの書き方や、AIに作らせたものをどう検証するかといった実践面は、バイブコーディングのやり方｜初心者向け5ステップ実践ガイドで手順として整理しています。

生成物の所有権とエクスポート可否

生成されたコードは利用者のものです。 GitHub／GitLabとの双方向同期に対応しており、GitHubを使わずにLovableから直接ダウンロードすることもできます。リポジトリは全プランでデフォルトprivateです。コミットの作者表記はLovableのbotですが、操作したメンバーのGitHubメールアドレスがco-authorとして付与されます。

ただし、実務上おさえておくべき制約が3つあります。

• 既存のGitHubリポジトリをLovableに取り込むことはできません。 エクスポート方向のみで、インポートは非対応です。つまり、すでに動いている自社プロダクトの改修にLovableを使うことはできません
• Lovableが同時に編集・同期できるのは1ブランチのみ（通常はデフォルトブランチ）です
• GitHub Enterprise Cloud／ServerはEnterpriseプランのみ対応です。github.com は全プランで利用できます

「既存コードベースに機能を足したい」というニーズは、LovableではなくCursorのようなエディタ統合型のAI開発ツールやWindsurf（Devin Desktop）の領域です。ここは競合というより明確な住み分けと考えてください。

Lovable CloudとSupabase、どちらを選ぶか

新規プロジェクトでは、バックエンドをLovable Cloud（内蔵）にするか、外部のSupabaseにするかを選びます。公式ドキュメントは、Lovableのツールでは両者の相互移行がサポートされていないと明記しています。最初の選択が後から効いてくる、実質的に後戻りしにくい判断です。

迷った場合の基準はシンプルです。Lovableだけで完結させるならCloud、他のシステムからも同じDBを使う計画があるなら外部Supabase。特に「将来的にLovableから卒業して自前開発に移行する」構想があるなら、最初から外部Supabaseにしておく方が移行の負担は軽くなります。

LovableとBoltの違い：クレジット課金とトークン課金

出典: Bolt 公式サイト

Lovableと最も比較されるのが、StackBlitzが提供するBolt（bolt.new）です。どちらもブラウザでAIにアプリを作らせるツールですが、課金の単位と対象ユーザーが異なります。

本質的な違いは3点に集約されます。

1. 課金単位の違いが予算の立てやすさを左右する。 Lovableのクレジットは「1タスクいくら」に近く、Planモードなら完全に固定です。Boltのトークン課金は生成量に比例するため、大きなファイルを扱うと消費が読みにくくなります。一方でLovableも、複雑なタスクは1メッセージで1.7クレジットを消費することがあり、デバッグの往復が増えれば当然コストは膨らみます。

2. チーム規模が大きいほど総額差が開く。 Boltは Teams が1メンバー月30ドルの席課金なので、10名なら月300ドル。Lovableは同じクレジット量なら人数に関係なく固定です。「部門に配布するが常用するのは数名」という日本企業の典型的な導入パターンでは、この差が効きます。

3. ガバナンス機能に到達する価格が違う。 LovableはBusiness（月50ドル〜）でSSO・セキュリティセンター・ロールベースアクセス制御まで届きます。Boltは同等の機能がEnterpriseの個別見積になるため、中小規模でガバナンスを効かせたい場合はLovableの方が閾値が低い、という判断ができます。

逆にBoltを選ぶべきなのは、フレームワークを自分で選びたい場合と、既存のプロジェクトを取り込んで続きから作りたい場合です。ここはLovableが構造的に対応していない領域です。

v0・Replit・Cursorとの選び分け

Lovableと従来型ノーコード（Bubble・Glide・Power Apps等）の決定的な違いは、成果物がReactコードとして持ち出せるかどうかです。ノーコードはプラットフォームにロックインされますが、LovableはGitHubに同期して開発者に引き継げます。「まず非エンジニアが作り、伸びたらエンジニアが引き取る」という移行が設計上可能なのは、Lovableの明確な強みです。

デザイン面での作り込みを含めて他のツールと見比べたい場合は、AIデザインツールおすすめ比較も判断材料になります。

セキュリティ：2026年4月の情報露出インシデントと公開前の必須確認

出典: Supabase 公式ドキュメント（Row Level Security）

Lovableを業務で使う前に必ず理解しておくべき論点が2つあります。2026年4月に公表された情報露出インシデントと、RLS（行レベルセキュリティ）設定不備という構造的リスクです。

2026年4月のインシデント：公式説明と発見者側の主張

この件は公式と第三者で説明が食い違っています。どちらかを事実として断定せず、主語を分けて整理します。

Lovable公式ブログ「Our response to the April 2026 incident」の説明

• 原因は2026年2月のバックエンド変更によるリグレッション。公開（public）設定のプロジェクトのチャット履歴とソースコードが、プロジェクトリンクを持つ任意のLovableユーザーからアクセスできる状態に戻ってしまった
• 影響期間は2026年2月3日〜4月20日。4月20日に発覚し、2時間以内に修正
• 影響範囲はpublicプロジェクトのみで、privateプロジェクトとLovable Cloudは一度も影響を受けていない
• 対応として、権限リグレッションを即時ロールバック、既存のpublicプロジェクトを（公式テンプレートを除き）すべてprivateに変更、プロジェクト可視性のUXを再設計、脆弱性報告のトリアージ体制を再構築、アクセスログを精査して該当オーナーに通知
• 「当初のコミュニケーションは的外れで、かえって混乱を招いた」と、社内の管理職が反省を公表している

発見者・報道側の主張

• 発見者は独立系セキュリティ研究者のMatt Palmer氏。2026年3月3日にHackerOne経由で報告したが修正されず、48日後の4月20日に公開開示した
• 手口は、無料アカウントと5回のAPIコールで、URL中のプロジェクトIDを差し替えるだけで他人のソースツリー全体を取得できたというもの。.envファイルや稼働中のSupabase URL・APIキーまで露出したとされる
• 影響対象は「2025年11月以前に作成されたすべてのプロジェクト」と報じられており、公式の「2026年2月3日以降のリグレッション」「publicのみ」という説明と範囲・原因が食い違っています
• Lovable製アプリはSupabase・Stripe・Google APIなどの資格情報を抱えることが多く、二次被害の懸念が指摘されました
• 対応の説明が短期間で揺れたことへの批判も報じられています

事実として確定しているのは、「AIが生成したアプリの可視性設定と資格情報の扱いが、実際に問題になった」という点です。ツールを信頼するかどうかの前に、利用者側で打てる手を打っておくことが現実的な対策になります。

AIエージェントが実環境を壊した事故の類例と再発防止の考え方は、AIエージェントがデータを全削除した事故まとめでも整理しています。

RLS設定不備：バイブコーディング共通の構造的リスク

Lovable製アプリのRLS不備は、CVE-2025-48757（CVSS 9.3・CRITICAL）として登録されています。RLSが有効になっていないテーブルは、アプリに同梱される公開キーを使って第三者が直接読み書きできてしまう可能性があります。

これはLovable固有の欠陥というより、「AIが作ったからセキュアだろう」という思い込みが生む設定上の問題です。Lovable自身も、内蔵のセキュリティスキャンについて「これらのツールは一般的なセキュリティ問題の発見を助けるが、完全なセキュリティを保証はできない」と公式ドキュメントに明記しています。機微なデータを扱うアプリは専門家のレビューが前提です。

公開前に確認したい7項目（個人情報・決済を扱うなら必須）

1. プロジェクトの可視性をprivateにする — 公開が必要なのは「アプリ」であって「プロジェクト」ではありません。両者の区別を必ず確認する
2. .envやAPIキーをコードに直書きせず、Secretsに保存する — チャットに貼ったキーは自動検知されますが、検知に頼らず自分で管理する
3. Supabase・Stripe・Google APIなど外部サービスのキーをローテーションする — 過去に露出した可能性があるものは入れ替える
4. すべてのテーブルでRLSが有効か、ポリシーの内容が意図どおりかを確認する — 匿名ロールに与えている権限を特に見る
5. Storageバケットの公開設定を確認する — 意図せずpublicになっていないか
6. Edge Functionsの認可を確認する — 認証なしで呼べる関数が業務データに触っていないか
7. Deep scanを実行する — Business以上ならセキュリティセンターでスケジュール実行を設定し、継続的に監視する

AIにコードを書かせること全般のリスクは、AIコーディングのセキュリティリスクでも扱っています。エージェントの挙動そのものを監視する仕組みに関心があれば、Perplexity Numbatのような監視OSSも参考になります。

Lovableの強みと弱み

Lovableを検討するうえでの強みと制約を整理します。

強み

• 非エンジニアでも、チャットだけでフロントからDB・公開まで到達できる。公式データでもビルダーの80%が非技術職
• 生成されるUIのデザイン品質が高く、社内提案や投資家向けデモに耐える見た目になりやすい
• Lovable Cloudにより、Supabaseを別契約せずバックエンドを立てられる。リージョン選択でデータ所在地の要件にも対応しやすい
• 席課金ではないため、人数の多い組織に配布しても席代が増えない
• 生成物はReactコードとして持ち出せる。ノーコードのようなロックインがない
• Business（月50ドル〜）でSSO・RBAC・セキュリティセンターに到達でき、ガバナンス要件のハードルが低い

弱み・制約

• 既存のGitHubリポジトリを取り込めない。 稼働中のプロダクトの改修には使えない
• Lovable Cloudと外部Supabaseの相互移行がサポートされていない。 最初の選択が後戻りしにくい
• アプリ内AIでClaudeを内蔵コネクタとして使えない。 自前APIキーとバックエンド関数の実装が必要
• 技術スタックの選択肢が狭い。フレームワークを自分で選びたい用途には向かない
• 管理画面・エディタのUIが英語
• デイリークレジットは当日失効。無料枠は月30が上限で、本格運用はできない
• ファイルサイズの上限がある（1ファイルあたりFree 20MB／有料 256MB／Enterprise 1GB。10MBを超えるファイルはプロジェクトコードに直接コミットできず、CDNへの移行が必要）
• 内蔵スキャンは完全なセキュリティを保証しない、と公式が明言している。個人情報・決済を扱うなら開発者レビューが前提

こんな人におすすめ／おすすめしない人

Lovableをおすすめする人

• コードは書けないが、アイデアを動くアプリにしたい起業家・事業担当者 — 現時点で最も到達距離が長い選択肢のひとつです
• 社内の非エンジニア部門にAI開発を展開したい情報システム・DX担当者 — 席課金がないため、配布人数が増えても料金構造が崩れません。Businessプランで SSO・RBAC・セキュリティセンター・導入インサイトまで揃います
• 社内向けの業務ツールや、部門単位の小規模アプリを内製したい企業 — 内部限定パブリッシュ（Business以上）で、社外に出さない運用ができます
• プロトタイプ・MVPを最短で作りたいプロダクトマネージャー — Planモードで方針を詰めてからBuildに渡す運用が有効です
• データ保存先を国内近傍にしたい要件がある組織 — Lovable CloudのAsia Pacificリージョンが選べます
• 将来的にエンジニアへ引き継ぐ前提で作り始めたい人 — GitHubに同期でき、コードは自分のものです

Lovableをおすすめしない人

• 既存のプロダクトに機能を追加・改修したい人 — 既存リポジトリのインポートに対応していません。CursorやWindsurfなど、既存コードベースを前提としたツールが適します
• フレームワークや技術スタックを自分で選びたい開発者 — Boltなど選択肢の広いツールの方が合います
• アプリ内AIにClaudeを使いたい人 — 内蔵コネクタでは提供されないため、自前実装の手間が発生します
• UIまで日本語で統一されていないと運用に乗らない組織 — AIへの指示は日本語で通りますが、管理画面は英語です
• 高トラフィックの本番システムを最初から作り込みたい人 — 実ユーザーの負荷を扱う前に開発者のレビューが必要というのが実務上の共通見解です
• 無料の範囲だけで完成まで持っていきたい人 — 月30クレジットの上限に必ず突き当たります

2026年8〜9月の主なアップデート

Lovableは更新が速く、数か月前の解説記事が実態と合わなくなりがちです。直近の主な変更点を整理します。

まとめ

Lovableは、AIとチャットするだけでWebアプリをゼロから公開まで作れるAIアプリビルダーです。2026年9月時点の要点を整理します。

• できること: 日本語の指示でUI・ロジック・DB・認証・公開までを生成。Buildモードは1メッセージで最長10時間の自律作業に対応し、Planモードで設計だけ先に詰めることもできる
• 料金: クレジット一本化。無料プランは5クレジット/日・月30まで。本格利用はPro月25ドル（100クレジット）〜、ガバナンス要件があるならBusiness月50ドル〜。席課金ではなくメンバー数は無制限
• 日本語対応: AIへの指示は日本語で通るが、管理画面のUIは英語。データ保存先はAsia Pacificを選べる
• 後戻りしにくい選択: Lovable Cloudか外部Supabaseかは相互移行がサポートされていない。既存GitHubリポジトリの取り込みも不可
• Boltとの違い: Lovableはクレジット課金・席無制限・非エンジニア向け、Boltはトークン課金・Teamsは席課金・スタック選択の自由度が高い
• セキュリティ: 2026年4月に情報露出インシデントが発生。公式はpublicプロジェクトのみと説明し、発見者側は範囲がより広いと主張している。RLS設定不備はCVE登録済みで、公開前の確認は必須

まずはFreeプランで小さなアプリを1つ作り、「1タスクでクレジットがどれだけ減るか」「日本語プロンプトがどこまで通るか」を体感してからProに進むのが、失敗の少ない進め方です。

よくある質問（FAQ）

Q. Lovableは無料で使えますか？どこまでできますか？

A. 無料プランがあり、クレジットカードなしで始められます。使える量は1日5クレジット（月30が上限）で、Cloud分20クレジット/月・AI分4クレジット/月が別途付与されます。小さなアプリを作って .lovable.app のURLで公開し、GitHubにコードを同期するところまでは可能ですが、独自ドメインやエディタ内でのコード編集、クレジットの追加購入は有料プランが必要です。デイリークレジットは当日中に失効し、翌日に繰り越せません。

Q. Proの月25ドル・100クレジットで、月にどれくらい作業できますか？

A. Buildモードの消費目安は1タスクあたり概ね0.50〜1.70クレジット、Planモードは1メッセージ1クレジット固定です。単純計算で月60〜200回程度の指示が目安になりますが、これに毎日5クレジットのデイリー分（Pro・Businessは月上限なし）が加算されるため、実際に使える回数はさらに増えます。足りない場合の追加購入はPro が50クレジット15ドル、Business が50クレジット30ドルです。

Q. 作ったアプリのコードは自分のものになりますか？他所に持ち出せますか？

A. コードは利用者のもので、GitHub／GitLabに双方向同期できるほか、Lovableから直接ダウンロードもできます。リポジトリは全プランでデフォルトprivateです。ただし逆方向、つまり既存のGitHubリポジトリをLovableに取り込むことは現時点でできません。

Q. Lovable Cloudと外部Supabaseは後から乗り換えられますか？

A. 公式ドキュメントによれば、Lovableのツールでは相互移行がサポートされていません。プロジェクト作成時の選択が実質的に固定されるため、「他のシステムからも同じDBを使う予定があるか」を先に決めてから着手してください。

Q. Lovableは日本語で使えますか？

A. AIへの指示は日本語で問題なく通り、日本語UIのアプリも生成できます。ただしLovable自体の管理画面・エディタは英語です。現時点で公式ドキュメントにUI言語の切り替え設定に関する記載は確認できていません。

Q. LovableとBoltはどちらを選ぶべきですか？

A. 非エンジニアが中心で、チームに配布して使いたいならLovable（クレジット課金・席無制限、Business月50ドル〜でSSOまで到達）。フレームワークを自分で選びたい、既存プロジェクトを取り込みたいエンジニアならBolt（トークン課金、Teamsは1人月30ドル）が向きます。個人1名での利用なら、どちらもPro月25ドルで大きな差は出ません。

Q. 2026年4月のインシデントの後、今も安全に使えますか？

A. Lovable公式は、影響を受けたのはpublic設定のプロジェクトのみで、privateプロジェクトとLovable Cloudは影響を受けていないと説明し、既存のpublicプロジェクトをすべてprivateに変更したとしています。一方で発見者・報道側は影響範囲がより広いと主張しており、説明が一致していません。利用側としては、プロジェクトをprivateに保つ、キーをSecretsで管理する、過去に露出した可能性のあるAPIキーをローテーションする、RLSポリシーを確認する、Deep scanを実行する、といった対策を取ることが現実的です。公式も内蔵スキャンは完全なセキュリティを保証しないと明記しています。

Q. Lovableで作ったアプリは本番運用できますか？

A. 2026年時点でリージョン選択・メールレート制限・Edge Functionsのエラーハンドリングなど本番向けの機能は揃ってきており、実際に収益化しているアプリも多数あります。ただし個人情報や決済を扱う場合は、RLS・認可・シークレット管理を開発者がレビューしたうえで公開するのが前提です。高トラフィックの基幹システムをLovableだけで作り切る使い方は、現時点では推奨しにくい選択です。