CAPTCHAとは？ わかりやすく10分で解説

CAPTCHAは、人間とボットを見分けることで、会員登録、ログイン、問い合わせフォーム送信、コメント投稿などで起こる自動化不正のハードルを上げる仕組みです。向いているのは、公開フォームへの大量送信や、短時間に同じ操作を繰り返す不正の抑止です。一方で、DDoS攻撃、盗まれた認証情報を使う不正、攻撃者が人手で解くケースまで、CAPTCHAだけで止め切れるわけではありません。

そのため、CAPTCHAは「これを置けば安心」という単独対策ではなく、必要な場所に最小限で配置し、WAF、ログイン試行の制御、多要素認証、リスクベース認証などと組み合わせて使うのが現実的です。ここでは、CAPTCHAの目的と仕組み、代表的な種類、導入時に起こりやすい失敗、そして「CAPTCHAだけでは守れない領域」まで整理します。

CAPTCHAとは

CAPTCHAは、"Completely Automated Public Turing test to tell Computers and Humans Apart" の略で、人間とコンピュータを区別するための仕組みです。歪んだ文字を読み取る、特定の物体を含む画像を選ぶ、チェックボックスをクリックするといった課題を使い、操作結果からボットを通しにくくします。

なお、近年は「ユーザーに明確な課題を解かせる」方式だけでなく、入力フォームの挙動やリクエストの特徴からリスクを推定し、必要な場合だけ追加の確認を出す方式も一般的です。これにより、ユーザーエクスペリエンスを大きく損なわずに、不正のハードルを上げやすくなります。

なぜCAPTCHAが使われるのか

インターネット上のサービスは基本的に人間の利用を想定していますが、現実にはボットがフォーム送信、アカウント作成、パスワード試行、スクレイピングなどを大量に実行し、サービス品質や運用コストを悪化させることがあります。CAPTCHAは、こうした「自動化の大量実行」に摩擦を加える対策として使われます。

CAPTCHAが向く場面と、不足しやすい場面

CAPTCHAは万能ではありません。効果が出やすい領域と、別の対策を主軸にした方がよい領域を切り分けて考える必要があります。

向いている場面

• 会員登録フォームの大量送信（スパムアカウント作成）
• コメント欄・問い合わせフォームのスパム投稿
• 予約・購入・抽選などの自動化による買い占め
• ブルートフォース攻撃のように、短時間に同じ操作を繰り返す試行の抑止
• スクレイピングへの摩擦付与

不足しやすい場面

• DDoS攻撃のように、帯域やサーバー資源の枯渇を狙う攻撃
• クレデンシャルスタッフィングのように、盗まれた正規認証情報を使う不正
• 攻撃者が人手で解答を通すケース
• セッション乗っ取りや盗難済みトークンの悪用

要するに、CAPTCHAは「入口での自動化を通しにくくする」対策であって、認証そのものを強化したり、あらゆる攻撃を止めたりする仕組みではありません。

CAPTCHAの種類と特徴

CAPTCHAには複数の方式があり、通しにくさだけでなく、使いやすさやアクセシビリティにも差が出ます。サイトの目的と利用者層に合わせて選ぶ必要があります。

歪んだ文字を読むタイプ

画面上に表示された歪んだ文字や数字を入力させる方式です。ノイズや歪みで自動読取を難しくする狙いがありますが、ユーザー側も読み取りづらく、入力ミスによる離脱が起きやすいのが弱点です。

画像認識を利用したタイプ

複数の画像から「信号機のある画像を選ぶ」「横断歩道を選ぶ」といった課題を出す方式です。直感的に使いやすい反面、スマートフォンでは選択しづらいことがあり、視覚に依存しやすいためアクセシビリティの設計が欠かせません。

チェックボックス型・リスク判定型

「私はロボットではありません」といったチェックボックスを使い、必要に応じて追加の確認を出す方式です。ユーザーの負担を抑えやすく、一般向けサイトで採用しやすい形式です。

パズル・ドラッグ操作などのユニーク型

