社内でAI開発ツールの話題が出ると、ほぼ必ず同じ質問が飛んできます。「LovableとCursor、どっちを入れるべきですか」。情報システム部門は後者を、事業部門は前者を推していて、どちらの言い分にも理があるように聞こえる。予算は1つなので、どちらかに決めなければならない——という前提で議論が進みます。
この前提が、そもそも間違っています。両者は同じ問題を別の方法で解くツールではなく、開発の異なる工程を担うツールだからです。比較して一方を落とすのではなく、どこで受け渡すかを設計するのが正しい問いになります。
この記事では、LovableとCursorの役割の違いを2026年9月1日時点の公式情報で整理し、検証から本番化までをどうリレーするかを具体的に示します。なお同じカテゴリのAIアプリビルダー同士の比較は論点が別になるため、本記事では扱いません。
結論から言えば、競合というより工程の前後関係にあります。両者が想定している「使う人」がまったく違うためです。
Lovableは、コードを書かない人を含むチームが、自然言語で画面・データベース・認証・公開までを一気通貫で作ることを想定しています。入口は空のプロジェクトで、出口は動いているアプリです。対してCursorは、コードエディタです。公式ドキュメントが示すとおり、既存のコードベースを前提に、エンジニアがAIの支援を受けながら編集する道具です。入口は既存のリポジトリで、出口は変更されたコードです。用語の定義はLovableの用語集、機能の更新履歴はチェンジログで確認できます。
（出典：Cursor は、意欲的なソフトウェアを構築するためのコーディング エージェント）
つまり「ゼロから形にする」段階と「既存のコードを育てる」段階で、それぞれ最適化されています。片方だけを見て他方を評価すると、必ず不当な結論になります。Cursorに「非エンジニアが使えない」と言うのも、Lovableに「大規模リファクタリングができない」と言うのも、設計思想を外した批判です。
役割の違いを、判断に使える形で分解します。着目すべきは機能の多寡ではなく、誰が・どの状態から・何を得るために使うかです。
| 観点 | Lovable | Cursor |
|---|---|---|
| 主な利用者 | 業務部門・非エンジニアを含むチーム | エンジニア |
| 入口の状態 | アイデアのみ（コードなし） | 既存のコードベース |
| 作業の単位 | 画面・機能・データ構造 | ファイル・関数・差分 |
| 付随して用意されるもの | データベース・認証・ホスティング・公開 | なし（別途用意する） |
| 得意な局面 | 要件が固まる前に動くものを出す | 本番運用中のコードを安全に変える |
この表で実務上いちばん効くのは、4行目です。Lovableは組み込みバックエンド（Cloud）を持ち、データベース・認証・ストレージ・公開までを追加の契約なしに扱えます。Cursorはエディタなので、動かす環境は自前で用意します。「動くものを見せる」までの距離が違うのは、この差によるものです。
逆に、本番稼働中のシステムに機能を1つ足すという作業では、既存コードの理解と差分の最小化が価値になります。ここはCursorの領域であり、Lovableで代替する必要はありません。
調達の観点でも性格が異なります。ここは稟議の書き方に直結するため、機能より先に確認しておく価値があります。
2026年9月1日時点のCursorの料金ページでは、無料のHobby、個人向けのPro（月20ドル）とその上位ティア、チーム向けのTeams（1ユーザーあたり月40ドル）、そしてEnterpriseが提示されています。TeamsではSAML/OIDCによるSSO、チーム全体のプライバシーモード、利用状況の分析が提供され、Enterpriseでは請求書・発注書（PO）による支払い、SCIMによる座席管理、監査ログ、リポジトリやモデルへのアクセス制御が挙げられています。プライバシーモードを有効にするとコードのデータが学習に使われないと明記されています。
（出典：Cursorの料金ページ）
一方Lovableは、公式料金ページでPro 月額25米ドル・Business 月額50米ドル（いずれも税別、月払い・100クレジットの場合）が下限とされ、月額は契約時に選ぶクレジット量で決まります（Proは1クレジット0.25米ドル、Businessは0.50米ドル）。クレジットが不足した場合はトップアップで追加購入する形です。さらに2026年からは、開発時の消費だけでなくホスティングやデプロイ済みアプリのAI利用も同じクレジット残高から差し引かれるため、実際の費用は利用量に応じて増減します。課金単位が座席ではなくワークスペース共有のクレジットである点（メンバー数は無制限）が、座席課金を基本とするCursorとの構造的な違いです。ただしCursorも座席に含まれる利用枠を超えると従量課金が発生するため、「固定 vs 変動」という単純な対比にはなりません。
データの扱いも前提が異なります。Lovableの公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはモデル学習に利用される可能性があり、個別にオプトアウトできる一方、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。Cursorはプライバシーモードの有効化で対応します。両ツールを併用する場合、この設定・契約の確認は2回必要になるということです。
併用の設計とは、要するに引き継ぎ点をどこに置くかという設計です。早すぎれば検証の速さを失い、遅すぎれば作り直しになります。
判断材料は感覚ではなく、次の4つの事象です。いずれかが起きたら、その時点が引き継ぎ点だと考えて構いません。
第一に、要件が確定して以降の変更が「調整」ではなく「最適化」になったとき。第二に、パフォーマンスや例外処理など、画面に現れない品質を作り込む必要が出たとき。第三に、既存の社内システムとの連携仕様が複雑になったとき。第四に、変更の頻度が下がり、代わりに1回あたりの慎重さが求められるようになったときです。
逆に、まだ画面の構成や項目が動いている段階でCursorに移すのは早すぎます。この段階では、非エンジニアが自分で触って確かめられることのほうが価値が高いためです。
技術的な経路はGitHubです。公式ドキュメントによれば、Lovableのプロジェクトはリポジトリと双方向で同期します。Lovable側の変更はGitHubへ同期され、同期中のブランチへプッシュされた変更はLovableへ戻ります。ローカルにクローンして外部のエディタで編集した内容も、同期中のブランチにプッシュすれば反映されます。
注意点が2つあります。ひとつは、Lovableが一度に編集・同期できるのは1ブランチのみである点です。もうひとつは、リポジトリはLovableが作成し、既定で非公開になりますが、所有者はGitHubのアカウントまたは組織である点です。リポジトリの削除・移動・名称変更は同期を壊すため、命名規則を先に決めておく必要があります。
組織要件がある場合は、Enterpriseで GitHub Enterprise Cloud のリージョン指定（`*.ghe.com` ホストの指定によりリージョンを固定）や、GitHub Enterprise Server の自社ホストにも対応するとされています。データの所在に制約がある企業では、引き継ぎ経路の設計にこの選択肢を含めてください。
このリレーが成立するのは、成果物がコードとして取り出せる場合に限られます。ここが担保されていないツールでは、そもそも引き継ぎという発想が成り立ちません。
Lovableの公式FAQは、プロジェクトとコードの所有者が作成者自身であると明記しています。GitHub同期と組み合わせることで、検証段階の成果物をそのままエンジニアの作業環境へ渡せます。
この点は、稟議での説明にも使えます。「試作が無駄にならない」「特定ツールに縛られない」という主張を、機能として裏づけられるからです。逆にいえば、コードを取り出せないツールで作った試作は、本番化の段階で必ず作り直しになります。検証段階のツール選定で、ここを軽視すべきではありません。
引き継ぎの議論は、コードを渡す話で終わりがちです。しかし実際に効いてくるのは、その後の稼働コストと責任の所在です。ここを決めずに渡すと、数か月後に「誰の予算で動いているのか分からないアプリ」が残ります。
まず稼働の形が変わりうる点を押さえてください。公式ドキュメントによれば、Lovableの組み込みバックエンド（Cloud）と自前のSupabase接続の間には自動マイグレーション機能がなく、どちらの方向にも移行できません。スキーマの再構築とデータの手動移行が必要になります。つまり「検証はCloudで、本番は自前で」と後から切り替える計画は、想定より重い作業になります。
Cloudのまま本番運用する場合は、Cloud usageとしてデータベースサーバーの稼働、保存容量、ネットワーク、ストレージ、バックエンド処理、リアルタイム更新のメッセージが継続的にクレジットを消費します。利用者数に比例して増えるため、引き継ぎ時に「誰の予算で、どの上限まで」を決めてください。プランによってはメンバーごとのクレジット上限を設定できます。
責任については、公開の承認者と障害時の一次対応者を引き継ぎ時に文書化するのが最小限です。公開の手順とセキュリティセンターの最終スキャン日時を合わせて見れば、点検状況は機械的に確認できます。
引き継ぎがうまくいかない原因の多くは、コードではなく意図が渡っていないことにあります。画面を見れば構造は分かりますが、なぜその設計にしたのかは分かりません。
有効なのは、渡す直前にPlan modeで現状の構造を整理させることです。Plan modeはコードを書かずにプロジェクトのファイルやデータベース、ログを調べ、構造化された計画を提示するモードで、メッセージあたり1クレジット固定で動きます。ここで出力された内容は、そのまま引き継ぎ資料の下敷きになります。
あわせて、セキュリティの実践ガイドに沿って、認証していない訪問者に何が見えるか、他人のデータが見えないか、管理者専用の操作が一般利用者に開いていないかの3点を確認し、その結果も添えてください。引き継ぎ後にこの確認をやり直す工数のほうが、渡す前に記録する工数より大きくなります。
設計を誤ると、2つのツールに払いながらどちらの利点も得られない状態になります。頻度の高い失敗を挙げます。
最も多いのが、引き継いだ後もLovable側で編集を続けてしまうケースです。同じブランチを両側から変更すれば、当然ながら競合します。引き継ぎ後の編集主体をどちらにするかを、日付を切って明示してください。
次に多いのが、引き継ぎが早すぎるケースです。要件が固まる前にエンジニアへ渡すと、仕様変更のたびにエンジニアの工数が消費され、「結局いつもの開発と同じ」という結論になります。これはツールの問題ではなく、渡すタイミングの問題です。
三つめが、権限設計の確認を「どちらかがやっているはず」と互いに思い込むケースです。Lovable側では公開時にBasic Scanが自動実行され、RLSポリシーのリンティングやデータベースの設定ミスを検査しますが、引き継ぎ後の変更については、エンジニア側のレビュー体制で担保する必要があります。責任の受け渡しを明文化してください。
2つ契約することの利点と負担を並べます。単純に足し算で判断すると、多くの場合コスト過大になります。
| 観点 | メリット | デメリット・留意点 |
|---|---|---|
| 速度 | 要件確定までを非エンジニアが担い、エンジニアの着手が遅くなる分だけ手戻りが減る | 引き継ぎ点の合意形成に時間がかかる |
| 費用 | 試作フェーズにエンジニア工数を投じずに済む | 2ツール分の契約と、それぞれの管理が発生する |
| 統制 | 両者ともSSOと学習利用の制御に対応 | 設定・契約の確認が2系統になる |
| 人材 | 業務知識を持つ人が直接形にできる | 引き継ぎを担えるエンジニアが最低1人は必要 |
| 資産 | コードが自社に残り、移行の自由度が高い | リポジトリの命名・ブランチ運用の設計が必須 |
この表で見落とされやすいのが、4行目です。併用モデルは「エンジニアが不要になる」構想ではありません。むしろ、引き継ぎを受けられるエンジニアがいることが前提条件です。その人がいない組織では、Lovable単独で完結する範囲に用途を絞るほうが現実的です。
予算や運用体制の都合で1つに絞る必要がある場合、判断軸は「社内にエンジニアがいるか」ではなく「作りたいものが既存システムの改修か、新規の業務アプリか」です。
新規の業務アプリで、まだ要件が固まっておらず、非エンジニアが主体になるならLovableです。既存の本番システムに手を入れる用途が中心で、担当がエンジニアであればCursorです。この判断を「どちらが高機能か」で行うと、ほぼ確実に外します。
迷う場合は、直近3か月で発生した開発ニーズを紙に書き出し、新規と改修で分類してみてください。件数の多いほうが答えです。組織の実態は、機能表ではなく過去の依頼履歴に表れます。
選定の壁打ちや、検証から本番化までの体制設計に関するご相談は、株式会社100のLovable公式パートナーページで承っています。
通常のコードベースとして扱えます。ただしLovableが同期できるのは一度に1ブランチのみのため、作業ブランチの運用を決めておかないと同期が想定外の挙動になります。
そのプロジェクトを今後Lovableで編集しないなら可能ですが、組み込みバックエンド（Cloud）を使っている場合は、ホスティングとバックエンドの移設先を先に決めてください。契約状態と稼働は別の話です。
要件が確定している改修であれば、その主張は正しい可能性が高いです。Lovableの価値は要件が固まる前の局面にあるため、確定済みの作業で比較すると優位性は出ません。比較する工程を揃えて議論してください。
単純に倍にはなりませんが、SSOの接続、学習利用の設定・契約、監査ログの取得先が2系統になります。導入前に、それぞれの管理者と棚卸しの担当を決めておいてください。
推奨しません。既存コードの構造理解を前提とした道具であり、レビューできない状態で変更を加えると、影響範囲を把握できません。役割を分けたほうが安全です。
データ構造と項目の定義、権限設計の意図、そして未実装のまま残した箇所の一覧です。画面は見れば分かりますが、この3つは見ても分かりません。ナレッジ機能に前提を記述しておくと、引き継ぎ資料の下敷きになります。
工程が違う以上、寄せる必要はありません。判断すべきは、自社の開発ニーズが新規寄りか改修寄りかという構成比の変化です。構成比が変われば投資配分を変える、という運用が実務的です。
LovableとCursorは、同じ問題を解く競合ではありません。Lovableは要件が固まる前に非エンジニアを含むチームが動くものを出す工程に、Cursorはエンジニアが既存のコードベースを安全に変える工程に、それぞれ最適化されています。
したがって決めるべきは優劣ではなく、引き継ぎ点です。要件が確定し、画面に現れない品質の作り込みが必要になった時点が目安になります。経路はGitHubの双方向同期で、Lovableが同期できるのは一度に1ブランチという制約と、リポジトリの所有者がGitHub側の組織であるという前提を押さえておけば運用できます。
そして併用が成立する条件は2つあります。コードを持ち出せること、そして引き継ぎを受けられるエンジニアが最低1人いることです。後者がいない組織では、Lovable単独で完結する範囲に用途を絞るほうが確実です。
Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、体制設計のご相談は株式会社100の問い合わせ窓口をご利用ください。
最終更新日: 2026年9月1日