Cloudflareが『価値』を可視化し始めた日 — BotBase と Attribution Business Insights、archives/93の一週間後に来た次の一手

archives/93の、わずか1日後

先日、当サイトでは「Cloudflareが『検証』の定義を変えた日」という記事で、Cloudflareが2026年7月1日に発表した"Content Independence Day 2026"を取り上げた。Search・Agent・Trainingという三分類への刷新、9月15日のデフォルト変更、「Verified」という言葉の意味そのものが変わったこと——WEBディレクターにとって決して小さくない転換点だった。

その記事を公開してから、たった1日である。Cloudflareは続報を出した。タイトルは"Content Independence Day, one year on: building the business model for the agentic Internet"。1年前に始まった「AIクローラーとどう向き合うか」という議論が、ちょうど1周年を迎えたタイミングで、次の一手を打ってきたのだ。

この記事では、archives/93の直系続報として、この新しい発表——BotBaseとAttribution Business Insights、そしてDirect vs Intermediary Accessという新しい区分——を扱う。結論から言えば、Cloudflareの視線は「ブロックするか、許可するか」という二択から、「そのボットは自分のサイトにどれだけの価値をもたらしているのか」を可視化する方向に、はっきりと踏み出している。

Content Independence Day, one年後——何が振り返られたのか

1年前の"Content Independence Day"は、WEBサイト運営者に「AIクローラーへのアクセス許可を自分で選べる権利」を返す、という宣言だった。それから1年が経ち、今回の"one year on"投稿は、その1年間で市場がどう動いたかの振り返りと、次のフェーズへの接続として位置づけられている。

当サイトのarchives/93で扱った通り、Cloudflareはこの1年の間に、AIクローラーの分類を「Search」「Agent」「Training」の三つに整理し直し、Verified AI Agentという概念を導入し、Content Signalsやsigned-agentsといった仕組みを積み上げてきた。今回の発表は、その積み重ねの上に「では、実際にそのアクセスはビジネス的にどれだけの価値があったのか」という、一段深い問いを持ち込んだものだ。

ブロックするかどうかの判断は、いわば「入口の管理」だった。今回追加された機能は、「入ってきたボットが、実際に何をもたらしたか」という、その先の話をカバーしようとしている。

なぜ今、「価値の可視化」なのか

WEBディレクターの立場で考えると、この流れは自然だ。robots.txtやWAFルールでAIクローラーを個別にallow/blockする運用は、この1年でかなり成熟してきた。しかし「blockした結果、何を失ったのか」「allowした結果、何を得たのか」を定量的に把握する手段は、これまでほとんど存在しなかった。当サイトがarchives/91で「37体のVerified AI Agentを個別allow」と宣言したときも、その先にあるのは「では、それぞれのボットが実際にサイトへ何をもたらしているのか」という疑問だった。Cloudflareの今回の発表は、まさにその疑問に答えるための機能だと言える。

この問いは、実はWEBディレクターにとって目新しいものではない。検索エンジンのクローラーに対しては、Google Search Consoleというツールを通じて「クロールされた結果、検索結果にどう表示され、そこからどれだけのクリックが生まれたか」を確認する習慣が、すでに何年も前から根づいている。AIクローラーに対しても、いずれ同じような「クロール→評価→改善」のサイクルが必要になるだろうということは、archives/93で三分類の刷新を扱った時点からある程度予想できたことでもある。今回のBotBaseとAttribution Business Insightsは、その予想を裏づける形で、Search Consoleに近い発想の機能をAIクローラー向けに用意しようとする動きだと理解できる。ただし、Search ConsoleがGoogleという単一の検索エンジン運営者による無料提供のツールであるのに対し、今回の機能はCDN/セキュリティベンダーであるCloudflareが、Enterprise向けの付加価値として提供する点は、性質が異なることも押さえておきたい。

BotBase — 検索可能なボット/エージェントのディレクトリ

新機能の一つ目はBotBaseである。これはCloudflareが追跡しているすべてのボット・AIエージェントを検索可能な形でまとめたディレクトリで、Enterprise Bot Management顧客はダッシュボードから直接閲覧できる。

これまでも、Cloudflareは「Verified Bots」というカテゴリを公式ドキュメントで定義していた。archives/93で扱ったSearch/Agent/Trainingの三分類も、この延長線上にある。BotBaseは、その定義を「読み物」から「検索できる実用ツール」に格上げしたものと理解するのが妥当だろう。

