PRO+ 公開サンプル · ログイン不要で全文をご覧いただけます。

PRO

インストール前の試食 · ログイン不要

microsoft/playwright 開発・テスト

公開前に、注文の流れをもう一度確かめる

商品を入れて注文し、完了結果まで確かめるには？手描き動画と3枚の説明図で期待結果・自動待機・ブラウザー分離・失敗の追跡を読み、既存のCypressを続ける条件も比べます。

66秒の動画説明図3枚選び方
まず動画で見る ↓すぐに始める ↓

01 · 動画でひと目に

公開前に、大切な流れを確かめよう

注文を例にした6段階の手描き解説です。音声・字幕は韓国語です。実際のショップでの実行結果ではありません。

02 · 実際のアプリ画面

公式文書の実際の画面で見てみる

Playwrightの公式文書に掲載されている画面です。例のテストの実行からレポート・UI Mode・Codegen・Traceまで、インストール後に使う順に選んで見られます。

コマンドラインで実行されるPlaywrightのテスト（公式文書の画像）
コマンドラインで例のテストを実行インストール文書が「コマンドラインで実行されるテスト」として掲載している画面です。原文は、既定の設定ではテストがブラウザーの画面なしでChromium・Firefox・WebKitに並列で実行され、出力とまとめた結果が端末に表示されると説明しています。

画面: microsoft/playwrightの公式文書の画像（docs/src/images/getting-started、v1.64.1）、Apache-2.0。ギット飯は幅2000px以下に縮小してWebPに変換しただけで、内容は変えていません。画面内のサイトは文書の例（playwright.dev、TodoMVCのデモ）で、Playwrightの名前やブラウザーのロゴなどは各所有者に帰属します。ギット飯が撮影した画面ではありません。

03 · すぐに始める

インストールコマンド1行で例のテストまで

いちばん早いのは、インストールコマンド1行です。コマンド横のコピーを押して、プロジェクトのフォルダーの端末に貼り付けます。VS Codeを使うなら、拡張機能でも同じ準備ができます。

元リポジトリv1.64.1（2026-10-14 UTCリリース）の文書に基づく · 2026-10-19確認 · ギット飯では実際にインストール・実行していません。原文の記述が食い違っています: インストール文書のシステム要件はNode.js 22.x・24.x・26.xの最新版を挙げますが、@playwright/testパッケージの設定はNode.js 20以上を受け付けます。同じ文書はmacOS 14（Sonoma）以降としていますが、v1.59のリリースノートはWebKitのmacOS 14対応を削除したと書いています。WindowsはWindows 11以降・Windows Server 2019以降・WSL、LinuxはDebian 12/13、Ubuntu 22.04/24.04/26.04（x86-64・arm64）です。ギット飯の補足: 両方を満たすなら、Node.js 22・24・26のいずれかの最新版、macOS 15以降が安全です。

どうやってインストールする？

インストールコマンド（npm・yarn・pnpm）

新しいプロジェクトを作るとき、または既存のプロジェクトにPlaywrightを加えるとき

  • playwright.config.ts
  • package.json
  • package-lock.json
  • tests/example.spec.ts

npm

npm init playwright@latest

yarn

yarn create playwright

pnpm

pnpm create playwright

4つの質問に答えます: TypeScriptかJavaScriptか（既定はTypeScript）、テストのフォルダー名（既定はtests、すでにあればe2e）、GitHub Actionsのワークフローを追加するか（CI向けに推奨・インストールツールのコードでは既定が「はい」のため、Enterだけで追加されます）、ブラウザーをインストールするか（既定ははい）。終わるとブラウザーをダウンロードし、上のファイルを作ります（yarn・pnpmではyarn.lock・pnpm-lock.yaml）。既存のプロジェクトでは今のpackage.jsonに依存関係が加わり、原文は再実行しても既存のテストを上書きしないと書いています。

インストールツール（create-playwright v1.17.139）のコードでギット飯が確認したこと: package.jsonがなければ先にnpm initを実行し、@types/nodeがなければ一緒にインストールします。package.jsonのtestスクリプトが「no test specified」の既定値なら削除し、package.jsonを書き直します。.gitignoreにnode_modules/・/test-results/・/playwright-report/・/blob-report/・/playwright/.cache/・/playwright/.auth/の行を加え、CIを選ぶと.github/workflows/playwright.ymlを作ります。同じ名前のファイルがすでにあれば「Override it?」（上書きするか）を尋ね、既定はNoです。Linuxでは、sudoが必要なOSの依存関係のインストールを別に尋ねます。

