この記事は、すでにMCP（Model Context Protocol）を知っている技術者や企画担当者に向けて書いています。「WebMCPという名前を聞いたが、MCPと何が違うのか」「自社のサイトでは、どちらを使えばよいのか」という疑問に答えます。読み終えるころには、両者の役割の違いと、自社の場合にどちらから考えるかを、自分で判断できるようになります。
ご注意いただきたい点があります。WebMCPは、W3Cのコミュニティグループが公開している草案（2026年10月16日付）にもとづく提案で、内容が変わり続けています。この記事は2026年10月時点の確認結果です。実装の前には、末尾の公式資料で最新の内容をご確認ください。起点となる解説はWebMCPとは：AIエージェントが使えるWebサイトの作り方にまとめています。
まず結論：置き換えではなく、役割分担
先に結論を述べます。WebMCPとMCPは、どちらか一方を選ぶ関係ではなく、役割が違う別のものです。MCPは、AIアプリを外部のシステムにつなぐための標準です。WebMCPは、Webページ自身が「できること」をAIに差し出す提案です。
目安としては、次のように考えると整理しやすくなります。
- サーバーの裏側にあるデータや業務を、AIにつなぎたい：MCPの領域
- 利用者が見ている画面の上で、AIに操作を手伝わせたい：WebMCPの領域
- 両方ある：役割を分けて、併用を考える
以下では、それぞれの定義から順に見ていきます。
MCPとは：AIアプリを外部システムにつなぐ標準
MCPは、AIアプリを外部のシステム（データ、ツール、ワークフロー）につなぐための、オープンソースの標準です。Anthropicが開発しました。公式サイトでは「AIアプリのUSB-C」というたとえが使われています。機器ごとに別のケーブルを用意せず、共通の差し込み口でつなぐ、という考え方です。
MCPでは、次の用語がよく出てきます。
- ホスト・クライアント・サーバー：AIアプリ側と、つなぎ先の側の役割の呼び名
- ツール：AIが呼び出せる機能
- リソース：AIが読める情報
- プロンプト：あらかじめ用意された指示のひな形
多くのAIアシスタントや開発ツールがMCPに対応しています。社内のデータベースや業務システムを、AIから使えるようにする場面でよく検討されます。この点は、MCPで社内システムとAIをつなぐで詳しく扱っています。
WebMCPとは：ページ自身がツールを公開する提案
WebMCPは、Webサイトが自分の機能を「ツール」として、ブラウザ上のAIエージェントに公開する仕組みの提案です。ツールは、名前、自然な言葉での説明、入力の形（JSON Schema）、実行する処理（JavaScriptの関数）でできています。エージェントは、画面を読み取ってクリックする代わりに、このツールを呼び出します。
位置づけにも注意が必要です。W3Cの標準になったわけではなく、コミュニティグループの草案の段階です。Chromeでは、Chrome 149からオリジントライアル（公開の試験運用）として提供されています。Chromeの資料も、議論の最中で変更される可能性があると明記しています。Edgeなど他のブラウザの対応時期は、公式な確認が取れていません。
また、WebMCPの主役は、あくまで人間向けの画面です。草案や資料は、バックエンド連携の代わりではないこと、人が関わる使い方を主に想定していることを述べています。画面を持たない完全自律の運用を、想定したものではありません。
違いを一覧で比べる
両者は用語や考え方を共有しています。ただ、動く場所や前提が異なります。草案の説明も、WebMCPはWebの概念（オリジン、ブラウザの権限、DOM、タブの寿命）に合わせて設計された、という趣旨です。主な違いを表にまとめます。
| 観点 | MCP | WebMCP |
|---|---|---|
| 何をするものか | AIアプリを外部システムにつなぐ標準 | ページが自分の機能をAIに公開する提案 |
| 動く場所 | 主にサーバー側の接続 | ブラウザの中のページ |
| 機能を持つ側 | MCPサーバー | ページ自身（MCPのサーバーのように振る舞う） |
| 主な相手 | MCPに対応したAIアプリ | ブラウザ上のAIエージェント |
| Webの概念 | 前提にしていない | オリジン、ブラウザの権限、DOMなどに合わせて設計 |
| 画面との関係 | 画面がなくても使える | 画面が主役で、人が関わる使い方が中心 |
| 位置づけ | オープンソースの標準として公開され、多くのツールが対応 | 草案の段階の提案で、変更される可能性がある |
MCPの接続方式は、草案の説明では主にstdio（標準入出力）やSSE（サーバーからの送信）などが想定されています。一方、WebMCPのツールは、ページを開いたブラウザの中で動くJavaScriptの関数です。この違いが、権限や安全性の考え方の違いにもつながります。
補完関係：裏側はMCP、画面の操作はWebMCP
実務では、「どの操作を、どこで行うか」で分けると迷いにくくなります。
裏側の業務連携はMCP
在庫データの照会や、社内文書の検索のように、画面を介さずに行える処理は、MCPが向いています。サーバー同士のつなぎ込みなので、利用者のブラウザが開いている必要がありません。
画面で行う操作の公開はWebMCP
利用者がブラウザで見ているページの上で、検索や絞り込み、入力の補助をAIに手伝わせたい場合は、WebMCPの出番です。ツールはページ上で見える形で実行されます。利用者は、AIが何をしているかを画面で確認できます。
人の確認が要る操作の扱い
購入や送金のように、取り消しにくい操作もあります。WebMCPの草案には、こうした操作を示す注釈（consequentialHint）があります。ただし、草案は、実行前のユーザー確認を必須とは定めていません。確認を出すかどうかは、クライアント（AI側）の判断に委ねられています。Chromeの資料は、重要な操作では確認ダイアログを出す指示をツールに含められると述べています。確認の設計は、事業者が自分で考える必要があります。
判断の目安：自社はどちらから考えるか
次の表は、フローチャートの代わりに、問いと答えを並べたものです。上から順に当てはめてみてください。あくまで考え方の目安であり、実際の判断は、サービスの内容や体制によって変わります。
| 問い | 答えの傾向 | まず検討するもの |
|---|---|---|
| AIを使うのは誰か（社内の担当者か、サイトの来訪者か） | 社内の担当者や、自社のAIアプリ | MCP |
| サイトを訪れた利用者のエージェント | WebMCP | |
| 画面を開いている必要があるか | 不要。裏側で完結する | MCP |
| 必要。画面の状態を使う | WebMCP | |
| 画面での操作を、AIに手伝わせたいか | はい。検索、絞り込み、入力の補助など | WebMCP |
| いいえ。データの照会や登録が中心 | MCP | |
| ログインが要るサービスか | 要る。社内の認証の仕組みで管理したい | MCPを中心に検討 |
| 要るが、画面上の操作を手伝わせたい | WebMCPを試す前に、認証の扱いを確認 |
ログインの扱いについては、草案は「ページ自身の実行環境で動く」という点までしか述べていません。認証やCookieの扱いが仕様で細かく定義されている、とは読み取れません。一方、Chromeの資料（MCPとの比較のページ）は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。また、MCPは永続的、WebMCPはタブに紐づく一時的なもの、と整理し、最も効果的なのは両方を使う形で、両者は競合ではなくパートナーだとしています。ログインが必要なサービスで試す場合は、事前に検証が必要です。
併用の例（架空の例）
ここでは、架空の例で考えます。ある宿泊予約サイトの運営会社が、AI対応を進めるとします。この会社は実在しません。
- 社内の運用：予約や問い合わせのデータを、社内のAIアシスタントから検索したい。これはMCPで、社内システムとつなぐ。
- サイトの来訪者向け：来訪者のエージェントが、検索画面で条件を入れて候補を絞る。これはWebMCPで、検索のツールを公開する。
- 予約の確定：取り消しにくい操作なので、注釈で示し、画面上で人が最後に確認する流れにする。
このように、同じ会社の中でも、使う人と使う場所によって、手段が分かれます。まずは影響の小さい読み取りの機能から試し、結果を見ながら範囲を広げる進め方が、無理がありません。
よくある誤解
誤解1：WebMCPはMCPの新しい版である
そうではありません。用語と考え方は共有していますが、別の目的で設計された別の仕組みです。MCPの後継、という位置づけの説明は、確認できていません。
誤解2：WebMCPがあれば、バックエンド連携は不要になる
これも違います。草案は、人間向けのUIが主役のままであり、バックエンド連携の代わりではないという位置づけです。裏側の連携が必要な場合は、引き続きMCPやAPIを検討します。
誤解3：もう標準になっていて、どのブラウザでも使える
現時点では、W3Cの標準ではなく、標準化トラックにも載っていません。ChromeではChrome 149からオリジントライアルとして提供されています。他のブラウザの対応時期は、確認できていません。
誤解4：ツールを公開すれば、安全にAIが使ってくれる
草案は、プロンプトインジェクション（ツールの説明や出力に紛れる悪意ある指示）や、宣言と実際の動作が一致する保証がないことなどを、リスクとして挙げています。宣言の内容を検証する手段もまだありません。公開する範囲は、慎重に決める必要があります。
同じ機能を、両方で用意する場合の違い
たとえば「商品を条件で検索する」という機能を考えます。これを両方で用意する場合、設計の観点が変わります。
MCPで用意する場合
サーバー側に検索の処理を置き、MCPのツールとして公開します。AIアプリは、サイトの画面を開かずに、直接その処理を呼べます。画面の状態に左右されない一方、誰がどの権限で呼ぶのかを、サーバー側で管理する必要があります。
WebMCPで用意する場合
ページ内のスクリプトに検索のツールを登録します。来訪者のエージェントが、そのページ上で呼び出します。画面に結果が表示されるので、利用者も内容を確かめられます。ただし、ページを開いているブラウザが前提になります。ツールの名前や説明、入力の形を変えるときは、登録を解除して、登録し直す必要があります。
どちらでも共通すること
ツールの名前と説明は、AIが読んで使い方を判断する材料になります。目的を一文で書き、入力の形をはっきり決めることが大切です。エラーのときは、次に何をすればよいかが分かる返し方にします。これは、どちらの方式でも変わりません。
導入前に確かめたい5つの問い
- AIに使わせたい機能は、画面を介さずに実行できるか。
- その機能を使うのは、社内の人か、サイトの来訪者か。
- 取り消しにくい操作や、個人情報を扱う操作は含まれるか。
- 仕様が変わったとき、直す担当者と予算はあるか。
- 対応していないブラウザや、AIを使わない利用者が、これまでどおり使えるか。
最後の問いは、Chromeの資料が勧める「プログレッシブエンハンスメント」の考え方に近いものです。ツールがあれば使われ、なくても画面から普通に使える、という作りにしておけば、仕様が変わったときの影響を小さくできます。
注意点：仕様の変化と、公開範囲の決め方
最後に、判断の前に押さえておきたい点をまとめます。
- 仕様は変わる：窓口の名前も、初期の資料にあったnavigator.modelContextから、document.modelContextに変わっています。実装は、変更に追従する前提で考えます。
- 宣言的APIの扱い：HTMLのフォームに注釈を付けてツールにする方式は、Chromeの資料では紹介されていますが、W3Cの草案の本文にはまだありません。
- 公開範囲：アクセスはPermissions Policyのtools機能で制御でき、既定は自オリジンです。他オリジンへ見せるときは、明示が必要です。
- 検証の体制：セキュリティや個人情報にかかわる部分は、社内の担当者や専門家に確認してください。
どちらを選んでも、「何を、誰に、どこまで任せるか」を決める作業は残ります。
Otsumuに相談できること
MCPとWebMCPの違いの整理や、公開する機能の洗い出しは、社内でも進められます。まず、自社の機能を「裏側の処理」と「画面での操作」に分けて、一覧にしてみてください。それだけで、どちらから考えるかが見えてくることが多いはずです。
一方で、既存システムとの接続、権限の設計、取り消しにくい操作の扱いなどは、判断が難しい部分です。Otsumuは、AIを前提に事業の構造や業務を組み直す、AIファーストな事業の再構築を支援しています。AIが下書きや実装を担い、人が判断と責任を持つ形で、設計から実装までご一緒できます。
具体的には、AIエージェント開発のご相談をお受けしています。内容が固まっていない段階でも、お問い合わせからご連絡ください。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元：WebMCP仕様草案（W3C Web Machine Learning Community Group）、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料、Model Context Protocol公式サイト。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20