Cloudflareが「検証」の定義を変えた日 — Search/Agent/Training 三分類の刷新と、37体allowの次の一手

2026年7月1日、Cloudflareが「Content Independence Day 2026」と名付けた2本の公式ブログを同時公開した。1本はボット管理の枠組み刷新の告知、もう1本はこの1年間の統計を振り返るレポートだ。archives/86でデフォルトの「AI botsブロック」設定がGEOを殺しかねないと警告し、archives/89でCloudflareが「検証署名」路線へ転換した証跡を追い、archives/90でIETF WebBotAuth WGという標準化機関の発足を記録し、archives/91で当サイトのCloudflare本番環境にVerified AI Agent 37体を個別allowする実装まで完了させた。今回の発表は、その連載の直系の続報にあたる。半歩先で警告した側には、半歩先で対応する責任がある——この連載を貫くテーマに、また一つ宿題が積まれた形だ。

Content Independence Day 2026 — 発表の全体像

Cloudflareは今回の発表を「すべての顧客向けの新しいAIトラフィックオプション」と位置づけている。柱は大きく2つある。1つは、ボットの用途を3分類に整理し直したこと。もう1つは、9月15日から新規ドメインとFreeティア顧客全体（既存サイトを含む）に、新しいデフォルト挙動を適用することだ。

対象範囲を整理すると次のようになる。

• 新規に作成されるドメイン、および既存顧客が新たに立てるサイト
• 既存のFreeティア顧客全員（すでに運用中の既存サイトも含む）
• 既存の有料契約サイトには自動適用されない（顧客側の設定が優先される）

デフォルトの中身は、「広告が表示されるページ」において、TrainingとAgentの2用途はデフォルトでブロックし、Searchはデフォルトで許可を維持するというものだ。設定は3択で、「全ページでブロック」「広告表示ページのみブロック」「ブロックしない」から選べる。9月15日より前であれば、Security設定からいつでもオプトアウトできる。

Search / Agent / Training 三分類の詳細

今回の刷新の核心は、これまで「AI bot」とひとまとめにされてきたクローラーを、行動の性質で3つに分けたことにある。Cloudflareの定義を原文の趣旨に沿って整理すると以下の通りだ。

注意すべきは、GooglebotのようなマルチパーパスクローラーはSearchとAI機能の両方に使われ続けており、Cloudflareはこうしたクローラーについて「用途ごとに分離して制御する」ことを推奨している点だ。たとえばGoogleの場合、AI学習だけを個別に制御したいなら、通常のGooglebotとは別に「Google Extended」ボットを管理する必要がある。3分類は概念としては明快だが、実際の運用では「1つのUAが複数の分類にまたがる」ケースへの目配りが要る。

「Verified」の意味が変わった — GEO担当者が見落としやすい最重要ポイント

ここが今回の発表でもっとも実務に影響する部分だ。従来、Cloudflareの「Verified bot」というラベルは、実質的に「デフォルトで許可される」ことを意味していた。archives/91で当サイトが個別allowを実装した動機も、「Verifiedでも一律ブロックされてしまう設定があるなら、意図的に許可リストへ載せる必要がある」という前提に立っていた。

今回の刷新で、この前提そのものが書き換わった。新しい定義では、Verifiedというラベルは「そのボットが属するカテゴリの中で許可対象になる」ことしか意味しない。つまり、あるボットがVerifiedであっても、そのボットがTrainingやAgentに分類され、かつそのカテゴリが新規ドメインでデフォルトブロックされているなら、Verifiedという肩書きだけでは自動的に通過できない。「Verified＝素通り」という単純な図式は、7月1日付けで公式に終わった。

加えて、Verified資格そのものが剥奪される条件も明文化された。自己申告した情報が虚偽だった場合、またはコンテンツを乱用した場合（例としてfull reproduction、つまりコンテンツの完全な再現・複製が挙げられている）は、Verified資格を失う。GEO担当者にとっての実務的な含意は明確だ——「Verifiedだから安心」ではなく、「そのボットがどの分類に属し、その分類が自サイトでどう扱われる設定になっているか」を個別に確認する作業が、9月15日までに必要になる。

Direct vs Intermediary Access — 誰が実際にそのボットを動かしているのか

もう一つ、2026年7月1日付けでBotBaseに追加された新しいメタデータフィールドが「Direct vs Intermediary Access」だ。背景にあるのは、Stripeのようなプラットフォーム経由の自動化が増え、「ボットを作った会社」と「実際にそのボットを操作している主体」が一致しないケースが増加しているという状況認識である。

