ソフトウェアに新機能を追加したりバグを修正したりするたびに、「直したはずなのに別の箇所が壊れた」という経験は開発現場で珍しくありません。こうした意図しない副作用を検出する手段がリグレッションテスト（回帰テスト）です。
リグレッションテスト（回帰テスト）の定義
リグレッションテストは、プログラムへの変更が既存機能に予期しない影響を与えていないかを確認するソフトウェアテスト手法です。英語の「regression」は「後退・回帰」を意味し、コード変更によってソフトウェアの品質が後退していないかを検証することからこの名前が付いています。
ISTQB（国際ソフトウェアテスト資格認定委員会）の用語集では、リグレッションテストを「以前テスト済みのプログラムに対し、変更後に実施するテストであり、変更の結果としてソフトウェアの未変更部分に欠陥が混入していない、または露呈していないことを確認するもの」と定義しています（出典: ISTQB Glossary）。日本におけるJSTQB Foundation Levelシラバス（Version 2023 V4.0）でも同様の定義が採用されており、すべてのテストレベル（単体テスト・結合テスト・システムテスト）で実施すべき確認テストとして位置づけられています（出典: JSTQB）。
よく使われる別称
リグレッションテストにはいくつかの呼び名があります。
| 呼称 | 使用されるコンテキスト |
|---|---|
| 回帰テスト | JIS・JSTQBの和訳で使用される正式な訳語 |
| デグレードテスト | 日本の開発現場で広く使われる通称 |
| ノンデグレードテスト | 「デグレが起きていないこと」を確認する意味で使われる |
| 退行テスト | 一部の文献・現場で用いられる |
| 無影響確認テスト | 金融業界など規制が厳しい分野で使われる |
リグレッションテストを省略するとどうなるか
リグレッションテストを実施しない場合、プロジェクトには以下のリスクが生じます。
本番障害の発生確率が上昇する: 変更箇所と直接関係のないモジュールにバグが潜むケースは、依存関係が複雑なシステムほど多くなります。テストを省略すると、これらの潜在バグがリリース後に顕在化し、ユーザーからの問い合わせや緊急対応に追われることになります。
修正コストが膨張する: ソフトウェア開発では、バグの発見が遅れるほど修正コストが指数関数的に増大するという経験則があります。開発フェーズで発見できた欠陥を本番で検出した場合、修正にかかるコストは数十倍に跳ね上がることもあります。
セキュリティ脆弱性の放置: 認証やアクセス制御まわりの変更が別の機能に影響を与え、意図しないセキュリティホールが生まれるケースがあります。リグレッションテストはこうした脆弱性を早期に検出するセーフティネットとして機能します。
信頼の毀損: 繰り返し障害が発生するソフトウェアは、エンドユーザーやステークホルダーからの信頼を失います。品質に対する信頼は一度損なわれると取り戻すのに長い時間がかかります。
実施タイミングと各テストレベルでの位置づけ
リグレッションテストはプログラムに変更を加えた後のテスト工程で実施するのが基本です。具体的なタイミングを整理します。
テストレベルごとの役割
| テストレベル | リグレッションテストの対象 | 代表的な手法 |
|---|---|---|
| 単体テスト | 修正した関数・メソッドに関連するユニットテスト | 自動テスト（xUnit系フレームワーク） |
| 結合テスト | 修正モジュールと連携するモジュール間のインターフェース | API テスト・インテグレーションテスト |
| システムテスト | 修正によるシステム全体の振る舞いへの影響 | E2Eテスト・手動探索テスト |
| 受入テスト | ビジネス要件の充足確認 | ユーザーシナリオベースのテスト |
ウォーターフォール型とアジャイル型での違い
ウォーターフォール型開発では、各テストフェーズの完了前にリグレッションテストを実施します。変更のスコープが大きいため、テスト範囲も広くなる傾向があります。
アジャイル開発（スクラム等） では、スプリントごとにリグレッションテストを繰り返し実施します。変更が頻繁に発生するため、テストの自動化が特に重要です。CI/CDパイプラインに自動テストを組み込み、コミットのたびにリグレッションテストを実行するアプローチが一般的になっています。
テスト観点と範囲の決め方
リグレッションテストのテスト範囲を決める際、「すべてを再テストする」のは非効率です。影響範囲分析（Impact Analysis）とリスクベースドテスティングの考え方を組み合わせて、テスト対象を絞り込みます。
影響範囲分析のアプローチ
- 変更箇所の特定: コードの差分（diff）からどのモジュール・関数が変更されたかを把握する
- 依存関係のトレース: 変更モジュールを呼び出している上位モジュール、および変更モジュールが呼び出す下位モジュールを洗い出す
- データフローの確認: 共有データベーステーブル・ファイル・APIエンドポイントなど、変更の影響が伝播する経路を確認する
リスクベースで優先順位をつける
すべてのテストケースを実行する時間がない場合、以下の基準で優先度を設定します。
- 重要度が高い業務機能: 売上に直結するEC決済フロー、個人情報を扱う認証機能など
- 過去にバグが頻発した領域: 障害履歴から「壊れやすい」モジュールを特定する
- 変更との結合度が高い部分: モジュール間の結合度（カップリング）が強い箇所ほど副作用のリスクが高い
- 利用頻度が高い機能: ユーザーが日常的に利用する画面・機能はバグ発生時の影響範囲が大きい
具体的なテスト観点リスト
| 観点カテゴリ | 確認内容の例 |
|---|---|
| 機能の正常系 | 変更前と同じ入力で同じ結果が得られるか |
| 境界値・異常系 | エラー処理や入力制限が変更前と同じ動作をするか |
| パフォーマンス | レスポンスタイムやスループットに劣化がないか |
| UI/UX | 画面レイアウト崩れ・表示テキストの変化がないか |
| データ整合性 | DB登録値・API応答値が変更前と一致するか |
| セキュリティ | 認証・認可・入力バリデーションに穴がないか |
| 外部連携 | 外部APIやバッチ処理との連携に支障がないか |
リグレッションテストとデグレードテストの違い
開発現場では「リグレッションテスト」と「デグレードテスト」が混同されがちですが、厳密には異なる概念です。
| 比較項目 | リグレッションテスト | デグレードテスト |
|---|---|---|
| 定義 | 変更が既存機能に予期しない影響を与えていないか確認するテスト | ソフトウェアの品質や機能が以前のバージョンより低下（デグレード）していないか確認するテスト |
| 英語名 | Regression Testing | Degradation Testing（和製英語的な用法） |
| ISTQB用語集 | 正式に定義されている | 正式には定義されていない（日本独自の慣用表現） |
| 焦点 | 変更による「意図しない副作用」の検出 | 変更による「品質低下」の検出 |
| 実務上の違い | ほぼ同義として使われることが多い | 特に日本の開発現場で多く使われる |
実務上はほぼ同じ意味で使われるケースが大半ですが、厳密にはリグレッションテストのほうがISTQB/JSTQBで正式に定義された国際標準の用語です。
再テスト（確認テスト）との違い
リグレッションテストと混同されやすいのが「再テスト（Confirmation Testing / Re-testing）」です。
- 再テスト: 報告された特定のバグが修正後に正しく直っているかを確認するテスト
- リグレッションテスト: バグ修正や機能追加が、修正箇所以外の部分に新たな問題を引き起こしていないかを確認するテスト
つまり再テストは「修正箇所そのもの」に焦点を当て、リグレッションテストは「修正箇所以外への影響」に焦点を当てています。バグ修正後にはまず再テストを実施し、次にリグレッションテストを実施するのが標準的な流れです。
リグレッションテスト自動化の進め方
リグレッションテストは繰り返し実行される性質上、自動化との相性が優れています。手動で毎回同じテストケースを実行するのは時間もコストもかかるため、段階的な自動化が効率化の鍵になります。
テストピラミッドに基づく自動化戦略
テストの自動化を設計する際は、Mike Cohnが著書『Succeeding with Agile』で提唱した「テストピラミッド」の考え方が参考になります。
/ E2E \ ← 少数・遅い・高コスト
/ テスト \
/──────────\
/ 結合テスト \ ← 中程度
/──────────────\
/ 単体テスト \ ← 多数・高速・低コスト
/──────────────────\
- 土台（単体テスト）: 最も多く・最も高速に回す。変更による影響を関数・メソッド単位で即座に検出する
- 中間層（結合テスト / APIテスト）: モジュール間のインターフェースを検証する。E2Eより高速で安定性が高い
- 頂点（E2Eテスト）: ユーザー操作をシミュレートする。実行に時間がかかるため、重要なビジネスシナリオに絞って実装する
自動化に向くテスト / 向かないテスト
| 自動化に向くテスト | 自動化に向かないテスト |
|---|---|
| 同じ手順を繰り返し実行するテスト | 実行するたびに手順や判断が変わる探索的テスト |
| 入出力が明確で結果を機械的に判定できるテスト | ユーザビリティや見た目の主観的な評価 |
| ビルドごとに必ず実行する回帰確認 | 一度だけ実施すれば十分なテスト |
| 大量のデータパターンの組み合わせテスト | テスト環境の準備に特殊な手動操作が必要なテスト |
CI/CDパイプラインとの統合
テスト自動化の効果を最大限に発揮するには、CI/CD（継続的インテグレーション / 継続的デリバリー）パイプラインへの組み込みが重要です。以下はGitHub Actionsを利用した例です。
# .github/workflows/regression-test.yml
name: リグレッションテスト
on:
pull_request:
branches: [main, develop]
push:
branches: [main]
jobs:
unit-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: '20'
- run: npm ci
- run: npm test
integration-test:
needs: unit-test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: '20'
- run: npm ci
- run: npm run test:integration
e2e-test:
needs: integration-test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: '20'
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
このワークフローでは、プルリクエストの作成やmainブランチへのプッシュをトリガーに、単体テスト → 結合テスト → E2Eテストの順で段階的にリグレッションテストを実行します。前段のテストが失敗した場合は後段のテストをスキップし、フィードバックを素早く返す設計になっています。
主要なテスト自動化ツール比較
リグレッションテストを自動化するためのツールは数多く存在します。プロジェクトの技術スタックや要件に応じて適切なツールを選定することが大切です。
オープンソースのテスト自動化フレームワーク
| ツール名 | 対応言語・プラットフォーム | 特徴 | 公式サイト |
|---|---|---|---|
| Selenium | Java, Python, C#, JavaScript 等 | Webアプリ向けUIテスト自動化の老舗。ブラウザ互換性が高い | https://www.selenium.dev/ |
| Playwright | JavaScript/TypeScript, Python, Java, C# | Microsoft製。マルチブラウザ対応、自動待機機能が充実 | https://playwright.dev/ |
| Cypress | JavaScript/TypeScript | フロントエンド特化。テスト実行の様子をリアルタイムで確認できるデバッグ機能が強力 | https://www.cypress.io/ |
| pytest | Python | Pythonエコシステムの標準テストフレームワーク。プラグインで拡張可能 | https://docs.pytest.org/ |
| JUnit | Java | Javaエコシステムの標準。JUnit 5はモジュール化されテストの柔軟性が向上 | https://junit.org/junit5/ |
商用（SaaS）テスト自動化プラットフォーム
| ツール名 | 特徴 | 想定ユーザー |
|---|---|---|
| Autify | ノーコードでE2Eテストを作成可能。AIがUI変更を自動検出してテストを修復する「自己修復」機能を搭載 | テストコードを書かずに自動化を始めたいチーム |
| MagicPod | モバイルアプリ（iOS/Android）とWebの両方に対応。AIによるテストメンテナンス支援 | モバイルアプリの回帰テストを効率化したいチーム |
| mabl | AIを活用したテスト自動化プラットフォーム。ローコードでテスト作成が可能。自動修復機能を備える | CI/CDとシームレスに統合したいチーム |
ツールを選定する際のチェックポイントは以下の通りです。
- 技術スタックとの相性: プロジェクトで使用している言語・フレームワークに対応しているか
- 学習コスト: チームメンバーが短期間で習熟できるか
- CI/CDとの連携: Jenkins、GitHub Actions、GitLab CI などの既存パイプラインとの統合が容易か
- メンテナンスコスト: UIの変更に追従しやすいか。自己修復機能の有無
- レポーティング: テスト結果の可視化や障害の切り分けが容易か
よくある質問（FAQ）
Q. リグレッションテストとデグレテストの違いは？
リグレッションテストはISTQB/JSTQBで正式に定義された国際標準用語で、「変更による意図しない副作用の検出」を目的としたテストです。デグレードテスト（デグレテスト）は日本の開発現場で広く使われる表現で、品質が「デグレード（低下）」していないかを確認する意味合いで使われます。実務上はほぼ同義です。
Q. リグレッションテストはいつ実施すべき？
基本的にはプログラムに変更を加えた後のテスト工程で実施します。具体的には、バグ修正後の確認テスト実施後、新機能の追加後、リファクタリング後、外部ライブラリのアップデート後、環境移行後などが該当します。アジャイル開発ではスプリントごと、CI/CD環境ではコミットごとに自動実行するのが理想的です。
Q. リグレッションテストと無影響確認テストの違いは？
意味はほぼ同じです。「無影響確認テスト」は特に金融業界やセキュリティ要件が厳しい分野で使われる用語で、変更が既存機能に悪影響を及ぼしていないことを確認するテストを指します。テストの目的や手法はリグレッションテストと同一です。
Q. リグレッションテストの範囲はどこまでやるべき？
理想は全テストケースの再実行ですが、現実には時間やコストの制約があります。影響範囲分析（Impact Analysis）で変更箇所の依存関係を洗い出し、リスクベースで優先順位をつけて範囲を決定するのが実践的です。コア機能のテストは毎回実行し、周辺機能は変更内容に応じて取捨選択するアプローチが一般的です。
Q. 単体テストとリグレッションテストの違いは？
単体テストは関数やメソッド単位で動作を検証する「テストレベル」の分類です。一方リグレッションテストは「変更による副作用がないか確認する」という「テスト目的」の分類であり、単体テストレベルでもリグレッションテストは実施されます。つまり両者は対立する概念ではなく、単体テストの中にリグレッションテストが含まれることもあります。
まとめ
リグレッションテスト（回帰テスト）は、ソフトウェアの変更が既存機能を壊していないかを確認する品質保証の基本です。
押さえておくべきポイントを整理します。
- リグレッションテストは「変更による副作用検出」が目的で、ISTQB/JSTQBの国際標準で定義されたテスト手法
- デグレードテスト・ノンデグレードテスト・無影響確認テストはいずれもほぼ同義の用語
- すべてのテストレベル（単体・結合・システム・受入）で実施すべきもの
- テスト範囲は影響範囲分析とリスクベースの優先順位付けで効率的に決定する
- 繰り返し実行する性質上、テスト自動化との相性がよい
- CI/CDパイプラインに組み込むことで、変更のたびに自動的に回帰確認が走る開発体制を構築できる
テスト自動化ツールの選択肢は、Selenium・Playwright・Cypressなどのオープンソースから、Autify・MagicPod・mablなどのSaaSプラットフォームまで幅広く存在します。プロジェクトの技術スタックやチームのスキルセットに合わせて選定し、テストピラミッドの考え方に沿って段階的に自動化を進めていくことが、効率的なリグレッションテスト運用への近道です。