開発プロジェクトの最前線！生成AIを活用したUIテスト自動化に取り組む「BiLD」の紹介

R&D本部 DI部ITアーキテクトの齊藤です。
​前回のコラムでは、UIが利用者の体験に直結する“接点”であること、そして手動テストがヒューマンエラーや疲労の影響を避けられないことを背景に、UIテスト自動化の重要性を整理しました。
​また、開発プロジェクトを主導するTech Leadを支える技術ノウハウとして、BiLDが社内の実績／教訓やテストフレームワークの検証レポートを整理し、導入を後押ししている点もご紹介しました。

自動化を成功させるには”動く仕組み”から”運用できる仕組み”へ育てることが重要です。このポイントはUIテスト自動化にも当てはまります。前回のコラムの続編となる今回は、UIテスト自動化の成功に欠かせない「判定方式（OK／NGをどう決めるか）」に焦点を当てます。
​品質を落とさずにリリースを早めたい一方で、テストの保守のしやすさ、誤検知の懸念、このような現場の声に寄り添いながら、今後の有力な選択肢として注目されている「アクセシビリティツリー比較型＋生成AI活用」まで、見通しを立てていきましょう。

UIテスト自動化の価値は、単に「テストを機械に任せる」ことではありません。前回の記事でも述べたとおり、開発側は仕様どおりにUIが動作するかを確認し、問題があれば修正し、再テストで仕様準拠を確認したうえで本番環境へ公開します。この反復のスピードと確度を上げるのが、UIテスト自動化です。

例えば週次リリースのWebサービスでは、小さなUI改善や文言変更が積み重なるほど回帰確認の範囲は広がります。手動テストは担当者の集中力や時間に依存しやすく、手順の取り違えや見落としが起きやすくなります。
​UIテスト自動化が回帰確認の土台を担うことで、変更の影響を短いサイクルで確認でき、安心して次の改善に進めます。結果として、リリース判断が早くなります。

UIの不具合は利用者の不満に直結し、サービスやシステム全体の印象にも影響します。
​“改善が早いのに安心できる”状態を継続できれば、利用者の信頼は高まり、長期運用でも変更への躊躇がなくなります。これは開発／運用の両面で効いてくる効果です。

UIテストは「自動で操作する」だけでは完結しません。重要なのは、その結果に対し何を根拠にOK／NGとするかです。同じUIテスト自動化でも、判定方式によって次が大きく変わります。これらの特長を理解し、適切に使い分けるのが重要です。

ここでは、まず代表的な2方式と、近年注目されている新しい方式を含めて3つに整理します。

アサーション判定型は、UIのあるべき状態や振る舞いをテストコードで明示し、それが満たされるかでOK／NGを判定する方式です。たとえば「ログイン後にユーザー名が表示される」「特定条件でエラーメッセージが出る」など、確認したい点を“狙って”検証できます。

狙った条件をピンポイントで確認できるため、仕様に沿った挙動の保証に強いのが魅力です。文言、入力値、表示／非表示、遷移など、多様な観点で積み上げられます。

一方で、確認ポイントが増えるほどテストコードは増え、仕様変更やUI部品の置き換えのたびに修正が必要になります。現場では「変更のたびにテストが失敗し、テストコードを直すだけで手一杯」となるなど、保守コストの増加が顕在化する傾向があります。

スクリーンショット比較型は、事前に用意した“正解の画面（ベースライン）”と、テスト実行時に取得した画面を画像として比較し、差分でOK／NGを判定する方式です。見た目の崩れを直感的に検知でき、ビジュアル回帰テストとして採用されることが多いアプローチです。

細かな条件を一つずつ書く代わりに、“見た目の差分”でまとめて検知できるため、導入時のハードルが下がりやすいのが利点です。

ブラウザーの描画はOSやフォント、設定などの影響を受けます。スクリーンショット比較はその揺れに引っ張られ、「本質的には問題ないのに落ちる（誤検知）」が起こりやすくなります。また、テーマ変更やアニメーション、動的コンテンツを含む画面では運用ルール（除外／固定化）が必要になる傾向があります。

アサーション判定型とスクリーンショット比較型による判定方式はいずれも強力ですが、悩ましいのは「網羅性」と「保守しやすさ」のトレードオフです。

結局のところ、どの方式も万能ではありません。開発プロジェクトの目的（仕様保証か、崩れ検知か、回帰確認の土台か）や状況（変更頻度、体制、リリースサイクル）に応じて、使い分け／組み合わせることが現実的です。

そこで近年、第三の選択肢として注目されているのが、アクセシビリティツリー比較型です。

アクセシビリティツリーは、ブラウザーがDOM（ドキュメントオブジェクトモデル）をもとに、要素の役割（role）や名前（name）、状態（state）などを整理し、支援技術（スクリーンリーダーなど）が参照できる形にした情報構造であり、テキスト形式で表現できます。
​比喩で言うなら、スクリーンショット比較が“写真”だとすると、アクセシビリティツリーは“読み上げの台本”や“UIの見取り図”に近い存在です。ピクセルではなく、「これはボタン」「これは見出し」「この入力欄のラベルは何か」という意味に軸があります。

アクセシビリティツリーはテキスト（構造化テキスト）として表現できるため、その差分比較で回帰を判定できます。
例えばMicrosoftのUIテストツール「Playwright」には、アクセシビリティツリーを“スナップショット”と比較して検証する仕組みが用意されています。

この仕組みのポイントは、次のような点にあります。

そして本稿のもう一つのポイントが、生成AIの活用です。アクセシビリティツリー比較は差分がテキストで出るため、生成AIが得意とする「要約」「分類」「説明」と親和性が高くなります。

これにより、例えば次のように活用できます。

重要なのは、生成AIが判定そのものを肩代わりするというより、判定結果（差分）の理解と意思決定を加速する点に価値が出やすいことです。テストが落ちた瞬間に「結局どこが問題なのか」が短縮できると、運用の継続性が上がります。

もちろん、アクセシビリティツリー比較がすべてを置き換えるわけではありません。
​純粋なレイアウト崩れ（余白が崩れてボタンが見えないなど）はスクリーンショット比較が得意で、逆に“見た目は同じでも意味が壊れる”ケース（例：見出しがh2からdivに代わってしまった）はアクセシビリティツリー比較が得意です。
​したがって現実解としては、アサーション／スクリーンショット／アクセシビリティツリーを目的別に組み合わせるのが王道になります。

以下に、3方式の特長を比較して整理します。

UIテストの判定方式は、生成AIの進化により“失敗した／成功した”の二択だけでなく、差分を理解し、次の判断につなげる方向へ発展し始めています。特にアクセシビリティツリーのような構造化テキストは、生成AIが扱いやすい形式であり、今後の伸びしろが大きい領域です。

キヤノンITソリューションズでは、前回記事でご紹介したUIテスト自動化の取り組みを継続しつつ、こうした生成AIとの親和性が高いアプローチも含めて、技術ノウハウ「BiLD」として整理／整備を進めます。
​“品質とスピードの両立”は、どの開発現場でも共通のテーマです。UIテスト自動化と生成AIを組み合わせることで、利用者の生産性向上と品質向上に、これからも継続的に貢献します。

もし貴社プロジェクトで「判定方式をどう設計すべきか」「自動化が保守のしやすさの妨げになっている」「生成AIを品質活動に取り込みたい」といった課題があれば、ぜひ気軽にご相談ください。
​また、この領域に関心のあるエンジニアの方々とも、実践を通じて一緒にチャレンジしていければ幸いです。