GPTBotの役割や、OAI-SearchBot・ChatGPT-Userとの違いを解説し、robots.txtによるAIクローラーの許可・拒否設定例や、SEO・AI検索への影響、WAF・CDNを使った制御方法、設定後の確認ポイントまで紹介します。
GPTBotをはじめとするAIクローラーは、生成AIの学習やAI検索での情報取得など、用途によって役割が異なります。そのため、すべてのAIクローラーを一律に拒否すると、意図せずChatGPTなどのAI検索からの引用やサイト流入まで失う可能性があります。
自社コンテンツを適切に保護しながらAI検索での露出も確保するには、GPTBot・OAI-SearchBotなどの違いを理解し、目的に応じてrobots.txtやWAF・CDNを使い分けることが重要です。本記事では、主要なAIクローラーの種類や役割、robots.txtの具体的な設定例、設定後の確認方法まで解説します。自社サイトに適したAIクローラーの制御方針を検討する際の参考にしてみてください。
2026年版＼無料／LLMO対策実践ガイド2026を受け取る
無料資料ダウンロード
LLMO対策実践ガイド2026
AIに推薦される会社の5つの条件と、自社診断20項目
- 商談前ヒアリングで多かった声
- AIは何を見て「おすすめ」を決めるのか
- よくある4つの誤解
目次
GPTBotとは
GPTBotは、OpenAIが運用するWebクローラーの一つです。インターネット上で一般公開されているWebページを巡回し、取得したコンテンツをOpenAIのAIモデルの学習や改善に役立てる目的で使用されます。サイト運営者はrobots.txtでGPTBotのアクセスを拒否し、公開コンテンツを学習目的でクロールされないよう制御できます。
学習目的のクローラーとAI検索向けのクローラーでは役割が異なるため、アクセス方針は用途ごとに分けて設定することが重要です。
AIクローラーは主な用途別に整理して考える
AIクローラーは、すべてが同じ目的でWebサイトへアクセスするわけではありません。モデルの学習、AI検索での情報取得、ユーザーの指示によるページ取得など、用途によって役割が異なるため、それぞれを区別して制御することが重要です。ここでは、AIクローラーの代表的な用途を3つに整理して解説します。
AIモデルの学習用クローラー
AIモデルの学習用クローラーは、Web上のコンテンツを収集し、生成AIの基盤モデルの改善や学習に利用することを主な目的とするクローラーです。代表例としてOpenAIのGPTBotがあり、サイト運営者はrobots.txtでアクセスを許可・拒否できます。GPTBotを拒否することで、自社サイトのコンテンツがOpenAIの生成AIモデル改善に利用される対象から除外する意思を示せます。
一方、学習用クローラーの制御とAI検索への掲載は分けて考えることが重要です。学習用と検索用で異なるUser-agentが用意されている場合は、「AI学習は拒否したいが、AI検索からの引用や流入は確保したい」といった目的に応じて設定できます。
AI検索・回答生成用クローラー
AI検索・回答生成用クローラーは、AIがWeb上の情報を検索し、ユーザーへの回答や引用元の提示に活用するためにコンテンツを取得するクローラーです。OpenAIではOAI-SearchBotがこの役割を担っており、ChatGPT検索でサイトの内容を要約やスニペットに含めてもらうには、OAI-SearchBotをブロックしないことが推奨されています。
学習用クローラーとは用途が異なるため、生成AIの学習を拒否する場合でも、検索用クローラーまで一律に遮断する必要はありません。AI検索から自社サイトへの引用や流入を期待するのであれば、学習用と検索用のUser-agentを区別し、検索に必要なクローラーがアクセスできる状態を維持することが重要です。
ユーザー操作を起点にページを取得するエージェント
3つ目は、AIサービスのユーザーによる操作をきっかけに、特定のWebページへアクセスするエージェントです。サイト全体を継続的に巡回して情報を集める一般的なクローラーとは異なり、ユーザーがURLを指定したり、AIにページの内容を確認させたりする場面などでアクセスが発生します。このようなユーザー起点のアクセスに用いられるUser-agentもあります。
このタイプは、モデル学習や検索インデックス作成を目的としたクローラーとは性質が異なります。そのため、「学習への利用」「AI検索への掲載」「ユーザーが明示的に求めたページ取得」を分けて整理し、自社がどこまでアクセスを許可するのかを決めることが大切です。
代表的なAIクローラー・制御トークンの種類
AIクローラーや生成AI向けの制御トークンは、提供元によって名称や役割、robots.txtへの対応方法が異なる点に注意が必要です。学習用・検索用・ユーザー操作起点など目的を把握しておくことで、自社の方針に合った制御を行いやすくなります。ここでは、代表的なAIクローラーと制御トークンの特徴について解説します。
OpenAI｜GPTBot・OAI-SearchBot・ChatGPT-User
OpenAIでは、Webへのアクセス目的に応じて複数のUser-agentを使い分けています。GPTBotは、生成AIの基盤モデルをより有用かつ安全にするため、学習に利用される可能性のあるコンテンツを収集するクローラーです。一方、OAI-SearchBotはChatGPTの検索機能でWebサイトを検索結果に表示するために利用されます。
ChatGPT-Userは自動巡回用ではなく、ユーザーがChatGPTやカスタムGPTを利用した際などにページへアクセスするためのUser-agentです。GPTBotとOAI-SearchBotは個別に制御できるため、AI学習を拒否しながらChatGPT検索への露出を確保したい場合は、それぞれの役割を区別して設定する必要があります。なお、ChatGPT-Userはユーザー操作を起点とするため、robots.txtのルールが適用されないケースもある点に注意が必要です。
Anthropic｜ClaudeBot・Claude-SearchBot・Claude-User
Anthropicも、Claudeで利用するWebアクセスを目的別に3種類へ分けています。ClaudeBotは、生成AIモデルの有用性や安全性を高めるため、将来のモデル学習に利用される可能性があるWebコンテンツを収集するクローラーです。Claude-SearchBotはWebを巡回し、Claudeの検索結果の関連性や正確性を高める役割を担います。
Claude-Userは、ユーザーからの質問などをきっかけにClaudeがWebサイトへアクセスするときに使用されます。Anthropicはこれらを別々のUser-agentとして提供しており、robots.txtによって個別にアクセス方針を設定できます。そのため、モデル学習は拒否しつつ検索経由の露出を維持したい場合など、自社の方針に合わせて対象を選び分けることが重要です。
Perplexity｜PerplexityBot・Perplexity-User
Perplexityでは、主にPerplexityBotとPerplexity-Userという2種類のUser-agentが使用されています。PerplexityBotは、WebサイトをPerplexityの検索結果に表示し、情報源としてリンクできるようにするためのクローラーです。公式情報では、AI基盤モデルの学習を目的としたコンテンツ収集には使用しないと説明されています。
Perplexity-Userは、ユーザーから質問を受けた際にWebページへアクセスし、回答に必要な情報を取得するために使用されます。こちらもAI基盤モデルの学習用ではありません。Perplexity-Userによるアクセスはユーザー操作を起点としているため、一般的にrobots.txtのルールを無視すると案内されています。確実にアクセスを制御したい場合は、robots.txtだけでなくWAFなどによる制御も検討する必要があります。
Google｜Google-Extended
Google-Extendedは、一般的なWebクローラーとは性質が異なり、Googleがクロールしたコンテンツを生成AI関連でどのように利用できるかをWebサイト側が制御するためのrobots.txt用トークンです。独立したHTTPリクエスト用User-agentとしてWebページを巡回するのではなく、既存のGoogleのUser-agentによって取得されたコンテンツの利用範囲を管理します。
Google-Extendedでは、Geminiを支える将来世代のモデルの学習や、Gemini Apps、Vertex AIにおけるGoogle検索を利用したグラウンディングへのコンテンツ利用を制御できます。Googleは、Google-Extendedの設定がGoogle検索への掲載や検索順位のシグナルには影響しないと明記しています。そのため、通常のGoogle検索と生成AI向けの利用方針を切り分けて考えられます。
その他｜CCBot・Applebot-Extendedなど
主要企業以外にも、生成AIや大規模データ収集に関連するUser-agentがあります。CCBotは非営利団体Common Crawlが運営するクローラーで、公開Webデータを収集してオープンなデータセットとして提供しています。robots.txtに対応しており、「CCBot」を指定してクロールを拒否できます。
Applebot-Extendedは実際にWebページを巡回するクローラーではなく、既存のクローラーが取得したコンテンツを生成AI基盤モデルの学習に利用できるか制御するための仕組みです。拒否しても検索結果への掲載自体を妨げるものではありません。そのほかにも、AI関連のクローラーや制御用トークンが存在します。サイト管理者は名称だけで一括して判断せず、それぞれの用途を確認したうえで許可・拒否を判断することが大切です。
AIクローラーを制御する必要がある理由
AIクローラーを制御する必要があるのは、自社コンテンツをどの用途まで利用させるかをサイト運営者側で判断するためです。生成AIの学習、AI検索での情報取得、ユーザー操作を起点としたアクセスでは目的が異なるため、すべてのクローラーを一律に許可・拒否すると、自社の方針と合わない結果になる可能性があります。
制御方針を決める際は、学習への利用、AI検索での参照、ユーザー操作に伴う取得のどこまでを許可するかを整理します。用途ごとに判断基準を分けることで、自社の方針に合ったアクセス範囲を決めやすくなります。
自社コンテンツの保護とAI経由の露出機会を両立するには、クローラーごとの役割を把握したうえで、事業方針に応じてアクセス範囲を設定することが重要です。
robots.txtとは
robots.txtとは、Webサイトを巡回するクローラーに対して、どのURLへのアクセスを許可・拒否するかを伝えるためのテキストファイルです。原則としてサイトのルートディレクトリに設置し、「User-agent」で対象のクローラーを指定し、「Disallow」「Allow」などでクロール可能な範囲を設定します。検索エンジンだけでなく、robots.txtに対応するAIクローラーの巡回方針を指定する際にも利用できます。
ただし、robots.txtはアクセスを技術的に強制遮断する仕組みではなく、クローラー側にルールの遵守を求める仕組みです。そのため、すべてのクローラーが必ず従うとは限らず、機密情報の保護には適していません。また、クロールの拒否と検索結果・AI回答での表示制御は異なります。表示を制御したい場合は、利用するサービスが対応するnoindexなどの仕様を確認し、機密情報は認証やアクセス制御などで保護することが重要です。
robots.txtでGPTBot・AIクローラーを制御する設定例
robots.txtでは、User-agentごとにアクセスの許可・拒否を設定できます。目的に応じてAIクローラーを個別に制御することが重要です。
ここでは、GPTBotや主要なAIクローラーを制御するrobots.txtの設定例について紹介します。
GPTBotだけを拒否する
AIモデルの学習に自社コンテンツを利用されたくない場合は、robots.txtで対象のUser-agentを指定してサイト全体へのアクセスを拒否します。記述例は以下のとおりです。
User-agent: GPTBot
Disallow: /「Disallow: /」は、指定したUser-agentに対してサイト全体のクロールを拒否する記述です。この設定ではGPTBotだけを対象としているため、Googlebotなどほかのクローラーを一律に拒否する設定にはなりません。OpenAIも、GPTBotを拒否することで、クロールされたコンテンツを生成AIの基盤モデルの学習対象から除外する意思を示せると案内しています。
ただし、GPTBotとChatGPT検索用のOAI-SearchBotは別のUser-agentです。AI検索への露出も制御したい場合は、それぞれの目的に応じて個別に設定する必要があります。
GPTBotを許可する
GPTBotによるサイト全体のクロールを明示的に許可する場合は、robots.txtに以下のように記述できます。
User-agent: GPTBot
Allow: /「Allow: /」は、指定したUser-agentに対してルート以下へのアクセスを許可する記述です。もともとGPTBotを拒否するルールがない場合は必ずしも追加する必要はありませんが、既存のrobots.txtに複数の制御ルールがあるサイトでは、管理方針を明確にするために記述する方法があります。OpenAIも、robots.txtによってGPTBotへの許可・拒否を管理できるとしています。
設定を変更するときは、既存のGPTBot向けルールと矛盾していないかも確認しましょう。robots.txtではUser-agentごとにルールがグループ化されるため、既存設定を確認したうえで追加・変更することが重要です。
AI学習を拒否してChatGPT検索は許可する
AIモデルの学習にはコンテンツを利用されたくないものの、ChatGPT検索からの引用や流入は確保したい場合は、GPTBotを拒否し、OAI-SearchBotを許可します。記述例は以下のとおりです。
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /この設定では、学習目的と検索目的のアクセスを別々に制御できます。
そのため、両者を分けて設定すれば「AI学習は拒否するが、ChatGPT検索には表示される可能性を残す」という運用が可能です。検索経由の引用・流入を重視する場合は、この設定を確認しておきましょう。
特定のページ・ディレクトリだけ拒否する
サイト全体ではなく、一部のコンテンツだけAIクローラーに取得されたくない場合は、Disallowに対象となるURLパスを指定し、たとえば「/members/」以下をクロールさせない場合は以下のように記述します。
User-agent: GPTBot
Disallow: /members/この設定では「/members/」配下がGPTBotのクロール対象外となり、それ以外の許可されているページにはアクセスできます。robots.txtのDisallowでは、サイトのルートを基準にURLパスを指定できるため、コンテンツの性質に応じた部分的な制御が可能です。
ただし、robots.txtはアクセス制御や認証の仕組みではありません。会員限定ページや機密情報など、第三者に取得されてはいけない情報はrobots.txtだけに頼らず、認証など適切な保護策を講じることが重要です。
複数のAIクローラー・制御トークンを個別に設定する
複数のAIクローラーや生成AI向け制御トークンを制御したい場合は、対象となるUser-agentトークンごとにルールを記述します。サイト全体で拒否する場合は、以下のような形式で設定できます。
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /すべてのクローラーを「User-agent: *」でまとめて拒否すると、通常の検索エンジンなど意図していないクローラーまで対象になる可能性があります。そのため、AI関連のアクセスだけを制御したい場合は、対象となるUser-agentを確認して個別に指定する方法が適しています。robots.txtでは複数のUser-agentに対してそれぞれルールを設定できます。
また、AIサービスによって検索用と学習・生成AI用途の制御方法は異なります。生成AI向けの制御トークンの中には、独立したHTTPリクエスト用User-agentとしてクロールするのではなく、既存のクローラーが取得したコンテンツの利用範囲を制御するものもあります。検索への掲載可否とは役割が異なるため、各提供元の公式情報を確認して対象を選定しましょう。
GPTBot・AIクローラーを拒否するとSEOやAI検索に影響する？
GPTBotを拒否しただけで、Google検索の順位が直接下がるわけではありません。GPTBotはOpenAIのモデル改善・学習に利用される可能性のあるコンテンツを収集するクローラーであり、Googlebotとは別に制御されます。そのため、GPTBotのみを拒否しても、Googlebotのクロールを許可していれば通常のGoogle検索への影響は基本的にありません。
一方、AI検索への露出は、どのクローラーを拒否するかによって変わります。ChatGPT検索でコンテンツを発見・引用されやすい状態を維持するには、OAI-SearchBotをブロックしないことが重要です。AI学習だけを避けたい場合はGPTBotを拒否し、OAI-SearchBotは許可するなど、目的ごとに設定を分ける必要があります。
robots.txtだけではAIクローラーを完全に遮断できない
robots.txtは、クローラーに対して「このページにはアクセスしないでほしい」と伝えるための仕組みであり、アクセス自体を技術的に禁止するものではありません。Robots Exclusion Protocolの仕様でも、robots.txtのルールはアクセス認証ではないと明記されています。そのため、ルールを遵守しないクローラーや、User-agentを偽装してアクセスするボットまで完全に防げるわけではありません。
AIクローラーからコンテンツを確実に保護したい場合は、robots.txtだけに依存せず、WAFやCDNなどによるアクセス制御を組み合わせることが重要です。サーバーログなどで実際のアクセス状況も確認し、robots.txtで示した方針どおりに制御できているか継続的に検証しましょう。
WAF・CDNでAIクローラーを制御する方法
WAF・CDNを活用すると、robots.txtだけでは対応しきれないAIクローラーのアクセスをより細かく制御できます。意図したアクセス方針を実現するには、実際のアクセス状況と各セキュリティ設定をあわせて確認することが重要です。ここでは、WAF・CDNを使ってAIクローラーを確認・制御する方法について解説します。
AIクローラーのアクセス状況を確認する
WAF・CDNの管理画面やアクセスログでは、どのAIクローラーが自社サイトへアクセスしているかを確認できる場合があります。期間・User-agent・ホスト名・パスなどで絞り込み、アクセス数や対象ページを確認すると、クローラーごとの利用状況を把握しやすくなります。
アクセス数だけでなく、どのページに集中しているかまで確認すると、学習用・検索用など用途を踏まえた制御方針を検討する際の判断材料にできます。
特定のAIクローラーを許可・拒否する
AIクローラーへのアクセス制御は、すべてを一律に遮断するのではなく、自社の方針に合わせて対象を選ぶことが重要です。WAF・CDNでは、User-agentやIPアドレス、アクセス先のパスなどを条件に、特定のAIクローラーを許可・拒否できる場合があります。学習用・検索用など用途ごとにルールを分け、必要に応じてカスタムルールを設定しましょう。
たとえば、AIモデルの学習を避けたい一方でAI検索からの流入を確保したい場合は、学習目的のクローラーを遮断し、検索目的のクローラーは許可するといった使い分けが考えられます。より細かな条件が必要な場合は、WAFのカスタムルールを利用して対象やパスなどを指定できます。
robots.txtで許可していてもWAF・CDNで遮断されていないか確認する
robots.txtで許可していても、WAF・CDNやボット対策で別の遮断ルールが設定されていると、リクエストが途中でブロックされる場合があります。
AI検索への露出を確保したい場合は、robots.txtだけでなく、WAF・CDN・ボット対策の設定も確認し、検索目的のクローラーを意図せず遮断していないか点検しましょう。
AIクローラーの設定後に確認するポイント
AIクローラーの設定は、記述しただけで完了ではありません。robots.txtの配置や実際のアクセス状況、WAF・CDNでのレスポンスまで確認し、意図したとおりに許可・拒否できているか検証することが重要です。ここでは、AIクローラーの設定後に確認したいポイントについて解説します。
robots.txtが正しい場所に設置されているか確認する
AIクローラー向けのルールを記述したら、まずrobots.txtが正しい場所に設置され、外部から取得できる状態になっているか確認します。robots.txtは対象となるサイトのルートへの配置が必要です。たとえば「https://example.com/」を対象にする場合は、「https://example.com/robots.txt」が設置場所となります。サブディレクトリに配置しても、サイト全体に対するルールとしては機能しません。
また、robots.txtのルールは配置されたプロトコル・ホスト・ポートに対して適用されます。そのため、サブドメインを運用している場合などは、それぞれの環境でrobots.txtを確認することが重要です。ブラウザから直接アクセスし、意図した内容が表示されるか、User-agentやDisallowなどの記述に誤りがないかまで確認しましょう。
サーバーログでUser-agent別のアクセスを確認する
robots.txtを設定しただけでは、実際にAIクローラーがどのようにアクセスしているかまでは判断できません。設定後はサーバーのアクセスログを確認し、GPTBot・OAI-SearchBot・ClaudeBotなどのUser-agentから、どのURLへリクエストが発生しているかを調べます。主要なAI事業者は用途ごとに異なるUser-agentを使用しているため、個別に確認することが重要です。
拒否したクローラーから継続的にアクセスが発生している場合は、robots.txtが取得されているか、対象パスの指定が正しいかを確認します。ただし、User-agentは送信側が自由に名乗れるため、ログ上の名称だけで正規のAIクローラーと断定しないことも大切です。
WAF・CDNのログやHTTPステータスを確認する
WAFやCDNを利用している場合は、AIクローラーへのレスポンスも確認します。robots.txtでアクセスを許可していても、WAFのカスタムルールやボット対策などによってリクエストが遮断されている可能性があるためです。アクセスログでは、AIクローラーごとのリクエスト数や2xx・3xx・4xx・5xxといったHTTPステータスを確認し、意図した制御になっているかを検証しましょう。
許可したクローラーに2xxが返っているか、拒否対象に403など意図したレスポンスが返っているかを確認します。特に「AI学習は拒否し、AI検索は許可する」といった設定では、用途の異なるクローラーを分けてログを見ることが重要です。想定外の4xxや5xxが多い場合は、robots.txtだけでなくWAF・CDNやオリジンサーバー側の設定も確認します。
公式IPレンジなどを使って正規クローラーか確認する
アクセスログに特定のUser-agent名が記録されていても、それだけで正規のクローラーとは判断できません。User-agentは第三者が偽装できるため、厳密に識別したい場合は、提供元が案内する確認方法に従い、公開IPレンジやUser-agentなど利用可能な情報を組み合わせて確認します。
公開されているIPレンジは更新される可能性があります。固定値を長期間使い続けず、提供元の最新情報を参照して確認しましょう。
AIクローラーを許可・拒否する判断基準
AIクローラーを許可するか拒否するかは、AI検索からの流入、AIモデルの学習利用、コンテンツ保護のどこを優先するかで判断が変わるため、事前に優先順位を整理することが大切です。
ここでは、AI検索への露出、学習利用、コンテンツ保護、遮断の確実性という4つの観点から判断基準について解説します。
AI検索からの引用・流入を狙うか
AI検索を新たな流入経路として活用したい場合は、検索・回答生成に使われるクローラーを安易に拒否しないことが重要です。たとえばOpenAIは、ChatGPTの検索結果でコンテンツを発見・表示し、出典やリンクを示しやすくするには、OAI-SearchBotをブロックしないよう案内しています。ChatGPTからの参照URLにはUTMパラメータも付与されるため、アクセス解析で流入状況を確認できます。
そのため、AI経由での認知拡大やサイト流入を期待する場合は、検索・回答生成用クローラーへのアクセスを許可する方向で検討します。一方、AI検索への露出を重視しないサイトでは、コンテンツ保護やサーバー負荷などを優先して制限する選択肢もあります。
AIモデルの学習を許可するか
AI検索への掲載とAIモデルの学習は、分けて判断することが重要です。検索経由の露出を残しながら学習目的の利用だけを制限できる場合もあるため、各クローラーの用途を確認して設定します。
サービスごとに制御方法は異なるため、利用目的まで確認したうえで判断しましょう。GoogleでもGoogle-Extendedを使ってGemini関連の学習などへの利用を管理でき、この設定はGoogle検索への掲載やランキングシグナルには影響しないと案内されています。
有料・機密・独自性の高いコンテンツを保護する必要があるか
会員限定記事や有料コンテンツ、社内向け資料など、第三者に取得されたくない情報を扱う場合は、AIクローラーへの公開範囲を慎重に判断する必要があります。特に、独自調査や専門データなど事業上の価値が高いコンテンツでは、AIへの露出によるメリットと、情報が外部から取得されるリスクを比較して方針を決めることが重要です。
ただし、本来非公開にすべき機密情報の保護をrobots.txtだけに頼るのは適切ではありません。robots.txtはクローラーへの指示であり、技術的にアクセスそのものを防ぐ仕組みではないためです。確実に非公開とする必要がある情報は、認証やアクセス制御などを用いて、そもそも外部から取得できない状態にする必要があります。
技術的に確実な遮断が必要か
AIクローラーをどの程度確実に遮断したいかも、制御方法を決める重要な判断基準です。まずは、アクセス方針を示せればよいのか、アクセス自体を防ぐ必要があるのかを整理しておきましょう。
アクセス自体を防ぐ必要がある場合は、技術的なアクセス制御を組み合わせ、ログで意図したとおりに遮断できているか確認します。
AIクローラーは用途を理解して目的に合わせて制御しよう
AIクローラーは、AIモデルの学習用、AI検索・回答生成用、ユーザー操作を起点としたアクセスなど、目的によって役割が異なります。そのため、すべてを一律に許可・拒否するのではなく、自社がAIにどのようにコンテンツを利用してほしいのかを整理したうえで設定することが重要です。
AI学習を避けながらAI検索からの引用や流入を確保したい場合は、用途別のクローラーを分けて制御します。また、robots.txtだけでは確実に遮断できないため、必要に応じてWAFやCDNを組み合わせ、設定後はログやHTTPステータスも確認してください。自社のコンテンツ保護とAI経由の露出機会のバランスを考え、目的に合ったAIクローラー制御を進めましょう。
都道府県別のLLMO対策会社を探す
関東
