作ったアプリを社外に出す段になって、法務から確認が入ります。「これ、商用利用していい規約になっていますか」。営業資料には「コードはお客様のもの」と書いてある。しかしそれは所有権の話であって、商用利用の可否とも、受託開発で納品してよいかとも、別の論点です。

ここを推測で答えると、後から契約上の問題になります。とくに受託開発の成果物として納品する場合、誤った説明は自社の責任になります。

この記事では、Lovableの利用規約（最終更新2026年8月28日、発効2026年8月15日）の記載にもとづいて、権利とライセンスの構造を整理します。なお本記事は規約の読み解きであり、法的助言ではありません。最終的な判断は原文と自社の法務部門で行ってください。

作ったものは、誰のものになるのか？

まず所有権から確認します。ここは規約に明確な記載があります。

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

ただし但し書きがあります。規約には、基礎となるモデルや学習データに対する第三者の権利による制限がある旨も記載されています。生成AI全般に共通する論点で、Lovable固有の制約ではありませんが、法務への説明では省略しないでください。

一方、Lovable側が持つものも明示されています。サービスおよびLovable Materials——プラットフォーム、ツール、基盤インフラ——に関するすべての権利、権原、利益はLovable（およびそのライセンサー）に帰属します。作ったアプリは自社のもの、道具そのものはLovableのもの、という区別です。プランごとの利用条件はプラン一覧および料金ページで確認できます。

商用利用は認められているのか？

結論として、認められています。ただし「何が認められ、何が禁止されているか」を正確に区別する必要があります。

規約は、利用者が構築したアプリケーション、ウェブサイト、その他のプロダクトを作成し、デプロイし、運用し、提供することを認めています。つまり、作ったものを事業として提供することに制限はかかっていません。有料サービスとして販売することも、この範囲に含まれます。

禁止されているのは別のことです。規約は、サービス自体を第三者に対してサービス・ビューロー方式やタイムシェアリング方式で再販・提供・利用可能にすることを禁じています。また、サービスの複製、改変、配布、販売、リース、サブライセンス、その他の形での利用も禁止されています。

この2つの区別が実務上の要点です。禁じられているのは「Lovableというツールを他人に使わせて商売すること」であり、「Lovableで作った成果物で商売すること」ではありません。この違いを法務に正確に伝えられるかどうかで、審査の結論が変わります。

付与されるライセンスの性質も押さえておいてください。規約によれば、利用者に付与されるのは限定的・非独占的・譲渡不可・全世界を対象とする・撤回可能なライセンスです。譲渡不可である点は、契約主体を誰にするかの判断に影響します。

受託開発で納品する場合、何が論点になるのか？

制作会社やコンサルティング会社にとっては、ここが最も気になる部分でしょう。

まず事実関係として、利用規約には受託開発や納品条件に関する明示的な条項は見当たりません。したがって「納品してよいと書いてある」とも「禁止されていると書いてある」とも言えないのが現状です。

そのうえで、規約の構造から読み取れる論点は次のとおりです。成果物であるアプリケーションとコードは利用者が所有するため、それを顧客に引き渡すこと自体は所有権の観点で矛盾しません。一方で、顧客がそのアプリを継続的に編集・運用する際、Lovableのアカウントを誰が持つのかという問題が残ります。自社のアカウントで顧客のアプリを運用し続ける形は、サービスの第三者提供に近づく可能性があります。

実務的な整理としては、成果物としてのコードを引き渡し、顧客自身がLovableと契約する形が最も曖昧さが少なくなります。公式ドキュメントによれば、すべてのプロジェクトはGitHubまたはGitLabへ継続的に同期でき、クローンして外部で修正し、自社のインフラでデプロイすることも可能です。引き渡しの経路は用意されています。同期の具体的な仕組みはGitHub連携のドキュメントに記載されています。

いずれにせよ、規約に明記のない領域を推測で判断すべきではありません。

生成物の品質について、どこまで保証されるのか？

権利と並んで法務が確認するのが、保証と責任の範囲です。ここは規約に強い表現で書かれています。

規約は、サービス——プラットフォーム、Lovable Cloud、AI Gateway、およびすべてのAI Outputを含む——が「現状有姿（AS IS）」かつ「提供可能な範囲（AS AVAILABLE）」で提供されると定めています。加えて、AI Outputには誤り、不正確さ、その他の問題が含まれる可能性があり、独立した検証なしに依拠すべきではないと明記されています。

責任についても制限があります。間接損害、付随的損害、特別損害、結果的損害等については責任を負わないとされ、賠償額の上限は直近12か月の支払額とされています。

