robots.txtでAIクローラーを許可すべきか。GPTBot・OAI-SearchBot・ClaudeBotの判断基準

結論から言うと、AI検索に自社サイトを見つけてもらいたい場合、robots.txt では 「検索・回答表示に関わるクローラー」と「生成AIモデル学習に関わるクローラー」を分けて判断する のが基本です。すべてのAIクローラーを一括で拒否すると、学習利用を避けられる可能性がある一方で、ChatGPT検索、Claudeの検索機能、Perplexityなどで公式ページが見つかりにくくなる可能性があります。

実務上の初期方針は、次のように整理できます。

1. 会社概要、サービス、料金、FAQ、事例など、AI検索に根拠として読ませたい公開ページは、検索用クローラーを不用意にブロックしない。
2. 生成AIモデルの学習利用に懸念がある場合は、学習用クローラーだけを個別に拒否する。
3. 非公開情報、会員向け情報、古い資料、法務上読ませたくない情報は、robots.txt だけで守らず、認証、削除、リダイレクト、noindex、アクセス制御まで含めて処理する。

OpenAIの場合、ChatGPT検索に関わる OAI-SearchBot と、基盤モデル学習に関わる GPTBot は別のユーザーエージェントとして案内されています。Anthropicも、学習系の ClaudeBot、ユーザー起点取得の Claude-User、検索品質向上の Claude-SearchBot を分けて説明しています。つまり「GPTBotを許可するか」だけでAI検索全体を判断するのは不十分です。

定義ブロック：robots.txt AIクローラー設定とは robots.txt AIクローラー設定とは、サイト直下の /robots.txt にユーザーエージェントごとの Allow / Disallow ルールを書き、AI関連クローラーにどのURLのクロールを許可・拒否するかを示す運用です。 目的は、公開ページの発見性、AI検索での参照可能性、生成AIモデル学習への利用、サーバー負荷、権利・法務リスクを分けて管理することです。 ただし robots.txt はアクセス権限や機密保護の仕組みではなく、クローラー側が尊重する前提の制御です。ページを検索結果から外したい場合や情報を保護したい場合は、noindex、認証、削除、WAF、サーバー設定など別の手段も必要です。

robots.txtは「AI検索のスイッチ」ではない

robots.txt は、検索エンジンやクローラーに「このURLをクロールしてよいか」を伝えるためのファイルです。標準仕様はRFC 9309で整理されており、Google Search Centralも、robots.txtは主にクローラーのアクセスやクロール負荷を管理するためのものだと説明しています。

ここで重要なのは、robots.txt が次の3つを直接保証しないことです。

• AI検索で表示されること
• AI回答に引用されること
• ページが完全に秘匿されること

Google公式ドキュメントでは、robots.txt はGoogle検索からWebページを隠す仕組みではなく、ページを検索結果から外したい場合は noindex やパスワード保護などを使うべきだと説明されています。また、RFC 9309も、robots.txtのルールはアクセス認可の代わりではないと明記しています。

AI検索の文脈でも同じです。robots.txt で検索用クローラーを許可しても、AI回答に採用されるとは限りません。逆に拒否しても、第三者サイト、過去にクロール済みの情報、ユーザー操作起点の取得、検索インデックス、外部リンクなど、別の経路で情報が使われる可能性をゼロにはできません。

だからこそ、robots.txtは「AIに載るための魔法の設定」ではなく、到達性を壊さないための入口管理として扱うのが現実的です。

まず分けるべき3種類のクローラー

AI関連のユーザーエージェントは、名前が似ていても目的が違います。判断を誤りやすいので、最初に3種類へ分けます。

• 検索用: AI検索や検索回答でWebサイトを見つけるための取得。例は OAI-SearchBot、Claude-SearchBot、PerplexityBot。
• 学習用: 生成AI基盤モデルの学習や改善に使われうる取得。例は GPTBot、ClaudeBot。
• ユーザー操作起点: ユーザーがURL取得やWeb参照を依頼した時のアクセス。例は ChatGPT-User、Claude-User、Perplexity-User。

