稟議の最終盤で、必ず一度は投げられる質問があります。「そのツールをやめたら、作ったものはどうなるんですか」。過去に特定のツールへ囲い込まれて痛い目に遭った企業ほど、この確認は厳しくなります。

営業資料には「コードはお客様のもの」と書いてある。しかし、その一文が実務上どこまで意味を持つのかは書かれていません。取り出せるのか、取り出したものが動くのか、取り出した後も同期し続けられるのか。3つは別の話です。

この記事では、Lovableで作った成果物がどこまで自社の資産として残るのかを、2026年9月1日時点の公式ドキュメントと利用規約にもとづいて検証します。

コードの所有権は、規約上どう定められているのか？

まず一次情報から確認します。営業資料の要約ではなく、契約文書に何と書かれているかです。

Lovableの利用規約（最終更新2026年8月28日）は、利用者が自身のCustomer Data——構築したアプリケーション、ウェブサイト、その他のプロジェクトを含む——を所有すると定めています。さらに、サービスを通じて生成されたAI Outputについても利用者が所有すると記載されています。公式FAQでも、プロジェクトとコードの所有者は作成者自身であると明記されています。

一方で、プラットフォームそのもの（サービスおよびLovable Materials）に関するすべての権利はLovable側にあるとされ、サービスを第三者に再販したり、サービス・ビューロー的に提供したりすることは禁止されています。区別は明確です。作ったアプリは自社のもの、Lovableという道具そのものは自社のものではない、ということです。

この区別を稟議書に書いておくと、法務からの追加質問が減ります。「所有できる」とだけ書くと、範囲が曖昧なまま承認され、後から確認作業が発生します。

取り出す方法は、どうなっているのか？

権利があっても、経路がなければ意味がありません。ここは機能の話です。

公式ドキュメントによれば、すべてのLovableプロジェクトはGitHubまたはGitLabへいつでも継続的に同期できるとされています。クローンして外部で修正し、自社のインフラでデプロイすることも可能です。

重要なのは「エクスポート」ではなく「継続的な同期」である点です。一度きりの書き出しであれば、書き出した瞬間から2つの版が乖離します。同期であれば、両側の変更が反映され続けます。この違いが、実務での使い勝手を大きく分けます。

GitHub同期は、具体的にどう動くのか？

公式ドキュメントによれば、接続は2層構造です。まずワークスペース単位でGitHubのアカウントまたは組織を認可し、これを複数プロジェクトで再利用します。次にプロジェクトとリポジトリを紐づけます。

同期は双方向です。Lovable側の変更はGitHubへ同期され、同期中のブランチへプッシュされた変更はLovableへ戻ります。ローカルにクローンして外部のエディタで編集した内容も、同期中のブランチにプッシュすれば反映されます。ブランチは既定でリポジトリのデフォルトブランチが使われ、切り替えや新規作成にも対応します。

制約も明示されています。Lovableが一度に編集・同期できるのは1ブランチのみです。並行して複数ブランチを扱う開発フローとは、そのままでは噛み合いません。

リポジトリは誰のものになるのか？

ここは実務上とくに重要です。公式ドキュメントによれば、リポジトリはLovableが作成し、既定では非公開になります。ただし所有者はGitHubのアカウントまたは組織です。

つまり、器は自社のGitHub組織の中にあります。一方で、リポジトリの削除・移動・名称変更はLovable側の同期を壊すとされています。自社の資産でありながら、扱いには制約があるということです。命名規則と管理者を、接続前に決めておいてください。

組織要件がある場合の選択肢も用意されています。Enterpriseでは GitHub Enterprise Cloud のリージョン指定により、リポジトリのデータとWebhookのトラフィックを指定リージョン内に留める構成が可能とされ、GitHub Enterprise Server の自社ホストにも対応します。後者では自社でアプリを登録し、その秘密鍵は安全に転送され暗号化して保管されるとされています。組織向けの統制の全体像はEnterpriseのドキュメントに整理されています。

取り出したコードは、そのまま動くのか？

ここが「持ち出せる」と「使える」の分かれ目です。ソースコードがあることと、それが自社環境で動くことは同じではありません。

フロントエンドとアプリケーションのコードは、通常のプロジェクトとして扱えます。問題になるのはバックエンドです。組み込みバックエンド（Cloud）を使っている場合、データベース、認証、ストレージ、サーバー側の処理はLovable側で提供されています。コードを持ち出しても、この部分は一緒には移動しません。

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

