Cloudflare Workers 料金を再検討：バンドルサイズだけなら有料化は不要に

Cloudflareでは、Cloudflare Workers 料金を検討するうえで、バンドルサイズだけを理由にWorkers Paidを選ぶ必要がなくなりました。2026年9月4日、従来のFree 3 MB、Paid 10 MBという圧縮後サイズの判定は廃止され、両プラン共通で非圧縮64 MiBの上限に一本化されました。今後、デプロイ容量の基準になるのはgzipではなく、Wranglerが表示するTotal Uploadです。

Cloudflare Workersのバンドルサイズ制限はどう変わったか

Workerバンドルとは、デプロイ時にCloudflareへ送られるコードと関連モジュール一式です。CloudflareのコマンドラインツールであるWranglerは、標準でesbuildを使ってアップロード用の成果物をビルドし、コードから読み込まれるnpmパッケージを含めたサイズを表示します。

9月4日までは、このバンドルを圧縮したうえで、Workers Freeでは3 MB、Workers Paidでは10 MBを超えるとデプロイが拒否されていました。この圧縮後サイズによる判定はすでに廃止されています。

現在チェックされるのは1点だけです。非圧縮のバンドルサイズが64 MiB以下である必要があり、FreeとPaidのどちらにも同じ上限が適用されます。

仕組みを理解するうえで重要なのは最後の列です。Total Uploadは非圧縮サイズを示します。gzipも参考値として引き続き表示されますが、Cloudflareがデプロイ可否の判定に使うことはありません。

新旧の上限を単純な倍率で比べることはできません。以前は圧縮後のバイト数をMB単位で測り、現在は非圧縮のバイト数をMiB単位で測っています。実際にどれだけ多くのコードを収められるかは、JavaScript、依存関係、バイナリモジュールがどの程度圧縮できるかによって変わります。

Cloudflare Workers 料金：$5プランを選ぶ基準が変わった

事業面での影響は限定的ですが、判断をはっきりさせる重要な変更です。Workers Paidには、アカウントあたり月額$5 USDの最低料金があります。従来のFree上限である3 MBをバンドルが超えることだけを理由にアップグレードを予定していたなら、Total Uploadが64 MiB以内に収まる限り、その必要はなくなりました。

ただし、FreeとPaidが同じプランになったわけではありません。Workers Freeには、1日あたり100,000リクエスト、1回の呼び出しあたり10ミリ秒のCPU時間、1回の呼び出しあたり50サブリクエストが含まれます。Workers Paidには、月間10 millionリクエストと30 million CPUミリ秒が含まれ、1回の呼び出しあたり10,000サブリクエストまで利用できます。さらに、1リクエストあたりのCPU時間は、標準の30秒から最大5分まで設定できます。

これで予算判断は明快になります。料金を払うべき基準は、トラフィック、CPU、サブリクエスト、Paid限定機能です。圧縮しやすいバンドルが、廃止されたFreeの上限を超えたという理由だけで支払う必要はありません。

実運用のためにすでにPaidを利用しているチームでは、請求額が直接下がるわけではありません。以前の上限を余裕をもって下回っていたチームも、ワークフローは変わりません。恩恵が大きいのは、デプロイサイズを理由にコードを削り、分割し、あるいはアップグレードしていたプロジェクトです。

アカウント全体の料金やランタイム利用量については、Cloudflareの総合レビューで、WorkersとCloudflareのほかのプラン・従量料金との関係を整理しています。その記事にある旧バンドル上限の数値は、今回の9月の変更で置き換わる部分です。

開発が楽になる4つのケース

個人SaaS開発者：フレームワークとプランを切り離して選べる

たとえば、Workers Freeでフルスタックアプリケーションを公開するとします。アプリケーションのトラフィックがFreeの範囲内でも、フレームワークアダプター、サーバーレンダリング用コード、本番用の依存関係をまとめると、圧縮後のバンドルが従来のFree上限を超えることがありました。

今後は、そのビルドを64 MiBのTotal Uploadと照らして判断できます。範囲内なら、バンドルサイズだけを理由に$5のPaid最低料金が発生することはありません。どの規模でも本番運用が無料になるという意味ではなく、まだ必要のないランタイム利用料を払う前に需要を検証できることが利点です。

制作会社：不要になったCIの判定を削除できる

制作会社のビルド担当者が、従来のgzip上限をすべてのクライアントリポジトリに組み込んでいる場合があります。その判定を残すと、Cloudflareがすでに適用していないルールによってビルドが失敗します。

非圧縮のTotal Uploadを確認する判定に置き換え、余裕を確保するために64 MiBより低い社内上限を設定します。そうすれば、クライアントのプロジェクトは過去のルールではなく、現在のプラットフォーム制約に対して判定されます。

Rust・WebAssemblyチーム：ランタイムではなく容量に余裕が生まれる

一般にWasmと略されるWebAssemblyを使うと、Worker上でRust、Go、Cなどからコンパイルしたバイナリコードを実行できます。Cloudflareによると、Wasm Workerは同等のJavaScript Workerより大きくなるのが一般的です。バイナリに追加のランタイム依存関係が含まれることが多いためです。

