AIクローラーは拒否すべきか？｜llms.txtの現在地

サイトのアクセスログを開くと、GooglebotやBingbotに混じって見慣れない名前が並ぶようになりました。GPTBot、ClaudeBot、PerplexityBot——ChatGPTをはじめとする生成AIサービスのクローラーです。AI検索の利用者が増えるにつれて、企業サイトを巡回するボットの顔ぶれはこの2年で大きく変わりました。ここで担当者が迫られるのが「ブロックすべきか、受け入れるべきか」という判断です。拒否すればコンテンツがAIの学習に使われることは避けやすくなりますが、同時にAI検索の回答で自社が引用される機会を失うかもしれない。守りたいものと得たいものが正面からぶつかる、新しいタイプの意思決定です。本記事では、主要AIクローラーの種類と用途の違い、robots.txtでの制御方法とその限界、話題のllms.txtの提案内容と2026年時点の現在地、そしてBtoBサイトとしての現実的な判断軸を、許可・拒否・選別という3つの選択肢の比較で整理します。

AIクローラーとは：検索エンジンのクローラーと何が違うか

AIクローラーとは、生成AIサービスを運営する企業がウェブ上のコンテンツを収集するために巡回させているボットの総称です。ページを取得して回るという動きだけを見れば、Googlebotのような検索エンジンのクローラーと変わりません。決定的に違うのは収集した情報の使い道です。検索エンジンのクローラーは、ページをインデックスに登録し、検索結果に「リンクとして」表示するために収集します。サイト側から見れば、クロールを許すことがそのまま流入というリターンにつながる、分かりやすい取引でした。

一方のAIクローラーは、収集したコンテンツをAIモデルの学習データにしたり、AI検索の回答文を組み立てる材料にしたりします。回答の中で出典として引用されればリンク経由の流入が生まれますが、利用者が回答文だけで満足すればサイトへの訪問は発生しません。つまりクロールを許すことのリターンが、検索エンジン時代ほど自明ではなくなったのです。この構造変化こそが、AIクローラーへの対応方針という新しい論点を生んでいます。感情論や流行で決めるのではなく、ボットの種類と用途を正確に知ったうえで、自社が何を守り何を得たいのかを整理するのが本記事の目的です。

主要AIクローラーの顔ぶれ：User-agent早見表

まず、2026年時点で企業サイトのログに現れる主要なAIクローラーを押さえましょう。運営元ごとに複数のボットを使い分けている点が重要です。

User-agent	運営元	主な用途
GPTBot	OpenAI	将来のAIモデルの学習用データ収集
OAI-SearchBot	OpenAI	ChatGPT検索の引用候補のインデックス作成
ChatGPT-User	OpenAI	利用者の指示に応じたその場のページ取得
ClaudeBot	Anthropic	AIモデルの学習用データ収集
Claude-SearchBot / Claude-User	Anthropic	検索インデックス／利用者要求時の取得
PerplexityBot / Perplexity-User	Perplexity	回答エンジンのインデックス／利用者要求時の取得
Google-Extended	Google	Geminiなど生成AIへの利用可否を伝える制御用トークン
CCBot	Common Crawl	公開ウェブアーカイブの構築（多くのAI学習に利用）

注意したいのがGoogle-Extendedの性質です。これは独立したクローラーではなく、Googlebotなどが収集した内容を生成AIの学習に使ってよいかを伝えるための制御用の名前で、robots.txtに書くことで意思表示になります。拒否しても通常のGoogle検索の掲載には影響しない、と公式ドキュメントで説明されています。また、Appleにも同様の仕組みとしてApplebot-Extendedがあります。自社サイトにどのボットが来ているかは、サーバーログやCDNのボットレポートでUser-agent名を検索すれば確認できます。

用途は3種類：学習・検索インデックス・その場の取得

表で見たとおり、AIクローラーの用途は大きく3つに分かれます。第一が学習用（GPTBot・ClaudeBotなど）で、収集したテキストは将来のAIモデルの訓練データになります。一度学習に取り込まれた内容は、後からrobots.txtで拒否しても取り消せません。第二が検索インデックス用（OAI-SearchBot・Claude-SearchBot・PerplexityBotなど）で、AI検索が回答を作るときに引用する候補ページの索引を作ります。ここを拒否すると、AI検索の回答で自社が出典として引用される可能性が下がります。

第三がユーザー要求時の取得（ChatGPT-User・Claude-User・Perplexity-Userなど）です。利用者が「このURLを要約して」と指示したときなど、人の操作をきっかけにその場でページを取得するもので、動きとしては人間がブラウザで開くのに近い性質を持ちます。対応方針を考えるうえで肝心なのは、この3種類は別々のUser-agentを名乗っており、robots.txtで個別に許可・拒否を書き分けられるという事実です。「AIボットだから全部拒否」も「全部許可」も、実は選択肢の両端にすぎません。

論点の整理:何を守り、何を得たいのか

方針を決める前に、対立している利害を言葉にしておきましょう。拒否派の論拠は主に3つです。①自社が費用をかけて作ったコンテンツが、対価なしにAIモデルの学習に使われることへの抵抗。②AIが回答文の中で内容を要約してしまい、サイト訪問が発生しない「ゼロクリック」への懸念。③クローラーのアクセスが増えることによるサーバー負荷。特に①は、コンテンツを競争力の源泉とするメディア企業ほど深刻に受け止めています。

受け入れ派の論拠も明確です。AI検索を情報収集に使うビジネスパーソンは着実に増えており、回答で引用されることは新しい発見経路になります。しかも後述するとおり、AI検索経由でサイトに来た訪問者は、すでにAIとの対話で課題を整理し終えているため検討度が高い傾向が報告されています。BtoBのように1件の商談の価値が大きい事業では、流入の絶対数が少なくても無視できません。つまりこの論点は「コンテンツ資産の保護」と「新しい流入経路の確保」のトレードオフであり、どちらを重く見るかは事業の性質によって答えが変わります。

選択肢①すべて拒否する：コンテンツ保護を最優先する判断

1つめの選択肢は、主要なAIクローラーをrobots.txtでまとめて拒否する方針です。報道機関や有料コンテンツを持つメディア、写真・イラストなど作品そのものが商品であるサイトでは合理的な判断になり得ます。学習への利用を止めたいという意思表示を明確にでき、コンテンツの二次利用に関する交渉余地（ライセンス契約など）を残せるのが利点です。実際、海外の大手メディアには、AI企業と個別のライセンス契約を結ぶまでクローラーを全面拒否した例が複数あります。

ただし失うものも正確に見ておく必要があります。AI検索のインデックス用ボットまで拒否するため、ChatGPTやPerplexityの回答で自社ページが引用・リンクされる機会はほぼなくなります。買い手がAIに「この分野のおすすめの会社は」と尋ねたとき、回答の候補に自社が挙がらない世界を受け入れるということです。また、robots.txtによる拒否は過去に学習済みの内容を消す効果はなく、あくまで今後のクロールを止めるだけです。BtoBの事業会社サイトの場合、守るべき独自コンテンツの量と、AI経由の接点を失う機会損失を天秤にかけると、全面拒否が最適になるケースは限られるでしょう。

選択肢②すべて受け入れる：AI経由の流入は伸びているのか

2つめの選択肢は、何も制限せずすべてのAIクローラーを受け入れる方針です。判断材料として、AI検索経由の流入の実態を見てみましょう。Similarwebのクリックストリームデータを引いた2026年の分析では、ChatGPT経由でサイトを訪れた人のコンバージョン率は7%台と、有料検索に次ぐ水準で、自然検索やSNS経由を上回ったと報告されています。また、Adobe Analyticsは2026年3月、米国小売サイトにおいてAI経由の訪問者が他経由より4割ほど高い率で購入に至ったと公表しました。量はまだ小さいが質が高い——これが各種データに共通する傾向です。

一方で規模感には冷静な目が必要です。BtoBサイトにおけるAI経由の紹介流入は、多くの調査でサイト全体のトラフィックの1%前後にすぎません。しかもGA4の標準設定では、ChatGPTやPerplexityからの流入が「Direct」や「Other」に分類されてしまい、存在自体に気づいていない企業も多いのが実情です。全面許可のリスクは、学習利用への抵抗感を除けば、行儀の悪いボットによるサーバー負荷くらいで大きくはありません。ただ、何も考えずに全部許可するのと、比較検討したうえで許可するのとでは、社内説明の説得力がまるで違います。方針は選択の結果として持つべきです。

選択肢③選別する：学習と検索を分けて制御する現実解

3つめが、用途ごとに扱いを分ける選別型です。典型的な組み合わせは「学習用ボット（GPTBot・ClaudeBot・Google-Extended・CCBotなど）は拒否し、検索インデックス用とユーザー要求時取得用は許可する」という形で、海外のSEO関係者の間でも現実解としてよく挙げられます。学習への提供という一方的な持ち出しは断りつつ、AI検索の回答で引用され流入を得るという新しい経路は確保する。トレードオフの真ん中を取る設計です。

3つの選択肢を並べて比較すると、それぞれの得失がはっきりします。

方針	得られるもの	失うもの・リスク
全面拒否	学習利用への明確な意思表示。交渉余地の確保	AI検索での引用機会をほぼ喪失。設定・監視の手間
全面許可	AI検索経由の引用・流入の最大化。手間ゼロ	学習への無償提供。ボット負荷。方針なき状態
選別型	学習は拒否しつつAI引用の経路は維持	User-agentの追加・変更を追い続ける運用負荷

選別型の注意点は運用です。AI企業は新しいボットを次々に追加するため、robots.txtを一度書いて終わりにはできません。各社の公式ドキュメントでUser-agent一覧を確認し、四半期に一度はrobots.txtを見直す運用をセットにすることで初めて機能します。また同じ運営元でもボットごとに設定が独立しているため、たとえば学習用のClaudeBotを拒否しても、検索用のClaude-SearchBotを明示的に許可していなければ引用の恩恵は受けられません。

robots.txtでの制御方法：記述例と設定手順

実際の設定はrobots.txtで行います。robots.txtはサイトのルート直下（例：example.co.jp/robots.txt）に置くテキストファイルで、ボットの名前（User-agent）ごとにクロールの可否を伝える標準的な仕組みです。選別型の記述例を挙げます。

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

導入の手順は次のとおりです。

なお、robots.txtの編集はサイト全体のクロールに影響し得る作業です。記述を誤ってGooglebotまで拒否してしまう事故が実際に起きています。変更は必ず検証環境か有識者のレビューを通し、公開直後にSearch Consoleのエラーを確認する運用にしてください。

robots.txtの限界：従わないクローラーへの対処

押さえておくべき前提として、robots.txtは法的な強制力を持たない紳士協定です。主要AI企業の公式ボットはおおむね従うと表明していますが、世の中のすべてのボットが従うわけではありません。実際、Cloudflareは2025年8月、Perplexityが公表済みのUser-agentとは別に、名前を偽ったクローラーでrobots.txtの拒否指定を回避していたとする調査報告を公開し、大きな議論になりました（Perplexity側は反論しています）。公式に文書化されたボットへの制御と、無法なスクレイパーへの防御は、別の問題として考える必要があります。

robots.txtで足りない場合の次の手段は、CDNやWAF（ウェブアプリケーションファイアウォール）によるボット管理です。CloudflareなどのCDN事業者は、AIクローラーを検知して一括ブロックしたり、逆に条件付きで通したりする機能を提供しており、2025年以降はクロールに課金する仕組みの実験も始まっています。もっとも、ここまでの対策が必要なのは大量のコンテンツ資産を持つメディア型のサイトが中心です。一般的なBtoB事業会社のサイトなら、まずはrobots.txtでの意思表示と月次のログ確認から始めれば十分でしょう。

llms.txtとは何か:提案の中身と書式

ここからもう1つの論点、llms.txtの話に入ります。llms.txtは、fast.ai共同創業者のJeremy Howard氏が2024年9月に提案した仕組みで、サイトのルート直下に置くMarkdown形式のファイルです。robots.txtがボットに「入ってよいか」を伝えるのに対し、llms.txtはAIに「このサイトの要点はこれで、重要なページはここにある」を伝えます。サイト名と概要の説明文、そして主要ページへのリンクを整理したリストというシンプルな書式で、いわばAI向けの案内板です。

提案の背景には、AIがウェブページを読む際の技術的な事情があります。現代のウェブページはナビゲーションや広告、装飾用のコードなど本文以外の要素が大半を占め、AIが文脈を読み取るうえでノイズになります。人間向けのHTMLとは別に、機械が読みやすい整理済みの入口を用意しようという発想です。ページ全文をMarkdown化して提供するllms-full.txtという拡張版もあわせて提案されています。ここで大事なのは、llms.txtはrobots.txtの代わりでも上位版でもなく、目的がまったく別のファイルだということです。アクセス制御はrobots.txt、内容の案内はllms.txtと役割が分かれます。

llms.txtの現在地：採用状況と主要AI企業の対応

では2026年時点で、llms.txtはどれだけ使われているのでしょうか。2026年6月に公開された調査では、世界の上位1,000サイトのうちllms.txtを公開しているのは8.7%と報告されています。また、SEOツールベンダーのSE Rankingが約30万ドメインを対象にした調査でも採用率は10%程度でした。提案から1年半で1割という数字は、開発者向けドキュメントサイトやSaaS企業を中心に一定の広がりを見せつつも、まだ標準とは言えない段階であることを示しています。

AI企業側の対応は割れています。AnthropicやPerplexityは自社サイトでllms.txtを公開し、仕様への賛同を示してきました。一方Googleは、2025年7月に検索チームのGary Illyes氏がllms.txtをサポートしておらず、対応の予定もないと明言し、同社のJohn Mueller氏は「誰も見ないkeywordsメタタグのようなもの」と例えたことが広く報じられました。さらに、複数のログ分析では主要AIクローラーがllms.txtファイルをほとんど取得していないという観測が報告されています。つまり「置けばAIに読まれる」という前提自体が、現時点では成り立っていないのです。

llms.txtを置くべきか：効果の見立てと判断

効果の見立てを正直に言えば、2026年時点のllms.txtは大きな効果は期待できないが、害もほぼない施策です。引用のされやすさが目に見えて変わったという確かなデータはなく、Googleが不支持である以上、検索やAI Overviewでの扱いにも影響しません。一部では、丁寧に整備したサイトでAIからの引用がわずかに増えたとする観測もありますが、因果関係を証明できる規模ではありません。導入コストは主要ページを整理したテキストを1枚作るだけなので、リスクとリターンがどちらも小さい施策と言えます。

それでも作る価値があるとすれば、理由は2つです。第一に、llms.txtの作成作業は「自社サイトの重要ページはどれか、それぞれ何を伝えるページか」の棚卸しそのものであり、サイト構造とコンテンツの整理という本質的な改善につながります。第二に、AIエージェントがウェブサイトを直接読んで業務をこなす流れは強まっており、機械可読な案内を用意しておくことは将来への保険になります。逆に言えば、通常のSEOやコンテンツ改善を差し置いてまで優先する施策ではありません。「余力があれば置く。ただし効果は期待しすぎない」が現実的な距離感です。

BtoBサイトの判断軸：社内で決めておく3つのこと

ここまでの材料を、BtoBサイトの実務に落とし込みます。決めるべきことは3つです。1つめは学習利用への態度。自社コンテンツの独自性が競争力の核心なら学習用ボットは拒否に倒し、認知拡大が最優先なら許可に倒します。どちらでも事業への短期的な影響は小さいので、経営層の考え方も聞いたうえで「会社としての態度」を決めることが大切です。2つめはAI検索での被引用の扱い。BtoBの買い手がAIで情報収集する流れは不可逆と見るなら、検索インデックス用ボットは許可が基本になります。

3つめは観測の仕組みです。方針は一度決めて終わりではなく、AI経由流入の推移を見て見直すものです。GA4で参照元にchatgpt.comやperplexity.aiを含むセッションを抽出するセグメントを作り、月次で件数と問い合わせへの寄与を追いかけてください。数字が積み上がってきたら許可の範囲を広げ、ゼロが続くなら方針を再考する——この観測ループさえあれば、最初の方針が多少ずれていても軌道修正できます。判断に完璧を求めるより、見直せる体制を作ることが重要です。