実務への含意は明確です。生成された成果物の品質担保は、利用者側の工程として設計する必要があります。とくに外部に提供するアプリでは、公開前の検証を誰が行い、その結果をどう記録するかを決めてください。公開時に自動実行される検査は設定や依存関係の問題を拾いますが、「独立した検証」の全部を代替するものではありません。

入力したデータは、どう扱われるのか？

商用利用の議論では見落とされがちですが、法務が同時に確認する論点です。

規約によれば、利用者はLovableに対し、Customer Dataを利用・複製・改変・処理・分析等するための全世界的・永続的・ロイヤリティフリーのライセンスを付与します。ただし利用者はいつでもこれを拒否できるとされています。また、Customer Dataから匿名化・集計されたデータを作成し、恒久的に保有・利用できるとされ、利用に伴って生成されるUsage Data（ログやテレメトリ）はLovableが所有するとされています。

プラン別の既定値は公式ドキュメントに整理されています。2026年9月9日以降、FreeプランとProプランの顧客データはモデル学習に利用される可能性があり、アカウント設定から個別にオプトアウトできます。BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。アプリのエンドユーザーのデータ、アカウント・請求情報は学習対象外とされています。

顧客のデータを扱う受託案件では、この既定値の差が判断を分けます。設定に依存する状態では、委託先としての説明責任を果たしにくいためです。契約で担保される構成を選んでください。根拠資料としてはデータ処理契約、プライバシーポリシー、トラストセンターが使えます。

エンドユーザーのデータについては、誰が責任を負うのか？

商用で提供する以上、アプリを使うのは自社の顧客です。その顧客のデータに何かあったとき、誰の責任になるのか。ここは規約だけでなく、過去の経緯も踏まえて理解しておく価値があります。

規約上、Lovableが学習の対象としないデータとして、アプリのエンドユーザーのデータが明示されています。一方で、そのデータを保護する設計の責任がどこにあるかは、別の論点です。

この点が争点として表面化した例があります。NVDに登録されたCVE-2025-48757は、生成されたサイトの行レベルセキュリティ（RLS）ポリシーが不十分なため、遠隔の認証されていない攻撃者が任意のテーブルを読み書きできる可能性を指摘したもので、CVSS 3.1の基本値は9.3、深刻度はCriticalです（2025年5月30日公開、対象は2025年4月15日までのLovable）。同時にNVDには、Lovableプラットフォームの各利用者が自身のアプリケーションのデータを保護する責任を引き受けているという理由で、ベンダーがこれを争っている旨も記載されています。

商用提供の文脈での含意は明確です。アプリのデータ保護は、提供者である自社の責任範囲として設計しておくべきだということです。セキュリティの実践ガイドに沿った公開前チェックを工程化し、その記録を残してください。顧客との契約でSLAや責任範囲を定める場合、この工程の有無が説明の裏づけになります。

決済を伴うサービスとして提供する場合、追加で何が必要か？

作ったアプリで課金するなら、規約の確認だけでは足りません。決済事業者側の審査が別に発生します。

公式ドキュメントによれば、組み込みのPayments機能はStripeとPaddleに対応し、利用にはPro以上の有料プランと、組み込みバックエンド（Cloud）が必要です。自前のSupabaseを接続しているプロジェクトでは利用できないとされています。設定できるのはプロジェクトまたはワークスペースの管理者に限られます。

本番稼働の前提として、事業者ごとの審査があります。公式ドキュメントによれば、Paddleでは所在地の確認とドメインの審査、KYC／KYBの検証フォームの完了が必要で、プライバシーポリシー、利用規約、返金ポリシーの掲載が必須とされています。Stripeでもアカウントの所有権移譲とオンボーディングのチェックリスト完了が求められます。いずれも、すべての手順を完了するまで本番の決済は機能しません。

手数料の構造も違います。公式ドキュメントによれば、Paddleは1取引あたり5.0%＋50セント、10ドル未満の少額取引は定率10%とされ、Stripeは従量課金です。またPaddleは完全なマーチャント・オブ・レコード方式で、Stripeはオプションでの対応とされています。この違いは、消費税や海外販売時の納税義務を誰が負うかに影響するため、経理・税務と合わせて確認してください。

制約もあります。1つのプロジェクトで両方の事業者を混在させることはできず、既定では各利用者が保有できるアクティブなサブスクリプションは1件です。またPaymentsを有効化したプロジェクトは、リミックス（フォーク）できなくなるとされています。

法務チェックで確認すべき項目は何か？

