Lovable Cloud のデメリットは何ですか？

Lovable Cloud は「1 Lovable プロジェクト = 1 Cloud DB」の紐付き設計のため、フロントエンドを別プロジェクトに切り出すとデータが分断されます。リージョン選択の概念がそもそも存在せず、日本ユーザー向け最適化ができません。また、別プロジェクトへの移行時には Claude Code 等で全テーブルの SELECT / INSERT スクリプトを手作業で書く必要があり、exit cost が高くなります。本格事業化を目指す経営者は独自 Supabase 構成に剥がすことを BANSOU CTO™ では推奨しています。

Lovable AI と直接 API はどちらが良いですか？

用途で使い分けるのが最適です。Lovable AI は内蔵モデルを高頻度で切り替える Gateway 設計のため、立ち上げ初期や一般的なサービス開発では Claude Code（Claude 固定）より柔軟で効率的です。一方、医療データ・採用 PII・契約書類などの機密データを扱う場合や、OpenAI gpt-image-2 / Google Gemini 3.1 pro 等のプロバイダ固有モデルを指名したい場合は、Customer Data 訓練ライセンスの問題もあり、直接 API への切替が必要です。

Lovable hosting から Cloudflare Workers に移行するメリットは？

TTFB が約 13 倍改善します（実測：oshushidayo で 2,170ms → 164ms）。Lovable hosting は HTML を edge-cache しない構造で日本から RTT 約 1,260ms、さらに /~api/analytics の強制注入が initial paint を 2.71 秒ブロックします。Cloudflare Workers に移行すると両方解消され、Lighthouse Performance スコアが 50 点台から 90 点台へ。加えて Resend 等の外部サービス連携の DNS 設定も自動化される副次効果があります。

Lovable から Cloudflare Workers への移行にどれくらい時間がかかりますか？

AI 駆動開発の時代では、小規模プロダクトなら 30〜60 分、1,000 ファイル超の大規模プロダクトでも数時間で完走します。手順は 6 ステップ：TanStack Start ベースの Lovable プロジェクト作成、Cloudflare Workers プロジェクト作成と GitHub 連携、Build configuration 設定、Supabase 接続情報および Node 関連の環境変数を標準セットで設定、Custom domain 接続、動作確認。BANSOU CTO™ スタンダードプランでは実装まで伴走します。

Lovable は今でも ChatGPT ベースですか？

Lovable は 2023 年に Anton Osika 氏らが立ち上げた OSS プロジェクト「GPT Engineer」（GitHub 50,000 stars）から派生した商用版です。Cloudflare の Workers ビルド画面で commit が gpt-engineer-app[bot] と表示されるのはその名残ですが、現在の Lovable AI は内部で Anthropic Claude・OpenAI・Google など複数プロバイダのモデルを動的に切り替える Gateway 設計で、特定プロバイダ依存ではありません。

独自 Supabase で複数の Lovable プロジェクトを共有できますか？

可能です。私は REMILA.SITE と resusty.co.jp という別 Lovable プロジェクトのフロントエンドから、同一の独自 Supabase プロジェクトに接続して運営しています。MeishiX（単発販売版）と saku meishi（saku.cloud モジュール版）も同じ DB スキーマを共有し、Phase 数を 85 から 66 に削減できました。マルチブランド・マルチプロダクト展開には独自 Supabase が事業戦略レベルで必須です。

BANSOU CTO™ は他の外部 CTO サービスと何が違いますか？

BANSOU CTO™ は助言だけでなく実装まで踏み込む伴走型フラクショナル CTO です。Lovable Top 1% の AI 駆動開発スキルで、Lovable の『All-in-One の罠』を回避する 3 層剥がし（AI 層・DB 層・配信層）を実装まで一気通貫で支援。スターター 50 万円（助言）/ スタンダード 100 万円（戦略 + 実装）/ フルコミット 200 万円（事業成長の右腕）の 3 プラン。正社員 CTO 採用と異なり、即日スタート可能・採用リスクなしです。

Lovable Cloudの罠とCloudflare Workers移行 ── 一人社長の3層剥がし実践記録

— Lovable は素晴らしい。だから純正で固める罠が見えにくい。 —

同じ Supabase に2つのフロントエンドが刺さっている話から始めます

私は今、Lovable で 2 つのプロダクトを並行運営しています。

ひとつは REMILA.SITE。美容業界の店舗運営者向けに、匿名フィードバックとシフト改善を支援するシステムです。もうひとつは resusty.co.jp。私が代表を務める株式会社リサスティーの公式サイト。

このふたつ、何がつながっているのか。バックエンドの Supabase が同じプロジェクトなんです。フロントエンドは完全に別の Lovable プロジェクトとして開発・運用されていますが、ユーザーデータベース・認証基盤・コンテンツ管理は同一の Supabase インスタンスに集約されている。