AI検索に載りたい企業サイトで最も危険なのは、「AIクローラー」という大きな括りで全拒否することです。学習利用を避けたいだけなら、学習用クローラーを個別に制御します。検索面で公式ページを見つけてほしいなら、検索用クローラーは別の判断にします。

GPTBot・OAI-SearchBot・ClaudeBotの判断表

OpenAIとAnthropicの公式情報をもとに、主要なボットを実務判断へ落とすと次のようになります。ここでの「許可寄り」「拒否寄り」は一般的な公開企業サイトの初期判断であり、法務・ライセンス・会員制コンテンツ・メディア事業では個別判断が必要です。

重要なのは、GPTBot と OAI-SearchBot、ClaudeBot と Claude-SearchBot を同じ扱いにしないことです。AI検索に載りたいのに検索用クローラーを止め、学習利用を止めたいのに学習用だけを見ていない、という逆転がよく起きます。

Perplexityについても、公式ドキュメントでは検索結果でWebサイトを表示・リンクするための PerplexityBot と、ユーザー操作起点の Perplexity-User が分けて説明されています。Perplexityでの引用設計は、Perplexityで引用される情報源をどう設計するかでも整理しています。

許可・拒否を決める質問

robots.txtの設定は、ボット名から入るより、ページの目的から決めた方が安全です。最低限、次の観点を確認します。

AI検索に載りたい場合、まずは「読ませたい公開ページ」と「読ませたくないページ」を分けます。そのうえで、検索用クローラーは前者に通し、学習用クローラーは会社方針で決める、という順番が実務的です。

実装パターン1：検索用は許可し、学習用は拒否する

企業サイトでよくあるのは、「AI検索には公式情報を見つけてほしいが、生成AIモデルの学習利用は慎重にしたい」という方針です。この場合、OpenAIでは OAI-SearchBot と GPTBot を分けます。

<pre><code>User-agent: OAI-SearchBot Allow: /

User-agent: GPTBot Disallow: /</code></pre>

この例は、ChatGPT検索に関わる検索用クローラーは許可し、学習用のGPTBotは拒否する意図を明示するものです。OpenAI公式ドキュメントも、OAI-SearchBotの許可とGPTBotの拒否は独立して扱える例として説明しています。

Anthropicでも同じ考え方を使えます。学習用の ClaudeBot は拒否し、検索用の Claude-SearchBot は許可する、という分け方です。

<pre><code>User-agent: Claude-SearchBot Allow: /

User-agent: ClaudeBot Disallow: /</code></pre>

ただし、Allow: / を書けば必ずAI回答に表示されるわけではありません。あくまで到達性を妨げない設定です。AI検索での説明品質は、正本ページの内容、見出し、本文の明確さ、内部リンク、外部情報との整合性、検索インデックスの状態なども影響します。robots.txtだけで完結させず、LLMO診断で見るべき項目とセットで点検します。

実装パターン2：公開情報だけ許可し、特定ディレクトリを拒否する

サイト全体を許可するのではなく、特定ディレクトリだけ拒否したい場合もあります。たとえば、公開はしているがAI検索に読ませたくない古いPDFや、検索面に出す必要のない内部資料ディレクトリがある場合です。

<pre><code>User-agent: OAI-SearchBot Allow: / Disallow: /old-docs/ Disallow: /temporary/

User-agent: GPTBot Disallow: /</code></pre>

この場合の注意点は、/old-docs/ に本当に公開してよい情報しか置かれていないかです。robots.txtにパスを書くと、そのパスの存在自体は公開されます。機密情報の保護にはなりません。

また、古いページを検索結果から外したい目的なら、robots.txtで遮断するだけでは不十分です。Googleは、noindexを有効にするにはクローラーがそのページへアクセスできる必要があると説明しています。robots.txtで先に遮断すると、クローラーが noindex を読めず、URLだけが検索結果に残る可能性があります。