したがって正確な言い方はこうなります。コードは自社資産として残る。ただしバックエンドを含む「動く状態」ごと引き上げるには、別途の移行作業が必要になる。稟議書にはこの2文をそのまま書いてください。

完全に外部へ移す場合、何を引き受けることになるのか？

ロックイン回避の議論では「出られること」ばかりが焦点になりますが、出た後に何を背負うのかも同時に見るべきです。

公式ドキュメントによれば、Lovableで構築したアプリケーションはどこにでもホストできます。一方で別のドキュメントは、完全に移行した場合に自社が管理することになる範囲として、CI/CDパイプラインと本番インフラの運用、データベース・ストレージ・バックアップ、認証やOAuthやAPI連携、そしてセキュリティ監査と法令準拠を挙げています。

公式の推奨も現実的です。「まず単純に始め、段階的に移す」とされ、コンプライアンスやネットワークの制約といった実際の必要が生じた段階で移行を検討するのが効率的だと述べられています。移行できる状態を確保しておくことと、いま移行することは別です。

「コードがある」ことと「引き継げる」ことは、どう違うのか？

ロックイン回避の議論は、たいてい「取り出せるか」で終わります。しかし現場で本当に問題になるのは、取り出したものを別の人が理解できるかどうかです。

生成されたコードは、人が書いたコードと同じように読めます。読めば構造は分かります。分からないのは、なぜその構造にしたのかという意図です。どのテーブルにどの項目を持たせたか、どの権限をどういう理由で設計したか、どこを未実装のまま残したか。これらはコードに書かれていません。

実務的な対処は2つです。ひとつは、引き継ぐ前にPlan modeで現状の構造を整理させることです。Plan modeはコードを書かずにプロジェクトのファイルやデータベース、ログを調べ、構造化された内容を提示します。メッセージあたり1クレジット固定で動くため、費用も読めます。

もうひとつが、公開前の点検結果を添えることです。セキュリティの実践ガイドに沿って、認証していない訪問者に何が見えるか、他人のデータが見えないか、管理者専用の操作が一般利用者に開いていないかを確認し、その結果を残してください。引き継いだ側がこれをやり直す工数のほうが、残す工数より大きくなります。

接続する前に、決めておくべきことは何か？

Git同期は後からでも接続できますが、先に決めておかないと後で直しにくい項目があります。3つだけ挙げます。

第一が、リポジトリを置く場所です。個人アカウントではなく、自社のGitHub組織に置いてください。担当者の退職時にリポジトリごと失われる事態を防げます。第二が、命名規則です。前述のとおり、リポジトリの削除・移動・名称変更は同期を壊すため、後から整理し直すのが困難です。第三が、Lovable側で固定するブランチです。1ブランチしか同期できないため、どのブランチを正とするかを最初に決めます。

組織で複数プロジェクトを扱う場合は、ワークスペース単位の接続を再利用できる点も設計に活かせます。プランによって利用できる統制機能が異なるため、全社展開を見込むなら上位プランの条件で確認してください。セキュリティセンターでは、全プロジェクトのシークレットを一元表示することもできます。

ロックイン回避という要件に、これは十分な答えになるのか？

法務や情報システム部門が確認したいのは、多くの場合「事業継続性」です。ツールが使えなくなったとき、業務が止まるかどうか。この観点で整理します。

この表の3行目と4行目のギャップが、実務上の要点です。「どこにでもホストできる」は正しいのですが、それはアプリケーションの話であり、データベースと認証が自動で付いてくるわけではありません。ここを混同したまま「移行は容易」と稟議に書くと、実行段階で説明が食い違います。

資産として残すために、運用で何をすべきか？

権利と機能が揃っていても、運用していなければ資産にはなりません。実際に手元に残すための最小限の作業を挙げます。

第一に、プロジェクト作成の初期にGit同期を接続することです。「必要になったら繋ぐ」と考えていると、必要になった時点では往々にして繋いでいません。接続自体は後からでも可能ですが、習慣として最初に行うほうが確実です。

第二に、リポジトリの命名規則と管理者を決めることです。前述のとおり、削除・移動・名称変更は同期を壊します。個人アカウントではなく組織のリポジトリに置き、管理権限を情報システム部門が持つ形が望ましいといえます。

第三に、データのエクスポート運用を別途設計することです。コードとデータは別管理です。組み込みバックエンドのデータベースにはバックアップからの復元機能がありますが、業務上重要なデータについては、自社側での定期的な書き出しを検討してください。稼働に関する費用はクレジットの消費として計上されるため、運用設計と合わせて確認してください。

