CAPTCHAは、問い合わせフォームの迷惑送信、ログイン画面への総当たり、アカウントの大量作成などを抑えるために使われます。
人間とボットを見分け、正当な利用だけを通すことを目的として利用されます。
GoogleのreCAPTCHA、CloudflareのTurnstileなどが有名ですね。
ただし、判定を厳しくすると、正当な利用者まで拒むおそれがあります。画像や音声を判別しにくい人もいます。細かな操作ができない人や、理由の分からない再試行を求められて利用を諦める人もいます。
また、CAPTCHAの導入効果は、通過率や拒否件数だけでは判断できません。攻撃をどれだけ抑えたかに加え、正当な利用者が送信を完了できたか、失敗後に復帰できたかまで確認する必要があります。
そこで、この記事では、正当な利用者への負担を含め、導入効果を判断するための見方と運用方法をまとめていきます。
CAPTCHAの方式によって利用者の負担は変わる
CAPTCHAは、人間には比較的容易で、機械には難しいと考えられる課題や判定を使い、人間とボットを区別する仕組みです。フォーム、ログイン、会員登録、コメント、購入など、守る対象によって使われ方は異なります。
利用者に見える動作を基準にすると、代表的な方式は次のように分けられます。
| 方式 | 利用者が行うこと | 起こり得る負担 |
|---|---|---|
| 文字入力型 | ゆがんだ文字や数字を読み取って入力する | 視覚、認知、言語、キーボード入力に関する負担 |
| 画像選択型 | 指定された物が写る画像を選ぶ | 視覚認識、画像の文化的な解釈、細かなポインター操作に関する負担 |
| 音声型 | 雑音を含む音声を聞き、内容を入力する | 聴覚、聴覚情報の処理、再生操作、言語に関する負担 |
| パズル・移動型 | スライダーや図形を動かす | 上肢や手指の操作、ドラッグ、画面拡大、キーボード操作に関する負担 |
| 行動・リスク判定型 | 通常は課題を解かず、判定時だけ追加確認を受ける | 判定理由が見えにくく、誤判定時の回復方法も分かりにくい |
利用者へ課題を見せない方式は、操作上の負担を減らせます。その一方で、判定に使う情報、誤判定時の処理、外部事業者へのデータ送信を確認しなければなりません。課題が画面に出なくても、利用者への影響がなくなるわけではありません。
突破を難しくすると、”本当の人間”の成功率も下がる
画像認識や音声認識が進歩すると、CAPTCHAの提供事業者や導入担当者は、文字のゆがみを強め、背景音を増やし、画像の判断を複雑にする対策を取りがちです。しかし、その変更は人間にとっての難度も上げます。
W3Cの2019年作業草案は、文字のゆがみを強めるほど、十分な視力や認知能力がある人でも安定して解くことが難しくなると指摘しています。この資料は作業草案であり、W3C勧告ではありません。それでも、セキュリティのための難化が人間の利用を妨げる問題を考える資料になります。
攻撃者は、画像認識だけを使うとは限りません。人手による解答代行や、別の回避手段も利用できます。正当な利用者へ難しい課題を出しても、それだけで攻撃を止められるとは限りません。
無事成功した人だけを見ていると、後ろにある誤検知に気づけない
USENIX Security 2023で発表された研究では、Amazon Mechanical Turkで募集した1,400人が、合計14,000件のCAPTCHAを解きました。方式によって解答時間に大きな差がありました。また、短時間で解ける方式が、必ずしも好まれるとは限らないという結果も報告されています。
同研究は、CAPTCHAだけを解く場面と、アカウント作成の途中で解く場面も比較しました。追加の離脱実験では、開始した574人のうち174人が完了前に離脱しています。
これは、報酬を設定したオンライン実験の結果です。一般の問い合わせフォームへ、そのまま「離脱率30%」として当てはめることはできません。ただし、完了者だけの解答時間や正答率を見ていると、途中で諦めた人が評価から抜け落ちることは分かります。
アクセシビリティの観点が重要、ただし音声版の有無以外にも押さえるべき事はある
CAPTCHAのアクセシビリティを「音声版があるか」だけで判断すると、別の障壁を見落とします。利用者の状況によって、利用できなくなる理由は異なります。
| 利用者の状況 | 起こり得る問題 | 確認したい代替・実装 |
|---|---|---|
| 全盲、弱視、色覚に関する特性 | 文字や画像を認識できない。拡大すると画像全体を見渡せない | 視覚だけに依存しない手段、支援技術で目的と操作を把握できる説明 |
| ろう、難聴、聴覚情報の処理に関する特性 | 音声版を聞き取れない。背景音と答えを分離できない | 音声だけに依存しない手段、再生以外の回復方法 |
| 認知、学習、読字、言語に関する特性 | ゆがんだ文字、曖昧な指示、論理問題、制限時間を理解しにくい | 短く具体的な説明、時間切れへの配慮、別形式の手段 |
| 上肢や手指の動作に関する特性 | 小さな画像の選択やドラッグを正確に行えない | キーボードを含む複数の入力方法、十分な操作対象の大きさ |
| 不安、疲労、反復操作の負担が大きい状態 | 失敗理由が不明なまま課題が増え、完了を諦める | 失敗理由と次の行動、入力内容の保持、有人対応を含む代替経路 |
現行のW3C勧告であるWCAG 2.2の達成基準1.1.1は、非テキストのCAPTCHAについて、目的を識別・説明するテキストと、異なる感覚に対応する代替形式を求めています。
ただし、画像版に音声版を加えれば、すべての人が利用できるとは限りません。盲ろう者、音声を処理しにくい人、音を出せない環境にいる人には、画像と音声のどちらも障壁になる場合があります。
WCAGへの適合と、特定の法令や契約への適合は別の判断です。法的な確認が必要な事業者は、対象となる管轄、適用資料、資料の日付を特定し、専門家へ確認します。ここで扱う内容は、2026年8月10日時点の公開資料に基づく一般情報です。
ここでも、誤判定の問題は当然ある
行動やリスクをもとにする方式は、多くの利用者から画像選択などの課題を取り除きます。しかし、判定の曖昧さまでなくなるわけではありません。
W3Cの2019年作業草案は、プライベートブラウズやCookieの消去・拒否などが、追加の課題を出す要因になり得ると述べています。実際に使う信号や判定の閾値は、サービスや設定によって異なります。
運用担当者は、低いリスクスコアや拒否件数だけでは誤判定を判別できません。送信内容、利用者からの申告、再試行後の結果なども確認します。その際、利用者の障害を推測して記録するのではなく、どの段階で何が起きたかを必要最小限のデータで確かめます。
フォーム改善の観点では、CAPTCHA以外にも様々な要素がある
CAPTCHAの管理画面に表示される通過率だけでは、フォームへの影響を判断できません。フォームへ到達した人、入力を始めた人、CAPTCHAを表示された人、再試行した人、送信を完了した人を一連の流れとしてチェックしていきましょう。
見るべき指標は、担当する役割によって異なります。
| 立場 | 主に知りたいこと | 指標の例 |
|---|---|---|
| セキュリティ担当者 | 自動送信や攻撃を抑えられたか。正当な利用者を巻き込んでいないか | 不審な試行数、制限数、課題の通過・失敗・再試行、保留後の判定 |
| マーケティング担当者 | 問い合わせや登録を完了できたか。どこで離れたか | フォーム到達、入力開始、CAPTCHA表示、送信試行、送信完了、代替経路の利用 |
| 利用者 | 目的と無関係な課題を避け、失敗しても復帰できるか | 完了までの時間、入力内容の消失、エラーの理解、代替手段の利用可否 |
一つの運用表で三者の指標を確認すると、攻撃抑止とフォーム完了のどちらか一方だけを改善したつもりになる事態を避けやすくなります。
フォーム離脱の原因を切り分ける
フォーム送信をためらう理由は、CAPTCHAだけではありません。当社がフォーム改善で確認してきた問題には、入力項目の多さやスマートフォンでの使いにくさに加え、問い合わせ前の不安も含まれます。
利用者は、「この内容で相談してよいか」「返信はいつ来るか」「強い営業を受けないか」「個人情報を送ってよいか」「誰が対応するか」を気にします。ここへCAPTCHAが加わると、「なぜ疑われたのか」「失敗しても入力は残るか」「別の連絡方法はあるか」も判断しなければなりません。
CAPTCHAが離脱のきっかけになった可能性はあります。ただし、送信完了数だけでは単独の原因と断定できません。観測した状態に応じて、次の項目を確認します。
| 観測した状態 | CAPTCHA以外に確認すること | CAPTCHAについて確認すること |
|---|---|---|
| フォーム到達後に入力されない | 項目数、相談できる内容、返信目安、担当者や個人情報への不安 | CAPTCHAが入力前から表示されるか、目的の説明があるか |
| 送信を試したのに完了しない | 必須項目のエラー、通信エラー、入力内容の消失、送信後の案内 | 初回失敗、期限切れ、再試行、判定不能時の動作 |
| 電話やメールの利用が増えた | 連絡手段の案内変更、営業時間、利用者の希望 | フォームでの拒否や支援依頼が同じ時期に増えていないか |
フォーム到達数と送信完了数の差が広がった場合、入力項目だけを直しても原因を除けないことがあります。運用担当者は、CAPTCHAの表示、エラー、期限切れ、再読込による入力消失、送信後の案内も確認します。
変更履歴を残し、原因を追えるようにする
CAPTCHAの導入と同時に、必須項目の削減、返信目安の追記、ボタンの変更まで行うと、完了率の変化をどの変更と結び付けるべきか分からなくなります。
一度に一つずつ変更できない場合もあります。その場合、運用担当者は変更日時、対象ページ、設定、変更理由、確認する指標を分けて記録します。
導入前には、フォーム到達数と送信完了数を基準として残します。導入後は、CAPTCHAの表示、初回失敗、再試行、送信完了、代替経路、支援依頼を同じ期間で確認します。数値が動かなかった場合も、計測漏れと利用者への影響が小さかった場合を区別できる状態にしておきます。
代替経路を用意しただけで終わらせない
電話やメールなどの代替経路は、CAPTCHAで止まった利用者の助けになります。ただし、設置しただけでは十分ではありません。運用担当者は、次の条件を確認します。
- CAPTCHAと同じ判定で、代替経路まで遮断していない
- エラー画面から、代替経路の場所と利用方法が分かる
- 電話だけ、音声だけなど、一つの感覚や操作方法へ限定していない
- 追加料金や著しい待ち時間など、利用者へ不利な条件を付けていない
- 送信前に入力した内容を、必要な範囲で保持できる
- 不審な送信を即時削除せず、必要に応じて人が確認できる
代替経路の利用が急に増えた場合は、「別の窓口が好まれるようになった」と決めつけないでください。通常のフォームで拒否や障害が起きていないかを調べます。
CAPTCHAだけにセキュリティ対策を頼り過ぎない
CAPTCHAへ多くを任せるほど、利用者へ難しい課題を出しやすくなります。攻撃を抑えるには、入口の判定以外の対策も組み合わせる必要があります。
当社が2016年に公開したWordPressサイトの侵害対応記録では、復旧後の対策の一つとしてCAPTCHAを導入しました。ただし、CAPTCHAだけで対応を終えてはいません。この記録は、現在の製品選定や復旧手順を示すものではありませんが、入口の判定だけに依存しない考え方は現在も参考になります。
当時は、CAPTCHAに加えて次の対策を行いました。現在も継続して確認すべき内容を含みます。
- ログイン失敗が続いた場合の制限
- 不要な管理者アカウントの無効化と権限の見直し
- WordPress本体、テーマ、プラグインの早期更新
- 異常を知らせるアラートと、変化を見つけるための監視
- バックアップと、クリーンな状態へ戻す復旧手順
CAPTCHAが主に抑止できるのは、人間向けの入口をボットが繰り返し使う攻撃です。奪われた権限、未修正の脆弱性、改ざんされたファイル、不正に追加されたアカウントまでは直せません。入口の判定、権限、更新、監視、復旧を分けて考えます。
問い合わせフォームでも同じです。送信頻度の制限、入力内容の検査、疑わしい送信の保留、サーバー側の検証を組み合わせれば、すべての利用者へ最も難しい課題を出さずに済む可能性があります。
導入後にチェックする項目と見直し条件
導入時に正常に動いていても、攻撃手法、ブラウザー、支援技術、外部サービス、サイト側の実装は変わります。次の項目を同じ期間で追い、変化が出たら設定とフォーム全体を見直します。
| 監視項目 | 見直しを始める変化 | 主な確認先 |
|---|---|---|
| CAPTCHAの表示率 | 通常時より急に増えた | 設定変更、流入元、端末・ブラウザー別の偏り、攻撃の有無 |
| 初回失敗率と再試行率 | 特定の方式や環境で上昇した | 課題の難度、表示崩れ、操作方法、説明文 |
| フォーム到達から送信完了までの割合 | CAPTCHA導入・更新後に低下した | CAPTCHA前後のイベント、入力消失、エラー、期限切れ |
| 不審な送信の通過数 | 完了率を保っても迷惑送信が増えた | 頻度制限、サーバー側検証、保留・監視との組み合わせ |
| 問い合わせ・支援依頼 | 「先へ進めない」「何度も出る」という申告が出た | 実際の端末、キーボード操作、支援技術、代替経路 |
| 代替経路の利用 | 電話やメールだけが急増した | フォーム障害、説明不足、判定の偏り |
| 変更履歴 | 数値が変わったが、変更との前後関係が分からない | CAPTCHAの設定、フォーム項目、説明、導線を変えた日時 |
運用担当者は、見直しの基準を他社の平均ではなく、自社の平常時と利用目的に合わせます。プラグインや判定設定を変えた日も記録します。個人情報や問い合わせ本文を必要以上にログへ残さず、保持期間と閲覧権限も定めます。
見直す際は、最初から課題を難しくしないことも重要です。表示対象を絞る、頻度制限を調整する、疑わしい送信を保留する、判定不能時の回復方法を変えるなど、利用者へ課す試験以外の手段も比較します。
まとめ
CAPTCHAは、フォームやログインをボットから守る一つの手段です。しかし、機械に難しい課題は、人間にとっても難しくなる場合があります。見えないリスク判定へ移っても、誤判定と回復の問題は残ります。
運用担当者は、導入後に攻撃の抑止だけでなく、フォーム到達から送信完了までの流れ、再試行、入力内容の消失、代替経路、利用者からの申告を確認します。CAPTCHAを権限管理、更新、頻度制限、監視、復旧と組み合わせることも必要です。
正当な利用者へ不要な課題を出していないかを継続して確かめることが、セキュリティと利用しやすさを両立させる出発点です。
参考資料
- W3C, “Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web,” Working Draft, 14 February 2019
https://www.w3.org/TR/2019/WD-turingtest-20190214/ - W3C, “Web Content Accessibility Guidelines (WCAG) 2.2,” W3C Recommendation, 12 December 2024
https://www.w3.org/TR/WCAG22/ - Andrew Searles et al., “An Empirical Study & Evaluation of Modern CAPTCHAs,” 32nd USENIX Security Symposium, 2023
https://www.usenix.org/conference/usenixsecurity23/presentation/searles
