WebMCPとMCPの違いとは

MCPは、自社のツールをAIエージェントに公開するサーバーを運用するためのプロトコルで、エージェントはどこからでもそのツールにアクセスできます。一方、WebMCPは提案中のWeb標準で、ユーザーがページを開いている間に、そのページ上でエージェントが実行できる操作をページ自身が宣言できるようにするものです。

すでにMCPサーバーを構築したことがある方なら、「WebMCP」という名前から、同じプロトコルがブラウザに移っただけのものだと想像するかもしれません。しかし、そうではありません。この違いによって、エージェント向けのコードをどこに配置するか、どのIDで実行されるか、そして現時点で本番利用に踏み切れるかどうかが変わってきます。

本記事では、両者をランタイム、ID、ライフサイクル、ディスカバリーの観点から比較します。そのうえで、それぞれがどのようなプロダクトに適しているかを整理し、WebMCPの現状を率直に解説します。

WebMCPとMCPの違いを一言で言うと？

MCPは、エージェントが自社のツールを呼び出せるように運用するサーバーです。WebMCPは、エージェントがすでに開いているページ上で何ができるかを、そのページ自身が宣言する仕組みです。Model Context Protocolは、AIアプリを外部のデータ、ツール、ワークフローに接続するためのオープン標準であり、エージェントがブラウザ上で動作しているかどうかは問いません。Chromeのガイド「WebMCPとMCPの使い分け」では、WebMCPを2つのAPIで構成される提案中のブラウザ標準と位置づけています。これらのAPIが連携するのはブラウザに組み込まれたエージェントだけで、ブラウザがそのエージェントとサイトの間でメッセージを仲介します。独自のエージェントを搭載したブラウザについては、エージェント型ブラウザ入門を参照してください。ChromeはWebMCPを「MCPに着想を得た（MCP-inspired）」ものと表現しています。つまり、MCPをモデルにしたブラウザAPIであって、MCPをJavaScriptで書き直したものではありません。

MCPとWebMCPでは、誰が何を実行するのか？

MCPサーバーは独立したプロセスであり、独自のデプロイ、独自の認証、独自の稼働管理が必要です。WebMCPは新たなプロセスを追加せず、開いているタブの中で動作します。

MCPでは、デスクトップ、モバイル、クラウド、Webのいずれのクライアント上のエージェントからも、いつでも接続できるサービスを運用します。このリーチの広さにはコストが伴います。サーバーのホスティング、バージョン管理、監視を自分で行い、各呼び出し元をどのように認証するかも自分で決める必要があります。クライアント、サーバー、プロトコルがどのように連携するかについては、MCPエコシステム開発者ガイドで解説しています。

WebMCPでは、ツール定義はフロントエンドの一部として配信されます。追加でデプロイするものはありませんが、ツールはタブに紐づきます。各WebMCPツールは、それを登録したタブとともに消滅します。ユーザーが別のページに移動したりタブを閉じたりすると、エージェントはそのツールにアクセスできなくなります。

ID：エージェントはサインイン中のユーザーとして動作する

WebMCPのツールはユーザーがすでに開いているページ内で実行されるため、それを使うエージェントはそのユーザーの既存のセッション、Cookie、権限の範囲内で動作します。サイトに対する別個の認証情報を持つことはありません。Chromeは、WebMCPがページのライブなセッションデータ、Cookie、DOMを利用できる点を指摘しており、これらはいずれも開いているタブの外には存在しません。したがって、ツールが発行するネットワークリクエストは、ページがすでに保持しているセッションをそのまま伴って送信されます。

MCPサーバーが直面する課題は異なります。MCPサーバーは独立したサービスなので、誰が呼び出しているのか、何を許可するのかを自ら判断しなければなりません。通常は、エージェントやそれが代理するユーザー向けに、何らかの認証情報を発行・検証する必要があります。WebMCPはユーザーのセッションから一切出ないため、この手順が不要です。APIキーのプロビジョニングやサービスアカウントの設定、エージェント専用の認可レイヤーの構築は必要ありません。

ただし、WebMCPのセッションベースのIDにはトレードオフがあります。ページから見ると、WebMCPのツール呼び出しはサインイン中のユーザーとして実行される操作です。意図的に区別する仕組みを設計しない限り、コード側ではエージェントによる呼び出しとユーザーのクリックを見分けられません。そこから、次の3つのプラクティスが導かれます。

• 各ツールのスコープは、ユーザーがUI上ですでに実行できる操作の範囲に限定する。
• センシティブな操作には確認を求める。WebMCPの概要によると、購入などのセンシティブな処理を行うツールは、実行前にユーザーに確認ダイアログを表示できます。
• プラットフォームによる制御を活用する。WebMCPはオリジン分離されたドキュメントでのみ動作し、tools Permissions Policyによって制御されます。このポリシーのデフォルトはselfなので、クロスオリジンのiframeには明示的にアクセスを許可する必要があります。

<iframe src="https://widget.example.com/" allow="tools"></iframe>

iframeにこの属性がない場合、デフォルトのselfにより、そのクロスオリジンフレームでのツール登録はブロックされます。また、Chromeのドキュメントによると、document.domainを有効にしているドキュメント（たとえばOrigin-Agent-Cluster: ?0ヘッダーを使用している場合）では、WebMCP APIは無効化されます。

WebMCPとMCPの比較

MCPとWebMCPの本質的な違いは、一方が永続性とリーチを、もう一方がページのコンテキストとユーザーセッションを重視している点にあります。

上の5行は、ChromeによるWebMCPとMCPの比較に基づいています。

MCPとWebMCPはどう使い分けるべきか？

UIのないサーバー上で行う処理にはMCPを、ユーザーがいるページ上で行う処理にはWebMCPを使います。