WEBディレクターにとっての意味は明確だ。「このUser-Agentは何者なのか」「このクローラーはどのカテゴリに属し、どんな目的でアクセスしてくるのか」を、ログを漁って推測するのではなく、公式のディレクトリで直接調べられるようになる。これはアクセスログ解析の手間を減らすだけでなく、allow/blockの判断根拠を「推測」から「参照可能な事実」に変える動きでもある。

Attribution Business Insights — allow/blockの先にある「価値の可視化」

今回の発表でより本質的なのは、こちらのAttribution Business Insightsだ。これは、各クローラーがサイトにもたらしている「ビジネス価値」を可視化するダッシュボード機能である。

これまでのボット管理は、突き詰めれば「このボットを通すか、止めるか」という二値判断だった。Attribution Business Insightsは、そこに三つ目の軸を持ち込む。「通した結果、何が起きたのか」という帰属（attribution）の可視化だ。

単純なallow/blockから、マネタイズ/ROI測定へ

これは、コンテンツ運営者にとって発想の転換を迫るものだと言える。従来の判断基準は主に「セキュリティ」と「サーバー負荷」だった。悪意あるスクレイパーは止める、正規のSearchクローラーは通す、という比較的シンプルな線引きである。

Attribution Business Insightsが持ち込むのは、「このAIクローラーを通した結果、実際に自社サイトへのビジネス上のリターンがあったのか」という視点だ。AI Overviewやチャットボットの回答に自社コンテンツが引用され、そこから実際にユーザーが流入したのか。あるいは、学習用途で一方的にデータを持っていかれているだけなのか。この違いを、感覚ではなくダッシュボード上の数字で確認できるようになる、というのがこの機能の狙いだと考えられる。

WEBディレクターの日常業務に引き寄せると、これはGoogle Search Consoleでクリック数やインプレッションを確認するのと同じ発想を、AIクローラー相手にも適用しようとする試みだ。ただし対象がAIエージェントである以上、「クリック」に相当する指標が何なのか、どこまで正確に帰属を追跡できるのかは、今後の実装次第という面もあるだろう。

ダッシュボードで実際に何が見えるのか — Changelogが明かした指標

「価値の可視化」と言われても、具体的にどんな数字が画面に並ぶのかが分からなければ、実務的なイメージは湧きにくい。Cloudflare公式Changelogの記載を確認したところ、Attribution Business Insightsのダッシュボードには、以下の要素が含まれることが分かった。

この中で特に注目したいのが「crawl-to-referral ratio」だ。これは、あるボットがどれだけクロールしてきたかという量と、そのクロールが実際にユーザーの参照（リファラー経由のアクセス）にどれだけつながったかという比率を突き合わせる指標である。当サイトはarchives/83で、クローラーのアクセス数とリファラー経由の流入数を比較する視点をすでに扱っていたが、今回Cloudflareが公式にこの比率をダッシュボードの主要指標として採用したことで、同じ発想が業界標準に近い位置づけを得たと言える。

また、集計期間が24時間・7日間・30日間の3段階で用意されている点も実務的だ。allow/block設定を変更した直後の短期的な影響（24時間）と、中長期的な傾向（30日間）の両方を見比べられる設計になっている。ただし、これらの情報はあくまでCloudflare公式Changelogの文章記載から確認できる範囲であり、実際のダッシュボード画面のキャプチャやUIの操作手順そのものは、Enterprise Bot Management契約者以外の当サイトからはまだ確認できていない。ここは正直に断っておきたい。

Direct vs Intermediary Access — 「推移的信頼」という新しい問題

三つ目の要素が、新しいメタデータ区分Direct vs Intermediary Accessである。これは、あるボットが「所有者自身が直接運用しているアクセス」なのか、それとも「多数のエンドユーザーの代理として動くエージェント」なのかを区別する仕組みだ。

Direct Access（直接アクセス）

ボットの所有者（企業・組織）自身が、自らの目的のために直接アクセスしてくるケース。従来のクローラーの多くがこれに該当する。

Intermediary Access（仲介アクセス）

