AIエージェントがブラウザを操作する標準仕様「Browser MCP」——主要4サーバーの選び方と導入手順

6月27日、Skyvernが「Browser MCP Guide: Top Options June 2026」と題した記事を公開した。この記事では、AIエージェントがブラウザを操作するための標準仕様「Browser MCP」の概要と、2026年6月時点で実用に足る主要サーバー実装について詳しく紹介されている。SeleniumやPlaywrightに代表されるセレクタベースの自動化が抱える課題を整理しつつ、Browser MCPがどのような設計思想でその課題に対処するかを理解するのに役立つ内容だ。

SeleniumやPlaywrightが壊れる根本原因と、Browser MCPのアプローチ

ページのレイアウトが変わるたびに、精巧に書いたSeleniumスクリプトが動かなくなる——この問題に悩まされたエンジニアは多いはずだ。CSSクラス名が変わり、ボタンの位置がずれると、セレクタベースの自動化は即座に壊れる。

Browser MCPはこの問題へのアプローチが根本的に異なる。AIエージェントにリアルタイムのブラウザアクセスを与え、ハードコードされたセレクタの代わりに「画面上に実際に何があるか」を読み取って操作させる。これはSeleniumやPlaywrightが持つセレクタ依存の脆弱性に対する一つのアプローチであり、すべてのケースで既存ツールを置き換えるものではないが、レイアウト変更への耐性という観点では設計上の優位がある。

「MCP」はModel Context Protocolの略で、LLM（大規模言語モデル）が外部ツールを構造化された形式で呼び出すためのオープン標準だ。Browser MCPはこのプロトコルをブラウザ操作に適用したもので、互換エージェントであればURLを開く、DOMを検査する、スクリーンショットを撮る、JavaScriptを実行するといった操作を、プロジェクトごとのカスタム接着コードなしに呼び出せる。

企業AIチームの78%がMCPを採用しているとされ（※Skyvern記事内で言及された数値。調査主体・手法の詳細は元記事に記載なし）、Browser MCPはもはや実験的なツールではなく実用的な標準として位置づけられている。

アーキテクチャ：クライアント・サーバー構成

Browser MCPはクライアント・サーバー構成を採る。

MCPサーバープロセス：ローカルマシン上で動作し、Chrome DevTools Protocol経由で既存ブラウザに接続するか、ヘッドレスインスタンスをプログラム的に起動してブラウザを管理する
AIクライアント：stdio またはHTTP（SSE）経由でツール呼び出しリクエストを送信し、ページ状態・スクリーンショット・抽出データを含む構造化レスポンスを受け取る
ブラウザブリッジ：サーバーとブラウザ間の低レベル通信を担い、コマンドを転送してDOMスナップショット、コンソールログ、ネットワークアクティビティを返す

ClaudeやCursorがWebタスクを実行する際、LLMがどのブラウザツールを呼び出すかを決定し、引数を渡し、結果を解釈してから次のステップを判断する。このループがタスク完了まで繰り返される。

従来のブラウザ自動化との比較

SeleniumやPlaywright、Puppeteerはすべて、セレクタ・XPath・CSSクラスで特定のDOM要素を狙い撃ちする。サイトがレイアウトを更新するとセレクタが壊れ、スクリプトが止まる。保守にはコードベースとターゲットサイトの両方を理解したエンジニアが必要だ。

Browser MCPの利点は以下の通りだ。

スクリプト保守コストの削減：ボタンが移動したりクラス名が変わっても、エージェントがレイアウト変更に適応する
自然言語での記述：複雑な多ステップワークフローを、何十もの中間ステップからなる手続き的コードではなく、自然な指示として表現できる
非エンジニアでも構築可能：タスクを平易な言葉で記述すれば、エージェントが実行の詳細を処理する

ただしトレードオフもある。LLM推論がループに入るため、直接スクリプト実行と比べてレイテンシとコストが増加する。ページ構造が固定されている大量反復タスクでは、従来の自動化の方が速くて安い場合がある。

