評価・安全性

回帰テストとは

この記事の結論

回帰テストとは、コードを変えた後に、それまで正しく動いていた部分が今も同じように動くかを確かめ直すテストのことです。
特別な種類のテストではなく、目的による呼び名です。すでにあるテスト一式を、変更のたびに流し直すことが回帰テストになります。
AIに修正を任せるときは、修正の前後で同じテストを実行させ、両方の結果を見比べるのが基本です（2026-09-26 時点の整理）。

かいきてすと／Regression Test

コードを変えた後に、それまで正しく動いていた部分が今も同じように動くかを確かめ直すテストのことです。

最終更新: 2026-09-26

回帰テストとは（意味と読み方）

回帰テスト（かいきてすと）とは、コードを変えた後に、それまで正しく動いていた部分が今も同じように動くかを確かめ直すテストです。英語の Regression Test から、リグレッションテストとも呼ばれます。

regression は「後戻り」を意味します。機能を足したり不具合を直したりした結果、動いていたものが動かなくなることを指し、日本の現場では「デグレ」と略して呼ぶこともあります。

壊れるのは変更した場所とは限らず、その場所に頼っていた別の場所のこともあります。そのため回帰テストは、変えていない部分まで含めて確かめます。

回帰テストの仕組み

流れは4段です。

変更する前に、テスト一式がすべて通ることを確かめる
コードを変更する
同じテスト一式をもう一度流す
前は通って今は落ちるテストがあれば、今回の変更が原因と見当を付けて調べる

この仕組みが役に立つのは、テストを頻繁に流すときです。Martin Fowler は「SelfTestingCode」（2014年）で、少なくとも1日に数回テスト一式を流せば、不具合を持ち込んだ直後に気づけて、直近の変更だけを見れば原因を探せる、と書いています。

毎回の実行を人の手に頼らない方法が、CI/CDの CI（継続的インテグレーション）です。GitHub Docs の継続的インテグレーションの解説は、コミットするたびにビルドとテストを継続的に行い、そのコミットがエラーを持ち込んでいないかを確かめられる、と説明しています。

AI開発での回帰テストの具体例

AIコーディングエージェントに検索機能の不具合を直させる場面で考えます。依頼文に次の3点を入れます。

修正の前に：npm test を実行し、結果をそのまま貼る
不具合を再現するテストを先に足す：今は落ちることを確かめてから直す
修正の後に：同じ npm test をもう一度実行し、結果を貼る

前後の結果を並べれば、直したテストが通るようになったことと、ほかのテストが落ちていないことを一度に確かめられます。足したテストはそのまま残り、同じ不具合が戻ってきたときに知らせる回帰テストになります。

壊れたことに気づいたのが何回も変更した後なら、git bisect が使えます。二分探索で、不具合を持ち込んだコミットを絞り込むコマンドです。git bisect run npm test のように判定用のコマンドを渡すと、終了コード 0 を「正常」、125 を除く 1〜127 を「不具合あり」として自動で探します。

回帰テストのよくある誤解

誤解：回帰テストという特別なテストを別に書く → 実際：単体テストでも画面を通しで動かすテストでも、変更のたびに流し直せば回帰テストとして働きます。呼び名は目的を表しています。
誤解：変更した箇所だけ確かめればよい → 実際：変えていない側が壊れることもあるため、一式を流し直します。
誤解：AIが「テストは全部通りました」と言えば安心 → 実際：テストの期待値が書き換えられたり、テストが消されたりして通っている場合もありえます。差分でテストファイルが変わっていないかを確かめます。
誤解：手作業の確認は回帰テストではない → 実際：決まった手順で同じ操作を確かめ直すなら、手作業でも回帰テストです。ただ毎回の負担が大きいので、繰り返すものから自動化します。

回帰テストを続けるコツ

直した不具合には再発防止のテストを1本足す：同じ不具合が後の変更で戻ってきたときに、すぐ気づけます。
速く終わるテストを中心にする：実行に時間がかかると流す回数が減り、気づくのが遅れます。
完成の条件をテストに写す：受け入れ基準を確かめるテストを書いておくと、一度満たした条件が後の変更で崩れていないかを見張れます。

出典・参考資料

SelfTestingCode（Martin Fowler, 2014年）：自動テストを頻繁に流すことで、不具合を持ち込んだ直後に気づけるという考え方。
継続的インテグレーション（GitHub Docs）：コミットごとにビルドとテストを行う仕組みの説明。
git-bisect（Git 公式ドキュメント）：不具合を持ち込んだコミットを二分探索で探す方法と、終了コードの扱い。

よくある質問

Q1. 回帰テストとは何ですか？
コードを変えた後に、それまで正しく動いていた部分が今も同じように動くかを確かめ直すテストです。英語の Regression Test から、リグレッションテストとも呼ばれます。

Q2. 回帰テストと単体テストはどう違いますか？
単体テストは関数などの小さな単位を確かめるという「範囲」による呼び名で、回帰テストは変更で既存の動きが壊れていないかを見るという「目的」による呼び名です。単体テストを変更のたびに流し直せば、それが回帰テストになります。

Q3. 回帰テストはいつ実行すればよいですか？
コードを変えるたびに実行します。変更の直後に流せば、落ちたテストの原因を直近の変更の中から探せます。毎回の実行はCIで自動にしておくと、流し忘れを防げます。

Q4. AIに修正を頼むとき、回帰テストはどう使えばよいですか？
修正の前と後で同じテストを実行させ、両方の結果を貼ってもらいます。あわせて差分を見て、テストの期待値が書き換えられていないか、テストが消されていないかを確かめます。