TL;DR
コードを書かない人が動く最初のバージョンにたどり着く速さでは、Lovableが他のどのツールより上だと言われています。アプリが育つと、Cursorが勝ちます。両方を比べた67のRedditスレッドでは、18がCursor、5がLovableを選び、16人がLovableからCursorへ移ったと書いていて、その逆の移行を書いた人はいませんでした。理由は、修正のやり直しで消えるクレジットと、中程度の複雑さで現れる壁です。Cursorの代償は学習コストです。コードエディタで作業することになり、エージェントは自分のPCでコマンドを実行できるため、いくつかのスレッドではフォルダが削除されました。経験者の多くは両方を使います。最初のバージョンはLovableで作り、GitHubに同期して、続きはCursorで進めます。
67
LovableとCursorの両方を論じたRedditスレッド
2025年11月〜2026年10月に読んだ445スレッドのうち
16 → 0
LovableからCursorへ移った人と、その逆の人
本人の移行のみ。アドバイスは含まない
18 vs 5
Cursorを選んだスレッド vs Lovableを選んだスレッド
残りは両方、別のツール、または選ばなかった
Denysです。フルスタック・AIエンジニアです。仕事の多くは、こうしたツールで始まったアプリを仕上げたり直したりすることなので、「LovableとCursorのどちらにするか」に、機能表より良い答えを出したいと思いました。自分で公平なテストをしたわけではありません。両方にお金を払っている人たちの発言を読み、数え、引用を残しました。
Lovable vs Cursor：どちらを使うべき？
機能ではなく、誰がアプリに手を入れるかで選んでください。スレッドはほぼこの線で分かれます。チームの誰もコードを読まないならLovable、読める人がいるか、学ぶ気があるならCursorです。
- コードが読めず、最初のバージョンが必要Lovable。クリックして見せられるものまでの最短ルートです。初日からGitHub同期をオンにしてください。
- コードが読める、またはアプリがデモの段階を過ぎたCursor。本物のリポジトリを編集するので、大きなアプリや独自のバックエンドで苦労しなくなります。
- Lovableで修正のやり直しにお金を払っている乗り換えた人の最も多い理由です。GitHubに同期して、同じリポジトリをCursorで開いてください。
スレッドの読み方
r/lovable、r/cursor、r/vibecoding、r/Base44、r/boltnewbuilders、r/nocode、r/SaaSから、2025年11月〜2026年10月の間に「cursor」「lovable」「switched」「alternative」などの検索に一致し、コメントが4件以上あるスレッドをすべて、公開Redditデータのアーカイブ（Arctic Shift）から集めました。710スレッドになり、そのうち445スレッドが少なくとも1つのツールについて実際の意見を含んでいて、コメントは合計9,062件です。各スレッドについて、論じているツール、それぞれへのトーン、挙げられた理由、投稿者やコメント者が書いたツール間の移行、引用を1つ記録しました。スクリプトで、すべての引用がアーカイブしたスレッドに一字一句そのまま現れることを確認し、公開前に引用した全スレッドをRedditで開いて、その言葉が今も残っているか確かめました。
445のうち67が、LovableとCursorの両方を論じています。特に断らない限り、この記事の数字はすべてこの67です。
この調査で分からないこと。Redditは何かが壊れたときに人が行く場所で、スレッドの大半はr/lovableのものです。そのためLovableへの不満は多めに出ます。トーンの区分は各スレッドに対する私の判断です。数字は市場シェアではなく、方向として見てください。
67スレッドが語る、それぞれのツール
Cursorは67スレッド中42で好意的、Lovableは10です。ただしLovableで最も多いのは「どちらとも言えない」の28スレッドで、これが実情です。最初の数日にLovableがしてくれることは好まれ、その後にかかるコストは嫌われます。「どちらとも言えない」の典型的な評価はこうです：“Basically lovable is perfect for 0 to 1”（要するに、Lovableは0から1にするには完璧）。「move to Cursor」というタイトルのスレッドでの発言です。
スレッドが1つのツールを選んだ場合は、Cursorが18回、Lovableが5回でした。ほかの8スレッドはどちらも選ばずClaude Codeへ行き、12スレッドは用途ごとに両方を使うと書いていました。
LovableからCursorへ移る理由
16件の移行の大半は、3つの理由で説明がつきます。
クレジット。 67スレッド中29が、Lovableのコストを批判しています。不満はプラン料金そのものではなく、直らない修正にお金を払うことです。2つを直接比べた人がいます：“If you want something simple try cursor. $20 a month will last you a lot longer $30 for 100 credits on lovable.”（シンプルなものを作りたいならCursorを試すといい。月20ドルのほうが、Lovableの100クレジット30ドルよりずっと長持ちする。）別の人：“I moved to Cursor 6 months ago and have not looked back”（6か月前にCursorに移って、一度も振り返っていない）。
中程度の複雑さで現れる壁。 16スレッドが、アプリに本物のロジックが入るとLovableでは手に負えなくなると書き、18スレッドがまさにその点でCursorを評価しています。“A year ago, I got frustrated with its buggy nature and pulled things into Cursor.”（1年前、バグの多さにうんざりして、Cursorに移した。）
修正ループ。 12スレッドが、Lovableが直っていない修正を「直した」と報告し、次の試行に課金する様子を書いています。両方を使ったr/cursorの人は率直に言いました：“Cursor can do a far better job from start to finish than lovable can ever do.”（Cursorは最初から最後まで、Lovableには到底できない出来で仕上げられる。）
これらのスレッドでも、Lovableが評価されているのは最初のバージョンまでの速さで、17スレッドです。乗り換えた人の何人かは、今もLovableから始めています：“I use lovable for frontend and design scaffolding and then bring it over to Cursor for all the backend and plumbing.”（フロントエンドとデザインの土台はLovableで作り、バックエンドや配線はすべてCursorに持ってくる。）
その代わりにCursorが求めるもの
学習コスト。 これらのスレッドでCursorへの不満の第1位で、67中7です。Lovableから移った人の言葉：“I will say, there is a steep learning curve when you get off of it.”（そこから離れると、学習曲線がかなり急だとは言っておく。）Lovableでは、ホスティング、データベース、プレビューが最初から用意されています。Cursorでは、そのすべてを自分で持つことになります。
Cursorは安全？ コードについてはホスト型のビルダーより安全で、PCについてはより危険です。Cursorのエージェントはあなたのコンピュータでコマンドを実行します。Cursorを論じた117スレッドのうち31が、何かを壊された、見せたくないものを読まれた、と不満を書いています。“Cursor Agent ran rmdir /s /q on Windows and deleted my user profile”（CursorエージェントがWindowsでrmdir /s /qを実行し、ユーザープロファイルを削除した）や、“Cursor autocomplete revealing secrets for .env”（Cursorのオートコンプリートが.envのシークレットを表示する）のようなタイトルは、実際にあり、最近のものです。エージェントを動かす前に毎回コミットし、本番の認証情報をプロジェクトのフォルダに置かず、確認なしでコマンドを実行させないでください。別のエージェントについての同じ設定の助言はClaude Codeは安全？にあります。
Lovableにも同じ種類の問題があります。102コメントのあるスレッドで、有料ユーザーが、プロジェクトがロックされ、Lovableがホストするデータベース（Supabase）も一緒に使えなくなったと書いています：“Because I was using their hosted Supabase instance, I have zero access to my 12GB of proprietary data.”（彼らのホスト型Supabaseインスタンスを使っていたので、12GBの自社データに一切アクセスできない。）リポジトリはGitHubにありましたが、データはありませんでした。
バックエンドはどちらでも同じように壊れる
誰がデータを読めるかは、どちらのツールも決めてくれません。どちらも多くはSupabaseの上にあり、LovableからCursorへ移っても同じミスがついてきます。row level securityがオフのテーブル、何も確認しないポリシー、ブラウザに出てしまうシークレットキーです。セキュリティの話題は、Lovableを論じた344スレッド中44に出てきて、その大半で穴は同じです。公開キーを持つ誰でも読めるテーブルです。
Cursorに移ってもこれは直りません。直すための道具が手に入るだけです。Lovableアプリで私が行う確認はLovableアプリのセキュリティチェックリストに、プラットフォーム側はSupabaseは安全？にあります。先に問題を見たいなら、無料のSupabaseセキュリティチェックが、データに触れずにプロジェクトのgrantとポリシーを読みます。
Lovable vs Cursor 比較表
| Lovable | Cursor | |
|---|---|---|
| 何か | ホスティングとデータベース込みの、ブラウザ上のアプリビルダー | AIエージェント付きのコードエディタ。自分のPC上で動く |
| スレッドで得意とされる点 | コード不要で、最初のバージョンを速く | 大きなアプリ、独自バックエンド、確認できる編集 |
| 最大の不満 | 修正に費やされるクレジット（67スレッド中29） | 学習コスト（67スレッド中7） |
| コードの置き場所 | Lovable。GitHub同期は任意 | 自分のリポジトリ |
| データの置き場所 | Lovable Cloud、または自分のSupabaseプロジェクト | 自分で設定した場所 |
| 起こりうる問題 | プロジェクトのロック、データが相手のバックエンドにある | エージェントがPC上で破壊的なコマンドを実行 |
| 67スレッドで見えた移行 | 16人がCursorへ移った | Lovableへ移った人は0人 |
よくある質問
CursorはLovableより優れている？ 最初のバージョンを過ぎたアプリなら、これらのスレッドの多くは「はい」と言っています。コードを書かない人の最初のバージョンなら「いいえ」です。Lovableのほうが速く、設定も済んでいます。
LovableのプロジェクトをCursorに移せる？ できます。LovableでプロジェクトをGitHubに接続し、リポジトリをcloneしてCursorで開きます。バックエンドは別に計画してください。アプリがLovable Cloudで動いているなら、データベース、ユーザー、シークレットはコードと一緒には移りません。気づくのが遅かった人が何人もいました。
LovableのほうがCursorより安い？ 短いプロジェクトなら、たいていそうです。修正が多い長いプロジェクトでは、スレッドは「違う」と言っています。Lovableでは、修正が成功してもしなくてもクレジットがかかるからです。実際の金額は、1つの変更に何回プロンプトが必要かで決まります。
両方使える？ できます。数か月使った人の間で最も多い構成です。最初の画面はLovable、アプリに本物のロジックが必要になったらCursor。間にGitHubを挟みます。
同じ445スレッドからの比較は、Lovable vs Bolt、Lovable vs Base44、Lovableの次に人が行く先にあります。