自社サイトをAIにどこまで読ませるか|robots.txtとCloudflareで決める順番
自社のホームページを、AIにどこまで読ませるか。相手になるのは、サイトを自動で見て回るクローラー(crawler)と呼ばれるプログラムです。「ボット」「ロボット」も同じものを指すため、この記事では3つを同じ意味で使います。
「AIに勝手に使われるのは気が進まない」という気持ちと、「AIに聞かれたときに自社の名前が出てこないのは困る」という気持ち。この2つを同時に抱えている会社は多いと思います。そしてこの2つは、設定画面のスイッチを1つ押すだけでは両立しません。
この記事では、昔からあるrobots.txtと、Cloudflareがネットワークの側に置く「関所」の違い、無料プランでもできる範囲、決める順番を、同社の公式ブログと開発者ドキュメントに書かれている範囲で整理します。
先に、結論を3つ
1|robots.txtは「お願い」 守るかどうかは相手任せで、技術的には止まりません。ただし無意味ではなく、意思表示の役割があります。
2|関所は無料プランでも置ける 名乗っているAIクローラーを1つずつ許可・ブロックできます。見分ける精度が上がるのはEnterpriseだけです。
3|先に決めるのは「何を読ませたいか」 設定はそのあとです。出したいページと守りたいページを分けるところから始めます。
なお、AI検索の回答に自社を出していきたい、という方向で考えている方には、AI検索時代のホームページ対策のほうが目的に合います。あちらはAI検索に出したい人向け、こちらは読ませ方を決めたい人向けの記事です。
決める前に|守りたいものと、出したいもの
設定の話に入る前に、1つだけ整理しておきます。「AIに読ませるかどうか」は、実は1つの質問ではありません。
Cloudflareは、AI関連の通信を目的によって「検索用」「エージェント」「AI学習用」の3つに分けています。
この3つに2026年9月15日を境にどんな初期設定が置かれるかは、Cloudflareの初期設定の変更で整理しました。この記事ではその経緯は繰り返さず、自分で読ませ方を決めるための手段を扱います。
目的が分かれている以上、答えも分けて考える必要があります。検索の索引に載るのは歓迎したい。AIの回答に参照されるのも、多くの場合は悪い話ではない。一方で、手間をかけた資料の中身が学習に取り込まれるのは避けたい。1つのサイトの中に、この3つの気持ちが同居しているのが普通です。
そこで最初にやるのが、ページの棚卸しです。たとえるなら、店のショーウィンドウと、奥の作業場の区別のようなものです。
多くの中小企業のサイトでは、左側のページのほうが多いはずです。会社案内やサービス紹介は、読まれるために置いてあります。「AIに読ませない」を全体に掛ける前に、守りたいページが本当にあるのか、あるならどこなのかを確かめる。ここが決まれば、使う手段も自然に決まります。
なお、そもそも公開したくない情報は、公開ページに置かないことで守るのが先です。この記事が扱うのは「公開しているページを、どう読ませるか」です。
robots.txtは「お願い」である
お願いと関所の違いそのものは、Cloudflareの初期設定の変更の記事で詳しく書きました。ここでは要点だけを確かめます。
AIクローラーへの意思表示として、まず名前が挙がるのがrobots.txtです。ドメインのいちばん上の階層に置く短いテキストファイルで、クローラーに対して「ここは見てよい」「ここは見ないでほしい」を伝えます。ただし強制力はありません。Cloudflareの開発者ドキュメント「robots.txt setting」は、robots.txtへの準拠は任意であり、技術的な水準でアクセスを妨げるものではないと書いたうえで、こう続けています。
Some crawler operators may disregard your robots.txt directives (instructions like Disallow: /) and crawl your content regardless.(クローラーの運営者の中には、robots.txtの指示——たとえば「Disallow: /」のような記述——を無視して、コンテンツをクロールするところもあります)
Cloudflare自身も2025年9月24日の公式ブログ「Content Signals Policy」で、robots.txtに書く意思表示は希望の表明であって、スクレイピング(サイトの内容を自動で集めて持ち出すこと)への技術的な対抗策ではないと書き、使われ方を管理したいならWAF(不正な通信を止めるファイアウォール)のルールやBot Management(Enterprise向けの、よりきめ細かいボット対策)と組み合わせるよう勧めています。開発者ドキュメントにも、強制したいならAI Crawl Controlを使い、robots.txtと併用してよいとあります。
お願いは、守ってくれる相手には十分に効きます。この記事では、お願いと関所のあいだに、後の節で説明する「使い方の希望」(Content Signals)を加えた3層で考えます。
上の2つはrobots.txtに書くもので、従うかどうかは読んだ相手が決めます。関所だけが、通信が届く手前で判定します。この「どこで効くか」の違いが、そのまま「誰に効くか」の違いになります。
managed robots.txtを入れると、何が書き足されるか
Cloudflareには、robots.txtを代わりに用意して更新する「managed robots.txt」という機能があり、無料プランのプラン表にも「Instruct AI bot traffic with robots.txt(robots.txtでAIボットの通信に指示を出す)」として載っています。
気になるのは、すでに自前のrobots.txtがある場合です。開発者ドキュメントによれば、既存のファイルが正常に返ってくる(HTTPの200応答で確認できる)とき、Cloudflareは既存の内容の前に自社が管理する内容を付け足し、1つの応答にまとめて返します。言い換えると、今ある文書は消さずに、その冒頭に1章を差し込む形です。
差し込まれる内容の中心は、次の数行です(開発者ドキュメントに載っている例から抜粋)。
User-Agent: *
Content-signal: search=yes, ai-train=no, use=reference
Allow: /
User-agent: Amazonbot
Disallow: /
このあとも同じ形が続きます。2行目の「Content-signal」は後の節で説明する意思表示の書き方で、「検索はよい」「AIの学習は不可」「再利用は参照のレベルまで」という意味です。そのうえで、ドキュメントの例では、Amazonbot、Applebot-Extended、Bytespider、CCBot、ClaudeBot、Google-Extended、GPTBot、meta-externalagentの8つを名指しして、サイト全体を見ないよう求めています。一覧はCloudflareが更新しており、実例のサイトではCloudflareBrowserRenderingCrawlerを加えた9つになっています。
Cloudflareが用意したファイルでも、robots.txtである以上、この中身もすべて「お願い」です。
robots.txtを置いていない無料プランのドメインでは
無料プランで、自前のrobots.txtを持たず、managed robots.txtも使っていないドメインでは、クローラーがrobots.txtを要求すると、Cloudflareが「Content Signals Policy」の説明文を返します。
ただし開発者ドキュメントは、この説明文は分類を定義するだけで具体的な希望は何も表明しないと書き、公式ブログも許可・禁止の指示もシグナルも含まないと明記しています。何かを宣言したことにはならないので、「ai-train=no」のような希望を示すなら、managed robots.txtをオンにします。この表示はダッシュボードのセキュリティ設定や概要(Overview)の画面から止められ、自前のrobots.txtがあるサイトでは何も変わりません。
また、こうした新しい書き方にGoogleのサーチコンソールが「Syntax not understood(構文を理解できません)」と報告することがある、とドキュメントは注意しています。そのうえでCloudflareは、それによるクロール頻度やSEOへの影響は観測していないと書いています。
Cloudflareの関所は何ができるか
お願いでは足りない相手に使うのが、Cloudflareの「AI Crawl Control」(旧AI Audit)です。公式ドキュメント「AI Crawl Control」によれば、どのAIサービスが来ているかを見えるようにし、希望に沿ってアクセスを管理するための道具です。
このページの冒頭には「Available on all plans(すべてのプランで利用可能)」とあり、「Deploy with zero configuration(設定なしで導入)」として、すべてのプランで自動的に動くとも書かれています。無料プランでも、導入作業なしに使えるということです。できることは4つ挙がっています。
来ているAIを見る、クローラーごとに許可・ブロックを選ぶ、robots.txtの指示を守っているかを追って強制のルールをつくる、の3つです。4つ目の値段をつける仕組みは、ドキュメント上も「private beta(限定公開の試験段階)」とされており、別の回で扱います。
この記事の文脈でいちばん効いてくるのは3つ目です。robots.txtというお願いを出したうえで、守っていない相手が誰かを見て、その相手だけを関所で止める。前の節の「お願いと強制の併用」は、具体的にはこの形になります。イメージとしては、来客名簿をつける受付のようなものです。名簿を見れば案内板を無視して奥へ進んだのが誰かが分かり、その相手にだけ入館証を出さない、という対応ができます。
前提が1つあります。自社サイトの通信がCloudflareを経由していなければ、関所はそもそも置けません。経由しているかどうかはドメインとDNSの設定で決まり、その位置関係はホームページのサーバー移転ガイドで確認できます。関所がどこに立つのかが見えやすくなります。
見分ける精度には階段がある
関所は無料でも置けます。では、有料プランと何が違うのか。答えは「相手を見分ける精度」です。AI Crawl Controlの機能説明「Manage AI crawlers」には、こう書かれています。
On the free plan, AI Crawl Control identifies AI crawlers based on their user agent strings. This enables AI Crawl Control to detect well-known, self-identifying AI crawlers.(無料プランでは、AI Crawl ControlはAIクローラーをユーザーエージェント文字列にもとづいて識別します。これにより、よく知られた、自ら名乗っているAIクローラーを検出できます)
ユーザーエージェントとは、通信のたびにクローラーが自分で申告する名前のことです。受付で書いてもらう来訪者カードのようなもので、正直に書く相手は見分けられますが、偽名や空欄の相手は見分けられません。同じ文書は続けて、プランを上げればBot Managementの判定ID(検出に使う識別番号)を使った、より踏み込んだ検出ができると書いています。
取り違えやすいのが、この「プランを上げれば」の中身です。AI Crawl Controlの導入ガイドにあるプラン比較の表は、列を「All plans(すべてのプラン)」と「Enterprise plans with Bot Management(Bot Managementを持つEnterpriseプラン)」の2つに分けています。ユーザーエージェントによる識別が前者、判定IDによる高度な検出が後者です。精度が上がるのはEnterpriseのBot Managementだけで、Pro・Businessに上げても、AIクローラーの見分け方は無料と同じく名乗りに頼ります。
| プラン | AIクローラーの見分け方 | ボット対策の名称 | クローラーごとの許可・ブロック |
|---|---|---|---|
| 無料(Free) | 名乗り(ユーザーエージェント) | Bot Fight Mode | できる |
| Pro・Business | 名乗り(無料と同じ) | Super Bot Fight Mode | できる |
| Enterprise | Bot Managementがあれば、判定IDによる高度な検出 | Bot Management | できる |
名前にも注意が要ります。ボットの通信を見つけて抑えるBot Fight Modeは無料プランの機能で、Pro・Business向けは「Super」が付いた別の機能です。Proプランの説明ページの比較表には、自動化されている可能性が高い通信のブロック・チャレンジは「Not available on Pro(Proでは利用不可)」で、Bot Managementが要ると書かれています。
この階段を、中小企業の実務に引き直すとこうなります。名乗っている有名なAIクローラーを1つずつ止めるだけなら、無料プランで足ります。名乗らない相手まで見分けたい、という要求が出てきたときに初めて、Enterpriseの話になります。
「使い方」まで伝えるContent Signals
robots.txtは、もともと「見てよい・見ないで」を伝える仕組みです。ところがAIの時代には、見たあとに何に使うのかのほうが問題になります。そこでCloudflareが2025年9月24日に発表したのが「Content Signals Policy」です。robots.txtに使い方の希望を書き込むための決まりで、CC0ライセンス(誰でも自由に実装・利用してよい形)で公開されています。
シグナルは3つです(定義文の要点を訳したもの)。
- search:検索の索引をつくり、検索結果を返すこと(リンクや短い抜粋を返すなど)
- ai-input:1つ以上のAIモデルに内容を入力すること(生成AIの検索回答のために、その場で内容を取り込むことなど)
- ai-train:AIモデルの学習や追加学習
注目したいのは、searchの定義の最後に置かれた一文です。
Search does not include providing AI-generated search summaries.(検索には、AIが生成する検索の要約を提供することは含まれません)
「検索はよい」と書いても、AIの要約に使ってよいという意味にはなりません。AIの回答に使われるのは、ai-inputの側です。それぞれに「yes」か「no」を書くか、何も書かないかを選び、何も書かなかった用途は「許可も制限もしていない」扱いになると定義されています。
「no」と書かないかぎり「だめ」とは伝わらない、ということです。たとえるなら、図書館の本に挟む注意書きのようなものです。「館内での閲覧のみ」と書いてあれば伝わりますが、何も書いていなければ、借りた人は自分の判断で扱います。
Cloudflareの3分類とは別もの
混同しやすいのが、最初の節で触れた3分類(検索用・エージェント・AI学習用)です。名前は似ていますが、同じものではありません。3分類は関所の側で通信を振り分ける区分、Content Signalsはrobots.txtに書く意思表示の区分です。ai-inputはエージェントに近い動きに見えますが、今回確認した公式ブログ2本(2025年9月24日・2026年7月1日)と開発者ドキュメント「robots.txt setting」の範囲では、両者を1対1で対応づける説明は見当たりませんでした。片方を決めればもう片方も揃う、とは考えないほうが安全です。
2026年7月から試されている「use=」
2026年7月1日の公式ブログ「Your site, your rules」では、4つ目の任意の項目として「use=」の試験導入が発表されました。アクセスしたあと、どこまで保存・再利用してよいかを、3段階で伝えるものです。
- immediate:やり取りはしてよいが、何も保存・再利用しない
- reference(初期値):索引をつくり、抜粋し、リンクで元のページに戻す
- full:要約し、再現する
managed robots.txtをすでに有効にしている利用者には「use=reference」が自動で追加された、と同じブログは書いています。前の節の差し込み内容に入っていたのは、このためです。そしてブログは、use=の値もほかの項目と同じく希望を示すもので、直接ブロックするものではないと念を押しています。
法的な効力について
Content Signalsの定義文には、シグナルで示した制限は「EUの著作権指令(2019/790)第4条にもとづく権利の留保である」という趣旨の一文が入っています。挙がっているのはEUの指令です。日本の法律のもとでどう扱われるかについて、この記事では評価しません。法的な扱いが問題になる場面では、弁護士に確認してください。
なお、ai-trainは「公開しているページが学習に使われるかどうか」の意思表示です。社員がAIに入力した内容の扱いは、AIサービスの側の別の設定で決まります。そちらはAIに入力した情報はどこに残るのかで整理しています。
決める順番|棚卸しから見直しまで
ここまでの道具を、使う順番に並べ直します。引っ越しの荷造りと同じだと考えると分かりやすいと思います。先に要る物と要らない物を分け、それから箱に詰めます。
1|出したいページと守りたいページを分ける
最初の節の棚卸しです。守りたいページがあるなら、どのURLのまとまりに入っているかまで書き出しておくと、次の手順でそのまま使えます。
2|robots.txtで意思を示す
Cloudflareを経由しているなら、managed robots.txtをオンにするのがいちばん手軽です。画面上では、ダッシュボードの「Security Settings」を「Bot traffic」で絞った中にある「Set your preference to block training in robots.txt」というスイッチです。自前で書く場合も、場所ごとに「見ないで」を書き分けられるのはrobots.txtの強みです。気をつけたいのは、開発者ドキュメントに載っている差し込み内容の「Content-signal」の行に、ai-input(AIの回答づくり)の指定が入っていないことです。書かなかった用途は「許可も制限もしない」扱いなので、AIの回答に使われることをどう考えるかは、自社で決めて書き足す部分になります。
3|守りたい相手だけ、関所で止める
AI Crawl Controlの画面でどのクローラーが来ているかを見て、止めたい相手を1つずつブロックします。関所は相手ごとに選ぶ仕組みなので、「AIは全部お断り」と一括で閉じる必要はありません。ブロックの前に、その相手が何の目的で来ているかを、Crawlersタブの表にある「Category」(クローラーの分類)の欄で確かめておくと、検索の入口まで閉じる事故を避けやすくなります。
4|定期的に見直す
AI Crawl Controlでは、robots.txtの指示をどのクローラーが守っているかを追えます。無視している相手が見つかったら、関所に回します。use=のように試験段階の仕組みもあるため、半年に一度くらいは画面を開くつもりでいるのが現実的です。
この順番は、途中で止めても損をしません。1で自社サイトの性格が分かり、2で意思表示ができます。3は、守りたいものがはっきりある会社だけが進めばよい段階です。
私たちの見解|止める前に、見せ方を決める
ここから先は、公式の記述ではなくこの記事の判断です。資料を読み進めていちばん意外だったのは、無料プランでもかなりのことができるという点でした。AIクローラー対策は上位プランのもの、という思い込みがあると、画面を開かずに終わってしまいます。実際には、名乗っている相手を見て1つずつ止めるところまでは、どのプランでもできます。
一方で、無料やPro・Businessの範囲では、名乗らない相手まで確実に見分けることは約束されていません。「完全に読ませない」を目標にすると、判断を誤りやすいと考えています。
そのうえで、多くのBtoBの中小企業にとっては、AIに読まれること自体が、見つけてもらう手段でもあると私たちは見ています。AIに「この地域で〇〇に対応している会社は」と尋ねられたとき、自社の名前が答えに出てくる。その価値と、学習に取り込まれることへの抵抗感とを天秤にかける話です。いわば、門を閉めるか開けるかではなく、どの部屋を来客に見せるかを決める話です。
同じ会社の中には、AIに社外の文書を読ませる側の顔もあります。そちらの注意点はAIが読んだ資料に「指示」が埋まっていたらで書きました。読まれる側としては見せ方を、読ませる側としては置き場所を決める。両方がそろって、AIとの距離の取り方が決まります。
まとめ
1|robots.txtは「お願い」 守るかどうかは相手任せです。ただし無意味ではなく、公式は関所との併用を勧めています。
2|managed robots.txtは既存を消さない 既存の内容の前に差し込まれます。中身は検索はよい・AI学習は不可・再利用は参照までです。
3|関所は全プランで使える AI Crawl Controlで、名乗っているクローラーを1つずつ許可・ブロックできます。
4|精度が上がるのはEnterpriseだけ Pro・Businessも、AIクローラーの見分け方は無料と同じ名乗り頼りです。
5|Content Signalsは希望の表明 search・ai-input・ai-trainとuse=で使い方を伝えますが、技術的に止める仕組みではありません。
設定の画面を開く前に、出したいページと守りたいページを1枚の紙に分けてみる。それが、読ませ方を決めるいちばん確実な出発点です。
よくある質問
無料プランでも、AIクローラーを止められますか。
止められます。AI Crawl Controlの公式ドキュメントには「Available on all plans(すべてのプランで利用可能)」とあり、クローラーごとに許可・ブロックを選べます。ただし無料プランでは、相手が自分で申告する名前(ユーザーエージェント)で見分けるため、名乗らない相手を見分けるのは難しくなります。前提として、自社サイトの通信がCloudflareを経由している必要があります。
Proプランに上げれば、見分ける精度は上がりますか。
AIクローラーの見分け方については、上がりません。AI Crawl Controlのプラン比較の表は、すべてのプランでのユーザーエージェントによる識別と、Bot Managementを持つEnterpriseプランでの判定IDによる高度な検出とを分けています。Proのプラン表にも、自動化されている可能性が高い通信のブロック・チャレンジはProでは利用できないとあります。精度が上がるのは、EnterpriseのBot Managementだけです。
robots.txtにContent Signalsを書けば、AIの学習を止められますか。
技術的には止められません。Cloudflareは2025年9月24日の公式ブログで、コンテンツシグナルは希望の表明であり、スクレイピングへの技術的な対抗策ではないと書いています。「ai-train=no」で意思は伝わりますが、守るかどうかは相手次第です。確実に止めたい相手には、AI Crawl Controlのような関所を併用します。なお、日本の法律のもとでの扱いについて、この記事では評価していません。
managed robots.txtをオンにすると、今あるrobots.txtは消えますか。
消えません。開発者ドキュメントによれば、既存のrobots.txtがHTTPの200応答で確認できる場合、Cloudflareは管理する内容を既存の内容の前に付け足し、1つの応答にまとめて返します。付け足される内容には、検索はよい・AIの学習は不可・再利用は参照までという意思表示と、主なAIクローラー(ドキュメントの例では8つ)への「サイト全体を見ないで」という指示が含まれます。いずれもお願いである点は変わりません。
参照元・出典
確認日はいずれも2026年9月10日です。
- Cloudflare Docs「robots.txt setting」(Last updated Aug 3, 2026)— 準拠は任意、併用の勧め、差し込みの挙動と内容、無料プランの説明文
- Cloudflare Docs「AI Crawl Control」(Last updated Aug 14, 2026)— 旧AI Audit、全プランで利用可能、できること4つ
- Cloudflare Docs「Manage AI crawlers」—無料プランはユーザーエージェントで識別
- Cloudflare Docs「Get started」(Last updated Apr 23, 2026)— プラン比較
- Cloudflare Docs「Free plan(Bots)」(Last updated May 6, 2026)— Bot Fight Mode
- Cloudflare Docs「Pro plan(Bots)」(Last updated Apr 15, 2026)— Super Bot Fight Mode、Proで使えない設定
- Cloudflare Blog「Content Signals Policy」(2025年9月24日)— 3つのシグナル、CC0、希望の表明であること
- Cloudflare Blog「Your site, your rules」(2026年7月1日)— use=の試験導入と自動追加