一方がボットをブロックしている間、他方は彼らにパスポートを提示するよう教えています。 2026年、Cloudflare、Google、Amazon、Akamai、OpenAIは一つの標準、すなわちWeb Bot Authの周りに集まりました。アイデアはシンプルで根本的です：自動トラフィックはもはやIPアドレスや簡単に偽造できるUser-Agent文字列で確認されません。その代わりに、エージェントは各リクエストに暗号的に署名し、サイトは瞬時に署名を確認します。2026年3月2日、アーキテクチャのドラフトの第5版（draft-meunier-web-bot-auth-architecture-05）が発表され、5月にはGoogleが実戦テストを開始し、IETFの作業部会は2026年8月までに標準を発表することを目指しています。このメカニズムが何であるか、誰がそれを支えているのか、そしてスクレイピングやマルチアカウントを行うすべての人にとって、なぜ180度の転換であるのかを見ていきましょう。
何が起こったのか：ボットに暗号的なアイデンティティが生まれる
ウェブにおけるクラシックな「自分–他人」の確認は二つの足場に依存していました。第一はUser-Agent：クライアントが自分自身について報告する文字列であり、どのスクリプトでも一行のコードに書き換えられます。第二はIPアドレスリスト：サイトはGooglebot、Bingbotなどの「公式」範囲のリストを保持し、逆DNSを確認します。2026年には、これらの両方のアプローチが完全に崩れました。
Cloudflareはその技術文書で問題を明確に定義しています：同じIPが多くのユーザーやサービスによって同時に使用される可能性があり、範囲自体はインフラに従って常に変化しています。User-Agentは実際には証明ではなく、単なる自己表現です。著者たちの意図によれば、暗号的な署名は「常に変わるIP範囲」や「偽造可能なUser-Agentのようなヘッダー」に依存せずに認証を提供します。
技術的には、Web Bot Authはすでに受け入れられている標準HTTP Message Signatures (RFC 9421)に基づいています。各エージェントにはEd25519のキーのペアが与えられます。リクエストを送信する前に、エージェントはすべてを署名するのではなく、対象URIのauthority、つまりアクセスするドメイン（example.comにアクセスする際にはexample.comを署名します）を署名します。リクエストにはSignature-Input（作成された日付と有効期限のラベルを持つ有効性ウィンドウ、JWKサムプリント形式のキーID、web-bot-authタグ）とSignature-Agentが追加され、公開鍵のディレクトリ（JWKS）を指します。サイトはこのディレクトリから公開鍵をダウンロードし、署名を確認します。プライベートキーなしでそれを偽造することは不可能であり、有効性ウィンドウはキャプチャされたリクエストの再再生から保護します。
誰が標準を支えているのか
これは一社の実験ではありません。Web Bot AuthはCloudflare、Amazon、Akamai、OpenAIによって支持されています。アーキテクチャのドラフトは、ティボー・ミュニエ（Cloudflare）とシャンドル・マイアー（Google）の共同執筆です。AWS WAFはすでに署名確認のサポートを追加しており、Cloudflareはそれを自社のVerified Botsプログラムに組み込み、プロダクションでエッジにアクティブ化しました。2026年にWeb Bot Authに関する特別なIETF作業部会が設立され、2026年8月までに仕様を標準化することを目指しています。
Googleが参加 — これは転換点です
2026年5月6日、Googleが自社のボットトラフィックを確認するためにWeb Bot Authをテストしていることが知られました。これは、サイトがGoogleのリクエストであることを確認できるようにするためです。つまり、GooglebotをUser-Agentに単に入力した誰かからのものでないことを確認します。署名されたGoogleのAIトラフィックはagent.bot.googというアイデンティティの下で行われ、サイトの所有者はこのエンドポイントからGoogleの公開鍵を取得し、SignatureおよびSignature-Inputヘッダーを検証します。
なぜ今これが重要なのか。それは、私たちがエージェントブラウザのブロックについて書いたこととまったく同じ理由です：2026年9月15日から、Cloudflareはデフォルトで新しいドメインの広告ページで「混合」AIクローラーをブロックします。そして、Cloudflareを介して流れるトラフィックは全ウェブの約5分の1です。ウェブは閉じつつあります。そして、Web Bot Authは「どうやってブロックするか」ではなく、「誰を受け入れるか」に関するものです。新しいタイプのホワイトリストが登場します：IPではなく、暗号的なアイデンティティによって。サイトは「確認された署名されたエージェントにのみ価格と商品詳細を表示する」というポリシーを実装でき、その他は自動的に外に残ります。
署名されたエージェント：最初のコホート
特定のカテゴリーはsigned agents（署名されたエージェント）です。これは、エンドユーザーによって管理されるボットであり、一つの企業によってではありません：プラットフォームまたはエージェントが動作するリモートブラウザがそのHTTPリクエストを署名し、Cloudflareが署名を検証します。最初のコホートにはChatGPT agent (OpenAI)、Goose (Block)、Browserbase、Anchor Browser、Cloudflare Browser Renderingが含まれています。Blockのダウヴェ・オシンガはその利点を直接述べました：「Web Bot Authは、サイトがGooseを信頼できるようにし、それをユニークに保つことを可能にします。」
重要な違いは、signed agentは人の代理として行動することです（条件付きアシスタントがあなたの依頼でサイトにアクセスする）、一方で「検索」または「トレーニング」クローラーは企業のために働きます。Cloudflareはすでにこれらのエンティティをセキュリティルールで区別しており、この分岐が2026–2027年のウェブで誰に扉が開かれるか、誰に開かれないかを決定します。
スクレイピングとプロキシにとっての意味
一見すると、暗号署名は匿名のスクレイピングを葬るように思えます。しかし、実際には状況はより微妙です — ウェブは二つの車線に分かれ、私たちのオーディエンスにとっては戦術が変わるだけで、廃止されるわけではありません。
- 署名されたエージェントの車線。 大規模なプラットフォームやホワイトリストの「ユーザー」アシスタントのための狭い特権通行です。そこに入るには、プライベートキー、公開JWKSディレクトリ、CDNへの登録、ポリシーへの適合が必要です。典型的なパーシングプロジェクト、アンチデテクトファーム、またはSMM自動化にとって、この道は閉ざされています：あなたはGoogleでもOpenAIでもないので、署名は発行されません。
- その他のすべての車線。 ここには依然として独立したスクレイパー、価格監視、データ収集、マルチアカウントが存在します。そして、ここでプロキシの質とフィンガープリンティングの信頼性が高まります。「合法的な」ものが署名で通過するので、署名されていないトラフィックに対する扱いはデフォルトで厳しくなります。
言い換えれば、Web Bot Authはプロキシの必要性を排除するのではなく、ホワイトリストに載っていない人々にとってのハードルを引き上げます。以前はグレーなUser-Agentで通過できる可能性がありましたが、今では署名されていないリクエストはすぐに「あなたが生きている人間であることを証明せよ」というカテゴリーに入ります。そして、それはクリーンなIPと信頼できる行動の組み合わせによって証明されます。
なぜレジデンシャルIPとモバイルIPがさらに価値を持つのか
署名が利用できない場合、合法的に見える唯一の方法は、通常のユーザーと区別できないことです。データセンターのアドレスではこの課題を解決できません：Cloudflareの保護測定によると、データセンターIPは40〜60％の確率で通過しますが、レジデンシャルプロキシは85〜99％の通過率を提供します。その理由は、レジデンシャルアドレスが実際のインターネットサービスプロバイダーと生きた加入者に属しているためであり、そのIPの評判からは同じルーターの背後にいる人間と区別できません。
最も保護されたプラットフォームやモバイルアプリケーションでは、携帯ネットワークが重要な役割を果たします。ここでは、モバイルプロキシが助けになります：一つのキャリアのIPの背後には何千もの生きた加入者がいるため、そのアドレスを大量にブロックすることは実際の顧客を切り離すことになります。この「共通の鍋」の効果が、モバイルIPを他のすべてが透過する世界で最も安定した通貨にしています。
しかし、クリーンなIPだけでは不十分です。アイデンティティの確認がネットワークから暗号に移行するため、すべての署名されていないボットの軍団は行動的およびブラウザーフィンガープリンティングを通過します：TLS/JA4、キャンバス、WebGL、フォント、タイミング。プロキシは一つの警告信号（アドレスの評判）を取り除きますが、他の信号は無くなりません。2026年の作業の組み合わせは、レジデンシャルまたはモバイルIPプラス整合されたフィンガープリンティングを持つアンチデテクト環境です。一方のコンポーネントが他方なしで存在すると、最初の防御レベルでボットが露見します。
今すぐ行動する方法
- プロジェクトを車線ごとに分ける。 公式な統合を大規模な製品の名義で行う場合、signed agentの道を学び、CDNへの登録とキーの取得を行います。それ以外のすべてについては、「その他のすべての車線」での作業を計画し、そのルールを考慮に入れます。
- IPの質に投資し、量ではなく質を重視する。 2026年には安価なデータセンタープールがますますストップファクターになります。タスクに応じてレジデンシャルおよびモバイルアドレスに賭けてください。
- フィンガープリンティングをネットワークと同期させる。 一つの国のIPで、ブラウザの言語、タイムゾーン、ロケールが別の国のものであるのは典型的な失敗です。フィンガープリンティングはプロキシの地理的位置と矛盾せずに一致する必要があります。
- 標準を監視する。 2026年8月までにIETFは仕様を最終化する予定です。Web Bot Authが特定のプラットフォームへのアクセスの必須条件となった場合、そのための戦術を事前に見直す必要があります。
結論
Web Bot Authは単なるアンチボットではなく、ウェブにおける信頼の論理そのものの変化です。「IPで誰かを確認する」から「暗号で誰かを証明する」へ。GoogleやOpenAIのような巨人にとっては、閉じつつあるインターネットへのパスです。独立したスクレイパーやマルチアカウントプロジェクトにとっては、グレーな手法が完全に機能しなくなるという信号です。「人間のように見えること」と「ボットのように見えること」の間のギャップが決定的になります。新しい現実で勝つのは、より多くのIPを持つ者ではなく、クリーンなレジデンシャルまたはモバイルアドレスと完璧に整合されたフィンガープリンティングを持つ者です。暗号パスポートはすべての人に発行されたわけではありません — したがって、他のすべての人はより説得力を持つ必要があります。
```