「ウィジェットは貼ったが検証していない」を潰す。Turnstile Spin がエージェントから実行可能に

要約

Cloudflare は 2026-09-25、Turnstile Spin を AI コーディングエージェントから実行できるようにしたと公式ブログで発表しました。

Spin 自体は新しくありません。2026-07 に提供を開始しており、公式は「Since July release」としてダッシュボード経由で 65,000 件超の Spin ウィジェット作成を記録していると述べています。今回の更新は、エージェント経由の導線が加わった点にあります。

狙いは、設定漏れの構造的な解消です。 Turnstile（Cloudflare のボット対策、CAPTCHA の代替）の導入は2段階に分かれています。フロントエンドへのウィジェット埋め込みと、バックエンドでの Siteverify API 呼び出しによるトークン検証です。

問題は、後者を飛ばす実装が多いことです。 公式は “Misconfiguring Turnstile by skipping backend validation leaves sites exposed to bots.” と書いています。ウィジェットを貼れば画面上にチェックが表示され、見た目には保護されているように見えます。 しかしサーバー側でトークンを検証していなければ、ボットはウィジェットを無視してエンドポイントを直接叩くだけで通ります。 保護されていると思い込んだまま、実際には通っている。気づきにくい種類の欠陥です。

エージェント経由の流れはこうなります。利用者が保護したい箇所を指定すると、エージェント（Claude、Cursor、Codex など、すでに使っているもの）がフロントエンドとバックエンドのコードを読み、統合プランを提示します。 承認すると、エージェントが利用者のコードベース内で変更を行います。 公式の表現では “The agent you already use…makes the approved changes inside your codebase”。

想定シナリオが3つ挙げられています。 新規導入では、ウィジェット埋め込みと Siteverify 配線をゼロから入れます。既存ウィジェットの修復では、サーバー側検証が欠けているものをダッシュボードで検出して修正します。移行では、既存の CAPTCHA コードを検出して Turnstile への置き換えを提案します。

アクセス経路は3つ。Cloudflare ダッシュボード、Wrangler CLI、GitHub でホストされている公開 Skill 経由でエージェントへ直接です。Turnstile は無料で、Spin 固有の課金は示されていません。

何が変わったか

• Turnstile Spin をコーディングエージェントから実行できるようになった（GitHub でホストされている公開 Skill 経由）
• エージェントがフロントエンドとバックエンドのコードを読み、統合プランを提示。承認後にコードベース内で変更を行う
• 新規導入では、ウィジェット埋め込みと Siteverify 配線をまとめて入れる
• 既存ウィジェットのうちサーバー側検証が欠けているものをダッシュボードで検出し、修復できる
• 既存の CAPTCHA コードを検出して Turnstile への置き換えを提案できる
• アクセス経路は3つ: ダッシュボード / Wrangler CLI / エージェント直接
• Spin 自体は 2026-07 提供開始。ダッシュボード経由で 65,000 件超のウィジェット作成実績
• Turnstile は無料。Spin 固有の課金の記載なし

業務インパクト（一般企業向け）

まず、自社サイトの Turnstile がサーバー側検証を入れているか確認する話になります。 これは推測ではなく、ダッシュボードで検出できると公式が明言しています。「入れたつもり」が実際どうなっているかが機械的に分かるわけです。フォーム、ログイン、問い合わせ、資料請求。ボット対策を入れた記憶はあるが、誰がどう入れたか分からない箇所は、どの会社にもあります。確認コストがほぼゼロになったのだから、やらない理由がありません。

この種の欠陥は、通常の品質管理では見つかりません。 動作テストでは通ります。人間が操作すればウィジェットが表示され、送信が成功し、期待どおりに見えます。検証が抜けていることは、ボットを実際に投げてみるまで分かりません。 セキュリティレビューの項目に入っていなければ、そのまま何年も残ります。「見た目が正しく動くのに守られていない」という欠陥の型として、社内のチェックリストに追加する価値があります。

エージェントにコードを変更させる、という点は審査対象です。 便利さの裏で、エージェントが自社のコードベースに変更を加えるという運用に入ります。公式の流れでは「プランを提示 → 承認 → 変更」であり、承認の段階が挟まります。この承認を誰がやるのか、変更内容をレビューするのか、テストを通すのか。 通常のコード変更と同じ手順に載せるなら問題になりませんが、「エージェントがやったから大丈夫」で通す運用は危険です。 セキュリティを入れる作業だからこそ、変更の中身を読む体制が要ります。

公開 Skill として GitHub にある、という提供形態も見ておく価値があります。 ベンダーが自社製品の導入手順を Skill として公開し、顧客が使うエージェントに読み込ませるという形です。製品ドキュメントを人間が読んで実装する、という前提が変わりつつあります。 自社が API やサービスを提供している立場なら、「エージェントが読める導入手順」を用意するかどうかが、今後の採用率に影響する可能性があります。今のところ先例は少なく、動きとして追う価値があります。

副業・個人活用視点

受託案件の点検メニューとして、すぐ売れる形です。 過去に納品したサイト、あるいは引き継いだサイトで、Turnstile のサーバー側検証が入っているかをダッシュボードで確認する。 抜けていればエージェント経由で修復する。作業時間は短く、効果は明確で、説明もしやすい。 「ボット対策が実は効いていませんでした、直しました」は、顧客にとって価値が分かる報告です。

新規サイト構築では、標準手順に入れておく価値があります。 フォームを作るたびに Turnstile を入れる、かつSiteverify まで必ず入れる。 これをエージェント経由で機械的に済ませれば、「あとで入れます」が発生しません。 手作業だと後回しにしてそのまま忘れるのが定番ですが、依頼1回で片付くなら忘れません。品質の下限が仕組みで上がります。

CAPTCHA からの移行提案は、単体の案件になります。 古い reCAPTCHA が入っているサイトは大量にあります。既存 CAPTCHA コードを検出して置き換えを提案する機能があるなら、移行作業の見積もりが立てやすい。ユーザー体験の改善（Turnstile はパズルを解かせない）とコスト面の両方を訴求できるため、提案としても通しやすい題材です。

エージェントに公開 Skill を読ませる、という形そのものを覚えておくと応用が効きます。 ベンダーが用意した Skill を自分のエージェントに読ませて、自分のコードベースに適用させる。この形は Turnstile 固有ではありません。 今後同じ提供形態が増えるなら、「どのベンダーが Skill を出しているか」を把握している人が、導入作業を速く終えられます。 情報の差がそのまま作業時間の差になる領域です。