「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」などの代表的エラーと解決策
目次
- 動作確認済み環境
- Node.js 20.x のインストール
- Playwright のインストールと初期設定
- 最初の E2E テストを書く
- 並列実行の設定(workers)
- GitHub Actions での CI/CD 統合
- よくあるエラーと解決策
- まとめ
動作確認済み環境
注意
バージョン差を確認する部分は 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 で確認しました。
$ 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 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 コンテナで実行したログがこちらです。
$ 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)で入れます。
①プロジェクトへのインストール
$ 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 を独自に管理しています。テストに使うブラウザは別途インストールが必要です。
$ 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

注意
--with-deps を付けると、Chromium の動作に必要なライブラリ(libgbm1・libnss3 など)が apt 経由で自動導入されます。実測では 67 個のパッケージが追加されました。CI 環境でも省略しないでください。
③設定ファイルの用意
プロジェクト直下に playwright.config.ts を用意します。最低限、テストディレクトリと headless 実行を指定しておけば動きます。
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で応答するデモサーバーに対して、ページ遷移とボタン表示を確認するテストを用意しました。
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回のページ遷移ぶん)でした。
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本すべて成功し、テストごとの所要時間が一覧で見られます。

並列実行の設定(workers)
Playwright のテストはデフォルトで CPU コア数のおよそ半分のワーカー数で並列実行されます。--workers オプションや playwright.config.ts の workers で明示的に制御できます。
逐次実行 vs 並列実行 — 実測タイミング
同じ 8 本のテストを workers=1(逐次)と workers=4(並列)でそれぞれ 3 回ずつ実行し、Playwright が出力する passed (Xs) を計測しました。

| 設定 | 1回目 | 2回目 | 3回目 | 平均 |
|---|---|---|---|---|
| workers=1(逐次) | 13.2s | 14.5s | 13.2s | 13.63s |
| workers=4(並列) | 5.5s | 5.4s | 5.3s | 5.40s |

実測では逐次 13.63 秒に対し、並列は 5.40 秒。約 2.5 倍の高速化です。並列側のばらつきが 5.3〜5.5 秒と非常に小さいのも特徴でした。
playwright.config.ts での workers 指定
CI と手元で値を変えたい場合は、環境変数で切り替えると便利です。
// CI(2コア想定)では 2、手元では 4 で並列
workers: process.env.CI ? 2 : 4,
retries: process.env.CI ? 2 : 0,
});
テストファイル分割による並列化のコツ
Playwright は既定で テストファイル単位で並列実行します(同一ファイル内は順番に走ります)。1ファイルに全テストを詰め込むと、workers を増やしても効果が出ません。今回も 8 本を 8 ファイルに分けたことで 4 ワーカーがフルに働きました。
- 機能ページ単位でファイルを分ける(
home.spec.ts、login.spec.ts…) - データ依存のあるテストは同じファイルに入れる(実行順序が保証される)
- ファイル内でもテスト単位で並列化したいときは
fullyParallel: trueを付ける
GitHub Actions での CI/CD 統合
Playwright は GitHub Actions の公式ランナー(ubuntu-24.04)でそのまま動きます。以下のワークフローをプロジェクトに置くだけで CI に組み込めます。
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点です。
actions/setup-node@v4で Node.js 20 を明示(Ubuntu 24.04 デフォルトの 18.x を使わない)cache: 'npm'で依存をキャッシュし、2回目以降のnpm ciを高速化するupload-artifactで HTML レポートを保存し、失敗時に原因を確認できるようにする
CI での workers 数の目安
- GitHub Actions の標準ランナーは 2 コア →
workers=2が目安 - 大型ランナー(4〜8コア)なら
workers=4以上に増やせる - 環境変数で切り替えると便利:
workers: process.env.CI ? 2 : 4
よくあるエラーと解決策
①「Executable doesn’t exist」— ブラウザが見つからない
/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」— 依存ライブラリ不足
解決策: --with-deps を付けてブラウザを再インストールする。これで必要なライブラリ(実測で67個)が apt 経由で揃います。
③「Timeout 30000ms exceeded」— タイムアウト
原因: テスト対象が重い、CI の帯域が遅い、テストが要素を待ち続けている、など。
解決策: playwright.config.ts でタイムアウトを伸ばすか、待ち方を見直す。
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.04・actions/setup-node@v4・cache: 'npm'の組み合わせで動く - フレイキーテストには
retriesとwaitForLoadState('networkidle')が有効
Playwright を VPS 上で常時 CI として動かす場合は、Chromium の動作にメモリが必要なので、メモリ 2GB 以上・swap 有効化をおすすめします。本格的に自分のサーバーで CI 環境を構築したい方は、VPS の選び方もあわせて参考にしてください。
Node.js の基本的なインストール手順は Ubuntu に Node.js をインストールする方法 を、VPS の実測ベンチ比較は VPS 比較おすすめ7選 もあわせてご覧ください。


コメント