これは Lovable Cloud では絶対に作れない構成です。なぜなら Lovable Cloud のデータベースは「Lovable プロジェクトに紐付いた」設計だから。フロントエンドだけ別プロジェクトに切り出した瞬間、Cloud DB も新規発行されて、データは完全に分断されます。「フロントだけ変えたい」という普通のニーズに対して、データを諦めるか、フロントを諦めるか、の二択になる。

私は最初から 独自 Supabase + 独自 AI API + Cloudflare Workers ホスティング で構築しているので、フロントを増やしたい・別ブランドを立ち上げたい・別 LP を試したい時に、データを共有したまま自由に増殖できます。これは Lovable の純正機能だけでは到達できない領域です。

整理しておきます。本記事で「Lovable All-in-One」と呼ぶのは、Lovable AI（推論）・Lovable Cloud（DB）・Lovable hosting（配信）を Lovable 純正のみで構成するアーキテクチャのことです。これに対する私の現在の構成は 直接 AI API（用途別）・独自 Supabase・Cloudflare Workers SSR の 3 層自前構成で、私はこれを「3 層剥がし」と呼んでいます。

そして 2026-05-14、Lovable が公式に SSR / SEO-AEO 機能を発表しました（lovable.dev/seo-aeo）。新規アプリ向けの TanStack Start ベース SSR、既存アプリ向けのプリレンダリング、Semrush 統合まで。Lovable はすでに 800万ユーザー・ARR $400M（TechCrunch 2026-03 報道）に達した、AI 駆動開発ツールの世界的勝者です。

その公式発表の 9 日前 に、私は同じ構成を /new-product パイプラインで自動生成し、Cloudflare Workers へ移行して TTFB 2,170ms → 164ms（13倍改善）を実測していました。続けて合計 6 プロダクトを連続移行。Lovable 公式 SSR が来た今こそ、その先の構造優位を発信すべきタイミングだと判断したので、この記事を書いています。

Lovable は素晴らしい。だから "純正で固める" 罠が見えにくい

最初に明確にしておきます。私は Lovable のヘビーユーザーであり、強い肯定派です。

公開されている統計値では、Lovable 内で「National Treasure」称号を持つ日本人ユーザー上位 1% に入っています。AI 支援で生成したコード行数は累計 700 万行以上。従来の人月単価 80 万円で換算すると、エンジニア 1 人が 26 年かけて書く工数を、私は 4 ヶ月で実現しています。これは Lovable 抜きでは絶対に到達できなかった生産性です。

Lovable AI も素晴らしい設計です。Anthropic の Claude Code が「原則 Claude」で固定されているのに対し、Lovable AI Gateway は内蔵モデルを高頻度で切り替えながら最適な応答を返してくれます。 立ち上げ初期、何を作るか手探りの段階では、この「賢いモデルがいい感じに選ばれる」UX は圧倒的に効きます。

ちなみに余談ですが、Lovable は 2023 年に Anton Osika 氏らがオープンソースで公開した「GPT Engineer」（GitHub 50,000 stars）から派生した商用版です。だから、Cloudflare の Workers ビルド画面を覗くと、Lovable からの自動 commit が gpt-engineer-app[bot] という名前で表示されます。これを見て「Lovable は OpenAI / ChatGPT 専用なのか？」と思う方もいますが、それは違います。これは前身プロジェクトの命名がそのまま残っているだけで、Lovable AI 自体は内部で Anthropic Claude・OpenAI・Google など複数プロバイダのモデルを動的に切り替える Gateway 設計です。Lovable の出自を知っていると、こういう細部に納得感が出てきます。

Lovable Cloud も初期立ち上げには優秀です。Supabase の知識ゼロでも DB が立ち上がり、認証・ストレージ・Edge Function まで Lovable Chat の中で完結します。最初の MVP を 3 日で出す、デモを取引先に見せる、そういう「速度命の局面」では Lovable 純正で固める方が早い。

ホスティングもそうです。Lovable Pro プラン（25 ドル / 課金サイクル）には hosting と AI 利用枠が含まれていて、小規模なら追加コストゼロでデプロイ可能。独自ドメインも Pro プラン以上で接続できます。「立ち上げ期の数十営業日、25 ドルで AI 駆動開発を試す」というスタートアップとしては、これ以上ない選択肢でしょう。

問題は、Lovable で成功した経営者が、そのまま Lovable 純正で固めて「本番事業化」する瞬間に発生します。

立ち上げ速度を上げるための All-in-One が、事業が伸びるほど自由を奪う構造に反転する。Lovable AI のメリットだった「賢いモデルがいい感じに選ばれる」は、特定モデルを指名したい場面では制約になる。Lovable Cloud のメリットだった「DB が自動で立ち上がる」は、フロントを増やしたい・別プロジェクトに移したい場面で exit cost を爆発させる。Lovable hosting のメリットだった「設定なしで動く」は、日本ユーザー向けに最適化したい場面で TTFB の壁になる。

これが私が「All-in-One の罠」と呼んでいる現象です。罠だと気づくのは、Lovable で軌道に乗ってからしばらく経った後。気づいた時には、Lovable の各レイヤーが事業の隅々まで結合していて、剥がすコストが高い。

