AIクローラーの拒否設定｜学習用と検索用のボットを分ける手順

「うちのサイトの記事が、勝手にAIの学習に使われているのでは」と気になって、AIクローラーの拒否設定を調べている方が増えています。この記事では、robots.txtでAIクローラーを拒否する具体的な手順と、拒否してはいけないボットの見分け方を、コピペで使える記述例つきで解説します。

対象は、自社サイトを運営していて、サーバーのファイルを1つ触るくらいならできる中小企業の経営者・広報・Web担当の方です。読み終わる頃には、自社が「止めるべきボット」と「止めてはいけないボット」を自分で仕分けでき、robots.txtに書く内容を決められる状態を目指します。

なお、この記事はAIクローラーの制御に絞ります。AI検索に引用されるための記事の作り方そのものはGEO対策のやり方を7手順で解説した記事にまとめているので、「そもそも止めるより載せたい」という方は先にそちらを読んでください。

Contents / 目次

1. 結論。AIクローラーは3系統に分けて、学習用だけ止める
2. robots.txtでAIクローラーを拒否する手順
3. Google検索を止めるとAI概要にも出なくなる。ここを混同しない
4. robots.txtだけでは止まらない。守らないボットへの対策
5. 拒否設定で実際に何が変わるのか
6. AIクローラー対策でやりがちな失敗4つ
7. 設定してから気づく、運用側の面倒ごと
8. AIクローラーの拒否設定でよくある質問
9. まず今日やる一歩

結論。AIクローラーは3系統に分けて、学習用だけ止める

AIクローラーの拒否設定でまずやるべきことは、全部まとめて止めることではありません。「学習用」「AI検索用」「ユーザー操作用」の3系統に分け、原則として学習用だけを止めることです。ここを分けずに一括で拒否すると、AI検索からの流入まで自分で切ってしまいます。

AIクローラーとは、生成AIを提供する会社がWebサイトを自動で巡回し、ページの本文を読み取っていくプログラムのことです。人間がブラウザで見に来るのと同じ経路でアクセスしますが、名乗る名前（User-agent）が違うので、その名前を見て通す・通さないを決められます。

3系統の違いを整理すると、次のようになります。表に挙げたUser-agent名と目的、robots.txtに従うかどうかは、必ず提供元の公式ドキュメントで1つずつ確認してください（OpenAIのクローラー一覧、Googleのクローラー一覧、AppleのApplebot解説、Anthropicのサポート情報、Common CrawlのCCBot解説、PerplexityのBot解説）。

系統	何のために来るか	止めると何が起きるか	代表的なUser-agentの例
学習用	AIモデルを鍛えるための文章データの収集	今後の学習に自社の文章が使われにくくなる。検索順位やAI回答への掲載は原則そのまま	GPTBot、ClaudeBot、CCBot、Google-Extended、Applebot-Extended
AI検索用	AIが回答を作るときに示す出典・引用元の収集	AIの回答で出典として扱われる機会が減り、そこからの流入も減ります	OAI-SearchBot、PerplexityBot
ユーザー操作用	利用者がURLを貼ったときなどに、その場で1ページ読みに来る	見込み客がAIに自社ページを読ませようとしても読めない	ChatGPT-User

User-agentの名前と目的の分類は各社が随時追加・変更します。この表は書き始めるときの目安として使い、実際に書く前に必ず提供元の公式ドキュメントで現在の一覧と目的を1つずつ確認してください。

AIボットは目的で分かれている、という前提を押さえる

「AIのボット」とひとくくりにしないという考え方は、インフラ側の解説でも共通しています。AWS WAF で AI ボットを管理し、セキュリティを強化する方法（Amazon Web Services ブログ）では、AIボットを次のように分類しています。

AIボットは「AIスクレイパー」（データ収集）、「AIツール」（関数呼び出し活用）、「AIエージェント」（自律的操作）の3種類に分類されます。

呼び方は違いますが、言っていることは同じです。データを集めに来るボットと、利用者の役に立つために来るボットは別物なので、扱いも分けるべきだということです。

自社が「止める側」か「載せたい側」かを先に決める

判断はサイトの性質で決まります。次の3タイプのどれに近いかで、やることが変わります。

• コンテンツ自体が商品のサイト：有料級のノウハウ記事、写真・イラスト素材、レシピ、調査データなどを扱う場合。学習用は止める価値があります。AI検索用も止めるかは、流入を捨てられるかで判断します。
• 集客が目的のサイト：BtoBのコーポレートサイト、サービスサイト、店舗サイトなど。AI検索用とユーザー操作用は必ず許可のままにします。学習用だけ、方針として止めるかを決めます。
• 負荷が問題になっているサイト：アクセスログがボットで埋まり、表示が重い場合。この場合は「拒否」より「頻度の制御」や、後述するサーバー・CDN側での対処が本筋です。

