メインコンテンツへスキップ

WebMCPの本当の競争相手は何かーーデータ交換、API、MCPから「Agentic Webの思想戦」へ

    滋賀坂本余白書房別館

    ＜２０２６年７月２２日以前のコンテンツ一覧はこちら＞

    ＜クリックすると目で見ている層（レイヤー）とは違う隠れている層（レイヤー）情報が取得できる時代がくるのかも、と思いました＞


    コンピュータの歴史をかなり乱暴に縮めると、一つの長い問いに行き着く。

    「別のコンピュータ、別のプログラム、そして別の主体と、どうやって意味を共有するのか」

    最初はファイルを渡した。次に、決められた形式のデータを交換した。やがてプログラム同士がネットワーク越しに機能を呼び出すようになり、APIが発達した。Webが世界的な共通基盤になるとWeb APIが広がり、クラウド時代にはAPIこそがシステムとシステムをつなぐ標準的な入口になった。

    そして生成AIの時代になり、今度は人間ではなくAIがAPIや外部システムを使おうとする。そこで登場した代表例がMCPである。さらに、その考えをブラウザとWebページの内部にまで持ち込もうとしているのがWebMCPだ。

    ここだけを見ると、データ交換 → API → Web API → MCP → WebMCPという一直線の技術進化に見える。しかし、WebMCPまで来たところで事情が変わった。これは単なる「次の便利な通信規格」の話ではない。

    WebMCPの最大の競争相手は別のAgent Protocolではない。
    最大の競争相手は、「そもそもAgent専用Protocol／Capability PlaneをWebに作る必要があるのか」というWebそのものの思想である。

    分析上の定義：ここでいう「競争相手」は、市場シェアや採用数で客観的に順位づけした競合製品を意味しない。WebMCPがWeb標準・実装として広がる際に競合する設計原理／標準化経路を指す。本稿の中心命題は、この意味での分析フレームである。

    1　データ交換小史――「データを渡す」ことから始まった

    コンピュータ同士が連携する最も原始的な方法は、データそのものを受け渡すことだった。紙テープ、磁気テープ、フロッピーディスク、CSV、固定長ファイルなど、媒体や形式は変わっても基本構造は同じである。一方のシステムがデータを書き出し、もう一方がそれを読み込む。

    そこでは、「何を送るのか」「どの順番で並べるのか」「数字なのか文字なのか」「日付はどの形式なのか」といった約束が必要になる。やがて企業間取引ではEDIのように、注文、請求、出荷などのデータ形式をあらかじめ決めて交換する仕組みが普及した。

    この時代の中心はデータの交換である。相手システム内部で何が起きているのかは基本的に分からない。境界を越えるのは主として「情報」であり、「機能」ではなかった。

    2　API小史――データではなく「機能」を呼び出す

    システムが複雑になるにつれて、単にファイルを渡すだけでは不便になった。そこで重要になったのがAPI、Application Programming Interfaceである。

    APIの本質は、「内部実装を全部知らなくても、決められた入口から機能を使えるようにする」ことにある。顧客番号を渡したら顧客情報を返す。商品番号と数量を渡したら注文を登録する。社員番号を渡したら勤務状況を返す。こうした約束によって、システムAはシステムBのデータベース構造やプログラム内部を知らなくても、公開された入口だけを使えばよくなった。

    データ交換の時代が「このデータを受け取ってください」だったとすれば、APIの時代は「この仕事をしてください」へ進んだのである。

    3　Web APIの登場――世界共通の道路としてHTTPを使う

    そしてインターネットとWebが広がる。ここでAPIはもう一度大きく変わった。専用回線や特定製品固有の通信方式だけではなく、世界中で使われているHTTPをAPIの共通道路として利用できるようになった。

    2000年前後にはSOAPとWSDLを中心としたWeb Servicesが大きく注目された。SOAP 1.1は2000年5月にW3C Noteとして公開され、XMLを使って分散環境で構造化情報を交換する枠組みを示した。WSDL 1.1は翌2001年、ネットワークサービスのendpoint、operation、messageなどを記述する形式として公開された。

    一方、同じ2000年にはRoy Fieldingの博士論文でRESTというWebアーキテクチャの考え方が体系化されている。RESTは単なる「JSON APIの書き方」ではなく、Webを大規模な分散システムとして成立させるための制約群として論じられた。参照先はUCIの正規ホストを用いる。

    その後の実務ではHTTPとURIを使い、比較的単純な形式でJSON等を交換するREST風Web APIが爆発的に普及した。スマートフォンアプリもSaaSもクラウドサービスも、背後ではWeb APIを大量に利用するようになった。

    人間
  ↓