幸い、AI 駆動開発の時代では「剥がす」も時間単位で完了します。 私が 6 プロダクトを Cloudflare Workers に連続移行したのも、1 プロダクトあたり 30 分〜数時間の作業でした。剥がすべきレイヤーを正しく見極めれば、Lovable のメリットを享受しながら、本番事業に必要な構造優位だけを取り戻せます。

この記事では、私が実際に剥がした AI 層・DB 層・配信層の 3 層 について、それぞれの罠と剥がし方を一次体験ベースで書きます。

第1の罠 ── Lovable AI のモデル制限と Customer Data 訓練ライセンス

Lovable AI の良さは「賢いモデルが自動選択される」こと

繰り返しますが、Lovable AI Gateway の動的モデル選択は素晴らしい設計です。プロンプトに応じて、Anthropic Claude 系・OpenAI 系・Google 系・オープンソース系を裏で切り替えて、最適な応答を返してくれる。私が観察している限り、この切替頻度は Lovable 側で継続的にチューニングされていて、新しいモデルが出るたびに自動で恩恵を受けられます。

Claude Code は「原則 Claude」で固定されているので、ここは Lovable の方が柔軟です。「どのモデルを使うか考えたくない」という経営者・初心者にとって、Lovable AI の動的選択は最高の UX でしょう。

でも「これ使いたいのに」という瞬間が来る

問題は、特定のモデルを指名したくなる瞬間です。

私の場合、画像生成では OpenAI gpt-image-2 を使いたい場面があります。LINE スタンプ生成・ブランドキャラクターの後段合成・プレゼン用スライドの背景画像生成、いずれも gpt-image-2 でしか出ない品質があります。

長文推論では Anthropic Claude Opus 4.7（1M context）を指名したい。設計書 15 ファイル分の整合性をまとめて検証する、補助金申請書全体を一度に読んで矛盾を検出する、こういう「大量コンテキスト × 高品質推論」の場面では他で代替できません。

Google Gemini 3.1 pro も特定の用途で必要です。Google Search との統合、長文 PDF の処理、医療系・法律系の専門領域に強いモデル特性。プロバイダ固有の最新世代モデルが選びたいのに、Lovable AI Gateway 経由ではそれが選べないケースがある。

Customer Data 訓練ライセンスという見えない罠

もうひとつ、見落とされがちな問題があります。Lovable AI Gateway 経由で送信されたデータは、Lovable のサービス向上のためにモデル訓練に利用される可能性がある利用規約になっています。これは Lovable AI に限らず、多くの AI Gateway 系サービスに共通する設計思想です。

通常のサービス開発なら問題ありません。しかし、医療データ・採用 PII（個人識別情報）・契約書類・補助金申請書類などの「絶対に訓練対象にしたくないデータ」を扱う場面では、Lovable AI Gateway は使えなくなるんです。

私が SeitaiYoyaku（整体院向け施術記録システム）で施術音声の文字起こし機能を実装した時、まさにこの判断が発生しました。施術音声には患者の身体状態・既往症・施術内容が含まれます。これは医療データに準じる扱いが必要で、Lovable AI Gateway 経由では Customer Data 訓練ライセンスがリスクになる。

結論として、2026-05-14 の判断で、施術音声文字起こしは Lovable AI から直接 Google Gemini API へ切替 しました。Gemini API には Google 公式の「データを訓練に使用しない」契約条項があり、医療データを安全に扱える設計になっています。同じことが採用 PII（履歴書・職務経歴書）や契約書類でも言えます。

追加の囲い込み証拠：Secrets タブで API キーが見えない

Lovable Cloud と組み合わせた Lovable AI 経由の構成では、Lovable Dashboard の Cloud → Secrets タブを開いても、表示される API キーは LOVABLE_API_KEY のみです。Supabase の publishable key も、内蔵 AI の API キーも、ユーザー側からは見えない設計になっています。

これは Cloudflare Workers 等への移行時に大きな摩擦になります。Workers のビルド環境変数に VITE_SUPABASE_PUBLISHABLE_KEY を設定する必要があるのに、Lovable Dashboard ではその値が確認できない。私の場合、Supabase Dashboard で該当プロジェクトを直接開いて値を取得するか、Lovable Chat に「client.ts を環境変数依存からハードコード方式に変更してください」と依頼するか、二択を強いられました。

AI 層の剥がし方

私の現在のスタックは、用途別にプロバイダを使い分ける構成です。

用途	採用 AI
通常のサービス開発・UI 生成・大半のコーディング	Lovable AI（メリット最大化）
長文推論・設計書整合性・補助金申請書	Anthropic Claude Opus 4.7（1M context）直接 API
画像生成（スライド・LINEスタンプ・ブランドキャラ）	OpenAI gpt-image-2 直接 API
医療データ・採用 PII・契約書類の処理	Google Gemini 3.1 pro 直接 API
Google Search 統合・PDF 処理	Google Gemini 3.1 pro 直接 API
コードレビュー・並列レビュー	Codex + Gemini + Claude の 3 AI 並列

