Webの品質を測る物差しとして、Lighthouseほど広く使われているツールはない。パフォーマンス、アクセシビリティ、ベストプラクティス、SEO——この4カテゴリの緑の円グラフは、制作会社と発注側の共通言語として機能してきた。
そのLighthouseに、5つ目のカテゴリが加わった。名前は Agentic Browsing。測るのは「人間に速く表示できるか」でも「検索エンジンに見つかるか」でもない。AIエージェントがあなたのサイトを読み、理解し、操作できるかだ。
何が起きたか：実験的カテゴリから、デフォルトへ
タイムラインを整理する。Agentic Browsingカテゴリ自体は2025年後半にLighthouseへ実験的に追加されていた。有効化には明示的な設定が必要で、目にしたのは意図的にオプトインした開発者だけだった。
転機は2026年5月7日。Lighthouse 13.3.0のchangelogに、次の一行が載った。
「New agentic browsing category added to default config」
デフォルト構成入り。つまり、これ以降のLighthouseを実行すれば、誰でも・何も設定しなくても、Agentic Browsingの監査結果が表示される。リリースノートには、このバージョンがChrome 150のDevToolsに搭載され、PageSpeed Insightsにも2週間以内に反映される見込みと記されている。実際、PSIのWeb画面ではその後Agentic Browsing監査が動き始めており、PSI経由でllms.txt監査が実行された報告がGitHubのissueに上がっている。一方でリポジトリには、Lighthouse ViewerがPSIのAPIを呼ぶ経路でagentic-browsingを無効化するコミット（#17041）も入っており、実行経路によって扱いが分かれている。「全面展開済み」と断定するには早いが、方向は明確である。
この変化の意味は、機能の追加そのものより可視性の反転にある。昨日まで「知っている人だけが見る実験」だったものが、今日からは「Lighthouseを回す全員——顧客も、上司も、競合調査中の誰かも——の目に入る標準項目」になった。Core Web Vitalsのときと同じ構図だ。Lighthouseにカテゴリが載ると、およそ1〜2年で業界の共通言語になる。
あえて0〜100点にしない、という設計
他の4カテゴリと決定的に違う点がある。Agentic Browsingには、おなじみの0〜100の加重スコアがない。
公式のスコアリング解説は理由をこう説明する。エージェンティックWebの標準はまだ形成途上であり、現時点の焦点は確定的なランキングではなく、データ収集と実行可能なシグナルの提供にある——。代わりに表示されるのは、合格したチェック数の比率（「4/6」のような分数表示）、監査ごとのPass/Fail、そして参考情報としてのカウントだ。
これは弱気な設計ではなく、正直な設計だと読むべきだ。Performanceスコアの加重が成立するのは、LCPやCLSといった入力が安定し、重みがユーザー体験の実測と較正されているからで、Agentic Browsingの入力にはまだその成熟がない。存在しない精度を装った単一スコアを出すより、pass/failの束を出す——標準形成期の計測として筋が通っている。
もうひとつ、設計の性格をよく表す事実がある。DebugBearの検証によれば、AI向けの新機能を何も実装していないことだけを理由にこのカテゴリで落第することはなく、素のexample.comは2/2の緑スコアを取る。減点法ではなく、実装したものの品質を見る加点的な観測——これがこのカテゴリの現在の性格だ。
6つの監査は、4つの領域に分かれる
カテゴリの中身は、4領域6監査で構成される。
順に見ていく。
WebMCP統合（3監査）。LighthouseはChrome DevTools Protocol（CDP）のWebMCPドメインを呼び出してツール登録イベントを監視し、HTMLで定義する宣言的ツールとJavaScriptで定義する命令的ツール（document.modelContext.registerTool。従来のnavigator.modelContextはChrome 150で非推奨になった）の両方を検証する。監査は3つ——登録済みツールの列挙、宣言的注釈のないフォームの検出、スキーマの妥当性検証。なおWebMCP監査の実行にはオリジントライアルへの登録が必要で、標準としてはまだ提案段階にある。WebMCPそのものの設計思想と実装は当サイトのWebMCP連載で詳しく扱ったので、ここでは繰り返さない。重要なのは、提案段階の標準を、Googleが監査ツールに載せて観測を始めたという事実のほうだ。
発見可能性（llms.txt、1監査）。llms.txt監査はドメインルートにファイルが存在するかを確認し、存在する場合はH1見出しの欠落、分量の不足、リンクの不在をチェックする。この項目には後述する大きな矛盾がある。
エージェント向けアクセシビリティ（1監査）。エージェントはアクセシビリティツリーを主要なデータモデルとして利用する。そのためLighthouseは、既存のa11y監査から機械的インタラクションに重要なサブセット——すべてのインタラクティブ要素にプログラム的な名前があるか、ロールと親子関係が有効か、操作可能なのにツリーから隠れたコンテンツがないか——を抽出して評価する。
レイアウト安定性（1監査）。中身は既存のCLSだ。ただし文脈が変わる。エージェントは時刻Tで「カートに追加」ボタンの位置を特定し、T+1でクリックする。その間にバナーが読み込まれてボタンが200ピクセル押し下げられれば、エージェントは別の何かをクリックする。人間なら目で追従できるズレが、機械にはサイトの故障として観測される。
8割は、すでに知っている仕事である
構造図を眺めると、あることに気づく。6監査のうち純粋な新規投資が必要なのはWebMCPとllms.txtだけで、残り——a11yツリーとCLS——は、この業界が10年言い続けてきた基本の仕事——ラベルを付ける、構造を正しく組む、レイアウトを揺らさない——の再文脈化だ。
これは偶然ではない。AIエージェントはスクリーンリーダーと同じアクセシビリティツリーを読む。ラベルのないアイコンボタン、divで偽装したボタン、視覚的には存在するのにツリーからは見えない要素——スクリーンリーダー利用者を困らせてきたものが、そのままエージェントを困らせる。アクセシビリティへの投資は、1行も書き換えずにエージェント可読性への投資になる。セマンティックHTMLと適切なARIAラベルこそが「機械の目から見たページ」だと、公式ドキュメント自身が明言している。
一方、新顔のllms.txtは矛盾を抱えている。GoogleのJohn Muellerは2026年に遡ること1年以上前、llms.txtを「keywordsメタタグに匹敵する」と評した。サイト運営者の自己申告にすぎず、主要なAIサービスは利用を表明しておらず、サーバーログを見ればチェックすらされていないことがわかる——という趣旨だ。その会社の監査ツールが、いまllms.txtの存在と品質を検査している。
矛盾に見えるが、読み方はある。前述のとおり、このカテゴリの現在のミッションは「ランキング」ではなく「データ収集」だ。Lighthouseがllms.txtを監査するのは「作れ」という推奨ではなく、提案中の標準が実際にどう書かれ、どう壊れているかを大規模に観測するための計器と解するのが整合的だろう。実務上の含意は明快で、llms.txtは低コストなので置いてもよいが、それで何かが起きると期待すべき根拠は現時点でない。
実測すると、手入れされたサイトでも厳しい
では、普通に運用されているサイトはどのくらいのスコアが出るのか。
ドイツのSEOコンサルタントが2026年6月に自サイトで行った実測では、SEO 100点・Best Practices 96点・Accessibility 89点という手入れされたサイトが、Agentic Browsingでは33%（1合格・2不合格・3非該当）だった。合格したのはCLSのみ。Yoastが自動生成したllms.txtは「推奨形式に従っていない」として不合格、アクセシビリティツリーも「well-formedでない」と判定され、WebMCPの3監査はツール未実装のため非該当。従来カテゴリの高得点とAgentic Browsingの結果が連動しない——これがこの監査の測っているものの独立性を、期せずして示している。
untype.jpでも実測した。2026年7月2日、npmのCLI（この時点の最新は13.4.0。デフォルト化された13.3.0からさらに一つ進んだバージョンだ）で実行した結果は、Agentic Browsing 2/3。WebMCPの3監査はツール未登録のため非該当で、適用された3監査の内訳はこうなった。
CLSは0で合格。llms.txtは「推奨に準拠」と判定され合格——前出の事例では自動生成のllms.txtが形式不備で落ちていたが、見出し・分量・リンクの要件を満たして書けば普通に通る。不合格はアクセシビリティツリーの1監査だけだった。
興味深いのは、その失敗の中身である。指摘はただ一点——ヘッダーのロゴリンク（<a href="/">）に判別可能なテキストがない、というものだった。SVGのロゴを包むリンクにaria-labelがなく、アクセシビリティツリー上は「名前のないリンク」になっている。人間の目にはロゴが見えているので誰も困らない。だが機械の目には、行き先不明のリンクがページの先頭に座っている。SEO 100点、Accessibility 88点のサイトでも、エージェント向けに抽出されたa11y監査はこの1件で二値的に不合格を返す——従来カテゴリとの非連動を、自分のサイトで確認することになった。
そこで実際にロゴリンクにaria-labelを足し、SVGをaria-hidden化してデプロイし、同日中に再実測した。判定は3/3に変わった。指摘から満点までの所要は、属性の追加とデプロイ1回である。なお付記しておくと、監査の指摘が同種の問題を網羅するとは限らない。人手でコードを洗い直すと、アイコンのみのボタンなど同種のラベル欠落は他にも見つかった。監査の合格は「検出された問題がない」ことの証明であって、問題がないことの証明ではない——これは従来のa11y監査と同じ制約だ。
実行方法は2つある。Chrome 150以降のDevToolsのLighthouseタブで実行するか、環境に依存しない方法としてnpmのlighthouseパッケージ（13.3.0以降）をCLIで実行するかだ。CLIはPuppeteer経由で監査を走らせるため、CI/CDへの組み込みや定点観測にはこちらが向く。
優先順位：新しい札を買う前に、手持ちの札を磨く
企業サイトの実務者が今やるべきことを、投資対効果の順に並べる。
第一に、アクセシビリティツリーの健全化。すべてのボタン・リンク・フォーム項目にプログラム的な名前を与え、セマンティックHTMLを使う。これはa11y・SEO・エージェント可読性の3方向に同時に効く、最も割のいい投資だ。第二に、CLSの撲滅。画像への寸法指定、広告・埋め込み領域の事前確保という定石で足りる。第三に、llms.txt。低コストなので置く判断はありだが、優先度は低い。置くなら監査が見るH1・分量・リンクの要件は満たすこと。第四に、WebMCP。オリジントライアル段階なので全面展開は時期尚早だが、検索や問い合わせなど高価値なアクション1つで試験導入し、標準の固まり方を実地で追う価値はある。
もうひとつ、この監査を過大評価しないための視点を図にしておく。
Agentic Browsingが検査するのは、単一ページの技術シグナル——3層構造の最下層だ。ここに合格することは必要条件であって十分条件ではない。サイト全体としてエージェントに意味が通る情報設計になっているか、同業他社と比べてどの位置にいるか、実際にエージェントがタスクを完了できるか——上の2層は、Lighthouseの視野の外にある。当社がAIエージェント互換性診断で扱ってきたのは主にこの上位層で、両者は競合ではなくレイヤーの分担だと私たちは捉えている。
監査「対象」と監査「実行者」——二層で進むエージェント化
最後に、少し引いた視点を置いておきたい。
Lighthouseの周辺では、もうひとつの動きが同時進行している。Chrome DevToolsのエージェント連携機能により、コーディングエージェントがLighthouse監査（a11y、SEO、Best Practices、そしてAgentic Browsing）を自律的に実行し、結果を読んで修正コードを提案できるようになった。つまり——
エージェントに読まれるためのWebを、エージェント自身が監査し、エージェント自身が直す。
「監査対象としてのエージェント対応」と「監査実行者としてのエージェント」が、同じツールチェーンの中で噛み合い始めている。前例はある。Core Web Vitalsは2020年5月に発表され、翌2021年6月から8月にかけて検索ランキングシグナルに段階的に反映され、ほどなくWeb制作の発注要件にも入った。発表から業界の共通言語化まで、おおよそ1〜2年。Agentic Browsingが同じ経路をたどるかはまだ確定していない——スコアリング設計が示すとおり、Google自身が観測フェーズだと言っている。ただ、観測装置が全員の手元に配られたという事実だけは、もう確定している。物差しが配られたら、次に来るのは比較だ。
参考情報
この記事をシェアする
