◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/Claude Code
⟐ Claude Code/2026-03-28上級

Claude Code × Playwright で E2E テストを本番運用に乗せる — 落とし穴と導入の判断基準

Claude Code と Playwright を組み合わせて E2E テストを本番運用するための実装パターンと、導入効果の測り方。Cloudflare Workers/Pages preview deployment 下での落とし穴と、個人開発者がテストを導入する判断基準まで踏み込んで解説します。

playwrighte2e-testingautomation55claude-code132testing5

✦ プレミアム記事

個人で複数のアプリを長く運営してきた中で、何度も同じ後悔をしてきました。「リリース前に E2E テストを書いておけば、この本番障害は防げた」というやつです。とはいえ、テストコードの記述と保守は重く、私のような個人開発者がプロダクションコードと同等の工数を割くのは現実的ではありません。

そんな中で、Claude Code を Playwright と組み合わせ始めてから、ようやく E2E テストが「コストではなく投資」として回り始めました。本稿は、この構成を段階的に展開するときに見ておきたい指標と、公式ドキュメントには書かれていなかった落とし穴を整理したものです。

最初に結論を共有しておきます。導入から90日で計測できた変化は次の3つです。

  • フレーキーテスト率: 15.3% → 0.42% (収束値)
  • Page Object クラスの新規生成時間: 約4時間 → 約18分 (1ファイル当たり、約13倍)
  • 月あたりの「本番デプロイ前に止められた」障害: 0件 → 7件 (4ヶ月平均)

この数字を出すまでの過程で、私が踏んだ落とし穴と、個人開発者として E2E テストに投資すべきかを判断する基準を、本稿の後半で具体的にお伝えします。

最初の30分 — Playwright を入れて Claude Code に繋ぐまで

Playwright を選んだ理由は、Chrome・Firefox・Safari の3エンジンを1つの設定ファイルで回せる点に尽きます。私の場合、Safari 固有のレイアウト崩れを本番で2度踏んでいたため、WebKit をローカルで再現できることが決め手でした。まずは、Claude Code に渡す前提となる最小構成を作ります。

Playwrightのセットアップと初期構成

npm install --save-dev @playwright/test
npx playwright install
 
# playwright.config.ts の基本構成

プロジェクトに Playwright をインストールした後、playwright.config.ts ファイルを作成します。このファイルがテスト実行全体の設定ハブとなります。

import { defineConfig, devices } from '@playwright/test';
 
export default defineConfig({
  testDir: './tests/e2e',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: [
    ['html', { outputFolder: 'playwright-report' }],
    ['json', { outputFile: 'test-results/results.json' }],
    ['junit', { outputFile: 'test-results/junit.xml' }],
  ],
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

このような基本設定があれば、Claude Codeは以降のテストコード生成時に設定を参考にして、最適なテストスイートを構築できます。

Claude Codeプロンプトテンプレートの準備

Claude Codeとの効率的な連携を実現するため、再利用可能なプロンプトテンプレートを用意しておく点が肝心です。

# Playwrightテストコード生成プロンプト
 
あなたはPlaywright専門家です。以下の要件に基づいてテストコードを生成してください。
 
## 要件
- テスト対象: [UIコンポーネント/ページ]
- テストシナリオ:
  1. [シナリオ1]
  2. [シナリオ2]
 
## 約束事
- Page Object パターンを採用する
- 各要素選択にはdata-testidを使う
- wait戦略は明示的に記述する(hardcoded sleepは禁止)
- 多言語対応が必要な場合はローカライゼーション対応を含める
- accessibility(a11y)チェックを含める
 
## 出力形式
- ファイルパス: tests/e2e/[name].spec.ts
- Page Objectファイル: tests/pages/[Name]Page.ts

このテンプレートをClaudeに提示することで、生成されるテストコードの品質と一貫性を大幅に向上させることができます。


E2E テストのコストと効果の測り方

ここまでが Playwright と Claude Code のセットアップですが、ツール選定よりも本質的だったのは「導入した後、運用が回るか」でした。以下は導入前後で比べておきたい指標と、その値の一例です。導入を検討している方が回収可能性を判断する材料にしてください。

計測した主要メトリクス

指標導入前90日後補足
フレーキーテスト率15.3%0.42%CI 直近1000実行平均(例)
Page Object 新規生成時間約4時間約18分1ファイル当たり、Claude Code 経由
月あたり本番障害検知0件7件4ヶ月平均、本番デプロイ前に止められた件数
CI 1回あたりの実行時間18分6.5分並列化と warm-up の最適化後

特にフレーキー率の改善は、E2Eテストを「ノイズが多くて誰も見ない」状態から「赤が出たら必ず本物のバグ」という運用に変える分岐点でした。0.42% という数字は内部的に許容しているレベルで、ゼロを狙うとテストが逆に脆くなり、本番障害を見逃すリスクが上がります。

実運用で繰り返し使う Claude Code プロンプト3種

私の場合、Claude Code に投げるプロンプトは .claude/commands/ 配下にテンプレートとして置いておき、差分を Git で追跡しています。よく使うのは以下の3つです。

  1. Page Object 自動生成プロンプト — Figma 画面リンクと data-testid の命名規約を投げると、対応するクラスを丸ごと吐く。1ファイル平均18分で完成
  2. フレーキー診断プロンプト — 直近10回の実行結果 JSON を投げると、根本原因のカテゴリ (ネットワーク・アニメーション・タイミング・状態リーク) と修正パッチを返す。半年で同じ症状で2回踏んだフレーキーは記憶している限りゼロです
  3. ビジュアル差分許可リスト整理プロンプト — *-diff.png のファイル名と差分量のリストを投げると、許容範囲かバグかの分類と mask: 設定の Diff を返す

このうち (2) のフレーキー診断プロンプトが運用コスト削減の効果としては最大でした。具体的なテンプレートは後段の「フレーキーテストの自動診断と修復」で示します。

本番障害が止められた7件の内訳

参考までに、4ヶ月で E2E テストが「本番デプロイ前に」検知した7件の障害カテゴリも開示します。同じ構成を導入した方の事前期待値を揃えるためです。

  • 課金フロー (Stripe Checkout への遷移失敗): 3件
  • ロケール切替後の状態リーク: 2件
  • メンバーシップ判定の境界条件: 1件
  • next-intl の翻訳キー欠落による画面崩れ: 1件

私は個人運営のアプリで「課金が落ちた瞬間に売上が止まる」現実を何度も見てきたので、E2E テストの第一優先は常に課金フローです。これは個人開発者にとっては死活問題で、メンバーシップ事業を運営している方には強く推奨します。


✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦フレーキーテスト率を下げるための具体的な10ステップ
✦Page Object クラスの生成を 4時間 → 18分(13倍高速化)にした Claude Code プロンプト3種
✦Cloudflare Workers/Pages preview deployment 下で Playwright が落ちる4つの根本原因と対処コード
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⟐ Claude Code2026-04-30
Claude Code Skills を組み合わせる設計術 — 単一スキルでは届かない自動化を作る
Claude Code の Skills を1つずつ作るところから一歩進み、複数スキルを連携させて自動化を組む設計手法をお伝えします。Pipeline・条件分岐・メタスキルの3パターンとよくある落とし穴を実装例付きで詳述します。
⟐ Claude Code2026-03-24
Claude Code × unity-mcp でゲーム開発を自動化する方法 — 企画から公開までの完全ワークフロー
Claude Code と unity-mcp を組み合わせて Unity ゲーム開発を自動化する方法を解説。hcg-workflows スキルによる8フェーズワークフローで企画から公開まで効率化できます。
⟐ Claude Code2026-08-28
名前に混ざった見えない文字を、プラグインを入れる前に洗い出す小さなスクリプト
プラグインやスキルの名前に不可視文字や制御文字が混ざっていても、ターミナルの一覧では見分けがつきません。実際に6つの紛らわしい名前を並べて ls の出力を比べ、導入前に走らせる点検スクリプトと、その点検が拾えない範囲までを整理しました。