プロトタイプを見せた翌日、情報システム部門から短い質問が来ます。「そのデータ、どこに置かれているんですか」。答えられずに持ち帰り、調べ始めて初めて、自分がバックエンドの選択を何もしていなかったことに気づく——Lovableで最初のアプリを作った担当者が、ほぼ必ず通る場面です。

この選択が厄介なのは、後回しにできないからです。あとで詳しく述べますが、Lovableのバックエンドは一度決めると実質的に変更できません。しかも既定で有効になっているため、「まだ選んでいない」つもりでも、実際には選択済みの状態で進んでいます。

この記事では、組み込みバックエンドである Lovable Cloud と、自前の Supabase を接続する構成の違いを、2026年9月1日時点の公式ドキュメントにもとづいて整理します。判断に必要なのは機能の一覧ではなく、後戻りできない箇所がどこかという情報です。

Lovable Cloudとは、何を含んでいるのか？

まず前提を揃えます。Lovable Cloudは追加のアカウント登録なしに使える組み込みバックエンドで、既定で有効になっています。データを保存する機能を求めるプロンプトを送った時点で、自動的に有効化されるか、有効化の確認を求められます。

公式ドキュメントによれば、含まれるのはデータベース、ユーザー認証、ストレージ、エッジ関数（サーバーレスのバックエンド処理）、スケジュール実行のジョブ、独自ドメインからのメール送信、そしてAPIキーなどを保管するシークレット管理です。データベースではテーブルの表示、レコードの編集、セキュリティポリシーの確認、バックアップからの復元が行えます。

実務的な意味は明確です。業務アプリに必要な要素——ログイン、データの保存、ファイルの添付、定期実行、通知メール——が、別のサービスを契約せずに揃うということです。「見積もりの前に動くものを出す」という使い方が成立するのは、この構成によります。

自前のSupabaseに接続すると、何が変わるのか？

もうひとつの選択肢が、自社で契約したSupabaseのプロジェクトに接続する構成です。変わるのは機能ではなく、所有と管理の主体です。

公式ドキュメントによれば、Supabase統合を選ぶと、バックエンドを自社で直接所有し、自社のSupabaseアカウントと課金体系のもとで管理し、Supabaseのダッシュボードにフル権限でアクセスできます。既存のSupabaseプロジェクトを使うこともできます。

接続の手順は権限で分かれます。ワークスペースのオーナーまたは管理者がSupabaseの組織をリンクし、編集権限を持つメンバーがリンク済みの組織から既存プロジェクトを接続する、という流れです。リンクはコネクタのページ、プロジェクト作成時、または既存プロジェクトのCloudビューから行えます。

接続の単位にも制約があります。ひとつのLovableプロジェクトが同時に接続できるSupabaseプロジェクトは1つです。逆に、複数のLovableプロジェクトが同一のSupabaseプロジェクトを共有することは可能とされています。

両者は、どこが違うのか？

比較の軸は「何ができるか」ではなく「誰が持ち、誰が管理し、誰に請求されるか」です。機能表を並べても判断できないのは、差が機能ではなく責任の所在にあるためです。

ここで注目していただきたいのは、2行目と5行目の組み合わせです。Cloudは請求先も運用責任もLovableに寄せる構成であり、自前Supabaseは両方を自社に引き取る構成です。社内に運用の担い手がいない状態で後者を選ぶと、便利さではなく負担だけが増えます。

データはどこに置かれ、後から動かせるのか？

冒頭の「どこに置かれているのか」という質問への答えです。ここには、見落とすと取り返しがつかない仕様があります。

公式ドキュメントによれば、Cloudで選択できるリージョンはAmericas、Europe、Asia Pacificです。初回は位置情報から最適なリージョンが推奨されます。そして重要なのは次の点です。プロジェクトでCloudを有効化すると、選択したリージョンはロックされ、変更できません。

日本企業にとっての含意は明確です。データの所在に社内規程がある場合、最初のプロジェクトを作る前にリージョンを確認する必要があります。試しに作ったつもりのプロジェクトが推奨のまま別リージョンで固定され、そこに業務データを入れてしまうと、リージョンを変えるにはプロジェクトを作り直すしかありません。

組織として統制する手段は用意されています。公式ドキュメントによれば、BusinessプランとEnterpriseプランでは、管理者が全プロジェクトに対する必須リージョンを設定できます。全社展開を前提にするなら、この設定を先に入れてから利用者を増やすのが正しい順序です。プラン別の機能差はプラン一覧、組織向けの統制はEnterpriseのドキュメントとトラストセンターで確認できます。

コードの所在についても、Enterpriseでは GitHub Enterprise Cloud のリージョン指定により、リポジトリのデータとWebhookのトラフィックを指定リージョン内に留める構成が可能とされ、GitHub Enterprise Server の自社ホストにも対応するとされています。データとコードは別の話なので、要件がある場合は両方を確認してください。

