バイブコーディングに選ぶなら?LovableとCursorの料金・保守・移行を比較【2026年】

バイブコーディングでMVPを作るなら、LovableとCursorのどちらを選ぶべきでしょうか。月額料金、ホスティング、コードの所有権、保守の責任を比較し、GitHub経由で作り直さずに引き継ぐ手順を解説します。非エンジニアの創業者やPMが、デモ完成後の運用まで見据えて判断するためのガイドです。

公開日

バイブコーディングに選ぶなら?LovableとCursorの料金・保守・移行を比較【2026年】

バイブコーディングでアイデアを動くWebアプリのMVPにしたいものの、まだコードを保守できる人がチームにいないなら、Lovableが向いています。すでにリポジトリがある、または公開後のアプリを担当する開発者がいるなら、Cursorを選びましょう。有料プランの月額はそれぞれ$25と$20からですが、LovableとCursorを選ぶ決め手は、最初のデモができた後の作業を誰が引き受けるかです。

バイブコーディングにはLovableとCursorのどちらが向いていますか?

エンジニアではない人がWebアプリのMVPを作り始めるなら、Lovableが有利です。開発者が既存のアプリを保守するなら、Cursorが適しています。 MVPとは、顧客がその製品を求めているかを確かめられる、必要最小限の機能を備えた製品です。次に何を検証し、何を変える必要があるかに合わせて選びましょう。

  • アイデアはあるが、開発者がいない創業者: Lovableから始めましょう。顧客が利用するまでの流れ、アプリに保存する情報、そして実際に使いたい人がいるかに集中できます。
  • 開発チームと協働するPM: 新しい体験を探るならLovable、チームの既存リポジトリ内で行う作業ならCursorを使います。リポジトリとは、コードをバージョン管理しながら保存するフォルダです。
  • Lovableでアプリは動いているが、解決できない技術的な問題がある創業者: コードから原因を調べられる人に加わってもらい、その作業にCursorを使いましょう。エディタを変えるだけでは、アプリの問題は直りません。
  • アプリが安定して動き、目的を果たしている創業者: Lovableを使い続けましょう。有料ユーザーがついたというだけで、うまくいっているMVPを移す必要はありません。
判断のポイントLovableCursor
始めるのに適した状態普段の言葉で説明できるアイデアがあるレビューと保守を担当できる人がいるプロジェクト
入門向け有料プランの月額Pro:ワークスペースごとに$25Pro:個人ごとに$20
ホスティングとデータベースマネージド型のアプリホスティングと組み込みのCloudバックエンドアプリのインフラは別途選び、運用する
コードの持ち出しやすさエクスポートとGitHubの双方向同期プロジェクトのファイルを直接扱う
選択を左右する制約任意の既存GitHubリポジトリはインポートできない保守を担う人や、マネージド型のアプリバックエンドが付くわけではない

料金は2026年10月11日に確認しました。 Lovableの料金ページとCursorの料金ページに掲載された、米ドル建ての月払い料金を使用しています。本記事は公開ドキュメント、料金の確認、予算の試算に基づく比較です。ログインしてのアプリ作成や性能テストは実施していません。使い始める際の手間、インフラの運用責任、コードの持ち出しやすさ、保守、月額費用を判断材料にしています。

プロンプトから始めるか、リポジトリから始めるか

Lovable:エンジニアでなくても始めやすい

Lovableは、説明文からユーザーインターフェースとバックエンドを生成するAI Webアプリビルダーです。Cloudサービスにはデータベース、ログイン、ファイルストレージ、そして画面の裏側でコードを実行するサーバー関数が用意されています。製品が役立つかどうかを確かめる前に決めておかなければならない、いくつもの初期設定を省けます。Lovable Cloudのドキュメント。

創業者が、顧客からの依頼を受け付けるポータルの需要を検証するとします。最初の指示では、誰が依頼を送るのか、どの項目に入力するのか、誰がその情報を閲覧できるのか、その後どう処理するのかを明確にすると効果的です。Lovableは、そうした構想を顧客に見てもらえる形にするのに適しています。ホスティング構成を先に選ばなくても、業務の流れが妥当かを判断できます。

