Moving past bots vs. humans｜ボットと人間の対立を超えて | AIニュース最前線

私たちがオンライン世界とやり取りするためには、何らかのゲートウェイが必要です。キーボード、画面、ブラウザ、デバイスなどです。オンラインで「ヒューマン検知」と呼ばれるものは、人間がこれらのデバイスとやり取りする際に使用するパターンです。近年、このパターンは変化しています。スタートアップのCEOはブラウザを使ってニュースを要約し、テック愛好家は夜にチケット販売が開始された際にコンサートチケットの予約プロセスを自動化し、視覚障害のある人はスクリーンリーダーでアクセシビリティ機能を有効にし、企業は従業員のトラフィックをゼロトラストプロキシ（zero trust proxies）経由でルーティングしています。 同時に、ウェブサイト所有者は依然としてデータの保護、リソースの管理、コンテンツ配信の制御、不正利用の防止を求めています。これらの問題は、クライアントが人間かボットかを理解するだけでは解決しません。望ましいボットもあれば、望ましくない人間も存在します。これらの問題には、意図と行動を知る必要があります。自動化を検知する能力は依然として重要ですが、アクター間の区別が曖昧になるにつれて、私たちが現在構築するシステムは、「ボット対人間」が重要なデータポイントではない未来を想定できるものでなければなりません。 実際問題として重要なのは、抽象的な「人間性」ではなく、以下のような問いです。これは攻撃トラフィックか？そのクローラーの負荷は返すトラフィックに比例しているか？このユーザーが新しい国から接続してくることを期待するか？私の広告は不正操作されているか？ 「ボット」という用語で私たちが議論しているのは、実のところ2つの物語です。1つ目は、ウェブサイト所有者がトラフィックを返さない既知のクローラーを通すかどうかです。私たちは、なりすまされることなく識別したいクローラーに対してHTTPメッセージ署名（http message signatures）によるボット認証を行うことで、これに触れてきました。2つ目は、ウェブブラウザが歴史的に組み込んでいたのと同じ行動を内包しない新しいクライアントの台頭です。これはプライベートレートリミット（private rate limit）のようなシステムにとって重要です。 この記事では、今日のウェブ保護がどのように機能しているか、そしてボットと人間の境界が消えゆく際にそれがどのように進化しなければならないかを探ります。 ### The Web we had 私たちがWebを利用するとき、毎日やり取りする何千ものサーバーと直接通信することはありません。私たちはウェブブラウザを使います。これらは「ユーザーエージェント（user agents）」とも呼ばれます。なぜなら、それらが私たちの代わりに行動し、私たちの利益を代表してくれるためです。これにより、サイトが私たちのコンピュータやスマートフォン全体にアクセスする権限を与えることなく、安全にショッピング、閲覧、動画視聴を行うことができます。 ウェブサイト側にも、ブラウザの動作に関する関心があります。彼らはコンテンツが正確に表示されることを確認したいのです（モバイル画面に適合しているか、適切な背景色であるか、正しい言語であるか）。ウェブサイトはまた、人々が購入を完了し、記事を読み、マイクを使用し、パスワードなしで安全にサインインできることを確保したいと考えています。さらに、記事の横にある広告を見てもらうことも望んでいます。 ブラウザユーザーとウェブサイトの利益間のこの緊張関係は長年にわたって続いてきました。パブリッシャー（コンテンツ提供者）は通常、ユーザーの体験に対してピクセルレベルの制御（pixel-level control）を望みますが、ブラウザの向こう側にいる人々は、パブリッシャーが想定していなかった方法でアクセスしたデータを利用したいと考えることがよくあります。 ウェブブラウザベンダーや、それに付随する標準化エコシステムは、これらの利益のバランスを取ることに細心の注意を払ってきました。時には大きな論争を巻き起こすこともありました。例えば、広告ブロックにブラウザ拡張機能（browser extensions）を使用できますが、時間とともにブラウザはこれらの拡張機能が実行できる操作を制限してきました。アクセシビリティ基準（例：WCAG）（Accessibility standards）は、ピクセルにこだわらない方法でウェブコンテンツを利用する道を開き、多くの地域で規制要件がこれを後押ししています。これらのトレードオフの具体的な内容について疑問を呈することは可能ですが、これらはセットで提供されます。ウェブを利用したいのであれば、パブリッシャーであれユーザーであれ、それを受け入れなければなりません。 しかし現在、そのバランスは変化しつつあります。アシスタントにニュースの要約や研究データの集約をさせるという概念自体は新しいものではありませんが、AIはこの機能をすべての人に民主化しました。摩擦が生じるのは、これらの新興クライアント（client）がどのように動作するかによるものです。人間のアシスタントは、パブリッシャーの知らないうちに記事を印刷したりスクリーンショットを撮ったりするかもしれませんが、それでも最初にサイトを表示するには標準的なウェブブラウザを使用します。AIエージェント（AI agents）はこのステップをバイパスし、ブラウザが構築したパブリッシャーの権利とユーザーの権利のバランスの取れたアプローチを混乱させます。それらはページを表示することなく、こっそりと生データを取得します。パブリッシャーにとって、これらは既存のブラウザトラフィックと重複するため、本質的に不透明です。ウェブサイト所有者は、取得されたコンテンツが1つのプライベートレポート（歪曲されている可能性もあれば、出典不明の可能性もある）を提供しているのか、それとも100万人のユーザー向けにモデルを学習させるために取り込まれているのかを判断できません。これは、サイトをオンラインで維持している予測可能（かつ収益化可能）なトラフィックを混乱させます。 ウェブを機能させていた暗黙の合意が崩れつつあります。その仕組みを理解するために、次のセクションではインターネット上の一般的なアーキテクチャについて解説します。 クライアント・サーバーモデル (client-server model) 一歩引いて、インターネット上の主要なデプロイメントパターン（deployment patterns）の1つであるクライアント・サーバーモデルを見てみましょう。クライアントはリソースを取得するためにサーバーにリクエスト（request）を送信します： `![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/61L0GkCvWVQl8TH2i2iwFp/899b2a1936aa7fbfaab45fca71d319d6/1.png)` 図1：クライアント・サーバーモデル。クライアントがリクエストを送信し、サーバーがそれに応答します。 より多くのリクエストを処理するために、ウェブサイトは提供能力を増やすことができます。追加のサーバーを展開したり、静的トラフィックの前にキャッシュ（cache）を配置したりできます。同様に、1人のクライアントがより多くのリクエストを送信する場合、またはクライアントの数が倍増する場合は、クライアント側からのリクエスト数が増加します。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/62BXZeYAXNXnwjKA5kNLWS/6c27205cf2467a42f568a8eaeaa46d7e/2.png) 図2：複数のクライアントが異なるサーバーに複数のリクエスト（request）を送信しており、その1つはCDN（コンテンツデリバリーネットワーク）で前面保護されている。 その単純さが、Webの成功を収めた要因の一つです。これにより多種多様なクライアントが存在可能となり、各サーバーが相手のエンドにどのようなソフトウェアがインストールされているかを正確に知らなくても、ネットワークを進化させることができます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/36loD91fUU6WotaZraCVHb/ddb9b5d9ad3fa9fc49f4c258dd56ed2b/3.png) 図3：サーバーにリクエストを送信する2つの異なるクライアントコンテキスト。各サーバーはリクエストのみを確認でき、背後にいるエンドユーザーは確認できません。 その開放性もまた不確実性を生み出します。ウェブサイトはリソースに対する有効なリクエストを確認できますが、通常、レスポンス（response）がサーバーを離れた後の状況は把握できません。キーボード、マウス、画面を使用してブラウザを操作する1人のユーザー向けにコンテンツがレンダリングされているのか、それとも独立したプログラムが自動的にリクエストを送信し、レスポンスをアーカイブしてインデックス付けし、より大きなシステムにフィードバックしているのか。 Bot management today このモデルは驚くほどよく機能します。そのため、インターネットに接続されたWebサーバーを起動するだけでウェブサイト運営が可能なほどシンプルになるのです。この状態は、サーバーがどのリクエストを提供し、信頼し、優先するかの判断を迫られるまで維持されます。 場合によっては、これは容量（capacity）の問題です。グローバルで1秒あたり100リクエストを処理するようにサービスがプロビジョニング（provisioned）されているのに、200のリクエストを受信している場合、特定のリクエストをドロップ（drop）する必要があります。サーバーにCPUが1つしかないのに、受信リクエストが2つの処理を必要とする場合も同様です。200を提供するコストが高すぎる場合は、すべてのリクエストにレートリミット（rate-limit）を適用する必要があります。 リクエストをランダムにドロップすることもできます。不公平である可能性があり、必要なクライアントにも影響して目標から外れるかもしれませんが、機能します。他のシグナルがない場合、他に選択肢はありません。 容量は全体の状況の一部に過ぎません。サーバーは他にも多くの理由でクライアントを区別しようとします：攻撃を通常のトラフィック（traffic）から分離するため、悪意のない負荷を管理するため、データ抽出を防ぐため、広告詐欺（ad fraud）を制限するため、偽アカウントの作成を防ぐため、またはユーザーに代わって行われる自動化されたアクションを停止するためです。 難しさは、Webクライアントがデフォルトで認証されていないにもかかわらず、多くの部分的なシグナルを公開している点にあります。そのため、ほとんどのサーバーは受信情報に基づいてアクセス制御ロジック（access control logic）を適用することを決定します。単一のIPアドレス（IP address）が他のクライアントの10倍のリクエストを送信している場合、ブロックされる可能性があります。さらに踏み込むサーバーは、このIPアドレスがVPN（仮想プライベートネットワーク）によって使用されており、したがって複数のユーザーのトラフィックをプロキシ（proxies）していると推測するかもしれません。サービスは係数を適用することを決定できます：各クライアントが1秒あたり10リクエストを送信できると仮定した場合、共有IPアドレスではリクエストがドロップされる前に100 rps（1秒あたりのリクエスト数）まで許可されます。 これがボット管理（bot management）の鍵の一つです。これは、サーバーがクライアントに関するより多くの情報を取得し、意思決定を支援することを目的としています。この情報は本質的に不正確です。なぜなら、クライアントはサーバーの制御下にあるわけではないからです。さらに、同じ情報が指紋ベクトル（fingerprint vectors）を生成し、サーバーはこれをパーソナライズされた広告など異なる目的で使用できます。これにより、軽減（mitigation）のベクトルが追跡（tracking）のベクトルへと変貌します。 大まかに言えば、サーバーはクライアントから以下のシグナル（signals）を受信します。 受動的クライアント・シグナル（passive client signals）：インターネット上でリクエストを送信する際に必須となるもの。クライアントは必ずIPアドレスを送信し、通常はTLSセッション（TLS session）を確立します。 能動的クライアント・シグナル（active client signals）：クライアントが自発的に提供し、エンドユーザーには見えないことが多いもの。これにはUser-Agentヘッダー（User-Agent header）や認証資格情報（authentication credentials）が含まれます。 サーバー・シグナル（server signals）：サーバーが観測する情報。例えば、リクエストを処理するエッジサーバーの地理的位置や、リクエストを受信した現地時刻などです。 大量の悪用（volumetric abuse）を制限し抑制するため、オリジン（origin）にとって重要なのは、クライアントが複数回リクエストを送信する能力と意図です。広告収入で成り立つウェブサイトの場合、オリジンは広告が実際にエンドユーザーに表示されていることを確信する必要があります。ブランドを保護するため、オリジンはクライアントに特定のレンダリング機能があることを確認したい場合があります：PDFリーダー、SVGレンダラー（SVG renderer）、仮想キーボードなどです。また、リクエストがインターセプティング・プロキシ（intercepting proxy）から来ている場合、オリジンはそのリクエストが実際にエンドクライアントから発信されたものであることを確認したいと考えるかもしれません。 トラフィックが増加すれば、運用コストも増大します。クライアントが金銭的かどうかを問わず価値を生み出さない場合、サーバーにはそのコストを負担するインセンティブがありません。 異なるオペレーターは、この環境に対してそれぞれ異なる対応を取ります。一部の大型クローラー（crawlers）やプラットフォームは、予測可能なアクセスが「追跡可能であることのコスト」に値するため、自らを識別します。それはむしろ有益な場合もあります。一方、他の者は識別を避けるよう努めます：ブロックされることを予想しているため、匿名性を求めているため、あるいはエンドユーザーに代わって運用しているためです。その結果は、部分的なシグナルに基づいた不安定な均衡です。 これが「人間対ボット」という枠組みが誤解を招く理由です。オリジンが関心を持つのは、抽象的な「人間性」ではなく、クライアントがサイトがサポートできる方法で行動しているかどうかです。 余談：レート制限のトリレンマ（rate limit trilemma） ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5FUj1FBUj2t46fUeyG3NES/616b8505016c40648659baa21093cca7/Rate_limit_trilemma_1_.png) 図4：レート制限のトリレンマ。分散型、匿名、責任追跡可能 — 2つを選択 私たちがインターネット上でのアクセスを管理する方法には、根本的な緊張関係があります。分散型、匿名、責任追跡可能 — 2つを選択してください。 完全な分散型＋匿名とは、責任追跡不可能を意味します。ブロックされたクライアントは、その評判に影響を与えることなく新しいアカウントを生成できます。これは、オリジンがリソースを管理するためにより多くの投資を行わなければならないことを意味します。これがウェブのデフォルトです。 デセントラライズド（分散型）＋アカウンタビリティ（追跡可能性）とは、誰もがあなたの正体を知っていることを意味し、特定のユースケースでは機能するものの明確な欠点があります。「Log in with」に代表されるOAuth（Open Authentication）メカニズムを想像してみてください。これにはアカウント登録が必要であり、第三者に対して活動内容を公開することになります。 アノニマス（匿名）＋アカウンタビリティ（追跡可能性）を実現するには、おそらくガバナンス、ルール、そして執行機構が必要です。同じアクターに対してこの両方の性質を達成している広く展開されたシステムは存在しません。最も近い先例はWeb PKI（Public Key Infrastructure）であり、ここでガバナンス（CAポリシーやCertificate Transparency）がサーバーを追跡可能にしています。このガバナンスが失敗すれば、何らかの代償が生じます。しかし現在、クライアント側に対応する同等の仕組みは存在しません。 現在のツールは、最初の空間（追跡可能な領域）の要素を基盤として構築し、第二の空間（匿名＋追跡可能）を目指しています：TLSフィンガープリント、IPアドレス、robots.txtなどです。これらは追跡可能性を試みていますが、派生するフィンガープリントが安定している間しか機能しません。 The important distinctions are what, not who 受信トラフィックをどのように処理するかを決定するウェブサイト所有者にとって、意味のある区別は必ずしもボット対ヒューマンではありません。それは、受信トラフィックを理解したいオリジン（送信元サーバー）のニーズと、プライバシーを保護したいクライアントのニーズとのバランスを取ることにほかなりません。 Platforms and services that want to be identifiable ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2m1T5Ukuy3Ton2aUjTMNcj/6ebfdb2e3cf33dcb07f2a485bbe59d24/5.png) Figure 5: A crawler makes multiple request to a server 一部のトラフィックは、大量のリクエストを送信する既知のオペレーターから来ます：検索エンジンクローラー、クラウドプラットフォーム、エンタープライズインフラストラクチャです。これらのアクターはしばしばプライバシーへの期待が低いです。彼らは識別可能なソースから数百万件のリクエストを送信するインフラストラクチャです。リクエストの送信元を識別できる能力は、インフラプロバイダーが過度なリクエストを送信したり、アクセスすべきでないページにアクセスしたりした場合の誤判断を軽減するのに役立ちます。自己識別（Self-identification）は、私たちが提案した責任あるAIボットの原則の一つです。CloudflareがRadar用のURLスキャナーを運用したり、クローリング機能を公開したりする仕組みは、これらの原則に基づいています。 この種のトラフィックにおいて、アイデンティティ（正体）は機能します。より正確には、一部のオペレーターは帰属可能なリクエストを許容できます。なぜなら、確実なアクセスの価値があるからです。HTTP Message Signatures（HTTPメッセージ署名）を用いたWeb Bot Authにより、オペレーターは暗号学的にリクエストに署名することができます。例えばOpenAI、Google、Cloudflare、AWSは、自プラットフォームから発生するリクエストに署名を行います。オリジンは、IPアドレス範囲やUser-Agent文字列に依存することなく、「このリクエストは本当にプラットフォームのインフラから来たものだ」と検証できます。 ヒューマン（人間）やその他のエンドユーザーは、識別可能であること以外の期待を正当に持っています。それは、アクセスと品質の経験（QoE）を犠牲にすることなく匿名性を維持するためです。 Distributed traffic that needs anonymity ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/BjltTNLM7u2OXd5IF8MAx/d46604ea762973096496193ebfd3e79b/6.png) 図6：3つの異なるブラウザがサーバーにリクエストを送信する。1つは人間が操作し、1つはデバイス上のアシスタント（on-device assistant）が操作し、1つは企業のプロキシ（corporate proxy）を経由してプロキシされている。 その他のトラフィックは多くのソースから発生しており、それぞれが比較的低頻度のリクエストを送信している。これにはウェブを閲覧する人間、測定を行う研究者、住宅用プロキシ（residential proxies）を使用するスクレイパー、そして人間に代わって行動するAIアシスタント（AI assistants）が増加していることが含まれる。 さらに、ボット（bots）と人間の区別はもはや意味をなさないものとなっている。コンサートチケットを予約するAIアシスタントと、それを手動で行う人間には本質的な違いはない。両者は分散型であり、両者に匿名性（anonymity）が必要である。それぞれのケースにおいて、オリジン（origin）は、サービスを意図通りに利用しようとするユーザーに対して、悪用するユーザーよりも摩擦（friction）を少なくしたいと考えるだろう。 識別情報（Identity）は機能しうる。IPアドレスに対して持っていた古い前提を置き換えるためには、特定のクライアントに紐づく一意で検証可能な属性のセットを提供し、アカウントログイン、メールアドレス、またはハードウェアキーを通じて証明されなければならない。しかし、それはウェブサイトにアクセスする際にこの識別情報を提示する必要性を意味し、さらにプライバシー（privacy）を損なうことにもなる。 私たちは、識別情報を証明することなく行動（behavior）を証明する現代的なソリューションを構築したいと考えている。 ウェブ向けの匿名認証情報（Anonymous credentials for the Web） 2019年以来、Cloudflare経由でウェブサイトにアクセスするクライアントは、リクエストとともにプライバシートークン（privacy token）を送信することで、このような行動の証明を提供できるようになっている。これはCloudflareがPrivacy Passを早期にサポートした結果である。RFC 9576およびRFC 9578で標準化されたPrivacy Passは、課題を解決したなどの事前チェックの裏付けを持つ証明を発行者（issuer）がバックアップする形でクライアントが持ち運べるようにし、その結果を安定した識別子（stable identifier）に変えることはない。これは、過去のどの訪問、リクエスト、またはセッションとも関連付けられないトークンを定義するものである。 これは重要である。なぜなら、フィンガープリント（fingerprinting）とは異なるモデルを提供しているからである。パッシブな信号を収集するのではなく、サーバーはクライアントに対してアクティブなプライバシー保護（privacy-preserving）信号を求めることができる。 これにより、セッション確立（session establishment）における摩擦が軽減される。Privacy Passは、主にプライバシーリレーサービス（privacy relay services）向けに、Cloudflareのインフラ全体で1日数十億個のトークンへとスケールしている。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3JBjW747zg5fBv2jCyhBrv/5de23a5ddb6b5057580224eedb9ba0a9/7.png) 図7：RFC 9576のセクション3.1からのPrivacy Pass償還および発行プロトコルの相互作用 RFCは4つの役割を強調しています。発行者（イシューア）は、資格情報（RFCではトークン）を発行する前にいくつかのチェックを行うために、1つ以上の証明者（アテスター）を信頼します。クライアントはこれらの資格情報を保持し、適切なスコープ内でいつ提示するかを決定します。オリジンは、どの発行者を信頼し、各提示が何を意味するかを制御し続けます。これは悪用やポリシーに関する問題を除去するものではなく、単にクライアントとサーバーに対して、それらを処理するためのプライバシーを保護する方法を提供します。 このシステムは単純ですが、限界もあります。例えば、動的なレート制限（dynamic rate limits）を許可するものではありません。クライアントに100個のトークンが発行され、最初のセッションまたは2番目のセッション後にリソースを過度に消費し始めた場合、以前発行された残りのトークンを無効化する手段がありません。 さらに、リンク不能性（unlinkability）の性質のため、新しい発行者が台頭するのは困難です。オリジンは、発行者トークンが伝えるシグナルの品質について、フィードバックメカニズムを提供する方法を持っていません。 最後に、発行者が提供するトークンの数と、それらのトークンが償還される際に使用して作成できるリンク不能な提示（unlinkable presentations）の数の間には、1:1の関係があります。つまり、提示ごとにトークン1つです。理想的には、クライアントが発行者に一度接触し、後で特定のオリジンのコンテキストにスコープを限定した複数の提示を行えるシステムを望みます。それは、単一使用のトークンを繰り返し取得するのではなく、ユーザーエージェント（user agents）が保証された資格情報を保持し、それらから派生した証明を提示する方向を示しています。 私たちの目標は、オープンなプライベートなレート制限エコシステムの確立を支援することです。その精神に基づき、私たちはAnonymous Rate-Limit Credentials（ARC）やAnonymous Credit Tokens（ACT）などの新しいPrivacy Passのプリミティブ（primitives）を開発・探求するのを支援しています。 例えば、ACTでは、クライアントは「私はこのサービスに対して良好な履歴を持っています」といったことを、「私はこのユーザーです」と明らかにすることなく証明できます。ACTは、ここで重要な暗号学的性質（cryptographic property）である、プロトコルレベルでの提示間のリンク不能性を維持します。RFC 9576の4.3節にある共同発行者-オリジン展開モデル（joint issuer-origin deployment model）でさえ、トークンの発行と提示が直接リンクされないようにプロトコルが設計されています。ただし、IPアドレス、クッキー、アカウント状態、タイミングなどの他の層を通じた相関を排除するものではありません。ACTが実装する逆フローフレームワーク（reverse flow framework）内において、標準化されたVOPRFおよびBlindRSAのプリミティブを使用して、同じ性質を提供することができます。 成功するエコシステムは、オープンな発行者エコシステムである必要があります。実際には、それは誰でも資格情報をミントできるという声明以上のことを意味します。オリジンは信頼する発行者を決定できる必要があります。ユーザーエージェントには、要求されているものを提示するための一貫した方法が必要です。また、エコシステムには、発行者が評判を確立し、信頼する側（relying parties）が低品質な発行者の信頼を停止する方法が必要です。単一のゲートキーパーが参加を制御すべきではありません。 これを機能させるためには、ブラウザやその他のユーザーエージェント（user agent）で動作するプロトコル（protocol）とクライアントAPI（client API）が必要です。デプロイは容易で、ユーザーにとって明確であり、かつ

ボットと人間の対立を超えて

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト