Lovable は本番運用に安全か：アクセス制御レビューの問題

TL;DR: Lovableは、非開発者が本物の、収益化可能なフルスタックアプリを公開する最速級の手段だ。危険は具体的で、説明できる。ユーザーのデータを誰が読めるかを決めるアクセス制御は、Supabaseの行レベルセキュリティ(RLS)SQLとして生成される——AIによって、定義上SQLを読めない人のために——そして using (true) のようなパターンは、セキュリティポリシーのように見えるのに、何も守っていない。デモを正しく振る舞わせるフロントエンドのフィルタ .eq('owner', user.id) は、リクエストの便宜であって、セキュリティ境界ではない。「動く」と「安全」は別々の主張であり、公開する当人はそれを区別できない。

失敗の正確な形を見せよう。「vibe codingは危険だ」では役に立たず、具体が全てだからだ。

ある創業者がユーザーアカウントを持つアプリを説明する。Lovableがそれを構築し、Supabaseを配線し、公開する。各ユーザーは自分のレコードしか見えない。創業者は2つのアカウントでテストする。完璧に振る舞う。デモにおいては、正しい。

では、ブラウザのネットワークタブ——非開発者が決して開かないもの——を開いて、アプリが実際に送るリクエストを見てみよう。

// フロントエンドはクエリを現在のユーザーに「絞り込む」:
const { data } = await supabase
  .from('customers')
  .select('*')
  .eq('owner', user.id)   // セキュリティ境界のように見える。だが違う。

この .eq('owner', user.id) はフィルタだ——リクエストのパラメータにすぎない。誰でもネットワークタブを開き、エンドポイントをコピーし、フィルタなしで再送できる。全員の行を取得されるのを止めるはずなのは、テーブルにかかった行レベルセキュリティのポリシーだ。危険な生成パターンの代表は次のものだ。

-- 境界であるはずの RLS ポリシー:
create policy "Enable read access for all users"
  on public.customers for select
  using (true);          -- ← すべての行、すべての呼び出し元に対して true になる

using (true) は次を意味する。認証されたすべての呼び出し元が、すべての行を読める。 ポリシーは存在する。有効になっている。そして何も守っていない。アプリが安全なのは、ちょうど1つの構成——フロントエンドがたまたまリクエストするもの——においてだけで、誰かが違う要求をした瞬間に大きく開け放たれる。CVE-2025-48757 のような事例が示すのは、この失敗が抽象的な懸念ではなく、生成アプリのアクセス制御で実際に起こりうるということだ。

フィルタは境界ではない

これが概念のすべてであり、名前を与えるに値する。一度見えれば、もう見えなくすることはできないからだ。フィルタはリクエストの便宜であり、境界はリクエストに関係なくサーバー側で強制される。 デモが動くのはフィルタのおかげだ。データが安全なのは境界がある場合だけだ。両者は外からは区別がつかない——どちらも2つのテストアカウントに正しいものを見せる——まさにそれゆえに、非開発者はアプリを使うだけでは安全なアプリと露出したアプリを見分けられない。

Lovableがアプリを構築する力を与える人は、製品自身の設計によって、using (true) と本物の using (auth.uid() = owner) の違いを読む装備が最も乏しい人だ。能力と理解が引き離されてしまった。その分離こそが、製品の魔法であり、同じ一筆でその負債でもある。

当然の反論を解体する——「Lovableはセキュリティスキャナを追加した」

Lovableの名誉のために言えば、この批判は届き、彼らは応えた——セキュリティスキャナ、SSOと監査ログを備えたエンタープライズ層だ。だから公正な問いはこうだ。それで解決しないのか?

スキャナが何を確認でき、何を確認できないかを見てほしい。報告された挙動によれば、それはテーブルにRLSポリシーが存在することを検証する——そして using (true) は存在するポリシーだ。何も強制していないのに「ポリシーが存在する」を合格にする。存在の確認は機械的だ。有効性の確認——このポリシーは誰が何を読むかを実際に制約しているか——には、データモデルを理解し、あらゆるアクセス経路を推論することが要る。それはまさに、ツールがユーザーに省かせるために存在する専門的判断だ。スキャナは、製品が取り除いた理解を供給できない。理解が安全そうに取り除かれたことを確認できるだけだ。

そしてエンタープライズの統制——SSO、組織の監査ログ——が司るのは人がどうLovableにログインするかであって、AIがあなたのアプリにどんなRLSを書いたかではない。それらは本物で、良いもので、直交している。穴はLovableのエンタープライズ姿勢ではない。AIが生成するアプリごとのアクセスロジックが、それに責任を負う唯一の人間にとって読めないことだ。

漏洩を説明する数字——検証の非対称性

このパターンを不運ではなく不可避にする数字がこれだ。2つのコストを比べてほしい。

構築のコスト(アプリを作る):一文。設計上、実質ゼロ——それこそが売り文句のすべてだ。
検証のコスト(安全だと確かめる):テーブルごとに生成されたRLSを読み、APIの経路ごとに推論し、フィルタと境界を区別する。専門家の時間、そして作り手が持っていないスキル。

構築コストがゼロに崩れる一方で検証コストが専門家の時間のままなら、非専門家の合理的な行動は検証を飛ばすことだ——できないし、アプリは完成しているように見えるからだ。これを集団全体に掛け合わせれば、漏洩は偶然の一件ではなく、繰り返し現れる故障モードになる。読めないアクセス制御を非専門家に生成させる、あらゆるツールにおいて、検証の非対称性は規模で効いてくる。

Lovableがまさに正しい場面——そして正直な但し書き

プロトタイプ、ランディングページ、ハッカソンの作品、社内の使い捨て、資金調達のデモ——実在の人物のデータがアプリの背後に座っていないあらゆる場面で、Lovableは抜群で、ほぼ確実に、もっと規律のあるどんなもの(我々を含む)よりも速い。露出するものが何もなければ、検証の非対称性は何のコストも生まない。使えばいいし、楽しめばいい。

そして、これを中傷記事にしないための正直な但し書き。これは構造的であって、Lovableの欠陥ではない。非専門家の構築コストを崩しつつ検証を専門家コストのまま残すツールはどれも、同じ非対称性を受け継ぐ——そしてLovableはそれを狭めようと積極的に取り組んでいる。要点は「Lovableが悪い」ではない。本番データに関しては、「作り手がアクセス制御を読めない」ことは、ビルダーに誰のロゴが付いていようと失格だ、ということだ。

線ははっきりしている。実在の人々のデータがその背後で生きる瞬間——顧客、患者、従業員——「動く」は何の証拠でもなくなり、「境界が見えない」は便宜ではなくなってリスクになる。

30秒でできるテスト

機能一覧は忘れよう。公開した本人にこう尋ねてほしい。

「ネットワークタブを開いて、データのリクエストを取り、フィルタを外して送ってみて。返ってくるのは自分の行だけ——それとも全員の?」

そのテストを実行できないか、理解できないか、答えが「全員の」なら、そのアプリは美しいプロトタイプであって本番システムではない——どれほど洗練されて見えようと、スキャナがチェックマークを付けようと。

ObjectStackの立場

ObjectStackは、漏洩を引き起こす分離を反転させる。アクセス制御は、作り手が読めない生成SQLではない。宣言された、読めるメタデータだ——オブジェクトのプロパティとしての read: owner == current_user——そしてランタイムがサーバー側で強制する境界であり、フロントエンドのフィルタを外しても何も変わらない。AIが誰が何を読めるかの変更を提案すると、それは非専門家が実際に承認できるdiffとして現れる(「これで customers が全員に読める状態になります——確認しますか?」)。SQLを読まねば気づけなかったであろう、沈黙の using (true) としては決して現れない。そしてセルフホスト可能で、あなたがすでに動かしているシステムの上に乗るので、機微なデータが、あなたが点検できない場所へひそかに着地することはない。

我々は最初のデモまでの時間でLovableに勝つことはないし、プロトタイプでは勝とうともしない。主張は、実データが関わった瞬間に効いてくるものだ。AIが作ったアプリのセキュリティは、それに責任を負う人に見えていなければならない——なぜなら、境界が見えないアプリは安全ではなく、まだ厳しい形で試されていないだけだからだ。