Web画面
  ↓
Webアプリケーション
  ↓
Web API
  ↓
バックエンドシステム

    「Web API」という名称は一つの特定規格を指すものではない。HTTP/HTTPSを使ってWeb上から利用できるAPI群を広く指す言葉であり、その中にREST的API、RPC的API、GraphQLなど多様な方式が存在する。重要なのは方式の名前ではない。Webの下に、機械同士が直接会話する巨大なAPI層が形成されたことである。

    4　API経済――画面の裏側にもう一つの世界ができた

    この結果、現代のWebサービスには事実上二つの世界が存在する。一つは人間が見る画面である。もう一つはプログラムが使うAPIである。

    銀行、物流、EC、決済、地図、ホテル予約、クラウド、SNS、業務システムなど、多くのデジタルサービスの裏側にAPIが存在する。APIは歴史的には、主として人間の開発者が設計したプログラムから呼ばれる入口として普及した。どのAPIを呼ぶのか、どのパラメータが必要なのか、どの順番で実行するのか、失敗したらどうするのか。これらの選択は、基本的に人間の開発者がコードや設定へ組み込んできた。

    LLMが登場すると、この前提が崩れ始めた。AI自身が「この仕事をするにはどの機能を使えばよいか」を判断するようになったからである。

    5　MCP小史――APIをAIが使うための「共通コンセント」

    Anthropicは2024年11月25日、Model Context Protocol、MCPをオープンソースとして公開した。目的は、AI Assistantとデータソース、業務ツール、開発環境などを接続するための共通標準を作ることだった。従来は新しいデータソースごとに個別統合が必要だったことが、MCP誕生の背景として説明されている。

    MCPが全く新しい種類の機能を発明したわけではない。データベースもAPIもファイルシステムも検索もSaaSも以前から存在する。変えようとしたのは、それらとAIとの接続方法だった。

    従来
AI ─ 個別実装A ─ システムA
AI ─ 個別実装B ─ システムB
AI ─ 個別実装C ─ システムC

MCP
AI
 ↓
MCP
 ↓