「Lovable AI を捨てる」のではなく、「Lovable AI を活かしつつ、特定モデルが必要な場面では直接 API を併走させる」設計です。これにより Lovable AI の動的最適化のメリットを享受しながら、Customer Data 訓練ライセンス問題やモデル指名の自由度問題を回避できます。

第2の罠 ── Lovable Cloud は "プロジェクトに紐付いた DB"

1 プロジェクト = 1 DB の構造的制約

冒頭で書いた REMILA.SITE × resusty.co.jp の話に戻ります。

Lovable Cloud は「1 Lovable プロジェクト = 1 Cloud DB」という設計思想で作られています。Lovable Chat で新しいプロジェクトを始めると、自動的に新しい Cloud DB が割り当てられて、その DB はそのプロジェクト専用になる。これは初期立ち上げの摩擦を最小化する優れた設計です。Supabase の知識ゼロでも DB が動く、認証が動く、ストレージが動く。

でも、事業が伸びてくると、この構造が縛りになります。

私のケースでいえば、REMILA というプロダクトを最初に立ち上げました。美容業界のクライアント向けに、店舗運営の課題を AI で支援するシステム。これがある程度形になった時、「同じユーザーデータベース上に、別のフロントエンドを立てたい」というニーズが生まれました。具体的には、株式会社リサスティーのコーポレートサイト（resusty.co.jp）です。両者は別プロダクト・別 LP・別 SEO 設計ですが、ユーザー登録・問い合わせ管理・コンテンツ管理は一元化したい。

独自 Supabase なら、これは 5 分で実現できます。同じ Supabase プロジェクトの URL と publishable key を、別の Lovable プロジェクトの環境変数に設定するだけ。両プロダクトが同じ DB を共有して動き始めます。

Lovable Cloud では、これが構造的に不可能です。新しい Lovable プロジェクトを作ると、新しい Cloud DB が割り当てられる。両プロジェクトのデータを共有したければ、片方の DB のデータをもう片方の DB に「移行」する必要があり、しかも常に同期し続ける仕組みを自前で構築する必要がある。これは現実的な選択肢ではありません。

リージョン選択の概念が存在しない

もうひとつ、見落とされがちな問題があります。Lovable Cloud には「リージョン選択」の概念がそもそも存在しません。

独自 Supabase なら、プロジェクト作成時に Tokyo（ap-northeast-1）・Singapore・Frankfurt・Virginia など世界各地のリージョンから自由に選べます。日本ユーザー向けのサービスなら当然 Tokyo を選ぶことで、DB レスポンスタイムを最小化できます。

Lovable Cloud では、この選択肢が UI に存在しない。デフォルトで割り当てられたリージョンに紐付くしかなく、後から変更もできません。

リージョンが事業に与える影響は想像以上に大きいです。私が運営する CONISA というプロダクトは、もともと Supabase Mumbai リージョンに置かれていました。これを Tokyo リージョンに移行した時の実測値は以下の通りです。

指標	Before（Mumbai）	After（Tokyo）	倍率
ログイン → Dashboard 表示	8 秒	2 秒	4 倍改善
Lighthouse Performance スコア	50	80+	30 ポイント上昇
RTT（往復遅延）	200-400ms	20-50ms	10 倍改善

これは独自 Supabase だからこそできた最適化です。Lovable Cloud で同じデータベースを運営していたら、リージョン選択肢がないため、永遠に Mumbai か他の遠隔リージョンに置かれたままでした。

exit cost の現実 ── Claude Code に泥臭い作業を強いられる

「でも、Lovable Cloud から独自 Supabase に後から移行すればいいのでは？」という反論を受けることがあります。技術的には可能です。しかし、実務的には exit cost が非常に高い。

具体的に何が起きるか。Lovable Cloud には標準的な PostgreSQL バックアップ・移行ツールが提供されていません。supabase db dump でスキーマとデータを export して、新しい Supabase プロジェクトに pg_restore で流し込む、というクリーンな手順が使えない。

結果として、私が見聞きする実務では、Claude Code 等の AI コーディングツールに「Lovable Cloud の各テーブルから SELECT * を出して、INSERT 文として組み立て直して、外部キー依存を解いて、ID マッピングを保持しながら新しい Supabase に流し込んでください」と泥臭い作業を全テーブル分依頼することになります。

これを「囲い込みじゃない」と言うのは、ただの楽観主義だと私は思います。技術的に移行可能であることと、移行コストがゼロであることは、別物です。

マルチプロダクト展開を支える独自 Supabase

私が運営している MeishiX（単発販売版の名刺管理 SaaS）と saku meishi（saku.cloud プラットフォーム内のモジュール版）は、最初から独自 Supabase の共有 DB 設計で開発しています。

両者はターゲット顧客が違います。MeishiX は「単発で買い切りたい中小企業」向け、saku meishi は「saku.cloud の他モジュールと組み合わせたい中堅企業」向け。フロントエンドの UI・課金フロー・機能セットは大きく異なります。

