「Playwright（プレイライト）」という名前は聞くけれど、実際に何をするものかピンとこない。あるいは、テストコードなんて書いたことがなくて自分にできる気がしない——そんな2つの入口に向けて、この記事を書きました。
Playwrightの正体、なぜ今これが選ばれているのか、環境構築の手順、そして最初のテストを動かすところまでを順番に案内します。今日中に、実際に自分のPCでテストが1本動く状態まで到達できるはずです。
Playwrightとは何か——ブラウザを自動で動かして確認する仕組み
「ログインして、商品をカートに入れて、購入完了画面が出るか」。こういう確認作業を、新機能をリリースするたびに手作業でポチポチやっている現場は、今でも珍しくないですよね。私も何度も見てきました。
Playwrightは、この一連のクリックや入力をコードで再現し、自動で実行してくれるツールです。人間の代わりにブラウザを操作して、「期待した画面が出たか」を機械的に判定します。この手法の呼び名はE2E（End to End）テスト。「入口から出口まで、実際の使われ方を通しで確認する」という意味です。
似た言葉に「ユニットテスト」があります。こちらは関数や部品といった、プログラムの小さな単位が正しく動くかを個別に確認する手法です。ユニットテストが「部品検査」だとすれば、E2Eテストは「完成車での試乗テスト」に近いイメージでしょうか。Playwrightが得意なのは、まさにこの試乗テストの部分です。
[画像挿入待ち] ファイル名: playwright-e2e-vs-unit-test.png ／ alt: E2Eテストとユニットテストの階層図。Playwrightが得意な領域を示す
Playwrightは、Microsoftが開発しているオープンソース（無償で公開され、誰でも中身を見られる）のツールです。Chromium（Google Chromeなどのベースになっているエンジン）、Firefox、WebKit（Safariのベースになっているエンジン）の3つに対応していて、1つのコードで主要ブラウザをまとめて確認できます。
なぜ今Playwrightなのか——Seleniumとの違いと立ち位置
テスト自動化ツールと言えば、長らくSelenium（セレニウム）が代名詞的な存在でした。歴史が長く、対応言語も幅広いのがSeleniumの強みです。ここ数年は、新しめのプロジェクトでPlaywrightを選ぶ声が増えてきた印象。優劣というより、住み分けの話だと私は捉えています。
違いの1つ目は通信方式です。Seleniumは主にWebDriverという仕組みでHTTP通信を使い、操作のたびに毎回リクエストを送ります。
一方のPlaywrightは、CDP（Chrome DevTools Protocol）をベースにしたWebSocket通信を使い、回線をつなぎっぱなしにして会話し続けます。電話で用件のたびにかけ直すか、回線をつなぎっぱなしで話し続けるか——そんなイメージの違いです。
違いの2つ目は自動待機（auto-wait）です。Seleniumでは、ボタンが表示されるまで待つ処理を自分で書く場面が多く、待機時間の調整に苦労した経験を持つ方も少なくありません。Playwrightの強みは、要素が実際に操作できる状態になるまで既定で自動的に待ってくれる点。初心者がいちばんつまずきやすい「タイミングのズレ」を、ツール側がかなり吸収してくれます。
3つ目はインストール時の挙動。Playwrightはセットアップ時にChromium・Firefox・WebKitのブラウザ本体（バイナリ）も一緒にダウンロードします。動作環境ごとのブラウザバージョンの差異で結果が変わる、という事故が起きにくい設計です。
まとめると、対応言語の広さと実績の長さを求めるならSelenium、新しいプロジェクトで導入のしやすさとつまずきにくさを求めるならPlaywright、という選び方になります。
環境を整える——Node.jsからPlaywrightのインストールまで
Playwright（JavaScript・TypeScript版）を動かすには、まずNode.js（サーバーサイドでJavaScriptを実行するための土台）が必要です。バージョンの目安は18以降。2026年7月時点の最新LTS（長期サポート版）はNode.js 24です。すでにNode.jsが入っている方は、この工程は飛ばして構いません。
- Node.js公式サイトにアクセスする
- 「LTS」と表示されているボタンからインストーラーをダウンロードする
- ダウンロードしたファイルを実行し、画面の指示に沿って進める（設定はほぼ初期値のままで問題ありません）
- コマンドプロンプト（またはPowerShell）を開き、
node -vと入力してEnterキーを押す v24.x.xのようにバージョン番号が表示されればインストール成功
Node.jsをインストールすると、npm（エヌピーエム。ライブラリやツールを取り寄せて管理するパッケージ管理ツール）も一緒に使えるようになります。この後インストールするPlaywrightも、npm経由で導入します。
Node.jsの準備ができたら、いよいよPlaywrightです。作業用フォルダを作り、その中で次のコマンドを実行します。
npm init playwright@latest実行すると、対話形式でいくつか質問されます。
| 質問 | 内容 | 迷ったときの選び方 |
|---|---|---|
| TypeScript or JavaScript? | 使う言語の選択 | 初心者はJavaScriptでもTypeScriptでも構いません。すでに慣れている方を選べばOKです |
| Where to put your end-to-end tests? | テストファイルの保存フォルダ名 | 特にこだわりがなければ初期値の tests のままEnter |
| Add a GitHub Actions workflow? | コード更新時に自動でテストを走らせる設定を追加するか | 個人での学習段階なら「いいえ」でも構いません |
| Install Playwright browsers? | Chromium等のブラウザ本体をまとめてダウンロードするか | 「はい」を選んでおきましょう |
すべて答え終えると、自動的にインストールとブラウザのダウンロードが進みます。回線速度にもよりますが、数分程度かかると考えておいてください。
完了すると、次のようなファイル・フォルダが生成されます。
my-project/
├── tests/
│ └── example.spec.ts ← サンプルのテストコード
├── tests-examples/ ← より詳しいサンプル集
├── playwright.config.ts ← 設定ファイル
├── package.json
└── package-lock.jsonこれはTypeScriptを選んだ場合の例です。JavaScriptを選んだ場合は、example.spec.js のように拡張子が .js になります。
playwright.config.ts は、どのブラウザで実行するか、タイムアウトは何秒にするかといった設定をまとめたファイルです。最初のうちは中身をいじらなくても十分動きます。
[画像挿入待ち] ファイル名: playwright-setup-cli.png ／ alt: npm init playwright@latestを実行した際の対話画面（TypeScript選択中）
[画像挿入待ち] ファイル名: playwright-folder-structure.png ／ alt: インストール完了後に生成されたフォルダ構成をエディタで開いた画面
基本概念を押さえる——テスト・ロケーター・アサーション・自動待機
コードを書き始める前に、Playwright Testでよく出てくる4つの言葉を押さえておきましょう。ここが本記事でいちばん大事なパートです。ここさえ分かれば、あとはコードを読むだけで理解が進むはずです。
テストとは何を指すのか
そもそも「テスト」とは、何を確認する単位を指すのでしょうか。Playwrightでは「〜を確認する」という1つのシナリオのまとまりを指します。test() という関数の中に、確認したい手順と判定を書いていきます。
test('タイトルが表示される', async ({ page }) => {
// ここに操作と確認を書く
});ロケーター（locator）
画面上の要素を指し示す「住所」のようなものです。「送信ボタン」や「購入完了というテキスト」を、ボタンの役割やラベルの名前で探し出します。
page.getByRole('button', { name: '送信' })CSSセレクタ（HTML内部のクラス名やID）をベタ書きで指定する方法も存在しますが、Playwrightの公式ドキュメントは getByRole のように役割や見た目で探すロケーターを推奨しています。理由は単純で、内部の実装（クラス名やID）はデザイン変更のたびに変わりがちですが、ボタンの役割やラベルの文言は変わりにくいからです。壊れにくいテストを書くための、地味に大事なポイント。
アサーション（assertion）
「期待通りかどうか」を判定する部分です。ここでテストの合否が決まります。
await expect(page.getByText('購入完了')).toBeVisible();「購入完了という文字が画面に表示されているはず」という期待を、toBeVisible() というメソッドで検証しています。期待通りならテストは成功（passed）、違えば失敗（failed）として記録されます。
自動待機（auto-wait）
正直、これがPlaywrightのいちばんの魅力だと私は思っています。要素が実際に操作できる状態になるまで、Playwrightが裏側で自動的に待ってくれる仕組みです。画面の読み込みが少し遅い、アニメーションが終わるまでボタンが押せない、といった場面でも、明示的な sleep（指定秒数だけ待つ処理）はほぼ不要。Seleniumとの体感差として、ここがいちばん大きい部分だと感じています。
最初のテストを書いて動かす——実際に手を動かすパート
ここまでの概念を踏まえて、実際にコードを書いて動かしてみましょう。題材はPlaywright公式サイトのトップページです。tests フォルダの中に新しいファイル（例：first.spec.ts）を作り、次のコードを書いてください。
import { test, expect } from '@playwright/test';
test('トップページのタイトルを確認する', async ({ page }) => {
await page.goto('https://playwright.dev/');
await expect(page).toHaveTitle(/Playwright/);
});やっていることはシンプル。page.goto() で指定したURLを開き、expect(page).toHaveTitle(/Playwright/) でページのタイトルに「Playwright」という文字が含まれているかを確認しています。JavaScriptで書く場合も、拡張子を .spec.js にすれば同じ書き方で動きます。
保存したら、ターミナルで次のコマンドを実行します。npx は、インストールしたツールをその場で実行するためのコマンドです。
npx playwright testしばらく待つと、緑色の文字で「3 passed」のような結果が表示されます。既定でChromium・Firefox・WebKitの3ブラウザ分が実行されるため、1つのテストでも3件としてカウントされます。これでテストが実際に動いたことになります。
実行結果はレポートとしても確認できます。
npx playwright show-reportブラウザが自動で立ち上がり、どのテストが何秒で終わったか、途中でどんな操作をしたかが視覚的に見られます。「後から見返せる」という安心感は、業務で使い始めると地味にありがたい機能です。
せっかくなので、わざと失敗させてみましょう。先ほどの正規表現を /存在しない文字列/ のような、絶対に一致しない内容に書き換えて再実行してください。今度は結果が赤い文字になり、「Expected〜」「Received〜」という形で、期待した値と実際の値の差がエラーメッセージに表示されます。この赤い表示に慣れておくと、実務でテストが落ちたときにも慌てずに原因を追えるようになります。
[画像挿入待ち] ファイル名: playwright-test-passed.png ／ alt: npx playwright testが成功し「3 passed」と表示された緑色の結果画面
[画像挿入待ち] ファイル名: playwright-test-report.png ／ alt: npx playwright show-reportで開いたHTMLレポート画面（3ブラウザ分Passed）
[画像挿入待ち] ファイル名: playwright-test-failed.png ／ alt: わざと失敗させた際の赤色エラー表示画面
次のステップ——codegen・UIモード・CI連携への入り口
最初のテストが動いたところで、次に触ると理解が一気に加速する3つの機能を紹介しておきます。詳しい手順は別の機会に譲りますが、名前だけでも覚えておいてください。
- codegen：
npx playwright codegenで起動すると、実際にブラウザを操作した内容を記録し、テストコードを自動生成してくれます。コードを書く前に「まず動きを掴む」入口として便利です - UIモード（
npx playwright test --uiで起動）：テストの実行過程をタイムライン形式で目で追える開発者向けの画面です。どこで何が起きたかが一目でわかり、デバッグが格段にやりやすくなります - CI連携：GitHub Actionsなどと組み合わせると、コードを更新するたびに自動でテストが走るようになります。「毎回手動で確認しなくていい」という状態を作れるのが、業務改善の観点では一番効いてくる部分です
もう1つ、最近の動きとして触れておきたいのが、MicrosoftがPlaywrightに組み込み始めているAIエージェント機能です。アプリを探索してテスト計画を立てる「Planner」、その計画から実行可能なテストコードを生成する「Generator」、テストが壊れたときに自動で原因を分析して修復を試みる「Healer」という3つの役割が用意されています。テスト自動化と生成AIが交わり始めている、という最新の流れとして頭の片隅に置いておくとよいでしょう。詳しくは別記事で扱う予定です。
まとめ
今回押さえたポイントを振り返っておきます。
- Playwrightは「ブラウザ操作を自動で確認する仕組み」で、E2Eテストを得意とする
- Seleniumとの違いは、通信方式（WebSocketベースで高速）と自動待機の手厚さ
npm init playwright@latestを実行すれば、対話に答えるだけで環境構築が完了する- テスト・ロケーター・アサーション・自動待機の4つが基本概念
npx playwright testで実行し、成功も失敗も実際に体験できた
次の行動として、自社サイトや業務システムでいちばん確認頻度が高い画面（ログイン画面など）を対象に、今日書いたコードを応用してみることをおすすめします。毎回人力でポチポチ確認している作業こそ、テスト自動化の効果がいちばん出やすい部分です。
「概念は分かったけれど、自社のシステムにどう組み込めばいいか分からない」という段階まで来たら、そこから先は個別の設計判断が必要になります。環境構築や導入設計で迷った際は、TechnoBridgeの業務改善支援・IT活用に関する相談窓口も選択肢に入れてみてください。テスト自動化とAI活用を組み合わせた取り組みに関心がある方は、「クラウドAIに社内情報を流したくない」──ローカルLLMという選択肢もあわせてご覧いただけると理解が深まるはずです。
コメント