Cloudflare Workers 入門：アカウント作成・プラン比較・開発環境構築ガイド

2026年6月27日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Cloudflare アカウント作成とプラン選択（Free と Pro の違い）
- 1.1 1️⃣ Free と Pro の基本情報
- 1.2 2️⃣ プラン選択の指針
2 対象ドメインの Cloudflare 追加と DNS 設定
- 2.1 1️⃣ ドメイン追加の概要
- 2.2 2️⃣ DNS レコードの具体的手順
  - 2.2.1 推奨 DNS レコード構成例
3 ローカル開発環境の構築：Node.js と Wrangler v2 のインストール
- 3.1 1️⃣ Node.js LTS の導入
- 3.2 2️⃣ Wrangler v2 のインストールとプロジェクト初期化
  - 3.2.1 生成されるディレクトリ構造（重要ファイル）
4 スクリプト作成とローカルテスト
5 デプロイ・運用ガイド（公開、シークレット管理、ログ取得、CI/CD）
6 まとめ

スポンサードリンク

Cloudflare アカウント作成とプラン選択（Free と Pro の違い）

Cloudflare Workers を本格的に利用するには、まず Cloudflare アカウントを取得し、使用したいプランを決定します。
Free プランは 小規模な検証や開発 に十分な機能が揃っており、Pro プランは 商用運用でのパフォーマンス向上と追加オプション が必要な場合に選択します。

1️⃣ Free と Pro の基本情報

項目	Free（無料）	Pro（月額 $20/アカウント）
リクエスト上限	100,000 リクエスト／日（約 3 M/月）。超過分は従量課金。	10 M リクエスト／月（超過分は従量課金）。
CPU 時間上限	最大 10 ms / リクエスト（1 日あたり合計 CPU 時間に制限あり）	最大 20 ms / リクエスト。Free に比べて余裕がある。
同時実行数 (Concurrency)	1000 リクエスト/秒程度のスパイクに対応（厳密な上限は非公開）。	同時実行数が増加可能で、ピーク時でも安定した処理が期待できる。
カスタムドメイン SSL	Universal SSL が自動付与され、`*.workers.dev` で利用可。	Dedicated SSL 証明書オプション（独自証明書のアップロードが可能）。
ページルール数	最大 5 件	最大 20 件
サポート	Community フォーラムのみ	Email & Chat による優先サポート

ポイント
- 「実行・デプロイは無制限に利用可能」という表現は誤解を招きます。デプロイ回数は無制限でも、リクエスト数と CPU 時間にはプラン別の上限があります。

2️⃣ プラン選択の指針

Free が適切なケース
PoC（概念実証）や個人ブログ、社内ツールなどリクエスト量が数十万程度に収まる場合。
カスタムドメインは workers.dev のサブドメインで十分。
Pro が推奨されるケース
月間リクエストが数百万以上、または CPU 集約型のロジックを実装する場合。
独自ドメインに Dedicated SSL を適用したいとき。
SLA に基づくサポートやページルールの増加が必要な大規模サイト。

対象ドメインの Cloudflare 追加と DNS 設定

Workers を利用するには、まず対象ドメインを Cloudflare に登録し、トラフィックを プロキシ（オレンジ雲） 経由で流す必要があります。ここでは、DNS の基本的な構成手順と注意点を解説します。

1️⃣ ドメイン追加の概要

Cloudflare のダッシュボードから「Add a Site」を選択し、ドメイン名を入力すると自動的に既存レコードがスキャンされます。プロキシ有効化だけで Workers が呼び出せるようになる ため、余計な設定は不要です。

2️⃣ DNS レコードの具体的手順

手順	内容
① Add a Site	ダッシュボード左上の「Add a Site」→対象ドメインを入力し「Begin Scan」。
② レコード確認	自動スキャン結果から、Web サーバーに必要な A または CNAME のみ残す。不要なレコードは削除または Cloudflare で無効化。
③ プロキシ設定	残したレコードの「Proxy status」を Proxied (オレンジ雲) に変更。これによりリクエストが Cloudflare のエッジへ転送され、Workers が介在できるようになる。
④ ネームサーバー更新	Cloudflare が提示する `ns1.cloudflare.com`・`ns2.cloudflare.com` をドメインレジストラ側で設定し、数分～数時間で反映させる。