デプロイ可能な容量が増えたことで、Wasmモジュールとその周辺コードに使える余地が広がりました。Wranglerは.wasmと.wasm?moduleを直接アップロードできます。それでもサイズ最適化は重要であり、Cloudflareはバイナリを小さくする手段としてwasm-optを推奨しています。

プラットフォームチーム：回避策としての構成を見直せる

Workers Paidを使うプラットフォームエンジニアのなかには、圧縮後10 MB以内に収めるためだけに、まとまりのあるサービスを分割したり、有用な依存関係を外したり、外部モジュール用の独自経路を構築したりした人もいるでしょう。こうした判断は、改めて見直す価値があります。

責任範囲や障害の境界が明確になるなら、分割を維持すべき場合もあります。一方、廃止されたアップロード判定だけを理由にした分割は、現在のプラットフォーム要件には不要な複雑さです。

次のCloudflare Workers デプロイ前に実際のバンドルを確認する

node_modulesやソースディレクトリのサイズ、別のフレームワークビルドが生成したアーカイブから推測する必要はありません。WorkerプロジェクトでWranglerのドライデプロイを実行し、Cloudflareへ実際に送られる成果物をビルドします。

1. 1

   デプロイせずにビルドする

   Cloudflareのドキュメントにあるドライラン用コマンドを実行します。

   wrangler deploy --outdir bundled/ --dry-run

   WranglerはWorkerをビルドし、デプロイせずに出力をローカルへ書き込みます。

2. 2

   Total Uploadを確認する

   コマンド出力からTotal Uploadを探します。これは、Cloudflareが現在64 MiBと照合している非圧縮バンドルサイズです。必要なら診断用の参考値としてgzipも確認できますが、プラットフォーム上の合否判定には使いません。

3. 3

   CIの容量基準を変更する

   Freeの圧縮後3 MB、Paidの圧縮後10 MBを基準にするルールは、Total Uploadを使うルールへ置き換えます。依存関係を1回更新しただけで余裕をすべて使い切らないよう、チーム独自の上限はプラットフォームの最大値より低く設定します。

4. 4

   実際のデプロイで起動時間を確認する

   次回の通常デプロイまたはバージョンアップロードでは、Wranglerが出力するstartup_time_msを記録します。バンドルがアップロード上限内でも、Cloudflareの別の起動チェックに通らない場合があります。

よくある間違いは、以前デプロイ可否を決めていたという理由で、見た目の数値が小さいgzipを追い続けることです。現在、容量の基準にすべき値はTotal Uploadです。

変わっていない制約まで64 MiB緩和されたわけではない

バンドルが大きくなれば、解析や初期化にも時間がかかる可能性があります。リクエストハンドラーの外、つまりグローバルスコープで負荷の高い処理を行うコードは、引き続きScript startup exceeded CPU time limitとエラーコード10021で検証に失敗することがあります。64 MiB未満ならサイズ判定は通りますが、正常に起動できると保証されるわけではありません。

特に影響を受けるのは、重いフレームワークとWasmです。以前はアップロード時の上限で先に止まることがよくありました。新しい上限ではより多くのコードが次の制約まで到達するため、そこでメモリ使用量と初期化時の挙動が表面化します。

それでもWorkerが大きすぎる場合、現在のドキュメントでは次の3つが実用的な対処法として挙げられています。

• デプロイされる実行経路で使っていないパッケージと依存関係を削除する。
• 設定、静的アセット、バイナリデータをWorkerバンドルに含めず、Workers Static Assets、KV、R2、D1へ置く。
• Service Bindingsを使って機能を複数のWorkersに分割する。

Service Bindingの呼び出しに、2回目のリクエスト料金はかかりません。Cloudflareが課金するのは、最初のWorker呼び出しと、関係するWorkers全体で使われたCPU時間です。このため、サービス分割はサイズ対策として現実的ですが、サービス境界が増えることは意識して受け入れる必要があります。

月曜日にやること

最近、従来のサイズ判定でWorkerのデプロイに失敗した場合、上限内に収めるためにフレームワークの依存関係を削った場合、またはバンドルサイズだけを理由にPaidへのアップグレードを検討していた場合は、今週中に対応しましょう。ドライデプロイを実行してTotal Uploadを記録し、その判断を見直します。

Workerが以前の上限を十分に下回り、デプロイパイプラインにgzipの固定判定もないなら、対応を待って構いません。アプリケーションのランタイムには何も変更がありません。

リクエスト数、CPU時間、サブリクエスト、その他のPaid機能に見合うなら、Paidを使い続けます。Freeでアップロードできる容量が増えたからといって、運用クォータが合わないプランへ本番ワークロードを移す理由にはなりません。

月曜日にやることはシンプルです。ビルドの判定基準をgzipからTotal Uploadへ変更し、バンドルサイズではなく利用量を基準にプランを選びましょう。

次に取るべき実践的なプラットフォーム対応は、ニュースレターでお届けします。