MCP サーバーで動かすKitesurf WebMCP：接続・実行・検証ガイド

MCP サーバーでKitesurf WebMCPを使う最短手順

Kitesurf WebMCPを使うには、MCP対応エージェントをChrome DevTools MCP経由でCloudflare Browser Runに接続し、WebSocketエンドポイントにbrowser=kitesurfを指定して、試験運用中のWebMCPツールカテゴリを有効にします。これにより、ページのアクションを検出するlist_webmcp_toolsと、選んだアクションを実行するexecute_webmcp_toolという2つの重要なコマンドをエージェントから使えるようになります。

最初に試すのは、読み取り専用か、簡単に元へ戻せるアクションにします。Cloudflare Radarは、navigate-toやset-locationなどのアクションを公開していることが文書化されており、検証先として適しています。Kitesurfが返すスキーマを確認し、そのスキーマで許可された引数だけを渡したうえで、構造化された結果と実際に見えるページの状態を照合します。両方が一致するまで、ツール呼び出しを成功とみなしてはいけません。

以下は公開ドキュメントに基づくテスト手順であり、ライブテストの成功を主張するものではありません。この検証ではCloudflareのテストアカウントもBrowser Runトークンも利用できなかったため、架空の成功結果は掲載していません。

Kitesurf WebMCPで何が変わるのか

MCPとWebMCPの役割は異なります。MCPはエージェントをリモートブラウザにつなぎ、WebMCPはそのブラウザ内でWebサイト自身が名前付きアクションを公開できるようにします。MCPが電話回線なら、WebMCPは通話先のメニューです。回線で相手につながり、メニューを見れば注文できる項目と、それぞれに必要な情報が正確にわかります。

そのメニューがなければ、エージェントは通常、ページを読み、操作対象を探し、クリックして待ち、もう一度ページを読み取ります。WebMCPがあれば、ページは型付きの入力を持つset-locationのような関数を公開できます。適切なアクションを選び、出力を検証する責任はエージェント側に残りますが、画面のピクセルやページ構造からすべての操作を推測する必要はなくなります。

CloudflareのWebMCPドキュメントによると、Kitesurfには独自の実装があるため、Chrome Labセッションは不要です。ページはdocument.modelContextを通じてプログラム型ツールを登録できるほか、Kitesurfはtoolnameとtooldescription属性が付いた宣言型フォームツールも認識します。

MCP サーバーをKitesurfに接続する

必要なのは、Node.js 20.19以降、MCP対応クライアント、CloudflareのアカウントID、そしてBrowser Rendering - Edit権限を持つAPIトークンです。CloudflareのMCPクライアント設定ガイドでは、Claude Desktop、Claude Code、Cursor、OpenCodeの設定方法を確認できます。初めてMCPに接続する場合は、MCPサーバーの比較記事を読むと、ローカルサーバーが担う役割をつかみやすくなります。

CloudflareがKitesurfの公開時に示したローカルクライアント設定は、次のとおりです。

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

設定の形は利用するクライアントに合わせますが、コマンド引数はそのまま保ちます。実際のアカウントIDとトークンは、リポジトリにコミットする設定ファイルではなく、環境変数などのシークレットから読み込ませてください。このURLにChrome Lab用のパラメータを加えてはいけません。Kitesurfではbrowser=kitesurfを使い、lab=trueは不要で、keep_aliveも受け付けません。

最後のフラグは必須です。--category-experimental-webmcpを指定することで、Chrome DevTools MCPにlist_webmcp_toolsとexecute_webmcp_toolが追加されます。接続そのものは正常でも、このフラグがなければ2つのWebMCPコマンドは表示されません。

Cloudflare Radarで検証付きタスクを1回実行する

最小限の有効なテストでは、ツールを検出できること、スキーマを読めること、実行結果が返ること、そしてページに結果が反映されることの4点を確認します。

