Cloudflare Adaptive Intelligence — 検知を「固定しない」ことで、ボット攻撃の採算を崩す

要約

2026-08-31、Cloudflare が Adaptive Intelligence を発表しました。ボット検知エンジンです。

設計思想が、この発表のいちばん面白い部分です。

目標は「すべての攻撃者をブロックすること」ではありません。 検知を継続的かつ予測不能にすることで、攻撃側のコストを引き上げ、採算を崩すことが目標だと明言されています。

この違いは実務的に大きい。 「完全に防ぐ」を目標にすると、防御は必ず負けます。攻撃側は一箇所破ればよく、防御側は全部守らなければならない。 非対称が構造的にあります。

「採算を崩す」を目標にすると、非対称が逆転します。 攻撃側は、破っても破っても、また変わっている状態に置かれる。 投じたコストが回収できなければ、技術的に可能でも、やる意味がなくなる。

中核となる仕組みは2つです。

1つめ、継続再学習。 固定バージョンの ML モデルをリリースする方式をやめ、ライブトラフィック上でモデルを継続的に再学習します。これにより、新しい回避手法に対して数日単位で適応できるとしています。

従来のモデル配布方式では、リリースから次のリリースまでの間、検知の中身は固定でした。 攻撃側から見れば、一度解析すれば、次の更新まで有効な回避策が手に入る。 その前提が崩れます。

2つめ、使い捨て検知ルール（disposable rules）。 一時的な検知ルールを生成し、ランダムに展開して、攻撃者がリバースエンジニアリングし終える前に引退させます。

これが効く理屈は、攻撃側の作業サイクルを考えると分かります。 回避策を作るには、まず「何を見られているか」を特定する必要があります。 試行錯誤して、どの条件で弾かれるかを絞り込む。この解析に時間がかかる。

解析が終わる前にルールが消えていれば、投じた時間が丸ごと無駄になります。 しかも、次に何が来るか分からない。 ここが「予測不能にする」の中身です。

判定に使うシグナルも複合的です。 JA4 TLS フィンガープリント、リクエスト構造、チャレンジの結果、セッションの振る舞いを、複数の時間窓にまたがって組み合わせます。単発のリクエストでは見えない、分散化された攻撃を検出するための設計です。

ネットワーク横断のシグナルからのパターン検出と、新規検知ルールの自動生成（マイニング）も自動化されています。

そして、安全な展開手順が用意されています。 新しい検知は、まず shadow mode で動きます。 既存の検知より優れていることを証明しない限り、本番トラフィックには影響しません。 継続的に自動生成される仕組みである以上、「自動生成された検知が誤って正規ユーザーを弾く」リスクへの手当てが要る——その答えがこれです。

提供形態は次のとおりです。

既存の Bot Management に統合され、顧客がすでに使っている bot score を強化する形で効きます。振る舞い検証エンジン Precursor と併用されます。Enterprise 向けに一般提供（GA） され、利用するには Bot Management ダッシュボードで「Auto Update Machine Learning」を有効化する必要があります。

何が変わったか

• Adaptive Intelligence が Enterprise 向けに GA
• 設計思想: すべてをブロックするのではなく、検知を継続的・予測不能にして攻撃の採算を崩す
• ML モデルの継続再学習（固定バージョンのリリース方式からの転換）。新しい回避手法へ数日単位で適応
• 使い捨て検知ルール: 一時ルールをランダムに展開し、リバースエンジニアリング完了前に引退させる
• 判定シグナル: JA4 TLS フィンガープリント / リクエスト構造 / チャレンジ結果 / セッション挙動を複数時間窓で組み合わせ
• ネットワーク横断のパターン検出と新規検知ルールの自動生成
• shadow mode を経て、既存検知より優れている場合のみ本番へ反映
• 既存の Bot Management に統合され、bot score を強化。Precursor（振る舞い検証エンジン）と併用
• 利用には Bot Management ダッシュボードで「Auto Update Machine Learning」の有効化が必要

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

Cloudflare で自社サイトを守っている側から見ると、対応は軽い部類です。

「Auto Update Machine Learning」を有効にする。 これで効きます。新しい製品を買う話ではなく、既存の Bot Management の中で動くという位置づけです。

ただし、副作用として押さえるべき点が一つあります。

bot score の変動が、これまでより増える可能性があります。 モデルが継続再学習される以上、同じトラフィックに対するスコアが、時期によって動きうる。

