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

Lovable（ラバブル）とは、AIとチャットするだけで、Webアプリ・Webサイトを画面からデータベース、公開（デプロイ）まで作れる「AIアプリビルダー」です。スウェーデン・ストックホルムの同名企業が開発しており、2026年9月には共同創業者兼CTOが「年換算収益6億ドル超」と明かしました。2026年6月の報道では、新規プロジェクトは週100万件に達しています。

料金は無料プラン（1日5クレジット・月30まで）から始められ、本格的に使うならPro月25ドルからです。ビルド・ホスティング・バックエンドの実行・アプリ内AIは、すべて1つのクレジット残高から差し引かれます。

この記事でわかること

• Lovableの概要、提供形態、規模を示す数字（出典と時点つき）
• 無料プランでできる範囲と、Pro・Business・Enterpriseの料金、クレジットが消費・失効するルール
• Build／Plan／Chatの3モード、Lovable Cloud、アプリ内AI（2026年9月からClaudeにも対応）などの現行機能
• 日本語対応の実情とデータの保存リージョン
• 登録から公開までの手順と、作ったアプリを本番運用やエンジニアに引き継ぐ段階の判断
• Bolt・v0・Replit・Cursorとの選び分け
• 2026年4月の情報露出インシデント、9月のTanStack Start脆弱性への対応、公開前に確認したい項目

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

料金と機能は、2026年10月時点の公式ドキュメント・料金ページ・changelogにもとづいています。Lovableは週に何度も更新されるため、契約前に公式ページで最新の内容を確認してください。

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

出典: Lovable 公式サイト

Lovableは、自然言語の指示（プロンプト）からWebアプリを生成し、公開までをブラウザの中で済ませるSaaSです。従来のノーコードツールとの大きな違いは、部品をドラッグ＆ドロップで並べるのではなく、実際のReactコードとバックエンドが生成されることです。生成されたコードはGitHub・GitLab・Bitbucketに同期でき、zipでダウンロードもできます。

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

Lovableの考え方は、コードを1行ずつ書くのではなく「こういうものが欲しい」とAIに伝えて作るバイブコーディングです。実装はAIに任せ、人は何を作るかの判断と出来上がりの確認に集中します。この形にしたことで、プログラミング経験のない人まで作り手に加わりました。

バイブコーディングの仕組み・リスク・ほかのツールとの関係は、バイブコーディングとは？仕組み・ツール比較・リスクと始め方で詳しく扱っています。

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

Lovableの数字は数か月で大きく変わります。数字を見るときは、いつ・誰が出したものかも一緒に確認してください。

ネットでよく見かける「年商500億円突破」という表現は不正確です。 2026年6月時点の5億ドルでも、1ドル145〜150円で換算すると約725〜750億円になり、500億円とは合いません。最新の6億ドル超を1ドル150円で換算すると約900億円です。また、ARRは決算上の年間売上ではなく、直近の月の収益を12倍した年換算の数字（ランレート）です。

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

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

出典: Supabase 公式サイト

Lovableでは、チャットで指示するだけで、動くアプリを公開するところまで進めます。2026年9〜10月は、相談専用のChatモード、本番に影響させずに変更を試せるDrafts、外部から操作できるLovable APIなどが続けて追加されました。

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

現行のLovableは、Build（作る）・Plan（設計する）・Chat（相談する）の3モードに分かれています。以前の「Default／Chat／Agent」という分け方とは別の分け方で、Chatモードは2026年9月に新しく作り直されました。

実務では、この3つを使い分けるとクレジットを節約できます。

• Chat: 「この機能は必要か」「エラーの原因は何か」のように、コードを変えずに考えたいとき。1メッセージ1クレジット未満
• Plan: 画面構成やデータ設計を詰めるとき。1メッセージ1クレジット固定
• Build: 方針が決まってから実装させるとき。作業量に応じて消費する

要件が固まっていない段階でBuildを走らせるより、ChatとPlanで方針を決めてからBuildに渡すほうが、手戻りが少なくクレジットも減りにくくなります。Buildは最長10時間動くので、「指示を出して席を外し、戻ってから結果を確認する」という使い方もできます。

仕様を先に固めてから実装させるやり方をもっと厳密にしたいなら、仕様駆動の考え方を取り入れたKiro（AWSの仕様駆動AIコーディングIDE）も選択肢になります。

アプリ内AIで使えるモデル（2026年9月からClaudeにも対応）

2026年9月23日から、Lovable AIでClaudeのモデルを使えるようになりました。 Anthropicのアカウントや自分のAPIキーがなくても、Lovableのクレジットで呼び出せます。これまでのLovable AIはGemini系とGPT系だけで、Claudeを使うには自分でAPIキーを用意する必要がありました。

古いモデルは順に提供終了になります。たとえばGemini 3.6 Flashは2026年11月19日、Gemini 3.7 Flashは2027年1月に終了する予定です。アプリに組み込んだモデルが終了予定になっていないか、ときどき確認してください。

アプリを作るLovable側のAIにも、新しいモデルが使われています。公式ブログでは、2026年9月に「Fable 5.1でビルドする」「Opus 5.5を導入してビルドが速くなった」と発表しました。モデルそのものについては、Claude Opus 5.5とはとClaude Fable 5とはで解説しています。

LLMを組み合わせたAIアプリ作りが主な目的なら、画面上でワークフローを組めるDifyのようなアプリ開発基盤のほうが合う場合もあります。

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

Lovableでは、1つのクレジット残高から、ビルド・ホスティング・バックエンドの実行・アプリ内AIの費用がすべて差し引かれます。以前は、ビルド用のサブスク、Cloudの残高、AIの残高が別々でした。

もう1つの特徴は、人数（席）で課金されないことです。公式の料金ページには「価格は含まれるクレジットの量で決まり、席の数では決まらない」とあり、ワークスペースのメンバーは全プランで無制限です。非エンジニアの部署に広く配りたい企業には、この点が有利に働きます。

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

ProとBusinessは、毎月のクレジット量で価格が変わります。Businessは同じクレジット量で、Proのおおむね2倍の価格です。

年払いは月払い10か月分の金額なので、2か月分が安くなります。学生と教員は、Proの100クレジット（月払い）を最大12か月、50%オフで使えます（lovable.dev/students）。

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

見落としやすいのが、サブスクに含まれるクレジットと追加購入では単価が違うことです。Proの100クレジットは1クレジット0.25ドルですが、追加購入は0.30ドルになります。Businessも0.50ドルに対して追加購入は0.60ドルです。さらに、Proの1,200クレジットは0.245ドル、10,000クレジットは0.225ドルと、上のプランほど単価が下がります。毎月足りなくなるなら、追加購入を続けるより上のプランに変えたほうが安くなります。

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

Freeプランで使えるビルドクレジットは1日5、月30までです。Buildモードは1回0.5〜2クレジット程度なので、指示できるのは1日に3〜10回くらいです。月30の上限があるため、毎日フルに使うと1週間ほどで上限に達します。

• できること: 小さなランディングページや簡単なデータ管理アプリを作り、.lovable.app のURLで公開する。招待した人だけに見せる公開もできる（2026年10月〜）。Cloud用の付与（月20）の範囲でDBや認証を試す。GitHubなどにコードを同期する。毎日のチャット枠で、作らない相談をする
• できないこと: 独自ドメイン、エディタでのコード編集、デザインシステム、クレジットの追加購入。月30クレジットを使い切ると、その月は作り込みを続けられない

Freeは「操作感と、どのくらいクレジットが減るかを確かめるお試し枠」と考えるのが現実的です。アプリを1つ最後まで仕上げるなら、Pro（月25ドル／100クレジット）が出発点になります。

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

Lovableは人数で課金されないため、チームで使うときに料金の増え方が変わります。席課金のツールと並べると、構造の違いがわかります。

ただし、人数が増えれば使うクレジットも増えるので、実際にはプランを上げることになります。違うのは「使った分だけ払い、使わないメンバーの席代はかからない」という点で、必ず安くなるわけではありません。全社に配っても実際に使うのは一部の人、という導入初期には有利です。Pro以上ならメンバーごとに上限とアラートを設定できるので、一部の人が使いすぎるのも防げます。

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

AIへの指示は日本語で通ります。ただし、管理画面とエディタは英語です。 「飲食店の予約管理アプリを作って。ログイン機能とカレンダー表示が欲しい」のような日本語の指示はそのまま伝わりますが、設定画面のメニューやエラーメッセージは英語で表示されます。2026年10月時点で、公式ドキュメントにUIの言語を切り替える設定は見当たりませんでした。

作るアプリの画面の文言やデータは、日本語にできます。日本語で指示すれば、日本語の画面のアプリが生成されます。

データの保存先は、Lovable CloudならAmericas / Europe / Asia Pacificの3つから選べます。Enterpriseでは国単位のリージョンを相談できます。注意したいのは、Cloudを有効にした後はリージョンを変えられず、既存プロジェクトを別のリージョンに移すこともできないことです。国内向けのサービスでデータの保存場所に条件があるなら、最初にAsia Pacificを選んでください。外部のSupabaseを使う場合は、Supabase側のリージョン設定に従います。

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

プログラミングの知識がなくても、チャットと画面の操作だけで公開まで進めます。

1. アカウントを作る：lovable.dev でGoogle・GitHub・Appleのアカウントかメールで登録します。Freeプランならクレジットカードはいりません
2. バックエンドの方式を決める：新しいプロジェクトでは、内蔵のLovable Cloudか外部のSupabaseかを選びます。後から切り替えにくいので、Cloudを選ぶならリージョンも含めて最初に決めます
3. ChatとPlanで方針を固める：いきなり作らせず、「どんな画面が必要か」「ログインはどう設計するか」をChatで相談し、Planで計画にまとめます
4. Buildで作らせる：「◯◯を作って」と日本語で指示すると、画面・処理・必要ならDBまで作られ、その場でプレビューできます。指示が具体的なほど手戻りが減り、クレジットの消費も抑えられます
5. 動作を確かめて直す：プレビューを触りながら「ボタンを大きく」「一覧を10件ずつ表示に」と追加で指示します。公開中のアプリを大きく変えるときは、Draftsで別のコピーを作って試すと安全です
6. セキュリティスキャンをかける：公開前にBasic scan／Deep scanを実行し、RLSポリシーの設定ミスやシークレットの露出がないか確認します
7. 公開する：標準では <プロジェクト名>.lovable.app で公開されます。関係者だけに見せたいなら招待した人だけに公開する設定（Free・Pro）、社内だけに公開する設定（Business以上）を使います。Pro以上は独自ドメインも設定できます
8. 必要ならコードを持ち出す：GitHub・GitLab・Bitbucketに同期するか、zipでダウンロードしてエンジニアに渡します

予算を決めて使うなら、最初にクレジットの上限とアラートを設定しておくと安心です。プロンプトの書き方や、AIが作ったものの確かめ方は、バイブコーディングのやり方｜初心者向け5ステップ実践ガイドで手順にまとめています。

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

生成されたコードは利用者のものです。 GitHub・GitLab・Bitbucket Cloudと双方向に同期でき、zipでダウンロードもできます。リポジトリは標準で非公開（private）になります。コミットの作成者はLovableのbotですが、操作したメンバーも共同作成者として記録されます。

ただし、実務では次の制約に注意が必要です。

• 既存のGitHubリポジトリをLovableに取り込むことはできません。 公式ドキュメントにも「LovableからGitHubへのエクスポートのみ」とあります。すでに動いている自社プロダクトの改修には使えません
• 同期できるのは1ブランチずつ（通常はデフォルトブランチ）です
• GitHub Enterprise Cloud／Serverとの連携はEnterpriseプランのみです。github.comは全プランで使えます

既存のコードに機能を足したいなら、LovableではなくCursorのようなエディタ統合型のAI開発ツールやWindsurf（Devin Desktop）の出番です。競合というより、得意な場面が分かれていると考えてください。

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

