Cloudflareがエージェントとサイトの関係に関する立場表明を公開しTAD連合を発表:サイト側の課題14項目とWeb Bot Auth、MOLEなどを軸にした計画、ただし標準の多くはドラフトでホワイトペーパーは未公開、提供済みの制御はCloudflare経由のトラフィックに限られる
2026年11月5日、Cloudflareは長い立場表明を公開し、個人エージェントをユーザーとサイトの間の仲介者と位置づけ、サイト側の課題14項目を挙げ、明確に定義された問題をIETFに持ち込むTrusted Agent Delegation連合の発足を発表しました。計画はWeb Bot Auth、MOLE、x402などの標準を軸にし、アイデンティティを、なし、セッション、アカウント、固有の4段階に分けることを提案しています。関連製品を販売するベンダーの主張で、課題のどれも数量化していません。標準の多くはまだドラフトで、連合のホワイトペーパーは未公開、アカウント不正防止は早期アクセス、Business InsightsはEnterprise Bot Management顧客向けです。
2026年11月5日、CloudflareはBryan Beckerによる長い立場表明「Agents aren't humans (but they kinda are)」を公開し、Trusted Agent Delegation(TAD)連合の発足を発表しました。11月4日の個人エージェントの可視化と制御に関する製品記事の続きですが、その内容は本号では繰り返しません。新しいのは議論と標準化の計画です。この文書は、ボットやアクセス制御を販売するベンダーによる主張であり、コストや必要性についての記述はCloudflare自身の枠組みです。
出発点は、個人AIエージェントは仲介者だという点です。エージェントはユーザーの代わりに動き、通常は運営者がマネージドサービスとして運用し、運営者のインフラからサイトに到達します。サイトに見えるのはユーザーではなくエージェントで、1つのエージェントが多くのユーザーを運ぶこともあります。Cloudflareは、サイトがこの関係を管理するには通常、アイデンティティ、評判、説明責任の三つが必要だと述べます。唯一の指針である「仲介原則」は、間に何が入っても、ユーザーとサイトの取引関係と各当事者のセキュリティ上の責任が維持されなければならないというものです。運営者の例としてMetaのMuseとOpenAIのdotsを挙げ、エージェントのトラフィックが近い将来、通常の人間のブラウジングを上回るかもしれず、そうなれば仲介者をブロックする従来の対応は成り立たなくなると述べています。
問題を具体的にするため、4人の依頼主の用事を引き受ける個人アシスタントのEzraの話のあと、サイト側の課題14項目の表を示します。アカウント共有、フレンドリー詐欺、なりすまし、トラフィックの混在(1人の依頼主が共有エージェントを悪用するとサイトはエージェントしかブロックできず、全ユーザーが巻き込まれる)、リソースの枯渇、コンテンツの無償消費、そしてCAPTCHAやリスクベース認証が設計どおりに働かなくなることなどです。Cloudflareは、ほぼすべての場合に主なコストをサイトが負うと結論づけます。これは推論と例に基づく主張で、測定ではなく、14項目のどれも数量化されていません。
Cloudflareは、よくある二つの案がなぜ不十分かも説明します。CAPTCHAをユーザーに回しても、その瞬間に誰かがいることしか証明できず、残りの時間にエージェントが誰のために動くかは分からず、エージェントが取り除くために存在する手間を戻してしまいます。アクセス範囲を狭める案は、エージェントがあらゆる権限を求めるため実際にはあまり使われず、狭い範囲でも示すのはエージェントに許されたことであり、問題が起きたときに誰が責任を負うかではありません。
提案される方向は、既存と新しい標準の組み合わせです。アイデンティティではCloudflareはWeb Bot Authを推します。エージェントが自分のリクエストに署名する方式で、同社の文書はIETFのドラフトに基づき、Ed25519鍵を使い、決まったwell-knownパスに鍵ディレクトリを置くことを求めると説明しています。記事は未解決の場合として、ブラウザーの中であるエージェントが別のエージェントを使うケースを挙げ、サイトが連鎖全体を見られる必要があると述べます。文書には、運営者のアイデンティティをそのような連鎖で運ぶためにForwardedヘッダーを試していると書かれ、実験的で変更される可能性があると注記されています。ユーザー識別子なしのレート制限にはMOLEを挙げ、Private Access Tokensの後継を意図したものと呼び、支払いにはx402を挙げます。識別情報は四つの段階、つまり何もなし、セッション、アカウント、第三者による固有の識別子に分け、サイトは必要以上に求めるべきでないと述べます。18歳以上であることやカード名義人であることといった主張を運ぶ方法や、エージェントに何が許されるかをサイトが機械可読で公開する方法も求めており、IETFのAI Preferencesワーキンググループは学習や検索のような利用の好みを扱うが、Cloudflareの見方ではより広い必要性は扱っていないと指摘します。
発表の中心はTAD連合です。掲げる目標は、エコシステム全体の代表を集めて課題群を議論し、既存のプロトコルを検討し、明確に定義された問題をIETFへ持ち込むことで、IETFの会合やワークショップで併設会合を開く予定です。連合のサイトはホワイトペーパーが近く公開されるとし、想定される一例として、リピーターの買い物客がエージェントを替えても、サイトは買い物客との関係を保ち、共有される個人情報を限定するという場面を示しています。ユーザー自身の端末で動くローカルやオープンソースのエージェントは、最初の焦点ではないとされています。
記事の最後は、Cloudflareの顧客が今できることで、これは11月4日の機能の言い直しです。Security Analyticsは個人アシスタントを独立したトラフィック分類にし、エージェントごとのアクセスポリシーで、あるエージェントを許可する、広告のあるページだけでブロックする、完全にブロックするを選べます。早期アクセス段階のアカウント不正防止は、ログインやサインアップが個人エージェントからか、どのエージェントかを示し、ハッシュ化したユーザーIDに対するWAFルールで個別のアカウントに対処できます。AIクローラーのトラフィックの全体像については、Enterprise Bot Management顧客向けのレポートツールBusiness Insightsも挙げられています。
私たちの見方です。役に立つのは語彙と失敗事例の一覧で、サイト運営者は14項目のどれが当てはまるかを確認できます。標準の多くはまだドラフトで、MOLEは「意図されたもの」と書かれ、ホワイトペーパーは未公開、すでに提供されている制御もCloudflareを通るトラフィックに限られます。この連合は採用された標準ではなく、表明された意図として扱うのが妥当です。
Sources
FAQ
TAD連合は採用された標準ですか?
違います。Cloudflareが発表した連合で、エコシステムの代表を集め、既存のプロトコルを検討し、明確に定義された問題をIETFへ持ち込むことを目標にしています。連合のサイトはホワイトペーパーが近く公開されると述べています。MOLEはPrivate Access Tokensの意図された後継とされ、Forwardedヘッダーの方式は実験的で変更される可能性があると注記されています。
記事の14項目の課題にはデータの裏付けがありますか?
数量化されたデータはありません。記事はEzraの話と14項目の表で問題を説明し、ほぼすべての場合に主なコストをサイトが負うと断じています。これは推論と例であって測定ではありません。著者の会社はボットとアクセス制御を販売しているため、コストと必要性の主張はCloudflare自身の枠組みとして読むべきです。
記事に出てくるCloudflareの制御はすべて今使えますか?
すべてではありません。Security Analyticsは個人アシスタントを分類として数え、エージェントごとのアクセスポリシーもありますが、アカウント不正防止はまだ早期アクセスで、Business InsightsはEnterprise Bot Management顧客向けです。これらの制御はCloudflareを通るトラフィックにのみ及ぶ製品機能で、プラットフォームを超えた標準ではありません。