これはGoogle I/O Writing Challenge

の提出です。Google I/O 2026で大きなアナウンスが目立ちました：Gemini 3.5、Antigravity 2.0、Androidエージェント、AI Studioのアップグレード、そしてAIを使ってソフトウェアを構築する多くの新しい方法。

私が何度も思い出したアナウンスはもっと静かでした：

WebMCP。

Chromeのドキュメントでは、それをChromeフラグの背後にローカルでテストできる提案されたオープンウェブ標準として説明しています。デモアプリを使って探索することもできます。

しかし、その下にある考え方は重要です：

もしウェブサイトがエージェントにボタンやフォームの意味を推測させるのをやめ、構造化された型付けされたアクションを直接公開したらどうでしょうか？

それは小さなことのように聞こえますが、現在存在するツールと比較してみれば分かります。Chrome DevTools MCP、Googleの公式MCPサーバーで、コーディングエージェントがDevToolsを通じてChromeを制御・検査できるものです

両方を見た後、私の考えは単純です

Chrome DevTools MCPはエージェントが既に作成したウェブを理解するのに役立ちます。WebMCPは私たちにエージェントが推測せずに使用できるウェブを構築するよう求めています

その違いはウェブ開発者にとって重要です

現在のウェブはまだ目と指のためのものです

大多数のウェブアプリはユーザーがピクセルを見てクリック一つずつでUIを操作する人間であると仮定しています

そのモデルは人間には機能しますが、エージェントにははるかに信頼性が低いです

エージェントはDOMを検査しようとすることができます。アクセシビリティツリーを使用できます。スクリーンショットを撮影できます。ボタンをクリックできます。フィールドにデータを入力できます。しかし、アプリがはっきりとした意図を公開しない限り、エージェントはまだ多くを推測しなければなりません：

• このボタンは破壊的ですか、または逆戻り可能ですか？
• この日付フィールドはMM/DD/YYYY、YYYY-MM-DD、またはカスタムピッカーフローを期待していますか？
• 表示価格は最終的なものですか、それとも税金が後で表示されますか？
• このフォームはすぐに提出されますか、それとも下書きを保存しますか？
• この無効化されたボタンは検証、認証、在庫、またはJavaScript状態を待っていますか？

人間は曖昧さを文脈で処理します。エージェントは曖昧さを再試行、脆いヒューリスティクス、そして時折のばかげたことを使って処理します。

WebMCPは、その曖昧さを元々から減らそうとするため面白いです。

WebMCPが追加するもの

The Chrome WebMCPドキュメントは、WebMCPをWebページが構造化されたツールをAIエージェントに公開するための方法として説明しています。ページはJavaScript関数を登録したり、HTMLフォームを注釈したりして、エージェントが利用可能なアクションを発見し、入力スキーマを理解し、現在のブラウザコンテキスト内でそれらのアクションを呼び出せるようにします。

つまり、ウェブサイトはこう言うことができます：

// Conceptual example, not exact production code
registerTool("searchFlights", {
  description: "Search available flights",
  input: {
    origin: "string",
    destination: "string",
    date: "string",
    passengers: "number"
  }
});

それは「テキストボックスを探して、おそらくオリジンという意味かと思って入力し、Tabキーを押して何か場所に移動し、カスタム日付選択器がうまく動くか期待して、青いボタンをクリックする」という違う契約です。

公式ドキュメントでは、発見、JSONスキーマ、ページ状態のサポートを呼び出しています。また、サポートフロー、旅行予約、構造化されたフォーム、日付選択器、非表示診断アクションなどの例を挙げています。

重要な言葉は構造化.

ウェブには既にAPIがあります。しかしWebMCPはバックエンドAPIではありません。ブラウザのコンテキストで動作します。ツール呼び出しはユーザーが見る同じUIを更新できます。これにより、ユーザーはループに残り、表示される製品体験が保存され、エージェントには生の操作よりも信頼性の高いパスが提供されます.

なぜChromeデベロッパートolls MCPと比較したのか

Google I/O開発者キーノートでは、WebMCPとエージェント向けのChrome DevToolsを同じ広範なセクションにまとめ、「エージェント時代におけるWeb開発の再定義」としました。この組み合わせは有用です.

エージェント向けChrome DevToolsは、コーディングエージェントがChromeとインタラクティブにやり取りし、ページを検査し、実行時の動作をデバッグし、実際のユーザーエクスペリエンスを模倣し、アウトリーチを実行し、コンソールメッセージを検査し、ネットワークリクエストを分析し、アクセシビリティツリーのスナップショットを取得し、パフォーマンスワークフローを実行する能力を与えます.

