エージェンティック・テスティング - E2Eテストスタックにおけるエージェントの役割

• Slackエンジニアリングチームが、エージェントベースのE2E(End-to-End)テストが既存の決定論的(deterministic)テストを置き換えられるかを検証するため、200件以上のエージェンティック・ワークフローを実行した実験結果
• 従来のE2Eテストが決められたUIパスを強制する一方で、エージェントは目標(goal)の達成可否を検証し、同じ結果に異なる経路で到達
• エージェント実行は1回あたり$15–30、10分以上を要するが、信頼性の面で明確な活用先が存在
• Playwright MCP方式はCLI・コード生成方式より低い失敗率と少ないトークン使用量を記録し、実行環境の安定性が結果を左右
• エージェンティック・テスティングは既存テストを置き換えるのではなく、テストピラミッド最上層に探索・デバッグ・複雑な動作検証のレイヤーとして追加される

---

ジャーニーから目標へ (From Journeys to Goals)

• 従来のE2EテストはUIに沿った特定のジャーニー(journey) を検証 → クリック → クリック → 入力 → アサート(assert)
• エージェントベースのテストは「スレッドメッセージを送信する」のような指示で表された目標の達成可能性を検証 → 目標 → エージェントの適応 → 結果の検証
  • 中核となる違い: 「テストはジャーニーを強制し、エージェントは目標を検証する」
• ワークフロー全体(ログイン → 検索 → 結果 → 初期化)は一定だったが、実際の動作順序は毎回異なった
  • 異なる入力方式(検索候補をクリック vs Enter入力)
  • 異なる探索パターン(検索を再実行 vs 既存状態を再利用)
  • 追加または省略されるステップ(追加クリック、スナップショット、中間動作)
• 柔軟性には信頼性・コスト・実行時間の面でトレードオフが伴う

• 問題提起

  • 1回あたり**$15–30、10分以上**かかる方式が、現代的なテストワークフローに組み込めるのかが中核の問い
  • 200件以上の実行結果から、従来テストとは本質的に異なりつつも、高い信頼性と明確な活用先が確認された
  • コード作成・失敗時のデバッグ・UIの直接操作を可能にした大規模言語モデル(LLM) の進化が、新しい実行モデルを可能にした

実験構成 (Our Experiment)

• 信頼性・実行速度・コストを測定するため、複数構成で200件以上の自動実行を実施

• 実行モデル (3つの方式)

  • Agent + Playwright MCP: エージェントが事前定義されたブラウザ操作(要素クリック、入力、DOM状態の読み取りなど)でブラウザと対話し、持続的コンテキスト(DOMスナップショット・ログ)を維持
  • Agent + Playwright CLI: シェルでPlaywright CLIコマンドを実行し、1ステップずつ処理。更新されたUI状態を見て次の動作を決定
  • Generated Playwright Tests: AIエージェントが自然言語による説明から決定論的なPlaywrightコードを生成し、標準E2Eテストとして実行して合格するまで反復改善

• 実験環境

  • MCP・CLIエージェントモデル: Claude Sonnet 4.5
  • 生成型Playwrightテストモデル: Claude Opus 4.6
  • 実行: 非対話型Claude Code (claude -p)
  • ブラウザツール: Playwright MCP, Playwright CLI
  • 環境: Slack Dev API MCP、全実験を非本番データのテストワークスペースで実施

• テストフロー (複雑さ2段階)

  • Thread Reply (単純): チャンネル作成、メッセージ送信、スレッド返信、スレッド状態の検証を含む約15–20ステップのワークフロー
  • Search Discovery (中程度の複雑さ): 検索語入力、結果探索、ビュー間移動(検索・チャンネル・スレッド)、期待結果の検証を含む約25–30ステップのワークフロー

• 入力形式

  • 自然言語(NL): ワークフローと期待結果をステップごとのリストで記述した、人が読みやすい指示
  • 構造化YAML: 同じワークフローをステップ・動作・対象・期待結果として明示した構造形式
    • 違いは詳細度ではなく表現方式 — 自然言語はエージェントが解釈・マッピングする必要があり、YAMLはそのマッピングをより明示的に定義

