Agents.txtはアクセス制御ではありません

DreamHostは現在、Web Hostingプランで、サイト側が独自のファイルを用意していない場合に、標準のrobots.txtとagents.txtが自動的に含まれると説明しています。¹

この小さなホスティング上の変更は、より大きな変化を示しています。いまのWebサイトは、少なくとも3つの相手に同時に語りかけています。検索クローラー、AIクローラー、そして推論時に整理された文脈を探すアシスタントです。ファイル名だけを見ると、この変化は整然として見えます。robots.txtは自動クライアントが何をクロールしてよいかを示します。llms.txtはLLMに厳選された地図を渡します。agents.txtはエージェント向けの方針を示そうとします。しかし、これらのファイルのどれも、運用者に「守られている」と感じさせるべきものではありません。

Agents.txtはアクセス制御ではありません。クローラー向けファイルは、公開された方針のヒントと発見の補助として扱ってください。本当の制御は、サーバー側の認可、ボットの身元確認、レート制限、ログ、キャッシュの挙動、そして重要なクローラーが現在のファイルを実際に見たという証拠から生まれます。

要約

Robots Exclusion Protocolの標準では、クローラー向けルールは「アクセス認可の形式ではない」とされています。² Googleも、robots.txtで許可しないURLであっても、他のページからリンクされていれば検索結果に表示される可能性があると警告しています。³ DreamHost自身のボット制御記事でも、robotsファイルは従順な検索エンジンへの提案として機能するものであり、悪質なボットはファイルを無視したり、誤解を招くユーザーエージェントを使ったりする可能性があると説明しています。¹

AIクローラーでは、方針の軸がさらに増えます。OpenAIは、ChatGPT検索向けのOAI-SearchBotと、学習関連のクロールを行うGPTBotを分けており、ChatGPT-Userはユーザーが起点となる操作を表すため、robots.txtが適用されない場合があると説明しています。⁴ Googleは、Google-Extendedには独立したHTTPユーザーエージェント文字列がなく、学習やグラウンディングに関する設定のためのrobots.txtプロダクトトークンとして機能し、Google検索への掲載には影響しないと説明しています。⁵ いまのクローラー制御ファイルに必要なのは、単純な許可・拒否のスイッチではなく、目的ごとの方針です。

ホスト、プラットフォーム、またはエージェントのエコシステムが期待しているなら、agents.txtを使ってください。推論時のツールに最良のページを理解してほしいなら、llms.txtを使ってください。主要なクローラーはいまも参照するため、robots.txtは正確に保つべきです。そのうえで、サーバーの境界でリクエストを検証し、ログを読みます。テキストファイルは意図を表現できます。しかし、信頼できないクライアントを止めることはできません。

重要なポイント

サイト所有者向け: - クロール方針にはrobots.txt、AIが読める文脈にはllms.txt、エージェント向けのヒントとしてのみagents.txtを公開します。 - 非公開ルート、秘密のファイル名、内部プロンプト、機密パスを、公開クローラー向けファイルに書いてはいけません。 - 変更後はログを確認します。方針ファイルに意味があるのは、適切なクローラーがそれを取得し、挙動を変えた場合だけです。

SEOおよびAIOチーム向け: - 検索での可視性、学習許可、ユーザー起点の取得を分けて考えます。 - 検索クローラーやAI回答面など、歓迎したいボットの許可リストを明示します。 - クローラー向けファイルは、サイトマップ、canonical、schema、llms.txtの検証と組み合わせます。

セキュリティチーム向け: - ユーザーエージェント文字列は身元ではなく、主張として扱います。 - 運用者が対応している場合は、逆引きDNSや公開IP範囲でクローラーを検証します。 - 機密リソースへのアクセスは、クローラーの礼儀に頼らず、認証、WAFルール、アプリケーション側の方針、レート制限で制御します。

Agents.txtで何が変わったのか

robots.txtは数十年前から存在します。RFCでは、サービス所有者がrobots.txtファイルを提供し、クローラーがどのURIにアクセスしてよいか判断できるようにすると定義されています。² 基本的な形は見慣れたものです。

User-agent: *
Disallow: /private-draft/
Sitemap: https://example.com/sitemap.xml

agents.txtが登場したのは、まったく別の時代です。Webが受け取るのは、もはや検索エンジンのクローラーだけではありません。学習用クローラー、回答エンジンのクローラー、広告安全性のクローラー、ブラウザーアシスタントの取得、ユーザー起点のLLM取得、アーカイブクローラー、SEOツール、そして正規クローラーの名前を借りるスパムボットまでやって来ます。

