E2E

E2Eテストで最もつまずきやすいのが「認証の壁」です。テストケースごとにログイン操作を繰り返すと実行時間が膨れ上がり、MFA（多要素認証）やOAuth連携が絡むとテストコード自体の設計が難しくなります。 Playwrightには storageState やセットアッププロジェクトといった認証テスト向けの機能が組み込まれており、一度の認証操作で取得したブラウザ状態を複数テストへ再利用できます。 ここでは、Basic認証・フォームログイン・OAuth/SSO・2段階認証（MFA）それぞれのパターンについて、Playwrightでの具体的な実装手順をコード付きで整理します。 PlaywrightのstorageStateによる認証状態の保存と再利用 Playwrightの storageState は、CookieとローカルストレージをJSONファイルへ書き出し、別のテストで読み込める仕組みです。ログイン操作を「セットアッププロジェクト」として1回だけ実行し、その結果をすべてのテストで共有することで、テスト全体の実行時間を大幅に短縮できます。 ディレクトリの準備 まず認証状態ファイルの保存先を用意します。 mkdir -p playwright/.auth echo "playwright/.auth" >> .gitignore .gitignore への追加は必須です。認証状態ファイルにはCookieやセッショントークンが含まれるため、リポジトリにコミットするとセキュリティリスクとなります。 auth.setup.tsの記述 tests/auth.setup.ts を作成し、ログイン操作と状態保存を記述します。 // tests/auth.setup.ts import { test as setup, expect } from '@playwright/test'; const authFile = 'playwright/.auth/user.json'; setup('ログイン処理', async ({ page }) => { // ログインページへ遷移 await page.goto('/login'); // フォーム入力 await page.getByLabel('メールアドレス').fill('test@example.com'); await page.getByLabel('パスワード').fill('secure-password'); await page.getByRole('button', { name: 'ログイン' }).click(); // 認証完了の確認（リダイレクト先URLやDOM要素で判定） await page.waitForURL('/dashboard'); await expect(page.getByText('ダッシュボード')).toBeVisible(); // ブラウザ状態を保存 await page.context().storageState({ path: authFile }); }); waitForURL での認証完了の確認は重要です。OAuth連携などではリダイレクトが複数回発生するため、最終URLに到達してからCookieが確定します。 playwright.config.tsの設定 セットアッププロジェクトを定義し、他のテストプロジェクトがその完了を待つように依存関係を組みます。 // playwright.config.ts import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ projects: [ // セットアップ：認証処理を1回だけ実行 { name: 'setup', testMatch: /.*\.setup\.ts/, }, // テスト本体：セットアップ完了後に実行 { name: 'chromium', use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json', }, dependencies: ['setup'], }, { name: 'firefox', use: { ...devices['Desktop Firefox'], storageState: 'playwright/.auth/user.json', }, dependencies: ['setup'], }, ], }); dependencies: ['setup'] がポイントです。Playwrightはこの設定を見て、setup プロジェクトの完了後にテスト本体を実行します。 ...

Nuxtで構築したWebアプリのリリース前に「画面が正しく動くか」を手動で全ページ確認するのは、現実的ではありません。SSRとCSRが混在するNuxt特有のレンダリング挙動は、単体テストだけではカバーしきれない領域です。 Playwrightは、Chromium・Firefox・WebKitの3エンジンを単一APIで自動操作できるE2Eテストフレームワークです。Nuxt公式パッケージ @nuxt/test-utils がPlaywrightとの統合をファーストクラスでサポートしており、SSRハイドレーション完了の自動待機など、Nuxt固有の課題を解決する仕組みが組み込まれています。 PlaywrightがNuxtのE2Eテストに適している理由 NuxtアプリのE2Eテストでは、通常のSPA向けテストにはない固有の課題があります。 SSRハイドレーションの同期問題: Nuxtはサーバーサイドで描画したHTMLをブラウザに送信し、その後JavaScriptがDOMを引き継ぐ「ハイドレーション」を行います。テストコードがハイドレーション完了前に要素を操作すると、ボタンが反応しない・イベントが発火しないといった不安定なテスト（Flaky Test）が生まれます。 @nuxt/test-utils/playwright は goto フィクスチャに waitUntil: 'hydration' オプションを提供しており、ハイドレーション完了を自動で待機してからテストを実行できます。これはPlaywright標準の page.goto() にはないNuxt専用の拡張機能です。 3ブラウザエンジンの同時テスト: Nuxtで構築するWebサイトはSEOを重視するケースが多く、Safari（WebKit）を含むクロスブラウザ動作保証が求められます。PlaywrightはChromium・Firefox・WebKitをネイティブサポートしているため、1つのテストコードで3ブラウザの動作を検証できます。 環境構築の手順 必要なパッケージのインストール Nuxtプロジェクトのルートで以下を実行します。 npm install -D @playwright/test @nuxt/test-utils npx playwright install @playwright/test がPlaywrightのテストランナー本体、@nuxt/test-utils がNuxtとの統合レイヤーです。npx playwright install で各ブラウザのバイナリをダウンロードします。 playwright.config.ts の作成 プロジェクトルートに playwright.config.ts を配置します。 import { fileURLToPath } from 'node:url' import { defineConfig, devices } from '@playwright/test' import type { ConfigOptions } from '@nuxt/test-utils/playwright' export default defineConfig<ConfigOptions>({ testDir: './test/e2e', fullyParallel: true, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 1 : undefined, reporter: 'html', use: { trace: 'on-first-retry', nuxt: { rootDir: fileURLToPath(new URL('.', import.meta.url)), }, }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, { name: 'firefox', use: { ...devices['Desktop Firefox'] }, }, { name: 'webkit', use: { ...devices['Desktop Safari'] }, }, ], }) nuxt.rootDir にプロジェクトルートを指定することで、@nuxt/test-utils がNuxtの設定ファイルを自動認識し、テスト実行時にNuxtサーバーを起動します。 ...