壁になるのは、問題の原因を特定する作業です。ある顧客が別の顧客の依頼を閲覧できてしまうなら、画面をきれいにしたり、大まかなプロンプトを追加したりするだけでは足りません。誰かが権限ルールを理解し、データにアクセスするすべての経路で修正が有効かを確かめる必要があります。行レベルセキュリティ(RLS)とは、ユーザーごとにアクセス可能なレコードを制御するデータベースのルールです。見た目の好みではなく、バックエンドで責任を持って扱うべき領域です。

この段階で必要なのは技術的なレビューです。Lovableではログイン機能や本番用アプリを作れない、という意味ではありません。公式ドキュメントにもセキュリティポリシーの制御機能が記載されており、自動チェックは完全な監査ではないと明示されています。

技術面の保守担当者なしで始めるなら、Lovableが有利です。 Proの最小プランは月額$25です。ただし、自社がすでに所有するリポジトリを拡張する仕事では、主な作業環境として選ばないほうがよいでしょう。エクスポート用の連携機能は、任意のリポジトリをインポートするためのものではありません。運用を任せられる環境が必要なら、Lovableの代替ツールガイドでほかのビルダーも確認できます。

Cursor:既存のコードを扱う作業に向いている

Cursorは、プロジェクトのファイルに対する変更を指示できるAIコーディング環境です。Agentはコードの検索、ファイルの編集、ターミナルコマンドの実行に対応しています。こちらも、英語の自然な文章で作業を伝えながら進められます。違うのは、その周辺にあるソフトウェア運用のどこまでを自分たちで担うかです。Cursor Agentのドキュメント。

Cursorでも、既存のリポジトリなしにプロンプトから作り始められます。 クラウドエージェントのセットアップには、CursorのリポジトリサービスであるOriginに下書きを作成するStart from scratchがあります。この方法には有料プランとOriginの設定が必要で、ドキュメントに記載された公開手順では、別のVercelホスティングアカウントを接続します。本記事の読者にとってLovableが有利なのは、プロンプトから作れること自体ではなく、アプリの運用まで一体化されている点です。Cursorのセットアップと公開ガイド。

同じ受付ポータルでも、外部サービスへの連携リクエストが失敗すると送信内容が消える、といった原因を開発者が追う場面があります。Cursorでは関連ファイルを調べ、動作を修正し、プロジェクトのチェックを実行できます。コードと、そのコードが生む動作を直接扱うことになります。

エンジニアでなくても、この作業手順を学ぶことはできます。ただし、変更を依頼できることと、その変更を承認できることは別です。Cursorのクイックスタートでも、編集の最後には差分、つまり変更された行の一覧を確認し、チェックを実行する手順が置かれています。危険な変更や不十分な修正を見抜く人は、やはり必要です。Cursorのクイックスタート。

既存リポジトリを変更するなら、Cursorが有利です。 Proは月額$20からです。技術的な支援を増やさず、理解できないLovableのエラーを、同じく理解できないCursorのエラーに置き換えるだけなら、移行は見送りましょう。Cursorのレビューでは、この作業環境をより詳しく解説しています。

ホスティングとデータベース:運用も任せるならLovable

アプリの作成だけでなく、その稼働もプラットフォームに任せたいなら、Lovableが有利です。 ホスティングは利用者に向けてアプリを動かす場所で、データベースはレコードを保存する場所です。エディタの利用料とアプリの運用費は、支払う対象が異なります。

Lovableは、顧客が操作する画面であるフロントエンドと、マネージド型のバックエンドサービスをまとめて提供します。Cursorはソフトウェア上の作業を支援しますが、そのソフトウェアをどこで動かすかは別途選びます。クラウドエージェントのワークフローでは、接続したVercelアカウント経由で公開できます。ただし、その接続によってCursorの契約にLovableのようなマネージド型バックエンドが含まれるわけではありません。

承認ワークフローを検証するPMにとって、この違いはすぐに効いてきます。Lovableなら、フォーム、承認ステータス、アクセスルールを中心に製品の議論を進められます。コードとホスティングを別々に用意する構成では、設定、デプロイ、バックアップ、復旧も誰かが担当しなければなりません。

