【AI×セキュリティ】AIクローラーとサイト運営｜「robots.txt で断れば大丈夫？」を解く

【AI×セキュリティ】AIクローラーとサイト運営｜「robots.txt で断れば大丈夫？」を解く AIセキュリティ

「うちの記事、AI の学習に勝手に使われているのでは？」「最近アクセスログに見慣れないボットが増えて、サーバが重い」——サイトを運営していると、こんな悩みが出てきます。調べてみると「robots.txt に書けば AI クローラーを断れる」という情報が見つかり、ひとまず書いてみた方も多いのではないでしょうか。

ただ、robots.txt は「来ないでください」というお願いの札です。鍵ではありません。しかも、ひとくちに AI クローラーといっても、学習用・AI 検索用・利用者の依頼でその場で取りに来るもの、と性格がまったく違います。全部をまとめて断ると、検索や AI の回答に自分のサイトが出なくなる、という副作用もあります。

この記事では、robots.txt の規格（RFC 9309）と主要な AI 事業者の公式ドキュメント、そして実際の遵守状況を測った研究をもとに、「何を・どこまで断れるのか」を運営者の目線で整理します！

AIクローラーは3種類ある

主要な AI 事業者の公式ドキュメントを読むと、ボットは目的ごとに分かれています。2026年10月時点の公開情報を整理すると次のとおりです。

事業者学習用AI 検索用利用者の依頼でその場で取得
OpenAIGPTBotOAI-SearchBotChatGPT-User
AnthropicClaudeBotClaude-SearchBotClaude-User
GoogleGoogle-Extended（robots.txt 用の名前。下記参照）（下記参照）ユーザー起点の取得用ボット各種
Perplexity（学習には使わないと明記）PerplexityBotPerplexity-User

各社とも robots.txt で使う名前と、ボットの送信元 IP アドレスの一覧を公開しています。ただし用途の分け方や制御の方法は事業者ごとに違います。特に注意したいのは、3 列目の「その場で取得」の扱いです。

  • OpenAI: ChatGPT-User は利用者の操作で動くため「robots.txt のルールが適用されないことがある」と書いています（OpenAI「Overview of OpenAI Crawlers」）
  • Perplexity: Perplexity-User は利用者の依頼による取得なので「一般に robots.txt を無視する」と明記しています（Perplexity Crawlers）
  • Google: 自動で巡回する一般的なクローラーは robots.txt に常に従う一方、ユーザー起点の取得用ボットは「一般に robots.txt のルールを無視する」としています。また Google-Extended は専用の UA も専用の IP 一覧も持たない robots.txt 上の名前です。Gemini の学習だけでなく、Gemini アプリなどで回答の根拠に検索の情報を使う「グラウンディング」への利用も対象で、Google 検索への掲載や順位には影響しないと説明しています（Google「Google’s common crawlers」・Google「User-triggered fetchers」）
  • Anthropic: 3 種類のボットはいずれも robots.txt の指示に従うと明記し、Claude-User を止めると利用者の質問に応じた取得もしなくなると説明しています（Anthropic「Does Anthropic crawl data from the web…」）

つまり、制御用の名前が用意されていれば robots.txt で意思表示できますが、対象の範囲は事業者ごとに異なり、「その場で取得」は扱いが分かれます。

robots.txt の位置づけ（RFC 9309）

robots.txt は 2022 年に RFC 9309 として標準化されました。この RFC は冒頭で、robots.txt のルールはクローラーに「守るよう求める」ものであり、「アクセス認可の仕組みではない」とはっきり書いています。セキュリティ上の考慮の節でも、robots.txt は正当なセキュリティ対策の代わりにならず、むしろ書いたパスが公開されて見つけやすくなると注意しています（RFC 9309）。

運営上知っておくと役に立つ決まりもあります。

  • クローラーはキャッシュした robots.txt を、原則として 24 時間を超えて使うべきではない（書き換えの反映には時間差がある）
  • robots.txt の取得時にサーバエラー（500 番台）が返ると、クローラーは「全体が拒否」とみなす
  • 4xx（見つからない等）なら、クローラーはサイトのどこにでもアクセスしてよい

