reCAPTCHAの導入方法【2026年9月時点】v2とv3の選び方、サーバー側検証、無料枠10,000件の上限

「問い合わせフォームに英文のスパムが毎日届く。reCAPTCHAを入れればよいと聞いたが、何から手をつければいいのか」——自社サイトを運用している方から、こうした相談をよく受けます。管理画面でキーを取るところまでは調べればわかる。けれども、v2とv3のどちらを選ぶのか、無料で使えるのか、正規のお客様をブロックしてしまわないか。そこから先が決まらない、という声がほとんどです。

結論から言うと、reCAPTCHAの導入方法は3つの判断で決まります。バージョンをv2とv3のどちらにするか、サーバー側でトークンを検証するか、v3のスコアをどの閾値でどう扱うか。この3つです。とくに見落とされやすいのがサーバー側の検証で、ここを省くと、フロントにスクリプトを貼ってもスパムは止まりません。もう1つ、v3は「スコアを返すだけ」で自動的にブロックはしません。何をするかはサイト側が実装します。

逆に言えば、この3つを先に決めておけば、実装そのものは大がかりな作業ではありません。難しいのはコードではなく、「怪しいと判定されたとき、自社の業務としてどうするか」を決めることです。拒否するのか、いったん受け取って管理画面に印を付けて人が見るのか。ここが決まっていない実装は、あとで必ず作り直しになります。

本記事では、reCAPTCHAで防げるもの・防げないもの、v2とv3の違いと使い分け、導入の手順(キーの発行・フロントの埋め込み・サーバー側の検証)、閾値の決め方と無料枠の上限、ユーザー体験とアクセシビリティ・個人情報とCookieの観点、reCAPTCHA以外の選択肢と外部チームに任せるときの確認点、よくある質問の順に解説します。バージョンの違い、スコアの仕組み、無料枠と課金、上位ティアの位置づけは、Googleの公式ドキュメントを2026年9月19日に直接確認した内容だけを書いています。コードを羅列する記事にはせず、発注側が判断できる粒度に揃えました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。フォームまわりで繰り返し聞くのが「reCAPTCHAを入れたのにスパムが減らない」という相談です。原因はほぼ1つに絞れます。この記事を読み終えるころには、自社のフォームに何をどの順で入れればよいか、外注先に何を確認すればよいかが判断できるはずです。

reCAPTCHAとは何か——フォームにスパムが来る仕組みと、防げるもの・防げないもの

手順に入る前に、reCAPTCHAが何をする道具で、何をしない道具なのかを揃えておきます。ここを飛ばして導入すると、「入れたのにスパムがゼロにならない」という不満が残り、対策そのものが失敗だったと評価されてしまいます。防げる範囲と防げない範囲を先に線引きしておけば、社内への説明も、外注先への依頼文も書きやすくなります。

reCAPTCHAとは「送信してきたのが人間かプログラムか」を推定して教えてくれる仕組み

reCAPTCHAはGoogleが提供する、フォーム送信やログインなどの操作が人間によるものかどうかを判定するサービスです。判定の材料はユーザーの操作の様子で、その結果を受け取ったサイト側が、送信を受け付けるか、追加の確認を求めるか、拒否するかを決めます。

押さえておきたいのは、reCAPTCHAが「門番」ではなく「鑑定人」だという点です。門を閉めるのはサイト側の仕事で、reCAPTCHAは「この訪問者は怪しい」と耳打ちするところまでを担当します。この役割分担が、後述するv3の誤解の元になっています。

なぜフォームにスパムが来るのか——公開されたURLとHTMLは、誰でも機械的に読める

「うちの小さなサイトに、なぜ毎日英文のスパムが届くのか」——これは仕組みを知ると腑に落ちます。Webサイトは公開されている以上、そのHTMLは誰でも取得でき、フォームの送信先URLと入力項目の名前も読み取れます。あとは、ブラウザを開かずにその送信先へ直接データを送るプログラムを書けば、1分間に何十件でも送信できます。

ここで重要なのは、スパムを送る側はあなたのサイトの画面を見ていないということです。「送信ボタンを押す」という人間の操作を経ていないので、画面上に置いた注意書きも、JavaScriptで動く入力チェックも意味を持ちません。狙い撃ちされているわけではなく、公開されているフォームを機械的に巡回して片端から送っているだけ、というのが実情です。だからこそ、判定はサーバー側、つまりデータを受け取る側で行う必要があります。

