AIでUIテストを効率化する方法｜57画面を安全にチェックするPlaywright活用術

Webシステムの開発やリニューアルでは、意外と時間がかかるのがUIテストや画面チェックです。

数画面なら、人がブラウザを開いて、

• レイアウトが崩れていないか
• ボタンが押せるか
• 正しい画面に遷移するか
• モーダルやエラー表示が正しく出るか

と順番に確認すれば済みます。

しかし対象が10画面、30画面、50画面と増えると、確認作業そのものが大きな負担になります。

実際、あるシステム移行では確認対象が57画面ありました。さらに、「表示できるか」だけでなく、元のシステムと比べて見た目と機能の両方が一致しているかを確認する必要がありました。

こうした大量のUIチェックを人手だけで進めるのは、時間もかかりますし、確認漏れも起こりやすくなります。

そこで今回は、

AI・Playwright・ATDD・画面台帳

を組み合わせて、57画面のUIテストを安全かつ効率的に進める方法を紹介します。

ポイントは、AIにすべてを丸投げすることではありません。

AIが判断しやすい形にテスト結果を構造化し、機械で確認できる部分はPlaywrightに任せ、人間は本当に見るべき差分だけ確認する。

この役割分担が重要です。

UIテスト自動化で最初に分けるべき2つのチェック

UIテストを効率化するうえで、まず重要なのが、チェック対象を2つに分けることです。

1つ目は、見た目のチェックです。

2つ目は、機能のチェックです。

今回の仕組みでは、これらをそれぞれ、

• 画面Parity
• 機能Parity

と呼んで管理しています。

Parity（パリティ）とは、「同等」「一致」といった意味です。

つまり画面Parityは、

元の画面と新しい画面の見た目が同じか

を確認します。

一方、機能Parityは、

元の画面と新しい画面で、同じ操作をしたときに同じ結果になるか

を確認します。

この2つは分けた方が安全です。

例えば、見た目が完全に一致していても、

「ボタンを押しても反応しない」

ということはあります。

逆に、ボタンや画面遷移は正常でも、

• 余白が違う
• フォントが違う
• テーブル幅が違う
• モーダルのサイズが違う

というケースもあります。

UIテスト自動化では、見た目と機能を別の軸でチェックすることが重要です。

Playwrightとは？ UIテスト自動化で何ができるのか

今回のUIチェックで中心的に使っているのがPlaywrightです。

Playwrightは、Webブラウザを自動操作するためのテストツールです。

人間がブラウザで行う、

• ページを開く
• ボタンを押す
• 文字を入力する
• リンクをクリックする
• 表示内容を確認する

といった操作を自動化できます。

UIテストやE2Eテストでよく使われるツールです。

E2Eテストとは「End to End Test」の略で、利用者が実際に操作する流れを最初から最後まで確認するテストです。

例えば、

「一覧画面を開く」
↓
「編集ボタンを押す」
↓
「編集画面に移動する」
↓
「編集項目が表示される」

という一連の動きを自動で確認できます。

57画面を人が毎回クリックして確認するのではなく、こうした部分をPlaywrightに任せるだけでも、UIチェックの負担は大きく減らせます。

ReactやBladeのように技術が違ってもUIは比較できる

今回のシステム移行では、元の画面と新しい画面で、Web画面を作る技術が異なっていました。

元の画面はReact、移行先ではLaravel Bladeを使っています。

Reactは、JavaScriptを使ってWeb画面を作る代表的な技術です。

Laravel Bladeは、PHPのWeb開発フレームワークであるLaravelに付属する、HTML画面を生成するための仕組みです。

ここで重要なのは、ReactやBladeそのものではありません。

ポイントは、

内部の作り方は違っていても、利用者から見える画面は同じにしたい

ということです。

そのため、HTMLの構造やCSSクラス名をそのまま比較しても意味がありません。

内部実装が違えば、それらは当然変わります。

そこで今回は、

実装方法ではなく、ブラウザに実際に表示された結果を比較する

という方法を取っています。

見た目のUIチェックはスクリーンショット比較だけにしない

UIテストというと、Visual Regression Test、つまりスクリーンショットを比較する方法を思い浮かべる人も多いと思います。

もちろん、スクリーンショット比較も有効です。

ただ、57画面分の差分画像を毎回人間が確認すると、それ自体が大きな作業になります。

そこで今回は、スクリーンショットだけではなく、画面から数値として取得できる情報も比較します。

例えば、

• 横幅
• 高さ
• 余白
• フォント
• 枠線
• 背景
• 文字配置

などです。

ブラウザは、最終的に画面へ適用されたスタイル情報を取得できます。

これは専門用語では**computed style（計算済みスタイル）**と呼ばれます。

簡単に言えば、

「このボタンは横幅120px」
「余白は16px」
「文字サイズは14px」

といった、ブラウザが最終的に計算した値です。

