はじめに
Webアプリケーションの開発において、ユーザーが実際にブラウザで操作する流れを自動化して品質を確かめるE2Eテストは、近年ますますその重要性を増しています。
一方で、テスト対象とするブラウザやOSの組み合わせが増えるほどテストの実行時間が肥大化し、CI/CDパイプライン全体のボトルネックになりがちです。「Playwright Workspaces」は、こうしたE2Eテストの課題をクラウド側のスケールで解決するMicrosoftのマネージドサービスです。
なお本連載執筆時点（2026年4月）において、かつて同種のサービスとして提供されていた「Microsoft Playwright Testing（MPT）」は2026年3月8日に廃止されており、後継サービスとなるAzure App Testing配下の「Playwright Workspaces」がGA（一般提供）されています。本連載では一貫してこの後継サービスを題材として扱います。
対象読者
- Microsoft AzureなどクラウドサービスでWebアプリを運用している方
- Playwrightや他のE2Eテストツールに興味があり、より大規模に活用したい方
- CI/CDパイプラインへのE2Eテスト組み込みを検討している方
- Node.js／TypeScriptでのWeb開発経験のある方
E2Eテストの課題とPlaywright Workspacesが解決するもの
WebアプリケーションのE2Eテストでは、実際のブラウザを起動してユーザー操作を再現します。これにより、APIテストや単体テストでは捉えきれない画面遷移やJavaScriptの挙動、レスポンシブデザインの破綻などを検出できます。アプリの品質を「ユーザーが触れる目線」で確認する手段として、E2Eテストは現代のWeb開発に不可欠なものとなっています。
一方で、E2Eテストには実行環境にまつわる悩ましい課題があります。代表的なのは次の3つの課題です。
ブラウザとOSの組み合わせ爆発
Webアプリは、Chromium系（ChromeやEdge）、Firefox、WebKit（Safari）といった複数のブラウザエンジンで動作します。さらにモバイル端末特有の表示やタッチ操作も検証しようとすると、Android Chrome、iOS Safariも対象に含めることになります。これらをホストOS（WindowsとLinuxの両方）でテストしようとすると、組み合わせ数は容易に十数パターンを超えます。すべての組み合わせを毎回真面目に検証していては、開発速度に追いつけません。
実行時間の肥大化
組み合わせが増えればテストの所要時間も比例して増えていきます。CIパイプラインでテスト完了まで30分以上かかれば、開発者はプルリクエストを出してから結果を待ち続けることになり、開発サイクル全体のリズムが大きく損なわれます。フィードバックの遅さは品質改善のサイクルそのものを鈍化させます。
セルフホスト環境の運用負荷
ローカルでは動くテストが、CIエージェント上では不安定になる現象もよく見られます。ブラウザのバージョン管理、フォントの差異、ヘッドレスモード固有の挙動、タイムアウト設定など、安定実行のための環境調整は決して軽い作業ではありません。エージェントの台数を増やせば並列度は上がりますが、その管理コストもまた重くのしかかります。
Playwright Workspacesは、これらの課題に対してクラウド側で大規模にホストされたブラウザ環境を提供することで解決を図ります。テストの実装自体はOSSのPlaywrightをそのまま使い、実行先のブラウザだけをクラウドに切り替える、というのがサービスの基本的な発想です。
クラウド側で多数のブラウザを並列起動できるため、ローカルでは1時間かかっていたテスト群が数分で完了するといったケースも珍しくありません。エージェント環境の管理はサービス提供側に委ねられるため、利用者はテストの中身づくりに集中できます。
OSS PlaywrightとPlaywright Workspacesの関係
ここで、テストフレームワーク本体である「OSS Playwright」と、本連載で扱う「Playwright Workspaces」の関係を整理しておきましょう。両者の関係を正しく理解しておくことは、本サービスの導入判断や活用方針を考える上で重要です。
OSS Playwrightとは
OSS Playwright（playwright.dev）は、Microsoftが開発を主導しているオープンソースのブラウザ自動化フレームワークです。Node.js（TypeScript／JavaScript）、Python、Java、.NETから利用でき、Chromium、Firefox、WebKitの3種のブラウザエンジンを単一のAPIで制御できます。
E2Eテスト向けのテストランナー（@playwright/test）も同梱されており、次の現代的な機能を備えています。
Locator API
ページ上の要素を指し示すためのオブジェクト指向の仕組みです。要素を取得した時点でDOMに紐付ける旧来型のセレクタと異なり、実際に操作する直前に都度要素を解決するため、画面遷移や再レンダリングで要素が置き換わっても壊れにくいテストを書けます。
Auto-wait
要素をクリックしたり値を取得したりする際に、その要素が「操作可能な状態」になるまでPlaywright側が自動で待機してくれる仕組みです。これにより、明示的な「sleep」や「waitForSelector」を書かなくても安定したテストを実装でき、Flakyテスト（信頼性の低いテスト）の大きな原因であるタイミング問題を低減できます。
Trace Viewer
テスト実行中の状態（各ステップのDOMスナップショット、ネットワーク通信、コンソールログなど）を時系列に沿って可視化するWebベースのツールです。特にCIで発生した失敗の再現・原因調査において、ローカル環境で再実行しなくても失敗の瞬間を克明に確認できるため、デバッグ効率が大きく向上します。
OSS Playwrightは無償で利用できるため、ローカルマシンや自前のCIエージェント上でテストを実行する分には追加コストはかかりません。一方で、ブラウザの並列実行数はそのマシンのCPUやメモリに制約され、複数OS／複数ブラウザの大規模テストを高速に流したい場合は、自分でテスト用エージェントの群を組む必要があります。
Playwright Workspacesの位置づけ
Playwright Workspacesは、OSS Playwrightの「実行基盤」をクラウド側に肩代わりさせるマネージドサービスです。テストコード自体はOSS Playwrightの内容をそのまま書き、「playwright.config.ts」ファイルに小さな設定を加えるだけで、テスト実行時にクラウド上のブラウザを利用できるようになります。既存のPlaywrightプロジェクトはほぼ無改修で対応できる、というのが大きな利点です。
両者の違いを整理すると、以下の表の通りです。
| 項目 | OSS Playwright | Playwright Workspaces |
|---|---|---|
| 並列ワーカー数 | ローカルCPU依存（4～8） | 数十並列まで容易に拡張 |
| 対応OS | 実行マシンのOSに依存 | Linux／Windowsを選択可能 |
| モバイルエミュレーション | 対応 | 対応（大規模並列が利く） |
| テスト結果の可視化 | ローカルのHTMLレポート | Azureポータルで集約 |
| コスト | 無償 | 従量課金（実行分単位） |
| 運用負荷 | CIエージェント管理が必要 | サービス側にお任せ |
並列ワーカー数とOS選択の柔軟性、テスト結果の集約機能が、Playwright Workspacesの優位点となります。コストと引き換えに、運用負荷と実行時間を大きく削減できると捉えると分かりやすいでしょう。
重要なポイントとして、OSSとWorkspacesは「置き換え」の関係ではなく「重ね掛け」の関係である点を押さえておきましょう。日々の開発時にはローカルでOSSを使ってテストを書きながら確認し、CIではWorkspaces側で大規模並列実行する、という併用が現実的な利用パターンとなります。OSSで書いたテスト資産はそのまま流用できるので、二重に実装する必要はありません。
