Webエンジニアなら知っておきたい！コードではなく”見た目”をテストする「VRT」について

開発技術部 Frontend1課の堀内です。近年、AIコーディングツールの普及により、開発スピードは劇的に上がりました。しかし、AIが書いたコードだからこそ、私たちエンジニアが責任を持ってレビューし、品質を担保する必要があります。

特にフロントエンドでは、「共通コンポーネントを修正したら予期せぬ別の画面が崩れた」といった問題がつきものです。AIの活用によってコードの変更スピードが劇的に上がった今、そのすべての影響範囲を人間が一つひとつ画面を開いて目視チェックするのは、もはや現実的ではありません。

こうした目視チェックの限界を補い、”見た目”のバグを自動検知してくれるのが、今回のテーマである VRT（Visual Regression Testing）です。フロントエンドエンジニアがUIをどう安全に保っているのか、その裏側を知るきっかけになれば幸いです。

VRTとは何か？

一言でいうと、VRTとは「画面のスクリーンショットを撮影し、過去の正常な状態とピクセル単位で比較して、意図しない見た目の変化を検知するテスト」です。実際にブラウザでレンダリングした結果を比較するため、CSSの変化やフォントのずれも検出できます。エンジニアにとって一番馴染み深い「差分」といえば、git diff だと思います。コードの変更を1行単位で検知するのが git diff なら、「画面の見た目の変更を1ピクセル単位で検知する仕組み」がVRTである、とイメージすると分かりやすいかもしれません。

実際のVRTの出力レポートを見てみましょう。以下の3枚の画像は、試しに画面中央の「counterボタンだけ角丸を変更しようとした」際に出力されたテスト結果です。

パッと見の目視チェックでは「変わったのは中央のボタンだけだな」と見落としてしまいそうですが、一番下の差分画像のハイライトを見ると、意図していなかったはずの下部のナビリンクボタンにまで丸みが取れてしまっているのが一目で分かります。

VRTの裏側では何が起きているのか？

VRTが「見た目の崩れ」を検知する裏側では、具体的にどのような処理が行われているのでしょうか。ここでは、VRTが画像を比較する仕組みと、実際のCI/CDパイプラインにどう組み込まれているのかを解説します。

VRTを支える3つの処理

VRTのツールが裏側で行っているのは、大きく分けて以下の3ステップです。

1. レンダリングと撮影

プルリクエストをトリガーにCI上でPlaywrightなどのヘッドレスブラウザを起動し、各画面やコンポーネントのスクリーンショットを撮影します。この際、スマートフォンやタブレットなどの画面サイズの指定はもちろん、ChromeやSafariといったブラウザの種類まで細かく組み合わせて指定することが可能です。「PCのChromeでは正常に見えるのに、iPhoneのSafariだとレイアウトが崩れてしまう」といった、特定の環境に依存する表示バグも検知できます。