Cloudflare Workersの実装設計：認証・キャッシュ・運用とLambdaとの使い分け

従来のサーバーレス（AWS Lambdaなど）と、エッジで動くサーバーレス（Cloudflare Workers）は、処理を動かす場所と仕組みが異なります。

静的配信に近い軽いAPIや、リクエストの振り分けなどには、Workersが候補になります。一方、時間のかかる処理、多くのランタイム機能を必要とする処理、AWS内のデータの近くで動かしたい処理は、Lambdaのほうが扱いやすい場合があります。料金表に加えて、処理にかかる時間、使うライブラリ、データの置き場所で判断します。

画面は静的配信に任せ、動的な処理だけをWorkersで行う構成が基本の形です。PagesとWorkersのどちらを使うかは、Cloudflare PagesとWorkersの違い：構成を選ぶための判断表で扱っています。この記事では、Workersで動的な処理を実装することを前提に、その設計と運用を説明します。

運用の費用を含めた構成の判断は、中小企業サイトの運用コストを抑える方法で整理しています。また、フロントエンドとAPIをリポジトリごとに分ける場合は、疎結合アーキテクチャの設計が前提になります。

この構成の利点は、オリジンサーバー（重い処理をするサーバー）への負荷を小さくできることです。静的ファイルへのアクセスはオリジンに届かず、動的なリクエストも、Workersがキャッシュや軽い処理で代わりに受け持ちます。

フロントエンドの開発で特に注意したいのが、APIキーやシークレットトークンの漏えいです。

原則は、Secretsをブラウザに届くコードに含めないことです。

• 危険な書き方：
  Reactのコードに const API_KEY = "sk-..." と書く。
  → ブラウザの「ソースを表示」などで、誰でも見られてしまいます。
• 安全な書き方：
  APIキーはCloudflare Workersの環境変数に保存し、画面側からはキーを付けずにWorkersを呼び出す。
  Workersの中で env.API_KEY を付けて、外部のAPIへ中継する。

Cloudflareでは、ダッシュボードから暗号化された環境変数を設定できます。コードからは参照できますが、デプロイした後に値を画面で見ることはできないように保護されています。

Cloudflare Workersの設定は、一つの設定ファイルで管理します（現在は wrangler.jsonc が推奨の形式ですが、wrangler.toml も引き続き使えます）。最小限の構成例は次のとおりです。

name = "my-worker-app"
main = "src/index.ts"
compatibility_date = "2026-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の使い方の例：

• ニュース一覧（誰にでも同じ内容）： max-age=600（10分キャッシュ）。誰が見ても同じ内容なので、エッジから返し続けます。
• ユーザー情報（利用者ごとの内容）： no-store（キャッシュしない）。常にDBから最新の情報を取得します。
• 検索結果： s-maxage=3600（1時間）。同じキーワードでの検索による負荷を下げます。

キャッシュできる範囲を先に決めておくと、オリジンやデータベースへの不要なアクセスを減らせます。個人情報を含むレスポンスや、権限によって内容が変わる画面は、共有のキャッシュに入れないように設計します。

サーバーレスでは、サーバーの管理は不要になりますが、運用がなくなるわけではありません。サーバーに入ってログを見ることができないため、何を記録し、どこで確認するかを前もって決めておきます。

• ログの保存：
  Workers Logsで実行ログを保存・検索できます（保存期間やサンプリング率はプランによって異なります）。長期間の保管や、外部のSIEMへの集約が必要な場合は、LogpushやDatadogとの連携を設定します。
• リアルタイムの確認：
  Wrangler tail コマンドで、今起きているエラーをターミナルで続けて確認できます。開発中のデバッグで役立ちます。
• バージョン管理：
  PagesもWorkersも、過去のデプロイへ1クリックで戻す（ロールバック）機能があります。障害が起きたときは、原因を直すより先に、前のバージョンへ戻すかどうかを判断すると、影響が続く時間を短くできます。

導入するときにつまずきやすい点を挙げます。

• CORSのエラー：
  Pages（ドメインA）からWorkers（ドメインB）を呼び出すと、ブラウザが通信をブロックします。Workers側で、適切な Access-Control-Allow-Origin ヘッダーを返すように実装します。
• Node.jsのAPIとの違い：
  Workersはブラウザと同じ系統のV8エンジンで動いており、Node.jsそのものではありません。fs モジュールなどは使えないため、ライブラリを選ぶときに、Workersで動くかを確かめます（参考：型安全にWorkersを実装するTypeScript開発環境）。

Cloudflareで構築を始める前に確認する項目です。