1. 接続したエージェントにhttps://radar.cloudflare.com/を開かせます。テスト用アカウントの範囲内で実施し、金銭、破壊的変更、アカウント全体に影響する操作は避けます。
2. list_webmcp_toolsを呼び出し、返されたすべてのツール名、説明、入力スキーマを保存します。利用できるツール群は、ページ遷移や別の操作の後に変わる可能性があるため、この一覧は現在のページ状態にひも付けます。
3. set-locationのような安全なアクションが見つかったら、それを選んで返却スキーマを読みます。この記事を見て引数名を推測してはいけません。実際に返されたスキーマを契約として扱います。
4. スキーマに適合する場所の値を指定してexecute_webmcp_toolを呼び出します。正確なツール名、引数、構造化された結果、経過時間、画面上のページ状態を記録します。
5. レスポンスとRadarの表示を照合します。状態が変わった後にlist_webmcp_toolsを再実行し、追加または削除されたアクションも記録します。

エージェントへの指示は、次のように具体的にします。

証跡はチャット履歴ではなく、小さなテスト記録として扱います。最低限、次の項目を残してください。

これで単なるデモが、開発チームで再現できるテストになります。同時に、WebMCP側の不具合とエージェントの推論ミスを切り分けられます。名前付きツールがなければ、実行前のインターフェース段階での失敗です。呼び出しは成功したのにページ表示が一致しなければ、実行後の実装または検証に問題があります。

Kitesurfでフォールバックが必要な場面

Kitesurf WebMCPは、あらゆるブラウザ操作を担う仕組みではありません。現在の制約を理解してこそ、本番タスクを安全に振り分けられます。

• iframeやポップアップ内で登録されたツールは、CDP経由では公開されません。エージェントからは利用できないものとして扱い、通常のブラウザ操作、人による操作、またはサイトを所有しているならトップレベルのツールを用意します。
• Kitesurfのセッションはwrangler browser listに表示されず、ライブビューもありません。人の確認待ちで停止するツールをエージェントだけで完了させることはできません。
• 確認が必要なアクションについてCloudflareが案内している手動ルートは、Kitesurf playgroundのApplication配下にあるWebMCPパネルです。これは無人自動化ではなく、人への引き継ぎです。
• Kitesurfは、WebMCPのtools権限ポリシーも、オリジン単位のツールフィルタリングも実装していません。ツールを検出できることは、実行権限があることを意味しません。ドメイン、アクション、テスト用IDには別途許可リストを設けてください。
• ツール一覧はページ状態に依存します。ページ遷移や状態を変える操作の後は、次のツールが引き続き存在すると決めつけず、一覧を取得し直します。

本番で採るべき現実的な構成は、ルーター型です。適切な名前付きアクションがあればWebMCPを優先し、なければ通常のブラウザ自動化へ、同意が必要なら人へ引き継ぎます。こうした分岐を、成功だけを期待する1本のプロンプトに隠してはいけません。

判断すべきはブラウザ料金ではなく保守コスト

Kitesurfはベータ期間中、アカウント上限の範囲で無料です。ただしCloudflareは、通常の有料Browser Runにおける超過料金が、この無料ベータにも適用されるとは示していません。現時点のKitesurfの料金と利用枠については、ベータの条件だけを前提に長期的なコストモデルを作るべきでない理由も含め、別の記事で詳しく解説しています。

一方、この市場ではブラウザインフラに実際の予算がすでに投じられています。Browserbaseの有料プランは月額$20と$99、Browserlessは年払いで月額$25と$140です。両製品はより広いインフラ用途を担うため、同条件の置き換え比較ではありません。ここから読み取れるのは、企業がブラウザエージェントの運用にすでに費用を払っているということです。

WebMCPが変えるのは、別のコスト項目です。セレクターの保守、再試行、オペレーターによる確認を減らせる可能性があります。ただし、ブラウザ、モデル、セキュリティ制御、結果検証、フォールバック経路が不要になるわけではありません。同じタスクを2つの方式で実行し、所要時間、失敗回数、人の介入、エンジニアによる修正を比較します。保守負担の削減効果が導入工数を上回る場所でだけ、Kitesurfを採用すべきです。