新しいプロジェクトでは、バックエンドをLovable Cloud（内蔵）にするか、外部のSupabaseにするかを選びます。公式ドキュメントによると、外部SupabaseからCloudへの移行はできません。CloudからSupabaseへも一括の移行機能はなく、データを書き出して新しいプロジェクトでテーブル構造を作り直す必要があります。 最初の選択がそのまま続くと考えてください。

迷ったら、Lovableの中で完結させるならCloud、ほかのシステムからも同じDBを使う予定があるなら外部Supabaseで決めてください。いずれLovableを離れて自社で開発する可能性があるなら、最初から外部Supabaseにしておくと移るときの手間が減ります。

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

出典: Bolt 公式サイト

Lovableとよく比べられるのが、StackBlitzが提供するBolt（bolt.new）です。どちらもブラウザでAIにアプリを作らせるツールですが、課金の単位と、想定している使い手が違います。2026年10月時点の公式料金ページとヘルプで比べます。

1. 課金の単位によって、予算の立てやすさが変わる。 Lovableのクレジットは「1回の作業でいくら」に近く、Planモードなら固定です。Boltのトークンは処理量に比例するため、大きなファイルを扱うと消費が読みにくくなります。とはいえLovableでも、長い作業は1回で2クレジット前後かかり、修正のやり取りが増えれば費用はふくらみます。

2. チームの人数が多いほど、総額の差が開く。 BoltのTeamsは1人月30ドルなので、10人なら月300ドルです。Lovableは同じクレジット量なら人数にかかわらず同じ金額です。「部署に配るが、よく使うのは数人」という導入なら、この差が大きくなります。

3. SSOなどの管理機能を使い始められる価格が違う。 LovableはBusiness（月50ドル〜）でSSO・セキュリティセンター・RBACまで使えます。BoltでSSOや監査ログを使うにはEnterpriseの個別見積が必要です。中小規模の会社で管理機能も必要なら、Lovableのほうが始めやすくなっています。

一方で、既存のリポジトリから作業を続けたい場合とモバイルアプリまで作りたい場合はBoltが向いています。どちらもLovableが対応していない領域です。BoltはLovableのプロジェクトをGitHub経由で取り込む手順を公式に案内しているので、「Lovableで試作し、Boltや開発環境に移って続ける」という使い方もできます。

v0・Replit・Cursorとの選び分け

v0・Replit・Cursor・Bubbleの欄は、各サービスのおおまかな位置づけを示したものです。料金体系や取り込みの対応範囲は変わりやすいため、契約前に各社の公式ページで確認してください。

Lovableと従来型ノーコード（Bubble・Glide・Power Appsなど）の大きな違いは、作ったものをReactのコードとして持ち出せるかです。ノーコードはそのサービスから離れにくいのに対し、LovableはGitHubなどに同期してエンジニアに渡せます。「まず非エンジニアが作り、伸びたらエンジニアが引き取る」流れを最初から組めるのは、Lovableの強みです。

AIコーディングツール全体を比べたい場合はAIコーディングツールおすすめ比較、デザインまで含めて比べたい場合はAIデザインツールおすすめ比較も参考になります。

試作のあとはどこへ移るか（本番運用・エンジニアへの引き継ぎ）

Lovableは、画面・DB・認証・公開がそろった最初の版を作るまでが特に速いツールです。 一般的には、従来どおりコードを書くより早く「触れるもの」が手に入ります。一方で、既存システムとの連携、複雑な権限、決済、性能の要件が加わると、AIの出力を人が読んで直す時間が増え、速さの差は縮まります。

公開URLで試作を動かしたあとは、用途に合わせて次の行き先を選びます。

DBやバックエンドについては、公式ドキュメントで確認できる範囲では、Lovable CloudのほうがDB運用の機能（リージョンの選択、Drizzleのマイグレーションファイル、負荷の警告、パスワードのローテーション）を細かくそろえています。BoltもBolt CloudでDB・認証・ストレージをそろえていますが、DBを長く運用するならLovableのほうが情報が多い状況です。どちらを使う場合でも、テーブル設計とアクセス権限は人が確かめてください。

