Lovableのセキュリティは本当に安全？【結論：設定次第】

こんにちは。AI・ノーコード開発を手がける成長支援カンパニーWalkersです。

弊社では多くの企業様からAI活用に関するご相談をいただいていますが、その中でも「Lovableのセキュリティは本当に安全なのか」という質問が寄せられます。

AIに作らせたアプリを業務で使うとなると、入力した内容の扱いや、公開したアプリから個人情報が漏れないかが気になるのはもっともです。

実は、Lovableのセキュリティは決して弱くありません。ただし、無料プランとProプランでは初期設定のままだと入力内容がAIの学習に使われる場合があるなど、確認しておくべき点があります。

そこで今回は、Lovableのセキュリティについて、公式の公開情報をもとに以下の内容を解説していきます。

Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら

Lovableのセキュリティは安全なのか？

Lovableは、文章で指示するだけでAIがWebアプリを作るサービスです。セキュリティを考えるときは、「Lovableという基盤の安全性」と「Lovableで作ったアプリの安全性」を分けて見る必要があります。

稟議書や監査で説明する立場であれば、次の3つに分けて整理すると判断しやすくなります。

最初の1つは提供元の公開情報で確認でき、残りの2つは自社の設定と確認で決まります。

この記事も、この順序で見ていきます。

Lovableのセキュリティが安全と言える4つの理由とは？

公式のトラストセンター、セキュリティのページ、ドキュメント、DPA（データ処理契約）などで裏取りできた理由は、次の4つです。

【理由①】国際的なセキュリティ認証を取得した基盤の上で提供されている

Lovableは、Lovable社が提供するアプリ開発AIのサービスです。プライバシーポリシーでは、同社の主たる拠点はスウェーデンのストックホルムとされています。

Lovable社は、トラストセンターで、SOC 2 Type II、ISO/IEC 27001:2022、AIUC-1を取得している旨を掲示しています。

※SOC 2 Type IIとは「第三者の監査人が、情報管理の統制が一定期間にわたって実際に機能していたかを確認した報告書」を指す。

※ISO 27001とは「情報セキュリティを組織として管理する仕組みに関する国際規格」を指す。

※AIUC-1とは「AIのセキュリティ、安全性、信頼性に関する第三者の基準」を指す。

SOC 2 Type IIについては、2026年10月5日付のお知らせで、2026年2月1日から8月1日までを対象期間とする監査が完了し、「指摘事項なし」で報告書が発行されたと説明されています。

GDPR（EUの個人データ保護法）とCCPA（米カリフォルニア州の個人情報保護法）については、取得する認証ではなく、法令への対応として説明されています。公式FAQも、これらに外部の認証は必要ないと明記しています。

認証が示すのは「提供元の管理体制の水準」であり、利用者が作るアプリの安全性までは含みません。

なお、SOC 2のレポート本体はトラストセンター経由の請求が前提で、ISO 27001の適用範囲も公開ページの本文には書かれていません。稟議で使う場合は、レポートや証明書を取り寄せて確認することになります。

»出典：Lovable Trust Center

【理由②】暗号化とアクセス統制の方針が公開されている

トラストセンターのFAQには、運用面の統制が項目ごとに公開されています。たとえば、次のような内容です。

セキュリティのページでは、利用者のワークスペースとプロジェクトは論理的に分離され、アカウントをまたいだデータの参照はできないと説明されています。ただし、Lovableは複数の顧客で基盤を共有するマルチテナント型で、分離は論理的なもの（アプリとインフラの両方の層で実施）と説明されています。

一方で、Lovableの基盤自体を対象にしたペネトレーションテスト（攻撃を模した脆弱性テスト）の実施頻度や、脆弱性報奨金制度については、公開ページの範囲では確認できませんでした。必要な場合は、トラストセンターに掲載されているホワイトペーパーなどで確かめる流れになります。

»出典：Lovable Trust Center（FAQ）

【理由③】生成アプリの鍵とデータを守る仕組みが標準で組み込まれている

