Lovableのセキュリティは何が危険か？公開前RLS設定チェックリスト23項目【日本公式パートナー解説】

「Lovableは安全ですか？」——情報システム部門から必ず投げられるこの問いに、「SOC 2に対応しています」と答えるのは半分しか答えていません。

プラットフォームが安全であることと、そのプラットフォームで自社が作ったアプリが安全であることは、まったく別の問題だからです。そして実際に起きるインシデントは、ほぼ例外なく後者で発生します。もっと具体的に言えば、データベースのアクセス制御（RLS）の設定漏れです。

厄介なのは、RLSが設定されていなくてもアプリは正常に動いてしまう点です。自分のアカウントでログインすれば自分のデータが見える。テストは通る。しかし他人のアカウントからも、あるいは認証を経ずに直接APIを叩いても、同じデータが読めてしまう——この状態に気づかないまま公開されるケースが後を絶ちません。

本記事では、Lovable公式セキュリティページおよびSupabase公式のRLSドキュメントの記載に基づき、責任分界点の整理と、公開前に必ず通すべき23項目のチェックリストを提示します。

Lovableの基礎は「Lovableとは？」、操作手順は「Lovableの使い方」、CRM連携は「Lovable×HubSpot連携でできること10選」をご覧ください。

Lovableのセキュリティは2層に分かれる——どちらが自社の責任か？

プラットフォーム側が担保しているものは何か？

Lovable公式のセキュリティページに記載されている内容を整理すると、プラットフォーム側は次の範囲をカバーしています。

ここは十分な水準です。情シス審査で問われる「ベンダーの体制」については、この内容を提示すれば大半の質問に答えられます。

自社の責任範囲はどこからか？

問題はここからです。Lovableのセキュリティページは、顧客側の責任範囲を明示的に列挙していません。プラットフォームの保護について記載する構成になっており、責任共有モデルとしての整理は載っていません。

しかし現実には、次の領域は完全に自社の責任です。

• 誰がどのデータを読み書きできるかの定義（＝RLSポリシー）
• 認証の要否と、未認証時の挙動
• 外部サービス連携に使うAPIキーの置き場所と権限範囲
• 公開範囲の設定（一般公開か、社内限定か）
• 公開後の棚卸しと、不要になったアプリの停止

クラウドサービス一般の責任共有モデルとまったく同じ構図です。ベンダーは「箱」の安全を守り、中に何をどう置くかは利用者の責任。この線引きを情シスと合意しないまま導入すると、事故が起きたときに責任の所在で揉めます。

なぜ事故のほとんどがRLS設定漏れなのか？

理由は3つあります。

第一に、設定しなくてもアプリが動くから。認証もデータ表示も正常に機能するため、テストで気づけません。

第二に、AIに「ログイン機能をつけて」と頼んでも、権限設計までは指示されない限り作り込まれないから。プロンプトに書いていない要件は実装されません。これはAIの欠陥ではなく、指示の欠落です。

第三に、そもそもRLSという概念を知らずに作っているから。非エンジニアが内製する以上、これは構造的に起こります。だからこそ、知識ではなくチェックリストという形で運用に埋め込む必要があります。

RLS（行レベルセキュリティ）とは何か？

RLSは何をする仕組みか？

LovableのCloudバックエンドはSupabase経由のPostgreSQLで構成されています。RLS（Row Level Security）は、このPostgreSQLに組み込まれた認可機能です。

Supabase公式ドキュメントの説明を借りれば、RLSは「データベース内で実行される粒度の細かい認可ルール」であり、その動作はすべてのクエリに自動的にWHERE句を付与することに相当します。

重要なのは、これがアプリケーション側ではなくデータベース側で効く点です。公式が「多層防御（defense in depth）」と表現するとおり、アプリの画面を経由しない直接のAPIアクセスや、サードパーティツール経由のアクセスに対しても同じ制御が働きます。画面上で「他人のデータを表示しない」ように作るだけでは、防御になりません。

RLSを有効化しないとどうなるのか？

