About

ボット対策はヘッダーひとつではない — 守る側から見た5つの層

接続・リクエスト・ページ・入力・セッションが同じ話をしているかを見て点数を付ける

RedditとNaverがブラウザを操作するAIを締め出していると聞いて、最初は「User-Agentヘッダーをひとつ見ているんだろう」と思った。調べてみると違った。今のボット管理はヘッダーひとつではなく、いくつもの層の信号が互いに合っているかを見て点数を付けている。 サイトを運営する側、守る側の視点でまとめた。自分のサービスにボット対策を入れるとき、何から決めればいいかが見えてくる。

よく思い浮かべる図と実際

よくある想像:  リクエスト ── User-Agent ──▶ 許可 / 拒否

実際に前段が見ているのは、いくつもの層だ。図はCloudflareがドキュメントで公開している構造をもとにした。サイトによって前段は違うことがある。

1 ConnectionTLS ClientHello fingerprint, HTTP/2 settings 2 Requestheader order, client hints, sec-fetch-* UA 3 Page scriptautomation and headless traces 4 Inputare clicks and keys real input? 5 SessionIP reputation, pacing, account history score 1–99 low = likely automated allow · challenge · block changing User-Agent touches only the small UA box in layer 2
層 見るもの 守る側が得る信号
接続 TLSの最初のあいさつ(ClientHello)の指紋、HTTP/2の設定 スクリプト用のHTTPクライアントと実際のブラウザは、ここから違う
リクエスト ヘッダーの種類・順序、client hint、sec-fetch-* UAが名乗るブラウザと、他のヘッダーが指すブラウザが違えば、その食い違いが信号
ページ内 JavaScriptから見たブラウザ環境 ヘッドレス・自動化ツールの痕跡
入力 クリック・キー入力が本物の入力か スクリプトが作ったイベント
セッション IPの評判、リクエストの間隔、アカウントの履歴 リクエスト単体がきれいでも積み上がる振る舞い

User-Agentを変えても、この表の二行目の中の一マスに触れるだけだ。他の層が別の話をしていれば、点数はそのまま残る。

点数は1〜99

Cloudflareのボットスコアのドキュメントによると、点数は1〜99で、低いほど自動化の可能性が高い。エンジンはヒューリスティック(既知の指紋との照合)、機械学習、JavaScript検出に分かれる。ヒューリスティックで確実に引っかかったリクエストは1になる。

接続層の代表がJA3・JA4といったTLS指紋だ。JA4はClientHelloの拡張の並びをソートして作る指紋で、JA3を改良したものだ。ただし細かい点数やJA3・JA4の値が見えるのは、Bot Managementを購入したEnterpriseの顧客だけ。Pro以上のプランは「自動化・人間」のグループ単位で見る。

一度通っても終わりではない。Cloudflareは2026年8月のブログで、セッションの間ずっとクライアントの振る舞いを見る検出を公開した。CAPTCHAがその瞬間の関門なら、振る舞いのスコアはその後のセッションを見る。

Redditはヘッダーではなく入り口を狭めた

The Verge(2026-09-30)が伝えたRedditの説明はこうだ。Old Redditはログインを必須にし、切り替え時点から直近6か月以内に使われたアカウントだけを残す。RSSは2026-11-13に止める。理由は大規模なスクレイピングと自動化された悪用だ。

「AIブラウザのヘッダーを弾く」のではなく、入り口とアカウントを絞ったわけだ。守る側から見ると、これがいちばん安い。指紋の追いかけっこには終わりがないが、匿名で開いている入り口を閉じるのは一度で済む。

Naverについては「このヘッダーならエージェントのブラウザとみなす」という公開ドキュメントは見つからなかった。YetiはNaverが外に出している収集クローラーの名前で、入ってくるブラウザを弾く印ではない。Naverがどの層で止めているかは確認できなかったので、ここでは書かない。

自分のサービスなら — いつ何を

状況 まずやること
ログイン・登録フォームに自動の試行が集中する リクエスト頻度の制限(rate limit)とCAPTCHA
公開APIやRSSを吸い上げられる 入り口を認証の後ろに移す、またはキーを発行
人のふりをするブラウザ自動化が問題 前段のボット管理(Cloudflareなど)のスコアを受けてルールにする

Railsなら一行目はコントローラーの一行から始められる。Rails 7.2から入った rate_limit だ。

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create
end

User-Agentのブロックリストだけを置くのは、いちばん弱い一マスだけを守っているようなものだ。正直に名乗るクローラーを整理するのには役に立つ。隠れたい側は、まずそのマスから変えてくる。

自分で試していないことも書いておく。RedditやNaverに自動化したブラウザを送って、どの層で拒否されるかを再現してはいない。点数の重み付けも公開されていない。

サービスにボット・スクレイピング対策をどこまで入れるか、ログインとAPIの入り口をどう分けるかで迷っているなら、https://www.negabaro.com/contact から聞いてほしい。

動作フロー

1

接続: TLS ClientHello・HTTP/2の設定でクライアントの種類を見る

2

リクエスト: ヘッダー順序・client hintがUAと合うかを見る

3

ページ・入力: JavaScriptで環境とイベントを確かめる

4

セッション: IP・間隔・アカウント履歴を積み上げ、1〜99の点数で許可・チャレンジ・ブロック

← 東京のカメラが埼玉の地図に載った理由 — 地図サービスの本当のコストは座標にある