AI駆動開発 テスト戦略では、テストの本数より、変更から結果が返るまでの距離を先に決めます。まず変更したロジックを狭い自動テストで検証し、次にデータベースやAPIとの境界、最後に重要な利用経路だけをE2Eで確かめます。ただし、この順番だけでは品質保証は追いつきません。失敗したときに原因を一つの層へ絞れること、そして仕様の妥当性や見た目など人が確認する範囲を残すことが条件です。
SECTION 01
生成が速いほど、テストの待ち時間より切り分け時間が問題になる
Claude CodeやCodexを使うと、実装案とともにテストコードの候補も短時間で増やせます。そこで全種類のテストを一度に追加したくなりますが、テスト量は変更の安全性を説明する証拠になりません。似た期待値を単体、API、画面の各層で重複して確かめれば、仕様変更のたびに複数箇所が壊れ、どの失敗が原因でどれが波及なのか分かりにくくなります。
Martin Fowlerサイトの「The Practical Test Pyramid」は、粒度の異なるテストを持ち、上位になるほど数を減らすという原則を示しています。同資料はさらに、上位テストだけが不具合を見つけたなら下位の回帰テストを追加し、可能な限り低い層で検証する考え方を示します。三角形の形を守ることより、狭く、速く、原因を特定しやすい場所へ検証を置く判断が優先されます。
AIが生成した差分は、一見すると整っていても、暗黙の業務条件、既存コードの前提、外部サービスの契約を取り違える可能性があります。テストの出発点には「今回、どの振る舞いと境界が変わったか」を置きます。それを人が示し、変更単位に対応する証拠を近い順にそろえます。AI生成コードのレビュー観点で人が見る境界を決め、組織導入前はAI駆動開発のPoC計画と同じ評価条件でテストと手戻りを記録します。
変更単位そのものは、AI駆動開発でPRを小さく保つ方法のように、一つの受け入れ条件と関連する検証が同時に判断できる境界で区切ります。
SECTION 02
AI駆動開発 テスト戦略の順番は変更単位から決める
自動化の順番は、プロジェクト全体で単体テストを網羅してから結合テストへ進む工程を指しません。一つの差分ごとに、壊れ得る場所へ近い検証から置きます。仕様の例を先に期待値へ変換できれば、AIへの実装指示と完了条件も同じ基準にそろいます。既存機能へ手を入れる場合は、変更前の振る舞いを固定するテストを先に置き、意図しない差分と意図した仕様変更を分けます。
- —第1層・変更したロジック: 計算、分岐、変換、権限制御などを、外部依存を切り離した狭いテストで確かめる。正常系だけでなく、境界値、空値、拒否条件を仕様から選ぶ。
- —第2層・接続境界: データベースの読み書き、HTTP API、メッセージ、ファイルなど、実装と外部要素が接する箇所を結合テストや契約テストで確かめる。
- —第3層・重要な利用経路: ログイン、主要な登録・更新、課金に関わる操作など、利用者にとって失敗の影響が大きい経路を少数のE2Eテストで確かめる。
- —第4層・人の確認: 要件そのものの妥当性、説明文の意味、視覚的な違和感、探索的にしか見つけにくい組み合わせを確認する。順番は一律に固定せず、変更が触れた最初の層から検証を始める。
SECTION 03
変更の種類と、最初に置くテストを対応させる
順番を実務へ落とすには、プルリクエストの説明に「変えた振る舞い」「触れた境界」「影響する利用経路」を書きます。AIにテストを生成させる場合も、コード全体から推測させるだけでなく、この三点と期待結果を入力します。すると、実装の内部構造をなぞるだけのテストより、変更理由を検証するテストを選びやすくなります。
- —純粋な計算や条件分岐の変更: 狭いロジックテストを最初に実行し、その層で全条件を検証する。画面E2Eでは同じ条件を繰り返さない。
- —データ形式やスキーマの変更: シリアライズ、マイグレーション、読み書きの互換性を境界で確認し、必要なら旧データも入力にする。
- —外部APIの利用変更: リクエストとレスポンスの契約、エラー、タイムアウト時の扱いを境界で確認する。本番サービスを自動テストの前提にしない。
- —画面遷移や複数機能をまたぐ変更: 下位層で分岐を検証したうえで、代表的な成功経路と重大な失敗経路だけをE2Eへ残す。
- —文言、レイアウト、操作感の変更: 機械的に固定できる属性は自動化し、意味の自然さや視覚的判断は人のレビュー対象として明記する。どの変更でも、最短距離で異常を説明できる場所を技術上の好みより優先する。
SECTION 04
失敗時は、最初に落ちた層から原因を絞る
速いテストを先に動かすと、待ち時間に加えて原因の切り分け時間も短縮できます。狭いテストが失敗した時点で後続を止めれば、原因候補を変更したロジックへ寄せられます。狭いテストが通り、境界テストが落ちたなら、データ形式、設定、依存先との契約を疑えます。そこまで通ってE2Eだけが落ちたなら、サービス間の配線、ブラウザ上の状態、経路全体に固有の問題へ調査範囲を移せます。
反対に、E2Eだけを品質の門番にすると、失敗から得られる情報が粗くなります。画面上の保存失敗だけでは、入力検証、API、認証、データベースのどこが原因か分かりません。E2Eで初めて見つかった不具合は、再現できる最も低い層へ回帰テストを追加します。E2Eは利用経路がつながる証拠として残し、細かな条件の責任は下へ戻します。
- —ロジック層の失敗: 入力、期待値、変更した分岐を確認する。
- —境界層の失敗: スキーマ、契約、テスト用依存先、設定を確認する。
- —E2Eだけの失敗: 層間の接続、認証状態、非同期処理、ブラウザ上の操作を確認する。
- —不安定に成否が変わる失敗: 製品不具合と混ぜず、時刻、共有状態、ネットワーク依存、待機条件を切り分ける。分類が決まれば、AIへ渡す修正材料も失敗ログの羅列から、調べるべき契約や状態へ絞り込める。
SECTION 05
CIは速い判定と詳しい証拠を分ける
GitHub Docsは、GitHub ActionsのNode.js向けCIで、ローカルと同じビルドやテストのコマンドをワークフローへ追加できると案内しています。また、ログ、テスト結果、スクリーンショットなどはartifactとして保存できます。この仕組みを使うなら、プルリクエストごとの必須判定は、変更に近い高速なテストと主要な境界テストを中心にします。時間がかかる全体E2Eは、変更の影響に応じた実行や別ジョブも検討します。
ただし、ジョブを分けるだけでは切り分けやすくなりません。失敗したテスト名に対象の振る舞いが表れ、期待値と実際値が読め、境界テストのログやE2Eのスクリーンショットへたどれる必要があります。AIへ修正を依頼する際も、失敗ログだけでなく、守るべき仕様と変更範囲を渡します。テストが通るまで期待値を弱める修正を防ぐためです。
SECTION 06
人は仕様と残余リスクを確認する
自動テストが通っても、作るべきものだったかは確定しません。人のレビューでは、受け入れ条件が利用者や業務の意図に合うか、AIが前提を勝手に補っていないか、セキュリティや個人情報への影響がないかを確認します。UIでは、文言の誤解、情報の優先順位、キーボード操作や視覚上の違和感など、固定した期待値だけでは評価しにくい点を扱います。
毎回すべてを手で再確認する運用は生成速度に追いつきません。プルリクエストごとに、人が見る範囲と自動テストへ任せる範囲を宣言します。新しい業務ルールなら仕様判断を厚くし、内部リファクタリングなら外部の振る舞いが変わらない証拠を重くします。確認範囲は、実装者の種類にかかわらず変更の危険度で決めます。
SECTION 07
導入時に固定する最小ルール
最初から理想的なテスト群を作り直す必要はありません。今後の変更に対して、近い層から証拠を追加するルールを固定します。壊れやすい巨大E2Eがあるなら、そこで検出した条件を下位へ移しながら、E2Eを重要経路へ絞ります。
- —変更前に、変える振る舞い、触れる境界、影響する利用経路を書く。
- —仕様から期待値を決め、AIが生成した実装とテストだけで相互に正当化させない。
- —変更に最も近いテストを先に実行し、同じ条件を上位層で重複させない。
- —上位層だけで見つかった不具合は、再現可能な下位層へ回帰テストを追加する。
- —CIの失敗から対象層、期待値、実際値、診断用artifactへたどれるようにする。
- —人が確認する仕様、セキュリティ、アクセシビリティ、表現、探索範囲を差分ごとに示す。まずこの六つをプルリクエストのテンプレートとCIへ反映すれば、既存テストを全面改修せずに運用を始められる。
SECTION 08
品質保証を追いつかせるのは、変更に近い証拠である
AI駆動開発で自動化すべき順番は、狭いロジック、外部との境界、重要な利用経路です。テストピラミッドの形だけを当てはめても、運用は安定しません。各テストを変更単位へ対応させ、失敗した層から原因を絞り、上位で見つけた不具合を下位の回帰テストへ戻します。この循環によって、生成量が増えたときの調査量の膨張を抑えられます。
冒頭で挙げた条件は、原因を一つの層へ絞れる設計と、人が判断する範囲の明文化です。機械は決めた期待値を繰り返し検証し、人はその期待値自体を問い直します。生成速度に品質保証を追いつかせるテスト戦略は、この責任分担まで含めて完成します。テストの優先順位やCI設計をチーム内だけで整理しにくい場合は、AI駆動開発の研修・導入支援・技術顧問について初回60分の無料相談を利用できます。成果の保証は伴わず、現在の開発工程に合う進め方を一緒に検討する場です。
FAQ
よくある質問
Q. AI駆動開発では、最初にどのテストを自動化すべきですか？
変更したロジックに最も近い、狭く高速なテストから始めます。次にデータベースやAPIなどの境界を確認し、最後に重要な利用経路だけをE2Eで検証します。変更内容によって最初の層は変わります。
Q. AIにテストコードも生成させれば、人のレビューは不要ですか？
不要にはなりません。AIが実装とテストの両方で同じ誤解をする可能性があるため、人は期待値の根拠、業務上の妥当性、セキュリティ、表現や操作上の違和感を確認します。
Q. E2Eテストは減らしてもよいですか？
重要な利用経路がつながる証拠は残します。ただし、細かな条件を下位層で十分に検証できるなら、同じ条件をE2Eで重複させる必要はありません。E2Eだけで見つけた不具合は、可能なら下位層へ回帰テストを追加します。
Q. CIでテストが不安定な場合はどう扱いますか？
再実行で済ませず、時刻、共有状態、ネットワーク、非同期処理の待機条件などを切り分けます。製品の不具合とテスト基盤の不安定さを同じ失敗として扱わず、診断用ログやスクリーンショットを保存します。