Playwright MCPの使い方：設定・ブラウザテストの実践と限界

MicrosoftのPlaywright MCPサーバーは、Claude Code、Codex、Cursor、VS CodeのCopilotエージェントなどを、ブラウザ自動化フレームワークのPlaywrightにつなぎます。私がおすすめする使い方は、探索的な動作確認や不具合の調査に活用し、そこで見つかった重要な確認項目を、レビュー済みの繰り返し実行できるテストに落とし込むことです。

Playwright MCPで何ができるのか

エージェントには、ブラウザを操作するツールと、ページを構造化した情報が渡されます。MCPはModel Context Protocolの略で、エージェントがこれらのツールを呼び出すための接続を担います。ブラウザ上の操作を実行するのはサーバーで、次にどの操作を依頼するかを決めるのはエージェントです。

アクセシビリティスナップショットは、建物の案内図のようなものです。案内図が部屋や出入口を用途と名前で示すように、ページのスナップショットはボタン、リンク、テキスト入力欄と、それぞれのアクセシブルネームを表します。エージェントは画像を見てクリック位置を推測する代わりに、この構造から操作対象を選べます。標準のワークフローでは、画像を認識するビジョンモデルは必要ありません。Microsoftによる概要

インストール前に、方式を選んでおきましょう。Microsoftは現在、コーディングエージェントの利用者に向けて、スキルを組み合わせたPlaywright CLIも案内しています。一方、MCPはブラウザの状態を維持しながら、ページ構造を繰り返し確認する用途に適していると説明しています。継続的にブラウザとやり取りする作業ならMCPを選び、エージェントがシェルコマンドでの作業を得意としているならCLI方式も比較してください。どちらを選んでも、それだけで顧客の操作フローがテストに合格したことにはなりません。MicrosoftによるMCPとCLIの比較

周辺ツールも含めて検討する場合は、2026年のおすすめMCPサーバーも参考にしてください。

Claude Code・Codex・Cursor・VS Codeへの導入方法

必要なのは、Node.js 18以降とMCPに対応したクライアントです。以下のコマンドと設定は、MicrosoftのREADMEにある例をそのまま掲載しています。利用しているクライアントの手順を選んでください。すべてのエディターで順番に実行する手順ではありません。必要条件とセットアップ

Claude Code

次のコマンドをそのまま実行します。

claude mcp add playwright npx @playwright/mcp@latest

Codex

次のコマンドをそのまま実行します。

codex mcp add playwright npx "@playwright/mcp@latest"

または、~/.codex/config.tomlに以下を追加します。

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

READMEにある手動設定の手順に沿って、Cursor Settings → MCP → Add new MCP Serverを開きます。名前を決め、種類にcommandを選んで、次のコマンドを入力します。

npx @playwright/mcp@latest

設定の確認や引数の追加にはEditを使います。READMEには、Cursorにインストールするボタンも用意されています。

VS Code

VS Code CLIで、次のコマンドをそのまま実行します。

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

これでVS CodeのGitHub Copilotエージェントからサーバーを利用できます。MicrosoftのREADMEには、インストールボタンやVS CodeのMCP設定ガイドへのリンクもあります。

共通のJSON設定

READMEの標準JSON設定を使うクライアントでは、次の例をそのまま利用できます。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

設定の保存場所は、上記の各クライアントの手順に従ってください。Codexの設定ファイルに直接追加する場合は、このJSONではなくTOMLを使います。組み合わせるエージェントを選ぶ際は、ブラウザテストに対応したAIコーディングエージェントも参考になります。

ブラウザと、エージェントがページを把握する方法を選ぶ

最初はブラウザウィンドウを表示し、分離されたプロファイルとスナップショットを使いましょう。オプションは、サーバーの引数リストで@playwright/mcp@latestの後ろに追加します。以下はMicrosoftの設定リファレンスに記載されているオプションです。

スナップショットとビジョンの違いは、操作対象の捉え方にあります。 標準のフローでは、browser_snapshotで対象を特定します。browser_take_screenshotは見た目の証拠を残すためのツールで、スクリーンショットを撮っただけでは座標クリックは有効になりません。--caps=visionで使えるツールとして、READMEにはbrowser_mouse_click_xy、browser_mouse_down、browser_mouse_drag_xy、browser_mouse_move_xy、browser_mouse_up、browser_mouse_wheelが挙げられています。画像をもとに判断するには、クライアントとモデルが、返された画像を利用できる必要があります。ツールリファレンス

通常のフォームやページ移動では、私はまずスナップショットを使います。見た目が重要な場合や、ページ構造だけでは操作対象を十分に把握できない場合は、画像を確認します。アクセシビリティスナップショットは構造を確認するうえで有用ですが、見た目が正しいことまでは証明できません。

ブラウザの動作確認で押さえておきたいツール

基本のツール群で、ページ移動、操作、証拠の収集を行えます。以下の表では、READMEにある基本の自動化ツールとタブ操作ツールを、エージェントに任せる作業別にまとめています。Microsoftのツール一覧

スナップショットに基づく操作では、ページのスナップショットにある対象への参照、または一意のセレクターを使います。セレクターとは、ページ上の要素を特定するための指定方法です。ページに大きな変化があったら、以前の参照がまだ有効だと思い込まず、スナップショットを取り直してください。

追加機能は、明示的に有効にして使います。オプション表にはvision、pdf、devtoolsがあり、ツールの説明ではさらにconfig、network、storage、testingも明記されています。

• PDF： --caps=pdfでbrowser_pdf_saveを追加します。
• デバッグ用の証拠： --caps=devtoolsには、トレース、動画、操作記録、注釈、ハイライト、一時停止した実行の再開が含まれます。たとえば、browser_start_tracingでトレースを開始し、browser_stop_tracingで終了します。
• アサーション： --caps=testingでbrowser_generate_locator、browser_verify_element_visible、browser_verify_list_visible、browser_verify_text_visible、browser_verify_valueを追加します。アサーションは、満たすべき条件を明示するものです。
• ネットワークのシミュレーション： --caps=networkでbrowser_network_state_set、browser_route、browser_route_list、browser_unrouteを追加し、オフライン時の動作やモックしたリクエストを扱います。
• ストレージ： --caps=storageでCookie、ローカルストレージ、セッションストレージの確認と編集を可能にし、browser_storage_stateとbrowser_set_storage_stateも追加します。
• 適用済み設定の確認： --caps=configでbrowser_get_configを追加します。

これはREADMEに記載された分類であり、どのクライアントでも直ちにすべてのツールを使えるという保証ではありません。必要なツールが見当たらない場合は、インストール済みパッケージのツール一覧と有効な機能を、READMEと照らし合わせてください。各ツールの詳しい説明

事業に直結する3つの活用場面

優先したいのは、不具合によって売上が失われたり、顧客からの連絡が届かなくなったりするフローです。以下は活用方法の提案であり、削減効果を実測したという主張ではありません。

購入手続きを途中で止めない

ECサイトの開発者なら、ステージング環境でゲスト購入の流れをたどらせ、選んだ商品がカートに残っているかを確認し、架空の配送先情報を入力して、実際の支払いの前で止めるようエージェントに依頼できます。顧客が遭遇する前に、購入を妨げる不具合を見つけられることが価値になります。

同じチームにとって、もう一つ有用なのが入力エラーから復帰できるかの確認です。不完全な配送先情報を送信し、エラーの内容が分かりやすいかを確認してから入力を修正し、先に進めるかを検証します。正常系だけでは、入力を間違えた顧客が直面する問題を見落とします。

デプロイ後のサイトを確認する

ランディングページの変更を公開する事業者なら、デプロイ先を開き、主要なCTAをたどって、想定した登録ページや問い合わせページに到達するかをエージェントに確認させられます。ページの証拠に加え、関連するコンソール出力や失敗したリクエストの情報も求めましょう。

制作会社の開発者なら、続けて狭いビューポートでも確認し、同じページ移動を繰り返せます。メニューが隠れていたり、ボタンにアクセスできなかったりする問題が見つかるかもしれません。スクリーンショットは人が確認するための資料として扱い、それだけで見た目の品質が保証されたとは考えないでください。

テストデータでフォームを動かす

SaaSの開発者なら、ローカル環境やステージング環境で、ログイン不要の登録フォームの必須項目、バリデーションメッセージ、修正後の動作を確認できます。実際のアカウント作成の前で止めるか、送信を受け付けるためのテスト専用の宛先を使います。

業務システムの開発者なら、ステージング環境の長いフォームに架空のデータを入力し、ドロップダウン、条件によって表示が変わる項目、テストファイルのアップロードを確認してから、モックのエンドポイントに送信できます。顧客データを送ったり、本番の業務フローを動かしたりせずに、フィールドの対応付けの誤りを見つけるのに役立ちます。

E2Eテストの実践例：ゲスト購入が支払い画面に進まない

エージェントには範囲を限定した作業を渡し、結論を裏付ける証拠を求めます。以下は、不具合をあらかじめ仮定した一連の流れを示す説明用の例です。実在する店舗をテストした報告ではありません。

