「私はロボットではありません」は何を見ている？CAPTCHAが人間を見分ける仕組みを追う

「私はロボットではありません」は何を見ている？CAPTCHAの仕組み・マウス・VPN・AIまで解説

Webサイトで、ときどき見かける小さな四角。

「私はロボットではありません」

人間なら、チェックを入れるだけです。

しかし、よく考えると妙ではないでしょうか。ロボットだって、チェックボックスをクリックするくらいならできそうです。

それなのに、あるときはチェックひとつで先へ進める。別の日には、信号機や横断歩道の画像を何度も選ばされる。VPNを使った途端に確認が増えた、と感じる人もいます。

では、あのチェックボックスの裏側では、いったい何を見ているのでしょうか。

最初に結論を言うと、チェックボックスを押せること自体を「人間の証明」にしているわけではありません。

少なくともGoogleは、2014年に「私はロボットではありません」を導入した時点ですでに、CAPTCHAとの関わり全体をリスク分析する仕組みを説明していました。現在のGoogle Cloudではさらに、サイト上のインタラクションだけでなく、IPアドレス、User-Agent、JA3・JA4と呼ばれるTLSクライアントの特徴、トークンなど、評価に利用できる情報の一部が公式資料に明記されています。

ただし、ここには大きな注意点があります。

Googleは、最終的な判定アルゴリズムや、使っている全シグナル、その重みを公開していません。

そのため、「マウスを一直線に動かすとbot扱いされる」「クリックまでの時間を見ている」「Googleにログインしていれば通りやすい」といったネット上で有名な説明を、現在のreCAPTCHAの仕様として断定することはできません。

そして2026年現在、この話はもはや「人間かロボットか」だけでは終わらなくなっています。

Google、Cloudflare、hCaptchaなどのbot対策は、画像を人間に解かせる仕組みから、アクセスのリスクを裏側で評価し、正規のbot、悪質な自動化、さらにはAI Agentまで見分けようとする仕組みへ変わりつつあります。

※本記事は2026年9月18日時点で確認できるGoogle Cloud、Cloudflare、hCaptcha、Carnegie Mellon University、W3C等の公式資料・一次資料を基準にしています。公開されていない判定ロジックについては推測で補っていません。

「私はロボットではありません」は、結局何を見ている？

まず、この記事で一番知りたいところから整理しましょう。

現在のreCAPTCHAについて、Googleが公式に公開している情報から確実に言えるのは、一つの動作だけで判定している仕組みではないということです。

Googleは2014年にNo CAPTCHA reCAPTCHAを発表した際、Advanced Risk Analysisによって、ユーザーがCAPTCHAと関わる「前・最中・後」を含めて評価すると説明しました。

さらに現在のGoogle Cloud Fraud Defense／reCAPTCHAでは、Webサイト側がAssessmentと呼ばれる評価を作成する際、次のような情報を扱えることが公式資料に記載されています。

一方、次のような話については事情が違います。

技術的に取得できる情報と、Googleが現在reCAPTCHAの判定に利用していると公表している情報は同じではありません。

ここを混ぜると、「reCAPTCHAの秘密はマウスの動きだった」といった、分かりやすいけれど裏付けの弱い説明になってしまいます。

マウスの動きを見ている、は本当？

「私はロボットではありません」の仕組みを検索すると、かなり高い確率で出てくるのがマウス軌跡の話です。

人間がマウスを動かせば微妙に揺れる。botならチェックボックスへ一直線に移動する。だからreCAPTCHAは軌跡を見れば人間かどうか分かる――という説明です。

しかし、現在のGoogle公式資料から、そこまで具体的な判定方法は確認できません。

Googleが公表しているのは、2014年の段階でユーザーとCAPTCHAとの関わり全体をリスク分析すること、そして現在はサイト上のインタラクションや各種リクエスト情報を組み合わせてリスク評価を行うことです。

そこから「マウス軌跡だけを見ている」「直線なら失敗する」という具体的なルールまで広げることはできません。

面白いのは、別のCAPTCHAサービスでは事情が違うことです。

hCaptchaは現在のプライバシーポリシーで、人間かどうかを判断するため取得し得る情報として、マウスの動き、スクロール位置、キー入力イベント、タッチ操作などを明示しています。

つまり、「行動情報を見るbot対策は存在する」というところまでは事実です。

しかし、hCaptchaが公表している仕様を、そのままGoogle reCAPTCHAにも当てはめることはできません。

「チェックを一瞬で押すとbotになる」も確認できない

同じ理由で、「ページを開いて0.5秒でチェックするとbot扱い」「わざとカーソルをぐるぐる動かせば通りやすい」といった話も、Googleの現在仕様として裏付けられていません。

