AI・SEO対策

Lighthouse 13.5の「エージェント監査」、0点は欠陥とは限らない｜日本語30サイト実測で分かった読み方

2026年9月24日日高駿12分で読めます

「Lighthouse で0点が出た。直さなければ」。レポートを受け取った担当者は、まずそう読みます。2026年9月18日に公開された Lighthouse 13.5.0 は、Agentic Browsing カテゴリに ARD（Agentic Resource Discovery）の監査 ard-schema を加えました。llms.txt の監査と同じ「エージェントの発見」のグループです。点が付けば、本社やクライアントへの説明が要ります。ところが日本語の公式サイト30件に当ててみると、0点やN/Aの中に、サイトの欠陥ではなく測る側の条件で決まったものが混ざっていました。

結論から書きます。llms-txt と ard-schema の0点・N/Aは、そのままサイトの状態を表してはいません。表示と実態のずれを生んでいたのは三つ。取得の時間切れ、存在しないURLへの200応答、CDNが返した403です。直す前に、その0点が「サイトの欠陥」なのか「測定条件」なのかを分けるところから始めてください。

取込層（LLMO）の話です。エージェントがサイトの案内ファイルを取りに来たとき、何が返っているか。その返り方を Lighthouse がどう採点するかを、ソースコードと実測で突き合わせました。

KEY POINTS

項目	内容
測定	日本語の公式サイト30件（日本に進出した韓国7・米国8ブランドの日本語サイト15件＋日本企業15件）。任意に選んだもので、無作為抽出ではない。2026年9月24日、Lighthouse 13.5.0・Chrome 153 で Agentic Browsing カテゴリのみ実行
llms-txt の0点	2回の計測を合わせた集計で30件中10件。うち6件はファイルの取得失敗による0点（タイムアウト4件、それ以外の取得エラー2件）で、4回実行して4回とも再現。curl で404を確認できたのは6件のうち4件（2件は判定不能）
ard-schema の0点	30件中4件。4件全てが、存在しないURLにHTMLをHTTP 200で返すソフト404によるもの
「ある」のにN/A	salesforce.com は llms.txt を公開しているが、Lighthouse の取得には CDN（Akamai）から403が返り「該当なし」
監査が見る場所	13.5.0 は /.well-known/ai-catalog.json を見る。8月26日付の ARD 仕様 v0.91 が定める /.well-known/ard.json は見に行かない
ARDファイルの保有	標本30件＋自社2件のうち判定できた30件で、ard.json・ai-catalog.json のどちらかを置いていたのは0件（2件は判定不能）

Lighthouse 13.5 で増えた監査と、その点数の性格

Agentic Browsing は実験段階のカテゴリで、0〜100の総合点を持ちません。

このカテゴリは、2026年5月7日の Lighthouse 13.3.0 で標準の設定に加わりました。9月18日の 13.5.0 で ard-schema 監査が追加され、llms.txt と ARD の二つの監査が「agent discovery」のグループに入っています。リリースノートには、この版が Chrome 156 の DevTools に載り、PageSpeed Insights には「within 2 weeks」で反映される見込みだとあります。あくまで見込みで、PSI での表示は私たちもまだ確かめていません。

Chrome の公式ドキュメントは、このカテゴリを「experimental」と明記し、テストには Chrome 150 以降が必要だとしています。点数の付け方も、パフォーマンスなど他のカテゴリとは違います。

"the Agentic Browsing category does not have a weighted average score from 0 to 100. Because the standards for the agentic web are still emerging, the current focus is to gather data and provide actionable signals rather than a definitive ranking."
Chrome for Developers「Lighthouse agentic browsing scoring」

Lighthouse はURLを渡せば国や言語を問わず動くツールで、日本語サイトにもそのまま使えます。ただ、13.5.0 のリリースノートにも採点のドキュメントにも、Google 検索の順位と結びつける記述は見当たりません。ここでの0点を検索順位の問題として読む根拠は、今のところ一次資料にない。

30サイトの測り方と、この数字の限界

標本は任意に選んだ30件で、日本のサイト全体を代表するものではありません。

標本は二つのグループです。一つは、日本に進出した韓国7・米国8ブランドの日本語公式サイト15件。家電、食品、化粧品、自動車、ファッション、SaaS、決済など、業種が重ならないように選びました。もう一つは日本企業の公式サイト15件で、うち6件は9月10日の記事（その「llms.txt 200 OK」、中身はHTMLです）で llms.txt を測ったサイトと重なります。重なる6件には、比較のため、HTMLを返すソフト404のサイトを意図的に多めに入れています。

計測日は2026年9月24日です。Lighthouse 13.5.0 を Chrome 153（headless）で動かし、Agentic Browsing カテゴリだけを既定の設定（モバイル・エミュレーション）で実行しました。回線は福岡の1か所。1回目の計測中に手元の回線が不安定になったため、失敗・タイムアウト・想定外の結果が出た20件を同じ設定で測り直しています（タイムアウト系は3回ずつ）。以下の集計は、測り直した20件は2回目の値、残る10件は1回目の値を合わせたものです。同じ日の2回の計測を組み合わせた1回分の結果であり、推移を示す数字ではありません。

