Lovableが本当は何なのか（そして何ではないのか）

Lovable（以前はGPT Engineerとして知られていた）は、シンプルなテキストプロンプトからReact + TypeScriptアプリケーションを作成するAI駆動型のアプリビルダーです。バックエンドにはSupabase、スタイリングにはTailwind CSS、コンポーネントにはshadcn/uiを搭載しています。簡潔に言うと、大規模言語モデルをラップしてコードを書き、デプロイを支援し、「会話」によって変更を加えることができるツールです。

それでは、良い部分は？簡単なリストを紹介します：

  • 高速プロトタイピング：数分で動作するUIを構築できます。ランディングページ、シンプルなCRUDアプリ、または基本的なダッシュボードが必要な場合、Lovableはこれらを素早く組み立てます。
  • 非開発者向けのアクセシビリティ：プロダクト担当者やデザイナーが自分でコードを書かずに、機能的なプロトタイプを組み立てたい場合、非常に便利です。
  • スムーズなSupabase統合：特にシンプルなユースケースでは、認証とデータベース接続の設定が非常に簡単です。

しかし、ちょっと待ってください。Lovableは人間の開発者のようにソフトウェアを構築しているわけではありません。いいえ。プロンプトからコードを生成することすべてです。プロジェクトがコンテキストウィンドウの閾値を超えた場合、特にコードベース全体の永続的なメモリを持ちません。この小さな詳細は、アプリが大きくなると大きな問題に変わります。

Lovable App Limitations: Why Projects Break After 15 Components

15コンポーネントの壁：プロジェクトが壊れる理由

この現象を15コンポーネント壁と呼ぶのが好きです。正確な数字は厳密ではなく、人によっては12コンポーネントで起こり、他の人は20かもしれません。しかし、すべてが崩壊し始める一貫したパターンが存在します。

では、なぜ15なのか？トークン計算に要約されます。特にTailwind、props、状態管理、およびビジネスロジックが装備されたReactコンポーネントは、80～200行のコード範囲で実行されます。15個のコンポーネントを取得すると、生成されたコードはおよそ1,500～3,000行になります。プロンプト履歴全体とLovableが依存している内部システムプロンプトを追加すると、言語モデルの有効なコンテキストウィンドウに接近します。

ここが結果です：

症状1：スタイル後退

ナビゲーションバーは数回のプロンプトにわたって注意深く洗練されていました。その後、Lovableが新しいページコンポーネントを生成し、推測できますか？ナビゲーションバーのパディングがシフトし、ホバー状態が消えるか、モバイルレスポンシブ動作が暴走します。あなたはそのような混乱を要求していません。

症状2：ロジックの競合

認証ガードが魅力のように機能していました。新しい機能を追加し、バーン、突然認証されていないユーザーが歩んで通り抜けます。AIは意図的にそれを妨害していませんでした。新しいコードを生成しながらロジックを追跡するだけで失いました。

症状3：重複した矛盾するコード

何もないところから、Lovableはユーティリティ関数を作成しており、コードベースは既にこれを持っています。さらに悪いことに、異なる動作を持つ新しいバージョンを作成します。これで2つのformatDate関数があり、異なるコンポーネントは異なるものを使用します。混乱万歳！

症状4：インポート/エクスポート混乱

コンポーネントリストが花開くと、Lovableは快活に壊れたインポートパス、循環依存関係、または約3回のプロンプト前に名前が変更されたコンポーネントへの参照を排出します。

キッカー？各個別プロンプト応答は完全に見える—孤立したものとして見た場合。AIは持っているコンテキスト内で最善を尽くしますが、もはや十分ではありません。

コンテキストウィンドウ後退の説明

さて、少し技術的になりましょう。これを理解することで、実際に問題を回避するのに役立ちます。

Lovableは128K～200Kトークンの範囲のコンテキストウィンドウを備えた大規模言語モデル（ClaudeまたはGPT-4クラス、おそらく両方）を使用しています。大きく聞こえますか？まあ、細分化するとそうではありません。

Lovableセッションの大まかなトークン予算は次のとおりです：

トークンコンシューマー 推定トークン パーセンテージ
システムプロンプトと指示 5,000-15,000 5-10%
プロンプト履歴 10,000-50,000 10-30%
現在のコードベースコンテキスト 20,000-80,000 15-50%
生成応答 2,000-8,000 2-5%
安全マージン/オーバーヘッド 10,000-20,000 5-15%