でも、バックエンドの DB スキーマは同じ。customers テーブル・app_role ENUM・plan_type ENUM 等を共有して、ALTER で各製品ラインに必要なカラムを追加していく構造です。これにより、Phase 数（実装計画上の作業単位）を 85 → 66 に削減できました。19 Phase 分の重複実装を回避できた計算です。

独自 Supabase の真の価値は、単に「移行できる」「リージョンが選べる」だけではありません。マルチプロダクト・マルチブランド展開を低コストで成立させる、事業戦略レベルの構造優位を提供することです。一人社長が複数の製品ライン・複数のブランドを並行運営できているのは、独自 Supabase の共有 DB 設計があるからです。

DB 層の剥がし方

3 つの実装パターンを段階的に紹介します。

パターン A: 新規プロダクトは最初から独自 Supabase で始める

これが exit cost ゼロを保証する唯一の方法です。Supabase Dashboard で新規プロジェクトを Tokyo リージョンで作成し、Lovable Chat に「このプロジェクトを独自 Supabase に接続してください。URL と publishable key を環境変数で渡します」と指示する。これだけで、最初から独自構成での開発が始まります。

パターン B: 既存 Lovable Cloud プロダクトを独自 Supabase に移行する

これは exit cost が発生するパターンです。新しい独自 Supabase プロジェクトを Tokyo で作成し、Lovable Cloud のスキーマを手動でコピー、データを INSERT スクリプトで移行、Lovable プロジェクトの接続先を切替、テスト、本番切替。AI 駆動開発なら数時間で完走できますが、スキーマ複雑度・データ量によって 1 セッションで足りない場合は分割実施になります。

パターン C: マルチプロダクト共有 DB 設計を最初から組み込む

最初の独自 Supabase プロジェクトを「ブランド・製品ライン横断のマスター DB」として設計します。各プロダクトの個別カラムは ALTER で追加していくスキーマ拡張戦略を採ります。これにより、2 つ目・3 つ目のプロダクトを立ち上げる時の DB 設計コストがゼロになります。Vibe Coding と呼ばれるこの AI 駆動開発手法の詳細は、株式会社IIWAYO.TECH ブログで関連記事を順次公開予定です。

第3の罠 ── Lovable hosting の TTFB 1,260ms と `/~api/analytics` 強制注入

日本ユーザー向けサービスの構造的な遅さ

Lovable hosting には、日本ユーザー向けサービスを運営する上で、構造的な遅さがあります。これは私の推測ではなく、Lovable AI Support が公式に回答した内容です。

"the HTML for deep links is intentionally not edge-cached on Lovable Cloud, so each request goes to origin. From a Cloudflare edge in Europe I see this respond in around 200ms, which suggests the 1.26s you're measuring is the regional round trip from a Japanese edge to our origin."

要約すると、Lovable Cloud は HTML を 意図的に edge-cache していない 設計で、全リクエストが origin サーバーに到達します。欧州の Cloudflare edge からは 200ms 程度で応答が返ってきますが、日本の edge から Lovable origin への RTT は約 1,260ms かかります。

これは「Lovable のチューニングが甘い」ではなく、「日本ユーザー向け SaaS には Lovable hosting は構造的に向かない」という公式回答です。

`/~api/analytics` 強制注入で initial paint が 2.71 秒ブロックされる

もうひとつ、Lovable Cloud 公開サイトには /~api/analytics という first-party analytics の POST リクエストが強制注入されます。これも Lovable AI Support の公式回答で:

"On /~api/analytics: yes, that's a first-party analytics call that Lovable Cloud injects into published sites. It is not something you can disable from the project today."

要約: Lovable Cloud が公開サイトに自動注入する first-party analytics call で、プロジェクト側から無効化できない。

これが何の問題かというと、initial paint をブロックしているんです。oshushidayo を実測した時、/~api/analytics のリクエストが完了するまでに 2.71 秒かかっていて、その間ユーザーの画面は真っ白でした。

Cloudflare Workers に移行すると、この /~api/analytics 強制注入が完全に消滅します。代わりに Cloudflare 標準の RUM（Real User Monitoring）が 9ms で完了するため、initial paint がブロックされません。

実測値 ── TTFB 13 倍改善

ここまでが「なぜ移行するか」の構造説明。次に「移行したら何がどう変わったか」の実測値を出します。

oshushidayo（おしゅしだよ公式ポータル + デザフェス2026・2026-05-05 Lovable で立ち上げ）を、5/06 に Cloudflare Workers へ移行した時の比較データ:

指標	Lovable hosting	Cloudflare Workers	倍率
TTFB（document）	2,170 ms	164 ms	13.2 倍改善
Load 完了	2,290 ms	478 ms	4.8 倍改善
Finish	5,300 ms	628 ms	8.4 倍改善
`/~api/analytics` ブロッキング	2,710 ms	0 ms（消滅）	排除完了

