ウェブにゲートキーパーは不要: Cloudflareの新しい「Signed Agents」提案
(positiveblue.substack.com)- Cloudflareの Signed Agents ポリシーは安全を名目としているが、実際には ウェブへのアクセスを許可制にする閉鎖的な試み
- ウェブは歴史的に オープン性と標準 によって成長してきており、Flash・Silverlightのような閉鎖技術は最終的にHTML5のようなオープン標準に押されて姿を消した
- 今後のウェブの主要な利用者は AIエージェント となり、そのためには 分散され検証可能な認証基盤と、タスク単位の権限付与 が必要
- 望ましいモデルは チェーンベースの委任 + リクエスト単位の証明 を組み合わせ、信頼できる認証ときめ細かな権限管理を実現すること
- 特定企業が鍵を握るのではなく、オープンなプロトコルと標準 を通じて誰もが参加し革新できるウェブを守るべき
CloudflareのSigned Agentsへの批判
- Cloudflareは新しい Signed Agents システムを提案したが、これは事実上 許可リストベースのアクセス制御
- 特定企業がエージェント登録の可否を判断するのは、インターネットプロトコルではなくベンダー承認制 にすぎない
- これはインターネットのオープンな性質と衝突しており、「フォームを書いて許可を得ること」が標準になることはない
ウェブはオープンであるべき
- 90年代のMicrosoftの 「embrace and extend」戦略 は失敗しており、それが可能だったのはウェブがオープン性を維持したから
- FlashやSilverlightのような 閉鎖的ランタイム は、最終的にHTML5というオープン標準に置き換えられた
- 歴史は常に、オープン標準がイノベーションを促進する ことを証明してきた
エージェント時代の到来
- AIエージェントは今後ウェブの中核的な利用者となり、情報検索、自動化、決済、契約交渉 などを担う
- 人間とエージェントの行為の境界は曖昧になっていき、これは 委任ベースの認証基盤 を必須とする
認証(Authentication)と認可(Authorization)
- 認証: 誰が行動しているのか?
- 認可: 何ができるのか?
- Cloudflareはこの2つの概念を混同し、「パスポート」であらゆる問題を解決しようとしているが、これは根本的に不可能
- 正しい認証は 委任チェーンとリクエスト単位の署名 を通じて実装されるべきであり、DNSベースの公開鍵発行のような 分散型の検証メカニズム を活用すべき
権限管理
- 既存ソフトウェアは 限定されたスコープ のおかげでOAuthのスコープモデルがうまく機能していた
- しかしエージェントは汎用的であるため、タスク単位(Task-Scoped)の権限付与 が必要
- 例: 「夕食の支払い」権限と「3か月分の支出履歴の照会」権限は、同じエージェントでも 別々のトークン を持つべき
- そのために、Macaroons, Biscuits のような制約ベースのトークンや、OPA/AWS Cedar のようなポリシーエンジンを活用できる
プロトコル優先、ゲートキーパー排除
- 認証、認可、収益化は特定企業ではなく、オープンで相互運用可能な標準 の上で行われるべき
- 少数の企業がエージェントの有効性を判定するなら、ウェブはやがて 閉じた庭園(Walled Garden) に転落する
- したがって、チェーンベースの委任、リクエスト単位の証明、タスクスコープの権限付与を オープンソースとして提案 し、誰でも実装できるよう共有する
結論
- ウェブの未来は「誰がゲートを支配するか」ではなく、誰もが共に構築し革新できるプロトコル にかかっている
1件のコメント
Hacker Newsの意見
誰もが完全に自由でオープンなウェブを夢見ているが、実際には小さなブログやコンテンツを持つ人がAIトレーニングボットから身を守る方法がほとんどないことに失望している。AgentとTrainingボットを区別して robots.txt を本当に尊重してくれると信じるのは現実的ではない。たとえ robots.txt を守るとしても、「licensed data」という名目でデータを間接的に買い集める構図は続く。Reddit、X、Google、Meta のように法的リソースがほぼ無限な企業でない限り、個人には力がない。関連して面白い動画もおすすめする
誰もが望む自由で開かれたウェブと、AIトレーニングボットを遮断したい気持ちは互いに矛盾しているように感じる。皆に開かれたウェブなら、AIトレーニングボットも例外なくアクセスできるべきだ
（オープンウェブの夢について）インターネット上でオープンなコンテンツを実現する夢は現実だ。自分のブログは人間でも機械でも誰でも自由にアクセスできるようにしている。自分のサーバーも自宅で直接ホスティングしているので、わざわざ人間とAIを区別する必要性を感じない。もしウェブサイトへのアクセスが多くなりすぎることを心配するなら、実際には人間でもAIでも過剰なトラフィックそのものが問題だ。robots.txt ではボットがループに陥らないための最小限のガイドだけ置き、自由にクロールできるようにしている。Amazonbot も自分のサイトに頻繁に来るがいつでも歓迎だ
敵対的なソフトウェアに対抗する自由ソフトウェアを開発すべきだと思う。大企業は敵対的なAIエージェントを開発し、それに対抗して有能なハッカーは anti-AI-agent を開発すべきだと考える。「私たちには力がない」という敗北主義には同意しない
ここ Hacker News には多くの大手IT企業のエンジニアがいるにもかかわらず、自分たちの業務におけるプライバシーやデータガバナンスには触れず、いつも別の話題にだけ声を上げている現実を指摘している。自己反省のための鏡が必要なら自分は買う意思がある
小規模ブログやコンテンツをAIトレーニングボットから守るべきだという問い自体が、なぜ出てくるのか分からない。もし基本的なHTML生成すら難しく、重く複雑なフレームワークを使わざるを得ず、その結果CPUリソースを大量に消費しているなら、それこそが本当の問題だと思う。あるいは自分のオンライン上の文章がコンテンツクリエイターとしての富や名声への道だと考えているなら心配するのも分かるが、そうでなければ問題自体がないと思う
現実的には「ウェブ」はすでにずっと前からオープンではないと思う。大半の相互作用、投稿、情報流通は認証（ログイン）の裏側で行われている。主要SNSや新聞社などの多くは未認証のアクセスを制限または遮断している。ブログは一般の人が消費する情報全体の中でごくわずかな割合にすぎない
自分もAI Agentそのものは気にしない。背後に実際の利用者がいるなら構わない。しかし Meta、Perplexity、OpenAI などが自分のサイトを激しくクロールするのには大きな不満がある。実際のユーザーやGoogle検索よりも多くのリソースをAIクロールが占めている。CPUコアがAIクロールに縛られる現象は本当に腹立たしい
自分も個人用アプリをいくつかオンラインに置いているが、先月あるAIボットが1.6TBのデータをさらっていき、Cloudflare の AI bot protection 機能を有効にするしかなかった。1日130万回を超えるリクエストが絶え間なく来て、とても耐えられなかった
自分のマーケティングサイトの一部では、毎秒200〜300回レベルでリクエストが来る。しかも存在しないURLまでランダムに作って叩いてくるなど、制御不能なレベルだ
AI企業がウェブクロールのためにどれだけのCPUサイクル（計算資源消費）を発生させているのか気になる。通常AIの環境影響というとトレーニングやサービス推論だけを考えがちだが、実際にはウェブクロールが追加の負荷を与えている点も考慮すべきだ。正確に比較するには、人間の利用者が直接その動作をした場合と比べて、ボットがより効率的にトラフィックを発生させるよう設計されているなら意味がある。つまりトラッカーや画像など付随要素は最小限だけ呼び出し、目標の問い合わせに必要なものだけを取るなら、人類全体がブラウザで直接訪問するよりCPU負荷がむしろ少なくなる可能性もある
自分も同じだ。AI agent を使うことの背後に実ユーザーがいて、異常に過剰なアクセスでなければあまり気にしない。（自分が AI agent の利用を意図したわけではないが、誰がどう使おうと構わない。）ただし過剰なクロールは嫌だ。一方でもっと重要なのは、誰かが単に
curlでファイルを1つダウンロードしたり、Lynx のようなテキストベースのブラウザを使うこともあり得るという点だ。こうしたシナリオも引き続きサポートされるべきだと思うCloudflare は、ある「ユーザーが試みた agent」は許可し、別の agent は遮断するという形で、実際のユーザーではなくトレーニングデータ収集のための無差別クロールと区別している。Meta、Perplexity、OpenAI が送る大半のリクエストは、実ユーザーのプロンプトに応じて動くウェブ検索機能であり、このリクエストが次のLLMモデルのトレーニングに使われるわけではない。Cloudflare は両者の違いをあえて曖昧にし、公式には「クリエイター保護」を掲げながら、実際にはLLMプロバイダーから「通行料」を受け取って自社の利益を残す仕組みを作っている。結局、公平性ではなく金銭的動機だと思う
自分は個人情報をあまり露出しない珍しいブラウザを使っているが、Cloudflare から見れば自分もボット同然に見える。ホスト（ウェブサイト所有者）がアクセス権限を決める環境では、プライバシーは存在し得ないと思う。サーバー負荷を防ぐための rate limiting には同意するが、自動化アクセスそのものを防ぐのは実質的に不可能で、結局こうして遮断していくと実際の利用者のアクセスまで難しくなる
もしかして今も Cloudflare や turnstile のせいで頻繁にブロックされる経験があるのか気になる。上でもすでに示唆されていたが、はっきり確認したい
もし独裁的な国家に住む人たちがプライバシーと自由のためにVPNを使わなければならないなら、インターネットは2〜3社が運営する captcha 地獄になる。自分で作った bot で Cloudflare 保護下のウェブサイトにアクセスするときより、むしろVPNとプライバシーブラウザで普通にネットサーフィンするときのほうが問題が多い。ちなみに Microsoft がもしウェブのゲートキーピングを担っていたらさらにひどかったはずだ。特にVPNを使って Microsoft の captcha を通過しようとすると、論文を1本書く覚悟で5分以上集中してやっと突破できる
ウェブサイトの所有者にも当然権利がある。運営に必要な財政的持続可能性のために gatekeeping を選ぶなというのは無理な主張だ
自分も珍しいブラウザを使っていて bot blocker に引っかかることが多い。ただ、ホストが自分のリクエストを自由に扱える権利もあると思う。特に政府サイトの場合は、すべての人に公平にサービスする責任がはるかに大きいと思う
もっとオープンなやり方に良い代替案があるなら聞きたい。しかし現状、Cloudflare のやり方はAIボットの現実的な問題をうまく解決している。これまでIPブロックや user agent でも防ごうとしてきたが限界があった。そして実際、ほかのセキュリティ問題もこうしたやや中央集権的な方法で解決されてきた。証明書発行機関（certificate authority）もオープンなシステムではなく、attestations の提供者もオープンシステムではないが、うまく機能している
もう少しオープンなソリューションを望むなら、規制が答えかもしれない。ウェブサイト運営者が robots.txt で明示的に許可していないクローラーのリクエストを法的に禁止し、執行機関が直接取り締まればよい。もし運営者が bot トラフィックを立証できれば政府に通報して巨額の罰金を科せる。クラウドサービス事業者には誰がどのIPを使ったかの記録を残すよう義務付けることも可能だ。100%の解決策ではないが、きちんと実施されれば十分に強い抑止効果を与えられる
この方法が最善の解決策ではないかもしれないが、現実的にはある程度機能するソリューションだ。中央集権化の問題を指摘する声は多いが、Cloudflare が主要AI企業とCDNをすべて参加させることに成功すれば、事実上の標準として定着し得ると思う
証明書は、人をボットと誤認したからといってブロックしたりはしない
むしろ AI poisoning（データに意図的に誤情報を混ぜてAIを妨害する方法）のほうが効果的な保護だと思う。Cloudflare 自体が AI bot に誤ったデータを意図的に与えるサービスも可能だ
実際、CA は Let's Encrypt が登場する前までは、一般企業のウェブサイト、それもログインページの一部でしか使われないことが多かった。もし Let's Encrypt のオープンな方針がなければ、私たちの個人情報はいまでもISPや中間者にそのまま露出していただろう。Attestation の提供者も、デバイスの脆弱性が広く知られてもビジネス判断のために認証取り消しを拒むなど無力だ。結論として、大半の議論では本当の代替案をうまく見つけられていないように思う。Cloudflare がインターネットのゲートキーパーになるのは悪い解決策だが、問題そのものはそれよりはるかに深刻だ。完全に分散したソリューションもすでに存在はする（例: remote attestation、有料訪問/サブスクリプションモデル、セルフホストのファイアウォールなど）。AIの副作用を無視して、費用だけ払えという態度が Cloudflare をさらに大きくしてきた原因だ。もしISPなどがスプーフィング、DDoS、ボットネットのような問題を放置していなければ、Cloudflare は単に Akamai のような競合の一つにとどまっていただろう
すでにゲートキーパーが多すぎる世界だ。どんな追加の gatekeeper の試みも攻撃的な行動と見るべきだ。Cloudflare も Google も、自分たちの gatekeeper としての立場をさらに強く押し出している。この傾向が続くなら、両社とも完全に崩れるのを見たい
複数の企業がAIボット問題の解決策を出そうとしているが、Cloudflare が選ばれれば莫大な利益を得ることになる。ただし Cloudflare が退いても問題が消えるわけではなく、別の企業のよくない代替案が採用されるだけだ。gatekeeping は実質的にウェブサイト所有者が自分の選択で採るオプションだ（例: paywall、独自の bot 検知、ID認証など）。Cloudflare はすでにこうしたサービスを提供しており、もし標準化まで進めば選択肢は増え、市場もさらに開く（副作用込みで）。真のオープンウェブの自由は、訪問者だけでなくサイト所有者にも同じように適用されるべきだ
Google が未来の gatekeeper になろうという「欲望」は行き過ぎている。すでに Google は Chrome ブラウザのシェアによって何年も gatekeeper の役割を果たしてきた。Firefox の存在感も薄れている。Google が www 全体を自分の望む方向へ導いているという見方だ（uBlock の禁止、
.webpフォーマットの押し付けなど）単一企業が運営する allowlist を問題視する前に、実際にはサイト運営者が自分でそのサービスを選んだという事実がある。面白いのは、「公平性」について理念的な観点から論じながら、ブログにはAIツールで作った漫画を載せるなど、現実の生活ではすでにAIが深く入り込んでいるという矛盾だ
Cloudflare は emerging Web Bot Auth 標準を実装中で、私たち Stytch も IsAgent.dev で同じ標準を適用している。現在の議論にはかなり過熱した面があるので慎重でありたいが、結局 allowlist は Cloudflare の顧客に提供されるオプションにすぎず、HTTP Message Signature のようにコア部分はオープンで分散的に設計されているため、誰でも使える
ある企業の allowlist を自分の選択で使うこと自体は大きな問題ではないが、それだけでプロトコルにはならない。そして公平性をめぐる論争とAI漫画の利用は、論理的には関係がないように見える
frying pan/fire（最善ではないがよりましな次善策）な状況で、特定企業のソリューションが公然たる標準のように残る懸念がある。今回を機に本当のプロトコル/標準ベースのソリューションが作られる可能性もあったのに、Cloudflare は自分のブルーオーシャンを作ろうとしている。そして「公平性」を主張しながら、実際にはAI活用を生活の至る所で行っている点を皮肉っぽく突いている
電子メールの構造に似ていると思う。電子メールはインターネット標準に基づいているが、実際には Gmail などごく少数のサービス提供者が大半のユーザーを抱えている。Cloudflare もオープン標準そのものを推しているが、実際の力は大規模顧客の数から生まれる。（良い代替手段は何か、という問いも投げかけている。）また電子メールもスパムフィルタリングの過程で配送信頼性が低く、実装が難しいという問題があるように、ウェブも似た道をたどる余地がある
ウェブは attestation や signed agent、Cloudflare が誰を「本物の」エージェントと決めることを望んでいない。皆が「public」の意味を改めて認識し、トラフィック処理が厳しいなら単に基本的な rate limiting だけを行うのが最適だ。ウェブは人間か、ボットか、犬かを問う必要はなく、適正なリソースの範囲内でリクエストした者すべてにバイトを提供すればいい。この「オープンウェブ」の本質が失われれば、誰もが惜しむことになるだろう
基本的な rate limiting でさえ攻撃に弱い。ボットネットを無視することはできず、IPv6 に移行すると有効な rate limiting は事実上不可能になる。バケットの切り方を誤ると、一部のネットワーク事業者は /48 帯域を簡単に配ってしまうため制限が無力化されたり、モバイル利用者は数十万人が1つの rate limit にまとめられたりする
このやり方は結局、多くの小規模ウェブサイトにトラフィックをさばけず閉鎖しろと言っているのと変わらない。「オープンインターネット」というスローガンと矛盾する
最新のAIクローラーは、今や悪性ボットネットと区別できなくなっている。まともな rate limiting はもはや意味をなさず、ここが Cloudflare が問題解決に乗り出した理由だ
「public はすなわち PUBLIC」という主張は、基本的な rate limiting だけで運用できれば理想的だが、実際には許容可能なアクセス速度を明示して公開する必要がある。しかし
user-agentが違うというだけで、1回リクエストしただけでもブロックされる事例が多い。結局、運営者は bot の振る舞いではなく identity だけを見て、あらゆるリクエストを遮断する傾向がある。判断基準が粗く、誤検知を大量に生み、その場合でも試行内容や文脈はまったく検討されず、単に identity を見てブロックが決まる基本的な rate limiting 自体も実装が簡単とは限らないことが多い。特定の認証や権限委任が必要な場合でない限り、公開ファイルへのアクセスには認証や権限委任は別途必要ないと思う。こうした委任の問題があるとしても、実際の委任者の役割以外で Cloudflare のような第三者が介入する必要はない
筆者の意見には概ね同意する。エンタープライズ環境では、複雑なプライベートネットワーク内で agent の振る舞いをどう制御するかが悩みだ。最近 biscuit ベースの「identity token」システムを自作してみた。この token によって自分自身が認証を受け、その後は委任 token を作って下位 agent にも渡せる。自分のシステムでは authorization token がなければ何もできない（シングルスコープ、シングルユースの概念）。インターネット上なら identity token + 少額決済（例: ごく小さな crypto 取引）と引き換えに authorization token を渡すことも想像できる。そうすれば人間のユーザーにはほぼ費用がかからず問題なく、AIクローラーだけが多く支払うことになる