この記事は、2026年10月20日時点のWebMCPの状況をまとめたものです。仕様の最新状況を追いたい技術者の方と、自社サイトへの取り入れ時期を考える企画担当の方に向けて書いています。読み終えるころには、いまは待つべきか、小さく試すべきかを、自社の事情に合わせて判断できるようになります。
先にお断りします。WebMCPは、仕様の草案が変わり続けている段階です。この記事も、仕様の動きに合わせて見直していく前提で書いています。日付が古いと感じたら、記事末尾の参照元で最新の内容を確認してください。
WebMCPの全体像や、事業者にとっての意味は、WebMCPとは何か：AIエージェントに使われるWebサイトの考え方で解説しています。この記事は、そちらを読んだうえで「いまどこまで進んでいるのか」を知りたい方向けの、状況整理です。
まず結論：いまの位置づけ
要点は三つです。一つ目に、WebMCPはW3Cの標準ではありません。二つ目に、Chromeでは試験的に提供されています。三つ目に、仕様は変更される可能性があります。
- 仕様の置き場所は、W3CのWeb Machine Learning Community Group（ウェブ機械学習コミュニティグループ）です。
- 公開されているのは、Draft Community Group Report（コミュニティグループの草案）で、2026年10月16日付のものです。
- W3Cの標準化トラック（標準になるための正式な道筋）には載っていません。
- 提案のリポジトリの公開は2025年8月13日です。実験的な提案と位置づけられています。
つまり「正式な標準」ではなく「標準にしようと議論している提案」です。Chromeの公式資料は、これを「proposed web standard（提案中のWeb標準）」と表現しています。
Chromeの提供状況
Chromeの公式資料によると、WebMCPはChrome 149からオリジントライアルとして提供されています。オリジントライアルとは、特定の機能を、期間を区切って公開サイトで試せる仕組みです。正式な機能になったという意味ではありません。
これまでの流れ
| 時期 | 出来事 |
|---|---|
| 2025年8月13日 | 提案がリポジトリで公開された |
| 2026年2月ごろ | 設定を有効にして試せる早期プレビューが始まった（複数の解説で一致。公式資料での日付は未確認） |
| 2026年5月18日 | Chromeの公式資料が公開された（最終更新は2026年10月7日） |
| Chrome 149 | オリジントライアルとして提供 |
| 2026年10月16日 | W3Cコミュニティグループの草案の最新版 |
手元で試す方法
ローカルの環境で検証するには、Chromeのフラグ（実験機能のスイッチ）を使います。アドレス欄に chrome://flags/#enable-webmcp-testing と入力して、設定を有効にします。
DevToolsでは、登録したツールの確認や、入力の形（スキーマ）の検証ができます。試験用の拡張機能として、Example Agentic Chrome ExtensionとModel Context Tool Inspector Extensionが紹介されています。また、Angularが実験的にWebMCPへ対応していることも、Chromeの資料に書かれています。
なお、Edgeなど他のブラウザの対応時期は、公式な情報を確認できていません。この記事では、対応するともしないとも書きません。
仕様の主な変更点
草案の2026年10月16日時点の内容を、初期の資料と見比べると、次のような違いがあります。これから実装する方は、古い解説記事のコードがそのまま動くとは限らない点に注意してください。
| 項目 | いまの草案 | 補足 |
|---|---|---|
| 入口となるオブジェクト | document.modelContext | 初期の資料にあったnavigator.modelContextは、廃止の方向です。Chrome 150で非推奨になるとの解説はありますが、公式の記載日は未確認です。 |
| 安全な接続 | SecureContextが必要 | HTTPSなど、安全な接続のページで使います。 |
| ツールの登録 | registerTool(tool, options) | 名前の重複、名前や説明が空の場合は失敗します。名前は128文字以内です（Chromeの安全性の資料は、エージェントに見せる量の目安として、名前30文字、説明500文字などを示しています。短く書くのが安全です）。 |
| 公開先の指定 | options.exposedTo | 他のオリジン（サイトの単位）にもツールを見せるときに、明示します。 |
| 登録の解除・中断 | options.signal、executeのsignal | AbortSignalという仕組みで、登録の解除や実行の中断ができます。 |
| 注釈（ヒント） | readOnlyHint、untrustedContentHint、consequentialHint | 読み取り専用か、返す内容が信頼できないか、取り消せない影響があるかを伝えます。既定はいずれもfalseです。 |
| イベント | toolchange、toolactivated、toolcancel | ツールの増減、実行の開始、中断を知らせます。 |
| エラー | NotFoundError、DataError、OperationError、AbortError | 他のオリジンからは、存在しないツールでもNotFoundErrorを返し、探られるのを防ぎます。 |
この表の「変更点」は、公開されている資料の読み比べによるものです。個々の変更がいつ、どの議論で決まったかまでは、この記事では扱いません。経緯を正確に知りたい場合は、提案のリポジトリの履歴を確認してください。
宣言的APIの扱いの違い
ここは、読み違えやすい点です。Chromeの公式資料では、2つ目のAPIとして、HTMLのフォームに注釈を付けてツールにする方式が紹介されています。コードでツールを登録する方式に対して、HTML側に宣言を書く方式なので、「宣言的API」と呼ばれます。
一方で、W3Cコミュニティグループの草案の本文（2026年10月時点）には、この宣言的APIは含まれていません。つまり、Chromeの資料では紹介されているが、W3Cの草案の本文にはまだない、という状態です。
- Chromeの資料だけを読むと、すでに仕様の一部のように見えます。
- 草案の本文だけを読むと、存在しないように見えます。
- 草案の本文とChromeの資料とで、記述の範囲が異なっています。
この差が今後どう解消されるかは、現時点では不明です。宣言的APIを前提に設計するなら、草案への取り込みを確認してからにするのが安全です。
未解決の課題
草案には、既知の課題がいくつも挙げられています。「まだ決まっていないこと」を知っておくと、どこが変わりやすいかが見えてきます。
| 課題 | 内容 |
|---|---|
| ツールの更新 | updateToolのような、内容の自動更新がありません。名前・説明・スキーマを変えるときは、登録を解除して再登録します。 |
| ツールの数 | ツールが多いと、モデルが一度に扱える文脈量に響きます。動的に登録する方法が勧められています。 |
| スキーマ検証 | 厳密すぎる検証は、エージェントを止めることがあります。executeの側でも入力を検証し、次の手が分かるエラーを返すことが勧められています。 |
| ユーザー確認 | 確認の標準的なやり方は、未解決の課題です。 |
| 出力の定義 | outputSchema（出力の形の定義）なども、未解決の課題です。 |
これらは、将来の仕様で変わる可能性が高い部分です。今ここに合わせて作り込むと、後で直す手間が出るかもしれません。
今後の見方：何を見ていれば更新が分かるか
情報の多くは解説記事を経由して届きますが、日付や内容がずれることがあります。更新を追うなら、次の一次情報を見るのが確実です。
- W3Cコミュニティグループの草案：仕様そのものです。日付と変更履歴を見ます。
- 提案のリポジトリ：議論と課題（Issue）が集まる場所です。未解決の論点はここで動きます。
- Chromeの公式資料：提供状況、フラグ、設計の勧めが更新されます。
- MCPの公式サイト：WebMCPと用語を共有するMCPの動きを知る手がかりになります。
見るときの目安も挙げておきます。草案の日付が変わったか、宣言的APIが本文に入ったか、ユーザー確認の扱いが決まったか、の三点です。これらが動いたら、自社の方針を見直すきっかけになります。ほかのブラウザの対応は、公式な発表があるまで判断材料にしないのが無難です。
事業者はいま何をすべきか：待つか、試すか
結論は、自社の状況によって分かれます。判断の目安を表にしました。
| 状況 | 向いている動き |
|---|---|
| 予約・検索・問い合わせなど、AIに任せたい操作がはっきりしている | 検証用の環境で、読み取り専用のツールを一つ試す |
| エンジニアがいて、新しい仕様を追う余力がある | フラグで手元の検証を行い、草案の更新を追う |
| まだ何をAIに任せるか決まっていない | 待ちながら、自社の機能の棚卸しを先に進める |
| 決済や契約など、取り消せない操作が中心 | 公開は急がず、確認の扱いが固まるのを待つ |
架空の例を挙げます。架空の宿泊予約サイトが、空室検索だけをツールにして試すとします。読み取りだけなので、間違っても予約は入りません。このような範囲なら、仕様が変わっても作り直しの負担は小さく済みます。
試すにしても、WebMCPはあくまでプログレッシブエンハンスメント（あれば使われ、なくても動く、という考え方）として扱うのが安全です。人間向けの画面が主役であることは、変わりません。自社サイトの現状を点検する項目は、エージェント対応サイトのチェックリストにまとめています。
注意したいこと
- 古い解説に注意：navigator.modelContextを使った例は、現在の草案と異なります。
- 標準になったとは言えない：オリジントライアルは、正式提供とは別です。
- 安全面：草案は、プロンプトインジェクション（ツールの説明や出力に紛れた悪意ある指示）などのリスクを挙げています。草案の本文は、ツール実行時のユーザー確認を必須とは定めていません。取り消せない操作では、確認の仕組みを自社でも考える必要があります。
- 認証・ログインの扱い：W3C草案は認証やCookieの扱いを定めていません。一方、Chromeの資料（MCPとの比較のページ）は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。設計の前に、最新の資料を確認してください。
- 数字や事例：普及の度合いや導入の効果を示す、確かな数字は確認できていません。この記事でも扱いません。
Otsumuに相談できること
仕様の追跡や、読み取り専用のツールを一つ試す程度なら、エンジニアのいる会社では自社でも進められます。まずは、草案と公式資料を読み、手元の環境で動きを見るところからです。
一方で、どの機能をAIに任せるか、取り消せない操作をどう守るか、事業全体をAI前提にどう組み直すか、といった判断は、技術だけでは決まりません。Otsumuは、AIファーストの事業の再構築（事業の組み直し）を支援しています。AIが下書きや実装を担い、人が判断と責任を持つ形で、設計から運用までをご一緒します。
具体的な開発についてはAIエージェント開発をご覧ください。ご相談はお問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日です。仕様は変動中のため、最新の内容は次の参照元でご確認ください。参照元：W3C Web Machine Learning Community Group の仕様草案、提案のリポジトリ、Chromeの公式資料、MCPの公式サイト。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20