Lovableアプリの情報漏洩で学ぶノーコードAIツールのセキュリティ対策

Lovable製アプリで起きた情報漏洩——何が、どの規模で流出したか

2026年11月2日、X上への報告をきっかけに、AIノーコードツール「Lovable」で生成されたWebアプリから大規模な個人情報流出が明らかになった。ドイツ・ハンブルクのセキュリティ企業Crissy FieldがドイツのHandelsblatt紙と共同調査したところ、対象となったLovableプラットフォーム上のアプリ159,041件のうち、Supabaseを使用するプロジェクト34,545件のうち24,664件（71%）で、外部から即座にデータへアクセスできる状態であることが確認された（DEV Community）。流出した情報にはパスポートの番号・有効期限・国籍を含む1,000件以上のパスポート情報、200,000件以上のチャットメッセージ、1プロバイダーだけで280,000件に及ぶ顧客メールアドレス、決済情報、住所が含まれていた（DEV Community、inshorts.com）。なお、流出データの実際の悪用は調査時点で確認されていない（inshorts.com）。

個人情報が流出した状態に置かれた利用者への影響を念頭に置きつつ、この記事では「なぜ起きたか」「AIでどう防げるか」という観点から技術的背景と実務的対策を整理する。

ほかにもこうした情報漏洩は起きているのかは、日本・世界の主な被害一覧で解説しています。

関連記事AIによる情報漏洩とは？原因や経路は？

なぜノーコードAIツールでこの問題が起きやすいのか——構造的な課題

今回の漏洩の直接的な技術背景は、SupabaseのRow Level Security（RLS）の未設定にある。Supabaseはブラウザからデータベースに直接アクセスする設計を持ち、公開用のanonキーは意図的に外部へ公開される仕様だ。ただし、このキーを使ったアクセス制御はRLSの適切な設定を前提としている。LovableのAIが生成するコードはアーキテクチャパターンが均一であるため、RLS未設定という問題が159,000件超のアプリに横断的に発生した（DEV Community、pasqualepillitteri.it）。攻撃に専門知識は不要で、ChromeのDevToolsでネットワークトラフィックを確認し、anonキーを取得してデータベースクエリを発行するだけで内部データにアクセスできた状態だったとされる（DEV Community）。

重要なのは、この問題がLovable固有の欠陥というよりも、ノーコード・ローコードAIツール全般に共通する構造的リスクを象徴している点だ。コーディング知識なしでWebアプリを構築できるツールでは、生成されたコードのセキュリティ設定を開発者が自分で確認することを前提としていない場合がある。設定の漏れが何万件というスケールで均一に発生しうる——これはAIによるコード生成が持つ固有の課題であり、一般的なアクセス制御設定の見落としや、設定ミスの発見の遅れが問題の根底にある。

アクセス制御の適切な設定はアプリケーションセキュリティの基本であり、JST CRDSの「データ・コンテンツのセキュリティー」（JST CRDS S3.03）でも重要事項として整理されている。AIが生成するコードにおいても同一の原則が適用される点は変わらない。

AIを使ってノーコードアプリのセキュリティ問題を防ぐ3つのアプローチ

①未然に防ぐ——コード生成直後の自動セキュリティ検査

最も効率的な防止策は、コードが生成された直後、あるいはデプロイ前の段階でセキュリティ上の問題を検出することだ。静的コード解析（SAST）ツールをCI/CDパイプラインに組み込み、AIが生成したコードに対して自動的に実行することで、RLSポリシーの欠落、認証なしのAPIエンドポイント、ハードコードされた認証情報といったパターンを検出できる。

具体的には、Semgrepのようなパターンベースの静的解析ツールにSupabase特有のルールセットを追加し、「RLSが有効化されていないテーブルへの直接アクセス」「anonキーが露出しているコード」を自動フラグとして立てる構成が実用的だ。LLMをコードレビューに活用する場合は、「このSupabaseの設定においてRow Level Securityが正しく設定されているか」という具体的な質問形式でプロンプトを設計すると、設定漏れの指摘精度が上がる。