主要Browser MCPサーバー比較

Skyvern

DOMセレクタやハードコードスクリプトに頼らず、コンピュータビジョンとAI推論でページを人間と同じように操作する。HTMLの構造やクラス名が変わってもワークフローが壊れない。CursorやClaude Codeなど主要MCPクライアントに対応し、認証・動的サイト・多ステップタスクの本番運用向けに設計されている。レイアウト変更への耐性は4サーバー中で最も高い。

agentdeskai/browser-tools-mcp

ブラウザ拡張機能とローカルNode.jsサーバーを組み合わせてChromeをブリッジする。コンソールログ、ネットワークリクエスト、スクリーンショット、DOMスナップショットへのアクセスを提供し、開発中のデバッグや反復的な開発ワークフローに向いている。ただしDOMセレクタ依存のため、サイト更新時に壊れやすい。

Puppeteer MCPサーバー

GoogleのPuppeteerライブラリをベースにしたサーバーで、ヘッドレスChromeをプログラム的に制御する。コードファーストなセットアップに慣れているチームで、ページ構造が安定したヘッドレス自動化が必要な場合に適している。

Playwright MCPサーバー

MicrosoftのPlaywright MCPサーバーはChrome・Firefox・WebKitに対応。クロスブラウザのテスト環境でブラウザ間の一貫性を重視するQAチームに向いている。ただしセレクタベースのため、レイアウト変更には弱い。

サーバー	ブラウザ対応	レイアウト変更への耐性	主な用途
Skyvern	Chrome（コンピュータビジョン）	高	本番ワークフロー、認証、動的サイト
agentdeskai/browser-tools-mcp	Chrome（拡張機能）	低	開発・デバッグ
Puppeteer MCP	ヘッドレスChrome	低	安定したページのヘッドレス自動化
Playwright MCP	Chrome・Firefox・WebKit	低	クロスブラウザテスト

セットアップ手順：Claude CodeとCursor IDEへの導入

以下の手順は、AIエージェントからブラウザ操作を試したい開発者や、既存の自動化ワークフローにBrowser MCPを組み込みたいチームを主な対象としている。デバッグ用途であればagentdeskai/browser-tools-mcpが手軽な出発点となり、本番ワークフローへの適用を検討するならSkyvernのクラウドベース構成が現実的な選択肢になる。

Claude Codeの場合

ターミナルで claude mcp add を実行し、プロンプトに従ってサーバー名とコマンドパスを登録する
claude mcp list でアクティブなMCP接続を確認する
URLを開く・スクリーンショットを撮るよう指示してテストする

プロジェクト単位でスコープを絞りたい場合はプロジェクトルートの .mcp.json を編集し、全セッションで使いたい場合はグローバル登録を選ぶ。

Cursor IDEの場合

CursorはMCPサーバー設定を ~/.cursor/mcp.json で管理する。mcp add コマンドはなく、設定ファイルを直接編集する。

agentdeskai/browser-tools-mcpの場合（ローカル開発・デバッグ向け）：

{
  "mcpServers": {
    "browser-tools": {
      "command": "npx",
      "args": ["@agentdeskai/browser-tools-mcp"]
    }
  }
}

SkyvernのクラウドベースMCPサーバーを使う場合（本番ワークフロー・HTTPトランスポート向け）：

{
  "mcpServers": {
    "skyvern": {
      "type": "http",
      "url": "https://api.skyvern.com/mcp/",
      "headers": {
        "x-api-key": "YOUR_SKYVERN_API_KEY"
      }
    }
  }
}

ファイルを保存してCursorを再起動すると、MCPツールがエージェントパネルに表示される。接続確認は「localhost:3000のURLをスクリーンショットで撮って」のように指示するだけでよい。タイムアウトや"tool not found"エラーが出た場合は、サーバープロセスが起動しているかとコマンドパスが正しく解決されるかを確認する。

詳細はBrowser MCP Guide: Top Options June 2026を参照していただきたい。