Playwright E2E + Vitestで支えるAIエージェント開発

伝統的なテストピラミッドは「ユニットテストを厚く、E2Eテストを薄く」と教えます。しかしAIエージェントが実装を書く前提では、この配分を見直す価値があります。

理由は2つあります。第一に、E2Eテストの作成コストが劇的に下がったからです。Playwrightのテストコードは定型的で、AIエージェントが得意とする種類のコードです。従来E2Eを薄くした最大の理由である「書くのも維持するのも高い」が崩れています。第二に、AIの間違い方に対してE2Eが最も強い検出力を持つからです。AIの典型的な失敗は、個々の関数は正しいのに結合すると壊れている、あるいは要件を微妙に取り違えている、というものです。ユーザーの操作フローを直接検証するE2Eテストだけが「結局、動くのか」に答えます。

そこで私たちは「クリティカルパスのE2Eを先に固め、ロジックの複雑な部分にユニットテストを足す」という順序で考えます。

LMSのような業務アプリケーションでは、E2Eテストの対象を事業影響の大きい順に選びます。私たちの優先順位は、ログイン認証、受講者のコース受講フロー、管理者の受講者招待、進捗レポートの表示です。この4つが通れば、サービスの根幹は生きています。

実装上の要点は3つです。テストデータの独立性（E2Eの不安定さの大半はデータ共有から生まれます。各テストは自分でデータを作り、自分で片付ける）。セレクタの規律（getByRole、getByLabelを基本とし、必要な箇所だけdata-testidを使う。アクセシビリティ改善と同じ方向を向くため一石二鳥です）。スクリーンショットの活用（AIエージェントに「変更後の画面を撮って確認せよ」という手順を組み込むと、レイアウト崩れに気づかないままPRを出す事故が減ります）。

ユニットテストは全てをカバーするためではなく、複雑さが集中する場所に置きます。具体的には、日付や進捗率の計算ロジック、日本語・ベトナム語の文字列処理、フォームのバリデーションルール、APIレスポンスの変換処理です。

AIにユニットテストを書かせる際の最重要の注意点は、実装と同時にテストを書かせないことです。実装直後のエージェントにテストを頼むと、実装の挙動をそのまま写しとった「現状追認テスト」ができがちです。実装が最初から間違っている場合に何も守ってくれません。

私たちは「テストは要件から書かせる」を原則にし、可能な場面ではテストを先に書かせて実装を後にする、つまりTDDの順序をエージェントに強制します。テストが要件の翻訳になっていれば、実装は安心して任せられます。

モノレポのCIでは、変更されたアプリだけをテストするパスフィルタが基本です。その上で、PR時にはリント、型チェック、ユニットテスト、クリティカルパスのE2Eのみ。マージ後とデプロイ前にE2Eのフルスイートを実行します。

PR時に全部を走らせないのは、フィードバックの速度がAIエージェントの作業効率に直結するからです。エージェントはCIの結果を見て自己修正しますが、その待ち時間が20分あるとセッション全体の効率が大きく落ちます。

テストコードは、AIエージェントにとって最も信頼できる仕様書です。散文で仕様を書くより、テストコードで示す方が曖昧さがありません。エージェントは既存のテストを読んで「このアプリではこう振る舞うのが正しい」を学習します。テストの品質は、そのままエージェントのアウトプットの品質に跳ね返ります。

人がコードを書かない時代とは、人がテストという形で要件を書く時代です。

テストが薄い既存プロジェクトに導入する場合の現実的な順序を示します。第一歩は、クリティカルパス4本のE2Eテストです。既存コードには触らず、現在の正しい挙動をテストとして固定します。第二歩は、CIへの組み込みです。ローカルでしか動かないテストは必ず腐ります。第三歩は、新規機能からのTDD適用です。

「全部にテストを書く」という号令は挫折します。守るべき順に、使う機会に合わせて増やすのが続く方法です。