AIクローラーは許可か拒否か｜robots.txtとContent Signalsの書き方・2026年9月の既定変更

AIクローラーへの意思表示は、「取得してよいか(robots.txt)」「取得した後どう使ってよいか(Content Signals)」「実際に通すか(CDN側のブロック)」の3層に分かれています。 結論は全部許可でも全部拒否でもなく用途別で、検索とAI回答の参照は開け、学習だけを方針で決めるのが基本形です。どれか1つを設定しただけでは意図した通りに扱われません。この記事は、3層それぞれの書き方と効き方、用途別(検索・AI回答・学習)の判断基準、そして2026年9月15日に予定されているCloudflareの既定変更までを、当サイトの実物のrobots.txtを示しながら整理します。

3つの用途を分けて考える

AIクローラーを「AIかどうか」で一括りにすると判断を誤ります。実務で意味があるのは用途の区別です。Cloudflareも2026年7月に、近い3分類(Search / Agent / Training)でのAIトラフィック管理を導入しました。

※Google-Extendedは独自のUA文字列を持つクローラーではなく、Geminiの学習とグラウンディングでの利用可否を制御するためのトークンです。robots.txtでの指定方法は他と同じですが、「そのクローラーを止める」のではなく「用途を拒否する」ものだと理解しておくと混乱しません。

この3語(search / ai-input / ai-train)は、後述するContent Signalsでそのまま使うラベルでもあります。IETFのドラフトでは、検索は「検索インデックスを作りSearch Resultsを提供する行為。AIによる要約の生成は含まない」、AI Inputは「RAGやグラウンディングなど、生成AIの回答のためにリアルタイムで取り込む行為」、AI Trainingは「モデルの学習・ファインチューニング」と定義されています。

判断が分かれるのは真ん中のai-inputです。学習は「渡して終わり」ですが、AI回答の参照は引用元リンクが表示されることが多く、検索の代替入口として機能します。AI経由の流入を取りにいくなら、ここを閉じてはいけません。

意思表示は3層ある

同じ「AIに読ませたくない」でも、書く場所によって効き方がまったく違います。

①と②はどちらも「お願い」であって、無視するクローラーは無視します。逆に③はサーバーに届く前に止まるため確実ですが、間違えると検索エンジンまで締め出します。「robots.txtに書いたから止まっているはず」という前提が、AIクローラーでは成立しないことがこの領域の出発点です。

Content Signalsの書き方

Content SignalsはCloudflareが2025年9月に提唱した仕組みで、robots.txtの中に「取得した後の利用目的」を宣言します。書式は単純で、User-agent ブロックの中に Content-Signal 行を足すだけです。

User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

yes は「その用途に使ってよい」、no は「使ってほしくない」という宣言です。指定しなかったラベルは「意思表示なし」であり、暗黙の許可でも拒否でもありません。当サイトは引用と露出を優先する方針のため、3つとも yes にしています。実物は当サイトのrobots.txtで確認できます。

# Content Signals(https://contentsignals.org/): AI利用の意思表示。
# 当サイトは引用・露出を優先するため3カテゴリすべてyes。
Content-Signal: search=yes, ai-input=yes, ai-train=yes

書く位置には落とし穴があります。robots.txtの仕様(RFC 9309)では、自分の名前に一致するグループがある場合、クローラーは User-agent: * のグループを読みません(* は一致するグループが無いときの受け皿です)。つまり User-agent: GPTBot のような名前付きグループを別に書いているサイトでは、User-agent: * に置いたContent-Signal行はGPTBotには届きません。いずれかのシグナルを no にする場合は、対象のクローラーのグループにも同じ行を書き足す必要があります。

User-agent: GPTBot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

法的な位置づけは正直に見ておく必要があります。IETFのインターネットドラフト draft-romm-aipref-contentsignals-00 は2025年10月に提出された後、2026年4月4日に期限切れとなったまま改訂版が出ていません(2026年8月時点)。標準として確定したものではなく、遵守は各AI事業者の判断に委ねられています。実際、Googleは自社のクローラーにもLLMにも一切効果がないと公言しており、対応を表明した主要クローラーは確認できていません。Cloudflareの既定文面が根拠として挙げるのはEU著作権指令(2019/790)第4条に基づく権利の留保で、法的効力は今後の判断待ちです。

それでも書く意味があるのは、機械可読な形で権利を留保した記録が残ること、そしてCloudflareのエージェント診断のように、この行の有無を評価に使うツールが実際に現れているためです。逆にいえば、今日クローラーの挙動が変わることは期待できません。

普及率は高くありません。Cloudflareの調査では、robots.txtを置いているサイトが約78%あるのに対し、Content Signalsを設定しているサイトは約4%にとどまります。裏を返せば、今設定すれば「AI利用について明示的な方針を持つ少数派のサイト」になれます。

2026年9月15日に既定が変わる

