Agentic Testingとは？既存のテスト自動化との違いを整理する
Agentic Testingという言葉を、海外のブログなどで見かける機会が増えてきました。これまでのテスト自動化や、AIを使った自動テストと何が違うのか、という疑問が浮かぶかもしれません。
本記事では、Agentic Testingの基本的な定義から、既存のテスト自動化との違い、そしてテストピラミッドにおける位置づけまでを整理します。
目次
Agentic Testingとは何か
Agentic Testingとは、AIエージェントに具体的な操作手順ではなくゴールだけを与え、UIの状態を観察しながら次に取るべき行動を自律的に判断させ、そのゴールの達成を検証するテスト手法です。仕組みとしては、UIの状態を観察する、次の行動を推論する、その行動を実行する、という3つのステップを繰り返すループになっています。あらかじめ決められた手順をなぞる従来の自動化とは異なり、状況に応じて経路を変えながらゴールの達成を目指す点が特徴です。
従来のE2Eテストとの違い
従来のE2Eテストは、UI上の特定の手順を検証します。ボタンをクリックし、文字を入力し、結果を確認するという、あらかじめ決められた操作の連なりをそのままなぞる形です。この手順のどこか一つでも変われば、テストは失敗と判定されます。
一方でAgentic Testingは、手順そのものではなく、ゴールが達成できたかどうかを検証します。たとえば「スレッドにメッセージを送信する」というゴールを与えると、エージェントはその時点のUIの状態を観察し、次にとるべき行動を都度判断しながら操作を進めます。検索候補をクリックするのか、Enterキーを押すのか、といった具体的な手段はエージェントの判断に委ねられます。
Slack Engineeringが公開した実験の記事では、この違いを「テストは手順を強制し、エージェントはゴールを検証する」という一文で整理しています。手順の再現性を重視する従来のE2Eテストと、結果の到達可否を重視するAgentic Testingという、検証の軸そのものが異なる点が、この対比からよくわかります。
▶参考：Agentic Testing: Where Agents Fit in the E2E Testing Stack
なぜAgentic Testingが必要なのか
既存のスクリプトベースのテスト自動化には、UIの変更のたびにテストコードのメンテナンスが必要になるという運用上の負担があります。また、事前に手順をすべてスクリプト化しきれない探索的なテストは、自動化の対象から外れがちでした。Agentic Testingは、こうした「手順を事前にすべて書き切れない」領域を、ゴールベースの指示で埋めるアプローチとして注目されています。
これを実用的な形で成立させるには、UIの状態を読み取り、次の行動を推論し、必要であればコードを書いてデバッグする、という一連の能力が欠かせません。大規模言語モデルの進化によって、これらの能力を一つのエージェントに統合できるようになったことが、Agentic Testingが具体的な実装として語られ始めた背景にあります。
AIを使ったテストとの違い
ここまで読んで、「自動修復(self-healing)機能を持つテストツールと何が違うのか」と感じた方もいるかもしれません。
self-healingは既存の自動テストの一部をAIが補助する形です。UI要素の変化をAIが検知し、既存のテストシナリオを修正する、という流れが中心になります。
これに対してAgentic Testingは、テストの実行そのものをエージェントに委ねます。事前に用意されたスクリプトに沿って動くのではなく、ゴールに向けて何をすべきかをエージェントが都度判断しながら進めるという点で、AIの関与の度合いが異なっています。
- 自動修復(self-healing)：既存のテストを補助する仕組み
- Agentic Testing：テストの実行主体そのものがエージェントに置き換わる仕組み
という違いとして整理できます。
Slack社の実験に見る実態
Agentic Testingが実務でどの程度使えるのかを考えるうえで、Slack社が2026年6月に公開した実験は参考になります。同社は200以上のエージェント駆動E2Eワークフローを実際に実行し、信頼性、速度、コストを比較しました。以下で紹介する数値やモデルは、いずれもこの記事で報告されている内容にもとづいています。
実験の概要
実験では、3つの実行方式が比較されています。
- Playwright MCPを介してエージェントがブラウザを操作する方式
- Playwright CLIのコマンドを介して一手順ずつ操作する方式
- エージェントが自然言語のテスト手順からPlaywrightのテストコードを生成し、決定論的なテストとして実行する方式
テストフローには、チャンネル作成からスレッド返信までを含む比較的シンプルな流れと、検索結果の閲覧や画面遷移を含むやや複雑な流れの、2種類が使われました。
Playwright MCPについては以下の記事も参考にしてください。
信頼性、速度、コストの結果
結果には、方式ごとに明確な傾向が見られました。
| 方式 | 失敗率(シンプルな手順) | 失敗率(複雑な手順) | 平均実行時間 |
|---|---|---|---|
| 1. Playwright MCP経由のエージェント | 0% | 約12% | 約5〜8分 |
| 2. Playwright CLI経由のエージェント | 約12% | 約20% | 約9〜11分 |
| 3. エージェント生成のPlaywrightテストコード | 約8% | 約48% | 約3分 |
3のエージェント生成のテストコードは、シンプルな流れでは実用的な失敗率にとどまるものの、複雑な流れでは失敗率が大きく上昇しています。実行速度自体は最も速いものの、生成されたテストが実際の複雑なUI状態にうまく追従しきれない場面があったと報告されています。
コスト面では、エージェント駆動の実行(1, 2)は1回あたり15〜30ドルかかったとされています。決定論的なテスト(3)と比べると高コストであり、この費用の大部分は、エージェントが各ステップでUIの状態を読み込み直す際に発生する、会話履歴の再送信によるトークン消費が占めているようです。
エージェントの「適応性」という特徴
同じゴールを与えた実行同士を比較しても、全く同じ操作の並びになったのは全体の約20%にとどまったとされています。残りの実行では、メニューを開く順序が異なっていたり、同じ結果に至るまでの経路が毎回微妙に違っていたりしました。
これは、決定論的なテストが単一の手順を厳密に再現するのに対し、Agentic Testingはゴールに至る経路そのものを探索する性質を持つことを示しています。同じ入力に対して毎回同じ結果を期待する従来のテストの感覚とは、前提が異なる点に注意が必要です。
▶参考：Agentic Testing: Where Agents Fit in the E2E Testing Stack
テストピラミッドの4層目としての位置づけ
ここまでの内容を踏まえると、Agentic Testingをどこに位置づけるべきかが見えてきます。Slack社は、単体テスト、統合テスト、E2Eテストという既存の3層の上に、Agentic Testingを第4層として加えるモデルを提示しています。
引用：Agentic Testing: Where Agents Fit in the E2E Testing Stack | Engineering at Slackより
Agentic TestingもE2Eテストと同じく、UIを通じて実際のユーザーの操作フローを検証しています。違いは、その検証がどのように実行されるかという部分にあります。
決定論的なE2Eテストは、高速で反復可能、かつ（Agentic Testingに比べると）運用コストが低く、CI環境での回帰テストに向いています。一方でAgentic Testingは、複雑なUI挙動の探索や、不安定な(フレーキーな)ワークフローのデバッグ、本番環境で起きたバグの再現といった用途に適していると整理されています。
どちらか一方に置き換えるのではなく、決定論的なテストがCIの土台を担い、その上にAgentic Testingという探索的な層を重ねる、という関係として捉えるのが妥当です。
Agentic Testingの代表的なユースケース
Agentic Testingが実際にどのような場面で使われ始めているかを、具体的に見ていきます。
複雑なUI挙動の探索では、複数の状態遷移や条件分岐が絡み合う画面において、想定しうる操作パターンをすべて事前にスクリプト化するのが現実的でない場合があります。ゴールだけを指示してエージェントに探索させることで、事前に想定していなかった経路での不具合を見つけられる可能性があります。
フレーキーなワークフローの原因調査では、特定の条件下でのみ失敗する不安定なテストについて、エージェントに同じゴールを繰り返し試行させることで、失敗が起きやすい条件を洗い出す手がかりが得られます。
本番環境で発生したバグの再現では、ユーザーからの不具合報告をもとに、再現手順を人間が一から書き起こすのではなく、エージェントに状況を伝えて再現を試みてもらう、という使い方が考えられます。
新機能のリリース前における探索的な確認では、決定論的なテストシナリオがまだ整備しきれていない新機能に対して、リリース前の動作確認をエージェントに任せる、という活用法も考えられます。
Agentic Testingの導入方法
Agentic Testingの導入について、確立された手順があるわけではありませんが、いくつかの現実的な進め方が考えられます。
まず、CIに組み込む決定論的なテストをすべて置き換えるのではなく、既存の自動化では手が回っていない探索的な用途、たとえば新機能の探索的確認やフレーキーなテストの原因調査といった、限定的なスコープから試すのが現実的です。
次に、既存のテスト自動化基盤との役割分担をあらかじめ整理しておくと、導入後の混乱を避けやすくなります。既存のテスト自動化ツール、たとえばMagicPodのようなノーコードや低コードのテスト自動化ツールは、決定論的なテストシナリオをCI環境で安定して繰り返し実行することを主眼に置いています。Agentic Testingは、こうした既存の自動化を置き換えるものというより、既存の自動化ではカバーしきれない探索的な検証を補う選択肢の一つとして捉えるのが、現時点では実態に近いといえます。
Agentic Testingの課題
現状のコスト構造を考えると、高頻度で実行するCI環境への組み込みには向いていません。実行のたびに数分から十数分の時間と、数十ドル規模のコストがかかる点は、モデルやツールの進化によって今後変わっていく可能性がありますが、現時点では見過ごせない制約です。
また、エージェントが毎回異なる経路でゴールに到達するという適応性は、裏を返せば同じ失敗を再現しにくいという課題にもつながります。障害調査のためのログや実行履歴を、決定論的なテストよりも丁寧に記録しておく必要があります。
Agentic Testingの今後の展望
現時点でのAgentic Testingは、コストや再現性の面でまだ発展途上の技術です。ただし、モデルの推論効率が上がれば、実行コストや速度は改善していく可能性があります。
今後は、決定論的なテストとAgentic Testingを組み合わせて使う運用パターンが、テスト自動化の選択肢の一つとして定着していく可能性があります。
まとめ
Agentic Testingは、手順ではなくゴールの達成を検証するという点で、従来のE2Eテストとは検証の軸が異なるアプローチです。Slack社の実験データからは、信頼性、速度、コストの面でまだ発展途上の技術であることもうかがえます。
テストピラミッドの観点では、既存の3層を置き換えるものではなく、探索的な検証を担う第4層として位置づけるのが実態に近いといえます。コスト面での制約から高頻度なCI実行にはまだ課題があるものの、複雑なUI挙動の探索やフレーキーなワークフローのデバッグ、本番バグの再現といった用途では、今後の活用の広がりが期待できる領域です。
既存のテスト自動化とAgentic Testingをどのように組み合わせるかは、今後のテスト戦略を検討するうえでの論点の一つになりそうです。
