最終更新日：2026年9月20日
fe fe-technology software-testing quality
まず結論
回帰テスト（リグレッションテスト）は、ソフトウェアを修正・変更したあとに、以前は正常に動いていた機能へ想定外の影響が出ていないか確認するテストです。
基本情報技術者試験では、次の言い換えを見抜けるようにすると判断しやすくなります。
プログラムを修正した
↓
以前正常だった機能に影響がないか確認する
↓
回帰テスト
試験では「修正した箇所が直ったか」だけではなく、その修正によって別の場所が壊れていないかを見る点が重要です。
IPAの基本情報技術者試験シラバスでも、テストの種類の用語例として回帰テスト（リグレッションテスト）が挙げられています。
直感的な説明
例えば、ECサイトの「送料計算」の不具合を修正したとします。
修正したあとに確認したいことは2つあります。
① 送料計算そのものが直ったか
→ 修正箇所の確認
② 送料計算を直した影響で、
注文確定や決済などが壊れていないか
→ 回帰テスト
ソフトウェアでは、ある部分を変更すると、直接触っていない別の部分へ影響が出ることがあります。
そのため、
直したところ以外も、前と同じように動くか確認する
のが回帰テストです。
定義・仕組み
回帰テストは、ソフトウェアの変更によって既存機能に不具合が入り込んでいないかを確認するために行います。
変更の例には、次のようなものがあります。
- 不具合修正
- 機能追加
- 仕様変更
- リファクタリング
- ライブラリやOSの更新
- 保守作業によるプログラム変更
変更後に、以前通っていたテストを再度実行し、同じ結果になるか確認します。
何を確認する？
回帰テストで見るのは、主に次の点です。
変更した機能
＋
変更の影響を受ける可能性がある既存機能
必要に応じて、過去に実施したテストケースを再利用します。
変更範囲が小さい場合は影響がありそうな部分に絞って実施することもあり、重要な変更では広い範囲を再テストすることもあります。
なぜ必要？
ソフトウェアでは、一つの修正が別の処理に影響することがあります。
例えば、
税率計算を修正
↓
請求金額の計算結果が変わる
↓
帳票出力にも影響
というように、変更の影響が連鎖することがあります。
回帰テストでは、このような想定外の副作用を見つけます。
ISTQBの公式用語集でも、regression testing は変更後に未変更部分へ悪影響がないか確認するテストとして整理されています。
科目Aでどう出る？
科目Aでは、回帰テストの説明を選ばせる問題がよく出ます。
正しい選択肢の見つけ方
次のキーワードがあれば、回帰テストを疑います。
修正・変更した
＋
以前正常だった機能
＋
影響が出ていないか確認
例えば、
プログラムを修正したことによって、想定外の影響が出ていないか確認する
という説明は、回帰テストです。
IPAの公開問題にも、回帰テスト（リグレッションテスト）の説明を問う出題例があります。
選択肢を切る
新規に作成したモジュールの誤りを検出する
これは回帰テストの説明ではありません。
新しく作ったモジュールを個別に確認
→ 単体テスト寄り
回帰テストは、変更前から存在していた機能への影響確認が中心です。
修正によって想定外の影響が出ていないか確認する
これは回帰テストです。
修正
＋
副作用の確認
→ 回帰テスト
ホワイトボックステストに限定する
回帰テストは、ホワイトボックステストだけに限定されません。
テストの目的が「変更による影響確認」であれば、内部構造を見るかどうかとは別の分類です。
毎回テストケースを作り直す
回帰テストでは、過去に正常だったことを確認済みのテストケースを再利用することがあります。
したがって、
毎回すべて作り直す
→ 回帰テストの必須条件ではない
と判断できます。
どんな場面で使う？
回帰テストは、ソフトウェアに変更を加えたあとに使います。
例えば、
不具合を修正したあと
ログイン機能を修正
↓
ログインできることを確認
↓
会員情報表示や権限制御も壊れていないか確認
新機能を追加したあと
クーポン機能を追加
↓
既存の価格計算や決済処理に影響がないか確認
リファクタリングしたあと
見た目の機能は変えずに内部構造を変更した場合でも、既存の動作が維持されているか確認します。
ライブラリなどを更新したあと
外部ライブラリやOSの更新によって、既存機能が動かなくなることがあります。
この場合も回帰テストが有効です。
よくある誤解・混同
回帰テストと再テストは同じ？
似ていますが、見る対象が違います。
再テスト
→ 修正した不具合そのものが直ったか確認
回帰テスト
→ その修正によって他の機能が壊れていないか確認
例えば、送料計算のバグを修正した場合、
送料計算が正しくなったか
→ 再テスト
注文確定や請求書出力が壊れていないか
→ 回帰テスト
と整理できます。
回帰テストは単体テスト？
違います。
単体テストは、モジュールなど小さな単位の動作を確認するテストレベルです。
一方、回帰テストは、変更による悪影響がないかを見るテスト目的です。
そのため、
単体テスト
→ どの範囲をテストするか
回帰テスト
→ 何のためにテストするか
と考えると混同しにくくなります。
回帰テストはホワイトボックステスト？
必ずしもそうではありません。
ホワイトボックステストは、内部構造やロジックを意識してテストする方法です。
回帰テストは変更後の影響確認が目的なので、ブラックボックス的なテストでも実施できます。
全テストケースを毎回やり直す必要がある？
必ずしもありません。
理想的には広く確認できるほど安心ですが、実務では時間やコストを考え、変更の影響範囲に応じて対象を選ぶことがあります。
試験では、
過去に正常だったテストケースを再利用して、変更の影響を確認する
というイメージを持っておけば十分です。
確認問題（基本情報技術者試験対策）
あるシステムで、会員登録機能の不具合を修正した。
修正後、会員登録が正しく動くことを確認した上で、ログイン機能や会員情報表示など、以前正常に動いていた機能にも影響が出ていないことを確認した。
後半の確認に該当するテストはどれか。
- ア. 単体テスト
- イ. 回帰テスト
- ウ. 負荷テスト
- エ. 受入れテスト
▶ クリックして答えと解説を見る（ここを開く）
正解：イ（回帰テスト）
判断材料は、
修正後
＋
以前正常だった機能
＋
影響がないか確認
です。
修正した会員登録機能そのものだけではなく、ログインや会員情報表示などの既存機能へ副作用が出ていないか確認しているため、回帰テストに該当します。
まとめ（試験直前用）
- 回帰テスト＝変更後に、既存機能へ悪影響がないか確認
- 「修正」「想定外の影響」「以前正常だった機能」が判断キーワード
- 再テスト＝修正した不具合そのものが直ったか確認
- 回帰テスト＝その修正で他の機能が壊れていないか確認
- 単体テストやホワイトボックステストとは分類軸が違う
- 既存のテストケースを再利用することがある
- 「直した場所ではなく、直した影響を見る」と覚える