「人間かボットか」を超えて：CloudflareのPrivacy Pass・Web Bot Auth・Agent Registryで変わるアクセス制御

AIを使って記事を要約するCEO、コンサートチケットの先行販売にスクリプトを使う技術者、スクリーンリーダーで音声読み上げをする視覚障害者、ゼロトラストプロキシ経由でWebにアクセスする企業社員——。

これらはすべて「ボット」か「人間」か。

Cloudflareは2026年4月、この問いへの答えとして「Moving past bots and humans（人間とボットを超えて）」という技術ブログを公開した。「ボットか人間か」という二分法は、現代のインターネットではすでに意味をなさない。むしろ問うべきは「これは攻撃トラフィックか」「クローラーの負荷は妥当か」「広告詐欺に使われているか」だ。

本記事では、CloudflareのPrivacy Pass・Web Bot Auth・Agent Registry・ARC（Anonymous Rate-Limit Credentials）という4つの技術スタックと、その背後にある設計思想を詳しく解説する。AIエージェントが急増する2026年、Webアクセス制御のパラダイムが根本から変わろうとしている。

「人間かボットか」という問いが崩壊した理由

従来のボット対策は単純な二分法に基づいていた。リクエストが人間から来ているか、ボットから来ているか——それを判定して、人間はOK、ボットはブロック。しかし現実はもっと複雑だ。

人間が起動するボット的なトラフィックの例：

• CEOがAIを使って記事を要約させる（自動化ツール経由でWebにアクセス）
• 技術者がコンサートの先行販売でチケット予約スクリプトを走らせる
• ブラウザ拡張機能がページの内容を自動翻訳・要約する
• RSSリーダーが定期的にフィードを取得する

ボットが人間の代わりに動くケース：

• スクリーンリーダーがウェブページを読み上げる
• 企業のゼロトラストプロキシが全社員のトラフィックをルーティングする
• クラウドサービスの出口IPからアクセスする在宅勤務者

AIエージェントの台頭でこの境界はさらに曖昧になった。ChatGPT Operator、Claude Agentをはじめとするエージェントはユーザーの指示に基づいて自律的にWebを操作する。これは「ボット」なのか「人間の代理」なのか——どちらでもあり、どちらでもない。

Cloudflareが指摘する通り、実際に問うべき問いはボット/人間の区別ではなく次のような質問だ：

• このトラフィックは攻撃か？
• クローラーの負荷は妥当か（サーバーに過度な負荷をかけていないか）？
• 予期しない国・リージョンからのアクセスか？
• 広告詐欺に使われているか？
• AIトレーニング目的か、ユーザーへのリアルタイム応答か？

これらの問いには「人間かボットか」という情報は含まれていない。

従来のボット検出の技術的限界

サーバーがクライアントについて受け取れる情報は3種類に分類できる：

IPアドレスに基づくボット検出は特に問題が多い。AWS・Google Cloud・Cloudflare自身のIPレンジからのトラフィックには、正規のAIエージェントも悪意あるスクレイパーも混在している。IPブロックは正規ユーザーへの誤検知を量産する。

Privacy Pass：1日数十億トークンを処理するCAPTCHA代替技術

Cloudflareが現在最大規模で運用している匿名認証技術がPrivacy Passだ。

Privacy Passの仕組みと特性

Privacy PassはRFC 9576（アーキテクチャ）とRFC 9578（トークン実装）で標準化されたプロトコルだ。基本的な考え方はシンプルで、「以前のチェック（CAPTCHAなど）を通過した証明」を匿名で再利用する仕組みだ。

フローは次の通り：

# Privacy Pass トークン発行フロー（概念）
[クライアント側]
1. nonce = random()          # ランダムな使い捨て値を生成
2. blind_msg = blind(nonce, r)  # ブラインドファクターrで盲目化
3. 発行者へ blind_msg を送信

[発行者側]
4. blind_sig = sign(blind_msg, private_key)
   # 重要: 発行者はblind_msgの内容を知らないまま署名する
5. クライアントへ blind_sig を返す

[クライアント側]
6. sig = unblind(blind_sig, r)  # ブラインドを解除
7. token = (nonce, sig)
# 発行者はnonceを知らないため、将来の使用と発行を紐付けられない

このフローにより「チャレンジを解いた正規ユーザー」であることを証明しながら、誰が証明したかは明かさないという特性が実現される。

暗号的な基盤：VOPRFとBlindRSA

Privacy Passを支える暗号プリミティブは2つある。

VOPRF（Verifiable Oblivious Pseudorandom Function）：発行者がトークンを生成する際、ユーザーの入力値を「見ずに」演算する。ユーザーは結果を受け取るが、発行者はユーザーが何を入力したか知らない。「盲目な計算」だが結果の正しさを検証できる。