AIで作った試作を社内の実データや既存システムにつないで業務で使う段階では、ログインと権限の設計、データの移し替え、運用の監視、障害が起きたときの責任の分け方など、Lovableの外側の作業が必要になります。何を渡して何を確かめればよいかは、AIで作ったアプリを開発会社へ引き継ぐにはにまとめています。

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

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

Lovableを業務で使う前に、3つのことを知っておく必要があります。2026年4月に公表された情報露出のインシデント、RLS（行レベルセキュリティ）の設定不備という構造上のリスク、そして2026年9月にLovable自身が見つけたTanStack Startの脆弱性です。

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

この件は、Lovableと発見者で説明が食い違っています。どちらか一方を事実とは決めつけず、それぞれの主張を分けて紹介します。

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に変更した。ほかに、公開範囲の画面の作り直し、脆弱性報告の受付体制の見直し、アクセスログの調査と該当するオーナーへの連絡を行った
• 社内の管理職が「最初の説明は的外れで、かえって混乱を招いた」と反省を公表した

発見者・報道側の主張

• 発見者は、独立系のセキュリティ研究者Matt Palmer氏。2026年3月3日にHackerOneで報告したが修正されず、48日後の4月20日に公開した
• 無料アカウントでAPIを5回呼び、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も公式ドキュメントで、内蔵のセキュリティスキャンについて「よくあるセキュリティの問題を見つける助けにはなるが、完全な安全は保証できない」と書いています。個人情報など重要なデータを扱うアプリは、専門家に確認してもらう前提で進めてください。

2026年9月：TanStack Start脆弱性への対応

2026年9月30日、LovableはTanStack Start（Webアプリの基盤となるフレームワーク）の脆弱性CVE-2026-102989への対応を公式ブログで公表しました。サーバーからの応答の処理に、反射型XSS（悪意のあるスクリプトを実行させられる問題）があったというものです。

• 9月14日にLovableのセキュリティチームが見つけ、TanStackに報告した
• 修正版が出るまで、Lovableで公開しているアプリはファイアウォールで守り、影響を受けるプロジェクトは次に変更したときに自動で更新されるようにした
• Lovableは、悪用された形跡は見つかっていないと説明している

注意が必要なのは、Lovableから書き出して自分のサーバーなどで公開しているアプリです。この場合はLovableの保護が届かないため、自分で修正版（@tanstack/react-start 1.168.60以降など）に更新して公開し直す必要があります。Netlifyも、手元で更新しただけでは公開済みのアプリは直らないと案内しています。

このほか2026年9〜10月には、APIキーを使える接続元IPの制限、Enterpriseでの2段階認証の必須化、データを30日以上保持するモデルは管理者が有効にしないと使えない設定、リミックス（複製）時にファイルを標準でコピーしない変更などが加わっています。

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

1. プロジェクトの公開範囲をprivateにする：公開する必要があるのは「アプリ」で、「プロジェクト」ではありません。この2つを取り違えないよう確認します
2. .envやAPIキーをコードに直接書かず、Secretsに保存する：チャットに貼ったキーは自動で検知されますが、それに頼らず自分で管理します
3. Supabase・Stripe・Google APIなど外部サービスのキーを入れ替える：過去に見られた可能性があるものは、新しいキーに替えます
4. すべてのテーブルでRLSが有効か、ポリシーが意図どおりかを確認する：ログインしていないユーザーに何を許しているかを特に確認します
5. Storageのバケットの公開設定を確認する：意図せずpublicになっていないか見ます
6. Edge Functionsの認可を確認する：ログインなしで呼べる関数が業務データに触れていないか確かめます
7. Deep scanを実行する：Business以上ならセキュリティセンターで定期実行を設定し、継続して監視します
8. 書き出して自分で公開しているアプリは、依存パッケージを更新する：TanStack Startのように、Lovableの外で動かしているアプリは自分で修正版を当てる必要があります

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

Lovableの強みと弱み

強み

