自社サイトがChatGPTやPerplexityの回答に引用されるかどうか、気になっている方に向けた内容です。今回扱うのは、AIエージェント（人間の代わりにWebページを読み取り操作するソフトウェア）向けにサイトを最適化する新しい計測ツールの話です。
2026年5月7日、Googleの計測ツールLighthouse（Webページの性能・品質を自動採点するツール）のバージョン13.3に、Agentic Browsingという新カテゴリが追加されました。同年8月21日には、VercelとOraがis-agentic.comという別の計測サービスを公開しています。
どちらも問いは同じです。「このサイトはAIエージェントが読める状態か」。ただし答え方が違います。導入前にどちらを見るべきか、あるいは両方見るべきか、判断材料を整理します。
なぜ今この判断が必要になるのか
背景にあるのは「Webの読者が2種類になった」という認識です。人間が見る画面と、機械が受け取るマークアップ（HTMLの生データ）は別物です。
ChatGPTやPerplexityの背後にいる取得クローラー（ページ内容を自動取得するプログラム）は、ブラウザが描画する見た目ではなく、返ってきたHTMLをそのまま読みます。JavaScriptを実行して組み立て直された画面ではなく、素のマークアップです。
つまり、CSR（クライアントサイドレンダリング、ブラウザ側でJSがHTMLを組み立てる方式）に依存したSPA（シングルページアプリケーション）は、人間には正しく見えていても、エージェントには空っぽのHTMLしか渡っていない可能性があります。これはSEOで長年言われてきた「JS実行前のHTMLに実体があるか」という論点と地続きですが、対象読者がGooglebotだけでなくAIエージェントに広がった点が新しいところです。
判断軸1: 何を測ろうとしているか
LighthouseのAgentic Browsingカテゴリは4項目をチェックします。
- llms.txt: サイトの内容をAIエージェント向けに要約するテキストファイル（提案段階の仕様）
- WebMCP: ページが呼び出し可能な「道具（ツール）」をエージェントに宣言する仕組み
- アクセシビリティツリーの一部: エージェントがページ構造を理解する際の主要なデータモデル
- CLS（Cumulative Layout Shift、累積レイアウトシフト）: 表示中に要素がガタつく度合い
一方でis-agentic.comは、実際のURLに対して決定論的な複数チェックを行い、JavaScriptを実行しない状態、つまり取得クローラーが実際に受け取る生HTMLを評価します。見た目のレンダリング結果ではなく「機械が受け取る第一印象」を測る設計です。
両者は測定対象が違うため、片方だけ見て安心するのは早計です。Lighthouse側はChromeとJS実行環境が必要で、ページが実行時にツールを登録することを前提にしています。is-agentic.com側はJSを動かさない生HTML視点です。自社サイトがどちらの前提に近いか、まず切り分けて考える必要があります。
判断軸2: スコアが欲しいか、シグナルが欲しいか
Lighthouseの通常カテゴリ（パフォーマンスやアクセシビリティ）は0〜100の加重平均スコアを出します。しかしAgentic Browsingカテゴリはあえて数値化していません。
公式の説明では、エージェント向けWebの標準がまだ固まっていないため、確定的なランキングではなくデータ収集と実行可能なシグナルの提供に焦点を当てているとされています。得られるのは合格率（パスした項目の割合）で、カテゴリ全体も実験的・開発中の位置づけです。
これは0〜100点文化を作った当のGoogleが下した、あえて数値を出さないという抑制的な判断です。逆に言えば、経営層への報告に「スコア〇点」という単一指標を使いたいチームには、現時点のLighthouseは向きません。合格率や個別チェックの結果を、そのままエンジニアリングの改善リストとして使う運用が現実的です。
判断軸3: 「直す」機能まで欲しいか
エージェント向け診断ツールの中には、問題点だけでなく修正案（優先順位付けされた修正、工数見積もり、コードサンプル）まで出すものがあります。一見親切に見えますが、この機能には注意が必要です。
診断結果は「エージェントが何をできなかったか」という事実です。しかし修正案は「そのコードベースを見たことのない誰かが下す決定」になりがちです。CI/CD（継続的インテグレーション・デリバリー）のオンコール担当が誰か、既存の制約が何かを知らないまま提案された修正を、そのまま本番に入れるのはリスクがあります。
判断軸としては「診断ツールが出す修正案は、あくまで叩き台として扱い、レビューを経てから採用するか」を事前にチーム内で決めておくことをおすすめします。自信ありげな出力と正しい出力は別物、という前提を崩さないことが肝心です。
選択肢の比較
| 観点 | Lighthouse 13.3 Agentic Browsing | is-agentic.com |
|---|---|---|
| 評価対象 | llms.txt・WebMCP・アクセシビリティツリー・CLS | 生HTMLに対する決定論的チェック |
| JS実行 | 必要（Chromeベース） | 実行しない（取得クローラー相当） |
| スコア形式 | 合格率（実験的） | 個別チェック結果 |
| 提供元 | Vercel / Ora |
ケース別の推奨
- SPAやSSR（サーバーサイドレンダリング）を組み合わせた構成で、実行時にツール登録やWebMCPの導入を検討しているなら、Lighthouse 13.3を導入し、まずアクセシビリティツリー周りの既存の警告から確認するのが近道です
- 静的サイトやSSG（静的サイト生成）中心で、JSに依存せずどこまで機械可読かを知りたいなら、is-agentic.comのような生HTML視点のチェックを先に使う方が実態に近い結果が得られます
- 経営層への報告や社内KPIに単一スコアを使いたいなら、現時点のAgentic Browsingカテゴリはスコアを出さないため、別途社内で合格率をベースにした指標を自作する必要があります
- 修正コード生成まで自動化したいなら、少なくとも今のツール群は「診断まで」が主戦場であり、修正の自動採用は避け、人間のレビューを挟む前提で運用してください
あえて見送るべき条件
社内向け管理画面やログイン後にしか到達しないページなど、検索エンジンや外部のAIエージェントがそもそも到達できない領域には、Agentic Browsing対応の優先順位は低くて構いません。
また、標準仕様（llms.txtやWebMCP）自体がまだ提案段階であるため、大規模な恒久対応をこの時点で作り込むのはリスクがあります。Lighthouse側も「実験的」と明言している以上、CIのゲート（合格しないとデプロイをブロックする仕組み）に組み込むのはまだ早いというのが妥当な線引きです。まずは計測だけ行い、閾値運用は仕様が固まってからで十分です。
確認の第一歩
まずChrome DevTools（開発者ツール）のLighthouseパネルを開き、バージョンが13.3以降か確認してください。Agentic Browsingカテゴリが表示されない場合はChromeとLighthouseのアップデートが必要です。
- 手元のプロダクションURLをis-agentic.comに投げて、生HTML視点での結果を先に見る
- 同じURLをLighthouse 13.3のAgentic Browsingカテゴリで計測し、両者の指摘の重なりとズレを確認する
- llms.txtの有無、WebMCPの実装状況、CLSの数値を個別にメモしておく
- 出てきた修正提案はそのまま採用せず、担当者レビューを経る運用ルールを決める
これらは今日から手を動かして確認できる範囲です。仕様が固まりきっていない領域だからこそ、スコアに一喜一憂するより、まず自社サイトが「機械にどう見えているか」を継続的に観察する体制を作ることが実務的な着地点になります。