Cypressとは？特徴や自動テストの始め方、Playwrightとの違いまで解説

公開日：2026/03/03

Cypressは、Webアプリケーション向けのフロントエンドテストツールです。本記事では、Cypressの特徴や始め方、SeleniumやPlaywrightとの違い、使用時の注意点までをわかりやすく解説します。テスト自動化ツールの選定に迷っている方にも役立つ内容です。

Cypressとは

Cypressとは、現代のWebアプリケーション向けに設計された次世代のフロントエンドテストツールです。公式ドキュメントでは「a next generation front end testing tool built for the modern web」と定義されており、E2Eテスト専用ツールではなくフロントエンド開発全般のテスト課題に応えるツールとして位置づけられています。2015年にBrian Mannによって開発が始まり、2016年に最初のバージョンが公開されました。現在もアクティブに開発が続いており、フロントエンドエンジニアやQAエンジニアに広く利用されています。

Cypressでできることを把握するために、まずどのようなテストに対応しているかを確認しておきましょう。Cypressが提供するソリューションは次のとおりです。

E2Eテスト：ブラウザ上でユーザー操作を再現した一連のフロー検証
コンポーネントテスト：React・Vue・Angular・Svelteなどのコンポーネント単体検証
アクセシビリティテスト：アクセシビリティ基準への適合チェック
UIカバレッジ：テストが網羅できていないUI領域の可視化

ただし、これらの機能がすべて無料で使えるわけではありません。プロダクト構成は4つです。
Cypress App（テスト実行機能を提供するコア部分）はMITライセンスのオープンソースで無料で利用できます。
Cypress Cloud（テスト結果の記録・分析・並列実行）は一定規模を超えると有料となります。これらに加え、UIの網羅状況を可視化するUI Coverageと、アクセシビリティ検査を提供するCypress Accessibilityが有料オプションとして提供されています。テスト自動化の基本的な機能はCypress Appだけで十分に活用できます。

なお、Cypressが対象とするのはブラウザ上で動作するWebアプリケーションのテストに限られます。モバイルアプリのテストには対応していない点は事前に押さえておきましょう。

現場レベルでは、無料で使えるOSS部分であるCypress AppをE2Eテストツールとして採用するケースが大半です。UIカバレッジやアクセシビリティ検査などは有料オプションのため、利用していないというユーザーもいます。そのため本記事では、Cypress AppによるE2Eテストの活用を中心に解説します。

Cypressの特徴

Cypressが他のテストフレームワークと大きく異なるのは、そのアーキテクチャです。SeleniumなどのツールはWebDriverというプロキシ層を経由してブラウザを操作しますが、Cypressはブラウザの内部で直接テストコードを実行します。この設計により、いくつかの特徴的な機能が実現されています。

自動待機（Automatic Waiting）

CypressはDOM（Document Object Model：ブラウザが内部で管理するページの構造情報）要素が表示されるまで、ネットワークリクエストが完了するまで、といった待機処理を自動的に行います。sleep()やwait()を明示的に書く必要がなく、非同期処理の多いモダンなWebアプリでも安定したテストを記述できます。

タイムトラベルデバッガー

テスト実行後、各ステップの実行時点におけるDOM（ページの構造情報）のスナップショットが自動的に保存されます。テストが失敗した際にどの時点で何が起きていたかを、GUIランナー上で時系列にさかのぼって確認できます。この機能はデバッグの時間を大幅に短縮します。

リアルタイムリロード

GUIランナーを起動した状態でテストコードを編集すると、保存のたびにテストが自動的に再実行されます。開発中のフィードバックループが短く、テストの作成・修正がスムーズです。

スクリーンショット・動画の自動取得

テスト失敗時のスクリーンショットと、テスト全体の動画が自動的に保存されます。CI/CD環境でのテスト失敗時にも、原因を視覚的に把握できます。

シンプルなセットアップ

npm install cypress --save-dev の1コマンドでインストールが完了します。WebDriverのインストールやバージョン管理が不要で、プロジェクトへの導入コストが低いです。

Cypressが活用される場面

Cypressは、次のようなテストタイプに活用されています。

E2Eテスト（エンドツーエンドテスト）

E2Eテストは、システム全体が、データや外部システムとのインターフェースを含めて期待どおりに動作するかを確認するテストです。ユーザーが実際に行う一連の操作（ログイン→商品検索→カートに追加→購入完了など）を自動化して検証することが代表的な活用例で、Cypressが最も得意とする用途です。

ただし、Cypressはブラウザの外側にある要素（外部システムとの複雑な連携、複数タブを使ったフローなど）には構造上の制約があります。「システム全体のビジネスプロセスを一気通貫で検証したい」というE2Eの本来の目的に対して、Cypressの適用範囲と制約を事前に把握しておくことが重要です。制約の詳細は「Cypressを使う際の注意点」で解説します。

コンポーネントテスト

ReactやVue.jsなどで開発したUIコンポーネントを、ブラウザ環境で単体テストする機能も備えています。ブラウザ上での実際の動作を確認しながらコンポーネントを開発できます。

APIテスト

cy.request() を使うことで、バックエンドのAPIに対してHTTPリクエストを送り、レスポンスを検証することも可能です。E2EテストのなかでUI操作を省いてAPIレベルで状態を構築する際にも活用されます。

特に相性がよいケース

React・Vue.js・Next.js・Nuxt.jsなどのモダンなフロントエンドフレームワークを採用しているプロジェクトとの親和性が高いです。フロントエンドエンジニアがテストを実装・保守するチームや、ブラウザとの密接な連携が求められるSPAの開発に適しています。チームの開発体験（DX）を重視しながらテスト自動化を進めたい場合に、特に効果を発揮します。

Cypressとその他フレームワークとの違い

E2Eテストのフレームワークはいくつか存在しますが、どれが「優れている」というわけではなく、チームの状況・プロジェクトの要件・テスト対象に応じた選択が重要です。ここでは代表的な2つのフレームワーク、SeleniumとPlaywrightとの違いを整理します。

CypressとSeleniumの違い

Seleniumはwebブラウザ操作を自動化する目的で2004年に開発されたオープンソースのツールです。テスト専用というわけではなくブラウザ操作全般に使えるため、WebスクレイピングやRPAなどにも応用されています。この立ち位置の違いは、アーキテクチャや使い勝手にも表れているので、主な違いを以下に整理します。

項目	Cypress	Selenium
アーキテクチャ	ブラウザ内で直接実行	WebDriver経由でブラウザを操作
対応言語	JavaScript / TypeScript のみ	Java・Python・Ruby・C#など多言語対応
セットアップ	npm installのみで完結	WebDriverの設定・バージョン管理が必要
テスト実行速度	比較的速い（WebDriverのオーバーヘッドがないため）	Cypressより遅い傾向
自動待機	標準搭載	明示的なwait処理が必要なことが多い
ブラウザ対応	Chrome・Firefox・Edge	主要ブラウザに幅広く対応

Seleniumは長い歴史があり、多言語対応という強みがあります。JavaやPythonで書かれた既存のテスト資産がある場合、Seleniumを継続利用するという選択は合理的です。一方、新規にWebアプリのE2Eテストを始める場合や、フロントエンド中心のチームには、セットアップのシンプルさやデバッグのしやすさからCypressが選ばれるケースが増えています。

CypressとPlaywrightの違い

PlaywrightはMicrosoftが開発するオープンソースのテストフレームワークで、2020年のリリース以降、急速にシェアを伸ばしています。CypressとPlaywrightはともにモダンなWebアプリのE2Eテストを得意としており、互いを意識しながら機能拡充を続けています。そのため機能面では重複する部分も多いですが、対応言語やブラウザの対応範囲などいくつかの点で差があるので、主な違いを以下に整理します。

項目	Cypress	Playwright
対応言語	JavaScript / TypeScript のみ	JS/TS・Python・C#・Java
ブラウザ対応	Chrome・Firefox・Edge・Safari（WebKit）対応（WebKitは比較的新しい）	Chrome・Firefox・Safari（WebKit）対応
並列実行	Cypress Cloud連携（ローカルは外部ライブラリ必要）	標準機能として搭載
単一ケースの起動速度	GUIランナー起動中はほぼゼロのオーバーヘッド	起動・終了に数秒かかることがある
デバッグUI	タイムトラベルデバッガー（直感的）	UIモード＋トレースビューワー
複数タブ・ウィンドウ	非対応	対応
学習コスト	比較的低い	やや高め

実行速度についての補足

比較表では表現しきれなかった実行速度について、少し補足します。
Cypressのテスト実行は「大量のケースを並列で流す場合はPlaywrightが速い」一方、「開発中に追加した単一ケースをすぐに再実行する場合はCypressが速い」という傾向があります。GUIランナーを起動したまま開発できるCypressは、テスト実装中のフィードバックが速く、開発体験に優れています。

どちらを選ぶかの判断軸