Tools / Resources / External Systems

    より重要なのは、MCPによって機能の見せ方が少し変わったことである。従来のAPIは、主として人間の開発者が呼出先をコードへ組み込む機能だった。MCPのToolは、LLM駆動のAgentが説明やSchemaを手掛かりに選択候補として扱える機能になる。ただし、実際の選択・実行はクライアントやホストのポリシー、人間承認などによって仲介され得る。

    ここには自然言語によるTool名や説明、Schema、AIによるTool選択、権限、認証、実行結果、誤ったToolを選んだ場合の責任といった問題が入ってくる。MCPは通信プロトコルであると同時に、AIに外界への手足を与える境界でもある。

    6　MCPだけでは「今見ているWebページ」の状態を直接共有しにくい

    MCPはバックエンド専用の仕組みではない。ローカルツール、開発環境、ブラウザ関連用途などにも利用できる。ただし典型的なMCP Server連携では、いま表示しているページのDOM、クライアント側JavaScriptの状態、現在のブラウザSessionそのものが自動的に共通状態になるわけではない。そのため、Web画面とAIが操作する外部機能の状態を別途橋渡ししなければならない場合がある。

    例えば、ユーザーが商品を三つまで絞り込み、特定店舗を選択し、ログイン済みSessionの下で編集途中のデータを持っているとする。外部のMCP Server側からこれらを利用するには、必要な状態を明示的に受け渡す、同じSessionへ接続する、あるいは別のBridgeを用意するなどの設計が必要になる。

    WebMCPのExplainerは、backend MCPやOpenAPIがserver-side actionには適する一方、UI context、state、authenticationの複製やclient-side capability公開に課題があるという問題意識を示している。

    そこで発想が一段変わる。「だったら、今開いているWebページそのものにAI向けToolを持たせればよいのではないか」。これがWebMCPである。

    7　WebMCP――Webページが「機能」を名乗り始める

    WebMCPの仕様案は2025年8月13日に最初に公開された。その後、Google Chromeは2026年2月10日にEarly Preview Programを発表し、さらに2026年6月9日にはChrome 149でOrigin Trialへの参加受付を開始した。したがって、WebMCPについては「仕様案の初公開」「ブラウザでのEarly Preview」「実サイトで試験するOrigin Trial」を区別して読む必要がある。MicrosoftとGoogleの関係者が初期著者として名を連ね、現在はW3C Web Machine Learning Community GroupでDraft Community Group Reportとして開発が続いているが、W3C RecommendationやStandards-Trackの標準として確定したものではない。

    参照: WebMCP repository ／ Chrome Early Preview (2026-02-10) ／ Chrome 149 Origin Trial (2026-06-09)

    名称上の注意：WebMCPという名前でも、WebMCP自体がMCPのwire protocolをWebページへそのまま持ち込む仕様という意味ではない。WebMCPはWeb APIとしてページ上のToolを登録・発見・実行する仕組みであり、MCPとは補完・橋渡しできる。公式Explainerはページを「in-page MCP serverのように考えられる」と比喩する一方、Mozillaは「There is no MCP here」と命名上の混同を指摘している。

    Webページ自身が、「商品を検索できます」「Todoを追加できます」「予約できます」といった機能を、自然言語descriptionとstructured schema付きのToolとしてAgentへ提示する。現在のWebMCPではJavaScriptによるImperative APIと、HTML formを利用するDeclarativeな方向の双方が検討されている。

                   人間
                 ↓
          HTML / UI / DOM
                 ↓
          Web Application
                 ↑
      WebMCP Capability
                 ↑
              AI Agent

    人間とAIが同じページやセッションの文脈を共有しやすくなる。ただし、アプリケーション内部のすべての状態が自動的に共有されるわけではない。画面認識してボタンを探し、「たぶんこの青いボタンが購入ボタンだろう」とAIが推測する必要も減らせる。サイト自身が「購入という機能はこれです」と明示できるからである。

    8　ところがここで、20年以上続いたWebの思想と衝突する

    WebMCPを単なる「MCPのブラウザ版」と理解すると、この先を見誤る。WebMCPの大きな論点は、とくにImperative APIで、既存のHTML／ARIAとは別にAgent向けの明示的Capability層をWebへ設けることにある。一方、Declarative APIは既存のformや可視UIの意味論へ寄せる設計であり、この対立の強さはWebMCP内部でもAPI形態によって異なる。

    従来のWebにはHTMLがある。buttonにはbuttonとしての意味がある。formにはformとしての意味がある。さらにARIAなどによって、スクリーンリーダー等のAssistive Technologyにも意味を伝えようとしてきた。

    WebKitはWebMCPに対し、Agent専用のparallel tool layerを設けるのではなく、HTMLやARIAのようなWeb Platformの共有層を改善し、ユーザー、Assistive Technology、Agentが同じ改善の恩恵を受けるべきだという立場を明確にした。

    ここで議論は単なるAPI設計を超える。AIがWeb画面を理解しにくいのであれば、WebMCP Toolを追加すべきなのか。それともHTMLそのものの意味をもっと豊かにし、AIも人間もAssistive Technologyも同じ意味構造を使うべきなのか。

    明示的なparallel capability layerが広く使われれば、人間向けUIとAgent向け機能面が二層化する可能性がある。共有Semantic層を優先すれば、HTML／ARIAなど共通意味層を強化する方向へ進む。つまり争点はTool APIの名前だけではない。「Webの共通意味層をどこまで維持し、どこからAgent向けCapability層を追加するのか」という境界設計なのである。

    9　WebMCPの最大の競争相手

    WebMCPと競争・補完する技術として、MCP、A2A、UCP、ACPなどの名前を並べることはできる。しかし、それだけでは本質を外している。これらは主として担当する問題層が異なり、一部では重なり合う。

    WebMCPが本当にぶつかっている相手はProtocolではない。Web Architectureである。

    WebMCP側の思想を単純化すれば、「Agentが確実に機能を実行するためには、明示的なCapability Layerが必要だ」となる。反対側を単純化すれば、「WebにAgent専用レーンを作るのではなく、HTMLやARIAなど既存の共有意味層を改善すべきだ」となる。

    これは、Capability WebとShared Semantic Web Platformの主要な対立軸／緊張関係に近い。ただし両者は排他的とは限らず、Declarativeな共有意味論と明示的Tool層が用途ごとに併存する可能性もある。

    推進側にも実務上の定量材料がある。2026年のTAG議論でWebMCP提案側は、Chrome Origin Trialのtelemetryとして、Imperative APIのtool登録イベントが約1.72億回、Declarative APIが約2万回だったと報告した。提案側はこれをImperativeなCapability実装への需要を示す材料の一つと解釈している。ただし、この数字はユニーク開発者数、採用サイト数、Tool実行回数、成功率、利用者の選好を直接示す指標ではない。したがって、明示的Tool層への実装上の強いシグナルではあっても、Webアーキテクチャ上の優劣を単独で証明するものではない。

    ここに標準化戦争の面白さがある。WebKitの正式見解はWebの共有Semantic Layerを重視する。一方、WebMCP提案者（Google／Microsoft関係者）はAgent実装の経験から、明示的Capability Layerの必要性を主張している。これはGoogle社・Microsoft社の包括的な「正式標準化ポジション」を意味するものではない。思想と実装現場の双方に、それぞれ根拠がある。

    10　「製品」で見ると混乱する。「レイヤー」で見る

    ここから先は、Google、Microsoft、Apple、Cloudflare、Shopifyといった会社名だけを追うと分かりにくくなる。同じ会社が複数の層へ同時に進出するからである。見るべきなのは製品ではなくレイヤーである。

    ──────────────────────────
