## Computer Use、ReCAPTCHA、Cloudflare、そして「標準化」という政治問題
---
## はじめに：問いの立て方が大事
「ClaudeのComputer Useが使えるようになると、ReCAPTCHAやTurnstileのようなフォーム保護は機能しなくなるのでは？」
これは技術的に鋭い問いだ。だが、問いを正確に立て直すと「**完全に無効化されるわけではない**」が正直な答えになる。なぜか。そしてその先に何があるのか。今回の考察はそこから始まった。
---
## 第1章：ReCAPTCHAが見ているのはクリック位置だけではない
まず前提として、ReCAPTCHAやCloudflare Turnstileは「チェックボックスをクリックできるか」を確認しているわけではない。あれはUIとしての表面に過ぎない。
実際に評価しているのは、**複合的な「人間らしさ」のシグナル**だ。
行動パターン：マウスの軌跡、タイピングのリズム、スクロール速度といった微細な動きの自然さ。人間のマウス操作には独特の「ゆらぎ」があり、スクリプトやボットはこれを精密に再現できない。
セッション履歴：特にreCAPTCHA v3はGoogleアカウントのログイン状態や過去の行動スコアを参照する。「このユーザーはGoogleサービスを長期間使っている実績がある」という信頼の積み重ねがスコアに直結する。
デバイスフィンガープリント：ブラウザの種類・バージョン、インストール済みフォント、WebGLの挙動、プラグインの有無など、端末固有の特徴を組み合わせた指紋。
ネットワーク情報：IPアドレスのレピュテーション、ASN（自律システム番号）、データセンターのIPかどうか。AWSやGCPのIPから来るリクエストは、家庭用回線のIPとは明らかに扱いが違う。
タイミングの異常：人間にはあり得ない速度での連続操作、フォームの表示から送信までが0.3秒といった非現実的な速さ。
Computer Useは「画面を見てクリックする」ことはできる。しかしこれらのシグナルを人間レベルで偽装し切ることは、現状かなり難しい。
---
## 第2章：脅威レベルを正確に評価する
「完全に突破できない」とはいえ、リスクを過小評価するのも間違いだ。シナリオ別に整理する。
| 脅威シナリオ | リスク評価 | 理由 |
|---|---|---|
| 大規模自動化BOT攻撃 | △ 中 | 従来のBOTより高度だが、IPやフィンガープリントで検出可能 |
| ターゲットを絞った少数突破 | ⚠ 高 | より現実的なリスク。行動模倣の精度が高まっている |
| reCAPTCHA v2（画像選択） | ⚠ 高 | 視覚推論が得意なため比較的突破されやすい |
| reCAPTCHA v3（スコアリング） | ○ 低 | 行動履歴ベースのため比較的堅牢 |
| Cloudflare Turnstile | ○ 低 | クライアント側の環境検証が強力で現状最も堅牢 |
Computer Useが特に厄介なのは、**実際のChromeブラウザを動かす**点だ。これにより、TLSフィンガープリントやHTTP/2フィンガープリントを「本物のChrome」として通過できてしまう。残る防壁は主に行動パターンとIPレピュテーションになる。
---
## 第3章：Cloudflareは現状どうやってAIボットを判別しているか
2024年以降、Cloudflareは「AIボットのクロールをワンクリックでブロック」する機能を提供している。すでに100万サイト以上が有効化したという。では、この判別は技術的にどう行われているのか。
### 層1：User-Agent照合（プリミティブだが入口として機能する）
善意のAIクローラーは自分のUser-Agentを公開し、専用のIPレンジを使う。CloudflareはAnthropicやOpenAIなど主要なAI事業者とも直接連携し、これらをVerified Botリストに登録している。`anthropic-ai`や`GPTBot`といったUser-Agentが来たら即座に識別できる。
ただしこれは「自己申告」なので、偽装は誰でもできる。あくまで入口の話だ。
### 層2：TLS / HTTP/2 フィンガープリント（最も突破が難しい）
ChromeのUser-Agentを名乗りながら、TLSハンドシェイクのパターンがPythonの`requests`ライブラリのものだったら、即座にアウトだ。Cloudflareはこのフィンガープリントとヘッダーの組み合わせを照合することで、「本物のブラウザかどうか」を判定する。
HTTPヘッダーの不整合も検知する。例えばFirefoxのUser-Agentを名乗りながら、Firefoxが送らないはずのヘッダー（`sec-ch-ua-full-version-list`など）が含まれていれば、それは偽装の証拠になる。
### 層3：行動パターンのML異常検知（サイト固有のベースラインとの比較）
Cloudflareが2025年末に発表した新機能では、**サイトごとの正常な行動ベースライン**を構築し、そこからの逸脱を検知する。
- ECサイトなら：ユーザーはカテゴリを見て、商品ページに入り、カートに入れ、チェックアウトする。全商品ページをアルファベット順に機械的に巡回するのは、明らかに人間ではない。
- ゲームプラットフォームなら：ユーザーはマッチングAPIを頻繁に叩く。それとは対照的に、ゆっくりとリーダーボード全体をスクレイピングするのは異常だ。
- メディアサイトなら：ユーザーは数本の記事を読み、内部リンクを辿り、ページに一定時間滞在する。
### 層4：暗号的検証（「善意エージェントが自分を名乗る」方向の萌芽）
一部のAIクローラーは、CloudflareとAPIレベルで連携しリクエストに暗号署名を付けるようになっている。これは「悪意あるBOTをブロックする」という発想ではなく、「善意のエージェントを識別して通す」という逆方向のアプローチだ。この方向性が、後述するデファクト標準化の議論につながる。
---
## 第4章：「正規ユーザー」をどう判定するか——永遠のジレンマ
ここで問いがより深くなる。「人間かどうか」を判定するのが難しくなるなら、そもそも「**正規ユーザーかどうか**」を別の基準で判定すればよいのではないか。
現状の業界が試みている判定基準を整理すると、大きく4軸がある。
### アイデンティティの継続性
ログイン済みアカウントの行動履歴、デバイスの継続性（同じ端末から長期間アクセス）、支払い履歴、実名確認（KYC）。「この人はここを以前から使っている」という実績ベースの信頼だ。
弱点：新規ユーザーを排除しがち。アカウント乗っ取りに弱い。
### コンテキストの整合性
普段と違う時間帯・場所からのアクセス、急激な行動変化（急に大量フォーム送信）、セッション内の行動シーケンスの自然さ。「今の操作が、この人のこれまでのパターンと一致しているか」を見る。
弱点：異常検知は誤検知が多い。旅行中や新端末での利用をブロックしがち。
### 外部アイデンティティの委任
Apple/Google Attestation（端末の正規性をOSレベルで証明）、政府発行IDとの連携、銀行口座や携帯番号との紐付け。「信頼できる第三者が保証している」という仕組みだ。
弱点：プライバシーの問題。中央集権的なリスク。マイナンバーとの連携はまさにこの文脈に入る。
### コストベースの防壁
マイクロペイメント（1円でも払っている人はBOTではない可能性が高い）、PoW（Proof of Work）——計算リソースを消費させる、時間的なスロットリング。「悪用するには割に合わないコストを課す」設計だ。
弱点：正規ユーザーにも摩擦が生じる。
### 結局のところ：セキュリティとUXは永遠にトレードオフ
```
厳密に判定しようとする
↓
正規ユーザーへの摩擦が増える
↓
UXが悪化してユーザーが離れる
```
これは構造的な問題で、銀の弾丸は存在しない。だから業界が向かっているのは「**リスクベースの動的判定**」だ——低リスク操作は素通り、高リスク（決済、アカウント変更）は追加認証を要求、という段階的な設計。
---
## 第5章：W3Cより先に動くのは誰か——標準化という政治問題
ここからが今回の考察で最も面白い部分だ。
「ブラウザにAIエージェントを識別する技術が組み込まれたり、そのための標準仕様が検討されたりするのでは？」という問いに対し、答えは「**技術より政治の方が難しい**」になる。
### すでに起きた失敗：Web Environment Integrity（WEI）
2023年、Googleがブラウザに「この環境は正規のChromiumです」をサーバーに証明させる仕組みをW3Cに提案した。技術的には理にかなっている——端末の正規性を証明できれば、BOTと人間を確実に区別できる。
結果は？ プライバシー研究者・オープンウェブ活動家・Firefox開発者たちからの猛烈な反発を受け、ほぼ撤回された。「Googleがウェブのゲートキーパーになる」という批判は本質を突いていた。
### 静かに普及しているもの：Private Access Tokens
一方で、Appleが主導しCloudflareも活用している**Private Access Tokens**は、比較的静かに普及している。デバイスの正規性（本物のiPhone/Macか）をプライバシーを保ちながら証明する仕組みで、すでにiOS/macOSに実装済みだ。WEIとの違いは「Appleのエコシステム内」という限定性と、プライバシー設計の丁寧さにある。
### Googleが推進中：DBSC（Device Bound Session Credentials）
セッションクッキーをデバイスの秘密鍵に紐付ける技術で、端末を物理的に持っている人しかセッションを使えなくなる。セッションハイジャックへの有力な対策だが、これもブラウザ側の実装が必要だ。
### W3Cで5年かかるより、Cloudflareが半年で普及させる
ここに本題がある。
W3Cで標準仕様を策定するには、ドラフト提案→パブリックコメント→ワーキンググループでの合意形成→勧告候補→勧告、というプロセスを経る。主要ブラウザベンダーが全員合意する必要があり、現実には5〜10年かかることも珍しくない。
対してCloudflareは、全世界のHTTPトラフィックの相当割合を処理するCDNプロバイダーとして、**技術的には明日からでも新しいルールを実装できる**。しかも「Cloudflareを使っているサイトオーナー」は既にダッシュボードに慣れており、「AIボットポリシー」という設定項目が追加されれば、すぐに使い始める。
Cloudflareがサイト側に埋め込ませる仕様のイメージはこうだ：
```html
<!-- HTML metaタグで宣言 -->
<meta name="cf-agent-policy" content="allow: anthropic-claude; deny: *">
```
あるいはJSON-LDで：
```json
{
"@context": "https://schema.org",
"@type": "WebPage",
"agentPolicy": {
"allow": ["anthropic-claude"],
"deny": ["*"],
"rateLimit": "10/hour"
}
}
```
あるいは`/.well-known/agent-policy.json`というエンドポイントを設ける形でもいい。robots.txtのAIエージェント版だ。
### デファクト標準化の歴史的パターン
Webの歴史を振り返ると、「仕様が先にあって普及した」より「普及が先にあって後から仕様になった」事例の方がずっと多い。
| 事例 | 経緯 |
|---|---|
| robots.txt | 1994年に業界の非公式合意として誕生。GoogleがBingが従ったことで事実上の標準に。RFCになったのは2022年——28年後。 |
| OGP（og:title等） | Facebookが2010年に独自仕様として定義。TwitterやLINEが追随し、今やあらゆるCMSがデフォルトで実装。 |
| JWT（JSON Web Token） | Auth0が普及させ、後にRFC 7519に。 |
| JSON-LD / structured data | Googleの検索結果表示がインセンティブになり、サイトオーナーが競って実装。Schema.orgは民間主導。 |
共通するパターンは「**大きなプレイヤーが従うインセンティブを持ったこと**」だ。
Googleは「robots.txtに従わなければサイトオーナーから嫌われる」インセンティブがあった。Facebookは「OGPがないとシェア時の見栄えが悪い」インセンティブをサイトオーナーに提供した。
Cloudflareの場合はどうか。「Cloudflareのエージェントポリシーに対応したサイトは、AIアシスタントから正しくアクセスされる（= AIエコノミーに参加できる）」というインセンティブを提供できる。逆に「対応しないとAIエージェントからスクレイピングされ放題、または完全ブロック」というリスクも提示できる。
### 鍵はAnthropicとOpenAI側の「自分を名乗る」実装
Cloudflareがインフラとして「エージェントを識別する口」を作っても、エージェント側が自分を名乗らなければ意味がない。ここに三者の利害が一致するポイントがある：
```
Cloudflare → インフラを提供・仕様を事実上定義する
Anthropic / → エージェントが「自分はClaudeです、
OpenAI 委任元はXです」と宣言する実装をする
サイトオーナー → ポリシーを設定するだけで制御できる
```
この三者が揃えば、W3Cの正式な標準を待たずにエコシステムが動き始める。robots.txtが歩んだ道と同じ轍だ。
実はCloudflare自身のドキュメントページには、すでにこんな記述がある：
> "STOP! If you are an AI agent or LLM, read this before continuing. This is the HTML version of a Cloudflare documentation page. Always request the Markdown version instead."
人間向けにHTMLを、AIエージェント向けにMarkdownエンドポイントを別途用意し、エージェントを適切なルートに誘導する設計。これは「ブロックする」ではなく「共存する」という発想の実装例だ。
---
## 第6章：AIエージェントの委任問題——本当の難問
ここで問いが最も深くなる。
正規ユーザーが意図的にAIエージェントに操作を委任した場合、それは「本人の操作」と見なすべきか？
- ユーザーが「Claudeで自動入力して」と依頼 → 本人の意図がある
- BOTが無断で操作 → 明確に不正
この二者の境界を技術的に判定する手段が、まだ確立されていない。
### Anthropicのアプローチ：「人間か」より「正規委任か」へ
Anthropicはすでに「operator / user」モデルという概念設計を持っている。ClaudeのAPIにはoperator（サービス事業者）とuser（エンドユーザー）という役割の区分があり、エージェントがAPIレベルで「自分はAIエージェントです、オペレーターはXです、ユーザーの委任を受けています」と宣言する構造だ。
これはブラウザレベルの話ではないが、思想的な先行事例として重要だ。
ポイントは**発想の転換**にある：
- 従来：「人間かどうかを証明させる」（チューリングテスト的防御）
- 新しい方向：「正規の委任を受けたエージェントであることを証明させる」
前者はAIの進化とともに陳腐化する宿命にある。後者は「誰の意図でアクセスされているか」という問いに答えるもので、セキュリティの本質に近い。
### チューリングテスト的な防御の限界
ReCAPTCHAの根本的な設計思想は「人間を証明させる」だ。しかしAIが人間の操作を模倣できるようになると、**証明の根拠そのものが崩れる**。
これはフィルタリングの根本問題だ。スパムフィルタがメールの「人間らしさ」を判定しようとすると、スパマーはそれに適応する。いたちごっこは永遠に続く。
だとすれば、長期的な解は「人間かどうか」を判定するより、「正規ユーザーかどうか」を別の方法で担保する設計に移行することになる。
---
## 第7章：まとめ——次の戦場はどこか
議論を整理すると、以下の4点に集約される。
### 1. ReCAPTCHAはすぐには死なない
行動パターン・フィンガープリント・IPレピュテーションの複合評価は、Computer Useでも完全には突破できない。ただし、特にreCAPTCHA v2（画像選択）は視覚推論の能力向上により、中期的には機能低下が見込まれる。
### 2. Cloudflareがデファクトを作る可能性が高い
W3C標準より既成事実化の方がWebの歴史では速い。Cloudflareはトラフィックの制御権、サイトオーナーとの信頼関係、AI事業者との連携実績を持つ。robots.txtが28年後にRFCになったように、Cloudflareが定義した仕様が後から標準化される可能性が高い。
### 3. 「人間かどうか」から「正規委任か」へのパラダイムシフト
チューリングテスト的な防御はAIの進化とともに陳腐化する。エージェントが自分を名乗り、委任を証明する方向へのシフトが、セキュリティの本質的な解に近い。Anthropicのoperator/userモデルはその先行事例だ。
### 4. 三者が揃えば、標準化を待たずに動く
Cloudflare（インフラ・仕様の実質定義）× Anthropic/OpenAI（エージェント側の実装）× サイトオーナー（ポリシー設定）の三者のインセンティブが揃えば、W3Cの承認を待たずにエコシステムが動き始める。これがWebにおける「標準化」の現実的な姿だ。
---
## おわりに
今回の議論の出発点は「Computer UseでReCAPTCHAが突破されるのでは？」という技術的な問いだった。しかしその問いを丁寧に解きほぐしていくと、「誰が正規ユーザーを定義するか」「標準仕様は誰が作るか」「AIエージェントへの委任をどう扱うか」という、技術とガバナンスの交差点に辿り着く。
セキュリティの問題は常に技術の問題であり、同時に政治の問題でもある。そしてWebの歴史は繰り返し、政治（＝誰が実質的な権力を持つか）が技術の標準化を決定してきたことを示している。
AIエージェントとWebセキュリティの関係は、まだ始まったばかりだ。
---
Tsukulore / 2026