Googleが提供するreCAPTCHAの有料化（実質的な無料枠の縮小）に伴い、完全無料で使える強力なボット対策として注目を集めているのがCloudflareの「Turnstile（ターンスタイル）」です。
本記事では、Turnstileのサイトキーとシークレットキーの具体的な取得手順を画面キャプチャ付きで分かりやすく解説します。
さらに、気になる料金体系やreCAPTCHAが有料化した背景、そしてTurnstileが将来的に有料化する可能性についてもまとめています。
Cloud FlareのTurn Stileの無料枠
Cloudflare Turnstile（ターンスタイル）の無料枠は、完全無料でリクエスト数無制限という非常に 寛容なプランが提供されています。
| 項目 | 無料プラン（Free） |
|---|---|
| 利用料金 | 0 円/月（完全無料） |
| リクエスト数 | 無制限（トラフィックや検証リクエストの制限なし） |
| ウィジェット数 | 最大 20 個まで作成可能 |
| ホスト名登録 | ウィジェットごとに最大 10 個（計 200 ホスト名まで可能） |
| 分析データ | 過去 7 日間まで確認可能 |
| Cloudflare ブランド表示 | あり（オフブランド不可） |
| サポート | コミュニティサポート |
| 利用可能なウィジェットタイプ | 全タイプ利用可能 |
Google reCAPTCHAのように無料枠（月 1 万回）を超えると停止してしまったり、自動課金（Enterpriseの場合）される心配が全くありません。
突然のトラフィック増加でも追加費用は発生しません。
Cloudflare の CDN や WAF を契約していなくても、Turnstile 単体で利用できます。
無料枠の制限
無料プランでは以下の制限があります。
- 分析データの遡り: 7 日間まで（有料 Enterprise は 30 日間）
- Cloudflare ブランド: ロゴの非表示（オフブランド）は Enterprise プランのみ
- ホスト名管理: 1 ウィジェットあたり最大 10 ホスト名（Enterprise は 200）
- Any Hostname ウィジェット: 事前登録ホスト名必須（Enterprise のみ任意ホスト名可）
1 アカウントでウィジェット 20 個、各ウィジェットで 10 ドメインまで登録可能なので、最大 200 ドメインで利用できます。個人ブログや中小規模のビジネスサイトであれば、ほぼ制限なく使える設計です。
reCAPCHAとの違いは？
一番大きな違いは無料枠とセキュリティ判定制度です。
reCAPTCHAは月100万回無料から月1万回無料に大幅改悪されました。
セキュリティ性能はreCAPTCHAの方が高いです。
| 項目 | reCAPTCHA（v3） | Turnstile |
|---|---|---|
| 判定精度 | ⭐⭐⭐⭐⭐（最高） | ⭐⭐⭐⭐（十分高い） |
| 誤判定リスク | 中〜高（VPN 利用者に厳しい） | 低〜中（一部の特殊環境で発生） |
| プライバシー保護 | 低（Cookie・行動データ収集） | 高（Cookie 不使用） |
| ボット対策効果 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| コスト | 有料化（月 1 万回超） | 完全無料 |
reCAPTCHAはなぜ有料化した？TurnStileが有料化する可能性は？
reCAPTCHAはなぜ有料化したか？
2024 年 8 月 1 日以降、reCAPTCHA は従来の管理画面からGoogle Cloud Platform（GCP）に統合し、以下の性能が強化されました。
- セキュリティの強化: reCAPTCHA の発行と管理をより厳格に行えるようになった
- 悪用防止: 不正な API キー発行や乱用を防ぐための仕組みを導入
- 管理の効率化: Google の他のサービスと同様に GCP で一括管理可能に
また、reCAPTCHA は長年寛大な無料で提供されていましたが、実際は膨大な費用がかかっていました。
- AI によるボット判定のインフラコスト
- 画像パズルの生成・検証コスト
- データ保存・処理コスト
- 規制対応：キャッシュ収集によるGDRPなどへの対応
このコストを無料のまま提供し続けるのは持続不可能と判断され、有料モデルになりました。
TurnStileが有料化する可能は？
TurnStileが有料化する可能は否定できませんが、有料化する可能性は低いと言われています。
Turnstile は「画像パズルを表示させる複雑なシステム」や「膨大な行動データ収集」を必要としないため、インフラコストが reCAPTCHA よりも低く抑えられています。
また、Turnstile は、Cloudflare にとって「顧客獲得のフック」としての役割を担っています。無料で Turnstile を使ったユーザーが、他の Cloudflare サービス（CDN、WAF、企業向けプランなど）を利用することを狙っています。
更に、Cloudflare は、世界規模の CDN インフラを既に保有しており、Turnstile のような比較的小規模なサービスを追加で提供するマージナルコストが低いという利点もあります。
■判定の違い
| 要素 | reCAPTCHA | Turnstile |
|---|---|---|
| 画像パズルの生成 | 必要（トレーニングデータ作成に膨大なコスト） | 不要（原則として画像パズルなし） |
| Cookie 追跡 | 必要（データ収集・処理コスト） | 不使用 |
| AI 判定の複雑さ | 非常に複雑（膨大な行動データ分析） | 比較的シンプル（ブラウザ挙動解析） |
| プライバシー対策 | 規制対応コスト（GDPR 等） | 元から Cookie 不使用、設計がシンプル |
TurnStileの使い方
「Cloudflare Turnstile」の公式ページに入ります。
https://www.cloudflare.com/ja-jp/application-services/products/turnstile/
「利用開始」をクリックします。
ログインしたら「Add widget manually」をクリックします。
ウィジェット名(widget name)の入力
登録するドメインに対するウィジェット名をつけます。名前は任意です。
識別しやすい名前にしておきます（例: Login Form, Contact Staging など）
ドメイン名の登録
「Add Hostnames」をクリックします。
モーダルが開くので、ドメイン名を入力し、「Add」をクリックします。
ドメインが追加されたら「Save」をクリックします。
表示モード（Widget Mode）の選択
ユーザーにボットチェック（チェックボックスやローディングアニメーション）をどのように見せるかを選択します。
通常は「Mnagaed」のままでOKです。
① Managed（マネージド） ※推奨
- Cloudflareがアクセス元のリスク（ブラウザの挙動やIPアドレスなど）を自動で分析します。一般的なユーザー（低リスク）には何もさせず自動で通過させますが、「怪しい」と判断された場合のみ、ユーザーにクリックを求めるチェックボックスなどの追加チャレンジを表示します。
- メリット: セキュリティ強度を保ちつつ、通常のユーザーにはストレスを与えません。
- おすすめの用途: ログイン画面、新規登録画面、お問い合わせフォームなど、一般的なほぼすべてのフォーム。
② Non-interactive（非インタラクティブ）
- 画面上には「確認中…」のようなローディングスピナー（アニメーション）が表示されますが、ユーザーがクリックなどの操作を求められることは一切ありません。自動的にバックグラウンドで検証が行われます。
- メリット: ユーザーの手間を完全にゼロにしつつ、「セキュリティチェックを行っている」という視覚的な安心感（またはボットへの威嚇）をサイト上に残せます。
- おすすめの用途: UI/UXのデザインを一貫させたい場合や、ユーザーに一切クリックの手間をかけたくないページ。
③ Invisible（不可視）
- 挙動: 画面上にはウィジェットやアニメーションが一切表示されません。完全にバックグラウンド（裏側）でボット判定が行われます。
- メリット: サイトのデザイン（UI）を全く邪魔しません。
- おすすめの用途: 決済ボタンの裏側、ページ遷移時、またはデザインを1ピクセルも崩したくない洗練されたフォーム。
画面に何も表示されませんが、フロントエンド（JS）でトークンを取得してバックエンドへ送るコードの実装は通常通り必要です。
事前クリアランスの設定：Skip future security rule challenges for verified visitors（Pre-clearance機能）
「Pre-clearance（事前クリアランス）」 と呼ばれる強力な連携機能です。
ONの場合、ユーザーがこのTurnstileのボットチェックに合格すると、その合格証（クッキー）がブラウザに保存されます。これにより、そのユーザーは同じドメイン内の他のページで CloudflareのWAF（セキュリティルール）のブロック画面（「アクセスを制限しました」というような画面）を自動的にパス（スキップ）できる ようになります。
- 有効な条件: 対象のWebサイト（ドメイン）のDNSが、Cloudflareのプロキシ（オレンジの雲マーク）を経由して運用されている必要があります。
基本は「オフ（デフォルト）」のままでOKです。
もし、サイト全体のセキュリティ（WAF）が厳しすぎて、一般ユーザーがよくCloudflareのブロック画面に引っかかってしまうような場合に、このトグルをオンにして「フォームで人間だと証明したから、しばらくの間はWAFの制限を緩めてあげる」という使い方をします。
全ての設定が終わったら「Create」をクリックします。
サイトキーとシクレッとキーが生成されます。
以上でCloud FlareのTurnStileの登録は完了です。
フロントエンドの構築（クライアント側）
HTMLのフォーム内にウィジェットを埋め込みます。最もシンプルな「自動（implicit）レンダリング」の手順です。
Step 1: スクリプトの読み込み
HTMLの <head> 内、または </body> 直前に以下のスクリプトを記述します。
HTML
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
Step 2: フォーム内へ配置
チャレンジを表示したい場所に、クラス名 cf-turnstile と取得した Sitekey を指定した <div> を配置します。
HTML
<form action="/api/verify" method="POST">
<!-- 既存の入力フォームなど -->
<input type="text" name="username" placeholder="ユーザー名" required />
<!-- Turnstile ウィジェット本体 -->
<div class="cf-turnstile" data-sitekey="YOUR_SITEKEY_HERE"></div>
<button type="submit">送信</button>
</form>
仕組み: チャレンジが成功すると、この
divの内部にcf-turnstile-responseという名前の隠しinput要素（トークン）が自動生成され、フォーム送信時に一緒にバックエンドへ送られます。
バックエンドでの検証（サーバー側）
フロントエンドから送られてきたトークンが「本物か、期限切れでないか」を、CloudflareのAPI（siteverify）に問い合わせて検証します。このサーバーサイドの検証を行わないと、ボット防御の意味がなくなります。
- エンドポイント: (https://challenges.cloudflare.com/turnstile/v0/siteverify)https://challenges.cloudflare.com/turnstile/v0/siteverifychallenges.cloudflare.com
- リクエストメソッド:
POST - 送信パラメータ (x-www-form-urlencoded または JSON):
secret: あなたの Secret Keyresponse: フロントから送られてきたトークン（cf-turnstile-responseの値）
サーバーサイドの実装例（Node.js / Fetch API の場合）
JavaScript
// Expressなどのハンドラー内を想定
app.post('/api/verify', async (req, res) => {
const token = req.body['cf-turnstile-response']; // フロントから届いたトークン
const secretKey = 'YOUR_SECRET_KEY_HERE'; // サーバー側で秘匿するキー
if (!token) {
return res.status(400).json({ success: false, message: 'トークンがありません' });
}
// Cloudflareへ検証リクエストを送信
const response = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
secret: secretKey,
response: token,
}),
});
const outcome = await response.json();
if (outcome.success) {
// 検証成功！ ユーザー登録やお問い合わせなどの本来の処理を進める
return res.json({ success: true, message: '人間であると判定されました' });
} else {
// 検証失敗（ボットの可能性、またはトークンの期限切れ）
return res.status(403).json({ success: false, message: 'ボットチェックに失敗しました', errors: outcome['error-codes'] });
}
});
💡 運用のポイント
- トークンの有効期限: 発行されてから 5分間（300秒） のみ有効です。また、1つのトークンは1回しか検証に使えません（再利用不可）。
- 環境の分離: 開発環境（
localhostやステージング）と本番環境でウィジェットを分けて作成し、キーを環境変数で管理するとセキュアかつ運用のトラブルを防げます。
