E2E に全部載せない：AI にテストを書かせる前に層を4つの基準で振り分ける
AI に「テストを書いて」と頼むと何でも E2E に寄せがちで、遅い E2E がマージを止める。何を確かめたいかで単体・コンポーネント・E2E（モック）・E2E（本物の API）に振り分けるルールを先に渡す。
どんな時に使う？
- E2E が数時間かかり、PR が詰まっている（@suna_gaku の例では 2〜3時間かかりマージを止めていた）
- エージェントが UI の細かな挙動まで Playwright で書いてしまう
- E2E を減らしたいが、どれを残すべきか決められない
振り分けの基準（AGENTS.md / CLAUDE.md に書く例）
| 確かめたいこと | 置き場所 |
|---|---|
| ロジック（計算・変換・分岐） | 単体テスト |
| UI の反応（クリックで表示が変わる等） | コンポーネントテスト（jsdom） |
| レイアウトや本物のブラウザでしか分からない挙動 | E2E（API はモックしてよい） |
| バックエンドまで通した一連の流れ | E2E（本物の API） |
markdown
## テストの置き場所
- 新しいテストは上の表で層を決めてから書く。迷ったら下の層（単体側）に置く
- E2E を足すときは「なぜ下の層では確かめられないか」を PR に1行書く@suna_gaku のチームはこの見直しで E2E を 1154 件から 60 件に減らした。
注意点
- 減らした E2E が守っていた観点が、下の層のテストに本当に移ったかを確かめる。テストの効き目は AI が書いたテストの「効き目」をミューテーションテストで測る（@mizchi/mutator） で測れる
- 残す E2E の作り方は E2E テストは「Chrome DevTools Recorder で録画 → JSON を AI に渡して Playwright 化」で書く、セキュリティ診断への流用は E2E テストを OWASP ZAP 経由で流して、脆弱性の一次チェックにする
- 型・lint、速いテスト、探索的テストの役割分担は同じ作者の関連投稿も参照