防げるもの・防げないものの線引き(表)——人が手で送る営業メールは止まらない

つまりreCAPTCHAは「機械による大量送信を減らす道具」であって、迷惑な連絡をゼロにする道具ではありません。当社でもヘッドレスCMSを使ったWebサイトや、介護記録SaaS「CareViewer」のように登録の入口を持つサービスを手がけていますが、最初の打ち合わせで必ずこの線引きを共有します。ここを曖昧にしたまま進めると、リリース後に「効果がなかった」という評価になり、次の対策に予算が付かなくなるからです。

なお、チャット機能の投稿や通報の設計はフォームのスパム対策とは別の論点になります。そちらは「チャットシステムの作り方」の記事で扱っています。次章では、reCAPTCHAのどのバージョンを選ぶかという最初の分岐を見ていきます。

v2とv3の違いと使い分け——チェックボックス型・画像選択型とスコア型、「v3はブロックしない」という誤解

reCAPTCHAには大きく2つの系統があります。ユーザーに操作を求めるv2と、操作を求めずスコアを返すv3です。「新しいv3のほうが良いに決まっている」と考えて選ぶ方が多いのですが、この2つは性能の新旧ではなく、判定の責任を誰が持つかが違います。ここを取り違えたまま導入するのが、最も多い失敗です。

v2の3つの型——チェックボックス、画像選択のチャレンジ、Invisible

Googleの公式ドキュメント(2026年9月19日確認)では、v2として次の型が説明されています。

• チェックボックス型: 「私はロボットではありません」のチェックボックスをユーザーがクリックする方式。公式には「連携が最も簡単な選択肢」と位置づけられています
• 画像選択のチャレンジ: チェックボックスを押したあと、怪しいと判断された場合に「信号機の写真を選んでください」といった追加確認が出ます。常に出るわけではなく、必要と判断されたときだけ表示されます
• Invisible(非表示バッジ)型: チェックボックスを置かず、サイト上の既存のボタンが押されたときに動きます。公式の説明では「既定では、非常に疑わしいトラフィックにのみチャレンジが表示される」とされ、この感度は設定で調整できます

v2の特徴は、サイト側に「合格・不合格」に近い結果が返ることです。ユーザーがチャレンジを突破したかどうかがはっきりするため、実装側の判断は「通す・通さない」の二択で済みます。

v3は「スコアを返すだけ」——公式に「ユーザーを遮ることはない」と書かれている

v3はユーザーに一切操作を求めません。代わりに、0.0から1.0のスコアを返します。公式ドキュメントには「1.0は非常に良いやり取りである可能性が高く、0.0は非常にボットである可能性が高い」と書かれています。

ここが本記事で最も強調したい点です。v3はスコアを返すだけで、送信をブロックしません。 Googleの公式ドキュメントには「reCAPTCHA v3 will never interrupt your users(v3がユーザーを遮ることはない)」と明記されています。つまり、スコアをいくつ以上なら通す、いくつ未満なら止める、止めたときに何を表示する——これらはすべてサイト側が実装する仕事です。

「v3を入れたのにスパムが減らない」という相談の多くは、ここに原因があります。スクリプトを貼ってスコアを受け取るところまでは動いているけれど、そのスコアを使って何もしていない。それでは何も変わりません。要注意です。

なお公式ドキュメントでは、スコアの判断基準として「まずは0.5を閾値として始める」ことが推奨されています。ただしこの数値の扱いには注意点があり、後の章で説明します。

v2とv3の比較表と、使い分けの判断軸(誰が判定の責任を持つか)

判断軸はシンプルです。判定の責任を自社で持てるならv3、持ちたくないならv2。閾値を決め、誤検知を監視し、必要なら調整する担当者を置けるならv3が使えます。置けないなら、ユーザーに少し手間をかけてもらってでもv2のほうが事故が少ない、というのが実情です。

併用という選択——v3のスコアが低いときだけv2のチャレンジを出す

二択で悩む必要はありません。v3で全リクエストにスコアを付け、スコアが低いものだけv2のチャレンジに回す、という組み合わせが実務ではよく採られます。大多数のユーザーは何も見ずに通過し、怪しいと判定されたときだけ確認が出るため、体験と防御の両立がしやすくなります。ただし実装するものが2系統になるので、工数は単独より増えます。自社のフォームは、どちらの摩擦を許容できるでしょうか。

