Workers のランタイム更新で処理中のリクエストに与えられる猶予が最大30秒から最大20分に延びた。長い HTTP、AI のストリーミング応答、WebSocket がどこまで守られ、何が設計に残るかを整理する。
20分 Workers のランタイム更新時に処理中のリクエストへ与えられる猶予の上限（従来は30秒） Cloudflare Changelog 2026年10月12日。上限であり、WebSocket は猶予前に切れうる
Cloudflare Workers のランタイム更新時に、処理中のリクエストと接続に与えられる猶予が最大20分になった。2026年10月12日付の Workers changelog によると、これまでは最大30秒だった。長時間の HTTP リクエスト、AI のストリーミング応答、WebSocket セッションは、更新で打ち切られるまでの時間が延びる。
ただし切断がなくなったわけではない。猶予が終われば残った処理は終了されるし、WebSocket は猶予の途中でも切れうると changelog 自身が書いている。Hibernation API を使った接続も例外ではない。再接続、安全なリトライ、状態の復元を設計に入れておく必要は、この変更の後も同じだ。
| 項目 | 変更前 | 2026年10月12日以降 |
|---|---|---|
| ランタイム更新時の猶予 | 最大30秒 | 最大20分 |
| 猶予の単位 | 旧仕様の詳細は未記載 | 旧バージョンを動かすプロセスごと |
| 猶予終了時 | 旧仕様の詳細は未記載 | 未完了のリクエストと開いた接続は終了 |
出典：Cloudflare Changelog「More time for requests to finish during Workers runtime updates」（2026年10月12日）
changelog の説明を順に並べると、更新中のプロセスでは次のことが起きる。
ここで読み落としやすいのは「最大」という語だ。20分は上限であって、すべての更新で20分待ってもらえるとは書かれていない。旧プロセスが実際にどれだけの時間残るのか、更新がどの頻度で来るのかも changelog には載っていない。20分を前提にした処理時間の見積もりは避けたほうがいい。
changelog は WebSocket について「猶予が終わる前に切断されうる」と明記している。対象には WebSocket Hibernation API を使う接続も含まれる。どんな条件で早く切れるのかは書かれていない。
この一文のおかげで、効果の範囲ははっきりする。ストリーミング応答や長い HTTP リクエストは、旧プロセスが残る間は続けられる余地が広がった。WebSocket はその余地を当てにできない。チャットや AI エージェントのセッションを WebSocket で長く保つ構成なら、切断は更新のたびに起こりうる通常の出来事として扱うことになる。
Cloudflare が changelog で求めているのは次の3点だ。
「安全に」リトライするには、同じリクエストが二度処理されても副作用が重複しない作りが要る。課金や外部 API への書き込みを伴う処理は特にそうだ。ここは changelog の要求から一般的に導かれる話で、具体的な手段までは示されていない。
AI のストリーミング応答では、途中まで返した内容をどう扱うかも決めておきたい。猶予の上限が延びた分、ランタイム更新中も長い生成を完了できる余地は広がった。ただし、猶予が常に20分確保されるとは限らない。途中で切れたときにクライアントが最初からやり直すのか、保存した途中結果から再開するのかは、アプリ側で選ぶしかない。
この変更を受けるために利用者側で有効にする設定は、changelog には書かれていない。
これまで30秒の猶予を前提に、長い処理を短く分割したり、更新による切断を頻繁なものとして扱ってきた構成は、その前提が緩んだ。とはいえ分割や再接続の仕組みを外す理由にはならない。猶予は上限付きで、WebSocket はその途中でも切れるからだ。
手を入れるなら、切断時の挙動を確かめるテストが先になる。WebSocket が切れたときにクライアントが再接続するか、中断したリクエストを再送して結果が重複しないか、再起動後に状態が戻るか。この3点は猶予時間にかかわらず確認しておきたい。テストが通っても切断時の遅延や復旧結果が必ず同じになるとは限らないため、実際の中断時に何が起きるかを観測する。
