TITLE

DenoがCloudflareに合流——Workers・Durable Objects・JSRの行方を整理する

投稿日：2026.10.13

合流の内容——チームの合流と、同時発表された統合計画

Cloudflare公式ブログによると、合流の対象はDeno Landチーム全体です。日本語で報じたPublickeyは、これを買収と見られる取引だと伝えています(買収条件は非公開)。

合流にあわせて、CloudflareはworkerdとcelldをどちらもCloudflare傘下として統合する計画を発表しました。workerdは、Cloudflare Workersの実行基盤をオープンソースで実装したランタイムです。この統合を主導するのは、Node.jsの作者であり、Denoの創設者でもあるRyan Dahlと、Bert Belderの2人です。両者は、workerdをセルフホスト環境でも「ファーストクラス」でサポートする新しい取り組みを担います。

Cloudflare側のKenton Vardaは、2022年にShopifyへ「Workers for Platforms」を提案した際、先方からランタイムのオープンソース化を求められた経緯に触れています。Cloudflareにとって、オープンソースのランタイムを求める声は今回が初めてではありません。

Deno Deploy・JSRへの影響——6か月後の終了と、継続するもの

影響を受ける製品は3つに分かれます。Denoランタイム本体は、今後1年間、月次のバグ修正とセキュリティ修正を受けます。その後Deno Landとしての開発は終了しますが、オープンソースのコードとして他の開発者が引き継ぐ可能性は残ります。

Deno Deployは、Deno Landが運営してきたクラウドホスティングサービスで、Denoランタイムで書いたコードをそのままインターネットに公開できる仕組みとして使われてきました。これは6か月後にシャットダウンし、Cloudflare Workersへの移行パスが提供される予定です。

JSR(JavaScript Registry)は、Deno発のパッケージレジストリで、npmに代わる配布先として設計されたものです。これは運営自体は継続する一方、インフラはCloudflareへ移行します。

workerd×celldの技術的意味——単一インスタンスの壁を外す試み

ここまでの製品ごとの結末(ランタイムの保守終了・Deployのシャットダウン・JSRのインフラ移行)は、Deno Landの事業整理としての判断です。これとは別の時間軸で進むのが、workerdとcelldの技術統合です。合流の技術的な核心は、ここにあります。

workerdには、Durable Objectsという分散ステート管理の仕組みが実装されています。特定のデータへの処理を1つのオブジェクトに集約し、一貫性を保つための機能です。ただし現状のworkerdのDurable Objectsは、単一インスタンスにしか対応しておらず、スケールしないという制約があります。

単一インスタンスしか使えないDurable Objectsの制約を示すイラスト。緑の部屋1つがコーラル色のデータで満杯になっている一方、同じ形の部屋2つが空のまま使われていない

celldは、Ryan Dahlが分散型のDurable Objectsを自前で運用するために開発したプロジェクトで、2025年8月にリリース済みです。Rustで書かれた単一バイナリで、外部依存はオブジェクトストレージのみという軽量な構成になっています。workerdとcelldの統合は、この単一インスタンスの制約を解消することを目指しています。具体的な技術発表は、今後数か月以内の予定とされています。

Publickeyの記事は、この合流を単純な買収・救済ではなく技術的な結合だと見立てています。Cloudflareはオープンソースの Durable Objects 実装を求めていて、Deno LandはDeno Deployを拡張するためにcelldを開発していた——という相互補完の構図だという説明です。

Web開発者が今すべきこと——製品ごとに分けて判断する

Deno Deployを使っている開発者には、6か月という期限がすでに始まっています。移行パスの詳細は今後の発表で示される予定なので、新規の長期運用をDeno Deploy前提で増やす判断は、いったん保留する価値があります。

JSRを使っている開発者に、緊急の対応は必要ありません。運営が継続するため、現状のパッケージ管理は変わりません。インフラ移行に伴う挙動の変化だけ、しばらくは確認しておきたいところです。

Cloudflare WorkersのDurable Objectsでスケールが必要なアーキテクチャを検討している開発者には、今が判断の分かれ目になります。現状の単一インスタンス制約を前提に設計を固めてしまう前に、今後数か月の技術発表を待つ方が、手戻りは小さくなります。

まとめ

Deno Deployはもともと、Cloudflare Workersと競合する立場にありました(2021年にはCloudflare側の誤ブロックで問題になったこともあります)。その両者が合流した今、残る問いは合流そのものではなく、workerdとcelldの統合がいつ技術的に確定するか、です。Deno Deployを使っている開発者にとっては6か月、JSRを使っている開発者にとってはほぼ影響なし、という期限の差がすでに生まれています。Durable Objectsのスケーリング制約が外れるかどうかは、今後数か月の発表を見てから判断すれば足ります。