目次

• 戦略的概要
• 1. PagesとWorkersを使用するタイミング
• 2. 無料プランの重要な制限

  • 一般的でないヒント
• 3. SPAの古典的な問題：深いルート

  • 一般的でないヒント
• 4. 環境変数：公開は秘密を意味しない

  • 一般的でないヒント
• 5. SPA内にAPI全体を含めないでください

  • 一般的でないヒント：すべてのためにFunctionsを呼び出さないでください
• 6. デプロイの最後にカスタムドメインを使用する
• 7.オリジンとAPIを保護する
• 8. Preview Deploymentsを活用する

  • 一般的でないヒント
• 9. 大容量ファイルにR2を使用する
• 10. 開発中の積極的なキャッシュを回避する
• 11. 監視すべきメトリクス
• 開始するための推奨アーキテクチャ
• 結論

戦略的概要

必要性	ツール	推奨事項
フロントエンドのデプロイ	Cloudflare Pages	Gitリポジトリを接続して自動デプロイ
静的ファイルの提供	Pages CDN	アセットのリクエストが無料で無制限であることを活用
ドメインの管理	Cloudflare DNS	カスタムドメインとプロキシレコードを使用
アプリケーションの保護	WAF Custom Rules	ログイン、登録、重要なエンドポイントを保護
小規模APIの作成	Pages FunctionsまたはWorkers	軽量なロジックとシンプルなエンドポイントに使用
ファイルの保存	R2	画像、PDF、大容量ファイルをフロントエンドから分離
シンプルなデータの保存	KVまたはD1	設定、セッション、プロトタイプに使用
フォームの保護	Turnstile	不正利用が存在する場所のみに追加
SPAルートの処理	_redirectsまたは_routes.json	不明なルートをindex.htmlに送信
シークレットの管理	Variables and Secrets	フロントエンドバンドルに秘密鍵を含めない
変更の検証	Preview Deployments	本番環境前に各プルリクエストをレビュー
コストの制御	制限と分析	Pages FunctionsとWorkersを別々に測定

1. PagesとWorkersを使用するタイミング

従来のSPAの場合、最も簡単な出発点はCloudflare Pagesです。

Pagesは、アプリケーションが静的ファイルにコンパイルされるときに適しています：

npm run build

次のようなフォルダが生成されます：

dist/

ワークフローは次のようになります：

1. Gitリポジトリを接続する。
2. フレームワークを選択する。
3. ビルドコマンドを定義する。
4. 出力フォルダを指定する。
5. 変更ごとに自動でデプロイする。

Cloudflare Pagesでは、コマンド、出力フォルダ、環境変数、およびさまざまなフレームワークのプリセットを設定できます。(Build configuration)

Workersは、次のような場合に使用します：

• カスタムAPI
• 高度なミドルウェア
• 認証
• リクエストの変換
• エッジで実行されるロジック
• フロントエンドとバックエンドを組み合わせた単一デプロイプロジェクト

実用的な推奨事項は次のとおりです：

まずはフロントエンドにPagesを使用し、バックエンドの具体的な必要がある場合にのみWorkersまたはPages Functionsを追加します。

2. 無料プランの重要な制限

無料のPagesプランでは、月間最大500回のビルド、同時ビルド1回、サイトあたり20,000ファイル、ファイルあたり最大25 MiBのサイズが許可されています。また、プレビューデプロイメントは無制限です。(Pages Limits)

これは、多くの個人アプリケーション、MVP、小規模プロジェクトには十分です。

ただし、次のものを直接Pagesにアップロードするのはお勧めしません：

• 大容量動画
• インストーラー
• バックアップ
• 重いマルチメディアファイル
• 大量の画像コレクション

これらには、R2または専用ストレージを使用し、Pagesをアプリケーション専用にすることが望ましいです。

一般的でないヒント

ビルドによって生成されるファイルをカウントします：

Get-ChildItem -Recurse dist | Measure-Object

アプリケーションはメガバイト単位では小さく見えるかもしれませんが、ソースマップ、翻訳、フォント、重複アセットによりファイル制限を超える可能性があります。

3. SPAの古典的な問題：深いルート

SPAは/からナビゲートするときは完璧に動作するかもしれませんが、ユーザーが直接次の場所に入ると404エラーが表示される場合があります：

/dashboard
/settings/profile
/projects/123

これは、サーバーがdashboardやsettings/profileという物理ファイルを探すために発生しますが、これらのルートはフロントエンドルーターによって解釈されるべきものです。

