2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～
@ichiken26(ichi ken)

CloudflareのWebMCPの何が「やばい」のか

2
Posted at

CloudflareのWeb MCPは間違いなくパラダイムシフトの1つである。
2026年8月6日、Cloudflareから「WebMCP」というなかなか面白い機能がDeveloper Previewとして公開された。

今回はこの内容を自分なりにかみ砕いて説明する。

最近MCPという言葉自体はかなり聞くようになったが、

「WebMCPって普通のMCPと何が違うんや？」
「WebサイトがMCPになるってどういうことや？」

と思った人もいるのではないだろうか。

自分も最初に発表を見たときは、
「Cloudflare通してるWebサイトが勝手にMCP Serverになるってこと？」
くらいの理解であった。

しかし、調べてみるとそんなものではなかった。まさにパラダイムシフトと評すべきものである。

そして個人的には、単なるCloudflareの新機能というより
「Webサイトの作り方そのものが大きく変わる可能性のある技術」
ではないかと思う。

今回はWebMCPとは何なのか、Cloudflareが何をしたのか、そしてこれが普及するとWeb開発がどう変わるのかをまとめる。

現在のWebサイトについて

そもそも今のWebサイトは「人間が操作する」前提で作られている。
例えばタスク管理アプリなら、

  1. タスク名を入力する
  2. 「追加」ボタンを押下する
  3. 「タスク一覧に追加される」というUIが表示される

AIエージェントがこのWebサイトを操作しようとすると、基本的にはこの人間向けUIをAIが頑張って操作することになる。

AIが以下のようなスクレイピング的操作をするということである

  1. ページを見る
  2. DOMや画面を解析
  3. 「これはタスク入力欄っぽい」
  4. 文字を入力
  5. 「これは追加ボタンっぽい」
  6. クリック操作

最近のブラウザエージェントはかなり賢くなっているので、これでもそれなりに動く。

しかし、よく考えるとかなり回りくどい。

AIがやりたいことは単純に、

createTask({
  title: "Cloudflareについて調べる"
})

これだけだ。わざわざ人間用の入力フォームを探してクリックする必要はない。

WebMCP

ここでWebMCPの登場である。
WebMCPは、Webサイト側が

「このサイトではAIからこういう操作ができるで」

というToolをブラウザに公開できる仕組みである。

現在Chrome 146で実験的に提供されており、ページ上には document.modelContext というAPIとして現れる。

例えばタスク管理アプリなら、

get_tasks
create_task
update_task
complete_task

というToolを公開する。

するとAIエージェントは、

  1. 画面を見る
  2. 入力欄を探す
  3. 文字を入力する
  4. ボタンを探す
  5. クリックする

のではなく、

  1. create_task
  2. { title: "Cloudflareについて調べる" }

と直接アプリを操作できる。

つまりWebサイトに

人間向けには「HTML / CSS / JS によるUI」
AI向けには「WebMCP Tools」

という2つのインターフェースを持たせることができる。
これがWebMCPのかなり重要なところだろう。

普通のMCPとは何が違うのか

ここで「それ普通のMCP Serverでよくね？」と思うかもしれない。

通常のMCPはざっくり、

Claude / ChatGPT / Codex
        ↓
    MCP Server
        ↓
    Application

という構造になる。

対してWebMCPは、

AI Agent
    ↓
Browser
    ↓
document.modelContext
    ↓
Web Application

となる。

つまり
「今ブラウザで開いているWebサイト自身がAIにToolを公開する」
というところが大きく違う。サーバーサイドではなくクライアントサイドで動いているのだ。

認証について

特に面白いのが認証である。

例えばユーザーがタスク管理アプリにログインしているとする。
そのブラウザ上で動いているAIなら、WebMCP経由でそのユーザーのセッションを利用した操作ができる。
CloudflareのSite MCP Server Packも、サイト自身のMCP endpointをsame-originで呼び出し、訪問者の既存セッションを利用する構成になっている。

これによって、

ユーザーが「今日のタスク教えて」と言ったことをAIに指示すると
AIがget_today_tasks()を実行し、タスク管理アプリのクライアントサイドが「ログイン中ユーザーのタスク」を返す。

AIが「今日はこの5件が期限やで」といったことができる。

じゃあCloudflareは今回何をしたのか

WebMCPそのものはCloudflare独自規格ではない。先ほども述べたようなChromeの実験搭載機能である。

今回Cloudflareがやったのは
「既存のWebサイトを簡単にWebMCP対応させるためのBridgeを作った」
というものだ。

Cloudflare DashboardからWebMCPを有効にすると、CloudflareはHTMLを配信するときにHTMLRewriterを使ってBridge Scriptを挿入する。

イメージとしては、

