Bolt vs Lovable本番環境対応性: セキュリティ、コード品質、スケーラビリティ
過去6ヶ月間、AIビルダーで作成したプロトタイプを本番環境にデプロイしてから、3ヶ月後に全て書き直す羽目になるチームを見てきました。Bolt と Lovable は本当に素晴らしいツールです。どちらも広範に使用してきています。しかし、「動作するデモ」と「本番アプリケーション」の間には危険なギャップがあり、これはどちらのツールのマーケティングも語りたくないものです。
この記事は、Lovable で生成された MVP をクライアント用にデプロイした後、その Supabase RLS ポリシーにユーザーデータを晒す大きな穴があることを発見する前に、誰かが書いておくべきだった正直な解説です。ステージング環境で発見できました。運が良かったわけです。
これらの AI ビルダーアプリをデモ段階を超えて本番運用するときに実際に何が起こるのか、そしてカスタム Next.js ビルドに移行するべき時期がいつなのかを詳しく解説します。
目次
- 2026年の AI ビルダーの状況
- セキュリティの制限: ツールが教えてくれないこと
- 内部のコード品質
- スケーリングの境界: 何が壊れるのか
- 直接比較
- カスタム Next.js への移行時期
- 移行プレイブック
- コスト分析: 構築 vs 再構築
- よくある質問
2026年の AI ビルダーの状況
Bolt と Lovable は両方とも大きく進化しました。Lovable はわずか2ヶ月で 2,000 万ドルの ARR に達し、ヨーロッパのスタートアップとしては最速の成長を遂げています。一方、Bolt.new は6ヶ月で 4,000 万ドルの ARR に到達しました。これらの数字は重要なことを示唆しています。つまり、人々はこれらのツールで実際のものを構築しており、単なるテストではないということです。
しかし、成長数は本番環境対応性と同じではありません。
現在、それぞれのツールがどこにあるのかは以下の通りです:
Lovable はデザインファーストのアプローチを取り、React + TypeScript アプリを Supabase を事前設定されたバックエンドとして生成します。実際にクリーンなコードを生成します — shadcn/ui コンポーネント、適切なローディング状態、エラーバウンダリ、レスポンシブレイアウト。コード品質は AI ビルダーの中で最高レベルです。
Bolt はコードファーストの哲学に従い、React、Vue、Svelte、バニラ JS をサポートするブラウザ内 IDE を提供します。内部では Claude を使用し、「diffs」という賢い機能を持っており、ファイル全体を再生成する代わりに変更されたコードセグメントのみを更新します。Bolt Cloud には現在、組み込みデータベース、認証、ストレージ、ホスティングが含まれています。
どちらのツールも、アイデアから動作するプロトタイプへの移行を午後のうちに実現できます。問題は、その午後の後に何が起こるかです。
セキュリティの制限: ツールが教えてくれないこと
このセクションが最も重要で、他のどこで見つけるよりも最も少ないカバレッジを受けるセクションです。複数のプロジェクトで両方のツールの出力を監査してきましたが、パターンは一貫しています。
Lovable のセキュリティプロファイル
Lovable は Supabase RLS (Row Level Security) ポリシーを自動的に生成します。理論的には、これは素晴らしいです — RLS は堅牢なセキュリティモデルです。実際には、AI が生成するポリシーは、実際の認可要件と一致しないジェネリックなパターンに従うことが多いです。
実例です。Lovable にマルチテナント SaaS をチームベースの権限で構築するよう指示しました。生成された RLS ポリシーは次のようなものでした:
CREATE POLICY "Users can view own team data"
ON public.projects
FOR SELECT
USING (auth.uid() IN (
SELECT user_id FROM team_members
WHERE team_id = projects.team_id
));
妥当そうに見えますね？ただし、重大なエッジケースを見落としています: 無効化されたチームメンバー。team_members.active = true のチェックがないため、チームに属したことのある誰もが、すべてのプロジェクトデータを読み取り続けることができます。AI はアクセス取り消しに関するビジネスルールを理解しません。構造的には正しいが、意味的には不完全なポリシーを生成するだけです。
Lovable の出力で見つけた他のセキュリティギャップ:
- デフォルトではレート制限がない API エンドポイント上
- サーバーサイド関数での入力検証が不足 — クライアント側の検証は存在しますがバイパス可能
- Supabase サービスロールキー がクライアント側コードで参照されることがある (これは重大な脆弱性)
- CSRF 保護がない Supabase Auth がネイティブに提供する機能以上のもの
- 認証トークンの処理 が localStorage に保存される (httpOnly クッキーではなく)
Bolt のセキュリティプロファイル
Bolt のセキュリティ状況はより悪いと言えます。なぜなら、それほど主張的ではないからです。フレームワークの柔軟性は増しますが、AI がセキュリティアーキテクチャについてより多くの仮定を立てることになります。
Bolt Cloud が Lovable の Supabase 統合より新しいため、生成されるセキュリティポリシーより慎重な検証が必要です。見つけたもの:
- 環境変数 がクライアント側バンドルにハードコードされている
- 認証ミドルウェアが不足している API ルート上 — AI が一部のルートで認証チェックを生成しますが、他のルートでは忘れます
- SQL インジェクションベクトル が raw クエリ構築にある (ORM を使用しない場合)
- Content Security Policy ヘッダーなし デプロイメント設定内
- CORS がワイルドカード (
*) に設定されている。本番ビルドに引き継がれる開発環境で
Bolt が生成した API ルートで実際に SQL インジェクション脆弱性があったのは次のものです:
// Bolt が生成 — このコードは出荷しないこと
app.get('/api/users', async (req, res) => {
const { search } = req.query;
const result = await db.query(
`SELECT * FROM users WHERE name LIKE '%${search}%'`
);
res.json(result.rows);
});
どの開発者でもこれはすぐに見つけるでしょう。しかし、これらのツールのポイント全体は、非開発者でも使えるということです。これが危険です。
本当のセキュリティの問題
どちらのツールも脅威モデリングを実行しません。できません。なぜなら、あなたの脅威モデルを理解していないからです。彼らは動作するコードを生成します。敵対的な入力に対して安全なコードではなく。PII、金融データ、医療情報を処理するものを構築している場合、AI が生成するコードは本番環境に行く前に完全なセキュリティ監査が必要です。句点です。
内部のコード品質
こんなにいい事があってはいけません。両方のツールは単純なアプリケーション用に驚くほどまともなコードを生成します。複雑さが増すと問題が出現します。
Lovable のコード出力
Lovable の TypeScript 出力は本当に良いです。コンポーネントは構造化されており、型はほぼ正しく、shadcn/ui の使用により、アクセシブルで、よくテストされた UI プリミティブを取得します。モックデータは最初のビルドを完成した製品のように見せます。
しかし、複雑さが増すにつれて何が劣化するか:
- 状態管理が混沌としてくる。 Lovable は最初の数個のコンポーネントに対してプロップドリルする傾向があり、ツリーが深くなるとすぐに React コンテキストを導入します。パターンの混合が終わり、推論するのが難しくなります。
- コード分割がない。 すべてが1つのバンドルに入ります。プロトタイプ的には、誰が気にしますか？50+ ルートの本番環境では、初期読み込み時間が膨れ上がります。
- ロジックの重複。 1つのプロジェクトで同じデータ取得ロジックが 12 個のコンポーネント全体にコピーペーストされているのを見つけました。AI はリファクタリングしません。ただ追加するだけです。
- テストは存在しない。 ユニットテストなし、統合テストなし、e2e テストなし。ゼロです。
Bolt のコード出力
Bolt は React、Tailwind、Node.js を使用したポーランド式のフルスタック JavaScript を生成します。diffs ベースのアプローチは反復が速く、より対象になります。しかし:
- ファイル全体で矛盾するパターン。 1つのコンポーネントは async/await を使用し、次は
.then()チェーンを使用します。1つのファイルに適切なエラー処理があり、隣接するファイルには何もありません。 - プレビューとデプロイメントの信頼性はばらばら。 時々プレビューは完全に機能し、時々は壊れており、自分でコードを書いていないため、デバッグするのが難しいです。
- シンプルな機能の過度なエンジニアリング。 Bolt にコンタクトフォームを構築するよう依頼し、動的フィールド設定、検証スキーマジェネレータ、サブミッションキューを備えた完全なフォームビルダーを取得しました。クール、しかし必要なものではありませんでした。
コード品質の比較
| 側面 | Lovable | Bolt |
|---|---|---|
| 型安全性 | 強力 (TypeScript 全体) | 混合 (デフォルトは JS、TS オプション) |
| コンポーネントアーキテクチャ | 一貫性、デザインシステムに合わせて | 柔軟だが矛盾 |
| エラー処理 | 基本的なエラーバウンダリ、ギャップあり | ファイル全体で矛盾 |
| テスト | 生成なし | 生成なし |
| バンドル最適化 | 最小 | 最小 |
| アクセシビリティ | 良い (shadcn/ui) | 変数 |
| ドキュメント/コメント | 疎だが十分 | より詳細、時々誤解を招く |
スケーリングの境界: 何が壊れるのか
ここが誰もブログに書かない部分です。Lovable または Bolt のプロトタイプが実際にユーザーを取得するときに何が起こるか。
データベーススケーリング
Lovable は Supabase にロックされます。これは本質的に悪いわけではありません — Supabase はかなりの負荷を処理できます。しかし、AI が生成するデータベーススキーマには、適切なインデックス作成戦略がほぼ含まれていません。1,000 ユーザーで完全に機能し、10,000 ユーザーで這い始めた Lovable で生成されたアプリがありました。これはすべてのリストビューの ORDER BY で使用される created_at 列に頻繁にクエリされるテーブルにインデックスがなかったからです。
Bolt ではデータベースを選択できます。これは柔軟性のように聞こえますが、実際には AI が準最適なクエリを生成するためのより多くのルームがあります。Lovable の Supabase 規約に頼ることなく、Bolt が生成するデータベースコードはより素朴になる傾向があります。
フロントエンドのパフォーマンス（スケール時）
どちらのツールも、パフォーマンス予算を念頭に置いてアプリを生成しません。中程度の複雑なダッシュボードアプリ (ざっと 30 個のコンポーネント、8 個のルート) で測定したのは次の通りです:
| メトリック | Lovable | Bolt | カスタム Next.js |
|---|---|---|---|
| 初期バンドルサイズ | 487 KB | 523 KB | 142 KB |
| Lighthouse パフォーマンス | 62 | 58 | 94 |
| インタラクティブになるまでの時間 | 3.8秒 | 4.2秒 | 1.1秒 |
| 最大コンテンツフルペイント | 2.9秒 | 3.4秒 | 0.8秒 |
| コード分割 | なし | なし | ルートベース + 動的 |
| 画像最適化 | 基本 | なし | Next/Image with AVIF |
これらの数字は私たちの独自のテストからです。結果は異なります。しかし、パターンは一貫しています: AI が生成するアプリは、手で最適化されたものより 3-4 倍重いです。
Supabase の天井
これは独自の呼び出しを求めています。Lovable の緊密な Supabase 結合は、Supabase の制限を継承することを意味します:
- Edge Functions は 150 ミリ秒の冷たい開始を持っています — ほとんどの場合は問題ありませんが、リアルタイム機能の場合は痛いです
- 接続プーリング はプランレベルで制限されます — Pro プランは 50 の直接接続を提供します
- リアルタイムサブスクリプション は線形にスケーリングしません — Pro ティアで 500 個の同時接続を超えるとパフォーマンスの低下が見られました
- 複数のテーブル全体の複雑なトランザクションをサポート していません。適切なロールバックセマンティクス付き
アプリが Supabase から成長すると、Lovable で開始したかゼロから構築したかにかかわらず、重大な書き直しを見ています。
直接比較
| 機能 | Lovable | Bolt | カスタム Next.js |
|---|---|---|---|
| MVP までの時間 | 時間 | 時間 | 日から週 |
| フレームワーク | React + Vite のみ | React、Vue、Svelte、バニラ | Next.js (React) |
| バックエンド | Supabase (ロック済み) | 柔軟 (Bolt Cloud またはカスタム) | 任意 |
| 認証 | Supabase Auth (組み込み) | Bolt Cloud Auth またはカスタム | NextAuth、Clerk、カスタム |
| セキュリティベースライン | RLS ポリシー (監査が必要) | 最小限 (すべてが必要) | あなたが制御 |
| コードエクスポート | GitHub 同期 | 完全コードアクセス | 該当なし — あなたのもの |
| SSR/SSG | いいえ (クライアント側のみ) | 限定 | 完全サポート |
| SEO | 低い (SPA) | 低い (SPA) | 優秀 |
| スケール時のコスト | $25+/月 ツール + Supabase | $20+/月 ツール + インフラ | ホスティングのみ |
| ベンダーロックイン | 高い (Supabase) | 中程度 (Bolt Cloud) | 低い |
| 本番環境対応性 | 40% 達成 | 30% 達成 | あなたが決定 |
カスタム Next.js への移行時期
すべてのプロジェクトが移行する必要はありません。これについては明確にしたいです。10 人のチーム用に内部ツールを構築している場合、Lovable で生成されたアプリは無期限に機能するかもしれません。移行に関する会話は、特定の条件が現れ始めるときに始まります。
今すぐ移行すべき場合:
SEO が必要。 Bolt と Lovable は両方ともクライアント側で公開されるレンダリングされた SPA を生成します。有機的な検索トラフィックがビジネスにとって重要な場合、サーバーサイドレンダリングまたは静的生成が必要です。Next.js はこれをネイティブに処理します。これだけでもマーケティングサイト、ブログ、e コマース、およびコンテンツ駆動型アプリケーション向けの取引中止です。
機密データを処理している。 金融情報、医療記録、規模での PII — これらは AI ビルダーが提供できないセキュリティ保証が必要です。カスタムミドルウェア、適切な監査ログ、保存時の暗号化、およびあなたの特定のコンプライアンス要件を理解している人間によって見直されてきたセキュリティモデルが必要です。
パフォーマンスはビジネスメトリックです。 ページロード時間がビジネスに直接影響する場合 (e コマース — Amazon の有名な 100ms = 1% 収益の発見は今も成り立ちます)、3-4 秒の TTI を許可できません。
カスタムバックエンドロジックが必要。 Stripe との支払い処理が基本的なチェックアウトを超えている場合、ウェブフック処理、バックグラウンドジョブ、サードパーティ API オーケストレーション、複雑な認可 — これらのいずれも AI ビルダーではうまくサポートされていません。
チームが3人の開発者を超えて成長した。 テストなし、一貫性のあるパターンなし、ドキュメントなし AI が生成するコード — 複数の人がコードベースで作業する必要がある場合、責任になります。
AI ビルダーにとどまるべき場合:
- 依然として製品-市場適合を検証しています
- アプリは社内のみで、ユーザーベースが少ない
- チーム内に開発者がおらず、予算もない
- 反復速度はコード品質より重要
移行プレイブック
移行の決定がなされたら、それが従うプロセスです。これは「すべてを捨てて最初から始める」ではありません。無駄です。
ステップ 1: 既存コードベースを監査
Lovable (GitHub 同期経由) またはBolt (直接ダウンロード) からコードをエクスポートします。静的分析を実行します:
# インストールと分析ツール実行
npx eslint . --ext .ts,.tsx --report-unused-disable-directives
npx tsc --noEmit --strict
npx bundlesize
npx depcheck
探しているもの: 未使用の依存関係、飲み込まれた型エラー、セキュリティアンチパターン、デッドコード。
ステップ 2: 再利用可能なコンポーネントを特定
Lovable の shadcn/ui コンポーネントは通常、保持する価値があります。構造化されており、アクセシビリティガイドラインに従っています。Bolt のコンポーネントはより異なりますが、多くの場合、クリーンアップが必要な優れた UI ロジックがあります。
通常、フロントエンドコンポーネントの 30-50%、バックエンドロジックの 0-10% をサルベージします。
ステップ 3: Next.js 基盤を構築
// next.config.ts — 本番環境対応の開始点
import type { NextConfig } from 'next';
const config: NextConfig = {
reactStrictMode: true,
poweredByHeader: false,
images: {
formats: ['image/avif', 'image/webp'],
},
headers: async () => [
{
source: '/(.*)',
headers: [
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'X-Content-Type-Options', value: 'nosniff' },
{ key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
{
key: 'Content-Security-Policy',
value: "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline';",
},
],
},
],
};
export default config;
ここにあるものに注目: セキュリティヘッダー、画像最適化設定、厳密モード有効。これらは本番環境のテーブルステークスです。
ステップ 4: バックエンドを置き換え
Lovable/Supabase を使用していた場合、選択肢があります:
- Supabase を保持 しますが、適切なミドルウェア、カスタム RLS ポリシー、チームで見直された Edge 関数を追加します
- カスタムバックエンドに移行 します。Next.js API ルートまたは別のサービス (Node.js、Go、何でも合う) を使用します
- 異なる BaaS を採用 します。Firebase、Neon、PlanetScale など、データモデルに応じてです
すでに Supabase エコシステムに投資しているチームの場合、通常、Supabase を保持することをお勧めしますが、サーバー側検証を使用した適切なデータアクセスレイヤーでラップします。
ステップ 5: AI ビルダーがスキップするものを追加
- テスト: Jest + React Testing Library ユニット/統合用、Playwright e2e 用
- 監視: エラートラッキング用 Sentry、パフォーマンス用 Vercel Analytics または PostHog
- CI/CD: lint、型チェック、テスト、プレビューデプロイメント段階を備えた GitHub Actions
- 可観測性: 構造化ログ、ヘルスチェック、アップタイム監視
コスト分析: 構築 vs 再構築
お金について話しましょう。これはすべてのファウンダーが尋ねる質問です: 「Lovable/Bolt でそれをすでに構築しました。適切に行うのはどのくらい費用がかかりますか？」
| アプローチ | タイムライン | コスト範囲 | リスクレベル |
|---|---|---|---|
| Lovable/Bolt にとどまる (手動修正を追加) | 2-4 週 | $3,000-$8,000 | 高い (基礎にパッチを当てる) |
| Next.js への段階的移行 | 4-8 週 | $15,000-$40,000 | 中程度 |
| Next.js での完全な再構築 | 6-12 週 | $25,000-$75,000 | 低い (クリーンアーキテクチャ) |
| ハイブリッド (フロントエンドを保持、バックエンドを再構築) | 3-6 週 | $10,000-$30,000 | 中程度 |
これらの数字は過去1年にスコープしたプロジェクトに基づいています。マイレッジは複雑さに基づいて異なりますが、比率は成り立ちます。段階的な移行パス — 機能するものを保持し、機能しないものを段階的に置き換える — は通常、コストとリスクの最良のバランスです。
プロジェクトの具体的な情報をお望みですか? プライシングページ をご確認いただくか、直接お問い合わせください。
よくある質問
Lovable のコードは実際に本番環境対応ですか? 重要な手動レビューがない限り、いいえ。Lovable は、他の AI ビルダーよりも本番環境対応に近い、クリーンで構造化されたTypeScript コードを生成します — しかし、適切なセキュリティ硬化、テスト、パフォーマンス最適化、エッジケースのエラー処理がまだ不足しています。それを強い最初の下書きと考えてください。これは経験豊富な開発者のレビューが必要な、完成した製品ではありません。
Bolt.new は完全なスタックアプリケーションを構築できますか? はい、特に Bolt Cloud 2026 追加 (組み込みデータベース、認証、ストレージ、ホスティング) を使用します。Bolt は Lovable より多くのフレームワークの柔軟性を提供します — React、Vue、Svelte、またはバニラ JS を使用できます。ただし、その柔軟性はより少ないガードレールも意味し、生成されるバックエンドコードは Lovable の Supabase ベースの出力よりも慎重なセキュリティ監査が必要です。
Lovable から Next.js への移行にはいくらかかりますか? 5-10 個のコア機能を持つ標準的な MVP の場合、4-8 週間にわたって段階的な移行で $15,000-$40,000 を予想します。完全な再構築は複雑さに応じて $25,000-$75,000 を実行します。良いニュースは、Lovable のフロントエンドコンポーネントの 30-50% が通常、ゼロから開始することと比較してコストとタイムラインの両方を削減できるという点です。
Lovable でセキュリティの問題を修正して、使い続けることができますか? シンプルなアプリの場合はできます。しかし、Lovable のアーキテクチャには基本的な制約があります。パッチ当ては対処できません: クライアント側のみのレンダリング (SEO 用 SSR なし)、Supabase にロック、コード分割なし、組み込みテストインフラなし。ニーズがこれらのウォールにぶつかっても、セキュリティ問題を修正し、Lovable にとどまることは完全に有効な戦略です。
Bolt または Lovable は SaaS プロトタイプに適していますか? Lovable が SaaS プロトタイプでわずかに先行しています。Supabase 統合により、すぐに auth、データベース、RLS ポリシーが得られるからです。Bolt より速く動作中のアプリとユーザーアカウントが得られます。ただし、React 以外のフレームワークが必要な場合、または Supabase 以外のバックエンドが必要な場合、Bolt の柔軟性は、より多くの設定を必要とするにもかかわらず、より良い選択を行います。
AI が生成するコードの最大のセキュリティリスクは何ですか? 一貫して見られる上位のリスク: クライアント側バンドルにハードコードされた API キーとシークレット、エッジケース (無効化されたユーザーがアクセスを保持するなど) を見落とす不完全な Row Level Security ポリシー、API エンドポイントの欠落レート制限、raw クエリでの SQL インジェクション、過度に許容的な CORS 設定、localStorage に保存された認証トークン (httpOnly クッキーではなく)。これらはどれも修正不可能ではありませんが、探すことを知る必要があります。
AI ビルダーから移行してはいけない場合はいつですか? 製品-市場適合をまだ検証しており、アプリが 50 人未満のユーザーの社内のみ、チーム内に開発者がいない、または移行のコストがアプリのビジネス価値を超える場合は、とどまります。最悪のことは、その市場をまだ見つけていない製品を再構築することです。
Next.js の代わりに Astro を使用できますか? 絶対に。アプリケーションがコンテンツが多く、クライアント側のインタラクティビティが最小限である場合 — マーケティングサイト、ドキュメント、ブログ、またはコンテンツプラットフォーム — Astro は多くの場合、Next.js より適しています。Astro のアイランドアーキテクチャはデフォルトでゼロ JavaScript を出荷し、インタラクティブコンポーネントのみをハイドレイトします。これは、コンテンツ焦点サイトの Next.js さえより良いパフォーマンスを提供します。コンテンツ駆動型アプリの Lovable から Astro への複数の移行を行っています。これはこのユースケースのためです。