しかも、こうした説明を攻略法として受け取るのは危険です。

現在のbot判定は、単一の動作だけを見ているとは限りません。マウスを不自然に動かすといった小細工で、リスク評価全体をコントロールできると考えない方がよいでしょう。

IPアドレスは本当に見られている？

これは公式資料で確認できます。

現在のGoogle Cloudでは、reCAPTCHAのAssessment作成時にuserIpAddressを渡すことが案内されています。

ただし、IPアドレスを使うからといって、

「このIPなら人間」

「VPNのIPならbot」

「同じIPなら同じ人」

と単純に判断しているわけではありません。

家庭のWi-Fiでも複数人が同じグローバルIPを共有することがあります。会社、学校、携帯電話回線、大規模なNAT環境では、さらに多くの利用者が外から見れば同じIPに集約されることがあります。

VPNでも、一つの出口IPを多数の利用者が共有することがあります。

そのためIPは、あくまで多数あるシグナルの一つとして考えるのが自然です。

JA3・JA4って何？IPアドレスとは違うの？

2026年のreCAPTCHAを調べると、以前の一般向け解説ではほとんど見かけなかったJA3とJA4という言葉が出てきます。

どちらも大まかに言えば、WebブラウザなどがHTTPS通信を始めるときのTLS接続の特徴から、「どういう種類のクライアントに見えるか」を表現するためのフィンガープリントです。

IPアドレスが主に「どこから通信が来ているか」に関係する情報だとすれば、JA3やJA4は「どのような特徴を持つTLSクライアントが通信してきたか」を見る別の角度です。

ここで注意したいのは、スマートフォン一台につき永久に変わらない固有番号が割り当てられる、という意味ではないことです。

ブラウザ、ライブラリ、TLSの実装や設定などが変われば特徴も変わり得ます。

bot対策側からすれば、User-Agentでは普通のブラウザを名乗っているのに、TLS接続の特徴がその説明と不自然に食い違う、といった状況を判断する材料の一つになり得ます。

Cookieは関係する？Googleにログインしていると通りやすい？

Cookieについては、Google公式に確認できる事実があります。

reCAPTCHAは実行時、リスク分析のために必要な_GRECAPTCHA Cookieを設定するとGoogle CloudのFAQに記載されています。

したがって「reCAPTCHAはCookieを一切使わない」は誤りです。

一方で、ここから

「Cookieが長期間残っていれば信頼される」

「Cookieを削除するとbotになる」

「Googleアカウントに長年ログインしていれば一発で通る」

と結論付けることはできません。

Googleは、そうした単純な判定ルールを現在の公式資料で公開していないからです。

Googleアカウントへのログインは？

これもよく語られますが、「Googleアカウントへログインしている利用者はreCAPTCHAで高評価になる」という現在の公式仕様は確認できません。

少なくとも公開情報だけから、

Googleログイン中＝人間として信頼される

とは書けません。

「reCAPTCHAを使うと閲覧履歴が全部Googleへ送られる」は？

これも別の話が混ざっています。

Webページ上でreCAPTCHAが動作し、リスク分析用の情報が処理されることと、ブラウザに保存された全閲覧履歴がGoogleへ送信されることは同じではありません。

Googleは現在、IPアドレスやUser-Agent、JA3・JA4など複数の情報を扱う仕組みを公開していますが、「reCAPTCHAを置いたページを開くと、その人のブラウザの全閲覧履歴を取得する」という仕様は確認できません。

シークレットモードを含め、ブラウザに何が残り、Webサイトやネットワーク側に何が見えるのかは別の記事で詳しく整理しています。

シークレットモードなら履歴は残らない？家族・会社・学校・プロバイダから何が見えるのか

シークレットモードだとCAPTCHAが増える？

「シークレットモードにした途端、CAPTCHAが増えた」という体験談もあります。

シークレットモードでは通常のブラウジングとはCookieやサイトデータの扱いが異なるため、サイトから見える状態に違いが生じること自体はあります。

しかし、Googleが「シークレットモードだからreCAPTCHAの評価を下げる」という仕様を公表しているわけではありません。

したがって、

シークレットモード＝bot扱い

と考えるのは行き過ぎです。

なおCloudflareのトラブルシューティングでは、逆に拡張機能やキャッシュの影響を切り分けるため、プライベートブラウジングを試す方法も案内されています。

同じ「シークレットモード」でも、状況によって確認の増減を一律には説明できません。

VPNを使うとCAPTCHAが増えることがあるのはなぜ？