パズルのピースを合わせる、スライダーを動かすといった操作を求める方式です。視覚的には分かりやすい一方、端末環境や身体的条件によって操作しづらくなる場合があるため、代替手段まで含めて設計した方が安全です。

導入時に起こりやすい失敗

CAPTCHAは設置しただけで終わりではありません。置き方や出し方を誤ると、不正対策のつもりが離脱要因になります。

常時表示で摩擦を増やしすぎる

すべてのユーザーに毎回CAPTCHAを解かせると、正規利用者の負担が増えます。とくにログインや購入導線では、失敗率がそのまま離脱率に跳ねやすくなります。短時間の連続送信やログイン失敗回数など、リスクが高まった場面だけに出す方が運用しやすい設計です。

方式の選定が利用者に合っていない

文字が読みづらい、画像が細かすぎる、スマホで操作しにくい、といった設計は入力失敗を増やします。対象ユーザーがスマホ中心なのか、一般消費者向けなのか、業務システム利用者なのかで、向く方式は変わります。

アクセシビリティの配慮が足りない

視覚に依存するCAPTCHAは、視覚障害のあるユーザーにとって使いにくい場合があります。音声など別の感覚に基づく代替手段を用意するだけでなく、そもそもCAPTCHAに頼りすぎない構成にしておくことが重要です。

誤判定を観測していない

CAPTCHAは、正規ユーザーを誤って弾くことがあります。失敗率、離脱率、問い合わせ内容、スパム減少の傾向を見ずに放置すると、対策が効いているのか、売上や登録率を落としているのか判断できません。導入後は数値で見直せる状態を作るべきです。

CAPTCHAだけでは守れない領域

CAPTCHAの限界は、攻撃の種類によっては「入口の摩擦」だけでは足りないことです。ここを誤解すると、導入しているのに被害が続く状態になります。

ログイン保護

ログイン画面では、ブルートフォース攻撃だけでなく、クレデンシャルスタッフィングやパスワードリスト攻撃のように、正しいID・パスワードの組み合わせを試す不正も問題になります。ここではCAPTCHAだけに頼らず、試行回数の制御、多要素認証、異常検知、段階的な追加認証まで含めて考える必要があります。

大規模なトラフィック攻撃

DDoS攻撃のように、通信量や接続数でサービスを圧迫する攻撃では、CAPTCHAが主役にはなりません。こうした領域では、CDN、WAF、レート制御、トラフィック分散など、別の仕組みを中心に据える必要があります。

正規ユーザーを装う不正

盗まれたセッションや有効な認証情報を使う不正では、「人間かボットか」より、「その利用が正当かどうか」の判断が重要になります。この領域では、端末情報、アクセス元、失敗傾向、操作の不自然さなどを踏まえたリスク判定が必要です。

CAPTCHAを含めた実用的な設計

現実の対策は、CAPTCHA単体ではなく、多層防御として組み合わせるのが基本です。たとえば、次のように役割を分けると整理しやすくなります。

• CAPTCHA：公開フォームや特定操作での自動化を通しにくくする
• レート制御：短時間の連続試行を抑える
• WAF：明らかに不自然なリクエストや既知の攻撃パターンを遮断する
• 多要素認証：ログイン後の不正利用を通しにくくする
• リスクベース認証：怪しいときだけ確認を強める

設置の基本は「必要な場所にだけ置く」ことです。会員登録、ログイン、問い合わせ、コメント投稿、予約・購入導線など、不正が起きている場所を特定し、そこに最小限の摩擦をかけます。常時表示より、リスクが高い場面だけ強める方が、使いやすさと防御の両立につながります。

まとめ

CAPTCHAは、人間とボットを区別し、フォーム送信やログインなどで起こる自動化不正のハードルを上げるための仕組みです。とくに、公開フォームへの大量送信や、短時間に同じ操作を繰り返す不正には向いています。

一方で、CAPTCHAだけでは、DDoS、盗まれた認証情報の悪用、正規セッションの不正利用まで止め切れません。実運用では、必要な場所に最小限で配置し、WAF、試行回数の制御、多要素認証、リスク判定と組み合わせて設計することが重要です。