課金の構造は、どう違うのか？

費用の見え方も大きく変わります。稟議の書き方に直結する部分です。

Cloudを使う場合、費用はLovableのクレジットに一本化されます。2026年6月13日に公表された課金体系の変更により、アプリの構築用とCloud/AI用に分かれていた残高が統合され、ひとつのクレジット残高で構築と運用の両方をまかなう形になりました。メンバー別・プロジェクト別・用途別に支出を可視化するページも提供されています。

Cloud usageの課金要因は、データベースサーバー（インスタンスの大きさ・稼働時間・トラフィック）、データベースの保存容量、ネットワーク、ストレージ、バックエンドの処理、リアルタイム更新のメッセージです。つまり利用者が増え、データが増えるほど消費します。

自前のSupabaseを使う場合、バックエンドの費用はSupabaseとの契約になります。Lovable側のクレジットは主に構築のために消費される形になり、稼働費用は別勘定です。請求書が2枚になる代わりに、バックエンドの費用構造は自社で直接コントロールできます。

どちらが安いかは規模と使い方によって変わるため、一般論では答えが出ません。判断すべきは金額ではなく、稼働費用を「1つの請求にまとめたいか、自社で個別に管理したいか」という運用方針です。

なぜ「後から変えられない」のか？

この記事で最も重要な事実です。ここを知らずに進めることが、最大のリスクになります。

公式ドキュメントによれば、Lovable Cloudと自前のSupabase接続の間には自動マイグレーションの機能がなく、どちらの方向にも移行できません。移行するにはスキーマを再構築し、データを手動で移す必要があります。

加えて、前述のとおりCloudのリージョンは有効化時点でロックされます。つまり「まずCloudで作って、本番化のときに自前Supabaseへ移す」という計画は、想定より重い作業になります。検証段階のデータ量が小さいうちは移行できても、運用が始まってからでは現実的ではありません。

したがって実務上の原則はこうなります。検証だけで終わらせる予定のプロジェクトはCloudで問題ありません。しかし本番運用まで見込んでいるなら、最初の1本を作る前にバックエンドとリージョンを決めてください。この判断だけは、動かしながら考えることができません。

どうしても移行が必要になったら、実務では何をするのか？

自動マイグレーションがない以上、移行は手作業になります。「できない」ではなく「手順を踏めばできる」なので、必要になった場合に備えて全体像を押さえておくと判断が速くなります。

作業は大きく4段階です。移行先のプロジェクトを用意し、スキーマ（テーブル定義・制約・インデックス）を再構築し、データを書き出して投入し、認証ユーザーとストレージ上のファイルを移します。このうち工数が読みにくいのは最後の段階です。認証情報の移行はサービスごとに制約があり、パスワードのハッシュをそのまま持ち込めるかどうかで難易度が変わります。

さらに、移行後には権限設計の再確認が必要です。テーブルを作り直せば行レベルセキュリティのポリシーも作り直しになるため、移行前と同じ見え方になっているかを人が確認しなければなりません。公開時に自動実行されるBasic ScanはRLSポリシーのリンティングを含みますが、業務上「誰に見せてよいか」の判断までは代替しません。公開手順の中に、この確認を工程として組み込んでください。

結論として、移行はデータ量が小さい検証段階でのみ現実的です。部門で運用が始まり、利用者と履歴が積み上がってからでは、作り直しに近い規模になります。だからこそ最初の判断が重要になります。

既存の社内システムのデータと、どう繋ぐのか？

もうひとつ、バックエンドの選択と混同されやすい論点があります。「既存の基幹システムやCRMのデータを使いたい」という要件です。これはバックエンドをどちらにするかとは別の問題です。

Lovableのバックエンドは、そのアプリが自分で持つデータの置き場です。既存システムのデータを扱いたい場合は、APIやコネクタ経由で参照・更新する構成になります。したがって「自前Supabaseにすれば社内データと繋がる」わけではありません。ここを取り違えると、選択の理由そのものが崩れます。

設計の順序としては、まず参照したい既存データとその方式（API、定期同期、手動取り込み）を決め、そのうえでアプリ自身のデータをどこに置くかを決めます。要件の整理には、実装前に計画を提示させるPlan modeが有効です。コードを書かずにプロジェクトを調べて確認質問を返し、メッセージあたり1クレジット固定で動きます。プロンプトの原則にあるとおり、保持する項目と選択肢を先に言語化しておくと、後からの作り直しを避けられます。

Cloudでしか使えない機能はあるのか？

機能面でも非対称があります。自前Supabaseを選ぶと使えなくなるものがあるため、要件に含まれていないか確認が必要です。

公式ドキュメントによれば、決済の統合、独自ドメインからのカスタムメール送信、ログイン状態でのブラウザテスト、機密情報のスキャンといった機能は、組み込みバックエンドでのみ利用できるとされています。エッジ関数やスケジュール実行のジョブも、Cloudのビューから統合的に管理する形です。