BlindRSA署名：ユーザーが署名対象メッセージを「盲目化（blinding）」してから発行者に送り、署名を受け取ってから盲目化を解除する。発行者は何に署名したかを知らない。

Cloudflareはこのプロトコルをインフラ全体で1日数十億トークン規模で処理している。主にプライバシーリレーサービスで使われており、WAF（Webアプリケーションファイアウォール）とボット管理製品でも重要なシグナルとして活用されている。数百万のWebサイトがCloudflare経由でPrivacy Passをネイティブに利用できる状態にある。

Privacy Passの「安定識別子にならない」設計

Privacy Passの重要な特性は「証明にはなるが、安定した識別子にはならない」点だ。

• 「私はCAPTCHAを解いた」→ 証明できる
• 「私は昨日もこのサイトを訪問した同一人物だ」→ 証明できない

これにより、ユーザーが複数サイトをまたいで追跡されることを防ぐ。同じユーザーが10個のWebサイトにPrivacy Passトークンを提示しても、それらが同一人物のものだとは証明できない。

Privacy Passの限界と次のステップ

Privacy Passは「チャレンジ通過証明」という一種類の認証しか表現できない。しかし実際のWebでは「このAPIに1時間10回まで」「プレミアム会員の証明」など、より複雑な状態を表現したい場合がある。この限界を超えるために、CloudflareはARCとACTという新プリミティブを開発中だ（後述）。

Web Bot Auth：AIエージェントが暗号署名で自己証明する仕組み

Privacy Passが「匿名ユーザー向け」の技術だとすると、Web Bot Authは「自分を公開する意思のあるボット・エージェント向け」の技術だ。

HTTP Message Signaturesによる認証の仕組み

Web Bot AuthはRFC 9421（HTTP Message Signatures）を基盤とする。仕組みは次の3ステップだ：

Step 1：鍵ペアを生成・公開する エージェント運営者は鍵ペアを生成し、公開鍵を /.well-known/http-message-signatures-directory というエンドポイントにJWKS形式で公開する。

// /.well-known/http-message-signatures-directory で公開するJWKS例
{
  "keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
      "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
      "kid": "my-agent-key-2026",
      "use": "sig"
    }
  ]
}

Step 2：HTTPリクエストに署名を付与する エージェントはHTTPリクエストを送信する際に、秘密鍵でリクエストの主要フィールドに署名を付与する。署名対象にはターゲットオリジン（example.comなど）が含まれる。これにより中間者がリクエストを別のサーバーに転送することを防ぐ。

GET /api/data HTTP/2
Host: example.com
Signature-Input: sig1=("@method" "@authority" "@path");keyid="my-agent-key-2026";created=1745289600
Signature: sig1=:MEUCIBSs1J7bPXZKzfJ2j6Vd3b8jY4OGkj...:
User-Agent: MyAIAgent/1.0

Step 3：Webサーバーが署名を検証する サーバーはエージェントの公開鍵ディレクトリからJWKSを取得し、署名が有効かを検証する。有効であれば「このリクエストは確かにMyAIAgentから来た」と確認できる。

OpenAI・Google・Cloudflare・AWSがすでに実装

Web Bot Authの普及は2025〜2026年にかけて急速に進んだ。2026年4月時点で以下の主要プレイヤーがHTTPメッセージ署名を実装済みだ：

• OpenAI Operator：ChatGPTエージェントが代行するすべてのリクエストに署名を付与
• Google：各種クローラー・エージェントに段階的に実装
• Cloudflare：自社クローラーに実装済み、かつWorkers AI製品にも対応
• AWS：Amazon Bedrock AgentCoreに実装

暗号署名による認証はIPアドレスと比べて格段に偽造が困難だ。「自分がGoogleBot」と名乗るUser-Agentヘッダーは誰でも設定できるが、対応する秘密鍵なしに署名を偽造するのは現実的に不可能だ。

CloudflareのVerified Botsプログラムとの統合

CloudflareのVerified Botsプログラムは従来、IPアドレスとUser-Agentの組み合わせで正規のボットを認定していた。現在はHTTPメッセージ署名の提示がVerified Bots登録の新しい経路として統合されつつある。

署名付きリクエストは以下の恩恵を受けられる：

• Verified Botsとして認定され、WAFルールで一括制御できる
• Cloudflare Radarでのトラフィック可視化に対応
• ダッシュボードで「署名付きエージェントのトラフィック」を分析可能
• セキュリティルールによる細かいアクセス制御が可能になる

