WebMCPで変わるWeb操作 — Codex「Site tools」の仕組み・使い分け・導入手順

WebMCPを検討するとき、最初に確認すべきなのは「新しい仕組みだから導入するか」ではありません。確認すべきなのは、ユーザーが開いているWebページ上の操作を、Agentにどこまで安全に任せたいかです。

WebMCPでは、Webアプリ自身が compare_items、inspect_chart_data、stage_replacement のような操作を構造化ツールとして登録できます。Agentはボタンの位置や複数画面の手順を推測する代わりに、サイトが定義した名前・説明・JSON Schemaに従って操作します。

導入判断を先にまとめると、次の通りです。

• 現在表示しているページを人とAgentが一緒に操作するなら、WebMCPを試す価値がある。
• バックグラウンド処理や複数システム連携は、従来のMCPを優先する。
• WebMCPに対応していないサイトには、ブラウザ自動化やComputer Useが必要になる。
• 最初の実装は、業務フロー1つ・読み取り専用ツール1個で十分である。

本記事は2026年8月31日時点のOpenAI、WebMCP草案、Chrome公式資料を基準にしています。WebMCPは実験段階であり、対応モデルやブラウザ実装は変更される可能性があります。

最初に整理する：WebMCPは提案、Site toolsはOpenAIの実装

「CodexがWebMCPを発表した」と説明すると、技術の位置づけを誤ります。

WebMCPは、W3C Web Machine Learning Community Groupで検討されている実験的なWeb API提案です。現在の文書はDraft Community Group Reportであり、WebMCP草案にはW3C StandardでもStandards Track上の仕様でもないことが明記されています。

一方、Site toolsはOpenAIによるWebMCPの実装名です。OpenAIのSite toolsドキュメントによると、ChatGPTデスクトップアプリ内のブラウザでChatGPT WorkとCodexがページ登録ツールを検出し、現在のログイン済みセッションと画面状態を共有しながら利用します。

導入前に、次の3点を分けて確認してください。

WebMCP        : オープンな実験的API提案
Site tools   : OpenAI製品におけるWebMCP実装
Codex / Work : Site toolsを検出・実行するAgent側の製品

この整理が必要な理由は、草案の全機能とOpenAIの対応範囲が一致しないためです。2026年8月31日時点で、OpenAIはGPT-5.6 SolとTerraでの利用を案内し、LunaではWebMCPを無効化しています。最新デスクトップアプリが必要で、EnterpriseとEduワークスペースは対象外です。これはWebMCP全体の制約ではなく、OpenAI実装の現在の条件です。

UIを推測する操作から、Webアプリが宣言する操作へ

従来のブラウザAgentも、スクリーンショットだけを見ているわけではありません。DOM、アクセシビリティツリー、セレクター、画像認識などを組み合わせて操作できます。それでも、画面上の部品から「このサイトでは何が正式な業務操作なのか」を推測する必要があります。

WebMCPは、この推測部分をWebアプリ側の宣言に置き換えます。登録ツールには、少なくとも次の情報があります。

1. 操作目的が分かるツール名
2. 副作用を含む自然言語の説明
3. 受け付ける入力を制限するJSON Schema
4. 既存アプリの処理につながる実行関数
5. ユーザーが結果を確認できる構造化レスポンス

例えば、Agentが価格フィルター、在庫チェック、カテゴリ選択を順番に操作する代わりに、ページが search_products を公開できます。編集画面では、即時保存を許可せず、stage_replacement で差分だけを作り、ユーザーがレビューしてから確定する設計にできます。

ここで得られる利点は4つです。

• 検出可能性： ページを訪れたAgentが、サイトの許可した操作を確認できる。
• 入力制約： JSON Schemaで型、必須項目、列挙値、余分なプロパティを制御できる。
• 状態共有： 現在の選択、編集中の文書、キャンバス、ログイン状態を同じ画面で利用できる。
• 結果確認： ID、件数、変更要約、差分を返し、「何が起きたか」を人が検証できる。