コードベースが特定のサイズに達すると、Lovableはお気に入りをプレイし始め、コンテキストに含めるコードを決定します。RAG（検索拡張生成）と推測を使用して、現在のプロンプトに最も関連のあるファイルを選択します。ネタバレ：常に正しく推測されるわけではありません。

目立たない問題はこのコンテキストウィンドウ後退です—AIは不完全な情報を持っているファイルを調整し、空白を仮定で埋めることが多く、それは誤っています。

私はこれが何度も起こるのを見てきました：

// プロンプトの前にコンポーネントがどのように見えたか
export const UserProfile = ({ user, onUpdate, showAdmin }: UserProfileProps) => {
  const [isEditing, setIsEditing] = useState(false);
  const { role } = useAuth();
  
  // ... 注意深く作成された50行のロジック
  
  return (
    // ... 管理者ビュー、編集モードなどを処理するJSX
  );
};

// Lovableが「bio フィールドを追加する」と要求した後に再生成したもの
export const UserProfile = ({ user }: { user: User }) => {
  // 失われたもの: onUpdate prop、showAdmin prop、useAuth フック、isEditing 状態
  // 追加されたもの: bio フィールド、しかし他のすべてはシンプル化/壊れている
  return (
    // ... 元の機能の半分が不足しているシンプル化されたJSX
  );
};

AIは完全なコンポーネントを見ていませんでした。不完全なコンテキストと「UserProfile」コンポーネントであるべきものの一般化された考えに基づいてバージョンを組み立てました。特定のロジック？消えました。

最も一般的なバグとスケーリング問題

Reddit、Discord、および私の実践的な経験を通じて、最も一般的な問題のリストは以下の通りです。

1. Supabase行レベルセキュリティの競合

機能を追加すると、Lovable製のRLSポリシーは互いに足を踏みます。関係のある数個のテーブルの後、ポリシーは混乱した混乱に変わります。場合によっては、新しい機能を生成することはLovableが既存のRLSポリシーを完全にドロップすることに至りました。

2. 状態管理の崩壊

LovableはすべてをローカルのReact状態（useState）にデフォルト設定します。素晴らしい...そうではなくなるまで。コンポーネント間で共有状態が必要になると、幸運をお祈りします。AIはReact Context、プロップドリリング、またはZustandを導入するかもしれません—その時点で何がお好みでも。

3. ルーティングの矛盾

約10ページを取得すると、ルートは互いに競合し始めます。保護されたルートはガード人員を失います。動的ルートのパラメータは誤って処理されます。また、Lovableが重複したルート定義を生成するのを見ました。

4. Tailwindクラスの競合と特異性戦争

これは壁まであなたを駆動させるでしょう。インラインで生成されたTailwindクラスは競合する可能性があります。className="w-full max-w-md w-[500px]" のような何かが現れます—3つの幅宣言が単一の要素をめぐって戦っています。

5. API呼び出しの重複

既存のAPIユーティリティ関数を再利用する代わりに、Lovableは新しいfetchまたはsupabase.from()呼び出しを直接コンポーネントの真ん中に排出します。15コンポーネント目までに、同じデータベースクエリはコードベース全体の6つの不十分に隠れた場所に浮かぶ可能性があります。

6. TypeScript型の浸食

初期は完璧なTypeScript型ですか？ゆっくり浸食します。複雑さで、Lovableはanyにデフォルト設定され、型定義を重複させるか、他のコンポーネントを台無しにする方法で型をそっと狭めます。

7. モバイルレスポンシブネスの回帰

おそらくこれは最も迷惑なバグです。レスポンシブデザインをすべて整理して、デスクトップの変更を加え、ブーム！モバイルが壊れています。AIはコンポーネントを再構成するときに、これらのすべて重要なレスポンシブブレークポイントクラスを頻繁に削除します。

Lovable App Limitations: Why Projects Break After 15 Components - architecture

実ベンチマーク：Lovableが崩壊する場所

同じもの—認証、CRUD操作、チーム管理、およびダッシュボードを備えたプロジェクト管理ツールを、異なるツール使用して構築しました。Lovable、Bolt.new、Cursor、および良い古いNext.jsの手動セットアップ。ここに起こったことがあります：

