ビジュアルリグレッションテスト：その概要と必要なケース
Yunhao Jiao
機能テストが見逃しやすいソフトウェアのバグがあります。アプリケーションが正しく動作しているにもかかわらず、見た目が崩れているというケースです。CSSの競合によって画面外に押し出されたボタン、正常に送信されるがモバイル端末ではラベルが重なって表示されるフォーム、依存関係のアップデート後に正しいデータを表示しているにもかかわらずレイアウトが崩れたダッシュボードなどがその例です。
ビジュアルリグレッションテストは、こうしたバグを自動的に検出するための手法です。このガイドでは、その概要、仕組み、および完全なテスト戦略における位置づけについて解説します。
ビジュアルリグレッションテストとは
ビジュアルリグレッションテストとは、アプリケーションのスクリーンショットをベースライン（正常な状態の参照画像）と自動的に比較し、バグを示す可能性のある視覚的な変化を検出する手法です。
新しいコード変更によってベースラインとの視覚的な差異が生じた場合、ビジュアルリグレッションテストがそれをフラグとして検出します。その後、人間のレビュアーがその変更が意図的なもの（デザインの更新や新機能）なのか、バグ（無関係な変更によるレイアウト崩れ）なのかを判断します。
ビジュアルリグレッションテストが答える問いは「この変更の前後でUIは同じ見た目か？」です。機能テストが答える問いは「UIは正しく動作しているか？」です。どちらの問いも重要です。前者に答えられるのはビジュアルリグレッションテストだけです。
機能テストだけでは不十分な理由
機能テストはふるまいを検証します。フォームが送信されたか、APIが正しいデータを返したか、ユーザーが正しいページにリダイレクトされたか。見た目は検証しません。
これによって生まれるギャップ：
- モバイルユーザーにとってボタンが見えなくなるCSSの変更は、すべての機能テストをパスします（ボタンはDOMに存在しているため）
- テキストが読めなくなるフォントサイズの変更は、すべての機能テストをパスします（テキストはそこに存在しているため）
- サードパーティウィジェットの読み込みによって発生したレイアウトシフトは、すべての機能テストに合格します（すべての要素が存在するため）
- 重要なUI要素を覆うz-indexの変更は、すべての機能テストに合格します（その要素は技術的にはクリック可能なままであるため）
これらは実際のユーザーエクスペリエンス上の障害です。機能テストではこれらを検出できません。手動QAでは明らかなものは検出できるかもしれません。ビジュアルリグレッションテストは、これらすべてを体系的に検出します。
ビジュアルリグレッションテストの仕組み
ベースラインのキャプチャ
最初の実行時（または指定されたリファレンス実行時）に、各ページまたはコンポーネントのスクリーンショットをキャプチャし、ベースラインとして保存します。これらのベースライン画像は「正常な状態」を表します。
比較
その後の実行では、新しいスクリーンショットがベースラインとピクセル単位で比較されます（または、軽微なレンダリングの差異を考慮した知覚的差分アルゴリズムを使用）。閾値を超える差異はすべてフラグが立てられます。
人によるレビュー
フラグが立てられた差異は、人間のレビュアーに提示されます。レビュアーは意図的な変更を承認し（ベースラインを更新）、意図しない変更を却下します（バグ修正をトリガー）。このレビューステップは避けられません — 完全に自動化されたビジュアルリグレッションは、正当なデザイン変更による誤検知が多すぎるためです。
ベースラインの更新
ビジュアルの変更が意図的なもの（デザインの更新や新機能など）である場合、ベースラインは新しい意図された状態を反映するよう更新されます。
ビジュアルリグレッションテストのツール
Percy（BrowserStack） — 最も広く採用されているビジュアルリグレッションツールです。ほとんどのCI/CDシステムおよびブラウザ自動化フレームワークと統合できます。ビジュアル差分の承認・却下のためのレビューインターフェースを提供します。料金はスクリーンショットの量に応じてスケールします。
Chromatic — Storybookコンポーネントライブラリ専用に構築されています。各コンポーネントのビジュアルスナップショットを独立した状態でキャプチャし、変更をフラグします。デザインシステムチームに特に有用です。
Playwrightのビジュアル比較 — Playwrightにはスクリーンショット比較機能が組み込まれています。専用ツールほど洗練されていませんが、すでにPlaywrightを使用しているチームには追加のツールが不要です。
TestSpriteのビジュアルアサーション — TestSpriteは、エージェント型テストカバレッジの一部としてビジュアル状態の検証を含んでいます。軽微なレンダリングの差異によるノイズが発生するピクセルパーフェクトな比較ではなく、TestSpriteはビジュアルの意図を検証します。「チェックアウトボタンが表示されている」「エラーメッセージが表示されている」「モバイルでナビゲーションが折りたたまれている」といった形です。このアプローチにより、ピクセル差分よりも低い誤検知率で実際のビジュアルバグを検出します。
ビジュアルリグレッションテストが必要な場合
ビジュアルリグレッションテストは、以下の状況で最も効果を発揮します。
多数のコンシューマーを持つデザインシステム。共有コンポーネントライブラリが多数のアプリケーションで使用されている場合、ライブラリのビジュアル変更がすべてのコンシューマーに影響を与える可能性があります。ライブラリに対するビジュアルリグレッションテストにより、変更が伝播する前に問題を検出できます。
急速なUI開発。UIコンポーネントを頻繁にリファクタリングするAIコーディングツールを使用しているチームは、意図しないビジュアル変更が発生しやすい状況にあります。ビジュアルリグレッションテストにより、機能テストでは見落とされる外観の破損を検出します。
複雑なレイアウトを持つアプリケーション。ダッシュボード、データテーブル、マルチカラムレイアウト、レスポンシブデザインは、ビジュアルバグが発生するサーフェスエリアが広くなります。レイアウトが複雑なほど、ビジュアルリグレッションテストの価値は高まります。
大規模リリース前。ビジュアルリグレッションテストを継続的に実施していないチームでも、開発サイクル中に蓄積されたビジュアルの問題を検出するために、大規模リリース前には実施すべきです。
テスト戦略におけるビジュアルリグレッションテストの位置づけ
ビジュアルリグレッションテストは、機能テストの代替ではなく補完するものです。完全なテスト戦略には以下のレイヤーがあります。
- ユニットテスト：ロジックの正確性
- インテグレーションテスト：コンポーネント間の連携の正確性
- E2Eテスト（機能）：フローと動作の正確性 — TestSpriteが自動的にカバー
- ビジュアルリグレッションテスト：外観の正確性
- パフォーマンステスト：速度と信頼性
ほとんどのチームにとって、最も効果的な順序は、まずE2E機能カバレッジを確立し（TestSpriteを使用）、次に最も視覚的に複雑な、またはユーザーに直接関係するフローにビジュアルリグレッションテストを追加することです。
機能的なE2Eカバレッジから始める →