人間・組織・Agentの目的
──────────────────────────
Governance / Policy / Approval / Evidence
──────────────────────────
Identity / Authentication / Authorization
──────────────────────────
Discovery / Verification
──────────────────────────
Agent-to-Agent Coordination
──────────────────────────
Capability / Tool Description
──────────────────────────
WebMCP / MCP / Commerce Protocol / Intent
──────────────────────────
API / Web API
──────────────────────────
Application / Database / Legacy System
──────────────────────────
Network / Compute / Storage
──────────────────────────

    この図にすると、WebMCPがゴールではないことが分かる。WebMCPはCapabilityをWebページからAgentへ公開する層の一候補にすぎない。

    さらに上には、「そのCapabilityはどこにあるのか」「誰が公開したのか」「信用してよいのか」「このAgentに使わせてよいのか」「この操作には人間承認が必要か」「実行後に取り消せるか」「何が行われたかを証明できるか」という問題が残っている。

    11　その先――Discovery Layerが必要になる

    この点で象徴的なのが、Googleが2026年6月17日に発表したAgentic Resource Discovery、ARDである。ARDはWeb上に分散したTool、Skill、Agentなどを公開、発見、検証するためのオープン仕様として提示された。

    MCPやWebMCPにも、接続済みServerや現在のページ内で利用可能なToolを列挙・発見する仕組みはある。ARDが狙うのはその外側で、複数のProtocol、Provider、組織をまたいでResource／Tool／Agentを見つけ、発行者や所在を検証するDiscovery層である。

    Agent向けCapabilityが何百万、何億と存在する世界になれば、Toolそのものより、Toolを発見し、選別し、信用度を判断する層の方が重要になる可能性がある。

    12　さらに横断的にIdentityとGovernanceが必要になる

    しかしDiscoveryでも終わらない。Toolが見つかったとしても、誰が使っているのかが分からなければならない。人間本人なのか、本人から権限を委任されたAIなのか、会社のAgentなのか、外部委託会社のAgentなのか、Agentが呼び出したSubagentなのか。

    ここからIdentity、Credential、Authorization、Delegation、Approval、Policy、Audit、Provenance、Reversibility、Liabilityといった層が必要になる。

    本稿の見立てでは、Agentic Webが成熟するほど、Protocolそのものに加えてGovernanceの比重が高まる。APIの歴史でも、接続方法の普及と並行して、認証、API Gateway、Rate Limit、IAM、監査、Zero Trust、Observabilityなどの管理層が発達した。Agentでも、Identity、Delegation、Approval、Auditなどの横断的管理が重要になる可能性が高い。

    13　WebMCPの先にあるもの

    以下は概念上の積層図であり、時系列や必須依存関係を示すものではない。Identity、Authorization、Governance、EvidenceはAPI時代から存在し、Agent時代に重要性や組み合わせ方が変化する横断層である。

    データ交換
    ↓