reCAPTCHA導入の手順——キーの発行、フロントの埋め込み、サーバー側の検証

ここからが本題の導入手順です。作業は3つに分かれ、担当者も分かれます。コードは載せません。公式ドキュメントに正確な実装例があり、言語やフレームワークによって書き方が変わるためです。この記事で押さえるのは、どの作業を誰がやり、何を確認すれば完了と言えるのかという粒度です。この粒度で理解しておけば、自分で作業するときも、外注先の見積もりを読むときも判断できます。

手順の全体像(表)——3つの作業と、誰の担当か

この表で伝えたいのは、手順1は非エンジニアでも進められるが、手順2と3は開発者の作業だということです。そして、手順3がなければ手順1と2は無意味です。

手順1: サイトキーとシークレットキーを発行する——Google Cloudプロジェクトへの移行に注意

管理画面でラベル(識別用の名前)を付け、使うバージョンを選び、対象ドメインを登録すると、2種類のキーが発行されます。サイトキーはHTMLに書く公開用のキー、シークレットキーはサーバー側だけで使う秘密のキーです。シークレットキーをフロントのコードやリポジトリに書くのは論外で、これが漏れると検証の意味がなくなります。

もう1つ注意点があります。reCAPTCHAの管理はGoogle Cloud側へ統合が進んでいます。公式の移行スケジュール(2026年9月19日確認)では、2024年第3四半期に新規のClassicキーの発行が停止し、2025年第4四半期からClassicキーの自動移行が始まり、2026年第1四半期に「Google Cloudプロジェクトに紐づかないキーはAPIアクセスがロックされる」とされています。既存のキーについては「移行後も既存のv2またはv3のサイトキーは動作し続け、サイトのコードを変更する必要はない」と公式に書かれていますが、キーの作成・削除・変更といった管理操作を行うにはGoogle Cloudプロジェクトを引き受ける必要があります。いま動いているサイトでも、管理画面に入れるかどうかを一度確認しておいてください。

手順2: フロントに埋め込む——ここまでは「トークンを作るだけ」

フォームのあるページでreCAPTCHAのスクリプトを読み込み、v2ならウィジェットを表示し、v3なら送信の直前に実行してトークンを受け取ります。このトークンを、フォームの他の入力値と一緒にサーバーへ送ります。

ここで理解しておきたいのは、フロントの作業が生むのはトークンだけだということです。トークンは「この操作についてGoogleが判定を持っている」という引換券にすぎず、券そのものには人間かどうかの答えは入っていません。なお公式には、v3ではトークンが2分で失効するため、ページの読み込み時ではなくユーザーの操作時に実行するよう記載されています。

手順3: サーバー側で検証する——省くと意味がない理由