TTFB が 13 倍改善した瞬間、ユーザー体験が別物になります。「ボタンを押してから 2 秒待つサイト」と「ボタンを押した瞬間に反応するサイト」では、コンバージョン率も離脱率も全く違う。これは SEO スコアにも直結します。Lighthouse Performance スコアは Lovable hosting の 50 点台から Cloudflare Workers の 90 点台まで上がりました。

これを 1 プロダクトだけでなく、合計 6 プロダクト で連続移行しています。oshushidayo / SeitaiYoyaku / iiwayotech / conisa-supabase / mgs-supabase / remilasite。それぞれ規模も技術スタックも違いますが、構造的な改善はすべて再現されました。

Cloudflare に剥がす副次的メリット ── Resend ドメイン設定が劇的に楽になる

TTFB 改善だけが Cloudflare に剥がすメリットではありません。DNS を Cloudflare に向けることで、他のサービス連携が劇的に簡単になるという副次的な恩恵があります。

私が一番強く実感したのは、Resend（トランザクションメール送信サービス）のドメイン認証設定です。

通常、Resend で自社ドメインからメール送信できるようにするには、SPF・DKIM・DMARC・MX 等の DNS レコードを 5〜10 件、ドメイン管理サービス（お名前.com 等）の管理画面で手動入力する必要があります。レコードの値は長い文字列で、誤字 1 文字でメール送信が失敗する。深夜にこの作業をやって、翌朝「メール届きません」とクライアントから連絡が来て初めて気づく、という事故が起きやすい工程です。

ところが、ドメインを Cloudflare DNS に向けていると、Resend に「このドメインで送信したい」と指定するだけで、Cloudflare が API 経由で必要な DNS レコードを全件自動設定してくれます。手作業の DNS 入力が完全に消える。

Lovable Chat からも Resend の連携設定は便利に行えます。ただし、Lovable から Resend に連携指示しても、Resend 側で実施する必要があるドメイン認証の DNS 設定は別途自分で行う必要があります。お名前.com で手動か、Cloudflare DNS で自動か、ここで分岐します。

このメリットは Resend に限りません。Stripe・Postmark・Mailgun・SendGrid・Google Workspace・Microsoft 365 など、ドメイン認証が必要なサービス連携すべてで Cloudflare DNS の優位性が効いてきます。「Cloudflare に DNS を移しただけで、外部サービス連携が全部楽になった」というのが、実務で剥がしてみた経営者の率直な感想です。

Lovable hosting の本質的な役割

ここで誤解を防ぐために書いておきます。私は Lovable hosting を否定しているわけではありません。

Lovable hosting の真の役割は、「開発フェーズでの即時プレビュー」だと私は理解しています。Lovable Chat でコードを生成 → push → 即時 deploy → ブラウザで確認 → フィードバックして再生成。このループを止めずに回せることが Lovable の最大の価値で、ここに hosting が組み込まれていることで AI 駆動開発の速度が成立しています。

本番事業化の段階で、Lovable hosting を Cloudflare Workers に剥がすことは、Lovable の AI 駆動開発フローと矛盾しません。Lovable Chat → push → GitHub → Cloudflare Workers の自動 build → 即時 deploy という流れは、移行後もそのまま維持されます。

つまり、Lovable hosting は開発時のプレビュー用途として残し、本番配信は Cloudflare Workers に剥がす、というハイブリッド構成が現実的です。これは私が IIWAYO.TECH の標準フレームワークとして 2026-05-10 に正式文書化した運用方針でもあります。

配信層の剥がし方

実装手順は別記事で詳述する予定ですが、ここでは概略だけ。

Lovable プロジェクトを TanStack Start ベースで作成（Lovable AI の新規プロジェクトは 2026 年 5 月からデフォルトで TanStack Start）
Cloudflare ダッシュボードで Workers プロジェクトを作成、GitHub リポジトリと連携
Build configuration を設定（bun install --no-frozen-lockfile && npm run build）
Environment variables を設定（VITE_SUPABASE_URL / VITE_SUPABASE_PUBLISHABLE_KEY / VITE_SUPABASE_PROJECT_ID / SUPABASE_URL / SUPABASE_PUBLISHABLE_KEY / NODE_VERSION=22、規模次第で NODE_OPTIONS=--max-old-space-size=8192）。SUPABASE_SERVICE_ROLE_KEY 等のサーバ秘密鍵は絶対に入れない
Custom domain を接続（wrangler.jsonc の routes 設定が確実）
動作確認後、Lovable 側の custom domain を外す

中規模以上のプロダクトでは追加で NODE_OPTIONS=--max-old-space-size=8192 の設定や、Workers Paid プラン（月 5 ドル・Worker 10MiB 制限解除）への切替が必要なケースもあります。oshushidayo のような小規模プロダクトなら 30〜60 分、remilasite のような 1,000 ファイル超のプロダクトでも数時間で完走できます。

3 層剥がしの実装ロードマップ ── AI 駆動開発で時間単位の作業

