AIのクローラーをどこまで通すかは、もうサーバー担当者だけの設定ではありません。記事を出している側にとっては、読まれ方と流入の両方に関わる判断です。Cloudflareは公式ブログで、同社が「Verified bots」として認めたボットについて、身元を確かめて一覧に載せるだけでは足りない、という整理を公表しました。認めたあとも行動を継続して観察し、その結果を帯の形で示すという内容です。
発表の中では、運転免許のたとえが使われています。免許は、その人が誰であるかと、試験に通ったことを示します。けれども、これから責任ある運転をするかどうかまでは示しません。ボットも同じで、身元が分かることは説明責任の出発点にすぎない、というのが今回の主張です。
この記事では、公式ブログと公式ドキュメントに書かれている範囲で、何が加わるのか、サイトを運営する側と、自社でクローラーやAIエージェントを動かす側のそれぞれに何が起きるのかを整理します。確認日は2026年10月21日です。英語の原文を訳しているため、日本語の資料や管理画面では語が違うことがあります。
身元の確認だけでは足りない、という整理
公式ブログは、Verified bot であるための条件を3つ挙げています。正確かつ安全に自分が誰かを名乗ること、名乗ったとおりのことだけを行うこと、そして乱暴な振る舞いをしないことです。名乗る手段としては、Web Bot Auth による署名で要求に身元を載せ、それを BotBase が公開された形式で目録にする、と説明されています。
公式ドキュメントの側は、同じ内容をもう少し事務的に書いています。認定の条件は2つで、1つは決まった形で身元を示すことです。手段として挙がっているのは、Web Bot Auth の署名、公開したIPリストと安定したユーザーエージェントの組み合わせ、逆引きDNSの3つです。もう1つは乱暴でないことで、robots.txt とクロールの指示に従い、無理のない要求の頻度を保ち、サイト運営者の意向をすり抜ける動きが観測されていないこと、と書かれています。
ここまでは以前からの決まりです。今回加わるのは、認定を受けたあとの行動を測り続ける仕組みです。ブログの言い方では、身元が分かることと、そのボットが責任ある動き方をすることは別の話だ、という問題意識から来ています。
「リスク」と「信頼」は別のものとして測られる
発表で最も実務に効くのは、リスクと信頼を分けて定義している部分です。リスクは、ある要求やある時点の行動が有害でありうる見込みを指し、刻々と変わるものとされています。これに対して信頼は、繰り返された一貫した行動によって、時間をかけて築かれるものと説明されています。
その上でCloudflareは、観測した行動を「説明できる信頼の帯」にまとめるとしています。帯は、そのボットがサイトの意向をどれだけ一貫して尊重しているかの幅を示し、どの観測がその判断の材料になったかを併せて示すものだと書かれています。そのボットや運営者に対する永続的な評価ではないとも明記されています。悪かった相手が永久に悪いままになる仕組みではない、ということです。
点数ではなく帯で、しかも理由つきで示す、という設計は、受け取る側にとって重要です。数字だけを渡されても、サイトの運営者は何を直せばよいか分かりません。どの行動がその判断につながったのかが添えられていれば、ボットを動かしている側は直せますし、サイトの側は自分の表明が効いているかを確かめられます。
最初に見られる信号は2つ
最初に評価される信号として挙がっているのは2つです。1つ目は、ボットが指示を尊重しているかどうかです。ここでいう指示はまず robots.txt で、サイト運営者の意向を伝える主要な方法だと書かれています。期待されているのは、責任あるボットが、サイトが公開している意向を確認してそれを尊重することで、RFC 9309 に沿う形だと説明されています。
評価の仕方には幅が持たせてあります。観測された通信が、公開された意向と時間を通して一致しているかを見る形で、単発の違反ではなく、意向を無視する行動が繰り返される型に目を向けると書かれています。1回の行き違いで失格にはしない、という作りです。
2つ目は、直接の合図に反応したかどうかです。サイトが押し返す最も分かりやすい方法として HTTP 429、つまり「Too Many Requests」の応答が挙げられています。見るのは、その応答を受けたあとに通信が変わるかどうかです。速度を落とすのか、いったん止まるのか、それとも同じ勢いのまま要求を送り続けるのか、と書かれています。
2つの信号に共通するのは、サイト側が何も表明していなければ、観察そのものが成り立たないことです。robots.txt を置いていなければ、意向に沿っているかどうかは測れません。混雑しても常に応答を返し続けていれば、相手が合図に反応する種類のボットなのかも分かりません。評価される側はボットですが、材料を出しているのはサイトの側です。
守らなかったボットに起きること
公式ドキュメントは、認定の条件を満たさなくなったサービスを、全体の許可リストから外すと書いています。外される例として挙がっているのは、次のようなものです。
| 方針違反として挙がっている例 | 何が問題とされているか |
|---|---|
| 認定したサービス専用ではないIPを追加する | 他の用途の通信が、認定された名前で通ることになる |
| サービスのIPが攻撃者に奪われる | 名乗りと実際の送信元が一致しなくなる |
| 修正されていない脆弱性が残っている | 認定された経路が、そのまま悪用の経路になりうる |
| 登録時に申告していないIPの帯を足す | 事前の申告と運用の実態がずれる |
| 公表した目的が、実際の通信と合っていない | 名乗ったとおりのことだけを行う、という条件を外れる |
| robots.txt の crawl-delay を守らないAIクローラー | 要求の頻度に関する指示を尊重していない |
ブログの側には、実際に外した例も書かれています。2025年に Perplexity のボットを一覧から外したという記述で、理由は、収集を拒否しているサイトの資料へアクセスしようとし、さらに制御をすり抜けようとしたことだとされています。認定は、取り消される前提のものとして扱われていることが分かります。
サイトを運営する側に起きる変化
いまのところ、この仕組みはCloudflareの内部で動いています。ブログには今後の予定が2つ書かれていて、1つはスコアを Radar で公開すること、もう1つはすべての顧客が、Verified bot の通信をどう扱うかを決めるための信頼のしきい値を選べるようにすることです。
これが実現すると、サイト運営者の選択肢の形が変わります。これまでのAIクローラーへの対応は、通すか止めるかの二択に寄っていました。しきい値を選ぶ形になると、問いは「どのくらい一貫して意向を守る相手までなら通すか」に変わります。AI検索からの流入を取りに行くのであれば一律の遮断は選びにくく、かといって全部を通すと、読み取られる量ばかりが増えます。
その判断には、自社側の実測が要ります。読み取られた量と、そこから戻ってきた訪問を並べて見る方法はMicrosoft Clarityが収集と流入を1つの指標に。AI Scrape-to-Referral Ratioで、AI検索経由の流入を事業の側から見た例はAI検索からの流入は別チャネル。Shopifyが出した2026年の実測データで扱っています。遮断の設定を触る前に、自社でどちらがどれだけ動いているかを見ておいたほうが、決め方に根拠が残ります。
自社がクローラーを動かす側になっていないか
もう一方の立場も考えておく必要があります。価格の調査、競合の監視、社内向けの要約、そして自社で動かすAIエージェント。これらはいずれも、外部のサイトから見ればボットの通信です。評価される側の条件は、大企業のクローラーと同じ文面で書かれています。
公式ドキュメントが求めているのは、決まった形で名乗ること、robots.txt とクロールの指示に従うこと、無理のない頻度を保つこと、意向をすり抜けないことです。社内の道具だからという例外はありません。外部のサイトを定期的に巡回する仕組みを持っているなら、名乗り方と間隔を一度確かめておくほうが安全です。
AI検索に自社の記事を拾ってもらうための整理はAI検索時代のSEOはどう変わるか｜変わらない部分と見直す部分を分けるにまとめています。出す側と集める側で、守る作法が同じ方向に寄ってきているのが、いまの流れです。
先に整えておくこと
第一に、robots.txt の表明が実態と合っているかです。拒否したつもりでいても、書かれていなければ意向は存在しません。なお公式ドキュメントは、robots.txt の遵守はあくまで任意のものであり、技術的にアクセスを止める仕組みではないとも書いています。表明は、意向を伝えるためのものです。
第二に、混雑したときに応答を返せる状態かどうかです。429 を返していないサイトでは、相手が合図に反応する種類かどうかを観察できません。これはボットのためというより、自分のサイトの負荷を自分で説明できるようにするための準備です。
第三に、用途ごとの可否を決めてあるかどうかです。Cloudflareの公式ドキュメントは、コンテンツの使われ方を3つに分けて指定できるとしています。検索の索引を作って検索結果を返す用途、生成AIの回答のために内容をその場で取り込む用途、モデルの学習や微調整に使う用途です。この3つは別のものとして指定できます。AIに学習させたくないことと、AI検索の回答に出てほしいことは、両立する要望だからです。
書かれていないこと
推測で埋めないために、探しても見つからなかった項目を残します。
| 確認したかった項目 | 公式ブログ・公式ドキュメントの記載 | どうするか |
|---|---|---|
| 帯の段階の数と名前 | 記載がありません | 公開されるまで、社内資料に段階を書き込まない |
| しきい値を選べるようになる時期 | 「将来」とだけ書かれています | 現在の設定の運用を続け、公開時に見直す |
| 対象になるプランと料金 | 記載がありません | 契約条件は窓口で確認する |
| 観察の対象となる期間の長さ | 記載がありません | 一時的な異常がどう扱われるかは判断しない |
| Verified ではないボットの扱い | 今回の説明の範囲外です | 従来のボット対策の設定と分けて考える |
| 日本語の管理画面での表記 | 確認できていません | 社内へ共有するときは英語の名称も併記する |
発表の時点で決まっていないことが多いのは、この種の仕組みでは普通です。問題になるのは、書かれていないことを自社の資料で埋めてしまうときです。社内で共有するなら、公式の記載と自分たちの見込みを分けて書いてください。
まとめ
Cloudflareは、Verified bots の扱いを、身元の確認で終わらせない形へ進めると公表しました。評価されるのは、robots.txt で示された意向に沿っているか、そして 429 のような合図を受けたあとに動きを変えるかです。判定は点数ではなく、理由を添えた信頼の帯で示され、将来は Radar で公開され、顧客がしきい値を選べるようになるとされています。
サイトを運営する側から見ると、AIクローラーへの向き合い方が「通すか止めるか」から「どこまで一貫した相手を通すか」へ寄ります。選べるようになったときに判断できるかどうかは、いま自社が何を表明しているかで決まります。robots.txt の表明、混雑時の応答、用途ごとの可否という3点は、発表を待たずに確かめられます。
同時に、自社が外部サイトを巡回する側になっている場合は、求められる作法が同じであることも押さえておいてください。集める側と出す側の両方で、名乗り方と要求の間隔が見られる時代になりました。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
Microsoft Clarityが収集と流入を1つの指標に。AI Scrape-to-Referral Ratio Microsoft Clarityに、AIクローラーによる収集量と、そこから戻ってくる流入を並べて見る指標が加わりました。どこにある機能で、何が分かり、何が分からないのかを公式情報の範囲で整理します。
AI検索からの流入は別チャネル。Shopifyが出した2026年の実測データ Shopifyが第1・第2四半期の自社データで、AI検索経由の買い物客と自然検索の違いを公表しました。着地点、転換率、カテゴリー別の差と、日本の実務者が先に用意すべきものを一次情報の範囲で整理します。
AI検索時代のSEOはどう変わるか｜変わらない部分と見直す部分を分ける AI検索が広がるなかで、SEOのどこが変わり、どこが変わらないのかを公式情報から整理します。指標の見直し方、流入が減ったときの確認手順、社内で決めておくことを実務目線で解説します。