E2Eテストとは何を守るテストか - Playwright/Cypress/Selenium選びの基準

「全部テストして」とClaude Codeに頼んだら、ブラウザを開いてボタンを片っ端からクリックする巨大なテストが80個出てきました。緑。気持ちいい。

でも次の朝、CIが12分かかるようになっていて、しかも3割が赤になったり緑になったりを繰り返していました。原因を追う気力が湧かない。気づけば誰も赤を見なくなり、テストはただの飾りになっていました。

これ、E2Eテストを「とりあえず全部」やった人がだいたい一度は通る道です。E2Eは強力なんですが、置く場所と量を間違えると、品質を守るどころか開発の足を引っ張ります。

この記事では、コードの書き方の前に、もっと手前の話をします。E2Eテストとは何を守るためのテストなのか。テストピラミッドのどこに置くのか。Playwright・Cypress・Seleniumをどう選ぶのか。何をE2Eに任せて、何を任せないのか。 ここがブレなければ、実装は後からいくらでも直せます。

具体的なPlaywrightの書き方とフレーキー潰しはPlaywright E2Eがすぐ壊れる僕がフレーキーを潰すまでに、単体・結合を含めたテスト全体の優先順位はClaude Codeで決めるテスト戦略に分けてあります。この記事は「概念とツール選び」に徹します。

この記事の要点

• E2Eテストは「ユーザーが画面を操作したら、最後までちゃんと完了するか」を本番に近い形で確かめるテスト。部品ではなく、つながりを守る。
• テストピラミッドではE2Eは一番上＝一番少なく。重くて遅くて壊れやすいから、価値の高い数本に絞る。
• ツールは3択。新規ならPlaywright、対話的開発が好きならCypress、レガシー/多言語要件があればSelenium。迷ったらPlaywright。
• E2Eに任せるのは「壊れると痛い導線」だけ。バリデーションの細かい分岐や見た目の検証はE2Eに入れない。
• フレーキー（たまに落ちる）の9割は固定待機・脆いセレクタ・テスト間のデータ共有が原因。ツールより設計で防ぐ。

E2Eテストとは結局なんなのか

E2EはEnd-to-End、つまり「端から端まで」の略です。

たとえばレストランで考えてみます。「コンロの火がつくか」は単体テスト。「コンロとフライパンと油で目玉焼きが焼けるか」は結合テスト。そして**「客が席に座って、注文して、料理が運ばれて、会計して、店を出るまでが滞りなく回るか」がE2E**です。一品の味ではなく、来店から退店までの一連の流れが成立するかを見ます。

Webアプリに置き換えると、ユーザーがブラウザを開いて、ログインして、商品をカートに入れて、決済して、注文完了画面が出る——この一連の操作を、実際のブラウザを動かして本番に近い環境で確認します。途中でどこか1つでもつながりが切れていれば、テストは落ちます。

ここが単体テストとの決定的な違いです。単体テストは部品が単体で正しく動くかを見ますが、部品がいくら全部正しくても、つなぎ目で壊れることはいくらでもあります。ログイン処理は正しい、カート処理も正しい、決済処理も正しい。でも「ログイン後のトークンがカート画面に渡っていない」せいで購入が完了しない。これは単体テストでは絶対に捕まりません。つなぎ目を見るのがE2Eの仕事です。

テストピラミッドでE2Eが「一番上」にある理由

テストの世界には「テストピラミッド」という古典的な考え方があります。下から順に、土台が広く、上に行くほど狭くなる三角形です。

層	速度	壊れやすさ	量の目安	守るもの
単体テスト（土台）	速い（数ミリ秒）	壊れにくい	一番多く	関数・部品単体の正しさ
結合テスト（中間）	普通	普通	そこそこ	モジュール間の連携
E2Eテスト（頂点）	遅い（数秒〜数十秒）	壊れやすい	一番少なく	ユーザー導線の成立

なぜE2Eが頂点、つまり一番少なくあるべきか。理由は3つあります。

遅いから。 実ブラウザを起動してページを描画してクリックして待つので、1本あたり数秒から数十秒かかります。単体テストの数千倍です。これを100本並べたら、CIが10分超えるのは当たり前です。

