PageSpeed Insights はこれまで Performance、Accessibility、Best Practices、SEO の 4 項目を採点してきました。2026 年、その行に 5 つ目の項目が静かに加わりました。Agentic Browsing です。これは他の 4 カテゴリが無視してきた 1 つの問いに答えます — 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 を用いて Moto G Power 相当の環境をエミュレートした実行であることを示す表記が現れ、Agentic Browsing は SEO のすぐ隣に並んでいました。つまりこの機能はカナリア限定ではなく、すでに稼働しています。同時に、明示的に未完成でもあります。レポート内のカテゴリ説明はそれを率直に記しています —「本カテゴリは開発中であり、変更される可能性があります」(原文 This category is still under development and subject to change)。
始める前に 1 つ実務的な注意点があります。PSI はこのカテゴリを Google 側で実行します。ページレベルのチェックに Chrome 150 やオリジントライアルは不要です。バージョン要件が生じるのは、Chrome DevTools でのローカル実行です。
自サイトでチェックを実行する
- pagespeed.web.dev を開き、URL を貼り付けます。まずモバイルで実行し、続いてデスクトップでも繰り返します。2 つのラボ実行は別々に採点されるためです。
- ラボデータの完了を待ちます。 上部のフィールドデータは Chrome UX Report から取得され、すぐに読み込まれます。その下の Lighthouse 実行には時間がかかり、カテゴリはそこにあります。
- スコア行を探します。 Performance、Accessibility、Best Practices、SEO が並び、その次に Agentic Browsing が 0〜100 のスコアではなく端数として表示されます。
- カテゴリを展開します。 監査リストは Agent Accessibility、WebMCP、および通常の合格・該当なしのまとまりにグループ化されています。
- 失敗した各監査を開きます。 各行は展開すると、失敗の背景にある具体的なルール、要素、ファイルを示します。これが修正チケットに必要な情報です。
5 つ目のカテゴリは、SEO チームが毎日確認するスコアと同じ行に並んでいます。2026 年 9 月 11 日に PageSpeed Insights で取得。
品質チェック: 同僚と結果を比較する前に、実行詳細で Lighthouse のバージョンを確認してください。PSI は独自のスケジュールで Lighthouse を更新しており、このカテゴリはバージョン間で今も変化しています。
失敗した場合: PSI は重いページで RPC タイムアウトを返すことがあります。調査中に大きなサイトで実際に発生しました。再試行するか、代わりにローカルの Lighthouse でページをテストしてください。
端数のスコアを正しく読む
Agentic Browsing には重みづけされた 0〜100 のスコアがなく、これは意図的な仕様です。Lighthouse のドキュメントは、エージェント型ウェブの標準がまだ形成途上にあるため、ランキングではなく実行可能なシグナルに焦点を置いていると述べています。
実際に重要な計算は次のとおりです。
表示 | 意味 |
|---|---|
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 の< |
Cumulative Layout Shift | 視覚的な安定性。要素の位置に基づいて動作するエージェントが、シフトの途中で誤ったものをクリックしないようにする | なし。常に採点される |
WebMCP ツールが登録されている | ページが宣言的 API または命令的 API を通じて WebMCP ツールを登録しているか | WebMCP の仕組みが検出されなかった |
WebMCP フォームの網羅率 | ツール注釈が欠けている宣言的フォーム | 上記と同じ |
WebMCP スキーマが有効 | 登録されたツールが有効な入力・出力スキーマを公開しているか | 上記と同じ |
展開したカテゴリビュー:失敗 2 件、合格 1 件、該当なし 3 件。失敗リストが作業項目への最短経路です。
3 つの WebMCP 監査が「該当なし」と表示されるのは 2026 年では正常です。WebMCP は提案中の標準で、オリジントライアルと早期プレビューの段階にあり、2 つの API を持ちます。標準的な HTML フォームに注釈を付ける宣言的 API と、JavaScript からツールを登録する命令的 API です。ほとんどのサイトはまだどちらも実装していないため、大半のレポートではそこに灰色の丸が 3 つ並びます。灰色は赤ではありません。失敗として扱わないでください。
チェックが指摘したものを修正する
4 つの修正テーマが 6 つの監査をカバーします。3 つの WebMCP 行は、実際にエージェントツールを出荷している場合にのみ対応が必要です。
アクセシビリティツリーをエージェントが読めるようにする
エージェントはアクセシビリティツリーをページの主要な地図として頼りにします。そこにはロール、名前、状態が列挙されます。アクセシブルな名前のないボタンは、エージェントにとって、そしてスクリーンリーダー利用者にとって行き止まりです。
対応: 展開した監査から、失敗しているルールを順に処理します。よくあるのはアイコンのみのボタン、ラベルのないフォームフィールド、テキストが「こちらをクリック」だけのリンク、無効な ARIA ロールの組み合わせ、ARIA から参照される重複 ID です。セマンティック HTML を優先し、label に for 属性を付け、ネイティブ要素が使えない場合はカスタムウィジェットに明示的な role と tabindex を与えてください。
期待される結果: 監査が合格に変わり、通常は同時に標準の Accessibility スコアも改善します。Agentic Browsing 版は同じチェックの焦点を絞った部分集合だからです。
復旧手順: 修正リストが数百要素に及ぶ場合は、1 つずつ追わないでください。ヘッダーのアイコンのみのボタンのような共通コンポーネントを修正し、再実行します。1 つのコンポーネントで数十行が解消されることがよくあります。
書式チェックを通過する llms.txt を出す
これには慎重な人ほど引っかかる罠があります。この監査は /llms.txt の存在だけでなく、ファイルの内容も確認します。生の URL を列挙しただけのファイルは失敗します。チェックは Markdown 形式のリンクを探すからです。
対応: ルートドメインに H1 見出しと本物の Markdown リンクを含む /llms.txt を作成します。
# あなたの会社名
サイトが扱う内容と、その利用方法についての短い説明。
## 主要ページ
- [製品概要](https://example.com/product)
- [料金](https://example.com/pricing)
- [ドキュメント](https://example.com/docs)期待される結果: 監査がグリーンになります。一方 404 は該当なしとして表示され、現時点では許容されます。500 番台の応答や取得エラーは実際の失敗であり、サーバー側の修正が必要です。
品質チェック: ターミナルで自分の /llms.txt を取得し、リンクを数えてください。https://example.com/pricing のように括弧がない形なら、ファイルが公開され人間には読めても、監査は失敗します。
正直な注意点を 1 つ。Google Search は llms.txt を使用しません。Google 自身の AI 最適化ガイドは、このファイルについて「Google Search はこれらを無視するため、Google Search におけるサイトの可視性やランキングを損なうことも助けることもない」と述べています。ランキングのためではなく、この慣習を読むエージェントツールのために書いてください。
エージェントが狙えるようにレイアウトを安定させる
レイアウトシフトは以前より重要になっています。ボタンの位置を特定してからその座標をクリックするエージェントは、その 2 つの瞬間の間に広告、バナー、遅延読み込み画像がボタンを 200 ピクセル押し下げると、外してしまいます。
対応: 画像と埋め込みに明示的な width と height(または aspect-ratio)を設定し、広告枠と同意バナーに固定のスペースを確保し、読み込み後に既存コンテンツの上へコンテンツを挿入することを避け、レイアウトを誘発するプロパティではなく transform でアニメーションさせてください。
期待される結果: ラボ実行で Cumulative Layout Shift が 0.1 未満になります。Core Web Vitals が使うのと同じしきい値です。
品質チェック: レポートの Performance 配下にある Layout shift culprits インサイトが、原因となる正確な要素を挙げます。推測するより、そこから始めてください。
WebMCP は後で判断する
3 つの WebMCP 監査は、サイトがツールを登録した場合にのみ採点されます。予約フロー、チェックアウト、サポートフォームなど、エージェントが完了できる構造化されたタスクがあるなら、WebMCP は試作する価値があります。エージェントに DOM から推測させるのではなく、呼び出すべきツールを正確に伝えられるからです。Chrome はこの機能をオリジントライアルとローカルテストフラグの背後で提供しているため、机上の空論ではなく現実的な選択肢です。
自動化する価値のあるタスクがないなら、WebMCP はそのままにしておいてください。灰色の丸が 3 つあっても問題ありません。唯一やってはいけないのは、端数を良く見せるためだけに飾りのツールを登録することです。このカテゴリは準備状態のシグナルであり、それを操作することは目的に反します。
修正を検証する
PSI で同じ URL を再実行し、1 つではなく 3 つを比較してください。端数、個々の監査ステータス、そしてデバイス種別です。修正が、気にしていた当のものを直さずに端数だけ動かすことはありますし、モバイルとデスクトップは別々のラボ結果を生みます。
より速く反復するには、PSI を待たずに Lighthouse をローカルで実行してください。このカテゴリは Lighthouse 13.3 以降に含まれるため、ローカルインストールでも取得できます。DevTools パネル版が必要な場合、Google のドキュメントはカテゴリのテストに Chrome 150 以降が必要で、WebMCP 監査にはオリジントライアルの登録も必要だと述べています。
修正前後の短い記録を残してください。「2026-09-11: モバイル 1/3、a11y ツリーと llms.txt が失敗」といった日付入りの 1 行で十分です。後日のリグレッションが本物なのか、単なる実行間のぶれなのかを教えてくれます。
このチェックがそうではないもの
広く誤解されているため、やらないことを 3 つ挙げます。
- ランキング要因ではありません。 Chrome の発表はこのカテゴリを情報提供目的でベンチマーク対象外と述べています。Google Search のランキングは Agentic Browsing の端数の影響を受けません。
- AI 可視性スコアではありません。 これはエージェントがページを操作できるかを測ります。ChatGPT や Perplexity が回答であなたを引用するかどうかは何も語りません。
- サイトに対する合否判定ではありません。 シンプルなマーケティングページで端数が低い場合、通常は採点対象がほとんどなかったという意味であり、エージェントが締め出されているという意味ではありません。
役立つ視点はこれです。このカテゴリは、訪問者が人間でないときにサイトが持ちこたえるかを確認します。そこで評価されるものはすべて、いずれにせよやる価値があります。セマンティック HTML、安定したレイアウト、ラベル付けされたコントロールです。Google 自身のエージェント向けガイダンスも同じ点で締めくくっています — サイトをエージェント対応にするものは、人間にとってもより良くする、と。
レビューのループに組み込む
エージェント対応は、プラットフォームがチェックリストより速く動いている領域の 1 つです。2 つの習慣で、プロジェクト化せずに最新の状態を保てます。
- テンプレート、ナビゲーション、フォーム、チェックアウトの変更後にチェックを再実行します。それらがアクセシビリティツリーとレイアウト安定性を動かす編集だからです。
- 端数は URL 単位ではなくテンプレート単位で追跡します。10 個の製品ページがすべて同じスコアならそれはテンプレートの問題で、1 つの修正で 10 個すべてが解決します。
PSI のチェックは意図的に狭く、6 つの監査を 1 ページずつ実行します。robots ルール、MCP サーバーカード、OAuth ディスカバリ、エージェントコマースシグナルまで含めた全体像が必要なら、Auspia は無料の Agent Readiness チェックを提供しており、URL をそれらのプロトコル水準の標準に対してスキャンし、比較用のリーダーボードを表示します。
FAQ
Agentic Browsing のスコアは Google のランキングに影響しますか? いいえ。Google はこのカテゴリを情報提供目的と説明しており、Search のランキングシステムの一部ではありません。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 検索のツール、どのチェックに時間を割く価値があるか、そしてそれらを日々の業務にどう組み込むかについて執筆。
