SEO

AIクローラーのrobots.txt設定方法｜許可・拒否の書き分けを解説

Q: サイト全体ではなく特定のページだけAIクローラーに拒否することはできますか？

はい、Disallowディレクティブにパスを指定することで、特定のディレクトリやページのみを拒否できます。たとえばDisallow: /members/と書けば、そのディレクトリ配下だけが対象になり、サイト全体には影響しません。ページ単位で細かく制御したい場合は、HTMLの<meta name="robots">タグやHTTPレスポンスヘッダーも組み合わせると効果的です。

2026/08/02 2026/07/30

GPTBot・PerplexityBot・ClaudeBotなど主要AIクローラーのUser-Agent名と、robots.txtへの許可・拒否設定の書き方を実例つきで解説。AI検索に引用されるためのクローラー制御の戦略とページ別の判断基準も紹介します。

ChatGPTやPerplexityなどのAI検索が急速に普及するなか、「自社コンテンツがAI回答に引用されているのか、そもそもクローラーを受け入れているのかわからない」と悩むSEO担当者は多いのではないでしょうか。生成AIは独自のクローラーでWebページを収集しており、robots.txtの設定ひとつで引用の機会が大きく変わります。この記事では、AIクローラーのrobots.txt設定方法を体系的に解説します。GPTBot・PerplexityBot・ClaudeBot・Google-Extendedなど主要クローラーのUser-Agent名と用途、AI検索での引用機会を守る「許可」設定と情報保護目的の「拒否」設定の書き方、ページ種別ごとの判断フレームワーク、設定後の動作確認方法とよくある設定ミスのパターンまでを網羅しています。

1 AIクローラーとrobots.txtの関係をおさらい
2 主要AIクローラー一覧と「用途」別の整理
3 【重要】AIクローラーを会社単位でまとめて設定してはいけない理由
4 目的別・robots.txt設定パターン4選【コピペ対応】
5 robots.txtの基本文法と正しいファイル設置手順
6 設定後に必ず行う動作確認と検証方法
7 robots.txtだけでは不十分？llms.txtとの役割分担と限界
8 よくある質問（FAQ）
9 あわせて読みたい
10 まとめ

AIクローラーとrobots.txtの関係をおさらい

robots.txtは、Webサーバーのルートディレクトリに設置するテキストファイルです。クローラーがサイトを巡回する前にこのファイルを読み込み、アクセスを許可するURLと拒否するURLを判断します。検索エンジンのクローラーだけでなく、生成AI系のクローラーも同じ仕組みで動作します。

robots.txtでできること・できないこと

robots.txtで設定できる主な内容は次のとおりです。

特定のUser-Agent（クローラーの識別名）に対して、URLやディレクトリへのアクセスを拒否する
クロールを許可するパスを明示的に指定する
サイトマップのURLをクローラーに案内する

重要な前提として、robots.txtはクローラーへの「お願い」であり、強制力はありません。ルールを尊重するクローラーは記述に従いますが、悪意あるボットや一部の非準拠クローラーは無視してアクセスすることがあります。また、すでに別の経路でURLを取得したクローラーの挙動を完全に制御することもできません。コンテンツへのアクセスを物理的に遮断したい場合は、認証やIP制限など別の手段が必要です。

生成AI普及でrobots.txtが再注目される理由

ChatGPT SearchやPerplexity、Google AI Overviewsといった生成AI系の検索・回答サービスが広く使われるようになり、robots.txtの設定を見直す動きが活発になっています。これらのサービスは独自のクローラーでWebコンテンツを収集し、AIが回答を生成する際に引用元として使用します。自社コンテンツがAI検索の回答に引用されるかどうかが、ブランド認知やサイトへの流入に影響する場面が増えてきました。

以前は「Googlebotへの対応」が設定の中心でしたが、GPTBotやClaudeBot、PerplexityBotといったAI系クローラーが加わったことで、robots.txtで制御すべき対象が一気に広がっています。AIに引用・おすすめされるサイトを作るうえでも、クローラーへの許可設定は最初に整えるべき土台です。どのクローラーを許可し何を拒否するかを適切に設計しないと、AI検索からの流入機会を失ったり、意図せずコンテンツが学習データに使われるリスクが生じます。

主要AIクローラー一覧と「用途」別の整理

AIクローラーは「学習用」「検索用」「ユーザーfetch型」の3種類に大別できます。同じ企業が用途の異なる複数のクローラーを持つケースも多く、用途を混同したまま設定すると意図しない制御になります。まず以下の一覧で全体像を把握しましょう。