ChromeのWebMCPガイドは、クリック操作を推測するより予測可能な経路として説明しています。Google Cloud Techの実装例（02:52）では、ツール名・説明・Schemaを登録する流れを確認できます。ただし、動画で語られるToken削減効果は共通ベンチマークではないため、自社タスクで測定する必要があります。

MCP・ブラウザ自動化・Computer Useとの使い分け

比較するときは「どれが最も新しいか」ではなく、処理がページに属するか、ページを閉じても続く必要があるかを確認します。

手段	提供元	動作範囲	強み	制約	適した用途
WebMCP	現在のWebページ	開いているページとセッション	UI、認証状態、構造化操作を共有	サイト側の実装が必要。ページを閉じると利用不可	検索、編集、診断、フォーム、レビュー
MCP	ローカルまたはリモートサーバー	ページから独立	バックグラウンド、複数システム、長時間処理	接続、サーバー、権限設計が別途必要	DB、リポジトリ、社内システム、API連携
ブラウザ自動化	自動化クライアント	アクセス可能なWebページ	サイトが未対応でも操作可能	UI構造やセレクター変更の影響を受ける	テスト、収集、既存サイト操作
Computer Use	汎用操作モデル	Webとデスクトップ	APIがないGUIにも対応	操作経路が長く、制約しにくい	レガシーソフト、汎用GUI作業
製品内Agent	製品開発チーム	単一製品	UXとモデルを全面的に設計可能	各製品がAgent基盤を個別に構築	高頻度の専門業務

確認順はシンプルです。

1. 現在の画面を人とAgentが一緒に確認するか → WebMCP
2. 画面を閉じても処理を続けるか → MCP
3. 対象サイトを変更できないか → ブラウザ自動化
4. Web以外のGUIも操作するか → Computer Use
5. 専用会話UIや独自モデル選択が製品価値か → 製品内Agent

ChromeのWebMCPとMCPの比較も、両者を置き換えではなく補完関係として説明しています。実務では、MCPがバックエンドデータを扱い、WebMCPが開いているダッシュボードでの確認を担当し、未対応サイトをブラウザ自動化が補う構成が自然です。

導入効果が見えやすい業務フロー

候補業務を選ぶときは、次の3条件を満たすものを優先します。

• ユーザーがすでに対象ページを開いている。
• 入力を小さなSchemaで表現できる。
• 実行結果を画面またはレスポンスで確認できる。

優先度が高い例

検索・比較： 商品、SaaSプラン、在庫、社内ナレッジの条件を構造化し、候補と判断材料を返す。

複雑なフォーム： サポート依頼、出張申請、イベント登録、設定ウィザードを、単なる入力欄ではなく業務単位のツールにする。

文書・キャンバス編集： 文書、Notebook、図表、設計ツールでAgentが変更案を作り、人が同じ画面で差分を確認する。

診断： 環境情報、設定、状態、安全なログ要約を読み取り専用で収集し、問い合わせ内容を整える。

プレビューと承認： 設定生成、カート作成、投稿下書きまではAgentに任せ、購入、公開、送信、削除は人が確定する。

専門アプリ： ゲーム、シミュレーター、アーキテクチャ図、データ可視化の意味を、キャンバス解析ではなく専門操作として公開する。

Chrome公式資料では、旅行計画、構造化フォーム、複雑な日時選択、開発者向け診断、zaMakerやLe Petit Bistroなどのデモが紹介されています。ただし、静的な記事ページやバックグラウンド一括処理までツール化する必要はありません。

見送る条件

• ページ上に価値のある操作がない。
• タブを閉じた後も処理を継続する必要がある。
• 管理できない複数の外部サイトを横断する。
• 認証・認可・サーバー側検証が未整備である。
• 成功指標がなく、「WebMCP対応」自体が目的になっている。