例として使うアプリには、ゲスト用のカート、配送先フォーム、支払いページがあります。配送先フォームが郵便番号のフィールドを誤ってpostalとして送信する一方、バックエンドはpostalCodeを想定している、という設定です。ログイン不要で、架空のデータを使い、実際の決済には接続しないローカル環境またはステージング環境のテスト用アプリを用意します。

角括弧内のURLを自分のテスト環境に置き換え、次の指示をエージェントに渡します。

セッションを分離するには、サーバー設定に--isolatedを指定します。プロンプトに書くだけでは、サーバーの設定は変わりません。

この例では、リクエストボディにpostalが含まれ、レスポンスがpostalCodeの欠落を示しています。これはフィールドの対応付けに誤りがあるという仮説を裏付けます。ただし、開発者は根本原因を修正できたと判断する前に、フォームのシリアライズ処理とバックエンドが求める仕様を確認する必要があります。

エージェントによる報告例：

次に行うのは、対応付けを修正し、不正な入力と正しい入力の両方の経路を再実行することです。動作を確認できたら、エージェントにPlaywrightの回帰テストの下書きを作らせ、アサーションをレビューして、既存のテストランナーに追加します。この最後の工程は、開発チームのワークフローとして行う作業です。MCPでのやり取りだけで回帰テストスイートができるわけではありません。

うまく確認できない場面と、ブラウザエージェントのアクセス範囲

確認の精度が落ちやすいのは、目的が曖昧な場合や、実行環境の安全性を確保していない場合です。「購入手続きをチェックして」では、合格条件をエージェントに決めさせることになります。「正しい配送先情報で支払いページに進めることを確認し、決済は送信しないで」と指定すれば、結果をレビューできます。

実際に使う際は、次の限界を見込んでおきましょう。

• 曖昧なページ構造： 名前のない操作要素や、canvasを多用する画面では、構造情報を案内図として使いにくくなります。自分たちが管理するアプリならアクセシブルなラベルを修正し、構造情報だけでは足りない箇所は画像で確認することをおすすめします。
• 状態の変化： 再描画、ポップアップ、遅れて起こるページ遷移によって、エージェントが次の操作の前提にしていた状態が変わることがあります。操作後の状態を確認し、目的のテキストの表示や遷移を待ってから先に進めます。
• プロファイルの競合： 永続プロファイルを同時に使えるブラウザインスタンスは一つだけです。Microsoftは、ワークスペースを共有する複数のクライアントを同時に動かす場合、分離されたセッションを使うか、それぞれに異なる--user-data-dirを指定することを推奨しています。
• 環境による違い： READMEのDocker実装が対応するのは、ヘッドレスのChromiumのみです。一般的なCLIの表にあるブラウザが、すべてそのコンテナで動くとは考えないでください。
• 網羅性の不足： あるページに到達できても、すべての入力検証、ブラウザ、デバイス、バックエンドの処理結果が正しく動くとは限りません。スクリーンショットだけでは、注文が正しく保存されたことも証明できません。これらは、ここで提案する確認手順の限界です。

プロファイルとDockerの制約は、MicrosoftのREADMEに記載されています。

ブラウザへのアクセスは、実際のアクセス権限として扱ってください。 Microsoftは、Playwright MCPがセキュリティ境界ではないと明記しています。標準のプロファイルはブラウザの状態を保持し、任意で導入できるChrome/Edge拡張機能は、既存のタブやログイン済みのセッションに接続できます。この記事で扱う作業では、Cookieを持ち込まず、普段使うブラウザにも接続しない、分離されたセッションを使います。プロファイルと拡張機能の動作

エージェントは、ブラウザの実行環境から到達できるページにリクエストを送れます。ネットワークの構成によっては、公開サイトだけでなく、開発サーバーや内部サービスも対象になります。オリジンのルールはネットワーク分離の代わりにはなりません。--allowed-originsと--blocked-originsはリダイレクトを制限せず、セキュリティ境界ではないことも明記されています。--allowed-hostsは、MCPサーバーが受信するリクエストのホストを確認するための設定であり、ブラウザがアクセスできるWebサイトのリストではありません。設定とセキュリティ

ファイルへのアクセスにも同じ注意が必要です。ドキュメントによると、標準ではファイルへのアクセスをワークスペースのルート内に制限し、file://への移動をブロックしますが、--allow-unrestricted-file-accessを指定すると、この制限が緩和されます。Microsoftは、ファイルのチェックを補助的な保護策と位置付けており、安全な隔離を保証するものとはしていません。さらに注意すべきなのがbrowser_run_code_unsafeです。このツールはサーバープロセス内でJavaScriptを実行し、そのプロセスがアクセスできる範囲に作用します。クライアント側の権限でツールの利用を管理し、サーバーの実行環境にも制限を設けてください。設定スキーマとツール

スクリーンショット、ページ内のテキスト、コンソール出力、リクエストボディを通じて、エージェントにデータが渡る可能性があります。架空のレコードとテスト専用のエンドポイントを使ってください。実際の課金、メッセージ送信、アカウント作成など、実際の影響を伴う送信は、その操作自体が明示的に許可されている場合を除き、実行前に止めます。

Playwright MCP・Chrome DevTools MCP・Browserbaseはどう選ぶ？

任せたい作業と、ブラウザをどこで動かすかに合わせて選びます。機能が重なる部分はありますが、それぞれが担う役割は同じではありません。

Microsoftも、ブラウザのエンドポイントに接続するための--cdp-endpointを用意しています。つまり、エージェントが使うインターフェースと、ブラウザを動かす場所は別々に選べます。BrowserbaseはMicrosoftのサーバーの別名ではありません。より広い選択肢については、AIエージェント向けのおすすめブラウザで扱っています。

費用の考え方と、事業化を検討したい2つの案

費用を比較するなら、現在の確認作業と、自動化後のワークフロー全体を比べる必要があります。Playwright MCPのリポジトリはApacheライセンスで公開されていますが、インストールすればエージェントのモデル、計算リソース、テスト環境、人によるレビューまでそろうわけではありません。

自分たちの実際の数字で計算してください。

• 導入前： 手作業での確認時間 × 間接費を含む時間当たりの人件費 ＋ 既存のテスト関連サブスクリプション料金。
• 導入後： エージェントの利用料 ＋ ブラウザのインフラ費用 ＋ 人によるレビュー ＋ テスト環境とテストの保守費用。

ホスティング費用の具体例として、Browserbaseでは、Developerプランを月額$20、ブラウザ稼働100時間込みで提供し、超過分のブラウザ稼働には時間当たり$0.12がかかると案内しています。これはブラウザのインフラ費用であり、エージェントによる購入フローのテスト全体の料金ではありません。Browserbaseの料金

最も有望な案：リリース時の受け入れ確認サービス

小規模な制作会社なら、顧客がデプロイするたびに、合意した顧客の操作フローを確認するサービスを提供できます。最小限でも役立つ形にするなら、ステージング環境のURLと受け入れ条件のチェックリストを受け取り、許可されたログイン不要の経路を実行し、証拠と未確認の範囲を明記した、レビュー済みの報告を渡します。顧客が対価を払うのは、リリース時の確認を責任を持って担ってもらえることです。

需要を示すデータは限定的です。2026年10月に取得したDataForSEOの米国・英語のキーワード推定値では、「automated browser testing」は月間110件、「checkout testing」は月間10件でした。これは検索の回数であり、購入者の数ではありません。幅広いソフトウェア製品に投資する前に、既存顧客を対象に、用途を絞ったサービスを試す根拠にはなります。

課題は保守です。操作フローの変更、曖昧なアサーション、誤検知への対応が、削減するはずだった工数を使い切る可能性があります。競争力になるのは、実用的な受け入れ条件のチェックリストと、信頼できる問題の切り分けです。誰でも導入できる公開MCPサーバーをインストールすること自体ではありません。

もう一つの案：ステージング環境のフォームチェッカー

Web制作会社なら、フォームに架空の値を入力し、必須項目のエラーを発生させ、修正後の送信がモックの送信先に届くかを確かめるチェッカーを作れます。まずは、すでに保守しているサイトのフォームを対象にし、開発者が再現できる報告を用意しましょう。

DataForSEOの同じ米国・英語のデータでは、「website form testing」は月間10件と推定されています。これだけで独立したサービスの集客を見込むには弱い数字です。私は、まずWebサイト保守の追加サービスとして販売し、継続的な需要を確認してから、単独の製品にするか判断するのがよいと考えています。

難しいのは、送信を受け取る側の仕組みです。画面上で成功したように見えても、見込み客の情報が宛先に届いた証明にはなりません。MVPには、ブラウザ上の証拠に加え、テスト用エンドポイントなど、許可された方法で受信を確認できる仕組みが必要です。

導入時によくある質問

次の月曜日に取り組むこと： 売上に最も近いゲスト向けの操作フローを選び、期待する結果と停止位置を書き出して、普段使っているコーディングエージェントにステージング環境で確認させましょう。対象範囲を広げる前に、そのフローを担当する開発者と証拠をレビューしてください。

リリース工程に合わせたブラウザの確認フローを構築したい場合は、業務フロー向けAIエージェントの開発をご相談ください。