9月15日、あなたのサイトはAIに読まれなくなる？
— Cloudflare仕様変更と3つの確認

1. 何が起きるのか — 9月15日の変更の正確な中身

Cloudflare（クラウドフレア）は、サイトの表示高速化や攻撃対策のために世界中のWebサイトが利用している基盤サービスです。W3Techsの調査（2026年8月）では、全Webサイトの24.8%がCloudflareを利用しています。おおよそ4サイトに1つです。日本の中小企業サイトでも、制作会社やサーバー事業者が裏側で組み込んでいるケースが多く、自社サイトが該当していることに運営者自身が気づいていないことは珍しくありません。

Cloudflareは2026年7月の発表で、AIのクローラー（サイトを読みに来るロボット）を用途で3つに分類し、サイト側が用途別に許可・拒否を選べる仕組みを整えました。

分類	用途	9/15からの初期設定 （対象ページ）
Search（検索）	検索やAI検索の索引を作り、出典つきで回答するための収集	許可
Training（学習）	AIモデルの学習・微調整のためのコンテンツ取得	ブロック
Agent（エージェント）	利用者の代わりにAIがリアルタイムでページを取得する操作	ブロック

そして2026年9月15日から、Cloudflareに新しくオンボードされるドメインでは、広告が掲載されているページ（広告枠を含み、人の訪問や広告表示が収益につながるページ）について、この初期設定が適用されます。Searchは通しつつ、TrainingとAgentは標準で遮断される、という状態が「何も設定しなくても」始まります。

2. 影響を受けるのは誰か — 広がっている誤解の訂正

SNSでは「無料プランの利用者は全員対象」といった説明も見かけますが、公式発表で確認できる範囲は次のとおりです。

• 対象: 9月15日以降にCloudflareへ新規オンボードされるドメインの、広告が掲載されているページ
• 既存の利用者: 事前に通知があり、設定を選び直すことができます（自動的に一律遮断されるわけではありません）
• 広告のないページ: 今回の初期設定変更の対象として明示されているのは広告掲載ページです

ただし「自分は既存だから関係ない」とも言い切れません。サイトのリニューアル、サーバー移転、新ドメインでのサイト立ち上げは「新規オンボード」に該当し得ます。また、この初期設定の変更は方向性の表明でもあり、用途別制御が標準になっていく流れ自体は既存サイトにも及びます。だからこそ、後述の「3つの確認」を一度やっておく価値があります。

3. なぜこうなったのか — 新聞3社の提訴という背景

日本の話が分かりやすいです。2025年8月、読売新聞グループがAI検索企業に対して約21.68億円の損害賠償等を求めて提訴し、同月には日本経済新聞社と朝日新聞社も同じ企業を相手に合計約44億円を求めて提訴しました。

争点のひとつが、サイト側が「AIによる収集を拒否する」と設定（robots.txt）していたのに、それを無視して読み取られていたという点です。つまり、サイト運営者が自分で「読むな」と書くだけでは守られるとは限らなかった。この経験から、通信の基盤側で強制力を持って止める、という流れが強まりました。今回のCloudflareの変更もその一環です。

方向としては、コンテンツを作る側に有利な変化です。ただし短期的には、AIに紹介されたくて情報発信しているのに、サイトの土台がそのAIを追い返しているという逆転が起こり得ます。ここが本記事の主題です。

4. サイト運営者が確認すべき3点

1. 自社サイトがCloudflareを使っているか
   制作会社かサーバー会社に聞けば1分で分かります。自分で確かめる方法は第6章に書きました（技術者でなくても手順どおりで確認できます）
2. 使っている場合、9月15日以降の設定がどうなるか
   新規ドメインでの立ち上げ・移転の予定があるか。広告（アドセンス等）を載せているページがあるか。既存ドメインでも、Cloudflareからの通知メールを見落としていないか