Lovableで作るアプリのコードはブラウザ上で動くため、APIキー（サービスを使うための鍵）をそのまま書くと、誰でも見られる状態になります。そこでLovableは、チャットに貼り付けられたAPIキーを検知し、「Secrets」という専用の保管場所に入れるよう案内します。

鍵は、ブラウザ側ではなくサーバー側のコードから呼び出す形で使われます。

※行レベルセキュリティ（RLS）とは「データベースの行ごとに、誰が読み書きできるかを決める仕組み」を指す。

また、ユーザーのデータを保存する機能を作るときは、RLSによるアクセス規則が基本的な形で自動的に設定されます。規則の一覧は、画面の「More」から「Database」「Manage」「Policies」の順に開くと確認できます。

さらに、公開（Publish）の画面を開くと「クイックスキャン」が自動で走り、規則のないテーブルや、誰でも通過できる規則、使っているライブラリの既知の脆弱性などを確認します。ただし公式も、自動の設定は基本的なものであり、早い段階で見直すよう案内しています。

»出典：Lovable ドキュメント（Security overview）

【理由④】契約書類と再委託先の情報が公開されている

BusinessまたはEnterpriseプランでは、利用にDPA（データ処理契約）が含まれます。DPAには、顧客の個人データをLovableが顧客の指示に基づいて処理すること、契約期間中はSOC 2 Type IIとISO 27001を維持することなどが書かれています。

※DPAとは「サービス提供者が、顧客の個人データをどのような条件で処理するかを定める契約書」を指す。

再委託先（Lovableの業務を支える外部事業者）は、トラストセンターで44社が地域と用途つきで公開されています。主な基盤は、Google Cloud（オランダ）、AWS（ストレージ等はロンドン、AIモデル用のBedrockは米国オレゴン）、Azure AI Foundry、Supabase（既定はEU）です。

AIモデルの提供元としては、Anthropic、OpenAI、Google Vertex AIなどが並び、地域は米国と表示されています。稟議では、データがどの国の事業者に渡るかを説明する材料になります。

再委託先の追加は、一覧の更新で通知される形です。DPAでは、新しい再委託先に同意しない場合、顧客が20営業日以内に申し立てられるとされています。2026年10月2日の更新では、すでに稼働していた提供元を追加し、用途・地域・リンクの記載を訂正したと説明されています。

一方で、個人データの漏洩が起きたときの通知期限は、DPAでは「不当な遅滞なく」と書かれているだけで、時間数は示されていません。DPAが利用に含まれると明記されているのはBusinessとEnterpriseで、FreeとProでの扱いは公開ページに書かれていません。

»出典：Lovable Trust Center（Subprocessors）

---

ここまでの内容をまとめると、Lovableのセキュリティは、

といった、複数のレイヤーで構成されています。

＼特典：最適な開発方法をご提案／

Lovableで設定できる主なセキュリティ機能とは？

Lovableには、学習利用、公開前の確認、アクセス範囲、企業向けの管理機能について、利用者が決められる設定があります。プランによって使える範囲が異なるため、あわせて整理します。

① AI学習への利用を止める設定（Free・Proは自分で設定）

Lovableは、2026年9月9日以降、FreeプランとProプランの顧客データ（プロンプト、添付した画像やファイル、コード、プロジェクトのファイル、生成物）を、AIモデルの学習や改善に使う場合があると説明しています。

止めるには、アカウント設定の「Preferences」にある「AI model training」で、「Use my Lovable content for model training」をオフにします。無料で、AI機能の利用にも影響しません。

BusinessとEnterpriseのワークスペースのデータは、既定で学習から除外され、DPAでも学習利用が禁止されています。作ったアプリの利用者が入力したデータや、アカウント・請求情報も、学習には使われないとされています。

注意したいのは、オフにした時点以降のデータだけが対象で、それ以前に作られた学習データやモデルからは取り消されない点です。この設定は共有プロジェクトでも各メンバー個人ごとに決まります。

»出典：Lovable ドキュメント（Manage training data and privacy）

② 公開前のブロックとスキャン（クイックスキャン・ディープスキャン）