User-agent名	運営会社	用途
GPTBot	OpenAI	AIモデルの学習データ収集
ClaudeBot	Anthropic	AIモデルの学習データ収集
anthropic-ai	Anthropic	AIモデルの学習データ収集
Google-Extended	Google	Gemini・Vertex AI向け学習
CCBot	Common Crawl Foundation	学習データ用クロール
Bytespider	ByteDance	AIモデルの学習データ収集
OAI-SearchBot	OpenAI	ChatGPT Search（検索機能）用
PerplexityBot	Perplexity	AI検索インデックス用
Applebot-Extended	Apple	Apple AI機能向け
ChatGPT-User	OpenAI	ユーザー操作によるページ取得

上表の「User-agent名」列が、robots.txtで各クローラーを識別するための文字列そのものです。

学習用クローラー（GPTBot・ClaudeBot・anthropic-ai・Google-Extended・CCBot・Bytespiderなど）

学習用クローラーは、各社がAIモデルを訓練するためにWebコンテンツを収集します。これらをブロックしてもAI検索への引用には直接影響しないため、コンテンツ保護と引用最大化を両立させる上でブロック対象の第一候補となります。

AnthropicのクローラーはClaudeBotとanthropic-aiの2種類が存在します。どちらか一方だけ設定してももう一方は通過してしまうため、Anthropic系を制御する際は必ず両方を記述してください。

Google-ExtendedはGooglebotとは別物です。Google-ExtendedをDisallowしてもGooglebotのクロールは止まらず、Google検索の順位付けには影響しません。「検索順位は維持しつつGemini・Vertex AIへの学習データ提供だけを止めたい」という場合に使う設定です。

検索用クローラー（OAI-SearchBot・PerplexityBot・Applebot-Extendedなど）

検索用クローラーは、AI検索エンジンのリアルタイム回答生成に使われます。OAI-SearchBotはChatGPT Searchの検索機能専用クローラーであり、PerplexityBotはPerplexityのAI検索、Applebot-ExtendedはAppleのAI機能向けのインデックス収集を担います。これらをブロックすると各サービスの検索結果にコンテンツが表示されにくくなるため、AI検索からの流入を重視するサイトでは許可設定を維持するのが基本方針です。

ユーザーfetch型（ChatGPT-User）の特殊な扱い

ChatGPT-Userは、ユーザーがChatGPT上でURLを入力・共有した際にページを参照するUser-agentです。自動クロールではなくユーザーの操作が起点となるため、学習用・検索用とは性質が大きく異なります。ブロックすると、ChatGPTユーザーがリンクを共有してページ内容を読み取る操作が制限される点に注意が必要です。

【重要】AIクローラーを会社単位でまとめて設定してはいけない理由

robots.txtを設定する際、「OpenAIのクローラーをまとめてブロックする」という粗い粒度で指定すると、意図しない制御漏れが発生します。同一企業のクローラーでも用途ごとにUser-agentは分かれており、一括管理はミスの温床です。

「GPTBotをブロック＝ChatGPT引用がなくなる」は誤解

GPTBotのブロックは、学習データへの利用を止めることだけを意味します。ChatGPT Searchへの掲載可否はOAI-SearchBotが制御するため、GPTBotをブロックしてもChatGPT Searchの表示には直接影響しません。OpenAIの公式ドキュメントでも、両クローラーはrobots.txtで別々に指定できると明記されています。「GPTBotを止めたらChatGPT検索にも表示されなくなった」という事態は、この誤解が原因で起きます。

学習・検索・ユーザーfetchを用途で分けて制御する考え方

OpenAIのクローラーは、用途ごとに以下の3種類に分かれています。

User-agent	用途
GPTBot	学習データの収集
OAI-SearchBot	ChatGPT Searchのインデックス収集
ChatGPT-User	ユーザー起点のページ参照

コンテンツを学習に使われたくないがAI検索には露出したい場合、GPTBotはDisallowしつつOAI-SearchBotは許可するという設計が成立します。OpenAIのクローラーを一括でブロックすると検索結果への露出まで失う可能性があるため、必ず用途別に分けて指定することが重要です。

同一企業のクローラーでも用途によって許可・拒否を使い分ける設計思想

「どの会社か」ではなく「どの用途か」を基準に設定するのが、AIクローラー時代のrobots.txt設計の基本方針です。ChatGPT-Userは、ユーザーがChatGPT上でURLを入力・共有した際にリアルタイムでページを取得するUser-agentです。OpenAIは原則としてrobots.txtのルールに従うと説明しており、User-agent: ChatGPT-User に Disallow: / を記述することでアクセスを拒否できます。ただし、自動クローラーとは異なりユーザーの能動的な操作が起点となるため、通常の学習・検索クローラーとは性質が異なる点は押さえておく必要があります。この3種を混同せずに整理することが、ChatGPTへの引用・掲載を最適化するうえでの出発点になります。