WebMCPは、訪問前のサイトをAgentが必ず発見する仕組みではありません。API、構造化データ、アクセシビリティ、人向けUIを置き換えるものでもありません。

盛り上がりと未解決課題を分けて見る

2026年8月31日時点で、WebMCPリポジトリには約3.6k stars、235 forks、107 issuesが表示されています。開催中のWebMCP Challengeは4,355人の参加者を表示しています。注目度を示す数字ではありますが、実運用サイト数や投資対効果を示す数字ではありません。

肯定的な反応は、次の3点に集約できます。

1. 専門操作なら、画面部品を探すより短い経路で実行できる。
2. Schemaにより、自然言語からフォームへ転記する際の曖昧さを減らせる。
3. 同じ画面状態を共有するため、Agentの処理を人が理解しやすい。

コミュニティでは、GeoGridに専門操作を追加して数秒でタスクを完了したという報告や、WordPress abilitiesをツールとして公開するプラグインが共有されています。GeoGridの議論は実装可能性を示しますが、速度を一般化できる比較試験ではありません。

一方、慎重な意見も確認する必要があります。

• PlaywrightはDOMやアクセシビリティツリーも利用できるため、「従来は画像だけ」という比較は不正確。
• サイト運営者の実装コストに対して、需要がどこまであるか未確定。
• Agentがページを訪問するまでツールを発見できず、ディレクトリの必要性も未合意。
• Agentの識別、同意、監査、第三者スクリプトによるツール登録など、安全面が発展途上。

ブラウザ自動化との比較に関する議論と発見方法に関する議論を見ると、コミュニティの結論はまだ一方向ではありません。現時点の評価は「試作する価値は高いが、全面採用を判断するデータは不足している」です。

実例から分かる設計パターン

参考になる実装は、Agentにすべてを任せていません。繰り返し可能な操作と、人が判断すべき境界を分けています。

Runme：評価NotebookをCodexと共有する

OpenAIは、オープンソースのWeb NotebookであるRunmeを使い、反復的なモデル評価作業をCodexに支援させています。Codexは目標を読み、計画を作成し、人の承認を待ってから評価を実行し、コマンド、失敗経路、判断を記録します。

Runmeはクライアント側のWebアプリです。同じページ操作のためだけにMCPサーバーを作ると、バックエンドと別のデータ経路が増えます。WebMCPでは、説明の読み取り、制限付きJavaScript実行、Notebook更新、ドキュメント参照をブラウザ側ツールとして登録できます。OpenAIのRunme事例で重要なのは、計画と高影響の判断を人が維持している点です。

AgentMarkup Studio：Agent編集と決定論的生成を分離する

AgentMarkup Studioは、同じメモリ上の草稿を編集する8個のツールを登録し、決定論的コンパイラーで llms.txt、robots.txt、JSON-LD、Agent Cardなどを生成します。

Agentが公開サイトを直接変更するのではなく、元に戻す、リセットする、ダウンロードする操作は人に残しています。モデルは構造化編集、通常コードは生成と矛盾チェック、人は最終適用という分担です。

Edgeとコミュニティの試作

CloudflareのDeveloper Previewは、同一オリジンbridgeをEdgeで挿入し、ツールパック、C2PAスキャナー、既存MCP機能のブラウザセッションへの代理公開を試しています。Cloudflareの発表は既存サイトの改修負担を減らす可能性を示しますが、すべてのCloudflareサイトに標準提供される機能ではありません。

ほかにも、ゲーム操作、WordPress連携、ブラウザ内コードワークスペースが作られています。コードワークスペースでは、Agentが検索・読み取り・正確な置換のステージングを行い、ユーザーがdiffを確認します。共通するのは「Agentが限定操作を担当し、不可逆な確定操作は人が担当する」という設計です。

各種Agentツールの比較（10:03）はAPI、MCP、Computer Use、WebMCP、製品内Agentの発想を比較する材料になります。ただし動画内でも実験段階であることが認められており、対応状況は公式資料で確認してください。

