イーサン・プロネフ氏は、AI駆動型QAテストフレームワークApproximaの共同創業者である。
AI支援開発の台頭により、ソフトウェアエンジニアは数年前には不可能と思われたペースで製品をリリースしている。しかし、開発者が扱うAI生成コードの信頼性の低さと量の多さにより、その正確性に対する確信はかつてないほど低下している。
この問題に対処するため、企業（筆者の会社を含む）はAIネイティブなソフトウェアテスト製品の新たな波に取り組んできたが、採用率は低く、この分野を支配するプレーヤーはまだ現れていない。なぜこのような状況になったのか、そしてなぜ誰も勝利していないのか。
ほぼ解決されていた問題
テストの領域は伝統的に3つの層に分かれてきた。ユニットテスト、統合テスト、そしてエンドツーエンド（E2E）テストである。最初の2つは概ね解決されている。成熟したフレームワークが存在し、パターンは十分に理解され、ユニット・統合テストスイートの構築と保守は容易だ。
エンドツーエンドテストは、事態が複雑になる領域だ。PlaywrightやCypressのようなツールがE2Eテストのデフォルト選択肢となっている。現代的なウェブコードベースで作業したことがあれば、ほぼ確実にどちらか、あるいは両方に遭遇しているはずだ。
しかし、それはすべてが解決されたことを意味しない。テストは、タイミングの問題、非決定論的なUI動作、競合状態により不安定になる可能性があり、また、常に変化するCSSクラスやDOM要素に紐付けられたセレクタにより脆弱になる可能性がある。その結果、多くのチームは包括的なE2Eカバレッジを諦め、手動の人間主導QAに戻るが、これはスケールしにくく、問題を遅れて発見することになる。
ノーコード・エージェント型テストの約束
最近、魅力的な提案を持つツールのカテゴリが登場した。もし平易な英語でテストを記述し、AIエージェントをアプリケーションに向け、残りを解決させることができたらどうだろうか。セレクタは不要。スクリプトも不要。意図だけでよい。技術者でないチームメンバーが「新規ユーザーがサインアップを完了してダッシュボードに到達できることを確認する」と入力すれば、エージェントがブラウザをナビゲートし、フローをクリックして報告する。
エージェント型テストは、最もホットで競争の激しいニッチの1つとなった。しかし、これにもかかわらず、PlaywrightやCypressの市場支配に近いものを達成したツールは存在しない。なぜ採用率はこれほど低いままなのか。
なぜ誰も勝利していないのか
主な問題は、エンドツーエンドテストが本質的に、単純なものに偽装された深く技術的な活動であることだと考える。最上層（ユーザーがブラウザをクリックする）の下には、包括的なE2Eセットアップには、本番エンドポイントのモック化、ネットワークリクエストのインターセプト、データベースのシード、スタックのあらゆる層での正確なアサーション、CIパイプラインとの緊密な統合が含まれる。
エージェントを十分に汎用的にして、全体の表面積を処理し、あらゆるチームの期待に応えることは、実質的に不可能な課題だ。誰もがわずかに異なるセットアップを持っている。
さらに、ロジスティック上のオーバーヘッドがある。エージェントは遅く、コストがかかる。4秒で実行されるスクリプトが、45秒かかるエージェントに置き換えられる。規模が大きくなると、これは急速に複合する。そして、エージェントは、LLMが非決定論的であるという事実に起因する新しい形の不安定性をもたらす。昨日合格したテストが今日失敗する可能性があるが、それはアプリケーションが変更されたからではなく、エージェントが異なる動作を決定したからだ。
また、見過ごされがちな、より人間的な要因もある。テストは常にコードベースの延長だった。リポジトリに存在し、レビューされ、アプリケーションがどのように動作すべきかについての組織的知識をエンコードする。当然ながら、開発者は、インフラストラクチャのこのような中核コンポーネントを取り除き、制御できないサードパーティのSaaSダッシュボードに渡すことに消極的だ。
ここで、物語は予期しない展開を見せる。
コードが王として復権
ノーコードテスト運動は、テストスクリプトの作成と保守がボトルネックであり、多くのチームが割けないエンジニアリング時間とスキルを必要とするという論点に基づいていた。その仮定は形成された当時は理にかなっていたが、今日ではあまり真実ではない。
LLMはコードを書くことに優れている。テストの生成、脆弱なセレクタのリファクタリング、テストスイートの保守は、AIコーディングが輝くタスクの種類だ。エンジニアリングチームはすでにコードを書くためのAI支援ワークフローを採用しているため、当然、これはテストの作成にも拡張されるべきだ。むしろ、テストはLLMが上手く書けるものだ。なぜなら、構造化され、制約があり、明確な成功基準があるからだ。
コードを抽象化しようとしていたカテゴリは今や、コードを書くことがもはやボトルネックではない世界と競争している。
答えはどのようなものか
E2Eテストの解決策は、スクリプトをエージェントに置き換えることではなく、決定論的ロジックが不足する場所で、AIでスクリプトを拡張することだと考える。
• 不安定性：ページ読み込みのためのハードコードされた待機の代わりに、エージェントにページを観察させ、準備ができたときを判断させる。
• 脆弱性：CSSセレクタの代わりに、基礎となる実装に関係なく正しい要素を見つけるための自然言語命令を挿入する。
• 主観性：ブール値のアサーションの代わりに、エージェントにスクリーンショットを評価させ、視覚的出力が意図と一致するかどうかを判断させる。
いずれの場合も、テストは依然としてコードだ。リポジトリに存在する。開発者が依然として作成し、所有する。AIは、AIが実際に得意なことを行っている。基盤全体を置き換えるのではなく、スクリプト化されたロジックが硬直的すぎるか脆弱すぎる場所のギャップを埋めることだ。
もちろん、AIでスクリプトを拡張することには、独自の課題がないわけではない。完全にエージェント型のテストが苦しむのと同じ非決定論は、エージェントの範囲を狭めても消えない。AI駆動のセレクタや視覚的アサーションは、実行間で依然として異なる動作をする可能性があり、失敗のデバッグには、アプリケーションロジックとモデルの判断の両方について推論する必要がある。
これを軽減するために、開発者は境界線がどこにあるかについて思慮深くなければならない。AIを過度に適用すると、実質的な利益なしに同等またはより脆弱な結果を生み出す可能性がある。いくつかのプラクティスが役立つ。ドリフトを検出できるようにモデルバージョンを固定する。失敗のトリアージが容易になるように優れた可観測性に投資する。可能な限りAI駆動ステップに決定論的フォールバックを追加する。
もちろん、これを推論し、どのテストがAIから恩恵を受けるかを正確に結論付けるには時間と労力がかかり、皮肉なことに、これはまさに開発者がQAプロセスを洗練する際に排除したい種類の作業だ。最終的に、AI拡張はスイート内でその地位を獲得しなければならず、その境界線がどこに落ちるかは、チームごとに異なって見えるだろう。
これを解決するチームは、何か新しいものを発明したというよりも、他者が始めたことを完成させたように見えるかもしれない。