このアプローチは「信頼できるアクセスには属性可能性（attributability）のコストを払う」という合理的なトレードオフだ。自分が誰かを明かす意思のあるエージェントは、その代わりに円滑なアクセスを得られる。AIエージェントフレームワークを活用してWebスクレイピングやデータ取得を行うエージェント開発者にとって、Web Bot Authへの対応は今後の必須要件になっていくだろう。

Agent Registry：信頼できるAIエージェントの公開台帳

Web Bot Authは個別のエージェントが「私はXです」と証明する仕組みだが、Agent Registryはその証明の台帳を標準化する試みだ。

Signature Agent Cardの構造

Agent Registryの中核はSignature Agent CardというJSON形式のメタデータだ：

// Signature Agent Card の例
{
  "name": "MyAIAssistant",
  "operator": {
    "name": "Example Corp",
    "url": "https://example.com",
    "contact": "[email protected]"
  },
  "description": "ユーザーのリサーチを支援するAIアシスタント",
  "expectedRequestRate": "100/hour",
  "keys": [
    {
      "keyDirectory": "https://example.com/.well-known/http-message-signatures-directory"
    }
  ]
}

このカードには以下が含まれる：

• エージェント名と運営者情報（問題発生時の連絡先を含む）
• 期待リクエストレート（サーバーへの負荷を事前に把握可能）
• 公開鍵ディレクトリのURL（署名検証に必要な鍵の取得先）

レジストリの形式と相互運用性

Agent Registryはシンプルなテキストファイルで、各エージェントのSignature Agent CardへのURLを1行ずつ列挙する：

# trusted-agents.txt
https://openai.com/.well-known/agent-card.json
https://googlebot.google/.well-known/agent-card.json
https://mybusiness.com/.well-known/my-agent-card.json

このフォーマットはIPリストと同じ使い勝手で著作・インポートできる。CloudflareはRadar上でCloudflareが信頼するボット・エージェントのレジストリを公開しており、サイト運営者はこのリストをインポートしてセキュリティルールに即座に適用できる。

2026年2月、CloudflareとAmazon Bedrock AgentCoreは共同でオープンレジストリフォーマットの標準化を発表した。エージェントの公開鍵を発見するための統一規格により、異なるプラットフォーム間での相互運用性が確保される。

CloudflareのURLスキャナー・Radarとの統合

CloudflareはすでにRadar（radar.cloudflare.com/bots）でボットトラフィックの世界的な可視化を提供している。Agent Registryとの統合により、「どのAIエージェントが世界規模でどれだけWebにアクセスしているか」をリアルタイムで把握できるようになる。これはWebのエコシステム全体の健全性を監視するためのインフラとしても機能する。

また、Cloudflareは自社のURLスキャナー（Radar）でクローリング機能を公開しており（developers.cloudflare.com）、エージェント・ボット開発者は自社のクローラーをCloudflareインフラ側に登録する手順も明確になっている。

ARC・ACT：匿名のままレート制限できる次世代暗号技術

Privacy PassとWeb Bot Authの間には「ギャップ」がある。Privacy Passは完全匿名だが表現できる認証の種類が少ない。Web Bot Authは柔軟だが自己開示が必要だ。このギャップを埋めるのがARC（Anonymous Rate-Limit Credentials）とACT（Anonymous Credit Tokens）だ。現在IETFのPrivacy Passワーキンググループで仕様策定が進んでいる。

ARCの設計：並列提示と遅延オリジンバインディング

ARCは代数MAC（Message Authentication Code）と零知識証明（Zero-Knowledge Proof）を組み合わせた匿名認証スキームだ。

# ARC 発行・提示フロー（概念）

[発行フェーズ]
発行者: ユーザーに「N回分のアクセス権バッジ」を発行
  → ユーザーを特定せずにN回のトークンを一括発行
  → 1000回分で70倍の通信効率（従来VOPRFバッチ比）

[提示フェーズ]
ユーザー: 並列で最大N回、任意のオリジンにトークンを提示可能
  → 1バッチ取得で複数サイトに同時アクセス可能
  → late origin-binding: どのサイトに使うかは発行時に確定しない

[検証フェーズ]
検証者: 「N回の中の1回」を確認
  → ユーザーを追跡せずにレート制限を実施
  → メッセージサイズ: わずか288B/提示

ARCの重要な特性「遅延オリジンバインディング（Late Origin-Binding）」は、通常のトークンが「特定のサイト向け」に発行されるのとは異なり、ARCは「どのオリジンへも提示できる」汎用トークンを発行し、実際の使用時にオリジンを紐付ける。これにより発行者は「ユーザーがどのサイトにアクセスするか」を知らない状態が保たれる。

