WebMCPを試してみた感想。フロントエンドの必須技術になりそうな予感。

弊社には「Orizm」という自社プロダクトのCMSがあり、現在私はOrizmを用いたWebサイトの開発業務を担当しています。

Orizmには「デザインエディター」という、Webページを見た目そのまま直感的に編集できる機能が組み込まれているのですが、入稿作業をしながら、ふと「ここにWebMCPを組み込んだらより便利になるのでは？」と考えました。

本来は人間が操作するためのGUIツールですが、AIエージェントに「このツールでページを作って」と依頼できるようになれば、入稿や編集作業がもっと楽になりそうですよね。

ということで社内向けツールとして実験的に実装してみることにしました。

WebMCPとは

WebMCPは、Webページ側が「AI向けの操作（ツール）」を直接ブラウザ上に提供するための仕組みです。

従来のMCPとは異なり、サーバー側ではなくフロントエンドにツールを登録するため、例えば以下のようなメリットがあります。

• エージェント側に特別な認証設定が要らず、ブラウザでログインしていればそのまま使える
• サーバーに保存される前の画面上の未保存データでもJavaScriptを介してAIから操作可能

---

WebMCPの定義方法には「宣言型」と「命令型」の2種類があります。

1. 宣言型（HTML属性）

フォーム要素に直接属性を付与する方式です。JavaScriptを書かずに標準的なHTMLフォームをそのままツール化できます。

<form toolname="search_products" tooldescription="製品名で製品を検索する">
  <input name="keyword" toolparamdescription="検索キーワード">
  <button type="submit">検索</button>
</form>

2. 命令型（JavaScript）

JavaScriptで関数を動的に登録する方式です。

document.modelContext.registerTool({
  name: "search_products",
  description: "製品名で製品を検索する",
  inputSchema: {
    type: "object",
    properties: { keyword: { type: "string" } },
    required: ["keyword"],
  },
  async execute({ keyword }) {
    return await searchProducts(keyword);
  },
});

今回組み込む予定のデザインエディターはReact製のアプリであるため、後者の「命令型」を採用しました。

WebMCPは2026年9月現在W3Cのコミュニティグループで議論中の提案仕様であり、Chromeではフラグ付きプレビューおよびオリジントライアルの段階です。ここ数ヶ月の間にも navigator.modelContext から document.modelContext へ変更されるなど、仕様変更が続いているようです。実装の際は必ず最新のドキュメントを確認してください。

セットアップ

検証には Codexのブラウザ操作（モデル：GPT-6 Astra / Effortレベル：中）を使用しました。

（※ChatGPTの内蔵ブラウザは2026年8月25日にWebMCPが利用可能になりました）

https://gihyo.jp/article/2026/08/chatgpt-app-browser-support-webmcp

検証内容

「すでに入稿済みの参考ページを読み取り、デザインエディターで同じデザインで一部内容を編集したページを再現する」というテストを実施しました。

作るページはこちら

（※架空のWebページです）

指示プロンプト（共通）

現在開いているページの作り方を参考にして、デザインエディターで同じデザインのページを組み立ててください。
ヘッダーの見出しには「ちょっと株式会社」、最初のセクションの見出しには「フロントエンドエンジニア募集」というテキストを入力してください。

検証1：WebMCP「なし」の場合

まず、WebMCPを使わずに検証してみました。

実行結果

Codexはまず参考ページ側の画面を自力で操作しはじめました。カーソルを動かし、ドロワーメニューをクリックして開いて、既存のブロック要素の一覧を確認し、各ブロックの設定値を1つずつ読み取っていきます。
その後、別タブの編集画面で操作開始。モーダルを開く → 挿入するブロックを選択 → テキストの入力フィールドを編集する → 次の操作へ…。
と、まさに人間が行なう操作そのものでした。

結果：完了まで 5分52秒

完成品は問題なく再現されていましたし、正直WebMCPなしでもCodexのブラウザ操作だけで十分すごいなと思いました。
ただ同時にやはり人間用のGUIをAIに操作させるのは非効率だとも感じました。
人間にとっては操作し易いものだとしても、AIにとってはボトルネックになっていそうです。

検証2：WebMCP「あり」の場合

次に、デザインエディター側にWebMCPのツールを実装して検証してみました。

実装イメージ

document.modelContext.registerTool() を使い、エディターが内部的に持っている状態変更関数をAIに開示します。

document.modelContext.registerTool({
  name: "insert_block",
  description: "ページにブロックを追加します",
  inputSchema: {
    // ツールに渡す引数の型定義（省略）
  },
  // AIエージェントがツールを呼び出したときに実行される処理
  async execute(params) {
    // ここでエディター内部の既存関数を呼び出す
    const result = await addBlock(params);
    return result;
  },
});

今回は、主に以下のような「読むツール（参照系）」と「書くツール（操作系）」を登録しました。

ツール名	種別	役割
list_blocks	read	今のページのブロックを入れ子の一覧で返す（ID・種類・テキスト抜粋）
get_block	read	1つのブロックの全項目値を返す（変更前の確認用）
get_block_catalog	read	使えるブロック種別・項目名・指定可能な値・既定値を返す
insert_block	write	ブロックを追加する
update_block_props	write	既存ブロックの項目値を更新する
move_block	write	ブロックの配置場所を移動する
remove_block	write	ブロックを削除する
select_block	write	エディター上でブロックをハイライトする（人間へのコンテキスト共有用）
undo / redo	write	直前の操作を取り消す / やり直す

最初は「追加」や「変更」といった操作系ツールだけで十分と考えていましたが、それだとAIは「現在のページ構造がどうなっているか」を把握できません。

list_blocks で現状を把握し、get_block_catalog で仕様を確認してから insert_block を実行する…という「観察→計画→実行」のフローを組めるようにしたことで、AIが正確に動作するようになりました。

実行結果

AIはまず get_block_catalog で利用可能なブロックを確認し、list_blocks で参考ページと編集対象ページの状態を把握。
その後、GUIを一切動かすことなく、WebMCPツール経由で一気にブロックとデータを挿入していきました。

結果：完了まで 3分9秒

最初にページ構造を読み取って思考する時間に大部分を費やしており、実際のページ構築処理自体はすぐに終わりました。

WebMCPなしと比較して約半分くらいの時間短縮になりました。
今回はシンプルなページ構造でしたが、ページが複雑化し構築量が増えるほど、WebMCPの有無による時間差はさらに広がりそうです。

感想

検証後、同僚に社内向けツールとして展開し、試しに使ってみてもらったのですが概ね好評のようでした。

正直Codexのブラウザ操作はかなり優秀なので、フォーム入力などシンプルな操作であればわざわざWebMCPを導入しなくとも問題ないかもしれません。
ただ、今回試したCMS操作のような人間向けに作られた複雑なUI操作が発生する画面においてWebMCPは強力な効果を発揮してくれそうだと思いました。

人間が一切見ない・操作しないAI向けアプリばかりになる未来は正直まだ想像しづらいですが、人間も使うWebアプリにWebMCPを組み込むことは、これからフロントエンドの実装として必須になりそうな予感です。