BLOG
AIが全CAPTCHAを突破：「人間である証明」はどう変わるか
冒頭：あるAIが、ウェブページ上で「自分はロボットではない」と証明したばかり
9月7日、OpenAI LabsのメンバーSharif Shameemが公開デモを行った。GPT-6 Astraが『I’m Not a Robot』の人間・機械判別テストを全48問連続で突破したのである。
最初の数問は、私たちにもおなじみの画像認識や文字判別だった。しかし先へ進むにつれ難易度は急上昇——ドラッグ＆ドロップ、駐車、視覚探索、リズム操作、論理系ミニゲーム。Astraは終始画面を見つめ、マウスとキーボードを操作し、ページの変化に応じて動作を調整しながら進み、最後にはゲームから発行される「人間認証」を手にした。
この話の滑稽さと恐ろしさは、同じ一点にある。キャプチャの設計意図とは、もともと機械を「人間のようにインターフェースを操作する」という扉の外に締め出すことにあった。それが今、扉の中にいた機械が外に出て、その扉を解体してしまったのだ。
面白いのは、この一件を報じたAI科技评论の見出しに、別れの言葉が添えられていたことだ——「さようなら、reCAPTCHA」。だが、防線は本当に失われたのだろうか？ 私はこの48問の背後にある技術的事実と、現代のウェブサイトが実際に備えているアンチボット体制を一通り整理したうえで、その問題を17年間ソフトウェア業界に身を置き、現在はAI技術ディレクターを務める永亮に投げかけた——彼が手がける企業システムは、日々「人間か機械か」という問題と向き合っているのだから。
拾闻：AIがキャプチャを全部クリアしてしまった。あなたの第一反応は「終わった」だったのか、それとも「やっぱりな」だったのか。 永亮：どちらでもない。「来るべきものが、ついに来た」ということだ。キャプチャが防いできたのは「賢さ」ではなく「手の不器用さ」だった——今やAIの手は不器用ではなくなったのだから、この問いは当然無効になる。だが、無効になったのは「問い」であって「試験」ではない。 拾闻：では、徹底的に掘り下げよう。AIは一体何を乗り越えたのか。現代のウェブサイトは今も何で防ぎ続けているのか。そして「あなたは人間だと証明する」ことを、これからどうすればいいのか。
Q1：48問完全クリアは、技術的に一体何を意味するのか？
永亮：AIが初めて「画面の理解」と「連続操作」を一本の安定したワークフローへと溶接した、ということです。
多くの人はCAPTCHAのクリアを「画像認識が強くなったから」と考えていますが、これが最大の誤解です。認識はあくまで入場券であり、本当の難所はその先にあります。
制御システムの視点で見てみましょう。Webページには内部状態があり、AIが見ているスクリーンショットは、その状態が表に露出した一角にすぎません。Astraはクリックするたび、ドラッグするたびにページが変化していきます——1フレームの画面、過去の画面、そして自分が実行した操作から「自分はいまタスクのどの段階にいるのか」を推論し続けなければならないのです。駐車ステージがこの問題を最もよく物語っています：画面には車が写っているのに、「なぜその車がここに停まっているのか」は画面のどこにもありません。リズム系のステージはさらに過酷で、AIが考えている間も環境が変わり続けます。
このワークフローを支えているのは、検証済みの3層の能力です。公開データでは、AstraはScreenSpot-Pro（「セマンティクスから座標へ」というUI要素の定位能力を測定）で92.7%を達成。OSWorld 2.0（長時間にわたる実PC操作を測定）では72.6%を達成し、模擬タスクの所要時間を約75分から約40分へと圧縮しました。
ここには重要な認識があります：**単発の正確さ ≠ 連続の安定性。**ボタンを1つ押し間違えれば、次のフレームでページは別の分岐に入り、以降のすべての推論が誤った前提の上に築かれてしまいます。だからこそ、長時間にわたる操作には見えないところで働くモジュール——「操作後の状態検証」——が必要になります：ポップアップを閉じるボタンを押したのに、新しいスクリーンショットにポップアップがまだ残っている？ならばこの一手は失敗。リトライするか、別のルートに切り替えます。48問すべてをクリアできたということは、この検証メカニズムが本当に回っていることの証です。
最後に一つ、正直な注釈を：デモを実演した本人が完全な実行環境の詳細を公開していないため、48/48を厳密な純視覚ベンチマークの成績として扱うことはできません。それでも、そこが示す方向性は本物です——CAPTCHAの存在を支えてきた「機械には連続的なGUI操作ができない」という前提は、すでに崩れ落ちたのです。
Q2：では、いまのウェブサイトはまだ丸腰なのか？ 現代のアンチボット体制とはいったい何なのか？
永亮：丸腰ではない。本当の防衛線は10年前から引っ越しを始めていた――「試験問題」からブラウザとサーバー側へと。
あなたは九宮格（3×3マス）の画像認証を解いているつもりでも、実のところ画像認証はとっくに、最後まで残された見せかけの関門に過ぎない。本当の判定は、あなたの見えない2つのレイヤーで行われている。
第1層は、ブラウザ環境のシグナル。 reCAPTCHA v3の仕組みでは、あなたがまだ何もクリックしていないのに、ブラウザはすでにバックグラウンドであなたの行動にリスクスコアを付けている――マウスの軌跡、ページの滞在、インタラクションのコンテキストがすべて計算の対象となり、最終的にサーバーへ1つのスコアが渡され、通すかどうかはサーバーが決める。CloudflareのTurnstileはさらに徹底している。一連の軽量チャレンジがブラウザ内で動作し（計算チャレンジ、Web APIの探査、環境の特徴）、通過すると使い切りのtokenが1つ発行される。有効期間は300秒で、引き換えは1回限りだ。
第2層は、ネットワークとリクエストの特徴。 TLSハンドシェイクのフィンガープリント（JA3/JA4）を見れば、本物のブラウザかどうかが分かる。リクエストの時系列、頻度、コンテキストの異常も、サーバー側ですべてお見通しだ。
この2つのレイヤーを合わせると、ある一つのことが説明できる：Astraがクリアできているのは「認知試験問題」までで、サーバーにはAstraに見えないものがまだ見えている――どのクライアント上で動いているのか、リクエストの順序は正常か、tokenは有効かどうか。まるで試験問題をすべて正解した受験生が、監督の先生に「そのペンは自分のものではない」と見抜かれたようなものだ。
ただし、この防衛線にも賞味期限がある。AIはいまやしばしば本物のChromeブラウザ内で直接動作し、本物のブラウザのプロトコル特性をすべて自然に引き継ぐ――かつての一目で偽と分かるSeleniumスクリプトとは、まったくの別物だ。Cloudflareのドキュメントは現時点でも自動化フレームワークを明確にサポートしていないが、「ブラウザのフィンガープリントで人間と機械を区別する」という余地は、確実に狭まりつつある。
Q3：「自分は人間だと証明する」ことは、今後も成り立つのか？
永亮：この問い自体が書き換えられることになります――今後は「機械アクセス」の半分が合法になるのですから。
今すぐにでも当たり前になりそうな場面を想像してみてください。AIアシスタントにフライトを調べさせ、注文を変更させ、経費申請を入力させる。サーバーが相手にするのは確かに機械ですが、それを遮断すれば、遮断されるのはあなた自身の正当なニーズです。従来のCAPTCHAにおける「人間/機械」という二値分類は、情報量としてすでに不十分なのです。
業界の答えは、問いを変えることでした。「あなたは機械か」と問う代わりに、「あなたはどの機械か、誰があなたを遣わしたのか、何をすることが許されているのか」と問うようになったのです。
Cloudflareが今年ローンチしたWeb Bot Authは、まさにこの考え方を具現化したものです。AIアシスタントは自身のEd25519鍵ペアを生成し、秘密鍵ですべてのHTTPリクエストに署名し、公開鍵を公開ディレクトリに登録します。サーバーは署名を検証します――これはCAPTCHAのロジックとはまったく異なるものです。**CAPTCHAは行動の特徴からあなたが誰かを推測し、署名は暗号学によってあなたが誰かを証明するのです。**AIの視覚能力が10倍になったところで、他人の秘密鍵による有効な署名を算出することはできません。
しかし認証は前半にすぎず、後半は認可です。このAIの身元を確認したうえで、何ができるのかを限定する必要があります――注文の照会は許可するが、注文のキャンセルは許可しない。メインアシスタントがサブアシスタントを呼び出すときには、権限を段階的に絞り込まなければなりません。未来のWebセキュリティモデルは、検証可能な委任チェーンです：AIの身元が有効 → ユーザーの認可が有効 → tokenが期限切れでない → 操作が認可の範囲内。
**平たく言い換えれば、CAPTCHAの時代は「あなたは人間ですか」と問い、AIの時代は「あなたは誰か、誰があなたを遣わしたのか、何ができるのか」と問うのです。**機械を排斥する時代から、機械を管理する時代へ。
Q4：一般の開発者や小規模企業は、いま何をすべきか？
永亮：優先順位に沿って、3つのこと。
**第一に、サイトがまだ画像CAPTCHAを主な防御線として使っているなら、今日すぐアップグレードすべきです。**reCAPTCHA v3 か Cloudflare Turnstile（無料）を導入し、判定をサーバーサイドに移しましょう。画像クイズを残しておくのは構いませんが、あくまで飾りとして使うものであって、鍵として使ってはいけません。
**第二に、AI トラフィックを十把一絡げに敵と見なさないこと。**あなたのユーザーは間もなく AI アシスタントを連れてやってきます。どの操作を認可済みの AI に開放し、どれを開放しないかを前もってはっきり決めておくほうが、いざというときに慌てて全面的に締め出すよりずっといいでしょう。
**第三に、AI アプリケーションを開発しているなら、クライアントにアイデンティティを持たせることを考え始めてください。**Web Bot Auth のような標準はまだ初期段階ですが、方向性は明確です。身元を検証できる AI は、今後ネット上で「匿名 AI」よりはるかにスムーズに行き来できるようになります。一歩でも早く導入すれば、その分早く誤って排除されるのを避けられます。
ついでに、多くの人が抱くかもしれない不安にお答えしておきます。CAPTCHA が一夜にして消えることはありません。明日サイトにログインするときも、相変わらず信号機をクリックすることになるでしょう。本当に変わるのは、その裏側にあるロジックです——ただ、あなたにはそれが感知できないだけ。インフラの入れ替わりは昔からひっそりと進むものです。スマートフォンを買い替える必要はないのに、世界の鍵はすでに取り替わっているのです。
Q5：この件の終局は何か？20年後、私たちはどうやって自分を証明するのか？
永亮：終局は——もはや証明が不要になることかもしれない。
20年前を振り返ると、キャプチャの全盛期とは、本質的に「人間がインターネットを利用し、機械が補助する」という時代だった。人と機械の境界は明確だったからこそ、たった一つの問題で両者を分けられた。今、その境界は溶解しつつある。人間のあらゆる動作に AI が関与し、AI のあらゆる操作の背後には人間の意図がある。
そのときが来れば、「アイデンティティ」はもっと下のレイヤーへと沈むことになる。あなたのデバイス、あなたの鍵、あなたの生体情報、あなたの認可チェーン——それらがバックグラウンドですべての証明を完了する。あなたは認証の存在を感知しなくなるだろう。ちょうど今、あなたが TLS ハンドシェイクの存在を感知していないのと同じように。
美しい話に聞こえる？あえて逆方向からの注意をひとつ残しておこう。**証明が完全に自動化されるとき、なりすましのリスクもまた完全に自動化される。**あなたの AI アイデンティティが盗まれることは、デジタル世界の「あなた」を盗まれるのと同じことだ。今後は、秘密鍵をしっかり管理することが、身分証をしっかり管理するのと同じくらい重要になる。
20年前の問いは「画面の向こうに人間はいるか」。20年後の問いは「画面の向こうに10個のアイデンティティがあるとき、どれが本当にあなたを表しているのか」。
エピローグ
拾闻：最後に、この回を一言でまとめると？ 永亮：AIがクリアしたのはキャプチャではなく、「人間と機械は別々の側に立たねばならない」という旧い世界――これからの安全は、機械を試験で打ち負かすことではなく、機械をきちんと管理することで守られる。 拾闻：この言葉を、皆さんに贈ります。それでは、また次回。
【技術深掘り】現代アンチボット体系の三層防御は、どんな姿をしているのか？
今号では「防御線の引っ越し」について繰り返し述べてきたが、技術系読者のために、現在の実際のレイヤー構造を分解して解説しよう（Cloudflare の体系を例に）。
**第一層：クライアントチャレンジ。**ページがロードされると、軽量な JavaScript がブラウザ内で動く。計算チャレンジ（負荷が大きすぎない計算問題を出題する）、Web API のプローブ（このブラウザに、正常なブラウザが備えるべきインターフェースがあるか）、環境整合性チェック（画面サイズ、フォント、タイムゾーンが辻褄合っているか）。人間には感知されず、秒単位で完了する。生成されるのは短期間・ワンタイムの token だ――注意してほしいのは、フロントエンドのコードを書き換えて「合格」を偽装しても意味がないということ。token はサーバーに持っていき、引き換えて検証される必要があるからだ。
**第二層：ネットワーク層のフィンガープリント。**TLS ハンドシェイクの際、クライアントは暗号スイートの優先順位や拡張の順序といった特徴を晒す（JA3/JA4 フィンガープリント）――本物の Chrome と Python スクリプトでは、フィンガープリントはまったく異なる。さらにリクエストヘッダーの順序や HTTP/2 のフレーム挙動を重ね合わせれば、サーバーは内容を見ないまま接続のプロファイリングができる。多くのクローラーが「リクエストを送る前にブロックされる」のは、まさにこのためだ。
**第三層：サーバー側のリスク管理。**token 検証（有効性、使用済みかどうか、時間窓）+ 行動シーケンス分析（この IP の直近一時間のリクエストは、正常なユーザーのものに似ているか）+ ビジネスルール（注文頻度、デバイスとアカウントの紐付け関係）。この層が見ているのは一回のリクエストではなく、時間軸全体だ。
**追加されつつある第四層：暗号学的身元。**Web Bot Auth は HTTP Message Signatures 規格を用いる。AI クライアントは Ed25519 秘密鍵で各リクエストに署名し、署名はリクエスト内容をカバーし（改ざん防止）、created/expires の時間窓を備え（リプレイ防止）、公開鍵は検索可能なディレクトリに公開される。サーバーによる署名検証のコストはミリ秒レベルだが、偽造の難易度は暗号学レベルだ。
四層を重ねると、CAPTCHA のあの九マス画像が、この体系全体における実際の役割はこうだ：本物のユーザーに「私は保護されている」という儀式感を与えること。扉の鍵は、とっくにあなたの見えない場所へと付け替えられている。