Playwright on Ubuntu 応用 — E2Eテスト並列実行とCI/CD統合

開発環境

「Playwright をインストールしたけど、テストが増えると遅くて困る」「CI/CD にどう組み込めばいいか分からない」——そんな悩みに答えるため、Playwright の並列実行(workers)と GitHub Actions 統合を実際に動かして検証しました。

結論から言うと、8本の E2E テストを workers=1(逐次)で実行すると 13.63 秒(3回平均)かかったのに対し、workers=4(並列)では 5.40 秒まで短縮できました。約 2.5 倍の高速化です。「4ワーカーなら4倍速」とはならない理由も、実測しながら解説します。

本記事では、Node.js のセットアップから Playwright のインストール、並列実行の設定、GitHub Actions での CI/CD 統合までを、すべて Docker コンテナ上で実行した実出力つきで順番に解説します。数字はすべて実測値です。

この記事のポイント

  • Ubuntu の apt デフォルト Node.js は古い(22.04→12.22.9 / 24.04→18.19.1)。Playwright には NodeSource 20.x を入れるのが確実(実測で node v20.20.2 確認)
  • Playwright 1.60.0 は npm install -D @playwright/test で導入し、npx playwright install chromium --with-deps でブラウザ(Chrome for Testing 148.0.7778.96)を準備する
  • workers=4 の並列実行は逐次比で約 2.5 倍速(実測:13.63s → 5.40s)。理論値の4倍にならないのは固定オーバーヘッドがあるため
  • GitHub Actions の ubuntu-24.04 ランナーでそのまま動く設定テンプレートを紹介
  • 「Executable doesn’t exist」「libgbm.so.1」などの代表的エラーと解決策

目次

  1. 動作確認済み環境
  2. Node.js 20.x のインストール
  3. Playwright のインストールと初期設定
  4. 最初の E2E テストを書く
  5. 並列実行の設定(workers)
  6. GitHub Actions での CI/CD 統合
  7. よくあるエラーと解決策
  8. まとめ

動作確認済み環境

注意

