Playwright vs Cypress どっちがいい？3ヶ月使い比べてわかったこと【2026年版】
PlaywrightとCypressを3ヶ月実務で使い比べた結果を徹底解説。実行速度・書きやすさ・Safari対応・CI連携の観点で比較し、プロジェクト用途別のおすすめを提案します。
※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。
「PlaywrightとCypress、どっちを導入すればいいかわからない」というのは、E2Eテストを始めようとしたエンジニアが必ず一度は悩むことだと思います。
僕もそうでした。去年の秋、担当しているNext.jsプロジェクトに自動テストを導入しようとして、ネットで調べれば調べるほど情報が錯綜していて、「結局どっちなんだ」という状態になってしまいました。
結論から言うと、2026年時点では「ほとんどのプロジェクトはPlaywright」でいいと思っています。ただし例外があって、それがCypressを選ぶべき状況です。
この記事では、3ヶ月間の実務での使い比べをもとに、速度・書きやすさ・Safari対応・学習コストの観点から両者を整理します。
僕は文系出身で独学8ヶ月でエンジニアに転職した経歴なので、「技術的に難しい話を噛み砕いて伝える」のは得意なほうです。テストをこれから始める方にも読みやすいように書いています。
PlaywrightとCypressの基本比較（表で整理）
まずは全体像を表にまとめます。細かい説明は後続セクションで行います。
| 項目 | Playwright | Cypress |
|---|---|---|
| 開発元 | Microsoft | Cypress.io |
| ブラウザ対応 | Chromium / Firefox / Safari(WebKit) | Chromium / Firefox（Safari非対応） |
| 言語 | TypeScript / JavaScript / Python / Java / .NET | TypeScript / JavaScript |
| 実行速度（CI） | 速い（並列処理が得意） | やや遅い（シングルスレッド構造） |
| セットアップ | npm init playwright@latest で即完了 | npm install cypress で即完了 |
| デバッグUI | UI Mode（開発中） | Cypress Studio（成熟している） |
| 学習コスト | やや高め | 比較的低め |
| コミュニティ規模 | 急速に拡大中 | 成熟・大きい |
| ライセンス | Apache 2.0 | MIT（ただしクラウドサービスは有料） |
ここがポイントなんですが、スペック表だけ見るとPlaywrightが優勢に見えます。実際、僕もそう思っていました。ところが使い込むと「Cypressじゃないと辛い場面」が出てきたんです。
実行速度について（差は想像以上にある）
正直、当時の僕は「E2Eテストなんてどっちも遅いでしょ」と思っていました。甘かった。
テストスイートが50件を超えたあたりから、差が顕著に出始めます。僕が計測した環境（GitHub Actions / Ubuntu / Node.js 20）では、同じテストシナリオで最大3倍の差が出ました。
Cypressはシングルスレッドで順番に実行する設計なので、テスト数が増えると直線的に時間がかかります。一方PlaywrightはデフォルトでWorkerを使った並列実行ができます。
// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './e2e',
fullyParallel: true, // 並列実行を有効化
forbidOnly: !!process.env.CI,
retries: process.env.CI ? 2 : 0,
workers: process.env.CI ? 4 : undefined, // CIでは4並列
reporter: 'html',
use: {
baseURL: 'http://localhost:3000',
trace: 'on-first-retry',
},
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] },
},
{
name: 'firefox',
use: { ...devices['Desktop Firefox'] },
},
{
name: 'webkit',
use: { ...devices['Desktop Safari'] },
},
{
name: 'Mobile Chrome',
use: { ...devices['Pixel 5'] },
},
],
webServer: {
command: 'npm run dev',
url: 'http://localhost:3000',
reuseExistingServer: !process.env.CI,
},
});CIでの速度改善はプロジェクト全体の開発体験に直結します。GitHub Actionsの設定も合わせて最適化すると、さらに効果が出ます。
書きやすさとDX（正直CypressのDXは優秀）
（書いてたらコーヒー冷めた）
ここは正直に書きます。Cypressのデベロッパー体験は今でも一流です。
Cypressのテストコードは、見た感じがほぼ英文です。「get this element, then click it, then should contain this text」という自然な流れで書ける。
// Cypressのテスト例（cy.get スタイル）
describe('ログインフロー', () => {
it('正しい認証情報でログインできる', () => {
cy.visit('/login');
cy.get('[data-cy="email-input"]')
.type('user@example.com');
cy.get('[data-cy="password-input"]')
.type('password123');
cy.get('[data-cy="submit-button"]')
.click();
cy.url()
.should('include', '/dashboard');
cy.get('[data-cy="welcome-message"]')
.should('contain', 'ようこそ');
});
});チェーンで繋いでいく書き方はとても直感的で、テストに慣れていない人でも読めます。
一方、Playwrightはasync/awaitベースです。
// Playwrightのテスト例（await ベース）
import { test, expect } from '@playwright/test';
test('正しい認証情報でログインできる', async ({ page }) => {
await page.goto('/login');
await page.getByTestId('email-input')
.fill('user@example.com');
await page.getByTestId('password-input')
.fill('password123');
await page.getByTestId('submit-button')
.click();
await expect(page)
.toHaveURL(/.*dashboard/);
await expect(page.getByTestId('welcome-message'))
.toContainText('ようこそ');
});TypeScriptの型補完が強力に効くのでPlaywrightの書き心地も悪くないですが、await が毎行付くので、慣れないうちは書くのが億劫に感じる人もいると思います。
デバッグに関しては、CypressのStudioが一歩リードしています。テスト実行をタイムトラベル的に追えるUIは完成度が高い。PlaywrightのUI Modeは機能的に伸びていますが、2026年現在まだCypressほどの完成度ではないというのが僕の感想です。
Safari対応という意外な決定打
ここがポイントなんですが、このセクションが一番「Playwrightにして良かった」と感じた理由です。
Cypressは2026年現在もSafari（WebKit）に対応していません。Chromium系ブラウザとFirefoxのみです。
「Safariなんて気にしなくていいでしょ」と思うかもしれません。でもiPhoneのシェアが高い日本では、Safariユーザーは無視できない存在です。実際に僕が担当したプロジェクトで、「Chromeでは動くのにiPhoneのSafariで動かない」という不具合が本番後に発覚して、対応に追われた経験があります。
Playwrightなら webkit プロジェクトを追加するだけでSafariの挙動をテストできます（前述のplaywright.config.ts参照）。これは機能差として非常に大きい。
Next.jsプロジェクトやReactアプリでiPhoneユーザーをターゲットにする場合、SafariテストができないCypressはそれだけで選択肢から外れます。
学習コストの現実
コードで言うなら、PlaywrightはNode.jsの標準的な非同期処理と同じ感覚で書けます。async/awaitに慣れているエンジニアなら、1〜2日で基本的なテストが書けるようになります。
ただし、これはあくまでも「書けるようになる」だけの話です。安定したテストスイートを設計するには、セレクターの戦略（data-testidの付け方、getByRoleの活用など）や、フレーキーなテストを避けるためのwait戦略の理解が必要で、それには実際に手を動かし続ける時間がかかります。
Cypressは公式ドキュメントが充実しており、コミュニティも成熟しています。日本語の情報も豊富です。「初めてE2Eテストを書く」人にはCypressのほうが入りやすい、というのは今でも本当だと思います。
どちらのツールにせよ、E2Eテストを実務レベルで運用するのは簡単ではありません。単体テスト（Jest/Vitest）の経験があると、「テストをどう設計するか」という思考が身についているので、E2Eへの移行がスムーズです。
用途別おすすめ（Playwright vs Cypress）
整理すると、こうなります。
| 状況 | おすすめ |
|---|---|
| Safari/iOSのテストが必要 | Playwright |
| CIで並列実行してスピードを上げたい | Playwright |
| TypeScriptプロジェクトで型補完を活かしたい | Playwright |
| チームにテスト未経験者が多い | Cypress |
| デバッグUIの完成度を重視する | Cypress |
| 既存のCypressテストスイートがある | Cypress（維持） |
| 小規模プロジェクトで手軽に始めたい | どちらでも（Cypressがやや楽） |
| マルチブラウザを一括で担保したい | Playwright |
というわけで、新規プロジェクトなら迷わずPlaywright、既存CypressはCI速度がボトルネックになるまでは無理に移行しなくて良い、というのが僕の結論です。
正直ここが微妙だったポイント
バランスを取るために、Playwrightで感じた不満点も書いておきます。
1. UI Modeの完成度 デバッグ用のPlaywright UI Modeは便利なんですが、Cypress Studioと比べると操作性がまだ荒い印象です。特にテストのスナップショット比較UI周りは、Cypressのほうが洗練されています。
2. エラーメッセージが長い Playwrightのエラーメッセージは情報量が多い反面、最初は何が原因かを読み解くのに時間がかかります。「タイムアウトしました」系のエラーはとくに原因特定が難しい。
3. Dockerイメージがやや重い
CI環境でDockerコンテナを使う場合、PlaywrightのブラウザバイナリはChromium + Firefox + WebKitの全部が入るのでイメージが大きくなりがちです。--with-depsフラグや軽量ベースイメージの選択に工夫が必要です。
これらは「致命的な欠点」というわけではなく、慣れや設定で対処できる話です。ただ、「完璧なツール」だと思って導入すると最初に面食らうので、正直に書いておきました。
最終結論
- 新規プロジェクト、特にSafari対応が必要 → Playwright一択
- チームが初めてE2Eテストに取り組む、または既存Cypress資産がある → Cypress継続で問題なし
- CI速度が課題になってきた → PlaywrightへのマイグレーションをROI計算して検討
これは断言できます。「Playwright vs Cypress」の答えは「どっちが上か」ではなく「自分のプロジェクトの何を優先するか」です。
どちらのツールも、E2Eテストを真面目に運用しようとすると相応の時間と学習が必要です。でも、一度テストスイートが整うと開発の安心感がまったく変わります。リファクタリングが怖くなくなるし、本番デプロイ前の確認作業が劇的に減る。
独学に限界を感じたら:
E2Eテストを含むフロントエンドの実践的なスキルは、一人で学ぶより現役エンジニアのフィードバックがある環境が効率的です。
よくある質問
Q: PlaywrightとCypressは同じプロジェクトで共存できますか？
A: 技術的には可能ですが、実務ではほぼやりません。テストの書き方・設定・CIのワークフローがそれぞれ異なるため、管理コストが2倍になります。移行期の一時的な共存以外では、どちらかに統一することを強くおすすめします。
Q: Cypress CloudなどのSaaSは使わないといけませんか？
A: 必須ではありません。CypressはOSSとして無料で使えます。Cypress Cloud（旧Cypress Dashboard）は並列実行の高速化やテスト結果の可視化に便利なSaaSですが、有料です。GitHub ActionsなどのCIと組み合わせるだけなら追加費用は発生しません。
Q: Playwrightは難しくて初心者には向かないですか？
A: async/awaitの非同期処理に慣れていれば、思ったほど難しくないです。公式ドキュメントの質が高く、npx playwright codegenでブラウザ操作からテストコードを自動生成できる機能もあります。完全な初心者にはCypressのほうが入口として楽ですが、「難しすぎて無理」ということはありません。
Q: Vue.jsを使っているプロジェクトでもPlaywrightは使えますか？
A: はい、問題なく使えます。PlaywrightはフレームワークではなくブラウザのE2Eを扱うツールなので、React/Vue/Angularなどのフレームワーク選択に依存しません。フレームワーク側のコンポーネントテストには別途ツール（Testing LibraryやVitest）が必要ですが、E2Eの文脈では関係ありません。
Q: 既存のCypressテストをPlaywrightに移行する工数はどのくらいかかりますか？
A: テスト数とコードの複雑さに依りますが、100テストケースで1〜2週間を見ておくのが現実的です。構文は大きく異なるので、自動変換ツールは補助程度で、実際には手動の書き直しが必要になるケースが多いです。移行はCI速度や保守性に問題が出てから検討するのが無難です。
追記（2026/04/22）
Playwright v1.43がリリースされ、UI Modeのパフォーマンスと安定性が大幅に改善されました。特にタイムライン表示のレスポンスが改善され、テストスイートが200件以上の規模でも快適に操作できるようになっています。「UI Modeがまだ荒い」と書いた本文の記述は、v1.43以降では以前より当てはまらない部分も出てきています。引き続き動向を追って更新します。
