ウェブにゲートキーパーは不要：Cloudflareの新しい「サイン付きエージェント」提案

2025年8月30日原文(positiveblue.substack.com)

概要

Cloudflareの「signed agents」提案は、表向きは安全性向上だが、実際はオープンウェブの精神に反する危険性を孕む。単一企業による許可制は、インターネット本来の分散性と相容れない。認証と認可は異なる課題であり、両者を混同した「ボットパスポート」構想は本質的な解決策にならない。真の解決策は、分散型・検証可能・委譲可能な認証モデルの採用。プロトコル主導の標準化が、今後のエージェント時代のウェブの自由と発展を守る鍵。

Cloudflareの「signed agents」提案の問題点

Cloudflare が提案する「signed agents」は、 許可リスト制 の導入
開発者やサービス提供者に 申請フォーム での登録を要求
インターネット のオープン性や標準化の精神に反する運用
申請制は標準ではなく、 ベンダーの承認制 に過ぎない
単一企業による 中央集権的な管理 の危険性

オープンウェブの歴史と教訓

Microsoft が90年代にウェブの囲い込みを試みたが失敗
HTML5 や Open Web Platform が Flash や Silverlight などの独自ランタイムを駆逐
オープンな標準が イノベーション を促進
ベンダー主導の許可制は 発展を阻害 する

エージェント時代の新たな課題

AI agents が情報取得・自動化・購入・契約交渉など多様な役割を担う時代
人間とエージェントの 境界が曖昧化
- 例：「友人にスマホを渡して返信を頼む」＝委譲の体現
認証（ 誰が行動しているか）と認可（ 何ができるか）の違い
Cloudflareは両者を 単一パスポート で解決しようとしているが本質的に不十分

「ボットパスポート」構想の限界

パスポート（署名）だけでは 真正性の担保が不十分
委譲の 証明チェーン と リクエストごとの署名 が必要
単一署名 の使い回し＝セキュリティリスク
必要なのは「 User X on Service YがAgent Zに委譲」のような 証明構造

望まれる認証・認可モデル

検証可能性 ：誰でも独立に確認できる
合成可能性 ：委譲チェーンを跨いで機能
分散性 ：単一のゲートキーパーが存在しない
公開鍵暗号 によるDNS証明の応用
- 企業はDNSで公開鍵を公開し、第三者認証を実現
- 申請や中央ディレクトリ登録不要

エージェント時代の認可の課題と解決策

従来の OAuthスコープ は特定用途向けで有効だった
エージェント は汎用的かつ短命な場合が多い
「 admin key」のような全権限付与は危険
認可はタスクごとに発行、エージェントごとではなくタスクごとにトークンを制御
マカロン（macaroons）やビスケット（biscuits） 等、細粒度・短命・委譲可能なトークンの活用
Open policy engines （OPAやAWS Cedar）によるRBAC/ABACの実装

委譲チェーンとリクエスト単位の認可モデル

User X が Service Y でadminトークンを保持
Agent Z に1タスク限定のトークンを派生
Agent Z がサブエージェント用にさらに限定トークンを派生
各リクエストごとに 委譲チェーンの検証 が可能

標準化と分散型プロトコルの重要性

この課題は Cloudflare や Google、 Microsoft 一社の問題ではない
未来のウェブ はプロトコル主導でなければならない
認証・認可・マネタイズは オープン・相互運用・標準化 が必須
数社による「有効エージェント」決定権の集中は ウェブの囲い込み を招く危険

今後のアクションと呼びかけ

委譲チェーン・リクエスト単位認可・タスクスコープ認可 のアイデアを オープンソース化
誰でも実装・議論・協力が可能な体制
興味・共感・批判・協力希望は jordi@fewsats.com まで連絡を推奨
未来は「 ゲートを握る者」ではなく、「 誰もが構築・共有・革新できるプロトコル」に託すべき

Hackerたちの意見

Aiエージェントには全く問題ないけど、背後に本物のユーザーがいるならね。MetaやPerplexity、OpenAIみたいな悪質な業者に、俺のサイトがめっちゃ攻撃的にクロールされるのは大問題だよ。AIがクロールするせいで、CPUコアをいくつも使ってるって気づくのが本当にイライラする。実際のユーザーやGoogleなんかよりも少ないのに。

└

俺の小さいマーケティングサイトのいくつかは、200-300RPSに達していて、URLをめちゃくちゃに妄想してる。マジで狂ってる。

└

