制限

リクエスト本文のサイズ制限は、Workers プランではなく Cloudflare アカウントプランに依存します。これらの上限を超えるリクエストには 413 Request entity too large エラーが返ります。

Enterprise のお客様は、ゾーンの Network ページ（Maximum Upload Size）から、リクエスト本文の最大サイズを最大 5 GB まで自分で変更できます。5 GB を超える上限が必要な場合は、アカウントチームまたは Cloudflare サポート に連絡してください。

Cloudflare はレスポンス本文サイズの制限を強制しません。CDN キャッシュの制限 が適用されます。Free、Pro、Business プランは 512 MB、Enterprise は 5 GB です。

CPU 時間は、Worker コードの実行に CPU が使った時間です。ネットワーク待ち（fetch() 呼び出し、KV 読み取り、データベースクエリなど）は、CPU 時間に含まれません。

ほとんどの Worker が使う CPU 時間はごくわずかです。平均はリクエストあたり約 2.2 ms です。認証、サーバーサイドレンダリング、大きなペイロードのパースなど、負荷の高い処理では通常 10〜20 ms です。

各 isolate には、Worker が設定した上限をたまに超える場合に備えた余裕があります。上限を継続的に超えるようになると、設定した上限に従って実行が打ち切られます。

Worker が CPU 時間の上限を超えると、Cloudflare はクライアントに Error 1102 を返し、メッセージは Worker exceeded resource limits です。ダッシュボードでは、Metrics > Errors > Invocation Statuses の下に Exceeded CPU Time Limits と表示されます。分析と Logpush では、呼び出し結果は exceededCpu です。

CPU 時間の上限エラーを解消するには:

1. CPU 時間の上限を上げる — Workers Paid プランでは、デフォルトの 30 秒から最大 5 分（300,000 ms）まで上げられます。Wrangler 設定またはダッシュボードで設定します。
2. コードを最適化する — DevTools の CPU プロファイリング で、CPU 負荷の高い箇所を特定します。
3. 処理をオフロードする — 重い計算を Durable Objects に移すか、データを複数リクエストに分けて小さく処理します。

Workers Paid プランでは、CPU 時間の上限をデフォルトの 30 秒から 5 分（300,000 ms）まで上げられます。

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // default is 30000 (30 seconds)
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

ダッシュボードでも変更できます。Workers & Pages を開き、対象の Worker を選び、Settings で CPU 時間の上限を調整します。

• Workers Logs — CPU 時間とウォールタイムは 呼び出しログ に表示されます。
• Tail Workers / Logpush — CPU 時間とウォールタイムは Workers Trace Events オブジェクト のトップレベルに表示されます。
• DevTools — ローカルで DevTools の CPU プロファイリング を使い、CPU 負荷の高い箇所を特定します。

各 isolate は、JavaScript ヒープと WebAssembly 割り当てを含め、最大 128 MB のメモリを使えます。この制限は呼び出しごとではなく、isolate ごとです。1 つの isolate が多数の同時リクエストを処理できます。

isolate が 128 MB を超えると、Workers ランタイムは進行中のリクエストを完了させ、以降のリクエスト用に新しい isolate を作ります。極端に負荷が高いときは、安定性を保つために一部の受信リクエストをキャンセルすることがあります。

Worker がメモリ上限を超えると、Cloudflare はクライアントに Error 1102 を返し、メッセージは Worker exceeded resource limits です。ダッシュボードでは、Metrics > Errors > Invocation Statuses の下に Exceeded Memory と表示されます。分析と Logpush では、呼び出し結果は exceededMemory です。

上限を超えるレスポンス本文をバッファしようとすると、ランタイムエラー Memory limit would be exceeded before EOF も出ることがあります。

メモリ上限エラーを解消するには:

1. リクエスト本文とレスポンス本文をストリーミングする — ペイロード全体をメモリに載せず、TransformStream または node:stream を使います。
2. 大きなインメモリオブジェクトを避ける — 大きなデータは Worker メモリに持たず、KV、R2、D1 に保存します。
3. Zod を更新する — Worker で Zod を使っている場合は、バージョン 4.5.0 以降 ↗ を使います。それ以前のバージョンは、スキーマあたりのメモリ使用量が大幅に多いです。
4. メモリ使用量をプロファイリングする — ローカルで DevTools のメモリプロファイリング を使い、リークとメモリ消費の大きい割り当てを特定します。

ダッシュボードでメモリエラーを確認する手順は次のとおりです。

1. Workers & Pages を開きます。

   Workers & Pages を開く ↗

2. 調査する Worker を選びます。

3. Metrics で Errors > Invocation Statuses を選び、Exceeded Memory を確認します。

継続時間は、Worker 呼び出しの開始から終了までのウォールクロック時間です。

HTTP トリガーの Workers には、継続時間の厳密な上限はありません。クライアントが接続している限り、Worker は処理、サブリクエスト、レスポンス本文のストリーミングを続けられます。クライアントが切断するかレスポンスが完了すると、そのリクエストに紐づくタスクはキャンセルされることがあります。レスポンス返却後の処理には ctx.waitUntil() を使います。waitUntil() は、レスポンス送信後またはクライアント切断後、最大 30 秒まで実行を延ばせます。

Workers は Cloudflare のグローバルネットワーク全体で自動的にスケールします。1 秒あたりのリクエスト数に一般的な上限はありません。

Workers Free プランのアカウントには、1 日 100,000 リクエストの上限があり、UTC の午前 0 時にリセットされます。この上限を超えると、Cloudflare は Error 1027 を返します。

フェイルモードは、対応する ルート の切り替えで設定できます。

サブリクエストは、Worker が Fetch API を使って行うリクエスト、または R2、KV、D1 などの Cloudflare サービスへのリクエストです。

リダイレクトチェーン内の各サブリクエストも、この上限にカウントされます。サブリクエストの合計は、コード内の fetch() 呼び出し数を超えることがあります。Worker ごとのサブリクエスト上限は、Wrangler 設定ファイルの limits 設定 で変更できます。

個々のサブリクエストに決まった時間制限はありません。クライアントが接続している限り、Worker はサブリクエストを続けられます。クライアントが切断するかレスポンスが完了すると、未完了の処理はキャンセルされることがあります。ただし ctx.waitUntil() に渡した場合は、最大 30 秒まで実行を延ばせます。

同じアカウント上の別の Worker へインターネットを経由せずにリクエストを送るには、Service Bindings を使います。

同じ ゾーン 上の別の Worker を、Service Bindings なしでグローバル fetch() から呼ぶと失敗します。Workers は カスタムドメイン 宛てのリクエストを受け付けます。

各 Worker 呼び出しは、レスポンスヘッダー待ちの接続を同時に最大 6 本まで持てます。初期接続の確立中で、サーバーがまだ応答していないあいだ、次の API 呼び出しがこの上限にカウントされます。

• Fetch API の fetch() メソッド
• Workers KV 名前空間オブジェクト の get()、put()、list()、delete() メソッド
• Cache オブジェクト の put()、match()、delete() メソッド
• R2 の list()、get()、put()、delete()、head() メソッド
• Queues の send()、sendBatch() メソッド
• connect() API で TCP ソケットを開くこと

外向きの WebSocket 接続も、この上限にカウントされます。

接続のレスポンスヘッダーが届くと、その接続は 6 本制限の対象外になります。つまり、同時にオープンな接続は多数持てますが、「ヘッダー待ち」の初期段階にあるのは同時に 6 本までです。すでに 6 本がヘッダー待ちのときに 7 本目を試みると、既存のいずれかがレスポンスヘッダーを受け取るまでキューに入ります。

