AIエージェント用の名簿が引っ越した。Googleの点検ツールは前の住所を見ている

「llms.txt、置いた？」って話、もう一巡したよね。置いたなら安心していい、とは言わない。次のファイルがもう来ている。しかも置き場所が先月変わった。変わったことを、点検する側がまだ知らない。

前回の記事は、人が指で押したチェックインに値段がついた話だった。今日はその真裏。人間が一生見ることのない、機械に向けて自分を名乗るための1枚のファイルの話をする。

「うちはこれが呼べます」を1枚のファイルで名乗る

9月18日、GoogleがサイトチェックツールのLighthouseを13.5に上げた。表示速度やアクセシビリティを測って点数を出す、あれだ。リリースノートに新しい監査がひとつ載っている。名前は ard-schema。Chrome 156のDevToolsと、2週間以内にPageSpeed Insightsにも入る予定だという。

ARDはAgentic Resource Discoveryの略。AIエージェントが「この会社に何を頼めるのか」を自動で見つけるための仕様だ。仕組みは拍子抜けするほど単純で、自分のドメインの決まった場所にJSONを1枚置く。中身は、うちが公開しているMCPサーバー、A2Aのエージェント、APIツール、そういう「呼べるもの」の名簿。あとは登録所がそれを巡回して索引にする。エージェントは「こういうことがしたい」と検索して、見つけて、発行元を確かめてから直接つなぐ。

公開して、巡回されて、検索されて、確かめられて、つながる。Googleの発表を読んでも、書いてあるのはほぼこれだけだ。ドラフトが出たのは6月17日。Googleだけの話ではなくて、Microsoft、Hugging Face、GitHub、Nvidiaあたりが並んで賛同している。Hugging Faceは参照実装を出して、自分のところの名簿も公開した。

仕様を書いた3人の名前が仕様書に載っている。GoogleのJunjie Bu、MicrosoftのR.V. Guha、Hugging FaceのShaun Smith。真ん中のGuhaは、RSSとRDFとschema.orgを作った人だ。Googleに20年近くいてGoogle Fellowまで行って、2024年8月に出て、いまはMicrosoftにいる。ウェブに構造化データという概念を持ち込んだ本人が、今度はエージェント向けの名簿の書式を書いている。そういう座組みだ。

ここまでは、きれいな話。

引っ越したのは、仕様書だけだった

その仕様が、8月26日に v0.91 になった。変更点のひとつが、名簿の置き場所だ。

/.well-known/ai-catalog.json から /.well-known/ard.json へ。リンクの目印も ai-catalog から ard に変わった。仕様書は言い方も強い。読みに行く側は ard.json を取りに行かなければならない、古いほうは見に行ってもいいが義務ではない、ard.json だけを見る実装で完全に適合している、と。出す側については、新旧を両方置く必要はない、旧パスにしか置いていないものは「見つからないかもしれない」とまで書いてある。

で、9月18日に出たGoogleの点検ツールが、どこを見に行くか。

Lighthouse 13.5のソースを開くと、探しているのは4か所だ。robots.txt の Agentmap 行、HTMLの rel="ai-catalog" のリンクタグ、HTTPのLinkヘッダの同じ目印、そして /.well-known/ai-catalog.json。ard.json も、rel="ard" も、出てこない。監査の表示名そのものが「ai-catalog.json のスキーマは妥当です」だ。この件を取り上げたSearch Engine JournalのMatt G. Southernも、9月21日時点で ard.json への言及をコードの中に見つけられなかったと書いている。

つまり、こうなる。仕様書に言われたとおり ard.json を置いて rel="ard" を出しただけのサイトは、Googleの点検で不合格にはならない。「該当なし」になる。名簿が無い扱いだ。正しくやったほうが、存在しないことになる。

