
こんにちは。Osukeラーニング、運営者の「osuke」です。
Cloudflare Workersを公開したあと、「無料枠は月に何件まで使えるのか」「Paidは月5ドルを払えば使い放題なのか」「急にアクセスが増えて高額請求にならないか」と気になっていませんか。料金表だけを見ると安く感じますが、無料枠と有料プランでは集計期間が違い、Paidではリクエスト数とCPU時間が別々に課金されます。
結論からいうと、Workers Freeは1アカウントにつき1日100,000リクエスト、1実行10msのCPU時間が基本です。Paid Standardは最低月額5ドルで、月1,000万リクエストと3,000万CPU msを含み、超過分を二軸で計算します。さらにD1、R2、KVなどを接続すれば、それぞれの保存量・読み書きも別に確認しなければなりません。
この記事はosuke本人のWorkers利用体験としては書かず、2026年8月25日時点のCloudflare公式料金資料と、Xで公開された8件の上限到達、CPU実測、無料運用、複合構成を照合しました。Xの結果は投稿者の環境に限られます。Workersの作成と公開がまだの方はCloudflareのWorkers入門、サービス全体を確認したい方はCloudflareとは何かを解説した記事から読むと理解しやすくなります。
料金や含有量は更新されるため、契約前の最終判断はCloudflare管理画面のBilling、公式Pricing、実際のinvoiceを優先してください。Enterprise契約は個別条件があるため担当者へ確認し、日本での税込請求額や為替手数料はカード会社・決済手段の明細で確定します。
記事のポイント
- Freeの10万件は月間ではなく1日単位で判定される
- Paidは月5ドルにリクエストとCPUの超過料金が加わる
- Static AssetsとWorkers Cacheではリクエスト課金が違う
- D1・R2・KVはWorkers本体とは別のメーターを持つ
- Budget alertは通知だけで利用を自動停止しない
Cloudflare Workersの料金と無料枠
Workersの料金は、まずFreeとPaidの集計方法を分けると理解できます。Freeは日次上限に達すると処理が失敗する停止型、Paidは月間の含有量を超えると従量課金が増える超過課金型です。この章ではリクエスト、CPU時間、最低月額、実際の計算式を順に整理します。
Workers Freeで無料になる範囲を知る
Cloudflare公式のWorkers Limitsによると、Freeは1アカウントにつき1日100,000リクエスト、1回のHTTPリクエストで10msのCPU時間、128MBのメモリを利用できます。外部へのsubrequestは1実行50件、Worker数は1アカウント100個です。個人のAPI、リダイレクト、小規模Webアプリを試すには広い範囲ですが、すべてが無制限になるわけではありません。
特に注意したいのは、100,000件が月間枠ではなく日次枠であることです。上限は毎日00:00 UTCにリセットされ、日本時間では午前9時です。30日で単純計算すれば最大300万件に見えますが、ある1日に150,000件、残り29日がゼロでも、その日の100,000件を超えた時点で制限対象になります。前日分の未使用枠を翌日へ繰り越すことはできません。
Freeの日次リクエスト上限を超えると、WorkerはError 1027を返します。Routeではfail openを選びWorkerを迂回して既存オリジンへ通すか、fail closedを選びエラーで止めるかを設定できます。認証、アクセス制御、署名検証のようにWorkerを通らないと危険な処理はfail closed、装飾的なヘッダー追加などはfail openを検討します。無料枠は「請求されない代わりに止まり得る枠」と理解してください。
- 100,000 inbound requests / day
- CPU 10ms / invocation
- Memory 128MB
- 外部subrequests 50件 / invocation
- リセットは00:00 UTC、日本時間午前9時
1日10万リクエストの数え方を確認する
Workersで数えるのは、外部からWorkerへ入ったinbound requestです。Workerの中からfetch()で外部APIやCloudflareサービスを呼ぶsubrequestは、Workers本体のrequest課金では別の1リクエストとして加算されません。ただし、D1のrows read、R2のClass B operation、KVのkey readなど、呼び出したサービス側の利用量は別に増えます。「subrequestが無料」ではなく「Workersのinbound request数へ二重加算しない」という意味です。
WebSocketは最初のUpgrade接続が1リクエストとして数えられ、その接続上を流れるメッセージはWorkers requestへ加算されません。反対に、通常のHTTP pollingを5秒ごとに行えば、利用者1人で1時間720リクエストです。100人が同時に1時間使えば72,000件となり、日次100,000件へ近づきます。リアルタイム機能では画面表示回数より通信方式が利用量を左右します。
WAFなどCloudflareのセキュリティ機能でWorker実行前に遮断された通信は、Workers MetricsのTotal requestへ数えられません。一方、ボットがWorkerまで届き、404を返した場合でもinbound requestです。無料枠はアカウント単位なので、複数WorkerやPages Functionsを運用するときは1サービスだけを見ず、アカウント全体の利用状況を確認します。公開URLを無制限に巡回されないよう、不要なRouteやAPI endpointも閉じてください。
- ブラウザからWorkerへ1回アクセス: 1 request
- そのWorkerが外部APIを3回fetch: Workers requestは追加0件
- WebSocket接続後に100メッセージ: Workers requestは最初の1件
- 存在しないURLへボットがアクセス: Workerまで届けば1件
CPU時間10msの意味を理解する
CPU時間は、Workerが計算に使った時間です。外部APIの応答、D1やKVの読み込み、ネットワークI/Oを待っているwall timeとは異なります。単純なJSON返却は短時間でも、巨大なJSONの解析、暗号化、画像処理、長いループ、サーバーサイドレンダリング、すべてのリクエストで行う認証更新はCPUを消費します。Freeでは平均値ではなく、各invocationの10ms上限を意識します。
Xでは、AA氏が24時間に無料枠のCPU limitへ1,000回以上達したと報告しています。また、Florian Baraz氏は全リクエストでSupabase認証を更新するmiddlewareを置き、ボット巡回でも処理が走ってCPU limit後にサイトが停止した流れを公開しました。総アクセスが少なくても、1回当たりの処理が重ければCPU側へ先に当たります。
ma2no4413氏の実測では、Freeの10msを超えるように見える処理が通り、2億回の純粋計算で1102になったと報告されています。公式Metrics資料も、短い処理から繰り越されるrollover CPU timeにより、グラフの高いquantileが上限を超えて見えても失敗しない場合があると説明しています。ただしこれは保証枠ではありません。観測上の余裕を前提に設計せず、1102が出る前に処理を小さくします。
- 大きな配列・JSONの全件走査
- 全アクセスで行う認証更新
- 重い暗号化・圧縮・画像変換
- SSRと多数のテンプレート処理
- ボットにも同じmiddlewareを実行する設計
Paidは月5ドルから始まる
Cloudflare公式Pricingでは、Workers Paid Standardはアカウント当たり最低月額5 USDです。月1,000万リクエストと3,000万CPU msを含み、超過リクエストは100万件当たり0.30 USD、超過CPUは100万CPU ms当たり0.02 USDです。CPUは既定30秒、設定により1実行最大5分まで引き上げられます。金額はUSDで、税、決済会社の為替レート、海外事務手数料は利用者ごとに異なります。
| 項目 | Workers Free | Paid Standard |
|---|---|---|
| 基本料金 | 0 USD | 最低5 USD / month |
| Requests | 100,000 / day | 10M / month込み、超過0.30 USD / 1M |
| CPU | 10ms / invocation | 30M CPU ms込み、超過0.02 USD / 1M CPU ms |
| CPU上限 | 10ms | 既定30秒、最大5分 |
| Memory | 128MB | 128MB |
| 超過時 | 停止・エラー | 従量課金 |
Xでは、Azure Kamsaki oSushi氏がFree 10万件/日、Paid 5ドル、1,000万リクエスト、3,000万CPU msを整理し、料金の小ささに注目しています。数値は公式資料と一致しますが、5ドルは上限額ではなく最低額です。月1,000万件以内でもCPU総量が3,000万msを超えればCPU超過分が発生し、逆にCPUが軽くても1,000万件を超えればrequest超過分が発生します。
Workers Paidは、ドメインに設定するCloudflare Free、Pro、Businessとは別のプランです。サイトをProへ上げたからWorkers Paidの含有量が自動で付くわけではなく、Workers Paidへ加入してもProのWAF機能が付くわけではありません。Paid本体にはWorkers、Pages Functions、KV、Hyperdrive、Durable Objectsの一定利用量が含まれますが、各サービスには独自の超過単価があります。契約画面で対象アカウントを確認してください。
- アカウント当たりの最低月額
- 1,000万requestsと3,000万CPU msを含む
- 両方を別々に超過計算する
- ドメイン側のFree・Pro・Businessとは別契約
- 接続サービスの超過利用は別に加算される
超過料金を計算する
Paidの概算は、月額5ドルにrequest超過とCPU超過を足します。request超過は「月間inbound requestsから1,000万件を引き、100万件で割って0.30ドルを掛ける」、CPU超過は「月間CPU msから3,000万msを引き、100万msで割って0.02ドルを掛ける」です。どちらも含有量以下なら、その項目の超過料金は0ドルです。
Monthly cost =
5 USD
+ max(0, requests - 10,000,000) / 1,000,000 × 0.30 USD
+ max(0, CPU_ms - 30,000,000) / 1,000,000 × 0.02 USD
公式例では、月1,500万リクエスト、平均CPU 7msのWorkerは、基本5ドル、request超過1.50ドル、CPU超過1.50ドルで合計8ドルです。CPU総量は1,500万×7msで1億500万msとなり、含有3,000万msを引いた7,500万msが課金対象です。「平均7msならFreeの10ms以内だからCPU料金も無料」という計算にはなりません。Freeの1実行上限とPaidの月間含有量は別の概念です。
別の公式例では、1時間に1回実行するCronが月720回、1回180,000msのCPUを使うと、requestsは含有量内でもCPU超過により月6.99ドルです。回数が少ないバッチでも、集計、変換、レポート生成が重ければCPU料金が中心になります。見積もりにはアクセス数だけでなく、Workers Metricsで観測した平均CPUと高いquantileを使い、繁忙日の余裕を加えてください。
- 15M requests・平均7ms: 8.00 USD / month
- 720 Cron executions・各180秒CPU: 6.99 USD / month
- 100M requests・平均7ms: 45.40 USD / month
- 日本円は固定せず、請求日の為替と税を確認
Cloudflare Workersの課金を抑える方法
料金を抑えるには、単にキャッシュをONにするのではなく、何が無料のStatic Assetsで、何がWorker invocationとして数えられるかを分けます。さらにD1、R2、KVの利用量を同じ請求画面で追い、通知とCPU上限を用意します。この章では公式料金例を運用判断へ変換します。
Static AssetsとWorkers Cacheを区別する
Cloudflare公式のStatic Assets料金資料では、静的ファイルに一致してAssetsから直接返るリクエストは無料・無制限で、Assetsを保存する追加費用もありません。HTML、CSS、JavaScript、画像を静的配信し、問い合わせやAPIだけをWorkerへ送る構成なら、全ページ表示をWorkerでSSRするよりWorkers requestとCPUを減らせます。
一方、Workers Cacheでcache hitした通信はWorkers requestとして数えられます。cache hitではWorker codeが動かないためCPUは減りますが、request超過は消えません。公式の月1億リクエスト・平均7ms例では、キャッシュなしが45.40ドル、80% cache hitで34.20ドルです。request料金27ドルは同じで、CPU料金だけが13.40ドルから2.20ドルへ下がります。
Static Assetsの公式例では、月1,500万アクセスの80%に当たる1,200万件をAssetsから直接返し、残る300万件だけがWorkerを呼ぶ場合、合計は最低月額5ドルです。似た80%でも課金結果が違うのは、Assetsへの直接一致とWorkers Cache hitが別だからです。run_worker_firstを広く設定するとAssetsより先にWorkerが動き、無料枠超過後は429になり得るため、Workerが必要なpathだけへ絞ります。
- Static Assetsへ直接一致: request無料・無制限
- Workerが実行: requestとCPUの対象
- Workers Cache hit: request対象、CPUは原則減る
- SSR・run_worker_first: 静的に見えてもWorker対象になり得る
D1・R2・KVの別料金を確認する
Workers本体が月5ドル以内でも、接続したデータサービスの利用量は別に増えます。D1はrows read・rows written・storage、R2はstorage・Class A・Class B operations、KVはkey read・write・delete・list・storageを数えます。WorkerからD1を1回呼んだだけでも、indexがなく全表走査すれば、返却した10行ではなく走査した何千・何万行がrows readになる場合があります。
| サービス | Freeの主な含有量 | 増えやすい操作 |
|---|---|---|
| D1 | 5M rows read/day、100K written/day、5GB | indexなしのfull scan、一括更新 |
| R2 Standard | 10GB-month、Class A 1M、Class B 10M/month | 大量の一覧・read、細かいwrite |
| KV | 100K read/day、1K write/day、1GB | 存在しないkeyの反復read、頻繁なwrite |
| Queues | 10K operations/day | write・read・deleteとretry |
Xでは、Jason Szesze氏がWorkers、R2 cache、D1 analytics、Static Assetsなどで1つのサービスを構築した例を公開しています。また、Saïd Aitmbarek氏はWorkers・D1・R2への統合でクラウド請求を90%減らせる見込みを投稿しました。後者は実験中の予測で実測ではありません。複合構成は管理先を減らせても、請求メーターが1つになるわけではありません。
Cloudflare Developersは2026年2月にQueues Freeへ1日10,000 operationsを追加したと発信しました。周辺サービスの無料枠は拡張される一方、料金単位や含有量も更新されます。古い料金まとめを固定資料にせず、月1回、Workers Pricingと利用中サービスの公式Pricingを開きます。特に「egress無料」を「storageやoperationsも無料」と読み替えないでください。
- Workers: inbound requests + CPU ms
- D1: rows read/write + storage
- R2: storage + Class A/B operations
- KV: key operations + storage
- 外部AI・DB・メールAPIの料金も別に加算
無料運用に向くアプリを判断する
Freeに向くのは、アクセスが小さく予測しやすい個人サイト、ポートフォリオ、学習用API、低頻度のWebhook、静的配信が中心の小規模アプリです。Xでは、たいち氏が予約管理付き自社ホームページをCloudflare無料枠で「運営費ほぼ0円」とする事例記事を公開しています。小規模サイトでは成立し得ますが、独自ドメイン、開発工数、外部予約・メール・AI APIまでゼロとは限りません。
無料運用を続ける判断では、平均ではなく直近7日間の最大日次requestsとCPUエラーを見ます。本記事の安全側の目安として、最大日次が50,000件未満、CPUの高いquantileが5ms前後、Exceeded Resourcesがゼロなら、Free上限の半分程度に余裕があります。これはCloudflare公式基準ではなく、アクセス急増やボット巡回に備える運用上の目安です。公開キャンペーン前には再計算してください。
Paidを検討する合図は、上限へ一度達してからではありません。日次requestsが70,000件を継続する、CPU 10ms付近が増える、FreeのD1/KV上限で書き込みが止まる、顧客が使うサービスでfail closed停止を許容できない、CronやSSRなど1回の処理を長くしたい場合です。月5ドルと停止時の損失を比べ、売上、問い合わせ、予約、業務処理に関わるなら早めにPaidへ移します。
- 静的配信が中心
- 最大日次requestsが上限の半分程度
- CPU 1102・daily 1027がゼロ
- D1・R2・KVの無料枠にも余裕
- 停止しても業務・売上への影響が小さい
Metricsと請求画面を毎週見る
Workers & Pagesで対象Workerを開くと、requests、success、errors、subrequests、CPU time、wall time、memoryなどを確認できます。TotalだけでなくErrorsからExceeded Resourcesを見て、1102や1027がないかを調べます。CPUは平均だけでは重い一部処理を隠すため、高いquantileも確認します。deployment markerの前後でCPUやmemoryが増えていれば、直前のコード変更を戻す判断材料になります。
PaidではManage Account > Billing > Billable Usageも開きます。Workers画面は個別Workerの健康状態、Billable Usageはアカウント全体の従量課金を把握する場所です。複数Worker、D1、R2、KVを運用していると、個別画面が正常でもアカウント合計が増える場合があります。毎週同じ曜日に前週比を記録し、デプロイ、広告、ボット、バッチ実行と増加日を照合してください。
まず記録する数値は、日次requests、request error率、CPU time、Exceeded Resources、D1 rows read/write、R2 Class A/B、KV read/write、月間usage costです。数値をすべて細かく追うより、平常値から2倍になった指標を見つける運用が続きます。新機能公開の前日に基準値を保存し、公開翌日、3日後、7日後に比較すると、請求増加をコード、アクセス、外部資源へ切り分けやすくなります。
- 日次inbound requests
- Success / Errors
- CPU timeの分布
- 1102・1027
- D1 rows read/write
- R2 Class A/B
- KV read/write
- Billable Usageの累計USD
Budget alertとCPU上限を設定する
Cloudflare公式のBudget alerts資料によると、Pay-as-you-goアカウントは、アカウント全体のusage-based spendが設定したUSD閾値を超えたとき、指定メールへ通知できます。2026年7月20日以降、対象アカウントには10ドルのdefault alertが順次作成されています。ただし自分のアカウントで有効か、通知先が読めるメールかを必ず確認します。
Budget alertはspend capではなく情報通知です。閾値を超えてもWorkers、R2、D1などは自動停止せず、請求は増え続けます。利用量は前日分を日次処理するため、通知はリアルタイムではなく翌日になる場合があります。5ドル運用を想定するなら、まず10ドルだけでなく5ドル、10ドル、20ドルなど段階的な閾値を置き、少なくとも2人が読める通知先を設定します。
denial-of-walletや暴走処理に備える最後の防護は、WorkerごとのCPU limitです。Paidでは既定30秒を必要以上に引き上げず、処理の正常上限に合わせてlimits.cpu_msを設定します。これは月額の完全な上限ではありませんが、1回の実行が異常に長くCPUを消費する範囲を狭めます。WAF、rate limiting、キャッシュ、queue batching、外部API timeoutも組み合わせ、1つの通知だけへ依存しないでください。
- Freeの日次上限とPaidの月次含有量を区別
- requestsとCPUを別々に見積もる
- 最大日次requestsを確認
- CPUの高いquantileを確認
- Static AssetsとCacheを区別
- D1・R2・KVを別計算
- Billable Usageを確認
- Budget alertの閾値と宛先を確認
- alertが自動停止ではないと共有
- CPU limitとrollbackを用意
Cloudflare Workersの料金は、Freeなら「1日10万件と1実行10msで止まり得る」、Paidなら「最低5ドルにrequestとCPUの超過を足す」と覚えると判断できます。Static Assetsは無料・無制限でも、Workers Cache hitはrequest対象です。D1、R2、KVも合算し、MetricsとBillable Usageを週1回確認してください。今日の一歩は、Cloudflare管理画面で直近7日の最大requests、CPU time、Exceeded Resourcesを記録し、Budget alertの有無を確認することです。
Cloudflareアカウントの初期設定や請求先の確認がまだなら、Cloudflareの始め方と初期設定手順もあわせて確認してください。次回は、Workersと接続して使うCloudflare D1について、データベース作成から料金を増やしにくいindex設計まで解説します。

