PageSpeed Insightsは長年にわたり、パフォーマンス、アクセシビリティ、ベストプラクティス、SEOの4項目を採点してきました。2026年、その並びに5つ目の項目が静かに加わりました。Agentic Browsingです。これは、他の4カテゴリが目を向けてこなかった1つの問いに答えます。すなわち、AIエージェントはこのページを実際に扱えるのか、という問いです。
本記事は、このチェックを自分のサイトで使いこなすためのガイドです。実行し、各監査が実際に何を語っているのかを読み解き、修正リストを持ち帰るところまでを扱います。
読み終えたときに得られるもの
対象読者： 人間ではなくAIエージェントがページを閲覧したときの挙動を知りたい、SEO担当者、開発者、サイトオーナー。
読み終えたときに手元にあるもの： 自分のサイトで取得した実際のAgentic Browsing結果、合格・不合格・該当なしを監査ごとに読み解いた記録、優先順位づけされた修正リスト。
前提条件： 公開されているURL、最初の実行に必要な約10分、その日のうちに修正する場合はコードへのアクセス。
完了条件： 分数スコアを監査単位で説明でき、どの失敗が本当にエージェントのタスク完了を妨げているのかを見分けられる状態。
このチェックが生まれた経緯と、いま注目される理由
Agentic Browsingカテゴリは1年前には存在しませんでした。導入は3段階で進み、いずれもGoogleが文書化しています。
- 2026年5月7日： Lighthouse 13.3がこのカテゴリをデフォルト設定に追加し、標準の実行に含まれるようになりました。
- 2026年6月22日： Chrome for Developersブログが「A developer toolkit to make your website agent-ready」でこのカテゴリを発表。エージェント向けDevToolsやWebMCPのガイダンスと並んで紹介されました。
- 2026年7月20日： Lighthouse 13.4.1がPageSpeed Insights API経由でこのカテゴリを有効化し、リリースノートには「2週間以内にPageSpeed Insightsへ届く見込み」と記されました。これにより、一般公開は2026年8月初旬となります。
2026年9月11日にこのチェックを実行したとき、レポートのフッターにはLighthouse 13.4.1によるエミュレーション実行と表示され、Agentic BrowsingはSEOのすぐ隣に並んでいました。つまり、この機能はCanary限定ではなく本番稼働しています。同時に、明確に未完成でもあります。レポート内のカテゴリ説明にも、このカテゴリは開発中であり変更される可能性があると明記されています。
開始前の実務的な注意点を1つ。PSIはこのカテゴリをGoogle側のサーバーで実行します。ページ単位のチェックにChrome 150やオリジントライアルは不要です。バージョン要件があるのは、Chrome DevToolsでローカル実行する場合です。
自分のサイトでチェックを実行する
- pagespeed.web.devを開き、URLを貼り付けます。まずモバイルで実行し、次にデスクトップでも繰り返します。2つのラボ実行は別々に採点されるためです。
- ラボデータの完了を待ちます。 上部のフィールドデータはChrome UX Reportから取得され、すぐに表示されます。その下のLighthouse実行には時間がかかり、カテゴリはそちらに表示されます。
- スコア行を確認します。 パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、そして0〜100のスコアではなく分数で表示されるAgentic Browsingが並びます。
- カテゴリを展開します。 監査リストはAgent Accessibility、WebMCP、および通常の合格・該当なしのまとまりにグループ分けされています。
- 失敗した監査をそれぞれ開きます。 各行を展開すると、失敗の背景にある具体的なルール、要素、ファイルが表示されます。修正チケットにはこれが必要です。
5つ目のカテゴリは、SEOチームが毎日確認するスコアと同じ行に座っています。2026年9月11日にPageSpeed Insightsで取得。
品質チェック： 同僚と結果を比較する前に、実行詳細でLighthouseのバージョンを確認しましょう。PSIは独自のスケジュールでLighthouseを更新し、カテゴリはバージョン間で変化し続けています。
うまくいかない場合： PSIは重いページでRPCタイムアウトを返すことがあります。私も調査中に大きなサイトで遭遇しました。再試行するか、ローカルのLighthouseでテストしてください。
分数スコアを正しく読む
Agentic Browsingには重み付けされた0〜100のスコアがありません。これは意図的な設計です。Lighthouseのドキュメントによれば、エージェントのためのWebの標準はまだ形成途上にあり、ランキングではなく実行可能なシグナルに焦点を当てているからです。
実際に意味を持つのは、この算術です。
表示 | 意味 |
|---|---|
3/3 | 採点対象の監査がすべて合格。該当なしの監査は除外される。 |
1/3 | 1件合格、2件失敗。分母は合格＋失敗した監査のみ。 |
0/3 | 採点対象ですべて合格したものがまだない状態。重い広告入りのページの初回実行でよく見られる。 |
分数なし | すべての監査が該当なし、またはカテゴリが実行されなかった。実行詳細を確認する。 |
罠は、1/3を「エージェント対応度33パーセント」と読んでしまうことです。これは何かの割合ではありません。カウントです。そのページで採点可能だった3つのチェックのうち1つが合格し、該当しなかった監査は計算から完全に除外されています。私が取得したレポートでは、6つの監査が実行され、3つが該当なしで、残りの3つが1/3を生み出しました。
同じページでも実行ごとにスコアは動きます。Lighthouseが挙げる3つの原因は、動的なツール登録（JavaScriptで登録されたWebMCPツールはタイミングによって捕捉されたりされなかったりする）、アクセシビリティツリーを作り変えるDOMの変更、広告・サイズ未指定の画像・注入されたコンテンツによるレイアウトシフトです。数値が揺れるときは、たいていこれが理由です。
6つの監査項目を順に見る
現在のPSIビルドでは6つの監査が実行されます。さらに1つが追加予定です。Lighthouseの開発ブランチでは、新しいAgent Discoverabilityグループの下にai-catalog.json（Agent Resource Discovery）のチェックがすでに追加されているため、このリストはバージョン依存だと考えてください。
監査 | 確認している内容 | 「該当なし」の意味 |
|---|---|---|
アクセシビリティツリーが不正 | エージェントに焦点を当てたアクセシビリティルールのサブセット：プログラム上の名前とラベル、妥当なARIA構造、ツリーから隠されていても操作可能であり続ける要素 | なし。常に採点される |
llms.txtが推奨に準拠していない |
| ファイルが404を返した。llms.txtの欠如は失敗ではなく任意扱い |
累積レイアウトシフト | 視覚的な安定性。要素の位置を基準に操作するエージェントが、シフトの最中に誤ったものをクリックしないようにする | なし。常に採点される |
WebMCPツールが登録されている | ページが宣言的APIまたは命令的APIを通じてWebMCPツールを登録しているか | WebMCPの仕組みが検出されなかった |
WebMCPフォームの網羅 | ツール注釈が欠けている宣言的フォーム | 上記と同じ |
WebMCPスキーマの妥当性 | 登録されたツールが妥当な入力・出力スキーマを公開しているか | 上記と同じ |
展開したカテゴリ表示。失敗2件、合格1件、該当なし3件。失敗リストが最短の作業リストになります。
3つのWebMCP監査が「該当なし」と表示されるのは、2026年時点では正常です。WebMCPは提案段階の標準で、オリジントライアルと早期プレビューの位置づけにあり、2つのAPIを持ちます。1つは標準的なHTMLフォームに注釈を付ける宣言的API、もう1つはJavaScriptからツールを登録する命令的APIです。ほとんどのサイトはどちらもまだ実装していないため、レポートのそこには灰色の丸が3つ並びます。灰色は赤ではありません。失敗として扱わないでください。
指摘された項目を修正する
4つの修正テーマが6つの監査をカバーします。3つのWebMCP行は、実際にエージェント向けツールを提供している場合にだけ対応が必要です。
アクセシビリティツリーをエージェントが読める状態にする
エージェントは、ページの主要な地図としてアクセシビリティツリーに頼ります。そこにはロール、名前、状態が列挙されています。アクセシブルな名前のないボタンは、エージェントにとっても、スクリーンリーダーの利用者にとっても行き止まりです。
対応： 展開した監査に表示される失敗ルールを順に潰します。よくあるのは、アイコンだけのボタン、ラベルのないフォーム項目、テキストが「こちらをクリック」だけのリンク、不正なARIAロールの組み合わせ、ARIAから参照されている重複IDです。セマンティックなHTMLを優先し、ラベルにはfor属性を付け、ネイティブ要素で実現できないカスタムウィジェットには明示的なroleとtabindexを与えます。
期待される結果： 監査が合格に変わり、通常はアクセシビリティのスコアも同時に改善します。Agentic Browsing版は同じチェックの焦点を絞ったサブセットだからです。
行き詰まったときの対処： 修正対象が数百要素に及ぶ場合は、1つずつ追いかけないでください。ヘッダーのアイコンだけのボタンのような共通コンポーネントを直してから再実行します。1つのコンポーネントで数十行が解消することがよくあります。
フォーマット検査を通過するllms.txtを公開する
ここには、丁寧に作業する人ほど引っかかる罠があります。この監査は/llms.txtが存在するかだけを見ているのではありません。ファイルの中身を検査しており、URLを素で並べただけのファイルは失敗します。チェックはMarkdown形式のリンクを探しているからです。
対応： ルートドメインに/llms.txtを作成し、H1見出しと本物のMarkdownリンクを入れます。
# 会社名
サイトの内容と、どう使ってほしいかを短く説明します。
## 主要ページ
- [製品概要](https://example.com/product)
- [料金](https://example.com/pricing)
- [ドキュメント](https://example.com/docs)期待される結果： 監査が緑になります。一方、404は該当なしとして表示され、現時点では許容されます。500番台の応答やフェッチエラーは実際の失敗であり、サーバー側の修正が必要です。
品質チェック： ターミナルで自分の/llms.txtを取得し、リンクの数を数えます。https://example.com/pricingのように括弧なしで並んでいたら、ファイルが公開され人間には読めても、監査は失敗します。
正直な注意点を1つ。Google検索はllms.txtを使いません。Google自身のAI最適化ガイドには、「Google検索はllms.txtを無視するため、サイトの可視性やランキングに良い影響も悪い影響も与えません」と書かれています。ランキングのためではなく、この慣習を読むエージェント向けツールのために書いてください。
エージェントが狙えるようレイアウトを安定させる
レイアウトシフトは以前より重要になっています。ボタンを見つけてからその座標をクリックするエージェントは、その2つの瞬間の間に広告、バナー、遅れて読み込まれる画像がボタンを200ピクセル押し下げると、クリックを外します。
対応： 画像や埋め込みに明示的なwidthとheight（またはaspect-ratio）を設定し、広告枠や同意バナーには固定の領域を確保し、読み込み後に既存コンテンツの上へコンテンツを挿入しないようにし、レイアウトを発生させるプロパティではなくtransformでアニメーションします。
期待される結果： ラボ実行で累積レイアウトシフトが0.1未満になります。Core Web Vitalsと同じしきい値です。
品質チェック： レポートのパフォーマンス欄にある「レイアウトシフトの原因」インサイトが、原因となっている要素を正確に示します。推測せず、そこから始めてください。
WebMCPは後回しで判断してよい
3つのWebMCP監査は、サイトがツールを登録している場合にのみ採点されます。予約フロー、決済、サポートフォームなど、エージェントが完了できる構造化されたタスクがあるなら、WebMCPは試作する価値があります。DOMから推測させるのではなく、呼び出すべきツールをエージェントに正確に伝えられるからです。Chromeはこの機能をオリジントライアルとローカルテスト用フラグの背後で提供しており、思考実験ではなく現実的な選択肢です。
自動化する価値のあるタスクがないなら、WebMCPには手を付けないでください。灰色の丸が3つあることは何も問題ありません。やらないほうがよいのは、分数を良く見せるためだけに飾りのツールを登録することです。このカテゴリは準備状態のシグナルであり、見せかけの対策はその目的を損ないます。
修正を検証する
同じURLをPSIで再実行し、1つではなく3つを比較します。分数、個々の監査ステータス、デバイスタイプです。修正が、気にしていた問題とは別の監査を動かして分数だけ変えることがあります。また、モバイルとデスクトップは別々のラボ結果を返します。
反復を速めたい場合は、PSIを待たずにローカルでLighthouseを実行します。このカテゴリはLighthouse 13.3以降に含まれるため、ローカルにインストールすれば利用できます。DevToolsパネル版を使いたい場合、GoogleのドキュメントによればカテゴリのテストにはChrome 150以降が必要で、WebMCP監査にはオリジントライアルの登録も必要です。
修正前後の短い記録を残しましょう。「2026-09-11：モバイル1/3、a11yツリーとllms.txtで失敗」のような日付入りの1行で十分です。後で発生した劣化が本物か、実行ごとの揺らぎかを見分けられます。
このチェックが意味しないもの
誤解が広がっているため、3つの「しないこと」を挙げます。
- ランキング要因ではありません。 Chromeの発表はこのカテゴリを情報提供目的でベンチマーク対象外としています。Google検索のランキングは、Agentic Browsingの分数の影響を受けません。
- AI可視性のスコアではありません。 エージェントがページを操作できるかを測るもので、ChatGPTやPerplexityが回答であなたを引用するかどうかは何も語りません。
- サイトの合否判定ではありません。 シンプルなマーケティングページで分数が低い場合、通常は採点対象が少なかっただけであり、エージェントが締め出されているわけではありません。
役に立つ見方はこれです。このカテゴリは、訪問者が人間でないときにサイトが持ちこたえるかを確認しています。そこで評価されるものは、いずれも本来やる価値のあることです。セマンティックなHTML、安定したレイアウト、ラベルの付いた操作要素。Google自身のエージェント対応ガイドも同じ結論で締めくくっています。サイトをエージェント対応にすることは、人間にとっても使いやすくすることなのです。
レビューの習慣に組み込む
エージェント対応は、チェックリストよりプラットフォームの進化が速い領域です。プロジェクト化せずに追随し続けるには、2つの習慣で十分です。
- テンプレート、ナビゲーション、フォーム、決済フローを変更した後は、必ずこのチェックを再実行する。これらの編集がアクセシビリティツリーとレイアウト安定性を動かすからです。
- 分数はURL単位ではなくテンプレート単位で追う。10個の製品ページがすべて同じ結果ならそれはテンプレートの問題で、1回の修正ですべて解決します。
PSIのチェックは意図的に狭く、6つの監査を1ページずつ見るだけです。より広い全体像、つまりrobotsのルール、MCPサーバーカード、OAuthディスカバリ、エージェントコマースのシグナルが揃っているかまで知りたい場合は、Auspiaが無料のAgent Readinessチェックを提供しています。URLをプロトコルレベルの標準に照らしてスキャンし、比較用のリーダーボードも表示します。
よくある質問
Agentic BrowsingのスコアはGoogleのランキングに影響しますか？いいえ。Googleはこのカテゴリを情報提供目的と説明しており、検索ランキングシステムの一部ではありません。SEOスコアではなく、エージェント向けの準備状態チェックとして扱ってください。
同じページで2回実行したのに分数が変わったのはなぜですか？動的なツール登録、アクセシビリティツリーを変えるDOMの変更、遅れて発生するレイアウトシフトが、実行ごとのばらつきを生みます。再テストし、分数だけでなく監査リストを比較してください。
3つのWebMCP監査がすべて該当なしになるのはなぜですか？ページがWebMCPツールを登録していないためです。2026年時点のほとんどのサイトで想定される状態であり、失敗ではありません。
llms.txtがないのは問題ですか？この監査では問題ありません。404は該当なしとして扱われます。ただし、存在するが形式が不正なファイルは失敗するので、公開するなら正しく公開してください。
CIで実行できますか？はい、使用しているLighthouseのバージョンにこのカテゴリが入っていれば可能です。監査は設計上決定論的で、だからこそパイプラインのチェックに向いています。ただしWebMCP部分はブラウザ対応とオリジントライアル登録に依存するため、ほとんどのCI環境では該当なしと表示されると想定してください。
この機能を使うのにChrome 150は必要ですか？いいえ。PageSpeed Insightsはサーバー側で実行します。Chrome 150の要件は、DevToolsでローカルにこのカテゴリを実行する場合に適用されます。
著者：Alice Monroe（アリス・モンロー）。Auspiaで150以上のツールを扱うAI SEOツールアナリスト。SEOとAI検索のツール、どのチェックに時間をかける価値があるか、日々の業務への組み込み方を執筆しています。