VPNだからロボットと判断される、という意味ではありません。

ただしVPNでは、サイトから見える通信元IPがVPN事業者の出口IPになります。

多数の利用者が同じIPを共有していたり、そのIPから短時間に大量のアクセスが発生していたりすれば、サービス側から見えるネットワーク上の状況は通常の家庭回線とは違ってきます。

Google検索の公式ヘルプでも、VPNを含むネットワークから自動生成されたような異常なトラフィックが検出された場合、reCAPTCHAによる確認が表示されることがあると案内されています。

Cloudflareも2026年の公式トラブルシューティングで、共有VPNや企業プロキシなどのIP reputation、VPN／Proxy拡張機能によるIPの不整合などが追加のセキュリティ確認に関係する場合があると説明しています。

つまり、正確にはこうです。

なぜ画像問題が出る人と出ない人がいる？

昔の文字CAPTCHAは、基本的に誰に対しても問題そのものを解かせる方式でした。

ところが「私はロボットではありません」のreCAPTCHAでは、リスク分析が前段に入ります。

現在のGoogle Cloudでも、CHECKBOXキーではチェック後にCAPTCHA Challengeが出る場合と出ない場合があることが公式に説明されています。

低リスクと判断できる場合は、追加の画像問題なしで進める。

もう少し確認が必要なら、画像などのChallengeを追加する。

大まかにはこの理解で問題ありません。

ただし、「IPが悪いから画像が出た」「マウスを早く動かしたから出た」というように、一つの原因へ決めつけることはできません。

正解しているのに何度も画像が出るのはなぜ？

画像を正しく選んだつもりなのに、新しい問題が続けて出てくることがあります。

これも必ずしも「一問目を間違えた」という意味ではありません。

追加のChallengeが必要と判断された可能性のほか、ブラウザ環境、JavaScript、拡張機能、通信状態、Challengeに必要なCookieやスクリプトの処理などが正常に完了していないケースも考えられます。

CloudflareはChallengeが繰り返される原因として、ネットワークの不安定さ、ブラウザ設定、拡張機能、JavaScript無効、非対応ブラウザ、検知エラーなどを公式に挙げています。

CAPTCHAが何度も出るからといって、単純に「あなたが怪しまれている」という話ではありません。

信号機が少しだけ写っていたら選ぶ？

これもCAPTCHA利用者が迷いやすい問題です。

タイルの端に信号機がほんの少しだけ入っている。横断歩道の白線が隣のマスにも続いている。こうした場合に「1ピクセルでも入っていたら必ず選ぶ」と説明する記事もあります。

しかし、Googleは一般利用者向けにそのようなピクセル単位の判定ルールを公開していません。

この記事でも独自の攻略ルールは作りません。

そもそもCAPTCHAとは何？

CAPTCHAは、

Completely Automated Public Turing Test to Tell Computers and Humans Apart

の頭文字です。

日本語に直訳すれば、「コンピューターと人間を見分けるための、完全自動化された公開チューリングテスト」といった意味になります。

Carnegie Mellon Universityによると、CAPTCHAは2000年にLuis von Ahn、Manuel Blum、Nicholas J. Hopper、John Langfordらの研究チームによって開発され、名称もこの時期に作られました。

2002年に関連する技術報告が発表され、2003年には「CAPTCHA: Using Hard AI Problems for Security」がEUROCRYPTで発表されています。

普通のチューリングテストとは少し違う

1950年にAlan Turingが提起した有名なチューリングテストでは、人間側の判定者が対話相手が人間か機械かを見分けます。

CAPTCHAは少し立場が逆です。

コンピューター自身が問題を作り、答えを採点しながら、アクセスしている相手が人間らしいかを判定します。

そのため「逆チューリングテスト」と説明されることもありますが、単純にTuring Testを裏返しただけではありません。

研究上の面白さは、コンピューター自身は問題を完全に解けないのに、人間の正解かどうかは自動判定できる問題をどう作るかというところにありました。

なぜCAPTCHAが必要になった？

1990年代末から2000年代初頭のWebでは、自動化されたプログラムによる大量操作がすでに問題になっていました。

無料メールアカウントを大量作成する。オンライン投票を自動化する。フォームへスパムを送る。チケットなど限られた商品へ自動でアクセスする。

一人の人間なら時間がかかる操作も、プログラムなら一瞬で何千回、何万回と繰り返せます。

そこで必要になったのが、Webサイト側が自動で、

「これは普通の利用者なのか、それとも自動化されたプログラムなのか」

を判断する仕組みでした。

約25年前、最初は「歪んだ文字」だった