手動で追加（パッケージ＋ブラウザー）

質問なしで既存のプロジェクトにパッケージだけ入れたいとき

npm i -D @playwright/test npx playwright install

READMEの「Or add manually」の2行です。テストのツールを開発用の依存関係として入れ、ブラウザーをダウンロードします。

インストール文書は、設定ファイルと例のテストを上のインストールコマンドが作ると書いています。ギット飯の補足: この2行ではそれらのファイルは作られないため、必要なら自分で作ります。

VS Codeの拡張機能

VS Codeを使っていて、Node.js（LTS推奨）があるとき

Test: Install Playwright

拡張機能ビュー（Ctrl+Shift+X / Cmd+Shift+X）で「Playwright」を検索し、Microsoftの公式拡張機能をインストールしてから、コマンドパレットでTest: Install Playwrightを実行します。テストするブラウザー（例: Chromium・Firefox・WebKit）を選び、必要ならGitHub Actionsのワークフローも加えます。この設定は後からplaywright.config.tsで変えられます。

そのあと、アクティビティバーのTestingアイコンでテストの一覧とPlaywrightのサイドバーを開きます。テスト横の再生アイコンで実行し、サイドバーのRecord new・Pick locatorで記録・ロケーターの選択を行い、Show Trace ViewerをオンにしてTraceを表示します。

v1.64.1リリースページ ↗

インストールしたあと

  1. 例のテストを実行

    既定の設定では、ブラウザーの画面なし（headless）でChromium・Firefox・WebKitに並列で実行され、結果が端末にまとめて表示されます。画面を見るなら--headed、一つのブラウザーだけなら--project=chromiumを付けます。ギット飯の補足: テンプレートの例はテスト2件なので、3つのブラウザーでは結果が6件になります（実際には実行していません）。

    npx playwright test

  2. HTMLレポートを開く

    ブラウザー・成功・失敗・スキップ・不安定（flaky）で絞り込めるレポートです。テストを押すと、エラー・添付・手順を確認できます。自動で開くのは失敗があるときだけなので、すべて成功したらこのコマンドで開きます。

    npx playwright show-report

  3. UI Modeで手順ごとに見る

    ウォッチモード、手順のライブ表示、過去の手順に戻って調べるデバッグ（time travel）を使えます。原文は、手元でテストを作って直すときにはUI Modeを使うよう案内しています。

    npx playwright test --ui

  4. Codegenでテストの下書きを記録

    ブラウザーの画面とPlaywright Inspectorが開き、ページでクリック・入力するとコードが作られます。ツールバーのアイコンで、表示（assert visibility）・テキスト（assert text）・値（assert value）の検証も加えられます。終わったらrecordボタンで止め、copyボタンでコードをコピーします。

    npx playwright codegen demo.playwright.dev/todomvc

  5. 失敗の原因をTraceで見る

    既定の設定では、Traceは失敗したテストの最初の再試行（on-first-retry）でだけ残り、再試行はCIで2回・手元で0回です。そのため、手元でそのまま実行してもTraceは残りません。UI Modeを使わずに手元で残すなら--trace onを付け、HTMLレポートでテストファイル名の横にあるTraceアイコンから開きます。

    npx playwright test --trace on

更新とバージョンの確認

Playwrightを更新して新しいブラウザーと依存関係を一緒に入れるとき、インストールされたバージョンを確かめるときの原文のコマンドです。

更新（ブラウザー・依存関係を含む）

npm install -D @playwright/test@latest npx playwright install --with-deps

インストールされたバージョンを確認

npx playwright --version

--with-depsはOSの依存関係までインストールします。Linuxでは管理者権限が必要になる場合があるため、実行する前に確認してください。

