MCPサーバーとWebMCPの違い AIに渡すのは入口か操作方法か
MCPサーバーとWebMCP。名前が3文字しか違わないので、同じものの言い換えだと思ってしまいます。私も最初はそう読みました。違いました。
先に結論を書きます。MCPサーバーはAIに「自社システムへの入口」を渡すもの。WebMCPはAIに「いま開いているページの操作方法」を渡すものです。渡す相手も、通る経路も、必要な準備も別です。
Cloudflareが8月6日にWebMCPの開発者プレビューを出したこともあって、この2つを並べて説明する必要が出てきました。順に見ていきます。
MCPサーバーは「AIに自社システムの入口を渡す」もの
MCP(Model Context Protocol)は、AIが外部のツールやデータと話すための共通規格です(詳しくは前の記事に書きました)。MCPサーバーというのは、その規格に沿って「うちにはこういう道具がありますよ」とAIに差し出す側のこと。相手はSaaSとは限りません。手元のパソコンのファイル、社内のデータベース、自社の業務システム。AIに触らせたいものがあれば、その前に立つ受付がMCPサーバーです。
サーバーという名前から大掛かりなものを想像しますが、規模の話ではありません。自分のパソコンの中で動く小さなプログラムでもMCPサーバーです。
動き方はこうです。AIプラットフォーム(ChatGPTやClaudeなど)がそのMCPサーバーに接続し、直接やり取りをする。利用者はAIと会話しているだけで、裏側でAIがサーバーと話して用事を済ませてくれます。
WebMCPは「AIに目の前のページの操作方法を渡す」もの
一言でいうと、バックエンドのAPIを新しく作らなくても、ブラウザに表示されているその画面の機能を、AIが直接動かせるようにする仕組みです。ページ側でWebMCPの道具を用意しておくだけでいい。
置き場所がまったく違う、と言い換えてもいいと思います。MCPサーバーはサーバー側、WebMCPはWebページの中です。
W3CのWeb Machine Learning Community Groupで策定が進んでいるWebMCPの提案によると、WebMCPは、Webアプリケーションの機能を「道具」として公開する仕組みです。公開できるのはJavaScriptの関数か、HTMLのフォーム。それぞれに自然言語の説明と、入力の形式を添えておく。するとAIエージェントがそれを読んで、直接呼べるようになります。
ブラウザ側では document.modelContext というAPIとして提案されていて、標準化が進められている段階です。Chromeで実験提供が始まっていて、Cloudflareの8月6日の発表ではChrome 146で実験的に提供されていると説明されています。一方でChrome公式のドキュメントは、Chrome 149からのオリジントライアルと、ローカル開発ではフラグを立てて試す方法を案内しています。まだバージョンの案内が固まりきっていない、という状況です。
何がうれしいのか。いまブラウザを操作するAIは、画面のスクリーンショットを撮り、何が写っているかを解析し、押すべき場所を推測してクリックしています。私たちもClaude in Chromeを毎日使っていますが、この方式は画面が少し変わるだけで崩れます。WebMCPなら「席を検索する」「予約を入れる」といった関数を最初から呼べる。推測が要らなくなるわけです。
呼ぶ側も1つではありません。ブラウザに内蔵されたエージェントだけでなく、ページ内やiframeで提供されるエージェントも想定されています。
違いは、ユーザーの画面とセッションを通るかどうか
2つを並べます。
| MCPサーバー | WebMCP | |
|---|---|---|
| 道具の置き場所 | サーバー側 | Webページの中(JavaScript) |
| 誰が呼ぶか | AIプラットフォームがサーバーへ直接接続 | ブラウザの中のエージェントがページの関数を呼ぶ |
| ユーザーの画面 | 経由しない | 経由する。画面と状態を共有したまま動く |
| 認証・状態 | サーバー側で用意する必要が出やすい | 訪問者がいまログインしているセッションをそのまま使える |
| 作るもの | サーバー側の実装が要る(既存APIを包む形が多い) | 既存のクライアント側JavaScriptを流用しやすい |
| 向いている用途 | 社内システムの参照や更新、定型処理 | 画面を伴う操作、その人の権限での作業 |
決定的なのは3行目と4行目です。MCPサーバー方式では、AIとサーバーが直接話すので、そのサービスのWeb画面は素通りされます。WebMCPでは、ユーザーが開いている画面の上でエージェントが動く。
WebMCPの提案文書は、この点をバックエンド連携方式の課題として3つ挙げています。
- UIを飛び越えて文脈が失われる: エージェントとサービスが直接やり取りするため、そのサービスのWeb体験が使われない
- 状態と認証を複製する必要がある: ユーザーの状態、いまの文脈、認証情報を、別のサーバー側にもう一度用意しなければならない
- 開発の負担が大きい: サイトが持っているクライアント側の機能を外に出すために、わざわざ専用のサーバーを書くことになる
3つ目は、中小企業にとって現実的に重い話です。「AIから使えるようにしたいだけなのに、なぜサーバーを1本作るのか」という疑問には、正直なところ答えづらい。WebMCPはそこに対する、クライアント側からの回答です。
別物だが、排他ではない
ここまで違いを強調しましたが、対立する規格ではありません。つながっている部分が3つあります。
考え方と道具の表現が近いです。 WebMCPはMCPから着想を得ていて、ツール、スキーマ、パラメータといった共通の考え方を使っています。入力と出力をJSON Schemaではっきり定義してAIの誤解を減らす、という思想も同じ。ただしMCPをそのままブラウザに移植した規格ではありません。Chrome公式のドキュメントは、WebMCPをMCPに着想を得たAPI群であってMCPの直接的なJavaScript実装ではない、ブラウザ専用に作られていてリソースなどサーバー側の概念は省いている、と説明しています。
Cloudflareの実装は、さらに両者を近づけています。 MCPのToolとCallToolResultという型をそのまま使っていて、パック(道具の束)とは「MCPのツール記述子とそのハンドラの集まりにすぎない」と書かれています。後述する2つのパックのうち片方が、まさにページから自社のMCPサーバーを呼ぶためのものです。すでにMCPサーバーを持っている会社は、それをWebMCP側へ橋渡しできます。
役割分担で考えるほうが正確です。 サーバー側で完結する処理はMCPサーバー、画面と権限を伴う操作はWebMCP。どちらか一方を選ぶ、という問いの立て方が、そもそも合っていません。
Cloudflareが出したのは、WebMCPを1クリックにする仕組み
ではCloudflareが8月6日に公開した開発者プレビューは何なのか。WebMCPを自分で実装しなくて済むようにするものです。
ダッシュボードで有効にすると、HTMLのレスポンスに1行だけスクリプトタグが差し込まれます。
<script type="module"
src="/.webmcp/bridge.js"
data-packs="c2pa,mcp-server-client"
data-mcp-url="/mcp"></script>
data-packs が有効にする道具の束、data-mcp-url が自社のMCPサーバーの場所です。オリジンのコードは1行も変わりません。 静的サイトでもSPAでも同じで、curl -s https://自社サイト | grep webmcp で入ったかどうか確認できます。ブラウザがWebMCPに対応していなければ、この橋渡し役は何もせずに終了するので、ページの挙動は今までどおりです。
ただし、今できることはかなり限られています。
| パック | 中身 | 現時点の制約 |
|---|---|---|
| Content Credentials | ページ内の画像のC2PA(来歴)情報を走査・解析する | 読んで報告するだけで、署名の暗号的な検証はしていません |
| Site MCP Server | ページから自社のMCPサーバーを呼ぶ | 自社のMCPサーバーが前提。持っていなければ使えません |
試す側の条件も厳しめです。WebMCPはChromeで実験提供されている段階で、CloudflareのBrowser RunではChrome betaの機能を有効にしたlabセッションを使って試せます。ただしそのドキュメントには、labセッションは実験的であり本番用途に使うべきではないと明記されています。
Cloudflareがこれを作った理由も書かれていて、そこは面白い。従来のクローラーはコンテンツをサーバーへ持ち帰り、元のサイトにはトラフィックも功績も残らなかった。WebMCPなら、エージェントは訪問者のブラウザの中で、そのサイトのオリジンとセッションのまま動く。サイトにアクセスが残るわけです。訪問者が必ずしも人間ではなくなっても成り立つWebへの一歩、という位置づけでした。
自社はどちらを考えるべきか
3つに分けます。
MCPサーバーを先に考えるべき会社。社内に、AIに参照させたい情報や実行させたい処理がある。在庫、顧客情報、受発注。画面を経由する必要がなく、決まった処理を確実に回したいなら、こちらが先です。
WebMCPが効いてくる会社。自社サイトやWebサービスの上で、訪問者に何か操作してもらう構造がある。予約、検索、申し込み、見積もり。その操作をAIエージェントに任せられるようにしたい会社です。ただし今はまだ準備段階なので、今日から効果が出る話ではありません。
今はまだ何もしなくていい会社。MCPサーバーを持っておらず、サイトも会社案内が中心。正直に言うと、多くの中小企業がここです。Cloudflareの開発者プレビューを今日有効にしても、得られるものはほぼありません。
それでも、この3つ目の層が今日できることはあります。
- サイトの情報を構造化しておく。営業時間、料金、対応範囲、よくある質問。AIに読み取ってほしい情報が、人間向けの画像やPDFの中にしか無い状態を先に解消する
- 公開してよい情報の線引きを決めておく。AIから触られてよいものと、そうでないもの。規格が固まってから慌てるより、先に決めておくほうが早い
- 小さなMCPサーバーを1つだけ作ってみる。全社導入ではなく、社内の1つの資料置き場をAIから引けるようにするだけでいい。作ってみると、権限をどう絞るかという本当の論点が見えてきます
私たちがAI導入支援の現場で見ていても、詰まるのはいつも技術ではなく、この2つ目と3つ目です。規格の議論を追いかけるより、手元の準備のほうが効きます。
まとめ 入口を作るのか、操作方法を並べるのか
もう一度だけ。MCPサーバーはAIに自社システムへの入口を渡すもの。WebMCPはAIに目の前のページの操作方法を渡すもの。 ここさえ押さえておけば、今後どちらの名前が出てきても迷わないはずです。
WebMCPはまだChromeの実験機能で、Cloudflareの提供も開発者プレビューです。今日の判断材料にはなりません。ただ、画面を持つサービスがAIエージェントの相手になるという方向は、もう動き始めています。
自社サイトで、訪問者に何かを操作してもらっているなら。その操作を関数として名前を付けるとしたら何になるか、一度書き出してみてください。予約する、在庫を調べる、見積もりを出す。その一覧が、いずれそのままAIに渡す道具の一覧になります。