ユーザー(クライアント)
↓
Cloudflare Edge
↓
元のHTML + WebMCP Bridge
↓
Browser
↓
document.modelContext

となる。

重要なのは、「Origin側のコードを変更する必要がない」ということだ。

静的サイトでもSPAでも同じように動く。
まさにエッジコンピューティングサービスを提供しているCDNの会社Cloudflareらしいといえるだろう。

「Webサイト側の改修が必要なくね？俺らがEdgeで挟んでやればええやん？」という発想だ。
具体的にはサイトのHTMLに

<script src="/.webmcp/bridge.js">

を挟み込みdocument.modelContext.registerTool(...)でWebページからエージェントにツールを公開してくれる。

ではスイッチをONにしたら何でもAIから操作できるのか？というとそうではない。

例えば自分でタスク管理アプリを作って、

Cloudflare WebMCPをONにしたからと言って、AIが「ほーんこれはタスク管理アプリやんね」と解釈して

search_tasks()
create_task()
delete_task()

と言った関数群が生えてくるわけではない。

Cloudflareがアプリの仕様を解析して、CRUD操作を勝手にTool化してくれるわけではないのだ。
現時点のDeveloper Previewでは「Tool Pack」という形で機能が提供されており、最初から用意されているのは主に

  1. Content Credentials Pack
  2. Site MCP Server Pack

の2つである。

Content Credentials Packはページ内画像のC2PAメタデータを調べるためのものである。
つまり、「この画像はAdobe Illustratorで作られたんやな」といった来歴情報を認識できる。

Site MCP Server Packは、サイトが既に持っているMCP ServerのToolをWebMCPへ橋渡しするものである。

つまり自作タスク管理アプリなら、

search_tasks
get_task
create_task
update_task
delete_task

といったアプリ固有の操作は、自分で設計する必要がある。

Cloudflareがやってくれるのは、そのToolをブラウザAIから使えるようにするためのBridge部分である。

実例を交えて

タスク管理アプリを公開するものとしよう

例えばCloudflare Workers + D1でタスク管理アプリを作ったとする。
※補足:
Workersはエッジサーバー上で動作し、静的サイトの配信やAPIなどのバックエンド処理を動かせるサーバーレス実行環境,
D1はSQLite互換のサーバーレスSQLデータベースである

Nuxtを使って実装するとしよう。構成は以下のよう

Nuxt
  ↓
Cloudflare Workers
  ↓
D1

ここにMCPを追加する。

Nuxt
  ↓
Cloudflare Workers
  ├─ REST API
  ├─ /mcp
  ↓
D1

そしてMCP Serverから、

search_tasks
get_task
create_task
update_task

を公開する。

Cloudflare WebMCPを有効にすると、

        ┌──── User ─────┐
        ↓               |
        UI              │
        ↓               │
    Workers REST API    │
        ↓               │
        D1              │
        ↑               │
    Workers /mcp        │
        ↑               │
Cloudflare WebMCP Bridge│
        ↑               │
document.modelContext   │
        ↑               │
    Browser Agent ──────┘

という構造にできる。

すると例えばブラウザAIに「Cloudflareについて調べるタスク登録してたっけ？」と聞く。

AIは、

search_tasks({
  query: "Cloudflare"
})

を呼ぶ。

タスク管理アプリが、

[
  {
    "title": "Cloudflareについて調べる",
    "status": "todo"
  }
]

を返す。

そしてAIが「これじゃね？」と答える。

つまりAIを自分のアプリに組み込んでいないのに、AIからアプリを操作できる。

「MCP Serverさえ用意しておけば、WebMCP対応のためのフロント改修をほぼせずにBrowser AgentへToolを公開できるのである」
ここが個人的にWebMCPで一番面白いと思ったところである。

「アプリにAIを入れる」から「AIがアプリを使う」へ

ここ数年、WebサービスへのAI導入というと、

Web Application
    ↓
OpenAI API
Gemini API
Claude API

という構成が多かった。

つまり「自分のアプリの中にAIを入れる」という考え方である。

WebMCPは逆である。

AI Agent
   ↓
Browser
   ↓
WebMCP
   ↓
Web Application

つまり、「ブラウザ上のAI AgentがWeb Appを使う」
LLMの実行主体がWebアプリ側からBrowser Agent側へ移るのだ。

ユーザーが普段使っているAIエージェントから、そのままWebサービスを利用できる。
例えばタスク管理アプリなら、
「今日のタスク整理して」
だけで

get_tasks()
↓
AIが優先順位を考える
↓
update_task()

ということも可能になる。

予約サイトなら「8月10日の19時から渋谷で2人で入れる店探して」と指示すれば

search_restaurants()
get_availability()
create_reservation()

という操作ができる。

ECサイトなら

