Claude Code × Vercel Preview × Playwrightで自動E2E環境を作る｜Preview公開後に本番前QAを自動化【2026年版】

Claude Codeでコードを書き、GitHubへPushし、GitHub Actionsでテストする。

ここまででも開発はかなり自動化できます。

しかし、本番に近い状態で本当に動くかを確認するなら、もう一段先があります。

それが、Vercelに実際にデプロイされたPreview環境へPlaywrightを実行する自動E2Eです。

Pull RequestごとにVercel Previewを発行し、デプロイ成功後にPreview URLを取得。そのURLをPlaywrightへ渡し、ログイン・フォーム送信・主要画面・回帰確認まで自動でテストします。

なぜローカルE2Eだけでは足りないのか

前の記事では、GitHub ActionsとPlaywrightを組み合わせ、PushやPull Request後にE2Eを実行する方法を紹介しました。

ただし、CI環境内で起動したアプリに対するテストと、実際にVercelへデプロイされたアプリに対するテストは完全に同じではありません。

たとえばPreview環境では、次のような問題が初めて表面化することがあります。

つまり、Buildできることと、デプロイ後にサービスとして正常に使えることは別です。

今回作るPreview自動QAの全体像

1. 1

   Claude Codeで実装

   featureブランチ上で機能追加や修正を進めます。

2. 2

   GitHubへPush

   Pull Requestを作成し、変更内容をGitHubへ送ります。

3. 3

   Vercel Previewを生成

   Pull Requestに紐づくPreview Deploymentが作成されます。

4. 4

   Preview URLを取得

   デプロイ成功後、そのPreview環境のURLをテストへ渡します。

5. 5

   Playwright E2E

   Preview上で主要ユーザーフローを実際にテストします。

6. 6

   Claude Codeで修正

   失敗した場合はログやTraceを確認して修正します。

Vercel Previewとは

Vercelでは、GitHubなどのGitリポジトリと連携すると、ブランチやPull Requestの変更に応じてPreview Deploymentを作成できます。

Productionへ反映する前に、実際のURLで変更内容を確認できるのがPreview環境の大きなメリットです。

一般的な開発では、人間がPreview URLを開き、画面を確認してからマージします。

今回やるのは、その確認の一部をPlaywrightへ任せるという考え方です。

Pull Request
↓
Vercel Preview
↓
Preview URL
↓
Playwright
↓
PASS / FAIL
↓
Human Review
↓
Merge

deployment_statusを使ってデプロイ後にテストする

重要なのは、GitHubへPushされた直後ではなく、Vercel Previewのデプロイが完了してからPlaywrightを動かすことです。

GitHub ActionsではDeployment Statusの変化をトリガーにworkflowを起動する構成を取れます。

考え方は次の通りです。

on:
  deployment_status:

そして、Deploymentが成功した場合だけE2Eを実行します。

if: github.event.deployment_status.state == 'success'

Preview URLへPlaywrightを実行するworkflow

基本構成は次のようになります。

name: Preview E2E

on:
  deployment_status:

permissions:
  contents: read