目的別・robots.txt設定パターン4選【コピペ対応】

自社サイトの方針に合わせて4パターンを用意しました。コードブロックはそのまま流用できます。

パターン1：AIクローラーをすべて許可する（AI引用を最大化したい場合）

既存設定でAIクローラーを明示的に拒否していない場合、すでにこの状態です。追加設定なしで許可を明示したいときは以下を記述します。

User-agent: *
Disallow:

メリット：設定が最もシンプル。AI検索・学習いずれの引用機会も最大化される
デメリット：コンテンツが学習データに無断利用されることを許容する
向いているサイト：ブランド認知・集客拡大を最優先するコーポレートサイト、オウンドメディア

パターン2：学習はブロック・AI検索引用は維持する（最もよく選ばれる方針）

中小企業・一般的なWebサイトで最も推奨されるバランス型です。モデルの学習には使わせず、AI検索（Perplexity・ChatGPT検索など）への引用は維持します。

# 学習用クローラーをブロック
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

# AI検索用クローラーは許可
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Applebot-Extended
Allow: /

メリット：コンテンツ保護とAI検索露出を両立できる
デメリット：新しいクローラーが登場するたびに追記が必要
向いているサイト：独自コンテンツを持つECサイト・士業・コンサル系サイト全般

パターン3：AIクローラーをすべてブロックする（コンテンツ保護を優先する場合）

学習・検索引用を問わず、AIクローラー全般のアクセスを拒否します。

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

メリット：コンテンツの無断利用・引用を最大限に抑制できる
デメリット：AI検索経由の流入機会もゼロになる。なお前セクションで触れたChatGPT-Userはrobots.txtが適用されない場合があり、このパターンでも完全な遮断は保証されない
向いているサイト：有料会員コンテンツ、研究成果・独自ノウハウの保護を最優先するサイト

パターン4：特定ページだけAIクローラーを許可・拒否する（部分制御）

ページ種別ごとに許可・拒否を使い分ける最も細かい制御方法です。AllowはDisallowより優先されるため、記述順に注意してください。

# GPTBot：ブログは許可、製品ページ・マイページは拒否
User-agent: GPTBot
Allow: /blog/
Disallow: /products/
Disallow: /mypage/
Disallow: /admin/

# PerplexityBot：サイト全体を許可
User-agent: PerplexityBot
Allow: /

メリット：有益な情報だけをAI検索に提供しつつ、内部情報は保護できる
デメリット：記述が複雑になるほどミスが起きやすい。設定後の動作確認が必須
向いているサイト：ECサイト（商品情報は公開・購入導線は非公開）、会員制サービス、複合コンテンツを持つポータルサイト

robots.txtの基本文法と正しいファイル設置手順

これまでのパターン例をそのまま使う場合でも、文法の基本を把握しておくと設定ミスを防げます。ここでは記述ルール・ファイルの置き場所・Sitemapの書き方を順番に確認します。

User-agent・Disallow・Allowの書き方ルール

robots.txtは「どのクローラーに（User-agent）」「何を指示するか（DisallowまたはAllow）」をセットで記述します。1つのブロックはUser-agentから始まり、その直下にDisallow・Allowを並べます。ブロックとブロックの間は空行で区切るのが慣例です。

# 学習クローラーをブログのみ許可
User-agent: GPTBot
Allow: /blog/
Disallow: /

# で始まる行はコメントとして扱われ、クローラーには無視されます。設定の意図をメモしておくのに活用しましょう。User-agent: * はすべてのクローラーへの指示ですが、同じクローラー名を指定した個別ブロックがあればそちらが優先されます。個別設定と全体設定を組み合わせるときは、より詳細なブロックが上書き適用されることを念頭に置いてください。

ファイルの設置場所とURL（ルートドメイン直下が必須）

robots.txtはサイトのルートドメイン直下にのみ設置する必要があります。

✅ クローラーが読む場所：https://example.com/robots.txt
❌ 読まれない場所：https://example.com/blog/robots.txt

サブディレクトリに置いたファイルはクローラーから参照されないため、この点は特に注意が必要です。また、サブドメインを運用している場合（shop.example.com など）は、それぞれのサブドメインに個別のrobots.txtを設置しなければなりません。メインドメインのrobots.txtはサブドメインには適用されません。

Sitemapディレクティブの追記方法