• 実験マトリクス

  • 各構成を20回ずつ実行し、合計5実験(MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, 生成テスト-NL)をThread Reply・Search Discoveryの2フローに適用

観察結果 (What We Observed)

• 結果要約

  • Agent (Playwright MCP): 失敗率 0%(thread reply) / 約12%(search discovery)、平均5–8分
  • Agent (Playwright CLI): 失敗率 約12% / 約20%、平均9–11分
  • Generated Playwright Tests: 失敗率 約8% / 約48%、平均3分

• 信頼性 (Reliability)

  • フローが複雑になるほど、信頼性の差が最もはっきり現れた
  • Playwright MCPが最も安定 — 単純シナリオではほぼ0%の失敗率、複雑フローでも0–12%を維持
  • Playwright CLIは失敗率がより高い(約12–20%)。大半はモデル推論ではなく、認証処理・ナビゲーションのタイミング・セッション不安定性といった実行上の問題で発生
  • 生成テストは単純フローでは良好(約8%)だったが、複雑ワークフローでは大きく悪化(約48%)
    • 完全に誤っているわけではなく、通常はフローの70–80%まで進んだ後、最後のインタラクションやアサートで失敗
    • 失敗原因はUI状態の変動性と抽象化の不一致 — ゆるく記述された自然言語フローから生成され、既存のページオブジェクト抽象化を再利用することで、精密な要素ターゲティングが妨げられた
  • 複雑さが増すほど信頼性の差は拡大し、MCPのようなエージェントネイティブな実行モデルの方が安定的
    • MCPはアプリのリアルタイムで安定したビューを維持する一方、CLIは各ステップでのスナップショットから状態を再構成するため、フローが長くなるほど不一致が蓄積
    • MCPはセッション内で前段の成功したインタラクションを再利用しているように見え、CLIは各ステップで毎回最初からやり直しているように見える(明示的には測定していない)

• 速度 (Speed)

  • 生成テストが一貫して最速(約3分)、MCPは約5–8分、CLIは約9–11分
  • 生成テストの数値にはテスト生成+実行を含み、各テストは1回生成後に5回実行した平均
    • 実際の純粋な実行時間ははるかに短い — thread replyは約32秒、search discoveryは約45秒
    • 繰り返し実行されるCI環境では、一度きりの生成コストは無視できる水準になり、決定論的テストが効率的にスケールする
  • エージェントワークフローは実行のたびにコストが発生 — 各ステップでUI状態の観察、次の動作の推論、動作実行と結果検証が必要

• 適応性 (Adaptability)

  • 同一の動作順序に従った実行は**約20%**にすぎず、大半は同じ目標に到達するための異なる有効なUIパスを見つけた
    • メニューを異なる順序で開く
    • わずかに異なるUI要素を選択する
    • 代替のナビゲーションフローを使う
  • 測定のため、実行間でアクションシグネチャ(action signature) を比較 — エージェントが行ったツール呼び出し・UI操作の順序一覧
    • 比較前に正規化を実施: パラメータ、待機/スナップショット動作、等価なツール差分(fill vs type)を統合し、意味のある差異のみを算出
  • 最終結果が正しくても、大半は動作順序が異なっていた — 従来E2Eは単一の決定論的ジャーニーを強制するのに対し、エージェントはインターフェースを探索しながら目標状態への到達可否を検証する