API
    ↓
Web API
    ↓
MCP
    ↓
WebMCP
    ↓
Capability Discovery
    ↓
Identity / Delegation
    ↓
Authorization / Policy
    ↓
Approval / Execution Governance
    ↓
Evidence / Provenance

    ただし、これは旧技術が新技術に置き換えられる歴史ではない。ファイル交換はいまも存在する。APIもWeb APIもなくならない。MCPがAPIを消すわけでも、WebMCPがMCPを消すわけでもない。上に新しい意味層が積み重なっていく。

    14　標準化戦争の実例――Shopify、Cloudflare、Mozilla、Apple

    標準化を考えるとき、企業ごとの役割を正確に分けて見る必要がある。

    Shopifyは2026年8月、Liquid storefrontへWebMCP対応を展開した。ただし現時点での実際の利用は、対応するChromium系Origin Trialなどブラウザ側の実装条件に依存する。「全storefrontへコードを展開した」ことと、「全ブラウザ・全Agentで利用可能になった」ことは同義ではない。

    また、Commerce側のUCP（Universal Commerce Protocol）はShopify単独の取り組みではない。GoogleがShopify、Etsy、Wayfair、Target、Walmartなどの業界各社と共同で開発したオープン標準として捉えるのが正確である。決済網との連携も含め、Commerce LayerそのものをAgent時代へ対応させる動きとして見る必要がある。

    CloudflareはWebMCPそのものの規格制定者というより、既存WebとAgent Webの間へ入るCompatibility／Mediation Layerとして重要である。本稿の分析では、規格が一つに統一される場合でも複数方式が併存する場合でも、Edgeで変換・注入・制御する中間層には価値が残り得る。

    MozillaはWebMCPをneutralとし、専用Capability Layerの価値を認めつつ、悪意あるサイト、prompt injection、データ収集、agent tarpit、そしてブラウザベンダー自身のAgentだけが特権的に利用できる閉鎖性を懸念している。ここでは特定製品名ではなく、原文どおり「browser vendors' own products」という問題設定で捉える方が正確である。

    Apple/WebKitには興味深い「ねじれ」がある。WebKitはWebMCPのAgent専用Capability Planeに反対する一方、AppleのネイティブOS世界ではApp Intentsという強力なCapabilityモデルを推進している。ただし、これは矛盾と断定すべきではない。App IntentsではOSがTrust Boundaryを握るのに対し、WebMCPでは任意のWebサイトがCapabilityを公開する。この信頼境界の位置の違いがAppleの判断を分けている可能性がある、という仮説として扱うのが妥当である。

    15　2026年8月上旬――実験APIから「導入・運用レイヤー」へ

    2026年8月上旬の動きは、WebMCPの位置づけをもう一段変えた。重要なのは「新しいProtocolがまた一つ増えた」ことではない。標準仕様がまだ流動的な段階で、CDN／Edge、ブラウザ、既存MCP、フロントエンドライブラリが、WebMCPを実サイトで運用するための周辺レイヤーを作り始めたことである。

    Cloudflareは2026年8月6日、「Give any website a WebMCP interface」と題するDeveloper Previewを発表した。日付は8月10日ではなく8月6日である。Cloudflare上のサイトではDashboardからWebMCPを有効にすると、Origin側のコードを変更せず、EdgeのHTMLRewriterが同一Originのbridge scriptをHTMLへ注入し、そのbridgeがWebMCP Toolを登録する。つまりサイト運営者は、アプリケーション本体を作り直さなくてもAgent向けCapability Planeを後付けできる。

    初期のTool Packには二つがある。一つは画像のC2PA情報を読み出すContent Credentials、もう一つは既存MCP ServerのToolをWebページ上のAgentへ橋渡しするSite MCP Serverである。後者は、訪問者のOriginと既存Sessionを保ったままサイト自身のMCP endpointへ接続する。ここでWebMCPと従来MCPは競合するのではなく、Browser内CapabilityとBackend MCPを接続する上下二層として組み合わされている。

    Provenanceにも重要な但し書きがある。
    CloudflareのContent Credentials Packは、現段階ではC2PA manifestを読み取り、編集履歴・著者・署名証明書などをAgentへ返すが、暗号学的署名の検証まで行うものではない。Cloudflare自身の例でも signatureVerified: false を返す。したがって、「来歴情報を読めること」と「来歴が検証済みであること」は別のレイヤーである。この違いは、Agentic WebにおけるEvidence／Provenance設計でも重要になる。

    Cloudflareのremote browserであるBrowser Run側のWebMCP対応自体は、直近一週間で初めて出たものではなく、2026年4月15日のBrowser Run発表時点ですでに含まれていた。8月6日の新しさは、Agent側のBrowser Runだけでなく、サイト側にもEdgeからWebMCP interfaceを付与できるようになり、「AgentがToolを発見して呼ぶ側」と「WebサイトがToolを公開する側」がCloudflare上で一周つながったことである。

    Microsoft Edgeについても、「フラグで試せるらしい」という段階より一歩進んでいる。MicrosoftはWebMCPの正式なOrigin Trial登録ページを公開しており、試験の期限を2026年11月17日としている。Edge 150のWeb Platform Release NotesにもWebMCPがOrigin Trialとして掲載されている。したがって2026年8月15日時点では、ChromeとEdgeの双方で「標準搭載」ではなく、Opt-inの実サイト試験が進んでいる、と表現するのが正確である。

    さらに周辺OSSも仕様変更を追い始めている。React向けの webmcp-react は現行仕様に合わせ、登録先を document.modelContext へ移し、Tool解除を AbortSignal に一本化し、exposedTo や toolchange を扱うようになった。これは、Toolの公開範囲、生成・破棄、動的変更というCapability Lifecycleの論点が、周辺実装にも現れ始めている一例と読める。ただし、単一OSSライブラリの実装だけからWebMCP全体の標準的方向性を断定することはできない。

    2026年8月上旬に見えてきた構造

