はじめに
ここ最近、「ブラウザ自動化ツール」という言葉を耳にする機会が増えてきました。
もしテストケースを自然言語で入力するだけでE2Eテストが実行できたら、開発や検証の負担はかなり軽くなりそうですよね。
そんな中で調べていて目に留まったのが、Browser Use と Playwright MCP の2つ。
どちらもブラウザを自動で操作できるツールですが、アプローチや得意分野は少し異なります。
そこで今回は、この2つを実際に動かしながら「どんなことができるのか」を試してみます。
自然言語駆動とコード駆動、それぞれの特徴や使い勝手を見比べつつ、ユースケースの違いを探っていきます。
セットアップ等については公式サイトやその他を調べてみてください。どちらを使うにも課金が必要になるのでご注意ください。
Browser Use:https://browser-use.com/
Playwright MCP:https://github.com/microsoft/playwright-mcp
テストに使う環境
ローカル用の商品管理システムを使用しました。
- 公開サイト:商品一覧・詳細を表示
- 管理画面:商品の作成・編集・削除(CRUD)
管理画面で登録した商品は、公開サイトにも反映されます。
管理一覧
公開
検証1:新規商品の公開まで
まずは操作デモとして、新規商品の登録をお願いしました。
Playwright MCP
プロンプト
Playwrightで管理画面(http://localhost:3000/admin/products)にアクセスして新規商品を追加してください。 商品名・価格・説明を入力し、作成したら成功メッセージが表示されたことを確認してください。 その後、公開サイトに移動し商品が追加されたのを確認してください。入力内容と表示内容が合っていればOKです。 商品の入力内容は以下です - 商品名: "検証1_Playwright" - 価格: 1000 - 商品説明: "Playwrightで作成された商品です"
結果(出力)
画面遷移のつまずきと修正を2〜3回繰り返した後、無事成功。指定した価格表記まで指摘してくれる丁寧さが印象的でした。画面パスを省略しても動作しましたが、指定すれば1回で成功できそうです。
Browser Use
プロンプト
from dotenv import load_dotenv from browser_use.llm import ChatOpenAI from browser_use import Agent import asyncio load_dotenv() llm = ChatOpenAI(model="gpt-4.1") async def main(): # 1つ目のタスク agent1 = Agent( task=( "Playwrightで管理画面(http://localhost:3000/admin/products)にアクセスして新規商品を追加してください。\n" "商品名・価格・説明を入力し、作成したら成功メッセージが表示されたことを確認してください。\n" "その後、公開サイトに移動し商品が追加されたのを確認してください。入力内容と表示内容が合っていればOKです。\n" "商品の入力内容は以下です\n" "- 商品名: \"検証1_Playwright\"\n" "- 価格: 1000\n" "- 商品説明: \"Playwrightで作成された商品です\"\n" ), llm=llm, ) result1 = await agent1.run() print(result1) asyncio.run(main())
結果(出力)
1回の実行で成功。スピードも通常操作とほぼ同等でした。
大まかな指示でも柔軟に操作してくれる印象です。(以下Log出力)
管理画面で新規商品『検証1_browser-use』を価格1000円、説明『browser-useで作成された商品です』で追加し、成功メッセージを確認しました。 その後、公開サイトでも同じ商品が正しく表 - 51 more characters', extracted_content='管理画面で新規商品『検証1_browser-use』を価格1000円、説明『browser-useで作成された商品です』で追加し、 成功メッセージを確認しました。その後、公開サイトでも同じ商品が正しく表示されていることを確認しました。全ての入力内容と表示内容が一致しています。ご依頼の作業は完了しました。
検証2:CRUD、E2Eテスト
次は単なる操作デモではなく、作成 → 公開反映 → 編集 → 公開反映 → 削除 → 非表示確認までを行うE2Eテストを実施しました。
スクリーンショット取得と確認観点の明示も行い、妥当性を検証します。
確認観点(全体)
- 公開反映の整合:公開側で名称/価格/説明が完全一致しているか(価格は¥+カンマ区切り)
- 更新の反映:更新後、表示内容が変更しているか
- 削除の反映:公開側から該当商品が消えていること
Playwright MCP
プロンプト
これをE2EテストとしてPlaywrightで実行して結果を教えてください。 1) 商品を新規作成(名称: E2E_CRUD_{時刻}、価格: 1000、説明: 自動テストで作成) 2) 公開サイトで作成した商品の名称/価格/説明が完全一致表示されているか確認 3) 商品を編集(名称に _更新、価格: 1500、説明に「更新済み」) 4) 公開サイトで更新内容が反映されているか確認 5) 商品を削除し、公開サイトで表示されないことを確認 観点は以下です。スクショも撮ってください ・公開反映の整合:公開側で名称/価格/説明が完全一致しているか(価格は¥+カンマ区切り) ・更新の反映:更新後、表示内容が変更しているか ・削除の反映:公開側から該当商品が消えていること
結果(出力)
出力は「成功」でしたが、最終ステップの削除が実行されず出力と異なる結果に。
スクリーンショットは3観点分取得されていたものの、削除後も商品が残っているケースが確認されました。
また、スクショのタイミングが「読み込み中」状態のこともあり、精度はやや不安定でした。
削除後のスクショ(削除できていない)
Browser Use
プロンプト
from dotenv import load_dotenv from browser_use.llm import ChatOpenAI from browser_use import Agent load_dotenv() import asyncio llm = ChatOpenAI(model="gpt-4.1") async def main(): agent = Agent( task=( "これをE2Eテストとして実行して結果を教えてください。\n\n" "管理画面はhttp://localhost:3000/admin/productsです。\n\n" "1) 商品を新規作成(名称: E2E_CRUD_{時刻}、価格: 1000、説明: 自動テストで作成)\n" "2) 公開サイトで作成した商品の名称/価格/説明が完全一致表示されているか確認\n" "3) 商品を編集(名称に _更新、価格: 1500、説明に「更新済み」)\n" "4) 公開サイトで更新内容が反映されているか確認\n" "5) 商品を削除し、公開サイトで表示されないことを確認\n\n" "観点は以下です。スクショも撮ってください\n" "・公開反映の整合:公開側で名称/価格/説明が完全一致しているか(価格は¥+カンマ区切り)\n" "・更新の反映:更新後、表示内容が変更しているか\n" "・削除の反映:公開側から該当商品が消えていること" ), llm=llm, ) result = await agent.run() print(result) asyncio.run(main())
結果(出力)
同様に削除ステップで失敗。ただし削除失敗した報告は有るため出力と矛盾なし。3観点分のスクリーンショットは取得済みでした。
【E2E CRUDテスト結果まとめ】商品新規作成 → 管理画面・公開サイトともに正しく反映(OK). 公開サイトで名称/価格/説明の完全一致表示 → OK(価格も¥+カンマ区切りで一致). 商品編集 → 管理画面・公開サイトともに正しく反映(OK). 公開サイトで更新内容反映 → OK. 商品削除 → 管理画面では削除操作成功だが、公開サイトで該当商品(E2E_CRUD_0216_更新)がまだ表示されておりNG 【観点ごとの判定】- 公開反映の整合:OK- 更新の反映:OK- 削除の反映:NG(バグまたは非同期反映遅延の可能性あり) 証跡としてスクリーンショットと抽出データを添付します。ご確認ください。
削除後のスクショ(削除できていない)
まとめ
今回の検証では、Browser UseとPlaywright MCPを同じE2Eテストシナリオで比較し試しました。
Browser Useは、その名の通りAIのブラウジング機能としての使い勝手がよく、大まかなプロンプトでも商品作成などのブラウザ操作を複雑な分岐や条件指定がなければ1回の指示で実行してくれます。ただし、今回のように複数工程を含むE2Eテストの正確性や再現性を求めるケースとは相性があまり良くなさそうです。
一方でPlaywright MCPは、E2Eテストに必要な「スクリプトの作成 → 実行 → 結果のブラウザ確認 → フィードバック → 修正」という一連の流れを自動で回してくれます。結果をテキスト出力しつつ、スクリーンショットで証跡も残せるため、テスト結果の確認や不具合の特定がスムーズでした。今回のようなCRUDを含む一気通貫の検証では、こちらの方が安定しており、用途に合っていると感じます。
比較表
項目 | Browser Use | Playwright MCP |
---|---|---|
特徴 | AIによる直接的なブラウジング操作 | PlaywrightベースのMCPサーバーでブラウザ操作 |
実行アプローチ | 自然言語 → 即ブラウザ操作 | 自然言語 → Playwrightスクリプト生成・実行 |
精度 | プロンプト依存度が高い。推測動作あり | プロンプト依存度が高いが試行修正あり |
向いているケース | 軽いブラウザ操作、調査、デモ | 正式なE2Eテスト、精度検証 |
また両ツールとも、プロンプトを正確に書くことが重要でした。URLや操作対象を明示しないと、Browser Useは推測で初期表示ページを開いてしまい、Playwright MCPも余計な試行を繰り返す傾向があります。必要なURL・画面パス・操作手順は明確に指定することで、成功率と実行速度が大きく変わるのでプロンプトはしっかり過不足なく書くと期待動作に近づくと思います。