必要なホスティング環境は、実際のコードにも左右されます。Lovableの現行ドキュメントでは、サーバー側のコードを実行する新しいTanStack Startアプリと、静的ファイルを生成する従来のReact + Viteアプリが区別されています。静的ホスティングは生成済みのファイルを配信し、サーバーホスティングはアプリのコードも実行します。エクスポートしたアプリはどれでも静的ホスティングに載せられる、と想定した引き継ぎ計画を受け入れる前に、実際のプロジェクトを確認してください。Lovableのホスティングと所有権に関するドキュメント。

MVPでは、要件を満たす範囲で運用負担が最も小さい構成を選びましょう。バックエンドとリリース手順がすでに決まっている既存の業務アプリなら、Cursorのほうがその運用に自然になじみます。

コードを所有することと、保守すること

開発者が主導する保守にはCursorが適しています。一方、Lovableにも実用的なエクスポート手段があります。 コードの所有権だけを理由にLovableを離れる必要はありません。その所有権を生かして作業できる人が必要です。

LovableとCursorのGitHub連携:エクスポートでできること

GitHubは、コードとその変更履歴を保存するサービスです。LovableからGitHubにリポジトリを作り、変更を双方向に同期できます。開発者はそのプロジェクトをCursorで編集し、接続されたブランチを通じて変更を戻せます。ブランチとは、コードの変更を分けて進めるためのものです。Lovableの所有権に関する規約では、オープンソースライセンスなどの第三者の権利を守ることを条件に、ソースコードを変更したり、別の場所でホスティングしたりすることも認められています。GitHub連携。

ただし、持ち出しと取り込みの条件は対称ではありません。LovableのプロジェクトはCursorで扱えますが、別の場所で始めた任意のプロジェクトをLovableに取り込めるわけではありません。 両方を継続して使うなら、既存の同期接続を維持してください。一度切断してから接続し直すと、元のリポジトリに再接続するのではなく、新しいリポジトリが作られます。

創業者にとって、意味のある引き継ぎはリポジトリのURLを渡すだけでは終わりません。次の保守担当者に、何がどこで動くのか、サービスのアカウントは誰が管理するのか、どうリリースするのか、不具合のある変更からどう復旧するのかを説明してもらいましょう。ファイルをダウンロードしただけでは、その開発者がアプリの責任を引き受けたことにはなりません。

PMはチームと責任範囲を決めましょう。どの製品変更はLovable内で進められるのか、どの変更にはコードレビューが必要か、誰が公開するのかを明確にします。共有ブランチを確認せずに、別々の人が同じ動作をそれぞれ変更する状況は避けてください。コードを両方のツールが書く場合でも、この調整は必要です。

LovableとCursorの料金:開発にかかる月額費用

1人分の基本料金はCursorのほうが低い一方、運用負担はLovableのほうが小さくなる場合があります。 どちらも、最小プランだけでMVPが完成すると保証しているわけではありません。作る範囲、修正の繰り返し、アプリの稼働、保守を担当する人によって、実際の支出は変わります。

現行の月払いプランは次のとおりです。

プラン月額料金主な利用枠・課金単位
Lovable Pro$25月間100 Proクレジット、共有ワークスペース
Lovable Proの上位クレジット枠$50月間200 Proクレジット
Lovable Business$50月間100 Businessクレジット、追加の管理機能
Cursor Pro$20個人アカウント、モデル利用枠を含む
Cursor Pro+$60個人アカウント、Agent利用上限はProの3倍
Cursor Ultra$200個人アカウント、Agent利用上限はProの20倍

出典:Lovableの料金、Cursorの料金。月払い料金は2026年10月11日に確認しています。適用される税金と外部サービスの費用は、別途予算に含めてください。Cursorは、エージェントを日常的に使う場合にPro+を推奨しています。最小プランの料金で、無制限に作業できるわけではありません。

Lovableのクレジット残高は、アプリの作成、Cloud、アプリ内AIの利用に使われ、追加付与分もあります。Cursorは、プラン内の利用枠を使い切った後、有料のオンデマンド利用に対応しています。Lovableの1クレジットはCursorの1リクエストと同じではなく、完成するソフトウェアの量が一定になる単位でもありません。どちらの料金ページからも、特定のMVPを作るための正確な利用料を両ツール間で換算することはできません。

同じ小規模MVPを作る、1か月分の予算