初期CAPTCHAの代表格が、背景にノイズを入れたり、文字を曲げたり、線を重ねたりした画像から文字列を読み取らせる方式です。

今見ると古典的ですが、当時は理にかなっていました。

人間は多少崩れた文字でも文脈や形から読める。一方、当時のOCR、つまり画像から文字を読み取るコンピューター技術は、ノイズや歪みに弱かったからです。

ここにはCAPTCHAの基本思想がそのまま表れています。

「人間には簡単だが、現在のコンピューターには難しい問題」をセキュリティへ利用する。

ただし、この前提には弱点もありました。

AIが進歩して問題を解けるようになれば、そのCAPTCHAは寿命を迎えます。

実際、その後の約25年間はこの繰り返しになりました。

reCAPTCHAは「人間確認」を別の仕事にも使った

2007年、Luis von AhnらはreCAPTCHAを開始します。

ここで発想が一段変わりました。

世界中の人に毎日大量の文字を読ませるのなら、その労力を「人間確認」だけに使うのはもったいない。

そこで、古い書籍や新聞をデジタル化するとき、OCRが読めなかった文字をCAPTCHAの問題として人間に読んでもらう仕組みが作られました。

2008年にScienceへ掲載されたreCAPTCHAの論文では、古い印刷物をスキャンした際、OCRが正確に認識できなかった単語を人間へ提示してデジタル化を補助する仕組みが詳しく説明されています。

なぜ昔のreCAPTCHAは2つの単語が出たのか

昔のreCAPTCHAを覚えている人なら、歪んだ単語が2つ並んでいたことを思い出すかもしれません。

あの2語には役割の違いがありました。

一つは、システム側がすでに正解を知っているcontrol word。

もう一つは、OCRでは正しく読み取れず、まだ正解が確定していないunknown wordです。

利用者がcontrol wordを正しく入力できれば、「この回答者は正しく文字を読める可能性が高い」と考えられます。

そこで一緒に入力されたunknown wordの答えも候補として記録します。

同じunknown wordを複数の利用者へ見せ、回答が一致してくれば、その文字列を正解として確定していく。

つまり利用者は、Webサイトへ入るための確認作業をしながら、同時にコンピューターが読めなかった古い文章を読んでいたのです。

CAPTCHAを解くことでGoogle Booksを作っていた？

ここは少し注意が必要です。

旧reCAPTCHAが、古い書籍や新聞のOCR補正に実際に利用されていたことは事実です。

しかし、「世界中の人がCAPTCHAを解いてGoogle Booksそのものを作った」という説明は単純化しすぎです。

reCAPTCHAはGoogleに買収される以前から存在しており、2008年の論文では大規模デジタル化プロジェクトの文脈としてGoogle BooksやInternet Archiveなどにも触れています。

正確には、大規模な印刷物デジタル化でOCRが読めなかった単語を、人間のCAPTCHA回答によって補正する仕組みだったと考えるのがよいでしょう。

2009年、GoogleがreCAPTCHAを買収

reCAPTCHAは最初からGoogleのサービスだったわけではありません。

GoogleがreCAPTCHAの買収を公式発表したのは2009年9月16日です。

Googleは当時、reCAPTCHAが10万以上のWebサイトをスパムや不正から守っていることに加え、古い書籍や新聞をスキャンした際にコンピューターが読めなかった単語を、人間がCAPTCHAとして入力する仕組みに注目していました。

セキュリティ確認と人間による文字起こしを一つの作業にまとめたところが、旧reCAPTCHAの大きな特徴でした。

文字CAPTCHAを終わらせたのは、皮肉にもAIだった

CAPTCHAの原点は、「人間には読めるがコンピューターには読めない文字」です。

しかしコンピューター側が進歩すれば、その差は当然縮まります。

Googleは2014年12月、当時のAI技術が最も難しい種類の歪み文字CAPTCHAを99.8％の精度で解けるようになったと説明しました。

ここで注意したいのは、

「2014年のAIがreCAPTCHA全体を99.8％突破できた」わけではない

ということです。

99.8％という数字は、難しい歪み文字を読む能力についての話です。

Googleは同じ2014年4月にも、Street View向けに開発した画像認識技術を使うと、難しいreCAPTCHA文字を99％以上の精度で解読できたと報告しています。

つまり「歪ませた文字を読ませる」という試験だけでは、すでに十分な防御にならなくなっていました。

Street Viewの数字から、画像を選ぶCAPTCHAへ

GoogleはreCAPTCHAの10周年を振り返った2017年の公式記事で、その変化を簡潔に整理しています。

歪んだ文字。

次に、Street Viewの番地や名称。

