火消し栓の画像を何度も選ばされる日々に、終わりが見えそうです。
2026年6月22日、CloudflareはGoogle Chrome、Microsoft Edge、Mozilla Firefox、Shopifyと共同で、CAPTCHAやログイン強制に代わる新しいウェブ標準「PACT（Private Access Control Tokens）」の開発を発表しました。この記事では、PACTが何を解決しようとしているのか、仕組み、現状の限界までを整理します。
この記事でわかること
- ボット過半数時代にCAPTCHAが破綻している背景
- PACTが匿名トークンで「人間かどうか」ではなく「歓迎すべきトラフィックか」を判定する考え方
- Privacy PassやAppleのPrivate Access Tokensとの違い
- 提案段階であり、実装スケジュールは未発表である点
ボットが人間を上回った、という前提
PACTが提案された背景には、ウェブのトラフィック構成の変化があります。CloudflareのCEO Matthew Prince氏は、HTTPリクエストのうちボット由来の割合が約57%に達し、人間を上回ったと報告しています。1日の中でも52%から62%の間で変動するという。Prince氏はもともと2027年頃にこの転換点が来ると予測していましたが、エージェント型AIの普及で想定より早く到来しました。
サイト運営者は長年、CAPTCHA、行動フィンガープリント、IPブロックでボットを防いできました。しかし生成AIの進化でCAPTCHAはボットの方が速く解ける場面が増え、プライバシー保護を強化したブラウザでは従来の検知シグナルが使えなくなっています。結果として、ログイン強制やVPNブロックといった侵入的な対策が広がり、正当な訪問者にも負担がかかっています。
PACTとは何か
PACTは、プライバシーを保ちながら「悪意のないトラフィックであること」を証明するためのオープンなプロトコルです。Cloudflareのプレスリリースによれば、すでに「personhood（人としての正当性）」を把握しているサイトが匿名トークンを発行し、ブラウザがそれを他のサイトに提示する仕組みです。受け取ったサイトはトークンの正当性を確認できますが、ユーザーの身元や閲覧履歴にはたどり着けない設計です。
Cloudflare CTOのDane Knecht氏は、「AIを動かすトラフィックが広がる中、既存のセキュリティ手段は粗すぎる」と述べ、人間にもエージェントにもかかる摩擦を減らしつつプライバシーを守れると説明しています。Mozilla Firefox CTOのBobby Holley氏も、自動トラフィックの急増がCAPTCHAや侵入的トラッキングを招いている現状を指摘し、より良い代替策が必要だとしています。
匿名トークンが仕組みの核
PACTの技術的基盤は、IETFで標準化されたPrivacy Passプロトコル（RFC 9576、RFC 9577）です。Privacy Passは2018年頃から開発され、CloudflareのCAPTCHA負担を減らす目的で生まれました。トークンの発行と利用は暗号学的に切り離され、発行元はトークンがどこで使われたかを知れず、利用先は誰に発行されたかを知れません。
Mozilla Hacksの技術解説では、PACTをさらに発展させた設計が示されています。ユーザーとの関係を持つサイトが「Anchor（アンカー）」となり、サブスクリプションやアカウントなど希少なリソースに基づく「Endorsement（推薦）」トークンを発行します。訪問先のサイトが「Moderator（モデレーター）」としてレート制限を管理し、状態を持つ「Credential（クレデンシャル）」を返します。Credentialの内部カウンターはAnonymous Credit Tokens（ACT）で管理され、サイトは残高の具体的な値を知らずにアクセス可否を判断できます。
重要なのは、PACTが「人間かボットか」という二択ではなく「このトラフィックは歓迎すべきか」という問いに切り替える点です。The Registerの報道では、再利用可能なプライバシー保護型CAPTCHA結果に近いが、対象は人間性そのものではなくトラフィックの望ましさだと整理されています。ユーザーが許可したAIエージェントがフライト予約を代行するケースも、正当なトラフィックとして扱える設計です。
AppleのPrivate Access Tokensとの違い
PACTを理解するうえで、Appleが2022年から展開するPrivate Access Tokens（PAT）との対比が有効です。PATもPrivacy Passを基盤にしており、iOSやmacOSのデバイスアテステーションでCAPTCHAを省略する仕組みとして実装されています。
Mozillaの解説は、PATがデバイスメーカーのハードウェア制御に依存する点を問題視しています。デバイスアテステーションは特定ベンダーのハードウェアとソフトウェアに縛られるため、オープンなウェブには不向きだという指摘です。PACTはメールアドレス、電話番号、有料サブスクリプション、アカウント維持など、ハードウェア以外の「希少性」にもアンカーを置ける設計を目指しています。VPNプロバイダーがサブスクリプションを根拠にユーザーを保証する例も挙げられています。
参加企業とそれぞれの動機
共同開発の参加者は、ブラウザベンダー3社に加え、ECプラットフォームのShopifyです。Microsoft EdgeのErik Anderson氏は、乱用対策とユーザー体験の両立に有効な標準を歓迎するとコメントしています。ShopifyのIlya Grigorik氏は、チェックアウト時の余計なチャレンジがカゴ放棄につながることを懸念し、正規の買い物客と許可されたエージェントを悪意あるトラフィックと区別できる標準としてPACT開発に関わると述べています。
技術的な議論はGitHubのantifraudcg/pactリポジトリで進められています。ACTと集約Issuer（発行者）を組み合わせた設計案など、具体的なアーキテクチャのスケッチがIssueとして公開されています。ただしリポジトリ自体はまだ初期段階で、IETFへのドラフト提出やW3CでのWebAPI標準化はこれからです。
解決しない問題と残る論点
PACTのプライバシー主張には、冷静な視点も必要です。The Registerは、トークン自体に個人情報が含まれない一方で、ブラウザフィンガープリントなど他の追跡手段には手を触れないと指摘しています。本質的には不正防止のための仕組みであり、ウェブトラフィックを「歓迎」と「非歓迎」に分ける枠組みだという分析もあります。
Mozillaの設計でも、どのAnchorを信頼するかのガバナンス、複数サイトをカバーするModeratorの集中化リスク、完全自律型エージェントへの対応は未解決の課題として挙げられています。Issuer blinding（発行者秘匿）を導入すると、強いAnchorと弱いAnchorで初期アクセスを差別化できず、最も弱いAnchorの水準に合わせる必要があるというトレードオフも説明されています。
いつ使えるのか
現時点でPACTは提案段階にとどまり、ブラウザへの実装や本番展開のスケジュールは発表されていません。Cloudflareは標準化団体への提出を約束していますが、仕様が数十億規模のブラウザセッションで動くようになるまでには時間がかかる見込みです。Endorsementがない場合はCAPTCHAやアカウント作成など既存の手段にフォールバックする設計のため、導入が進んでも突然アクセスできなくなるわけではありません。
ボット過半数のウェブで、プライバシーと利便性の両立を目指すPACT。CAPTCHAの終焉を告げるにはまだ道のりがありますが、主要ブラウザが同じ方向を向いたこと自体が、次のウェブ認証の議論の出発点になります。