GitHubのREADMEファイルchrome-devtools-mcp は、Antigravity、Claude、Cursor、Copilot、CodexなどのエージェントがライブのChromeブラウザを制御・監視できるMCPサーバーであると説明しています。ツールのリファレンスにはナビゲーション、入力自動化、エミュレーション、ネットワーク監視、コンソール監視、スクリーンショット、アクセシビリティスナップショット、Lighthouseの監査、パフォーマンストレース、メモリツール、拡張機能ツール、実験的なWebMCPツールが含まれます。

それは多くの権力です。

しかし、それは別のレイヤーです.

Chrome DevTools MCPは主に開発者側のデバッグと自動化ツールです.

WebMCPはサイト側の機能契約です.

一方はエージェントが何があるかを確認できるようにします。もう一方はサイトが何ができるかを宣言できるようにします.

私の小さなテスト

手元で確認したいと思ったのではなく、「AIはすべてを変える」という記事をもう書きたくなかった

WebMCPのドキュメントは、命令形と宣言形の実装をカバーするデモを指している

• WebMCP zaMaker、これはWebMCP命令形APIを使用している
• 旅行デモも、WebMCP命令形APIを使用している
• Le Petit Bistroは、WebMCP宣言型APIを使用しています。

私はWebMCP zaMakerから始めました。命令型版では、コアなアイデアが非常に明確になるからです。エージェントにピザのコントロールをピクセルから推測させる代わりに、ページはインスペクターが発見できる明示的なツールを登録します。

私はChromeでWebMCPのテストを有効にし、zaMakerデモを開き、WebMCP - モデルコンテキストツールインスペクターを使用しました。 拡張機能.

この拡張機能は、ページ定義されたツールをいくつか表示しました。例えば:

• add_topping
• manage_pizza
• remove_topping
• set_pizza_size
• set_pizza_style

これが私にとってのポイントです。これらは「座標Xでクリックする」や「入力Yにタイプする」のような一般的なブラウザのアクションではありません。これらはページによって公開される製品レベルの機能です.

例えば、デバッガーは add_topping を表示し、スキーマには topping 列挙型とが含まれていました。size 列挙型です。また、set_pizza_size と構造化された size 入力を示し、number_of_persons フィールドも含まれ、適切なサイズを推測するのに役立ちました。

その後、私はインスペクターで自然言語のプロンプトを使用しました。

add pizza with large toppings

インスペクターはそれをツール呼び出しに翻訳しました。

{
  "size": "Large",
  "topping": "🍕"
}

その後、私は試しました：

make the pizza extra large

拡張機能は以下を呼び出しました：

{
  "size": "Extra Large"
}

ページはピザの状態を変更することで反応しました。

その小さなデモは、ドキュメントだけでは分からなかった違いを明確にしました。ブラウザ自動化エージェントはピザビルダーをクリックできます。一方、WebMCPに対応したページは「この製品がサポートするアクションはこちら、許可されたパラメータはこちら、そして1つを呼び出したときに何が起こったかはこちら」と言うことができます。

対照的に、Chrome DevTools MCPは開発者側のレンズのように感じられました。ページを検査し、アクセシビリティツリーを読み取り、コンソール出力を確認し、インタラクションを自動化し、エージェントがChromeで既にレンダリングされたものをデバッグするのを助けることができます.

それは強力ですが、それでもページから外側から見ています。zaMakerデモはこの考えの他方を示しました：ページ自体がエージェントが使用するための意図的なアクションの小さなセットを公開することができます。

私の実機での結果は以下の通りです：

Chrome DevTools MCPは今日ではページの検査とテストに実用的です。WebMCPインスペクターはページ自体が製品レベルのツールを公開する際に何が変わるかを示します。

WebMCP対Chrome DevTools MCP

私は今、この違いについて考える最もクリーンな方法はこちらです：

エージェントがチェックアウトページがどうして壊れているかをデバッグしようとしている場合、Chrome DevTools MCPが正しいツールです

エージェントが旅行を予約しようとしている場合、サポートリクエストを提出しようとしている場合、ダッシュボードを設定しようとしている場合、またはアプリケーション内でマルチステップのワークフローを完了しようとしている場合、WebMCPはより興味深い長期的な答えです.

なぜ「AIがボタンをクリックできる」というよりも大きいのか

WebMCPが登場する前、デフォルトのブラウザエージェントのパスはこんな感じでした.

1. ページを見てください.
2. ユーザーの次のアクションを推測してください。
3. クリックまたはタイプします.
4. 結果を確認します.
5. 間違っていたら再試行します.