ポイント。中小企業のコーポレートサイトの多くは2番目です。学習用を止めるのは経営判断として理解できますが、AI検索用まで止めると、これから増える流入経路を自分で閉じることになります。

robots.txtでAIクローラーを拒否する手順

ここからは実際の作業です。robots.txtとは、サイトの入口に置いて「このプログラムはここを読まないでください」と伝えるためのテキストファイルのことです。お店の入口に貼る「関係者以外お断り」の紙に近く、読んで従うかどうかは相手次第という性質があります。

ステップ1。今のrobots.txtの中身を確認する

いきなり新しいファイルを作らず、まず今の状態を見ます。ブラウザで自社ドメインの末尾に /robots.txt を付けてアクセスするか、ターミナルで次を実行してください。

# 今の robots.txt をそのまま表示する
# example.com は自社ドメインに置き換える
curl -s https://example.com/robots.txt

ここで出てきた内容は、あとで必ず残します。表示された内容をメモ帳にコピーしておいてください。

ステップ2。止めるボットの一覧を公式ドキュメントで確認する

User-agentの表記は1文字でも違うと効きません。書く前に、止めたい会社の公式ドキュメントで現在の表記を確認します。確認するのは主に次の4点です。

1. そのボットの正確なUser-agent名（大文字小文字、ハイフンの有無まで）
2. そのボットの目的（学習なのか、AI検索の出典収集なのか、利用者の操作に応じた取得なのか）
3. robots.txtの指示に従うと明記されているか
4. 同じ会社が他にどんなボットを出しているか

OpenAIやAnthropicなど主要な提供元は、自社のクローラー一覧と目的を公開しています。数が多くて追いきれないと感じたら、まずは表に挙げた学習用の代表格だけに絞って構いません。全部を網羅しようとして手が止まるより、主要な数個を今日書くほうが実利があります。

ステップ3。学習用だけを拒否する記述を書く

次が実際の記述例です。書いていないボットは「許可」の扱いになるので、AI検索用とユーザー操作用はあえて書きません。

# robots.txt（サイトのルートに設置）
# 学習用クローラーだけを止める例
# User-agent 名は各社の公式ドキュメントで最新を確認する

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# ここから下はステップ1で控えた既存の内容。消さずに残す
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

ブロックとブロックの間は1行空けます。Disallow: / はサイト全体、Disallow: /blog/ のように書けばその配下だけを対象にできます。「記事だけ守って会社概要は読ませたい」という使い分けも可能です。

最後の Sitemap: の行を消してしまう事故がよく起きます。ステップ1で控えた内容は、必ずそのまま下に貼り付けてください。

ステップ4。ルート直下に設置する

ファイル名は全て小文字で robots.txt、置き場所はドキュメントルートの直下です。https://example.com/robots.txt で開ける位置でなければ意味がありません。/wp-content/ の中や、階層の深いフォルダに置いても効きません。

robots.txtはホスト単位で扱われます。www の有無で別のホストになる構成や、shop.example.com のようなサブドメイン、独自ドメインを当てたLPがある場合は、それぞれに設置が必要です。ここは見落としが多いところなので、自社にいくつホストがあるかを先に洗い出しておいてください。

ステップ5。設置後に動作を確認する

置いて終わりにせず、3つ確認します。

1. ブラウザで https://example.com/robots.txt を開き、書いた内容がそのまま表示されるか見る（キャッシュが残っている場合は時間を置く）
2. Google Search Consoleのrobots.txtの状態を確認し、取得できているかとエラーが出ていないかを見る
3. サーバーのアクセスログで、対象ボットのアクセスが減っていくかを見る

ログの確認は次のようなコマンドで足ります。サーバーによってログの置き場所とファイル名が違うので、そこだけ自社の環境に合わせてください。

# アクセスログから GPTBot の件数を数える
# access_log のパスは自社サーバーの実際の場所に変更する
grep -ic "GPTBot" /home/ユーザー名/example.com/log/access_log

# 直近のログで、AI系ボットの内訳をまとめて見る
grep -ioE "GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot" access_log | sort | uniq -c | sort -rn