技術的には、RFC 7239で定義されているForwardedヘッダーの考え方を応用し、Forwarded: for="openai"のような形でプロキシ層を越えて信頼情報を伝達する仕組みが想定されている。この延長線上にあるのが「Signed agent」という概念で、エンドユーザーが制御し、Web Bot Auth（archives/90で取り上げたIETF標準化の対象そのもの）の暗号署名によって検証されるボットを指す。

ここでCloudflare自身が誠実な留保を付けている点も見逃せない。この推移的信頼の仕組みは、「身元を明かす余裕のあるユーザーにしか及ばない可能性がある」とCloudflare自身が認めている。すべてのエージェント利用者が署名インフラを持てるわけではない、という現実的な限界を、発表元が自分で言葉にしている構造だ。

非人間トラフィックが50%を超えた日

1年間の振り返りレポートで示された統計は、この一連の政策転換の背景を物語っている。

• 2026年6月、Cloudflare経由のトラフィックにおいて非人間トラフィックの割合が初めて50%を超えた（史上初の節目）
• AI訓練用クローラーの割合は52%。2025年春の22%から大きく増加
• 混合用途クローラー（複数の目的を兼ねるもの）は36%以上
• Cloudflare経由のWebドメイン比率は20%超
• 生成AIの利用者数は30億人以上に到達。これは3.5年での到達であり、スマートフォン普及の2倍以上の速度
• Googleが占める参照トラフィックの割合は約88%

Matthew Prince CEOはこの状況について、「インターネット上のトラフィックの過半数が非人間になった以上、持続可能なエコシステムが生まれるよう、我々はさらに踏み込み、より速く行動しなければならない」（TechCrunch）と述べている。また「小規模サイトを運営している場合、問題はコンテンツがモデルの学習に使われることだけではない。誰にも見つけてもらえなくなることだ」とも語っており、ブロック一辺倒ではなく「見つけてもらう」導線としてのAI流入を意識した発言だと読める。

archives/91の37体allowは今どうなるのか — 自己実証

ここからは当サイト自身の状況を、正直に開示する。

✅ 当サイト実施済 archives/91で実装した「Verified AI Agent 37体を本番CloudflareのWAF Custom Ruleで個別allowする」設定は、現時点でも本番環境に存在している。この設定自体が今回の分類刷新によって即座に無効化されるという公式のアナウンスは見当たらない。ただし、正直に書いておくべきことがある——既存のWAF Custom Ruleが、新しいSearch/Agent/Training分類とどう対応づけられるのか、あるいは移行手順が別途必要になるのかについて、Cloudflareの公式ドキュメント上に明確な記述は見つかっていない。ここは推測で埋めず、9月15日に向けて公式情報を追い続けるべき箇所として、次の課題に位置づける。

🔧 これから 新しいSearch/Agent/Training分類への対応方針の見直し、およびrobots.txtへのContent-Signal設定は、当サイトでもまだ着手できていない。9月15日のデフォルト変更適用までに対応する予定として、ここに明記しておく。

もう一つ、確認できたことを誠実に共有したい。本番Apacheのアクセスログ（origin側、直近5日間）を調べたところ、ClaudeBotやGPTBot、PerplexityBotといったAI系ユーザーエージェントはほとんど観測されなかった（Bytespiderが/robots.txtへのアクセスとして2件のみ確認できた程度だった）。これは「AI流入が減った」ことを意味するのではない。Cloudflareがorigin（自社サーバー）の手前で検証・処理を行っているため、origin側のログだけを見てもAI botトラフィックの実態は正確には測れない、という構造的な限界を示しているにすぎない。効果測定には、Cloudflare側の集計データを別途確認する必要がある。この点は誇張せず、限界として明記しておく。

WEBディレクターが9月15日までに確認すべきこと

今回の発表を受けて、実務的に確認しておくべき項目を整理する。

• 自サイトの契約プランを確認する。Freeティアであれば、既存サイトも含めて9月15日にデフォルトが変わる対象になる。有料契約であれば自動適用はされないが、今後のプラン変更時に挙動が変わる可能性は意識しておく
• Verifiedボットの一覧を、分類（Search/Agent/Training）ごとに見直す。「Verifiedだから許可されている」という前提を一度崩し、個別のボットがどの分類に属し、その分類が現在ブロックされていないかを確認する
• 広告表示ページとそれ以外のページで挙動が異なる点を把握する。今回のデフォルト変更は「広告表示ページ」に限定されているため、サイト全体の設計次第で影響範囲が変わる
• Google Extendedなど、マルチパーパスクローラーの個別制御が必要かどうかを検討する。SearchとTraining/Agentの両方に使われるボットは、一律の許可・拒否ではなく用途分離が推奨されている
• robots.txtのContent-Signal拡張を検討する。search=yes,ai-train=no,use=referenceのような記法で、search/ai-trainの可否と、use（immediate/reference/full）による利用範囲を細かく指定できる
• 9月15日より前にオプトアウトの要否を判断する。デフォルトのままでよいか、意図的に「ブロックしない」設定に変更するかを、自サイトのGEO戦略に照らして決めておく