実装パターン3：全AIクローラー拒否を選ぶ場合

メディア、独自データベース、会員制教材、契約上の制約が強いコンテンツでは、検索露出よりも権利保護や利用制限を優先し、検索用クローラーも含めて拒否する判断があります。その場合は、OAI-SearchBot、GPTBot、Claude-SearchBot、ClaudeBot、PerplexityBot など、対象サービスごとに拒否対象を列挙します。

この方針を選ぶなら、「AI検索からの発見性よりも取得制限を優先する」と社内で合意しておく必要があります。AI検索に載りたい企業サイトの通常運用では、最初から全拒否にする前に、検索用と学習用の分離を検討してください。

また、悪質なクローラーや仕様を守らない取得を止めたい場合、robots.txtだけでは限界があります。WAF、Bot管理、IP検証、レート制限、認証、ログ監視まで含めて設計します。Perplexity公式ドキュメントも、WAFを使う場合はユーザーエージェントと公開IPレンジを組み合わせて許可する考え方を示しています。

WordPress運用での実装チェックリスト

WordPressサイトでは、SEOプラグイン、サーバー設定、CDN、セキュリティプラグインがそれぞれrobots関連の挙動に関わることがあります。設定ファイルだけを見て完了にせず、本番URLで確認します。

llms.txtを併用する場合も、先にrobots.txtと検索制御を整えます。llms.txtはサイトの要点や正本URLを伝える補助ファイルであり、クロール許可や検索表示を制御する主役ではありません。導入前の考え方はWordPressでllms.txtを設置する前に確認すべきことで解説しています。

よくある失敗例

失敗例1：GPTBotを許可しているのでChatGPT検索も大丈夫だと思う

GPTBot はOpenAIの学習用クローラーとして案内されています。ChatGPT検索の表示に関わるのは OAI-SearchBot です。そのため、GPTBotだけを見てChatGPT検索の到達性を判断すると、確認対象を間違えます。

AI検索に見つけてもらいたいなら、まず OAI-SearchBot が正本ページに到達できるかを確認します。学習利用を制限したいなら、GPTBotの扱いを別に決めます。

失敗例2：ClaudeBotを拒否したらClaude検索も全部止まると思う

Anthropicは ClaudeBot、Claude-User、Claude-SearchBot を分けて説明しています。ClaudeBot は学習系、Claude-SearchBot は検索品質向上、Claude-User はユーザー起点取得です。

Claudeの検索面で公式ページを読ませたい一方、モデル学習への利用は避けたい場合、ClaudeBot だけを拒否し、Claude-SearchBot は別判断にします。ボット名の「Claude」だけで一括判断しないことが重要です。

失敗例3：User-agent: * で全拒否したあと、個別Allowを書いて安心する

User-agent: * に Disallow: / を書くと、全クローラー拒否の意図が強くなります。仕様上はより具体的なユーザーエージェントのグループが優先されるケースがありますが、クローラーごとの解釈差や設定ミス、WAF側の別ルールが絡むと、意図通りに動かないことがあります。

AI検索に載せたいページがあるなら、全体拒否を前提にする前に、対象ボットごとのログ確認を行います。特定の非公開領域を守りたいだけなら、サイト全体ではなく対象パスを絞る方が安全です。

失敗例4：robots.txtを機密保護に使う

robots.txtは公開ファイルです。Disallow: /secret/ と書けば、そのパスの存在を外部に示すことになります。仕様上も、robots.txtはアクセス認可の代わりではありません。

見られて困る情報は、Webに置かない、認証をかける、ネットワーク制限を使う、署名付きURLにする、不要なら削除する、といったアクセス制御で守ります。robots.txtは「尊重するクローラーにクロールしないでほしいと伝える」ためのものです。

失敗例5：noindexしたいページをrobots.txtで先に遮断する

検索結果から外したいページに noindex を入れても、robots.txtでクロールを遮断していると、クローラーがその noindex を読めない場合があります。Google公式も、noindexを有効にするにはページがrobots.txtでブロックされていない必要があると説明しています。