ACTの設計：動的状態更新と段階的レート制限

ACT（Anonymous Credit Tokens）はステートフルなアプローチを取る。各リクエスト後にサーバーが新しいトークンを再発行し、使用残高が動的に更新される仕組みだ。

# ACT の動的レート制限フロー（概念）

リクエスト1: token(balance=100) → サーバーが処理コストを評価
  → 重い処理（検索、大量取得）: balance -10 → new_token(balance=90)
リクエスト2: token(balance=90) → サーバーが評価
  → 軽い処理（ページビュー）: balance -1 → new_token(balance=89)
...
balance=0: リクエスト拒否（残高切れ）

# 不審なパターン検出時:
サーバー: 再発行を保留 → 実質的なアクセス停止（逐次的なため即時効果）

ACTにより「APIの処理コストに応じた動的な残高管理」を匿名のまま実現できる。

ARC vs ACT：性能・機能の比較

ARCは通信効率が高く（288B/提示）、1000回分バッチのVOPRFと比較して発行が約70倍高速だ。一方ACTは動的な状態管理が可能で、悪意あるパターンを検出した際にリアルタイムでレートを絞れる。

Cloudflareが提案するのはハイブリッドアプローチだ：最初のアクセスにはN=1のARCを使い、正当なアクセスが確認されたらACTにアップグレードして動的管理に移行する。これにより「限定的な取り消し能力」と「動的レート調整」を両立できる。

分散化・匿名性・説明責任のトリレンマ

Cloudflareのブログが提示した、インターネット管理の根本的な緊張関係が「三者択一（Trilemma）」だ。

分散化＋匿名性：Torネットワークのようなシステムは説明責任がなく、悪用が難しく防げない。

分散化＋説明責任：OAuth認証のような仕組みでは誰もが特定されてしまい、プライバシーが失われる。

匿名性＋説明責任：中央管理機構が必要だ。現状のインターネットで唯一の実例はWeb PKI（SSL証明書基盤）だ。CA（認証局）が証明書を発行し、ブラウザが信頼する仕組みがこれに当たる。

Cloudflareが目指すのは「匿名性＋説明責任」の領域を、中央管理なしに実現することだ。Privacy PassとARCはその試みだ——発行者が「チャレンジを解いた」という事実を証明できるが、「誰が解いたか」は管理しない。これは理想的なシステムへの一歩だが、まだ完全には実現できていない。

ボット認証手法の比較

何もしなかった場合のリスク：より閉じたインターネット

CloudflareがこのブログのもっとかA significant section to discuss is: 何もしなかった場合、何が起きるか。

Webサイト運営者がボット・AIエージェント問題に対処できなければ、自然な反応として次のような変化が起きる：

1. コンテンツへのアカウント必須化 ログインしないとコンテンツが読めなくなる。匿名での情報アクセスが失われ、安定した識別子（メールアドレス・SNSアカウント）への紐付けが強制される。

2. 広告支援モデルのフリーコンテンツの消滅 AIクローラーが広告を踏まずにコンテンツだけを取得するため、広告収益が機能しなくなる。「無料で読めるがログイン不要」というモデルが崩壊する。

3. コンテンツビジネスのWeb離れ メディア・出版社がWebを離れ、OpenAI・Google・Anthropicといった特定のAIベンダーと直接ライセンス契約を結ぶ方向へシフトする。Web上でコンテンツへアクセスするのではなく、AIシステム内で消費されるようになる。

4. 少数企業によるアクセス仲介 この結果、情報へのアクセスを少数の大企業が仲介する、より脆弱なインターネットが生まれる。現在のオープンWebという概念が崩れ、AIプラットフォームが情報の「ゲートキーパー」になる。

Cloudflareが示す基準は明確だ：「世界中のどこからでも、誰もが自分のデバイスとブラウザを構築でき、任意のOSを使ってWebにアクセスできるか」。この問いに”No”となる仕組みは、オープンWebの理念と相反する。

IETFとW3Cでのオープンスタンダード化

Cloudflareが強調するのは、これらの技術をプロプライエタリな製品ではなくオープンスタンダードとして育てることだ。IETFとW3Cで公開作業が進んでいる。

IETF側の標準化スケジュール

Web PKIがオープンな認証局エコシステムを実現したように、Cloudflareは「単一のゲートキーパーなしのオープン発行者エコシステム」を目指している。誰でも発行者になれる、誰でも検証者になれる——そのための仕様がIETFとW3Cで標準化されていく。

W3Cでのクライアント側API開発