ここまで読んで、「3 層全部剥がすのは大変そう」と感じる経営者もいるかもしれません。実際は、AI 駆動開発の時代では 3 層全部剥がしても、合計で数時間〜1 営業日で完走 します。私の経験では、適切に Phase を切ればさらに圧縮できます。

推奨される実装順序

Phase 1: 配信層の剥がし（即効性最大）

最初に剥がすべきは配信層です。理由は、TTFB 改善の体感が圧倒的で、しかも DB / AI 層に手を入れなくても完結するから。oshushidayo の例なら 30〜60 分で完了します。Lovable Chat → push → Cloudflare Workers の自動 build という開発フローも維持されるので、その後の開発速度が落ちません。同時に Resend 等の外部サービス連携も Cloudflare DNS 経由で楽になるという副次効果も得られます。

Phase 2: DB 層の剥がし（事業戦略への投資）

次に DB 層。Lovable Cloud を使っていたプロダクトなら、新規 Supabase プロジェクトを Tokyo リージョンで作成し、スキーマとデータを移行します。AI 駆動開発なら数時間で完走。マルチプロダクト展開を予定しているなら、この段階で共有 DB 設計を組み込むのが効率的です。

Phase 3: AI 層の剥がし（用途別最適化）

最後に AI 層。これは「全部剥がす」のではなく、「用途別に剥がす」のがポイントです。通常のサービス開発は Lovable AI のまま、医療データや採用 PII は直接 API、画像生成は gpt-image-2 直接、長文推論は Claude Opus 直接、という使い分け。実装としては、各機能のロジック側で AI プロバイダを切替えるだけなので、1 プロバイダにつき 1〜2 時間で組み込めます。

コスト感覚

経営者として気になるコストの見通しを書いておきます。

Lovable 関連コスト

Pro プラン: 25 ドル / 課金サイクル（hosting + AI 利用枠込み）
大規模利用なら Business プランや Enterprise も検討

Cloudflare 関連コスト

Workers Paid プラン: 5 ドル / 課金サイクル（Worker 10MiB 制限解除）
独自ドメイン: 年 1,000〜3,000 円程度（.com で 12-15 ドル / 年）
1,000 万リクエスト / 課金サイクルまでは追加コストなし

Supabase 関連コスト

Free Tier: 0 円（500MB DB・50,000 MAU まで）
Pro Tier: 25 ドル / 課金サイクル（プロダクション利用が現実的になる規模）

AI API 関連コスト（直接利用分）

Anthropic Claude Opus 4.7: 入力 15 ドル / 1M tokens 程度
OpenAI gpt-image-2: 画像 1 枚あたり 0.04 ドル前後
Google Gemini 3.1 pro: 競争力ある価格設定

「Lovable 純正 vs 剥がし構成」のコスト比較は、事業規模と利用パターンによって逆転点が変わります。数万 PV 規模なら Lovable 純正の方が安いケースもありますし、数十万 PV 以上なら剥がし構成の方が経済的にも有利になります。重要なのはコスト最適化だけではなく、事業の自由度・移行可能性・拡張性を持つことだと私は考えています。

なぜ "入口で止まる" 経営者が多いのか

ここで一度、視点を引き上げます。

私が 2025 年から発信し続けているコアメッセージは、「AI セミナーは入口。でも入口で止まっている会社が多すぎる」 です。AI セミナーに参加して、ChatGPT や Claude の使い方を学んで、社内で勉強会を開いて……というところまでは多くの会社が到達します。

問題は、その先です。「勉強した内容を、実際に会社の仕組みに落とし込む」段階で 9 割の会社が止まる。AI で議事録を書く・メール下書きを作る・コードを生成する、までは進んでも、AI が会社の業務プロセス全体を再設計するレベルには到達できない。

Lovable も、まったく同じ構造で "入口" の罠を内包しています。

Lovable で MVP を作れた経営者は、ある意味で「AI セミナーの入口」を超えて、実装まで進んだ人たちです。これは素晴らしい第一歩。でも、その勢いで Lovable 純正の All-in-One で固めて本番事業化してしまうと、今度は「Lovable で立ち上げる」という新しい入口で止まってしまう。

事業が伸びると、必ず以下のニーズが生まれます。

別フロントエンドを立てたい（マルチブランド・別 LP・A/B テスト用）
既存ユーザーデータを共有したい（複数製品ラインの統合管理）
日本リージョンで高速化したい（ユーザー体験の競争力）
特定の AI モデルを指名したい（品質・コスト・セキュリティ要件）
データを訓練対象にしたくない（医療・採用・契約等の機密データ）
ホスティングを独自最適化したい（CDN・WAF・エッジ機能）
外部サービス連携を簡素化したい（DNS 統合・自動レコード設定）

これらすべてが「入口の先」のニーズです。Lovable 純正で全部対応しようとすると、各機能を個別に Lovable 側のロードマップに依存することになる。一方で、3 層剥がしの構成を取っておけば、これらすべてを自前で最適化できます。

