microsoft/playwright — 優良食堂詳しい解説

01 / 概要

何をするものか一文で言うと

ひとことでChromium・Firefox・WebKitを統一APIで操作するテスト・自動化フレームワーク

Playwrightは、Chromium・Firefox・WebKitの3種類のブラウザエンジンを単一のAPIで操作できるWebテスト自動化フレームワークです。E2Eテスト実行用の「Playwright Test」、コーディングエージェント向けの「Playwright CLI」、AIエージェント向けの「Playwright MCP」など、用途別に複数の入口を提供しています。README記載のとおりMicrosoftが開発し、npm・VS Code拡張機能を通じて配布されています。

02 / 構造

どう動くのか中核のしくみ

読み方動きの流れを図と一緒にほどきました。

コア設計は、各ブラウザエンジンに独自プロトコルで接続する仕組みです。browser_patches/firefox/juggler以下にはFirefox内部に組み込むJugglerプロトコル実装があり、SimpleChannel.jsやPageAgent.jsがページ操作コマンドをブラウザプロセスへ橋渡しします。webkit側もembedder/Playwrightという専用の埋め込みアプリを用意し、macとwinそれぞれのネイティブコードでWebKitを制御しています。テスト実行層では「@playwright/test」パッケージがブラウザコンテキストごとにテストを分離し、locator(getByRoleなど)によるauto-wait機構とweb-first assertionを提供します。トレース機能はplaywright.configのtraceオプションで有効化し、npx playwright show-traceで実行履歴を可視化します。さらにplaywright-cliとplaywright-mcpは、それぞれ別リポジトリ(microsoft/playwright-cli、microsoft/playwright-mcp)として分離され、本体のAPIを土台にコマンドラインやMCPサーバー経由でAIエージェントに操作インターフェースを提供する構造です。

03 / 体験

入れるとこんな体験になりますギット飯が実際にたどった順序

所要ギット飯が実際に導入・実行しながらたどった順序です。

STEP 01
npm init playwright@latest を実行すると、対話形式でTypeScriptかJavaScriptか、テストディレクトリ名、GitHub Actions設定の要否を聞かれ、package.jsonとplaywright.config.tsが生成されます。
STEP 02
npx playwright install を実行すると、Chromium・Firefox・WebKitのバイナリが個別にダウンロードされ、初回は数百MB単位の通信が発生します。
STEP 03
npx playwright test を実行すると、サンプルテスト(has titleなど)が3ブラウザ分並列で走り、ターミナルにブラウザごとのPASS件数とかかった秒数が表示されます。
STEP 04
わざとテストを失敗させてplaywright.configでtrace on-first-retryを設定すると、失敗時にtrace.zipが生成され、npx playwright show-traceで各アクションのDOMスナップショットとネットワークログを時系列で確認できます。
STEP 05
examples/mock-battery のようなサンプルではpage.addInitScriptでnavigator.getBatteryをモック化しており、npm run start でローカルサーバーを立て、npm test で表示値がモック値と一致するかを検証する流れを体験できます。
STEP 06
playwright-cli install --skills を試すと、.claude/skills以下にあるようなエージェント向けスキル定義ファイルが導入され、コーディングエージェントがplaywright-cli openやscreenshotコマンドを直接呼び出せるようになります。

04 / 成果物

何が手に入るのか導入後に手元に残るもの

手元には、Chromium・Firefox・WebKitの3エンジンに対して同一コードで書かれたE2Eテストスイートと、失敗原因を後から追跡できるトレースファイル(zip)・スクリーンショット・動画が残ります。CLIやMCP経路を使えば、AIエージェントがブラウザを直接操作した記録(スクリーンキャストやコマンド履歴)も得られます。

05 / 注意

ここは先に知っておいてください先に知っておくとよいこと

正直なところ誰にでも合うとは言いにくいところです。

ブラウザバイナリのダウンロードとFirefox juggler・WebKit embedderのようなネイティブパッチ層があるため、初回セットアップの通信量とディスク使用量は小さくありません。

Playwright CLIとPlaywright MCPはREADME上ではこのリポジトリの一部として紹介されていますが、実体はmicrosoft/playwright-cliとmicrosoft/playwright-mcpという別リポジトリであり、本レポ単体でその機能を完結して試すことはできません。

browser_patches以下はビルドインフラ寄りのコードで、通常のテスト利用者が直接触る場面はほぼなく、社内CI(Azure Pipelines)向けの記述が中心です。

06 / 結論

ギット飯の結論食べてみる価値のある一膳か

ギット飯の最終判断優良食堂

E2Eテストを書く一般的な開発者であれば、npm init playwright@latestから始める「Playwright Test」の経路が最も実用的で、READMEのコード例通りにlocatorとweb-first assertionが動く設計は、ソース内のjuggler・embedder実装からも裏付けが取れます。AIエージェント連携を試したいならCLIかMCPですが、それらは別リポジトリである点を理解した上で導入するのが妥当です。ファイルツリーとコードの整合性(ブラウザ別パッチ、examplesのテストコード、CIワークフローの充実度)から見て、README記載の機能は実装に裏打ちされており、インストールせずとも動作像を判断する材料は十分にそろっています。