robots.txtにはサイトマップのURLを記述できます。ファイルの末尾に以下の形式で追記してください。

Sitemap: https://example.com/sitemap.xml

SitemapディレクティブはUser-agentブロックに紐づかず、ファイル全体に対して有効です。複数のサイトマップがある場合は行を分けて列挙できます。これを記述しておくと、クローラーがサイト構造を把握しやすくなり、インデックスの効率向上が期待できます。robots.txtを使ったクローラー最適化の具体的な手順も参照しながら、設定内容を一通り見直してみましょう。

設定後に必ず行う動作確認と検証方法

robots.txtを変更したら、意図した通りに機能しているかを必ず検証しましょう。設定ミスに気づかないまま放置すると、AI引用を期待していたクローラーをブロックしていたり、保護したいコンテンツを開放してしまうリスクがあります。

Google Search Consoleのrobots.txtテスターで意図通りか確認する

Google Search Console（GSC）のrobots.txtテスターを使うと、特定のURLがクローラーにブロックされているかをシミュレーションできます。確認手順は次の通りです。

GSCのrobots.txtレポートを開く
テストしたいURLを入力し、User-agentを選択する（例：Googlebot）
「テスト」をクリックし、「許可済み」または「ブロック済み」の判定を確認する

ブロックされている場合は、原因となっている記述が赤くハイライト表示されます。テスター画面で編集した内容はサーバーには自動保存されないため、修正した記述は必ず実際のrobots.txtファイルに反映させてください。なお、GSCのURL検査ツールでも、対象ページがrobots.txtのルールでブロックされているかを確認できます。両ツールを組み合わせて二重チェックするのが確実です。

設定変更後は、GSCのrobots.txtレポートにある「再クロールをリクエスト」機能でGoogleへの反映を促しましょう。

サーバーアクセスログでAIクローラーの到達を検証する

GSCのテスターはGooglebotの確認に特化しており、GPTBotやPerplexityBotなどのAIクローラーは確認対象外です。これらが実際にサイトへ到達しているかは、サーバーのアクセスログで確認します。

アクセスログにはリクエストごとのUser-agent文字列が記録されています。以下のようにgrepコマンドでUser-agent名を絞り込むと、対象クローラーのアクセス履歴を効率よく抽出できます。

grep "GPTBot" /var/log/nginx/access.log
grep "PerplexityBot" /var/log/nginx/access.log

ブロック設定後もアクセスが継続している場合は、そのクローラーがrobots.txtを遵守していない可能性があります。その場合はサーバー側でのIPブロックなど、別の対策を検討してください。

反映タイミングとキャッシュに注意すべき点

クローラーは取得したrobots.txtを一定期間キャッシュします。ファイルを更新してもクローラーが古いルールで動作し続ける場合があり、「再クロールをリクエスト」を送っても再クロールのタイミングはクローラー次第です。変更が即座に効かない場合があることを前提に、設定後はアクセスログを定期的に確認しながら数日単位でクローラーの挙動を観察してください。

robots.txtだけでは不十分？llms.txtとの役割分担と限界

robots.txtはあくまで紳士協定—守らないクローラーへの対処

robots.txtには、技術的にも法的にも強制力がありません。あくまでクローラーに「このルールを守ってください」と伝えるディレクティブであり、悪意あるボットや一部の非準拠クローラーはこれを無視してクロールできてしまいます。AI普及に伴い、この協定を守らないクローラーが増えているのも事実です。ブロックを設定していても無断クロールが続く場合は、サーバー側のIPブロックなど別の手段を併用する必要があります。

llms.txtとは何か：AIに読ませたい情報を積極的に伝えるファイル

llms.txtは、生成AI（LLM）がサイトの情報を正しく理解・引用できるよう案内するための補助ファイルです。robots.txtが「クロールを制御する」のに対し、llms.txtは「AIに渡したい情報を積極的に提示する」役割を担います。Markdown形式で記述し、H1にサイト名を書くだけで最低限の実装は完了するため、設置コストはほぼゼロです。重要ページに絞ったキュレーションが推奨されており、10KB以下の軽量ファイルとして運用するのが慣習となっています。

なお、現時点ではPerplexityが試験的にllms.txtの読み取りを導入していますが、GoogleやOpenAIは公式な対応を表明していません。効果を過信せず、あくまで補完的な施策として位置づけることが重要です。

robots.txt（クロール制御）×llms.txt（内容ガイド）の使い分け

2つのファイルは役割が異なるため、組み合わせて使うのが基本です。実装の順序としては、まずrobots.txtでGPTBot・ClaudeBot・PerplexityBotなどをAllowしてクロールを受け入れ、その上でllms.txtにMarkdown形式のサイト案内を置くという流れになります。

