AIブラウザ制御で主流となっているprotocolは2つあります。CDP（Chrome DevTools Protocol）とMCP（Model Context Protocol）です。異なるレイヤーで異なる問題を解決しますが、browserエージェントを構築する開発者はしばしば両者を混同したり、ユースケースに合わないほうを選んでしまいます。本ガイドでは、各protocolの役割、使い分け、そして本番agentスタックでの併用方法を解説します。
要約： CDPはWebSocket接続を通じてbrowserを直接低レベルで制御します。MCPは標準化されたtool-useインターフェースを通じてLLMに高レベルのbrowser toolsを提供します。CDPはエンジン、MCPはハンドルです。多くの本番AIエージェントには両方が必要です。MCPでLLMがactionを判断し、CDPが実際のbrowser操作を担います。Clawbrowserは両方をネイティブでサポートしています。
補足： 本記事の「CDP」はChrome DevTools Protocol（ブラウザ制御の標準）を指します。
CDPとMCPの正体
CDP：Chrome DevTools Protocol
CDPはWebSocketベースのprotocolで、Chromium browserをプログラムで制御します。GoogleがChrome DevTools（F12で開くinspector）用に開発しましたが、browser自動化の標準となりました。Playwright、Puppeteer、主要な自動化ライブラリはすべて内部でCDPを使っています。
Playwrightでpage.goto()を呼ぶと、WebSocketを通じてCDPコマンドがbrowserへ送信されます。CDPはページ遷移、JavaScript実行、network requestのintercept、cookieの操作、screenshotの取得など、きめ細かい制御を提供します。
# CDP: your code controls the browser directly
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp("http://127.0.0.1:9222")CDPの詳しい解説はAIエージェント向けCDPブラウザ開発者ガイドをご覧ください。
MCP：Model Context Protocol
MCPはLLMと外部ツールの接続方法を標準化するprotocolです。各ツールごとにカスタムのfunction-call定義を書く代わりに、LLMがMCPサーバーを通じて利用可能なツールを発見し、標準インターフェースで呼び出します。
browser制御の場合、MCPサーバーはnavigate、click、type、screenshot、extractなどのactionをLLMが呼び出せるツールとして公開します。LLMがタスクに応じてどのツールを呼ぶか判断します。Playwrightのコードも、CSSセレクタも、agentでのカスタムツール定義も不要です。
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]この設定をClaude Code、Cursor、Gemini CLIなどMCP対応agentに追加すれば、LLMはすぐにbrowser toolsを使えます。
なぜ混同されるのか
どちらのprotocolもAIエージェントをbrowserに接続します。どちらにも「protocol」という語が含まれます。AIエージェント基盤の議論で同時に登場します。しかし動作するレイヤーが異なります。
- CDPはbrowserレベルのprotocolです。Chromiumと通信します。
- MCPはアプリケーションレベルのprotocolです。LLMと通信します。
MCP browserサーバーは内部でCDPを使ってbrowserを制御します。両者は代替手段ではなく、同じスタックのレイヤーです。
並列比較
| CDP (Chrome DevTools Protocol) | MCP (Model Context Protocol) | |
|---|---|---|
| 開発元 | Google（Chromeチーム） | Anthropic |
| Protocolの種類 | ブラウザ制御（WebSocket） | ツール利用（stdio/SSE） |
| 呼び出し元 | コード（Playwright、Puppeteer、raw WebSocket） | LLM（Claude、GPT、Gemini） |
| 制御レベル | 低レベル：DOM、network、JavaScript実行、cookies | 高レベル：navigate、click、type、screenshot、extract |
| セットアップ | browserのdebugging portに接続 | agentにMCPサーバーを設定 |
| 柔軟性 | 完全：browserでできることすべて | サーバーが公開するツールに限定 |
| アクション速度 | ミリ秒（inference不要） | 0.5〜3秒（LLMが毎ステップ判断） |
| エラー処理 | コードでエラーを処理 | LLMがエラーを推論 |
| Anti-detection | 非搭載（browserに依存） | 非搭載（browserに依存） |
| 最適な用途 | スクリプト自動化、fine-grained制御、framework開発 | LLM駆動ブラウジング、オープンエンドなタスク、ラピッドプロトタイピング |
どちらのprotocolもanti-detectionは提供しません。これはprotocolの問題ではなく、browserレベルの問題です。標準のChrome instanceはCDP経由でもMCPサーバー経由でも同じ自動化シグナルを漏洩します。anti-detectionにはClawbrowserのようなengineレベルのソリューションが必要です。20以上のsurfaceにわたるmanaged fingerprints、組み込みproxy routing、Chromiumソースレベルでの CDP signal抑制を備えています。
CDPを使うべきとき
browserを精密かつプログラムで制御する必要があり、実行手順が事前に分かっている場合はCDPを使います。
CDPが適しているシナリオ：
- 構造化されたスクレイピング。 対象のセレクタ、抽出するデータ、ページネーションの処理方法が分かっている。コードは毎回同じ手順を実行する。
- Networkのintercept。 リソースのブロック、requestヘッダーの変更、API responseのキャプチャ、ページロード前のJavaScript注入が必要。
- 複雑なwait条件。 特定のDOM要素、network idle状態、JavaScript変数の変化を待つ必要がある。
- パフォーマンス重視の自動化。 CDPコマンドはミリ秒で実行されます。アクションごとのLLM inference遅延がありません。CDP経由で数秒で終わる50ステップのスクレイピングジョブが、LLM推論を挟むと数分かかります。
- Framework開発。 agentフレームワーク、テストハーネス、他の人が使う自動化ライブラリを構築している。
# CDP: full control, full responsibility
await page.wait_for_selector("#login-form")
await page.fill("#email", "[email protected]")
await page.fill("#password", credentials)
await page.click("#submit")トレードオフ： browserのglueコードをすべて自分で書いてメンテナンスする必要があります。セレクタ、wait条件、エラーハンドラのすべてです。対象ページの構造が変わればコードも壊れます。
MCPを使うべきとき
ページの表示内容に基づいてLLMが次のアクションを判断すべき場合はMCPを使います。
MCPが適しているシナリオ：
- オープンエンドなブラウジング。 「料金ページを見つけてプラン詳細を取得して」。agentはハードコードされたセレクタなしにページを読み、クリック先を判断する。
- 判断を伴うマルチステップワークフロー。 「ログインし、新しい請求書があるか確認し、金額が500ドル以上ならダウンロード」。LLMが各ステップでページ内容を読んで条件分岐を処理する。
- ラピッドプロトタイピング。 Playwrightコードを書かずに5分でbrowserエージェントを動かしたい。MCP設定を追加し、タスクを記述するだけ。
- 非開発者ユーザー。 agentの操作者が自然言語でタスクを記述する。コードは不要。
- Agent-nativeな環境。 Claude Code、Cursor、Gemini CLIはすでにMCPに対応しており、browserの追加は設定1つで完了する。
# MCP: the LLM decides what to do
User prompt: "Go to example.com and tell me the page title"
LLM calls: navigate(url="https://example.com")
LLM calls: screenshot()トレードオフ： 精度が下がります。LLMが誤った要素をクリックしたり、余分なステップを踏んだり、ページ内容を読み違える可能性があります。各アクションにLLM inference遅延が発生します。標準のMCP browser toolsではnetwork requestのinterceptやJavaScriptの注入はできません。
両方を併用すべきとき
多くの本番AIエージェントが最終的にたどり着くのがこの構成です。MCPがLLM-to-agentインターフェースを担い、CDPがagent-to-browserインターフェースを担います。MCPサーバーが両者の間に立ち、高レベルのtool callsを低レベルのbrowserコマンドに変換します。
LLM ← MCP → MCP Server ← CDP → Browser
(clawctl) (Clawbrowser)LLMがMCPのtool callsを送り（「このURLに遷移」「ログインボタンをクリック」）、MCPサーバーがそれをCDPコマンドに変換してbrowserへ送信します。結果はチェーンを逆流して返されます。
browserレイヤーが重要な理由
多くのMCP browserサーバーは標準のChrome instanceにCDP経由で接続します。そのbrowserにはfingerprint管理、proxy routing、anti-detectionがありません。agentはデモサイトでは動きますが、Cloudflare、DataDome、Akamaiの背後にある本番Webサイトではブロックされます。
Clawbrowserの内蔵MCPサーバーは独自のChromium engineに接続します。LLMがnavigateを呼ぶと、MCPサーバーはmanaged fingerprints、geo-aligned proxy routing、engineレベルのCDP signal抑制を備えたbrowserへCDPコマンドを送信します。stealth plugin、proxy middleware、fingerprint rotationコードは不要です。
MCPパス（LLM駆動、glueコード不要）：
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]CDPパス（スクリプト、完全制御）：
browser = await playwright.chromium.connect_over_cdp(
"http://127.0.0.1:9222"
)どちらのパスも同じClawbrowser instanceに接続し、同じfingerprints、proxy routing、anti-detectionを使います。ユースケースに合うインターフェースを選んでください。1つのプロジェクト内でworkflowの異なる部分に異なるレベルの制御が必要な場合は両方を使えます。
agentを両方のprotocolで構築するステップバイステップのチュートリアルは、ウェブを閲覧するAIエージェントの構築方法を参照してください。
判断フレームワーク
| 質問 | CDP | MCP |
|---|---|---|
| 実行手順が事前に分かっているか？ | はい | CDPを使う |
| LLMがクリック先を判断すべきか？ | MCPを使う | はい |
| Networkのinterceptが必要か？ | はい | 利用不可 |
| サブ秒単位のアクション速度が必要か？ | はい | いいえ（LLM遅延あり） |
| 非開発者向けか？ | いいえ | はい |
| Claude CodeまたはCursorを使っているか？ | 利用可 | ネイティブ統合 |
| browserコードをゼロにしたいか？ | いいえ | はい |
両方の列で「はい」がある場合は、両方を使います。LLM駆動の部分にはMCP、精密制御の部分にはCDPを。Clawbrowserはどちらのprotocolでもbrowserレイヤーを担います。
FAQ
browserを変えずにCDPとMCPを切り替えられますか？
はい（browserが両方をサポートしている場合）。Clawbrowserは各profileにCDP endpointを公開し、内蔵MCPサーバーも提供します。スクリプト自動化にはPlaywrightをCDP endpointに接続し、LLM駆動ブラウジングにはMCPサーバーを使います。同じbrowser profileで同じfingerprintsとsessionsを利用できます。両方の接続方法の手順はCursorをCDPで実ブラウザに接続する方法をご覧ください。
どちらのprotocolが速いですか？
CDPです。LLM inferenceが不要なため、コマンドはミリ秒で実行されます。MCPはLLMが呼び出すツールを決定し結果を解釈する必要があるため、アクションごとに0.5〜3秒かかります。50ステップのスクレイピングジョブはCDPなら数秒、MCP経由なら数分かかります。手順が分かっている大量自動化にはCDPを使い、各ステップで判断が必要なタスクにはMCPを使います。
WebDriver BiDiはどうですか？
WebDriver BiDiはW3C標準で、WebDriver（Seleniumが使用）とCDPの一部をbrowser非依存のprotocolで置き換えることを目指しています。まだ成熟途上です。PlaywrightとPuppeteerは引き続き内部でCDPを使っています。WebDriver BiDiが完全に普及すれば、browser制御レイヤーでCDPと競合しますが、tool-useレイヤーのMCPとは競合しません。本記事のCDP対MCPの判断フレームワークは、低レベルのbrowser protocolが何であっても適用できます。
どちらのprotocolでもanti-detect browserは必要ですか？
はい（agentがanti-bot保護のあるサイトを自動化する場合）。CDPにもMCPにもanti-detectionは含まれていません。これらはbrowserへコマンドを送るprotocolです。browserが自動化シグナル（navigator.webdriver、headless User-Agent、汎用canvas hash）を漏洩すれば、どちらのprotocolを使っても検知されます。完全な検出モデルについてはブロックされないブラウザ自動化を参照してください。
構築を始める
clawbrowser.aiでインストールプロンプトをAIエージェントに貼り付けてClawbrowserをインストールします。
MCPパス（LLM駆動）：agentにClawbrowserのMCPサーバー設定を追加し、自然言語でブラウジングを開始します。
CDPパス（スクリプト）：PlaywrightまたはPuppeteerをCDP endpointに接続し、自動化コードを書きます。
両方：LLMが何をすべきか推論する部分にはMCPを、精密で高速な決定的制御が必要な部分にはCDPを使います。同じbrowser、同じfingerprints、同じsessionsです。
CDPの詳しい解説はAIエージェント向けCDPブラウザ開発者ガイドをご覧ください。構築チュートリアルはウェブを閲覧するAIエージェントの構築方法をご覧ください。
Continue exploring
Ask AI how Clawbrowser helps
続きを読む