古い料金ページや終了したキャンペーンページを処理する場合は、robots.txtだけで止めず、削除、リダイレクト、noindex、canonical、内部リンク削除まで含めて設計します。AI検索で古い情報が残る問題は、AI検索に古い情報が出る時の記事更新手順も参考になります。

設定変更後に見るべきログ

robots.txtを変えたら、ブラウザでファイルを見て終わりにしないでください。アクセスログで対象ユーザーエージェントが正本ページへ到達しているか、WAFログで403やBot判定になっていないか、CDNで古いrobots.txtが返っていないかを確認します。

ログ確認では、到達の有無と回答採用を分けて見ます。クローラーが来ていても、AI回答に使われるとは限りません。反対に、回答に出たとしても、その原因がrobots.txt変更だけとは限りません。LLMOの計測は、LLMOの効果測定で見るべき指標のように、検索面、クエリ、回答本文、出典、流入を分けて記録する必要があります。

FAQ

Q1. GPTBotを拒否するとChatGPT検索に出なくなりますか？

OpenAI公式ドキュメントでは、ChatGPT検索に関わる検索用クローラーは OAI-SearchBot、生成AI基盤モデルの学習に関わるクローラーは GPTBot と分けて案内されています。そのため、GPTBotの拒否だけでChatGPT検索の可否を判断するのは適切ではありません。ChatGPT検索への到達性を見たい場合は、OAI-SearchBot の扱いを確認します。

Q2. OAI-SearchBotを許可すればChatGPTに必ず表示されますか？

表示は保証されません。OAI-SearchBot の許可は、ChatGPT検索側が対象ページを取得できる可能性を残す設定です。実際に回答や出典として扱われるかは、ページ内容、検索意図との一致、鮮度、信頼性、他の情報源、検索側の仕様など複数要因に左右されます。

Q3. ClaudeBotを拒否してもClaude-SearchBotは許可できますか？

Anthropic公式ヘルプでは、ClaudeBot、Claude-User、Claude-SearchBot が別のボットとして説明されています。学習用の ClaudeBot を拒否し、検索品質向上に関わる Claude-SearchBot を許可する、という分け方は実務上の検討対象になります。ただし、対象ページの権利や公開方針に合わせて判断してください。

Q4. robots.txtで拒否すればAIに情報を使われませんか？

完全な保証にはなりません。robots.txtは、尊重するクローラーにクロール方針を伝える仕組みです。すべてのクローラーが同じように従うとは限らず、ユーザー起点取得、第三者ページ、過去の取得情報、検索インデックスなど別経路もあります。秘匿したい情報は認証や削除で守るべきです。

まとめ：AI検索に載りたいなら、全拒否ではなく「目的別制御」にする

robots.txtでAIクローラーを許可すべきかは、1つの答えで決まりません。公開ページをAI検索に見つけてほしいなら、検索用クローラーを止めすぎないことが重要です。一方で、生成AIモデルの学習利用に懸念があるなら、学習用クローラーを個別に拒否する選択肢があります。

判断の軸は次の3つです。

1. AI検索に根拠として読ませたい公開ページか。
2. 生成AIモデル学習への利用を許容できる内容か。
3. robots.txt以外のnoindex、WAF、認証、削除、リダイレクトと矛盾していないか。

AI検索攻略では、robots.txtだけを単独施策として扱わず、正本ページ、内部リンク、llms.txt、構造化データ、計測ログと合わせて点検することを推奨します。自社サイトで「検索用クローラーまで止めていないか」「学習用だけを意図通り制御できているか」を確認したい場合は、LLMO診断で技術設定とAI検索上の見え方を合わせて棚卸しできます。

EDITORIAL REVIEW AI検索攻略編集部（株式会社Uravation）

生成AI・AI検索・SEOの公開情報を確認しながら、企業サイトの情報設計として実務で扱える形に整理しています。仕様変更が多い領域のため、公開前後に公式情報と本文の整合性を確認します。