• バックエンドサービス、バックグラウンドジョブ、UIを伴わないデータアクセス：MCP。 WebMCPには開いているページが必要であり、Chromeの概要でも、ヘッドレス実行ではなく、主にローカルブラウザで作業する人を想定して設計されていると説明されています。まずはMCPサーバーの構築方法から始めましょう。
• ログイン中のユーザーがいるWebアプリ：WebMCP。 複雑なフォームの入力や予約ウィジェットでの日付選択など、ユーザーのセッションやページの状態が重要になる、現在のページ上の操作に使います。
• 両方。 多くのプロダクトでは両方が必要になるでしょう。MCPがコアとなるビジネスロジックとデータを担い、WebMCPがタブ内の操作をカバーします。すでにHTTP APIがある場合は、MCPでAPIをLLMに公開するのが、サーバーサイド側の自然な選択肢です。ブラウザ側については、関連記事WebMCPでサイトの操作をAIエージェントに公開するを参照してください。

WebMCPはMCPを置き換えるのか？

いいえ。Chromeは、WebMCPがMCPを拡張するものでも置き換えるものでもないと明言しています。WebMCPはブラウザ向けに設計されており、リソースなどのサーバーサイドの概念は含まれていません。また、ページに依存します。ツールはサイトにアクセスしなければ見つけられず、タブを閉じると消えてしまいます。スケジュールされたジョブ、IDEアシスタント、データパイプライン、クラウドで動作するエージェントなど、Webページにまったく関与しないエージェントタスクも数多く存在します。こうしたタスクには、引き続きMCPサーバーが必要です。

WebMCPの成熟度は？

WebMCPは実験段階にあります。Chrome 149から始まるChromeのオリジントライアルを通じて、またローカルではchrome://flags/#enable-webmcp-testingフラグを通じて利用でき、ChromeはAPIがまだ議論中であり変更される可能性があると警告しています。オリジントライアルは期間限定で実施され、利用上限が設けられる場合もあり、最終的なAPIの形を決めるためのフィードバック収集を目的としています。WebMCP仕様は、W3C Web Machine Learning Community Groupによるドラフトレポートです。W3C標準ではなく、W3C標準化トラックにも乗っていません。Chromeのドキュメントが扱っているのはChromeの実装のみなので、他のブラウザやエージェントホストでのサポートについては、それぞれのドキュメントで確認できるまで前提にしないでください。マイルストーンの変更はChrome StatusのWebMCPページで追跡できます。また、ChromeはWebMCPをプログレッシブエンハンスメントとして追加できるとしています。エージェントがツールを認識できるかどうかにかかわらずUIが同じように動作するよう、その方針で実装しましょう。

どちらを選ぶべきか

MCPとWebMCPは、異なる問いに答えるものです。MCPは、あらゆるエージェントからいつでも自社の機能にアクセスできるようにします。WebMCPは、ユーザーが開いているページを、そのユーザーのブラウザ内のエージェントがユーザー自身のセッションで操作できるようにします。次のステップとして、プロダクトが公開している操作を洗い出して分類しましょう。ヘッドレスな処理はMCPサーバーに任せ、セッションに紐づくページ上の操作は、オリジントライアルのもとでWebMCPの候補とします。APIはまだ変更される可能性があるため、WebMCPのレイヤーは薄く保っておきましょう。

よくある質問

自分のブラウザだけでなく、実際の訪問者に対してWebMCPを有効にするにはどうすればよいですか？

Chrome Origin Trialsコンソールでオリジンを登録し、WebMCPのトークンを生成します。そのトークンを、ツールを登録するすべてのページで、オリジントライアル用のmetaタグまたはOrigin-Trial HTTPレスポンスヘッダーとして配信してください。トークンはオリジンごとに発行されます。トークンがない場合、通常のChromeを使う訪問者にはツールが一切表示されません。ローカルのテスト用フラグは、それを有効にしたブラウザにしか影響しないためです。トライアルはChrome 149で開始され、当初はChrome 156までの予定でした。GoogleはChrome 162までの延長を申請しているため、Origin Trialsコンソールで自分のトークンの有効期限を確認してください。

エージェントを構築せずにWebMCPツールをテストするにはどうすればよいですか？

ChromeのWebMCPドキュメントで紹介されているChrome拡張機能、Model Context Tool Inspectorを使用します。ページが登録したツールを一覧表示し、自分で実行できます。また、ブラウザがJSON Schemaを解析できるかどうかを確認でき、各ツールが返す結果やエラーも表示されます。なお、ページ側ではWebMCPを有効にしておく必要があります。chrome://flagsのWebMCPテスト用フラグを使うか、オリジントライアルのトークンを使用してください。

MCPのツール定義をWebMCPで再利用できますか？

入力の定義は多くの場合再利用できますが、ハンドラーは再利用できません。MCPツールとWebMCPツールはどちらもJSON Schemaで入力を記述するため、ツールの名前、説明、引数の構造は通常そのまま流用できます。異なるのはハンドラーです。MCPのハンドラーは、自分で実装した認証のもとでサーバー上で実行されます。WebMCPのハンドラーはページ内で実行されるJavaScriptで、ユーザーのセッションとライブなDOMの状態を利用します。

AngularはWebMCPをサポートしていますか？

はい。ただし実験的なサポートにとどまります。Angularの実験的サポートでは、Angularの依存性注入（DI）のライフサイクルに従うWebMCPツールを登録でき、JSON Schemaを手書きしなくてもSignal Formsをツールに変換できます。Angularのドキュメントでは、WebMCP仕様は頻繁に変更されており、これらのAPIはメジャーバージョン以外でも変更される可能性があると警告しています。Angularのバージョンを固定し、コードの更新が必要になることを想定しておきましょう。