「AI 経営の入口で止まらない」ためには、Lovable のメリットを享受しながら、必要なレイヤーは自前最適化に剥がしていく ハイブリッド戦略 が必要です。これが私が 6 プロダクトを連続移行しながら確立した、IIWAYO.TECH の標準フレームワークです。

BANSOU CTO™ が提供する "剥がす AI 経営"

ここで、私が運営している BANSOU CTO™ サービスについて触れさせてください。

BANSOU CTO™ は、AI セミナーや一般的なアドバイザリーCTO とは違う設計のサービスです。助言だけでなく、実装まで踏み込む伴走型フラクショナル CTO として、経営者と一緒に AI 経営の "入口の先" を走り抜けます。

具体的に何をするか。3 つのプランがあります。

スターター（50 万円 / 課金サイクル） ── 技術の相談役。MTG 2 回、開発方針アドバイス、軽微改善 50 件目安。実装は経営者側の開発チームが担当。「AI 経営の戦略は欲しいけど、実装は社内でやる」企業向け。

スタンダード（100 万円 / 課金サイクル・おすすめ） ── 経営と技術の参謀。戦略立案 + プロトタイプ開発、システム設計・実装、M&A 支援、中規模基幹システム構築/刷新、軽微改善 100 件目安。「Lovable で立ち上げて、その先の本番事業化を一緒に走り抜けたい」企業に最適です。

フルコミット（200 万円 / 課金サイクル） ── 事業成長の右腕。MTG 4 回以上、フルスタック開発、60 日以内のシステムローンチ、チームマネジメント、大規模基幹システム、軽微改善 200 件目安。「AI で事業の根幹を作り変える」フェーズの企業向け。

「正社員 CTO を採用するには 80 万〜125 万円かかる・しかも採用リスクが高い・即日スタートできない・実装スキルとマネジメントスキルが両立する人材は希少」という従来の壁を、フラクショナル CTO として解消するサービスです。

詳細とサービス比較は iiwayo.tech/pricing で公開しています。

「いきなり 50 万円の契約は重い」という経営者には、SokuApp（30 万円・単発） という爆速プロトタイプ開発サービスもあります。Lovable で 2〜7 日で MVP を作って納品する設計です。BANSOU CTO™ と SokuApp の比較も同じく iiwayo.tech/pricing でご覧ください。

おわりに ── Lovable 公式 SSR が来た今こそ "剥がし" を発信する理由

2026-05-14、Lovable が公式に SSR / SEO-AEO 機能を発表しました。これは私から見ると、AI 駆動開発業界全体にとって素晴らしいニュースです。SSR・SEO・AEO（Answer Engine Optimization）という技術トピックが、800 万人の Lovable ユーザーの視野に一気に入ってくる。業界全体の技術リテラシーが底上げされます。

同時に、これは「Lovable が AI 駆動開発の標準になる」加速点でもあります。今後、ますます多くの経営者・スタートアップが Lovable で立ち上げる時代になるでしょう。

だからこそ今、「Lovable 純正で固める罠」と「3 層剥がしで自由を取り戻す道」を発信する意味があると私は考えています。Lovable 公式 SSR の発表で「Lovable で SSR ができる」ことが業界知識になる。その先の「Cloudflare Workers + 独自 Supabase + 直接 AI API」という構成優位を、いま発信しなければタイミングを逃します。

私が 6 プロダクトを連続移行しながら確立した 3 層剥がしの構造は、決して特殊な技術選定ではありません。「Lovable のメリットを享受しながら、本番事業に必要な構造優位だけを取り戻す」、極めて実用的なハイブリッド戦略です。

経営者として、あなたは Lovable で何を作っていますか。それは "入口" で止まっていませんか。

この記事のポイント

Lovable は素晴らしい AI 駆動開発ツールであり、私は強い肯定派。ただし All-in-One（AI / Cloud / hosting）純正で固めると本番事業化で構造的な罠にハマる
3 層剥がしの構造優位 ── AI 層（直接 API）/ DB 層（独自 Supabase）/ 配信層（Cloudflare Workers）。AI 駆動開発の時代では合計数時間〜1 営業日で完走できる
6 プロダクト連続移行で実測 ── TTFB 13 倍改善、CONISA リージョン移行で 8 秒 → 2 秒、独自 Supabase 共有 DB で Phase 85 → 66 削減
Cloudflare に剥がす副次効果 ── Resend / Stripe 等の外部サービス連携時の DNS 設定が自動化される
「Lovable も入口」 ── AI セミナーは入口で止まる会社が多い、と同じ構造で Lovable も "純正固め" で入口で止まる罠を内包する
BANSOU CTO™ は経営者と一緒に "入口の先" を走り抜ける伴走型フラクショナル CTO サービス

伊藤翔太 株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー代表取締役

次に読むおすすめ

株式会社IIWAYO.TECH ブログ — Lovable / AI 駆動開発 / 経営戦略の関連記事
BANSOU CTO™ サービス詳細 — 3 プランの料金比較・申込導線
株式会社IIWAYO.TECH コーポレートサイト — 創業ストーリー・事業内容