search_products()
get_product()
add_to_cart()

などを公開できる。

AIがDOMを解析してボタンをクリックする必要がなくなる。UI操作でトークンを消費することがなくなるのだ。

より詳しく図解

API・UI・MCP・WebMCPの4分類が登場人物である。こう考えるとかなり分かりやすい。

今までWebアプリには大きく、

人間が使う「UI」
プログラムが使う「REST API / GraphQL」
の2種があった。

最近はAIにとってのわかりやすい説明書たる「MCPサーバー」が出てきたのでこれを加えて3種類。
ここに、WebアプリにおいてはAI Agentが使う入口として「WebMCP」が増える。
ただし、Chrome公式が「WebMCP is not an extension or a replacement of MCP.」というようにWeb MCPはMCPサーバーの拡張でも置き換えでもない。
Web MCPは「サイトを開いているときだけ使えるAI用インターフェース」でMCPサーバーは「アプリ外からいつでも利用できるAI用インターフェース」である。

つまり、ユーザーがアクセスしたときに動く範囲として

    Web App
┌───────┼───────┐
↓       ↓       ↓
Human Program Agent
↓       ↓       ↓
UI     API    WebMCP

という構造である。

WebMCPが普及した場合、Webサービスを作るときに、

「画面どうする？」
「APIどうする？」

だけではなく、

「Agentには何のToolを公開する？」

という設計が入ってくるということだ。

Web MCPには何を置く？

そして個人的にここはかなり重要だと思っている。

WebMCPでは、AIに何をさせるかをサイト側が決められる。

例えばタスク管理アプリなら、

get_tasks       → 公開
create_task     → 公開
complete_task   → 公開

delete_task     → 要確認
delete_all      → 公開しない
export_all_data → 公開しない

といった設計ができる。

AIにDBを直接触らせるわけではない。
あくまで、サイト側が許可したToolだけをAIに渡す。

なので今後WebMCPが普及した場合、

「AI対応するかどうか」

だけではなく

「AIにどこまで権限を渡すか」

という設計がかなり重要になりそうである。

特に削除、購入、送信、公開などの不可逆操作については、人間による確認をどう挟むかというUX設計も必要になってくるだろう。

AIクローラーとの違いも面白い。
Cloudflareが今回かなり強調しているのがこの部分である。

現在の生成AIでは、

Webサイト
↓
Crawler
↓
AI企業のサーバー
↓
LLM
↓
ユーザー

という構造になることが多い。
サイトの情報だけ取られて、ユーザーは元サイトに来ない。

WebMCPでは、

ユーザー
↓
Browser AI
↓
WebMCP
↓
Webサイト

となる。

つまりAIがサイトの公式な入口を使ってサイト自身とやり取りする。
Cloudflareも、従来のクローラーがコンテンツをサーバーへコピーし、元サイトにトラフィックやクレジットが十分戻らない問題を今回の発表で明確に挙げている。

AI時代のWebについて「AIにクロールさせるか、させないか」ではなく
「AI用の正式なインターフェースを提供する」という第三の選択肢が出てきたとも言える。

ただしまだかなり実験段階、、

ここまで書くとすぐにでもWebMCP対応した方が良さそうに見えるが、まだそこまでではない。

現状WebMCPはChrome 146で実験的に提供されている段階であり、Cloudflareの機能についてもDeveloper Previewである。
仕様も今後変わる可能性がある。

そのため「今後すべてのWebサイトがWebMCP対応する」とまで言うのは早い。
が、「Webサイトが人間だけではなくAI Agentから操作されることを前提にする」という考え方自体はかなり面白い。

まとめ

今回のCloudflare WebMCPについて調べてみたが、最初に思っていた

「Cloudflareがサイトを勝手にMCP化してくれる」

というものではなかった。

正確には

「Webサイトが持っているAI向けToolを、ブラウザAIから利用しやすくするBridgeをCloudflareがEdgeから後付けできるようにした」

というものであった。

そして個人的に面白いと思ったのはCloudflareの機能そのものより、

人間用には「HTMLベースのUI」
プログラム用には「REST API / GraphQL」
AIエージェント用には「WebMCP」

という考え方である。

これまではWebサービスにAIを導入するとき
「どうやって自分のアプリにAIを組み込むか」
を考えることが多かった。

しかしWebMCPのような仕組みが普及すると
「どうやってAIから使いやすいアプリを作るか」
を考えるようになるかもしれない。

数年後、Webアプリの設計レビューで

「この画面のUIどうする？」
「APIはこれでいい？」

に加え

「ところでAgent Interfaceどうする？」

という会話を普通にしている可能性もある。
まだDeveloper Previewではあるが、個人的には今後を追っておきたい技術の一つである。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?