reCAPTCHA v3とは？導入手順やメリットを詳しく解説
<この記事でわかること>
- reCAPTCHA v3は、チェックや画像選択などの認証を出さずに、ユーザーの行動から「不正の可能性」を0.0〜1.0のスコアで判定する仕組み
- v2は目に見える認証で強く止められるが、ユーザーが面倒に感じて離脱しやすい。v3は離脱を増やしにくい一方で、「何点以下を危険とするか」など運用設計が重要
- v3の強みは、スコアに応じて「通常処理」「保留」「追加確認」「制限」など、段階的に対策を切り替えられること
- 導入は「サイト登録→キー発行→トークン取得→検証APIでチェック→スコアで判定→処理を分岐」という流れで行う。導入後はログを見ながら調整するのが安全
- 誤検知で正規ユーザーを落とすリスクがあるため、最初は遮断せずスコア監視から始めることが大切。また、トークン期限切れ防止や、バッジ非表示時の表示義務も押さえる必要がある
フォームのスパム対策は重要ですが、画像選択などの認証が入るとユーザーの負担になり、途中で離脱される原因にもなります。このような課題を解決するのが、ユーザーに認証作業をさせず、裏側で不正アクセスを判定できる「reCAPTCHA v3」の導入です。
本記事では、reCAPTCHA v3の仕組みやv2との違い、具体的な導入手順をわかりやすく解説します。さらに、スコア判定を使った柔軟なスパム対策の考え方や、誤検知を防ぐための運用ポイントも紹介します。
<目次>
reCAPTCHA v3とは？
reCAPTCHA v3は、ユーザーにチェックや画像選択などの認証をさせずに、不正アクセスを防ぐ仕組みです。サイトを利用しているときの行動をもとに、「人間らしさ」をスコアで判定します。
フォーム送信やログインなど、守りたい操作ごとに判定できるため、不正送信を減らしつつ、必要に応じて追加の対策も行えます。ここでは、reCAPTCHA v3の基本的な仕組みと考え方を解説します。
reCAPTCHA v3の仕組み
reCAPTCHA v3は、ページにJavaScriptを読み込ませて利用します。ユーザーがフォーム送信などの操作をしたタイミングで「トークン」を発行し、それをサーバへ送ります。
サーバ側では検証APIにトークンを送信し、次の情報を受け取ります。
- そのトークンが自社サイト用に発行されたものか
- スコアはいくつか
- どの操作（action）に対する判定か
特長は判定結果が「OK／NG」ではなく、0.0〜1.0のスコアで返ってくることです。スコアをもとに送信を許可するか、追加認証を入れるかなどを自社で決めて運用します。
reCAPTCHA v2との違い
reCAPTCHA v2は、「私はロボットではありません」というチェックや、「信号機の画像を選んでください」といった画像選択をユーザーに求めます。これらは不正を止める効果が高い反面、ユーザーにとっては「思考の中断」を強いる大きなストレスになり、コンバージョン直前での離脱を招く大きな要因となります。
一方、reCAPTCHA v3は認証操作が表示されず、裏側でスコア判定を行います。そのため、ユーザーの負担を増やさずに対策できるのが大きな特長です。ただしv3は、スコアの基準をどう設定するか、低スコアの場合にどう対応するかを設計しないと、正規ユーザーを誤って弾いてしまう可能性があります。
reCAPTCHA v3導入のメリット
reCAPTCHA v3の大きな特長は、ユーザーに認証操作をさせずに不正対策ができる点です。さらに、スコア情報をもとに柔軟な対策を設計できるため、単にスパムをブロックするだけでなく運用改善にもいかせます。
ここでは、reCAPTCHA v3を導入することで得られる具体的なメリットを解説します。
ユーザーの操作を邪魔せずコンバージョン低下を防げる
reCAPTCHA v3は、フォーム送信直前に画像選択などの認証が表示されないため、途中で離脱されるリスクを減らせます。特にBtoBサイトでは、問い合わせ完了までの流れが少しでも複雑になると、コンバージョンに大きく影響することがあります。そのため、セキュリティ対策を強化しながらも、成果を落としにくい設計が可能です。
また、v2のように認証画面が表示されると、「怪しい利用者だと思われたのでは」と感じるユーザーもいます。v3ならこうした心理的な違和感が起こりにくく、ブランド体験を損なわずに対策を行えます。
スコア判定による段階的な不正対策ができる
reCAPTCHA v3は、判定結果が0.0〜1.0のスコアで返ってきます。そのため「通すか止めるか」の二択ではなく、状況に応じて段階的に対応できます。
たとえば、次のような運用が可能です。
- 0.7以上は通常に処理する
- 0.3〜0.7は送信は受けるが内容を確認対象にする
- 0.3未満は追加認証や送信制限をかける
このように対策を細かく調整できるため、スパム被害を抑えつつ、正規ユーザーの取りこぼしも減らせます。さらに、操作ごとのスコア傾向を分析すれば、どの導線が狙われやすいか把握する材料にもなります。
低スコア時の対応を柔軟に設計できる
reCAPTCHA v3は、スコア判定の結果をもとに「次に何をするか」を自社で決められます。低スコアだからといって即遮断するのではなく、メール認証やSMS認証、簡単な追加質問、送信頻度制限など、ビジネスに合った救済策を選べます。
特にBtoBの問い合わせでは、不正送信が混ざる一方で、重要な問い合わせを逃すリスクもあります。そのため、単純に止めるよりも、段階的に分岐させる設計のほうが現実的です。運用の自由度が高い分、成果とセキュリティのバランスを取りやすい点がメリットです。
自社サイトに合わせて精度が向上する
reCAPTCHA v3は、サイト上のユーザー行動をもとにリスクを判定する仕組みです。そのため、トラフィックが蓄積するほどスコア判定が安定しやすい傾向があります。導入直後やテスト環境ではスコア分布が本番と異なる場合があるため、最初から厳しく遮断するのではなく、まずはスコアを観測して基準を作ることが重要です。
また、フォームの種類や導線、ユーザー属性によって「正常なスコアの相場」は変わります。自社サイトの状況に合わせて調整できること自体が大きな価値であり、運用を続けるほど精度を高めていける対策だといえます。
これからCRM活用をはじめる人にみてほしいCRM・顧客管理資料3点セット
「CRM導入の失敗あるある7選」や「SFAとCRMの違い」「顧客管理レベルチェックシート」3つの資料がセットでダウンロードできます。
reCAPTCHA v3の導入手順
reCAPTCHA v3は、「キーを取得する→サイトに組み込む→動作を確認する」という流れで導入します。さらに、環境ごとの設定やaction・hostnameの確認、スコアの基準となる閾値（しきいち：判定の基準値）まで決めておくと、より安全に運用できます。ここでは導入手順を解説します。
Google reCAPTCHAにサイトを登録する
まず行うのは、キーの発行です。管理画面でサイトを登録すると、フロント側で使う「サイトキー」と、サーバ側で検証に使う「シークレット（秘密鍵）」が発行されます。基本の流れは次のとおりです。
- 管理コンソールで新規キーを作成し、タイプはv3（スコアベース）を選ぶ
- 利用するドメインを登録する
- 発行されたサイトキー／シークレットを控え、シークレットはサーバ側の安全な場所に保管する
キーはドメインに紐付く仕組みのため、登録していないドメインで使うとエラーになります。また、検証時にはhostname（ドメイン）やactionも確認し、想定外の流用や不正な送信を防げるようにしておくと安心です。
Webサイトへ実装する
キーを取得したら、次はサイト側に組み込みます。フロント側でトークンを発行し、サーバ側で検証してスコアを受け取り、結果に応じて処理を分岐させます。CMSを使うか、自前で実装するかによって手順が変わります。
WordPressの場合（Contact Form 7など）
WordPressでは、プラグイン側にreCAPTCHA連携機能が用意されていることが多く、手作業の実装を最小限にできます。
たとえばContact Form 7の場合は、管理画面の「お問い合わせ」→「インテグレーション」からreCAPTCHA設定画面を開き、サイトキーとシークレットを登録します。あとはフォーム送信時に自動でトークン発行と検証が行われ、判定結果に応じた処理ができます。
注意点として、サイト全体で同じキーを使う設計になるケースがあるため、本番とステージングを分けたい場合は、環境ごとに別のキーを発行する必要があります。また、導入後はバッジ表示や文言が正しく出ているかも必ず確認しましょう。
HTML／PHPで直接コーディングする場合
自前で実装する場合は、フォーム送信ボタンが押されたタイミングなどでトークンを取得し、フォームデータと一緒にサーバへ送ります。サーバ側では検証APIにトークンを送信し、successに加えてscore、action、hostnameを受け取ります。
実装例として、次のように<body>内でスクリプトを読み込みます。
<script src=”https://www.google.com”></script>
<script>
grecaptcha.ready(function() {
grecaptcha.execute(‘サイトキー’, {action: ‘submit’}).then(function(token) {
// トークンをフォームに埋め込むなどの処理
});
});
</script>
ここで重要なのは、スコアだけで判断せず、actionとhostnameも必ず検証することです。別ページで発行されたトークンが流用されていないかを確認できます。
運用面では、低スコアの送信をすべて遮断するのではなく、送信は受けて管理画面で隔離する、さらに危険な場合のみ追加認証やレート制限をかけるなど、段階的な対応にすると誤検知の影響を抑えられます。
動作確認・設定を行う
導入後は、スコアが返ってきているかだけでなく、「想定したactionになっているか」「hostnameが正しいか」まで確認します。さらに、一定期間ログを取得し、通常ユーザーのスコア帯を把握してから閾値を決めるのが現実的です。
最初から遮断を強めると、広告流入や海外IP、セキュリティ強化ブラウザなど一部の正規ユーザーが低スコアになり、問い合わせ機会を失う可能性があります。まずは観測し、基準を作ったうえで段階的に強化する流れが安全です。
また、スコアの傾向は季節やキャンペーンで変わることもあるため、閾値は固定せず定期的に見直すと運用が安定します。
reCAPTCHA v3を導入する際の注意点
reCAPTCHA v3は便利ですが、スコア判定の仕組みだからこそ注意すべきポイントもあります。特に「誤検知」と「導入直後のスコアのブレ」は、問い合わせフォームの成果に影響しやすい部分です。
設計を間違えると、スパムは減っても問い合わせまで減ってしまう可能性があります。ここでは、導入時に押さえておきたい注意点を解説します。
誤検知リスクを把握しておく
reCAPTCHA v3は「不正かどうか」を確率で判定するため、正規のユーザーでも低スコアになる場合があります。たとえば、プライバシー保護が強いブラウザ設定やトラッキング制限、共有IP、海外からのアクセスなどは、不正と判断されやすい傾向があります。
このとき、低スコアの送信をすぐにエラーにしてしまうと、スパムは減りますが、本来の問い合わせまで減ってしまいます。
そのため実務では、低スコアの場合は「遮断」ではなく「追加確認」「一時保留」「管理側で重点チェック」など、救済策を用意した設計にするのが安全です。特にBtoBサイトでは、少数の重要な問い合わせを取りこぼす影響が大きいため、強さよりバランスを重視した設計が向いています。
導入初期は「遮断」せず「スコア監視」に徹する
導入直後は、どのスコア帯が「正常」なのか判断できません。そのため、最初から閾値を決めて遮断すると、誤って正規ユーザーを弾いてしまうリスクがあります。
まずは2週間〜1か月ほど、ブロックはせずログだけを取り、通常ユーザーのスコアの平均やばらつきを確認しましょう。時間帯や流入経路によってスコアが変わるケースもあります。
そのうえで、段階的に「低スコアは確認対象へ」「さらに低ければ追加確認」と強化していくと、成果を落とさずに運用を安定させやすくなります。
トークンの有効期限に注意する
技術面で多いトラブルが、トークンの期限切れです。フォーム入力に時間がかかると、最初に発行したトークンが古くなり、送信時にエラーや不自然な判定が出ることがあります。
対策としては、ページ表示時ではなく「送信直前」にトークンを発行する設計にするのが基本です。入力項目が多いフォームや長文入力がある場合は、送信ボタンを押したタイミングでトークンを取り直す、もしくは期限切れなら再取得して送信する仕組みにすると安全です。
スコア（0.0〜1.0）の仕組みと判定ロジック
まず前提として、reCAPTCHA v3のスコアは「1.0に近いほど人間らしい」「0.0に近いほどボットの可能性が高い」という考え方で判定されます。
ただし注意したいのは、同じサイトでも「ログイン」と「問い合わせ」では攻撃の種類が異なり、適切なスコア基準（閾値）も変わる点です。そのため実装時には、操作ごとにactionを付けて管理し、検証結果として返ってくるactionが想定どおりかを必ず確認します。ここが曖昧だと、別ページで発行されたトークンが流用されても気づきにくくなります。
運用の基本は、次の流れで進めるのが安全です。
- まずログを集める
- スコア分布を確認し、通常ユーザーのスコア帯を把握する
- スコアに応じた分岐を段階的に設定する
分岐の考え方としては、「止める」よりも「扱いを変える」設計のほうが現実的です。たとえば、次のように段階分けできます。
- 高スコア：通常処理（即時送信／即時ログイン）
- 中間スコア：送信は受けるが、通知を弱める・管理画面でフラグ付け・内容を自動チェックする
- 低スコア：追加確認（メール認証など）やレート制限、同一IPの連投抑止を行う
- 極端に低い：遮断（ただし救済導線は残す）
このようにスコアを「危険度のラベル」として扱うと、成果と安全性の両方を保ちやすくなります。また、検証結果として返ってくるhostname（ドメイン）も必ず確認し、想定外のドメインからの送信を遮断することで、キーの流用リスクを下げられます。
reCAPTCHA v3に関するよくある質問
reCAPTCHA v3を導入するときに多い疑問は、料金やv2との併用、バッジ表示のルール、表示速度への影響などに集中します。ここでは、よくある質問と実務的な回答を紹介します。
reCAPTCHA v3とv2は併用できますか？
併用は十分に可能で、実務でもよく使われる方法です。たとえば、通常はv3でスコア判定を行い、スコアが低い場合だけv2の画像認証や追加確認に切り替える、といった運用がよく取られます。
v3はユーザーの手間が少ない一方で、誤検知が完全になくなるわけではありません。そのため「怪しいときだけ強くする」仕組みと相性が良いのが特長です。
reCAPTCHA v3は有料ですか？
利用状況によって変わります。小規模〜中規模のサイトであれば無料枠の範囲で運用できるケースもありますが、アクセス数が多いサイトや高度な機能を使う場合は有料プランの検討が必要になります。
費用を判断する際は、月間の判定回数と必要な機能を基準に考えるのが基本です。まずは、フォーム送信やログイン、会員登録などの回数を概算し、無料枠で足りるかを確認しましょう。
右下の「reCAPTCHAバッジ」は非表示にしても規約違反になりませんか？
バッジはCSSで非表示にできますが、その場合は代わりに「reCAPTCHAで保護していること」と「Googleのプライバシーポリシー／利用規約が適用されること」を、ユーザーが確認できる場所に表示する必要があります。
実務では、フォームの送信ボタン付近やフッターに、指定された文言とリンクを掲載するケースが一般的です。
導入によってサイトの表示速度（ページスピード）は遅くなりますか？
外部スクリプトを読み込むため、理屈のうえではリクエストが増え、影響がゼロとは言えません。ただし、reCAPTCHA v3はユーザーの操作を止めない仕組みのため、実装次第で体感への影響は抑えられます。
ポイントは、ページ表示時に毎回トークン取得を行うのではなく、フォーム送信など「必要なタイミング」だけで実行することです。無駄な判定を減らせるため、表示の初動への負荷も小さくできます。
まとめ
reCAPTCHA v3は、ユーザーの操作を阻害せずにスパム対策ができる有効な手段です。しかし、導入にはAPIを利用した開発が必要であり、適切に機能させるにはスコア判定の基準作りや、誤検知で正規ユーザーを遮断しないための調整など、運用面に専門的な知識と工数が求められます。
こうした技術的な実装や運用の手間をかけずに、安全なフォーム環境を構築したい場合は、当社の「Synergy!」が役立ちます。「Synergy!」のWebフォーム機能は、標準でreCAPTCHA v3に対応しており、管理画面で設定するだけで簡単に導入が可能です。複雑なコードを書くことなく、スパムメールの削減とユーザーの利便性を両立できます。
▼フォームの入力画面イメージ
「Synergy!」を提供するシナジーマーケティングは、システムの提供だけでなく、セキュリティ要件に合わせたフォームの設計や運用までをトータルで支援します。「スパムメールに悩んでいるが、実装のリソースがない」「コンバージョンを落とさずにセキュリティを高めたい」とお考えの方は、ぜひお気軽にご相談ください。
CRMシステム「Synergy!」の特長が機能別でわかる資料です！
「Synergy!」の具体的な製品機能については、ぜひ以下のフォームから資料をダウンロードしてご確認ください。
関連情報
※記載されている内容は掲載当時のものであり、一部現状とは内容が異なる場合があります。ご了承ください。