DreamHostのドキュメントが重要なのは、agents.txtを少なくとも1つの主要ホストで、ニッチな発想から標準のホスティング挙動へ押し出しているからです。その記事では、DreamHostがWeb Hostingプラン向けに標準のrobots.txtとagents.txtを自動で含め、サイト所有者はサイトルートに独自ファイルを置くことでどちらのファイルも上書きできると説明しています。¹ だからといって、agents.txtが強制力を持つ標準になるわけではありません。ただし、このファイル名を実際のWeb上で見かける可能性は高くなります。

安全な読み方は限定的です。

ファイル名同士を競わせる必要はありません。これらは方針パケットとして組み合わせるべきです。クローラーが何をリクエストしてよいか、AIシステムが何を読むべきか、エージェントが何を知るべきか、そしてサーバーが実際に何を観測したかをまとめるのです。

Robots.txtはいまも重要ですが、保護にはなりません

クローラー向けファイルは、チームがそれをセキュリティ境界として使ったときに破綻します。

RFCはその境界を明確にしています。このプロトコルは、自動クライアントがURIへアクセスする際にルールを尊重することを求めるものであり、アクセスを認可するものではありません。² Googleも運用上、同じことを述べています。他のページが許可されていないURLにリンクしている場合、Googleはブロックされたページ本文をクロールしなくても、そのURLアドレスや公開リンク情報を見つけてインデックスする可能性があります。³ DreamHostも、robotsルールは従順な検索エンジンへの提案として機能し、悪質なボットはファイルを無視したり、偽のユーザーエージェントを使ったりする可能性があると警告しています。¹

ここから導けるルールは単純です。検索結果にコピーされたり、データセットにスクレイピングされたり、LLMによって表示されたりしたら困るものを、robots.txt、agents.txt、llms.txtのどれにも書いてはいけません。

悪いクローラー向けファイルは、守るよりも多くをさらします。

User-agent: *
Disallow: /internal-product-roadmap/
Disallow: /legal-private/
Disallow: /prompt-drafts/
Disallow: /customers/acme-renewal-risk/

上のファイルは、機密情報がありそうな場所をすべての訪問者に教えています。従順なクローラーは、そのパスを避けるかもしれません。しかし攻撃者には、ディレクトリの地図を渡していることになります。

より安全なファイルは、機密の棚卸しを示さずに、公開クロール方針だけを伝えます。