AIエージェントが、多数のエンドユーザーの「代理」として動作し、個々のユーザーの指示でサイトにアクセスしてくるケース。ChatGPTやClaudeのようなAIアシスタントが、ユーザーの質問に答えるためにWebページを取得する場合などが該当しうる。

「推移的信頼（transitive trust）」という論点

ここでCloudflareが提起しているのが「推移的信頼（transitive trust）」という概念だ。仲介者（AIエージェントの運営企業）自体は信頼できる相手かもしれない。しかし、そのエージェントを実際に駆動しているのは、無数のエンドユーザーである。仲介者を信頼することと、その仲介者を動かしている全エンドユーザーの意図まで信頼することは、本来別の話だ——という問題設定である。

これはarchives/93で扱った「Verified」の定義変更とも地続きの話だと言える。従来「Verified AI Agent」という言葉は、比較的単純に「その企業が運営する正規のボットである」ことを意味していた。しかしDirect vs Intermediary Accessの区分が持ち込まれることで、「verifiedかどうか」だけでなく「誰の代理として、何の目的で来ているのか」という、もう一段深い階層の情報が必要になる。

この課題への技術的なアプローチとして、CloudflareはForwardedヘッダー（RFC 7239）を用いて、エンドユーザーに関する情報を転送する実験を行っている。RFC 7239はもともとプロキシ経由のリクエストで、元のクライアント情報を後段のサーバーに伝えるための標準的な仕組みだ。これをAIエージェント経由のアクセスに応用し、「このリクエストは、どのエンドユーザーの意図によるものか」という情報をサイト側に伝えようとしている、というのが現時点でわかっている内容である。

この「推移的信頼」という論点は、抽象的な議論に聞こえるかもしれないが、WEBディレクターの実務にとっては意外と身近な問題設定でもある。たとえば、社内で複数の担当者が共有アカウントを使ってツールにアクセスしている場合、「そのツールのベンダーは信頼できるか」という判断と、「そのアカウントを使う個々の担当者の操作すべてを無条件に信頼できるか」という判断は、本来別のレイヤーの話だ。AIエージェントとエンドユーザーの関係も、これと構造的に似ている。仲介者（AIエージェントの運営企業）を信頼するという判断と、そのエージェントを通じてアクセスしてくる個々のリクエストの意図まで無条件に信頼するという判断を、Cloudflareは今回、明確に切り分けて扱おうとしている。この切り分けが技術的にどこまで実現できるのか、Forwardedヘッダーによる情報転送がどの程度の粒度でエンドユーザーの意図を伝えられるのかは、現時点の一次情報だけでは判断がつかない部分であり、今後の実装の進展を待つ必要がある。

WEBディレクターが今すぐ確認すべきこと

ここまでの内容を踏まえて、今の時点で現実的にできること・できないことを正直に整理しておきたい。

つまり、今回の発表は現時点ではEnterprise契約者を主な対象としており、多くの中小規模サイト運営者がすぐに触れる機能ではない可能性が高い。ここは誠実に書いておく必要がある。ただし、方向性としては確実に押さえておくべきものだ。

• 自社のCloudflareプランを確認する: 今後Attribution Business Insightsのような機能がどのプラン層まで降りてくるのか、契約プランと機能範囲を定期的にチェックしておく。特に、Enterprise Bot Managementがオプション追加という形で提供されているのか、上位プランに標準搭載される形で提供されているのかは、コスト試算にも直結するため、営業窓口や公式ドキュメントの更新を確認しておきたい
• 「価値の可視化」という発想を先取りする: 機能が使えなくても、自サイトのAI Overview引用状況やAI経由の流入を、Google Search ConsoleのAI関連指標やGA4のリファラー分析で、できる範囲で自前計測しておく。allow/blockの設定変更のたびに、その前後でこれらの指標がどう動いたかを記録しておけば、Attribution Business Insightsが提供する情報の一部を、粗い精度ではあっても自前で近似できる
• BotBaseの一般公開有無を継続ウォッチする: 検索可能なボットディレクトリは、Enterprise以外にも展開される可能性がある。公式Changelogを定期的に確認する価値がある。過去の実績を振り返ると、Cloudflareは新機能をEnterprise向けに先行公開し、その後に段階的に下位プランへ展開するというパターンを取ることが多いため、Changelogのウォッチは今後も有効な情報源になり得る
• Direct/Intermediary Accessの一般提供に備えて、自社のUser-Agent対応表を整理しておく: archives/91で当サイトが行ったような個別allow設定は、Direct/Intermediaryという新しい区分が一般提供された段階で、見直しが必要になる可能性がある。今のうちに「どのボットを、どんな理由でallowしているか」を一覧化しておけば、区分が追加された際の対応がスムーズになる