使う前に知っておくこと

  • 例のテスト（tests/example.spec.ts）はhttps://playwright.dev/ に接続します。ギット飯の補足: インターネットが使えない場所では、例が失敗してもインストールの問題とは限りません。
  • ブラウザーはOSごとのキャッシュフォルダーにダウンロードされます: macOSは~/Library/Caches/ms-playwright、Linuxは~/.cache/ms-playwright、Windowsは%USERPROFILE%\AppData\Local\ms-playwright。インストールすると数百MBを使います。
  • Linuxでは、インストールコマンドがOSの依存関係のインストールを別に尋ね、この手順にはsudo（root）権限が必要だと書かれています。更新コマンドの--with-depsも、ブラウザーとOSの依存関係を一度にインストールします。
  • GitHub Actionsのワークフローを加えると、main/masterブランチへのpushとpull requestのたびにテストが実行され、レポートを30日保存する設定が入ります。ギット飯の補足: CIの実行時間と保存領域はチームの負担です。
  • WebKitでの実行はSafariそのものではありません。原文には、PlaywrightはAppleが配布するSafariアプリでは動作せず、Safariに最も近い結果を見るにはMacでWebKitを動かすよう書かれています（例: 動画の再生）。
  • ギット飯の補足: 実際の顧客アカウント・本番の決済・本番サーバーを対象にせず、毎回初期化できるテスト環境から始めてください。

AIアプリにインストールを任せるなら

下の指示文をClaude CodeやCodexに貼り付けると、固定したv1.64.1のインストール文書どおりに進め、Node.jsのインストール、既存ファイルの上書き、CIの追加、ブラウザーのダウンロードの前には先に確認し、sudoは実行せずにコマンドだけを伝えます。指示文はギット飯が公式文書をもとに書いたものです。

AIアプリに貼り付けるインストールの指示文

インストール文書（intro-js.md） ↗システム要件 ↗READMEの手動インストール ↗VS Codeの拡張機能 ↗HTMLレポート ↗Codegen ↗Trace Viewer ↗GitHub Actionsのワークフロー ↗ブラウザーの保存場所 ↗@playwright/testのpackage.json（node >=20） ↗v1.59リリースノート（macOS 14のWebKit対応削除） ↗インストールツールv1.17.139: 質問 ↗インストールツール: 作るファイル ↗インストールツール: .gitignore・package.json ↗インストールツール: 上書きの確認（既定No） ↗ライセンス: Apache-2.0 ↗

仕組みの説明図3枚を開く

動画の注文例を3枚の説明図で読みます。操作順に期待結果を付け、ツールが分ける状態と人が準備するデータを整理します。 図のラベルは韓国語です。

01 / 期待結果の説明図

クリック後、何が見えるべき？

商品追加、注文、完了確認をつなぐ説明図
ギット飯の説明図（韓国語）根拠の文書 ↗関連文書 ↗説明図を大きく見る ↗
図が説明すること
商品を追加して注文し、完了メッセージや記録が期待した状態か確認します。クリックの成功だけを合格にしないことが大切です。
自分の状況なら
変更のたびに注文画面を手で確認するチームの出発点になります。
自分で確認すること
テスト専用環境にアカウント・商品・注文データを準備し、本番決済が起きない条件を決めます。

公式文書を基にギット飯が作った説明図です。実際のショップ検査・速度比較・決済実験は行っていません。

説明図・動画: ギット飯。根拠: Microsoft・Playwright公式文書。確認: 2026年10月19日。 原本文書のライセンス ↗

04 · 選び方

自分の条件なら、どちらを選ぶ？

自分の状況に合わせて選ぶ

3つの質問で結論まで

答えを選ぶと、下の比較と判断の根拠をもとにギット飯がまとめた結論がすぐに表示されます。

いまのE2Eテストは？
必ず確認するブラウザーは？
失敗を読んで直す担当者と初期データはありますか？

3つ選ぶと結論が表示されます。

結論は、下の比較と「条件が変わったら」の判断、元の分析の推薦・保留の条件をそのまま反映したものです。 公式文書: WebKitとSafari ↗

ひと目で比較

同じ「更新後の注文フローの検証」を、両ツールを自分のCIで動かす基本構成どうしで比べました（Playwright v1.64.1の文書・Cypressの文書は2026-10-15に固定した版）。

基準Playwright Test · 自分のCIで実行Cypress App · 自分のCIで実行
必須のブラウザーChromium・Firefox・WebKitのプロジェクトChrome系・Firefox、WebKitは実験的な対応
失敗を調べる方法UI Mode・記録したTraceOpen ModeのCommand Log（CloudのTest Replayは別）
既存テストがある場合新しく作成、移行は追加作業既存テストを同じツールで補う
CI・費用・保存CIでの導入・レポート保存はチームの負担自前のCIで実行可、Cloudへの記録は別に判断・料金を確認

こんなときは Playwright Test · 自分のCIで実行新しいE2Eテストを作り、複数エンジンとCIの失敗記録を管理する開発者がいるとき。