そして2014年のNo CAPTCHA reCAPTCHA。

2017年のInvisible reCAPTCHA。

技術の進歩に合わせて、「人間に何をさせるか」そのものが変わってきました。

現在よく知られている、信号機、横断歩道、バス、自転車、オートバイ、消火栓などを選ぶ画像問題も、この流れの中にあります。

なぜ信号機や横断歩道を選ばされるの？

Googleが2014年のNo CAPTCHA reCAPTCHA発表時に説明していたのは、画像群の中から指定された対象を選ばせる、いわゆる画像ラベリングというComputer Visionの問題です。

文字認識が機械にとって簡単になれば、今度は当時のコンピューターが苦手としていた画像認識を問題にする。

CAPTCHAの歴史から見れば自然な変化でした。

「自動運転AIの教師データを無料で作らされている」は本当？

これは非常に有名な説です。

信号機、横断歩道、バス、自転車など、道路に関係する画像が多いため、「Googleの自動運転AIへ教師データを与えている」と説明されることがあります。

しかし、2026年現在確認できるGoogle公式資料から、現在の画像reCAPTCHAの回答がすべて自動運転AIの教師データとして使われているとは確認できません。

Street Viewの画像認識技術とreCAPTCHAが歴史的に深く関係しているのは事実です。

旧reCAPTCHAで人間の回答をOCR補正に利用したことも事実です。

ただし、この2つの事実をつなげて「現在の信号機CAPTCHA＝自動運転学習」とするのは飛躍があります。

Googleについては、公式に確認できる範囲に留めるべきです。

一方、CAPTCHA回答を機械学習へ使うサービス自体は存在する

ここが少しややこしいところです。

hCaptchaは現在のプライバシーポリシーで、利用者がChallengeへ回答した結果から得られる画像ラベルや音声から変換したテキストなどをLabeled Dataとして扱い、機械学習用途のデータラベリングサービスに利用することを明記しています。

したがって、

「CAPTCHA回答が機械学習データになることは絶対にない」

も間違いです。

正しくは、サービスや時代によって違うということになります。

2014年、「私はロボットではありません」が登場

大きな転換点が2014年12月3日です。

Googleは「No CAPTCHA reCAPTCHA」を発表しました。

あの有名な、

「I'm not a robot」

というチェックボックスです。

一見すると、それまでの歪んだ文字より簡単すぎます。

ロボットでもチェックできるからです。

しかしGoogleが前年から進めていたのは、文字問題そのものへ頼る方式ではなく、Advanced Risk AnalysisによってユーザーとCAPTCHAとの関わり全体を評価する方式でした。

リスク分析で十分に判断できれば、利用者はチェックだけで通過する。

判断しきれないときには、追加の画像Challengeを出す。

つまり、チェックボックスを難しくしたのではなく、難しい判定を裏側へ移したのです。

2017年、チェックボックスすら消え始める

次の転換は2017年3月7日。

Invisible reCAPTCHAが登場します。

名前の通り、「私はロボットではありません」のチェックボックス自体を表示せず、バックグラウンドでリスク分析を行う方式です。

Googleは同年6月、Invisible reCAPTCHAについて、日々多くの人間の利用者がクリックなしで通過していると説明していました。

この時点でCAPTCHAは、すでに「人間へ問題を見せるもの」から離れ始めています。

2018年、reCAPTCHA v3は「問題」ではなくスコアを返した

2018年10月29日、GoogleはreCAPTCHA v3を公開しました。

v3の大きな違いは、原則として利用者へCAPTCHA問題を出さず、アクセスごとにスコアを返すことです。

現在のGoogle Cloudでも、この考え方は続いています。

スコアは0.0から1.0。

1.0に近いほどリスクが低く、正当なインタラクションである可能性が高い。

0.0に近いほどリスクが高く、不正である可能性が高いという評価です。

ここで「人間らしさスコア」と呼んでしまうと少し意味が変わります。

1.0＝人間、0.0＝ロボットという認定ではありません。

現在の公式資料でも、「低リスクで正当である可能性が高い」「高リスクで不正の可能性がある」という説明になっています。

0.5未満ならbot、という共通ルールもない

サイトによって、守りたいものは違います。

ブログへのコメント投稿と、オンラインバンキングのログインでは、許容できるリスクが同じではありません。

そのためサイト運営者はスコアを受け取り、その値や用途に応じて、

そのまま通す。

追加認証を求める。

投稿を保留する。

アクセスを制限する。

といった対応を決めます。

「0.5未満は全サイトでbot」という仕組みではありません。

2026年、GoogleのreCAPTCHAはv2・v3だけでは説明できない