この発表が示す、次のコンテンツ戦略への示唆

ここまでの内容を踏まえて、機能そのものが使えるかどうかとは別に、この発表が示している方向性から、コンテンツ戦略上の示唆をいくつか引き出しておきたい。あくまで当サイトの編集上の見解であり、Cloudflare公式が明言している内容ではない点を断っておく。

第一に、「AIクローラーにコンテンツを読ませること自体が目的化してはいけない」という当たり前の教訓が、今回の発表によってあらためて強調された形になる。Attribution Business Insightsが測ろうとしているのは、あくまで「クローラーを通した結果、ビジネス上の価値があったかどうか」であって、「クローラーに読まれた回数」そのものではない。AI Overviewやチャットボットの回答に頻繁に引用されていても、そこからの実際の流入やブランド認知への貢献が乏しければ、今後は「価値の低いアクセス」として扱われる可能性がある。GEO・AEOという言葉が先行して広まった結果、「引用されること」自体をゴールにしてしまいがちな風潮に対して、Cloudflareのこの発表は、静かに軌道修正を促しているようにも読める。

第二に、Direct vs Intermediary Accessという区分は、コンテンツの書き方そのものにも間接的な影響を及ぼす可能性がある。Intermediary Access、つまりエンドユーザーの代理としてAIエージェントがアクセスしてくるケースが今後さらに増えるのであれば、コンテンツは「検索エンジンのクローラーに読まれる」ことだけでなく、「エージェントが特定のユーザーの質問に答えるために、正確に引用できる」ことも意識して構成する必要が出てくる。これはE-E-A-Tや構造化データといった、当サイトがこれまで繰り返し扱ってきたテーマとも重なる論点であり、今回の発表を機に、あらためてその重要性が裏付けられたと言える。

self-proof: 当サイトは今、何を確認できているか

当サイトはarchives/91で、Verified AI Agentのうち37体を個別allowする設定を実装し、archives/93ではSearch/Agent/Training三分類への対応状況を自己開示した。今回のBotBaseとAttribution Business Insightsについても、同じ姿勢で正直に書いておきたい。

🔧 着手中 BotBase / Attribution Business Insightsの検証: 当サイトが現在利用しているCloudflareプランでは、これらの機能がEnterprise Bot Management向けであるため、ダッシュボード上でまだ確認できていない。運営者・池田南美夫と相談の上、プラン内容と機能提供範囲を確認し、利用可能になった際には改めてこの記事、または続報で実際のダッシュボード画面と合わせて報告する。

🔧 着手中 Direct vs Intermediary Accessへの対応: この区分自体が実験段階の機能であり、当サイト側で今すぐ設定できる項目は現時点で確認されていない。Forwardedヘッダーの一般提供が始まった段階で、archives/91のallow設定と合わせてどう組み合わせるべきか検討する。

正直に言えば、今回の記事は「まだ使えていない機能」についての解説記事という性格が強い。それでも、archives/93で扱った検証定義の変更と地続きの流れとして、早い段階で構造を理解しておくことには意味がある。allow/blockの判断だけでなく「その先に何を測るべきか」という視点を、機能が使えるようになる前から持っておきたい。

まとめ

Cloudflareは、archives/93で扱った"Content Independence Day 2026"のわずか1日後に、次の一手としてBotBaseとAttribution Business Insightsを発表した。ボットを「通すか止めるか」という入口の管理から、「通した結果どんな価値があったのか」という出口の可視化へ——この流れは、AIクローラー対応がセキュリティの話から、マーケティング・ROI測定の話へと領域を広げつつあることを示している。

Direct vs Intermediary Accessが提起する「推移的信頼」の問題は、archives/93の「Verified」定義変更ともつながる、今後も注視すべき論点だ。今回はEnterprise向け機能が中心で、多くのサイト運営者がすぐに触れられるものではない。しかし、この一週間で立て続けに起きた「分類の刷新」→「価値の可視化」という流れそのものは、WEBディレクターが押さえておくべき地図の更新だと言える。

