Google I/O 2026では、GeminiやWorkspaceだけでなく、ChromeとWeb制作の領域でも重要な発表がありました。特に WebMCP、Modern Web Guidance、Chrome DevTools for agents は、AIエージェントがWebサイトをどう操作し、開発者がどう検証するかに関わる発表です。
WebMCPは、自社サイトのフォームやJavaScriptの処理を「AIエージェントが呼べるツール」として登録するための提案中のWeb標準で、2026年10月時点ではChrome 149からのorigin trial（期間限定の試験提供）として試せます。Chrome DevTools for agentsは、開発者が使うAIコーディングエージェントを実際のChromeにつなぎ、表示確認やLighthouse監査をさせる道具です。前者は「来訪するエージェントにサイトを操作させる」、後者は「作る側のエージェントにサイトを検証させる」ためのもので、対象も許可の考え方も異なります。
要点
- WebMCPは、サイトのフォームやJavaScript処理をAIエージェントが呼べるツールとして登録する提案中のWeb標準で、Chrome 149からorigin trialで試せます。
- Chrome DevTools for agentsは、開発者のAIエージェントを実際のChromeにつなぎ、表示確認やLighthouse監査をさせる道具で、接続したブラウザの中身をエージェントが扱える点に注意が要ります。
- 企業サイトでは、エージェントに使わせる導線と送信を人に残す導線を分け、フォーム、同意、確認画面、計測を先に整えます。
WebMCPとChrome DevTools for agentsの違い
| 比較点 | WebMCP | Chrome DevTools for agents |
|---|---|---|
| 何をつなぐか | サイトの機能 → 閲覧者のブラウザで動くAIエージェント | 開発者のAIコーディングエージェント → Chromeブラウザ |
| 誰が使うか | サイトを訪れた利用者の代わりに動くエージェント | サイトを作る・直す開発者 |
| 提供状態（2026年10月時点） | 提案中の標準。Chrome 149からorigin trial。仕様は変更の可能性あり | 提供中。MCPサーバーとCLIとして提供され、エージェント向けのskillsを同梱 |
| 操作の許可 | サイトが登録したツールを通じて操作する。機密操作では利用者に確認ダイアログを出せる。ツールを登録できるのは既定で自サイトと同じオリジンのページ | 接続したブラウザの中身を、エージェントが確認・デバッグ・変更できる |
| 企業サイトでの使いどころ | 資料請求、診断、在庫・料金の照会など、エージェントに使わせたい導線 | 公開前の表示確認、利用者の操作の再現、Lighthouseによるアクセシビリティ・SEO・パフォーマンス監査 |
出典：WebMCP（Chrome for Developers）、Chrome DevTools for agents、chrome-devtools-mcp（GitHub）
WebMCPとagentic webで何が変わるか
WebMCPは、WebサイトがAIエージェントに対して、JavaScript関数やHTMLフォームのような構造化された操作を提示するための提案です。2026年10月時点ではChrome 149からorigin trialとして試せ、APIは今後変わる可能性があると案内されています。Gemini in Chromeについては、I/Oの発表で対応予定と案内されています。
これは、AIエージェントが人間の画面をまねてボタンを探し、入力欄を推測し、クリックを繰り返す世界から、サイト側が「この操作はこの道具を使う」と明示する世界への移行です。旅行サイトなら条件検索、ECなら在庫確認やカート操作、BtoBサイトなら資料請求、診断、料金見積もり、問い合わせのような導線が対象になり得ます。
企業サイトで重要なのは、AIに操作させたい導線と、操作させたくない導線を分けることです。問い合わせ送信、資料請求、個人情報入力、見積もり依頼のような高い意図を持つ行動は、エージェント任せにする前に、確認画面、同意文、入力エラー、ログ、計測イベントを整える必要があります。
I/Oでは、コーディングエージェントに最新のWeb実装方針を渡すModern Web Guidance（early preview）も発表されました。
最小例：フォームをツールとして公開する
WebMCPには、HTMLフォームに属性を足す宣言型と、JavaScriptで登録する命令型があります。資料請求フォームを宣言型で公開する場合、フォームにツール名と説明を付けます。
<form toolname="request_document"
tooldescription="サービス資料の送付を申し込む"
action="/request/">
<input name="company" toolparamdescription="会社名">
<input name="email" type="email" toolparamdescription="資料の送付先メールアドレス">
<button type="submit">申し込む</button>
</form>エージェントがこのツールを呼ぶと、ブラウザがフォームにフォーカスして項目を埋めます。宣言型APIのドキュメントによると、既定では送信ボタンは利用者が押し、フォームに toolautosubmit 属性を付けた場合だけ送信まで進みます。料金の照会のように画面遷移を伴わない処理は、命令型で document.modelContext.registerTool() に名前、説明、入力の形式、実行する関数を渡して登録します。どちらもorigin trial中の仕様で、属性名やAPIは変わる可能性があります。
公開する前に、送信まで任せるか、入力だけ任せて送信は利用者に押してもらうかを決めます。個人情報を送る導線では、確認ダイアログを出す設定と、同意文・確認画面を人が読める状態に保つことが前提です。
Chrome DevTools for agentsはWeb制作のQAをどう変えるか
Chrome DevTools for agents は、AIエージェントがChromeブラウザを操作し、実際のページで確認しながら開発や修正を進めるための仕組みです。Googleのドキュメントでは、エージェントがブラウザ上でコードを検証し、ユーザー操作をエミュレートし、出荷前にバグを見つける用途が説明されています。
Web制作やLP改善では、これまで「修正したつもり」のまま公開される事故が起きがちでした。ボタンの文言が折れる、モバイルでフォームがはみ出す、低コントラストで読みにくい、送信完了イベントが発火しない、画像のaltが抜ける、といった問題は、見た目の好みではなくCVと信頼に直結します。
AIエージェントがChrome DevToolsを扱えるようになると、実装と検証の間にある手作業を減らせます。ただし、確認観点をAI任せにすると抜けが出ます。企業側は、ページ種別ごとに「何を合格とするか」をチェックリスト化しておく必要があります。
- ファーストビューで主語、対象読者、CTAが伝わるか
- モバイルでCTA、料金表、フォーム、FAQが崩れていないか
- Lighthouseのアクセシビリティ、SEO、パフォーマンスで致命的な警告がないか
- 資料請求、問い合わせ、診断の計測イベントが確認できるか
- 入力エラー、確認画面、完了画面の文言が読者向けになっているか
注意したいのは、Chrome DevTools for agentsがエージェントにブラウザの中身を渡す道具だという点です。基盤のchrome-devtools-mcpのREADMEは、接続したMCPクライアントがブラウザ内のデータを確認・デバッグ・変更できるとして、共有したくない機密情報や個人情報を扱わないよう注意しています。管理画面や本番の計測ツールにログインしたままのブラウザではなく、検証用のプロファイルやテスト環境につないで使います。
企業サイトが最初に直すべき場所
WebMCPにすぐ対応するかどうかより先に、AIエージェントが読んでも人間が読んでも誤解しにくいページ構造を作ることが重要です。これは AI検索最適化 とも近く、情報を隠さず、比較しやすく、答えが見出し直下にある状態を作る作業です。
最初に見るべきなのは、問い合わせや資料請求の前後です。AIエージェントがユーザーの代わりに操作できるようになるほど、フォームの説明、同意、確認、完了後の次アクションが曖昧なサイトは不利になります。人間が読んでも迷う導線は、AIにも安定して扱えません。
| 見直す場所 | よくある問題 | 改善の方向 |
|---|---|---|
| CTA | 何が起きるボタンか分からない | 相談、資料請求、診断など行動を明確にする |
| フォーム | 必須項目とエラー理由が分かりにくい | ラベル、補足、確認画面、完了画面を整える |
| 比較表 | 強みだけで条件や制約がない | 向く会社、向かない会社、前提条件を書く |
| FAQ | 営業資料の言い換えになっている | 導入前の不安、費用、権限、運用負荷に答える |
| 計測 | CV地点しか見ていない | CTAクリック、エラー、途中離脱も測る |
特にBtoBサイトでは、LPだけを整えても足りません。サービスページ、料金説明、事例、FAQ、資料請求、問い合わせ後の完了ページまで一連の流れで見ます。AIエージェントが横断的に情報を拾うほど、ページ単体ではなく導線全体の整合性が問われます。
Web制作チームの運用に落とし込む手順
最初の手順は、最新技術を入れることではありません。AIエージェントに検証させたいページと、人間が最終確認すべき項目を分けることです。Chrome DevTools for agentsのような仕組みは、QAを丸投げする道具ではなく、確認漏れを減らす道具として使う方が定着します。
- 主要CVページ、LP、フォーム、資料請求導線をリストアップする
- 各ページで、表示、入力、計測、アクセシビリティ、SEOの合格条件を決める
- AIエージェントに任せる確認と、人間が見る確認を分ける
- 修正後はChrome上でモバイル、フォーム、CTA、Lighthouseを確認する
- 改善結果をCV、途中離脱、フォームエラー、問い合わせ品質で見る
この流れは、AIエージェントガバナンスの考え方ともつながります。エージェントにできることが増えるほど、権限、ログ、承認、停止方法を決めておく必要があります。Webサイトの場合は、公開ページの変更、フォーム送信、外部連携、計測タグ変更がリスクになりやすい領域です。
よくある質問
WebMCPとは何ですか？
Webサイト側が、AIエージェントに使わせたいフォームやJavaScript関数などを構造化して示すための提案です。Chrome 149からorigin trialとして試せますが、仕様は変更の可能性があります。
Chrome DevTools for agentsは何ができますか？
AIエージェントがChrome上でページを操作し、コンソールログ、ネットワーク、アクセシビリティツリー、Lighthouse監査などを使って検証しやすくなります。Web制作では、修正後の表示確認、モバイル確認、SEOやアクセシビリティの確認に向きます。
DevTools for agentsを使うときの注意点は？
エージェントが接続したブラウザの中身を確認・変更できるため、管理画面や本番サービスにログインしたままのブラウザにはつながず、検証用のプロファイルやテスト環境で使います。
企業サイトはすぐWebMCPに対応すべきですか？
まずは焦って実装するより、フォーム、FAQ、料金表、比較表、資料請求導線、計測イベントを機械にも人にも分かりやすく整えることが先です。WebMCPの正式仕様や対応ブラウザの広がりを見ながら、操作させたい導線から検討します。origin trialの期間中は仕様が変わる可能性があるため、主要な導線をWebMCPだけに依存させない方が安全です。
LP改善では何から始めるべきですか？
主要フォーム、CTA、入力エラー、モバイル表示、アクセシビリティ、計測タグから始めるのが現実的です。AIエージェントが検証できる形にしておくと、更新のたびに同じ品質確認を回しやすくなります。
