コンテンツにスキップ

14-4 どこに置くか

Plan: Free費用: 0円Wrangler 4.126.0公式ドキュメント取得日 2026-08-27
係を置くのは、書き込みを受け付ける場所だけです。

係を雇えたら、次は立ち位置です。すべての通路に立たせれば安全に見えますが、実際にはお客さんが疲れて帰ってしまいます。

守りたいのは、店に何かを書き込んでもらう場所です。パンフレットを眺めるだけの棚の前に係は要りません。

いま読んでいるこのサイト(Cloudflare Lab)は現在すべて読むだけのページなので、係の立ち位置は「これから足す書き込みの入口」になります。

Learning goals

この節でできるようになること

  • 係を置く場所の選び方を言える
  • 置きすぎないための公式の手がかりを言える
  • 公式が挙げる置き方の決まりを 3 つ言える
  • Turnstile Analytics で何を見るかを言える

店に来るお客さんは二とおりです。見るだけの人と、何かを申し込む人です。困るのは、申込用紙に機械が大量に書き込むことです。

公式は、Turnstile がウェブサイトの form を bot から守るものだと最初に書いています。また、名前の付け方の例として「Login Form」「Contact Page」を挙げており、想定している置き場所が読み取れます。

同時に公式は、Turnstile がサイトのどこででも、より邪魔にならない形で課題を走らせられるとも説明しています。置き場所を選べるのが Turnstile の性質です。

係を置くのは書き込みを受け付ける場所で、読むだけの場所には置きません。

書き込みを受ける場所には係が立ち、読むだけの場所には立っていません。

つまり、係を置くのは「書き込みを受け付ける場所」です。

係を増やせば増やすほど安全になる、とは限りません。増えるのは、本物のお客さんが立ち止まる回数です。

数の上限は公式に決まっています。Plans のページは、Free で置ける widget を 20 個までとしています。無限に増やす前提の仕組みではありません。

公式には Pre-clearance という機能もあります。単一ページのアプリケーション(SPA)で Turnstile に Pre-Clearance の cookie を発行させ、Cloudflare の課題を組み込むものです。

公式は、どの widget がどこで使われているかを把握しておくことも勧めています。

係を置きすぎると、本物のお客さんの手間だけが増えます。

通路のたびに係が立っていると、本物のお客さんの足が止まります。

つまり、係は必要な入口にだけ置き、数と場所を把握します。

係を何人も雇うと、誰がどこの係か分からなくなります。名前と持ち場を先に決めておくと、後で困りません。

公式の Best practices には、運用の項目が並んでいます。widget に用途が分かる名前を付けること、開発・検証・本番で別々の widget を使うこと、どの widget がどこで使われているかを記録することです。

安全側の項目もあります。Restrict your hostnames(自分が管理する店名でだけ係を立たせる)、secret key を client-side のコードに出さないこと、key を定期的に入れ替えること、そして使われ方を監視することです。

係は用途ごとに分け、立ってよい店の名前を決めておきます。

係にはそれぞれ持ち場の名前が付いていて、立ってよい店名も決まっています。

つまり、名前・開発と本番の別・店名の三つを最初に決めておきます。

係を置いた後で見るべきなのは、「何人止めたか」ではなく「本物のお客さんが通れているか」です。数字で見ないと、どちらも分かりません。

Cloudflare では、この数字を Turnstile Analytics で見ます。公式は、hostname・country・browser・IP アドレスといった切り口で widget の統計を示し、課題がどこで多く出ているか、特定の相手が失敗しているか迂回しているかを見分けられると説明しています。

見られる項目には Top HostnamesTop BrowsersTop CountriesTop Source IPs などがあります。widget の画面では、solve rate(課題が解かれた割合)と通信量、上位の action の変化が示されます。Free でさかのぼれるのは最大 7 日ぶんです。

係の働きは、通した数と止めた数のグラフで確かめます。

通した数と止めた数が並んでいます。片方だけでは判断できません。

つまり、置いた後は Turnstile Analytics の数字で確かめます。

ここで紹介した置き方が、いま読んでいる Cloudflare Lab でどう使われるかを見ます。

Cloudflare Lab は Worker で動いているので、書き込みの入口を足す段階で widget を 1 つ置き、Worker の中で Siteverify API を呼んで token を確かめる予定です。Hostname management には公開している店名だけを登録します。実測は後で追記します。

  • 係を置くのは、書き込みを受け付ける場所です。
  • Free の widget は 20 個までで、SPA 向けの Pre-clearance もあります。
  • 置いた後は Turnstile Analytics の solve rate と通信量で確かめます。

この節で出てきた言葉を、つながりの順に並べると次のようになります。

図のラベル: 守りたいのは書き込み form / そこにだけ係を置く widget / 数と場所を把握する Free は 20 個まで / SPA に組み込む Pre-clearance / 名前・開発と本番の別・店名を決める Best practices / 数字で確かめる Turnstile Analytics / 0 なら確認漏れ Siteverify API

次の章では、検問で使う名簿(Lists)と守りの点検表を扱います。

この節のチェック

問 1公式が最初に挙げる Turnstile の守る対象はどれですか?

問 2同じ訪問者に繰り返し課題を出すのを減らすために、公式が挙げている機能はどれですか?

問 3公式の Best practices にある運用の項目はどれですか?

問 4Turnstile Analytics で見られるものはどれですか?

問 5token の確認を実装していないとき、Turnstile Analytics の表示はどうなりますか?

最終更新日: