移行のリグレッションテスト｜新旧で挙動が一致するか確かめる方法

移行におけるリグレッションテスト（回帰テスト）とは、新システムが旧システムと同じ入力に対して、同じ結果・同じ挙動を返すかを確かめるテストです。 日本の現場では「現新比較テスト」「新旧比較」とも呼ばれます。

通常の開発では、回帰テストは「一部を直したら、他が壊れていないか」を確認するものです。一方、マイグレーションでは言語・フレームワーク・DB・インフラがまとめて変わります。つまり、壊れる可能性があるのはシステム全体です。

そのため、移行のリグレッションテストでは、次の3点を最初に決める必要があります。

• 守るべき挙動の範囲（現行踏襲の範囲）
• 新旧を比べるポイント
• 「一致した」と判断する合格基準

本記事は、マイグレーションテストの進め方｜ゴールデンデータと4つの品質軸の関連記事として、回帰テストの部分を掘り下げます。

1. マイグレーションにおけるリグレッションテストとは

まずは、移行のリグレッションテストが通常の回帰テストとどう違うのかを整理します。違いを押さえると、なぜ移行で「デグレ」が起きやすいのかも見えてきます。

1-1. 通常開発の回帰テストとの違い：変わるのは「一部」ではなく「全体」

通常開発のリグレッションテストは、修正箇所の周辺に影響がないかを確認します。正解は仕様書や既存のテストケースにあります。

移行では、変わるのはシステム全体です。そして多くの場合、仕様書は古いか、残っていません。頼れる正解は「旧システムが実際にどう動くか」になります。

用語も混同されやすいため、次に整理しておきます。

1-2. 現新比較テスト・新旧比較・デグレテストとの関係

似た言葉が多いですが、関係はシンプルです。

• リグレッションテスト（回帰テスト）：挙動が「後退」していないかを確かめる目的
• 現新比較テスト／新旧比較テスト：同じ入力を新旧に与え、結果を突き合わせる手法
• デグレ（デグレード）：変更によって以前の挙動が損なわれる不具合

つまり、移行のリグレッションテストは、主に現新比較という手法で実施され、デグレを見つけることが目的です。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド」でも、現行システムと新システムで同じ動作結果となっているかを確認するテストとして、現新比較テストが取り上げられています。用語の国際的な定義は、ISTQB用語集も参考になります。

では、なぜ移行ではデグレがこれほど起きやすいのでしょうか。

1-3. なぜ移行プロジェクトではデグレが起きやすいのか

主な原因は、次の5つです。

1. 仕様書が古い、または残っていない：長年の改修で、システムがブラックボックス化している
2. 暗黙の仕様がコードにしかない：端数処理、並び順、NULLの扱いなど
3. 言語・ライブラリ・DBの違い：日付型、文字列比較、浮動小数点の挙動が変わる
4. 文字コードの変換：Shift_JISからUTF-8への変換や、外字の扱い
5. AIによるコード変換：もっともらしいが誤った変換が混じる（参考：生成AIマイグレーションのハルシネーション対策）

失われた設計情報は、AIリバースエンジニアリングによる設計書の復元で補うこともできます。ただし、最後に挙動を保証するのはリグレッションテストです。

2. 最初に決めるべきこと：「守る挙動」と「変えてよい挙動」

移行のリグレッションテストで最も多い混乱は、「どこまで旧システムと同じにするのか」が決まっていないことです。テストを書く前に、まずこの線引きを行います。

2-1. 現行踏襲の範囲を合意する

「現行どおり」という言葉は、人によって意味が違います。画面の見た目まで同じなのか、計算結果だけ同じでよいのか。ここが曖昧なままだと、差異が出るたびに議論が起きます。

IPAのユーザガイドでも、現行踏襲内容の明確化は再構築のリスク対策の重要な観点とされています。機能ごとに、次の3段階で合意しておくと判断がぶれません。

• 完全一致：出力の値・形式とも旧システムと同じ（例：請求金額、帳票）
• 結果一致：値は同じだが、表示形式やUIは変更可（例：画面レイアウト）
• 変更予定：移行に合わせて意図的に変える（例：廃止する機能）

合意には、情報システム部門だけでなく業務部門の承認者を入れることが重要です。

ただし、旧システムの挙動がすべて正しいとは限りません。次はその扱いです。

2-2. 旧システムの既知バグ・法改正対応はどう扱うか：「意図的な差異リスト」

旧システムは比較の基準（ベースライン）ですが、正しさそのものではありません。既知のバグや、法改正・税率変更に未対応の処理が残っていることもあります（参考：テストが「PASS」でも品質を証明できない理由）。

そこで、新旧であえて変える挙動を「意図的な差異リスト」として先に登録します。

こうしておけば、比較で差異が出ても「リストにある差異か」で即座に判断できます。

2-3. 挙動の棚卸し：画面・帳票・バッチ・API・データ