クイックスキャンは公開のたびに自動で走ります。さらに、アプリのコード全体を調べる「ディープスキャン」を、任意のタイミングで実行できます。スキャンの実行自体は無料です。

ディープスキャンでは、他人のデータを見られる状態、認証なしで動かせる処理、不正な入力、漏れた鍵、決済の抜け道、個人情報の露出などを調べ、結果を「Critical」「Warning」「Info」で示します。

重要なのが「Block publishing with critical issues」で、未解決のCriticalがあるアプリの公開を止める設定です。全プランで使えますが、既定は無効で、Lovableが新しく作るEnterpriseワークスペースだけ最初から有効になります。公式は、すべてのワークスペースで有効にすることを推奨しています。

「Auto-fix」を有効にすると、ビルドの依頼のたびにクイックスキャンの重大な指摘の修正も試みます。ただしクレジットを消費し、ディープスキャンの指摘は対象外です。Wiz（脆弱性スキャン）やAikido（AIによる疑似攻撃テスト）を、任意で連携することもできます。

ブロックを通過しても、安全が証明されるわけではないと公式も明記しています。

»出典：Lovable ドキュメント（Security overview）

③ プロジェクトと公開アプリのアクセス範囲（Project access・Website access）

Lovableには、独立した2つのアクセス設定があります。「Project access」は、ソースコードやチャット履歴を見られる人を決める設定で、「Website access」は、公開したURLを開ける人を決める設定です。片方を変えても、もう片方は変わりません。

2025年12月以降、すべてのワークスペースで、プロジェクトの既定のアクセスは「Workspace」（ワークスペースのメンバーだけ）です。BusinessとEnterpriseでは、オーナーと招待した人だけに絞る「Restricted」も選べますが、ワークスペースのオーナーは全プロジェクトを閲覧・編集できます。

ワークスペースの設定では、公開アプリの既定が「Anyone」（リンクを知っていれば誰でも開ける）です。BusinessとEnterpriseでは、これをワークスペースのメンバーだけに変えられます。社内向けのツールは、公開範囲を必ず確認しておきたい項目です。

このほか、誰でも見られるストレージのバケット（ファイルの保管場所）を作れなくする設定が、全プランで既定で有効です。

公式の更新履歴によると、プロジェクト自体を一般公開する「Public」の設定は廃止され、既存の公開プロジェクトはワークスペース限定に変更されています。

»出典：Lovable ドキュメント（Control project access）

④ 企業向けの管理機能（SSO・2段階認証・監査ログ・保存地域）

SSO（会社のIDでまとめてログインする仕組み）は、BusinessとEnterpriseで使えます。2段階認証の必須化と監査ログはEnterprise向けです。

データの保存地域は、BusinessとEnterpriseで、ワークスペースの既定を「Americas」「Europe」「Asia Pacific」から選べます。適用されるのは新しいプロジェクトだけで、作成済みのプロジェクトの地域は変えられません。

国を指定する地域（例：ドイツ、日本、米国東部）は、Enterpriseで要望に応じて有効にできるとされ、空き状況に左右されます。国の指定が案内されているのはEnterpriseだけで、それ以外のプランで「Asia Pacific」がどの国を指すのかは、公開ドキュメントには書かれていません。

AIモデルへのリクエストをEU内で処理する「EU inference」もEnterprise向けで、保存地域とは別の設定です。Enterpriseでは既定でゼロデータ保持のモデルだけを使い、保持を伴うモデルを有効にすると、提供元が30日以上保持する場合があります（学習には使われないとされています）。

データの保存場所と、AIが処理する場所は別の設定になっている点に注意が必要です。

SSOや監査ログが使えるプランと料金については、【2026年最新】Lovable(ラバブル)の料金プランを完全解説！で詳しくご紹介しておりますので、そちらをご覧ください。

»出典：Lovable ドキュメント（Privacy & security settings）

セキュリティが強くても情報漏洩が起きるのはなぜか？

ここまで見てきたとおり、公開情報の範囲では、Lovableは基盤、契約、管理機能が整っています。

しかし、それでも情報漏洩のリスクが完全になくなるわけではありません。

