Cloudflare BotBase for Operators — AIエージェントが「誰が運営し、何のために巡回するか」を申告する仕組みが整った

要約

2026-08-28、Cloudflare が BotBase for Operators を公開しました。

BotBase は、Cloudflare が持つ検証済みボット・AIエージェントのディレクトリです。 サイト側は「このボットは何者か」を判断する材料としてこれを参照し、受け入れるかブロックするかを決めます。Cloudflare の配下にあるサイトの数を考えると、このディレクトリに載っているかどうかは、ボット運営者にとって実質的な通行証として働きます。

今回公開されたのは、その登録を申請する側のためのダッシュボードです。 場所は Protect & Connect → Application Security → BotBase。

これまでの申請体験は、率直に言えばブラックボックスでした。 出したら音沙汰なし。通ったのか、落ちたのか、落ちたなら何が悪かったのか。分からないまま待つ。内容を直したければ、また最初から出し直す。

今回、ここが変わりました。 申請の状態が Waiting for review / Accepted / Rejected として見え、却下には理由が付きます。 そして内容の更新が、再申請なしでできます。 ボットの仕様が変わったときに、登録情報を最新に保てるということです。

審査そのものも自動化されました。 背景として Cloudflare が挙げているのは、2023年以降、申請数が7倍に増えたという事実です。完全な手作業では回らなくなった。自動検証の内容は具体的で、重複の確認、user-agent が十分に特定的か、IP リストの妥当性、逆引き DNS の確認、そして Web Bot Auth 署名の認証が走ります。

分類法（taxonomy）も更新されました。 運営者は3つの属性を申告する必要があります。そのボットが何をするか。コンテンツをどう使うか。誰が運営しているか。 この3つです。

この3属性の設計が、今回の更新の要点です。 従来のボット識別は「誰か」に寄っていました。user-agent 文字列と IP レンジで、正体を確かめる。そこに「何のために」が加わった。 検索インデックスのためなのか、データ収集なのか、モデル学習なのか。用途を宣言させる。

これは Content Signals の考え方に沿っています。 ボット側が用途を宣言し、サイト側が robots.txt で示した意向を尊重する。「入れるか入れないか」の二択ではなく、「この用途なら入れる」という条件付きの合意が成立する構造です。

Verified 状態は、申告と実際の挙動が一致していることが条件です。 宣言と違う動きをすれば、その状態は維持できません。そして Verified かどうかが、Cloudflare ネットワーク全体でのサイト側の受け入れ判断に効きます。

何が変わったか

• ボット・AIエージェント運営者向けの申請管理ダッシュボードが公開（Protect & Connect → Application Security → BotBase）
• 申請の状態（Waiting for review / Accepted / Rejected）と却下理由が確認できる
• 申請内容を再申請なしで更新できる
• 審査が手作業から自動審査へ移行（背景: 2023年以降、申請数が7倍に増加）
• 自動検証の内容: 重複確認、user-agent の特定性、IP リストの妥当性、逆引き DNS、Web Bot Auth 署名の認証
• 分類法が更新され、「何をするか」「コンテンツをどう使うか」「誰が運営するか」の3属性の申告が必須に
• 振る舞いモデルは Content Signals に沿い、ボット側の用途宣言とサイト側の robots.txt の意向を突き合わせる
• Verified 状態の維持には、申告内容と実際の挙動の一致が必要

業務インパクト（一般企業向け）

影響を受ける立場は2つあります。ボットを出す側と、サイトを守る側です。

まず、出す側から。 自社サービスの一部として外部サイトを巡回する仕組みを持っているなら、これは直接効きます。 価格比較、求人情報の収集、業界動向のモニタリング、そして最近増えているのがAIエージェントによる自動リサーチです。「エージェントに調べさせる」機能を製品に載せている企業は、その動きが外から見ればボットの巡回であることを意識する必要があります。

Cloudflare 配下のサイトにブロックされたとき、これまでは打つ手が限られていました。 問い合わせ先も分からない。今後は、BotBase に登録して Verified を取るという正規の経路があります。逆に言えば、登録していないボットは「素性不明」として扱われる方向に、環境が固まっていきます。

登録には準備が要ります。 user-agent を十分に特定的にする。IP リストを整備し、逆引き DNS を設定する。Web Bot Auth の署名に対応する。 これらは申請の前提であり、自動検証で機械的に確認されます。 「とりあえず申請してみる」で通る種類のものではありません。開発工数として見積もっておくべき作業です。

