回帰テスト（リグレッションテスト）とは
回帰テスト（リグレッションテスト）とは、システムに機能を追加したり不具合を修正したりしたあとに、それまで正しく動いていた既存の機能が、変更の影響で壊れていないかを確かめるテストです。
平易に言えば「台所の蛇口を直したら、お風呂のお湯が出なくなっていないかを確かめる」ことです。ある場所の修正が、思いがけない別の場所に影響を与えることは、システムでもよく起こります。
英語の regression は「後退、退行」という意味で、一度できていたことができなくなる状態を指します。開発の現場では、変更によって既存機能が壊れることを「デグレ（デグレード）」と呼び、回帰テストはデグレを見つけるためのテストと言い換えられます。
仕組み・ポイント
回帰テストは、新しい機能そのものを確かめるテストとは目的が異なります。
| テスト | 目的 | 対象 |
|---|---|---|
| 新機能のテスト | 追加した機能が仕様どおりに動くか | 今回作ったところ |
| 回帰テスト | 既存の機能が変わらず動くか | 今回は触っていないはずのところ |
システムが育つほど既存の機能は増えるため、回帰テストの対象も増え続けます。毎回すべてを手作業で確認するのは現実的ではなく、次のような工夫で範囲と方法を決めます。
- 影響範囲から選ぶ：変更した部品を使っている機能を洗い出し、重点的に確認する
- 重要度から選ぶ：ログイン、決済、締め処理など、止まると影響が大きい機能は毎回必ず確認する
- 自動化する：毎回確認する項目はテスト自動化の対象にする
- 過去の不具合を加える：一度起きた不具合を再現する確認を追加し、再発を防ぐ
自動化された回帰テストは、変更のたびに自動で実行され、既存機能が壊れたときにすぐ気づけるようにします。画面操作を含む重要な流れはE2Eテストで、計算や業務ルールは単体テストで確かめる、という組み合わせが一般的です。
実務での使い方・具体例
ある会社の販売管理システムで、取引先ごとの値引きルールを追加したところ、請求書の合計金額の計算が一部の取引先で変わってしまった、という事態が起きた場面を考えます。変更した担当者は請求書の機能には手を入れていないつもりでした。
再発を防ぐための回帰テストの整え方の例です。
- 請求、在庫、受注など、主要な機能ごとに「毎回確認すべきこと」の一覧を作る
- 金額計算のように間違いが許されない処理は、代表的な取引条件の組み合わせで自動テストを書く
- 今回の不具合を再現するテストを追加する
- 変更のたびに自動で回帰テストが実行される仕組みにする
- 自動化していない項目は、リリース前に手順書に沿って手で確認する
一覧を作るときは、業務を最もよく知る現場の担当者に「これが間違っていたら困る」という場面を挙げてもらうのが近道です。開発者だけで作ると、技術的には重要でも業務上はあまり使われない機能に偏ることがあります。発注側が確認項目づくりに関わることで、守るべき機能の優先度が業務の実態に合ったものになります。
保守契約の中での位置づけ
運用中のシステムでは、OSやライブラリの更新、小さな改修が定期的に発生します。そのたびに回帰テストが必要になるため、保守契約の中で「どの範囲の回帰テストを、誰が、どの環境で行うか」を明確にしておくことが大切です。回帰テストの範囲があいまいなまま改修を依頼すると、確認が不十分なまま本番に反映され、不具合の原因の切り分けや責任の所在でもめることがあります。
よくある誤解と注意点
- 変更した箇所だけ確認すれば十分、ではない：影響は思わぬところに出ます。変更箇所とつながりのある機能、重要な機能は必ず確認します。
- 毎回すべてを手作業で確認する：時間がかかりすぎて、結局は省略されがちです。繰り返す確認は自動化し、手作業は絞ります。
- テストの一覧が更新されない：機能を追加しても回帰テストの一覧に加えないと、守られない機能が増えていきます。機能追加とテストの追加をセットにします。
- 確認結果を記録しない：手作業の回帰テストで、何を確認して問題なかったのかが残っていないと、後で不具合が見つかったときに原因の時期を絞り込めません。確認した項目と結果を簡単でも記録します。
- ライブラリ更新も対象：プログラムを直接変えていなくても、OSやライブラリの更新で動きが変わることがあります。更新時にも回帰テストを行います。
関連用語
- テスト自動化：回帰テストを効率よく続けるための手段
- E2Eテスト（エンドツーエンドテスト）：重要な流れの回帰テストに使われるテスト
- ロールバック：回帰テストで見逃した不具合が本番で出たときに前の状態へ戻す手段
- デプロイ：回帰テストを通過した変更を環境に反映する作業
- 実践記事：ライブラリ更新を放置するリスクと、計画的なアップデートの進め方
Otsumuに相談できること
改修のたびに既存機能が壊れる、保守の中で回帰テストの範囲が決まっていない、といった課題に対して、確認項目の整理から自動化、保守の進め方の見直しまで支援しています。詳しくは保守・運用をご覧ください。
30分の無料相談で、これまでの不具合の傾向と現在の確認方法を伺います。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01