ここまでを、審査に持ち込める形にまとめます。左列の項目を規約の該当箇所で確認するのが、最短の進め方です。

この表で最も注意が必要なのは最下段です。規約に書かれていないことを「問題ない」と読むのは危険であり、同時に「禁止されている」と読むのも不正確です。判断が必要な領域として扱い、確認の記録を残してください。

提供形態によって、確認すべき範囲はどう変わるのか？

「商用利用できるか」という問いは、実際には提供形態によって答えの重心が変わります。同じ規約でも、確認すべき箇所が違うということです。

社内利用にとどまる場合、論点はほぼデータの扱いに集約されます。エンドユーザーが自社の従業員であるため、外部への提供という論点が発生しません。学習利用の既定値と権限設計を押さえれば足ります。

顧客向けに提供する場合、これに保証と責任の範囲が加わります。規約が現状有姿であることを踏まえ、自社が顧客に対してどこまで保証するのかを別途定める必要があります。Lovable側の責任上限が直近12か月の支払額である点と、自社が顧客に約束する内容の乖離は、契約前に確認してください。

受託開発の成果物として納品する場合、さらにアカウントの所有と運用主体の論点が加わります。前述のとおりこの領域には明示の条項が見当たらないため、個別の確認が必要です。Enterpriseの契約では条件を個別化できるとされているため、商流に組み込む前に条件として整理するのが安全です。

整理すると、確認範囲は社内利用＜顧客提供＜受託納品の順に広がります。自社がどこに該当するかを最初に定めてから規約を読むと、確認すべき条項が絞れます。すべてを一度に確認しようとすると、判断が止まります。

よくある質問（FAQ）

作ったアプリを有料サービスとして販売できますか？

規約は、構築したアプリケーションやプロダクトを作成・デプロイ・運用・提供することを認めています。販売自体を禁じる記載は見当たりません。ただし決済の実装や特定商取引法への対応など、規約とは別の要件は自社で満たす必要があります。

生成された画像やアイコンは商用で使えますか？

AI Outputの所有については利用者に帰属すると記載されていますが、基礎となるモデルや学習データに関する第三者の権利による制限があるとされています。素材の性質によって判断が変わるため、外部公開物に使う場合は法務の確認を経てください。

クライアントのアプリを自社アカウントで運用し続けてよいですか？

規約に明示の条項が見当たらない領域です。サービスの第三者提供に該当しないかという論点があるため、商流に組み込む前にLovableへ直接確認することをおすすめします。

解約後も、作ったアプリを事業で使い続けられますか？

コードの所有は利用者にあり、GitHubまたはGitLabへ同期していれば手元に残ります。ただし組み込みバックエンドを使っている場合、データベースや認証は一緒には移動しません。事業継続を前提にするなら、同期とデータのエクスポート運用を先に整えてください。

規約はいつ変わるか分かりません。どう管理すべきですか？

本記事が参照した版は最終更新2026年8月28日です。契約書に規約を引用する場合は、参照した日付と版を明記してください。あわせて公式チェンジログを定期的に確認する担当を決めておくと、変更に気づけます。

免責が「現状有姿」だと、業務利用は難しいのでは？

クラウドサービス全般に共通する条項であり、これ自体で利用不可と判断する必要はありません。要点は、品質担保と検証の工程を自社側で設計しているかどうかです。設計があれば説明できます。

英語の規約しかありません。翻訳して社内資料にしてよいですか？

理解のための翻訳は実用的ですが、契約判断の根拠を機械翻訳のまま転記するのは避けてください。所有権・禁止行為・責任上限といった条項は、誤訳が判断を誤らせます。該当箇所は原文を併記するのが安全です。

まとめ：商用利用は可能、禁止されているのは「サービスの再販」

Lovableの利用規約は、構築したアプリケーションと生成されたAI Outputの所有を利用者に認め、それらを作成・デプロイ・運用・提供することを許容しています。したがって、作ったものを事業として提供することに規約上の制限はかかっていません。

禁止されているのは、Lovableというサービス自体を第三者に再販・提供することです。この区別を正確に伝えられれば、法務審査の中心的な論点は解消します。付与されるライセンスが譲渡不可である点、保証が現状有姿である点、責任上限が直近12か月の支払額である点も、あわせて確認してください。

一方で、受託開発における納品や運用代行については、規約に明示の条項が見当たりません。ここは「書かれていないから問題ない」と読まず、商流に組み込む前に個別に確認すべき領域です。本記事は規約の読み解きであり、法的助言ではありません。最終判断は原文と自社の法務部門で行ってください。

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