Lovable社自身も、セキュリティ機能の説明で次のように述べています。

These tools help identify common security issues, but they cannot guarantee complete security. For apps handling sensitive data or critical functionality, consider an additional professional security review.

（これらのツールは一般的なセキュリティ上の問題を見つける助けにはなるが、完全なセキュリティを保証するものではない。機密データや重要な機能を扱うアプリでは、専門家による追加のセキュリティレビューを検討すること。）

出典：Lovable公式ドキュメント（Security overview）

実際に、2025年には、Lovableで作られたアプリのデータベースのアクセス規則（RLS）の不備により、認証のない第三者がテーブルを読み書きできるとする脆弱性情報（CVE-2025-48757）が登録されました。

※CVEとは「公式に報告されたバグ（脆弱性）につける共通の識別番号」を指す。

登録先の米国NVDには、提供元が「各顧客が自分のアプリのデータを守る責任を負う」としてこの指摘に異議を唱えている旨も併記されています。DPAにも、顧客が設定や設計を安全な形で実装する責任を負うという趣旨の記載があります。

提供元が担うのは、基盤の管理と契約上の約束までです。作ったアプリのアクセス規則、鍵の置き場所、公開範囲は、利用者の側で決まります。スキャンで「問題なし」と出ても、公式は、すべてのリスクを検出できるわけではないと説明しています。

漏洩の原因は、ツールそのものよりも、設定の未確認、権限の付与、運用ルールの不在にあることがほとんどです。

データの守りの設定が抜けたまま公開されて起きた事故など、実際に起きたセキュリティ事故については、Lovableのセキュリティ事故事例4選｜対策まで完全解説でまとめておりますので、そちらをご覧ください。

»出典：NVD（CVE-2025-48757）

注意すべきポイントは何か？

Lovableを業務で使うときに、利用者がやってしまいがちな行動を4つ挙げます。

① 学習利用の設定を確認しないまま、社内の資料や顧客情報をプロンプトに入れてしまう

FreeプランとProプランでは、前述のとおり、初期設定のままだと入力内容が学習に使われる場合があります。個人のアカウントで始めたまま、業務の資料や顧客情報を入れてしまうのが典型的なパターンです。

プライバシーポリシーには、学習や改善に使う内容を、担当者が品質の確認や不具合の診断のために確認することがあるとも書かれています。

入力してよい情報の区分を社内規程で決め、業務での利用はBusiness以上のワークスペースに限る、といった運用が現実的です。

»出典：Lovable プライバシーポリシー

② RLSとスキャン結果を確認しないまま、アプリを公開してしまう

公式のベストプラクティスでは、公開前に、重要なテーブルでRLSが有効か、他のユーザーの非公開データを見られないか、新しいテーブルに規則が漏れていないかを確認するよう案内しています。RLSは、実際のデータが入る前のほうが直しやすいとも書かれています。

サーバー側のコードが特権のあるデータベースアクセスを使う場合は、RLSの対象外になるため、コード側で権限を確認する必要があります。画面側のログイン判定だけで権限を制御するのも避けるべきとされています。

Criticalの指摘が残ったままでも公開できる設定が既定である点は、前述のとおりです。

»出典：Lovable ドキュメント（Security best practices）

③ APIキーやパスワードを、ブラウザ側のコードや環境変数に置いてしまう

Lovableの公式ドキュメントによると、名前が「VITE_」で始まる環境変数は、ブラウザに埋め込まれる値です。公開されても問題ない値だけを置く場所で、秘密の値はSecretsに入れる決まりになっています。

Secretsに保存した値は、保存後に再表示できず、置き換えか削除しかできません。鍵を紛失した場合は、発行元のサービスで新しい鍵を作り直します。

鍵をチャットに貼り付けた場合は、Lovableが検知してSecretsへ誘導しますが、そもそも貼り付けない運用にしておくのが安全です。

»出典：Lovable ドキュメント（Secrets）

④ 機微な個人情報や保存地域の条件を確認しないまま、業務データを扱うアプリを作る