Supabase公式ドキュメントは明確に警告しています。「publicスキーマ内のRLSなしテーブルは、権限を持つあらゆるロールから読み書き可能」です。

具体的な帰結は次のとおりです。

• 未認証ロール（anon）に削除権があれば、全行を削除できる
• 認証済みロール（authenticated）に更新権があれば、他人のデータを変更できる

顧客ポータルや社内の人事データを扱うアプリでこれが起きた場合の影響は、説明するまでもありません。

「権限（GRANT）」と「ポリシー」は何が違うのか？

ここが最も誤解されるポイントです。両者は独立して動作します。

そして決定的な注意点として、Supabase公式は「ポリシーを追加しても、既存の付与権は自動的に削除されない」と明記しています。テーブルが保護されていない状態では、anonロールが挿入権を持っている場合があります。したがって、RLSを有効化するだけでなく、不要な付与権を明示的に取り消す手順が必要です。

-- ①RLSを有効化
alter table public.reports enable row level security;

-- ②既存の付与権を取り消す（この手順が抜けやすい）
revoke all on table public.reports from anon, authenticated;

-- ③必要な権限だけを再付与
grant select, insert, update, delete on table public.reports to authenticated;

公開前チェックリスト①：データベース設定（6項目）

ここからが本題です。以下はそのまま社内の公開フローに組み込める形で書いています。

とくに6番は見落とされがちです。「請求書PDFをアップロードできる社内ツール」で、テーブルは守られているのにファイル本体が推測可能なURLで取得できた——という構成ミスは現実に起こります。

公開前チェックリスト②：ポリシー設計（7項目）

データベースの設定が整っていても、ポリシーの中身が誤っていれば防御にはなりません。ここが本チェックリストの中核です。とくに操作ごとにポリシーを分けて考えられているかが分かれ目で、読み取りだけを設定して更新と削除を放置した状態が実務では最も多く見られます。

13番は特に重大です。「管理者フラグ」のような権限情報をユーザー編集可能なメタデータに置くと、利用者が自分を管理者に昇格させられます。ロール情報の保存先は必ず確認してください。

参考として、Supabase公式が示す推奨形は次のとおりです。

create policy "Users can update their own profile."
on profiles for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

なお auth.uid() を (select auth.uid()) と括るのは、単なる書き方の好みではありません。公式によれば、これによりPostgreSQLのオプティマイザが結果をステートメント単位でキャッシュし、行ごとの関数呼び出しを回避してパフォーマンスが向上します。

公開前チェックリスト③：シークレットと外部連携（5項目）

ここからはデータベースの外側の話になります。権限設計が正しくても、APIキーが漏れれば意味がありません。AI生成型ツールで作るアプリはフロントエンド中心の構成になりやすく、意識せずに実装すると鍵がブラウザから読める場所に置かれます。以下は外部サービスと連携する場合に必ず確認してください。

14番が実務上の最頻出リスクです。Lovableで作るアプリはフロントエンド中心の構成になりやすく、素直に実装するとキーがブラウザから読める場所に置かれます。実装をAIに依頼する時点で、プロンプトに「APIキーはサーバーサイドで扱い、クライアントコードに含めないこと」と明記してください。

公開前チェックリスト④：公開設定と運用（5項目）

最後は、公開の瞬間とその後に関する項目です。ここまでの点検をすべて通過しても、公開範囲の設定を誤れば意図しない相手にアプリが届きます。また、公開後に誰も見なくなったアプリは数年後の負債になります。作る前に決めておくべき運用ルールも含めています。

よくある設定ミスと、その症状はどう現れるか？

ロールを指定していないポリシー

ポリシーに to authenticated を書かないと、未認証ロールに対してもポリシー評価が走ります。動作としては弾かれるものの、Supabase公式はロール指定を推奨しています。指定があればポリシー実行の手前で停止するためです。

UPDATEにSELECTポリシーがない

症状は「更新ボタンを押しても何も起きない」。エラーも出ないため、UIのバグとして調査に時間を溶かしがちです。原因はポリシー設計の欠落です。