現在も「reCAPTCHA v2とv3の違い」という説明はよく見かけます。

歴史を知るうえでは分かりやすいのですが、2026年のGoogle Cloud体系を説明するには、それだけでは足りません。

Webサイト向けの現在の主なキーは、次のように整理されています。

Googleは現在、Checkbox方式を推奨していない

ここは「私はロボットではありません」というUIの歴史を考えるうえで、かなり象徴的です。

Google Cloudは現在、WebサイトでScore-based keyを推奨しています。

一方のCheckbox keyについては、ユーザーの負担を増やす一方で精度を大幅には改善しないとして、使用を推奨していません。

あれだけ有名になった「私はロボットではありません」は今も残っていますが、Google自身のbot対策はすでに、そのチェックボックスを中心とした考え方から先へ進んでいます。

2026年、reCAPTCHAはGoogle Cloud Fraud Defenseの一部になった

さらに大きな変化が2026年4月にありました。

GoogleはGoogle Cloud Fraud Defenseを発表し、「reCAPTCHAの次の進化」と位置付けました。

reCAPTCHAそのものが消えたわけではありません。

Googleによれば、既存reCAPTCHAはFraud Defenseの中核となるbot防御として継続します。

変わったのは、見ようとしている対象です。

従来のイメージは、

人間　対　bot

でした。

現在のFraud Defenseは、そこへAI Agentを含むさまざまな自動化が加わります。

2026年7月には、Agent overview dashboardが追加され、verified agentとsuspected agentを区別して監視する仕組みも公開されています。

API上でも、botの種類としてAI_AGENT、CONTENT_SCRAPER、SEARCH_INDEXERなどを扱う仕組みが確認できます。

つまり今後重要になるのは、単純に、

「機械なら拒否」

ではありません。

「このアクセスは何者で、どの程度信用でき、何をしようとしているのか」

という判断へ変わりつつあります。

bot＝悪者ではない

Googlebotのような検索エンジンのクローラーもbotです。

サイト監視サービスも自動アクセスします。

そして2026年には、人間の指示を受けてWebを操作するAI Agentも現実のアクセス主体になっています。

全部を「ロボットだから拒否」してしまえば、検索エンジンからも見えなくなり、正当な自動化サービスも利用できなくなります。

そのため現在のbot対策では、

正規の検索bot。

許可したAI Agent。

コンテンツを大量取得するスクレイパー。

不正ログインを繰り返すbot。

一般の利用者。

といった違いを識別する必要が出てきました。

Cloudflareの「確認しています」は何をしている？

Google以外で、現在よく見かけるのがCloudflareです。

Webサイトへ入ろうとすると、

「確認しています」

「Verify you are human」

といった画面が数秒表示されることがあります。

ここではまず、Cloudflare Challenge PageとTurnstileは同じものではないと整理しておきましょう。

Challenge Pageはサイトへ入る前に表示される確認画面。

Turnstileはログインフォームや問い合わせフォームなど、ページ内へ組み込める仕組みです。

ただし両者はCloudflareのChallenge Platformという共通の基盤技術を利用しています。

Cloudflare Turnstileは何を見ている？

CloudflareはTurnstileを「CAPTCHA alternative」、つまりCAPTCHAの代替として位置付けています。

2026年8月更新の公式ドキュメントでは、最初にブラウザ上で複数の小さな非対話型JavaScript Challengeを実行し、訪問者やブラウザ環境についてのシグナルを集めると説明しています。

例として挙げられているのが、

proof-of-work。

proof-of-space。

Web APIの確認。

ブラウザ固有の挙動。

human behavior。

などです。

これらを組み合わせ、できるだけ人間へ画像問題を出さずに判断します。

Managed・Non-interactive・Invisibleの違い

ここでも重要なのは、チェックボックスそのものではありません。

Cloudflare自身も、Turnstileではチェックする行為より、ブラウザ側で実行しているテストや取得したシグナルの方が重要だと説明しています。

Proof of Workって、仮想通貨のマイニングと同じ？

Turnstileの説明で少し驚くのがproof-of-workという言葉です。

Bitcoinなど暗号資産でも有名なので、「CAPTCHAを見るたびにマイニングさせられているの？」と思うかもしれません。

同じ言葉でも、目的も規模も違います。

Turnstileで説明されているのは、ブラウザへ小さな計算問題を行わせるChallengeの一種です。

その結果を、ブラウザ環境が正常に動いているか判断する複数シグナルの一つとして利用します。

大量の電力や計算資源を使って暗号資産ネットワークの合意形成を行うマイニングと同一視する必要はありません。

proof-of-spaceについてもCloudflareはChallengeの一つとして公式に挙げていますが、内部判定の細部までは公開していません。

Private Access TokenならCAPTCHA自体を減らせる

さらに別の方向からCAPTCHAを減らそうとしているのが、Private Access Token（PAT）です。

Appleは2026年現在、iPhone、iPad、Macで自動認証を提供しています。

対応するサイトやアプリでは、Apple Accountへサインイン済みの端末についてApple側がデバイスとアカウントを確認し、第三者のトークン発行サーバーを通じてPrivate Access Tokenを生成します。

Appleの説明では、Apple自身は利用者がどの対応サイトへサインインしようとしているかを知ることができず、閲覧履歴にもアクセスしません。サイト側へ渡るのもPrivate Access Tokenです。

CloudflareのChallenge PlatformでもPATは判断材料の一つとして利用されます。

ただし、PATがあればCloudflare Challengeを必ず自動通過できるわけではありません。

Cloudflare自身も、有効なPATによって一部のChallengeを省略できる場合はあるものの、Challenge Pageそのものを無条件に回避するものではないと説明しています。

それでも方向性は興味深いものです。

人間に「信号機を選んでください」と試験する代わりに、プライバシーを守りながら信頼できる端末・環境であることを証明する。

CAPTCHAの未来を考えるうえで重要な考え方です。

hCaptchaはGoogleやCloudflareと何が違う？

もう一つの主要なサービスがhCaptchaです。

hCaptchaというと画像問題のイメージが強いですが、現在はそれだけではありません。

Invisible方式に加え、EnterpriseではPassive mode、リアルタイムのrisk scoring、device intelligence、AI Agent Detectionなどを提供しています。

Passive modeでは、可視のChallengeを出さずにリスク評価を使う構成も可能です。

そして先ほど触れた通り、hCaptchaはプライバシーポリシーで、マウス移動、スクロール位置、キー入力、タッチイベントなどを人間判定のため収集する情報として具体的に公表しています。

この点でも、内部シグナルの詳細をすべて同じレベルでは公表していないGoogleとは情報の出し方が違います。

2026年の主要bot対策を比べるとどうなる？

どれが「最も優れている」と単純には比較できません。

守る対象、サイトの規模、プライバシー要件、アクセシビリティ、必要な摩擦の少なさなどで選択は変わります。

CAPTCHAとパスワード・2段階認証・パスキーは別物

CAPTCHAを「本人確認」と説明することがありますが、厳密にはパスワードやパスキーとは役割が違います。

CAPTCHAやbot対策が見ようとしているのは、アクセスが正当そうか、自動化による不正ではないか、といったリスクです。

一方、パスワード、SMS認証、パスキーなどは、アカウントへアクセスしている本人を認証するための仕組みです。

CAPTCHAを通過したからといって、その人がアカウント所有者本人だと証明されたわけではありません。

パスキーの仕組みについては、パスキーとは何？パスワードとの違い・機種変更・紛失・iPhone⇔Android移行まで整理で詳しく解説しています。

AIが画像を読めるなら、CAPTCHAはもう意味がない？

CAPTCHAの歴史を振り返ると、この疑問はかなり本質的です。

初期CAPTCHAの前提は、

「人間には簡単だが、機械には難しい」

でした。

しかし今のAIは、文字認識、画像認識、物体検出、自然言語理解で大きく進歩しています。

Googleが2014年に歪み文字を99.8％で認識できると公表した時点で、文字問題だけへ頼る方式の限界は明白になっていました。

画像認識も同じ道をたどります。

だから現在のbot対策は、

「この画像をAIが解けるか？」

だけで勝負しなくなっています。

ブラウザ環境。

通信の特徴。

アクセス量。

サイト内でのインタラクション。

セッション全体。

既知の正規botか。

AI Agentなのか。

こうした複数の情報を合わせて評価する方向へ移っています。

「CAPTCHAを通過した＝100％人間」ではない

言葉としては「人間確認」ですが、現代の仕組みを理解するなら、100％の証明だと思わない方がよいでしょう。

Google Cloudのスコアは、人間である確率そのものではなく、インタラクションのリスクや正当性を評価します。

理由コードとしても、

AUTOMATION。

UNEXPECTED_ENVIRONMENT。

TOO_MUCH_TRAFFIC。

UNEXPECTED_USAGE_PATTERNS。

LOW_CONFIDENCE_SCORE。

といった分類があります。

つまり判断しているのは、単純な「人間／機械」の二択だけではありません。

Cloudflareでも、Challenge結果やブラウザ環境、ネットワークなど複数の情報を扱います。