メトリック Lovable Bolt.new Cursor + Next.js 手動Next.js
動作するプロトタイプまでの時間 25分 30分 2時間 8時間
最初の回帰前のコンポーネント 14 11 N/A* N/A
20コンポーネント時に手動修正が必要なバグ 12 15 3 0
プロジェクト終了時のコード品質（1-10） 3 3 7 9
本番環境にデプロイできるか いいえ いいえ はい（作業あり） はい
バグ修正を含む総時間 12時間 14時間 6時間 8時間

* Cursorは実ファイルシステム内で直接動作するため、壁に当たりません。

最後の行は多くを物語ります。Lovableのプロトタイプへの速度は比類のないものですが、本番環境への準備ができるまで？それは保存されたすべての時間を食べ、それが作成する混乱を修正する際にさらに多くを食べます。

さらに、コスト。2025年半ばの時点で、Lovableは$20/月（スターター、メッセージクレジット制限あり）から$100/月（チーム）の範囲です。問題を修正するためだけにメッセージクレジットを使い切ると、スタータープランは急速に枯渇します。適度に複雑なアプリの回帰を取り消すだけで、200以上のメッセージを使い切りました。

実際に機能する回避策

これらすべての注意事項を考慮して、Lovableの有用性の範囲を拡張する方法があります：

重要なコンポーネントをピン留めします

Lovableに何のファイルを変更しないべきかを明確にします：

変更しないでください次のファイル：
- src/components/Navigation.tsx
- src/components/AuthGuard.tsx  
- src/lib/supabase.ts
- src/types/index.ts

新しい設定ページに関連するファイルのみを作成または変更します。

確実ではありませんが、回帰を軽減するのに役立ちます。

アトミックプロンプトを使用します

プロンプトごとに単数の変更に固執します。「設定ページにユーザー設定、通知制御、テーマスイッチャーを追加する」の代わりに、3つの個別の要求に分割します。より小さな変更はコンテキストをオーバーフローさせるチャンスが少なくなります。

GitHubで外部に編集およびエクスポートします

Lovableをとして同期させてくださいGitHubを最大限に活用します。主な機能を追加した後：

  1. GitHubにプッシュする
  2. ローカルに引き出してレビューする
  3. 問題を手動で修正する
  4. 修正をプッシュバックする
  5. Lovableと同期する

AI生成とヒューマンタッチのこの混合は、見つけた最良のレシピです。

タイプファーストアプローチを確立します

早期にtypes.tsファイルを構築し、明示的に参照します：

src/types/index.ts（User、Project、Task、Team）で定義された型を使用して、TaskListコンポーネントを作成します...

これはLovableに確かなアンカーを与え、型浸食を大幅に削減します。

新しい会話を戦略的に開始します

新しい会話、新しいコンテキスト。時々、コードベースの簡潔な説明を使用してチャットスレッドをリセットすることで、長い進行中のスレッドより魔法のようにきれいな結果が生成されます。

Lovableから移行する時期

ここに適切な開発ツールに交換する時期です：

  • 修正よりも構築に多くの時間を費やします。 それが起こり始めるとき、さて、再考する時間です。
  • 複雑なビジネスロジックが発生します。 マルチステップワークフロー、洗練された認可、リアルタイム機能、支払い—これらは人間の創意工夫を乞います。
  • パフォーマンスが重要です。 Lovableはあなたを始めるが、高度な最適化のために、あなたは適切なツールで専門家の手が必要です。
  • 実際のデータの処理。 AIが生成したコード、特に認証、支払い、またはPIIを取り巻いて、機密性の高い、実際のユーザーデータのリスクを冒さないでください。
  • 信頼できるCI/CDとテストが必要です。 Lovableはあなたのためにテストを書きません。本番環境にテストされていないコードを出荷したい人は誰ですか？

移行はかなり簡単です：GitHubにエクスポート、実数のNext.jsまたはAstroプロジェクトを確立、リファクタリング、テストを追加、および強力なデプロイメントプロセスを設定します。

Lovableプロトタイプを検証しましたか？おめでとうございます。それでは、本当にそれを構築しましょう。ここに私たちが入り、ヘッドレスCMS開発およびカスタム開発サービスを通じて遷移を支援します。

検討する価値があるAlternatives

Lovableに飽きた？ここに次に試すかもしれないことがあります：

Cursor + Next.js/Astro：スケーリング頭痛なしでAI支援を望む開発者向けの黄金の選択。Cursorは実IDEの中で動作し、あなたが制御する実際のファイルに触れます。AIはコードベースを所有することなく支援します。

Bolt.new：Lovableと同様の志向を持ち、同じ天井があります。特定のUIパターンで独特の強みがありますが、Lovableのようなコンテキストで停滞します。

