WEBサイトLighthouse 13.5にAIエージェント向けカタログの検査が入った。探す名前は、仕様が「前身」と呼ぶai-catalogの側だった ── 置くか置かないかを決めて確かめる14項目（2026年10月時点）
Lighthouse 13.5にAIエージェント向けカタログの検査が入った。探す名前は、仕様が「前身」と呼ぶai-catalogの側だった ── 置くか置かないかを決めて確かめる14項目（2026年10月時点）
目次
01 何が起きたか — Lighthouse 13.5.0にARDの検査が入り、探しに行く名前は仕様が「前身の名前」と呼ぶ側だった
Lighthouse v13.5.0の「New Audits」に、検査が1つ載った
Lighthouseの公開ページ（GitHub）にある「v13.5.0」のリリースを、2026年10月5日に開いた。「New Audits」（訳: 新しい検査）の欄には、次の1行だけが載っている。
"ard-schema: add Agent Resource Discovery audit (#17168)"
（訳: ard-schema: Agent Resource Discoveryの検査を追加する（#17168））
同じページには、いつ使えるようになるかの見込みも書かれている。
"We expect this release to ship in the DevTools of Chrome 156, and to PageSpeed Insights within 2 weeks."
（訳: このリリースは、Chrome 156の開発者ツールと、2週間以内にPageSpeed Insightsに搭載される見込みである。）
リリースのページには、公開の日時が「18 Sep 16:18」と表示されている。ページのHTMLには、日時の値としてdatetime="2026-09-18T16:18:20Z"（訳: 2026年9月18日16時18分20秒、UTC）があり、年は2026年と分かる。この値はUTC（協定世界時）なので、日本時間では9月19日の1時18分にあたる。この記事では、UTCの日付で「2026年9月18日」と書く。PageSpeed Insightsに入ったかどうかは、確かめていない。
検査の名前は「ard-schema」で、Agentic Browsingのカテゴリに入る
変更の説明は、次のとおりである。
"Adds the Agentic Resource Discovery (ARD) schema conformance audit (ard-schema) to Lighthouse under the agentic-browsing category."
（訳: Agentic Resource Discovery（ARD）のスキーマへの適合を調べる検査（ard-schema）を、agentic-browsingのカテゴリのもとでLighthouseに加える。）
なお、正式な名前の綴りが文書によって揃っていない。リリースの欄は「Agent Resource Discovery」、変更の説明と仕様のページは「Agentic Resource Discovery」と書いている。この記事は、略称のARDで統一する。検査の表示名は、合格のときが「ai-catalog.json schema is valid」、不合格のときが「ai-catalog.json schema is invalid」である（Lighthouse 13.5.0のソースにある文字列）。
検査が探しに行く手がかりは、4つある
13.5.0のソースを読むと、この検査は、まず次の順に「カタログの場所」を決めている。
- robots.txtの中の、「Agentmap:」で始まる行の値
- ページの中にある、rel属性にai-catalogを含むlink要素のhref（headの中に限らない）
- HTTPレスポンスのLinkヘッダーのうち、relがai-catalogのもの（ページを読み込む形の実行のときだけ）
- 上の3つが無いときは、固定の場所/.well-known/ai-catalog.json
決まった場所のファイルを取得して、JSONとしての形と、いくつかの決まりを検査する。仕組みの詳細は、04章の表と、07章の手元の確認にまとめた。
仕様の側は、新しい名前に変わっている
ARDの仕様のページは、冒頭に次の3つを書いている。バージョンはv0.91、状態（Status）はProposal（訳: 提案）、日付は2026年8月26日である。
そのページの「Discovery」の節は、読み取る側の決まりとして、/.well-known/ard.jsonを取得することと、rel="ard"のリンクを尊重することを定めている。そして、前の名前については、こう書いている。
"ARD's predecessor specified the path /.well-known/ai-catalog.json and the link relation ai-catalog; a consumer MAY additionally consult these, and a consumer that does treats them as equivalent entry sources."
（訳: ARDの前身は、/.well-known/ai-catalog.jsonというパスと、ai-catalogというリンクの関係名を定めていた。読み取る側は、これらも追加で参照してよく、参照する場合は同等の入口として扱う。）
公開する側への案内も、同じ節にある。
"A resource that remains only at /.well-known/ai-catalog.json may not be found, since consulting that path is optional for consumers — a publisher on the predecessor path SHOULD move to ard.json."
（訳: /.well-known/ai-catalog.jsonにしか無い資源は、見つからないかもしれない。読み取る側にとって、そのパスの参照は任意だからである。前身のパスで公開している側は、ard.jsonへ移るべきである。）
つまり、検査と仕様で、探す名前が食い違っている
Lighthouse 13.5.0が探す4つの手がかりのうち、ファイルの名前・linkのrel・Linkヘッダーの3つは、仕様が「前身」と呼ぶ名前の側である。仕様の現在の名前（ard.jsonとrel="ard"）は、13.5.0のソースには出てこない。robots.txtの「Agentmap:」の行だけが、両方に共通している。
仕様のページには、Linkヘッダーを使う方法の記載が、取得した本文の中に見つからなかった。13.5.0は、仕様に書かれていない入口も探していることになる。
この記事が書くことと、書かないこと
この記事は、Lighthouseそのものを実行した結果を載せていない。ソースコード（v13.5.0）を読んだ内容と、検査の部品だけを取り出して実行した結果を載せている。そして、「ARDを置かないと評価が下がる」とは書かない。Lighthouseの採点を説明する公式のページ（最終更新2026年5月5日）には、ARDの記載が無かった。
02 なぜ・背景 — AIエージェント向けの案内を置く話は、提案の段階にある
ARDが解こうとしている問題
ARDの仕様の「Motivation」（訳: 動機）の節は、AIが外部の道具や別のエージェントを使うとき、利用者や開発者が使う前に1つずつ「導入」して、あらかじめ組み込む形になっている点を問題としている。そのうえで、検索エンジンがウェブページを見つけるように、エージェントも検索で見つけられる形を目指している。
仕様がこの文書で「エージェントの資源」と呼ぶのは、MCPの道具、A2Aのエージェント、スキル、その他の呼び出せるサービスである。記事を読ませるためのページではなく、呼び出して使う窓口が対象になっている。
仕様は「提案」であり、作者の所属は複数にまたがる
仕様のページの冒頭には、著者として3人の名前と所属が並んでいる（Googleの人、Microsoftの人、Hugging Faceの人）。状態は先に書いたとおりProposalで、バージョンはv0.91である。決まった標準というより、複数の会社の人が出した提案が、版を重ねている段階と読める。
前身の名前（ai-catalog）の仕様と今の仕様の関係については、Lighthouseのソースの先頭のコメントが「ARD Spec 1.0 / ADR-0003」と書いている。一方、取得した仕様のページの本文には、「specVersion」という語が1件も無かった。検査の部品が必須とする項目（07章）と、仕様のページの書き方が、同じ版を指しているかどうかは、この記事では確かめていない。
Lighthouseの「Agentic Browsing」は、実験的なカテゴリである
Lighthouseの公式のページは、このカテゴリについて、こう書いている。
"Note: The Agentic Browsing category and WebMCP support are experimental and based on proposed standards."
（訳: 注意: Agentic Browsingのカテゴリと、WebMCPへの対応は、実験的であり、提案段階の標準に基づいている。）
採点の方法も、ほかのカテゴリとは違う。
"Unlike other Lighthouse categories, the Agentic Browsing category does not have a weighted average score from 0 to 100."
（訳: ほかのLighthouseのカテゴリと違い、Agentic Browsingのカテゴリには、0から100までの加重平均の点数が無い。）
代わりに、確認項目のうち何個を満たしたかの割合が表示される。13.5.0の設定ファイルを読むと、このカテゴリには7つの検査が入っていて、どれも重みは同じ1である。ard-schemaは、llms-txtと同じ「Agent Discoverability」（訳: エージェントからの見つかりやすさ）の区分に置かれている。
公式の採点ページには、ARDの記載がまだ無い
Lighthouseの採点を説明するページ（最終更新2026年5月5日）の本文には、「ARD」も「ai-catalog」も出てこなかった。発見のされやすさの項目として書かれているのは、llms.txtだけである。13.5.0のリリースの後に、ページが更新されるかどうかは、確かめていない。
03 用語 — 似た名前が多いので、先にそろえる
ARDとai-catalog
用語
ARD：Agentic Resource Discoveryの略称で、AIエージェントが使える資源（MCPの道具やエージェントなど）を、公開する側が説明し、探す側が見つけるための仕様である。ai-catalog：その前身の仕様が使っていた名前で、ファイルがai-catalog.json、リンクの関係名がai-catalogだった。現在の仕様は、ard.jsonとrel="ard"を使う。
エントリとrepresentativeQueries
用語
エントリ：1つの資源を説明するひとまとまりの記述である。仕様は、identifier（探すための名前）・displayName（人が読む名前）・type（資源の種類）・urlまたはdata（本体の場所または中身）を必須としている。representativeQueries：その資源が答えられる、自然な文の質問の例である。仕様は2〜5個を勧めている。
Agentmap
用語
Agentmap：robots.txtの中に「Agentmap: https://example.com/entries.json」の形で書く、エントリの置き場を示す行である。ほかの方法と並ぶ、見つけてもらうための入口の1つとして、仕様が挙げている。
「対象外」と「不合格」の違い
用語
対象外（Not Applicable）：Lighthouseで、その検査をする前提が無いサイトに付く表示で、合格にも不合格にも数えられない。不合格：検査の前提はあるが、条件を満たさないときの表示である。この記事の核心は、置いていないサイトは「不合格」ではなく「対象外」になるという、ソースの読み方にある（04章）。
04 型別 — 自社に関係があるか、何が測られていないか、どの順で確かめるか
🅰 この検査が関係するサイト
ARDが対象にするのは、AIエージェントが呼び出せる窓口である。次のどれかを公開しているなら、関係がある。
- MCPサーバー（AIが道具として呼び出せるもの）
- 別のAIエージェントが話しかけられる窓口
- AIに渡して使わせるための、スキルの配布場所
会社の紹介・記事・店舗の案内が中心のサイトは、このどれにも当てはまらない場合が多い。そのときは、置くものが無い。置くものが無いのにファイルを置くと、中身を空にするか、実在しない窓口を書くことになる。
🅱 この検査が測っていないこと
ard-schemaが測るのは、置かれたファイルがJSONとして正しい形かどうかである。次のことは、測っていない。
- 検索順位や、AIの回答への表示にどう影響するか（この検査が測る範囲に、順位や回答への表示は含まれていない）
- AIエージェントが、実際にそのファイルを読みに来るか
- ファイルの中に書かれた窓口が、本当に動いているか
- 説明の文が、利用者の質問に合っているか
注意
「Lighthouseで合格した」ことは、「AIエージェントに見つけてもらえる」ことを意味しない。この検査が確かめるのは、ファイルの形だけである。見つけてもらえるかどうかは、この検査では分からない。
🅲 確かめる手順
手順は5つである。表は、検査と仕様で探す名前を並べたものである。
| 手がかり | Lighthouse 13.5.0（ソースを読んだ結果） | ARD仕様 v0.91（本文の記載） |
|---|---|---|
| robots.txt | 行頭が「Agentmap:」の行の、最初の値を使う（大文字と小文字は区別しない） | 「Agentmap:」の行で、エントリの置き場を示せる |
| ページ中のlink | relにai-catalogを含むlink要素のhref | rel="ard"のlink要素。ai-catalogは前身の名前 |
| Linkヘッダー | relがai-catalogのもの（ページを読み込む形の実行のときだけ） | 取得した本文に記載が見つからなかった |
| 固定のパス | /.well-known/ai-catalog.json（上の3つが無いとき） | /.well-known/ard.json。ai-catalog.jsonは前身のパス |
手順1 — 2つのファイル名と、3つの入口を開く
/.well-known/ai-catalog.jsonと/.well-known/ard.jsonを、ブラウザで開く。robots.txtで「Agentmap:」を探し、トップページのソースでai-catalogとrel="ard"を探し、レスポンスのLinkヘッダーを開発者ツールで見る。ここまでは、5分で終わる。
手順2 — 「存在しない場所」の返事を確かめる
ファイルが無い場所に、どんな返事が来るかを確かめる。404が返れば、Lighthouseは「対象外」にするとソースから読める。一方で、無い場所にもサイト共通の画面を、ステータス200で返す作りのサイトでは、事情が変わる。ステータスが200だと、カタログがあるものとして扱われ、中身がJSONでなければ、JSONの形の誤りとして数えられる、とコードからは読める（実行しては確かめていない）。
手順3 — 窓口を数える
自社が公開している、AIエージェントが呼び出せる窓口の数を、担当者に聞いて数える。0なら、置かない。1以上なら、窓口ごとに「名前・種類・説明の場所」を1行の表にする。
実務のヒント
「置かない」と決めたときも、日付・決めた人・理由を1行で残す。数か月後に仕様が変わったとき、何を根拠に置かなかったかが分かる。
手順4 — 置くなら、ARDの手順の雛形から始め、必須の項目を足す
ARDの公式サイトの「How to publish」（訳: 公開の方法）は、ard.jsonの雛形を載せている。ところが、その雛形は、Lighthouse 13.5.0の検査部品に通すとエラーになる。理由と結果は、07章に書いた。
手順5 — 3か月後に、公式の更新日を見直す
仕様はProposalで、Lighthouseのカテゴリは実験的である。名前は、また変わりうる。リリースノートと仕様のページの更新日を、3か月後に開き直す予定を、先に入れておく。
05 明日、自社で確認するチェックリスト
次の14項目は、1項目あたり5分ほどでできる作業である。項目1〜6が手順1と2、項目7〜9が手順3、項目10〜12が手順4、項目13と14が手順5に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- ブラウザで、自社のドメインの「/.well-known/ai-catalog.json」を開き、結果を「404」「JSON」「そのほか」のどれかで書き留める
- 同じ手順で「/.well-known/ard.json」を開き、結果を項目1の隣に書く
- 2つのアドレスに、curlで「curl -s -o /dev/null -w '%{http_code}'」を実行し、ステータスの数字を記録する。200が返ったら、本文の最初の1行を見て、JSONかHTMLかを書く
- robots.txtを開き、「Agentmap:」で始まる行の数を数えて、数字で書く
- トップページのソースを表示し、「ai-catalog」と「rel="ard"」を検索して、見つかった数を書く
- 開発者ツールのNetworkで、トップページの読み込みを選び、レスポンスヘッダーにLinkが無いかを確認する。あればrelの値を書き写す
- 社内の担当者3人に、AIエージェントが呼び出せる窓口（MCPサーバー・エージェント・API）を公開しているかを聞き、窓口の数を数字で書く
- 窓口が0なら、「置かない」と、日付・決めた人・理由を1行で記録に書く
- 窓口が1つ以上なら、窓口ごとに「名前・種類・説明の場所」を、1行ずつの表にする
- 置くなら、表の1行を1つのエントリに写し、identifierを「urn:air:自社のドメイン:種類:名前」の形で書き、representativeQueriesを2〜5個書く
- ファイルの先頭に「"specVersion": "1.0"」を書いたかを確認する（Lighthouse 13.5.0の検査部品は、これが無いとエラーにする）
- 置いたら、Lighthouse 13.5.0以降が使える環境で、Agentic Browsingのカテゴリを実行し、ard-schemaの結果を記録する
- 置く名前を、ard.jsonだけにするか、ai-catalog.jsonも置くかを決め、決めた理由を1行で書く
- 3か月後の日付で、Lighthouseのリリースノートと仕様のページの更新日を開く予定を、カレンダーに入れる
06 代替・他の選択肢 — llms.txtとの扱いの違いを見て、置かない選択も含めて決める
同じ区分にあるllms.txtの検査は、どう扱われるか
13.5.0のソースを読んで、llms.txtの検査と、ard-schemaの扱いを並べた。
| 場面 | llms-txtの検査 | ard-schemaの検査 |
|---|---|---|
| ファイルが無い | 取得の結果が4xxなら「対象外」 | 入口の手がかりが無く、ステータスが200でなければ「対象外」 |
| サーバーの誤り | 5xxなら不合格 | 入口の手がかりが無いときは、5xxでも「対象外」になる、とコードからは読める |
| 中身の条件 | 見出し1が1つ以上・リンクの形が1つ以上・50文字以上 | JSONの形・specVersion・entries・各エントリの必須の項目。誤りがあれば0、警告だけなら0.9 |
| 重み | 1（Agent Discoverabilityの区分） | 1（同じ区分） |
llms.txtの公式の説明ページも、「ファイルが無く404なら対象外」と書いている。
"If the file is not provided by the server (resulting in a 404), the audit is marked as Not Applicable (N/A), as providing the file is optional at the moment."
（訳: サーバーがファイルを提供していない場合（404になる場合）、現時点ではファイルの提供が任意であるため、この検査は「対象外（N/A）」と表示される。）
ard-schemaの説明ページは、取得した範囲では見つからなかった。ただ、ソースの動きは、llms.txtと同じ考え方である。置いていなければ対象外、置いたなら中身を検査する。
置かない選択は、不利になる設計ではない
13.5.0のコードでは、入口の手がかりが無く、固定のパスのステータスが200でなければ、検査は「対象外（score 1・notApplicable）」を返す。カテゴリの割合の数え方の細部は、確かめていない。しかし、少なくとも、置いていないことが、検査の不合格として表示される作りではない。
実務のヒント
報告書にLighthouseの結果を載せる担当者は、「Agentic Browsingの割合が低い」と「ARDを置いていない」を、分けて書く。置いていなければ、その検査は割合に数えられない、と読める。
WebMCPの検査は、また別の準備が要る
Agentic Browsingのカテゴリには、WebMCPの検査も3つ入っている（登録された道具・宣言のないフォーム・スキーマの正しさ）。公式の採点ページは、WebMCPの検査の実行に、WebMCPのorigin trial（訳: 試験的な機能の登録）への登録が要ると書いている。ARDの検査とは、前提が違う。
当サイトの無料ツールで、確認の入口を作る
手順1の前に、公開ページの基本情報を一覧で見たいときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールが使える。metaタグ・見出し・リンク・セキュリティヘッダーを一覧にするが、ARDの有無を判定するツールではない。
Lighthouseの結果をまとめて見たいときは、PageSpeed Insightsを使って最大3ページを測る🔧 WEBサイトの 最大３ページ Lighthouse監査・チェックツールがある（利用には無料の会員登録が必要です）。13.5.0の検査がPageSpeed Insightsに入ったか、このツールの結果にAgentic Browsingが出るかは、この記事では確かめていない。
07 当サイトで確かめたこと
当サイトのトップと入口を、2026年10月5日に確かめた
ブラウザ相当のUAに、確認用の識別子を足して、当サイトを読んだ。結果は次のとおりである。
- /.well-known/ai-catalog.json：404
- /.well-known/ard.json：404
- robots.txt（370バイト）の「Agentmap:」の行：0件
- トップページ（約18万バイト）のlink要素で、relがardまたはai-catalogのもの：0件（二重引用符と単一引用符の両方で探した）
- トップページのレスポンスヘッダーのLink：0件
404の返事は、題名が当サイトの名前になっている画面だった。遮断の画面ではなく、当サイト自身の「見つからない」の画面である。
ソースの読み方に当てはめると、検査は「対象外」になる
入口の手がかりが4つとも無く、固定のパスが404なので、13.5.0のコードを読む限り、当サイトのard-schemaは「対象外」になる。Lighthouse自体は実行していないので、実際の画面での表示は、確かめていない。
当サイトのllms.txtは、隣の検査の3つの条件を満たしている
同じ区分のllms-txtの検査の条件（見出し1が1つ以上・リンクの形が1つ以上・50文字以上）を、当サイトのllms.txtに当てた。ファイルはステータス200で、約12,000バイト（文字数にして約5,900字）あり、3つとも満たしていた。この結果も、検査の部品の条件を手元で当てたもので、Lighthouseの実行結果ではない。
ARDの手順の雛形を、検査部品に通した結果
ARDの公式サイトの「How to publish」の雛形（entriesの1件だけを書いたもの）を、Lighthouse 13.5.0のソースにある検査の部品に通した。
- 雛形そのまま：エラー2・警告1。エラーは「Missing required 'specVersion' root property.」（訳: 必須の項目specVersionが、最上位に無い）を含む。警告は、雛形のtypeが「標準の発見用の種類」の一覧に無いことだった
- specVersion: "1.0"を足す：エラー0・警告1（警告は同じtypeの指摘）
- さらにtypeをapplication/mcp-server-card+jsonに替える：エラー0・警告0
雛形のtypeは「application/mcp-server+json」で、検査部品の一覧は「application/mcp-server-card+json」である。仕様のページにも、後者の書き方がある。つまり、ARDの公式サイトの「How to publish」（訳: 公開の方法）の手順どおりに書いたファイルは、13.5.0の検査では、そのままでは通らない。この結果は、Lighthouse全体ではなく、検査の部品だけを取り出して実行したものである。
当サイトの扱い
この確認の時点では、当サイトでは2つのファイルのどちらも置いていない。ARDが対象にするのは、AIエージェントが呼び出せる窓口であり、記事を読ませるためのページではない。そのため、窓口を公開したときに、置くかどうかを決める。決めたら、日付と理由を記録に残す。
08 このテーマの、これまで
検査が入るまでの、日付つきの記録
| 日付 | 出来事 |
|---|---|
| 2026年5月5日 | Lighthouseの採点のページと、llms.txtの検査のページの最終更新日（どちらも同じ日の表示） |
| 2026年8月10日 | ard-schemaの検査を加える変更（#17168）が提案された（変更のページの表示より） |
| 2026年8月26日 | ARD仕様 v0.91の日付（Status: Proposal） |
| 2026年8月31日 | #17168が統合された（変更のページの表示より） |
| 2026年9月18日 | Lighthouse v13.5.0のリリース（UTCの日付。日本時間では9月19日の1時18分） |
| 2026年10月5日 | この記事のために、リリース・変更・仕様・ソースを開き、当サイトの入口を確かめた |
Chrome 156の開発者ツールとPageSpeed Insightsに入る時期は、リリースのページに「見込み」としてしか書かれていない。入った日付は、この表のどの行にも含まれていない。
当サイトの、関連する過去の記事
AIエージェント向けの案内ファイルについては、当サイトのブログでも書いてきた。
- Google が llms.txt を「不要」と断言した日 ── 公式ガイドの射程と、それでも Perplexity が引用し続ける理由 — llms.txtについて、Googleの公式ガイドが何を言ったかを整理した記録。
- llms.txtを当サイトで実際に設置した — 採用率10%のB2A時代、WEBディレクターが今やるべきこととその正直な現在地 — 当サイトにllms.txtを置いたときの記録。
- llms.txt を置いた1ヶ月後、正直に答え合わせ — 見えていないと思っていたら、実は見えていなかった — 置いてから1か月後の答え合わせの記録。
- llms.txt を置いて51日、正直に答え合わせ第2弾 ── Google が『効かない』と言った以上に、他の AI も読みに来ていなかった — 置いてから51日後の答え合わせの記録。
- 1サイトで測った結果は仮説、2サイトの一致は事実 ── llms.txtを8言語サイトでも測ったら、AIクローラーが1件も来ていなかった — 8言語のサイトでも同じ測り方をした記録。
- 検索は「クリックする場所」から「エージェントが代わりに動く場所」になった — WebMCP・UCPとAgentic Commerce時代の実務チェックリスト — WebMCPなど、エージェントが動く場所の実務の確認項目。
同じ「AIの訪問」を扱った、当サイトの記事は、AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける（2026年9月時点）でrobots.txtとllms.txtの切り分けを、AIエージェントが作ったサイトでも、Googleが見る土台はたった3つ ── 公開前に確認する13項目（2026年9月時点）でAIエージェントが作ったサイトの公開前の確認を、扱っている。この記事は、それらの内容を繰り返さない。
現在の貴方のIPアドレス
このサイトで書いている人
