2025年に静的サイトをCloudflare Workersにデプロイする方法

Fred· AI Engineer & Developer Educator2 min read

最終テスト日: 2025年10月 | Wrangler: 3.x | Node.js: 20+ | プラットフォーム: macOS/Linux/Windows

Git統合経由でCloudflare Pagesにデプロイしていた方は、新しい非推奨メッセージに気付いたかもしれません：Cloudflareは2025年4月にPagesを非推奨にしました。 彼らはすべての人をCloudflare Workersにプッシュしています。

最初、これは面倒に聞こえます。Pagesは非常にシンプルでした—リポジトリを接続し、ビルドコマンドを設定すれば完了。Workers？サーバーレス関数を書いてエッジコンピューティングを理解する必要があるように聞こえます...はい、どこから始めればいいかわからないと威圧的になりえます。

良いニュースがあります：ワークフローを理解すれば、静的サイトをWorkersにデプロイするのは簡単です。 そして、その過程でデプロイメントに対するより多くのコントロールを得られます。

私は自分のGatsbyブログを古いPagesフローからWorkersに移行しました。学んだすべてをお伝えします。

完全な移行パス

このガイドでは、静的サイトをWorkersに移行する正確な手順を提供します：

  • 実際の本番サイトでテストされた動作するコード例
  • 一般的な落とし穴とその回避方法
  • パフォーマンス比較 Workersがより高速であることを示す
  • コスト分析（ネタバレ：ほとんどのサイトで無料のまま）

なぜCloudflareはPagesを終了したのか

Cloudflareの理由は非常に明確です：Workersはエッジコンピューティングの統一プラットフォームです。2つの別々のシステム（静的サイト用のPages、関数用のWorkers）を維持する代わりに、すべてをWorkersに統合しています。 CloudflareがPagesデプロイメントを完全に廃止するまで数年かかるかもしれませんが、Workersがすべての新機能を取得し、積極的にサポートされます。Pagesはそうではありません。

新しいプロジェクトを開始するか、既存のプロジェクトを移行する場合、Workersが唯一の道です。強調しておきます：新しいプロジェクトをCloudflare Pagesにデプロイすることはお勧めしません。

必要なもの

始める前に、以下があることを確認してください：

  1. 静的サイト（Gatsby、Next.js静的エクスポート、Reactビルド、Hugo、Astro）
  2. Node.js 20+ がインストールされている
  3. Cloudflareアカウント（無料ティアで十分）
  4. Wrangler CLI（これからインストールします）

ステップ1：Wranglerのインストール

WranglerはCloudflareのWorkersへのデプロイ用コマンドラインツールです。プロジェクトに追加します：

npm install -D wrangler

またはグローバルにインストールする場合：

npm install -g wrangler

チームが同じバージョンを使用するように、プロジェクトの開発依存関係としてインストールすることをお勧めします。

ステップ2：Wranglerの認証

デプロイする前に、WranglerをCloudflareアカウントに接続する必要があります：

npx wrangler login

これはブラウザを開き、Wranglerを承認するよう求めます。「許可」をクリックすれば設定完了です。

CI/CDの場合、代わりにAPIトークンが必要です（後で説明します）。

ステップ3：wrangler.tomlの作成

Wranglerにはプロジェクトのルートに設定ファイルが必要です。wrangler.tomlを作成します：

name = "your-project-name"
compatibility_date = "2025-10-19"

# これはWranglerに静的ファイルの場所を伝えます
pages_build_output_dir = "public"

[site]
bucket = "./public"

主要なフィールド：

  • name：プロジェクト名（WorkersのURLの一部になります）
  • compatibility_date：Workersランタイムバージョンをロック
  • pages_build_output_dir：ビルド後の静的ファイルの場所
  • bucket：同じもの、異なる構文（両方機能します）

Gatsbyサイトの場合、出力ディレクトリはpublicです。Next.jsの場合はoutです。Create React Appの場合はbuildです。

ステップ4：サイトのビルド

ここは何も変わりません。通常のビルドコマンドを実行します：

# Gatsby
npm run build

# Next.js（静的エクスポート）
npm run build && npm run export

# Create React App
npm run build

これにより、出力ディレクトリに静的ファイルが生成されます。

ステップ5：Workersへのデプロイ

マジックコマンドはこちらです：

npx wrangler pages deploy public

publicを出力ディレクトリに置き換えてください。

初回デプロイ？ Wranglerが尋ねます：

✔ Enter the name of your new project: … your-site-name
✔ Enter the production branch name: … main

その後、Wranglerがサイトをビルドしてデプロイします。次のようなURLが得られます：

https://your-site-name.pages.dev

はい、Workers経由でデプロイしても.pages.devドメインを使用します。Cloudflareは静的サイト用にその命名を維持しました。

ステップ6：package.jsonにデプロイスクリプトを追加

毎回npx wrangler pages deploy publicと入力するのは面倒です。package.jsonにスクリプトを追加します：

{
  "scripts": {
    "build": "gatsby build",
    "deploy": "npm run build && wrangler pages deploy public",
    "deploy:prod": "npm run build && wrangler pages deploy public --branch=main"
  }
}

これでデプロイは：

npm run deploy

ステップ7：カスタムドメインの設定

.pages.dev URLは機能しますが、おそらく独自のドメインが欲しいでしょう。

オプション1：Cloudflareダッシュボード経由（最も簡単）