重要な発想の転換は、ノーコードツールが生成したコードを「確認済み」ではなく「確認が必要な草稿」として扱う運用フローを設けることだ。AIによるコード生成の速度メリットを維持しながら、セキュリティレビューというゲートを挟む構成が現実的な解になる。

②早く見つける——インフラ設定の継続的な監査

すでに稼働しているアプリに対しては、インフラ設定の継続的な監視が有効だ。クラウドセキュリティポスチャ管理（CSPM）ツールは、クラウドリソースの設定を定期的にスキャンし、公開状態になっているストレージ、過剰な権限、RLSが無効なデータベーステーブルといった設定ミスを検出する。

AIを活用した文脈では、設定項目の膨大なリストから「優先度の高い問題」を自動分類する機能が実務上の価値を持つ。すべての警告が均等に緊急なわけではなく、個人情報を含むテーブルへの非認証アクセスと、静的アセットの公開では対応優先度が異なる。LLMを活用した分類エージェントは、テーブル名・カラム名・データの種類から「このテーブルに個人情報が含まれる可能性が高い」という判断を自動で行い、アラートの優先順位付けに使える。

Supabaseを使用しているプロジェクトであれば、Supabase公式のセキュリティアドバイザー機能（ダッシュボード内に実装済み）がRLSの有効化状況を一覧表示するため、まずこの機能を使った棚卸しが最初の一歩になる。追加コストなしで即日実施できる点で、現在稼働中のアプリを持つ担当者が最優先で確認すべき手順だ。

③被害を小さくする——異常アクセスの検知と自動遮断

設定ミスが存在した場合でも、異常なアクセスパターンを早期に検知することで被害を最小化できる。APIゲートウェイやWAF（Webアプリケーションファイアウォール）にAIベースの異常検知を組み合わせると、通常の利用パターンから大きく逸脱したクエリ——短時間での大量データ取得や、通常利用では発行されないテーブルへの直接クエリ——を検知してアラートを上げたり、自動的に遮断したりすることができる。

SIEM（セキュリティ情報・イベント管理）ツールにログを集約し、異常検知ルールをAIで自動更新するアプローチも有効だ。ただし、AIによる自動遮断を導入する場合は誤検知によって正当なユーザーへのサービスが停止するリスクがあるため、自動遮断の対象とログ確認後の手動対応の対象を明確に区分した運用設計が前提になる。

この対策が特に重要な場面——日本の事業者・担当者の視点から

ノーコードAIツールによるアプリ開発は、エンジニアリソースが限られる中小企業、スタートアップ、あるいは社内の業務改善プロジェクトで急速に広がっている。開発コストと速度のメリットは明確だが、今回の事例が示すように、生成されたコードのセキュリティ品質は開発者自身が確認する必要がある。

特に影響が大きいと考えられる場面を整理する。

• 個人情報を扱う社内ツール・顧客向けサービス：会員情報、購買履歴、問い合わせ内容を扱うアプリでRLSが未設定だった場合、外部から全件取得できる状態になりうる。
• 自治体・公的機関が導入するDXツール：住民情報や申請データを扱うアプリは、設定ミス1件が大規模な個人情報漏洩につながるリスクがある。
• 医療・法務・金融分野のスタートアップ：センシティブなデータを扱う業種では、ノーコードツールで生成したアプリのセキュリティ監査を外部のペネトレーションテストと組み合わせることを検討する価値がある。

いずれの場面にも共通するのは、「ツールが生成したコードは安全である」という前提を置かないことだ。Lovableの事案が示したのは、AIが生成するコードのアーキテクチャパターンが均一であるがゆえに、設定ミスも均一・大規模に発生しうるという点であり、これはノーコード開発を採用するすべての組織に当てはまる構造的課題だ（DEV Community、pasqualepillitteri.it）。

AIセキュリティ対策の注意点と限界

AIを使ったセキュリティ対策には明確な限界と留意点がある。