見せたくないページは、robots.txt ではなく認証で守るのが原則です！

📄 論文: 130 種のボットは robots.txt をどこまで守ったか

Scrapers selectively respect robots.txt directives: evidence from a large-scale empirical study（Taein Kim ほか、2025年5月、arXiv:2505.21733）は、査読前の論文（プレプリント）です。著者らは所属機関の Web サイトの匿名化したログを使い、robots.txt の内容を意図的に変える実験を 40 日間行って、名乗っているボット 130 種（と多数の名乗らないボット）の振る舞いを調べました。

結果は「選んで守る」でした。制限の厳しい指示ほど守られにくく、AI 検索クローラーなど一部のカテゴリは、そもそも robots.txt をほとんど取得していませんでした。著者らは、robots.txt だけで望まない収集を防ぐのは危うく、別の手段が要ると結論づけています。

運営者にとっての意味は、robots.txt には守らない相手を止める力はないということです。

📄 論文: AI アシスタントは「その場の取得」で robots.txt を守るか

Do Generative AI Assistants Respect robots.txt? Tracing Web Access Beyond Visible Answers（Gabriel Lopez-Fonseca ほか、2026年7月、arXiv:2607.14447）も査読前の論文（プレプリント）です。Web 検索機能をうたう AI アシスタント 10 種について、「全員に許可」「全員に禁止」「そのアシスタントの UA だけ許可」「その UA だけ禁止」の 4 条件で、計 200 回の試行を行いました。サーバのログと、ページに埋め込んだ秘密の文字列を使い、「実際にページを取りに来たか」と「回答が正しかったか」を分けて測っています。

この 10 種での結果は、アシスタントによって大きく違いました。期待どおり許可・禁止に従うものがある一方、robots.txt を取得しないまま禁止したページにアクセスしたものや、汎用の UA を使っていてどこのボットか判別しにくいものもありました。さらに、ページを取得したのに回答には出さない、逆に許可したページすら取得しない、というずれもありました。

運営者にとっての意味は、学習用クローラーとは別に「利用者の質問に応じてその場で来るアクセス」があり、UA 名だけでは見分けきれない場合があるということです。

📄 論文: 運営者が使える手段は、どれだけ効くのか

Somesite I Used To Crawl: Awareness, Agency and Efficacy in Protecting Content Creators From AI Crawlers（Enze Liu ほか、2024年11月、arXiv:2411.15091）は arXiv 版で、IMC ’25 に採録されています。大規模な計測と、プロのアーティスト 203 人への調査を組み合わせ、作品を AI の収集から守る手段の「知られ方・使えるか・効くか」を調べました。

robots.txt を使いたいという需要は強いものの、技術的な知識の不足、自分で設定できる立場にないこと、従わないクローラーには効かないことが壁になっていました。一方、リバースプロキシが提供するネットワーク側のクローラー遮断は、まだ普及は限られるものの、AI クローラーに対してより強い保護になると評価しています（ただし限界もあると付け加えています）。

運営者にとっての意味は、確実に止めたい相手には、robots.txt に加えてサーバの手前での遮断を組み合わせる必要があるということです。

📄 論文: 断る・断らないは、サイトの外にも影響する

Is Misinformation More Open? A Study of robots.txt Gatekeeping on the Web（Nicolas Steinacker-Olsztyn ほか、2025年10月、arXiv:2510.10315）は、WWW ’26（ACM Web Conference 2026）採録の論文です。信頼できるニュースサイトと誤情報サイトの robots.txt を比べ、AI クローラーの拒否のしかたを調べました。

信頼できるニュースサイトの 60.0% が少なくとも 1 つの AI クローラーを拒否していたのに対し、誤情報サイトでは 9.1% にとどまりました。著者らは、こうした差が LLM の学習に使えるデータを偏らせる可能性を指摘しています。

運営者にとっての意味は、「全部断る」か「全部許す」かの二択ではなく、自分の情報を AI の回答にどう扱ってほしいかという方針の問題だということです。

標準化の動き：IETF の aipref