こんなときは Cypress App · 自分のCIで実行Cypressに慣れたチームが必要なブラウザーをすでに検証し、移行の具体的な利点が小さいとき。

基準ごとの詳しい説明と出典
必須のブラウザー
Playwright Test · 自分のCIで実行
Chromium・Firefox・WebKitをプロジェクトに設定できます。WebKitは実際のSafariアプリと同一ではありません。
Cypress App · 自分のCIで実行
Chrome系とFirefoxに対応し、WebKitは現在実験的な対応です。

WebKitの定期検証が必須で新規導入ならPlaywrightを先に検討します。実機iPhoneの動作は別途確認します。

1 ↗2 ↗

失敗を調べる方法
Playwright Test · 自分のCIで実行
ローカルのUI Modeがあり、記録したTraceで操作・画面・エラーを追えます。
Cypress App · 自分のCIで実行
ローカルのOpen ModeでCommand Logと当時の画面を確認できます。CloudのCI Test Replayとは区別します。

どちらも原因を自動で確定するわけではありません。チームが記録を読み、修正できることが重要です。

1 ↗2 ↗3 ↗

既存テストがある場合
Playwright Test · 自分のCIで実行
新しいプロジェクトにテスト、データの準備、CI設定を作ります。他のツールのテストを移すのは追加作業です。
Cypress App · 自分のCIで実行
既存のCypressテストが必要な操作をカバーしていれば、同じツールで改善できます。

ブラウザーの制約など明確な不足がなければ、書き直すより既存テストの不足を補うことを優先します。

1 ↗2 ↗

CI・費用・保存
Playwright Test · 自分のCIで実行
CIでブラウザーと依存関係を導入し、レポートを保存します。実行時間、保存領域、保守はチームの負担です。
Cypress App · 自分のCIで実行
Cypress Appも自分のCIで実行できます。Cloudへの記録は別途選び、条件と料金を確認します。

オープンソースだから運用費ゼロとは比較しません。同じ操作・ブラウザー・保存期間で実行回数を見積もります。

1 ↗2 ↗

導入前に確認する3つ

インストール前に確認しておくと、無駄足を減らせます。チェックはこの画面でのみ表示されます。

  • 合わないときは 毎回手動認証が必要で代案がなければ、自動化の範囲を減らすか導入を保留します。

  • 合わないときは 月額費用は実測値とCI提供元の条件から計算します。ここでは費用削減を断定しません。

  • 合わないときは 基準がなければテストが緑でも、業務上重要な問題を見逃す可能性があります。

ギット飯が想定した例と根拠

新しいショップで、E2Eテストはまだなく、開発者1人が保守できます。商品追加・注文・完了確認をChromium・Firefox・WebKitで確認したい状況です。外部のテスト分析サービスとの追加契約は、まず保留します。

  • 目的：変更のたびに注文フローを確認。品質保証のすべてを代替する前提ではありません。
  • 現状：E2Eテストがなく、JavaScript/TypeScriptを保守できる開発者がいます。
  • 運用：テスト環境、初期データ、CIを用意できます。新規の有料分析サービスは保留しますが、CIの実行・保存費用は必要と考えます。

Playwrightの公式文書は2026年10月19日にv1.64.1のタグのコミットに固定して再確認し、Cypressの比較文書は2026年10月15日に固定した版に基づきます。この記事のためにショップを導入・検査したり、両ツールの速度や費用を測定したりはしていません。条件付きの推薦はギット飯の判断で、利用者評価で検証済みの結果ではありません。

使いどころがわかる解説

注文ボタンを押すところから、結果の検証まで

完成したサイトに使う開発・検証ツールです。利用者に新機能を提供するより、コードの変更後も既存機能が約束した結果になるか確かめるために使います。

01 · 役割を分ける

任せる部分と、自分で担う部分

Playwright に任せる

  • 記述した操作をブラウザーで実行し、指定した結果を検証します。
  • 設定したレポートや追跡データから実行状況を確認できます。

自分たちで準備・運用する

  • 利用者に重要な操作、合格基準、例外を決めます。
  • テスト用アカウント、データ、CI、記録のアクセス権限を準備します。
  • 画面や業務ルールの変更に合わせて検証文を更新し、不安定な失敗を調べます。

一つの操作を繰り返し実行でき、意図的な不一致を検知でき、別の担当者が失敗を説明できれば、次の操作へ広げる準備ができています。

