静的サイトのまま動的処理を足すCloudflare Workers活用

「Astroで組むと速いのは分かりました。でも、問い合わせフォームはどう動くんですか」。静的サイト構成を提案すると、制作会社のディレクターからほぼ毎回この質問をいただきます。HTMLを事前に生成して配って終わり、という構成では送信を受け取るサーバーがない——そう見えるのは自然です。

結論から書くと、サイト全体を動的CMSにする必要はありません。必要な処理だけをエッジ（CDN側で動くサーバーレス実行環境。ここではCloudflare Workers）に足せば、静的の速さと動的の柔軟さは両立できます。当サイト（tsudzuri.com）はAstroとヘッドレスCMSのEmDashをCloudflareで動かす、いわゆるJamstack構成ですが、フォームもメール通知も動的OGPも下書きプレビューも、全部この方式で動いています。

「静的だとできない」と思われがちな処理

打ち合わせでよく挙がる不安は、だいたいこの4つに集約されます。

• フォーム送信とメール通知。POSTを受ける先がなく、届いた内容を担当者へ飛ばせない
• 動的OGP画像。記事ごとのシェア画像を手作業で作り続けたくない
• リダイレクト。キャンペーン終了後の転送や条件付きの出し分け
• CMS下書きのプレビュー。ビルド済みHTMLには「公開前の記事」が存在しない

どれも「サーバー側の受け口」が要る処理なのは事実です。ただ、その受け口のためにサイト全体をWordPressのような常時稼働の動的構成へ戻すのは割に合いません。ページ配信のほとんどは静的で足りるのに、ごく一部の処理のためにアプリケーションサーバーとデータベースを抱え、保守し続けることになるからです。セキュリティ更新の追従やサーバー監視といった運用の手間も、そのまま制作会社側の負担になります。

受け口だけ、エッジに後付けする

Cloudflare Workersは、世界中のCDNエッジ上でJavaScriptを実行できるサーバーレス環境です。静的ファイルはそのまま高速配信し、特定のURLだけWorkersに処理させる、という足し算の設計です。当サイトで実際に動かしている例を挙げます。

• フォーム送信。Workersが受け、ハニーポット・署名付き時間トラップ・Turnstileの3層でスパムを弾いています。Turnstileは無料で、多くの場合ユーザーに操作をさせず通過できるのが営業サイト向きです。実装の詳細はサーバーレスのフォームメール送信に書きました
• メール通知。WorkersはSMTPを直接使えない（生のTCP接続が張れない）ため、GmailのHTTP API経由で送っています。ここは最初にハマりやすいポイントです
• 動的OGP。記事タイトルからシェア画像をエッジで自動生成しています。作り方は動的OGP生成の記事に
• 下書きプレビュー。公開前の記事だけCMSから直接取得して表示するルートを別に用意しています

この4つに限らず、リダイレクトの出し分けや公開前サイトの閲覧制限のような細かい処理も、同じ発想でエッジに置けます。当サイトの実装は、どれも小さなWorkerを足す規模でした。専用サーバーの構築や月額のサーバー費は発生していません。Workersの無料枠は1日10万リクエスト（2026年7月時点の公式ドキュメント）。コーポレートサイトのフォーム受信程度なら、まず収まると感じています。

どこまで静的＋エッジで行けるか

判断の軸は「ページの中身が、閲覧者ごと・分単位で変わるか」です。

• 静的＋エッジで足りる。更新が日〜週単位のコーポレートサイトや採用サイト、メディア。フォーム・OGP・リダイレクト・プレビューはエッジ側で賄えます
• 動的CMSへ寄せる。ログイン必須の会員機能、閲覧者ごとに中身が変わる大量のページ、分単位で反映したい在庫や価格。ここまで来るとエッジの後付けでは設計が苦しくなります

迷いやすいのは検索や予約のような中間のケースでしょう。外部サービスへの橋渡しだけエッジに持たせて静的側へ倒すか、最初から動的に組むか。更新の主体と頻度を伺うと、どちらへ倒すべきかの線はだいたい引けます。

「CMSで更新したいから動的」は、実は理由になりません。ヘッドレスCMSを組み合わせれば、更新は管理画面から、配信は静的のまま。この構成への乗り換えは脱WordPressの記事にまとめています。

静的か動的か、構成の相談から

「フォームがあるから静的は無理」と選択肢を狭めてしまうのはもったいない、というのが実装側の実感です。要件を伺えれば、どこまで静的＋エッジで行けるか、どこから動的へ寄せるべきかを構成込みでご提案できます。お問い合わせからどうぞ。

本記事は2026年7月時点の情報です。