Cloudflare Turnstileとは｜無料プランの上限と導入に要るもの

問い合わせフォームに、意味の通らない英文の送信が毎日届く。営業リストに載せるためだけの入力が止まらない。こうした送信を減らす手段として、長いあいだ、信号機や横断歩道の画像を選ばせるCAPTCHAが使われてきました。Cloudflare Turnstileは、その画像選択を出さずに同じ役割を果たすことを狙ったサービスで、無料のプランがあります。

Turnstileには、検討の入口になる特徴が2つあります。1つは、自社サイトの通信をCloudflare経由に切り替えなくても使えることです。公式の概要ページは、Cloudflareへトラフィックを送ることなく、どのWebサイトにも埋め込めると書いています。もう1つは、無料プランでも検証の回数に上限が置かれていないことです。上限があるのは回数ではなく、あとで見るとおり「数」のほうです。

ただし、フォームにコードを貼れば終わり、というものではありません。公式ドキュメントはサーバー側での検証を必須としており、ここを省くと、入れたつもりで実際には何も確かめていない状態になります。この記事では、Cloudflareの公式ドキュメントに書かれている範囲だけを使って、仕組み、トークンの制限、表示モード、無料プランの上限、そして日本の会社が導入の前に決めておく項目を整理します。確認日は2026年9月16日です。

検証は2か所にある。片方だけでは成立しない

Turnstileを使うには、まずCloudflareのダッシュボードでウィジェットを作ります。このとき2つの鍵が渡されます。サイトキーはフォームのHTMLに書き込むもので、訪問者に見えて構いません。シークレットキーはサーバー側に置くもので、外に出してはいけないものです。この2つが、そのまま実装する場所の2か所に対応します。

訪問者の側では、ウィジェットが読み込まれると検証が走ります。公式の概要ページによれば、ここで行われているのは非対話型のJavaScriptによる検証で、計算量を要する問題、記憶領域を使う問題、ブラウザのWeb APIの検出などを組み合わせ、相手のリスクに応じて難易度を変えています。画像の選択が出ないのは、検出をやめたからではなく、判定材料を別のところから取っているためです。

検証に通ると、ブラウザ側にトークンが発行されます。このトークンはフォームの送信内容と一緒に自社のサーバーへ届きます。サーバーは、受け取ったトークンとシークレットキーをchallenges.cloudflare.com/turnstile/v0/siteverifyへ送り、返ってきたsuccessがtrueかどうかで受け付けるかを決めます。ここまでやって、ようやく1回ぶんの判定が終わります。

公式ドキュメントの書き方は、この点でかなり強い調子です。サーバー側の検証は必須（mandatory）であり、トークンは無効かもしれず、期限切れかもしれず、すでに使われているかもしれないため、検証しなければ実装に大きな脆弱性が残る、としています。さらに、siteverifyを呼ばない限り設定は未完了で、トークンの検証件数はゼロのままになるとも書かれています。

ここが、実務では最初の分かれ目になります。フォームの送信処理に手を入れられるかどうかで、導入できるかが決まるからです。制作会社に任せたまま構成が分からないサイトや、送信先をサービス側が持っている埋め込み型のフォームでは、ウィジェットを表示させることはできても、検証する側を用意できないことがあります。見た目のチェックボックスだけが増えて、実際には誰も確かめていない、という状態はそうやって生まれます。

トークンは5分で切れ、1回しか使えない

siteverifyに送るトークンには、公式ドキュメントに3つの制限が明記されています。これは仕様の細部のように見えて、フォームの設計をどうするかに直結します。

有効期間は発行から300秒、つまり5分です。これが効いてくるのは、入力に時間のかかるフォームです。相談内容を長文で書いてもらう問い合わせ、複数ページに分かれた申込み、添付ファイルを探しているあいだに手が止まる資料請求。こうした画面では、送信ボタンを押した時点でトークンがすでに失効していることがあります。実装のときは、失効した場合に何を表示して、どう取り直させるかまで決めておかないと、正規の訪問者が理由の分からないエラーに突き当たります。