v0 by Vercel：個々のUIコンポーネントを生成するのに最適で、独自のプロジェクトにメッシュします。Lovableより少ないスケール（アプリ全体を構築しようとしていない）、よりきれいなレンズはそれをより信頼できるにします。

Windsurf（Codeium）：別のAI傾向IDE、しかしより大きなコードベース向けです。Lovableとは異なり、ローカルファイルを活用するため、プロジェクト全体をチャットに詰め込もうとしません。

実際の開発：はい、時々あなたは強力なフレームワークを備えた熟練した開発者が必要です。スケール、実際のユーザーの処理、またはプロトタイプを超える夢を目指す場合、優秀な才能と良いフレームワークに勝つものはありません。興味がありますか？Contact us—多くのチームをAIプロトタイプから堅実なアーキテクチャへガイドしました。

FAQ

Lovableアプリがより多くのコンポーネントを追加した後に壊れるのはなぜですか？

Lovableのaiモデルは有限なコンテキストウィンドウを持っています。プロジェクトがスケールアップすると、AIはコードベース全体に対する把握を失います。コードを生成している間、仮定を始め、回帰、スタイルの不一致、およびロジック破損を引き起こします。これは通常、複雑さに基づいて12から20コンポーネントに達すると点火します。

Lovableのコンテキストウィンドウ後退とは何ですか？

あなたのコードが要求することなく魔法で変更されたことのような気がしますか？それはコンテキストウィンドウ後退です。AIは全体像を持たずにコードを修正または再生成し、ライブ実装の代わりにそれのトレーニングデータからの誤った仮定につながります。機能を破る、スタイルを逆転させ、ロジックを拭き取ります—すべて要求なし。

Lovableで本番環境アプリを構築できますか？

多分、あなたが純粋にシンプルなアプリ（ランディングページ、基本的なCRUDツール、内部ダッシュボード、限られた人数）に固執している場合。ただし、複雑なロジック、実際のセキュリティ、迅速なパフォーマンス、またはやや重要なユーザーベースが関係するあらゆることについては、いいえ。それはプロトタイピング天国で、本番環境パワーハウスではありません。非常に示唆、テストはゼロを作成し、パフォーマンスはゼロを最適化し、そしてセキュリティパターン？彼らは進行中の仕事だと言いましょう。

Lovableは壊れる前に何コンポーネントを処理できますか？

ほとんどの人は12から20コンポーネント間で問題に遭遇します。コンポーネントの複雑さ、プロンプト履歴の長さ、および埋め込まれた状態/ロジックの量などの要因はこのしきい値に影響します。簡単で、ディスプレイヘビーなコンポーネントは複雑なステートフルなコンポーネントよりも多くのスペースを提供します。

Lovableはアプリを構築するためにBolt.newより優れていますか？

彼らは鏡像で、強みと弱みを共有しています。Lovableはsupabase統合の優位性を持っていますが、Bolt.newはデプロイメントでわずかに多目的です。両方は同じ成長壁に直面します。シンプルなモデルを超えた本番環境アプリについては、どちらも切ります。2025年までに、両方とも$20/月で始まり、Lovableの計画は$100/月まで上昇します。

Lovableの回帰を始めずに修正するにはどうすればよいですか？

最良の治療法は、GitHubで、ローカルIDE（VS CodeまたはCursor）で監査し、手動で修正してからLovableと同期できないことです。他のトリック：アトミックプロンプト（リクエストごとの1つの変更）、スペアするファイルを述べる、チャットがふくれあがるときに新しい会話で開始します。

プロジェクトのためにLovableまたはCursorを使用する必要がありますか？

高速プロトタイピングとアイデア検証？Lovableはケーキを取ります。実際のユーザーデプロイメントのため、コンテキスト制約のないAI促進を備えた堅牢なフレームワークのようなNext.jsまたはAstroに結合したCursorは提供します。Cursorは既存のファイルで動作するため、コンテキスト問題のないプロジェクト全体を表示します。

Lovableプロジェクトを実際の開発に移行する最良の方法は何ですか？

GitHubで、堅牢なNext.jsまたはAstroプロジェクトを立ち上げるエクスポート、およびLovableスクリプトをブループリントと見なす—再構築、洗練、挿入本物のタイプ、テスト、エラー管理、および実行中にパフォーマンスを向上させます。このルートは、自動生成の混乱の直接リファクタリングよりも高速です。