Claude Code × GitHub Actions × Playwrightで自動QA環境を作る｜Push後にテスト・E2E・回帰確認まで自動化【2026年版】

Claude Codeで機能実装が数十分で終わるようになっても、そのあと人間が毎回ブラウザを開いて「本当に動くか」を確認していたら、開発全体の速度はそこで止まります。

AI開発を次の段階へ進めるために必要なのが、実装だけではなく、テスト・E2E・失敗検知・原因調査までをつなげる仕組みです。

そこで今回作るのが、Claude Code × GitHub Actions × Playwrightを組み合わせた自動QA環境です。

コードをPushしたらGitHub Actionsが起動し、Lint・型チェック・Build・E2Eテストを実行。テストが失敗したらレポートやログを残し、Claude Codeで原因調査・修正につなげます。

Claude Codeだけでは「自動開発」にならない

Claude Codeは、コードの実装・修正・調査・Git操作などをエージェント的に進められる強力な開発ツールです。

しかし、Claude Codeがコードを書いたからといって、その実装が必ず正しいとは限りません。

一見問題なく動いていても、別ページが壊れていたり、既存機能に回帰が発生したり、スマートフォンだけレイアウトが崩れたりする可能性があります。

AIによってコードを書く速度が上がるほど、重要になるのが「正しく動いているか」をAIとは別の仕組みで判定する品質ゲートです。

GitHub Actions・Playwright・Claude Codeの役割

今回の構成では、3つのツールにそれぞれ違う役割を持たせます。

今回作る自動QA環境の全体像

基本的な流れは次の通りです。

1. 1

   Claude Codeで実装

   機能追加・バグ修正・リファクタリングなどを進めます。

2. 2

   GitHubへPush

   featureブランチやdevelopブランチへ変更をPushします。

3. 3

   GitHub Actionsが起動

   Lint・型チェック・Unit Test・Buildなどを自動実行します。

4. 4

   PlaywrightでE2E

   ブラウザを起動し、主要なユーザーフローを検証します。

5. 5

   失敗情報を保存

   HTML Report・Trace・Screenshotなどを残します。

6. 6

   Claude Codeで原因調査

   ログを確認し、問題を修正して再びQAを実行します。

まずPlaywrightを導入する

まだPlaywrightを入れていない場合は、プロジェクト内でセットアップします。

npm init playwright@latest

既存プロジェクトへ追加する場合は、プロジェクト構成に合わせて導入してください。

たとえば、次のような構成になります。

project/
├── app/
├── tests/
│   ├── login.spec.ts
│   ├── customer.spec.ts
│   └── form.spec.ts
├── playwright.config.ts
├── package.json
└── .github/
    └── workflows/
        └── qa.yml

Playwrightの設定を作る

CI環境では、ローカル開発以上にテストの再現性と安定性が重要です。

Playwright公式では、CIでは安定性を優先するためworkerを1にする構成が推奨されています。

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',
  },
});

失敗時にTraceやScreenshotを残しておけば、「どの操作のあとに、何が壊れたのか」を追いやすくなります。

GitHub ActionsでQAを自動実行する

次に、GitHub Actionsのworkflowを作ります。

.github/workflows/qa.ymlを作成します。

name: QA

on:
  pull_request:
    branches:
      - main
      - develop

  push:
    branches:
      - develop

permissions:
  contents: read

jobs:
  qa:
    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: Lint
        run: npm run lint --if-present

      - name: Typecheck
        run: npm run typecheck --if-present

      - name: Unit tests
        run: npm test --if-present

      - name: Build
        run: npm run build

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

      - name: Run Playwright tests
        run: npx playwright test

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

Pushすると何が起きる？

このworkflowを導入すると、Pull Request作成やdevelopへのPushをきっかけにQAが自動実行されます。

1. 1

   Checkout

   GitHub上のコードをCI環境へ取得します。

2. 2

   Static Check

   Lint・Typecheck・Unit Testなどを実行します。

3. 3

   Build

   アプリケーションが正常にBuildできるか確認します。

4. 4

   E2E

   Playwrightが実際のブラウザ操作を自動実行します。

5. 5

   Report

   実行結果やPlaywright Reportを保存します。

Playwrightで何をテストする？

最初からすべての画面をE2E化する必要はありません。

むしろ最初は、サービス提供・売上・顧客体験に直結する「壊れたら困るフロー」からテストする方が効果的です。

ログインをE2Eテストする例

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

