Claude Code × SupabaseでQA専用DBを作る｜Previewごとにテストデータを分離して安全にE2Eする【2026年版】

Vercel PreviewにPlaywrightを接続できても、接続先のデータベースがProductionと同じなら、安全なQA環境とは言えません。

E2Eテストでは、ログイン・顧客登録・フォーム送信・データ更新など、実際にデータを書き換える操作を行います。

そのため本番DBへ接続したまま自動テストすると、テスト顧客・テスト案件・テスト請求などが実データへ混ざる可能性があります。

そこで今回作るのが、Claude Code × Supabase Branching × Vercel Preview × Playwrightを組み合わせたQA専用データ環境です。

Preview環境だけ分けても安全とは限らない

Vercel Previewは、本番反映前にアプリケーションを実際のURLで確認できる非常に便利な仕組みです。

しかし、画面だけPreviewになっていても、環境変数のDATABASE_URLがProduction DBを向いていたら、アプリが操作するデータは本番と同じです。

たとえばPlaywrightが自動で次の処理をしたとします。

これらがProductionへ向いていれば、自動テストが実データを直接変更してしまいます。

Supabase Branchingとは

Supabase Branchingを使うと、GitブランチやPull Requestに対応したPreview環境を作成できます。

Preview Branchごとに独立したDatabaseやAPI環境を持たせることができるため、Productionへ影響を与えずにschema変更・テストデータ・Auth設定などを検証できます。

理想のQA環境構成

Production
├── Production App
├── Production DB
├── Production Auth
├── Production Storage
└── 実ユーザー / 実データ

Preview / QA
├── Vercel Preview
├── Supabase Preview Branch
│   ├── QA Database
│   ├── QA Auth
│   └── QA Storage
├── QA Tenant
├── QA User
├── Seed Data
└── Playwright E2E

ポイントは、Playwrightが触る対象をすべてQA側へ閉じ込めることです。

SchemaはMigrationで管理する

QA環境を再現可能にするためには、Database schemaを人の記憶やDashboard操作だけで管理しないことが重要です。

SupabaseではMigrationファイルを使ってschema変更をコードとして管理できます。

supabase migration new add_customer_status

Migrationファイルにschema変更を書きます。

alter table public.customers
add column status text default 'active';

ローカル環境ではresetして、Migrationを最初から再実行できます。

supabase db reset

この状態を作ることで、「新しいQA環境をゼロから作っても、同じschemaになる」状態を目指します。

テストデータはseed.sqlで管理する

Schemaだけ作っても、E2Eに必要なデータが存在しなければテストできません。

そこで、QA用の初期データをsupabase/seed.sqlへ定義します。

insert into public.tenants (
  id,
  name,
  slug
)
values (
  '00000000-0000-0000-0000-000000000001',
  'QA Tenant',
  'qa'
);

insert into public.customers (
  tenant_id,
  name,
  email
)
values (
  '00000000-0000-0000-0000-000000000001',
  'QA Customer',
  'qa-customer@example.test'
);

こうしておけば、QA環境を作り直しても同じ初期状態からテストを開始できます。

QA Tenantを固定しておく

マルチテナントSaaSでは、テスト対象をQA専用Tenantへ固定しておくと安全です。

たとえばPlaywrightが作成する顧客・案件・タスクは、すべてqa Tenantの中だけに作成します。

QA Userの認証情報はSecretsで管理する

Playwrightからログインする場合でも、パスワードをRepositoryへ直接書くのは避けます。

GitHub ActionsのSecretsなどから環境変数として渡します。

env:
  QA_EMAIL: ${{ secrets.QA_EMAIL }}
  QA_PASSWORD: ${{ secrets.QA_PASSWORD }}

そしてPlaywright側で読み込みます。

await page.getByLabel('メールアドレス').fill(
  process.env.QA_EMAIL || ''
);

await page.getByLabel('パスワード').fill(
  process.env.QA_PASSWORD || ''
);

Supabase Preview BranchをGitHubと連携する

SupabaseのGitHub IntegrationでAutomatic Branchingを有効にすると、GitHub側のbranchに対応するSupabase Branchを作る構成が取れます。

