chot Inc.（ちょっと株式会社）

WebMCPとは何か — Webページ自身がAIエージェントに「ツール」を渡す仕組みと2026年9月時点の現状

開発

WebMCP は、Web ページが自分の機能を「ツール」としてブラウザに登録し、ブラウザ上で動く AI エージェントがそれを直接呼び出せるようにする JavaScript API の提案です。エージェントに画面を推測させる代わりに、サイト側が「この操作をこの引数で呼んでください」と宣言します。2026 年 9 月現在、W3C の Web Machine Learning Community Group によるドラフト（標準化トラックには載っていません）で、Chrome 149 以降のオリジントライアルと ChatGPT デスクトップアプリの内蔵ブラウザで実際に動かせる段階です。結論としては、今は「本番の全面導入」ではなく「限定範囲での検証」が妥当な距離感です。

WebMCP の仕組み：ツール名・説明・入力スキーマの3点セット

WebMCP でページが公開する「ツール」は、ツール名、自然言語の説明、入力の JSON スキーマを持った JavaScript 関数です。仕様書はこの状態を「バックエンドではなくクライアントスクリプトでツールを実装した MCP サーバーのようなもの」と説明しています。

登録方法は 2 種類あります。

  • 命令型 API（Imperative API）：JavaScript で registerTool() 相当の呼び出しを行い、検索・状態変更・画面遷移などの関数をツールとして登録する
  • 宣言型 API（Declarative API）：既存の HTML フォームに toolname などの属性を付けるだけでツール化する

React や Vue で状態を持つアプリは命令型、問い合わせフォームや検索フォームなど素直なフォームは宣言型が向きます。宣言型は既存のフォームに属性を足すだけなので、実装コストは小さく済みます。

注意点として、API の置き場所は短期間に変わっています。navigator.modelContext を前提に書かれた記事のコードは現在のドラフト（document.modelContext）では動きません。実装前に必ず最新の仕様とブラウザのドキュメントを確認してください。

従来のエージェント操作、MCP との違い

今のブラウザ操作エージェントは、スクリーンショットや DOM を読み取り、クリックと入力をシミュレートして動きます。Chrome のドキュメントはこれを「アクチュエーション（actuation）」と呼び、手順が多くなるほど解釈の余地が増えて信頼性が落ちると整理しています。クラス名の変更やレイアウト変更で壊れるのも、この方式の弱点です。

サーバー側で動く通常の MCP との違いは、実行場所と前提です。MCP サーバーはページが開いていなくても動きますが、別途の接続設定と認証が必要です。WebMCP は開いているページとログイン済みセッションの中で動くため、ユーザーとエージェントが同じ画面・同じ状態を共有できます。ダッシュボードやエディタのように「今そこに見えているもの」を一緒に操作する用途では、この差が大きく効きます。両方を併せて提供することも可能です。

2026年9月時点の対応状況

判断に必要なのは、仕様と実装のそれぞれの成熟度です。

  • 仕様：Web Machine Learning Community Group の Draft Community Group Report として更新が続いています（最新版は 2026 年 9 月 15 日付）。W3C 標準ではなく、標準化トラック上の文書でもありません
  • Chrome：ローカル検証は chrome://flags/#enable-webmcp-testing、実ユーザーへの提供は Chrome 149 からのオリジントライアル（期間限定の試験公開）。DevTools にも登録済みツールを確認・実行する実験的な支援があります
  • 他ブラウザ：Microsoft は仕様の編集者に名を連ねていますが、2026 年 5 月の Chromium の Intent to Experiment 時点で Gecko・WebKit からの実装シグナルは「なし」と記載されています。全ブラウザで既定有効になる段階ではありません
  • エージェント側：2026 年 8 月 25 日に ChatGPT デスクトップアプリの内蔵ブラウザが「サイトツール」として WebMCP に対応しました。ただし対応は仕様の一部で、宣言型 API と iframe 内のツールは対象外、モデルは GPT-5.6 Sol / Terra が必要、Enterprise・Edu ワークスペースは対象外という条件があります

つまり「サイト側が用意する手段」は整いつつあり、「呼ぶ側」が広がり始めたところです。WebMCP に対応していないエージェントは従来どおり画面を操作するだけなので、人間向け UI を残すことは必須の前提になります。

