本記事は公開時点（2026年08月10日）の情報です。AI関連のサービスや仕様は変化が速いため、最新の情報は各公式サイトをご確認ください。
バイブコーディングという言葉が定着して、動くコードができあがるまでの速度は桁違いに上がりました。そうなると口を揃えて言われるのが「これからはテストが大事」です。AIが書いたコードを人間が全行レビューするのは現実的ではないので、正しさの担保はテストに寄せるしかない、という理屈で、これには弊社も異論ありません。ただ、その要となるE2Eテストは、書いてもUIの変更でセレクタが壊れ、直すコストに疲れて放置されがちなのが実情です。白状すると、弊社のコーポレートサイトもユニットテストはあるのにE2Eは未整備のままでした。では、そのテスト自体もエージェントに任せたらどうなるのか。
そんなことを考えていた折に読んだのが、Slack のエンジニアリングブログ Agentic Testing: Where Agents Fit in the E2E Testing Stack（2026年6月）です。200回以上の自動実行で「AIエージェントにテストをさせる」を定量評価した実験レポートで、こう整理しています。従来のテストは経路を強制し、エージェントは目標を検証する。click→type→assert の代わりに「スレッドに返信して」という目標を渡し、エージェントがUIを観察しながら自力で経路を見つける、というアプローチです。
数字も具体的でした。Playwright MCP 方式が最も安定（単純フローで失敗率0%）、AI生成の決定的テストは複雑フローで失敗率48%まで悪化。1実行 $15〜30 とコストは高く、興味深いことに同じ操作順序を辿った実行は全体の約2割だけ。残り8割は違う経路で同じゴールに到達していたそうです。モデルはブラウザ操作が Claude Sonnet 4.5、テスト生成が Claude Opus 4.6 という構成でした。
読んで終わりでは芸がないので、うちのサイトでミニチュア版を追試しました。
実験の設計
Slack の構成を、コーポレートサイト規模に縮めて再現しました。題材は副作用のない2フローです。
- フロー①（単純）: ROIシミュレーターで「月給30万円・従業員30人・削減30分/営業日のときの月間削減額を調べて」
- フロー②（探索）: 「技術ブログから地図APIのコスト問題の記事を探して、Google Maps を選ぶべきケースを要約して」
比較したのは2方式。エージェント方式は、Claude のサブエージェントに上記の目標文だけを渡し、ブラウザ操作ツール（Slack と同じく Playwright MCP）で自力達成させます。ポイントはUIの構造もURLも一切教えないこと。生成テスト方式は、同じ目標を決定的な Playwright テストに書き起こして繰り返し実行します。モデルは執筆時点の最新である Claude Fable 5 で統一しました（Slack のように操作用と生成用でモデルを分けていません）。なお LLM が動くタイミングは方式で異なり、エージェント方式は毎回の実行でモデルがブラウザを操作するのに対し、生成テスト方式でモデルを使うのはスペックを書き起こす最初の1回だけ。書き上がった Playwright テストの実行はただのコードで、LLM は関与しません。エージェント方式を各3回、生成テスト方式を各5回、さらに Slack の3方式に揃えるため、MCPツールを使わずエージェントが Playwright スクリプトを自作してシェルから段階実行する「CLI方式」も1回試しました。計17実行です。
結果
| 方式 | フロー | 成功 | 1実行の所要時間 | ツール呼び出し |
|---|---|---|---|---|
| エージェント | ROI（単純） | 3/3 | 41〜56秒 | 6〜7回 |
| エージェント | 記事探索 | 3/3 | 36〜46秒 | 6〜7回 |
| CLI | ROI（1回のみ） | 1/1 | 126秒 | スクリプト5本を段階実行 |
| 生成テスト | 両フロー（計10回） | 10/10 | 2.8〜5.4秒 | なし（実行時LLMコストゼロ） |
全実行成功、という表の見た目より、過程のログのほうがずっと面白かったので3つ紹介します。
発見1: 3回とも違うルートでゴールする
記事探索フローでは、2回目のエージェントはフッターのリンクから技術ブログへ入ったのに対し、1回目と3回目はトップページで /blog へのリンクを見つけると、クリックせずURLを直接叩いて移動しました。ROIフローも、フッター経由が1回、トップの試算カード経由が2回。手段もばらけていて、ページ内検索ツールで記事を絞り込む個体もあれば、スナップショットを読んで探す個体もいます。それでも全員が正しいゴールに到達し、記事探索の要約内容もほぼ一致。Slack の言う「同一経路は2割だけ」を、たった6回の実行で体感した格好です。
これは従来のE2Eテストと真逆の性質です。決定的テストなら「フッターのリンクが壊れた」ことは検知できますが、エージェントは別の入口から入ってしまうので気づかない。ユーザーが目的を達成できるかを検証しているのであって、特定の導線が生きているかを検証しているのではない、という違いがはっきり出ます。
発見2: つまずくのはUIではなく実行環境
17実行のなかでエージェントがつまずいた場面は2回だけありますが、どちらもサイトのUIではありません。1つはROIフローの3回目で、クリック対象の指定書式を間違えてツールにエラーを返された場面。エージェントは書式を自分で直してそのまま続行しました。もう1つはCLI方式で、詰まったのは Node.js のモジュール解決エラー（ERR_MODULE_NOT_FOUND）のほうで、node_modules へのシンボリックリンクを張って自己解決しています。Slack も CLI 方式の不安定さの原因を認証やセッション管理といった環境要因に求めていて、「信頼性の差はモデルではなく実行環境に起因する」という彼らの結論に、規模は違えどうちの実験も着地しています。
頼もしい話に聞こえますが、裏返すと障害を報告するより先に回避してしまうということでもあります。今回の2件はたまたま環境側の問題でしたが、これがもしサイト側の実在するバグだったら、エージェントは同じ調子で回り道をして「成功」と報告していたはずです。リグレッション検知の道具として使うなら、この性質は明確な弱点になります。
発見3: コストは2桁違う
エージェント方式は1実行あたり4〜5万トークンを消費し、36〜56秒かかりました。生成テストは3〜5秒・実行時のLLMコストゼロ。うちの短いフローでもこの差なので、Slack の15〜30ステップのフローで1実行 $15〜30 という数字にも納得がいきます。エージェント方式をCIで毎コミット回す、はまだ現実的ではありません。
冷静な注意点
追試して見えた制約も書いておきます。まず規模で、Slack の200回に対してうちは17回。統計というより観察記録です。また、題材を読み取り専用フローに限定したのは意図的で、問い合わせ送信のような副作用のあるフローを「目標達成のためなら何でもする」エージェントに渡すのは怖い、というのが実際に触った率直な感想です（今回はプロンプトで送信禁止を明示しました）。
だからこそ Slack の結論——エージェントテストは既存テストの置き換えではなく最上層への追加（探索・デバッグ・本番バグ再現向き）——は、追試した実感としても正しいと思います。決定的テストが「知っている壊れ方」を高速に検知し、エージェントが「知らない壊れ方」を探索する、という分担です。
副産物として、うちにE2Eテストが生えた
オチがひとつあります。この実験の生成テスト方式で書いた Playwright のスペックは、そのまま弊社サイトの e2e/ ディレクトリに残しました。冒頭で「E2E未整備でした」と白状しましたが、Slack の記事を追試したら、副産物としてE2Eテスト基盤が立ち上がったわけです。
// エージェントと同じ目標を決定的テストに書き起こしたもの
test("ブログ一覧から地図API記事を見つけてセクションに到達できる", async ({ page }) => {
await page.goto("/blog");
await page.getByRole("link", { name: /地図APIの請求書が怖くなったら/ }).first().click();
await expect(page).toHaveURL(/\/blog\/leaflet-openstreetmap/);
await expect(
page.getByRole("heading", { name: "それでも Google Maps を選ぶべきケース" }),
).toBeVisible();
});「経路ではなく目標を渡す」はテストに限らず、エージェントに業務を任せるときの本質だと考えています。どの業務なら目標だけ渡せるのか、どこには決定的な手順が必要なのか——その仕分けの相談も、AI・業務自動化の支援で承っています。