生成AIを使った検索や回答サービスが広がり、企業サイトには検索エンジンのクローラーに加えて、AI事業者のクローラーも訪れるようになりました。BtoB企業のマーケティングやDX推進の担当者の中には、「AIクローラーは許可すべきか、拒否すべきか」「何から手を付ければよいのか」と迷っている方も少なくないでしょう。
AIクローラー 対策は、すべて拒否するか、すべて許可するかの二択ではありません。自社サイトのコンテンツの役割と事業方針に合わせて、クローラーごと、ディレクトリごとに方針を決めるのが現実的です。この記事では、BtoBサイトで許可・拒否を判断するための基準と、robots.txt、構造化データ、クロール可能性の整備手順を順に解説します。
AIクローラーとは？検索エンジンのクローラーとの違い
AIクローラーとは、生成AIサービスを提供する事業者が、Webページの情報を自動で取得するために使うプログラムです。従来の検索エンジンのクローラーは、検索結果に表示するためにページを収集・索引化してきました。AIクローラーは、それに加えてAIモデルの学習や、AIによる回答の根拠となる情報の取得にも使われる点が異なります。
AIクローラーの主な用途は3種類
AIクローラーは、目的によって大きく次の3種類に分けて考えると判断しやすくなります。
- 学習用：AIモデルの学習データとしてWebページを収集する
- 検索・引用用：AI検索やAIによる回答で、情報源として参照・引用するためにページを取得する
- ユーザー操作に応じた取得：利用者がAIサービス上でURLを指定したり質問したりしたときに、その場でページを読み込む
この区別が重要なのは、「学習には使われたくないが、AI検索で自社の情報が正しく引用されるのは歓迎したい」といった、目的ごとの方針設定ができるからです。
代表的なAIクローラーのユーザーエージェント
クローラーは、ユーザーエージェントと呼ばれる名前でアクセス元を名乗ります。robots.txtではこの名前を指定して制御します。代表的なものには次のような名前があります。
- OpenAI：GPTBot（学習用）、OAI-SearchBot（検索用）、ChatGPT-User（ユーザー操作に応じた取得）
- Anthropic：ClaudeBot（学習用）、Claude-SearchBot（検索用）、Claude-User（ユーザー操作に応じた取得）
- Google：Google-Extended（Geminiなどの生成AIでの利用を制御するための名前）
- Perplexity：PerplexityBot（検索用）
- Common Crawl：CCBot（公開データセットの収集用）
ユーザーエージェントの名前や用途は、各事業者の判断で追加・変更されることがあります。設定前には、各事業者が公開している最新のドキュメントを確認してください。
AIクローラーの仕組みと、robots.txtでできること・できないこと
AIクローラーの多くは、サイトにアクセスすると最初にrobots.txtを読み込み、そこに書かれたルールに従って取得してよいページを判断します。robots.txtは、サイトのルートに置くテキストファイルで、「どのクローラーに、どのパスへのアクセスを許可・拒否するか」を記述します。
ただし、robots.txtには次のような限界があります。
- 強制力はない：robots.txtはクローラーへの「お願い」であり、ルールを守らないクローラーのアクセスを技術的に止めるものではありません
- 過去の取得分には及ばない：設定は今後のクロールに対するもので、すでに取得されたデータの扱いは各事業者の方針によります
- ユーザー操作に応じた取得は扱いが異なる場合がある：利用者の指示で読み込むエージェントについては、robots.txtの扱いが事業者ごとに異なることがあります
確実にアクセスを止めたい情報は、robots.txtだけに頼らず、ログイン認証やWAF・CDNのボット対策機能などで保護する必要があります。逆に言えば、公開して広く知ってもらいたい情報については、robots.txtで意図せず拒否していないかを確認することが対策の第一歩になります。
BtoBサイトでAIクローラーを許可するか拒否するかの判断基準
BtoBサイトには、サービス紹介や会社概要のように「広く知ってもらいたい情報」と、有料資料や会員向けコンテンツのように「それ自体が価値を持つ情報」が混在しています。次の4つの観点で整理すると、方針を決めやすくなります。
判断基準1：コンテンツの性質
まず、そのコンテンツが「集客のための情報」なのか「商品そのもの」なのかを見極めます。サービスの特徴、導入の流れ、よくある質問、会社情報などは、AIを通じて見込み顧客に届けば集客につながる可能性があります。一方、独自の調査レポートやノウハウ資料、ダウンロード資料のように、情報そのものが営業上の価値を持つものは、学習利用を拒否する選択肢を検討する余地があります。
判断基準2：AI経由で見つけてもらう価値
見込み顧客が、課題の調査やサービス比較の段階でAI検索やAIアシスタントを使う場面は増えています。検索・引用用のクローラーを拒否すると、AIの回答で自社の情報が参照されにくくなったり、古い情報や第三者の情報をもとに自社が説明されたりする可能性があります。自社の正確な情報をAIに参照してもらうことを重視するなら、検索・引用用のクローラーは許可するのが基本的な考え方です。
判断基準3：学習利用への方針と権利関係
自社コンテンツをAIモデルの学習に使われることをどう考えるかは、企業ごとの方針によって分かれます。また、取引先から提供を受けた資料や、外部の執筆者・制作会社の著作物、利用許諾の範囲が限られた写真や図版などを掲載している場合は、権利関係の観点からも判断が必要です。法務部門や知的財産の担当者と、学習利用への方針をすり合わせておきましょう。
判断基準4：サーバー負荷と運用体制
クローラーのアクセスが集中すると、サーバーに負荷がかかることがあります。アクセスログを見て、特定のクローラーのアクセスがサイトの表示速度や安定性に影響していないかを確認します。また、robots.txtのルールは一度決めて終わりではなく、新しいクローラーの登場や事業方針の変化に合わせて見直す必要があります。誰が管理し、どの頻度で見直すかという運用体制も判断材料に含めましょう。
BtoBサイトでよく取られる方針パターン
4つの観点を踏まえると、方針はおおむね次のパターンに整理できます。
- 全面許可：AIでの露出を最大化したい場合。公開情報の大半が集客目的で、学習利用にも抵抗がないときに選ばれます
- 検索・引用は許可し、学習は拒否：AI検索での引用は歓迎しつつ、学習データとしての利用は控えたい場合。BtoBサイトでは検討しやすい中間的な方針です
- ディレクトリ単位で制御：サービスページやコラムは許可し、資料ダウンロードや会員向け領域など特定のディレクトリだけを拒否する方法です
- 全面拒否：サイト全体の情報を守る必要がある場合。ただし、AI経由で見つけてもらう機会も失う点に注意が必要です
実務では、パターン2とパターン3を組み合わせるケースが扱いやすいでしょう。
AIクローラー対策の整備手順
ここからは、方針の決定から実装、検証までを7つのステップで解説します。
ステップ1：現状を把握する
最初に、現在の設定とアクセス状況を確認します。
- 現在のrobots.txtの内容（ブラウザで「サイトのURL/robots.txt」を開くと確認できます）
- サーバーやCDNのアクセスログに、どのAIクローラーがどの程度アクセスしているか
- WAFやCDNのボット対策機能が、AIクローラーを意図せずブロックしていないか
- CMSやプラグインが、robots.txtを自動生成・上書きしていないか
特にWAFやCDNのボット対策は、管理者が意識しないうちにAIクローラーを遮断していることがあります。robots.txtだけを見て判断しないようにしましょう。
ステップ2：コンテンツを棚卸しして分類する
サイト内のコンテンツをディレクトリ単位で一覧にし、「広く知ってもらいたい情報」「学習には使われたくない情報」「公開範囲を限定すべき情報」に分類します。URLの構造が整理されていないと、robots.txtでディレクトリ単位の制御がしにくくなるため、必要に応じてURL設計の見直しも検討します。
ステップ3：方針を決めて社内で合意する
分類結果と前述の判断基準をもとに、クローラーの種類ごと、ディレクトリごとの方針を決めます。マーケティング部門だけで決めず、法務部門、情報システム部門、コンテンツ制作の担当者を交えて合意しておくと、後から方針が覆るリスクを減らせます。決めた方針と理由は文書に残しておきましょう。
ステップ4：robots.txtを設定する
方針が決まったら、robots.txtに記述します。たとえば「検索・引用は許可し、学習は拒否」する場合は、次のように書きます。
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: *
Allow: /
Sitemap: https://www.example.com/sitemap.xml
特定のディレクトリだけを学習用クローラーから除外したい場合は、次のように書きます。
User-agent: GPTBot
Disallow: /download/
Disallow: /members/
設定時の注意点は次のとおりです。
- クローラーは、自分の名前が書かれたグループがあればそのルールに従い、「User-agent: *」のルールは適用されません。個別に指定したグループには、必要なルールをすべて書きましょう
- 「Disallow: /」をすべてのクローラー向けに書くと、検索エンジンのクローラーも拒否してしまいます。記述ミスは検索流入に直接影響するため、公開前に必ず確認します
- サンプルのドメインやディレクトリ名は、自社サイトの実際の構成に置き換えてください
ステップ5：構造化データを整備する
構造化データとは、ページの内容を検索エンジンやAIが理解しやすい形式で記述したデータです。schema.orgの語彙を使い、Googleが推奨するJSON-LD形式で記述するのが一般的です。BtoBサイトでは、次の種類から整備を始めると効果的です。
- Organization：会社名、ロゴ、所在地、問い合わせ先、公式SNSなど、企業の基本情報
- WebSite：サイト名やサイトのURL
- BreadcrumbList：パンくずリストによるサイト内の階層構造
- Article：コラム記事のタイトル、著者、公開日、更新日
- Service：提供しているサービスの名称や概要
- FAQPage：よくある質問とその回答
構造化データの内容は、ページに表示されている内容と一致させる必要があります。表示されていない情報を構造化データだけに書くことは避けましょう。実装後は、GoogleのリッチリザルトテストやSchema Markup Validatorで記述エラーがないかを確認します。なお、構造化データはAIによる引用や表示を保証するものではありません。あくまで、情報を正しく理解してもらうための土台として整備します。
ステップ6：クロール可能性を整える
AIクローラーを許可しても、ページの情報を取得できなければ意味がありません。クローラーが情報を読み取れる状態になっているかを、次の観点で点検します。
- 重要な情報がHTMLに含まれているか：JavaScriptを実行しない、または実行が限定的なクローラーもあるため、サービス内容や会社情報などの重要な情報は、HTMLに直接記述しておくのが安全です
- 情報がPDFや画像だけに載っていないか：サービスの特徴や料金体系がPDF資料や画像内の文字だけで説明されていると、正しく読み取られない可能性があります。要点はHTMLのテキストでも記載しましょう
- XMLサイトマップが最新か：公開中のページが漏れなく含まれ、削除済みのページが残っていないかを確認し、robots.txtにサイトマップの場所を記載します
- canonicalとnoindexの設定が正しいか：意図しないページにnoindexが付いていないか、正規URLの指定が正しいかを確認します
- ステータスコードが適切か：存在しないページが正しく404を返しているか、リダイレクトが連鎖していないかを確認します
- 内部リンクと見出し構造が整理されているか：重要なページへ内部リンクでたどれること、見出しが内容を正しく表していることは、検索エンジンにもAIにも共通して重要です
- 表示速度やサーバーの応答が安定しているか：応答が遅い、またはエラーが多いと、クロールが十分に行われない原因になります
ステップ7：検証し、定期的に見直す
設定を反映したら、robots.txtが意図どおりに公開されているかをブラウザで確認し、Google Search Consoleのrobots.txtレポートで検索エンジン向けの読み込み状況もチェックします。その後は、アクセスログで各クローラーのアクセス状況が方針どおりに変化しているかを確認します。
AIクローラーは今後も新しいものが登場し、各事業者の仕様も変わっていきます。四半期ごとなど、見直しのタイミングをあらかじめ決めておき、ユーザーエージェントの一覧や社内の方針を更新していきましょう。
よくある失敗と注意点
AIクローラー 対策で起こりやすい失敗には、次のようなものがあります。
- 検索エンジンまで拒否してしまう：「User-agent: *」に「Disallow: /」を書いてしまい、Googleなどの検索エンジンからも見えなくなるケースです
- 学習用と検索用を区別せずに拒否する：学習だけを避けたかったのに、検索・引用用のクローラーまで拒否してしまい、AI検索で自社情報が参照されにくくなります
- robots.txtだけで機密情報を守ろうとする：robots.txtには強制力がないため、公開すべきでない情報は認証などで保護する必要があります。また、robots.txtに秘匿したいディレクトリ名を書くと、かえってその存在を知らせることにもなります
- CMSの更新で設定が上書きされる：プラグインやCMSの設定変更で、robots.txtが自動的に書き換わることがあります。更新後は内容を確認しましょう
- 設定して終わりにする：新しいクローラーへの対応が漏れ、方針と実態がずれていくことがあります
よくある質問
Q. robots.txtで拒否すれば、AIに一切使われなくなりますか？
いいえ。robots.txtはルールを守るクローラーに対して効果がある仕組みで、強制力はありません。また、すでに取得されたデータや、第三者のサイトに転載された情報には設定が及びません。確実に守りたい情報は、認証などで公開範囲そのものを制限してください。
Q. Google-Extendedを拒否すると、Google検索の順位に影響しますか？
Googleは、Google-Extendedの設定はGoogle検索への掲載や順位には影響しないと説明しています。Google検索のクロールはGooglebotが担っているため、Googlebotを拒否しない限り、通常の検索には影響しない仕組みです。最新の仕様はGoogleの公式ドキュメントで確認してください。
Q. llms.txtは設置すべきですか？
llms.txtは、AI向けにサイトの概要や重要なページを案内するためのテキストファイルとして提案されている仕組みです。robots.txtのようにアクセスを制御するものではなく、広く標準化された仕様でもありません。まずはrobots.txt、構造化データ、クロール可能性の整備を優先し、llms.txtは余力があれば補助的に検討するとよいでしょう。
まとめ
AIクローラー 対策は、「許可か拒否か」を一律に決めるのではなく、コンテンツの性質、AI経由で見つけてもらう価値、学習利用への方針、運用体制の4つの観点から、クローラーの種類とディレクトリごとに方針を決めることが重要です。
- AIクローラーは「学習用」「検索・引用用」「ユーザー操作に応じた取得」に分けて考える
- BtoBサイトでは「検索・引用は許可し、学習は拒否」や「ディレクトリ単位の制御」が検討しやすい
- robots.txtには強制力がないため、守るべき情報は認証などで保護する
- 許可するだけでなく、構造化データとクロール可能性を整えて、正しく読み取れる状態にする
- 新しいクローラーや仕様の変化に合わせて、定期的に見直す
AI検索が情報収集の手段として広がる中、自社の情報を正しく届けるための土台づくりは、マーケティング施策の一部として取り組む価値があります。
無料マーケティング診断のご案内
ハイ・ヴァーチュ・ラボは、AI駆動開発・システムインテグレーション・マーケティングを一気通貫で提供するテクノロジーパートナーです。プロジェクトの立ち上げから収益化まで、すべての工程を網羅しています。
「自社サイトのrobots.txtやWAFの設定がAIクローラーにどう影響しているか分からない」「構造化データやサイト構造をどこから見直せばよいか判断できない」といったお悩みがあれば、無料マーケティング診断をご利用ください。現状を整理し、自社に合ったAIクローラー対策の進め方を一緒に検討します。