AIコーディングエージェントが普及するなか、「ブラウザ操作だけは人の手が必要」という壁にぶつかるケースは多いです。Playwright MCPは、自然言語の指示だけでブラウザを自動制御できるMCPサーバーとして、この壁を取り除く存在になりつつあります。 本記事では、Playwright MCPの技術的な仕組みから、VS Code（GitHub Copilot）・Cursor・Claude Code・Claude Desktopそれぞれの設定手順、さらにE2Eテストやスクレイピングへの応用例まで、開発現場で即使える情報を体系的にまとめています。 Playwright MCPの概要と基本的な仕組み Playwright MCPとは何か Playwright MCPは、MicrosoftのPlaywrightチームが公式に開発・提供するMCP（Model Context Protocol）サーバーです。npmパッケージ名は @playwright/mcp で、Apache-2.0ライセンスのもとオープンソースとして公開されています。 GitHubリポジトリは2025年3月21日に作成され、最初のリリース（v0.0.7）は2025年3月28日に公開されました。2026年2月時点での最新バージョンはv0.0.64です（出典: GitHub Releases）。 従来のPlaywrightはTypeScriptやPythonのコードを書いてブラウザを操作するAPIライブラリですが、Playwright MCPはLLM（大規模言語モデル）やAIエージェントからの呼び出しに特化したサーバー実装です。両者は「関連はあるが根本的に異なるプロダクト」であり、Playwright MCPはPlaywrightの内部機能を活用しつつ、MCPプロトコルを通じてAIとブラウザを橋渡しします。 MCP（Model Context Protocol）の役割 MCPは2024年11月にAnthropicが提唱した通信規格で、AIアプリケーションと外部ツールを標準化された方法で接続します。Language Server Protocol（LSP）がエディタと言語サーバーの間を標準化したのと同様に、MCPはLLMと外部ツールの間を標準化するプロトコルです。 MCPの登場以前は、N個のAIアプリケーションとM個のツールを接続するには最大N×M個の個別コネクタが必要でした。MCPはこのN×M問題を解消し、MCP対応ツールであればどのMCP対応AIクライアントからも利用可能にします。2025年にはLinux Foundationに移管され、業界標準としての地位が固まりました。 アクセシビリティツリーによるページ表現 Playwright MCPの最大の技術的特徴は、ブラウザのページ情報をアクセシビリティツリーで表現する点です。 ブラウザ自動化技術は次のように変遷してきました。 世代 代表技術 ページの表現方法 第1世代 Selenium DOMツリー＋CSSセレクタ 第2世代 Puppeteer / Playwright DOM＋Chrome DevTools Protocol（CDP） 第3世代 Playwright MCP アクセシビリティツリー（ARIA Snapshot） 従来のスクリーンショットベースのアプローチ（Vision Modelで画像解析する方式）と比較すると、アクセシビリティツリーには以下の利点があります。 トークン効率が高い: 画像データよりYAML形式のテキストのほうが遥かに軽量 構造を正確に把握できる: ボタンの意味やフォームの役割をセマンティックに伝達 安定性が高い: CSSの変更やレイアウト崩れに左右されにくい 高速に処理できる: Vision Modelへの問い合わせが不要 Playwright MCPが出力するARIA Snapshotの例は以下のとおりです。 - navigation "メインメニュー": - link "ホーム" [ref=e1] - link "製品" [ref=e2] - link "お問い合わせ" [ref=e3] - main: - heading "製品一覧" [level=1] - list: - listitem: - link "製品A" [ref=e4] LLMはこの構造化データを解釈し、refパラメータを使って操作対象の要素を指定します。スクリーンリーダーが「見る」ページ構造と同じ情報をAIが受け取る仕組みです。 ...