それは機能しますが、脆いです。また、遅くて高価です。なぜなら、各ステップがモデルの推論、視覚的なパース、DOMの解釈、または両方を追加するからです.

WebMCPは別の道を提案します.

1. サイトの利用可能なツールを発見します.
2. ユーザーの目標に合致するツールを選びます.
3. タイプされたパラメータを送信します.
4. サイトが表示されているブラウザコンテキストでアクションを実行します.
5. 構造化された出力または明確なエラーを返します.

それはAPIに近いですが、ユーザーがまだ製品を見ています。

それが why I think WebMCP が重要だと思う理由です。それはエージェントをより強力にするだけでなく、責任をアプリケーション開発者に戻すことについてです。エージェントが安全かつ信頼性のある動作をするためには、ピクセルからすべてのワークフローを逆-engineer することはできません.

意図を公開する必要があります.

WebMCP がどこにでもある前に開発者にできること

私たちはほとんど、明日からWebMCPの生産フローを展開できません。ブラウザのサポートはまだ始まったばかりで、提案もまだ変更されています。

しかし、人間とエージェントの両方にとって理解しやすいサイトを構築することはできます。

このから実用的なチェックリストを取りました：

• カスタムウィジェットの前に、意味論的なHTMLを使用します。
• アクセシビリティツリーで重要なボタンとフォームを明確にします。
• 入力に対して安定した名前とラベルを与えなさい.
• 重要な状態を視覚的なスタイリングだけに隠さないようにしなさい.
• 破壊的なアクションは明確な確認の後に保持しなさい.
• 「プレビュー」、「下書きを保存」、「提出」、「購入」のフローを明確に分けなさい.
• 検証エラーは機械が読み取れるようにし、人間が読み取れるようにしなさい.
• ブラウザ自動化、アクセシビリティスナップショット、Lighthouseを使用して重要なフローをテストします.
• 後で構造化ツールが適しているアプリケーション操作について考えてみましょう.

WebMCPの製品を準備しているなら、すべてのボタンをツールとして公開するのではなく、曖昧さが最も損をする少数のワークフローから始めます.

• 検索
• 購入確認
• 予約
• サポートチケット作成
• 返金/返品開始
• ダッシュボードフィルタリング
• 診断
• アカウント設定変更

これらはエージェントがUIを通じて推測する場所で、実際のユーザーに痛みを生む可能性がある場所です

セキュリティ質問

ここには明らかなリスクがあります：もしウェブサイトがエージェントにアクションを公開すれば、悪いツール設計が悪いアクションをより簡単にする可能性があります.

それが私がWebMCPモデルがアクションをブラウザコンテキストに保持し、すべてのサイトを盲目なバックエンドAPIに変えるのではなく、それを好む理由です。機密なアクションはまだ可視的なUI、ユーザー確認、ページレベルの状態を必要とすることができます.

しかし、開発者は規律が必要です.

良いWebMCPツールは以下の特徴を持つべきです：

• 限られた目的
• 明確な名前
• 厳格なスキーマ
• 役立つエラーメッセージ
• 分かりやすい実行状況
• 不可逆的なアクションの確認
• 予期せぬ副作用がない

目標は「エージェントに何でもできるようにする」であってはなりません。

目標は「エージェントに正しいことを推測せずに行わせる」ことである。

私の考え

Chrome DevTools MCP は、ウェブ開発者が今使えるツールのようだ。

WebMCP は、ウェブ開発者が次に設計する必要がある契約のようだ。

それが、なぜ Google I/O 2026 のより重要なウェブアナウンスの一つだと思った理由である。それは、変化の方向性を示しているからである。

エージェントはより良いスクレイピングツールとして

宛先：

構造化されたウェブ機能の第一級ユーザーとしてのエージェント

その変化は一晩で起こらない。ブラウザのサポート、標準化作業、開発者ツール、セキュリティパターン、そして多くの現実世界のテストが必要だ。

しかし方向性は明確です。代理者側が私たちの代わりにウェブを使用する場合、ウェブアプリケーションは単に視覚的に利用可能である以上のものが必要です。

それらは理解可能である必要があります。

それらは検査可能である必要があります。

そして最終的には、それらは代理者用に準備されている必要があります。

リソース

• WebMCPドキュメント
• WebMCP命令型API
• エージェント向けChromeデベロッパートール
• ChromeDevTools/chrome-devtools-mcp on GitHub
• Google I/O 2026開発者キーノートの振り返り
• GoogleChromeLabs WebMCPツールとデモンストレーション