AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける（2026年9月時点）

01 何が起きたか — 「AIクローラー」は、もう一つの塊ではない

2026年に入って、名前を持つクローラーが増えた

「AIクローラーを止めたい」という相談を受けたとき、まず確認すべきことがあります。それは、止めたい対象が本当に1種類なのか、という点です。2026年2月、Anthropicは自社のクローラーに関する公式ドキュメントを更新し、それまで「ClaudeBot」としてひとまとめに説明されていた挙動を、学習用の収集を行うClaudeBot、ユーザーがClaudeに質問したときに実際のページを取得するClaude-User、検索結果の品質向上のためにコンテンツを確認するClaude-SearchBotという3つの役割に分けて説明し直しました。このページは2026年4月7日付けで更新されており、それぞれ個別のrobots.txtトークンを持ち、ブロックしたときに起きることも別々に案内されています。

同じことは、事業者を変えても起きています。OpenAIも学習用のGPTBot、ChatGPTでの検索表示用のOAI-SearchBot、ユーザーの質問に応じてその場でページを取得するChatGPT-Userを、それぞれ別のUser-Agentとして公開しています。「AIクローラーをまとめてブロックする」という発想は、もはや実態に合いません。どの用途のクローラーを、どのトークンで制御するかを、事業者ごと・用途ごとに切り分けて考える必要があります。

Googleは、クローラーのIPレンジを確認する場所を変えた

2026年3月、Googleはクローラー・フェッチャーのIPレンジを示すJSONファイルの置き場所を変更しました。従来のgooglebot.jsonはcommon-crawlers.jsonという名前になり、置き場所そのものも別のパスへ移動しています。ファイアウォールやWAFの許可リストに旧いパスのURLを直書きしている場合、更新が必要になります。このIPレンジの移行そのものを自社の設定でどう確認するかはファイアウォールやWAFの個別設定の話になるため、本記事では「何を止め、何を通すか」という判断の側に絞ります。

「llms.txtを作れば効く」に、Google公式が答えを出した

もう一つ、2026年7月10日に更新されたGoogleの公式ガイド「Optimizing your website for Generative AI features on Google Search」（訳: Google検索の生成AI機能に向けてサイトを最適化する）が、長く曖昧だった論点に決着をつけました。llms.txtというファイルについて、公式ガイドはこう述べています。

"It's completely fine if you decide to create and maintain llms.txt files (or other similar files) for other services or systems that use these files. Doing so will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them."

（訳: llms.txtファイル（または類似のファイル）を、これらのファイルを利用する他のサービスやシステムのために作成・維持することは、まったく問題ありません。ただし、Google検索はこれらのファイルを無視するため、そうしても自社サイトのGoogle検索での見え方や順位には、良い影響も悪い影響も与えません。）

llms.txtに関する記録は、AI Ronブログのarchives/127やarchives/126でも継続的に扱われています。本記事では、この「効かないが害もない」という位置づけを踏まえたうえで、robots.txtとUser-Agentで実際に制御できることに焦点を当てます。

02 なぜ・背景 — robots.txtは「アクセス制御」ではない

robots.txtは、鍵ではなく「お願い」の文書。「止める」の意味も一つではない

robots.txtの仕様は、2022年9月にIETFの標準文書RFC 9309として正式に定められました。著者にはGoogleの担当者も名を連ねています。この文書は、robots.txtが何であるかを次のように定義しています。

"These rules are not a form of access authorization."

（訳: これらのルールは、アクセス認可の一形態ではありません。）

つまりrobots.txtは、クローラーに「ここは読まないでください」とお願いする文書であって、実際に読めないようにする鍵ではありません。Google自身も、robots.txtの入門ページで「ページをGoogle検索から除外する仕組みではない」と明記しており、検索結果から隠したいページにはnoindexメタタグやパスワード保護を使うよう案内しています。会員専用ページや管理画面をrobots.txtのDisallowだけで守っている場合、それは守られていません。他のサイトからリンクされていれば、Disallowされたページでもインデックスされることがある、と公式ドキュメントは明記しています。

WEBディレクターがAIクローラーを制御しようとするとき、目的は一つではありません。サーバー負荷を抑えたいのか、コンテンツが将来のモデル学習に使われることに同意しないという意思表示をしたいのか、検索やAIの回答からの露出そのものを止めたいのか。この3つは、使うべきトークンも、効果の範囲も違います。archives/111で扱われている「守る」から「見分ける」への視点の転換のとおり、まず何を守りたいのかを決めないと、正しいトークンを選べません。

03 用語 — クローラーとフェッチャーは別のもの

「クローラー」と「フェッチャー」の違い

robots.txtの基本的な書き方

robots.txtは、サイトのルート直下にrobots.txtという名前で、UTF-8のテキストファイルとして置く必要があります。User-agent:で対象のクローラーを指定し、続けてDisallow:（拒否するパス）やAllow:（許可するパス）を書きます。ワイルドカードの*は「任意の文字列」を、$は「URLの末尾」を表し、Sitemap以外のすべてのルールで使えます。#で始めた行はコメントとして無視されます。同じUser-Agentに一致するグループが複数ある場合、Googleは最も詳細に一致するグループを優先して適用します。

robots.txtを新規に作る、あるいは仕様を確認する際は、当サイトの🔧 XMLサイトマップ作成ツールで作ったsitemap.xmlのURLを、robots.txtのSitemap:ディレクティブに絶対URLで記載しておくと、クローラーがサイト構造を把握しやすくなります。sitemap.xmlの仕様そのものはXMLサイトマップの作り方と運用で扱っています。

04 型別 — 何を、どう止めるか

🅰 適用範囲 — 目的別に使うトークンが違う

検索エンジンからの露出そのものを止めたいなら、robots.txtではなくnoindexメタタグを使います。robots.txtはあくまで「クロールするかどうか」の制御であり、クロールを止めても外部リンク経由でインデックスされる可能性が残るためです。

AIモデルの学習データとして使われることに同意しないという意思表示をしたいなら、GPTBot・ClaudeBot・CCBot・Google-Extendedのような学習用のトークンを個別にDisallowします。一方、ChatGPTやClaudeの回答にページ内容が引用されること自体を止めたいなら、ChatGPT-UserやClaude-Userのような回答時フェッチャー用のトークンを別途Disallowする必要があります。学習用だけを止めて回答用は通す、あるいはその逆、という組み合わせも可能です。

🅱 その確認方法が測っていないこと — 「尊重する」は自己申告

各社の公式ドキュメントは、いずれも「robots.txtを尊重する」と説明しています。しかし、それが実際のアクセスにおいて常に守られているかどうかは、公式ドキュメントを読むだけでは分かりません。Cloudflareは2025年8月4日付けの報告で、あるAI検索サービスが、公式に宣言していないクローラーを使い、robots.txtの制限があるサイトに対しても一般的なブラウザを装ったUser-Agentでアクセスを続けていたと公表しました。この報告の対象となったサービス側は、集計方法について異議を唱えています。どちらが正しいかをこの記事だけで判定することはできませんが、「公式に遵守すると書いてある」ことと「実際のログで遵守が確認できる」ことは、別の事実だという点は押さえておく必要があります。

🅲 手順 — 本物のクローラーかどうかを確かめる

User-Agentの文字列は誰でも自由に名乗れるため、「Googlebot」を名乗る不正なアクセスも存在します。Googleは、本物のGooglebotかどうかを見分ける手順を公式に案内しています。まずアクセス元のIPアドレスに対して逆引きDNSを行い、得られたドメイン名がgooglebot.com・google.com・googleusercontent.comのいずれかであることを確認します。次に、そのドメイン名に対して正引きDNSを行い、最初のIPアドレスと一致することを確認します。この2段階を踏まずにIPアドレスだけで判定すると、なりすましを本物と誤認する可能性があります。手動で確認する以外に、Googleが公開しているJSON形式のIPレンジ一覧（CIDR表記）と機械的に突き合わせる方法もあります。

サイト全体で外部からどこまでアクセスできる状態になっているかをまとめて洗い出したい場合は、当サイトの🔧 外からできるセキュリティ対策監査ツール（利用には無料の会員登録が必要です）で、robots.txtとは別の角度から確認できます。

05 自分のサイトで確認するチェックリスト

チェックリストの4つの観点

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、robots.txtの現状確認、アクセスログでの実態確認、方針の決定、なりすましの検証の4つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• robots.txtを開き、User-agent: *の直後にDisallow: /が書かれていないか確認する（書かれていると全クローラーを拒否している）
• robots.txtのファイルサイズを確認する（500 KiBを超えた部分はGoogleに無視される）
• robots.txtにcrawl-delay・nofollow・noindexを書いていないか確認する（Googleは2019年9月からこれらのルールを無視している）
• robots.txtにSitemap:ディレクティブでsitemap.xmlの絶対URLを記載しているか確認する
• 直近7日分のアクセスログから、User-Agentに「GPTBot」「ClaudeBot」「CCBot」「Google-Extended」の文字列を含む行をそれぞれ数え、件数を書き出す
• 「学習データとして使われることに同意するか」を社内で決め、同意しない場合は該当トークンをrobots.txtに追加する
• 「ChatGPTやClaudeの回答に引用されることを許すか」を、学習用の判断とは別に決める
• 会員専用ページや管理画面が、robots.txtのDisallowだけで守られていないか確認し、守られていなければnoindexメタタグかパスワード保護を追加する
• Googlebotを名乗るアクセスを1件選び、逆引きDNS→正引きDNSの手順で本物のGooglebotか確認する
• llms.txtを設置している場合、Google検索の順位には影響しないことを社内の関係者と共有しておく
• robots.txtの更新履歴を残す仕組み（バージョン管理やコメント）があるか確認し、無ければ最終更新日をファイル内にコメントで残す
• robots.txtで拒否した主要なパスを3つ選び、直近30日のアクセスログにそのパスへの該当クローラーからのアクセスが無いか確認する
• 「robots.txtを尊重する」と公式に明記しているクローラーでも、上記の確認を四半期に1回は繰り返す予定を立てる

13項目の内訳と、かかる時間の目安

最初の4項目はrobots.txtの現状確認、5番目から8番目は方針の決定、9番目と10番目は個別の確認、11番目から13番目は継続的な検証に対応しています。すべてに目を通す時間の目安は1サイトあたり20分程度です。特に13番目の「繰り返す予定を立てる」は見落としがちですが、公式ドキュメントの「尊重する」という文言は、その時点の方針を示しているにすぎず、継続的な検証に代わるものではありません。

06 止める手段を比較する

4つの手段、それぞれの向き不向き

AIクローラーやWebクローラーを制御する手段は、robots.txtだけではありません。以下は、目的別に使い分ける4つの手段を、防げることと防げないことで整理した表です。

組み合わせて使う場合の優先順位

実際には、これらの手段は排他的ではなく、組み合わせて使います。目的ごとに手段を割り当てるのが基本の考え方です。検索結果からもAIの回答からも除外したいページにはnoindexメタタグを使います。クロールの負荷だけを抑えたいが検索には出したいページには、robots.txtのDisallowを個別に使います。学習利用への同意・不同意を示したいだけなら、robots.txtに学習用トークンだけを追加します。

llms.txtは、現時点では検索順位にもAI Overviewsにも影響しないと公式に説明されているため、設置するかどうかは他の3つの判断が終わったあとに検討しても遅くありません。

07 このサイトでの記録

AI Ronブログでの継続的な記録

このサイトが運営するAI Ronブログでは、AIクローラーの訪問状況を継続的に記録しています。archives/137では、52日分のアクセスログを対象に、AIクローラーの訪問回数とAI経由の流入件数を分けて数えた結果が示され、訪問はあっても流入には直結していなかったことが記録されています。またarchives/136では、ログを行全体で検索すると、AI自身が名乗った文字列とAI経由の流入が混ざって数えられてしまう、という記録の取り方そのものの注意点も扱われています。robots.txtでの制御を検討する前提として、まず自社のログでどのクローラーが実際に来ているかを把握しておくと、どのトークンを優先すべきかの判断材料になります。

08 このテーマの、これまで

1994年〜2024年: 1つの仕組みから、事業者ごとの仕組みへ

robots.txtの原型は、1994年にMartijn Koster氏が提案した「Robots Exclusion Protocol」に遡ります。長らく検索エンジンのクローラーを制御するための仕組みとして使われてきましたが、2019年7月、Googleは公式ブログでcrawl-delay・nofollow・noindexのサポート終了を告知し、同年9月1日付けで実施しました。2022年9月には、robots.txtの仕様がIETFの標準文書RFC 9309として正式に定められています。生成AIの学習を目的とするクローラーが登場したのは、この標準化のすぐあとです。2023年8月にOpenAIがGPTBotを公開し、robots.txtでの制御方法をあわせて案内しました。Common Crawlが運用するCCBotは、それより古く2008年から公開データの収集を続けてきた仕組みですが、2023年以降、複数のAI企業が学習データの一部として利用してきたことが広く知られるようになりました。

2025年〜2026年: 役割ごとに分かれ、公式見解も更新された

2024年9月には、Jeremy Howard氏がllms.txtという新しい提案を発表しました。2025年8月には、AI検索サービスのクロール実態を巡ってCloudflareが報告を公表し、公式の説明と実際のアクセスの間にずれがあり得ることが表面化しました。2026年2月にはAnthropicがクローラードキュメントを更新して3つの役割に分割し、2026年3月にはGoogleがクローラーIPレンジのファイルの置き場所を変更しました。そして2026年7月、Googleは公式ガイドで「llms.txtはGoogle検索に一切影響しない」と明記しています。llms.txt自体も2026年8月10日にバージョン2へ更新されました。