Cloudflare Turnstileの設定方法｜フォーム実装・サーバー側検証・失敗時対応
Cloudflare Turnstileは、従来の画像選択式CAPTCHAに代わる人間確認・ボット対策機能です。CloudflareのCDNを使っていないサイトでも導入でき、問い合わせ、会員登録、ログイン、キャンペーン応募などを保護できます。
実装で最も重要なのは、ブラウザへウィジェットを表示するだけで終わらせないことです。攻撃者はクライアント側処理を回避できるため、フォームの送信先サーバーからSiteverifyへトークンを送り、検証成功後だけ業務処理を実行します。
Turnstileは、管理画面でウィジェットを作成しサイトキーをフロントエンドへ配置し、受け取ったトークンをサーバー側からSiteverifyへ送って検証します。シークレットはブラウザへ出さず、失敗・期限切れ・再送を拒否します。
本記事のポイント
- Turnstileはウィジェット表示だけでは防御にならず、送信先サーバーでSiteverifyを必ず実行します。
- トークンの有効性だけでなく、期待するホスト名やアクション、重複送信、失敗時の扱いを確認します。
- テストキー、CSP、遅延読込、アクセシビリティ、Cloudflare障害時の代替導線まで公開前に確認します。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| サイトキー | ブラウザ側で使用 | 公開情報としてウィジェットを識別 |
| シークレットキー | サーバー側だけで使用 | Siteverifyの認証 |
| トークン | 利用者の検証結果 | 短時間・一回性を前提に扱う |
| Siteverify | サーバーから検証 | 成功後だけフォーム処理 |
| 運用 | ログ・再送・障害対応 | 取りこぼしと迂回を防ぐ |
ウィジェットとホスト名を登録する
Cloudflareの管理画面でTurnstileウィジェットを作成し、利用するホスト名を登録します。開発、ステージング、本番を分けるか、どの環境で同じ設定を使うかを決めます。
サイトキーはフロントエンドへ配置できますが、シークレットキーはサーバーの秘密情報として管理します。リポジトリ、HTML、ログ、分析ツールへ露出させません。
フロントエンドへ安全に組み込む
フォーム表示時にTurnstileスクリプトとウィジェットを読み込み、成功時のトークンをフォーム送信へ含めます。表示方式、遅延読込、SPAの画面遷移、再試行、フォーム二重送信を考慮します。
CSPを設定しているサイトでは必要なスクリプト・フレーム・接続先を公式要件に沿って許可します。広告ブロッカー、厳しいブラウザ設定、社内ネットワークでも表示を確認します。
Siteverifyでサーバー側検証する
フォーム受信時、トークンとシークレットをSiteverifyへ送信します。成功応答を確認してから、メール送信、データ保存、アカウント作成など不可逆な処理へ進みます。
検証結果の成功だけでなく、期待するホスト名やactionを使っている場合は一致を確認します。トークンがない、失敗、期限切れ、重複利用、検証APIの異常をそれぞれ扱い、失敗を成功として処理しません。
再送・二重処理・タイムアウトを防ぐ
利用者が送信ボタンを複数回押したり、通信タイムアウト後に再送したりすると、Turnstile検証とは別に業務処理が二重実行される可能性があります。フォーム側でも冪等キーや受付番号を使い、同じ申請を重複処理しない設計にします。
検証APIが一時的に失敗した場合、無条件で通過させると攻撃経路になります。利用者へ再試行を案内する、別の連絡手段を表示する、受付を保留するなど、業務に応じた失敗時設計を決めます。
公開前テストとアクセシビリティ
Cloudflareが提供するテスト用キーを使い、成功、失敗、期限切れ、検証API異常をテストします。本番シークレットをローカルテストへコピーしません。
キーボード操作、スクリーンリーダー、エラー表示、フォーカス移動、モバイル表示を確認します。フォームの通知と受付確認まで含む監視は、問い合わせフォームの通知漏れを防ぐ監視設計も参考になります。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 環境ごとのホスト名とウィジェットを決めた
- シークレットをサーバー側だけに保存した
- Siteverify成功後にだけ業務処理する
- hostname・action等の期待値を確認した
- 期限切れ・再送・二重処理をテストした
- CSPと主要ブラウザで表示確認した
- 障害時の再試行・代替連絡先を用意した
よくある質問
TurnstileはCloudflare CDNを使っていなくても利用できますか？
利用できます。対象ホスト名を登録し、フロントエンドとサーバー側検証を実装します。
シークレットキーをJavaScriptへ書いてよいですか？
書いてはいけません。サイトキーは公開側、シークレットはサーバー側の秘密情報として管理します。
Siteverifyに失敗したらフォームを通してよいですか？
原則として通しません。再試行や代替導線を用意し、ボット対策を無条件に迂回しない設計にします。
Turnstileでスパムを完全に止められますか？
単独では完全ではありません。レート制御、内容検査、メール確認、業務側の重複防止などを組み合わせます。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
Turnstileをフォームへ安全に組み込み、クライアント表示だけで終わらせずサーバー側でトークンを検証する実装ガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