創業者が1人で、検証用の顧客依頼受付ポータルを作るとします。機能の範囲は固定し、作業は選んだプランの利用枠内に収まるものとします。最初の試算では、アプリ稼働に伴う有料の超過利用、外部サービス、人件費を除きます。

  • Lovableのみ: Proの最小プランを1か月利用して$25です。
  • Cursorのみ: Proを1か月利用して$20に、アプリに必要な運用費が加わります。
  • 引き継ぎ月に両方を利用: 基本料金は$25 + $20 = $45です。
  • Cursor Pro+で引き継ぎ: 基本料金は$25 + $60 = $85です。

これはサブスクリプションの予算であり、ポータルの制作費を実測したものではありません。運用費と保守費を加えると、1人で使う場合の損益分岐点はすぐに訪れます。Cursor側の追加費用がLovable側より$5高くなるだけで、$20対$25という基本料金の差はなくなります。 計算式は「$20 + Cursorの追加費用 = $25 + Lovableの追加費用」です。必要に応じた技術レビューも含め、両方で同じ費目を数えてください。

基本料金の差を節約するためだけに、動いているアプリを移行しないでください。まず、実際に必要な保守やホスティング作業の見積もりを取りましょう。

共同作業する人数が増えると、料金の比較も変わる

Lovableはメンバーごとではなく、ワークスペースで共有するクレジット枠に課金します。同じ範囲の検証プロジェクトで、その枠が十分であれば、作業者が1人、2人、3人でも月額は$25のままです。Cursor Proのアカウントを個別に契約すると、それぞれ$20、$40、$60になります。ここで比べているのは個人向けの契約であり、Cursor Teamsの管理機能ではありません。

月額料金の比較グラフ。Lovable Proは共有ワークスペースの料金が25ドルのまま。Cursor Proはアカウントが1人、2人、3人分になると20ドル、40ドル、60ドルになる
基本料金の損益分岐点の試算では、作業者が2人になるとLovableのほうが安くなります。ただし、固定した作業量が共有クレジット枠内に収まることが条件です。ホスティング、超過利用、人件費は含みません。

計算式は「$25 = $20 × 作業者数」で、分岐点は1.25アカウントです。人数を整数で考えると、この前提では1人ならCursor、2人以上ならLovableのほうが安くなります。2人で利用すると、Lovableは1人あたり$12.50、Cursorは1人あたり$20です。ただし、同じ量のAIを使えると示したわけではありません。作業が増えて共有枠を使い切れば、Lovableの料金が横ばいという前提は崩れます。

Lovableの利用量がProの最小枠を超えたら、200クレジットのProを選ぶと、月額を$25追加して月間枠を倍にできます。同じ$50のBusinessは、最小枠が100クレジットのままで管理機能を追加するプランです。クレジットを増やす近道としてではなく、その管理機能が必要な場合に選びましょう。Lovableの料金ガイドとCursorの料金ガイドでは、課金の仕組みをさらに詳しく解説しています。

LovableからCursorへ:作り直さずに引き継ぐ手順

まずコードを編集する作業環境を移し、稼働中のバックエンドは必要が生じたときに移します。 Lovableには、ホスティングとCloudサービスを使い続けながらローカルで開発する手順が用意されています。エクスポートしたコードをCursorで開くために、データベース、ログイン、ファイルストレージをすぐに置き換える必要はありません。