ビューでRLSがバイパスされる

テーブル本体にはRLSを設定したのに、そのテーブルを参照するビュー経由で全行が読めてしまうケース。PostgreSQL 15未満ではビューは既定でRLSをバイパスします。PostgreSQL 15以降では次の形で解決します。

create view your_view with (security_invoker = true)
as select ...;

このほか、2つのテーブルのポリシーが相互参照すると再帰エラー（42P17）が発生します。この場合は security definer 関数を挟んで回避します。

セキュリティスキャンはどこまで信用できるのか？

Lovableは公開前に基本スキャンを自動実行し（約10〜15秒）、任意で詳細スキャン（約3分）を実行できます。Business・Enterpriseではセキュリティセンターでコード分析・依存パッケージ・シークレット管理を一元管理でき、Enterpriseでは定期実行と自動修正、重大問題による公開ブロックも設定できます。

ただし、スキャンは「設計意図の正しさ」を判定できません。「このデータは全員に見せてよいのか」はビジネス上の判断であり、静的解析の守備範囲外です。スキャンが検出するのは実装上の危険信号であって、権限設計が business requirement と合っているかは人間が確認するしかありません。

したがって、スキャンは「通れば安全」ではなく「通らなければ確実に危険」という下限のフィルタとして扱ってください。加えてOWASP Top 10、API連携を伴う場合はOWASP API Security Top 10およびOWASP Authorization Cheat Sheetの観点でのレビューを組み込むことを推奨します。国内の公的資料としてはIPA「安全なウェブサイトの作り方」が実務的です。個人データを扱う場合は個人情報保護委員会のガイドラインもあわせて確認してください。

公開前に必ず行う「別アカウントテスト」とは何か？

チェックリスト20番の詳細です。これが唯一、設定漏れを実際に発見できる検証です。手順は次のとおりです。

1. テスト用アカウントを2つ作る（ユーザーA、ユーザーB）
2. ユーザーAでログインし、データを1件作成する
3. ユーザーBでログインし、Aのデータが見えないことを確認する（一覧・詳細・検索すべて）
4. ユーザーBから、AのデータのIDを直接指定してアクセスを試みる（URLのID書き換え）
5. ログアウト状態で、同じURLにアクセスして何も返らないことを確認する
6. ユーザーBから、Aのデータの更新・削除を試みて失敗することを確認する

4番と5番が肝です。画面上のリンクを辿るだけのテストでは、他人のデータへの導線がそもそも存在しないため「見えない」ように錯覚します。IDを直接書き換えてアクセスできてしまう状態は、実際の攻撃手法そのものです。

より厳密に運用するなら、Supabaseはテスト駆動での検証を推奨しています。supabase/tests/<table>_rls.test.sql を作成し、pgTAPでanon・authenticated両ロール、4操作すべてについて許可・拒否の両ケースを検証する方法です。「テストが通るまでポリシーの意図が正しいかは判断できない」——公式のこの表現は、そのまま社内ルールにする価値があります。

情報システム部門の審査を通すために何を準備すべきか？

審査で問われる論点は、概ね次の4つに集約されます。準備すべき回答をセットで整理します。

最初の3つはベンダー資料で答えられます。審査が止まるのは常に4つ目です。ここに対して「公開前チェックリストを運用フローに組み込んでいます」と実物を提示できるかどうかが、承認の可否を分けます。

逆に言えば、チェックリストと検証手順を先に整備しておけば、内製の適用範囲を広げやすくなるということです。市民開発（Citizen Developer）の推進で失敗する企業は、統制を後回しにして配布を先行させます。順序を逆にしてください。

株式会社100は、HubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援してきた知見をもとに、Lovableによる内製化のセキュリティ設計、情シス審査対応、公開フローの整備までをご支援しています。

よくある質問（FAQ）

Q1. Lovableは安全ですか？

プラットフォーム自体はSOC 2・GDPRに対応し、リージョン別のデータ所在地、テナント分離、シークレットの保存時暗号化、SAML/OIDC・SCIMなどを備えています。ただし「作ったアプリの安全性」は別問題で、こちらは自社の責任範囲です。事故の大半はRLS設定漏れで発生します。

