Cloudflare Browser Run の /crawl が Content Signals の use を尊重 — 既定値が full なので、宣言しないと弾かれる側になる
Cloudflare Browser Run の /crawl エンドポイントが、Content Signals 標準の use ディレクティブを尊重するようになった。クロールする側は新しい contentUse パラメータで利用意図を宣言する。値は制限の緩い順に reference と full の2つで、既定値は full。対象サイトの robots.txt が宣言した use レベルが、リクエスト側の contentUse より制限的な場合、クロールリクエストは 400 エラーで拒否される。重要なのは既定値が full である点で、明示しなければ最も広い利用意図を宣言したことになり、制限的なサイトへのクロールが既定で失敗しうる。サイト側の意向の尊重が、クローラー側の善意ではなくプラットフォームの実装として組み込まれた形になる。
ニュース原文を読む ↗要約
2026-08-31、Cloudflare の changelog に 「Crawl endpoint now respects the Content Signals use directive」 が掲載されました。製品は Browser Run です。
Browser Run の /crawl エンドポイントが、Content Signals 標準の use ディレクティブを尊重するようになったという内容です。
仕組みは、両側からの宣言を突き合わせる形になっています。
サイト側は、robots.txt の Content Signals で「自サイトのコンテンツが利用されてよい最大のレベル」を表明します。
クロールする側は、新しい contentUse パラメータで自分の利用意図を宣言します。 取りうる値は制限の緩い順に reference と full の2つです。
そして、突き合わせの結果はこうなります。 対象サイトの robots.txt が宣言した use レベルが、リクエスト側の contentUse より制限的である場合、クロールリクエストは 400 エラーで拒否されます。
つまり、「全面利用（full）」を宣言してクロールしようとしても、サイト側が「参照まで（reference）」しか許可していなければ、そのリクエストは Cloudflare 側で弾かれます。
ここで、実装上いちばん重要なのは既定値です。
contentUse の既定値は full です。
明示しなければ、最も広い利用意図を宣言したことになります。 ということは、既存の /crawl 呼び出しは、制限的な Content Signals を掲げているサイトに対して、これから失敗しうるということです。コードを変えていなくても、挙動が変わる。
この点は changelog に明示されていませんが、仕様から論理的に導けます。 既定が最も緩い側ではなく最も広い側に置かれている——これは「宣言しないこと」を安全側に倒さない設計です。使う側に明示を促す方向の設計判断だと読めます。
構造として何が起きたのかを整理します。
これまで、robots.txt の記述を尊重するかどうかは、クローラー側の実装と善意に委ねられていました。 読むかどうかも、従うかどうかも、クローラーを書いた人次第。 破っても、技術的に止まるわけではありませんでした。
今回、その判定がプラットフォーム側に入りました。 Cloudflare の /crawl を使う限り、サイト側の意向より過大な利用意図でのクロールは、そもそも成功しません。
「守るかどうか」から「守らないと動かない」への移行です。これは、宣言ベースの仕組みが実効性を持つ数少ない形の一つです。
もちろん、これは Cloudflare の /crawl を使う場合の話です。 自前でクローラーを書けば、この制約は掛かりません。プラットフォームを経由することと引き換えに、制約を受け入れる——という構図であることは、正確に理解しておく必要があります。
何が変わったか
- Browser Run の
/crawlエンドポイントが Content Signals のuseディレクティブを尊重するようになった - リクエスト側に
contentUseパラメータが追加。値は制限の緩い順にreferenceとfull - 既定値は
full（明示しなければ最も広い利用意図を宣言したことになる） - 対象サイトの
robots.txtのuseレベルがcontentUseより制限的な場合、リクエストは400エラーで拒否される - 呼び出し例（公式 changelog より）:
POST /accounts/{account_id}/browser-rendering/crawlのボディに"contentUse": "reference"を含める - 既存の呼び出しは
contentUse: full相当として扱われるため、制限的なサイトに対して失敗しうる
業務インパクト（一般企業向け）
まず、/crawl を使っている実装があるなら、これは確認事項です。
コードを変えていなくても、挙動が変わりうるという種類の変更だからです。既定が full である以上、制限的な Content Signals を掲げるサイトへのクロールは 400 で落ち始めます。
そして 400 は、クロール処理の中では扱いが雑になりがちなステータスです。 「不正なリクエスト」として一括でログに流され、リトライもされず、気づかれないまま件数だけ減る。 監視していなければ、静かにデータが欠ける形の障害になります。
やるべきことは2つです。 /crawl の 400 応答を、他のエラーと区別して監視すること。 そして、自社の利用実態に合った contentUse を明示的に指定すること。
後者には、事前の意思決定が要ります。
「自社は取得したコンテンツをどう使うのか」に答えなければ、reference と full のどちらを宣言するか決められません。
参照・引用にとどめるのか。それとも全面的に利用するのか。 モデルの学習に使うのか、使わないのか。 ——この問いは技術的な問いではなく、法務とデータ管理の問いです。
技術要件に見えて、実は社内の意思決定を要求している。 この構造は、AI 関連の統制で繰り返し現れます。エンジニアが独断で full と書いて済ませられる項目ではありません。
現実的な進め方としては、reference から始めることを勧めます。 制限の緩い側を宣言しておけば、拒否される範囲が狭くなります。 そのうえで、full が必要な用途が本当にあるなら、そこだけ根拠を持って上げる。 既定値に任せて full になっている状態は、「意思決定をしていない」ことを「最も広い宣言」として外部に表明しているのと同じです。
サイトを運営する側から見ると、意味合いは逆になります。
robots.txt に Content Signals を書く実利が、一段はっきりしました。 書いておけば、少なくとも Cloudflare の /crawl を経由するクロールに対しては、意向が実際に効きます。 書かなければ、何も主張していないことになります。
「自社コンテンツが AI の学習に使われるのを制限したい」という要望は、多くの企業が持ちながら、手段が乏しい状態が続いていました。 完全な解決ではありませんが、宣言が実際に効く経路が一つ増えたのは前進です。
ただし、限界は正確に押さえてください。 これは Cloudflare の /crawl を使うクローラーにしか効きません。 自前実装のクローラーには何の制約も掛かりません。「Content Signals を書いたから守られる」という説明は、誤りです。 法的な拘束力があるのは、あくまで利用規約とその先の法制度であり、技術的な仕組みはそれを実効的にする補助——という位置づけが正確です。
副業・個人活用視点
Browser Run の /crawl を使ってリサーチ系のツールを作っている人には、直接効く変更です。
まず、自分の実装に contentUse を明示してください。 明示しなければ full として扱われ、制限的なサイトで落ち始めます。 リサーチ用途で内容を参照するだけなら、reference が実態に合っているはずです。
そして、宣言と実際の使い方を一致させてください。 reference と宣言しておいて全面的に再利用するのは、技術的には通っても、宣言の意味を壊す行為です。この種の仕組みは、宣言が信頼される限りにおいて機能します。
エージェントに Web を調べさせる処理を書いているなら、あなたはクローラー運営者です。 これは前提として押さえてください。「ちょっと調べさせているだけ」でも、外から見ればクロールです。
案件としては、二方向あります。
一つは、クロール側の実装対応。 contentUse の指定、400 の監視、そして「自社はコンテンツをどう使うのか」の言語化支援まで含めると、単なる実装作業以上の価値になります。最後の部分——用途の言語化——が、実はいちばん詰まる箇所です。 法務を巻き込む必要があり、技術と法務の間を通訳できる人が要る。
もう一つは、サイト運営側の設定支援。 robots.txt の Content Signals をどう書くか。 これは経営層に説明しやすいテーマです。「自社コンテンツが AI の学習に使われる」という懸念は、実際に強い。
ただし、提案するときに効果を過大に言わないこと。 Cloudflare の /crawl 経由にしか効かないという限界を先に伝えてください。「これで守られます」と言った後に自前クローラーの存在を指摘されると、そこで信頼が終わります。 できることとできないことを両方言えることが、この領域では最大の差別化です。
もう一つ、押さえておく価値のある視点があります。
宣言ベースの仕組みが実効性を持つ条件は、「経路が絞られていること」です。 Content Signals 自体は誰でも無視できますが、Cloudflare の /crawl という経路を通る限り無視できない。 プラットフォームを経由することと引き換えに、制約を受け入れる——この構造は、他の領域でも繰り返し現れます。規範を実効化したいなら、経路を押さえる。 この一般則を理解していると、次に何が起きるかが読めます。