経済モデルの新展開

今回の発表には、ブロック/許可という二択を超えた経済的な仕組みも含まれている。Pay Per Crawl（AIボットによるスクレイピングに対する課金）、Pay Per Use（コンテンツが実際に価値を生んだ時点で課金する方式、初期パートナーとしてCeramic.aiやYou.comの名前が挙がっている）、そしてMonetization GAteway（あらゆるコンテンツに課金できるようにする新機能、ウェイトリストが開始されている）だ。The Registerはこの動きを「Cloudflare to block cynical search-and-scrape bots from ad-supported web pages」と報じ、TechCrunchは「Cloudflare's new policy pushes AI companies to pay for publishers' content」と評している。ブロックか許可かという単純な二択から、「価値の対価を求める」という第三の軸が明確に立ち上がってきた1年だったと言える。

補足: Cloudflare以外の選択肢はどうなっているか

今回の刷新はCloudflare独自の動きに見えるが、AIクローラー対応という観点では業界全体が同じ方向に進んでいる。AWS WAFは、AIクローラーをエッジで検出し、単純なブロックではなく「課金対象のイベント」として扱う機能を組み込んでいる。すでにAWS上でサイトを運用している事業者にとっては、新しいベンダーを追加せずに同様の制御ができる点が特徴だ。Akamaiも、既存のBot Manager（署名ベースのStandardと、SDKによる端末フィンガープリンティングを伴う行動ベースのPremierの2ティア構成）を土台に、AIクローラーのマネタイズ機能を展開している。

Cloudflareは「Web全体のおよそ5分の1」の前に立つ立場から、クローラー側とパブリッシャー側の両方を見渡せる清算機関（クリアリングハウス）としてPay Per Crawlを主導してきた経緯がある。AWS・Akamai・Cloudflareの3社を並べて見えてくるのは、「AIクローラーをブロックするか許可するか」という二択から、「検出し、価値に応じて課金する」という方向へ、CDN/WAF業界全体が足並みを揃えつつあるという構図だ。自社がどのベンダーを使っているかに関わらず、この流れ自体は把握しておく価値がある。

実務メモ — Cloudflareダッシュボードで今すぐ確認すべき場所

ここまでの分類変更を踏まえ、実際に何をどう確認すればいいのか。Cloudflareの管理画面全体の詳細な操作手順は本記事執筆時点で筆者が実機検証したものではないため、UIのボタン名やメニュー階層まで断定はしない。ただし、公式発表や既存のBot管理機能の構造から論理的に導ける確認ポイントは以下の3点だ。

1. AIクローラーの分類設定を探す

Cloudflareのダッシュボードでは、従来から「Security」領域の配下にBot管理関連の設定が集約されている。今回のSearch／Agent／Trainingの三分類刷新も、この延長線上に実装されているはずだ。まずは自サイトのゾーン設定でSecurity関連メニューを開き、Bot管理・AIクローラー関連の項目に「三分類」を反映した表示や、カテゴリ別のallow／block切り替えができる箇所がないかを確認してほしい。項目名が刷新前後で変わっている可能性があるため、「AI Crawlers」「AI Bots」に類する名称の設定ブロックを目視で探すのが確実だ。

2. 個別ボットの「Verified」表示を確認する

archives/91で扱った37体の個別allow設定が、三分類刷新後にどう表示されているかは重要な確認事項だ。「Verified」の定義がDirect Access（Cloudflareが直接検証したボット）とIntermediary Access（サードパーティ経由の間接アクセス）に分かれた以上、従来一括りだった「Verified bot」表示が、どちらの区分に該当するかまで踏み込んで確認する必要がある。設定画面上でこの区分が明示されていない場合は、Cloudflareのサポートドキュメントやリリースノートで該当ボットの分類を照合するのが安全だ。

3. Monetization GAteway関連の課金設定に触れない