サーバー側で、受け取ったトークンとシークレットキーを検証エンドポイント(https://www.google.com/recaptcha/api/siteverify)にPOSTし、返ってきたJSONを見て判定します。公式ドキュメントによれば、返ってくる主な項目は成否を示す success、v3ではスコアを示す score と操作名を示す action、解決された日時の challenge_ts、ドメインを示す hostname、そして失敗時の error-codes です。

この手順を省くとどうなるか。フォームの送信先URLは公開されているので、ブラウザを通さずにそのURLへ直接データを送れば、トークンが無くても、あるいはでたらめな値を入れても受け付けられてしまいます。つまり、フロントにスクリプトを貼っただけの状態は、鍵を買って玄関に置いたまま鍵穴を付けていないのと同じです。 私が「reCAPTCHAを入れたのにスパムが減らない」という相談を受けて確認すると、ほとんどがこの状態です。

確認のポイントを3つ挙げておきます。

1. 検証に失敗した送信を、確実に止めているか。 検証結果をログに出すだけで処理を続けている実装は珍しくありません
2. トークンの再利用を防いでいるか。 公式には「各トークンは2分間有効で、1回だけ検証できる」と記載されており、再利用しようとすると timeout-or-duplicate というエラーコードが返ります
3. hostname と(v3なら)action を照合しているか。 別のサイトや別の操作で取得したトークンを使い回されないようにするためです。公式もaction名の検証を求めています

私が開発の現場で伝えているのは、「検証を通っていない送信が本当に保存されないか、自分の手で試してから完了と言ってください」ということです。当社はGitのプルリクエストによるコードレビューを標準化し、リリース前にダブルチェックを行っていますが、この種の見落としはレビューの観点に入れておかないと通過してしまいます。動いているように見えることと、効いていることは別です。

閾値の決め方と誤検知、無料枠の上限と課金、上位ティアとの違い

実装が終わったあとに決めることが2つ残ります。v3を選んだ場合の閾値と、費用です。どちらも「あとで考える」と後回しにされがちですが、閾値は正規のお客様を取りこぼすかどうかを左右し、費用は無料だと思っていたら請求が来るか、逆にある日突然エラーになるかを分けます。この章の数値はすべてGoogleの公式ドキュメントで2026年9月19日に確認したものです。

閾値の決め方——いきなり拒否に使わない。記録→保留→拒否の三段構え

公式ドキュメントでは「まずは0.5を閾値として始める」ことが推奨されています。ただしこれは出発点であって、そのまま拒否の基準にしてよいという意味ではありません。自社のフォームに実際に来る送信のスコア分布は、サイトの性質によって大きく違うからです。

そしてもう1つ、公式ドキュメントに重要な記載があります。reCAPTCHAのスコアには11段階があり、0.0〜1.0の値を取りますが、課金アカウントを紐づける前の状態では「0.1、0.3、0.7、0.9」の4つのスコアレベルしか返りません。つまり無料で使っている限り、0.5という閾値は実質的に「0.3以下を弾く」と同じ意味になります。0.45と0.55を切り分けるような細かい閾値設計をしても、返ってくる値がその粒度にならないので意味がありません。ここを知らずに細かく調整して悩んでいるケースをよく見ます。

現実的な進め方は、次の三段構えです。

誤検知を減らすうえで大切なのは、弾いたことに気づける設計にしておくことです。拒否した送信を一切記録していないと、正規のお客様を何件取りこぼしたのかが永遠に分かりません。少なくとも、拒否した件数とスコアは残してください。エラー画面には「うまく送信できない場合は電話またはメールで」と代替の連絡先を必ず書いておきます。問い合わせは売上の入口なので、ここを塞ぐのは失敗のもとです。

無料枠の上限と、超えたときに何が起きるか(公式の数値)

費用は「使った回数(アセスメント)」で決まります。公式の課金ドキュメント(2026年9月19日確認)には、次のとおり記載されています。

ここは判断が分かれるところです。課金を有効にしないと、上限に達した瞬間にreCAPTCHAがエラーを返します。 そのときフォームがどう振る舞うかは、あなたのサイトの実装次第です。検証に失敗したものを一律で拒否する実装にしていると、月末に全員がフォームを送れなくなる、という事故が起こり得ます。一方、課金を有効にすれば止まりませんが、想定外のアクセスがあれば費用が発生します。

月10,000という数字は、問い合わせフォームだけなら十分に見えますが、アセスメントは送信の回数ではなく判定の回数です。ログイン画面や検索など複数の導線にv3を入れていると、思ったより早く積み上がります。導入前に「どの画面に何回分の判定が発生するか」を見積もってください。上限に達したときの挙動を決めていないのは要注意です。

上位ティア(Enterprise)との違い——使える機能と契約形態

公式のティア比較ドキュメント(2026年9月19日確認)では、ボット防御の段階数がEssentialsとPremiumで4レベル、Enterpriseで11レベルとされています。また、判定理由を示すreason codesはEssentialsでは提供されず、Premiumで基本的なもの、Enterpriseで高度なものが使えます。アカウント乗っ取り対策(パスワード漏えい検知、SMS詐欺対策)や不正取引の検知はPremium以上、専任の担当者や攻撃調査はEnterpriseのみです。Enterpriseは「12か月以上のサブスクリプション」という契約形態になります。

整理すると、コーポレートサイトの問い合わせフォームのスパム対策が目的なら、上位ティアは不要です。上位ティアが意味を持つのは、会員制サービスで不正ログインやアカウント乗っ取りが実害になっている場合、あるいはECで不正決済を検知したい場合です。目的が「問い合わせフォームの英文スパムを減らす」なら、無料枠と閾値設計で足ります。

ユーザー体験とアクセシビリティ、個人情報とCookieの観点——同意は要るのか

スパム対策は、訪問者に何かを課す対策でもあります。導入の可否を判断するうえで、実際に通れない人が出ることと、外部に情報が送られることの2点は避けて通れません。社内の法務やコンプライアンス部門から質問を受けるのもこの2点です。以下は公表されている資料に基づく一般的な整理であり、法的助言ではありません。 自社の状況に当てはめた判断は、必ず弁護士など専門家に確認してください。

ユーザー体験とアクセシビリティ——画像選択も音声も、通れない人がいる

W3Cが公開している「Inaccessibility of CAPTCHA」というノート(2021年12月16日公開・2026年9月19日確認)は、CAPTCHA全般のアクセシビリティ上の問題を整理しています。歪んだ文字や画像を使う方式は、視覚に障害のある人には当然使えず、それ以外の視覚の困難を抱える人にとっても「非常に難しい」と指摘されています。また、英語を前提とした出題は、英語を読めない利用者を排除します。

音声版が用意されていれば解決するわけでもありません。同ノートには、プログラムによる突破を防ぐために音声も歪ませてあるため、聴力に問題のない被験者にとっても聞き取れなかったという初期の検証結果が紹介されています。さらに音声版は、通常の会話を理解するのに比べて「すべての人間の利用者に認知的な負荷をかける」とも書かれています。同ノートが示す方向性は明快で、ハニーポットやスパムフィルタリング、二段階の確認といった、利用者に操作を求めない手段が推奨されています。

実務への落とし込みは3つです。第一に、画像選択のチャレンジが出る設定は、出る頻度を最小にする。第二に、通れなかった人のための代替経路(電話番号、メールアドレス)をフォームの近くに必ず置く。第三に、会員登録や申し込みのように「そこを通らないとサービスが使えない」導線ほど、操作を求めない方式を選ぶ。非機能要件としてアクセシビリティを定義しておくと、開発会社との合意が取りやすくなります。

個人情報とCookieの観点——何が外部に送られ、どこまで整理が要るか

まず事実から。Googleの公式FAQ(2026年9月19日確認)には、reCAPTCHAはリスク分析を行う目的で _GRECAPTCHA という必要なCookieを設置すると明記されています。また、Googleの他のCookieを追加で置かないようにするために、www.google.com の代わりに www.recaptcha.net を使う方法も案内されています。つまり「Cookieは使っていない」という前提で導入するのは誤りです。

次に、日本の個人情報保護法との関係です。個人情報保護委員会のFAQ(2026年9月19日確認)では、Cookieなどの端末識別子について、個人情報に該当しない場合には「通常、当該端末識別子に係る情報端末の利用者に関する情報として、『個人に関する情報』に該当し、個人関連情報に該当する」と整理されています。家族などで端末を共用している場合も同様とされています。

そして、個人関連情報を第三者に提供する場面では、提供先がそれを本人が識別できる個人データとして取得することが想定される場合、原則として本人の同意が必要とされています。さらに、提供先が外国にある第三者である場合には、同意を得ようとする時点で、その外国の個人情報保護制度や、提供先が講じる措置などの参考情報を本人にあらかじめ提供していることを確認する必要がある、とされています。

ここで「では同意ボタンが必須か」と結論を急がないでください。同意が求められる構造は「提供先が個人データとして取得することが想定されるか」という条件に懸かっており、自社が何をどこへ送り、提供先がどう扱うかによって評価が変わります。加えて、Webサイトやアプリで利用者の情報を外部に送信する仕組みを入れる場合には、電気通信事業法の外部送信規律によって、送信される情報の内容と、その情報を取り扱う者の名称等を通知または公表することが求められる場合があります。どの規律が自社に及ぶかは事業の内容で変わるため、ここは法務・専門家の確認事項として扱ってください。

なお、開発を海外の委託先に任せる場合の個人データの取り扱いは、本記事とは別の論点です。委託と越境移転の整理は「ベトナムへのデータ越境と個人情報」の記事で扱っています。

実務としてやること3つ(プライバシーポリシー・表示・代替手段)

最低限、次の3つは導入とセットで進めてください。第一に、プライバシーポリシーに、スパム対策のために外部サービスを利用していること、Cookieが設置されること、送信される情報の種類を記載する。第二に、reCAPTCHAを利用している旨の表示をフォーム付近に置く(バッジを非表示にする場合、Googleの規定により代わりの文言表示が求められます)。第三に、通れなかった人のための代替の連絡先を用意する。この3つは実装ではなく運用の作業なので、開発の見積もりに含まれていないことが多く、抜け落ちやすい部分です。

reCAPTCHA以外の選択肢と、外部チームに任せるときの確認点——当社の体制

reCAPTCHAが唯一の手段ではありません。無料で併用できる手段もあれば、無料枠の考え方がまったく違うサービスもあります。そして、これらのどれを選ぶにせよ、実装を外部の制作会社や開発チームに任せるなら、見積書の「reCAPTCHA対応」という一行を分解して確認する必要があります。この章では選択肢の整理と、外注時に確認する項目をまとめます。

代替と併用の選択肢4つ(表)——hCaptcha、Cloudflare Turnstile、ハニーポット、レート制限

各サービスの公式ページで2026年9月19日に確認した内容です。

選び方の目安を示します。外部にデータを送りたくない、あるいは法務のレビューを短くしたいならハニーポット+レート制限から始める。 これだけでも機械的な巡回による大量送信はかなり減ります。それで足りなければreCAPTCHAかTurnstileを足す。アクセシビリティの要件が明示されている案件ではTurnstileが選びやすい。会員制サービスで不正ログインが実害になっているなら、CAPTCHAだけで解こうとせず多要素認証やレート制限と組み合わせる。この順番です。

なお、開発や運用を外部に委託するとき全般のセキュリティ(契約・人・環境・運用・法規制)は、フォームのボット対策とは別の話です。そちらは「オフショア開発 セキュリティ対策」の記事にまとめています。

外部チームに任せるときの確認点7つ——見積書で「reCAPTCHA対応」の一行を分解する

見積書に「reCAPTCHA対応 一式」と書かれていたら、次の7つを確認してください。この7つが埋まっていない見積もりは、あとで追加費用か、効かない実装のどちらかになります。

とくに4番は見落とされがちです。制作会社のGoogleアカウントでキーを発行したまま契約が終了し、次の会社が引き継げない、というのは実際によくある話です。キーの名義は自社に置いてください。開発会社の選定そのものについては「システム開発会社の選び方」「ホームページ制作 外注費用」の記事も参考になります。

当社の体制——フォームの実装は「判定後の業務」まで含めて設計する

当社(TALENTBASE VIETNAM)は、ホーチミンを拠点にベトナムの開発チームで受託開発とラボ型開発を提供しています。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社を挟む仲介マージンがありません。体制は日本人PM・ブリッジSEをフロントに置くパターンAを推奨しており、1名から、最短2週間で開始できます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

この記事の内容に関係するところで言えば、当社は介護記録SaaS「CareViewer」のようにユーザー登録の入口を持つサービスや、ヘッドレスCMSを使ったWebサイト、Stripeを使った決済アプリ(二要素認証を含む)を手がけてきました。フォームまわりの実装では、判定後に何をするかを先に決めてから着手します。 拒否するのか、受け取って管理画面に印を付けて人が見るのか。ここを決めずに始めた実装は、必ず作り直しになるからです。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準の手順にしています。

スパム対策だけを切り出した小さな依頼でも、上の7項目を整理したうえで、必要な作業と工数をお伝えします。既存のサイトを大きく作り替えずに済むなら、率直にそうお伝えします。

【FAQ】reCAPTCHAの導入方法に関するよくある質問

ここまでで触れきれなかった、実務でよく聞かれる5つの質問をまとめます。いずれも「自社の場合はどうか」を判断するための材料として読んでください。数値は2026年9月19日に公式ドキュメントで確認したものです。

Q1. WordPressなどのCMSを使っています。プラグインを入れるだけで足りますか

多くの場合は足ります。フォームのプラグインにreCAPTCHA連携の機能があり、管理画面でサイトキーとシークレットキーを入力すれば、サーバー側の検証まで含めて動くように作られているためです。ただし、プラグインの説明に「サーバー側で検証する」旨の記載があるかを確認してください。 表示だけを追加するタイプのものもあります。また、自作のフォームや、外部のフォームSaaSを埋め込んでいる場合は、プラグインでは対応できません。

Q2. 無料の範囲で運用できますか

問い合わせフォーム1つであれば、まず足ります。公式には、1つの組織あたり暦月ごとに10,000アセスメントまで無料とされています。ただしこの枠は「すべてのアカウント、すべてのサイト」で合算されるため、複数サイトを運用している場合や、ログイン・検索など複数の導線にv3を入れている場合は早く消費します。また、課金を有効にしていないEssentialsティアでは、上限を超えるとリクエストが429のクォータエラーを返します。上限に達したときにフォームがどう振る舞うかを決めておいてください。

Q3. v3を入れたのにスパムが減りません。何を疑えばよいですか

順に3つです。第一に、サーバー側の検証が実装されているか。 実装されていなければ、フォームの送信先に直接POSTされて素通りします。最も多い原因です。第二に、スコアを受け取ったあとに何か処理をしているか。 v3はスコアを返すだけで、公式にも「ユーザーを遮ることはない」と明記されています。第三に、届いているのが本当にプログラムによる送信か。 人が手で送っている営業メールなら、reCAPTCHAでは止まりません。

Q4. 正規のお客様をブロックしていないか、どうやって確認しますか

拒否した送信の件数・スコア・時刻・入力内容の一部を記録し、週に一度目視で確認してください。記録していなければ確認しようがありません。あわせて、エラー画面に電話番号やメールアドレスなどの代替の連絡先を置き、「送信できない」という連絡が来る経路を残しておきます。導入直後の2〜4週間は拒否せず記録だけにする、という進め方が安全です。

Q5. 実装を外部に頼むと、どのくらいの規模の作業になりますか

既存のフォームが1つで、サーバー側の処理に手を入れられる状態なら、調査・実装・確認を含めても数人日の範囲に収まることが多い作業です。規模が膨らむのは、フォームが複数ある場合、フォームがフロントエンドとサーバーで分かれている場合、判定後の業務(管理画面での確認や通知の振り分け)を新たに作る場合です。当社の場合、公開している単価は実務3年目安で月1,500USD(約22.5万円 / 1USD=150円換算目安)からで、最小構成は日本人PMをフロントに置いて2〜3人月の月額約80万円〜です。ただしスパム対策のような小さな範囲であれば、継続の体制を組むより、必要な作業だけを切り出して見積もるほうが合理的な場合もあります。現在のサイトの構成をお聞かせいただければ、必要な作業と、作らなくてよい部分の切り分け。

まとめ: reCAPTCHAの導入方法は、バージョン選定・サーバー側検証・閾値設計の3点で決まる

reCAPTCHAの導入方法は、キーを発行してスクリプトを貼る作業ではありません。決めるのは3つです。第一に、ユーザーに操作を求めるv2か、操作を求めずスコアを返すv3か。v3はGoogleの公式ドキュメントに「ユーザーを遮ることはない」と明記されているとおり、スコアを返すだけで自動的にブロックはしません。第二に、サーバー側でトークンを検証するか。ここを省くと、フォームの送信先に直接データを送られて素通りします。「入れたのにスパムが減らない」の原因はほぼこれです。第三に、v3のスコアをどの閾値でどう扱うか。無料で使っている間は返るスコアが0.1・0.3・0.7・0.9の4段階に限られるため、細かい閾値設計には意味がありません。

費用は、1つの組織あたり暦月ごとに10,000アセスメントまでが無料で、この枠はすべてのアカウント・すべてのサイトで合算されます。課金を有効にしていない場合、上限を超えるとリクエストが429のクォータエラーを返すため、上限に達したときにフォームがどう振る舞うかを先に決めておいてください(いずれも2026年9月19日に公式ドキュメントで確認)。また、画像選択のチャレンジは通れない人が必ずいます。代替の連絡先を必ず用意し、プライバシーポリシーにCookieと外部送信の記載を加えてください。外部にデータを送りたくない場合は、ハニーポットとレート制限から始める選び方もあります。

外部の制作会社や開発チームに任せるときは、見積書の「reCAPTCHA対応」という一行を7項目に分解して確認してください。とくに、サーバー側検証が範囲に入っているか、判定後に何をするか、キーを誰の名義で発行するかの3つです。フォームのスパム対策を含むWebサイト・システムの実装についてはホームページ制作の外注費用、委託先に任せるとき全般のセキュリティはオフショア開発のセキュリティ対策もあわせてご覧ください。現在のサイトの構成と要件をお聞かせいただければ、必要な作業と、作らなくてよい部分の切り分けを概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。