設置前の件数を控えておくと、あとで「効いたのか」を数字で言えます。ここを取らずに設定だけすると、社内で聞かれたときに答えられません。robots.txtの書式そのものをもう少し丁寧に知りたい方や、AI向けの案内ファイルを合わせて整えたい方は、llms.txtの書き方とWordPress設置手順を解説した記事も参考になります。

Google検索を止めるとAI概要にも出なくなる。ここを混同しない

Google関連は特に取り違えが多いので、単独で整理します。押さえるべきは、Googlebotを止めることと、Google-Extendedを止めることは全く別の話だという点です。

• Googlebot：Google検索のためのクローラー。これを拒否すると、Google検索そのものに載らなくなります。AI概要（AI Overviews）はGoogle検索の中の機能なので、検索に載らなくなれば当然そこにも出ません。
• Google-Extended：robots.txtで指定できる、生成AI向けの利用可否を示すための名前です。Google-Extendedを拒否した場合にGoogle検索の掲載や順位にどう影響するかは、Googleのクローラー一覧で現在の説明を確認してください。

つまり「AIに使われたくない」という理由で User-agent: * に Disallow: / と書いてしまうと、AIどころか検索そのものから消えます。これは実際に起きている事故です。

合わせて覚えておきたいのが、robots.txtで拒否したページには noindex の指定が効かないという性質です。読みに来ることを止めているので、ページの中に書いた「載せないでください」という指示も読まれません。この点はGoogle検索セントラルのnoindexによるインデックス登録のブロックでも明記されています。検索結果から消したいのか、クロールを止めたいのか、目的を分けて手段を選ぶ必要があります。

robots.txtだけでは止まらない。守らないボットへの対策

robots.txtは強制力のある技術ではありません。書いた指示に従うかどうかは、相手のボット次第です。名乗る名前を変えて回避しようとするアクセスも現実に存在します。だから「robots.txtに書いたから学習は止まった」とは言えません。ここを正直に理解したうえで、次の段を用意します。

.htaccessでアクセス自体を返さない

Apacheが動いているレンタルサーバーなら、.htaccessでUser-agentを見て遮断できます。robots.txtが「お願い」なのに対し、こちらは「ドアを開けない」対応です。

# .htaccess に追記（Apache 2.4 系）
# 作業前に必ず現在の .htaccess をダウンロードして保管する
# 書き間違えるとサイト全体が 500 エラーになるので注意
# mod_setenvif が無い環境では遮断も動かないよう、判定と遮断を同じ IfModule に入れる

<IfModule mod_setenvif.c>
SetEnvIfNoCase User-Agent "GPTBot" ai_bot
SetEnvIfNoCase User-Agent "ClaudeBot" ai_bot
SetEnvIfNoCase User-Agent "CCBot" ai_bot

  <IfModule mod_authz_core.c>
    <RequireAll>
      Require all granted
      Require not env ai_bot
    </RequireAll>
  </IfModule>
</IfModule>

この書き方は mod_setenvif と mod_authz_core が有効で、.htaccess の上書きが許可されている環境が前提です。各ディレクティブの意味は、Apache公式のRequireAllディレクティブの解説とmod_setenvifの解説で確認してください。レンタルサーバーでは .htaccess の一部の記述が使えないこともあるので、契約先の仕様も合わせて見ておくと安全です。この記述例が自社の環境で意図どおり動くかは、次の確認手順で必ず実測してください。

追記したら、必ず自分のサイトが普通に見えるかをブラウザで確認してください。そのうえで、次のコマンドで遮断できているかを試します。curl は、指定した名前を名乗ってページを取りに行くコマンドです。

# GPTBot を名乗ってアクセスし、返ってくるステータスを見る
curl -A "GPTBot" -I https://example.com/

# 通常のブラウザを名乗った場合と比べる（こちらは 200 が返るのが正しい）
curl -A "Mozilla/5.0" -I https://example.com/

前者で 403、後者で 200 が返れば、意図どおりに動いています。ここまで確認して初めて「設定した」と言えます。

サーバー会社やCDNの機能を使う

自分でファイルを触りたくない、あるいはボットの名前を追い続けるのが現実的でない場合は、契約中のサービス側に用意があるかを確認するのが早道です。

• レンタルサーバー・ブログサービス：管理画面からAIクローラーを制限できるかどうかは、契約中のサービスの公式ヘルプやお知らせで確認してください。対象になるボットの一覧まで公開されているかも合わせて見ます。
• CDN・WAF：ボットの種類を見分けて可視化・遮断できるかどうかは、利用するサービスの公式ドキュメントで確認してください。対応の有無、既定の挙動、課金の扱いは変わることがあるので、契約前に現在の仕様を見てください。