実際に効果が出るのはどんな画面か

chot Inc. のエンジニアが技術ブログで、自社 CMS「Orizm」のデザインエディター（ページを見た目のまま編集する GUI）に WebMCP のツールを実装し、Codex のブラウザ操作で「参考ページと同じ構成のページを作る」検証を行っています。WebMCP なしでは 5 分 52 秒、ありでは 3 分 9 秒という結果でした（同一プロンプト・単純な構成のページでの 1 回の比較であり、ベンチマークではありません）。

この検証から実装上のヒントとして読み取れるのは次の 2 点です。

  • 「書くツール」だけでは足りない：追加・更新・削除といった操作系ツールだけ用意しても、エージェントは現在のページ構造を把握できません。一覧取得や利用可能なブロック種別のカタログといった「読むツール」を揃えることで、観察 → 計画 → 実行の流れが成立し、動作が安定しました
  • 効くのは複雑な GUI：フォーム入力のような単純な操作は、WebMCP がなくても既存のエージェントで十分こなせます。差が出るのは、モーダルや入れ子構造、ドラッグ操作など人間向けに最適化された画面です

逆に言えば、静的なコーポレートサイトに慌てて入れる必要はありません。候補になるのは、CMS の管理画面、業務システム、ダッシュボード、検索・絞り込みが複雑な EC、社内向けツールです。

導入前に押さえるべき制約とリスク

技術的な制約はいくつか明確です。ツールの呼び出しには開いたタブが必要で、ヘッドレス実行はサポートされません。トップレベルのドキュメントが対象で、iframe 内の登録は ChatGPT の内蔵ブラウザでは検出されません。Chrome では Permissions Policy による制御下に置かれます。

セキュリティ面では、OpenAI 自身が、サイトツールは画面上に存在しない機能を露出させ得るため、データの外部流出やプロンプトインジェクションといった新しいリスクを伴うと明記しています。加えて、購入・削除・権限変更・メッセージ送信などは確認を挟む運用になっています。実装側の指針としては次の通りです。

  1. ツールは既存ロジックの薄いラッパーにとどめ、認証・認可・入力検証はアプリ側の仕組みをそのまま通す
  2. 入力は狭く定義し、副作用を説明文に明記し、結果の検証に足る情報を返す
  3. 破壊的な操作は確認を必須にし、そもそもツール化しない選択も検討する
  4. ツール名と説明文から内部構造が推測できる点を踏まえ、社内限定機能を不用意に公開しない
  5. 人間向けの UI と操作経路は必ず維持する（プログレッシブエンハンスメントとして足す）

SEO への影響を期待するのも現時点では早計です。OpenAI は WebMCP 対応を検索順位や引用、推薦と結び付けていません。

いま取るべき現実的な進め方

仕様が動いている前提で、投資を小さく保つのが要点です。まずローカルのフラグ有効化と ChatGPT デスクトップの内蔵ブラウザで、自社サイトの中で「エージェントに任せたい操作」を 1〜2 個だけツール化して試します。次に、読むツールと書くツールの組み合わせでタスクが完走するかを確認し、既存コードをどれだけ再利用できたかを記録します。ツール登録部分は薄い抽象層にまとめておくと、API 名の変更が起きても差分を 1 箇所に閉じ込められます。本番の実ユーザーに出すのは、オリジントライアルの条件と期限を確認した上で、社内ツールや管理画面から始めるのが無理のない順序です。

WebMCP は「標準になったら対応する」よりも、対象を絞って今のうちに手触りを掴んでおくほうが費用対効果の高いテーマです。CMS の管理画面や業務システムをエージェントから扱えるようにしたい、あるいは自社サイトのどの操作をツール化すべきか判断したいという段階であれば、お問い合わせからご相談ください。検証の設計から実装まで、現在の仕様の制約を踏まえてお手伝いします。

出典

この記事をシェア

最新の記事

AI最新情報

Jevとは何か — 文章を生成しないAIモデルがLLMやAIエージェントと違う点

開発

デプロイナウコンテストの応募方法と締切｜賞金100万円を狙う前に確認する条件

サイト制作

キラキラシール（ホログラムシール）の作り方3通り｜100均・自宅プリント・印刷通販の選び分け

コラム一覧