AIセキュリティ対策の有効範囲と限界

項目	AIが得意なこと	AIだけでは解決しないこと
設定ミスの検出	既知パターンの大量・高速スキャン	未知のアーキテクチャ固有の脆弱性
アラートの優先順位付け	データの種類・文脈から重要度を分類	ビジネス上の許容リスクの判断
異常検知	通常パターンからの統計的逸脱を検出	意図的な低速・分散アクセスの見落とし
コードレビュー支援	RLS・認証設定の有無を機械的にチェック	ロジックの設計上の欠陥・仕様の誤り
対応・修正	修正コードの候補を提示	最終的な適用判断・テスト・責任の所在

特に重要な3点を挙げる。

最終判断は人が行う：AIが「問題なし」と判定した設定でも、実際のビジネスロジックや利用文脈に照らした判断は人間が担う必要がある。AIによる自動承認をセキュリティの最終ゲートにすることは避けなければならない。

誤検知・見逃しは必ず発生する：静的解析ツールやLLMベースのレビューは既知のパターンに対して高い検出率を持つが、新しいライブラリや独自のアーキテクチャでは見逃しが生じる。ツールの組み合わせと定期的な手動監査を併用する運用が現実的だ。

監視ログ自体が個人情報を含む：アクセスログや異常検知のためにユーザー行動を記録する場合、そのログ自体が個人情報保護法やGDPRの対象になりうる。監視の仕組みを設計する段階から、ログの保存期間・アクセス権限・廃棄手順を定める必要がある。

AIで全てのセキュリティ問題を防げるわけではない。技術的な自動化は「確認の漏れを減らす補助」であり、セキュリティ設計・運用の責任は依然として人と組織が負う。

明日から試せる実務的な一歩

大掛かりなツール導入よりも先に、現在稼働中のノーコードAIツール製アプリに対して次のチェックを実施することを勧める。

Supabase使用プロジェクトの場合：ダッシュボード上の「Security Advisor」機能にアクセスし、RLSが無効化されているテーブルの一覧を確認する。これは追加コストなしで即日実施できる最初の棚卸しだ。

アプリ全般の場合：LLM（ChatGPTやClaude等）に生成済みのデータベーススキーマと接続設定コードを貼り付け、「このコードでアクセス制御の設定漏れがないか、特に認証なしで読み取れるテーブルやAPIエンドポイントがないか確認してほしい」と依頼する。ゼロコストで実施できる一次チェックとして有効だが、LLMの出力は完全ではないため「見落としを減らすための補助」として扱う。機密情報そのものをLLMに入力しないよう注意することも必須だ。

開発フロー上の対策：今後ノーコードAIツールで新規アプリを作成する場合、デプロイ前のチェックリストに「RLS有効化の確認」「APIキーの公開範囲の確認」を明示的に加える。チェックリスト自体をLLMに作成させることも可能で、「SupabaseとLovableを使ったWebアプリのデプロイ前セキュリティチェックリストを作成してほしい」というプロンプトで実用的な叩き台が得られる。

AIが設定を均一に生成するなら、その設定をAIで検証するサイクルを組み込むことが、ノーコード開発の次の標準的な運用になると考えられる。今回の事案が示したスケールの問題——1つのパターンの欠落が24,664件のアプリに横断的に波及するという現実——は、手作業による確認では対応が追いつかないことを明確にした。AIによる自動検証を開発フローに組み込む動機として、これ以上わかりやすい事例はない。

参考文献

• DEV Community https://dev.to/yashvikothari/lovable-data-leak-2026-24664-ai-apps-exposed-80000-user-records-via-supabase-2l7a
• inshorts.com https://inshorts.com/en/news/lovable-built-apps-expose-payment-details–passport-data—2-lakh-chats-online-1793717035907
• pasqualepillitteri.it https://pasqualepillitteri.it/en/news/29806/lovable-apps-leak-passport-data
• JST CRDS https://www.jst.go.jp/crds/pdf/CRDS-FR-S/CRDS-FR-S303-202601.pdf