これを元画面と新画面の両方から取得し、比較します。

今回は、この比較用データを画面の**「指紋」**のように扱っています。

スクリーンショットだけでなく、数値として比較できる状態にすることで、AIにも差分を解析させやすくなります。

HTML構造ではなく「役割」で比較する

UIテストでさらに重要なのが、どの要素を見るかの指定方法です。

内部のHTML構造に依存してしまうと、技術を変更しただけでテストが大量に壊れます。

そこで、

• ページタイトル
• 検索フォーム
• 一覧テーブル
• 保存ボタン
• ページ送り
• モーダル

といった役割単位で比較します。

例えば、

「保存ボタンの横幅」
「検索フォームの高さ」
「一覧テーブルの余白」

という形です。

これなら、ReactとBladeのように内部実装が大きく違っていても比較できます。

UIテストを長く運用するなら、

実装そのものではなく、利用者から見た役割を基準にする

のが重要です。

機能チェックでは「クリックできた」だけでは不十分

見た目とは別に、機能チェックも必要です。

ここでもPlaywrightを使います。

例えば、

「編集ボタンをクリックする」

というテストがあったとします。

単にクリック処理が成功しただけでは不十分です。

その後に、

• 正しいURLへ遷移したか
• 遷移先の画面が表示されたか
• その画面固有の項目が存在するか

まで確認します。

つまり、

操作した
ではなく、

期待した結果になった

ところまで確認します。

この考え方が、ATDDにもつながります。

ATDDとは？ 「どうなれば合格か」を先に決める

ATDDは、

Acceptance Test Driven Development

の略です。

日本語では「受け入れテスト駆動開発」と呼ばれます。

少し難しく聞こえますが、考え方は単純です。

先に、

この画面は、どうなれば完成と言えるのか

を決めておきます。

例えば、

「一覧画面の編集ボタンを押したら編集画面へ移動する」

「保存後に完了メッセージが表示される」

「エラー時には入力項目の下にメッセージが出る」

といった条件です。

この受け入れ条件をPlaywrightで確認できる形にしておけば、人が毎回同じ確認をする必要がなくなります。

UIチェック自動化では、

テストを書くこと以上に、何を成功条件とするかを明確にすること

が重要です。

57画面を台帳で管理する

画面数が増えてくると、テスト実行そのもの以上に難しくなるのが、

何をどこまで確認したのか

の管理です。

そこで、57画面すべてを台帳で管理します。

台帳には、例えば、

• 画面番号
• 関連するプログラム
• 確認する操作
• 実行するテスト
• テスト結果
• 既知の問題
• 関連するIssue

を記録します。

Issueとは、GitHubなどで使われる、バグや課題、作業内容を管理する単位です。

この台帳があると、AIに、

「まだテストしていない画面を出して」

「失敗している画面だけ整理して」

「この修正の影響を受ける画面を探して」

といった作業を任せられます。

AIを「57画面全部を見る担当」にするのではありません。

テスト結果を整理し、次に見るべき場所を絞り込む担当

として使います。

ここがAIでUIテストを効率化するときの大きなポイントです。

57画面すべてを毎回テストしない

UIテストを自動化しても、変更のたびに57画面すべてを実行していたら時間がかかります。

そこで、

今回変更したプログラムがどの画面に影響するか

を管理します。

例えば、

「このファイルが変更されたらA12画面を確認する」

という関係を台帳に持たせます。

Gitには、今回どのファイルを変更したかという情報があります。

その差分を使って、

変更の影響を受ける画面だけPlaywrightテストを実行する

ようにします。

普段の開発では、

変更
↓
影響画面を抽出
↓
対象画面だけテスト
↓
問題があれば修正

という流れにします。

一方、リリース前などの節目では57画面すべてをチェックします。

この、

普段は部分テスト、節目では全体テスト

という使い分けが、画面数の多いシステムでは非常に重要です。

AIは画面を見るより「差分分析」に使う

生成AIをUIテストに使うというと、

「AIにスクリーンショットを見せて判断させる」

という方法を想像するかもしれません。

それも一つの方法ですが、AIが特に力を発揮するのは、テストで差が出た後です。

例えば、

• ボタンの高さが違う
• 余白が8px違う
• モーダルが表示されない
• 遷移先URLが違う
• 元画面にあるボタンが新画面にはない

といった結果が出たとします。

これをAIに渡して、

• 修正が必要な差か
• 仕様上許容できる差か
• どのファイルが原因になりそうか
• CSSなのか機能実装なのか
• 追加テストが必要か

を分析させます。

つまり、

機械が異常候補を探し、AIが原因を分析し、人間が最終判断する

という役割分担です。

人間が57画面すべてを確認するよりも、はるかに効率的です。

AIでUIテストを自動化するときに一番怖いこと

AIや自動テストを使うときに最も怖いのは、