もう一点、見落としやすい条件があります。/jp/ のような経路で日本語サイトを置いているブランドでは、llms.txt も .well-known もドメインのルートで判定されます。Lighthouse のコードが /llms.txt をページURLのオリジンから組み立てるためです。つまり、そうしたブランドの結果は日本語サイトではなく、グローバルドメイン全体のものです。なお標本の1件は、確認の結果ブランドの公式サイトではなく売却中のドメインだったため、個別の事例としては扱いません。

「ない」が不合格になる、2秒の壁

llms.txt がないサイトは本来N/Aになるはずが、取得が2秒以内に終わらないか、取得そのものがエラーになると0点になります。

13.5.0 の llms-txt 監査は、判定の順番がはっきりしています。取得でエラーが出れば0点。ステータスが取れなくても0点。5xxなら0点。4xxなら「該当なし（N/A）」。それ以外（200など）が返ったときに初めて、H1見出し・リンク・50字以上の三つで中身を見ます。Content-Type は確認しません。

引っかかるのは取得の上限です。Lighthouse の fetcher は fetchResource(url, options = {timeout: 2_000}) と、既定で2,000ミリ秒を上限にしています。llms.txt の収集処理はこれを引数なしで呼ぶので、2秒を過ぎると「Timed out fetching resource」で終わる。404を返すはずのサイトでも、その404が2秒以内に届かなければ0点です。

今回、取得の失敗で0点になったのが6件でした。小売・EC系が5件、製造業が1件。4件は2秒の上限に当たった「Timed out fetching resource」、2件はタイムアウト以外の取得エラーで「Fetch of llms.txt failed」。1回目に1回、2回目に3回、計4回とも同じ結果が出ています。curl で同じURLを取ると、タイムアウト4件のうち3件と、取得エラー2件のうち1件は404で、ファイルは置かれていません。残る2件は curl でも判定できませんでした。6件のうち少なくとも4件は、ファイルがないのにレポートには不合格として残ります。

同じ Chrome から直接取り直すと、2秒を過ぎてから404が返るサイトや、HTTP/2 のプロトコルエラーでステータス自体が取れないサイトがありました。サーバーやCDNの応答の仕方と、Lighthouse の2秒という条件が重なった結果です。どちらが悪いと決められる話ではありません。

付け加えると、1回目の計測では、ほかにも取得に失敗したサイトがありました。測り直すと消えたため、上の6件には数えていません。同じサイト・同じ設定でも、1回目と2回目で取得の成否が分かれたことになります。

「カタログがない」が「カタログが壊れている」になる

ard-schema の0点4件は、全てソフト404でした。

ard-schema 監査は、カタログの有無を hasCatalog = hasExplicitSignal || ard.status === 200 で決めます。robots.txt やリンクタグでの明示がなくても、/.well-known/ai-catalog.json が200を返せば「カタログあり」。ここでも Content-Type は確認しません。

存在しないURLに、トップページや自前のエラーページをHTTP 200で返すサイトがあります。これがソフト404です。この場合 Lighthouse は返ってきたHTMLをJSONとして検証し、「Malformed JSON in manifest: SyntaxError: Unexpected token '<'」で0点を付けます。レポートの見出しは「ai-catalog.json schema is invalid」。カタログを一度も置いたことのないサイトが、「カタログのスキーマが無効」と表示されるわけです。

該当したのは飲食チェーン1件、ホテル2件、小売1件で、1回目と2回目の計測で同じ結果でした。4件とも /llms.txt にもHTMLが返っていて、llms-txt でも0点です。ソフト404のサイトは、エージェント発見の二つの監査で同時に落ちる。直す場所は一つで、存在しないURLに404を返すことです。

「ある」が「該当なし」になる、CDNの403

N/Aもまた、「ファイルがない」とは限りません。

salesforce.com は /llms.txt に約1MBのテキストファイルを公開しています。curl で取ると200、text/plain。ところが Lighthouse の取得には403が返り、監査はN/Aになりました。403を返したのは CDN の Akamai（AkamaiGHost）です。1回目、2回目、Chrome からの直接取得の3回とも403で、curl は Lighthouse と同じ User-Agent を付けても200でした。どの規則で止められているのかは、外からは確かめられません。

4xxをN/Aにする設計は、ファイルを置いていないサイトを責めないためのものです。その同じ分岐が、WAFなどに止められたとみられるケースも「対象外」として静かに処理する。丁寧に作ったファイルが、レポート上では置いていないのと同じ扱いになります。

監査が見る場所と、仕様が指す場所

13.5.0 の ard-schema は旧パスの ai-catalog.json を見ていて、8月の仕様が定める ard.json は見ていません。

ARD の仕様 v0.91 は2026年8月26日付で、ステータスは Proposal（提案段階）。著者は Google・Microsoft・Hugging Face 所属の3人です。扱う対象は、MCP ツールや A2A エージェントなど、エージェントが呼び出せる資源。発見の手順について、仕様はこう定めています。

"A consumer resolving a domain's entries MUST fetch /.well-known/ard.json, and MUST honour a rel="ard" link."
AgenticResourceDiscovery.org「ARD Specification」v0.91 §5.1

旧パスの ai-catalog.json を見るかどうかは、読む側の任意（MAY）です。公開する側については「There is no need to serve the predecessor path」とあり、旧パスだけに置いたものは見つからない可能性がある、とまで明記しています。

13.5.0 の収集処理が探すのは、rel="ai-catalog" のリンクタグ、同じ rel の Link ヘッダー、そして /.well-known/ai-catalog.json です。ソースコードに ard.json を取りに行く処理はありません。9月22日には、この食い違いを指摘する Issue #17251 が外部の開発者から立てられ、9月24日時点でオープンのままです。Issue は、ard.json だけを置いたサイトについてこう書いています。「it reports notApplicable, not a failure, so nothing in the report says why」。ARD 上は有効な collections 配列付きのマニフェストが0点になる、という別の不具合も同じ Issue で報告されています。

ただし、標本30件と自社2件のうち判定できた30件で、ard.json か ai-catalog.json を置いていたところは0件でした（2件は判定不能）。判定できた範囲では、この食い違いのせいで今、点を落としているサイトはありません。呼び出せるツールやエージェントを公開していないサイトには、そもそもカタログに載せるものがない。気にすべきなのは、これから導入する側です。仕様に従って ard.json に置くと、13.5.0 のレポートにはN/Aと出ます。「見つからなかった」のではなく、「見に行っていない」N/Aです。

レポートに残るのは「その条件で取れたもの」

Agentic Browsing の0点とN/Aは、サイトの状態そのものではなく、Lighthouse がその条件で取れたものの記録です。

本質は点数の高低ではありません。問うべきは、エージェントがそのURLに来たとき、正しいステータスが、時間内に、止められずに返るかどうか。0点の中身を分解すると、手を入れる場所はファイルの中身より手前の、サーバーの返し方にありました。

日本語サイトの担当者が今週やること

自社ドメインで 13.5.0 の監査を回す：Chrome 150 以降の環境で、npx [email protected] https://example.co.jp/ --only-categories=agentic-browsing のように Agentic Browsing だけを実行します。PSI への反映は見込みの段階です。0点が出ても1回で確定させず、時間を置いてもう一度回してください。
0点・N/Aが出たら、curl で実態を分ける：curl -sS -o /dev/null -w "%{http_code} %{content_type} %{time_total}\n" https://example.co.jp/llms.txt を、/.well-known/ai-catalog.json と /.well-known/ard.json にも投げます。404が素直に返るなら「ファイルなし」で、それ自体は欠陥ではありません。200で text/html ならソフト404です。
存在しないURLには404を返す：トップページへのリダイレクトや、エラーページの200応答をCMS・CDN側で止めます。まずは /llms.txt と /.well-known/ 配下から。二つの監査で同時に0点を招いていた原因が一つ消えます。
ファイルを置いているのにN/Aなら、CDN・WAFを疑う：headless の Chrome からの取得がボット対策で止められていないか、CDN・WAFのログで確かめます。
/jp/ 型の日本語サイトは本社と話す：llms.txt も .well-known もドメインのルートで判定されるため、日本側の判断だけでは結果を変えられない場合があります。本社のサイト運用チームとの確認事項に入れてください。
ARD を導入するなら ard.json に置く：仕様が定める場所はそこです。13.5.0 ではN/Aと表示される前提で、Issue #17251 の行方を追ってください。

今後の展望

ツールの採点は、仕様より遅れて動きます。今回の ard.json がその一例で、仕様は8月に場所を移し、9月の Lighthouse は古い場所を見ていました。Issue が閉じれば ard-schema の見る場所は変わり得るし、PSI に載れば、このレポートを目にする人は一気に増える。そのとき0点について問われて慌てないために、今のうちに自社の0点を「欠陥」と「測定条件」に分けておく価値があります。カテゴリ自体が実験段階である以上、点数を目標に据えるより、エージェントが来たときの返り方を整えるほうが長く効きます。

参考資料

#AI検索最適化#LLMO#llms.txt#Lighthouse#日本進出

日高駿

株式会社MenuMenu 代表取締役

ソフトウェアエンジニアであり、UI・UXデザイナー。2012年からシリコンバレーと韓国でプロダクトをつくってきました。SEO・MEO・AEOの専門家として、訪日観光客と日本のローカルビジネスをつなぐMenuMenuを自ら設計・開発しています。

プロフィールを見る →

「見つかっているか」を、数字で確かめませんか。

AIの答え、検索、地図。どこで見つかっていて、どこで見つかっていないのか。まずはサイトを点検し、現状を数字にしてから次の一手を決められます。

診断をはじめる

ブログ一覧に戻る