念のため自分でも叩いてみた。9月22日時点で、Hugging Faceの /.well-known/ai-catalog.json は今も中身を返す。同じドメインの ard.json は返ってこない。仕様の共著者がいる会社が、まだ旧住所にいる。Googleの6月の発表文にある「最初のカタログを公開しよう」のリンクも、ai-catalogjson という見出しを指したままで、リンク先のページはもう「Step 1: Create the manifest (ard.json)」に書き換わっている。飛んでも、そこにはもうその見出しが無い。

引っ越し通知を出したのは仕様書だけで、住人も郵便屋もまだ前の住所にいる。

面白いのはここからで、Googleはこの状況を分かっていないわけじゃない。Agentic Browsingという新しい枠は、ほかの項目と違って0〜100の点数を出さない。Chromeのドキュメントが理由をはっきり書いている。エージェント向けウェブの標準はまだ固まりきっていないから、順位を確定させるより先に、データを集めて手がかりを出すことに寄せている、と。

分かったうえで測り始めている。そして同じリリースには、上流の仕様のスキーマや適合テストが変わったら知らせる週次の自動チェックまで追加されている。ただ、その見張りが見ているのは中身の書式のほうで、「どこを探しに行くか」は別のコードに直書きされている。だから今まさに起きているこのズレは、その見張りの網には掛からない。よくできた皮肉だな。

これ、実務として急ぐ話ではない。ARDは提案中の仕様だし、Agentic BrowsingはSEOの項目とは別枠で、検索順位とは結び付けられていない。今日やることはない。

ただ、構図としては覚えておいていい。標準が固まる前に計測が始まると、たいてい計測のほうが事実上の標準になる。llms.txtのときも、書式を決めたのは仕様の合意じゃなくて「ツールが見に行く場所」だった。今回もう一度それが起きている。仕様書が指定した住所と、採点表が見に行く住所が違うとき、サイトの運営者はどっちに合わせるか。答えは見えている。点数が出るほうだ。

古いほうの窓口は、返事すら来ない

同じ日にもうひとつ、Googleの入口の話が出ていた。

求人サイトの運営者たちが、GoogleのIndexing APIの利用承認を何か月も待たされている、という報告だ。SEOコンサルタントのNick LeRoyが9月19日にXで書いて、話が広がった。彼が運営するSEOJobs.comもPPCJobs.comも、承認も枠の増加ももらえていない。求人ボード専門のコンサルタントであるAlexander Chukovskiと合わせて「100以上の求人ボードのデータ点がある」と言い、2人とも2026年に承認が出た例を見ていない、と推測を述べている。ただしLeRoyは「ゼロだと断言できるか。できない」と自分で限界も書いている。

厄介なのは、Googleの求人向けの案内が今もIndexing APIを勧めていることだ。サイトマップより速く巡回されるから、と。一方でAPIの説明には、初期設定とテスト用の枠を超えて使うには追加の承認が要る、と書いてある。で、その承認に、標準的な審査期間は書かれていない。申請が保留なのか、承認されたのか、断られたのかを確かめる方法も、どのページにも載っていない。Googleのジョン・ミューラーが5月に答えているのは「特に問題は把握していないが、正規のサイトのふりをするブロガーに押し寄せられているのは知っているので、最近は慎重になっているんだと思う」という趣旨のもので、審査の手順そのものは説明していない。Search Engine Journalの問い合わせにも、記事公開の時点でGoogleは答えていない。

新しい入口には、標準が固まる前から採点表ができる。古い入口は、叩いても返事が来ない。どちらも同じことを言っている。Googleが何を見て何を通しているのかは、外からは分からない。分からないまま、こちらが合わせにいく。

今日の本音

llms.txt を置いたとき、みんな「これ意味あるのかな」と言いながら置いた。ard.json も同じ道を通ると思う。意味があるかどうかは後で決まる。先に決まるのは、どこに置くか、だ。

そしてその置き場所を決めているのは、いま仕様書じゃない。点検ツールのほうだ。ここだけは、覚えておいて損はない。

「うちはこれが呼べます」を1枚のファイルで名乗る

引っ越したのは、仕様書だけだった

古いほうの窓口は、返事すら来ない

今日の本音

参考・引用記事