ありがちな失敗:方針決定の落とし穴

最後に、AIクローラー対応でよく見かける失敗パターンを挙げます。いずれも「仕組みの理解が浅いまま極端に振れる」ことが原因です。

• 「AIは脅威」という空気だけで全ボットを拒否し、AI検索経由の引用と流入の芽まで摘んでしまう
• robots.txtに学習用ボットの拒否だけ書いて、検索用ボットの存在を知らずに「AI対策は完了」と思い込む
• llms.txtを置いただけで「AI検索対策済み」と報告し、コンテンツ自体の品質改善を止めてしまう
• robots.txtの編集ミスでGooglebotまで拒否し、検索流入を落とす
• 一度設定したきり見直さず、新しいUser-agentの登場に1年以上気づかない

• robots.txtの変更は反映確認までがセット。公開後にSearch Consoleでクロールエラーが出ていないか必ず確認する
• 過去にAIが学習済みの内容は、robots.txtで拒否しても取り消せない。拒否は「これから」に効く施策と理解する
• User-agent名や各社の仕様は変わり得るため、設定時点の公式ドキュメントを確認し、確認日を社内メモに残す

よくある質問

robots.txtでブロックすれば、過去に学習された内容も消えますか？

消えません。robots.txtの拒否は今後のクロールを止めるだけで、すでにAIモデルに学習された内容や、過去に収集済みのデータには影響しません。だからこそ、方針は「これからどうしたいか」で決めるべきで、過去の分を悔やんで極端な設定に走る必要はありません。学習済みデータの扱いを争う訴訟や、AI企業とメディアのライセンス契約の動きは続いており、ルール自体がまだ形成途上です。

GPTBotをブロックするとGoogleの検索順位に影響しますか？

影響しません。GPTBotはOpenAIのボットで、Google検索のランキングとは無関係です。同様に、Google-Extendedを拒否しても通常のGoogle検索の掲載・順位には影響しないと公式に説明されています。ただし、Googlebot本体を誤って拒否すれば当然検索から消えていくため、robots.txt編集時のミスにだけは注意してください。

自社サイトにどのAIボットが来ているか、簡単に調べる方法は？

いちばん手軽なのはCDNやサーバーのアクセスログで「GPTBot」「ClaudeBot」「PerplexityBot」などのUser-agent名を検索することです。Cloudflareを使っているなら、管理画面のボットレポートでAIクローラーの訪問状況を一覧できます。まず直近1か月分を確認し、来ているボットの種類と頻度をメモしてから方針の議論を始めると、話が具体的になります。

llms.txtはSEOに悪影響がありますか？

悪影響は報告されていません。llms.txtは検索エンジンのランキング要因ではなく、置いても置かなくても順位には中立です。リスクがあるとすれば、記載内容の更新を忘れて実際のサイトとずれた案内を載せ続けることくらいです。導入する場合は、サイト構成を変えたときにllms.txtも直す、という運用ルールをセットにしてください。

まとめ

AIクローラーへの対応は、「拒否か受け入れか」の二択ではなく、学習用・検索インデックス用・ユーザー要求時取得用という3つの用途を分けて考えることから始まります。コンテンツ資産の保護を重く見るなら学習用を拒否し、AI検索という新しい発見経路を確保したいなら検索用は許可する——この選別型が多くのBtoBサイトの現実解です。制御の道具は今もrobots.txtが本線であり、llms.txtは主要AIクローラーにほとんど読まれておらずGoogleも不支持という現在地を踏まえ、過度な期待をせずに扱うのが賢明です。AI経由の流入は全体の1%前後とまだ小さいものの、検討度の高い訪問者を連れてくるという報告が積み上がりつつあります。方針を文書化し、ログと流入データを月次で観測し、四半期ごとに見直す。この地味なループを回せる会社が、AI検索時代の変化を味方につけていきます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。