• 非エンジニアでも、チャットだけで画面からDB・公開まで進める。公式の調査でも、ビルダーの80%が非技術職
• 作られる画面の見た目がよく、社内の提案や投資家向けのデモに使える仕上がりになりやすい
• Lovable Cloudがあるので、Supabaseを別に契約しなくてもバックエンドを用意できる。保存先のリージョンも選べる
• 人数で課金されないので、大きな組織に配っても席代が増えない
• 作ったものをReactのコードとして持ち出せる。ノーコードのように特定のサービスから離れにくくなることがない
• Business（月50ドル〜）でSSO・RBAC・セキュリティセンターまで使え、管理機能を入れるハードルが低い
• アプリ内AIでClaude・GPT・Geminiを、自分でAPIキーを用意せずに使える

弱み・制約

• 既存のGitHubリポジトリを取り込めない。 稼働中のプロダクトの改修には使えない
• Lovable Cloudと外部Supabaseの間で、簡単に移行できない。 Cloudのリージョンも後から変えられない
• 技術スタックの選択肢が少ない。フレームワークを自分で選びたい用途には向かない。モバイルアプリはBoltのほうが向いている
• 管理画面・エディタは英語
• 毎日のクレジットはその日のうちに失効する。無料枠は月30が上限で、本格的な運用はできない
• 作業量に応じた課金なので、修正のやり取りが増えると費用が読みにくい。Chatモードの価格も2026年10月31日までの暫定
• 内蔵スキャンで完全な安全は保証されない、と公式が書いている。個人情報や決済を扱うなら、開発者の確認が前提

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

Lovableをおすすめする人

• コードは書けないが、アイデアを動くアプリにしたい起業家・事業担当者：非エンジニアが一人で公開まで進められる、数少ない選択肢です
• 社内の非エンジニア部署にAI開発を広げたい情報システム・DX担当者：人数で課金されないので、配る人数が増えても料金の仕組みは変わりません。BusinessプランならSSO・RBAC・セキュリティセンター・導入状況の分析もそろいます
• 社内向けの業務ツールや、部署単位の小さなアプリを内製したい企業：Business以上の「社内だけへの公開」で、社外に出さずに運用できます
• プロトタイプやMVPを最短で作りたいプロダクトマネージャー：ChatとPlanで方針を固めてからBuildに渡すと、無駄な消費を抑えられます
• データの保存先を日本に近い場所にしたい組織：Lovable CloudでAsia Pacificリージョンを選べます
• いずれエンジニアに引き継ぐつもりで作り始めたい人：GitHubなどに同期でき、コードは自分のものです

Lovableをおすすめしない人

• 既存のプロダクトに機能を足したり、改修したりしたい人：既存リポジトリを取り込めません。CursorやWindsurfなど、既存のコードを扱うツールが向いています
• フレームワークを自分で選びたい開発者、モバイルアプリも作りたい人：Boltのように選べる幅の広いツールのほうが合います
• 画面まで日本語でないと運用できない組織：指示は日本語で通りますが、管理画面は英語です
• アクセスの多い本番システムを最初から作り込みたい人：実際の利用者の負荷を受ける前に、開発者の確認が必要というのが実務での一般的な見方です
• 毎月の費用をきっちり固定したい組織：作業量で消費が変わるため、上限とアラートを設定しても月ごとの差は出ます
• 無料の範囲だけで完成させたい人：月30クレジットの上限に必ずぶつかります

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

出典: Lovable 公式ブログ

Lovableは更新が速く、数か月前の解説がもう実態と合わないこともあります。公式changelog・ブログで確認できた2026年9〜10月の主な変更は次のとおりです。

まとめ

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