今回の記事で扱った内容の多くは、現時点では「今すぐ自社サイトで設定を変える」種類の話ではない。Enterprise Bot Managementという契約の壁があり、Direct vs Intermediary Accessは実験段階にとどまっている。それでも、この記事をここまで書いてきたのは、archives/86からarchives/93までの警告・検証・実装の積み重ねと同じく、「まだ使えない機能」の構造を早い段階で理解しておくことに意味があると考えているからだ。allow/blockという入口の管理を終えた次に、「通した結果の価値をどう測るか」という出口の設計が来る——この順番自体を、機能が降りてくる前から頭に入れておきたい。以下、補足として実務上のヒントと、archives/93との接続を整理した比較、用語集、そしてこの1年の動きを俯瞰する年表を付け加える。

実務メモ — Enterprise未契約サイトが今日から確認できること

ここまで見てきた通り、BotBaseとAttribution Business InsightsはEnterprise Bot Management顧客向けの機能として発表されている。当サイトを含む多くの中小規模サイトの運営者にとって、「では自分たちはダッシュボードで何も確認できないのか」という疑問が残る。結論から言えば、今回発表された新機能そのものには触れられないが、Cloudflareが一般提供している既存の機能の中にも、同じ方向性——「どのボットが、どれだけ来ていて、何をもたらしているのか」を把握するための手がかりは、いくつか存在する。ここでは、Enterprise契約の有無にかかわらず確認できる可能性がある3つのアプローチを、誠実な範囲で整理しておきたい。

① Bot Fight Mode / Super Bot Fight Modeの設定とログを見直す

Cloudflareの無料〜Proプランでも、Bot Fight Modeという基本的なボット対策機能が提供されている（より上位のプランではSuper Bot Fight Modeとして、カテゴリ別の制御が可能になる）。ここで確認できるのは、あくまで「怪しいボットをどれだけブロックしたか」という防御寄りの情報が中心であり、Attribution Business Insightsが目指すような「ビジネス価値の可視化」とは性質が異なる。それでも、Verified Botsとして許可されているカテゴリと、そうでないカテゴリの挙動の違いを、自分のダッシュボード上で見比べておくことには意味がある。今回のBotBaseが目指す「検索可能なボットディレクトリ」の考え方を先取りする形で、自サイトにアクセスしてきているUser-Agentの一覧を、まずは手元で棚卸ししておくアプローチだ。

② Security Analyticsでボットカテゴリ別の推移を確認する

Cloudflareダッシュボードの「Security」→「Analytics」（または相当するアクセス解析画面）では、リクエストをボットスコアやカテゴリ別にフィルタして時系列で見ることができる場合がある。ここでAI関連クローラーに該当しそうなカテゴリのアクセス推移を定期的に確認しておけば、Attribution Business Insightsが一般提供された際に「自分のサイトでは、どのタイミングからAIクローラーのアクセスが増減しているか」という前提情報として役立つはずだ。ただし、この画面で確認できるのはあくまでアクセス量の推移であり、「そのアクセスが実際にビジネス上のリターンをもたらしたか」というAttributionの部分までは、現状の一般提供機能だけでは追いきれない点は、正直に書いておく必要がある。

③ robots.txtとアクセスログを突き合わせて「素通り」しているボットを探す

もう一つ、Enterprise機能に頼らずにできることとして、自サイトのrobots.txtで許可・拒否しているUser-Agentの一覧と、実際のアクセスログ（またはCloudflareのログ機能で取得できる範囲のアクセス記録）を突き合わせる作業がある。robots.txtで名前を挙げていない未知のボットが継続的にアクセスしてきていないか、逆にVerified Bots相当だと思われるクローラーが、想定よりも低い頻度でしかアクセスしていないかを探ることで、BotBaseが提供しようとしている「このUser-Agentは何者か」という情報の一部を、手作業に近い形で代替できる。当サイトも archives/91 で37体のVerified AI Agentを個別allowした際、アクセスログの目視確認を行った実績がある。BotBaseが一般提供されれば、この作業のかなりの部分が置き換えられることになるだろう。

④ Search ConsoleとGA4の指標を、ボットのカテゴリ分けと重ねて読む

Cloudflare側の機能とは別軸になるが、Google Search Consoleのクリック・表示回数の推移と、GA4で計測できるリファラー由来の流入を、archives/93で扱ったSearch/Agent/Trainingの三分類、あるいは今回のDirect/Intermediary Accessの考え方と突き合わせて読む、という視点もある。たとえば「AI検索エンジン経由と思われる参照元からのアクセスが増えている時期」と「Cloudflare側でVerified Bot扱いのクローラーのアクセスが増えている時期」が一致するかどうかを、自前のアクセス解析ツールの範囲で観察しておく。これはAttribution Business Insightsが提供しようとしている機能そのものではないが、「クローラーのアクセス」と「実際のユーザー流入」という2つのデータソースを自分の手で突き合わせるという発想自体は、今回の発表が示す方向性と地続きだと言える。

いずれの方法も、Attribution Business Insightsが提供しようとしている「ビジネス価値の可視化」そのものを再現するものではない。あくまで、その考え方に近づくための代替的な観察手段にとどまる、という点は誠実に断っておきたい。それでも、機能が降りてくる前に「自分のサイトにどんなボットが、どれくらい来ているのか」を把握しておくことは、後々の判断を早めるための土台になるはずだ。Enterprise契約という壁の向こう側で何が計測されようとしているのかを理解しておけば、いざ自社のプランでも同種の機能が使えるようになったときに、何を、どう見ればいいのかで迷わずに済む。機能を待つ間の準備運動として、この4つのアプローチを位置づけておきたい。

比較 — 「Verified bot」の旧定義と新定義（archives/93との接続）

archives/93では、Cloudflareが2026年7月1日の"Content Independence Day 2026"で、Verifiedという言葉の意味そのものを変えたことを扱った。今回のBotBaseとAttribution Business Insightsの発表は、その延長線上で、「verified」という判定がどう使われるのかという運用面の変化として読むことができる。ここで一度、旧アプローチと新アプローチを並べて整理しておきたい。

こう並べてみると、archives/93で扱った「Verifiedの意味変更」は、単なる用語の言い換えではなく、その後に続くAttribution Business Insightsのような機能が乗ってくるための土台づくりだったことが見えてくる。まず「誰が、どういう立場でアクセスしてきているか」を精緻に区分できるようにし（Search/Agent/Training、そしてDirect/Intermediary）、その上で「その区分ごとに、実際どれだけの価値があったのか」を測定する——という二段構えの設計だ。archives/93を読んだ時点では「分類が変わっただけ」に見えたかもしれないが、1週間後の今回の発表を踏まえると、その分類変更自体が、価値測定のための布石だったと捉え直すことができる。

WEBディレクターの実務にとって、この変化が意味するのは「一度allow/blockを設定したら終わり」という運用では、もう十分ではなくなりつつあるということだ。archives/91で当サイトが37体のVerified AI Agentを個別allowしたときの判断基準は、主に「このボットはどのカテゴリに属し、悪意のあるアクセスではないか」という、いわば入口の安全確認だった。しかし今回の発表を踏まえると、次の段階では「allowしたボットが、実際に自社サイトの露出やAI引用にどう貢献しているのか」を継続的に観察し、必要であれば設定を見直していく、という運用サイクルが求められることになるだろう。これは一度きりの設定作業から、継続的なモニタリング業務への移行を意味している。

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

BotBase

Cloudflareが追跡しているボット・AIエージェントを検索可能な形でまとめたディレクトリ機能。Enterprise Bot Management顧客がダッシュボードから直接参照できる。従来「読み物」として提供されていたVerified botsの定義を、実務で引きやすい検索可能な形に格上げしたものと位置づけられる。WEBディレクターの視点で言えば、アクセスログに現れる未知のUser-Agentを推測ではなく公式データベースで照合できるようになる点が、実務上の最大の意味だと考えられる。

Attribution Business Insights

各クローラー・AIエージェントがサイトにもたらしているビジネス価値を可視化するダッシュボード機能。「通すか止めるか」の判断だけでなく、「通した結果、実際にどんなリターンがあったのか」という帰属（attribution）の測定を狙う。Enterprise Bot Management顧客向けに発表された。従来はセキュリティ・サーバー負荷の観点でしか語られなかったボット管理に、マーケティング・ROI測定という新しい評価軸を持ち込む機能だと言える。

Transitive Trust（推移的信頼）

