チャレンジを一度も出さない reCAPTCHA の代替

チームが乗り換えを考え始める理由

reCAPTCHA を置き換える理由が「ボットを止められないから」であることは、ほとんどありません。置き換えの理由は 3 つあり、どれも検知精度とは無関係です。

コンバージョン。対話的なチャレンジはすべて、実在の顧客の一定割合が離脱するファネルの一段です。決済や登録の画面では、その損失は測定可能で、しかも取り返しがつきません。離脱した人がパズルをやり直しに戻ってくることはないからです。

アクセシビリティ。画像グリッドや音声チャレンジは、視覚や運動に困難のある利用者にとって障壁です。そして「バスをすべて選べ」は、アメリカのスクールバスを見たことがない人を落とします。これは年々多くの法域でコンプライアンスの問題になっています。

データの流れ。reCAPTCHA は訪問者のシグナルを Google に送り、Google 自身の広告アイデンティティグラフと突き合わせます。欧州の事業者にとっては、評価すべき移転であり、指名すべき処理者であり、締結すべき DPA です。そして近年は、契約前に顧客から問われる項目でもあります。

スコアモデルが力尽きるところ

reCAPTCHA v3 は 0.0 から 1.0 のスコアを返し、判断は利用者に委ねます。柔軟に聞こえますが、実務では 2 つの問題を生みます。

スコアが不透明であること。どのシグナルがそれを生んだのかが見えないため、実在の顧客が 0.1 を取ったとき、調べるものも調整するものもありません。サポートには、答えようのないチケットが届きます。

しきい値は自分で当てずっぽうに決めるしかないこと。厳しくすれば顧客を弾き、緩くすればボットを通します。多くのチームはある数字で落ち着き、二度と見直しません。その数字が何を犠牲にしたのかを教えてくれるフィードバックの回路が存在しないからです。

そしてスコアが低いときに用意されている手当ては 1 つだけ、チャレンジを出すことです。取り除こうとしていたファネルの一段に、そのまま戻ってきます。

Karma のやり方はどう違うか

Karma はセッションだけでなくアドレスを採点し、チャレンジに退避することは決してありません。

シグナルは 2 つの層から来ます。行動：セッションが実際にページとどうやりとりしているか。トランスポート：JA3/JA3N の TLS フィンガープリントと HTTP/2 設定で、クライアントスタックを特定でき、user-agent 文字列よりはるかに偽装が困難です。

判定はあなたのゲートウェイへ渡り、ゲートウェイ自身が人間を通しボットを止めます。インタースティシャルもパズルも、ページ内のサードパーティ iframe もありません。

そして判断は説明可能です。パネルは判定ごとに、その根拠となったシグナルを表示します。異議の出たブロックは、受け入れるしかないものではなく、確かめられるものになります。

並べて比較

reCAPTCHA が実際に勝っている点も含めた、正直な比較です。

一斉切り替えの日を作らずに移行する

初日に選ぶ必要はありませんし、選ぶべきでもありません。

reCAPTCHA と並べて Karma のスニペットを入れ、遮断はオフのままにします。それが Detect プランで、費用はかかりません。1〜2 週間、両方のシステムが同じトラフィックを見ることになり、身元を実際に特定できるセッション——完了した注文、既知の優良顧客、すでに把握しているスクレイパー——の上で、判定と reCAPTCHA のスコアを突き合わせます。

判定が妥当に見えたら、ゲートウェイで遮断を有効にし、reCAPTCHA の呼び出しを外します。許可リストと拒否リストは常にプラットフォームより優先されるので、依存しているパートナーやクローラーは、何かを切り替える前に固定しておけます。