Preview BranchのDatabase schemaは、Repositoryに保存されたMigrationから構築されます。

本番Databaseの実データをそのままコピーするのではなく、Seedとして明示したテストデータだけを使う構成にできるのが大きなポイントです。

Feature Branch
↓
Pull Request
↓
Supabase Preview Branch
↓
Migrations
↓
Seed Data
↓
QA Database Ready

Preview BranchはProductionから分離される

Supabase Branchでは、それぞれのbranchが独立した環境として扱われます。

そのためPreview側でテストデータを作成・削除しても、Production側のデータへ直接影響しない構成を作れます。

Vercel PreviewとSupabase Branchをつなぐ

ここまでできたら、Vercel Preview側も対応するSupabase Preview Branchを使うようにします。

理想的な流れは次の通りです。

GitHub PR
   ↓
┌────────────────────────────┐
│ Supabase Preview Branch    │
│ QA DB / Auth / Seed Data   │
└────────────────────────────┘
   ↓
Environment Variables
   ↓
┌────────────────────────────┐
│ Vercel Preview             │
│ Preview Application        │
└────────────────────────────┘
   ↓
Playwright E2E

SupabaseとVercelのBranching Integrationを利用する場合、Git branchに対応したSupabase Preview Branchの環境変数をVercel Previewへ同期する構成も利用できます。

環境変数を確認する

Previewで特に確認したいのが、Database・API・Authの接続先です。

メール・通知・決済はQAでは無効化する

Databaseを分離しても、外部への副作用がProductionと同じなら事故につながる可能性があります。

たとえばQAテストでフォームを送信しただけなのに、実際の顧客や営業担当へ通知メールが届くような状態は避けるべきです。

QA環境を何度でも作り直せる状態にする

理想は、QA環境を長期間手作業で維持することではありません。

必要になったら作り、壊れたら捨て、またMigrationとSeedから再生成できる状態です。

Migration
+
Seed Data
+
Environment Config
       ↓
Fresh QA Environment
       ↓
Playwright E2E
       ↓
Destroy / Reset
       ↓
Recreate

この設計にすると、「QA環境だけ誰かが手作業で直したため、他の環境では再現できない」という状態を減らせます。

Claude CodeにQA環境の整合性も確認させる

Claude Codeには、アプリコードだけでなくMigration・Seed・E2Eの差分もまとめて確認させることができます。

今回の変更について以下を確認してください。

1. Prisma / Supabase migration
2. QA seed data
3. Preview環境変数
4. Playwright E2E
5. Productionへの副作用

問題がある場合は、

原因調査
↓
最小修正
↓
migration validation
↓
seed validation
↓
E2E
↓
diff report

まで進めてください。

Production DB・本番メール・本番通知・
本番決済への接続は禁止です。

Preview Branchのコストにも注意する

Preview Branchは便利ですが、それぞれが独立したSupabase環境としてリソースを利用します。

不要なbranchを大量に残し続けるより、Pull Requestが終わったら削除するなど、運用ルールを決めておく方が扱いやすくなります。

AI自動開発とQA DBは相性がいい

AIエージェントは、人間より短時間で大量の変更を試せます。

一方で、そのたびにProduction DBへ影響する可能性があれば、自動化できる範囲は大きく制限されます。

そこで、

Claude Code
↓
Feature Branch
↓
Supabase Preview Branch
↓
Vercel Preview
↓
Seed Data
↓
Playwright E2E
↓
FAIL
↓
Claude Codeが修正
↓
QA環境で再検証
↓
PASS
↓
Human Review

という環境を作れば、AIがProductionから隔離された場所で何度も試行錯誤できるようになります。

Productionへ進める品質ゲート

次はテスト失敗をClaude Codeに自動修正させる

ここまでで、

実装 → Preview → QA DB → E2E

までがつながりました。

次の段階は、PlaywrightやCIが失敗したときに、その失敗情報をClaude Codeへ渡し、原因調査・修正・再テストまで自動化することです。

これができると、AI開発はさらに「人間が毎回指示する開発」から離れていきます。

出典：Supabase公式ドキュメント / Vercel・Supabase Branching Integration公式ドキュメント / GitHub Actions公式ドキュメント