IETFがプロトコル層を担うのに対し、W3Cではブラウザが直接Privacy PassトークンやARCトークンを取得・提示するためのクライアントAPIの開発が進んでいる。これが完成すると、ブラウザがCAPTCHAを解く代わりに自動的にPrivacy Passトークンを取得・提示するフローが標準化される。

Cloudflareのインフラが既に1日数十億トークンを処理していることは、このビジョンが単なる構想ではないことを示している。GitHubActionsのセキュリティ対策と同様、セキュリティのベストプラクティスがコンテキストに合わせて進化し続けている。

サイト運営者とエージェント開発者が今すぐできること

Webサイト・APIを運営している場合

すぐに始められる対応（今日）：

• Cloudflare WAFでVerified Botsの扱いを確認し、正規エージェントのトラフィックを誤ブロックしていないかチェックする
• Cloudflare Radarのボットトラフィックデータで自サイトへのエージェントアクセス量を把握する
• robots.txtを整備し、許可するクローラーと許可しないクローラーを明示する

中期的な対応（2〜3ヶ月）：

• Web Bot Authの検証実装を追加する（cloudflare/web-bot-authライブラリが利用可能）
• Agent Registryのテキストファイル形式を作成し、信頼するエージェントリストをインポートする
• HTTPメッセージ署名付きリクエストには通常アクセスを許可し、未署名リクエストにはより厳格なレート制限を適用する

長期的な対応（標準化後）：

• Privacy Passの発行者・検証者として参加することを検討する
• ARC・ACTのIETF仕様が確定次第、実装を計画に含める

AIエージェントを開発している場合

すぐに始められる対応（今日）：

• 鍵ペアを生成し、/.well-known/http-message-signatures-directoryにJWKSを公開する
• HTTPリクエストにHTTPメッセージ署名（RFC 9421）を付与する実装を追加する
• Cloudflare Agent Registryへの登録申請を行う（Signature Agent Cardを作成する）

署名実装の基本スクリプト：

# HTTPメッセージ署名の追加例（Python + requests）
import base64
import hashlib
import time
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes, serialization

def sign_request(method, host, path, private_key_pem):
    """RFC 9421準拠のHTTPメッセージ署名を生成"""
    private_key = serialization.load_pem_private_key(private_key_pem, password=None)
    created = int(time.time())
    sig_input = f'sig1=("@method" "@authority" "@path");keyid="my-agent-key";created={created}'
    sig_base = f'"@method": {method}\n"@authority": {host}\n"@path": {path}'
    
    signature = private_key.sign(sig_base.encode(), ec.ECDSA(hashes.SHA256()))
    sig_b64 = base64.b64encode(signature).decode()
    
    return {
        "Signature-Input": sig_input,
        "Signature": f"sig1=:{sig_b64}:"
    }

まとめ：「誰か」から「何ができるか」へのパラダイム転換

Cloudflareの「Moving past bots and humans」が示すのは、Webアクセス制御の根本的なパラダイム転換だ。

従来の問い：「あなたは人間ですか、ボットですか？」 新しい問い：「あなたは信頼できる行動を取りますか？何の権限を持っていますか？」

この転換は技術的な話だけではない。オープンなインターネットを維持するための哲学的な選択でもある。

Cloudflareが1日数十億トークンを処理しているという事実は、Privacy Passがすでに実戦投入されたインフラであることを示している。Web Bot AuthはOpenAI・Google・AWSの実装により急速に普及しており、Agent RegistryとARC/ACTはその次の波だ。

MCP（Model Context Protocol）のセキュリティ問題が示すように、AIエージェントが急増する時代には、アクセス制御の設計が後手に回ることのコストは高い。Web Bot AuthとAgent Registryへの対応は、セキュリティ投資として今から始める価値がある。

Webの設計者たちが議論を続けているIETFとW3Cの場で、次世代のアクセス制御標準が形作られている。エージェント時代のWebセキュリティに関心を持つエンジニアにとって、この動きは注目に値する。

参照ソース

• Moving past bots and humans - Cloudflare Blog
• Anonymous credentials: rate-limiting bots and agents without compromising privacy - Cloudflare Blog
• Forget IPs: using cryptography to verify bot and agent traffic - Cloudflare Blog
• Beyond IP lists: a registry format for bots and agents - Cloudflare Blog
• The age of agents: cryptographically recognizing agent traffic - Cloudflare Blog
• Privacy Pass - RFC 9576 / RFC 9578 (IETF)
• HTTP Message Signatures - RFC 9421 (IETF)
• cloudflare/web-bot-auth - GitHub
• Bot Traffic Worldwide - Cloudflare Radar
• Anonymous credentials: an illustrated primer (Part 2) - Matthew Green