そして、用途の申告が新しい負荷になります。 「コンテンツをどう使うか」を宣言するということは、社内で用途を定義しておく必要があるということです。収集したデータを学習に使うのか、使わないのか。この問いに答えられない状態で申請はできません。 法務やデータ管理の担当を巻き込む話になります。

次に、守る側。 Cloudflare を使ってサイトを運用しているなら、判断の材料が増えます。 これまでは「ボットか、人間か」「既知か、未知か」という粗い軸しかありませんでした。用途の宣言が入ることで、「検索インデックスは歓迎、モデル学習は拒否」という方針が表明可能になります。

これは実際に多くの企業が持っている方針です。 自社サイトが検索に出るのは望ましい。一方で、コンテンツが AI の学習データとして吸われるのは望まない。 この2つを分けたい、という要望は強いのに、技術的に分ける手段がこれまで乏しかった。 robots.txt では粒度が足りず、User-agent ごとに書き分けるのは追いつかない。用途の宣言と Content Signals の組み合わせは、この分離を可能にする方向の整備です。

ただし、宣言ベースである点は正確に理解してください。 ボット側が「学習には使わない」と申告し、実際にそう振る舞うことが前提です。Cloudflare は申告と挙動の一致を Verified の条件にしていますが、これは検証であって強制ではありません。 宣言を破るボットが存在しうる、という前提は変わりません。法的な拘束力があるのは、あくまで robots.txt と利用規約と、その先の契約や法制度です。 技術的な仕組みは、それを実効的にする補助として位置づけるのが正確です。

副業・個人活用視点

AIエージェントを作って動かしている人には、これは他人事ではありません。 「エージェントに Web を調べさせる」処理を書いた瞬間、あなたはボット運営者になっています。 副業で自動化ツールを作っている人、スクレイピングを含む案件を受けている人、リサーチ系のエージェントを製品化しようとしている人——全員が対象です。

現実的な問題として、Cloudflare にブロックされる経験は誰でもしています。 動いていたスクリプトが突然 403 を返す。ヘッダーを変えたり、待ち時間を入れたりして凌ぐ。この「凌ぐ」やり方が、通用しにくくなる方向に環境が動いています。

正規の経路が整備されたことは、長期的には作る側にとって有利です。 素性を明かして登録し、用途を宣言し、Verified を取れば、堂々と巡回できます。 回避策を積み重ねるより、登録の要件を満たす方が安定します。

ただし、個人や小規模で登録要件を満たすのは簡単ではありません。 固定 IP のリストと逆引き DNS が要求される時点で、家庭のネット回線や一般的なクラウド関数からは難しい。 Web Bot Auth の署名対応も実装が要ります。「ちょっと試したい」段階では手が届かないのが実情です。

この非対称は正直に見ておくべきです。 参入のハードルが上がるということでもあります。個人開発者にとって、外部サイトの巡回を前提にした製品は作りにくくなる方向です。 公開 API のあるサービスを使う、データ提供元と契約する、ユーザー自身のブラウザで動かす——巡回以外の設計を最初から検討する方が現実的な場面が増えます。

案件としては、逆側に価値があります。 サイトを運用しているクライアントに対して、「検索エンジンは通し、学習用クローラーは拒否する」という方針を技術的に実装する支援ができます。これは経営層に説明しやすいテーマです。自社コンテンツが AI の学習に使われることへの懸念は、実際に多くの企業が持っています。

提案として成立するのは、方針の言語化から実装までを通すことです。 何を許可し、何を拒否するか。その判断基準を決める。robots.txt と Content Signals にどう書くか。Cloudflare の設定でどう反映するか。 そして宣言ベースである以上、完全には防げないという限界も含めて説明する。 この「できないことも含めて説明する」姿勢が、この領域では信頼につながります。過大に約束すると、後で必ず破綻します。

もう一つ、押さえておく価値のある視点があります。 ボットの識別が「誰か」から「何のために」へ移りつつある、という変化です。これは AI エージェントが増えた結果として必然的に起きています。 同じ主体が、あるときは検索のために、あるときはユーザーの代理として巡回する。主体で判断する方式が限界に来ている。 この構造変化を理解していると、次に何が来るか——おそらくリクエスト単位での用途宣言と、その検証——が読めます。先回りして準備できる領域です。