コードはLovable、GitHub、Cursorの間で同期されます。データ、認証、ファイルを扱う稼働中のバックエンドは、別途移行するまでそのまま残ります
エディタの引き継ぎとバックエンドの移行は別のプロジェクトです。コードのブランチを分けても、稼働中のデータベースは分離されません。
  1. 自社で管理するアカウントにコードを接続する

    LovableでProject settings → Git → GitHubを開きます。権限を持つオーナーが、利用するGitHubのアカウントまたは組織にワークスペースを接続し、その後プロジェクトを接続します。Lovableがリポジトリを作成し、同期を開始します。両ツールを継続して使うなら、この接続を維持してください。GitHub連携の公式設定手順。

  2. 編集の前に、保守担当者にプロジェクトを確認してもらう

    接続したリポジトリをクローンし、そのフォルダをCursorで開きます。フレームワーク、起動手順、設定、外部サービスを確認してください。書き直しを依頼する前に、まずアプリの仕組みを説明してもらいましょう。最初は、受付フォームの入力項目のバリデーションを直すといった、範囲の小さな明確な変更を選び、レビューの手順を整えます。

  3. コードの試行と本番データを切り離す

    書き込みを実行する前に、ローカルの設定がどのバックエンドを参照しているかを確認してください。Gitのブランチを分けても、別のデータベースは作られません。保守担当者と相談し、分離した環境か、管理されたテストデータを用意しましょう。そうしなければ、ローカルのアプリから公開中のアプリと同じレコードを変更してしまう可能性があります。

  4. レビュー後に同期し、必要な部分をデプロイする

    コードの変更とプロジェクトのチェック結果を確認し、Lovableが同期するブランチにマージします。プレビューを確認し、準備ができたら公開します。コードの同期だけでは、サイトの公開、新しいデータベースマイグレーションの実行、変更したバックエンドのEdge Functionsのデプロイは自動では行われません。それぞれのリリース操作を明示的に実施する必要があります。Lovableのローカル開発と同期のガイド。

  5. 実行環境も移すなら、別途移行費用を見積もる

    レコード、アップロード済みファイル、ログインプロバイダー、シークレット、サーバー関数、定期実行ジョブ、外部連携を洗い出します。そのうえで、復元できることを確認し、切り替え手順も含めた、作業範囲の明確な移行計画を立ててもらいましょう。リポジトリのエクスポートにはソースコードとデータベース構造のファイルが含まれますが、保存済みのレコードやアップロード済みファイルは含まれません。Lovableの外部ホスティングガイド。

完全に移行するには、現在Lovable経由で動いている連携機能も置き換える必要があります。データベース、ログイン、ストレージを提供するバックエンドサービスのSupabaseは、ドキュメントに記載された移行先のひとつです。ただし、運用環境全体を丸ごと取り込めるわけではありません。データ転送と外部連携の作業費は、エディタの利用料とは別に見積もってください。

顧客に基本的な業務フローをまだ受け入れてもらえていない、アプリが現在の目的を十分に果たしている、あるいは移行後のリリースを担う人がいないなら、まだ切り替えないでください。コードを直接扱うことが特定の問題の解決に役立ち、その結果を検証できる人がいるときが切り替えのタイミングです。必要なのが別のマネージド型ビルダーなら、バイブコーディングツールの比較で候補を広げましょう。

よくある質問

初心者にはCursorよりLovableが向いていますか?

エンジニアではない人が新しいWebアプリを検証するなら、Lovableが向いています。初期設定やインフラに関する判断を減らせるためです。すでに開発者が関わっている場合や、既存リポジトリに合わせて作業する必要がある場合は、Cursorのほうが適した出発点になります。

Lovableで実際に使えるアプリを作れますか?

マネージド型バックエンドを備えた、動作するWebアプリを生成できます。ただし、そのアプリを顧客に提供できるかは、権限、データの扱い、重要な業務フローによって決まります。プレビューが正常に動くことは有意義な到達点ですが、すべての業務ルールが正しく実装されている証明にはなりません。

Cursorは料金に見合う価値がありますか?

自分自身、または保守担当者が変更をレビューし、アプリを運用できるなら、検討する価値があります。まだ障害の原因を調べられないなら、利用料に加えて学習や技術的な支援の予算も確保しましょう。高機能なエディタを契約するだけで、責任を持つ保守担当者が生まれるわけではありません。

これらのツールで作ったコードを自分で所有できますか?

Lovableは、第三者の権利を守ることを条件に、コードの所有とエクスポートを認めています。Cursorは自分のプロジェクトファイルを直接扱います。LovableからCursorに引き継ぐ場合は、GitHubリポジトリを自分たちの管理下に置いてください。コードをエクスポートしても、稼働中のデータベースやアップロード済みファイルまでは持ち出せない点にも注意が必要です。

以下のAI業務ワークフロー監査チェックリストを使い、業務フロー、担当者、予算を明確にしましょう。ニュースレターに登録すると、最新のビルダー比較を受け取れます。

公開日
カテゴリー
Build
ローカルLLM比較:OllamaとLM Studioの選び方