jobs:
  e2e:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    timeout-minutes: 60

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Node
        uses: actions/setup-node@v6
        with:
          node-version: lts/*
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright
        run: npx playwright install --with-deps

      - name: Run Preview E2E
        run: npx playwright test
        env:
          PLAYWRIGHT_TEST_BASE_URL: ${{ github.event.deployment_status.target_url }}

      - name: Upload Playwright report
        if: ${{ !cancelled() }}
        uses: actions/upload-artifact@v5
        with:
          name: preview-playwright-report
          path: playwright-report/
          retention-days: 30

Playwright側はbaseURLを環境変数化する

Preview URLはデプロイごとに変化するため、テストコードへURLを直接書かない方が扱いやすくなります。

playwright.config.tsで環境変数を読み取ります。

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',

  workers: process.env.CI ? 1 : undefined,

  retries: process.env.CI ? 2 : 0,

  reporter: [
    ['html', { open: 'never' }]
  ],

  use: {
    baseURL:
      process.env.PLAYWRIGHT_TEST_BASE_URL ||
      'http://localhost:3000',

    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
  },
});

テスト側ではURLを意識せず、相対パスを利用できます。

import { test, expect } from '@playwright/test';

test('Preview環境でログインできる', async ({ page }) => {
  await page.goto('/login');

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

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

  await page.getByRole('button', {
    name: 'ログイン'
  }).click();

  await expect(page).toHaveURL(/dashboard/);
});

Preview E2Eで何を確認する？

PreviewでのE2Eは、細かいUIのすべてをテストするより、まずサービスの主要ルートが壊れていないことを確認するのがおすすめです。

QA専用ユーザーを用意する

Playwrightでログインテストを行うなら、E2E専用のユーザーを用意します。

普段利用している管理者アカウントをCIへ渡すのは避けた方が安全です。

Production
├── Production DB
├── Production User
└── 実データ

Preview
├── Preview / QA DB
├── QA Tenant
├── QA User
└── Playwright Test Data

本番DBとPreviewを絶対に混ぜない

Preview環境自体が分かれていても、接続しているDatabaseがProductionと同じなら安全とは言えません。

Playwrightがフォーム送信やデータ作成を行えば、そのテストデータが本番DBへ保存される可能性があるためです。

特にメール送信・通知・決済などの副作用がある処理は、QA環境では無効化するか、テスト専用の接続先へ向けます。

Preview Protectionがある場合はどうする？

Vercelの設定によっては、Preview Deploymentが一般公開されず、認証やDeployment Protectionの対象になる場合があります。

その場合、GitHub Actions上のPlaywrightから直接アクセスすると、アプリ画面ではなく認証画面へ到達することがあります。

このケースでは、組織・プラン・Protection設定に合わせて、CIが安全にPreviewへアクセスできる方法を設計する必要があります。

失敗時はPlaywright ReportとTraceを残す

自動テストは、失敗したことだけ分かっても十分ではありません。

重要なのは「なぜ失敗したか」を後から追えることです。

失敗したらClaude Codeへ調査させる

Preview E2Eで失敗が検知されたら、次はClaude Codeを使って原因を調べます。

見るべき情報は、主に次の4つです。

単に「テストを直して」と渡すのではなく、

Preview E2Eが失敗しています。

以下を確認してください。

1. GitHub Actionsの失敗ログ
2. Playwrightの失敗テスト
3. 今回のgit diff
4. 既存機能への回帰可能性

そのうえで、

原因調査
↓
最小修正
↓
関連テスト
↓
E2E再実行
↓
diff report

まで進めてください。

テストを通すためだけに
検証条件を弱める変更は禁止です。

のように、QAの基準を落とさず原因から直すよう指示する方が安全です。

テストを通すためにテストを弱くしない

AIに失敗修正を任せるとき、非常に重要なのがこの考え方です。

テストが失敗したからといって、

• assertを削除する
• timeoutを極端に伸ばす
• 失敗しているテストをskipする
• 条件を緩めてPASSさせる

だけでは、本当の意味で問題は解決していません。

Productionへ進める条件を決める

Preview E2Eを導入したら、「Productionへマージしてよい条件」も明確にしておくと運用しやすくなります。

この状態まで作れると、「なんとなく動いていそうだからmainへ入れる」という開発からかなり離れられます。

AI開発ではPreview環境の価値がさらに高くなる

人間が1日に数回コードを変更する開発では、手動QAでも運用できるケースがあります。

しかし、AIエージェントが短時間に何度も実装・修正を繰り返すようになると、人間が毎回そのすべてをチェックするのは難しくなります。

そのとき重要なのが、

AIが実装
↓
Previewを自動生成
↓
E2Eで検証
↓
失敗
↓
AIが原因調査
↓
修正
↓
新しいPreview
↓
E2E再検証
↓
人間が最終承認

というループです。

最終的に目指す自動開発パイプライン

ここまでをつなぐと、自動開発環境は次のようになります。

Issue / Specification
↓
Claude Code
↓
Feature Branch
↓
GitHub
↓
Vercel Preview
↓
GitHub Actions
↓
Playwright E2E
↓
PASS ─────────→ Human Review → Merge
↓
FAIL
↓
Claude Code
↓
原因調査
↓
最小修正
↓
再Preview
↓
再E2E

ここまで来ると、Claude Codeは単なる「コードを書くAI」ではなく、検証環境の中で何度も実装・修正を繰り返せる開発エージェントとして使えるようになります。

次はQA専用DBまで自動化する

Preview環境でE2Eが動くようになったら、次に考えたいのがQAデータベースの自動管理です。

Previewが作られたらQA用DBを用意し、Seedデータを投入してPlaywrightを実行。テスト終了後は不要なデータを消す。

ここまでできれば、さらに再現性の高いQA環境へ進められます。

出典：Vercel公式ドキュメント / GitHub Actions公式ドキュメント / Microsoft Playwright公式ドキュメント