導入は読み取り専用ツール1個から始める

最初から多数のツールを作ると、説明の競合、権限ミス、保守対象が増えます。次の順序なら、少ない実装で価値とリスクを確認できます。

導入チェックリスト

1. 業務を1つ選ぶ： 注文状態の確認、選択商品の比較、診断情報の要約など、既存ページで行われている作業を選ぶ。
2. 読み取り専用にする： 検出、Schema、結果表示、失敗処理を最小権限で確認する。
3. 既存ロジックを再利用する： 認証、認可、検証、レート制限、サービス関数を通常UIと共有する。
4. Schemaを狭くする： 必要な項目だけを受け取り、列挙値を使い、additionalProperties: false を設定する。
5. 検証可能な結果を返す： ID、件数、現在状態、変更差分を返す。
6. 実タスクで測る： 完了率、時間、確認回数、失敗理由、ユーザーの採用率を記録する。

最小例は、現在のページタイトルを読むだけのツールです。

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "get_page_title",
    description: "現在のページタイトルを読み取ります。ページやユーザーデータは変更しません。",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async () => ({
      title: document.title,
      url: location.href,
    }),
  });
}

OpenAIの現在の実装を対象にする場合は、トップレベルページで命令型JavaScript APIを使います。内蔵ブラウザは、HTMLフォーム属性を使う宣言型APIとiframe内の登録ツールを現在サポートしていません。

Chrome公式ガイドでは命令型と宣言型の両方が説明され、Chrome 149からのOrigin Trialと、ローカル確認用 chrome://flags/#enable-webmcp-testing が案内されています。同じWebMCPでも対応範囲が異なるため、OpenAIとChromeを別々に検証してください。

既存の認証・認可を崩さない

ブラウザがツール呼び出しを安全審査しても、サイト、ツール説明、レスポンスが信頼済みになるわけではありません。OpenAIも、購入、メッセージ送信、削除、権限変更では通常の確認ポリシーが適用され、安全審査はWebサイト出力の信頼性を保証しないと説明しています。

リリース前に、次の順序で確認します。

• ツール名と説明が実際の処理と一致しているか。
• 不要な個人情報やページ状態をSchemaに含めていないか。
• 信頼できる境界で認証・認可を再検証しているか。
• 購入、公開、送信、削除、権限変更に人の確認があるか。
• 第三者スクリプトが高権限ツールを登録できないか。
• ツール出力を新しい命令ではなく、未信頼データとして扱っているか。
• 呼び出し、結果、失敗を監査・評価できるか。
• WebMCP非対応時も通常UIが動作するか。

WebMCP草案は、プロンプトインジェクション、ツールポイズニング、意図の誤表示、過剰なパラメーター、オリジン境界を議論しています。Agent識別、セキュリティポリシー、同意、監査ログは今も検討中です。草案のセキュリティ記述とGitHubのセキュリティ提案は、対策がすべて完成した証拠ではなく、論点が継続中である証拠です。

結論として、WebMCPは現在のWebページで人とAgentが共同作業するための有力なレイヤーです。しかし、すべての連携を置き換えるものではありません。ページ外の処理はMCP、未対応サイトはブラウザ自動化、ページ内の限定操作はWebMCPと分担し、最初の読み取り専用ツールが実際に価値を生むか確認してから拡張するのが安全です。

出典

• OpenAI：Site tools
• W3C Web Machine Learning Community Group：WebMCP API草案
• Chrome for Developers：WebMCP
• Chrome for Developers：WebMCPとMCPの比較
• OpenAI：CodexとRunmeによる反復作業の自動化
• Cloudflare：WebMCP Developer Preview
• AgentMarkup Studioの実装事例
• The WebMCP Challenge
• WebMCP GitHubリポジトリ
• Google Cloud Tech：実装デモ 02:52
• Greg Isenberg：Agentツール比較 10:03
• OpenAI提供を含むSite tools体験 12:30