第四に、引き継ぎ用のドキュメントを残すことです。データ構造と項目の定義、権限設計の意図、未実装のまま残した箇所の一覧。コードを読めば分かることではないため、ナレッジ機能などに記述しておくと、後任が読める形で残ります。

乗り換えのシナリオは、どこまで想定しておくべきか？

事業継続性の審査では、しばしば「最悪の場合」を問われます。ただし、あらゆる事態に備えると設計が過剰になります。想定すべきシナリオを3つに絞ると、議論が現実的になります。

第一が、契約を解約して別ツールへ移るケースです。この場合に必要なのは、コードが手元にあることと、データを書き出せることです。Git同期を接続していれば前者は満たされ、後者は自社側のエクスポート運用で担保します。

第二が、特定のアプリだけを本番システムとして切り出すケースです。これは乗り換えではなく成長に伴う移行で、実際にはこちらのほうが頻度が高くなります。外部ホスティングへの移設と、バックエンドの再構築が主な作業です。

第三が、サービス側の重大な仕様変更に対応するケースです。ここは事前の準備というより、変更を早く知る体制の問題になります。公式チェンジログを定期的に確認する担当を決めておくだけで、対応の初動が変わります。

この3つのうち、実務で最も起きるのは第二です。ところが稟議で議論されるのは第一ばかりで、第二の想定が抜けがちです。成長に伴う移行を前提に、最初からGit同期とデータのエクスポート運用を組み込んでおくのが、結果として最も無駄がありません。

よくある質問（FAQ）

契約を解約したら、リポジトリは消えますか？

リポジトリはGitHub／GitLab側の自社アカウントまたは組織にあります。したがって、同期を接続しておけばコードは手元に残ります。逆に接続していなければ、解約前に取り出す作業が必要になります。

GitLabでも同じことができますか？

公式ドキュメントには、すべてのプロジェクトをGitHubまたはGitLabへ継続的に同期できると記載されています。ただし各機能の対応範囲は異なる可能性があるため、GitLabを社内標準としている場合は接続前に詳細を確認してください。

複数人が同時に別のブランチで作業できますか？

Lovableが一度に編集・同期できるのは1ブランチのみです。並行開発を行う場合は、外部エディタ側でブランチを分け、Lovable側は特定のブランチに固定するといった運用設計が必要になります。

エクスポートしたコードの著作権は誰にありますか？

利用規約では、構築したアプリケーションおよび生成されたAI Outputを利用者が所有すると定めています。ただし基礎となるモデルや学習データに関する第三者の権利には制限があるとされているため、詳細は原文と自社の法務判断で確認してください。

移行の見積もりは、どう作ればよいですか？

アプリケーションのコードではなく、バックエンドの移設を軸に見積もってください。スキーマの再構築、データの移行、認証ユーザーとストレージ上のファイルの移設が主な工数です。とくに認証情報の移行は制約が多く、難易度が読みにくい部分です。

ロックイン回避のために、最初から自前Supabaseにすべきですか？

その判断もあり得ますが、運用責任を最初から自社が負うことになります。Cloudのリージョンは有効化後に変更できない点も含め、要件を整理したうえで選んでください。検証だけならCloudで十分です。

情シスに提出する資料には何を書けばよいですか？

所有権に関する規約の該当箇所、Git同期の仕組みと1ブランチ制約、そしてバックエンドが自動では移行できないという3点です。この3点が書かれていれば、事業継続性の観点での確認はほぼ通ります。

まとめ：残るのはコード、残らないのは動く状態

Lovableで作った成果物は、規約上も機能上も自社の資産として残ります。利用規約は構築したアプリケーションと生成されたAI Outputの所有を利用者に認めており、GitHubまたはGitLabへの継続的な同期によって、コードは常に自社のリポジトリにある状態を作れます。

ただし「動く状態ごと引き上げる」ことは別作業です。組み込みバックエンドと自前Supabaseの間には自動マイグレーションがなく、データベース・認証・ストレージの移設には手作業が必要です。外部へ完全移行した場合は、CI/CDから法令準拠まで運用責任を自社が負います。

したがって実務でやるべきことは明快です。プロジェクトを作ったらすぐGit同期を接続し、リポジトリを組織で管理し、データのエクスポート運用と引き継ぎ資料を別途用意する。この4点で、ロックイン回避という要件には実質的に応えられます。

Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、情報システム部門向けの説明資料の整備は株式会社100の問い合わせ窓口でご相談ください。