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

Cloudflare Pagesに置いたHTMLやCSSなどの静的ファイルは、そのまま配信されます。静的ファイルの配信だけでは、「メールを送る」「データベースに保存する」といったサーバー側の処理は実行されません。PagesではPages Functionsでサーバー側のコードを動かせるため、フォームの受信処理はPages Functions、別のWorker、外部のフォームサービスのいずれかで補います。

ブラウザのJavaScriptからメールAPIを直接呼ぶと、APIキーを公開することになり、第三者に送信機能を悪用されるおそれがあります。キーを扱う処理はサーバー側に置きます。

補足：この記事は、実装と運用を中心にした技術的な解説です。静的配信で減らせる維持費と残る費用（経営者・Web担当者向け）は、ホームページ維持費の記事で扱っています。

表は横にスクロールできます →

どの方式でも、入力の検証、スパム対策、通知先、失敗したときの確認は必要です。この記事では、サイトと受信処理を独立して公開・運用したい場合の構成例として、Cの別のWorkerで手順を示します。

この記事は、フォームの受信処理を独立したCloudflare Workerで実装する構成例です。サイトと受信処理を別々に公開・運用したい場合を想定しています。秘密値の保存やログの確認はPages Functionsでも使えるため（Pages FunctionsのSecrets・ログ）、それだけでWorkersを選ぶ理由にはなりません。

Cloudflareは、新しいプロジェクトをWorkersで始めるよう案内しています（Cloudflare Pagesの概要）。新しく作る場合はWorkersを第一の候補として検討し、既存のPagesサイトでは、Pages Functionsで受信処理を加えて運用を続ける方法もあります。構成全体の選び方はCloudflare PagesとWorkersの違い：構成を選ぶための判断表で扱っています。Workers側の認証・キャッシュ・運用の設計はCloudflare Workersの実装設計を参照してください。

今回の構成例の全体像です。ブラウザからは直接メールを送らず、Workerで受け付けて検証してから、メールAPIを呼び出します。

Turnstileのトークンは、Workerがサーバー側の検証（Siteverify）で確認します。検証に失敗した場合はメールAPIへ進まず、メールAPIがエラーを返した場合も送信済みとして扱いません。

構築時に確認する手順を、7つの段階で示します。

サイトと受信処理が別のオリジン（ドメインなど）にある場合は、Worker側でCORSを設定し、許可するオリジンを指定します。CORSはブラウザが適用する仕組みのため（MDN：CORS）、利用者の認証の代わりにはならず、ブラウザ以外からの直接の呼び出しも防げません。

公開したフォームは、ボットによる送信や、送信機能の悪用の対象になります。主な脅威と対策を整理します。1つの対策だけで防げるものではないため、適用範囲を確認して組み合わせます。

表は横にスクロールできます →

Turnstileは、訪問者に画像選択などのパズルを表示せずに判定できる仕組みです（Turnstile）。判定の結果はサーバー側の検証で確認する必要があり、トークンは発行から300秒で失効し、1回しか検証できません（Siteverify）。検証のAPIに接続できない場合も、通過させずにエラーとして扱います。Turnstileだけで大量送信や不正な入力を防げるわけではないため、対策の適用範囲、レート制限、通常の利用者への影響、通知とログの確認を組み合わせます。

メールAPIが429・5xxを返した場合やタイムアウトした場合は、利用者に失敗または再試行の案内を表示し、受付済みかどうか分からない送信は照合します。同じ問い合わせの重複を防ぐには、問い合わせごとにIDを決め、それに対応するメール送信用の重複防止キー（ResendのIdempotency-Key）を、再試行でも同じ値で使います。再試行のたびに別のキーを発行すると、重複の防止になりません。Resendはこのキーを24時間保持します（Resend：Idempotency Keys、確認日：2026年10月22日）。Turnstileのトークンは人による操作かを確かめるためのもので、1回しか検証できないため、問い合わせの識別や重複の防止には使いません。

公開前に、正常な送信に加えて、失敗したときの画面・記録・担当を確認します。次の表は、確認する場面の例です。

表は横にスクロールできます →

記録には、問い合わせの本文や秘密値をそのまま残さないようにします。照合に必要なID、処理結果、時刻などに絞り、確認する担当と保存期間を決めます。ログが保存されるかどうかと保存期間は、利用するサービスと設定によって異なります。たとえば、Pages Functionsのリアルタイムのログは保存されません（Pages Functionsのログ）。配信状態は、Resendの配信イベント（送信受付・配信・遅延・バウンスなど）で確認できます（Resend：Event Types）。

同種の構成はVercelでも実装できます。選択は、利用するランタイムと依存ライブラリ、既存の環境、費用の条件で判断します。

表は横にスクロールできます →

どちらが速いか、安いかは、処理の内容、利用量、契約プランによって変わります。メール送信だからといって一方が常に有利とは限りません。無料枠と課金条件は変更されるため、金額は各社の料金ページで最新の条件を確認してください（Vercel：Node.jsランタイム）。

フォームを公開した後も、Cloudflareの機能で保護を追加できます。ただし、使える機能と設定できる条件は、対象のURL・ドメイン・公開経路と契約プランによって異なります。アプリ側の入力検証やトークンの検証、運用の担当を置き換えるものではありません。

• WAF：Cloudflareを経由するドメインへのリクエストに、条件に応じたルールを適用します。
• レート制限：一定の時間内のリクエスト数に上限を設けます。ルールに使える条件や期間は、プランによって異なります（Rate limiting rules）。たとえば、同じ送信元から短い時間に一定の回数を超えたら一時的に遮断する、といったルールを、通常の利用者を遮断しない値で決めます。
• Zero Trust：社内向けの管理画面を追加で作る場合に、利用者を認証してからアクセスを許可する仕組みを組み合わせられます。

どの対策も、導入しただけで安全になるわけではありません。対象の経路と設定値を決め、誤って遮断した場合の連絡先と確認の担当を決めておきます。

静的サイトでも、フォームの受信処理をサーバー側に置けば問い合わせフォームを実装できます。受信処理はPages Functionsや別のWorkerで実装でき、画面・項目やデータの保存先がサービスの範囲で足りる場合は、外部のフォームサービスも選択肢です。どの方式でも、配信サービスの料金、コードと設定の保守、失敗したときの確認の担当は残るため、運用費と担当を含めて選びます。