Cloudflare Adaptive Intelligenceは、Bot Managementのボットスコアを、世界中の実トラフィックで再学習し続ける検知エンジンです。固定の版を配って数か月使う従来のモデルと違い、攻撃者が回避策を見つけても判定の基準が動き続ける仕組みです。この記事では、発表時点で使える機能と予定の機能の切り分け、機械学習モデルの自動更新の設定、WAFルールとWorkersでスコアを読む書き方を設定例付きで整理します。後半では、署名付きのAIエージェントを通しつつ悪性ボットを止めるルールの組み方と、採用する条件・見送る場面を判断します。
まとめ:Adaptive Intelligenceはボットスコアを動かし続ける検知エンジン
Adaptive Intelligenceは、新しい課金製品ではありません。Enterprise Bot Managementのボットスコアを作る機械学習エンジンの更新方式が変わった、と捉えるのが正確です。利用者が書くルールは従来どおりcf.bot_management.scoreを参照し、その値を出す判定器が裏で入れ替わり続けます。
2026年8月31日の発表時点で提供されているのは、モデルの継続的な再学習だけです。攻撃ごとの使い捨てルール生成や、保護対象サイトのトラフィックからの学習は「近日」と書かれています。導入の判断材料にするなら、提供済みの部分だけで評価してください。
スコアが動き続ける以上、閾値を固定したルールの振る舞いも変わります。署名付きエージェントと検証済みボットを先に除外し、ログイン・決済などの書き込み系の経路に絞ってスコアで止める設計が、誤ブロックを抑える基本形です。
Adaptive Intelligenceの仕組みとボットスコアに反映されるまでの流れ
Cloudflareの発表ブログは、静的で決定的な検知ルールは攻撃者に学習材料を与えると述べています。そこで、統計的な判定と頻繁に入れ替わる防御で、攻撃を続けるコストを引き上げる設計を取りました。分析対象は1日1兆件を超えるリクエストです。
2026年8月31日時点で提供済みの機能と近日予定の機能の区別
ブログに並ぶ構成要素を、提供状況ごとに分けると次のとおりです。報道では予定の機能まで含めて紹介されることが多いので、契約や設計の前に区別しておきます。
| 構成要素 | 内容 | 状況 |
|---|---|---|
| 継続的な再学習 | 実トラフィックでモデルを更新 | 提供中 |
| 使い捨てルール生成 | 攻撃別のルールを出し入れ | 近日 |
| 保護対象からの学習 | 誤検知の報告を学習に使う | 近日 |
| 検出の自動生成 | 信号の組み合わせを探索 | 今後 |
| 攻撃の記憶 | 止めた検出のパターンを保持 | 今後 |
入力に使う信号として、JA4のTLSフィンガープリント、リクエストの構造、チャレンジの結果、セッションの振る舞い、ネットワークの評判、TurnstileとPrecursorからのクライアント側の計測値が挙げられています。
ボットスコア1〜99と検出エンジンの関係から見た機械学習の位置づけ
ボットスコアのドキュメントでは、1がほぼ確実に自動化、99がほぼ確実に人間です。区分は1がAutomated、2〜29がLikely automated、30〜99がLikely humanで、0は「未計算」を意味し、人間である保証ではありません。
スコアの大半(2〜99)を出すのは機械学習エンジンで、Adaptive Intelligenceが手を入れるのはこの部分です。既知の悪性フィンガープリントでスコア1を付けるヒューリスティクスや、ヘッドレスブラウザを見つけるJavaScript検出は別のエンジンとして残ります。詳細な数値のスコアを使えるのはBot Managementを契約したEnterpriseだけで、他のプランは区分の表示にとどまります。
新モデルをシャドウモードで並走させて実ユーザーへの影響を防ぐ展開方式
判定器が勝手に変わると、正規の利用者が突然チャレンジされる心配があります。ブログによると、新モデルはまず現行モデルと並走するシャドウモードで実トラフィックを採点し、訪問者には影響させません。チャレンジの解決率などを比べ、実ユーザーのスコアが悪化する場合は本番に上げない手順です。
新しい検出もボットスコアへの入力として段階的に展開され、スコア分布やチャレンジ結果を見ながら一時停止や巻き戻しができるとされています。更新のたびに、適合率と再現率で置き換え前のモデル以上であることを示す決まりです。
MLモデルの自動更新を有効にしてWAFルールでスコアを使う手順
Adaptive Intelligenceを受け取るための作業は、自動更新の設定を1つオンにするだけです。ただし、スコアを使うルールが既にある環境では、更新でスコアが変わることを前提に確認の手順を組んでおきます。
ダッシュボードでAuto-updatesを有効にする手順と切り替え時の影響
機械学習モデルのドキュメントによると、設定名は「Auto-updates to the Machine Learning Model」です。Security Settingsで「Bot traffic」に絞り込み、Bot ManagementのConfigurationsを編集してオンにします。ブログ側では「Auto Update Machine Learning」と表記されていますが、同じ設定です。
古いモデルを使っていた場合、オンにした時点でMachine Learning由来のスコアがすぐ変わります。既に最新のモデルなら、スコアに変化が出るのは新モデルがグローバルの既定になったときだけです。既定の切り替え前にはメールとダッシュボードで通知が届きます。ドキュメントの版一覧に載っている最新はv9(2025年第2四半期)で、2026年10月時点では版番号ではなく継続更新として扱われています。
WAFカスタムルールでスコア30未満のログイン要求にチャレンジを返す式
ルールで使うフィールドはBot Managementの変数一覧にまとまっています。次の式は、ログインのPOSTだけを対象に、検証済みボットと署名付きエージェントを除いたうえでスコア30未満を拾います。
(http.request.uri.path eq "/api/login" and http.request.method eq "POST")
and not cf.bot_management.verified_bot
and not cf.bot_management.signed_agent
and cf.bot_management.score lt 30
スコア0の「未計算」もlt 30に含まれる点に注意してください。ログインでは未計算の要求をチャレンジへ回す方が安全なので、この式ではあえて残しています。サイト全体に広げる場合は、画像やCSSを除くnot cf.bot_management.static_resourceを足し、未計算を外すならcf.bot_management.score gt 0を加えます。
Rulesets APIのmanaged_challenge追加用curlの実行例
ルールをコードで管理するなら、カスタムルール作成APIのドキュメントのとおり、ゾーンのカスタムルール用rulesetへPOSTします。RULESET_IDはphases/http_request_firewall_custom/entrypointを取得して確かめます。
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"description": "login: low bot score",
"expression": "(http.request.uri.path eq \"/api/login\" and http.request.method eq \"POST\") and not cf.bot_management.verified_bot and not cf.bot_management.signed_agent and cf.bot_management.score lt 30",
"action": "managed_challenge"
}'
アクションはアクションの一覧から選びます。managed_challengeは要求の特性に応じてCloudflareがチャレンジの方式を選ぶもので、人間に解かせる手間が最も少なくなります。いきなりblockにせず、まずlogで数日分の該当件数を見てから切り替える順番が安全です。
スコアの分布が変わる前提で閾値ルールを見直す月次運用の組み方
継続再学習では、同じ利用者の同じ操作でも、ある日を境にスコアが数ポイント動きます。閾値ちょうどの30で区切ったルールは、この揺れの影響を最も受ける設定です。月に1回はSecurityのボット分析で区分ごとの件数とチャレンジ通過率を見て、通過率が高いのにチャレンジされている層があれば閾値を下げます。
スコアだけで区切れない攻撃には、レート制限やTurnstileを重ねます。WAFという仕組み全体の中でボット対策が受け持つ範囲は、WAFの仕組みと選び方の解説で整理しています。
正規のAIエージェントと悪性ボットを分けるルールとWorkersの設計
台帳上の論点で最も実務に効くのがここです。ユーザーの代わりにページを読み、予約や購入まで進めるAIエージェントは、振る舞いだけ見れば自動化そのものです。ボットスコアは低く出るため、スコアだけで止めると正規の利用まで締め出します。
Web Bot Authの署名でエージェントが身元を名乗る仕組み
検証済みボットのドキュメントでは、身元の示し方としてWeb Bot Authの暗号署名、固定のUser-Agentと公開IPリスト、逆引きDNSを挙げています。2026年7月1日以降は、運営者が直接動かすDirectと、利用者の代理で動くIntermediaryの区分も持ちます。
Web Bot Authのドキュメントによると、エージェントはEd25519で要求に署名し、次の3つのヘッダーを付けます。公開鍵は/.well-known/http-message-signatures-directoryでJWKSとして配ります。
Signature-Agent: "https://signature-agent.test"
Signature-Input: sig2=("@authority" "signature-agent");created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";alg="ed25519";expires=1735693200;tag="web-bot-auth"
Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:
上はドキュメントの例からnonceを省いて1行にまとめたものです。サイト側でこの署名を検証する必要はなく、Cloudflareが検証した結果がcf.bot_management.signed_agentに入ります。
Workersでスコアと署名の有無を見て応答を分けるコード例
ルールの式では書きにくい分岐は、Workersでrequest.cf.botManagementを読んで組みます。次の例は、身元を示したエージェントには閲覧を許しつつ、ログインの代行だけは拒否し、匿名の低スコア要求はログインで止めるものです。Workersの基本はCloudflare Workersの使い方と料金を参照してください。
export default {
async fetch(request) {
const bm = request.cf?.botManagement ?? {};
const url = new URL(request.url);
const isLogin = url.pathname === "/api/login" && request.method === "POST";
// 身元を示したボットとエージェントは閲覧を通す(ログインの代行は不可)
if (bm.verifiedBot || bm.signedAgent) {
if (isLogin) {
return new Response("Use the API token flow for agents", { status: 403 });
}
return fetch(request);
}
// 匿名の低スコア要求はログインだけ止める(0は未計算なので除外)
if (isLogin && bm.score > 0 && bm.score < 30) {
return new Response("Forbidden", { status: 403 });
}
return fetch(request);
},
};
署名付きであることは「誰のエージェントか」を示すだけで、そのエージェントに何を許すかはサイト側が決めます。ログインや決済をエージェントに任せたいなら、画面操作ではなく、権限を絞ったAPIトークンの経路を別に用意する方が監査もしやすくなります。
AI bot policyで回答検索・代理操作・学習の用途別に設定する判断
AIのクローラーとエージェントは、AIボットのブロック設定で用途ごとに扱いを決められます。区分は、回答用に情報を収集する検索用途、利用者の代わりにリアルタイムで動くAgent(代理操作)、学習用に取得するTraining(学習用途)の3つです。それぞれに全ページでブロック、広告のあるページだけブロック、許可を選べます。
2026年9月15日に旧来の「Block AI bots」が非推奨になり、同日以降に追加したドメインはTrainingとAgentが広告ページでブロックされる既定値になりました。予約・購入をエージェント経由で受けたいECや予約サイトは、Agentが止まっていないかを先に確認してください。反対に、エージェント向けのヘッドレスブラウザであるCloudflare Kitesurfは、ボット判定のチャレンジを通過する機能を持ちません。送る側と受ける側の両方の事情を知っておくと、ルールの意図を説明しやすくなります。
Adaptive Intelligenceの採否条件とTurnstileとの使い分け
Adaptive Intelligenceを単独で買うことはできません。判断の対象は「Enterprise Bot Managementを契約し、自動更新をオンにするか」です。
Enterprise契約済みでログインや決済を守る案件は採用
Enterprise Bot Managementを既に契約し、クレデンシャルスタッフィングや在庫の買い占め、価格情報のスクレイピングに悩んでいるなら、自動更新をオンにしない理由はほとんどありません。ドキュメントも、更新しないモデルは保守と監視の対象外になり、トラフィックの変化で精度が落ちうると明記しています。
その際は、既存ルールの閾値と除外条件をあわせて点検します。スコアのルール、レート制限、ログイン画面の作りを含めて、攻撃者の視点で抜け道が無いかを確かめたい場合は、脆弱性診断・セキュリティ診断のサービスで検証範囲を相談できます。
Free・Pro・Businessプランや閾値を固定したい運用は見送り
Enterprise以外のプランでは数値のスコアを使えないため、この更新の恩恵を直接は受けません。Cloudflareを使うこと自体の可用性や情報管理の論点は、Cloudflareの危険性と対策の解説で扱っています。
もう1つの見送り条件は、監査や社内規程で「判定ロジックを固定し、変更は事前承認」と決まっている運用です。継続再学習では版を固定できないため、変更管理の考え方を先に改める必要があります。この場合は、通知を受けてから検証環境で影響を確かめる手順を規程に書き足してから有効にします。
Turnstile・Precursorとの役割分担と組み合わせ方
Turnstileは、フォームの送信など特定の操作の直前に「人間か」を確かめる部品です。キー発行からサーバー側の検証まではTurnstileの設定方法で解説しています。2026年7月13日に発表されたPrecursorは、ブラウザ上のセッション全体の振る舞いを継続的に測る仕組みで、GAまでは無料とされています。
役割は、Precursorがセッションの振る舞いを測り、Adaptive Intelligenceがネットワーク全体の信号から学び、Turnstileが要所で確かめる、という分担です。3つはボットスコアとチャレンジの結果を通じてつながっているため、どれか1つを入れれば十分という関係にはなりません。
Adaptive Intelligenceの料金・提供範囲に関するよくある質問
Cloudflare Adaptive Intelligenceの導入の検討で出やすい質問に、公式ブログとドキュメントの記載をもとに回答します。提供状況は頻繁に変わるため、契約前に各ページの更新日を確かめてください。
Adaptive Intelligenceは追加料金がかかりますか?
2026年10月時点で、Adaptive Intelligence単体の料金は公開されていません。発表ブログでは、Enterprise顧客がBot Managementの設定で自動更新をオンにすれば使えると説明されています。Bot Management自体はEnterpriseの契約で、価格は個別見積もりです。
国内の報道で見る発表日と公式の日付が違うのはなぜですか?
公式ブログの公開日は2026年8月31日です。国内の記事は翻訳や取材の都合で数日遅れて出ることがあり、記事の日付を発表日と取り違えやすくなります。版や時期を社内資料に書くときは、公式ブログの日付を使ってください。
導入するとボットスコアの値が急に変わりますか?
古いモデルを使っていた場合は、自動更新をオンにした時点でMachine Learning由来のスコアが変わります。既に最新モデルなら、スコアが変わるのは新モデルが既定になるときだけで、通知はその切り替えより前です。影響を見たい場合は、スコアを使うルールを一時的にlogへ切り替えて件数を比べます。
ChatGPTなどのAIエージェントがブロックされることはありますか?
あります。エージェントの操作は自動化なのでスコアは低く出やすく、さらに2026年9月15日以降に追加したドメインでは、Agent区分が広告のあるページでブロックされる既定値です。正規のエージェントを通したいなら、AIボットの設定でAgentを許可し、WAFルールにnot cf.bot_management.signed_agentを入れます。
Google検索のクローラーまで止めてしまう心配はありませんか?
検索エンジンのクローラーは検証済みボットとして扱われ、cf.bot_management.verified_botが真になります。ルールでこの条件を除外していれば止まりません。除外を書き忘れた場合の影響と、Googleが自動化トラフィックをどう見ているかは、機械生成トラフィックの解説が参考になります。
関連記事
- Cloudflare Kitesurfとは:Wasmブラウザの実測値と切替手順・使えない場面を解説:AIエージェント側から見たCloudflareのヘッドレスブラウザです。
- Cloudflare Turnstileの設定方法|キー発行からsiteverify検証・エラー対処まで:要所で人間を確かめる部品の実装手順です。
- WAFとは?仕組み・ファイアウォール/IPS・IDSとの違いと企業の選び方を解説:ボット対策を含むWAF全体の役割分担です。
- Cloudflare Workersとは?対応言語・無料枠・使い方・料金を最新版で総まとめ:スコアで応答を分けるWorkersの基本です。
- 機械生成トラフィックとは?Googleの定義と「通常以上のトラフィック」表示の原因・ボット対策:自動化トラフィックの定義と検索エンジン側の扱いです。