AIにコードを直させた後の回帰テスト｜前に動いた機能を壊していないか確かめる

AIにコードを直してもらい、問題の画面が動いたら作業を終えたくなります。しかし、直した機能だけが動いても、共通部品やデータの保存、別の画面に悪影響が出ていれば完了ではありません。修正前の失敗を再現するテストと、以前から動いていた機能を確かめる回帰テストを分け、変更箇所から周辺、全体へ順番に広げることが大切です。

この記事では、テストの本数をむやみに増やすのではなく、AIが変更した差分から壊れやすい経路を選び、結果を証拠として残す手順を紹介します。AI生成コード全般の確認項目はAI生成コードの検品チェックリストも参照してください。

回帰テストが必要な変更

回帰テストは、変更によって意図しない悪影響が生じていないかを確かめるテストです。ISTQBの公式シラバスでは、元の欠陥が直ったかを見る確認テストと、変更がほかの部分へ悪影響を与えていないかを見る回帰テストを区別しています。バグ修正後は「報告された問題が消えた」だけでなく、「変更前に正常だった経路が今も正常か」まで確認します。

特に回帰テストが必要なのは、共通関数、認証、権限、データベースの構造、入力検証、依存パッケージ、環境設定を変えたときです。見た目だけの変更でも、共通CSSやレイアウト部品なら複数ページへ影響します。ファイルが1つしか変わっていないことと、影響が1か所に限られることは同じではありません。

反対に、変更と無関係な機能を毎回すべて手作業で試すのも現実的ではありません。まず変更理由と差分を確認し、影響の強さに応じてテスト範囲を決めます。

影響範囲を洗い出す

AIの作業報告だけで判断せず、実際の変更ファイルと差分を起点にします。変更した関数や部品について、次の3方向をたどります。

1. 入力側: どの画面、API、コマンドから値が入るか
2. 処理側: 共通関数、認証、保存処理、外部サービスを共有していないか
3. 出力側: どの画面、ファイル、通知、ログへ結果が出るか

たとえばメールアドレスの入力検証を直した場合、対象フォームだけでなく、同じ検証関数を使う登録画面、変更画面、管理画面も候補になります。保存形式を変えたなら、書き込みだけでなく読み込み、一覧、検索、エクスポートまで確認対象です。

作業前に簡単な表を作ると、AIにも人にも範囲が伝わります。次は、変更内容から最低限の確認範囲を決めるための目安です。実際の範囲は、利用者への影響、変更の大きさ、共通部品の利用先に応じて調整します。

変更点	まず確かめること	周辺へ広げる範囲	全体テストの優先度
入力検証	境界値、空欄、形式違い	同じ検証を使うフォームやAPI	高
保存処理・データ構造	作成、更新、再読み込み	一覧、検索、削除、エクスポート	高
認証・権限	許可と拒否の両方	役割別画面、API、セッション更新	高
共通関数・設定・依存関係	変更箇所の単体テスト	呼び出し元、ビルド、実行環境	高
表示部品・共通CSS	対象画面の操作と表示	部品を共有する画面、画面幅の違い	中

修正前の再現条件を残す

修正を始める前に、失敗した入力、操作順、期待結果、実際の結果を残します。可能なら、その条件で失敗する自動テストを先に作ります。修正後に同じテストが通れば、少なくとも元の問題を取り違えて直した可能性を減らせます。

記録は次の形で十分です。

対象: 会員情報の更新
事前条件: 登録済みの一般ユーザーでログイン
操作: 姓を空欄にして保存
期待結果: 保存せず、姓の入力を求める
修正前の実結果: 空欄のまま保存される
確認環境: ローカル / 使用したブラウザと版は※要確認

ISTQBの公式シラバスでも、欠陥修正後の確認では、少なくとも元の失敗を再現した手順を新しい版で再実行する考え方が示されています。AIへ修正を頼むときは、この再現条件と変更してよい範囲を一緒に渡します。依頼の具体例はCodexへテストを依頼する書き方にまとめています。

正常系と異常系を選ぶ

正常系は代表的な入力で目的の操作が完了するか、異常系は空欄、形式違い、上限超過、権限不足、保存失敗などを安全に扱えるかを見るテストです。修正した条件だけに寄せず、その前後の値も選びます。

数値の上限を100へ直したなら、100だけでなく99、101、空欄、文字列を試します。権限の修正なら、許可された利用者と拒否される利用者の両方が必要です。保存処理なら、成功時だけでなく通信や保存が失敗したときに、途中データや秘密情報を残さないかも確認します。

先に期待結果を書いてから実行してください。結果を見た後で期待値を変えると、誤った実装を正解として受け入れやすくなります。画面のテストでは、内部の関数名やCSSのクラス名ではなく、利用者が見る表示と操作を確かめます。Playwright公式のベストプラクティスも、実装詳細ではなく利用者から見える振る舞いをテストすることを勧めています。

変更箇所から近い順に試す

最初から時間のかかる全体テストだけを回すと、失敗原因を絞りにくくなります。次の順番なら、早い段階で修正ミスを見つけやすくなります。

1. 元の不具合を再現するテスト
2. 変更した関数や部品の単体テスト
3. 直接呼び出す画面やAPIのテスト
4. 共通部品を使う周辺機能のテスト
5. プロジェクト全体のテスト

使えるコマンドはプロジェクトの設定によって異なるため、package.jsonやテスト設定にある既存コマンドを優先します。Vitestを導入済みならファイルパスやテスト名で対象を絞れます。pytestもファイル、ディレクトリ、-kによる名前指定を公式に案内しています。