フロントエンドエンジニアがテストを実装・保守する → Cypress
Safariやクロスブラウザテストが必要 → Playwright
JavaScript以外の言語でテストを書きたい → Playwright
複数タブ・複数ウィンドウを使うシナリオがある → Playwright
テスト実装初期でデバッグのしやすさを重視したい → Cypress
テストケース数が多く並列実行で時間を短縮したい → Playwright

Cypressを活用したE2Eテスト自動化の進め方

Cypressの特徴や他ツールとの違いをひととおり把握できたところで、実際に手を動かしてみましょう。ここでは、Cypressをインストールしてサンプルのテストケースを作成・実行するまでの手順を解説します。

前提条件

CypressのインストールにはNode.jsが必要です。Node.js 18.x または 20.x 以上がインストールされていることを確認してください。

node -v  # バージョンを確認

インストール

テスト対象のプロジェクトのルートディレクトリで以下のコマンドを実行します。

npm install cypress --save-dev

Cypressの起動と初回セットアップ

インストール後、以下のコマンドでCypressのGUIランナーを起動します。

npx cypress open

初回起動時は「What's New in Cypress」のリリースノート画面が表示されます。内容を確認したら「Continue」をクリックして進みます。

次に「Welcome to Cypress!」画面が表示され、テストの種別を選択します。E2Eテストを行う場合は「E2E Testing」を選択してください。

「E2E Testing」を選択すると、Cypressが必要な設定ファイルを自動生成します。生成されるファイルは以下のとおりです。

cypress.config.js：E2Eテスト用の設定ファイル
cypress/support/e2e.js：各テストの実行前に読み込まれるサポートファイル
cypress/support/commands.js：カスタムコマンドを定義するファイル
cypress/fixtures/example.json：テストデータ（フィクスチャ）のサンプル

内容を確認したら「Continue」をクリックします。

続いてブラウザの選択画面が表示されます。ChromeまたはElectronから選択できます。通常はChromeを選択し、「Start E2E Testing in Chrome」をクリックしてください。

Chromeが起動し、Specs一覧画面が表示されます。

テストファイルの作成

Specs一覧画面で「Create new spec」をクリックすると、テストファイルの作成ダイアログが表示されます。ファイル名（例: cypress/e2e/spec.cy.js）を入力して「Create spec」を押すと、テンプレートが自動生成された状態でファイルが作成されます。

テストファイルは cypress/e2e/ ディレクトリ内に .cy.js（TypeScriptを使う場合は .cy.ts）という拡張子で作成されます。生成されたファイルをエディタで開き、テストコードを記述していきます。

以下は、ホテル予約サイトで「宿泊予約」ボタンをクリックし、宿泊プラン一覧画面に遷移することを確認するサンプルです。

// cypress/e2e/hotel.cy.js
describe('ホテル予約サイトのテスト', () => {
  it('宿泊予約ボタンをクリックすると宿泊プラン一覧画面に遷移する', () => {
    // ホテル予約サイトにアクセス
    cy.visit('https://hotel-example-site.takeyaqa.dev/ja/index.html')

    // 宿泊予約リンクをクリック
    cy.contains('a', '宿泊予約').click()

    // h1タグが表示されていることを確認
    cy.get('h1').should('be.visible')

    // URLに "plan" または "reservation" が含まれていることを確認
    cy.url().should('match', /plan|reservation/i)
  })
})

よく使うコマンド

cy.visit(url)：指定URLにアクセスする
cy.get(selector)：セレクタでDOM要素を取得する
cy.click()：要素をクリックする
cy.type(text)：テキストを入力する
cy.should(condition)：アサーション（期待する状態の検証。「このURLになっているはず」「このテキストが表示されているはず」といった確認処理）を行う
cy.url()：現在のURLを取得する

テストの実行

GUIランナーでテストファイルをクリックすると、ブラウザが起動してテストが実行されます。左ペインに各ステップの実行ログがリアルタイムで表示され、右ペインには実際のブラウザ画面が映し出されます。テストがすべてパスすると、ステップ名の左にチェックマークが表示されます。

CI/CD環境ではヘッドレスモード（ブラウザ画面を表示させずにバックグラウンドで実行するモード）での実行が一般的です。以下のコマンドで全テストをヘッドレス実行できます。

npx cypress run

GitHub ActionsやCircleCIなどのCI/CDパイプラインにこのコマンドを組み込むことで、プルリクエストのたびに自動的にテストを実行する環境を構築できます。

画面操作を記録して新しいテストを作成する

サンプルコードを動かすところまでできたら、次は自分のアプリケーション向けにテストを新しく作成してみましょう。Cypressには、ブラウザ上の操作を記録してテストコードを自動生成する機能があります。コードを一から書かなくても、実際に画面を操作するだけでテストの骨格を作れます。

既存のspecファイルを開いた状態で、画面上部のspec名の横にある「…」ボタンをクリックするとメニューが表示されます。「New test」を選択すると、画面右側に「studio ai」パネルが開き、「Name your test」の入力欄が表示されます。テストの名前（例:「ログインのテスト」）を入力して「Create test」をクリックします。

ブラウザが起動し、まずテスト対象のURLを入力する画面が表示されます。テストしたいページのURLを入力すると、そのページが表示された状態で記録モードに入ります。あとはブラウザ上でクリックや入力など実際の操作を行うと、その操作が順番にテストコードとして記録されていきます。操作が完了したら右ペインの「Save」ボタンをクリックすると、記録した内容がspecファイルに書き出されます。

生成されたコードはそのまま使えることもありますが、アサーション（期待する状態の確認処理）は手動で追加・調整することが多いです。記録機能でテストの骨格を素早く作り、細かい検証条件はコードで補足するという使い方が実践的です。

Cypressを使う際の注意点

Cypressは多くのシーンで有効なツールですが、事前に把握しておきたい制約と注意点がいくつかあります。

JavaScript / TypeScriptのみ対応

Cypressのテストコードが書けるのはJavaScriptとTypeScriptに限られます。JavaやPython、C#などを主に使っているチームには採用のハードルがあります。バックエンドの言語に合わせてテストも書きたい場合は、Playwright（多言語対応）やSeleniumの方が適しています。

Safari（WebKit）対応は比較的新しい

CypressはバージョンV10.8.0（2022年後半）から実験的機能としてWebKitのサポートを開始し、現在は正式に利用可能です。ただし対応は比較的新しく、ChromeやFirefoxと比べると動作の安定性や対応状況に差がある場合があります。Safariでの検証を重視するプロジェクトでは、WebKitサポートの成熟度が高いPlaywrightも選択肢として検討するとよいでしょう。

複数タブ・複数ウィンドウのテストに非対応

Cypressの公式ドキュメントでは、複数ブラウザを同時に操作するテストは「永続的なトレードオフ」として非対応と明記されています。複数タブを使った決済フローや、ポップアップを伴う操作のテストには対応できません。

並列実行にはCypress Cloudが必要

ローカル環境での並列実行は外部ライブラリが必要で、CI環境での並列実行はCypress Cloudとの連携が前提となります。テストケース数が増えてきた段階でコスト面も含めて検討が必要です。

テストケース増加に伴うメンテナンスコスト

E2Eテストは一般的に、UIの変更が発生するたびにテストコードの修正が必要になります。テストケースが増えるほどメンテナンスコストも上がるため、どのシナリオを自動化するかの設計が重要です。

モバイルアプリのテスト自動化やノーコードでの自動化を検討している場合

CypressとPlaywrightはいずれもWebアプリ専用のツールです。iOSアプリ・Androidアプリのテスト自動化が必要なチームや、コードを書かずにテストを自動化したいチームには別の選択肢が必要になります。

たとえば、MagicPodはWebアプリとモバイルアプリの両方に対応したノーコードのテスト自動化ツールです。テストシナリオを画面上で記録・編集できるため、コーディングの知識がないメンバーもテスト自動化に参加しやすい環境を構築できます。テスト対象がWebアプリのみかどうか、チームにJavaScriptの知識があるかどうかといった観点も含めて、ツールを選定するとよいでしょう。

まとめ

Cypressは、JavaScriptベースでWebアプリのE2Eテストを効率よく実装できるフレームワークです。導入の容易さやデバッグのしやすさが強みで、特にフロントエンド中心の開発体制と相性があります。一方で、複数タブ非対応や言語制限などの制約も存在します。プロジェクトの要件やチーム構成に応じて、Playwrightなど他ツールも含めて比較検討することが重要です。なお、Webやモバイルを横断した自動化や、ノーコードでのテスト運用を検討している場合は、MagicPodのような選択肢も視野に入るでしょう。

誰でもカンタンに使えるテスト自動化ツール MagicPodのご紹介

MagicPodを導入することで得られる効果や、多くの企業に選ばれている理由をわかりやすくまとめました。

ダウンロード無料

MagicPod 編集部

テスト自動化の最新トレンドや品質向上のノウハウなど、現場で役立つ情報をお届けします。