はじめに
2026年9月15日から、Cloudflare に新しく登録されるドメインのデフォルト設定が変わることをご存知でしょうか？
「AI クローラーが全面ブロックされる」という話 ではありません。
ただ、Web クローラーを業務で開発している筆者にとって、また、Web コンテンツを活用する側の開発者にとって、このトピックは追っておく必要がありそうだと感じたため記事にしました。
この記事では コンテンツを取りに行く側が何を知っておくべきか について考えます。
ポイントは2段階あって、
- 誰であるか を証明する軸 — Web Bot Auth
- 何をしてよいか を宣言する軸 — robots.txt / Content Signals
です。
構造的には認証・認可に似ていますね。
何が変わるのか
Cloudflare は AI 関連のトラフィックを3つに分けています。
| 分類 | 内容 |
|---|---|
| Search | 後で質問に答えるためにコンテンツを索引化する |
| Agent | 人の代理でリアルタイムに動く。chat の fetch、browser-use 系のエージェントなど |
| Training | モデルの学習・fine-tuning のためにコンテンツを集める |
注目は Agent です。この分類には LLM アプリケーションが裏で叩いている fetch が入ります。
ユーザーが質問して、その場でエージェントが Web を見に行くリクエストもここに入ります。
そして、Cloudflare は新しく登録されるドメインについて Agent と Training 目的の bot を デフォルトでブロック すると発表しました。
これからは bot が「誰であるか」だけではなく、「何をする」 bot なのかまで示す必要が出てきたということです。
身元、用途を示すための技術基盤
まず「誰であるか」を提示する方法について見ていきます。
これまで、bot が自分の身元を示す手段は主に2つでした。
- User-Agent(UA): 手軽だが、自己申告。簡単に書き換え可能。
- IP レンジを公開する: 公開側、サイト側ともに運用が重い。フォワードプロキシを挟むようになるとさらに複雑になる。
UA にクローラーのヘルプページを載せたりもしますが、bot の身元証明って実は結構難しいんですよね。
サイトを守るために、一律で bot をブロックするという選択もありえます。
これから必要になるのは、改竄できない形で身元を示す手段 です。
Web Bot Auth
Web Bot Auth は、公開鍵暗号を使って bot の身元を証明する仕組みです。
技術的な基盤は RFC 9421 HTTP Message Signatures です。HTTP ヘッダに載せて署名を作り、エンコードし検証する標準化された仕様です。Web Bot Auth はその上で、bot の身元確認という用途に必要な約束事を決めた IETF ドラフト（draft-meunier-web-bot-auth-architecture）です。
送るもの
署名付きリクエストには3つのヘッダが載ります。
| ヘッダ | 中身 |
|---|---|
Signature-Input |
署名の対象にした構成要素の一覧と、パラメータ（keyid、created、expires、tag など） |
Signature |
実際の署名バイト列 |
Signature-Agent |
自分の鍵ディレクトリの URL |
実物はこうなります。
Signature-Input: sig1=("@authority");created=1786162298;expires=1786162598;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";tag="web-bot-auth"
Signature: sig1=:4qjzAQDQ3eoqc8PYAf+oYvH4O2o66qqQEEKEKXliBfUl07DQEEcI9zue+P3obN7iQpaf+rgDv/MzUHDWdFtBDg==:
鍵をどう渡すか
サイト側は、署名を検証するために公開鍵を手に入れる必要があります。そのために、bot 側は鍵ディレクトリを HTTPS で公開します。
- パスは
/.well-known/http-message-signatures-directory -
Content-Typeはapplication/http-message-signatures-directory+json - 中身は JWK Set。Ed25519 の公開鍵なので
kty/crv/xだけを含む
Signature-Agent ヘッダは、この URL を指すためのものです。
HTTP リクエストに Signature-Input / Signature ヘッダを載せる
TypeScript の風擬似コードです。実装の規模感が分かる程度に触れています。
まず鍵を用意します。Ed25519 なので openssl で十分です。
openssl genpkey -algorithm ed25519 -out private.pem
openssl pkey -in private.pem -pubout -out public.pem
署名処理は自分で書くこともできますが、Cloudflare が公式パッケージを出しているので、実務ではこちらを使うのが安全です。
| パッケージ | 用途 |
|---|---|
web-bot-auth |
Web Bot Auth のドラフトに沿った署名 |
http-message-sig |
RFC 9421 の署名プリミティブ |
jsonwebkey-thumbprint |
RFC 7638 の thumbprint 計算（= keyid） |
やることは、署名の対象を並べた文字列（signature base）を組み立てて、それに署名し、3つのヘッダとして載せることです。イメージとしてはこうなります。
// keyid は公開鍵から機械的に決まる
const keyid = jwkThumbprint(publicJwk);
const now = Math.floor(Date.now() / 1000);
const signed = signRequest(request, {
components: ["@authority"], // 署名の対象にする構成要素
params: {
created: now,
expires: now + 300, // 有効期限は短くしてよい
keyid,
tag: "web-bot-auth", // これを忘れると検証が通らない
},
privateKey,
});
// → Signature-Input / Signature ヘッダが付く
Content Signals
ここまでが bot が「誰であるか」を示す方法についてでした。
冒頭でも触れたように、これからは bot が「何をする」のかもフェッチがブロックされるか否かにおいて重要になってきます。
Cloudflare が提案している Content Signals はこれを分類し、サイト側で robots.txt の拡張として宣言するための仕組みです。
用途は3つに区別されます。
| 値 | 用途 |
|---|---|
search |
検索のために索引化してよいか |
ai-input |
AI の入力として使ってよいか（回答生成のために参照する用途） |
ai-train |
モデルの学習に使ってよいか |
web コンテンツを利用する側から見ると、
- これまで:
robots.txtで Disallow されていなければ、取得し、どんな用途で使っても良い - これから: 取得した後も、 どんな用途で使うか が
robots.txtで縛られる
ということになります。
robots.txt の拡張仕様なので強制力はありません。
しかし、Web Bot Auth と組み合わせると用途別に bot をブロックするということがシステム的に可能になってきていて、冒頭の Cloudflare の対応はその一例と捉えられるのではないでしょうか。
考察 -- web コンテンツを利用する側の姿勢とは？
筆者自身 web クローラーを開発している人間ですので、今後 Cloudflare のサイトを中心にクローラーがブロックされることが増えそうで身構えています。
ただ、既存のサイトのポリシーが変わるわけではないことや Web Bot Auth もまだ IETF ドラフトの段階であることから、即座になにかすべきという訳では無いかもしれません。（フェッチがブロックされたログを落として、監視できるようにしておくくらいはしても良いかも）
まとめ
- 9月15日から、Cloudflare の新規ドメインで Training と Agent がブロックされる（広告表示ページ、Search は許可）。Agent には LLM アプリの fetch が含まれる
- 行儀のよい bot の条件として、誰であるか（Web Bot Auth）と、何をしてよいか（robots.txt / Content Signals）を明示するという流れが強まりそう