Cloudflare Pages/Workersでのエッジ配信とサーバーレス活用

従来のサーバーレス（AWS Lambda等）と、エッジサーバーレス（Cloudflare Workers）は、アーキテクチャが根本的に異なります。

静的サイトの配信や軽量なAPIならCloudflareが圧倒的に有利ですが、動画変換や機械学習などの「重い処理」はAWS Lambdaの方が向いています。

Cloudflareのエコシステムは機能が豊富ですが、モダンなWeb開発において主役となるのは「Pages」と「Workers」の2つです。これらを混同せず、適材適所で使い分けることが成功の第一歩です。

💡 実践ガイド
中小企業がコストを抑えて安全にWebサイトを構築する具体的な手順については、👉 中小企業が無料〜安価に高品質HPを作る：Cloudflare Pages × Next.js 実務手順 で詳細に解説しています。

基本戦略は、「画面（UI）はPages、ロジック（API）はWorkers」です。Next.jsなどのフレームワークを使う場合、Pagesの中にFunctions（実体はWorkers）を含めることも可能ですが、大規模化を見越すならリポジトリレベルで分離する疎結合アーキテクチャを検討すべきです。

最もコストパフォーマンスが良く、スケーラビリティが高いのが以下の構成です。

1. User → Cloudflare Pages (CDN Edge)

まずは最寄りのエッジから、キャッシュされたHTML/JSを0.1秒で受信します。

2. Frontend → Cloudflare Workers (BFF)

ブラウザから動的なデータ（在庫、マイページ情報）をWorkersへリクエストします。

3. Workers → Upstream API / DB

WorkersがAPIキーを付与して外部API（Headless CMS, DBなど）を叩き、結果を整形して返します。

この構成のメリットは、「オリジンサーバー（重い処理をするサーバー）への負荷を極小化できる」点です。静的ファイルへのアクセスはオリジンに行かず、動的リクエストもWorkersがキャッシュや軽量処理を肩代わりします。

フロントエンド開発で最も危険なのが、APIキーやシークレットトークンの漏洩です。

「Secretsをフロントに出さない」ことが鉄則です。

• NG (危険)：
  Reactコード内に const API_KEY = "sk-..." と書く。
  → ブラウザの「ソースを表示」で誰でも見れてしまいます。
• OK (安全)：
  Cloudflare Workersの環境変数にAPIキーを保存し、フロントからはキー無しでWorkersを叩く。
  Workers内で env.API_KEY を付与して外部APIへプロキシする。

Cloudflareではダッシュボードから暗号化された環境変数を設定でき、コード内からは参照できますが、デプロイ後の値の閲覧はできないよう保護されています。

Cloudflare Workersの設定は wrangler.toml ファイル一つで管理します。最小限の構成例を見てみましょう。

name = "my-worker-app"
main = "src/index.ts"
compatibility_date = "2024-01-01"

# ■ 環境変数のバインディング
# シークレットはここには書かず、CLIで `npx wrangler secret put` して登録します
[vars]
API_HOST = "https://api.example.com"

# ■ KV (Key-Valueストア) の設定
[[kv_namespaces]]
binding = "MY_KV"
id = "xxxxxxxxxxxxxxxxxxxxx"

# ■ スマートプレースメント (最適配置) の有効化
# ユーザーに近いエッジではなく、DBに近いエッジで動かす場合にONにする
# [placement]
# mode = "smart"

このように、「インフラの設定」をコードとしてリポジトリ管理（IaC）できる運用性の高さも魅力の一つです。

エッジ活用の醍醐味はキャッシュコントロールにあります。Workersを使えば、「特定のユーザーだけキャッシュしない」「1分だけキャッシュする」といった細かい制御が可能です。

Cache API活用例：

• ニュース一覧 (Public)： max-age=600 (10分キャッシュ)。誰が見ても同じなので、エッジで返し続ける。
• ユーザー情報 (Private)： no-store (キャッシュなし)。常にDBから最新を取得。
• 検索結果 (Query)： s-maxage=3600 (1時間)。同じキーワードでの検索負荷を下げる。

これらを適切に設定するだけで、バックエンドDBの負荷を1/10以下に減らすことも珍しくありません。

サーバーレスは「サーバー管理が不要」ですが、「運用が不要」なわけではありません。むしろ、ログが見えにくくなるため、意図的な可視化が必要です。

• ログストリーミング：
  Workersのログは標準では保存されません。DatadogやLogpush連携を設定し、永続化します。
• リアルタイム監視：
  「Wrangler tail」コマンドで、今起きているエラーをターミナルで流し見ることができます。開発中のデバッグに必須です。
• バージョン管理：
  PagesもWorkersも、過去のデプロイメントに「1クリックでロールバック（切り戻し）」する機能があります。障害時は修正より先に、まず前バージョンに戻す判断が重要です。

導入時によくハマるポイントを挙げます。

• CORS (Cross-Origin Resource Sharing) エラー：
  Pages (Domain A) から Workers (Domain B) を叩く時、ブラウザがブロックします。Workers側で適切な Access-Control-Allow-Origin ヘッダーを返す実装が必要です。
• Node.js APIの非互換：
  Workersはブラウザ互換のV8エンジンで動いており、Node.jsではありません。fs モジュールなどは使えないため、型安全にWorkersを実装するTypeScript開発環境での実装時にライブラリ選びに注意が必要です。

Cloudflare環境での構築プロジェクトを始める前の確認リストです。