公開日: 2026 年 3 月 11 日、最終更新日: 2026 年 10 月 27 日
ブラウザで AI エージェントが一般的になるにつれて、ウェブ デベロッパーから「WebMCP は Model Context Protocol（MCP）に代わるものですか？」という質問が寄せられています。この質問は誤解から生じています。エージェント エクスペリエンスを作成するために、MCP と WebMCP のどちらかを選択する必要はありません。WebMCP は、MCP の拡張機能でも代替でもありません。
WebMCP と MCP は、それぞれ異なるニーズに対応しています。WebMCP は、アプリケーション機能の目的を明確にし、ウェブサイトとやり取りするための追加機能をブラウザ エージェントに提供します。
この 2 つのテクノロジーの違いは、会社のコールセンターと店舗の専門スタッフの違いに似ています。
- MCP はコールセンターです。いつでもどこからでも利用できます。必要に応じてデータにアクセスし、コアタスクを処理します。
- WebMCP は店舗のエキスパートです。この機能は、ユーザーがページにアクセスしている間のみ利用できます。これにより、エージェントは人間向けに設計された UI を理解するのではなく、サイトの機能を直接使用できます。
これらを組み合わせることで、エージェントは人間のユーザーに代わってパーソナライズされたタスクを完了できます。
機能と目的
どちらのテクノロジーも、アプリケーションがツールを AI エージェントに公開するための標準化された信頼性の高い方法を作成するという同じ理念を共有しています。
実際には、次のような内容が含まれます。
- 構造化されたツールの検出: エージェントが「何ができるか」を尋ね、使用可能なツール、そのパラメータ、目的の明確なリストを取得するための、機械で読み取り可能な方法を提供します。
- 予測可能な実行: 推測ではなく、明示的な関数呼び出しを使用します。エージェントが定義済みのツールを呼び出します。通常、モデルは呼び出すツールを選択し、ハーネスがそれを実行します。エラーからの復旧など、場合によっては、ハーネスがツールを直接呼び出すこともあります。
- 明確な意図: 機能を明示的に宣言します。WebMCP と MCP がないと、エージェントは UI の理解に基づいて、実行するアクションを推測します。WebMCP と MCP を使用すると、エージェントは UI 要素からアクションを推測することなく、各機能の明示的な説明を取得できます。
WebMCP と MCP の主な違いは、アプリケーション機能がどこに存在するかです。
MCP がエージェントをサービスに接続
Model Context Protocol（MCP）は、AI エージェント（ブラウザベースかどうかを問わず）をデータソース、ツール、ワークフローなどの外部システムに接続する標準です。このプロトコルは汎用性があり、JSON-RPC 2.0（stdio や HTTP などのトランスポート上で実行）に基づいて構築されています。これは、Rust、Python、TypeScript などの言語固有の SDK を介して実装されます。
WebMCP でエージェントをウェブページに接続する
WebMCP は、ページがブラウザで動作するエージェントにツールを公開できるようにする、提案されているブラウザ標準です。これらの API は、JavaScript または HTML 属性を使用して実装できます。ブラウザは、ウェブサイトとエージェント間のコミュニケーターとして機能します。
WebMCP は、MCP の JavaScript 実装ではなく、「MCP に着想を得た」API のセットと考えてください。WebMCP はブラウザ専用に構築されており、リソースなどのさまざまなサーバーサイドのコンセプトが省略されています。
エージェントによるウェブサイトへのアクセスを制御する
WebMCP を使用すると、エージェントに特定のタスクを完了するための優先パスを提供できます。これには、次のような主なメリットがあります。
- 速度と信頼性: WebMCP はブラウザの内部システムを使用するため、エージェントは追加のネットワーク ホップなしでツールを呼び出すことができます。
- 耐久性に優れた設計: WebMCP ツールは、設計ではなくアプリケーション ロジックに接続します。つまり、命令型ツールはレイアウトから切り離されています。エージェントがウェブサイトと正しくやり取りする機能を損なうことなく、ウェブサイトを再設計できます。
- 管理はユーザーが行う: エージェントがクリックする適切なボタンを見つけることを期待するのではなく、エージェントがサイトを操作する好ましい方法を明確に定義します。エージェントが理解できる方法でアプリケーションのロジックを定義し、エージェントが UI からアクションを推測するのではなく、直接ガイドします。
UI アクセスを制御する
違いを理解するには、「UI を所有しているのは誰か」を考えてみてください。MCP アプリは、エージェント UI 内にアプリケーションの UI をレンダリングします。インターフェースはこれらの制約に準拠する必要があり、新しい別のアプリケーションが必要です。
WebMCP を使用すると、エージェントは既存のウェブサイトとリアルタイムでやり取りできます。ツールは、ユーザーのセッションを使用してページ内で実行されます。アプリケーションがエージェント内のゲストになるのではなく、エージェントがプラットフォーム上のゲストになります。
重要なのは、WebMCP ツールはエフェメラルであるということです。ページが開いている間のみ存在します。ユーザーがページから移動するか、タブを閉じると、ページの WebMCP ツールは使用できなくなります。
WebMCP と MCP を使用する
特定の機能に適したソリューションを選択する際は、コンテキストと可用性を考慮してください。
| MCP | WebMCP | |
|---|---|---|
| 概要 | エージェントをバックエンド システムに接続するプロトコル | エージェントにツールを提供するウェブページ用のフロントエンド JavaScript API |
| ツールの場所 | サーバー上 | ウェブページ |
| ツールを呼び出すことができるユーザー | 任意の MCP クライアント | レンダリングされたページにアクセスできるエージェントまたはクライアント（ブラウザ、ウェブビューなど） |
| コードの実行場所 | サーバー | ページの JavaScript ランタイム |
| 利用できるタイミング | サーバーが稼働している限り、常に | ページが開いている間のみ |
| 使用するログイン情報 | 独自の認証情報 | ユーザーの現在のセッション |
| UI | なし、またはエージェントのアプリ内に表示 | エージェントが動作する独自のウェブサイト |
| 構成要素 | ツール、リソース、プロンプト | ツールのみ |
| ツールの検出 | ユーザーまたはアプリがサーバーを追加する | ページがアクティブなセッションで動的に登録する |
| 最適なユースケース | バックグラウンド タスクとデータアクセス | コンテキスト内のウェブ アクション、クライアントサイドのセッション統合、ウェブ自動化 |
アプリケーションは、両方を使用することでメリットを得ることができます。
- MCP でコアロジックを管理する: MCP サーバーは、基盤となるサービスレイヤとして機能します。コアのビジネス ロジック、データ取得、バックグラウンド タスクを処理します。これにより、サービスはプラットフォームに依存せず、エージェントが常に利用できるようになります。
- WebMCP を使用してコンテキスト UI を構築する: WebMCP は最後のステップで、エージェントをウェブサイトに直接接続します。コンテキストに応じたブラウザ内でのインタラクション向けに設計されており、ユーザーがウェブサイトを開いている間に、エージェントがユーザーに代わって迅速かつ確実に操作を実行できます。
MCP と WebMCP は、競合ではなくパートナーとして捉えてください。WebMCP は、ブラウザベースの AI エージェントが、ユーザーがタブに表示している特定の世界とやり取りするための高忠実度の方法を提供します。