はじめに
最近、フロントエンド開発において、CursorなどのAIエディタにコードを書かせる機会が激増しました。
しかし、実際にCursorに向かって「この機能のテストを書いて」と漠然と依頼してみると、ある問題に直面しました。
テストコードの量が多すぎる！
- 単純な読み取り機能なのに、何十件ものテストケースが生成される
- E2Eテストが必要以上に乱発される
- UnitとIntegrationで同じような検証が重複している
結果として、「テストの量は十分すぎるほどあるが、安心できない。メンテコストがものすごく高い」 という状態に陥りました。
そこで今回、Testing Trophy（テストのトロフィー）の概念を 「定量的な指示（件数目安と役割）」 に落とし込んでAIに与えてみたところ、それなりに制御できるようになったので、その試行錯誤の過程と具体的なルールを共有します。
1. なぜAIのテスト生成はうまくいかないのか
最初の失敗で気づいたのは、「AIはテストの量を勝手には最適化してくれない」 ということです。
人間がテストを書くときは、「ここはUnitで見たからIntegrationでは省こう」「ここはクリティカルだからE2Eでも通そう」といったバランス感覚が無意識に働きます。
しかし、AIに方針を与えずに任せると、以下のような現象が起きました。
- 重複の嵐: ロジックの境界値確認をUnitテストで行ったのに、Integrationテストでも同じ網羅性で確認しようとする。
- E2Eの乱用: 本来Integrationテスト（コンポーネント結合）で十分な確認を、すべてブラウザを動かすE2Eで確認しようとする。
これでは、実行時間は長くなり、仕様変更時の修正コストも跳ね上がってしまいます。AIには「よしなに」は通じませんでした。
2. Testing Trophyを「数値目標」に落とし込む
そこで、「Testing Trophy」の考え方をベースにしつつ、AIが実行可能な 「1機能あたりのテスト件数の目安」 を策定しました。
「概念」ではなく「数字」で枠を与えることで、AIの出力暴走を物理的に抑え込む作戦です。
▼ 策定した件数と役割の指針
実際に運用している目安が以下の表です。
| 層 | 目的 | 1機能あたりの目安 |
|---|---|---|
| Static | 型チェック、Lint | - |
| Unit | 純粋なロジック・関数の検証 | 2〜4件 |
| Integration | UI + Hook + APIの結合確認 | 8〜10件 |
| E2E | 主要ユーザーフローの確認 | 1〜2件 |
▼ 併せて決めたルール
件数指定に加えて、以下の指示も定義しました。
- 重複はIntegrationに寄せる: UnitとIntegrationで迷ったらIntegration（React Testing Library等）で検証し、Unitは書かない。
- E2Eは「Happy Path」中心: 正常に画面遷移し、目的が達成できることだけを確認する。
これらをプロンプトやルールに含めることで、AIが生成するテストコードが「適切なTesting Trophyの形」に収まるようになりました。
3. 「件数を絞ると不安」をどう解消するか
件数を制限すると、次に生まれる不安が「必要なテストケースまで削られてしまわないか？」という点です。
AIが適当にテストケースを間引いてしまっては意味がありません。
そこで今回は、 「受入基準（Acceptance Criteria = AC）」 に着目しました。
ACをテスト観点として渡す
テスト生成に関するルールに「受入基準（AC）を満たすことを検証するためのテストは必ず作成してください」といった内容を追加しました。
「ACの充足」を最優先事項とし、そのための手段として 「指定された件数枠を使う」 という指示構造にします。
こうすることで、AIは限られた件数枠の中で、ACを網羅できるテストケースの組み合わせを考えてくれるようになりました。
4. カバレッジと運用について
このルールで運用を始めてから、カバレッジ（網羅率）に対する考え方も少し変わりました。
-
監視指標: 一応
Line 80% / Branch 70%を目安として見ています。 - 優先順位: 数字の達成自体は目的化せず、 「ACが満たされているか」 を優先します。
また、AI駆動開発ならではのメリットとして、 「テスト方針の変更が怖くない」 という点があります。
人間が手書きでガリガリ書いていると、テスト戦略の変更は大きな痛みを伴いますが、AIであれば「やっぱこのIntegrationテスト、Unitに移して」と言えば一瞬で書き直してくれます。
そのため、最初から完璧なテスト戦略を立てようと気負いすぎず、定期的に「件数上限」や「層の配分」を見直しながら運用することができます。
5. まとめ
- AIには「定量的な指示」が必要: Testing Trophyのような概念も、「件数」や「明確な役割分担」という具体的なルールに翻訳して渡す必要がある。
- AC（受入基準）が品質のアンカーになる: 件数を絞る分、何を保証すべきか（AC）を明確に伝えないとテストの質が落ちる。
- 人間は設計、AIは実装: 人間は「テストの方針策定」と「受入基準の定義」に注力し、実際のコーディングはAIに任せるという分担が、現時点での最適解だと感じています。
テストコードの実装コストが下がった分、私たちは「どうテストすべきか」という設計の部分により多くの時間を使えるようになりました。
まだまだ試行錯誤の段階ですが、少しでも参考になると嬉しいです！