「うちはPlanner/Generator/Healerで手一杯です」という声をよく聞く
以前PlaywrightのTest Agentsの記事を書いてから、コメントやDMで一番多く来るのが「うちはまだPlanner/Generator/Healerを回すだけで精一杯です」という声です。正直、これはとても健全な状態だと思います。テスト計画を立てるPlanner、コードを書くGenerator、壊れたテストを直すHealer。この3役をチームに定着させるだけでも、結構な業務改善だからです。
ただ、私は職業柄「その先」も追いかけてしまう性分です。今回は2026年に入って見かけるようになった、もう一段階分業を進めた構成を紹介します。結論から言うと、Webアプリを探索・機能・見た目・API・性能の5つの役割に分けて、並列で診断させるという流派です。乗り換えを煽る記事にはしたくないので、何が違って何が同じなのか、正直に整理していきます。
おさらい：Planner/Generator/Healerは「テストを書く」ための3役
Playwright公式のTest Agentsは、npx playwright init-agentsで導入できる3つのエージェントです。Plannerがアプリを探索してMarkdownのテスト計画を作り、Generatorがその計画をTypeScriptのテストコードに変換し、Healerが失敗したテストの原因を見て修正案を出します。詳しくは以前の記事を見てもらえればと思うのですが、この3役はあくまで「テストという成果物を作る・直す」ためのパイプラインです。
これに対して今回紹介する構成は、目的そのものが少し違います。テストコードを作ることが目的ではなく、Webアプリそのものを多角的に診断することが目的です。
Explorer/Functional/Visual/API/Performanceという5役
執筆時点でWebSearchで確認できた範囲だと、この構成はmcpmarket.comが公開しているClaude Code Skillの「Playwright Multi-Agent Testing」という実装で具体的に説明されていました。5つのエージェントを並列で動かし、Webアプリを深く分析するというものです。役割はおおよそ次のように分かれています（呼び方は出典により多少揺れます）。
- Explorer：アプリのページを自動で発見していきます。BFS（幅優先探索）でリンクをたどってページとインタラクティブ要素をマッピングする、という説明がありました。
- Functional：見つかったページに対して、実際に機能が動くかどうかを検証します。ここはPlanner/Generatorがやっていることに近い領域です。
- Visual：見た目とレスポンシブ対応を見ます。異なるビューポートでの崩れがないかを確認する役割です。
- API：画面の裏で飛んでいるネットワークリクエストを監視します。フロントの見た目は正常でも、裏のAPIがエラーを返しているケースを拾うイメージです。
- Performance：Core Web Vitalsを計測します。LCPやCLSといった指標を、テストのついでに一緒に取ってしまう発想です。
さらにこの構成には、axe-coreによるアクセシビリティ監査も含まれているとのことでした。UI/UXの総合的な監査ができる、という触れ込みです。正直、Functional・Visual・APIあたりは「結局中でPlaywrightを操作している」という点でPlanner/Generatorと地続きです。差分は、それを1本のパイプラインで直列にやるか、役割ごとに切り分けて並列で走らせるか、という設計思想の違いだと理解しています。
この数字と名前、どこまで信じていいのか
ここは正直に書いておきたいところです。「5エージェント・Explorer/Functional/Visual/API/Performance」という具体的な名前と数は、私が確認できた範囲ではmcpmarket.com上のこの1実装の説明が出典です。同じ話題を扱う別の記事では、エージェント数もツール名も揺れます（3つと言っているものもあれば、6つのQAパイプラインを名乗るものもありました）。つまり「これが業界標準の5エージェント構成です」と言い切れるほど、まだ枯れた話ではありません（この界隈、半年で名前が変わることもザラなので、あまり構成名そのものを覚えにいく必要はないと思っています）。
もう一つ気になったのが、Claude Codeのマルチエージェント運用そのものについての一般的なガイドです。Agent Teamsの記事でも触れましたが、複数エージェントを並走させる話は今のClaude Code界隈全体のトレンドです。ただ、その一般論を扱ったeesel.aiのガイドでは「サブエージェントは3〜4個までにしておくべき、それ以上は生産性を下げる」という指摘がありました。5エージェント構成はこの目安を超えています。テスト・診断という決まった手順を並列実行するタスクと、汎用的な開発作業を任せるタスクでは事情が違う可能性がありますが、少なくとも「エージェントは増やせば増やすほど良い」という単純な話ではなさそうです。
実際どう受け止めればいいか
ここからが本番です。1年目の読者にとって一番大事なのは、乗り換えるかどうかではなく「この方向性がある」と知っておくことだと思っています。理由は3つあります。
まず、Planner/Generator/HealerはPlaywright本体が公式にリリースしたものですが、今回紹介したExplorer/Functional/Visual/API/Performance構成は、あくまでサードパーティのClaude Code Skillの実装例です。公式ロードマップにこの5役が乗るかどうかは、執筆時点ではわかりません。両者を同列に語ると誤解を招くので、ここは分けて捉えるべきです。
次に、やっていること自体は目新しいものではありません。axe-coreでのアクセシビリティ監査も、Core Web Vitalsの計測も、ネットワーク監視も、Playwrightを直接使えばこれまでも手動で組めた処理です。新しいのは「これを役割ごとのエージェントに割り振って、並列で自動的にやらせる」という運用の型のほうです。
最後に、これは費用の話とセットで考える必要があります。以前MCP経由とCLI経由でトークン消費が約4倍違うという記事を書きましたが、エージェントを5つ並列で走らせれば、その分だけモデルの呼び出し回数も増えます。「診断が速くて楽になる」という触れ込みの裏には、それだけのコストがかかっているという前提を忘れないほうがいいと思います。
5つのレポートを誰がまとめるのか
もう一つ、正直に触れておきたい懸念があります。Explorer/Functional/Visual/API/Performanceを並列で走らせると、当然ながら5本のレポートが出てきます。ページ探索の結果、機能テストの結果、見た目の崩れ、APIエラー、Core Web Vitals。それぞれは有用な情報ですが、そのままでは「今日直すべきものはどれか」の優先順位が付きません。結局は人間が5本のレポートを読んで、どれが致命的でどれが後回しでいいかを判断する作業が残ります。ここをエージェントにやらせる仕組みまで含めて「5エージェント構成」と呼んでいるのか、単にレポートを並べるだけなのかは、出典を読んだ範囲ではっきりしませんでした（このあたりは実際に触ってみないと分からない部分です）。
もう一つ気になるのは、Healerに相当する役割がこの5役には見当たらないことです。Explorerが不具合を見つけても、それを直すのはあくまで人間、というのが今の構成のようです。見つける専門家は5人に増えたけれど、直す専門家は増えていない。ここは「診断」と銘打たれている理由と符合しますし、テスト自動化というよりは品質監査に近い立ち位置なのかもしれません。
まずは小さく試すなら
いきなり5エージェント体制を組む前に、まず自分の手元で「役割を分けて診断する」感覚だけ掴んでみるのはおすすめです。すでにPlaywright MCPを導入しているなら、同じMCPサーバーに対して「まずアクセシビリティだけ見て」「次にレスポンシブ崩れだけ見て」と役割を絞ったプロンプトを別々に投げてみましょう。1つのプロンプトに全部詰め込むより、結果の見通しが良くなることに気付くはずです。これが体感できれば、5エージェント構成が何を並列化しようとしているのかも腑に落ちると思います。
逆に、Planner/Generator/Healerすらまだ手一杯という段階なら、無理に手を広げる必要はありません。テストという土台がぐらついたまま診断エージェントを増やしても、拾った不具合を直す余力がなければ意味がないからです。
まとめ
PlaywrightのPlanner/Generator/Healerの先には、Webアプリを探索・機能・見た目・API・性能の5役に分けて並列診断するという流派が出てきています。ただし現時点では特定の実装（Claude Code Skill）で見られる構成であり、名前や数はまだ揺れている段階です。公式のTest Agentsと違って標準化されたものではない、という前提は持っておいたほうがいいと思います。とはいえ「1つのエージェントに全部やらせず、役割ごとに分けて並列でやる」という発想そのものは、テスト自動化の次の当たり前になっていきそうな気配があります。似たような構成を試した方がいたら、ぜひコメントで教えてください。
コメント