Supabaseをはじめる
なぜ学ぶか： 「DB＋認証＋API」をひとまとめで提供してくれるのがSupabase — AIが生成する個人開発アプリのデータ層の定番です。特に重要なのが「anonキーはなぜ公開してよいのか」という問い。この答え（RLSがあるから）を理解しないまま使うのが、AI生成アプリの最も危険なパターンです。
Supabase＝DBのフルセットサービス
本物のデータベースに、認証・自動生成API・管理画面が付いてきます。無料枠で個人開発は十分始められます。
SQLを書かずに操作できる
supabase.from("posts").select()のように、SQLを直接書かずにデータを操作します（裏ではSQLに変換されます）。
anonキー＝公開前提の入場券
NEXT_PUBLIC_を付けてブラウザに置いてよい特殊なキー。「公開してよい」の根拠は次のRLS— キーは入口を示すだけで、権限は行単位で別に守られるからです。
service_roleキーは絶対秘密
もう1つの「全権キー」はRLSを無視できます。サーバー専用（無印の環境変数）で、NEXT_PUBLIC_に載せたら即事故。2つのキーの区別が要です。
コード例
// lib/supabase.ts — クライアントの作成（プロジェクトで1回だけ）import { createClient } from "@supabase/supabase-js"; export const supabase = createClient( process.env.NEXT_PUBLIC_SUPABASE_URL!, // プロジェクトの住所 process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, // 公開前提の入場券); // 使う側: SQL を書かずにデータを操作できるconst { data: posts, error } = await supabase .from("posts") .select("id, title"); if (error) console.error("取得失敗:", error.message);
anonキーがNEXT_PUBLIC_でよいのは「公開しても安全な設計（RLS）」とセットだから。service_roleキーは正反対の全権キー — 取り違えたら即事故です（仕組みは後のRLSのトピックで）。※新しめのプロジェクトでは「publishable key（sb_publishable_…）」「secret key（sb_secret_…）」という名前になっていることもあります。役割の分担は同じです。
ステップ 1 / 2
※ カリキュラムの内容はAIが生成しており、誤りが含まれる場合があります。正確な情報は公式ドキュメント等でご確認ください。