推奨 DNS レコード構成例

種別	用途	設定例
A	IPv4 アドレス直指向	`example.com → 203.0.113.10`（Proxy: ON）
CNAME	サブドメインのエイリアス	`www → example.com`（Proxy: ON）
TXT (SPF/DKIM)	メール認証情報	変更不要、プロキシ設定は行わない
MX	メール配送先	変更不要、プロキシ設定は行わない

注意
- MX や TXT レコードは Proxy（オレンジ雲）を OFF にした状態 で運用してください。メールトラフィックが Cloudflare のエッジに乗らず、配信遅延や認証失敗のリスクが低減します。

ローカル開発環境の構築：Node.js と Wrangler v2 のインストール

Workers のローカル開発は Node.js（LTS） と公式 CLI ツール Wrangler があれば完了です。以下では主要 OS ごとのインストール手順と、プロジェクト雛形の生成方法を示します。

1️⃣ Node.js LTS の導入

OS	手順
Windows	公式サイト https://nodejs.org から LTS インストーラ（例: v20.x）をダウンロードし実行。インストール後 `node -v` と `npm -v` でバージョン確認。
macOS	Homebrew がある場合 `brew install node@20` Homebrew 未導入は公式インストーラを利用。
Ubuntu / Debian 系	`bash<br>curl -fsSL https://deb.nodesource.com/setup_20.x \| sudo -E bash -<br>sudo apt-get install -y nodejs<br>node -v<br>`

2️⃣ Wrangler v2 のインストールとプロジェクト初期化

# npm でグローバルにインストール（全 OS 共通）
npm i -g wrangler@latest   # v2 系が自動取得されます

# プロジェクト雛形作成例
mkdir my-worker &amp;&amp; cd my-worker
wrangler init --site       # 静的サイト用テンプレートを同時生成

# npm でグローバルにインストール（全 OS 共通）

npm i -g wrangler@latest # v2 系が自動取得されます

# プロジェクト雛形作成例

mkdir my-worker && cd my-worker

wrangler init --site # 静的サイト用テンプレートを同時生成

生成されるディレクトリ構造（重要ファイル）

my-worker/
├─ package.json          # npm パッケージ情報
├─ wrangler.toml         # Workers 設定（バンドル対象、環境変数など）
├─ src/
│  └─ index.js           # デフォルトハンドラ（エントリポイント）
└─ public/               # 静的アセット（必要に応じて配置）

my-worker/

├─ package.json # npm パッケージ情報

├─ wrangler.toml # Workers 設定（バンドル対象、環境変数など）

├─ src/

│ └─ index.js # デフォルトハンドラ（エントリポイント）

└─ public/ # 静的アセット（必要に応じて配置）

Tip
- wrangler.toml の name, compatibility_date は必ず設定してください。
- compatibility_date は「Workers がサポートする最新 API を保証する日付」で、例: 2024-06-01。

スクリプト作成とローカルテスト

ここでは シンプルなハンドラ と リバースプロキシ の2パターンを実装し、wrangler dev によるローカルテスト手順を紹介します。

1️⃣ シンプル HTTP ハンドラ例（30 行未満）

// src/index.js
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // /hello にアクセスしたら固定メッセージを返す
    if (url.pathname === &quot;/hello&quot;) {
      return new Response(&quot;Hello from Cloudflare Workers!&quot;, {
        headers: { &quot;content-type&quot;: &quot;text/plain&quot; },
      });
    }

    // それ以外は 404 Not Found
    return new Response(&quot;Not Found&quot;, { status: 404 });
  },
};

// src/index.js

export default {

async fetch(request, env, ctx) {

const url = new URL(request.url);

// /hello にアクセスしたら固定メッセージを返す

if (url.pathname === "/hello") {

return new Response("Hello from Cloudflare Workers!", {

headers: { "content-type": "text/plain" },

});

}

// それ以外は 404 Not Found

return new Response("Not Found", { status: 404 });

};

2️⃣ リバースプロキシ実装例（バックエンド転送）

// src/index.js
export default {
  async fetch(request, env) {
    // 環境変数からバックエンド URL を取得（後述の secret 管理で設定）
    const target = env.BACKEND_URL;   // 例: &quot;https://api.example.com&quot;

    const url = new URL(request.url);
    const upstream = `${target}${url.pathname}${url.search}`;

    const init = {
      method: request.method,
      headers: request.headers,
      body: request.body,
      redirect: &quot;manual&quot;,
    };

    const resp = await fetch(upstream, init);

    // 必要に応じてヘッダーを書き換える
    const newHeaders = new Headers(resp.headers);
    newHeaders.set(&quot;X-Proxy-By&quot;, &quot;Cloudflare Workers&quot;);

    return new Response(resp.body, {
      status: resp.status,
      statusText: resp.statusText,
      headers: newHeaders,
    });
  },
};

// src/index.js

export default {

async fetch(request, env) {

// 環境変数からバックエンド URL を取得（後述の secret 管理で設定）

const target = env.BACKEND_URL; // 例: "https://api.example.com"

const url = new URL(request.url);

const upstream = `${target}${url.pathname}${url.search}`;

const init = {

method: request.method,

headers: request.headers,

body: request.body,

redirect: "manual",

};

const resp = await fetch(upstream, init);

// 必要に応じてヘッダーを書き換える

const newHeaders = new Headers(resp.headers);

newHeaders.set("X-Proxy-By", "Cloudflare Workers");

return new Response(resp.body, {

status: resp.status,

statusText: resp.statusText,

headers: newHeaders,

});

};

3️⃣ ローカルテスト手順

# プロジェクトディレクトリで実行
wrangler dev

# プロジェクトディレクトリで実行

wrangler dev

起動後、http://localhost:8787/hello にアクセスするとハンドラのメッセージが表示されます。
リバースプロキシの場合はバックエンドサーバーへのリクエストが正しく転送されたか、ブラウザのデベロッパーツールや wrangler dev のコンソールで確認してください。

デバッグポイントまとめ

項目	方法
コンソール出力	`console.log()` → `wrangler dev` のターミナルに表示
リクエストヘッダー取得	`request.headers.get('Header-Name')`
エラーハンドリング例	`js<br>try { … } catch (e) { return new Response(e.message, {status: 500}); }<br>`

デプロイ・運用ガイド（公開、シークレット管理、ログ取得、CI/CD）

コードのテストが完了したら、本番環境へデプロイし、運用上必要な シークレット管理、リアルタイムログ取得、そして 自動デプロイパイプライン を構築します。

1️⃣ `wrangler publish` で本番デプロイ

# プロジェクトのルートで実行
wrangler publish

# プロジェクトのルートで実行

wrangler publish

成功すると CLI に ✅ Published と Workers の URL が表示されます。
デフォルトは production 環境 にデプロイされ、<your-subdomain>.workers.dev でアクセス可能です。

デプロイ後の確認

ブラウザで <your-subdomain>.workers.dev/hello を開く。
Cloudflare Dashboard → Workers → Logs タブでもリクエストがリアルタイムに流れているか確認。

2️⃣ シークレット（環境変数）管理のベストプラクティス

2‑1️⃣ 正しいコマンド例

# シークレットを対話式で追加（プロンプトに入力）
wrangler secret put BACKEND_URL   # ← 名前は大文字＋アンダースコアが推奨

# GitHub Actions 等 CI から自動投入したい場合
echo &quot;$BACKEND_URL&quot; | wrangler secret put BACKEND_URL --env production

# シークレットを対話式で追加（プロンプトに入力）

wrangler secret put BACKEND_URL # ← 名前は大文字＋アンダースコアが推奨

# GitHub Actions 等 CI から自動投入したい場合

echo "$BACKEND_URL" | wrangler secret put BACKEND_URL --env production

コード側での参照方法（src/index.js）

// env オブジェクト経由で取得
const target = env.BACKEND_URL;   // 先ほど登録したシークレット名と同一

// env オブジェクト経由で取得

const target = env.BACKEND_URL; // 先ほど登録したシークレット名と同一

2‑2️⃣ 管理上の注意点

項目	推奨設定
命名規則	大文字・アンダースコア（例: `API_TOKEN`, `DB_PASSWORD`）
環境分離	本番とステージングは別プロジェクトまたは `--env` オプションで分け、シークレットも個別に保持
最小権限	Cloudflare API トークンは Workers Scripts + Account Settings のみ付与し、不要な権限は除外

3️⃣ リアルタイムログ取得とデバッグ

方法	コマンド例・操作
Dashboard	Workers → 対象スクリプト → Logs タブでフィルタリング。
wrangler tail（CLI）	`wrangler tail` （production がデフォルト）。環境指定は `--env staging` など。
ログレベル設定	`wrangler.toml` の `[triggers]` 配下に `log_level = "info"` 等を記述可能。

ポイント
- console.error() や console.warn() は自動的に wrangler tail に流れるので、エラー原因の特定に有効です。

4️⃣ GitHub Actions を用いた自動デプロイ例

以下は main ブランチへのプッシュ 時に Workers を自動でビルド・シークレット注入・デプロイする最小構成です。

# .github/workflows/deploy.yml
name: Deploy Cloudflare Worker

on:
  push:
    branches: [ main ]

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

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '20'   # LTS を指定

      - name: Install Wrangler
        run: npm i -g wrangler@latest

      - name: Inject secret and publish
        env:
          CF_API_TOKEN: ${{ secrets.CF_API_TOKEN }}   # GitHub Secrets に保存した Cloudflare API Token
          BACKEND_URL: ${{ secrets.BACKEND_URL }}     # バックエンド URL も同様に管理
        run: |
          echo &quot;$BACKEND_URL&quot; | wrangler secret put BACKEND_URL --env production
          echo &quot;$CF_API_TOKEN&quot; | wrangler secret put CF_API_TOKEN --env production
          wrangler publish --env production

# .github/workflows/deploy.yml

name: Deploy Cloudflare Worker

on:

push:

branches: [ main ]

jobs:

deploy:

runs-on: ubuntu-latest

steps:

- name: Checkout repository

uses: actions/checkout@v4

- name: Set up Node.js

uses: actions/setup-node@v3

with:

node-version: '20' # LTS を指定

- name: Install Wrangler

run: npm i -g wrangler@latest

- name: Inject secret and publish

env:

CF_API_TOKEN: ${{ secrets.CF_API_TOKEN }} # GitHub Secrets に保存した Cloudflare API Token

BACKEND_URL: ${{ secrets.BACKEND_URL }} # バックエンド URL も同様に管理

run: |

echo "$BACKEND_URL" | wrangler secret put BACKEND_URL --env production

echo "$CF_API_TOKEN" | wrangler secret put CF_API_TOKEN --env production

wrangler publish --env production

CI 用シークレットの作り方

Cloudflare Dashboard → My Profile → API Tokens で「Edit Cloudflare Workers」権限だけを持つトークンを生成。
GitHub リポジトリ > Settings > Secrets and variables > Actions に CF_API_TOKEN と BACKEND_URL を登録。

5️⃣ 運用時に気を付けるべき項目

項目	注意点
リクエスト量の監視	ダッシュボードの Analytics → Requests で日次・月次利用状況を定期的にチェック。Free の上限超過は従量課金になるのでアラート設定が必須。
CPU 時間超過エラー	`Error: CPU time limit exceeded` が出たら、ロジックの最適化（キャッシュ活用、外部 API 呼び出し回数削減）を検討。
シークレット漏洩防止	ソースコードに平文を書かない。CI で注入する際は標準入力 (`<<<`) 経由で渡すことでログに残らないようにする。
バージョン管理	`wrangler.toml` の `compatibility_date` を更新し続けると、将来の API 変更による破壊的影響を防げます。

まとめ

Free プランは日次 100,000 リクエスト（約 3 M/月）・CPU 時間 10 ms/リクエスト が上限です。小規模検証や開発には十分です。
Pro プランはリクエスト上限 10 M、CPU 時間 20 ms、同時実行数増加、Dedicated SSL などの追加機能 が提供されます。商用運用ではこちらを選択するのが安全です。
ドメイン登録後は DNS のプロキシ設定だけで Workers が利用可能 になるため、特別なネットワーク構成は不要です。
開発環境は Node.js LTS + Wrangler v2 があればすぐに始められます。wrangler init が作る雛形をベースに実装し、wrangler dev でローカルテストしてください。
本番デプロイは wrangler publish、シークレットは wrangler secret put <NAME> --env production で安全に管理し、wrangler tail や Dashboard の Logs でリアルタイム監視を行います。
CI/CD（例: GitHub Actions）と組み合わせれば コード変更 → テスト → デプロイ が自動化され、ヒューマンエラーが大幅に削減できます。

この手順通りに進めば、Cloudflare Workers の導入から本番運用までをスムーズに実現できるはずです。ぜひ実際のプロジェクトで試してみてください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Cloudflare

comment コメントをキャンセル

: Cloudflare

Zero TrustとSASEの最新概念とCloudflare One徹底解説（2026年版）

本稿では、Zero Trust と SASE の最新定義を紹介し、Cloudflare One のサービス構成・料金体系を詳細に説明。従来型SASEベンダーとの比較や実際の導入事例、VPN 置換手順も網羅しています。

: Cloudflare

Cloudflare Registrar 登録ガイド｜初心者向け2026年最新版

Cloudflare Registrarのドメイン検索・アカウント作成からSSL設定・DNS連携までの2026年最新版ガイド。個人事業主やWeb制作初心者向けに手順を網羅しています。

: Cloudflare

Cloudflare WorkersのアーキテクチャとV8 Isolate、WASM・Pyodide活用事例

本稿では、Cloudflare Workersが世界規模のエッジネットワークとV8 Isolateで低レイテンシを実現する方法、WASM と Pyodide を用いたマルチランゲージ環境、実際の導入事例と他社サービスとの比較ポイントをまとめます。

: Cloudflare

Cloudflare R2 と Amazon S3 の料金比較とコストシミュレーション – イグレス費用ゼロの優位性

クラウドストレージの選定では、保存料・リクエスト料・データ転送料の３要素を正確に把握することが第一歩です。

: Cloudflare

Cloudflare WARP 接続不安定の原因と対策完全ガイド

本記事では、Cloudflare WARP の接続不安定な状態を症状別に把握し、頻度測定方法や OS・ネットワークの基本チェック、Zero Trust の設定確認、ローカルのファイアウォールや MTU 調整手順、さらに Docker や ARM 環境での注意点とベンチマーク手法までを体系的に解説します。

育児ノートで夫婦の情報共有を効率化する方法

2026年ホットペッパーグルメ新機能と中小飲食店への影響

Cloudflare Workers 入門：アカウント作成・プラン比較・開発環境構築ガイド

Cloudflare アカウント作成とプラン選択（Free と Pro の違い）

1️⃣ Free と Pro の基本情報

2️⃣ プラン選択の指針

対象ドメインの Cloudflare 追加と DNS 設定

1️⃣ ドメイン追加の概要

2️⃣ DNS レコードの具体的手順

推奨 DNS レコード構成例

ローカル開発環境の構築：Node.js と Wrangler v2 のインストール

1️⃣ Node.js LTS の導入

2️⃣ Wrangler v2 のインストールとプロジェクト初期化

生成されるディレクトリ構造（重要ファイル）

スクリプト作成とローカルテスト

1️⃣ シンプル HTTP ハンドラ例（30 行未満）

2️⃣ リバースプロキシ実装例（バックエンド転送）

3️⃣ ローカルテスト手順

デバッグポイントまとめ

デプロイ・運用ガイド（公開、シークレット管理、ログ取得、CI/CD）

1️⃣ wrangler publish で本番デプロイ

デプロイ後の確認

2️⃣ シークレット（環境変数）管理のベストプラクティス

2‑1️⃣ 正しいコマンド例

2‑2️⃣ 管理上の注意点

3️⃣ リアルタイムログ取得とデバッグ

4️⃣ GitHub Actions を用いた自動デプロイ例

CI 用シークレットの作り方

5️⃣ 運用時に気を付けるべき項目

まとめ

1️⃣ `wrangler publish` で本番デプロイ