逆にいえば、自前Supabaseを選ぶ理由は「これらを諦めてでも、バックエンドを自社の管理下に置きたい」という要件があるときに限られます。既にSupabaseで動いている資産がある、社内標準としてSupabaseを使っている、といった事情がなければ、Cloudを選ぶほうが素直です。

どちらを選ぶべきか、どう判断するのか？

判断は3つの問いで済みます。順に答えていけば、選択肢はほぼ1つに絞られます。

第一の問い。既にSupabaseを社内で運用しており、そこに接続したい資産がありますか。あるなら自前Supabaseです。第二の問い。データの所在について社内規程がありますか。あるなら、Cloudを使う場合はリージョンを確認し、Business以上で必須リージョンを設定してから開始してください。第三の問い。決済統合やカスタムメールを使う予定がありますか。あるならCloudです。

いずれにも当てはまらない場合はCloudで構いません。追加の契約と運用負担がなく、検証から公開までの距離が最も短いためです。ただし、その決定を「意識して選んだ」と記録に残してください。既定のまま進んだのか、検討して選んだのかは、後から情報システム部門に問われたときに大きな差になります。

それぞれのメリットとデメリットは何か？

最後に両面を並べます。判断が割れるのは、良し悪しではなく組織の体制によって重みが変わるためです。

最下段を1行にまとめたのは、これが両者に共通する制約であり、かつ選択のやり直しコストそのものだからです。この1行を稟議資料に転記しておくと、後から「なぜ最初に決めたのか」を説明する必要がなくなります。

バックエンド構成の選定、データ所在の要件整理、情報システム部門向けの説明資料に関するご相談は、株式会社100のLovable公式パートナーページで承っています。

よくある質問（FAQ）

すでにCloudでプロジェクトを作ってしまいました。リージョンを変えられますか？

公式ドキュメントによれば、Cloudを有効化した時点で選択したリージョンはロックされ、変更できません。要件と異なる場合は、正しいリージョンで新しいプロジェクトを作り直すことになります。データ量が少ないうちに判断してください。

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

公式ドキュメントによれば可能です。ただしLovableプロジェクト側は、同時に1つのSupabaseプロジェクトにしか接続できません。共有する場合は、テーブルの命名や権限設計が相互に影響する点に注意してください。

Cloudのデータはバックアップされていますか？

Cloudのデータベースビューにはバックアップからの復元機能があると記載されています。ただし保持期間や粒度は要件に照らして確認し、業務上重要なデータは別途エクスポートの運用を設計してください。

クレジットが尽きたら、Cloudのデータは消えますか？

消えません。公式ドキュメントによれば、残高がゼロになるとCloudに依存するアプリは一時停止することがありますが、データベース・ストレージ・認証のデータは停止中も安全に保持されるとされています。ただしアプリは止まるため、業務利用では上限と補充の運用を決めておく必要があります。

情シスに「Supabaseとは何か」から説明する必要があります。どう伝えればよいですか？

「アプリの裏側でデータを保存・認証する部分」と説明し、Cloudはそれをまとめて提供する構成、自前Supabaseは同じ部分を自社契約で持つ構成、と対比するのが最短です。判断が必要なのは技術ではなく、管理と請求をどちらに置くかです。

本番運用を見込む場合、最初からBusinessプラン以上にすべきですか？

その可能性が高いです。必須リージョンの設定、SSO、セキュリティセンターはBusiness以上の機能であり、ワークスペースデータが契約にもとづき既定で学習対象外になるのもBusiness・Enterpriseです。後から移るより、最初から揃えるほうが手戻りが少なくなります。

Supabaseのセルフホスト版に接続できますか？

公式ドキュメントで明示的に案内されているのは、Supabaseのアカウント・組織を通じた接続です。セルフホスト構成での利用を検討している場合は、要件を整理したうえで事前に確認してください。公開情報だけで判断すると、実装後に手戻りが発生します。

まとめ：バックエンドとリージョンは、最初の1本を作る前に決める

Lovableのバックエンドには、組み込みのCloudと、自前Supabaseへの接続という2つの構成があります。違いは機能ではなく、所有・管理・請求の主体です。Cloudは追加契約なしで最短距離を進める構成、自前Supabaseはバックエンドを自社の管理下に置く構成です。

そして判断を先送りできない理由が2つあります。両者の間に自動マイグレーションがなく、どちらの方向にも移行できないこと。そしてCloudのリージョンは有効化時点でロックされ、変更できないことです。データの所在に規程がある企業では、最初のプロジェクトを作る前に、Business以上で必須リージョンを設定しておくのが正しい順序になります。

迷ったらCloudで構いません。ただし「既定のまま進んだ」のではなく「検討して選んだ」という記録を残してください。情報システム部門が確認したいのは構成そのものより、判断が行われたかどうかです。

Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、構成選定のご相談は株式会社100の問い合わせ窓口をご利用ください。