最後に、守るべき挙動を対象ごとに洗い出します。

この棚卸しは、移行前のレガシーシステムアセスメントと一緒に進めると効率的です。

3. 移行で確認すべきリグレッションテストの観点

守る範囲が決まったら、次は「何を比べるか」です。移行のリグレッションテストでは、機能だけを見ていると見落としが出ます。4つの観点で確認しましょう。

3-1. 機能の回帰：出力値・業務ルール・境界値

最も基本となる観点です。

• 計算結果（金額、数量、ポイントなど）
• 業務ルールの分岐（顧客区分、地域、期間による条件）
• 境界値（月末・年度末、上限値、0件）
• エラー時の挙動とメッセージ

特に境界値は、言語やライブラリの違いで差異が出やすい部分です。

3-2. データの回帰：件数・合計値・文字コード・丸め・和暦

日本のシステム移行で、特に差異が出やすいのがデータです。

• 件数・合計値（コントロールトータル）の一致
• 端数処理：四捨五入・切り捨て・切り上げの違い
• 和暦・日付：元号、うるう年、日付の境界
• 文字コード：外字、全角・半角、機種依存文字
• NULLと空文字の扱い
• 並び順：同じ値が並ぶときのソート順

件数と合計値の比較は低コストで実施できるため、全件で必ず行うことをおすすめします。

3-3. 非機能の回帰：性能・バッチ処理時間・同時実行

機能が一致しても、遅くなれば業務は止まります。多くの解説で見落とされがちなのが、この非機能のリグレッションテストです。

• オンライン画面の応答時間
• 夜間バッチが時間枠内に終わるか
• 同時アクセス時の排他制御
• ログ・監査証跡が同じ情報を残しているか

3-4. 外部連携・ファイル・帳票の回帰

システムの外側との境界も確認が必要です。

• 連携ファイルのレイアウト、文字コード、改行コード
• 外部APIへのリクエスト内容
• 帳票のレイアウトと改ページ位置
• 通知メールの文面と送信タイミング

4. 移行のリグレッションテストの進め方：6ステップ

ここからは、実際の進め方です。各ステップに完了条件を置くことで、「なんとなく次に進む」ことを防ぎます。

Step1. ベースラインを取得する：旧システムの入出力を記録

最初に、旧システムに入力を与えて実行し、その出力を記録します。これが比較の基準になります。入力は、本番ログやDBスナップショットなどから集め、個人情報はマスキングします。

完了条件は、旧システム上で再実行しても同じ結果が再現できることです。再現しない項目は、比較前に原因を特定しておきます。ベースラインの作り方は、親記事のゴールデンデータの解説で詳しく紹介しています。

ベースラインができたら、次は「どこで比べるか」を決めます。

Step2. 比較ポイント（シーム）を決める

移行ではコードの構造が変わるため、内部の関数単位では新旧を比べられません。そこで、新旧どちらにも残る境界（API、DBテーブル、ファイル、帳票など）で比較します。

この境界を「シーム（接合点）」と呼びます。シームの見つけ方は、マイグレーションテストの進め方で解説しています。

Step3. 比較を自動化し、正規化ルールを定義する

新旧の出力をそのまま比べると、本質的でない差異が大量に出ます。そこで、比較前にそろえる「正規化ルール」を定義します。

• タイムスタンプ、処理日時
• 自動採番されるID
• 並び順の指定がない一覧
• 前後の空白、浮動小数点の許容誤差

注意点は、正規化しすぎると本物のバグまで隠れることです。ルールは必ず文書化し、承認を得てから適用します。

Step4. 差異を判定し、トリアージする

比較で出た差異は、次の4つに分類します。

1. バグ：新システムを修正する
2. 許容できる差異：正規化ルールに追加し、承認を得る
3. 意図的な差異：2-2の「意図的な差異リスト」と照合する
4. 旧システム側の不具合：業務部門と扱いを決め、リストに追加する

ゴールは、説明のつかない差異をゼロにすることです。分類の考え方は、差異の分類の章も参考にしてください。

Step5. 並行稼働・シャドーテストで本番相当データを流す

テストデータだけでは、本番特有のパターンを網羅できません。そこで、本番と同じ入力を新旧の両方に流して比較します。

• 並行稼働：一定期間、新旧を同時に動かし、結果を突き合わせる
• シャドーテスト：新システムは裏で動かし、業務には影響させずに出力だけ比較する

期間は、月末締めや月次処理など、業務サイクルを最低1回は一巡させるのが目安です。

Step6. 合格基準を決め、カットオーバーを判定する

最後に、あらかじめ合意した基準でカットオーバーを判定します。

• 一致率がしきい値を超えている
• 説明のつかない差異がゼロ
• 非機能（性能・バッチ時間）が基準内
• ロールバック手順をリハーサル済み
• 業務部門の承認者が合格を判断した

