2026-04-21 Thibault Meunier 15分読了
はじめに
オンラインの世界と相互作用するために、私たちは入り口が必要です：キーボード、スクリーン、ブラウザ、デバイスです。オンラインで「人間検出」と呼ばれるものは、人間がこのようなデバイスと相互作用するときに使用するパターンです。これらのパターンは近年変わってきました：スタートアップのCEOは現在、ブラウザを使ってニュースを要約し、テック愛好家は夜間にチケット販売が開始されたときにコンサートチケットを予約するプロセスを自動化し、視覚障害のある人はスクリーンリーダーのアクセシビリティを有効にし、企業は従業員トラフィックをゼロトラストプロキシ経由でルーティングしています。
同時に、ウェブサイトの所有者は依然としてデータを保護し、リソースを管理し、コンテンツ配信を制御し、悪用を防ぐことを望んでいます。これらの問題は、クライアントが人間かボットかを知ることでは解決されません：望ましいボットもあれば、望ましくない人間もいます。これらの問題は、意図と行動を知ることが必要です。
自動化を検出する能力は依然として重要です。しかし、アクター間の区別が曖昧になるにつれて、今構築するシステムは「ボット対人間」が重要なデータポイントではない未来に対応する必要があります。実際に重要なのは、抽象的な人間性ではなく、次のような質問です：これは攻撃トラフィックか、そのクローラーロードは返すトラフィックに比例しているか、このユーザーがこの新しい国から接続することを期待しているか、私の広告がゲーム化されているか。
「ボット」という用語で議論する内容
「ボット」という用語で議論する内容は、実は2つのストーリーです。
1つ目は、ウェブサイトの所有者がトラフィックを返していない既知のクローラーを通すべきかどうかです。これは、自分自身を偽装されずに識別したいクローラーのためのHTTPメッセージシグネチャを使用したボット認証で触れています。
2つ目は、ウェブブラウザが歴史的に埋め込んでいたのと同じ動作を埋め込まない新しいクライアントの出現です。これはプライベートレート制限などのシステムにとって重要です。
この投稿では、ウェブ保護が今日どのように機能するか、そしてボットと人間の線が薄れるときにそれがどのように進化する必要があるかを探ります。
私たちが持っていたウェブ
ウェブを使用するとき、私たちは毎日相互作用する数千のサーバーと直接通信しません。ウェブブラウザを使用します。これらは「ユーザーエージェント」としても知られています。なぜなら、私たちの代わりに行動し、私たちの利益を代表しているため、サイトに私たちのコンピュータまたは電話全体へのアクセスを与えることなく、安全にショッピング、読書、ウェブを視聴できるからです。
ウェブサイトもブラウザの動作方法に関心があります。彼らは自分たちのコンテンツが正確に表示されることを確認したいのです（モバイルで画面に合う、正しい背景色、正しい言語）。ウェブサイトはまた、人々が購入を完了し、記事を読み、マイクを使用し、パスワードなしで安全にサインインできることを確認したいと考えています。また、人々が記事の横に広告を見ることも望んでいます。
ブラウザユーザーとウェブサイトの利益の間のこの緊張は長い間続いています。パブリッシャーは通常、ユーザーの経験をピクセルレベルで制御したいと考えていますが、ブラウザの向こう側の人々は、パブリッシャーが想定していない方法でアクセスするデータを使用したいと考えていることが多いです。
ウェブブラウザベンダーとそれらの周りの標準エコシステムは、これらの利益のバランスを取ることに細心の注意を払ってきました。時には大きな論争を伴って。例えば、ブラウザ拡張機能を使用して広告をブロックできますが、時間とともにブラウザはそのような拡張機能ができることを制限してきました。アクセシビリティ標準（例：WCAG）は、ピクセルに関するものではないウェブコンテンツを使用する方法を開きました。多くの場所で規制要件によってサポートされています。
これらのトレードオフの詳細については異論があるかもしれませんが、それらはパッケージとして提供されます：ウェブ上にいたい場合、パブリッシャーであろうとユーザーであろうと、それを受け入れる必要があります。
バランスの変化
しかし、そのバランスは今シフトしています。アシスタントにニュースを要約させたり、研究を集約させたりすることは新しい概念ではありませんが、AIはこの機能を誰もが利用できるようにします。摩擦は、これらの新しいクライアントがどのように動作するかから生じます。
人間のアシスタントは、パブリッシャーが知らないうちに記事を印刷したりスクリーンショットを撮ったりするかもしれませんが、それでも最初にサイトをレンダリングするために標準的なウェブブラウザを使用します。AIエージェントはこのステップをバイパスし、ブラウザが構築したパブリッシャーとユーザーの権利のバランスの取れたアプローチを破壊します。ページをレンダリングせずに静かに生データを取得します。
パブリッシャーにとって、既存のブラウザトラフィックとの重複のため、これらのクライアントは本質的に不透明です。ウェブサイトの所有者は、取得したコンテンツが1つのプライベートレポート（おそらく歪んでいる、おそらく帰属していない）を提供しているのか、それとも100万人のユーザーのモデルをトレーニングするために取り込まれているのかを判断できません。これは、サイトをオンラインに保つ予測可能な（そして収益化可能な）トラフィックを破壊します。
ウェブを機能させた暗黙の合意は崩壊しています。
クライアント・サーバーモデル
一歩下がって、インターネット上の主要なデプロイメントパターンの1つを見てみましょう：クライアント・サーバーモデルです。
クライアントはサーバーにリソースを取得するためのリクエストを送信します。
より多くのリクエストを処理するために、ウェブサイトは容量を増やすことができます。追加のサーバーをデプロイするか、静的トラフィックの前にキャッシュを配置できます。同様に、クライアント側からのリクエスト数は、1つのクライアントがより多くのリクエストを行う場合、またはクライアント数が増加する場合に増加する可能性があります。
このシンプルさはウェブが成功した理由の一部です。多くの種類のクライアントが存在することを可能にし、各サーバーが反対側にどのようなソフトウェアがあるかを正確に知る必要なく、ネットワークが進化することを可能にします。
その開放性はまた不確実性を生み出します。ウェブサイトはリソースの有効なリクエストを見ることができますが、通常、レスポンスがサーバーを離れた後に何が起こるかを知ることはできません：コンテンツがキーボード、マウス、スクリーンを使用してブラウザを制御する1人の人間のためにレンダリングされているのか、または独立したプログラムがリクエストを自動的に行い、レスポンスをアーカイブし、インデックスを付け、より大きなシステムに供給しているのか。
今日のボット管理
このモデルは驚くほどうまく機能します。これがウェブサイトの運営がインターネットに接続されたウェブサーバーを起動するのと同じくらい簡単である理由です。サーバーがどのリクエストを提供、信頼、または優先順位付けできるかを決定する必要があるまでのみ保持されます。
時々それは容量についてです。サービスが1秒あたり100リクエストをグローバルに処理するようにプロビジョニングされているが、200を受け取っている場合、特定のリクエストをドロップする必要があります。サーバーに1つのCPUしかないが、受信リクエストに2つが必要な場合、リクエストをドロップする必要があります。200を提供するコストが法外である場合、すべてのリクエストをレート制限する必要があります。
ランダムにリクエストをドロップできます。おそらく不公平であり、望ましいクライアントに影響を与えることで目標を逃す可能性がありますが、機能します。他の信号がない場合、他に選択肢はありません。
容量は全体像の一部にすぎません。サーバーはまた、多くの他の理由でクライアント間を区別しようとします：攻撃を通常のトラフィックから分離する、非悪意のあるロードを管理する、データの抽出を防ぐ、広告詐欺を制限する、偽のアカウント作成を防ぐ、またはユーザーに代わって自動化されたアクションが実行されるのを停止する。
困難なのは、ウェブクライアントはデフォルトで認証されていないが、多くの部分的な信号を公開しているということです。したがって、ほとんどのサーバーは、受け取った情報に基づいてアクセス制御ロジックを適用することを決定します。
単一のIPアドレスが他のIPアドレスの10倍のリクエスト数を行っている場合、ブロックされる可能性があります。さらに進むサーバーは、このIPアドレスがVPNによって使用されていると推測し、したがって複数のユーザーのトラフィックをプロキシします。サービスは係数を適用することを決定できます：各クライアントが1秒あたり10リクエストを行うことができると仮定すると、共有IPアドレスはリクエストがドロップされるのを見る前に1秒あたり100リクエストが許可されます。
これはボット管理の鍵の1つです：サーバーにクライアントに関する詳細情報を提供して、決定を下すのに役立つことを目的としています。この情報は本質的に不正確です。なぜなら、クライアントはサーバーの制御下にないからです。さらに、同じ情報は、パーソナライズされた広告などの異なる目的のためにサーバーによって使用できるフィンガープリントベクトルを作成します。これは緩和ベクトルを追跡ベクトルに変換します。
高いレベルでは、サーバーはクライアントから次の信号を見ます：
- パッシブクライアント信号：インターネット上でリクエストを行うために必要です。クライアントは必ずIPアドレスを送信し、通常はTLSセッションを確立します。
- アクティブクライアント信号：クライアントによって自発的に提供され、エンドユーザーに見えないことが多いです。これには、User-Agentヘッダーまたは認証資格情報が含まれます。
- サーバー信号：サーバーが観察する情報。リクエストを処理するエッジサーバーの地理的位置、またはリクエストが受信される現地時間など。
体積的な悪用を制限およびキャップするために、オリジンにとって重要なのは、クライアントが複数のリクエストを行う能力と意図です。広告資金のウェブサイトの場合、オリジンは広告が実際にエンドユーザーに表示されていることを確信する必要があります。ブランドを保護するために、オリジンはクライアントが特定のレンダリング機能を持っていることを確認したい場合があります：PDFリーダー、SVGレンダラー、仮想キーボード。リクエストがインターセプトプロキシから来ている場合、オリジンはリクエストが実際にエンドクライアントから発信されていることを確認したい場合があります。
トラフィックが増加すると、運営コストも増加します。クライアントが金銭的またはそうでない価値を生成しない場合、サーバーはそれらのコストをカバーするインセンティブを持ちません。異なるオペレーターはこの環境に異なる方法で対応します。
大規模なクローラーとプラットフォームの一部は、予測可能なアクセスが帰属可能であるというコストの価値があるため、自分自身を識別します。それはさらに役立つかもしれません。他の人は識別を避けようとします：ブロックされることを期待しているため、匿名性を求めているため、またはエンドユーザーに代わって動作しているため。
結果は、部分的な信号に基づいて構築された不安定なバランスです。これが人間対ボットのフレームが誤解を招く理由です。オリジンが気にするのは、抽象的な人間性ではなく、クライアントがサイトがサポートできる方法で動作しているかどうかです。
余談：レート制限のトリレンマ
分散型、匿名、説明責任 — 2つを選択してください。
インターネット上のアクセスを管理する方法には、根本的な緊張があります：分散型、匿名、説明責任 — 2つを選択してください。
完全に分散型+匿名は説明責任がないことを意味します。ブロックされたクライアントは、その評判に影響を与えることなく新しいアカウントを生成できます。これは、オリジンがリソースを管理するためにより多くの投資をする必要があることを意味します。これはウェブのデフォルトです。
分散型+説明責任は、誰もが誰であるかを知っていることを意味します。これは特定のユースケースに対して機能しますが、明らかな欠点があります。「ログイン」などのOAuthメカニズムを考えてください。これにはアカウント登録と第三者への活動の開示が必要です。
匿名+説明責任は、おそらくガバナンス、ルール、および執行を必要とします。同じアクターに対して両方のプロパティを達成する広く展開されたシステムはありません。最も近い前例はWeb PKIです。ここでガバナンス（CA ポリシー、Certificate Transparency）がサーバーに説明責任を持たせます。そのガバナンスが失敗すると、結果があります。クライアント側に同等のものは今日存在しません。
現在のツールは、その最初のスペースの要素に基づいて構築され、2番目を目指しています：TLSフィンガープリント、IPアドレス、robots.txt。彼らは説明責任を試みていますが、派生したフィンガープリントが安定したままである限りのみ保持されます。
重要な区別は「誰」ではなく「何」
受信トラフィックを処理する方法を決定するウェブサイトの所有者にとって、意味のある区別は必ずしもボット対人間ではありません。それはオリジンが受け取るトラフィックを理解する必要性とクライアントがプライバシーを保護する必要性のバランスを取ることについてです。