# 例: Vitestを導入済みのプロジェクトで対象ファイルを実行
npx vitest run src/example.test.ts

# 例: pytestで対象ファイルを実行
pytest tests/test_example.py

これらはそのまま全プロジェクトで使える保証はありません。既存のテストランナー、設定、依存関係を確認し、未導入の道具をテストのためだけに勝手に追加しないでください。

全体テストへ広げる基準

近いテストが通ったら、共通部品を利用する範囲、ビルド、静的解析、全体テストへ広げます。少なくとも、共通関数や設定を変更した場合、依存関係を更新した場合、認証・権限・保存形式へ触れた場合は、局所テストだけで終えない方が安全です。

全体テストが長いプロジェクトでは、「手元では近いテストを先に実行し、変更を統合する前にCIで全体を実行する」と役割を分けられます。ただし、CIが通ったという表示だけでなく、何件が実行され、スキップや失敗がなかったかをログで確認します。テストの隔離も重要です。Playwright公式資料では、各テストを独立させることで再現性を高め、連鎖的な失敗を防ぎやすくなると説明しています。

テストが不安定なときに、理由を調べず再実行して成功回だけを採用してはいけません。データの使い回し、実行順への依存、時刻、通信待ちなどを切り分け、同じ条件で再現できる状態へ戻します。

Playwrightの公式資料では、再実行後に通ったテストを、最初から通ったテストとは分けて「flaky（不安定）」として扱います。再実行は調査材料にはなりますが、最初の失敗を消すものではありません。初回結果、再実行結果、失敗時のログを残し、原因を直すまでは未解決として扱います。

証拠を残して完了する

完了時には「テスト済み」ではなく、対象、コマンド、終了結果、実行件数、失敗・スキップ、確認環境を残します。画面操作なら期待した表示の記録、CIならテスト結果やログを保存します。GitHub Actionsの公式ドキュメントでは、ビルドやテストの出力を成果物として保存し、失敗の調査やカバレッジの確認に利用できると案内しています。ワークフロー実行ログは、ジョブごとに表示、検索、ダウンロードできます。

変更: 入力検証とエラー表示
再現テスト: 合格
周辺テスト: 合格
全体テスト: 合格 / 実行件数は※要確認
実行コマンド: ※要確認
失敗・スキップ: ※要確認
未確認: 実機環境での表示

未実行の確認は空欄にせず、「未確認」と明記します。AIには成功した結果だけでなく、失敗したコマンドと残ったリスクも報告させてください。修正の差分自体を見直す場合はCodexにコードレビューを任せる手順も利用できます。

回帰テストの目的は、本数を増やして安心感を作ることではありません。元の問題が直った証拠と、変更前に動いていた重要な経路が今も動く証拠を、同じ条件で再現できる形にすることです。

よくある質問

回帰テストと再テストの違いは何ですか

元の不具合が直ったかを同じ条件で確かめるのが確認テスト（再テスト）、修正によって既存機能へ悪影響が出ていないかを確かめるのが回帰テストです。バグ修正後は両方を行います。

小さな修正でも回帰テストは必要ですか

変更ファイルが1つでも、共通関数、共通CSS、設定、認証、保存処理を通じて影響が広がることがあります。まず差分と利用先を確認し、影響が局所的なら近いテストへ範囲を絞ります。

回帰テストはどこまで実行すればよいですか

元の再現テスト、変更箇所のテスト、直接の利用先、共通部品を使う周辺機能の順に広げます。認証、権限、データ構造、共通設定、依存関係を変えた場合は、ビルドや全体テストまで進める優先度が高くなります。

自動テストがない場合はどうすればよいですか

まず再現条件、操作、期待結果、実際の結果を手順として固定し、手動で確認します。繰り返し発生しうる不具合や重要な経路から、自動テストへ置き換える候補にします。

再実行して通れば合格にしてよいですか

初回に失敗した事実は残ります。再実行後に通った場合も不安定なテストとして記録し、データ、実行順、時刻、通信待ちなどの原因を切り分けます。

関連記事

• GitHub Actionsがローカルだけ成功するときの確認手順
• Windowsで終了コードを確認する方法
• AIコーディングの引き継ぎメモの作り方

一次情報の確認メモ

• 確認日: 2026-07-24 / ISTQB Certified Tester Foundation Level Syllabus v4.0.1（確認テストと回帰テスト）: https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
• 確認日: 2026-07-24 / Playwright Best Practices（利用者から見える振る舞い、テストの独立性）: https://playwright.dev/docs/best-practices
• 確認日: 2026-07-24 / Playwright Retries（初回成功、不安定、失敗の分類）: https://playwright.dev/docs/test-retries
• 確認日: 2026-07-24 / Vitest Test Filtering（ファイルパス・テスト名による絞り込み）: https://vitest.dev/guide/filtering
• 確認日: 2026-07-24 / pytest How to invoke pytest（ファイル・ディレクトリ・-kによる選択）: https://docs.pytest.org/en/stable/how-to/usage.html
• 確認日: 2026-07-24 / GitHub Docs「Store and share data with workflow artifacts」（テスト出力の保存）: https://docs.github.com/en/actions/tutorials/store-and-share-data
• 確認日: 2026-07-24 / GitHub Docs「Using workflow run logs」（ジョブログの表示・検索・ダウンロード）: https://docs.github.com/en/actions/how-tos/monitor-workflows/use-workflow-run-logs