Q2. RLSとは何ですか？

Row Level Security（行レベルセキュリティ）の略で、PostgreSQLに組み込まれた認可機能です。すべてのクエリに自動でWHERE句を付与するように働き、アプリの画面を経由しない直接アクセスに対しても効きます。LovableのCloudバックエンドはSupabase経由のPostgreSQLで構成されています。

Q3. RLSを設定しないとどうなりますか？

Supabase公式によれば「publicスキーマ内のRLSなしテーブルは、権限を持つあらゆるロールから読み書き可能」です。未認証ロールに削除権があれば全行削除が可能で、認証済みロールに更新権があれば他人のデータを変更できます。

Q4. RLSを有効化すれば安全ですか？

不十分です。ポリシーを追加しても既存の付与権は自動削除されません。RLS有効化 → 不要な付与権のrevoke → 必要な権限のみ再付与、という3段階が必要です。

Q5. 非エンジニアでもこの設定はできますか？

AIに依頼して設定させること自体は可能ですが、設定が正しいかを検証できる人がレビューすべきです。最低限、本記事の「別アカウントテスト」（URLのID直接書き換えを含む）は非エンジニアでも実施できるため、公開フローに必須手順として組み込んでください。

Q6. セキュリティスキャンを通れば公開してよいですか？

いいえ。スキャンは実装上の危険信号を検出しますが、「このデータを誰に見せてよいか」という設計意図の正しさは判定できません。「通れば安全」ではなく「通らなければ確実に危険」という下限のフィルタとして扱ってください。

Q7. 社内限定で使うなら、RLSは不要ですか？

必要です。社内限定公開はアプリへの到達を制限するもので、アプリ内での「部門をまたいだデータ閲覧」は防げません。人事データや取引先情報を扱う社内ツールでは、むしろ厳密な設計が求められます。

Q8. アップロードしたファイルも保護されますか？

テーブルのRLSとは別に、ストレージ側のアクセス制御設定が必要です。テーブルは守られているのにファイル本体が公開URLで取得できるという構成ミスは実際に起こります。チェックリスト6番を必ず確認してください。

Q9. 管理者権限のフラグはどこに保存すべきですか？

raw_app_meta_dataです。raw_user_meta_dataはユーザー自身が更新できるため、認可情報の保存先として不適切です。ここを誤ると、利用者が自分を管理者に昇格させられます。

Q10. ポリシーを設定したらアプリが遅くなりました。なぜですか？

ポリシーは行ごとに評価されるため、フィルタ列にインデックスがないと全テーブルスキャンになります。またSupabase公式は、auth.uid()を(select auth.uid())と括ることでオプティマイザが結果をキャッシュし、行ごとの関数呼び出しを回避できると説明しています。

Q11. 「更新ボタンを押しても何も起きない」のはなぜですか？

UPDATEポリシーはあるがSELECTポリシーがない、という設計漏れの典型的な症状です。公式ドキュメントにもUPDATEには対応するSELECTポリシーが必須と明記されています。

Q12. 生成したコードを自社でレビューできますか？

できます。実コードが生成され、GitHub／GitLabと双方向同期できるため、通常のコードレビュープロセスに乗せられます。マイグレーションファイルを確認すれば、RLSポリシーの実際の定義も追跡できます。

Q13. 情シス審査で最初に聞かれることは何ですか？

経験上、ベンダーの認証状況よりも「誰が作って、誰が保守し、いつ止めるのか」が焦点になります。技術的な安全性より運用体制を問われるため、公開フロー・棚卸しルール・権限管理の3点を先に文書化しておくと審査が速く進みます。

本記事の仕様は、2026年8月31日時点のLovable公式セキュリティページおよびSupabase公式ドキュメントの記載に基づきます。実装時は必ず公式ドキュメントで最新をご確認ください。本記事はセキュリティ設計の一般的な指針であり、個別システムの安全性を保証するものではありません。