実は確認できていないのに「問題なし」になること

です。

例えば、

「モーダルを開いて、その見た目を比較する」

というテストがあるとします。

ところが、モーダルを開くボタンのクリックに失敗していた場合、

元画面も新画面も、

「モーダルが閉じた状態」

で比較される可能性があります。

すると、

「両方同じなのでOK」

と判定される危険があります。

そこで、

「モーダルを開く操作をした」

だけでなく、

本当にモーダルが開いたか

まで確認します。

このような考え方を、開発ではfail-closeと呼ぶことがあります。

簡単に言えば、

正しいことを確認できないなら、成功扱いにしない

という考え方です。

例えば、

• 必要な要素が見つからないなら失敗
• 必要な状態が取得できないなら失敗
• 古いテスト結果しかないなら失敗
• 比較条件が違うなら比較しない

といったルールです。

AIでUIチェックを効率化する場合、

AIを使うこと以上に、誤判定を防ぐ仕組みを作ること

が重要です。

AIで安全にUIチェックを効率化する基本フロー

57画面のような大量のUIを確認するときは、次の流れにすると管理しやすくなります。

まず、すべての画面を台帳に登録します。

次に、それぞれについて、

• 何を見るか
• 何を操作するか
• どうなれば成功か

を定義します。

そしてPlaywrightで、

• 見た目の数値を取得
• 画面を実際に操作
• 遷移先を確認
• 必要な要素を確認

します。

差分が出たらAIに分析させます。

修正後は、変更の影響を受ける画面だけ再実行します。

最後に、リリース前などの節目で全画面チェックを行います。

この仕組みができると、人間の仕事は、

57画面を毎回一枚ずつ見ること

ではなく、

57画面を機械が確認できる状態にして、異常だけ判断すること

へ変わります。

UIテストを完全自動化することが目的ではない

ここは大切です。

UIチェックのすべてをAIやPlaywrightに任せる必要はありません。

例えば、

• マウスを乗せたときの違和感
• キーボード操作時の見え方
• 文章の読みやすさ
• 画面全体のバランス
• 操作したときの感覚

などは、人が見たほうがよい場合があります。

UIテスト自動化の目的は、

人間による確認をゼロにすることではありません。

機械で確認できるものはPlaywrightに任せる。

大量の結果整理や原因分析はAIに任せる。

最後の判断や違和感の確認は人間が行う。

この役割分担によって、UIチェック全体の時間を減らします。

まとめ：AIはUIチェックの「目」より「絞り込み役」として使う

AIでUIテストを効率化すると聞くと、

「AIに画面を見せて、自動で良し悪しを判断してもらう」

というイメージを持つかもしれません。

しかし、実際に57画面規模のシステムを扱ってみると、それだけでは不十分です。

重要なのは、

何をもって正しいとするのかを明確にすること

です。

そのうえで、

Playwrightが操作する。

見た目の差分を機械的に取得する。

ATDDで合格条件を決める。

台帳で57画面の状態を管理する。

AIが差分や失敗原因を分析する。

人間が最後の判断をする。

という形にします。

AIを万能な確認役として使うのではなく、

機械的なテストと人間の判断の間をつなぐ存在として使う。

これが、大量の画面チェックを安全かつ効率的に進めるための、現実的なAI活用方法だと考えています。

用語集

UI
User Interfaceの略。利用者が見る画面やボタン、入力欄などのことです。

UIテスト
画面の表示や操作が想定どおりになっているか確認するテストです。

E2Eテスト
End to End Testの略。利用者の一連の操作を最初から最後まで確認するテストです。

Playwright
Webブラウザを自動操作できるテストツールです。クリック、入力、画面遷移、表示確認などを自動化できます。

ATDD
Acceptance Test Driven Developmentの略。「どうなれば完成か」という受け入れ条件を決め、その条件を満たしているか確認する開発方法です。

Parity（パリティ）
同等、一致という意味です。本記事では、元システムと新システムで見た目や機能が一致していることを指します。

React
JavaScriptを使ってWeb画面を構築するための代表的な技術です。

Laravel Blade
PHPのWeb開発フレームワークLaravelで使われる、HTML画面を作るための仕組みです。

computed style
ブラウザが最終的に計算した画面の表示設定です。幅、高さ、余白、フォントサイズなどを取得できます。

Visual Regression Test
画面のスクリーンショットなどを以前の状態と比較し、見た目の変更を検知するテスト方法です。

Issue
GitHubなどで、バグ、課題、改善内容、作業内容を管理する単位です。

Git
プログラムの変更履歴を管理する仕組みです。どのファイルが変更されたかを調べることもできます。

CI
Continuous Integrationの略。プログラムの変更時に、自動でテストなどを実行する仕組みです。

fail-close
正しいことを確認できない場合は成功扱いにしない、という安全側の考え方です。