「学習はだめ、検索は可」のような意思を、ボットの名前に頼らず伝える仕組みを作ろうと、IETF で aipref ワーキンググループが作業しています。中身は 2 本の文書に分かれています。

  • 語彙（draft-ietf-aipref-vocab）: 「AI の学習」「AI での利用」「検索」といった用途の区分と、それぞれへの許可・不許可の表し方を定める
  • 付け方（draft-ietf-aipref-attach）: その意思を HTTP のヘッダーや robots.txt に載せる方法を定める。この草案は RFC 9309 の更新を提案している

2026年10月1日時点で、語彙は改訂 -08（2026年9月）、付け方は改訂 -05（2026年8月）で、どちらもワーキンググループで作業中の文書（IESG には未提出）です。ワーキンググループの予定では 2026年8月までに IESG へ提出することになっていましたが、まだ RFC にはなっていません（IETF aipref WG）。

また語彙の草案自身が、意思表示を受け取った側が従うかどうかは受け取った側の選択であり、この仕様の範囲外だと書いています（draft-ietf-aipref-vocab-08）。標準ができても、robots.txt と同じく「お願い」である点は変わらないのです。

運営者のやること

1. 方針を決める

まず「学習に使われたくないか」「AI 検索や AI の回答に出たいか」を分けて考えます。学習は断るけれど AI 検索には出たい、というのはよくある組み合わせです。事業者側もボットを分けているので、方針に合わせて選べます。

2. robots.txt に書く

方針が「学習を断る」なら、公式ドキュメントにある名前を並べます。例えば次のように書きます（Google-Extended は Gemini のグラウンディングにも及ぶ点に注意）。

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

検索用（OAI-SearchBot・Claude-SearchBot・PerplexityBot など）を断ると、各社の AI 検索の結果に出にくくなると公式ドキュメントに書かれています。名前は増えたり変わったりするので、ときどき公式ページを見直しましょう。アクセスの頻度を下げたいだけなら、Anthropic のように独自拡張の Crawl-delay に対応すると明記している事業者もあります。

3. 止めたい相手はサーバ側で制御する

robots.txt を守らない相手、その場の取得、名乗らないボットには、サーバ側の制御が必要です。Web サーバやリバースプロキシ、CDN のボット対策機能で UA や送信元によって遮断・回数制限をかけます。UA は偽れるので、各社が公開する IP アドレスの一覧との照合が識別の助けになります。一覧は更新されるので最新を使い、Google のように逆引き DNS での確認手順を案内している事業者もあります（Google「Verify requests from Google crawlers and fetchers」）。なお Anthropic は、IP での遮断だと robots.txt を読めなくなり、オプトアウトが確実に伝わらないことがあると注意しています。意思表示は robots.txt、強制はサーバ側、と役割を分けましょう。

4. ログで確かめる

設定したら、アクセスログで効果を確認します。どの UA がどれくらい来ているか、robots.txt を取得しているか、禁止したパスに来ていないかを見ます。守るかどうかはボットごとに違うので、自分のサイトで確かめましょう！

AIクローラー対策の鍵は次の3点です

  1. robots.txt は「お願い」、鍵ではない
    RFC 9309 自身がアクセス認可の仕組みではないと明記しています。見せたくないものは認証で守りましょう。
  2. ボットの種類ごとに方針を分ける
    学習用・AI 検索用・その場の取得は別物です。全部断ると検索や AI の回答から消える副作用があります。
  3. 意思表示と強制を組み合わせ、ログで確かめる
    robots.txt で意思を示し、守らない相手はサーバ側で止めます。効いているかはログで確認します。

まとめ：robots.txt は入口、守りはサーバ側と組み合わせて！

AI クローラーへの対応は、「robots.txt に書いたから大丈夫」では終わりません。研究では、厳しい指示ほど守られず、AI 検索や AI アシスタントのその場の取得には robots.txt を見ないものもありました。一方で、主要な事業者はボットの名前と目的を公開しており、方針さえ決めれば robots.txt で意思表示はできます。まずは方針を決め、robots.txt を整え、必要ならサーバ側で制御し、ログで確かめる。この順番で進めていきましょう！

参考文献

タイトルとURLをコピーしました