ボット対人間を超えて
2026-04-21 — Thibault Meunier — 15分読
私たち人間がオンライン世界とやりとりするにはゲートウェイが必要です: キーボード、画面、ブラウザ、デバイス。オンラインで「人間検出」と呼ばれるものは、こうしたデバイスとやりとりするときに人間が示すパターンです。これらのパターンは近年変化しています：あるスタートアップのCEOはブラウザを使ってニュースを要約させ、ある技術愛好家は夜間のチケット販売開始時にコンサートチケットを自動で取得し、視覚に障がいのある人はスクリーンリーダーのアクセシビリティを有効にし、企業は従業員のトラフィックをゼロトラストプロキシ経由でルーティングします。
同時に、ウェブサイト運営者は依然としてデータを保護し、リソースを管理し、コンテンツ配信を制御し、悪用を防止したいと考えています。クライアントが「人間かボットか」を知るだけではこれらの問題は解決しません。望ましいボットもいれば望ましくない人間も存在するからです。これらの問題は、意図と振る舞いを知ることを必要とします。自動化を検出する能力は依然として重要です。しかし、アクター間の区別があいまいになるにつれて、私たちが今構築するシステムは「ボット対人間」が重要なデータポイントでなくなる未来に対応できるべきです。
実際に重要なのは抽象的な「人間性」ではなく、次のような問いです：これは攻撃トラフィックか、あのクローラの負荷は返しているトラフィックに比例しているか、このユーザーがこの新しい国から接続することを予期していたか、広告が操作されているか？
「ボット」という用語で語られるものは実際には二つの話です。ひとつは、既知のクローラがトラフィックを返していないときにウェブサイト運営者がそれらを許可すべきかどうか、という話です。これはクローラがなりすまされないように識別するための HTTP メッセージ署名によるボット認証で触れられてきました。もうひとつは、従来のウェブブラウザと同じ振る舞いを埋め込まない新しいクライアントの出現で、これは private rate limit のようなシステムに影響します。本稿では、今日のウェブ保護がどのように機能しているか、そしてボットと人間の境界が薄れていくときにどのように進化すべきかを探ります。
我々が持っていた Web
Web を使うとき、私たちは毎日やりとりする何千ものサーバーに直接話しかけているわけではありません。Web ブラウザを使います。これらは「user agents」とも呼ばれ、私たちに代わって行動し、サイトにコンピュータや電話全体へのアクセスを与えずに安全に買い物や読書、視聴を行えるようにします。
ウェブサイトにはブラウザの動作に関する利害もあります。コンテンツが正しく表示されること（モバイルで画面に収まる、背景色が正しい、言語が正しい）を確認したいし、ユーザーが購入を完了したり、記事を読んだり、マイクを使ったり、パスワードなしで安全にサインインできるようにしたい。記事の横に広告が表示されることも望みます。
ブラウザ利用者とウェブサイト運営者の利害の緊張関係は長く続いてきました。出版者は通常、ユーザー体験のピクセル単位での制御を望みますが、ブラウザの向こうにいる人々はしばしば出版者が想定していなかった方法で取得したデータを使いたがります。Web ブラウザベンダーとそれを取り巻く標準エコシステムは、時に大きな論争を伴いながらもこれらの利害を慎重に調整してきました。例えば、ブラウザ拡張機能で広告をブロックできますが、時間とともにブラウザはその拡張機能ができることを制限してきました。アクセシビリティ標準（例：WCAG）は、ピクセル以外の方法で Web コンテンツを利用する道を開き、多くの場所で規制要件によって裏付けられています。
これらのトレードオフの詳細は問えますが、ひとまとめのパッケージとして存在します：Web に参加したければ、出版者であれユーザーであれ、それを受け入れなければなりません。しかし今、そのバランスが変わろうとしています。
アシスタントにニュースを要約させたり研究を集約させたりすること自体は新しい概念ではありませんが、AI はこの能力を誰にでも開放しました。摩擦は、こうした新興クライアントがどのように動作するかから生じます。人間のアシスタントは記事を印刷したりスクリーンショットを撮ったりして出版者に気づかれずに情報を保存するかもしれませんが、まず標準の Web ブラウザを使ってページをレンダリングします。一方で AI エージェントはこのステップを迂回し、ページをレンダリングせずに生のデータを静かに取得します。出版者にとって、これらのクライアントは既存のブラウザトラフィックと重なるため本質的に不透明です。サイト運営者は、取得されたコンテンツが単一のプライベートレポート（歪められているかもしれない、帰属がないかもしれない）をサービスしているのか、それとも百万のユーザー向けのモデルの学習に取り込まれているのかを判断できず、これは彼らのサイトをオンラインに保つための予測可能で（かつ収益化可能な）トラフィックを乱します。Web を成り立たせていた暗黙の合意が崩れつつあります。
その仕組みを理解するために、次節ではインターネット上の一般的なアーキテクチャを概説します。
クライアント-サーバーモデル
一歩引いて、インターネット上の主要なデプロイパターンのひとつであるクライアント-サーバーモデルを見てみましょう。クライアントがサーバーにリクエストを送り、リソースを取得します。
Figure 1: Client-Server model. A client sends a request which the server responds to.
より多くのリクエストを扱うために、ウェブサイトはサーバーの容量を増やすことができます。追加のサーバーを配備したり、静的トラフィックの前にキャッシュを置いたりします。同様に、クライアント側から来るリクエスト数は、1つのクライアントがより多くリクエストを出す場合やクライアントの数が増える場合に増加します。
Figure 2: Multiple clients send multiple requests to different servers, with one fronted by a CDN.
この単純さが Web を成功させた要因の一部です。多様な種類のクライアントを許容し、各サーバーが相手側にどんなソフトウェアがあるか正確に知る必要なくネットワークを進化させることを可能にしました。
Figure 3: Two different client contexts that send requests to servers. Each server only sees a request, but not the end-user behind it.
その開放性は同時に不確実性も生みます。ウェブサイトはリソースへの有効なリクエストを見ても、通常レスポンスがサーバーを離れた後に何が起きるかを知ることはできません：コンテンツがキーボード、マウス、画面でブラウザを操作する一人の人間のためにレンダリングされるのか、あるいは独立したプログラムが自動的にリクエストを行い、レスポンスをアーカイブ、インデックス化し、より大きなシステムに供給するのか。
ボット管理の現状
このモデルは驚くほどよく機能します。だからこそウェブサーバーを起動してインターネットに接続するだけでサイト運営ができるのです。しかしサーバーがどのリクエストを提供し、信頼し、優先すべきかを決めなければならないとき、その単純さは限界を迎えます。
時にはそれはキャパシティの問題です。もしあなたのサービスがグローバルに毎秒100リクエストを処理するようにプロビジョニングされているのに200リクエスト受け取っているなら、特定のリクエストを切らなければなりません。サーバーの CPU が1つしかなく、入ってくるリクエストが2つ必要ならリクエストを落とす必要があります。200を処理するコストが prohibitive であれば、すべてのリクエストに対してレート制限を適用することになります。ランダムにリクエストを落とすこともできます。これは不公平であり、望ましいクライアントに影響してターゲットを外す可能性はありますが、働きます。ほかに信号がなければ選択肢はありません。
そしてキャパシティは状況の一部に過ぎません。サーバーはまた別の多くの理由でクライアントを区別しようとします：攻撃と通常のトラフィックを分けるため、悪意のない負荷を管理するため、データの抽出を防ぐため、広告詐欺を制限するため、偽のアカウント作成を防ぐため、またはユーザーの代わりに自動化された操作が行われるのを止めるためなどです。
難しいのは、ウェブクライアントはデフォルトで認証されておらず、多くの部分的な信号を露出しているという点です。したがってほとんどのサーバーは受け取る情報に基づいてアクセス制御ロジックを適用することにします。単一の IP アドレスが他より10倍多くリクエストしているなら、そのIPはブロックされるかもしれません。さらに踏み込むサーバーは、その IP が VPN によって使われていると推測し、したがって複数のユーザーのトラフィックをプロキシしていると判断するかもしれません。サービス側は係数を適用することにします：各クライアントが1秒あたり10リクエスト作成できると仮定し、共有 IP アドレスには100 rps を許可してそれ以上は落とす、といった具合です。
これがボット管理の鍵の一つです：サーバーが意思決定を行うためにクライアントに関するより多くの情報を提供しようとすることです。こうした情報はクライアントがサーバーの管理下にないため本質的に不正確になりえます。加えて、同じ情報はサーバー側でフィンガープリントのベクトルを作成し、ターゲティング広告など別の目的で利用され得ます。これにより緩和手段が追跡の手段へと変わります。
高レベルでは、サーバーはクライアントから以下のような信号を見ます：
- 受動的クライアント信号: インターネット上でリクエストを行うために必要なもの。クライアントは必然的に IP アドレスを送信し、通常 TLS セッションを確立します。
- 能動的クライアント信号: クライアントが任意に提供するもので、エンドユーザーには見えないことが多い。これには
User-Agent ヘッダや認証資格情報が含まれます。
- サーバー信号: リクエストを処理するエッジサーバーの地理的位置や、リクエストを受信した現地時刻など、サーバーが観察する情報。
ボリュメトリックな濫用を制限・抑制するために、オリジンが重要視するのはクライアントが複数のリクエストを行う能力と意図です。広告で収益を得るサイトであれば、オリジンは広告が実際にエンドユーザーに表示されているという確信を必要とします。ブランドを保護するために、オリジンはクライアントが特定のレンダリング能力を持っていること（PDFリーダー、SVGレンダラ、仮想キーボードなど）を確認したがるかもしれません。そして、リクエストが傍受するプロキシから来ている場合、オリジンはそのリクエストが実際にエンドクライアントから発しているものかを確認したいでしょう。
トラフィックが増えれば運用コストも増えます。クライアントが価値（金銭的であれ非金銭的であれ）を生まないなら、サーバーはそのコストを負担するインセンティブがありません。オペレーターはこの環境に対して異なる対応を取ります。大規模なクローラやプラットフォームの一部は、予測可能なアクセスが帰属可能であることのコストに見合うため自らを識別します。それが助けになる場合もあります。他の者は識別を避けようとします：ブロックされることを予期しているから、匿名性を求めているから、またはエンドユーザーに代わって動作しているからです。その結果、部分的信号に基づいた不安定な均衡が生まれます。
だからこそ「人間対ボット」という枠組みは誤解を招くのです。オリジンが気にするのは抽象的な人間性ではなく、クライアントがサイトがサポートできる方法で振る舞っているかどうかです。
余談：レート制限の三者択一（trilemma）
Figure 4: Rate limit trilemma. Decentralized, anonymous, accountable — pick two
インターネット上でアクセスを統治する方法には根本的な緊張があります：分散型、匿名、説明責任 — 二つを選べ。完全に分散かつ匿名であれば説明責任は存在しません。ブロックされたクライアントは新しいアカウントを作って評判に影響を与えずに復活できます。これはオリジンがリソース管理にさらに投資しなければならないことを意味します。これは Web のデフォルトです。
分散型かつ説明責任があれば、誰があなたなのかが皆に分かるため、特定のユースケースでは機能しますが明らかな欠点もあります。OAuth のような「Log in with」の仕組みを考えてください。アカウント登録や第三者に活動を明かすことが必要です。匿名かつ説明責任を実現するにはガバナンス、ルール、執行が必要でしょう。同じアクターに対してこれら両方の性質を備えた広く配備されたシステムは存在しません。
最も近い先例は Web PKI です。ここではガバナンス（CAポリシー、Certificate Transparency）がサーバーに説明責任を負わせます。ガバナンスが失敗すると 、結果が生じます。クライアント側に同等の仕組みは今日存在しません。現在のツールはこの最初の領域の要素を基に第二の領域を目指しています：TLS フィンガープリント、IP アドレス、robots.txt。説明責任を試みますが、導出されたフィンガープリントが安定している限りでしか維持されません。
重要な区別は「誰」ではなく「何」
ウェブサイト運営者が着信トラフィックをどう扱うか決める際に意味のある区別は、必ずしもボット対人間ではありません。重要なのはオリジンが受け取るトラフィックを理解する必要と、クライアントのニーズを保護することのバランスです。