ここが直近で最も実務的な論点です。Cloudflareは、2026年9月15日から、新たにCloudflareへオンボードするドメインについて、広告を表示しているページではTraining(学習)とAgent(エージェント)の分類のクローラーを既定でブロックすると公表しています。Search(検索)は既定で許可のままです。既定値が変わるのは新規オンボードのドメインで、既存の顧客はこの既定変更の対象外です。ただし既存ドメインでもTrainingをブロックしている場合は複合クローラーの扱いが影響を受けるため、9月15日までに設定を確認しておくべきです。オプトアウトは9月15日までなら、セキュリティ設定からいつでもできます。

この変更で本当に注意すべきなのは、既定値そのものより複合クローラーの扱いです。Cloudflareの説明では、検索と学習の両方の性質を持つクローラーは、そのすべての振る舞いに従って許可・ブロックが決まります。つまりTrainingをブロックする設定にすると、GooglebotやApplebot、bingbotもブロック対象に含まれます。「学習だけ止めたい」つもりで検索流入の入口ごと閉じる事故が起こりうる、という意味です。

対象条件としてCloudflareが挙げているのは「広告を表示しているページ」です。広告の種類や判定方法までは公表されていないため、広告を掲載しているサイトは、9月15日より前に自社ドメインが新規オンボード扱いかどうかと、Trainingブロックを選んだ場合の影響範囲を確認しておくのが安全です。

ダッシュボードが勝手に方針を書き換えることがある

当サイトで実際に起きた事故を共有します。2026年8月、CloudflareのAI関連機能(エージェント診断のベータ)を触った時期に、ゾーン設定の「AIボットアクセスを管理」が有効になり、本番のrobots.txtの先頭にCloudflare管理のブロックが自動で注入されていました。中身はGPTBot・ClaudeBot・Google-Extended・CCBotなどを Disallow し、Content-Signalで学習を拒否するものでした。

当サイトはAIに読ませて引用されることを狙う方針なので、掲げている方針と真逆の内容が、リポジトリのファイルを一切変更しないまま配信されていたことになります。CDNがrobots.txtを書き換える構成では、リポジトリの中身と実際に配信される内容が一致しているとは限りません。

対処は単純で、ダッシュボードでAI関連の設定を操作したら本番のファイルをそのまま取得して確認することです。

curl -s https://example.com/robots.txt | head -20

管理robots.txtは「AIに学習させたくない」サイトにとっては便利な機能です。問題は、自分の方針と一致しているかを確認しないまま有効になることです。

自社はどちらを選ぶべきか

用途を分けて考えれば、多くのサイトは「全部拒否」でも「全部許可」でもない中間に落ち着きます。

判断の軸は1つです。そのコンテンツは「読まれること」で儲かるのか、「読ませないこと」で儲かるのか。 前者なら開ける、後者なら閉める。AI経由の流入をどう捉えるかの全体像はAEO(回答エンジン最適化)とはで、AIエージェントにサイトの機能そのものを開放する一歩先の話はCloudflare WebMCPの解説で扱っています。

よくある失敗

• Disallowだけで安心する: robots.txtに強制力はない。遵守しないクローラーを止めるにはCDN・WAF側のブロックが要る
• Trainingを一括ブロックして検索まで止める: Googlebotやbingbotは複合クローラー。用途分類ではなくクローラー名まで確認する
• ai-inputを学習と同じ扱いで閉じる: AI回答の参照は引用リンクを伴う集客経路。閉じるとAI検索からの流入が消える
• CDNのダッシュボード操作後にrobots.txtを見ない: 管理robots.txtが方針と逆の内容を注入することがある(当サイトで実例)
• Content-Signalを User-agent: * にだけ書く: 名前付きグループを持つクローラーはそちらしか読まない(RFC 9309)。no を宣言するなら各グループに書く
• 設定して終わりにする: 新しいクローラーは継続的に登場する。四半期に一度は実物のrobots.txtとアクセスログを確認する

まとめ

• AIクローラーへの意思表示は「取得の可否(robots.txt)」「使い方の宣言(Content Signals)」「実際の遮断(CDN)」の3層。①②に強制力はない
• 用途は検索(search)・AI回答の参照(ai-input)・学習(ai-train)の3分類。AI経由の流入を取るならai-inputは開ける
• Content Signalsは User-agent ブロック内に Content-Signal: search=yes, ai-input=yes, ai-train=no の形で1行足すだけ。普及率は約4%
• IETFドラフトは-00のまま2026年4月に期限切れで、法的拘束力はない。対応を表明したクローラーもまだない。意思表示の記録として書く
• 2026年9月15日から、Cloudflareへ新規オンボードするドメインの広告表示ページではTraining・Agentが既定ブロック。既存ドメインは対象外だがTrainingブロックは複合クローラー(Googlebot等)も巻き込むため設定確認を

いまの自社サイトがAIから見てどう評価されるかはAIエージェント対応度の実測で測れます。生成AIまわりの社内ルール整備はAIガバナンス、AI向けのサイト概要ファイルはllms.txtもあわせてどうぞ。