Web Site / Existing App
        ↓
Cloudflare Edge Bridge      ← 後付け・変換・配布
        ↓
WebMCP Capability Plane     ← Tool公開・Lifecycle
        ↕
Existing MCP Server         ← Backend機能・既存Session
        ↓
Browser / Browser Run
        ↓
AI Agent

その外側
Identity / Consent / Policy / Provenance / Audit

    この直近動向は、本稿の中心命題を補強する材料になる。競争は「WebMCP対別のAgent Protocol」だけではなく、Webのどの場所にCapabilityを置き、それを誰が後付けし、誰が発見し、誰が認証・承認・監査するのかというレイヤー間の競争としても捉えられる。本稿の分析上、Cloudflareは規格と既存Webを結ぶMediation Layerの代表例として位置づけられる。

    参照: Cloudflare, Give any website a WebMCP interface (2026-08-06) ／ Cloudflare Browser Run (2026-04-15) ／ Microsoft Edge WebMCP Origin Trial ／ Edge 150 release notes ／ webmcp-react

    16　Schemaは「意味の真実」までは保証しない

    WebMCPのToolにはname、description、inputSchema、execute()などがある。Typed Schemaがあれば引数の型や形は制約できる。しかしWebKitが指摘するように、Schemaが保証するのは引数のshapeであって、Toolが宣言した意味と実際の動作が一致することまでは保証しない。

    例えば、著者による単純な例として、Tool名がcancel_subscriptionであっても、その名前だけでは実際のexecute()が契約解約以外の副作用を持たないことまでは証明できない。これはWebKitが示した具体例ではなく、論点を説明するための例示である。

    Typed Schema
      ≠