同じトークンを検証できるのは1回だけです。すでに検証したトークンを送り直すと、期限切れと同じtimeout-or-duplicateというエラーコードが返ります。送信に失敗したときに同じ内容をそのまま再送する作りにしていると、2回目はここで止まります。なお、通信の失敗などで安全に再試行したい場合に備えて、siteverifyにはidempotency_keyという任意のパラメータが用意されています。

3つ目の2048文字は、トークンの最大の長さです。受け取ったトークンをデータベースやログに残す設計にするなら、格納先の長さをここに合わせておきます。

表示モードは3つ。選ぶのは強さではなく見せ方

Turnstileには3つの表示モードがあります。混同しやすいのですが、これは検出の強さを段階で選ぶ設定ではありません。訪問者の画面に何を見せるかの違いです。

Managedは、訪問者のリスクの度合いに応じてチェックボックスを出すかどうかを自動で決めます。公式ドキュメントが推奨としているのはこれです。Non-interactiveは、読み込み中を示す表示は出るものの、訪問者が操作する必要はありません。Invisibleは何も表示されず、検証が背後で完結します。

見えないほうが体験として優れている、と短絡しないほうがいい理由が2つあります。1つは、Invisibleを使う場合、プライバシーポリシーでTurnstile Privacy Addendumに言及することが公式ドキュメントで求められている点です。もう1つは、何も表示されないと、送信できなかったときに訪問者が理由を推測する手掛かりを持てない点です。止めたいのはbotであって、問い合わせをやめてしまう見込み客ではありません。

表示の調整もひととおり用意されています。サイズはnormal・flexible・compact、テーマはauto・light・darkから選べます。言語については、対応言語の一覧に日本語がja-jpとjaの両方で載っています。日本語のサイトに英語のウィジェットだけが残る、という事態は避けられます。

無料プランの上限は、回数ではなく「数」で決まる

料金の考え方は、使った量で課金する多くのSaaSとは違います。公式のプラン比較を、記載のまま並べます。

項目	Free	Enterprise
料金	Free	Contact Sales
ウィジェットの数	Up to 20 widgets	Unlimited
チャレンジ（トラフィックまたは検証リクエスト）	Unlimited	Unlimited
ウィジェットあたりのホスト名	10 hostnames per widget	Maximum of 200 hostnames per widget
ホスト名を事前指定しないウィジェット	No	Yes
分析でさかのぼれる期間	7 days maximum	30 days maximum
Pre-clearance	Yes	Yes
Ephemeral IDs	No	Yes
Cloudflareの表記を外す（Offlabel）	No	Yes
WCAG 2.2 AAA compliance	Yes	Yes
コミュニティサポート	Yes	Yes

出典はCloudflare Turnstile「Plans」（確認日 2026-09-16）です。値は英語の表記のまま記録し、日本語へ言い換えていません。

読み方の要点は3つあります。まず、検証の回数は両方のプランで無制限です。アクセスが増えたから料金が発生する、という形ではありません。次に、無料プランの制約はウィジェットが20個まで、1つのウィジェットにつきホスト名が10個まで、という「数」で効いてきます。複数のブランドサイトやサブドメインを抱えている会社は、導入の前にこの掛け算を数えておくほうが安全です。

3つ目は分析です。無料プランでさかのぼれるのは7日ぶんで、Enterpriseでも30日ぶんです。週次で様子を見る運用なら足りますが、月次のレポートに「先月どれだけ弾いたか」を載せる運用にすると、無料プランの範囲では数字を取り出せません。数値を残したいなら、自社側で判定結果を記録しておく設計が要ります。

何を受け取り、何を受け取らないのか

フォームは個人情報が最初に通る場所なので、外部のサービスを挟むときは、そこへ何が渡るのかを先に押さえておく必要があります。

