SupabaseはVibe Codingの罠だ Image: AI generated

30秒の魔法

「バックエンドを作って。」AIがSupabaseを推薦する。URLひとつでPostgreSQL、認証、ストレージ、リアルタイム購読が揃う。30秒でログインが動く。2分でCRUDが完成する。

3ヶ月後、誰もこのRLS（Row Level Security）ポリシーを誰が書いたか知らない。

AIが推薦する理由

SupabaseがVibe Codingのデフォルト選択になったのは技術的優位性のためではない。訓練データにチュートリアルが最も多いからだ。

Cursor、Bolt、v0、Lovable——どのAIコーディングツールに「バックエンドを作って」と入力してもSupabaseが出てくる。AIは最も多く見たパターンを推薦する。最良のパターンではなく。

Zhang et al.（ACL 2025）は、7つのLLMが明示的な指示なしに特定のプロバイダーを系統的に好み、入力コードを自律的に修正して好みのプロバイダーを挿入する現象を実証した。ユーザーはAIが推薦したものが最善だと信じる。AIは訓練データで最も頻繁に登場するものを推薦する。これが追従バイアスのインフラ版だ。

ブラックボックスにロジックを隠すと

Supabaseの本当の問題はSupabase自体ではない。ビジネスロジックがブラックボックスの中に入ることが問題だ。

1. RLSポリシー = 隠されたビジネスロジック

Row Level Securityは強力な機能だ。問題は、AIがRLSポリシーを生成したとき、それがどこに住むかだ。

  • コードにない。Supabaseダッシュボードにある。
  • gitにない。バージョン管理されていない。
  • テストにない。CIで検証できない。

「このテーブルに誰がアクセスできるか？」という問いの答えがコードベースに存在しない。Supabaseコンソールにログインして確認するしかない。エージェントはこれを読めない。

AIが「整理」のためにRLSポリシーを修正したら？認証が破られる。テストがないから誰も気づかない。本番環境で顧客データが漏洩してから発覚する。

これは仮説ではない。CVE-2025-48757では、Lovableで生成された170以上のアプリがRLS欠如によりSupabaseデータベース全体が露出した。303の脆弱なエンドポイントからメール、APIキー、決済情報が漏洩した。2026年1月には、AIソーシャルネットワークのMoltbookがRLS無効状態でデプロイされ、150万のAPIトークンと35,000件のメールアドレスが流出した。

2. Edge Functions = 二番目のブラックボックス

ビジネスロジックが二箇所に住んでいる。フロントエンドのコードとSupabase Edge Functions。AIはどのロジックがどこにあるかを判断しなければならない。AIはこの判断を間違える。

決済割引計算がEdge Functionにある。AIがフロントエンドをリファクタリングしながら同じ計算をフロントエンドに再実装する。割引が二重に適用される。3週間後、売上レポートで発覚する。

3. マイグレーション = 脱出コスト

Supabaseを去るには四つのものを同時に引き剥がさなければならない：

  1. Auth — Supabase AuthにバインドされたJWT構造、OAuthコールバック、セッション管理
  2. Storage — バケット構造、アクセスポリシー、URL署名
  3. Realtime — WebSocket購読、Presenceチャンネル
  4. RLSポリシー — ドキュメント化されていないビジネスルールすべて

それぞれは1日でできそうに見えるが、四つが互いに絡み合っている。Authを変えるとRLSが壊れ、RLSが壊れるとStorageアクセスが解放され、Storage URLが変わるとフロントエンドが壊れる。

これがvendor lock-inだ。入るのは30秒、出るのは3ヶ月。

ポート地獄のクラウド版

Vibe CoderがローカルでぶつかるPort地獄——AIがサーバーを立ち上げ、落とさず、ポートが混乱し、何が動いているかわからない状態——これがSupabaseではインフラレベルに上昇する。

ローカルのPort地獄：プロセスが見えない。 Supabaseの地獄：ビジネスロジックが見えない。

どちらも同じ構造だ。エージェントが作ったものをエージェントが追跡できない。

代替案は何か

Supabaseを使うなと言っているのではない。ビジネスロジックをブラックボックスに入れるなということだ。

原則：すべての決定はコードベースに存在しなければならない。

  • 認証ルール → コードで宣言し、テストで検証
  • アクセスポリシー → DDL + Regoで宣言し、CIで検証
  • ビジネスロジック → 一箇所にのみ存在し、重複なし
  • インフラ設定 → Terraform/IaCで宣言し、gitでバージョン管理

Supabaseをプロトタイピングに使うのは合理的だ。しかしプロトタイプを本番に持っていく瞬間、ブラックボックスの中のロジックを取り出して宣言的なレイヤーに移さなければならない。

30秒の魔法を3ヶ月の苦痛に変えないために。

あなたのRLSポリシーはgitにあるか？

あなたのEdge Functionにテストはあるか？

AIが「整理」しても認証が破られないと確信できるか？

Supabaseが問題ではない。見えない場所に決定を隠すことが問題だ。

関連記事

出典

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable-generated 170+ apps exposed entire Supabase DBs due to missing RLS. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API tokens + 35K emails exposed. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev