Coding Agentでシステムテストを行う

Coding Agentで一部可能になってきたUIテスト

ここまで、lint、typecheck、統合テストを通じて、アプリケーションが通常のソフトウェアとして壊れていないかを確認してきました。ただし、それだけでは画面上の問題までは見つけられないことがあります。

例えば、APIは正しく返っていても、テキストがはみ出している、モバイル幅で要素が重なっている、ボタンが押しづらい、といった問題は起こります。これは、コードやAPIだけを見ていても気づきにくい問題です。

UIの確認は、従来は人間がブラウザを開き、クリックし、入力し、複数の画面幅で目視する作業でした。最近は、Coding Agentにもブラウザを操作させ、スクリーンショット、console error、network errorを確認させることができるようになってきています。

Anthropicの長時間稼働Agentに関する記事では、ブラウザ自動化ツールを使って人間ユーザーのようにE2E確認を行わせることで、コードだけでは見つけにくいバグをAgentが発見・修正しやすくなったと説明されています。また、OpenAIのHarness Engineering記事でも、CodexがUI、ログ、メトリクスを直接読めるようにすることで、バグの再現や修正確認を行いやすくしている例が紹介されています。

基本的な流れはシンプルです。開発サーバーを起動し、対象画面を開き、主要な操作を実行します。そのうえで、アクセシビリティツリー、スクリーンショット、console error、network errorなどを確認します。問題が見つかったら、Coding Agentが修正し、同じ画面をもう一度確認します。

操作確認には、アクセシビリティツリーのような構造化されたUI情報が向いています。一方で、レイアウト崩れ、要素の重なり、Canvas、チャート、画像のような視覚的な問題はスクリーンショットが向いています。この2つを組み合わせることで、Coding AgentによるUI確認の効率は上がっていきます。

代表的なツール

2026年5月時点のUIテストの代表的なツールを以下に紹介します。

まずは比較的軽量な確認として、アクセシビリティツリーを使って主要な操作ができるかを見ます。そのうえで、見た目の確認が必要なところはスクリーンショットで確認します。また、次のように具体的に指示すると、Coding Agentが単体テストだけで完了扱いにしてしまうことを避けやすくなります。

UI変更後は、対象ページをdesktop幅とmobile幅で確認してください。
アクセシビリティツリーで主要操作が可能か確認し、スクリーンショットでレイアウト崩れを確認してください。
console errorまたはnetwork errorがある場合は原因を調査し、修正後に再確認してください。

evalsに向けて

ここまで、ソフトウェアとして壊れていないかを確認するためのテストを見てきました。これらのテストは、AI Agentの出力品質を評価するevalsとは分けて考えることが重要です。

AI Agentの精度を評価したいのに、画面が壊れている、API接続が失敗している、UI上で結果が確認できない、といった問題が混ざっていると、評価の意味が曖昧になります。人手評価やLLM as a judgeにかかる時間やAPIコストも無駄になりやすくなります。

だからこそ、ソフトウェアテストはできるだけ軽量に自動化し、Coding Agentが自分で確認・修正できる状態にしておくことが大切です。その土台があると、evalsではAI Agentの確率的な挙動や回答品質に集中できます。

次の章からは、いよいよAI Agentの出力品質そのものを扱います。offline evalsを通じて、回答が正しいか、役に立つか、根拠があるか、といったAIらしい品質をどのように評価していくかを見ていきます。