fetch() を使うがレスポンス本文が不要な場合は、メモリを解放するために response.body.cancel() を呼ぶのがよい習慣です。

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

圧縮サイズの上限はありません。カウントされるのは非圧縮バンドルサイズだけです。

Worker バンドルが大きいと、起動時間に影響することがあります。Worker バンドルサイズを確認するには:

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

Total Upload: 259.61 KiB / gzip: 47.23 KiB

Total Upload の値が非圧縮バンドルサイズです。gzip の値は参考表示であり、制限ではありません。

Worker サイズを小さくするには:

• 不要な依存関係とパッケージを削除します。
• 設定ファイル、静的アセット、バイナリデータはバンドルせず、KV、R2、D1、または Workers Static Assets に保存します。
• Service bindings を使い、機能を複数の Workers に分割します。

Worker は、グローバルスコープ（ハンドラーの外にあるトップレベルコード）のパースと実行を 1 秒以内に終える必要があります。バンドルが大きい場合や、グローバルスコープで重い初期化をしている場合、起動時間は長くなります。

Worker が起動時間の上限を超えてプラットフォームがデプロイを拒否すると、検証はエラー Script startup exceeded CPU time limit（エラーコード 10021）を返します。Wrangler は CPU プロファイルを自動生成し、Chrome DevTools にインポートするか VS Code で開けます。詳細は wrangler check startup を参照してください。

起動時間を測るには、npx wrangler@latest deploy または npx wrangler@latest versions upload を実行します。Wrangler は出力に startup_time_ms を表示します。

起動時間を短くするには、グローバルスコープで重い処理をしないでください。初期化ロジックはハンドラー内かビルド時に移します。たとえば、大きなスキーマをトップレベルで生成または消費すると、この上限を超えやすくなります。

--remote フラグで リモート開発 セッションを実行すると、Cloudflare はゾーンあたり 50 ルートの上限を適用します。Cloudflare ダッシュボードの Quick Editor も wrangler dev --remote を使うため、同じ上限が適用されます。

ゾーンのルートが 50 を超えている場合は、上限未満になるまでルートを削除しないとリモートセッションを実行できません。

Worker あたり 1,000 を超えるルート、または 1,000 を超えるルート対象ゾーンが必要な場合は、Workers for Platforms の利用を検討してください。ゾーンあたり 100 を超えるカスタムドメインが必要な場合は、ワイルドカード ルート の利用を検討してください。

リクエストあたりの呼び出し数は、リクエストごとの Cache API の put()、match()、delete() 呼び出し回数です。サブリクエスト（fetch()）と同じクォータを共有します。

この制限は、1 リクエストについて console.log() の出力、例外、リクエストメタデータ、ヘッダーとして出るすべてのデータを対象にします。この上限を超えると、そのリクエストについて、ログ、tail ログ、Tail Workers に追加のコンテキストは記録されません。

Logpush 宛先へ送るフィールドの制限は、Workers Trace Event Logpush のドキュメント を参照してください。

Workers で Image Resizing を使う場合の制限は、Image Resizing のドキュメント を参照してください。

Worker が Unbound プランの場合、制限は Workers Paid プランと同じです。

Worker が Bundled プランの場合、制限は Workers Paid プランと同じですが、次の例外があります。

Bundled プランの Workers には、Cron Triggers、Durable Object Alarms、Queue Consumers の継続時間制限はありません。

ウォールタイム（ウォールクロック時間とも呼ばれます）は、呼び出しの開始から終了までの経過時間の合計です。ネットワークリクエスト、I/O、その他の非同期処理の待ち時間も含みます。CPU 時間 とは異なります。CPU 時間は、CPU がコードを実際に実行している時間だけを測ります。

次の表は、開発者プラットフォーム全体における Worker の呼び出し種別ごとのウォールタイム上限です。

• KV の制限
• Durable Object の制限
• Queues の制限
• Workers エラーリファレンス