このニュースの概要： 2026年8月のCloudflare Agents Weekはエージェントウォレットなど一連の機能を発表したが、構造的に重要な変化は8月7日に発表された信頼スコアリングの転換だ——「一度検証を通過すれば通行可能」から「すべてのリクエストが累積行動に基づいて再評価される」への転換である。これは一般的な「身元認証＝エージェントが署名しているか、チェックを通過したか」という静的な理解とは異なる。新しい仕組みの下では、チェックを通過することは出発点にすぎず、その後のエージェントのあらゆる行動が継続的にスコアに反映され、信頼状態自体が動的かつ常に変動しうるものになる。
見た目との違い：多くの報道は「エージェントについにウォレットができた」という点に焦点を当てたが、ウォレットは今回の更新の中では相対的に副次的な部分にすぎない。長期的な運用リスクに実質的に影響するのは信頼スコアリングロジックの転換であり、この点は多くの報道でほとんど掘り下げられていない。
なぜCloudflareはこのタイミングでこの変更を行ったのか： 直接の要因はMatthew Prince氏が公表したデータだ——自動化システムが生成するHTMLリクエストの割合が57.5%に達し、予想より約18か月早く到来した。自動化トラフィックが人間のトラフィックの規模に迫る、あるいはそれを超えるようになると、「入り口で一度身元を検証すれば通行可能」という静的モデルの防御効率は急速に低下する。悪意ある行為者は一度検証を通過しさえすれば、その後は長期にわたってそのパスをどんな行動にも利用でき、防御側はその後の行動に基づいて再評価する手段をまったく持たない。
これはまた、なぜCloudflareが同じ週に「お金」（Wallets）と「継続的信頼スコアリング」を同時に打ち出したのかも説明する。エージェントが実際に資金を保有し動かし始めると、静的検証のリスクは「無駄なトラフィックが少し増える」から「実際の金銭的損失が発生する」へと格上げされる。このリスク階層の変化こそが、防御ロジック全体を一度きりの検証から継続的監視へと転換させなければならなかった根本的な理由だ。
具体的な仕組み： この継続的信頼スコアリングの下には、実は二つの技術層が重なっている。第一層はWeb Bot Authが提供する身元層だ。RFC 9421規格のHTTPメッセージ署名を用い、各エージェントが専用のEd25519鍵ですべてのリクエストに署名し、Signature-Agentヘッダーと公開鍵ディレクトリを組み合わせることで、サーバー側は「このリクエストは本当にそのエージェントから来たものか」を確認できる。この層は2025年からすでに本番インフラであり、2026年8月に変わったわけではない。
第二層こそが今回の実際の変更点だ——「Unveiling good and bad behaviors」で説明されている継続的行動評価である。エージェントが第一層の署名検証（身元の証明）を通過した後も、システムは「何をしているか」を監視し続ける。リクエスト頻度、アクセスパターン、触れるべきでないリソースに触れていないかといった行動データが、継続的に信頼スコアモデルへ反映される。二つの層を合わせると、身元は静的（署名は一度なされれば有効であり続ける）だが信頼は動的（今日の良い行動は明日の信頼スコアを保証しない）ということになる。
読者にとっての実際的な影響： 外部サイトやAPIにアクセスするエージェントや自動化システムを開発・運用しているなら、このニュースの実際的な意味は、「身元認証を正しく設定した」ことを一度きりのセキュリティチェック項目として扱えなくなり、継続的に追跡すべき運用リスクへと変えなければならないということだ。具体的な行動として、本記事で示した4項目の監査（ドメインのSPF/DKIM/DMARCが整合しているか、ウェブコンテンツがJavaScriptなしで読めるか、料金・連携・セキュリティページが画像やPDFではなくテキストで事実を記載しているか、自動化されたスクレイピングやブラウジングが署名されているか）を一通り確認すること。データ収集やスクレイピングをサードパーティベンダーに委託している場合は、「ベンダーが対応しているはず」と前提せず、署名状況について書面での確認を積極的に求めること。
より長期的な意味としては、この仕組みは現在まだ確定していない草案標準の上に構築されており、CloudflareとIETF草案の間にはすでに実装上の矛盾（辞書形式 vs 構造化文字列形式）が存在する。つまり近い将来、あなたのエージェントは仕様自体が変動していることが原因で、予期しない検証失敗に遭遇する可能性が現実的にある。これはあなたのコードの問題ではなく、エコシステム全体がまだ急速に変化している証拠であり、トラフィックが原因不明で落ち込んでから調査するのではなく、事前に監視とアラートを設定しておく価値がある。
2026年8月3日から7日にかけて、Cloudflareは「Agents Week」を開催し、エージェントの身元と資金に関わる一連の新機能を集中的に発表した——Cloudflare Wallets（プログラマブルなエージェント用ウォレット）、cloudflare.pay（エージェントの加盟店向け識別子）、Agent Access Model（リソースアクセスの枠組み）。しかしこの週で本当に記憶すべき日は、8月7日に公開された「Unveiling good and bad behaviors on the Agentic Internet」だ。この記事は、Cloudflareのボット対策ロジックを「一回限りのリスクスコア」から「継続的な信頼スコアリング」へと根本的に書き換えた——この変化はウォレット機能自体よりもはるかに重大な意味を持つが、多くの報道ではほとんど触れられなかった。
従来のボット対策ロジックは、本質的に「訪問者が入り口で一度資格情報を提示し、検証が通れば通行を許可する」というものだった——これは最小権限の原則を従来型のアクセス制御に適用した典型例であり、一度認可すればその範囲内で実行し続ける仕組みだ。Cloudflareの今回の変更は、この論理をすべて「その訪問者からのすべてのリクエストが再評価される」という形に置き換えた。評価の根拠は最初に提示した資格情報ではなく、蓄積された行動パターンだ。つまり、2年間クリーンにスクレイピングしてきたデータベンダーが、行動パターンの変化を理由に来月再分類される可能性があり、しかも事前の警告もなければ誰も積極的に知らせてはくれない。
多くの報道は8月の発表を「エージェント身元認証」の出発点として扱ったが、実際の時系列はまったく異なる。Cloudflareは2025年5月にすでにWeb Bot Authを提案しており、RFC 9421規格のHTTPメッセージ署名、エージェントごとのEd25519鍵、Signature-Agentヘッダー、公開鍵ディレクトリを用いて、自動化クライアントがすべてのHTTPリクエストに署名できるようにしていた。2025年8月にはすでに、Block社のGoose、Browserbase、Anchor Browserを含む最初の署名済みエージェントのコホートを発表済みだった。
さらに報道されていないのは、2025年10月14日にすでにCloudflareが主要な決済ネットワークと協力し、Web Bot Authを基盤としたエージェント商取引向け認証層の構築を発表していたことだ。VisaはTrusted Agent Protocolを共同開発しVisa Intelligent Commerceに組み込み、MastercardはAgent Payに組み込み、American Expressも自社のエージェント商取引プログラムでの採用を約束した。つまり「このエージェントが自分の身元を証明できるか」という問いは、2026年8月のウォレット機能が登場するはるか前から、すでに本番稼働中のインフラだった——8月に本当に新しく加わったのは「お金」の部分だけだ。
2026年6月3日、Cloudflare CEOのMatthew Prince氏はRadarのデータを公開し、世界のHTMLコンテンツへのHTTPリクエストのうち57.5%が自動化システムによるもので、人間は42.5%にとどまると発表した。しかしこの数字には見落とされやすい条件が付いている。この測定はCloudflareのネットワーク上のHTMLページリクエストのみを対象としており、すべてのインターネットトラフィックではない。同時期、Cloudflareの全トラフィックにおけるボット指標は約35.2%だった——HTMLリクエストは画像、スクリプト、API呼び出し、動画、ゲームを除外しており、これらは人間がはるかに高い割合でトラフィックを生成するカテゴリだ。
Web Bot Authはまだ正式な標準ではない——IETFが作業部会を設立したのは2026年初めで、2026年8月12日時点でその部会はまだ1件の文書も正式採択していない。一方でCloudflare、AWS、Akamai、HUMAN、Vercelは毎日本番環境でこれらの署名を検証し、どのエージェントがどのウェブサイトにアクセスできるかを決定している。
あなたのエージェントがウェブをクロールしたり、サードパーティAPIを呼び出したり、ユーザーの代わりに加盟店とやり取りしたりする場合、継続的な信頼スコアリングは重要な前提を変える——一度検証を通過すれば無期限に稼働し続けられるという前提はもはや成り立たない。あなたのエージェントは今、三つの面でリスクにさらされている。送信側の身元インフラ（ドメイン、鍵、署名がすべて整っているか）、自動化データ収集（依存しているサードパーティのスクレイパーやベンダーが署名しているか、誰の身元で署名しているか）、そしてプラットフォームとのやり取りにおける自動化行動パターン自体（一度きりの検証ではなく継続的に評価される）だ。
あなたのエージェントや自動化システムが外部サイト、API、プラットフォームへの長期的で安定したアクセスに依存しているなら、継続的信頼スコアリングがもたらすリスクは、今日正常に動いているものが明日予告なく格下げされたりブロックされたりする可能性があることだ。実際にできることとして、あなたのエージェントや自動化パイプラインがWeb Bot Authで署名しているかを確認すること（答えが「ベンダーが対応している」なら、それを前提とせず書面で明確な回答を求めること）、データ収集サービスに依存している場合は署名の有無と誰の身元で署名しているかを直接尋ねること、そして継続的信頼スコアリングを一度きりの確認で済ませるものではなく、継続的に追跡すべきリスク項目として扱うことだ。