バージョン差を確認する部分は ubuntu:22.04 / ubuntu:24.04 の公式 Docker イメージで、Playwright の並列ベンチは node:20 公式イメージ(Debian 12 ベース・Node 20.20.2)で実行しています。Ubuntu 24.04 に NodeSource 20.x を入れた環境でも、手順・挙動は同じです。

  • バージョン確認: Ubuntu 22.04 / 24.04 公式 Docker イメージ
  • ベンチ実行環境: node:20 公式イメージ(Debian GNU/Linux 12 bookworm)
  • Node.js: 20.20.2 / npm: 10.8.2
  • Playwright: 1.60.0(同梱ブラウザ: Chrome for Testing 148.0.7778.96 / build v1223)
  • 割り当て CPU: 5 コア(コンテナ内 nproc
  • 検証日: 2026-06-14

Ubuntu 22.04 vs 24.04 — Node.js のデフォルトバージョン差

まず知っておきたいのが、Ubuntu のバージョンによって apt で入る Node.js が大きく違う点です。実際に apt-cache policy nodejs で確認しました。




ubuntu@linuxlab: ~
$ # Ubuntu 22.04
$ docker run –rm ubuntu:22.04 bash -c “apt-get update -qq; apt-cache policy nodejs | grep -E ‘Installed|Candidate'”
Installed: (none)
Candidate: 12.22.9~dfsg-1ubuntu3.6
$ # Ubuntu 24.04
$ docker run –rm ubuntu:24.04 bash -c “apt-get update -qq; apt-cache policy nodejs | grep -E ‘Installed|Candidate'”
Installed: (none)
Candidate: 18.19.1+dfsg-6ubuntu5
Ubuntu バージョン別の apt デフォルト Node.js(実測:apt-cache policy)
Ubuntu バージョン別の apt デフォルト Node.js(実測:apt-cache policy)

Ubuntu 22.04 のデフォルトは 12.22.9(すでに保守終了)で、Playwright 1.60.0 は Node.js 18 以上を要求するため、そのままでは動きません。Ubuntu 24.04 は 18.19.1 が入るので動作はしますが、すでに旧 LTS です。CI や本番運用では NodeSource 公式リポジトリから Node.js 20.x を入れるのが確実です。

Node.js 20.x のインストール

Ubuntu 22.04 / 24.04 のどちらでも、NodeSource の公式セットアップスクリプトで Node.js 20.x LTS を入れられます。実際に ubuntu:24.04 コンテナで実行したログがこちらです。




ubuntu@linuxlab: ~
$ # curl が無ければ先に入れる
$ sudo apt-get update && sudo apt-get install -y curl ca-certificates
$ # NodeSource 20.x のリポジトリを登録
$ curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash –
… – Installing pre-requisites
… – Repository configured successfully.
$ sudo apt-get install -y nodejs
$ node –version && npm –version
v20.20.2
10.8.2

NodeSource 20.x を入れた ubuntu:24.04 でも、node:20 公式イメージでも、表示されたのは同じ v20.20.2 / npm 10.8.2 でした。Ubuntu の apt デフォルトとの差は上の表のとおりです。

Playwright のインストールと初期設定

Node.js が入ったら Playwright を導入します。プロジェクトに追加する場合は -D(devDependencies)で入れます。

①プロジェクトへのインストール




ubuntu@linuxlab: ~/app
$ mkdir app && cd app
$ npm init -y
$ npm install -D @playwright/test
added 3 packages, and audited 4 packages in 1s
found 0 vulnerabilities
$ npx playwright –version
Version 1.60.0

実際に node:20 コンテナで試したところ、added 3 packages, and audited 4 packages in 1s で Playwright 1.60.0 がインストールされました。

②ブラウザのインストール

Playwright は Chromium・Firefox・WebKit を独自に管理しています。テストに使うブラウザは別途インストールが必要です。




ubuntu@linuxlab: ~/app
$ # Chromium と OS 依存ライブラリを同時に導入
$ npx playwright install chromium –with-deps
Downloading Chrome for Testing 148.0.7778.96 (playwright build v1223) …
Installing dependencies… (67 newly installed via apt)
Chrome for Testing 148.0.7778.96 (playwright build v1223) downloaded
$ ls ~/.cache/ms-playwright/
chromium-1223 chromium_headless_shell-1223 ffmpeg-1011
Playwright 1.60.0 と Chromium の導入ログ(実測:node:20 コンテナ)
Playwright 1.60.0 と Chromium の導入ログ(実測:node:20 コンテナ)

注意

--with-deps を付けると、Chromium の動作に必要なライブラリ(libgbm1libnss3 など)が apt 経由で自動導入されます。実測では 67 個のパッケージが追加されました。CI 環境でも省略しないでください。

③設定ファイルの用意

プロジェクト直下に playwright.config.ts を用意します。最低限、テストディレクトリと headless 実行を指定しておけば動きます。




ubuntu@linuxlab: ~/app/playwright.config.ts
import { defineConfig } from ‘@playwright/test’;

export default defineConfig({
testDir: ‘./tests’,
fullyParallel: true,
reporter: [[‘list’]],
use: {
headless: true,
browserName: ‘chromium’,
actionTimeout: 10_000,
},
});

最初の E2E テストを書く

Playwright のテストは TypeScript(または JavaScript)で書きます。tests/ 配下に .spec.ts を置くのが慣例です。今回の検証では、約600msで応答するデモサーバーに対して、ページ遷移とボタン表示を確認するテストを用意しました。




ubuntu@linuxlab: ~/app/tests/login.spec.ts
// tests/login.spec.ts
import { test, expect } from ‘@playwright/test’;

test(‘ログインページが表示され、トップへ戻れる’, async ({ page }) => {
await page.goto(‘/login’);
await expect(page).toHaveTitle(/ログイン/);
await expect(page.getByRole(‘button’, { name: ‘ログイン’ })).toBeVisible();
await page.goto(‘/’);
await expect(page).toHaveTitle(/トップ/);
});

実行すると、各テストは list レポーターでこのように緑のチェックが付きます。1本あたり 1.3〜1.4 秒(2回のページ遷移ぶん)でした。




ubuntu@linuxlab: ~/app
$ npx playwright test –workers=1
Running 8 tests using 1 worker
✓ 1 …about.spec.ts › Aboutページが表示され、トップへ戻れる (1.4s)
✓ 5 …home.spec.ts › トップページのタイトルとログインボタンを確認する (1.3s)
✓ 7 …login.spec.ts › ログインページが表示され、トップへ戻れる (1.4s)
…(計8本)
8 passed (13.2s)

テスト結果は HTML レポートでも確認できます(--reporter=html)。実際に workers=4 で実行したレポートがこちらです。8本すべて成功し、テストごとの所要時間が一覧で見られます。

Playwright HTML レポート(workers=4 実行・8本すべて成功)
Playwright HTML レポート(workers=4 実行・8本すべて成功)

並列実行の設定(workers)

Playwright のテストはデフォルトで CPU コア数のおよそ半分のワーカー数で並列実行されます。--workers オプションや playwright.config.tsworkers で明示的に制御できます。

逐次実行 vs 並列実行 — 実測タイミング

同じ 8 本のテストを workers=1(逐次)と workers=4(並列)でそれぞれ 3 回ずつ実行し、Playwright が出力する passed (Xs) を計測しました。

workers=1 と workers=4 の実行ログ比較(実測)
workers=1 と workers=4 の実行ログ比較(実測)
設定 1回目 2回目 3回目 平均
workers=1(逐次) 13.2s 14.5s 13.2s 13.63s
workers=4(並列) 5.5s 5.4s 5.3s 5.40s
Playwright 逐次 vs 並列の実行時間(実測:13.63s → 5.40s)
Playwright 逐次 vs 並列の実行時間(実測:13.63s → 5.40s)

実測では逐次 13.63 秒に対し、並列は 5.40 秒。約 2.5 倍の高速化です。並列側のばらつきが 5.3〜5.5 秒と非常に小さいのも特徴でした。

著者アイコン
著者アイコン

「4ワーカーなら4倍速になるはず」と思いがちですが、実測は約2.5倍でした。これは、ワーカーごとにブラウザを起動する固定コストと、サーバーの応答時間(今回は約600ms)という、並列化しても縮まない部分があるためです。逆に言うと、テスト本数が増えるほどこの固定コストは薄まり、並列の効果は理論値に近づいていきます。

playwright.config.ts での workers 指定

CI と手元で値を変えたい場合は、環境変数で切り替えると便利です。




ubuntu@linuxlab: ~/app/playwright.config.ts(抜粋)
export default defineConfig({
// CI(2コア想定)では 2、手元では 4 で並列
workers: process.env.CI ? 2 : 4,
retries: process.env.CI ? 2 : 0,
});

テストファイル分割による並列化のコツ

Playwright は既定で テストファイル単位で並列実行します(同一ファイル内は順番に走ります)。1ファイルに全テストを詰め込むと、workers を増やしても効果が出ません。今回も 8 本を 8 ファイルに分けたことで 4 ワーカーがフルに働きました。

  • 機能ページ単位でファイルを分ける(home.spec.tslogin.spec.ts …)
  • データ依存のあるテストは同じファイルに入れる(実行順序が保証される)
  • ファイル内でもテスト単位で並列化したいときは fullyParallel: true を付ける

GitHub Actions での CI/CD 統合

Playwright は GitHub Actions の公式ランナー(ubuntu-24.04)でそのまま動きます。以下のワークフローをプロジェクトに置くだけで CI に組み込めます。




ubuntu@linuxlab: ~/app/.github/workflows/playwright.yml
name: Playwright E2E Tests
on:
push:
branches: [main, develop]
pull_request:
branches: [main]

jobs:
test:
runs-on: ubuntu-24.04
steps:
– uses: actions/checkout@v4
– name: Setup Node.js 20
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
– name: Install dependencies
run: npm ci
– name: Install Playwright browsers
run: npx playwright install –with-deps chromium
– name: Run E2E tests
run: npx playwright test –workers=2
– name: Upload test report
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
retention-days: 7

ポイントは次の3点です。

  1. actions/setup-node@v4 で Node.js 20 を明示(Ubuntu 24.04 デフォルトの 18.x を使わない)
  2. cache: 'npm' で依存をキャッシュし、2回目以降の npm ci を高速化する
  3. upload-artifact で HTML レポートを保存し、失敗時に原因を確認できるようにする

CI での workers 数の目安

  • GitHub Actions の標準ランナーは 2 コア → workers=2 が目安
  • 大型ランナー(4〜8コア)なら workers=4 以上に増やせる
  • 環境変数で切り替えると便利: workers: process.env.CI ? 2 : 4

よくあるエラーと解決策

①「Executable doesn’t exist」— ブラウザが見つからない




ubuntu@linuxlab: ~/app
Error: browserType.launch: Executable doesn’t exist at
/root/.cache/ms-playwright/chromium-1223/chrome-linux/chrome

原因: npx playwright install を実行していないか、別ユーザーで実行している。

解決策: テストを動かすのと同じユーザーで npx playwright install chromium --with-deps を実行し直す。今回の環境ではブラウザ本体は ~/.cache/ms-playwright/chromium-1223/ に展開されました。

②「libgbm.so.1: cannot open shared object file」— 依存ライブラリ不足




ubuntu@linuxlab: ~/app
error while loading shared libraries: libgbm.so.1: cannot open shared object file

解決策: --with-deps を付けてブラウザを再インストールする。これで必要なライブラリ(実測で67個)が apt 経由で揃います。




ubuntu@linuxlab: ~/app
$ npx playwright install chromium –with-deps

③「Timeout 30000ms exceeded」— タイムアウト

原因: テスト対象が重い、CI の帯域が遅い、テストが要素を待ち続けている、など。

解決策: playwright.config.ts でタイムアウトを伸ばすか、待ち方を見直す。




ubuntu@linuxlab: ~/app/playwright.config.ts
export default defineConfig({
timeout: 60_000, // テスト全体(デフォルト 30000ms)
use: {
actionTimeout: 15_000, // クリック・入力など1アクション
navigationTimeout: 30_000, // page.goto() の待ち
},
});

④ フレイキーテスト(不安定なテスト)を減らすには

正直、並列実行で一番悩まされるのがフレイキーテストです。以下を組み合わせると安定します。

  • retries: 2 — 失敗時に最大2回リトライ(CIのみ)
  • await page.waitForLoadState('networkidle') — 通信が落ち着いてから操作
  • 存在チェックより toBeVisible() の可視チェックを使う(自動待機が効く)

まとめ

Ubuntu / Docker 上での Playwright 応用セットアップを実測ベースでまとめます。

  • Ubuntu の apt デフォルト Node.js(22.04: 12.22.9 / 24.04: 18.19.1)ではなく、NodeSource から Node.js 20.x(実測 v20.20.2)を入れるのが確実
  • Playwright 1.60.0 は npm install -D @playwright/test で入り、npx playwright install chromium --with-deps で Chrome for Testing 148.0.7778.96 が準備される
  • 実測では workers=4 の並列実行が逐次より約2.5倍速い(13.63s → 5.40s、8本のテスト)。理論値の4倍にならないのは固定オーバーヘッドがあるため
  • テストはファイル単位で並列化されるので、機能ページ単位でファイルを分けるのがポイント
  • GitHub Actions は ubuntu-24.04actions/setup-node@v4cache: 'npm' の組み合わせで動く
  • フレイキーテストには retrieswaitForLoadState('networkidle') が有効

Playwright を VPS 上で常時 CI として動かす場合は、Chromium の動作にメモリが必要なので、メモリ 2GB 以上・swap 有効化をおすすめします。本格的に自分のサーバーで CI 環境を構築したい方は、VPS の選び方もあわせて参考にしてください。

Node.js の基本的なインストール手順は Ubuntu に Node.js をインストールする方法 を、VPS の実測ベンチ比較は VPS 比較おすすめ7選 もあわせてご覧ください。

コメント

タイトルとURLをコピーしました