Google I/O 2026 で発表された WebMCP は、「新しい MCP 標準」として紹介されることがあります。しかし、この表現は正確ではありません。WebMCP はブラウザのタブを実行環境とするプロトコルであり、既存のサーバーサイド MCP とは設計上の前提がまったく異なります。この違いを混同したまま技術選定を進めると、後から取り返しのつかないアーキテクチャ上の問題が生じます。
WebMCP が解く問題の範囲
MCP（Model Context Protocol）とは、AI エージェントが外部ツールを呼び出すための通信規約です。エージェントが「メールを読む」「カレンダーを確認する」などの操作を行うとき、その操作の定義と呼び出し方を標準化するのが MCP の役割です。
WebMCP はこの MCP を Chrome のタブ内に閉じ込めた形で実装したものです。ツールの定義はページ内に存在し、認証にはユーザーが既にログインしているブラウザセッション（クッキーや OAuth トークン）を利用します。エージェントが動作するライフサイクルも、タブが開いている間だけです。
たとえば、ユーザーが社内ダッシュボードを開いた状態で「このグラフを週次レポートに貼り付けて」と指示するような場面では、WebMCP は適切に機能します。ユーザーが画面の前にいることが前提であり、その場の操作を補助するという用途に特化しています。
サーバーサイド MCP とのアーキテクチャ比較
一方、従来のサーバーサイド MCP は stdio または HTTP をトランスポート（データ転送経路）として使い、プロセスとして独立して動作します。認証には API キーやサービスアカウントの認証情報を使い、実行環境はローカルマシン・VPS・コンテナのいずれかです。
両者の設計上の差異を整理すると次のようになります。
- 実行環境: WebMCP は Chrome タブ / サーバーサイドはプロセス（VPS・コンテナ）
- 認証モデル: WebMCP はユーザーのブラウザセッション / サーバーサイドは API キー・サービスアカウント
- 起動トリガー: WebMCP はユーザー操作 / サーバーサイドは cron・webhook・キュー
- ライフサイクル: WebMCP はタブが開いている間のみ / サーバーサイドは常時稼働
- マルチテナント対応: WebMCP は困難（セッションが 1 つ）/ サーバーサイドはプロセス分離で対応可能
シード記事の著者は、Gmail トリアージ・Telegram 通知・請求書生成の 3 つの MCP サーバーを本番稼働させており、1 日あたり 400 回以上のツール呼び出しが発生していると述べています。これらはすべてサーバーサイドの実装であり、ブラウザもユーザーセッションも不要です。
設計判断の軸：「人間がいるか」
アーキテクチャの選定基準は、実はシンプルな問いに集約されます。エージェントが実行される時点で、人間が画面の前にいるかどうかです。
ユーザーがその場で操作している → WebMCP が候補に入ります。フォーム入力の補助や、ページ内データの抽出など、人間の意図をリアルタイムで補強する場面です。
エージェントが自律的に・定期的に動作する → サーバーサイド MCP が必要です。深夜のバッチ処理、webhook をトリガーとした通知、定期レポート生成などが該当します。
サーバーサイドの実装例として、シード記事では以下のような構造が示されています。
# mcp.server と stdio_server を使ったサービス型の実装
from mcp.server import Server
from mcp.server.stdio import stdio_server
from google.oauth2.credentials import Credentials
app = Server("gmail-triage")
creds = Credentials.from_authorized_user_file("/etc/agents/gmail.json")
@app.tool()
async def list_unread(max_results: int = 50) -> list[dict]:
# Gmail API を直接呼び出す。ブラウザセッション不要
...この実装では、認証情報をファイルとして保持し（chmod 600 で保護）、専用ユーザーのプロセスとして systemd に登録します。ブラウザの存在を前提とした設計ではないため、ユーザーがオフラインでも動作を継続できます。
日本の開発現場で馴染みのある構成に例えると、サーバーサイド MCP は従来の「バックエンド API サーバー」に近い位置付けです。WebMCP はいわばサービスワーカー（ブラウザ上で動作する補助スクリプト）に相当し、バックエンドの代替にはなりません。シード記事の著者もこの点を「サービスワーカーをバックエンドと呼ぶようなもの」と表現しています。
技術的負債の観点から見た選定ミスのリスク
WebMCP を「汎用の MCP 実装」として採用してしまった場合、どのような技術的負債が生まれるかを考えてみます。
まず、認証モデルが根本から変わります。ブラウザセッションに依存した設計は、バッチ処理や API 連携への転用が困難です。後から「ユーザーがいないときも動かしたい」という要件が加わった時点で、認証フローを一から再設計する必要が生じます。
次に、可用性の問題があります。WebMCP のライフサイクルはタブに縛られているため、SLA（サービス品質の保証水準）を定義することが難しく、監視やアラートの設計とも相性が悪いです。
マルチアカウント・マルチテナント対応も課題になります。ブラウザセッションは原則として 1 ユーザー分しか保持できないため、複数テナントを扱う B2B サービスでは根本的な制約になります。
技術選定の段階でこれらの非機能要件（可用性・セキュリティ・スケーラビリティ）を整理しておくことで、後工程での設計変更コストを大幅に抑えられます。
WebMCP とサーバーサイド MCP はどちらが優れているかという話ではなく、解決しようとしている問題が異なります。設計判断の起点を「ユーザーの有無」に置き、その答えに合わせてランタイムと認証モデルを選ぶことが、持続可能なエージェント基盤の設計につながります。