経済モデルの新展開に関連する設定（Pay Per Crawlやマネタイズ関連の機能）が同じSecurity領域内に混在している可能性がある。三分類の確認作業のついでに、意図せず課金を伴う設定をONにしてしまわないよう、変更を伴う操作の前には必ずステージング環境や設定の現状スクリーンショットを残してから触ることを勧める。詳細な操作手順が不明な項目については、断定的な手順を示すよりも、CloudflareダッシュボードのSecurity設定内で該当項目を探して公式説明文を読む、という誠実なアプローチを取ってほしい。

比較 — Cloudflare / AWS WAF / Akamai の「AIボット分類」アプローチ

3社を横並びで見ると、AIクローラー対策への向き合い方の違いが見えてくる。以下は本記事で参照した一次情報の範囲でまとめた比較であり、非公開の詳細は正直に「非公開」と記載する。

WEBディレクターとして押さえておきたいのは、「三分類のような体系立った公開情報を持つのはCloudflareが先行している」という点だ。AWS WAFやAkamaiを利用しているサイトでは、同等の分類粒度での確認ができない可能性が高く、その場合はログベースでUser-Agentを手動分類するといった代替手段の検討が必要になる。

用語集 — この記事に出てくる6つのキーワード

BotBase

Cloudflareが管理するボット識別・分類の基盤機能群を指す。今回のSearch/Agent/Training三分類も、このBotBase上の刷新として位置づけられる。

Content-Signal

コンテンツ提供者がクローラーに対して、自コンテンツの利用可否や利用目的（検索表示可・AI学習不可、など）を伝えるためのシグナル機構。robots.txtの拡張的な位置づけで語られることが多い。

Verified bot（検証済みボット）

Cloudflareが本人確認・出所確認を行った上でクロール許可を与えるボットの呼称。今回の刷新でDirect Access（Cloudflareが直接検証）とIntermediary Access（第三者経由の間接アクセス）に区分が分かれた点が最重要ポイント。

Signed agent（署名済みエージェント）

暗号署名によって身元が保証されたAIエージェント・クローラーのこと。archives/91で扱った37体の個別allow対象も、この署名済みエージェントの枠組みに連なる。

Pay Per Crawl

AIクローラーによるクロール1回ごとに課金を発生させる、Cloudflareが提供するマネタイズモデル。サイト運営者がコンテンツ利用の対価を得る仕組みとして位置づけられている。

Monetization GAteway

Pay Per Crawlを含む、AIクローラー由来トラフィックの収益化機能全般を束ねるゲートウェイ機能。経済モデルの新展開の中核をなす。

まとめ — 半歩先の責任は、標準化が進むほど重くなる

archives/86でCloudflareのデフォルトブロックに警告を鳴らし、archives/89・90でその流れが業界標準へと収斂していく過程を追い、archives/91で自サイトの実装まで完走させた。今回のContent Independence Day 2026は、その流れの「次のバージョン」だ。Verifiedの意味が変わったことは、当サイトが積み上げてきた37体のallowリストが「正しかったかどうか」を再検証する宿題を突きつけている。半歩先で警告した側には、半歩先で対応する責任がある——この通底テーマに従うなら、9月15日までにやるべきことは明確だ。分類ごとの見直し、Content-Signalの設定、そして何より、公式情報の更新を追い続けること。標準化が進むほど、警告した側の責任は軽くなるのではなく、むしろ具体的になっていく。

関連 archives（連載軸として読む）

• archives/86「Cloudflareのデフォルト『AI botsブロック』があなたのGEOを殺している」 ── 連載の起点、デフォルトブロックへの警告（2026-06-23）
• archives/89「機械が人間を超えた日」 ── Cloudflareが検証署名へ転換した最初の証跡（2026-06-28）
• archives/90「IETF WebBotAuth WG が発足した日」 ── 標準化機関誕生、三部作完結（2026-06-29）
• archives/91「Verified AI Agent 37体を個別allowした実装ログ」 ── 警告した側の実装責任を果たした記録（2026-06-30）

一次情報出典

• Cloudflare公式ブログ: Your site, your rules: new AI traffic options for all customers
• Cloudflare公式ブログ: Content Independence Day, one year on
• Cloudflare Changelog: New options to manage AI traffic
• Cloudflare Docs: Verified bots
• Cloudflare Docs: Signed agents
• The Register: Cloudflare to block cynical search-and-scrape bots from ad-supported web pages
• TechCrunch: Cloudflare's new policy pushes AI companies to pay for publishers' content
• StartupHub.ai: How to Monetize AI Bot Traffic in 2026: AWS, Cloudflare, and Akamai