Googleが提供するパフォーマンス計測ツール「Lighthouse」のバージョン13.3において、「Agentic Browsing」という実験的な新カテゴリが追加された。これは人間ではなく、大規模言語モデルを搭載したAIエージェントが、Webサイトをどれだけ円滑に操作できるかを評価するための指標である。従来、Web制作者は検索エンジンのクローラーに向けてSEO（検索エンジン最適化）を行い、人間のユーザーに向けてUI/UXを改善してきた。しかし、今回のアップデートは、自律的にウェブを回遊するエージェントがトラフィックの主体となる時代を見据えたものだ。
この新カテゴリは、既存のLighthouseスコアのような「0から100」の加重平均によるスコアリングを採用していない。代わりに、エージェント対応状況のチェックリストに対する合格率が分数スコアとして提示される。現在の焦点は、絶対的なランキングを決定することではなく、AIエージェントのブラウジングに必要な技術要件のデータを収集し、開発者に実用的なシグナルを提供することに置かれている。これは、AIエージェントによるWeb操作の基準がまだ発展途上であることを示していると同時に、早期に対応を進める開発者に対して技術的な指針を与える目的がある。
この変化の背景には、5月中旬に開催された「Android Show: I/O Edition」で発表された「Gemini in Chrome」のようなブラウザ統合型AIの台頭がある。ユーザーが自らサイト内を検索・閲覧する代わりに、AIに「このサイトの内容を整理して」と指示する場面が増加する。これにより、ユーザーは検索エンジンの結果ページに遷移する前にブラウザ内でコンテンツを消費するようになり、従来のページ直帰率やセッション数の意味合いが根本から変わる。Web制作者は、人間向けの視覚的な情報提示と並行して、マシン向けの構造的なデータ提示を設計段階から組み込む必要に迫られている。
AIエージェントが要求する4つの技術的要件
LighthouseのAgentic Browsing監査では、サイトがマシンとのやり取りに適した構造になっているかを判断するために、主に4つの決定論的なシグナルが検証される。
1つ目は、アクセシビリティツリーの品質である。AIエージェントは人間の視覚情報をそのまま処理するのではなく、アクセシビリティツリーを主要なデータモデルとして参照する。そのため、すべてのインタラクティブな要素にaria-labelやrole属性を通じたプログラム名が正しく設定されており、親子の構造が有効に構築されているかが厳密に問われる。これまで人間に向けて推奨されてきたアクセシビリティ対応が、ここに来てAIエージェントのための必須要件へと性質を変化させている。
2つ目は、Cumulative Layout Shift（CLS）による視覚的安定性である。ページ読み込み後に要素の位置が大きくずれる現象は、人間のユーザーの閲覧体験を損なう事象である。加えて、AIエージェントにとっては致命的な操作エラーの直接的な原因となる。エージェントが特定のボタンやリンクを特定してからクリックを実行するまでの間にレイアウトが移動すると、誤った要素を操作してしまうリスクが生じる。広告の遅延読み込みやサイズの指定がない画像など、CLSを悪化させる要因はエージェントの操作性を著しく低下させる。
3つ目はWebMCP（Web Model Context Protocol）の統合である。WebMCPは、Webサイトの内部ロジックやデータ構造、入力フォームなどをAIエージェントに対して明示的に公開し、接続するためのプロトコルである。LighthouseはChrome DevTools Protocol（CDP）を介してWebMCPツールの動的および静的な登録イベントを監視し、サイトがエージェントに対してどのような機能を提供しているかを検証する。
4つ目はllms.txtの存在確認である。ドメインのルートディレクトリに、機械可読な形式で記述されたサイト全体の要約ファイル（llms.txt）が配置されているかがチェックされる。コンテキストウィンドウ（一度に処理できる情報量）に制限のあるAIエージェントが、複雑な階層を持つ大規模なサイトの全体構造を効率的に把握するためには、このファイルが事前情報の提供元となる。
検索エンジン最適化（SEO）からエージェント最適化（AEO）への移行
Google CloudのAIエンジニアリングディレクターであるAddy Osmani氏が提唱する「Agentic Engine Optimization（AEO）」の概念は、これらの技術的要件の根底にある設計思想を明確にしている。AIエージェントは、深い階層に埋もれた情報を探し出したり、無駄なトークンを消費する冗長なマークアップを解析したりすることに高いコンピューティングリソースを要する。そのため、よりクリーンなセマンティックHTMLの構築や、トークン効率の高いコンテンツ配信、Markdown形式での代替コンテンツの提供が推奨されている。
興味深い事実は、Googleが「llms.txtやMarkdownは従来の生成AI検索（AI Overviewsなど）の露出には不要である」と公式に明言している点である。検索エンジンとしてのGoogleはHTMLを十分に解析する能力を持っている。しかし、LighthouseがChromeの監査項目としてこれを追加したことは、検索トラフィックの獲得という目的を超えた、マシンツーマシンの情報伝達効率を高めるアーキテクチャ設計の需要が高まっていることを示している。Webの実装は、Google検索のアルゴリズムに最適化する段階から、多様なLLMエージェントの自律的なタスク実行を支援する段階へと視野を広げている。
エージェント向けChrome DevTools 1.0による開発ワークフローの自動化
AIエージェントがWebを操作するための要件が定義されると同時に、エージェント自身がWeb開発やデバッグを行うためのインフラストラクチャも本格稼働を始めている。「エージェント向けChrome DevTools」の安定版1.0リリースは、コーディングエージェントがライブブラウザ環境で実際のユーザーと同じようにサイトを操作し、インタラクティブにデバッグを行うことを可能にした。これまで、生成AIはコードを記述できても、そのコードがブラウザ上でどのようにレンダリングされ、どのようなエラーを引き起こすかを自律的に検証することは困難であった。
この1.0リリースでは、Model Context Protocol（MCP）サーバーを通じてLLMがDevToolsのデバッグ機能に直接接続される。エージェントはLighthouse監査を自動で実行し、アクセシビリティやパフォーマンスの欠陥をリンターのように検出できる。さらに、ブラウザのエミュレーション機能を活用して、デバイスサイズやネットワーク環境のシミュレーションを自律的に進行する。ヒープスナップショットを取得してメモリリークの原因となっているDOMノードを特定するなど、高度なパフォーマンステストまでをエージェントに委譲するワークフローが構築されている。
また、サードパーティのデベロッパーツールとの連携により、Webアプリケーションの内部状態をAIエージェントと共有する仕組みも導入された。これにより、AIエージェントは標準の分析では隠されているデータにアクセスし、複雑なロジックを理解するためのコンテキストを取得できる。ブラウザの現在のコンテキストをエージェントと共有する機能により、ログインが必要な認証領域でのデバッグ作業も効率化され、AIアシスタントが人間の作業を途切れることなく引き継ぐ環境が整った。
プラットフォームとスタイリングアーキテクチャの自律化
開発環境のAI対応が進む中、デザインシステムにおけるAIとの協調プロトコルや、実装におけるカプセル化の手法も新たな標準を確立しつつある。GoogleのAIデザインツール「Stitch」で採用されていたDESIGN.mdフォーマットがApache 2.0ライセンスでオープンソース化され、主要なコーディングエージェントでの導入が進んでいる。このファイルは、プロジェクトのルートディレクトリに配置することで、AIに対してブランドの視覚的ルールやコンポーネントの設計意図を機械可読な形式で伝達する。
DESIGN.mdの内部構造は、YAMLフロントマターとMarkdown本文の組み合わせで構成されている。YAML部分にはカラーパレットやタイポグラフィなどのデザイントークンが定義され、Markdown部分には「この色は特定のボタンに限定する」といった運用上の制約が記述される。AIにコンポーネントを生成させる際、プロジェクトのトーン＆マナーから逸脱した独自のスタイルが適用される問題を、DESIGN.mdによるルールの明文化が防ぐ。エージェントの推論プロセスにデザインシステムの制約を強制し、開発チームの意図に沿った一貫性のあるアウトプットを継続的に出力させる。
これと並行して、CSSのコンポーネントスコープ機能である@scopeがFirefox 146でのサポートにより、全主要ブラウザで使用可能となった。@scopeを利用すると、特定のコンポーネント内にスタイルを閉じ込めることがネイティブのCSSのみで実現できる。長年にわたりBEMなどの命名規則に依存してきたスコープ管理が、ブラウザの構造的な保証へと移行する。AIエージェントがコードを生成する際にも、@scopeを用いることで他のコンポーネントとのスタイルの衝突を物理的に防ぐことができ、AI生成コードを本番環境へ適用する際の安全性が劇的に向上する。
さらに、5月20日に正式リリースが確定したWordPress 7.0の動向も、AIエージェント時代のWebインフラの変化を暗示している。今回のリリースではWeb Client AI APIの統合といった基盤のアップデートが含まれている。世界のWebサイトの大きなシェアを占めるWordPressのようなCMSが、生成AIのAPIをコア機能に統合し、出力するマークアップの品質を向上させていくことは、Agentic Browsingの普及を後押しする大きな要因となる。開発現場では、AIエージェントによる操作を前提とした設計方針への切り替えが、プラットフォームレベルでの対応を伴いながら進行していく。