動画で読む
Turnstile は「指紋を出さないブラウザ」を弾き始めた
Cloudflare Turnstile（CAPTCHA の代わりに使われる bot 判定ウィジェット）が、WebGL から取れる端末の指紋情報を要求するようになった、という報告が出ています。先に結論を書くと、これは bot を弾く仕組みの代償として、フィンガープリント（端末を識別するための指紋情報）を拒否する一部ブラウザの人間まで一緒に締め出してしまう話です。そして自サイトに Turnstile を置いている運用者は、知らないうちに「誰を通し、誰を弾くか」を選んでいます。
私はこのサイトを Cloudflare の後ろで動かしていて、bot 対策のウィジェットは「置けば勝手に守ってくれる便利な箱」だと思っていました。今回の件を読んで、その箱が裏で何を読み取っているかを一度確認しないとまずい、と考え直しました。
何が起きたのか
きっかけは、2026 年 5 月 30 日に lanodan 氏が公開した WebKit-GTK で Turnstile が無限ループする報告です。氏の使う BadWolf という WebKit-GTK ベースのブラウザで、Turnstile のチェックが終わらず、複数のサイトにアクセスできなくなった、という内容でした。
調べると、Turnstile の互換性テストページで「WebGL renderer info is spoofed（WebGL のレンダラ情報が偽装されている）」と表示されていたそうです。WebKit はフィンガープリント対策として GPU 情報を隠すため、Turnstile から見ると「指紋を出さない＝怪しい」と判定される。Cloudflare 自身の説明も「フィンガープリントをブロックしたりランダム化したりするプライバシーツールは、ブラウザを bot のように見せてしまう」という趣旨でした。つまり仕様です。バグではありません。ここが厄介なところです。
WebGL フィンガープリントは何を読むのか
WebGL フィンガープリントが識別に強いのは、GPU の素性がそのまま出るからです。具体的には WebGL API 越しに GPU のベンダー名・レンダラ名・対応する拡張のリストなどを読み取り、それらを組み合わせると端末がかなり細かく特定できます。Cookie を消しても、この指紋は残ります。
ブラウザによって防御の度合いが違うことも、今回の締め出しの背景にあります。WebKit と Blink はこの種の情報をハードコードした固定文字列で返し、実態を隠します。対する Firefox は privacy.resistfingerprinting という設定を持っていますが、これは「厳格」プライバシーモードでも既定では有効になっていません。Mozilla の Bugzilla #1916271 では、Gecko が GPU の特性を（サニタイズ済みとはいえ）見せてしまう一方、WebKit/Blink は固定文字列を返す、という差が記録されています。
要するに、Safari と同じ WebKit エンジンでも、デスクトップ Linux 向けの WebKit-GTK は実質的に締め出され、Safari 本体は例外扱いされる。同じ「指紋を隠す」挙動が、ブラウザの出自によって通ったり弾かれたりするわけです。
運用者が払っているトレードオフ
Turnstile を置くという判断は、bot 防御とユーザの可用性・プライバシーを天秤にかける判断です。守りを固くするほど、指紋を出さない正規ユーザを巻き込む確率も上がります。今回あらためて言語化した軸を表にします。
| 観点 | Turnstile を置く | 置かない / 別手段 |
|---|---|---|
| bot 防御 | 強い。広範な signal で弾く | 自前のレート制限などで補う必要 |
| 巻き込み | 指紋を隠す正規ユーザを弾きうる | その層は通る |
| プライバシー | 端末指紋を第三者に渡す | 自分の管理下に留められる |
| EU データ要件 | Cloudflare 経由になる | 配置を選べる |
| 運用コスト | 置くだけで楽 | 実装と監視が要る |
どちらが正解という話ではありません。総当たり攻撃を受けているログインフォームなら、多少の巻き込みを覚悟してでも Turnstile の防御力を取る価値があります。逆に、ただの記事ページにまで広く掛けると、失うものの方が大きくなりがちです。
自サイトに入れているなら確認すること
まず確認すべきは「自分のサイトで Turnstile が誰をどれだけ弾いているか」です。導入したきり中身を見ていないと、巻き込みの規模に気づけません。今回チェックリストにしたのは次の点です。
- どのページに掛けているか。記事ページなど低リスクな場所まで広げていないか
- 失敗時のフォールバックがあるか。ループしたユーザに代替の連絡手段や別経路を残しているか
- managed / invisible モードの挙動。見えない設定に寄せすぎて、弾かれた人に何も表示されていないか
- ログで pass / fail 率を見ているか。特定ブラウザ群だけ fail が突出していないか
正直に言うと、私のサイトはこれまで 4 つ目をまともに見ていませんでした。「動いているから問題ない」は、弾かれた人が黙って去るタイプの問題には一番効かない油断です。
代替手段はあるのか
完全な代替はありませんが、指紋に依存しない方向の選択肢はあります。ただし銀の弾丸は無く、リスクに応じた組み合わせになります。
一つは Proof-of-Work 系のチャレンジです。mCaptcha や Friendly Captcha、Prosopo のように、端末の指紋ではなく計算コストを課して bot を割に合わなくする方式があります。指紋を取らない分プライバシーは穏当ですが、大規模な bot に対する防御力は指紋方式に劣る場面もあります。
もう一つは、そもそもクライアント側のチャレンジに頼りすぎないことです。サーバ側のレート制限、不審な振る舞いの検知、メール確認などを地道に組み合わせる。手間は増えますが、防御の主導権と利用ログを自分の手元に残せます。私が小規模なフォームで取っているのはこちらの方針です。理由は単純で、巻き込みで失う読者の方が、すり抜ける bot より痛いと判断したからです。
まとめ
Turnstile の WebGL フィンガープリント要求は、便利な bot 対策の裏側にある「誰を弾くか」という選択を、運用者の目の前に引き戻した一件です。持ち帰る点を整理します。
- これはバグではなく仕様。指紋を隠すブラウザは bot 扱いされうる
- 運用者は Turnstile を置いた時点で、防御力とユーザ巻き込み・プライバシーを天秤にかけている
- まず自サイトの適用範囲と fail 率を確認する。低リスクページへの広掛けは見直す
- 代替は PoW 系やサーバ側対策。銀の弾丸は無く、リスクに応じて組み合わせる
便利な箱ほど、中で何を読んでいるかを一度開けて確かめる価値があります。今回はそのいい口実になりました。
bot を弾く線は、いつも誰か人間の足元すれすれを通っている。
よくある質問
- Turnstile が一部ブラウザを弾くのはバグですか？
- いいえ、仕様です。Turnstile は WebGL から取れる端末の指紋を読み取って人間か判定するため、指紋を隠すブラウザ（WebKit-GTK など）は『指紋を出さない＝怪しい』と扱われます。Cloudflare 自身も、指紋をブロックするプライバシーツールは bot のように見えると説明しています。
- WebGL フィンガープリントは具体的に何を取得しますか？
- WebGL API 越しに GPU のベンダー名・レンダラ名・対応拡張のリストなどを読み取ります。これらを組み合わせると端末がかなり細かく特定でき、Cookie を消しても残るのが特徴です。WebKit や Blink は固定文字列を返して隠しますが、Firefox は既定では完全には隠しません。
- 自サイトに Turnstile を入れている場合、何を確認すべきですか？
- 適用ページの範囲（低リスクな記事ページまで広掛けしていないか）、失敗時のフォールバックの有無、invisible モードで弾かれた人に何も出ていないか、そして pass / fail 率のログです。特定ブラウザ群だけ fail が突出していないかを見ると巻き込みに気づけます。
- 指紋に依存しない代替手段はありますか？
- Proof-of-Work 系の mCaptcha・Friendly Captcha・Prosopo などは、指紋ではなく計算コストで bot を抑えます。加えてサーバ側のレート制限や不審検知、メール確認の組み合わせも有効です。ただし銀の弾丸は無く、リスクに応じた併用になります。