使い分けの目安。意思表示だけで十分ならrobots.txt、実際に遮断したいなら.htaccessかサーバー機能、負荷やなりすましまで対処したいならCDN・WAFという順で検討すると迷いません。

拒否設定で実際に何が変わるのか

効果は「AIに学習されなくなる」という曖昧な話ではなく、自分で測れる形にしておくと社内でも説明しやすくなります。設定後に変化として観測できるのは、主に次の3つです。

• アクセスログ上のボット比率：対象ボットのリクエスト件数が変化します。設定前後の件数を比べれば、そのまま報告資料になります。
• 転送量とサーバー負荷：変化の大きさは、そのボットがもともとどれだけ巡回していたかで決まります。ほとんど来ていなかったサイトでは、止めても数字は動きません。
• AI検索からの流入：止め方を誤った場合はここが減ります。逆に言えば、学習用だけを止めた場合はほぼ動かないはずです。動いてしまったら、止めるボットを間違えています。

AI検索からの流入は、通常のアクセス解析だと参照元がまとまってしまい、変化に気づきにくいところです。設定を変える前に測れる状態にしておくのが安全です。計測の作り方はGA4でChatGPT流入を可視化する手順と、Search ConsoleでAI検索の表示回数を確認する手順にまとめています。

うまく運用している会社に共通していること

この設定を落ち着いて運用できている会社には、共通点があります。「全部止める・全部許す」ではなく、ディレクトリ単位で線を引いていることです。

たとえば、サービス紹介・会社概要・導入事例は全て許可のまま残し、有料級のノウハウをまとめた記事だけを学習用から外す。あるいは、会員向けのページ配下だけを対象にする。こうすると、AI検索で見つけてもらう機会は残したまま、守りたい資産だけを守れます。

もうひとつは、設定した日付と理由を社内に書き残していることです。半年後に「なぜこのボットを止めたのか」が誰も説明できないと、担当が代わった瞬間に触れないファイルになります。robots.txtの中にコメント行（# から始まる行）で日付と判断理由を書いておくだけで十分です。

AIクローラー対策でやりがちな失敗4つ

ここからは、設定後に問題になりやすい失敗です。どれも設定した本人には気づきにくく、しばらく経ってから気づくのが厄介なところです。

失敗1。一括拒否でGooglebotまで止めてしまう

「AIに読ませたくない」と焦って、User-agent: * に Disallow: / と書いてしまうケースです。この記述は「全てのボットに全ページを読ませない」という意味なので、GooglebotもBingbotも対象になります。

結果として、時間の経過とともに検索結果から自社ページが消えていきます。しかもrobots.txtで止めているため、ページの中に何を書いても伝わらず、復旧にも時間がかかります。

防ぎ方はシンプルで、User-agent: には必ず具体的なボット名を書き、* の行には既存の記述以外を足さないことです。設置後にSearch ConsoleのURL検査で主要ページを1つ調べ、クロールがブロックされていないかを確認してください。

失敗2。学習用とAI検索用を「AIだから」でまとめて止める

これが一番もったいない失敗です。GPTBotを止めるついでに、AI検索の出典を集めるボットや、利用者がURLを貼ったときに読みに来るボットまで拒否してしまうパターンです。

起きるのは、AIの回答に自社が出てこなくなることです。とくに商談中に相手が「この会社どう？」とAIに聞いたときや、送ったURLをAIに要約させようとしたときに読めない状態になります。せっかく資料を送っても中身が伝わらない、という損の出方をします。

防ぎ方は、拒否リストに入れる前に必ず1つずつ目的を確認することです。名前に「Search」や「User」が入っているものは、学習用ではない可能性が高いので特に注意して調べてください。

失敗3。robots.txtに書いただけで止まったと思い込む

robots.txtは拒否の意思表示であって、通信を遮断する仕組みではありません。指示を尊重すると公表しているボットもあれば、そうでないものもあります。

この思い込みが怖いのは、「対策済み」として報告してしまうことです。実際にはアクセスが続いていても、誰も見ていないので気づきません。

防ぎ方は、設定してからしばらく経ったあとに必ずアクセスログを見ることです。ボットの巡回間隔はサイトの規模や更新頻度、ボットによって大きく違うので、いつ判断できるかは一概に言えません。設定前と同じ長さの期間で件数を比べ、変化が無いなら、そのボットが指示に従っていないのか、そもそも巡回対象になっていないのかを切り分けます。指示に従っていないと判断したら、.htaccessやCDN側での遮断に切り替えます。

