reCAPTCHAの代替を探す場合、選択肢は大きく4つのアプローチに分けられます。どれが最適かは「何を防ぎたいか」と「どのトレードオフを許容できるか」によって変わります。また、どの技術的対策を採用しても人間が手動で送ってくる迷惑フォームは防げないため、技術的な対策と送信内容の判定を組み合わせることが現実的な終着点です。
reCAPTCHAから乗り換えを検討する典型的な理由
reCAPTCHAは長年のデファクトスタンダードですが、現場では次のような課題が挙がることがあります。
UX面
- 画像選択の問題が繰り返し表示され、フォームからの離脱につながりやすい
- モバイルデバイスでの操作が特に煩わしいと感じるユーザーが多い
プライバシー面
- reCAPTCHA v2・v3はGoogleのスクリプトをページ上で実行するため、訪問者の行動データがGoogleに送られる
- GDPRやプライバシーポリシーとの整合を気にするサイト運営者が増えている
技術・運用面
- v3はスコアを返すだけなので、どのしきい値で拒否するかを自社で継続的に調整する必要がある
- Enterpriseプランへの移行が促されるケース、または無料枠の条件変更への懸念
これらの課題の背景についてはreCAPTCHAの限界と問題点で詳しく整理しています。
代替アプローチの4分類と守備範囲
代替手段は「何を防ぐか」によって大きく4種類に分けられます。それぞれの守備範囲と特性を理解してから選ぶと、導入後のミスマッチが少なくなります。
1. 別のCAPTCHAサービスに切り替える
hCaptcha・Cloudflare Turnstile・FriendlyCaptchaなど、reCAPTCHA以外のCAPTCHAサービスが複数存在します。
| 観点 | 概要 |
|---|---|
| 守備範囲 | 自動送信botを弾く点はreCAPTCHAと同等 |
| UX | サービスによって異なる。非表示チェックが基本のサービスはユーザー操作が不要なケースが多い |
| プライバシー | Googleへのデータ送信は避けられるが、各サービス独自のデータポリシーを確認する必要がある |
| 導入コスト | 無料枠があるサービスが多いが、上限やライセンス条件はサービスごとに異なる |
向いている場面: 既存のCAPTCHA実装パターンを大きく変えずに、Googleへの依存だけを解消したい場合。
2. ハニーポット
ハニーポットは、人間には見えない隠しフィールドをフォームに仕込む手法です。botはCSSで非表示になっているフィールドを認識せずに自動入力するため、そのフィールドが埋まっていれば「bot送信」と判定して弾くことができます。
| 観点 | 概要 |
|---|---|
| 守備範囲 | フォームフィールドを機械的にすべて埋める単純なbotに有効 |
| UX | ユーザーには完全に不可視で、離脱率への影響はほぼゼロ |
| プライバシー | 外部スクリプト不要。訪問者データを第三者に送らない |
| 限界 | ハニーポットの存在を認識した高度なbotには通用しない |
向いている場面: プライバシーを重視したい、ユーザー操作を一切増やしたくない、シンプルな自動送信botを防げれば十分な場合。
ハニーポットの実装詳細や他のbot対策との組み合わせについてはハニーポットでフォームのbot対策をする方法で解説しています。
3. 挙動分析（JavaScriptベース）
フォームへの入力速度・マウスの動き・タイプのリズムなどをJavaScriptで記録し、「人間らしい操作かどうか」をスコアリングするアプローチです。reCAPTCHA v3も広義ではこのカテゴリに含まれます。
| 観点 | 概要 |
|---|---|
| 守備範囲 | ヘッドレスブラウザや人間の挙動を模倣しないbotに有効 |
| UX | ユーザー操作が不要な場合が多い（非表示で動作） |
| プライバシー | 挙動データをどのサーバーに送るかはサービスによる |
| 調整コスト | しきい値の設定によって誤検知率が変わるため継続的なチューニングが必要 |
向いている場面: CAPTCHAの見た目は使いたくないが、ある程度の精度でbotを検知したい場合。「Googleを経由しないこと」が最優先事項の場合。
4. 送信内容をAI・フィルタリングで判定する
送信が届いた後、内容そのものを評価するアプローチです。技術的なbot対策とは異なり、「メールアドレスの形式が疑わしい」「本文が営業テンプレートに見える」「意味のない文字列が含まれている」といった観点から迷惑送信かどうかを判定します。
| 観点 | 概要 |
|---|---|
| 守備範囲 | botかどうかに関わらず、迷惑な内容を後段でフィルタリングできる |
| UX | 送信者には一切影響なし |
| プライバシー | 送信内容をどのシステムに渡すかによって変わる |
| 限界 | 技術的なbot送信の「量」自体は減らない |
このアプローチは「botを玄関で弾く」のではなく「届いた郵便物を仕分ける」イメージです。技術的対策と並行して使うことで、どちらか片方では対処できない迷惑送信をカバーできます。AIによる問い合わせの仕分けの実務についてはAI問い合わせ自動振り分けの仕組みと精度も参考になります。
どれを選んでも「人力送信」は残る
ここで押さえておきたい重要な前提があります。技術的なbot対策はすべて「自動化された送信」への対策です。人間が手動でフォームを開き、フィールドを埋めて送ってくる迷惑メッセージ（営業メール、スパム、嫌がらせ）は、どのbot対策を採用しても原理的には防げません。
人力送信への対策としてよく使われる手段:
- ダブルオプトイン（確認メール要求）: アドレスの実在確認になるが、確認ステップ自体が正規ユーザーの離脱を生む
- 送信後の確認ステップ: 一定のハードルにはなるが、手間をかけた送信者には通用しない
- 内容フィルタリング: キーワードマッチや機械学習で迷惑送信を自動分類する
フォームへの迷惑送信対策の全体像については問い合わせフォームのスパム対策ガイドで詳しく取り上げています。
実務的な組み合わせの考え方
対策の全体像は「入口で弾く層」と「届いた後に仕分ける層」の2段階で整理できます。
入口で弾く層（技術的bot対策）
- ハニーポット＋送信速度チェックを最低限として置く（外部スクリプト不要でUX影響ゼロ）
- さらに精度を上げたい場合はCAPTCHAまたは挙動分析を追加する
届いた後に仕分ける層（内容判定）
- キーワードフィルタ・スコアリング・AIによる分類などを組み合わせる
- 人力送信への対応はここで初めて効いてくる
たとえば、ハニーポットと送信速度チェックで自動botを入口で弾きつつ、届いた問い合わせをAIで「重要・通常・スパム」に分類するという2段構えのアプローチは、UXを損なわずに迷惑送信を実務的に管理できる着地点として検討する価値があります。
どちらか一方だけを強化しても、もう一方の穴は残ります。とくにビジネス用途のフォームでは「重要な問い合わせを見落とさないこと」も同じくらい大切です。入口の対策を厳しくしすぎることで正規ユーザーを弾いてしまわないよう、誤検知率にも目を向けることをおすすめします。
まとめ
reCAPTCHAの代替を検討するときに押さえておきたいポイントを整理します。
| アプローチ | 主なメリット | 主な限界 |
|---|---|---|
| 別のCAPTCHAサービス | 実装パターンを変えずにGoogle依存を解消できる | UXへの影響はサービスによって異なる |
| ハニーポット | UX影響ゼロ・外部依存なし | 高度なbotには通用しない |
| 挙動分析 | 操作不要でbot検知できる | しきい値のチューニングコストがかかる |
| 内容判定（AI・フィルタ） | 人力送信にも対処できる唯一の手段 | bot送信の量自体は減らない |
最終的には「入口でのbot対策」と「届いた後の内容判定」の2段構えを意識することが、フォームスパムを実務的に減らしていく近道です。どの技術も単独では万能ではないため、守備範囲の異なる手段を重ねることがポイントになります。