Lovableの導入検討が情報システム部門に上がった瞬間、審査担当者が最初に打ち込む検索語は「Lovable 情報漏洩」です。私たちがLovableの導入を支援する際、技術検証よりも先にこの検索結果への説明を求められることが繰り返し起きています。
そして、検索して出てくるものは実在します。2025年、Lovableで生成されたアプリから個人情報が外部に露出しうる問題がCVE-2025-48757として登録され、CVSS v3.1で9.3（Critical）が付与されました。同じ年、Lovableはフィッシングサイト生成への耐性を測るベンチマークで、比較対象の中で最も低いスコアを記録しています。
ただし、この2件を「Lovableは危険なツールである」という結論に直結させると、審査は前に進みません。CVE-2025-48757は、ベンダーであるLovable自身が「異議あり（disputed）」を申し立てている、責任分界そのものが争点になった事案です。何が起き、どこまでが誰の責任で、いま何が変わっているのか。この記事では一次情報に当たって時系列で整理し、そのうえで情報システム部門の審査で確認すべき論点を提示します。
目次
公開されている事案は、性質の異なる2件です。1件目は生成されたアプリのデータベース設定に関するもの、2件目はLovable自体が悪用された不正利用に関するものです。混同されて語られがちですが、審査上の意味はまったく違います。
NVD（米国国立標準技術研究所の脆弱性データベース）に登録された記述は、次のとおりです。「2025年4月15日までのLovableにおける不十分なデータベース行レベルセキュリティ（RLS）ポリシーにより、リモートの未認証の攻撃者が、生成されたサイトの任意のデータベーステーブルを読み取りまたは書き込みできる」。
ここで言うRLS（Row Level Security／行レベルセキュリティ）は、Lovableが標準のバックエンドとして採用しているSupabase（PostgreSQL）の権限制御機構です。テーブル単位ではなく行単位で「誰がどの行を読めるか」を定義します。この定義が抜けている、あるいは緩すぎる状態でアプリを公開すると、フロントエンドの画面上は正常に見えていても、データベースのAPIエンドポイントに直接リクエストを投げれば全行が返ってきます。ブラウザに埋め込まれるanonキーは公開前提の鍵であり、これ自体が漏れることは想定内の設計です。守るのはRLS側であって、鍵の隠蔽ではありません。
重要なのは、この攻撃に認証もユーザー操作も不要だという点です。CVSS v3.1のベクトルは AV:N/AC:L/PR:N/UI:N/S:C、つまりネットワーク経由・攻撃条件は容易・権限不要・利用者の操作不要・影響範囲は当該システムを超える、と評価されています。公開されているURLさえ分かれば、専門的な道具を使わずにデータを取得できる状態でした。
発見者が公開した調査では、1,645件のLovable製プロジェクトをスキャンし、170サイト（10.3%）で計303件の脆弱なAPIエンドポイントが見つかっています。露出していた情報として、APIキー・メールアドレス・電話番号が挙げられています。この事象は、OWASP Top 10のA01「アクセス制御の不備」に分類される典型例です。
この10.3%という数字の読み方には注意が必要です。これは「Lovableを使うと10.3%の確率で漏れる」という意味ではなく、「公開前にRLSを点検する工程を持たない運用が、当時は10件に1件の割合で存在した」という意味です。私たちが公開前のチェックリストを設計しているのは、この差が運用設計で埋まる領域だからです。設定漏れの発生率は、ツールの性能ではなく公開フローの設計で決まります。
審査の場では「脆弱性があったか」よりも「ベンダーがどう対応したか」が問われます。この事案の経緯は、発見者が自身のサイトの声明で日付単位で公開しています。以下は同記述に基づく整理です。
| 日付（2025年） | 出来事 |
|---|---|
| 3月20日 | 発見者が、Lovable製サイトのデータベース露出を確認 |
| 3月21日 | Lovableへ報告。当初、問題として受け付けられなかったと発見者は記述している |
| 4月14日 | 別の技術者が同種の問題を公開の場で指摘。発見者が45日の開示期限を設定して再通知 |
| 4月15日 | NVDの記述上、この日までのバージョンが影響対象とされている |
| 4月24日 | Lovableがセキュリティスキャナーを搭載した「Lovable 2.0」を公開（公式チェンジログ） |
| 5月30日 | CVE-2025-48757としてNVDに公開 |
初報から機能提供までが約5週間、CVE公開までが約10週間です。この期間の長短の評価は審査基準によりますが、報告の受付から公表までの過程で当事者間の認識が一致していなかったことは、後述する「異議あり」の扱いに直結しています。
ここが、この事案の中心です。NVDのCVE-2025-48757の記述には、脆弱性の説明に続いて次の注記が付いています。「NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.（本件はサプライヤーにより異議が申し立てられている。Lovableプラットフォームの各顧客が、自身のアプリケーションのデータを保護する責任を引き受けているためである）」
つまりLovableの立場は「プラットフォームの欠陥ではなく、利用者が負う責任範囲の話である」というものです。実際、Lovableの公式セキュリティドキュメントには「アプリが用途に見合ったセキュリティ要件を満たしていることを確認する責任は、あなたにあります（You are responsible for ensuring that your app meets the security requirements appropriate for its use case）」と明記されています。
この構図は、クラウドの責任共有モデルと同じ形をしています。AWSの責任共有モデルやMicrosoftの責任共有モデルで、インフラの保護は事業者、その上に載せる設定とデータの保護は利用者、と切り分けられているのと同じ考え方です。
私たちが稟議資料を作る際、この点を曖昧にしたまま「ベンダーが対応済みです」と書くことはしません。書くのは、責任の線がどこに引かれていて、線の内側（自社側）を誰がどの工程で担保するのか、です。ここを空欄にした稟議は、情報システム部門の審査で必ず差し戻されます。逆に、線の内側の担保方法が書けていれば、CVEの存在自体は審査の障害になりません。
発見者は、Lovableが追加したセキュリティスキャナーについて「RLSポリシーの存在は確認するが、その内容が業務ロジックと整合しているかは検証しない」ため、誤った安心感を与えると批判しています。
この指摘は、実務上は正しく機能します。RLSポリシーが「存在する」ことと「正しい」ことは別物です。たとえば USING (true) という条件のポリシーは、構文上は有効に存在していますが、全ユーザーに全行を開放します。Supabaseのトラブルシューティング資料でも、ポリシーの記述ミスが典型的な事故要因として挙げられています。スキャナーが「RLS有効」と表示しても、それは安全性の証明にはなりません。私たちが公開前チェックで別アカウントによる実地テストを必須にしているのは、この一点のためです。公開前RLS設定チェックリスト23項目で具体的な確認手順を整理しています。
2025年4月、セキュリティ企業Guardio Labsが「VibeScamming」と題したベンチマークを公開しました。生成AIに詐欺サイトの作成を依頼したとき、どれだけ拒否できるかを測定したものです。
スコア（高いほど耐性が高い）は、ChatGPTが8.0、Claudeが4.3、Lovableが1.8でした。レポートによれば、Lovableは認証情報を保存するフィッシングページを生成したうえ、取得した認証情報・IPアドレス・タイムスタンプ・平文パスワードを閲覧できる管理画面まで出力しています。
このレポートは複数のセキュリティ媒体でも取り上げられています（The Hacker News／第三者メディアによる報道であり、Lovableの公式発表ではない点にご留意ください）。この事案は、CVE-2025-48757とは論点が異なります。自社のデータが漏れる問題ではなく、Lovableというプラットフォームが第三者の攻撃基盤として使われる問題です。自社の審査に直接効くのは前者ですが、後者にも実務的な影響があります。Lovableのホスティングドメイン（*.lovable.app）が悪用事例に登場することで、企業のセキュリティ製品側でドメイン単位のレピュテーション評価が下がり、社内からのアクセスがブロックされる可能性があるためです。
私たちが業務利用のアプリを公開する際に独自ドメインの設定を初期工程に入れているのは、この理由が大きな部分を占めます。共有ドメインのままにしておくと、自社の設定とは無関係な要因でアクセス可否が変動します。
現在のLovableに実装されているセキュリティ機能を、公式ドキュメントの記述に基づいて整理します。ここで見るべきは機能の数ではなく、どの機能が「検出」までを担い、どこから先が人間の判断に残されているかです。
| 機能 | 検査内容 | 担保できる範囲 |
|---|---|---|
| Basic scan | RLSポリシーのlint、データベーススキーマとアクセス制御のレビュー、npm依存パッケージの既知脆弱性検出 | 設定の欠落・過度に緩いルールの検出 |
| Deep scan | 上記に加え、アクセス制御レビュー、バックエンドエンドポイントの保護状況、コードレベルの脆弱性検出 | 認証欠落のエンドポイント、シークレット露出、SQLインジェクション・XSSの兆候 |
| Wiz連携（オプション） | 脆弱性およびコードセキュリティの検出 | 外部の専門製品による二重チェック |
| Aikido連携（オプション） | AIによるペネトレーションテスト | 攻撃の再現による検証 |
なお企業向けの統制機能や第三者認証の状況はLovableのセキュリティページに掲載されています。公式ドキュメントには、これらのツールは「徹底的なセキュリティレビューを置き換えるものではない」「完全なセキュリティを保証できない」と明記されています。ベンダー自身が保証していないものを、稟議で「対策済み」と書いてはいけません。書くべきは、自社の公開フローのどの工程で誰が確認するか、です。
審査で必ず出る質問がこれです。結論から言えば、RLSの設定漏れはLovable固有ではなく、Supabaseをバックエンドに使う構成すべてに共通する構造上の論点です。PostgreSQLのRLSは、テーブルに対して ALTER TABLE ... ENABLE ROW LEVEL SECURITY を明示的に実行しなければ機能しません。この「デフォルトでは無効」という仕様が、AI生成の速さと組み合わさったときに事故になります。
したがって、Lovableを避けて別のAIアプリビルダーを選んでも、同じバックエンドを使う限りこの論点は残ります。Lovable・Bolt・v0の比較で整理しているとおり、ツール選定で解決する問題ではありません。
比較の軸として意味があるのは、次の2点です。1つは、公開前の検査機能が標準で組み込まれているか。もう1つは、組織単位で公開を止められる管理機能があるか。この観点では、CVE以降のLovableは検査機能を標準搭載した側に回っています。審査で問うべきは「過去に脆弱性があったか」ではなく「いま公開を止める仕組みがあるか」です。前者はすべてのプラットフォームに該当し、選定の判断材料になりません。
ここが、海外のセキュリティ記事では触れられない部分です。RLSの設定漏れで個人データが露出した場合、日本の個人情報保護法上は報告義務の対象になり得ます。
個人情報保護委員会によれば、個人データの漏えい等が発生し個人の権利利益を害するおそれがあるときは、委員会への報告と本人への通知が義務づけられています（2022年4月1日施行）。報告対象は、①要配慮個人情報が含まれる場合、②不正利用により財産的被害が生じるおそれがある場合、③不正の目的をもって行われたおそれがある場合（①〜③は1人でも対象）、④1,000人を超える漏えい等またはそのおそれがある場合です。
報告は2段階で、速報は速やかに（おおむね3〜5日以内）、確報は発覚から30日以内（不正の目的によるおそれがある場合は60日以内）です。手続の詳細と様式は個人情報保護委員会の漏えい等対応ページに掲載されています。あわせて個人情報保護法ガイドライン（通則編）で、安全管理措置の求められる水準を確認してください。
実務上の要点は、RLS設定漏れが「④のおそれ」に該当しやすいという点です。アクセスログが残っていない状態では「漏えいしていないことの証明」ができないため、「そのおそれ」として扱わざるを得ない場面が生じます。私たちが業務アプリの設計時にアクセスログの保全を初期要件に入れているのは、事故の予防ではなく事故後の説明可能性のためです。ログがなければ、影響範囲をゼロと主張する根拠を持てません。
あわせて、IPAの「情報セキュリティ10大脅威」では、組織向け脅威として設定不備やサプライチェーンに起因する事案が継続して挙げられています。社内規程の整備状況とあわせて確認してください。クラウドサービス利用時の統制の考え方は、IPAの情報セキュリティ対策ガイドラインが参照点になります。
ここまでの内容を、審査シートに落とせる形にまとめます。ベンダーへの質問ではなく、自社の運用設計に対する質問として並べている点に注意してください。CVEの経緯が示したのは、この5点が空欄のまま公開されると事故になるということです。
この5点は、全社展開時のガバナンス設計と同じ構造をしています。セキュリティの問いと統制の問いは、実務では同一の設計に収束します。
公正に両面を整理します。私たちがLovableの公式パートナーであることを踏まえても、すべての企業・すべての用途に適するとは考えていません。
| 観点 | 導入を支持する側の事実 | 導入を慎重にすべき側の事実 |
|---|---|---|
| 脆弱性の性質 | プラットフォームのコード実行基盤ではなく、利用者側の設定に起因する。設計と手順で回避できる | 回避が利用者責任である以上、統制の弱い組織では再発する |
| ベンダーの対応 | 検査機能を標準搭載し、外部製品との連携も提供している | CVEに異議を申し立てており、責任範囲を利用者側に置く姿勢は変わっていない |
| 検出の限界 | 設定の欠落は自動検出できる | ポリシーの内容が業務ロジックと合っているかは自動検出できない |
| 他ツールとの比較 | 同じバックエンド構成のツールは同じ論点を持つ。回避は選定では達成できない | 逆に言えば、Lovableを選ぶ固有の安全性上の利点もない |
| 日本法対応 | ログ保全とデータ範囲の定義で報告義務のリスクは管理できる | 個人データを扱う用途では、この設計を省略できない |
私たちの判断基準は単純です。公開前チェックと公開権限の分離を運用に組み込めるなら導入し、組み込めないなら個人データを扱わない用途に限定します。「セキュリティが不安だから使わない」という判断は、リスクを回避しているのではなく、判断を先送りしているだけの場合が多くあります。実際には、統制のないまま個人が無償プランで業務データを入れる状態こそが最も危険です。
支援の現場で実際に使っている順序です。工程を減らすことはできますが、順序を入れ替えると意味を失います。
最初に、そのアプリが扱うデータの区分を決めます。個人データを含むか、含むなら要配慮個人情報に該当するか。ここで「含まない」に振り分けられたアプリは、以降の工程が大幅に軽くなります。逆に、この振り分けをせずに全アプリを同じ重さで審査する運用は、現場が審査を回避する動機を作ります。
次に、テーブルごとにRLSを有効化し、ポリシーを業務ロジックと1対1で対応させます。ここでスキャナーを実行しますが、合格表示は工程の完了条件にしません。完了条件は、別アカウントでログインして他人のデータが見えないことを実地で確認した記録です。
そのうえで独自ドメインを設定し、公開します。Lovableの使い方で全体の流れを、HubSpotとの連携で既存システムに接続する場合の追加要件を整理しています。CRMのデータに接続する場合は、Lovable側のRLSに加えて連携先の権限設計も点検対象になります。
Q. CVE-2025-48757は、いま修正されていますか？
NVDの記述では2025年4月15日までのバージョンが影響対象とされ、Lovableは同年4月24日にセキュリティスキャナーを搭載したバージョンを提供しています。ただしLovableはこのCVE自体に異議を申し立てており、「利用者責任の範囲である」という立場を取っています。したがって「修正済み」と単純に扱うのではなく、自社側の点検工程が必要である前提で扱ってください。
Q. 過去にLovableで作ったアプリは、いま点検すべきですか？
2025年4月より前に公開したアプリで、データベースを使っており、かつ点検記録が残っていないものは対象にしてください。確認手順は、別アカウントでログインして他人のデータが見えないかを実際に試すことです。管理画面上の「RLS有効」表示は確認になりません。
Q. 自社のアプリが影響を受けたかどうかは、どう調べますか？
アクセスログを確認します。ログを取得していなかった場合、影響がなかったことを証明する手段はありません。この状態で個人データを扱っていた場合は、漏えいの「おそれ」として社内の報告基準に照らして判断することになります。ログの保全は、事故対応の前提条件です。
Q. セキュリティスキャンで問題なしと出れば、公開してよいですか？
いいえ。スキャナーはRLSポリシーの存在と明らかに緩い設定を検出しますが、ポリシーの内容が自社の業務ロジックと合っているかは判定しません。公式ドキュメントにも「徹底的なセキュリティレビューを置き換えるものではない」と記載されています。
Q. 無償プランでも同じリスクがありますか？
リスクの性質は同じです。むしろ無償プランは情報システム部門の把握外で使われやすいため、統制上の危険度は上がります。Freeプランでできる範囲を確認し、業務データを扱う段階では有償プランと管理機能に移行してください。
Q. フィッシング悪用の件は、自社の審査に関係しますか？
直接の関係は限定的ですが、共有ドメインのまま公開すると、自社の設定とは無関係にセキュリティ製品側でブロックされる可能性があります。業務利用では独自ドメインを設定してください。
Q. 「AIが作ったコードだから危険」という指摘には、どう答えるべきですか？
この事案で問題になったのはコードの品質ではなく、データベースの権限設定です。人間が書いたコードでも同じ設定漏れは起きます。論点をコード生成の是非にずらすと、実際に必要な対策（権限設計と公開フロー）が抜け落ちます。
Q. 情報システム部門が導入に反対しています。どこから話を進めればよいですか？
反対の中身を、①データが漏れること、②把握できないアプリが増えること、③保守を引き取れないこと、のどれかに分解してください。この記事の内容は①に対応します。②③は統制設計の論点であり、全社展開の設計で扱っています。反対の中身を特定せずに安全性の説明だけを重ねても、審査は通りません。
CVE-2025-48757が示したのは、Lovableが危険なツールだということではありません。示されたのは、公開前の点検工程と公開権限の分離を持たない運用が、10件に1件の割合でデータを露出させるという事実です。そしてその工程は、ツールの選定では手に入りません。
審査で確認すべきは5点です。公開の承認者、RLS検査の手順、アクセスログの保全、扱ってよいデータの範囲、公開済みアプリの棚卸し。この5つが埋まっていれば、CVEの存在は導入の障害になりません。埋まっていなければ、どのツールを選んでも同じ事故が起きます。
株式会社100は、Lovableの日本初の公式パートナーとして、この5点の設計から公開後の棚卸しまでを日本語で支援しています。情報システム部門の審査で止まっている案件があれば、Lovable導入支援からご相談ください。
本記事のCVE情報はNVD（2026年6月17日最終更新時点）、Lovableの機能仕様は公式ドキュメント（2026年9月2日取得時点）に基づきます。仕様および料金は変更される可能性があります。