Semantic Truth
      ≠
Safe Action

    この問題は、Agentic WebがProtocolだけで終わらず、Governance、Verification、Evidenceへ上がっていく理由でもある。

    17　結論――次のWebは「能力」も公開する方向へ向かう可能性がある

    Webの第一世代では情報を公開した。HTMLページを置けば、人間が読みに来た。Web API時代になると機能を公開するようになった。しかしそれを使う主体は主として人間が書いたプログラムだった。

    Agent時代にはさらに一歩進み、Webやシステムが「私は何ができるか」をAgentへ機械可読に公開する方向が強まる可能性がある。DiscoveryやIdentity／Delegationの層が十分に整えば、Agentは複数のCapabilityから必要なものを探し、本人や組織から委任された権限の範囲で実行できるようになる。

    そこでは、ページ、API、Tool、Skill、Agent、Credential、Policy、Evidenceが一続きの構造になる。

    だからWebMCPは重要である。しかしWebMCPそのものを最終地点と考えるのは早い。本稿の見立てでは、WebMCPは、Webが情報だけでなくCapabilityも機械可読に公開する方向へ進む過程で、共有Semantic層とAgent向けCapability層の境界問題が大きく表面化した場所と位置づけられる。

    本稿の分析上、WebMCPの最大の競争相手は別のAgent Protocolではない。
    競争相手は、「そもそもAgent専用Protocol／Capability PlaneをWebに作る必要があるのか」というWebそのものの思想である。

    18　今回作成したExcelについて

    本稿に対応するExcel群は、この問題を製品比較ではなくレイヤー比較として読むために作成している。

    一つ目は、テキスト、CSV、XML、JSONなどを扱うデータ形式史である。二つ目は、データ交換、API、Web API、MCPまでを追うWebMCP以前の技術史である。三つ目が、Google、Microsoft、Apple/WebKit、Mozilla、Shopify、Cloudflareなどを中心に、Capability Layer、Discovery、Identity、Authorization、Governanceまで含めて比較するWebMCP／Agentic Web標準化戦争アトラスである。

    三冊を続けて見ることで、技術史と概念上のレイヤーは次のようにつながる。ただし、これは厳密な時系列や必須依存関係を示すものではない。IdentityやGovernanceはAPI時代から存在しており、Agent時代に再編・強化される横断層として読む。

    データ形式
    ↓
データ交換
    ↓
API / Web API
    ↓
MCP
    ↓
WebMCP
    ↓
Discovery / Identity / Governance / Evidence

    重要なのは、WebMCPの勝敗だけを予測することではない。Agentic Webのどのレイヤーが標準化され、どのレイヤーが複数方式のまま残り、誰が「能力・発見・権限・実行・証拠」の各制御点を握るのかを追うことである。

    主要参照先

    参照日：2026年8月15日。標準化状況・Origin Trial・製品実装状況は今後変更される可能性がある。


    ＜質問＞
    それではWebサイトの画面をクリックすると見た目の情報とは違う隠れた情報が取得できるような時代がくるのではと感じました。

    ＜AI回答＞Webサイトの画面をめくる未来――WebMCPから考える透明なWeb

    はい。まさにそこまで行く可能性があります。しかも「隠れた情報」というより、人間には普段見せていない“機械向けの意味・能力・状態”を、必要なときだけ見せるWebになっていくのだと思います。

    今のWebページは、ざっくり言えばこうです。

    人間が見る層
画面・文字・ボタン・画像
        ↓
ブラウザが持つ層
HTML / DOM / ARIA / 属性
        ↓
システムが持つ層
API / JSON / 認証状態 / 業務データ

    WebMCPのような考え方が加わると、その間にもう一枚、

    Agentが読むCapability層
「この画面では何ができるのか」
「何を入力すればよいのか」
「実行すると何が起きるのか」

    が入ってきます。

    だから将来、ある商品画面で「購入」ボタンをクリック、あるいはAIにポイントして、

    このボタンについて詳しく教えて

    と聞いたら、表面には単に

    「購入する」

    としか書いていないのに、裏側では例えば、

    Action: create_order

