問い合わせフォームをCloudflare Workersで実装する：Turnstile・Resend連携

Cloudflare Pagesのような「静的サイトホスティング」は、サーバーが存在しないため、「メールを送る」「データベースに保存する」といった処理が単体ではできません。

安易に外部からのJavaScriptだけで処理しようとすると、APIキーが漏洩し、スパムの踏み台にされるリスクがあります。そこで、「フォームの裏側で動く極小のサーバー」が必要になります。

Note: 本記事は実装・運用にフォーカスした技術解説です。Cloudflare Pagesの基本的な構築手順や、Vercelとの料金比較（経営者・Web担当者視点）については、こちらの導入ガイドをご覧ください。

「B: Pages Functions」も悪くありませんが、将来的に「スマホアプリからも送りたい」「他のサイトでも使いたい」となった時、独立した「C: Workers」の方が柔軟性が高いため、本記事ではCを推奨します。

本記事は、フォームの受信処理をCloudflare Workersで実装する前提で手順を示します。Pages Functionsでも同等の処理は書けますが、Secretsをコマンドラインで管理でき、フロントエンドと切り離してデプロイできる点からWorkersを選んでいます。

PagesとWorkersの一般的な使い分け、どちらを選ぶかの判断基準はCloudflare PagesとWorkersの違い：構成を選ぶための判断表で扱っています。Workers側の認証・キャッシュ・運用設計はCloudflare Workersの実装設計を参照してください。

今回構築するシステムの全体像です。

クライアントからは直接メールを送らず、Workerを経由させます。ここで「Turnstileの認証トークン」をチェックすることで、ボットによる大量送信を水際で遮断します。

実運用に耐えうる構成での実装ステップです。以下の手順で構築を進めます。

「動けばいい」で作ったフォームは、攻撃者の格好の標的になります。最低限考慮すべき脅威と対策をまとめました。

特に「Botスパム」は公開後すぐに来ます。Turnstileを入れておけば、ユーザーに「自転車のタイルを選んでください」といった面倒なパズルを強いることなく、ブラウザ検証と振る舞い分析でボット判定が行われます。

同種の構成はVercelでも実装できます。選択に影響する違いは、実行環境と課金軸の2点です。

メール送信のような軽い処理には、Workersの短い起動時間が適しています。一方で、重い画像処理やNode.js固有のライブラリに依存する場合はVercelが扱いやすくなります。無料枠と課金条件は変更されるため、金額での比較は各社の料金ページで最新の条件を確認してください。

本構成の真の価値は、フォームを作った後にあります。Cloudflareのエコシステムに乗っているため、以下のようなセキュリティ強化が「管理画面の設定だけ」で可能になります。

• WAF (Web Application Firewall)：特定の国やIPからのアクセスをブロック。
• Rate Limiting：「1分間に10回以上送信してきたら1時間ブロック」等のルール設定。
• Zero Trust：社内管理画面を追加で作る際、VPNなしで安全にアクセス制御。

「まずはフォームから」始めた場合でも、WAFやZero Trustなどのセキュリティ基盤へ段階的に拡張できる点がCloudflareの特徴です。

「静的サイトだからフォームは諦める（またはGoogleフォームで妥協する）」必要はありません。Cloudflare Workersを使えば、セキュアで高速、かつ運用費の安いフォームが作れます。