User-agent: *
Allow: /
Disallow: /*.md$
Sitemap: https://example.com/sitemap.xml

この版なら、非公開構造を明かさずに実際の希望を表現できます。もし/prompt-drafts/が存在するなら、サーバー側で認証をかけ、必要に応じてnoindexヘッダーを使うべきです。クローラー向けファイルにその負担を背負わせてはいけません。

AIクローラーには目的ごとの方針が必要です

検索クローラーの方針は、以前は二択に見えました。Googlebotを許可し、うるさいSEOツールをブロックし、非公開ページはサーバー側の制御で守る、という形です。

AIクローラーの方針には目的が加わります。サイト所有者は、あるページをChatGPT検索結果には表示したい一方で、同じページをモデル学習には使わせたくないかもしれません。OpenAIのクローラードキュメントは、この分岐を明確にしています。OAI-SearchBotはChatGPT検索機能を支え、GPTBotはOpenAIの生成AI基盤モデルの学習に使われる可能性があるコンテンツをクロールすると説明されています。⁴ OpenAIはさらに、これらの設定は独立しており、Web管理者はOAI-SearchBotを許可しながらGPTBotを許可しない設定にできると述べています。⁴

Googleも別の形で似た境界を示しています。Googleのクローラードキュメントでは、Google-Extendedには独立したHTTPリクエストのユーザーエージェント文字列がなく、既存のGoogleユーザーエージェントがクロールを行い、Google-Extendedはrobots.txtのプロダクトトークンとして機能すると説明されています。⁵ Googleによれば、このトークンはクロールされたサイトコンテンツを将来のGeminiモデル学習やグラウンディングに使えるかどうかを制御するもので、Google検索への掲載やランキングには影響しません。⁵

この2つの例だけでも、平面的なブロックリストでは要点を外すことが分かります。本当に必要な方針マトリクスは、次の問いを扱います。

方針ファイルは目的に合わせるべきです。すべてのAIユーザーエージェントを拒否しておきながら、AI検索面がサイトを無視すると不思議がってはいけません。すべてのAIクローラーを許可しておきながら、ユーザー向け検索のためだけに意図したページを学習クローラーが消費したと不満を言うのも筋が通りません。目的を分け、希望を明示し、挙動を検証してください。

Llms.txtが解く問題は別です

llms.txtはrobots.txtの代替ではありません。Jeremy Howardの提案では、/llms.txtはLLMが推論時にWebサイトを利用しやすくする情報を提供する方法として説明されています。⁶ 同じ提案では、llms.txtは既存のWeb標準と共存できるとも述べられています。サイトマップは検索エンジン向けにページを列挙し、llms.txtはLLM向けに厳選された概要を提供し、許可されたコンテンツについて文脈を添えることでrobots.txtを補完できます。⁶

この違いはAIOでは重要です。

robots.txtが答える問いは、「このクローラーはこのパスをリクエストしてよいか」です。

llms.txtが答える問いは、「アシスタントが自分のサイトを読むなら、まず何を理解すべきか」です。

agents.txtが答えるかもしれない問いは、「エージェント型クライアントは、望ましい振る舞いについて何を知るべきか」です。

これらの問いは近くにあります。しかし1つのファイルに潰してよいものではありません。本気で運用するサイトなら、AIによる発見をリリース面として扱うべきです。

1. 明確なタイトルと説明を持つcanonicalページを公開します。
2. 表示ページと一致する構造化データを追加します。
3. サイトマップとRSSの出力を最新に保ちます。
4. 厳選したAI向け文脈としてllms.txtとllms-full.txtを公開します。
5. 明示的なクローラー方針を持つrobots.txtを公開します。
6. プラットフォームまたはエージェントのエコシステムに具体的な読み手がいる場合だけ、agents.txtを追加します。
7. ログを確認し、クローラーが変更後のファイルをリクエストしたことを確かめます。

最後の手順を省くと、AIOは願掛けになります。クローラー向けファイルは存在する。ルートは200を返す。それでも、意図したクライアントが見たことを証明する証拠はありません。

検証はエッジで行うものです

ユーザーエージェント文字列は身元を証明しません。任意のスクリプトがUser-Agent: Googlebotを送れます。スクレイパーはUser-Agent: GPTBotを送れます。ヘッダーだけを信じる方針は、最も偽装しやすい相手に最も寛大な扱いを与えます。

Googleは、Googleから来たと主張するリクエストについて2つの検証方法を文書化しています。単発確認向けの逆引きDNSと正引きDNS、そして大規模システム向けの公開IP範囲照合です。⁷ OpenAIは、クローラードキュメント内でOAI-SearchBot、GPTBot、ChatGPT-User向けのIPアドレスJSONファイルを公開しています。⁴ これらの仕組みですべてのクローラーを網羅できるわけではありません。それでも、正しい形は示されています。身元には、文字列を超える証拠が必要です。

最低限、エッジ側の方針では次を記録すべきです。

このログのまとまりが、クローラー方針を意見から証拠へ変えます。GPTBotが許可していないパスをリクエストし続けるなら、それを証明できます。偽のGooglebotが住宅用プロキシから非公開らしいURLを叩いているなら、本物のGooglebotを罰せずにブロックできます。OAI-SearchBotが変更後の記事を一度もリクエストしていないなら、そのページがChatGPT検索に出てこない理由が分かります。

実用的なAIクローラー方針パケット

ファイルから始めてはいけません。まず成果から始めます。

このパケットでは、各層に適切な役割を与えます。robots.txtは希望を伝えます。llms.txtは文脈を伝えます。agents.txtは読み手が存在する場合に、エージェント向けの意図を伝えます。サーバーが強制します。ログが証明します。

私自身のサイトでも、クローラー対応はこの分担に沿っています。公開方針ファイルでは正当なクローラーを歓迎し、クローラーがコードブロックの例から推測した生のMarkdownパスをブロックしています。AI文脈ファイルは、公開記事への厳選された入り口をアシスタントに渡します。夜間のクロール調査では、クローラーがエラー、古いキャッシュ、欠落ルート、いまは410を返すべき古いURLを見たかどうかを確認します。方針ファイルは意図を示します。その意図が機能したかどうかを決めるのはログです。

Agents.txtに何を書くべきか

エコシステムが定まるまでは、agents.txtは退屈で公開向けの内容にとどめてください。

良い候補:

• サイト連絡先と方針URL。
• robots.txt、サイトマップ、llms.txt、RSSへの案内。
• 公開コンテンツの望ましい利用に関する記述。
• 非公開または認証付きルートには認可が必要であるという注意。
• クロール問題のサポート窓口。

悪い候補:

• 秘密のパス。
• 内部プロンプトのルール。
• 非公開のAPIルート。
• 顧客名。
• セキュリティ例外。
• 敵対的なクライアントにコピーされたらサイトに損害を与える指示。

agents.txtの正しい基準は、「良いエージェントが喜ぶか」ではありません。正しい基準は、「悪いエージェント、検索結果、見知らぬユーザーの全員がこのファイルを読んでも平気か」です。

よりよい考え方

クローラー向けファイルは、公道に立てる標識です。

標識には「搬入口」「進入禁止」「ここから始めてください」と書けます。礼儀正しい運転者は標識に従います。無謀な運転者は無視します。それでも標識には価値があります。正当なトラフィックの多くは、明確な指示を求めているからです。標識を鍵のかかった扉のように扱った瞬間に、標識は失敗します。

AIクローラーによって、標識はより重要になり、同時により不十分にもなりました。重要になったのは、AIシステムに明確な公開文脈、目的別の方針、ルート地図が必要だからです。不十分になったのは、ユーザーエージェントが増え、学習と検索が分かれ、悪いクライアントが良いクライアントになりすませるからです。

答えは、クローラー向けファイルを諦めることではありません。答えは、その権威を適切な水準まで下げることです。明確な公開方針を公開する。誰がそのファイルをリクエストしたかを検証する。何を取得したかを見る。非公開の境界はサーバーで強制する。「AIで見える」という主張は、ログとライブのルートが支えるまで未証明として扱う。

これが、AIOの見せかけと本物のクローラー運用の違いです。

FAQ

agents.txtとは何ですか？

agents.txtは、サイトルートで提供されることがある、登場しつつあるエージェント向けのテキストファイルです。DreamHostはWeb Hostingプラン向けの標準agents.txtファイルを文書化していますが、その文書によってこのファイルがアクセス制御の標準になるわけではありません。特定のエージェントプラットフォームが、このファイルをどのように読み、どのように適用するかを明確に文書化するまでは、公開されたヒントとして扱ってください。¹

robots.txtはAIクローラーをブロックできますか？

従順なクローラーはrobots.txtを尊重する場合があり、主要な運用者は自社クローラー向けの具体的なトークンを文書化しています。OpenAIはOAI-SearchBotとGPTBotの制御を文書化し、Googleは学習とグラウンディング設定向けのプロダクトトークンとしてGoogle-Extendedを文書化しています。⁴⁵ それでもrobots.txtは、クライアントを認証したり、コンテンツを隠したり、ファイルを無視することを選んだボットを止めたりするものではありません。²³

llms.txtを公開すべきですか？

AIアシスタントに公開コンテンツの厳選された地図を見つけてほしいなら、llms.txtを公開してください。この提案では、llms.txtは推論時の文脈として位置づけられており、サイトマップやrobots.txtの代替ではありません。⁶ 役に立つファイルは、エージェントに実際に理解してほしいページを指し示します。

許可していないURLが検索に出ることはありますか？

あります。Googleは、robots.txtでブロックされたURLでも、他のページからリンクされていれば表示される可能性があると説明しています。ただし、Googleはブロックされたページ本文をクロールまたはインデックスしません。³ 公開結果から除外すべきページには、認証、クロールアクセスを許す場合のnoindex、サーバー側方針を使ってください。

本物のクローラーと偽物をどう見分ければよいですか？

ユーザーエージェント文字列だけに頼らないでください。Googleは、逆引きDNSと正引きDNSの確認、および公開IP範囲の照合を文書化しています。⁷ OpenAIは、文書化されたボット向けのIPアドレスJSONファイルを公開しています。⁴ クローラー運用者が検証データを公開していない場合、そのリクエストは主張として分類し、挙動に応じてレート制限やチャレンジを適用します。

公開サイトにとって最も安全なクローラー向けファイル構成は何ですか？

クローラー方針にはrobots.txt、URL発見にはサイトマップ、厳選されたAI向け文脈にはllms.txt、公開されたエージェント向け案内に限ってagents.txtを使います。機密パスはすべての公開ファイルから除外してください。そのうえで、ライブのルート、キャッシュ状態、クローラー取得、サーバーログを検証してから、構成が機能していると言うべきです。

参考文献