必須入力:
- product_id
- quantity
- shipping_address

前提条件:
- ログイン済み
- 在庫あり

副作用:
- 注文を作成する
- 決済処理へ進む

取消:
- 決済確定前まで可能

必要権限:
- 本人による購入権限

実行主体:
- 現在ログイン中の利用者

提供元:
- ○○株式会社

最終更新:
- 2026-08-14

    のような情報をAgentが読める世界は十分考えられます。

    これはかなり面白い変化です。

    「画面を見る」から「画面の意味を見る」へ

    従来のWebでは、人間が画面を見て意味を推測します。

    「これは購入ボタンだ」
    「ここへ住所を書くんだ」
    「この操作をすると注文されるらしい」

    AIも現在はかなりの部分を同じように推測しています。

    ところがCapability Layerができると、

    推測する必要がなくなる。

    画面の裏側に、

    私は購入操作です
    この3項目を受け取ります
    実行すると注文が発生します

    と書かれている。

    つまりWebが、

    見た目のWeb

    から

    意味のWeb

    さらに

    行為のWeb

    へ進むわけです。

    そしてユーザーがおっしゃった「クリックすると隠れた情報が取得できる」という発想は、かなり重要だと思います。

    私は将来的に、ブラウザに現在の「ページのソースを表示」「検証」のようなものとは別に、

    「この要素の意味を見る」

    という機能が出ても不思議ではないと思います。

    例えば右クリックすると、

    このボタンの意味
このボタンが呼ぶCapability
入力項目
出力
必要な権限
外部送信先
取り消し可能性
データ提供元
AIが利用可能か

    まで見える。

    これは開発者向けDevToolsではなく、普通の利用者向けのSemantic / Capability Inspectorです。

    かなり面白い未来です。

    さらに進むと「Web版のレントゲン」になります

    例えば航空券のページで価格をクリックする。

    表面には、

    東京 → パリ　148,000円

    としか見えない。

    しかし「意味を見る」と、

    基本運賃      93,000円
燃油費        31,000円
税金          18,000円
販売手数料     6,000円

払い戻し      条件付き
変更          有料
荷物          23kg × 1
価格有効期限   10分
価格提供元     Airline API
取得時刻       10:31:42

    まで出る。

    金融商品なら、

    表示利率
実質利率
手数料
リスク区分
根拠データ
更新日時

    ニュースなら、

    記事本文
引用元
一次資料
更新履歴
AI生成部分
編集者
C2PA/来歴

    まで開ける。

    要するに、

    Webページの表面をめくる

    感じです。

    これは以前議論したProvenanceやEvidence Networkとも非常に近い方向になります。

    そして私はここで一つ大きな分岐があると思います。

    現在までは、

    機械向け情報は人間から隠れていてもよい

    という設計が普通でした。

    しかしAIエージェント時代には逆に、

    AIが何を見て、何を根拠に、何を実行できるのかを人間も確認できなければならない

    となる可能性があります。

    つまりAgent Capability Planeは、完全な「裏側」ではなく、

    必要なら人間にも展開表示できる半透明な層

    であるべきかもしれません。

    私はこれをかなり重要な設計原則だと思います。

    Visual Layer
人間が普通に見る画面
        ↓
Semantic Layer
HTML / ARIA / structured data
        ↓
Capability Layer
何ができるか
        ↓
Policy Layer
誰が、どの条件でできるか
        ↓
Evidence Layer
なぜそう判断・実行したか

    そしてユーザーが画面上の一点を指すと、

    この5層を縦に貫いて見る。

    たぶんこれが、今の議論のかなり先にあるWeb像です。

    WebMCPはその完成形そのものではなく、「Webページには人間向け画面とは別に、機械が理解できる行為の意味が必要なのではないか」という扉を開き始めた技術、と考えると非常に面白いです。

    そして皮肉なことに、ここまで進むとWebKit側の「Agent専用の裏Webを作るな」という懸念も、かなり重くなってきます。機械だけが見える情報を増やすのか、それとも人間も必要ならその意味層を覗ける“透明なWeb”にするのか。

    たぶん次の本当の論点はここですね。

    あなたへのおすすめ