壊れやすいから。 本番に近い環境を再現するということは、それだけ変数が多いということです。ネットワーク、アニメーション、フォント読み込み、画面幅、外部APIの応答速度。どれか1つがブレると、コードは正しいのにテストが落ちます。これがいわゆる「フレーキーテスト」です。

調査が重いから。 単体テストが落ちたら原因はその関数の中です。E2Eが落ちたら、フロント・バックエンド・DB・外部連携・テスト環境のどこが原因か、まず切り分けからになります。

だから戦略はシンプルです。安くて速くて確実な単体テストで土台を厚くし、E2Eは「ここが壊れたら本当に困る」数本だけに絞る。 テスト全体でどの層をどれだけ書くかの優先順位づけはClaude Codeで決めるテスト戦略に詳しく書いたので、そちらと合わせて読むと全体像がつながります。

ツールは3択 - Playwright / Cypress / Selenium

E2Eツールは無数にありますが、2026年時点で実質この3つに集約されます。まず全体像を表で押さえます。

観点	Playwright	Cypress	Selenium
開発元	Microsoft	Cypress.io	OSS（W3C標準）
対応ブラウザ	Chromium / Firefox / WebKit	Chrome系 / Firefox / Edge / Electron	ほぼ全部（WebDriver経由）
動く場所	ブラウザの外から制御	アプリと同じ実行ループ内	ブラウザの外から制御
対応言語	JS/TS, Python, Java, .NET	JS/TS のみ	主要言語ほぼ全部
待機	自動待機が標準	自動待機が標準	基本は自分で待つ
複数タブ/別オリジン	得意	cy.origin()等で対応	対応するが書きやすくはない
デバッグ	Trace Viewer / UIモード	GUIが見やすい	標準では弱い
向く場面	CI前提・複数ブラウザ・新規	チームの対話的開発	レガシー資産・多言語要件

公式の一次情報はPlaywright公式とCypress公式、Selenium公式で必ず確認してください。バージョンで挙動が変わる部分があります。

Playwright - 迷ったらこれ

Microsoftが作っているE2Eフレームワークです。最大の強みは、Chromium・Firefox・WebKit（Safariの中身）の3エンジンを1つの書き方でカバーできること。SafariでだけCTAが崩れる、みたいな事故をCIで捕まえられます。

getByRole・getByLabel・getByTextのような「ユーザーから見た探し方」で要素を掴むロケータが標準で、自動待機（要素が出てくるまで勝手に待つ）も組み込みです。落ちたときに操作の様子を丸ごと記録するTrace Viewerが優秀で、Claude Codeに「このtraceを前提に原因を絞って」と渡せるのも実務で効きます。新規でCI前提なら、まずこれを選んで後悔しにくいです。

Cypress - 対話的開発が気持ちいい

Cypressは設計思想が独特で、テストがアプリと同じ実行ループの中で動きます。だからブラウザの中のwindowやDOMに直接触れて、関数をスタブしたり状態を書き換えたりがやりやすい。GUIでテストの実行を1ステップずつ見られる体験も分かりやすく、フロントエンドチームが「書きながら確認する」スタイルに向いています。

昔は「別オリジンに飛べない」「複数タブが苦手」という制約が目立ちましたが、今はcy.origin()やcy.session()が用意されて緩和されています。言語がJS/TSだけ、という点が許容できるなら良い選択肢です。

Selenium - 古くて、まだ強い

Seleniumは一番歴史が長く、ブラウザ操作の標準仕様（WebDriver）そのものに近い存在です。対応ブラウザの広さと対応言語の多さは群を抜いています。Java・Python・C#・Rubyなど、チームの主力言語が何であれ書けます。

代わりに、自動待機が弱く明示的な待機を自分で書く必要があったり、デバッグ体験が今どきの2つに比べて素朴だったりします。新規でわざわざ選ぶ理由は薄いですが、「既存のSelenium資産が大量にある」「JS/TS以外の言語で書く要件がある」「とにかく対応ブラウザが必要」 なら現役の選択肢です。

選び方を一言でまとめると、こうです。新規でCIを回したいならPlaywright。チームが対話的に書きたいならCypress。レガシーか多言語の縛りがあるならSelenium。判断に迷っている時点では、たいていPlaywrightが正解です。

何をE2Eに任せ、何を任せないか

ここが一番大事で、ツール選びより事故率に効きます。E2Eは「全部」やる道具ではありません。壊れると本当に痛い導線だけを選びます。

