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クローラーでは成立しないことがこの領域の出発点です。

3層すべてに共通する、もう1つの弱点があります。そもそも相手の名乗りを信じてよいのかという問題です。User-Agent文字列は自己申告なので、GPTBotを名乗る第三者のスクレイパーと本物を見分けられません。ここを埋めるのがWeb Bot Authで、ボット側がリクエストに電子署名を付け、サイト側(実務ではCDNやWAF)が公開鍵で検証します。標準化はまだドラフト段階ですが、Cloudflareは2025年7月にVerified Bots Programへ組み込み、AWS WAFも2025年11月にサポートを発表しました。用途別の許可・拒否は、相手が名乗りどおりであって初めて意味を持ちます。

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利用について明示的な方針を持つ少数派のサイト」になれます。

ボットが何をするかは誰が申告しているのか

ここまでの2節はすべて、サイト側からの意思表示でした。robots.txtで取得の可否を書き、Content Signalsで利用目的を宣言し、Web Bot Authで相手の名乗りが本物かを検証する。それでも残る問いがあります。名乗りが本物だと分かったあと、そのボットが実際に何をするのかを、サイト側はどこで知るのかです。

Cloudflareがその受け皿として持っているのが、既知のボットを挙動で分類したディレクトリ「BotBase」です。公式ドキュメントは、追跡している各ボットを「そのボットがサイト上で何をしうるか」という振る舞いで分類すると説明しており、1つのボットが複数の分類にまたがることもあるとしています。ダッシュボードから検索・絞り込みができ、特定のボットの detection ID をコピーしてセキュリティルールの対象に指定できます。ただしディレクトリの閲覧はEnterprise Bot Managementの顧客向けと公式ドキュメントに明記されており(2026年8月時点)、無料プランで開ける画面ではありません。

2026年8月28日、Cloudflareはこの仕組みのうちボットを運用する側(オペレーター)の登録手続きを更新したと公表しました。提出の窓口がダッシュボードの「Protect & Connect > Application Security > BotBase」に移り、全顧客がその日から使えること、一度出した申請を後から編集でき、審査待ちの申請を取り下げられること、そして審査を自動化したこと(重複の確認、申告した検証方式が実際に成立するかの確認、IPリストの取得、逆引きDNSやWeb Bot Authの検証)が挙げられています。申請の状態は Waiting for review(審査待ち)・Accepted(承認)・Rejected(却下)の3つです。

サイト運営者にとって効いてくるのは、そこでオペレーターが申告する3項目のほうです。

2つ目が噛み合っている点に注目してください。Cloudflareはサイト側のrobots.txtの例として Content-Signal: search=yes, ai-train=no, use=reference を挙げたうえで、ボット側にも同じ語彙で使い方を申告させています。サイトが「こう使ってほしい」と書く語彙と、ボットが「こう使う」と申告する語彙が噛み合っていなければ、用途別の許可・拒否は成立しません。

裏を返せば、用途別の判断は最終的に相手の自己申告に依存しているということでもあります。robots.txtにもContent Signalsにも強制力はなく、BotBaseの分類もボット側の申告と審査を土台にしています。3層の意思表示が意図どおりに効くかどうかは、名乗りの証明(Web Bot Auth)・用途の申告(BotBase)・サイト側の宣言(Content Signals)の3つが噛み合うかにかかっている、というのが現在地です。自社に実際に来ているボットをクローラー名まで突き止める作業は、いまのところアクセスログとCDNの分析画面が出発点であることは変わりません。

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

ここが直近で最も実務的な論点です。Cloudflareは、2026年9月15日から、広告を表示しているページでは、Training(学習)とAgent(エージェント)に分類されるクローラーを既定でブロックすると公表しています。Search(検索)は既定で許可のままです。あわせて、検索・エージェント・学習を運営者が選び分けられない「混合用途(mixed)」のクローラーは、広告のある全ページでブロックされます。用途を申告し分けられないクローラーは、まとめて閉め出される側に回るという設計です。

対象は、新規に契約する顧客、既存顧客が新しく追加するサイト、そして9月15日までに設定を変更しなかった既存の無料プラン利用者すべてです。有料プランで運用中の既存ドメインは自動的には対象になりませんが、Trainingをブロックしている場合は複合クローラーの扱いが影響を受けるため、いずれにせよ9月15日までに設定を確認してください。オプトアウトは9月15日までなら、セキュリティ設定からいつでもできます。なお当サイトはCloudflareの無料プランで広告も表示しているため、この変更の対象に含まれます。

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

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

拒否の次にある選択肢:課金

許可か拒否かの二択に、第3の選択肢が加わりつつあります。Pay Per Crawlは、AIクローラーの取得リクエストに対してサイト側が料金を提示できる仕組みで、Cloudflareが2025年7月にプライベートベータで公開しました。クローラーがページを要求すると、サイト側は「無料で通す(200を返す)」「料金を提示する(402 Payment Requiredを返す)」「拒否する」の3つから応答を選びます。402の応答には価格が入り、支払う意思のあるクローラーだけが本文を受け取ります。

2026年7月1日には次の段階として、課金の起点を「取得されたとき」から「コンテンツが価値を生んだとき」へ移す方針(Pay Per Use)が、Cloudflareの公式ブログとプレスリリースで示されました。試験のパートナーはCeramic.aiとYou.comの2社です。Ceramicは自社の検索結果に記事が表示されたときに支払う「pay-per-query」型、You.comはエージェントが必要な有料コンテンツごとに都度支払う型で、いずれもパブリッシャー側のオプトインが前提です。Pay Per Crawlが「取りに来たら課金」だったのに対し、Pay Per Useは「使われたら課金」へ軸を移すもので、クロールの量と価値がずれているという問題意識が背景にあります。

背景の数字は、AI流入をどう扱うかを決めるうえで押さえておく価値があります。Cloudflareが2026年7月に公表したレポートの実測値です。

読み方は単純で、クロールは増え、人の訪問は減っているという構図です。ただし課金が答えになるのは、コンテンツ自体が商品であるサイトに限られます。BtoBのオウンドメディアやツールサイトのように「読まれることで儲かる」側は、課金より許可と引用最適化のほうが合理的です。当サイトが3カテゴリとも yes を選んでいるのはこの理由によります。

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

当サイトで実際に起きた事故を共有します。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日から、広告表示ページではTraining・Agentが既定ブロック(Searchは許可)。用途を選び分けられない混合クローラーは広告のある全ページでブロック。対象は新規契約・新規サイト・既存の無料プラン利用者すべて
• 許可・拒否に次ぐ第3の選択肢として、リクエスト単位で課金するPay Per Crawlがある。有効なのはコンテンツ自体が商品のサイトで、集客の入口として出しているサイトでは逆効果
• 3層すべてに共通する弱点は「名乗りを信じてよいのか」。電子署名で身元を証明するWeb Bot Authがその前提を埋める。標準化はドラフト段階だが検証の実装は先行している
• 名乗りの次にくるのは「そのボットが何をするか」。CloudflareのBotBaseはボット側に用途・使い方・運営主体を申告させる仕組みで、2026年8月28日に提出手続きが更新された。使い方の申告はContent Signalsと同じ語彙。ディレクトリの閲覧はEnterprise Bot Managementの顧客向け

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