test('ユーザーがログインできる', 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/);
});

本番DBでE2Eを実行しない

自動QAで特に注意したいのが、テストデータと本番データの分離です。

CRMやSaaSのE2Eを本番環境へ直接実行すると、テスト顧客・テスト案件・テスト請求などが本番データへ混入する可能性があります。

Production
├── Production DB
└── 実ユーザー

Preview / QA
├── QA DB
├── QA Tenant
├── QA User
└── Playwright E2E

Vercel Previewに対してE2Eする

ローカルBuildだけでなく、実際にデプロイされたPreview環境をPlaywrightでテストする構成も作れます。

Playwright公式では、GitHubのdeployment_statusイベントを利用し、Deploymentがsuccessになったあとに対象URLへE2Eを実行する構成例も掲載されています。

Claude Code
    ↓
Git Push
    ↓
Vercel Preview Deploy
    ↓
Deployment Success
    ↓
GitHub Actions
    ↓
Playwright E2E
    ↓
PASS / FAIL

これによって、「ローカルでは動いたが、実際のPreview環境では壊れていた」といった問題も検出しやすくなります。

Preview URLを使った実装は次の記事でさらに詳しく解説します。

CIが失敗したらClaude Codeで解析する

ここからClaude CodeをQAフローへ組み込みます。

AnthropicのClaude Code Actionでは、GitHub Actionsへのactions: read権限を付与することで、workflowの実行状態・job log・CI statusをClaudeが参照できます。

workflow側では、必要な権限を設定します。

permissions:
  contents: write
  pull-requests: write
  issues: write
  actions: read

Claude Code Action側でも追加権限を指定します。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    additional_permissions: |
      actions: read

この構成にすると、Claudeに「なぜCIが失敗した？」「Playwrightの失敗ログを調べて」といった形で原因調査を依頼できます。

テストとAIの役割を逆にしない

AI自動開発で重要なのは、Claude Code自身を「テストの正解判定役」にしないことです。

Claude Codeに修正まで任せられる？

技術的には、失敗したCIを読み、Claude Codeにコード修正まで進めさせる構成も可能です。

ただし最初から完全自動化する必要はありません。

まずは次の流れを安定させる方が安全です。

1. 1

   CIで自動テスト

   コード変更を機械的に検証します。

2. 2

   失敗情報を保存

   ログ・Trace・Screenshotなどを残します。

3. 3

   Claude Codeで解析

   CIとE2Eの失敗原因を調べます。

4. 4

   修正

   必要なコード変更を実行します。

5. 5

   再検証

   再びGitHub ActionsとPlaywrightを実行します。

GitHub Actionsの権限は最小限にする

GitHub Actionsではpermissionsを使って、workflowやjob単位でGITHUB_TOKENの権限を指定できます。

QAを実行するだけなら、まずはread中心の最小権限から始めます。

permissions:
  contents: read

Claude Code Actionなど、書き込みが必要な処理を追加するときだけ、そのworkflowに必要な権限を追加します。

特に外部ForkからのPull RequestやSecretsを扱うworkflowでは、権限の与えすぎに注意してください。

AI自動開発で重要なのは「品質ゲート」

Claude Code・Codex・Cursorなどによって、コードを書く速度は今後さらに上がっていきます。

しかし、コード生成だけ高速化しても、その後の確認作業がすべて人間のままなら、開発全体の自動化には限界があります。

AIが実装
↓
CIが検証
↓
E2Eがユーザーフローを確認
↓
失敗したらAIが調査
↓
AIが修正
↓
再検証
↓
人間が最終レビュー

このループができると、人間は毎回同じ確認を繰り返すのではなく、仕様判断・例外判断・最終承認など、より重要な部分へ集中しやすくなります。

次はVercel Previewまでつなぐ

今回の構成だけでも、コード変更後のQAはかなり自動化できます。

次のステップは、実際に発行されたVercel Preview URLを取得し、その環境に対してPlaywrightを自動実行することです。

Claude Code
↓
GitHub
↓
Vercel Preview
↓
Playwright E2E
↓
PASS / FAIL
↓
Claude Codeで原因調査・修正
↓
再検証

ここまでつながると、AIによる実装からPreview環境での検証までを、一連のパイプラインとして扱えるようになります。

出典：Anthropic Claude Code Action公式ドキュメント / GitHub Actions公式ドキュメント / Microsoft Playwright公式ドキュメント