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が生成しており、誤りが含まれる場合があります。正確な情報は公式ドキュメント等でご確認ください。