E2Eに任せるべきもの。

1. ログインからその後の本命画面まで - 認証が通って、ダッシュボードや会員ページが正しく出るか。ここが死ぬとサービス全体が死にます。
2. 購入・予約・問い合わせの完了まで - 売上とリードに直結する導線。注文番号が出る、確認画面に進む、二重送信されない。
3. 記事や無料PDFから次のページへ進む導線 - 個人サイトだとここが地味に重要で、CTAのhrefが消えても画面は普通に表示されるので見逃します。

逆に、E2Eに任せてはいけないもの。

• バリデーションの細かい分岐 - 「メールアドレスに@がない」「パスワードが7文字」みたいな入力チェックの全パターンを実ブラウザで回すのは無駄。単体テストでやる方が速くて確実です。
• 見た目の細部 - ボタンの色、余白、文字サイズ。E2EでtoBeVisibleは見られても「きれいか」は判定できません。見た目はビジュアルリグレッション用のツールに任せます。
• 外部サービスの本番呼び出し - 決済の本番課金、メールの実送信、広告のクリック。E2Eから毎回叩くと遅く・壊れやすく・お金もかかる。テストモードかモックにして、契約の確認はAPI側のClaude CodeでAPIテスト自動化に分けます。

判断の軸はシンプルで、「それが壊れたとき、ユーザーが操作を完了できなくなるか？」。Yesならその導線をE2Eで守る。Noなら、もっと安い層のテストに回す。これだけです。

フレーキー対策は、ツールより設計

「たまに落ちる」フレーキーテストは、E2E最大の敵です。緑になったり赤になったりを繰り返すと、人は赤を信じなくなり、本物のバグが赤に紛れて見過ごされます。

僕が潰してきたフレーキーの原因は、ほぼこの3つに集約されます。

1つ目、固定秒数で待つこと。 「3秒待ってからクリック」みたいなコードは、自分のPCでは通ってもCIの遅いマシンでは落ちます。逆に速いマシンでは無駄に遅くなる。正解は「3秒待つ」ではなく「ボタンが出てきたら進む」。今どきのツールは自動待機を持っているので、状態を待つ書き方にします。

2つ目、脆いセレクタで要素を掴むこと。 .btn-primary:nth-child(2)みたいなCSS依存の指定は、デザインを少し変えただけで壊れます。ユーザーが認識する「ボタンのラベル」や「役割（role）」で掴み、どうしても難しい所だけdata-testidという専用の目印を付けます。

3つ目、テスト同士でデータを共有すること。 前のテストが作ったカートやログイン状態を次のテストが当てにすると、並列実行や順番が変わった瞬間に崩れます。テストごとに状態をまっさらにするのが鉄則です。

つまり、フレーキーはツールを乗り換えても消えません。待ち方・掴み方・データの独立、この3点の設計で防ぐものです。具体的な直し方の手順はPlaywright E2Eがすぐ壊れる僕がフレーキーを潰すまでに実コードつきでまとめました。

まず触ってみる - 1コマンドでE2E環境を作る

概念の話が続いたので、手を動かす入口だけ置いておきます。Playwrightは環境構築が1コマンドで終わります。Node.jsが入っていれば、これだけです。

# 新しいフォルダを作ってPlaywrightを導入する
mkdir e2e-demo && cd e2e-demo

# 設定ファイル・サンプルテスト・CI雛形まで一気に作られる
npm init playwright@latest

# ブラウザ本体（Chromium/Firefox/WebKit）を入れる
npx playwright install

# サンプルテストを実行（ヘッドレス＝画面を出さずに走る）
npx playwright test

# 落ちた原因を見たいときは操作の様子をブラウザで開く
npx playwright show-report

# 1ステップずつ目で追いたいときはUIモード
npx playwright test --ui

npm init playwright@latestを叩くと、設定ファイル・サンプルspec・GitHub Actions用のCI雛形までまとめて生成されます。まずnpx playwright testでサンプルが緑になることを確認し、--uiでブラウザがどう操作されるかを目で見ると、E2Eが「何をしているか」が一気に腹落ちします。ここから先、自分の画面に合わせた実装はPlaywright実践記に譲ります。

Claude Codeにツール選定を手伝わせるコツ

