Workers のランタイム更新時の猶予が最大30秒から最大20分へ。長時間ストリーミングと WebSocket が更新をまたいで生き残りやすくなった

要約

Cloudflare が Workers のランタイムを更新する際、処理中のリクエストと接続に与えられる猶予期間が、従来の最大30秒から最大20分へ延長されました。

この変更を理解するには、Workers のランタイム更新という仕組みを先に押さえる必要があります。

Workers は、利用者が管理しないランタイムの上で動きます。Cloudflare はこのランタイムを自分の都合で随時更新します。 セキュリティ修正、性能改善、機能追加。利用者にデプロイの通知は来ません。更新時には動いているインスタンスが新しいものに置き換わります。

このとき問題になるのが、置き換えの瞬間に処理中だったリクエストです。 完了を待つべきか、打ち切るべきか。従来の上限は最大30秒でした。 30秒以内に終わればそのまま完了し、超えていれば切られていました。

今回、この上限が最大20分になりました。 約40倍です。

なぜこれが大きいかは、数字ではなく用途で見るべきです。 30秒という上限は、Workers が「短いリクエストを大量に捌く」用途に最適化されていた時代の前提です。HTTP リクエストを受けて JSON を返すなら、30秒は十分すぎる余裕でした。

ところが LLM を扱うようになると、1リクエストの寿命が伸びます。

• LLM のストリーミング応答: 長い回答を生成している間、接続は開いたままです。推論モデルなら数分かかることもあります
• 長時間動くエージェント: ツールを何度も呼び、その間ずっと1つのセッションが生きています
• 常時接続の WebSocket: チャット UI やリアルタイム協調編集では、接続が数十分続くのが普通です

これらはいずれも30秒を超えます。 つまりランタイム更新が来るたびに切断される構造でした。頻度は高くないものの、「たまに原因不明で切れる」という形で現れるため、調査が難しい種類の障害です。

ただし公式は、同時にはっきりと留保をつけています。 猶予期間が終わる前に接続が切れることは依然としてありうるため、アプリケーション側は WebSocket の再接続と安全なリトライを扱えるように作っておく必要がある、と明記しています。

つまり「切れなくなった」ではなく「切れにくくなった」変更です。 ここを読み違えると、再接続処理を省く判断に繋がります。

利用者側の作業は不要です。 コード変更も設定変更もなく、プラットフォーム側の挙動として適用されます。changelog にプラン別の差異の記載はありません。

何が変わったか

• Workers ランタイム更新時の猶予期間が 最大30秒 → 最大20分（約40倍）
• 対象は処理中のリクエストと張られている接続
• 公式の留保: 猶予期間の終了前に接続が切れることは依然としてありうる
• アプリ側に求められること: WebSocket の再接続、安全なリトライ（公式明記）
• コード変更・設定変更は不要。 プラットフォーム側の挙動変更
• changelog にプラン別の差異の記載は無い
• 影響が大きい用途: LLM のストリーミング応答、長時間エージェント、常時接続 WebSocket

業務インパクト（一般企業向け）

この変更が効くのは、「原因不明の切断」を調査したことがあるチームです。

Workers 上で LLM のストリーミングを扱っていると、低い頻度で応答が途中で止まる現象に出会います。ログには異常が出ず、再現もしません。ユーザーからは「たまに途切れる」という報告だけが来ます。ランタイム更新による30秒打ち切りは、この種の報告の原因の1つでした。

原因が分かりにくい理由は、更新のタイミングが利用者から見えないことです。 自分のデプロイでもなく、トラフィックの急増でもなく、Cloudflare 側の更新。ログを自分のシステムの中だけで探している限り、見つかりません。

今回の変更は、この失敗要因の発生確率を構造的に下げます。 30秒を超えるリクエストのうち、20分以内に終わるものは猶予に収まります。LLM のストリーミング応答のほぼ全部、エージェントの多くがこの範囲です。

ただし、設計の結論を変えてはいけません。

公式が留保を書いている通り、切れることは依然としてあります。 実装上の判断として正しいのは次の2つです。

• WebSocket は再接続前提で書く。 状態をサーバー側（Durable Objects など）に置き、接続は使い捨てにできる形にする
• リトライは安全に作る。 冪等性を担保する。LLM 呼び出しの再実行が二重課金や二重書き込みになる構造を避ける

「20分あるからリトライは要らない」は誤りです。 猶予期間は上限であって保証ではありません。

プラン別の記載が無い点は、確認対象として残しておいてください。 changelog に差異の記述はありませんが、無いことは「全プラン同じ」の明言でもありません。 可用性を SLA として顧客に約束している場合は、サポート経由で確認する価値があります。

実務としてやることは2つです。 (1) 30秒を超えるリクエストを持つ Worker を洗い出す。 今回の変更の恩恵を受けるのはそこだけです。(2) 再接続とリトライの実装状況を確認する。 入っていないものが「これまで運良く動いていた」のか「切断を受け入れていた」のかを区別してください。前者なら、今回の変更で問題が見えにくくなるだけで消えてはいないことになります。

副業・個人活用視点

個人開発で Workers に LLM を載せている人には、直接効きます。

ストリーミング応答が途中で切れるという不具合は、個人開発で最も原因を特定しにくい部類です。 ローカルでは再現せず、本番でまれに起きる。ログにも出ない。「自分のコードが悪いのだろう」と延々探してしまう種類の問題です。原因の候補としてランタイム更新を知っているだけで、無駄な調査時間が減ります。

案件の観点では、2つの売り方があります。

1つ目は、「切断に強い作り」を明示的に納品物に含めることです。 再接続とリトライは、入れても見た目が変わりません。だからこそ入っていない納品が普通に存在します。 公式が「再接続とリトライを扱えるように」と明記している事実は、提案書に引用できる根拠です。「公式がこう書いているので、この実装を入れています」と言えるのは強いです。

2つ目は、既存システムの点検です。 Workers で LLM を動かしている既存案件に対して、30秒を超えるリクエストの棚卸しと、再接続の有無の確認は短時間で終わる作業です。そして**「たまに切れる」という既知の不具合を抱えている顧客は多い**です。原因の候補を提示できるだけで、調査の受託に繋がります。

コンテンツとしては、「見えない更新」という切り口が書きやすいです。 マネージドなランタイムの上で動かすということは、自分の知らないタイミングで足元が入れ替わることを受け入れるということです。これは Workers に限らず、Lambda でも Cloud Run でも同じ構造があります。30秒から20分という具体的な数字が公式に出たことで、抽象論ではなく事実として書けます。

注意点を1つ。 この変更はコスト構造を変えません。長時間リクエストが許されやすくなっただけで、長く動かした分の課金は変わりません。 「20分まで動かしていい」と読むと、課金の見積りを誤ります。