Direct vs Intermediary Accessの区分から生まれた論点。AIエージェントの運営企業（仲介者）自体は信頼できる相手だとしても、そのエージェントを実際に駆動しているのは無数のエンドユーザーであり、仲介者への信頼がエンドユーザー全員の意図への信頼をそのまま意味するわけではない、という問題設定を指す。archives/93で扱った「Verified」の定義変更は、この推移的信頼という論点を扱うための前段の区分整理だったと捉えることができる。

Forwardedヘッダー（RFC 7239）

プロキシ経由のリクエストにおいて、元のクライアント情報を後段のサーバーに伝えるための標準的なHTTPヘッダーの仕様。Cloudflareは、AIエージェント経由のアクセスにおいて「どのエンドユーザーの意図によるリクエストか」という情報を転送するための実験的な応用として、このヘッダーを用いていると報告している。一般的なプロキシ・CDN構成で古くから使われてきた仕組みを、AIエージェント時代の信頼区分という新しい文脈に転用している点が興味深い。

年表 — この1年、この1週間で何が起きたか

今回の発表を正しく位置づけるために、当サイトがこれまで報告してきたCloudflare関連の動きを、時系列で改めて並べておきたい。すべて当サイトの既発記事で扱った内容であり、新しい統計や外部データを付け加えるものではない。

こうして並べてみると、archives/86での警告から今回のarchives/94まで、当サイトはCloudflareのAIクローラー対応の変化をほぼリアルタイムで追い続けてきたことになる。特にarchives/93と今回のarchives/94の間隔が「わずか1日」だった事実は、この領域の動きがどれだけ速いかを物語っている。WEBディレクターとして一次情報を継続的に追うことの意味は、まさにこの「1日でも動きを見逃すと、次の発表の文脈がつかめなくなる」というスピード感にある。

統計 — 「非人間トラフィック」はどこまで進んでいるか

ここまで「価値の可視化」という発想の転換を扱ってきたが、そもそもAIクローラーが現在どれだけの規模でWEBサイトにアクセスしてきているのか、Cloudflare自身が公表している数字を確認しておきたい。今回参照している一次情報（Cloudflare公式ブログ「Content Independence Day, one year on」）には、以下の統計が示されている。

この数字が示しているのは、「AIクローラーの存在感が増している」という漠然とした印象ではなく、すでにインターネットトラフィックの主役が人間から非人間へと入れ替わりつつある、という具体的な変化だ。AI訓練目的のクローラーリクエストが1年強で22%から52%へと倍増以上に伸びた事実は、archives/86でこの領域を最初に警告した時点から今回のarchives/94に至るまで、当サイトが一貫して扱ってきた「入口の管理だけでは足りなくなる」という論旨を、数字の面からも裏づけている。BotBaseやAttribution Business Insightsのような「価値の可視化」機能が今のタイミングで出てきた背景には、この非人間トラフィックの急増があると理解するのが自然だろう。

なお、この統計はあくまでCloudflareのネットワークを経由するトラフィックに基づくものであり、インターネット全体を代表する数字と断定できるわけではない点は、誠実に断っておきたい。それでも、Cloudflareが世界的に広く使われているCDN/セキュリティサービスであることを踏まえれば、業界全体の傾向を示す有力な参考値として扱ってよいはずだ。

代替手段 — Cloudflare以外でAIクローラーを管理する方法

今回扱ったBotBaseとAttribution Business Insightsは、Cloudflareという特定のCDN/セキュリティベンダーが、Enterprise向けに提供する機能である。「Cloudflareを使っていない、あるいはEnterpriseプランではないサイトはどうすればよいのか」という疑問に、現時点でわかっている範囲で正直に答えておきたい。

① robots.txtによる自前管理

どのCDN・ホスティング環境であっても、robots.txtでUser-Agentごとにクロール許可・拒否を宣言する方法は変わらず有効だ。archives/91で当サイトが行った37体の個別allow設定も、根本にはこのrobots.txtとWAFルールの組み合わせがある。Cloudflareを使っていなくても、robots.txtでAIクローラーへの意思表示自体は可能だ。ただし、宣言した内容が実際に守られているかを確認する手段（BotBaseのような検索可能なディレクトリ）は、Cloudflare以外のベンダーでも同等のものが提供されているかどうか、今回参照した一次情報の範囲では確認できていない。