bot対策は「人間であることを数学的に証明する装置」というより、不正なアクセスをできるだけ正確に見分けるリスク管理の仕組みへ近づいています。

人間なのにCAPTCHAを解けない、というもう一つの問題

機械がCAPTCHAを解けるようになった一方で、逆方向の問題もあります。

本物の人間なのにCAPTCHAを解けない。

W3Cは長年、CAPTCHAのアクセシビリティ問題を指摘しています。

歪んだ文字は、視覚障害や弱視だけでなく、ディスレクシアなど一部の認知特性を持つ人にも大きな負担になります。

画像選択も、視覚に頼っています。

音声Challengeを用意すればすべて解決するわけでもありません。聴覚障害、聴覚処理に困難がある人、音声を利用しにくい環境では別の問題が発生します。

W3CのWCAG 2.2でも、CAPTCHAを使う場合は目的を説明するテキストと、異なる感覚モードを使う代替手段を提供することが求められています。

現在の各サービスも「人に問題を出さない」方向へ進んでいる

Cloudflare TurnstileはWCAG 2.2 AA準拠を掲げ、画像や歪み文字の問題を基本的な方式としていません。

hCaptchaもテキストベースのAccessibility Challengeやアクセシビリティ用の認証手段を用意し、EnterpriseではPassive modeも提供しています。

GoogleもScore-based keyを推奨しており、現在の公式資料ではアクセシビリティ要件があるWebサイトをScore方式の利用例として挙げています。

人間に難しい問題を解かせ続けること自体が、bot対策の弱点になり始めているのです。

CAPTCHAの約25年を並べると、変化がよく分かる

CAPTCHAは25年間でどう変わった？

よくあるCAPTCHAの俗説を整理

では、CAPTCHAはこれから消える？

「消える」と断言するのはまだ早いでしょう。

実際、2026年現在も画像Challengeやチェックボックスは使われています。

GoogleもPolicy-based challengeや新しいChallenge方式を開発しています。

ただし方向性はかなりはっきりしています。

人間へ文字を読ませる。

人間へ画像を選ばせる。

そこから、

ブラウザ自身がChallengeを処理する。

端末や環境が信頼性を証明する。

アクセスをリスクスコアで評価する。

正規botと悪質botを分ける。

AI Agentを識別する。

という流れへ進んでいます。

2026年7月にはGoogle Cloud Fraud Defenseで、Policy EngineやUniversal keysに加え、AIによる自動操作へ対抗するための新しいQRコードChallengeもPreviewとして公開されました。

これも、「AIには解けない画像を探し続ける」だけでは難しくなったことを象徴する動きです。

まとめ｜チェックボックスが人間を見分けていたわけではない

「私はロボットではありません」の四角を見ると、ついチェックする行為そのものが試験だと思ってしまいます。

しかし、CAPTCHAの約25年を追うと、実際には逆でした。

最初は、人間に問題を解かせることが中心でした。

歪んだ文字を読み、古い書籍のOCRを補正し、Street Viewの文字や画像を認識する。

ところがAIが進歩し、「人間に簡単で機械には難しい問題」を作ること自体がどんどん難しくなりました。

そこで2014年のNo CAPTCHA reCAPTCHAでは、目に見える問題よりも裏側のリスク分析が重要になります。

2017年にはチェックボックスすら消え、2018年のv3ではスコア方式へ進みました。

そして2026年、GoogleはreCAPTCHAをGoogle Cloud Fraud Defenseへ広げ、Cloudflare TurnstileやhCaptchaも、人間に画像を解かせるより、ブラウザ環境、行動、ネットワーク、リスクスコアなどから判断する方向へ進んでいます。

現在のCAPTCHAを一言で「人間かロボットかを当てるテスト」と考えると、少し実態からずれます。

今のbot対策は、「このアクセスは何者で、どの程度正当そうなのか」を複数の手掛かりから評価する仕組みへ変わっている。

だから、「私はロボットではありません」が何を見ているのかという問いにも、完全な答えはありません。

IPアドレス、User-Agent、JA3・JA4、Cookie、サイト上のインタラクションなど、公式資料から分かることはかなりあります。

その一方で、Googleが使用する全シグナルや、それぞれをどの程度重視するのか、マウス軌跡などを現在どのように扱うのかは公開されていません。

公開情報だけでも、チェックボックスの裏側が想像以上に複雑であることは分かります。

けれど、すべてが分かるわけではない。

その「分からない部分」を勝手な雑学で埋めないことも、CAPTCHAというセキュリティ技術を正しく理解するうえでは大切です。