DPAには、利用者が機微なデータをLovableに提供しないこと、具体的にはHIPAA（米国の医療情報保護法）の対象となる医療情報、金融口座番号、政府発行の識別番号、生体情報などをアップロードや入力しないことが書かれています。

保存地域も要確認です。作成済みのプロジェクトの地域は変えられず、国の指定が案内されているのはEnterpriseだけです。社内規程や取引先との契約で保存地域に条件がある場合は、プロジェクトを作る前に、地域とAIの処理場所を確かめておく必要があります。

医療情報など標準の規約では扱えないデータを含め、Lovableでできないことは、【完全版】Lovableでできること/できないことを3分で解説！でまとめておりますので、そちらをご覧ください。

»出典：Lovable Data Processing Agreement

---

Lovableは、

といった観点から、企業利用を意識した設計がされているツールです。

しかし、

セキュリティは「ツールだけで完結するものではない」
最終的には「ユーザーの使い方」が重要になる

という点は、必ず押さえておく必要があります。

【解決策】Lovableでの開発を外注する場合は信頼性の高い会社を選ぶ

ここまで見てきた通り、Lovableの基盤は、第三者認証や契約書類が整っています。

しかし実際の開発においては、「誰がどのように使うか」によって、安全性や品質は大きく変わります。

特に外注する場合は、開発会社の選び方が、そのままセキュリティや開発品質に直結すると言っても過言ではありません。

【ポイント①】信頼できる実績があるか

まず最も重要なのが、実績の有無とその中身です。

Lovableは、文章で指示するだけでアプリの形まで作れる一方で、単にツールを使うだけでは、安全で使いやすいアプリにはつながりません。

重要なのは、

といった「使い方の設計」です。

そのため開発会社に依頼する際は、「Lovableを使っています」という表面的な説明ではなく、具体的な活用プロセスや成果事例まで確認することが重要です

特に、自社の目的に近い領域（MVP開発、業務効率化、社内ツールなど）での実績がある会社であれば、認識のズレが起きにくく、プロジェクトもスムーズに進めやすくなります。

【ポイント②】ブログやSNS、YouTubeで有益な発信がされているか

Lovableを扱う領域は、変化のスピードが非常に速い分野です。

そのため、開発会社が

などで継続的に情報発信しているかどうかは、最新の仕様変更やセキュリティ動向を追えているかの判断材料になります。

【ポイント③】問い合わせた際の対応が丁寧か

問い合わせ段階の対応は、そのままプロジェクト中のコミュニケーション品質に表れます。

Lovableのプランごとの学習利用の扱いや、RLS（アクセス規則）の確認方法について質問したときに、公式資料を根拠に答えてくれるかどうかも、確認しやすい判断材料です。

【ポイント④】サポート体制は十分か

リリース後に、セキュリティ上の問題やLovable側の仕様変更が見つかったときに、どこまで対応してもらえるかを事前に確認しておくことが重要です。

【ポイント⑤】自社特有の課題を踏まえて提案してくれるか

Lovableは強力なツールですが、「作れるから作る」という判断に陥ると失敗しやすいのも事実です。

そのため重要なのは、

といった視点で提案してくれるかどうかです。

単なる開発ではなく、

まで伴走してくれる会社であれば、スピードと事業価値の両立がしやすくなります。

---

本記事では、Lovableのセキュリティについて、安全と言える理由と、あわせて押さえておきたい注意点を解説しました。

Lovableは、第三者認証、暗号化と運用統制の公開、生成アプリを守る標準機能、契約書類と再委託先の開示など、複数の観点から安全性が考慮されたツールです。
一方で、無料・Proプランの学習利用の初期設定や、作ったアプリのアクセス規則の確認など、利用者の設定と確認で結果が変わる点も多くあります。

だからこそ、「Lovableは安全か危険か」を二択で考えるのではなく、どのような仕組みで安全性が担保されているのか、そして安全に使うために何を意識すべきかを理解した上で活用することが重要です。

この記事が、Lovableの導入や活用を検討する際の参考になれば幸いです。

Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。

AI開発×補助金支援サービスの概要はこちら＞＞

Walkersに無料で相談する＞＞