E2Eで「守るべきもの」はこう決める ─ Playwright / Cypress 前提の“判断できる”品質設計

E2Eテストを書き始めると、ほぼ必ずこの壁にぶつかります。
「どこまでE2Eで守るべきなのか」「何をテスト対象に含め、何を切り捨てるのか」。

PlaywrightやCypressのような強力なツールが普及したことで、
“技術的に書ける範囲”と“守るべき範囲”が混同されやすくなったと私は感じています。

この記事では、
E2Eテストにおいて何を守るかをどう決めるのか、
そして Playwright / Cypress 前提で、どう品質を作ると実務で機能するのかを、結論まで含めてはっきり書きます。

対象読者は、

E2EテストをすでにCIで回している
テストはあるが、リリース判断が楽になっていない
「増やす／減らす」の判断に毎回悩んでいる

そんな実務レベルのエンジニアです。

1. 世界的に共有されている前提：E2Eは「ユーザー価値の破壊」を検知する仕組み

まず、判断軸を明示します。

E2Eテストが守る対象は、
ユーザーが価値を受け取るまでの“連続した体験”が壊れていないことです。

これはツールや流派の話ではありません。
ソフトウェアテストの国際的な品質モデル（ISO/IEC 25010）を
E2Eというテストレイヤーに限定して解釈すると、必ずここに収束します。

個々の関数が正しいか → 単体テスト
モジュール同士が正しく連携するか → 結合テスト
ユーザーが目的を達成できるか → E2Eテスト

つまりE2Eは、
「この操作をしたユーザーは、最後まで目的を達成できるか」
を判断するためのテストです。

この前提を外した瞬間、
E2Eテストは簡単に“数だけ多い信用できないテスト”になります。

2. 「重要そうだから守る」は失敗する

E2Eで守るべきものを決めるとき、
多くの現場でこんな決め方がされます。

売上に関わるから重要
主要画面だから重要
PMが心配しているから重要

私はこの決め方で、
E2Eが膨れ上がり、判断に使えなくなる現場を何度も見ました。

理由は単純です。

「重要そう」という基準は、壊れたときの判断に使えない。

E2Eで本当に必要なのは、
重要かどうかではなく、次の問いです。

そのフローが壊れたとき、
リリース可否の判断は変わるか？

ここに即答できないものは、
E2Eで守る価値がありません。

3. 結論：E2Eで守るべきものは「判断が変わる境界」だけ

私の結論は明確です。

E2Eで守るべきものは、
その結果次第で「出す／止める」の判断が変わる境界だけ。

具体的には、こういうものです。

ログインできるか
購入・申込み・送信まで到達できるか
主要なロールで、致命的な操作が完遂できるか

逆に、こういうものはE2Eで守りません。

表示の細かな分岐
バリデーション文言の差異
一部条件でのみ起きるUI分岐

それらは重要でも、
E2Eで判断する対象ではないからです。

4. Playwright / Cypress 前提での品質設計の考え方

PlaywrightやCypressは強力です。
だからこそ、品質設計を間違えると被害が大きくなります。

私がこの2つのツールを使うとき、
必ず意識している設計原則があります。

4.1 「何が壊れたら落ちるか」をテスト名で言語化する

E2Eテストは、
コードより先に“日本語で説明できる状態”であるべきです。

何のユーザーが
何をしようとして
どこで失敗したら落ちるのか

これがテスト名から読み取れないなら、
そのテストは判断に使えません。

4.2 1テスト = 1判断

PlaywrightでもCypressでも、
1テストで複数の判断をさせると、失敗時に必ず迷います。

ログイン
遷移
入力
送信

これらを全部詰め込むのではなく、
「どこまで通ればOKなのか」を1つに絞る。

長いテストより、
判断が鋭いテストの方が価値があります。

4.3 安定性より「説明可能性」を優先する

よくある誤解ですが、
E2Eは「絶対に落ちない」必要はありません。

落ちたときに、

何が壊れたか
どこから疑えばいいか

これが即座に分かるなら、
多少落ちても品質は下がりません。

むしろ、
理由の分からない安定は、実務では害になります。

5. 「守らないもの」を明確にすると、E2Eは強くなる

E2E設計で一番大事なのは、
あえて守らないものを決めることです。

単体テストで守る
結合テストで守る
人のレビューで見る

この切り分けをしないままE2Eを増やすと、
PlaywrightでもCypressでも、必ず破綻します。

私はいつも、こう自問します。

この失敗を見て、私は迷わず判断できるか？

迷うなら、そのテストは設計ミスです。

6. まとめ：E2Eの品質は「守った数」では決まらない

最後に、結論をはっきり言います。

E2Eで守るべきものは、
ユーザー体験のすべてではない。
判断が変わる“境界”だけでいい。

PlaywrightやCypressは、
その境界を高速・確実に確認するための道具です。

守る範囲を決めるのは、ツールではない
正解は網羅ではなく、判断の鋭さ
良いE2Eは、人の迷いを減らす

E2Eテストの品質は、
テストが増えた瞬間ではなく、
リリース判断が速くなった瞬間に分かります。

それが、私が実務で積み上げてきた結論です。