CursorとLovableの違いと使い分け

CursorとLovableは、どちらも自然言語からコードを書き、Webアプリを作れるAIです。

ただ、入口がかなり違います。

既存コードを含め、開発者がコードベースを直接扱いながらAI Agentを使うならCursor。アイデアからWebアプリを作り、非エンジニアも含めて画面を見ながら進めたいならLovableという分け方が分かりやすいです。

2026年にはCursorも「repoなしでゼロからCloud Agentを開始」できるようになり、Lovableとの境界は少し近づきました。

それでも、Cursorは開発環境中心、Lovableはプロダクトビルダー中心という違いが残っています。

先に比較

表は横にスクロールできます

見るポイント	Cursor	Lovable
主な入口	コードエディタ / Agent	チャットからアプリ生成
対象	開発者中心	非技術者〜開発者
コード編集	エディタで直接	AI / visual / code、GitHubへexport
既存repo	強い	GitHub連携可能
ゼロから作る	対応、Cloud Agentでstart from scratch	中心用途
Backend	自分のstackを扱う	Lovable Cloud等でfull-stack構築
Hosting	Vercel等へpublish、自由度高い	Lovable Cloudでpublish可能
Code ownership	自分のrepo	ユーザーがproject/codeを所有
料金単位	plan + model usage	workspace credits

Cursorは「コードベースをAIと一緒に触る」道具

CursorはAIコードエディタです。

Tab補完、Agent、Cloud Agents、MCP、skillsなどを使い、コードベースを直接編集します。

既存repoへ入って、

• バグ修正

• refactor

• test追加

• 複数ファイル変更

• PR作成

• Cloud Agentへ長時間タスクを委任

といった仕事を進めるのが自然です。

コードが中心にあり、その周囲にAI Agentがいるイメージです。

Lovableは「作りたいサービスを会話から形にする」入口が強い

Lovableは公式に「AI software engineer」と説明され、専門知識がなくてもチャットからWebサイトやWebアプリを作れるサービスです。

アイデア、画面、機能を伝えると、実際のアプリへ変換します。

2026年のLovableは、buildだけでなくLovable Cloudでhostingし、アプリ内AI機能を動かすこともcreditsで管理します。

そのため、

「repoを開いてコードを直す」

より

「こういうサービスを作りたい」

から始める人には理解しやすいです。

Lovableでもコードは自分のもの

Lovableはノーコードの閉じたサービスではありません。

公式Termsでは、ユーザーがCustomer Data、作成したapplications / websites / projects、AI Outputを所有するとしています。

さらにGitHubへcodeをsync / exportでき、別環境へdeployすることもできます。

つまり、

Lovableで作ったら一生Lovableの中でしか編集できない

という構造ではありません。

開発者へ引き継いだり、GitHub上でPRレビューしたりする流れを作れます。

Cursorもゼロから作れるようになった

以前は「Cursorは既存repo、Lovableは新規アプリ」と分けやすかったのですが、2026年8月以降は少し違います。

Cursor Cloud AgentにはStart from scratchが追加され、repoを接続せずプロンプトから開発を始められます。

完成後はCursor Origin repoとして保存し、Vercelアカウントを接続してpublishできます。

そのため新規アプリでもCursorを使えます。

ただしCursorでは、最終的にコード、dev environment、repoという開発者向け概念が中心です。

Lovableはそれらを意識しなくても最初のアプリを作りやすい。

この差は残っています。

非エンジニアを含むチームならLovableが分かりやすい

Lovableはproduct manager、designer、operatorなど、エンジニア以外もworking softwareを作ることを強く意識しています。

visual editingやchatで変更しつつ、エンジニアはGitHubでコードを確認できます。

企画担当が自分で試作し、必要になったら開発者へ引き継ぐ。

こういう流れには合いやすいです。

Cursorはコードエディタが中心なので、少なくともrepository、terminal、dependencyなど開発の基本概念を理解している方が扱いやすくなります。

既存システムの深い改修ならCursorを先に見る

既に大きなNext.jsやReact、backend、monorepoがあり、その中へ機能を追加する。

