【結論】Supabase CLIとMigrationを使い、RLSをテストしてから反映する
Claude CodeとSupabaseを組み合わせる場合、SQLを直接本番へ貼り付けるのではなく、Supabase CLIでMigrationを作成し、ローカル環境でRLSと認証境界をテストしてから反映します。
匿名公開用のanon keyと、強い権限を持つservice role keyを明確に分離します。
# ターミナルでSupabase CLIプロジェクトを初期化
npx supabase init
# ターミナルでローカル環境を起動
npx supabase start
# ターミナルで新しいMigrationを作成
npx supabase migration new create_tasks具体的な手順・設定方法
要件からテーブル、外部キー、Index、監査列、削除方針、RLSポリシーを設計します。
MigrationへSQLを書き、未認証・本人・他ユーザー・管理者の各ケースをテストします。
型定義はCLIで生成し、フロントエンドでは公開可能なURLとanon keyだけを使い、service role keyはサーバー側Secret Managerで管理します。
実践プロンプト / 活用テクニック
RLSレビューを依頼する例です。
# 起動後のセッション内で入力
supabase/migrations内のtasksテーブルを確認し、ユーザーが自分の行だけSELECT、INSERT、UPDATE、DELETEできるRLS案を作成してください。
# 続けて入力
本番反映は行わず、未認証・他人・本人のテストSQLとロールバック手順を追加してください。注意点・よくあるエラーと対処法
.envやservice role keyをClaudeへ読ませないだけでなく、OS権限、Secret Manager、CIの保護変数で管理してください。
AIが生成したRLSは抜け漏れがあり得るため、Dashboard表示だけで判断せず、異なるJWTで実際にテストします。
db pushや破壊的Migrationは人間が差分を確認し、BackupとRollbackを準備してから実行します。