公式資料 1 ↗公式資料 2 ↗公式資料 3 ↗公式資料 4 ↗公式資料 5 ↗公式資料 6 ↗公式資料 7 ↗
さらに詳しく：原作の読み方と確認事項

小さなWebチームが、商品の追加→注文→完了確認をテスト環境で繰り返す場面を想定します。目的は全バグを保証することではなく、一つの重要な流れの期待結果をコードに残し、失敗原因を読めるようにすることです。

02 · 読むだけで終わらせない

導入後の最初の確認は「通過する」だけでなく「誤った結果を見逃さず、理由を説明できる」ことです。以下は提案する手順で、実行結果ではありません。

以下は自分の条件に照らして確認するための手順です。ギット飯による実行結果ではありません。

  1. テスト環境で商品追加 → 注文 → 完了メッセージと注文記録の確認を一つの流れにします。テスト用の注文IDで対象を区別します。

    残すものクリックの順番とは別に「何が保存されるべきか」をチームで説明できます。

  2. 正常時を確認した後、テスト環境で期待する完了メッセージを意図的に変え、検証を失敗させてみます。

    残すもの正常な流れは通り、誤った期待値では失敗するはずです。検知を確認したら期待値を元に戻します。

  3. CIで同じテストを実行し、別の担当者がレポートとTraceを開いて原因を説明してみます。

    残すものローカル限定の条件、記録漏れ、アクセス権限の問題を見つけます。成否と実行時間はこの段階で実測します。

次へ進める条件

同じ初期状態を繰り返し用意でき、意図した失敗を検知し、担当者が記録を読んで修正できたら範囲を広げます。

立ち止まる条件

正常なコードでもデータ・ログイン・環境差で頻繁に失敗したり、再実行で通すだけで原因を説明できない場合は拡大を止めます。

判断の根拠と確認項目を詳しく読む

名前で探し、制限時間内で待つ

公式資料で確認
役割・名前のlocatorでボタンを探し、clickは表示・安定性・イベント受信・有効状態を確認します。Web-first assertionは条件を再試行します。
ギット飯の解釈
長い固定待機より、操作可能な条件と期待結果を記述する方法です。制限時間を超えると失敗します。
導入前の判断
まず識別できるボタン名と明確な完了条件を用意します。
根拠資料 1 ↗根拠資料 2 ↗根拠資料 3 ↗

3つのブラウザーと実機では確認範囲が違う

公式資料で確認
Chromium・Firefox・WebKitのプロジェクトと新しいブラウザーコンテキストを利用できます。文書には、PlaywrightはAppleが配布するSafariアプリでは動作せず、コーデックなどの機能はOSごとに異なり、Safariに最も近い結果はMacでWebKitを動かして得られると書かれています。
ギット飯の解釈
ブラウザー状態の分離はサーバーデータの自動分離まで行うものではありません。
導入前の判断
別のテストデータと、実機で残す確認項目を一緒に決めます。
根拠資料 1 ↗根拠資料 2 ↗根拠資料 3 ↗

向いている場面

  • 開発者が保守するWebサービスで、重要な利用者の操作を繰り返し確認したいとき。
  • 失敗時の画面・操作・エラーを残し、別の担当者と調べたいとき。

別の選択肢も比べたい場面

  • 導入すればAIがすべての業務ルールを自動でテストすると期待するとき。
  • 実機iPhoneのSafari確認を、WebKitのエミュレーションだけで済ませたいとき。

試す前に確認すること

  • 失敗を確認する人と、誤ったテストを修正する人を決めましたか？
  • 毎回同じ初期状態に戻せるテスト用アカウントとデータがありますか？
  • 自動テスト後も必要な実機・アクセシビリティ・業務例外の確認を分けましたか？

選んだ理由：クリックの自動化と注文の成功を検証する作業を分けて理解できる例です。テスト用アカウント、サーバーデータ、失敗を修正する担当者まで考えます。

出典と確認範囲

公式資料とコードをもとに、ギット飯が説明図と動画を制作しました。実機を操作した録画や、新しく動作・導入効果を測定した記録ではありません。

作者
Microsoft and Playwright contributors
確認日
2026-10-19
ライセンス
Apache-2.0 ↗
GitHub ↗公式ドキュメント ↗参照した版 · cfe490d ↗

ギット飯は GitHub のオープンソース情報を日本語でまとめてお届けするサービスです。掲載しているリポジトリ情報・AI 要約は原著作者の公開資料にもとづくもので、各著作物の権利は原著作者に帰属します。