ファイル	役割	対象
robots.txt	クロールの許可・拒否を制御	クローラー全般
llms.txt	AIに読ませたい情報を能動的に提示	生成AI（LLM）

ただし、この2ファイルを整えるだけでAI検索に引用されるわけではありません。AI検索で引用されるには、構造化データの実装やコンテンツの専門性・網羅性といった品質面が根本的な条件となります。robots.txtとllms.txtはその「土台づくり」として機能するものと理解してください。

よくある質問（FAQ）

robots.txtでAIクローラーを拒否すると、検索順位に影響しますか？

AIクローラーへの拒否設定は、GoogleやBingなどの検索エンジンのクローラーとは別に制御できるため、適切に書き分ければ検索順位への影響はありません。robots.txtではUser-agentごとにルールを指定できるので、検索ボットは許可しつつAIクローラーだけを拒否することが可能です。ただし、User-agent: *で全ボットを拒否する設定は検索クローラーにも適用されるため注意が必要です。

GPTBot以外にも拒否すべきAIクローラーはありますか？

はい、GPTBotのほかにもCCBot（Common Crawl）やGoogle-Extended、ClaudeBot（Anthropic）など、複数のAIクローラーが存在します。それぞれ異なるUser-agent名を持つため、拒否したいクローラーを個別に指定する必要があります。各AIサービスの公式ドキュメントで正式なUser-agent名を確認してから設定することを推奨します。

robots.txtの設定はAIクローラーに必ず守られますか？

robots.txtはあくまで「お願い」の仕組みであり、法的拘束力はなく、悪意のあるボットには無視される場合があります。ただし、OpenAIやAnthropicなどの主要AI企業はrobots.txtのルールを遵守すると公表しています。重要なコンテンツを確実に保護したい場合は、アクセス制限や認証との併用を検討してください。

robots.txtを変更したあと、すぐにクローラーへ反映されますか？

いいえ、変更はすぐには反映されません。クローラーがrobots.txtを再取得するタイミングはボットごとに異なり、反映まで数日〜数週間かかる場合があります。設定変更後は時間をおいてサーバーのアクセスログを確認し、対象クローラーのアクセスが変化しているかを確認するのが確実です。

サイト全体ではなく特定のページだけAIクローラーに拒否することはできますか？

はい、Disallowディレクティブにパスを指定することで、特定のディレクトリやページのみを拒否できます。たとえばDisallow: /members/と書けば、そのディレクトリ配下だけが対象になり、サイト全体には影響しません。ページ単位で細かく制御したい場合は、HTMLの<meta name="robots">タグやHTTPレスポンスヘッダーも組み合わせると効果的です。

まとめ

AIクローラーへの対応は、「許可か拒否か」の二択ではなく、用途ごとに設定を分けることが出発点です。この記事で解説した要点を以下に整理します。

AIクローラーは3用途に分類して考える。 学習用（GPTBot・ClaudeBotなど）、検索用（OAI-SearchBot・PerplexityBotなど）、ユーザーfetch型（ChatGPT-Userなど）は、それぞれ役割が異なる。同一企業のクローラーであっても、用途ごとに許可・拒否を使い分けることが適切な設計の基本となる。
「学習ブロック×AI検索許可」が現実的な方針として選ばれやすい。 独自コンテンツの無断学習を防ぎながら、AI検索エンジンへの引用機会は維持できる。多くのサイトにとってバランスの取れた出発点となる。
robots.txtはルートドメイン直下への設置が必須。 ファイルを用意したらGoogle Search ConsoleのURL検査やrobots.txtテスター機能を使い、意図した通りにクローラーを制御できているかを必ず確認する。設定変更後はキャッシュの反映タイミングにも注意が必要。
robots.txtだけではAI検索対策として不十分な場面がある。 クロール制御を担うrobots.txtと、AIに読ませたい情報を能動的に伝えるllms.txtを組み合わせることで、AI検索への対応をより強固にできる。ただし、この2ファイルの整備はあくまで土台であり、引用されるかどうかはコンテンツの質が根本的な条件となる点は変わらない。

次にとるべきアクションはひとつです。 今すぐブラウザで https://（自サイトのドメイン）/robots.txt にアクセスし、現在の設定内容を確認してください。AIクローラーへの記述が一切ない場合も、意図せず全許可になっている状態です。本記事のパターン別サンプルを参照しながら、自サイトの方針に合った記述へ更新することが、AI検索対応の具体的な第一歩になります。