技術的概要：自律型 QA エージェント

問題定義

本論文は、現代のソフトウェア開発における重要なボトルネック、すなわち品質保証（QA）が迅速なアジャイルおよび DevOps サイクルに追いついていないという課題に取り組んでいる。主要な課題は、人間が読み取れる要件（自然言語、モックアップ）と機械が実行可能なテストコード（Selenium スクリプト）との間の「意味的ギャップ」である。大規模言語モデル（LLM）はコードを生成できるが、「盲目のコーダー」という問題に悩まされている。すなわち、テスト対象アプリケーション（AUT）に関する知識が欠如しているため、存在しない UI 要素を幻覚視することが頻繁に発生する（例：実際の ID が #btn-confirm であるにもかかわらず、#submit といった ID を推測する）。これにより、スクリプト実行の失敗率が上昇する。モデルベーステスト（MBT）などの既存のアプローチは維持が複雑すぎる一方、標準的な LLM 生成は特定のアプリケーションコンテキストに基づく適切なグラウンディングを欠いている。

手法

著者は、テストスクリプト生成を機能的要件とアプリケーションの実際の構造的現実の両方にグラウンディングするために設計された、検索拡張生成（RAG）フレームワークである「自律型 QA エージェント」を提案する。

システムアーキテクチャ

本システムは、5 つのレイヤーから構成されるモジュール型マイクロサービスベースのアーキテクチャである。

1. フロントエンド: ドキュメントのアップロードとテスト生成のための Streamlit インターフェース。
2. API: オーケストレーションと RESTful エンドポイントを処理する FastAPI レイヤー。
3. サービス: ドキュメント解析や RAG パイプラインを含むビジネスロジックをカプセル化する。
4. データレイヤー: 高次元の埋め込みを格納するためのベクトルデータベースとして ChromaDB を利用する。
5. モデルレイヤー: 低遅延推論のために Groq の API を通じて Llama 3.1-8b-instant を統合する。

RAG パイプラインと取り込み

中核的な革新は、以下の 2 つを処理するマルチモーダル取り込みパイプラインである。

• テキスト要件: Markdown、PDF、JSON 形式の PRD および仕様書。
• 構造的コンテキスト: AUT の DOM を表す生 HTML ファイル。

前処理戦略は、テキストに対しては 再帰的文字テキストスプリッター（1000 文字のチャンク、200 文字のオーバーラップ）を用いる。HTML については、スクリプトとスタイルを除去し、Selenium セレクターに不可欠な構造タグ（div、input、button）と属性（id、class、name）のみを保持する。

生成プロセス

パイプラインは厳密な数学的定式化に従う。

1. 埋め込み: テキストおよび HTML チャンクを all-MiniLM-L6-v2 を使用して 384 次元のベクトル空間にマッピングする。
2. 検索: ユーザーのクエリ（例：「チェックアウトフローをテストする」）に対して、最も高いコサイン類似度を持つ上位-$k$（通常 $k=3$）のチャンクを検索する。重要なのは、ドキュメントと HTML チャンクの両方をフィルタリングしてマージすることである。
3. コンテキスト融合とプロンプト作成: 検索されたドキュメント（[DOCUMENTATION]）と HTML 構造（[HTML STRUCTURE]）を明示的に分離したプロンプトを構築する。
4. 制約: プロンプトは、「提供された HTML からの ID のみを使用する」や「動的要素に対して WebDriverWait を追加する」といった制約を強制する。
5. 生成: LLM は、このグラウンディングされたコンテキストに基づいて Python Selenium スクリプトを生成する。

主要な貢献

1. QA 向けの革新的な RAG アーキテクチャ: コードまたはテキストのみを対象とする一般的な RAG システムとは異なり、テキストの機能的要件と構造的な HTML/DOM コンテキストという 2 つの異なるコンテキストタイプを検索する専用システム。
2. マルチモーダル取り込みパイプライン: 包括的な知識基盤を構築するために、多様な形式（Markdown、PDF、JSON、HTML）を処理できる堅牢なパイプライン。
3. コンテキスト認識型スクリプト生成: 実際の HTML 構造に基づいてグラウンディングされた Selenium スクリプトを生成する実証済みの手法であり、要素の位置特定エラーを大幅に削減する。
4. 再現可能な評価: 20 のテストシナリオにおける統計分析を伴う詳細な実験設定により、AI 駆動型テストのためのベンチマークを提供する。

実験結果

本システムは、4 つのページにわたる 127 個の DOM 要素を持つカスタム E コマースアプリケーションで評価された。評価では、**自律型 QA エージェント（RAG）**と、コンテキストなしの 標準 LLM ベースライン（Llama 3.1-8b）を比較した。

主要指標（3 回の実行の平均）:

• 構文妥当性: RAG は 100% を達成（ベースラインは 95%）。
• 要素解決: RAG は 95% を達成（ベースラインは 40%）。この指標は、ターゲット DOM 要素を位置特定するセレクターの精度を測定する。
• 実行成功: RAG は 90% を達成（ベースラインは 30%）。これは例外なく最初から最後までスクリプトが実行されることを測定する。

統計的有意性:
2 標本 t 検定により、改善が統計的に有意であることが確認された（$p < 0.001$）。効果量も大きく（解決については Cohen's $d = 3.2$、実行については $d = 3.8$）、実質的な効果を示している。

アブレーション研究:

• テキストのみの RAG: 解決率 60%。
• HTML のみの RAG: 解決率 85%。
• 完全な RAG（テキスト + HTML）: 解決率 95%。
  これは、DOM の構造的な理解が UI 自動化に不可欠であり、意味的な要件だけでは不十分であることを確認するものである。

失敗分析:
RAG エージェントの 10% の失敗率は、以下の要因に起因すると考えられた。

1. 動的要素のタイミング: 静的 HTML スナップショットでは捕捉されない JavaScript アニメーション後にのみ表示される要素。
2. 曖昧なコンテキスト: 複数の類似要素が存在する場合の、曖昧さを解消するコンテキストの不足。

意義と主張

本論文は、LLM 基盤のコード生成における幻覚問題が、ドメイン固有の RAG アーキテクチャを通じて効果的に緩和され得ると主張する。AUT をブラックボックスではなく、取り込むべき知識源として扱うことで、システムは LLM が有能な QA エンジニアとして機能することを可能にする。

著者は、セレクターの特定とボイラープレート生成を自動化することにより、QA エンジニアのスクリプト作成時間を 60〜70% 削減できると推定している。標準 LLM の方が高速である（エンドツーエンドのレイテンシが 4 秒対 13.2 秒）としても、ベースラインの 70% の失敗率に必要な手動デバッグ時間を考慮すると、RAG アプローチの方がコスト効果が高いと論じている。

本研究は、「自己記述・自己修復」テストスイートの基盤として位置づけられているが、著者は静的 HTML 取り込みに関する限界（シングルページアプリケーションでは困難）や、E コマース以外の多様なドメインにおけるさらなる検証の必要性について、控えめに認めている。