AI駆動開発のブラウザテスト｜PlaywrightとClaude Coworkの違い・使い分けを徹底解説
AIを使ってコードを書くことが当たり前になりつつある一方で、開発現場では新しい課題も出てきています。
それが、
「AIが作った画面を、誰がチェックするのか？」
という問題です。
AIに実装を任せれば、以前よりはるかに速く画面を作れるようになりました。
しかし、
- ボタンを押したら正しく遷移するか
- フォーム入力後に登録されるか
- モーダルが画面からはみ出していないか
- スマートフォン表示が崩れていないか
- 文言が不自然になっていないか
- 想定外の操作でエラーにならないか
といった確認は、依然として必要です。
そこで最近注目しているのが、
PlaywrightとClaude Coworkを組み合わせたブラウザチェック
です。
どちらもブラウザを操作できますが、得意なことはかなり違います。
結論から言えば、
Playwrightは「決められた仕様を何度でも正確に確認する」のが得意。
Claude Coworkは「実際の画面を見ながら、おかしいところを考えて探す」のが得意。
という違いがあります。
AI駆動開発では、この2つを競合させるのではなく、役割分担させることで品質確認まで高速化できると考えています。
Playwrightとは？
PlaywrightはMicrosoftが中心となって開発しているブラウザ自動化・E2Eテストツールです。
Chromium、Firefox、WebKitを1つのAPIから操作でき、
- ページを開く
- ボタンを押す
- フォームに入力する
- URLを確認する
- 表示された文字を確認する
- スクリーンショットを撮る
- ネットワーク通信を確認する
といったブラウザ操作をプログラムから自動化できます。
例えば、
await page.goto('/login');
await page.getByLabel('メールアドレス').fill('test@example.com');
await page.getByLabel('パスワード').fill('password');
await page.getByRole('button', { name: 'ログイン' }).click();
await expect(page).toHaveURL('/dashboard');
というテストを書いておけば、
「ログインしてダッシュボードへ移動できるか」
を何度でも自動確認できます。
さらにPlaywrightには、画面が表示されるまで待つAuto-waitや、条件が成立するまで繰り返し確認するWeb-first Assertionsが用意されています。
そのため、単純なブラウザ操作スクリプトよりも、Webアプリケーションの自動テストを安定して実行しやすい設計になっています。
Claude Coworkとは？
Claude Coworkは、AnthropicのClaudeにブラウザやファイル、各種ツールを操作させながら、複数ステップの作業を任せられる仕組みです。
2026年9月時点では、一部プランで従来の「Chat」と「Cowork」を統合したClaude体験への移行も進められていますが、本記事では分かりやすくClaude Coworkと呼びます。
Coworkではブラウザを使って、
- Webサイトを開く
- ページを読む
- ボタンをクリックする
- フォームへ入力する
- ページを移動する
といった操作をClaude自身が行えます。
つまり、
「この画面を一通り操作して、不自然なところがないか確認して」
という、人間のテスターに近い指示ができます。
ここがPlaywrightとの大きな違いです。
PlaywrightとClaude Coworkの違い
ざっくり比較すると次のようになります。
| 項目 | Playwright | Claude Cowork |
|---|---|---|
| 基本思想 | 自動テスト | AIエージェント |
| 操作方法 | コード・テストケース | 自然言語 |
| 同じ操作の再現性 | ◎ | ○ |
| 大量テスト | ◎ | △ |
| CI/CDとの連携 | ◎ | △ |
| 画面を見た判断 | △ | ◎ |
| 違和感の発見 | △ | ◎ |
| 初見の画面探索 | △ | ◎ |
| 想定外操作の探索 | ○ | ◎ |
| 文言チェック | △ | ◎ |
| UI/UX確認 | △ | ◎ |
| 回帰テスト | ◎ | △ |
| 非エンジニアによる利用 | △ | ◎ |
重要なのは、
「自動化できるか」という意味では両方できるものの、自動化の性質が違う
ということです。
Playwrightが得意なのは「正解が決まっているテスト」
Playwrightが特に強いのは、
期待する結果が明確なテスト
です。
例えば、
ログイン
↓
案件一覧
↓
案件を登録
↓
登録完了
↓
一覧に案件名が表示される
という仕様がある場合、
Playwrightなら、
案件を登録する
↓
一覧画面へ移動する
↓
案件名が存在する
まで機械的にチェックできます。
しかも同じテストを何度でも実行できます。
回帰テストとの相性が非常に良い
例えばAIに、
案件管理画面に検索機能を追加してください
と指示したとします。
AIは検索機能を実装してくれるでしょう。
しかし、
検索機能を追加した結果、
案件登録が壊れた
ということも起こり得ます。
そこで、
ログイン
案件登録
案件編集
案件削除
検索
権限確認
などのテストをPlaywrightとして保存しておきます。
変更するたびにすべて実行すれば、
既存機能を壊していないか
を自動確認できます。
これがAI駆動開発では非常に重要です。
Trace ViewerもAI駆動開発と相性が良い
PlaywrightにはTrace Viewerがあります。
テスト失敗時について、
- どこをクリックしたか
- DOMがどうなっていたか
- ネットワーク通信
- Console
- エラー
- 操作前後の画面
などを時系列で確認できます。
つまり、
テスト失敗
↓
Traceを見る
↓
原因を特定
↓
AIに修正させる
という開発ループを作りやすいのです。
さらにAIコーディングエージェントにTraceやエラー内容を渡せば、
テスト → 原因調査 → 修正
までかなり自動化できます。
Claude Coworkが得意なのは「正解が決まっていないチェック」
一方でClaude Coworkが面白いのは、
テストコードに書かれていない問題を探せること
です。
例えば、
http://localhost:3000
を開いて、案件管理システムとして一通り操作してください。
操作中に、
・表示崩れ
・分かりづらいUI
・不自然な日本語
・押せそうなのに押せないUI
・入力時の不自然な挙動
・エラー
・モーダルの問題
などを見つけて報告してください。
と指示できます。
するとClaudeがページを移動しながら確認できます。
Anthropic自身もClaude in Chromeについて、Webページの読み取り・クリック・移動だけでなく、Consoleエラー、Network、DOM状態を使ったデバッグや、実装結果のデザイン確認などを用途として案内しています。
Playwrightでは見つけにくい問題
例えばこんな画面があったとします。
案件登録
会社：
[ ]
担当者：
[ ]
受注確率：
[ ]
[保存]
Playwrightでは、
入力できた
保存できた
DBに登録された
というテストはできます。
しかし、
「受注確率って0〜100なのか、A/B/Cなのか分からない」
というUX上の問題は、通常のE2Eテストでは検出しにくいでしょう。
Claudeなら、
受注確率の入力形式がユーザーから分かりにくい。
「0〜100%」などの補足を表示した方が良い
という指摘ができます。
これが、
テストとレビューの違い
です。
Claude Coworkは「AIの探索テスト」と考えると分かりやすい
ソフトウェアテストには、
探索的テスト（Exploratory Testing）
という考え方があります。
決められたテストケースだけではなく、
人間が実際にシステムを操作しながら、
ここを押したらどうなる？
この順番で操作したら？
変な文字を入れたら？
戻るボタンを押したら？
スマホだったら？
と試していきます。
Claude Coworkは、この役割と非常に相性が良いと考えています。
PlaywrightにもAIエージェント向け機能がある
ここで少し面白いのが、
Playwright自身もAIエージェント対応をかなり進めている
ということです。
現在Playwrightには、
- Playwright Test
- Playwright CLI
- Playwright MCP
があります。
特にPlaywright MCPでは、AIエージェントがAccessibility Snapshotを読み取り、
textbox
button
heading
checkbox
といったページ構造を理解してブラウザを操作できます。
つまり、
Claude
↓
Playwright MCP
↓
Browser
という構成も可能です。
「Playwright vs Claude」ではなくなっている
ここが2026年のAI開発で特に面白いところです。
従来なら、
Playwright
VS
AIブラウザ操作
という比較でした。
現在は、
Claude
↓
Playwright
↓
Browser
という組み合わせも成立します。
Playwright公式も、Playwright CLIについてClaude Codeなどのコーディングエージェント向けのブラウザ自動化手段として案内しています。
そのため今後は、
AIエージェントがPlaywrightを使う
という構成が増えていく可能性があります。
AI駆動開発なら「3段階」に分けると使いやすい
弊社でAI駆動開発へ取り入れるなら、ブラウザチェックを3段階に分ける考え方が分かりやすいと思っています。
STEP1：Claudeで探索する
開発途中ではClaude Coworkなどを使います。
このシステムをユーザーとして操作してください。
新規登録
↓
編集
↓
検索
↓
削除
まで実施し、不自然なところを探してください。
Claudeに自由に触らせます。
ここでは、
問題を発見すること
が目的です。
STEP2：見つかった問題をPlaywrightにする
例えばClaudeが、
登録ボタンを2回押すと二重登録できる
という問題を発見したとします。
修正するだけではありません。
Playwrightに、
登録ボタンを連続クリックしても
案件が1件しか作成されない
というテストを追加します。
すると、
一度見つかったバグが再発することを防げます。
STEP3：Playwrightで継続監視する
最終的には、
ログイン
案件登録
案件編集
案件削除
権限
検索
帳票
主要画面遷移
などをPlaywrightで固定します。
そして、
Git Push
↓
CI
↓
Playwright
↓
PASS
↓
Deploy
という流れにします。
これにより人間が毎回同じ操作を確認する必要がなくなります。
つまり「Claudeで発見し、Playwrightで固定する」
個人的に分かりやすい整理はこれです。
Claudeでバグを発見し、Playwrightで再発を防ぐ。
Claudeだけだと、
毎回同じ確認をしてくれるとは限りません。
逆にPlaywrightだけだと、
テストケースに書かれていない問題は基本的に見つかりません。
そこで、
Claude
探索・レビュー
↓
問題発見
↓
修正
↓
Playwright
テストケース化
↓
CIで永久に確認
という流れにします。
かなり相性の良い組み合わせです。
例えば57画面ある業務システムなら
業務システムを例に考えてみます。
仮に、
57画面
162パターン
291操作
程度の確認項目があったとします。
これを毎回人間が確認すると、大きな負担になります。
そこで、
Playwright
291操作のうち、
仕様として固定できるものを自動テスト
します。
例えば、
ログイン
CRUD
画面遷移
入力チェック
権限
検索
API結果
などです。
一方Claudeには、
主要57画面を順番に確認してください。
・レイアウト崩れ
・文言
・操作性
・違和感
・レスポンシブ
・予期しないエラー
を確認してください。
と依頼します。
すると、
Playwright
＝機能検査
Claude
＝AIレビュー
という役割分担ができます。
画面の見た目チェックはClaudeの方が向いている
Playwrightにもスクリーンショット比較があります。
そのため、
以前の画像
VS
現在の画像
を比較するVisual Regression Testはできます。
これは非常に便利です。
ただし、
5pxずれた
ことは検出できても、
このボタンはユーザーから見ると
「保存」なのか「確定」なのか分かりづらい
という判断は別問題です。
ClaudeのようなLLM・エージェントを組み合わせる意味はここにあります。
レスポンシブチェックにも使える
例えばClaudeへ、
PC
1440px
タブレット
768px
スマートフォン
390px
で主要画面を確認してください。
と指示します。
そして、
・横スクロール
・文字切れ
・ボタン重複
・モーダルはみ出し
・タップしづらいUI
を確認してください。
と追加します。
こうしたチェックも、AIレビューと相性の良い領域です。
ではClaudeだけで全部やればよいのか？
ここは注意が必要です。
Claude CoworkのようなAIエージェントは、
判断能力がある代わりに、決定論的ではありません。
同じ依頼でも、
今回チェックした画面
次回チェックした画面
が完全に一致するとは限りません。
一方Playwrightなら、
test A
test B
test C
として定義しておけば、毎回同じ条件を確認できます。
したがって、
品質保証の土台はPlaywright
にした方が扱いやすいでしょう。
Claude Coworkにもセキュリティ上の注意がある
ブラウザを操作できるAIエージェントでは、従来の自動テストとは異なる注意点もあります。
代表的なのが、
Prompt Injection
です。
Webページの中にAI向けの悪意ある指示が含まれていた場合、ブラウザを操作するAIが影響を受ける可能性があります。
AnthropicもClaudeのブラウザ機能について、Prompt Injectionのリスクを明示しています。
そのため、
- 金融情報
- 医療情報
- 個人情報
- 顧客の機密情報
- 本番環境での削除・変更操作
などを扱う場合には特に注意が必要です。
開発用途では、
本番環境ではなくステージング環境でAIエージェントを動かす
といった運用が現実的です。
AI駆動開発の開発フローはどう変わるのか
従来の開発では、
要件定義
↓
設計
↓
開発
↓
テスト
↓
修正
↓
テスト
と進めていました。
AI駆動開発では、より短いループになります。
AIが実装
↓
Playwright実行
↓
Claudeが画面確認
↓
問題発見
↓
AIが修正
↓
Playwright再実行
↓
Claude再確認
つまり、
AIが作り、AIが操作し、AIがレビューし、自動テストが品質を保証する
という開発スタイルです。
人間はすべてのクリックを確認するのではなく、
何を正しい状態とするのか
を定義する側へ移っていきます。
PlaywrightとClaude Coworkのおすすめの使い分け
実務では次のように分けると分かりやすいでしょう。
Playwrightに任せるもの
- ログイン
- CRUD
- 画面遷移
- フォーム入力
- バリデーション
- 権限チェック
- API連携
- データ整合性
- 回帰テスト
- CI/CD
- クロスブラウザ確認
Claude Coworkに任せるもの
- UIレビュー
- UXレビュー
- 表示崩れ
- 不自然な文章
- 操作の分かりづらさ
- 想定外操作
- 探索的テスト
- 新機能の初回チェック
- 人間目線での違和感探し
そして、
両方にやらせるもの
- 主要業務フロー
- フォーム
- エラー処理
- レスポンシブ
- 新機能
- 過去にバグが発生した機能
です。
AI駆動開発では「テストコードの量」が資産になる
AIによって開発速度が上がるほど、
実は重要になるのがテストです。
AIなら大量のコードを短時間で変更できます。
つまり、
変更できる量が増えるほど、壊せる量も増える
ということでもあります。
そこで、
AIによる開発速度
+
Playwrightによる回帰テスト
+
Claudeによる探索的レビュー
という組み合わせが重要になります。
そしてプロジェクトが進むほど、
10テスト
↓
50テスト
↓
200テスト
↓
500テスト
とテスト資産が蓄積されていきます。
最終的には、
AIが大量に変更しても、既存機能を自動確認できる開発環境
になっていきます。
まとめ：PlaywrightとClaude Coworkは競合ではなく補完関係
PlaywrightとClaude Coworkは、どちらもブラウザを操作できます。
しかし役割は異なります。
Playwrightは、
決められたことを、速く、正確に、何度でも確認するツール
です。
Claude Coworkは、
実際に画面を触りながら、何がおかしいかを考えるAI
です。
したがってAI駆動開発では、
Claudeで探索
↓
問題発見
↓
AIで修正
↓
Playwrightへテスト追加
↓
CIで自動チェック
というサイクルが非常に相性の良い方法だと考えています。
これからの開発では、
「AIにコードを書かせる」だけではなく、「AIにテストさせる」「AIにレビューさせる」ところまで含めてAI駆動開発
になっていくのではないでしょうか。
開発スピードを上げながら品質も維持するためには、AIと従来の自動テスト、それぞれの得意分野を理解して組み合わせることが重要です。
