Cypressはオワコン？【2026年版】現役QAエンジニアが実態を解説

「Cypressはオワコン」「PlaywrightにCypressは負けた」——2024年頃からこうした意見がSNSやQiitaで増えている。テスト自動化ツールとして一世を風靡したCypressだが、2026年現在の実態はどうなのか。15年以上のQA実務経験をもとに、GitHub Stars・求人数・CI/CD実績・コンポーネントテストの観点から冷静に評価する。結論を先に言うと、「オワコンではないが、選ぶ理由は明確にすべき時代」だ。

「Cypressはオワコン」は半分正解・半分間違いだ。勢いは落ちたが、Cypressにしかできないことがまだある。

Cypressが登場した2017年当時、そのDX（Developer Experience：開発者体験）は革命的だった。インタラクティブなテストランナー、タイムトラベルデバッグ、ブラウザ内で直接動作する仕組み——フロントエンドエンジニアを中心に一気に広まった。しかしPlaywrightが登場し、2022年頃からGitHub Starsが逆転。「Cypressはもう古い」という声が増えてきた。では実態はどうなのか、正直に整理してみよう。

「Cypressはオワコン」と言われる理由とは

批判の根拠は感情論ではなく、具体的なデータと技術的な制約に基づいている。主な理由を整理しよう。

① GitHub Stars・新規採用トレンド・State of JS でPlaywright優勢が続く

② 技術的な制約がPlaywrightで解消された

Cypressには構造上の制約があり、Playwrightの登場でそれが可視化された。

③ State of JS 調査でもPlaywrightへの移行が加速

GitHub Starsはあくまで人気の参考指標の一つだ。加えて毎年実施される「State of JS」調査でも、2023年以降のE2EテストカテゴリでPlaywrightの「使用したい」スコアがCypressを上回り続けており、npm weeklyダウンロード数でもPlaywrightの伸びが顕著になっている。これらを総合すると新規採用トレンドはPlaywright優勢だと言える。

Cypressが今でも強い場面

批判ばかりでは不公平だ。Cypressには今でも現役で選ばれる理由がある。

① コンポーネントテストでの強み

CypressのComponent Testing機能は、React・Vue・Angularなどのコンポーネントを実際のブラウザ環境で単体テストできる。Playwrightも追いかけているが、フロントエンドエンジニアの使い勝手という点ではCypressがまだ一歩リードしている。

// Cypress Component Testing（React コンポーネントをブラウザで直接テスト）
import { mount } from 'cypress/react'
import LoginForm from './LoginForm'

it('バリデーションエラーが表示される', () => {
  mount()
  cy.get('[data-testid="submit-btn"]').click()
  cy.get('[data-testid="error-msg"]')
    .should('be.visible')
    .and('contain', 'メールアドレスを入力してください')
})

② タイムトラベルデバッグのDX

Cypress最大の強みの一つがタイムトラベルデバッグだ。テスト実行後にCypress App上で各ステップのスナップショットを前後に行き来しながら確認できる。デバッグ時間が大幅に短縮され、フロントエンドエンジニアから特に高い評価を得ている。

③ JS/TSフロントエンドチームへの自然な導入

Cypressは完全にJavaScript/TypeScriptで動作するため、フロントエンドエンジニアが既存のJS知識でそのまま書ける。「QAエンジニア不在のフロントエンドチームがテストを書く」という文脈では、今でも非常に合理的な選択だ。

3ツール徹底比較｜Cypress vs Playwright vs Selenium

コードで見る違い｜同じテストを書き比べ

Cypressで書いた場合

// Cypress（JavaScript/TypeScript）
describe('ログインテスト', () => {
  it('正しい認証情報でダッシュボードへ遷移する', () => {
    cy.visit('https://example.com/login')

    // CypressもAuto-waitあり（Playwrightより細かい制御は少ない）
    cy.get('#username').type('test_user')
    cy.get('#password').type('test_pass')
    cy.get('#login-btn').click()

    cy.url().should('include', 'dashboard')
    cy.get('[data-testid="welcome-msg"]').should('be.visible')
  })
})

Playwrightで書いた場合（Python）

from playwright.sync_api import expect

# Playwright（Python）
def test_ログイン後にダッシュボードへ遷移する(page):
    page.goto("https://example.com/login")

    page.fill("#username", "test_user")
    page.fill("#password", "test_pass")
    page.click("#login-btn")

    page.wait_for_url("**/dashboard")
    expect(page.get_by_test_id("welcome-msg")).to_be_visible()

どの場面でどのツールを選ぶか

Cypressは2026年でも実際に採用されているのか

「新規採用でPlaywrightが増えている」は事実だが、Cypressが消えたわけでもない。実際の採用状況を整理しよう。

チーム構成別おすすめツール

移行判断チェックリスト｜Cypress → Playwright

既存のCypressプロジェクトをPlaywrightに移行するかどうかは、以下で判断しよう。

Cypressを選んで困るケース｜移行検討のヒント

Cypressは強力なツールだが、特定のシナリオでは構造的な制約がボトルネックになりやすい。以下に当てはまる場合は移行を検討する価値がある。

FAQ｜よくある質問

まとめ

ツール選びに正解はない。この記事の比較表とチェックリストを使って、現場に合った判断をしてほしい。