Claude CodeとLovableの違い — アプリ生成と既存コードの使い分け
Claude CodeとLovableの違いを、作業の起点・課金の単位・コードの持ち出し・公開の経路で比べ、新規アプリを一気に作る場面と手元のリポジトリを育てる場面の分かれ目を示します。
Lovableは「アプリを作って出す場」、Claude Codeは「手元のコードを育てる道具」
Lovableは、自然言語でWebアプリを作り、公開まで進めるAI開発プラットフォームです。フロントエンド・バックエンド・データベース・認証・外部連携を含むアプリを、編集可能なコードの形で生成します。
Claude Codeは、手元のリポジトリに対して動くコーディングエージェントです。ターミナル、IDE、デスクトップ、Webのどこからでも使えますが、仕事の中心は既存コードの読解・修正・テストです。
二つの違いは、起点にあります。アプリが無いところから作るのか、コードがあるところから育てるのか。
| 観点 | Lovable | Claude Code |
|---|---|---|
| 作業の起点 | Lovable説明文から新しいプロジェクトを生成 | Claude Code手元にある既存のリポジトリ |
| 作業の単位 | Lovableワークスペース内のプロジェクト(1つが1アプリ) | Claude Code開いているディレクトリ |
| 課金の単位 | Lovableワークスペース共有のクレジット | Claude Code主にClaudeのサブスクリプション、またはAPIのトークン従量 |
| コードの出口 | LovableGit同期かダウンロード | Claude Code最初から自分のリポジトリ上 |
| 公開 | LovablePublishで公開URLが発行される | Claude Codegit・CIなど既存の経路 |
Replitのようなブラウザ完結型との比較はClaude CodeとReplit Agentの違いで扱っています。概念の整理が先ならvibe codingの安全な始め方が入口になります。
作業の起点 — 新規生成と既存リポジトリで向きが逆になる
Lovableの説明では、利用者は作りたいものを書き、Lovableがフロントエンド・バックエンド・データベース・認証・連携を含む動くアプリを生成します。対象にはプロトタイプ、社内ツール、SaaS、ダッシュボード、ランディングページなどが並びます。プレゼン資料やPDF・Excel・Wordといった文書、画像・動画の生成も含まれます。
人の動きは次の順です。作りたいものを書き、プレビューで確かめ、直して、公開する。コードを読めることは前提になっていません。
ここで見落としやすい制限があります。Git同期のページには、Export onlyの注記があります。既存のリポジトリをLovableに取り込むことはできず、プロジェクトをつなぐと、Lovableは必ず新しいリポジトリを作ります。
つまり次のように分かれます。
- すでに数年育ったリポジトリがある: Lovableの入口には載りません。Claude Codeを置く場面です
- 白紙から画面を立ち上げたい: Lovableが最短です
- 立ち上げたあと、育て続ける: コードをGitに出し、手元でClaude Codeに引き継ぐ流れがあります
Claude Code側の入口は逆向きです。リポジトリのCLAUDE.md、設定、MCPサーバーがあり、そこに依頼を投げます。ターミナル、VS Code、JetBrains、デスクトップ、Webのどこから使っても、同じ設定が効きます。
課金の単位 — クレジットの消費とトークンの消費
課金の考え方も別物です。
何を数えて課金するか
Lovable
ワークスペースが共有のクレジットプールを持ちます。プランはプロジェクト数や席数ではなく、クレジットで値付けされています。ビルド、チャット、Cloud(ホスティングと組み込みバックエンド)、デプロイ後のアプリのAI機能、コネクタが同じ残高から引かれます。
Claude Code
コストはAPIのトークン消費で決まります。Pro・Max・Team・Enterpriseのサブスクリプションでは、プランの利用枠に対して消費します。Consoleやクラウド事業者経由なら、トークン従量で請求されます。
Lovableのクレジットの出方を、数字で確かめます。
Lovableの無料枠と有料枠
Freeの日次ビルドクレジット
5/日
月30まで
有料プランの月次クレジット
100〜
ProとBusinessは100/月から
Planモードの1メッセージ
1
調査の追加分は別
ビルドモードの消費は一定ではありません。例示された目安では、ボタンを灰色にする変更が0.50、認証の追加が1.20、画像付きのランディングページが2.00です。これは例であり、実際の消費は依頼の複雑さで変わります。
長いビルドには安全弁があります。1メッセージの消費が既定で20クレジットに達すると、実行がいったん止まり、続けるか仕上げるかを選べます。同じ1メッセージが最大10時間動くことがあるため、止める地点があるのは判断材料になります。
Claude Code側の目安も押さえておきます。コストの解説ページによると、企業導入全体の平均は開発者1人あたり活動日で約13ドル、月150〜250ドルで、9割のユーザーは活動日あたり30ドル未満に収まっています。開発者ごとの差は、モデル選択、コードベースの規模、複数インスタンスや自動化の有無で大きく動きます。節約の手順はClaude Codeのコスト管理に、サブスクのプラン差はClaude Codeのプラン別機能差にまとめています。
数え方の違いは、財布の見え方に響きます。Lovableは「何回作り直したか」がクレジットに直結し、Claude Codeは「どれだけコードを読み書きさせたか」がトークンに直結します。
コードの持ち出し — Git同期で守るべき運用の癖
LovableのコードはLovableのプラットフォーム内に保存されます。外に出す経路は二つです。
- Git同期: GitHub、GitLab、Bitbucketの自分のリポジトリと自動で双方向に同期する
- コードのダウンロード: 有料プランで、プロジェクト設定かコードエディタから取得する
Gitを使わずに作って公開まで行く人も多い、とも書かれています。
Git同期にはClaude Codeと組み合わせるときに効く決まりがあります。
- Lovableが編集・同期するのは1本のブランチだけ。ほかのブランチのコミットは、同期ブランチへマージするまでLovable側に現れない
- 同期ブランチでのforce-push、rebase、squashは避ける。履歴を書き換えると、次の同期でLovableのコピーが置き換わる(置き換わる前にバックアップは取られる)
mainへの直接pushが保護されている場合、Lovableのpushは拒否され、lovable-syncブランチに送られる- ドラフトはリポジトリのブランチとして現れない。受け入れたあとに届く
さらに、クローンしたコードはサービスごと手元に来るわけではありません。Lovable Cloudを使うプロジェクトでは、.envに本番と同じバックエンドのURLと公開用キーが入っています。そのまま動かすと、ローカルでの書き込みが本物のデータを変えます。Gitのブランチを切っても、データベースは別になりません。
VITE_で始まる変数はブラウザに届くコードに含まれるため、サービスロールキーなどの秘密は入れない、と注意されています。
Edge Functionsとマイグレーションにも癖があります。コミットが同期されても、Lovableは変更されたEdge Functionをデプロイせず、新しいマイグレーションも流しません。反映はプロジェクトのチャットでLovableに頼むか、SQLを自分で実行します。
Claude Codeを同じリポジトリに乗せる — CLAUDE.mdの断片と検証
Git同期済みのリポジトリにClaude Codeを入れるなら、Lovable側の決まりをCLAUDE.mdに書いておくと、事故を減らせます。次は、Lovableの同期ルールに沿った一例です。
## Lovable連携リポジトリの決まり
- 作業は`feature/*`ブランチで行い、`main`へはPR経由でマージする
- `main`へのforce-push・rebase・squashはしない(Lovableのコピーが置き換わる)
- `.env`のバックエンドは本番と同じ。書き込みを伴う動作確認は、テスト用のアカウントとレコードに限る
- `VITE_`で始まる変数に秘密を入れない
- supabase/functions と migrations を変えたら、反映はLovableのチャットで依頼する旨をPRに書くマージのあとは、手戻りを減らす検証が効きます。Claude Codeに次のように頼みます。
git diff main...HEAD --stat を実行し、
変更ファイルのうち supabase/ 配下と .env に触れたものを列挙して。出力を読み、バックエンド側に触れていれば、Lovableへ反映を頼むメモをPRに加えます。Lovable側にも、手元で変えた内容を引き継ぐための雛形があります。
I changed [files] outside Lovable to [describe the change]. Keep [behavior or constraint] when making further edits. Now [describe the next change you want].マージが同期ブランチに届き、同期状態が揃ったら、変更ファイルをコードエディタで開いてプレビューで挙動を確かめます。その上で上の雛形をLovableのチャットに貼ります。
公開までの経路 — Publishと自前のデプロイ
Lovableの公開は、エディタ右上のPublishを2回押す操作です。公開されたアプリはlovable.app上で動き、Free・Proでは、リンクを知る人なら誰でもアクセスできます。BusinessとEnterpriseは、ワークスペースの既定設定に従います。
Claude Codeの主な使い方は、成果物をgitに返し、デプロイは既存のCIが受け取る形です。CIとの接続はGitHub Actionsのワークフロー作成で扱っています。
公開の手間を減らしたいならLovable、公開後の運用を既存の仕組みに載せたいならClaude Codeです。
併用の道 — Lovable MCPサーバーをClaude Codeから呼ぶ
二つは競合だけではありません。Lovableは自分自身をhttps://mcp.lovable.devのMCPサーバーとして公開しており、Claude Codeから接続できます。全プランで使えます。
claude mcp add --transport http lovable "https://mcp.lovable.dev"初回のツール実行でブラウザが開き、Lovableにログインします。接続は/mcpで確かめられ、「Lovableのワークスペースを一覧して」と頼んでも動作を見られます。Lovableのプラグインを入れる方法もあります。
接続後にClaude Codeへ頼める作業は次のとおりです。
- 新しいLovableプロジェクトの作成(
create_project) - 既存プロジェクトへの変更依頼、ファイル構成の確認、直近の編集差分の取得
deploy_projectによる公開と、公開URLの取得
一つのセッションの中で、ほかのMCPツールと組み合わせられる点が強みです。たとえば、Claude Codeでコンテンツを生成し、LovableでUIを立ち上げ、公開URLだけを返すといった分業が組めます。
MCP経由でも、create_projectとsend_messageには通常のLovableクレジットがかかります。ほかのツールは無料です。Claude Code側のトークン消費と合わせて、二重に動く点は見積もりに入れておきます。
使い分けの早見表
| 状況 | 向く道具 | 理由 |
|---|---|---|
| 説明文から社内ツールや画面を最短で立ち上げたい | 向く道具Lovable | 理由生成から公開URLまでが1つの場所で完結する |
| 既存リポジトリのバグ修正・リファクタ | 向く道具Claude Code | 理由Lovableは既存リポジトリを取り込めない |
| 立ち上げたアプリを、チームの開発フローに載せる | 向く道具両方 | 理由Git同期で出し、手元のレビューとCIはClaude Codeが受ける |
| コードを読み書きしない人が試作を作る | 向く道具Lovable | 理由コードを前提にしない入口がある |
| 認証・DB込みの本番データを手元から触る | 向く道具条件次第 | 理由.envが本番バックエンドを指すため、テスト用データに限る |
| 費用の見通しを立てたい | 向く道具どちらも要計測 | 理由片方はクレジット、片方はトークンで、単位が違う |
まとめ
Lovableは、無いところにアプリを作り、公開まで運ぶ道具です。Claude Codeは、あるコードを読み、直し、テストし、PRに返す道具です。
選ぶ軸は機能の優劣ではなく、起点と出口です。起点が説明文ならLovable、起点がリポジトリならClaude Code。出口が公開URLならLovable、出口がPRならClaude Code。両者をつなぐ必要が出たら、Git同期の決まりをCLAUDE.mdに書き、MCPサーバーで橋を架けます。