最初のデプロイが成功したら、カスタムドメインを追加します：

  1. https://dash.cloudflare.comでCloudflareダッシュボードにログイン
  2. 左サイドバーでWorkers & Pagesをクリック
  3. プロジェクト（例：vibe-coding-redo）を見つけてクリック
  4. 上部のCustom domainsタブをクリック
  5. Set up a custom domainボタンをクリック
  6. ドメインを入力（例：vibecodingwithfred.com）
  7. Continueをクリック
  8. 必要に応じてwwwサブドメイン用に別のドメインを追加（例：www.vibecodingwithfred.com）
  9. Activate domainをクリック

重要な注意：

  • ドメインはすでにCloudflare DNSにある必要があります（ない場合は、まずCloudflareに追加してください）
  • SSL証明書は自動的にプロビジョニングされます（通常1〜2分かかります）
  • DNSレコードは自動的に作成されます
  • ドメインが以前に別のPages/Workersプロジェクトで使用されていた場合、Cloudflareは自動的に移動します

ステップ8：GitHub Actionsによる自動デプロイ

古いPagesフローはmainにプッシュすると自動デプロイしました。GitHub Actionsでこれを再現できます。

.github/workflows/deploy.ymlを作成します：

name: Deploy to Cloudflare Workers

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build site
        run: npm run build

      - name: Deploy to Cloudflare Workers
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=your-project-name

Cloudflare認証情報の取得

2つのものが必要です：

1. アカウントID：

  • Cloudflareダッシュボードに移動
  • Workers & Pagesをクリック
  • アカウントIDは右サイドバーにあります

2. APIトークン：

  • My Profile → API Tokensに移動
  • Create Tokenをクリック
  • **「Edit Cloudflare Workers」**テンプレートを使用
  • トークンをコピー（一度しか表示されません！）

GitHubにシークレットを追加

リポジトリ → Settings → Secrets and variables → Actions → New repository secretに移動

追加：

  • CLOUDFLARE_API_TOKEN：あなたのAPIトークン
  • CLOUDFLARE_ACCOUNT_ID：あなたのアカウントID

これでmainへのプッシュのたびに自動的にデプロイがトリガーされます。

一般的な問題と修正

問題1：依存関係の競合

Pagesから移行してnpmエラーが発生した場合：

npm error ERESOLVE could not resolve

プロジェクトルートに.npmrcを作成します：

legacy-peer-deps=true

これはnpmにピア依存関係の競合を無視するよう伝えます（古いGatsbyプラグインでよく見られます）。

問題2：Nodeバージョンの不一致

Workersはデフォルトでnode 20+を使用します。プロジェクトが特定のバージョンを必要とする場合、ロックします：

.nvmrcを作成：

20

および.node-version：

20

package.jsonを更新：

{
  "engines": {
    "node": ">=18.0.0 <=20.x"
  }
}

問題3：ビルド出力ディレクトリが間違っている

Wranglerがファイルを見つけられない場合：

✖ No such directory 'public'

wrangler.tomlを確認し、pages_build_output_dirが実際のビルド出力と一致していることを確認してください。

問題4：CI/CDで認証が失敗する

GitHub Actionsが認証エラーで失敗する場合、再確認してください：

  1. APIトークンにEdit Cloudflare Workers権限がある
  2. CLOUDFLARE_API_TOKENとCLOUDFLARE_ACCOUNT_IDの両方をシークレットとして追加した
  3. トークンが期限切れになっていない

古いPagesからのゼロダウンタイム移行

古いPagesセットアップから移行する場合：

戦略1：新しいWorkersプロジェクトにデプロイ

  1. 異なるプロジェクト名でWorkersデプロイをセットアップ
  2. .pages.devプレビューURLでテスト
  3. 準備ができたら、新しいプロジェクトにカスタムドメインを追加
  4. Cloudflareは自動的にドメインを古いから新しいに移動（即時切り替え）
  5. 古いPagesプロジェクトを削除

戦略2：段階的ロールオーバー

  1. 古いPagesデプロイを実行したまま
  2. ステージングドメインでWorkersにデプロイ
  3. 徹底的にテスト
  4. DNSをWorkersに向けるよう更新
  5. すべてが機能することを確認した後、Pagesを非推奨に

推奨： 戦略1の方がクリーンで、ダウンタイムがありません。

結論

Cloudflareが Pagesを終了してすべての人をWorkersに強制するのは、最初は後退のように感じます。GitベースのAutoデプロイは本当に便利でした。

しかし、WranglerとCI/CDをセットアップすると、以下が得られます：

  • 完全なコントロール いつどのようにデプロイするか
  • より高速なデプロイ（Cloudflareのビルドキューを待つ必要なし）
  • より良いデバッグ（デプロイ前にローカルでビルドをテストできる）
  • Workers機能へのアクセス（関数、KVストレージ、エッジロジック）

初期セットアップには20分かかります。その後はgit pushだけでGitHub Actionsが残りを処理します—Pagesと同じ体験ですが、より多くのパワーがあります。

そして、静的サイトにサーバーレス関数やエッジロジックを追加する準備ができたら、すでに適切なプラットフォームにいます。

関連ガイド

Workersにデプロイする前に、Cloudflareのセットアップが完了していることを確認してください：

Fred

Fred

AUTHOR

Full-stack developer with 10+ years building production applications. I've been deploying to Cloudflare's edge network since Workers launched in 2017.

Need a developer who gets it?

POC builds, vibe-coded fixes, and real engineering. Let's talk.

Hire Me →