Lovable AI ビルダーの限界: Next.jsで再構築する時期
以下、翻訳されたマークダウン記事です：
このパターンは何度も見てきました。ファウンダーが週末にLovableでSaaSプロトタイプを立ち上げます。見た目は素晴らしい。投資家は感動します。ユーザーがサインアップします。その後、現実が襲いかかります。Googleがマーケティングページをインデックスしていない、チームワークスペースを追加するとauth フローが壊れる、Supabaseクエリがテナント間で衝突し始める、そしてあなたは製品を構築するのではなくツールと戦っていることに気づきます。
Lovableは確かに素晴らしいツールです。しかし天井があり、本物のSaaSプロダクトを構築するなら、その天井に到達するでしょう。この記事では、Lovableが具体的にどこで不足しているのか、カスタムNext.jsへの移行をいつ計画すべきか、そして正気を保ったままリライトに取り組む方法を詳しく説明します。
目次
- Lovableのアーキテクチャを理解する
- SEO問題：CSRは公開ページにとって行き止まり
- 基本的なログイン以上の認証の複雑さ
- マルチテナントデータ：Lovableに答えがない場所
- スターターSaaS以上のスケーリング
- 移行のタイミング：決定フレームワーク
- リライトへのアプローチ方法
- Lovable vs カスタムNext.js：並行比較
- FAQ
Lovableのアーキテクチャを理解する
制限事項について話す前に、Lovableが実際に何を生成するのかを明確にしておきましょう。内部的には、LovableはVite + Reactアプリケーションにクライアント側レンダリング（CSR）を生成します。以上です。サーバー側レンダリングはありません。静的サイト生成はありません。増分静的再生成はありません。純粋なCSRです。
これは秘密ではありません。Lovable自体のレンダリングに関するFAQがこれを認めています。彼らはSEO対策としてプリレンダリングを推奨しており、SSRは「Lovableの現在の設定では難しい」と正直に述べています。
生成されたコードは通常、以下を使用します：
- React Router クライアント側ナビゲーション用
- Supabase auth とデータベース用
- Tailwind CSS スタイリング用
- shadcn/ui コンポーネント
内部ツール、認証の背後にあるダッシュボード、または急速なプロトタイプの場合、このスタックは完全に問題ありません。問題は、プロダクト要件が単一ページアプリケーションが処理できる範囲を超えて成長するときに始まります。
Lovableが得意な点
信用するべきところでは、Lovableは以下に優れています：
- プロトタイプまでの速度：数週間ではなく数時間で動作するUIを用意できます
- デザイン品質：生成されたインターフェースはすぐに洗練されて見えます
- Supabase統合：基本的なauth フローとCRUD操作は素早く機能します
- コンポーネント品質：生成するshadcn/uiコンポーネントは本番グレードです
問題は品質ではなく、スコープです。Lovableはv0.1にできるだけ速く到達するために最適化されています。v2.0に到達するように最適化されていません。
SEO問題：CSRは公開ページにとって行き止まり
これは最も直接的で痛ましい制限であり、ファウンダーを不意打ちにする傾向があります。あなたのSaaSに公開向けページがある場合——マーケティングサイト、ブログ、ドキュメント、料金ページ、検索可能であるべきユーザー生成コンテンツ——Lovableのアーキテクチャは、あなたに対抗して積極的に機能しています。
クローラーがLovable生成ページにヒットするときに何が起きるか：
<!-- Googlebotが（時々）見るもの -->
<!DOCTYPE html>
<html>
<head>
<title>My SaaS App</title>
</head>
<body>
<div id="root"></div>
<script type="module" src="/assets/index-abc123.js"></script>
</body>
</html>
その空の<div id="root">は、ほとんどのクローラーにとってあなたのページコンテンツ全体です。GoogleのWeb Rendering Service（WRS）はJavaScriptを実行してCSRコンテンツをレンダリングできますが、これには実際の問題があります：
- 保証されていません。 Googleはあなたのコンテンツをレンダリングするかもしれませんし、しないかもしれません。レンダリングするとき、発見から実際のレンダリングまでに数時間から数日の遅延があります。
- 他のすべてのクローラーは失敗します。 LLMクローラー（GPTBot、ClaudeBot、PerplexityBot）、ソーシャルメディアアンフューラー（Facebook、LinkedIn、Twitter/X、Slack、Discord）、Bingのレンダラー（Googleより信頼性が低い）——これらはどれもJavaScriptを確実に実行しません。
- ソーシャル共有は壊れています。 LovableページをLinkedInで共有すると、空のプレビューカードが表示されます。これは成長させようとしているプロダクトにとって悪い第一印象です。
- AI検索の可視性はゼロです。 これは2026年ますます重要になっています。Perplexity、ChatGPT検索、またはClaudeがあなたのコンテンツを見ることができない場合、AI生成の回答に存在しません。
Nati Elimelechが広く共有されたLinkedInの投稿で指摘したように：「Lovableのアーキテクチャ（Vite + React CSR）は根本的に最新のクローラー要件と相容れません。」
Lovableのプリレンダリング対策
Lovableは、プリレンダリングを対策として提供しています。これは動的なReactアプリを構築時に静的HTMLに変換します。本当に静的なページ——シンプルなランディングページ、概要ページには機能します。しかし以下の場合は崩れます：
- 頻繁に更新されるブログコンテンツ（公開するたびにリビルドが必要）
- 動的なプロダクトページ（例：テンプレートギャラリー、マーケットプレイスリスティング）
- ユーザー生成の公開プロフィール
- バージョン管理付きドキュメント
- 1日以上に1回以上コンテンツが変わるページ
これをNext.jsと比較すると、ルートごとのレンダリング制御が得られます：
// 構築時に静的生成（ブログ記事のような）
export async function generateStaticParams() {
const posts = await getAllPosts();
return posts.map((post) => ({ slug: post.slug }));
}
// リクエストのたびにサーバー側レンダリング（ユーザープロフィールのような）
export const dynamic = 'force-dynamic';
// 増分静的再生成（60秒ごとに検証）
export const revalidate = 60;
このルートごとの柔軟性はLovableが提供できないものです。Next.jsプロジェクトをクライアント向けに構築するとき、この粒度のレンダリング制御は、CSR専用ツールから移行する唯一の最大の理由であることがよくあります。
基本的なログイン以上の認証の複雑さ
Lovableのsupabase統合は基本を処理します：メール/パスワードサインアップ、マジックリンク、おそらくGoogleとのOAuth。これはプロトタイプで十分です。本番SaaSには十分ではありません。
認証がどこで複雑になり、Lovableがついていけなくなるか：
ロールベースアクセス制御（RBAC）
本物のSaaSアプリにはロールが必要です。最小限でもオーナー、アドミン、メンバー、ビューアの階層が必要です。Lovableでいるとき、RBACの実装は：
- カスタムSupabase RLS（Row Level Security）ポリシーを手で書く
- クライアント側でロール状態を管理する（認可決定には本質的に不安全）
- Reactコンポーネント内でミドルウェアのようなロジックを構築する
Next.jsでは、コンテンツが送信される前のサーバーレベルで認可を処理します：
// middleware.ts -- ページがレンダリングされる前に実行
import { NextResponse } from 'next/server';
import { createServerClient } from '@supabase/ssr';
export async function middleware(request) {
const supabase = createServerClient(/* config */);
const { data: { user } } = await supabase.auth.getUser();
if (!user) {
return NextResponse.redirect(new URL('/login', request.url));
}
const { data: membership } = await supabase
.from('team_members')
.select('role')
.eq('user_id', user.id)
.eq('team_id', extractTeamId(request.url))
.single();
if (membership?.role !== 'admin' && request.nextUrl.pathname.includes('/settings')) {
return NextResponse.redirect(new URL('/dashboard', request.url));
}
return NextResponse.next();
}
これはサーバーで実行されます。認可されていないユーザーは、設定ページを見ることもなく、HTMLを受け取ることもなく、JavaScriptバンドルを取得することもありません。CSRアプリでは、コードを配布して、クライアント側のチェックで非表示にしています。やる気のあるユーザーなら誰でもバイパスできます。
サブドメイン全体のセッション管理
SaaSがサブドメインを使用する場合（acme.yourapp.comのような）、サブドメイン全体で機能するクッキー、エッジケースを処理するトークンリフレッシュロジック、テナント間でリークしないセッション検証が必要です。Lovableはこれを処理するサーバー側インフラストラクチャを提供していません。本番環境で崩れるワークアラウンドをハック一緒に作成することになります。
エンタープライズSSO（SAML/OIDC）
50人以上の従業員がいる企業に販売している場合、誰かがSAMLまたはOIDC統合を求めるでしょう。これには、サーバー側のコールバック処理、トークン交換、セキュアなセッション作成が必要です。根本的にサーバー側フローです。CSR専用アプリでこれを実装しようとすることは、重力に逆らっています。
マルチテナントデータ：Lovableに答えがない場所
マルチテナンシーはSaaSの定義上の建築上の課題です。すべてのリクエストは正しい組織にスコープされる必要があります。すべてのクエリはテナントでフィルタリングする必要があります。すべてのデータには分離保証が必要です。
Lovableはsupabase を提供します。RLSポリシーを通じてマルチテナンシーを処理できます。しかし、アプリケーションレベルのパターン——ルーティング、コンテキスト、データ取得——は完全にあなたに任せられており、Lovableのaiはマルチテナント対応コードを生成しません。
2つのパターン
| パターン | 例 | 利点 | 欠点 |
|---|---|---|---|
| パスベース | app.com/[team]/dashboard |
シンプルなホスティング、DNS設定不要 | 顧客向けのブランド化が少ない |
| サブドメインベース | team.app.com |
よりよいホワイトラベリング、クリーンなURL | ワイルドカードSSL、DNS設定、ミドルウェアルーティング必要 |
Next.jsは両方をネイティブにサポートしています。App Routerの動的セグメントはパスベースのルーティングを優雅に処理します：
app/
[teamSlug]/
dashboard/
page.tsx
settings/
page.tsx
billing/
page.tsx
サブドメインベースのルーティングの場合、Next.jsミドルウェアはサブドメインを抽出し、ページコードが実行される前にテナントを解決できます：
// middleware.ts
export function middleware(request) {
const hostname = request.headers.get('host');
const subdomain = hostname?.split('.')[0];
// テナントコンテキストを含めるようにURLを書き込む
if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
return NextResponse.rewrite(
new URL(`/${subdomain}${request.nextUrl.pathname}`, request.url)
);
}
}
Lovableでは、これをReact Routerとカスタムフックでワイヤリングし、テナントを解決するためにクライアント側fetch呼び出しを行い、ロード中に間違ったテナントコンテンツのフラッシュを処理する必要があります。これが失敗するのを見ました。きれいではありません。
データ分離懸念
最も恐ろしいマルチテナンシーバグはデータリークです——テナントAのデータをテナントBに表示する。サーバーレンダリングアーキテクチャでは、レスポンスが送信される前のデータレイヤーでテナントスコープを強制できます。CSRでは、クライアント側コードが正しいテナントIDをAPIに渡すことを信頼し、他のすべてをキャッチするようあなたのRLSポリシーに希望しています。
RLSは安全装置です。主要な防衛ではありません。主要な防衛は、すべてのリクエストでテナントコンテキストを検証するサーバー側ミドルウェアです。Lovableはこのレイヤーを提供していません。
スターターSaaS以上のスケーリング
実ユーザー、実データ、実ビジネス要件があるまで表示されない一連の問題があります。Lovableの生成されたコードはこれらのシナリオ向けに設計されていません。
スケールでのパフォーマンス
Lovableアプリはあなたのアプリケーション全体をJavaScriptバンドルとして配布します。アプリが成長するにつれて、バンドルも成長します。React Routerはすべてをメモリに読み込みます。遅い接続や古いデバイスのユーザーはこれを感じます。
Next.jsはルートレベルで自動コード分割を提供します。/dashboardにナビゲートするとダッシュボードコードだけが読み込まれます。/settingsにナビゲートするとsettingsコードだけが読み込まれます。これは自動です——設定する必要はありません。
バックグラウンドジョブとサーバーロジック
本物のSaaSアプリは以下を必要とします：
- Webhookハンドラー（Stripe、SendGrid、サードパーティ統合）
- スケジュールされたジョブ（請求サイクル、レポート生成、データクリーンアップ）
- サーバー側テンプレートを使用したメール送信
- PDF生成
- ファイル処理
これらのいずれもCSR専用アプリケーションでは不可能です。別のバックエンドが必要です。Next.jsでは、webhookとサーバーロジックを直接処理できます：
// app/api/webhooks/stripe/route.ts
export async function POST(request: Request) {
const body = await request.text();
const sig = request.headers.get('stripe-signature');
const event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
switch (event.type) {
case 'customer.subscription.updated':
await updateSubscription(event.data.object);
break;
case 'invoice.payment_failed':
await handleFailedPayment(event.data.object);
break;
}
return Response.json({ received: true });
}
これは実際のAPIエンドポイントです。サーバー側コードを実行します。同じコードベースがあなたのフロントエンドと同じです。別のExpressサーバーなし。別のデプロイなし。
テストとCI/CD
Lovableで生成されたプロジェクトはテストインフラストラクチャなしで提供されます。ユニットテストなし、統合テストなし、E2Eテストなし。プロトタイプでは問題ありません。顧客の支払いと機密データを処理する本番SaaSでは負債です。
Next.jsプロジェクトはJest、Vitest、Playwright、Cypressと自然に統合されます。サーバーコンポーネント、APIルート、ミドルウェアを隔離でテストできます。
移行のタイミング：決定フレームワーク
すべてのLovableプロジェクトがリライトを必要とするわけではありません。実践的なフレームワークがあります：
Lovableに留まる場合：
- プロダクト市場適合前で、まだ検証中
- アプリが認証の背後に完全に存在（SEO必要な公開ページなし）
- シングルテナントモデル（1ユーザー、1アカウント）
- 内部ツールまたは管理パネル
- チームに開発者リソースがない
移行を計画する場合：
- 公開ページへのオーガニック検索トラフィックが必要
- チーム/組織ワークスペースを追加している
- エンタープライズ顧客がSSOを要求している
- Supabase RLSポリシーがスパゲッティ化になっている
- サーバー側統合（webhook、支払い処理）が必要
- ページ読み込み時間がアプリ成長とともに上昇している
- Lovableと戦うのではなく機能構築に時間を費やしている
すぐに移行する場合：
- マルチテナントデータリークが発生している、またはほぼ発生している
- Google Search Consoleは重要なページのインデックス失敗を表示
- SSO/セキュリティ要件のために取引を失っている
- クライアントバンドルが500KB gzipped を超えている
リライトへのアプローチ方法
最悪なことは、すべてをスクラッチから再構築し、スイッチを切るビッグバンリライトを試みることです。それはリライトが死ぬ方法です。
ストラングラーフィグパターン
最も賢いアプローチは段階的です。Next.jsアプリをLovableアプリと一緒にデプロイして、ルートを一度に1つ移行します。
- 公開ページから開始。 マーケティングサイト、ブログ、ドキュメントをNext.jsに移行します。適切なSSR/SSGを使用します。これは即座のSEO勝利を与えます。
- auth層を移行。 Next.jsミドルウェアで認証フローを実装します。これが最も難しい部分です。早期に行います。
- 機能ごとに移行。 最もシンプルなページから始めて、最も複雑なものに向かって作業します。
- コンポーネントを再利用。 Lovableは、ほとんどが最小限の変更でNext.jsで動作するReactコンポーネントを生成します。主にReact Routerの依存関係を削除し、ファイルベースのルーティングに変換します。
NextLovableというCLIツールがあり、構造的な変換の一部を自動化します：
npx @nextlovable/cli convert ./src/components/ -f app-router
これはLovableのフラットコンポーネントディレクトリから、Next.js App Routerのネストされたレイアウトパターンへのファイル構造変換を処理します。ビジネスロジックは処理しませんが、単調なファイル移動を数時間節約します。
予算を何に設定するか
中程度の複雑性のSaaS（10～20ページ、auth、基本マルチテナンシー）の現実的な移行タイムライン：
| フェーズ | タイムライン | 労力 |
|---|---|---|
| 公開ページ + SEO | 1～2週間 | 低 |
| Auth + ミドルウェア | 2～3週間 | 高 |
| ダッシュボード移行 | 3～4週間 | 中 |
| APIルート + webhook | 1～2週間 | 中 |
| テスト + QA | 1～2週間 | 中 |
| 合計 | 8～13週間 | -- |
3ヶ月を移行に費やしたくない場合、それはまさに我々が処理する種類のプロジェクトです。我々は、地雷がどこにあるか知るほどこれをやっています。
Lovable vs カスタムNext.js：並行比較
| 機能 | Lovable（Vite + React CSR） | カスタムNext.js |
|---|---|---|
| プロトタイプまでの時間 | 時間 | 日～週 |
| SSR / SSG / ISR | ❌ なし（プリレンダリングのみ） | ✅ 完全サポート、ルートごと |
| 公開ページのSEO | ⚠️ 低い（Googleのレンダリングに依存） | ✅ 優秀 |
| AI検索の可視性 | ❌ LLMクローラーに不可視 | ✅ 完全に可視 |
| ソーシャルプレビューカード | ❌ 壊れている | ✅ 動的OG画像 |
| マルチテナンシー | ⚠️ 手動、クライアント側のみ | ✅ ミドルウェア + サーバー側 |
| Auth（基本） | ✅ Supabase統合 | ✅ 複数のプロバイダー |
| Auth（エンタープライズSSO） | ❌ サーバー側サポートなし | ✅ SAML/OIDCサポート |
| APIルート | ❌ 別バックエンド必要 | ✅ 組み込み |
| コード分割 | ⚠️ 手動 | ✅ ルートごとに自動 |
| テストインフラストラクチャ | ❌ 生成されたなし | ✅ 完全なエコシステム |
| デプロイメント柔軟性 | Lovableホスティングまたはnetlify/Vercel（静的） | Vercel、AWS、Docker、自己ホスト |
| スケール時のコスト | $20～50/月（Lovable）+ Supabase | ホスティング異なり（$0～200+/月） |
FAQ
Lovableをマーケティングサイト、Next.jsをアプリに使用できますか？
できますが、メンテナンスのオーバーヘッドが生じます。2つのコードベース、2つのデプロイパイプライン、潜在的に一貫性のないデザインがあります。より良いアプローチは、Next.jsですべてを構築することです。マーケティングページに静的生成を使用し、アプリに静的サーバーコンポーネントを使用します。すでにLovableを使用している場合、公開ページの移行のみから始め、完全な移行に準備ができるまでアプリをLovableに保持します。
LovableのプリレンダリングはSEO問題を解決しますか？
部分的に。プリレンダリングは構築時に静的HTMLを生成し、クローラーが読むことができます。頻繁に変わらないページ——概要ページ、料金ページに機能します。頻繁に更新されるブログ記事、ユーザー生成コンテンツ、マーケットプレイスリスティングなどの動的コンテンツには機能しません。コンテンツが変わるたびにリビルドをトリガーする必要があります。これは急速に非実用的になります。Next.jsの ISR（増分静的再生成）は、スケジュールオンデマンド再検証することでこれを優雅に処理します。
Lovable to Next.js移行は通常いくらかかりますか？
シンプルなプロトタイプの場合（5～10ページ、基本auth）、2～4週間の開発者時間を期待します。マルチテナンシー、カスタムauth フロー、API統合を使用した中程度の複雑性のSaaSの場合、8～13週間を予算します。エージェンシーレートでは、複雑さに応じて約$15,000～$50,000です。価格設定を確認、またはあなたの実際のコードベースに基づいてスコープ予定のお問い合わせください。
LovableからカスタムNext.jsへの段階的移行は可能ですか？
絶対に。そしてそれは推奨されるアプローチです。ストラングラーフィグパターンを使用します：Next.jsをLovableアプリと一緒にデプロイ、ルートを一度に1つ移行、公開ページで始め、NextLovableのCLIは構造的な変換の一部を自動化できます。
公開ページの代わりにAstroはどうですか？
Astroは相互作用が最小限の、コンテンツが豊富なサイトに優れています。公開ページがほぼ静的マーケティングコンテンツで、アプリが別のSPAの場合、Astroは素晴らしい選択です。しかし、マーケティングページと動的アプリの両方に1つの統合されたコードベースが必要な場合、Next.jsがより実用的です。クライアントのニーズに応じて両方で構築します。公開ページがどの程度の相互作用を必要とするかに関します。
Lovable ReactコンポーネントはNext.jsで動作しますか？
ほとんどは最小限の変更で動作します。主な変更は：React Routerインポートを削除し、Next.jsLinkとuseRouterを代わりに使用、useStateやuseEffectのようなフックを使用するコンポーネントに'use client'ディレクティブを追加、Lovable固有のユーティリティを置換するです。コンポーネントロジックとスタイリング（Tailwindクラス、shadcn/uiコンポーネント）は直接転送します。
開発者でない場合、Lovableから移動することはできますか？
できますが、開発者の助けが必要です。移行はテクニカルプロジェクトです。フリーランスNext.js開発者を雇用、ヘッドレス開発エージェンシーを使用、またはNextLovable CLIを使用して頭を開始し、複雑な部分のために助けを持ち込むことができます。良いニュースは、Lovableの生成されたコードがクリーンで整形式されており、ほとんどのAI生成コードベースより開発者が作業しやすいということです。
2026年でLovableはいつ正しい選択ですか？
Lovableは内部ツール、認証の背後にある管理パネル、チーム内のダッシュボード、投資家に見せているMVP、ユーザーテスト用の急速なプロトタイプに理想的です。あなたのチーム外の誰もが検索を通じてあなたのアプリを見つける必要がなく、複雑なauthやマルチテナンシーが必要ない場合、Lovableはあなたをかなり遠く取ることができます。重要なのは、あなたが成長した時を正直であること——そして技術的負債があなたを押しつぶしている時まで待たないことです。