Cloudflare Workers のタイムアウトとサイズ制限を整理する｜エッジ実行のCPU時間・本文サイズ・サブリクエスト

本記事は、Cloudflare Workers のタイムアウトとサイズ制限を、公式ドキュメントを基準に調べた記録です。CPU時間と実時間（wall-clock）の区別、レスポンスサイズに明示的な上限がない設計、リクエスト本文サイズがWorkers側ではなく Cloudflare アカウントのプランで決まる仕様など、Workers 特有の見方が必要な論点を、実務で当たりやすい順に整理します。

01.結論：CPU時間とプラン依存サイズが「Workers特有」の論点

Workers の上限を読むときに最初につまずきやすいのは、CPU時間と実時間（wall-clock）が別計測である点と、レスポンスサイズに明示的な上限が公式に書かれていない点です。「タイムアウトは 30 秒」という数字だけを見て同じ感覚で設計を進めようとすると、実時間と CPU 時間の違いで読み違えやすくなります。

Workers は「コードの実行」と「I/O待ち」を別物として測る設計で、エッジでの軽い実行を前提に組まれています。本記事はその前提を踏まえて、CPU時間・リクエスト本文・レスポンス本文・サブリクエスト・メモリ・キャッシュの順で上限を整理します。

02.Workersは「実時間」ではなく「CPU時間」で制限される

Workersの時間制限を理解するために、最初に押さえておく区別が「CPU時間（CPU time）」と「実時間（wall-clock）」の違いです。

CPU時間：Free 10ms ／ Paid 既定30秒・最大5分

Cloudflare公式の Workers制限ドキュメント と 2025年3月のCPU時間上限引き上げ告知 によれば、WorkersのCPU時間はプランで桁違いに変わります。Free プランは 1 リクエストあたり 10msと非常に短く、Workers Paid プランは既定で 30 秒、設定により最大 5 分（300,000 ミリ秒）まで引き上げられます。CPU時間を超過するとCloudflareはエラー1102を返し、Workersのダッシュボードでは「Exceeded CPU Time Limits」として記録されます。

Free で動かして問題なかった Worker が、本来扱いたい処理を載せた Paid 移行後に挙動が変わる、というよりも、本番想定の Worker を Free プランで CPU 時間まわりの挙動を検証するのはそもそも難しいのが実情です。Free と Paid で前提が違うことを意識して検証環境を選ぶ必要があります。

wall-clockには実質上限がない（HTTPトリガー）

Workers のもう一つの特徴は、CPU時間に「fetch待ち」「KV読み込み待ち」などのI/O時間は含まれない点です。HTTPトリガーの Worker では、クライアントが接続を切らない限り、実時間（wall-clock）に実質的な上限はありません。

実装面では、「重い計算は少ないが、外部 API を長く待つ」種類の処理に向きます。たとえば外部の LLM API に数十秒かけて応答を返してもらい、それをそのままストリーミングで返す、といった構成が CPU 時間の壁にぶつからずに書けます。

03.リクエスト本文サイズはWorkersではなくプランで決まる

Workersのリクエスト本文サイズの上限は、Workers側ではなく、Cloudflareアカウントのプランで決まります。POST／PUT／PATCHリクエストの本文がプラン上限を超えると、Cloudflareは413 Request Entity Too Largeを返します。

Worker のコード側で「リクエスト本文サイズの上限」を設定する手段はありません。「ファイルアップロードを直接 Worker で受ける」ような設計を想定するときは、業務要件で扱う最大サイズと契約プランの上限を突き合わせるのが先です。Worker でアップロードを受けたときに小さく止まる場合は、まずアカウントのプランから確認することになります。

04.レスポンス本文に明示的な上限はない

Workersのレスポンス本文サイズには、公式ドキュメント上で明示的な上限が示されていません。ストリームで返せばいくらでも流せる設計です。

ただし、CDN に乗せて配るキャッシュ容量はプランで分かれます（後述）。「重いレスポンスをそのまま流す」用途では実行時の上限に当たらず、「重いレスポンスを CDN にキャッシュさせて何度も配る」用途ではキャッシュ容量側の上限を意識する、という見方が現実的です。

05.サブリクエスト数・メモリ・キャッシュ容量

サブリクエスト数の上限はFreeとPaidで大きく違う

1リクエスト内で実行できるサブリクエスト（fetch()・KV読み込み・他Cloudflareサービス呼び出しなど）の数にも上限があります。 2026年2月のサブリクエスト上限緩和の告知 以降、Paidプランの既定上限は10,000に引き上げられ、Wrangler設定で最大1,000万まで延ばせます。Freeプランは引き続き外部 fetch が 50 件／Cloudflare サービス（KV・R2・D1 など）への呼び出しが 1,000 件です。

実務的には、複数の外部 API を束ねる BFF（Backend for Frontend）的な Worker で上限に当たりやすいのはここです。Free プランで検証していて Paid 想定の本番でだけ前提条件が変わる項目でもあるので、プランを跨ぐときに見落とさないように注意します。

メモリは1リクエストあたり128MB

Workersのメモリは、1リクエスト（1Worker invocation）あたり128MBです。Lambdaのように関数単位でメモリを大きく取って性能を上げる設計はできず、計算量の重いタスクは別の場所に逃がす前提になります。

CDNキャッシュ容量はプラン依存

Cloudflareがエッジでキャッシュできるリソースサイズもプランで分かれます。Free・Pro・Businessは512MBまで、Enterpriseは5GBまでです。大きな動画ファイルや巨大なJSONダンプをそのままエッジでキャッシュさせたい用途では、ここに当たることがあります。

06.Amplify／CloudFront との違い

Cloudflare 以外の選択肢として AWS の Amplify Hosting がありますが、上限の体系が大きく違います。要件に合わせて選び分けるときの参考として、並べて整理します。

比較すると、処理時間とレスポンスサイズのいずれも Cloudflare Workers の方が Amplify SSR Compute より緩いです。タイムアウトについては、Amplify は実時間 30 秒で頭打ちなのに対し、Cloudflare Workers は CPU 時間が Paid プランで既定 30 秒・最大 5 分まで延ばせて、HTTP トリガーの実時間には実質上限がありません。レスポンスサイズについても、Amplify は 5.72MB を超えると 504 になる一方、Cloudflare Workers はレスポンス本文サイズに明示的な上限を設けていません。ただし、これは重い処理結果を同期リクエストで返す設計を推奨するものではありません。生成や集計に時間がかかる処理は、非同期ジョブ化して結果を保存し、完了後に参照先を返す設計が基本です。

07.設計段階で上限に当たらないためのチェック

Workers を本番に乗せる前に、次のチェックを通しておくと事故が減ります。

Workers の設計でとくに最初に意識しておきたいのは、「実時間ではなく CPU 時間で測られる」「メモリは 128MB 一律」という 2 点です。一般的なアプリケーションサーバの感覚で組むと、この 2 点で読み違えやすくなります。

08.よくある質問（FAQ）

09.まとめ

Cloudflare Workers の設計でとくに注意したいのは、CPU 時間と実時間（wall-clock）が別計測である点と、レスポンスサイズに明示的な上限がない点です。ほかのホスティング環境の感覚で読むと、この 2 点で読み違えやすくなります。Free と Paid で CPU 時間が桁違いに変わる（10ms と 30 秒〜5 分）ことも、検証環境を選ぶときに踏まえておく必要があります。

本記事で扱った制限値は、各サービスの公式ドキュメントを出典としています。クォータは時期によって緩和されることもあるため、本番に乗せる前には最新の公式ドキュメントで再確認してください。