この場合はCursorを先に確認しやすいです。

Cursor Agent / Cloud Agentはrepo全体を読み、testを実行し、複数repoをまたいだ変更も扱えます。

LovableもGitHub連携できますが、サービスの中心は「Webアプリを構築する」ことです。

既存コード保守と新規product buildingでは、仕事の重心が違います。

料金の考え方も違う

Cursor個人プランはHobby無料、Pro $20/月、Pro+ $60/月、Ultra $200/月です。

Cursorはmodel usageのpoolがあり、上限後はon-demand usageを追加できます。

Lovableはworkspace単位のcreditsでbuild、Cloud、アプリ内AI機能を支払います。

Freeにはdaily build credits等があり、paid planではcredits balanceを柔軟に使います。

さらにLovableはper-seat課金ではなく、workspaceへ何人招待してもsubscription cost自体は増えず、共有creditsの消費量が増える仕組みです。

「1人の開発者へいくら」なのか、「チームで1つのアプリをどれだけbuildするか」なのかで料金の見方が違います。

Cursorを先に試しやすい人

• コードを直接編集する

• 既存repoを改修する

• terminalやGitを日常的に使う

• 複数Agentへ開発タスクを委任したい

• 自分でstack / infrastructureを決めたい

Lovableを先に試しやすい人

• アイデアからMVPを作りたい

• 非エンジニアでも画面を見ながら変更したい

• Webアプリを自然言語中心で作りたい

• Lovable Cloudで公開まで進めたい

• 後からGitHubへコードを渡せる形にしたい

既存コードか、完成イメージかを小さく試す

比較の結論を出す前に、実データを使わない小さな課題を用意します。たとえば「イベント申込の1ページを作り、必須項目・確認画面・送信後表示を実装する」という短い仕様です。画面の見た目だけでなく、入力エラー、スマートフォン表示、コードの持ち出し、修正後の再確認までを受け入れ条件にします。CursorとLovableの両方で同じ仕様を頼み、使った時間、手修正、仕様漏れ、次の担当者がコードを読めるかを記録します。実サービスの個人情報や顧客コードは試験に含めません。

表は横にスクロールできます

いまの状況	先に確認する候補	理由と次の確認
既存リポジトリの変更が中心	Cursor	既存コードを理解しながら変更・テストする運用と合うかを確認
仕様を画面にし、MVPを早く見せたい	Lovable	会話からUIを組み立てる流れが合うか、生成後のコードを引き継げるかを見る
非エンジニアも継続して触る	Lovableを候補に含める	UI上の変更だけで運用できる範囲と、開発者へ渡す境界を決める
権限・既存設計を細かく管理したい	Cursorを候補に含める	生成よりコードレビュー、テスト、権限管理に時間を割けるか確認

料金も単純な月額比較では終わりません。Lovableのbuild・Cloud・AI機能は共通クレジットを使い、作業によって消費量が変わります。無料枠のクレジットには日次上限や月次上限があり、workspace内で共有され、未使用分の扱いにも条件があります。見積もりを取るなら、同じ小課題を複数回行い、使ったプラン、workspaceの人数、表示された残量を記録します。Cursor側もモデルやAgentの使い方で利用量が変わるため、表示された月額だけで実運用コストを断定しないでください。

公開前には両方で、生成コードの動作、依存パッケージのライセンス、認証情報の扱い、デプロイ先、エラー時に戻せる方法を人が確認します。Lovableの公式案内ではFree / ProはPrivacy設定から学習への利用をオプトアウトでき、Business / Enterpriseのworkspaceデータは学習に使わないとされています。検証アカウントのプランと設定を確認し、顧客情報や社内コードを入力してよいかは別途組織ルールで判断します。

AIものさしの判断

CursorとLovableは「コードを書けるAI」という点では重なります。

ただし選ぶ基準は、AIの賢さより誰が主に操作するかです。

開発者がコードベースを握り、AIへ作業を委任するならCursor。

企画・デザイン側も含め、まず動くWebアプリを会話から作るならLovable。

新規開発なら両方候補になりますが、既存repoの深い開発とMVP作成では自然な入口が違います。