Cloudflareのプライバシーの説明ページは、Turnstileが処理するシグナルとして、クライアントのIPアドレス、TLSフィンガープリント、User-Agentヘッダー、そしてサイトキーとそれに紐づくオリジンを挙げています。そのうえで、これらのシグナルからCloudflareが個人を直接特定することはできない、と書いています。概要ページの側には、セキュリティの検証に厳密に必要なデータだけを処理し、利用者のやり取りやフォームの入力内容にはアクセスも保存も送信もしない、という記述があります。

Cookieについては、条件によって扱いが変わります。Turnstile自体はログインCookieのようなものを読みに行きませんが、pre-clearanceという機能を使うとcf_clearanceというCookieが設定されます。これは、いちど検証に通った訪問者が、その後のリクエストでCloudflareのWAFのチャレンジを省けるようにする仕組みです。使うには、ウィジェットのホスト名がWAFのルールを持つゾーンと一致している必要があると書かれています。Cookieの同意の設計に関わる部分なので、pre-clearanceを使うかどうかは実装の前に決めておくほうが手戻りが少なくて済みます。

日本の会社が、導入の前に決めておくこと

ここまでは公式ドキュメントに書かれていることです。日本で運営しているサイトに入れる場合は、書かれていない側を自社で決める必要があります。決めるのは次の5つです。

決めること	判断の材料	見る場所
サーバー側の検証を誰が書くか	フォームの送信処理に手を入れられるか	自社の実装、または制作会社
表示モード	訪問者に何を見せるか。Invisibleならポリシーへの記載	公式ドキュメント「Widget types」
表示言語	日本語で出すなら ja または ja-jp を指定する	公式ドキュメント「Supported languages」
ウィジェットとホスト名の数	サイト数とサブドメイン数が上限に収まるか	公式ドキュメント「Plans」
外部送信と越境移転の説明	自社が何を個人データとして扱っているか	個人情報保護委員会のガイドラインとFAQ

最後の項目だけ、判断の材料が社外にあります。個人情報保護委員会は、よくある質問の中で、外国にある第三者へ個人データを提供する場合には、日本と同等の水準の制度を持つ国であるか、施行規則の基準に適合する体制を整備しているか、法第27条第1項各号に該当するか、のいずれでもない限り本人の同意が必要だと説明しています。これは、第三者提供ではなく取扱いの委託にあたる場合も同じだとしています。

自社のフォームにTurnstileを入れることがこれに当たるかどうかは、そのフォームで何を扱っていて、どの契約の形で提供しているかによって変わります。この記事は法的な判断をしていません。該当するかどうかは、社内の担当部門か専門家に確認してください。ここで示したかったのは、確認すべき論点が「料金」や「精度」とは別に1つあるという点です。

公式ドキュメントで確認できなかったこと

公平を期すために、参照した範囲で分からなかったことを残します。

Enterpriseの金額は「Contact Sales」としか書かれておらず、公表されていません。日本語のサポート窓口の有無、日本国内の導入実績、可用性の保証についても、参照したページには記載がありません。検出の精度、つまりどれだけのbotを実際に止められるかを示す数値も見当たりませんでした。止まる割合を約束しているサービスではない、という前提で入れるかどうかを決めることになります。

他社のCAPTCHAとの優劣もこの記事では比べていません。並べるには、両方の公表値を同じ条件で読み直す必要があり、ここではTurnstileの公式ドキュメントだけを扱いました。導入したあとに効果を語るなら、自社のフォームで受信件数がどう変わったかを記録するのが、いちばん確かな材料になります。

海外のWebサービスを、公表されている条件だけで判断する読み方は、当サイトで繰り返し扱っています。料金と自前運用の条件を読んだPlausible Analyticsの記事や、責任の所在がどこへ移るのかを整理したMerchant of Recordの記事が近い読み方です。フォームの実装を自社サイト側から見るなら、WordPressのプラグインの選び方もあわせて読めます。海外の事業とサービスの動きは海外ビジネスにまとめています。