• できること: 日本語の指示で、画面・処理・DB・認証・公開まで作れる。Build・Plan・Chatの3モードを使い分け、Draftsで本番を変えずに改修を試せる
• 料金: 1つのクレジット残高で払う方式。無料プランは毎日5クレジット（月30まで）。本格的に使うならPro月25ドル（100クレジット）から、SSOなどの管理機能が必要ならBusiness月50ドルから。人数では課金されず、メンバーは無制限
• クレジットのルール: 毎日の分は当日中に失効し、月の分は付与から2か月で失効する。Chatモードの価格は10月31日までの暫定
• 日本語対応: 指示は日本語で通るが、管理画面は英語。保存先はAsia Pacificを選べるが、後から変えられない
• 後から変えにくい選択: CloudかSupabaseかは簡単に移行できない。既存のGitHubリポジトリも取り込めない
• Boltとの違い: Lovableはクレジット課金・人数無制限・非エンジニア向け。Boltはトークン課金・Teamsは席課金で、既存リポジトリの取り込みやモバイルアプリに強い
• セキュリティ: 2026年4月の情報露出は、公式と発見者で範囲の説明が食い違っている。RLSの不備はCVEに登録済み。書き出して自分で公開しているアプリは、TanStack Startの修正版への更新が必要

まずはFreeプランで小さなアプリを1つ作り、1回の作業でどのくらいクレジットが減るか、日本語の指示がどこまで通るかを確かめてから、Proに進むのが失敗の少ない始め方です。

よくある質問（FAQ）

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

A. 無料プランがあり、クレジットカードなしで始められます。ビルドに使えるのは1日5クレジット（月30まで）で、ほかにCloud用20クレジット／月とAI用4クレジット／月が付きます。小さなアプリを作って.lovable.appで公開したり、招待した人だけに見せたりできます。独自ドメイン、エディタでのコード編集、クレジットの追加購入には有料プランが必要です。

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

A. Buildモードは1回0.5〜2クレジット程度なので、100クレジットで50〜200回ほどの指示が目安です。Proには毎日5クレジットも付くので、毎日使う人はもっと多く指示できます（毎日の分はその日のうちに失効します）。足りないときは50クレジット15ドルで買い足せますが、毎月足りないなら、追加購入より上のプランに変えたほうが単価は下がります。

Q. Lovableと従来のコーディングでは、どちらが速く作れますか？

A. 画面・DB・ログイン機能がそろった最初の版を作るまでは、一般的にLovableのほうが速くなります。ただ、既存の社内システムとの連携や細かい権限設定、決済が入ると、生成されたコードを人が確認して直す時間が増え、差は小さくなります。試作はLovable、本番の作り込みはエンジニアのツールで、と段階で使い分けるのが現実的です。

Q. Lovableで作ったアプリにClaudeを組み込めますか？

A. 組み込めます。2026年9月23日から、アプリ内AI（Lovable AI）でClaude Fable 5.1・Opus 5.5・Sonnet 5・Haiku 4.5などが使えるようになりました。Anthropicのアカウントや自分のAPIキーはいらず、利用分はLovableのクレジットから差し引かれます。

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

A. 簡単には乗り換えられません。外部SupabaseからCloudへの移行はできず、CloudからSupabaseへも、データを書き出して新しいプロジェクトでテーブル構造を作り直す必要があります。Cloudのリージョンも後から変えられないので、作り始める前に決めてください。

Q. LovableとBoltは、DBやバックエンドを作るならどちらが強いですか？

A. どちらもDB・認証・ストレージを内蔵しています。公式ドキュメントで確認できる範囲では、Lovable Cloudのほうがリージョンの選択、マイグレーションファイル、DB負荷の警告など、DBを運用するための機能が細かくそろっています。一方、Boltは既存のリポジトリやSupabaseのプロジェクトをつないで作業を続けやすいのが特徴です。

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

A. Lovableは、影響はpublic設定のプロジェクトだけで、privateのプロジェクトとLovable Cloudには影響がなかったと説明しています。一方で発見者側はもっと範囲が広いと主張しており、説明は一致していません。プロジェクトをprivateにしておく、キーをSecretsで管理して入れ替える、RLSを確認する、Deep scanを実行する、といった対策を利用者側で取っておくのが安全です。

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

A. 公式サイトでは4万社以上がビジネスで利用していると紹介されており、社内向けの業務ツールや小規模なサービスなら運用は現実的です。顧客の個人情報や決済を扱う場合は、RLS・権限・認証情報の管理を開発者が確認してから公開するのが前提です。アクセスの多い基幹システムをLovableだけで作り切る使い方は、現時点ではおすすめしにくい選択です。