ツール選びそのものをClaude Codeに相談するのも有効です。ただし「どのE2Eツールがいい？」と丸投げすると、一般論のまとめが返ってくるだけです。前提を渡すと、判断が一気に具体的になります。

E2Eツールを選びたい。以下の前提で、Playwright/Cypress/Seleniumのどれが
合うか、理由と一緒に1つ推薦して。トレードオフも添えること。

前提:
- スタック: Next.js + TypeScript、CIはGitHub Actions
- 守りたい導線: ログイン → ダッシュボード、購入完了、記事CTA
- ブラウザ要件: Chrome必須、Safari(WebKit)も見たい
- チーム: フロント2人、E2E経験は浅い
- 制約: 既存のE2E資産なし、新規で始める

出力:
- 推薦ツールと理由（3行）
- このケースで捨てる機能・割り切る点
- 最初に書くべきE2E 3本の候補

前提に「Safariも見たい」「新規」「経験浅い」と書いてあれば、Claude Codeは自然とPlaywrightを推し、理由まで前提に紐づけて返してきます。ツール選びで効くのは賢い質問ではなく、自分の状況を具体的に渡すことです。

よくある質問

Q. E2Eテストはどこまで（何本）書けばいい？ A. 「壊れたらユーザーが操作を完了できなくなる導線」だけ。多くのサービスでまず3〜5本で十分です。ログイン後の本命画面、購入や問い合わせの完了、主要なCTA導線。細かい分岐や見た目はE2Eに入れず、単体テストや専用ツールに回します。本数を増やすより、落ちない数本を維持する方が価値があります。

Q. PlaywrightとCypress、結局どっちがいい？ A. 新規でCIをしっかり回したい、SafariなどWebKitも見たいならPlaywright。フロントエンドチームが対話的に書きながら確認したい、JS/TSだけで完結していいならCypress。判断に迷う段階なら、対応ブラウザの広さとTrace Viewerの調査体験からPlaywrightを選んでおくと後悔しにくいです。

Q. Seleniumはもう古い？選ぶ理由はある？ A. 新規でわざわざ選ぶ理由は薄いですが、現役です。既存のSelenium資産が大量にある、JS/TS以外（Java・Python・C#等）で書く要件がある、対応ブラウザの広さが絶対条件、のいずれかなら有力候補です。新規プロジェクトならPlaywrightかCypressから入るのが無難です。

Q. E2Eと単体テストはどう住み分ける？ A. 単体テストは「部品が単体で正しいか」、E2Eは「部品がつながって導線が成立するか」。入力バリデーションの全パターンや計算ロジックは単体で、ログインから購入完了までの流れはE2Eで見ます。層ごとの比率の決め方はClaude Codeで決めるテスト戦略にまとめました。

Q. テストがたまに落ちる（フレーキー）。ツールを変えれば直る？ A. ほぼ直りません。原因の大半は固定秒数の待機・脆いセレクタ・テスト間のデータ共有で、これは設計の問題だからです。状態を待つ書き方、ユーザー視点のロケータ、テストごとの状態リセットで対処します。手順はPlaywright実践記に。

実際に試した結果

冒頭の「80本のE2Eが飾りになった」失敗のあと、僕がやったのはツールの乗り換えではありませんでした。E2Eを5本に削っただけです。

残したのは、ログインからダッシュボード、購入完了、記事から研修ページへのCTA、問い合わせ送信、無料PDF登録。この5本に絞ったら、CIは2分を切り、フレーキーもほぼ消えました。何より、赤が出たときに「これは本物だ」と全員が信じられるようになったのが大きい。テストが信頼を取り戻した瞬間でした。

E2Eで一番効いたのは、テスト名に「CTAのhrefを確認する」と書いたことです。画面が表示されているだけでは、記事末尾の導線が消えても気づけません。「読める」ではなく「次に進める」までをE2Eで守る。収益導線を持つサイトなら、ここは外せないと今は思っています。

選定で迷ったら、まずPlaywrightで3本。安定したら少しずつ広げる。これが僕の結論です。実装の続きはPlaywright実践記、テスト全体の設計はテスト戦略へ。チームでCIやCLAUDE.md、E2Eの責任分担まで整えたいならClaude Code研修・導入相談を、繰り返し使うプロンプトを固めたいなら教材一覧を見てみてください。