失敗4。過去に取り込まれた分まで消えると期待する

今から拒否設定をしても、すでに収集済みのデータが取り消されるわけではありません。robots.txtは「これから来るアクセス」に対する指示だからです。

ここを誤解したまま経営層に説明すると、あとで「消えていないじゃないか」という話になります。伝えるべきは「今後の収集を減らす措置であり、過去分は対象外」という事実です。過去分の扱いについては、各社が問い合わせ窓口や削除の申し出方法を公開している場合があるので、必要なら提供元の公式情報を確認してください。

設定してから気づく、運用側の面倒ごと

ここは教科書的な解説には出てこない、実際にやってみると詰まる部分です。

WordPressの仮想robots.txtと実ファイルの二重問題

WordPressやSEOプラグインが、実ファイルを置いていなくてもrobots.txtの内容を出している場合があります。まずは自社のドメインで /robots.txt を開き、何が表示されているかを確かめてください。

ここで表示されている内容は、実ファイルを設置すると出なくなることがあります。サイトマップの記述が出ていた場合、それも一緒に消える可能性があるということです。

回避策は、記事のステップ1です。実ファイルを置く前に今の内容を控え、必ず引き継ぐ。プラグインの管理画面からrobots.txtを編集できる場合は、実ファイルを作らずそちらから追記するほうが安全です。設置後は、もう一度 /robots.txt を開いて、控えた内容がすべて残っているかを確認してください。

サーバー会社の一括遮断は、中身を確認してから使う

管理画面のスイッチひとつで主要なAIクローラーを止められる機能は、手間の面では魅力的です。ただ、どのボットが対象なのかはサービス側が決めます。学習用だけでなくAI検索用まで含まれていれば、AI検索の引用機会も一緒に消えます。

オンにする前に対象ボットの一覧を確認し、自社が残したいボットが含まれていないかを見てください。一覧が公開されていない場合は、オンにする前後でアクセスログを比べ、何が止まったかを実測するしかありません。

止める判断そのものに、コストがある

率直に言うと、BtoBの中小企業のコーポレートサイトでは、学習用も含めて何も止めないほうが得になるケースがかなりあります。守るべき独自コンテンツが少なく、むしろ「AIに正しく知ってもらう」ほうが商談に効くからです。

逆に、独自の調査データ、現場写真、業界特化のノウハウ記事のように、それ自体が営業資産になっているサイトなら、止める意味があります。判断の分かれ目は「そのページを丸ごとAIが要約して見せたとき、自社に来る理由が残るか」です。残らないなら守る、残るなら載せる。この一言で仕分けできます。

なお、robots.txtの原稿づくり自体は生成AIに下書きさせても構いません。ただし、AIは古いUser-agent名を自信満々に出してくることがあるので、出てきた名前は必ず提供元の公式ドキュメントと1文字ずつ照合してください。照合を省くと、効かない設定ファイルが完成します。

帯域の問題を「拒否」で解決しようとしない

「ボットのせいでサイトが重い」という相談も増えています。ただ、原因がAIクローラーとは限りません。画像の重さやプラグインの処理が原因のこともあります。

先にログでボットのリクエスト比率を出し、本当にボットが原因かを確かめてから対策を選んでください。順番を逆にすると、拒否設定を入れたのに何も変わらず、原因も分からないまま時間だけが過ぎます。「検索には出ているのにAIには引用されない」という悩みが混ざっている場合は、検索1位でもAIに引用されない理由をまとめた記事のほうが近いかもしれません。

AIクローラーの拒否設定でよくある質問

まず今日やる一歩

今日中にできることは1つです。ブラウザで自社ドメインの末尾に /robots.txt を付けて開き、今どんな記述になっているかを見てください。何も出てこないのか、プラグインが自動で出しているのか、それだけで次にやることが決まります。

そのうえで「止めるより、AIに正しく載りたい」と感じた方は、BtoBがAIに引用される一次情報戦略をまとめた記事を続けて読んでみてください。

ここまで読んで、「どのボットを止めてどれを残すか、自社で判断しきれる自信がない」と感じた方もいると思います。ここは一度決めると影響が長く残る設定なので、迷ったまま触るより、現状のログと方針を一緒に整理するほうが確実です。コレットラボでは、AI検索に引用される記事づくりとあわせて、この線引きの相談も受けています。今の状態を見てもらうだけでも構いませんので、AI検索に引用される記事づくりの詳細はこちらから気軽にお声がけください。