bot score の閾値でファイアウォールルールを組んでいる環境では、ここが効きます。 「スコア 30 以下をブロック」といった固定閾値のルールが、モデルの更新で挙動を変える。 弾かれる範囲が広がることも、狭まることもあります。

やるべきことは、有効化した後にしばらく観測することです。 ブロック件数の推移を見る。 急な変動があれば、閾値の見直しを検討する。「設定して終わり」にせず、変動を前提にした運用へ切り替える——これが、この種の継続学習型の仕組みを入れるときの原則です。

shadow mode の存在は、この不安をかなり和らげます。 新しい検知は、既存より優れていることを証明しないと本番に出てこない。 とはいえ**「優れている」は全体の統計として優れているという意味**であり、個別のトラフィックパターンで悪化しないことを保証するものではありません。 自社固有の正規トラフィックが誤検知される可能性は、観測でしか潰せません。

逆側——AI エージェントやクローラーを出している側——には、別の意味があります。

検知が予測不能になるということは、正規のボットにとっても環境が読みにくくなるということです。 「この条件なら通る」という経験則が、通用しにくくなります。

回避策を積み重ねる運用は、いよいよ持続しません。 ヘッダーを工夫する、待ち時間を入れる、フィンガープリントを寄せる——こうした対処は、継続再学習の前では賞味期限が数日単位になります。

正規の経路を取る方が、圧倒的に安定します。 BotBase への登録、Web Bot Auth への対応、用途の申告。「素性を明かして通る」方向へ、環境が一段はっきり傾きました。 自社サービスが外部サイトを巡回する仕組みを持っているなら、回避策の改善に工数を割くより、正規登録の要件を満たす方に投資すべきです。判断としては、もう迷う段階ではありません。

副業・個人活用視点

個人開発でスクレイピングを含む処理を書いている人には、率直に言って向かい風です。

動いていたスクリプトが、ある日から通らなくなる。 原因を調べても、条件が特定できない。 特定できたと思ったら、また変わっている。 ——これが設計として意図された挙動になった、ということです。

この現実は、早めに受け入れた方が時間を節約できます。 回避策のイタチごっこに投じる時間は、これから回収率が下がり続けます。 相手は自動生成され、自動で引退していく仕組みです。人間が手作業で追いつく前提が成り立ちません。

代替の設計を先に検討してください。 公開 API があるサービスを使う。データ提供元と契約する。ユーザー自身のブラウザで動かす。 巡回を前提にしない設計へ寄せる方が、結果的に安定します。

受託案件では、この見立てを正直に伝えられるかどうかが分かれ目です。

「スクレイピングで取ってきます」という提案は、今後の保守コストを過小に見積もることになります。 短期的には動いても、継続的に壊れる。 その保守を誰が負担するのかを曖昧にしたまま受けると、後で必ず揉めます。

提案の段階で「この方式は継続的に壊れる前提です」と言えるか。 言ったうえで、代替案（API 利用、データ購入、手動運用との組み合わせ）を並べて示せるか。 ——ここが実力の差が出る箇所です。案件を取るために黙っておくと、その案件が負債になります。

守る側の支援としては、案件になります。

Cloudflare を使っているクライアントに対して、「Auto Update Machine Learning を有効化し、その後の bot score の変動を観測して閾値を調整する」という一連は、明確な作業として提案できます。 有効化そのものは簡単ですが、変動を観測して判断する部分には知見が要ります。

特に、誤検知の切り分けができる人は重宝されます。 「正規ユーザーが弾かれている」という問い合わせが来たとき、bot score の推移とルールの閾値から原因を特定する——これはログを読める人にしかできません。継続学習型の仕組みが増えるほど、この種の「変動を読む」スキルの価値は上がります。

もう一つ、考え方として持ち帰る価値があるのが「採算を崩す」という発想です。

セキュリティを「完全に防ぐ」で考えると、必ず負けます。 攻撃側は一箇所破ればよく、防御側は全部守らなければならない。 この非対称は、努力では埋まりません。

「攻撃のコストを、得られる利益より高くする」に目標を置き換えると、勝ち筋が見えます。 完全でなくてよい。割に合わなくすればよい。 ——この発想の転換は、セキュリティ以外の場面でも使えます。不正利用対策、スパム対策、そして AI の悪用対策。 完全な防止が不可能な領域で、何を目標に設定すれば実際に効くのかを考える型として、覚えておく価値があります。