• コストとその発生源 (Cost and Where It Comes From)

  • エージェント実行は通常1回あたり$15–30で、従来テストよりはるかに高価
  • 同じsearch discoveryフローにおけるトークン使用量の分析
    • MCP (Opus 4.6) 約3.8M, MCP (Sonnet 4.5) 約3.5M, MCP (Haiku 4.5) 約5.7M
    • CLI (Opus 4.6) 約6M, Code Gen (Opus 4.6) 約7M
  • どのモデルを使うかより、どう実行するかの方が重要 — Haikuの方がトークンを多く使ったが、すべてのMCP方式はCLI・Code Genよりトークン使用量が少なかった
  • Claude Codeのセッション実行方式の分析: 基盤APIがステートレス(stateless) のため、毎ターンごとにシステムプロンプト全体と会話履歴全体を再送
    • コストを決めるのはモデル出力ではなく、コンテキストの蓄積速度とターン数
  • ターン数: MCP (Opus/Sonnet) 約40, MCP (Haiku) 約60, CLI (Opus) 約85, Code Gen (Opus) 約70
    • CLIでは各ブラウザインタラクションが、動作・待機・スナップショット・読み取り・要素問い合わせなど複数コマンドに分割され、平均85ターンに達した
    • MCPはインタラクションと状態返却を単一のラウンドトリップに統合
    • ターンが増えるたび、システムプロンプト全体のコストと過去の会話コンテキスト再送の負担が加わる
  • コンテキストを埋める要素
    • MCP・CLI: ブラウザスナップショットが主なペイロード — Playwright MCPが返すアクセシビリティツリー(accessibility tree)のスナップショットが、その後の全ターンに蓄積
    • Code Gen: リトライごとに、完全なエラートレース・アサート失敗・DOM状態を含むテストランナー出力が蓄積
  • コストの大半は既に見た内容の再送であり、各ターンで新たに追加される情報はごく一部
  • トークン使用量はまだ最適化されていない段階 — 削減手法としてプロンプトキャッシング、コンテキスト圧縮(compaction)、スナップショット頻度の削減を提示
  • コストのため、現時点では高頻度CI実行より対象を絞ったデバッグ・探索的テストにより適しており、将来のモデルやツールで改善の可能性がある

• インフラの重要性 (MCP vs CLI)

  • モデル自体だけでなく実行環境も信頼性に大きく影響 — MCPは0–12%、CLIは12–20%の失敗率
  • CLIの失敗の大半は認証・ナビゲーション問題(ログインエラー、タイムアウト、セッション不安定)に由来し、エージェント推論ではなく実行レイヤーの問題
  • Playwright MCPは、構造化されたブラウザプリミティブとエージェントのツール呼び出しワークフローとの緊密な統合を提供し、CLIはエージェントとブラウザの間に追加レイヤーを導入する
  • 並列化の違い: MCPは同時実行が容易で、CLIは並列化が難しく大半が逐次実行
  • 信頼性・速度・コストはモデルだけでなく、実行環境の安定性と設計に左右される

• 実行能力の境界 (Execution Capability Boundaries)

  • 本実験は単一セッションのUIワークフローに焦点を当てた
  • クロスワークスペースのフローや複数ブラウザウィンドウを開くワークフローでは、実行モデルの選択がエージェントそのものと同じくらい重要になる別の難題が伴う
    • MCPは長いフローで観察ループが増え、コスト問題が生じる可能性
    • CLIは複数ブラウザセッション管理時に、調整の複雑さと高いトークン使用量が生じる可能性
  • どちらの方式も対応可能だがトレードオフは異なる — 本実験では未検証であり、評価チームが考慮すべき重要事項

テストピラミッドにおけるエージェンティック・テスティングの位置

• エージェンティック・テスティングは既存方式を置き換えるのではなく、その上に新しい能力を追加する

• 決定論的E2Eテスト

  • CIにおける高速で再現可能な回帰テストに最適
    • 人が書く場合もAIが生成する場合もある
    • 高速で再現可能、CIフレンドリー
    • 運用コストが低い
    • 特定のUIジャーニーを強制する

• エージェンティック・テスティング

  • 定められたスクリプトを実行するのではなく、目標から出発する — UIを観察し、現在状態を推論し、望ましい結果に到達する方法を決定
    • 複雑なUI動作の探索
    • 不安定な(flaky)ワークフローのデバッグ
    • 本番バグの再現

• エージェンティック層を含むテストピラミッド

  • システム観点では、エージェンティック・テスティングはE2Eと同じレベルでUIを通じて実際のユーザーワークフローを検証し、違いはワークフローの実行方法にある
  • 将来の最も効果的なテスト戦略は両者の組み合わせ — 決定論的テストがCIの安定した土台を提供し、エージェンティック・テスティングがピラミッド最上層で探索・デバッグ・複雑動作の検証を担う