② 他のCDN/WAFベンダーのボット管理機能

Fastly・Akamaiをはじめとする大手CDN/セキュリティベンダーも、一般にボット管理・WAF機能を提供している。ただし、今回当サイトが参照したCloudflare公式ブログおよびHelp Net Securityの記事のいずれにも、これら他ベンダーの具体的な機能や、Attribution Business Insightsに相当する「AIクローラーの価値可視化」機能についての言及は見当たらなかった。他ベンダーが同種の機能を持っているかどうかは、現時点の一次情報からは確認できない、というのが正直なところだ。断定的な比較表を作るには材料が不足しているため、ここでは「Cloudflare以外にも選択肢としてCDN/WAFベンダーは存在するが、価値可視化という切り口での機能比較は今後の続報を待ちたい」という留保付きの整理にとどめる。

③ Google Search Console + GA4による自前の近似計測

本文の実務メモでも触れた通り、Cloudflareの新機能に頼らずとも、Google Search ConsoleのクリックデータとGA4のリファラー分析を組み合わせることで、AIクローラー経由の流入を粗い精度で近似計測することはできる。これはCloudflare・Fastly・Akamaiのどれを使っていても実行可能な、ベンダー非依存のアプローチだ。Attribution Business Insightsのような専用ダッシュボードには及ばないが、今この瞬間から始められる代替手段として、あらためて位置づけておきたい。

結論として、「Cloudflare以外で同等の価値可視化機能を使う具体的な手順」を今回示すことはできない。しかし、robots.txtによる意思表示、他ベンダーのWAF機能の活用、Search Console/GA4による自前計測という3つのアプローチを組み合わせることで、Cloudflareの新機能が一般提供されるまでの間、方向性としては近い取り組みを始めることができる。

よくある質問（FAQ）

Q. BotBaseとAttribution Business Insightsは、今すぐ自分のサイトで使えますか？

A. 現時点ではEnterprise Bot Management顧客向けの機能として発表されており、一般のCloudflareプランではまだ利用できない可能性が高いです。当サイトも同様の理由で、まだ実際のダッシュボード画面を確認できていません。

Q. Enterprise未契約でも、今からできることはありますか？

A. あります。本記事の「実務メモ」セクションで整理した通り、Bot Fight Mode設定の見直し、Security Analyticsでのボットカテゴリ別推移確認、robots.txtとアクセスログの突き合わせ、Search Console・GA4での自前近似計測の4つは、Enterprise契約の有無にかかわらず着手できます。

Q. archives/93との違いは何ですか？

A. archives/93はSearch/Agent/Trainingという「分類」の刷新と、Verifiedという言葉の「意味変更」を扱いました。本記事（archives/94）はその1日後に発表された続報で、分類された後のボットが「実際にどれだけの価値をもたらしているか」を可視化する機能（BotBase・Attribution Business Insights）を扱っています。分類が土台、価値可視化がその上に乗る次の階層、という関係です。

Q. 当サイト自身はこの機能を使っていますか？

A. 使えていません。本記事のself-proofセクションで正直に開示している通り、当サイトが利用しているCloudflareプランではEnterprise Bot Management向けの今回の新機能を確認できておらず、🔧着手中のバッジを付けています。利用可能になり次第、続報で報告します。

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

• archives/93「Cloudflareが『検証』の定義を変えた日」 — 本記事の直系の前身。Search/Agent/Training三分類の刷新とVerifiedの定義変更を扱った
• archives/91「Verified AI Agent 37体、個別allow実装ログ」 — 当サイトが実際にVerified AI Agentを個別allowした実装記録
• archives/90「IETF WebBotAuth WGが発足した日」 — ボット検証の標準化が始まった経緯を扱った記事
• archives/89「機械が人間を超えた日」 — Cloudflareの「検証署名」への転換を扱った、三部作の起点の続編
• archives/86「Cloudflareのデフォルト『AI botsブロック』があなたのGEOを殺している」 — インフラ層でのAIクローラーブロックの問題を最初に警告した記事

一次情報出典

• Cloudflare公式ブログ「Content Independence Day, one year on: building the business model for the agentic Internet」
• Cloudflare Changelog「BotBase and Attribution Business Insights」
• Help Net Security「Cloudflare's new AI crawler controls」
• Cloudflare公式ドキュメント「Verified bots」