カットオーバーまでの全体像は、マイグレーションの進め方｜3段階と4つの関門もあわせてご覧ください。

5. テスト範囲の決め方：全件比較かリスクベースか

すべてを全件比較できれば理想ですが、時間とコストには限りがあります。ここでは、移行ならではの範囲の決め方を紹介します。

5-1. 移行方式によって変わる回帰テストの重み

マイグレーションの方式によって、リグレッションテストで重点を置く場所は変わります。

方式が決まったら、次は優先度です。

5-2. 優先度を決める3つの軸：業務影響・変更の大きさ・利用頻度

限られた工数は、次の3つの軸で配分します。

• 業務影響：お金、法令、顧客に関わるか
• 変更の大きさ：AI変換、手修正、ライブラリ置換の量
• 利用頻度・処理量：毎日使うか、年1回か

3つとも高い領域は全件比較、低い領域はサンプリングとするのが現実的です。ただし、年1回の処理（年次決算など）は利用頻度が低くても業務影響が大きいため、優先度を下げすぎないよう注意します。

6. リグレッションテストの自動化とAI活用：どこまで任せられるか

移行のリグレッションテストは、変換のたびに何度も繰り返します。手作業では続かないため、自動化が前提です。

6-1. 自動化の前提：比較ツールとCIへの組み込み

自動化の基本は、次の3つです。

• ファイル・帳票の差分比較ツール
• SQLによるテーブル単位の突合
• CIパイプラインでの自動実行

ポイントは、比較を終盤の1回で終わらせず、コード変換のたびに毎回実行することです。早く気づくほど、修正のコストは小さくなります。

6-2. AIにできること・人が判断すべきこと

AIはリグレッションテストの効率を大きく高めます。ただし、任せてよい範囲があります（参考：マイグレーションのAI活用と品質担保）。

AIを使ううえで、特に注意すべき落とし穴が1つあります。

6-3. 変換とテストを同じAIに任せない：循環検証のリスク

同じAIに、コード変換と期待値の作成を両方任せると、同じ誤解がコードとテストの両方に入り込み、テストはPASSしてしまいます。これが循環検証のリスクです。

期待値は、AIが推測したものではなく、旧システムの実行結果から取るのが原則です。詳しくは「テストが「PASS」でも品質を証明できない理由」で解説しています。

7. 移行のリグレッションテストでよくある失敗と対策

最後に、現場でよく見かける失敗をまとめます。

8. HBLABの移行品質保証：Migurei AI Inside

HBLABは、AI搭載のモダナイゼーションソリューション「Migurei」を活用し、移行の品質保証を一貫して支援しています。

• アセスメントによる「守る挙動」の棚卸し
• 旧システムの実行結果からのベースライン（ゴールデンデータ）構築
• シームでの新旧比較と差異の分類
• 4つの品質軸による評価

詳しくは、HBLABのモダナイゼーション支援をご覧ください。

9. 移行のリグレッションテストに関するよくある質問

Q1. 現新比較テストとリグレッションテストの違いは何ですか？

リグレッションテストは「挙動が後退していないか」を確かめる目的を指し、現新比較テストはそのための手法です。移行では、リグレッションテストの多くを現新比較で実施します。

Q2. 旧システムのバグも新システムで再現すべきですか？

一律には決められません。業務がそのバグの挙動を前提にしている場合は、再現した方が安全なこともあります。修正する場合は、「意図的な差異リスト」に登録し、業務部門の承認を得てください。

Q3. 一致率は何%あれば合格ですか？

一律の正解はありません。重要なのは一致率の数字よりも、説明のつかない差異がゼロであることです。金額や法令に関わる領域は、意図的な差異を除いて全件一致を基準にすることをおすすめします。

Q4. 旧システムがすでに動かない場合はどうしますか？

本番ログや過去の出力データをベースラインとして使う方法があります。それも難しい場合は、設計書を復元し、仕様ベースのテストに切り替えます。方式の選び方はマイグレーションテストの進め方をご覧ください。

Q5. リグレッションテストは何回実施すべきですか？

回数を決めるより、コード変換のたびに自動で繰り返す仕組みを作ることが大切です。そのうえで、結合テスト前、並行稼働中、カットオーバー直前の3回は必ず全体を確認します。

まとめ

移行のリグレッションテストで押さえるべきポイントは、次の4つです。

1. 移行では変わるのはシステム全体であり、正解の拠り所は旧システムの挙動
2. テストの前に「守る挙動」と「変えてよい挙動」を合意し、意図的な差異リストを作る
3. 機能・データ・非機能・外部連携の4観点で、6ステップと完了条件に沿って進める
4. 合格基準は一致率だけでなく、説明のつかない差異ゼロ

新システムが旧システムの挙動を守れているかを証明できるのは、計画的に設計された移行のリグレッションテストです。