3. 検索用（Search）と学習用（Training）・エージェント用（Agent）を、分けて設定できているか
   ここが肝です。「AIは全部ブロック」にすると、AIの回答にもAI検索にも出られなくなります。「全部許可」にすると、意図しない利用も含めて素通しです。用途別に選べる状態にしておくことが、どちらの方針を採るにしても前提になります

5. 「全部ブロック」も「全部許可」も正解ではない

どう設定すべきかは、サイトの目的で決まります。

• 集客のためのサイト（会社サイト・店舗サイト・サービス紹介） — AIに読まれることは損失ではなく、AIの回答で紹介されるための入口です。少なくともSearchは開けておくべきで、当社は自社サイトを「AIに読まれて、推薦される」方針で全面的に開けています。この考え方と実装はAIO対策 完全ガイドに実証つきでまとめています
• コンテンツ自体が商品のサイト（有料記事・写真・データ） — Trainingを閉じ、Searchの扱いを事業判断として決める意味があります。新聞社の提訴はこちら側の論理です
• 非公開にすべき領域（会員ページ・提案資料・検証環境） — クローラー設定ではなく、認証やHTTPヘッダーで守るのが確実です。robots.txtは「お願い」であり、守らない相手がいることは前述の訴訟が示しています

6. 実測 — 当社サイト3つを1分で点検した手順

本記事を書く前に、当社の3サイト（会社サイト・ECサイト・デモ環境）を実際に点検しました。手順はこれだけです。

1. ブラウザで対象サイトを開き、開発者ツール（F12）のネットワークタブで最初の応答の「レスポンスヘッダー」を見る。server: cloudflare や cf-ray: という行があればCloudflare利用中です（コマンドが使える方は curl -I https://自社ドメイン/ で同じことが確認できます）
2. https://自社ドメイン/robots.txt を開き、AI向けの記述（GPTBot、CCBot等への指定）がどうなっているか見る
3. Cloudflare利用中なら、管理画面のAI Crawl Control（AIクローラー制御）で、Search／Training／Agentの設定状態を確認する

当社の結果: 3サイトともCloudflareは不使用（サーバー直配信）で、9月15日の初期設定変更の影響はありませんでした。公開ページのクローラー設定は全面許可＝「AIに読まれて推薦される」方針どおり、非公開領域は認証・ヘッダーで分離済み、という現状を確認して本記事を書いています。

7. よくある質問

Q. 広告を載せていない会社サイトなら、何もしなくていいですか？

今回の初期設定変更の直接の対象ではありません。ただし「自社がCloudflareを使っているか」「AIクローラーに対して今どういう設定になっているか」を把握していない状態は、それ自体がリスクです。確認は1分で終わるので、この機会に一度見ておくことをお勧めします。

Q. AIにたくさん読まれると、サーバーが重くなりませんか？

アクセスが極端に多い場合は起こり得ます。その場合も全面遮断ではなく、用途別の制御やレート制限で「読ませ方」を調整するのが筋です。

Q. 確認したいが、社内に分かる人がいません。

無料相談で、その場で貴社サイトを一緒に確認します（上の手順を当社が実施するだけなので、確認自体はすぐ終わります）。そのうえで、AIに推薦される側の施策が必要であればAIO診断（5万円）をご案内します。

出典・参考

• Cloudflare公式ブログ「Your site, your rules: new AI traffic options for all customers」（2026年7月）ほか、Content Independence Day関連の発表一式
• W3Techs: Usage Statistics of Cloudflare（2026年8月・全Webサイトの24.8%）
• gihyo.jp: Cloudflare、AIボットによるコンテンツ利用の用途別制御機能を発表
• 読売新聞グループによる提訴（2025年8月・約21.68億円）、日本経済新聞社・朝日新聞社による提訴（2025年8月・計約44億円）の各社発表

本記事は2026年8月25日時点の公開情報に基づいています。設定の名称・仕様は変わることがあります。実施の際は必ず最新の公式情報をご確認ください。