解決策は、不明なルートをindex.htmlにリダイレクトすることです。

多くのPagesプロジェクトでは、パブリックフォルダ内に_redirectsファイルを作成できます：

/* /index.html 200

コード200は、ブラウザがルートを可視的なリダイレクトに変換せずにindex.htmlのコンテンツを受け取るべきことを示します。

一般的でないヒント

静的ファイルやAPIにこのフォールバックを無差別に適用しないでください。設定が不適切な場合、次のような実際のエラーが：

/api/users
/assets/logo.svg
/favicon.ico

index.htmlからのHTMLレスポンスに変わる可能性があります。

常にテストしてください：

• メインルート
• 内部ルート
• 存在しないルート
• ブラウザのリロード
• 直接共有されたリンク
• モバイルデバイスからのアクセス

4. 環境変数：公開は秘密を意味しない

SPAはブラウザで実行されます。したがって、ビルド中に含まれる変数は、ユーザーに表示される可能性があります。

次のものを公開することは有効です：

VITE_API_URL
NEXT_PUBLIC_API_URL
PUBLIC_SUPABASE_URL

ただし、次のものを公開してはいけません：

DATABASE_PASSWORD
STRIPE_SECRET_KEY
JWT_PRIVATE_KEY
CLOUDFLARE_API_TOKEN

公開変数はフロントエンドの設定に使用できます。シークレットはPages Functions、Workers、またはバックエンドに残す必要があります。

Cloudflareでは、プロジェクトパネルから本番環境とプレビュー用に異なる変数を設定できます。(Pages Bindings)

一般的でないヒント

2つの別々の環境を作成します：

Preview → テストAPI
Production → 実際のAPI

これにより、テストフロントエンドが実際のデータを変更することなく、プルリクエストをレビューできます。

また、.nvmrc、.node-version、またはNODE_VERSIONを介してNode.jsのバージョンを明示的に設定します。これにより、ビルド環境の変更が予期せずデプロイを壊すのを防ぎます。(Pages Build Image)

5. SPA内にAPI全体を含めないでください

SPAは秘密鍵を必要とするサービスと直接通信すべきではありません。

安全でないアーキテクチャ：

SPA → 秘密鍵を使用した外部サービス

推奨されるアーキテクチャ：

SPA → WorkerまたはPages Function → 外部サービス

Workerは次のことができます：

• 受信データの検証
• 認証の確認
• レート制限の適用
• 資格情報の非表示
• レスポンスの正規化
• エラーのログ

Pages FunctionsはWorkersとして実行され、そのリクエストはWorkersのクォータにカウントされます。無料プランでは、結合されたクォータは1日あたり100,000リクエストです。(Pages Functions Pricing)

一般的でないヒント：すべてのためにFunctionsを呼び出さないでください

Pagesプロジェクトにルートを設定せずにFunctionを追加すると、静的ファイルのみを提供すべきリクエストに対して動的ロジックを実行してしまう可能性があります。

Functionが次のもののみに応答するようにルートを設定します：

/api/*

アセットは静的コンテンツのままにします。Cloudflareでは、包含ルートと除外ルートを定義して、Functionsを呼び出すリクエストを制御できます。(Pages Functions Routing)

6. デプロイの最後にカスタムドメインを使用する

まず、次の場所でアプリケーションをテストします：

my-app.pages.dev

次に、次の場所を接続します：

app.example.com

これにより、次のように簡単に分離できます：

app.example.com       → 本番環境
staging.example.com   → テスト
api.example.com       → API
assets.example.com    → 大容量ファイル

HTTPおよびHTTPSトラフィックにはCloudflareプロキシを有効にしますが、メールレコードなど、Webプロキシと互換性のないサービスはDNS-onlyのままにします。

7.オリジンとAPIを保護する

フロントエンドがPagesにあるがAPIが別のサーバーにある場合、そのオリジンも保護する必要があります。

推奨される対策：

• バックエンドのIPを不必要に公開しない。
• フロントエンドだけでなくAPIにも認証を適用する。
• CORSを検証する。
• /api/login、/api/register、/api/reset-passwordへのリクエストを制限する。
• 攻撃されたフォームでTurnstileを使用する。
• ユーザーをブロックする前にManaged Challengeを適用する。

Cloudflareのカスタムルールでは、ブロックやチャレンジなどのアクションを実行できます。無料プランでは数量と機能の制限があるため、重要なルートのために予約することをお勧めします。(Custom Rules)

8. Preview Deploymentsを活用する

小規模チームにとって最も有用な機能の1つは、プルリクエストごとにプレビューURLを持つことです。

推奨されるワークフロー：

プルリクエスト
   ↓
プレビューデプロイメント
   ↓
視覚的および機能的テスト
   ↓
本番環境にマージ

これは、次のものを検出できるため、SPAにとって特に重要です：

• 404を返すルート
• 欠落している環境変数
• CORSエラー
• モバイルでの壊れた変更
• キャッシュの問題
• 認証の失敗

一般的でないヒント

アプリケーションに環境を示す小さな視覚ラベルを含めます：

Preview · commit a81f2c

これにより、レビュー中にテストURLを本番環境と混同しなくなります。

9. 大容量ファイルにR2を使用する

SPAバンドルには、アプリケーションを実行するために必要なもののみを含める必要があります。

Pagesの外部に保持します：

• ユーザーがアップロードした画像
• 動画
• PDF
• プロジェクトファイル
• バックアップ
• 生成されたエクスポート

R2はオブジェクトストレージ用に設計されており、Workersまたは独自のAPIで使用できます。Cloudflareの現在のオファリングでは、無料プランにはR2のストレージと操作クォータが含まれています。(Cloudflare Plans)

シンプルなアーキテクチャは次のようになります：

SPA → Worker → R2

Workerは制御されたURLを生成し、バケットが完全にオープンなアクセスポイントにならないようにします。

10. 開発中の積極的なキャッシュを回避する

Cloudflareはフロントエンドファイルを長時間キャッシュできます。これは本番環境ではプラスですが、開発中はイライラする可能性があります。

問題を回避するために：

• CSSとJavaScriptにバージョン付きの名前を使用する。
• プライベートレスポンスをキャッシュしない。
• すべてをパージするのではなく、特定のURLをパージする。
• 急速な変更中はDevelopment Modeを使用する。
• CF-Cache-Statusを確認する。
• ブラウザキャッシュがCloudflareパージを生き残る可能性があることを覚えておく。

無料プランでは、上位のプランよりも低い制限で、Cache Rules、キャッシュパージ、キャッシュ分析が可能です。(Cache Features by Plan)

11. 監視すべきメトリクス

SPAの場合、訪問数を測定するだけでは不十分です。

次のものを観察します：

• メインJavaScriptの読み込み時間
• キャッシュされたレスポンスの割合
• 内部ルートの404エラー
• APIの4xxおよび5xxエラー
• Functionリクエスト
• Workersの1日あたりの使用量
• リクエストあたりのCPU時間
• 認証エラー率
• バンドルサイズ
• フォーム放棄率

無料のWorkersプランには、1日あたり100,000リクエスト、リクエストあたり10 msのCPU制限があります。小さな機能はうまく機能するかもしれませんが、画像を処理し、複雑なユーザーを認証し、重い計算を実行する機能はその制限を超える可能性があります。(Workers Limits)

開始するための推奨アーキテクチャ

Cloudflare DNS
      ↓
Cloudflare Pages
      ↓
静的SPA
      ↓
Pages Functions / Workers
      ↓
外部データベースまたはD1
      ↓
ファイル用のR2

MVPの場合、次のものから始めることができます：

• フロントエンド用のPages
• API用のWorkerまたはPages Function
• データベース用のSupabase、Neon、またはD1
• ファイル用のR2
• 重要なフォーム用のTurnstile
• 変更をレビューするためのPreview Deployments

結論

Cloudflareの無料プランは、静的ホスティング、CDN、HTTPS、カスタムドメイン、プレビュー、サーバーレス機能を組み合わせているため、SPAをデプロイする際に特に興味深いものです。

最も効率的な戦略は次のとおりです：

1. まずPagesにフロントエンドをデプロイする
2. SPAルートを正しく解決する
3. 公開変数をシークレットから分離する
4. 動的ロジックにのみFunctionsまたはWorkersを使用する
5. 大容量ファイルをR2に保存する
6. ログイン、登録、APIを保護する
7. 消費量、エラー、パフォーマンスを測定する
8. 実際の制限がある場合にのみスケールする

Cloudflareはバックエンド全体を自動的に置き換えるものではありませんが、モジュラーアーキテクチャで機能的で安全でかなり経済的なWebアプリケーションを構築できます。