効果が大きい順：7つのユースケース

以下のすべてのユースケースは、対象ページが適切なWebMCPツールを実際に公開していることが前提です。Kitesurfは、サイトに存在しないアクションを作り出すことはできません。

最も広く価値を生むのは1つ目の用途です。今後何年も、多くのチームは構造化されたサイトと従来型サイトが混在するWebに向き合います。WebMCPを使わない場面まで判断できるルーターのほうが、用意された1ページだけで成功するデモより実用的です。

作る価値がある3つのプロダクト

1. WebMCP優先のフォールバックルーター

ページのツールを一覧化し、ユーザーが求める操作を許可済みのスキーマと照合して、execute_webmcp_tool、通常のブラウザ自動化、人の対応キューのいずれかへ振り分けるポリシー層を、エージェント運用チーム向けに構築します。すべてのサイトがWebMCPに対応するのを待つのではなく、導入時の空白を埋めるため、これが最も有望です。

関連する需要はすでに検索に表れています。browser automationは月間約720回検索され、商用意図のあるbrowser automation toolsは月間約260回、CPCは$34.28です。販売可能な最小構成には、MCPクライアント接続を1つ、ドメインとアクションの許可リスト、スキーマ照合、実行ログ、フォールバックアダプターを1つ用意します。

課題は対応範囲です。WebMCP対応サイトはまだ限られ、ツール群はページ状態によって変化し、Kitesurfはiframeやポップアップ内のツールをCDP経由で公開できません。フォールバックエンジンは後から足す機能ではなく、製品の一部です。

2. WebMCP回帰監視サービス

サイト運営者向けに、公開されているツール名とスキーマを定期記録し、元へ戻せるフィクスチャ用アクションを1つ実行して、結果と画面状態を比較し、差分があれば通知するサービスを提供します。website automationは月間約590回検索され、CPCは$33.88です。関連する単数形の検索語browser automation toolは、候補キーワードデータで前年比24%増えています。

MVPでは、テスト用認証情報を使って所有サイト内の少数のルートを監視し、実行前後のツール一覧を保存して、引数、結果、所要時間、ページ状態をまとめた簡潔な障害記録を作れます。課題は状態管理です。ツールが見つからない原因は、リリースの不具合ではなく、ルートやセッション状態の誤りかもしれません。再現可能なナビゲーションと慎重に設計したフィクスチャが必要です。

3. WebMCP対応状況の監査サービス

Webチーム向けに、顧客導線のどこでトップレベルツールが公開され、どの操作がiframeやポップアップ内にあり、どれに人の承認が必要かを整理する事前監査サービスを構築します。需要を示す実用的な指標として、playwright browser automationは月間約320回検索され、前年比129%増、website automationは月間約590回検索されています。

最小構成では、所有サイトのルートとテスト用IDを受け取り、利用可能なツールを一覧化・分類して、優先順位付きの実装レポートを作成します。率直な課題は可視性です。KitesurfはiframeやポップアップにあるツールをCDP経由で公開できないため、Kitesurfだけを見ても、それらが意図した契約を推測できません。非表示なのか存在しないのかを判別するには、サイト所有者からの情報か、第2の調査手段が必要です。

制約と現実的な評価

Kitesurf WebMCPを今使うなら、構造化されたアクションがクリック操作より明らかに適している、範囲が限定された元へ戻せるタスクに絞ります。重要なワークフローの唯一の経路、入れ子になった決済フロー、人のリアルタイム承認を待つ必要があるタスクには使うべきではありません。

この機能には価値がありますが、エコシステムより先に登場したのも事実です。名前付きアクションは曖昧さを減らし、障害原因を追いやすくします。一方で、すべてのWebサイトがエージェント対応になるわけではなく、返却されたデータだけでページが正しく動いたと証明することもできません。製品の成否を分ける境界は、検証ステップにあります。

この接続、検証テスト基盤、フォールバックポリシーを本番用エージェントへ組み込みたい場合は、本番システムの構築をご相談ください。