ローカルLLM比較:OllamaとLM Studioの選び方

ローカルLLMを使うならOllamaとLM Studioのどちらが適しているのでしょうか。開発者向けAPIとデスクトップでの使い勝手から、ヘッドレス運用、Mac・GPU対応、商用利用のライセンス、無料のローカル実行と任意のクラウド料金まで比較。会話状態の保持や認証、推論の実行先も踏まえ、用途に合う選び方を解説します。2026年10月11日Build
Cursor Rulesの設定・書き方|TypeScriptで使える3つのルール例

Cursor Rulesの設定・書き方|TypeScriptで使える3つのルール例

Cursor Rulesの設定場所と書き方をTypeScript向けの3つの例で解説。Project Rules・User Rules・Team Rulesの使い分けから、適用条件、実際の変更での検証までを整理。繰り返す修正を減らすために、スタイル・テスト・セキュリティの指示をどう絞り、チームで見直すかがわかります。2026年10月11日Build
Codex CLIの使い方:導入からチーム共通設定まで

Codex CLIの使い方:導入からチーム共通設定まで

Codex CLIのインストールからChatGPT・APIキーでの認証、最初のテスト追加と差分レビューまでを解説。モデル選択、サンドボックスと承認、AGENTS.md、config.toml、MCP、worktreeの設定を整理し、小規模チームで共通ルールを整えて導入するための手順と確認ポイントを紹介します。2026年10月11日Build
Claude Code 使い方ガイド:手戻りとコストを減らす実践習慣

Claude Code 使い方ガイド:手戻りとコストを減らす実践習慣

Claude Codeの使い方を、検証・計画・CLAUDE.md・コンテキスト管理から実践的に解説。採用された変更あたりのコストを測り、権限設定、フック、サブエージェント、worktreeを必要な順に導入する方法を紹介します。小規模チームが手戻りを減らし、利用枠を有効に使うための具体例とコマンドをまとめました。2026年10月11日Build
Codex MCP 設定をチームで共有するには?プラグインの作成と導入

Codex MCP 設定をチームで共有するには?プラグインの作成と導入

Codexのプラグインで、作業手順とMCP接続設定をチームに配布。3ファイルのパッケージ作成から、リポジトリのマーケットプレイスへの登録、CLI・デスクトップアプリでの導入まで解説します。個別のサービス認証、管理者の公開制御、対応するマニフェスト形式も整理し、APIレビューの具体例で共有の流れを確認できます。2026年10月11日Build
Claude Code ルール設定ガイド:CLAUDE.mdと自動メモリの使い分け

Claude Code ルール設定ガイド:CLAUDE.mdと自動メモリの使い分け

Claude CodeのルールをCLAUDE.mdにまとめ、チームで同じ説明を繰り返す手間を減らしましょう。小規模チーム向けのひな形を使い、指示ファイルの置き場所、パス別ルール、AGENTS.mdとの使い分け、自動メモリの保存範囲と月次整理まで解説します。チームで共有する指示と、個人の学習メモを無理なく管理できます。2026年10月11日Build
decision model比較2026:Jevの代替7選を料金と導入条件で選ぶ

decision model比較2026:Jevの代替7選を料金と導入条件で選ぶ

Jevの代替となるdecision modelを、料金・入力形式・ライセンス・実行環境で比較。Perplexity、Cloudflare Clef、Microsoft、OpenAI、Liquid d1、Strandsの向き不向きを整理し、月額費用の試算と移行時の確認点から、自社の判断業務に合う候補を選べます。2026年10月11日Build
OpenAI Decisions APIの使い方:問い合わせの自動振り分けと料金

OpenAI Decisions APIの使い方:問い合わせの自動振り分けと料金

OpenAI Decisions APIの使い方を、問い合わせチケットの自動振り分けを軸に解説します。三つのリクエスト例、回答拒否への対応、信頼度のしきい値、料金と制約を整理。既存のLLM呼び出しやルール処理を残すべき場面も含め、移行の手間に見合うかを実データで判断するための手順を紹介します。2026年10月11日Build
ニュースレター

毎週日曜、一通の手紙。動くシステムの話。感想戦ではなく。

週刊。スパムなし。いつでも解除できます。