Cloudflareは、どのユーザーがウェブサイトのコンテンツを読むことができるかを制限しようとしてるけど、これはもちろん、ウェブサイトをスクレイピングしてトレーニングデータを集めるのとは全然違うよね。Meta、Perplexity、OpenAIは、ユーザーのプロンプトに基づいてリクエストを送るウェブ検索機能を持ってる。これらは次のLLMをトレーニングするために保存されるリクエストじゃない。Cloudflareは両方のタイプのボットの境界を意図的に曖昧にしていて、その意味では「コンテンツクリエイターを守る」と言いながら、真ん中に立ってLLMプロバイダーから料金を取ってクリエイターに支払うという詐欺的な手法を使ってるんだよね（もちろん、自分たちも利益を取る）。これは公平だからやってるわけじゃなくて、金銭的な動機があるんだ。

└

自分の個人アプリがいくつかあって、CloudflareのAIボット保護をオンにしなきゃいけなかった。というのも、そのうちの一つが先月1.6TBのデータにアクセスされて、1日で130万リクエストも来てたから。もう止まることなく叩かれてたよ。

└

AI企業がコンテンツをスクレイピングすることで、どれだけのCPUサイクルが消費されてるのか気になるな。この要素は「AIの環境影響」を見積もるときにはあまり考慮されてないよね。このことが推論やトレーニングにどれだけのオーバーヘッドをもたらすんだろう？公平に言えば、正確な測定には、ボットを動かしている人間のユーザーがどれだけのCPUサイクルを使うかも考慮する必要があると思う。その観点から見ると、スクレイパーは効率的にクローリングすることで「埋め合わせ」ができるかもしれない。つまり、クエリを解決するために必要ない限り、トラッカーのスクリプトや画像を読み込まないようにするってこと。こうすれば、CPUサイクルは消費するけど、少なくともヘッドフルなブラウザインスタンスを持つ人間のユーザーよりは少なくなるはず。

└

自分のサイトがMetaやPerplexity、OpenAIなどの悪質な業者にすごく攻撃的にクローリングされるのに大きな問題を抱えてるよ。もし、インターネットの中央アーカイブみたいなものがあればいいのに。そうすれば、これらのAI企業はその単一の存在と合意の上で直接やり取りできるんだ。

タイトルは「ウェブにはゲートキーパー（Cloudflare）がいらない」って意味かもね。終わりの方でそう言ってるし。>「我々はゲートキーパーではなく、プロトコルが必要だ。」でも、実際に機能するプロトコルができるまで、多くのウェブマスターはサイトを安全に保つためにゲートキーパーが必要なんだよね。こんなことは望んでないけど、プロトコル時代は、ユーザーをロックインする非オープンなプロトコルを持つWeb 2.0プラットフォームが出てきた時に終わったと思う。Facebookは、AIMやMSN、IRCの隣でオープンなクライアントでMessengerを使わせたくないんだよね。そして、悪者が勝った。まあ、間違ってたらいいけど。

もしオープンな解決策があるなら、ぜひ教えてほしい。でも、CloudflareがやってることはAIボットの本当の問題を解決してるんだよ。IPブロックやユーザーエージェントでこの問題を解決しようとしたけど、全然うまくいかなかった。実際、他の似たような問題もこうやって解決されてきたんだ。証明書機関はオープンじゃないけど、ちゃんと機能してるし、アテステーションプロバイダーもオープンじゃなくても問題なく動いてる。

└

AIポイズニングの方がいい保護策だと思う。Cloudflareは、クライアントを守るためにAIボットに悪いデータを供給することができるんだ。

└

同意。これが最善の解決策とは言えないかもしれないけど、うまく機能している解決策ではあるよね。中央集権は悪だとか言ってるけど、もしCloudflareが主要なAIプレイヤーを巻き込めたら、主要なCDNも参加させることができたら… ipso facto columbo oreo…スタンダードになるかも。

└

証明書機関は、ボットに「見える」人間をブロックしないよ。

これは、メールがインターネット標準に基づいているけど、大部分のメールユーザーがGmailを使っているのと似てる。Cloudflareが推進しているインターネット標準はオープンだけど、顧客が多いからCloudflareには大きな力があるんだよね。（Cloudflareの良い代替案は何？）状況が似ているもう一つの点は、メール配信はスパムフィルターのせいで不安定で実装が難しいこと。ウェブでも似たようなことが起きてるみたい。

Hacker Newsで議論の続きを見る

ハクソク